Re: [PATCH v5 07/24] regulator: pwm: use pwm_get_args() where appropriate
On Thu, Apr 14, 2016 at 09:17:27PM +0200, Boris Brezillon wrote: > The PWM framework has clarified the concept of reference PWM config > (the platform dependent config retrieved from the DT or the PWM > lookup table) and real PWM state. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation
On Thu, Apr 14, 2016 at 1:34 PM, Pavel Machek wrote: > On Thu 2016-04-14 13:14:07, Kees Cook wrote: >> On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: >> > Hi! >> > >> >> Since kASLR and Hibernation can not currently coexist at runtime >> >> on x86, the default behavior was to disable kASLR by default when >> >> CONFIG_HIBERNATION was present (to retain original behavior). >> >> >> >> The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by >> >> default when selected at build time. Since arm64 Hibernation does not >> >> conflict with kASLR, this fixes the hibernation argument parsing to be >> >> x86-specific. Additionally, since end users want to be able to select >> >> kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON >> >> that is present only on x86. >> >> >> >> Signed-off-by: Kees Cook >> > >> > I believe this is bad idea. arm64 shows that kaslr and hibernation can >> > coexist, and hibernation is still useful when your battery runs out. >> >> What? I'm confused -- this patch leaves the x86 behavior as-is by >> default but allows hibernation to work with arm64. (For example, right >> now, if you boot arm64 with "kaslr" kernel argument, hibernation will >> get needlessly disabled.) > > So it is very different from the PATCH v1, still it shares the > subject? It was similar, but not the same: v1: Prefer kASLR over Hibernation v2: kaslr: allow kASLR to be default over Hibernation I'm happy to call it whatever you like, though! :) > This is the part I don't like: > >> >> Since kASLR and Hibernation can not currently coexist at runtime >> >> on x86, the default behavior was to disable kASLR by default when >> >> CONFIG_HIBERNATION was present (to retain original behavior). > > Now I notice that it is quite unclear if it actually changes > anything... Okay, right. So, there are a few problems that this patch is solving, and maybe it needs to be broken up into separate patches, but it didn't seem like it to me at the time. Specifically: 1) The x86 hibernation and KASLR code don't play well together currently. "1" was worked around so that both could be built in, but only one would be active at a time. This lead to: 2) The general hibernation code contains kernel arguments that should only affect x86. And we have the desire by folks to have KASLR enabled by default on x86, giving us: 3) There is no build-time way on x86 to switch the preference of KASLR vs hibernation. I think "2" should be solved for this release, since arm64 KASLR is landing, and mistakenly booting an arm64 system with "kaslr" on the command line will needlessly disable hibernation. 3 and 2 are a result of 1, and IIUC, you're saying you want to solve 1 to make everything else go away? My only concern with that idea is that I don't (yet) have the knowledge of x86 hibernation internals to fix this, and it'll take a while to get to having KASLR on by default if we have to wait on me to fix hibernation. (I'm not saying I won't/can't, it's just that it'll take me time to come up to speed on it.) That do you think? -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: cgroup: "unshare -C" to unshare cgroup namespace
Use "unshare -C" to be consistent with the unshare utility from util-linux
Signed-off-by: Josef Lusticky
---
Documentation/cgroup-v2.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 4cc07ce..929af1c 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1179,7 +1179,7 @@ init_cgroup_ns, this is the real root ('/') cgroup.
The cgroupns root cgroup does not change even if the namespace creator
process later moves to a different cgroup.
- # ~/unshare -c # unshare cgroupns in some cgroup
+ # ~/unshare -C # unshare cgroupns in some cgroup
# cat /proc/self/cgroup
0::/
# mkdir sub_cgrp_1
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] kaslr: allow kASLR to be default over Hibernation
On Thu 2016-04-14 13:14:07, Kees Cook wrote: > On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: > > Hi! > > > >> Since kASLR and Hibernation can not currently coexist at runtime > >> on x86, the default behavior was to disable kASLR by default when > >> CONFIG_HIBERNATION was present (to retain original behavior). > >> > >> The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by > >> default when selected at build time. Since arm64 Hibernation does not > >> conflict with kASLR, this fixes the hibernation argument parsing to be > >> x86-specific. Additionally, since end users want to be able to select > >> kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON > >> that is present only on x86. > >> > >> Signed-off-by: Kees Cook > > > > I believe this is bad idea. arm64 shows that kaslr and hibernation can > > coexist, and hibernation is still useful when your battery runs out. > > What? I'm confused -- this patch leaves the x86 behavior as-is by > default but allows hibernation to work with arm64. (For example, right > now, if you boot arm64 with "kaslr" kernel argument, hibernation will > get needlessly disabled.) So it is very different from the PATCH v1, still it shares the subject? This is the part I don't like: > >> Since kASLR and Hibernation can not currently coexist at runtime > >> on x86, the default behavior was to disable kASLR by default when > >> CONFIG_HIBERNATION was present (to retain original behavior). Now I notice that it is quite unclear if it actually changes anything... Pavel -- (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-doc" 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] kaslr: allow kASLR to be default over Hibernation
On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: > Hi! > >> Since kASLR and Hibernation can not currently coexist at runtime >> on x86, the default behavior was to disable kASLR by default when >> CONFIG_HIBERNATION was present (to retain original behavior). >> >> The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by >> default when selected at build time. Since arm64 Hibernation does not >> conflict with kASLR, this fixes the hibernation argument parsing to be >> x86-specific. Additionally, since end users want to be able to select >> kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON >> that is present only on x86. >> >> Signed-off-by: Kees Cook > > I believe this is bad idea. arm64 shows that kaslr and hibernation can > coexist, and hibernation is still useful when your battery runs out. What? I'm confused -- this patch leaves the x86 behavior as-is by default but allows hibernation to work with arm64. (For example, right now, if you boot arm64 with "kaslr" kernel argument, hibernation will get needlessly disabled.) -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] kaslr: allow kASLR to be default over Hibernation
Hi! > Since kASLR and Hibernation can not currently coexist at runtime > on x86, the default behavior was to disable kASLR by default when > CONFIG_HIBERNATION was present (to retain original behavior). > > The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by > default when selected at build time. Since arm64 Hibernation does not > conflict with kASLR, this fixes the hibernation argument parsing to be > x86-specific. Additionally, since end users want to be able to select > kASLR on x86 by default at build time, create CONFIG_RANDOMIZE_BASE_ON > that is present only on x86. > > Signed-off-by: Kees Cook I believe this is bad idea. arm64 shows that kaslr and hibernation can coexist, and hibernation is still useful when your battery runs out. Pavel -- (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-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate
Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
field. Doing that will ease adaptation of the PWM framework to support
atomic update.
Signed-off-by: Boris Brezillon
---
Patch generated with the following coccinelle script:
--->8---
virtual patch
@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity(p, e);
|
-(p)->polarity
+pwm_get_polarity(p)
|
-(p)->period = e;
+pwm_set_period(p, e);
|
-(p)->period
+pwm_get_period(p)
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle(p, e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle(p)
)
--->8---
---
drivers/pwm/pwm-crc.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
drivers/pwm/pwm-omap-dmtimer.c | 2 +-
drivers/pwm/pwm-sun4i.c| 3 ++-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 7101c70..bd0ebd0 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -75,7 +75,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct
pwm_device *pwm,
return -EINVAL;
}
- if (pwm->period != period_ns) {
+ if (pwm_get_period(pwm) != period_ns) {
int clk_div;
/* changing the clk divisor, need to disable fisrt */
diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 9861fed..19dc64c 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -249,7 +249,7 @@ static int lpc18xx_pwm_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
LPC18XX_PWM_EVSTATEMSK(lpc18xx_data->duty_event),
LPC18XX_PWM_EVSTATEMSK_ALL);
- if (pwm->polarity == PWM_POLARITY_NORMAL) {
+ if (pwm_get_polarity(pwm) == PWM_POLARITY_NORMAL) {
set_event = lpc18xx_pwm->period_event;
clear_event = lpc18xx_data->duty_event;
res_action = LPC18XX_PWM_RES_SET;
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index b7e6ecb..3e95090 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -192,7 +192,7 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
load_value, load_value, match_value, match_value);
omap->pdata->set_pwm(omap->dm_timer,
- pwm->polarity == PWM_POLARITY_INVERSED,
+ pwm_get_polarity(pwm) == PWM_POLARITY_INVERSED,
true,
PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE);
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 67af9f6..03a99a5 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -354,7 +354,8 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
for (i = 0; i < pwm->chip.npwm; i++)
if (!(val & BIT_CH(PWM_ACT_STATE, i)))
- pwm->chip.pwms[i].polarity = PWM_POLARITY_INVERSED;
+ pwm_set_polarity(&pwm->chip.pwms[i],
+PWM_POLARITY_INVERSED);
clk_disable_unprepare(pwm->clk);
return 0;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/24] clk: pwm: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
Acked-by: Stephen Boyd
---
drivers/clk/clk-pwm.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 8830458..1630a1f 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -59,6 +59,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
struct clk_init_data init;
struct clk_pwm *clk_pwm;
struct pwm_device *pwm;
+ struct pwm_args pargs;
const char *clk_name;
struct clk *clk;
int ret;
@@ -71,22 +72,28 @@ static int clk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm))
return PTR_ERR(pwm);
- if (!pwm->period) {
+ pwm_get_args(pwm, &pargs);
+ if (!pargs.period) {
dev_err(&pdev->dev, "invalid PWM period\n");
return -EINVAL;
}
if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
- clk_pwm->fixed_rate = NSEC_PER_SEC / pwm->period;
+ clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
- if (pwm->period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
- pwm->period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
+ if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
+ pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
dev_err(&pdev->dev,
"clock-frequency does not match PWM period\n");
return -EINVAL;
}
- ret = pwm_config(pwm, (pwm->period + 1) >> 1, pwm->period);
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to the
+* atomic PWM API.
+*/
+ pwm_apply_args(pwm);
+ ret = pwm_config(pwm, (pargs.period + 1) >> 1, pargs.period);
if (ret < 0)
return ret;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/24] pwm: introduce the pwm_args concept
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition or
directly hardcoded in PWM drivers).
Create a pwm_args struct to store this reference config, so that PWM users
can differentiate the current config from the reference one.
Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to
use pwm_args instead of pwm_get_period/polarity().
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 22 +++---
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
include/linux/pwm.h| 32
4 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 7c330ff..ac89529 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -128,6 +128,14 @@ static int pwm_device_request(struct pwm_device *pwm,
const char *label)
set_bit(PWMF_REQUESTED, &pwm->flags);
pwm->label = label;
+ /*
+* FIXME: this should be removed as soon as all PWM users are
+* properly making use of pwm_args to initialize the PWM device.
+* If we don't get rid of it, then PWM state and hardware can be
+* desynchronized.
+*/
+ pwm_apply_args(pwm);
+
return 0;
}
@@ -146,12 +154,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[1]);
+ pwm->args.period = args->args[1];
if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
return pwm;
}
@@ -172,7 +180,7 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[1]);
+ pwm->args.period = args->args[1];
return pwm;
}
@@ -736,13 +744,13 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
if (!chip)
goto out;
+ pwm->args.period = chosen->period;
+ pwm->args.polarity = chosen->polarity;
+
pwm = pwm_request_from_chip(chip, chosen->index, con_id ?: dev_id);
if (IS_ERR(pwm))
goto out;
- pwm_set_period(pwm, chosen->period);
- pwm_set_polarity(pwm, chosen->polarity);
-
out:
mutex_unlock(&pwm_lookup_lock);
return pwm;
diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index a80c108..7d33542 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -60,7 +60,7 @@ static int clps711x_pwm_request(struct pwm_chip *chip, struct
pwm_device *pwm)
return -EINVAL;
/* Store constant period value */
- pwm_set_period(pwm, DIV_ROUND_CLOSEST(NSEC_PER_SEC, freq));
+ pwm->args.period = DIV_ROUND_CLOSEST(NSEC_PER_SEC, freq);
return 0;
}
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index cb2f702..58b709f 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -160,7 +160,7 @@ pxa_pwm_of_xlate(struct pwm_chip *pc, const struct
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[0]);
+ pwm->args.period = args->args[0];
return pwm;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 6555f01..c8859b7 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -74,6 +74,23 @@ enum pwm_polarity {
PWM_POLARITY_INVERSED,
};
+/**
+ * struct pwm_args - PWM arguments
+ * @period: reference period
+ * @polarity: reference polarity
+ *
+ * This structure describes board-dependent arguments attached to a PWM
+ * device. Those arguments are usually retrieved from the PWM lookup table or
+ * DT definition.
+ * This should not be confused with the PWM state: PWM args don't represent
+ * the current PWM state, but the configuration the PWM user plans to use
+ * on this PWM device.
+ */
+struct pwm_args {
+ unsigned int period;
+ enum pwm_polarity polarity;
+};
+
enum {
PWMF_REQUESTED = 1 << 0,
PWMF_ENABLED = 1 << 1,
@@ -91,6 +108,7 @@ enum {
* @period: period of the PWM signal (in nanoseconds)
* @duty_cycle: duty cycle of the PWM signal (in nanoseconds)
* @polarity: polarity of the PWM signal
+ * @args: PWM arguments
*/
struct pwm_device {
const char *label;
@@ -103,6 +121,8 @@ struct pwm_device {
unsigned int period;
unsigned int duty_cycle;
enum pwm_polarity polarity;
+
+ struct pwm_args args;
};
static inline bool pwm_is_enabled(const struc
[PATCH v5 08/24] fbdev: ssd1307fb: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
---
drivers/video/fbdev/ssd1307fb.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index fa34808..652f688 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -286,6 +286,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
{
int ret;
u32 precharge, dclk, com_invdir, compins;
+ struct pwm_args pargs;
if (par->device_info->need_pwm) {
par->pwm = pwm_get(&par->client->dev, NULL);
@@ -294,7 +295,15 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return PTR_ERR(par->pwm);
}
- par->pwm_period = pwm_get_period(par->pwm);
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to
+* the atomic PWM API.
+*/
+ pwm_apply_args(par->pwm);
+
+ pwm_get_args(par->pwm, &pargs);
+
+ par->pwm_period = pargs.period;
/* Enable the PWM */
pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
pwm_enable(par->pwm);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/24] backlight: lp855x: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver makes use of it. Signed-off-by: Boris Brezillon --- drivers/video/backlight/lp855x_bl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c index daca9e6..e5b14f5 100644 --- a/drivers/video/backlight/lp855x_bl.c +++ b/drivers/video/backlight/lp855x_bl.c @@ -246,6 +246,12 @@ static void lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br) return; lp->pwm = pwm; + + /* +* FIXME: pwm_apply_args() should be removed when switching to +* the atomic PWM API. +*/ + pwm_apply_args(pwm); } pwm_config(lp->pwm, duty, period); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/24] leds: pwm: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
Acked-by: Jacek Anaszewski
---
drivers/leds/leds-pwm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 4783bac..a9145aa 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -91,6 +91,7 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
struct led_pwm *led, struct device_node *child)
{
struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
+ struct pwm_args pargs;
int ret;
led_data->active_low = led->active_low;
@@ -117,7 +118,15 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
else
led_data->cdev.brightness_set_blocking = led_pwm_set_blocking;
- led_data->period = pwm_get_period(led_data->pwm);
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to the
+* atomic PWM API.
+*/
+ pwm_apply_args(led_data->pwm);
+
+ pwm_get_args(led_data->pwm, &pargs);
+
+ led_data->period = pargs.period;
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/24] hwmon: pwm-fan: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
Acked-by: Kamil Debski
---
drivers/hwmon/pwm-fan.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 3e23003..f9af393 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -40,15 +40,18 @@ struct pwm_fan_ctx {
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
{
+ struct pwm_args pargs;
unsigned long duty;
int ret = 0;
+ pwm_get_args(ctx->pwm, &pargs);
+
mutex_lock(&ctx->lock);
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;
- duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
- ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+ duty = DIV_ROUND_UP(pwm * (pargs.period - 1), MAX_PWM);
+ ret = pwm_config(ctx->pwm, duty, pargs.period);
if (ret)
goto exit_set_pwm_err;
@@ -215,6 +218,7 @@ static int pwm_fan_probe(struct platform_device *pdev)
{
struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct pwm_args pargs;
struct device *hwmon;
int duty_cycle;
int ret;
@@ -233,11 +237,19 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to the
+* atomic PWM API.
+*/
+ pwm_apply_args(ctx->pwm);
+
/* Set duty cycle to maximum allowed */
- duty_cycle = ctx->pwm->period - 1;
+ pwm_get_args(ctx->pwm, &pargs);
+
+ duty_cycle = pargs.period - 1;
ctx->pwm_value = MAX_PWM;
- ret = pwm_config(ctx->pwm, duty_cycle, ctx->pwm->period);
+ ret = pwm_config(ctx->pwm, duty_cycle, pargs.period);
if (ret) {
dev_err(&pdev->dev, "Failed to configure PWM\n");
return ret;
@@ -303,14 +315,16 @@ static int pwm_fan_suspend(struct device *dev)
static int pwm_fan_resume(struct device *dev)
{
struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+ struct pwm_args pargs;
unsigned long duty;
int ret;
if (ctx->pwm_value == 0)
return 0;
- duty = DIV_ROUND_UP(ctx->pwm_value * (ctx->pwm->period - 1), MAX_PWM);
- ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+ pwm_get_args(ctx->pwm, &pargs);
+ duty = DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
+ ret = pwm_config(ctx->pwm, duty, pargs.period);
if (ret)
return ret;
return pwm_enable(ctx->pwm);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/24] regulator: pwm: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
---
drivers/regulator/pwm-regulator.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index 4689d62..ffdb895 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -59,16 +59,16 @@ static int pwm_regulator_set_voltage_sel(struct
regulator_dev *rdev,
unsigned selector)
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
- unsigned int pwm_reg_period;
+ struct pwm_args pargs;
int dutycycle;
int ret;
- pwm_reg_period = pwm_get_period(drvdata->pwm);
+ pwm_get_args(drvdata->pwm, &pargs);
- dutycycle = (pwm_reg_period *
+ dutycycle = (pargs.period *
drvdata->duty_cycle_table[selector].dutycycle) / 100;
- ret = pwm_config(drvdata->pwm, dutycycle, pwm_reg_period);
+ ret = pwm_config(drvdata->pwm, dutycycle, pargs.period);
if (ret) {
dev_err(&rdev->dev, "Failed to configure PWM\n");
return ret;
@@ -138,13 +138,15 @@ static int pwm_regulator_set_voltage(struct regulator_dev
*rdev,
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
unsigned int ramp_delay = rdev->constraints->ramp_delay;
- unsigned int period = pwm_get_period(drvdata->pwm);
+ struct pwm_args pargs;
int duty_cycle;
int ret;
+ pwm_get_args(drvdata->pwm, &pargs);
duty_cycle = pwm_voltage_to_duty_cycle_percentage(rdev, min_uV);
- ret = pwm_config(drvdata->pwm, (period / 100) * duty_cycle, period);
+ ret = pwm_config(drvdata->pwm, (pargs.period / 100) * duty_cycle,
+pargs.period);
if (ret) {
dev_err(&rdev->dev, "Failed to configure PWM\n");
return ret;
@@ -281,6 +283,12 @@ static int pwm_regulator_probe(struct platform_device
*pdev)
return PTR_ERR(drvdata->pwm);
}
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to the
+* atomic PWM API.
+*/
+ pwm_apply_args(drvdata->pwm);
+
regulator = devm_regulator_register(&pdev->dev,
&drvdata->desc, &config);
if (IS_ERR(regulator)) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/24] input: misc: max77693: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
---
drivers/input/misc/max77693-haptic.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/max77693-haptic.c
b/drivers/input/misc/max77693-haptic.c
index 6d96bff..29ddeb7 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -70,10 +70,13 @@ struct max77693_haptic {
static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
{
- int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+ struct pwm_args pargs;
+ int delta;
int error;
- error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+ pwm_get_args(haptic->pwm_dev, &pargs);
+ delta = (pargs.period + haptic->pwm_duty) / 2;
+ error = pwm_config(haptic->pwm_dev, delta, pargs.period);
if (error) {
dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
return error;
@@ -234,6 +237,7 @@ static int max77693_haptic_play_effect(struct input_dev
*dev, void *data,
struct ff_effect *effect)
{
struct max77693_haptic *haptic = input_get_drvdata(dev);
+ struct pwm_args pargs;
u64 period_mag_multi;
haptic->magnitude = effect->u.rumble.strong_magnitude;
@@ -245,7 +249,8 @@ static int max77693_haptic_play_effect(struct input_dev
*dev, void *data,
* The formula to convert magnitude to pwm_duty as follows:
* - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
*/
- period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
+ pwm_get_args(haptic->pwm_dev, &pargs);
+ period_mag_multi = (u64)pargs.period * haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);
@@ -329,6 +334,12 @@ static int max77693_haptic_probe(struct platform_device
*pdev)
return PTR_ERR(haptic->pwm_dev);
}
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to the
+* atomic PWM API.
+*/
+ pwm_apply_args(haptic->pwm_dev);
+
haptic->motor_reg = devm_regulator_get(&pdev->dev, "haptic");
if (IS_ERR(haptic->motor_reg)) {
dev_err(&pdev->dev, "failed to get regulator\n");
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/24] backlight: pwm_bl: use pwm_get_args() where appropriate
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon
---
drivers/video/backlight/pwm_bl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index a33a290..b2b366b 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -201,6 +201,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
+ struct pwm_args pargs;
int ret;
if (!data) {
@@ -307,12 +308,19 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
dev_dbg(&pdev->dev, "got pwm for backlight\n");
/*
+* FIXME: pwm_apply_args() should be removed when switching to
+* the atomic PWM API.
+*/
+ pwm_apply_args(pb->pwm);
+
+ /*
* The DT case will set the pwm_period_ns field to 0 and store the
* period, parsed from the DT, in the PWM device. For the non-DT case,
* set the period from platform data if it has not already been set
* via the PWM lookup table.
*/
- pb->period = pwm_get_period(pb->pwm);
+ pwm_get_args(pb->pwm, &pargs);
+ pb->period = pargs.period;
if (!pb->period && (data->pwm_period_ns > 0))
pb->period = data->pwm_period_ns;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 12/24] backlight: lm3630a: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver makes use of it. Signed-off-by: Boris Brezillon --- drivers/video/backlight/lm3630a_bl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c index 3d16bd6..60d6c2a 100644 --- a/drivers/video/backlight/lm3630a_bl.c +++ b/drivers/video/backlight/lm3630a_bl.c @@ -424,6 +424,12 @@ static int lm3630a_probe(struct i2c_client *client, dev_err(&client->dev, "fail : get pwm device\n"); return PTR_ERR(pchip->pwmd); } + + /* +* FIXME: pwm_apply_args() should be removed when switching to +* the atomic PWM API. +*/ + pwm_apply_args(pchip->pwmd); } /* interrupt enable : irq 0 is not allowed */ -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate
On 14 April 2016 at 21:17, Boris Brezillon
wrote:
> Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
> field. Doing that will ease adaptation of the PWM framework to support
> atomic update.
>
> Signed-off-by: Boris Brezillon
> ---
> Patch generated with the following coccinelle script:
>
> --->8---
> virtual patch
>
> @@
> struct pwm_device *p;
> expression e;
> @@
> (
> -(p)->polarity = e;
> +pwm_set_polarity(p, e);
> |
> -(p)->polarity
> +pwm_get_polarity(p)
> |
> -(p)->period = e;
> +pwm_set_period(p, e);
> |
> -(p)->period
> +pwm_get_period(p)
> |
> -(p)->duty_cycle = e;
> +pwm_set_duty_cycle(p, e);
> |
> -(p)->duty_cycle
> +pwm_get_duty_cycle(p)
> )
> --->8---
> ---
> drivers/pwm/pwm-crc.c | 2 +-
> drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
> diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> index 9861fed..19dc64c 100644
> --- a/drivers/pwm/pwm-lpc18xx-sct.c
> +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> @@ -249,7 +249,7 @@ static int lpc18xx_pwm_enable(struct pwm_chip *chip,
> struct pwm_device *pwm)
>LPC18XX_PWM_EVSTATEMSK(lpc18xx_data->duty_event),
>LPC18XX_PWM_EVSTATEMSK_ALL);
>
> - if (pwm->polarity == PWM_POLARITY_NORMAL) {
> + if (pwm_get_polarity(pwm) == PWM_POLARITY_NORMAL) {
> set_event = lpc18xx_pwm->period_event;
> clear_event = lpc18xx_data->duty_event;
> res_action = LPC18XX_PWM_RES_SET;
For the lpc18xx-sct part:
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 16/24] ARM: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver makes use of it. Signed-off-by: Boris Brezillon --- arch/arm/mach-s3c24xx/mach-rx1950.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c index 774c982..25a139b 100644 --- a/arch/arm/mach-s3c24xx/mach-rx1950.c +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c @@ -496,6 +496,12 @@ static int rx1950_backlight_init(struct device *dev) return PTR_ERR(lcd_pwm); } + /* +* FIXME: pwm_apply_args() should be removed when switching to +* the atomic PWM API. +*/ + pwm_apply_args(lcd_pwm); + rx1950_lcd_power(1); rx1950_bl_power(1); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 15/24] drm: i915: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/i915/intel_panel.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 21ee647..dc3a2e4 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1640,6 +1640,12 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
return -ENODEV;
}
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to
+* the atomic PWM API.
+*/
+ pwm_apply_args(panel->backlight.pwm);
+
retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
CRC_PMIC_PWM_PERIOD_NS);
if (retval < 0) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 14/24] input: misc: pwm-beeper: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the
polarity and period are initialized according to the information provided
in pwm_args.
This is an intermediate state, and pwm_apply_args() should be dropped as
soon as the atomic PWM infrastructure is in place and the driver makes
use of it.
Signed-off-by: Boris Brezillon
---
drivers/input/misc/pwm-beeper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index f2261ab..8d71332 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -87,6 +87,12 @@ static int pwm_beeper_probe(struct platform_device *pdev)
goto err_free;
}
+ /*
+* FIXME: pwm_apply_args() should be removed when switching to
+* the atomic PWM API.
+*/
+ pwm_apply_args(beeper->pwm);
+
beeper->input = input_allocate_device();
if (!beeper->input) {
dev_err(&pdev->dev, "Failed to allocate input device\n");
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 17/24] pwm: keep PWM state in sync with hardware state
Before the introduction of pwm_args, the core was resetting the PWM period
and polarity states to the reference values (those provided through the
DT, a PWM lookup table or hardcoded in the driver).
Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in
pwm_device_request().
We can also get rid of the pwm_set_period() call done in
pwm_apply_args(), because PWM users are now directly using pargs->period
instead of pwm_get_period(). By doing that we avoid messing with the
current PWM period.
The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 8
include/linux/pwm.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ac89529..26c3cf5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -128,14 +128,6 @@ static int pwm_device_request(struct pwm_device *pwm,
const char *label)
set_bit(PWMF_REQUESTED, &pwm->flags);
pwm->label = label;
- /*
-* FIXME: this should be removed as soon as all PWM users are
-* properly making use of pwm_args to initialize the PWM device.
-* If we don't get rid of it, then PWM state and hardware can be
-* desynchronized.
-*/
- pwm_apply_args(pwm);
-
return 0;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index c8859b7..2f500a5 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -170,7 +170,6 @@ static inline void pwm_get_args(const struct pwm_device
*pwm,
static inline void pwm_apply_args(struct pwm_device *pwm)
{
- pwm_set_period(pwm, pwm->args.period);
pwm_set_polarity(pwm, pwm->args.polarity);
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 20/24] pwm: add the PWM initial state retrieval infra
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 3 +++
include/linux/pwm.h | 28
2 files changed, 31 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index c2759bc..0e7f687 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -270,6 +270,9 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->hwpwm = i;
pwm->state.polarity = polarity;
+ if (chip->ops->get_state)
+ chip->ops->get_state(chip, pwm, &pwm->state);
+
radix_tree_insert(&pwm_tree, pwm->pwm, pwm);
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 7bfeacf..73ca679 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -205,6 +205,29 @@ static inline void pwm_get_args(const struct pwm_device
*pwm,
static inline void pwm_apply_args(struct pwm_device *pwm)
{
+ /*
+* PWM users calling pwm_apply_args() expect to have a fresh config
+* where the polarity and period are set according to pwm_args info.
+* The problem is, polarity can only be changed when the PWM is
+* disabled.
+*
+* PWM drivers supporting hardware readout may declare the PWM device
+* as enabled, and prevent polarity setting, which changes from the
+* existing behavior, where all PWM devices are declared as disabled
+* at startup (even if they are actually enabled), thus authorizing
+* polarity setting.
+*
+* Instead of setting ->enabled to false, we call pwm_disable()
+* before pwm_set_polarity() to ensure that everything is configured
+* as expected, and the PWM is really disabled when the user request
+* it.
+*
+* Note that PWM users requiring a smooth handover between the
+* bootloader and the kernel (like critical regulators controlled by
+* PWM devices) will have to switch to the atomic API and avoid calling
+* pwm_apply_args().
+*/
+ pwm_disable(pwm);
pwm_set_polarity(pwm, pwm->args.polarity);
}
@@ -216,6 +239,9 @@ static inline void pwm_apply_args(struct pwm_device *pwm)
* @set_polarity: configure the polarity of this PWM
* @enable: enable PWM output toggling
* @disable: disable PWM output toggling
+ * @get_state: get the current PWM state. This function is only
+ *called once per PWM device when the PWM chip is
+ *registered.
* @dbg_show: optional routine to show contents in debugfs
* @owner: helps prevent removal of modules exporting active PWMs
*/
@@ -228,6 +254,8 @@ struct pwm_ops {
enum pwm_polarity polarity);
int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
+ void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state);
#ifdef CONFIG_DEBUG_FS
void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);
#endif
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 18/24] pwm: introduce the pwm_state concept
The PWM state, represented by its period, duty_cycle and polarity,
is currently directly stored in the PWM device.
Declare a pwm_state structure embedding those field so that we can later
use this struct to atomically update all the PWM parameters at once.
All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 8
include/linux/pwm.h | 54 +
2 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 26c3cf5..59bcece 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->chip = chip;
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
- pwm->polarity = polarity;
+ pwm->state.polarity = polarity;
radix_tree_insert(&pwm_tree, pwm->pwm, pwm);
}
@@ -446,8 +446,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int
period_ns)
if (err)
return err;
- pwm->duty_cycle = duty_ns;
- pwm->period = period_ns;
+ pwm->state.duty_cycle = duty_ns;
+ pwm->state.period = period_ns;
return 0;
}
@@ -480,7 +480,7 @@ int pwm_set_polarity(struct pwm_device *pwm, enum
pwm_polarity polarity)
if (err)
return err;
- pwm->polarity = polarity;
+ pwm->state.polarity = polarity;
return 0;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2f500a5..3022c05 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -97,6 +97,18 @@ enum {
PWMF_EXPORTED = 1 << 2,
};
+/*
+ * struct pwm_state - state of a PWM channel
+ * @period: PWM period (in nanoseconds)
+ * @duty_cycle: PWM duty cycle (in nanoseconds)
+ * @polarity: PWM polarity
+ */
+struct pwm_state {
+ unsigned int period;
+ unsigned int duty_cycle;
+ enum pwm_polarity polarity;
+};
+
/**
* struct pwm_device - PWM channel object
* @label: name of the PWM device
@@ -105,10 +117,8 @@ enum {
* @pwm: global index of the PWM device
* @chip: PWM chip providing this PWM device
* @chip_data: chip-private data associated with the PWM device
- * @period: period of the PWM signal (in nanoseconds)
- * @duty_cycle: duty cycle of the PWM signal (in nanoseconds)
- * @polarity: polarity of the PWM signal
* @args: PWM arguments
+ * @state: curent PWM channel state
*/
struct pwm_device {
const char *label;
@@ -118,13 +128,21 @@ struct pwm_device {
struct pwm_chip *chip;
void *chip_data;
- unsigned int period;
- unsigned int duty_cycle;
- enum pwm_polarity polarity;
-
struct pwm_args args;
+ struct pwm_state state;
};
+/**
+ * pwm_get_state() - retrieve the current PWM state
+ * @pwm: PWM device
+ * @state: state to fill with the current PWM state
+ */
+static inline void pwm_get_state(const struct pwm_device *pwm,
+struct pwm_state *state)
+{
+ *state = pwm->state;
+}
+
static inline bool pwm_is_enabled(const struct pwm_device *pwm)
{
return test_bit(PWMF_ENABLED, &pwm->flags);
@@ -133,23 +151,31 @@ static inline bool pwm_is_enabled(const struct pwm_device
*pwm)
static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
{
if (pwm)
- pwm->period = period;
+ pwm->state.period = period;
}
static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
{
- return pwm ? pwm->period : 0;
+ struct pwm_state state;
+
+ pwm_get_state(pwm, &state);
+
+ return state.period;
}
static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int
duty)
{
if (pwm)
- pwm->duty_cycle = duty;
+ pwm->state.duty_cycle = duty;
}
static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
{
- return pwm ? pwm->duty_cycle : 0;
+ struct pwm_state state;
+
+ pwm_get_state(pwm, &state);
+
+ return state.duty_cycle;
}
/*
@@ -159,7 +185,11 @@ int pwm_set_polarity(struct pwm_device *pwm, enum
pwm_polarity polarity);
static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
{
- return pwm ? pwm->polarity : PWM_POLARITY_NORMAL;
+ struct pwm_state state;
+
+ pwm_get_state(pwm, &state);
+
+ return state.polarity;
}
static inline void pwm_get_args(const struct pwm_device *pwm,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 22/24] pwm: update documentation
Update the PWM subsystem documentation to reflect the atomic PWM changes.
Signed-off-by: Boris Brezillon
---
Documentation/pwm.txt | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index ca895fd..789b27c 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -42,9 +42,26 @@ variants of these functions, devm_pwm_get() and
devm_pwm_put(), also exist.
After being requested, a PWM has to be configured using:
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
+int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
-To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
+This API controls both the PWM period/duty_cycle config and the
+enable/disable state.
+
+The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
+around pwm_apply_state() and should not be used if the user wants to change
+several parameter at once. For example, if you see pwm_config() and
+pwm_{enable,disable}() calls in the same function, this probably means you
+should switch to pwm_apply_state().
+
+The PWM user API also allows one to query the PWM state with pwm_get_state().
+
+In addition to the PWM state, the PWM API also exposes PWM arguments, which
+are the reference PWM config one should use on this PWM.
+PWM arguments are usually platform-specific and allows the PWM user to only
+care about dutycycle relatively to the full period (like, duty = 50% of the
+period). struct pwm_args contains 2 fields (period and polarity) and should
+be used to set the initial PWM config (usually done in the probe function
+of the PWM user). PWM arguments are retrieved with pwm_get_args().
Using PWMs with the sysfs interface
---
@@ -105,6 +122,15 @@ goes low for the remainder of the period. Conversely, a
signal with inversed
polarity starts low for the duration of the duty cycle and goes high for the
remainder of the period.
+Drivers are encouraged to implement ->apply() instead of the legacy
+->enable(), ->disable() and ->config() methods. Doing that should provide
+atomicity in the PWM config workflow, which is required when the PWM controls
+a critical device (like a regulator).
+
+The implementation of ->get_state() (a method used to retrieve initial PWM
+state) is also encouraged for the same reason: letting the PWM user know
+about the current PWM state would allow him to avoid glitches.
+
Locking
---
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 21/24] pwm: add the core infrastructure to allow atomic update
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic update.
This method will be preferred over the ->enable(), ->disable() and
->config() methods if available.
Add the pwm_apply_state() function to the PWM user API.
Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.
pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.
pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 186 +++-
include/linux/pwm.h | 269 +++-
2 files changed, 302 insertions(+), 153 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 0e7f687..112a696 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -226,6 +226,19 @@ void *pwm_get_chip_data(struct pwm_device *pwm)
}
EXPORT_SYMBOL_GPL(pwm_get_chip_data);
+static bool pwm_ops_check(const struct pwm_ops *ops)
+{
+ /* driver supports legacy, non-atomic operation */
+ if (ops->config && ops->enable && ops->disable)
+ return true;
+
+ /* driver supports atomic operation */
+ if (ops->apply)
+ return true;
+
+ return false;
+}
+
/**
* pwmchip_add_with_polarity() - register a new PWM chip
* @chip: the PWM chip to add
@@ -244,8 +257,10 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
unsigned int i;
int ret;
- if (!chip || !chip->dev || !chip->ops || !chip->ops->config ||
- !chip->ops->enable || !chip->ops->disable || !chip->npwm)
+ if (!chip || !chip->dev || !chip->ops || !chip->npwm)
+ return -EINVAL;
+
+ if (!pwm_ops_check(chip->ops))
return -EINVAL;
mutex_lock(&pwm_lock);
@@ -431,102 +446,137 @@ void pwm_free(struct pwm_device *pwm)
EXPORT_SYMBOL_GPL(pwm_free);
/**
- * pwm_config() - change a PWM device configuration
+ * pwm_apply_state() - atomically apply a new state to a PWM device
* @pwm: PWM device
- * @duty_ns: "on" time (in nanoseconds)
- * @period_ns: duration (in nanoseconds) of one cycle
- *
- * Returns: 0 on success or a negative error code on failure.
+ * @state: new state to apply. This can be adjusted by the PWM driver
+ *if the requested config is not achievable, for example,
+ *->duty_cycle and ->period might be approximated.
*/
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state)
{
int err;
- if (!pwm || duty_ns < 0 || period_ns <= 0 || duty_ns > period_ns)
+ if (!pwm)
return -EINVAL;
- err = pwm->chip->ops->config(pwm->chip, pwm, duty_ns, period_ns);
- if (err)
- return err;
-
- pwm->state.duty_cycle = duty_ns;
- pwm->state.period = period_ns;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(pwm_config);
+ if (!memcmp(state, &pwm->state, sizeof(*state)))
+ return 0;
-/**
- * pwm_set_polarity() - configure the polarity of a PWM signal
- * @pwm: PWM device
- * @polarity: new polarity of the PWM signal
- *
- * Note that the polarity cannot be configured while the PWM device is
- * enabled.
- *
- * Returns: 0 on success or a negative error code on failure.
- */
-int pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
-{
- int err;
+ if (pwm->chip->ops->apply) {
+ err = pwm->chip->ops->apply(pwm->chip, pwm, state);
+ if (err)
+ return err;
- if (!pwm || !pwm->chip->ops)
- return -EINVAL;
+ pwm->state = *state;
+ } else {
+ /*
+* FIXME: restore the initial state in case of error.
+*/
+ if (state->polarity != pwm->state.polarity) {
+ if (!pwm->chip->ops->set_polarity)
+ return -ENOTSUPP;
+
+ /*
+* Changing the polarity of a running PWM is
+* only allowed when the PWM driver implements
+* ->apply().
+*/
+ if (pwm->state.enabled) {
+ pwm->chip->ops->disable(pwm->chip, pwm);
+ pwm->state.enabled = false;
+ }
+
+ err = pwm->chip->ops->set_polarity(pwm->chip, pwm,
+ state->polarity);
+ if (err)
+
[PATCH v5 23/24] pwm: switch to the atomic API
Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 5 -
drivers/pwm/sysfs.c | 61 +++--
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 112a696..aefffcf 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -947,13 +947,16 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct
seq_file *s)
for (i = 0; i < chip->npwm; i++) {
struct pwm_device *pwm = &chip->pwms[i];
+ struct pwm_state state;
+
+ pwm_get_state(pwm, &state);
seq_printf(s, " pwm-%-3d (%-20.20s):", i, pwm->label);
if (test_bit(PWMF_REQUESTED, &pwm->flags))
seq_puts(s, " requested");
- if (pwm_is_enabled(pwm))
+ if (state.enabled)
seq_puts(s, " enabled");
seq_puts(s, "\n");
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index ab28c89..40daf1c 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -47,13 +47,13 @@ static ssize_t period_show(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
const struct pwm_device *pwm = export->pwm;
- unsigned int period;
+ struct pwm_state state;
mutex_lock(&export->lock);
- period = pwm_get_period(pwm);
+ pwm_get_state(pwm, &state);
mutex_unlock(&export->lock);
- return sprintf(buf, "%u\n", period);
+ return sprintf(buf, "%u\n", state.period);
}
static ssize_t period_store(struct device *child,
@@ -62,6 +62,7 @@ static ssize_t period_store(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
struct pwm_device *pwm = export->pwm;
+ struct pwm_state state;
unsigned int val;
int ret;
@@ -70,7 +71,9 @@ static ssize_t period_store(struct device *child,
return ret;
mutex_lock(&export->lock);
- ret = pwm_config(pwm, pwm_get_duty_cycle(pwm), val);
+ pwm_get_state(pwm, &state);
+ state.period = val;
+ ret = pwm_apply_state(pwm, &state);
mutex_unlock(&export->lock);
return ret ? : size;
@@ -82,13 +85,13 @@ static ssize_t duty_cycle_show(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
const struct pwm_device *pwm = export->pwm;
- unsigned int duty;
+ struct pwm_state state;
mutex_lock(&export->lock);
- duty = pwm_get_duty_cycle(pwm);
+ pwm_get_state(pwm, &state);
mutex_unlock(&export->lock);
- return sprintf(buf, "%u\n", duty);
+ return sprintf(buf, "%u\n", state.duty_cycle);
}
static ssize_t duty_cycle_store(struct device *child,
@@ -97,6 +100,7 @@ static ssize_t duty_cycle_store(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
struct pwm_device *pwm = export->pwm;
+ struct pwm_state state;
unsigned int val;
int ret;
@@ -105,7 +109,9 @@ static ssize_t duty_cycle_store(struct device *child,
return ret;
mutex_lock(&export->lock);
- ret = pwm_config(pwm, val, pwm_get_period(pwm));
+ pwm_get_state(pwm, &state);
+ state.duty_cycle = val;
+ ret = pwm_apply_state(pwm, &state);
mutex_unlock(&export->lock);
return ret ? : size;
@@ -117,13 +123,13 @@ static ssize_t enable_show(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
const struct pwm_device *pwm = export->pwm;
- bool enabled;
+ struct pwm_state state;
mutex_lock(&export->lock);
- enabled = pwm_is_enabled(pwm);
+ pwm_get_state(pwm, &state);
mutex_unlock(&export->lock);
- return sprintf(buf, "%d\n", enabled);
+ return sprintf(buf, "%d\n", state.enabled);
}
static ssize_t enable_store(struct device *child,
@@ -132,24 +138,20 @@ static ssize_t enable_store(struct device *child,
{
struct pwm_export *export = child_to_pwm_export(child);
struct pwm_device *pwm = export->pwm;
+ struct pwm_state state;
int val, ret;
ret = kstrtoint(buf, 0, &val);
if (ret)
return ret;
+ if (val != 0 && val != 1)
+ return -EINVAL;
+
mutex_lock(&export->lock);
- switch (val) {
- case 0:
- pwm_disable(pwm);
- break;
- case 1:
- ret = pwm_enable(pwm);
- break;
- default:
- ret = -EINVAL;
- break;
- }
+ pwm_get_state(pwm, &state);
+ state.enabled = val;
+ ret = pwm_apply_state(pwm, &state);
mutex_unlock(&export->lock);
return ret ? : size;
@@ -162,9 +1
[PATCH v5 24/24] pwm: add information about polarity, duty cycle and period to debugfs
From: Heiko Stübner The pwm-states make it possible to also output the polarity, duty cycle and period information in the debugfs pwm summary-outout. This makes it easier to gather overview information about pwms without needing to walk through the sysfs attributes of every pwm. Signed-off-by: Heiko Stuebner Signed-off-by: Boris Brezillon --- drivers/pwm/core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index aefffcf..9f4e97e 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -959,6 +959,11 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s) if (state.enabled) seq_puts(s, " enabled"); + seq_printf(s, " period:%uns", state.period); + seq_printf(s, " duty:%uns", state.duty_cycle); + seq_printf(s, " polarity:%s", + state.polarity ? "inverse" : "normal"); + seq_puts(s, "\n"); } } -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 13/24] input: misc: max8997: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver makes use of it. Signed-off-by: Boris Brezillon --- drivers/input/misc/max8997_haptic.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/input/misc/max8997_haptic.c b/drivers/input/misc/max8997_haptic.c index a806ba3..bf17f65 100644 --- a/drivers/input/misc/max8997_haptic.c +++ b/drivers/input/misc/max8997_haptic.c @@ -304,6 +304,12 @@ static int max8997_haptic_probe(struct platform_device *pdev) error); goto err_free_mem; } + + /* +* FIXME: pwm_apply_args() should be removed when switching to +* the atomic PWM API. +*/ + pwm_apply_args(chip->pwm); break; default: -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 10/24] backlight: lp8788: explicitly apply PWM config extracted from pwm_args
Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver makes use of it. Signed-off-by: Boris Brezillon --- drivers/video/backlight/lp8788_bl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/video/backlight/lp8788_bl.c b/drivers/video/backlight/lp8788_bl.c index 5d583d7..cf869ec 100644 --- a/drivers/video/backlight/lp8788_bl.c +++ b/drivers/video/backlight/lp8788_bl.c @@ -145,6 +145,12 @@ static void lp8788_pwm_ctrl(struct lp8788_bl *bl, int br, int max_br) } bl->pwm = pwm; + + /* +* FIXME: pwm_apply_args() should be removed when switching to +* the atomic PWM API. +*/ + pwm_apply_args(pwm); } pwm_config(bl->pwm, duty, period); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 19/24] pwm: move the enabled/disabled info into pwm_state
Prepare the transition to PWM atomic update by moving the enabled/disabled
state into the pwm_state struct. This way we can easily update the whole
PWM state by copying the new state in the ->state field.
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 13 +
include/linux/pwm.h | 11 ---
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 59bcece..c2759bc 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -499,10 +499,10 @@ int pwm_enable(struct pwm_device *pwm)
if (!pwm)
return -EINVAL;
- if (!test_and_set_bit(PWMF_ENABLED, &pwm->flags)) {
+ if (!pwm_is_enabled(pwm)) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
- if (err)
- clear_bit(PWMF_ENABLED, &pwm->flags);
+ if (!err)
+ pwm->state.enabled = true;
}
return err;
@@ -515,8 +515,13 @@ EXPORT_SYMBOL_GPL(pwm_enable);
*/
void pwm_disable(struct pwm_device *pwm)
{
- if (pwm && test_and_clear_bit(PWMF_ENABLED, &pwm->flags))
+ if (!pwm)
+ return;
+
+ if (pwm_is_enabled(pwm)) {
pwm->chip->ops->disable(pwm->chip, pwm);
+ pwm->state.enabled = false;
+ }
}
EXPORT_SYMBOL_GPL(pwm_disable);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 3022c05..7bfeacf 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -93,8 +93,7 @@ struct pwm_args {
enum {
PWMF_REQUESTED = 1 << 0,
- PWMF_ENABLED = 1 << 1,
- PWMF_EXPORTED = 1 << 2,
+ PWMF_EXPORTED = 1 << 1,
};
/*
@@ -102,11 +101,13 @@ enum {
* @period: PWM period (in nanoseconds)
* @duty_cycle: PWM duty cycle (in nanoseconds)
* @polarity: PWM polarity
+ * @enabled: PWM enabled status
*/
struct pwm_state {
unsigned int period;
unsigned int duty_cycle;
enum pwm_polarity polarity;
+ bool enabled;
};
/**
@@ -145,7 +146,11 @@ static inline void pwm_get_state(const struct pwm_device
*pwm,
static inline bool pwm_is_enabled(const struct pwm_device *pwm)
{
- return test_bit(PWMF_ENABLED, &pwm->flags);
+ struct pwm_state state;
+
+ pwm_get_state(pwm, &state);
+
+ return state.enabled;
}
static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/24] pwm: add support for atomic update
Hello, This series adds support for atomic PWM update, or IOW, the capability to update all the parameters of a PWM device (enabled/disabled, period, duty and polarity) in one go. It also adds support for initial PWM state retrieval (or hardware readout), which should allow smooth handover between the bootloader and Linux. For example, critical PWM users (like critical regulators controlled by a PWM) can query the current PWM state, and adapt the PWM config without having to disable/enable the PWM, or abruptly change the period/dutycyle/polarity config. In this version, I dropped all patches converting PWM users and PWM drivers to the atomic API in order to limit the number of patches and ease review. I plan to send the remaining patches once these ones have been accepted. If you want to test the series, or see the big picture, you can have a look at this branch [1]. Best Regards, Boris [1]https://github.com/bbrezillon/linux-rk/tree/atomic-pwm Changes since v5: - fix bugs in pwm_apply_state() implementation - drop already applied patches - s/pstate/state/ - add pwm_apply_args() helper - limit the series to core changes and required changes in PWM users code Changes since v4: - introduce pwm_args to expose per-board/platform config - deprecate non-atomic APIs - implement non-atomic functions as wrappers around atomic ones - patch all PWM users to use the atomic API - rename the ->reset_state() hook into ->get_state() - drop most acks - rework PWM config in the pwm-regulator driver - patch sun4i and sti PWM drivers to support HW readout Changes since v3: - rebased on pwm/for-next after pulling 4.4-rc1 - replace direct access to pwm fields by pwm_get/set_xxx() helpers, thus fixing some build errors - split changes to allow each maintainer to review/ack or take the modification through its subsystem Changes since v2: - rebased on top of 4.3-rc2 - reintroduced pwm-regulator patches Changes since v1: - dropped applied patches - squashed Heiko's fixes into the rockchip driver changes - made a few cosmetic changes - added kerneldoc comments - added Heiko's patch to display more information in debugfs - dropped pwm-regulator patches (should be submitted separately) Boris Brezillon (23): pwm: introduce the pwm_args concept pwm: use pwm_get/set_xxx() helpers where appropriate clk: pwm: use pwm_get_args() where appropriate hwmon: pwm-fan: use pwm_get_args() where appropriate input: misc: max77693: use pwm_get_args() where appropriate leds: pwm: use pwm_get_args() where appropriate regulator: pwm: use pwm_get_args() where appropriate fbdev: ssd1307fb: use pwm_get_args() where appropriate backlight: pwm_bl: use pwm_get_args() where appropriate backlight: lp8788: explicitly apply PWM config extracted from pwm_args backlight: lp855x: explicitly apply PWM config extracted from pwm_args backlight: lm3630a: explicitly apply PWM config extracted from pwm_args input: misc: max8997: explicitly apply PWM config extracted from pwm_args input: misc: pwm-beeper: explicitly apply PWM config extracted from pwm_args drm: i915: explicitly apply PWM config extracted from pwm_args ARM: explicitly apply PWM config extracted from pwm_args pwm: keep PWM state in sync with hardware state pwm: introduce the pwm_state concept pwm: move the enabled/disabled info into pwm_state pwm: add the PWM initial state retrieval infra pwm: add the core infrastructure to allow atomic update pwm: update documentation pwm: switch to the atomic API Heiko Stübner (1): pwm: add information about polarity, duty cycle and period to debugfs Documentation/pwm.txt| 30 +++- arch/arm/mach-s3c24xx/mach-rx1950.c | 6 + drivers/clk/clk-pwm.c| 17 +- drivers/gpu/drm/i915/intel_panel.c | 6 + drivers/hwmon/pwm-fan.c | 26 ++- drivers/input/misc/max77693-haptic.c | 17 +- drivers/input/misc/max8997_haptic.c | 6 + drivers/input/misc/pwm-beeper.c | 6 + drivers/leds/leds-pwm.c | 11 +- drivers/pwm/core.c | 214 ++ drivers/pwm/pwm-clps711x.c | 2 +- drivers/pwm/pwm-crc.c| 2 +- drivers/pwm/pwm-lpc18xx-sct.c| 2 +- drivers/pwm/pwm-omap-dmtimer.c | 2 +- drivers/pwm/pwm-pxa.c| 2 +- drivers/pwm/pwm-sun4i.c | 3 +- drivers/pwm/sysfs.c | 61 --- drivers/regulator/pwm-regulator.c| 20 ++- drivers/video/backlight/lm3630a_bl.c | 6 + drivers/video/backlight/lp855x_bl.c | 6 + drivers/video/backlight/lp8788_bl.c | 6 + drivers/video/backlight/pwm_bl.c | 10 +- drivers/video/fbdev/ssd1307fb.c | 11 +- include/linux/pwm.h | 335 +++ 24 files changed, 606 insertions(+), 201 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.o
Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.
On Tue, Apr 12, 2016 at 05:12:55PM -0500, ttha...@opensource.altera.com wrote: > This patch set adds the memory initialization functions for Altera's > Arria10 peripherals, the first of which is the Ethernet EDAC. The > first 3 patches add the memory initialization functionality. The > last 3 patches add Ethernet EDAC support. The ethernet part seems a bit strange to me to put under EDAC as EDAC is primarily memory controller ECC (and caches to some extent). Also you would not halt the system in case of an UC, but rather just drop the frame. This would need to be part of the ethernet driver in that case. Of course, given that ethernet frames already have a CRC, ECC of the FIFO seems a bit redundant. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] procfs: expose umask in /proc//status
On 04/14/2016 01:08 PM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status line ("Umask") in /proc//status. It contains
> the file mode creation mask (umask) in octal. It is only shown for
> tasks which have task->fs.
>
> This patch is adapted from one originally written by Pierre Carrier.
>
> Signed-off-by: Richard W.M. Jones
Acked-by: Jerome Marchand
> ---
> Documentation/filesystems/proc.txt | 1 +
> fs/proc/array.c| 20 +++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> index 7f5607a..e8d0075 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
> TracerPid PID of process tracing this process (0 if not)
> Uid Real, effective, saved set, and file system
> UIDs
> Gid Real, effective, saved set, and file system
> GIDs
> + Umask file mode creation mask
> FDSize number of file descriptor slots currently
> allocated
> Groups supplementary group list
> NStgid descendant namespace thread group ID hierarchy
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index b6c00ce..88c7de1 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -83,6 +83,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -139,12 +140,25 @@ static inline const char *get_task_state(struct
> task_struct *tsk)
> return task_state_array[fls(state)];
> }
>
> +static inline int get_task_umask(struct task_struct *tsk)
> +{
> + struct fs_struct *fs;
> + int umask = -ENOENT;
> +
> + task_lock(tsk);
> + fs = tsk->fs;
> + if (fs)
> + umask = fs->umask;
> + task_unlock(tsk);
> + return umask;
> +}
> +
> static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *p)
> {
> struct user_namespace *user_ns = seq_user_ns(m);
> struct group_info *group_info;
> - int g;
> + int g, umask;
> struct task_struct *tracer;
> const struct cred *cred;
> pid_t ppid, tpid = 0, tgid, ngid;
> @@ -162,6 +176,10 @@ static inline void task_state(struct seq_file *m, struct
> pid_namespace *ns,
> ngid = task_numa_group_id(p);
> cred = get_task_cred(p);
>
> + umask = get_task_umask(p);
> + if (umask >= 0)
> + seq_printf(m, "Umask:\t%#04o\n", umask);
> +
> task_lock(p);
> if (p->files)
> max_fds = files_fdtable(p->files)->max_fds;
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2] procfs: expose umask in /proc//status
On Thu, Apr 14, 2016 at 2:08 PM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status line ("Umask") in /proc//status. It contains
> the file mode creation mask (umask) in octal. It is only shown for
> tasks which have task->fs.
>
> This patch is adapted from one originally written by Pierre Carrier.
>
> Signed-off-by: Richard W.M. Jones
Acked-by: Konstantin Khlebnikov
> ---
> Documentation/filesystems/proc.txt | 1 +
> fs/proc/array.c| 20 +++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> index 7f5607a..e8d0075 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
> TracerPid PID of process tracing this process (0 if not)
> Uid Real, effective, saved set, and file system
> UIDs
> Gid Real, effective, saved set, and file system
> GIDs
> + Umask file mode creation mask
> FDSize number of file descriptor slots currently
> allocated
> Groups supplementary group list
> NStgid descendant namespace thread group ID hierarchy
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index b6c00ce..88c7de1 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -83,6 +83,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -139,12 +140,25 @@ static inline const char *get_task_state(struct
> task_struct *tsk)
> return task_state_array[fls(state)];
> }
>
> +static inline int get_task_umask(struct task_struct *tsk)
> +{
> + struct fs_struct *fs;
> + int umask = -ENOENT;
> +
> + task_lock(tsk);
> + fs = tsk->fs;
> + if (fs)
> + umask = fs->umask;
> + task_unlock(tsk);
> + return umask;
> +}
> +
> static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *p)
> {
> struct user_namespace *user_ns = seq_user_ns(m);
> struct group_info *group_info;
> - int g;
> + int g, umask;
> struct task_struct *tracer;
> const struct cred *cred;
> pid_t ppid, tpid = 0, tgid, ngid;
> @@ -162,6 +176,10 @@ static inline void task_state(struct seq_file *m, struct
> pid_namespace *ns,
> ngid = task_numa_group_id(p);
> cred = get_task_cred(p);
>
> + umask = get_task_umask(p);
> + if (umask >= 0)
> + seq_printf(m, "Umask:\t%#04o\n", umask);
> +
> task_lock(p);
> if (p->files)
> max_fds = files_fdtable(p->files)->max_fds;
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] procfs: expose umask in /proc//status
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add a new status line ("Umask") in /proc//status. It contains
the file mode creation mask (umask) in octal. It is only shown for
tasks which have task->fs.
This patch is adapted from one originally written by Pierre Carrier.
Signed-off-by: Richard W.M. Jones
---
Documentation/filesystems/proc.txt | 1 +
fs/proc/array.c| 20 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 7f5607a..e8d0075 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
+ Umask file mode creation mask
FDSize number of file descriptor slots currently
allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
diff --git a/fs/proc/array.c b/fs/proc/array.c
index b6c00ce..88c7de1 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -83,6 +83,7 @@
#include
#include
#include
+#include
#include
#include
@@ -139,12 +140,25 @@ static inline const char *get_task_state(struct
task_struct *tsk)
return task_state_array[fls(state)];
}
+static inline int get_task_umask(struct task_struct *tsk)
+{
+ struct fs_struct *fs;
+ int umask = -ENOENT;
+
+ task_lock(tsk);
+ fs = tsk->fs;
+ if (fs)
+ umask = fs->umask;
+ task_unlock(tsk);
+ return umask;
+}
+
static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *p)
{
struct user_namespace *user_ns = seq_user_ns(m);
struct group_info *group_info;
- int g;
+ int g, umask;
struct task_struct *tracer;
const struct cred *cred;
pid_t ppid, tpid = 0, tgid, ngid;
@@ -162,6 +176,10 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
ngid = task_numa_group_id(p);
cred = get_task_cred(p);
+ umask = get_task_umask(p);
+ if (umask >= 0)
+ seq_printf(m, "Umask:\t%#04o\n", umask);
+
task_lock(p);
if (p->files)
max_fds = files_fdtable(p->files)->max_fds;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] procfs: expose umask in /proc//status
v1 -> v2:
- Change printf format to %#04o.
- Retest and update examples accordingly.
--
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add a new status line ("Umask") in /proc//status. It contains
the file mode creation mask (umask) in octal. It is only shown for
tasks which have task->fs.
For the library this allows me to read the umask from
/proc/self/status.
This patch is adapted from one originally written by Pierre Carrier:
https://lkml.org/lkml/2012/5/4/451
Example usage:
$ grep Umask /proc/1/status
Umask: 0022
$ grep Umask /proc/2/status
Umask: 0022
$ grep Umask /proc/self/status
Umask: 0022
$ umask 002
$ grep Umask /proc/self/status
Umask: 0002
Rich.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 01/46] pwm: rcar: make use of pwm_is_enabled()
Hi Thierry
On Tue, 12 Apr 2016 13:01:52 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:24PM +0200, Boris Brezillon wrote:
> > Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
> > new function to test whether a PWM device is enabled or not without
> > manipulating PWM internal fields.
> > Hiding this is necessary if we want to smoothly move to the atomic PWM
> > config approach without impacting PWM drivers.
> > Fix this driver to use pwm_is_enabled() instead of directly accessing the
> > ->flags field.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/pwm/pwm-rcar.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied, thanks.
I'd like to rebase my atomic series on top of pwm/for-next but I don't
see the 4 patches you said you applied. Did you forget to push
your local branch, or did you decide to revert them based on Lee's
comments?
Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] procfs: expose umask in /proc//status
On 04/14/2016 11:34 AM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status line ("Umask") in /proc//status. It contains
> the file mode creation mask (umask) in octal. It is only shown for
> tasks which have task->fs.
>
> This patch is adapted from one originally written by Pierre Carrier.
>
> Signed-off-by: Richard W.M. Jones
> ---
> Documentation/filesystems/proc.txt | 1 +
> fs/proc/array.c| 20 +++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> index 7f5607a..e8d0075 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
> TracerPid PID of process tracing this process (0 if not)
> Uid Real, effective, saved set, and file system
> UIDs
> Gid Real, effective, saved set, and file system
> GIDs
> + Umask file mode creation mask
> FDSize number of file descriptor slots currently
> allocated
> Groups supplementary group list
> NStgid descendant namespace thread group ID hierarchy
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index b6c00ce..03e8d3f 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -83,6 +83,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -139,12 +140,25 @@ static inline const char *get_task_state(struct
> task_struct *tsk)
> return task_state_array[fls(state)];
> }
>
> +static inline int get_task_umask(struct task_struct *tsk)
> +{
> + struct fs_struct *fs;
> + int umask = -ENOENT;
> +
> + task_lock(tsk);
> + fs = tsk->fs;
> + if (fs)
> + umask = fs->umask;
> + task_unlock(tsk);
> + return umask;
> +}
> +
> static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *p)
> {
> struct user_namespace *user_ns = seq_user_ns(m);
> struct group_info *group_info;
> - int g;
> + int g, umask;
> struct task_struct *tracer;
> const struct cred *cred;
> pid_t ppid, tpid = 0, tgid, ngid;
> @@ -162,6 +176,10 @@ static inline void task_state(struct seq_file *m, struct
> pid_namespace *ns,
> ngid = task_numa_group_id(p);
> cred = get_task_cred(p);
>
> + umask = get_task_umask(p);
> + if (umask >= 0)
> + seq_printf(m, "Umask:\t0%o\n", umask);
It seems to me that umasks are usually displayed in the form 0XXX, such
as the output of umask command. So what about:
seq_printf(m, "Umask:\t%#04o\n", umask);
Provided printk() supports those flags, of course.
Thanks,
Jerome
> +
> task_lock(p);
> if (p->files)
> max_fds = files_fdtable(p->files)->max_fds;
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)
On Thu, Apr 14, 2016 at 10:34:48AM +0100, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
>
> Add a new status line ("Umask") in /proc//status. It contains
> the file mode creation mask (umask) in octal. It is only shown for
> tasks which have task->fs.
>
> For the library this allows me to read the umask from
> /proc/self/status.
>
> This patch is adapted from one originally written by Pierre Carrier:
> https://lkml.org/lkml/2012/5/4/451
Sorry, I meant to add an example of what this looks like:
$ grep Umask /proc/1/status
Umask:022
$ grep Umask /proc/2/status
Umask:022
$ grep Umask /proc/self/status
Umask:022
$ umask 002
$ grep Umask /proc/self/status
Umask:02
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add a new status line ("Umask") in /proc//status. It contains
the file mode creation mask (umask) in octal. It is only shown for
tasks which have task->fs.
For the library this allows me to read the umask from
/proc/self/status.
This patch is adapted from one originally written by Pierre Carrier:
https://lkml.org/lkml/2012/5/4/451
Rich.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] procfs: expose umask in /proc//status
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especially if the main program might be multithreaded.
Add a new status line ("Umask") in /proc//status. It contains
the file mode creation mask (umask) in octal. It is only shown for
tasks which have task->fs.
This patch is adapted from one originally written by Pierre Carrier.
Signed-off-by: Richard W.M. Jones
---
Documentation/filesystems/proc.txt | 1 +
fs/proc/array.c| 20 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 7f5607a..e8d0075 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -225,6 +225,7 @@ Table 1-2: Contents of the status files (as of 4.1)
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
+ Umask file mode creation mask
FDSize number of file descriptor slots currently
allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
diff --git a/fs/proc/array.c b/fs/proc/array.c
index b6c00ce..03e8d3f 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -83,6 +83,7 @@
#include
#include
#include
+#include
#include
#include
@@ -139,12 +140,25 @@ static inline const char *get_task_state(struct
task_struct *tsk)
return task_state_array[fls(state)];
}
+static inline int get_task_umask(struct task_struct *tsk)
+{
+ struct fs_struct *fs;
+ int umask = -ENOENT;
+
+ task_lock(tsk);
+ fs = tsk->fs;
+ if (fs)
+ umask = fs->umask;
+ task_unlock(tsk);
+ return umask;
+}
+
static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *p)
{
struct user_namespace *user_ns = seq_user_ns(m);
struct group_info *group_info;
- int g;
+ int g, umask;
struct task_struct *tracer;
const struct cred *cred;
pid_t ppid, tpid = 0, tgid, ngid;
@@ -162,6 +176,10 @@ static inline void task_state(struct seq_file *m, struct
pid_namespace *ns,
ngid = task_numa_group_id(p);
cred = get_task_cred(p);
+ umask = get_task_umask(p);
+ if (umask >= 0)
+ seq_printf(m, "Umask:\t0%o\n", umask);
+
task_lock(p);
if (p->files)
max_fds = files_fdtable(p->files)->max_fds;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] serial: doc: .(un)throttle() depends on hardware assisted flow control
Document that .throttle() and .unthrottle() are relevant only if hardware assisted flow control is enabled. Signed-off-by: Geert Uytterhoeven --- Documentation/serial/driver | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 03369d076ca20a98..03b703cf93182216 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -135,6 +135,7 @@ hardware. Notify the serial driver that input buffers for the line discipline are close to full, and it should somehow signal that no more characters should be sent to the serial port. + This will be called only if hardware assisted flow control is enabled. Locking: none. @@ -142,6 +143,7 @@ hardware. Notify the serial driver that characters can now be sent to the serial port without fear of overrunning the input buffers of the line disciplines. + This will be called only if hardware assisted flow control is enabled. Locking: none. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] serial: doc: .(un)throttle() are serialized by the tty layer
Document that .(un)throttle() are serialized with each other, and with termios modification by the tty layer. Reported-by: Peter Hurley Signed-off-by: Geert Uytterhoeven --- Documentation/serial/driver | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 03b703cf93182216..7fb80682e394eb76 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -137,7 +137,8 @@ hardware. should be sent to the serial port. This will be called only if hardware assisted flow control is enabled. - Locking: none. + Locking: serialized with .unthrottle() and termios modification by the +tty layer. unthrottle(port) Notify the serial driver that characters can now be sent to the serial @@ -145,7 +146,8 @@ hardware. disciplines. This will be called only if hardware assisted flow control is enabled. - Locking: none. + Locking: serialized with .throttle() and termios modification by the +tty layer. send_xchar(port,ch) Transmit a high priority character, even if the port is stopped. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] serial: doc: Re-add paragraph documenting uart_console_write()
Commit 834392a7d92677ff ("serial: doc: Un-document non-existing
uart_write_console()") removed a paragraph about a helper function that
seemed to never exist.
Peter Hurley pointed out that the function does exist, but is called
differently. Re-add the paragraph, with the function name corrected.
Fixes: 834392a7d92677ff ("serial: doc: Un-document non-existing
uart_write_console()")
Signed-off-by: Geert Uytterhoeven
---
Documentation/serial/driver | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 65de49a4b39e5baf..03369d076ca20a98 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -28,6 +28,11 @@ The serial core provides a few helper functions. This
includes identifing
the correct port structure (via uart_get_console) and decoding command line
arguments (uart_parse_options).
+There is also a helper function (uart_console_write) which performs a
+character by character write, translating newlines to CRLF sequences.
+Driver writers are recommended to use this function rather than implementing
+their own version.
+
Locking
---
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] serial: doc: .break_ctl() may sleep
As mutex_lock() must not be called with interrupts disabled, .break_ctl() may sleep. Reported-by: Peter Hurley Signed-off-by: Geert Uytterhoeven --- Documentation/serial/driver | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 7fb80682e394eb76..39701515832b70b0 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -187,7 +187,6 @@ hardware. ctl. Locking: caller holds port->mutex - This call must not sleep startup(port) Grab any interrupt resources and initialise any low level driver -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] serial: doc: Low Level Serial API Documentation Improvements (take two)
Hi Greg, Jiri, Jon, Peter, Russell,
This patch series contains improvements to the low level serial driver
API documentation.
It is an incremental update (sort of v2) of "[PATCH 0/9] serial: doc:
Low Level Serial API Documentation Improvements", which was already
applied to the docs tree.
Thanks for your comments!
Geert Uytterhoeven (4):
serial: doc: Re-add paragraph documenting uart_console_write()
serial: doc: .(un)throttle() depends on hardware assisted flow control
serial: doc: .(un)throttle() are serialized by the tty layer
serial: doc: .break_ctl() may sleep
Documentation/serial/driver | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL v4.6-rc1] bcache: documentation updates
[ +cc: linux-doc, kent ] On Tue, 12 Apr 2016, Marc MERLIN wrote: > On Mon, Mar 28, 2016 at 6:09 PM, Eric Wheeler > wrote: > > git pull https://bitbucket.org/ewheelerinc/linux > > v4.6-rc1-bcache-documentation > > Hi Eric, > > Do I have a way to find out if your patch was pulled? I've not seen them in the commit history for 4.6-rc3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=v4.6-rc3&qt=grep&q=bcache: Hello linux-doc list! There is a bcache documentation update available: > > git pull https://bitbucket.org/ewheelerinc/linux > > v4.6-rc1-bcache-documentation Is this the right list to submit such documentation? -- Eric Wheeler > > Thanks, > Marc > > On Mon, Mar 28, 2016 at 6:09 PM, Eric Wheeler > wrote: > > Hi Jens, > > > > I've rebased documentation updates against 4.6-rc1. There is some reflow > > and trailing whitespace cleanup, so its not pretty---but it cleans > > fills in some missing documentation and adds corrections: > > > > git pull https://bitbucket.org/ewheelerinc/linux > > v4.6-rc1-bcache-documentation > > > > > > -- > > Eric Wheeler > > > > On Sat, 12 Mar 2016, Eric Wheeler wrote: > > > >> Hi Jens, > >> > >> Please pull: > >> > >> Documentation updates for bcache: > >> git pull https://bitbucket.org/ewheelerinc/linux.git > >> v4.5-rc7-bcache-fixes-2 > >> > >> > >> -- > >> Eric Wheeler > >> > >> On Fri, 11 Mar 2016, Marc MERLIN wrote: > >> > >> > Bcache documentation updates: > >> > - Added new HOWTO/COOKBOOK section > >> > - fixed a few typos > >> > - /sys/block/bcache0/cache_mode is /sys/block/bcache0/bcache/cache_mode > >> > > >> > Signed-off-by: Marc MERLIN > >> > --- > >> > Documentation/bcache.txt | 160 > >> > --- > >> > 1 file changed, 152 insertions(+), 8 deletions(-) > >> > > >> > diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt > >> > index 32b6c31..b8302f9 100644 > >> > --- a/Documentation/bcache.txt > >> > +++ b/Documentation/bcache.txt > >> > @@ -1,4 +1,4 @@ > >> > -Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be > >> > +Say you've got a big slow raid 6, and an ssd or three. Wouldn't it be > >> > nice if you could use them as cache... Hence bcache. > >> > > >> > Wiki and git repositories are at: > >> > @@ -8,7 +8,7 @@ Wiki and git repositories are at: > >> > > >> > It's designed around the performance characteristics of SSDs - it only > >> > allocates > >> > in erase block sized buckets, and it uses a hybrid btree/log to track > >> > cached > >> > -extants (which can be anywhere from a single sector to the bucket > >> > size). It's > >> > +extents (which can be anywhere from a single sector to the bucket > >> > size). It's > >> > designed to avoid random writes at all costs; it fills up an erase block > >> > sequentially, then issues a discard before reusing it. > >> > > >> > @@ -55,7 +55,10 @@ immediately. Without udev, you can manually register > >> > devices like this: > >> > Registering the backing device makes the bcache device show up in /dev; > >> > you can > >> > now format it and use it as normal. But the first time using a new > >> > bcache > >> > device, it'll be running in passthrough mode until you attach it to a > >> > cache. > >> > -See the section on attaching. > >> > +If you are thinking about using bcache later, it is recommended to > >> > setup all your > >> > +slow devices as bcache backing devices without a cache, and you can > >> > choose to add > >> > +a caching device later. > >> > +See 'ATTACHING' section below. > >> > > >> > The devices show up as: > >> > > >> > @@ -72,12 +75,14 @@ To get started: > >> >mount /dev/bcache0 /mnt > >> > > >> > You can control bcache devices through sysfs at > >> > /sys/block/bcache/bcache . > >> > +You can also control them through /sys/fs//bcache// . > >> > > >> > Cache devices are managed as sets; multiple caches per set isn't > >> > supported yet > >> > but will allow for mirroring of metadata and dirty data in the future. > >> > Your new > >> > cache set shows up as /sys/fs/bcache/ > >> > > >> > -ATTACHING: > >> > +ATTACHING > >> > +- > >> > > >> > After your cache device and backing device are registered, the backing > >> > device > >> > must be attached to your cache set to enable caching. Attaching a > >> > backing > >> > @@ -105,7 +110,8 @@ but all the cached data will be invalidated. If > >> > there was dirty data in the > >> > cache, don't expect the filesystem to be recoverable - you will have > >> > massive > >> > filesystem corruption, though ext4's fsck does work miracles. > >> > > >> > -ERROR HANDLING: > >> > +ERROR HANDLING > >> > +-- > >> > > >> > Bcache tries to transparently handle IO errors to/from the cache device > >> > without > >> > affecting normal operation; if it sees too many errors (the threshold is > >> > @@ -127,7 +133,143 @@ the backing devices to passthrough mode. > >> > writeback mode).
Re: [PATCH v8 02/10] drm/hisilicon: Add hisilicon kirin drm master driver
Hi Emil,
On 13 April 2016 at 20:15, Emil Velikov wrote:
> Hi Xinliang,
>
> On 11 April 2016 at 09:55, Xinliang Liu wrote:
>
>> +static int kirin_drm_connectors_register(struct drm_device *dev)
>> +{
>> + struct drm_connector *connector;
>> + struct drm_connector *failed_connector;
>> + int ret;
>> +
>> + mutex_lock(&dev->mode_config.mutex);
>> + drm_for_each_connector(connector, dev) {
>> + ret = drm_connector_register(connector);
>> + if (ret) {
>> + failed_connector = connector;
>> + goto err;
>> + }
>> + }
>> + mutex_unlock(&dev->mode_config.mutex);
>> +
>> + return 0;
>> +
>> +err:
>> + drm_for_each_connector(connector, dev) {
>> + if (failed_connector == connector)
>> + break;
>> + drm_connector_unregister(connector);
>> + }
>> + mutex_unlock(&dev->mode_config.mutex);
>> +
>> + return ret;
>> +}
>> +
> Iirc we have new drm_connector_{un,}register_all() helpers.You might
> want to use it once they are in (i.e. not sure what your base is and
> if they have landed yet).
I can't find these drm_connector_{un,}register_all() helpers in latest
tag v4.6-rc3.
>
>
>> +static struct device_node *kirin_get_remote_node(struct device_node *np)
>> +{
>> + struct device_node *endpoint, *remote;
>> +
>> + /* get the first endpoint, in our case only one remote node
>> +* is connected to display controller.
>> +*/
>> + endpoint = of_graph_get_next_endpoint(np, NULL);
>> + if (!endpoint) {
>> + DRM_ERROR("no valid endpoint node\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> + of_node_put(endpoint);
>> +
>> + remote = of_graph_get_remote_port_parent(endpoint);
>> + if (!remote) {
>> + DRM_ERROR("no valid remote node\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> + of_node_put(remote);
>> +
>> + if (!of_device_is_available(remote)) {
>> + DRM_ERROR("not available for remote node\n");
>> + return ERR_PTR(-ENODEV);
>> + }
>> +
> This seems like a common pattern in many platform DRM drivers. Yet
> some tend to differ in subtle ways - I'm leaning that they might be
> bugs, but one cannot be too sure.
>
> A friendly request:
> Can you please follow up by adding a helper and removing the
> duplication thoughout ?
Yes, I will create another patch set for this. I think I need to
figure out other drivers requirements.
Maybe, I need to add one more parameter for this helper. That's
endpoint index to get which endpoint remote node.
I will follow up this.
Thanks,
-xinliang
>
> Thanks
> Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
