* [PATCHv5 0/2] Variscite DART-6UL SoM support
From: Oliver Graute @ 2019-08-28 16:19 UTC (permalink / raw)
To: shawnguo
Cc: Mark Rutland, devicetree, narmstrong, Sascha Hauer, linux-kernel,
oliver.graute, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
Need feedback to the following patches which adds support for a DART-6UL Board
Need feedback howto document propertys and compatible the right way
Need feedback why ethernet RX is deaf
Product Page: https://www.variscite.com/product/evaluation-kits/dart-6ul-kits
Oliver Graute (2):
ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 445 +++++++++++++++++++++
arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts | 196 +++++++++
3 files changed, 642 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 3/6] PCI: tegra: Add support to configure sideband pins
From: Vidya Sagar @ 2019-08-28 16:16 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190828150739.GX14582@e119886-lin.cambridge.arm.com>
On 8/28/2019 8:37 PM, Andrew Murray wrote:
> On Wed, Aug 28, 2019 at 06:45:02PM +0530, Vidya Sagar wrote:
>> Add support to configure sideband signal pins when information is present
>> in respective controller's device-tree node.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> ---
>> V2:
>> * Addressed review comment from Andrew Murray
>> * Handled failure case of pinctrl_pm_select_default_state() cleanly
>>
>> drivers/pci/controller/dwc/pcie-tegra194.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>> index fc0dbeb31d78..057ba4f9fbcd 100644
>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>> @@ -1304,8 +1304,13 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
>> if (ret < 0) {
>> dev_err(dev, "Failed to get runtime sync for PCIe dev: %d\n",
>> ret);
>> - pm_runtime_disable(dev);
>> - return ret;
>> + goto fail_pm_get_sync;
>> + }
>> +
>> + ret = pinctrl_pm_select_default_state(pcie->dev);
>
> This patch looks OK, though you're still using pcie->dev here instead of dev.
I'll take care of this.
Thanks for the thorough review.
- Vidya Sagar
>
> Thanks,
>
> Andrew Murray
>
>> + if (ret < 0) {
>> + dev_err(dev, "Failed to configure sideband pins: %d\n", ret);
>> + goto fail_pinctrl;
>> }
>>
>> tegra_pcie_init_controller(pcie);
>> @@ -1332,7 +1337,9 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
>>
>> fail_host_init:
>> tegra_pcie_deinit_controller(pcie);
>> +fail_pinctrl:
>> pm_runtime_put_sync(dev);
>> +fail_pm_get_sync:
>> pm_runtime_disable(dev);
>> return ret;
>> }
>> --
>> 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 0/6] Fix TLB invalidation on arm64
From: Will Deacon @ 2019-08-28 16:12 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, Mark Rutland, Peter Zijlstra, Catalin Marinas,
Marc Zyngier, linux-arm-kernel
In-Reply-To: <1566947104.2uma6s0pl1.astroid@bobo.none>
Hi Nick,
On Wed, Aug 28, 2019 at 10:35:24AM +1000, Nicholas Piggin wrote:
> Will Deacon's on August 27, 2019 11:18 pm:
> > So far, so good, but the final piece of the puzzle isn't quite so rosy.
> >
> > *** Other architecture maintainers -- start here! ***
> >
> > In the case that one CPU maps a page and then sets a flag to tell another
> > CPU:
> >
> > CPU 0
> > -----
> >
> > MOV X0, <valid pte>
> > STR X0, [Xptep] // Store new PTE to page table
> > DSB ISHST
> > ISB
> > MOV X1, #1
> > STR X1, [Xflag] // Set the flag
> >
> > CPU 1
> > -----
> >
> > loop: LDAR X0, [Xflag] // Poll flag with Acquire semantics
> > CBZ X0, loop
> > LDR X1, [X2] // Translates using the new PTE
> >
> > then the final load on CPU 1 can raise a translation fault for the same
> > reasons as mentioned at the start of this description.
>
> powerpc's ptesync instruction is defined to order MMU memory accesses on
> all other CPUs. ptesync does not go out to the fabric though. How does
> it work then?
>
> Because the MMU coherency problem (at least we have) is not that the
> load will begin to "partially" execute ahead of the store, enough to
> kick off a table walk that goes ahead of the store, but not so much
> that it violates the regular CPU barriers. It's just that the loads
> from the MMU don't participate in the LSU pipeline, they don't snoop
> the store queues aren't inserted into load queues so the regular
> memory barrier instructions won't see stores from other threads cuasing
> ordering violations.
>
> In your first example, if powerpc just has a normal memory barrier
> there instead of a ptesync, it could all execute completely
> non-speculatively and in-order but still cause a fault, because the
> table walker's loads didn't see the store in the store queue.
Ah, so I think this is where our DSB comes in, as opposed to our usual
DMB. DMB provides ordering guarantees and is generally the only barrier
instruction you need for shared memory communication. DSB, on the other
hand, has additional properties such as making page-table updates visible
to the table walker and completing pending TLB invalidation.
So in practice, DSB is likely to drain the store buffer to ensure that
pending page-table writes are visible at L1, which is coherent with all
CPUs (and their page-table walkers).
> From the other side of the fabric you have no such problem. The table
> walker is cache coherent apart from the local stores, so we don't need a
> special barrier on the other side. That's why ptesync doesn't broadcast.
Curious: but do you need to do anything extra to take into account
instruction fetch on remote CPUs if you're mapping an executable page?
We added an IPI to flush_icache_range() in 3b8c9f1cdfc5 to handle this,
because our broadcast I-cache maintenance doesn't force a pipeline flush
for remote CPUs (and may even execute as a NOP on recent cores).
> I would be surprised if ARM's issue is different, but interested to
> hear if it is.
If you take the four scenarios of Map/Unmap for the UP/SMP cases:
Map+UP // Some sort of fence instruction (DSB;ISB/ptesync)
Map+SMP // Same as above
Unmap+UP // Local TLB invalidation
Unmap+SMP // Broadcast TLB invalidation
then the most interesting case is Map+SMP, where one CPU transitions a PTE
from invalid to valid and executes its DSB;ISB/PTESYNC sequence without
affecting the remote CPU. That's what I'm trying to get at in my example
below:
> > CPU 0 CPU 1
> > ----- -----
> > spin_lock(&lock); spin_lock(&lock);
> > set_fixmap(0, paddr, prot); if (mapped)
> > mapped = true; foo = *fix_to_virt(0);
> > spin_unlock(&lock); spin_unlock(&lock);
> >
> > could fault.
>
> This is kind of a different issue, or part of a wider one at least.
> Consider speculative execution more generally, any branch mispredict can
> send us off to crazy town executing instructions using nonsense register
> values. CPU0 does not have to be in the picture, or any kernel page
> table modification at all, CPU1 alone will be doing speculative loads
> wildly all over the kernel address space and trying to access pages with
> no pte.
>
> Yet we don't have to flush TLB when creating a new kernel mapping, and
> we don't get spurious kernel faults. The page table walker won't
> install negative entries, at least not "architectural" i.e., that cause
> faults and require flushing. My guess is ARM is similar, or you would
> have seen bigger problems by now?
Right, we don't allow negative (invalid) entries to be cached in the TLB,
but CPUs can effectively cache the result of a translation for a load/store
instruction whilst that instruction flows down the pipe after its virtual
address is known. /That/ caching is not restricted to valid translations.
For example, if we just take a simple message passing example where we have
two global variables: a 'mapped' flag (initialised to zero) and a pointer
(initialised to point at a page that is not yet mapped):
[please excuse the mess I've made of your assembly language]
CPU 0
// Set PTE which maps the page pointed to by pointer
stw r5, 0(r4)
ptesync
lwsync
// Set 'mapped' flag to 1
li r9, 1
stb r9, 0(r3)
CPU 1
// Poll for 'mapped' flag to be set
loop: lbz r9, 0(r3)
lwsync
cmpdi cr7, r0, 0
beq cr7, loop
// Dereference pointer
lwz r4, 0(r5)
So in this example, I think it's surprising that CPU 1's dereference of
'pointer' can fault. The way this happens on arm64 is that CPU 1 can
translate the 'pointer' dereference before the load of the 'mapped' flag has
returned its data. The walker may come back with a fault, but then if the
flag data later comes back as 1, the fault will be taken when the lwz
commits. In other words, translation table walks can occur out-of-order
with respect to the accesses they are translating for, even in the presence
of memory barriers.
In practice, I think this kind of code sequence is unusual and triggering
the problem relies on CPU 1 knowing the virtual address it's going to
dereference before it's actually mapped. However, this could conceivably
happen with the fixmap and possibly also if the page-table itself was
being written concurrently using cmpxchg(), in which case you might use
the actual pte value in the same way as the 'mapped' flag above.
But yes, adding the spurious fault handler is belt and braces, which is
why I've kept a WARN_RATELIMIT() in there if it ever triggers.
> If you have CPU0 doing a ro->rw upgrade on a kernel PTE, then it may
> be possible another CPU1 would speculatively install a ro TLB and then
> spurious fault on it when attempting to store to it. But no amount of
> barriers would help because CPU1 could have picked up that TLB any time
> in the past.
Transitioning from ro->rw requires TLB invalidation, and so that falls
into the Unmap+SMP combination which I'm not worried about because it
doesn't pose a problem for us.
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 v4.4 V2 24/43] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Mark Rutland @ 2019-08-28 16:08 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190808120600.qhbhopvp4e5w33at@vireshk-i7>
On Thu, Aug 08, 2019 at 05:36:00PM +0530, Viresh Kumar wrote:
> On 06-08-19, 13:18, Mark Rutland wrote:
> > Upstream and in v4.9, the meltdown patches came before the spectre
> > patches, and doing this in the opposite order causes context problems
> > like the above.
> >
> > Given that, I think it would be less surprising to do the meltdown
> > backport first, though I apprecaite that's more work to get these
> > patches in. :/
>
> I attempted meltdown backport in the last two days and the amount of
> extra patches to be backported is enormous. And I am not sure if
> everything is alright as well now, and things will greatly rely on
> reviews from you for it.
>
> For this series, what about just backporting for now to account for
> CSV3 ? And attempting meltdown backport separately later ?
>
> 179a56f6f9fb arm64: Take into account ID_AA64PFR0_EL1.CSV3
I don't think that buys us anything; that's still going to cause some
context problems (e.g. for commit 179a56f6f9fb itself), and still means
that the v4.4 backport differs from all the others.
If it's really not feasible to do the meltdown patches first, then I
reluctantly agree that we should just do the spectre bits alone if there
aren't major changes that have to be made to entry.S and friends as a
result.
Could you send a v3 (of just the spectre bits) with the changes
requested so far?
Thanks,
Mark.
_______________________________________________
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 RESEND v11 7/8] open: openat2(2) syscall
From: Jeff Layton @ 2019-08-28 15:55 UTC (permalink / raw)
To: sbaugh, linux-fsdevel
Cc: linux-arch, linux-ia64, linux-parisc, linux-sh, linux-api,
linux-kernel, linux-mips, linuxppc-dev, linux-alpha, sparclinux,
linux-arm-kernel
In-Reply-To: <854l2366zp.fsf@catern.com>
On Mon, 2019-08-26 at 19:50 +0000, sbaugh@catern.com wrote:
> Aleksa Sarai <cyphar@cyphar.com> writes:
> > To this end, we introduce the openat2(2) syscall. It provides all of the
> > features of openat(2) through the @how->flags argument, but also
> > also provides a new @how->resolve argument which exposes RESOLVE_* flags
> > that map to our new LOOKUP_* flags. It also eliminates the long-standing
> > ugliness of variadic-open(2) by embedding it in a struct.
>
> I don't like this usage of a structure in memory to pass arguments that
> would fit in registers. This would be quite inconvenient for me as a
> userspace developer.
>
> Others have brought up issues with this: the issue of seccomp, and the
> issue of mismatch between the userspace interface and the kernel
> interface, are the most important for me. I want to add another,
> admittedly somewhat niche, concern.
>
> This interfaces requires a program to allocate memory (even on the
> stack) just to pass arguments to the kernel which could be passed
> without allocating that memory. That makes it more difficult and less
> efficient to use this syscall in any case where memory is not so easily
> allocatable: such as early program startup or assembly, where the stack
> may be limited in size or not even available yet, or when injecting a
> syscall while ptracing.
>
> A struct-passing interface was needed for clone, since we ran out of
> registers; but we have not run out of registers yet for openat, so it
> would be nice to avoid this if we can. We can always expand later...
>
We can't really expand later like you suggest.
Suppose in a couple of years that we need to add some new argument to
openat2 that isn't just a new flag. If all these values are passed by
individual arguments, you can't add one later without adding yet another
syscall.
Using a struct for this allows this to be extended later, OTOH. You can
extend it, and add a flag that tells the kernel that it can access the
new field. No new syscall required.
--
Jeff Layton <jlayton@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 v3 2/5] arm64: Use correct ll/sc atomic constraints
From: Andrew Murray @ 2019-08-28 15:44 UTC (permalink / raw)
To: Mark Rutland
Cc: Peter Zijlstra, Catalin Marinas, Boqun Feng, Will Deacon,
Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190828152540.GA42408@lakrids.cambridge.arm.com>
On Wed, Aug 28, 2019 at 04:25:40PM +0100, Mark Rutland wrote:
> On Wed, Aug 28, 2019 at 02:01:19PM +0100, Andrew Murray wrote:
> > On Thu, Aug 22, 2019 at 04:32:23PM +0100, Mark Rutland wrote:
> > > Hi Andrew,
> > >
> > > On Mon, Aug 12, 2019 at 03:36:22PM +0100, Andrew Murray wrote:
> > > > For many of the ll/sc atomic operations we use the 'I' machine constraint
> > > > regardless to the instruction used - this may not be optimal.
> > > >
> > > > Let's add an additional parameter to the ATOMIC_xx macros that allows the
> > > > caller to specify an appropriate machine constraint.
> > > >
> > > > Let's also improve __CMPXCHG_CASE by replacing the 'K' constraint with a
> > > > caller provided constraint. Please note that whilst we would like to use
> > > > the 'K' constraint on 32 bit operations, we choose not to provide any
> > > > constraint to avoid a GCC bug which results in a build error.
> > > >
> > > > Earlier versions of GCC (no later than 8.1.0) appear to incorrectly handle
> > > > the 'K' constraint for the value 4294967295.
> > >
> > > From reading the above, it's difficult to discern what's a fix and
> > > what's an improvement, and I think we need to be more explicit about
> > > that. It would also be helpful to have the necessary context up-front.
> > >
> > > How about:
> > >
> > > | The A64 ISA accepts distinct (but overlapping) ranges of immediates for:
> > > |
> > > | * add arithmetic instructions ('I' machine constraint)
> > > | * sub arithmetic instructions ('J' machine constraint)
> > > | * 32-bit logical instructions ('K' machine constraint)
> > > | * 64-bit logical instructions ('L' machine constraint)
> > > |
> > > | ... but we currently use the 'I' constraint for many atomic operations
> > > | using sub or logical instructions, which is not always valid.
> > > |
> > > | When CONFIG_ARM64_LSE_ATOMICS is not set, this allows invalid immediates
> > > | to be passed to instructions, potentially resulting in a build failure.
> > > | When CONFIG_ARM64_LSE_ATOMICS is selected the out-of-line ll/sc atomics
> > > | always use a register as they have no visibility of the value passed by
> > > | the caller.
> > > |
> > > | This patch adds a constraint parameter to the ATOMIC_xx and
> > > | __CMPXCHG_CASE macros so that we can pass appropriate constraints for
> > > | each case, with uses updated accordingly.
> > > |
> > > | Unfortunately prior to GCC 8.1.0 the 'K' constraint erroneously accepted
> > > | 0xffffffff, so we must instead force the use of a register.
> >
> > Looks great - I'll adopt this, thanks for writing it.
>
> Cool. :)
>
> > > Given we haven't had any bug reports, I'm not sure whether this needs a
> > > Fixes tag or Cc stable. This has been a latent issue for a long time,
> > > but upstream code doesn't seem to have tickled it.
> >
> > Yes I guess this is more a correctness issue rather than a reproducible bug
> > in upstream code. I won't add a fixes tag or CC to stable.
>
> Sounds good to me.
>
> > > [...]
> > >
> > > > -ATOMIC_OPS(and, and)
> > > > -ATOMIC_OPS(andnot, bic)
> > > > -ATOMIC_OPS(or, orr)
> > > > -ATOMIC_OPS(xor, eor)
> > > > +ATOMIC_OPS(and, and, K)
> > > > +ATOMIC_OPS(andnot, bic, )
> > > > +ATOMIC_OPS(or, orr, K)
> > > > +ATOMIC_OPS(xor, eor, K)
> > >
> > > Surely it's not safe to use the K constraint here, either? AFAICT code
> > > like:
> > >
> > > atomic_xor(~0, &atom);
> > >
> > > ... would suffer from the same problem as described for cmpxchg.
> >
> > Thanks for spotting this.
> >
> > Yes, I think the resolution here (and for any 32bit bitmask immediate) is to
> > drop the constraint.
> >
> > Do you agree that we should drop the 'K' constraint for both orr and eor
> > above?
>
> Yes, I think we should drop the 'K' for all the 32-bit logical ops.
Ah yes, I keep getting 'and' and 'add' mixed up. OK I'll drop 'K' from all
the above.
>
> > > [...]
> > >
> > > > -ATOMIC64_OPS(and, and)
> > > > -ATOMIC64_OPS(andnot, bic)
> > > > -ATOMIC64_OPS(or, orr)
> > > > -ATOMIC64_OPS(xor, eor)
> > > > +ATOMIC64_OPS(and, and, K)
> > > > +ATOMIC64_OPS(andnot, bic, )
> > > > +ATOMIC64_OPS(or, orr, K)
> > > > +ATOMIC64_OPS(xor, eor, K)
> > >
> > > Shouldn't these be 'L'?
> > >
> > > IIUC K is a subset of L, so if that's deliberate we should call that out
> > > explicitly...
> >
> > Oooh yes that's wrong. I guess the atomic64_[and,or,xor] are rarely called
> > in the kernel which perhaps is why the compiler hasn't shouted at me.
> >
> > Do you agree that the and, orr and eor should all be 'L' instead of 'K'?
>
> Yes, I think all the 64-bit logical ops should all use 'L'.
With the exception of bic? I don't think there is an appropriate constraint
for this (it requires an 8 bit immediate).
>
> I did a quick local test, and the 'L' constraint seems to correctly
> reject ~0UL (i.e. it doesn't seem to have a similar bug to the 'K'
> constraint).
Yes, if I recall correctly the issue was only with 'K'.
>
> > > > +__CMPXCHG_CASE(w, b, , 8, , , , , )
> > > > +__CMPXCHG_CASE(w, h, , 16, , , , , )
> > > > +__CMPXCHG_CASE(w, , , 32, , , , , )
> > > > +__CMPXCHG_CASE( , , , 64, , , , , L)
> > > > +__CMPXCHG_CASE(w, b, acq_, 8, , a, , "memory", )
> > > > +__CMPXCHG_CASE(w, h, acq_, 16, , a, , "memory", )
> > > > +__CMPXCHG_CASE(w, , acq_, 32, , a, , "memory", )
> > > > +__CMPXCHG_CASE( , , acq_, 64, , a, , "memory", L)
> > > > +__CMPXCHG_CASE(w, b, rel_, 8, , , l, "memory", )
> > > > +__CMPXCHG_CASE(w, h, rel_, 16, , , l, "memory", )
> > > > +__CMPXCHG_CASE(w, , rel_, 32, , , l, "memory", )
> > > > +__CMPXCHG_CASE( , , rel_, 64, , , l, "memory", L)
> > > > +__CMPXCHG_CASE(w, b, mb_, 8, dmb ish, , l, "memory", )
> > > > +__CMPXCHG_CASE(w, h, mb_, 16, dmb ish, , l, "memory", )
> > > > +__CMPXCHG_CASE(w, , mb_, 32, dmb ish, , l, "memory", )
> > > > +__CMPXCHG_CASE( , , mb_, 64, dmb ish, , l, "memory", L)
> > >
> > > ... but these uses imply that's not the case.
> >
> > Yup, so I can leave these as they are.
>
> Yup; sounds good.
Thanks,
Andrew Murray
>
> Thanks,
> Mark.
_______________________________________________
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/2] ARM: dts: ux500: Update thermal zone
From: Daniel Lezcano @ 2019-08-28 15:43 UTC (permalink / raw)
To: Linus Walleij, linux-arm-kernel, Ulf Hansson
In-Reply-To: <20190828135218.7307-2-linus.walleij@linaro.org>
On 28/08/2019 15:52, Linus Walleij wrote:
> After moving the DB8500 thermal driver to use device tree
> we define the default thermal zone for the Ux500 in the
> device tree replacing the oldstyle hardcoded trigger
> points.
>
> This default thermal zone utilizes the cpufreq driver
> (using the generic OF cpufreq back-end) as a passive
> cooling device, and defines a critical trip point when
> the temperature goes above 85 degrees celsius which will
> (hopefully) make the system shut down if the temperature
> cannot be controlled.
>
> This default policy can later be augmented for specific
> subdevices if these have tighter temperature conditions.
>
> After this patch we get:
>
> /sys/class/thermal/thermal_zone0 (CPU thermal zone)
> This reports the rough temperature and trip points
> from the thermal zone in the device tree.
>
> By executing two yes > /dev/null & jobs fully utilizing
> the two CPU cores we can notice the temperature climbing
> in the thermal zone in response and falling when we kill
> the jobs.
>
> /syc/class/thermal/cooling_device0 (cpufreq cooling)
> this reports all 4 available cpufreq frequencies as
> states.
>
> Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/boot/dts/ste-dbx5x0.dtsi | 57 +++++++++++++++++++------------
> 1 file changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi
> index 7953eea7c486..9ee50f339e7a 100644
> --- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
> +++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
> @@ -44,6 +44,7 @@
> clocks = <&prcmu_clk PRCMU_ARMSS>;
> clock-names = "cpu";
> clock-latency = <20000>;
> + #cooling-cells = <2>;
> };
> CPU1: cpu@301 {
> device_type = "cpu";
> @@ -52,6 +53,39 @@
> };
> };
>
> + thermal-zones {
> + /*
> + * Thermal zone for the SoC, using the thermal sensor in the
> + * PRCMU for temperature and the cpufreq driver for passive
> + * cooling.
> + */
> + cpu_thermal: cpu-thermal {
> + polling-delay-passive = <0>;
> + polling-delay = <1000>;
Assuming zero for both.
If the temperature is below 'cpu_alert', no polling will be done (which
good for PM reason). When the temperature is reached, then the sensor
will fire an interrupt, leading to the thermal zone update, which in
turn does the mitigation. As the temperature is updated by the
interrupts, a polling is pointless when mitigating because the tz is
updated automatically. On the other hand, I don't know if the slope of
the temperature change will be correctly represented with this change
and how that may impact the governor if the temperature sampling is
variable (not based on polling but on interrupt events).
IMO the polling-delay should be zero, and the polling-delay-passive
should be something like 250.
In order to disable the mitigation, the sensor should update the
temperature with a value under the 'cpu_alert'. I guess that is the case
because the lowest temperature is 15000mC, right ?
> + thermal-sensors = <&thermal>;
> +
> + trips {
> + cpu_alert: cpu-alert {
> + temperature = <70000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + cpu-crit {
> + temperature = <85000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + trip = <&cpu_alert>;
> + cooling-device = <&CPU0 0 2>;
Except it is done on purpose, 0 2 means restricting the number of state
of the cooling device.
It could/should be:
<&CPU0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&CPU1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + contribution = <100>;
> + };
> + };
> + };
> +
> soc {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -502,33 +536,14 @@
> reg = <0x80157450 0xC>;
> };
>
> - thermal@801573c0 {
> + thermal: thermal@801573c0 {
> compatible = "stericsson,db8500-thermal";
> reg = <0x801573c0 0x40>;
> interrupt-parent = <&prcmu>;
> interrupts = <21 IRQ_TYPE_LEVEL_HIGH>,
> <22 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
> - num-trips = <4>;
> -
> - trip0-temp = <70000>;
> - trip0-type = "active";
> - trip0-cdev-num = <1>;
> - trip0-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip1-temp = <75000>;
> - trip1-type = "active";
> - trip1-cdev-num = <1>;
> - trip1-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip2-temp = <80000>;
> - trip2-type = "active";
> - trip2-cdev-num = <1>;
> - trip2-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip3-temp = <85000>;
> - trip3-type = "critical";
> - trip3-cdev-num = <0>;
> + #thermal-sensor-cells = <0>;
> };
>
> db8500-prcmu-regulators {
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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] PCI: rockchip: Properly handle optional regulators
From: Thierry Reding @ 2019-08-28 15:41 UTC (permalink / raw)
To: Andrew Murray
Cc: Lorenzo Pieralisi, Heiko Stuebner, linux-pci, Shawn Lin,
Vidya Sagar, linux-rockchip, Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20190828153243.GZ14582@e119886-lin.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3973 bytes --]
On Wed, Aug 28, 2019 at 04:32:44PM +0100, Andrew Murray wrote:
> On Wed, Aug 28, 2019 at 05:07:37PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > regulator_get_optional() can fail for a number of reasons besides probe
> > deferral. It can for example return -ENOMEM if it runs out of memory as
> > it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> > problematic because it results in these legitimately fatal errors being
> > treated as "regulator not specified in DT".
> >
> > What we really want is to ignore the optional regulators only if they
> > have not been specified in DT. regulator_get_optional() returns -ENODEV
> > in this case, so that's the special case that we need to handle. So we
> > propagate all errors, except -ENODEV, so that real failures will still
> > cause the driver to fail probe.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> > index 8d20f1793a61..ef8e677ce9d1 100644
> > --- a/drivers/pci/controller/pcie-rockchip-host.c
> > +++ b/drivers/pci/controller/pcie-rockchip-host.c
> > @@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
> >
> > rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
> > if (IS_ERR(rockchip->vpcie12v)) {
> > - if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie12v);
> > dev_info(dev, "no vpcie12v regulator found\n");
>
> In the event that -ENODEV is returned - we don't set vpcie12v to NULL, however
> it seems that this is OK as vpcie12v is tested with IS_ERR before use everywhere
> else in this file.
Yeah, I was trying to keep the diff small here. There doesn't seem to be
any canonical way to mark regulators as "not available". This driver
leaves it set as an error pointer, the Tegra PCI driver sets it to NULL.
They're both valid ways to do it as long as they use the proper checks
before using them. So I wasn't trying to force one way or another, just
kept it the way it was and only fixed the problematic checks.
> By the way it looks like this patch pattern could be applied right across the
> kernel, there are also others in PCI: pci-imx6 and pcie-histb.c - not sure if
> you wanted to fix those up too.
I hadn't checked any other drivers, but I can take another look and
prepare patches for them.
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Thanks,
Thierry
> > }
> >
> > rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
> > if (IS_ERR(rockchip->vpcie3v3)) {
> > - if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie3v3);
> > dev_info(dev, "no vpcie3v3 regulator found\n");
> > }
> >
> > rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
> > if (IS_ERR(rockchip->vpcie1v8)) {
> > - if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie1v8);
> > dev_info(dev, "no vpcie1v8 regulator found\n");
> > }
> >
> > rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
> > if (IS_ERR(rockchip->vpcie0v9)) {
> > - if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > + if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
> > + return PTR_ERR(rockchip->vpcie0v9);
> > dev_info(dev, "no vpcie0v9 regulator found\n");
> > }
> >
> > --
> > 2.22.0
> >
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: rockchip: Properly handle optional regulators
From: Andrew Murray @ 2019-08-28 15:32 UTC (permalink / raw)
To: Thierry Reding
Cc: Lorenzo Pieralisi, Heiko Stuebner, linux-pci, Shawn Lin,
Vidya Sagar, linux-rockchip, Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20190828150737.30285-1-thierry.reding@gmail.com>
On Wed, Aug 28, 2019 at 05:07:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> regulator_get_optional() can fail for a number of reasons besides probe
> deferral. It can for example return -ENOMEM if it runs out of memory as
> it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> problematic because it results in these legitimately fatal errors being
> treated as "regulator not specified in DT".
>
> What we really want is to ignore the optional regulators only if they
> have not been specified in DT. regulator_get_optional() returns -ENODEV
> in this case, so that's the special case that we need to handle. So we
> propagate all errors, except -ENODEV, so that real failures will still
> cause the driver to fail probe.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 8d20f1793a61..ef8e677ce9d1 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
>
> rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
> if (IS_ERR(rockchip->vpcie12v)) {
> - if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie12v);
> dev_info(dev, "no vpcie12v regulator found\n");
In the event that -ENODEV is returned - we don't set vpcie12v to NULL, however
it seems that this is OK as vpcie12v is tested with IS_ERR before use everywhere
else in this file.
By the way it looks like this patch pattern could be applied right across the
kernel, there are also others in PCI: pci-imx6 and pcie-histb.c - not sure if
you wanted to fix those up too.
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> }
>
> rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
> if (IS_ERR(rockchip->vpcie3v3)) {
> - if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie3v3);
> dev_info(dev, "no vpcie3v3 regulator found\n");
> }
>
> rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
> if (IS_ERR(rockchip->vpcie1v8)) {
> - if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie1v8);
> dev_info(dev, "no vpcie1v8 regulator found\n");
> }
>
> rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
> if (IS_ERR(rockchip->vpcie0v9)) {
> - if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie0v9);
> dev_info(dev, "no vpcie0v9 regulator found\n");
> }
>
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: Use correct ll/sc atomic constraints
From: Mark Rutland @ 2019-08-28 15:25 UTC (permalink / raw)
To: Andrew Murray
Cc: Peter Zijlstra, Catalin Marinas, Boqun Feng, Will Deacon,
Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190828130118.GW14582@e119886-lin.cambridge.arm.com>
On Wed, Aug 28, 2019 at 02:01:19PM +0100, Andrew Murray wrote:
> On Thu, Aug 22, 2019 at 04:32:23PM +0100, Mark Rutland wrote:
> > Hi Andrew,
> >
> > On Mon, Aug 12, 2019 at 03:36:22PM +0100, Andrew Murray wrote:
> > > For many of the ll/sc atomic operations we use the 'I' machine constraint
> > > regardless to the instruction used - this may not be optimal.
> > >
> > > Let's add an additional parameter to the ATOMIC_xx macros that allows the
> > > caller to specify an appropriate machine constraint.
> > >
> > > Let's also improve __CMPXCHG_CASE by replacing the 'K' constraint with a
> > > caller provided constraint. Please note that whilst we would like to use
> > > the 'K' constraint on 32 bit operations, we choose not to provide any
> > > constraint to avoid a GCC bug which results in a build error.
> > >
> > > Earlier versions of GCC (no later than 8.1.0) appear to incorrectly handle
> > > the 'K' constraint for the value 4294967295.
> >
> > From reading the above, it's difficult to discern what's a fix and
> > what's an improvement, and I think we need to be more explicit about
> > that. It would also be helpful to have the necessary context up-front.
> >
> > How about:
> >
> > | The A64 ISA accepts distinct (but overlapping) ranges of immediates for:
> > |
> > | * add arithmetic instructions ('I' machine constraint)
> > | * sub arithmetic instructions ('J' machine constraint)
> > | * 32-bit logical instructions ('K' machine constraint)
> > | * 64-bit logical instructions ('L' machine constraint)
> > |
> > | ... but we currently use the 'I' constraint for many atomic operations
> > | using sub or logical instructions, which is not always valid.
> > |
> > | When CONFIG_ARM64_LSE_ATOMICS is not set, this allows invalid immediates
> > | to be passed to instructions, potentially resulting in a build failure.
> > | When CONFIG_ARM64_LSE_ATOMICS is selected the out-of-line ll/sc atomics
> > | always use a register as they have no visibility of the value passed by
> > | the caller.
> > |
> > | This patch adds a constraint parameter to the ATOMIC_xx and
> > | __CMPXCHG_CASE macros so that we can pass appropriate constraints for
> > | each case, with uses updated accordingly.
> > |
> > | Unfortunately prior to GCC 8.1.0 the 'K' constraint erroneously accepted
> > | 0xffffffff, so we must instead force the use of a register.
>
> Looks great - I'll adopt this, thanks for writing it.
Cool. :)
> > Given we haven't had any bug reports, I'm not sure whether this needs a
> > Fixes tag or Cc stable. This has been a latent issue for a long time,
> > but upstream code doesn't seem to have tickled it.
>
> Yes I guess this is more a correctness issue rather than a reproducible bug
> in upstream code. I won't add a fixes tag or CC to stable.
Sounds good to me.
> > [...]
> >
> > > -ATOMIC_OPS(and, and)
> > > -ATOMIC_OPS(andnot, bic)
> > > -ATOMIC_OPS(or, orr)
> > > -ATOMIC_OPS(xor, eor)
> > > +ATOMIC_OPS(and, and, K)
> > > +ATOMIC_OPS(andnot, bic, )
> > > +ATOMIC_OPS(or, orr, K)
> > > +ATOMIC_OPS(xor, eor, K)
> >
> > Surely it's not safe to use the K constraint here, either? AFAICT code
> > like:
> >
> > atomic_xor(~0, &atom);
> >
> > ... would suffer from the same problem as described for cmpxchg.
>
> Thanks for spotting this.
>
> Yes, I think the resolution here (and for any 32bit bitmask immediate) is to
> drop the constraint.
>
> Do you agree that we should drop the 'K' constraint for both orr and eor
> above?
Yes, I think we should drop the 'K' for all the 32-bit logical ops.
> > [...]
> >
> > > -ATOMIC64_OPS(and, and)
> > > -ATOMIC64_OPS(andnot, bic)
> > > -ATOMIC64_OPS(or, orr)
> > > -ATOMIC64_OPS(xor, eor)
> > > +ATOMIC64_OPS(and, and, K)
> > > +ATOMIC64_OPS(andnot, bic, )
> > > +ATOMIC64_OPS(or, orr, K)
> > > +ATOMIC64_OPS(xor, eor, K)
> >
> > Shouldn't these be 'L'?
> >
> > IIUC K is a subset of L, so if that's deliberate we should call that out
> > explicitly...
>
> Oooh yes that's wrong. I guess the atomic64_[and,or,xor] are rarely called
> in the kernel which perhaps is why the compiler hasn't shouted at me.
>
> Do you agree that the and, orr and eor should all be 'L' instead of 'K'?
Yes, I think all the 64-bit logical ops should all use 'L'.
I did a quick local test, and the 'L' constraint seems to correctly
reject ~0UL (i.e. it doesn't seem to have a similar bug to the 'K'
constraint).
> > > +__CMPXCHG_CASE(w, b, , 8, , , , , )
> > > +__CMPXCHG_CASE(w, h, , 16, , , , , )
> > > +__CMPXCHG_CASE(w, , , 32, , , , , )
> > > +__CMPXCHG_CASE( , , , 64, , , , , L)
> > > +__CMPXCHG_CASE(w, b, acq_, 8, , a, , "memory", )
> > > +__CMPXCHG_CASE(w, h, acq_, 16, , a, , "memory", )
> > > +__CMPXCHG_CASE(w, , acq_, 32, , a, , "memory", )
> > > +__CMPXCHG_CASE( , , acq_, 64, , a, , "memory", L)
> > > +__CMPXCHG_CASE(w, b, rel_, 8, , , l, "memory", )
> > > +__CMPXCHG_CASE(w, h, rel_, 16, , , l, "memory", )
> > > +__CMPXCHG_CASE(w, , rel_, 32, , , l, "memory", )
> > > +__CMPXCHG_CASE( , , rel_, 64, , , l, "memory", L)
> > > +__CMPXCHG_CASE(w, b, mb_, 8, dmb ish, , l, "memory", )
> > > +__CMPXCHG_CASE(w, h, mb_, 16, dmb ish, , l, "memory", )
> > > +__CMPXCHG_CASE(w, , mb_, 32, dmb ish, , l, "memory", )
> > > +__CMPXCHG_CASE( , , mb_, 64, dmb ish, , l, "memory", L)
> >
> > ... but these uses imply that's not the case.
>
> Yup, so I can leave these as they are.
Yup; sounds good.
Thanks,
Mark.
_______________________________________________
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/2] ARM: dts: ux500: Fix up the thermal nodes
From: Daniel Lezcano @ 2019-08-28 15:25 UTC (permalink / raw)
To: Linus Walleij, linux-arm-kernel, Ulf Hansson
In-Reply-To: <20190828135218.7307-1-linus.walleij@linaro.org>
On 28/08/2019 15:52, Linus Walleij wrote:
> The thermal driver for the DB8500 was never properly converted
> to device tree, the node should definitely be activated for
> all board variants so move this down into the main SoC
> DTSI, and default on.
>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/boot/dts/ste-dbx5x0.dtsi | 22 +++++++++++++++++++++-
> arch/arm/boot/dts/ste-snowball.dts | 29 -----------------------------
> 2 files changed, 21 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi
> index b1a31134f860..7953eea7c486 100644
> --- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
> +++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
> @@ -505,10 +505,30 @@
> thermal@801573c0 {
> compatible = "stericsson,db8500-thermal";
> reg = <0x801573c0 0x40>;
> + interrupt-parent = <&prcmu>;
> interrupts = <21 IRQ_TYPE_LEVEL_HIGH>,
> <22 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
> - status = "disabled";
> + num-trips = <4>;
> +
> + trip0-temp = <70000>;
> + trip0-type = "active";
> + trip0-cdev-num = <1>;
> + trip0-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip1-temp = <75000>;
> + trip1-type = "active";
> + trip1-cdev-num = <1>;
> + trip1-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip2-temp = <80000>;
> + trip2-type = "active";
> + trip2-cdev-num = <1>;
> + trip2-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip3-temp = <85000>;
> + trip3-type = "critical";
> + trip3-cdev-num = <0>;
I think you can fold both patches, that would be clearer than moving and
then removing.
> };
>
> db8500-prcmu-regulators {
> diff --git a/arch/arm/boot/dts/ste-snowball.dts b/arch/arm/boot/dts/ste-snowball.dts
> index 3428290644ba..064e8abec954 100644
> --- a/arch/arm/boot/dts/ste-snowball.dts
> +++ b/arch/arm/boot/dts/ste-snowball.dts
> @@ -376,40 +376,11 @@
> pinctrl-0 = <&ssp0_snowball_mode>;
> };
>
> - cpufreq-cooling {
> - status = "okay";
> - };
> -
> prcmu@80157000 {
> cpufreq {
> status = "okay";
> };
>
> - thermal@801573c0 {
> - num-trips = <4>;
> -
> - trip0-temp = <70000>;
> - trip0-type = "active";
> - trip0-cdev-num = <1>;
> - trip0-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip1-temp = <75000>;
> - trip1-type = "active";
> - trip1-cdev-num = <1>;
> - trip1-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip2-temp = <80000>;
> - trip2-type = "active";
> - trip2-cdev-num = <1>;
> - trip2-cdev-name0 = "thermal-cpufreq-0";
> -
> - trip3-temp = <85000>;
> - trip3-type = "critical";
> - trip3-cdev-num = <0>;
> -
> - status = "okay";
> - };
> -
> ab8500 {
> ab8500-gpio {
> /*
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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 4/6] PCI: tegra: Add support to enable slot regulators
From: Andrew Murray @ 2019-08-28 15:20 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190828131505.28475-5-vidyas@nvidia.com>
On Wed, Aug 28, 2019 at 06:45:03PM +0530, Vidya Sagar wrote:
> Add support to get regulator information of 3.3V and 12V supplies of a PCIe
> slot from the respective controller's device-tree node and enable those
> supplies. This is required in platforms like p2972-0000 where the supplies
> to x16 slot owned by C5 controller need to be enabled before attempting to
> enumerate the devices.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> V2:
> * Addressed review comments from Thierry Reding and Andrew Murray
> * Handled failure case of devm_regulator_get_optional() for -ENODEV cleanly
>
> drivers/pci/controller/dwc/pcie-tegra194.c | 80 ++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 057ba4f9fbcd..6a66101ec83d 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
> u32 aspm_l0s_enter_lat;
>
> struct regulator *pex_ctl_supply;
> + struct regulator *slot_ctl_3v3;
> + struct regulator *slot_ctl_12v;
>
> unsigned int phy_count;
> struct phy **phys;
> @@ -1047,6 +1049,72 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
> }
> }
>
> +static int tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
> + if (IS_ERR(pcie->slot_ctl_3v3)) {
> + if (PTR_ERR(pcie->slot_ctl_3v3) != -ENODEV)
> + return PTR_ERR(pcie->slot_ctl_3v3);
> +
> + pcie->slot_ctl_3v3 = NULL;
> + }
> +
> + pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
> + if (IS_ERR(pcie->slot_ctl_12v)) {
> + if (PTR_ERR(pcie->slot_ctl_12v) != -ENODEV)
> + return PTR_ERR(pcie->slot_ctl_12v);
> +
> + pcie->slot_ctl_12v = NULL;
> + }
> +
> + return 0;
> +}
> +
> +static int tegra_pcie_enable_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + int ret;
> +
> + if (pcie->slot_ctl_3v3) {
> + ret = regulator_enable(pcie->slot_ctl_3v3);
> + if (ret < 0) {
> + dev_err(pcie->dev,
> + "Failed to enable 3V3 slot supply: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + if (pcie->slot_ctl_12v) {
> + ret = regulator_enable(pcie->slot_ctl_12v);
> + if (ret < 0) {
> + dev_err(pcie->dev,
> + "Failed to enable 12V slot supply: %d\n", ret);
> + goto fail_12v_enable;
> + }
> + }
> +
> + /*
> + * According to PCI Express Card Electromechanical Specification
> + * Revision 1.1, Table-2.4, T_PVPERL (Power stable to PERST# inactive)
> + * should be a minimum of 100ms.
> + */
> + msleep(100);
> +
> + return 0;
> +
> +fail_12v_enable:
> + if (pcie->slot_ctl_3v3)
> + regulator_disable(pcie->slot_ctl_3v3);
> + return ret;
> +}
> +
> +static void tegra_pcie_disable_slot_regulators(struct tegra_pcie_dw *pcie)
> +{
> + if (pcie->slot_ctl_12v)
> + regulator_disable(pcie->slot_ctl_12v);
> + if (pcie->slot_ctl_3v3)
> + regulator_disable(pcie->slot_ctl_3v3);
> +}
> +
> static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> bool en_hw_hot_rst)
> {
> @@ -1060,6 +1128,10 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> return ret;
> }
>
> + ret = tegra_pcie_enable_slot_regulators(pcie);
> + if (ret < 0)
> + goto fail_slot_reg_en;
> +
> ret = regulator_enable(pcie->pex_ctl_supply);
> if (ret < 0) {
> dev_err(pcie->dev, "Failed to enable regulator: %d\n", ret);
> @@ -1142,6 +1214,8 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
> fail_core_clk:
> regulator_disable(pcie->pex_ctl_supply);
> fail_reg_en:
> + tegra_pcie_disable_slot_regulators(pcie);
> +fail_slot_reg_en:
> tegra_pcie_bpmp_set_ctrl_state(pcie, false);
>
> return ret;
> @@ -1174,6 +1248,8 @@ static int __deinit_controller(struct tegra_pcie_dw *pcie)
> return ret;
> }
>
> + tegra_pcie_disable_slot_regulators(pcie);
> +
> ret = tegra_pcie_bpmp_set_ctrl_state(pcie, false);
> if (ret) {
> dev_err(pcie->dev, "Failed to disable controller %d: %d\n",
> @@ -1373,6 +1449,10 @@ static int tegra_pcie_dw_probe(struct platform_device *pdev)
> return ret;
> }
>
> + ret = tegra_pcie_get_slot_regulators(pcie);
> + if (ret < 0)
> + return ret;
All of the functions called from tegra_pcie_dw_probe appear to dev_err if
something goes wrong, is there any reason why you haven't done that here?
Thanks,
Andrew Murray
> +
> pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
> if (IS_ERR(pcie->pex_ctl_supply)) {
> dev_err(dev, "Failed to get regulator: %ld\n",
> --
> 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
* [GIT PULL 4/4] DaVinci DT updates for v5.4
From: Sekhar Nori @ 2019-08-28 15:17 UTC (permalink / raw)
To: ARM-SoC Maintainers; +Cc: Bartosz Golaszewski, nsekhar, Linux ARM Mailing List
In-Reply-To: <20190828151754.21023-1-nsekhar@ti.com>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/dt
for you to fetch changes up to 01cc0596ef0e483543abd1f4887eff7e54797c36:
ARM: dts: da850-evm: Use generic jedec, spi-nor for flash (2019-08-26 17:50:30 +0530)
----------------------------------------------------------------
Contains a patch to switch to more generic compatible for SPI NOR.
This helps SPI NOR to work on newer board variants.
----------------------------------------------------------------
Adam Ford (1):
ARM: dts: da850-evm: Use generic jedec, spi-nor for flash
arch/arm/boot/dts/da850-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/4] DaVinci fbdev driver updates for v5.4
From: Sekhar Nori @ 2019-08-28 15:17 UTC (permalink / raw)
To: ARM-SoC Maintainers
Cc: Bartosz Golaszewski, nsekhar, Linux ARM Mailing List,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20190828151754.21023-1-nsekhar@ti.com>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/fbdev
for you to fetch changes up to 671da5f3444b09779f108d28cc69414c57deab8c:
fbdev: da8xx: use resource management for dma (2019-08-26 17:54:00 +0530)
----------------------------------------------------------------
This converts the da8xx fbdev driver to use GPIO backlight device
and regulator devices. This will finally help get rid of legacy
GPIO API calls and simplify DaVinci GPIO driver.
----------------------------------------------------------------
Bartosz Golaszewski (7):
ARM: davinci: da850-evm: model the backlight GPIO as an actual device
fbdev: da8xx: add support for a regulator
ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc
fbdev: da8xx: remove panel_power_ctrl() callback from platform data
fbdev: da8xx-fb: use devm_platform_ioremap_resource()
fbdev: da8xx-fb: drop a redundant if
fbdev: da8xx: use resource management for dma
arch/arm/mach-davinci/board-da850-evm.c | 90 +++++++++++++++++-------
drivers/video/fbdev/da8xx-fb.c | 118 ++++++++++++++++++--------------
include/video/da8xx-fb.h | 1 -
3 files changed, 131 insertions(+), 78 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/4] DaVinci defconfig updates for v5.4
From: Sekhar Nori @ 2019-08-28 15:17 UTC (permalink / raw)
To: ARM-SoC Maintainers; +Cc: Bartosz Golaszewski, nsekhar, Linux ARM Mailing List
In-Reply-To: <20190828151754.21023-1-nsekhar@ti.com>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/defconfig
for you to fetch changes up to e869e44f2d82b9b4d35d58ceaeeadb0242bc634c:
ARM: davinci_all_defconfig: enable GPIO backlight (2019-08-08 14:33:45 +0530)
----------------------------------------------------------------
Contains davinci_all_defconfig refresh using savedefconfig and a
patch to enable GPIO backlight.
----------------------------------------------------------------
Bartosz Golaszewski (2):
ARM: davinci: refresh davinci_all_defconfig
ARM: davinci_all_defconfig: enable GPIO backlight
arch/arm/configs/davinci_all_defconfig | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/4] DaVinci SoC updates for v5.4
From: Sekhar Nori @ 2019-08-28 15:17 UTC (permalink / raw)
To: ARM-SoC Maintainers; +Cc: Bartosz Golaszewski, nsekhar, Linux ARM Mailing List
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/soc
for you to fetch changes up to 93eae12c9f3e3bf423b308b341d380b0b4291bf8:
ARM: davinci: dm646x: Fix a typo in the comment (2019-08-26 17:51:28 +0530)
----------------------------------------------------------------
This converts all DaVinci SoCs except DM365 to use new clocksource
driver. DM365 conversion is still under debug and will be part of a
future pull request.
----------------------------------------------------------------
Bartosz Golaszewski (8):
ARM: davinci: enable the clocksource driver for DT mode
ARM: davinci: WARN_ON() if clk_get() fails
ARM: davinci: da850: switch to using the clocksource driver
ARM: davinci: da830: switch to using the clocksource driver
ARM: davinci: move timer definitions to davinci.h
ARM: davinci: dm355: switch to using the clocksource driver
ARM: davinci: dm644x: switch to using the clocksource driver
ARM: davinci: dm646x: switch to using the clocksource driver
Christophe JAILLET (1):
ARM: davinci: dm646x: Fix a typo in the comment
arch/arm/Kconfig | 1 +
arch/arm/mach-davinci/da830.c | 45 +++++++++++-----------------
arch/arm/mach-davinci/da850.c | 50 +++++++++++--------------------
arch/arm/mach-davinci/davinci.h | 3 ++
arch/arm/mach-davinci/dm355.c | 28 ++++++++++-------
arch/arm/mach-davinci/dm365.c | 4 +++
arch/arm/mach-davinci/dm644x.c | 28 ++++++++++-------
arch/arm/mach-davinci/dm646x.c | 30 +++++++++++--------
arch/arm/mach-davinci/include/mach/time.h | 2 --
arch/arm/mach-davinci/time.c | 14 ---------
10 files changed, 95 insertions(+), 110 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] drm/meson: add resume/suspend hooks
From: Neil Armstrong @ 2019-08-28 15:14 UTC (permalink / raw)
To: Kevin Hilman, dri-devel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <7htva1s4rt.fsf@baylibre.com>
On 28/08/2019 17:12, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> On 27/08/2019 21:17, Kevin Hilman wrote:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
>>>> and the DW-HDMI Glue driver to correctly save state and disable HW before
>>>> suspend, and succesfully re-init the HW to recover functionnal display
>>>> after resume.
>>>>
>>>> This serie has been tested on Amlogic G12A based SEI510 board, using
>>>> the newly accepted VRTC driver and the rtcwake utility.
>>>
>>> Tested-by: Kevin Hilman <khilman@baylibre.com>
>>>
>>> Tested on my G12A SEI510 board, and I verified that it fixes
>>> suspend/resume issues previously seen.
>>>
>>> Kevin
>>>
>>
>> Thanks,
>>
>> Applying to drm-misc-next (for v5.5), with a typo fix in the first patch commit log:
>> s/suspens/suspend
>
> Is there any chance of getting this in a a fix for v5.4 so we have a
> working suspend/resume in v5.4?
Nop, it's already applied to drm-misc-next and is already out of the window
for 5.4 anyway.
Neil
>
> Thanks,
>
> Kevin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] drm/meson: add resume/suspend hooks
From: Kevin Hilman @ 2019-08-28 15:12 UTC (permalink / raw)
To: Neil Armstrong, dri-devel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <b8ea00c4-3749-e571-edb6-ae5091b23247@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 27/08/2019 21:17, Kevin Hilman wrote:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
>>> and the DW-HDMI Glue driver to correctly save state and disable HW before
>>> suspend, and succesfully re-init the HW to recover functionnal display
>>> after resume.
>>>
>>> This serie has been tested on Amlogic G12A based SEI510 board, using
>>> the newly accepted VRTC driver and the rtcwake utility.
>>
>> Tested-by: Kevin Hilman <khilman@baylibre.com>
>>
>> Tested on my G12A SEI510 board, and I verified that it fixes
>> suspend/resume issues previously seen.
>>
>> Kevin
>>
>
> Thanks,
>
> Applying to drm-misc-next (for v5.5), with a typo fix in the first patch commit log:
> s/suspens/suspend
Is there any chance of getting this in a a fix for v5.4 so we have a
working suspend/resume in v5.4?
Thanks,
Kevin
_______________________________________________
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] PCI: tegra: Add support to configure sideband pins
From: Andrew Murray @ 2019-08-28 15:07 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190828131505.28475-4-vidyas@nvidia.com>
On Wed, Aug 28, 2019 at 06:45:02PM +0530, Vidya Sagar wrote:
> Add support to configure sideband signal pins when information is present
> in respective controller's device-tree node.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> V2:
> * Addressed review comment from Andrew Murray
> * Handled failure case of pinctrl_pm_select_default_state() cleanly
>
> drivers/pci/controller/dwc/pcie-tegra194.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index fc0dbeb31d78..057ba4f9fbcd 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -1304,8 +1304,13 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
> if (ret < 0) {
> dev_err(dev, "Failed to get runtime sync for PCIe dev: %d\n",
> ret);
> - pm_runtime_disable(dev);
> - return ret;
> + goto fail_pm_get_sync;
> + }
> +
> + ret = pinctrl_pm_select_default_state(pcie->dev);
This patch looks OK, though you're still using pcie->dev here instead of dev.
Thanks,
Andrew Murray
> + if (ret < 0) {
> + dev_err(dev, "Failed to configure sideband pins: %d\n", ret);
> + goto fail_pinctrl;
> }
>
> tegra_pcie_init_controller(pcie);
> @@ -1332,7 +1337,9 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
>
> fail_host_init:
> tegra_pcie_deinit_controller(pcie);
> +fail_pinctrl:
> pm_runtime_put_sync(dev);
> +fail_pm_get_sync:
> pm_runtime_disable(dev);
> return ret;
> }
> --
> 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
* [PATCH] PCI: rockchip: Properly handle optional regulators
From: Thierry Reding @ 2019-08-28 15:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Shawn Lin
Cc: Heiko Stuebner, linux-pci, Vidya Sagar, linux-rockchip,
Andrew Murray, linux-arm-kernel
From: Thierry Reding <treding@nvidia.com>
regulator_get_optional() can fail for a number of reasons besides probe
deferral. It can for example return -ENOMEM if it runs out of memory as
it tries to allocate data structures. Propagating only -EPROBE_DEFER is
problematic because it results in these legitimately fatal errors being
treated as "regulator not specified in DT".
What we really want is to ignore the optional regulators only if they
have not been specified in DT. regulator_get_optional() returns -ENODEV
in this case, so that's the special case that we need to handle. So we
propagate all errors, except -ENODEV, so that real failures will still
cause the driver to fail probe.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index 8d20f1793a61..ef8e677ce9d1 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
if (IS_ERR(rockchip->vpcie12v)) {
- if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
+ return PTR_ERR(rockchip->vpcie12v);
dev_info(dev, "no vpcie12v regulator found\n");
}
rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
if (IS_ERR(rockchip->vpcie3v3)) {
- if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
+ return PTR_ERR(rockchip->vpcie3v3);
dev_info(dev, "no vpcie3v3 regulator found\n");
}
rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
if (IS_ERR(rockchip->vpcie1v8)) {
- if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
+ return PTR_ERR(rockchip->vpcie1v8);
dev_info(dev, "no vpcie1v8 regulator found\n");
}
rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
if (IS_ERR(rockchip->vpcie0v9)) {
- if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
+ return PTR_ERR(rockchip->vpcie0v9);
dev_info(dev, "no vpcie0v9 regulator found\n");
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Adam Ford @ 2019-08-28 15:00 UTC (permalink / raw)
To: linux-omap
Cc: Mark Rutland, devicetree, Paul Walmsley, aaro.koskinen,
Tony Lindgren, adam.ford, Russell King, linux-kernel, t-kristo,
Rob Herring, Benoît Cousson, pali.rohar, Adam Ford,
linux-arm-kernel
The datasheet for the AM3517 shows the RNG is connected to L4.
It shows the module address for the RNG is 0x480A0000, and it
matches the omap2.dtsi description. Since the driver can support
omap2 and omap4, it seems reasonable to assume the omap3 would
use the same core for the RNG.
This RFC, mimics much of the omap2 hwmods on the OMAP3. It
also adds the necessary clock for driving the RNG. Unfortunately,
it appears non-functional. If anyone has any suggestions on how
to finish the hwmod (or port it to the newer l4 device tree
format), feedback is requested.
Currently the hwmods repond as follows:
[ 0.245697] omap_hwmod: rng: _wait_target_ready failed: -22
[ 0.245727] omap_hwmod: rng: cannot be enabled for reset (3)
[ 6.780792] omap_hwmod: rng: _wait_target_ready failed: -22
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
index 945537aee3ca..05891dff7fa1 100644
--- a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
@@ -189,7 +189,7 @@
<&mcspi2_ick>, <&mcspi1_ick>, <&i2c3_ick>, <&i2c2_ick>,
<&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
<&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
- <&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>,
+ <&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>, <&rng_ick>,
<&ssi_ick>;
};
};
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 037529a9e969..82330a66e35c 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -17,6 +17,7 @@
#define OMAP3430_CLKACTIVITY_IVA2_MASK (1 << 0)
#define OMAP3430_CLKTRCTRL_MPU_MASK (0x3 << 0)
#define OMAP3430_ST_AES2_SHIFT 28
+#define OMAP34XX_ST_RNG_SHIFT 2
#define OMAP3430_ST_SHA12_SHIFT 27
#define AM35XX_ST_UART4_SHIFT 23
#define OMAP3430_ST_HDQ_SHIFT 22
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f52438bdfc14..bae4487383b6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1627,6 +1627,42 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = {
.flags = HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS,
};
+/* RNG */
+
+static struct omap_hwmod_class_sysconfig omap3_rng_sysc = {
+ .rev_offs = 0x3c,
+ .sysc_offs = 0x40,
+ .syss_offs = 0x44,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3_rng_hwmod_class = {
+ .name = "rng",
+ .sysc = &omap3_rng_sysc,
+};
+
+struct omap_hwmod omap3xxx_rng_hwmod = {
+ .name = "rng",
+ .main_clk = "rng_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 4,
+ .idlest_idle_bit = OMAP34XX_ST_RNG_SHIFT,
+ },
+ },
+ /*
+ * XXX The first read from the SYSSTATUS register of the RNG
+ * after the SYSCONFIG SOFTRESET bit is set triggers an
+ * imprecise external abort. It's unclear why this happens.
+ * Until this is analyzed, skip the IP block reset.
+ */
+ .flags = HWMOD_INIT_NO_RESET,
+ .class = &omap3_rng_hwmod_class,
+};
+
/*
* interfaces
*/
@@ -2508,6 +2544,13 @@ static struct omap_hwmod omap3xxx_sham_hwmod = {
.class = &omap3xxx_sham_class,
};
+/* l4_core -> rng */
+struct omap_hwmod_ocp_if omap3xxx_l4_core__rng = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_rng_hwmod,
+ .clk = "rng_ick",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
static struct omap_hwmod_ocp_if omap3xxx_l4_core__sham = {
.master = &omap3xxx_l4_core_hwmod,
@@ -2769,6 +2812,7 @@ static struct omap_hwmod_ocp_if *omap36xx_hwmod_ocp_ifs[] __initdata = {
&omap3xxx_l4_core__mmu_isp,
&omap3xxx_l3_main__mmu_iva,
&omap3xxx_l4_core__ssi,
+ &omap3xxx_l4_core__rng,
NULL,
};
@@ -2788,6 +2832,7 @@ static struct omap_hwmod_ocp_if *am35xx_hwmod_ocp_ifs[] __initdata = {
&am35xx_l4_core__mdio,
&am35xx_emac__l3,
&am35xx_l4_core__emac,
+ &omap3xxx_l4_core__rng,
NULL,
};
--
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: [EXT] [PATCH v3 0/2] drm: bridge: Add NWL MIPI DSI host controller support
From: Robert Chiras @ 2019-08-28 14:29 UTC (permalink / raw)
To: dl-linux-imx, narmstrong@baylibre.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org, lee.jones@linaro.org,
devicetree@vger.kernel.org, agx@sigxcpu.org, festevam@gmail.com,
jernej.skrabec@siol.net, daniel@ffwll.ch, mark.rutland@arm.com,
a.hajda@samsung.com, dri-devel@lists.freedesktop.org,
jonas@kwiboo.se, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, sam@ravnborg.org,
airlied@linux.ie, Laurent.pinchart@ideasonboard.com,
kernel@pengutronix.de, arnd@arndb.de, s.hauer@pengutronix.de
In-Reply-To: <cover.1566470526.git.agx@sigxcpu.org>
Hi Guido,
I tested this on my setup and it works. My DSI panel is a little bit
different and it doesn't work with this as-is, but I added some
improvements on top of this, in order to be able to setup the clocks.
The changes I made can arrive on top of this as improvements, of
course, since it will allow this driver to dinamically set the
video_pll clock for any kind of mode.
So, for the whole patch-set, you can add:
Tested-by: Robert Chiras <robert.chiras@nxp.com>
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Best regards,
Robert
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on i.MX8
> SoCs.
>
> It adds support for the i.MX8MQ but the same IP core can also be
> found on e.g.
> i.MX8QXP. I added the necessary hooks to support other imx8 variants
> but since
> I only have imx8mq boards to test I omitted the platform data for
> other SoCs.
>
> The code is based on NXPs BSP so I added Robert Chiras as
> Co-authored-by. Robert, if this looks sane could you add your
> Signed-off-by:?
>
> The most notable changes over the BSP driver are
> - Calculate HS mode timing from phy_configure_opts_mipi_dphy
> - Perform all clock setup via DT
> - Merge nwl-imx and nwl drivers
> - Add B0 silion revision quirk
> - become a bridge driver to hook into mxsfb (from what I read[0]
> DCSS, which
> also can drive the nwl on the imx8mq will likely not become part
> of
> imx-display-subsystem so it makes sense to make it drive a bridge
> for dsi as
> well).
> - Use panel_bridge to attach the panel
> - Use multiplex framework instead of accessing syscon directly
>
> This has been tested on a Librem 5 devkit using mxsfb with Robert's
> patches[1]
> and the rocktech-jh057n00900 panel driver on next-20190821. The DCSS
> can later
> on also act as input source too.
>
> Changes from v2:
> - Per review comments by Rob Herring
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> August%2F230448.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637020674654566414&sdata=JdvAdCPGq2CTsW%2BgXgnAVltWMIfdCDQn
> dXSLYpnjEH8%3D&reserved=0
> - bindings:
> - Simplify by restricting to fsl,imx8mq-nwl-dsi
> - document reset lines
> - add port@{0,1}
> - use a real compatible string for the panel
> - resets are required
> - Per review comments by Arnd Bergmann
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> August%2F230868.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637020674654566414&sdata=LyJpZjQjMCe5zUdvK8CD8ETucLPxx621gW
> xtpAr8DM4%3D&reserved=0
> - Don't access iomuxc_gpr regs directly. This allows us to drop the
> first patch in the series with the iomuxc_gpr field defines.
> - Per review comments by Laurent Pinchart
> - Fix wording in bindings
> - Add mux-controls to bindings
> - Don't print error message on dphy probe deferal
>
> Changes from v1:
> - Per review comments by Sam Ravnborg
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> July%2F228130.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637020674654566414&sdata=AU2gzIwrbCdIBZenPWWYYX%2BgdX53zc2%2B
> SQhZbuN%2FWpU%3D&reserved=0
> - Change binding docs to YAML
> - build: Don't always visit imx-nwl/
> - build: Add header-test-y
> - Sort headers according to DRM convention
> - Use drm_display_mode instead of videmode
> - Per review comments by Fabio Estevam
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> July%2F228299.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637020674654566414&sdata=6kpIZ6iNAQ13fMXU6sqENLwy%2FdIWL6ef8j
> gyas7I0CQ%3D&reserved=0
> - Don't restrict build to ARCH_MXC
> - Drop unused includes
> - Drop unreachable code in imx_nwl_dsi_bridge_mode_fixup()
> - Drop remaining calls of dev_err() and use DRM_DEV_ERR()
> consistently.
> - Use devm_platform_ioremap_resource()
> - Drop devm_free_irq() in probe() error path
> - Use single line comments where sufficient
> - Use <linux/time64.h> instead of defining USEC_PER_SEC
> - Make input source select imx8 specific
> - Drop <asm/unaligned.h> inclusion (after removal of
> get_unaligned_le32)
> - Drop all EXPORT_SYMBOL_GPL() for functions used in the same
> module
> but different source files.
> - Drop nwl_dsi_enable_{rx,tx}_clock() by invoking
> clk_prepare_enable()
> directly
> - Remove pointless comment
> - Laurent Pinchart
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> July%2F228313.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637020674654566414&sdata=tDlVGeET1CPMH9W%2FqmnePNR51vNaTKD%2F
> iFOoR9%2FmESc%3D&reserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> July%2F228308.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637020674654566414&sdata=NsLGAL8%2BcOC0ZZxxeoGe7VxQCgqSBEN4G3
> WVGOeZpCo%3D&reserved=0
> - Drop (on iMX8MQ) unused csr regmap
> - Use NWL_MAX_PLATFORM_CLOCKS everywhere
> - Drop get_unaligned_le32() usage
> - remove duplicate 'for the' in binding docs
> - Don't include unused <linux/clk-provider.h>
> - Don't include unused <linux/component.h>
> - Drop dpms_mode for tracking state, trust the drm layer on that
> - Use pm_runtime_put() instead of pm_runtime_put_sync()
> - Don't overwrite encoder type
> - Make imx_nwl_platform_data const
> - Use the reset controller API instead of open coding that platform
> specific
> part
> - Use <linux/bitfield.h> intead of making up our own defines
> - name mipi_dsi_transfer less generic: nwl_dsi_transfer
> - ensure clean in .remove by calling mipi_dsi_host_unregister.
> - prefix constants by NWL_DSI_
> - properly format transfer_direction enum
> - simplify platform clock handling
> - Don't modify state in mode_fixup() and use mode_set() instead
> - Drop bridge detach(), already handle by nwl_dsi_host_detach()
> - Drop USE_*_QUIRK() macros
> - Drop (for now) unused clock defnitions. 'pixel' and 'bypass' clock
> will be
> used for i.MX8 SoCs but since they're unused atm drop the
> definitions - but
> keep the logic to enable/disable several clocks in place since we
> know we'll
> need it in the future.
>
> Changes from v0:
> - Add quirk for IMQ8MQ silicon B0 revision to not mess with the
> system reset controller on power down since enable() won't work
> otherwise.
> - Drop devm_free_irq() handled by the device driver core
> - Disable tx esc clock after the phy power down to unbreak
> disable/enable (unblank/blank)
> - Add ports to dt binding docs
> - Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
> phy_mipi_dphy_get_default_config
> - Select DRM_MIPI_DSI
> - Include drm_print.h to fix build on next-20190408
> - Drop some debugging messages
> - Newline terminate all DRM_ printouts
> - Turn component driver into a drm bridge
>
> [0]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> May%2F219484.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757201
> f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C637020674654566414&sdata=4IVjhLy3a2XxZ4jYwDFD23D%2BvwAVAEj44hY
> fvvp8OpQ%3D&reserved=0
> [1]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fpatchwork.freedesktop.org%2Fseries%2F62822%2F&data=02%7C01%7Cro
> bert.chiras%40nxp.com%7C757201f9aaa54653580e08d726edb290%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637020674654566414&sdata=GueUBOc
> baGjWtWcMYBplL6ki2UbgaFPkQHg%2F6eReiYg%3D&reserved=0
>
> To: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
> Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>
> , Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.
> de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <
> festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Andrzej
> Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>
> , Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman
> <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@siol.net>, Lee
> Jones <lee.jones@linaro.org>, Guido Günther <agx@sigxcpu.org>, dri-de
> vel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kern
> el@lists.infradead.org, linux-kernel@vger.kernel.org, Robert Chiras <
> robert.chiras@nxp.com>, Sam Ravnborg <sam@ravnborg.org>, Fabio
> Estevam <festevam@gmail.com>, Arnd Bergmann <arnd@arndb.de>
>
>
> Guido Günther (2):
> dt-bindings: display/bridge: Add binding for NWL mipi dsi host
> controller
> drm/bridge: Add NWL MIPI DSI host controller support
>
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++++
> drivers/gpu/drm/bridge/Kconfig | 2 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501 +++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 ++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> ++++++++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 +++
> 9 files changed, 1556 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
>
> --
> 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
* Re: [PATCH 8/8] coresight: etm4x: docs: Additional documentation for ETM4x.
From: Mike Leach @ 2019-08-28 14:20 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Coresight ML, linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190827223438.GA20203@xps15>
Hi Mathieu,
I assume you want the split to be ? :-
1. the update in Documentation/ARM/testing/sysfs-bus-coresight-devices-etm4x
2. the moving of coresight docs to their new common directory.
3. the addition of the new etm4x doc
On Tue, 27 Aug 2019 at 23:34, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:20PM +0100, Mike Leach wrote:
> > Update existing docs for new sysfs API features.
> > Add new ETMv4 reference document for sysfs programming.
> > Move coresight documentation to common directory.
> >
>
> I also get the following warnings when adding the patch:
>
> $ git am 0008-coresight-etm4x-docs-Additional-documentation-for-ET.patch
> Applying: coresight: etm4x: docs: Additional documentation for ETM4x.
> .git/rebase-apply/patch:620: space before tab in indent.
> bitfield up to 32 bits setting trace features.
> .git/rebase-apply/patch:950: space before tab in indent.
> ; range comparator
> .git/rebase-apply/patch:954: space before tab in indent.
> ; address comparator
> .git/rebase-apply/patch:1057: new blank line at EOF.
> +
> warning: 4 lines add whitespace errors.
>
OK - I'll re-look at this, but don't recall seeing any errors myself
& al cleared by checkpatch.
Regards
Mike
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../testing/sysfs-bus-coresight-devices-etm4x | 183 ++++---
> > .../{ => coresight}/coresight-cpu-debug.txt | 0
> > .../coresight/coresight-etm4x-reference.txt | 459 ++++++++++++++++++
> > .../trace/{ => coresight}/coresight.txt | 0
> > MAINTAINERS | 3 +-
> > 5 files changed, 575 insertions(+), 70 deletions(-)
> > rename Documentation/trace/{ => coresight}/coresight-cpu-debug.txt (100%)
> > create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.txt
> > rename Documentation/trace/{ => coresight}/coresight.txt (100%)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > index 36258bc1b473..112c50ae9986 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > @@ -1,4 +1,4 @@
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -8,82 +8,82 @@ Description: (RW) Enable/disable tracing on this specific trace entiry.
> > of coresight components linking the source to the sink is
> > configured and managed automatically by the coresight framework.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cpu
> > +What: /sys/bus/coresight/devices/etm<N>/cpu
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) The CPU this tracing entity is associated with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
> > +What: /sys/bus/coresight/devices/etm<N>/nr_pe_cmp
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of PE comparator inputs that are
> > available for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
> > +What: /sys/bus/coresight/devices/etm<N>/nr_addr_cmp
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of address comparator pairs that are
> > available for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
> > +What: /sys/bus/coresight/devices/etm<N>/nr_cntr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of counters that are available for
> > tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
> > +What: /sys/bus/coresight/devices/etm<N>/nr_ext_inp
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates how many external inputs are implemented.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/numcidc
> > +What: /sys/bus/coresight/devices/etm<N>/numcidc
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of Context ID comparators that are
> > available for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/numvmidc
> > +What: /sys/bus/coresight/devices/etm<N>/numvmidc
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of VMID comparators that are available
> > for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
> > +What: /sys/bus/coresight/devices/etm<N>/nrseqstate
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of sequencer states that are
> > implemented.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_resource
> > +What: /sys/bus/coresight/devices/etm<N>/nr_resource
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of resource selection pairs that are
> > available for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
> > +What: /sys/bus/coresight/devices/etm<N>/nr_ss_cmp
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Indicates the number of single-shot comparator controls that
> > are available for tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/reset
> > +What: /sys/bus/coresight/devices/etm<N>/reset
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (W) Cancels all configuration on a trace unit and set it back
> > to its boot configuration.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mode
> > +What: /sys/bus/coresight/devices/etm<N>/mode
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -91,302 +91,349 @@ Description: (RW) Controls various modes supported by this ETM, for example
> > P0 instruction tracing, branch broadcast, cycle counting and
> > context ID tracing.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/pe
> > +What: /sys/bus/coresight/devices/etm<N>/pe
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls which PE to trace.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/event
> > +What: /sys/bus/coresight/devices/etm<N>/event
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls the tracing of arbitrary events from bank 0 to 3.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/event_instren
> > +What: /sys/bus/coresight/devices/etm<N>/event_instren
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls the behavior of the events in bank 0 to 3.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/event_ts
> > +What: /sys/bus/coresight/devices/etm<N>/event_ts
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls the insertion of global timestamps in the trace
> > streams.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/syncfreq
> > +What: /sys/bus/coresight/devices/etm<N>/syncfreq
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls how often trace synchronization requests occur.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
> > +What: /sys/bus/coresight/devices/etm<N>/cyc_threshold
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Sets the threshold value for cycle counting.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
> > +What: /sys/bus/coresight/devices/etm<N>/bb_ctrl
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls which regions in the memory map are enabled to
> > use branch broadcasting.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/event_vinst
> > +What: /sys/bus/coresight/devices/etm<N>/event_vinst
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls instruction trace filtering.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
> > +What: /sys/bus/coresight/devices/etm<N>/s_exlevel_vinst
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) In Secure state, each bit controls whether instruction
> > tracing is enabled for the corresponding exception level.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
> > +What: /sys/bus/coresight/devices/etm<N>/ns_exlevel_vinst
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) In non-secure state, each bit controls whether instruction
> > tracing is enabled for the corresponding exception level.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_idx
> > +What: /sys/bus/coresight/devices/etm<N>/addr_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which address comparator or pair (of comparators) to
> > work with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
> > +What: /sys/bus/coresight/devices/etm<N>/addr_instdatatype
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls what type of comparison the trace unit performs.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_single
> > +What: /sys/bus/coresight/devices/etm<N>/addr_single
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Used to setup single address comparator values.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_range
> > +What: /sys/bus/coresight/devices/etm<N>/addr_range
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Used to setup address range comparator values.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_idx
> > +What: /sys/bus/coresight/devices/etm<N>/seq_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which sequensor.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_state
> > +What: /sys/bus/coresight/devices/etm<N>/seq_state
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Use this to set, or read, the sequencer state.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_event
> > +What: /sys/bus/coresight/devices/etm<N>/seq_event
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Moves the sequencer state to a specific state.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
> > +What: /sys/bus/coresight/devices/etm<N>/seq_reset_event
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Moves the sequencer to state 0 when a programmed event
> > occurs.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
> > +What: /sys/bus/coresight/devices/etm<N>/cntr_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which counter unit to work with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
> > +What: /sys/bus/coresight/devices/etm<N>/cntrldvr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) This sets or returns the reload count value of the
> > specific counter.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_val
> > +What: /sys/bus/coresight/devices/etm<N>/cntr_val
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) This sets or returns the current count value of the
> > specific counter.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
> > +What: /sys/bus/coresight/devices/etm<N>/cntr_ctrl
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls the operation of the selected counter.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/res_idx
> > +What: /sys/bus/coresight/devices/etm<N>/res_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which resource selection unit to work with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
> > +What: /sys/bus/coresight/devices/etm<N>/res_ctrl
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Controls the selection of the resources in the trace unit.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
> > +What: /sys/bus/coresight/devices/etm<N>/ctxid_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which context ID comparator to work with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
> > +What: /sys/bus/coresight/devices/etm<N>/ctxid_pid
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Get/Set the context ID comparator value to trigger on.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
> > +What: /sys/bus/coresight/devices/etm<N>/ctxid_masks
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Mask for all 8 context ID comparator value
> > registers (if implemented).
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
> > +What: /sys/bus/coresight/devices/etm<N>/vmid_idx
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Select which virtual machine ID comparator to work with.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_val
> > +What: /sys/bus/coresight/devices/etm<N>/vmid_val
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Get/Set the virtual machine ID comparator value to
> > trigger on.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
> > +What: /sys/bus/coresight/devices/etm<N>/vmid_masks
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (RW) Mask for all 8 virtual machine ID comparator value
> > registers (if implemented).
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
> > +What: /sys/bus/coresight/devices/etm<N>/addr_exlevel_s_ns
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (RW) Set the Exception Level matching bits for secure and
> > + non-secure exception levels.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/vinst_pe_cmp_start_stop
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (RW) Access the start stop control register for PE input
> > + comparators.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/addr_cmp_view
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (R) Print the current settings for the selected address
> > + comparator.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/sshot_idx
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (RW) Select the single shot control register to access.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/sshot_ctrl
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (RW) Access the selected single shot control register.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/sshot_status
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (R) Print the current value of the selected single shot
> > + status register.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/sshot_pe_ctrl
> > +Date: August 2019
> > +KernelVersion: 5.4
> > +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > +Description: (RW) Access the selected single show PE comparator control
> > + register.
> > +
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcoslsr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the OS Lock Status Register (0x304).
> > The value it taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdcr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Power Down Control Register
> > (0x310). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdsr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Power Down Status Register
> > (0x314). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trclsr
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the SW Lock Status Register
> > (0xFB4). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcauthstatus
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Authentication Status Register
> > (0xFB8). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevid
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Device ID Register
> > (0xFC8). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Device Type Register
> > (0xFCC). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr0
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Peripheral ID0 Register
> > (0xFE0). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr1
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Peripheral ID1 Register
> > (0xFE4). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr2
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Peripheral ID2 Register
> > (0xFE8). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr3
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the Peripheral ID3 Register
> > (0xFEC). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcconfig
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcconfig
> > Date: February 2016
> > KernelVersion: 4.07
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the trace configuration register
> > (0x010) as currently set by SW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trctraceid
> > +What: /sys/bus/coresight/devices/etm<N>/mgmt/trctraceid
> > Date: February 2016
> > KernelVersion: 4.07
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Print the content of the trace ID register (0x040).
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr0
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns the tracing capabilities of the trace unit (0x1E0).
> > The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr1
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns the tracing capabilities of the trace unit (0x1E4).
> > The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr2
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -394,7 +441,7 @@ Description: (R) Returns the maximum size of the data value, data address,
> > VMID, context ID and instuction address in the trace unit
> > (0x1E8). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -403,42 +450,42 @@ Description: (R) Returns the value associated with various resources
> > architecture specification for more details (0x1E8).
> > The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr4
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns how many resources the trace unit supports (0x1F0).
> > The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr5
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns how many resources the trace unit supports (0x1F4).
> > The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr8
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns the maximum speculation depth of the instruction
> > trace stream. (0x180). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr9
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns the number of P0 right-hand keys that the trace unit
> > can use (0x184). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr10
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Description: (R) Returns the number of P1 right-hand keys that the trace unit
> > can use (0x188). The value is taken directly from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr11
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -446,7 +493,7 @@ Description: (R) Returns the number of special P1 right-hand keys that the
> > trace unit can use (0x18C). The value is taken directly from
> > the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr12
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > @@ -454,7 +501,7 @@ Description: (R) Returns the number of conditional P1 right-hand keys that
> > the trace unit can use (0x190). The value is taken directly
> > from the HW.
> >
> > -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
> > +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr13
> > Date: April 2015
> > KernelVersion: 4.01
> > Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> > diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt
> > similarity index 100%
> > rename from Documentation/trace/coresight-cpu-debug.txt
> > rename to Documentation/trace/coresight/coresight-cpu-debug.txt
> > diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.txt b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > new file mode 100644
> > index 000000000000..72e81bbbef43
> > --- /dev/null
> > +++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> > @@ -0,0 +1,459 @@
> > +ETMv4 sysfs linux driver programming reference - v2.
> > +====================================================
> > +
> > +Supplement to existing ETMv4 driver documentation.
> > +
> > +Sysfs files and directories
> > +---------------------------
> > +
> > +Root: /sys/bus/coresight/devices/etm<N>
> > +
> > +
> > +The following paragraphs explain the association between sysfs files and the
> > +ETMv4 registers that they effect. Note the register names are given without
> > +the ‘TRC’ prefix.
> > +
> > +File : mode (rw)
> > +Trace Registers : {CONFIGR + others}
> > +Notes : Bit select trace features. See ‘mode’ section below. Bits
> > + in this will cause equivalent programming of trace config and
> > + other registers to enable the features requested.
> > +Syntax & eg : 'echo bitfield > mode'
> > + bitfield up to 32 bits setting trace features.
> > +Example : $> echo 0x > mode
> > +
> > +File : reset (wo)
> > +Trace Registers : All
> > +Notes : Reset all programming to trace nothing / no logic programmed.
> > +Syntax : 'echo 1 > reset'
> > +
> > +File : enable_source (wo)
> > +Trace Registers : PRGCTLR, All hardware regs.
> > +Notes : >0: Programs up the hardware with the current values held in
> > + the driver and enables trace.
> > + 0: disable trace hardware.
> > +Syntax : 'echo 1 > enable_source'
> > +
> > +File : cpu (ro)
> > +Trace Registers : None.
> > +Notes : CPU ID that this ETM is attached to.
> > +Example :$> cat cpu
> > + $> 0
> > +
> > +File : addr_idx (rw)
> > +Trace Registers : None.
> > +Notes : Virtual register to index address comparator and range
> > + features. Set index for first of the pair in a range.
> > +Syntax : 'echo idx > addr_idx'
> > + Where idx < nr_addr_cmp x 2
> > +
> > +File : addr_range (rw)
> > +Trace Registers : ACVR[idx, idx+1], VIIECTLR
> > +Notes : Pair of addresses for a range selected by addr_idx. Include
> > + / exclude according to the optional parameter, or if omitted
> > + uses the current ‘mode’ setting. Select comparator range in
> > + control register. Error if index is odd value.
> > +Depends : mode, addr_idx
> > +Syntax : 'echo addr1 addr2 [exclude] > addr_range'
> > + Where addr1 and addr2 define the range and addr1 < addr2.
> > + Optional exclude value - 0 for include, 1 for exclude.
> > +Example : $> echo 0x0000 0x2000 0 > addr_range
> > +
> > +File : addr_single (rw)
> > +Trace Registers : ACVR[idx]
> > +Notes : Set a single address comparator according to addr_idx. This
> > + is used if the address comparator is used as part of event
> > + generation logic etc.
> > +Depends : addr_idx
> > +Syntax : 'echo addr1 > addr_single'
> > +
> > +File : addr_start (rw)
> > +Trace Registers : ACVR[idx], VISSCTLR
> > +Notes : Set a trace start address comparator according to addr_idx.
> > + Select comparator in control register.
> > +Depends : addr_idx
> > +Syntax : 'echo addr1 > addr_start'
> > +
> > +File : addr_stop (rw)
> > +Trace Registers : ACVR[idx], VISSCTLR
> > +Notes : Set a trace stop address comparator according to addr_idx.
> > + Select comparator in control register.
> > +Depends : addr_idx
> > +Syntax : 'echo addr1 > addr_stop'
> > +
> > +File : addr_context (rw)
> > +Trace Registers : ACATR[idx,{6:4}]
> > +Notes : Link context ID comparator to address comparator addr_idx
> > +Depends : addr_idx.
> > +Syntax : 'echo ctxt_idx > addr_context'
> > + Where ctxt_idx is the index of the linked context id / vmid
> > + comparator.
> > +
> > +File : addr_ctxtype (rw)
> > +Trace Registers : ACATR[idx,{3:2}]
> > +Notes : Input value string. Set type for linked context ID comparator
> > +Depends : addr_idx
> > +Syntax : 'echo type > addr_ctxtype'
> > + Type one of {all, vmid, ctxid, none}
> > +Example : $> echo ctxid > addr_ctxtype
> > +
> > +File : addr_exlevel_s_ns (rw)
> > +Trace Registers : ACATR[idx,{14:8}]
> > +Notes : Set the ELx secure and non-secure matching bits for the
> > + selected address comparator
> > +Depends : addr_idx
> > +Syntax : 'echo val > addr_exlevel_s_ns'
> > + val is a 7 bit value for exception levels to exclude. Input
> > + value shifted to correct bits in register.
> > +Example : $> echo 0x4F > addr_exlevel_s_ns
> > +
> > +File : addr_instdatatype (rw)
> > +Trace Registers : ACATR[idx,{1:0}]
> > +Notes : Set the comparator address type for matching. Driver only
> > + supports setting instruction address type.
> > +Depends : addr_idx
> > +
> > +File : addr_cmp_view (ro)
> > +Trace Registers : ACVR[idx, idx+1], ACATR[idx], VIIECTLR
> > +Notes : Read the currently selected address comparator. If part of
> > + address range then display both addresses.
> > +Depends : addr_idx
> > +Syntax : 'cat addr_cmp_view'
> > +Example : $> cat addr_cmp_view
> > + addr_cmp[0] range 0x0 0xffffffffffffffff include ctrl(0x4b00)
> > +
> > +File : nr_addr_cmp (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of address comparator pairs
> > +
> > +File : sshot_idx (rw)
> > +Trace Registers : None
> > +Notes : Select single shot register set.
> > +
> > +File : sshot_ctrl (rw)
> > +Trace Registers : SSCCR[idx]
> > +Notes : Access a single shot comparator control register.
> > +Depends : sshot_idx
> > +Syntax : 'echo val > sshot_ctrl'
> > + Writes val into the selected control register.
> > +
> > +File : sshot_status (ro)
> > +Trace Registers : SSCSR[idx]
> > +Notes : Read a single shot comparator status register
> > +Depends : sshot_idx
> > +Syntax : 'cat sshot_status'
> > + Read status.
> > +Example : $> cat sshot_status
> > + 0x1
> > +
> > +File : sshot_pe_ctrl (rw)
> > +Trace Registers : SSPCICR[idx]
> > +Notes : Access a single shot PE comparator input control register.
> > +Depends : sshot_idx
> > +Syntax : echo val > sshot_pe_ctrl
> > + Writes val into the selected control register.
> > +
> > +File : ns_exlevel_vinst (rw)
> > +Trace Registers : VICTLR{23:20}
> > +Notes : Program non-secure exception level filters. Set / clear NS
> > + exception filter bits. Setting ‘1’ excludes trace from the
> > + exception level.
> > +Syntax : 'echo bitfield > ns_exlevel_viinst'
> > + Where bitfield contains bits to set clear for EL0 to EL2
> > +Example : %> echo 0x4 > ns_exlevel_viinst
> > + ; Exclude EL2 NS trace.
> > +
> > +File : vinst_pe_cmp_start_stop (rw)
> > +Trace Registers : VIPCSSCTLR
> > +Notes : Access PE start stop comparator input control registers
> > +
> > +File : bb_ctrl (rw)
> > +Trace Registers : BBCTLR
> > +Notes : Define ranges that Branch Broadcast will operate in.
> > + Default (0x0) is all addresses.
> > +Depends : BB enabled.
> > +
> > +File : cyc_threshold (rw)
> > +Trace Registers : CCCTLR
> > +Notes : Set the threshold for which cycle counts will be emitted.
> > + Error if attempt to set below minimum defined in IDR3, masked
> > + to width of valid bits.
> > +Depends : CC enabled.
> > +
> > +File : syncfreq (rw)
> > +Trace Registers : SYNCPR
> > +Notes : Set trace synchronisation period. Power of 2 value, 0 (off)
> > + or 8-20. Driver defaults to 12 (every 4096 bytes).
> > +
> > +File : cntr_idx (rw)
> > +Trace Registers : none
> > +Notes : Select the counter to access
> > +Syntax : 'echo idx > cntr_idx'
> > + Where idx < nr_cntr
> > +
> > +File : cntr_ctrl (rw)
> > +Trace Registers : CNTCTLR[idx]
> > +Notes : Set counter control value
> > +Depends : cntr_idx
> > +Syntax : 'echo val > cntr_ctrl'
> > + Where val is per ETMv4 spec.
> > +
> > +File : cntrldvr (rw)
> > +Trace Registers : CNTRLDVR[idx]
> > +Notes : Set counter reload value
> > +Depends : cntr_idx
> > +Syntax : 'echo val > cntrldvr'
> > + Where val is per ETMv4 spec.
> > +
> > +File : nr_cntr (ro)
> > +Trace Registers : From IDR5
> > +Notes : Number of counters implemented.
> > +
> > +File : ctxid_idx (rw)
> > +Trace Registers : None
> > +Notes : Select the context ID comparator to access
> > +Syntax : 'echo idx > ctxid_idx'
> > + Where idx < numcidc
> > +
> > +File : ctxid_pid (rw)
> > +Trace Registers : CIDCVR[idx]
> > +Notes : Set the context ID comparator value
> > +Depends : ctxid_idx
> > +
> > +File : ctxid_masks (rw)
> > +Trace Registers : CIDCCTLR0, CIDCCTLR1, CIDCVR<0-7>
> > +Notes : Pair of values to set the byte masks for 1-8 context ID
> > + comparators. Automatically clears masked bytes to 0 in CID
> > + value registers.
> > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > ctxid_masks'
> > + 32 bit values made up of mask bytes, where mN represents a
> > + byte mask value for Ctxt ID comparator N.
> > + Second value not required on systems that have fewer than 4
> > + context ID comparators
> > +
> > +File : numcidc (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of Context ID comparators
> > +
> > +File : vmid_idx (rw)
> > +Trace Registers : None
> > +Notes : Select the VM ID comparator to access.
> > +Syntax : 'echo idx > vmid_idx'
> > + Where idx < numvmidc
> > +
> > +File : vmid_val (rw)
> > +Trace Registers : VMIDCVR[idx]
> > +Notes : Set the VM ID comparator value
> > +Depends : vmid_idx
> > +
> > +File : vmid_masks (rw)
> > +Trace Registers : VMIDCCTLR0, VMIDCCTLR1, VMIDCVR<0-7>
> > +Notes : Pair of values to set the byte masks for 1-8 VM ID
> > + comparators. Automatically clears masked bytes to 0 in VMID
> > + value registers.
> > +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > vmid_masks'
> > + Where mN represents a byte mask value for VMID comparator N.
> > + Second value not required on systems that have fewer than
> > + 4 VMID comparators.
> > +
> > +File : numvmidc (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of VMID comparators
> > +
> > +File : res_idx (rw)
> > +Trace Registers : None.
> > +Notes : Select the resource selector control to access. Must be 2 or
> > + higher as selectors 0 and 1 are hardwired.
> > +Syntax : 'echo idx > res_idx'
> > + Where 2 <= idx < nr_resource x 2
> > +
> > +File : res_ctrl (rw)
> > +Trace Registers : RSCTLR[idx]
> > +Notes : Set resource selector control value. Value per ETMv4 spec.
> > +Depends : res_idx
> > +Syntax : 'echo val > res_cntr'
> > + Where val is per ETMv4 spec.
> > +
> > +File : nr_resource (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of resource selector pairs
> > +
> > +File : event (rw)
> > +Trace Registers : EVENTCTRL0R
> > +Notes : Set up to 4 implemented event fields.
> > +Syntax : 'echo ev3ev2ev1ev0 > event'
> > + Where evN is an 8 bit event field. Up to 4 event fields make up
> > + the 32bit input value. Number of valid fields implementation
> > + dependent defined in IDR0.
> > +
> > +File : event_instren (rw)
> > +Trace Registers : EVENTCTRL1R
> > +Notes : Choose events which insert event packets into trace stream.
> > +Depends : EVENTCTRL0R
> > +Syntax : 'echo bitfield > event_instren'
> > + Where bitfield is up to 4 bits according to number of event
> > + fields.
> > +
> > +File : event_ts (rw)
> > +Trace Registers : TSCTLR
> > +Notes : Set the event that will generate timestamp requests.
> > +Depends : TS activated
> > +Syntax : 'echo evfield > event_ts'
> > + Where evfield is an 8 bit event selector.
> > +
> > +File : seq_idx (rw)
> > +Trace Registers : None
> > +Notes : Sequencer event register select - 0 to 2
> > +
> > +
> > +File : seq_state (rw)
> > +Trace Registers : SEQSTR
> > +Notes : Sequencer current state - 0 to 3.
> > +
> > +File : seq_event (rw)
> > +Trace Registers : SEQEVR[idx]
> > +Notes : State transition event registers
> > +Depends : seq_idx
> > +Syntax : 'echo evBevF > seq_event'
> > + Where evBevF is a 16 bit value made up of two event selectors,
> > + evB - back, evF - forwards.
> > +
> > +File : seq_reset_event (rw)
> > +Trace Registers : SEQRSTEVR
> > +Notes : Sequencer reset event
> > +Syntax : 'echo evfield > seq_reset_event'
> > + Where evfield is an 8 bit event selector.
> > +
> > +File : nrseqstate (ro)
> > +Trace Registers : From IDR5
> > +Notes : Number of sequencer states (0 or 4)
> > +
> > +File : nr_pe_cmp (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of PE comparator inputs
> > +
> > +File : nr_ext_inp (ro)
> > +Trace Registers : From IDR5
> > +Notes : Number of external inputs
> > +
> > +File : nr_ss_cmp (ro)
> > +Trace Registers : From IDR4
> > +Notes : Number of Single Shot control registers
> > +
> > +Note: When programming any address comparator the driver will tag the
> > +comparator with a type used - i.e. RANGE, SINGLE, START, STOP. Once this tag
> > +is set, then only the values can be changed using the same sysfs file / type
> > +used to program it.
> > +
> > +Thus:-
> > +% echo 0 > addr_idx ; select address comparator 0
> > +% echo 0x1000 0x5000 0 > addr_range ; set address range on comparators 0 and 1.
> > +% echo 0x2000 > addr_start ; this will error as comparator 0 is a
> > + ; range comparator
> > +% echo 2 > addr_idx ; select address comparator 2
> > +% echo 0x2000 > addr_start ; this is OK as comparator 2 is unused,
> > +% echo 0x3000 > addr_stop ; this will error as comparator 2 a start
> > + ; address comparator
> > +% echo 2 > addr_idx ; select address comparator 3
> > +% echo 0x3000 > addr_stop ; this is OK
> > +
> > +To remove programming on all the comparators (and all the other hardware) use
> > +the reset parameter:
> > +
> > +% echo 1 > reset
> > +
> > +The ‘mode’ sysfs parameter.
> > +---------------------------
> > +
> > +This is a bitfield selection parameter that sets the overall trace mode for the
> > +ETM. The table below describes the bits, using the defines from the driver
> > +source file, along with a description of the feature these represent. Many
> > +features are optional and therefore dependent on implementation in the
> > +hardware.
> > +
> > +Bit assignements shown below:-
> > +
> > +bit (0) : #define ETM_MODE_EXCLUDE
> > +description : This is the default value for the include / exclude function when
> > + setting address ranges. Set 1 for exclude range. When the mode
> > + parameter is set this value is applied to the currently indexed
> > + address range.
> > +
> > +bit (4) : #define ETM_MODE_BB
> > +description : Set to enable branch broadcast if supported in hardware [IDR0].
> > +
> > +bit (5) : #define ETMv4_MODE_CYCACC
> > +description : Set to enable cycle accurate trace if supported [IDR0].
> > +
> > +bit (6) : ETMv4_MODE_CTXID
> > +description : Set to enable context ID tracing if supported in hardware [IDR2].
> > +
> > +bit (7) : ETM_MODE_VMID
> > +description : Set to enable virtual machine ID tracing if supported [IDR2].
> > +
> > +bit (11) : ETMv4_MODE_TIMESTAMP
> > +description : Set to enable timestamp generation if supported [IDR0].
> > +
> > +bit (12) : ETM_MODE_RETURNSTACK
> > +description : Set to enable trace return stack use if supported [IDR0].
> > +
> > +bit (13-14) : ETM_MODE_QELEM(val)
> > +description : ‘val’ determines level of Q element support enabled if
> > + implemented by the ETM [IDR0]
> > +
> > +bit (19) : ETM_MODE_ATB_TRIGGER
> > +description : Set to enable the ATBTRIGGER bit in the event control register
> > + [EVENTCTLR1] if supported [IDR5].
> > +
> > +bit (20) : ETM_MODE_LPOVERRIDE
> > +description : Set to enable the LPOVERRIDE bit in the event control register
> > + [EVENTCTLR1], if supported [IDR5].
> > +
> > +bit (21) : ETM_MODE_ISTALL_EN
> > +description : Set to enable the ISTALL bit in the stall control register
> > + [STALLCTLR]
> > +
> > +bit (23) : ETM_MODE_INSTPRIO
> > +description : Set to enable the INSTPRIORITY bit in the stall control register
> > + [STALLCTLR] , if supported [IDR0].
> > +
> > +bit (24) : ETM_MODE_NOOVERFLOW
> > +description : Set to enable the NOOVERFLOW bit in the stall control register
> > + [STALLCTLR], if supported [IDR3].
> > +
> > +bit (25) : ETM_MODE_TRACE_RESET
> > +description : Set to enable the TRCRESET bit in the viewinst control register
> > + [VICTLR] , if supported [IDR3].
> > +
> > +bit (26) : ETM_MODE_TRACE_ERR
> > +description : Set to enable the TRCCTRL bit in the viewinst control register
> > + [VICTLR].
> > +
> > +bit (27) : ETM_MODE_VIEWINST_STARTSTOP
> > +description : Set the initial state value of the ViewInst start / stop logic
> > + in the viewinst control register [VICTLR]
> > +
> > +bit (30) : ETM_MODE_EXCL_KERN
> > +description : Set default trace setup to exclude kernel mode trace (see note a)
> > +
> > +bit (31) : ETM_MODE_EXCL_USER
> > +description : Set default trace setup to exclude user space trace (see note a)
> > +
> > +Note a) On startup the ETM is programmed to trace the complete address space
> > +using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> > +set EL exclude bits for NS state in either user space (EL0) or kernel space
> > +(EL1) in the address range comparator. (the default setting excludes all
> > +secure EL, and NS EL2)
> > +
> > +Once the reset parameter has been used, and/or custom programming has been
> > +implemented - using these bits will result in the EL bits for address
> > +comparator 0 being set in the same way.
> > +
> > +Note b) Bits 2-3, 8-10, 15-16, 18, 22, control features that only work with
> > +data trace. As A profile data trace is architecturally prohibited in ETMv4,
> > +these have been omitted here. Possible uses could be where a kernel has
> > +support for control of R or M profile infrastructure as part of a heterogeneous
> > +system.
> > +
> > +Bits 17, 28-29 are unused.
> > +
> > diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight/coresight.txt
> > similarity index 100%
> > rename from Documentation/trace/coresight.txt
> > rename to Documentation/trace/coresight/coresight.txt
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 783569e3c4b4..777b77fde29b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1582,8 +1582,7 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
> > L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> > S: Maintained
> > F: drivers/hwtracing/coresight/*
> > -F: Documentation/trace/coresight.txt
> > -F: Documentation/trace/coresight-cpu-debug.txt
> > +F: Documentation/trace/coresight/*
> > F: Documentation/devicetree/bindings/arm/coresight.txt
> > F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> > F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
> > --
> > 2.17.1
> >
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: khadas-vim3: add support for the SM1 based VIM3L
From: Neil Armstrong @ 2019-08-28 14:18 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141816.16328-1-narmstrong@baylibre.com>
Add the Amlogic SM1 based Khadas VIM3L, sharing all the same features
as the G12B based VIM3, but:
- a different DVFS support since only a single cluster is available
- audio is still not available on SM1
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../dts/amlogic/meson-sm1-khadas-vim3l.dts | 70 +++++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index edbf128e7707..84afecba9ec0 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
new file mode 100644
index 000000000000..5233bd7cacfb
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include "meson-khadas-vim3.dtsi"
+
+/ {
+ compatible = "khadas,vim3l", "amlogic,sm1";
+ model = "Khadas VIM3L";
+
+ vddcpu: regulator-vddcpu {
+ /*
+ * Silergy SY8030DEC Regulator.
+ */
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <690000>;
+ regulator-max-microvolt = <1050000>;
+
+ vin-supply = <&vsys_3v3>;
+
+ pwms = <&pwm_AO_cd 1 1250 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu1 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU1_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu2 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU2_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu3 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU3_CLK>;
+ clock-latency = <50000>;
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_d_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin1";
+ status = "okay";
+};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/3] arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
From: Neil Armstrong @ 2019-08-28 14:18 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141816.16328-1-narmstrong@baylibre.com>
To prepare support of the Amlogic SM1 based Khadas VIM3, move the non-G12B
specific nodes (all except DVFS and Audio) to a new meson-khadas-vim3.dtsi
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../amlogic/meson-g12b-a311d-khadas-vim3.dts | 1 +
.../dts/amlogic/meson-g12b-khadas-vim3.dtsi | 355 -----------------
.../amlogic/meson-g12b-s922x-khadas-vim3.dts | 1 +
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 360 ++++++++++++++++++
4 files changed, 362 insertions(+), 355 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
index 73128ed24361..3a6a1e0c1e32 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "meson-g12b-a311d.dtsi"
+#include "meson-khadas-vim3.dtsi"
#include "meson-g12b-khadas-vim3.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
index 9c3ca2edc725..554863429aa6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
@@ -5,116 +5,9 @@
* Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
*/
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/gpio/meson-g12a-gpio.h>
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
/ {
- model = "Khadas VIM3";
-
- aliases {
- serial0 = &uart_AO;
- ethernet0 = ðmac;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
- adc-keys {
- compatible = "adc-keys";
- io-channels = <&saradc 2>;
- io-channel-names = "buttons";
- keyup-threshold-microvolt = <1710000>;
-
- button-function {
- label = "Function";
- linux,code = <KEY_FN>;
- press-threshold-microvolt = <10000>;
- };
- };
-
- leds {
- compatible = "gpio-leds";
-
- white {
- label = "vim3:white:sys";
- gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "heartbeat";
- };
-
- red {
- label = "vim3:red";
- gpios = <&gpio_expander 5 GPIO_ACTIVE_LOW>;
- };
- };
-
- emmc_pwrseq: emmc-pwrseq {
- compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
- };
-
- gpio-keys-polled {
- compatible = "gpio-keys-polled";
- poll-interval = <100>;
-
- power-button {
- label = "power";
- linux,code = <KEY_POWER>;
- gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_LOW>;
- };
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
- clocks = <&wifi32k>;
- clock-names = "ext_clock";
- };
-
- dc_in: regulator-dc_in {
- compatible = "regulator-fixed";
- regulator-name = "DC_IN";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- };
-
- vcc_5v: regulator-vcc_5v {
- compatible = "regulator-fixed";
- regulator-name = "VCC_5V";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&dc_in>;
-
- gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
- enable-active-high;
- };
-
- vcc_1v8: regulator-vcc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- vcc_3v3: regulator-vcc_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vsys_3v3>;
- regulator-always-on;
- /* FIXME: actually controlled by VDDCPU_B_EN */
- };
-
vddcpu_a: regulator-vddcpu-a {
/*
* MP8756GD Regulator.
@@ -153,62 +46,6 @@
regulator-always-on;
};
- vddao_1v8: regulator-vddao_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VDDIO_AO1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vsys_3v3>;
- regulator-always-on;
- };
-
- emmc_1v8: regulator-emmc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "EMMC_AO1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- vsys_3v3: regulator-vsys_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VSYS_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&dc_in>;
- regulator-always-on;
- };
-
- usb_pwr: regulator-usb_pwr {
- compatible = "regulator-fixed";
- regulator-name = "USB_PWR";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc_5v>;
-
- gpio = <&gpio GPIOA_6 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- hdmi-connector {
- compatible = "hdmi-connector";
- type = "a";
-
- port {
- hdmi_connector_in: endpoint {
- remote-endpoint = <&hdmi_tx_tmds_out>;
- };
- };
- };
-
- wifi32k: wifi32k {
- compatible = "pwm-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
- };
-
sound {
compatible = "amlogic,axg-sound-card";
model = "G12A-KHADAS-VIM3";
@@ -269,20 +106,6 @@
status = "okay";
};
-&cec_AO {
- pinctrl-0 = <&cec_ao_a_h_pins>;
- pinctrl-names = "default";
- status = "disabled";
- hdmi-phandle = <&hdmi_tx>;
-};
-
-&cecb_AO {
- pinctrl-0 = <&cec_ao_b_h_pins>;
- pinctrl-names = "default";
- status = "okay";
- hdmi-phandle = <&hdmi_tx>;
-};
-
&clkc_audio {
status = "okay";
};
@@ -329,31 +152,6 @@
clock-latency = <50000>;
};
-&ext_mdio {
- external_phy: ethernet-phy@0 {
- /* Realtek RTL8211F (0x001cc916) */
- reg = <0>;
- max-speed = <1000>;
-
- interrupt-parent = <&gpio_intc>;
- /* MAC_INTR on GPIOZ_14 */
- interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-ðmac {
- pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
- pinctrl-names = "default";
- status = "okay";
- phy-mode = "rgmii";
- phy-handle = <&external_phy>;
- amlogic,tx-delay-ns = <2>;
-};
-
-&frddr_a {
- status = "okay";
-};
-
&frddr_b {
status = "okay";
};
@@ -362,46 +160,6 @@
status = "okay";
};
-&hdmi_tx {
- status = "okay";
- pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
- pinctrl-names = "default";
- hdmi-supply = <&vcc_5v>;
-};
-
-&hdmi_tx_tmds_port {
- hdmi_tx_tmds_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
-};
-
-&i2c_AO {
- status = "okay";
- pinctrl-0 = <&i2c_ao_sck_pins>, <&i2c_ao_sda_pins>;
- pinctrl-names = "default";
-
- gpio_expander: gpio-controller@20 {
- compatible = "ti,tca6408";
- reg = <0x20>;
- vcc-supply = <&vcc_3v3>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- rtc@51 {
- compatible = "haoyu,hym8563";
- reg = <0x51>;
- #clock-cells = <0>;
- };
-};
-
-&ir {
- status = "okay";
- pinctrl-0 = <&remote_input_ao_pins>;
- pinctrl-names = "default";
- linux,rc-map-name = "rc-khadas";
-};
-
&pwm_ab {
pinctrl-0 = <&pwm_a_e_pins>;
pinctrl-names = "default";
@@ -418,81 +176,6 @@
status = "okay";
};
-&pwm_ef {
- status = "okay";
- pinctrl-0 = <&pwm_e_pins>;
- pinctrl-names = "default";
-};
-
-&saradc {
- status = "okay";
- vref-supply = <&vddao_1v8>;
-};
-
-/* SDIO */
-&sd_emmc_a {
- status = "okay";
- pinctrl-0 = <&sdio_pins>;
- pinctrl-1 = <&sdio_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
- #address-cells = <1>;
- #size-cells = <0>;
-
- bus-width = <4>;
- cap-sd-highspeed;
- sd-uhs-sdr50;
- max-frequency = <100000000>;
-
- non-removable;
- disable-wp;
-
- mmc-pwrseq = <&sdio_pwrseq>;
-
- vmmc-supply = <&vsys_3v3>;
- vqmmc-supply = <&vddao_1v8>;
-
- brcmf: wifi@1 {
- reg = <1>;
- compatible = "brcm,bcm4329-fmac";
- };
-};
-
-/* SD card */
-&sd_emmc_b {
- status = "okay";
- pinctrl-0 = <&sdcard_c_pins>;
- pinctrl-1 = <&sdcard_clk_gate_c_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <4>;
- cap-sd-highspeed;
- max-frequency = <50000000>;
- disable-wp;
-
- cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
- vmmc-supply = <&vsys_3v3>;
- vqmmc-supply = <&vsys_3v3>;
-};
-
-/* eMMC */
-&sd_emmc_c {
- status = "okay";
- pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
- pinctrl-1 = <&emmc_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <8>;
- cap-mmc-highspeed;
- mmc-ddr-1_8v;
- mmc-hs200-1_8v;
- max-frequency = <200000000>;
- disable-wp;
-
- mmc-pwrseq = <&emmc_pwrseq>;
- vmmc-supply = <&vcc_3v3>;
- vqmmc-supply = <&emmc_1v8>;
-};
-
&tdmif_b {
status = "okay";
};
@@ -504,41 +187,3 @@
&tohdmitx {
status = "okay";
};
-
-&uart_A {
- status = "okay";
- pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
- pinctrl-names = "default";
- uart-has-rtscts;
-
- bluetooth {
- compatible = "brcm,bcm43438-bt";
- shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
- max-speed = <2000000>;
- clocks = <&wifi32k>;
- clock-names = "lpo";
- };
-};
-
-&uart_AO {
- status = "okay";
- pinctrl-0 = <&uart_ao_a_pins>;
- pinctrl-names = "default";
-};
-
-&usb2_phy0 {
- phy-supply = <&dc_in>;
-};
-
-&usb2_phy1 {
- phy-supply = <&usb_pwr>;
-};
-
-&usb3_pcie_phy {
- phy-supply = <&usb_pwr>;
-};
-
-&usb {
- status = "okay";
- dr_mode = "peripheral";
-};
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
index 6bcf972b8bfa..b73deb282120 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "meson-g12b-s922x.dtsi"
+#include "meson-khadas-vim3.dtsi"
#include "meson-g12b-khadas-vim3.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
new file mode 100644
index 000000000000..8647da7d6609
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
+ */
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ model = "Khadas VIM3";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 2>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1710000>;
+
+ button-function {
+ label = "Function";
+ linux,code = <KEY_FN>;
+ press-threshold-microvolt = <10000>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ white {
+ label = "vim3:white:sys";
+ gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ red {
+ label = "vim3:red";
+ gpios = <&gpio_expander 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ power-button {
+ label = "power";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ dc_in: regulator-dc_in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vcc_5v: regulator-vcc_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-high;
+ };
+
+ vcc_1v8: regulator-vcc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ regulator-always-on;
+ /* FIXME: actually controlled by VDDCPU_B_EN */
+ };
+
+ vddao_1v8: regulator-vddao_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vsys_3v3>;
+ regulator-always-on;
+ };
+
+ emmc_1v8: regulator-emmc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EMMC_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ vsys_3v3: regulator-vsys_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VSYS_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ usb_pwr: regulator-usb_pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v>;
+
+ gpio = <&gpio GPIOA_6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&ext_mdio {
+ external_phy: ethernet-phy@0 {
+ /* Realtek RTL8211F (0x001cc916) */
+ reg = <0>;
+ max-speed = <1000>;
+
+ interrupt-parent = <&gpio_intc>;
+ /* MAC_INTR on GPIOZ_14 */
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+ðmac {
+ pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+};
+
+&hdmi_tx {
+ status = "okay";
+ pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
+ pinctrl-names = "default";
+ hdmi-supply = <&vcc_5v>;
+};
+
+&hdmi_tx_tmds_port {
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+};
+
+&i2c_AO {
+ status = "okay";
+ pinctrl-0 = <&i2c_ao_sck_pins>, <&i2c_ao_sda_pins>;
+ pinctrl-names = "default";
+
+ gpio_expander: gpio-controller@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ vcc-supply = <&vcc_3v3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+ linux,rc-map-name = "rc-khadas";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vddao_1v8>;
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vsys_3v3>;
+ vqmmc-supply = <&vddao_1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vsys_3v3>;
+ vqmmc-supply = <&vsys_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&emmc_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ };
+};
+
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
+
+&usb2_phy0 {
+ phy-supply = <&dc_in>;
+};
+
+&usb2_phy1 {
+ phy-supply = <&usb_pwr>;
+};
+
+&usb3_pcie_phy {
+ phy-supply = <&usb_pwr>;
+};
+
+&usb {
+ status = "okay";
+ dr_mode = "peripheral";
+};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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