* 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
* 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 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 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
* [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
* [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
* 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
* 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 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 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
* [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
* [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 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 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 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
* 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
* 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: Continuous SD IO causes hung task messages
From: Ulf Hansson @ 2019-08-28 10:31 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190827150614.GN13294@shell.armlinux.org.uk>
On Tue, 27 Aug 2019 at 17:06, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Aug 27, 2019 at 03:52:17PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Aug 27, 2019 at 03:36:34PM +0100, Russell King - ARM Linux admin wrote:
> > > On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> > > > On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > While dd'ing the contents of a SD card, I get hung task timeout
> > > > > messages as per below. However, the dd is making progress. Any
> > > > > ideas?
> > > > >
> > > > > Presumably, mmc_rescan doesn't get a look-in while IO is progressing
> > > > > for the card?
> > > >
> > > > Is it a regression?
> > > >
> > > > There not much of recent mmc core and mmc block changes, that I can
> > > > think of at this point.
> > >
> > > No idea - I just repaired the SD socket after the D2 line became
> > > disconnected, and decided to run that command as a test.
> > >
> > > > > ARM64 host, Macchiatobin, uSD card.
> > > >
> > > > What mmc host driver is it? mmci?
> > >
> > > sdhci-xenon.
> > >
> > > I'm just trying with one CPU online, then I'll try with two. My
> > > suspicion is that there's a problem in the ARM64 arch code where
> > > unlocking a mutex doesn't get noticed on other CPUs.
> > >
> > > Hmm, I thought I'd try bringing another CPU online, but it seems
> > > like the ARM64 CPU hotplug code is broken:
> > >
> > > [ 3552.029689] CPU1: shutdown
> > > [ 3552.031099] psci: CPU1 killed.
> > > [ 3949.835212] CPU1: failed to come online
> > > [ 3949.837753] CPU1: failed in unknown state : 0x0
> > >
> > > which means I can only take CPUs down, I can't bring them back
> > > online without rebooting.
> >
> > Okay, running on a single CPU shows no problems.
> >
> > Running on four CPUs (as originally) shows that the kworker thread
> > _never_ gets scheduled, so the warning is not false.
> >
> > With three CPUs, same problem.
> >
> > root@arm-d06300000000:~# ps aux | grep ' D '
> > root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
> > root@arm-d06300000000:~# cat /proc/34/sched
> > kworker/1:1 (34, #threads: 1)
> > -------------------------------------------------------------------
> > se.exec_start : 318689.992440
> > se.vruntime : 37750.882357
> > se.sum_exec_runtime : 9.421240
> > se.nr_migrations : 0
> > nr_switches : 1174
> > nr_voluntary_switches : 1171
> > nr_involuntary_switches : 3
> > se.load.weight : 1048576
> > se.runnable_weight : 1048576
> > se.avg.load_sum : 6
> > se.avg.runnable_load_sum : 6
> > se.avg.util_sum : 5170
> > se.avg.load_avg : 0
> > se.avg.runnable_load_avg : 0
> > se.avg.util_avg : 0
> > se.avg.last_update_time : 318689991680
> > se.avg.util_est.ewma : 10
> > se.avg.util_est.enqueued : 0
> > policy : 0
> > prio : 120
> > clock-delta : 0
> >
> > The only thing that changes there is "clock-delta". When I kill the
> > dd, I get:
> >
> > root@arm-d06300000000:~# cat /proc/34/sched
> > kworker/1:1 (34, #threads: 1)
> > -------------------------------------------------------------------
> > se.exec_start : 574025.791680
> > se.vruntime : 79996.657300
> > se.sum_exec_runtime : 10.916400
> > se.nr_migrations : 0
> > nr_switches : 1403
> > nr_voluntary_switches : 1400
> > nr_involuntary_switches : 3
> > se.load.weight : 1048576
> > se.runnable_weight : 1048576
> > se.avg.load_sum : 15
> > se.avg.runnable_load_sum : 15
> > se.avg.util_sum : 15007
> > se.avg.load_avg : 0
> > se.avg.runnable_load_avg : 0
> > se.avg.util_avg : 0
> > se.avg.last_update_time : 574025791488
> > se.avg.util_est.ewma : 10
> > se.avg.util_est.enqueued : 0
> > policy : 0
> > prio : 120
> > clock-delta : 40
> >
> > so the thread makes forward progress.
> >
> > Down to two CPUs:
> >
> > root@arm-d06300000000:~# ps aux | grep ' D '
> > root 34 0.0 0.0 0 0 ? D 15:38 0:00 [kworker/1:1+events_freezable]
> >
> > Same symptoms. dd and md5sum switch between CPU 0 and CPU1.
>
> Hmm.
>
> static blk_status_t mmc_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
> const struct blk_mq_queue_data *bd)
>
> mq->in_flight[issue_type] += 1;
> get_card = (mmc_tot_in_flight(mq) == 1);
>
> if (get_card)
> mmc_get_card(card, &mq->ctx);
>
> mmc_get_card() gets the host lock according to the card.
>
> So, if we always have requests in flight (which is probably the case
> here) we never drop the host lock, and mmc_rescan() never gets a look
> in - hence blocking the kworker.
Ahh, you are right. However, this isn't a new problem I believe.
Even if we did some re-work of the locking mechanism while converting
to blk-mq, I still think the worker could starve the mmc_rescan work
before.
In practice this shouldn't be a problem though, unless I am
overlooking something. This is because it's not until there is an I/O
error, that causes the block worker to release the host, to it makes
sense to let mmc_rescan to claim the host to check for card removal.
>
> So this is a real issue with MMC, and not down to something in the
> arch.
Yep, thanks for running the test and providing more details!
>
> I suspect the reason that single-CPU doesn't show it is because it is
> unable to keep multiple requests in flight.
Yes, most likely.
Now, how to solve this problem I need to think more about....
FYI: The long term goal has been to try to remove the big fat host
lock altogether and slowly we have moved more an more things to be
executed as a part of the block worker, which is one of the needed
steps. Like the mmc ioctls for example...
Kind regards
Uffe
_______________________________________________
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 v5 05/10] regulator: Add document for MT6358 regulator
From: Mark Brown @ 2019-08-28 10:44 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Sean Wang, Liam Girdwood,
linux-kernel, Richard Fontana, Rob Herring, linux-mediatek,
linux-arm-kernel, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-rtc
In-Reply-To: <1566531931-9772-6-git-send-email-hsin-hsiung.wang@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]
On Fri, Aug 23, 2019 at 11:45:26AM +0800, Hsin-Hsiung Wang wrote:
> + pmic {
> + compatible = "mediatek,mt6358";
> +
> + mt6358regulator: mt6358regulator {
> + compatible = "mediatek,mt6358-regulator";
This still lists the subnode compatible string which has been removed
from the binding.
[-- Attachment #1.2: signature.asc --]
[-- 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 v5 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Mark Brown @ 2019-08-28 10:45 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Sean Wang, Liam Girdwood,
linux-kernel, Richard Fontana, Rob Herring, linux-mediatek,
linux-arm-kernel, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-rtc
In-Reply-To: <1566531931-9772-8-git-send-email-hsin-hsiung.wang@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 436 bytes --]
On Fri, Aug 23, 2019 at 11:45:28AM +0800, Hsin-Hsiung Wang wrote:
> The MT6358 is a regulator found on boards based on MediaTek MT8183 and
> probably other SoCs. It is a so called pmic and connects as a slave to
> SoC using SPI, wrapped inside the pmic-wrapper.
This looks good - since there was only one small issue with the example
in the binding document I'll apply both patches, please send a followup
fixing the binding document.
[-- Attachment #1.2: signature.asc --]
[-- 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] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Alejandro González @ 2019-08-28 10:52 UTC (permalink / raw)
To: Ulf Hansson, Maxime Ripard
Cc: Greg Kroah-Hartman, Linus Walleij, linux-sunxi,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Chen-Yu Tsai, Thomas Gleixner, Linux ARM
In-Reply-To: <CAPDyKFr5opD2yBXmFRBY-9oA_3ShVv0GPFRO8Q_8TEiT+z2pQA@mail.gmail.com>
El 27/8/19 a las 15:24, Ulf Hansson escribió:> Assuming this should go stable as well? Perhaps you can find a
> relevant commit that we can put as a fixes tag as well?
>
> Kind regards
> Uffe
The most relevant commit I've found that is related to enabling DDR speeds
on H6 boards is this one: https://github.com/torvalds/linux/commit/07bafc1e3536a4e3c422dbd13341688b54f159bb .
But it doesn't address the H6 SoC specifically, so I doubted whether it would
be appropiate to mark this patch as fixing it, and opted to not do it. I don't
mind adding that tag if it's appropiate, though :-)
On the other hand, I'm not sure that I understood correctly what do you mean by
this patch going stable, but I might say the changes themselves are stable and work.
The only downside I can think of to them is that they are a kind of workaround that
reduces performance on H6 boards and/or eMMC not affected by this problem (are there
any?), unless device trees are changed.
El 27/8/19 a las 15:32, Maxime Ripard escribió:
> On Sun, Aug 25, 2019 at 05:05:58PM +0200, Alejandro González wrote:
>> Some Allwinner H6 boards have timing problems when dealing with
>> DDR-capable eMMC cards. These boards include the Pine H64 and Tanix TX6.
>>
>> These timing problems result in out of sync communication between the
>> driver and the eMMC, which renders the memory unsuable for every
>> operation but some basic commmands, like reading the status register.
>>
>> The cause of these timing problems is not yet well known, but they go
>> away by disabling DDR mode operation in the driver. Like on some H5
>> boards, it might be that the traces are not precise enough to support
>> these speeds. However, Jernej Skrabec compared the BSP driver with this
>> driver, and found that the BSP driver configures pinctrl to operate at
>> 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
>> the mainline kernel lacks any mechanism to switch voltages dynamically.
>> Finally, other possible cause might be some timing parameter that is
>> different on the H6 with respect to other SoCs.
>
> This should be a comment in the driver where this is disabled.
>
> Maxime
Thank you for your review. I'll mention that briefly in a comment in the code for
the next revision of this patch.
Regards.
_______________________________________________
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 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-28 10:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Marek Szyprowski,
Stephen Rothwell, Joerg Roedel, Russell King, Thierry Reding,
linux-xtensa, Kees Cook, Nicolin Chen, Andrew Morton,
linux-arm-kernel, Chris Zankel, Wolfram Sang, David Woodhouse,
linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim, Robin Murphy
In-Reply-To: <20190827115541.GB5921@lst.de>
Hi Christoph,
On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > Yes, this makes my driver working again
> > when CONFIG_DMA_CMA=y.
> >
> >
> > If I apply the following, my driver gets back working
> > irrespective of CONFIG_DMA_CMA.
>
> That sounds a lot like the device simply isn't 64-bit DMA capable, and
> previously always got CMA allocations under the limit it actually
> supported. I suggest that you submit this quirk to the mmc maintainers.
I tested v5.2 and my MMC host controller works with
dma_address that exceeds 32-bit physical address.
So, I believe my MMC device is 64-bit DMA capable.
I am still looking into the code
to find out what was changed.
--
Best Regards
Masahiro Yamada
_______________________________________________
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] arm64: fix fixmap copy for 16K pages and 48-bit VA
From: Anshuman Khandual @ 2019-08-28 11:00 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel
Cc: Catalin Marinas, Steve Capper, Marc Zyngier, Will Deacon,
Ard Biesheuvel
In-Reply-To: <20190827155708.34699-1-mark.rutland@arm.com>
On 08/27/2019 09:27 PM, Mark Rutland wrote:
> With 16K pages and 48-bit VAs, the PGD level of table has two entries,
> and so the fixmap shares a PGD with the kernel image. Since commit:
>
> f9040773b7bbbd9e ("arm64: move kernel image to base of vmalloc area")
>
> ... we copy the existing fixmap to the new fine-grained page tables at
> the PUD level in this case. When walking to the new PUD, we forgot to
> offset the PGD entry and always used the PGD entry at index 0, but this
> worked as the kernel image and fixmap were in the low half of the TTBR1
> address space.
>
> As of commit:
>
> 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
>
> ... the kernel image and fixmap are in the high half of the TTBR1
> address space, and hence use the PGD at index 1, but we didn't update
> the fixmap copying code to account for this.
>
> Thus, we'll erroneously try to copy the fixmap slots into a PUD under
> the PGD entry at index 0. At the point we do so this PGD entry has not
> been initialised, and thus we'll try to write a value to a small offset
> from physical address 0, causing a number of potential problems.
>
> Fix this be correctly offsetting the PGD. This is split over a few steps
> for legibility.
>
> Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
> Reported-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Steve Capper <Steve.Capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
Tested-by: Anshuman Khandual <anshuman.khandual@arm.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] arm64: kpti: ensure patched kernel text is fetched from PoU
From: James Morse @ 2019-08-28 11:12 UTC (permalink / raw)
To: Mark Rutland; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20190827171257.36023-1-mark.rutland@arm.com>
Hi Mark,
On 27/08/2019 18:12, Mark Rutland wrote:
> While the MMUs is disabled, I-cache speculation can result in
(Nit: MMU)
> instructions being fetched from the PoC. During boot we may patch
> instructions (e.g. for alternatives and jump labels), and these may be
> dirty at the PoU (and stale at the PoC).
>
> Thus, while the MMU is disabled in the KPTI pagetable fixup code we may
> load stale instructions into the I-cache, potentially leading to
> subsequent crashes when executing regions of code which have been
> modified at runtime.
>
> Similarly to commit:
>
> 8ec41987436d566f ("arm64: mm: ensure patched kernel text is fetched from PoU")
>
> ... we can invalidate the I-cache after enabling the MMU to prevent such
> issues.
> The KPTI pagetable fixup code itself should be clean to the PoC per the
> boot protocol, so no maintenance is required for this code.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
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 v3 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-08-28 11:23 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190827084407.GA6541@e113682-lin.lund.arm.com>
On 27/08/2019 09:44, Christoffer Dall wrote:
> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
>> Introduce a paravirtualization interface for KVM/arm64 based on the
>> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>>
>> This only adds the details about "Stolen Time" as the details of "Live
>> Physical Time" have not been fully agreed.
>>
>> User space can specify a reserved area of memory for the guest and
>> inform KVM to populate the memory with information on time that the host
>> kernel has stolen from the guest.
>>
>> A hypercall interface is provided for the guest to interrogate the
>> hypervisor's support for this interface and the location of the shared
>> memory structures.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
>> 1 file changed, 100 insertions(+)
>> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>>
>> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
>> new file mode 100644
>> index 000000000000..1ceb118694e7
>> --- /dev/null
>> +++ b/Documentation/virt/kvm/arm/pvtime.txt
>> @@ -0,0 +1,100 @@
>> +Paravirtualized time support for arm64
>> +======================================
>> +
>> +Arm specification DEN0057/A defined a standard for paravirtualised time
>> +support for AArch64 guests:
>> +
>> +https://developer.arm.com/docs/den0057/a
>> +
>> +KVM/arm64 implements the stolen time part of this specification by providing
>> +some hypervisor service calls to support a paravirtualized guest obtaining a
>> +view of the amount of time stolen from its execution.
>> +
>> +Two new SMCCC compatible hypercalls are defined:
>> +
>> +PV_FEATURES 0xC5000020
>> +PV_TIME_ST 0xC5000022
>> +
>> +These are only available in the SMC64/HVC64 calling convention as
>> +paravirtualized time is not available to 32 bit Arm guests. The existence of
>> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
>> +mechanism before calling it.
>> +
>> +PV_FEATURES
>> + Function ID: (uint32) : 0xC5000020
>> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>> + PV-time feature is supported by the hypervisor.
>> +
>> +PV_TIME_ST
>> + Function ID: (uint32) : 0xC5000022
>> + Return value: (int64) : IPA of the stolen time data structure for this
>> + (V)CPU. On failure:
>> + NOT_SUPPORTED (-1)
>> +
>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>> +with inner and outer write back caching attributes, in the inner shareable
>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>> +meaningfully filled by the hypervisor (see structure below).
>> +
>> +PV_TIME_ST returns the structure for the calling VCPU.
>> +
>> +Stolen Time
>> +-----------
>> +
>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>> +
>> + Field | Byte Length | Byte Offset | Description
>> + ----------- | ----------- | ----------- | --------------------------
>> + Revision | 4 | 0 | Must be 0 for version 0.1
>> + Attributes | 4 | 4 | Must be 0
>> + Stolen time | 8 | 8 | Stolen time in unsigned
>> + | | | nanoseconds indicating how
>> + | | | much time this VCPU thread
>> + | | | was involuntarily not
>> + | | | running on a physical CPU.
>> +
>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
>> +will be present within a reserved region of the normal memory given to the
>> +guest. The guest should not attempt to write into this memory. There is a
>> +structure per VCPU of the guest.
>> +
>> +User space interface
>> +====================
>> +
>> +User space can request that KVM provide the paravirtualized time interface to
>> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
>> +
>
> I feel it would be more consistent to have the details of this in
> Documentation/virt/kvm/devices/arm-pv-time.txt and refer to this
> document from here.
Fair point - I'll move this lower part of the document and add a reference.
Thanks,
Steve
>> + struct kvm_create_device pvtime_device = {
>> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
>> + .attr = 0,
>> + .flags = 0,
>> + };
>> +
>> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
>> +
>> +Creation of the device should be done after creating the vCPUs of the virtual
>> +machine.
>> +
>> +The IPA of the structures must be given to KVM. This is the base address
>> +of an array of stolen time structures (one for each VCPU). The base address
>> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
>> +multiple of PAGE_SIZE.
>> +
>> +The memory for these structures should be added to the guest in the usual
>> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
>> +
>> +For example:
>> +
>> + struct kvm_dev_arm_st_region region = {
>> + .gpa = <IPA of guest base address>,
>> + .size = <size in bytes>
>> + };
>> +
>> + struct kvm_device_attr st_base = {
>> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
>> + .attr = KVM_DEV_ARM_PV_TIME_ST,
>> + .addr = (u64)®ion
>> + };
>> +
>> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
>> --
>> 2.20.1
>>
>
> Thanks,
>
> Christoffer
>
_______________________________________________
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