* Re: [PATCH v2 2/2] watchdog: aspeed: Add support for AST2600
From: Guenter Roeck @ 2019-08-20 15:50 UTC (permalink / raw)
To: Joel Stanley
Cc: devicetree, Ryan Chen, linux-watchdog, linux-aspeed,
Andrew Jeffery, Rob Herring, Wim Van Sebroeck, linux-arm-kernel
In-Reply-To: <20190819051738.17370-3-joel@jms.id.au>
On Mon, Aug 19, 2019 at 02:47:38PM +0930, Joel Stanley wrote:
> From: Ryan Chen <ryan_chen@aspeedtech.com>
>
> The ast2600 can be supported by the same code as the ast2500.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2:
> Reuse ast2500 config structure
> ---
> drivers/watchdog/aspeed_wdt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index cc71861e033a..5b64bc2e8788 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -34,6 +34,7 @@ static const struct aspeed_wdt_config ast2500_config = {
> static const struct of_device_id aspeed_wdt_of_table[] = {
> { .compatible = "aspeed,ast2400-wdt", .data = &ast2400_config },
> { .compatible = "aspeed,ast2500-wdt", .data = &ast2500_config },
> + { .compatible = "aspeed,ast2600-wdt", .data = &ast2500_config },
> { },
> };
> MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
> @@ -259,7 +260,8 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
> set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
> }
>
> - if (of_device_is_compatible(np, "aspeed,ast2500-wdt")) {
> + if ((of_device_is_compatible(np, "aspeed,ast2500-wdt")) ||
> + (of_device_is_compatible(np, "aspeed,ast2600-wdt"))) {
> u32 reg = readl(wdt->base + WDT_RESET_WIDTH);
>
> reg &= config->ext_pulse_width_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 2/4] iommu/io-pgtable-arm: Rationalise TTBRn handling
From: Will Deacon @ 2019-08-20 15:50 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <e644e0f6-4588-56eb-a6e9-7b482e3d228d@arm.com>
On Tue, Aug 20, 2019 at 03:17:19PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:19, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
> > > TTBR1 values have so far been redundant since no users implement any
> > > support for split address spaces. Crucially, though, one of the main
> > > reasons for wanting to do so is to be able to manage each half entirely
> > > independently, e.g. context-switching one set of mappings without
> > > disturbing the other. Thus it seems unlikely that tying two tables
> > > together in a single io_pgtable_cfg would ever be particularly desirable
> > > or useful.
> > >
> > > Streamline the configs to just a single conceptual TTBR value
> > > representing the allocated table. This paves the way for future users to
> > > support split address spaces by simply allocating a table and dealing
> > > with the detailed TTBRn logistics themselves.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/arm-smmu-v3.c | 2 +-
> > > drivers/iommu/arm-smmu.c | 9 ++++-----
> > > drivers/iommu/io-pgtable-arm-v7s.c | 16 +++++++---------
> > > drivers/iommu/io-pgtable-arm.c | 7 +++----
> > > drivers/iommu/ipmmu-vmsa.c | 2 +-
> > > drivers/iommu/msm_iommu.c | 4 ++--
> > > drivers/iommu/mtk_iommu.c | 4 ++--
> > > drivers/iommu/qcom_iommu.c | 3 +--
> > > include/linux/io-pgtable.h | 4 ++--
> > > 9 files changed, 23 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > > index 2a8db896d698..2e50cf49c3c4 100644
> > > --- a/drivers/iommu/arm-smmu-v3.c
> > > +++ b/drivers/iommu/arm-smmu-v3.c
> > > @@ -1722,7 +1722,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
> > > }
> > > cfg->cd.asid = (u16)asid;
> > > - cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
> > > + cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> > > cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
> > > cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair;
> > > return 0;
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index 184ca41e9de7..19030c4b5904 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> > > @@ -473,13 +473,12 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > > /* TTBRs */
> > > if (stage1) {
> > > if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_S) {
> > > - cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr[0];
> > > - cb->ttbr[1] = pgtbl_cfg->arm_v7s_cfg.ttbr[1];
> > > + cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
> > > + cb->ttbr[1] = 0;
> > > } else {
> > > - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
> > > + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> > > cb->ttbr[0] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
> > > - cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> > > - cb->ttbr[1] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
> > > + cb->ttbr[1] = FIELD_PREP(TTBRn_ASID, cfg->asid);
> >
> > Why do you continue to put the ASID in here?
>
> For the same reason we put it there before ;)
>
> Although I guess if TCR.A1 were ever to get flipped accidentally then we're
> still cool.
Hmm, but we don't do this for other drivers, so I'd be inclined to zap it
with 0 for consistency.
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 v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Rob Herring @ 2019-08-20 15:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Young,
linux-kernel@vger.kernel.org, Chen-Yu Tsai, Mauro Carvalho Chehab,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20190820095028.l74sfvipwjjla6kq@flea>
On Tue, Aug 20, 2019 at 4:50 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi Sean,
>
> On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote:
> > On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> > > From: Maxime Ripard <maxime.ripard@bootlin.com>
> > >
> > > The RC controllers have a bunch of generic properties that are needed in a
> > > device tree. Add a YAML schemas for those.
> > >
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >
> > For the series (both 1/2 and 2.2):
> >
> > Reviewed-by: Sean Young <sean@mess.org>
> >
> > How's tree should this go through?
>
> Either yours or Rob's, I guess?
Sean's because there are other changes to
Documentation/devicetree/bindings/media/sunxi-ir.txt in -next.
Rob
_______________________________________________
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 1/6] dt-bindings: watchdog: Add YAML schemas for the generic watchdog bindings
From: Guenter Roeck @ 2019-08-20 15:54 UTC (permalink / raw)
To: Maxime Ripard, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Chen-Yu Tsai, Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190819182039.24892-1-mripard@kernel.org>
On 8/19/19 11:20 AM, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The watchdogs have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
What is the target subsystem for this series ? You didn't copy the watchdog
mailing list, so I assume it won't be the watchdog subsystem.
Thanks,
Guenter
>
> ---
>
> Changes from v1:
> - New patch
> ---
> .../bindings/watchdog/watchdog.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.yaml
>
> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
> new file mode 100644
> index 000000000000..187bf6cb62bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/watchdog.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Watchdog Generic Bindings
> +
> +maintainers:
> + - Guenter Roeck <linux@roeck-us.net>
> + - Wim Van Sebroeck <wim@linux-watchdog.org>
> +
> +description: |
> + This document describes generic bindings which can be used to
> + describe watchdog devices in a device tree.
> +
> +properties:
> + $nodename:
> + pattern: "^watchdog(@.*|-[0-9a-f])?$"
> +
> + timeout-sec:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Contains the watchdog timeout in seconds.
> +
> +...
>
_______________________________________________
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 2/5] arm64: cpufeature: Add feature to detect heterogeneous systems
From: Raphael Gault @ 2019-08-20 15:55 UTC (permalink / raw)
To: Mark Rutland
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190820154955.GB43412@lakrids.cambridge.arm.com>
Hi Mark,
Thank you for your comments.
On 8/20/19 4:49 PM, Mark Rutland wrote:
> On Tue, Aug 20, 2019 at 04:23:17PM +0100, Mark Rutland wrote:
>> Hi Raphael,
>>
>> On Fri, Aug 16, 2019 at 01:59:31PM +0100, Raphael Gault wrote:
>>> This feature is required in order to enable PMU counters direct
>>> access from userspace only when the system is homogeneous.
>>> This feature checks the model of each CPU brought online and compares it
>>> to the boot CPU. If it differs then it is heterogeneous.
>>
>> It would be worth noting that this patch prevents heterogeneous CPUs
>> being brought online late if the system was uniform at boot time.
>
> Looking again, I think I'd misunderstood how
> ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU was dealt with, but we do have a
> problem in this area.
>
> [...]
>
>>
>>> + .capability = ARM64_HAS_HETEROGENEOUS_PMU,
>>> + .type = ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
>>> + .matches = has_heterogeneous_pmu,
>>> + },
>
> I had a quick chat with Will, and we concluded that we must permit late
> onlining of heterogeneous CPUs here as people are likely to rely on
> late CPU onlining on some heterogeneous systems.
>
> I think the above permits that, but that also means that we need some
> support code to fail gracefully in that case (e.g. without sending
> a SIGILL to unaware userspace code).
I understand, however, I understood that
ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU did not allow later CPU to be
heterogeneous if the capability wasn't already enabled. Thus if as you
say we need to allow the system to switch from homogeneous to
heterogeneous, then I should change the type of this capability.
> That means that we'll need the counter emulation code that you had in
> previous versions of this patch (e.g. to handle potential UNDEFs when a
> new CPU has fewer counters than the previously online CPUs).
>
> Further, I think the context switch (and event index) code needs to take
> this cap into account, and disable direct access once the system becomes
> heterogeneous.
That is a good point indeed.
Thanks,
--
Raphael Gault
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Ondřej Jirman @ 2019-08-20 15:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree, netdev,
linux-kernel, Maxime Ripard, linux-stm32, Chen-Yu Tsai,
Rob Herring, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <20190820153939.GL29991@lunn.ch>
On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > calls.
>
> Hi Ondrej
>
> What do you mean by a dummy supply? I'm just trying to make sure you
> are not breaking backwards compatibility.
I have tested it on Orange Pi PC 2, that uses only phy-supply, but not
phy-io-supply, and the kernel now prints:
[ 1.410137] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
I have also tested it on Orange Pi PC, that doesn't use external phy, and
instead of:
[ 1.081378] dwmac-sun8i 1c30000.ethernet: No regulator found
The kernel now prints:
[ 1.112752] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy not found, using dummy regulator
[ 1.112814] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
Ethernet works in both cases, so that should cover all existing combinations. :)
regards,
Ondrej
> Thanks
> Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Andrew Lunn @ 2019-08-20 15:57 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820154714.2rt4ctovil5ol3u2@core.my.home>
On Tue, Aug 20, 2019 at 05:47:14PM +0200, Ondřej Jirman wrote:
> Hi Andrew,
>
> On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> > On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > > calls.
> >
> > Hi Ondrej
> >
> > What do you mean by a dummy supply? I'm just trying to make sure you
> > are not breaking backwards compatibility.
>
> Sorry, I mean dummy regulator. See:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1874
>
> On systems that use DT (i.e. have_full_constraints() == true), when the
> regulator is not found (ENODEV, not specified in DT), regulator_get will return
> a fake dummy regulator that can be enabled/disabled, but doesn't do anything
> real.
Hi Ondrej
But we also gain a new warning:
dev_warn(dev,
"%s supply %s not found, using dummy regulator\n",
devname, id);
This regulator is clearly optional, so there should not be a warning.
Maybe you can add a new get_type, OPTIONAL_GET, which does not issue
the warning, but does give back a dummy regulator.
Thanks
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: perf_event: Add missing header needed for smp_processor_id()
From: Raphael Gault @ 2019-08-20 15:57 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, acme, Raphael Gault, mingo
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Raphael Gault <raphael.gault@arm.com>
---
arch/arm64/kernel/perf_event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 96e90e270042..24575c0a0065 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include <linux/of.h>
#include <linux/perf/arm_pmu.h>
#include <linux/platform_device.h>
+#include <linux/smp.h>
/* ARMv8 Cortex-A53 specific event types. */
#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
--
2.17.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 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Will Deacon @ 2019-08-20 15:58 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <469dc66a-2532-5f7f-cd8d-3fe13f6c279a@arm.com>
On Tue, Aug 20, 2019 at 03:51:45PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:30, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> > > Now that callers are free to use a given table for TTBR1 if they wish
> > > (all they need do is shift the provided attributes when constructing
> > > their final TCR value), the only remaining impediment is the address
> > > validation on map/unmap. The fact that the LPAE address space split is
> > > symmetric makes this easy to accommodate - by simplifying the current
> > > range checks into explicit tests that address bits above IAS are all
> > > zero, it then follows straightforwardly to add the inverse test to
> > > allow the all-ones case as well.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/io-pgtable-arm.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> > > index 09cb20671fbb..f39c50356351 100644
> > > --- a/drivers/iommu/io-pgtable-arm.c
> > > +++ b/drivers/iommu/io-pgtable-arm.c
> > > @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> > > arm_lpae_iopte *ptep = data->pgd;
> > > int ret, lvl = ARM_LPAE_START_LVL(data);
> > > arm_lpae_iopte prot;
> > > + long iaext = (long)iova >> data->iop.cfg.ias;
> > > /* If no access, then nothing to do */
> > > if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> > > return 0;
> > > - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
> > > - paddr >= (1ULL << data->iop.cfg.oas)))
> > > + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
> >
> > I had to read that '&&' twice, but I see what you're doing now :)
> >
> > > return -ERANGE;
> >
> > This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0
> > addresses from being mapped in the same TTBR. Perhaps we need a quirk for
> > TTBR1, which could then take care of setting EPDx appropriately?
>
> Right, that's the one downside of going for the minimalist "io-pgtable
> doesn't even have to know" approach. On reflection, though, in that paradigm
> it should probably be the caller's responsibility to convert TTBR1 addresses
> to preserve the "as if TTBR0" illusion anyway :/
Right, and I'd rather not push stuff into the caller for the common case.
It's not exactly onerous to support this in io-pgtable. It's also why I'd
still like to keep the EPDx in there, because the callers that care can
rewrite the stuff, but at least we provided a default.
> The advantage of not having a quirk is that it allows split address spaces
> to fit more closely with the aux_domain idea, i.e. we could allocate and
> initialise a domain without having to assume, or even care, whether it will
> end up attached as a primary or aux domain. It *might* even be potentially
> useful to have a domain attached to TTBR0 of one device's context and TTBR1
> of another's at the same time, although that's pretty niche.
That sounds pretty theoretical to me at the moment.
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 v3 2/5] arm64: cpufeature: Add feature to detect heterogeneous systems
From: Mark Rutland @ 2019-08-20 16:03 UTC (permalink / raw)
To: Raphael Gault
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <8cf12008-cc86-3872-7358-2e837cf2498a@arm.com>
On Tue, Aug 20, 2019 at 04:55:24PM +0100, Raphael Gault wrote:
> Hi Mark,
>
> Thank you for your comments.
>
> On 8/20/19 4:49 PM, Mark Rutland wrote:
> > On Tue, Aug 20, 2019 at 04:23:17PM +0100, Mark Rutland wrote:
> > > Hi Raphael,
> > >
> > > On Fri, Aug 16, 2019 at 01:59:31PM +0100, Raphael Gault wrote:
> > > > This feature is required in order to enable PMU counters direct
> > > > access from userspace only when the system is homogeneous.
> > > > This feature checks the model of each CPU brought online and compares it
> > > > to the boot CPU. If it differs then it is heterogeneous.
> > >
> > > It would be worth noting that this patch prevents heterogeneous CPUs
> > > being brought online late if the system was uniform at boot time.
> >
> > Looking again, I think I'd misunderstood how
> > ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU was dealt with, but we do have a
> > problem in this area.
> >
> > [...]
> >
> > >
> > > > + .capability = ARM64_HAS_HETEROGENEOUS_PMU,
> > > > + .type = ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
> > > > + .matches = has_heterogeneous_pmu,
> > > > + },
> >
> > I had a quick chat with Will, and we concluded that we must permit late
> > onlining of heterogeneous CPUs here as people are likely to rely on
> > late CPU onlining on some heterogeneous systems.
> >
> > I think the above permits that, but that also means that we need some
> > support code to fail gracefully in that case (e.g. without sending
> > a SIGILL to unaware userspace code).
>
> I understand, however, I understood that ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU
> did not allow later CPU to be heterogeneous if the capability wasn't already
> enabled.
Yes, I think that you're right. IIUC the absence of
ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU is what prevents that from
happening.
> Thus if as you say we need to allow the system to switch from
> homogeneous to heterogeneous, then I should change the type of this
> capability.
I'm afraid so!
I believe we need both ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU and
ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU, so I guess we should be using
ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.
Does that sound right to you? ... or have I confused myself again?
Thanks,
Mark.
> > That means that we'll need the counter emulation code that you had in
> > previous versions of this patch (e.g. to handle potential UNDEFs when a
> > new CPU has fewer counters than the previously online CPUs).
> >
> > Further, I think the context switch (and event index) code needs to take
> > this cap into account, and disable direct access once the system becomes
> > heterogeneous.
>
> That is a good point indeed.
>
> Thanks,
>
> --
> Raphael Gault
_______________________________________________
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: perf_event: Add missing header needed for smp_processor_id()
From: Mark Rutland @ 2019-08-20 16:06 UTC (permalink / raw)
To: Raphael Gault
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190820155745.20593-1-raphael.gault@arm.com>
On Tue, Aug 20, 2019 at 04:57:45PM +0100, Raphael Gault wrote:
It would be worth having a body for the commit message like:
| in perf_event.c we use smp_processor_id(), but we haven't included
| <linux/smp.h> where it is defined, and rely on this being pulled in
| via a transitive include. Let's make this more robust by including
| <linux.smp.h> explciitly.
... and with that, my Acked-by stands.
Thanks,
Mark.
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> ---
> arch/arm64/kernel/perf_event.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 96e90e270042..24575c0a0065 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -19,6 +19,7 @@
> #include <linux/of.h>
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
> +#include <linux/smp.h>
>
> /* ARMv8 Cortex-A53 specific event types. */
> #define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> --
> 2.17.1
>
_______________________________________________
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] dt-bindings: arm: Convert Actions Semi bindings to jsonschema
From: Manivannan Sadhasivam @ 2019-08-20 16:06 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, Rob Herring, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree
In-Reply-To: <CAL_JsqJoQDkqZO_4XdaQymVW0cJDXVmAPh3uieRkBjoUXeWE1w@mail.gmail.com>
On Fri, Jun 14, 2019 at 01:33:47PM -0600, Rob Herring wrote:
> On Fri, Jun 14, 2019 at 11:07 AM Andreas Färber <afaerber@suse.de> wrote:
> >
> > Am 14.06.19 um 19:04 schrieb Manivannan Sadhasivam:
> > > On Thu, Jun 13, 2019 at 04:44:35PM -0600, Rob Herring wrote:
> > >> On Fri, May 17, 2019 at 10:32:23AM -0500, Rob Herring wrote:
> > >>> Convert Actions Semi SoC bindings to DT schema format using json-schema.
> > >>>
> > >>> Cc: "Andreas Färber" <afaerber@suse.de>
> > >>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >>> Cc: Mark Rutland <mark.rutland@arm.com>
> > >>> Cc: linux-arm-kernel@lists.infradead.org
> > >>> Cc: devicetree@vger.kernel.org
> > >>> Signed-off-by: Rob Herring <robh@kernel.org>
> > >>> ---
> > >>> v3:
> > >>> - update MAINTAINERS
> > >>>
> > >>> .../devicetree/bindings/arm/actions.txt | 56 -------------------
> > >>> .../devicetree/bindings/arm/actions.yaml | 38 +++++++++++++
> > >>> MAINTAINERS | 2 +-
> > >>> 3 files changed, 39 insertions(+), 57 deletions(-)
> > >>> delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt
> > >>> create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml
> > >>
> > >> Ping. Please apply or modify this how you'd prefer. I'm not going to
> > >> keep respinning this.
> > >>
> > >
> > > Sorry for that Rob.
> >
> > Well, it was simply not clear whether we were supposed to or not. :)
>
> I thought 'To' you and a single patch should be clear enough.
>
> > > Andreas, are you going to take this patch? Else I'll pick it up (If you
> > > want me to do the PR for next cycle)
> >
> > I had checked that all previous changes to the .txt file were by myself,
> > so I would prefer if we not license it under GPLv2-only but under the
> > same dual-license (MIT/GPLv2+) as the DTs. That modification would need
> > Rob's approval then.
>
> That's fine and dual license is preferred. Can you adjust that when
> applying. Note that the preference for schema is (GPL-2.0 OR
> BSD-2-Clause), but MIT/GPLv2+ is fine by me.
Andreas, are you going to take this patch? Else, we can ask Rob to take
this through his tree as we don't have any queued patches for v5.4 yet.
Thanks,
Mani
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Will Deacon @ 2019-08-20 16:07 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <48ca6945-de73-116a-3230-84862ca9e60b@arm.com>
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> > > Although it's conceptually nice for the io_pgtable_cfg to provide a
> > > standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> > > looks exactly like an Arm CPU, and they all have various other TCR
> > > controls which io-pgtable can't be expected to understand. Thus since
> > > there is an expectation that drivers will have to add to the given TCR
> > > value anyway, let's strip it down to just the essentials that are
> > > directly relevant to io-pgatble's inner workings - namely the address
> > > sizes, walk attributes, and where appropriate, format selection.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/arm-smmu-v3.c | 7 +------
> > > drivers/iommu/arm-smmu.c | 1 +
> > > drivers/iommu/arm-smmu.h | 2 ++
> > > drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
> > > drivers/iommu/io-pgtable-arm.c | 4 ----
> > > drivers/iommu/qcom_iommu.c | 2 +-
> > > 6 files changed, 7 insertions(+), 15 deletions(-)
> >
> > Hmm, so I'm a bit nervous about this one since I think we really should
> > be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
> > on the driver to do this worries me. See my comments on the next patch.
>
> The whole idea is that we already know we can't provide a *complete* TCR
> value (not least because anything above bit 31 is the wild west), thus
> there's really no point in io-pgtable trying to provide anything other than
> the parts it definitely controls. It makes sense to provide this partial TCR
> value "as if" for TTBR0, since that's the most common case, but ultimately
> io-pgatble doesn't know (or need to) which TTBR the caller intends to
> actually use for this table. Even if the caller *is* allocating it for
> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
> already, so it still wouldn't be in a position to make the EPD1 call either
> way.
Ok, but the driver can happily rewrite/ignore what it gets back. I suppose
an alternative would be scrapped the 'u64 tcr' and instead having a bunch
of named bitfields for the stuff we're actually providing, although I'd
still like EPDx to be in there.
> Ultimately, it's the IOMMU drivers who decide what they put in which TTBR,
> so it's the IOMMU drivers which have to take responsibility for EPD*. Sure
> you can worry about it, but you can equally worry about them them
> misprogramming the ASID or anything else...
I find the EPDx bits particularly dangerous because:
- They're easily overlooked
- Clobbering TTBR1 with 0x0 doesn't disable walks via TTBR1 as you might
reasonably expect
- If you do the above without EPD, the breakage will be subtle
and given that I don't see any real downsides to us providing a default TCR
value with EPD set appropriately, then I think we should do that. I'd be
happy to revisit the decision later on if it's getting the way of a real
use-case, but it feels like we're throwing the baby out with the bathwater
at the moment and I'd rather do this incrementally based on actual need.
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] arm64: perf_event: Add missing header needed for smp_processor_id()
From: Will Deacon @ 2019-08-20 16:11 UTC (permalink / raw)
To: Mark Rutland
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, Raphael Gault, mingo, linux-arm-kernel
In-Reply-To: <20190820160629.GD43412@lakrids.cambridge.arm.com>
On Tue, Aug 20, 2019 at 05:06:29PM +0100, Mark Rutland wrote:
> On Tue, Aug 20, 2019 at 04:57:45PM +0100, Raphael Gault wrote:
>
> It would be worth having a body for the commit message like:
>
> | in perf_event.c we use smp_processor_id(), but we haven't included
> | <linux/smp.h> where it is defined, and rely on this being pulled in
> | via a transitive include. Let's make this more robust by including
> | <linux.smp.h> explciitly.
>
> ... and with that, my Acked-by stands.
Queued for 5.4. with typo fixed above.
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 4/6] dt-bindings: arm: amlogic: add SM1 bindings
From: Rob Herring @ 2019-08-20 16:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, devicetree, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-amlogic
In-Reply-To: <20190820144052.18269-5-narmstrong@baylibre.com>
On Tue, Aug 20, 2019 at 9:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add bindings for the new Amlogic SM1 SoC Family.
>
> It a derivative of the G12A SoC Family with :
> - Cortex-A55 core instead of A53
> - more power domains
> - a neural network co-processor
> - a CSI input and image processor
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 5/6] dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
From: Rob Herring @ 2019-08-20 16:16 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, devicetree, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-amlogic
In-Reply-To: <20190820144052.18269-6-narmstrong@baylibre.com>
On Tue, Aug 20, 2019 at 9:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add the compatible for the Amlogic SM1 Based SEI610 board.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
From: Rob Herring @ 2019-08-20 16:18 UTC (permalink / raw)
To: Ondrej Jirman
Cc: Mark Rutland, devicetree, Alexandre Torgue, netdev,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-stm32,
Chen-Yu Tsai, Jose Abreu, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820145343.29108-2-megous@megous.com>
On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> This is already supported by the driver, but is missing from the
> bindings.
Really, the supply for the phy should be in the phy's node...
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Ondřej Jirman @ 2019-08-20 16:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree, netdev,
linux-kernel, Maxime Ripard, linux-stm32, Chen-Yu Tsai,
Rob Herring, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <20190820155744.GN29991@lunn.ch>
Hi,
On Tue, Aug 20, 2019 at 05:57:44PM +0200, Andrew Lunn wrote:
> On Tue, Aug 20, 2019 at 05:47:14PM +0200, Ondřej Jirman wrote:
> > Hi Andrew,
> >
> > On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> > > On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > > > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > > > calls.
> > >
> > > Hi Ondrej
> > >
> > > What do you mean by a dummy supply? I'm just trying to make sure you
> > > are not breaking backwards compatibility.
> >
> > Sorry, I mean dummy regulator. See:
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1874
> >
> > On systems that use DT (i.e. have_full_constraints() == true), when the
> > regulator is not found (ENODEV, not specified in DT), regulator_get will return
> > a fake dummy regulator that can be enabled/disabled, but doesn't do anything
> > real.
>
> Hi Ondrej
>
> But we also gain a new warning:
>
> dev_warn(dev,
> "%s supply %s not found, using dummy regulator\n",
> devname, id);
>
> This regulator is clearly optional, so there should not be a warning.
>
> Maybe you can add a new get_type, OPTIONAL_GET, which does not issue
> the warning, but does give back a dummy regulator.
We already had a info message. See my other e-mail with the dmesg output.
IMO, that warning is useful during development, and more informative than the
previous one.
regards,
o.
> Thanks
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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 2/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: Rob Herring @ 2019-08-20 16:20 UTC (permalink / raw)
To: Ondrej Jirman
Cc: Mark Rutland, devicetree, Alexandre Torgue, netdev,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-stm32,
Chen-Yu Tsai, Jose Abreu, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820145343.29108-3-megous@megous.com>
On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Some PHYs require separate power supply for I/O pins in some modes
> of operation. Add phy-io-supply property, to allow enabling this
> power supply.
Perhaps since this is new, such phys should have *-supply in their nodes.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
_______________________________________________
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 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Sean Young @ 2019-08-20 16:22 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel@vger.kernel.org,
Maxime Ripard, Chen-Yu Tsai, Mauro Carvalho Chehab, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <CAL_JsqJaH5wWCHScNZwN4jxqY5Q_UDZLnq+fghecBgYY752Lnw@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:52:29AM -0500, Rob Herring wrote:
> On Tue, Aug 20, 2019 at 4:50 AM Maxime Ripard <mripard@kernel.org> wrote:
> > On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote:
> > > On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> > > > From: Maxime Ripard <maxime.ripard@bootlin.com>
> > > >
> > > > The RC controllers have a bunch of generic properties that are needed in a
> > > > device tree. Add a YAML schemas for those.
> > > >
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> > >
> > > For the series (both 1/2 and 2.2):
> > >
> > > Reviewed-by: Sean Young <sean@mess.org>
> > >
> > > How's tree should this go through?
> >
> > Either yours or Rob's, I guess?
>
> Sean's because there are other changes to
> Documentation/devicetree/bindings/media/sunxi-ir.txt in -next.
Good point, I'll take them.
Thanks
Sean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Jordan Crouse @ 2019-08-20 16:23 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, Will Deacon, iommu, linux-arm-kernel
In-Reply-To: <48ca6945-de73-116a-3230-84862ca9e60b@arm.com>
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> >On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> >>Although it's conceptually nice for the io_pgtable_cfg to provide a
> >>standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> >>looks exactly like an Arm CPU, and they all have various other TCR
> >>controls which io-pgtable can't be expected to understand. Thus since
> >>there is an expectation that drivers will have to add to the given TCR
> >>value anyway, let's strip it down to just the essentials that are
> >>directly relevant to io-pgatble's inner workings - namely the address
> >>sizes, walk attributes, and where appropriate, format selection.
> >>
> >>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>---
> >> drivers/iommu/arm-smmu-v3.c | 7 +------
> >> drivers/iommu/arm-smmu.c | 1 +
> >> drivers/iommu/arm-smmu.h | 2 ++
> >> drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
> >> drivers/iommu/io-pgtable-arm.c | 4 ----
> >> drivers/iommu/qcom_iommu.c | 2 +-
> >> 6 files changed, 7 insertions(+), 15 deletions(-)
> >
> >Hmm, so I'm a bit nervous about this one since I think we really should
> >be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
> >on the driver to do this worries me. See my comments on the next patch.
>
> The whole idea is that we already know we can't provide a *complete* TCR
> value (not least because anything above bit 31 is the wild west), thus
> there's really no point in io-pgtable trying to provide anything other than
> the parts it definitely controls. It makes sense to provide this partial TCR
> value "as if" for TTBR0, since that's the most common case, but ultimately
> io-pgatble doesn't know (or need to) which TTBR the caller intends to
> actually use for this table. Even if the caller *is* allocating it for
> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
> already, so it still wouldn't be in a position to make the EPD1 call either
> way.
>
> Ultimately, it's the IOMMU drivers who decide what they put in which TTBR,
> so it's the IOMMU drivers which have to take responsibility for EPD*. Sure
> you can worry about it, but you can equally worry about them them
> misprogramming the ASID or anything else...
I agree. If the driver *does* want to use TTBR1 then it gets a bit uglier to
realize that the io-pgtable set the bit and mask it off. To me it is a lot
clearer if this is done explicitly in the driver especially if the driver is
where we are making the choice to use either ttbr0 or ttbr1.
It would probably be easier to see in actual code, and I'll have a patch
shortly on top of this series.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] ASoC: mchp-i2s-mcc: Several fixes
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
This pathset fixes some issues detected while testing some more the
Microchip I2S multichannel controller. The first two patches fix some
issues that appear mostly when hw_free() and hw_params() callbacks
are called multiple times. The third patch fixes a problem caused
when the controller is in master mode and both capture and playback
are played at the same time.
All three patches have a "Fixes" tag. Although they are independent,
some conflicts might appear if they are not applied in the order
presented in this patchset. If so, please let me know so I can rebase
them.
Codrin Ciubotariu (3):
ASoC: mchp-i2s-mcc: Wait for RX/TX RDY only if controller is running
ASoC: mchp-i2s-mcc: Fix unprepare of GCLK
ASoC: mchp-i2s-mcc: Fix simultaneous capture and playback in master
mode
sound/soc/atmel/mchp-i2s-mcc.c | 111 +++++++++++++++++++--------------
1 file changed, 64 insertions(+), 47 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ASoC: mchp-i2s-mcc: Wait for RX/TX RDY only if controller is running
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
In-Reply-To: <20190820162411.24836-1-codrin.ciubotariu@microchip.com>
Since hw_free() can be called multiple times and not just after a stop
trigger command, we should check whether the RX or TX ready interrupt was
truly enabled previously. For this, we assure that the condition of the
wait event is always true, except when RX/TX interrupts are enabled.
Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
sound/soc/atmel/mchp-i2s-mcc.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/sound/soc/atmel/mchp-i2s-mcc.c b/sound/soc/atmel/mchp-i2s-mcc.c
index 86495883ca3f..8272915fa09b 100644
--- a/sound/soc/atmel/mchp-i2s-mcc.c
+++ b/sound/soc/atmel/mchp-i2s-mcc.c
@@ -686,22 +686,24 @@ static int mchp_i2s_mcc_hw_free(struct snd_pcm_substream *substream,
err = wait_event_interruptible_timeout(dev->wq_txrdy,
dev->tx_rdy,
msecs_to_jiffies(500));
+ if (err == 0) {
+ dev_warn_once(dev->dev,
+ "Timeout waiting for Tx ready\n");
+ regmap_write(dev->regmap, MCHP_I2SMCC_IDRA,
+ MCHP_I2SMCC_INT_TXRDY_MASK(dev->channels));
+ dev->tx_rdy = 1;
+ }
} else {
err = wait_event_interruptible_timeout(dev->wq_rxrdy,
dev->rx_rdy,
msecs_to_jiffies(500));
- }
-
- if (err == 0) {
- u32 idra;
-
- dev_warn_once(dev->dev, "Timeout waiting for %s\n",
- is_playback ? "Tx ready" : "Rx ready");
- if (is_playback)
- idra = MCHP_I2SMCC_INT_TXRDY_MASK(dev->channels);
- else
- idra = MCHP_I2SMCC_INT_RXRDY_MASK(dev->channels);
- regmap_write(dev->regmap, MCHP_I2SMCC_IDRA, idra);
+ if (err == 0) {
+ dev_warn_once(dev->dev,
+ "Timeout waiting for Rx ready\n");
+ regmap_write(dev->regmap, MCHP_I2SMCC_IDRA,
+ MCHP_I2SMCC_INT_RXRDY_MASK(dev->channels));
+ dev->rx_rdy = 1;
+ }
}
if (!mchp_i2s_mcc_is_running(dev)) {
@@ -809,6 +811,8 @@ static int mchp_i2s_mcc_dai_probe(struct snd_soc_dai *dai)
init_waitqueue_head(&dev->wq_txrdy);
init_waitqueue_head(&dev->wq_rxrdy);
+ dev->tx_rdy = 1;
+ dev->rx_rdy = 1;
snd_soc_dai_init_dma_data(dai, &dev->playback, &dev->capture);
--
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 2/3] ASoC: mchp-i2s-mcc: Fix unprepare of GCLK
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
In-Reply-To: <20190820162411.24836-1-codrin.ciubotariu@microchip.com>
If hw_free() gets called after hw_params(), GCLK remains prepared,
preventing further use of it. This patch fixes this by unpreparing the
clock in hw_free() or if hw_params() gets an error.
Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
sound/soc/atmel/mchp-i2s-mcc.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sound/soc/atmel/mchp-i2s-mcc.c b/sound/soc/atmel/mchp-i2s-mcc.c
index 8272915fa09b..ab7d5f98e759 100644
--- a/sound/soc/atmel/mchp-i2s-mcc.c
+++ b/sound/soc/atmel/mchp-i2s-mcc.c
@@ -670,8 +670,13 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
}
ret = regmap_write(dev->regmap, MCHP_I2SMCC_MRA, mra);
- if (ret < 0)
+ if (ret < 0) {
+ if (dev->gclk_use) {
+ clk_unprepare(dev->gclk);
+ dev->gclk_use = 0;
+ }
return ret;
+ }
return regmap_write(dev->regmap, MCHP_I2SMCC_MRB, mrb);
}
@@ -710,9 +715,13 @@ static int mchp_i2s_mcc_hw_free(struct snd_pcm_substream *substream,
regmap_write(dev->regmap, MCHP_I2SMCC_CR, MCHP_I2SMCC_CR_CKDIS);
if (dev->gclk_running) {
- clk_disable_unprepare(dev->gclk);
+ clk_disable(dev->gclk);
dev->gclk_running = 0;
}
+ if (dev->gclk_use) {
+ clk_unprepare(dev->gclk);
+ dev->gclk_use = 0;
+ }
}
return 0;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] ASoC: mchp-i2s-mcc: Fix simultaneous capture and playback in master mode
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
In-Reply-To: <20190820162411.24836-1-codrin.ciubotariu@microchip.com>
This controller supports capture and playback running at the same time,
with the limitation that both capture and playback must be configured the
same way (sample rate, sample format, number of channels, etc). For this,
we have to assure that the configuration registers look the same when
capture and playback are initiated.
This patch fixes a bug in which the controller is in master mode and the
hw_params() callback fails for the second audio stream. The fail occurs
because the divisors are calculated after comparing the configuration
registers for capture and playback. The fix consists in calculating the
divisors before comparing the configuration registers. BCLK and LRC are
then configured and started only if the controller is not already running.
Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
---
sound/soc/atmel/mchp-i2s-mcc.c | 70 ++++++++++++++++++----------------
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/sound/soc/atmel/mchp-i2s-mcc.c b/sound/soc/atmel/mchp-i2s-mcc.c
index ab7d5f98e759..befc2a3a05b0 100644
--- a/sound/soc/atmel/mchp-i2s-mcc.c
+++ b/sound/soc/atmel/mchp-i2s-mcc.c
@@ -392,11 +392,11 @@ static int mchp_i2s_mcc_clk_get_rate_diff(struct clk *clk,
}
static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
- unsigned int bclk, unsigned int *mra)
+ unsigned int bclk, unsigned int *mra,
+ unsigned long *best_rate)
{
unsigned long clk_rate;
unsigned long lcm_rate;
- unsigned long best_rate = 0;
unsigned long best_diff_rate = ~0;
unsigned int sysclk;
struct clk *best_clk = NULL;
@@ -423,7 +423,7 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
(clk_rate == bclk || clk_rate / (bclk * 2) <= GENMASK(5, 0));
clk_rate += lcm_rate) {
ret = mchp_i2s_mcc_clk_get_rate_diff(dev->gclk, clk_rate,
- &best_clk, &best_rate,
+ &best_clk, best_rate,
&best_diff_rate);
if (ret) {
dev_err(dev->dev, "gclk error for rate %lu: %d",
@@ -437,7 +437,7 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
}
ret = mchp_i2s_mcc_clk_get_rate_diff(dev->pclk, clk_rate,
- &best_clk, &best_rate,
+ &best_clk, best_rate,
&best_diff_rate);
if (ret) {
dev_err(dev->dev, "pclk error for rate %lu: %d",
@@ -459,33 +459,17 @@ static int mchp_i2s_mcc_config_divs(struct mchp_i2s_mcc_dev *dev,
dev_dbg(dev->dev, "source CLK is %s with rate %lu, diff %lu\n",
best_clk == dev->pclk ? "pclk" : "gclk",
- best_rate, best_diff_rate);
-
- /* set the rate */
- ret = clk_set_rate(best_clk, best_rate);
- if (ret) {
- dev_err(dev->dev, "unable to set rate %lu to %s: %d\n",
- best_rate, best_clk == dev->pclk ? "PCLK" : "GCLK",
- ret);
- return ret;
- }
+ *best_rate, best_diff_rate);
/* Configure divisors */
if (dev->sysclk)
- *mra |= MCHP_I2SMCC_MRA_IMCKDIV(best_rate / (2 * sysclk));
- *mra |= MCHP_I2SMCC_MRA_ISCKDIV(best_rate / (2 * bclk));
+ *mra |= MCHP_I2SMCC_MRA_IMCKDIV(*best_rate / (2 * sysclk));
+ *mra |= MCHP_I2SMCC_MRA_ISCKDIV(*best_rate / (2 * bclk));
- if (best_clk == dev->gclk) {
+ if (best_clk == dev->gclk)
*mra |= MCHP_I2SMCC_MRA_SRCCLK_GCLK;
- ret = clk_prepare(dev->gclk);
- if (ret < 0)
- dev_err(dev->dev, "unable to prepare GCLK: %d\n", ret);
- else
- dev->gclk_use = 1;
- } else {
+ else
*mra |= MCHP_I2SMCC_MRA_SRCCLK_PCLK;
- dev->gclk_use = 0;
- }
return 0;
}
@@ -502,6 +486,7 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
+ unsigned long rate = 0;
struct mchp_i2s_mcc_dev *dev = snd_soc_dai_get_drvdata(dai);
u32 mra = 0;
u32 mrb = 0;
@@ -640,6 +625,17 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
return -EINVAL;
}
+ if (set_divs) {
+ bclk_rate = frame_length * params_rate(params);
+ ret = mchp_i2s_mcc_config_divs(dev, bclk_rate, &mra,
+ &rate);
+ if (ret) {
+ dev_err(dev->dev,
+ "unable to configure the divisors: %d\n", ret);
+ return ret;
+ }
+ }
+
/*
* If we are already running, the wanted setup must be
* the same with the one that's currently ongoing
@@ -656,19 +652,27 @@ static int mchp_i2s_mcc_hw_params(struct snd_pcm_substream *substream,
return 0;
}
- /* Save the number of channels to know what interrupts to enable */
- dev->channels = channels;
-
- if (set_divs) {
- bclk_rate = frame_length * params_rate(params);
- ret = mchp_i2s_mcc_config_divs(dev, bclk_rate, &mra);
+ if (mra & MCHP_I2SMCC_MRA_SRCCLK_GCLK && !dev->gclk_use) {
+ /* set the rate */
+ ret = clk_set_rate(dev->gclk, rate);
if (ret) {
- dev_err(dev->dev, "unable to configure the divisors: %d\n",
- ret);
+ dev_err(dev->dev,
+ "unable to set rate %lu to GCLK: %d\n",
+ rate, ret);
+ return ret;
+ }
+
+ ret = clk_prepare(dev->gclk);
+ if (ret < 0) {
+ dev_err(dev->dev, "unable to prepare GCLK: %d\n", ret);
return ret;
}
+ dev->gclk_use = 1;
}
+ /* Save the number of channels to know what interrupts to enable */
+ dev->channels = channels;
+
ret = regmap_write(dev->regmap, MCHP_I2SMCC_MRA, mra);
if (ret < 0) {
if (dev->gclk_use) {
--
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
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