RE: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Hi George,
On Tue, Jul 09, 2013 at 14:47:26, Cherian, George wrote:
+ usb_otg_hs1: am4372_dwc3@4838 {
Wouldn't usb a better node name ?
+ compatible = ti,am437x-dwc3;
Usage of wild card is discouraged per DT documentation.
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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: omap: make am43xx build with SMP enabled
Hi, On Mon, Jun 24, 2013 at 12:47:42, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [130621 16:28]: With am43xx enabled, omap4 and omap5 disabled and SMP on, I get these build errors: arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': :(.text+0x7858): undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': :(.text+0x793c): undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die': :(.ref.text+0x44): undefined reference to `omap4_hotplug_cpu' The easiest way to work around that is to turn on the missing functions, even though we know they won't be used on am43xx, which is single-CPU. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Ankur Kishore a-kish...@ti.com Cc: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Looks OK to me: Acked-by: Tony Lindgren t...@atomide.com Wait, seeing another build error after applying this patch, I will respond back soon. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: omap: make am43xx build with SMP enabled
Hi Arnd, Tony, On Sat, Jun 22, 2013 at 04:52:47, Arnd Bergmann wrote: With am43xx enabled, omap4 and omap5 disabled and SMP on, I get these build errors: Getting AM43x only build with OMAP4/5 disabled was really difficult with original series itself, I thought finally had got a right Makefile change handling SMP combinations too, but still :(, my brain was not big enough to think of multiplatform case :) Thanks Arnd for the patch. arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': :(.text+0x7858): undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': :(.text+0x793c): undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die': :(.ref.text+0x44): undefined reference to `omap4_hotplug_cpu' The easiest way to work around that is to turn on the missing functions, even though we know they won't be used on am43xx, which is single-CPU. This change was giving errors mainly due to unavailable omap4 prcm functions required by omap-mpuss-lowpower.c How about the below patch - we don't need to include additional files with it, or something wrong with it ? Regards Afzal ---8-- From: Afzal Mohammed af...@ti.com Date: Mon, 24 Jun 2013 12:41:05 +0530 Subject: [PATCH] ARM: OMAP2+: AM43x: resolve SMP related build error If AM43x and SMP is selected, OMAP4 OMAP5 deselected, build error as follows, arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': arch/arm/mach-omap2/sleep44xx.S:131: undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode' arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': arch/arm/mach-omap2/sleep44xx.S:227: undefined reference to `omap4_get_scu_base' arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode' Resolve it by building sleep44xx.S only for OMAP4 OMAP5. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 0520dc4..a6c4187 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -35,8 +35,9 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o smp-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o smp-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -omap-4-5-common= omap4-common.o omap-wakeupgen.o \ - sleep44xx.o +omap-4-5-common= omap4-common.o omap-wakeupgen.o +obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +obj-$(CONFIG_SOC_OMAP5)+= sleep44xx.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) $(smp-y) obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common) $(smp-y) obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common) -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2: reboot: Include common.h to fix build error
Hi,
On Wed, Jun 19, 2013 at 23:16:41, Axel Lin wrote:
Include common.h which will include linux/reboot.h to fix below build error.
CC arch/arm/mach-omap2/omap4-restart.o
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: 'enum reboot_mode'
declared inside parameter list [enabled by default]
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 ('mode') has
incomplete type
arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn't
a prototype [-Wstrict-prototypes]
make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Axel Lin axel@ingics.com
---
Seems this build error is introduced by commit 7507d035f3cf40c
reboot: arm: change reboot_mode to use enum reboot_mode
This patch is against linux-next 20130619.
diff --git a/arch/arm/mach-omap2/omap4-restart.c
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..7306d9b 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -9,6 +9,7 @@
#include linux/types.h
#include prminst44xx.h
+#include common.h
Arnd has posted a patch [1] that includes reboot.h directly for
multiple platforms including this one.
Regards
Afzal
[1] https://lkml.org/lkml/2013/6/19/498
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v2 0/2] Remove unused voltagedomain data for AM33xx
Hi, On Mon, Jun 17, 2013 at 18:46:21, Nayak, Rajendra wrote: The powerdomain framework currently expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. All these SoCs', hence do not support any form of auto-scaling of voltages, that was possible on earlier OMAPs' using the VFSM to trigger an i2c communication to the PMIC automatically on hitting a low power state. Instead of adding dummy voltage domain data files, like was done for the AM33xx case, make the powerdomain framework aware of the fact that some SoCs' might not really have support for auto-scaling of voltages in hw. Patches are based of 3.10-rc6 and are boot tested on am335x bone. Tested-by: Afzal Mohammed af...@ti.com (am335x evm) 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig
Hi Tony, On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote: I've updated this patch to remove the default y and depends on ARCH_OMAP2PLUS entries for the usual reasons and applied the first ten patches into omap-for-v3.11/soc. Thanks. Patch 10 ARM: OMAP2+: AM43x: basic dt support is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig
Hi Tony, On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [130613 00:04]: Patch 10 ARM: OMAP2+: AM43x: basic dt support is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream. Hmm if that's .dts changes, Benoit needs to queue that. It is not dts change. Patch 10 patches board-generic.c for DT boot (Benoit has already picked up dts, that is patch 14). 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/14] ARM: OMAP2+: AM43x initial support
Hi Tony, On Mon, May 27, 2013 at 20:03:27, Mohammed, Afzal wrote: This series adds initial support for AM43x based SoC's. To boot AM43x, in addition to these patches, PRCM support is also needed, which would be posted later as a separate series. DT sources doesn't have ti,hwmod entry - this would be added along with PRCM support. AM43x SoC's are based on ARM Cortex-A9 with one core. AM43x is similar to AM335x in it's peripheral capabilities, except a few additional ones, with many of the peripheral register mapping's similar. AM43x has a sync timer, which is being used as clocksource. Clockevent used is 1ms dmtimer. SoC has PL310 L2 cache, support for it would be added later. soc_is_am43xx() is introduced to handle AM43x specific details and soc_is_am437x() is a subclass of it - first member of the class. AM43x is currently in pre-silicon stage and currently there are no public documents. This has been tested on a pre-silicon platform that emulates AM43x SoC with additional changes on top of this. AM335x based board (AM335x EVM) has been verfied to boot as earlier with this series. Baseline: v3.10-rc3 Dependency: ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature by Vaibhav Hiremath hvaib...@ti.com If you have any comments on this series please let me know, else if you are okay with this, please consider patches 1-10 for inclusion in the coming merge window. Patch 14/14 has been taken by Benoit and patches 11-13 are to be dropped (as per discussion in 11/14 thread) Regards Afzal
RE: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Benoit,
On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:
And in this case, you do not introduce any new revision.
There is no point to update the binding each time we add a new SoC
variant that will contain the exact same IP.
I think it will mainly confuse the user that will wonder what is
different in that version compare to the previous one, moreover we can
end up with hundred of entries for the exact same IP for nothing.
The real problem is due to the introduction of the SoC name in the
device compatible name. That does introduced a SoC level information
that is mostly irrelevant at device level. I can understand why it was
done for practical aspect when the IP version is not well identified,
but that can lead to this proliferation of new pointless bindings.
As opinions on $subject seems not yet to be conclusive, I plan to
rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes
use of C preprocessor on OMAP DTS) and post separately dropping
11-14 patches, is that okay ?
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Jon, On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: ti,am335x-timer (applicable to AM335x devices) ti,am335x-timer-1ms (applicable to AM335x devices) + ti,am4372-timer-1ms, ti,am335x-timer-1ms for AM43x 1ms timer + ti,am4372-timer, ti,am335x-timer for AM43x timers other than 1ms one If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. Stephen took words out of my finger ;) Some explanations, 1. first compatible should be exact device [A], followed by compatible model (if one) 2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase). As we both were in GPMC land earlier, an example, If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required. Regards Afzal [A] http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
RE: [PATCH v2 12/14] Documentation: dt: binding: omap: am43x counter
Hi Jon, On Wed, May 29, 2013 at 02:56:05, Jon Hunter wrote: Changelog should state why this is needed. Please see my reply on 11/14 thread. Regards Afzal
RE: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Benoit, On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote: On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. Stephen took words out of my finger ;) Some explanations,I don;t 1. first compatible should be exact device [A], followed by compatible model (if one) 2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase). As we both were in GPMC land earlier, an example, If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required. That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver interface in the Device Tree model description. Since the driver does not support any new compatible string, you should not update the binding. I have a different opinion: Binding documentation is to be considered an entity that is not a part of the Kernel, but currently is a part of the Kernel for want of a better place. And binding is to be considered OS agnostic being ignorant of any piece of software (driver here). Binding has the authority to allow its usage in DT sources. The driver and the binding will have to be changed the day you will have to update the driver to handle a bug / feature specific to that revision (ti,am4372-timer). Since this series does not seems to update the driver, you should not update the bindings. I believe that updating binding is a prerequisite for making a new DTS change, hence binding was updated first, then DTS. Regards Afzal
RE: [RFC 2/8] ARM: twd: register clock event for 1 core SMP
Hi Rob,
On Mon, Feb 18, 2013 at 19:17:29, Rob Herring wrote:
On 02/18/2013 12:30 AM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one core, this is being registered as per
existing boot flow, with a difference that they happens after delay
calibration. Registering the clock for tick in case of one core should
be done before Kernel calibrates delay (this is required to boot,
unless local timer is the only one registered for tick). Registering
twd local timer at init_time (which platforms are doing now) helps
achieve that with the proposed change.
This helps in an almost booting Kernel (minimal) by only relying on
ARM parts for an A9 one core SMP.
arch/arm/kernel/smp_twd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 616268c..118f4f2 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -335,6 +335,9 @@ static int __init
twd_local_timer_common_register(struct device_node *np)
twd_get_clock(np);
+ if (num_possible_cpus() == 1)
+ twd_timer_setup(evt);
+
Shouldn't this be fixed in the core code, so the same issue is fixed for
all timers?
Is the following that you had in mind ? (with it, this patch as well as
1/8 would not be required),
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index d3a22be..2b6417d 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -42,6 +42,8 @@ void handle_IPI(int ipinr, struct pt_regs *regs);
*/
extern void smp_init_cpus(void);
+extern void smp_monocore_timer_setup(void);
+
/*
* Provide a function to raise an IPI cross call on CPUs in callmap.
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 5f73f70..7431b77 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -504,6 +504,15 @@ int local_timer_register(struct local_timer_ops *ops)
}
#endif
+void __init smp_monocore_timer_setup(void)
+{
+ unsigned int cpu = smp_processor_id();
+ struct clock_event_device *evt = per_cpu(percpu_clockevent, cpu);
+
+ if (!lt_ops)
+ lt_ops-setup(evt);
+}
+
static void __cpuinit percpu_timer_setup(void)
{
unsigned int cpu = smp_processor_id();
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..eb023ee 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -116,5 +116,6 @@ int __init register_persistent_clock(clock_access_fn
read_boot,
void __init time_init(void)
{
machine_desc-init_time();
+ smp_monocore_timer_setup();
sched_clock_postinit();
}
Regards
Afzal
RE: [PATCH, RFC 7/8] ARM: dts: am4372: initial support
Hi Felipe,
On Mon, Feb 18, 2013 at 23:52:40, Balbi, Felipe wrote:
On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
+ uart1: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ clock-frequency = 4800;
+ reg = 0x44e09000 0x2000;
+ interrupts = 0 72 0x4;
missing ti,hwmods ??
It is a deliberate omission. For minimal bootconsole booting, hwmod
help is not required. Hwmod details would be added gradually later,
current series doesn't register hwmod.
Regards
Afzal
RE: [PATCH, RFC 4/8] ARM: am33xx: ll debug config help
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH, RFC 8/8] ARM: dts: am43-pre-silicon support
Hi Santosh, On Tue, Feb 19, 2013 at 16:05:22, Shilimkar, Santosh wrote: On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote: AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in a pre-silicon platform. To validate and boot Linux in pre-silicon platform that emulates an AM43 SoC, add DT build support. Note: This would be replaced by an original board support. - am335x-bone.dtb + am335x-bone.dtb \ + am43-pre-silicon.dtb Well the pre-silicon platform and the SOC are very close and at least the support you are adding here is exactly same. So lets just use am437x.dtb or something like that. SoC support is already added in patch 7/8. This is board (which doesn't exist now) support, hence a pre-silicon temporary one to validate it. Regards Afzal
RE: [PATCH, RFC 8/8] ARM: dts: am43-pre-silicon support
Hi Santosh, On Tue, Feb 19, 2013 at 16:30:13, Shilimkar, Santosh wrote: On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote: SoC support is already added in patch 7/8. This is board (which doesn't exist now) support, hence a pre-silicon temporary one to validate it. I mean we can call it am437x-xyxboard.dtb already considering the data here can be re-used. Boot-args can be used from default kernel config with CONFIG_CMDLINE_FORCE. No strong opinion if you still insist to have a pre-silicon dtb. This patch would be replaced by original board, once it is known. This was included to make a working complete series and if someone wants (internally) to test the series as is. Regards Afzal
RE: [PATCH, RFC 0/8] ARM: AM43 (OMAP2+) boot support
Hi Santosh,
On Tue, Feb 19, 2013 at 15:39:32, Shilimkar, Santosh wrote:
After looking at the specs, you don't need the SMP mode since ACP
isn't being used.
TWD use for AM437x is also limited because these times stops in
low power sates and there you will need broad-cast mechanism which
again more of SMP machine feature.
So I suggest to use the wakeup timer(GPT1) clock-event instead
of local timer for the mentioned reason.
Ok, all your remaining comments are w.r.t SMP and usage of TWD
as clock event.
I am not that familiar with SMP things, upon starting on AM43,
observing the fact that it is an SMP with one core configuration
and that as per ARM MP Core TRM it can have local timer, I saw
it as a ray of hope to get Kernel booting early without hwmod,
and I jumped on that idea which I feel was natural. Without
spending too much time on it, though of taking feedback on this
approach, resulting this rfc.
Let me understand more on SMP, TWD, and explore possibility
of using GPT1 instead of TWD for clock event.
From the beginning I wondered on seeing that as per ARM TRM's
Cortex-A9 can be MP core with 1-4 core (instead of 2-4), while
another uniprocessor A9 configuration is present.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v3 00/10] video: da8xx-fb: runtime timing configuration
Hi Tomi, Florian,
On Tue, Jan 15, 2013 at 19:00:50, Mohammed, Afzal wrote:
This series makes da8xx-fb driver (device found on DaVinci and AM335x)
capable of handling runtime timing configuration by adding fb_set_par.
The last change adds actual fb_set_par support. Other preceeding
changes makes the way clear for it as well as does certain cleanup's
on the way.
This has been tested on da850 evm as is. This was also tested on
am335x-evm am335x-evmsk with a series that adds DT support.
This is based on v3.8-rc3, this is the only change in this revision.
The new version of this series is being posted so that this series can
be applied easily (as __dev* are removed, there would be merge
conflicts with v2, which was based on -rc2).
series
Can you please consider this series for inclusion. There are no
pending comments or dependency for this series. If you need a
pull request, let me know, I will sent it.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: DT GPMC SRAM and NOR flash support ?
Hi Jon, On Tue, Feb 05, 2013 at 22:05:20, Hunter, Jon wrote: On 02/05/2013 10:16 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive. Sorry for the delay. I personally don't have anything in the pipe. Afzal, do you know of anyone looking at this? I am not aware of anyone working on it. Regards Afzal
RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Paul,
On Fri, Jan 25, 2013 at 17:48:22, Mohammed, Afzal wrote:
On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
like MPU CPUFreq. I'd suggest reverting
241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
As you prefer reverting the above commit, I will proceed so, hmm.. got
This patch or reverting the above mentioned commit is not required for
lcdc to be usable on am335x, instead please consider for inclusion
patches 3 4 of this series,
ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper and
ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
Patches 3 4 are required to have a functional frame buffer driver
on am335x, also it may help drm driver for the lcdc ip in am335x to
be a platform independent one.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
Hi Mike,
On Sat, Jan 26, 2013 at 04:14:53, Mike Turquette wrote:
I think Paul W. or someone on the TI side should weigh in on your clkdev
entries. My main point is that the actual tree should be modeled and
clocks shouldn't be globbed together unnecessarily. As mentioned in the
other mail thread you might be better off making a divider for your LCDC
IP block and modeling each node individually.
It seems complexity of driver would increase by creating a new inherited
divider clock and having a total 3-4 clock nodes. The advantage going
with it would be higher configurable resolution for pixel clock.
Current use cases work without higher pixel clock resolution.
And drm driver posted for the same IP is without CCF modeling.
So I will presently not model clock nodes in LCDC IP, later if use cases
badly require, this can be done (and if it happens, hopefully by that
DaVinci would be CCF'ed and it would be more clean to implement it).
Thanks for sharing your ideas.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike, On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote: Thank you for the information. In short, the way you program your clock depend on the configuration of your lcdc device. As such I am not sure the basic divider is the right choice for you. You might be better off creating a clock for your IP which takes into account these details. Luckily it is possible to inherit from the basic clock types and create a new type. An example of this is the MXS divider. It uses the basic divider as a parent class and adds a busy bit. This is a better approach than putting every feature into the basic divider type. You can see how it was done in drivers/clk/mxs/clk-div.c Let me know what you think. Yes, a derived divider is better. As mentioned in other thread, the modeling of clock nodes (derived plus gates) would bring in considerable (relative to complete driver) code, the advantage being higher pixel clock resolution. Current use cases work as per existing divider setting in driver. Hence now it seems a better decision now is to proceed with logic as in v2 (not using clock nodes). And later depending on the use case requirement, clock tree modeling can be implemented. Thanks for your input. Regards Afzal
RE: RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Mike, On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote: Is MULT_ROUND_UP doing the right thing for you in the clk_divider code? What is the clock rate requested of the parent PLL? I just want to make sure that we're doing the right thing in the basic divider code. Actually MULT_ROUND_UP made my life difficult earlier, and finally came up with this solution instead of removing it. It was something like 6000 requested of PLL, for i = 1, but for other values, it was something like 6001, 6002 etc. Even if round rate rounds, I thought removing MULT_ROUND_UP would be ok, couldn't spend time to understand fully rational behind it, and as it was in generic code, kept away from doing it. Regards Afzal
RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
Hi Rob,
On Fri, Jan 25, 2013 at 20:22:55, Rob Clark wrote:
On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal af...@ti.com wrote:
It's not about being simple, but not doing the wrong way, here you are
relying on a platform specific clock in a driver, think about the case
where same IP is used on another platform. Either way it is not a good
thing to handle platform specific details (about disp_clk) in driver.
Right, but I was trying to understand what was the benefit that the
added complexity is. I didn't realize on davinci that you are limited
Here I am referring to usage of disp_clk,
Driver is not supposed to do platform hacks - here you are trying to
configure something (PLL) in your driver which is not part of LCDC IP.
And LCDC IP is not aware of PLL which is a platform specific matter
(existent only in AM335x), it is only aware of functional clock.
You can set the rate on fck (functional clock) in AM335x using my patch,
ARM: AM33XX: clock: SET_RATE_PARENT in lcd path, and there
would not be any need for driver to be aware of platform specific PLL.
+ priv-clk = clk_get(dev-dev, fck);
+ priv-disp_clk = clk_get(dev-dev, dpll_disp_ck);
at the moment all this discussion is a bit moot. I'd propose leaving
the driver as it is for now, because that at least makes it useful on
am33xx. And when CCF and davinci have the needed support in place,
Let's forget about leveraging CCF in driver, but sane solution w.r.t PLL
configuration would be to do as mentioned above.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 1/3] usb: otg: nop: add dt support
Hi Michael,
On Mon, Jan 28, 2013 at 03:10:05, Michael Grzeschik wrote:
On Thu, Sep 27, 2012 at 11:15:05AM +0530, Afzal Mohammed wrote:
From: B, Ravi ravib...@ti.com
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
What happend to that patch? It did not show up in any new series. Is it
queued anywhere?
This patch was not required to get the single instance usb supported
on am335x.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: OMAP baseline test results for v3.8-rc5
Hi,
On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
* am335xbone: hangs after Starting kernel
- Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
- http://marc.info/?l=linux-omapm=135903184512238w=2
FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
to help my bone, no matter if I had appended DTB or not.
Following patch with low level debug may help to find where the issue is,
(my observation is that it boots with mainline u-boot)
Regards
Afzal
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..178a411 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -117,6 +117,10 @@ config SOC_AM33XX
select CPU_V7
select MULTI_IRQ_HANDLER
select COMMON_CLK
+ select MACH_AM335XEVM
+
+config MACH_AM335XEVM
+ bool
config OMAP_PACKAGE_ZAF
bool
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: OMAP baseline test results for v3.8-rc5
Hi Felipe,
On Mon, Jan 28, 2013 at 16:17:52, Balbi, Felipe wrote:
will try your patch, but are you using Beagle Bone white or black ? I
should've made it clear I'm using beagle bone black.
Hmm.., I am using white, have never tried on black.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: OMAP baseline test results for v3.8-rc5
Hi Felipe, On Mon, Jan 28, 2013 at 17:08:19, Balbi, Felipe wrote: seems to be a bug with __unflatten_device_tree()... U-Boot# bootm 0x8020 - 0x80f8 Try loading dtb at a different address, I do, bootm 8100 - 8200 Regards Afzal
RE: OMAP baseline test results for v3.8-rc5
Hi Felipe, On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote: didn't help :-s Hands up :( Regards Afzal
RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
Hi Mike, On Thu, Jan 24, 2013 at 22:30:44, Mike Turquette wrote: Quoting Mohammed, Afzal (2013-01-24 03:36:02) So there are 3 - LIDD is actually not for present use case, CORE could be clubbed with the divider to have a composite clock. And CORE is in functional clock path and logically it's perfectly alright to have the composite clock. Some of the clock names are a bit generic, so a question that I'm going to repeat throughout my response: is this clock only inside of your video IP ? Yes these three clocks are inside LCDC IP. Regarding the CORE clock, is this only inside of your IP or are you referring to the SoC CORE clock which is driven by a DPLL and clocks DDR and many other peripherals (often MMC, UART, etc)? Sorry for the confusion, here CORE refers to clock inside LCDC IP. This CORE should not be confused with CORE PLL. Actually I used CORE so that it corresponds to the nomenclature in LCDC section of TRM. Note that this is from my past experience with OMAP, and I'm making an assumption that the clock scheme between OMAP and Da Vinci/AM335x parts isn't very different. Additional detail: DaVinci doesn't have these 3 clocks controls available, so these three are required only on AM335x (which has IP version 2 ) Is there a public TRM I can look at? It would help me understand this without having to ask you so many annoying questions ;) No problem, http://www.ti.com/product/am3359 And now we are left with DMA, this is actually in the interface clock path which driver in unaware. An option would be to have DMA clock as child of CORE plus divider composite clock, even though logically DMA can't be considered in the same path. Why is the driver unaware of the interface clk? For instance OMAP3 had separate fclk and iclk for IPs and drivers would call clk_enable on both. Or am I misunderstanding something? HWMOD handles enabling those upon pm_runtime calls, HWMOD makes an alias for main clock with fck, but not for ick, so currently ick is unavailable for the driver, continued below .. In general I don't think the clock subtree should be modeled in a way that is convenient for software, but instead model the actual hardware. Trust me, if you don't model the actual hardware then you will be very confused when you come back and revisit this code in 6 months and can't remember why things are so weird looking. Ok, then it seems an omap clock entry for con-id ick should be created as follows (dpll_core_m4_ck supplies interface clock), CLK(4830e000.lcdc,ick, dpll_core_m4_ck, CK_AM33XX) And then in the driver, DMA gate clock should be made a child of this clock (obtained with con-id ick). Let me know your opinion on this. Regards Afzal
RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike, On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote: Quoting Mohammed, Afzal (2013-01-24 03:29:15) It is a functional constraint: divider has 8 bits and it can have all possible values (0 to 255) and divider value corresponds to value set in the 8 bits. But depending on the modes the minimum value that can be configured (to get display working) varies. Eg. For raster mode (which the driver is presently supporting), it can take a minimum value of 2, while in LIDD (LCD interface display driver) mode it can take a min value of 1. Here min rate is not a constraint w.r.t divider in LCDC IP, but rather min divider. Just so I understand correctly... you are saying that the functional constraint is not caused by the clock rate, but instead by the divider value? For the different modes (raster vs LIDD) is the clock rate the same, or is the clock rate different? What is the clock output rate of the divider in raster mode? What is the clock output rate of the divider in LIDD mode? Yes, functional constraint in caused by divider value. clock output rate can defined for both modes as follows, p_clk (clock output rate) = lcd_clk (input clock rate) / div, to configure div, we have r/w 8 bits, so div values can range from 0-255, And IP spec says value 0 and 1 should not be written, in raster mode. Further it says if in LIDD mode it can have values from 0-255, but effect of writing 0 is same as 1. Effect of divider value on output rate is in the same way for both modes as per above expression (except for writing 0 in LIDD mode). The driver supports only raster mode. Regards Afzal Note: link to trm has been mentioned in the earlier reply.
RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Paul, On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote: On Wed, 23 Jan 2013, Afzal Mohammed wrote: Currently round rate function would return proper rate iff requested rate exactly matches the PLL lockable rate. This causes set_rate to fail if exact rate could not be set. Instead round rate may return closest rate possible (less than the requested). And if any user is badly in need of exact rate, then return value of round rate could be used to decide whether to invoke set rate or not. Modify round rate so that it return closest possible rate. This doesn't look like the right approach to me. For some PLLs, an exact rate is desired. If exact rate is required, there is a way to achieve it as mentioned in the commit message, i.e. by first invoking round rate over reqd. rate and if it doesn't match, bail out w/o invoking set_rate. And it seems requirement of CCF w.r.t to round rate is to return closest possible rate. We removed the rate tolerance code in commit 241d3a8dca239610d3d991bf58d4fe38c2d86fd5, but that was probably premature. We've encountered several situations now where we could really use it, like MPU CPUFreq. I'd suggest reverting 241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach. As you prefer reverting the above commit, I will proceed so, hmm.. got not so simple merge conflict, wish there was a command, git revert logical .. Regards Afzal
RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
Hi Rob,
On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
+void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
+ /* in raster mode, minimum divisor is 2: */
+ ret = clk_set_rate(priv-disp_clk, crtc-mode.clock * 1000 * 2);
These things can better be handled with divider clock having a
minimum value (being discussed with Mike on how exactly it should
be) and instead of setting rate over a platform specific clock,
you can set rate over lcd clock using SET_RATE_PARENT at platform
level, more below,
+ /* Configure the LCD clock divisor. */
+ tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
+ LCDC_RASTER_MODE);
+
+ if (priv-rev == 2)
+ tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
+ LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
+ LCDC_V2_CORE_CLK_EN);
Mike was suggesting to model the above using gate/divider/composite
clocks of CCF in the FB driver.
+ priv-clk = clk_get(dev-dev, fck);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev-dev, failed to get functional clock\n);
+ ret = -ENODEV;
+ goto fail;
+ }
+
+ priv-disp_clk = clk_get(dev-dev, dpll_disp_ck);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev-dev, failed to get display clock\n);
+ ret = -ENODEV;
+ goto fail;
+ }
dpll_disp_ck is a platform specific matter, driver should not
be handling platform specifics. And this won't work on DaVinci,
you can probably make use of
my series [PATCH v2 0/4] ARM: AM335x: LCDC platform support
or something similar to overcome this.
Regards
Afzal
RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
Hi Rob,
On Fri, Jan 25, 2013 at 19:29:40, Rob Clark wrote:
On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal af...@ti.com wrote:
On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
+void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
+ /* in raster mode, minimum divisor is 2: */
+ ret = clk_set_rate(priv-disp_clk, crtc-mode.clock * 1000 * 2);
These things can better be handled with divider clock having a
minimum value (being discussed with Mike on how exactly it should
be) and instead of setting rate over a platform specific clock,
you can set rate over lcd clock using SET_RATE_PARENT at platform
level, more below,
I looked at that patch you were proposing for da8xx-fb.. to be
honest, it did not seem simpler to me, so I was sort of failing to see
the benefit..
It's not about being simple, but not doing the wrong way, here you are
relying on a platform specific clock in a driver, think about the case
where same IP is used on another platform. Either way it is not a good
thing to handle platform specific details (about disp_clk) in driver.
And Mike mentioned that one of design goals of CCF is to model these
kinds of clocks in IP's.
+ /* Configure the LCD clock divisor. */
+ tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
+ LCDC_RASTER_MODE);
+
+ if (priv-rev == 2)
+ tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
+ LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
+ LCDC_V2_CORE_CLK_EN);
Mike was suggesting to model the above using gate/divider/composite
clocks of CCF in the FB driver.
+ priv-clk = clk_get(dev-dev, fck);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev-dev, failed to get functional clock\n);
+ ret = -ENODEV;
+ goto fail;
+ }
+
+ priv-disp_clk = clk_get(dev-dev, dpll_disp_ck);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev-dev, failed to get display clock\n);
+ ret = -ENODEV;
+ goto fail;
+ }
dpll_disp_ck is a platform specific matter, driver should not
be handling platform specifics. And this won't work on DaVinci,
you can probably make use of
meaning the clock has a different name on davinci, or? Presumably
there must be some clock generating the pixel clock for the display,
but I confess to not being too familiar with the details on davinci..
The only option for the driver in DaVinci is to configure clock rate
using the divider of LCDC IP, it has fck, which gives a rate
decided by its ancestors.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi Kishon, On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote: On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote: On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote: USB first instance of am335x works in mainline as of now. Can you check if this series indeed breaks am335x? Thanks for your help. Do you have a tree having these changes, it would be easier for me. I tried with your omap5-with-palmas branch that was mentioned in the cover letter of your latest series (but couldn't find the commit that you mentioned in the cover letter, HEAD of that branch that I tested was 2c29519 ARM: dts: palmas: update dt data for palmas-usb) usb first instance of am335x works as earlier. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike,
On Thu, Jan 24, 2013 at 03:10:53, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-23 03:38:52)
Some of clocks can have a limit on minimum divider value that can be
programmed, prepare for such a support.
Add a new field min_div for the basic divider clock and a new dynamic
clock divider registration function where minimum divider value can
be specified. Keep behaviour of existing divider clock registration
functions, static initialization helpers as was earlier.
My first question is whether the minimum divider you plan to use is an
actual constraint of the hardware (e.g. the clock controller ip only
lets program two bits which divide by 4, 5, 6 or 7, where 4 is the
minimum divider) or if this is a functional constraint (e.g. the clock
hardware can divide by a lower value, but you never want that since it
results in non-functional video/audio/whatever). If this is more of a
functional constraint then perhaps a new api like clk_set_min_rate makes
more sense.
It is a functional constraint: divider has 8 bits and it can have
all possible values (0 to 255) and divider value corresponds to
value set in the 8 bits. But depending on the modes the minimum
value that can be configured (to get display working) varies.
Eg. For raster mode (which the driver is presently supporting), it
can take a minimum value of 2, while in LIDD (LCD interface display
driver) mode it can take a min value of 1.
Here min rate is not a constraint w.r.t divider in LCDC IP, but
rather min divider.
As it is the case, you prefer a clk_divider_set_min_div()?
Secondly, have you looked into using the rate-table option provided by
the basic divider clock? Can you explain how this is not a good fit for
your needs? Perhaps there are too many divisor values so the table
would be large?
Divider values can range from 2-255 (254 possible values), so I believe
it is not a suitable candidate here (also divider to values have 1-to-1
mapping)
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
Hi Mike,
On Thu, Jan 24, 2013 at 01:52:04, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-23 03:48:56)
+static inline void da8xx_fb_clkc_enable(void)
+{
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par
*par,
+ struct fb_videomode
*mode)
+{
+ ret = clk_set_rate(par-child_clk, PICOS2KHZ(mode-pixclock) *
1000);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(par-dev, unable to setup pixel clock of %u ps,
+ mode-pixclock);
+ return ret;
+ }
+ da8xx_fb_clkc_enable();
It looks like you are using the legacy method to enable/disable the
clock and using the CCF basic divider to set the rate. This feels a bit
hacky to me. If you want to model your clock in CCF then you should
probably model the whole clock, not just the rate-change aspects of it.
Initially I thought about it, but seeing requirement of 3 gate clocks
(due to 3 bits meant for different purposes - DMA, LIDD and CORE
functionalities), felt that having 4 clocks (3 gate + 1 divider) in
driver would be an overdesign [leaving a branch instead of a leaf of
the tree in driver ;)].
Have you looked at the composite clock patches from Prashant? Those
might give you the divider+gate properties that you are looking for:
http://article.gmane.org/gmane.linux.kernel/1416697
Thanks for the pointer,
Now with the composite clock in mind, it was tried to relate to what
was required for the present scenario.
So there are 3 - LIDD is actually not for present use case, CORE could
be clubbed with the divider to have a composite clock. And CORE is
in functional clock path and logically it's perfectly alright to have
the composite clock.
And now we are left with DMA, this is actually in the interface clock
path which driver in unaware. An option would be to have DMA clock
as child of CORE plus divider composite clock, even though logically
DMA can't be considered in the same path.
Also tried not enabling DMA clock, but driver is able to provide
display without any issues, so was thinking whether to avoid
instantiating DMA clock at all and hence to have a simple single
composite clock. Trying to get information internally on whether
not setting DMA clock bits would actually make a difference.
If you have any opinion on how to deal here, let me know.
Regards
Afzal
RE: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi Kishon, On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote: On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote: USB first instance of am335x works in mainline as of now. Can you check if this series indeed breaks am335x? Thanks for your help. Do you have a tree having these changes, it would be easier for me. Regards Afzal
RE: [PATCH v3 00/12] video: da8xx-fb: am335x DT support
Hi,
On Wed, Jan 23, 2013 at 00:15:09, Rob Clark wrote:
Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM
based driver for this IP block?
we probably can't delete da8xx-fb, but I think it would be ok to only
use it for legacy platforms not yet ported to DT.
We can't remove da8xx-fb as DA830 is a non-DT one and DA850 is only gaining
DT support.
And Rob,
I am not familiar with drm setup, would all the user space frame buffer based
applications work as is with drm driver?
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
Hi Mike, On Wed, Jan 16, 2013 at 10:32:10, Nori, Sekhar wrote: On 1/15/2013 9:02 PM, Mike Turquette wrote: Quoting Afzal Mohammed (2013-01-15 05:44:36) Note: A better (if allowable) solution may be to represent clock divider in LCDC IP as a basic divider clock - the one defined in common clock framework. But for this to happen, all the platform's using this driver should be using common clock framework (DaVinci is yet to be converted to use common clock framework). And it has to be determined whether common clock framework allows this kind of a clock modelling inside a driver and for this to be part of clock tree. Advantage of doing so would be better resolution for pixel clock, even though without this existing use cases are working properly. Or another extreme alternative would be to replicate clk-divider of common clock framework inside the driver, but that probably is not preferred and not worth as it would be duplication and without much advantage to existing users. Modeling the divider inside your IP block as a clock is supported in the common clock framework. Linking up these sorts of clocks to the clock tree was one of the original design goals of CCF. Regarding DaVinci: converting that platform over to use CCF would be the best approach. This is work in progress. There are patches that have been posted. Work has been slow on this though due to lack of bandwidth. An alternative would be that you could break single-image boot for AM335x and DaVinci, by having AM335x use CCF and DaVinci use the legacy clock framework. From the LCDC driver's Single image for DaVinci and AM335x is not possible anyway since ARMv5 and ARMv6+ cannot be supported in a single image. perspective this should not matter and is indeed the purpose of the clk.h api and clkdev interfaces, however looking at this driver I can see there would still be a lot ifdef-ery going on... better to just convert everything over to CCF. Waiting for DaVinci CCF to complete will be too long a wait. Probably convert to CCF just for AM335x ATM. There would be some ifdef'ry but hopefully that need not be inside function bodies. Would have to see the implementation, I guess. v4 posted has the divider in LCDC IP modeled by clock node for CCF, for non-CCF (DaVinci), existing logic is kept as is with the help of ifdef's (as DaVinci maintainer mentioned that DaVinci CCF may take some time) Regards Afzal
RE: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
Hi Koen, On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote: Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally. USB first instance of am335x works in mainline as of now. Regards Afzal
RE: [PATCH 08/10] video: da8xx-fb: obtain fb_videomode info from dt
Hi Steffen,
On Mon, Jan 07, 2013 at 14:51:15, Mohammed, Afzal wrote:
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
+- display-timings: list of different videomodes supported by the lcd
+ panel, represented as childs, can have multiple modes supported, if
+ only one, then it is considered native mode, if multiple modes are
+ provided, native mode can be set explicitly, more details available
+ @Documentation/devicetree/bindings/video/display-timing.txt
Keep in mind that the text combined with...
+ if (of_get_fb_videomode(np, lcdc_info, 0)) {
+ dev_err(dev-dev, timings not available in DT\n);
+ return NULL;
+ }
+ return lcdc_info;
+ }
... this is not correct. You are just supporting the first display-timings
subnode (of_get_fb_videomode(..., 0)).
Yes right, I will modify the text to reflect what the driver does.
Thinking about it further, it seems the right thing to do
in this case would be to invoke as,
of_get_fb_videomode(np, lcd_info, OF_USE_NATIVE_MODE).
Updated version has been posted to the lists (forgot to cc you)
Regards
Afzal
RE: [PATCH 08/10] video: da8xx-fb: obtain fb_videomode info from dt
Hi Steffen,
On Mon, Jan 07, 2013 at 14:41:31, Steffen Trumtrar wrote:
On Mon, Jan 07, 2013 at 10:41:30AM +0530, Afzal Mohammed wrote:
Obtain fb_videomode details for the connected lcd panel using the
display timing details present in DT.
+- display-timings: list of different videomodes supported by the lcd
+ panel, represented as childs, can have multiple modes supported, if
+ only one, then it is considered native mode, if multiple modes are
+ provided, native mode can be set explicitly, more details available
+ @Documentation/devicetree/bindings/video/display-timing.txt
Keep in mind that the text combined with...
+ if (of_get_fb_videomode(np, lcdc_info, 0)) {
+ dev_err(dev-dev, timings not available in DT\n);
+ return NULL;
+ }
+ return lcdc_info;
+ }
... this is not correct. You are just supporting the first display-timings
subnode (of_get_fb_videomode(..., 0)).
Yes right, I will modify the text to reflect what the driver does.
Regards
Afzal
usb: multi phy support
Hi Felipe, AM335x SoC's used in boards like beagle bone has two instances of USB modules (2.0) at the hardware level, each having a dedicated phy. Currently in mainline, only one instance of USB is supported (including a fix in your latest pull request). To support multi instance, the biggest obstacle is lack of multi phy support for usb phy's of same type. Earlier Kishon was working on usb phy device tree support, later it was seen that generic phy layer was preferred. And Kishon posted a couple of versions on generic phy framework, latest being on 26th September 2012, but I could not see follow up's on that series. It seems Kishon is not now working on generic phy support. Let me know your opinion/suggestions on supporting usb phy's of same type. We are trying to get multi USB instance support in mainline for AM335x. Regards Afzal
RE: [PATCH] da8xx: Allow use by am33xx based devices
Hi, On Wed, Dec 12, 2012 at 13:30:56, Hiremath, Vaibhav wrote: On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. It seems adding machine dependency is more in line with the approach adopted in similar cases. As this IP is used only in 2 arch's and would not in any immediate future go with other arch's, it would be better not to ask other arch's a question on whether this driver needs to be selected or not. Regards Afzal
RE: [PATCH] usb: musb: dsps: header movement build error fix
Hi Felipe, On Tue, Nov 27, 2012 at 20:15:22, Mohammed, Afzal wrote: 54db6ee ARM: OMAP2+: Introduce local usb.h moved control module bit definitions from plat/usb.h (which dsps glue was using) to a local header in mach-omap2. And in parallel, c68bb4c usb: musb: dsps: control module handling (quirk) added control module handling capability to dsps glue driver that used those control module bit definitions. Integration of above two changes would cause build error in musb dsps glue driver (they go through different trees upstream) as is seen now in linux-next. Fix it by adding necessary definitions in dsps glue driver. Signed-off-by: Afzal Mohammed af...@ti.com --- This applies on top of your musb branch, please help this reach mainline along with other musb dsps changes for coming merge window so that they would not cause build error and so that we can have a working usb in mainline for am335x (beaglebone) at the earliest. musb dsps build breaks in mainline now, this patch fixes it, can you please help this change reach mainline. Both commits mentioned above (control module quirk usb header movement) has reached mainline. Regards Afzal
RE: [PATCH 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
Hi Tony, On Thu, Nov 08, 2012 at 03:10:14, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [121107 01:00]: And Daniel has started working on gpmc dt. Let us take Tony's opinion on how to deal with this, Tony ? Up to you to figure out the ordering. Maybe send pull requests for the ones that are ready to go? Pending timing related patches, a. ARM: OMAP2+: nand: remove redundant rounding b. ARM: OMAP2+: gpmc: handle additional timings c. ARM: OMAP2+: gpmc: generic timing calculation d. ARM: OMAP2+: onenand: generic timing calculation e. ARM: OMAP2+: smc91x: generic timing calculation f. ARM: OMAP2+: tusb6010: generic timing calculation can be divided to two categories, 1. timing cleanup (a,b) 2. migrate to generic timing routine (c-f) '1' has been tested on omap3evm (also with the help of a local patch adding onenand support). '2' has been verified on omap3evm onenand async operation (support for omap3evm onenand is not present in mainline) and by simulation. These changes could not be validated on boards supported in mainline that make use of runtime timing calculation as I do not have those boards. I will be sending pull request containing both sets 1 2, please let me know in case you have a different opinion. Regards Afzal
RE: [PATCH 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
+ Tony, Daniel
Hi,
On Wed, Nov 07, 2012 at 02:04:03, Hunter, Jon wrote:
On 11/06/2012 12:00 PM, Matthieu CASTET wrote:
I will post another patch, unless this is already done in Afzal patch (Is
there
a tree where I can get Afzal pending patches ?)
Afzal keeps his kernel tree on gitorious [1]. However, I am not sure
what Afzal's plans are for the remaining patches not yet merged and
which branch you should look at (I have a lot of problems viewing
anything on gitorious these days).
Afzal, let us know how you prefer to handle this.
My initial plan was to do timing related changes first and then dt
conversion. But at the present moment, it seems higher priority has
to be given for dt conversion over timing changes (it involves
using generic timing routine for all required gpmc peripherals,
handling additional timings inclusive of $subject) and hence timing
related changes were put in suspended animation for now.
And Daniel has started working on gpmc dt. Let us take Tony's
opinion on how to deal with this, Tony ?
Following are the pending changes w.r.t timing available @[1]
(please note that these would have to be rebased over branch/tag
specified by Tony in reply to Matthieu's patch 3/3)
a. d42eafa ARM: OMAP2+: nand: remove redundant rounding
b. f229aba ARM: OMAP2+: gpmc: handle additional timings
c. 14cbb87 ARM: OMAP2+: gpmc: generic timing calculation
d. 9830264 ARM: OMAP2+: onenand: generic timing calculation
e. 5f33ea5 ARM: OMAP2+: smc91x: generic timing calculation
f. 9876020 ARM: OMAP2+: tusb6010: generic timing calculation (HEAD)
'b' is a superset of $subject
Originally 'a' and 'b' was part of gpmc cleanup series for common
zImage, then Tony requested for minimal changes for it, hence
'a' 'b' was left out in the pull request (picked up by Tony),
so that gpmc common zImage cleanup series would not create any
timing related issues.
One thing to note is that cycle2cycledelay and busturnaround field's
would get zeroed out with $subject patch for those peripheral's that
call gpmc_cs_set_timings(). If there are any boards silently
depending on bootloader setting these values, it may be affected, so
this change would need to be verified for existing boards in mainline.
Perhaps 'b' (for $subject patch) can be taken ahead if Tony is
happy with it.
And regarding patches 2 3 of Matthieu's series that calculate
timings, I was wondering whether generic timing routine (c) can
learn from it as well as vice-versa. Also with gpmc common zImage
series, omap-nand driver does not have access to timing related
gpmc functions, a new gpmc function would have to be exported
that translates onfi timings to gpmc (or educate generic timing
routine with onfi translation too ?)
Regards
Afzal
[a] git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 0/5] usb: musb: am335x support
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 yet to that question when I asked Felipe about how interface drivers like dsps are supposed to act in order to get host mode back after the recent musb cleanups. What type of hardware do you test this with? Does host mode work for you? To add to those details mentioned by Ravi, This was tested on Beagle Bone with USB0 as usb-ethernet. For purely Kernel part, this series is sufficient (along with dependency mentioned in cover letter), considering the fact that dt node is strictly not a part of Kernel. To test this series, node for usbss should be present in dt. Example in dt documentation can be pasted onto dtsi file to get USB0 working. Alternatively, you can fetch from, git://gitorious.org/x0148406-public/linux-kernel.git usb it has dt updated with usbss node. 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 info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc1
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 merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. Note: Sending via exchange, hope this is readable. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] arm/dts: am33xx rtc node
+ 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.
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..356711e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,14 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ rtc {
+ compatible = ti,da830-rtc;
+ ti,hwmods = rtc;
+ reg = 0x44e3e000 0x1000;
+ interrupt-parent = intc;
+ interrupts = 75
+ 76;
+ };
};
};
--
1.7.12
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 2/3] RTC: omap-rtc: enable pm_runtime
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 support for writing to the
OMAP_RTC_OSC_REG (path 3/3 in my series). Would like me to rebase the
functionality? I need thatkind of setup for my board ...
This is bit tricky and required more discussion before merging it,
let me reopen the old discussion which I had started some time back -
RTC OSC clock is required to configure clocksource systemtimer for the
kernel, and it is important when you get into PM related features.
Please refer the below commit for more reference,
http://marc.info/?l=u-bootm=135057734713796w=2
Newer version (v4) of omap rtc patches for am335x has been
posted, rtc: omap dt support (for am33xx).
In case you can test, please do it over the new series.
You would need also need DT patch that adds DT node to
test (it has been separated from the series as it is
felt that it should not be part of same series),
arm/dts: am33xx rtc node
If you are using mainline uboot, you would need the fix as
mentioned by Vaibhav H (as in the link he provided above),
expecting it to reach uboot mainline soon.
If the above is being attempted to achieve in Kernel it
would cause 2-3 seconds delay in boot time (else it had
to be made a module), please refer link provided by
Vaibhav H for more details.
else you can do in current mainline uboot,
mw.l 0x44e3e06c 0x83e70b13
mw.l 0x44e3e070 0x95a4f1e0
mw.b 0x44e3e054 0x48
and then boot kernel.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [GIT PULL] OMAP-GPMC cleanup for common zImage
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-czimage Please ignore this, will repost with correct url. Regards Afzal
RE: [PATCH 0/4] OMAP-GPMC generic timing migration
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 for that set against -rc1 when it's out? Just the minimal set of patches. Pull request on gpmc cleanup for common ARM zImage has been sent. Yes, then please do a second pull request for what's needed to apply the minimal DT bindings. For the DT binding, let's just leave out the timings for now as we can load those from auxdata. Then the binding for the timings can be added later on. So just the minimal binding using standard features for the iorange and interrupt. Ok, I will keep timings aside for now and proceed with DT (avoiding auxdata usage with generic routine looked to me a saner approach though, with an initial DT'fy delay) Regards Afzal
RE: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
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 could be sparse IRQ related regression..
Patch has been posted to resolve the issue,
ARM: OMAP4: hwmod data: gpmc main clk.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: omap3 gpmc: irq-20 could not claim: err -2
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, now as certain gpmc patches got merged recently (during the ongoing merge window), this should be gone. NAND still works since it is operated in NAND_OMAP_PREFETCH_POLLED mode; however, I'd like to try NAND_OMAP_PREFETCH_IRQ to see if it brings any performance gains I vaguely remember that once while checking irq mode (not mainline, on am335x-evm), speed was less compared to default, so I doubt whether you get any performance gains, anyway it would be good to know performance results in your case. just passing NAND_OMAP_PREFETCH_IRQ via gmpc_nand_init() hangs the kernel (I guess since the request_irq() failed earlier) With mainline HEAD, you should be able to use irq. another question is dev_ready which also seems to depend on IRQ also Now it is no more. can you make any recommendation w.r.t NAND performance on OMAP? Once DMA was checked, but found it slower than other two, not sure whether I was doing anything wrong. Right now don't have any suggestions, if I come across any will let you know. Regards Afzal
RE: [PATCH 0/4] OMAP-GPMC generic timing migration
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 this series would be the required. Note that 1st patch of series [2] has already reached mainline. Another easy way would be, pull, git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing git checkout -b gpmc myremote/gpmc-timing git rebase --onto Linus-current-master next-20121005 (or 080aa9c) would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. I would be doing gpmc DT conversion next. Hoping that this series too will be picked up by Tony, as once this series is accepted, during DT conversion we need not rely on auxdata (a last resort option) for timings. Thanks for you hard work, Thanks, it was a pleasure to read the above. Regards Afzal [1] http://marc.info/?l=linux-omapm=134945131602622w=2 [2] http://marc.info/?l=linux-omapm=134967458329531w=2
RE: [PATCH v2 00/14] OMAP-GPMC related cleanup for common zImage
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 tests passed successfully. I occasionally had weird read errors though, especially when reading blank pages: the omap driver returned 512-byte sectors containing something like: I was able to reproduce the problem also on l2-mtd tip, albeit less often. The problem seems to occur quite randomly, it may be a hardware issue on my board... Anyway, the ECC handling part looks OK to me. Thanks Ivan Regards Afzal
RE: [PATCH v2 00/14] OMAP-GPMC related cleanup for common zImage
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 moved platform data header files
to contain only platform data. Also gpmc-nand information is moved
to nand platform data header.
Patches 9-13 makes nand driver independent of gpmc header file
And the final patch localizes gpmc header.
BCH[48] support that you have added on OMAP using gpmc exported
symbols has been changed such that nand driver now takes care
of BCH support without relying on gpmc exported symbols.
This is more or less a cut paste of your implementation, which was
necessitated now due to common ARM zImage cleanup w.r.t header files.
Please verify that BCH[48] works as earlier with this series.
Regards
Afzal
This series is available
@ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-czimage-v2
and is based on
linux-next (next-20121005)
and is dependent on
http://marc.info/?l=linux-omapm=134945131602622w=2
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 00/15] OMAP-GPMC related cleanup for common zImage
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
RE: [PATCH v8 0/6] OMAP-GPMC cleanup for generic timing
+ 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 as a new separate series shortly. This rearrangement has been done so that generic timing series will happen on top of another cleanup series required for common arm zImage. Both will follow shortly. Intention is to make easy path for common arm zImage cleanup. This series contains minor cleanups that were low hanging fruits came across upon implementing generic timing routine. This series is same as v7, except that last 4 patches in v7 has been removed from this series (those 4 patches were for generic timing) This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-prep-v8 and is based on linux-next (next-20121005) Regards Afzal v8: Remove generic timing conversion patches v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings 3. Remove redundant rounding of nand timings (a new patch) v6: 1. Generic timing calculation, move existing users of custom calculation to use the new generic one 2. Set OneNAND part to async mode before gpmc configuration 3. Move extra delay time user handling to proper patch (3/10 - 2/10) 4. Modify nand init for OMAP3EVM too as support got added v5: Use flags for sync_read/write, hv, vhf v4: Reorganize OneNAND set_sync/async functions in a better way v3: 1. Refactor OneNAND set_sync/async functions to separate out timing and configurations 2. Handle bool type timings too 3. Swap patches 2 3 due to dependency of OneNAND change on newly added bool type timings v2: 1. Make use of timing api for setting clock activation time, and remove direct writing to register for clock activation. 2. Move ensuring that async mode in OneNAND has been setup from set_sync to setup function, improve commit message Afzal Mohammed (5): ARM: OMAP2+: nand: unify init functions ARM: OMAP2+: nand: remove redundant rounding ARM: OMAP2+: gpmc: handle additional timings ARM: OMAP2+: onenand: refactor for clarity ARM: OMAP2+: gpmc: remove cs# in sync clk div calc Jon Hunter (1): ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function arch/arm/mach-omap2/board-devkit8000.c | 8 +- arch/arm/mach-omap2/board-flash.c | 45 ++--- arch/arm/mach-omap2/board-flash.h | 6 +- arch/arm/mach-omap2/board-igep0020.c| 2 +- arch/arm/mach-omap2/board-ldp.c | 4 +- arch/arm/mach-omap2/board-omap3beagle.c | 8 +- arch/arm/mach-omap2/board-omap3evm.c| 8 +- arch/arm/mach-omap2/board-omap3touchbook.c | 8 +- arch/arm/mach-omap2/board-overo.c | 7 +- arch/arm/mach-omap2/board-zoom.c| 5 +- arch/arm/mach-omap2/common-board-devices.c | 45 - arch/arm/mach-omap2/common-board-devices.h | 1 - arch/arm/mach-omap2/gpmc-nand.c | 30 ++- arch/arm/mach-omap2/gpmc-onenand.c | 232 arch/arm/mach-omap2/gpmc.c | 52 +- arch/arm/mach-omap2/usb-tusb6010.c | 3 +- arch/arm/plat-omap/include/plat/gpmc.h | 21 ++- include/linux/platform_data/mtd-onenand-omap2.h | 8 - 18 files changed, 262 insertions(+), 231 deletions(-) -- 1.7.12
RE: [PATCH v8 1/6] ARM: OMAP2+: nand: unify init functions
+ 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 similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board omap3evm was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-devkit8000.c | 8 --
arch/arm/mach-omap2/board-flash.c | 45
+++---
arch/arm/mach-omap2/board-flash.h | 6 ++--
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c| 4 +--
arch/arm/mach-omap2/board-omap3beagle.c| 8 --
arch/arm/mach-omap2/board-omap3evm.c | 8 --
arch/arm/mach-omap2/board-omap3touchbook.c | 8 --
arch/arm/mach-omap2/board-overo.c | 7 +++--
arch/arm/mach-omap2/board-zoom.c | 5 ++--
arch/arm/mach-omap2/common-board-devices.c | 45
--
arch/arm/mach-omap2/common-board-devices.h | 1 -
12 files changed, 62 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..9933966 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -55,8 +55,11 @@
#include sdram-micron-mt46h32m32lf-6.h
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#define NAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -621,8 +624,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
- ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
omap_twl4030_audio_init(omap3beagle);
/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..f8b30cb 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -104,41 +104,41 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -238,5 +238,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n
RE: [PATCH v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
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 register fields and the
right-hand side are the timing parameters these are calculated using.
Ok
Also, given that this is in documentation for completeness it could be
good to somewhere state what t_ceasu means. For the gpmc register
field description may be we could give a reference to an OMAP document.
Yes, it has been mentioned, as quoted below, reason it has not been
mentioned here is to avoid duplication. I will add TRM reference.
+Note: Many of gpmc timings are dependent on other gpmc timings (a few
+mentioned above, refer timing routine for more details. To know what
+these peripheral timings correspond to, please see explanations in
+struct gpmc_device_timings definition.
+struct gpmc_device_timings {
+ u32 t_ceasu;/* address setup to CS valid */
+adv_rd_off: t_avdp_r, t_avdh(s*)
+oe_on: t_oeasu, t_aavdh(a**), t_ach(s), cyc_aavdh_oe(s)
Would it be better to have ...
oe_on (sync): t_oeasu, t_ach(*), cyc_aavdh_oe
oe_on (async):t_oeasu, t_aavdh(*)
Ok
* - optional
I assume that the hold times from the clock (t_ach and t_aavdh) are used
for fine tuning if the peripheral requires this, but a user adding a new
device would not be required to specify these, where as t_oeasu is
mandatory.
It depends on the peripheral, t_oeasu in not used for OneNAND, tusb sync,
so I prefer not mentioning any timing as optional or mandatory.
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 Address/Data Multiplexed
Write Sync
Write Sync Address/Data Multiplexed
There may be some duplication but it will be clear where things like ADV
timing applies.
I would prefer to keep it concise, but no strong opinion on it, if you
prefer as above, I will change it.
+/* can the cycles be avoided ? */
Nit should this be marked with a TODO?
+ /* mux check required ? */
Nit should this be marked with a TODO?
Marking XXX should Ok, right ?, reason is that they are not
kept as TODO, but rather as pointers to may be possible
improvements
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
Any reason why we can't return ns in the above function? Or make this
function gpmc_round_ps_to_ns()? Then we could avoid having
gpmc_convert_ps_to_ns() below.
Calculation in ps is required to get more accurate results.
Calculating in ns was the reason for issue faced on N800 for Tony
with previous version.
I will explain what would have happened with v6 on N800,
i.e. using ns values,
Based on logs from Tony, gpmc clk was 9ns, actually it would
have been somewhere around 9115ps.
Take below timings of previous version in tusb async case
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on * 1000 + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on * 1000 + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on * 1000 + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
Upon calculating we get,
oe_on = 63805 / 1000 = 63
and for access (t_oe = 300, t_ce = t_aa = t_iaa = 0),
temp = 63 * 1000 + 300 = 63300
access = 63300 / 1000 = 63
Here we get oe_on as well as access as 7 ticks, but access should
have been 8 ticks, which is what we will get by using ps values,
i.e. as in this version, as below,
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp);
I believe it is always better to go with higher resolution.
+ gpmc_convert_ps_to_ns(gpmc_t);
I am wondering if we could avoid this above function and then ...
This will be removed once it is confirmed that all the peripherals
using custom runtime calculation can work with this generic
routine. Then all calculation would be purely in ps.
Right now converting ps to ns has been kept only to be compatible
with custom routines and so that we can easily go back to custom
routines in case of any issues, quoting relevant commit message below,
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
RE: Help needed with remaining plat headers
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
RE: [PATCH v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
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 Address/Data Multiplexed Write Sync Write Sync Address/Data Multiplexed There may be some duplication but it will be clear where things like ADV timing applies. I would prefer to keep it concise, but no strong opinion on it, if you prefer as above, I will change it. I think that if these represent the main use-case configurations this could add some value. Ok + gpmc_convert_ps_to_ns(gpmc_t); I am wondering if we could avoid this above function and then ... This will be removed once it is confirmed that all the peripherals using custom runtime calculation can work with this generic routine. Then all calculation would be purely in ps. Ok, great. May be add a TODO here to make this clear that this is temporary. Sure Regards Afzal
RE: query on [PATCH 2/3] usb: otg: add device tree support to otg library
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 on beagle bone (AM335X), which has 2 phy's of same type. Or is the plan to use generic phy framework instead ? Yes, Kishon's patches look more generic than mine. Will post the next version by this week. Thanks Marc and Kishon Regards Afzal
RE: gpmc_cs_request() causes early boot hang
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.
Surely omap-gpmc needs to be setup before any calls such as gpmc_cs_request()
?
Is there a method to delay my test code, or maybe get the omap-gpmc
registered earlier ?
Hope below patch helps you (untested)
Regards
Afzal
8---
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1c53c05..a4c6912 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -827,7 +827,19 @@ static struct platform_driver gpmc_driver = {
},
};
-module_platform_driver(gpmc_driver);
+static __init int gpmc_init(void)
+{
+return platform_driver_register(gpmc_driver);
+}
+
+static __exit void gpmc_exit(void)
+{
+platform_driver_unregister(gpmc_driver);
+
+}
+
+postcore_initcall(gpmc_init);
+module_exit(gpmc_exit);
int gpmc_suspend(void)
{
8
RE: gpmc_cs_request() causes early boot hang
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 = 0x12345678;
gpmc_cs_request(0, SZ_16M, base);
printk(KERN_INFO gpmc base @ 0x%08lx\n, base);
}
... and added a call to gpmc_test() at the end of am335x_evm_init().
If I try to run this code, the kernel fails to boot, and simply hangs at:-
Uncompressing Linux... done, booting the kernel.
If I comment out the call to gpmc_cs_request(), the system boots as
expected (but without my required cs).
I've looked at the use of this call in other board files, and can't see
that their code does anything special so I'm stuck on why this simple
code fails to work.
Can anyone shed light on what I'm doing wrong ?
Do I have to initialise the gpmc beforehand in some way ?
It seems you are using PSP Kernel.
Invoking omap_init_gpmc before gpmc request should help.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v7 00/11] OMAP-GPMC: generic time calc, prepare for driver
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 that's still pending? I think Jon made some comments on the format? What I deduced finally from Jon's replies was that he wanted more documentation on generic timings, and that has been added in this series. Regards Afzal
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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
the watchdog, I ran into multiple merge conflicts with
current linux next and gave up.
OK went back to my original branch without current linux
next and with the new cbus + retu driver from Aaro applied.
Confirmed it's now working on n800 tusb6010.
Thanks for checking and confirming.
Care to repost this series updated against current linux
next?
I'm afraid I've pretty much lost track of all the patches
and rather not start resolving the conflicts as I'm sure
I'll break something else :)
You should still repost the whole updated series against
linux next.
New updated version - v7, based over linux next has been posted.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v9 3/3] ARM: OMAP2+: gpmc: minimal driver support
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'; saves us time and
frustration...
I am sorry for that, in future --strict will be part of my process
Perhaps it would be better to patch Documentation with a mention
of --strict for checkpatch
And seeing an unpleasant behavior with --strict, running
checkpatch over cached changes (for pre-commit hook) is
not making effect of --strict felt
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v9 1/3] ARM: OMAP2/3: hwmod data: add gpmc
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 correct? Yes, it is due to Kernel relying on bootloader gpmc settings Assuming it is, ideally we wouldn't merge such a patch, but I guess this is somewhat complicated now with the DT transition. So those should be marked with comments so we know this is not a hardware bug... something like the following. Thanks Regards Afzal
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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 in the expressions. Moving
completely to picoseconds resolves the issue.
Can you please try with the attached patch ?
Can you please try with patch attached in previous message
of this thread and check whether it makes n800 gpmc
peripherals work properly
Changes as in above mentioned patch has been pasted below again.
Regards
Afzal
---8
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d8e5b08..e9d57db 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -289,11 +289,11 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ps_to_ticks(time);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d: %-10s* %3d ns, %3d ticks = %d\n,
+ pr_info(GPMC CS%d: %-10s* %3d ps, %3d ticks = %d\n,
cs, name, time, ticks, 1 nr_bits);
#endif
return -1;
@@ -302,10 +302,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
mask = (1 nr_bits) - 1;
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
- printk(KERN_INFO
- GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ pr_info(GPMC CS%d: %-10s: %3d ticks, %3lu ps (was %3i ticks) %3d ps\n,
+ cs, name, ticks, gpmc_get_fclk_period() * ticks,
+ (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
@@ -385,8 +384,8 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ pr_info(GPMC CS%d CLK period is %lu ps (div %d)\n,
+ cs, div * gpmc_get_fclk_period(), div);
#endif
l = ~0x03;
l |= (div - 1);
@@ -922,46 +921,42 @@ static int gpmc_calc_sync_read_timings(struct
gpmc_timings *gpmc_t,
* indirectly necessitates requirement of t_avdp_r t_avdp_w
* instead of having a single t_avdp
*/
- temp = max_t(u32, temp, gpmc_t-clk_activation * 1000 +
- dev_t-t_avdh);
- temp = max_t(u32,
- (gpmc_t-adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_avdh);
+ temp = max_t(u32, gpmc_t-adv_on + gpmc_ticks_to_ps(1), temp);
}
- gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
/* oe_on */
temp = dev_t-t_oeasu; /* remove this ? */
if (mux) {
- temp = max_t(u32, temp,
- gpmc_t-clk_activation * 1000 + dev_t-t_ach);
- temp = max_t(u32, temp, (gpmc_t-adv_rd_off +
- gpmc_ticks_to_ns(dev_t-cyc_aavdh_oe)) * 1000);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_ach);
+ temp = max_t(u32, temp, gpmc_t-adv_rd_off +
+ gpmc_ticks_to_ps(dev_t-cyc_aavdh_oe));
}
- gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
/* any scope for improvement ?, by combining oe_on clk_activation,
* need to check whether access = clk_activation + round to sync clk ?
*/
temp = max_t(u32, dev_t-t_iaa, dev_t-cyc_iaa * gpmc_t-sync_clk);
- temp += gpmc_t-clk_activation * 1000;
+ temp += gpmc_t-clk_activation;
if (dev_t-cyc_oe)
- temp = max_t(u32, temp, (gpmc_t-oe_on +
- gpmc_ticks_to_ns(dev_t-cyc_oe)) * 1000);
- gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-oe_on +
+ gpmc_ticks_to_ps(dev_t-cyc_oe));
+ gpmc_t-access = gpmc_round_ps_to_ticks(temp);
- gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ns(1);
+ gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ps(1);
gpmc_t
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
* 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 please try with the attached patch ?
Once it is confirmed that issue is resolved, I will cleanup
gpmc-nand.c too (which would also take care of picoseconds)
Note: As this mail is sent via exchange, I am attaching the
patch so that it reaches you in proper way.
Regards
AfzalFrom 101b3d4c558bae420cbeba634f4deeae27c3b905 Mon Sep 17 00:00:00 2001
From: Afzal Mohammed af...@ti.com
Date: Wed, 12 Sep 2012 19:30:27 +0530
Subject: [PATCH] gpmc: rounding error fix
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 150 +++-
arch/arm/plat-omap/include/plat/gpmc.h | 40
2 files changed, 90 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d8e5b08..e9d57db 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -289,11 +289,11 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ps_to_ticks(time);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d: %-10s* %3d ns, %3d ticks = %d\n,
+ pr_info(GPMC CS%d: %-10s* %3d ps, %3d ticks = %d\n,
cs, name, time, ticks, 1 nr_bits);
#endif
return -1;
@@ -302,10 +302,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
mask = (1 nr_bits) - 1;
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
- printk(KERN_INFO
- GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ pr_info(GPMC CS%d: %-10s: %3d ticks, %3lu ps (was %3i ticks) %3d ps\n,
+ cs, name, ticks, gpmc_get_fclk_period() * ticks,
+ (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
@@ -385,8 +384,8 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
-cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ pr_info(GPMC CS%d CLK period is %lu ps (div %d)\n,
+cs, div * gpmc_get_fclk_period(), div);
#endif
l = ~0x03;
l |= (div - 1);
@@ -922,46 +921,42 @@ static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
* indirectly necessitates requirement of t_avdp_r t_avdp_w
* instead of having a single t_avdp
*/
- temp = max_t(u32, temp, gpmc_t-clk_activation * 1000 +
- dev_t-t_avdh);
- temp = max_t(u32,
- (gpmc_t-adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_avdh);
+ temp = max_t(u32, gpmc_t-adv_on + gpmc_ticks_to_ps(1), temp);
}
- gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
/* oe_on */
temp = dev_t-t_oeasu; /* remove this ? */
if (mux) {
- temp = max_t(u32, temp,
- gpmc_t-clk_activation * 1000 + dev_t-t_ach);
- temp = max_t(u32, temp, (gpmc_t-adv_rd_off +
-gpmc_ticks_to_ns(dev_t-cyc_aavdh_oe)) * 1000);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_ach);
+ temp = max_t(u32, temp, gpmc_t-adv_rd_off +
+gpmc_ticks_to_ps(dev_t-cyc_aavdh_oe));
}
- gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
/* any scope for improvement ?, by combining oe_on clk_activation,
* need to check whether access = clk_activation + round to sync clk ?
*/
temp = max_t(u32, dev_t-t_iaa, dev_t-cyc_iaa * gpmc_t-sync_clk);
- temp += gpmc_t-clk_activation * 1000;
+ temp += gpmc_t-clk_activation;
if (dev_t-cyc_oe)
- temp = max_t(u32, temp, (gpmc_t-oe_on +
-gpmc_ticks_to_ns(dev_t-cyc_oe)) * 1000);
- gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-oe_on +
+gpmc_ticks_to_ps(dev_t-cyc_oe));
+ gpmc_t-access = gpmc_round_ps_to_ticks(temp);
- gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ns(1);
+ gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ps(1);
gpmc_t-cs_rd_off = gpmc_t-oe_off;
/* rd_cycle */
temp = max_t(u32, dev_t-t_cez_r, dev_t-t_oez);
temp = gpmc_round_ps_to_sync_clk(temp, gpmc_t-sync_clk) +
- gpmc_t-access * 1000;
+ gpmc_t-access;
/* barter t_ce_rdyz with t_cez_r ? */
if (dev_t-t_ce_rdyz)
- temp = max_t(u32, temp,
-gpmc_t-cs_rd_off * 1000 + dev_t-t_ce_rdyz);
- gpmc_t-rd_cycle = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-cs_rd_off + dev_t-t_ce_rdyz);
+ gpmc_t-rd_cycle = gpmc_round_ps_to_ticks
RE: [PATCH v3 10/10] mtd: nand: omap2: use gpmc provided irqs
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
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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 the tusb async values is less by one. I need to get it right. And thanks for sending me the easily diff-able logs. Regards Afzal
RE: [PATCH] mtd: nand: omap2: fix error path
+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
did not propogate error code properly due to
which this fix was required.
But this has not been mentioned in commit message
as it is not yet in mainline.
Regards
Afzal
drivers/mtd/nand/omap2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 337cf0a..27293e3 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1404,6 +1404,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-gpmc_irq_count = platform_get_irq(pdev, 1);
if (info-gpmc_irq_count = 0) {
dev_err(pdev-dev, error getting count irq\n);
+ err = -ENODEV;
goto out_release_mem_region;
}
err = request_irq(info-gpmc_irq_count, omap_nand_irq,
--
1.7.0.4
RE: [PATCH v3 10/10] 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 whether you can fixup or I should post as a separate patch. Oh OK, please just post a separate patch as I've already pushed it out. I have posted a separate patch, please consider for inclusion in your tree. BTW, you original commit that fixes the compiler warning has some strange characters. Regards Afzal
RE: [PATCH v8 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD
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 jon-hun...@ti.com Thanks for your reviews, updated series has been posted Regards Afzal
RE: [PATCH v8 0/3] GPMC driver conversion
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 current GPMC timing functions using the compatible flags and auxdata in the gpmc.c driver. That way we get all the legacy boards booting with GPMC support for smsc911x etc, and can even remove some less used board-*.c files. Thanks. I agree with your suggestion and would be proceeding so as to achieve minimal devicetree support. And a newer version of this series has been posted. Then we just add the generic GPMC timings when we're happy with those. Meanwhile can you send me the gpmc debug logs for n800 where tusb patch on generic timing was causing the hang along with logs without the culprit tusb patch so that we could arrive at generic gpmc timings. Regards Afzal
RE: [PATCH v3 10/10] mtd: nand: omap2: use gpmc provided irqs
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
path even though compiler didn't complain.
Not sure whether you can fixup or I should post as a
separate patch.
As an aside, there was compiler warning before this
series, but I didn't dare to touch it, so a warning
was seen but thought it was due to the earlier one.
And now Arnd has fixed the original warning.
Regards
Afzal
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 337cf0a..27293e3 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1404,6 +1404,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-gpmc_irq_count = platform_get_irq(pdev, 1);
if (info-gpmc_irq_count = 0) {
dev_err(pdev-dev, error getting count irq\n);
+ err = -ENODEV;
goto out_release_mem_region;
}
err = request_irq(info-gpmc_irq_count, omap_nand_irq,
From: Tony Lindgren t...@atomide.com
Date: Mon, 10 Sep 2012 17:14:13 -0700
Subject: [PATCH] mtd: nand omap2: Fix uninitialized err warning
Commit bd4156fd (mtd: nand: omap2: use gpmc provided irqs)
introduced a new warning:
drivers/mtd/nand/omap2.c: In function ‘omap_nand_probe’:
drivers/mtd/nand/omap2.c:1267: warning: ‘err’ may be used uninitialized in
this function
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1389,6 +1389,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-gpmc_irq_fifo = platform_get_irq(pdev, 0);
if (info-gpmc_irq_fifo = 0) {
dev_err(pdev-dev, error getting fifo irq\n);
+ err = -ENODEV;
goto out_release_mem_region;
}
err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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 issue and has posted a solution [2]. Are you facing the same issue ?, if so, then it is not due to this series. I tried to get an n800, but has been unsuccessful. Regards Afzal [1] http://marc.info/?l=linux-omapm=134685988517580w=2 [2] http://www.spinics.net/lists/arm-kernel/msg190879.html 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 OneNAND working without 10/10. Do you have any idea, which timing could have gone wrong, can you please sent me DEBUG enabled gpmc log with and without 10/10. Can you please sent me GPMC DEBUG enabled logs with and without this series.
RE: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
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 rebased on testing-cleanup branch that I just pushed. That branch is not immutable yet though as we're waiting to hear from Arnd regrading the first patch in the branch. The patches rebased on testing-cleanup branch has been posted [1]. Regards Afzal [1] http://marc.info/?l=linux-omapm=134683495407871w=2
RE: [PATCH v7 3/3] ARM: OMAP2+: gpmc: minimal driver support
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 | GPMC_HAS_WR_DATA_MUX_BUS;
v8 of this series has been submitted leveraging gpmc capability
flag to determine whether wr_access and wr_data_mux_bus timing
fields has to be configured.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
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 this, let me know, I will post.
Yes please post the patches rebased on testing-cleanup branch that I
just pushed. That branch is not immutable yet though as we're waiting
to hear from Arnd regrading the first patch in the branch.
The patches rebased on testing-cleanup branch has been posted [1].
Latest version (v8) of patch series has been posted [A] with an
enhancement, please ignore v7.
Regards
Afzal
[A] http://marc.info/?l=linux-omapm=134684859913232w=2
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
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 we don't rely on headers included in irqs.h. While at it, sort
the includes the standard way.
arch/arm/mach-omap2/gpmc.c | 11 +---
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
/* GPMC register offsets */
#define GPMC_REVISION0x00
#define GPMC_SYSCONFIG 0x10
@@ -846,16 +849,16 @@ static int __init gpmc_init(void)
l = OMAP2420_GPMC_BASE;
else
l = OMAP34XX_GPMC_BASE;
- gpmc_irq = INT_34XX_GPMC_IRQ;
+ gpmc_irq = 20;
} else if (cpu_is_omap34xx()) {
ck = gpmc_fck;
l = OMAP34XX_GPMC_BASE;
- gpmc_irq = INT_34XX_GPMC_IRQ;
+ gpmc_irq = 20;
} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
/* Base address and irq number are same for OMAP4/5 */
ck = gpmc_ck;
l = OMAP44XX_GPMC_BASE;
- gpmc_irq = OMAP44XX_IRQ_GPMC;
+ gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
I have a suggestion to avoid above hardcoded patching on gpmc.c.
With driver conversion series it again would have to be patched.
I have made a basic gpmc driver conversion, which is expected to
be non-controversial. This was done over your devel-gpmc branch.
It is working fine, has only 3 patches
1. Add hwmod entry
2. Adapt to hwmod
3. Basic driver conversion
Here the basic driver gets resources and clk in driver probe
using con-id fck, it has no platform data as of now
It is available
@git://gitorious.org/x0148406-public/linux-kernel.git gpmc-simple-drv
Originally this was made on top of my series,
OMAP-GPMC: generic time calc, prepare for driver
It was modified so that it can be applied to your devel-gpmc branch.
*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.
As I am proceeding with Paul's suggestion on hwmod reset,
I hope Paul can take the first one.
Regards
Afzal
RE: [PATCH 6/9] ARM: OMAP: Move gpio.h to include/linux/platform_data
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 arch/arm/mach-omap2 for single zImage support. While at it, arrange the related includes in the standard way. Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-...@lists.infradead.org Cc: alsa-de...@alsa-project.org Acked-by: Tony Lindgren t...@atomide.com I think there is only one Tony ;) Regards Afzal
RE: Without MACH_ option Early printk (DEBUG_LL)
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 DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Won't having compile time selection of debug uart over machine based runtime detection help here ? 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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 tusb6010 as well as OneNAND in sync read async write mode, was OneNAND working without 10/10. Do you have any idea, which timing could have gone wrong, can you please sent me DEBUG enabled gpmc log with and without 10/10. Can you please sent me GPMC DEBUG enabled logs with and without this series. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation
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 as of now they need to have a good grasp on it. I would consider myself to be an initial user and I am concerned, doesn't that count? Yes sir, what I meant was new users who want to have runtime calculation using the generic timing routine. For the peripherals already making use of custom timing routine, I am into that role too, hence the patches 8-10. And if you have any board that makes use of existing custom timing calculation routines (OneNAND, tusb6010 or smc91x), can you please give this series a try. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
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 OneNAND working without 10/10. Do you have any idea, which timing could have gone wrong, can you please sent me DEBUG enabled gpmc log with and without 10/10. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation
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 wanted to avoid usage of cycles, but it seems it is required logically as well. This was mentioned as a note for future to find out whether at any future point of time this can be removed. +/* Device timings in picoseconds */ Why pico seconds and not nanoseconds? I understand you may need to temporarily convert to pico-secs for rounding, but when providing timing it seems nano-secs is more suitable. For more accuracy, if you see some of the tusb6010 calculation are in picoseconds, this can be true for any device although only tusb does so. If we hold on to picoseconds till the last moment, value would be more accurate. For eg. 300 ps has to be used in the case of tusb, and with ns, it can't be accounted for I am a little concerned about the above timings structure. For example, if I am adding support for a new devices it is not clear ... 1. Which are required 2. Which are applicable for async, sync, address-data multiplexed etc. 3. Exactly how these relate to the fields in the gpmc registers. Please see at the end I understand that this is based upon how timings for onenand and tusb are being calculated today, but I am not sure that this is the way to go for all devices. Personally, I would like to see us get away from how those devices are calculating timings for any new device. You cannot do away with many of the those, as logically they are right. Eg. read data should be available at access time, assuming a zero data hold time, we can very well derive an expression as, read de-assertion time (oe_off) = access time plus 1 gpmc clock, and this is what the existing calculations do, and also the generic routine. There could be other constraints, but this certainly should be one (I do realize that oe_off could be optimized to be less than access time, by relying on read hold time, then again effect of it would be in similar way for different peripherals, but let's forget about optimization in the beginning) In general, I am concerned that we are abstracting the timings further from the actual register fields. For example, the timings parameter t_ceasu is described address setup to CS valid which is not incorrect but this value is really just programming the CSONTIME field and so why not call this cs_on? Timing fields of struct gpmc_device_timings are selected such that they should be bindable by DT. At least one of the peripheral datasheet has these fields. If user knows timings in terms of gpmc values, he can directly use struct gpmc_timings, but then all the values should be updated in struct gpmc_timings. User should not update some of the values in terms of peripheral timings, others in terms of gpmc timings, that would make things complex and does not seem the right way to me. cs_on and other gpmc aware timings could be binded by DT, not as peripheral timing, but as gpmc timing. Bindings for peripheral DT timings should be something that can be obtained from peripheral datasheet, here accidentally it is same as gpmc timings, but not most timings are this way. Also there could be other constraints that can come for cs_on, even though I have not come across any till now. So although this may consolidate how the timings are calculated today, I am concerned it will be confusing to add timings for a new device. At least if I am calculating timings, I am taking the timing information for the device and translating that to the how I need to program the gpmc register fields. If I am not wrong, GPMC IP has been present for around a decade, and so far I have not come across any generic time calculation method that can be applied to all peripherals. Getting to work same peripheral for a different gpmc frequency is another problem. Here we are trying to generalize based on the understanding of gpmc peripheral timings, as well as by a kind of reverse engineering without most of the hardware or datasheet. Think of this as an attempt to create one, let it evolve and become a robust one. If a new user want to add a peripheral, let him add support, input timings are selected such that it is found in peripheral datasheet, if that does not work, let him try to add any new timing field or alter existing expression as he deems to be proper and verify that it does not break others. And I can help provided I am not heavily loaded with other works. 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 as of now they need to have a good grasp on it. Meanwhile I will try to document more. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap
RE: [PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation
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. Which values in struct gpmc_device_timings are you referring to ? Values that need to have an option to specify in cycles has been provided such an option, while not updating time based field value, you can achieve what you mentioned above. But if you want that to be handled in in generic routine, I will do so. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver
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, output - translated timings that gpmc can understand. Later, to DT'ify, gpmc peripheral timings could be passed through DT. Input timings that has been used here are selected such that it represents those that are present in peripheral timing datasheets. What I don't understand yet about this new approach is where the gpmc client code should live in. In order to probe the drivers via DT, each driver would need to call the gpmc support functions itself, right? Is By gpmc client code, if you are referring to helper functions in mach-omap2/gpmc-*, if things go as per plan, with DT, they will go away and gpmc driver would handle those based on the information from DT. No change would be needed for client drivers like smc91x ethernet drivers, but NAND driver may need some change to live with DT as it is tightly coupled with GPMC. the plan to obsolete helper functions like gpmc_nand_init() and move that functionality to the drivers? Yes, plan is to obsolete the functions like gpmc_nand_init, those tasks would be handled by gpmc driver I applied these patches locally and would like to help get the NAND controller on my AX33xx DT-driven board going. Let me know if I can do anything here. Thanks for offering the help, will take liberty to ask you for help when required. BTW, do you have any OMAP family boards ? 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 info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 00/10] OMAP-GPMC: generic time calc, prepare for driver
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 in nand driver getting probed. What I have in mind is to represent peripherals connected to gpmc as childs of gpmc node. For devices like smsc911x, as they already have DT bindings, creating an of device for childs by parsing DT hopefully should relieve task of handling their platform data. Similarly for nand, creating an of device is to be done by gpmc driver. Once the bigger issue of timing is resolved, I am planning to implement DT as said above Also for the existing boards on non-DT boot, plan is to keep the existing interface as such, with no change needed in board files. No change would be needed for client drivers like smc91x ethernet drivers, but NAND driver may need some change to live with DT as it is tightly coupled with GPMC. NAND drivers also typically parse partition entries that are children of the DT node the are owning. Yes, in addition to the above, omap nand driver would need to determine a few gpmc specific like transfer mode. I do have a beaglboard xM, but the board I'm currently working with is a custom one based on an AM33xx. I was in need of a board like rx51, n800 that currently calculate gpmc timings at runtime to test the generic timing function, np, thanks again 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 info at http://vger.kernel.org/majordomo-info.html
RE: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
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 [5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does not have a timing calculation for smsc911x) Are you able to verify that the timing calculated by this function are identical? May be some more details on exactly how you tested this would be good. Yes, it was verified. A new driver preparation series has been posted, http://marc.info/?l=linux-omapm=134554573104116w=2 that includes generic timing calculation method. The new series mentions how timing values were validated. There are a couple of timing parameters that would vary as mentioned in the above mentioned mail, but these I don't expect to create problems as this is more inline with gpmc peripheral timings. And both of the these has been verified that it would not create problem with peripheral functionality. One was tested directly (we_on related for OneNAND) and other indirectly (adv_rd(wr)_off on SMSC 9220 for SMSC 91C96). Reason for doing so was that quirks required to handle these specific cases could be avoided, otherwise new peripheral timing data would be required and it would be difficult to achieve DT bindings (when DT happens) for these kind of fixup timings. But if this causes any problems (which I don't expect), then we will have to fallback to the quirks that I wanted to avoid. Do you think that there is any value in making the tusb member a u32 dev_type and then set it too GPMC_DEVICE_TUSB then this could be used for other devices in the future too if needed? Would it be possible to create a sub-function called gpmc_calc_timings_tusb() and put all these if (tusb) statements in there? Or maybe a generic function called gpmc_calc_timings_prepare(). Usage of a tusb check was something that I really wanted to avoid as that was making generic timing calculation function peripheral Gnostic. With the newly posted series, tusb field has been removed. 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 info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL 1/5] omap device tree changes for v3.6 merge window
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 instead of the already pulled devel-dt branch. That branch should not have other dependencies as it's based on -rc5. Of course is it's buried into other DT patches it's too late. Now with -rc1 out, I'll queue the following fix. Thanks Tony 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 info at http://vger.kernel.org/majordomo-info.html
gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
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 and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
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
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_rd_off = gpmc_round_ns_to_ticks(temp / 1000);
/* oe_on */
if (mux)
temp = gpmc_t.adv_rd_off * 1000 + dev_t-adv_add_hold;
else
temp = dev_t-oe_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.adv_rd_off + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.oe_on = gpmc_round_ns_to_ticks(temp / 1000);
/* access */
temp = max_t(u32, dev_t-rd_access,
gpmc_t.oe_on * 1000 + dev_t-oe_access);
temp = max_t(u32, temp,
gpmc_t.cs_on * 1000 + dev_t-cs_access);
temp = max_t(u32, temp,
gpmc_t.adv_on * 1000 + dev_t-adv_access);
if (tusb) {
temp = max_t(u32, temp,
(gpmc_t.oe_on + gpmc_ticks_to_ns(1)) * 1000);
temp = max_t(u32, temp, gpmc_t.oe_on * 1000 + 300);
}
gpmc_t.access = gpmc_round_ns_to_ticks(temp / 1000);
gpmc_t.oe_off = gpmc_t.access + gpmc_ticks_to_ns(1);
gpmc_t.cs_rd_off = gpmc_t.oe_off;
/* rd_cycle */
temp = max_t(u32,
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
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 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Also following needs to be removed from commit message, Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. With the above diff we are in effect disabling sync mode in onenand before GPMC has been setup in the Kernel If you want, I can sent a new series too. Can you please take this series along with the above changes folded in $subject patch. I Jon concurred on this as a solution in this same thread (along with preventing hwmod reset, which is taken care in hwmod patch). Please let me know whether you prefer to have a separate series posted inclusive of the above changes. 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 info at http://vger.kernel.org/majordomo-info.html
