Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one
Hi On 09/24/2015 01:01 PM, Peter Ujfalusi wrote: > Hi, > > Changes since v3: > - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got > squashed > by accident for v3 > - Added Tony's Acked-by to patch 11 (for mach-oamp2 part) Gentle ping on this series ;) -- Péter > Changes since v2: > - devm_kasprintf format string fixed > - Additional patch to enable dynamic paRAM slot usage when the channel mapping > is supported by the eDMA module. > On am335x we have 256 paRAM slots and 64 DMA channels, this means that we > had > 64 slots 'locked away' all the time. The dynamic paRAM slot logic will allow > us to use all 256 slots freely for any purpose. > > Changes since v1: > - Convert edma platform device registration to use > platform_device_register_full > - Moved the PM callback also to the dmaengine driver - missed in v1 > - Commit message added to: > ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers > - New patch which reads the flag for the channel mapping support in one place > > Cover letter: > > with this series the edma two driver setup will be changed to have only one > driver to support eDMA3. The legacy edma interface will be removed and eDMA > can > only be used via dmaengine API from this point on. > In order to do the merge the following improvements has been done: > - One driver instance per eDMA: > - Any number of eDMA instances are supported (both legacy and DT boot) > - Not relying on global variables, arrays, etc > - Code simplification and optimizations in several places > > This change will also help us to do bigger changes in the eDMA driver since, > since now we have only one driver to work with. > > The series has been tested on: > da850-evm (OMAP-L138) > - with legacy and DT boot (both eDMA0 and eDMA1 is enabled) > - In code swapping the eDMA instances in legacy mode to make sure the second > instance is handled correctly. > > am335x-evmsk > - DT boot > > I think this series could go via the dmaengine tree. Changes are trivial under > arch/arm/ > > Regards, > Peter > --- > Peter Ujfalusi (25): > ARM: common: edma: Fix channel parameter for irq callbacks > ARM: common: edma: Remove unused functions > dmaengine: edma: Simplify and optimize the edma_execute path > ARM: davinci/common: Convert edma driver to handle one eDMA instance > per driver > ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine > driver > ARM: common: edma: Internal API to use pointer to 'struct edma' > ARM/dmaengine: edma: Public API to use private struct pointer > ARM/dmaengine: edma: Remove limitation on the number of eDMA > controllers > ARM: davinci: Use platform_device_register_full() to create pdev for > eDMA > ARM: davinci: Add dma_mask to eDMA devices > ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ > dmaengine: edma: Allocate memory dynamically for bitmaps and > structures > dmaengine: edma: Parameter alignment and long line fixes > dmaengine: edma: Use devm_kcalloc when possible > dmaengine: edma: Cleanup regarding the use of dev around the code > dmaengine: edma: Use dev_dbg instead pr_debug > dmaengine: edma: Use the edma_write_slot instead open coded > memcpy_toio > dmaengine: edma: Print warning when linking slots from different eDMA > dmaengine: edma: Consolidate the comments for functions > dmaengine: edma: Simplify the interrupt handling > dmaengine: edma: Move the pending error check into helper function > dmaengine: edma: Simplify and optimize ccerr interrupt handler > dmaengine: edma: Read channel mapping support only once from HW > dmaengine: edma: Rename bitfields for slot and channel usage tracking > dmaengine: edma: Dynamic paRAM slot handling if HW supports it > > arch/arm/Kconfig |1 - > arch/arm/common/Kconfig |3 - > arch/arm/common/Makefile |1 - > arch/arm/common/edma.c| 1876 > - > arch/arm/mach-davinci/devices-da8xx.c | 122 +-- > arch/arm/mach-davinci/dm355.c | 40 +- > arch/arm/mach-davinci/dm365.c | 25 +- > arch/arm/mach-davinci/dm644x.c| 40 +- > arch/arm/mach-davinci/dm646x.c| 44 +- > arch/arm/mach-omap2/Kconfig |1 - > drivers/dma/Kconfig |1 - > drivers/dma/edma.c| 1569 --- > include/linux/platform_data/edma.h| 101 -- > 13 files changed, 1523 insertions(+), 2301 deletions(-) > delete mode 100644 arch/arm/common/edma.c > -- To unsubscribe from this list: send the line "unsubscribe 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] pwm: tipwmss: enable on TI DRA7x and AM437x
On Monday 05 October 2015 08:50 PM, Thierry Reding wrote: > On Tue, Sep 08, 2015 at 08:44:05PM +0530, Sekhar Nori wrote: >> From: Vignesh R >> >> TIPWMSS is present on TI's DRA7x and >> AM437x SoCs. Enable its usage. >> >> Instead of adding each SoC individually, >> use the more generic ARCH_OMAP2PLUS >> instead. >> >> Signed-off-by: Vignesh R >> Signed-off-by: Sekhar Nori >> --- >> drivers/pwm/Kconfig | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > Applied, thanks. In the future, try to make use of the 78 columns. There > is no need to make lines as short as you did. Alright. 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: [PATCH] arm: omap2: timer: don't disable our timers
Hi, Sebastian Reichel writes: > On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote: >> We will gain a user from OMAP remoteproc driver as well (out of tree at >> the moment, but it does follow the DT phandle and >> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is >> converted to DT, and also some of the API are alive just because of the >> continued OMAP3 legacy boot support. Guess, it is a just a question of >> not breaking existing API until we kill some of them. > > Right, ir-rx51 has not yet been converted to DT. Additionally it > depends !ARCH_MULTIPLATFORM, since it requires . > > I remember a patchset adding a omap-pwm driver using dmtimers. If > that was added to the kernel, ir-rx51 could probably be switched to > the PWM API + hrtimer API instead of depending on the dmtimer API. > At the end not much is gained, though, since then the PWM driver > would probably require the dmtimer API. Tony has been talking about an HRTimer API for some time, but I guess it didn't happen yet. Until then, cleanups will have to continue to cope with legacy users. -- balbi signature.asc Description: PGP signature
Re: [PATCH] arm: omap2: timer: don't disable our timers
Suman Anna writes: > Hi Felipe, > >>> >>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote: We actually want these devices to be created because we will be moving timers to drivers/clocksource and this will prevent them from probing. >>> >>> This logic is also used to remove the secure timer from being >>> registered to the kernel on HS devices, while allowing the timer to be >>> available on GP devices. Your patch actually would break that >>> functionality. I suggest that you look at the history of the code that >> >> heh, that's a silly way of doing so. Could just detect if we're running >> on HS or not. > > This function is invoked only after detecting that we are running on a > HS device. What actually disables the timer is omap_get_timer_dt() and that's called in more than one place. >>> originally added this logic - this function seems to be designed to >>> actually remove the node. The OMAP DMTimer provides an API to request >>> timers, and I think this logic was used to eliminate giving out the >>> timers used for clocksource and clockevent when the driver got adapted >>> to DT. >> >> again not the best way of achieving what you want. In any case, other >> than ir-rx51.c who's using that API ? Seems like we could just pass a >> phandle to ir-rx51 and be done with it. > > We will gain a user from OMAP remoteproc driver as well (out of tree at > the moment, but it does follow the DT phandle and > omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is > converted to DT, and also some of the API are alive just because of the > continued OMAP3 legacy boot support. Guess, it is a just a question of > not breaking existing API until we kill some of them. sure, but until remoteproc gets upstream, it's only 1 user ;-) Signed-off-by: Felipe Balbi --- Tony, I wonder if you can get merged as a fix, or do you prefer receiving it together with my timer series ? >>> >>> NAK for rc, as it breaks other stuff. >> >> a single stuff which is likely easy enough to fix. But fair enough > > Don't think this patch is fixing any critical bug either, better to club > it with your cleanup series. it is kinda critical when you consider that the timer is disabled outside of the soc type detection. -- balbi signature.asc Description: PGP signature
Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node
Suman Anna writes:
> Add the DT node for Timer12 present on DRA7 family of
> SoCs. Timer12 is present in PD_WKUPAON power domain, and
> has the same capabilities as the other timers, except for
> the fact that it serves as a secure timer on HS devices
> and is clocked only from the secure 32K clock.
>
> The node is marked disabled for now, and the kernel should
> refrain from using this secure timer on HS devices.
>
> Signed-off-by: Suman Anna
> ---
> arch/arm/boot/dts/dra7.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..37d632dad576 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -762,6 +762,16 @@
> ti,hwmods = "timer11";
> };
>
> + timer12: timer@4ae2 {
> + compatible = "ti,omap5430-timer";
> + reg = <0x4ae2 0x80>;
> + interrupts = ;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + status = "disabled";
according to Tony we should avoid using status at all for in-SoC
devices.
Tony, can you confirm I understood you correctly ?
--
balbi
signature.asc
Description: PGP signature
[PATCH v2] arm: omap2: timer: don't disable our timers
We actually want these devices to be created because
we will be moving timers to drivers/clocksource and
this will prevent them from probing.
The only situation where we want secure timers to be
actually disabled is when we *know* we're running on
non-GP (read: HS or EMU) chips, because the secure
timer will NOT be available for the public world.
This patch is just moving the call to of_add_property
to its rightful place.
Signed-off-by: Felipe Balbi
---
Okay, seems like this is a saner approach.
changes since v1:
- don't completely remove the status disabled trick, just limit it to
non-GP chips
arch/arm/mach-omap2/timer.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0ff676273b4b..0bd3ee4552de 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -161,9 +161,7 @@ static const struct of_device_id omap_timer_match[]
__initconst = {
*
* Helper function to get a timer during early boot using device-tree for use
* as kernel system timer. Optionally, the property argument can be used to
- * select a timer with a specific property. Once a timer is found then mark
- * the timer node in device-tree as disabled, to prevent the kernel from
- * registering this timer as a platform device and so no one else can use it.
+ * select a timer with a specific property.
*/
static struct device_node * __init omap_get_timer_dt(const struct of_device_id
*match,
const char *property)
@@ -182,8 +180,6 @@ static struct device_node * __init omap_get_timer_dt(const
struct of_device_id *
of_get_property(np, "ti,timer-pwm", NULL) ||
of_get_property(np, "ti,timer-secure", NULL)))
continue;
-
- of_add_property(np, &device_disabled);
return np;
}
@@ -208,7 +204,10 @@ static void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
- of_node_put(np);
+ if (np) {
+ of_add_property(np, &device_disabled);
+ of_node_put(np);
+ }
}
}
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: timer: don't disable our timers
Hi, On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote: > We will gain a user from OMAP remoteproc driver as well (out of tree at > the moment, but it does follow the DT phandle and > omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is > converted to DT, and also some of the API are alive just because of the > continued OMAP3 legacy boot support. Guess, it is a just a question of > not breaking existing API until we kill some of them. Right, ir-rx51 has not yet been converted to DT. Additionally it depends !ARCH_MULTIPLATFORM, since it requires . I remember a patchset adding a omap-pwm driver using dmtimers. If that was added to the kernel, ir-rx51 could probably be switched to the PWM API + hrtimer API instead of depending on the dmtimer API. At the end not much is gained, though, since then the PWM driver would probably require the dmtimer API. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] arm: omap2: timer: don't disable our timers
Hi Felipe, >> >> On 10/05/2015 02:48 PM, Balbi, Felipe wrote: >>> We actually want these devices to be created because >>> we will be moving timers to drivers/clocksource and >>> this will prevent them from probing. >> >> This logic is also used to remove the secure timer from being >> registered to the kernel on HS devices, while allowing the timer to be >> available on GP devices. Your patch actually would break that >> functionality. I suggest that you look at the history of the code that > > heh, that's a silly way of doing so. Could just detect if we're running > on HS or not. This function is invoked only after detecting that we are running on a HS device. > >> originally added this logic - this function seems to be designed to >> actually remove the node. The OMAP DMTimer provides an API to request >> timers, and I think this logic was used to eliminate giving out the >> timers used for clocksource and clockevent when the driver got adapted >> to DT. > > again not the best way of achieving what you want. In any case, other > than ir-rx51.c who's using that API ? Seems like we could just pass a > phandle to ir-rx51 and be done with it. We will gain a user from OMAP remoteproc driver as well (out of tree at the moment, but it does follow the DT phandle and omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is converted to DT, and also some of the API are alive just because of the continued OMAP3 legacy boot support. Guess, it is a just a question of not breaking existing API until we kill some of them. > >>> Signed-off-by: Felipe Balbi >>> --- >>> >>> Tony, I wonder if you can get merged as a fix, or do you >>> prefer receiving it together with my timer series ? >> >> NAK for rc, as it breaks other stuff. > > a single stuff which is likely easy enough to fix. But fair enough Don't think this patch is fixing any critical bug either, better to club it with your cleanup series. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node
Add the DT node for Timer12 present on DRA7 family of
SoCs. Timer12 is present in PD_WKUPAON power domain, and
has the same capabilities as the other timers, except for
the fact that it serves as a secure timer on HS devices
and is clocked only from the secure 32K clock.
The node is marked disabled for now, and the kernel should
refrain from using this secure timer on HS devices.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/dra7.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e289c706d27d..37d632dad576 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -762,6 +762,16 @@
ti,hwmods = "timer11";
};
+ timer12: timer@4ae2 {
+ compatible = "ti,omap5430-timer";
+ reg = <0x4ae2 0x80>;
+ interrupts = ;
+ ti,hwmods = "timer12";
+ ti,timer-alwon;
+ ti,timer-secure;
+ status = "disabled";
+ };
+
timer13: timer@48828000 {
compatible = "ti,omap5430-timer";
reg = <0x48828000 0x80>;
--
2.6.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
[PATCH v2 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
The omap_dm_timer_set_source() function provides a means for client
users to configure the mux parent for a GPTimer's functional clock.
However, not all timers are configurable (Eg: Timer12 on DRA7 is fed
by an internal 32k oscillator clock, and does not have configurable
parent clocks). So, check for such cases and proceed with out throwing
an error.
Signed-off-by: Suman Anna
---
arch/arm/plat-omap/dmtimer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d379bc3..4c48b52c4a7c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -36,6 +36,7 @@
*/
#include
+#include
#include
#include
#include
@@ -504,6 +505,12 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (IS_ERR(timer->fclk))
return -EINVAL;
+#if defined(CONFIG_COMMON_CLK)
+ /* Check if the clock has configurable parents */
+ if (clk_hw_get_num_parents(__clk_get_hw(timer->fclk)) < 2)
+ return 0;
+#endif
+
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
parent_name = "timer_sys_ck";
--
2.6.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
[PATCH v2 0/4] DRA7 Timer12 Support
Hi Tony, This is a revised version of the DRA7 Timer12 support patch series [1]. The series mainly is respun to fix a build issue caused by Patch1 [2] with omap1_defconfig due to the absence of Common Clock framework for OMAP1. Only Patch 1 is modified from the previous series. I have also revised the check slightly to fix another issue seen when requesting Timer12 on OMAP3, as that is a fixed clock and does return back with a parent count of 1. Series baselined on v4.3-rc3 just like the original series, and tested on all generations (AMx3x, OMAP4, OMAP5 and DRA7) except OMAP1 and OMAP2 generations. regards Suman [1] http://marc.info/?l=linux-omap&m=144372799601354&w=2 [2] https://patchwork.kernel.org/patch/7311021/ Suman Anna (4): ARM: OMAP: dmtimer: check for fixed timers during config ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices ARM: dts: DRA7: Add timer12 node ARM: DRA7: hwmod: Add data for GPTimer 12 arch/arm/boot/dts/dra7.dtsi | 10 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- arch/arm/mach-omap2/timer.c | 6 +++--- arch/arm/plat-omap/dmtimer.c | 7 ++ 4 files changed, 54 insertions(+), 5 deletions(-) -- 2.6.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
[PATCH v2 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP) devices. This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f102
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/timer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a55655127ef2..1e346aa0a687 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -193,8 +193,8 @@ static struct device_node * __init omap_get_timer_dt(const
struct of_device_id *
/**
* omap_dmtimer_init - initialisation function when device tree is used
*
- * For secure OMAP3 devices, timers with device type "timer-secure" cannot
- * be used by the kernel as they are reserved. Therefore, to prevent the
+ * For secure OMAP3/DRA7xx devices, timers with device type "timer-secure"
+ * cannot be used by the kernel as they are reserved. Therefore, to prevent the
* kernel registering these devices remove them dynamically from the device
* tree on boot.
*/
@@ -202,7 +202,7 @@ static void __init omap_dmtimer_init(void)
{
struct device_node *np;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() && !soc_is_dra7xx())
return;
/* If we are a secure device, remove any secure timer nodes */
--
2.6.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
[PATCH v2 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12
Add the hwmod data for GPTimer 12. GPTimer 12 is present in
WKUPAON power domain and is clocked from a secure 32K clock.
GPTimer 12 serves as a secure timer on HS devices, but is
available for kernel on regular GP devices.
The hwmod link is registered only on GP devices. The hwmod data
also reused the existing timer class instead of reintroducing
the identical dra7xx_timer_secure_sysc class which was dropped
in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class
for GPTimer4").
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..37a10f87fbcd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = {
},
};
+/* timer12 */
+static struct omap_hwmod dra7xx_timer12_hwmod = {
+ .name = "timer12",
+ .class = &dra7xx_timer_hwmod_class,
+ .clkdm_name = "wkupaon_clkdm",
+ .main_clk = "secure_32k_clk_src_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET,
+ },
+ },
+};
+
/* timer13 */
static struct omap_hwmod dra7xx_timer13_hwmod = {
.name = "timer13",
@@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup -> timer12 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = {
+ .master = &dra7xx_l4_wkup_hwmod,
+ .slave = &dra7xx_timer12_hwmod,
+ .clk= "wkupaon_iclk_mux",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_per3 -> timer13 */
static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = {
.master = &dra7xx_l4_per3_hwmod,
@@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
NULL,
};
+/* GP-only hwmod links */
+static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
+ &dra7xx_l4_wkup__timer12,
+ NULL,
+};
+
+/* SoC variant specific hwmod links */
static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l4_per3__usb_otg_ss4,
NULL,
@@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void)
ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
if (!ret && soc_is_dra74x())
- return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
+ ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
else if (!ret && soc_is_dra72x())
- return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+ ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+
+ if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
+ ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
return ret;
}
--
2.6.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] arm: omap2: timer: don't disable our timers
Suman Anna writes: > Hi Felipe, > > On 10/05/2015 02:48 PM, Balbi, Felipe wrote: >> We actually want these devices to be created because >> we will be moving timers to drivers/clocksource and >> this will prevent them from probing. > > This logic is also used to remove the secure timer from being > registered to the kernel on HS devices, while allowing the timer to be > available on GP devices. Your patch actually would break that > functionality. I suggest that you look at the history of the code that heh, that's a silly way of doing so. Could just detect if we're running on HS or not. > originally added this logic - this function seems to be designed to > actually remove the node. The OMAP DMTimer provides an API to request > timers, and I think this logic was used to eliminate giving out the > timers used for clocksource and clockevent when the driver got adapted > to DT. again not the best way of achieving what you want. In any case, other than ir-rx51.c who's using that API ? Seems like we could just pass a phandle to ir-rx51 and be done with it. >> Signed-off-by: Felipe Balbi >> --- >> >> Tony, I wonder if you can get merged as a fix, or do you >> prefer receiving it together with my timer series ? > > NAK for rc, as it breaks other stuff. a single stuff which is likely easy enough to fix. But fair enough -- balbi signature.asc Description: PGP signature
Re: [PATCH] arm: omap2: timer: don't disable our timers
Hi Felipe,
On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
> We actually want these devices to be created because
> we will be moving timers to drivers/clocksource and
> this will prevent them from probing.
This logic is also used to remove the secure timer from being
registered to the kernel on HS devices, while allowing the timer to be
available on GP devices. Your patch actually would break that
functionality. I suggest that you look at the history of the code that
originally added this logic - this function seems to be designed to
actually remove the node. The OMAP DMTimer provides an API to request
timers, and I think this logic was used to eliminate giving out the
timers used for clocksource and clockevent when the driver got adapted
to DT.
>
> Signed-off-by: Felipe Balbi
> ---
>
> Tony, I wonder if you can get merged as a fix, or do you
> prefer receiving it together with my timer series ?
NAK for rc, as it breaks other stuff.
regards
Suman
>
> arch/arm/mach-omap2/timer.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 0ff676273b4b..0c00138d7bd5 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -136,12 +136,6 @@ static struct clock_event_device clockevent_gpt = {
> .tick_resume= omap2_gp_timer_shutdown,
> };
>
> -static struct property device_disabled = {
> - .name = "status",
> - .length = sizeof("disabled"),
> - .value = "disabled",
> -};
> -
> static const struct of_device_id omap_timer_match[] __initconst = {
> { .compatible = "ti,omap2420-timer", },
> { .compatible = "ti,omap3430-timer", },
> @@ -161,9 +155,7 @@ static const struct of_device_id omap_timer_match[]
> __initconst = {
> *
> * Helper function to get a timer during early boot using device-tree for use
> * as kernel system timer. Optionally, the property argument can be used to
> - * select a timer with a specific property. Once a timer is found then mark
> - * the timer node in device-tree as disabled, to prevent the kernel from
> - * registering this timer as a platform device and so no one else can use it.
> + * select a timer with a specific property.
> */
> static struct device_node * __init omap_get_timer_dt(const struct
> of_device_id *match,
>const char *property)
> @@ -183,7 +175,6 @@ static struct device_node * __init
> omap_get_timer_dt(const struct of_device_id *
> of_get_property(np, "ti,timer-secure", NULL)))
> continue;
>
> - of_add_property(np, &device_disabled);
> return np;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe 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/4] Allow USB devices to remain runtime-suspended when sleeping
On 5 October 2015 at 16:45, Tomeu Vizoso wrote: > Hi, > > this is v9 of an attempt to make it easier for devices to remain in > runtime PM when the system goes to sleep, mainly to reduce the time > spent resuming devices. > > For this, we interpret the absence of all PM callback implementations as > it being safe to do direct_complete, so their ancestors aren't prevented > from remaining runtime-suspended. > > Additionally, the prepare() callback of USB devices will return 1 if > runtime PM is enabled and the current wakeup settings are correct. > > With these changes, a uvcvideo device (for example) stays in runtime > suspend when the system goes to sleep and is left in that state when the > system resumes, not delaying it unnecessarily. > > Thanks, > > Tomeu > > Changes in v9: > - Add docs noting the need for the device lock to be held before calling > device_is_bound() > - Add docs noting the need for the device lock to be held before calling > dev_pm_domain_set() > - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. > - Rename from device_check_pm_callbacks to device_pm_check_callbacks to > follow with the naming convention of existing API. > - Re-add calling to device_pm_check_callbacks from device registration > and when updating the PM domain of a device. > > Changes in v8: > - Add device_is_bound() > - Add dev_pm_domain_set() and update code to use it > - Move no_pm_callbacks field into CONFIG_PM_SLEEP > - Call device_check_pm_callbacks only after a device is bound or unbound > > Changes in v7: > - Reduce indentation by adding a label in device_prepare() > > Changes in v6: > - Add stub for !CONFIG_PM. > - Move implementation of device_check_pm_callbacks to power/main.c as it > doesn't belong to CONFIG_PM_SLEEP. > - Take dev->power.lock before modifying flag. > > Changes in v5: > - Check for all dev_pm_ops instances associated to a device, updating a > no_pm_callbacks flag at the times when that could change. > > Tomeu Vizoso (4): > device core: add device_is_bound() > PM / Domains: add setter for dev.pm_domain > PM / sleep: Go direct_complete if driver has no callbacks > USB / PM: Allow USB devices to remain runtime-suspended when sleeping > > arch/arm/mach-omap2/omap_device.c | 7 --- > drivers/acpi/acpi_lpss.c | 5 +++-- > drivers/acpi/device_pm.c | 5 +++-- > drivers/base/dd.c | 21 +++-- > drivers/base/power/clock_ops.c| 5 +++-- > drivers/base/power/common.c | 24 > drivers/base/power/domain.c | 6 -- > drivers/base/power/main.c | 35 +++ > drivers/base/power/power.h| 3 +++ > drivers/gpu/vga/vga_switcheroo.c | 10 +- > drivers/misc/mei/pci-me.c | 5 +++-- > drivers/misc/mei/pci-txe.c| 5 +++-- > drivers/usb/core/port.c | 6 ++ > drivers/usb/core/usb.c| 11 ++- > include/linux/device.h| 2 ++ > include/linux/pm.h| 1 + > include/linux/pm_domain.h | 3 +++ > 17 files changed, 131 insertions(+), 23 deletions(-) > > -- > 2.4.3 > This looks good to me, for the series you may add: Reviewed-by: Ulf Hansson Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe 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/4] Allow USB devices to remain runtime-suspended when sleeping
On Monday, October 05, 2015 04:45:28 PM Tomeu Vizoso wrote: > Hi, > > this is v9 of an attempt to make it easier for devices to remain in > runtime PM when the system goes to sleep, mainly to reduce the time > spent resuming devices. > > For this, we interpret the absence of all PM callback implementations as > it being safe to do direct_complete, so their ancestors aren't prevented > from remaining runtime-suspended. > > Additionally, the prepare() callback of USB devices will return 1 if > runtime PM is enabled and the current wakeup settings are correct. > > With these changes, a uvcvideo device (for example) stays in runtime > suspend when the system goes to sleep and is left in that state when the > system resumes, not delaying it unnecessarily. > > Thanks, > > Tomeu > > Changes in v9: > - Add docs noting the need for the device lock to be held before calling > device_is_bound() > - Add docs noting the need for the device lock to be held before calling > dev_pm_domain_set() > - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. > - Rename from device_check_pm_callbacks to device_pm_check_callbacks to > follow with the naming convention of existing API. > - Re-add calling to device_pm_check_callbacks from device registration > and when updating the PM domain of a device. > > Changes in v8: > - Add device_is_bound() > - Add dev_pm_domain_set() and update code to use it > - Move no_pm_callbacks field into CONFIG_PM_SLEEP > - Call device_check_pm_callbacks only after a device is bound or unbound > > Changes in v7: > - Reduce indentation by adding a label in device_prepare() > > Changes in v6: > - Add stub for !CONFIG_PM. > - Move implementation of device_check_pm_callbacks to power/main.c as it > doesn't belong to CONFIG_PM_SLEEP. > - Take dev->power.lock before modifying flag. > > Changes in v5: > - Check for all dev_pm_ops instances associated to a device, updating a > no_pm_callbacks flag at the times when that could change. > > Tomeu Vizoso (4): > device core: add device_is_bound() > PM / Domains: add setter for dev.pm_domain > PM / sleep: Go direct_complete if driver has no callbacks > USB / PM: Allow USB devices to remain runtime-suspended when sleeping > > arch/arm/mach-omap2/omap_device.c | 7 --- > drivers/acpi/acpi_lpss.c | 5 +++-- > drivers/acpi/device_pm.c | 5 +++-- > drivers/base/dd.c | 21 +++-- > drivers/base/power/clock_ops.c| 5 +++-- > drivers/base/power/common.c | 24 > drivers/base/power/domain.c | 6 -- > drivers/base/power/main.c | 35 +++ > drivers/base/power/power.h| 3 +++ > drivers/gpu/vga/vga_switcheroo.c | 10 +- > drivers/misc/mei/pci-me.c | 5 +++-- > drivers/misc/mei/pci-txe.c| 5 +++-- > drivers/usb/core/port.c | 6 ++ > drivers/usb/core/usb.c| 11 ++- > include/linux/device.h| 2 ++ > include/linux/pm.h| 1 + > include/linux/pm_domain.h | 3 +++ > 17 files changed, 131 insertions(+), 23 deletions(-) The series looks good to me now, but patch [4/4] needs an ACK from the USB maintainers and patch [1/4] needs an ACK from Greg. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2: timer: don't disable our timers
We actually want these devices to be created because
we will be moving timers to drivers/clocksource and
this will prevent them from probing.
Signed-off-by: Felipe Balbi
---
Tony, I wonder if you can get merged as a fix, or do you
prefer receiving it together with my timer series ?
arch/arm/mach-omap2/timer.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0ff676273b4b..0c00138d7bd5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -136,12 +136,6 @@ static struct clock_event_device clockevent_gpt = {
.tick_resume= omap2_gp_timer_shutdown,
};
-static struct property device_disabled = {
- .name = "status",
- .length = sizeof("disabled"),
- .value = "disabled",
-};
-
static const struct of_device_id omap_timer_match[] __initconst = {
{ .compatible = "ti,omap2420-timer", },
{ .compatible = "ti,omap3430-timer", },
@@ -161,9 +155,7 @@ static const struct of_device_id omap_timer_match[]
__initconst = {
*
* Helper function to get a timer during early boot using device-tree for use
* as kernel system timer. Optionally, the property argument can be used to
- * select a timer with a specific property. Once a timer is found then mark
- * the timer node in device-tree as disabled, to prevent the kernel from
- * registering this timer as a platform device and so no one else can use it.
+ * select a timer with a specific property.
*/
static struct device_node * __init omap_get_timer_dt(const struct of_device_id
*match,
const char *property)
@@ -183,7 +175,6 @@ static struct device_node * __init omap_get_timer_dt(const
struct of_device_id *
of_get_property(np, "ti,timer-secure", NULL)))
continue;
- of_add_property(np, &device_disabled);
return np;
}
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter
Felipe Balbi writes:
> On Wed, Sep 30, 2015 at 11:58:16PM +0200, Arnd Bergmann wrote:
>> On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote:
>> > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote:
>> > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote:
>> > > > All devices should have a default status. Ignoring
>> > > > the arguments if it should be 'okay' or 'disabled'
>> > > > by default, let's set them all the 'disabled' and
>> > > > have boards enable 32k counter.
>> > > >
>> > > > Signed-off-by: Felipe Balbi
>> > > >
>> > >
>> > > The patch looks good, but the description is slightly incorrect:
>> > > There is no reason to list "status='okay'" other than overriding
>> > > the 'disabled' status.
>> > >
>> > > I'd phrase it something like:
>> > >
>> > > "We want the use of the 32k counter to be a per-board setting,
>> > > so let's disable it by default in each dtsi file and override the
>> > > setting in the boards. Any board that does not wire up the counter
>> > > should leave it disabled".
>> > >
>> > > However, if you really want all boards to provide the counter all
>> > > the time, I'd argue that we're better off dropping this patch. We
>> > > use the status="disabled" trick for anything that may or may not
>> > > be working based on the board design, but things that are present
>> > > everywhere don't need this.
>> >
>> > okay, so here's the thing. While fiddling with the 32k counter, I noticed
>> > that even though there was no status listed, the thing still initializes
>> > fine. However, when moving 32k to drivers/clocksource and using
>> > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit
>> > status = "okay" in DT.
>>
>> Very strange, that sounds like a bug in the clocksource probe code.
>> Can you check how this happens?
>
> seems like something overwrites counter's status field, here's a snippet of
> boot
> log:
>
> [0.00] ===> counter is available ??
> [0.00] ===> no status -> TRUE!!
> [0.00] ===> searching for timer
> [0.00] ===> timer is available ??
> [0.00] ===> no status -> TRUE!!
> [0.05] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every
> 4398046511103ns
> [0.14] clocksource: arm_global_timer: mask: 0x
> max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [0.47] ===> searching for timer
> [0.51] ===> timer is available ??
> [0.54] ===> no status -> TRUE!!
> [0.000307] ===> searching for counter
> [0.000311] ===> counter is available ??
> [0.000315] ===> counter status disabled
> [0.000318] > counter NOT available
>
> note that first time around counter had no status and later it got a status
> disabled from somewhere.
found it. arch/arm/mach-omap2/timer.c is the culprit:
/**
* omap_get_timer_dt - get a timer using device-tree
* @match - device-tree match structure for matching a device type
* @property- optional timer property to match
*
* Helper function to get a timer during early boot using device-tree for use
* as kernel system timer. Optionally, the property argument can be used to
* select a timer with a specific property. Once a timer is found then mark
* the timer node in device-tree as disabled, to prevent the kernel from
* registering this timer as a platform device and so no one else can use it.
*/
static struct device_node * __init omap_get_timer_dt(const struct of_device_id
*match,
const char *property)
{
struct device_node *np;
for_each_matching_node(np, match) {
if (!of_device_is_available(np))
continue;
if (property && !of_get_property(np, property, NULL))
continue;
if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
of_get_property(np, "ti,timer-dsp", NULL) ||
of_get_property(np, "ti,timer-pwm", NULL) ||
of_get_property(np, "ti,timer-secure", NULL)))
continue;
of_add_property(np, &device_disabled);
return np;
}
return NULL;
}
I'll patch this up and drop $subject
--
balbi
signature.asc
Description: PGP signature
Re: All OMAP platforms: MMC is broken
On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [151005 07:57]:
> > * Tony Lindgren [151005 07:44]:
> > > * Tony Lindgren [151005 04:28]:
> > >
> > > Based on some tests it seems that the duovero unpaired regulator usage
> > > is fixed by reverting:
> > >
> > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > > find pbias status")
> >
> > With commit c55d7a055364 my guess is that the PBIAS regulator is
> > already on from an earlier MMC probe and getting re-enabled when
> > a deferred probe happens?
>
> Unless somebody has a better fix in mind for the above, I suggest
> we revert it for the -rc kernel.
Let me try reverting that in my build tree, and...
> > > And it seems that omap3 legacy MMC is broken earlier in the
> > > series with:
> > >
> > > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > > devm_regulator_get_optional() for vmmc")
> > >
> > > This one does not cleanly revert so have not yet tried reverting
> > > it.
> >
> > And with commit 7d607f917008 I'm guessing we can't return an
> > error if the PBIAS regulator does not exist as that's not there
> > for the legacy booting.
>
> For omap3 legacy booting, we keep getting -EPROBE_DEFER for
> all the optional regulators.
>
> Something like the following might be the minimal fix for the -rc
> cycle?
applying this patch. If that gets things going again, then we
_definitely_ should get both of these to Linus ASAP. The breakage
has been around far too long already.
> 8<
> From: Tony Lindgren
> Date: Mon, 5 Oct 2015 09:37:36 -0700
> Subject: [PATCH] mmc: host: omap_hsmmc: Fix MMC for omap3 legacy booting
>
> Starting with commit 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working
> for legacy booting.
>
> This is because legacy booting sets up some of the resource in the
> platform init code, and for optional regulators always seem to
> return -EPROBE_DEFER for the legacy booting.
>
> Let's fix the issue by checking for device tree based booting for
> now. Then when omap3 boots in device tree only mode, this patch
> can be just reverted.
>
> Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc")
> Signed-off-by: Tony Lindgren
>
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -478,7 +478,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> mmc->supply.vmmc = devm_regulator_get_optional(host->dev, "vmmc");
> if (IS_ERR(mmc->supply.vmmc)) {
> ret = PTR_ERR(mmc->supply.vmmc);
> - if (ret != -ENODEV)
> + if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
> PTR_ERR(mmc->supply.vmmc));
> @@ -493,7 +493,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> mmc->supply.vqmmc = devm_regulator_get_optional(host->dev, "vmmc_aux");
> if (IS_ERR(mmc->supply.vqmmc)) {
> ret = PTR_ERR(mmc->supply.vqmmc);
> - if (ret != -ENODEV)
> + if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get vmmc_aux regulator %ld\n",
> PTR_ERR(mmc->supply.vqmmc));
> @@ -503,7 +503,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> host->pbias = devm_regulator_get_optional(host->dev, "pbias");
> if (IS_ERR(host->pbias)) {
> ret = PTR_ERR(host->pbias);
> - if (ret != -ENODEV)
> + if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get pbias regulator %ld\n",
> PTR_ERR(host->pbias));
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
On 10/05/2015 11:58 AM, Tony Lindgren wrote: > * Suman Anna [151005 09:47]: >> Tony, >> >> On 10/03/2015 12:29 PM, kbuild test robot wrote: >>> Hi Suman, >>> >>> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please >>> ignore] >>> >>> config: arm-omap1_defconfig (attached as .config) >>> reproduce: >>> wget >>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >>> -O ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> # save the attached .config to linux build tree >>> make.cross ARCH=arm >>> >>> All error/warnings (new ones prefixed by >>): >>> >>>arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source': > arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of > function 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration] >>> if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >>> ^ > arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of > function '__clk_get_hw' [-Werror=implicit-function-declaration] >>>cc1: some warnings being treated as errors >>> >>> vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c >>> >>>503 return pdata->set_timer_src(timer->pdev, >>> source); >>>504 >>>505 if (IS_ERR(timer->fclk)) >>>506 return -EINVAL; >>>507 >>>508 /* Check if the clock has parents if not no point >>> checking */ >>> > 509 if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >>>510 return 0; >> >> CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose >> this within #ifdef CONFIG_COMMON_CLK? > > Yes, or maybe you can just clk_get_rate() on the 32k oscillator? > > Boards with no 32k oscillator should set the rate for that 0 zero. Well, this API is about setting the timer clk's mux source, and not really dealing with the clk rate or just setting it to the 32k oscillator. A 32k is usually one of the mux parents (if the timer has them). If there is a way to find if the clk is a mux clock, then that check would be ideal. But since no such thing exists, so I will go ahead and fix this by adding the #ifdef check. regards Suman -- To unsubscribe from this list: send the line "unsubscribe 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 11/11] arm: boot: dts: omap: add missing default status for 32k counter
On Wed, Sep 30, 2015 at 11:58:16PM +0200, Arnd Bergmann wrote: > On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote: > > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: > > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > > > > All devices should have a default status. Ignoring > > > > the arguments if it should be 'okay' or 'disabled' > > > > by default, let's set them all the 'disabled' and > > > > have boards enable 32k counter. > > > > > > > > Signed-off-by: Felipe Balbi > > > > > > > > > > The patch looks good, but the description is slightly incorrect: > > > There is no reason to list "status='okay'" other than overriding > > > the 'disabled' status. > > > > > > I'd phrase it something like: > > > > > > "We want the use of the 32k counter to be a per-board setting, > > > so let's disable it by default in each dtsi file and override the > > > setting in the boards. Any board that does not wire up the counter > > > should leave it disabled". > > > > > > However, if you really want all boards to provide the counter all > > > the time, I'd argue that we're better off dropping this patch. We > > > use the status="disabled" trick for anything that may or may not > > > be working based on the board design, but things that are present > > > everywhere don't need this. > > > > okay, so here's the thing. While fiddling with the 32k counter, I noticed > > that even though there was no status listed, the thing still initializes > > fine. However, when moving 32k to drivers/clocksource and using > > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit > > status = "okay" in DT. > > Very strange, that sounds like a bug in the clocksource probe code. > Can you check how this happens? seems like something overwrites counter's status field, here's a snippet of boot log: [0.00] ===> counter is available ?? [0.00] ===> no status -> TRUE!! [0.00] ===> searching for timer [0.00] ===> timer is available ?? [0.00] ===> no status -> TRUE!! [0.05] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every 4398046511103ns [0.14] clocksource: arm_global_timer: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.47] ===> searching for timer [0.51] ===> timer is available ?? [0.54] ===> no status -> TRUE!! [0.000307] ===> searching for counter [0.000311] ===> counter is available ?? [0.000315] ===> counter status disabled [0.000318] > counter NOT available note that first time around counter had no status and later it got a status disabled from somewhere. -- balbi signature.asc Description: PGP signature
Re: [PATCH] clk: ti: fix dual-registration of uart4_ick
* Tero Kristo [151005 05:39]:
> On 10/05/2015 01:17 PM, Tony Lindgren wrote:
> >* Ben Dooks [150929 06:14]:
> >>On 25/09/15 06:42, Tero Kristo wrote:
> >>>On 09/23/2015 08:30 PM, Tony Lindgren wrote:
> * Ben Dooks [150923 07:53]:
> >On the OMAP AM3517 platform the uart4_ick gets registered
> >twice, causing any power managment to /dev/ttyO3 to fail
> >when trying to wake the device up.
> >
> >This solves the following oops:
> >
> >[] Unhandled fault: external abort on non-linefetch (0x1028) at
> >0xfa09e008
> >[] PC is at serial_omap_pm+0x48/0x15c
> >[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
>
> No uart4 on 34xx/35xx, that got introduced with 36xx so:
>
> Acked-by: Tony Lindgren
>
> >Signed-off-by: Ben Dooks
> >---
> > drivers/clk/ti/clk-3xxx.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> >index 5e12f32..2e7ef1f 100644
> >--- a/drivers/clk/ti/clk-3xxx.c
> >+++ b/drivers/clk/ti/clk-3xxx.c
> >@@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
> > DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
> > DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
> > DT_CLK(NULL, "uart3_ick", "uart3_ick"),
> >-DT_CLK(NULL, "uart4_ick", "uart4_ick"),
> > DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
> > DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
> > DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
> >>>
> >>>NAK.
> >>>
> >>>This patch is actually only partially correct, it removes the uart4_ick
> >>>alias for omap36xx also. It should be added back to the omap36xx clks
> >>>array. Care to post a v2?
> >>
> >>Thankyou for the feedback. I'll update, but do not have a device to test.
> >
> >Hmm but isn't that entry already there for 36xx? So this just removes
> >a duplicate for 36xx.. Tero, can you please check again, maybe I'm
> >confused.
>
> uart4_ick wasn't there, we only had uart4_fck listed for omap36xx.
OK thanks for checking.
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: All OMAP platforms: MMC is broken
* Tony Lindgren [151005 07:57]:
> * Tony Lindgren [151005 07:44]:
> > * Tony Lindgren [151005 04:28]:
> >
> > Based on some tests it seems that the duovero unpaired regulator usage
> > is fixed by reverting:
> >
> > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> > find pbias status")
>
> With commit c55d7a055364 my guess is that the PBIAS regulator is
> already on from an earlier MMC probe and getting re-enabled when
> a deferred probe happens?
Unless somebody has a better fix in mind for the above, I suggest
we revert it for the -rc kernel.
> > And it seems that omap3 legacy MMC is broken earlier in the
> > series with:
> >
> > 7d607f917008 ("mmc: host: omap_hsmmc: use
> > devm_regulator_get_optional() for vmmc")
> >
> > This one does not cleanly revert so have not yet tried reverting
> > it.
>
> And with commit 7d607f917008 I'm guessing we can't return an
> error if the PBIAS regulator does not exist as that's not there
> for the legacy booting.
For omap3 legacy booting, we keep getting -EPROBE_DEFER for
all the optional regulators.
Something like the following might be the minimal fix for the -rc
cycle?
Regards,
Tony
8<
From: Tony Lindgren
Date: Mon, 5 Oct 2015 09:37:36 -0700
Subject: [PATCH] mmc: host: omap_hsmmc: Fix MMC for omap3 legacy booting
Starting with commit 7d607f917008 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working
for legacy booting.
This is because legacy booting sets up some of the resource in the
platform init code, and for optional regulators always seem to
return -EPROBE_DEFER for the legacy booting.
Let's fix the issue by checking for device tree based booting for
now. Then when omap3 boots in device tree only mode, this patch
can be just reverted.
Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Signed-off-by: Tony Lindgren
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -478,7 +478,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
mmc->supply.vmmc = devm_regulator_get_optional(host->dev, "vmmc");
if (IS_ERR(mmc->supply.vmmc)) {
ret = PTR_ERR(mmc->supply.vmmc);
- if (ret != -ENODEV)
+ if ((ret != -ENODEV) && host->dev->of_node)
return ret;
dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
PTR_ERR(mmc->supply.vmmc));
@@ -493,7 +493,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
mmc->supply.vqmmc = devm_regulator_get_optional(host->dev, "vmmc_aux");
if (IS_ERR(mmc->supply.vqmmc)) {
ret = PTR_ERR(mmc->supply.vqmmc);
- if (ret != -ENODEV)
+ if ((ret != -ENODEV) && host->dev->of_node)
return ret;
dev_dbg(host->dev, "unable to get vmmc_aux regulator %ld\n",
PTR_ERR(mmc->supply.vqmmc));
@@ -503,7 +503,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
host->pbias = devm_regulator_get_optional(host->dev, "pbias");
if (IS_ERR(host->pbias)) {
ret = PTR_ERR(host->pbias);
- if (ret != -ENODEV)
+ if ((ret != -ENODEV) && host->dev->of_node)
return ret;
dev_dbg(host->dev, "unable to get pbias regulator %ld\n",
PTR_ERR(host->pbias));
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
* Suman Anna [151005 09:47]: > Tony, > > On 10/03/2015 12:29 PM, kbuild test robot wrote: > > Hi Suman, > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > > ignore] > > > > config: arm-omap1_defconfig (attached as .config) > > reproduce: > > wget > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > > -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # save the attached .config to linux build tree > > make.cross ARCH=arm > > > > All error/warnings (new ones prefixed by >>): > > > >arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source': > >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of > >>> function 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration] > > if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) > > ^ > >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of > >>> function '__clk_get_hw' [-Werror=implicit-function-declaration] > >cc1: some warnings being treated as errors > > > > vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c > > > >503 return pdata->set_timer_src(timer->pdev, > > source); > >504 > >505 if (IS_ERR(timer->fclk)) > >506 return -EINVAL; > >507 > >508 /* Check if the clock has parents if not no point > > checking */ > > > 509 if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) > >510 return 0; > > CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose > this within #ifdef CONFIG_COMMON_CLK? Yes, or maybe you can just clk_get_rate() on the 32k oscillator? Boards with no 32k oscillator should set the rate for that 0 zero. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
Tony, On 10/03/2015 12:29 PM, kbuild test robot wrote: > Hi Suman, > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > ignore] > > config: arm-omap1_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All error/warnings (new ones prefixed by >>): > >arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source': >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of function >>> 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration] > if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) > ^ >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of function >>> '__clk_get_hw' [-Werror=implicit-function-declaration] >cc1: some warnings being treated as errors > > vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c > >503return pdata->set_timer_src(timer->pdev, > source); >504 >505if (IS_ERR(timer->fclk)) >506return -EINVAL; >507 >508/* Check if the clock has parents if not no point > checking */ > > 509if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >510return 0; CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose this within #ifdef CONFIG_COMMON_CLK? regards Suman -- To unsubscribe from this list: send the line "unsubscribe 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 03/11] arm: omap2: timer: remove __omap_gptimer_init()
* Felipe Balbi [151005 09:13]: > On Mon, Oct 05, 2015 at 09:02:25AM -0700, Tony Lindgren wrote: > > * Felipe Balbi [151005 08:29]: > > > On Mon, Oct 05, 2015 at 04:01:45AM -0700, Tony Lindgren wrote: > > > > * Felipe Balbi [150929 13:48]: > > > > > since now we can reuse __omap_sync32k_timer_init() > > > > > for OMAP3-like devices, we can safely remove > > > > > __omap_gptimer_init(). > > > > > > > > There are tons of boards out there that need to use the > > > > high frequency ocillator source with gptimer because of the > > > > beagleboard B4 and earlier issue #7. So we need to provide > > > > both options for the boards. Using the high frequency > > > > oscillator source blocks deeper idle states in hardware > > > > so those devices are usable. > > > > > > have a closer look, that hasn't changed > > > > Oh right, you added the argument in the previous patch. > > Maybe update the description a bit to make that clear? > > I understood that we can only use the sync32k source now.. > > > > The __omap_sync32k_timer_init should not be called > > "sync32k" as that's TRM name for the always-on counter :) > > that's renamed on a follow-up patch, too ;-) OK so then I suggest updating the description with something like "With __omap_sync32k_timer_init() now taking the clock source as a parameter, we no longer need __omap_gptimer_init(). Note that __omap_sync32k_timer_init() gets renamed in the later patches as it's no longer 32k source specific". 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: [RFC/PATCH 03/11] arm: omap2: timer: remove __omap_gptimer_init()
On Mon, Oct 05, 2015 at 09:02:25AM -0700, Tony Lindgren wrote: > * Felipe Balbi [151005 08:29]: > > On Mon, Oct 05, 2015 at 04:01:45AM -0700, Tony Lindgren wrote: > > > * Felipe Balbi [150929 13:48]: > > > > since now we can reuse __omap_sync32k_timer_init() > > > > for OMAP3-like devices, we can safely remove > > > > __omap_gptimer_init(). > > > > > > There are tons of boards out there that need to use the > > > high frequency ocillator source with gptimer because of the > > > beagleboard B4 and earlier issue #7. So we need to provide > > > both options for the boards. Using the high frequency > > > oscillator source blocks deeper idle states in hardware > > > so those devices are usable. > > > > have a closer look, that hasn't changed > > Oh right, you added the argument in the previous patch. > Maybe update the description a bit to make that clear? > I understood that we can only use the sync32k source now.. > > The __omap_sync32k_timer_init should not be called > "sync32k" as that's TRM name for the always-on counter :) that's renamed on a follow-up patch, too ;-) -- balbi signature.asc Description: PGP signature
Re: [RFC/PATCH 03/11] arm: omap2: timer: remove __omap_gptimer_init()
* Felipe Balbi [151005 08:29]: > On Mon, Oct 05, 2015 at 04:01:45AM -0700, Tony Lindgren wrote: > > * Felipe Balbi [150929 13:48]: > > > since now we can reuse __omap_sync32k_timer_init() > > > for OMAP3-like devices, we can safely remove > > > __omap_gptimer_init(). > > > > There are tons of boards out there that need to use the > > high frequency ocillator source with gptimer because of the > > beagleboard B4 and earlier issue #7. So we need to provide > > both options for the boards. Using the high frequency > > oscillator source blocks deeper idle states in hardware > > so those devices are usable. > > have a closer look, that hasn't changed Oh right, you added the argument in the previous patch. Maybe update the description a bit to make that clear? I understood that we can only use the sync32k source now.. The __omap_sync32k_timer_init should not be called "sync32k" as that's TRM name for the always-on counter :) 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] dmaengine: omap-dma: Enable packed accesses for cyclic transfers
On Mon, Sep 14, 2015 at 03:31:05PM +0300, Peter Ujfalusi wrote: > From: Misael Lopez Cruz > > The L3 throughput can be higher than expected when packed access > is not enabled. The ratio depends on the number of bytes in a > transaction and the EMIF interface width. > > The throughput was measured for the following settings/cases: > > * Case 1: Burst size of 64 bytes, packed access disabled > * Case 2: Burst size of 64 bytes, packed access enabled > * Case 3: Burst disabled, packed access disabled > > Throughput measurements were done during McASP-based audio > playback on the Jacinto6 EVM using the omapconf tool [1]: > $ omapconf trace bw -m sdma_rd > > - > Throughput (MB/s) > Audio parametersCase 1Case 2Case 3 > - > 44.1kHz, 16-bits, stereo 1.41 0.18 1.41 > 44.1kHz, 32-bits, stereo 1.41 0.35 1.41 > 44.1kHz, 16-bits, 4-chan 2.82 0.35 2.82 > 44.1kHz, 16-bits, 6-chan 4.23 0.53 4.23 > 44.1kHz, 16-bits, 8-chan 5.64 0.71 5.64 > - > > From above measurements, case 2 is the only one that delivers > the expected throughput for the given audio parameters. For > that reason, the packed accesses are now enabled. > > It's worth to mention that packed accesses cannot be enabled > for all addressing modes. In cyclic transfers, it can be > enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM, > as they use post-increment mode which supports packed accesses. > > Peter Ujfalusi: > From the TRM regarding to this: > "NOTE: Except in the constant addressing mode, the source or > destination must be specified as packed for burst transactions > to occur." > > So w/o the packed setting the burst on the MEM side was not > enabled, this explains the numbers. > > [1] https://github.com/omapconf/omapconf > Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe 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 03/11] arm: omap2: timer: remove __omap_gptimer_init()
On Mon, Oct 05, 2015 at 04:01:45AM -0700, Tony Lindgren wrote: > * Felipe Balbi [150929 13:48]: > > since now we can reuse __omap_sync32k_timer_init() > > for OMAP3-like devices, we can safely remove > > __omap_gptimer_init(). > > There are tons of boards out there that need to use the > high frequency ocillator source with gptimer because of the > beagleboard B4 and earlier issue #7. So we need to provide > both options for the boards. Using the high frequency > oscillator source blocks deeper idle states in hardware > so those devices are usable. have a closer look, that hasn't changed -- balbi signature.asc Description: PGP signature
Re: [PATCH] pwm: tipwmss: enable on TI DRA7x and AM437x
On Tue, Sep 08, 2015 at 08:44:05PM +0530, Sekhar Nori wrote: > From: Vignesh R > > TIPWMSS is present on TI's DRA7x and > AM437x SoCs. Enable its usage. > > Instead of adding each SoC individually, > use the more generic ARCH_OMAP2PLUS > instead. > > Signed-off-by: Vignesh R > Signed-off-by: Sekhar Nori > --- > drivers/pwm/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied, thanks. In the future, try to make use of the 78 columns. There is no need to make lines as short as you did. Thierry signature.asc Description: PGP signature
[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping
Hi, this is v9 of an attempt to make it easier for devices to remain in runtime PM when the system goes to sleep, mainly to reduce the time spent resuming devices. For this, we interpret the absence of all PM callback implementations as it being safe to do direct_complete, so their ancestors aren't prevented from remaining runtime-suspended. Additionally, the prepare() callback of USB devices will return 1 if runtime PM is enabled and the current wakeup settings are correct. With these changes, a uvcvideo device (for example) stays in runtime suspend when the system goes to sleep and is left in that state when the system resumes, not delaying it unnecessarily. Thanks, Tomeu Changes in v9: - Add docs noting the need for the device lock to be held before calling device_is_bound() - Add docs noting the need for the device lock to be held before calling dev_pm_domain_set() - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. - Rename from device_check_pm_callbacks to device_pm_check_callbacks to follow with the naming convention of existing API. - Re-add calling to device_pm_check_callbacks from device registration and when updating the PM domain of a device. Changes in v8: - Add device_is_bound() - Add dev_pm_domain_set() and update code to use it - Move no_pm_callbacks field into CONFIG_PM_SLEEP - Call device_check_pm_callbacks only after a device is bound or unbound Changes in v7: - Reduce indentation by adding a label in device_prepare() Changes in v6: - Add stub for !CONFIG_PM. - Move implementation of device_check_pm_callbacks to power/main.c as it doesn't belong to CONFIG_PM_SLEEP. - Take dev->power.lock before modifying flag. Changes in v5: - Check for all dev_pm_ops instances associated to a device, updating a no_pm_callbacks flag at the times when that could change. Tomeu Vizoso (4): device core: add device_is_bound() PM / Domains: add setter for dev.pm_domain PM / sleep: Go direct_complete if driver has no callbacks USB / PM: Allow USB devices to remain runtime-suspended when sleeping arch/arm/mach-omap2/omap_device.c | 7 --- drivers/acpi/acpi_lpss.c | 5 +++-- drivers/acpi/device_pm.c | 5 +++-- drivers/base/dd.c | 21 +++-- drivers/base/power/clock_ops.c| 5 +++-- drivers/base/power/common.c | 24 drivers/base/power/domain.c | 6 -- drivers/base/power/main.c | 35 +++ drivers/base/power/power.h| 3 +++ drivers/gpu/vga/vga_switcheroo.c | 10 +- drivers/misc/mei/pci-me.c | 5 +++-- drivers/misc/mei/pci-txe.c| 5 +++-- drivers/usb/core/port.c | 6 ++ drivers/usb/core/usb.c| 11 ++- include/linux/device.h| 2 ++ include/linux/pm.h| 1 + include/linux/pm_domain.h | 3 +++ 17 files changed, 131 insertions(+), 23 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 2/4] PM / Domains: add setter for dev.pm_domain
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
---
Changes in v9:
- Add docs noting the need for the device lock to be held before calling
dev_pm_domain_set()
Changes in v8:
- Add dev_pm_domain_set() and update code to use it
arch/arm/mach-omap2/omap_device.c | 7 ---
drivers/acpi/acpi_lpss.c | 5 +++--
drivers/acpi/device_pm.c | 5 +++--
drivers/base/power/clock_ops.c| 5 +++--
drivers/base/power/common.c | 21 +
drivers/base/power/domain.c | 4 ++--
drivers/gpu/vga/vga_switcheroo.c | 10 +-
drivers/misc/mei/pci-me.c | 5 +++--
drivers/misc/mei/pci-txe.c| 5 +++--
include/linux/pm_domain.h | 3 +++
10 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 4cb8fd9f741f..204101d11632 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r->name = dev_name(&pdev->dev);
}
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
- pdev->dev.pm_domain = &omap_device_fail_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_fail_pm_domain);
return ret;
}
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
{
pr_debug("omap_device: %s: registering\n", pdev->name);
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
return platform_device_add(pdev);
}
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f51bd0d0bc17..cc6e1abc69b3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block
*nb,
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
- pdev->dev.pm_domain = &acpi_lpss_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
@@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct notifier_block
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
- pdev->dev.pm_domain = NULL;
+ dev_pm_domain_set(&pdev->dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 4806b7f856c4..8c5955bf9bbf 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);
if (adev && dev->pm_domain == &acpi_general_pm_domain) {
- dev->pm_domain = NULL;
+ dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
- dev->pm_domain = &acpi_general_pm_domain;
+ dev_pm_domain_set(dev, &acpi_general_pm_domain);
if (power_on) {
acpi_dev_pm_full_power(adev);
acpi_device_wakeup(adev, ACPI_STATE_S0, false);
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..e80fda6c03a9 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PM
@@ -346,7 +347,7 @@ static int pm_clk_notify(struct notifier_block *nb,
if (error)
Re: All OMAP platforms: MMC is broken
* Tony Lindgren [151005 07:44]:
> * Tony Lindgren [151005 04:28]:
> > * Russell King - ARM Linux [151001 03:07]:
> > > On Thu, Oct 01, 2015 at 11:50:00AM +0200, Ulf Hansson wrote:
> > > > On 1 October 2015 at 11:33, Russell King - ARM Linux
> > > > wrote:
> > > > > On Thu, Sep 24, 2015 at 04:37:56PM -0700, Tony Lindgren wrote:
> > > > >> * Russell King - ARM Linux [150924 02:04]:
> > > > >> > Nightly testing has revealed that both the OMAP3430 LDP and the
> > > > >> > OMAP4430
> > > > >> > SDP fail to boot due to lack of working MMC. Both platforms fail
> > > > >> > to
> > > > >> > find their rootfs, which is on a SD card.
> > > > >> >
> > > > >> > The breakage occurred somewhere between trees of September 9th
> > > > >> > (commit
> > > > >> > 4e4adb2f4628) and September 12th (commit b0a1ea51bda4), so during
> > > > >> > the
> > > > >> > merge window.
> > > > >>
> > > > >> Yes sorry things got messed up in multiple ways :( I've summarized
> > > > >> the mess here earlier:
> > > > >>
> > > > >> http://article.gmane.org/gmane.linux.kernel.mmc/33911
> > > > >>
> > > > >> And today commit b9c93646fd5c ("regulator: pbias: program pbias
> > > > >> register
> > > > >> offset in pbias driver") hit mainline so I'll send a pull request for
> > > > >> the related dts change.
> > > > >
> > > > > It's still broken and untestable. We're 8 days off it being a full
> > > > > month worth of failed testing for OMAP3 and OMAP4 platforms.
> > > > >
> > > > > I think OMAP and MMC people need to do a post-mortem and work out why
> > > > > this happened, and how to stop it happening again in the future.
> > > >
> > > > You are probably right!
> > > >
> > > > I think I should have been more persistent when asking on how to deal
> > > > with these patches. Typically they should all have gone together via
> > > > one tree, or we needed a slower way forward keeping changes more
> > > > standalone.
> > > >
> > > > Anyway, according to kernelci.org, which builds and boot my next
> > > > branch omap3/4 seems to boot now...
> > > > http://kernelci.org/boot/all/job/ulfh/kernel/v4.3-rc3-27-gf7734d097520/
> > >
> > > It continues to fail here.
> > >
> > > Okay, sod it, I'm at the point of just not giving a damn about whether
> > > OMAP3 and OMAP4 boot anymore.
> > >
> > > I'm taking all OMAP platforms out of my boot farm. I'm totally fed up
> > > with this kind of regression happening. It's probably some config option
> > > that someone's recently introduced which defaults to being off, thereby
> > > breaking the ability for people to move forward without constantly having
> > > to re-configure. This is not acceptable.
> > >
> > > STOP BREAKING THE KERNEL.
> >
> > I totally agree, this is unacceptable. And I'm fed up chasing driver
> > breakage and trying to test everything myself.
> >
> > If Kihon is not starting to respond to these issues, we better start
> > reverting some of the MMC patches. And I'd say in the future non-trivial
> > patches really have to sit in linux next for two weeks before merging.
> >
> > We have still the omap3 legacy booting issue remaining, and warnings
> > at least on omap4 overo.
>
> Sorry i mean Kishon instead of Kihon above.
>
> Based on some tests it seems that the duovero unpaired regulator usage
> is fixed by reverting:
>
> c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
> find pbias status")
With commit c55d7a055364 my guess is that the PBIAS regulator is
already on from an earlier MMC probe and getting re-enabled when
a deferred probe happens?
> And it seems that omap3 legacy MMC is broken earlier in the
> series with:
>
> 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc")
>
> This one does not cleanly revert so have not yet tried reverting
> it.
And with commit 7d607f917008 I'm guessing we can't return an
error if the PBIAS regulator does not exist as that's not there
for the legacy booting.
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: All OMAP platforms: MMC is broken
* Tony Lindgren [151005 04:28]:
> * Russell King - ARM Linux [151001 03:07]:
> > On Thu, Oct 01, 2015 at 11:50:00AM +0200, Ulf Hansson wrote:
> > > On 1 October 2015 at 11:33, Russell King - ARM Linux
> > > wrote:
> > > > On Thu, Sep 24, 2015 at 04:37:56PM -0700, Tony Lindgren wrote:
> > > >> * Russell King - ARM Linux [150924 02:04]:
> > > >> > Nightly testing has revealed that both the OMAP3430 LDP and the
> > > >> > OMAP4430
> > > >> > SDP fail to boot due to lack of working MMC. Both platforms fail to
> > > >> > find their rootfs, which is on a SD card.
> > > >> >
> > > >> > The breakage occurred somewhere between trees of September 9th
> > > >> > (commit
> > > >> > 4e4adb2f4628) and September 12th (commit b0a1ea51bda4), so during the
> > > >> > merge window.
> > > >>
> > > >> Yes sorry things got messed up in multiple ways :( I've summarized
> > > >> the mess here earlier:
> > > >>
> > > >> http://article.gmane.org/gmane.linux.kernel.mmc/33911
> > > >>
> > > >> And today commit b9c93646fd5c ("regulator: pbias: program pbias
> > > >> register
> > > >> offset in pbias driver") hit mainline so I'll send a pull request for
> > > >> the related dts change.
> > > >
> > > > It's still broken and untestable. We're 8 days off it being a full
> > > > month worth of failed testing for OMAP3 and OMAP4 platforms.
> > > >
> > > > I think OMAP and MMC people need to do a post-mortem and work out why
> > > > this happened, and how to stop it happening again in the future.
> > >
> > > You are probably right!
> > >
> > > I think I should have been more persistent when asking on how to deal
> > > with these patches. Typically they should all have gone together via
> > > one tree, or we needed a slower way forward keeping changes more
> > > standalone.
> > >
> > > Anyway, according to kernelci.org, which builds and boot my next
> > > branch omap3/4 seems to boot now...
> > > http://kernelci.org/boot/all/job/ulfh/kernel/v4.3-rc3-27-gf7734d097520/
> >
> > It continues to fail here.
> >
> > Okay, sod it, I'm at the point of just not giving a damn about whether
> > OMAP3 and OMAP4 boot anymore.
> >
> > I'm taking all OMAP platforms out of my boot farm. I'm totally fed up
> > with this kind of regression happening. It's probably some config option
> > that someone's recently introduced which defaults to being off, thereby
> > breaking the ability for people to move forward without constantly having
> > to re-configure. This is not acceptable.
> >
> > STOP BREAKING THE KERNEL.
>
> I totally agree, this is unacceptable. And I'm fed up chasing driver
> breakage and trying to test everything myself.
>
> If Kihon is not starting to respond to these issues, we better start
> reverting some of the MMC patches. And I'd say in the future non-trivial
> patches really have to sit in linux next for two weeks before merging.
>
> We have still the omap3 legacy booting issue remaining, and warnings
> at least on omap4 overo.
Sorry i mean Kishon instead of Kihon above.
Based on some tests it seems that the duovero unpaired regulator usage
is fixed by reverting:
c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
find pbias status")
And it seems that omap3 legacy MMC is broken earlier in the
series with:
7d607f917008 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
This one does not cleanly revert so have not yet tried reverting
it.
I'm at ELCE so there may be delays for me debugging stuff. Anybody
see obvious places to fix with those two patches above?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] iio:adc:palmas: add DT support
Am 05.10.2015 um 13:17 schrieb Mark Rutland :
> On Sun, Oct 04, 2015 at 06:05:59PM +0200, H. Nikolaus Schaller wrote:
>> From: Marek Belisko
>>
>> Code was found at:
>> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
>>
>> Signed-off-by: Laxman Dewangan
>> [Fixed minor typos + add channels list to documentation]
>> Signed-off-by: Marek Belisko
>> ---
>> .../devicetree/bindings/iio/adc/palmas-gpadc.txt | 46 +++
>> drivers/iio/adc/palmas_gpadc.c | 52
>> +++---
>> 2 files changed, 93 insertions(+), 5 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> new file mode 100644
>> index 000..2149afe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> @@ -0,0 +1,46 @@
>> +* Palmas general purpose ADC IP block devicetree bindings
>> +
>> +Channels list:
>> +0 battery type
>> +1 battery temp NTC (optional current source)
>> +2 GP
>> +3 temp (with ext. diode, optional current source)
>> +4 GP
>> +5 GP
>> +6 VBAT_SENSE
>> +7 VCC_SENSE
>> +8 Backup Battery voltage
>> +9 external charger (VCHG)
>> +10 VBUS
>> +11 DC-DC current probe (how does this work?)
>> +12 internal die temp
>> +13 internal die temp
>> +14 USB ID pin voltage
>> +15 test network
>> +
>> +Required properties:
>> +- compatible : Must be "ti,palmas-gpadc".
>> +
>> +Optional sub-nodes:
>> +ti,channel0-current-microamp: Channel 0 current in uA.
>> +Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
>> +ti,channel3-current-microamp: Channel 3 current in uA.
>> +Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
>
> It's only possible to configure channels 0 and 3 in this manner?
Yes. The other channels have no built-in current source, i.e. these
channels are special.
>
>> +ti,enable-extended-delay: Enable extended delay.
>
> What is this? When would I select it? Why does it belong in the DT
> rather than being a runtime option?
The chip allows to extend the time window between channel selection
and sampling by 400µs (according to data sheet). But for all channels
and not each one. As far as I understand, this is - depending on hardware
setup - to get more stable ADC readings.
Most channels have a fixed function (e.g. battery voltage, USB VBUS,
temperature NTC) so it can't be arbitrarily chosen and depends on how
the Palmas is embedded (it is a PMIC with a bank of ADCs and not a
general purpose ADC chip).
So I think it is really a hardware dependent parameter and not something
the user should be able to change.
>
>> +Example:
>> +
>> +pmic {
>> +compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
>> +...
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> + 16 0
>> + 17 0>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +};
>> +};
>> +...
>> +};
>
> I thought you needed #iio-cells for encoding the channel?
Yes, we forgot (we don't have a client for it in our setup yet - so did not
test :)
>
> Mark.
Thanks,
Nikolaus Schaller
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: N900: always enable IBE bit
Hi!
> The kernel's workaround for Errata 430973 consists of a BTAC/BTB
> flush at context switch. This requires the IBE bit being set, which
> should normally be done by the bootloader.
>
> Since the Nokia N900's bootloader is not easily replaceable,
> a pdata quirk enables the IBE bit for the Nokia N900. Until
> e748994f5cc5, the flush at context switch required
> CONFIG_ARM_ERRATA_430973, so the same check has been used
> for setting the IBE bit.
>
> Since all sold N900s are assumed to be affected, the guard
> can be removed now, so that the IBE bit is always set.
Is the qemu affected?
Does qemu have enough secure support not to fail on this?
Best regards,
Pavel
>
> Signed-off-by: Sebastian Reichel
> ---
> arch/arm/mach-omap2/board-rx51.c | 2 --
> arch/arm/mach-omap2/pdata-quirks.c | 11 ++-
> 2 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51.c
> b/arch/arm/mach-omap2/board-rx51.c
> index 2d1e5a6..3df01cc 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -108,11 +108,9 @@ static void __init rx51_init(void)
> rx51_peripherals_init();
>
> if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> -#ifdef CONFIG_ARM_ERRATA_430973
> pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
> /* set IBE to 1 */
> rx51_secure_update_aux_cr(BIT(6), 0);
> -#endif
> }
>
> /* Ensure SDRC pins are mux'd for self-refresh */
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 821171c..0aa438d 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -249,18 +249,11 @@ static void __init nokia_n900_legacy_init(void)
> hsmmc2_internal_input_clk();
>
> if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> - if (IS_ENABLED(CONFIG_ARM_ERRATA_430973)) {
> - pr_info("RX-51: Enabling ARM errata 430973
> workaround\n");
> - /* set IBE to 1 */
> - rx51_secure_update_aux_cr(BIT(6), 0);
> - } else {
> - pr_warn("RX-51: Not enabling ARM errata 430973
> workaround\n");
> - pr_warn("Thumb binaries may crash randomly without this
> workaround\n");
> - }
> + pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
> + rx51_secure_update_aux_cr(BIT(6), 0); /* set IBE to 1 */
>
> pr_info("RX-51: Registring OMAP3 HWRNG device\n");
> platform_device_register(&omap3_rom_rng_device);
> -
> }
> }
>
> --
> 2.1.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: fix dual-registration of uart4_ick
On 10/05/2015 01:17 PM, Tony Lindgren wrote:
* Ben Dooks [150929 06:14]:
On 25/09/15 06:42, Tero Kristo wrote:
On 09/23/2015 08:30 PM, Tony Lindgren wrote:
* Ben Dooks [150923 07:53]:
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power managment to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
No uart4 on 34xx/35xx, that got introduced with 36xx so:
Acked-by: Tony Lindgren
Signed-off-by: Ben Dooks
---
drivers/clk/ti/clk-3xxx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 5e12f32..2e7ef1f 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
-DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
NAK.
This patch is actually only partially correct, it removes the uart4_ick
alias for omap36xx also. It should be added back to the omap36xx clks
array. Care to post a v2?
Thankyou for the feedback. I'll update, but do not have a device to test.
Hmm but isn't that entry already there for 36xx? So this just removes
a duplicate for 36xx.. Tero, can you please check again, maybe I'm
confused.
uart4_ick wasn't there, we only had uart4_fck listed for omap36xx.
-Tero
Regars,
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: [RFC/PATCH 00/11] arm: omap: counter32k rework
On Monday 05 October 2015 04:13:41 Tony Lindgren wrote: > * Arnd Bergmann [151005 04:08]: > > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote: > > > * Daniel Lezcano [151001 15:16]: > > > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote: > > > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > > > > >> > > > > >>TEGRA folks: the tegra_read_persistent_clock() implementation > > > > >>apparently > > > > >>predates the Tegra RTC driver and I wonder if they actually do the > > > > >>right thing in combination. Could it be that the wall time forwards > > > > >>twice as fast as it should during resume when the RTC driver is > > > > >>loaded? > > > > >>Could it be that we can simply remove tegra_read_persistent_clock() > > > > >>and the register_persistent_clock() infrastructure? > > > > >> > > > > > > > > > >I found the 'sleeptime_injected' variable now, which takes care of > > > > >forwarding the clock by the correct amount. > > > > > > > > > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which > > > > >should let us use the counter32k driver to provide the correct > > > > >time during suspend without the omap_read_persistent_clock() function. > > > > >We should be able to just delete that code. > > > > > > > > > >If we decide to also delete the tegra_read_persistent_clock() > > > > >function, we can remove the registration too. > > > > > > > > > > > > +1 > > > > > > We could maybe have read_persistent_clock() just check for the > > > CLOCK_SOURCE_SUSPEND_NONSTOP flag? > > > > timekeeping_resume() already ignores the persistent clock values if > > the clocksource has this set. Do you mean we should additionally > > not call the read_persistent_clock() function at all to safe a > > few cycles reading that value? > > Hmm no I mean if we have CLOCK_SOURCE_SUSPEND_NONSTOP we can > automatically make read_persistent_clock() use that if nothing > else got registered. Ok, so we don't need to change anything here then. > > How expensive is the function? > > Usually the persistent clock is on some interconnect, so it is > way slower compared to a local timer. It doubt it makes a > difference in timekeeping_resume() though Right. 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 v2 2/3] iio:adc:palmas: add DT support
On Sun, Oct 04, 2015 at 06:05:59PM +0200, H. Nikolaus Schaller wrote:
> From: Marek Belisko
>
> Code was found at:
> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
>
> Signed-off-by: Laxman Dewangan
> [Fixed minor typos + add channels list to documentation]
> Signed-off-by: Marek Belisko
> ---
> .../devicetree/bindings/iio/adc/palmas-gpadc.txt | 46 +++
> drivers/iio/adc/palmas_gpadc.c | 52 +++---
> 2 files changed, 93 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> new file mode 100644
> index 000..2149afe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> @@ -0,0 +1,46 @@
> +* Palmas general purpose ADC IP block devicetree bindings
> +
> +Channels list:
> + 0 battery type
> + 1 battery temp NTC (optional current source)
> + 2 GP
> + 3 temp (with ext. diode, optional current source)
> + 4 GP
> + 5 GP
> + 6 VBAT_SENSE
> + 7 VCC_SENSE
> + 8 Backup Battery voltage
> + 9 external charger (VCHG)
> + 10 VBUS
> + 11 DC-DC current probe (how does this work?)
> + 12 internal die temp
> + 13 internal die temp
> + 14 USB ID pin voltage
> + 15 test network
> +
> +Required properties:
> +- compatible : Must be "ti,palmas-gpadc".
> +
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
It's only possible to configure channels 0 and 3 in this manner?
> +ti,enable-extended-delay: Enable extended delay.
What is this? When would I select it? Why does it belong in the DT
rather than being a runtime option?
> +Example:
> +
> +pmic {
> + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> + ...
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> + 16 0
> + 17 0>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + };
> + };
> + ...
> +};
I thought you needed #iio-cells for encoding the channel?
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 00/11] arm: omap: counter32k rework
* Arnd Bergmann [151005 04:08]: > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote: > > * Daniel Lezcano [151001 15:16]: > > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote: > > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > > > >> > > > >>TEGRA folks: the tegra_read_persistent_clock() implementation apparently > > > >>predates the Tegra RTC driver and I wonder if they actually do the > > > >>right thing in combination. Could it be that the wall time forwards > > > >>twice as fast as it should during resume when the RTC driver is loaded? > > > >>Could it be that we can simply remove tegra_read_persistent_clock() > > > >>and the register_persistent_clock() infrastructure? > > > >> > > > > > > > >I found the 'sleeptime_injected' variable now, which takes care of > > > >forwarding the clock by the correct amount. > > > > > > > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which > > > >should let us use the counter32k driver to provide the correct > > > >time during suspend without the omap_read_persistent_clock() function. > > > >We should be able to just delete that code. > > > > > > > >If we decide to also delete the tegra_read_persistent_clock() > > > >function, we can remove the registration too. > > > > > > > > > +1 > > > > We could maybe have read_persistent_clock() just check for the > > CLOCK_SOURCE_SUSPEND_NONSTOP flag? > > timekeeping_resume() already ignores the persistent clock values if > the clocksource has this set. Do you mean we should additionally > not call the read_persistent_clock() function at all to safe a > few cycles reading that value? Hmm no I mean if we have CLOCK_SOURCE_SUSPEND_NONSTOP we can automatically make read_persistent_clock() use that if nothing else got registered. > How expensive is the function? Usually the persistent clock is on some interconnect, so it is way slower compared to a local timer. It doubt it makes a difference in timekeeping_resume() though :) 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: [RFC/PATCH 00/11] arm: omap: counter32k rework
On Monday 05 October 2015 03:55:55 Tony Lindgren wrote: > * Daniel Lezcano [151001 15:16]: > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote: > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > > >> > > >>TEGRA folks: the tegra_read_persistent_clock() implementation apparently > > >>predates the Tegra RTC driver and I wonder if they actually do the > > >>right thing in combination. Could it be that the wall time forwards > > >>twice as fast as it should during resume when the RTC driver is loaded? > > >>Could it be that we can simply remove tegra_read_persistent_clock() > > >>and the register_persistent_clock() infrastructure? > > >> > > > > > >I found the 'sleeptime_injected' variable now, which takes care of > > >forwarding the clock by the correct amount. > > > > > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which > > >should let us use the counter32k driver to provide the correct > > >time during suspend without the omap_read_persistent_clock() function. > > >We should be able to just delete that code. > > > > > >If we decide to also delete the tegra_read_persistent_clock() > > >function, we can remove the registration too. > > > > > > +1 > > We could maybe have read_persistent_clock() just check for the > CLOCK_SOURCE_SUSPEND_NONSTOP flag? timekeeping_resume() already ignores the persistent clock values if the clocksource has this set. Do you mean we should additionally not call the read_persistent_clock() function at all to safe a few cycles reading that value? How expensive is the function? 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: [RFC/PATCH 09/11] clocksource: add TI 32.768 Hz counter driver
* Tony Lindgren [151005 03:56]:
> * Daniel Lezcano [151001 15:04]:
> > >+ clocks_calc_mult_shift(&persistent_mult, &persistent_shift,
> > >+ 32768, NSEC_PER_SEC, 12);
> > >+
> > >+ ret = clocksource_mmio_init(sync32k_cnt_reg, "32k_counter", 32768,
> > >+ 250, 32, clocksource_mmio_readl_up);
> > >+ if (ret) {
> > >+ pr_err("32k_counter: can't register clocksource\n");
> > >+ return;
> > >+ }
> > >+
> > >+ sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
> > >+ register_persistent_clock(NULL, omap_read_persistent_clock64);
> >
> > I will let John Stultz to have a look at this part because I have doubt
> > regarding the usage of the persistent clock.
>
> The persistent clock we want to keep for deeper idle states..
> Especially when we start changing clocksource for the duration of
> deeper idle states. I'll post some updated patches on that when I
> get a chance.
But sounds like we can just have read_persistent_clock() check
for the CLOCK_SOURCE_SUSPEND_NONSTOP like I pointed in the other
patch in this series.
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 v2 2/3] iio:adc:palmas: add DT support
On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote: From: Marek Belisko Code was found at: https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1 Signed-off-by: Laxman Dewangan [Fixed minor typos + add channels list to documentation] Signed-off-by: Marek Belisko --- Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe 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 03/11] arm: omap2: timer: remove __omap_gptimer_init()
* Felipe Balbi [150929 13:48]: > since now we can reuse __omap_sync32k_timer_init() > for OMAP3-like devices, we can safely remove > __omap_gptimer_init(). There are tons of boards out there that need to use the high frequency ocillator source with gptimer because of the beagleboard B4 and earlier issue #7. So we need to provide both options for the boards. Using the high frequency oscillator source blocks deeper idle states in hardware so those devices are usable. Regads, 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 v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc
On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote: This driver code was found as: https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc Fixed various compilation issues and test this driver on omap5 evm. Signed-off-by: Pradeep Goudagunta Signed-off-by: H. Nikolaus Schaller Signed-off-by: Marek Belisko Acked-by: Laxman Dewangan -- To unsubscribe from this list: send the line "unsubscribe 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 00/11] arm: omap: counter32k rework
* Daniel Lezcano [151001 15:16]: > On 09/30/2015 04:49 PM, Arnd Bergmann wrote: > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > >> > >>TEGRA folks: the tegra_read_persistent_clock() implementation apparently > >>predates the Tegra RTC driver and I wonder if they actually do the > >>right thing in combination. Could it be that the wall time forwards > >>twice as fast as it should during resume when the RTC driver is loaded? > >>Could it be that we can simply remove tegra_read_persistent_clock() > >>and the register_persistent_clock() infrastructure? > >> > > > >I found the 'sleeptime_injected' variable now, which takes care of > >forwarding the clock by the correct amount. > > > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which > >should let us use the counter32k driver to provide the correct > >time during suspend without the omap_read_persistent_clock() function. > >We should be able to just delete that code. > > > >If we decide to also delete the tegra_read_persistent_clock() > >function, we can remove the registration too. > > > +1 We could maybe have read_persistent_clock() just check for the CLOCK_SOURCE_SUSPEND_NONSTOP flag? And we probably should have also has_persistent_clock() or something that also checks for the CLOCK_SOURCE_SUSPEND_NONSTOP. 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: [RFC/PATCH 09/11] clocksource: add TI 32.768 Hz counter driver
* Daniel Lezcano [151001 15:04]:
> >+clocks_calc_mult_shift(&persistent_mult, &persistent_shift,
> >+32768, NSEC_PER_SEC, 12);
> >+
> >+ret = clocksource_mmio_init(sync32k_cnt_reg, "32k_counter", 32768,
> >+250, 32, clocksource_mmio_readl_up);
> >+if (ret) {
> >+pr_err("32k_counter: can't register clocksource\n");
> >+return;
> >+}
> >+
> >+sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
> >+register_persistent_clock(NULL, omap_read_persistent_clock64);
>
> I will let John Stultz to have a look at this part because I have doubt
> regarding the usage of the persistent clock.
The persistent clock we want to keep for deeper idle states..
Especially when we start changing clocksource for the duration of
deeper idle states. I'll post some updated patches on that when I
get a chance.
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: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter
* Felipe Balbi [150929 13:48]: > All devices should have a default status. Ignoring > the arguments if it should be 'okay' or 'disabled' > by default, let's set them all the 'disabled' and > have boards enable 32k counter. We should not use "disabled" really at all. That means no struct device is ever created while that hardawre is there for the internal devices for sure. Also, we should use the 32k counter as the default one as that's always on for deeper idle states. For cases where the 32k ocillator is not available, it's better to just set the source clock rate to 0 in the board specific dts file and have the driver bail out early if source clock rate is 0. 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] clk: ti: fix dual-registration of uart4_ick
* Ben Dooks [150929 06:14]:
> On 25/09/15 06:42, Tero Kristo wrote:
> > On 09/23/2015 08:30 PM, Tony Lindgren wrote:
> >> * Ben Dooks [150923 07:53]:
> >>> On the OMAP AM3517 platform the uart4_ick gets registered
> >>> twice, causing any power managment to /dev/ttyO3 to fail
> >>> when trying to wake the device up.
> >>>
> >>> This solves the following oops:
> >>>
> >>> [] Unhandled fault: external abort on non-linefetch (0x1028) at
> >>> 0xfa09e008
> >>> [] PC is at serial_omap_pm+0x48/0x15c
> >>> [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
> >>
> >> No uart4 on 34xx/35xx, that got introduced with 36xx so:
> >>
> >> Acked-by: Tony Lindgren
> >>
> >>> Signed-off-by: Ben Dooks
> >>> ---
> >>> drivers/clk/ti/clk-3xxx.c | 1 -
> >>> 1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> >>> index 5e12f32..2e7ef1f 100644
> >>> --- a/drivers/clk/ti/clk-3xxx.c
> >>> +++ b/drivers/clk/ti/clk-3xxx.c
> >>> @@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
> >>> DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
> >>> DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
> >>> DT_CLK(NULL, "uart3_ick", "uart3_ick"),
> >>> -DT_CLK(NULL, "uart4_ick", "uart4_ick"),
> >>> DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
> >>> DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
> >>> DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
> >
> > NAK.
> >
> > This patch is actually only partially correct, it removes the uart4_ick
> > alias for omap36xx also. It should be added back to the omap36xx clks
> > array. Care to post a v2?
>
> Thankyou for the feedback. I'll update, but do not have a device to test.
Hmm but isn't that entry already there for 36xx? So this just removes
a duplicate for 36xx.. Tero, can you please check again, maybe I'm
confused.
Regars,
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
