Re: [PATCH v4 0/6] Generic PHY Framework
Hi, On Friday 29 March 2013 12:01 AM, David Miller wrote: You really need to CC: net...@vger.kernel.org rather than me explicitly on this patch set. I was CC'ing whatever get_maintainer shows. I'll make sure to CC net...@vger.kernel.org though there's nothing related to network in this patch series (Maybe sometime in the future it'll be used). Thanks Kishon -- 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 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
Hi Felipe, On Tue, Apr 2, 2013 at 1:59 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Apr 01, 2013 at 07:24:01PM +0530, Vivek Gautam wrote: The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, wrong comment style. Yea :-( will fix this. + * to make sure we know device state prior to + * pm_runtime_enable + */ + pm_runtime_set_suspended(dev); didn't Alan mention this should be done at the Bus level ? In that case, shouldn't you have call pm_runtime_set_active/suspended() based on DT's status=okay or status=disabled ? Or something similar ? True, we should be doing this at bus level. But he did also mention to let pm core know of the state of the device before enabling the runtime pm. Right ? Moreover immediately after pm_runtime_enable(), we do pm_runtime_get_sync() so that device comes to active state. I am possibly missing things out here, not able to grab this whole picture completely :-( Wouldn't DT's status=disabled actually be disabling the device as a whole ? So, how much will runtime power management on the device be affecting ? -- Thanks Regards Vivek -- 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 01/11] usb: phy: Add APIs for runtime power management
Hi Kishon,
On Wed, Apr 3, 2013 at 10:38 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi,
On Monday 01 April 2013 07:24 PM, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
--
Thanks Regards
Vivek
--
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 0/6] Generic PHY Framework
From: Kishon Vijay Abraham I kis...@ti.com Date: Wed, 3 Apr 2013 11:29:53 +0530 Hi, On Friday 29 March 2013 12:01 AM, David Miller wrote: You really need to CC: net...@vger.kernel.org rather than me explicitly on this patch set. I was CC'ing whatever get_maintainer shows. I'll make sure to CC net...@vger.kernel.org though there's nothing related to network in this patch series (Maybe sometime in the future it'll be used). What about drivers/net/phy isn't networking? -- 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 0/6] Generic PHY Framework
Hi, On Wednesday 03 April 2013 12:01 PM, David Miller wrote: From: Kishon Vijay Abraham I kis...@ti.com Date: Wed, 3 Apr 2013 11:29:53 +0530 Hi, On Friday 29 March 2013 12:01 AM, David Miller wrote: You really need to CC: net...@vger.kernel.org rather than me explicitly on this patch set. I was CC'ing whatever get_maintainer shows. I'll make sure to CC net...@vger.kernel.org though there's nothing related to network in this patch series (Maybe sometime in the future it'll be used). What about drivers/net/phy isn't networking? This patch series is about drivers/phy which will be used for now by usb, sata and maybe some video PHY's. Network itself has a comprehensive PHY in drivers/net/phy which we'd like to merge it with drivers/phy so that we have all the phy stuff in drivers/phy but we are not planning too far ahead here. Thanks Kishon -- 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 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 11:48:39AM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
Hi, On Wed, Apr 03, 2013 at 11:35:43AM +0530, Vivek Gautam wrote: The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, wrong comment style. Yea :-( will fix this. + * to make sure we know device state prior to + * pm_runtime_enable + */ + pm_runtime_set_suspended(dev); didn't Alan mention this should be done at the Bus level ? In that case, shouldn't you have call pm_runtime_set_active/suspended() based on DT's status=okay or status=disabled ? Or something similar ? True, we should be doing this at bus level. But he did also mention to let pm core know of the state of the device before enabling the runtime pm. Right ? Moreover immediately after pm_runtime_enable(), we do pm_runtime_get_sync() so that device comes to active state. I am possibly missing things out here, not able to grab this whole picture completely :-( Wouldn't DT's status=disabled actually be disabling the device as a whole ? So, how much will runtime power management on the device be affecting ? indeed, maybe we can keep it like this, but it would be nice to have OF core handle this for us based on whatever data. -- balbi signature.asc Description: Digital signature
Re: [PATCH 00/28] OMAP: DSS related board file changes
Hi, On 2013-03-28 14:48, Tomi Valkeinen wrote: So here are the DSS related board file changes for 3.10. First there are a bunch of patches adding the Kconfig options so that only one display device is created for a single video bus. Only Overo had more than two displays on the same bus, but unfortunately there were multiple boards with a setup that puts an LCD and DVI output on the same video bus. So the ifdeffery is not very nice. But, as discussed, this is the best way forward, and should be seen as a temporary solution until we get full DT support. Then the rest are converting the old omap_dss_device style displays to platform devices. Only TFP410, generic-dpi-panel, HDMI and Taal drivers have been converted yet, but those seem to form the bulk of the display options used. This series can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/1-arch-dss These patches depend on a few dss header file changes. These header file changes can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers If this series is applied without the relevant omapdss changes, everything compiles and the boards boot, but the converted displays do not work. The same happens if only the omapdss changes are applied, but not this series. The related omapdss changes can be found from: git://gitorious.org/linux-omap-dss2/linux.git 3.10/3-dss-dev-model I'll drop these patches and the branches mentioned above, as I don't have a solution to the multiple-displays-per-output problem. I'll continue looking at this, but it surely won't make into the next merge window. Tomi signature.asc Description: OpenPGP digital signature
[RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
Instead of removing the tasklet we can identify the DMA channel used by audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel shift
issue and later when we have the dynamic DMA channel allocation we can adjust
the code.
Regards,
Peter
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc) !c-desc) {
- struct omap_dmadev *d = to_omap_dma_dev(chan-device);
- spin_lock(d-lock);
- if (list_empty(c-node))
- list_add_tail(c-node, d-pending);
- spin_unlock(d-lock);
- tasklet_schedule(d-task);
+ /*
+* c-cyclic is used only by audio and in this case the DMA need
+* to be started without delay.
+*/
+ if (!c-cyclic) {
+ struct omap_dmadev *d = to_omap_dma_dev(chan-device);
+ spin_lock(d-lock);
+ if (list_empty(c-node))
+ list_add_tail(c-node, d-pending);
+ spin_unlock(d-lock);
+ tasklet_schedule(d-task);
+ } else {
+ omap_dma_start_desc(c);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
--
1.8.1.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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels
On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
Instead of removing the tasklet we can identify the DMA channel used by audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel
shift
issue and later when we have the dynamic DMA channel allocation we can adjust
the code.
Regards,
Peter
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan
*chan)
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc) !c-desc) {
If you add !c-cyclic in above if then you can avoid
indentation change and just have else for cyclic case.
- struct omap_dmadev *d = to_omap_dma_dev(chan-device);
- spin_lock(d-lock);
- if (list_empty(c-node))
- list_add_tail(c-node, d-pending);
- spin_unlock(d-lock);
- tasklet_schedule(d-task);
+ /*
+ * c-cyclic is used only by audio and in this case the DMA need
+ * to be started without delay.
+ */
+ if (!c-cyclic) {
+ struct omap_dmadev *d = to_omap_dma_dev(chan-device);
+ spin_lock(d-lock);
+ if (list_empty(c-node))
+ list_add_tail(c-node, d-pending);
+ spin_unlock(d-lock);
+ tasklet_schedule(d-task);
+ } else {
+ omap_dma_start_desc(c);
+ }
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
--
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 v9 0/9] DMA Engine support for AM33XX
Hi Matt, On 3/6/2013 9:45 PM, Matt Porter wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. Matt Porter (9): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers If you are going to be late in re-spinning the entire series in time for v3.10, then I suggest I queue the first two patches through davinci tree for v3.10 and then you can work on rest of patches for next (v3.11) merge window. Let me know what you think. ARM: edma: add AM33XX support to the private EDMA API dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI DMA support Thanks, Sekhar -- 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: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Vaibhav, On Mon, Dec 31, 2012 at 2:07 PM, Vaibhav Bedia vaibhav.be...@ti.com wrote: AM335x supports various low power modes as documented in section 8.1.4.3 of the AM335x TRM which is available @ http://www.ti.com/litv/pdf/spruh73f May I ask about the plans for this series? Will you be re-spinning them for a current tree, and what's the planned merge window for it? Many thanks, Daniel DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as the suspend state in the kernel. In this state, MPU and PER domains are turned off with the internal RAM held in retention to facilitate resume process. As part of the boot process, the assembly code is copied over to OCMCRAM using the OMAP SRAM code. AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU in DeepSleep0 entry and exit. WKUP_M3 takes care of the clockdomain and powerdomain transitions based on the intended low power state. MPU needs to load the appropriate WKUP_M3 binary onto the WKUP_M3 memory space before it can leverage any of the PM features like DeepSleep. The IPC mechanism between MPU and WKUP_M3 uses a mailbox sub-module and 8 IPC registers in the Control module. MPU uses the assigned Mailbox for issuing an interrupt to WKUP_M3 which then goes and checks the IPC registers for the payload. WKUP_M3 has the ability to trigger on interrupt to MPU by executing the sev instruction. In the current implementation when the suspend process is initiated MPU interrupts the WKUP_M3 to let it know about the intent of entering DeepSleep0 and waits for an ACK. When the ACK is received MPU continues with its suspend process to suspend all the drivers and then jumps to assembly in OCMC RAM. The assembly code puts the PLLs in bypass, puts the external RAM in self-refresh mode and then finally execute the WFI instruction. Execution of the WFI instruction triggers another interrupt to the WKUP_M3 which then continues wiht the power down sequence wherein the clockdomain and powerdomain transition takes place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI execution on WKUP_M3 causes the hardware to disable the main oscillator of the SoC. When a wakeup event occurs, WKUP_M3 starts the power-up sequence by switching on the power domains and finally enabling the clock to MPU. Since the MPU gets powered down as part of the sleep sequence in the resume path ROM code starts executing. The ROM code detects a wakeup from sleep and then jumps to the resume location in OCMC which was populated in one of the IPC registers as part of the suspend sequence. The low level code in OCMC relocks the PLLs, enables access to external RAM and then jumps to the cpu_resume code of the kernel to finish the resume process. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- v1-v2: Move assembly code addition, control module access and hookup in OMAP PM framework in separate patches. Address other comments from Kevin Hilman and Santosh Shilimkar on v1. The discussion on v1 is present @ http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129979.html Note: The mailbox change will need slight rework once the driver is finalized. arch/arm/mach-omap2/pm33xx.c | 469 ++ arch/arm/mach-omap2/pm33xx.h | 56 + 2 files changed, 525 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/pm33xx.c create mode 100644 arch/arm/mach-omap2/pm33xx.h diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c new file mode 100644 index 000..aaa4daa --- /dev/null +++ b/arch/arm/mach-omap2/pm33xx.c @@ -0,0 +1,469 @@ +/* + * AM33XX Power Management Routines + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * Vaibhav Bedia vaibhav.be...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/err.h +#include linux/firmware.h +#include linux/io.h +#include linux/platform_device.h +#include linux/sched.h +#include linux/suspend.h +#include linux/completion.h +#include linux/module.h +#include linux/mailbox.h +#include linux/interrupt.h + +#include
Re: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels
On 04/03/2013 01:24 PM, Santosh Shilimkar wrote:
On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
Instead of removing the tasklet we can identify the DMA channel used by audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel
shift
issue and later when we have the dynamic DMA channel allocation we can adjust
the code.
Regards,
Peter
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan
*chan)
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc) !c-desc) {
If you add !c-cyclic in above if then you can avoid
indentation change and just have else for cyclic case.
It can not be embedded there because of the existing tests. How would we
handle the case when c-desc is _not_ NULL and c-cyclic is false? We would
need to test again in else, but we can not do this for the
vchan_issue_pending(c-vc).
-struct omap_dmadev *d = to_omap_dma_dev(chan-device);
-spin_lock(d-lock);
-if (list_empty(c-node))
-list_add_tail(c-node, d-pending);
-spin_unlock(d-lock);
-tasklet_schedule(d-task);
+/*
+ * c-cyclic is used only by audio and in this case the DMA need
+ * to be started without delay.
+ */
+if (!c-cyclic) {
+struct omap_dmadev *d = to_omap_dma_dev(chan-device);
+spin_lock(d-lock);
+if (list_empty(c-node))
+list_add_tail(c-node, d-pending);
+spin_unlock(d-lock);
+tasklet_schedule(d-task);
+} else {
+omap_dma_start_desc(c);
+}
}
spin_unlock_irqrestore(c-vc.lock, flags);
}
--
Péter
--
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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels
On Wednesday 03 April 2013 05:22 PM, Peter Ujfalusi wrote:
On 04/03/2013 01:24 PM, Santosh Shilimkar wrote:
On Wednesday 03 April 2013 04:47 PM, Peter Ujfalusi wrote:
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald pme...@pmeerw.net
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
Instead of removing the tasklet we can identify the DMA channel used by
audio
based on the cyclic flag of the channel.
I think this can be used as a short term solution to fix the audio channel
shift
issue and later when we have the dynamic DMA channel allocation we can
adjust
the code.
Regards,
Peter
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan
*chan)
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc) !c-desc) {
If you add !c-cyclic in above if then you can avoid
indentation change and just have else for cyclic case.
It can not be embedded there because of the existing tests. How would we
handle the case when c-desc is _not_ NULL and c-cyclic is false? We would
need to test again in else, but we can not do this for the
vchan_issue_pending(c-vc).
right. Thanks for clarifying it.
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
[PATCH v3] ARM: omap2: twl-common: Add default power configuration
From: Matthias Brugger matthias@gmail.com
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger matthias@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Tony, Matthias,
Changes since v2:
- remove the __initdata from all the structures introduced by this patch
Regards,
Peter
arch/arm/mach-omap2/twl-common.c | 38 ++
arch/arm/mach-omap2/twl-common.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 51e138c..7551bbc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = omap3_codec,
};
+static struct twl4030_ins wrst_seq[] __initdata = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] __initdata = {
+ wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] __initdata = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata __initdata = {
+ .scripts= omap3_power_scripts,
+ .num= ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
+};
+
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
};
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
pmic_data-audio = omap3_audio_pdata;
+ if (pdata_flags TWL_COMMON_PDATA_POWER !pmic_data-power)
+ pmic_data-power = omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
pmic_data-vdac = omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC (1 2)
#define TWL_COMMON_PDATA_AUDIO (1 3)
+#define TWL_COMMON_PDATA_POWER (1 4)
/* Common LDO regulators for TWL4030/TWL6030 */
#define TWL_COMMON_REGULATOR_VDAC (1 0)
--
1.8.1.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 0/5] usb: musb: am335x support
On 19.03.2013 14:27, Peter Korsgaard wrote: Daniel == Daniel Mack zon...@gmail.com writes: Hi, I know this patch reintroduces bits that have been intentionally removed before, in particular by 032ec49f53 (usb: musb: drop useless board_mode usage), but I don't know how this usb driver is supposed to work in host mode without taking the configured port mode into account. If anyone can explain to me which information I'm missing here, I can happily test a patch. For now, this works for me. Daniel Hmm, nobody, really? Am I the only one who's running the musb Daniel driver in host-only mode? Sorry, I'll be needing host mode as well, but am currently stuck working on non-am335x stuff - So I'm definately interested in getting it to work, but don't have free cycles to look into it right now. Another two weeks passed with no answer at all, which makes me wonder whether the changes were made considering the setup at all that at least Peter, Koen and me are using. Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
On 2013-02-14 15:51, Igor Grinberg wrote:
On 02/14/13 14:52, Tomi Valkeinen wrote:
On 2013-02-14 14:37, Igor Grinberg wrote:
On 02/14/13 12:59, Tomi Valkeinen wrote:
On 2013-02-14 11:43, Igor Grinberg wrote:
True, it's generic, but does it work reliably? The panel hardware is now
partly handled in the backlight driver, and partly in the omap's panel
driver (and wherever on other platforms).
It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...
How do you handle the gpios on other platform? Those are the ones
causing the issues here, right?
Well, I'm also talking about something that is a history already.
Remember, we had multiple panel drivers inside the
video/omap2/displays and then they were consolidated into the
generic dpi/dsi/whatever.
Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
task for you with simple panels? It could've been taken even further,
though (see below).
Yes it was a good thing (I have already told this below).
And yes you are right, on the platforms I'm aware of, the GPIO is not
handled. Apparently its hardware default (pull resistor) is always on...
Ok, so the simple fix of setting the GPIOs only in the board file is
acceptable for now.
Yep. I also told this already in one of the previous emails.
Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
backlight will supposedly be always on. Is it just a simple switch for
the BL power, which does not affect the SPI in any way?
Yes, it can for now.
Also, I think we should also take into account the backlight framework,
including PMW.
I've updated this patch to set the LCD EN gpio once at boot time, and pass the
LCD BL gpio to the panel driver. Updated patch below.
---
commit a58a72363aa4359cdb75878de1517bd50faf9eb4
Author: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon Dec 3 16:05:06 2012 +0530
arm: omap: board-cm-t35: use generic dpi panel's gpio handling
The cm-t35 board file currently requests gpios required to configure the
tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and
shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: Only BL enable gpio is handled in the panel driver. The LCD enable
GPIO is handled in the board file at init time, as there's a 50 ms delay
required when using the GPIO, and the panel driver doesn't know about
that.
Cc: Tony Lindgren t...@atomide.com
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index bccd3e5..cccbfea 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device
*dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = toppoly_tdo35s,
- .platform_enable= cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 1,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[]
__initdata = {
},
};
-static struct gpio cm_t35_dss_gpios[] __initdata = {
- { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, lcd enable},
- { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, lcd bl enable },
-};
-
static void __init cm_t35_init_display(void)
{
int err;
@@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err =
Re: [PATCH 0/5] usb: musb: am335x support
Hi, (sorry, being really busy lately) On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: I know this patch reintroduces bits that have been intentionally removed before, in particular by 032ec49f53 (usb: musb: drop useless board_mode usage), but I don't know how this usb driver is supposed to work in host mode without taking the configured port mode into account. If anyone can explain to me which information I'm missing here, I can happily test a patch. For now, this works for me. Daniel Hmm, nobody, really? Am I the only one who's running the musb Daniel driver in host-only mode? Sorry, I'll be needing host mode as well, but am currently stuck working on non-am335x stuff - So I'm definately interested in getting it to work, but don't have free cycles to look into it right now. Another two weeks passed with no answer at all, which makes me wonder whether the changes were made considering the setup at all that at least Peter, Koen and me are using. Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. DWC3 and Chipidea are doing it very nicely. patches are highly welcome. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: musb: am335x support
Hi Felipe, On 03.04.2013 14:04, Felipe Balbi wrote: (sorry, being really busy lately) On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: I know this patch reintroduces bits that have been intentionally removed before, in particular by 032ec49f53 (usb: musb: drop useless board_mode usage), but I don't know how this usb driver is supposed to work in host mode without taking the configured port mode into account. If anyone can explain to me which information I'm missing here, I can happily test a patch. For now, this works for me. Daniel Hmm, nobody, really? Am I the only one who's running the musb Daniel driver in host-only mode? Sorry, I'll be needing host mode as well, but am currently stuck working on non-am335x stuff - So I'm definately interested in getting it to work, but don't have free cycles to look into it right now. Another two weeks passed with no answer at all, which makes me wonder whether the changes were made considering the setup at all that at least Peter, Koen and me are using. Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. DWC3 and Chipidea are doing it very nicely. Thanks a lot for your answer! I'll look into that and send some patches then. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: omap2: twl-common: Add default power configuration
Whata...
On 04/03/2013 01:59 PM, Peter Ujfalusi wrote:
From: Matthias Brugger matthias@gmail.com
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger matthias@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Tony, Matthias,
Changes since v2:
- remove the __initdata from all the structures introduced by this patch
Regards,
Peter
arch/arm/mach-omap2/twl-common.c | 38 ++
arch/arm/mach-omap2/twl-common.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 51e138c..7551bbc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = omap3_codec,
};
+static struct twl4030_ins wrst_seq[] __initdata = {
The __initdata remained :o
Will resend it.
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] __initdata = {
+ wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] __initdata = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata __initdata = {
+ .scripts= omap3_power_scripts,
+ .num= ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
+};
+
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
};
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
pmic_data-audio = omap3_audio_pdata;
+ if (pdata_flags TWL_COMMON_PDATA_POWER !pmic_data-power)
+ pmic_data-power = omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
pmic_data-vdac = omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h
b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC(1 2)
#define TWL_COMMON_PDATA_AUDIO (1 3)
+#define TWL_COMMON_PDATA_POWER (1 4)
/* Common LDO regulators for TWL4030/TWL6030 */
#define TWL_COMMON_REGULATOR_VDAC(1 0)
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
Hi Tony, On 2013-02-13 18:46, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [130213 06:26]: init functions in omap board files request panel specific gpios, and provide functions which omapdss panel drivers call to enable or disable them. Instead of the board files requesting these gpios, they should just pass the platform specific data(like the gpio numbers), the panel should retrieve the platform data and request the gpios. Doing this prevents the need of the panel driver calling platform functions in board files. Panel drivers have their own platform data struct, and the board files populate these structs and pass the pointer to the 'data' field of omap_dss_device. This work will make it easier for the panel drivers be more adaptable to the DT model. There is also removal of passing panel reset_gpio numbers through omap_dss_device struct directly, reset gpios are passed through platform data only. To avoid merge conflicts and dependencies between drivers and core Soc code, please break thes kind of patches into following parts: 1. Any platform_data header changes needed so both I and Tomi can pull it in as needed. 2. Changes to DSS drivers. Please keep stubs around for the board specific callback functions so omap2plus_defconfig won't break with just #1 merged into arm soc tree. 3. All the arch/arm/*omap* changes based on #1 above to drop obsolete callback functions and add new pdata if still needed. This needs to build and boot on #1 so I can merge this in via arm soc tree. 4. Any .dts changes needed. Tony, I've split these patches as follows: Platform data header file changes: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers Board file changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup DSS panel changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup Removing unused fields from header files (based on panel changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup The 2-late-panel-cleanup breaks compilation if the arch changes are not merged, so I'll leave that until they have been merged. Do you mind if I add the board-cleanup branch temporarily to omapdss's for-next, to simplify testing? When everything looks ok, I'll remove it and pass the branch to you to be handled through l-o. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v4] ARM: omap2: twl-common: Add default power configuration
From: Matthias Brugger matthias@gmail.com
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger matthias@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Tony, Matthias,
Changes since v3:
- remove the __initdata from all the structures introduced by this patch
If it is OK, I'll send a pull with this patch.
Regards,
Peter
arch/arm/mach-omap2/twl-common.c | 38 ++
arch/arm/mach-omap2/twl-common.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 51e138c..a85531e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = omap3_codec,
};
+static struct twl4030_ins wrst_seq[] = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] = {
+ wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata = {
+ .scripts= omap3_power_scripts,
+ .num= ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
+};
+
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
};
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
pmic_data-audio = omap3_audio_pdata;
+ if (pdata_flags TWL_COMMON_PDATA_POWER !pmic_data-power)
+ pmic_data-power = omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
pmic_data-vdac = omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC (1 2)
#define TWL_COMMON_PDATA_AUDIO (1 3)
+#define TWL_COMMON_PDATA_POWER (1 4)
/* Common LDO regulators for TWL4030/TWL6030 */
#define TWL_COMMON_REGULATOR_VDAC (1 0)
--
1.8.1.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 0/5] usb: musb: am335x support
On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that people might want to run a single kernel image on multiple platforms? I believe it should be up to the DT to define the actual hardware wiring. Daniel -- 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 v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/omap-usb2.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..4e48db4 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/phy/phy.h
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy *x)
+{
+ struct omap_usb *phy = dev_get_drvdata(x-dev);
+
+ if (!phy-is_suspended) {
+ omap_control_usb_phy_power(phy-control_dev, 0);
+ pm_runtime_put_sync(phy-dev);
+ phy-is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+ u32 ret;
+ struct omap_usb *phy = dev_get_drvdata(x-dev);
+
+ if (phy-is_suspended) {
+ ret = pm_runtime_get_sync(phy-dev);
+ if (ret 0) {
+ dev_err(phy-dev, get_sync failed with err %d\n,
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy-control_dev, 1);
+ phy-is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= omap_usb_suspend,
+ .resume = omap_usb_resume,
+ .of_xlate = of_phy_xlate,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +185,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
+ generic_phy = devm_phy_create(phy-dev, omap-usb2, pdev-dev.of_node,
+ USB_PHY_TYPE_USB2, ops, phy);
+ if (IS_ERR(generic_phy)) {
+ dev_dbg(pdev-dev, Failed to create PHY\n);
+ return PTR_ERR(generic_phy);
+ }
+
phy-control_dev = omap_get_control_dev();
if (IS_ERR(phy-control_dev)) {
dev_dbg(pdev-dev, Failed to get control device\n);
--
1.7.10.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 v5 1/6] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
power_on, power_off.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/ABI/testing/sysfs-class-phy | 15 +
.../devicetree/bindings/phy/phy-bindings.txt | 67 +++
Documentation/phy.txt | 113
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 616
include/linux/phy/phy.h| 228
10 files changed, 1068 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-phy
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/ABI/testing/sysfs-class-phy
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..b735467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What: /sys/class/phy/phy/label
+Date: Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for getting the label of the phy.
+
+What: /sys/class/phy/phy/phy_bind
+Date: Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for reading the phy binding
+ information. It contains the device name of the controller,
+ the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..e7b246a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg = ...;
+.
+.
+#phy-cells = 1;
+.
+.
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = usb2_phy, usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..7785ec0
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,113 @@
+ PHY SUBSYSTEM
+ Kishon Vijay Abraham I kis...@ti.com
+
[PATCH v5 0/6] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linus tree HEAD. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. Changes from v4: * removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers* should use their custom implementation of of_xlate or use of_phy_xlate to get *phy instance* from *phy providers*. * Added of_phy_xlate to be used by *phy providers* if it provides only one PHY. * changed phy_core from having subsys_initcall to module_init. * other minor fixes. Changes from v3: * Changed the return value of PHY APIs to ENOSYS * Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting PHYs if the same IP implements multiple PHYs. * modified phy_bind API so that the binding information can now be _updated_. In effect of this removed the binding information added in board files and added only in usb-musb.c. If a particular board uses a different phy binding, it can update it in board file after usb_musb_init(). * Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding information. Changes from v2: * removed phy_descriptor structure completely so changed the APIs which were taking phy_descriptor as parameters * Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used by PHY user drivers which has *phy* and *phy-names* binding in the dt data * Fixed a few typos * Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and class_dev_iter_exit for traversing through the phy list. (Note we still need phy_bind list and phy_bind_mutex). * Changed the sysfs entry name from *bind* to *phy_bind*. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (6): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information ARM: dts: omap: update usb_otg_hs data usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy | 15 + .../devicetree/bindings/phy/phy-bindings.txt | 67 +++ Documentation/devicetree/bindings/usb/omap-usb.txt |5 + Documentation/devicetree/bindings/usb/usb-phy.txt |6 + Documentation/phy.txt | 113 MAINTAINERS|7 + arch/arm/boot/dts/omap3.dtsi |2 + arch/arm/boot/dts/omap4.dtsi |3 + arch/arm/boot/dts/twl4030.dtsi |1 + arch/arm/mach-omap2/usb-musb.c |7 +- drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 616 drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c| 22 +- drivers/usb/otg/twl4030-usb.c | 37 ++ drivers/usb/phy/omap-usb2.c| 48 ++ include/linux/phy/phy.h| 228 20 files changed, 1194 insertions(+), 7 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 1.7.10.4 -- To unsubscribe from this
[PATCH v5 4/6] ARM: OMAP: USB: Add phy binding information
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..f01bc42 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
#include linux/dma-mapping.h
#include linux/io.h
#include linux/usb/musb.h
+#include linux/phy/phy.h
#include omap_device.h
#include soc.h
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ phy_bind(musb-hdrc.0.auto, 0, omap-usb2.1.auto);
+ } else if (cpu_is_omap34xx()) {
+ phy_bind(musb-hdrc.0.auto, 0, twl4030_usb);
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
--
1.7.10.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 v5 6/6] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb-xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/otg.h
#include linux/usb/musb.h
+#include linux/phy/phy.h
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev-parent-of_node)
+ if (dev-parent-of_node) {
+ musb-phy = devm_of_phy_get_byname(dev-parent, usb2-phy);
+
+ /* We can't totally remove musb-xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
- else
+ } else {
musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-phy = devm_phy_get(dev, 0);
+ }
- if (IS_ERR_OR_NULL(musb-xceiv)) {
- pr_err(HS USB OTG: no transceiver configured\n);
+ if (IS_ERR_OR_NULL(musb-xceiv) || IS_ERR(musb-phy)) {
+ dev_err(dev, no transceiver configured\n);
return -EPROBE_DEFER;
}
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb-xceiv, 1);
+ phy_suspend(musb-phy);
}
return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
- usb_phy_set_suspend(musb-xceiv, 0);
+ phy_resume(musb-phy);
}
return 0;
--
1.7.10.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 v5 3/6] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..6dab049 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/usb/otg.h
+#include linux/phy/phy.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -575,10 +576,39 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl4030_usb_suspend(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(phy-dev);
+
+ twl4030_phy_suspend(twl, 1);
+
+ return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(phy-dev);
+
+ if (!twl-asleep)
+ return -EBUSY;
+ __twl4030_phy_resume(twl);
+ twl-asleep = 0;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
+ .of_xlate = of_phy_xlate,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = pdev-dev.platform_data;
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev-dev.of_node;
@@ -617,6 +647,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg-set_host = twl4030_set_host;
otg-set_peripheral = twl4030_set_peripheral;
+ phy = devm_phy_create(twl-dev, twl4030, pdev-dev.of_node,
+ USB_PHY_TYPE_USB2, ops, twl);
+ if (IS_ERR(phy)) {
+ dev_dbg(pdev-dev, Failed to create PHY\n);
+ return PTR_ERR(phy);
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
--
1.7.10.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 v5 5/6] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
Documentation/devicetree/bindings/usb/usb-phy.txt |6 ++
arch/arm/boot/dts/omap3.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/twl4030.dtsi |1 +
5 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..9324e79 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num_eps = 16;
ram_bits = 12;
ctrl-module = omap_control_usb;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
};
Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
- reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1e21565..dd7d2ff 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -405,6 +405,8 @@
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 06d044e..64cd000 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -442,6 +442,7 @@
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
};
@@ -550,6 +551,8 @@
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 398d2c3..6f71de7 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -74,5 +74,6 @@
usb1v8-supply = vusb1v8;
usb3v1-supply = vusb3v1;
usb_mode = 1;
+ #phy-cells = 0;
};
};
--
1.7.10.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
Re: [PATCH 0/5] usb: musb: am335x support
Hi, On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). people might want to run a single kernel image on multiple platforms? I believe it should be up to the DT to define the actual hardware wiring. Right, for runtime decision Ravi pointed me to a patch implementing that (Ravi, could you post it by any chance as RFC ?) which we could start a discussion and hopefully merge for v3.11 -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: musb: am335x support
Op 3 apr. 2013, om 15:09 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that?-- 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 01/11] usb: phy: Add APIs for runtime power management
Hi Felipe,
On Wed, Apr 3, 2013 at 1:45 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 11:48:39AM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
--
balbi
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] usb: musb: am335x support
On 03.04.2013 15:12, Koen Kooi wrote: Op 3 apr. 2013, om 15:09 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that? You would enable DUAL_ROLE and then let run-time code sort out the actual config. Which is what most people would do if they are uncertain, and which leaves the Kconfig option only for opting out some binary size. Also, we already have CONFIG_USB_GADGET_MUSB_HDRC which is there to remove all the gadget-only bits, right? Daniel -- 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 1/6] drivers: phy: add generic PHY framework
On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend,
resume,
power_on, power_off.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/ABI/testing/sysfs-class-phy | 15 +
.../devicetree/bindings/phy/phy-bindings.txt | 67 +++
Documentation/phy.txt | 113
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 616
include/linux/phy/phy.h| 228
10 files changed, 1068 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-phy
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/ABI/testing/sysfs-class-phy
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..b735467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What:/sys/class/phy/phy/label
+Date:Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for getting the label of the phy.
+
+What:/sys/class/phy/phy/phy_bind
+Date:Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for reading the phy binding
+ information. It contains the device name of the controller,
+ the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..e7b246a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information
about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells: Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg = ...;
+.
+.
+#phy-cells = 1;
+.
+.
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = usb2_phy, usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the two PHYs.
diff --git a/Documentation/phy.txt
Re: [PATCH 0/5] usb: musb: am335x support
Hi, On Wed, Apr 03, 2013 at 03:12:11PM +0200, Koen Kooi wrote: On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that? you can't be asking this... are you serious ? For beaglebone it won't help in anything, but beaglebone is nothing but *ONE* user of am335x. You need to consider a product, what if someone decides to build a product with am335x but uses either a single port in host-only mode (or peripheral-only) or, both ports in same mode ? Will that not help ? Spend 5 minutes thinking harder before sending this attack emails. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: musb: am335x support
Hi, On Wed, Apr 03, 2013 at 03:16:05PM +0200, Daniel Mack wrote: On 03.04.2013 15:12, Koen Kooi wrote: Op 3 apr. 2013, om 15:09 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote: On 03.04.2013 14:04, Felipe Balbi wrote: On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote: Felipe, could you explain the background on how the dsps driver is supposed to work in host mode at boot time with the rework of the driver you did for 3.7? It might just be me not understanding the rationale behind all these changes, but appearantly, I'm not the only one who's affected by that. right, so the idea with that was to drop the huge amount of ifdeferry hack from the MUSB driver. It would be great if someone would send *CLEAN* patches adding Kconfig-based role choices again. Are Kconfig-based rules really what we want here after all? Wouldn't run-time configured settings make much more sense, considering that we need both. Say that you want to build a product with MUSB hardwired as host, why would you enable gadget framework ? I can think of at least am335x where this would be perfectly plausible (no EHCI available, only MUSB). Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that? You would enable DUAL_ROLE and then let run-time code sort out the actual config. Which is what most people would do if they are uncertain, and which leaves the Kconfig option only for opting out some binary size. Also, we already have CONFIG_USB_GADGET_MUSB_HDRC which is there to remove all the gadget-only bits, right? kinda, it's there but it's unused :-) But you got the idea. We use Kconfig to opt-out of some features if we're certain our product won' use it. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
On Wed, Apr 03, 2013 at 06:23:50PM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/omap-usb2.c | 48
+++
1 file changed, 48 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..4e48db4 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/phy/phy.h
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy *x)
+{
+ struct omap_usb *phy = dev_get_drvdata(x-dev);
+
+ if (!phy-is_suspended) {
+ omap_control_usb_phy_power(phy-control_dev, 0);
+ pm_runtime_put_sync(phy-dev);
+ phy-is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+ u32 ret;
+ struct omap_usb *phy = dev_get_drvdata(x-dev);
+
+ if (phy-is_suspended) {
+ ret = pm_runtime_get_sync(phy-dev);
+ if (ret 0) {
+ dev_err(phy-dev, get_sync failed with err %d\n,
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy-control_dev, 1);
+ phy-is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
const ? Maybe provide a:
#define DEFINE_PHY_OPS(name)\
const struct phy_ops #name_phy_ops = {
macro ? This will force people to add the const keyword :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
HI,
On Wed, Apr 03, 2013 at 06:42:48PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141
+++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver than
having an API for it to be done by *phy user* driver. Felipe, what do
you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made
by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 3, 2013 at 7:26 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe
and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what do
you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are made
by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm on
PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
--
Thanks Regards
Vivek
--
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 01/11] usb: phy: Add APIs for runtime power management
Hi,
On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in probe
and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what
do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are
made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm
on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the
PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active
state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that
case,
only one of the consumer can enable runtime_pm on PHY. So who decides
this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if
any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi,
On Wednesday 03 April 2013 07:12 PM, Felipe Balbi wrote:
On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
power_on, power_off.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/ABI/testing/sysfs-class-phy | 15 +
.../devicetree/bindings/phy/phy-bindings.txt | 67 +++
Documentation/phy.txt | 113
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 616
include/linux/phy/phy.h| 228
10 files changed, 1068 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-phy
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/ABI/testing/sysfs-class-phy
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..b735467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What: /sys/class/phy/phy/label
+Date: Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for getting the label of the phy.
+
+What: /sys/class/phy/phy/phy_bind
+Date: Apr 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I kis...@ti.com
+Description:
+ This is a read-only file for reading the phy binding
+ information. It contains the device name of the controller,
+ the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..e7b246a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg = ...;
+.
+.
+#phy-cells = 1;
+.
+.
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = usb2_phy, usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..7785ec0
---
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
hi,
On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:
+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
+{
+ return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_xlate);
so you get a PHY and just return it ? What gives ?? (maybe I skipped
some of the discussion...)
hmm.. this is for the common case where the PHY provider implements
only one PHY. And both phy provider and phy_instance is represented
by struct phy *.
For the case where PHY provider implements multiple PHYs (here it
will have a single dt node), the PHY provider will implement it's own
version of of_xlate that takes *of_phandle_args* as argument and
finds the appropriate PHY.
got it.
+struct phy *of_phy_get(struct device *dev, int index)
+{
+ int ret;
+ struct phy *phy = NULL;
+ struct phy_bind *phy_map = NULL;
+ struct of_phandle_args args;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
+ index, args);
+ if (ret) {
+ dev_dbg(dev, failed to get phy in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ phy = of_phy_lookup(args.np);
+ if (IS_ERR(phy) || !try_module_get(phy-ops-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ goto err0;
+ }
+
+ phy = phy-ops-of_xlate(phy, args);
alright, so of_xlate() is optional, am I right ? How about not
Not really. of_xlate is mandatory (it's even checked in phy_create).
Either the PHY provider can implement it's own version or use the
implementation above (by filling the function pointer).
alright.
implementing the above and have a check for of_xlate() being a valid
pointer here ?
Having the way it is actually mandates the PHY providers to always
provide of_xlate which IMO is better since some PHY providers wont
accidentally be using the default implementation.
ok cool, thanks for clarifying.
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ if (!phy_class)
+ phy_core_init();
why don't you setup the class on module_init ? Then this would be a
terrible error condition here :-)
This is for the case where the PHY driver gets loaded before the PHY
framework. I could have returned EPROBE_DEFER here instead I thought
will have it this way.
looks a bit weird IMO. Is it really possible for PHY to load before ?
Since PHY driver uses symbols from phy-core, modprobe will make sure to
load drivers based on symbol dependency, right ?
+static struct device_attribute phy_dev_attrs[] = {
+ __ATTR(label, 0444, phy_name_show, NULL),
+ __ATTR(phy_bind, 0444, phy_bind_show, NULL),
you could expose a human-readable 'type' string. BTW, how are you using
type ? USB2/USB3/etc ? Have you considered our OMAP5 SerDes pair which
Actually not using *type* anywhere. Just used as an additional info
about the PHY. It's actually not even enum. Maybe I can remove it
completely.
makes sense.
are currently for USB3 and SATA (and could just as easily be used for
PCIe)
Yeah. Me and Balaji were planning to work on it for having a single
driver to be used for all the above.
cool :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi,
On Wednesday 03 April 2013 07:57 PM, Felipe Balbi wrote:
hi,
On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:
+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
+{
+ return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_xlate);
so you get a PHY and just return it ? What gives ?? (maybe I skipped
some of the discussion...)
hmm.. this is for the common case where the PHY provider implements
only one PHY. And both phy provider and phy_instance is represented
by struct phy *.
For the case where PHY provider implements multiple PHYs (here it
will have a single dt node), the PHY provider will implement it's own
version of of_xlate that takes *of_phandle_args* as argument and
finds the appropriate PHY.
got it.
+struct phy *of_phy_get(struct device *dev, int index)
+{
+ int ret;
+ struct phy *phy = NULL;
+ struct phy_bind *phy_map = NULL;
+ struct of_phandle_args args;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
+ index, args);
+ if (ret) {
+ dev_dbg(dev, failed to get phy in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ phy = of_phy_lookup(args.np);
+ if (IS_ERR(phy) || !try_module_get(phy-ops-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ goto err0;
+ }
+
+ phy = phy-ops-of_xlate(phy, args);
alright, so of_xlate() is optional, am I right ? How about not
Not really. of_xlate is mandatory (it's even checked in phy_create).
Either the PHY provider can implement it's own version or use the
implementation above (by filling the function pointer).
alright.
implementing the above and have a check for of_xlate() being a valid
pointer here ?
Having the way it is actually mandates the PHY providers to always
provide of_xlate which IMO is better since some PHY providers wont
accidentally be using the default implementation.
ok cool, thanks for clarifying.
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ if (!phy_class)
+ phy_core_init();
why don't you setup the class on module_init ? Then this would be a
terrible error condition here :-)
This is for the case where the PHY driver gets loaded before the PHY
framework. I could have returned EPROBE_DEFER here instead I thought
will have it this way.
looks a bit weird IMO. Is it really possible for PHY to load before ?
yeah. it actually happened when I tried with beagle and had all the
modules as built-in. Because twl4030 has subsys_initcall(), it loads
before PHY framework.
Thanks
Kishon
--
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 01/11] usb: phy: Add APIs for runtime power management
On Wed, Apr 3, 2013 at 7:48 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device
available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
IMO we need not have wrapper APIs for runtime_enable and
runtime_disable
here. Generally runtime_enable and runtime_disable is done in
probe and
remove of a driver respectively. So it's better to leave the
runtime_enable/runtime_disable to be done in *phy provider* driver
than
having an API for it to be done by *phy user* driver. Felipe, what
do you
think?
Thanks!!
That's very true, runtime_enable() and runtime_disable() calls are
made by
*phy_provider* only. But a querry here.
Wouldn't in any case a PHY consumer might want to disable runtime_pm
on PHY ?
Say, when consumer failed to suspend the PHY properly
(*put_sync(phy-dev)* fails), how much sure is the consumer about the
state of PHY ?
no no, wait a minute. We might not want to enable runtime pm for the
PHY
until the UDC says it can handle runtime pm, no ? I guess this makes a
bit of sense (at least in my head :-p).
Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
enabled... Does it make sense to leave that control to the USB
controller drivers ?
I'm open for suggestions
Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.
Actually trying out few things, here are my observations
Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy-dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active
state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and
wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.
But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in
that case,
only one of the consumer can enable runtime_pm on PHY. So who decides
this.
Aargh!! lot of confusion here :-(
hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??
How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.
True
So how about:
usb_phy_autopm_enable()
{
if (!phy-suports_autosuspend)
return -ENOSYS;
if (phy-autosuspend_enabled)
return 0;
phy-autosuspend_enabled = true;
return pm_runtime_enable(phy-dev);
}
???
Great
and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.
Yea, this is a way around this. :-)
Just one more query :-)
Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if
any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?
Will the controller (like EHCI/OHCI) be functional now ?
ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)
Yes ofcourse.
So PHYs (in their runtime_suspend) should not be pulled into a state
wherein even the controllers become in-operational.
Thereby no attach-detection, and controller doesn't wake up to be able
to usb_phy_autopm_get_sync()
Sorry for so much noise, i am acting like slow study ;-)
--
balbi
--
Thanks Regards
Vivek
--
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/21] usb: phy: nop: Add some parameters to platform data
On 04/02/2013 08:21 PM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130320 09:24]: On Wed, Mar 20, 2013 at 09:13:24AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130320 09:00]: On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote: Add clk_rate parameter to platform data. If supplied, the NOP phy driver will program the clock to that rate during probe. Also add 2 flags, needs_vcc and needs_reset. If the flag is set and the regulator couldn't be found then the driver will bail out with -EPROBE_DEFER. Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com Hi Tony, maybe you might prefer to merge commit 1f0972f from my next branch which is exactly this patch. Basically, if you: $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next $ git merge 1f0972f you get $SUBJECT and can apply the others without fear of conflicts later. OK thanks will use commit 1f0972f, so let's consider that commit immutable. yeah, once it hits my 'next' branch, I don't rebase anymore. I've applied the board related patchs into omap-for-v3.10/usb that's based on commit 1f0972f. Thanks Tony. cheers, -roger -- 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/6] usb: phy: omap-usb2: use the new generic PHY framework
On Wednesday 03 April 2013, Felipe Balbi wrote:
const ? Maybe provide a:
#define DEFINE_PHY_OPS(name)\
const struct phy_ops #name_phy_ops = {
macro ? This will force people to add the const keyword :-)
Forcing people to use const structures is good, but I think it would be
better without the macro, just by marking the argument in
devm_phy_create() as const.
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 v4] ARM: omap2: twl-common: Add default power configuration
* Peter Ujfalusi peter.ujfal...@ti.com [130403 05:36]:
From: Matthias Brugger matthias@gmail.com
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger matthias@gmail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Tony, Matthias,
Changes since v3:
- remove the __initdata from all the structures introduced by this patch
If it is OK, I'll send a pull with this patch.
Well I was wondering if you have checked what happens if you re-init
the driver via /sys? Is this safe to do?
Regards,
Tony
arch/arm/mach-omap2/twl-common.c | 38 ++
arch/arm/mach-omap2/twl-common.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 51e138c..a85531e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = omap3_codec,
};
+static struct twl4030_ins wrst_seq[] = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] = {
+ wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata = {
+ .scripts= omap3_power_scripts,
+ .num= ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
+};
+
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
};
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
pmic_data-audio = omap3_audio_pdata;
+ if (pdata_flags TWL_COMMON_PDATA_POWER !pmic_data-power)
+ pmic_data-power = omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
pmic_data-vdac = omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h
b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC(1 2)
#define TWL_COMMON_PDATA_AUDIO (1 3)
+#define TWL_COMMON_PDATA_POWER (1 4)
/* Common LDO regulators for TWL4030/TWL6030 */
#define TWL_COMMON_REGULATOR_VDAC(1 0)
--
1.8.1.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 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
* Tomi Valkeinen tomi.valkei...@ti.com [130403 05:32]: Hi Tony, On 2013-02-13 18:46, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [130213 06:26]: init functions in omap board files request panel specific gpios, and provide functions which omapdss panel drivers call to enable or disable them. Instead of the board files requesting these gpios, they should just pass the platform specific data(like the gpio numbers), the panel should retrieve the platform data and request the gpios. Doing this prevents the need of the panel driver calling platform functions in board files. Panel drivers have their own platform data struct, and the board files populate these structs and pass the pointer to the 'data' field of omap_dss_device. This work will make it easier for the panel drivers be more adaptable to the DT model. There is also removal of passing panel reset_gpio numbers through omap_dss_device struct directly, reset gpios are passed through platform data only. To avoid merge conflicts and dependencies between drivers and core Soc code, please break thes kind of patches into following parts: 1. Any platform_data header changes needed so both I and Tomi can pull it in as needed. 2. Changes to DSS drivers. Please keep stubs around for the board specific callback functions so omap2plus_defconfig won't break with just #1 merged into arm soc tree. 3. All the arch/arm/*omap* changes based on #1 above to drop obsolete callback functions and add new pdata if still needed. This needs to build and boot on #1 so I can merge this in via arm soc tree. 4. Any .dts changes needed. Tony, I've split these patches as follows: Platform data header file changes: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers Board file changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup DSS panel changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup Removing unused fields from header files (based on panel changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup The 2-late-panel-cleanup breaks compilation if the arch changes are not merged, so I'll leave that until they have been merged. Do you mind if I add the board-cleanup branch temporarily to omapdss's for-next, to simplify testing? When everything looks ok, I'll remove it and pass the branch to you to be handled through l-o. Sure please go ahead. There are still some board-*.c related patches that I have not merged, but we'll see those merge conflicts before next as I usually do a merge with next before sending out pull reqs. 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 v5 1/6] drivers: phy: add generic PHY framework
Hi, On Wed, Apr 03, 2013 at 08:02:52PM +0530, Kishon Vijay Abraham I wrote: + ret = -EINVAL; + goto err0; + } + + if (!phy_class) + phy_core_init(); why don't you setup the class on module_init ? Then this would be a terrible error condition here :-) This is for the case where the PHY driver gets loaded before the PHY framework. I could have returned EPROBE_DEFER here instead I thought will have it this way. looks a bit weird IMO. Is it really possible for PHY to load before ? yeah. it actually happened when I tried with beagle and had all the modules as built-in. Because twl4030 has subsys_initcall(), it loads before PHY framework. that's a bug in twl4030. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Hi,
On Wed, Apr 03, 2013 at 02:55:47PM +, Arnd Bergmann wrote:
On Wednesday 03 April 2013, Felipe Balbi wrote:
const ? Maybe provide a:
#define DEFINE_PHY_OPS(name)\
const struct phy_ops #name_phy_ops = {
macro ? This will force people to add the const keyword :-)
Forcing people to use const structures is good, but I think it would be
better without the macro, just by marking the argument in
devm_phy_create() as const.
that won't force the definition of the struct to be const, however. But
I get your point.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Paul, Should I start a new email chain with that patch or add it here? On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh alexey.pel...@gmail.com wrote: Hi Paul, No problem, I'll prepare patch in next 24 hours and will send in ASAP. But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ On Tue, Apr 2, 2013 at 9:24 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Paul, can you please try to comment out change related to Rx line (granulation one). That's only Rx line related change in the patch. Yes, looks like simply reverting the commit 1776fd059c40 (OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation) change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it. Care to send a patch doing so ASAP for v3.9-rc fixes? That would moot the revert of the entire commit 1776fd059c40. - 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 v4 0/6] Generic PHY Framework
From: Kishon Vijay Abraham I kis...@ti.com Date: Wed, 3 Apr 2013 12:05:30 +0530 This patch series is about drivers/phy which will be used for now by usb, sata and maybe some video PHY's. Network itself has a comprehensive PHY in drivers/net/phy which we'd like to merge it with drivers/phy so that we have all the phy stuff in drivers/phy but we are not planning too far ahead here. Ok, that makes sense, 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: OK to use commit 71856843 as base for further omap clean up?
On Tue, Mar 26, 2013 at 11:22:00PM +, Russell King - ARM Linux wrote: On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote: Hi Russell, On 03/19/2013 12:59 PM, Tony Lindgren wrote: Hi Russell, Can we use your commit 71856843 (ARM: OMAP: use consistent error checking) as an immutable base for further omap dmtimer and gpmc work? I saw that you updated your clean-up branch. Ok to use the below commit [1] as a base for some v3.10 updates? It's still the same commit. I'm not intending to remove this commit from it, so yes, fine, go ahead. *sigh*. Actually, 4d485661d799e81f98097057d445f4803cef2af0 is buggered which is the commit below it. I said yes too quickly. Oh well, it'll just have to be broken for when it hits mainline now. -- 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/11] usb: dwc3/xhci/phy: Enable runtime power management
Question: Do you still need this patch for 3.10? http://marc.info/?l=linux-usbm=136057666911621w=2 Does this patchset build on top of that? I'm really behind on my patches for 3.10, sorry. Sarah Sharp On Mon, Apr 01, 2013 at 07:23:59PM +0530, Vivek Gautam wrote: This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on Samsung's USB 2.0 type and USB 3.0 type PHYs. Based on 'next' branch of Felipe Balbi's USB tree. Changes from v2: - Using separate functions for USB PHY runtime power management, instead of using macros. - Adding 'pm_runtime_set_suspended()' api call in dwc3 core layer before enabling runtime pm. (Ideally, we should be explicitly make device 'suspended' or 'active' before enabling runtime pm on it). - Checking return code for 'put_sync' and 'get_sync' of USB-PHYs when waking up or suspending them from dwc3 core's runtime_pm callbacks. - Removed buggy pm_runtime_put() calls from driver's (xhci, dwc3 and PHY) remove functions. - Adding a patch to enable runtime power management of Samsung's USB 2.0 PHY (usb: phy: samsung: Enable runtime power management on usb2phy) Changes from v1: - Adding required PHY APIs to handle runtime power management instead of directly twiddling with phy-dev. - Handling runtime power management of usb PHYs in dwc3 core driver instead of in any glue layer. - Splitting the patch: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb into required number to bifurcate functionality. Vivek Gautam (11): usb: phy: Add APIs for runtime power management USB: dwc3: Adjust runtime pm to allow autosuspend usb: dwc3: Enable runtime pm only after PHYs are initialized usb: dwc3: Add runtime power management callbacks usb: dwc3: exynos: Enable runtime power management usb: xhci: Enable runtime pm in xhci-plat usb: phy: samsung: Enable runtime power management on usb2phy usb: phy: samsung: Enable runtime power management on usb3phy usb: phy: samsung: Add support for external reference clock usb: phy: samsung: Add support for PHY ref_clk gpio usb: phy: samsung: Add support for PHY refclk switching drivers/usb/dwc3/core.c| 59 ++-- drivers/usb/dwc3/dwc3-exynos.c | 12 +++ drivers/usb/host/xhci-plat.c |6 ++ drivers/usb/phy/phy-samsung-usb.c | 26 +++ drivers/usb/phy/phy-samsung-usb.h |1 + drivers/usb/phy/phy-samsung-usb2.c |5 ++ drivers/usb/phy/phy-samsung-usb3.c | 119 +-- include/linux/usb/phy.h| 141 8 files changed, 358 insertions(+), 11 deletions(-) -- 1.7.6.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 V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Nishanth Menon n...@ti.com writes:
The following version 3 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used in non device
tree enabled boot.
However, in order to enable complete SoC entitlement for OMAP platforms, with
this series, key features are still pending on device tree adaptation for
OMAP:
A) clock framework data transition to DT - this should happen soon, so this
series hacks the clock node for the time being as suggested in review of
original series[1].
B) On processors that use voltage controller, voltage processor (VC/VP
hardware
loop using I2C_SR path) - we have started work on transitioning them to
regulator framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]
Note: At this point in time, we do not have DT entries for clock on OMAP
platforms. Common Clock Framework(CCF) could also control regulators[3].
Once these conversions are complete, there might be minimal cleanup work to
switch to the new data structure changes.
Key benefit of the series is to allow all relevant TI platforms now to use a
single cpufreq driver and equivalent frameworks in addition be part of the
transition to device tree.
NOTE: As a result of this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we should
delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
boot systems.
Yes, I like this direction better. Thanks for reworking and thanks for
the thorough changelog.
Key changes in version 3:
- series now rebased on Device tree patches queued for OMAP 3.10
- DT patches introducing OPPs are now merged, so pending patches alone
are part of the new series.
- omap-cpufreq is now converted to platform_device to address:
http://marc.info/?t=13643490191r=1w=2
version 2 of the series:
http://marc.info/?t=13637157023r=1w=2
available at:
https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2
version 1 of the series:
http://marc.info/?t=13632948545r=1w=2
available at:
https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1
[1] Original discussion thread which triggered this series:
http://marc.info/?l=linux-pmm=136304313700602w=2
https://patchwork.kernel.org/patch/2251841/
https://patchwork.kernel.org/patch/2251851/
[2] ABB RFC: http://marc.info/?l=linux-omapm=136449099409794w=2
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/
Version 3 is now based on for-3.10/dts branch from Benoit:
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
Version 3 is also available at:
https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
git link: git://github.com/nmenon/linux-2.6-playground.git
branch: cpufreq-cpu0-omap-all-v3
Test coverage:
test script: http://pastebin.com/zrr8ptge
Platforms verified:
beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
beagleboard (rev C1D) - OMAP3430 compatible
- DT enabled boot: http://pastebin.com/2AY1F5Qa
- No DT enabled boot: http://pastebin.com/hDk0gbpU
omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr
And thanks also for the broad testing.
One nit about the test report/coverage is I don't see any
test/verification that the voltage is still being scaled based on the DT
based OPPs. It's easy to verify at least from the regulator PoV that
the voltage is scaled also.
My dumb DVFS test script (below) should work on any busybox rootfs
Care to give that (or something like it) a try as well?
With that extra confirmation of testing, I will queue up this series.
Thanks,
Kevin
[1]
#!/bin/sh
REG=`find /sys/class/regulator -follow -maxdepth 2 -name name -exec grep -l mpu
{} \;`
mpu_reg=`echo $REG | cut -d'/' -f5`
echo MPU regulator: $mpu_reg
if [ ! -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
echo CPUfreq not enabled in kernel.
exit 0
fi
cd /sys/devices/system/cpu/cpu0/cpufreq
echo -n Available frequencies:
cat scaling_available_frequencies
echo -n Current frequency:
cat scaling_cur_freq
echo userspace
Re: [PATCH/Resend 2/2] arm: mach-omap2: prevent UART console idle on suspend while using no_console_suspend
Sourav Poddar sourav.pod...@ti.com writes: Hi Kevin, On Wednesday 20 March 2013 05:36 PM, Sourav Poddar wrote: Realised the list to whom the patch was send got dropped. Ccing them all.. On Wednesday 20 March 2013 05:18 PM, Sourav Poddar wrote: Hi Kevin, On Tuesday 19 March 2013 12:24 AM, Kevin Hilman wrote: Sourav Poddarsourav.pod...@ti.com writes: With dt boot, uart wakeup after suspend is non functional on omap4/5 while using no_console_suspend in the bootargs. With no_console_suspend used, od-flags should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing the console to idle in the suspend path. For non-dt case, this was taken care by platform data. Tested on omap5430evm, omap4430sdp. Cc: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Rajendra nayakrna...@ti.com Signed-off-by: Sourav Poddarsourav.pod...@ti.com This patch creates a dependency between omap_device (generic, device-independent code) and a specific driver (UART.) If you need to do something like this that's DT boot specific, then we probably need some late initcall in serial.c to handle this. It does not belong in omap_device. The following function omap_device_disable_idle_on_suspend(pdev) should only be called once the omap device has been build, which in the case of device tree is done in omap_device.c file. Moreover, the above call should be executed conditionally and should depend on the following two parameter. [1] a. Whether no_console_suspend is set and b. the device build is a console uart. When I look closely into the serial.c file, I realised that core_initcall(omap_serial_early_init) gets called irrespective of dt/non dt boot and will take care of most of the stuff(checking whether no_console_suspend is used and which uart is used as a console uart) which the $subject patch is proposing. But the problem is that we need to exchange the parsed information from serial.c to the omap_device file for the condtional execution of omap_device_disable_idle_on_suspend In this case, from serial.c we need 1. no_console_suspend = true 2. strcpy(console_name, oh_name), where oh_name corresponds to the console uart. then in omap_device.c do if (no_console_suspend !strcmp(oh-name, console_name)) omap_device_disable_idle_on_suspend(pdev); Please correct if I am understanding it incorrectly. If the above understanding looks good to you, is there a way we can make this exchange of information happen between serial.c and omap_device.c file? Any input on this? As I explained earlier, that there is a need to parse information in serial.c and use that in omap_device.c only after the device is build. As I explained earlier, any device specific hacks inside omap_device should be a red flag that something has gone wrong. How about fixing the UART driver/core to not runtime suspend if no_console_suspend is given? Then we can get rid of this no_idle_on_suspend hack all together since UART is the only remaining user. 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: OK to use commit 71856843 as base for further omap clean up?
* Russell King - ARM Linux li...@arm.linux.org.uk [130403 09:58]: On Tue, Mar 26, 2013 at 11:22:00PM +, Russell King - ARM Linux wrote: On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote: Hi Russell, On 03/19/2013 12:59 PM, Tony Lindgren wrote: Hi Russell, Can we use your commit 71856843 (ARM: OMAP: use consistent error checking) as an immutable base for further omap dmtimer and gpmc work? I saw that you updated your clean-up branch. Ok to use the below commit [1] as a base for some v3.10 updates? It's still the same commit. I'm not intending to remove this commit from it, so yes, fine, go ahead. *sigh*. Actually, 4d485661d799e81f98097057d445f4803cef2af0 is buggered which is the commit below it. I said yes too quickly. Oh well, it'll just have to be broken for when it hits mainline now. Yes we have few branches based on that. Note that the issue reported by Lothar I just resolved in the omap-for-v3.10/timer branch along with other conflicts when pulling in Jon's patches, so that might do the trick assuming there are no other issues. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: System timer updates
* Jon Hunter jon-hun...@ti.com [130401 19:14]: The following changes since commit 2d61aecee8f32259920cdf90a452fa26ffc64e9f: Merge commit '6bb27d7349db51b50c40534710fe164ca0d58902' into omap-timer-for-v3.10 (2013-04-01 13:47:29 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-timer-for-v3.10 for you to fetch changes up to 4615943cf3a531bc76f589c22bd366da092b7c0f: ARM: OMAP4+: Fix sparse warning in system timers (2013-04-01 13:49:46 -0500) This series consists mainly of clean-ups for clockevents and clocksource timers on OMAP2+ devices. The most significant change in functionality comes from the 5th patch which is changing the selection of the clocksource timer for OMAP3 and AM335x devices when gptimers are used for clocksource. This series is dependent on commit 7185684 (ARM: OMAP: use consistent error checking) from RMK's clean-up branch and commit 6bb27d7 (ARM: delete struct sys_timer) Thanks pulling into omap-for-v3.10/timer. I ended up merging this with omap-for-v3.10/fixes-non-critical because of the omap5 merge conflict. Regards, Tony Jon Hunter (7): ARM: OMAP2+: Display correct system timer name ARM: OMAP2+: Remove hard-coded test on timer ID ARM: OMAP2+: Simplify system timer clock definitions ARM: OMAP2+: Simplify system timers definitions ARM: OMAP3: Update clocksource timer selection ARM: OMAP2+: Store ID of system timers in timer structure ARM: OMAP4+: Fix sparse warning in system timers arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/common.h |3 +- arch/arm/mach-omap2/timer.c | 121 +- 4 files changed, 65 insertions(+), 63 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
On Wed, 3 Apr 2013, Felipe Balbi wrote: Lets suppose DWC3 enables runtime_pm on USB 2 type phy, it will try to go into suspend state and thereby call runtime_suspend(), if any. And PHY will come to active state only when its consumer wakes it up, and this consumer is operational only when its related PHY is in fully functional state. So do we have a situation in which this PHY goes into low power state in its runtime_suspend(), resulting in non-detection of devices on further attach (since PHY is in low power state) ? Will the controller (like EHCI/OHCI) be functional now ? ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(), right ? (so does DWC3 :-) Maybe you guys have already got this all figured out -- if so, feel free to ignore this email. Some subsystems handle this issue by calling pm_runtime_get_sync() before probing a driver and pm_runtime_put_sync() after unbinding the driver. If the driver is runtime-PM-enabled, it then does its own put_sync near the end of its probe routine and get_sync in its release routine. With PHYs you don't have probing and releasing, but you do have consumers registering and unregistering themselves, which is about the same thing. Alan Stern -- 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 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
On 10:47-20130403, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: [...] Test coverage: test script: http://pastebin.com/zrr8ptge Platforms verified: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr beagleboard (rev C1D) - OMAP3430 compatible - DT enabled boot: http://pastebin.com/2AY1F5Qa - No DT enabled boot: http://pastebin.com/hDk0gbpU omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr And thanks also for the broad testing. One nit about the test report/coverage is I don't see any test/verification that the voltage is still being scaled based on the DT based OPPs. It's easy to verify at least from the regulator PoV that the voltage is scaled also. I had probed and verified voltage on beagle and beagle XM. OMAP4 obviously wont scale (as mentioned) due to the fact that vc-vp regulator is needed. My dumb DVFS test script (below) should work on any busybox rootfs thanks for the script. yep - I can use this as well, but given that probe did verify voltage scale on TWL5030 inductors, it might be redundant. Ref: https://plus.google.com/photos/112464029509057661457/albums/5715034179943520193/5854221132322035042 I can take it again and show the same snap along with the log with the mentioned script later today. -- Regards, Nishanth Menon -- 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] OMAP/serial: Revert bad fix of Rx FIFO threshold granularity
From: Alexey Pelykh alexey.pel...@gmail.com Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2 that introduced regression reported by Paul Walmsley. This commit restores setting granularity in SCR register and adds note about comments below being inconsistent with actual code. Signed-off-by: Alexey Pelykh alexey.pel...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@linaro.org Cc: Felipe Balbi ba...@ti.com Cc: linux-ser...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org --- Paul, please confirm that this patch solves the regression. diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 4dc4140..30d4f7a 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -886,6 +886,17 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR); /* FIFO ENABLE, DMA MODE */ + up-scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK; + /* +* NOTE: Setting OMAP_UART_SCR_RX_TRIG_GRANU1_MASK +* sets Enables the granularity of 1 for TRIGGER RX +* level. Along with setting RX FIFO trigger level +* to 1 (as noted below, 16 characters) and TLR[3:0] +* to zero this will result RX FIFO threshold level +* to 1 character, instead of 16 as noted in comment +* below. +*/ + /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ -- 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] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
Nishanth Menon n...@ti.com writes:
With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.
As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we have OMAP clock nodes in device
tree.
Once the OMAP device tree conversion is complete, we can then do:
clocks = dpll_mpu_ck; or the SoC specific equivalent.
Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.
Cc: Kevin Hilman khil...@linaro.org
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Keerthy j-keer...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
One more thought on this patch...
---
Changes in v3:
- modified CC list.
- no functional change
V2: https://patchwork.kernel.org/patch/2303471/
V1: https://patchwork.kernel.org/patch/2273571/
arch/arm/mach-omap2/board-generic.c |5 +
arch/arm/mach-omap2/cclock33xx_data.c |2 +-
arch/arm/mach-omap2/cclock3xxx_data.c |3 ++-
arch/arm/mach-omap2/cclock44xx_data.c |3 ++-
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
Rather than adding new clkdev nodes below, how about using clk add_alias
here?
Kevin
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck, CK_AM33XX),
- CLK(cpu0, NULL, dpll_mpu_ck, CK_AM33XX),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck, CK_AM33XX),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck,
CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5a5b471 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
- CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
+ CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX), /* used in
non-device tree boot */
+ CLK(cpufreq-cpu0.0, NULL, dpll1_ck, CK_3XXX), /* used in
device tree boot */
};
static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bcea785 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X), /* used in
non-device tree boot */
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck, CK_443X), /* used in
device tree boot */
};
int __init omap4xxx_clk_init(void)
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
I've submitted patch that should remove this regression On Wed, Apr 3, 2013 at 6:55 PM, Alexey Pelykh alexey.pel...@gmail.com wrote: Paul, Should I start a new email chain with that patch or add it here? On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh alexey.pel...@gmail.com wrote: Hi Paul, No problem, I'll prepare patch in next 24 hours and will send in ASAP. But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ On Tue, Apr 2, 2013 at 9:24 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 1 Apr 2013, Alexey Pelykh wrote: Paul, can you please try to comment out change related to Rx line (granulation one). That's only Rx line related change in the patch. Yes, looks like simply reverting the commit 1776fd059c40 (OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation) change to OMAP_UART_SCR_RX_TRIG_GRANU1_MASK fixes it. Care to send a patch doing so ASAP for v3.9-rc fixes? That would moot the revert of the entire commit 1776fd059c40. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
Hi Santosh
On Wed, 3 Apr 2013, Santosh Shilimkar wrote:
Thes patchset has already missed last couple of merge windows and its the
biggest bottleneck in getting OMAP5 booting from mainline. So I request
you to please have a look it quickly so that Tony can line that up for
3.10.
Looks like there are a few minor issues with the patches based on a quick
look. I'll post those to the list shortly; they should be easy to fix.
But those issues aren't my real concern with this series.
What's harder to fix are the underlying process issues. My main concern
is that these patches add almost 9,000 lines of code and data. We've
received clear guidance from the upstream ARM SoC maintainers that any
significant new additions need to be balanced with moving a similar number
of lines of code and data out of arch/arm/{plat-,mach-}* into drivers/.
(Or the new patches should be accompanied with patches that show obvious
progress towards the goal of moving code and data out of
arch/arm/{plat-,mach-}*.) We need to see more help from TI on the
prerequisites for this cleanup process.
For example, as discussed last year with the TI upstream PM team, an
important first step in this process in my view is to get rid of the
direct PRM/CM register accesses in the OMAP PM code. See commit
c4ceedcb18cf7a06059482a3a1828b9aad9f78cf (ARM: OMAP2+: CM/clock: convert
_omap2_module_wait_ready() to use SoC-independent CM functions) as an
example of this process. This should make it easier to get the PRM/CM
functionality into drivers/. That in turn make it possible to move the
clockdomain, clock, powerdomain, and hwmod code to drivers/.ARM: OMAP2+:
CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM
functions. So far as I can tell, there hasn't been any forward progress
on this.
It's also necessary to see more TI contributions in finding and fixing
regressions. Detecting and fixing regressions from the previous kernel
release should be done first, before working on cleanup series or new
feature/SoC additions. Looking at the list of v3.9-rc regressions that
I've found, we've gotten very little organized help from TI on dealing
with them.
This in turn robs the maintainers of time that could be spent doing patch
review or further cleanup work, which benefits no one in the end.
Ideally each regression would be assigned to a member of the TI upstream
team, and the whole process could be completed within one or two weeks.
...
So from my point of view, I'd like to see the following changes before we
accept any new patchsets that add a significant number of lines:
1. Organized help from TI in finding and fixing regressions in the -rc
cycle, with the regressions dealt with before any new feature
pull-requests are sent
2. Help from TI on some of the cleanup work that we've mentioned in the
past, starting with the PRM/CM register access cleanup inside mach-omap2/
3. Pairing any large feature or SoC additions with at least an equal
removal of lines of code
regards,
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No functional change.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65
-
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d650f91..d9e4843 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
void (*secondary_startup)(void);
};
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend: CPU suspend finisher function pointer
+ * @resume: CPU resume function pointer
+ * @scu_prepare: CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+ int (*finish_suspend)(unsigned long cpu_state);
+ void (*resume)(void);
+ void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
checkpatch should've yelled at you for adding externs to .c files.
Also, aren't these already defined in common.h anyways?
Otherwise, patch looks fine.
Kevin
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static int default_finish_suspend(unsigned long cpu_state)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static void dummy_cpu_resume(void)
+{}
+
+static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{}
+
+struct cpu_pm_ops omap_pm_ops = {
+ .finish_suspend = default_finish_suspend,
+ .resume = dummy_cpu_resume,
+ .scu_prepare= dummy_scu_prepare,
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -172,11 +208,12 @@ static void save_l2x0_context(void)
{
u32 val;
void __iomem *l2x0_base = omap4_get_l2cache_base();
-
- val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
- __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
- val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
- __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ if (l2x0_base) {
+ val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+ __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+ val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+ __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ }
}
#else
static void save_l2x0_context(void)
@@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
cpu_clear_prev_logic_pwrst(cpu);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
- scu_pwrst_prepare(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
+ omap_pm_ops.scu_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
/*
* Call low level function with targeted low power state.
*/
if (save_state)
- cpu_suspend(save_state, omap4_finish_suspend);
+ cpu_suspend(save_state, omap_pm_ops.finish_suspend);
else
- omap4_finish_suspend(save_state);
+ omap_pm_ops.finish_suspend(save_state);
/*
* Restore the CPUx power state to ON otherwise CPUx
@@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info-pwrdm);
pwrdm_set_next_pwrst(pm_info-pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));
- scu_pwrst_prepare(cpu, power_state);
+ omap_pm_ops.scu_prepare(cpu, power_state);
/*
* CPU never retuns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap_secondary_startup().
*/
- omap4_finish_suspend(cpu_state);
+ omap_pm_ops.finish_suspend(cpu_state);
pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
return 0;
@@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
save_l2x0_context();
+ if (cpu_is_omap44xx()) {
+ omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.resume = omap4_cpu_resume;
+ omap_pm_ops.scu_prepare =
Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Quoting Nishanth Menon (2013-04-02 19:00:02) On 20:35-20130402, Andrii Tseglytskyi wrote: On 04/02/2013 08:16 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 20:35:45) On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. ACK. Making the ABB code into a regulator driver is the right thing to do regardless of whether or not we use a Super Regulator(tm) or just chain together Not So Super Regulators(tm). I'm not an expert at the regulator framework, but I encourage Andrii to look into regulator_set_mode(), which might be a more semantically accurate alternative than regulator_set_voltage() for the ABB ldo. Agree. It is a good idea in general. regulator_set_mode() API seems to be good enough for handling ABB mode (FBB/RBB/Bypass). Knowledge about ABB mode on each OPP can be moved from ABB regulator to Super regulator. Thanks a lot for all your comments. Digging a little more on this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/regulator/consumer.h#n41 If we were to mean usage of mode to mean - usage of PWM/PFM etc mode(like in tps/twl chips), this makes sense. However, if we mean forward, reverse and bypass as modes we might be misusing the original intent of the API. Yeah, I agree that using those modes would probably qualify as abuse. However I still find it tempting to use FAST for FBB and maybe NORMAL or STANDBY for bypass. Instead of using a mode then a voltage could be used. Any Vnom value passed into regulator_set_voltage would result in ABB ldo being bypassed, whereas if 900mV was passed in that would put the ABB ldo into FBB. And that 900mV value isn't really set in stone, it is just more often than not the value observed on OMAP3630 and OMAP4. However that is really a kludge and completely non-intuitive for someone looking at the code for the first time. I haven't gone digging through the regulator stuff concerning this but I hope a good solution can be found. Regards, Mike -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
cc Kevin Hi On Wed, 20 Mar 2013, Santosh Shilimkar wrote: Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files So it looks like this patch never made it to the mailing list. Was it too big? If so, please try splitting it into two or more pieces. Looking at the git branch that you posted for pulling, the patch adds two files, so maybe you can just create one patch for each file? Also, looking at the bottom of the arch/arm/mach-omap2/prm54xx.h from this commit 600e78bb51c0ee081f0da14f879c3e4a1dee9896, there are a bunch of function prototypes that reference OMAP44xx. Shouldn't these reference OMAP54xx, or be removed from this file? If you're reusing the OMAP4 PRM functions for OMAP5, then shouldn't they be moved out from the OMAP4 header files into a separate header file? ARM: OMAP5: CM: Add OMAP54XX register and bitfield files There are similar problems with this patch. It doesn't look like it ever made it to the linux-omap list, in my inbox, anyway. And again the function prototypes make several references to OMAP4, when they should refer to OMAP5 or be removed from this file. ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers More duplicated OMAP4 function prototypes here. ARM: OMAP5: SCRM: Add OMAP54XX header file. Looks fine to me. ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header These two look okay to me based on a superficial inspection. Is there a public TRM posted for OMAP5? It's not in the obvious place, so there's no way to review these against the TRM: http://www.ti.com/lsds/ti/omap-applications-processors/technical-documents.page?familyId=601docCategoryId=6 ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Looks like this one hasn't been reposted after the changes that were made to it after Tony's comments? If I've just missed the list post, please send a link. Otherwise, the updated patch should be reposted. Santosh Shilimkar (4): ARM: OMAP5: hwmod_data: Fix UART sysc settings ARM: OMAP5: hwmod-data: Add timer clock activity flags These two should be rolled into the ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data patch. ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data This one needs to be acked by Kevin. ARM: OMAP5: Enable build and frameowrk initialisations Looks fine to me. - 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 00/10] ARM: OMAP5: hwmod, clock and prm data files
Hi, On Fri, 18 Jan 2013, Santosh Shilimkar wrote: Series contains the hwmod, clock and prm data files for OMAP54xx SOCs. This data was kept out of tree to be validated on es2.0 silicon version and also to avoid the es1.0/es2.0 differences which are many. Benoit Cousson, Rajendra Nayak, Paul Walmesly and Mike have all contributed to get the autogen scripts in shape for OMAP5. From various discussion on the list, the clock data files are suppose to be moved to drivers/clk/. Once the direction is clear, patch 8 can be updated accordingly. Patches are tested on OMAP5 sEVM and uEVM. For testing few additional patches are needed. Same tree can be fetched from here [1] The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.9/omap5_data_files for you to fetch changes up to 7f534e1ebeb2bc64250b56fe00eb7d4dfa585e8e: ARM: OMAP5: Enable build and frameowrk initialisations (2013-01-18 19:45:48 +0530) I've posted several comments on the patch contents themselves, all of which are relatively minor, and should be easy to fix: http://marc.info/?l=linux-omapm=136501977311223w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP/serial: Revert bad fix of Rx FIFO threshold granularity
Hi Greg, Alexey, On Wed, 3 Apr 2013, Alexey Pelykh wrote: From: Alexey Pelykh alexey.pel...@gmail.com Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2 that introduced regression reported by Paul Walmsley. This commit restores setting granularity in SCR register and adds note about comments below being inconsistent with actual code. Signed-off-by: Alexey Pelykh alexey.pel...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@linaro.org Cc: Felipe Balbi ba...@ti.com Cc: linux-ser...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Tested-by: Paul Walmsley p...@pwsan.com Thanks for the fast response and fix, Alexey. Greg, is it possible for you to take this for v3.9-rc fixes? - 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
On Wed, 3 Apr 2013, Alexey Pelykh wrote: I've submitted patch that should remove this regression Thanks, indeed it does. So the revert patch that I sent at the beginning of this thread is now mooted. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile |9 ++--
arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} | 54
.../mach-omap2/{sleep44xx.S = sleep_omap4plus.S} |0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c = pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S = sleep_omap4plus.S} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d5ff91..d91ae0f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o
omap-4-5-common = omap4-common.o
omap-wakeupgen.o \
-sleep44xx.o
+sleep_omap4plus.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common)
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap-smc.o:=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
@@ -80,11 +80,12 @@ endif
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
+omap4plus-common-pm = omap-mpuss-lowpower.o pm_omap4plus.o
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
-obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
+obj-$(CONFIG_SOC_OMAP5) += $(omap4plus-common-pm)
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 86%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..e920c34 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4PLUS Power Management Routines
nit: OMAP4+ (you only need to spell out plus in the filename.
*
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
* Rajendra Nayak rna...@ti.com
* Santosh Shilimkar santosh.shilim...@ti.com
*
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
}
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.
{
- int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+ int ret = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
- goto err2;
+ return ret;
}
/*
@@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
ducati_clkdm = clkdm_lookup(ducati_clkdm);
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
(!l3_2_clkdm) || (!ducati_clkdm))
- goto err2;
+ return -EINVAL;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |=
Re: [PATCH] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi, On Wed, 3 Apr 2013, Alexey Pelykh wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ If you want to continue to experiment with it, I'd be willing to do an occasional test boot on 37xx EVM. It's nice to see community patches... - 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] OMAP/serial: Revert bad fix of Rx FIFO threshold granularity
On Wed, Apr 03, 2013 at 08:16:18PM +, Paul Walmsley wrote: Hi Greg, Alexey, On Wed, 3 Apr 2013, Alexey Pelykh wrote: From: Alexey Pelykh alexey.pel...@gmail.com Partially reverts 1776fd059c40907297d6c26c51876575d63fd9e2 that introduced regression reported by Paul Walmsley. This commit restores setting granularity in SCR register and adds note about comments below being inconsistent with actual code. Signed-off-by: Alexey Pelykh alexey.pel...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@linaro.org Cc: Felipe Balbi ba...@ti.com Cc: linux-ser...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Tested-by: Paul Walmsley p...@pwsan.com Thanks for the fast response and fix, Alexey. Greg, is it possible for you to take this for v3.9-rc fixes? Will do, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
Santosh Shilimkar santosh.shilim...@ti.com writes: Enables MPUSS ES2 power management mode using ES2_PM_MODE in AMBA_IF_MODE register. 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken What is broken? 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently. The AMBA_IF_MODE register value is stored on SAR RAM and restored by ROM code. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-secure.h|2 ++ arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++ arch/arm/mach-omap2/omap-wakeupgen.h |1 + 3 files changed, 22 insertions(+) diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h index 0e72917..82b3c4c 100644 --- a/arch/arm/mach-omap2/omap-secure.h +++ b/arch/arm/mach-omap2/omap-secure.h @@ -42,6 +42,8 @@ #define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109 #define OMAP4_MON_L2X0_PREFETCH_INDEX0x113 +#define OMAP5_MON_AMBA_IF_INDEX 0x108 + /* Secure PPA(Primary Protected Application) APIs */ #define OMAP4_PPA_L2_POR_INDEX 0x23 #define OMAP4_PPA_CPU_ACTRL_SMP_INDEX0x25 diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index f8bb3b9..8bcaa8c 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -42,6 +42,7 @@ #define CPU1_ID 0x1 #define OMAP4_NR_BANKS 4 #define OMAP4_NR_IRQS128 +#define OMAP5_AMBA_IF_PM_MODE(1 5) nit: use BIT() 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 v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
Santosh Shilimkar santosh.shilim...@ti.com writes:
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b1441b1..d390d18 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -62,6 +62,10 @@
#include prm44xx.h
#include prm-regbits-44xx.h
+/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
+#define PRM_PSCON_HG_EN (1 24)
+#define PRM_PSCON_HG_RAMPUP (1 25)
nit: use BIT()
#ifdef CONFIG_SMP
struct omap4_cpu_pm_info {
@@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
return 0;
}
+/**
+ * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
+ *
+ * OMAP5 devices supports SR3-APG (mercury) power management technology to
+ * reduce leakage. It allows for full logic and memories retention on
+ * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
+ * the mercury retention feature.
+ */
+static void enable_mercury_retention_mode(void)
__init ?
This is very OMAP5 specific (unless you generalize the offsets used) so
should this have omap5_ prefix?
Kevin
+{
+ u32 reg;
+
+ /*
+ * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
+ * enabled from PRM_PSCON_COUNT register.
+ */
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+ reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
nit: when I see 'reg', I expect it to be a register/offset. But this is
a register value. Maybe use 'val' instead as you've done elsewhere in
this series.
Kevin
+}
/*
* Initialise OMAP4 MPUSS
@@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ enable_mercury_retention_mode();
}
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 v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
Santosh Shilimkar santosh.shilim...@ti.com writes:
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|3 ++-
arch/arm/mach-omap2/io.c|8
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..8e261a6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
+ .init_late = omap5_init_late,
.dt_compat = omap5_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f75d972 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
}
#endif
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) (defined(CONFIG_ARCH_OMAP4) ||
defined(CONFIG_SOC_OMAP5))
int omap4_pm_init(void);
#else
static inline int omap4_pm_init(void)
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void omap5_init_late(void);
int omap2_common_pm_late_init(void);
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e948a39..cdd1264 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -636,6 +636,14 @@ void __init omap5_init_early(void)
omap_hwmod_init_postsetup();
}
+
+void __init omap5_init_late(void)
+{
+ omap_mux_late_init();
+ omap2_common_pm_late_init();
+ omap4_pm_init();
+ omap2_clk_enable_autoidle_all();
+}
Since you're consolidating, why not rename omap4430_init_late to
omap4plus_init_late and use it for both OMAP4 and OMAP5?
Kevin
#endif
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
--
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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi On Wed, Apr 3, 2013 at 11:21 PM, Paul Walmsley p...@pwsan.com wrote: Hi, On Wed, 3 Apr 2013, Alexey Pelykh wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ If you want to continue to experiment with it, I'd be willing to do an occasional test boot on 37xx EVM. It's nice to see community patches... I'm pretty sure that current configuration of UART indeed sets Rx FIFO threshold to 1 character, as opposite to 16 characters mentioned in comments. Kernel 3.3 is the origin of Rx 1-char-granularity bit setting, but states clearly that Rx FIFO is being set to 1 character in non-DMA mode. The comment appears between 3.6 and 3.7 in commit 6721ab7f77f2614ab43e3de2f908b1d7436331df by Felipe Balbi. 3.0-3.2 kernels don't have 1-char-granularity enabled, and Rx FIFO threshold level was effectively set to 16 characters, what should be the same as my patch that turned off 1-char-granularity Paul, can you confirm (if possible, surely) if 3.0-3.2 kernels had same issue? Felipe, it would be great to get your comments on this? - 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi, On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh alexey.pel...@gmail.com wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. As FWIW I was also affected by it, maybe because my console is on UART3 and that is on different power (or was is clock?) domain than UART1. -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for
OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+ omap_pm_ops.finish_suspend = omap5_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap5_secondary_startup;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
+ /* Over-write the OMAP4 hook to take care of ROM BUG */
+ if (cpu_is_omap446x())
+ omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
A couple nits...
I think this would go better at the end of the 'if omap44xx' block
above.
Also, while you're hear, maybe it's time to rename the current secondary
startup functions to match the new one. IOW omap4_..., omap4460_... and
omap5_...
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 v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
Santosh Shilimkar santosh.shilim...@ti.com writes: While waking up CPU from off state using clock domain force wakeup, restore the CPU power state to ON state before putting CPU clock domain under hardware control. Otherwise CPU wakeup might fail. The change is recommended for all OMAP4+ devices though the PRCM weakness was observed on OMAP5 devices first. Sounds reasonable, but can you describe the weakness a little more? IOW, what exactly happens if this is not done? It sounds like the CPU might immediately go back to retention, but how does that happen unless it does a WFI? Also, this sounds like a fix to me, and should probably be broken out accordingly. 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi Alexey, On Wed, 3 Apr 2013, Alexey Pelykh wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. Well probably no one else is testing it :-) As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ Again it certainly would not surprise me... that UART IP block seems to be poorly understood :-( Bizarre, I know. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
Santosh Shilimkar santosh.shilim...@ti.com writes:
When the entire MPUSS cluster is powered down in device off state, L2 cache
memory looses it's content and hence while targetting such a state,
l2 cache needs to be flushed to main memory.
Add the necessary low power code support for the same.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/sleep_omap4plus.S | 21 +
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 1739468..a171a5a 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -47,6 +47,7 @@
#define OMAP4_MON_L2X0_PREFETCH_INDEX0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AUX_CTRL_INDEX 0x107
+#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
this #define is not used in this patch.
Kevin
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S
b/arch/arm/mach-omap2/sleep_omap4plus.S
index 4a5e2e4..288f62f 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
* 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR L2 lost(debug only)
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
@@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
isb
dsb
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
+ andsr5, r5, #0x0f
+ ldreq r0, [r8, #L2X0_SAVE_OFFSET0]@ Retrieve L2 state
+ ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
+ cmp r0, #3
+ bne do_wfi
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1@ Check for HS device
+ bne skip_secure_l2_clean_op
+ mov r0, #1 @ Clean secure L2
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l2_clean_op:
+ bl v7_flush_dcache_all
+
do_wfi:
bl omap_do_wfi
--
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 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
Santosh Shilimkar santosh.shilim...@ti.com writes: OMAP4 CPUidle driver registration call is under a loop which leads to calling cpuidle_register_driver twice which is not intended. Fix it by moving the driver registration outside the loop. Reported-by: Nishanth Menon n...@ti.com Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks good. I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply this one there. 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 v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
Santosh Shilimkar santosh.shilim...@ti.com writes: If the CPUidle device registration fails for some reason, we should unregister the driver on error path. Fix the code accordingly. Also when at it, check of the driver registration failure too. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Adding to my for_3.10/fixes/cpuidle branch. 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 v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
Santosh Shilimkar santosh.shilim...@ti.com writes: It is useful to know the CPU power state along with MPUSS power state in a supported C-state. Since the data is available via sysfs, one can avoid scrolling the source code for precise construction of C-state. Reported-by: Nishanth Menon n...@ti.com Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Nice. Adding to for_3.10/fixes/cpuidle branch. 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] Revert OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation
Hi Paul, Is it possible to check behavior on 3.0-3.2 kernels? On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley p...@pwsan.com wrote: Hi Alexey, On Wed, 3 Apr 2013, Alexey Pelykh wrote: But, since we've found the issue, I suggest that we should look at it closer, especially since at this moment only you can reproduce it. Well probably no one else is testing it :-) As far as I understand, but I may be wrong, this comment is wrong, since if to specify OMAP_UART_SCR_RX_TRIG_GRANU1_MASK, it effectively sets Rx threshold to 1 character, instead of 16. /* Set receive FIFO threshold to 16 characters and * transmit FIFO threshold to 16 spaces */ Again it certainly would not surprise me... that UART IP block seems to be poorly understood :-( Bizarre, I know. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index b8a22f0..ac6d526 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4PLUS CPU idle Routines
nit: s/PLUS/+/
in a few other places in this patch also.
*
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2013 Texas Instruments, Inc.
* Santosh Shilimkar santosh.shilim...@ti.com
* Rajendra Nayak rna...@ti.com
*
@@ -24,13 +24,13 @@
#include clockdomain.h
/* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
};
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = omap4_idle_data[0];
The assignment at init time (from the next patch) should be done here
for 44xx, and the next patch can just add OMAP5 support.
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 v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
Retention) power states can be achieved with respective power states
on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
because of hardware limitation.
I'm a bit confused by the description here.
I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?
Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake.
Even on secure devices?
Code makes use of voting scheme for cluster low power state to support
MPUSS CSWR C-state.
The voting scheme and associated locking should be better described
here, or commented in the code itself.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ int cpu_id = smp_processor_id();
+ unsigned long flag;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
I think the CPUidle core handles the broadcast notification now.
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.
Even with that, it still seems potentially racy. Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
+ return index;
+}
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 v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
Santosh Shilimkar santosh.shilim...@ti.com writes:
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
function to check whether the MPU cluster lost context or not. Thanks to
couple CPUIdle, cluster low power entry is almost guaranteed and hence
the programmed cluster check is enough in idle exit path. The API was
more of an optimization for corner cases, where if the cluster low power
entry fails for some reason, the cluster context restore gets skipped.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Looks good, but I find the changelog a bit confusing.
Below is a slightly modified patch (I only modified the changelog). If
those changes are OK with you, I'll add it to my cpuidle branch as well.
Kevin
From c01794dc249f826f0714578f26ff9efd35ea6296 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 25 Mar 2013 15:35:08 +0530
Subject: [PATCH] ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
to check whether the MPU cluster lost context or not before calling
cpu_cluster_pm_exit(). This was initially done an optimization for
corner cases, where if the cluster low power entry fails for some
reason, the cluster context restore gets skipped. However, since
reading the previous context is expensive (involving slow accesses to
the PRCM), it's better to avoid it and simply check the target cluster
state instead.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[khil...@linaro.org: minor changelog edits]
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/common.h | 5 -
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f5c9983 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -249,7 +249,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -277,10 +276,6 @@ static inline int omap4_finish_suspend(unsigned long
cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 354517a..3cad103 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -149,7 +149,8 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx-mpu_state == PWRDM_POWER_RET)
+ (cx-mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 8bcb64b..e80327b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -139,20 +139,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int
cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg = OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: GPMC updates
* Jon Hunter jon-hun...@ti.com [130402 10:00]: The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4: Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10 for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23: ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500) Adds GPMC DT support for NOR flash and Ethernet and includes various GPMC cleans-up and fixes. This series is dependent on commit 7185684 (ARM: OMAP: use consistent error checking) from RMK's clean-up branch and commit 31d9adc (ARM: OMAP2+: Fix broken gpmc support). Looks good except it adds a new warning: arch/arm/mach-omap2/gpmc.c: In function ‘gpmc_read_timings_dt’: arch/arm/mach-omap2/gpmc.c:1324: warning: ‘p’ may be used uninitialized in this function Can you please take a look? Regards, Tony Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check Javier Martinez Canillas (3): ARM: OMAP2+: return -ENODEV if GPMC child device creation fails ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child() ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes Jon Hunter (17): ARM: OMAP2+: Simplify code configuring ONENAND devices ARM: OMAP2+: Add variable to store number of GPMC waitpins ARM: OMAP2+: Add structure for storing GPMC settings ARM: OMAP2+: Add function for configuring GPMC settings ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings() ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings() ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure() ARM: OMAP2+: Add function to read GPMC settings from device-tree ARM: OMAP2+: Add additional GPMC timing parameters ARM: OMAP2+: Add device-tree support for NOR flash ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT ARM: OMAP2+: Detect incorrectly aligned GPMC base address ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails Mark Jackson (1): ARM: OMAP: Clear GPMC bits when applying new setting. Documentation/devicetree/bindings/bus/ti-gpmc.txt | 103 +++- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 .../devicetree/bindings/mtd/gpmc-onenand.txt |3 + Documentation/devicetree/bindings/net/gpmc-eth.txt | 97 arch/arm/mach-omap2/gpmc-nand.c| 42 +- arch/arm/mach-omap2/gpmc-onenand.c | 118 ++--- arch/arm/mach-omap2/gpmc-smc91x.c | 30 +- arch/arm/mach-omap2/gpmc.c | 544 ++-- arch/arm/mach-omap2/gpmc.h | 43 +- arch/arm/mach-omap2/usb-tusb6010.c | 62 ++- 10 files changed, 831 insertions(+), 309 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt -- 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 1/6] drivers: phy: add generic PHY framework
On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
s/dt data/device tree ?
+PHY subsystem refer Documentation/phy.txt
s/refer/refer to ?
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+#phy-cells =1;
+.
+.
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg =xxx;
+.
+.
+phys =usb2_phy,usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
s/PHYs/PHYs, ?
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg =xxx;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
I find it a bit difficult to parse. Perhaps
This node represents a controller that uses one of the PHYs of the PHY
provider
device defined previously. ...
or something similar ?
+differentiate between the two PHYs.
s/the two/the two available ?
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..7785ec0
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,113 @@
+ PHY SUBSYSTEM
+ Kishon Vijay Abraham Ikis...@ti.com
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
Shouldn't it be ...medium, e.g. the USB... ?
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controller has PHY functionality embedded into it and others use an external
controllers have PHY functionality embedded into them ?
+PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
s/uses/use ?
+SATA etc.
+
+The intention of creating this framework is to bring the phy drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and to
+increase code maintainability.
+
+This framework will be of use only to devices that uses external PHY (PHY
s/uses/use ?
+functionality is not embedded within the controller).
+
+2. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, const char *label,
+ struct device_node *of_node, int type, struct phy_ops *ops,
+ void *priv);
+struct phy *devm_phy_create(struct device *dev, const char *label,
+ struct device_node *of_node, int type, struct phy_ops *ops,
+ void *priv);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, label, device node, type, phy ops and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, suspend, resume, power_on and power_off.
+
+3. Binding the PHY to the controller
+
+The framework provides an API for binding the controller to the PHY in the
+case of non dt boot.
+
+struct phy_bind *phy_bind(const char *dev_name, int index,
+ const char *phy_dev_name);
+
+The API fills the phy_bind structure with the dev_name (device name of the
+controller), index and phy_dev_name (device name of the PHY). This will
+be used when the controller requests this phy. This API should be used by
+platform specific initialization code (board file).
+
+In the case of dt boot, the binding information should be added in the dt
+data of the controller.
s/in the dt data of/in the device tree node of ?
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides 6 APIs to get a reference to the PHY.
+
+struct phy
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
Hi Laurent, On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart wrote: On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote: Pali Rohár wrote: On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote: On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote: On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote: On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote: On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote: On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote: +/* + * arch/arm/mach-omap2/board-rx51-camera.c + * + * Copyright (C) 2008 Nokia Corporation + * + * Contact: Sakari Ailus sakari.ai...@nokia.com + * Tuukka Toivonen tuukka.o.toivo...@nokia.com You should put these people to CC... Just to see if the addresses are still valid (which I doubt). Ok, trying :-) I got Delivery Status Notification (Failure) for both addresses. This is expected. Sakari Ailus hosts some code on github [0], which has the following email address: sakari.ailus+gitori...@retiisi.org.uk I added it to this mail's CC. [0] https://gitorious.org/~sailus Nice to hear people are interested in this. ;-) The primary reason I haven't tried submitting this to mainline is that ARM board code has a bad reputation these days. The N900 does not have yet support for device tree (AFAIK), which also would require a few bits and pieces on the flash driver to work. Also the sensor and lens drivers would need at least some work before being ready for submission to mainline for camera to be usable. Unfortunately I haven't had recently time to work on this. N9(50) support has higher priority for myself. That, too, is pending the DT support for the device. There's indeed more up-to-date code in my repository. Even if it's not too close to mainline anymore it should be a better starting point than the old kernel from MeeGo. URL:https://gitorious.org/omap3camera/pages/Home Hi, this board code is same in your git repository and on meego obs. Patch only adding support for adp1653 driver which is already in upstream kernel. Are there any other problems with this patch to go for upstream? A few more things comes to mind. We depend a little bit on actual board code; it's not only static data. That's the configuration of the external clock from the ISP to the sensor. That should move to the common clock framework so that the ISP registers the clock and the sensor driver can then use it. AFAIR Laurent has done some work on that. Yes. I hope to get the patches in v3.10. Cool! :) The peculiar detail of the rx51 is that there's a switch on the camera CCP2 bus that selects either sensor (primary or secondary). Both sensors are connected to the same receiver. That isn't properly modelled currently at all, so that's why we have rx51_camera_set_xshutdown(). I guess it'd still work if you only power (i.e. open) either of the devices at a time, though. Have you thought about how we could model that ? Well, the two dependent gpios could be modelled as two independent ones ( for sensor drivers), but setting the state of those gpios could fail, gpio_set_value() still returns void. This isn't pretty perhaps but as a result the initialisation of the secondary sensor to be powered up at the same time will fail since it's in reset: the xshutdown of both sensors is controlled by the same gpio as is the mux (AFAIR). So one N900 camera specific gpio driver would be needed. It'd be a very simple driver. What do you think? -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted earlier (March 1st 2013). Patch-set incorporates comments from Nishant Menon (Thanks for review NM) and his acked-by tags. I would like to get this queued for 3.10 merge window if you are ok with the series. I did a review of this series with several comments on the individual patches. I've already queued most of the CPUidle fixes/cleanups in my for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the rest, I suggest probably breaking it up into cleanup/consolidation stuff and then OMAP5 support. The latter will depend on all the OMAP5 data/headers but the cleanup/consolidation stuff could be merged sooner (but probably a bit late for v3.10 now.) 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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Hi,
* Roger Quadros rog...@ti.com [130319 07:31]:
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
arch/arm/boot/dts/omap4.dtsi |5 +++
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/cclock44xx_data.c | 35
arch/arm/mach-omap2/clock44xx.h|1 +
arch/arm/mach-omap2/common.h |9 +
arch/arm/mach-omap2/io.c |6 +++
7 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
...
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
Is this really specific to omap4 and auxclk only?
Shouldn't it be just omap-clock.txt?
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+ auxclk0_ck,
+ auxclk1_ck,
+ auxclk2_ck,
+ auxclk3_ck,
+ auxclk4_ck,
+ auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
+static struct clk_onecell_data scrm_data;
+
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
+
+#else
+
+int __init omap4_clk_init_dt(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
int __init omap4xxx_clk_init(void)
{
u32 cpu_clkflg;
.. and I'm not too keen on adding driver specific stuff to this file.
How about just add a minimal drivers/clk/omap/clk-xyz.c that takes
the configuration from DT and is based on the binding we already have in
Documentation/devicetree/bindings/clock/clock-bindings.txt?
Then as we add new bindings there we can drop them from current
cclock44xx_data.c, no? That is after omap4 is DT only..
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 v5 0/6] Generic PHY Framework
On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. ... Changes from v4: * removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers* should use their custom implementation of of_xlate or use of_phy_xlate to get *phy instance* from *phy providers*. * Added of_phy_xlate to be used by *phy providers* if it provides only one PHY. * changed phy_core from having subsys_initcall to module_init. s/of_phy_xlate/of_phy_simple_xlate/ ? That would hightlight the fact it's just /an/ implementation for the simple case, not /the/ implementation for all cases. It'd be consistent with e.g. drivers/gpio, which has of_gpio_simple_xlate(). -- 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 1/6] drivers: phy: add generic PHY framework
On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend,
resume,
power_on, power_off.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
+extern struct phy *devm_phy_create(struct device *dev, const char *label,
+ struct device_node *of_node, int type, struct phy_ops *ops,
+ void *priv);
Can't the function get of_node from dev-of_node?
I wonder if we shouldn't split up the registration a bit though:
A function which registers a PHY object itself. That's the function above.
A function which registers a DT-based PHY provider.
Then, the of_xlate op would be part of the PHY provider, not part of
some random PHY that happens to exist on that node. So:
struct phy {
struct device *dev;
struct module *owner;
int (*init)(struct phy *phy);
int (*exit)(struct phy *phy);
int (*suspend)(struct phy *phy);
int (*resume)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
};
int phy_register(struct phy *phy);
All PHY providers would use that API, whether running in a DT-base
system or not.
struct of_phy_provider {
struct device *dev;
struct phy * (*of_xlate)(struct of_phy_provider *provider,
struct of_phandle_args *args);
};
int phy_register_of_provider(struct of_phy_provider *provider);
Only DT-based PHY providers would use that API.
... or something like that?
phy_get() would do something like:
if dev-of_node:
# look up using registerd of_phy_providers
phy = phy_get_of(...)
if phy: return phy
# now look up using whatever other mapping table exists
phy = ...
return phy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: GPMC updates
On 04/03/2013 04:40 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130402 10:00]: The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4: Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10 for you to fetch changes up to c67bd6e7cad2160c3bbfa2ac2bd954f918301c23: ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-01 14:53:50 -0500) Adds GPMC DT support for NOR flash and Ethernet and includes various GPMC cleans-up and fixes. This series is dependent on commit 7185684 (ARM: OMAP: use consistent error checking) from RMK's clean-up branch and commit 31d9adc (ARM: OMAP2+: Fix broken gpmc support). Looks good except it adds a new warning: arch/arm/mach-omap2/gpmc.c: In function ‘gpmc_read_timings_dt’: arch/arm/mach-omap2/gpmc.c:1324: warning: ‘p’ may be used uninitialized in this function Can you please take a look? No problem. I did not see get this warning, but I believe that there is a bug that needed to be fixed. Can you try the below? Jon The following changes since commit dca3a783400a18e2bf4503b1d4a85c4d0ca1a7e4: Merge commit '31d9adca82ce65e5c99d045b5fd917c702b6fce3' into tmp (2013-04-01 14:33:50 -0500) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-for-v3.10-take2 for you to fetch changes up to 5330dc161cb41e399e85d30e6908f1b93b956d1e: ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes (2013-04-03 20:13:42 -0500) Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check Javier Martinez Canillas (3): ARM: OMAP2+: return -ENODEV if GPMC child device creation fails ARM: OMAP2+: rename gpmc_probe_nor_child() to gpmc_probe_generic_child() ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes Jon Hunter (17): ARM: OMAP2+: Simplify code configuring ONENAND devices ARM: OMAP2+: Add variable to store number of GPMC waitpins ARM: OMAP2+: Add structure for storing GPMC settings ARM: OMAP2+: Add function for configuring GPMC settings ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings() ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings() ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure() ARM: OMAP2+: Add function to read GPMC settings from device-tree ARM: OMAP2+: Add additional GPMC timing parameters ARM: OMAP2+: Add device-tree support for NOR flash ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT ARM: OMAP2+: Detect incorrectly aligned GPMC base address ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails Mark Jackson (1): ARM: OMAP: Clear GPMC bits when applying new setting. Documentation/devicetree/bindings/bus/ti-gpmc.txt | 103 +++- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 .../devicetree/bindings/mtd/gpmc-onenand.txt |3 + Documentation/devicetree/bindings/net/gpmc-eth.txt | 97 arch/arm/mach-omap2/gpmc-nand.c| 42 +- arch/arm/mach-omap2/gpmc-onenand.c | 118 ++--- arch/arm/mach-omap2/gpmc-smc91x.c | 30 +- arch/arm/mach-omap2/gpmc.c | 544 ++-- arch/arm/mach-omap2/gpmc.h | 43 +- arch/arm/mach-omap2/usb-tusb6010.c | 62 ++- 10 files changed, 831 insertions(+), 309 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt -- 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
AM3517 DaVinci EMAC Ethernet performance issues
(( Attempting to re-post this since Yahoo! shipped the previous one as HTML... )) All, My team is presently seeing *extremely poor* (on the order of single-digit Mbps) Ethernet performance out of an AM3517-based COM (Technexion's TAM-3517 in this case) when it _transmits TCP_. Receiving TCP appears to happen fine, and our UDP transmit and receive appears pretty solid. Is anyone else seeing anything like this on an AM3517-based platform? (I have a CompuLab CM-T3517 that I'll try to get to by the end of this week for comparison.) I reported a similar, perhaps related, issue nearly a year ago at http://thread.gmane.org/gmane.linux.ports.arm.omap/78647 http://e2e.ti.com/support/arm/sitara_arm/f/416/t/195442.aspx, and never heard much in response. Though the performance of the EMAC port has never been stellar (others have admitted that), we've continued working with the COM because the network performance our tests were seeing at the time was more than adequate to our tasks at hand. Recently however, while testing our latest hardware we hit this nasty performance snag and that caused us to revisit this entirely. Frustratingly, these tests are showing that that performance now appears to be way worse than anything we previously saw, on both our custom hardware and dev. kit systems. The behavior is easily characterized using 'iperf'. If the TAM hosts the iperf server (i.e. receives TCP using 'iperf -s'), a client can connect to it and run ~90Mbps forever. That's perfect. If those roles are reversed however, and the TAM plays client (i.e. transmits TCP using 'iperf -i 10 -t 60 -c server_ip'), the data rate becomes sporadic and often plummets or even times out. Please see captures below. Although it misbehaves dramatically, the driver never registers a single error, xrun, nothing... *** EMAC running server (receiving TCP) *** $ iperf -i 10 -t 60 -c 10.22.0.17 Client connecting to 10.22.0.17, TCP port 5001 TCP window size: 23.5 KByte (default) [ 3] local 10.22.255.5 port 60936 connected with 10.22.0.17 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 113 MBytes 94.5 Mbits/sec [ 3] 10.0-20.0 sec 112 MBytes 94.3 Mbits/sec [ 3] 20.0-30.0 sec 112 MBytes 94.0 Mbits/sec [ 3] 30.0-40.0 sec 112 MBytes 94.2 Mbits/sec [ 3] 40.0-50.0 sec 112 MBytes 94.3 Mbits/sec [ 3] 50.0-60.0 sec 112 MBytes 94.0 Mbits/sec [ 3] 0.0-60.0 sec 674 MBytes 94.2 Mbits/sec *** EMAC running client (transmitting TCP) *** # iperf -i 10 -t 60 -c 10.22.255.5 Client connecting to 10.22.255.5, TCP port 5001 TCP window size: 19.6 KByte (default) [ 3] local 10.22.0.17 port 43185 connected with 10.22.255.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 92.5 MBytes 77.6 Mbits/sec [ 3] 10.0-20.0 sec 102 MBytes 85.3 Mbits/sec [ 3] 20.0-30.0 sec 98.6 MBytes 82.7 Mbits/sec [ 3] 30.0-40.0 sec 55.4 MBytes 46.5 Mbits/sec [ 3] 40.0-50.0 sec 2.73 MBytes 2.29 Mbits/sec [ 3] 50.0-60.0 sec 1.26 MBytes 1.06 Mbits/sec [ 3] 0.0-64.5 sec 352 MBytes 45.8 Mbits/sec Since discovering this behavior at the end of last week, I have systematically gone back through our generations of our custom carrier boards as well as the TAM's Twister dev kit and proven that the issue is now present on everything we have. Since the behavior appears to have changed since we last aggressively tested this nearly a year ago, I'm assuming a slight software alteration somewhere is largely to blame. So I walked back through all of my recorded boot logs and retried running our main previous kernels (l-o 3.4-rc6 and l-o 3.5-rc4) as well as older versions of the bootloaders. In every case, the problem has remained. The latest software we're running is still based on linux-omap's 3.5-rc4. We locked the kernel down there several months ago in order to stage for release, and until we discovered this last week it has been running _very_ stably. I have, however, continued to monitor the lists and major patch sites looking to see if any major bug fixes are released in the drivers we're using, etc. Since discovering this issue, I've also gone ahead and backported in many of the patches released by the folks I CC'd onto this message - at least those I could easily pull in without upgrading the kernel. Unless I'm overlooking something, it now looks to me like I have everything but the DT and OF stuff worked into our kernel. (I'm assuming that DT and OF stuff really does not impact performance. Is that a safe assumption?) Unfortunately, pulling in those changes has not corrected this issue. We've done network captures on our link, and the problem is very strange. The iperf client transmits data quickly and steadily for a while, but then all the sudden just stops. In the captures you can see an
