* [PATCH RESEND] drm/meson: vclk: use the correct G12A frac max value
From: Neil Armstrong @ 2019-08-28 13:23 UTC (permalink / raw)
To: dri-devel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
When calculating the HDMI PLL settings for a DMT mode PHY frequency,
use the correct max fractional PLL value for G12A VPU.
With this fix, we can finally setup the 1024x768-60 mode.
Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Fixed typo in commit log, 1024x76 => 1024x768
drivers/gpu/drm/meson/meson_vclk.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c b/drivers/gpu/drm/meson/meson_vclk.c
index ac491a781952..f690793ae2d5 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -638,13 +638,18 @@ static bool meson_hdmi_pll_validate_params(struct meson_drm *priv,
if (frac >= HDMI_FRAC_MAX_GXBB)
return false;
} else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) ||
- meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL) ||
- meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
+ meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL)) {
/* Empiric supported min/max dividers */
if (m < 106 || m > 247)
return false;
if (frac >= HDMI_FRAC_MAX_GXL)
return false;
+ } else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
+ /* Empiric supported min/max dividers */
+ if (m < 106 || m > 247)
+ return false;
+ if (frac >= HDMI_FRAC_MAX_G12A)
+ return false;
}
return true;
--
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
* Re: [linux-sunxi] Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Chen-Yu Tsai @ 2019-08-28 13:29 UTC (permalink / raw)
To: Alejandro González
Cc: Ulf Hansson, Greg KH, Linus Walleij, linux-mmc,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-sunxi,
Thomas Gleixner, Linux ARM
In-Reply-To: <CACRpkdazfe3gJr6Q+X05GzxPuKtUg0M780SPA_oR5bd+-xBPvA@mail.gmail.com>
On Wed, Aug 28, 2019 at 8:52 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sun, Aug 25, 2019 at 5:06 PM Alejandro González
> <alejandro.gonzalez.correo@gmail.com> wrote:
>
> > Jernej Skrabec compared the BSP driver with this
> > driver, and found that the BSP driver configures pinctrl to operate at
> > 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
> > the mainline kernel lacks any mechanism to switch voltages dynamically.
AFAIK The Pine H64 does not have the ability to switch I/O voltages. It is
fixed to either 1.8V (the default based on the schematics) or 3.3V.
> (...)
> > the kernel lacks the required
> > dynamic pinctrl control for now
>
> This is not a pin control thing, the I/O voltage level is usually
> controlled by a regulator called VCCQ, if the selection of the
> voltage rails is inside the pin control registers, see the solution
> in drivers/pinctrl/sh-pfc/pfc-sh73a0.c where we simply provide
> a regulator from inside the pinctrl driver to make things easy
> for the MMC core. Do this thing!
Or if it's simply voltage trimming for input, the a80 pinctrl driver
has something similar. Basically it registers a notifier on the
voltage rail supplying a set of pins, and toggles the register
to match the external voltage provided.
Unfortunately the user manual is quite vague on what it actually is.
> If you don't have time to fix it up properly right now I would slap
> in a big FIXME in the code so people know this needs
> to be fixed properly.
+1
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: ARM_ERRATA_775420: Spelling s/date/data/
From: Geert Uytterhoeven @ 2019-08-28 13:31 UTC (permalink / raw)
To: Russell King, Simon Horman, Catalin Marinas
Cc: Geert Uytterhoeven, linux-kernel, linux-arm-kernel
Caching dates is never a good idea ;-)
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dcf46f0e45c24a5f..eb18279a63027c08 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1040,7 +1040,7 @@ config ARM_ERRATA_775420
depends on CPU_V7
help
This option enables the workaround for the 775420 Cortex-A9 (r2p2,
- r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance
+ r2p6,r2p8,r2p10,r3p0) erratum. In case a data cache maintenance
operation aborts with MMU exception, it might cause the processor
to deadlock. This workaround puts DSB before executing ISB if
an abort may occur on cache maintenance.
--
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: [PATCHv5] drivers/amba: add reset control to amba bus probe
From: Dinh Nguyen @ 2019-08-28 13:34 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: devicetree, daniel.thompson, tony.luck, manivannan.sadhasivam,
keescook, robh, linus.walleij, anton, linux, linux-kernel,
p.zabel, ccross, frowand.list, linux-arm-kernel
In-Reply-To: <30608.1566933924@turing-police>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 8/27/19 2:25 PM, Valdis Kl?tnieks wrote:
> On Mon, 26 Aug 2019 10:42:52 -0500, Dinh Nguyen said:
>> The primecell controller on some SoCs, i.e. SoCFPGA, is held in
>> reset by default. Until recently, the DMA controller was brought
>> out of reset by the bootloader(i.e. U-Boot). But a recent change
>> in U-Boot, the peripherals that are not used are held in reset
>> and are left to Linux to bring them out of reset.
>>
>> Add a mechanism for getting the reset property and de-assert the
>> primecell module from reset if found. This is a not a hard fail
>> if the reset properti is not present in the device tree node, so
>> the driver will continue to probe.
>
> Does this DTRT for both old and new U-Boots? My naive reading of
> this patch
What is a DTRT?
> says on an old U-Boot, we end up attempting to bring it out of
> reset even though they had already been brought out.
>
If the peripheral is already out of reset, de-asserting the reset has
no affect.
Dinh
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEoHhMeiyk5VmwVMwNGZQEC4GjKPQFAl1mgtYACgkQGZQEC4Gj
KPRKMRAArFO9bQ7FCE4oiVgO/sOLm2M/ngGD3Czi6Y8TcAbIk4EylBGVw634Gs4Z
v5vuyxShlfApBb0PqfhLOo5cXrTyMdpWOq9AQ4vEcEU2MPKN8QcyLczvEagyYcwA
ianhTLR21v1Gdfm5MHqpKrNxSrb6Nt6cWmYCXjpabLYZg0gKJnsYl2XheHIdUJ02
kD2P6sQC3mf3OC5Gou4JXZGvDMgEwLG9lHsb7YoFq6tzZW3YQvAi3HcxIZZh4J8b
jFcPR3RxxQgGwESEGDWQu2EzY/d9qStEQ9VYHl/v6QIL77S1oXUAXLbh3e6ZoSgt
M93eK2G9wGCL5JlUbHXQ402OfewHchgQW1bDpjkaZLL+d9jUiGLqALAj0Az2FqX1
HtPPtifB4z6TuaLkxNTZ1Oz7UR0cWtKeSYjsuIwi0XzQMXopgH7oKdzJajNlAfRJ
In6fSVuwp47p43wj2dmUtuCSYvzKTHAg/sVGaufEfsT8ZINSOZJY9ivDqkJIzlDR
nsOclhfOGs5PgL4NPFW5U5O58DzZ5yl9NEotB4ahacuOqJv1PUdT3gABbL5hUogx
QTAPNREbYesG3osFLeEXeachiNChyJ7r+NyWFly7RXA/ukxoer2Rkxt3h0hQib6Q
/jhAsa1ar1NEk8dJJfNO7R5pZkG7ZCbhzuSDKPB2yRZPDeQGol8=
=SFzc
-----END PGP SIGNATURE-----
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Maxime Ripard @ 2019-08-28 13:43 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Ulf Hansson, Alejandro González, Greg KH, Linus Walleij,
linux-mmc, linux-kernel@vger.kernel.org, linux-sunxi,
Thomas Gleixner, Linux ARM
In-Reply-To: <CAGb2v67e8EiS-LUuhAyPc57nWd4iOBEWC_SZbH801Lzi4QWGyg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 867 bytes --]
On Wed, Aug 28, 2019 at 09:29:32PM +0800, Chen-Yu Tsai wrote:
> On Wed, Aug 28, 2019 at 8:52 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Sun, Aug 25, 2019 at 5:06 PM Alejandro González
> > <alejandro.gonzalez.correo@gmail.com> wrote:
> >
> > > Jernej Skrabec compared the BSP driver with this
> > > driver, and found that the BSP driver configures pinctrl to operate at
> > > 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
> > > the mainline kernel lacks any mechanism to switch voltages dynamically.
>
> AFAIK The Pine H64 does not have the ability to switch I/O voltages. It is
> fixed to either 1.8V (the default based on the schematics) or 3.3V.
Should that be handled at the board level then maybe?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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 V9 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Will Deacon @ 2019-08-28 13:44 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828120524.9038-1-qiangqing.zhang@nxp.com>
On Wed, Aug 28, 2019 at 12:07:52PM +0000, Joakim Zhang wrote:
> AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> writes with an ARID or AWID matching filter setting. Granularity is at
> subsystem level. Implementation does not allow filtring between masters
> within a subsystem. Filter is defined with 2 configuration parameters.
>
> --AXI_ID defines AxID matching value
> --AXI_MASKING defines which bits of AxID are meaningful for the matching
> 0：corresponding bit is masked
> 1: corresponding bit is not masked, i.e. used to do the matching
>
> When non-masked bits are matching corresponding AXI_ID bits then counter
> is incremented. This filter allows counting read or write access from a
> subsystem or multiple subsystems.
>
> Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
>
> AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
>
> Read and write AXI ID filter should write same value to DPCR1 if want to
> specify at the same time as this filter is shared between counters.
>
> e.g.
> perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
> perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
>
> NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
> it will be reverted in driver automatically. so that the user can just specify
> axi_id to monitor a specific id, rather than having to specify axi_mask.
> e.g.
> perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Thanks, I've pushed this series out to:
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-next/perf
and plan to send it for 5.4. I did rewrite the commit messages, so please
take a look. I also folded the other two patches together.
Thanks,
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: [linux-sunxi] Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Chen-Yu Tsai @ 2019-08-28 13:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ulf Hansson, Alejandro González, Greg KH, Linus Walleij,
linux-mmc, linux-kernel@vger.kernel.org, linux-sunxi,
Thomas Gleixner, Linux ARM
In-Reply-To: <20190828134334.qzuwodoxmw7ov5yg@flea>
On Wed, Aug 28, 2019 at 9:43 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> On Wed, Aug 28, 2019 at 09:29:32PM +0800, Chen-Yu Tsai wrote:
> > On Wed, Aug 28, 2019 at 8:52 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Sun, Aug 25, 2019 at 5:06 PM Alejandro González
> > > <alejandro.gonzalez.correo@gmail.com> wrote:
> > >
> > > > Jernej Skrabec compared the BSP driver with this
> > > > driver, and found that the BSP driver configures pinctrl to operate at
> > > > 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
> > > > the mainline kernel lacks any mechanism to switch voltages dynamically.
> >
> > AFAIK The Pine H64 does not have the ability to switch I/O voltages. It is
> > fixed to either 1.8V (the default based on the schematics) or 3.3V.
>
> Should that be handled at the board level then maybe?
Yeah. You'd specify which one using vqmmc-supply in the mmc node and
vcc-pc-supply
in the pinctrl node.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv5] drivers/amba: add reset control to amba bus probe
From: Valdis Klētnieks @ 2019-08-28 13:46 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree, daniel.thompson, tony.luck, manivannan.sadhasivam,
keescook, robh, linus.walleij, anton, linux, linux-kernel,
p.zabel, ccross, frowand.list, linux-arm-kernel
In-Reply-To: <46bcf493-9dd6-bf5b-089a-be158739a13f@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 520 bytes --]
On Wed, 28 Aug 2019 08:34:20 -0500, Dinh Nguyen said:
> > Does this DTRT for both old and new U-Boots? My naive reading of
> > this patch
>
> What is a DTRT?
Do The Right Thing, sorry...
> > says on an old U-Boot, we end up attempting to bring it out of
> > reset even though they had already been brought out.
> >
>
> If the peripheral is already out of reset, de-asserting the reset has
> no affect.
OK, thanks. There's been hardware where doing that sort of thing twice will
confuse the device and cause issues.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 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 v3 01/10] KVM: arm64: Document PV-time interface
From: Christoffer Dall @ 2019-08-28 13:49 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Marc Zyngier, Russell King, linux-kernel,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190827085706.GB6541@e113682-lin.lund.arm.com>
On Tue, Aug 27, 2019 at 10:57:06AM +0200, Christoffer Dall wrote:
> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> > Introduce a paravirtualization interface for KVM/arm64 based on the
> > "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
> >
> > This only adds the details about "Stolen Time" as the details of "Live
> > Physical Time" have not been fully agreed.
> >
> > User space can specify a reserved area of memory for the guest and
> > inform KVM to populate the memory with information on time that the host
> > kernel has stolen from the guest.
> >
> > A hypercall interface is provided for the guest to interrogate the
> > hypervisor's support for this interface and the location of the shared
> > memory structures.
> >
> > Signed-off-by: Steven Price <steven.price@arm.com>
> > ---
> > Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
> > 1 file changed, 100 insertions(+)
> > create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
> >
> > diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> > new file mode 100644
> > index 000000000000..1ceb118694e7
> > --- /dev/null
> > +++ b/Documentation/virt/kvm/arm/pvtime.txt
> > @@ -0,0 +1,100 @@
> > +Paravirtualized time support for arm64
> > +======================================
> > +
> > +Arm specification DEN0057/A defined a standard for paravirtualised time
> > +support for AArch64 guests:
> > +
> > +https://developer.arm.com/docs/den0057/a
> > +
> > +KVM/arm64 implements the stolen time part of this specification by providing
> > +some hypervisor service calls to support a paravirtualized guest obtaining a
> > +view of the amount of time stolen from its execution.
> > +
> > +Two new SMCCC compatible hypercalls are defined:
> > +
> > +PV_FEATURES 0xC5000020
> > +PV_TIME_ST 0xC5000022
> > +
> > +These are only available in the SMC64/HVC64 calling convention as
> > +paravirtualized time is not available to 32 bit Arm guests. The existence of
> > +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> > +mechanism before calling it.
> > +
> > +PV_FEATURES
> > + Function ID: (uint32) : 0xC5000020
> > + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> > + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> > + PV-time feature is supported by the hypervisor.
> > +
> > +PV_TIME_ST
> > + Function ID: (uint32) : 0xC5000022
> > + Return value: (int64) : IPA of the stolen time data structure for this
> > + (V)CPU. On failure:
> > + NOT_SUPPORTED (-1)
> > +
> > +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> > +with inner and outer write back caching attributes, in the inner shareable
> > +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> > +meaningfully filled by the hypervisor (see structure below).
> > +
> > +PV_TIME_ST returns the structure for the calling VCPU.
> > +
> > +Stolen Time
> > +-----------
> > +
> > +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> > +
> > + Field | Byte Length | Byte Offset | Description
> > + ----------- | ----------- | ----------- | --------------------------
> > + Revision | 4 | 0 | Must be 0 for version 0.1
> > + Attributes | 4 | 4 | Must be 0
> > + Stolen time | 8 | 8 | Stolen time in unsigned
> > + | | | nanoseconds indicating how
> > + | | | much time this VCPU thread
> > + | | | was involuntarily not
> > + | | | running on a physical CPU.
> > +
> > +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> > +will be present within a reserved region of the normal memory given to the
> > +guest. The guest should not attempt to write into this memory. There is a
> > +structure per VCPU of the guest.
> > +
> > +User space interface
> > +====================
> > +
> > +User space can request that KVM provide the paravirtualized time interface to
> > +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> > +
> > + struct kvm_create_device pvtime_device = {
> > + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> > + .attr = 0,
> > + .flags = 0,
> > + };
> > +
> > + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> > +
> > +Creation of the device should be done after creating the vCPUs of the virtual
> > +machine.
> > +
> > +The IPA of the structures must be given to KVM. This is the base address
> > +of an array of stolen time structures (one for each VCPU). The base address
> > +must be page aligned. The size must be at least 64 * number of VCPUs and be a
> > +multiple of PAGE_SIZE.
> > +
> > +The memory for these structures should be added to the guest in the usual
> > +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
> > +
> > +For example:
> > +
> > + struct kvm_dev_arm_st_region region = {
> > + .gpa = <IPA of guest base address>,
> > + .size = <size in bytes>
> > + };
>
> This feel fragile; how are you handling userspace creating VCPUs after
> setting this up, the GPA overlapping guest memory, etc. Is the
> philosophy here that the VMM can mess up the VM if it wants, but that
> this should never lead attacks on the host (we better hope not) and so
> we don't care?
>
> It seems to me setting the IPA per vcpu throught the VCPU device would
> avoid a lot of these issues. See
> Documentation/virt/kvm/devices/vcpu.txt.
>
>
I discussed this with Marc the other day, and we realized that if we
make the configuration of the IPA per-PE, then a VMM can construct a VM
where these data structures are distributed within the IPA space of a
VM, which could lead to a lower TLB pressure for some
configurations/workloads.
Thanks,
Christoffer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: ux500: Fix up the thermal nodes
From: Linus Walleij @ 2019-08-28 13:52 UTC (permalink / raw)
To: linux-arm-kernel, Ulf Hansson; +Cc: Linus Walleij, Daniel Lezcano
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>;
};
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 {
/*
--
2.21.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 2/2] ARM: dts: ux500: Update thermal zone
From: Linus Walleij @ 2019-08-28 13:52 UTC (permalink / raw)
To: linux-arm-kernel, Ulf Hansson; +Cc: Linus Walleij, Daniel Lezcano
In-Reply-To: <20190828135218.7307-1-linus.walleij@linaro.org>
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>;
+
+ 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>;
+ 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 {
--
2.21.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
* Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Sudeep Holla @ 2019-08-28 13:58 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, Sudeep Holla,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1567004515-3567-2-git-send-email-peng.fan@nxp.com>
On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index 000000000000..f8eb28d5e307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan <peng.fan@nxp.com>
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported.
What do you mean by that ? I would prefer to drop the above line unless
I am missing something. IMO it contradicts the previous statement less
you elaborate more on this.
> However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
I assume you refer to asynchronous communication from OS to firmware in the
above statement and "not asynchronous notification" from firmware to OS.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
Not sure if reference to SCMI is needed at all but I don't have any
objections to it, just thought worth mentioning.
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
Other than the above points, I am fine with it. Once fixed,
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Note I haven't reviewed the yaml scheme, but just binding in general.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
From: Sudeep Holla @ 2019-08-28 14:02 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, Sudeep Holla,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1567004515-3567-3-git-send-email-peng.fan@nxp.com>
On Wed, Aug 28, 2019 at 03:03:02AM +0000, Peng Fan wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> This mailbox driver implements a mailbox which signals transmitted data
> via an ARM smc (secure monitor call) instruction. The mailbox receiver
> is implemented in firmware and can synchronously return data when it
> returns execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs
> which either don't have a separate management processor or on which such
> a core is not available. A user of this mailbox could be the SCP
> interface.
>
> Modified from Andre Przywara's v2 patch
> https://lore.kernel.org/patchwork/patch/812999/
>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/mailbox/Kconfig | 7 ++
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm-smc-mailbox.c | 215 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/mailbox/arm-smc-mailbox.c
>
[...]
> +static int arm_smc_mbox_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mbox_controller *mbox;
> + struct arm_smc_chan_data *chan_data;
> + const char *method;
> + bool mem_trans = false;
> + int ret, i;
> + u32 val;
> +
> + if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
> + if (!val) {
> + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> + return -EINVAL;
> + }
> + } else {
> + return -EINVAL;
> + }
> +
> + if (!of_property_read_string(dev->of_node, "transports", &method)) {
> + if (!strcmp("mem", method)) {
> + mem_trans = true;
> + } else if (!strcmp("reg", method)) {
> + mem_trans = false;
> + } else {
> + dev_warn(dev, "invalid \"transports\" property: %s\n",
> + method);
> +
> + return -EINVAL;
> + }
> + } else {
> + return -EINVAL;
> + }
> +
> + if (!of_property_read_string(dev->of_node, "method", &method)) {
> + if (!strcmp("hvc", method)) {
> + invoke_smc_mbox_fn = __invoke_fn_hvc;
> + } else if (!strcmp("smc", method)) {
> + invoke_smc_mbox_fn = __invoke_fn_smc;
> + } else {
> + dev_warn(dev, "invalid \"method\" property: %s\n",
> + method);
> +
> + return -EINVAL;
> + }
> + } else {
> + return -EINVAL;
> + }
> +
> + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> + if (!mbox)
> + return -ENOMEM;
> +
> + mbox->num_chans = val;
> + mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
> + GFP_KERNEL);
> + if (!mbox->chans)
> + return -ENOMEM;
> +
> + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> + GFP_KERNEL);
> + if (!chan_data)
> + return -ENOMEM;
> +
> + for (i = 0; i < mbox->num_chans; i++) {
> + u32 function_id;
> +
> + ret = of_property_read_u32_index(dev->of_node,
> + "arm,func-ids", i,
> + &function_id);
I missed it in binding but I thought we agreed to make this "arm,func-ids"
a required property and not optional ?
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8] thermal: cpu_cooling: Migrate to using the EM framework
From: Quentin Perret @ 2019-08-28 14:02 UTC (permalink / raw)
To: edubezval, rui.zhang, javi.merino, viresh.kumar, amit.kachhap,
rjw, catalin.marinas, will, daniel.lezcano
Cc: linux-pm, linux-kernel, quentin.perret, mka, ionela.voinescu,
dietmar.eggemann, linux-arm-kernel
In-Reply-To: <20190812084235.21440-5-quentin.perret@arm.com>
The newly introduced Energy Model framework manages power cost tables in
a generic way. Moreover, it supports several types of models since the
tables can come from DT or firmware (through SCMI) for example. On the
other hand, the cpu_cooling subsystem manages its own power cost tables
using only DT data.
In order to avoid the duplication of data in the kernel, and in order to
enable IPA with EMs coming from more than just DT, remove the private
tables from cpu_cooling.c and migrate it to using the centralized EM
framework. Doing so should have no visible functional impact for
existing users of IPA since:
- recent extenstions to the the PM_OPP infrastructure enable the
registration of EMs in PM_EM using the DT property used by IPA;
- the existing upstream cpufreq drivers marked with the
'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP
infrastructure, which means they all support PM_EM. The only two
exceptions are qoriq-cpufreq which doesn't in fact use an EM and
scmi-cpufreq which doesn't use DT for power costs.
For existing users of cpu_cooling, PM_EM tables will contain the exact
same power values that IPA used to compute on its own until now. The
only new dependency for them is to compile in CONFIG_ENERGY_MODEL.
The case where the thermal subsystem is used without an Energy Model
(cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
frequency table which is already a dependency for cpu_cooling.c anyway.
Since the thermal framework expects the cooling states in a particular
order, bail out whenever the CPUFreq table is unsorted, since that is
fairly uncommon in general, and there are currently no users of
cpu_cooling for this use-case.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
---
In v8 I fixed the checkpatch.pl errors reported by Rui (thanks for
pointing them out) due to whitespaces instead of tabs. There is no
actual code change. The one warning left is intentional, but do let me
know if you have better ideas to make it go away.
Thanks,
Quentin
---
drivers/thermal/Kconfig | 1 +
drivers/thermal/cpu_cooling.c | 249 ++++++++++++----------------------
2 files changed, 90 insertions(+), 160 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364a6deb..340853a3ca48 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -144,6 +144,7 @@ config THERMAL_GOV_USER_SPACE
config THERMAL_GOV_POWER_ALLOCATOR
bool "Power allocator thermal governor"
+ depends on ENERGY_MODEL
help
Enable this to manage platform thermals by dynamically
allocating and limiting power to devices.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 498f59ab64b2..89be25210ed4 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/cpu.h>
#include <linux/cpu_cooling.h>
+#include <linux/energy_model.h>
#include <trace/events/thermal.h>
@@ -36,21 +37,6 @@
* ...
*/
-/**
- * struct freq_table - frequency table along with power entries
- * @frequency: frequency in KHz
- * @power: power in mW
- *
- * This structure is built when the cooling device registers and helps
- * in translating frequency to power and vice versa.
- */
-struct freq_table {
- u32 frequency;
-#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
- u32 power;
-#endif
-};
-
/**
* struct time_in_idle - Idle time stats
* @time: previous reading of the absolute time that this cpu was idle
@@ -72,7 +58,7 @@ struct time_in_idle {
* frequency.
* @max_level: maximum cooling level. One less than total number of valid
* cpufreq frequencies.
- * @freq_table: Freq table in descending order of frequencies
+ * @em: Reference on the Energy Model of the device
* @cdev: thermal_cooling_device pointer to keep track of the
* registered cooling device.
* @policy: cpufreq policy.
@@ -88,7 +74,7 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int clipped_freq;
unsigned int max_level;
- struct freq_table *freq_table; /* In descending order */
+ struct em_perf_domain *em;
struct cpufreq_policy *policy;
struct list_head node;
struct time_in_idle *idle_time;
@@ -162,114 +148,40 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb,
static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
unsigned int freq)
{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- unsigned long level;
+ int i;
- for (level = 1; level <= cpufreq_cdev->max_level; level++)
- if (freq > freq_table[level].frequency)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (freq > cpufreq_cdev->em->table[i].frequency)
break;
-
- return level - 1;
-}
-
-/**
- * update_freq_table() - Update the freq table with power numbers
- * @cpufreq_cdev: the cpufreq cooling device in which to update the table
- * @capacitance: dynamic power coefficient for these cpus
- *
- * Update the freq table with power numbers. This table will be used in
- * cpu_power_to_freq() and cpu_freq_to_power() to convert between power and
- * frequency efficiently. Power is stored in mW, frequency in KHz. The
- * resulting table is in descending order.
- *
- * Return: 0 on success, -EINVAL if there are no OPPs for any CPUs,
- * or -ENOMEM if we run out of memory.
- */
-static int update_freq_table(struct cpufreq_cooling_device *cpufreq_cdev,
- u32 capacitance)
-{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- struct dev_pm_opp *opp;
- struct device *dev = NULL;
- int num_opps = 0, cpu = cpufreq_cdev->policy->cpu, i;
-
- dev = get_cpu_device(cpu);
- if (unlikely(!dev)) {
- pr_warn("No cpu device for cpu %d\n", cpu);
- return -ENODEV;
}
- num_opps = dev_pm_opp_get_opp_count(dev);
- if (num_opps < 0)
- return num_opps;
-
- /*
- * The cpufreq table is also built from the OPP table and so the count
- * should match.
- */
- if (num_opps != cpufreq_cdev->max_level + 1) {
- dev_warn(dev, "Number of OPPs not matching with max_levels\n");
- return -EINVAL;
- }
-
- for (i = 0; i <= cpufreq_cdev->max_level; i++) {
- unsigned long freq = freq_table[i].frequency * 1000;
- u32 freq_mhz = freq_table[i].frequency / 1000;
- u64 power;
- u32 voltage_mv;
-
- /*
- * Find ceil frequency as 'freq' may be slightly lower than OPP
- * freq due to truncation while converting to kHz.
- */
- opp = dev_pm_opp_find_freq_ceil(dev, &freq);
- if (IS_ERR(opp)) {
- dev_err(dev, "failed to get opp for %lu frequency\n",
- freq);
- return -EINVAL;
- }
-
- voltage_mv = dev_pm_opp_get_voltage(opp) / 1000;
- dev_pm_opp_put(opp);
-
- /*
- * Do the multiplication with MHz and millivolt so as
- * to not overflow.
- */
- power = (u64)capacitance * freq_mhz * voltage_mv * voltage_mv;
- do_div(power, 1000000000);
-
- /* power is stored in mW */
- freq_table[i].power = power;
- }
-
- return 0;
+ return cpufreq_cdev->max_level - i - 1;
}
static u32 cpu_freq_to_power(struct cpufreq_cooling_device *cpufreq_cdev,
u32 freq)
{
int i;
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- for (i = 1; i <= cpufreq_cdev->max_level; i++)
- if (freq > freq_table[i].frequency)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (freq > cpufreq_cdev->em->table[i].frequency)
break;
+ }
- return freq_table[i - 1].power;
+ return cpufreq_cdev->em->table[i + 1].power;
}
static u32 cpu_power_to_freq(struct cpufreq_cooling_device *cpufreq_cdev,
u32 power)
{
int i;
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- for (i = 1; i <= cpufreq_cdev->max_level; i++)
- if (power > freq_table[i].power)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (power > cpufreq_cdev->em->table[i].power)
break;
+ }
- return freq_table[i - 1].frequency;
+ return cpufreq_cdev->em->table[i + 1].frequency;
}
/**
@@ -410,7 +322,7 @@ static int cpufreq_state2power(struct thermal_cooling_device *cdev,
struct thermal_zone_device *tz,
unsigned long state, u32 *power)
{
- unsigned int freq, num_cpus;
+ unsigned int freq, num_cpus, idx;
struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
/* Request state should be less than max_level */
@@ -419,7 +331,8 @@ static int cpufreq_state2power(struct thermal_cooling_device *cdev,
num_cpus = cpumask_weight(cpufreq_cdev->policy->cpus);
- freq = cpufreq_cdev->freq_table[state].frequency;
+ idx = cpufreq_cdev->max_level - state;
+ freq = cpufreq_cdev->em->table[idx].frequency;
*power = cpu_freq_to_power(cpufreq_cdev, freq) * num_cpus;
return 0;
@@ -463,8 +376,59 @@ static int cpufreq_power2state(struct thermal_cooling_device *cdev,
power);
return 0;
}
+
+static inline bool em_is_sane(struct cpufreq_cooling_device *cpufreq_cdev,
+ struct em_perf_domain *em) {
+ struct cpufreq_policy *policy;
+ unsigned int nr_levels;
+
+ if (!em)
+ return false;
+
+ policy = cpufreq_cdev->policy;
+ if (!cpumask_equal(policy->related_cpus, to_cpumask(em->cpus))) {
+ pr_err("The span of pd %*pbl is misaligned with cpufreq policy %*pbl\n",
+ cpumask_pr_args(to_cpumask(em->cpus)),
+ cpumask_pr_args(policy->related_cpus));
+ return false;
+ }
+
+ nr_levels = cpufreq_cdev->max_level + 1;
+ if (em->nr_cap_states != nr_levels) {
+ pr_err("The number of cap states in pd %*pbl (%u) doesn't match the number of cooling levels (%u)\n",
+ cpumask_pr_args(to_cpumask(em->cpus)),
+ em->nr_cap_states, nr_levels);
+ return false;
+ }
+
+ return true;
+}
#endif /* CONFIG_THERMAL_GOV_POWER_ALLOCATOR */
+static unsigned int get_state_freq(struct cpufreq_cooling_device *cpufreq_cdev,
+ unsigned long state)
+{
+ struct cpufreq_policy *policy;
+ unsigned long idx;
+
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
+ /* Use the Energy Model table if available */
+ if (cpufreq_cdev->em) {
+ idx = cpufreq_cdev->max_level - state;
+ return cpufreq_cdev->em->table[idx].frequency;
+ }
+#endif
+
+ /* Otherwise, fallback on the CPUFreq table */
+ policy = cpufreq_cdev->policy;
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING)
+ idx = cpufreq_cdev->max_level - state;
+ else
+ idx = state;
+
+ return policy->freq_table[idx].frequency;
+}
+
/* cpufreq cooling device callback functions are defined below */
/**
@@ -530,7 +494,7 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
if (cpufreq_cdev->cpufreq_state == state)
return 0;
- clip_freq = cpufreq_cdev->freq_table[state].frequency;
+ clip_freq = get_state_freq(cpufreq_cdev, state);
cpufreq_cdev->cpufreq_state = state;
cpufreq_cdev->clipped_freq = clip_freq;
@@ -552,26 +516,12 @@ static struct notifier_block thermal_cpufreq_notifier_block = {
.notifier_call = cpufreq_thermal_notifier,
};
-static unsigned int find_next_max(struct cpufreq_frequency_table *table,
- unsigned int prev_max)
-{
- struct cpufreq_frequency_table *pos;
- unsigned int max = 0;
-
- cpufreq_for_each_valid_entry(pos, table) {
- if (pos->frequency > max && pos->frequency < prev_max)
- max = pos->frequency;
- }
-
- return max;
-}
-
/**
* __cpufreq_cooling_register - helper function to create cpufreq cooling device
* @np: a valid struct device_node to the cooling device device tree node
* @policy: cpufreq policy
* Normally this should be same as cpufreq policy->related_cpus.
- * @capacitance: dynamic power coefficient for these cpus
+ * @em: Energy Model of the cpufreq policy
*
* This interface function registers the cpufreq cooling device with the name
* "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
@@ -583,12 +533,13 @@ static unsigned int find_next_max(struct cpufreq_frequency_table *table,
*/
static struct thermal_cooling_device *
__cpufreq_cooling_register(struct device_node *np,
- struct cpufreq_policy *policy, u32 capacitance)
+ struct cpufreq_policy *policy,
+ struct em_perf_domain *em)
{
struct thermal_cooling_device *cdev;
struct cpufreq_cooling_device *cpufreq_cdev;
char dev_name[THERMAL_NAME_LENGTH];
- unsigned int freq, i, num_cpus;
+ unsigned int i, num_cpus;
int ret;
struct thermal_cooling_device_ops *cooling_ops;
bool first;
@@ -622,55 +573,38 @@ __cpufreq_cooling_register(struct device_node *np,
/* max_level is an index, not a counter */
cpufreq_cdev->max_level = i - 1;
- cpufreq_cdev->freq_table = kmalloc_array(i,
- sizeof(*cpufreq_cdev->freq_table),
- GFP_KERNEL);
- if (!cpufreq_cdev->freq_table) {
- cdev = ERR_PTR(-ENOMEM);
- goto free_idle_time;
- }
-
ret = ida_simple_get(&cpufreq_ida, 0, 0, GFP_KERNEL);
if (ret < 0) {
cdev = ERR_PTR(ret);
- goto free_table;
+ goto free_idle_time;
}
cpufreq_cdev->id = ret;
snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
cpufreq_cdev->id);
- /* Fill freq-table in descending order of frequencies */
- for (i = 0, freq = -1; i <= cpufreq_cdev->max_level; i++) {
- freq = find_next_max(policy->freq_table, freq);
- cpufreq_cdev->freq_table[i].frequency = freq;
-
- /* Warn for duplicate entries */
- if (!freq)
- pr_warn("%s: table has duplicate entries\n", __func__);
- else
- pr_debug("%s: freq:%u KHz\n", __func__, freq);
- }
-
cooling_ops = &cpufreq_cooling_ops;
#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
- if (capacitance) {
- ret = update_freq_table(cpufreq_cdev, capacitance);
- if (ret) {
- cdev = ERR_PTR(ret);
- goto remove_ida;
- }
+ if (em_is_sane(cpufreq_cdev, em)) {
+ cpufreq_cdev->em = em;
cooling_ops->get_requested_power = cpufreq_get_requested_power;
cooling_ops->state2power = cpufreq_state2power;
cooling_ops->power2state = cpufreq_power2state;
- }
+ } else
#endif
+ if (policy->freq_table_sorted == CPUFREQ_TABLE_UNSORTED) {
+ pr_err("%s: unsorted frequency tables are not supported\n",
+ __func__);
+ cdev = ERR_PTR(-EINVAL);
+ goto remove_ida;
+ }
+
cdev = thermal_of_cooling_device_register(np, dev_name, cpufreq_cdev,
cooling_ops);
if (IS_ERR(cdev))
goto remove_ida;
- cpufreq_cdev->clipped_freq = cpufreq_cdev->freq_table[0].frequency;
+ cpufreq_cdev->clipped_freq = get_state_freq(cpufreq_cdev, 0);
mutex_lock(&cooling_list_lock);
/* Register the notifier for first cpufreq cooling device */
@@ -686,8 +620,6 @@ __cpufreq_cooling_register(struct device_node *np,
remove_ida:
ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
-free_table:
- kfree(cpufreq_cdev->freq_table);
free_idle_time:
kfree(cpufreq_cdev->idle_time);
free_cdev:
@@ -709,7 +641,7 @@ __cpufreq_cooling_register(struct device_node *np,
struct thermal_cooling_device *
cpufreq_cooling_register(struct cpufreq_policy *policy)
{
- return __cpufreq_cooling_register(NULL, policy, 0);
+ return __cpufreq_cooling_register(NULL, policy, NULL);
}
EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
@@ -737,7 +669,6 @@ of_cpufreq_cooling_register(struct cpufreq_policy *policy)
{
struct device_node *np = of_get_cpu_node(policy->cpu, NULL);
struct thermal_cooling_device *cdev = NULL;
- u32 capacitance = 0;
if (!np) {
pr_err("cpu_cooling: OF node not available for cpu%d\n",
@@ -746,10 +677,9 @@ of_cpufreq_cooling_register(struct cpufreq_policy *policy)
}
if (of_find_property(np, "#cooling-cells", NULL)) {
- of_property_read_u32(np, "dynamic-power-coefficient",
- &capacitance);
+ struct em_perf_domain *em = em_cpu_get(policy->cpu);
- cdev = __cpufreq_cooling_register(np, policy, capacitance);
+ cdev = __cpufreq_cooling_register(np, policy, em);
if (IS_ERR(cdev)) {
pr_err("cpu_cooling: cpu%d failed to register as cooling device: %ld\n",
policy->cpu, PTR_ERR(cdev));
@@ -791,7 +721,6 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
thermal_cooling_device_unregister(cdev);
ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
kfree(cpufreq_cdev->idle_time);
- kfree(cpufreq_cdev->freq_table);
kfree(cpufreq_cdev);
}
EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
--
2.22.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: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Robin Gong @ 2019-08-28 14:05 UTC (permalink / raw)
To: Jurgen Lambrecht, Leonard Crestez
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <7282882c-1c79-9685-4bfe-80195976c8d6@televic.com>
On 8/28/19 17:27, Jurgen Lambrecht wrote:
>
> On 8/27/19 5:04 PM, Leonard Crestez wrote:
> > CAUTION: This Email originated from outside Televic. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > On 27.08.2019 16:35, Jurgen Lambrecht wrote:
> >> We are updating our kernel on our custom board with an iMX6UL from
> >> 3.14 to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin
> >> v3.5 the kernel hangs when booting, only "Starting kernel ..." is
> >> printed (by uBoot I think).
> > If you enable "earlycon" you should be able to see an useful error
> > message from crashes in early boot.
> >
> > Enabling earlycon is board-specific: if you have a correct
> > /chosen/stdout-path reference in dts just adding "earlycon" to kernel
> > cmdline should work otherwise you can specify
> > earlycon=ec_imx6q,0x202000,115200 with the exact address depending on
> > which uart is console on your board.
>
> OK, thanks. First time I hear of earlycon.
>
> But as I thought (because of logs with other kernel versions) the kernel just
> hangs when loading the sdma driver.
> Now it is v3.5, but I also tried v3.3 a few weeks ago.
>
> This is the last kernel log (below the full log):
>
> [ 2.312336] imx-sdma 20ec000.sdma: loaded firmware 3.5
>
> About the DT config, I enabled sdma on all that I found: standard dtsi only
> has sdma enabled for SAI. But the freescale 4.1 kernel has more: I also
> enabled sdma for ecspi1 to ecspi4, uart1 to uart8.
> But as a test I have also removed all sdma entries from DT, and still it hangs.
Could you help check if below commit in your side?
commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
Author: Lucas Stach <l.stach@pengutronix.de>
Date: Tue Nov 6 03:40:28 2018 +0000
Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool"
This reverts commit fe5b85c656bc. The SDMA engine needs the descriptors to
be contiguous in memory. As the dma pool API is only able to provide a
single descriptor per alloc invocation there is no guarantee that multiple
descriptors satisfy this requirement. Also the code in question is broken
as it only allocates memory for a single descriptor, without looking at the
number of descriptors required for the transfer, leading to out-of-bounds
accesses when the descriptors are written.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Vinod Koul <vkoul@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
* [PATCH v2 0/3] arm64: meson-sm1: add support for the SM1 based VIM3L
From: Neil Armstrong @ 2019-08-28 14:11 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
This patchset adds support for the Amlogic SM1 based Khadas VIM3L variant.
The S903D3 package variant of SM1 is pin-to-pin compatible with the
S922X and A311d, so only internal DT changes are needed :
- DVFS support is different
- Audio support not yet available for SM1
This patchset moved all the non-g12b nodes to meson-khadas-vim3.dtsi
and add the sm1 specific nodes into meson-sm1-khadas-vim3l.dts.
Display has a color conversion bug on SM1 by using a more recent vendor
bootloader on the SM1 based VIM3, this is out of scope of this patchset
and will be fixed in the drm/meson driver.
Dependencies:
- patch 1,2: None
- patch 3: Depends on the "arm64: meson-sm1: add support for DVFS" patchset at [1]
Changes since v1:
- renamed compatible to khadas,vim3l
- renamed DT file to meson-sm1-khadas-vim3l.dts
[1] https://patchwork.kernel.org/cover/11109411/
Neil Armstrong (3):
arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
amlogic: arm: add Amlogic SM1 based Khadas VIM3L bindings
arm64: dts: khadas-vim3: add support for the SM1 based VIM3L
.../devicetree/bindings/arm/amlogic.yaml | 3 +-
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../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 ++++++++++++++++++
.../dts/amlogic/meson-sm1-khadas-vim3l.dts | 70 ++++
7 files changed, 435 insertions(+), 356 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
--
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
* [PATCH v2 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3L bindings
From: Neil Armstrong @ 2019-08-28 14:11 UTC (permalink / raw)
To: khilman, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141157.15503-1-narmstrong@baylibre.com>
The Khadas VIM3 is also available as VIM3L with the Pin-to-pin compatible
Amlogic SM1 SoC in the S905D3 variant package.
Change the description to match the S905X3/D3/Y3 variants like the G12A
description, and add the khadas,vim3l compatible.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index b48ea1e4913a..99015cef8bb1 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,9 +150,10 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
- - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
items:
- enum:
- seirobotics,sei610
+ - khadas,vim3l
- const: amlogic,sm1
...
--
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 v2 1/3] arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
From: Neil Armstrong @ 2019-08-28 14:11 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141157.15503-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
* [PATCH v2 3/3] arm64: dts: khadas-vim3: add support for the SM1 based VIM3L
From: Neil Armstrong @ 2019-08-28 14:11 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141157.15503-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
* Re: [PATCH v2 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3L bindings
From: Neil Armstrong @ 2019-08-28 14:15 UTC (permalink / raw)
To: khilman, devicetree; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <20190828141157.15503-3-narmstrong@baylibre.com>
Damn wrong subject.. please ignore this one.
Neil
On 28/08/2019 16:11, Neil Armstrong wrote:
> The Khadas VIM3 is also available as VIM3L with the Pin-to-pin compatible
> Amlogic SM1 SoC in the S905D3 variant package.
>
> Change the description to match the S905X3/D3/Y3 variants like the G12A
> description, and add the khadas,vim3l compatible.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
> index b48ea1e4913a..99015cef8bb1 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
> @@ -150,9 +150,10 @@ properties:
> - const: amlogic,s922x
> - const: amlogic,g12b
>
> - - description: Boards with the Amlogic Meson SM1 S905X3 SoC
> + - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
> items:
> - enum:
> - seirobotics,sei610
> + - khadas,vim3l
> - const: amlogic,sm1
> ...
>
_______________________________________________
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 7/8] coresight: etm4x: Add missing single-shot control API to sysfs
From: Mike Leach @ 2019-08-28 14:15 UTC (permalink / raw)
To: Leo Yan; +Cc: Coresight ML, linux-arm-kernel, Mathieu Poirier
In-Reply-To: <20190828051847.GG26133@leoy-ThinkPad-X240s>
HI Leo,
On Wed, 28 Aug 2019 at 06:18, Leo Yan <leo.yan@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:19PM +0100, Mike Leach wrote:
> > An API to control single-shot comparator operation was missing from sysfs.
> > This adds the parameters to sysfs to allow programming of this feature.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../coresight/coresight-etm4x-sysfs.c | 122 ++++++++++++++++++
> > drivers/hwtracing/coresight/coresight-etm4x.c | 26 +++-
> > drivers/hwtracing/coresight/coresight-etm4x.h | 3 +
> > 3 files changed, 150 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index 483976074779..7c019dda1236 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -239,6 +239,7 @@ static ssize_t reset_store(struct device *dev,
> > for (i = 0; i < drvdata->nr_resource; i++)
> > config->res_ctrl[i] = 0x0;
> >
> > + config->ss_idx = 0x0;
> > for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > config->ss_ctrl[i] = 0x0;
> > config->ss_pe_cmp[i] = 0x0;
> > @@ -1713,6 +1714,123 @@ static ssize_t res_ctrl_store(struct device *dev,
> > }
> > static DEVICE_ATTR_RW(res_ctrl);
> >
> > +static ssize_t sshot_idx_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + val = config->ss_idx;
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_idx_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > + if (val >= drvdata->nr_ss_cmp)
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + config->ss_idx = val;
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_idx);
> > +
> > +static ssize_t sshot_ctrl_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_ctrl[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_ctrl_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->ss_idx;
> > + config->ss_ctrl[idx] = val & GENMASK(24, 0);
> > + /* must clear bit 31 in related status register on programming */
> > + config->ss_status[idx] &= ~BIT(31);
>
> Since function etm4_enable_hw() will clear ss_status's bit 31 when
> program TRCSSCSRn, so is here redundant to clear bit 31?
>
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_ctrl);
> > +
> > +static ssize_t sshot_status_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_status[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +static DEVICE_ATTR_RO(sshot_status);
> > +
> > +static ssize_t sshot_pe_ctrl_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_pe_cmp[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_pe_ctrl_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->ss_idx;
> > + config->ss_ctrl[idx] = val & GENMASK(7, 0);
> > + /* must clear bit 31 in related status register on programming */
> > + config->ss_status[idx] &= ~BIT(31);
>
> Same question for if it's redundant to clear bit 31?
>
> Thanks,
> Leo Yan
>
The sysfs representation is not the current state of these registers,
but the values that will be programmed on enabling the hardware. We do
not write anything to hardware immediately.
So from a sysfs perspective, the bit clear is reflected in the status
register here to recognise that it will be programmed as cleared.
Should the same registers be set from a different path - e.g. perf,
then the status will automatically be cleared each time the hw is
enabled.
Regards
Mike
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_pe_ctrl);
> > +
> > static ssize_t ctxid_idx_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > @@ -2169,6 +2287,10 @@ static struct attribute *coresight_etmv4_attrs[] = {
> > &dev_attr_addr_exlevel_s_ns.attr,
> > &dev_attr_addr_cmp_view.attr,
> > &dev_attr_vinst_pe_cmp_start_stop.attr,
> > + &dev_attr_sshot_idx.attr,
> > + &dev_attr_sshot_ctrl.attr,
> > + &dev_attr_sshot_pe_ctrl.attr,
> > + &dev_attr_sshot_status.attr,
> > &dev_attr_seq_idx.attr,
> > &dev_attr_seq_state.attr,
> > &dev_attr_seq_event.attr,
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index d8b078d0cc7f..fb7083218410 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -149,6 +149,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> > drvdata->base + TRCRSCTLRn(i));
> >
> > for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + /* always clear status bit on restart if using single-shot */
> > + if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> > + config->ss_status[i] &= ~BIT(31);
> > writel_relaxed(config->ss_ctrl[i],
> > drvdata->base + TRCSSCCRn(i));
> > writel_relaxed(config->ss_status[i],
> > @@ -448,6 +451,9 @@ static void etm4_disable_hw(void *info)
> > {
> > u32 control;
> > struct etmv4_drvdata *drvdata = info;
> > + struct etmv4_config *config = &drvdata->config;
> > + struct device *etm_dev = &drvdata->csdev->dev;
> > + int i;
> >
> > CS_UNLOCK(drvdata->base);
> >
> > @@ -470,6 +476,18 @@ static void etm4_disable_hw(void *info)
> > isb();
> > writel_relaxed(control, drvdata->base + TRCPRGCTLR);
> >
> > + /* wait for TRCSTATR.PMSTABLE to go to '1' */
> > + if (coresight_timeout(drvdata->base, TRCSTATR,
> > + TRCSTATR_PMSTABLE_BIT, 1))
> > + dev_err(etm_dev,
> > + "timeout while waiting for PM stable Trace Status\n");
> > +
> > + /* read the status of the single shot comparators */
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + config->ss_status[i] =
> > + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> > + }
> > +
> > coresight_disclaim_device_unlocked(drvdata->base);
> >
> > CS_LOCK(drvdata->base);
> > @@ -576,6 +594,7 @@ static void etm4_init_arch_data(void *info)
> > u32 etmidr4;
> > u32 etmidr5;
> > struct etmv4_drvdata *drvdata = info;
> > + int i;
> >
> > /* Make sure all registers are accessible */
> > etm4_os_unlock(drvdata);
> > @@ -699,9 +718,14 @@ static void etm4_init_arch_data(void *info)
> > drvdata->nr_resource = BMVAL(etmidr4, 16, 19) + 1;
> > /*
> > * NUMSSCC, bits[23:20] the number of single-shot
> > - * comparator control for tracing
> > + * comparator control for tracing. Read any status regs as these
> > + * also contain RO capability data.
> > */
> > drvdata->nr_ss_cmp = BMVAL(etmidr4, 20, 23);
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + drvdata->config.ss_status[i] =
> > + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> > + }
> > /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> > drvdata->numcidc = BMVAL(etmidr4, 24, 27);
> > /* NUMVMIDC, bits[31:28] number of VMID comparators for tracing */
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 60bc2fb5159b..be8b32ea1654 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -175,6 +175,7 @@
> > ETM_MODE_EXCL_USER)
> >
> > #define TRCSTATR_IDLE_BIT 0
> > +#define TRCSTATR_PMSTABLE_BIT 1
> > #define ETM_DEFAULT_ADDR_COMP 0
> >
> > /* PowerDown Control Register bits */
> > @@ -226,6 +227,7 @@
> > * @cntr_val: Sets or returns the value for a counter.
> > * @res_idx: Resource index selector.
> > * @res_ctrl: Controls the selection of the resources in the trace unit.
> > + * @ss_idx: Single-shot index selector.
> > * @ss_ctrl: Controls the corresponding single-shot comparator resource.
> > * @ss_status: The status of the corresponding single-shot comparator.
> > * @ss_pe_cmp: Selects the PE comparator inputs for Single-shot control.
> > @@ -269,6 +271,7 @@ struct etmv4_config {
> > u32 cntr_val[ETMv4_MAX_CNTR];
> > u8 res_idx;
> > u32 res_ctrl[ETM_MAX_RES_SEL];
> > + u8 ss_idx;
> > u32 ss_ctrl[ETM_MAX_SS_CMP];
> > u32 ss_status[ETM_MAX_SS_CMP];
> > u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> > --
> > 2.17.1
> >
> > _______________________________________________
> > CoreSight mailing list
> > CoreSight@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/coresight
--
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
* Re: [PATCH 7/8] coresight: etm4x: Add missing single-shot control API to sysfs
From: Mike Leach @ 2019-08-28 14:15 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Coresight ML, linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190827222718.GC14958@xps15>
Hi,
On Tue, 27 Aug 2019 at 23:27, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:19PM +0100, Mike Leach wrote:
> > An API to control single-shot comparator operation was missing from sysfs.
> > This adds the parameters to sysfs to allow programming of this feature.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../coresight/coresight-etm4x-sysfs.c | 122 ++++++++++++++++++
> > drivers/hwtracing/coresight/coresight-etm4x.c | 26 +++-
> > drivers/hwtracing/coresight/coresight-etm4x.h | 3 +
> > 3 files changed, 150 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index 483976074779..7c019dda1236 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -239,6 +239,7 @@ static ssize_t reset_store(struct device *dev,
> > for (i = 0; i < drvdata->nr_resource; i++)
> > config->res_ctrl[i] = 0x0;
> >
> > + config->ss_idx = 0x0;
> > for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > config->ss_ctrl[i] = 0x0;
> > config->ss_pe_cmp[i] = 0x0;
> > @@ -1713,6 +1714,123 @@ static ssize_t res_ctrl_store(struct device *dev,
> > }
> > static DEVICE_ATTR_RW(res_ctrl);
> >
> > +static ssize_t sshot_idx_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + val = config->ss_idx;
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_idx_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > + if (val >= drvdata->nr_ss_cmp)
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + config->ss_idx = val;
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_idx);
> > +
> > +static ssize_t sshot_ctrl_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_ctrl[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_ctrl_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->ss_idx;
> > + config->ss_ctrl[idx] = val & GENMASK(24, 0);
> > + /* must clear bit 31 in related status register on programming */
> > + config->ss_status[idx] &= ~BIT(31);
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_ctrl);
> > +
> > +static ssize_t sshot_status_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_status[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +static DEVICE_ATTR_RO(sshot_status);
> > +
> > +static ssize_t sshot_pe_ctrl_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + val = config->ss_pe_cmp[config->ss_idx];
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t sshot_pe_ctrl_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->ss_idx;
> > + config->ss_ctrl[idx] = val & GENMASK(7, 0);
>
> config->ss_pe_cmp[idx] = val & GENMASK(7, 0);
>
Good spot, Thanks
Mike
> > + /* must clear bit 31 in related status register on programming */
> > + config->ss_status[idx] &= ~BIT(31);
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(sshot_pe_ctrl);
> > +
> > static ssize_t ctxid_idx_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > @@ -2169,6 +2287,10 @@ static struct attribute *coresight_etmv4_attrs[] = {
> > &dev_attr_addr_exlevel_s_ns.attr,
> > &dev_attr_addr_cmp_view.attr,
> > &dev_attr_vinst_pe_cmp_start_stop.attr,
> > + &dev_attr_sshot_idx.attr,
> > + &dev_attr_sshot_ctrl.attr,
> > + &dev_attr_sshot_pe_ctrl.attr,
> > + &dev_attr_sshot_status.attr,
> > &dev_attr_seq_idx.attr,
> > &dev_attr_seq_state.attr,
> > &dev_attr_seq_event.attr,
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index d8b078d0cc7f..fb7083218410 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -149,6 +149,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> > drvdata->base + TRCRSCTLRn(i));
> >
> > for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + /* always clear status bit on restart if using single-shot */
> > + if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> > + config->ss_status[i] &= ~BIT(31);
> > writel_relaxed(config->ss_ctrl[i],
> > drvdata->base + TRCSSCCRn(i));
> > writel_relaxed(config->ss_status[i],
> > @@ -448,6 +451,9 @@ static void etm4_disable_hw(void *info)
> > {
> > u32 control;
> > struct etmv4_drvdata *drvdata = info;
> > + struct etmv4_config *config = &drvdata->config;
> > + struct device *etm_dev = &drvdata->csdev->dev;
> > + int i;
> >
> > CS_UNLOCK(drvdata->base);
> >
> > @@ -470,6 +476,18 @@ static void etm4_disable_hw(void *info)
> > isb();
> > writel_relaxed(control, drvdata->base + TRCPRGCTLR);
> >
> > + /* wait for TRCSTATR.PMSTABLE to go to '1' */
> > + if (coresight_timeout(drvdata->base, TRCSTATR,
> > + TRCSTATR_PMSTABLE_BIT, 1))
> > + dev_err(etm_dev,
> > + "timeout while waiting for PM stable Trace Status\n");
> > +
> > + /* read the status of the single shot comparators */
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + config->ss_status[i] =
> > + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> > + }
> > +
> > coresight_disclaim_device_unlocked(drvdata->base);
> >
> > CS_LOCK(drvdata->base);
> > @@ -576,6 +594,7 @@ static void etm4_init_arch_data(void *info)
> > u32 etmidr4;
> > u32 etmidr5;
> > struct etmv4_drvdata *drvdata = info;
> > + int i;
> >
> > /* Make sure all registers are accessible */
> > etm4_os_unlock(drvdata);
> > @@ -699,9 +718,14 @@ static void etm4_init_arch_data(void *info)
> > drvdata->nr_resource = BMVAL(etmidr4, 16, 19) + 1;
> > /*
> > * NUMSSCC, bits[23:20] the number of single-shot
> > - * comparator control for tracing
> > + * comparator control for tracing. Read any status regs as these
> > + * also contain RO capability data.
> > */
> > drvdata->nr_ss_cmp = BMVAL(etmidr4, 20, 23);
> > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > + drvdata->config.ss_status[i] =
> > + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> > + }
> > /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> > drvdata->numcidc = BMVAL(etmidr4, 24, 27);
> > /* NUMVMIDC, bits[31:28] number of VMID comparators for tracing */
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 60bc2fb5159b..be8b32ea1654 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -175,6 +175,7 @@
> > ETM_MODE_EXCL_USER)
> >
> > #define TRCSTATR_IDLE_BIT 0
> > +#define TRCSTATR_PMSTABLE_BIT 1
> > #define ETM_DEFAULT_ADDR_COMP 0
> >
> > /* PowerDown Control Register bits */
> > @@ -226,6 +227,7 @@
> > * @cntr_val: Sets or returns the value for a counter.
> > * @res_idx: Resource index selector.
> > * @res_ctrl: Controls the selection of the resources in the trace unit.
> > + * @ss_idx: Single-shot index selector.
> > * @ss_ctrl: Controls the corresponding single-shot comparator resource.
> > * @ss_status: The status of the corresponding single-shot comparator.
> > * @ss_pe_cmp: Selects the PE comparator inputs for Single-shot control.
> > @@ -269,6 +271,7 @@ struct etmv4_config {
> > u32 cntr_val[ETMv4_MAX_CNTR];
> > u8 res_idx;
> > u32 res_ctrl[ETM_MAX_RES_SEL];
> > + u8 ss_idx;
> > u32 ss_ctrl[ETM_MAX_SS_CMP];
> > u32 ss_status[ETM_MAX_SS_CMP];
> > u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> > --
> > 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 0/3] arm64: meson-sm1: 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
This patchset adds support for the Amlogic SM1 based Khadas VIM3L variant.
The S903D3 package variant of SM1 is pin-to-pin compatible with the
S922X and A311d, so only internal DT changes are needed :
- DVFS support is different
- Audio support not yet available for SM1
This patchset moved all the non-g12b nodes to meson-khadas-vim3.dtsi
and add the sm1 specific nodes into meson-sm1-khadas-vim3l.dts.
Display has a color conversion bug on SM1 by using a more recent vendor
bootloader on the SM1 based VIM3, this is out of scope of this patchset
and will be fixed in the drm/meson driver.
Dependencies:
- patch 1,2: None
- patch 3: Depends on the "arm64: meson-sm1: add support for DVFS" patchset at [1]
Changes since v2:
- fixed patch 2 subject
Changes since v1:
- renamed compatible to khadas,vim3l
- renamed DT file to meson-sm1-khadas-vim3l.dts
[1] https://patchwork.kernel.org/cover/11109411/
Neil Armstrong (3):
arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
dt-bindings: arm: amlogic: add Amlogic SM1 based Khadas VIM3L bindings
arm64: dts: khadas-vim3: add support for the SM1 based VIM3L
.../devicetree/bindings/arm/amlogic.yaml | 3 +-
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../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 ++++++++++++++++++
.../dts/amlogic/meson-sm1-khadas-vim3l.dts | 70 ++++
7 files changed, 435 insertions(+), 356 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
--
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
* [PATCH v3 2/3] dt-bindings: arm: amlogic: add Amlogic SM1 based Khadas VIM3L bindings
From: Neil Armstrong @ 2019-08-28 14:18 UTC (permalink / raw)
To: khilman, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141816.16328-1-narmstrong@baylibre.com>
The Khadas VIM3 is also available as VIM3L with the Pin-to-pin compatible
Amlogic SM1 SoC in the S905D3 variant package.
Change the description to match the S905X3/D3/Y3 variants like the G12A
description, and add the khadas,vim3l compatible.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index b48ea1e4913a..99015cef8bb1 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,9 +150,10 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
- - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
items:
- enum:
- seirobotics,sei610
+ - khadas,vim3l
- const: amlogic,sm1
...
--
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