Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Benoit, The main motivation is that it's a driver and thus does not have anything to do inside mach-omap2. Right, I understood that. mach-omap2 is not suitable for full fledged drivers. Where will you put that otherwise? Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I prefer first one. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Yes, I remember that rule, but that's not stopping us to create a fwk, may be others will rise once they see the framework and contribute if their h/w architecture requirements are not addressed? ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 1/2] ARM: omap: hwmod: Restore sysc after a reset
On Wednesday 04 April 2012 09:11 PM, Paul Walmsley wrote:
On Tue, 13 Mar 2012, Rajendra Nayak wrote:
After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: Anand Gadiyargadi...@ti.com
Signed-off-by: Rajendra Nayakrna...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Shubhrajyoti Dshubhrajy...@ti.com
Thanks, this patch has been modified a bit to consolidate the SYSCONFIG
reload after _reset() into the _reset() function itself. This should
hopefully avoid future mistakes and avoid some code duplication. Modified
patch follows, queued for 3.4-rc.
Thanks, changes look good.
- Paul
From: Rajendra Nayakrna...@ti.com
Date: Tue, 13 Mar 2012 22:55:23 +0530
Subject: [PATCH] ARM: OMAP2+: hwmod: Restore sysc after a reset
After a softreset, make sure the sysc settings are correctly
restored.
Reported-by: Anand Gadiyargadi...@ti.com
Signed-off-by: Rajendra Nayakrna...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Shubhrajyoti Dshubhrajy...@ti.com
[p...@pwsan.com: combined post-reset SYSCONFIG reload code into the
_reset() function to avoid duplication and future mistakes]
Signed-off-by: Paul Walmsleyp...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a68010..d32c1ce 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1477,6 +1477,11 @@ static int _reset(struct omap_hwmod *oh)
ret = (oh-class-reset) ? oh-class-reset(oh) : _ocp_softreset(oh);
+ if (oh-class-sysc) {
+ _update_sysc_cache(oh);
+ _enable_sysc(oh);
+ }
+
return ret;
}
@@ -1786,20 +1791,9 @@ static int _setup(struct omap_hwmod *oh, void *data)
return 0;
}
- if (!(oh-flags HWMOD_INIT_NO_RESET)) {
+ if (!(oh-flags HWMOD_INIT_NO_RESET))
_reset(oh);
- /*
-* OCP_SYSCONFIG bits need to be reprogrammed after a softreset.
-* The _enable() function should be split to
-* avoid the rewrite of the OCP_SYSCONFIG register.
-*/
- if (oh-class-sysc) {
- _update_sysc_cache(oh);
- _enable_sysc(oh);
- }
- }
-
postsetup_state = oh-_postsetup_state;
if (postsetup_state == _HWMOD_STATE_UNKNOWN)
postsetup_state = _HWMOD_STATE_ENABLED;
--
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 05/12] Add dummy smsc911x regulators to cm-t35.
On 04/03/12 20:43, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [120327 23:37]: On 03/27/12 20:32, Russ Dill wrote: No objection. 10x Russ. I've combined patches 5 - 12 into a single patch as they pretty much do the same thing, and to cut down the patch noise for fixes. Merging into fixes with the updated patch below. 10x, looks good! -- Regards, Igor. -- 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: OMAP34xx
On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote: On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote: On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote: Hi, On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote: Okay, so this requires backlight support, and TAAL selected, so that sorts that error, but causes others: taal display0: taal panel revision e3.83.7d omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 This happens when the flex cable connected to the display is faulty or loose. Well, I don't know - it works with ES1 and an old kernel just fine. Okay, I'll look into this more. Any news on this? I see no progress on this in mainline kernels: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=112 Yet I can still boot the kernel with the originally provided kernel and CPU and it all works fine. Has anyone else tried to get the LCD panels working on the 4430SDP? -- 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: OMAP34xx
Hi, On Thursday 05 April 2012 01:54 PM, Russell King - ARM Linux wrote: On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote: On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote: On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote: Hi, On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote: Okay, so this requires backlight support, and TAAL selected, so that sorts that error, but causes others: taal display0: taal panel revision e3.83.7d omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 omapdss DSI error: DSI CIO error, cio irqstatus 20 DSI CIO IRQ 0x20: ERRCONTENTIONLP1_1 This happens when the flex cable connected to the display is faulty or loose. Well, I don't know - it works with ES1 and an old kernel just fine. Okay, I'll look into this more. Any news on this? I see no progress on this in mainline kernels: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=112 Yet I can still boot the kernel with the originally provided kernel and CPU and it all works fine. Has anyone else tried to get the LCD panels working on the 4430SDP? We figured out the culprit patch, reverting this prevents the issue: commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237 Author: Archit Taneja arc...@ti.com Date: Fri Oct 7 03:08:44 2011 -0600 ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Fix the shift and mask macros for DSIx_PPID fields in CONTROL_DSIPHY. The OMAP4430 Public TRM vV has these fields mentioned correctly. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com This was added to be in sync with the register definitions in newer OMAP4 TRMs. But it turns out that the newer TRMs might be actually messing up the register fields in question. The DSIx_PPID register fields are responsible for the pull up/down of the DSI lanes. Some SDP versions may already have enough pull up to make the panels work, and others might not. We get the contention errors on these SDP boards as we don't configure the lanes as pull up. We were trying to verify from the TRM maintainers if this was a TRM mistake, if so, reverting the patch would be the right way to go. We haven't got a response, so I'll probe the voltage of DSI lanes on a board which gives these errors so that we have enough proof. Archit -- 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: OMAP34xx
On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote: We figured out the culprit patch, reverting this prevents the issue: commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237 Author: Archit Taneja arc...@ti.com Date: Fri Oct 7 03:08:44 2011 -0600 ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Fix the shift and mask macros for DSIx_PPID fields in CONTROL_DSIPHY. The OMAP4430 Public TRM vV has these fields mentioned correctly. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com This was added to be in sync with the register definitions in newer OMAP4 TRMs. But it turns out that the newer TRMs might be actually messing up the register fields in question. Okay, I've just tried reverting this commit, and the errors have gone. However, I still see nothing on either display at boot time - not even the backlight seems to be on. Should I see anything on the displays? -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
On Wed, 4 Apr 2012, Paul Walmsley wrote: On Wed, 4 Apr 2012, Tony Lindgren wrote: Thanks, looks like two of these patches I already merged into fixes yesterday from your earlier pull request. So merging this in would cause duplicate commits. Can you please update your branch to remove those two commits? Do you happen to recall which ones they are? Anyway, am guessing that you are planning to pull these into your 'fixes' branch? If so then probably the conflicts are with the misc_devel_3.4 branch patches. Will post another pull request for you with those two patches dropped. But if you're pulling these into a different branch, please let me know... - Paul -- 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 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi! On Thu, Apr 5, 2012 at 8:53 AM, Trilok Soni ts...@codeaurora.org wrote: Hi Benoit, The main motivation is that it's a driver and thus does not have anything to do inside mach-omap2. Right, I understood that. mach-omap2 is not suitable for full fledged drivers. The initial motivation is to provide a generic framework for this type of drivers, by cleaning up the current OMAP code and by providing as much generic code as possible. Cf. the patch sets I submitted before this very one: - the SR code clean-up [1], which is needed to make the code ready for the integration of new features, - the SR class support [2], which is needed for new SR classes to be implemented. From the maintainer point of view it made more sense to move the code before cleaning it up and so it should happen before [1] and [2]. The result is that [1] and [2] will need to be rebased when the move is accepted and merged in. [1] http://marc.info/?l=linux-omapm=133055488908132w=2 [2] http://marc.info/?l=linux-omapm=133163445926544w=2 Where will you put that otherwise? Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I prefer first one. Those paths are for OMAP specific code and not for a generic framework. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. Also I am sure that other vendors could step in and have their platform specific code converted to the new fwk as well. Yes, I remember that rule, but that's not stopping us to create a fwk, may be others will rise once they see the framework and contribute if their h/w architecture requirements are not addressed? Thanks, Jean ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: OMAP34xx
On Thursday 05 April 2012 02:19 PM, Russell King - ARM Linux wrote: On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote: We figured out the culprit patch, reverting this prevents the issue: commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237 Author: Archit Tanejaarc...@ti.com Date: Fri Oct 7 03:08:44 2011 -0600 ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Fix the shift and mask macros for DSIx_PPID fields in CONTROL_DSIPHY. The OMAP4430 Public TRM vV has these fields mentioned correctly. Signed-off-by: Archit Tanejaarc...@ti.com Acked-by: Benoit Coussonb-cous...@ti.com Acked-by: Santosh Shilimkarsantosh.shilim...@ti.com Signed-off-by: Paul Walmsleyp...@pwsan.com This was added to be in sync with the register definitions in newer OMAP4 TRMs. But it turns out that the newer TRMs might be actually messing up the register fields in question. Okay, I've just tried reverting this commit, and the errors have gone. However, I still see nothing on either display at boot time - not even the backlight seems to be on. Should I see anything on the displays? Backlight support isn't there yet because the TWL soultion to use it is hacky. However, you should be able to see penguins if you have built-in DSS2 in the kernel and enabled the following configs: CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y Tomi, Benoit, I tried to probe the DSI1 lines on a board which we get the errors. The register fields DSI1_PPID and DSI2_PPID are definitely swapped in the newer OMAP TRMs. I get around 950mV on DSI1's D1+ lane, and if I set the corresponding D1+ bit in the DSI2_PPID, the voltage becomes 1.28V, the DSI spec says that we need 1.2V when opearting in DSI LP mode. I'll post a patch which reverts this commit. Archit -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
Hi Paul, I think you have missed out to queue my patch. Could you please include the same. Best Regards, Gowda -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Paul Walmsley Sent: 05 April 2012 02:00 To: t...@atomide.com Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [GIT PULL] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-fixes-a-for-3.4rc for you to fetch changes up to cf1a9298231d7719b67ad0eae6236c91888b7a32: Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_3.4rc', 'powerdomain_fixes_a_3.4rc' and 'prcm_fixes_3.4rc' into fixes_for_3.4rc2 (2012-04-04 14:53:33 -0600) These changes have been boot-tested on OMAP37xx ES1.0 Beagleboard-XM, OMAP2420 N800, OMAP4430 ES2.0 Pandaboard, and OMAP35xx ES3.0 BeagleBoard. System suspend and serial wakeup has been tested on OMAP4430 ES2.0 Pandaboard, and dynamic retention idle and serial wakeup has been tested on OMAP35xx ES3.0 BeagleBoard. - OMAP clock, powerdomain, clockdomain, hwmod, and PRCM fixes intended for the early v3.4-rc series. Also contains an HSMMC integration refinement of an earlier hardware bug workaround. ARM: OMAP3: clock data: fill in some missing clockdomains ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() ARM: OMAP: hwmod: Use sysc_fields-srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK ARM: OMAP4: prm: fix interrupt register offsets ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP: clock: fix race in disable all clocks ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data - Ameya Palande (1): ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL Govindraj.R (1): ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules Grazvydas Ignotas (2): ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks Ilya Yanok (1): ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases Nishanth Menon (1): ARM: OMAP: clock: fix race in disable all clocks Paul Walmsley (4): ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP3: clock data: fill in some missing clockdomains Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_3.4rc', 'powerdomain_fixes_a_3.4rc' and 'prcm_fixes_3.4rc' into fixes_for_3.4rc2 Rajendra Nayak (4): ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status ARM: OMAP: hwmod: Use sysc_fields-srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock Santosh Shilimkar (1): ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() Tero Kristo (1): ARM: OMAP4: prm: fix interrupt register offsets Vaibhav Hiremath (1): ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions arch/arm/mach-omap2/clock3xxx_data.c | 18 +++-- arch/arm/mach-omap2/clock44xx_data.c |5 +- arch/arm/mach-omap2/clockdomains44xx_data.c |2 +- arch/arm/mach-omap2/hsmmc.c |7 ++ arch/arm/mach-omap2/omap_hwmod.c | 96 -- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 arch/arm/mach-omap2/powerdomain.c|8 ++- arch/arm/mach-omap2/prm44xx.c| 21 +++--- arch/arm/plat-omap/clock.c |5 +- arch/arm/plat-omap/include/plat/omap_hwmod.h | 12 ++-- 10 files changed,
RE: [GIT PULL] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
On Thu, 5 Apr 2012, madhusudhan.go...@elektrobit.com wrote: Hi Paul, I think you have missed out to queue my patch. Could you please include the same. I thought you were going to fix the patch description. Could you please do that and repost it? - Paul -- 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 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Jean, The initial motivation is to provide a generic framework for this type of drivers, by cleaning up the current OMAP code and by providing as much generic code as possible. Cf. the patch sets I submitted before this very one: - the SR code clean-up [1], which is needed to make the code ready for the integration of new features, - the SR class support [2], which is needed for new SR classes to be implemented. From the maintainer point of view it made more sense to move the code before cleaning it up and so it should happen before [1] and [2]. The result is that [1] and [2] will need to be rebased when the move is accepted and merged in. [1] http://marc.info/?l=linux-omapm=133055488908132w=2 [2] http://marc.info/?l=linux-omapm=133163445926544w=2 I am going through your patches and including some wiki pages. I understand the SR can be connected in two ways - intelligent and dumb :) For intelligent I mean you just configure SR and it will and program PMIC, whereas in dumb scenarios application processor gets the notification and then it goes and writes into PMIC based on some floor/ceiling values. In the first case not much of apps. s/w but in the later case whole lot. Where will you put that otherwise? Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I prefer first one. Those paths are for OMAP specific code and not for a generic framework. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. I don't understand much of these versions right now, but hopefully after going through all these docs. My only contention point is to not create any directory into the drivers/power, unless it is generic fwk and then build up client drivers on top of it. Meanwhile we could move this driver into above options as I have suggested. ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Apr 04, 2012 at 16:09:51, Hiremath, Vaibhav wrote:
On Wed, Apr 04, 2012 at 14:34:09, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 9:05 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Tue, Apr 03, 2012 at 00:05:38, Hilman, Kevin wrote:
Shilimkar, Santosh santosh.shilim...@ti.com writes:
[...]
I don't personally like to add features which hardly anybody use and
fundamentally broken with full kernel.
Let's keep sane defaults, but not make it unreasonable to tweak eaither.
I suggest what has already been mentioned.
Register both timers, but have the sync timer have a higher rating. On
AMxxx where there is no sync timer, GPtimer will be used.
This is another good option, I can change the rating of both the timers.
With below description and given understanding/discussion/usability of
both
the timers, we can reverse the rating,
Btw, if we are going with this path, then there won't any need of
commandline
option since clock-source can be switched from user space as well.
Yes, both the options will be open now and its upto user how he want to
choose it (either bootargs or sysfs).
Santosh, Kevin and others (may be Russell can comment/conform),
Unfortunately, I am still struggling to get final patch out of this
discussion,
Although now we concluded on changing the rates for 32ksync (rating = 300)
and gptmier (rating = 250), and we thought kernel will choose better
clocksource automatically, in default case it would be 32ksync_counter, and
that is what we want; and user can use bootargs to override the clocksource
to gptimer.
But we all missed on setup_sched_clock(), which is dependent on clock
Frequency, and based on that whole sched_clock() function works.
In case of 32ksync_counter:
--
cd.mult - 40, cd.shift - 17
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
In case of gptimer:
--
cd.mult - 2581110154, cd.shift - 26
sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
Also, in addition to this,
- We do not have any API available in sched_clock code to update the
mult/shift factors.
- You supposed to not call setup_sched_clock() multiple times, it dumps
whole stack with,
WARN_ON(read_sched_clock != jiffy_sched_clock_read);
- In case, user pass clocksource=gp timer in bootargs, still initially
Kernel is going to use 32ksync_counter as a clocksource and the late in
the boot sequence it will switch to gptimer.
[0.637512] Switching to clocksource gp timer
There seems to be limitation for ARM architecture, it is restricted by
sched_clock implementation present in arch/arm/kernel/sched_clock.c.
Natively, clocksource framework does support change in rate/frequency for
registered timer, using,
- __clocksource_updatefreq_scale()
- __clocksource_updatefreq_hz()
- __clocksource_updatefreq_khz()
May be I am missing something here, so far this is what my understanding is,
I am still digging through the code to understand how best we can handle
this. And also, I wouldn't want to again create our own sched_clock
interface.
May be Russell can help me to conform my understanding here.
Coming back to our actual problem of registering 2 clocksources, with all
above things, I am slowly moving towards keeping CONFIG_OMAP_32K_TIMER
config option and use compile time option for this (original approach) along
with hwmod detection, so that it can be reused for devices like AM33xx.
Code implementation will be,
#ifdef CONFIG_OMAP_32K_TIMER
oh = omap_hwmod_lookup(oh_name);
if (oh oh-slaves_cnt != 0) {
u32 pbase;
unsigned long size;
struct resource mem_rsrc;
res = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM,
NULL, mem_rsrc);
if (!res) {
pbase = mem_rsrc.start + 0x10;
size = mem_rsrc.end - mem_rsrc.start;
res = omap_init_clocksource_32k(pbase, size);
if (!res)
return;
}
}
#endif
/* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
__omap_dm_timer_load_start(clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
else
pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
gptimer_id, clksrc.rate);
Thanks,
Vaibhav
--
To unsubscribe from this list: send
RE: [GIT PULL] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
Thanks Paul for the quick reply. Ok I will repost it. Best Regards Gowda -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Paul Walmsley Sent: 05 April 2012 12:19 To: Gowda Madhusudhan Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [GIT PULL] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc On Thu, 5 Apr 2012, madhusudhan.go...@elektrobit.com wrote: Hi Paul, I think you have missed out to queue my patch. Could you please include the same. I thought you were going to fix the patch description. Could you please do that and repost it? - Paul ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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
[GIT PULL] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc (misc_devel_3.4 patches dropped)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-fixes-a2-for-3.4rc for you to fetch changes up to a9dd31b744a033b4324c93cec4ecb4c74061e2cf: Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_a2_3.4rc' and 'powerdomain_fixes_a_3.4rc' into omap-fixes-a2-for-3.4rc-branch (2012-04-05 03:00:22 -0600) This version is intended to merge cleanly into your 'fixes' branch. - OMAP clock, powerdomain, clockdomain, and hwmod fixes intended for the early v3.4-rc series. Also contains an HSMMC integration refinement of an earlier hardware bug workaround. ARM: OMAP3: clock data: fill in some missing clockdomains ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP: clock: fix race in disable all clocks ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data - Ameya Palande (1): ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL Govindraj.R (1): ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules Grazvydas Ignotas (2): ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks Ilya Yanok (1): ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases Nishanth Menon (1): ARM: OMAP: clock: fix race in disable all clocks Paul Walmsley (4): ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP3: clock data: fill in some missing clockdomains Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_a2_3.4rc' and 'powerdomain_fixes_a_3.4rc' into omap-fixes-a2-for-3.4rc-branch Rajendra Nayak (3): ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status Santosh Shilimkar (1): ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() Vaibhav Hiremath (1): ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions arch/arm/mach-omap2/clock3xxx_data.c | 18 -- arch/arm/mach-omap2/clock44xx_data.c |5 +- arch/arm/mach-omap2/clockdomains44xx_data.c |2 +- arch/arm/mach-omap2/hsmmc.c |7 ++ arch/arm/mach-omap2/omap_hwmod.c | 88 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 arch/arm/mach-omap2/powerdomain.c|8 ++- arch/arm/plat-omap/clock.c |5 +- arch/arm/plat-omap/include/plat/omap_hwmod.h | 12 ++-- 9 files changed, 105 insertions(+), 68 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPfWgsAAoJEMePsQ0LvSpLAQMP/082AoPpGNAO/wCz4RSvr7AS 0RX2mqsVaLf++lvtlyooKb0oosUyXkPoE6hMt4t/3QwQ9B/NW3LdcGCJIO07OUcK 767L7Dw19UOBZ6rDoESpqOplBC2jNwRlL5JzXz4Jera/vTws+uQ7M8Bb+LxjJRcV R675NCzgJQn0yiSesK9GWAF1QAT8JFpzmJekJ/A9+twT31yQg/vJjkitZjtUW2eJ /j8I0qVKS/NdxIf4I/Rt/rTWn6h1JXyMgq79q5IfqTAq/I4n9Vo1MQuzWEB58IeR uN7/vvZChLXLmwN/0pE1/QyZ28AARvOsq2iP+VZPXwpbSw05u+pKLwi74aYw13+C wdBqwGlJHYIlGQ5k/aJAllITKMv2QLA1o4DEarGiVnTNULL9fT+Os0uPWpckS31E ca+S70tGL/YO5C7uyjm3lqEy2uTe5pe4W4/qyeR9VD1Zvb+MBnPQbJ6ZbCSMmEF9 RoSNHS5EouZVu+xxrYtqH02kUGlS7uhlUKCZBajasY8P9OrhFh57vZNuYmCdRwRG RjOk2VRDdrn7/egHlNfsguQUz6YPPDq6XZPfprZlFnUTJspzKC24pc6DJSSwBgyx VsLaJMHy1greZFXtvHY5ltr3DHyCqzAoTQ9/bmkJkQybqfMUsB51dmQKVNBhLFXm etfYMqw0KAGroKb+uNHP =qH6Y -END PGP SIGNATURE- -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote: There seems to be limitation for ARM architecture, it is restricted by sched_clock implementation present in arch/arm/kernel/sched_clock.c. Natively, clocksource framework does support change in rate/frequency for registered timer, using, Any kind of switching of timing sources introduces loss of time issues by the mere fact that you can't instantly know the counter values of both timing sources at precisely the same instant - because CPUs can only do one thing at a time. So any kind of repeated dynamic switching _will_ result in a gradual loss of time - which will be indeterminant as it depends on the frequency of the switching and the relative delta between the two. To put it another way - it is not possible to maintain high precision and accuracy while dynamically switching your timing sources. I'm not about to lift the restriction that there's only one source for sched_clock() just for OMAP. That'd require a lot of additional code - it's not just about adjusting the multiplier and shift, you also have to correct the returned ns value as well, which means synchronizing against two counters. (And as I've pointed out above, that's impossible to do accurately.) -- 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: OMAP3EVM not booting on l-o master
On Thu, 5 Apr 2012, Paul Walmsley wrote: I just rebased this series on top of v3.4-rc1 and built each patch in it successfully, so it sounds like there's some bisection-specific build problem? Okay, a quick update. Just tried with a different .config, and can reproduce the following build problem with patch 2 of the IO wakeup series, in code that is later removed by patch 6: arch/arm/mach-omap2/pm34xx.c: In function 'omap_sram_idle': arch/arm/mach-omap2/pm34xx.c:281:4: error: implicit declaration of function 'omap3_reconfigure_io_chain' That's my mistake and I will correct it here and send a new pull request, once we figure out what's going on with your boot hang. As far as the crashes go, I don't think I have an OMAP3EVM, but I'll take a look here on the OMAP35xx boards that I do have. I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? - Paul Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc1-6-g297624c (paul@dusk) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #404 SMP T2 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0e53000 s11456 r8192 d13120 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 mem=256M rootwait earlyprintk [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 246220k/246220k available, 15924k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc0619ee8 (6216 kB) [0.00] .init : 0xc061a000 - 0xc0667cc0 ( 312 kB) [0.00] .data : 0xc0668000 - 0xc06f9c98 ( 584 kB) [0.00].bss : 0xc06f9cbc - 0xc0c4df60 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001129] Calibrating delay loop... 471.61 BogoMIPS (lpj=1843200) [0.081909] pid_max: default: 32768 minimum: 301 [0.082916] Security Framework initialized [0.083282] Mount-cache hash table entries: 512 [0.089874] CPU: Testing write buffer coherency: ok [0.091033] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.091186] Setting up static identity map for 0x80472300 - 0x80472370 [0.093597] Brought up 1 CPUs [0.093627] SMP: Total of 1 processors activated (471.61 BogoMIPS). [0.110290] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. [0.120819] dummy: [0.123565] NET: Registered protocol family 16 [0.125244] GPMC revision 5.0 [0.139343] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.140014] OMAP GPIO hardware version 2.5 [0.141448] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [0.143920] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [0.145812] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [0.147735] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [
RE: OMAP3EVM not booting on l-o master
Hi Paul, On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, Regards Afzal Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc1-11705-g33fc21e (af...@linux-psp-server.india.ext.ti.com) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #5 SMP Thu Apr 5 15:19:27 IST 2012 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32512 [0.00] free_area_init_node: node 0, pgdat c06b3cc0, node_mem_map c0c0a000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32256 pages, LIFO batch:7 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0d0e000 s11456 r8192 d13120 u32768 [0.00] pcpu-alloc: s11456 r8192 d13120 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO0,115200n8 root/dev/ram rw earlyprintk mem=128M initrd=0x81338000,0x1f6c2f initcall_debug debug [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 127MB = 127MB total [0.00] Memory: 114536k/114536k available, 16536k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05d2e34 (5932 kB) [0.00] .init : 0xc05d3000 - 0xc0621cc0 ( 316 kB) [0.00] .data : 0xc0622000 - 0xc06b5958 ( 591 kB) [0.00].bss : 0xc06b597c - 0xc0c09be0 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001129] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504) [0.085906] pid_max: default: 32768 minimum: 301 [0.086883] Security Framework initialized [0.087219] Mount-cache hash table entries: 512 [0.093780] CPU: Testing write buffer coherency: ok [0.094970] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.095001] calling init_static_idmap+0x0/0xe0 @ 1 [0.095123] Setting up static identity map for 0x804278b8 - 0x80427928 [0.095153] initcall init_static_idmap+0x0/0xe0 returned 0 after 0 usecs [0.095184] calling omap4_sar_ram_init+0x0/0x60 @ 1 [0.095214] initcall omap4_sar_ram_init+0x0/0x60 returned -12 after 0 usecs [0.095245] initcall omap4_sar_ram_init+0x0/0x60 returned with error code -12 [0.095275] calling omap_l2_cache_init+0x0/0xec @ 1 [0.095306] initcall omap_l2_cache_init+0x0/0xec returned -19 after 0 usecs [0.095336] calling spawn_ksoftirqd+0x0/0x54 @ 1 [0.095825] initcall spawn_ksoftirqd+0x0/0x54 returned 0 after 0 usecs [0.095855] calling init_workqueues+0x0/0x3c8 @ 1 [0.097015] initcall init_workqueues+0x0/0x3c8 returned 0 after 0 usecs [0.097045] calling migration_init+0x0/0x78 @ 1 [0.097106] initcall migration_init+0x0/0x78 returned 0 after 0 usecs [0.097137] calling cpu_stop_init+0x0/0xd8 @ 1 [0.097473] initcall cpu_stop_init+0x0/0xd8 returned 0 after 0 usecs [0.097503] calling rcu_scheduler_really_started+0x0/0x18 @ 1 [0.097534] initcall
RE: OMAP3EVM not booting on l-o master
cc Tony Hi, On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, thanks. ... [6.065307] calling omap_mux_late_init+0x0/0x1a0 @ 1 Looks like a mux-related problem. Tony recently found some mux-related bugs that got merged with the v3.3 mach-omap2/serial.c - I wonder if they might be affecting your board too? - Paul -- 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: OMAP3EVM not booting on l-o master
Hi Afzal, On Thu, Apr 5, 2012 at 3:47 PM, Paul Walmsley p...@pwsan.com wrote: cc Tony Hi, On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, thanks. ... [ 6.065307] calling omap_mux_late_init+0x0/0x1a0 @ 1 Looks like a mux-related problem. Tony recently found some mux-related bugs that got merged with the v3.3 mach-omap2/serial.c - I wonder if they might be affecting your board too? Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. -- Thanks, Govindraj.R [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65347.html -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote: There seems to be limitation for ARM architecture, it is restricted by sched_clock implementation present in arch/arm/kernel/sched_clock.c. Natively, clocksource framework does support change in rate/frequency for registered timer, using, Any kind of switching of timing sources introduces loss of time issues by the mere fact that you can't instantly know the counter values of both timing sources at precisely the same instant - because CPUs can only do one thing at a time. So any kind of repeated dynamic switching _will_ result in a gradual loss of time - which will be indeterminant as it depends on the frequency of the switching and the relative delta between the two. To put it another way - it is not possible to maintain high precision and accuracy while dynamically switching your timing sources. I'm not about to lift the restriction that there's only one source for sched_clock() just for OMAP. That'd require a lot of additional code - it's not just about adjusting the multiplier and shift, you also have to correct the returned ns value as well, which means synchronizing against two counters. (And as I've pointed out above, that's impossible to do accurately.) Thanks a ton Russell for confirming on this, I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. So this means, we have to use compile time option, as existing implementation in arch/arm/mach-omap2/timer.c. Thanks again, I will repost patches shortly with the code changes (mentioned in my last email) Thanks, Vaibhav -- 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: OMAP3: clock: fix DPLL4 CLKSEL masks
On Wed, Apr 4, 2012 at 5:40 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 26 Mar 2012, Grazvydas Ignotas wrote: Commit 2a9f5a4d455 OMAP3 clock: remove unnecessary duplicate of dpll4_m2_ck, added for 36xx consolidated dpll4 clock structures between 34xx and 36xx, but left 34xx CLKSEL masks for most dpll4 related clocks, which causes clock code to not behave correctly when booting on DM3730 with higher (36xx only) divisors set: [ 0.00] WARNING: at arch/arm/mach-omap2/clkt_clksel.c:375 omap2_init_clksel_parent+0x104/0x114() [ 0.00] clock: dpll4_m3_ck: init parent: could not find regval 0 [ 0.00] WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 omap2_clksel_recalc+0xd4/0xe4() [ 0.00] clock: Could not find fieldval 0 for clock dpll4_m3_ck parent dpll4_ck Fix this by switching to 36xx masks, as valid divisors will be limited by clksel_rate lists. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Grazvydas Ignotas nota...@gmail.com Thanks, queued for 3.4-rc. (Looks like the lakml cc was accidentally dropped, so I went ahead and did that, but maybe you could do that for me next time :-) ) I think I simply forgot it, thanks! -- Gražvydas -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Thursday 05 April 2012 04:01 PM, Hiremath, Vaibhav wrote: On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote: There seems to be limitation for ARM architecture, it is restricted by sched_clock implementation present in arch/arm/kernel/sched_clock.c. Natively, clocksource framework does support change in rate/frequency for registered timer, using, Any kind of switching of timing sources introduces loss of time issues by the mere fact that you can't instantly know the counter values of both timing sources at precisely the same instant - because CPUs can only do one thing at a time. So any kind of repeated dynamic switching _will_ result in a gradual loss of time - which will be indeterminant as it depends on the frequency of the switching and the relative delta between the two. To put it another way - it is not possible to maintain high precision and accuracy while dynamically switching your timing sources. I'm not about to lift the restriction that there's only one source for sched_clock() just for OMAP. That'd require a lot of additional code - it's not just about adjusting the multiplier and shift, you also have to correct the returned ns value as well, which means synchronizing against two counters. (And as I've pointed out above, that's impossible to do accurately.) Thanks a ton Russell for confirming on this, I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. So this means, we have to use compile time option, as existing implementation in arch/arm/mach-omap2/timer.c. Thanks again, I will repost patches shortly with the code changes (mentioned in my last email) I suggest you wait for Kevin and Tony to look at it. Am still going back to what I proposed initially. Why not the conditional way as shown in the patch [1] I proposed or your initial patch with some updates? Something like this. if(commandline.clksource == gpt) omap2_gptimer_clocksource_init(gptimer_id, fck_source); else if (omap_init_clocksource_32k()) omap2_gptimer_clocksource_init(gptimer_id, fck_source); This won't need compile time option and gives you all everybody wants. 1. Ability to use gpt as a clock-source for perf like stuff 2. Hardware like AMXX where 32K synctimer doesn't exist which means omap_init_clocksource_32k() will fail and use gptimer. 3. For OMAP, it will continue to use 32K sync timer. What am I missing Vaibhav? Regards Santosh -- 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 v3] OMAP2+: UART: Remove cpu checks for populating errata flags
Hi Govind,
On Tuesday 03 April 2012 07:12 PM, Govindraj.R wrote:
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Jon Hunter jon-hun...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 74
-
3 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..6affdd4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
34xx is true for 3630 also thanks for fixing the unneeded oring.
:-)
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata = omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 0121486..0555c96 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define UART_BUILD_REVISION(x, y)(((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
Maybe a comment can be added or the #define changed to reflect
the processor also so that it is easy to map.
A dev_info print could be added so that the bootup logs(probe) could
tell what ip rev is booted is running.
Feel free to ignore such trivial comments.
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -53,6 +60,17 @@
#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK (0x3 6)
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK0x0f
+
+#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT 8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1346,6 +1364,59 @@ static void uart_tx_dma_callback(int lch, u16
ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr OMAP_UART_MVR_SCHEME_SHIFT;
+
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
+ major = (mvr OMAP_UART_LEGACY_MVR_MAJ_MASK)
+ OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
+ minor = (mvr OMAP_UART_LEGACY_MVR_MIN_MASK);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr OMAP_UART_MVR_MAJ_MASK)
+ OMAP_UART_MVR_MAJ_SHIFT;
+ minor = (mvr OMAP_UART_MVR_MIN_MASK);
+ break;
+ default:
+
Re: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Wed, Mar 21, 2012 at 3:54 PM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) Alan / Greg, With you ack on tty parts can this series be upstreamed from omap tree ? Tony, Can you take these series into your uart fixes branch for 3.4-rc (Let me know if you need a pull request with patches based on linux-omap tree uart branch) -- Thanks, Govindraj.R -- 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 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Thu, 5 Apr 2012 16:54:03 +0530 Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, Mar 21, 2012 at 3:54 PM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) Alan / Greg, With you ack on tty parts can this series be upstreamed from omap tree ? Fine by me - this seems primarily to be architectural details. -- 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 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Mon, Apr 02, 2012 at 12:26:11, Shilimkar, Santosh wrote:
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
Thanks for the change log update Vaibhav.
Some more comments.
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86
-
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index a2e6d07..3f96a00 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -72,6 +72,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc410
Shouldn't you just update OMAP1_32K_TIMER_BASE ?
No, they are different. First one is normal timer base address
and next one is 32k-sync timer base address.
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -185,7 +186,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
If pbase is NULL, you might not want to call the init.
First check we do in _init function is, check for NULL, so you
can ignore it.
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5c9acea..f35db1a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+* First check for availability for 32k-sync timer.
+*
+* In case of failure in finding 32k_counter module or
+* registering it as clocksource, execution will fallback to
+* gp-timer.
+*/
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
Don't hardcode the offset here. This is error prone when the IP
changes so use the register define.
Ok, I will define macro for this and use it.
Thanks,
Vaibhav
--
To unsubscribe from this
[PATCH] staging: drm/omap: move where DMM driver is registered
From: Rob Clark r...@ti.com
Not sure what triggered the change in behavior, but seems to
result in recursively acquiring a mutex and hanging on boot. But
omap_drm_init() seems a much more sane place to register the
driver for the DMM sub-device.
---
drivers/staging/omapdrm/omap_drv.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 3df5b4c..620b8d5 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -803,9 +803,6 @@ static void pdev_shutdown(struct platform_device *device)
static int pdev_probe(struct platform_device *device)
{
DBG(%s, device-name);
- if (platform_driver_register(omap_dmm_driver))
- dev_err(device-dev, DMM registration failed\n);
-
return drm_platform_init(omap_drm_driver, device);
}
@@ -833,6 +830,10 @@ struct platform_driver pdev = {
static int __init omap_drm_init(void)
{
DBG(init);
+ if (platform_driver_register(omap_dmm_driver)) {
+ /* we can continue on without DMM.. so not fatal */
+ dev_err(NULL, DMM registration failed\n);
+ }
return platform_driver_register(pdev);
}
--
1.7.9.1
--
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
[PATCH v3 0/9] Convert OMAP GPMC to driver
Hi, GPMC driver conversion series. NAND and smsc911x ethernet device has been adapted to use GPMC driver. Patches has been generated over linux-omap/master, HEAD 33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending branches As OMAP3EVM does not boot linux-omap/master, merge commit, 58adb29 Merge branch 'io_chain_devel_3.4' of git://git.pwsan.com/linux-2.6 into prm has to be reverted to get OMAP3EVM boot. Last patch (with subject prefix TMP - 9/9) is for testing. Once driver is acceptable, platform code for other peripherals connected via GPMC would be adapted to make use of GPMC driver. And then the board modifications. But before that HWMOD entry has to be populated for respective SoC(s ?). Now DESTINATION FOR THIS DRIVER has to be decided. Original plan was to consider GPMC as MFD. The peripheral(s) connected to GPMC being considered childs of MFD. GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC has to be configured as required by timings of the connected peripheral. It needs to be configured only initially (only exception being resume afaik, where it needs to be reconfigured). Handling GPMC cannot be left to platform code to handle, then where can it be ? (currently it is handled by platform code). Once it is configured it can be used to handle different protocols like NAND, NOR. Various kinds of devices like ethernet, uart, usb, fpga etc can work using GPMC interface. GPMC has a seperate additional functionality of NAND handling (not manhandling ;) ). But with this series, dealing NAND block of GPMC has been separated from GPMC driver and given to NAND driver. It seems decision on where a driver should go is based more on functionality. Any suggestions on where GPMC driver could go would be very helpful. This would also help in reducing amount of platform code for OMAP. Various options that could be seen so far on where this driver can go, 1. mfd 2. misc 3. drivers/platform/arm/ (create an new one?) 4. memory (create a new one ?) If GPMC sounds similar to something else that is present in other chips, please be kind enough to let me know how this is handled by Kernel (if). GPMC details can be referred in AM335X Technical Reference Manual @ http://www.ti.com/lit/pdf/spruh73 Regards Afzal v3: Single device structure passed from platform for peripherals using multiple CS instead of using multiple device structure having a few redundant data, handle interrupts, GPMC NAND handling by GPMC NAND driver instead of GPMC driver v2: Avoid code movement that kept similar code together (for easy review) TODO: 1. Decide on destination of GPMC driver 2. Modify platform code so that remaining peripherals can be configured using GPMC driver instead of platform code doing so. 3. Remove static struct gpmc * (could be done once all other peripherals are adapted to use GPMC driver) 4. Devise method to handle OneNAND for GPMC cleanly 5. Handle acquiring CS# (if required) 6. Adapt to HWMOD, use RPM 7. Cleanup (once all peripherals make use of GPMC driver all the exported symbols can be removed, and complete removal of a few of these functions would be possible, like gpmc_nand_* can be deleted now itself) Afzal Mohammed (9): ARM: OMAP2+: gpmc: driver conversion ARM: OMAP2+: gpmc: registers for nand driver ARM: OMAP2+: nand: create platform data structure ARM: OMAP2+: gpmc-nand: populate gpmc configs ARM: OMAP2+: gpmc-smsc911x: gpmc driver information mtd: nand: omap2: obtain memory from resource mtd: nand: omap2: use gpmc provided irqs mtd: nand: omap2: handle nand on gpmc OMAP3EVM: Test gpmc-nand arch/arm/mach-omap2/board-devkit8000.c |6 +- arch/arm/mach-omap2/board-flash.c | 63 +-- arch/arm/mach-omap2/board-flash.h | 13 +- arch/arm/mach-omap2/board-ldp.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c |6 +- arch/arm/mach-omap2/board-omap3evm.c| 95 +++- arch/arm/mach-omap2/board-omap3touchbook.c |6 +- arch/arm/mach-omap2/board-overo.c |5 +- arch/arm/mach-omap2/board-zoom.c|5 +- arch/arm/mach-omap2/common-board-devices.c | 46 -- arch/arm/mach-omap2/common-board-devices.h |1 - arch/arm/mach-omap2/gpmc-nand.c | 97 ++-- arch/arm/mach-omap2/gpmc-smsc911x.c | 59 +-- arch/arm/mach-omap2/gpmc.c | 543 +++ arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |9 +- arch/arm/plat-omap/include/plat/gpmc.h | 66 ++- arch/arm/plat-omap/include/plat/nand.h | 10 +- drivers/mtd/nand/omap2.c|
[PATCH v3 2/9] ARM: OMAP2+: gpmc: registers for nand driver
If peripheral connected is NAND, update NAND drivers platform data
with NAND related register addresses so that NAND driver can handle
GPMC NAND operations by itself
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 25 +
arch/arm/plat-omap/include/plat/gpmc.h | 16
arch/arm/plat-omap/include/plat/nand.h |1 +
3 files changed, 42 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index cf5d8f3..ca7fa83 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -30,6 +30,7 @@
#include asm/mach-types.h
#include plat/gpmc.h
+#include plat/nand.h
#include plat/sdrc.h
@@ -766,6 +767,28 @@ static int __init gpmc_init(void)
}
postcore_initcall(gpmc_init);
+static __devinit void gpmc_update_nand_reg(struct gpmc *gpmc,
+ struct omap_nand_platform_data *nand)
+{
+ int cs = nand-cs;
+
+ nand-reg.gpmc_status = gpmc-io_base + GPMC_STATUS;
+ nand-reg.gpmc_nand_command = gpmc-io_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
+ nand-reg.gpmc_nand_address = gpmc-io_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
+ nand-reg.gpmc_nand_data = gpmc-io_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
+ nand-reg.gpmc_prefetch_config1 = gpmc-io_base + GPMC_PREFETCH_CONFIG1;
+ nand-reg.gpmc_prefetch_config2 = gpmc-io_base + GPMC_PREFETCH_CONFIG2;
+ nand-reg.gpmc_prefetch_control = gpmc-io_base + GPMC_PREFETCH_CONTROL;
+ nand-reg.gpmc_prefetch_status = gpmc-io_base + GPMC_PREFETCH_STATUS;
+ nand-reg.gpmc_ecc_config = gpmc-io_base + GPMC_ECC_CONFIG;
+ nand-reg.gpmc_ecc_control = gpmc-io_base + GPMC_ECC_CONTROL;
+ nand-reg.gpmc_ecc_size_config = gpmc-io_base + GPMC_ECC_SIZE_CONFIG;
+ nand-reg.gpmc_ecc1_result = gpmc-io_base + GPMC_ECC1_RESULT;
+}
+
static __devinit struct resource gpmc_setup_cs_mem(struct gpmc_cs_data *p,
struct gpmc_device_pdata *gdp, struct gpmc *gpmc)
{
@@ -1066,6 +1089,8 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
gpmc_mem_init();
for (gdq = gp-device_pdata, gd = gpmc-device; *gdq; gdq++, i++) {
+ if ((*gdq)-is_nand)
+ gpmc_update_nand_reg(gpmc, (*gdq)-pdata);
ret = gpmc_setup_device(*gdq, gd, gpmc);
if (IS_ERR_VALUE(ret))
dev_err(gpmc-dev, gpmc setup on %s failed\n,
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index fa62cdf..a320e71 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -169,6 +169,7 @@ struct gpmc_device_pdata {
unsignednum_per_res;
struct gpmc_cs_data *cs_data;
unsignednum_cs;
+ boolis_nand;
};
struct gpmc_pdata {
@@ -179,6 +180,21 @@ struct gpmc_pdata {
unsignednum_irq;
};
+struct gpmc_nand_regs {
+ void __iomem*gpmc_status;
+ void __iomem*gpmc_nand_command;
+ void __iomem*gpmc_nand_address;
+ void __iomem*gpmc_nand_data;
+ void __iomem*gpmc_prefetch_config1;
+ void __iomem*gpmc_prefetch_config2;
+ void __iomem*gpmc_prefetch_control;
+ void __iomem*gpmc_prefetch_status;
+ void __iomem*gpmc_ecc_config;
+ void __iomem*gpmc_ecc_control;
+ void __iomem*gpmc_ecc_size_config;
+ void __iomem*gpmc_ecc1_result;
+};
+
extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 67fc506..86e4d9c 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -29,6 +29,7 @@ struct omap_nand_platform_data {
unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
+ struct gpmc_nand_regs reg;
};
/* minimum size for IO mapping */
--
1.7.9.3
--
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
[PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Convert GPMC code to driver. Boards using GPMC should provide driver
with type of configuration, timing, CS, GPMC address space details
(if already configured, driver will retrieve, as is existing).
Platform devices would the be created for each connected peripheral
(details also to be passed by board so that it reaches respective
driver). And GPMC driver would populate memory resource details for
the driver of connected peripheral.
A peripheral connected to GPMC can have multiple address spaces using
different chip select. Hence GPMC driver has been provided capability
to create platform device for peripheral using mutiple CS. The
peripheral that made it necessary was tusb6010. Thanks to Jon Hunter
for his suggesstion on better way to handle this.
Interrupts of GPMC are presented to drivers of connected peripherals
as resource. A fictitious interrupt controller chip handles these
interrupts at GPMC hardware level. Clients can use normal interrupt
APIs. Platforms should inform GPMC driver infrastruture available
for these imaginary client interrupts (like irq number). Platform
information of peripheral passed to GPMC driver should indicate
interrupts to be used via flags.
Final destination for this driver is being investigated. Before moving
to the new location, all existing GPMC users has to be converted to
work with this driver.
NAND driver for NAND used via GPMC is tightly coupled with GPMC
driver (GPMC has few blocks exclusively for NAND), while that is not
the case for most of the other users (they need GPMCs help only for
initial configuration). Currently NAND driver manage using exported
GPMC symbols. This is being planned to remove later would need
informing NAND driver about GPMC NAND registers. This would help to
have export symbol free GPMC driver, and probably
mv omap2.c gpmc-nand.c for OMAP NAND driver.
Thanks to Vaibhav Hiremath for his ideas on this.
Acquiring CS# for NAND is done on a few boards. It means, depending
on bootloader to embed this information. Probably CS# being used can
be set in the Kernel, and acquiring it can be removed. If ever this
capbility is needed, GPMC driver has to be made aware of handling it.
OneNAND - as it may involve reconfiguring GPMC for synchronous may
need a quirk to handle or driver has to be made more intelligent to
handle it.
Code related to GPMC clock may have to continue live in platform
folders (even if the driver is moved to MFD) as input clock is beyond
the control of GPMC and calculating timing for the peripheral may
need other helpers.
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 518 ++--
arch/arm/plat-omap/include/plat/gpmc.h | 50 ++-
2 files changed, 476 insertions(+), 92 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..cf5d8f3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,8 +14,11 @@
*/
#undef DEBUG
+#include linux/platform_device.h
+
#include linux/irq.h
#include linux/kernel.h
+#include linux/slab.h
#include linux/init.h
#include linux/err.h
#include linux/clk.h
@@ -64,6 +67,47 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
+#defineDRIVER_NAME omap-gpmc
+
+#defineGPMC_NR_IRQ 6
+
+struct gpmc_device {
+ char*name;
+ int id;
+ void*pdata;
+ unsignedpdata_size;
+ struct resource *per_res;
+ unsignednum_per_res;
+ struct resource *gpmc_res;
+ unsignednum_gpmc_res;
+};
+
+struct gpmc_irq{
+ unsignedirq;
+ u32 regval;
+};
+
+struct gpmc {
+ struct device *dev;
+ unsigned long fclk_period;
+ void __iomem*io_base;
+ unsigned long phys_base;
+ u32 memsize;
+ unsignedcs_map;
+ int ecc_used;
+ spinlock_t mem_lock;
+ struct resource mem_root;
+ struct resource cs_mem[GPMC_CS_NUM];
+ /* XXX: Or allocate dynamically ? */
+ struct gpmc_device device[GPMC_CS_NUM];
+ unsignednum_device;
+ unsignedmaster_irq;
+ unsignedirq_start;
+ unsignednum_irq;
+ struct gpmc_irq irq[GPMC_NR_IRQ];
+ struct irq_chip irq_chip;
+};
+
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -91,58 +135,50 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
-static struct resource gpmc_mem_root;
-static struct resource gpmc_cs_mem[GPMC_CS_NUM];
-static
[PATCH v3 3/9] ARM: OMAP2+: nand: create platform data structure
New API for updating nand platform data. This has
been created by unifying the two existing ones and
taking out gpmc hardware handling.
From now on, platforms can call omap_nand_init to
initialize platform nand structures, it's fields.
Or can statically create the same.
Acquiring gpmc CS has been removed. Acquiring CS
probably should be avoided, if ever required, do
in GPMC driver.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c |6 ++-
arch/arm/mach-omap2/board-flash.c | 63 ++--
arch/arm/mach-omap2/board-flash.h | 13 --
arch/arm/mach-omap2/board-ldp.c|4 +-
arch/arm/mach-omap2/board-omap3beagle.c|6 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |6 ++-
arch/arm/mach-omap2/board-overo.c |5 ++-
arch/arm/mach-omap2/board-zoom.c |5 ++-
arch/arm/mach-omap2/common-board-devices.c | 46
arch/arm/mach-omap2/common-board-devices.h |1 -
10 files changed, 61 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index a2010f0..adfcfc1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,6 +59,7 @@
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
#define OMAP_DM9000_GPIO_IRQ 25
@@ -648,8 +649,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));
+ omap_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), GPMC_CS_NUM + 1,
+ NAND_BUSWIDTH_16, NULL);
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0349fd2..26c70b8 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,45 +108,45 @@ __init board_onenand_init(struct mtd_partition
*nor_parts, u8 nr_parts, u8 cs)
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 omap_nand_data = {
+ .gpmc_t = nand_default_timings,
};
-void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+struct omap_nand_platform_data *
+__init omap_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.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
- board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
- gpmc_nand_init(board_nand_data);
+ omap_nand_data.cs = cs;
+ omap_nand_data.parts= nand_parts;
+ omap_nand_data.nr_parts = nr_parts;
+ omap_nand_data.devsize = nand_type;
+ omap_nand_data.gpmc_t = gpmc_t;
+
+ return omap_nand_data;
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
@@ -242,6 +242,7 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
if (nandcs GPMC_CS_NUM)
pr_err(NAND: Unable to find configuration in GPMC\n);
else
- board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ omap_nand_init(partition_info[2].parts,
+
[PATCH v3 4/9] ARM: OMAP2+: gpmc-nand: populate gpmc configs
Currently gpmc is configured in platform for nand.
As configuring gpmc has been moved to gpmc driver,
populate details needed for the driver to configure
gpmc. gpmc driver would configure based on this
information.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c| 97 ++--
arch/arm/plat-omap/include/plat/nand.h |8 ++-
2 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..85de31f 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,24 +21,38 @@
#include plat/board.h
#include plat/gpmc.h
-static struct resource gpmc_nand_resource = {
- .flags = IORESOURCE_MEM,
+
+#defineGPMC_NAND_CONFIG_NUM4
+#defineIDX_DEV_SIZE2
+#defineIDX_RDY_BSY 3
+
+static struct gpmc_config gpmc_nand_config[GPMC_NAND_CONFIG_NUM] = {
+ { GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND},
+ { GPMC_CONFIG_WP, 0},
};
-static struct platform_device gpmc_nand_device = {
+static struct gpmc_cs_data gpmc_nand_cs_info = {
+ .config = gpmc_nand_config,
+ .num_config = ARRAY_SIZE(gpmc_nand_config),
+ .irq_flags = GPMC_IRQ_FIFOEVENT | GPMC_IRQ_TERMINALCOUNT,
+};
+
+static struct gpmc_device_pdata gpmc_nand_info = {
.name = omap2-nand,
.id = 0,
- .num_resources = 1,
- .resource = gpmc_nand_resource,
+ .cs_data= gpmc_nand_cs_info,
+ .num_cs = 1,
};
-static int omap2_nand_gpmc_retime(struct omap_nand_platform_data
*gpmc_nand_data)
-{
- struct gpmc_timings t;
- int err;
+static struct gpmc_timings t;
- if (!gpmc_nand_data-gpmc_t)
+static struct gpmc_timings *
+gpmc_nand_retime(struct omap_nand_platform_data *gpmc_nand_data)
+{
+ if (!gpmc_nand_data-gpmc_t) {
+ pr_warn(gpmc timings not provided\n);
return 0;
+ }
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_nand_data-gpmc_t-sync_clk;
@@ -68,56 +82,31 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
- /* Configure GPMC */
- if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 1);
- else
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_DEV_SIZE, 0);
- gpmc_cs_configure(gpmc_nand_data-cs,
- GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
- if (err)
- return err;
-
- return 0;
+ return t;
}
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
+struct gpmc_device_pdata *
+__init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
{
- int err = 0;
- struct device *dev = gpmc_nand_device.dev;
+ gpmc_nand_info.pdata = gpmc_nand_data;
+ gpmc_nand_info.pdata_size = sizeof(*gpmc_nand_data);
- gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+ gpmc_nand_cs_info.cs = gpmc_nand_data-cs;
+ gpmc_nand_cs_info.mem_size = NAND_IO_SIZE;
- err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- gpmc_nand_data-phys_base);
- if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
- return err;
- }
+ gpmc_nand_cs_info.timing = gpmc_nand_retime(gpmc_nand_data);
-/* Set timings in GPMC */
- err = omap2_nand_gpmc_retime(gpmc_nand_data);
- if (err 0) {
- dev_err(dev, Unable to set gpmc timings: %d\n, err);
- return err;
- }
-
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data-dev_ready) {
- gpmc_cs_configure(gpmc_nand_data-cs, GPMC_CONFIG_RDY_BSY, 1);
- }
-
- err = platform_device_register(gpmc_nand_device);
- if (err 0) {
- dev_err(dev, Unable to register NAND device\n);
- goto out_free_cs;
- }
-
- return 0;
+ gpmc_nand_config[IDX_DEV_SIZE].cmd = GPMC_CONFIG_DEV_SIZE;
+ if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
+ gpmc_nand_config[IDX_DEV_SIZE].val = 1;
+ else
+ gpmc_nand_config[IDX_DEV_SIZE].val = 0;
-out_free_cs:
- gpmc_cs_free(gpmc_nand_data-cs);
+ gpmc_nand_config[IDX_RDY_BSY].cmd = GPMC_CONFIG_RDY_BSY;
+ if (gpmc_nand_data-dev_ready)
+ gpmc_nand_config[IDX_RDY_BSY].val = 1;
+ else
+ gpmc_nand_config[IDX_RDY_BSY].val = 0;
- return err;
+ return gpmc_nand_info;
}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
[PATCH v3 5/9] ARM: OMAP2+: gpmc-smsc911x: gpmc driver information
gpmc has been converted to driver. And all gpmc related
configuration would be done by gpmc driver. Provide
gpmc driver with sufficient information so that it can
configure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 59 ---
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |9 +++-
2 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index b6c77be..52192a9 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -24,13 +24,8 @@
#include plat/gpmc.h
#include plat/gpmc-smsc911x.h
-static struct resource gpmc_smsc911x_resources[] = {
- [0] = {
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
- },
+static struct resource gpmc_smsc911x_resources = {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
};
static struct smsc911x_platform_config gpmc_smsc911x_config = {
@@ -44,26 +39,42 @@ static struct smsc911x_platform_config gpmc_smsc911x_config
= {
* assume that pin multiplexing is done in the board-*.c file,
* or in the bootloader.
*/
-void __init gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
+__init struct gpmc_device_pdata *
+gpmc_smsc911x_init(struct omap_smsc911x_platform_data *gpmc_cfg)
{
- struct platform_device *pdev;
- unsigned long cs_mem_base;
int ret;
+ struct gpmc_device_pdata *gpmc_pdev;
+ struct gpmc_cs_data *gpmc_cs;
- if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
- pr_err(Failed to request GPMC mem region\n);
- return;
+ gpmc_pdev = kzalloc(sizeof(*gpmc_pdev), GFP_KERNEL);
+ if (gpmc_pdev == NULL)
+ return gpmc_pdev;
+
+ gpmc_cs = kzalloc(sizeof(*gpmc_cs), GFP_KERNEL);
+ if (gpmc_pdev == NULL) {
+ kfree(gpmc_pdev);
+ return NULL;
}
- gpmc_smsc911x_resources[0].start = cs_mem_base + 0x0;
- gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
+ gpmc_pdev-cs_data = gpmc_cs;
+ gpmc_pdev-num_cs = 1;
+ gpmc_pdev-name = smsc911x;
+ gpmc_pdev-id = gpmc_cfg-id;
+ gpmc_pdev-pdata = gpmc_smsc911x_config;
+ gpmc_pdev-pdata_size = sizeof(gpmc_smsc911x_config);
+
+ gpmc_cs-cs = gpmc_cfg-cs;
+ gpmc_cs-mem_size = 0xff;
+
+ gpmc_pdev-per_res = gpmc_smsc911x_resources;
+ gpmc_pdev-num_per_res = 1;
if (gpio_request_one(gpmc_cfg-gpio_irq, GPIOF_IN, smsc911x irq)) {
pr_err(Failed to request IRQ GPIO%d\n, gpmc_cfg-gpio_irq);
goto free1;
}
- gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg-gpio_irq);
+ gpmc_smsc911x_resources.start = gpio_to_irq(gpmc_cfg-gpio_irq);
if (gpio_is_valid(gpmc_cfg-gpio_reset)) {
ret = gpio_request_one(gpmc_cfg-gpio_reset,
@@ -81,21 +92,15 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *gpmc_cfg)
gpmc_smsc911x_config.flags = gpmc_cfg-flags ? : SMSC911X_USE_16BIT;
- pdev = platform_device_register_resndata(NULL, smsc911x, gpmc_cfg-id,
-gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
-gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
- if (!pdev) {
- pr_err(Unable to register platform device\n);
- gpio_free(gpmc_cfg-gpio_reset);
- goto free2;
- }
-
- return;
+ return gpmc_pdev;
free2:
gpio_free(gpmc_cfg-gpio_irq);
free1:
- gpmc_cs_free(gpmc_cfg-cs);
+ kfree(gpmc_cs);
+ kfree(gpmc_pdev);
pr_err(Could not initialize smsc911x device\n);
+
+ return NULL;
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index ea6c9c8..66dc7f1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -11,6 +11,8 @@
* published by the Free Software Foundation.
*/
+#includeplat/gpmc.h
+
#ifndef __ASM_ARCH_OMAP_GPMC_SMSC911X_H__
struct omap_smsc911x_platform_data {
@@ -23,12 +25,15 @@ struct omap_smsc911x_platform_data {
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
+extern struct gpmc_device_pdata *
+gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
#else
-static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
+static inline struct gpmc_device_pdata *
+gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
{
+ return NULL;
}
#endif
--
1.7.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH v3 6/9] mtd: nand: omap2: obtain memory from resource
gpmc being converted to driver, provides drivers
of peripheral connected memory space used by the
peripheral as memory resource.
Modify nand omap driver to obtain memory detials
from resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |1 -
drivers/mtd/nand/omap2.c | 20 ++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 30c61c9..570c4f4 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -26,7 +26,6 @@ struct omap_nand_platform_data {
booldev_ready;
int gpmc_irq;
enum nand_ioxfer_type;
- unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c2b0bba..be4b321 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -118,6 +118,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
+ unsigned long mem_size;
struct completion comp;
int dma_ch;
int gpmc_irq;
@@ -931,6 +932,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_platform_data *pdata;
int err;
int i, offset;
+ struct resource *res;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -950,7 +952,6 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
info-pdev = pdev;
info-gpmc_cs = pdata-cs;
- info-phys_base = pdata-phys_base;
info-mtd.priv = info-nand;
info-mtd.name = dev_name(pdev-dev);
@@ -959,16 +960,23 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info-nand.options = pdata-devsize;
info-nand.options |= NAND_SKIP_BBTSCAN;
- /* NAND write protect off */
- gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_WP, 0);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ err = -EINVAL;
+ dev_err(pdev-dev, error getting memory resource\n);
+ goto out_free_info;
+ }
+
+ info-phys_base = res-start;
+ info-mem_size = resource_size(res);
- if (!request_mem_region(info-phys_base, NAND_IO_SIZE,
+ if (!request_mem_region(info-phys_base, info-mem_size,
pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, NAND_IO_SIZE);
+ info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1110,7 +1118,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
return 0;
out_release_mem_region:
- release_mem_region(info-phys_base, NAND_IO_SIZE);
+ release_mem_region(info-phys_base, info-mem_size);
out_free_info:
kfree(info);
--
1.7.9.3
--
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
[PATCH v3 7/9] mtd: nand: omap2: use gpmc provided irqs
GPMC driver provides it's clientsd with interrupts that can be used
through struct resource. Make use of it for irq mode functionality.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 67 +-
1 file changed, 42 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index be4b321..440536b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -121,7 +121,8 @@ struct omap_nand_info {
unsigned long mem_size;
struct completion comp;
int dma_ch;
- int gpmc_irq;
+ int gpmc_irq_fifo;
+ int gpmc_irq_count;
enum {
OMAP_NAND_IO_READ = 0, /* read */
OMAP_NAND_IO_WRITE, /* write */
@@ -472,13 +473,11 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
{
struct omap_nand_info *info = (struct omap_nand_info *) dev;
u32 bytes;
- u32 irq_stat;
- irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
if (info-buf_len (info-buf_len bytes))
@@ -495,20 +494,17 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
(u32 *)info-buf, bytes 2);
info-buf = info-buf + bytes;
- if (irq_stat 0x2)
+ if (this_irq == info-gpmc_irq_count)
goto done;
}
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
return IRQ_HANDLED;
done:
complete(info-comp);
- /* disable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
- /* clear status */
- gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ disable_irq_nosync(info-gpmc_irq_fifo);
+ disable_irq_nosync(info-gpmc_irq_count);
return IRQ_HANDLED;
}
@@ -542,9 +538,9 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd,
u_char *buf, int len)
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for read to complete */
wait_for_completion(info-comp);
@@ -591,12 +587,13 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
goto out_copy;
info-buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info-gpmc_irq_count);
+ enable_irq(info-gpmc_irq_fifo);
/* waiting for write to complete */
wait_for_completion(info-comp);
+
/* wait for data to flushed-out before reset the prefetch */
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
@@ -982,6 +979,14 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
goto out_release_mem_region;
}
+ info-gpmc_irq_fifo = platform_get_irq(pdev, 0);
+ if (info-gpmc_irq_fifo == -ENXIO)
+ dev_warn(pdev-dev, error getting FIFO IRQ\n);
+
+ info-gpmc_irq_count = platform_get_irq(pdev, 1);
+ if (info-gpmc_irq_fifo == -ENXIO)
+ dev_warn(pdev-dev, error getting TERMINALCOUNT IRQ\n);
+
info-nand.controller = info-controller;
info-nand.IO_ADDR_W = info-nand.IO_ADDR_R;
@@ -1037,17 +1042,24 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
break;
case NAND_OMAP_PREFETCH_IRQ:
- err = request_irq(pdata-gpmc_irq,
- omap_nand_irq, IRQF_SHARED, gpmc-nand, info);
+ err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
+ IRQF_SHARED, gpmc-nand-fifo, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
- pdata-gpmc_irq, err);
+ info-gpmc_irq_fifo, err);
goto out_release_mem_region;
- } else {
- info-gpmc_irq = pdata-gpmc_irq;
- info-nand.read_buf = omap_read_buf_irq_pref;
- info-nand.write_buf =
[PATCH v3 8/9] mtd: nand: omap2: handle nand on gpmc
GPMC driver has been modified to fill NAND platform data with GPMC
NAND register details. As these registers are accessible in NAND
driver itself, configure NAND in GPMC by itself.
Note: Verfying that other CS have not yet enabled for prefetch ecc
has to be incorporated. Currently this causes no issues as there are
no boards that use NAND on multiple CS. With GPMC modifications,
perhaps it would be better to consider NAND connected on multiple CS
as a single peripheral using multiple CS. This would make handling
multiple CS issues easier.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/mtd/nand/omap2.c | 209 --
1 file changed, 165 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 440536b..34fb726 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -129,8 +129,79 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ struct gpmc_nand_regs reg;
};
+#definePREFETCH_CONFIG1_CS_SHIFT 24
+#defineECC_CONFIG_CS_SHIFT 1
+#defineCS_MASK 0x7
+#defineENABLE_PREFETCH (0x1 7)
+#defineDMA_MPU_MODE_SHIFT 2
+#defineECCSIZE1_SHIFT 22
+#defineECC1RESULTSIZE 0x1
+#defineECC_CLEAR_SHIFT 8
+#defineECC10x1
+
+/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int cs, int fifo_th, int dma_mode,
+ unsigned int u32_count, int is_write, struct omap_nand_info *info)
+{
+ u32 val;
+
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ pr_err(gpmc: fifo threshold is not supported\n);
+ return -1;
+ } else if (!(readl(info-reg.gpmc_prefetch_control))) {
+ /* Set the amount of bytes to be prefetched */
+ writel(u32_count, info-reg.gpmc_prefetch_config2);
+
+ /* Set dma/mpu mode, the prefetch read / post write and
+* enable the engine. Set which cs is has requested for.
+*/
+ val = ((cs PREFETCH_CONFIG1_CS_SHIFT) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
+ ENABLE_PREFETCH |
+ (dma_mode DMA_MPU_MODE_SHIFT) |
+ (0x1 is_write));
+ writel(val, info-reg.gpmc_prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(0x1, info-reg.gpmc_prefetch_control);
+ } else {
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static int omap_prefetch_reset(int cs, struct omap_nand_info *info)
+{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = readl(info-reg.gpmc_prefetch_config1);
+ if (((config1 PREFETCH_CONFIG1_CS_SHIFT) CS_MASK) != cs)
+ return -EINVAL;
+
+ /* Stop the PFPW engine */
+ writel(0x0, info-reg.gpmc_prefetch_control);
+
+ /* Reset/disable the PFPW engine */
+ writel(0x0, info-reg.gpmc_prefetch_config1);
+
+ return 0;
+}
+
/**
* omap_hwcontrol - hardware specific access to control-lines
* @mtd: MTD device structure
@@ -149,13 +220,13 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_COMMAND, cmd);
+ writeb(cmd, info-reg.gpmc_nand_command);
else if (ctrl NAND_ALE)
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+ writeb(cmd, info-reg.gpmc_nand_address);
else /* NAND_NCE */
- gpmc_nand_write(info-gpmc_cs, GPMC_NAND_DATA, cmd);
+ writeb(cmd, info-reg.gpmc_nand_data);
}
}
@@ -189,7 +260,8 @@ static void omap_write_buf8(struct mtd_info *mtd, const
u_char *buf, int len)
iowrite8(*p++, info-nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = gpmc_read_status(GPMC_STATUS_BUFFER);
+ status = readl(info-reg.gpmc_status)
+ GPMC_STATUS_BUFF_EMPTY;
} while (!status);
[TMP] OMAP3EVM: Test gpmc nand smsc911x
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 95 +-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 49df127..60938af 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -23,6 +23,7 @@
#include linux/input/matrix_keypad.h
#include linux/leds.h
#include linux/interrupt.h
+#include linux/mtd/nand.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
@@ -41,6 +42,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
+#include plat/nand.h
#include plat/board.h
#include plat/usb.h
#include common.h
@@ -52,6 +54,7 @@
#include sdram-micron-mt46h32m32lf-6.h
#include hsmmc.h
#include common-board-devices.h
+#include board-flash.h
#define OMAP3_EVM_TS_GPIO 175
#define OMAP3_EVM_EHCI_VBUS22
@@ -102,6 +105,36 @@ static void __init omap3_evm_get_revision(void)
}
}
+static struct gpmc_device_pdata *gpmc_data_array[3];
+static struct gpmc_device_pdata **gpmc_data_cur = gpmc_data_array;
+
+static struct gpmc_pdata gpmc_data = {
+ .device_pdata = gpmc_data_array,
+};
+
+static struct resource gpmc_resources[] = {
+ {
+ .start = OMAP34XX_GPMC_BASE,
+ .end = OMAP34XX_GPMC_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_34XX_GPMC_IRQ,
+ .end = INT_34XX_GPMC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device gpmc_device = {
+ .name = omap-gpmc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(gpmc_resources),
+ .resource = gpmc_resources,
+ .dev= {
+ .platform_data = gpmc_data,
+ }
+};
+
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include plat/gpmc-smsc911x.h
@@ -114,6 +147,8 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
static inline void __init omap3evm_init_smsc911x(void)
{
+ struct gpmc_device_pdata *gpmc_smsc911x_info;
+
/* Configure ethernet controller reset gpio */
if (cpu_is_omap3430()) {
if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
@@ -122,7 +157,11 @@ static inline void __init omap3evm_init_smsc911x(void)
smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
}
- gpmc_smsc911x_init(smsc911x_cfg);
+ gpmc_smsc911x_info = gpmc_smsc911x_init(smsc911x_cfg);
+ if (gpmc_smsc911x_info)
+ *gpmc_data_cur++ = gpmc_smsc911x_info;
+ else
+ pr_err(error: unable to initilaize gpmc smsc911x\n);
}
#else
@@ -523,6 +562,41 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata
= {
.reset_gpio_port[2] = -EINVAL
};
+/*
+ * NAND
+ */
+static struct mtd_partition omap3_evm_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 40 * (64 * 2048),
+ },
+ {
+ .name = File System - NAND,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x78 */
+ },
+};
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux omap35x_board_mux[] __initdata = {
OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
@@ -630,6 +704,8 @@ static struct regulator_consumer_supply dummy_supplies[] = {
static void __init omap3_evm_init(void)
{
+ struct omap_nand_platform_data *nand_data;
+
omap3_evm_get_revision();
regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
@@ -681,6 +757,23 @@ static void __init omap3_evm_init(void)
omap3evm_init_smsc911x();
omap3_evm_display_init();
omap3_evm_wl12xx_init();
+ /* NAND */
+ nand_data = omap_nand_init(omap3_evm_nand_partitions,
+ ARRAY_SIZE(omap3_evm_nand_partitions),
+ 0,
RE: OMAP3EVM not booting on l-o master
Hi Govindraj, On Thu, Apr 05, 2012 at 15:53:25, R, Govindraj wrote: Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. With that patch too, Kernel does not boot. 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: [PATCHv5 16/18] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
On 04/04/2012 02:22 PM, Jon Hunter wrote: Hi Shubhro, On 04/04/2012 12:45 PM, Shubhrajyoti Datta wrote: Hi Jon, + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev= OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; The errata ID is not correct. I believe that 1P153 is referring to the section number in the errata doc and not the errata ID. The errata ID should be i451 in the latest OMAP34xx and OMAP36xx docs. Please can you update this? The section number changed in the latest errata docs and it took me a minute to find this. Do you mind if that is a separate patch? Not at all and in fact it probably should be. Sorry the erratum ID is not i451 but i462! Cheers Jon -- 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: OMAP3EVM not booting on l-o master
Hi Paul, On Thu, Apr 05, 2012 at 15:37:42, Paul Walmsley wrote: I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? I am unable to fetch using git protocol, hence tried, http://git.pwsan.com/linux-2.6 http://git.pwsan.com/linux-2.6.git but giving error, fatal: http://git.pwsan.com/linux-2.6/info/refs not found: did you run git update-server-info on the server? Any other to 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] staging: drm/omap: move where DMM driver is registered
On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device. --- drivers/staging/omapdrm/omap_drv.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Is this needed for 3.4-final? Any older kernels like 3.3 as well? thanks, greg k-h -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
* Paul Walmsley p...@pwsan.com [120405 01:53]: On Wed, 4 Apr 2012, Paul Walmsley wrote: On Wed, 4 Apr 2012, Tony Lindgren wrote: Thanks, looks like two of these patches I already merged into fixes yesterday from your earlier pull request. So merging this in would cause duplicate commits. Can you please update your branch to remove those two commits? Do you happen to recall which ones they are? Anyway, am guessing that you are planning to pull these into your 'fixes' branch? If so then probably the conflicts are with the misc_devel_3.4 branch patches. Will post another pull request for you with those two patches dropped. But if you're pulling these into a different branch, please let me know... Yes it's the fixes branch I was talking about, thanks for updating it. Tony -- 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 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Thu, Apr 05, 2012 at 01:26:17PM +0100, Alan Cox wrote: On Thu, 5 Apr 2012 16:54:03 +0530 Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, Mar 21, 2012 at 3:54 PM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) Alan / Greg, With you ack on tty parts can this series be upstreamed from omap tree ? Fine by me - this seems primarily to be architectural details. Fine by me as well: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] staging: drm/omap: move where DMM driver is registered
On Thu, Apr 5, 2012 at 11:41 AM, Greg KH g...@kroah.com wrote: On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device. --- drivers/staging/omapdrm/omap_drv.c | 7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Is this needed for 3.4-final? Any older kernels like 3.3 as well? Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7) BR, -R thanks, greg k-h ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
* Raja, Govindraj govindraj.r...@ti.com [120403 23:18]: On Tue, Apr 3, 2012 at 11:49 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [120321 03:06]: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove all default pads except uart1/3 as most boards tend to use either uart1/3 as console port and use only tx/rx lines, declare only those pads for uart1/3. If any boards tend to use any other uart other uart1/3 the mux data should to passed from board file and init individual uart port using omap_serial_init_port api. This is still wrong. We can't mux any serial pins unless specifically requested from the board-*.c files. So please do a fix to get back to v3.2 behaviour where you basically revert 7496ba3. How to do we fix the rx pin wakeup capability? The mux data has the info about the rx pin wakeup Without rx pin wakeup PM will be broken. Let's first make things work reliably before even getting started about PM being broken. Fix all board files with duplicated data for uart3 or uart1 having rx pin marked as wakeup capable? And how do you know which pins to mux? You don't, unless you look at the schematics for all the boards. The only safe option without looking at the schematics is to make omap_serial_init not do any muxing. If you want muxing and PM wake-up events, then use omap_serial_init_port for those ports with board specific pins. Behavior in v3.2 was raw_write to all uarts rx_pin to enable wakeup enable bit. Hmm I don't think any muxing was done automatically unless omap_serial_init_port was being called with pins. Regards, Tony -- 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] staging: drm/omap: move where DMM driver is registered
On Thu, Apr 05, 2012 at 11:51:30AM -0500, Rob Clark wrote: On Thu, Apr 5, 2012 at 11:41 AM, Greg KH g...@kroah.com wrote: On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device. --- drivers/staging/omapdrm/omap_drv.c | 7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Is this needed for 3.4-final? Any older kernels like 3.3 as well? Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7) Ok, I'll queue it up for 3.4-final, let me know if it's also needed in 3.3 if you get the chance. greg k-h -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
* Tony Lindgren t...@atomide.com [120405 10:01]: * Raja, Govindraj govindraj.r...@ti.com [120403 23:18]: On Tue, Apr 3, 2012 at 11:49 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [120321 03:06]: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove all default pads except uart1/3 as most boards tend to use either uart1/3 as console port and use only tx/rx lines, declare only those pads for uart1/3. If any boards tend to use any other uart other uart1/3 the mux data should to passed from board file and init individual uart port using omap_serial_init_port api. This is still wrong. We can't mux any serial pins unless specifically requested from the board-*.c files. So please do a fix to get back to v3.2 behaviour where you basically revert 7496ba3. How to do we fix the rx pin wakeup capability? The mux data has the info about the rx pin wakeup Without rx pin wakeup PM will be broken. Let's first make things work reliably before even getting started about PM being broken. Fix all board files with duplicated data for uart3 or uart1 having rx pin marked as wakeup capable? And how do you know which pins to mux? You don't, unless you look at the schematics for all the boards. The only safe option without looking at the schematics is to make omap_serial_init not do any muxing. If you want muxing and PM wake-up events, then use omap_serial_init_port for those ports with board specific pins. Something that might be doable is to read the pin settings for the uart in question in omap_serial_init. And then bail out for that port if the rx or tx pin is not already muxed to uart in question. Only if the rx and tx pin is muxed for uart, then you can enable the wake-up events. So basically doing remuxing in serial.c is only safe when omap_serial_init_port with mux data is being used. Regards, Tony -- 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: OMAP3EVM not booting on l-o master
* Mohammed, Afzal af...@ti.com [120405 09:22]: Hi Govindraj, On Thu, Apr 05, 2012 at 15:53:25, R, Govindraj wrote: Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. With that patch too, Kernel does not boot. What happens if you disable CONFIG_OMAP_MUX? Regards, Tony -- 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] staging: drm/omap: move where DMM driver is registered
On Thu, Apr 5, 2012 at 11:58 AM, Greg KH g...@kroah.com wrote: On Thu, Apr 05, 2012 at 11:51:30AM -0500, Rob Clark wrote: On Thu, Apr 5, 2012 at 11:41 AM, Greg KH g...@kroah.com wrote: On Thu, Apr 05, 2012 at 10:34:56AM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Not sure what triggered the change in behavior, but seems to result in recursively acquiring a mutex and hanging on boot. But omap_drm_init() seems a much more sane place to register the driver for the DMM sub-device. --- drivers/staging/omapdrm/omap_drv.c | 7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Is this needed for 3.4-final? Any older kernels like 3.3 as well? Yeah, it is needed for 3.4-final.. I need to check on 3.3 (it was fine circa 3.3-rc6 or rc7) Ok, I'll queue it up for 3.4-final, let me know if it's also needed in 3.3 if you get the chance. oh, duh.. I realized that patch that split DMM into a sub-device (for hwmod) was actually part of the patches for 3.4, so the problem didn't exist yet in 3.3 :-) BR, -R greg k-h -- 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 -- 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] omap fixes for v3.4-rc1
Hi, On Wed, Apr 4, 2012 at 5:42 PM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Note that this also contains a set of fixes that are not regressions or oopses to properly deal with the smsc911x regulator issue. Basically the regulators must be per board file as the regulators can also come from drivers, such as twl4030. So it's best to dumb down gpmc-smsc911x.c to not even care about the regulators. Regards, Tony The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linus Torvalds (1): Linux 3.4-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Thanks, pulled. Feel free to start sending these as signed tags with the above in the tag description, so it's carried forward in the git history without any work for us. :-) -Olof -- 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
[PATCH] staging: drm/omap: dmabuf/prime support
From: Rob Clark r...@ti.com
For now just implementing the exporting APIs, not yet importing. And
kmap is rejected on tiled buffers (although the usefulness of that seems
questionable, but could be added later if needed).
---
drivers/staging/omapdrm/Makefile |1 +
drivers/staging/omapdrm/omap_drv.c|4 +-
drivers/staging/omapdrm/omap_drv.h|7 ++
drivers/staging/omapdrm/omap_gem.c| 26 +-
drivers/staging/omapdrm/omap_gem_dmabuf.c | 150 +
5 files changed, 186 insertions(+), 2 deletions(-)
create mode 100644 drivers/staging/omapdrm/omap_gem_dmabuf.c
diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index d9cdc12..1ca0e00 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -13,6 +13,7 @@ omapdrm-y := omap_drv.o \
omap_fb.o \
omap_fbdev.o \
omap_gem.o \
+ omap_gem_dmabuf.o \
omap_dmm_tiler.o \
tcm-sita.o
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 620b8d5..1f559f4 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -746,7 +746,7 @@ static const struct file_operations omapdriver_fops = {
static struct drm_driver omap_drm_driver = {
.driver_features =
- DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
+ DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM |
DRIVER_PRIME,
.load = dev_load,
.unload = dev_unload,
.open = dev_open,
@@ -766,6 +766,8 @@ static struct drm_driver omap_drm_driver = {
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
#endif
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .gem_prime_export = omap_gem_prime_export,
.gem_init_object = omap_gem_init_object,
.gem_free_object = omap_gem_free_object,
.gem_vm_ops = omap_gem_vm_ops,
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 3d22df7..2b41152 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -148,9 +148,16 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t
roll);
int omap_gem_get_paddr(struct drm_gem_object *obj,
dma_addr_t *paddr, bool remap);
int omap_gem_put_paddr(struct drm_gem_object *obj);
+int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
+ bool remap);
+int omap_gem_put_pages(struct drm_gem_object *obj);
+uint32_t omap_gem_flags(struct drm_gem_object *obj);
uint64_t omap_gem_mmap_offset(struct drm_gem_object *obj);
size_t omap_gem_mmap_size(struct drm_gem_object *obj);
+struct dma_buf * omap_gem_prime_export(struct drm_device *dev,
+ struct drm_gem_object *obj, int flags);
+
static inline int align_pitch(int pitch, int width, int bpp)
{
int bytespp = (bpp + 7) / 8;
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index 921f058..c5ba334 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -266,6 +266,12 @@ static void omap_gem_detach_pages(struct drm_gem_object
*obj)
omap_obj-pages = NULL;
}
+/* get buffer flags */
+uint32_t omap_gem_flags(struct drm_gem_object *obj)
+{
+ return to_omap_bo(obj)-flags;
+}
+
/** get mmap offset */
static uint64_t mmap_offset(struct drm_gem_object *obj)
{
@@ -764,9 +770,27 @@ static int get_pages(struct drm_gem_object *obj, struct
page ***pages)
return 0;
}
-int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages)
+/* if !remap, and we don't have pages backing, then fail, rather than
+ * increasing the pin count (which we don't really do yet anyways,
+ * because we don't support swapping pages back out). And 'remap'
+ * might not be quite the right name, but I wanted to keep it working
+ * similarly to omap_gem_get_paddr(). Note though that mutex is not
+ * aquired if !remap (because this can be called in atomic ctxt),
+ * but probably omap_gem_get_paddr() should be changed to work in the
+ * same way. If !remap, a matching omap_gem_put_pages() call is not
+ * required (and should not be made).
+ */
+int omap_gem_get_pages(struct drm_gem_object *obj, struct page ***pages,
+ bool remap)
{
int ret;
+ if (!remap) {
+ struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ if (!omap_obj-pages)
+ return -ENOMEM;
+ *pages = omap_obj-pages;
+ return 0;
+ }
mutex_lock(obj-dev-struct_mutex);
ret = get_pages(obj, pages);
mutex_unlock(obj-dev-struct_mutex);
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
Re: [GIT PULL] omap fixes for v3.4-rc1
* Olof Johansson o...@lixom.net [120405 10:51]: Hi, On Wed, Apr 4, 2012 at 5:42 PM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Note that this also contains a set of fixes that are not regressions or oopses to properly deal with the smsc911x regulator issue. Basically the regulators must be per board file as the regulators can also come from drivers, such as twl4030. So it's best to dumb down gpmc-smsc911x.c to not even care about the regulators. Regards, Tony The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linus Torvalds (1): Linux 3.4-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Thanks, pulled. Thanks. Feel free to start sending these as signed tags with the above in the tag description, so it's carried forward in the git history without any work for us. :-) OK will do. Tony -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc
On Thu, 5 Apr 2012, Tony Lindgren wrote: Yes it's the fixes branch I was talking about, thanks for updating it. Thanks -- sorry about the confusion... - Paul -- 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: OMAP3EVM not booting on l-o master
On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:37:42, Paul Walmsley wrote: I just booted the 'io_chain_devel_3.5' branch from git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no problems. Could you please try booting this branch on your OMAP3EVM? I am unable to fetch using git protocol, hence tried, http://git.pwsan.com/linux-2.6 http://git.pwsan.com/linux-2.6.git but giving error, fatal: http://git.pwsan.com/linux-2.6/info/refs not found: did you run git update-server-info on the server? The git trees on that server aren't exported by the HTTP server, so git protocol is the only access method on git.pwsan.com right now. Anyway, I've just posted that branch on git.kernel.org. Here's the gitweb URL: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary If you open it in your web browser, it shows http and https URLs for the tree that you should be able to pull from. You'll want the io_chain_devel_3.5 branch. - Paul -- 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 v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 04/05/2012 10:45 AM, Afzal Mohammed wrote:
[...]
+struct gpmc_irq{
+ unsignedirq;
+ u32 regval;
Are you using regval to indicate the bit-mask? If so, maybe call it
bitmask instead.
[...]
+static __devinit
+int gpmc_setup_cs_irq(struct gpmc *gpmc, struct gpmc_device_pdata *gdp,
+ struct gpmc_cs_data *cs, struct resource *res)
+{
+ int i, n, val;
+
+ for (i = 0, n = 0; i gpmc-num_irq; i++)
+ if (gpmc-irq[i].regval cs-irq_flags) {
+ res[n].start = res[n].end = gpmc-irq[i].irq;
+ res[n].flags = IORESOURCE_IRQ;
+
+ dev_info(gpmc-dev, resource irq %u for %s
+ (on CS %d) [bit: %x]\n, res[n].start,
+ gdp-name, cs-cs, __ffs(gpmc-irq[i].regval));
+
+ switch (gpmc-irq[i].regval) {
+ case GPMC_IRQ_WAIT0EDGEDETECTION:
+ case GPMC_IRQ_WAIT1EDGEDETECTION:
+ case GPMC_IRQ_WAIT2EDGEDETECTION:
+ case GPMC_IRQ_WAIT3EDGEDETECTION:
+ val = __ffs(gpmc-irq[i].regval);
+ val -= __ffs(GPMC_IRQ_WAIT0EDGEDETECTION);
+ gpmc_cs_configure(cs-cs,
+ GPMC_CONFIG_WAITPIN, val);
Why is the configuration of the wait pin done here? It is possible to
use the wait pin may be used without enabling the interrupt.
Where do you handle allocating the wait pins to ensure two devices don't
attempt to use the same one? Like how the CS are managed.
Also, where you you configure the polarity of the wait pins? I would
have thought it would make sense to have the wait pin configured as part
of the cs configuration.
+ }
+ n++;
+ }
+
+ return n;
+}
+
+static __devinit int gpmc_setup_device(struct gpmc_device_pdata *gdp,
+ struct gpmc_device *dev, struct gpmc *gpmc)
+{
+ int i, j, n;
+ struct gpmc_cs_data *cs;
+
+ for (i = 0, n = 0, cs = gdp-cs_data; i gdp-num_cs; i++, cs++)
+ n += hweight32(cs-irq_flags GPMC_IRQ_MASK);
+
+ n += gdp-num_cs;
+
+ dev-gpmc_res = devm_kzalloc(gpmc-dev, sizeof(*dev-gpmc_res) * n,
+ GFP_KERNEL);
+ if (dev-gpmc_res == NULL) {
+ dev_err(gpmc-dev, error: memory allocation\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0, j = 0, cs = gdp-cs_data; i gdp-num_cs; cs++, i++) {
+ dev-gpmc_res[j] = gpmc_setup_cs_mem(cs, gdp, gpmc);
+ if (dev-gpmc_res[j++].flags IORESOURCE_MEM)
+ j += gpmc_setup_cs_irq(gpmc, gdp, cs,
+ dev-gpmc_res + j);
+ else {
+ dev_err(gpmc-dev, error: setup for %s\n, gdp-name);
+ devm_kfree(gpmc-dev, dev-gpmc_res);
+ dev-gpmc_res = NULL;
+ dev-num_gpmc_res = 0;
+ return -EINVAL;
+ }
}
This section of code is not straight-forward to read. I see what you are
doing, but I am wondering if this could be improved.
First of all, returning a structure from a function is making this code
harder to read. Per the CodingStyle document in the kernel, it is
preferred for a function to return success or failure if the function is
an action, like a setup.
Secondly, do you need to pass cs, gdp and gpmc to gpmc_setup_cs_mem()?
It appears that gdp and gpmc are only used for prints. You could
probably avoid passing gdp and move the print to outside this function.
+ dev-num_gpmc_res = j;
- ret = request_irq(gpmc_irq,
- gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base);
- if (ret)
- pr_err(gpmc: irq-%d could not claim: err %d\n,
- gpmc_irq, ret);
- return ret;
+ dev-name = gdp-name;
+ dev-id = gdp-id;
+ dev-pdata = gdp-pdata;
+ dev-pdata_size = gdp-pdata_size;
+ dev-per_res = gdp-per_res;
+ dev-num_per_res = gdp-num_per_res;
+
+ return 0;
+}
+
+static __devinit
+struct platform_device *gpmc_create_device(struct gpmc_device *p,
+ struct gpmc *gpmc)
+{
+ int num = p-num_per_res + p-num_gpmc_res;
+ struct resource *res;
+ struct platform_device *pdev;
+
+ res = devm_kzalloc(gpmc-dev, sizeof(struct resource) * num,
+ GFP_KERNEL);
+ if (!res) {
+ dev_err(gpmc-dev, error: allocating memory\n);
+ return NULL;
+ }
+
+ memcpy((char
Re: [PATCH v3 1/9] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 04/05/2012 03:21 PM, Jon Hunter wrote:
Hi Afzal,
On 04/05/2012 10:45 AM, Afzal Mohammed wrote:
[...]
+struct gpmc_irq {
+ unsigned irq;
+ u32 regval;
Are you using regval to indicate the bit-mask? If so, maybe call it
bitmask instead.
[...]
+static __devinit
+int gpmc_setup_cs_irq(struct gpmc *gpmc, struct gpmc_device_pdata *gdp,
+ struct gpmc_cs_data *cs, struct resource *res)
+{
+ int i, n, val;
+
+ for (i = 0, n = 0; i gpmc-num_irq; i++)
+ if (gpmc-irq[i].regval cs-irq_flags) {
+ res[n].start = res[n].end = gpmc-irq[i].irq;
+ res[n].flags = IORESOURCE_IRQ;
+
+ dev_info(gpmc-dev, resource irq %u for %s
+ (on CS %d) [bit: %x]\n, res[n].start,
+ gdp-name, cs-cs, __ffs(gpmc-irq[i].regval));
+
+ switch (gpmc-irq[i].regval) {
+ case GPMC_IRQ_WAIT0EDGEDETECTION:
+ case GPMC_IRQ_WAIT1EDGEDETECTION:
+ case GPMC_IRQ_WAIT2EDGEDETECTION:
+ case GPMC_IRQ_WAIT3EDGEDETECTION:
+ val = __ffs(gpmc-irq[i].regval);
+ val -= __ffs(GPMC_IRQ_WAIT0EDGEDETECTION);
+ gpmc_cs_configure(cs-cs,
+ GPMC_CONFIG_WAITPIN, val);
Why is the configuration of the wait pin done here? It is possible to
use the wait pin may be used without enabling the interrupt.
Sorry very bad english here on my part. I meant it is possible to use a
wait pin, without enabling the interrupt.
Where do you handle allocating the wait pins to ensure two devices don't
attempt to use the same one? Like how the CS are managed.
Also, where you you configure the polarity of the wait pins? I would
have thought it would make sense to have the wait pin configured as part
of the cs configuration.
+ }
+ n++;
+ }
+
+ return n;
+}
+
+static __devinit int gpmc_setup_device(struct gpmc_device_pdata *gdp,
+ struct gpmc_device *dev, struct gpmc *gpmc)
+{
+ int i, j, n;
+ struct gpmc_cs_data *cs;
+
+ for (i = 0, n = 0, cs = gdp-cs_data; i gdp-num_cs; i++, cs++)
+ n += hweight32(cs-irq_flags GPMC_IRQ_MASK);
+
+ n += gdp-num_cs;
+
+ dev-gpmc_res = devm_kzalloc(gpmc-dev, sizeof(*dev-gpmc_res) * n,
+ GFP_KERNEL);
+ if (dev-gpmc_res == NULL) {
+ dev_err(gpmc-dev, error: memory allocation\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0, j = 0, cs = gdp-cs_data; i gdp-num_cs; cs++, i++) {
+ dev-gpmc_res[j] = gpmc_setup_cs_mem(cs, gdp, gpmc);
+ if (dev-gpmc_res[j++].flags IORESOURCE_MEM)
+ j += gpmc_setup_cs_irq(gpmc, gdp, cs,
+ dev-gpmc_res + j);
+ else {
+ dev_err(gpmc-dev, error: setup for %s\n, gdp-name);
+ devm_kfree(gpmc-dev, dev-gpmc_res);
+ dev-gpmc_res = NULL;
+ dev-num_gpmc_res = 0;
+ return -EINVAL;
+ }
}
This section of code is not straight-forward to read. I see what you are
doing, but I am wondering if this could be improved.
First of all, returning a structure from a function is making this code
harder to read. Per the CodingStyle document in the kernel, it is
preferred for a function to return success or failure if the function is
an action, like a setup.
Secondly, do you need to pass cs, gdp and gpmc to gpmc_setup_cs_mem()?
It appears that gdp and gpmc are only used for prints. You could
probably avoid passing gdp and move the print to outside this function.
+ dev-num_gpmc_res = j;
- ret = request_irq(gpmc_irq,
- gpmc_handle_irq, IRQF_SHARED, gpmc, gpmc_base);
- if (ret)
- pr_err(gpmc: irq-%d could not claim: err %d\n,
- gpmc_irq, ret);
- return ret;
+ dev-name = gdp-name;
+ dev-id = gdp-id;
+ dev-pdata = gdp-pdata;
+ dev-pdata_size = gdp-pdata_size;
+ dev-per_res = gdp-per_res;
+ dev-num_per_res = gdp-num_per_res;
+
+ return 0;
+}
+
+static __devinit
+struct platform_device *gpmc_create_device(struct gpmc_device *p,
+ struct gpmc *gpmc)
+{
+ int num = p-num_per_res + p-num_gpmc_res;
+ struct resource *res;
+ struct platform_device *pdev;
+
+ res = devm_kzalloc(gpmc-dev, sizeof(struct resource) * num,
+ GFP_KERNEL);
+ if (!res) {
+ dev_err(gpmc-dev, error: allocating memory\n);
+ return NULL;
+ }
+
+ memcpy((char *)res, (const char *) p-gpmc_res,
+ sizeof(struct resource) * p-num_gpmc_res);
+ memcpy((char *)(res + p-num_gpmc_res), (const char *)p-per_res,
+ sizeof(struct resource) * p-num_per_res);
+
+ pdev = platform_device_register_resndata(gpmc-dev, p-name, p-id,
+ res, num, p-pdata, p-pdata_size);
+
+ devm_kfree(gpmc-dev, res);
+
+ return pdev;
}
-postcore_initcall(gpmc_init);
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
- u8 cs;
+ int i;
+ u32 regval;
+ struct gpmc *gpmc = dev;
- /* check cs to invoke the irq */
- cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1)) CS_NUM_SHIFT) 0x7;
- if (OMAP_GPMC_IRQ_BASE+cs= OMAP_GPMC_IRQ_END)
- generic_handle_irq(OMAP_GPMC_IRQ_BASE+cs);
+ regval = gpmc_read_reg(GPMC_IRQSTATUS);
+
+
+ for (i = 0; i gpmc-num_irq; i++)
+ if (regval gpmc-irq[i].regval)
+ generic_handle_irq(gpmc-irq[i].irq);
+ gpmc_write_reg(GPMC_IRQSTATUS, regval);
return IRQ_HANDLED;
}
+static int gpmc_irq_endis(struct irq_data *p, bool endis)
+{
+ struct gpmc *gpmc = irq_data_get_irq_chip_data(p);
+ int i;
+ u32 regval;
+
+ for (i = 0; i gpmc-num_irq; i++)
+ if (p-irq == gpmc-irq[i].irq) {
+ regval =
[PATCH] ARM: OMAP2+: PRM: fix compile for OMAP4-only build
For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers to detect incorrect usage. However, several unrelated omap3 PRM functions have made it inside the #else clause of the #ifdef wrapping the omap2_prm stubs, causing them to disappear on OMAP4-only builds. This was unnoticed until the IO chain support was added and introduced a new function in this section which is referenced by omap_hwmod.c: /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain': /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-fungiction-declaration] Fix by using the #ifdef to only wrap the omap2_prm functions that need stubs on OMAP4-only builds. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch applies on top your io_chain_devel_3.5 branch. arch/arm/mach-omap2/prm2xxx_3xxx.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-omap2/prm2xxx_3xxx.h index 1ba3d65..a8c946f 100644 --- a/arch/arm/mach-omap2/prm2xxx_3xxx.h +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h @@ -303,6 +303,8 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift); extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift); extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 st_shift); +#endif /* CONFIG_ARCH_OMAP4 */ + /* OMAP3-specific VP functions */ u32 omap3_prm_vp_check_txdone(u8 vp_id); void omap3_prm_vp_clear_txdone(u8 vp_id); @@ -323,8 +325,6 @@ extern void omap3xxx_prm_ocp_barrier(void); extern void omap3xxx_prm_save_and_clear_irqen(u32 *saved_mask); extern void omap3xxx_prm_restore_irqen(u32 *saved_mask); -#endif /* CONFIG_ARCH_OMAP4 */ - #endif /* -- 1.7.9.2 -- 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: OMAP3EVM not booting on l-o master
Paul Walmsley p...@pwsan.com writes: On Thu, 5 Apr 2012, Paul Walmsley wrote: I just rebased this series on top of v3.4-rc1 and built each patch in it successfully, so it sounds like there's some bisection-specific build problem? Okay, a quick update. Just tried with a different .config, and can reproduce the following build problem with patch 2 of the IO wakeup series, in code that is later removed by patch 6: arch/arm/mach-omap2/pm34xx.c: In function 'omap_sram_idle': arch/arm/mach-omap2/pm34xx.c:281:4: error: implicit declaration of function 'omap3_reconfigure_io_chain' That's my mistake and I will correct it here and send a new pull request, once we figure out what's going on with your boot hang. I notcied this problem too when building an OMAP4-only .config and just sent a patch: [PATCH] ARM: OMAP2+: PRM: fix compile for OMAP4-only build Kevin -- 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
Hiremath, Vaibhav hvaib...@ti.com writes: On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote: There seems to be limitation for ARM architecture, it is restricted by sched_clock implementation present in arch/arm/kernel/sched_clock.c. Natively, clocksource framework does support change in rate/frequency for registered timer, using, Any kind of switching of timing sources introduces loss of time issues by the mere fact that you can't instantly know the counter values of both timing sources at precisely the same instant - because CPUs can only do one thing at a time. So any kind of repeated dynamic switching _will_ result in a gradual loss of time - which will be indeterminant as it depends on the frequency of the switching and the relative delta between the two. To put it another way - it is not possible to maintain high precision and accuracy while dynamically switching your timing sources. I'm not about to lift the restriction that there's only one source for sched_clock() just for OMAP. That'd require a lot of additional code - it's not just about adjusting the multiplier and shift, you also have to correct the returned ns value as well, which means synchronizing against two counters. (And as I've pointed out above, that's impossible to do accurately.) Thanks a ton Russell for confirming on this, I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. So this means, we have to use compile time option, as existing implementation in arch/arm/mach-omap2/timer.c. Not exactly. A compile time option isn't (yet) the only option. Russell points out the various problems with dynamic switching of clocksources, which is true. However, we're not trying to dynamically switch clocksources. What we need is only one-time selection at boot based on presence (or not) of various timers. IOW, we still only ever need to call setup_sched_clock() once based on which HW timers are available. Why not just delay the setup_sched_clock() until the clocksource is decided? Kevin -- 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+: PRM: fix compile for OMAP4-only build
On Thu, 5 Apr 2012, Kevin Hilman wrote: For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers to detect incorrect usage. However, several unrelated omap3 PRM functions have made it inside the #else clause of the #ifdef wrapping the omap2_prm stubs, causing them to disappear on OMAP4-only builds. This was unnoticed until the IO chain support was added and introduced a new function in this section which is referenced by omap_hwmod.c: /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain': /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-fungiction-declaration] Fix by using the #ifdef to only wrap the omap2_prm functions that need stubs on OMAP4-only builds. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch applies on top your io_chain_devel_3.5 branch. Thanks, Tony reported this too. Any objections to me rolling this into the offending patch? - Paul -- 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] mmc: omap_hsmmc: set dto to 14 for all devices
* Chris Ball c...@laptop.org [120315 20:26]: Hi Paul, On Mon, Mar 12 2012, Paul Walmsley wrote: I don't think this is the right fix. Steve Sakoman and I discussed this a few months ago -- we did some debugging and Steve observed the timeouts on multiple block writes (0x19): [...] So perhaps something like the following patch instead? Unfortunately, I don't have one of these crappy SD cards as far as I know, so I can't really test it. - Paul From: Paul Walmsley p...@pwsan.com Date: Mon, 12 Mar 2012 04:46:29 -0600 Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards Several people have noticed that crappy SD cards take much longer to complete multiple block writes than the 300ms that Linux specifies. Try to work around this by using a three second write timeout instead. insert Chase's patch description here Not-yet-signed-off-by: Paul Walmsley p...@pwsan.com Sounds like a good idea -- want to send a signed-off patch for this? This seems like the right fix to me too. Works on my pandaboard es and some random card that produces I/O errors without this. Tested-by: Tony Lindgren t...@atomide.com -- 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] mmc: omap4: hsmmc: fix module re-insertion
Chris, * Balaji T K balaj...@ti.com [120308 07:27]: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Any news on getting this fix merged during the -rc cycle? This is pretty important fix for anybody wanting to reload the omap_hsmmc.ko module.. Regards, Tony Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e550170..102425c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1741,8 +1741,6 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1766,7 +1764,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch= -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-next_data.cookie = 1; -- 1.7.0.4 -- 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 -- 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] mmc: omap4: hsmmc: fix module re-insertion
Hi Tony, On Thu, Apr 05 2012, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [120308 07:27]: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Any news on getting this fix merged during the -rc cycle? This is pretty important fix for anybody wanting to reload the omap_hsmmc.ko module.. It's in my fixes branch, planning on sending that to Linus tomorrow. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] mmc: omap4: hsmmc: fix module re-insertion
* Chris Ball c...@laptop.org [120405 15:17]: Hi Tony, On Thu, Apr 05 2012, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [120308 07:27]: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Any news on getting this fix merged during the -rc cycle? This is pretty important fix for anybody wanting to reload the omap_hsmmc.ko module.. It's in my fixes branch, planning on sending that to Linus tomorrow. OK thanks for the update. Tony -- 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] mmc: omap_hsmmc: set dto to 14 for all devices
Hi, On Thu, Apr 05 2012, Tony Lindgren wrote: * Chris Ball c...@laptop.org [120315 20:26]: Hi Paul, On Mon, Mar 12 2012, Paul Walmsley wrote: I don't think this is the right fix. Steve Sakoman and I discussed this a few months ago -- we did some debugging and Steve observed the timeouts on multiple block writes (0x19): [...] So perhaps something like the following patch instead? Unfortunately, I don't have one of these crappy SD cards as far as I know, so I can't really test it. - Paul From: Paul Walmsley p...@pwsan.com Date: Mon, 12 Mar 2012 04:46:29 -0600 Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards Several people have noticed that crappy SD cards take much longer to complete multiple block writes than the 300ms that Linux specifies. Try to work around this by using a three second write timeout instead. insert Chase's patch description here Not-yet-signed-off-by: Paul Walmsley p...@pwsan.com Sounds like a good idea -- want to send a signed-off patch for this? This seems like the right fix to me too. Works on my pandaboard es and some random card that produces I/O errors without this. Tested-by: Tony Lindgren t...@atomide.com Thanks. Paul, just waiting for your Signed-off-by. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc (misc_devel_3.4 patches dropped)
Hi Olof, * Paul Walmsley p...@pwsan.com [120405 02:45]: Hi Tony, The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-fixes-a2-for-3.4rc for you to fetch changes up to a9dd31b744a033b4324c93cec4ecb4c74061e2cf: Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_a2_3.4rc' and 'powerdomain_fixes_a_3.4rc' into omap-fixes-a2-for-3.4rc-branch (2012-04-05 03:00:22 -0600) This version is intended to merge cleanly into your 'fixes' branch. If not too late for this round of fixes, can you please pull this set of fixes directly from Paul? I was planning on including this into my fixes yesterday, but two patches had to be dropped that Paul did last night. This one already has the signed tag ;) Regards, Tony OMAP clock, powerdomain, clockdomain, and hwmod fixes intended for the early v3.4-rc series. Also contains an HSMMC integration refinement of an earlier hardware bug workaround. ARM: OMAP3: clock data: fill in some missing clockdomains ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP: clock: fix race in disable all clocks ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data Ameya Palande (1): ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL Govindraj.R (1): ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules Grazvydas Ignotas (2): ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks Ilya Yanok (1): ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases Nishanth Menon (1): ARM: OMAP: clock: fix race in disable all clocks Paul Walmsley (4): ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks ARM: OMAP3: clock data: fill in some missing clockdomains Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_a2_3.4rc' and 'powerdomain_fixes_a_3.4rc' into omap-fixes-a2-for-3.4rc-branch Rajendra Nayak (3): ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock ARM: OMAP2+: hwmod: Restore sysc after a reset ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status Santosh Shilimkar (1): ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch() Vaibhav Hiremath (1): ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions arch/arm/mach-omap2/clock3xxx_data.c | 18 -- arch/arm/mach-omap2/clock44xx_data.c |5 +- arch/arm/mach-omap2/clockdomains44xx_data.c |2 +- arch/arm/mach-omap2/hsmmc.c |7 ++ arch/arm/mach-omap2/omap_hwmod.c | 88 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 arch/arm/mach-omap2/powerdomain.c|8 ++- arch/arm/plat-omap/clock.c |5 +- arch/arm/plat-omap/include/plat/omap_hwmod.h | 12 ++-- 9 files changed, 105 insertions(+), 68 deletions(-) -- 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+: PRM: fix compile for OMAP4-only build
* Paul Walmsley p...@pwsan.com [120405 14:36]: On Thu, 5 Apr 2012, Kevin Hilman wrote: For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers to detect incorrect usage. However, several unrelated omap3 PRM functions have made it inside the #else clause of the #ifdef wrapping the omap2_prm stubs, causing them to disappear on OMAP4-only builds. This was unnoticed until the IO chain support was added and introduced a new function in this section which is referenced by omap_hwmod.c: /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain': /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-fungiction-declaration] Fix by using the #ifdef to only wrap the omap2_prm functions that need stubs on OMAP4-only builds. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch applies on top your io_chain_devel_3.5 branch. Thanks, Tony reported this too. Any objections to me rolling this into the offending patch? I heard of this first from Kevin before I started hitting it with my compiles.. Anyways, can you also check that we don't have a similar issue with omap44xx_prm_reconfigure_io_chain for omap3 only builds? Regards, Tony -- 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+: PRM: fix compile for OMAP4-only build
On Thu, 5 Apr 2012, Tony Lindgren wrote: I heard of this first from Kevin before I started hitting it with my compiles.. Okay. Anyways, can you also check that we don't have a similar issue with omap44xx_prm_reconfigure_io_chain for omap3 only builds? Will do. Clearly I need to be running the full build-test suite on all of my branches, as I was doing before the arm-soc transition. Future pull requests from me will be test-built with a large variety of kernel .configs, and will contain a 'size' report for each generated binary in the pull request. - Paul -- 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] mmc: omap_hsmmc: set dto to 14 for all devices
Hi Chris, I'm really sorry for the long delay! On Thu, 5 Apr 2012, Chris Ball wrote: Thanks. Paul, just waiting for your Signed-off-by. Signed-off-by: Paul Walmsley p...@pwsan.com - Paul -- 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] mmc: omap_hsmmc: set dto to 14 for all devices
Hi Paul, On Thu, Apr 05 2012, Paul Walmsley wrote: I'm really sorry for the long delay! On Thu, 5 Apr 2012, Chris Ball wrote: Thanks. Paul, just waiting for your Signed-off-by. Signed-off-by: Paul Walmsley p...@pwsan.com Thanks, no problem! Pushed to mmc-next for 3.4. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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+: PRM: fix compile for OMAP4-only build
Paul Walmsley p...@pwsan.com writes: On Thu, 5 Apr 2012, Kevin Hilman wrote: For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers to detect incorrect usage. However, several unrelated omap3 PRM functions have made it inside the #else clause of the #ifdef wrapping the omap2_prm stubs, causing them to disappear on OMAP4-only builds. This was unnoticed until the IO chain support was added and introduced a new function in this section which is referenced by omap_hwmod.c: /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain': /work/kernel/omap/dev/arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-fungiction-declaration] Fix by using the #ifdef to only wrap the omap2_prm functions that need stubs on OMAP4-only builds. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch applies on top your io_chain_devel_3.5 branch. Thanks, Tony reported this too. Any objections to me rolling this into the offending patch? No objections. Kevin -- 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: Suspend broken on 3.3?
On Wed, 4 Apr 2012, Raja, Govindraj wrote: On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 2 Apr 2012, Raja, Govindraj wrote: As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Haven't been following this thread closely, but this doesn't seem right. Why would changing the UART driver's ability to wake from suspend via the sysfs file prevent the driver from using hardware wakeups to wake from dynamic idle? IIUC wakeup capability is needed in suspend path or in cpu idle path. once uart wakeup capability is disabled from sysfs the Module level wakeup from PM_WKEN1 reg on omap3 and pad wakeup from pin mux data given will be disabled.. As far as I know, that sysfs wakeup file is not meant to disable all module-level wakeup. Kevin can correct me if I'm wrong, but I think it's only supposed to control wakeup from suspend. So in my opinion, that sysfs file should not affect dynamic module-level, or I/O ring wakeup at all. If it is intended to affect dynamic idle wakeup, then we also will need code to prevent the UART from disabling its clocks when the sysfs wakeup file is set to disabled. So after we enter suspend and wakeup from suspend using keypad press, now through pm workqueue the MPU enters retention and uart module level wakeups disabled at this point console becomes slower to respond. Now enabling wakeups from sysfs enter suspend/resume to enable wakeups and once we come back from wakeup console response is better. So disabling uart module level wake up and allowing MPU to enter retention is making console slow. - Paul -- 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] ARM: OMAP: clock, powerdomain, clockdomain, hwmod fixes for early v3.4-rc (misc_devel_3.4 patches dropped)
On Thu, Apr 5, 2012 at 3:46 PM, Tony Lindgren t...@atomide.com wrote: Hi Olof, * Paul Walmsley p...@pwsan.com [120405 02:45]: Hi Tony, The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-fixes-a2-for-3.4rc for you to fetch changes up to a9dd31b744a033b4324c93cec4ecb4c74061e2cf: Merge branches 'clock_fixes_3.4rc', 'clockdomain_fixes_3.4rc', 'hsmmc_erratum_2_1_1_128_refine_3.4rc1', 'hwmod_data_fixes_a_3.4rc', 'hwmod_fixes_a2_3.4rc' and 'powerdomain_fixes_a_3.4rc' into omap-fixes-a2-for-3.4rc-branch (2012-04-05 03:00:22 -0600) This version is intended to merge cleanly into your 'fixes' branch. If not too late for this round of fixes, can you please pull this set of fixes directly from Paul? I was planning on including this into my fixes yesterday, but two patches had to be dropped that Paul did last night. This one already has the signed tag ;) Thanks, pulled. Paul, thanks for using a signed tag with an overview. There's no need to list the changes in the signed tag though -- git pull --log will include them in the merge commit instead. In general Linus tends to not like seeing redundant info in the tag text that can be derived from the branch contents instead. -Olof -- 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: OMAP3EVM not booting on l-o master
Hi Tony, On Thu, Apr 05, 2012 at 22:46:53, Tony Lindgren wrote: What happens if you disable CONFIG_OMAP_MUX? Then it boots properly. 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: OMAP3EVM not booting on l-o master
Hi Paul, On Fri, Apr 06, 2012 at 01:22:20, Paul Walmsley wrote: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary If you open it in your web browser, it shows http and https URLs for the tree that you should be able to pull from. You'll want the io_chain_devel_3.5 branch. OMAP3EVM does not boot with this branch, hung at the same point. 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Apr 06, 2012 at 03:03:01, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote:
On Thu, Apr 05, 2012 at 09:36:00AM +, Hiremath, Vaibhav wrote:
There seems to be limitation for ARM architecture, it is restricted by
sched_clock implementation present in arch/arm/kernel/sched_clock.c.
Natively, clocksource framework does support change in rate/frequency for
registered timer, using,
Any kind of switching of timing sources introduces loss of time issues
by the mere fact that you can't instantly know the counter values of
both timing sources at precisely the same instant - because CPUs can
only do one thing at a time. So any kind of repeated dynamic switching
_will_ result in a gradual loss of time - which will be indeterminant
as it depends on the frequency of the switching and the relative delta
between the two.
To put it another way - it is not possible to maintain high precision
and accuracy while dynamically switching your timing sources.
I'm not about to lift the restriction that there's only one source for
sched_clock() just for OMAP. That'd require a lot of additional code -
it's not just about adjusting the multiplier and shift, you also have to
correct the returned ns value as well, which means synchronizing against
two counters. (And as I've pointed out above, that's impossible to do
accurately.)
Thanks a ton Russell for confirming on this,
I understand, we also have to adjust ns value and such confirmation is what
exactly I was looking for.
So this means, we have to use compile time option, as existing
implementation in arch/arm/mach-omap2/timer.c.
Not exactly. A compile time option isn't (yet) the only option.
Russell points out the various problems with dynamic switching of
clocksources, which is true. However, we're not trying to dynamically
switch clocksources.
What we need is only one-time selection at boot based on presence (or
not) of various timers. IOW, we still only ever need to call
setup_sched_clock() once based on which HW timers are available.
Why not just delay the setup_sched_clock() until the clocksource is
decided?
Kevin,
I liked Santosh's idea in using command line argument clocksource= and
make decision based on this. I have implemented it and tried it on both
OMAP3EVM and beaglebone and it works great.
I have introduced something like this in mach-omap2/timer.c,
static int __init omap2_override_clocksource(char* str)
{
if (!str)
return 0;
/*
* For OMAP architecture, we only have two options
*- sync_32k (default)
*- gp timer
*/
if (!strcmp(str, gp timer))
use_gptimer_clksrc = true;
return 0;
}
early_param(clocksource, omap2_override_clocksource);
It solves all issues what we have been trying address.
Thanks,
Vaibhav
Kevin
--
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
