Re: [GIT PULL] few omap fixups for v3.5 merge window
On Fri, May 11, 2012 at 12:22 PM, Tony Lindgren wrote: > Hi Arnd & Olof, > > Here are the fixes needed for the regressions caused by > omap-cleanup-sparse-for-v3.5. I suggest pulling this into > arm-soc/omap/cleanup-sparse where the issues got introduced. > > Regards, > > Tony > > > The following changes since commit 09f45b83109cb8e23a06d5efb1096a08a9545974: > > Merge tag 'omap-cleanup-a2-for-3.5' of > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into > cleanup-sparse (2012-04-18 10:09:26 -0700) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > fixes-for-cleanup Thanks, pulled. -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: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul, On Thu, May 10, 2012 at 11:33:44, Mohammed, Afzal wrote: > Hi Paul, > > On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote: > > > > Major reason was that there are some boards that rely on bootloader > > > settings, eg. kernel does not do any setting for smsc911x. I did not > > > want to break those, at least it causes problem with omap3evm, see below > > > > But this is the whole point. The Linux GPMC driver and integration code > > should be setting up the GPMC registers based on board file and/or DT > > data, before the kernel touches any GPMC devices. > > > > We don't want to rely on the bootloader settings unless we absolutely have > > no other choice. Otherwise, the stability of the kernel could easily be > > impacted by the bootloader's GPMC timings and other register settings, and > > we want to minimize those potential sources of variation. > > > > So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here, > > which doesn't sound like the case so far, we need to understand exactly > > why this is so. > > There are 14 out of 20 boards partially or fully relying on bootloader > settings. I will try to do configuration for smsc911x in Kernel itself, > this is the only one that can be tested from my side (on omap3evm), but > there are other peripherals like NOR, quaduart, onenand-flash (different > from omap-onenand), then smc91x (timings are not set from kernel for > sdp boards), these would affect 7 boards of both omap2 & omap3. To > get configuration done from Kernel properly without having these boards > is too tough for me. > > So I request you to keep HWMOD_INIT_NO_RESET (I will add configuration > for smsc911x), please let me know your comments. ping Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Fri, 11 May 2012 17:30:48 -0700, Kevin Hilman wrote: > Hi Grant, > > Here's the final round of GPIO cleanups for v3.5. This branch is based > on my for_3.5/fixes/gpio branch you just pulled. > > Kevin > > > The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509: > > gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10 > 07:16:15 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.5/gpio/cleanup Applied, thanks. g. > > for you to fetch changes up to 1b1287032df3a69d3ef9a486b444f4ffcca50d01: > > gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 > -0700) > > > Tarun Kanti DebBarma (8): > gpio/omap: remove virtual_irq_start variable > gpio/omap: remove saved_fallingdetect, saved_risingdetect > gpio/omap: remove suspend_wakeup field from struct gpio_bank > gpio/omap: remove saved_wakeup field from struct gpio_bank > gpio/omap: remove retrigger variable in gpio_irq_handler > gpio/omap: remove suspend/resume callbacks > gpio/omap: remove cpu_is_omap() checks from *_runtime_resume() > gpio/omap: fix missing check in *_runtime_suspend() > > arch/arm/mach-omap1/gpio15xx.c |2 - > arch/arm/mach-omap1/gpio16xx.c |5 -- > arch/arm/mach-omap1/gpio7xx.c |7 --- > arch/arm/mach-omap2/gpio.c |3 +- > arch/arm/plat-omap/include/plat/gpio.h |3 +- > drivers/gpio/gpio-omap.c | 103 > +++- > 6 files changed, 27 insertions(+), 96 deletions(-) -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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] gpio/omap: cleanups for v3.5
Hi Grant, Here's the final round of GPIO cleanups for v3.5. This branch is based on my for_3.5/fixes/gpio branch you just pulled. Kevin The following changes since commit 6edd94db250038c8fdf176f23ca4017d2f312509: gpio/omap: fix incorrect initialization of omap_gpio_mod_init (2012-05-10 07:16:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/gpio/cleanup for you to fetch changes up to 1b1287032df3a69d3ef9a486b444f4ffcca50d01: gpio/omap: fix missing check in *_runtime_suspend() (2012-05-11 17:08:40 -0700) Tarun Kanti DebBarma (8): gpio/omap: remove virtual_irq_start variable gpio/omap: remove saved_fallingdetect, saved_risingdetect gpio/omap: remove suspend_wakeup field from struct gpio_bank gpio/omap: remove saved_wakeup field from struct gpio_bank gpio/omap: remove retrigger variable in gpio_irq_handler gpio/omap: remove suspend/resume callbacks gpio/omap: remove cpu_is_omap() checks from *_runtime_resume() gpio/omap: fix missing check in *_runtime_suspend() arch/arm/mach-omap1/gpio15xx.c |2 - arch/arm/mach-omap1/gpio16xx.c |5 -- arch/arm/mach-omap1/gpio7xx.c |7 --- arch/arm/mach-omap2/gpio.c |3 +- arch/arm/plat-omap/include/plat/gpio.h |3 +- drivers/gpio/gpio-omap.c | 103 +++- 6 files changed, 27 insertions(+), 96 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 v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
On 05/11/2012 07:51 AM, Tomi Valkeinen wrote: On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote: Sorry, some hunks where missing in the patch that I submitted yesterday. I just pushed a branch containing the whole most up-to-date series here: git://gitorious.org/omap-audio/linux-audio.git ricardon/topic/dss_audio-for-tomi This includes the implementation of the DSS audio interface for HDMI covering the improved locking strategy [1][2], plus the missing hunks in my yesterday's patch, plus handling of mode changes you pointed out. Please let me know if you want me to resubmit the whole patch series so that you can comment if you need to. Thanks, I think this is fine. I had to rebase your branch as you had some extra patches there also. There were also a few conflicts with latest dss stuff, but nothing serious. I pushed the branch with latest dss and your branch to: git://gitorious.org/linux-omap-dss2/linux.git test With a quick test video works ok, but I didn't test audio. Thanks for taking the patches! In your branch, the audio part would not build with audio enabled as your branch does not have the ALSA CEA-861 definitions patch [1]. The platform devices for the ASoC HDMI drivers[2] are also missing. I put these patches on top of your test branch and audio works well. [1] and [2] will come from Takashi's and Tony's branches. BR, Ricardo [1]http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66600.html [2]http://www.spinics.net/lists/linux-omap/msg68834.html Tomi -- 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: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 11:38 AM, Will Deacon wrote: > On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: >> Can you send me your .config? > > Sent off-list. > >> At the same time, maybe just try "make omap2plus_defconfig" and enable >> the OMAP3 debug devices config. That's all I am doing. > > Excellent, that works for me. Once we've worked out the problem with my > .config you can have my tested-by. Great! I have been looking at your .config, but I have not been able to figure out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. 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: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 05/11/2012 03:06 PM, Jassi Brar wrote:
> On 12 May 2012 00:58, Stephen Warren wrote:
>> On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
>>> Do we also need to somehow tag these signals for the client to
>>> differentiate between TX and RX channel ?
>>
>> Yes, the client's DT binding would certainly need to describe how many
>> DMA request signals its HW generates, and give a unique ID to each. The
>> driver would need to request a DMA channel for a specific one of its DMA
>> requests.
>>
> Did I read "give a unique ID to each" correctly ?
It'd be unique relative to that individual device or DT node, not at any
larger scope.
> Could you please take some time out to jot down an example of how a
> typical client's dma specifier should look.
With this proposal, I'm not sure that the client DT node would need any
DMA information at all, at least nothing that identifies which DMA
controllers, channels, or requests are required to service this
node/device's DMA requests - that routing information is all represented
in the DMA controller itself.
(I think Arnd made the following point earlier in this thread):
If you did need to put any other information in DT, then that probably
would go in the DMA client node, since it'd presumably be the same
irrespective of which DMA controller got used. However, that information
presumably wouldn't be needed in DT at all, since the driver would know
it, since it'd be a facet of the HW.
Note: I'm thinking things like DMA physical address (presumably an
offset from the reg property), DMA access size (presumably a fixed
property of the HW), DMA burst size (presumably a property of the HW,
although at least some HW can be programmed to raise the DMA request
signal with a varying number of FIFO entries free, so not fixed), etc.
> FWIW, I think I can live with what you propose. Let us go for the kill.
--
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 Kevin, On Wed, 2 May 2012, Kevin Hilman wrote: > >From 22726db6fc514cc5110db43fdf05d5afda8e4a59 Mon Sep 17 00:00:00 2001 > From: Kevin Hilman > Date: Tue, 1 May 2012 07:06:42 -0700 > Subject: [PATCH] ARM: OMAP3: PM: leave PRCM interrupts disabled until > explicitly enabled. > > By default, request_irq() will auto-enable the requested IRQ. > > For PRCM interrupts, we may want to avoid that until the PM core code > is fully ready to handle the interrupts. This is particularily true > for IO pad interrupts on OMAP3, which are shared between the hwmod > core and the PRM core. > > In order to avoid PRCM IO-chain interrupts until the PM core is ready > to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain > interrupt, which means it will remain disabled after request_irq(). > > Then, explicitly enable the PRCM interrupts after the request_irq() in > the PM core (but not in the hwmod core.) > > Special thanks to Tero Kristo for suggesting to isolate the fix to > only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts. > > Tested-by: Afzal Mohammed > Acked-by: Tero Kristo > Cc: Paul Walmsley > Signed-off-by: Kevin Hilman Acked-by: Paul Walmsley If for some reason it doesn't get in for 3.5, let me know and I'll queue with the other IO chain patches for 3.6 as we discussed. - 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-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
"Hiremath, Vaibhav" writes: > On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote: >> "Hiremath, Vaibhav" writes: >> >> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote: >> >> Vaibhav Hiremath writes: >> >> >> >> > The function __omap2_set_globals() can be common across all >> >> > platforms/architectures, even in case of omap4, internally it >> >> > calls same set of functions as in __omap2_set_globals() function >> >> > (except for sdrc). >> >> >> >> OK so far. >> >> >> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, >> >> > so that we can reuse same function across omap2/3/4... >> >> >> >> But what happens when a single kernel is built that has support for an >> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? >> >> >> > >> > As such Nothing...I looking into this direction while implementing. >> > >> > In that case, sdrc.c file will be compiled in and execution will jump to >> > omap2_set_globals_sdrc(). But inside this function, we are already >> > checking >> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then >> > use >> > it. >> > >> > And function omap2_sdrc_init() is also depends on machine, so in case of >> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it >> > will. >> >> Then why bother with the #ifdef at all? >> >> If it already safe to call on all SoCs, just get rid of the #ifdef all >> together. >> > > Kevin, > > sdrc.o target gets built only as "omap-2-3-common", this will not get built > for omap4, am33xx, ti81xx, etc... OK, I see what you mean now. I was confusing because this patch doesn't touch sdrc.c, or the Makefile for sdrc.c. > So in order to avoid build break, you have to have some mechanism, and > that's where we need to create config option dependent on platform. That being the case, for readability sake, I suggest you change the Makefile to use the new config option for sdrc.c as well. 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Stephen Warren [120511 14:08]: > On 05/11/2012 01:51 PM, Tony Lindgren wrote: > > * Stephen Warren [120511 12:21]: > >> > >> The mapping of GPIO to pinctrl pins would presumably be driven solely by > >> the HW design of the pin controller and GPIO, and not by the mux > >> selection in the pin controller (otherwise, I'd argue this isn't a > >> simple case that should be handled by pinctrl-simple). > >> > >> As such, I'd expect some properties/table at the top-level of the pin > >> controller object to describe the GPIO mapping. In turn, that implies > >> that the individual per-pin mux-selection/configuration nodes don't need > >> to describe any GPIO-related information. > > > > Yes good point. I agree it's a HW design issue, and could be in the > > properties > > for the pin controller object. > > > > Just to summarize, the things to consider with the GPIO to mux mapping are: > > > > 1. Having this table as static data in the driver is is not a nice > >solution as it seems that we'd currently need six mapping tables for > >omap2+ alone. > > > > 2. This table is not needed for most of the (hundreds of) pins, it's > >only needed for a few selected pins, let's say ten or so on an average > >device. So there's no need to stuff the kernel with information about > >the unused GPIO pins. > > > > It seems that the conclusion here is that we don't need to worry about > > GPIOs in the pinctrl-simple binding for now, and it can be added later > > without having to change the basic binding. > > The one thing I wanted to resolve here wasn't so much the binding for > GPIO interaction here, but the following comment: > > You wrote: > > I wrote: > >> From a binding perspective, I don't see why you'd want to allow two cases: > >> > >> 1) One node with multiple entries in pinctrl-simple,cells > >> 2) Multiple nodes each with a single entry in pinctrl-simple,cells > >> > >> Why not only allow (1)? > > > > Because we need to specify GPIO for some pins. There may be additional flags > > too, we do have external DMA request lines for few pins available.. I'm not > > saying pinctrl fwk should know about that, but it's a similar mapping of > > pins > > to GPIO lines. > > I'm asserting that since any GPIO mapping information would be at the > top-level of the pinctrl-simple binding, we can in fact only allow > option (1) above for the individual pin configuration nodes. Yes I agree. Based on what we have discussed #2 binding can now be dropped. At least I don't have any other reasons for pin specific flags that would need to be passed in the binding #2 above. The only additional data #2 binding provides are the real function names for the mux signals. But those can be eventually be shown by userspace debug tools, so no need for the kernel to care about them. From kernel and device driver point of view the named states are much more generic. 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
[RFC] net: ethernet: davinci_emac: add pm_runtime support
From: "Mark A. Greer"
Add pm_runtime support to the TI Davinci EMAC driver.
Signed-off-by: Mark A. Greer
---
This patch is RFC only since it will break emac support
for mach-davinci platforms. Hopefully, mach-davinci will
be fixed soon and this can be submitted.
drivers/net/ethernet/ti/davinci_emac.c | 43
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..15c84e4 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
@@ -346,10 +347,6 @@ struct emac_priv {
void (*int_disable) (void);
};
-/* clock frequency for EMAC */
-static struct clk *emac_clk;
-static unsigned long emac_bus_frequency;
-
/* EMAC TX Host Error description strings */
static char *emac_txhost_errcodes[16] = {
"No error", "SOP error", "Ownership bit not set in SOP buffer",
@@ -1534,6 +1531,8 @@ static int emac_dev_open(struct net_device *ndev)
int k = 0;
struct emac_priv *priv = netdev_priv(ndev);
+ pm_runtime_get(&priv->pdev->dev);
+
netif_carrier_off(ndev);
for (cnt = 0; cnt < ETH_ALEN; cnt++)
ndev->dev_addr[cnt] = priv->mac_addr[cnt];
@@ -1603,7 +1602,7 @@ static int emac_dev_open(struct net_device *ndev)
priv->phy_id);
ret = PTR_ERR(priv->phydev);
priv->phydev = NULL;
- return ret;
+ goto err;
}
priv->link = 0;
@@ -1644,7 +1643,11 @@ rollback:
res = platform_get_resource(priv->pdev, IORESOURCE_IRQ, k-1);
m = res->end;
}
- return -EBUSY;
+
+ ret = -EBUSY;
+err:
+ pm_runtime_put(&priv->pdev->dev);
+ return ret;
}
/**
@@ -1686,6 +1689,7 @@ static int emac_dev_stop(struct net_device *ndev)
if (netif_msg_drv(priv))
dev_notice(emac_dev, "DaVinci EMAC: %s stopped\n", ndev->name);
+ pm_runtime_put(&priv->pdev->dev);
return 0;
}
@@ -1779,6 +1783,9 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
struct emac_platform_data *pdata;
struct device *emac_dev;
struct cpdma_params dma_params;
+ struct clk *emac_clk;
+ unsigned long emac_bus_frequency;
+
/* obtain emac clock from kernel */
emac_clk = clk_get(&pdev->dev, NULL);
@@ -1787,12 +1794,14 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
return -EBUSY;
}
emac_bus_frequency = clk_get_rate(emac_clk);
+ clk_put(emac_clk);
+
/* TODO: Probe PHY here if possible */
ndev = alloc_etherdev(sizeof(struct emac_priv));
if (!ndev) {
rc = -ENOMEM;
- goto free_clk;
+ goto no_ndev;
}
platform_set_drvdata(pdev, ndev);
@@ -1908,15 +1917,13 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
SET_ETHTOOL_OPS(ndev, ðtool_ops);
netif_napi_add(ndev, &priv->napi, emac_poll, EMAC_POLL_WEIGHT);
- clk_enable(emac_clk);
-
/* register the network device */
SET_NETDEV_DEV(ndev, &pdev->dev);
rc = register_netdev(ndev);
if (rc) {
dev_err(&pdev->dev, "error in register_netdev\n");
rc = -ENODEV;
- goto netdev_reg_err;
+ goto no_irq_res;
}
@@ -1925,10 +1932,12 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
"(regs: %p, irq: %d)\n",
(void *)priv->emac_base_phys, ndev->irq);
}
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_resume(&pdev->dev);
+
return 0;
-netdev_reg_err:
- clk_disable(emac_clk);
no_irq_res:
if (priv->txchan)
cpdma_chan_destroy(priv->txchan);
@@ -1942,8 +1951,7 @@ no_dma:
probe_quit:
free_netdev(ndev);
-free_clk:
- clk_put(emac_clk);
+no_ndev:
return rc;
}
@@ -1977,9 +1985,6 @@ static int __devexit davinci_emac_remove(struct
platform_device *pdev)
iounmap(priv->remap_addr);
free_netdev(ndev);
- clk_disable(emac_clk);
- clk_put(emac_clk);
-
return 0;
}
@@ -1991,8 +1996,6 @@ static int davinci_emac_suspend(struct device *dev)
if (netif_running(ndev))
emac_dev_stop(ndev);
- clk_disable(emac_clk);
-
return 0;
}
@@ -2001,8 +2004,6 @@ static int davinci_emac_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct net_device *ndev = platform_get_drvdata(pdev);
- clk_enable(emac_clk);
-
if (netif_running(ndev))
[PATCH 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
From: "Mark A. Greer"
The am35x family of SoCs has a Davinci EMAC ethernet
controller on-chip. Unfortunately, the EMAC is unable
to wake the PRCM when there is network activity which
leads to a hung or extremely slow system when the MPU
has executed a 'wfi' instruction (because of pm_idle
or CPUidle). To prevent this, add hooks to the EMAC
pm_runtime suspend/resume calls so that hlt is disabled
whenever the EMAC is in use.
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/am35xx-emac.c | 44 +
arch/arm/mach-omap2/am35xx-emac.h | 16 +---
arch/arm/mach-omap2/board-am3517evm.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
4 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 3bb5cb3..22ff968 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -23,6 +23,37 @@
#include "control.h"
#include "am35xx-emac.h"
+/*
+ * Default pm_lats for the am35x.
+ * The net effect of using am35xx_emac_pm_lats[] is that
+ * pm_idle or CPUidle won't be called while the emac
+ * interface is open. This is required because the
+ * EMAC can't wake up PRCM so if the MPU is executing
+ * a 'wfi' instruction (e.g., from pm_idle or CPUidle),
+ * it won't break out of it due to emac activity.
+ */
+static int am35xx_emac_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int am35xx_emac_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency am35xx_emac_pm_lats[] = {
+ {
+ .deactivate_func= am35xx_emac_deactivate_func,
+ .activate_func = am35xx_emac_activate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int am35xx_emac_pm_lats_size = ARRAY_SIZE(am35xx_emac_pm_lats);
+
static void am35xx_enable_emac_int(void)
{
u32 regval;
@@ -61,12 +92,13 @@ static struct emac_platform_data am35xx_emac_pdata = {
static struct mdio_platform_data am35xx_mdio_pdata;
static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
- void *pdata, int pdata_len)
+ void *pdata, int pdata_len,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct platform_device *pdev;
pdev = omap_device_build(oh->class->name, 0, oh, pdata, pdata_len,
- NULL, 0, false);
+ pm_lats, pm_lats_size, false);
if (IS_ERR(pdev)) {
WARN(1, "Can't build omap_device for %s:%s.\n",
oh->class->name, oh->name);
@@ -76,7 +108,8 @@ static int __init omap_davinci_emac_dev_init(struct
omap_hwmod *oh,
return 0;
}
-void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
+void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size)
{
struct omap_hwmod *oh;
u32 regval;
@@ -91,7 +124,7 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
ret = omap_davinci_emac_dev_init(oh, &am35xx_mdio_pdata,
-sizeof(am35xx_mdio_pdata));
+sizeof(am35xx_mdio_pdata), NULL, 0);
if (ret) {
pr_err("Could not build davinci_mdio hwmod device\n");
return;
@@ -106,7 +139,8 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
ret = omap_davinci_emac_dev_init(oh, &am35xx_emac_pdata,
-sizeof(am35xx_emac_pdata));
+sizeof(am35xx_emac_pdata),
+pm_lats, pm_lats_size);
if (ret) {
pr_err("Could not build davinci_emac hwmod device\n");
return;
diff --git a/arch/arm/mach-omap2/am35xx-emac.h
b/arch/arm/mach-omap2/am35xx-emac.h
index 15c6f9c..7c23808 100644
--- a/arch/arm/mach-omap2/am35xx-emac.h
+++ b/arch/arm/mach-omap2/am35xx-emac.h
@@ -6,10 +6,20 @@
* published by the Free Software Foundation.
*/
+#include
+
#define AM35XX_DEFAULT_MDIO_FREQUENCY 100
-#if defined(CONFIG_TI_DAVINCI_EMAC) || defined(CONFIG_TI_DAVINCI_EMAC_MODULE)
-void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en);
+#if IS_ENABLED(CONFIG_TI_DAVINCI_EMAC)
+extern struct omap_device_pm_latency am35xx_emac_pm_lats[];
+extern int am35xx_emac_pm_lats_size;
+
+void am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en,
+ struct omap_device_pm_latency *pm_lats, int pm_lats_size);
#else
-static inline void am35xx_emac_i
[PATCH 1/2] arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support
From: "Mark A. Greer"
Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/am35xx-emac.c | 92 ++--
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/include/mach/am35xx.h |2 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 +
4 files changed, 135 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 1f97e74..3bb5cb3 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -15,27 +15,13 @@
* General Public License for more details.
*/
-#include
+#include
#include
-#include
-#include
+#include
+#include
#include
-
#include "control.h"
-
-static struct mdio_platform_data am35xx_emac_mdio_pdata;
-
-static struct resource am35xx_emac_mdio_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET, SZ_4K),
-};
-
-static struct platform_device am35xx_emac_mdio_device = {
- .name = "davinci_mdio",
- .id = 0,
- .num_resources = ARRAY_SIZE(am35xx_emac_mdio_resources),
- .resource = am35xx_emac_mdio_resources,
- .dev.platform_data = &am35xx_emac_mdio_pdata,
-};
+#include "am35xx-emac.h"
static void am35xx_enable_emac_int(void)
{
@@ -72,41 +58,57 @@ static struct emac_platform_data am35xx_emac_pdata = {
.interrupt_disable = am35xx_disable_emac_int,
};
-static struct resource am35xx_emac_resources[] = {
- DEFINE_RES_MEM(AM35XX_IPSS_EMAC_BASE, 0x3),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RXTHRESH_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_RX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_TX_PULSE_IRQ),
- DEFINE_RES_IRQ(INT_35XX_EMAC_C0_MISC_PULSE_IRQ),
-};
+static struct mdio_platform_data am35xx_mdio_pdata;
-static struct platform_device am35xx_emac_device = {
- .name = "davinci_emac",
- .id = -1,
- .num_resources = ARRAY_SIZE(am35xx_emac_resources),
- .resource = am35xx_emac_resources,
- .dev= {
- .platform_data = &am35xx_emac_pdata,
- },
-};
+static int __init omap_davinci_emac_dev_init(struct omap_hwmod *oh,
+ void *pdata, int pdata_len)
+{
+ struct platform_device *pdev;
+
+ pdev = omap_device_build(oh->class->name, 0, oh, pdata, pdata_len,
+ NULL, 0, false);
+ if (IS_ERR(pdev)) {
+ WARN(1, "Can't build omap_device for %s:%s.\n",
+ oh->class->name, oh->name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8 rmii_en)
{
- unsigned int regval;
- int err;
+ struct omap_hwmod *oh;
+ u32 regval;
+ int ret;
- am35xx_emac_pdata.rmii_en = rmii_en;
- am35xx_emac_mdio_pdata.bus_freq = mdio_bus_freq;
- err = platform_device_register(&am35xx_emac_device);
- if (err) {
- pr_err("AM35x: failed registering EMAC device: %d\n", err);
+ oh = omap_hwmod_lookup("davinci_mdio");
+ if (!oh) {
+ pr_err("Could not find davinci_mdio hwmod\n");
+ return;
+ }
+
+ am35xx_mdio_pdata.bus_freq = mdio_bus_freq;
+
+ ret = omap_davinci_emac_dev_init(oh, &am35xx_mdio_pdata,
+sizeof(am35xx_mdio_pdata));
+ if (ret) {
+ pr_err("Could not build davinci_mdio hwmod device\n");
return;
}
- err = platform_device_register(&am35xx_emac_mdio_device);
- if (err) {
- pr_err("AM35x: failed registering EMAC MDIO device: %d\n", err);
- platform_device_unregister(&am35xx_emac_device);
+ oh = omap_hwmod_lookup("davinci_emac");
+ if (!oh) {
+ pr_err("Could not find davinci_emac hwmod\n");
+ return;
+ }
+
+ am35xx_emac_pdata.rmii_en = rmii_en;
+
+ ret = omap_davinci_emac_dev_init(oh, &am35xx_emac_pdata,
+sizeof(am35xx_emac_pdata));
+ if (ret) {
+ pr_err("Could not build davinci_emac hwmod device\n");
return;
}
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 12c64db..f2f422e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3478,7 +3478,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "ipss_ick", &ipss_ick, CK_AM35XX),
CLK(NULL, "rmii_ck", &rmii_ck, CK_AM35XX),
CLK(NULL, "pclk_ck", &pclk_ck, CK_AM35XX),
- CLK("davinci_emac", NULL, &emac_ick, CK_AM35XX),
+ CLK("davi
[PATCH 0/2] arm: omap3: am35x: Convert emac to hwmod & disable hlt when open
From: "Mark A. Greer" Paul, Kevin, These patches convert the davinci emac support for the am35x SoC to use hwmod and add enable_hlt()/disable_hlt() calls to the pm_runtime hooks for that driver. I have converted the davinci_emac driver to use pm_runtime but I can't formally submit it yet since it requires some changes on the mach-davinci side that haven't happened yet. I will send it as an RFC in a reply to this thread. The patches are based on: git://git.pwsan.com/linux-2.6 am35xx_hwmod_data_fixes_a_3.5 Mark -- Mark A. Greer (2): arm: omap3: am35x: Add Davinci EMAC/MDIO hwmod support arm: omap3: am35x: Disable hlt when using Davinci EMAC arch/arm/mach-omap2/am35xx-emac.c | 120 ++-- arch/arm/mach-omap2/am35xx-emac.h | 16 +++- arch/arm/mach-omap2/board-am3517evm.c |3 +- arch/arm/mach-omap2/board-cm-t3517.c |3 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/include/mach/am35xx.h |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 7 files changed, 183 insertions(+), 48 deletions(-) -- 1.7.9.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
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 12 May 2012 00:58, Stephen Warren wrote:
> On 05/10/2012 01:59 PM, Jassi Brar wrote:
>
>> I think arbitrary numerical tokens are a reasonable price to pay for the
>> robustness and simplicity they bring.
>
> I have to disagree here.
>
> Using phandle+ID is almost as simple, and much more flexible. Global IDs
> have a number of disadvantages:
>
> a) You have to somehow keep them unique. Even with just a single .dts
> file, that's going to be a little painful since there's no central table
> of these IDs.
>
> What if the DT is composed of a bunch of chunks that represent pluggable
> boards, which may be mixed/matched together depending on what the user
> actually plugged in? Then, you have to be very careful to keep the n
> different files' numbering ranges segregated, or conflicts will occur.
>
You might want to revisit this point after working out the finer details of what
you propose for a client's specifier :)
>>
>> Well, I doubt if there would ever be enough such platforms to warrant a
>> new generic framework. For now, I would leave that to be a matter between
>> the dmac driver and its DT node.
>>
>> Similarly let every dmac, being unique, require DT data in it's own custom
>> format - I don't believe we can find a generic DT format for every kind of
>> dmac that does exist or would exist. (For ex, you found a way for RMK's
>> mux'ed req_lines, but what about assigning priorities to clients which is
>> possible with PL08X dmacs but not most others?)
>
> Good question. Again thought that sounds a little like policy, so
> perhaps should be negotiated at runtime rather than described in DT?
>
As much as we love everything to be runtime configurable, I am afraid it
can't be. We can't add new calls to the dmaengine api for simply
supporting specific features of various dmacs (priority in this case)
Because that would mean ideally every client going through the mostly
useless ritual of querying/setting those features and most dmacs
just 'pretending' to support some, except for the rare ones that actually do.
So as much as these sound like policy, they would usually be directly
hardcoded via dt for the machine or deducted by the dmac driver.
>>
>>> client0: i2s {
>>> /* has 2 DMA request output signals: 0, 1 */
>>> };
>>>
>>> client1: spdif {
>>> /* has 2 DMA request signals: 0, 1 */
>>> };
>>>
>> Do we also need to somehow tag these signals for the client to
>> differentiate between TX and RX channel ?
>
> Yes, the client's DT binding would certainly need to describe how many
> DMA request signals its HW generates, and give a unique ID to each. The
> driver would need to request a DMA channel for a specific one of its DMA
> requests.
>
Did I read "give a unique ID to each" correctly ?
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
FWIW, I think I can live with what you propose. Let us go for the kill.
Thanks.
--
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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/11/2012 01:51 PM, Tony Lindgren wrote: > * Stephen Warren [120511 12:21]: >> >> The mapping of GPIO to pinctrl pins would presumably be driven solely by >> the HW design of the pin controller and GPIO, and not by the mux >> selection in the pin controller (otherwise, I'd argue this isn't a >> simple case that should be handled by pinctrl-simple). >> >> As such, I'd expect some properties/table at the top-level of the pin >> controller object to describe the GPIO mapping. In turn, that implies >> that the individual per-pin mux-selection/configuration nodes don't need >> to describe any GPIO-related information. > > Yes good point. I agree it's a HW design issue, and could be in the properties > for the pin controller object. > > Just to summarize, the things to consider with the GPIO to mux mapping are: > > 1. Having this table as static data in the driver is is not a nice >solution as it seems that we'd currently need six mapping tables for >omap2+ alone. > > 2. This table is not needed for most of the (hundreds of) pins, it's >only needed for a few selected pins, let's say ten or so on an average >device. So there's no need to stuff the kernel with information about >the unused GPIO pins. > > It seems that the conclusion here is that we don't need to worry about > GPIOs in the pinctrl-simple binding for now, and it can be added later > without having to change the basic binding. The one thing I wanted to resolve here wasn't so much the binding for GPIO interaction here, but the following comment: You wrote: > I wrote: >> From a binding perspective, I don't see why you'd want to allow two cases: >> >> 1) One node with multiple entries in pinctrl-simple,cells >> 2) Multiple nodes each with a single entry in pinctrl-simple,cells >> >> Why not only allow (1)? > > Because we need to specify GPIO for some pins. There may be additional flags > too, we do have external DMA request lines for few pins available.. I'm not > saying pinctrl fwk should know about that, but it's a similar mapping of pins > to GPIO lines. I'm asserting that since any GPIO mapping information would be at the top-level of the pinctrl-simple binding, we can in fact only allow option (1) above for the individual pin configuration nodes. -- 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 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Hi, * Sricharan R [120510 10:47]: > Hi Tony, > > > -Original Message- > > From: R Sricharan [mailto:r.sricha...@ti.com] > > Sent: Thursday, May 03, 2012 12:56 PM > > To: linux-omap@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; > > t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com > > Subject: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support > > > > The series adds minimal OMAP5 support. > > OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB > > L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and > > hence large part of the peripherals are re-used. > > > > OMAP5432 is another variant of OMAP5430, with a > > memory controller supporting DDR3 and SATA. > > > OMAP5 V2 series is ready with all comments addressed, but I have > below dependencies to be merged to apply my series against your > cleanup-soc branch OK > 1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 This one is not merged in yet and it seems that we're out of time for v3.5 unless it drags on and we have -rc8 after -rc7. > 2) git://git.pwsan.com/linux-2.6 hwmod_data_cleanup_3.5 > 3) https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup These two are merged in arm-soc now. > 4) http://www.spinics.net/lists/arm-kernel/msg174461.html I think this series still has some pending comments? > Can you please let me know how you want me to prepare the series > with these dependencies. Until these dependencies get cleared out, it seems that the best branch to base your patches is omap-cleanup-timer-for-v3.5 tag and just carry the pending patches for a little bit longer. 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 1/3] ARM: OMAP2+: gpmc: update nand register helper
* Afzal Mohammed [120511 08:48]:
> Provide helper function for updating NAND register details for
> the necessary chip select. NAND drivers platform data can be
> updated with this information so that NAND driver can handle
> GPMC NAND operations by itself.
Hmm this seems that it might be a more future proof path.
Tony
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/gpmc.c | 21 +
> arch/arm/plat-omap/include/plat/gpmc.h | 18 ++
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 46b09da..a409a3e 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -49,6 +49,7 @@
> #define GPMC_ECC_CONTROL 0x1f8
> #define GPMC_ECC_SIZE_CONFIG 0x1fc
> #define GPMC_ECC1_RESULT0x200
> +#define GPMC_ECC_BCH_RESULT_00x240
>
> /* GPMC ECC control settings */
> #define GPMC_ECC_CTRL_ECCCLEAR 0x100
> @@ -681,6 +682,26 @@ int gpmc_prefetch_reset(int cs)
> }
> EXPORT_SYMBOL(gpmc_prefetch_reset);
>
> +void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
> +{
> + reg->gpmc_status = gpmc_base + GPMC_STATUS;
> + reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
> + GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
> + reg->gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
> + GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
> + reg->gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
> + GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
> + reg->gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
> + reg->gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
> + reg->gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
> + reg->gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
> + reg->gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
> + reg->gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
> + reg->gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
> + reg->gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
> + reg->gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
> +}
> +
> static void __init gpmc_mem_init(void)
> {
> int cs;
> diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
> b/arch/arm/plat-omap/include/plat/gpmc.h
> index 1527929..6a8078e 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc.h
> @@ -131,6 +131,24 @@ struct gpmc_timings {
> u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
> };
>
> +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;
> + void __iomem*gpmc_bch_result0;
> +};
> +
> +extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
> +
> 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);
> --
> 1.7.10
>
--
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 v4-alt 0/6] GPMC driver migrate one
* Mohammed, Afzal [120509 23:39]: > Hi Tony, > > On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote: > > > > To resolve this and as per your earlier question on whether old along > > > with new interface can be made to work parallely, here is suggestion > > > from my end to deal with it. > > > > I think this is the only way to keep this all building and booting > > for each patch in the series, no? If so, then we should select this > > option. The first patch should be broken up into more readable patches, > > it seems that you can do that without breaking things. > > Bisectability has been maintained in the patches. > > Ok, I will proceed by keeping old & new interface together, will > try to achieve it in smaller patches and without hacks. > > > > Please let me know whether you are fine in taking patch series > > > as in v4 (that converts all boards at once, with further revisions > > > based on review comments). > > > > It seems that there are still some pending comments and we need to > > have the hwmod entries merged first by Paul. > > Ok, first I will try to get hwmod in. Let's try to get merged these into l-o master around -rc2 so we can have them tested properly for a few weeks before v3.6 merge window. 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: [GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
Hi, * Cousson, Benoit [120511 05:51]: > Hi Tony, > > Here are some remaining DT patches I was not able to push at 3.4 due to some > missing dependency. > It applies now fine on top of lo/dt branch. It seems that there are still patches being discussed for those SoCs and we're pretty much done for this merge window. So unless things drag on to -rc8, I'd say we just need to postpone merging new things and merge them early around -rc2. Regards, Tony > Regards, > Benoit > > > The following changes since commit 40364b9f5a4d167d97bb6a76cd239ca8cfff056a: > Benoit Cousson (1): > arm/dts: omap4-panda: Add LEDs support > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.5/dts/am33xx > > Vaibhav Hiremath (3): > arm/dts: Add support for TI AM335x EVM board > arm/dts: omap3-evm: Add i2c and twl4030 support > arm/dts: Add support for TI AM3517/05 EVM board > > arch/arm/boot/dts/am335x-evm.dts | 39 > ++ > arch/arm/boot/dts/am3517-evm.dts | 32 +++ > arch/arm/boot/dts/omap3-evm.dts | 28 +++ > 3 files changed, 99 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/boot/dts/am335x-evm.dts > create mode 100644 arch/arm/boot/dts/am3517-evm.dts -- 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Stephen Warren [120511 12:21]: > > The mapping of GPIO to pinctrl pins would presumably be driven solely by > the HW design of the pin controller and GPIO, and not by the mux > selection in the pin controller (otherwise, I'd argue this isn't a > simple case that should be handled by pinctrl-simple). > > As such, I'd expect some properties/table at the top-level of the pin > controller object to describe the GPIO mapping. In turn, that implies > that the individual per-pin mux-selection/configuration nodes don't need > to describe any GPIO-related information. Yes good point. I agree it's a HW design issue, and could be in the properties for the pin controller object. Just to summarize, the things to consider with the GPIO to mux mapping are: 1. Having this table as static data in the driver is is not a nice solution as it seems that we'd currently need six mapping tables for omap2+ alone. 2. This table is not needed for most of the (hundreds of) pins, it's only needed for a few selected pins, let's say ten or so on an average device. So there's no need to stuff the kernel with information about the unused GPIO pins. It seems that the conclusion here is that we don't need to worry about GPIOs in the pinctrl-simple binding for now, and it can be added later without having to change the basic binding. 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 V3 1/2] of: Add generic device tree DMA helpers
On 05/10/2012 01:59 PM, Jassi Brar wrote:
> On 10 May 2012 22:30, Stephen Warren wrote:
>> On 05/09/2012 03:38 PM, Jassi Brar wrote:
>
>>> One point is about 'qos' here something like bandwidth allocation.
>>> If the dmac driver knew up-front the max possible clients that could be
>>> active simultaneously, it could "divide the bandwidth" accordingly.
>>> Again, the example of PL330 employing 2physical channels for better
>>> service - LLI (you got it right), where even 1 physical channel would
>>> also have served only not as reliably. I believe there would be
>>> more such scenarios.
>>
>> QoS seems like policy to me, whereas DT is more about describing the HW.
>> Is DT the correct place to describe QoS policy?
>>
>> I guess you are talking more about deriving policy from the description
>> of HW, i.e. how many client described in DT.
>
> Yeah, that's what I meant.
>
>> However, for some reason that seems dangerous to me; what if clients
>> can be instantiated some other way?
>
> The other way could be hotplug ?
Yes. Also, there's probably some mix of DT-driven and non-DT-driven
instantiation during the transition to DT, although that's probably
temporary.
> Anyway in those machines every channel would be populated
> and dmac driver would always account for the all-ports-plugged case.
>
>> For a 1:1 mapping (or 1:n mapping in HW with static selection specified
>> in the DT) between DMA client and DMA controller, perhaps the controller
>> can indeed make QoS decisions based on which (how many) clients are
>> connected to it.
>>
>> However, if a DMA client can be serviced by more than 1 DMA engine, and
>> the decision as to which DMA engine to use occurs at run-time by the DMA
>> driver core, rather than being statically configured in the DT, then the
>> DMA controller drivers cannot know ahead of time which will be used
>
> I think the dmac driver would make use of the routing flexibility to sustain
> its
> 'qos', and not the other way around (decide qos based on which one of the
> two dmacs would provide a channel to a client in future).
> Anyways, so far only Samsung SoCs seem to have that flexibility/redundancy
> and I have never had anyone asking for that runtime decision making.
>
>>> The minor difference being, you use the {request-signal, phandle} pair
>>> to find the right channel, I used only 'token'.
>>
>> That's a pretty big difference, I think.
>>
>> In your proposal, every token was globally unique (well, within the 1 DT
>> file). I'd rather not see any more global numbering schemes.
>
> Probably my shallow experience, but "globally unique, within a file" sounds
> like an oxymoron :)
To the kernel, that one file describes everything it knows about the HW
(except for probed information), so it's global:-) Aside from that, I've
often seen the term "global" used relative to some specific scope.
> I think arbitrary numerical tokens are a reasonable price to pay for the
> robustness and simplicity they bring.
I have to disagree here.
Using phandle+ID is almost as simple, and much more flexible. Global IDs
have a number of disadvantages:
a) You have to somehow keep them unique. Even with just a single .dts
file, that's going to be a little painful since there's no central table
of these IDs.
What if the DT is composed of a bunch of chunks that represent pluggable
boards, which may be mixed/matched together depending on what the user
actually plugged in? Then, you have to be very careful to keep the n
different files' numbering ranges segregated, or conflicts will occur.
b) Everything else in DT already uses phandle+ID, so doing the same
thing would be much more familiar and consistent for DT users.
>> Now, DMA requests are signals /from/ a DMA client to a DMA controller
>> ("send more data please", or "pull more data please"). Hence, I assert
>> that the phandle should refer to the DMA client, not the DMA controller.
>
> OK, though we may just want to convey information about the h/w setup
> from the s/w POV, rather than info to simulate the h/w ;)
DT is specifically about describing the HW from a HW perspective.
> For ex, the dma api and controller drivers don't really care about
> the fact that the client's driver must set some bit to trigger operation,
> whereas some simulator would need to care about that.
>
> Anyways, I am OK with whatever works well and make things simpler.
>
>>> Also note that, a client's dma specifier becomes perfectly general
>>> and future-proof
>>>
>>>client1: spdif {
>>> dma_tx = <278>
>>> dma_rx = <723>
>>> };
>>>
>>> otherwise the following representation
>>>
>>> client1: spdif {
>>>dma = <&sdma 2 1 &sdma 3 2>;
>>> };
>>>
>>> could break with some weird dma setups (IIANW Russell already finds
>>> it wouldn't work for him).
>>
>> To solve Russell's HW, we need some way of representing the mux directly
>> in DT irrespective of how the DMA controller or DMA client specify what
>> they're connec
[GIT PULL] few omap fixups for v3.5 merge window
Hi Arnd & Olof, Here are the fixes needed for the regressions caused by omap-cleanup-sparse-for-v3.5. I suggest pulling this into arm-soc/omap/cleanup-sparse where the issues got introduced. Regards, Tony The following changes since commit 09f45b83109cb8e23a06d5efb1096a08a9545974: Merge tag 'omap-cleanup-a2-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-sparse (2012-04-18 10:09:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes-for-cleanup for you to fetch changes up to 19b08b33fa4c60d66d4e341d4d1d9a6e86ffc9e6: ARM: OMAP: OTG integration: fix compiler warning (2012-05-11 09:56:43 -0700) Turns out the earlier omap-cleanup-sparse-for-v3.5 up introduced one compile issue and a new warning. Paul Walmsley (2): ARM: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds ARM: OMAP: OTG integration: fix compiler warning arch/arm/mach-omap1/common.h |4 arch/arm/plat-omap/usb.c |4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 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: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim wrote: > On 05/09/2012 01:31 AM, S, Venkatraman wrote: > >> On Tue, May 8, 2012 at 1:16 PM, Minchan Kim wrote: >>> On 05/03/2012 11:22 PM, Venkatraman S wrote: >>> Standard eMMC (Embedded MultiMedia Card) specification expects to execute one request at a time. If some requests are more important than others, they can't be aborted while the flash procedure is in progress. New versions of the eMMC standard (4.41 and above) specfies a feature called High Priority Interrupt (HPI). This enables an ongoing transaction to be aborted using a special command (HPI command) so that the card is ready to receive new commands immediately. Then the new request can be submitted to the card, and optionally the interrupted command can be resumed again. Some restrictions exist on when and how the command can be used. For example, only write and write-like commands (ERASE) can be preempted, and the urgent request must be a read. In order to support this in software, a) At the top level, some policy decisions have to be made on what is worth preempting for. This implementation uses the demand paging requests and swap read requests as potential reads worth preempting an ongoing long write. This is expected to provide improved responsiveness for smarphones with multitasking capabilities - example would be launch a email application while a video capture session (which causes long writes) is ongoing. >>> >>> >>> Do you have a number to prove it's really big effective? >> >> What type of benchmarks would be appropriate to post ? >> As you know, the response time of a card would vary depending on >> whether the flash device >> has enough empty blocks to write into and doesn't have to resort to GC during >> write requests. >> Macro benchmarks like iozone etc would be inappropriate here, as they won't >> show >> the latency effects of individual write requests hung up doing page >> reclaim, which happens >> once in a while. > > > We don't have such special benchmark so you need time to think how to prove > it. > IMHO, you can use run-many-x-apps.sh which checks elapsed time to activate > programs > by posting by Wu long time ago. > > http://www.spinics.net/lists/linux-mm/msg09653.html > > Of course, your eMMC is used above 80~90% for triggering GC stress and > your memory should be used up by dirty pages to happen reclaim. > > >>> >>> What I have a concern is when we got low memory situation. >>> Then, writing speed for page reclaim is important for response. >>> If we allow read preempt write and write is delay, it means read path takes >>> longer time to >>> get a empty buffer pages in reclaim. In such case, it couldn't be good. >>> >> >> I agree. But when writes are delayed anyway as it exceeds >> hpi_time_threshold (the window >> available for invoking HPI), it means that the device is in GC mode >> and either read or write >> could be equally delayed. Note that even in case of interrupting a >> write, a single block write >> (which usually is too short to be interrupted, as designed) is >> sufficient for doing a page reclaim, >> and further write requests (including multiblock) would not be subject >> to HPI, as they will >> complete within the average time. > > > My point is that it would be better for read to not preempt > write-for-page_reclaim. > And we can identify it by PG_reclaim. You can get the idea. > > Anyway, HPI is only feature of a device of many storages and you are > requiring modification > of generic layers although it's not big. So for getting justification and > attracting many > core guys(MM,FS,BLOCK), you should provide data at least. > Hi Kim, Apologies for a delayed response. I am studying your suggestions and will get back with some changes and also some profiling data. Regards, Venkat. -- 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 05/10/2012 11:27 AM, Tony Lindgren wrote:
> * Stephen Warren [120510 10:09]:
>> On 05/09/2012 02:49 PM, Tony Lindgren wrote:
>>> * Stephen Warren [120509 13:22]:
On 05/04/2012 04:08 PM, Tony Lindgren wrote:
> * Stephen Warren [120504 11:59]:
>> On 05/04/2012 10:34 AM, Tony Lindgren wrote:
>>> * Jean-Christophe PLAGNIOL-VILLARD [120504
>>> 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
>>
>> so I was thinking to do like on gpio
>>
>> uart {
>> pin = < &pioA 12 {pararms} >
>>
>> }
>
> Hmm I assume the "12" above the gpio number?
no pin number in the bank because it could not be gpio
>>>
>>> Yes OK, but pin number 12 in the gpio bank, not in the mux register.
>>> Got it.
>>
>> I'd prefer to avoid any references to GPIOs here; not all muxable pins
>> are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
>> independent.
>
> And it seems that &pioA 12 is not always enough information for the
> pinctrl
> driver to request a GPIO. So it's best to specify it separately.
Why would a pinctrl driver "request a GPIO"?
>>>
>>> Hmm what would pinctrl_request_gpio do if the GPIO driver is separate
>>> driver?
>>
>> Well, that's a GPIO driver requesting a GPIO from the pinctrl system,
>> rather than the pinctrl driver requesting a GPIO (sorry to be picky).
>
> Oh sorry maybe I misunderstood what pinctrl_request_gpio is doing.
> Seems like that should work the same way from binding point of view.
>
>> It wasn't at all obvious to me from your binding proposal that you
>> intended the pinctrl-simple driver to support the GPIO operations at
>> all. If you do want this, I think you'd need some properties (perhaps
>> some kind of explicit table) in order to set up the GPIO ID -> pinctrl
>> pin ID mapping. I don't recall seeing those; did I just miss them? I
>> think we'd want this to be explicit because:
>>
>> a) It may well be the case that not all users of pinctrl-simple actually
>> mux/control GPIOs at all. It's certainly possible to only mux "special
>> functions", and have dedicated pins for a GPIO controller.
>>
>> b) Even when GPIOs do come into the picture, it may be that only some of
>> the pins are available as GPIOs.
>
> Right, we need some pinctrl to gpio mapping eventually. That comes
> automatically from DT for the pins and gpios we care about.
>
> And that's why the binding needs to be flexible enough so we can add
> optional pin specific options as needed in addition to parsing a larger
> set of pins with no options.
The mapping of GPIO to pinctrl pins would presumably be driven solely by
the HW design of the pin controller and GPIO, and not by the mux
selection in the pin controller (otherwise, I'd argue this isn't a
simple case that should be handled by pinctrl-simple).
As such, I'd expect some properties/table at the top-level of the pin
controller object to describe the GPIO mapping. In turn, that implies
that the individual per-pin mux-selection/configuration nodes don't need
to describe any GPIO-related information.
--
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] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Mon, 7 May 2012 10:52:28 +0530, "DebBarma, Tarun Kanti" wrote: > Hi, > > On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas wrote: > > I've noticed that current mainline enables _all_ possible GPIO > > interrupts, this patch fixes that problem. > OK, thanks. > > > Also Grant doesn't seem to be on CC so might not be able to pick this up. > I have added Cc: in the patch and was expecting that would take care. > Looks like that has not happened. Anyways, I have explicitly added in the > email. I'm particularly bursty when it comes to patch review and applying. Sometimes it takes me a while to find time for maintainership work. g. -- 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] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
On Thu, 10 May 2012 07:23:56 -0700, Kevin Hilman wrote: > Grant, > > "DebBarma, Tarun Kanti" writes: > > > Hi, > > > > On Thu, May 10, 2012 at 3:06 AM, Janusz Krzysztofik > > wrote: > >> On Mon, 7 May 2012 10:52:28 DebBarma, Tarun Kanti wrote: > >>> On Sun, May 6, 2012 at 3:25 AM, Grazvydas Ignotas > >>> wrote: > >>> > On Mon, Apr 30, 2012 at 10:20 AM, Tarun Kanti DebBarma > >>> > wrote: > >>> >> Initialization of irqenable, irqstatus registers is the common > >>> >> operation done in this function for all OMAP platforms, viz. OMAP1, > >>> >> OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced > >>> >> wrongly to take care of OMAP2+ platforms were overwriting initially > >>> >> programmed OMAP1 value breaking functionality on OMAP1. > >> > >> Hi, > >> I can confirm that my other issues with GPIO on Amstrad Delta were not > >> related, and this patch is still required for GPIO interrupts hardware > >> being correctly initialized on OMAP1 in 3.4-rc6. You can add my > >> > >> Tested-by: Janusz Krzysztofik > >> > >> if you wish. > > Thank you for confirming!! > > We'd like to get this one in for v3.4-rc. Can you queue it? > > I added the tested-by from Janusz and my signoff, and pull request is > below. Pulled, thanks. I'll send a pull req out to Linus today. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: OTG integration: fix compiler warning
* Paul Walmsley [120509 15:41]:
>
> Tony reported the following compile warning after commit
> eeb3711b89d68e147e05e7b43a49ecc5009dc157 ("ARM: OMAP2+: clean up some
> cppcheck warnings"):
>
> arch/arm/plat-omap/usb.c: In function 'omap_otg_init':
> arch/arm/plat-omap/usb.c:40: warning: unused variable 'status'
>
> This happens if CONFIG_ARCH_OMAP_OTG is set but
> CONFIG_USB_GADGET_OMAP, CONFIG_USB_OHCI_HCD,
> CONFIG_USB_OHCI_HCD_MODULE, and CONFIG_USB_OTG are all unset.
>
> Fix by localizing the status variable to the blocks that use it.
>
> Compile-tested only, with omap2plus_defconfig and omap2plus_defconfig
> with CONFIG_USB_OHCI_HCD and CONFIG_USB_OTG enabled.
Thanks applying into fixes-for-cleanup branch.
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: OMAP1: USB: fix ocpi_enable compile problem on non-1610 builds
* Paul Walmsley [120510 15:31]:
>
> Janusz Krzysztofik reported the following build break on OMAP1 builds that
> don't include CONFIG_ARCH_OMAP16XX:
>
> LD .tmp_vmlinux1
> arch/arm/mach-omap1/built-in.o: In function `omap1_usb_init':
> lcd_dma.c:(.init.text+0x1420): undefined reference to `ocpi_enable'
> make: *** [.tmp_vmlinux1] Error 1
>
> This was caused by commit d3645d39ad0ed9f09535065676ea0ba114f93cdf
> ("ARM: OMAP1: OHCI: use platform_data fn ptr to enable OCPI bus").
> Fix by declaring an empty ocpi_enable() on non-16XX builds, which
> should work until the OCPI code is moved out to drivers/.
Thanks applying into fixes-for-cleanup branch.
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: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: > Can you send me your .config? Sent off-list. > At the same time, maybe just try "make omap2plus_defconfig" and enable > the OMAP3 debug devices config. That's all I am doing. Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Cheers, Will -- 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: oprofile and ARM A9 hardware counter
Hi Will,
On 05/11/2012 10:02 AM, Will Deacon wrote:
> On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
>> Hi Will,
>
> Hello,
>
>> On 05/11/2012 08:49 AM, Will Deacon wrote:
>>> I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
>>
>> I tried the same (make omap2plus_defconfig and enabled the above
>> option), and I do see the interrupts firing on both 4430 and 4460...
>>
>> / # cat /proc/interrupts
>>CPU0 CPU1
>> 29: 1023404 GIC twd
>> 33:401 0 GIC arm-pmu
>> 34: 0441 GIC arm-pmu
>
> Well, at least it's working for somebody!
>
>> What is your kernel commit ID that you applied the patches on top of?
>
> 7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
> please test"). Is there something else I need too?
Ok, thanks. I was based upon Tony's -rc5. However, I rebased to the same
as you and it is still working for me
Can you send me your .config?
At the same time, maybe just try "make omap2plus_defconfig" and enable
the OMAP3 debug devices config. That's all I am doing.
>> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?
>
> Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
> same .config (I can mail it to you separately if you want).
Ok, should be fine. The kernel should print the ES version on start-up ...
[0.00] OMAP4430 ES2.2
What does yours show?
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: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Ivan, On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote: > > > So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. > > > > But this is not going to happen this merge window as I understood, may > > be not even the next one. We need to make UBIFS happy sooner than that, > > I think. So may be we go forward with your original patch? > > I'm OK with this too, as the patches are ready and tested. > The MTD patch is [2], it depends on [1] which has been pushed, then dropped > by Tony. > Do you need me to repost [2] ? > > Tony, sorry to backpedal on this: would you re-push patch [1], if indeed > Afzal's patches > are not going to be merged soon ? In the meantime, I can prepare a patch on > top of Afzal's to > have a smooth transition w.r.t BCH support. What do you think ? A new series [A-D] has been sent for handling GPMC NAND registers by NAND driver itself. This is being targeted for 3.5. Hopefully if every one is in agreement, we can avoid patching for BCH support again when GPMC driver migration happens. And the effect of GPMC driver migration on NAND driver can be reduced when it happens. Can you try a patch on top of this series & checks if it works for you, if more is required from my side let me know. Regards Afzal [A] http://marc.info/?l=linux-omap&m=133675113218509&w=2 [B] http://marc.info/?l=linux-omap&m=133675123118577&w=2 [C] http://marc.info/?l=linux-omap&m=133675123718579&w=2 [D] http://marc.info/?l=linux-omap&m=133675124818580&w=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
[PATCH 3/3] 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.
Modified prefetch and ecc functions are logically same as the
corresponding exported symbols from GPMC code.
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 ongoing GPMC driver
migration, 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
---
drivers/mtd/nand/omap2.c | 207 --
1 file changed, 163 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c2b0bba..25f930c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -95,6 +95,16 @@
#define P4e_s(a) (TF(a & NAND_Ecc_P4e) << 0)
#define P4o_s(a) (TF(a & NAND_Ecc_P4o) << 1)
+#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
+#defineECCCLEAR0x100
+#defineECC10x1
+
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -127,9 +137,70 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ struct gpmc_nand_regs reg;
};
/**
+ * 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
* @cmd: command to device
@@ -147,13 +218,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, inf
[PATCH 2/3] ARM: OMAP2+: gpmc-nand: update gpmc-nand regs
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..d4e803c 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -108,6 +108,8 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_RDY_BSY, 1);
}
+ gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
+
err = platform_device_register(&gpmc_nand_device);
if (err < 0) {
dev_err(dev, "Unable to register NAND device\n");
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.10
--
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 1/3] ARM: OMAP2+: gpmc: update nand register helper
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc.c | 21 +
arch/arm/plat-omap/include/plat/gpmc.h | 18 ++
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 46b09da..a409a3e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -681,6 +682,26 @@ int gpmc_prefetch_reset(int cs)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+ reg->gpmc_status = gpmc_base + GPMC_STATUS;
+ reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
+ reg->gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
+ reg->gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
+ reg->gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
+ reg->gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
+ reg->gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
+ reg->gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
+ reg->gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
+ reg->gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
+ reg->gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
+ reg->gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
+ reg->gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 1527929..6a8078e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,24 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
};
+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;
+ void __iomem*gpmc_bch_result0;
+};
+
+extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+
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);
--
1.7.10
--
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 0/3] Handle GPMC-NAND registers by NAND driver
Hi, This series provides the ability for OMAP NAND driver to configure GPMC_NAND registers by NAND driver itself instead of using GPMC exported symbols. Regards Afzal Afzal Mohammed (3): ARM: OMAP2+: gpmc: update nand register helper ARM: OMAP2+: gpmc-nand: update gpmc-nand regs mtd: nand: omap2: handle nand on gpmc arch/arm/mach-omap2/gpmc-nand.c|2 + arch/arm/mach-omap2/gpmc.c | 21 arch/arm/plat-omap/include/plat/gpmc.h | 18 +++ arch/arm/plat-omap/include/plat/nand.h |1 + drivers/mtd/nand/omap2.c | 207 +--- 5 files changed, 205 insertions(+), 44 deletions(-) -- 1.7.10 -- 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Thu, 2012-05-10 at 19:45 +0200, Ivan Djelic wrote: > On Thu, May 10, 2012 at 04:52:18PM +0100, Artem Bityutskiy wrote: > > On Thu, 2012-05-10 at 17:17 +0200, Ivan Djelic wrote: > > > But in order to do so, I need the changes that Afzal has submitted > > > (in particular [3]). Those changes (and as a consequence, my new patch) > > > won't hit 3.5. > > > > > > So, when Afzal's patches are pushed, I'll submit a new, single MTD patch. > > > > But this is not going to happen this merge window as I understood, may > > be not even the next one. We need to make UBIFS happy sooner than that, > > I think. So may be we go forward with your original patch? > > I'm OK with this too, as the patches are ready and tested. > The MTD patch is [2], it depends on [1] which has been pushed, then dropped > by Tony. > Do you need me to repost [2] ? > > Tony, sorry to backpedal on this: would you re-push patch [1], if indeed > Afzal's patches > are not going to be merged soon ? In the meantime, I can prepare a patch on > top of Afzal's to > have a smooth transition w.r.t BCH support. What do you think ? OK, since we now have Tony's ack - I have applied both patches to l2-mtd.git. Thanks. I have a question though - will send separately. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
* Olof Johansson [120511 01:41]: > On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley wrote: > > Hello Olof, > > > > On Fri, 11 May 2012, Olof Johansson wrote: > > > >> I did notice that omap2plus_defconfig has grown a new warning caused > >> by "ARM: OMAP2+: clean up some cppcheck warnings" (oh, the irony!): > >> > >> arch/arm/plat-omap/usb.c: In function 'omap_otg_init': > >> arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' > >> [-Wunused-variable] > > > > Thanks, this has been fixed by: > > > > http://marc.info/?l=linux-omap&m=133660322929805&w=2 > > Sounds good, I'll wait for it to trickle in on a future pull request. Thanks I'll see if there's some other fixes still needed and send a pull request today. 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: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
* Olof Johansson [120511 00:25]: > Tony, > > I've pulled all 10 requests. Many of them ended up going into the same > next/ branch, but that's quite OK. Please double check my merge > conflict resolutions. > > One nit is that at least one of the branches had a few varying patch > subjects, so just a friendly reminder to sanitize them to ARM: OMAP.*: > or so when you apply patches. Oops, sorry looks like I missed some of them. Usually I do fix those up though, and had my scripts do that automatically when applying from k.o patchwork earlier. I'll add some checks to my scripts applying from mbox format too. 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: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
> Hi Will,
Hello,
> On 05/11/2012 08:49 AM, Will Deacon wrote:
> > I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
>
> I tried the same (make omap2plus_defconfig and enabled the above
> option), and I do see the interrupts firing on both 4430 and 4460...
>
> / # cat /proc/interrupts
>CPU0 CPU1
> 29: 1023404 GIC twd
> 33:401 0 GIC arm-pmu
> 34: 0441 GIC arm-pmu
Well, at least it's working for somebody!
> What is your kernel commit ID that you applied the patches on top of?
7cf543bc ("Linux-omap rebuilt: Updated to -rc6, merged in pending branches,
please test"). Is there something else I need too?
> What board are you using? Blaze, panda, etc, and is it 4430 or 4460?
Ye olde Panda 4430. It does work with my perf/omap4 branch though using the
same .config (I can mail it to you separately if you want).
Cheers,
Will
--
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: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 08:49 AM, Will Deacon wrote: > On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: >> On 05/11/2012 07:25 AM, Will Deacon wrote: >>> I figured I may as well take perf for a spin and see how I got on. The good >>> news is that the hwmod bits all seem to work as before and the correct IRQs >>> are requested: >>> >>> root@florentine-pogen:~# cat /proc/interrupts >>>CPU0 CPU1 >>> 29: 44527 17916 GIC twd >>> 33: 0 0 GIC arm-pmu >>> 34: 0 0 GIC arm-pmu >>> >>> But, unfortunately, as you can see from the above, I just can't persuade >>> them >>> to fire. The PMU counters do tick, but they happily increment through zero >>> without us realising. I retested with my perf/omap4 branch to make sure my >>> board is ok, and the irqs do fire there. >>> >>> Any ideas? >> >> Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU >> is enabled? > > I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu What is your kernel commit ID that you applied the patches on top of? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? 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: [PATCH 02/19] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode
On Wed, 2012-05-09 at 16:27 -0700, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > From: Rajendra Nayak
> >
> > Restore all CM1/2 module registers as they are lost in OFF mode.
>
> Except they are still lost since nobody calls these new functions (in
> this patch.) :)
>
> For ease of review, it's preferred to add the *users* of new code in the
> same patch as the new code.
I'll fix this for the next version. I think this same comment applies to
patch #3 also.
>
> > [n...@ti.com: minor clean ups]
> > Signed-off-by: Nishanth Menon
> > Signed-off-by: Rajendra Nayak
> > Signed-off-by: Santosh Shilimkar
> > Signed-off-by: Axel Haslam
> > Signed-off-by: Tero Kristo
> > ---
> > arch/arm/mach-omap2/cm44xx.c | 322
> > ++
> > arch/arm/mach-omap2/cm44xx.h |2 +
> > 2 files changed, 324 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cm44xx.c b/arch/arm/mach-omap2/cm44xx.c
> > index 535d66e..fb5465b 100644
> > --- a/arch/arm/mach-omap2/cm44xx.c
> > +++ b/arch/arm/mach-omap2/cm44xx.c
> > @@ -21,8 +21,11 @@
> > #include "iomap.h"
> > #include "common.h"
> > #include "cm.h"
> > +#include "cm44xx.h"
> > #include "cm1_44xx.h"
> > #include "cm2_44xx.h"
> > +#include "cminst44xx.h"
> > +#include "prcm44xx.h"
> > #include "cm-regbits-44xx.h"
> >
> > /* CM1 hardware module low-level functions */
> > @@ -50,3 +53,322 @@ void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16
> > reg)
> > {
> > __raw_writel(val, OMAP44XX_CM2_REGADDR(inst, reg));
> > }
> > +
> > +#define MAX_CM_REGISTERS 51
> > +
> > +struct omap4_cm_reg {
> > + u16 offset;
> > + u32 val;
> > +};
> > +
> > +struct omap4_cm_regs {
> > + u32 mod_off;
> > + u32 no_reg;
>
> minor: do these need to be u32?
u16 should be good enough to save space I guess, I'll try changing this
and see what happens.
>
> > + struct omap4_cm_reg reg[MAX_CM_REGISTERS];
> > +};
> > +
> > +static struct omap4_cm_regs cm1_regs[] = {
> > + /* OMAP4430_CM1_OCP_SOCKET_MOD */
> > + { .mod_off = OMAP4430_CM1_OCP_SOCKET_INST, .no_reg = 1,
> > + {{.offset = OMAP4_CM_CM1_PROFILING_CLKCTRL_OFFSET} },
>
> For readability sake, I'd prefer to see this line indented. And why
> the extra space before the final '}'}
These tables are horrible, would be better to get rid of them completely
but I guess that is not possible... I'll look at the indentation.
>
> > + },
>
> [...]
>
> > +static void omap4_cm1_prepare_off(void)
> > +{
> > + u32 i, j;
> > + struct omap4_cm_regs *cm_reg = cm1_regs;
> > +
> > + for (i = 0; i < ARRAY_SIZE(cm1_regs); i++, cm_reg++) {
> > + for (j = 0; j < cm_reg->no_reg; j++) {
> > + cm_reg->reg[j].val =
> > + omap4_cminst_read_inst_reg(OMAP4430_CM1_PARTITION,
> > + cm_reg->mod_off,
> > + cm_reg->reg[j].offset);
> > + }
> > + }
> > +}
> > +
> > +static void omap4_cm2_prepare_off(void)
> > +{
> > + u32 i, j;
> > + struct omap4_cm_regs *cm_reg = cm2_regs;
> > +
> > + for (i = 0; i < ARRAY_SIZE(cm2_regs); i++, cm_reg++) {
> > + for (j = 0; j < cm_reg->no_reg; j++) {
> > + cm_reg->reg[j].val =
> > + omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
> > + cm_reg->mod_off,
> > + cm_reg->reg[j].offset);
> > + }
> > + }
> > +}
>
> > +static void omap4_cm1_resume_off(void)
> > +{
> > + u32 i, j;
> > + struct omap4_cm_regs *cm_reg = cm1_regs;
> > +
> > + for (i = 0; i < ARRAY_SIZE(cm1_regs); i++, cm_reg++) {
> > + for (j = 0; j < cm_reg->no_reg; j++) {
> > + omap4_cminst_write_inst_reg(cm_reg->reg[j].val,
> > + OMAP4430_CM1_PARTITION,
> > + cm_reg->mod_off,
> > + cm_reg->reg[j].offset);
> > + }
> > + }
> > +}
> > +
> > +static void omap4_cm2_resume_off(void)
> > +{
> > + u32 i, j;
> > + struct omap4_cm_regs *cm_reg = cm2_regs;
> > +
> > + for (i = 0; i < ARRAY_SIZE(cm2_regs); i++, cm_reg++) {
> > + for (j = 0; j < cm_reg->no_reg; j++) {
> > + omap4_cminst_write_inst_reg(cm_reg->reg[j].val,
> > + OMAP4430_CM2_PARTITION,
> > + cm_reg->mod_off,
> > + cm_reg->reg[j].offset);
> > + }
> > + }
> > +}
>
> Notice the two prpare functions (and resume functions) are basically
> identical, except for the partition.
>
> How about adding a .partition field to the struct so there can be a
> single function}
Yea, should be possible. I'll fix this for next rev.
-Tero
--
To unsubscribe from this
[PATCH 2/2] ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck
Timers in PER domain periodically report old time from TCRR in
posted mode if ick < 4*fck. Therefore, set timer to non-posted
whenever ick < 4*fck for all timers.
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/plat-omap/dmtimer.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 15e7882..a81b85e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -378,6 +378,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
{
int ret;
struct dmtimer_platform_data *pdata;
+ struct clk *iclk;
if (unlikely(!timer))
return -EINVAL;
@@ -388,6 +389,17 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
return -EINVAL;
ret = pdata->set_timer_src(timer->pdev, source);
+ /*
+* Timers in PER domain periodically report old time
+* from TCRR in posted mode if ick < 4*fck. Hence,
+* when this condition is satisfied setting the timer
+* to non-posted mode, instead.
+*/
+ if (!IS_ERR(&ret)) {
+ iclk = clk_get(&timer->pdev->dev, "ick");
+ if (clk_get_rate(iclk) < (4 * clk_get_rate(timer->fclk)))
+ timer->posted = 0;
+ }
return ret;
}
--
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
[PATCH 1/2] ARM: omap: hwmod: Add an 'ick' clkdev alias
From: Rajendra Nayak For all hwmods' with just one slave interface, use the slave->clk to add an 'ick' clkdev alias in the table. This is useful for drivers of such devices to get the interface clock using 'clk_get(dev, "ick")' Signed-off-by: Rajendra Nayak --- arch/arm/plat-omap/omap_device.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index d50cbc6..c8bc005 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -311,6 +311,9 @@ static void _add_hwmod_clocks_clkdev(struct omap_device *od, for (i = 0; i < oh->opt_clks_cnt; i++) _add_clkdev(od, oh->opt_clks[i].role, oh->opt_clks[i].clk); + + if (oh->slaves_cnt == 1) + _add_clkdev(od, "ick", oh->slaves[0]->clk); } -- 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
[PATCH 0/2] ARM: omap: dmtimer: fix incorrect TCRR value in posted mode
Timers in PER domain periodically report old time from TCRR in posted mode unless ICLK >= 4 * FCLK. The problem is addressed in the following manner: Patch 1: Adds ick alias in the clkdev table so that dmtimer code can extract the iclk rate using clk_get_rate(). Patch 2: The final logic added in omap_dm_timer_prepare() where timer is set to non-posted mode if iclk < 4*fclk. Rajendra Nayak (1): ARM: omap: hwmod: Add an 'ick' clkdev alias Tarun Kanti DebBarma (1): ARM: omap: dmtimer: set non-posted mode if iclk less than 4*fck arch/arm/plat-omap/dmtimer.c | 12 arch/arm/plat-omap/omap_device.c |3 +++ 2 files changed, 15 insertions(+), 0 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: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: > On 05/11/2012 07:25 AM, Will Deacon wrote: > > I figured I may as well take perf for a spin and see how I got on. The good > > news is that the hwmod bits all seem to work as before and the correct IRQs > > are requested: > > > > root@florentine-pogen:~# cat /proc/interrupts > >CPU0 CPU1 > > 29: 44527 17916 GIC twd > > 33: 0 0 GIC arm-pmu > > 34: 0 0 GIC arm-pmu > > > > But, unfortunately, as you can see from the above, I just can't persuade > > them > > to fire. The PMU counters do tick, but they happily increment through zero > > without us realising. I retested with my perf/omap4 branch to make sure my > > board is ok, and the irqs do fire there. > > > > Any ideas? > > Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU > is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. Will -- 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: oprofile and ARM A9 hardware counter
Hi Will On 05/11/2012 07:25 AM, Will Deacon wrote: > On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: >> Hi Will, > > Hi Jon, > >> For my testing I have just been reading the PM_EMU_PWRSTST register which >> shows the power state of the EMU power domain. It should read 3 when the >> power domain is ON and 0 when it is off. I did something like the following >> (dumping all EMU clock and power domain registers). > > I figured I may as well take perf for a spin and see how I got on. The good > news is that the hwmod bits all seem to work as before and the correct IRQs > are requested: > > root@florentine-pogen:~# cat /proc/interrupts >CPU0 CPU1 > 29: 44527 17916 GIC twd > 33: 0 0 GIC arm-pmu > 34: 0 0 GIC arm-pmu > > But, unfortunately, as you can see from the above, I just can't persuade them > to fire. The PMU counters do tick, but they happily increment through zero > without us realising. I retested with my perf/omap4 branch to make sure my > board is ok, and the irqs do fire there. > > Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? 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: [PATCH] OMAP4: panda: add statics to remove warnings
On Fri, 2012-05-04 at 12:29 -0700, Tony Lindgren wrote: > * Tomi Valkeinen [120425 05:32]: > > On Tue, 2012-04-24 at 10:16 -0700, Tony Lindgren wrote: > > > * Tomi Valkeinen [120423 00:43]: > > > > Add statics to board-omap4-panda.c's internal functions and data > > > > structures to remove warnings. > > > > > > Care to update with the warnings produced? > > > > Ah, sure. Updated patch below: > > > > From e96ddeb7d783d48a15a32f8ef5a7bae3089f66b9 Mon Sep 17 00:00:00 2001 > > From: Tomi Valkeinen > > Date: Wed, 28 Mar 2012 11:38:58 +0300 > > Subject: [PATCH] OMAP4: panda: add statics to remove warnings > > > > Add statics to board-omap4-panda.c's internal functions and data > > structures to remove sparse warnings: > > > > arch/arm/mach-omap2/board-omap4panda.c:234:29: warning: symbol > > 'omap_panda_wlan_data' was not declared. Should it be static? > > arch/arm/mach-omap2/board-omap4panda.c:441:24: warning: symbol > > 'omap4_panda_dvi_device' was not declared. Should it be static? > > arch/arm/mach-omap2/board-omap4panda.c:451:12: warning: symbol > > 'omap4_panda_dvi_init' was not declared. Should it be static? > > arch/arm/mach-omap2/board-omap4panda.c:512:13: warning: symbol > > 'omap4_panda_display_init' was not declared. Should it be static? > > Thanks adding to fixes-non-critical. It seems this patch is obsolete, as there's already one in linux-next: commit 8c3d4534a8da0dc6a2d52b61585e61f7e8143096 Author: Paul Walmsley Date: Fri Apr 13 06:34:26 2012 -0600 ARM: OMAP2+: declare file-local functions as static Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
On Thu, 2012-05-10 at 20:56 -0500, Ricardo Neri wrote: > Sorry, some hunks where missing in the patch that I submitted yesterday. > > I just pushed a branch containing the whole most up-to-date series here: > > git://gitorious.org/omap-audio/linux-audio.git > ricardon/topic/dss_audio-for-tomi > > This includes the implementation of the DSS audio interface for HDMI > covering the improved locking strategy [1][2], plus the missing hunks in > my yesterday's patch, plus handling of mode changes you pointed out. > > Please let me know if you want me to resubmit the whole patch series so > that you can comment if you need to. Thanks, I think this is fine. I had to rebase your branch as you had some extra patches there also. There were also a few conflicts with latest dss stuff, but nothing serious. I pushed the branch with latest dss and your branch to: git://gitorious.org/linux-omap-dss2/linux.git test With a quick test video works ok, but I didn't test audio. Tomi signature.asc Description: This is a digitally signed message part
[GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. Regards, Benoit The following changes since commit 40364b9f5a4d167d97bb6a76cd239ca8cfff056a: Benoit Cousson (1): arm/dts: omap4-panda: Add LEDs support are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.5/dts/am33xx Vaibhav Hiremath (3): arm/dts: Add support for TI AM335x EVM board arm/dts: omap3-evm: Add i2c and twl4030 support arm/dts: Add support for TI AM3517/05 EVM board arch/arm/boot/dts/am335x-evm.dts | 39 ++ arch/arm/boot/dts/am3517-evm.dts | 32 +++ arch/arm/boot/dts/omap3-evm.dts | 28 +++ 3 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/am335x-evm.dts create mode 100644 arch/arm/boot/dts/am3517-evm.dts -- 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: oprofile and ARM A9 hardware counter
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: > Hi Will, Hi Jon, > For my testing I have just been reading the PM_EMU_PWRSTST register which > shows the power state of the EMU power domain. It should read 3 when the > power domain is ON and 0 when it is off. I did something like the following > (dumping all EMU clock and power domain registers). I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Cheers, Will -- 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] usb/dwc3: Fix the dwc3 dependency
Hello. On 11-05-2012 9:55, joseph daniel wrote: The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT&& USB_XHCI_HCD) Signed-off-by: joseph daniel --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..68271fa 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,6 +1,6 @@ config USB_DWC3 tristate "DesignWare USB3 DRD Core Support" - depends on (USB&& USB_GADGET) + depends on (USB&& USB_SUPPORT&& USB_XCHI_HCD&& USB_GADGET) Parens not needed -- could as well get rid of them. WBR, Sergei -- 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 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On Fri, 11 May 2012, Cousson, Benoit wrote: > But they are not separately gated for OMAP4 either. This is the modulemode > trick that make us think that, but it just means that the PRCM should ensure > that this clock is needed when at least one UART modulemode is enabled. In > fact the SPI modules are using the same clock. > > The modulemode is used to do some reference counting, but the gating is done > globally. It was the same with the FCK_EN and ICK_EN in OMAP2&3. > > The PRCM spec show only one global gating between FUNC_48M_FCLK and > PER_48M_GFCLK. All the modules are sharing the exact same clock. Well, on OMAP3 and AM3517, they do not all share the same clock. If you look at the 34xx TRM vZU Table 17-11 "UART Clocks", you can see that the UART1 and 2 functional clocks are sourced from clocks managed by the CORE clockdomain, while UART3 is sourced from clocks managed by the PER clockdomain. This is also expressed in our OMAP3 clock tree. I realize this is slightly tangential to your point. As to where the clock gating nodes are actually located on a given piece of silicon, unfortunately I have no way of confirming that, aside from power measurement. You might be correct about what's going on with the AM3517 but it would be nice to get some confirmation from the AM35xx PRCM engineer(s). At this point one of two possibilities seem likely: either CM_FCLKEN1_CORE.EN_UART4 does nothing, or CM_FCLKEN1_CORE.EN_UART4 is necessary but not sufficient to get the UART4 to work. If CM_FCLKEN1_CORE.EN_UART4 does not actually do anything then we need to remove it from the kernel and ideally file a documentation bug to get it removed from the TRM. On the other hand, if we do have to enable CM_FCLKEN1_CORE.EN_UART4 to deassert the IdleAck to UART4, but the PRCM usecounting is broken, then I guess we'll need to add a workaround to the hwmod code to essentially support multiple "main clocks". - 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
[PATCH v2] usb/dwc3: Fix the dwc3 dependency
The warning shown up when ran with randconfig, warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct dependencies (USB_SUPPORT && USB_XHCI_HCD) Signed-off-by: joseph daniel --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index d8f741f..d13c60f 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -4,7 +4,7 @@ config USB_DWC3 select USB_OTG_UTILS select USB_GADGET_DUALSPEED select USB_GADGET_SUPERSPEED - select USB_XHCI_PLATFORM + select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD help Say Y or M here if your system has a Dual Role SuperSpeed USB controller based on the DesignWare USB3 IP Core. -- 1.7.9.5 -- 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] usb/dwc3: Fix the dwc3 dependency
Hi Felipe, On Fri, May 11, 2012 at 1:27 PM, Felipe Balbi wrote: > On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote: >> The warning shown up when ran with randconfig, >> >> warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct >> dependencies (USB_SUPPORT && USB_XHCI_HCD) >> >> Signed-off-by: joseph daniel >> --- >> drivers/usb/dwc3/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >> index d8f741f..68271fa 100644 >> --- a/drivers/usb/dwc3/Kconfig >> +++ b/drivers/usb/dwc3/Kconfig >> @@ -1,6 +1,6 @@ >> config USB_DWC3 >> tristate "DesignWare USB3 DRD Core Support" >> - depends on (USB && USB_GADGET) >> + depends on (USB && USB_SUPPORT && USB_XCHI_HCD && USB_GADGET) > > typo > > I would prefer the select to change: > > select XHCI_PLATFORM if (USB_SUPPORT && USB_XHCI_HCD) > will do this and send out a patch shotly. > or something similar. > >> select USB_OTG_UTILS >> select USB_GADGET_DUALSPEED >> select USB_GADGET_SUPERSPEED > > -- > balbi Thanks -- 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 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On 5/11/2012 11:35 AM, Paul Walmsley wrote: On Fri, 11 May 2012, Cousson, Benoit wrote: On 5/11/2012 11:22 AM, Paul Walmsley wrote: On the rest of the OMAPs, as far as I know, the UART clocks are all separate. In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same. By "separate" I mean that they are all independently gated. This does not appear to be the case with AM3517. Or perhaps it is the case and something isn't right with the idle management FSMs. But they are not separately gated for OMAP4 either. This is the modulemode trick that make us think that, but it just means that the PRCM should ensure that this clock is needed when at least one UART modulemode is enabled. In fact the SPI modules are using the same clock. The modulemode is used to do some reference counting, but the gating is done globally. It was the same with the FCK_EN and ICK_EN in OMAP2&3. The PRCM spec show only one global gating between FUNC_48M_FCLK and PER_48M_GFCLK. All the modules are sharing the exact same clock. Regards, Benoit -- 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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
From: "Govindraj.R"
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads were used in
different mode by any other module then it would fail since the default
pads took over all the uart pins forcefully. With removal of default pads
the rx_pad wakeup for console uart while waking up from off mode is broken.
Utilise the mux api available to probe the availability of mux pins
in uart mode and probe for availability of uart pin in mux mode0
if uart is available as uart pin itself then configure rx pin
as wakeup capable.
This patch itself doesn't cater to all boards. Boards using uart rx wakeup
mechanism should ensure the usage of omap_serial_init_port by configuring
required uart ports and pass necessary mux data, till then this probing of
uart pins can cater to enabling of rx pad wakeup to most of the boards.
This patch can also throw some boot warning from _omap_mux_get_by_name
if pin is requested for availability is not present while dynamically probing
the uart pins availability such boot warnings can be addressed only when board
files are patched with omap_serial_init_port calls passing the right pads
needed for a given port.
Discussion Threads for reference:
http://www.spinics.net/lists/linux-omap/msg69859.html
http://www.spinics.net/lists/linux-omap/msg68659.html
Cc: Felipe Balbi
Cc: Kevin Hilman
Cc: Russ Dill
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Ameya Palande
Signed-off-by: Govindraj.R
---
Patching of all board files would be difficult as even I am not aware of all
omap-board schematics and uart port usage. So individual board file can be
enabled accordingly for uart usage by calling omap_serial_init_port call
with right mux data.
for testing: Patch based on v3.4-rc6
(tested on beagle-xm for off mode rx wakeup)
Patch targeted for v3.5
arch/arm/mach-omap2/mux.c|3 +-
arch/arm/mach-omap2/mux.h| 11 +++
arch/arm/mach-omap2/serial.c | 65 +++--
3 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..d937ddd 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
-omap_mux_get_by_name(const char *muxname,
+int __init omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..471e62a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -59,6 +59,7 @@
#define OMAP_PIN_OFF_WAKEUPENABLE OMAP_WAKEUP_EN
#define OMAP_MODE_GPIO(x) (((x) & OMAP_MUX_MODE7) == OMAP_MUX_MODE4)
+#define OMAP_MODE_UART(x) (((x) & OMAP_MUX_MODE7) == OMAP_MUX_MODE0)
/* Flags for omapX_mux_init */
#define OMAP_PACKAGE_MASK 0x
@@ -225,8 +226,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+ struct omap_mux_partition **found_partition,
+ struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9fc2f44..2dc50e7 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -57,6 +57,7 @@ struct omap_uart_state {
struct list_head node;
struct omap_hwmod *oh;
+ struct omap_device_pad default_omap_uart_pads[2];
};
static LIST_HEAD(uart_list);
@@ -126,11 +127,68 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+
+static void __init
+omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
+ struct omap_uart_state *uart)
+{
+ uart->default_omap_uart_pads[0].name = rx_pad_name;
+ uart->default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
+ OMAP_DEVICE_PAD_WAKEUP;
+ uart->default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP
Re: [PATCH 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On Fri, 11 May 2012, Cousson, Benoit wrote: > On 5/11/2012 11:22 AM, Paul Walmsley wrote: > > > On the rest of the OMAPs, as far as I know, the UART clocks are all > > separate. > > In fact, not really. The same PER_48M_GFCLK clock is used for every UART > instances in OMAP4. We do have a separate modulemode for each UART but as far > as clocks are concerned, the source clock is the same. By "separate" I mean that they are all independently gated. This does not appear to be the case with AM3517. Or perhaps it is the case and something isn't right with the idle management FSMs. - 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 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
On 5/11/2012 11:22 AM, Paul Walmsley wrote: Hi Benoît On Fri, 11 May 2012, Cousson, Benoit wrote: I do not have any clue about that chip, but is this clock really what it is supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or something like that. Don't we just have an issue becasue the clock names are not accurate? I guess that's what I'm trying to find out. According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 "UART Functional Integration" and Table 14-11 "UART Clocks", all of the UARTs appear to have independent functional clocks. The table even mentions a CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't mention that at all. So the documentation is not too useful here. On the rest of the OMAPs, as far as I know, the UART clocks are all separate. In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same. Regards, Benoit -- 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/2] mfd: twl: remove pdata->irq_base/_end, no more users
Hi Kevin, On Tue, May 08, 2012 at 10:19:02AM -0700, Kevin Hilman wrote: > After converstion to SPARSE_IRQ, the driver doesn't use the > pdata->irq_base/irq_end fields anymore. The last users > have been cleanup up, and now these fields can be removed. > > Cc: Benoit Cousson > Cc: Samuel Ortiz > Signed-off-by: Kevin Hilman Acked-by: Samuel Ortiz Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Hi Benoît On Fri, 11 May 2012, Cousson, Benoit wrote: > I do not have any clue about that chip, but is this clock really what it is > supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or > something like that. Don't we just have an issue becasue the clock names are > not accurate? I guess that's what I'm trying to find out. According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 "UART Functional Integration" and Table 14-11 "UART Clocks", all of the UARTs appear to have independent functional clocks. The table even mentions a CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't mention that at all. So the documentation is not too useful here. On the rest of the OMAPs, as far as I know, the UART clocks are all separate. - Paul
Re: [PATCH v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 2:04 PM, Russ Dill wrote: > On Thu, May 10, 2012 at 6:05 AM, Govindraj.R wrote: >> From: "Govindraj.R" >> >> The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of >> default uart pads) removed default uart pads that where getting populated >> and which was making rx pin wakeup capable. If uart pads was used in >> different mode by any other module then it would fail since the default >> pads took over all the uart pins forcefully. With removal of default pads >> the rx_pad wakeup for console uart while waking up from off mode is broken. [...] >> + * Check if uart is used in default tx/rx mode i.e. in mux >> mode0 >> + * if yes then configure rx pin for wake up capability >> + */ >> + if (!(rx_mode & 0x07) && !(tx_mode & 0x07)) >> + omap_serial_fill_uart_tx_rx_pads(bdata, uart); > > I realize the comment makes it clear, but it'd probably be better to > just make the code clear. I noticed mux.h has a OMAP_MODE_GPIO(x) > macro for testing if a mux is in mode4. Perhaps its time to start > expanding on that, at least with a macro like: > > #define OMAP_MUX_MODE(x) ((x) & OMAP_MUX_MODE7) > > So you can do a OMAP_MUX_MODE(rx_mode) == OMAP_MUX_MODE0 > Yes sure, will add the macro and use the same. (will post v3 addressing the comments received so far) -- 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 v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 12:41 AM, Tony Lindgren wrote:
> * Govindraj.R [120510 06:09]:
>> From: "Govindraj.R"
>>
>> The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
>> default uart pads) removed default uart pads that where getting populated
>> and which was making rx pin wakeup capable. If uart pads was used in
>
> Nitpick.. this should say "were used" here ^^^
will change this.
>
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -295,8 +353,7 @@ void __init omap_serial_board_init(struct
>> omap_uart_port_info *info)
>> bdata.pads = NULL;
>> bdata.pads_cnt = 0;
>>
>> - if (cpu_is_omap44xx() || cpu_is_omap34xx())
>> - omap_serial_fill_default_pads(&bdata);
>> + omap_serial_check_wakeup(&bdata, uart);
>
> Should this section become:
>
> if (!info) {
> omap_serial_check_wakeup(&bdata, uart);
> omap_serial_init_port(&bdata, NULL);
> } else {
> omap_serial_init_port(&bdata, &info[uart->num]);
> }
>
> As if you have bdata, then there should not be anything to mux,
> right?
populating bdata should not depend on port_info,
omap_serial_board_init takes only port info parameter and tries to populate
wakeup parameter since it has not received the same from board file.
And board file may or may not pass port info.
So populating bdata -> for uart wakeup pin should not be coupled with
availability of port info.
--
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 3/3] ARM: OMAP: AM35xx: fix UART4 softreset
Hi Paul,
On 5/10/2012 7:29 PM, Paul Walmsley wrote:
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 1 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or
disabled state
From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise
the reset will never complete. So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process. (The choice of
uart1_fck over uart2_fck was arbitrary.)
Unfortunately this observation raises many questions. Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly? What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like? If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.
I do not have any clue about that chip, but is this clock really what it
is supposed to be? I mean, isn't the uart1_fck the parent of all the
UART fck or something like that. Don't we just have an issue becasue the
clock names are not accurate?
Regards,
Benoit
Cc: Benoît Cousson
Cc: Kyle Manna
Cc: Mark A. Greer
Cc: Ranjith Lohithakshan
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock3xxx_data.c |8 ++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 11644bf..12c64db 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3201,8 +3201,12 @@ static struct clk vpfe_fck = {
};
/*
- * The UART1/2 functional clock acts as the functional
- * clock for UART4. No separate fclk control available.
+ * The UART1/2 functional clock acts as the functional clock for
+ * UART4. No separate fclk control available. XXX Well now we have a
+ * uart4_fck that is apparently used as the UART4 functional clock,
+ * but it also seems that uart1_fck or uart2_fck are still needed, at
+ * least for UART4 softresets to complete. This really needs
+ * clarification.
*/
static struct clk uart4_ick_am35xx = {
.name = "uart4_ick",
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c939131..c6653a80 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -535,6 +535,20 @@ static struct omap_hwmod_dma_info am35xx_uart4_sdma_reqs[]
= {
{ .dma_req = -1 }
};
+/*
+ * XXX AM35xx UART4 cannot complete its softreset without uart1_fck or
+ * uart2_fck being enabled. So we add uart1_fck as an optional clock,
+ * below, and set the HWMOD_CONTROL_OPT_CLKS_IN_RESET. This really
+ * should not be needed. The functional clock structure of the AM35xx
+ * UART4 is extremely unclear and opaque; it is unclear what the role
+ * of uart1/2_fck is for the UART4. Any clarification from either
+ * empirical testing or the AM3505/3517 hardware designers would be
+ * most welcome.
+ */
+static struct omap_hwmod_opt_clk am35xx_uart4_opt_clks[] = {
+ { .role = "softreset_uart1_fck", .clk = "uart1_fck" },
+};
+
static struct omap_hwmod am35xx_uart4_hwmod = {
.name = "uart4",
.mpu_irqs = am35xx_uart4_mpu_irqs,
@@ -549,6 +563,9 @@ static struct omap_hwmod am35xx_uart4_hwmod = {
.idlest_idle_bit = AM35XX_ST_UART4_SHIFT,
},
},
+ .opt_clks = am35xx_uart4_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am35xx_uart4_opt_clks),
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.class =&omap2_uart_class,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
On Fri, May 11, 2012 at 1:33 AM, Paul Walmsley wrote: > Hello Olof, > > On Fri, 11 May 2012, Olof Johansson wrote: > >> I did notice that omap2plus_defconfig has grown a new warning caused >> by "ARM: OMAP2+: clean up some cppcheck warnings" (oh, the irony!): >> >> arch/arm/plat-omap/usb.c: In function 'omap_otg_init': >> arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' >> [-Wunused-variable] > > Thanks, this has been fixed by: > > http://marc.info/?l=linux-omap&m=133660322929805&w=2 Sounds good, I'll wait for it to trickle in on a future pull request. -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: [PATCH v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Thu, May 10, 2012 at 6:05 AM, Govindraj.R wrote:
> From: "Govindraj.R"
>
> The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
> default uart pads) removed default uart pads that where getting populated
> and which was making rx pin wakeup capable. If uart pads was used in
> different mode by any other module then it would fail since the default
> pads took over all the uart pins forcefully. With removal of default pads
> the rx_pad wakeup for console uart while waking up from off mode is broken.
>
> Utilise the mux api available to probe the availability of mux pins
> in uart mode and probe for availability of uart pin in mux mode0
> if uart is available as uart pin itself then configure rx pin
> as wakeup capable.
>
> This patch itself doesn't cater to all boards. Boards using uart rx wakeup
> mechanism should ensure the usage of omap_serial_init_port by configuring
> required uart ports and pass necessary mux data, till then this probing of
> uart pins can cater to enabling of rx pad wakeup to most of the boards.
>
> This patch can also throw some boot warning from _omap_mux_get_by_name
> if pin is requested for availability is not present while dynamically probing
> the uart pins availability such boot warnings can be addressed only when board
> files are patched with omap_serial_init_port calls passing the right pads
> needed for a given port.
>
> Discussion Threads for reference:
> http://www.spinics.net/lists/linux-omap/msg69859.html
> http://www.spinics.net/lists/linux-omap/msg68659.html
>
> Cc: Felipe Balbi
> Cc: Kevin Hilman
> Cc: Russ Dill
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Ameya Palande
> Signed-off-by: Govindraj.R
> ---
>
> Patching of all board files would be difficult as even I am not aware of all
> omap-board schematics and uart port usage. So individual board file can be
> enabled accordingly for uart usage by calling omap_serial_init_port call
> with right mux data.
>
> for testing: Patch based on v3.4-rc6
> (tested on beagle-xm for off mode rx wakeup)
> Patch targeted for v3.5
>
> arch/arm/mach-omap2/mux.c | 3 +-
> arch/arm/mach-omap2/mux.h | 10 ++
> arch/arm/mach-omap2/serial.c | 65 +++--
> 3 files changed, 72 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 65c3391..d937ddd 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -217,8 +217,7 @@ static int __init _omap_mux_get_by_name(struct
> omap_mux_partition *partition,
> return -ENODEV;
> }
>
> -static int __init
> -omap_mux_get_by_name(const char *muxname,
> +int __init omap_mux_get_by_name(const char *muxname,
> struct omap_mux_partition **found_partition,
> struct omap_mux **found_mux)
> {
> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
> index 69fe060..68927f1 100644
> --- a/arch/arm/mach-omap2/mux.h
> +++ b/arch/arm/mach-omap2/mux.h
> @@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int
> nr_pads);
> */
> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
>
> +int omap_mux_get_by_name(const char *muxname,
> + struct omap_mux_partition **found_partition,
> + struct omap_mux **found_mux);
> #else
>
> +static inline int omap_mux_get_by_name(const char *muxname,
> + struct omap_mux_partition **found_partition,
> + struct omap_mux **found_mux)
> +{
> + return 0;
> +}
> +
> static inline int omap_mux_init_gpio(int gpio, int val)
> {
> return 0;
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 9fc2f44..c097317 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -57,6 +57,7 @@ struct omap_uart_state {
>
> struct list_head node;
> struct omap_hwmod *oh;
> + struct omap_device_pad default_omap_uart_pads[2];
> };
>
> static LIST_HEAD(uart_list);
> @@ -126,11 +127,68 @@ static void omap_uart_set_smartidle(struct
> platform_device *pdev) {}
> #endif /* CONFIG_PM */
>
> #ifdef CONFIG_OMAP_MUX
> -static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
> +
> +#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
> +static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
> + tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
> +
> +static void __init
> +omap_serial_fill_uart_tx_rx_pads(struct omap_board_data *bdata,
> + struct omap_uart_state *uart)
> +{
> + uart->default_omap_uart_pads[0].name = rx_pad_name;
> + uart->default_omap_uart_pads[0].flags = OMAP_DEVICE_PAD_REMUX |
> +
> OMAP_DEVICE_PAD_WAKEUP;
> + uart->default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
> + OMAP_MUX_MODE0;
> + uart->default
Re: New OMAP build warning
On Fri, 11 May 2012, Russell King - ARM Linux wrote: > arch/arm/plat-omap/usb.c: In function 'omap_otg_init': > arch/arm/plat-omap/usb.c:40: warning: unused variable 'status' > > caused by: > > commit eeb3711b89d68e147e05e7b43a49ecc5009dc157 > Author: Paul Walmsley > Date: Fri Apr 13 06:34:32 2012 -0600 > > ARM: OMAP2+: clean up some cppcheck warnings Thanks, this has been fixed by: http://marc.info/?l=linux-omap&m=133660322929805&w=2 - 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 1/10] omap non-critical fixes for v3.5 merge window
Hello Olof, On Fri, 11 May 2012, Olof Johansson wrote: > I did notice that omap2plus_defconfig has grown a new warning caused > by "ARM: OMAP2+: clean up some cppcheck warnings" (oh, the irony!): > > arch/arm/plat-omap/usb.c: In function 'omap_otg_init': > arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' > [-Wunused-variable] Thanks, this has been fixed by: http://marc.info/?l=linux-omap&m=133660322929805&w=2 - 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] usb/dwc3: Fix the dwc3 dependency
On Fri, May 11, 2012 at 11:25:24AM +0530, joseph daniel wrote: > The warning shown up when ran with randconfig, > > warning: (USB_DWC3) selects USB_XHCI_PLATFORM which has unmet direct > dependencies (USB_SUPPORT && USB_XHCI_HCD) > > Signed-off-by: joseph daniel > --- > drivers/usb/dwc3/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index d8f741f..68271fa 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -1,6 +1,6 @@ > config USB_DWC3 > tristate "DesignWare USB3 DRD Core Support" > - depends on (USB && USB_GADGET) > + depends on (USB && USB_SUPPORT && USB_XCHI_HCD && USB_GADGET) typo I would prefer the select to change: select XHCI_PLATFORM if (USB_SUPPORT && USB_XHCI_HCD) or something similar. > select USB_OTG_UTILS > select USB_GADGET_DUALSPEED > select USB_GADGET_SUPERSPEED -- balbi signature.asc Description: Digital signature
New OMAP build warning
arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40: warning: unused variable 'status' caused by: commit eeb3711b89d68e147e05e7b43a49ecc5009dc157 Author: Paul Walmsley Date: Fri Apr 13 06:34:32 2012 -0600 ARM: OMAP2+: clean up some cppcheck warnings -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/10] omap non-critical fixes for v3.5 merge window
Tony, I've pulled all 10 requests. Many of them ended up going into the same next/ branch, but that's quite OK. Please double check my merge conflict resolutions. One nit is that at least one of the branches had a few varying patch subjects, so just a friendly reminder to sanitize them to ARM: OMAP.*: or so when you apply patches. I did notice that omap2plus_defconfig has grown a new warning caused by "ARM: OMAP2+: clean up some cppcheck warnings" (oh, the irony!): arch/arm/plat-omap/usb.c: In function 'omap_otg_init': arch/arm/plat-omap/usb.c:40:6: warning: unused variable 'status' [-Wunused-variable] -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: [GIT PULL 8/10] omap timer cleanup for v3.5 merge window
[+sfr]
On Thu, May 10, 2012 at 1:24 PM, Tony Lindgren wrote:
> * Tony Lindgren [120510 11:55]:
>> * Tony Lindgren [120510 11:49]:
>> > The following changes since commit
>> > bfd17879866b36e95c58721da070d9f2ac7f8901:
>> >
>> > Merge tag 'omap-devel-c-for-3.5' of
>> > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
>> > devel-hwmod-data (2012-05-09 09:58:42 -0700)
>> >
>> > are available in the git repository at:
>> >
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
>> > tags/omap-cleanup-timer-for-v3.5
>> >
>> > for you to fetch changes up to 1fe97c8f6a1de67a5f56e029a818903d5bed8017:
>> >
>> > ARM: OMAP: Make OMAP clocksource source selection using kernel param
>> > (2012-05-09 10:07:05 -0700)
>> >
>> >
>> > Timer changes to make it easier to support various SoCs
>> >
>> >
>>
>> And this has a conflict for common headers:
> ...
>
> Also looks like this produces a merge conflict with linux-next
> commit bd0493ea (ARM: 7413/1: move read_{boot,persistent}_clock to
> the architecture level). To resolve, the line to add
> register_persistent_clock(NULL, omap_read_persistent_clock);
> needs to be resolved as below.
Thanks for the heads up. Stephen, see below for tomorrow's -next rebuild.
-Olof
>
> Regards,
>
> Tony
>
>
> --- a/arch/arm/plat-omap/counter_32k.c
> +++ b/arch/arm/plat-omap/counter_32k.c
> @@@ -69,40 -69,55 +70,41 @@@ static void omap_read_persistent_clock(
> *ts = *tsp;
> }
>
> -int __init omap_init_clocksource_32k(void)
> +/**
> + * omap_init_clocksource_32k - setup and register counter 32k as a
> + * kernel clocksource
> + * @pbase: base addr of counter_32k module
> + * @size: size of counter_32k to map
> + *
> + * Returns 0 upon success or negative error code upon failure.
> + *
> + */
> +int __init omap_init_clocksource_32k(void __iomem *vbase)
> {
> - static char err[] __initdata = KERN_ERR
> - "%s: can't register clocksource!\n";
> -
> - if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
> - u32 pbase;
> - unsigned long size = SZ_4K;
> - void __iomem *base;
> - struct clk *sync_32k_ick;
> -
> - if (cpu_is_omap16xx()) {
> - pbase = OMAP16XX_TIMER_32K_SYNCHRONIZED;
> - size = SZ_1K;
> - } else if (cpu_is_omap2420())
> - pbase = OMAP2420_32KSYNCT_BASE + 0x10;
> - else if (cpu_is_omap2430())
> - pbase = OMAP2430_32KSYNCT_BASE + 0x10;
> - else if (cpu_is_omap34xx())
> - pbase = OMAP3430_32KSYNCT_BASE + 0x10;
> - else if (cpu_is_omap44xx())
> - pbase = OMAP4430_32KSYNCT_BASE + 0x10;
> - else
> - return -ENODEV;
> -
> - /* For this to work we must have a static mapping in io.c for
> this area */
> - base = ioremap(pbase, size);
> - if (!base)
> - return -ENODEV;
> -
> - sync_32k_ick = clk_get(NULL, "omap_32ksync_ick");
> - if (!IS_ERR(sync_32k_ick))
> - clk_enable(sync_32k_ick);
> -
> - timer_32k_base = base;
> -
> - /*
> - * 12 rough estimate from the calculations in
> - * __clocksource_updatefreq_scale.
> - */
> - clocks_calc_mult_shift(&persistent_mult, &persistent_shift,
> - 32768, NSEC_PER_SEC, 12);
> -
> - if (clocksource_mmio_init(base, "32k_counter", 32768, 250, 32,
> - clocksource_mmio_readl_up))
> - printk(err, "32k_counter");
> -
> - setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
> - register_persistent_clock(NULL, omap_read_persistent_clock);
> + int ret;
> +
> + /*
> + * 32k sync Counter register offset is at 0x10
> + */
> + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF;
> +
> + /*
> + * 12 rough estimate from the calculations in
> + * __clocksource_updatefreq_scale.
> + */
> + clocks_calc_mult_shift(&persistent_mult, &persistent_shift,
> + 32768, NSEC_PER_SEC, 12);
> +
> + ret = clocksource_mmio_init(sync32k_cnt_reg, "32k_counter", 32768,
> + 250, 32, clocksource_mmio_readl_up);
> + if (ret) {
> + pr_err("32k_counter: can't register clocksource\n");
> + return ret;
> }
> +
> + setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
> + pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
> ++ register_pers
RE: [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
On Fri, May 11, 2012 at 04:32:11, Paul Walmsley wrote: > On Wed, 9 May 2012, Vaibhav Hiremath wrote: > > > In order to remove unnecessary idefs, move noncore and core > > dpll ops to dpll3xxx.c file (where it should have been already). > > > > The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops) > > is used in clock data files, and dependency is already handled by > > Makefile rule. > > > > Signed-off-by: Vaibhav Hiremath > > Cc: Tony Lindgren > > Cc: Kevin Hilman > > Cc: Paul Walmsley > > This is probably okay. > > Acked-by: Paul Walmsley > > Thanks Paul, 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
