* 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
* Re: [PATCH v4 1/2] dt-bindings: arm: imx: add imx8mq nitrogen support
From: Dafna Hirschfeld @ 2019-08-20 16:27 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Ezequiel Garcia, Sascha Hauer,
linux-kernel@vger.kernel.org, Troy Kisky, Gary Bisson,
Sascha Hauer, kernel, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJx6pTw7Pr=7f0jkC81JF+EDkyhHrvFehSWZV=0wy+YXQ@mail.gmail.com>
On Mon, 2019-08-19 at 14:08 -0500, Rob Herring wrote:
> On Mon, Aug 19, 2019 at 12:26 PM Dafna Hirschfeld
> <dafna.hirschfeld@collabora.com> wrote:
> > From: Gary Bisson <gary.bisson@boundarydevices.com>
> >
> > The Nitrogen8M is an ARM based single board computer (SBC)
> > designed to leverage the full capabilities of NXP’s i.MX8M
> > Quad processor.
> >
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > [Dafna: porting vendor's code to mainline]
> > Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
> > ---
> > Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> Please add acks/reviewed-bys when posting new versions.
>
Hi,
Thank you for the remark, I forgot to add it. I will add it in the
next.
Regards,
Dafna Hirschfeld
> 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 2/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: Ondřej Jirman @ 2019-08-20 16:34 UTC (permalink / raw)
To: Rob Herring
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: <CAL_JsqLHeA6A_+ZgmCzC42Y6yJrEq6+D3vKn8ETh2D7LJ+1_-g@mail.gmail.com>
On Tue, Aug 20, 2019 at 11:20:22AM -0500, Rob Herring wrote:
> 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.
Yes, I just don't understand, since external ethernet phys are so common,
and they require power, how there's no fairly generic mechanism for this
already in the PHY subsystem, or somewhere?
It looks like other ethernet mac drivers also implement supplies on phys
on the EMAC nodes. Just grep phy-supply through dt-bindings/net.
Historical reasons, or am I missing something? It almost seems like I must
be missing something, since putting these properties to phy nodes
seems so obvious.
thank you and regards,
Ondrej
> >
> > 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 2/6] arm64: Introduce config for S32
From: Stefan-gabriel Mirea @ 2019-08-20 16:38 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819081457.GH5999@X250>
Hello Shawn,
On 8/19/2019 11:15 AM, Shawn Guo wrote:
> On Fri, Aug 09, 2019 at 11:29:10AM +0000, Stefan-gabriel Mirea wrote:
>> +config ARCH_S32
>> + bool "Freescale S32 SoC Family"
>
> So you still want to use 'Freescale' than 'NXP' here?
>
>> + help
>> + This enables support for the Freescale S32 family of processors.
Thanks; I will replace Freescale with NXP wherever possible in the next
version.
Regards,
Stefan
_______________________________________________
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 3/6] arm64: dts: fsl: Add device tree for S32V234-EVB
From: Stefan-gabriel Mirea @ 2019-08-20 16:38 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org, Dan Nica,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
Larisa Ileana Grigore
In-Reply-To: <20190819085816.GI5999@X250>
Hello Shawn,
Thank you for your suggestions!
On 8/19/2019 11:58 AM, Shawn Guo wrote:
> On Fri, Aug 09, 2019 at 11:29:12AM +0000, Stefan-gabriel Mirea wrote:
>> .../boot/dts/freescale/fsl-s32v234-evb.dts | 24 ++++
>
> The 'fsl-' prefix can be saved here, so that we can distinguish three
> families by starting string: imx??? for i.MX, fsl-??? for LayerScape,
> and s32??? for S32.
All right, I will remove the prefixes.
>> + model = "Freescale S32V234";
>
> The 'model' is usually used in board level DTS to describe the board.
I will delete the 'model' property from fsl-s32v234.dtsi and add a
suitable one in fsl-s32v234-evb.dts.
>> + };
>
> Please have a newline between nodes.
>
>> + cpu1: cpu@1 {
I've got it.
>> + interrupts = <0 59 1>;
>
> Please use GIC_SPI and IRQ_TYPE_xxx defines to make it more readable.
I will use GIC_SPI/GIC_PPI and IRQ_TYPE_xxx/GIC_CPU_MASK_xxx where
applicable.
>> +
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xf08>,
>> + <1 14 0xf08>,
>> + <1 11 0xf08>,
>> + <1 10 0xf08>;
>> + /* clock-frequency might be modified by u-boot, depending on the
>> + * chip version.
>> + */
>> + clock-frequency = <10000000>;
>> + };
>> +
>> + gic: interrupt-controller@7d001000 {
>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0 0x7d001000 0 0x1000>,
>> + <0 0x7d002000 0 0x2000>,
>> + <0 0x7d004000 0 0x2000>,
>> + <0 0x7d006000 0 0x2000>;
>> + interrupts = <1 9 0xf04>;
>> + };
>
> We usually put these core platform devices prior to 'soc' node.
Sure, I will move the 'timer' and 'interrupt-controller' nodes right
before 'soc'.
Regards,
Stefan
_______________________________________________
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 RFC] dt-bindings: regulator: define a mux regulator
From: Rob Herring @ 2019-08-20 16:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, devicetree, Liam Girdwood,
linux-kernel@vger.kernel.org, Mark Brown, Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820152511.15307-1-u.kleine-koenig@pengutronix.de>
On Tue, Aug 20, 2019 at 10:25 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> A mux regulator is used to provide current on one of several outputs. It
> might look as follows:
>
> ,------------.
> --<OUT0 A0 <--
> --<OUT1 A1 <--
> --<OUT2 A2 <--
> --<OUT3 |
> --<OUT4 EN <--
> --<OUT5 |
> --<OUT6 IN <--
> --<OUT7 |
> `------------'
>
> Depending on which address is encoded on the three address inputs A0, A1
> and A2 the current provided on IN is provided on one of the eight
> outputs.
>
> What is new here is that the binding makes use of a #regulator-cells
> property. This uses the approach known from other bindings (e.g. gpio)
> to allow referencing all eight outputs with phandle arguments. This
> requires an extention in of_get_regulator to use a new variant of
> of_parse_phandle_with_args that has a cell_count_default parameter that
> is used in absence of a $cell_name property. Even if we'd choose to
> update all regulator-bindings to add #regulator-cells = <0>; we still
> needed something to implement compatibility to the currently defined
> bindings.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> the obvious alternative is to add (here) eight subnodes to represent the
> eight outputs. This is IMHO less pretty, but wouldn't need to introduce
> #regulator-cells.
I'm okay with #regulator-cells approach.
>
> Apart from reg = <..> and a phandle there is (I think) nothing that
> needs to be specified in the subnodes because all properties of an
> output (apart from the address) apply to all outputs.
>
> What do you think?
>
> Best regards
> Uwe
>
> .../bindings/regulator/mux-regulator.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mux-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/mux-regulator.yaml b/Documentation/devicetree/bindings/regulator/mux-regulator.yaml
> new file mode 100644
> index 000000000000..f06dbb969090
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mux-regulator.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: GPL-2.0
(GPL-2.0-only OR BSD-2-Clause) is preferred.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mux-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MUX regulators
> +
> +properties:
> + compatible:
> + const: XXX,adb708
? I assume you will split this into a common and specific schemas. I
suppose there could be differing ways to control the mux just like all
other muxes.
> +
> + enable-gpios:
> + maxItems: 1
> +
> + address-gpios:
> + description: Array of typically three GPIO pins used to select the
> + regulator's output. The least significant address GPIO must be listed
> + first. The others follow in order of significance.
> + minItems: 1
> +
> + "#regulator-cells":
How is this not required?
> + const: 1
> +
> + regulator-name:
> + description: A string used to construct the sub regulator's names
> + $ref: "/schemas/types.yaml#/definitions/string"
> +
> + supply:
> + description: input supply
> +
> +required:
> + - compatible
> + - regulator-name
> + - supply
> +
> +
> +examples:
> + - |
> + mux-regulator {
> + compatible = "regulator-mux";
> +
> + regulator-name = "blafasel";
> +
> + supply = <&muxin_regulator>;
> +
> + enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + address-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>,
> + <&gpio2 3 GPIO_ACTIVE_HIGH>,
> + <&gpio2 4 GPIO_ACTIVE_HIGH>,
> + };
> +...
> --
> 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
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