RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
Hi,
* Hiremath, Vaibhav hvaib...@ti.com [120502 02:37]:
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
I realize people may not necessarily like this, but I think that the
AM33xx EVM needs its own board file. This is because it really has
nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
except core with omap3. And the SOC is independent of the core selected,
there is no dependency between SoC and the core.
Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
compile with different flags either.
What about cpu_is_omap34xx() true for am33xx? Should we follow it?
Please, no.
I've already demonstrated that that is not necessary and only leads to
confusion and maintenance headaches.
That's what I was expecting...
Probably last question where I have confusion,
Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need
to follow for AM33XX?
I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose
here?
Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
OR
Should we create ARCH_AM, assuming that all AM devices have similar
memory map layout, interrupt mapping, etc...
OR
Should I just add SOC_OMAPAM33XX, wherever required?
Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option,
which is required for AM33XX, how should we handle this?
For example,
arch/arm/plat-omap/include/plat/clock.h
struct dpll_data {
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
dpll related variables
#endif
};
arch/arm/mach-omap2/clock.c
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
const struct clkops clkops_omap3_noncore_dpll_ops = {
};
const struct clkops clkops_omap3_core_dpll_ops = {
}
--
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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Russ, On 05/03/12 22:08, Russ Dill wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. -- Thanks, Govindraj.R [1]: http://pastebin.pandaboard.org/index.php/view/20343533 I've tracked down the difference. I'm loading my uEnv.txt and uImage in u-boot from the network which means initializing USB. You are loading straight from MMC. If I switch to loading straight from MMC everything works. Can everyone do a 'usb start' in u-boot before booting and re-test? I'm pretty sure this is a regression, but the bug could be a strange u-boot/kernel interaction. Probably, kernel code does not reinitialize EHCI correctly if it was already enabled? Can you try the below sequence: usb start usb stop boot Linux ? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 88 ++---
1 file changed, 74 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 07232fd..46d2a98 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev,
unsigned long tput)
return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
}
+static struct platform_device *create_dss_pdev(const char *pdev_name,
+ int pdev_id, const char *oh_name, void *pdata, int pdata_len,
+ struct platform_device *parent)
This function looks quite generic, it's like omap_device_build() but
with a parent associated. omap_device_build() seems to be a special case
of this function with parent passed as null. Won't this
function be needed by other devices too?
Maybe we could modify omap_device_build_ss() to take a parent argument,
and make a function called omap_device_build_parent(), where both
omap_device_build() and omap_device_build_parent() call
omap_device_build_ss()?
Archit
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ struct omap_hwmod *ohs[1];
+ struct omap_hwmod *oh;
+ int r;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ r = -ENODEV;
+ goto err;
+ }
+
+ pdev = platform_device_alloc(pdev_name, pdev_id);
+ if (!pdev) {
+ pr_err(Could not create pdev for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ if (parent != NULL)
+ pdev-dev.parent =parent-dev;
+
+ if (pdev-id != -1)
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ else
+ dev_set_name(pdev-dev, %s, pdev-name);
+
+ ohs[0] = oh;
+ od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
+ if (!od) {
+ pr_err(Could not alloc omap_device for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ r = platform_device_add_data(pdev, pdata, pdata_len);
+ if (r) {
+ pr_err(Could not set pdata for %s\n, pdev_name);
+ goto err;
+ }
+
+ r = omap_device_register(pdev);
+ if (r) {
+ pr_err(Could not register omap_device for %s\n, pdev_name);
+ goto err;
+ }
+
+ return pdev;
+
+err:
+ return ERR_PTR(r);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
- struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
+ struct platform_device *dss_pdev;
/* create omapdss device */
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- for (i = 0; i oh_count; i++) {
- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n,
- curr_dss_hwmod[i].oh_name);
- return -ENODEV;
- }
+ dss_pdev = NULL;
- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,
+ for (i = 0; i oh_count; i++) {
+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+ curr_dss_hwmod[i].id,
+ curr_dss_hwmod[i].oh_name,
NULL, 0,
- NULL, 0, 0);
+ dss_pdev);
+
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s\n,
+ curr_dss_hwmod[i].oh_name);
+
+ return PTR_ERR(pdev);
+ }
- if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
- curr_dss_hwmod[i].oh_name))
- return -ENODEV;
+ if (i == 0)
+ dss_pdev = pdev;
}
return 0;
--
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
RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Fri, May 04, 2012 at 01:07:32, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120503 09:45]: What about cpu_is_omap34xx() true for am33xx? Should we follow it? Well are there components that could be used as is with that? If not, then it probably does not make sense. I am also in favor of not following cpu_is_omap34xx() for am33xx, but what about ARCH_OMAP? I don't see that you are in agreement in creating ARCH_OMAPAM33XX. Does it make sense to say that, for am33xx, cpu_is_omap34xx() is false, but still it is under ARCH_OMAP3? BTW, you should post your patches on top of the clean-up patches Santosh posted as that already leaves out some cpu_is_omap checks. That's the ARM: OMAP2+: Misc cleanup thread. Ok. I will do that. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote: Hi, * Hiremath, Vaibhav hvaib...@ti.com [120502 02:37]: On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote: Hi On Fri, 2 Dec 2011, hvaib...@ti.com wrote: From: Afzal Mohammed af...@ti.com This patch adds minimal support for AM335X EVM. The approach taken here is to add AM335X EVM support to AM3517EVM, considering the fact that with device tree developement we will get rid of board-*.c. Signed-off-by: Afzal Mohammed af...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com I realize people may not necessarily like this, but I think that the AM33xx EVM needs its own board file. This is because it really has nothing to do with the AM3517EVM. Also, the AM3517EVM depends on CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4. I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything except core with omap3. And the SOC is independent of the core selected, there is no dependency between SoC and the core. Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to compile with different flags either. But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where, we have issues for adding new devices like AM33xx and TI81xx. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver
On Friday 04 May 2012 05:33 AM, Greg KH wrote: On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote: On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs Hi Santosh, Can you send Greg a patch that adds proper dependencies to the Kconfig? I was going to simply add an ARM dependency, but perhaps you want to restrict it further to a subset of OMAP platforms? Thanks Paul for reporting the issue. At the moment it is causing build failures in other architectures. http://kisskb.ellerman.id.au/kisskb/buildresult/6243036/ I think there's a config option for readl/writel, but yes, ARM would probably be fine as well. Just send a patch [1] to Greg. EMIF driver build is restricted to ARCH_OMAP2PLUS for now and can be extended later if any other non OMAP architecture start using it. Regards Santosh [1] https://lkml.org/lkml/2012/5/4/22 -- 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] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces
Hi Archit, On Fri, 13 Apr 2012, Archit Taneja wrote: On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote: On 4/13/2012 10:01 AM, Archit Taneja wrote: The clock for all DSS L3 slave interfaces had been recently changed to dss_fck from l3_div_ck. dss_fck is an optional clock in DSS clock domain which can't autoidle when enabled. Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS hwmods so that clock is explicitly enabled and disabled by software. Without this, dss_fck would be left as enabled and the OMAP4 device won't idle even when DSS is not in use. Yeah, that was done on purpose with Tomi knowning well that limitation. The issue was mainly due to the lack of proper parent / child relationship between the DSS (the whole subsystem) and the DSS children at that time. I think that Tomi posted a series to fix that for 3.4. So if we ensure that every DSS IPs are children of the DSS, then pm_runtime will always ensure that the DSS will be enabled each time a submodule is used. So the right fix is to put back the proper iclk (l3_div) to the DSS instead of the dss_fck. Ok, I get it now. Tomi's patch series ensured the parent-child dependency, but they didn't switch the iclks back to l3_div, I guess that should be a part of the series too. Just checking on this one. Does this patch need to be updated ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. Aim of DMA helpers - The purpose of device-tree (as far as I understand), is to describe the capabilites of the hardware. Thinking about DMA controllers purely from the context of the hardware to begin with, we can describe a device in terms of a DMA controller as follows ... 1. Number of DMA controllers 2. Number of channels (maybe physical or logical) 3. Mapping of DMA requests signals to DMA controller 4. Number of DMA interrupts 5. Mapping of DMA interrupts to channels - With the above in mind the aim of the DT DMA helper functions is to extract the above information from the DT and provide to the appropriate driver. However, due to the vast number of DMA controllers and not all are using a common driver (such as DMA Engine) it has been seen that this is not a trivial task. Sorry for being slow, but so far I thought DT is only to provide _h/w_ specific info to the _controller_ drivers. It was not supposed to provide any info pertaining to some API (dmaengine in this case). And I believe this is one of few situations where we are better off not generalizing the interface - pass controller specific info in the controller driver's specified format. Generalizing only seems to complicate things here, when we anyway have machine specific dtb, which could always have clients requesting and the controllers given dma's info in controller driver's specific format. Perhaps I am overlooking the need to generalize. If you think so, please help me understand by pointing out some use case for it. 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 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces
Hi Paul, On Friday 04 May 2012 12:09 PM, Paul Walmsley wrote: Hi Archit, On Fri, 13 Apr 2012, Archit Taneja wrote: On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote: On 4/13/2012 10:01 AM, Archit Taneja wrote: The clock for all DSS L3 slave interfaces had been recently changed to dss_fck from l3_div_ck. dss_fck is an optional clock in DSS clock domain which can't autoidle when enabled. Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS hwmods so that clock is explicitly enabled and disabled by software. Without this, dss_fck would be left as enabled and the OMAP4 device won't idle even when DSS is not in use. Yeah, that was done on purpose with Tomi knowning well that limitation. The issue was mainly due to the lack of proper parent / child relationship between the DSS (the whole subsystem) and the DSS children at that time. I think that Tomi posted a series to fix that for 3.4. So if we ensure that every DSS IPs are children of the DSS, then pm_runtime will always ensure that the DSS will be enabled each time a submodule is used. So the right fix is to put back the proper iclk (l3_div) to the DSS instead of the dss_fck. Ok, I get it now. Tomi's patch series ensured the parent-child dependency, but they didn't switch the iclks back to l3_div, I guess that should be a part of the series too. Just checking on this one. Does this patch need to be updated ? We were working on this, but we realised that only having a parent-child relation in dss platform devices won't be sufficient to remove the use of dss_fck(or MODULEMODE bits) as a slave clock hack. The issue is that during bootup(when omap_hwmod_setup_all() is called), all hwmods are enabled independently, so all dss hwmods need to enable the MODULEMODE bits for them to be setup correctly. With the parent-child relation in platform devices in DSS, only the parent platform device's hwmod(dss_core in our case) should enable and disable the MODULEMODE bits. If the children also become capable of enabling/disabling it, then things wouldn't work. Hence, to go ahead with this approach, the hwmod's themselves need to have some sort of parent child relationship, or atleast some sort of use counting for MODULEMODE bits. Benoit and Tomi could comment more on this. Hence we are sort of stuck :) Archit - 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 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.
On Fri, May 4, 2012 at 3:17 AM, Kevin Hilman khil...@ti.com wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code cpu checks accordingly so that there is no need to patch the file for any future OMAP2+ devices. In long run, all these attributes should come from hwmod dev_attr based on DMA IP version. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/dma.c | 2 +- arch/arm/plat-omap/dma.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index b19d849..2750bb9 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) dma_stride = OMAP2_DMA_STRIDE; dma_common_ch_start = CSDP; - if (cpu_is_omap3630() || cpu_is_omap44xx()) + if (omap_rev() = OMAP3630_REV_ES1_0) It's not obvious (at least to me) that this is equivalent. For example, this will now be true on the TI81xx devices. I see your point. On second thought, i decided to drop this hunk from the patch since the availability of the dma descriptor feature can be read from dma capability register. Will post another patch for it and also add it to the clean-up series. Updated $subject patch in the end of email. Regards Santosh From e42966bc56b1603e033b5b259564ae149b11a5d9 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Sat, 28 Apr 2012 20:19:10 +0530 Subject: [PATCH 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching. cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code cpu checks accordingly so that there is no need to patch the file for any future OMAP2+ devices. In long run, all these attributes should come from hwmod dev_attr based on DMA IP version. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Dropped the hunk for descriptor feature check based on OMAP cpu version since it can be handled with DMA hardware capability register read. arch/arm/plat-omap/dma.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ecdb3da..c046a19 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -843,7 +843,7 @@ omap_dma_set_prio_lch(int lch, unsigned char read_prio, } l = p-dma_read(CCR, lch); l = ~((1 6) | (1 26)); - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) l |= ((read_prio 0x1) 6) | ((write_prio 0x1) 26); else l |= ((read_prio 0x1) 6); @@ -2057,7 +2057,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev) } } - if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) + if (cpu_class_is_omap2() !cpu_is_omap242x()) omap_dma_set_global_params(DMA_DEFAULT_ARB_RATE, DMA_DEFAULT_FIFO_DEPTH, 0); -- 1.7.5.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] ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.
The system dma module has capabiities register indicating
the support for descriptor loading, constant fill, etc.
Use this instead of OMAP revision check to identify the features
supported runtime.
This avoids patching the code for feature SOCs which has
those capabilities.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/dma.c | 11 +++
arch/arm/plat-omap/include/plat/dma.h |5 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index b19d849..ff75abe 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -227,10 +227,6 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dma_stride = OMAP2_DMA_STRIDE;
dma_common_ch_start = CSDP;
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- dma_common_ch_end = CCDN;
- else
- dma_common_ch_end = CCFN;
p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
if (!p) {
@@ -277,6 +273,13 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
dev_err(pdev-dev, %s: kzalloc fail\n, __func__);
return -ENOMEM;
}
+
+ /* Check the capabilities register for descriptor loading feature */
+ if (dma_read(CAPS_0, 0) DMA_HAS_DESCRIPTOR_CAPS)
+ dma_common_ch_end = CCDN;
+ else
+ dma_common_ch_end = CCFN;
+
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index dc562a5..7742204 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -312,6 +312,11 @@
#define CLEAR_CSR_ON_READ BIT(0xC)
#define IS_WORD_16 BIT(0xD)
+/* Defines for DMA Capabilities */
+#define DMA_HAS_TRANSPARENT_CAPS (0x1 18)
+#define DMA_HAS_CONSTANT_FILL_CAPS (0x1 19)
+#define DMA_HAS_DESCRIPTOR_CAPS(0x3 20)
+
enum omap_reg_offsets {
GCR, GSCR, GRST1, HW_ID,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.
On Fri, May 4, 2012 at 12:59 PM, R Sricharan r.sricha...@ti.com wrote: The system dma module has capabiities register indicating the support for descriptor loading, constant fill, etc. Use this instead of OMAP revision check to identify the features supported runtime. This avoids patching the code for feature SOCs which has those capabilities. Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/dma.c | 11 +++ arch/arm/plat-omap/include/plat/dma.h | 5 + 2 files changed, 12 insertions(+), 4 deletions(-) Looks fine. Will add it to my clean-up series if no has any objection on the patch. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 88 ++---
1 file changed, 74 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 07232fd..46d2a98 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev,
unsigned long tput)
return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
}
+static struct platform_device *create_dss_pdev(const char *pdev_name,
+ int pdev_id, const char *oh_name, void *pdata, int pdata_len,
+ struct platform_device *parent)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ struct omap_hwmod *ohs[1];
+ struct omap_hwmod *oh;
+ int r;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ r = -ENODEV;
+ goto err;
+ }
+
+ pdev = platform_device_alloc(pdev_name, pdev_id);
+ if (!pdev) {
+ pr_err(Could not create pdev for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ if (parent != NULL)
+ pdev-dev.parent =parent-dev;
+
+ if (pdev-id != -1)
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ else
+ dev_set_name(pdev-dev, %s, pdev-name);
+
+ ohs[0] = oh;
+ od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
+ if (!od) {
+ pr_err(Could not alloc omap_device for %s\n, pdev_name);
+ r = -ENOMEM;
+ goto err;
+ }
+
+ r = platform_device_add_data(pdev, pdata, pdata_len);
+ if (r) {
+ pr_err(Could not set pdata for %s\n, pdev_name);
+ goto err;
+ }
+
+ r = omap_device_register(pdev);
+ if (r) {
+ pr_err(Could not register omap_device for %s\n, pdev_name);
+ goto err;
+ }
+
+ return pdev;
+
+err:
+ return ERR_PTR(r);
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
- struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
+ struct platform_device *dss_pdev;
/* create omapdss device */
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- for (i = 0; i oh_count; i++) {
- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n,
- curr_dss_hwmod[i].oh_name);
- return -ENODEV;
- }
+ dss_pdev = NULL;
- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,
+ for (i = 0; i oh_count; i++) {
+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+ curr_dss_hwmod[i].id,
+ curr_dss_hwmod[i].oh_name,
NULL, 0,
- NULL, 0, 0);
+ dss_pdev);
+
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s\n,
+ curr_dss_hwmod[i].oh_name);
+
+ return PTR_ERR(pdev);
+ }
- if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
- curr_dss_hwmod[i].oh_name))
- return -ENODEV;
+ if (i == 0)
+ dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, dss_core))
dss_pdev = pdev;
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
omapdss). Is it just a way to get the board data?
Archit
}
return 0;
--
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 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin, I want to point out some cases of SR implementation where this may not be true. Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR. Under this, SR module issues an interrupt to ARM when there is a need to change the voltage based on temperature changes, ageing etc. Once the interrupt arrives, kernel needs to adjust voltage using regulator API. The voltage change is a micro adjustment as in other SR classes. The SR class 2B implementation on these devices does not exist in mainline. I can point to some public repositories if you are interested in taking a look at the current code. Implementation of this SR method is must on at least the DM8168 device and I know some customers who are using it on their production systems. Regards AnilKumar -- 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 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/mach-omap2/smartreflex.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 144d118..15907b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_mpu_irqs[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_core_irqs[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
@@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
Regards
AnilKumar
--
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 08/25] OMAPDSS: clean up the omapdss platform data mess
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 39
+++
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 62 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 60cded4..07232fd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,10 +191,24 @@ int __init omap_display_init(struct
omap_dss_board_info *board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+ board_data-set_min_bus_tput = omap_dss_set_min_bus_tput;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
After this patch, the omapdss platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 39
+++
drivers/video/omap2/dss/core.c | 35 +++
drivers/video/omap2/dss/dispc.c | 21 ++---
drivers/video/omap2/dss/dsi.c | 17 +++--
drivers/video/omap2/dss/dss.h |3 +++
drivers/video/omap2/dss/hdmi.c |2 --
include/video/omapdss.h |5 -
7 files changed, 62 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 60cded4..07232fd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
- struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
- memset(pdata, 0, sizeof(pdata));
+ /* create omapdss device */
+
+ board_data-dsi_enable_pads = omap_dsi_enable_pads;
+ board_data-dsi_disable_pads = omap_dsi_disable_pads;
+ board_data-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+ board_data-set_min_bus_tput = omap_dss_set_min_bus_tput;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
After this patch, the omapdss platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Oh okay, I don't know where the initcalls exactly happen, but I guess
they will happen after the .init_machine op in the board file.
Do you know where the initcalls happen, I couldn't find it by browsing
the kernel code :)
Archit
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: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
On Fri, 2012-05-04 at 11:33 +0530, Archit Taneja wrote: Hi, On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote: Instead of using omap_device_build() to create the omap_devices for DSS hwmods, create them with a custom function. This will allow us to create a parent-child hierarchy for the devices so that the omapdss_core device is parent for the rest of the dss hwmod devices. Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c | 88 ++--- 1 file changed, 74 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 07232fd..46d2a98 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput) return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput); } +static struct platform_device *create_dss_pdev(const char *pdev_name, + int pdev_id, const char *oh_name, void *pdata, int pdata_len, + struct platform_device *parent) This function looks quite generic, it's like omap_device_build() but with a parent associated. omap_device_build() seems to be a special case of this function with parent passed as null. Won't this function be needed by other devices too? Maybe we could modify omap_device_build_ss() to take a parent argument, and make a function called omap_device_build_parent(), where both omap_device_build() and omap_device_build_parent() call omap_device_build_ss()? Yes, that sounds good to me. Paul, Kevin, what do you think, could the omap_device functions be extended to allow setting a parent device? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess
On Fri, 2012-05-04 at 14:06 +0530, Archit Taneja wrote: On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote: Hmm. The sequence shouldn't change. The order in which the devices are registered doesn't matter if there are no drivers registered yet. When the drivers are registered, and there's a device for it, the probe will be done. So in this case the order of the driver registration will dictate the order of probes. Oh okay, I don't know where the initcalls exactly happen, but I guess they will happen after the .init_machine op in the board file. Do you know where the initcalls happen, I couldn't find it by browsing the kernel code :) Well, include/linux/init.h lists the inits in order. machine init is not there, I guess it's not part of the init order, but even earlier. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces
On Fri, 2012-05-04 at 12:33 +0530, Archit Taneja wrote: Hi Paul, On Friday 04 May 2012 12:09 PM, Paul Walmsley wrote: Hi Archit, On Fri, 13 Apr 2012, Archit Taneja wrote: On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote: On 4/13/2012 10:01 AM, Archit Taneja wrote: The clock for all DSS L3 slave interfaces had been recently changed to dss_fck from l3_div_ck. dss_fck is an optional clock in DSS clock domain which can't autoidle when enabled. Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS hwmods so that clock is explicitly enabled and disabled by software. Without this, dss_fck would be left as enabled and the OMAP4 device won't idle even when DSS is not in use. Yeah, that was done on purpose with Tomi knowning well that limitation. The issue was mainly due to the lack of proper parent / child relationship between the DSS (the whole subsystem) and the DSS children at that time. I think that Tomi posted a series to fix that for 3.4. So if we ensure that every DSS IPs are children of the DSS, then pm_runtime will always ensure that the DSS will be enabled each time a submodule is used. So the right fix is to put back the proper iclk (l3_div) to the DSS instead of the dss_fck. Ok, I get it now. Tomi's patch series ensured the parent-child dependency, but they didn't switch the iclks back to l3_div, I guess that should be a part of the series too. Just checking on this one. Does this patch need to be updated ? We were working on this, but we realised that only having a parent-child relation in dss platform devices won't be sufficient to remove the use of dss_fck(or MODULEMODE bits) as a slave clock hack. The issue is that during bootup(when omap_hwmod_setup_all() is called), all hwmods are enabled independently, so all dss hwmods need to enable the MODULEMODE bits for them to be setup correctly. With the parent-child relation in platform devices in DSS, only the parent platform device's hwmod(dss_core in our case) should enable and disable the MODULEMODE bits. If the children also become capable of enabling/disabling it, then things wouldn't work. Hence, to go ahead with this approach, the hwmod's themselves need to have some sort of parent child relationship, or atleast some sort of use counting for MODULEMODE bits. Benoit and Tomi could comment more on this. Hence we are sort of stuck :) Yes, this is my understanding also. I got the impression from Benoit that adding such a parent-child relationship is not trivial. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
@@ -221,22 +279,24 @@ int __init omap_display_init(struct
omap_dss_board_info *board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- for (i = 0; i oh_count; i++) {
- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n,
- curr_dss_hwmod[i].oh_name);
- return -ENODEV;
- }
+ dss_pdev = NULL;
- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,
+ for (i = 0; i oh_count; i++) {
+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+ curr_dss_hwmod[i].id,
+ curr_dss_hwmod[i].oh_name,
NULL, 0,
- NULL, 0, 0);
+ dss_pdev);
+
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s\n,
+ curr_dss_hwmod[i].oh_name);
+
+ return PTR_ERR(pdev);
+ }
- if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
- curr_dss_hwmod[i].oh_name))
- return -ENODEV;
+ if (i == 0)
+ dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, dss_core))
dss_pdev = pdev;
I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:
dss_pdev = create_the_device();
for () {
// create the rest of the devices
create_the_device();
}
and that would clarify what's going on.
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
omapdss). Is it just a way to get the board data?
Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.
As I see it, omapdss is currently a virtual higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.
I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.
For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Thu, May 3, 2012 at 11:03 PM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Russ, On 05/03/12 22:08, Russ Dill wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. -- Thanks, Govindraj.R [1]: http://pastebin.pandaboard.org/index.php/view/20343533 I've tracked down the difference. I'm loading my uEnv.txt and uImage in u-boot from the network which means initializing USB. You are loading straight from MMC. If I switch to loading straight from MMC everything works. Can everyone do a 'usb start' in u-boot before booting and re-test? I'm pretty sure this is a regression, but the bug could be a strange u-boot/kernel interaction. Probably, kernel code does not reinitialize EHCI correctly if it was already enabled? Can you try the below sequence: usb start usb stop boot Linux That doesn't work. Rebooting does work though. -- 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 24/25] OMAPDSS: DSI: improve DSI module id handling
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
We currently use the id of the dsi platform device (dsidev-id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the dsi_pdev_map
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
Archit
Instead of using dsidev-id during operation, this patch stores the
value of dsidev-id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 46 +++--
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6cc92a8..ce964dd 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -256,6 +256,8 @@ struct dsi_data {
struct platform_device *pdev;
void __iomem*base;
+ int module_id;
+
int irq;
struct clk *dss_clk;
@@ -358,11 +360,6 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
return dsi_pdev_map[module];
}
-static inline int dsi_get_dsidev_id(struct platform_device *dsidev)
-{
- return dsidev-id;
-}
-
static inline void dsi_write_reg(struct platform_device *dsidev,
const struct dsi_reg idx, u32 val)
{
@@ -1181,10 +1178,9 @@ static unsigned long dsi_get_txbyteclkhs(struct
platform_device *dsidev)
static unsigned long dsi_fclk_rate(struct platform_device *dsidev)
{
unsigned long r;
- int dsi_module = dsi_get_dsidev_id(dsidev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- if (dss_get_dsi_clk_source(dsi_module) == OMAP_DSS_CLK_SRC_FCK) {
+ if (dss_get_dsi_clk_source(dsi-module_id) == OMAP_DSS_CLK_SRC_FCK) {
/* DSI FCLK source is DSS_CLK_FCK */
r = clk_get_rate(dsi-dss_clk);
} else {
@@ -1683,7 +1679,7 @@ static void dsi_dump_dsidev_clocks(struct platform_device
*dsidev,
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct dsi_clock_info *cinfo =dsi-current_cinfo;
enum omap_dss_clk_source dispc_clk_src, dsi_clk_src;
- int dsi_module = dsi_get_dsidev_id(dsidev);
+ int dsi_module = dsi-module_id;
dispc_clk_src = dss_get_dispc_clk_source();
dsi_clk_src = dss_get_dsi_clk_source(dsi_module);
@@ -1755,7 +1751,6 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
unsigned long flags;
struct dsi_irq_stats stats;
- int dsi_module = dsi_get_dsidev_id(dsidev);
spin_lock_irqsave(dsi-irq_stats_lock, flags);
@@ -1772,7 +1767,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
#define PIS(x) \
seq_printf(s, %-20s %10d\n, #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
- seq_printf(s, -- DSI%d interrupts --\n, dsi_module + 1);
+ seq_printf(s, -- DSI%d interrupts --\n, dsi-module_id + 1);
PIS(VC0);
PIS(VC1);
PIS(VC2);
@@ -2272,7 +2267,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
DSSDBGF();
- r = dss_dsi_enable_pads(dsi_get_dsidev_id(dsidev),
dsi_get_lane_mask(dssdev));
+ r = dss_dsi_enable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
if (r)
return r;
@@ -2382,20 +2377,21 @@ err_cio_pwr:
dsi_cio_disable_lane_override(dsidev);
err_scp_clk_dom:
dsi_disable_scp_clk(dsidev);
- dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev),
dsi_get_lane_mask(dssdev));
+ dss_dsi_disable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
return r;
}
static void dsi_cio_uninit(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
/* DDR_CLK_ALWAYS_ON */
REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 0, 13, 13);
dsi_cio_power(dsidev,
RE: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
include/linux/power/smartreflex.h | 23 ++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+ IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include linux/types.h
#include linux/platform_device.h
-
+#include linux/delay.h
#include plat/voltage.h
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
I think we can use time_after()/time_before() APIs for timeout and cpu_relax()
for
tight loops instead of udelay().
Regards
AnilKumar
--
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 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
On Friday 04 May 2012 02:30 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
- for (i = 0; i oh_count; i++) {
- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
- if (!oh) {
- pr_err(Could not look up %s\n,
- curr_dss_hwmod[i].oh_name);
- return -ENODEV;
- }
+ dss_pdev = NULL;
- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
- curr_dss_hwmod[i].id, oh,
+ for (i = 0; i oh_count; i++) {
+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+ curr_dss_hwmod[i].id,
+ curr_dss_hwmod[i].oh_name,
NULL, 0,
- NULL, 0, 0);
+ dss_pdev);
+
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s\n,
+ curr_dss_hwmod[i].oh_name);
+
+ return PTR_ERR(pdev);
+ }
- if (WARN((IS_ERR(pdev)), Could not build omap_device for %s\n,
- curr_dss_hwmod[i].oh_name))
- return -ENODEV;
+ if (i == 0)
+ dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, dss_core))
dss_pdev = pdev;
I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:
Right, my suggestion wont work either.
dss_pdev = create_the_device();
for () {
// create the rest of the devices
create_the_device();
}
and that would clarify what's going on.
Yes, or you could just add a comment saying i == 0 is the dss_core
hwmod, and we make sure dss_core is the first one on the list.
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
omapdss). Is it just a way to get the board data?
Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.
As I see it, omapdss is currently a virtual higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.
I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.
For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.
Okay, makes sense now.
Thanks,
Archit
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: Problems with 3.4-rc5
-Original Message-
From: Tomi Valkeinen tomi.valkei...@ti.com
To: Joe Woodward j...@terrafix.co.uk
Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 16:07:22 +0300
Subject: Re: Problems with 3.4-rc5
On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
Both patches together results in slightly different behaviour, the
display is still broken-
it flickers on and off with occassional underflows before breaking
completely.
Beagle works fine for me with omap2plus based config, and I think overo
also although I can't test it now as I broke my micro mmc adapter.
Can you send your panel definition? Any other things that could affect
display? Do you have PM enabled? Can you share your kernel config?
Tomi
I've gone back to a test setup others can replicate.
I have a GUSMTIX Overo Earth (OMAP3503-based), running in a
Chestnut43 board with a connect 4.3 Samsung LCD panel (480x320).
(my previous emails were using a GUMSTIX Overo AirSTORM (AM3703),
but the results seem to be the same with the Earth)
I've built stock 3.4-rc5 using the omap2plus_defconfig (using the
CodeSorcery toolchain: arm-2010.09-50-arm-none-linux-gnueabi.bin).
I've had to make the following changes to the defconfig for my RFS (I've
attached the defconfig for reference):
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=4
CONFIG_FB_OMAP2=y
CONFIG_PANEL_GENERIC_DPI=y
CONFIG_TUN=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SQUASHFS=y
I've also set the LCD to the default display device in board-overo.c:
static struct omap_dss_board_info overo_dss_data = {
.num_devices = ARRAY_SIZE
(overo_dss_devices),
.devices = overo_dss_devices,
.default_device = overo_lcd43_device, /* @@
Default to LCD*/
};
I'm booting using uBoot 2012.04.01, and run everything from RAM.
When booting I can see the Linux boot logo for a short time.
The log is pasted below, but you can see:
[6.621215] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
the overlay
Cheers,
Joe
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version
4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 3 15:38:04 BST
2012
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),
cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[0.00] Machine: Gumstix Overo
[0.00] Reserving 4194304 bytes SDRAM for VRAM
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[0.00] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192
d13056 u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 128768
[0.00] Kernel command line: console=ttyO2,115200
omapfb.rotate=0 root=/dev/ram0 rw ramdisk_size=98304
initrd=0x8100,96M rootfstype=squashfs
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.00] Memory: 507MB = 507MB total
[0.00] Memory: 403416k/403416k available, 120872k reserved, 0K
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB)
[0.00] lowmem : 0xc000 - 0xe000 ( 512 MB)
[0.00] modules : 0xbf00 - 0xc000 ( 16 MB)
[0.00] .text : 0xc0008000 - 0xc065e058 (6489 kB)
[0.00] .init : 0xc065f000 - 0xc06acd00 ( 312 kB)
[0.00] .data : 0xc06ae000 - 0xc0740d18 ( 588 kB)
[0.00].bss : 0xc0740d3c - 0xc0c96b20 (5464 kB)
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:474
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96
interrupts
[0.00] Total of 96 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps
every 131071999ms
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES: 8
[0.00] ... MAX_LOCK_DEPTH: 48
[0.00] ... MAX_LOCKDEP_KEYS:8191
[0.00] ... CLASSHASH_SIZE: 4096
[0.00] ... MAX_LOCKDEP_ENTRIES: 16384
[0.00] ... MAX_LOCKDEP_CHAINS: 32768
[0.00] ... CHAINHASH_SIZE: 16384
[0.00]
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On 05/04/12 12:06, Russ Dill wrote: On Thu, May 3, 2012 at 11:03 PM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Russ, On 05/03/12 22:08, Russ Dill wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. -- Thanks, Govindraj.R [1]: http://pastebin.pandaboard.org/index.php/view/20343533 I've tracked down the difference. I'm loading my uEnv.txt and uImage in u-boot from the network which means initializing USB. You are loading straight from MMC. If I switch to loading straight from MMC everything works. Can everyone do a 'usb start' in u-boot before booting and re-test? I'm pretty sure this is a regression, but the bug could be a strange u-boot/kernel interaction. Probably, kernel code does not reinitialize EHCI correctly if it was already enabled? Can you try the below sequence: usb start usb stop boot Linux That doesn't work. Rebooting does work though. This means that U-Boot's usb stop command is also not clean enough... So we have two problems here, one is related to kernel USB initialization and the second to U-Boot usb stop command... -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
We currently use the id of the dsi platform device (dsidev-id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the dsi_pdev_map
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
This is only a problem with device tree, and I solved it so that I pass
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi-module_id from the pdev-id, but with DT I initialize
dsi-module_id from the DT data.
So basically we remove the use of pdev-id in this patch, and add
dsi-module_id field, which needs to be initialized to 0 or 1, depending
on the corresponding HW module. We just happen to use the pdev-id to
initialize it when using the old pdata method, as we know it tells the
right id. But we could initialize it from any other source.
This allows us to keep the 0 and 1 DSI IDs, and I think we need those
anyway. Some parts of the code could work fine with arbitrary ID, as
long as a pdev can be linked to/from this ID. However, there are things
where we must have the ID, like configuring the clock source settings in
dss_core, where we set a certain bit for DSI module 0, and certain bit
for module 1.
Perhaps even those could be handled without explicit ID of 0 or 1, but
that doesn't sound trivial and I didn't want to start tackling that in
this series.
I wish there was a way to get the module ID from the HW registers
somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
very correct. At least with DT it's a bit wrong, in my opinion, but best
I could come up with.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling
On Friday 04 May 2012 03:23 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
We currently use the id of the dsi platform device (dsidev-id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the dsi_pdev_map
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
This is only a problem with device tree, and I solved it so that I pass
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi-module_id from the pdev-id, but with DT I initialize
dsi-module_id from the DT data.
Oh ok, so the code which decides how dsi-module_id is initialised(from
DT or pdata) is not in this series right? And it would come later? Right
now it's just set to dsidev-id in probe.
So basically we remove the use of pdev-id in this patch, and add
dsi-module_id field, which needs to be initialized to 0 or 1, depending
on the corresponding HW module. We just happen to use the pdev-id to
initialize it when using the old pdata method, as we know it tells the
right id. But we could initialize it from any other source.
Right, I get it now.
This allows us to keep the 0 and 1 DSI IDs, and I think we need those
anyway. Some parts of the code could work fine with arbitrary ID, as
long as a pdev can be linked to/from this ID. However, there are things
where we must have the ID, like configuring the clock source settings in
dss_core, where we set a certain bit for DSI module 0, and certain bit
for module 1.
Perhaps even those could be handled without explicit ID of 0 or 1, but
that doesn't sound trivial and I didn't want to start tackling that in
this series.
I wish there was a way to get the module ID from the HW registers
somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
very correct. At least with DT it's a bit wrong, in my opinion, but best
I could come up with.
We could derive it via a parameter like number of lanes or something
similar through DSI_GNQ, but that doesn't seem very nice, and may not be
usable on future OMAPs.
Archit
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: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
Hi AnilKumar,
Thanks for reviewing.
On Fri, May 4, 2012 at 2:00 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/mach-omap2/smartreflex.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 144d118..15907b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_mpu_irqs[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_core_irqs[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
@@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks here.
Regards
AnilKumar
--
Regards and Thanks,
Keerthy
--
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 24/25] OMAPDSS: DSI: improve DSI module id handling
On Fri, 2012-05-04 at 15:35 +0530, Archit Taneja wrote: This is only a problem with device tree, and I solved it so that I pass a DSI module ID in the device tree data. So, with old pdata way I initialize dsi-module_id from the pdev-id, but with DT I initialize dsi-module_id from the DT data. Oh ok, so the code which decides how dsi-module_id is initialised(from DT or pdata) is not in this series right? And it would come later? Right now it's just set to dsidev-id in probe. Yes, there's no DT code in this series, only cleanups to make adding DT support easier. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] OMAP: Finish ehci omap phy reset cycle before adding hcd.
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a
regression
with Beagleboard xM if booting the kernel after running 'usb start' under
u-boot.
Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is
most likely due to
usb_add_hcd calling the driver's reset and init functions which expect the
hardware to be
up and running.
Signed-off-by: Russ Dill russ.d...@ti.com
---
drivers/usb/host/ehci-omap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 5c78f9e..e669c6a 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -242,15 +242,6 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
ehci_reset(omap_ehci);
- ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
- if (ret) {
- dev_err(dev, failed to add hcd with err %d\n, ret);
- goto err_add_hcd;
- }
-
- /* root ports should always stay powered */
- ehci_port_power(omap_ehci, 1);
-
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
* PHY is settled and ready
@@ -264,6 +255,15 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
gpio_set_value(pdata-reset_gpio_port[1], 1);
}
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (ret) {
+ dev_err(dev, failed to add hcd with err %d\n, ret);
+ goto err_add_hcd;
+ }
+
+ /* root ports should always stay powered */
+ ehci_port_power(omap_ehci, 1);
+
return 0;
err_add_hcd:
--
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] OMAP: Finish ehci omap phy reset cycle before adding hcd.
Hi,
On Fri, May 04, 2012 at 04:24:47AM -0700, Russ Dill wrote:
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a
regression
with Beagleboard xM if booting the kernel after running 'usb start' under
u-boot.
Finishing the reset before calling 'usb_add_hcd' fixes the regression. This
is most likely due to
usb_add_hcd calling the driver's reset and init functions which expect the
hardware to be
up and running.
Signed-off-by: Russ Dill russ.d...@ti.com
looks correct to me:
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/host/ehci-omap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 5c78f9e..e669c6a 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -242,15 +242,6 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
ehci_reset(omap_ehci);
- ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
- if (ret) {
- dev_err(dev, failed to add hcd with err %d\n, ret);
- goto err_add_hcd;
- }
-
- /* root ports should always stay powered */
- ehci_port_power(omap_ehci, 1);
-
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
* PHY is settled and ready
@@ -264,6 +255,15 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
gpio_set_value(pdata-reset_gpio_port[1], 1);
}
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (ret) {
+ dev_err(dev, failed to add hcd with err %d\n, ret);
+ goto err_add_hcd;
+ }
+
+ /* root ports should always stay powered */
+ ehci_port_power(omap_ehci, 1);
+
return 0;
err_add_hcd:
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Thursday 03 May 2012, Stephen Warren wrote: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the controller. I don't see why those properties would be mandatory in device tree. They don't appear to be involved in parsing a DMA client's DMA specifier. Shouldn't this information be provided at run-time by the DMA controller driver. If it supports different HW models with different capabilities, then it certainly could represent those values in DT, but I don't think this should be required. Agreed. I would list them as 'optional' though, so that every specific binding that needs these will have to use the same format. Arnd -- 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: Problems with 3.4-rc5
On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org Date: Thu, 03 May 2012 16:07:22 +0300 Subject: Re: Problems with 3.4-rc5 On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: Both patches together results in slightly different behaviour, the display is still broken- it flickers on and off with occassional underflows before breaking completely. Beagle works fine for me with omap2plus based config, and I think overo also although I can't test it now as I broke my micro mmc adapter. Can you send your panel definition? Any other things that could affect display? Do you have PM enabled? Can you share your kernel config? Tomi I've gone back to a test setup others can replicate. Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Tomi signature.asc Description: This is a digitally signed message part
ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hello, I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. All the kernel versions have been tested with identical bootloaders and identical setup, so there is apparently no misconfiguration of my serial terminal program regarding flow control or things like that. I have seen that there has been multiple changes to the OMAP UART code between 3.2 and 3.3, but a git bisect attempt has failed miserably due to numerous build issues in the OMAP code at various points of the bisection. I am attaching the boot logs for 3.2 (working), 3.3 (not working) and 3.4-rc5 (not working) in case this is of any help. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.2.0-2-g7892880 (thomas@skate) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #4 SMP Fri May 4 14:24:20 CEST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: IGEP v2 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/200/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c103d000 s10112 r8192 d14464 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: init=/bin/sh mtdparts=omap2-nand.0:6m(boot),6m(rootfs) rootfstype=jffs2 root=/dev/mtdblock1 console=ttyO2,115200 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 507236k/507236k available, 17052k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc060b388 (6157 kB) [0.00] .init : 0xc060c000 - 0xc0658780 ( 306 kB) [0.00] .data : 0xc065a000 - 0xc06e0970 ( 539 kB) [0.00].bss : 0xc06e0994 - 0xc0c34f20 (5458 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:410 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001068] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.085876] pid_max: default: 32768 minimum: 301 [0.086822] Security Framework initialized [0.087188] Mount-cache hash table entries: 512 [0.092681] CPU: Testing write buffer coherency: ok [0.093994] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.096527] Brought up 1 CPUs [0.096527] SMP: Total of 1 processors activated (597.64 BogoMIPS). [0.101379] devtmpfs: initialized [0.125549] print_constraints: dummy: [0.128540] NET: Registered protocol family 16 [0.130126] GPMC revision 5.0 [0.148162] OMAP GPIO hardware version 2.5 [0.171112] omap_mux_init: Add partition: #1: core, flags: 0 [0.174163] IGEP2: Hardware Revision C (B-NON compatible) [0.188110] Reprogramming SDRC clock to 2 Hz [0.188140] dpll3_m2_clk rate change failed: -22 [0.189605] IGEP: initializing NAND memory device [0.208648] hw-breakpoint: debug architecture 0x4 unsupported. [
RE: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
Hi Kevin, On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote: Ben Hutchings bhutchi...@solarflare.com writes: On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote: On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote: [...] So, if I understood this correctly, it's effectively like blocking a low power state transition (here wfi execution) when EMAC is active? Assuming it is my patch, correct. Recently I was thinking about how to get certain drivers to disallow some or all low power states and to me this also seems to fall in a similar category. One of the suggestions that I got was to check if the 'wakeup' entry associated with the device under sysfs could be leveraged for this. The PM code could maintain a whitelist (or blacklist) of devices and it decides the low power state to enter based on the 'wakeup' entries associated with these devices. In this particular case, maybe the driver could simply set this entry to non-wakeup capable when necessary and then let the PM code take care of skipping the wfi execution. Thoughts/brickbats welcome :) You can maybe (ab)use the pm_qos mechanism for this. I thought of using this too, but it doesn't actually solve the problem: Using PM QoS, you can avoid hitting the deeper idle states by setting a very low wakeup latency. However, on ARM platforms, even the shallowest idle states use the WFI instruction, and the EMAC would still not be able to wake the system from WFI. A possibility would be define the shallowest idle state to be one that doesn't call WFI and just does cpu_relax(). However, that would only work for CPUidle since PM QoS constraints are only checked by CPUidle. So, a non-CPUidle kernel would still have this bug. :( Ultimately, this is just broken HW. This network HW was bolted onto an existing SoC without consideration for wakeup capabilities. The result is that any use of this device with networking has to completely disable SoC power management. I was checking with internally with some folks on the issue being addressed in this patch and unfortunately no one seems to be aware of this :( Mark mentioned nfs mounted rootfs being slow but in my limited testing I didn't observe this on an AM3517 board. I am yet to go through the PSP code to be fully sure that wfi instruction is indeed being executed but I wanted to check if I need to do something specific to reproduce this at my end. Irrespective of the above problem being present in the h/w, I feel the approach of adding platform callbacks for blocking deeper idle states will create problems when this is required for multiple peripherals. I agree that the default behavior should be to support the deepest idle state based on the peripherals being used but IMO the user should have the flexibility to change this behavior if he wishes to do so. I don't know whether the usage of the 'wakeup' entries for giving this control to users qualifies as an abuse of the infrastructure. If it does, perhaps there should some other mechanism for letting users control the system behavior. Regards, 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
[PATCH 0/3] ARM: OMAP4: add support for TPS62361 PMIC
Hi, This set adds support for TPS62361 PMIC, which is used to power MPU voltagedomain on OMAP4460 boards. These patches apply on top of 3.4 + my voltagedomain fixes set to avoid adding redundant code. Working tree available here for interested parties: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-voltdm-tps-v1 Tree has been tested with: - omap3beagle board - omap4panda es board (OMAP4460) - omap4blaze board (OMAP4430) Tested modifying the voltage levels on all core regulators (vdd1...vdd3) and measuring that the voltages do actually change. Patch #1 was needed before the voltages could be modified on a panda board es device, otherwise the timing for the I2C channel was so bogus it usually failed. The values used were taken from an android tree and are based on TI analysis. -Tero -- 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: OMAP4: VC: fix I2C timing
Current I2C timing parameters do not work with Panda board at least. Parameters updated based on TI recommendation. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/vc.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c index 1fd976e..a731400 100644 --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -585,7 +585,9 @@ static void __init omap4_vc_init_channel(struct voltagedomain *voltdm) omap4_set_timings(voltdm, true); /* XXX These are magic numbers and do not belong! */ - vc_val = (0x60 OMAP4430_SCLL_SHIFT | 0x26 OMAP4430_SCLH_SHIFT); + vc_val = (0x28 OMAP4430_SCLL_SHIFT | 0x2c OMAP4430_SCLH_SHIFT); + vc_val |= (0x0b OMAP4430_HSSCLL_SHIFT); + vc_val |= (0x0 OMAP4430_HSSCLH_SHIFT); voltdm-write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET); } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP3+: PM: introduce a central pmic control
From: Nishanth Menon n...@ti.com
Since we are starting to use multiple PMICs in various combinations,
use the existing .omap_chip = OMAP_CHIP_INIT() to mark the
structures we are interested in using per OMAP device we
are currently running on. This mapping is based on the default
device recommendations from TI. Boards using custom PMICs now
have an opportunity to register their own custom mapping.
With this we no longer need omap4_twl_init and omap3_twl_int
instead we introduce a registration mechanism which is PMIC
generic and move twl implementation to use the same. This allows
for future OMAP4460 support where there is a mixture of
PMIC combinations used.
Signed-off-by: Nishanth Menon n...@ti.com
[t-kri...@ti.com: moved code under twl-common, other minor cleanups]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 81 ++
arch/arm/mach-omap2/pm.h |9 +---
arch/arm/mach-omap2/twl-common.c | 55 +-
arch/arm/mach-omap2/twl-common.h | 27 +
4 files changed, 129 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 7830eae..c8e418e 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -19,8 +19,8 @@
#include linux/i2c/twl.h
#include voltage.h
-
#include pm.h
+#include twl-common.h
#define OMAP3_SRI2C_SLAVE_ADDR 0x12
#define OMAP3_VDD_MPU_SR_CONTROL_REG 0x00
@@ -170,7 +170,7 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.uv_to_vsel = twl4030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_mpu_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore1_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -187,7 +187,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_iva_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore2_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
@@ -204,7 +204,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_voltdm_pmic omap4_core_pmic = {
+static struct omap_voltdm_pmic twl6030_vcore3_pmic = {
.slew_rate = 4000,
.step_size = 12660,
.startup_time = 500,
@@ -222,31 +222,9 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-int __init omap4_twl_init(void)
+static int __init twl_set_sr(struct voltagedomain *voltdm)
{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
-
- voltdm = voltdm_lookup(mpu);
- omap_voltage_register_pmic(voltdm, omap4_mpu_pmic);
-
- voltdm = voltdm_lookup(iva);
- omap_voltage_register_pmic(voltdm, omap4_iva_pmic);
-
- voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap4_core_pmic);
-
- return 0;
-}
-
-int __init omap3_twl_init(void)
-{
- struct voltagedomain *voltdm;
-
- if (!cpu_is_omap34xx())
- return -ENODEV;
+ int r = 0;
/*
* The smartreflex bit on twl4030 specifies if the setting of voltage
@@ -258,15 +236,50 @@ int __init omap3_twl_init(void)
* voltage scaling will not function on TWL over I2C_SR.
*/
if (!twl_sr_enable_autoinit)
- omap3_twl_set_sr_bit(true);
+ r = omap3_twl_set_sr_bit(true);
- voltdm = voltdm_lookup(mpu_iva);
- omap_voltage_register_pmic(voltdm, omap3_mpu_pmic);
+ return r;
+}
- voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap3_core_pmic);
+static __initdata struct omap_pmic_map omap_twl_map[] = {
+ {
+ .name = mpu_iva,
+ .cpu = PMIC_CPU_OMAP3,
+ .pmic_data = omap3_mpu_pmic,
+ .special_action = twl_set_sr,
+ },
+ {
+ .name = core,
+ .cpu = PMIC_CPU_OMAP3,
+ .pmic_data = omap3_core_pmic,
+ },
+ {
+ .name = mpu,
+ .cpu = PMIC_CPU_OMAP4430,
+ .pmic_data = twl6030_vcore1_pmic,
+ },
+ {
+ .name = core,
+ .cpu = PMIC_CPU_OMAP4430,
+ .pmic_data = twl6030_vcore3_pmic,
+ },
+ {
+ .name = core,
+ .cpu = PMIC_CPU_OMAP4460,
+ .pmic_data = twl6030_vcore1_pmic,
+ },
+ {
+ .name = iva,
+ .cpu = PMIC_CPU_OMAP44XX,
+ .pmic_data = twl6030_vcore2_pmic,
+ },
+ /* Terminator */
+
[PATCH 3/3] ARM: OMAP2+ PM: Add support for TPS62361
From: Vishwanath BS vishwanath...@ti.com
TPS62361 is a new PMIC used with OMAP4460 on SDP4430 platform
and panda board ES to supply MPU VDD.
Rest of the VDDs continue to be supplied via TWL6030.
As part of this, the following have been moved to common
location in voltage.h
OMAP4_VP_CONFIG_ERROROFFSET, OMAP4_VP_VSTEPMIN_VSTEPMIN,
OMAP4_VP_VSTEPMAX_VSTEPMAX, OMAP4_VP_VLIMITTO_TIMEOUT_US
[n...@ti.com: cleaned up TPS to handle board variations]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[t-kri...@ti.com: minor cleanup, added panda board support]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/Kconfig|9 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-4430sdp.c| 10 ++
arch/arm/mach-omap2/board-omap4panda.c |8 +
arch/arm/mach-omap2/omap_tps6236x.c| 247
arch/arm/mach-omap2/omap_twl.c |5 -
arch/arm/mach-omap2/twl-common.c |1 +
arch/arm/mach-omap2/twl-common.h | 16 ++
arch/arm/mach-omap2/voltage.h |5 +
9 files changed, 297 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_tps6236x.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..a147f00 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -334,6 +334,7 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
@@ -342,6 +343,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select OMAP_TPS6236X
config OMAP3_EMU
bool OMAP3 debugging peripherals
@@ -384,6 +386,13 @@ config OMAP4_ERRATA_I688
In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
IO barrier ensure that there is no synchronisation loss on initiators
operating on both interconnect port simultaneously.
+
+config OMAP_TPS6236X
+ bool OMAP4 support for TPS6236X power IC
+ help
+ TPS62361 is a PMIC used with OMAP4460 to supply MPU VDD voltage.
+ Rest of the VDDs continue to be supplied via TWL6030.
+
endmenu
endif
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..58861a2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,6 +22,7 @@ obj-y += mcbsp.o
endif
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_OMAP_TPS6236X) += omap_tps6236x.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..58fbf64 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -63,6 +63,8 @@
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
+#define TPS62361_GPIO 7
+
static const int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
@@ -958,6 +960,14 @@ static void __init omap_4430sdp_init(void)
pr_err(Keypad initialization failed: %d\n, status);
omap_4430sdp_display_init();
+
+ if (cpu_is_omap446x()) {
+ /* Vsel0 = gpio, vsel1 = gnd */
+ status = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ OMAP_PIN_OFF_OUTPUT_HIGH, -1);
+ if (status)
+ pr_err(TPS62361 initialization failed: %d\n, status);
+ }
}
MACHINE_START(OMAP_4430SDP, OMAP4430 4430SDP board)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d8c0e89..5b5a6bc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -55,6 +55,7 @@
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
+#define TPS62361_GPIO 7 /* Vsel0 control for TPS62361 */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -572,6 +573,13 @@ static void __init omap4_panda_init(void)
omap4_ehci_init();
usb_musb_init(musb_board_data);
omap4_panda_display_init();
+ if (cpu_is_omap446x()) {
+ /* vsel0 = gpio, vsel1 = gnd */
+ ret = omap_tps6236x_board_setup(true, TPS62361_GPIO, -1,
+ OMAP_PIN_OFF_OUTPUT_HIGH, -1);
+ if (ret)
+ pr_err(TPS62361 initialization failed: %d\n, ret);
+ }
}
MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
diff --git a/arch/arm/mach-omap2/omap_tps6236x.c
Re: Problems with 3.4-rc5
On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org Date: Thu, 03 May 2012 16:07:22 +0300 Subject: Re: Problems with 3.4-rc5 On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: Both patches together results in slightly different behaviour, the display is still broken- it flickers on and off with occassional underflows before breaking completely. Beagle works fine for me with omap2plus based config, and I think overo also although I can't test it now as I broke my micro mmc adapter. Can you send your panel definition? Any other things that could affect display? Do you have PM enabled? Can you share your kernel config? Tomi I've gone back to a test setup others can replicate. Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi signature.asc Description: This is a digitally signed message part
Re: Problems with 3.4-rc5
-Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org Date: Fri, 04 May 2012 17:01:12 +0300 Subject: Re: Problems with 3.4-rc5 On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote: -Original Message- From: Tomi Valkeinen tomi.valkei...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org Date: Thu, 03 May 2012 16:07:22 +0300 Subject: Re: Problems with 3.4-rc5 On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote: Both patches together results in slightly different behaviour, the display is still broken- it flickers on and off with occassional underflows before breaking completely. Beagle works fine for me with omap2plus based config, and I think overo also although I can't test it now as I broke my micro mmc adapter. Can you send your panel definition? Any other things that could affect display? Do you have PM enabled? Can you share your kernel config? Tomi I've gone back to a test setup others can replicate. Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Cheers, Joe -- 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] net: davinci_emac: Add pre_open, post_stop platform callbacks
+Sekhar Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi Kevin, On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote: Ben Hutchings bhutchi...@solarflare.com writes: On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote: On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote: [...] So, if I understood this correctly, it's effectively like blocking a low power state transition (here wfi execution) when EMAC is active? Assuming it is my patch, correct. Recently I was thinking about how to get certain drivers to disallow some or all low power states and to me this also seems to fall in a similar category. One of the suggestions that I got was to check if the 'wakeup' entry associated with the device under sysfs could be leveraged for this. The PM code could maintain a whitelist (or blacklist) of devices and it decides the low power state to enter based on the 'wakeup' entries associated with these devices. In this particular case, maybe the driver could simply set this entry to non-wakeup capable when necessary and then let the PM code take care of skipping the wfi execution. Thoughts/brickbats welcome :) You can maybe (ab)use the pm_qos mechanism for this. I thought of using this too, but it doesn't actually solve the problem: Using PM QoS, you can avoid hitting the deeper idle states by setting a very low wakeup latency. However, on ARM platforms, even the shallowest idle states use the WFI instruction, and the EMAC would still not be able to wake the system from WFI. A possibility would be define the shallowest idle state to be one that doesn't call WFI and just does cpu_relax(). However, that would only work for CPUidle since PM QoS constraints are only checked by CPUidle. So, a non-CPUidle kernel would still have this bug. :( Ultimately, this is just broken HW. This network HW was bolted onto an existing SoC without consideration for wakeup capabilities. The result is that any use of this device with networking has to completely disable SoC power management. I was checking with internally with some folks on the issue being addressed in this patch and unfortunately no one seems to be aware of this :( Do you mean they are not aware that the EMAC cannot wakeup th SoC, or they are not aware that having a device that cannot wakup the SoC has such an impact on Linux. Mark mentioned nfs mounted rootfs being slow but in my limited testing I didn't observe this on an AM3517 board. I am yet to go through the PSP code to be fully sure that wfi instruction is indeed being executed but I wanted to check if I need to do something specific to reproduce this at my end. Based on my discussion with Mark, I suspect that the kernel you're using is simply not going idle. Irrespective of the above problem being present in the h/w, I feel the approach of adding platform callbacks for blocking deeper idle states will create problems when this is required for multiple peripherals. I agree. If we have to do this for multiple peripherals, the curren approach it will become unwieldy. I agree that the default behavior should be to support the deepest idle state based on the peripherals being used but IMO the user should have the flexibility to change this behavior if he wishes to do so. Well, we always have the option of booting with 'nohlt' on the commandline. Since nobody seems to have thought about idle power management in the HW design, maybe we shouldn't break our backs to hack around the HW brokenness. Personally, I'm perfectly OK leaving the default behavior of sluggish/unresponsive devices that are not wakeup capable. The only fix is to not sleep, and that can be accomplished on the cmdline using nohlt (at the expense of some energy savings.) I don't know whether the usage of the 'wakeup' entries for giving this control to users qualifies as an abuse of the infrastructure. It does. If it does, perhaps there should some other mechanism for letting users control the system behavior. Come to think of it, the right solution here is probably to use runtime PM. We could then to add some custom hooks for davinci_emac in the device code to use enable_hlt/disable_hlt based on activity. In order to do that though, the davinci_emac driver needs to be runtime PM converted. 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
v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. I don't see the problem with v3.3, but as there has been a lot of DSS changes also, it could as well be a DSS change that has triggered the problem. It also looks that the sync lost happens when the system idles a bit. I compared count and time files in debugfs/pm_debug/ for both working (i.e. usb compiled in) and non-working cases, but they seem similar for the relevant parts. core_pwrdm is always ON, mpu_pwrdm has both RET and ON states, dss_pwrdm both RET and ON states (identical counts). Do you have anything in mind related to PM that has changed for v3.4 which could affect DSS? Any idea what effect USB gadget has? My understanding is that it keeps usbhost_pwrdm forcibly alive, maybe also something else, but I'm not sure why it would affect DSS. I also tested with my DSS OPP100 patches, which try to force OPP100 when DSS is enabled by adding a PM constraint for bus tput of 10, but it doesn't seem to have any effect. And, I guess, the constraint affects only core_pwrdm, and as seen it's anyway always on in both cases. Any debugging ideas are welcome. Tomi signature.asc Description: This is a digitally signed message part
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 22:08]:
In my mind in the driver we do not have to care how to list
register/unregister the group. We just need to be able to do this
pinctrl_register_group(...)
or
pinctrl_unregistewr_group(...)
On at91 we have this type of controller
Ah I see. Yeah makes sense. Also I think we should let the pinctrl
core eventually manage the pins more too. Right now the pins are
a static array in the driver, which makes things unnecessarily
complex for the DT case. It would be nice to also have something like
pinctrl_register/unregister_pin instead of requiring them all
be registered while registering with the framework initially.
But all that can be improved later on once we get the binding down..
one pin can have multiple function and each function can be on different pin
and we need to program and represent each of them one by one
And each pin have different parameter
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
and use macro as basicaly we are just this
and this can be applied to tegra too as you will just refer the pin in this hw
pin block
I was thinking of adding gpio eventually as a separate attribute with
something like the following. Here cam_d10 pin is used as gpio109:
cam_d10.gpio_109 {
pinctrl-simple,cells = 0xfa 0x104;/* OMAP_PIN_INPUT |
OMAP_MUX_MODE4 */
gpio = gpio4 13 0; /* gpio109 */
};
The reasoning for this is that as we may not care about the gpio number
for all pins, it should be optional. Would that work for you?
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
Hi Stephen,
On 05/03/2012 05:26 PM, Stephen Warren wrote:
On 04/30/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I'll reply to the binding documentation first; perhaps that'll set the
scene for my questions better.
+++ b/Documentation/devicetree/bindings/dma/dma.txt
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver using DMA Engine to retrieve
the
+DMA request or channel information that goes from a hardware device to a DMA
+controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Number elements to describe DMA channel information. Must
be
+ 2 with current implementation but in future we could allow
+ more than 2 to describe interrupt mapping as well.
That makes sense.
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
controller.
I don't see why those properties would be mandatory in device tree. They
don't appear to be involved in parsing a DMA client's DMA specifier.
Shouldn't this information be provided at run-time by the DMA controller
driver. If it supports different HW models with different capabilities,
then it certainly could represent those values in DT, but I don't think
this should be required.
Yes you are right. These should not be required.
+Example:
+
+sdma: dmaengine@4800 {
+compatible = ti,omap4-sdma
+reg = 0x4800 0x1000;
+interrupts = 4;
+#dma-cells = 2;
+#dma-channels = 32;
+#dma-requests = 127;
+};
+
+
+* DMA client
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by the number of DMA request/channel and the transfer type of the
What exactly is request/channel? Is it a request ID, a channel ID,
both packed into a single integer (which bits are used for each field),
etc.?
The thought here was that some DMAs may distinguish between devices by a
request ID or a channel ID or both. In the case of say an OMAP4, we have
32 channels and 127 request IDs. From a h/w perspective we need to know
both. Each of the 32 channels can be programmed to use any one of the
127 h/w request signals.
Other DMAs may only need to specify requests or channels. However, the
thought was you could specific either or both depending on your needs.
Again these should have been optional parameters.
If this is up to the individual controller binding, then I think the
description should just specify that there is a phandle followed by a
DMA specifier, and the DMA specifier contains #dma-cells from the
phandle node. See other similar bindings for suitable wording.
Ok, thanks. Still a bit green (new) on the DT stuff.
+channel (eg. device-to-memory, memory-to-device, memory-to-memory, etc).
Drivers
+should use the DMA Engine enum dma_transfer_direction (eg. DMA_DEV_TO_MEM,
+DMA_MEM_TO_DEV, etc) for specifying the transfer type.
The binding document should stand alone; you shouldn't need to go look
up values in any particular OS/driver's source code. In other words,
this should explicitly enumerate the values for DMA_DEV_TO_MEM etc.
here. That said, I'm not sure it's appropriate to mandate that every DMA
controller's DMA specifier actually include this information in DT (a
controller might only support DEV_TO_MEM for example, and hence not need
this information in DT at all).
The DMA client's binding should specify how many entries it needs in the
dma property and what they mean, e.g. it should know that dma property
index 0 is the TX DMA specifier, and index 1 is the RX specifier.
Ok. I was trying to add another parameter to make this explicit in the
property. When I was looking at the bindings it is not clear what index
0 is, what index 1, etc, and I needed to look at both the client driver
and DT to figure out what they think the indexes represent. Hence, I
thought a parameter that identified this could be useful. However, your
point is well taken and I agree that it would be cleaner to keep it
separated. If it is preferred to have the client driver understand the
indexes then that is fine.
+Required property:
+- dma: List of phandle + dma-request/channel + transfer-type,
+ one group per request line.
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma = sdma 2 1 sdma 3 2;
Should that be dmas (plural) to be consistency with interrupts, gpios,
...?
It could be. However, there could also be cases where there is a single
DMA request/channel. However, to be consistent with others we can make
it dmas.
Back to pieces of your patch description:
v3: - avoid passing an
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Fri, May 04, 2012 at 10:06:53AM -0500, Jon Hunter wrote: The thought here was that some DMAs may distinguish between devices by a request ID or a channel ID or both. In the case of say an OMAP4, we have 32 channels and 127 request IDs. From a h/w perspective we need to know both. Each of the 32 channels can be programmed to use any one of the 127 h/w request signals. Other DMAs may only need to specify requests or channels. However, the thought was you could specific either or both depending on your needs. Again these should have been optional parameters. As being the one who is converting you over to DMA engine, I can't agree with what you've just said. I don't see that there's anything specific to any particular DMA channel. I don't see that a driver would need to obtain a reference to any particular channel. This seems to be supported by the current OMAP DMA API which merely returns any one of the 32 channels that it can find whenever omap_request_dma() is called. At the moment, the DMA engine support I'm working on totally hides the physical DMA channels behind a set of virtual DMA channels, one for each DMA request signal. This appears to work well, and is compatible with how existing drivers use the current OMAP DMA API. -- 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
Hi Jassi, On 05/04/2012 01:56 AM, Jassi Brar wrote: On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. Aim of DMA helpers - The purpose of device-tree (as far as I understand), is to describe the capabilites of the hardware. Thinking about DMA controllers purely from the context of the hardware to begin with, we can describe a device in terms of a DMA controller as follows ... 1. Number of DMA controllers 2. Number of channels (maybe physical or logical) 3. Mapping of DMA requests signals to DMA controller 4. Number of DMA interrupts 5. Mapping of DMA interrupts to channels - With the above in mind the aim of the DT DMA helper functions is to extract the above information from the DT and provide to the appropriate driver. However, due to the vast number of DMA controllers and not all are using a common driver (such as DMA Engine) it has been seen that this is not a trivial task. Sorry for being slow, but so far I thought DT is only to provide _h/w_ specific info to the _controller_ drivers. It was not supposed to provide any info pertaining to some API (dmaengine in this case). And I believe this is one of few situations where we are better off not generalizing the interface - pass controller specific info in the controller driver's specified format. Generalizing only seems to complicate things here, when we anyway have machine specific dtb, which could always have clients requesting and the controllers given dma's info in controller driver's specific format. Perhaps I am overlooking the need to generalize. If you think so, please help me understand by pointing out some use case for it. No not really, your points are valid. From reading the previous discussions one of the items that was clearly lacking was the ability to represent and identify a device having more than one DMA controller. In other words, when you request the DMA resource, how do you identify which DMA controller in the system that resource belongs too. With DMA engine there are ways we can do this. However, thinking about this now. Instead of passing specific DMA engine parameters to the register function may be we can pass a generic void * pointer with the information and completely abstract the binding from DMA engine. This is probably a better approach. 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
Hi Jassi, On 05/04/2012 01:56 AM, Jassi Brar wrote: On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. Aim of DMA helpers - The purpose of device-tree (as far as I understand), is to describe the capabilites of the hardware. Thinking about DMA controllers purely from the context of the hardware to begin with, we can describe a device in terms of a DMA controller as follows ... 1. Number of DMA controllers 2. Number of channels (maybe physical or logical) 3. Mapping of DMA requests signals to DMA controller 4. Number of DMA interrupts 5. Mapping of DMA interrupts to channels - With the above in mind the aim of the DT DMA helper functions is to extract the above information from the DT and provide to the appropriate driver. However, due to the vast number of DMA controllers and not all are using a common driver (such as DMA Engine) it has been seen that this is not a trivial task. Sorry for being slow, but so far I thought DT is only to provide _h/w_ specific info to the _controller_ drivers. It was not supposed to provide any info pertaining to some API (dmaengine in this case). And I believe this is one of few situations where we are better off not generalizing the interface - pass controller specific info in the controller driver's specified format. Generalizing only seems to complicate things here, when we anyway have machine specific dtb, which could always have clients requesting and the controllers given dma's info in controller driver's specific format. Perhaps I am overlooking the need to generalize. If you think so, please help me understand by pointing out some use case for it. No not really, your points are valid. From reading the previous discussions one of the items that was clearly lacking was the ability to represent and identify a device having more than one DMA controller. In other words, when you request the DMA resource, how do you identify which DMA controller in the system that resource belongs too. With DMA engine there are ways we can do this. However, thinking about this now. Instead of passing specific DMA engine parameters to the register function may be we can pass a generic void * pointer with the information and completely abstract the binding from DMA engine. This is probably a better approach. 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
rx51: support for lis3lv02d accelerometer
Hi!
Upstream linux kernel has already driver for lis3lv02d accelerometer
in drivers/misc/lis3lv02d. So now can be added also platform support
for nokia rx51. Patch exists for long time in meego obs repository:
https://build.pub.meego.com/package/view_file?file=linux-2.6-omap-rx51-Platform-support-for-lis3lv02d-acceleromet.patchpackage=kernel-adaptation-n900project�%3AAdaptation%3AN900
It is possible to include this patch to upstream kernel?
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index d87ee06..a49801f 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -44,6 +44,7 @@
#include linux/leds-lp5523.h
#include ../drivers/staging/iio/light/tsl2563.h
+#include linux/lis3lv02d.h
#include mux.h
#include hsmmc.h
@@ -63,6 +64,9 @@
#define RX51_TSC2005_RESET_GPIO 104
#define RX51_TSC2005_IRQ_GPIO 100
+#define LIS302_IRQ1_GPIO 181
+#define LIS302_IRQ2_GPIO 180 /* Not yet in use */
+
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
@@ -73,6 +77,77 @@ enum {
static struct wl12xx_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
+#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
+static int lis302_setup(void)
+{
+ int err;
+ int irq1 = LIS302_IRQ1_GPIO;
+ int irq2 = LIS302_IRQ2_GPIO;
+
+ /* gpio for interrupt pin 1 */
+ err = gpio_request(irq1, lis3lv02dl_irq1);
+ if (err) {
+ printk(KERN_ERR lis3lv02dl: gpio request failed\n);
+ goto out;
+ }
+
+ /* gpio for interrupt pin 2 */
+ err = gpio_request(irq2, lis3lv02dl_irq2);
+ if (err) {
+ gpio_free(irq1);
+ printk(KERN_ERR lis3lv02dl: gpio request failed\n);
+ goto out;
+ }
+
+ gpio_direction_input(irq1);
+ gpio_direction_input(irq2);
+
+out:
+ return err;
+}
+
+static int lis302_release(void)
+{
+ gpio_free(LIS302_IRQ1_GPIO);
+ gpio_free(LIS302_IRQ2_GPIO);
+
+return 0;
+}
+
+static struct lis3lv02d_platform_data rx51_lis3lv02d_data = {
+ .click_flags= LIS3_CLICK_SINGLE_X | LIS3_CLICK_SINGLE_Y |
+ LIS3_CLICK_SINGLE_Z,
+ /* Limits are 0.5g * value */
+ .click_thresh_x = 8,
+ .click_thresh_y = 8,
+ .click_thresh_z = 10,
+ /* Click must be longer than time limit */
+ .click_time_limit = 9,
+ /* Kind of debounce filter */
+ .click_latency= 50,
+
+ /* Limits for all axis. millig-value / 18 to get HW values */
+ .wakeup_flags = LIS3_WAKEUP_X_HI | LIS3_WAKEUP_Y_HI,
+ .wakeup_thresh = 800 / 18,
+ .wakeup_flags2 = LIS3_WAKEUP_Z_HI ,
+ .wakeup_thresh2 = 900 / 18,
+
+ .hipass_ctrl = LIS3_HIPASS1_DISABLE | LIS3_HIPASS2_DISABLE,
+
+ /* Interrupt line 2 for click detection, line 1 for thresholds */
+ .irq_cfg = LIS3_IRQ2_CLICK | LIS3_IRQ1_FF_WU_12,
+
+ .axis_x = LIS3_DEV_X,
+ .axis_y = LIS3_INV_DEV_Y,
+ .axis_z = LIS3_INV_DEV_Z,
+ .setup_resources = lis302_setup,
+ .release_resources = lis302_release,
+ .st_min_limits = {-32, 3, 3},
+ .st_max_limits = {-3, 32, 32},
+ .irq2 = OMAP_GPIO_IRQ(LIS302_IRQ2_GPIO),
+};
+#endif
+
#if defined(CONFIG_SENSORS_TSL2563) || defined(CONFIG_SENSORS_TSL2563_MODULE)
static struct tsl2563_platform_data rx51_tsl2563_platform_data = {
.cover_comp_gain = 16,
@@ -950,6 +1025,16 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
}
};
+static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
+#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
+ {
+ I2C_BOARD_INFO(lis3lv02d, 0x1d),
+ .platform_data = rx51_lis3lv02d_data,
+ .irq = OMAP_GPIO_IRQ(LIS302_IRQ1_GPIO),
+ },
+#endif
+};
+
static int __init rx51_i2c_init(void)
{
if ((system_rev = SYSTEM_REV_S_USES_VAUX3 system_rev 0x100) ||
@@ -971,7 +1056,8 @@ static int __init rx51_i2c_init(void)
omap_pmic_init(1, 2200, twl5030, INT_34XX_SYS_NIRQ, rx51_twldata);
omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_2));
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(3, 400, rx51_peripherals_i2c_board_info_3,
+ ARRAY_SIZE(rx51_peripherals_i2c_board_info_3));
return 0;
}
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Monday 30 April 2012, Jon Hunter wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. Thanks for picking this up again, I very much appreciate it as not having the binding is blocking a number of other activities. Design of DMA helpers 1. Supporting devices with multiple DMA controllers In the case of DMA controllers that are using DMA Engine, requesting a channel is performed by calling the following function. struct dma_chan *dma_request_channel(dma_cap_mask_t mask, dma_filter_fn filter_fn, void *filter_param); The mask variable is used to identify the device controller in a list of controllers. The filter_fn and filter_param are used to identify the required dma channel and return a handle to the dma channel of type dma_chan. From the examples I have seen, the mask and filter_fn are constant for a given DMA controller. I believe this is not entirely correct: sometimes the filter_fn is provided by the slave driver, sometimes by the master driver. Also, the mask does not identify a specific controller, AFAICT it just provides certain constraints. There are cases where a driver can pick from a multitude of dma engine controllers, as long as the channel the constraints are resolved. This could be expressed in the device tree by listing multiple dma request lines (one per controller) in the device using it, or the author of the device tree can pick one. Therefore, when registering a DMA controller with device tree we can pass these parameters and store them so that a device can request them when requesting a channel. Hence, based upon this our register function for the DMA controller now looks like this. int of_dma_controller_register(struct device_node *np, dma_cap_mask_t *mask, dma_filter_fn fn); This changes the behavior for drivers that provide their own filter functions, which may or may not be a problem. For examples, have a look at some of these: drivers/spi/spi-ep93xx.c drivers/mmc/host/tmio_mmc_dma.c drivers/usb/renesas_usbhs/fifo.c 2. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. However, _IF_ legacy devices that are not using DMA Engine, only have a single DMA controller, then this problem is a lot simpler. For example, if we look at the previously proposed API for registering a DMA controller (where we pass the mask and function pointer to the DMA Engine filter function) we can simply pass NULL and hence, a driver requesting the DMA channel information would receive NULL for the DMA Engine specific parameters. Then for legacy devices we simply need a means to return the channel information (more on this later). If there are legacy devices that do have multiple DMA controllers, then maybe they need to be converted to support DMA Engine. I am not sure if this is unreasonable??? I think it's even simpler: any device that uses another interface instead of dmaengine will just have to parse the DT information itself. We should make sure that it uses the same binding though, so we can later migrate to the dmaengine API without having to change the device trees. 3. Representing and requesting channel information From a hardware perspective, a DMA channel could be represented as ... i. channel index/number ii. channel transfer type (optional) iii. DMA interrupt mapping (optional) Please note that the transfer type is used to indicate if the transfer is to device from memory, to memory from device, to memory from memory, etc. This can be useful when there is a device such as an MMC device that uses two DMA channels, one for reading (RX) and one for writing (TX). Forgetting device tree for now, some drivers use strings to represent a DMA channel instead of using an integer. I assume that these drivers then employ some sort of look-up table to convert the string into a channel number/index that the hardware understands. If this assumption is correct then when moving to a device tree implementation having such look-up tables in the driver should no longer be necessary as the device tree will provide the mapping of channel index/number to the device. Furthermore, it makes sense that device tree uses integers to represent channel as opposed to strings to save the driver having to convert the string into a integer at some later stage. Next we need to think about how the DMA controller and channels are described in the device tree itself. The following device tree node example describes the properties of the DMA controller that includes, the
Re: [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
Hello Benoit, Le Fri, 23 Sep 2011 22:23:09 +0200, Benoit Cousson b-cous...@ti.com a écrit : Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Do you know if some progress has been made on having a generic DT aware map_io function, or is the per-SoC -map_io() function still the recommended way of handling SoC having different requirements of static mappings at boot time? Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 08:03 Fri 04 May , Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 22:08]:
In my mind in the driver we do not have to care how to list
register/unregister the group. We just need to be able to do this
pinctrl_register_group(...)
or
pinctrl_unregistewr_group(...)
On at91 we have this type of controller
Ah I see. Yeah makes sense. Also I think we should let the pinctrl
core eventually manage the pins more too. Right now the pins are
a static array in the driver, which makes things unnecessarily
complex for the DT case. It would be nice to also have something like
pinctrl_register/unregister_pin instead of requiring them all
be registered while registering with the framework initially.
But all that can be improved later on once we get the binding down..
agreed at 100%
one pin can have multiple function and each function can be on different pin
and we need to program and represent each of them one by one
And each pin have different parameter
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
evenif on at91 and nearly on the controller I known it is the case
and use macro as basicaly we are just this
and this can be applied to tegra too as you will just refer the pin in this
hw
pin block
I was thinking of adding gpio eventually as a separate attribute with
something like the following. Here cam_d10 pin is used as gpio109:
cam_d10.gpio_109 {
pinctrl-simple,cells = 0xfa 0x104;/* OMAP_PIN_INPUT |
OMAP_MUX_MODE4 */
gpio = gpio4 13 0; /* gpio109 */
};
The reasoning for this is that as we may not care about the gpio number
for all pins, it should be optional. Would that work for you?
yes
but I was thinking to put it as a param but why not
my idea was this
pinctrl@f200 {
#address-cells = 1;
#size-cells = 0;
compatible = atmel,at91rm9200-pinctrl;
atmel,mux-mask =
/*A B */
0x 0xffc003ff /* pioA */
0x 0x800f8f00 /* pioB */
0x 0x0e00 /* pioC */
0x 0xff0c1381 /* pioD */
0x 0x8181 /* pioE */
;
pioA: gpio@f200 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf200 0x100;
interrupts = 2 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioB: gpio@f400 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf400 0x100;
interrupts = 3 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioC: gpio@f600 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf600 0x100;
interrupts = 4 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
uart0_rts_cts {
groups = uart0_rxd_txd ;
pins = pioB 17 MUX_B NO_PULL_UP /* rts */
pioB 15 MUX_B NO_PULL_UP ; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = uart0_rts_cts ;
gpios = pioC 1 0;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Best Regards,
Re: [PATCH 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
Neil,
On Fri, 4 May 2012, NeilBrown wrote:
On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
Why not simply managing the pending bit for level irqs ?
Hi Thomas,
thanks again for the patch. I finally made time to test it and it works as
expected. I've included it below with a change-log entry and tested-by:
in case that helps.
thanks for testing. The changelog is great. You know how to make the
live of lazy buggers easier :)
for_each_irq_desc(irq, desc) {
- if (irqd_is_wakeup_set(desc-irq_data)) {
+ if (desc-depth == 1
+ irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
continue;
I split that part into a separate patch, as it's really a different
issue.
Thanks,
tglx
--
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 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 05/03/2012 03:23 AM, Mohammed, Afzal wrote:
Hi Jon,
On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote:
Hi Afzal,
Looks good! Some minor comments ...
Thanks
+#defineGPMC_WAITPIN_IDX0 0x0
+#defineGPMC_WAITPIN_IDX1 0x1
+#defineGPMC_WAITPIN_IDX2 0x2
+#defineGPMC_WAITPIN_IDX3 0x3
+#defineGPMC_NR_WAITPIN 0x4
How about an enum here? Also OMAP4 only have 3 wait pins and so the
number is device dependent.
Ok
#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
#define BOOT_ROM_SPACE 0x10/* 1MB */
@@ -64,6 +106,55 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
+#defineDRIVER_NAME omap-gpmc
+
+#defineGPMC_NR_IRQ 2
Why has this been changed to 2? It was 6 in the previous version. As we
discussed before the number of IRQs should be detected based upon GPMC
IP version.
As mentioned in the cover letter,
Additional features that currently boards in mainline does not make
use of like, waitpin interrupt handling, changes to leverage revision
6 IP differences has not been incorporated.
Priority in this series is to convert into a driver, get all boards working
on mainline. Once all boards are working with gpmc driver, these features
which are not required for currently supported boards can be added later.
Yes, but I meant why 2 and not say 5? Anyway, I think that this should
be marked with a comment like a TODO so it is clear that this needs to
be re-visited.
+struct gpmc_device {
+ char*name;
+ int id;
+ void*pdata;
+ unsignedpdata_size;
+ struct resource *per_res;
+ unsignedper_res_cnt;
+ struct resource *gpmc_res;
+ unsignedgpmc_res_cnt;
+ boolhave_waitpin;
+ unsignedwaitpin;
+ int waitpin_polarity;
I think that it make more sense to have the wait-pin information part of
the gpmc_cs_data structure for the following reasons ...
Waitpin information is indeed a part of cs as far as boards are concerned,
it is only that it gets propogated to device
Why does the device's driver care? From my point of view, the wait-pin
is just part of the interface setup/configuration. The external device
may require this and assumes that this has been setup along with the CS
and interface timing, but the device's driver should not care. Remember
this is just a ready signal used to stall the access. Once configured,
software should be unaware of it.
1. If a device can use multiple CS, then it could use multiple wait signals.
2. Eventually, all board information needs to move to device tree. By
having it in the pdata it will be easier to migrate to device tree.
It may be nice to have have_waitpin be an integer too, that indicates
if wait is used for both read and write or just one or the other.
Also, any reason why waitpin_polarity is an int? I see you define LOW as
-1, but I not sure why LOW cannot be 0 as 0 is programmed into the
register for an active low wait signal.
Only intention is not to alter default waitpin polarity value, i.e. if
any board does make use of it w/o knowledge of Kernel, I don't want to
break it, there may be an argument saying that the board code is buggy,
while if some board does so, it is, but don't want to break working one.
Here unless user explicitly set the flag, it does nothing on polarity
Ok. Do such scenario's exist today? Please note that board code will be
removed in the future and device-tree will replace. So if there are no
cases today, I would not be concerned. Unless this could be something
that has already been configured by the bootloader. However, in that
case would be even call this function?
+ if (idx != ~0x0) {
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
+ gd-have_waitpin = true;
+ gd-waitpin = idx;
+ gd-waitpin_polarity = polarity;
+ }
I am not sure about the above code. What happens if a device has
multiple CS signals and uses multiple wait signals?
I am also not sure why gpmc_setup_cs_waitpin and gpmc_setup_waitpin
cannot be combined. I think that it would be a fair assumption to make
that anyone using the waitpin does so
Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 05/01/2012 07:19 AM, Afzal Mohammed wrote:
[...]
+static int gpmc_setup_cs_waitpin(struct gpmc *gpmc, struct gpmc_device *gd,
+ unsigned cs, unsigned conf)
+{
+ u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ unsigned idx = ~0x0;
+ int polarity = 0;
- l = gpmc_read_reg(GPMC_REVISION);
- printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f);
- /* Set smart idle mode and automatic L3 clock gating */
- l = gpmc_read_reg(GPMC_SYSCONFIG);
- l = 0x03 3;
- l |= (0x02 3) | (1 0);
- gpmc_write_reg(GPMC_SYSCONFIG, l);
- gpmc_mem_init();
+ switch (conf GPMC_WAITPIN_MASK) {
+ case GPMC_WAITPIN_0:
+ idx = GPMC_WAITPIN_IDX0;
+ break;
+ case GPMC_WAITPIN_1:
+ idx = GPMC_WAITPIN_IDX1;
+ break;
+ case GPMC_WAITPIN_2:
+ idx = GPMC_WAITPIN_IDX2;
+ break;
+ case GPMC_WAITPIN_3:
+ idx = GPMC_WAITPIN_IDX3;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default? Both are invalid configurations so
just report invalid selection.
- /* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- irq_set_chip_and_handler(irq, dummy_irq_chip,
- handle_simple_irq);
- set_irq_flags(irq, IRQF_VALID);
- irq++;
+ switch (conf GPMC_WAITPIN_POLARITY_MASK) {
+ case GPMC_WAITPIN_ACTIVE_LOW:
+ polarity = LOW;
+ break;
+ case GPMC_WAITPIN_ACTIVE_HIGH:
+ polarity = HIGH;
+ break;
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, waitpin polarity set to low high\n);
+ return -EINVAL;
+ break;
}
Again, combine case 0 and default as these are invalid.
- ret = request_irq(gpmc_irq, gpmc_handle_irq, IRQF_SHARED, gpmc, NULL);
- if (ret)
- pr_err(gpmc: irq-%d could not claim: err %d\n,
- gpmc_irq, ret);
- return ret;
+ if (idx != ~0x0) {
If you combine the above cases, then you can drop the idx test here.
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
Don't need the else as you are going to return in the above.
+ gd-have_waitpin = true;
+ gd-waitpin = idx;
+ gd-waitpin_polarity = polarity;
+ }
+
+ l = ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+ } else if (polarity) {
+ dev_err(gpmc-dev, error: waitpin polarity specified with out
wait pin number on device %s.%d\n,
+ gd-name, gd-id);
+ return -EINVAL;
Drop this else-if. The above switch statements will report the bad
configuration. This seems a bit redundant.
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: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. On v3.4-rc, can you see if reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect? That patch had some unfortunate side effects, but I haven't seen the problem you see, so I'm not sure if it's related. 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 v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal, On 05/03/2012 03:37 AM, Mohammed, Afzal wrote: Hi Jon, On Wed, May 02, 2012 at 02:11:48, Hunter, Jon wrote: + + pdata-clk_prd = gpmc_get_fclk_period(); Does this need to be done here? May be this should be done in the probe function. You could store the handle to the main clk in the pdata. This is done so that migration of gpmc driver to the drivers folder would be smooth, remember that this function will still live here. Sure, but why call this here? + pr_err(error: clk_get on %s\n, oh-main_clk); + return -EINVAL; } clk_enable(gpmc_l3_clk); I would have thought we should be able to remove the gpmc_init function completely by now. Most of the code should be moved to the probe function. Also now with hwmod in place, we should be able to remove the clk_enable/disable functions and use the pm_runtime APIs instead. There was no plan to add rpm in this series, but now that you have brought it up, I will adapt the driver to rpm. Ok, great. 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [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.
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
I could change to use this too no problem. The only concern I have is
that is pioB 12 immutable for all gpio controllers?
Grepping the *.dts* files, at least exynos is using the following
for gpios:
gpios = gpx2 0 0 0 2;
If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
uart0_rts_cts {
groups = uart0_rxd_txd ;
pins = pioB 17 MUX_B NO_PULL_UP /* rts */
pioB 15 MUX_B NO_PULL_UP ; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = uart0_rts_cts ;
gpios = pioC 1 0;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Yeah sounds doable to me, but can probably be added later?
Regarding grouping, basically for most cases it makes sense to have
three states: default, active, idle instead of just active and idle.
The reason is that for most cases the default pins only need to be
set once for each devices. Only few pins need to toggle between
active and idle states.
For example, omap2 uart needs to toggle rx pin to gpio input everytime
it hits idle to provide wake-up events. Other pins do not need to change.
As this is done all the time, the active and idle toggling should be kept
to minimum.
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] net: davinci_emac: Add pre_open, post_stop platform callbacks
On Fri, May 04, 2012 at 01:55:58PM +, Bedia, Vaibhav wrote: Hi Vaibhav. Hi Kevin, On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote: Ben Hutchings bhutchi...@solarflare.com writes: On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote: On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote: [...] So, if I understood this correctly, it's effectively like blocking a low power state transition (here wfi execution) when EMAC is active? Assuming it is my patch, correct. Recently I was thinking about how to get certain drivers to disallow some or all low power states and to me this also seems to fall in a similar category. One of the suggestions that I got was to check if the 'wakeup' entry associated with the device under sysfs could be leveraged for this. The PM code could maintain a whitelist (or blacklist) of devices and it decides the low power state to enter based on the 'wakeup' entries associated with these devices. In this particular case, maybe the driver could simply set this entry to non-wakeup capable when necessary and then let the PM code take care of skipping the wfi execution. Thoughts/brickbats welcome :) You can maybe (ab)use the pm_qos mechanism for this. I thought of using this too, but it doesn't actually solve the problem: Using PM QoS, you can avoid hitting the deeper idle states by setting a very low wakeup latency. However, on ARM platforms, even the shallowest idle states use the WFI instruction, and the EMAC would still not be able to wake the system from WFI. A possibility would be define the shallowest idle state to be one that doesn't call WFI and just does cpu_relax(). However, that would only work for CPUidle since PM QoS constraints are only checked by CPUidle. So, a non-CPUidle kernel would still have this bug. :( Ultimately, this is just broken HW. This network HW was bolted onto an existing SoC without consideration for wakeup capabilities. The result is that any use of this device with networking has to completely disable SoC power management. I was checking with internally with some folks on the issue being addressed in this patch and unfortunately no one seems to be aware of this :( This is from the TI hardware engineer that I talked to after spending many hours trying to get the EMAC to wake up the system. It was a private conversation so I won't share his name/email here. If you want to contact him, please reach me privately. No, AM35x can't be waken up from CPGMAC. If customer need to wake AM35x up from Ethernet, a wake up interrupt signal from Ethernet phy should be connected to one of wakeup capable GPIO pins. Mark mentioned nfs mounted rootfs being slow but in my limited testing I didn't observe this on an AM3517 board. I am yet to go through the PSP code to be fully sure that wfi instruction is indeed being executed but I wanted to check if I need to do something specific to reproduce this at my end. When you go through the PSP code, look for the definition use of omap3_can_sleep(). That routine returns '0' when either cpu_is_omap3505() or cpu_is_omap3517() ruturns true (among other conditions). You will see that its used in omap3_pm_idle() to exit early so pm_idle never executes the wfi. I expect that you don't have CONFIG_CPU_IDLE enabled, so cpuidle has no opportunity to execute a wfi. If it is enabled, omap3_can_sleep() is used in omap3_idle_bm_check() which is used in omap3_enter_idle_bm() so the wfi won't be executed when omap3_enter_idle_bm() is called. omap3_enter_idle() isn't called (in my testing--the code is very different from current k.o.) so it doesn't execute the wfi either. Therefore, you don't see an issue when running PSP code. Irrespective of the above problem being present in the h/w, I feel the approach of adding platform callbacks for blocking deeper idle states will create problems when this is required for multiple peripherals. I agree that the default behavior should be to support the deepest idle state based on the peripherals being used but IMO the user should have the flexibility to change this behavior if he wishes to do so. I agree but hopefully this doesn't become common. The real issue is a missing hardware feature that--again, hopefully--won't become common. Mark -- 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] net: davinci_emac: Add pre_open, post_stop platform callbacks
Hi Mark, Mark A. Greer mgr...@animalcreek.com writes: [...] To work around this issue, add platform data callbacks which are called at the beginning of the open routine and at the end of the stop routine of the davinci_emac driver. The callbacks allow the platform code to issue disable_hlt() and enable_hlt() calls appropriately. Calling disable_hlt() prevents cpu_idle from issuing the 'wfi' instruction. OK, I'm feeling rather dumb for not thinking of this before and suggesting that you use pdata callbacks. But there is a better solution: runtime PM. I hadn't noticed before that since this driver comes from davinci, it uses the clock API and not runtime PM which all OMAP drivers have been (or are being) converted to. If we replace the clock API usage in this driver with proper runtime PM usage, we can make this work. Basically, clk_enable() turns into pm_runtime_get_sync() and clk_disable() turns into pm_runtime_put(). With that, the OMAP PM core will get callbacks whenever the device is [not] needed and we can use device-specific hooks to call disable_hlt/enable_hlt. The only catch though is that in order for this driver to be converted to runtime PM and still work on davinci devices, the davinci kernel needs to grow runtime PM support. I belive Sekhar is already looking into this, and OMAP1 (mach-omap1/pm_bus.c) will be a good example of how to get a basic runtime PM implementation working for davinci which just does basic clock management. Having worked on the guts of runtime PM for OMAP, I know it pretty well (which is all the more embarrasing that I didn't think of suggesting it sooner.) So, let me know how I can help. As a quick hack to test my idea will help, you can try simply calling disable_hlt() after clk_enable() and enable_hlt() after clk_disable() in teh davinci_emac driver. That will effectively be what happens after a runtime PM conversion with device-specific hooks. The (not even compile tested) patch below does this. For starters, can you tell me if this results in normal performance on the EMAC? Kevin diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 174a334..c92bc28 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1909,6 +1909,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) netif_napi_add(ndev, priv-napi, emac_poll, EMAC_POLL_WEIGHT); clk_enable(emac_clk); + disable_hlt(); /* register the network device */ SET_NETDEV_DEV(ndev, pdev-dev); @@ -1929,6 +1930,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) netdev_reg_err: clk_disable(emac_clk); + enable_hlt(); no_irq_res: if (priv-txchan) cpdma_chan_destroy(priv-txchan); @@ -1979,6 +1981,7 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev) clk_disable(emac_clk); clk_put(emac_clk); + enable_hlt(); return 0; } -- 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 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.
Shilimkar, Santosh santosh.shilim...@ti.com writes: On Fri, May 4, 2012 at 3:17 AM, Kevin Hilman khil...@ti.com wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code cpu checks accordingly so that there is no need to patch the file for any future OMAP2+ devices. In long run, all these attributes should come from hwmod dev_attr based on DMA IP version. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/dma.c | 2 +- arch/arm/plat-omap/dma.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index b19d849..2750bb9 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) dma_stride = OMAP2_DMA_STRIDE; dma_common_ch_start = CSDP; - if (cpu_is_omap3630() || cpu_is_omap44xx()) + if (omap_rev() = OMAP3630_REV_ES1_0) It's not obvious (at least to me) that this is equivalent. For example, this will now be true on the TI81xx devices. I see your point. On second thought, i decided to drop this hunk from the patch since the availability of the dma descriptor feature can be read from dma capability register. Will post another patch for it and also add it to the clean-up series. Updated $subject patch in the end of email. Regards Santosh From e42966bc56b1603e033b5b259564ae149b11a5d9 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Sat, 28 Apr 2012 20:19:10 +0530 Subject: [PATCH 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching. cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code cpu checks accordingly so that there is no need to patch the file for any future OMAP2+ devices. In long run, all these attributes should come from hwmod dev_attr based on DMA IP version. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Dropped the hunk for descriptor feature check based on OMAP cpu version since it can be handled with DMA hardware capability register read. Right, this looks better. Thanks, 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] omap: dma: Clear status registers on enable/disable irq.
Hi,
* Oleg Matcovschi oleg.matcovs...@ti.com [120420 13:49]:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt
status register.
This seems like a nice fix to me. As it affects all omaps, I'd like to
see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a try
with some audio tests?
Also one comment below.
@@ -575,10 +573,15 @@ static inline void omap_enable_channel_irq(int lch)
p-dma_write(dma_chan[lch].enabled_irqs, CICR, lch);
}
-static void omap_disable_channel_irq(int lch)
+static inline void omap_disable_channel_irq(int lch)
{
- if (cpu_class_is_omap2())
- p-dma_write(0, CICR, lch);
+ /* disable channel interrupts */
+ p-dma_write(0, CICR, lch);
+ /* Clear CSR */
+ if (cpu_class_is_omap1())
+ p-dma_read(CSR, lch);
+ else if (cpu_class_is_omap2())
+ p-dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR, lch);
}
You can leave out the else if cpu_class_is_omap2 and replace it
with just else above.
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 3.4-rc4] ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 10:30]: Commit 384ebe1c2849160d040df3e68634ec506f13d9ff, gpio/omap: Add DT support to GPIO driver, introduced dynamic IRQ numbering of OMAP GPIO interrupts, breaking all IH_GPIO_BASE based IRQ number calculations. This issue was corrected in the OMAP GPIO driver and the related header file with commit 25db711df3258d125dc1209800317e5c0ef3c870, gpio/omap: Fix IRQ handling for SPARSE_IRQ. However, the Amstrad Delta FIQ handler, which replaces the gpio-omap driver in serving GPIO interrupts on this board, still uses that outdated method. Fix it. Thanks applying into fixes. Created and tested against linux-3.4-rc4. I've dropped this last line as that's pretty obvious from the commit alone. You can put extra comments like that could between some --- lines: --- This is based on -rc4... --- So they get ignored when the patch gets applied. What is important, is what it was tested on, so saying Tested on ams delta would be more meaningful, although I guess that too is pretty obvious in this case :) Regards, Tony Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- arch/arm/mach-omap1/ams-delta-fiq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c b/arch/arm/mach-omap1/ams-delta-fiq.c index fcce7ff..cfd98b1 100644 --- a/arch/arm/mach-omap1/ams-delta-fiq.c +++ b/arch/arm/mach-omap1/ams-delta-fiq.c @@ -48,7 +48,7 @@ static irqreturn_t deferred_fiq(int irq, void *dev_id) struct irq_chip *irq_chip = NULL; int gpio, irq_num, fiq_count; - irq_desc = irq_to_desc(IH_GPIO_BASE); + irq_desc = irq_to_desc(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK)); if (irq_desc) irq_chip = irq_desc-irq_data.chip; -- 1.7.3.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.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Hi, * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 11:15]: Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze: On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. Tony, Would I get your Ack for this fix if I extend the commit message as Artem suggested? If not, what do you think should be a correct way to fix the regression? Well how about adding some exported functions to drivers/gpio/gpio_omap.c like omap_mpuio_latch? For the regression fix, if you guys want to do what Janusz is suggesting, then assuming the patch description also contains some decent long term plan to properly fix it: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP3/4: cpuidle - misc fixes
These two patches are coming from the series I previously sent for the cpuidle OMAP3/4 cleanups. The first one, move the powerdomain lookup check in the init function, the second one fix the linkage error, when the CONFIG_PM is not set while CONFIG_CPU_IDLE is. Omap's Kconfig has been modified to select CONFIG_PM when CONFIG_CPU_IDLE is set. I compiled with different options but I was not able to boot my board because the kernel panics for another reason. Daniel Lezcano (2): ARM: OMAP3: cpuidle - check the powerdomain lookup ARM: OMAP3/4: consolidate cpuidle Makefile arch/arm/mach-omap2/Kconfig |2 ++ arch/arm/mach-omap2/Makefile | 11 +++ arch/arm/mach-omap2/cpuidle34xx.c | 11 +++ arch/arm/mach-omap2/cpuidle44xx.c |8 arch/arm/mach-omap2/pm.h | 17 +++-- 5 files changed, 27 insertions(+), 22 deletions(-) -- 1.7.5.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: OMAP3: cpuidle - check the powerdomain lookup
At init time, check the powerdomains lookup is successful otherwise exit the cpuidle driver init function with -ENODEV like what is done for the omap3 cpuidle driver. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org Reviewed-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index f682e17..207bc1c 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -363,6 +363,9 @@ int __init omap3_idle_init(void) per_pd = pwrdm_lookup(per_pwrdm); cam_pd = pwrdm_lookup(cam_pwrdm); + if (!mpu_pd || !core_pd || !per_pd || !cam_pd) + return -ENODEV; + cpuidle_register_driver(omap3_idle_driver); dev = per_cpu(omap3_idle_dev, smp_processor_id()); -- 1.7.5.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 2/2] ARM: OMAP3/4: consolidate cpuidle Makefile
Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.
CONFIG_PM is enabled when CPU_IDLE is enabled because the cpuidle drivers
use some functions from the pm subsystem.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 ++
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
5 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..42f6b89 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -34,6 +34,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARCH_HAS_OPP
+ select PM if CPU_IDLE
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
@@ -51,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select PM if CPU_IDLE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..f46c735 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,10 +64,8 @@ endif
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
- cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
- cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
@@ -81,6 +79,11 @@ endif
endif
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
# PRCM
obj-y += prm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 207bc1c..3134452 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
#include control.h
#include common.h
-#ifdef CONFIG_CPU_IDLE
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
@@ -379,9 +377,3 @@ int __init omap3_idle_init(void)
return 0;
}
-#else
-int __init omap3_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..02d15bb 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
#include pm.h
#include prm.h
-#ifdef CONFIG_CPU_IDLE
-
/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
@@ -199,9 +197,3 @@ int __init omap4_idle_init(void)
return 0;
}
-#else
-int __init omap4_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..ab04d3b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,12 +15,25 @@
#include powerdomain.h
+#ifdef CONFIG_CPU_IDLE
+extern int __init omap3_idle_init(void);
+extern int __init omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+ return 0;
+}
+#endif
+
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
--
1.7.5.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
Hi Arnd, On 05/04/2012 10:56 AM, Arnd Bergmann wrote: On Monday 30 April 2012, Jon Hunter wrote: From: Jon Hunter jon-hun...@ti.com This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. Thanks for picking this up again, I very much appreciate it as not having the binding is blocking a number of other activities. No problem. Design of DMA helpers 1. Supporting devices with multiple DMA controllers In the case of DMA controllers that are using DMA Engine, requesting a channel is performed by calling the following function. struct dma_chan *dma_request_channel(dma_cap_mask_t mask, dma_filter_fn filter_fn, void *filter_param); The mask variable is used to identify the device controller in a list of controllers. The filter_fn and filter_param are used to identify the required dma channel and return a handle to the dma channel of type dma_chan. From the examples I have seen, the mask and filter_fn are constant for a given DMA controller. I believe this is not entirely correct: sometimes the filter_fn is provided by the slave driver, sometimes by the master driver. Ok, but in the master case I assume they still use the same API? Also, the mask does not identify a specific controller, AFAICT it just provides certain constraints. There are cases where a driver can pick from a multitude of dma engine controllers, as long as the channel the constraints are resolved. True, but this should still work in that case. This could be expressed in the device tree by listing multiple dma request lines (one per controller) in the device using it, or the author of the device tree can pick one. Therefore, when registering a DMA controller with device tree we can pass these parameters and store them so that a device can request them when requesting a channel. Hence, based upon this our register function for the DMA controller now looks like this. int of_dma_controller_register(struct device_node *np, dma_cap_mask_t *mask, dma_filter_fn fn); This changes the behavior for drivers that provide their own filter functions, which may or may not be a problem. For examples, have a look at some of these: drivers/spi/spi-ep93xx.c drivers/mmc/host/tmio_mmc_dma.c drivers/usb/renesas_usbhs/fifo.c Ok, thanks for the references! That makes life a little more tricky! 2. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. However, _IF_ legacy devices that are not using DMA Engine, only have a single DMA controller, then this problem is a lot simpler. For example, if we look at the previously proposed API for registering a DMA controller (where we pass the mask and function pointer to the DMA Engine filter function) we can simply pass NULL and hence, a driver requesting the DMA channel information would receive NULL for the DMA Engine specific parameters. Then for legacy devices we simply need a means to return the channel information (more on this later). If there are legacy devices that do have multiple DMA controllers, then maybe they need to be converted to support DMA Engine. I am not sure if this is unreasonable??? I think it's even simpler: any device that uses another interface instead of dmaengine will just have to parse the DT information itself. We should make sure that it uses the same binding though, so we can later migrate to the dmaengine API without having to change the device trees. Yes agreed. 3. Representing and requesting channel information From a hardware perspective, a DMA channel could be represented as ... i. channel index/number ii. channel transfer type (optional) iii. DMA interrupt mapping (optional) Please note that the transfer type is used to indicate if the transfer is to device from memory, to memory from device, to memory from memory, etc. This can be useful when there is a device such as an MMC device that uses two DMA channels, one for reading (RX) and one for writing (TX). Forgetting device tree for now, some drivers use strings to represent a DMA channel instead of using an integer. I assume that these drivers then employ some sort of look-up table to convert the string into a channel number/index that the hardware understands. If this assumption is correct then when moving to a device tree implementation having such look-up tables in the driver should no longer be necessary as the device tree will provide the mapping of channel index/number to the device. Furthermore, it makes sense that device tree uses integers to represent channel as opposed to strings to save the driver having to
Re: [PATCH 1/2] OMAP2+: UART: Fix incorrect population of default uart pads
* Raja, Govindraj govindraj.r...@ti.com [120424 01:41]: On Tue, Apr 24, 2012 at 5:15 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove the default pads adding. I just noticed that this patch breaks runtime PM wakeups for UART console (at least on 3530/Overo with ttyO2 console.) By removing the pads, the initial device_init_wakeup() is not called on port init. Without this call serial_omap_pm() disables runtime PM because it checks device_may_wakeup(). Since runtime PM was disabled, I manually re-enabled it and then enabled wakeups: echo auto /sys/devices/platform/omap_uart.2/power/control echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup Then, after enabling auto-suspend timeouts, it seems wakeups are still not working since the console hangs. Reverting $SUBJECT patch gets things working again. This was decided as part of discussion [1] If we are _reconsidering_ taking this patch [2] to dynamically probe uart pins and enable rx wakeup. I can re-work on the patch[2] as per tony's comments[1] and re-post it. Just to follow up on this.. Let's first get things working reliably, and only then add more PM support. We absolutely can't revert $SUBJECT because it's known to mess up at least smsc911x and ehci on zoom3, hsi on n900 and probably many other things. For the -rc cycle, it seems that [2] is out of question at this point as too intrusive. If the PM wakeups are broken in the default cases, then I suggest we just take few steps back and disable any deeper PM states in the -rc series. Regards, Tony [1]: http://www.spinics.net/lists/linux-omap/msg68226.html [2]: http://www.spinics.net/lists/linux-omap/msg67822.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 09:34 Fri 04 May , Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [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.
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
I could change to use this too no problem. The only concern I have is
that is pioB 12 immutable for all gpio controllers?
Grepping the *.dts* files, at least exynos is using the following
for gpios:
gpios = gpx2 0 0 0 2;
If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
I would said yes but we could use the same notion to create pin-bank
the idea is to refer to the bank and then the pin inside
after if a driver need more argumement as on exynos they will have to
implement their own xlate
as we did on at91 for the irq xlate
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
uart0_rts_cts {
groups = uart0_rxd_txd ;
pins = pioB 17 MUX_B NO_PULL_UP /* rts */
pioB 15 MUX_B NO_PULL_UP ; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = uart0_rts_cts ;
gpios = pioC 1 0;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Yeah sounds doable to me, but can probably be added later?
for the sub-group stuff yes agreed
Regarding grouping, basically for most cases it makes sense to have
three states: default, active, idle instead of just active and idle.
The reason is that for most cases the default pins only need to be
set once for each devices. Only few pins need to toggle between
active and idle states.
yeah agreed
Best Regards,
J.
--
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] arm: omap: fix trivial warnings for dspbridge
* Felipe Contreras felipe.contre...@gmail.com [120423 07:36]: arch/arm/plat-omap/devices.c: In function 'omap_dsp_reserve_sdram_memblock': arch/arm/plat-omap/devices.c:170: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t' arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_init': arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'phys_addr_t' arch/arm/mach-omap2/dsp.c:60: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'phys_addr_t' Thanks I'll apply this into fixes-non-critical. 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] OMAP: igep0020: fix smsc911x dummy regulator id
* Enrico ebut...@users.sourceforge.net [120430 10:23]: From: Enrico Butera ebut...@users.berlios.de Using id 0 causes errors at boot: WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x9c/0xac() sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.0' Fix it by using a random (not-already-used) id, as suggested by Tony Lindgren. Thanks applying into fixes. 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-V6 1/3] ARM: OMAP1: FIX: check possible error condition in timer_init
Hi, * Kevin Hilman khil...@ti.com [120502 13:11]: Vaibhav Hiremath hvaib...@ti.com writes: OMAP1, omap_32k_timer_init() function always returns true, irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code. This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k(). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- This is new patch addition compared to original series (=V5). Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it. I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer Kconfigs. Works fine, but needs small change below for compile warnings. Otherwise, looks good. We need at least one tested-by on some 15xx platform for these changes. Janusz, can you please give this series a try on your board 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: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
* Kevin Hilman khil...@ti.com [120504 09:31]: Hi Thomas, Thomas Petazzoni thomas.petazz...@free-electrons.com writes: I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. On v3.4-rc, can you see if reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect? That patch had some unfortunate side effects, but I haven't seen the problem you see, so I'm not sure if it's related. Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken solution like you mentioned. But if it helps, then the proper fix is to add muxing to board-*.c files for the uart pins and use omap_serial_init_port for each uart instead of omap_serial_init. That should fix the wake-up issues 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: [PATCH] ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.
* Shilimkar, Santosh santosh.shilim...@ti.com [120504 00:37]: On Fri, May 4, 2012 at 12:59 PM, R Sricharan r.sricha...@ti.com wrote: The system dma module has capabiities register indicating the support for descriptor loading, constant fill, etc. Use this instead of OMAP revision check to identify the features supported runtime. This avoids patching the code for feature SOCs which has those capabilities. Signed-off-by: R Sricharan r.sricha...@ti.com --- arch/arm/mach-omap2/dma.c | 11 +++ arch/arm/plat-omap/include/plat/dma.h | 5 + 2 files changed, 12 insertions(+), 4 deletions(-) Looks fine. Will add it to my clean-up series if no has any objection on the patch. Yes this is nice. 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: Incorrect Register Offsets in OMAP Mailbox
* Henry Chan enli.c...@gmail.com [120307 23:33]: Sorry about that. Kind of new at this. -H Signed-off-by: Henry Chan enli.c...@gmail.com Thanks, applying this finally into fixes-non-critical. Tony On 03/05/12 11:34, Tony Lindgren wrote: Hi Henry, * Henry Chan enli.c...@gmail.com [120207 09:25]: Hi, Looks like the register offsets are incorrect in the OMAP mailbox code (arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K. Patch attached. My hardware hasn't come in yet, so I would appreciate it if anyone can share their experience using this code. Can you please reply with your Signed-off-by, it's missing from the patch. Thanks, Tony --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -26,9 +26,9 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define OMAP4_MAILBOX_IRQSTATUS(u)(0x104 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE(u)(0x108 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE_CLR(u)(0x10c + 10 * (u)) +#define OMAP4_MAILBOX_IRQSTATUS(u)(0x104 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u)(0x108 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u)(0x10c + 0x10 * (u)) #define MAILBOX_IRQ_NEWMSG(m) (1 (2 * (m))) #define MAILBOX_IRQ_NOTFULL(m)(1 (2 * (m) + 1)) -- Henry Chan -- 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: add minimal support for Nokia RM-696
Hi Pavel, * Pavel Machek pa...@ucw.cz [120501 03:51]: Hi! Add minimal support for Nokia RM-696 board. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- The patch is based boot-tested with 3.3-rc6. arch/arm/mach-omap2/Kconfig |3 ++- arch/arm/mach-omap2/board-rm680.c| 14 +- arch/arm/plat-omap/include/plat/uncompress.h |1 + 3 files changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e20c8ab..b740c2e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -245,10 +245,11 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680 board + bool Nokia RM-680/696 board depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select MACH_NOKIA_RM696 AFAICT, this is nokia N9. At least help text should state that... config MACH_NOKIA_RX51 bool Nokia RX-51 board diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 8678b38..094473e 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680. + * Board support file for Nokia RM-680/696. * And a comment. Sorry this is already in mainline tree as commit 63fc5f3bb3d0ca9ab4767a801b518aa6335f87ad. Care to do a follow-up patch to add some N9 comments to Kconfig and board-rm680.c? 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] omap3_beagle: init uart2 for beagle rev AX/BX only
Hi,
Looking at this again..
* Govindraj.R govindraj.r...@ti.com [120306 00:34]:
From: Govindraj.R govindraj.r...@ti.com
All beagle boards rev AX/BX have external usb hubs connected to ehci
interface, external hub/peripheral uses a nreset sequence for which
uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle
boards expect rev Ax/BX.
(Reference to all beagle boards rev schematics:
http://beagleboard.org/hardware/design)
Initialising uart2 will lead to serial init taking over uart2_rx pin
so init uart2_rx pin mux only for Beagle AX/BX rev boards.
Dont init uart2 for all other boards allowing usb_ehci functionality.
OK so the above got fixed for the muxing part with commit
bce492c04ba8fc66a4ea0a52b181ba255daaaf54.
To initialise individual uart port by id utilise and modify the existing
available func. omap_serial_board_init.
This makes sense as board specific fixes.
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,7 @@ static void __init omap3_beagle_init_rev(void)
beagle_config.mmc1_gpio_wp = 29;
beagle_config.reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
+ omap_serial_board_init(NULL, 1);
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
@@ -528,7 +529,10 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ omap_serial_board_init(NULL, 0);
+ omap_serial_board_init(NULL, 2);
+ omap_serial_board_init(NULL, 3);
+
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
So this still looks valid, except now you also add the muxing for the
uart pins instead of NULL? Note that you could define OMAP3_UART1_DEFAULT_PINS
etc in some header.
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -393,30 +393,32 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
+ * @port_id: uart port number to be initialised
*
- * Initializes all available UARTs as serial ports. Platforms
+ * Initializes individual UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
+ * for serial ports (e.g initialize individual serial ports based on port
id).
*/
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
+void __init omap_serial_board_init(struct omap_uart_port_info *info, u8
port_id)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
- list_for_each_entry(uart, uart_list, node) {
- bdata.id = uart-num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
-
- if (!info)
- omap_serial_init_port(bdata, NULL);
- else
- omap_serial_init_port(bdata, info[uart-num]);
- }
+ list_for_each_entry(uart, uart_list, node)
+ if (uart-num == port_id) {
+ bdata.id = uart-num;
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ if (!cpu_is_omap24xx())
+ omap_serial_fill_default_pads(bdata);
+
+ if (!info)
+ omap_serial_init_port(bdata, NULL);
+ else
+ omap_serial_init_port(bdata, info);
+ }
}
@@ -428,5 +430,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
*/
void __init omap_serial_init(void)
{
- omap_serial_board_init(NULL);
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node)
+ omap_serial_board_init(NULL, uart-num);
}
Is this fix still needed? If so, it should probably be a separate fix
with it's own description.
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/04/2012 09:06 AM, Jon Hunter wrote:
Hi Stephen,
On 05/03/2012 05:26 PM, Stephen Warren wrote:
On 04/30/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
...
+
+ sdma: dmaengine@4800 {
+ compatible = ti,omap4-sdma
+ reg = 0x4800 0x1000;
+ interrupts = 4;
+ #dma-cells = 2;
+ #dma-channels = 32;
+ #dma-requests = 127;
+ };
+
+
+* DMA client
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by the number of DMA request/channel and the transfer type of the
What exactly is request/channel? Is it a request ID, a channel ID,
both packed into a single integer (which bits are used for each field),
etc.?
The thought here was that some DMAs may distinguish between devices by a
request ID or a channel ID or both. In the case of say an OMAP4, we have
32 channels and 127 request IDs. From a h/w perspective we need to know
both. Each of the 32 channels can be programmed to use any one of the
127 h/w request signals.
From a HW perspective, do you actually need to know both? I think the HW
description must specify the request ID, but because any channel can be
programmed to any request ID, you don't actually care about the channel
ID; it can be dynamically allocated by the DMA driver when the client
driver calls dma_request_channel().
Actually, you say the following below, so I guess you already agree here:
Yes this is the same as OMAPs SDMA. In the case of such DMA controllers
you only really care about the request ID and total number of channels
that are available to you.
...
This is why I think DMA controller should specify the format of their
own DMA specifier in DT, and why they should provide an xlate function
to parse that.
Ok fair enough. However, it seems that at a minimum we could provide one
or two xlate functions in the generic binding for people to use. One
could be the DMA engine xlate binding and another could be the simple
xlate binding Nicolas proposed for a DMA controller that returns a
single channel/request ID.
However, at the same time, may be people would prefer that devices such
as tegra, omap, at91, etc, offer their own xlate function for DMA
engine. I am not sure, but we could go either way.
I'd expect the bindings to be written to allow the individual DMA
controllers to have complete control over the meaning of the DMA specifier.
That said, I would certainly expect some common patterns to emerge, such
as a single cell to specify the DMA channel ID, or a single cell to
specify the DMA request/selector ID. We should certainly make sure that
where different controllers need the same information, they use the same
way to represent it, and use common utility code to implement the xlate
functionality. We could perhaps even write these common cases into the
core DMA bindings as examples to help ensure uniformity. However, we
just need to do this in a way that allows other cases too.
--
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] net: davinci_emac: Add pre_open, post_stop platform callbacks
On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote: Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi Kevin. If it does, perhaps there should some other mechanism for letting users control the system behavior. Come to think of it, the right solution here is probably to use runtime PM. We could then to add some custom hooks for davinci_emac in the device code to use enable_hlt/disable_hlt based on activity. That was my first thought, actually, but that only works if its okay for the driver to call enable_hlt/disable_hlt directly (i.e., have runtime_suspend() call enable_hlt() and runtime_resume() call disable_hlt()). However, I assumed it would _not_ be acceptable for the driver to issue those calls directly. Its a platform-specific issue that we shouldn't be polluting the driver with and there are currently no drivers that call them under the drivers directory. If its not okay to call enable_hlt/disable_hlt directly, then we still need callback hooks to the plaform code (i.e., some version of this patch). In order to do that though, the davinci_emac driver needs to be runtime PM converted. We probably should pm_runtime-ize the driver either way but we need to resolve the question of whether its okay for the driver to call enable_hlt/disable_hlt directly or not. If it is okay, we call them in runtime_suspend/resume. If it isn't okay, then we still need platform callback hooks. Mark -- 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/04/2012 09:56 AM, Arnd Bergmann wrote:
On Monday 30 April 2012, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
...
Forgetting device tree for now, some drivers use strings to represent a
DMA channel instead of using an integer. I assume that these drivers then
employ some sort of look-up table to convert the string into a channel
number/index that the hardware understands. If this assumption is correct
then when moving to a device tree implementation having such look-up tables
in the driver should no longer be necessary as the device tree will provide
the mapping of channel index/number to the device. Furthermore, it makes
sense that device tree uses integers to represent channel as opposed to
strings to save the driver having to convert the string into a integer at
some later stage.
...
I think you can actually use strings, too, as long as you use a fixed number
of cells.
Wouldn't something like this work:?
...
some-device {
compatible = something;
dmas = dma-controller1, some-dma,
dma-controller2 1 2 3;
}
The idea of mixing integer cells and strings in the same property has
come up before for other bindings, but been rejected. IIRC, there are
issues such as alignment of the integers after the string (they are not
aligned in the DTB) which can cause unaligned accesses, and perhaps
other issues I fail to recall - perhaps because it's no longer possible
to skip from the dma-controller1 phandle to the dma-controller2
phandle using #dma-cells, but rather you need to use strlen() and hence
involve the DMA controller driver itself (otherwise, how do you know
it's a string?) rather than just the core DMA property parsing code.
--
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 4/4] ARM: OMAP3+: am33xx: Add powerdomain PRM support
* Hiremath, Vaibhav hvaib...@ti.com [120426 23:40]: On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: As far as PRM/CM/PRCM modules are concerned, AM33XX device is different than OMAP3 and OMAP4 architectures; so we need to handle it separately. This patch adds support for, Powerdomain, Powerdomain data, PRM api's required for AM33XX device. And also, hooks up AM33XX powerdomain to existing OMAP framework. [...] @@ -1288,7 +1289,15 @@ static int _assert_hardreset(struct omap_hwmod *oh, const char *name) if (IS_ERR_VALUE(ret)) return ret; - if (cpu_is_omap24xx() || cpu_is_omap34xx()) + /* + * cpu_is_omap34xx() is true for am33xx device as well, so + * fist check for cpu_is_am33xx(). + */ + if (cpu_is_am33xx()) + return am33xx_prm_assert_hardreset(ohri.rst_shift, + oh-clkdm-pwrdm.ptr-prcm_offs, + oh-prcm.omap4.rstctrl_offs); This still troubles me. I *really* don't like that we have a dependence on cpu_is* call ordering. This is very fragile and error prone. I also don't like all the cpu_is* checking currently in omap_hwmod.c (which is here before you added this) and have an idea on how to clean it up, I should have a patch by tomorrow for this. That should help adding am33xx support here without needing all the cpu_is* checking. That being said, I just did a simple experiment[1] to see why cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based on my quick experiment, it does not appear to be needed. I think our lives will be much simpler if cpu_is_omap34xx() is not true for the AM335x family. Can you have a look at my test branch[1] and see what you think? I changed the omap_revision for AM335x so that cpu_is_omap34xx() is no longer true on this platform. Then, I only needed to fixup the SRAM init, and it boots just fine on my BeagleBone. I really think we need to go this route, because having cpu_is_omap34xx() true on AM335x is causing more headaches than it is solving problems. This will require you to rework a little bit these clock/power/voltage domain patches, but I belive it will greatly simplify the maintainability of the end result. Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. But honestly, I fully agree with you that, we are creating more issue, adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. As I have done in the past initially, I recommend and vote for, 1. Creating separate family cpu_is_am33xx() for AM33xx device. OR 2. Bring it to omap44xx family, since prcm block is closer to omap4 and not with omap3. Also, Tony, I will let tony make a decision on this. By the time, Tony makes his decision, I will spend time to explore your (Kevin's below) branch. Just to summarize, I guess it's pretty obvious that we need cpu_is_am33xx here. In general work on getting rid of the cpu_is_ checks as they are not safe to use with single zImage in initcalls. 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] net: davinci_emac: Add pre_open, post_stop platform callbacks
On Fri, May 04, 2012 at 09:44:45AM -0700, Kevin Hilman wrote: Hi Mark, Hi Kevin. Mark A. Greer mgr...@animalcreek.com writes: [...] To work around this issue, add platform data callbacks which are called at the beginning of the open routine and at the end of the stop routine of the davinci_emac driver. The callbacks allow the platform code to issue disable_hlt() and enable_hlt() calls appropriately. Calling disable_hlt() prevents cpu_idle from issuing the 'wfi' instruction. OK, I'm feeling rather dumb for not thinking of this before and suggesting that you use pdata callbacks. But there is a better solution: runtime PM. I hadn't noticed before that since this driver comes from davinci, it uses the clock API and not runtime PM which all OMAP drivers have been (or are being) converted to. If we replace the clock API usage in this driver with proper runtime PM usage, we can make this work. Basically, clk_enable() turns into pm_runtime_get_sync() and clk_disable() turns into pm_runtime_put(). With that, the OMAP PM core will get callbacks whenever the device is [not] needed and we can use device-specific hooks to call disable_hlt/enable_hlt. The only catch though is that in order for this driver to be converted to runtime PM and still work on davinci devices, the davinci kernel needs to grow runtime PM support. I belive Sekhar is already looking into this, and OMAP1 (mach-omap1/pm_bus.c) will be a good example of how to get a basic runtime PM implementation working for davinci which just does basic clock management. Having worked on the guts of runtime PM for OMAP, I know it pretty well (which is all the more embarrasing that I didn't think of suggesting it sooner.) So, let me know how I can help. As a quick hack to test my idea will help, you can try simply calling disable_hlt() after clk_enable() and enable_hlt() after clk_disable() in teh davinci_emac driver. That will effectively be what happens after a runtime PM conversion with device-specific hooks. The (not even compile tested) patch below does this. For starters, can you tell me if this results in normal performance on the EMAC? No worries. I thought of pm_runtime before embarking on this patch, actually. I explained why I did this patch anyaway in another email-- our emails crossed in the ether. diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 174a334..c92bc28 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1909,6 +1909,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) netif_napi_add(ndev, priv-napi, emac_poll, EMAC_POLL_WEIGHT); clk_enable(emac_clk); + disable_hlt(); /* register the network device */ SET_NETDEV_DEV(ndev, pdev-dev); @@ -1929,6 +1930,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev) netdev_reg_err: clk_disable(emac_clk); + enable_hlt(); no_irq_res: if (priv-txchan) cpdma_chan_destroy(priv-txchan); @@ -1979,6 +1981,7 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev) clk_disable(emac_clk); clk_put(emac_clk); + enable_hlt(); return 0; } Yes, this works (it essentially does what my patches do except I did the calls in open/stop instead of probe/remove :). Mark -- 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/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [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.
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
I could change to use this too no problem. The only concern I have is
that is pioB 12 immutable for all gpio controllers?
You mean is the number of cells used to specify a GPIO the same
everywhere? No. It's defined by #gpio-cells in the GPIO controller node.
But again, the GPIO binding shouldn't be related to the pinctrl binding
directly.
Grepping the *.dts* files, at least exynos is using the following
for gpios:
gpios = gpx2 0 0 0 2;
If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
I don't really see how that DT format represents pins, functions, and
nodes directly, and separately from which of those a board chooses to
use. I think this binding and the one Tony originally proposed are
eseentially semantically identical.
Going back to my idea of separating SoC and board configurations, if we
did that, I'd expect to see something more like:
soc.dtsi or board.dts:
This is the data that the pin controller driver needs to export to
pinctrl core. This can be completely enumerated in the soc.dtsi, or
perhaps for uncommonly used pins/groups/functions, only included in the
board.dts that actually uses it to cut down on soc.dtsi's size:
This data is not needed for SoCs whose pinctrl drivers include it in
their driver file instead of DT.
/ {
pinctrl@... {
pins {
uart1_rx_pin: uart1_rx {
/* register to program the pin if per-pin muxing*/
reg = ...;
name = UART1_RX;
...;
}
uart1_tx_pin: uart1_tx {
reg = ...;
name = UART1_TX;
...;
}
uart2_rx_pin: uart2_rx {
reg = ...;
name = UART2_RX;
...;
}
uart2_tx_pin: uart2_tx {
reg = ...;
name = UART2_TX;
...;
}
};
pingroups {
uart1_pg: uart1 {
/* register to program the group, if per-grouop muxing */
reg = ...;
pins = pin_uart1_rx pin_uart1_tx;
}
uart2_pg: uart2 {
pins = pin_uart2_rx pin_uart2_tx;
}
};
functions {
uart1_func: uart1 {
selectable-on = uart1_pg 0; /* where, mux value */
};
uart2_func: uart2 {
selectable-on = uart2_pg 0;
};
spi_func: spi {
selectable-on = uart1_pg 1 uart2_pg 1;
};
};
soc.dtsi or board.dts:
This is part of the data used to construct the mapping table. Common
options for function X on pin/pingroup Y can be included in soc.dtsi to
reduce duplication in board files. Uncommon options can be included
directly in the board.dts that uses them, to avoid bloating soc.dtsi:
This data is needed irrespective of whether a SoC pinctrl driver stores
the pin/function/group information in DT or in the driver itself.
/ {
pinctrl@... {
uart1_uart1 {
muxing = uart1_pg
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 4 May 2012 20:47, Jon Hunter jon-hun...@ti.com wrote:
Hi Jassi,
On 05/04/2012 01:56 AM, Jassi Brar wrote:
On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree (as far as I understand), is to describe the
capabilites of the hardware. Thinking about DMA controllers purely from the
context of the hardware to begin with, we can describe a device in terms of
a DMA controller as follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to
extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task.
Sorry for being slow, but so far I thought DT is only to provide _h/w_
specific info
to the _controller_ drivers. It was not supposed to provide any info
pertaining to
some API (dmaengine in this case).
And I believe this is one of few situations where we are better off
not generalizing
the interface - pass controller specific info in the controller
driver's specified format.
Generalizing only seems to complicate things here, when we anyway have
machine
specific dtb, which could always have clients requesting and the
controllers given
dma's info in controller driver's specific format.
Perhaps I am overlooking the need to generalize. If you think so, please
help me
understand by pointing out some use case for it.
No not really, your points are valid. From reading the previous
discussions one of the items that was clearly lacking was the ability to
represent and identify a device having more than one DMA controller. In
other words, when you request the DMA resource, how do you identify
which DMA controller in the system that resource belongs too. With DMA
engine there are ways we can do this.
Well, if we really can't have dmac drivers make 'intelligent' runtime decision
of request mapping on more than one capable controllers, we still can
make it simpler than the proposed scheme.
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
Channel properties like duplex, priority etc specified in client's dt node
doesn't seem really necessary - the client's driver is able to adjust
according to the capability of the channel the dmaengine api is able
to provide and the client driver can't really do anything if it saw txrx
specified in it's dt node while it doesn't yet support full-duplex (say).
Having spilled my guts and realizing the fact that the Maradonas and Peles
of the game seem to have already bought the scheme, I am afraid it only
points to my not yet diagnosed adhd :o
--
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 Friday 04 May 2012, Jon Hunter wrote:
I believe this is not entirely correct: sometimes the filter_fn is provided
by the slave driver, sometimes by the master driver.
Ok, but in the master case I assume they still use the same API?
The all use dma_request_channel, but the format of the data that gets
passed depends only on whoever provides the filter function, which
is not necessarily the slave or the master, but could be either one.
FWIW, I believe that for each dma engine implementation we only do
one or the other, i.e. if the dmaengine driver provides a filter function,
it is always used with these devices.
Next we need to think about how the DMA controller and channels are
described
in the device tree itself. The following device tree node example
describes
the properties of the DMA controller that includes, the register address
range, number of interrupt supported, number of channels and number of
request
signals. This has been enhanced from the previous versions by adding
number of
channels and number of request signals.
I think you can actually use strings, too, as long as you use a fixed number
of cells.
Wouldn't something like this work:?
dma-controller1: dma1 {
compatible = something-using-strings;
#dma-cells = 1;
};
dma-controller2: dma2 {
compatible = something-using-integers;
#dma-cells = 3
};
some-device {
compatible = something;
dmas = dma-controller1, some-dma,
dma-controller2 1 2 3;
}
The only hard requirement is that the format of the attributes is
what the binding specific to that controller understands.
Yes it could. My point was why do this, if at the end of the day you
need to resolve the string into a number at some point in the driver?
However, this may make the migration easier for those using strings.
Well, actually Stephen just clarified that we should not use strings
here :(
We will always have to use numbers then.
I think a better interface for the device driver would be something that
combines
your of_get_dma_channel_info() function with the dma_request_channel()
function,
like
struct dma_chan *of_dma_request_channel(struct device_node *dn, int
index);
When we have the device tree, the driver using that channel doesn't
actually have
to care about the specific of how the channel is defined any more, it just
needs
to say which one it's interested in, out of the list of channels defined
for that
device node.
Yes true. I was trying to avoid any changes to DMA engine itself. Plus
in the feedback from Stephen his preference was to isolate the binding
from DMA engine.
So in your example, is index passed via dma_request_channel()? I assume
that of_dma_request_channel() get called in the context of
dma_request_channel somewhere???
What I meant what that you should still provide the existing
dma_request_channel interface without changes, and also provide
of_dma_request_channel as a wrapper around it that does a lookup
in the way that your of_get_dma_channel_info does, passing the
data it gets back from the device tree into the filter function
that was provided by the dma engine driver.
By the way, have you looked at the pl330_filter() function
(drivers/dma/pl330.c)? They parse the device-tree in the filter function
itself. The index could be passed as the filter_param. In this type of
implementation there would be no need for a generic dma binding.
However, would only work for devices supporting DMA engine.
IMHO this will have to change, we should not have allowed a nonstandard
binding for pl330 to be used for the samsung platforms and should migrate
to the new binding as soon as possible.
Arnd
--
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 RESEND] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
* Archit Taneja arc...@ti.com [120419 05:13]: This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Thanks applying into fixes. Tony Cc: sta...@vger.kernel.org # v3.2+ Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- Note: Resend with stable kernel list added in cc .../include/mach/ctrl_module_pad_core_44xx.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h index 1e2d332..c88420d 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h @@ -941,10 +941,10 @@ #define OMAP4_DSI2_LANEENABLE_MASK (0x7 29) #define OMAP4_DSI1_LANEENABLE_SHIFT 24 #define OMAP4_DSI1_LANEENABLE_MASK (0x1f 24) -#define OMAP4_DSI2_PIPD_SHIFT19 -#define OMAP4_DSI2_PIPD_MASK (0x1f 19) -#define OMAP4_DSI1_PIPD_SHIFT14 -#define OMAP4_DSI1_PIPD_MASK (0x1f 14) +#define OMAP4_DSI1_PIPD_SHIFT19 +#define OMAP4_DSI1_PIPD_MASK (0x1f 19) +#define OMAP4_DSI2_PIPD_SHIFT14 +#define OMAP4_DSI2_PIPD_MASK (0x1f 14) /* CONTROL_MCBSPLP */ #define OMAP4_ALBCTRLRX_FSX_SHIFT31 -- 1.7.5.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 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
* Jon Hunter jon-hun...@ti.com [120425 08:16]:
Hi Tero,
On 04/25/2012 02:33 AM, Tero Kristo wrote:
On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
+/**
+ * omap4_dpll_print_reg - dump out a single DPLL register value
+ * @dpll_reg: register to dump
+ * @name: name of the register
+ * @tuple: content of the register
+ *
+ * Helper dump function to print out a DPLL register value in case
+ * of restore failures.
+ */
+static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
*name,
+ struct dpll_reg *tuple)
+{
+ if (tuple-offset)
+ pr_warn(%s - Address offset = 0x%08x, value=0x%08x\n, name,
+ tuple-offset, tuple-val);
Minor nit-pick here ...
1. Offset is 16-bits and so we can just have offset = 0x%04x
2. Consider dropping Address from Address offset
3. Can we be consistent in our spaces for offset = and value=?
+}
+
+/*
+ * omap4_dpll_dump_regs - dump out DPLL registers
+ * @dpll_reg: DPLL to dump
+ *
+ * Dump out the contents of the registers for a DPLL. Called if a
+ * restore for DPLL fails to lock.
+ */
+static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
+{
+ pr_warn(%s: Unable to lock dpll %s[part=%x inst=%x]:\n,
+ __func__, dpll_reg-name, dpll_reg-mod_partition,
+ dpll_reg-mod_inst);
+ omap4_dpll_print_reg(dpll_reg, clksel, dpll_reg-clksel);
+ omap4_dpll_print_reg(dpll_reg, div_m2, dpll_reg-div_m2);
+ omap4_dpll_print_reg(dpll_reg, div_m3, dpll_reg-div_m3);
+ omap4_dpll_print_reg(dpll_reg, div_m4, dpll_reg-div_m4);
+ omap4_dpll_print_reg(dpll_reg, div_m5, dpll_reg-div_m5);
+ omap4_dpll_print_reg(dpll_reg, div_m6, dpll_reg-div_m6);
+ omap4_dpll_print_reg(dpll_reg, div_m7, dpll_reg-div_m7);
+ omap4_dpll_print_reg(dpll_reg, clkdcoldo, dpll_reg-clkdcoldo);
+ omap4_dpll_print_reg(dpll_reg, clkmode, dpll_reg-clkmode);
+ omap4_dpll_print_reg(dpll_reg, autoidle, dpll_reg-autoidle);
+ if (dpll_reg-idlest.offset)
+ pr_warn(idlest - Address offset = 0x%08x, before val=0x%08x
+ after = 0x%08x\n, dpll_reg-idlest.offset,
+ dpll_reg-idlest.val,
+ omap4_dpll_read_reg(dpll_reg, dpll_reg-idlest));
Nit-pick ...
1. Same comments as above
2. Consider dropping Address offset altogether here as we print
idlest the offset should be implied.
3. Also can we be consistent in our naming of before val and after?
For example, val before = and val now = .
Okay, I'll modify both prints slightly. Question though, do we want
these prints in the kernel in the first place? At least Tony has been
frowning upon register dumps in the kernel and this falls into that
category. What we could do is just to print the warning but drop the
register dumps out.
Thanks. Good question. If we are not seeing failures often, and I would
hope not, probably ok to remove. However, I will let Tony comment here ...
Well if the register dumps really help trace the issue and don't happen
continuously I'm fine with them.
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 Friday 04 May 2012, Jassi Brar wrote:
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.
Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.
If I understand you correctly, you think we can generalize the dma-request
data in a way that we don't need to pass a specific dma engine phandle.
I very much doubt this is possible, given how different the requirements
are for each of the engines we support. You really need to pass a specific
phandle so that we can find the code that can interpret the data in a
meaningful way.
It would be nice though if we could support your scenario where multiple
dma engines are available that can be used by a single client.
I've already mentioned that I think we can provide multiple channel
definitions and let the driver request each of them until one succeeds,
but that does require extra code inside of each driver that might need
to do this.
Another alternative would be to change the binding so that it can deal
with multiple distinct dmaengine instances using a single device node.
Given the example from exynos5250.dtsi, which currently contains this
fragment:
pdma0: pdma@121A {
compatible = arm,pl330, arm,primecell;
reg = 0x121A 0x1000;
interrupts = 0 34 0;
};
pdma1: pdma@121B {
compatible = arm,pl330, arm,primecell;
reg = 0x121B 0x1000;
interrupts = 0 35 0;
};
mdma0: pdma@1080 {
compatible = arm,pl330, arm,primecell;
reg = 0x1080 0x1000;
interrupts = 0 33 0;
};
mdma1: pdma@11C1 {
compatible = arm,pl330, arm,primecell;
reg = 0x11C1 0x1000;
interrupts = 0 124 0;
};
We could transform it into one node with multiple children:
dma: dma-engines {
compatible = arm,pl330-multi, arm,primecell;
#dma-cells = 3;
#address-cells = 1;
#size-cells = 1;
ranges;
pdma@121A {
compatible = arm,pl330, arm,primecell;
arm,pl330-instance = 0;
reg = 0x121A 0x1000;
interrupts = 0 34 0;
};
pdma@121B {
compatible = arm,pl330, arm,primecell;
arm,pl330-instance = 1;
reg = 0x121B 0x1000;
interrupts = 0 35 0;
};
pdma@1080 {
compatible = arm,pl330, arm,primecell;
arm,pl330-instance = 2;
reg = 0x1080 0x1000;
interrupts = 0 33 0;
};
pdma@11C1 {
compatible = arm,pl330, arm,primecell;
arm,pl330-instance = 3;
reg = 0x11C1 0x1000;
interrupts = 0 124 0;
};
};
This way, a client would just point to the dma-engines device node
that cover all of the actual engines, and the pl330 code registers
the four devices with the dmaengine layer.
Arnd
--
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/02/2012 11:24 AM, Tony Lindgren wrote:
Add simple pinctrl driver using device tree data.
Currently this driver only works on omap2+ series of
processors, where there is either an 8 or 16-bit padconf
register for each pin. Support for other similar pinmux
controllers could be added.
Note that this patch does not yet support pinconf_ops
or GPIO. Further.
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's this one finally updated to use the common pinctrl bindings.
That sure cleaned up a bunch of the nasty things in this driver :)
Nice job Stephen!
Thanks.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
+Required properties:
+- compatible : one of:
+ - pinctrl-simple
+ - ti,omap2420-padconf
+ - ti,omap2430-padconf
+ - ti,omap3-padconf
+ - ti,omap4-padconf
I'm in two minds about this.
If this is truly intended to be generic, I would not document any of the
ti compatible values here. Instead, I'd create a binding document for
the TI controllers that basically just says this uses the bindings in
pinctrl-simple.txt, with the following additions, and list the
compatible values as an addition.
On the other hand, I worry about whether using pinctrl-simple here as
the compatible value is going to cause issues:
Certainly, this is a pretty simple driver, and most likely reasonably
generic an applicable to many SoCs. However, it doesn't cover a bunch of
cases that I'd still consider simple. For example, what if each pin
has a separate mux and pinconf register? There are probably many such
small cases that would add up to something more complex. to cover those
cases, will we be able to extend pinctrl-simple to cover them, and
continue to be backwards compatible, or will we need to create a
binding/driver for pinctrl-simple-1, pinctrl-simple-2, pinctrl-simple-3
each of which covers some different, yet still simple, configuration?
To resolve this, perhaps it would be best to rework this binding and
driver as a set of utility code that other bindings and drivers can
build upon, rather than making it a standalone directly usable driver
and binding.
Honestly, I'm not really sure which way to go here.
+- reg : offset and length of the register set for the mux registers
+- #pinctrl-cells : width of the pinctrl array, currently only 2 is supported
+- pinctrl-simple,register-width : pinmux register access width
+- pinctrl-simple,function-mask : mask of allowed pinmux function bits
+- pinctrl-simple,function-off : function off mode for disabled state
+- pinctrl-simple,pinconf-mask : mask of allowed pinconf bits
+
+This driver uses the common pinctrl bindings as specified in
+pinctrl-bindings.txt document in this directory. The common bindings are used
+to specify the client device states using pinctrl-0 and pinctrl-names
entries.
I think just remove the second sentence there; it's implicit given the
first.
+/* board specific .dts file, such as omap4-sdp.dts */
+omap4_pmx_core {
+
+ /*
+ * map all board specific static pins enabled by the pinctrl driver
+ * itself during the boot (or just set them up in the bootloader)
+ */
+ pinctrl-names = default;
+ pinctrl-0 = board_pins;
+
+ board_pins: pinmux_board_pins {
+ board_static_pins {
I'd like to see a little more explanation of the node structure here.
I.e. what does each node represent, why are there two levels of nodes, etc.
Given that the pinctrl-simple,cells can specify both mux function and
pin configuration for each pin, i.e. everything you need to, I don't see
why you'd ever need two levels of nodes here. I'd expect each pin
configuration node (in pinctrl core bindings terminology) to be a
single level:
node {
pinctrl-simple,cells = ...;
};
where node is what's references in the pinctrl-0 property by pinctrl
client drivers.
+ pinctrl-simple,cells =
cells here doesn't seem like the right word. Perhaps pins or
configuration? Cells to me seems semi-reserved for binding cell
count description, like #gpio-cells, #address-cells, etc.
Also, there's nothing in the free-form text part of this binding
document that says describes the set of properties that need to exist in
these pin configuration nodes, nor what their content is.
+ 0x6c 0xf/* CSI21_DX3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x6e 0xf/* CSI21_DY3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x70 0xf/* CSI21_DX4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x72 0xf/* CSI21_DY4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ ;
+ };
+ };
+
+
+ /* map all uart2 pins as a single function */
+ uart2_pins: pinmux_uart2_pins {
+ uart2_pins {
+
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Arnd,
On 05/04/2012 02:06 PM, Arnd Bergmann wrote:
On Friday 04 May 2012, Jon Hunter wrote:
I believe this is not entirely correct: sometimes the filter_fn is provided
by the slave driver, sometimes by the master driver.
Ok, but in the master case I assume they still use the same API?
The all use dma_request_channel, but the format of the data that gets
passed depends only on whoever provides the filter function, which
is not necessarily the slave or the master, but could be either one.
FWIW, I believe that for each dma engine implementation we only do
one or the other, i.e. if the dmaengine driver provides a filter function,
it is always used with these devices.
Ok, I think I am with you now. That should be fine.
Next we need to think about how the DMA controller and channels are
described
in the device tree itself. The following device tree node example
describes
the properties of the DMA controller that includes, the register address
range, number of interrupt supported, number of channels and number of
request
signals. This has been enhanced from the previous versions by adding
number of
channels and number of request signals.
I think you can actually use strings, too, as long as you use a fixed number
of cells.
Wouldn't something like this work:?
dma-controller1: dma1 {
compatible = something-using-strings;
#dma-cells = 1;
};
dma-controller2: dma2 {
compatible = something-using-integers;
#dma-cells = 3
};
some-device {
compatible = something;
dmas = dma-controller1, some-dma,
dma-controller2 1 2 3;
}
The only hard requirement is that the format of the attributes is
what the binding specific to that controller understands.
Yes it could. My point was why do this, if at the end of the day you
need to resolve the string into a number at some point in the driver?
However, this may make the migration easier for those using strings.
Well, actually Stephen just clarified that we should not use strings
here :(
We will always have to use numbers then.
Ok. I think it makes life easier in the long run too.
I think a better interface for the device driver would be something that
combines
your of_get_dma_channel_info() function with the dma_request_channel()
function,
like
struct dma_chan *of_dma_request_channel(struct device_node *dn, int
index);
When we have the device tree, the driver using that channel doesn't
actually have
to care about the specific of how the channel is defined any more, it just
needs
to say which one it's interested in, out of the list of channels defined
for that
device node.
Yes true. I was trying to avoid any changes to DMA engine itself. Plus
in the feedback from Stephen his preference was to isolate the binding
from DMA engine.
So in your example, is index passed via dma_request_channel()? I assume
that of_dma_request_channel() get called in the context of
dma_request_channel somewhere???
What I meant what that you should still provide the existing
dma_request_channel interface without changes, and also provide
of_dma_request_channel as a wrapper around it that does a lookup
in the way that your of_get_dma_channel_info does, passing the
data it gets back from the device tree into the filter function
that was provided by the dma engine driver.
Ok, gotcha.
By the way, have you looked at the pl330_filter() function
(drivers/dma/pl330.c)? They parse the device-tree in the filter function
itself. The index could be passed as the filter_param. In this type of
implementation there would be no need for a generic dma binding.
However, would only work for devices supporting DMA engine.
IMHO this will have to change, we should not have allowed a nonstandard
binding for pl330 to be used for the samsung platforms and should migrate
to the new binding as soon as possible.
Ok, that's fine with me.
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.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Fri, 4 May 2012 10:11:25 Tony Lindgren wrote: Hi, * Janusz Krzysztofik jkrzy...@tis.icnet.pl [120430 11:15]: Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze: On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. Tony, Would I get your Ack for this fix if I extend the commit message as Artem suggested? If not, what do you think should be a correct way to fix the regression? Well how about adding some exported functions to drivers/gpio/gpio_omap.c like omap_mpuio_latch? For the regression fix, if you guys want to do what Janusz is suggesting, then assuming the patch description also contains some decent long term plan to properly fix it: Acked-by: Tony Lindgren t...@atomide.com Thanks. Now that we know you prefer to keep the memory requested from inside the gpio-omap, which I was about to suggest to drop back as an alternative fix, I'll try to cook a new description for my patch, and perhaps add a comment replacing the request_mem_region function removed from the ams-delta NAND driver, in order to satisfy both yours and Artem's comments in a few days. Regards, Janusz -- 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
* Tomi Valkeinen tomi.valkei...@ti.com [120425 05:32]: On Tue, 2012-04-24 at 10:16 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [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 tomi.valkei...@ti.com 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. 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] omap: dma: Clear status registers on enable/disable irq.
Dnia piątek, 4 maja 2012 09:51:46 Tony Lindgren pisze: Hi, * Oleg Matcovschi oleg.matcovs...@ti.com [120420 13:49]: Use omap_disable_channel_irq() function instead of directly accessing CICR. The omap_disable_chanel_irq() function clears pending interrupts and disables interrupt on channel. Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt status register. This seems like a nice fix to me. As it affects all omaps, I'd like to see some tested-by from Janusz/Jarkko/Peter. Can you guys give it a try with some audio tests? OK, I can do, but perhaps not before next Saturday, when I'm back home, able to actually listen to the audio, not only watch the IRQ counters rising up ;-). Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V6 1/3] ARM: OMAP1: FIX: check possible error condition in timer_init
Dnia piątek, 4 maja 2012 10:43:02 Tony Lindgren pisze: Hi, * Kevin Hilman khil...@ti.com [120502 13:11]: Vaibhav Hiremath hvaib...@ti.com writes: OMAP1, omap_32k_timer_init() function always returns true, irrespective of whether error occurred while initializing 32k sync counter as a kernel clocksource or not and execution will never fallback to mpu_timer clocksource init code. This patch adds check for return value from function omap_init_clocksource_32k(), and fallback to omap_mpu_timer_init() in case of failure/error from omap_init_clocksource_32k(). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- This is new patch addition compared to original series (=V5). Also, note that, this patch is only compile tested, since I do not have omap1 board with me to validate it. Kevin, can you help me to validate it. I boot tested on OMAP1 (5912/OSK) with 32k timer and MPU timer Kconfigs. Works fine, but needs small change below for compile warnings. Otherwise, looks good. We need at least one tested-by on some 15xx platform for these changes. Janusz, can you please give this series a try on your board too? Sure, but in a week or so. I'm still trying to follow the l-o list, but please always Cc: me for testing any changes on Amstrad Delta whenever you see fit. Regards, Janusz -- 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: igep0020: Specify the VPLL2 regulator unconditionally
* Enric Balletbò i Serra eballe...@gmail.com [120427 02:30]:
2012/4/23 Laurent Pinchart laurent.pinch...@ideasonboard.com:
The supply is connected to the DSS DO-D5 pins and is thus needed for
both serial and parallel display interfaces on the igep0030 as well as
the igep0020.
If the igep0030 module isn't connected to a display, no DSI or DPI
display will be specified in board code, and the DSS driver won't enable
to VPLL2 regulator anyway.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/board-igep0020.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index a59ace0..242cdff 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -539,7 +539,10 @@ static void __init igep_i2c_init(void)
{
int ret;
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB, 0);
+ omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_USB,
+ TWL_COMMON_REGULATOR_VPLL2);
+ igep_twldata.vpll2-constraints.apply_uV = true;
+ igep_twldata.vpll2-constraints.name = VDVI;
if (machine_is_igep0020()) {
/*
@@ -553,10 +556,7 @@ static void __init igep_i2c_init(void)
igep_twldata.keypad = igep2_keypad_pdata;
/* Get common pmic data */
- omap3_pmic_get_config(igep_twldata, TWL_COMMON_PDATA_AUDIO,
- TWL_COMMON_REGULATOR_VPLL2);
- igep_twldata.vpll2-constraints.apply_uV = true;
- igep_twldata.vpll2-constraints.name = VDVI;
+ omap3_pmic_get_config(igep_twldata,
TWL_COMMON_PDATA_AUDIO, 0);
}
omap3_pmic_init(twl4030, igep_twldata);
--
Regards,
Laurent Pinchart
--
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
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Yes seems like a valid fix to me so applying into fixes.
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 4/7] ARM: OMAP2: Add MMC hwmod data for 2420
* Paul Walmsley p...@pwsan.com [120502 18:05]: On Wed, 2 May 2012, Paul Walmsley wrote: Hi Tony, On Mon, 23 Apr 2012, Tony Lindgren wrote: Add MMC for 2420 so we can pass the DMA request lines the same way as we already do on omap2430 and later. Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Tony Lindgren t...@atomide.com Made a few changes here so that it applies on the omap-devel-a-for-3.5 tag that you pulled in. Also changed the 2420 MMC class name to msdi and the hwmod name to msdi1 -- this is the IP block name that is listed in the 2420 TRM Rev. X Table 26-9 Instance Summary. It also is convenient for us, because the 2420 MMC driver is different than the 2430+ HSMMC driver, so we can just probe all of the hwmods of class msdi to register the 2420 MMC :-) Also, forgot to mention that a struct omap_hwmod_class_sysconfig record was added here too, based on the info in the 2420 TRM. The updated patch is below. Have queued it in a hwmod data update branch here along with some other hwmod data updates. Will send a pull request after testing is finished here... OK 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
