* Re: [PATCH v7 07/13] soc: mediatek: Refactor bus protection control
From: Matthias Brugger @ 2019-08-28 10:28 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-8-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Put bus protection enable and disable control in separate functions.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Applied to v5.4-next/soc
Thanks!
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 44 ++++++++++++++++++++++++++-------------
> 1 file changed, 30 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index ad0f619..fb2b027 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -274,6 +274,30 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
> MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> }
>
> +static int scpsys_bus_protect_enable(struct scp_domain *scpd)
> +{
> + struct scp *scp = scpd->scp;
> +
> + if (!scpd->data->bus_prot_mask)
> + return 0;
> +
> + return mtk_infracfg_set_bus_protection(scp->infracfg,
> + scpd->data->bus_prot_mask,
> + scp->bus_prot_reg_update);
> +}
> +
> +static int scpsys_bus_protect_disable(struct scp_domain *scpd)
> +{
> + struct scp *scp = scpd->scp;
> +
> + if (!scpd->data->bus_prot_mask)
> + return 0;
> +
> + return mtk_infracfg_clear_bus_protection(scp->infracfg,
> + scpd->data->bus_prot_mask,
> + scp->bus_prot_reg_update);
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> @@ -316,13 +340,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> if (ret < 0)
> goto err_pwr_ack;
>
> - if (scpd->data->bus_prot_mask) {
> - ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> - scpd->data->bus_prot_mask,
> - scp->bus_prot_reg_update);
> - if (ret)
> - goto err_pwr_ack;
> - }
> + ret = scpsys_bus_protect_disable(scpd);
> + if (ret < 0)
> + goto err_pwr_ack;
>
> return 0;
>
> @@ -344,13 +364,9 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> u32 val;
> int ret, tmp;
>
> - if (scpd->data->bus_prot_mask) {
> - ret = mtk_infracfg_set_bus_protection(scp->infracfg,
> - scpd->data->bus_prot_mask,
> - scp->bus_prot_reg_update);
> - if (ret)
> - goto out;
> - }
> + ret = scpsys_bus_protect_enable(scpd);
> + if (ret < 0)
> + goto out;
>
> ret = scpsys_sram_disable(scpd, ctl_addr);
> if (ret < 0)
>
_______________________________________________
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 6/6] pwm: atmel: implement .get_state()
From: Claudiu.Beznea @ 2019-08-28 10:26 UTC (permalink / raw)
To: uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-7-uwe@kleine-koenig.org>
On 24.08.2019 03:10, Uwe Kleine-König wrote:
> External E-Mail
>
>
> This function reads back the configured parameters from the hardware. As
> .apply rounds down (mostly) I'm rounding up in .get_state() to achieve
> that applying a state just read from hardware is a no-op.
Since this read is only at probing, at least for the moment, and, as far as
I remember, the idea w/ .get_state was to reflect in Linux the states of
PWMs that were setup before Linux takes control (e.g. PWMs setup in
bootloaders) I think it would no problem if it would be no-ops in this
scenario. In case of run-time state retrieval, pwm_get_state() should be
enough. If one would get the state previously saved w/ this .get_state API
he/she would change it, then it would apply the changes to the hardware. No
changes of PWM state would be anyway skipped from the beginning, in
pwm_apply_state() by this code:
if (state->period == pwm->state.period &&
state->duty_cycle == pwm->state.duty_cycle &&
state->polarity == pwm->state.polarity &&
state->enabled == pwm->state.enabled)
return 0;
But maybe I'm missing something.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> New in v2
>
> drivers/pwm/pwm-atmel.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index 152c2b7dd6df..f788501ab6ca 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -295,8 +295,47 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> return 0;
> }
>
> +static void atmel_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> + u32 sr, cmr;
> +
> + sr = atmel_pwm_readl(atmel_pwm, PWM_SR);
> + cmr = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, PWM_CMR);
> +
> + if (sr & (1 << pwm->hwpwm)) {
> + unsigned long rate = clk_get_rate(atmel_pwm->clk);
> + u32 cdty, cprd, pres;
There is a whitespace at the end of this line.
> + u64 tmp;
> +
> + pres = cmr & PWM_CMR_CPRE_MSK;
> +
> + cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, atmel_pwm->data->regs.period);
If this is possible, please try to keep it at 80 chars per line. In my
opinion this still looks good:
cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
atmel_pwm->data->regs.period);
> + tmp = (u64)cprd * NSEC_PER_SEC;
> + tmp <<= pres;
> + state->period = DIV64_U64_ROUND_UP(tmp, rate);
> +
> + cdty = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, atmel_pwm->data->regs.duty);
Ditto.
> + tmp = (u64)cdty * NSEC_PER_SEC;
> + tmp <<= pres;
> + state->duty_cycle = DIV64_U64_ROUND_UP(tmp, rate);
> +
> + state->enabled = true;
> + } else {
> + state->enabled = false;
> + }
> +
> + if (cmr & PWM_CMR_CPOL)
> + state->polarity = PWM_POLARITY_INVERSED;
> + else
> + state->polarity = PWM_POLARITY_NORMAL;
> +
> +}
> +
> static const struct pwm_ops atmel_pwm_ops = {
> .apply = atmel_pwm_apply,
> + .get_state = atmel_pwm_get_state,
> .owner = THIS_MODULE,
> };
Other than the minor things above,
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 4/4] aspeed/watchdog: Add access_cs0 option for alt-boot
From: Ivan Mikhaylov @ 2019-08-28 10:24 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190828102402.13155-1-i.mikhaylov@yadro.com>
The option for the ast2400/2500 to get access to CS0 at runtime.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
.../ABI/testing/sysfs-class-watchdog | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog
index 6317ade5ad19..675f9b537661 100644
--- a/Documentation/ABI/testing/sysfs-class-watchdog
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -72,3 +72,37 @@ Description:
It is a read/write file. When read, the currently assigned
pretimeout governor is returned. When written, it sets
the pretimeout governor.
+
+What: /sys/class/watchdog/watchdog1/access_cs0
+Date: August 2019
+Contact: Ivan Mikhaylov <i.mikhaylov@yadro.com>,
+ Alexander Amelkin <a.amelkin@yadro.com>
+Description:
+ It is a read/write file. This attribute exists only if the
+ system has booted from the alternate flash chip due to
+ expiration of a watchdog timer of AST2400/AST2500 when
+ alternate boot function was enabled with 'aspeed,alt-boot'
+ devicetree option for that watchdog or with an appropriate
+ h/w strapping (for WDT2 only).
+
+ At alternate flash the 'access_cs0' sysfs node provides:
+ ast2400: a way to get access to the primary SPI flash
+ chip at CS0 after booting from the alternate
+ chip at CS1.
+ ast2500: a way to restore the normal address mapping
+ from (CS0->CS1, CS1->CS0) to (CS0->CS0,
+ CS1->CS1).
+
+ Clearing the boot code selection and timeout counter also
+ resets to the initial state the chip select line mapping. When
+ the SoC is in normal mapping state (i.e. booted from CS0),
+ clearing those bits does nothing for both versions of the SoC.
+ For alternate boot mode (booted from CS1 due to wdt2
+ expiration) the behavior differs as described above.
+
+ This option can be used with wdt2 (watchdog1) only.
+
+ When read, the current status of the boot code selection is
+ shown. When written with any non-zero value, it clears
+ the boot code selection and the timeout counter, which results
+ in chipselect reset for AST2400/AST2500.
--
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 v4 3/4] watchdog/aspeed: add support for dual boot
From: Ivan Mikhaylov @ 2019-08-28 10:24 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190828102402.13155-1-i.mikhaylov@yadro.com>
Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
to clear out boot code source and re-enable access to the primary SPI flash
chip while booted via wdt2 from the alternate chip.
AST2400 datasheet says:
"In the 2nd flash booting mode, all the address mapping to CS0# would be
re-directed to CS1#. And CS0# is not accessible under this mode. To access
CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
register WDT30.bit[1]."
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
drivers/watchdog/aspeed_wdt.c | 65 ++++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index cc71861e033a..125dbd349b00 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
#define WDT_CTRL_ENABLE BIT(0)
#define WDT_TIMEOUT_STATUS 0x10
#define WDT_TIMEOUT_STATUS_BOOT_SECONDARY BIT(1)
+#define WDT_CLEAR_TIMEOUT_STATUS 0x14
+#define WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION BIT(0)
/*
* WDT_RESET_WIDTH controls the characteristics of the external pulse (if
@@ -165,6 +167,60 @@ static int aspeed_wdt_restart(struct watchdog_device *wdd,
return 0;
}
+/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
+static ssize_t access_cs0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ u32 status = readl(wdt->base + WDT_TIMEOUT_STATUS);
+
+ return sprintf(buf, "%u\n",
+ !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
+}
+
+static ssize_t access_cs0_store(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t size)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val)
+ writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
+ wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
+
+ return size;
+}
+
+/*
+ * This attribute exists only if the system has booted from the alternate
+ * flash with 'alt-boot' option.
+ *
+ * At alternate flash the 'access_cs0' sysfs node provides:
+ * ast2400: a way to get access to the primary SPI flash chip at CS0
+ * after booting from the alternate chip at CS1.
+ * ast2500: a way to restore the normal address mapping from
+ * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+ *
+ * Clearing the boot code selection and timeout counter also resets to the
+ * initial state the chip select line mapping. When the SoC is in normal
+ * mapping state (i.e. booted from CS0), clearing those bits does nothing for
+ * both versions of the SoC. For alternate boot mode (booted from CS1 due to
+ * wdt2 expiration) the behavior differs as described above.
+ *
+ * This option can be used with wdt2 (watchdog1) only.
+ */
+static DEVICE_ATTR_RW(access_cs0);
+
+static struct attribute *bswitch_attrs[] = {
+ &dev_attr_access_cs0.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(bswitch);
+
static const struct watchdog_ops aspeed_wdt_ops = {
.start = aspeed_wdt_start,
.stop = aspeed_wdt_stop,
@@ -306,9 +362,16 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
}
status = readl(wdt->base + WDT_TIMEOUT_STATUS);
- if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
+ if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
wdt->wdd.bootstatus = WDIOF_CARDRESET;
+ if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
+ of_device_is_compatible(np, "aspeed,ast2500-wdt"))
+ wdt->wdd.groups = bswitch_groups;
+ }
+
+ dev_set_drvdata(dev, wdt);
+
return devm_watchdog_register_device(dev, &wdt->wdd);
}
--
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 v4 2/4] vesnin: add secondary SPI flash chip
From: Ivan Mikhaylov @ 2019-08-28 10:24 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190828102402.13155-1-i.mikhaylov@yadro.com>
Adds secondary SPI flash chip into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 2ee26c86a32e..db4cc3df61ce 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -81,6 +81,14 @@
label = "bmc";
#include "openbmc-flash-layout.dtsi"
};
+
+ flash@1 {
+ status = "okay";
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ m25p,fast-read;
+ label = "alt";
+ };
};
&spi {
--
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 v4 0/4] add dual-boot support
From: Ivan Mikhaylov @ 2019-08-28 10:23 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
ASPEED SoCs support dual-boot feature for SPI Flash.
When strapped appropriately, the SoC starts wdt2 (/dev/watchdog1)
and if within a minute it is not disabled, it goes off and reboots
the SoC from an alternate SPI Flash chip by changing CS0 controls
to actually drive CS1 line.
When booted from alternate chip, in order to access the main chip
at CS0, the user must reset the appropriate bit in the watchdog
hardware. There is no interface that would allow to do that from
an embedded firmware startup script.
This commit implements support for that feature:
* Enable 'alt-boot' option for wdt2
* Enable secondary SPI flash chip
* Make it possible to get access to the primary SPI flash chip at CS0
after booting from the alternate chip at CS1. A sysfs interface is added
to provide an easy way for embedded firmware startup scripts to clear
the chip select bit to gain access to the primary flash chip in order
to allow for recovery of its contents.
Ivan Mikhaylov (4):
vesnin: add wdt2 section with alt-boot option
vesnin: add secondary SPI flash chip
watchdog/aspeed: add support for dual boot
aspeed/watchdog: Add access_cs0 option for alt-boot
.../ABI/testing/sysfs-class-watchdog | 34 ++++++++++
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 12 ++++
drivers/watchdog/aspeed_wdt.c | 65 ++++++++++++++++++-
3 files changed, 110 insertions(+), 1 deletion(-)
--
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 v4 1/4] vesnin: add wdt2 section with alt-boot option
From: Ivan Mikhaylov @ 2019-08-28 10:23 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190828102402.13155-1-i.mikhaylov@yadro.com>
Adds wdt2 section with 'alt-boot' option into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 0b9e29c3212e..2ee26c86a32e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -222,3 +222,7 @@
&vuart {
status = "okay";
};
+
+&wdt2 {
+ aspeed,alt-boot;
+};
--
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 v4.4 V2 24/43] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Viresh Kumar @ 2019-08-28 10:23 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190808120600.qhbhopvp4e5w33at@vireshk-i7>
On 08-08-19, 17:36, Viresh Kumar wrote:
> On 06-08-19, 13:18, Mark Rutland wrote:
> > Upstream and in v4.9, the meltdown patches came before the spectre
> > patches, and doing this in the opposite order causes context problems
> > like the above.
> >
> > Given that, I think it would be less surprising to do the meltdown
> > backport first, though I apprecaite that's more work to get these
> > patches in. :/
>
> I attempted meltdown backport in the last two days and the amount of
> extra patches to be backported is enormous. And I am not sure if
> everything is alright as well now, and things will greatly rely on
> reviews from you for it.
>
> For this series, what about just backporting for now to account for
> CSV3 ? And attempting meltdown backport separately later ?
>
> 179a56f6f9fb arm64: Take into account ID_AA64PFR0_EL1.CSV3
@Mark ?
--
viresh
_______________________________________________
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 v7 06/13] soc: mediatek: Refactor sram control
From: Matthias Brugger @ 2019-08-28 10:22 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-7-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Put sram enable and disable control in separate functions.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Applied with the following changes made to your patch:
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index ad0f6199cd0c..603262d547c3 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -236,7 +236,8 @@ static int scpsys_sram_enable(struct scp_domain *scpd, void
__iomem *ctl_addr)
u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
int tmp;
- val = readl(ctl_addr) & ~scpd->data->sram_pdn_bits;
+ val = readl(ctl_addr);
+ val &= ~scpd->data->sram_pdn_bits;
writel(val, ctl_addr);
/* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
@@ -265,7 +266,8 @@ static int scpsys_sram_disable(struct scp_domain *scpd, void
__iomem *ctl_addr)
u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
int tmp;
- val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
+ val = readl(ctl_addr);
+ vale |= scpd->data->sram_pdn_bits;
writel(val, ctl_addr);
/* Either wait until SRAM_PDN_ACK all 1 or 0 */
@@ -357,7 +359,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
goto out;
/* subsys power off */
- val = readl(ctl_addr) | PWR_ISO_BIT;
+ val = readl(ctl_addr);
+ val |= PWR_ISO_BIT;
writel(val, ctl_addr);
val &= ~PWR_RST_B_BIT;
Hope that is OK for you (and I didn't made any mistake). If you see any problem,
please let me know.
Thanks,
Matthias
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 79 +++++++++++++++++++++++++--------------
> 1 file changed, 51 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index 73e4a1a..ad0f619 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -230,12 +230,55 @@ static int scpsys_clk_enable(struct clk *clk[], int max_num)
> return ret;
> }
>
> +static int scpsys_sram_enable(struct scp_domain *scpd, void __iomem *ctl_addr)
> +{
> + u32 val;
> + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> + int tmp;
> +
> + val = readl(ctl_addr) & ~scpd->data->sram_pdn_bits;
> + writel(val, ctl_addr);
> +
> + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> + if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> + /*
> + * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> + * MT7622_POWER_DOMAIN_WB and thus just a trivial setup
> + * is applied here.
> + */
> + usleep_range(12000, 12100);
> + } else {
> + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> + int ret = readl_poll_timeout(ctl_addr, tmp,
> + (tmp & pdn_ack) == 0,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int scpsys_sram_disable(struct scp_domain *scpd, void __iomem *ctl_addr)
> +{
> + u32 val;
> + u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> + int tmp;
> +
> + val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
> + writel(val, ctl_addr);
> +
> + /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> + return readl_poll_timeout(ctl_addr, tmp,
> + (tmp & pdn_ack) == pdn_ack,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> struct scp *scp = scpd->scp;
> void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
>
> @@ -247,6 +290,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> if (ret)
> goto err_clk;
>
> + /* subsys power on */
> val = readl(ctl_addr);
> val |= PWR_ON_BIT;
> writel(val, ctl_addr);
> @@ -268,24 +312,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> val |= PWR_RST_B_BIT;
> writel(val, ctl_addr);
>
> - val &= ~scpd->data->sram_pdn_bits;
> - writel(val, ctl_addr);
> -
> - /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> - if (MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) {
> - /*
> - * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for
> - * MT7622_POWER_DOMAIN_WB and thus just a trivial setup is
> - * applied here.
> - */
> - usleep_range(12000, 12100);
> -
> - } else {
> - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> - if (ret < 0)
> - goto err_pwr_ack;
> - }
> + ret = scpsys_sram_enable(scpd, ctl_addr);
> + if (ret < 0)
> + goto err_pwr_ack;
>
> if (scpd->data->bus_prot_mask) {
> ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> @@ -312,7 +341,6 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> struct scp *scp = scpd->scp;
> void __iomem *ctl_addr = scp->base + scpd->data->ctl_offs;
> - u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
>
> @@ -324,17 +352,12 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> goto out;
> }
>
> - val = readl(ctl_addr);
> - val |= scpd->data->sram_pdn_bits;
> - writel(val, ctl_addr);
> -
> - /* wait until SRAM_PDN_ACK all 1 */
> - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == pdn_ack,
> - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> + ret = scpsys_sram_disable(scpd, ctl_addr);
> if (ret < 0)
> goto out;
>
> - val |= PWR_ISO_BIT;
> + /* subsys power off */
> + val = readl(ctl_addr) | PWR_ISO_BIT;
> writel(val, ctl_addr);
>
> val &= ~PWR_RST_B_BIT;
>
_______________________________________________
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] mtd: spi-nor: aspeed-smc: Add of_node_put()
From: Tudor.Ambarus @ 2019-08-28 10:20 UTC (permalink / raw)
To: nishkadg.linux, marek.vasut, dwmw2, computersforpeace,
miquel.raynal, richard, vigneshr, joel, andrew, linux-mtd,
linux-arm-kernel, linux-aspeed
In-Reply-To: <20190808075104.15928-1-nishkadg.linux@gmail.com>
On 08/08/2019 10:51 AM, Nishka Dasgupta wrote:
> External E-Mail
>
>
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a break from the middle of the loop, there is
> no put, thus causing a memory leak. Upon termination of the loop
> (whether by break or a natural exit), either ret will have a non-zero
> value or child will be NULL. Hence add an of_node_put() that will
> execute only when ret has a non-zero value, as calling of_node_put() on
> a possible NULL value does not cause any further issues.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
> drivers/mtd/spi-nor/aspeed-smc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git,
spi-nor/next branch.
Thanks,
ta
_______________________________________________
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] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Enric Balletbo i Serra @ 2019-08-28 10:09 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Andersson
Cc: Gwendal Grignou, kernel, Geert Uytterhoeven, Tony Lindgren,
Catalin Marinas, Linus Walleij, Thierry Reding, Miquel Raynal,
Guenter Roeck, Leonard Crestez, Will Deacon, Marek Szyprowski,
Maxime Ripard,
moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Anson Huang,
Lee Jones, Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Robert Jarzmik, SoC Team,
open list:TEGRA ARCHITECTURE SUPPORT, Simon Horman,
Fabrice Gasnier, Benson Leung, Linux ARM,
Linux Kernel Mailing List, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <CAK8P3a2h2gUhxcVgD5JhR1Uo4qUSuG5yp4RCrAxevNmyD4ZRTA@mail.gmail.com>
Hi Bjorn, Arnd,
On 27/8/19 18:12, Arnd Bergmann wrote:
> On Tue, Aug 27, 2019 at 6:08 PM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>>
>> On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
>>
>>> Recently we refactored the CrOS EC drivers moving part of the code from
>>> the MFD subsystem to the platform chrome subsystem. During this change
>>> we needed to rename some config options, so, update the defconfigs
>>> accordingly.
>>>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>>> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
>>> Tested-by: Gwendal Grignou <gwendal@chromium.org>
>>
>> Can we make the entries in the generic arm64 defconfig modules?
>
> Good idea.
>
> Actually I would prefer to have all of them as modules for consistency,
> if at all possible.
>
It is very common boot Chromebooks from an USB device, the EC needs to be
built-in in order to boot from these devices, otherwise you should use an
initramfs. I'd like to avoid forcing people to build an initramfs just to boot
from these devices if possible, in fact, my usual workflow is without initramfs,
and knowing that with the default defconfig just should boot helps a lot sometimes.
Note that, it's not the case for EC subdevices, these are already build as modules.
BTW, Lee asked if this patch should be squashed with the patches that really
renames the config options to help bisect ability, I don't have a hard opinion
as I don't usually run the config option between bisection steps, so please let
me know what do you prefer and I'll respin the patches ASAP if that's the case.
Thanks,
Enric
> Arnd
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v5.4 (#1)
From: Gregory CLEMENT @ 2019-08-28 10:09 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Andrew Lunn, linux-kernel, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Here is the first pull request for dt64 for mvebu for v5.4.
Gregory
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-5.4-1
for you to fetch changes up to c00bc38354cf81ce83b678ff13ecf01e75d0e8da:
arm64: dts: marvell: Add cpu clock node on Armada 7K/8K (2019-08-27 16:39:22 +0200)
----------------------------------------------------------------
mvebu dt64 for 5.4 (part 1)
- Add mailbox support on Armada 37xx
- Add cpu clock node needed for CPU freq on Armada 7K/8K
- Enhance CP110 COMPHY support used by PCIe, USB3 and SATA
----------------------------------------------------------------
Gregory CLEMENT (1):
arm64: dts: marvell: Add cpu clock node on Armada 7K/8K
Marek Behún (1):
arm64: dts: marvell: armada-37xx: add mailbox node
Miquel Raynal (5):
arm64: dts: marvell: Add CP110 COMPHY clocks
arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes
arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes
arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes
arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 ++++
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 37 +++++++++++++------
.../dts/marvell/armada-8040-clearfog-gt-8k.dts | 22 ++++++++---
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 43 +++++++++++++++++++---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi | 38 +++++++++++++++----
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 5 ++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 7 ++++
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 13 +++++++
8 files changed, 139 insertions(+), 33 deletions(-)
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v5.4 (#1)
From: Gregory CLEMENT @ 2019-08-28 10:07 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Andrew Lunn, linux-kernel, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Here is the first pull request for dt for mvebu for v5.4.
Gregory
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-5.4-1
for you to fetch changes up to 644763224169e9ca2e3010c24bf4b81a6be64959:
ARM: dts: kirkwood: ts219: disable the SoC's RTC (2019-08-27 17:05:24 +0200)
----------------------------------------------------------------
mvebu dt for 5.4 (part 1)
- Disable the kirkwood RTC that doesn't work on the ts219 board
----------------------------------------------------------------
Uwe Kleine-König (1):
ARM: dts: kirkwood: ts219: disable the SoC's RTC
arch/arm/boot/dts/kirkwood-ts219.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
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 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Will Deacon @ 2019-08-28 10:04 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828030305.7190-2-qiangqing.zhang@nxp.com>
On Wed, Aug 28, 2019 at 03:05:39AM +0000, Joakim Zhang wrote:
> Add i.MX8 ddr pmu user doc.
>
> ChangeLog:
> V1 -> V4:
> * new add in V4.
> V4 -> V5:
> * no change.
> V5 -> V6:
> * change the event name
> V6 -> V7:
> * no change.
> V7 -> V8:
> * improve the doc, add more details.
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> Documentation/admin-guide/perf/imx-ddr.rst | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
>
> diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
> new file mode 100644
> index 000000000000..438de3be667b
> --- /dev/null
> +++ b/Documentation/admin-guide/perf/imx-ddr.rst
> @@ -0,0 +1,51 @@
> +=====================================================
> +Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
> +=====================================================
> +
> +There are no performance counters inside the DRAM controller, so performance
> +signals are brought out to the edge of the controller where a set of 4 x 32 bit
> +counters is implemented. This is controlled by the Performance log on parameter
I don't understand what you mean by "Performance log on parameter".
> +which causes a large number of PERF signals to be generated.
> +
> +Selection of the value for each counter is done via the config registiers. There
registers
> +is one register for each counter. Counter 0 is special in that it always counts
> +“time” and when expired causes a lock on itself and the other counters and an
> +interrupt ie enable of counter 0 is a global function.
by "causes a lock on itself and the other counters" do you mean that Counter
0 counts down and, when it hits 0, all the counters stop counting?
Will
_______________________________________________
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/6] PCI: tegra: Enable PCIe C5 controller of Tegra194 in p2972-0000 platform
From: Vidya Sagar @ 2019-08-28 10:04 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, kishon, linux-tegra, robh+dt,
linux-pci, bhelgaas, digetx, jonathanh, linux-arm-kernel,
sagar.tv
In-Reply-To: <20190828091028.GB2917@ulmo>
On 8/28/2019 2:40 PM, Thierry Reding wrote:
> On Mon, Aug 26, 2019 at 01:01:37PM +0530, Vidya Sagar wrote:
>> This patch series enables Tegra194's C5 controller which owns x16 slot in
>> p2972-0000 platform. C5 controller's PERST# and CLKREQ# are not configured as
>> output and bi-directional signals by default and hence they need to be
>> configured explicitly. Also, x16 slot's 3.3V and 12V supplies are controlled
>> through GPIOs and hence they need to be enabled through regulator framework.
>> This patch series adds required infrastructural support to address both the
>> aforementioned requirements.
>> Testing done on p2972-0000 platform
>> - Able to enumerate devices connected to x16 slot (owned by C5 controller)
>> - Enumerated device's functionality verified
>> - Suspend-Resume sequence is verified with device connected to x16 slot
>>
>> Vidya Sagar (6):
>> dt-bindings: PCI: tegra: Add sideband pins configuration entries
>> arm64: tegra: Add configuration for PCIe C5 sideband signals
>> PCI: tegra: Add support to configure sideband pins
>> dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
>> arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
>> PCI: tegra: Add support to enable slot regulators
>
> Hi Vidya,
>
> when you resend with review comments addressed, can you please reorder
> the patches slightly? I think it's more natural to order them like this:
>
> dt-bindings: PCI: tegra: Add sideband pins configuration entries
> PCI: tegra: Add support to configure sideband pins
> dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
> PCI: tegra: Add support to enable slot regulators
> arm64: tegra: Add configuration for PCIe C5 sideband signals
> arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
>
> Or perhaps even like this:
>
> dt-bindings: PCI: tegra: Add sideband pins configuration entries
> dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
> PCI: tegra: Add support to configure sideband pins
> PCI: tegra: Add support to enable slot regulators
> arm64: tegra: Add configuration for PCIe C5 sideband signals
> arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
>
> That makes it more obvious that patches 1-2 need an Acked-by from Rob
> and patches 1-4 need to go through Lorenzo's tree and that I'll pick up
> patches 5-6.Sure.
I'll do that.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
t=1566986650; bh=fKSn9tEu0u/7kvehjleUQGVzZJJHx0MojZ9eQ2aJqWM=;
h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From:
Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
Content-Transfer-Encoding;
b=aSDWQiNYeJefaP3hT1F2Kc9CSOb6AJPVC1NOPnn4rLtaj7EOJb+j70r/h4+I3bKEk
N6siO4F51Zz49OC3S0601fPefcag3AJZZQEdvrpk3pIhqGZ+62QMXTeG4f7t/ETsLY
TPYf5ksG6Kb8vxeUEAY6ATiHOIhjJhbLjRn/uJ/Oat+8ZRv3VgTOtujSHpzsKf1rTz
gJZbRa8GsOlGBEvMoc7xxgRDx1/GzUqaHw8T8GqLV/JDOW9qNy44TVpHkk4Exc7g5+
bM5zCyghflgpfG+ZMzbwZEkd1b4gDyPfxYL2J+AzEjgQyVsBSU6+nXSjJg65VfzSd6
bM8cWEfkmyeMA==
Thanks,
Vidya Sagar
>
> Thierry
>
_______________________________________________
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 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Will Deacon @ 2019-08-28 9:51 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828030305.7190-1-qiangqing.zhang@nxp.com>
On Wed, Aug 28, 2019 at 03:05:36AM +0000, Joakim Zhang wrote:
> AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> writes with an ARID or AWID matching filter setting. Granularity is at
> subsystem level. Implementation does not allow filtring between masters
> within a subsystem. Filter is defined with 2 configuration parameters.
>
> --AXI_ID defines AxID matching value
> --AXI_MASKING defines which bits of AxID are meaningful for the matching
> 0：corresponding bit is masked
> 1: corresponding bit is not masked, i.e. used to do the matching
>
> When non-masked bits are matching corresponding AXI_ID bits then counter
> is incremented. This filter allows counting read or write access from a
> subsystem or multiple subsystems.
>
> Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
>
> AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
>
> Read and write AXI ID filter should write same value to DPCR1 if want to
> specify at the same time as this filter is shared between counters.
>
> e.g.
> perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
> perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
>
> NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
> it will be reverted in driver automatically. so that the user can just specify
> axi_id to monitor a specific id, rather than having to specify axi_mask.
> e.g.
> perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
>
> ChangeLog:
> V1 -> V2:
> * add error log if user specifies read/write AXI ID filter at
> the same time.
> * of_device_get_match_data() instead of of_match_device(), and
> remove the check of return value.
> V2 -> V3:
> * move the AXI ID check to event_add().
> * add support for same value of axi_id.
> V3 -> V4:
> * move the AXI ID check to event_init().
> V4 -> V5:
> * reject event group if AXI ID not consistent in event_init().
> V5 -> V6:
> * change the event name: axi-id-read->axid-read;
> axi-id-write->axid-write
> * add another helper: ddr_perf_filters_compatible()
> * drop the dev_dbg()
> V6 -> V7:
> * revert AXI_MASKING at driver.
> V7 -> V8:
> * separate axi_id to axi_mask and axi_id these two fileds.
Nit: please don't include the ChangeLog in the commit message (we don't
want to include this in the linux history). Instead stick it after the
cut.
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> drivers/perf/fsl_imx8_ddr_perf.c | 72 +++++++++++++++++++++++++++++++-
> 1 file changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
> index 0e3310dbb145..e9bf956f434d 100644
> --- a/drivers/perf/fsl_imx8_ddr_perf.c
> +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> @@ -35,6 +35,8 @@
> #define EVENT_CYCLES_COUNTER 0
> #define NUM_COUNTERS 4
>
> +#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB 16bits) + AXI_ID(LSB 16bits) */
> +
> #define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
>
> #define DDR_PERF_DEV_NAME "imx8_ddr"
> @@ -42,9 +44,22 @@
>
> static DEFINE_IDA(ddr_ida);
>
> +/* DDR Perf hardware feature */
> +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
> +
> +struct fsl_ddr_devtype_data {
> + unsigned int quirks; /* quirks needed for different DDR Perf core */
> +};
> +
> +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> +
> +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> + .quirks = DDR_CAP_AXI_ID_FILTER,
> +};
> +
> static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> - { .compatible = "fsl,imx8-ddr-pmu",},
> - { .compatible = "fsl,imx8m-ddr-pmu",},
> + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> + { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
> @@ -58,6 +73,7 @@ struct ddr_pmu {
> struct perf_event *events[NUM_COUNTERS];
> int active_events;
> enum cpuhp_state cpuhp_state;
> + const struct fsl_ddr_devtype_data *devtype_data;
> int irq;
> int id;
> };
> @@ -129,6 +145,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
> IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> + IMX8_DDR_PMU_EVENT_ATTR(axid-read, 0x41),
> + IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
> NULL,
> };
>
> @@ -138,9 +156,13 @@ static struct attribute_group ddr_perf_events_attr_group = {
> };
>
> PMU_FORMAT_ATTR(event, "config:0-7");
> +PMU_FORMAT_ATTR(axi_id, "config1:0-15");
> +PMU_FORMAT_ATTR(axi_mask, "config1:16-31");
>
> static struct attribute *ddr_perf_format_attrs[] = {
> &format_attr_event.attr,
> + &format_attr_axi_id.attr,
> + &format_attr_axi_mask.attr,
> NULL,
> };
>
> @@ -190,6 +212,26 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
> return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
> }
>
> +static bool ddr_perf_is_filtered(struct perf_event *event)
> +{
> + return event->attr.config == 0x41 || event->attr.config == 0x42;
> +}
> +
> +static u32 ddr_perf_filter_val(struct perf_event *event)
> +{
> + return event->attr.config1;
> +}
> +
> +static bool ddr_perf_filters_compatible(struct perf_event *a,
> + struct perf_event *b)
> +{
> + if (!ddr_perf_is_filtered(a))
> + return true;
> + if (!ddr_perf_is_filtered(b))
> + return true;
> + return ddr_perf_filter_val(a) == ddr_perf_filter_val(b);
> +}
> +
> static int ddr_perf_event_init(struct perf_event *event)
> {
> struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
> @@ -216,6 +258,15 @@ static int ddr_perf_event_init(struct perf_event *event)
> !is_software_event(event->group_leader))
> return -EINVAL;
>
> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> + if (!ddr_perf_filters_compatible(event, event->group_leader))
> + return -EINVAL;
> + for_each_sibling_event(sibling, event->group_leader) {
> + if (!ddr_perf_filters_compatible(event, sibling))
> + return -EINVAL;
> + }
> + }
> +
> for_each_sibling_event(sibling, event->group_leader) {
> if (sibling->pmu != event->pmu &&
> !is_software_event(sibling))
> @@ -288,6 +339,21 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> struct hw_perf_event *hwc = &event->hw;
> int counter;
> int cfg = event->attr.config;
> + int cfg1 = event->attr.config1;
> +
> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> + int i;
> +
> + for (i = 1; i < NUM_COUNTERS; i++) {
> + if (pmu->events[i] &&
> + !ddr_perf_filters_compatible(event, pmu->events[i]))
> + return -EINVAL;
> + }
> +
> + /* revert axi id masking(axi_mask) value */
> + cfg1 ^= AXI_MASKING_REVERT;
> + writel(cfg1, pmu->base + COUNTER_DPCR1);
I was about to queue this up, but then I wondered about the following
situation:
- I add a filtered event to a group (say 0x41) with a filter of 0
(which the driver inverts to 0xffff)
- I then add a non-filtered event (say 0x40) but config1 is set
to 0xffff0000
Won't the logic above result in us corrupting DPCR1 and clobbering the
filter for the first event? What am I missing?
I think you should only program DPCR1 for filtered events.
Will
_______________________________________________
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 v7 05/13] soc: mediatek: Refactor clock control
From: Matthias Brugger @ 2019-08-28 9:46 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-6-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Put clock enable and disable control in separate function.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Applied, thanks!
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 45 ++++++++++++++++++++++++---------------
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index aed540d..73e4a1a 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -207,6 +207,29 @@ static int scpsys_regulator_disable(struct scp_domain *scpd)
> return regulator_disable(scpd->supply);
> }
>
> +static void scpsys_clk_disable(struct clk *clk[], int max_num)
> +{
> + int i;
> +
> + for (i = max_num - 1; i >= 0; i--)
> + clk_disable_unprepare(clk[i]);
> +}
> +
> +static int scpsys_clk_enable(struct clk *clk[], int max_num)
> +{
> + int i, ret = 0;
> +
> + for (i = 0; i < max_num && clk[i]; i++) {
> + ret = clk_prepare_enable(clk[i]);
> + if (ret) {
> + scpsys_clk_disable(clk, i);
> + break;
> + }
> + }
> +
> + return ret;
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> @@ -215,21 +238,14 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
> - int i;
>
> ret = scpsys_regulator_enable(scpd);
> if (ret < 0)
> return ret;
>
> - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++) {
> - ret = clk_prepare_enable(scpd->clk[i]);
> - if (ret) {
> - for (--i; i >= 0; i--)
> - clk_disable_unprepare(scpd->clk[i]);
> -
> - goto err_clk;
> - }
> - }
> + ret = scpsys_clk_enable(scpd->clk, MAX_CLKS);
> + if (ret)
> + goto err_clk;
>
> val = readl(ctl_addr);
> val |= PWR_ON_BIT;
> @@ -282,10 +298,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> return 0;
>
> err_pwr_ack:
> - for (i = MAX_CLKS - 1; i >= 0; i--) {
> - if (scpd->clk[i])
> - clk_disable_unprepare(scpd->clk[i]);
> - }
> + scpsys_clk_disable(scpd->clk, MAX_CLKS);
> err_clk:
> scpsys_regulator_disable(scpd);
>
> @@ -302,7 +315,6 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
> u32 val;
> int ret, tmp;
> - int i;
>
> if (scpd->data->bus_prot_mask) {
> ret = mtk_infracfg_set_bus_protection(scp->infracfg,
> @@ -343,8 +355,7 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> if (ret < 0)
> goto out;
>
> - for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++)
> - clk_disable_unprepare(scpd->clk[i]);
> + scpsys_clk_disable(scpd->clk, MAX_CLKS);
>
> ret = scpsys_regulator_disable(scpd);
> if (ret < 0)
>
_______________________________________________
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] mmc: mediatek: enable SDIO IRQ low level trigger function
From: Yong Mao @ 2019-08-28 9:45 UTC (permalink / raw)
To: Ulf Hansson
Cc: srv_heupstream, linux-mmc, linux-kernel, yong mao, linux-mediatek,
Chaotian Jing, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1566985524-22749-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
SDIO IRQ is not defaultly triggered by low level,
but by falling edge. It needs to set related register
to enable SDIO IRQ low level trigger function.
Otherwise the SDIO IRQ may be lost in some specail condition.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 33f4b63..585f0c7 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -192,6 +192,7 @@
#define SDC_STS_CMDBUSY (0x1 << 1) /* RW */
#define SDC_STS_SWR_COMPL (0x1 << 31) /* RW */
+#define SDC_DAT1_IRQ_TRIGGER (0x1 << 19) /* RW */
/* SDC_ADV_CFG0 mask */
#define SDC_RX_ENHANCE_EN (0x1 << 20) /* RW */
@@ -1568,6 +1569,7 @@ static void msdc_init_hw(struct msdc_host *host)
/* Config SDIO device detect interrupt function */
sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ sdr_set_bits(host->base + SDC_ADV_CFG0, SDC_DAT1_IRQ_TRIGGER);
/* Configure to default data timeout */
sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
--
1.9.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 v2] mmc: mediatek: enable SDIO IRQ low level trigger function
From: Yong Mao @ 2019-08-28 9:45 UTC (permalink / raw)
To: Ulf Hansson
Cc: srv_heupstream, linux-mmc, linux-kernel, linux-mediatek,
Chaotian Jing, Matthias Brugger, linux-arm-kernel
In-Reply-To:
_______________________________________________
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 v7 04/13] soc: mediatek: Refactor regulator control
From: Matthias Brugger @ 2019-08-28 9:44 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-5-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Put regulator enable and disable control in separate functions.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Applied to v5.4-next/soc
Thanks!
> ---
> drivers/soc/mediatek/mtk-scpsys.c | 32 +++++++++++++++++++++++---------
> 1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index e97fc0e..aed540d 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -191,6 +191,22 @@ static int scpsys_domain_is_on(struct scp_domain *scpd)
> return -EINVAL;
> }
>
> +static int scpsys_regulator_enable(struct scp_domain *scpd)
> +{
> + if (!scpd->supply)
> + return 0;
> +
> + return regulator_enable(scpd->supply);
> +}
> +
> +static int scpsys_regulator_disable(struct scp_domain *scpd)
> +{
> + if (!scpd->supply)
> + return 0;
> +
> + return regulator_disable(scpd->supply);
> +}
> +
> static int scpsys_power_on(struct generic_pm_domain *genpd)
> {
> struct scp_domain *scpd = container_of(genpd, struct scp_domain, genpd);
> @@ -201,11 +217,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> int ret, tmp;
> int i;
>
> - if (scpd->supply) {
> - ret = regulator_enable(scpd->supply);
> - if (ret)
> - return ret;
> - }
> + ret = scpsys_regulator_enable(scpd);
> + if (ret < 0)
> + return ret;
>
> for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++) {
> ret = clk_prepare_enable(scpd->clk[i]);
> @@ -273,8 +287,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> clk_disable_unprepare(scpd->clk[i]);
> }
> err_clk:
> - if (scpd->supply)
> - regulator_disable(scpd->supply);
> + scpsys_regulator_disable(scpd);
>
> dev_err(scp->dev, "Failed to power on domain %s\n", genpd->name);
>
> @@ -333,8 +346,9 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
> for (i = 0; i < MAX_CLKS && scpd->clk[i]; i++)
> clk_disable_unprepare(scpd->clk[i]);
>
> - if (scpd->supply)
> - regulator_disable(scpd->supply);
> + ret = scpsys_regulator_disable(scpd);
> + if (ret < 0)
> + goto out;
>
> return 0;
>
>
_______________________________________________
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 01/11] asm-generic: add dma_zone_size
From: Nicolas Saenz Julienne @ 2019-08-28 9:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: catalin.marinas, eric, linux-riscv, frowand.list, m.szyprowski,
linux-arch, f.fainelli, will, devicetree, Arnd Bergmann,
marc.zyngier, robh+dt, linux-rpi-kernel, linux-arm-kernel, phill,
mbrugger, linux-mm, linux-kernel, iommu, wahrenst, akpm,
Robin Murphy
In-Reply-To: <027272c27398b950f207101a2c5dbc07a30a36bc.camel@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]
On Mon, 2019-08-26 at 15:46 +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote:
> > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> > > Some architectures have platform specific DMA addressing limitations.
> > > This will allow for hardware description code to provide the constraints
> > > in a generic manner, so as for arch code to properly setup it's memory
> > > zones and DMA mask.
> >
> > I know this just spreads the arm code, but I still kinda hate it.
>
> Rob's main concern was finding a way to pass the constraint from HW definition
> to arch without widening fdt's architecture specific function surface. I'd say
> it's fair to argue that having a generic mechanism makes sense as it'll now
> traverse multiple archs and subsystems.
>
> I get adding globals like this is not very appealing, yet I went with it as it
> was the easier to integrate with arm's code. Any alternative suggestions?
>
> > MAX_DMA_ADDRESS is such an oddly defined concepts. We have the mm
> > code that uses it to start allocating after the dma zones, but
> > I think that would better be done using a function returning
> > 1 << max(zone_dma_bits, 32) or so. Then we have about a handful
> > of drivers using it that all seem rather bogus, and one of which
> > I think are usable on arm64.
>
> Is it safe to assume DMA limitations will always be a power of 2? I ask as
> RPi4
> kinda isn't: ZONE_DMA is 0x3c000000 bytes big, I'm approximating the zone mask
> to 30 as [0x3c000000 0x3fffffff] isn't defined as memory so it's unlikely that
> we´ll encounter buffers there. But I don't know how it could affect mm
> initialization code.
>
> This also rules out 'zone_dma_bits' as a mechanism to pass ZONE_DMA's size
> from
> HW definition code to arch's.
Hi Christoph,
I gave it a thought and think this whole MAX_DMA_ADDRESS topic falls out of the
scope of the series. I agree it's something that we should get rid of, but
fixing it isn't going to affect the overall enhancement intended here. I'd
rather focus on how are we going to pass the DMA zone data into the arch code
and fix MAX_DMA_ADDRESS on another series.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v7 03/13] soc: mediatek: Refactor polling timeout and documentation
From: Matthias Brugger @ 2019-08-28 9:43 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-4-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Use USEC_PER_SEC to indicate the polling timeout directly.
> And add documentation of scp_domain_data.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
Queued for v5.4-next/soc
Thanks!
> drivers/soc/mediatek/mtk-scpsys.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index 503222d..e97fc0e 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -21,7 +21,7 @@
> #include <dt-bindings/power/mt8173-power.h>
>
> #define MTK_POLL_DELAY_US 10
> -#define MTK_POLL_TIMEOUT (jiffies_to_usecs(HZ))
> +#define MTK_POLL_TIMEOUT USEC_PER_SEC
>
> #define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
> #define MTK_SCPD_FWAIT_SRAM BIT(1)
> @@ -108,6 +108,17 @@ enum clk_id {
>
> #define MAX_CLKS 3
>
> +/**
> + * struct scp_domain_data - scp domain data for power on/off flow
> + * @name: The domain name.
> + * @sta_mask: The mask for power on/off status bit.
> + * @ctl_offs: The offset for main power control register.
> + * @sram_pdn_bits: The mask for sram power control bits.
> + * @sram_pdn_ack_bits: The mask for sram power control acked bits.
> + * @bus_prot_mask: The mask for single step bus protection.
> + * @clk_id: The basic clocks required by this power domain.
> + * @caps: The flag for active wake-up action.
> + */
> struct scp_domain_data {
> const char *name;
> u32 sta_mask;
>
_______________________________________________
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 v7 02/13] dt-bindings: soc: Add MT8183 power dt-bindings
From: Matthias Brugger @ 2019-08-28 9:39 UTC (permalink / raw)
To: Weiyi Lu, Nicolas Boichat, Rob Herring
Cc: James Liao, srv_heupstream, linux-kernel, Fan Chen,
linux-mediatek, Yong Wu, linux-arm-kernel
In-Reply-To: <1566983506-26598-3-git-send-email-weiyi.lu@mediatek.com>
On 28/08/2019 11:11, Weiyi Lu wrote:
> Add power dt-bindings of MT8183 and introduces "BASIC" and
> "SUBSYS" clock types in binding document.
> The "BASIC" type is compatible to the original power control with
> clock name [a-z]+[0-9]*, e.g. mm, vpu1.
> The "SUBSYS" type is used for bus protection control with clock
> name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/soc/mediatek/scpsys.txt | 14 ++++++++++++
> include/dt-bindings/power/mt8183-power.h | 26 ++++++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/power/mt8183-power.h
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> index 876693a..00eab7e 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> @@ -14,6 +14,7 @@ power/power_domain.txt. It provides the power domains defined in
> - include/dt-bindings/power/mt2701-power.h
> - include/dt-bindings/power/mt2712-power.h
> - include/dt-bindings/power/mt7622-power.h
> +- include/dt-bindings/power/mt8183-power.h
>
> Required properties:
> - compatible: Should be one of:
> @@ -25,18 +26,31 @@ Required properties:
> - "mediatek,mt7623a-scpsys": For MT7623A SoC
> - "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC
> - "mediatek,mt8173-scpsys"
> + - "mediatek,mt8183-scpsys"
> - #power-domain-cells: Must be 1
> - reg: Address range of the SCPSYS unit
> - infracfg: must contain a phandle to the infracfg controller
> - clock, clock-names: clocks according to the common clock binding.
> These are clocks which hardware needs to be
> enabled before enabling certain power domains.
> + The new clock type "BASIC" belongs to the type above.
> + As to the new clock type "SUBSYS" needs to be
> + enabled before releasing bus protection.
The new clock type won't be new in a couple of month, better reword this. E.g.:
Some SoCs have to groups of clocks. BASIC clocks need to be enabled before
enabling the corresponding power domain. SUBSYS clocks need to be enabled before
releasing the bus protection.
> Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif"
> Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio", "vdec"
> Required clocks for MT6797: "mm", "mfg", "vdec"
> Required clocks for MT7622 or MT7629: "hif_sel"
> Required clocks for MT7623A: "ethif"
> Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
> + Required clocks for MT8183: BASIC: "audio", "mfg", "mm", "cam", "isp",
> + "vpu", "vpu1", "vpu2", "vpu3"
> + SUBSYS: "mm-0", "mm-1", "mm-2", "mm-3",
> + "mm-4", "mm-5", "mm-6", "mm-7",
> + "mm-8", "mm-9", "isp-0", "isp-1",
> + "cam-0", "cam-1", "cam-2", "cam-3",
> + "cam-4", "cam-5", "cam-6", "vpu-0",
> + "vpu-1", "vpu-2", "vpu-3", "vpu-4",
> + "vpu-5"
>
> Optional properties:
> - vdec-supply: Power supply for the vdec power domain
> diff --git a/include/dt-bindings/power/mt8183-power.h b/include/dt-bindings/power/mt8183-power.h
> new file mode 100644
> index 0000000..5c0c8c7
> --- /dev/null
> +++ b/include/dt-bindings/power/mt8183-power.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Weiyi Lu <weiyi.lu@mediatek.com>
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
> +#define _DT_BINDINGS_POWER_MT8183_POWER_H
> +
> +#define MT8183_POWER_DOMAIN_AUDIO 0
> +#define MT8183_POWER_DOMAIN_CONN 1
> +#define MT8183_POWER_DOMAIN_MFG_ASYNC 2
> +#define MT8183_POWER_DOMAIN_MFG 3
> +#define MT8183_POWER_DOMAIN_MFG_CORE0 4
> +#define MT8183_POWER_DOMAIN_MFG_CORE1 5
> +#define MT8183_POWER_DOMAIN_MFG_2D 6
> +#define MT8183_POWER_DOMAIN_DISP 7
> +#define MT8183_POWER_DOMAIN_CAM 8
> +#define MT8183_POWER_DOMAIN_ISP 9
> +#define MT8183_POWER_DOMAIN_VDEC 10
> +#define MT8183_POWER_DOMAIN_VENC 11
> +#define MT8183_POWER_DOMAIN_VPU_TOP 12
> +#define MT8183_POWER_DOMAIN_VPU_CORE0 13
> +#define MT8183_POWER_DOMAIN_VPU_CORE1 14
> +
> +#endif /* _DT_BINDINGS_POWER_MT8183_POWER_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 6/6] PCI: tegra: Add support to enable slot regulators
From: Andrew Murray @ 2019-08-28 9:37 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, Vidya Sagar, linux-kernel, kishon, linux-tegra,
robh+dt, linux-pci, bhelgaas, digetx, jonathanh, linux-arm-kernel,
sagar.tv
In-Reply-To: <20190828090757.GA2917@ulmo>
On Wed, Aug 28, 2019 at 11:07:57AM +0200, Thierry Reding wrote:
> On Tue, Aug 27, 2019 at 06:13:34PM +0100, Andrew Murray wrote:
> > On Tue, Aug 27, 2019 at 09:54:17PM +0530, Vidya Sagar wrote:
> > > On 8/27/2019 9:17 PM, Andrew Murray wrote:
> > > > On Mon, Aug 26, 2019 at 01:01:43PM +0530, Vidya Sagar wrote:
> > > > > Add support to get regulator information of 3.3V and 12V supplies of a PCIe
> > > > > slot from the respective controller's device-tree node and enable those
> > > > > supplies. This is required in platforms like p2972-0000 where the supplies
> > > > > to x16 slot owned by C5 controller need to be enabled before attempting to
> > > > > enumerate the devices.
> > > > >
> > > > > Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> > > > > ---
> > > > > drivers/pci/controller/dwc/pcie-tegra194.c | 65 ++++++++++++++++++++++
> > > > > 1 file changed, 65 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > index 8a27b25893c9..97de2151a738 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
> > > > > u32 aspm_l0s_enter_lat;
> > > > > struct regulator *pex_ctl_supply;
> > > > > + struct regulator *slot_ctl_3v3;
> > > > > + struct regulator *slot_ctl_12v;
> > > > > unsigned int phy_count;
> > > > > struct phy **phys;
> > > > > @@ -1047,6 +1049,59 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
> > > > > }
> > > > > }
> > > > > +static void tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
> > > > > +{
> > > > > + pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> > > > > + if (IS_ERR(pcie->slot_ctl_3v3))
> > > > > + pcie->slot_ctl_3v3 = NULL;
> > > > > +
> > > > > + pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
> > > > > + if (IS_ERR(pcie->slot_ctl_12v))
> > > > > + pcie->slot_ctl_12v = NULL;
> > > >
> > > > Do these need to take into consideration -EPROBE_DEFER?
> > > Since these are devm_* APIs, isn't it taken care of automatically?
> >
> > devm_regulator_get_optional can still return -EPROBE_DEFER - for times when
> > "lookup could succeed in the future".
> >
> > It's probably helpful here for your driver to distinguish between there not
> > being a regulator specified in the DT, and there being a regulator but there
> > is no device for it yet. For the latter case - your driver would probe but
> > nothing would enumerate.
> >
> > See pcie-rockchip-host.c for an example of where this is handled.
> >
> > Of course if, for whatever reason it is unlikely you'll ever get -EPROBE_DEFER
> > then maybe it's OK as it is.
>
> Let's not assume that. We've just recently encountered a case where we
> did not handle -EPROBE_DEFER because we had assumed too much, and that
> turned into a bit of a hassle to fix.
>
> Vidya, I think what Andrew is saying is that you need to propagate the
> -EPROBE_DEFER error to the caller (i.e. the ->probe() callback) so that
> the PCI controller driver can be properly added to the defer queue in
> case the regulator isn't ready yet.
Indeed.
>
> I think what we want here is something like:
>
> pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> if (IS_ERR(pcie->slot_ctl_3v3)) {
> if (PTR_ERR(pcie->slot_ctl_3v3) != -ENODEV)
> return PTR_ERR(pcie->slot_ctl_3v3);
>
> pcie->slot_ctl_3v3 = NULL;
> }
>
> Andrew, I'm not sure the handling in rockchip_pcie_parse_host_dt() is
> correct. It singles out -EPROBE_DEFER, which I think is the wrong way
> around. We should be special-casing -ENODEV, because regulator_get()
> can return a wide array of error cases, not all of which we actually
> want to consider successes. For example we could be getting -ENOMEM,
> which, I would argue, is something that we should propagate.
Yes I completely agree, given that the regulator is optional: we only want
to proceed if we find the regulator or if a regulator wasn't specified in the
DT. We should fail upon any other error, in case a regulator was specified
but the error prevented it from being returned.
> I think
> it'd be very confusing to take that as meaning "optional regulator
> wasn't specified", because in that case the DTS file would've had the
> regulator hooked up (we have to assume that it is needed in that case)
> but we won't be enabling it, so it's unlikely that devices will
> enumerate.
Thanks,
Andrew Murray
>
> Thierry
_______________________________________________
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] thermal: mediatek: add suspend/resume callback
From: Zhang Rui @ 2019-08-28 9:36 UTC (permalink / raw)
To: michael.kao, Eduardo Valentin, Daniel Lezcano, Rob Herring,
Mark Rutland, Matthias Brugger, hsinyi
Cc: devicetree, linux-pm, Louis Yu, linux-kernel, linux-mediatek,
linux-arm-kernel
In-Reply-To: <1562058985-27538-1-git-send-email-michael.kao@mediatek.com>
On Tue, 2019-07-02 at 17:16 +0800, michael.kao@mediatek.com wrote:
> From: Louis Yu <louis.yu@mediatek.com>
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal
> driver
> needs re-initialization during resume.
>
> Signed-off-by: Louis Yu <louis.yu@mediatek.com>
> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
> ---
> This patch series base on these patches [1][2][3].
>
> [1]thermal: mediatek: mt8183: fix bank number settings (
> https://patchwork.kernel.org/patch/10938817/)
> [2]thermal: mediatek: add another get_temp ops for thermal sensors (
> https://patchwork.kernel.org/patch/10938829/)
> [3]thermal: mediatek: use spinlock to protect PTPCORESEL (
> https://patchwork.kernel.org/patch/10938841/)
>
all these patches are not sent to linux-pm mailing list, thus they
never got chance to get merged. please resend them to linux-pm.
I don't know what the first part of the patch set do, so I'm wondering
if there is any dependency?
thanks,
rui
> drivers/thermal/mtk_thermal.c | 134
> +++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 125 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c
> b/drivers/thermal/mtk_thermal.c
> index 3d01153..61d4114 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -30,6 +30,7 @@
> #include <linux/thermal.h>
> #include <linux/reset.h>
> #include <linux/types.h>
> +#include <linux/iopoll.h>
>
> /* AUXADC Registers */
> #define AUXADC_CON1_SET_V 0x008
> @@ -39,6 +40,8 @@
>
> #define APMIXED_SYS_TS_CON1 0x604
>
> +#define APMIXED_SYS_TS_CON1_BUFFER_OFF 0x30
> +
> /* Thermal Controller Registers */
> #define TEMP_MONCTL0 0x000
> #define TEMP_MONCTL1 0x004
> @@ -46,6 +49,7 @@
> #define TEMP_MONIDET0 0x014
> #define TEMP_MONIDET1 0x018
> #define TEMP_MSRCTL0 0x038
> +#define TEMP_MSRCTL1 0x03c
> #define TEMP_AHBPOLL 0x040
> #define TEMP_AHBTO 0x044
> #define TEMP_ADCPNP0 0x048
> @@ -95,6 +99,9 @@
> #define TEMP_ADCVALIDMASK_VALID_HIGH BIT(5)
> #define TEMP_ADCVALIDMASK_VALID_POS(bit) (bit)
>
> +#define TEMP_MSRCTL1_BUS_STA (BIT(0) | BIT(7))
> +#define TEMP_MSRCTL1_SENSING_POINTS_PAUSE 0x10E
> +
> /* MT8173 thermal sensors */
> #define MT8173_TS1 0
> #define MT8173_TS2 1
> @@ -266,6 +273,10 @@ struct mtk_thermal_data {
> struct mtk_thermal {
> struct device *dev;
> void __iomem *thermal_base;
> + void __iomem *apmixed_base;
> + void __iomem *auxadc_base;
> + u64 apmixed_phys_base;
> + u64 auxadc_phys_base;
>
> struct clk *clk_peri_therm;
> struct clk *clk_auxadc;
> @@ -795,6 +806,42 @@ static void mtk_thermal_init_bank(struct
> mtk_thermal *mt, int num,
> mtk_thermal_put_bank(bank);
> }
>
> +static int mtk_thermal_disable_sensing(struct mtk_thermal *mt, int
> num)
> +{
> + struct mtk_thermal_bank *bank = &mt->banks[num];
> + u32 val;
> + unsigned long timeout;
> + void __iomem *addr;
> + int ret = 0;
> +
> + bank->id = num;
> + bank->mt = mt;
> +
> + mtk_thermal_get_bank(bank);
> +
> + val = readl(mt->thermal_base + TEMP_MSRCTL1);
> + /* pause periodic temperature measurement for sensing points */
> + writel(val | TEMP_MSRCTL1_SENSING_POINTS_PAUSE,
> + mt->thermal_base + TEMP_MSRCTL1);
> +
> + /* wait until temperature measurement bus idle */
> + timeout = jiffies + HZ;
> + addr = mt->thermal_base + TEMP_MSRCTL1;
> +
> + ret = readl_poll_timeout(addr, val, (val &
> TEMP_MSRCTL1_BUS_STA) == 0x0,
> + 0, timeout);
> + if (ret < 0)
> + goto out;
> +
> + /* disable periodic temperature meausrement on sensing points
> */
> + writel(0x0, mt->thermal_base + TEMP_MONCTL0);
> +
> +out:
> + mtk_thermal_put_bank(bank);
> +
> + return ret;
> +}
> +
> static u64 of_get_phys_base(struct device_node *np)
> {
> u64 size64;
> @@ -917,7 +964,6 @@ static int mtk_thermal_probe(struct
> platform_device *pdev)
> struct device_node *auxadc, *apmixedsys, *np = pdev-
> >dev.of_node;
> struct mtk_thermal *mt;
> struct resource *res;
> - u64 auxadc_phys_base, apmixed_phys_base;
> struct thermal_zone_device *tzdev;
> struct mtk_thermal_zone *tz;
>
> @@ -954,11 +1000,11 @@ static int mtk_thermal_probe(struct
> platform_device *pdev)
> return -ENODEV;
> }
>
> - auxadc_phys_base = of_get_phys_base(auxadc);
> + mt->auxadc_phys_base = of_get_phys_base(auxadc);
>
> of_node_put(auxadc);
>
> - if (auxadc_phys_base == OF_BAD_ADDR) {
> + if (mt->auxadc_phys_base == OF_BAD_ADDR) {
> dev_err(&pdev->dev, "Can't get auxadc phys address\n");
> return -EINVAL;
> }
> @@ -969,11 +1015,12 @@ static int mtk_thermal_probe(struct
> platform_device *pdev)
> return -ENODEV;
> }
>
> - apmixed_phys_base = of_get_phys_base(apmixedsys);
> + mt->apmixed_phys_base = of_get_phys_base(apmixedsys);
> + mt->apmixed_base = of_iomap(apmixedsys, 0);
>
> of_node_put(apmixedsys);
>
> - if (apmixed_phys_base == OF_BAD_ADDR) {
> + if (mt->apmixed_phys_base == OF_BAD_ADDR) {
> dev_err(&pdev->dev, "Can't get auxadc phys address\n");
> return -EINVAL;
> }
> @@ -985,19 +1032,19 @@ static int mtk_thermal_probe(struct
> platform_device *pdev)
> ret = clk_prepare_enable(mt->clk_auxadc);
> if (ret) {
> dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n",
> ret);
> - return ret;
> + goto err_disable_clk_auxadc;
> }
>
> ret = clk_prepare_enable(mt->clk_peri_therm);
> if (ret) {
> dev_err(&pdev->dev, "Can't enable peri clk: %d\n",
> ret);
> - goto err_disable_clk_auxadc;
> + goto err_disable_clk_peri_therm;
> }
>
> for (ctrl_id = 0; ctrl_id < mt->conf->num_controller ;
> ctrl_id++)
> for (i = 0; i < mt->conf->num_banks; i++)
> - mtk_thermal_init_bank(mt, i, apmixed_phys_base,
> - auxadc_phys_base,
> ctrl_id);
> + mtk_thermal_init_bank(mt, i, mt-
> >apmixed_phys_base,
> + mt->auxadc_phys_base,
> ctrl_id);
>
> platform_set_drvdata(pdev, mt);
>
> @@ -1041,11 +1088,80 @@ static int mtk_thermal_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static int __maybe_unused mtk_thermal_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret;
> +
> + for (i = 0; i < mt->conf->num_banks; i++) {
> + ret = mtk_thermal_disable_sensing(mt, i);
> + if (ret)
> + goto out;
> + }
> +
> + /* disable buffer */
> + writel(readl(mt->apmixed_base + APMIXED_SYS_TS_CON1) |
> + APMIXED_SYS_TS_CON1_BUFFER_OFF,
> + mt->apmixed_base + APMIXED_SYS_TS_CON1);
> +
> + clk_disable_unprepare(mt->clk_peri_therm);
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return 0;
> +
> +out:
> + dev_err(&pdev->dev, "Failed to wait until bus idle\n");
> +
> + return ret;
> +}
> +
> +static int __maybe_unused mtk_thermal_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct mtk_thermal *mt = platform_get_drvdata(pdev);
> + int i, ret, ctrl_id;
> +
> + ret = device_reset(&pdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(mt->clk_auxadc);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable auxadc clk: %d\n",
> ret);
> + goto err_disable_clk_auxadc;
> + }
> +
> + ret = clk_prepare_enable(mt->clk_peri_therm);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't enable peri clk: %d\n",
> ret);
> + goto err_disable_clk_peri_therm;
> + }
> +
> + for (ctrl_id = 0; ctrl_id < mt->conf->num_controller ;
> ctrl_id++)
> + for (i = 0; i < mt->conf->num_banks; i++)
> + mtk_thermal_init_bank(mt, i, mt-
> >apmixed_phys_base,
> + mt->auxadc_phys_base,
> ctrl_id);
> +
> + return 0;
> +
> +err_disable_clk_peri_therm:
> + clk_disable_unprepare(mt->clk_peri_therm);
> +err_disable_clk_auxadc:
> + clk_disable_unprepare(mt->clk_auxadc);
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mtk_thermal_pm_ops,
> + mtk_thermal_suspend, mtk_thermal_resume);
> +
> static struct platform_driver mtk_thermal_driver = {
> .probe = mtk_thermal_probe,
> .remove = mtk_thermal_remove,
> .driver = {
> .name = "mtk-thermal",
> + .pm = &mtk_thermal_pm_ops,
> .of_match_table = mtk_thermal_of_match,
> },
> };
_______________________________________________
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