* Re: [PATCH v2 2/2] crypto: sun4i-ss: enable pm_runtime
From: Corentin Labbe @ 2019-09-23 7:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: herbert, linux-sunxi, linux-kernel, wens, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190919165559.e7xyapggcwp2ukdt@gilmour>
On Thu, Sep 19, 2019 at 06:55:59PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Sep 19, 2019 at 07:10:35AM +0200, Corentin Labbe wrote:
> > This patch enables power management on the Security System.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 9 +++
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 94 +++++++++++++++++++----
> > drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 12 +++
> > drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 9 ++-
> > drivers/crypto/sunxi-ss/sun4i-ss.h | 2 +
> > 5 files changed, 110 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > index fa4b1b47822e..c9799cbe0530 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > @@ -480,6 +480,7 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
> > struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
> > struct sun4i_ss_alg_template *algt;
> > const char *name = crypto_tfm_alg_name(tfm);
> > + int err;
> >
> > memset(op, 0, sizeof(struct sun4i_tfm_ctx));
> >
> > @@ -497,13 +498,21 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
> > return PTR_ERR(op->fallback_tfm);
> > }
> >
> > + err = pm_runtime_get_sync(op->ss->dev);
> > + if (err < 0)
> > + goto error_pm;
> > return 0;
>
> Newline here
>
> > +error_pm:
> > + crypto_free_sync_skcipher(op->fallback_tfm);
> > + return err;
> > }
> >
> > void sun4i_ss_cipher_exit(struct crypto_tfm *tfm)
> > {
> > struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
> > +
> > crypto_free_sync_skcipher(op->fallback_tfm);
> > + pm_runtime_put(op->ss->dev);
> > }
> >
> > /* check and set the AES key, prepare the mode to be used */
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index 6c2db5d83b06..311c2653a9c3 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -44,7 +44,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
> > .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
> > .cra_ctxsize = sizeof(struct sun4i_req_ctx),
> > .cra_module = THIS_MODULE,
> > - .cra_init = sun4i_hash_crainit
> > + .cra_init = sun4i_hash_crainit,
> > + .cra_exit = sun4i_hash_craexit
>
> You should add a comma at the end to prevent having to modify it again
>
> > }
> > }
> > }
> > @@ -70,7 +71,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
> > .cra_blocksize = SHA1_BLOCK_SIZE,
> > .cra_ctxsize = sizeof(struct sun4i_req_ctx),
> > .cra_module = THIS_MODULE,
> > - .cra_init = sun4i_hash_crainit
> > + .cra_init = sun4i_hash_crainit,
> > + .cra_exit = sun4i_hash_craexit
>
> Ditto
>
> > }
> > }
> > }
> > @@ -262,6 +264,61 @@ static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
> > return err;
> > }
> >
> > +/*
> > + * Power management strategy: The device is suspended unless a TFM exists for
> > + * one of the algorithms proposed by this driver.
> > + */
> > +#if defined(CONFIG_PM)
> > +static int sun4i_ss_pm_suspend(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + sun4i_ss_disable(ss);
> > + return 0;
> > +}
> > +
> > +static int sun4i_ss_pm_resume(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + return sun4i_ss_enable(ss);
> > +}
> > +#endif
> > +
>
> Why not just have the suspend and resume function and the enable /
> disable functions merged together, you're not using them directy as
> far as I can see.
>
> > +const struct dev_pm_ops sun4i_ss_pm_ops = {
> > + SET_RUNTIME_PM_OPS(sun4i_ss_pm_suspend, sun4i_ss_pm_resume, NULL)
> > +};
> > +
> > +/*
> > + * When power management is enabled, this function enables the PM and set the
> > + * device as suspended
> > + * When power management is disabled, this function just enables the device
> > + */
> > +static int sun4i_ss_pm_init(struct sun4i_ss_ctx *ss)
> > +{
> > + int err;
> > +
> > + pm_runtime_use_autosuspend(ss->dev);
> > + pm_runtime_set_autosuspend_delay(ss->dev, 2000);
> > +
> > + err = pm_runtime_set_suspended(ss->dev);
> > + if (err)
> > + return err;
> > + pm_runtime_enable(ss->dev);
> > +#if !defined(CONFIG_PM)
> > + err = sun4i_ss_enable(ss);
> > +#endif
> > + return err;
> > +}
>
> This looks nicer:
> https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-sun4i.c#L492
>
> Or, just make it depend on CONFIG_PM, we should probably do it anyway
> at the ARCH level anyway.
>
Hello
I usually prefer to give choice (PM vs not PM), but it simplify a lot the code to depend on PM, so I will go for it.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] sched/eas: introduce system-wide overutil indicator
From: Dietmar Eggemann @ 2019-09-23 8:05 UTC (permalink / raw)
To: YT Chang, Peter Zijlstra, Matthias Brugger
Cc: linux-arm-kernel, linux-mediatek, linux-kernel, wsd_upstream
In-Reply-To: <1568877622-28073-1-git-send-email-yt.chang@mediatek.com>
On 9/19/19 9:20 AM, YT Chang wrote:
> When the system is overutilization, the load-balance crossing
> clusters will be triggered and scheduler will not use energy
> aware scheduling to choose CPUs.
We're currently transitioning from traditional big.LITTLE (the CPUs of 1
cluster (all having the same CPU (original) capacity) represent a DIE
Sched Domain (SD) level Sched Group (SG)) to DynamIQ systems. Later can
share CPUs with different CPU (original) capacity in one cluster.
In Linux mainline with today's DynamIQ systems (1 cluster) you will
only have 1 cluster, i.e. 1 MC SD level SG.
For those systems the current approach is much more applicable.
Or do you apply the out-of-tree Phantom Domain concept, which creates n
(n=2 or 3 ((huge,) big, little)) DIE SGs on your 1 cluster DynamIQ system?
> The overutilization means the loading of ANY CPUs
> exceeds threshold (80%).
>
> However, only 1 heavy task or while-1 program will run on highest
> capacity CPUs and it still result to trigger overutilization. So
> the system will not use Energy Aware scheduling.
The patch-header of commit 2802bf3cd936 ("sched/fair: Add
over-utilization/tipping point indicator") mentioned why the current
approach is so conservatively defined.
> To avoid it, a system-wide over-utilization indicator to trigger
> load-balance cross clusters.
>
> The policy is:
> The loading of "ALL CPUs in the highest capacity"
> exceeds threshold(80%) or
> The loading of "Any CPUs not in the highest capacity"
> exceed threshold(80%)
We experimented with an overutilized (tipping point) indicator per SD
from Thara Gopinath (Linaro), mentioned by Vincent already, till v2 of
the Energy Aware Scheduling patch-set in 2018 but we couldn't find any
advantage using it over the one you now find in mainline.
https://lore.kernel.org/r/20180406153607.17815-4-dietmar.eggemann@arm.com
Maybe you can have a look at this patch and see if it gives you an
advantage with your use cases and system topology layout?
The 'system-wide' in the name of the patch is misleading. The current
approach is also system-wide, we have the overutilized information on
the root domain (system here stands for root domain). You change the
detection mechanism from per-CPU to a mixed-mode detection (per-CPU and
per-SG).
> Signed-off-by: YT Chang <yt.chang@mediatek.com>
> ---
> kernel/sched/fair.c | 76 +++++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 65 insertions(+), 11 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 036be95..f4c3d70 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5182,10 +5182,71 @@ static inline bool cpu_overutilized(int cpu)
> static inline void update_overutilized_status(struct rq *rq)
> {
> if (!READ_ONCE(rq->rd->overutilized) && cpu_overutilized(rq->cpu)) {
> - WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
> - trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
> + if (capacity_orig_of(cpu_of(rq)) < rq->rd->max_cpu_capacity) {
> + WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
> + trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
> + }
> }
> }
> +
> +static
> +void update_system_overutilized(struct sched_domain *sd, struct cpumask *cpus)
> +{
> + unsigned long group_util;
> + bool intra_overutil = false;
> + unsigned long max_capacity;
> + struct sched_group *group = sd->groups;
> + struct root_domain *rd;
> + int this_cpu;
> + bool overutilized;
> + int i;
> +
> + this_cpu = smp_processor_id();
> + rd = cpu_rq(this_cpu)->rd;
> + overutilized = READ_ONCE(rd->overutilized);
> + max_capacity = rd->max_cpu_capacity;
> +
> + do {
> + group_util = 0;
> + for_each_cpu_and(i, sched_group_span(group), cpus) {
> + group_util += cpu_util(i);
> + if (cpu_overutilized(i)) {
> + if (capacity_orig_of(i) < max_capacity) {
> + intra_overutil = true;
> + break;
> + }
> + }
> + }
> +
> + /*
> + * A capacity base hint for over-utilization.
> + * Not to trigger system overutiled if heavy tasks
> + * in Big.cluster, so
> + * add the free room(20%) of Big.cluster is impacted which means
> + * system-wide over-utilization,
> + * that considers whole cluster not single cpu
> + */
> + if (group->group_weight > 1 && (group->sgc->capacity * 1024 <
> + group_util * capacity_margin)) {
Why 'group->group_weight > 1' ? Do you have some out-of-tree code which
lets SGs with 1 CPU survive?
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] pwm: mxs: add support for setting polarity via DT
From: Rasmus Villemoes @ 2019-09-23 8:13 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, linux-pwm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Rasmus Villemoes
This series adds support for setting the polarity via DT to the
pwm-mxs driver.
The DT binding is updated, but I'm not touching the existing .dts or
.dtsi files - it seems that the same was done for bcm2835 in commits
46421d9d8e802e570dfa4d793a4938d2642ec7a7 and
8a88b2a2017d1e7e80db53080baff591fd454722, while
arch/arm/boot/dts/bcm283x.dtsi still has #pwm-cells = <2>.
Rasmus Villemoes (4):
pwm: mxs: implement ->apply
pwm: mxs: remove legacy methods
pwm: mxs: add support for inverse polarity
dt-bindings: pwm: mxs-pwm: Increase #pwm-cells
.../devicetree/bindings/pwm/mxs-pwm.txt | 4 +-
drivers/pwm/pwm-mxs.c | 73 ++++++++-----------
2 files changed, 34 insertions(+), 43 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] pwm: mxs: remove legacy methods
From: Rasmus Villemoes @ 2019-09-23 8:13 UTC (permalink / raw)
To: Thierry Reding, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-pwm, Rasmus Villemoes, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190923081348.6843-1-linux@rasmusvillemoes.dk>
Since we now have ->apply, these are no longer relevant.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/pwm/pwm-mxs.c | 77 -------------------------------------------
1 file changed, 77 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index c70c26a9ff68..284107784dad 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -102,85 +102,8 @@ static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
return 0;
}
-static int mxs_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
- struct mxs_pwm_chip *mxs = to_mxs_pwm_chip(chip);
- int ret, div = 0;
- unsigned int period_cycles, duty_cycles;
- unsigned long rate;
- unsigned long long c;
-
- rate = clk_get_rate(mxs->clk);
- while (1) {
- c = rate / cdiv[div];
- c = c * period_ns;
- do_div(c, 1000000000);
- if (c < PERIOD_PERIOD_MAX)
- break;
- div++;
- if (div >= PERIOD_CDIV_MAX)
- return -EINVAL;
- }
-
- period_cycles = c;
- c *= duty_ns;
- do_div(c, period_ns);
- duty_cycles = c;
-
- /*
- * If the PWM channel is disabled, make sure to turn on the clock
- * before writing the register. Otherwise, keep it enabled.
- */
- if (!pwm_is_enabled(pwm)) {
- ret = clk_prepare_enable(mxs->clk);
- if (ret)
- return ret;
- }
-
- writel(duty_cycles << 16,
- mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
- writel(PERIOD_PERIOD(period_cycles) | PERIOD_ACTIVE_HIGH |
- PERIOD_INACTIVE_LOW | PERIOD_CDIV(div),
- mxs->base + PWM_PERIOD0 + pwm->hwpwm * 0x20);
-
- /*
- * If the PWM is not enabled, turn the clock off again to save power.
- */
- if (!pwm_is_enabled(pwm))
- clk_disable_unprepare(mxs->clk);
-
- return 0;
-}
-
-static int mxs_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- struct mxs_pwm_chip *mxs = to_mxs_pwm_chip(chip);
- int ret;
-
- ret = clk_prepare_enable(mxs->clk);
- if (ret)
- return ret;
-
- writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + SET);
-
- return 0;
-}
-
-static void mxs_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- struct mxs_pwm_chip *mxs = to_mxs_pwm_chip(chip);
-
- writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + CLR);
-
- clk_disable_unprepare(mxs->clk);
-}
-
static const struct pwm_ops mxs_pwm_ops = {
.apply = mxs_pwm_apply,
- .config = mxs_pwm_config,
- .enable = mxs_pwm_enable,
- .disable = mxs_pwm_disable,
.owner = THIS_MODULE,
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] pwm: mxs: implement ->apply
From: Rasmus Villemoes @ 2019-09-23 8:13 UTC (permalink / raw)
To: Thierry Reding, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-pwm, Rasmus Villemoes, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190923081348.6843-1-linux@rasmusvillemoes.dk>
In preparation for supporting setting the polarity, switch the driver
to support the ->apply method.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/pwm/pwm-mxs.c | 62 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 04c0f6b95c1a..c70c26a9ff68 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -26,6 +26,7 @@
#define PERIOD_PERIOD_MAX 0x10000
#define PERIOD_ACTIVE_HIGH (3 << 16)
#define PERIOD_INACTIVE_LOW (2 << 18)
+#define PERIOD_POLARITY_NORMAL (PERIOD_ACTIVE_HIGH | PERIOD_INACTIVE_LOW)
#define PERIOD_CDIV(div) (((div) & 0x7) << 20)
#define PERIOD_CDIV_MAX 8
@@ -41,6 +42,66 @@ struct mxs_pwm_chip {
#define to_mxs_pwm_chip(_chip) container_of(_chip, struct mxs_pwm_chip, chip)
+static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct mxs_pwm_chip *mxs = to_mxs_pwm_chip(chip);
+ int ret, div = 0;
+ unsigned int period_cycles, duty_cycles;
+ unsigned long rate;
+ unsigned long long c;
+
+ if (state->polarity != PWM_POLARITY_NORMAL)
+ return -ENOTSUPP;
+
+ rate = clk_get_rate(mxs->clk);
+ while (1) {
+ c = rate / cdiv[div];
+ c = c * state->period;
+ do_div(c, 1000000000);
+ if (c < PERIOD_PERIOD_MAX)
+ break;
+ div++;
+ if (div >= PERIOD_CDIV_MAX)
+ return -EINVAL;
+ }
+
+ period_cycles = c;
+ c *= state->duty_cycle;
+ do_div(c, state->period);
+ duty_cycles = c;
+
+ /*
+ * If the PWM channel is disabled, make sure to turn on the clock
+ * before writing the register. Otherwise, keep it enabled.
+ */
+ if (!pwm_is_enabled(pwm)) {
+ ret = clk_prepare_enable(mxs->clk);
+ if (ret)
+ return ret;
+ }
+
+ writel(duty_cycles << 16,
+ mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
+ writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
+ mxs->base + PWM_PERIOD0 + pwm->hwpwm * 0x20);
+
+ if (state->enabled) {
+ if (!pwm_is_enabled(pwm)) {
+ /*
+ * The clock was enabled above. Just enable
+ * the channel in the control register.
+ */
+ writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + SET);
+ }
+ } else {
+ if (pwm_is_enabled(pwm))
+ writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + CLR);
+ clk_disable_unprepare(mxs->clk);
+ }
+ return 0;
+}
+
static int mxs_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
@@ -116,6 +177,7 @@ static void mxs_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
}
static const struct pwm_ops mxs_pwm_ops = {
+ .apply = mxs_pwm_apply,
.config = mxs_pwm_config,
.enable = mxs_pwm_enable,
.disable = mxs_pwm_disable,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] dt-bindings: pwm: mxs-pwm: Increase #pwm-cells
From: Rasmus Villemoes @ 2019-09-23 8:13 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: devicetree, Rasmus Villemoes, linux-kernel, linux-arm-kernel,
linux-pwm
In-Reply-To: <20190923081348.6843-1-linux@rasmusvillemoes.dk>
We need to increase the pwm-cells for the optional flags parameter, in
order to implement support for polarity setting via DT.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
index 96cdde5f6208..1697dcd3b07c 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
@@ -3,7 +3,7 @@ Freescale MXS PWM controller
Required properties:
- compatible: should be "fsl,imx23-pwm"
- reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
the cells format.
- fsl,pwm-number: the number of PWM devices
@@ -12,6 +12,6 @@ Example:
pwm: pwm@80064000 {
compatible = "fsl,imx28-pwm", "fsl,imx23-pwm";
reg = <0x80064000 0x2000>;
- #pwm-cells = <2>;
+ #pwm-cells = <3>;
fsl,pwm-number = <8>;
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] pwm: mxs: add support for inverse polarity
From: Rasmus Villemoes @ 2019-09-23 8:13 UTC (permalink / raw)
To: Thierry Reding, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team
Cc: devicetree, linux-pwm, Rasmus Villemoes, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190923081348.6843-1-linux@rasmusvillemoes.dk>
If I'm reading of_pwm_xlate_with_flags() right, existing device trees
that set #pwm-cells = 2 will continue to work.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/pwm/pwm-mxs.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 284107784dad..c46697acaf11 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -25,8 +25,11 @@
#define PERIOD_PERIOD(p) ((p) & 0xffff)
#define PERIOD_PERIOD_MAX 0x10000
#define PERIOD_ACTIVE_HIGH (3 << 16)
+#define PERIOD_ACTIVE_LOW (2 << 16)
+#define PERIOD_INACTIVE_HIGH (3 << 18)
#define PERIOD_INACTIVE_LOW (2 << 18)
#define PERIOD_POLARITY_NORMAL (PERIOD_ACTIVE_HIGH | PERIOD_INACTIVE_LOW)
+#define PERIOD_POLARITY_INVERSE (PERIOD_ACTIVE_LOW | PERIOD_INACTIVE_HIGH)
#define PERIOD_CDIV(div) (((div) & 0x7) << 20)
#define PERIOD_CDIV_MAX 8
@@ -50,9 +53,7 @@ static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned int period_cycles, duty_cycles;
unsigned long rate;
unsigned long long c;
-
- if (state->polarity != PWM_POLARITY_NORMAL)
- return -ENOTSUPP;
+ unsigned int pol_bits;
rate = clk_get_rate(mxs->clk);
while (1) {
@@ -81,9 +82,12 @@ static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
return ret;
}
+ pol_bits = state->polarity == PWM_POLARITY_NORMAL ?
+ PERIOD_POLARITY_NORMAL : PERIOD_POLARITY_INVERSE;
+
writel(duty_cycles << 16,
mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
- writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
+ writel(PERIOD_PERIOD(period_cycles) | pol_bits | PERIOD_CDIV(div),
mxs->base + PWM_PERIOD0 + pwm->hwpwm * 0x20);
if (state->enabled) {
@@ -129,6 +133,8 @@ static int mxs_pwm_probe(struct platform_device *pdev)
mxs->chip.dev = &pdev->dev;
mxs->chip.ops = &mxs_pwm_ops;
+ mxs->chip.of_xlate = of_pwm_xlate_with_flags;
+ mxs->chip.of_pwm_n_cells = 3;
mxs->chip.base = -1;
ret = of_property_read_u32(np, "fsl,pwm-number", &mxs->chip.npwm);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] drm/mediatek: Apply CMDQ control flow
From: Pi-Hsun Shih @ 2019-09-23 8:14 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Nicolas Boichat, Yongqiang Niu, David Airlie, Daniel Vetter,
open list, dri-devel, Tomasz Figa, YT Shen, CK Hu, Thierry Reding,
moderated list:ARM/Mediatek SoC support, Philipp Zabel,
Matthias Brugger, moderated list:ARM/Mediatek SoC support
In-Reply-To: <20190830074103.16671-3-bibby.hsieh@mediatek.com>
Hi Bibby,
On Fri, Aug 30, 2019 at 3:41 PM Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
> ...
> +static void ddp_cmdq_cb(struct cmdq_cb_data data)
> +{
> +
> +#if IS_ENABLED(CONFIG_MTK_CMDQ)
> + struct mtk_cmdq_cb_data *cb_data = data.data;
> + struct drm_crtc_state *crtc_state = cb_data->state;
> + struct drm_atomic_state *atomic_state = crtc_state->state;
> + struct drm_crtc *crtc = crtc_state->crtc;
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +
> + DRM_DEBUG_DRIVER("%s\n", __func__);
This debug message is printed about twice per second when enabled,
which makes debugging other things that also use DRM_DEBUG_DRIVER
harder. Can this be rate-limited or removed?
> +
> + if (mtk_crtc->pending_needs_vblank) {
> + /* cmdq_vblank_event must be read after cmdq_needs_event */
> + smp_rmb();
> +
> ...
> +void mtk_drm_crtc_plane_update(struct drm_crtc *crtc, struct drm_plane *plane,
> + struct mtk_plane_state *state)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> + struct drm_crtc_state *crtc_state = crtc->state;
> + struct mtk_crtc_state *mtk_crtc_state = to_mtk_crtc_state(crtc_state);
> + struct cmdq_pkt *cmdq_handle = mtk_crtc_state->cmdq_handle;
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
> + unsigned int plane_index = plane - mtk_crtc->planes;
> +
> + DRM_DEBUG_DRIVER("%s\n", __func__);
Same with this one.
> + if (mtk_crtc->cmdq_client) {
> + if (plane_index >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = plane_index - comp_layer_nr;
> ...
> @@ -494,13 +599,29 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state)
> {
> struct drm_atomic_state *old_atomic_state = old_crtc_state->state;
> + struct drm_crtc_state *crtc_state = crtc->state;
> + struct mtk_crtc_state *state = to_mtk_crtc_state(crtc_state);
> + struct cmdq_pkt *cmdq_handle = state->cmdq_handle;
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> struct mtk_drm_private *priv = crtc->dev->dev_private;
> + struct mtk_cmdq_cb_data *cb_data;
> unsigned int pending_planes = 0;
> int i;
>
> - if (mtk_crtc->event)
> - mtk_crtc->pending_needs_vblank = true;
> + DRM_DEBUG_DRIVER("[CRTC:%u] [STATE:%p(%p)->%p(%p)]\n", crtc->base.id,
> + old_crtc_state, old_crtc_state->state,
> + crtc_state, crtc_state->state);
Same with this one.
> +
> + if (IS_ENABLED(CONFIG_MTK_CMDQ) && mtk_crtc->cmdq_client) {
> + drm_atomic_state_get(old_atomic_state);
> + cb_data = kmalloc(sizeof(*cb_data), GFP_KERNEL);
> + cb_data->state = old_crtc_state;
> ...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 3/6] mm: Introduce Reported pages
From: Michael S. Tsirkin @ 2019-09-23 8:15 UTC (permalink / raw)
To: Alexander Duyck
Cc: yang.zhang.wz, pagupta, kvm, david, mhocko, linux-mm,
alexander.h.duyck, aarcange, virtio-dev, konrad.wilk, willy,
wei.w.wang, vbabka, riel, dan.j.williams, lcapitulino,
linux-arm-kernel, osalvador, nitesh, dave.hansen, linux-kernel,
pbonzini, akpm, mgorman
In-Reply-To: <20190918175249.23474.51171.stgit@localhost.localdomain>
On Wed, Sep 18, 2019 at 10:52:49AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> In order to pave the way for free page reporting in virtualized
> environments we will need a way to get pages out of the free lists and
> identify those pages after they have been returned. To accomplish this,
> this patch adds the concept of a Reported Buddy, which is essentially
> meant to just be the Uptodate flag used in conjunction with the Buddy
> page type.
>
> It adds a set of pointers we shall call "reported_boundary" which
> represent the upper boundary between the unreported and reported pages.
> The general idea is that in order for a page to cross from one side of the
> boundary to the other it will need to verify that it went through the
> reporting process. Ultimately a free list has been fully processed when
> the boundary has been moved from the tail all they way up to occupying the
> first entry in the list.
>
> One limitation to this approach is that it is essentially a linear search
> and in the case of the free lists we can have pages added to either the
> head or the tail of the list. In order to place limits on this we only
> allow pages to be added before the reported_boundary instead of adding
> to the tail itself. An added advantage to this approach is that we should
> be reducing the overall memory footprint of the guest as it will be more
> likely to recycle warm pages versus trying to allocate the reported pages
> that were likely evicted from the guest memory.
>
> Since we will only be reporting one zone at a time we keep the boundary
> limited to being defined for just the zone we are currently reporting pages
> from. Doing this we can keep the number of additional pointers needed quite
> small. To flag that the boundaries are in place we use a single bit
> in the zone to indicate that reporting and the boundaries are active.
>
> We store the index of the boundary pointer used to track the reported page
> in the page->index value. Doing this we can avoid unnecessary computation
> to determine the index value again. There should be no issues with this as
> the value is unused when the page is in the buddy allocator, and is reset
> as soon as the page is removed from the free list.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
> include/linux/mmzone.h | 16 ++++
> include/linux/page-flags.h | 11 +++
> mm/Kconfig | 11 +++
> mm/compaction.c | 5 +
> mm/memory_hotplug.c | 2
> mm/page_alloc.c | 67 +++++++++++++++--
> mm/page_reporting.h | 178 ++++++++++++++++++++++++++++++++++++++++++++
> 7 files changed, 283 insertions(+), 7 deletions(-)
> create mode 100644 mm/page_reporting.h
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 270a7b493174..53922c30b8d8 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -463,6 +463,14 @@ struct zone {
> seqlock_t span_seqlock;
> #endif
>
> +#ifdef CONFIG_PAGE_REPORTING
> + /*
> + * Pointer to reported page tracking statistics array. The size of
> + * the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
> + * unused page reporting is not present.
> + */
> + unsigned long *reported_pages;
> +#endif
> int initialized;
>
> /* Write-intensive fields used from the page allocator */
> @@ -538,6 +546,14 @@ enum zone_flags {
> ZONE_BOOSTED_WATERMARK, /* zone recently boosted watermarks.
> * Cleared when kswapd is woken.
> */
> + ZONE_PAGE_REPORTING_ACTIVE, /* zone enabled page reporting and is
> + * activly flushing the data out of
> + * higher order pages.
> + */
> + ZONE_PAGE_REPORTING_REQUESTED, /* zone enabled page reporting and has
> + * requested flushing the data out of
> + * higher order pages.
> + */
> };
>
> static inline unsigned long zone_managed_pages(struct zone *zone)
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index f91cb8898ff0..759a3b3956f2 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -163,6 +163,9 @@ enum pageflags {
>
> /* non-lru isolated movable page */
> PG_isolated = PG_reclaim,
> +
> + /* Buddy pages. Used to track which pages have been reported */
> + PG_reported = PG_uptodate,
> };
>
> #ifndef __GENERATING_BOUNDS_H
> @@ -432,6 +435,14 @@ static inline bool set_hwpoison_free_buddy_page(struct page *page)
> #endif
>
> /*
> + * PageReported() is used to track reported free pages within the Buddy
> + * allocator. We can use the non-atomic version of the test and set
> + * operations as both should be shielded with the zone lock to prevent
> + * any possible races on the setting or clearing of the bit.
> + */
> +__PAGEFLAG(Reported, reported, PF_NO_COMPOUND)
> +
> +/*
> * On an anonymous page mapped into a user virtual memory area,
> * page->mapping points to its anon_vma, not to a struct address_space;
> * with the PAGE_MAPPING_ANON bit set to distinguish it. See rmap.h.
> diff --git a/mm/Kconfig b/mm/Kconfig
> index a5dae9a7eb51..0419b2a9be3e 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -237,6 +237,17 @@ config COMPACTION
> linux-mm@kvack.org.
>
> #
> +# support for unused page reporting
> +config PAGE_REPORTING
> + bool "Allow for reporting of unused pages"
> + def_bool n
> + help
> + Unused page reporting allows for the incremental acquisition of
> + unused pages from the buddy allocator for the purpose of reporting
> + those pages to another entity, such as a hypervisor, so that the
> + memory can be freed up for other uses.
> +
> +#
> # support for page migration
> #
> config MIGRATION
> diff --git a/mm/compaction.c b/mm/compaction.c
> index ce08b39d85d4..60e064330b3a 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -24,6 +24,7 @@
> #include <linux/page_owner.h>
> #include <linux/psi.h>
> #include "internal.h"
> +#include "page_reporting.h"
>
> #ifdef CONFIG_COMPACTION
> static inline void count_compact_event(enum vm_event_item item)
> @@ -1325,6 +1326,8 @@ static int next_search_order(struct compact_control *cc, int order)
> continue;
>
> spin_lock_irqsave(&cc->zone->lock, flags);
> + page_reporting_free_area_release(cc->zone, order,
> + MIGRATE_MOVABLE);
> freelist = &area->free_list[MIGRATE_MOVABLE];
> list_for_each_entry_reverse(freepage, freelist, lru) {
> unsigned long pfn;
> @@ -1681,6 +1684,8 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
> continue;
>
> spin_lock_irqsave(&cc->zone->lock, flags);
> + page_reporting_free_area_release(cc->zone, order,
> + MIGRATE_MOVABLE);
> freelist = &area->free_list[MIGRATE_MOVABLE];
> list_for_each_entry(freepage, freelist, lru) {
> unsigned long free_pfn;
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 49f7bf91c25a..09c6f52e2bc5 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -41,6 +41,7 @@
>
> #include "internal.h"
> #include "shuffle.h"
> +#include "page_reporting.h"
>
> /*
> * online_page_callback contains pointer to current page onlining function.
> @@ -1613,6 +1614,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
> if (!populated_zone(zone)) {
> zone_pcp_reset(zone);
> build_all_zonelists(NULL);
> + page_reporting_reset_zone(zone);
> } else
> zone_pcp_update(zone);
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8271ec8e06e..ed0128c65936 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -74,6 +74,7 @@
> #include <asm/div64.h>
> #include "internal.h"
> #include "shuffle.h"
> +#include "page_reporting.h"
>
> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
> static DEFINE_MUTEX(pcp_batch_high_lock);
> @@ -891,10 +892,15 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
> static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
> unsigned int order, int migratetype)
> {
> - struct free_area *area = &zone->free_area[order];
> + struct list_head *tail = get_unreported_tail(zone, order, migratetype);
>
> - list_add_tail(&page->lru, &area->free_list[migratetype]);
> - area->nr_free++;
> + /*
> + * To prevent the unreported pages from slipping behind our iterator
> + * we will force them to be inserted in front of it. By doing this
> + * we should only need to make one pass through the freelist.
> + */
> + list_add_tail(&page->lru, tail);
> + zone->free_area[order].nr_free++;
> }
>
> /* Used for pages which are on another list */
> @@ -903,12 +909,20 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
> {
> struct free_area *area = &zone->free_area[order];
>
> + /* Make certain the page isn't occupying the boundary */
> + if (unlikely(PageReported(page)))
> + __del_page_from_reported_list(page, zone);
> +
> list_move(&page->lru, &area->free_list[migratetype]);
> }
>
> static inline void del_page_from_free_list(struct page *page, struct zone *zone,
> unsigned int order)
> {
> + /* remove page from reported list, and clear reported state */
> + if (unlikely(PageReported(page)))
> + del_page_from_reported_list(page, zone, order);
> +
> list_del(&page->lru);
> __ClearPageBuddy(page);
> set_page_private(page, 0);
> @@ -972,7 +986,7 @@ static inline void del_page_from_free_list(struct page *page, struct zone *zone,
> static inline void __free_one_page(struct page *page,
> unsigned long pfn,
> struct zone *zone, unsigned int order,
> - int migratetype)
> + int migratetype, bool reported)
> {
> struct capture_control *capc = task_capc(zone);
> unsigned long uninitialized_var(buddy_pfn);
> @@ -1048,7 +1062,9 @@ static inline void __free_one_page(struct page *page,
> done_merging:
> set_page_order(page, order);
>
> - if (is_shuffle_order(order))
> + if (reported)
> + to_tail = true;
> + else if (is_shuffle_order(order))
> to_tail = shuffle_pick_tail();
> else
> to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);
> @@ -1367,7 +1383,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
> if (unlikely(isolated_pageblocks))
> mt = get_pageblock_migratetype(page);
>
> - __free_one_page(page, page_to_pfn(page), zone, 0, mt);
> + __free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
> trace_mm_page_pcpu_drain(page, 0, mt);
> }
> spin_unlock(&zone->lock);
> @@ -1383,7 +1399,7 @@ static void free_one_page(struct zone *zone,
> is_migrate_isolate(migratetype))) {
> migratetype = get_pfnblock_migratetype(page, pfn);
> }
> - __free_one_page(page, pfn, zone, order, migratetype);
> + __free_one_page(page, pfn, zone, order, migratetype, false);
> spin_unlock(&zone->lock);
> }
>
> @@ -2245,6 +2261,43 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
> return NULL;
> }
>
> +#ifdef CONFIG_PAGE_REPORTING
> +struct list_head **reported_boundary __read_mostly;
> +
> +/**
> + * free_reported_page - Return a now-reported page back where we got it
> + * @page: Page that was reported
> + * @order: Order of the reported page
> + *
> + * This function will pull the migratetype and order information out
> + * of the page and attempt to return it where it found it. If the page
> + * is added to the free list without changes we will mark it as being
> + * reported.
> + */
> +void free_reported_page(struct page *page, unsigned int order)
> +{
> + struct zone *zone = page_zone(page);
> + unsigned long pfn;
> + unsigned int mt;
> +
> + /* zone lock should be held when this function is called */
> + lockdep_assert_held(&zone->lock);
> +
> + pfn = page_to_pfn(page);
> + mt = get_pfnblock_migratetype(page, pfn);
> + __free_one_page(page, pfn, zone, order, mt, true);
> +
> + /*
> + * If page was not comingled with another page we can consider
> + * the result to be "reported" since part of the page hasn't been
> + * modified, otherwise we would need to report on the new larger
> + * page.
> + */
> + if (PageBuddy(page) && page_order(page) == order)
> + add_page_to_reported_list(page, zone, order, mt);
> +}
> +#endif /* CONFIG_PAGE_REPORTING */
> +
> /*
> * This array describes the order lists are fallen back to when
> * the free lists for the desirable migrate type are depleted
> diff --git a/mm/page_reporting.h b/mm/page_reporting.h
> new file mode 100644
> index 000000000000..c5e1bb58ad96
> --- /dev/null
> +++ b/mm/page_reporting.h
> @@ -0,0 +1,178 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _MM_PAGE_REPORTING_H
> +#define _MM_PAGE_REPORTING_H
> +
> +#include <linux/mmzone.h>
> +#include <linux/pageblock-flags.h>
> +#include <linux/page-isolation.h>
> +#include <linux/jump_label.h>
> +#include <linux/slab.h>
> +#include <asm/pgtable.h>
> +
> +#define PAGE_REPORTING_MIN_ORDER pageblock_order
> +#define PAGE_REPORTING_HWM 32
> +
> +#ifdef CONFIG_PAGE_REPORTING
> +/* Reported page accessors, defined in page_alloc.c */
> +void free_reported_page(struct page *page, unsigned int order);
> +
> +/* Free reported_pages and reset reported page tracking count to 0 */
> +static inline void page_reporting_reset_zone(struct zone *zone)
> +{
> + kfree(zone->reported_pages);
> + zone->reported_pages = NULL;
> +}
> +
> +/* Boundary functions */
> +static inline pgoff_t
> +get_reporting_index(unsigned int order, unsigned int migratetype)
> +{
> + /*
> + * We will only ever be dealing with pages greater-than or equal to
> + * PAGE_REPORTING_MIN_ORDER. Since that is the case we can avoid
> + * allocating unused space by limiting our index range to only the
> + * orders that are supported for page reporting.
> + */
> + return (order - PAGE_REPORTING_MIN_ORDER) * MIGRATE_TYPES + migratetype;
> +}
> +
> +extern struct list_head **reported_boundary __read_mostly;
> +
> +static inline void
> +page_reporting_reset_boundary(struct zone *zone, unsigned int order, int mt)
> +{
> + int index;
> +
> + if (order < PAGE_REPORTING_MIN_ORDER)
> + return;
> + if (!test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> + return;
> +
> + index = get_reporting_index(order, mt);
> + reported_boundary[index] = &zone->free_area[order].free_list[mt];
> +}
So this seems to be costly.
I'm guessing it's the access to flags:
/* zone flags, see below */
unsigned long flags;
/* Primarily protects free_area */
spinlock_t lock;
which is in the same cache line as the lock.
> +
> +static inline void page_reporting_disable_boundaries(struct zone *zone)
> +{
> + /* zone lock should be held when this function is called */
> + lockdep_assert_held(&zone->lock);
> +
> + __clear_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
> +}
> +
> +static inline void
> +page_reporting_free_area_release(struct zone *zone, unsigned int order, int mt)
> +{
> + page_reporting_reset_boundary(zone, order, mt);
> +}
> +
> +/*
> + * Method for obtaining the tail of the free list. Using this allows for
> + * tail insertions of unreported pages into the region that is currently
> + * being scanned so as to avoid interleaving reported and unreported pages.
> + */
> +static inline struct list_head *
> +get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
> +{
> + if (order >= PAGE_REPORTING_MIN_ORDER &&
> + test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> + return reported_boundary[get_reporting_index(order,
> + migratetype)];
> +
> + return &zone->free_area[order].free_list[migratetype];
> +}
> +
> +/*
> + * Functions for adding/removing reported pages to the freelist.
> + * All of them expect the zone lock to be held to maintain
> + * consistency of the reported list as a subset of the free list.
> + */
> +static inline void
> +add_page_to_reported_list(struct page *page, struct zone *zone,
> + unsigned int order, unsigned int mt)
> +{
> + /*
> + * Default to using index 0, this will be updated later if the zone
> + * is still being processed.
> + */
> + page->index = 0;
> +
> + /* flag page as reported */
> + __SetPageReported(page);
> +
> + /* update areated page accounting */
> + zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
> +}
> +
> +static inline void page_reporting_pull_boundary(struct page *page)
> +{
> + struct list_head **tail = &reported_boundary[page->index];
> +
> + if (*tail == &page->lru)
> + *tail = page->lru.next;
> +}
> +
> +static inline void
> +__del_page_from_reported_list(struct page *page, struct zone *zone)
> +{
> + /*
> + * Since the page is being pulled from the list we need to update
> + * the boundary, after that we can just update the index so that
> + * the correct boundary will be checked in the future.
> + */
> + if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> + page_reporting_pull_boundary(page);
> +}
> +
> +static inline void
> +del_page_from_reported_list(struct page *page, struct zone *zone,
> + unsigned int order)
> +{
> + __del_page_from_reported_list(page, zone);
> +
> + /* page_private will contain the page order, so just use it directly */
> + zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]--;
> +
> + /* clear the flag so we can report on it when it returns */
> + __ClearPageReported(page);
> +}
> +
> +#else /* CONFIG_PAGE_REPORTING */
> +static inline void page_reporting_reset_zone(struct zone *zone)
> +{
> +}
> +
> +static inline void
> +page_reporting_free_area_release(struct zone *zone, unsigned int order, int mt)
> +{
> +}
> +
> +static inline struct list_head *
> +get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
> +{
> + return &zone->free_area[order].free_list[migratetype];
> +}
> +
> +static inline void
> +add_page_to_reported_list(struct page *page, struct zone *zone,
> + int order, int migratetype)
> +{
> +}
> +
> +static inline void
> +__del_page_from_reported_list(struct page *page, struct zone *zone)
> +{
> +}
> +
> +static inline void
> +del_page_from_reported_list(struct page *page, struct zone *zone,
> + unsigned int order)
> +{
> +}
> +
> +static inline void
> +move_page_to_reported_list(struct page *page, struct zone *zone, int dest_mt)
> +{
> +}
> +#endif /* CONFIG_PAGE_REPORTING */
> +#endif /*_MM_PAGE_REPORTING_H */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] iommu/io-pgtable-arm: Mali LPAE improvements
From: Tomeu Vizoso @ 2019-09-23 8:17 UTC (permalink / raw)
To: Will Deacon
Cc: Rob Herring, Neil Armstrong, Joerg Roedel, Steven Price,
Linux IOMMU, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190919083035.tv446nelad6ki6db@willie-the-truck>
On Thu, 19 Sep 2019 at 10:31, Will Deacon <will@kernel.org> wrote:
>
> On Wed, Sep 11, 2019 at 06:19:40PM +0100, Robin Murphy wrote:
> > On 2019-09-11 5:20 pm, Will Deacon wrote:
> > > On Wed, Sep 11, 2019 at 06:19:04PM +0200, Neil Armstrong wrote:
> > > > On 11/09/2019 16:42, Robin Murphy wrote:
> > > > > Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of
> > > > > other bits that I've collected so far. I'm not considering this as
> > > > > 5.3 fixes material, but it would be nice if there's any chance still
> > > > > to sneak it into 5.4.
> > > > >
> > > > > Robin.
> > > > >
> > > > >
> > > > > Robin Murphy (3):
> > > > > iommu/io-pgtable-arm: Correct Mali attributes
> > > > > iommu/io-pgtable-arm: Support more Mali configurations
> > > > > iommu/io-pgtable-arm: Allow coherent walks for Mali
> > > > >
> > > > > drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
> > > > > 1 file changed, 48 insertions(+), 13 deletions(-)
> > > > >
> > > >
> > > > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > > >
> > > > On Khadas VIM2 (Amlogic S912) with T820 Mali GPU
> > > >
> > > > I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !
> > >
> > > Not a chance -- the merge window opens on Monday and -next isn't being
> > > rolled out at the moment due to LPC. Let's shoot for 5.5 and get this
> > > queued up in a few weeks.
> >
> > Fair enough, that was certainly more extreme optimism than realistic
> > expectation on my part :)
> >
> > There is some argument for taking #1 and #2 as 5.4 fixes, though - the
> > upcoming Mesa 19.2 release will enable T820 support on the userspace side -
> > so let's pick that discussion up again in a few weeks.
>
> Ok, I'll include those two in my fixes pull to Joerg at -rc1.
Hi Will,
Looks like this didn't end up happening?
Thanks,
Tomeu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
From: Vlastimil Babka @ 2019-09-23 8:20 UTC (permalink / raw)
To: Andrey Ryabinin, Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger, Qian Cai,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <4e76e7ce-1d61-524a-622b-663c01d19707@virtuozzo.com>
On 9/16/19 5:57 PM, Andrey Ryabinin wrote:
> I'd rather keep all logic in one place, i.e. "if (!page_owner_disabled && (IS_ENABLED(CONFIG_KASAN) || debug_pagealloc_enabled())"
> With this no changes in early_debug_pagealloc() required and CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y should also work correctly.
OK.
----8<----
From 7437c43f02682fdde5680fa83e87029f7529e222 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Mon, 16 Sep 2019 11:28:19 +0200
Subject: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
The commit "mm, page_owner, debug_pagealloc: save and dump freeing stack trace"
enhanced page_owner to also store freeing stack trace, when debug_pagealloc is
also enabled. KASAN would also like to do this [1] to improve error reports to
debug e.g. UAF issues. This patch therefore introduces a helper config option
PAGE_OWNER_FREE_STACK, which is enabled when PAGE_OWNER and either of
DEBUG_PAGEALLOC or KASAN is enabled. Boot-time, the free stack saving is
enabled when booting a KASAN kernel with page_owner=on, or non-KASAN kernel
with debug_pagealloc=on and page_owner=on.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Suggested-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Documentation/dev-tools/kasan.rst | 4 ++++
mm/Kconfig.debug | 4 ++++
mm/page_owner.c | 31 ++++++++++++++++++-------------
3 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index b72d07d70239..434e605030e9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -41,6 +41,10 @@ smaller binary while the latter is 1.1 - 2 times faster.
Both KASAN modes work with both SLUB and SLAB memory allocators.
For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
+To augment reports with last allocation and freeing stack of the physical
+page, it is recommended to configure kernel also with CONFIG_PAGE_OWNER = y
+and boot with page_owner=on.
+
To disable instrumentation for specific files or directories, add a line
similar to the following to the respective kernel Makefile:
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 327b3ebf23bf..1ea247da3322 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -62,6 +62,10 @@ config PAGE_OWNER
If unsure, say N.
+config PAGE_OWNER_FREE_STACK
+ def_bool KASAN || DEBUG_PAGEALLOC
+ depends on PAGE_OWNER
+
config PAGE_POISONING
bool "Poison pages after freeing"
select PAGE_POISONING_NO_SANITY if HIBERNATION
diff --git a/mm/page_owner.c b/mm/page_owner.c
index dee931184788..8b6b05676158 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -24,13 +24,14 @@ struct page_owner {
short last_migrate_reason;
gfp_t gfp_mask;
depot_stack_handle_t handle;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t free_handle;
#endif
};
static bool page_owner_disabled = true;
DEFINE_STATIC_KEY_FALSE(page_owner_inited);
+static DEFINE_STATIC_KEY_FALSE(page_owner_free_stack);
static depot_stack_handle_t dummy_handle;
static depot_stack_handle_t failure_handle;
@@ -91,6 +92,8 @@ static void init_page_owner(void)
register_failure_stack();
register_early_stack();
static_branch_enable(&page_owner_inited);
+ if (IS_ENABLED(CONFIG_KASAN) || debug_pagealloc_enabled())
+ static_branch_enable(&page_owner_free_stack);
init_early_allocated_pages();
}
@@ -148,11 +151,11 @@ void __reset_page_owner(struct page *page, unsigned int order)
{
int i;
struct page_ext *page_ext;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t handle = 0;
struct page_owner *page_owner;
- if (debug_pagealloc_enabled())
+ if (static_branch_unlikely(&page_owner_free_stack))
handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
#endif
@@ -161,8 +164,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
if (unlikely(!page_ext))
continue;
__clear_bit(PAGE_EXT_OWNER_ACTIVE, &page_ext->flags);
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled()) {
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
page_owner = get_page_owner(page_ext);
page_owner->free_handle = handle;
}
@@ -451,14 +454,16 @@ void __dump_page_owner(struct page *page)
stack_trace_print(entries, nr_entries, 0);
}
-#ifdef CONFIG_DEBUG_PAGEALLOC
- handle = READ_ONCE(page_owner->free_handle);
- if (!handle) {
- pr_alert("page_owner free stack trace missing\n");
- } else {
- nr_entries = stack_depot_fetch(handle, &entries);
- pr_alert("page last free stack trace:\n");
- stack_trace_print(entries, nr_entries, 0);
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
+ handle = READ_ONCE(page_owner->free_handle);
+ if (!handle) {
+ pr_alert("page_owner free stack trace missing\n");
+ } else {
+ nr_entries = stack_depot_fetch(handle, &entries);
+ pr_alert("page last free stack trace:\n");
+ stack_trace_print(entries, nr_entries, 0);
+ }
}
#endif
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/4] pwm: mxs: implement ->apply
From: Uwe Kleine-König @ 2019-09-23 8:24 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: devicetree, linux-pwm, Shawn Guo, Sascha Hauer, linux-kernel,
Rob Herring, Thierry Reding, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190923081348.6843-2-linux@rasmusvillemoes.dk>
Hello Rasmus,
On Mon, Sep 23, 2019 at 10:13:45AM +0200, Rasmus Villemoes wrote:
> In preparation for supporting setting the polarity, switch the driver
> to support the ->apply method.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/pwm/pwm-mxs.c | 62 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
> index 04c0f6b95c1a..c70c26a9ff68 100644
> --- a/drivers/pwm/pwm-mxs.c
> +++ b/drivers/pwm/pwm-mxs.c
> @@ -26,6 +26,7 @@
> #define PERIOD_PERIOD_MAX 0x10000
> #define PERIOD_ACTIVE_HIGH (3 << 16)
> #define PERIOD_INACTIVE_LOW (2 << 18)
> +#define PERIOD_POLARITY_NORMAL (PERIOD_ACTIVE_HIGH | PERIOD_INACTIVE_LOW)
> #define PERIOD_CDIV(div) (((div) & 0x7) << 20)
> #define PERIOD_CDIV_MAX 8
>
> @@ -41,6 +42,66 @@ struct mxs_pwm_chip {
>
> #define to_mxs_pwm_chip(_chip) container_of(_chip, struct mxs_pwm_chip, chip)
>
> +static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct mxs_pwm_chip *mxs = to_mxs_pwm_chip(chip);
> + int ret, div = 0;
> + unsigned int period_cycles, duty_cycles;
> + unsigned long rate;
> + unsigned long long c;
> +
> + if (state->polarity != PWM_POLARITY_NORMAL)
> + return -ENOTSUPP;
> +
> + rate = clk_get_rate(mxs->clk);
> + while (1) {
> + c = rate / cdiv[div];
> + c = c * state->period;
> + do_div(c, 1000000000);
> + if (c < PERIOD_PERIOD_MAX)
> + break;
> + div++;
> + if (div >= PERIOD_CDIV_MAX)
> + return -EINVAL;
> + }
> +
> + period_cycles = c;
> + c *= state->duty_cycle;
> + do_div(c, state->period);
> + duty_cycles = c;
> +
> + /*
> + * If the PWM channel is disabled, make sure to turn on the clock
> + * before writing the register. Otherwise, keep it enabled.
> + */
> + if (!pwm_is_enabled(pwm)) {
> + ret = clk_prepare_enable(mxs->clk);
> + if (ret)
> + return ret;
> + }
> +
> + writel(duty_cycles << 16,
> + mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
> + writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
> + mxs->base + PWM_PERIOD0 + pwm->hwpwm * 0x20);
> +
> + if (state->enabled) {
> + if (!pwm_is_enabled(pwm)) {
> + /*
> + * The clock was enabled above. Just enable
> + * the channel in the control register.
> + */
> + writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + SET);
> + }
> + } else {
> + if (pwm_is_enabled(pwm))
> + writel(1 << pwm->hwpwm, mxs->base + PWM_CTRL + CLR);
> + clk_disable_unprepare(mxs->clk);
> + }
> + return 0;
> +}
Maybe it would be easier to review when converting from .config +
.enable + .disable to .apply in a single step. (Note this "maybe" is
honest, I'm not entirely sure.)
There is a bug: If the PWM is running at (say) period=100ms, duty=0ms
and we call
pwm_apply_state(pwm, { .enabled = false, duty=100000, period=1000000 });
the output might get high which it should not.
Also there is a bug already in .config: You are not supposed to call
clk_get_rate if the clk might be off.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] pwm: mxs: add support for inverse polarity
From: Uwe Kleine-König @ 2019-09-23 8:27 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: devicetree, linux-pwm, Shawn Guo, Sascha Hauer, linux-kernel,
Rob Herring, Thierry Reding, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190923081348.6843-4-linux@rasmusvillemoes.dk>
On Mon, Sep 23, 2019 at 10:13:47AM +0200, Rasmus Villemoes wrote:
> If I'm reading of_pwm_xlate_with_flags() right, existing device trees
> that set #pwm-cells = 2 will continue to work.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/pwm/pwm-mxs.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
> index 284107784dad..c46697acaf11 100644
> --- a/drivers/pwm/pwm-mxs.c
> +++ b/drivers/pwm/pwm-mxs.c
> @@ -25,8 +25,11 @@
> #define PERIOD_PERIOD(p) ((p) & 0xffff)
> #define PERIOD_PERIOD_MAX 0x10000
> #define PERIOD_ACTIVE_HIGH (3 << 16)
> +#define PERIOD_ACTIVE_LOW (2 << 16)
> +#define PERIOD_INACTIVE_HIGH (3 << 18)
> #define PERIOD_INACTIVE_LOW (2 << 18)
> #define PERIOD_POLARITY_NORMAL (PERIOD_ACTIVE_HIGH | PERIOD_INACTIVE_LOW)
> +#define PERIOD_POLARITY_INVERSE (PERIOD_ACTIVE_LOW | PERIOD_INACTIVE_HIGH)
> #define PERIOD_CDIV(div) (((div) & 0x7) << 20)
> #define PERIOD_CDIV_MAX 8
>
> @@ -50,9 +53,7 @@ static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> unsigned int period_cycles, duty_cycles;
> unsigned long rate;
> unsigned long long c;
> -
> - if (state->polarity != PWM_POLARITY_NORMAL)
> - return -ENOTSUPP;
> + unsigned int pol_bits;
>
> rate = clk_get_rate(mxs->clk);
> while (1) {
> @@ -81,9 +82,12 @@ static int mxs_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> return ret;
> }
>
> + pol_bits = state->polarity == PWM_POLARITY_NORMAL ?
> + PERIOD_POLARITY_NORMAL : PERIOD_POLARITY_INVERSE;
> +
> writel(duty_cycles << 16,
> mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
> - writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
> + writel(PERIOD_PERIOD(period_cycles) | pol_bits | PERIOD_CDIV(div),
When will this affect the output? Only on the next start of a period, or
immediatly? Can it happen that this results in a mixed output (i.e. a
period that has already the new duty cycle from the line above but not
the new polarity (or period)?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-23 8:28 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Marc Zyngier, Anshuman Khandual,
Matthew Wilcox, Kaly Xin, hejianet, Ralph Campbell,
Suzuki Poulose, Jérôme Glisse, Thomas Gleixner, nd,
linux-arm-kernel, linux-kernel, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190921135054.142360-4-justin.he@arm.com>
On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
> in case there can be some obscure use-case.(by Kirill)
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> Signed-off-by: Jia He <justin.he@arm.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/3] reset: meson: add Meson-A1 SoC support
From: Xingyu Chen @ 2019-09-23 8:34 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Neil Armstrong
Cc: devicetree, Hanjie Lin, Jianxin Pan, linux-kernel, Rob Herring,
linux-arm-kernel, linux-amlogic, Xingyu Chen, Jerome Brunet
This patchset adds support for Meson-A1 SoC Reset Controller. A new struct
meson_reset_param is introduced to describe the register differences between
Meson-A1 and previous SoCs.
This patchset is based on A1 DTBv4[0].
Changes since v1 at [1]:
- rebase on linux-next
- add Neil's Reviewed-by
[0] https://lore.kernel.org/linux-amlogic/1568276370-54181-1-git-send-email-jianxin.pan@amlogic.com
[1] https://lore.kernel.org/linux-amlogic/1568808746-1153-1-git-send-email-xingyu.chen@amlogic.com
Xingyu Chen (3):
arm64: dts: meson: add reset controller for Meson-A1 SoC
dt-bindings: reset: add bindings for the Meson-A1 SoC Reset Controller
reset: add support for the Meson-A1 SoC Reset Controller
.../bindings/reset/amlogic,meson-reset.yaml | 1 +
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 6 +++
drivers/reset/reset-meson.c | 35 ++++++++++---
include/dt-bindings/reset/amlogic,meson-a1-reset.h | 59 ++++++++++++++++++++++
4 files changed, 94 insertions(+), 7 deletions(-)
create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: meson: add reset controller for Meson-A1 SoC
From: Xingyu Chen @ 2019-09-23 8:34 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Neil Armstrong
Cc: devicetree, Hanjie Lin, Jianxin Pan, linux-kernel, Rob Herring,
linux-arm-kernel, linux-amlogic, Xingyu Chen, Jerome Brunet
In-Reply-To: <1569227661-4261-1-git-send-email-xingyu.chen@amlogic.com>
Add the reset controller device of Meson-A1 SoC family
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index 7210ad0..1c588ab 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -74,6 +74,12 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x1000000>;
+ reset: reset-controller@0 {
+ compatible = "amlogic,meson-a1-reset";
+ reg = <0x0 0x0 0x0 0x8c>;
+ #reset-cells = <1>;
+ };
+
uart_AO: serial@1c00 {
compatible = "amlogic,meson-gx-uart",
"amlogic,meson-ao-uart";
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: reset: add bindings for the Meson-A1 SoC Reset Controller
From: Xingyu Chen @ 2019-09-23 8:34 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Neil Armstrong
Cc: devicetree, Hanjie Lin, Jianxin Pan, linux-kernel, Rob Herring,
linux-arm-kernel, linux-amlogic, Xingyu Chen, Jerome Brunet
In-Reply-To: <1569227661-4261-1-git-send-email-xingyu.chen@amlogic.com>
Add DT bindings for the Meson-A1 SoC Reset Controller include file,
and also slightly update documentation.
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
---
.../bindings/reset/amlogic,meson-reset.yaml | 1 +
include/dt-bindings/reset/amlogic,meson-a1-reset.h | 59 ++++++++++++++++++++++
2 files changed, 60 insertions(+)
create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
index 00917d8..b3f57d8 100644
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
@@ -16,6 +16,7 @@ properties:
- amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
- amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
- amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
+ - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs
reg:
maxItems: 1
diff --git a/include/dt-bindings/reset/amlogic,meson-a1-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-reset.h
new file mode 100644
index 00000000..8d76a47
--- /dev/null
+++ b/include/dt-bindings/reset/amlogic,meson-a1-reset.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ *
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen <xingyu.chen@amlogic.com>
+ *
+ */
+
+#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H
+#define _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H
+
+/* RESET0 */
+#define RESET_AM2AXI_VAD 1
+#define RESET_PSRAM 4
+#define RESET_PAD_CTRL 5
+#define RESET_TEMP_SENSOR 7
+#define RESET_AM2AXI_DEV 8
+#define RESET_SPICC_A 10
+#define RESET_MSR_CLK 11
+#define RESET_AUDIO 12
+#define RESET_ANALOG_CTRL 13
+#define RESET_SAR_ADC 14
+#define RESET_AUDIO_VAD 15
+#define RESET_CEC 16
+#define RESET_PWM_EF 17
+#define RESET_PWM_CD 18
+#define RESET_PWM_AB 19
+#define RESET_IR_CTRL 21
+#define RESET_I2C_S_A 22
+#define RESET_I2C_M_D 24
+#define RESET_I2C_M_C 25
+#define RESET_I2C_M_B 26
+#define RESET_I2C_M_A 27
+#define RESET_I2C_PROD_AHB 28
+#define RESET_I2C_PROD 29
+
+/* RESET1 */
+#define RESET_ACODEC 32
+#define RESET_DMA 33
+#define RESET_SD_EMMC_A 34
+#define RESET_USBCTRL 36
+#define RESET_USBPHY 38
+#define RESET_RSA 42
+#define RESET_DMC 43
+#define RESET_IRQ_CTRL 45
+#define RESET_NIC_VAD 47
+#define RESET_NIC_AXI 48
+#define RESET_RAMA 49
+#define RESET_RAMB 50
+#define RESET_ROM 53
+#define RESET_SPIFC 54
+#define RESET_GIC 55
+#define RESET_UART_C 56
+#define RESET_UART_B 57
+#define RESET_UART_A 58
+#define RESET_OSC_RING 59
+
+/* RESET2 Reserved */
+
+#endif
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/3] reset: add support for the Meson-A1 SoC Reset Controller
From: Xingyu Chen @ 2019-09-23 8:34 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Neil Armstrong
Cc: Hanjie Lin, Jianxin Pan, linux-kernel, Rob Herring,
linux-arm-kernel, linux-amlogic, Xingyu Chen, Jerome Brunet
In-Reply-To: <1569227661-4261-1-git-send-email-xingyu.chen@amlogic.com>
The number of RESET registers and offset of RESET_LEVEL register for
Meson-A1 are different from previous SoCs, In order to describe these
differences, we introduce the struct meson_reset_param.
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/reset/reset-meson.c | 35 ++++++++++++++++++++++++++++-------
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index 7d05d76..94d7ba8 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -15,12 +15,16 @@
#include <linux/types.h>
#include <linux/of_device.h>
-#define REG_COUNT 8
#define BITS_PER_REG 32
-#define LEVEL_OFFSET 0x7c
+
+struct meson_reset_param {
+ int reg_count;
+ int level_offset;
+};
struct meson_reset {
void __iomem *reg_base;
+ const struct meson_reset_param *param;
struct reset_controller_dev rcdev;
spinlock_t lock;
};
@@ -46,10 +50,12 @@ static int meson_reset_level(struct reset_controller_dev *rcdev,
container_of(rcdev, struct meson_reset, rcdev);
unsigned int bank = id / BITS_PER_REG;
unsigned int offset = id % BITS_PER_REG;
- void __iomem *reg_addr = data->reg_base + LEVEL_OFFSET + (bank << 2);
+ void __iomem *reg_addr;
unsigned long flags;
u32 reg;
+ reg_addr = data->reg_base + data->param->level_offset + (bank << 2);
+
spin_lock_irqsave(&data->lock, flags);
reg = readl(reg_addr);
@@ -81,10 +87,21 @@ static const struct reset_control_ops meson_reset_ops = {
.deassert = meson_reset_deassert,
};
+static const struct meson_reset_param meson8b_param = {
+ .reg_count = 8,
+ .level_offset = 0x7c,
+};
+
+static const struct meson_reset_param meson_a1_param = {
+ .reg_count = 3,
+ .level_offset = 0x40,
+};
+
static const struct of_device_id meson_reset_dt_ids[] = {
- { .compatible = "amlogic,meson8b-reset" },
- { .compatible = "amlogic,meson-gxbb-reset" },
- { .compatible = "amlogic,meson-axg-reset" },
+ { .compatible = "amlogic,meson8b-reset", .data = &meson8b_param},
+ { .compatible = "amlogic,meson-gxbb-reset", .data = &meson8b_param},
+ { .compatible = "amlogic,meson-axg-reset", .data = &meson8b_param},
+ { .compatible = "amlogic,meson-a1-reset", .data = &meson_a1_param},
{ /* sentinel */ },
};
@@ -102,12 +119,16 @@ static int meson_reset_probe(struct platform_device *pdev)
if (IS_ERR(data->reg_base))
return PTR_ERR(data->reg_base);
+ data->param = of_device_get_match_data(&pdev->dev);
+ if (!data->param)
+ return -ENODEV;
+
platform_set_drvdata(pdev, data);
spin_lock_init(&data->lock);
data->rcdev.owner = THIS_MODULE;
- data->rcdev.nr_resets = REG_COUNT * BITS_PER_REG;
+ data->rcdev.nr_resets = data->param->reg_count * BITS_PER_REG;
data->rcdev.ops = &meson_reset_ops;
data->rcdev.of_node = pdev->dev.of_node;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/1] clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate
From: Jerome Brunet @ 2019-09-23 8:38 UTC (permalink / raw)
To: Martin Blumenstingl, narmstrong, linux-amlogic
Cc: Martin Blumenstingl, linux-kernel, linux-arm-kernel, linux-clk
In-Reply-To: <20190921150411.767290-1-martin.blumenstingl@googlemail.com>
On Sat 21 Sep 2019 at 17:04, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> The meson-saradc driver manually sets the input clock for
> sar_adc_clk_sel. Update the GXBB clock driver (which is used on GXBB,
> GXL and GXM) so the rate settings on sar_adc_clk_div are propagated up
> to sar_adc_clk_sel which will let the common clock framework select the
> best matching parent clock if we want that.
>
> This makes sar_adc_clk_div consistent with the axg-aoclk and g12a-aoclk
> drivers, which both also specify CLK_SET_RATE_PARENT.
>
> Fixes: 33d0fcdfe0e870 ("clk: gxbb: add the SAR ADC clocks and expose them")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Looks good. I'll apply it once rc1 is tagged
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] pwm: mxs: add support for inverse polarity
From: Rasmus Villemoes @ 2019-09-23 8:45 UTC (permalink / raw)
To: Uwe Kleine-König, Rasmus Villemoes
Cc: devicetree, linux-pwm, Shawn Guo, Sascha Hauer, linux-kernel,
Rob Herring, Thierry Reding, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190923082735.tzxyhvjlnztsxhsc@pengutronix.de>
On 23/09/2019 10.27, Uwe Kleine-König wrote:
> On Mon, Sep 23, 2019 at 10:13:47AM +0200, Rasmus Villemoes wrote:
>>
>>
>> + pol_bits = state->polarity == PWM_POLARITY_NORMAL ?
>> + PERIOD_POLARITY_NORMAL : PERIOD_POLARITY_INVERSE;
>> +
>> writel(duty_cycles << 16,
>> mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
>> - writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
>> + writel(PERIOD_PERIOD(period_cycles) | pol_bits | PERIOD_CDIV(div),
>
> When will this affect the output? Only on the next start of a period, or
> immediatly? Can it happen that this results in a mixed output (i.e. a
> period that has already the new duty cycle from the line above but not
> the new polarity (or period)?
The data sheet says "Also, when the user reprograms the channel in this
manner, the new register values will not take effect until the beginning
of a new output period. This eliminates the potential for output
glitches that could occur if the registers were updated while the
channel was enabled and in the middle of a cycle.". So I think this
should be ok. "this manner" refers to the registers being written in the
proper order (first ACTIVEn, then PERIODn).
Rasmus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/10] ASoC: wm8994: Add support for MCLKn clock gating
From: Charles Keepax @ 2019-09-23 8:51 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190920130218.32690-5-s.nawrocki@samsung.com>
On Fri, Sep 20, 2019 at 03:02:13PM +0200, Sylwester Nawrocki wrote:
> As an intermediate step before covering the clocking subsystem
> of the CODEC entirely by the clk API add handling of external CODEC's
> master clocks in DAPM events when the AIFn clocks are sourced directly
> from MCLKn; when FLLn are used we enable/disable respective MCLKn
> before/after FLLn is enabled/disabled.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
Looks good to me:
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] pwm: mxs: add support for inverse polarity
From: Uwe Kleine-König @ 2019-09-23 8:54 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: devicetree, linux-pwm, Fabio Estevam, Sascha Hauer, linux-kernel,
Rob Herring, Thierry Reding, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, linux-arm-kernel
In-Reply-To: <d2b29144-3de8-4561-3292-49db7e697aca@rasmusvillemoes.dk>
On Mon, Sep 23, 2019 at 10:45:56AM +0200, Rasmus Villemoes wrote:
> On 23/09/2019 10.27, Uwe Kleine-König wrote:
> > On Mon, Sep 23, 2019 at 10:13:47AM +0200, Rasmus Villemoes wrote:
> >>
> >>
> >> + pol_bits = state->polarity == PWM_POLARITY_NORMAL ?
> >> + PERIOD_POLARITY_NORMAL : PERIOD_POLARITY_INVERSE;
> >> +
> >> writel(duty_cycles << 16,
> >> mxs->base + PWM_ACTIVE0 + pwm->hwpwm * 0x20);
> >> - writel(PERIOD_PERIOD(period_cycles) | PERIOD_POLARITY_NORMAL | PERIOD_CDIV(div),
> >> + writel(PERIOD_PERIOD(period_cycles) | pol_bits | PERIOD_CDIV(div),
> >
> > When will this affect the output? Only on the next start of a period, or
> > immediatly? Can it happen that this results in a mixed output (i.e. a
> > period that has already the new duty cycle from the line above but not
> > the new polarity (or period)?
>
> The data sheet says "Also, when the user reprograms the channel in this
> manner, the new register values will not take effect until the beginning
> of a new output period. This eliminates the potential for output
> glitches that could occur if the registers were updated while the
> channel was enabled and in the middle of a cycle.". So I think this
> should be ok. "this manner" refers to the registers being written in the
> proper order (first ACTIVEn, then PERIODn).
OK. IMHO this is worth a code comment.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
From: Andrzej Hajda @ 2019-09-23 8:59 UTC (permalink / raw)
To: Guido Günther, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Neil Armstrong, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Lee Jones, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, Robert Chiras, Sam Ravnborg,
Arnd Bergmann
In-Reply-To: <3bef8eb6a7dd32406e31c68f39ccde3accb58222.1569170717.git.agx@sigxcpu.org>
On 22.09.2019 18:47, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> Tested-by: Robert Chiras <robert.chiras@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 176 ++++++++++++++++++
> 1 file changed, 176 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> new file mode 100644
> index 000000000000..31119c7885ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -0,0 +1,176 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: https://protect2.fireeye.com/url?k=7c9397fbdbbe3fd5.7c921cb4-87fc4542b5f41502&u=http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> +
> +maintainers:
> + - Guido Gúnther <agx@sigxcpu.org>
> + - Robert Chiras <robert.chiras@nxp.com>
> +
> +description: |
> + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge for
> + the SOCs NWL MIPI-DSI host controller.
> +
> +properties:
> + compatible:
> + const: fsl,imx8mq-nwl-dsi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + clocks:
> + items:
> + - description: DSI core clock
> + - description: RX_ESC clock (used in escape mode)
> + - description: TX_ESC clock (used in escape mode)
> + - description: PHY_REF clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: rx_esc
> + - const: tx_esc
> + - const: phy_ref
> +
> + mux-controls:
> + description:
> + mux controller node to use for operating the input mux
> +
> + phys:
> + maxItems: 1
> + description:
> + A phandle to the phy module representing the DPHY
> +
> + phy-names:
> + items:
> + - const: dphy
> +
> + power-domains:
> + maxItems: 1
> +
> + resets:
> + items:
> + - description: dsi byte reset line
> + - description: dsi dpi reset line
> + - description: dsi esc reset line
> + - description: dsi pclk reset line
> +
> + reset-names:
> + items:
> + - const: byte
> + - const: dpi
> + - const: esc
> + - const: pclk
> +
> + ports:
> + type: object
> + description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/graph.txt.
> + properties:
> + port@0:
> + type: object
> + description:
> + Input port node to receive pixel data from the
> + display controller
> +
> + port@1:
> + type: object
> + description:
> + DSI output port node to the panel or the next bridge
> + in the chain
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + - port@0
> + - port@1
> +
> + additionalProperties: false
> +
> +patternProperties:
> + "^panel@[0-9]+$":
> + type: object
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - clock-names
> + - clocks
> + - compatible
> + - interrupts
> + - mux-controls
As I understand mux is not a part of the device, so maybe would be safer
to make it optional.
Regards
Andrzej
> + - phy-names
> + - phys
> + - ports
> + - reg
> + - reset-names
> + - resets
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + mipi_dsi: mipi_dsi@30a00000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A00000 0x300>;
> + clocks = <&clk 163>, <&clk 244>, <&clk 245>, <&clk 164>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + interrupts = <0 34 4>;
> + mux-controls = <&mux 0>;
> + power-domains = <&pgc_mipi>;
> + resets = <&src 0>, <&src 1>, <&src 2>, <&src 3>;
> + reset-names = "byte", "dpi", "esc", "pclk";
> + phys = <&dphy>;
> + phy-names = "dphy";
> +
> + panel@0 {
> + compatible = "rocktech,jh057n00900";
> + reg = <0>;
> + port@0 {
> + panel_in: endpoint {
> + remote-endpoint = <&mipi_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mipi_dsi_in: endpoint {
> + remote-endpoint = <&lcdif_mipi_dsi>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + mipi_dsi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> + };
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] pwm: mxs: implement ->apply
From: Rasmus Villemoes @ 2019-09-23 9:04 UTC (permalink / raw)
To: Uwe Kleine-König, Rasmus Villemoes
Cc: devicetree, linux-pwm, Shawn Guo, Sascha Hauer, linux-kernel,
Rob Herring, Thierry Reding, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190923082459.huqpbz5eseonkscv@pengutronix.de>
On 23/09/2019 10.24, Uwe Kleine-König wrote:
> Hello Rasmus,
>
> On Mon, Sep 23, 2019 at 10:13:45AM +0200, Rasmus Villemoes wrote:
>> In preparation for supporting setting the polarity, switch the driver
>> to support the ->apply method.
>>
>
> Maybe it would be easier to review when converting from .config +
> .enable + .disable to .apply in a single step. (Note this "maybe" is
> honest, I'm not entirely sure.)
I tried to make .apply do exactly what the old sequence of calls from
the core to the individual methods would do, and for that it seemed a
little easier to keep the old methods around - but yes, I do need to be
more careful than that to provide the atomicity guarantee that the
legacy methods did not. It's also much easier to squash than to split,
so for now I'll leave them separate - if somebody prefers them squashed,
I'll do that.
> There is a bug: If the PWM is running at (say) period=100ms, duty=0ms
> and we call
> pwm_apply_state(pwm, { .enabled = false, duty=100000, period=1000000 });
> the output might get high which it should not.
Ah, yes. So I suppose that if we're changing from enabled to disabled,
we should simply disable it in the CTRL register before changing the
duty/period.
> Also there is a bug already in .config: You are not supposed to call
> clk_get_rate if the clk might be off.
Interesting, I didn't know that. So the prepare_enable logic needs to be
moved before we start computing the period/duty cycles. Do you know why
it has apparently worked so far? I would have thought such a rule would
be enforced by the clock framework, or at least produced a warning.
Thanks for the fast review. I'll wait a day or two to see if there are
other comments before sending out a v2.
Rasmus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: add vendor prefix for logic technologies limited
From: Philippe Schenker @ 2019-09-23 9:07 UTC (permalink / raw)
To: marcel@ziswiler.com, dri-devel@lists.freedesktop.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, heiko@sntech.de,
Marcel Ziswiler, j.bauer@endrich.com,
linux-kernel@vger.kernel.org, mripard@kernel.org,
info@logictechno.com, robh+dt@kernel.org,
laurent.pinchart@ideasonboard.com, hverkuil-cisco@xs4all.nl,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
icenowy@aosc.io
In-Reply-To: <20190920075411.15735-1-marcel@ziswiler.com>
On Fri, 2019-09-20 at 09:54 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> Add vendor prefix for Logic Technologies Limited [1] which is a
> Chinese
> display manufacturer e.g. distributed by German Endrich Bauelemente
> Vertriebs GmbH [2].
>
> [1] https://logictechno.com/contact-us/
> [2]
> https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com>
>
> ---
>
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 967e78c5ec0a..1441146f394f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -541,6 +541,8 @@ patternProperties:
> description: Linear Technology Corporation
> "^logicpd,.*":
> description: Logic PD, Inc.
> + "^logictechno,.*":
> + description: Logic Technologies Limited
> "^longcheer,.*":
> description: Longcheer Technology (Shanghai) Co., Ltd.
> "^lsi,.*":
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox