* Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
From: Dmitry Baryshkov @ 2024-04-09 15:20 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunkuang.hu, robh, krzysztof.kozlowski+dt, conor+dt, p.zabel,
airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
matthias.bgg, shawn.sung, yu-chang.lee, ck.hu, jitao.shi,
devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-2-angelogioacchino.delregno@collabora.com>
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
With the color and gamma being in play, should the configuration be
board-driver or rather use-case driven with the driver being able to
reroute some of the blocks at runtime?
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
With best wishes
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO_GET
From: Sebastian Ene @ 2024-04-09 15:19 UTC (permalink / raw)
To: catalin.marinas, james.morse, jean-philippe, maz, oliver.upton,
qperret, qwandor, sudeep.holla, suzuki.poulose, tabba, will,
yuzenghui, vdonnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, kernel-team,
Sebastian Ene
Handle the FFA_PARTITION_INFO_GET host call inside the pKVM hypervisor
and copy the response message back to the host buffers. Save the
returned FF-A version as we will need it later to interpret the response
from the TEE.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 49 +++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 320f2eaa14a9..72fc365bc7a8 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -67,6 +67,7 @@ struct kvm_ffa_buffers {
*/
static struct kvm_ffa_buffers hyp_buffers;
static struct kvm_ffa_buffers host_buffers;
+static u32 ffa_version;
static void ffa_to_smccc_error(struct arm_smccc_res *res, u64 ffa_errno)
{
@@ -640,6 +641,49 @@ static bool do_ffa_features(struct arm_smccc_res *res,
return true;
}
+static void do_ffa_part_get(struct arm_smccc_res *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, uuid0, ctxt, 1);
+ DECLARE_REG(u32, uuid1, ctxt, 2);
+ DECLARE_REG(u32, uuid2, ctxt, 3);
+ DECLARE_REG(u32, uuid3, ctxt, 4);
+ DECLARE_REG(u32, flags, ctxt, 5);
+ u32 off, count, sz, buf_sz;
+
+ hyp_spin_lock(&host_buffers.lock);
+ if (!host_buffers.rx) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ goto out_unlock;
+ }
+
+ arm_smccc_1_1_smc(FFA_PARTITION_INFO_GET, uuid0, uuid1,
+ uuid2, uuid3, flags, 0, 0,
+ res);
+
+ if (res->a0 != FFA_SUCCESS)
+ goto out_unlock;
+
+ count = res->a2;
+ if (!count)
+ goto out_unlock;
+
+ if (ffa_version > FFA_VERSION_1_0) {
+ buf_sz = sz = res->a3;
+ if (sz > sizeof(struct ffa_partition_info))
+ buf_sz = sizeof(struct ffa_partition_info);
+ } else {
+ /* FFA_VERSION_1_0 lacks the size in the response */
+ buf_sz = sz = 8;
+ }
+
+ WARN_ON((count - 1) * sz + buf_sz > PAGE_SIZE);
+ for (off = 0; off < count * sz; off += sz)
+ memcpy(host_buffers.rx + off, hyp_buffers.rx + off, buf_sz);
+out_unlock:
+ hyp_spin_unlock(&host_buffers.lock);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_res res;
@@ -686,6 +730,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_MEM_FRAG_TX:
do_ffa_mem_frag_tx(&res, host_ctxt);
goto out_handled;
+ case FFA_PARTITION_INFO_GET:
+ do_ffa_part_get(&res, host_ctxt);
+ break;
}
if (ffa_call_supported(func_id))
@@ -726,6 +773,8 @@ int hyp_ffa_init(void *pages)
if (FFA_MAJOR_VERSION(res.a0) != 1)
return -EOPNOTSUPP;
+ ffa_version = res.a0;
+
arm_smccc_1_1_smc(FFA_ID_GET, 0, 0, 0, 0, 0, 0, 0, &res);
if (res.a0 != FFA_SUCCESS)
return -EOPNOTSUPP;
--
2.44.0.478.gd926399ef9-goog
_______________________________________________
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: [RFC PATCH v2 0/2] fw_devlink overlay fix
From: Geert Uytterhoeven @ 2024-04-09 15:10 UTC (permalink / raw)
To: Saravana Kannan
Cc: Herve Codina, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi
In-Reply-To: <20240409053704.428336-1-saravanak@google.com>
Hi Saravana,
On Tue, Apr 9, 2024 at 7:37 AM Saravana Kannan <saravanak@google.com> wrote:
> Don't bother reviewing this patch. It needs to be tested and possibly
> refactored first.
>
> Geert and Herve,
>
> This patch serious should hopefully fix both of your use cases
> [1][2][3]. Can you please check to make sure the device links created
> to/from the overlay devices are to/from the right ones?
Thanks for your series!
After applying the first patch (the revert), the issue reported in
[1] is back, as expected.
After applying both patches, applying[A]/unapplying[B]/reapplying[C]
overlay [4] works as without this series, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Note that the state of /sys/class/devlink/ after [C] is still not the
same as after [A], as reported before in [5]:
- platform:e6060000.pinctrl--platform:keys link is not recreated in [B],
- nothing changes in /sys/class/devlink in [C].
But that issue is not introduced in this series.
> [1] - https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
[4] "arm64: dts: renesas: ebisu: cn41: Add overlay for MSIOF0 and 25LC040"
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/renesas-overlays&id=222a4936b0d3dabd43bdffb3a578423bff97b02d
[5] https://lore.kernel.org/lkml/CAMuHMdXNoYH8PJE1xb4PK-vzjXtOzrxNJoZhsHT-H4Ucm=7_ig@mail.gmail.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] cpufreq: Convert to exit callback returning void
From: Christophe Leroy @ 2024-04-09 15:05 UTC (permalink / raw)
To: Lizhe, mpe@ellerman.id.au, npiggin@gmail.com,
aneesh.kumar@kernel.org, naveen.n.rao@linux.ibm.com,
rafael@kernel.org, viresh.kumar@linaro.org, andersson@kernel.org,
konrad.dybcio@linaro.org, sudeep.holla@arm.com,
cristian.marussi@arm.com, thierry.reding@gmail.com,
jonathanh@nvidia.com
Cc: inuxppc-dev@lists.ozlabs.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org
In-Reply-To: <20240409145316.5181-1-sensor1010@163.com>
Le 09/04/2024 à 16:53, Lizhe a écrit :
> For the exit() callback function returning an int type value,
> this leads many driver authors mistakenly believing that error
> handling can be performed by returning an error code. However,
> the returned value is ignored, and to improve this situation,
> it is proposed to modify the return type of the exit() callback
> function to void.
>
> Signed-off-by: Lizhe <sensor1010@163.com>
> ---
> drivers/cpufreq/pasemi-cpufreq.c | 4 +---
> drivers/cpufreq/powernv-cpufreq.c | 4 +---
> drivers/cpufreq/ppc_cbe_cpufreq.c | 3 +--
> drivers/cpufreq/qcom-cpufreq-hw.c | 4 +---
> drivers/cpufreq/qoriq-cpufreq.c | 4 +---
> drivers/cpufreq/scmi-cpufreq.c | 4 +---
> drivers/cpufreq/scpi-cpufreq.c | 4 +---
> drivers/cpufreq/sh-cpufreq.c | 4 +---
> drivers/cpufreq/sparc-us2e-cpufreq.c | 3 +--
> drivers/cpufreq/sparc-us3-cpufreq.c | 3 +--
> drivers/cpufreq/speedstep-centrino.c | 4 +---
> drivers/cpufreq/tegra194-cpufreq.c | 4 +---
> drivers/cpufreq/vexpress-spc-cpufreq.c | 3 +--
> 13 files changed, 13 insertions(+), 35 deletions(-)
Did you do a building test ?
How can this work without changing the definition of exit in struct
cpu_freq driver in include/linux/cpufreq.h ?
Christophe
_______________________________________________
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 v1 1/6] dt-bindings: cache: Document the sifive,perfmon-counters property
From: Conor Dooley @ 2024-04-09 15:03 UTC (permalink / raw)
To: Samuel Holland
Cc: Will Deacon, Mark Rutland, Eric Lin, Palmer Dabbelt, devicetree,
linux-kernel, Paul Walmsley, linux-riscv, Rob Herring,
Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <20240216000837.1868917-2-samuel.holland@sifive.com>
[-- Attachment #1.1: Type: text/plain, Size: 1392 bytes --]
On Thu, Feb 15, 2024 at 04:08:13PM -0800, Samuel Holland wrote:
> The SiFive Composable Cache controller contains an optional PMU with a
> configurable number of event counters. Document a property which
> describes the number of available counters.
>
> Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
> ---
>
> Documentation/devicetree/bindings/cache/sifive,ccache0.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
> index 7e8cebe21584..100eda4345de 100644
> --- a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
> +++ b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
> @@ -81,6 +81,11 @@ properties:
> The reference to the reserved-memory for the L2 Loosely Integrated Memory region.
> The reserved memory node should be defined as per the bindings in reserved-memory.txt.
>
> + sifive,perfmon-counters:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + description: Number of PMU counter registers
I think this should be restricted to devices that actually have it,
given we've already gone pretty hard in this binding with specific
requirements.
> +
> allOf:
> - $ref: /schemas/cache-controller.yaml#
>
> --
> 2.43.0
>
[-- 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
* [PATCH net v2] net: dsa: mt7530: trap link-local frames regardless of ST Port State
From: Arınç ÜNAL via B4 Relay @ 2024-04-09 15:01 UTC (permalink / raw)
To: Daniel Golle, DENG Qingfang, Sean Wang, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Bartel Eerdekens, mithat.guner, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek,
Arınç ÜNAL
From: Arınç ÜNAL <arinc.unal@arinc9.com>
In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer
(DLL) of the Open Systems Interconnection basic reference model (OSI/RM)
are described; the medium access control (MAC) and logical link control
(LLC) sublayers. The MAC sublayer is the one facing the physical layer.
In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A
Bridge component comprises a MAC Relay Entity for interconnecting the Ports
of the Bridge, at least two Ports, and higher layer entities with at least
a Spanning Tree Protocol Entity included.
Each Bridge Port also functions as an end station and shall provide the MAC
Service to an LLC Entity. Each instance of the MAC Service is provided to a
distinct LLC Entity that supports protocol identification, multiplexing,
and demultiplexing, for protocol data unit (PDU) transmission and reception
by one or more higher layer entities.
It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC
Entity associated with each Bridge Port is modeled as being directly
connected to the attached Local Area Network (LAN).
On the switch with CPU port architecture, CPU port functions as Management
Port, and the Management Port functionality is provided by software which
functions as an end station. Software is connected to an IEEE 802 LAN that
is wholly contained within the system that incorporates the Bridge.
Software provides access to the LLC Entity associated with each Bridge Port
by the value of the source port field on the special tag on the frame
received by software.
We call frames that carry control information to determine the active
topology and current extent of each Virtual Local Area Network (VLAN),
i.e., spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN
Registration Protocol Data Units (MVRPDUs), and frames from other link
constrained protocols, such as Extensible Authentication Protocol over LAN
(EAPOL) and Link Layer Discovery Protocol (LLDP), link-local frames. They
are not forwarded by a Bridge. Permanently configured entries in the
filtering database (FDB) ensure that such frames are discarded by the
Forwarding Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in
detail:
Each of the reserved MAC addresses specified in Table 8-1
(01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be
permanently configured in the FDB in C-VLAN components and ERs.
Each of the reserved MAC addresses specified in Table 8-2
(01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently
configured in the FDB in S-VLAN components.
Each of the reserved MAC addresses specified in Table 8-3
(01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB
in TPMR components.
The FDB entries for reserved MAC addresses shall specify filtering for all
Bridge Ports and all VIDs. Management shall not provide the capability to
modify or remove entries for reserved MAC addresses.
The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of
propagation of PDUs within a Bridged Network, as follows:
The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that
no conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN)
component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward.
PDUs transmitted using this destination address, or any other addresses
that appear in Table 8-1, Table 8-2, and Table 8-3
(01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can
therefore travel no further than those stations that can be reached via a
single individual LAN from the originating station.
The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an
address that no conformant S-VLAN component, C-VLAN component, or MAC
Bridge can forward; however, this address is relayed by a TPMR component.
PDUs using this destination address, or any of the other addresses that
appear in both Table 8-1 and Table 8-2 but not in Table 8-3
(01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed
by any TPMRs but will propagate no further than the nearest S-VLAN
component, C-VLAN component, or MAC Bridge.
The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an
address that no conformant C-VLAN component, MAC Bridge can forward;
however, it is relayed by TPMR components and S-VLAN components. PDUs
using this destination address, or any of the other addresses that appear
in Table 8-1 but not in either Table 8-2 or Table 8-3
(01-80-C2-00-00-[00,0B,0C,0D,0F]), will be relayed by TPMR components and
S-VLAN components but will propagate no further than the nearest C-VLAN
component or MAC Bridge.
Because the LLC Entity associated with each Bridge Port is provided via CPU
port, we must not filter these frames but forward them to CPU port.
In a Bridge, the transmission Port is majorly decided by ingress and egress
rules, FDB, and spanning tree Port State functions of the Forwarding
Process. For link-local frames, only CPU port should be designated as
destination port in the FDB, and the other functions of the Forwarding
Process must not interfere with the decision of the transmission Port. We
call this process trapping frames to CPU port.
Therefore, on the switch with CPU port architecture, link-local frames must
be trapped to CPU port, and certain link-local frames received by a Port of
a Bridge comprising a TPMR component or an S-VLAN component must be
excluded from it.
A Bridge of the switch with CPU port architecture cannot comprise a
Two-Port MAC Relay (TPMR) component as a TPMR component supports only a
subset of the functionality of a MAC Bridge. A Bridge comprising two Ports
(Management Port doesn't count) of this architecture will either function
as a standard MAC Bridge or a standard VLAN Bridge.
Therefore, a Bridge of this architecture can only comprise S-VLAN
components, C-VLAN components, or MAC Bridge components. Since there's no
TPMR component, we don't need to relay PDUs using the destination addresses
specified on the Nearest non-TPMR section, and the proportion of the
Nearest Customer Bridge section where they must be relayed by TPMR
components.
One option to trap link-local frames to CPU port is to add static FDB
entries with CPU port designated as destination port. However, because that
Independent VLAN Learning (IVL) is being used on every VID, each entry only
applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC
Bridge component or a C-VLAN component, there would have to be 16 times
4096 entries. This switch intellectual property can only hold a maximum of
2048 entries. Using this option, there also isn't a mechanism to prevent
link-local frames from being discarded when the spanning tree Port State of
the reception Port is discarding.
The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4
registers. Whilst this applies to every VID, it doesn't contain all of the
reserved MAC addresses without affecting the remaining Standard Group MAC
Addresses. The REV_UN frame tag utilised using the RGAC4 register covers
the remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination
addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF
destination addresses which may be relayed by MAC Bridges or VLAN Bridges.
The latter option provides better but not complete conformance.
This switch intellectual property also does not provide a mechanism to trap
link-local frames with specific destination addresses to CPU port by
Bridge, to conform to the filtering rules for the distinct Bridge
components.
Therefore, regardless of the type of the Bridge component, link-local
frames with these destination addresses will be trapped to CPU port:
01-80-C2-00-00-[00,01,02,03,0E]
In a Bridge comprising a MAC Bridge component or a C-VLAN component:
Link-local frames with these destination addresses won't be trapped to
CPU port which won't conform to IEEE Std 802.1Q-2022:
01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F]
In a Bridge comprising an S-VLAN component:
Link-local frames with these destination addresses will be trapped to CPU
port which won't conform to IEEE Std 802.1Q-2022:
01-80-C2-00-00-00
Link-local frames with these destination addresses won't be trapped to
CPU port which won't conform to IEEE Std 802.1Q-2022:
01-80-C2-00-00-[04,05,06,07,08,09,0A]
Currently on this switch intellectual property, if the spanning tree Port
State of the reception Port is discarding, link-local frames will be
discarded.
To trap link-local frames regardless of the spanning tree Port State, make
the switch regard them as Bridge Protocol Data Units (BPDUs). This switch
intellectual property only lets the frames regarded as BPDUs bypass the
spanning tree Port State function of the Forwarding Process.
With this change, the only remaining interference is the ingress rules.
When the reception Port has no PVID assigned on software, VLAN-untagged
frames won't be allowed in. There doesn't seem to be a mechanism on the
switch intellectual property to have link-local frames bypass this function
of the Forwarding Process.
Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
Changes in v2:
- Add a Fixes: trailer.
- Slightly adjust the patch log and the comment section.
- Link to v1: https://lore.kernel.org/r/20240407-b4-for-net-mt7530-fix-link-local-when-stp-discarding-v1-1-b4b20ac93457@arinc9.com
---
drivers/net/dsa/mt7530.c | 229 ++++++++++++++++++++++++++++++++++++++++-------
drivers/net/dsa/mt7530.h | 5 ++
2 files changed, 200 insertions(+), 34 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 1035820c2377..fd62b38ae913 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -950,20 +950,173 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
mutex_unlock(&priv->reg_mutex);
}
-/* On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std
- * 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA
- * must only be propagated to C-VLAN and MAC Bridge components. That means
- * VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports,
- * these frames are supposed to be processed by the CPU (software). So we make
- * the switch only forward them to the CPU port. And if received from a CPU
- * port, forward to a single port. The software is responsible of making the
- * switch conform to the latter by setting a single port as destination port on
- * the special tag.
+/* In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer (DLL)
+ * of the Open Systems Interconnection basic reference model (OSI/RM) are
+ * described; the medium access control (MAC) and logical link control (LLC)
+ * sublayers. The MAC sublayer is the one facing the physical layer.
*
- * This switch intellectual property cannot conform to this part of the standard
- * fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC
- * DAs, it also includes :22-FF which the scope of propagation is not supposed
- * to be restricted for these MAC DAs.
+ * In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A
+ * Bridge component comprises a MAC Relay Entity for interconnecting the Ports
+ * of the Bridge, at least two Ports, and higher layer entities with at least a
+ * Spanning Tree Protocol Entity included.
+ *
+ * Each Bridge Port also functions as an end station and shall provide the MAC
+ * Service to an LLC Entity. Each instance of the MAC Service is provided to a
+ * distinct LLC Entity that supports protocol identification, multiplexing, and
+ * demultiplexing, for protocol data unit (PDU) transmission and reception by
+ * one or more higher layer entities.
+ *
+ * It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC
+ * Entity associated with each Bridge Port is modeled as being directly
+ * connected to the attached Local Area Network (LAN).
+ *
+ * On the switch with CPU port architecture, CPU port functions as Management
+ * Port, and the Management Port functionality is provided by software which
+ * functions as an end station. Software is connected to an IEEE 802 LAN that is
+ * wholly contained within the system that incorporates the Bridge. Software
+ * provides access to the LLC Entity associated with each Bridge Port by the
+ * value of the source port field on the special tag on the frame received by
+ * software.
+ *
+ * We call frames that carry control information to determine the active
+ * topology and current extent of each Virtual Local Area Network (VLAN), i.e.,
+ * spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN Registration
+ * Protocol Data Units (MVRPDUs), and frames from other link constrained
+ * protocols, such as Extensible Authentication Protocol over LAN (EAPOL) and
+ * Link Layer Discovery Protocol (LLDP), link-local frames. They are not
+ * forwarded by a Bridge. Permanently configured entries in the filtering
+ * database (FDB) ensure that such frames are discarded by the Forwarding
+ * Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in detail:
+ *
+ * Each of the reserved MAC addresses specified in Table 8-1
+ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be
+ * permanently configured in the FDB in C-VLAN components and ERs.
+ *
+ * Each of the reserved MAC addresses specified in Table 8-2
+ * (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently
+ * configured in the FDB in S-VLAN components.
+ *
+ * Each of the reserved MAC addresses specified in Table 8-3
+ * (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB in
+ * TPMR components.
+ *
+ * The FDB entries for reserved MAC addresses shall specify filtering for all
+ * Bridge Ports and all VIDs. Management shall not provide the capability to
+ * modify or remove entries for reserved MAC addresses.
+ *
+ * The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of
+ * propagation of PDUs within a Bridged Network, as follows:
+ *
+ * The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that no
+ * conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN)
+ * component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward.
+ * PDUs transmitted using this destination address, or any other addresses
+ * that appear in Table 8-1, Table 8-2, and Table 8-3
+ * (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can
+ * therefore travel no further than those stations that can be reached via a
+ * single individual LAN from the originating station.
+ *
+ * The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an
+ * address that no conformant S-VLAN component, C-VLAN component, or MAC
+ * Bridge can forward; however, this address is relayed by a TPMR component.
+ * PDUs using this destination address, or any of the other addresses that
+ * appear in both Table 8-1 and Table 8-2 but not in Table 8-3
+ * (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed by
+ * any TPMRs but will propagate no further than the nearest S-VLAN component,
+ * C-VLAN component, or MAC Bridge.
+ *
+ * The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an address
+ * that no conformant C-VLAN component, MAC Bridge can forward; however, it is
+ * relayed by TPMR components and S-VLAN components. PDUs using this
+ * destination address, or any of the other addresses that appear in Table 8-1
+ * but not in either Table 8-2 or Table 8-3 (01-80-C2-00-00-[00,0B,0C,0D,0F]),
+ * will be relayed by TPMR components and S-VLAN components but will propagate
+ * no further than the nearest C-VLAN component or MAC Bridge.
+ *
+ * Because the LLC Entity associated with each Bridge Port is provided via CPU
+ * port, we must not filter these frames but forward them to CPU port.
+ *
+ * In a Bridge, the transmission Port is majorly decided by ingress and egress
+ * rules, FDB, and spanning tree Port State functions of the Forwarding Process.
+ * For link-local frames, only CPU port should be designated as destination port
+ * in the FDB, and the other functions of the Forwarding Process must not
+ * interfere with the decision of the transmission Port. We call this process
+ * trapping frames to CPU port.
+ *
+ * Therefore, on the switch with CPU port architecture, link-local frames must
+ * be trapped to CPU port, and certain link-local frames received by a Port of a
+ * Bridge comprising a TPMR component or an S-VLAN component must be excluded
+ * from it.
+ *
+ * A Bridge of the switch with CPU port architecture cannot comprise a Two-Port
+ * MAC Relay (TPMR) component as a TPMR component supports only a subset of the
+ * functionality of a MAC Bridge. A Bridge comprising two Ports (Management Port
+ * doesn't count) of this architecture will either function as a standard MAC
+ * Bridge or a standard VLAN Bridge.
+ *
+ * Therefore, a Bridge of this architecture can only comprise S-VLAN components,
+ * C-VLAN components, or MAC Bridge components. Since there's no TPMR component,
+ * we don't need to relay PDUs using the destination addresses specified on the
+ * Nearest non-TPMR section, and the proportion of the Nearest Customer Bridge
+ * section where they must be relayed by TPMR components.
+ *
+ * One option to trap link-local frames to CPU port is to add static FDB entries
+ * with CPU port designated as destination port. However, because that
+ * Independent VLAN Learning (IVL) is being used on every VID, each entry only
+ * applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC
+ * Bridge component or a C-VLAN component, there would have to be 16 times 4096
+ * entries. This switch intellectual property can only hold a maximum of 2048
+ * entries. Using this option, there also isn't a mechanism to prevent
+ * link-local frames from being discarded when the spanning tree Port State of
+ * the reception Port is discarding.
+ *
+ * The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4
+ * registers. Whilst this applies to every VID, it doesn't contain all of the
+ * reserved MAC addresses without affecting the remaining Standard Group MAC
+ * Addresses. The REV_UN frame tag utilised using the RGAC4 register covers the
+ * remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination
+ * addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF
+ * destination addresses which may be relayed by MAC Bridges or VLAN Bridges.
+ * The latter option provides better but not complete conformance.
+ *
+ * This switch intellectual property also does not provide a mechanism to trap
+ * link-local frames with specific destination addresses to CPU port by Bridge,
+ * to conform to the filtering rules for the distinct Bridge components.
+ *
+ * Therefore, regardless of the type of the Bridge component, link-local frames
+ * with these destination addresses will be trapped to CPU port:
+ *
+ * 01-80-C2-00-00-[00,01,02,03,0E]
+ *
+ * In a Bridge comprising a MAC Bridge component or a C-VLAN component:
+ *
+ * Link-local frames with these destination addresses won't be trapped to CPU
+ * port which won't conform to IEEE Std 802.1Q-2022:
+ *
+ * 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F]
+ *
+ * In a Bridge comprising an S-VLAN component:
+ *
+ * Link-local frames with these destination addresses will be trapped to CPU
+ * port which won't conform to IEEE Std 802.1Q-2022:
+ *
+ * 01-80-C2-00-00-00
+ *
+ * Link-local frames with these destination addresses won't be trapped to CPU
+ * port which won't conform to IEEE Std 802.1Q-2022:
+ *
+ * 01-80-C2-00-00-[04,05,06,07,08,09,0A]
+ *
+ * To trap link-local frames to CPU port as conformant as this switch
+ * intellectual property can allow, link-local frames are made to be regarded as
+ * Bridge Protocol Data Units (BPDUs). This is because this switch intellectual
+ * property only lets the frames regarded as BPDUs bypass the spanning tree Port
+ * State function of the Forwarding Process.
+ *
+ * The only remaining interference is the ingress rules. When the reception Port
+ * has no PVID assigned on software, VLAN-untagged frames won't be allowed in.
+ * There doesn't seem to be a mechanism on the switch intellectual property to
+ * have link-local frames bypass this function of the Forwarding Process.
*/
static void
mt753x_trap_frames(struct mt7530_priv *priv)
@@ -971,35 +1124,43 @@ mt753x_trap_frames(struct mt7530_priv *priv)
/* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them
* VLAN-untagged.
*/
- mt7530_rmw(priv, MT753X_BPC, MT753X_PAE_EG_TAG_MASK |
- MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK |
- MT753X_BPDU_PORT_FW_MASK,
- MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) |
- MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_BPDU_CPU_ONLY);
+ mt7530_rmw(priv, MT753X_BPC,
+ MT753X_PAE_BPDU_FR | MT753X_PAE_EG_TAG_MASK |
+ MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK |
+ MT753X_BPDU_PORT_FW_MASK,
+ MT753X_PAE_BPDU_FR |
+ MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) |
+ MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_BPDU_CPU_ONLY);
/* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress
* them VLAN-untagged.
*/
- mt7530_rmw(priv, MT753X_RGAC1, MT753X_R02_EG_TAG_MASK |
- MT753X_R02_PORT_FW_MASK | MT753X_R01_EG_TAG_MASK |
- MT753X_R01_PORT_FW_MASK,
- MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) |
- MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_BPDU_CPU_ONLY);
+ mt7530_rmw(priv, MT753X_RGAC1,
+ MT753X_R02_BPDU_FR | MT753X_R02_EG_TAG_MASK |
+ MT753X_R02_PORT_FW_MASK | MT753X_R01_BPDU_FR |
+ MT753X_R01_EG_TAG_MASK | MT753X_R01_PORT_FW_MASK,
+ MT753X_R02_BPDU_FR |
+ MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) |
+ MT753X_R01_BPDU_FR |
+ MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_BPDU_CPU_ONLY);
/* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress
* them VLAN-untagged.
*/
- mt7530_rmw(priv, MT753X_RGAC2, MT753X_R0E_EG_TAG_MASK |
- MT753X_R0E_PORT_FW_MASK | MT753X_R03_EG_TAG_MASK |
- MT753X_R03_PORT_FW_MASK,
- MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) |
- MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
- MT753X_BPDU_CPU_ONLY);
+ mt7530_rmw(priv, MT753X_RGAC2,
+ MT753X_R0E_BPDU_FR | MT753X_R0E_EG_TAG_MASK |
+ MT753X_R0E_PORT_FW_MASK | MT753X_R03_BPDU_FR |
+ MT753X_R03_EG_TAG_MASK | MT753X_R03_PORT_FW_MASK,
+ MT753X_R0E_BPDU_FR |
+ MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) |
+ MT753X_R03_BPDU_FR |
+ MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
+ MT753X_BPDU_CPU_ONLY);
}
static void
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index d17b318e6ee4..2deffe741484 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -65,6 +65,7 @@ enum mt753x_id {
/* Registers for BPDU and PAE frame control*/
#define MT753X_BPC 0x24
+#define MT753X_PAE_BPDU_FR BIT(25)
#define MT753X_PAE_EG_TAG_MASK GENMASK(24, 22)
#define MT753X_PAE_EG_TAG(x) FIELD_PREP(MT753X_PAE_EG_TAG_MASK, x)
#define MT753X_PAE_PORT_FW_MASK GENMASK(18, 16)
@@ -75,20 +76,24 @@ enum mt753x_id {
/* Register for :01 and :02 MAC DA frame control */
#define MT753X_RGAC1 0x28
+#define MT753X_R02_BPDU_FR BIT(25)
#define MT753X_R02_EG_TAG_MASK GENMASK(24, 22)
#define MT753X_R02_EG_TAG(x) FIELD_PREP(MT753X_R02_EG_TAG_MASK, x)
#define MT753X_R02_PORT_FW_MASK GENMASK(18, 16)
#define MT753X_R02_PORT_FW(x) FIELD_PREP(MT753X_R02_PORT_FW_MASK, x)
+#define MT753X_R01_BPDU_FR BIT(9)
#define MT753X_R01_EG_TAG_MASK GENMASK(8, 6)
#define MT753X_R01_EG_TAG(x) FIELD_PREP(MT753X_R01_EG_TAG_MASK, x)
#define MT753X_R01_PORT_FW_MASK GENMASK(2, 0)
/* Register for :03 and :0E MAC DA frame control */
#define MT753X_RGAC2 0x2c
+#define MT753X_R0E_BPDU_FR BIT(25)
#define MT753X_R0E_EG_TAG_MASK GENMASK(24, 22)
#define MT753X_R0E_EG_TAG(x) FIELD_PREP(MT753X_R0E_EG_TAG_MASK, x)
#define MT753X_R0E_PORT_FW_MASK GENMASK(18, 16)
#define MT753X_R0E_PORT_FW(x) FIELD_PREP(MT753X_R0E_PORT_FW_MASK, x)
+#define MT753X_R03_BPDU_FR BIT(9)
#define MT753X_R03_EG_TAG_MASK GENMASK(8, 6)
#define MT753X_R03_EG_TAG(x) FIELD_PREP(MT753X_R03_EG_TAG_MASK, x)
#define MT753X_R03_PORT_FW_MASK GENMASK(2, 0)
---
base-commit: 365af7ace014ef3fc6f5d0a373c96cc7193db4ce
change-id: 20240401-b4-for-net-mt7530-fix-link-local-when-stp-discarding-6e2a4e3e867a
Best regards,
--
Arınç ÜNAL <arinc.unal@arinc9.com>
_______________________________________________
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 v1 0/6] SiFive cache controller PMU drivers
From: Conor Dooley @ 2024-04-09 15:01 UTC (permalink / raw)
To: Conor Dooley
Cc: Samuel Holland, Will Deacon, Mark Rutland, Eric Lin,
Palmer Dabbelt, devicetree, linux-kernel, Paul Walmsley,
linux-riscv, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <20240216-shopping-unnoticed-e73e72a0e849@wendy>
[-- Attachment #1.1: Type: text/plain, Size: 950 bytes --]
On Fri, Feb 16, 2024 at 10:05:04AM +0000, Conor Dooley wrote:
> On Thu, Feb 15, 2024 at 04:08:12PM -0800, Samuel Holland wrote:
>
> > All three of these cache controllers (with PMUs) have been integrated in
> > SoCs by our customers. However, as none of those SoCs have been publicly
> > announced yet, I cannot include SoC-specific compatible strings in this
> > version of the devicetree bindings.
>
> And I don't want to apply any of those dt-binding patches until then.
> Stuff like "sifive,perfmon-counters" seems like a property that would
> go away with a device-specific compatible, at least for the ccache.
Reading the P550 stuff today reminded me that I had not got around to
looking at this series again. You should be able to use that to satisfy
my wish for some soc-specific compatibles, right?
And w.r.r. the perfmon-counters property, looked to me like Rob was
proposing it not even having to be vendor specific.
[-- 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 v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Cristian Marussi @ 2024-04-09 14:56 UTC (permalink / raw)
To: Rob Herring
Cc: Peng Fan, Krzysztof Kozlowski, Peng Fan (OSS),
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+aVEOPzqddu-X8GLJPex+J6V+_T1qaGHAXgp94+_-ptg@mail.gmail.com>
On Tue, Apr 09, 2024 at 09:09:46AM -0500, Rob Herring wrote:
> On Tue, Apr 9, 2024 at 7:01 AM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
> >
> > On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> > > Hi Krzysztof,
> > >
> > > > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > additionalProperties to true
> > > >
> > > > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > additionalProperties to true
> > > > >
> > > > > On 08/04/2024 08:08, Peng Fan wrote:
> > > > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >> additionalProperties to true
> > > > > >>
> > > > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > > > >>>> additionalProperties to true
> > > > > >>>>
> > > > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>> set additionalProperties to true
> > > > > >>>>>>
> > > > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > > > >>>>>>>> set additionalProperties to true
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > > > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > > > >> warning:
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > > > >>>>>>>>> "
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > > > >>>>>>>>
> > > > > >>>>>>>> I do not see anything addressed here, except making the
> > > > > >>>>>>>> binding accepting anything anywhere...
> > > > > >>>>>>>
> > > > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > > > >>>>>>> protocol
> > > > > >> extension.
> > > > > >>>>>>>
> > > > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > > > suggest.
> > > > > >>>>>>
> > > > > >>>>>> First of all, you cannot affect negatively existing devices
> > > > > >>>>>> (their
> > > > > >>>>>> bindings) and your patch does exactly that. This should make
> > > > > >>>>>> you thing what is the correct approach...
> > > > > >>>>>>
> > > > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > > > >>>>>> did not address that.
> > > > > >>>>>
> > > > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > > > >>>>> =
> > > > > >>>> "arm,scmi";"
> > > > > >>>>
> > > > > >>>> So you claim that your vendor extensions are the same or fully
> > > > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > > > >>>> extensions/protocol valid for arm,scmi?
> > > > > >>>
> > > > > >>> Yes. They are valid for arm,scmi.
> > > > > >>>
> > > > > >>> If yes, why is this in separate binding. If no, why you use
> > > > > >>> someone
> > > > > >>>> else's compatible?
> > > > > >>>
> > > > > >>> Per SCMI Spec
> > > > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > > > >>> this interface
> > > > > >>>
> > > > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > > > >>> the id for their own protocol.
> > > > > >>
> > > > > >> So how are they valid for arm,scmi? I don't understand.
> > > > > >
> > > > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > > > to implement the protocols.
> > > > > >
> > > > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > > > spec
> > > > > compatible.
> > > > >
> > > > > That's not the point. It is obvious that your firmware is compatible
> > > > > with arm,scmi, but what you try to say in this and revised patch is
> > > > > that every arm,scmi is compatible with your implementation. What you
> > > > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > > > NXP, Samsung, TI, Mediatek etc.
> > > > >
> > > > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> > > >
> > > > You are right. I am lost now on how to add vendor ID support, using
> > > > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
> > >
> >
> > Hi Peng,
> >
> > I dont think in the following you will find the solution to the problem,
> > it is just to recap the situation and constraints around vendor protocol
> > bindings.
> >
> > Describing SCMI vendors protocols is tricky because while on one side
> > the protocol node has to be rooted under the main scmi fw DT node (like
> > all the standard protocols) and be 'derived' from the arm,scmi.yaml
> > protocol-node definition, the optional additional properties of the a specific
> > vendor protocol nodes can be customized by each single vendor, and since,
> > as you said, you can have multiple protocols from different vendors sharing the
> > same protocol number, you could have multiple disjoint sets of valid properties
> > allowed under that same protocol node number; so on one side you have to stick
> > to some basic protocol-node defs and be rooted under the SCMI node, while on
> > the other side you will have multiple possibly allowed sets of additional
> > properties to check against, so IOW you cannot anyway just set
> > additionalProperties to false since that will result in no checks at all.
> >
> > As a consequence, at runtime, in the final DTB shipped with a specific
> > platform you should have only one of the possible vendor nodes for each
> > of these overlapping protocols, and the SCMI core at probe time will
> > pick the proper protocol implementation based on the vendor/sub_vendor
> > IDs gathered from the running SCMI fw platform at init: this way you
> > can just build the usual "all-inclusive" defconfig without worrying
> > about vendor protocol clashes since the SCMI core can pick the right
> > protocol implementation, you should just had taken care to provide the
> > proper DTB for your protocol; BUT this also means that it is not possible
> > to add multiple DT bindings based on a 'if vendor' condition since the
> > vendor itself is NOT defined and not needed in the bindings since it is
> > discoverable at runtime.
> >
> > So, after all of this blabbing of mine about this, I am wondering if it
> > is not possible that the solution is to handle each and every vendor
> > protocol node that appears with a block of addtional properties that
> > are picked via a oneOf statement from some external vendor specific
> > yaml.
> > (...in a similar way to how pinctrl additional properties are added...)
> >
> >
> > NOTE THAT the following is just an example of what I mean, it is certainly
> > wrong, incomplete annd maybe just not acceptable (and could cause DT
> > maintainers eyes to bleed :P)...
> >
> > ...so it is just fr the sake of explaining what I mean...
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index e9d3f043c4ed..3c38a1e3ffed 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -278,6 +278,22 @@ properties:
> > required:
> > - reg
> >
> > + protocol@81:
> > + $ref: '#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + patternProperties:
> > + '$':
> > + type: object
>
> Did you mean to have child nodes under the protocol node rather than in it?
... nope ... it is just as bad as my yaml-fu is :P ... but not sure if
vendors has also this needs or plain props will suffice...
>
> > + oneOf:
> > + - $ref: /schemas/vendor-A/scmi-protos.yaml#
> > + - $ref: /schemas/vendor-B/protos.yaml#
>
> Moved up one level, this would work, but it would have to be an
> 'anyOf' because it is possible that 2 vendors have the exact same set
> of properties.
>
ok
> I can think of 2 other ways to structure this.
>
> First, is a specific vendor protocol discoverable? Not that is 0x81
> protocol present, but that 0x81 is vendor Foo's extra special
> value-add protocol? If not, I think we should require a compatible
> string on vendor protocols. Then the base SCMI schema can require just
> that, and each vendor protocol defines its node with a $ref to
> '#/$defs/protocol-node'.
Basically yes it is discoverable, since at runtime the SCMI core, early on,
normally discovers the vendor_id/sub_vendor_id by querying the platform via
Base protocol and then later only loads/initializes (by closest match) the
vendor protocols that are present in the DT AND that has been 'tagged' at
compile time with the same vendor_id/sub_vendor_id tuple (in the vendor
module code, struct scmi_protocol)
Of course you should take care to put the proper protocol@81 node in your
vendor_A DTB for the vendor_A SCMI driver to make use of the additional
vendor_A properties that you have defined under your node as referred
in your vendor-protos.yaml...if you botch that up I will load a protocol
and call your vendor_A driver with a vendor_X DT node.
DT is currrently vendor-agnostic.
>
> The 2nd way is just a variation of the oneOf above, but do we do 1
> file per vendor protocol or 1 file per vendor. Either should be
> doable, just a matter of where 'protocol@81', etc. are defined.
>
Oh, yes mine was just an ill example...one file per vendor will do just
fine: the important thing is that the list and the yaml itself can be
extended as new vendors appears (in a backward compatble way of course)
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] cpufreq: Convert to exit callback returning void
From: Lizhe @ 2024-04-09 14:53 UTC (permalink / raw)
To: mpe, npiggin, christophe.leroy, aneesh.kumar, naveen.n.rao,
rafael, viresh.kumar, andersson, konrad.dybcio, sudeep.holla,
cristian.marussi, thierry.reding, jonathanh
Cc: inuxppc-dev, linux-pm, linux-kernel, linux-arm-msm,
linux-arm-kernel, linux-tegra, Lizhe
For the exit() callback function returning an int type value,
this leads many driver authors mistakenly believing that error
handling can be performed by returning an error code. However,
the returned value is ignored, and to improve this situation,
it is proposed to modify the return type of the exit() callback
function to void.
Signed-off-by: Lizhe <sensor1010@163.com>
---
drivers/cpufreq/pasemi-cpufreq.c | 4 +---
drivers/cpufreq/powernv-cpufreq.c | 4 +---
drivers/cpufreq/ppc_cbe_cpufreq.c | 3 +--
drivers/cpufreq/qcom-cpufreq-hw.c | 4 +---
drivers/cpufreq/qoriq-cpufreq.c | 4 +---
drivers/cpufreq/scmi-cpufreq.c | 4 +---
drivers/cpufreq/scpi-cpufreq.c | 4 +---
drivers/cpufreq/sh-cpufreq.c | 4 +---
drivers/cpufreq/sparc-us2e-cpufreq.c | 3 +--
drivers/cpufreq/sparc-us3-cpufreq.c | 3 +--
drivers/cpufreq/speedstep-centrino.c | 4 +---
drivers/cpufreq/tegra194-cpufreq.c | 4 +---
drivers/cpufreq/vexpress-spc-cpufreq.c | 3 +--
13 files changed, 13 insertions(+), 35 deletions(-)
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 039a66bbe1be..0c00a033bd9e 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -204,7 +204,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
return err;
}
-static int pas_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+static void pas_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
/*
* We don't support CPU hotplug. Don't unmap after the system
@@ -217,8 +217,6 @@ static int pas_cpufreq_cpu_exit(struct cpufreq_policy *policy)
iounmap(sdcasr_mapbase);
if (sdcpwr_mapbase)
iounmap(sdcpwr_mapbase);
-
- return 0;
}
static int pas_cpufreq_target(struct cpufreq_policy *policy,
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index fddbd1ea1635..50c62929f7ca 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -874,7 +874,7 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+static void powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
struct powernv_smp_call_data freq_data;
struct global_pstate_info *gpstates = policy->driver_data;
@@ -886,8 +886,6 @@ static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
del_timer_sync(&gpstates->timer);
kfree(policy->driver_data);
-
- return 0;
}
static int powernv_cpufreq_reboot_notifier(struct notifier_block *nb,
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq.c b/drivers/cpufreq/ppc_cbe_cpufreq.c
index 88afc49941b7..5ee4c7bfdcc5 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -113,10 +113,9 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+static void cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
cbe_cpufreq_pmi_policy_exit(policy);
- return 0;
}
static int cbe_cpufreq_target(struct cpufreq_policy *policy,
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 70b0f21968a0..bb818111162d 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -573,7 +573,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
return qcom_cpufreq_hw_lmh_init(policy, index);
}
-static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
+static void qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
{
struct device *cpu_dev = get_cpu_device(policy->cpu);
struct qcom_cpufreq_data *data = policy->driver_data;
@@ -583,8 +583,6 @@ static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
qcom_cpufreq_hw_lmh_exit(data);
kfree(policy->freq_table);
kfree(data);
-
- return 0;
}
static void qcom_cpufreq_ready(struct cpufreq_policy *policy)
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 0aecaecbb0e6..3519bf34d397 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -225,7 +225,7 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
return -ENODEV;
}
-static int qoriq_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+static void qoriq_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
struct cpu_data *data = policy->driver_data;
@@ -233,8 +233,6 @@ static int qoriq_cpufreq_cpu_exit(struct cpufreq_policy *policy)
kfree(data->table);
kfree(data);
policy->driver_data = NULL;
-
- return 0;
}
static int qoriq_cpufreq_target(struct cpufreq_policy *policy,
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 3b4f6bfb2f4c..bf5f17f0dfb1 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -308,7 +308,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
-static int scmi_cpufreq_exit(struct cpufreq_policy *policy)
+static void scmi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scmi_data *priv = policy->driver_data;
@@ -316,8 +316,6 @@ static int scmi_cpufreq_exit(struct cpufreq_policy *policy)
dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
free_cpumask_var(priv->opp_shared_cpus);
kfree(priv);
-
- return 0;
}
static void scmi_cpufreq_register_em(struct cpufreq_policy *policy)
diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index d33be56983ed..8d73e6e8be2a 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -167,7 +167,7 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
-static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
+static void scpi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scpi_data *priv = policy->driver_data;
@@ -175,8 +175,6 @@ static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
kfree(priv);
-
- return 0;
}
static struct cpufreq_driver scpi_cpufreq_driver = {
diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
index b8704232c27b..aa74036d0420 100644
--- a/drivers/cpufreq/sh-cpufreq.c
+++ b/drivers/cpufreq/sh-cpufreq.c
@@ -135,14 +135,12 @@ static int sh_cpufreq_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int sh_cpufreq_cpu_exit(struct cpufreq_policy *policy)
+static void sh_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
unsigned int cpu = policy->cpu;
struct clk *cpuclk = &per_cpu(sh_cpuclk, cpu);
clk_put(cpuclk);
-
- return 0;
}
static struct cpufreq_driver sh_cpufreq_driver = {
diff --git a/drivers/cpufreq/sparc-us2e-cpufreq.c b/drivers/cpufreq/sparc-us2e-cpufreq.c
index 2783d3d55fce..8a0cd5312a59 100644
--- a/drivers/cpufreq/sparc-us2e-cpufreq.c
+++ b/drivers/cpufreq/sparc-us2e-cpufreq.c
@@ -296,10 +296,9 @@ static int us2e_freq_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int us2e_freq_cpu_exit(struct cpufreq_policy *policy)
+static void us2e_freq_cpu_exit(struct cpufreq_policy *policy)
{
us2e_freq_target(policy, 0);
- return 0;
}
static struct cpufreq_driver cpufreq_us2e_driver = {
diff --git a/drivers/cpufreq/sparc-us3-cpufreq.c b/drivers/cpufreq/sparc-us3-cpufreq.c
index 6c3657679a88..b50f9d13e6d2 100644
--- a/drivers/cpufreq/sparc-us3-cpufreq.c
+++ b/drivers/cpufreq/sparc-us3-cpufreq.c
@@ -140,10 +140,9 @@ static int us3_freq_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int us3_freq_cpu_exit(struct cpufreq_policy *policy)
+static void us3_freq_cpu_exit(struct cpufreq_policy *policy)
{
us3_freq_target(policy, 0);
- return 0;
}
static struct cpufreq_driver cpufreq_us3_driver = {
diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c
index 75b10ecdb60f..28e65bcf7242 100644
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -400,7 +400,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy)
return 0;
}
-static int centrino_cpu_exit(struct cpufreq_policy *policy)
+static void centrino_cpu_exit(struct cpufreq_policy *policy)
{
unsigned int cpu = policy->cpu;
@@ -408,8 +408,6 @@ static int centrino_cpu_exit(struct cpufreq_policy *policy)
return -ENODEV;
per_cpu(centrino_model, cpu) = NULL;
-
- return 0;
}
/**
diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c
index 59865ea455a8..07ea7ed61b68 100644
--- a/drivers/cpufreq/tegra194-cpufreq.c
+++ b/drivers/cpufreq/tegra194-cpufreq.c
@@ -551,14 +551,12 @@ static int tegra194_cpufreq_offline(struct cpufreq_policy *policy)
return 0;
}
-static int tegra194_cpufreq_exit(struct cpufreq_policy *policy)
+static void tegra194_cpufreq_exit(struct cpufreq_policy *policy)
{
struct device *cpu_dev = get_cpu_device(policy->cpu);
dev_pm_opp_remove_all_dynamic(cpu_dev);
dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
-
- return 0;
}
static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c b/drivers/cpufreq/vexpress-spc-cpufreq.c
index 9ac4ea50b874..b2a42cdb9582 100644
--- a/drivers/cpufreq/vexpress-spc-cpufreq.c
+++ b/drivers/cpufreq/vexpress-spc-cpufreq.c
@@ -447,7 +447,7 @@ static int ve_spc_cpufreq_init(struct cpufreq_policy *policy)
return 0;
}
-static int ve_spc_cpufreq_exit(struct cpufreq_policy *policy)
+static void ve_spc_cpufreq_exit(struct cpufreq_policy *policy)
{
struct device *cpu_dev;
@@ -459,7 +459,6 @@ static int ve_spc_cpufreq_exit(struct cpufreq_policy *policy)
}
put_cluster_clk_and_freq_table(cpu_dev, policy->related_cpus);
- return 0;
}
static struct cpufreq_driver ve_spc_cpufreq_driver = {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] PM: EM: Add min/max available performance state limits
From: Hongyan Xia @ 2024-04-09 14:47 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm
Cc: dietmar.eggemann, linux-arm-kernel, sudeep.holla,
cristian.marussi, linux-samsung-soc, rafael, viresh.kumar,
quic_sibis
In-Reply-To: <20240403162315.1458337-2-lukasz.luba@arm.com>
On 03/04/2024 17:23, Lukasz Luba wrote:
> [...]
>
> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
> index 927cc55ba0b3d..1a8b394251cb2 100644
> --- a/kernel/power/energy_model.c
> +++ b/kernel/power/energy_model.c
> @@ -628,6 +628,8 @@ int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
> goto unlock;
>
> dev->em_pd->flags |= flags;
> + dev->em_pd->min_ps = 0;
> + dev->em_pd->max_ps = nr_states - 1;
>
> em_cpufreq_update_efficiencies(dev, dev->em_pd->em_table->state);
>
> @@ -856,3 +858,49 @@ int em_dev_update_chip_binning(struct device *dev)
> return em_recalc_and_update(dev, pd, em_table);
> }
> EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
> +
> +
> +/**
> + * em_update_performance_limits() - Update Energy Model with performance
> + * limits information.
> + * @pd : Performance Domain with EM that has to be updated.
> + * @freq_min_khz : New minimum allowed frequency for this device.
> + * @freq_max_khz : New maximum allowed frequency for this device.
> + *
> + * This function allows to update the EM with information about available
> + * performance levels. It takes the minimum and maximum frequency in kHz
> + * and does internal translation to performance levels.
> + * Returns 0 on success or -EINVAL when failed.
> + */
> +int em_update_performance_limits(struct em_perf_domain *pd,
> + unsigned long freq_min_khz, unsigned long freq_max_khz)
> +{
> + struct em_perf_state *table;
> + int min_ps = -1;
> + int max_ps = -1;
> + int i;
> +
> + if (!pd)
> + return -EINVAL;
> +
> + rcu_read_lock();
> + table = em_perf_state_from_pd(pd);
> +
> + for (i = 0; i < pd->nr_perf_states; i++) {
> + if (freq_min_khz == table[i].frequency)
> + min_ps = i;
> + if (freq_max_khz == table[i].frequency)
> + max_ps = i;
> + }
> + rcu_read_unlock();
> +
> + /* Only update when both are found and sane */
> + if (min_ps < 0 || max_ps < 0 || max_ps < min_ps)
> + return -EINVAL;
> +
> + pd->min_ps = min_ps;
> + pd->max_ps = max_ps;
Are we sure we are protected against multiple simultaneous updates? Or
is this a concern for the caller?
The rest of the patch LGTM.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(em_update_performance_limits);
_______________________________________________
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 05/18] ASoC: mediatek: mt8365: Add common header
From: Alexandre Mergnat @ 2024-04-09 13:42 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Lee Jones, Flora Fu, Jaroslav Kysela, Takashi Iwai, Sumit Semwal,
Christian König, Catalin Marinas, Will Deacon, Rob Herring
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Alexandre Mergnat
In-Reply-To: <20240226-audio-i350-v3-0-16bb2c974c55@baylibre.com>
Add header files for register definition and structure.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
sound/soc/mediatek/mt8365/mt8365-afe-common.h | 491 +++++++++++++
sound/soc/mediatek/mt8365/mt8365-reg.h | 991 ++++++++++++++++++++++++++
2 files changed, 1482 insertions(+)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-common.h b/sound/soc/mediatek/mt8365/mt8365-afe-common.h
new file mode 100644
index 000000000000..4d8f8c4b19e3
--- /dev/null
+++ b/sound/soc/mediatek/mt8365/mt8365-afe-common.h
@@ -0,0 +1,491 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Mediatek 8365 audio driver common definitions
+ *
+ * Copyright (c) 2024 MediaTek Inc.
+ * Authors: Jia Zeng <jia.zeng@mediatek.com>
+ * Alexandre Mergnat <amergnat@baylibre.com>
+ */
+
+#ifndef _MT8365_AFE_COMMON_H_
+#define _MT8365_AFE_COMMON_H_
+
+#define COMMON_CLOCK_FRAMEWORK_API
+#define IDLE_TASK_DRIVER_API
+#define ENABLE_AFE_APLL_TUNER
+
+#include <linux/clk.h>
+#include <linux/list.h>
+#include <linux/regmap.h>
+#include <sound/soc.h>
+#include <sound/asound.h>
+#include "../common/mtk-base-afe.h"
+#include "mt8365-reg.h"
+
+#define ENUM_TO_STR(enum) #enum
+
+#define snd_soc_dai_stream_active_playback(dai) \
+ snd_soc_dai_stream_active(dai, SNDRV_PCM_STREAM_PLAYBACK)
+#define snd_soc_dai_stream_active_capture(dai) \
+ snd_soc_dai_stream_active(dai, SNDRV_PCM_STREAM_CAPTURE)
+
+enum {
+ MT8365_AFE_MEMIF_DL1,
+ MT8365_AFE_MEMIF_DL2,
+ MT8365_AFE_MEMIF_TDM_OUT,
+ /*
+ * MT8365_AFE_MEMIF_SPDIF_OUT,
+ */
+ MT8365_AFE_MEMIF_AWB,
+ MT8365_AFE_MEMIF_VUL,
+ MT8365_AFE_MEMIF_VUL2,
+ MT8365_AFE_MEMIF_VUL3,
+ MT8365_AFE_MEMIF_TDM_IN,
+ /*
+ * MT8365_AFE_MEMIF_SPDIF_IN,
+ */
+ MT8365_AFE_MEMIF_NUM,
+ MT8365_AFE_BACKEND_BASE = MT8365_AFE_MEMIF_NUM,
+ MT8365_AFE_IO_TDM_OUT = MT8365_AFE_BACKEND_BASE,
+ MT8365_AFE_IO_TDM_IN,
+ MT8365_AFE_IO_I2S,
+ MT8365_AFE_IO_2ND_I2S,
+ MT8365_AFE_IO_PCM1,
+ MT8365_AFE_IO_VIRTUAL_DL_SRC,
+ MT8365_AFE_IO_VIRTUAL_TDM_OUT_SRC,
+ MT8365_AFE_IO_VIRTUAL_FM,
+ MT8365_AFE_IO_DMIC,
+ MT8365_AFE_IO_INT_ADDA,
+ MT8365_AFE_IO_GASRC1,
+ MT8365_AFE_IO_GASRC2,
+ MT8365_AFE_IO_TDM_ASRC,
+ MT8365_AFE_IO_HW_GAIN1,
+ MT8365_AFE_IO_HW_GAIN2,
+ MT8365_AFE_BACKEND_END,
+ MT8365_AFE_BACKEND_NUM = (MT8365_AFE_BACKEND_END -
+ MT8365_AFE_BACKEND_BASE),
+};
+
+enum {
+ MT8365_AFE_IRQ1,
+ MT8365_AFE_IRQ2,
+ MT8365_AFE_IRQ3,
+ MT8365_AFE_IRQ4,
+ MT8365_AFE_IRQ5,
+ MT8365_AFE_IRQ6,
+ MT8365_AFE_IRQ7,
+ MT8365_AFE_IRQ8,
+ MT8365_AFE_IRQ9,
+ MT8365_AFE_IRQ10,
+ MT8365_AFE_IRQ_NUM,
+};
+
+enum {
+ MT8365_TOP_CG_AFE,
+ MT8365_TOP_CG_I2S_IN,
+ MT8365_TOP_CG_22M,
+ MT8365_TOP_CG_24M,
+ MT8365_TOP_CG_INTDIR_CK,
+ MT8365_TOP_CG_APLL2_TUNER,
+ MT8365_TOP_CG_APLL_TUNER,
+ MT8365_TOP_CG_SPDIF,
+ MT8365_TOP_CG_TDM_OUT,
+ MT8365_TOP_CG_TDM_IN,
+ MT8365_TOP_CG_ADC,
+ MT8365_TOP_CG_DAC,
+ MT8365_TOP_CG_DAC_PREDIS,
+ MT8365_TOP_CG_TML,
+ MT8365_TOP_CG_I2S1_BCLK,
+ MT8365_TOP_CG_I2S2_BCLK,
+ MT8365_TOP_CG_I2S3_BCLK,
+ MT8365_TOP_CG_I2S4_BCLK,
+ MT8365_TOP_CG_DMIC0_ADC,
+ MT8365_TOP_CG_DMIC1_ADC,
+ MT8365_TOP_CG_DMIC2_ADC,
+ MT8365_TOP_CG_DMIC3_ADC,
+ MT8365_TOP_CG_CONNSYS_I2S_ASRC,
+ MT8365_TOP_CG_GENERAL1_ASRC,
+ MT8365_TOP_CG_GENERAL2_ASRC,
+ MT8365_TOP_CG_TDM_ASRC,
+ MT8365_TOP_CG_NUM
+};
+
+enum {
+ MT8365_CLK_TOP_AUD_SEL,
+ MT8365_CLK_AUD_I2S0_M,
+ MT8365_CLK_AUD_I2S1_M,
+ MT8365_CLK_AUD_I2S2_M,
+ MT8365_CLK_AUD_I2S3_M,
+ MT8365_CLK_ENGEN1,
+ MT8365_CLK_ENGEN2,
+ MT8365_CLK_AUD1,
+ MT8365_CLK_AUD2,
+ MT8365_CLK_I2S0_M_SEL,
+ MT8365_CLK_I2S1_M_SEL,
+ MT8365_CLK_I2S2_M_SEL,
+ MT8365_CLK_I2S3_M_SEL,
+ MT8365_CLK_CLK26M,
+ MT8365_CLK_NUM
+};
+
+enum {
+ MT8365_AFE_APLL1 = 0,
+ MT8365_AFE_APLL2,
+ MT8365_AFE_APLL_NUM,
+};
+
+enum {
+ MT8365_AFE_1ST_I2S = 0,
+ MT8365_AFE_2ND_I2S,
+ MT8365_AFE_I2S_SETS,
+};
+
+enum {
+ MT8365_AFE_I2S_SEPARATE_CLOCK = 0,
+ MT8365_AFE_I2S_SHARED_CLOCK,
+};
+
+enum {
+ MT8365_AFE_TDM_OUT_I2S = 0,
+ MT8365_AFE_TDM_OUT_TDM,
+ MT8365_AFE_TDM_OUT_I2S_32BITS,
+};
+
+enum mt8365_afe_tdm_ch_start {
+ AFE_TDM_CH_START_O28_O29 = 0,
+ AFE_TDM_CH_START_O30_O31,
+ AFE_TDM_CH_START_O32_O33,
+ AFE_TDM_CH_START_O34_O35,
+ AFE_TDM_CH_ZERO,
+};
+
+enum {
+ MT8365_PCM_FORMAT_I2S = 0,
+ MT8365_PCM_FORMAT_EIAJ,
+ MT8365_PCM_FORMAT_PCMA,
+ MT8365_PCM_FORMAT_PCMB,
+};
+
+enum {
+ MT8365_FS_8K = 0,
+ MT8365_FS_11D025K,
+ MT8365_FS_12K,
+ MT8365_FS_384K,
+ MT8365_FS_16K,
+ MT8365_FS_22D05K,
+ MT8365_FS_24K,
+ MT8365_FS_130K,
+ MT8365_FS_32K,
+ MT8365_FS_44D1K,
+ MT8365_FS_48K,
+ MT8365_FS_88D2K,
+ MT8365_FS_96K,
+ MT8365_FS_176D4K,
+ MT8365_FS_192K,
+};
+
+enum {
+ FS_8000HZ = 0, /* 0000b */
+ FS_11025HZ = 1, /* 0001b */
+ FS_12000HZ = 2, /* 0010b */
+ FS_384000HZ = 3, /* 0011b */
+ FS_16000HZ = 4, /* 0100b */
+ FS_22050HZ = 5, /* 0101b */
+ FS_24000HZ = 6, /* 0110b */
+ FS_130000HZ = 7, /* 0111b */
+ FS_32000HZ = 8, /* 1000b */
+ FS_44100HZ = 9, /* 1001b */
+ FS_48000HZ = 10, /* 1010b */
+ FS_88200HZ = 11, /* 1011b */
+ FS_96000HZ = 12, /* 1100b */
+ FS_176400HZ = 13, /* 1101b */
+ FS_192000HZ = 14, /* 1110b */
+ FS_260000HZ = 15, /* 1111b */
+};
+
+enum {
+ MT8365_AFE_DEBUGFS_AFE,
+ MT8365_AFE_DEBUGFS_MEMIF,
+ MT8365_AFE_DEBUGFS_IRQ,
+ MT8365_AFE_DEBUGFS_CONN,
+ MT8365_AFE_DEBUGFS_DBG,
+ MT8365_AFE_DEBUGFS_NUM,
+};
+
+enum {
+ MT8365_AFE_IRQ_DIR_MCU = 0,
+ MT8365_AFE_IRQ_DIR_DSP,
+ MT8365_AFE_IRQ_DIR_BOTH,
+};
+
+/* MCLK */
+enum {
+ MT8365_I2S0_MCK = 0,
+ MT8365_I2S3_MCK,
+ MT8365_MCK_NUM,
+};
+
+struct mt8365_fe_dai_data {
+ bool use_sram;
+ unsigned int sram_phy_addr;
+ void __iomem *sram_vir_addr;
+ unsigned int sram_size;
+};
+
+struct mt8365_be_dai_data {
+ bool prepared[SNDRV_PCM_STREAM_LAST + 1];
+ unsigned int fmt_mode;
+};
+
+#define MT8365_CLK_26M 26000000
+#define MT8365_CLK_24M 24000000
+#define MT8365_CLK_22M 22000000
+#define MT8365_CM_UPDATA_CNT_SET 8
+
+enum mt8365_cm_num {
+ MT8365_CM1 = 0,
+ MT8365_CM2,
+ MT8365_CM_NUM,
+};
+
+enum mt8365_cm2_mux_in {
+ MT8365_FROM_GASRC1 = 1,
+ MT8365_FROM_GASRC2,
+ MT8365_FROM_TDM_ASRC,
+ MT8365_CM_MUX_NUM,
+};
+
+enum cm2_mux_conn_in {
+ GENERAL2_ASRC_OUT_LCH = 0,
+ GENERAL2_ASRC_OUT_RCH = 1,
+ TDM_IN_CH0 = 2,
+ TDM_IN_CH1 = 3,
+ TDM_IN_CH2 = 4,
+ TDM_IN_CH3 = 5,
+ TDM_IN_CH4 = 6,
+ TDM_IN_CH5 = 7,
+ TDM_IN_CH6 = 8,
+ TDM_IN_CH7 = 9,
+ GENERAL1_ASRC_OUT_LCH = 10,
+ GENERAL1_ASRC_OUT_RCH = 11,
+ TDM_OUT_ASRC_CH0 = 12,
+ TDM_OUT_ASRC_CH1 = 13,
+ TDM_OUT_ASRC_CH2 = 14,
+ TDM_OUT_ASRC_CH3 = 15,
+ TDM_OUT_ASRC_CH4 = 16,
+ TDM_OUT_ASRC_CH5 = 17,
+ TDM_OUT_ASRC_CH6 = 18,
+ TDM_OUT_ASRC_CH7 = 19
+};
+
+struct mt8365_cm_ctrl_reg {
+ unsigned int con0;
+ unsigned int con1;
+ unsigned int con2;
+ unsigned int con3;
+ unsigned int con4;
+};
+
+struct mt8365_control_data {
+ bool bypass_cm1;
+ bool bypass_cm2;
+ unsigned int loopback_type;
+};
+
+enum dmic_input_mode {
+ DMIC_MODE_3P25M = 0,
+ DMIC_MODE_1P625M,
+ DMIC_MODE_812P5K,
+ DMIC_MODE_406P25K,
+};
+
+enum iir_mode {
+ IIR_MODE0 = 0,
+ IIR_MODE1,
+ IIR_MODE2,
+ IIR_MODE3,
+ IIR_MODE4,
+ IIR_MODE5,
+};
+
+enum {
+ MT8365_GASRC1 = 0,
+ MT8365_GASRC2,
+ MT8365_GASRC_NUM,
+ MT8365_TDM_ASRC1 = MT8365_GASRC_NUM,
+ MT8365_TDM_ASRC2,
+ MT8365_TDM_ASRC3,
+ MT8365_TDM_ASRC4,
+ MT8365_TDM_ASRC_NUM,
+};
+
+struct mt8365_gasrc_ctrl_reg {
+ unsigned int con0;
+ unsigned int con2;
+ unsigned int con3;
+ unsigned int con4;
+ unsigned int con5;
+ unsigned int con6;
+ unsigned int con9;
+ unsigned int con10;
+ unsigned int con12;
+ unsigned int con13;
+};
+
+struct mt8365_gasrc_data {
+ bool duplex;
+ bool tx_mode;
+ bool cali_on;
+ bool tdm_asrc_out_cm2;
+ bool iir_on;
+};
+
+#ifdef CONFIG_MTK_HIFIXDSP_SUPPORT
+struct mt8365_adsp_data {
+ /* information adsp supply */
+ bool adsp_on;
+ int (*hostless_active)(void);
+ /* information afe supply */
+ int (*set_afe_memif)(struct mtk_base_afe *afe,
+ int memif_id,
+ unsigned int rate,
+ unsigned int channels,
+ snd_pcm_format_t format);
+ int (*set_afe_memif_enable)(struct mtk_base_afe *afe,
+ int memif_id,
+ unsigned int rate,
+ unsigned int period_size,
+ int enable);
+ void (*get_afe_memif_sram)(struct mtk_base_afe *afe,
+ int memif_id,
+ unsigned int *paddr,
+ unsigned int *size);
+ void (*set_afe_init)(struct mtk_base_afe *afe);
+ void (*set_afe_uninit)(struct mtk_base_afe *afe);
+};
+#endif
+
+struct mt8365_afe_private {
+ struct clk *clocks[MT8365_CLK_NUM];
+ struct regmap *topckgen;
+ struct mt8365_fe_dai_data fe_data[MT8365_AFE_MEMIF_NUM];
+ struct mt8365_be_dai_data be_data[MT8365_AFE_BACKEND_NUM];
+ struct mt8365_control_data ctrl_data;
+ struct mt8365_gasrc_data gasrc_data[MT8365_TDM_ASRC_NUM];
+#ifdef CONFIG_MTK_HIFIXDSP_SUPPORT
+ struct mt8365_adsp_data adsp_data;
+#endif
+ int afe_on_ref_cnt;
+ int top_cg_ref_cnt[MT8365_TOP_CG_NUM];
+ void __iomem *afe_sram_vir_addr;
+ unsigned int afe_sram_phy_addr;
+ unsigned int afe_sram_size;
+ /* locks */
+ spinlock_t afe_ctrl_lock;
+ struct mutex afe_clk_mutex; /* Protect & sync APLL TUNER registers access*/
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_dentry[MT8365_AFE_DEBUGFS_NUM];
+#endif
+ int apll_tuner_ref_cnt[MT8365_AFE_APLL_NUM];
+ unsigned int tdm_out_mode;
+ unsigned int cm2_mux_input;
+
+ /* dai */
+ bool dai_on[MT8365_AFE_BACKEND_END];
+ void *dai_priv[MT8365_AFE_BACKEND_END];
+};
+
+static inline u32 rx_frequency_palette(unsigned int fs)
+{
+ /* *
+ * A = (26M / fs) * 64
+ * B = 8125 / A
+ * return = DEC2HEX(B * 2^23)
+ */
+ switch (fs) {
+ case FS_8000HZ: return 0x050000;
+ case FS_11025HZ: return 0x06E400;
+ case FS_12000HZ: return 0x078000;
+ case FS_16000HZ: return 0x0A0000;
+ case FS_22050HZ: return 0x0DC800;
+ case FS_24000HZ: return 0x0F0000;
+ case FS_32000HZ: return 0x140000;
+ case FS_44100HZ: return 0x1B9000;
+ case FS_48000HZ: return 0x1E0000;
+ case FS_88200HZ: return 0x372000;
+ case FS_96000HZ: return 0x3C0000;
+ case FS_176400HZ: return 0x6E4000;
+ case FS_192000HZ: return 0x780000;
+ default: return 0x0;
+ }
+}
+
+static inline u32 AutoRstThHi(unsigned int fs)
+{
+ switch (fs) {
+ case FS_8000HZ: return 0x36000;
+ case FS_11025HZ: return 0x27000;
+ case FS_12000HZ: return 0x24000;
+ case FS_16000HZ: return 0x1B000;
+ case FS_22050HZ: return 0x14000;
+ case FS_24000HZ: return 0x12000;
+ case FS_32000HZ: return 0x0D800;
+ case FS_44100HZ: return 0x09D00;
+ case FS_48000HZ: return 0x08E00;
+ case FS_88200HZ: return 0x04E00;
+ case FS_96000HZ: return 0x04800;
+ case FS_176400HZ: return 0x02700;
+ case FS_192000HZ: return 0x02400;
+ default: return 0x0;
+ }
+}
+
+static inline u32 AutoRstThLo(unsigned int fs)
+{
+ switch (fs) {
+ case FS_8000HZ: return 0x30000;
+ case FS_11025HZ: return 0x23000;
+ case FS_12000HZ: return 0x20000;
+ case FS_16000HZ: return 0x18000;
+ case FS_22050HZ: return 0x11000;
+ case FS_24000HZ: return 0x0FE00;
+ case FS_32000HZ: return 0x0BE00;
+ case FS_44100HZ: return 0x08A00;
+ case FS_48000HZ: return 0x07F00;
+ case FS_88200HZ: return 0x04500;
+ case FS_96000HZ: return 0x04000;
+ case FS_176400HZ: return 0x02300;
+ case FS_192000HZ: return 0x02000;
+ default: return 0x0;
+ }
+}
+
+bool mt8365_afe_clk_group_48k(int sample_rate);
+bool mt8365_afe_rate_supported(unsigned int rate, unsigned int id);
+bool mt8365_afe_channel_supported(unsigned int channel, unsigned int id);
+#ifdef CONFIG_MTK_HIFIXDSP_SUPPORT
+struct mtk_base_afe *mt8365_afe_pcm_get_info(void);
+#endif
+
+int mt8365_dai_i2s_register(struct mtk_base_afe *afe);
+int mt8365_dai_set_priv(struct mtk_base_afe *afe,
+ int id,
+ int priv_size,
+ const void *priv_data);
+
+int mt8365_afe_fs_timing(unsigned int rate);
+
+void mt8365_afe_set_i2s_out_enable(struct mtk_base_afe *afe, bool enable);
+int mt8365_afe_set_i2s_out(struct mtk_base_afe *afe, unsigned int rate, int bit_width);
+
+int mt8365_dai_adda_register(struct mtk_base_afe *afe);
+int mt8365_dai_enable_adda_on(struct mtk_base_afe *afe);
+int mt8365_dai_disable_adda_on(struct mtk_base_afe *afe);
+
+int mt8365_dai_dmic_register(struct mtk_base_afe *afe);
+
+int mt8365_dai_pcm_register(struct mtk_base_afe *afe);
+
+int mt8365_dai_tdm_register(struct mtk_base_afe *afe);
+
+#endif
diff --git a/sound/soc/mediatek/mt8365/mt8365-reg.h b/sound/soc/mediatek/mt8365/mt8365-reg.h
new file mode 100644
index 000000000000..f79ae78b5c1e
--- /dev/null
+++ b/sound/soc/mediatek/mt8365/mt8365-reg.h
@@ -0,0 +1,991 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Mediatek 8365 audio driver reg definition
+ *
+ * Copyright (c) 2024 MediaTek Inc.
+ * Authors: Jia Zeng <jia.zeng@mediatek.com>
+ * Alexandre Mergnat <amergnat@baylibre.com>
+ */
+
+#ifndef _MT8365_REG_H_
+#define _MT8365_REG_H_
+
+#define AUDIO_TOP_CON0 (0x0000)
+#define AUDIO_TOP_CON1 (0x0004)
+#define AUDIO_TOP_CON2 (0x0008)
+#define AUDIO_TOP_CON3 (0x000c)
+
+#define AFE_DAC_CON0 (0x0010)
+#define AFE_DAC_CON1 (0x0014)
+#define AFE_I2S_CON (0x0018)
+#define AFE_CONN0 (0x0020)
+#define AFE_CONN1 (0x0024)
+#define AFE_CONN2 (0x0028)
+#define AFE_CONN3 (0x002c)
+#define AFE_CONN4 (0x0030)
+#define AFE_I2S_CON1 (0x0034)
+#define AFE_I2S_CON2 (0x0038)
+#define AFE_MRGIF_CON (0x003c)
+#define AFE_DL1_BASE (0x0040)
+#define AFE_DL1_CUR (0x0044)
+#define AFE_DL1_END (0x0048)
+#define AFE_I2S_CON3 (0x004c)
+#define AFE_DL2_BASE (0x0050)
+#define AFE_DL2_CUR (0x0054)
+#define AFE_DL2_END (0x0058)
+#define AFE_CONN5 (0x005c)
+#define AFE_AWB_BASE (0x0070)
+#define AFE_AWB_END (0x0078)
+#define AFE_AWB_CUR (0x007c)
+#define AFE_VUL_BASE (0x0080)
+#define AFE_VUL_END (0x0088)
+#define AFE_VUL_CUR (0x008c)
+#define AFE_CONN6 (0x00bc)
+#define AFE_MEMIF_MSB (0x00cc)
+#define AFE_MEMIF_MON0 (0x00d0)
+#define AFE_MEMIF_MON1 (0x00d4)
+#define AFE_MEMIF_MON2 (0x00d8)
+#define AFE_MEMIF_MON3 (0x00dc)
+#define AFE_MEMIF_MON4 (0x00e0)
+#define AFE_MEMIF_MON5 (0x00e4)
+#define AFE_MEMIF_MON6 (0x00e8)
+#define AFE_MEMIF_MON7 (0x00ec)
+#define AFE_MEMIF_MON8 (0x00f0)
+#define AFE_MEMIF_MON9 (0x00f4)
+#define AFE_MEMIF_MON10 (0x00f8)
+#define AFE_MEMIF_MON11 (0x00fc)
+#define AFE_ADDA_DL_SRC2_CON0 (0x0108)
+#define AFE_ADDA_DL_SRC2_CON1 (0x010c)
+#define AFE_ADDA_UL_SRC_CON0 (0x0114)
+#define AFE_ADDA_UL_SRC_CON1 (0x0118)
+#define AFE_ADDA_TOP_CON0 (0x0120)
+#define AFE_ADDA_UL_DL_CON0 (0x0124)
+#define AFE_ADDA_SRC_DEBUG (0x012c)
+#define AFE_ADDA_SRC_DEBUG_MON0 (0x0130)
+#define AFE_ADDA_SRC_DEBUG_MON1 (0x0134)
+#define AFE_ADDA_UL_SRC_MON0 (0x0148)
+#define AFE_ADDA_UL_SRC_MON1 (0x014c)
+#define AFE_SRAM_BOUND (0x0170)
+#define AFE_SECURE_CON (0x0174)
+#define AFE_SECURE_CONN0 (0x0178)
+#define AFE_SIDETONE_DEBUG (0x01d0)
+#define AFE_SIDETONE_MON (0x01d4)
+#define AFE_SIDETONE_CON0 (0x01e0)
+#define AFE_SIDETONE_COEFF (0x01e4)
+#define AFE_SIDETONE_CON1 (0x01e8)
+#define AFE_SIDETONE_GAIN (0x01ec)
+#define AFE_SGEN_CON0 (0x01f0)
+#define AFE_SINEGEN_CON_TDM (0x01f8)
+#define AFE_SINEGEN_CON_TDM_IN (0x01fc)
+#define AFE_TOP_CON0 (0x0200)
+#define AFE_BUS_CFG (0x0240)
+#define AFE_BUS_MON0 (0x0244)
+#define AFE_ADDA_PREDIS_CON0 (0x0260)
+#define AFE_ADDA_PREDIS_CON1 (0x0264)
+#define AFE_CONN_MON0 (0x0280)
+#define AFE_CONN_MON1 (0x0284)
+#define AFE_CONN_MON2 (0x0288)
+#define AFE_CONN_MON3 (0x028c)
+#define AFE_ADDA_IIR_COEF_02_01 (0x0290)
+#define AFE_ADDA_IIR_COEF_04_03 (0x0294)
+#define AFE_ADDA_IIR_COEF_06_05 (0x0298)
+#define AFE_ADDA_IIR_COEF_08_07 (0x029c)
+#define AFE_ADDA_IIR_COEF_10_09 (0x02a0)
+#define AFE_VUL_D2_BASE (0x0350)
+#define AFE_VUL_D2_END (0x0358)
+#define AFE_VUL_D2_CUR (0x035c)
+#define AFE_HDMI_OUT_CON0 (0x0370)
+#define AFE_HDMI_OUT_BASE (0x0374)
+#define AFE_HDMI_OUT_CUR (0x0378)
+#define AFE_HDMI_OUT_END (0x037c)
+#define AFE_SPDIF_OUT_CON0 (0x0380)
+#define AFE_SPDIF_OUT_BASE (0x0384)
+#define AFE_SPDIF_OUT_CUR (0x0388)
+#define AFE_SPDIF_OUT_END (0x038c)
+#define AFE_HDMI_CONN0 (0x0390)
+#define AFE_HDMI_CONN1 (0x0398)
+#define AFE_CONN_TDMIN_CON (0x039c)
+#define AFE_IRQ_MCU_CON (0x03a0)
+#define AFE_IRQ_MCU_STATUS (0x03a4)
+#define AFE_IRQ_MCU_CLR (0x03a8)
+#define AFE_IRQ_MCU_CNT1 (0x03ac)
+#define AFE_IRQ_MCU_CNT2 (0x03b0)
+#define AFE_IRQ_MCU_EN (0x03b4)
+#define AFE_IRQ_MCU_MON2 (0x03b8)
+#define AFE_IRQ_MCU_CNT5 (0x03bc)
+#define AFE_IRQ1_MCU_CNT_MON (0x03c0)
+#define AFE_IRQ2_MCU_CNT_MON (0x03c4)
+#define AFE_IRQ1_MCU_EN_CNT_MON (0x03c8)
+#define AFE_IRQ5_MCU_CNT_MON (0x03cc)
+#define AFE_MEMIF_MINLEN (0x03d0)
+#define AFE_MEMIF_MAXLEN (0x03d4)
+#define AFE_MEMIF_PBUF_SIZE (0x03d8)
+#define AFE_IRQ_MCU_CNT7 (0x03dc)
+#define AFE_IRQ7_MCU_CNT_MON (0x03e0)
+#define AFE_MEMIF_PBUF2_SIZE (0x03ec)
+#define AFE_APLL_TUNER_CFG (0x03f0)
+#define AFE_APLL_TUNER_CFG1 (0x03f4)
+#define AFE_IRQ_MCU_CON2 (0x03f8)
+#define IRQ13_MCU_CNT (0x0408)
+#define IRQ13_MCU_CNT_MON (0x040c)
+#define AFE_GAIN1_CON0 (0x0410)
+#define AFE_GAIN1_CON1 (0x0414)
+#define AFE_GAIN1_CON2 (0x0418)
+#define AFE_GAIN1_CON3 (0x041c)
+#define AFE_GAIN2_CON0 (0x0428)
+#define AFE_GAIN2_CON1 (0x042c)
+#define AFE_GAIN2_CON2 (0x0430)
+#define AFE_GAIN2_CON3 (0x0434)
+#define AFE_GAIN2_CUR (0x043c)
+#define AFE_CONN11 (0x0448)
+#define AFE_CONN12 (0x044c)
+#define AFE_CONN13 (0x0450)
+#define AFE_CONN14 (0x0454)
+#define AFE_CONN15 (0x0458)
+#define AFE_CONN16 (0x045c)
+#define AFE_CONN7 (0x0460)
+#define AFE_CONN8 (0x0464)
+#define AFE_CONN9 (0x0468)
+#define AFE_CONN10 (0x046c)
+#define AFE_CONN21 (0x0470)
+#define AFE_CONN22 (0x0474)
+#define AFE_CONN23 (0x0478)
+#define AFE_CONN24 (0x047c)
+#define AFE_IEC_CFG (0x0480)
+#define AFE_IEC_NSNUM (0x0484)
+#define AFE_IEC_BURST_INFO (0x0488)
+#define AFE_IEC_BURST_LEN (0x048c)
+#define AFE_IEC_NSADR (0x0490)
+#define AFE_CONN_RS (0x0494)
+#define AFE_CONN_DI (0x0498)
+#define AFE_IEC_CHL_STAT0 (0x04a0)
+#define AFE_IEC_CHL_STAT1 (0x04a4)
+#define AFE_IEC_CHR_STAT0 (0x04a8)
+#define AFE_IEC_CHR_STAT1 (0x04ac)
+#define AFE_CONN25 (0x04b0)
+#define AFE_CONN26 (0x04b4)
+#define FPGA_CFG2 (0x04b8)
+#define FPGA_CFG3 (0x04bc)
+#define FPGA_CFG0 (0x04c0)
+#define FPGA_CFG1 (0x04c4)
+#define AFE_SRAM_DELSEL_CON0 (0x04f0)
+#define AFE_SRAM_DELSEL_CON1 (0x04f4)
+#define AFE_SRAM_DELSEL_CON2 (0x04f8)
+#define FPGA_CFG4 (0x04fc)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON0 (0x0500)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON1 (0x0504)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON2 (0x0508)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON3 (0x050c)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON4 (0x0510)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON5 (0x0514)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON6 (0x0518)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON7 (0x051c)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON8 (0x0520)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON9 (0x0524)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON10 (0x0528)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON12 (0x0530)
+#define AFE_TDM_GASRC4_ASRC_2CH_CON13 (0x0534)
+#define PCM_INTF_CON2 (0x0538)
+#define PCM2_INTF_CON (0x053c)
+#define AFE_APB_MON (0x0540)
+#define AFE_CONN34 (0x0544)
+#define AFE_TDM_CON1 (0x0548)
+#define AFE_TDM_CON2 (0x054c)
+#define PCM_INTF_CON1 (0x0550)
+#define AFE_SECURE_MASK_CONN47_1 (0x0554)
+#define AFE_SECURE_MASK_CONN48_1 (0x0558)
+#define AFE_SECURE_MASK_CONN49_1 (0x055c)
+#define AFE_SECURE_MASK_CONN50_1 (0x0560)
+#define AFE_SECURE_MASK_CONN51_1 (0x0564)
+#define AFE_SECURE_MASK_CONN52_1 (0x0568)
+#define AFE_SECURE_MASK_CONN53_1 (0x056c)
+#define AFE_SE_SECURE_CON (0x0570)
+#define AFE_TDM_IN_CON1 (0x0588)
+#define AFE_TDM_IN_CON2 (0x058c)
+#define AFE_TDM_IN_MON1 (0x0590)
+#define AFE_TDM_IN_MON2 (0x0594)
+#define AFE_TDM_IN_MON3 (0x0598)
+#define AFE_DMIC0_UL_SRC_CON0 (0x05b4)
+#define AFE_DMIC0_UL_SRC_CON1 (0x05b8)
+#define AFE_DMIC0_SRC_DEBUG (0x05bc)
+#define AFE_DMIC0_SRC_DEBUG_MON0 (0x05c0)
+#define AFE_DMIC0_UL_SRC_MON0 (0x05c8)
+#define AFE_DMIC0_UL_SRC_MON1 (0x05cc)
+#define AFE_DMIC0_IIR_COEF_02_01 (0x05d0)
+#define AFE_DMIC0_IIR_COEF_04_03 (0x05d4)
+#define AFE_DMIC0_IIR_COEF_06_05 (0x05d8)
+#define AFE_DMIC0_IIR_COEF_08_07 (0x05dc)
+#define AFE_DMIC0_IIR_COEF_10_09 (0x05e0)
+#define AFE_DMIC1_UL_SRC_CON0 (0x0620)
+#define AFE_DMIC1_UL_SRC_CON1 (0x0624)
+#define AFE_DMIC1_SRC_DEBUG (0x0628)
+#define AFE_DMIC1_SRC_DEBUG_MON0 (0x062c)
+#define AFE_DMIC1_UL_SRC_MON0 (0x0634)
+#define AFE_DMIC1_UL_SRC_MON1 (0x0638)
+#define AFE_DMIC1_IIR_COEF_02_01 (0x063c)
+#define AFE_DMIC1_IIR_COEF_04_03 (0x0640)
+#define AFE_DMIC1_IIR_COEF_06_05 (0x0644)
+#define AFE_DMIC1_IIR_COEF_08_07 (0x0648)
+#define AFE_DMIC1_IIR_COEF_10_09 (0x064c)
+#define AFE_SECURE_MASK_CONN39_1 (0x068c)
+#define AFE_SECURE_MASK_CONN40_1 (0x0690)
+#define AFE_SECURE_MASK_CONN41_1 (0x0694)
+#define AFE_SECURE_MASK_CONN42_1 (0x0698)
+#define AFE_SECURE_MASK_CONN43_1 (0x069c)
+#define AFE_SECURE_MASK_CONN44_1 (0x06a0)
+#define AFE_SECURE_MASK_CONN45_1 (0x06a4)
+#define AFE_SECURE_MASK_CONN46_1 (0x06a8)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON0 (0x06c0)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON1 (0x06c4)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON2 (0x06c8)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON3 (0x06cc)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON4 (0x06d0)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON5 (0x06d4)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON6 (0x06d8)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON7 (0x06dc)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON8 (0x06e0)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON9 (0x06e4)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON10 (0x06e8)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON12 (0x06f0)
+#define AFE_TDM_GASRC1_ASRC_2CH_CON13 (0x06f4)
+#define AFE_TDM_ASRC_CON0 (0x06f8)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON0 (0x0700)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON1 (0x0704)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON2 (0x0708)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON3 (0x070c)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON4 (0x0710)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON5 (0x0714)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON6 (0x0718)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON7 (0x071c)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON8 (0x0720)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON9 (0x0724)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON10 (0x0728)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON12 (0x0730)
+#define AFE_TDM_GASRC2_ASRC_2CH_CON13 (0x0734)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON0 (0x0740)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON1 (0x0744)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON2 (0x0748)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON3 (0x074c)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON4 (0x0750)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON5 (0x0754)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON6 (0x0758)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON7 (0x075c)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON8 (0x0760)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON9 (0x0764)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON10 (0x0768)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON12 (0x0770)
+#define AFE_TDM_GASRC3_ASRC_2CH_CON13 (0x0774)
+#define AFE_DMIC2_UL_SRC_CON0 (0x0780)
+#define AFE_DMIC2_UL_SRC_CON1 (0x0784)
+#define AFE_DMIC2_SRC_DEBUG (0x0788)
+#define AFE_DMIC2_SRC_DEBUG_MON0 (0x078c)
+#define AFE_DMIC2_UL_SRC_MON0 (0x0794)
+#define AFE_DMIC2_UL_SRC_MON1 (0x0798)
+#define AFE_DMIC2_IIR_COEF_02_01 (0x079c)
+#define AFE_DMIC2_IIR_COEF_04_03 (0x07a0)
+#define AFE_DMIC2_IIR_COEF_06_05 (0x07a4)
+#define AFE_DMIC2_IIR_COEF_08_07 (0x07a8)
+#define AFE_DMIC2_IIR_COEF_10_09 (0x07ac)
+#define AFE_DMIC3_UL_SRC_CON0 (0x07ec)
+#define AFE_DMIC3_UL_SRC_CON1 (0x07f0)
+#define AFE_DMIC3_SRC_DEBUG (0x07f4)
+#define AFE_DMIC3_SRC_DEBUG_MON0 (0x07f8)
+#define AFE_DMIC3_UL_SRC_MON0 (0x0800)
+#define AFE_DMIC3_UL_SRC_MON1 (0x0804)
+#define AFE_DMIC3_IIR_COEF_02_01 (0x0808)
+#define AFE_DMIC3_IIR_COEF_04_03 (0x080c)
+#define AFE_DMIC3_IIR_COEF_06_05 (0x0810)
+#define AFE_DMIC3_IIR_COEF_08_07 (0x0814)
+#define AFE_DMIC3_IIR_COEF_10_09 (0x0818)
+#define AFE_SECURE_MASK_CONN25_1 (0x0858)
+#define AFE_SECURE_MASK_CONN26_1 (0x085c)
+#define AFE_SECURE_MASK_CONN27_1 (0x0860)
+#define AFE_SECURE_MASK_CONN28_1 (0x0864)
+#define AFE_SECURE_MASK_CONN29_1 (0x0868)
+#define AFE_SECURE_MASK_CONN30_1 (0x086c)
+#define AFE_SECURE_MASK_CONN31_1 (0x0870)
+#define AFE_SECURE_MASK_CONN32_1 (0x0874)
+#define AFE_SECURE_MASK_CONN33_1 (0x0878)
+#define AFE_SECURE_MASK_CONN34_1 (0x087c)
+#define AFE_SECURE_MASK_CONN35_1 (0x0880)
+#define AFE_SECURE_MASK_CONN36_1 (0x0884)
+#define AFE_SECURE_MASK_CONN37_1 (0x0888)
+#define AFE_SECURE_MASK_CONN38_1 (0x088c)
+#define AFE_IRQ_MCU_SCP_EN (0x0890)
+#define AFE_IRQ_MCU_DSP_EN (0x0894)
+#define AFE_IRQ3_MCU_CNT_MON (0x0898)
+#define AFE_IRQ4_MCU_CNT_MON (0x089c)
+#define AFE_IRQ8_MCU_CNT_MON (0x08a0)
+#define AFE_IRQ_MCU_CNT3 (0x08a4)
+#define AFE_IRQ_MCU_CNT4 (0x08a8)
+#define AFE_IRQ_MCU_CNT8 (0x08ac)
+#define AFE_IRQ_MCU_CNT11 (0x08b0)
+#define AFE_IRQ_MCU_CNT12 (0x08b4)
+#define AFE_IRQ11_MCU_CNT_MON (0x08b8)
+#define AFE_IRQ12_MCU_CNT_MON (0x08bc)
+#define AFE_VUL3_BASE (0x08c0)
+#define AFE_VUL3_CUR (0x08c4)
+#define AFE_VUL3_END (0x08c8)
+#define AFE_VUL3_BASE_MSB (0x08d0)
+#define AFE_VUL3_END_MSB (0x08d4)
+#define AFE_IRQ10_MCU_CNT_MON (0x08d8)
+#define AFE_IRQ_MCU_CNT10 (0x08dc)
+#define AFE_IRQ_ACC1_CNT (0x08e0)
+#define AFE_IRQ_ACC2_CNT (0x08e4)
+#define AFE_IRQ_ACC1_CNT_MON1 (0x08e8)
+#define AFE_IRQ_ACC2_CNT_MON (0x08ec)
+#define AFE_TSF_CON (0x08f0)
+#define AFE_TSF_MON (0x08f4)
+#define AFE_IRQ_ACC1_CNT_MON2 (0x08f8)
+#define AFE_SPDIFIN_CFG0 (0x0900)
+#define AFE_SPDIFIN_CFG1 (0x0904)
+#define AFE_SPDIFIN_CHSTS1 (0x0908)
+#define AFE_SPDIFIN_CHSTS2 (0x090c)
+#define AFE_SPDIFIN_CHSTS3 (0x0910)
+#define AFE_SPDIFIN_CHSTS4 (0x0914)
+#define AFE_SPDIFIN_CHSTS5 (0x0918)
+#define AFE_SPDIFIN_CHSTS6 (0x091c)
+#define AFE_SPDIFIN_DEBUG1 (0x0920)
+#define AFE_SPDIFIN_DEBUG2 (0x0924)
+#define AFE_SPDIFIN_DEBUG3 (0x0928)
+#define AFE_SPDIFIN_DEBUG4 (0x092c)
+#define AFE_SPDIFIN_EC (0x0930)
+#define AFE_SPDIFIN_CKLOCK_CFG (0x0934)
+#define AFE_SPDIFIN_BR (0x093c)
+#define AFE_SPDIFIN_BR_DBG1 (0x0940)
+#define AFE_SPDIFIN_INT_EXT (0x0948)
+#define AFE_SPDIFIN_INT_EXT2 (0x094c)
+#define SPDIFIN_FREQ_INFO (0x0950)
+#define SPDIFIN_FREQ_INFO_2 (0x0954)
+#define SPDIFIN_FREQ_INFO_3 (0x0958)
+#define SPDIFIN_FREQ_STATUS (0x095c)
+#define SPDIFIN_USERCODE1 (0x0960)
+#define SPDIFIN_USERCODE2 (0x0964)
+#define SPDIFIN_USERCODE3 (0x0968)
+#define SPDIFIN_USERCODE4 (0x096c)
+#define SPDIFIN_USERCODE5 (0x0970)
+#define SPDIFIN_USERCODE6 (0x0974)
+#define SPDIFIN_USERCODE7 (0x0978)
+#define SPDIFIN_USERCODE8 (0x097c)
+#define SPDIFIN_USERCODE9 (0x0980)
+#define SPDIFIN_USERCODE10 (0x0984)
+#define SPDIFIN_USERCODE11 (0x0988)
+#define SPDIFIN_USERCODE12 (0x098c)
+#define SPDIFIN_MEMIF_CON0 (0x0990)
+#define SPDIFIN_BASE_ADR (0x0994)
+#define SPDIFIN_END_ADR (0x0998)
+#define SPDIFIN_APLL_TUNER_CFG (0x09a0)
+#define SPDIFIN_APLL_TUNER_CFG1 (0x09a4)
+#define SPDIFIN_APLL2_TUNER_CFG (0x09a8)
+#define SPDIFIN_APLL2_TUNER_CFG1 (0x09ac)
+#define SPDIFIN_TYPE_DET (0x09b0)
+#define MPHONE_MULTI_CON0 (0x09b4)
+#define SPDIFIN_CUR_ADR (0x09b8)
+#define AFE_SINEGEN_CON_SPDIFIN (0x09bc)
+#define AFE_HDMI_IN_2CH_CON0 (0x09c0)
+#define AFE_HDMI_IN_2CH_BASE (0x09c4)
+#define AFE_HDMI_IN_2CH_END (0x09c8)
+#define AFE_HDMI_IN_2CH_CUR (0x09cc)
+#define AFE_MEMIF_BUF_MON0 (0x09d0)
+#define AFE_MEMIF_BUF_MON1 (0x09d4)
+#define AFE_MEMIF_BUF_MON2 (0x09d8)
+#define AFE_MEMIF_BUF_MON3 (0x09dc)
+#define AFE_MEMIF_BUF_MON6 (0x09e8)
+#define AFE_MEMIF_BUF_MON7 (0x09ec)
+#define AFE_MEMIF_BUF_MON8 (0x09f0)
+#define AFE_MEMIF_BUF_MON10 (0x09f8)
+#define AFE_MEMIF_BUF_MON11 (0x09fc)
+#define SYSTOP_STC_CONFIG (0x0a00)
+#define AUDIO_STC_STATUS (0x0a04)
+#define SYSTOP_W_STC_H (0x0a08)
+#define SYSTOP_W_STC_L (0x0a0c)
+#define SYSTOP_R_STC_H (0x0a10)
+#define SYSTOP_R_STC_L (0x0a14)
+#define AUDIO_W_STC_H (0x0a18)
+#define AUDIO_W_STC_L (0x0a1c)
+#define AUDIO_R_STC_H (0x0a20)
+#define AUDIO_R_STC_L (0x0a24)
+#define SYSTOP_W_STC2_H (0x0a28)
+#define SYSTOP_W_STC2_L (0x0a2c)
+#define SYSTOP_R_STC2_H (0x0a30)
+#define SYSTOP_R_STC2_L (0x0a34)
+#define AUDIO_W_STC2_H (0x0a38)
+#define AUDIO_W_STC2_L (0x0a3c)
+#define AUDIO_R_STC2_H (0x0a40)
+#define AUDIO_R_STC2_L (0x0a44)
+
+#define AFE_CONN17 (0x0a48)
+#define AFE_CONN18 (0x0a4c)
+#define AFE_CONN19 (0x0a50)
+#define AFE_CONN20 (0x0a54)
+#define AFE_CONN27 (0x0a58)
+#define AFE_CONN28 (0x0a5c)
+#define AFE_CONN29 (0x0a60)
+#define AFE_CONN30 (0x0a64)
+#define AFE_CONN31 (0x0a68)
+#define AFE_CONN32 (0x0a6c)
+#define AFE_CONN33 (0x0a70)
+#define AFE_CONN35 (0x0a74)
+#define AFE_CONN36 (0x0a78)
+#define AFE_CONN37 (0x0a7c)
+#define AFE_CONN38 (0x0a80)
+#define AFE_CONN39 (0x0a84)
+#define AFE_CONN40 (0x0a88)
+#define AFE_CONN41 (0x0a8c)
+#define AFE_CONN42 (0x0a90)
+#define AFE_CONN44 (0x0a94)
+#define AFE_CONN45 (0x0a98)
+#define AFE_CONN46 (0x0a9c)
+#define AFE_CONN47 (0x0aa0)
+#define AFE_CONN_24BIT (0x0aa4)
+#define AFE_CONN0_1 (0x0aa8)
+#define AFE_CONN1_1 (0x0aac)
+#define AFE_CONN2_1 (0x0ab0)
+#define AFE_CONN3_1 (0x0ab4)
+#define AFE_CONN4_1 (0x0ab8)
+#define AFE_CONN5_1 (0x0abc)
+#define AFE_CONN6_1 (0x0ac0)
+#define AFE_CONN7_1 (0x0ac4)
+#define AFE_CONN8_1 (0x0ac8)
+#define AFE_CONN9_1 (0x0acc)
+#define AFE_CONN10_1 (0x0ad0)
+#define AFE_CONN11_1 (0x0ad4)
+#define AFE_CONN12_1 (0x0ad8)
+#define AFE_CONN13_1 (0x0adc)
+#define AFE_CONN14_1 (0x0ae0)
+#define AFE_CONN15_1 (0x0ae4)
+#define AFE_CONN16_1 (0x0ae8)
+#define AFE_CONN17_1 (0x0aec)
+#define AFE_CONN18_1 (0x0af0)
+#define AFE_CONN19_1 (0x0af4)
+#define AFE_CONN43 (0x0af8)
+#define AFE_CONN43_1 (0x0afc)
+#define AFE_CONN21_1 (0x0b00)
+#define AFE_CONN22_1 (0x0b04)
+#define AFE_CONN23_1 (0x0b08)
+#define AFE_CONN24_1 (0x0b0c)
+#define AFE_CONN25_1 (0x0b10)
+#define AFE_CONN26_1 (0x0b14)
+#define AFE_CONN27_1 (0x0b18)
+#define AFE_CONN28_1 (0x0b1c)
+#define AFE_CONN29_1 (0x0b20)
+#define AFE_CONN30_1 (0x0b24)
+#define AFE_CONN31_1 (0x0b28)
+#define AFE_CONN32_1 (0x0b2c)
+#define AFE_CONN33_1 (0x0b30)
+#define AFE_CONN34_1 (0x0b34)
+#define AFE_CONN35_1 (0x0b38)
+#define AFE_CONN36_1 (0x0b3c)
+#define AFE_CONN37_1 (0x0b40)
+#define AFE_CONN38_1 (0x0b44)
+#define AFE_CONN39_1 (0x0b48)
+#define AFE_CONN40_1 (0x0b4c)
+#define AFE_CONN41_1 (0x0b50)
+#define AFE_CONN42_1 (0x0b54)
+#define AFE_CONN44_1 (0x0b58)
+#define AFE_CONN45_1 (0x0b5c)
+#define AFE_CONN46_1 (0x0b60)
+#define AFE_CONN47_1 (0x0b64)
+#define AFE_CONN_RS_1 (0x0b68)
+#define AFE_CONN_DI_1 (0x0b6c)
+#define AFE_CONN_24BIT_1 (0x0b70)
+#define AFE_GAIN1_CUR (0x0b78)
+#define AFE_CONN20_1 (0x0b7c)
+#define AFE_DL1_BASE_MSB (0x0b80)
+#define AFE_DL1_END_MSB (0x0b84)
+#define AFE_DL2_BASE_MSB (0x0b88)
+#define AFE_DL2_END_MSB (0x0b8c)
+#define AFE_AWB_BASE_MSB (0x0b90)
+#define AFE_AWB_END_MSB (0x0b94)
+#define AFE_VUL_BASE_MSB (0x0ba0)
+#define AFE_VUL_END_MSB (0x0ba4)
+#define AFE_VUL_D2_BASE_MSB (0x0ba8)
+#define AFE_VUL_D2_END_MSB (0x0bac)
+#define AFE_HDMI_OUT_BASE_MSB (0x0bb8)
+#define AFE_HDMI_OUT_END_MSB (0x0bbc)
+#define AFE_HDMI_IN_2CH_BASE_MSB (0x0bc0)
+#define AFE_HDMI_IN_2CH_END_MSB (0x0bc4)
+#define AFE_SPDIF_OUT_BASE_MSB (0x0bc8)
+#define AFE_SPDIF_OUT_END_MSB (0x0bcc)
+#define SPDIFIN_BASE_MSB (0x0bd0)
+#define SPDIFIN_END_MSB (0x0bd4)
+#define AFE_DL1_CUR_MSB (0x0bd8)
+#define AFE_DL2_CUR_MSB (0x0bdc)
+#define AFE_AWB_CUR_MSB (0x0be8)
+#define AFE_VUL_CUR_MSB (0x0bf8)
+#define AFE_VUL_D2_CUR_MSB (0x0c04)
+#define AFE_HDMI_OUT_CUR_MSB (0x0c0c)
+#define AFE_HDMI_IN_2CH_CUR_MSB (0x0c10)
+#define AFE_SPDIF_OUT_CUR_MSB (0x0c14)
+#define SPDIFIN_CUR_MSB (0x0c18)
+#define AFE_CONN_REG (0x0c20)
+#define AFE_SECURE_MASK_CONN14_1 (0x0c24)
+#define AFE_SECURE_MASK_CONN15_1 (0x0c28)
+#define AFE_SECURE_MASK_CONN16_1 (0x0c2c)
+#define AFE_SECURE_MASK_CONN17_1 (0x0c30)
+#define AFE_SECURE_MASK_CONN18_1 (0x0c34)
+#define AFE_SECURE_MASK_CONN19_1 (0x0c38)
+#define AFE_SECURE_MASK_CONN20_1 (0x0c3c)
+#define AFE_SECURE_MASK_CONN21_1 (0x0c40)
+#define AFE_SECURE_MASK_CONN22_1 (0x0c44)
+#define AFE_SECURE_MASK_CONN23_1 (0x0c48)
+#define AFE_SECURE_MASK_CONN24_1 (0x0c4c)
+#define AFE_ADDA_DL_SDM_DCCOMP_CON (0x0c50)
+#define AFE_ADDA_DL_SDM_TEST (0x0c54)
+#define AFE_ADDA_DL_DC_COMP_CFG0 (0x0c58)
+#define AFE_ADDA_DL_DC_COMP_CFG1 (0x0c5c)
+#define AFE_ADDA_DL_SDM_FIFO_MON (0x0c60)
+#define AFE_ADDA_DL_SRC_LCH_MON (0x0c64)
+#define AFE_ADDA_DL_SRC_RCH_MON (0x0c68)
+#define AFE_ADDA_DL_SDM_OUT_MON (0x0c6c)
+#define AFE_ADDA_DL_SDM_DITHER_CON (0x0c70)
+
+#define AFE_VUL3_CUR_MSB (0x0c78)
+#define AFE_ASRC_2CH_CON0 (0x0c80)
+#define AFE_ASRC_2CH_CON1 (0x0c84)
+#define AFE_ASRC_2CH_CON2 (0x0c88)
+#define AFE_ASRC_2CH_CON3 (0x0c8c)
+#define AFE_ASRC_2CH_CON4 (0x0c90)
+#define AFE_ASRC_2CH_CON5 (0x0c94)
+#define AFE_ASRC_2CH_CON6 (0x0c98)
+#define AFE_ASRC_2CH_CON7 (0x0c9c)
+#define AFE_ASRC_2CH_CON8 (0x0ca0)
+#define AFE_ASRC_2CH_CON9 (0x0ca4)
+#define AFE_ASRC_2CH_CON10 (0x0ca8)
+#define AFE_ASRC_2CH_CON12 (0x0cb0)
+#define AFE_ASRC_2CH_CON13 (0x0cb4)
+
+#define AFE_PCM_TX_ASRC_2CH_CON0 (0x0cc0)
+#define AFE_PCM_TX_ASRC_2CH_CON1 (0x0cc4)
+#define AFE_PCM_TX_ASRC_2CH_CON2 (0x0cc8)
+#define AFE_PCM_TX_ASRC_2CH_CON3 (0x0ccc)
+#define AFE_PCM_TX_ASRC_2CH_CON4 (0x0cd0)
+#define AFE_PCM_TX_ASRC_2CH_CON5 (0x0cd4)
+#define AFE_PCM_TX_ASRC_2CH_CON6 (0x0cd8)
+#define AFE_PCM_TX_ASRC_2CH_CON7 (0x0cdc)
+#define AFE_PCM_TX_ASRC_2CH_CON8 (0x0ce0)
+#define AFE_PCM_TX_ASRC_2CH_CON9 (0x0ce4)
+#define AFE_PCM_TX_ASRC_2CH_CON10 (0x0ce8)
+#define AFE_PCM_TX_ASRC_2CH_CON12 (0x0cf0)
+#define AFE_PCM_TX_ASRC_2CH_CON13 (0x0cf4)
+#define AFE_PCM_RX_ASRC_2CH_CON0 (0x0d00)
+#define AFE_PCM_RX_ASRC_2CH_CON1 (0x0d04)
+#define AFE_PCM_RX_ASRC_2CH_CON2 (0x0d08)
+#define AFE_PCM_RX_ASRC_2CH_CON3 (0x0d0c)
+#define AFE_PCM_RX_ASRC_2CH_CON4 (0x0d10)
+#define AFE_PCM_RX_ASRC_2CH_CON5 (0x0d14)
+#define AFE_PCM_RX_ASRC_2CH_CON6 (0x0d18)
+#define AFE_PCM_RX_ASRC_2CH_CON7 (0x0d1c)
+#define AFE_PCM_RX_ASRC_2CH_CON8 (0x0d20)
+#define AFE_PCM_RX_ASRC_2CH_CON9 (0x0d24)
+#define AFE_PCM_RX_ASRC_2CH_CON10 (0x0d28)
+#define AFE_PCM_RX_ASRC_2CH_CON12 (0x0d30)
+#define AFE_PCM_RX_ASRC_2CH_CON13 (0x0d34)
+
+#define AFE_ADDA_PREDIS_CON2 (0x0d40)
+#define AFE_ADDA_PREDIS_CON3 (0x0d44)
+#define AFE_SECURE_MASK_CONN4_1 (0x0d48)
+#define AFE_SECURE_MASK_CONN5_1 (0x0d4c)
+#define AFE_SECURE_MASK_CONN6_1 (0x0d50)
+#define AFE_SECURE_MASK_CONN7_1 (0x0d54)
+#define AFE_SECURE_MASK_CONN8_1 (0x0d58)
+#define AFE_SECURE_MASK_CONN9_1 (0x0d5c)
+#define AFE_SECURE_MASK_CONN10_1 (0x0d60)
+#define AFE_SECURE_MASK_CONN11_1 (0x0d64)
+#define AFE_SECURE_MASK_CONN12_1 (0x0d68)
+#define AFE_SECURE_MASK_CONN13_1 (0x0d6c)
+#define AFE_MEMIF_MON12 (0x0d70)
+#define AFE_MEMIF_MON13 (0x0d74)
+#define AFE_MEMIF_MON14 (0x0d78)
+#define AFE_MEMIF_MON15 (0x0d7c)
+#define AFE_SECURE_MASK_CONN42 (0x0dbc)
+#define AFE_SECURE_MASK_CONN43 (0x0dc0)
+#define AFE_SECURE_MASK_CONN44 (0x0dc4)
+#define AFE_SECURE_MASK_CONN45 (0x0dc8)
+#define AFE_SECURE_MASK_CONN46 (0x0dcc)
+#define AFE_HD_ENGEN_ENABLE (0x0dd0)
+#define AFE_SECURE_MASK_CONN47 (0x0dd4)
+#define AFE_SECURE_MASK_CONN48 (0x0dd8)
+#define AFE_SECURE_MASK_CONN49 (0x0ddc)
+#define AFE_SECURE_MASK_CONN50 (0x0de0)
+#define AFE_SECURE_MASK_CONN51 (0x0de4)
+#define AFE_SECURE_MASK_CONN52 (0x0de8)
+#define AFE_SECURE_MASK_CONN53 (0x0dec)
+#define AFE_SECURE_MASK_CONN0_1 (0x0df0)
+#define AFE_SECURE_MASK_CONN1_1 (0x0df4)
+#define AFE_SECURE_MASK_CONN2_1 (0x0df8)
+#define AFE_SECURE_MASK_CONN3_1 (0x0dfc)
+
+#define AFE_ADDA_MTKAIF_CFG0 (0x0e00)
+#define AFE_ADDA_MTKAIF_SYNCWORD_CFG (0x0e14)
+#define AFE_ADDA_MTKAIF_RX_CFG0 (0x0e20)
+#define AFE_ADDA_MTKAIF_RX_CFG1 (0x0e24)
+#define AFE_ADDA_MTKAIF_RX_CFG2 (0x0e28)
+#define AFE_ADDA_MTKAIF_MON0 (0x0e34)
+#define AFE_ADDA_MTKAIF_MON1 (0x0e38)
+#define AFE_AUD_PAD_TOP (0x0e40)
+
+#define AFE_CM1_CON4 (0x0e48)
+#define AFE_CM2_CON4 (0x0e4c)
+#define AFE_CM1_CON0 (0x0e50)
+#define AFE_CM1_CON1 (0x0e54)
+#define AFE_CM1_CON2 (0x0e58)
+#define AFE_CM1_CON3 (0x0e5c)
+#define AFE_CM2_CON0 (0x0e60)
+#define AFE_CM2_CON1 (0x0e64)
+#define AFE_CM2_CON2 (0x0e68)
+#define AFE_CM2_CON3 (0x0e6c)
+#define AFE_CM2_CONN0 (0x0e70)
+#define AFE_CM2_CONN1 (0x0e74)
+#define AFE_CM2_CONN2 (0x0e78)
+
+#define AFE_GENERAL1_ASRC_2CH_CON0 (0x0e80)
+#define AFE_GENERAL1_ASRC_2CH_CON1 (0x0e84)
+#define AFE_GENERAL1_ASRC_2CH_CON2 (0x0e88)
+#define AFE_GENERAL1_ASRC_2CH_CON3 (0x0e8c)
+#define AFE_GENERAL1_ASRC_2CH_CON4 (0x0e90)
+#define AFE_GENERAL1_ASRC_2CH_CON5 (0x0e94)
+#define AFE_GENERAL1_ASRC_2CH_CON6 (0x0e98)
+#define AFE_GENERAL1_ASRC_2CH_CON7 (0x0e9c)
+#define AFE_GENERAL1_ASRC_2CH_CON8 (0x0ea0)
+#define AFE_GENERAL1_ASRC_2CH_CON9 (0x0ea4)
+#define AFE_GENERAL1_ASRC_2CH_CON10 (0x0ea8)
+#define AFE_GENERAL1_ASRC_2CH_CON12 (0x0eb0)
+#define AFE_GENERAL1_ASRC_2CH_CON13 (0x0eb4)
+#define GENERAL_ASRC_MODE (0x0eb8)
+#define GENERAL_ASRC_EN_ON (0x0ebc)
+
+#define AFE_CONN48 (0x0ec0)
+#define AFE_CONN49 (0x0ec4)
+#define AFE_CONN50 (0x0ec8)
+#define AFE_CONN51 (0x0ecc)
+#define AFE_CONN52 (0x0ed0)
+#define AFE_CONN53 (0x0ed4)
+#define AFE_CONN48_1 (0x0ee0)
+#define AFE_CONN49_1 (0x0ee4)
+#define AFE_CONN50_1 (0x0ee8)
+#define AFE_CONN51_1 (0x0eec)
+#define AFE_CONN52_1 (0x0ef0)
+#define AFE_CONN53_1 (0x0ef4)
+
+#define AFE_GENERAL2_ASRC_2CH_CON0 (0x0f00)
+#define AFE_GENERAL2_ASRC_2CH_CON1 (0x0f04)
+#define AFE_GENERAL2_ASRC_2CH_CON2 (0x0f08)
+#define AFE_GENERAL2_ASRC_2CH_CON3 (0x0f0c)
+#define AFE_GENERAL2_ASRC_2CH_CON4 (0x0f10)
+#define AFE_GENERAL2_ASRC_2CH_CON5 (0x0f14)
+#define AFE_GENERAL2_ASRC_2CH_CON6 (0x0f18)
+#define AFE_GENERAL2_ASRC_2CH_CON7 (0x0f1c)
+#define AFE_GENERAL2_ASRC_2CH_CON8 (0x0f20)
+#define AFE_GENERAL2_ASRC_2CH_CON9 (0x0f24)
+#define AFE_GENERAL2_ASRC_2CH_CON10 (0x0f28)
+#define AFE_GENERAL2_ASRC_2CH_CON12 (0x0f30)
+#define AFE_GENERAL2_ASRC_2CH_CON13 (0x0f34)
+
+#define AFE_SECURE_MASK_CONN28 (0x0f48)
+#define AFE_SECURE_MASK_CONN29 (0x0f4c)
+#define AFE_SECURE_MASK_CONN30 (0x0f50)
+#define AFE_SECURE_MASK_CONN31 (0x0f54)
+#define AFE_SECURE_MASK_CONN32 (0x0f58)
+#define AFE_SECURE_MASK_CONN33 (0x0f5c)
+#define AFE_SECURE_MASK_CONN34 (0x0f60)
+#define AFE_SECURE_MASK_CONN35 (0x0f64)
+#define AFE_SECURE_MASK_CONN36 (0x0f68)
+#define AFE_SECURE_MASK_CONN37 (0x0f6c)
+#define AFE_SECURE_MASK_CONN38 (0x0f70)
+#define AFE_SECURE_MASK_CONN39 (0x0f74)
+#define AFE_SECURE_MASK_CONN40 (0x0f78)
+#define AFE_SECURE_MASK_CONN41 (0x0f7c)
+#define AFE_SIDEBAND0 (0x0f80)
+#define AFE_SIDEBAND1 (0x0f84)
+#define AFE_SECURE_SIDEBAND0 (0x0f88)
+#define AFE_SECURE_SIDEBAND1 (0x0f8c)
+#define AFE_SECURE_MASK_CONN0 (0x0f90)
+#define AFE_SECURE_MASK_CONN1 (0x0f94)
+#define AFE_SECURE_MASK_CONN2 (0x0f98)
+#define AFE_SECURE_MASK_CONN3 (0x0f9c)
+#define AFE_SECURE_MASK_CONN4 (0x0fa0)
+#define AFE_SECURE_MASK_CONN5 (0x0fa4)
+#define AFE_SECURE_MASK_CONN6 (0x0fa8)
+#define AFE_SECURE_MASK_CONN7 (0x0fac)
+#define AFE_SECURE_MASK_CONN8 (0x0fb0)
+#define AFE_SECURE_MASK_CONN9 (0x0fb4)
+#define AFE_SECURE_MASK_CONN10 (0x0fb8)
+#define AFE_SECURE_MASK_CONN11 (0x0fbc)
+#define AFE_SECURE_MASK_CONN12 (0x0fc0)
+#define AFE_SECURE_MASK_CONN13 (0x0fc4)
+#define AFE_SECURE_MASK_CONN14 (0x0fc8)
+#define AFE_SECURE_MASK_CONN15 (0x0fcc)
+#define AFE_SECURE_MASK_CONN16 (0x0fd0)
+#define AFE_SECURE_MASK_CONN17 (0x0fd4)
+#define AFE_SECURE_MASK_CONN18 (0x0fd8)
+#define AFE_SECURE_MASK_CONN19 (0x0fdc)
+#define AFE_SECURE_MASK_CONN20 (0x0fe0)
+#define AFE_SECURE_MASK_CONN21 (0x0fe4)
+#define AFE_SECURE_MASK_CONN22 (0x0fe8)
+#define AFE_SECURE_MASK_CONN23 (0x0fec)
+#define AFE_SECURE_MASK_CONN24 (0x0ff0)
+#define AFE_SECURE_MASK_CONN25 (0x0ff4)
+#define AFE_SECURE_MASK_CONN26 (0x0ff8)
+#define AFE_SECURE_MASK_CONN27 (0x0ffc)
+
+#define MAX_REGISTER AFE_SECURE_MASK_CONN27
+
+#define AFE_IRQ_STATUS_BITS 0x3ff
+
+/* AUDIO_TOP_CON0 (0x0000) */
+#define AUD_TCON0_PDN_TML BIT(27)
+#define AUD_TCON0_PDN_DAC_PREDIS BIT(26)
+#define AUD_TCON0_PDN_DAC BIT(25)
+#define AUD_TCON0_PDN_ADC BIT(24)
+#define AUD_TCON0_PDN_TDM_IN BIT(23)
+#define AUD_TCON0_PDN_TDM_OUT BIT(22)
+#define AUD_TCON0_PDN_SPDIF BIT(21)
+#define AUD_TCON0_PDN_APLL_TUNER BIT(19)
+#define AUD_TCON0_PDN_APLL2_TUNER BIT(18)
+#define AUD_TCON0_PDN_INTDIR BIT(15)
+#define AUD_TCON0_PDN_24M BIT(9)
+#define AUD_TCON0_PDN_22M BIT(8)
+#define AUD_TCON0_PDN_I2S_IN BIT(6)
+#define AUD_TCON0_PDN_AFE BIT(2)
+
+/* AUDIO_TOP_CON1 (0x0004) */
+#define AUD_TCON1_PDN_TDM_ASRC BIT(15)
+#define AUD_TCON1_PDN_GENERAL2_ASRC BIT(14)
+#define AUD_TCON1_PDN_GENERAL1_ASRC BIT(13)
+#define AUD_TCON1_PDN_CONNSYS_I2S_ASRC BIT(12)
+#define AUD_TCON1_PDN_DMIC3_ADC BIT(11)
+#define AUD_TCON1_PDN_DMIC2_ADC BIT(10)
+#define AUD_TCON1_PDN_DMIC1_ADC BIT(9)
+#define AUD_TCON1_PDN_DMIC0_ADC BIT(8)
+#define AUD_TCON1_PDN_I2S4_BCLK BIT(7)
+#define AUD_TCON1_PDN_I2S3_BCLK BIT(6)
+#define AUD_TCON1_PDN_I2S2_BCLK BIT(5)
+#define AUD_TCON1_PDN_I2S1_BCLK BIT(4)
+
+/* AUDIO_TOP_CON3 (0x000C) */
+#define AUD_TCON3_HDMI_BCK_INV BIT(3)
+
+/* AFE_I2S_CON (0x0018) */
+#define AFE_I2S_CON_PHASE_SHIFT_FIX BIT(31)
+#define AFE_I2S_CON_FROM_IO_MUX BIT(28)
+#define AFE_I2S_CON_LOW_JITTER_CLK BIT(12)
+#define AFE_I2S_CON_RATE_MASK GENMASK(11, 8)
+#define AFE_I2S_CON_FORMAT_I2S BIT(3)
+#define AFE_I2S_CON_SRC_SLAVE BIT(2)
+
+/* AFE_ASRC_2CH_CON0 */
+#define ONE_HEART BIT(31)
+#define CHSET_STR_CLR BIT(4)
+#define COEFF_SRAM_CTRL BIT(1)
+#define ASM_ON BIT(0)
+
+/* CON2 */
+#define O16BIT BIT(19)
+#define CLR_IIR_HISTORY BIT(17)
+#define IS_MONO BIT(16)
+#define IIR_EN BIT(11)
+#define IIR_STAGE_MASK GENMASK(10, 8)
+
+/* CON5 */
+#define CALI_CYCLE_MASK GENMASK(31, 16)
+#define CALI_64_CYCLE FIELD_PREP(CALI_CYCLE_MASK, 0x3F)
+#define CALI_96_CYCLE FIELD_PREP(CALI_CYCLE_MASK, 0x5F)
+#define CALI_441_CYCLE FIELD_PREP(CALI_CYCLE_MASK, 0x1B8)
+
+#define CALI_AUTORST BIT(15)
+#define AUTO_TUNE_FREQ5 BIT(12)
+#define COMP_FREQ_RES BIT(11)
+
+#define CALI_SEL_MASK GENMASK(9, 8)
+#define CALI_SEL_00 FIELD_PREP(CALI_SEL_MASK, 0)
+#define CALI_SEL_01 FIELD_PREP(CALI_SEL_MASK, 1)
+
+#define CALI_BP_DGL BIT(7) /* Bypass the deglitch circuit */
+#define AUTO_TUNE_FREQ4 BIT(3)
+#define CALI_AUTO_RESTART BIT(2)
+#define CALI_USE_FREQ_OUT BIT(1)
+#define CALI_ON BIT(0)
+
+#define AFE_I2S_CON_WLEN_32BIT BIT(1)
+#define AFE_I2S_CON_EN BIT(0)
+
+#define AFE_CONN3_I03_O03_S BIT(3)
+#define AFE_CONN4_I04_O04_S BIT(4)
+#define AFE_CONN4_I03_O04_S BIT(3)
+
+/* AFE_I2S_CON1 (0x0034) */
+#define AFE_I2S_CON1_I2S2_TO_PAD BIT(18)
+#define AFE_I2S_CON1_TDMOUT_TO_PAD (0 << 18)
+#define AFE_I2S_CON1_RATE GENMASK(11, 8)
+#define AFE_I2S_CON1_FORMAT_I2S BIT(3)
+#define AFE_I2S_CON1_WLEN_32BIT BIT(1)
+#define AFE_I2S_CON1_EN BIT(0)
+
+/* AFE_I2S_CON2 (0x0038) */
+#define AFE_I2S_CON2_LOW_JITTER_CLK BIT(12)
+#define AFE_I2S_CON2_RATE GENMASK(11, 8)
+#define AFE_I2S_CON2_FORMAT_I2S BIT(3)
+#define AFE_I2S_CON2_WLEN_32BIT BIT(1)
+#define AFE_I2S_CON2_EN BIT(0)
+
+/* AFE_I2S_CON3 (0x004C) */
+#define AFE_I2S_CON3_LOW_JITTER_CLK BIT(12)
+#define AFE_I2S_CON3_RATE GENMASK(11, 8)
+#define AFE_I2S_CON3_FORMAT_I2S BIT(3)
+#define AFE_I2S_CON3_WLEN_32BIT BIT(1)
+#define AFE_I2S_CON3_EN BIT(0)
+
+/* AFE_ADDA_DL_SRC2_CON0 (0x0108) */
+#define AFE_ADDA_DL_SAMPLING_RATE GENMASK(31, 28)
+#define AFE_ADDA_DL_8X_UPSAMPLE GENMASK(25, 24)
+#define AFE_ADDA_DL_MUTE_OFF_CH1 BIT(12)
+#define AFE_ADDA_DL_MUTE_OFF_CH2 BIT(11)
+#define AFE_ADDA_DL_VOICE_DATA BIT(5)
+#define AFE_ADDA_DL_DEGRADE_GAIN BIT(1)
+
+/* AFE_ADDA_UL_SRC_CON0 (0x0114) */
+#define AFE_ADDA_UL_SAMPLING_RATE GENMASK(19, 17)
+
+/* AFE_ADDA_UL_DL_CON0 */
+#define AFE_ADDA_UL_DL_ADDA_AFE_ON BIT(0)
+#define AFE_ADDA_UL_DL_DMIC_CLKDIV_ON BIT(1)
+
+/* AFE_APLL_TUNER_CFG (0x03f0) */
+#define AFE_APLL_TUNER_CFG_MASK GENMASK(15, 1)
+#define AFE_APLL_TUNER_CFG_EN_MASK BIT(0)
+
+/* AFE_APLL_TUNER_CFG1 (0x03f4) */
+#define AFE_APLL_TUNER_CFG1_MASK GENMASK(15, 1)
+#define AFE_APLL_TUNER_CFG1_EN_MASK BIT(0)
+
+/* PCM_INTF_CON1 (0x0550) */
+#define PCM_INTF_CON1_EXT_MODEM BIT(17)
+#define PCM_INTF_CON1_16BIT (0 << 16)
+#define PCM_INTF_CON1_24BIT BIT(16)
+#define PCM_INTF_CON1_32BCK (0 << 14)
+#define PCM_INTF_CON1_64BCK BIT(14)
+#define PCM_INTF_CON1_MASTER_MODE (0 << 5)
+#define PCM_INTF_CON1_SLAVE_MODE BIT(5)
+#define PCM_INTF_CON1_FS_MASK GENMASK(4, 3)
+#define PCM_INTF_CON1_FS_8K FIELD_PREP(PCM_INTF_CON1_FS_MASK, 0)
+#define PCM_INTF_CON1_FS_16K FIELD_PREP(PCM_INTF_CON1_FS_MASK, 1)
+#define PCM_INTF_CON1_FS_32K FIELD_PREP(PCM_INTF_CON1_FS_MASK, 2)
+#define PCM_INTF_CON1_FS_48K FIELD_PREP(PCM_INTF_CON1_FS_MASK, 3)
+#define PCM_INTF_CON1_SYNC_LEN_MASK GENMASK(13, 9)
+#define PCM_INTF_CON1_SYNC_LEN(x) FIELD_PREP(PCM_INTF_CON1_SYNC_LEN_MASK, ((x) - 1))
+#define PCM_INTF_CON1_FORMAT_MASK GENMASK(2, 1)
+#define PCM_INTF_CON1_SYNC_OUT_INV BIT(23)
+#define PCM_INTF_CON1_BCLK_OUT_INV BIT(22)
+#define PCM_INTF_CON1_SYNC_IN_INV BIT(21)
+#define PCM_INTF_CON1_BCLK_IN_INV BIT(20)
+#define PCM_INTF_CON1_BYPASS_ASRC BIT(6)
+#define PCM_INTF_CON1_EN BIT(0)
+#define PCM_INTF_CON1_CONFIG_MASK (0xf3fffe)
+
+/* AFE_DMIC0_UL_SRC_CON0 (0x05b4)
+ * AFE_DMIC1_UL_SRC_CON0 (0x0620)
+ * AFE_DMIC2_UL_SRC_CON0 (0x0780)
+ * AFE_DMIC3_UL_SRC_CON0 (0x07ec)
+ */
+#define DMIC_TOP_CON_CK_PHASE_SEL_CH1 GENMASK(29, 27)
+#define DMIC_TOP_CON_CK_PHASE_SEL_CH2 GENMASK(26, 24)
+#define DMIC_TOP_CON_TWO_WIRE_MODE BIT(23)
+#define DMIC_TOP_CON_CH2_ON BIT(22)
+#define DMIC_TOP_CON_CH1_ON BIT(21)
+#define DMIC_TOP_CON_VOICE_MODE_MASK GENMASK(19, 17)
+#define DMIC_TOP_CON_VOICE_MODE_8K FIELD_PREP(DMIC_TOP_CON_VOICE_MODE_MASK, 0)
+#define DMIC_TOP_CON_VOICE_MODE_16K FIELD_PREP(DMIC_TOP_CON_VOICE_MODE_MASK, 1)
+#define DMIC_TOP_CON_VOICE_MODE_32K FIELD_PREP(DMIC_TOP_CON_VOICE_MODE_MASK, 2)
+#define DMIC_TOP_CON_VOICE_MODE_48K FIELD_PREP(DMIC_TOP_CON_VOICE_MODE_MASK, 3)
+#define DMIC_TOP_CON_LOW_POWER_MODE_MASK GENMASK(15, 14)
+#define DMIC_TOP_CON_LOW_POWER_MODE(x) FIELD_PREP(DMIC_TOP_CON_LOW_POWER_MODE_MASK, (x))
+#define DMIC_TOP_CON_IIR_ON BIT(10)
+#define DMIC_TOP_CON_IIR_MODE GENMASK(9, 7)
+#define DMIC_TOP_CON_INPUT_MODE BIT(5)
+#define DMIC_TOP_CON_SDM3_LEVEL_MODE BIT(1)
+#define DMIC_TOP_CON_SRC_ON BIT(0)
+#define DMIC_TOP_CON_SDM3_DE_SELECT (0 << 1)
+#define DMIC_TOP_CON_CONFIG_MASK (0x3f8ed7a6)
+
+/* AFE_CONN_24BIT (0x0AA4) */
+#define AFE_CONN_24BIT_O10 BIT(10)
+#define AFE_CONN_24BIT_O09 BIT(9)
+#define AFE_CONN_24BIT_O06 BIT(6)
+#define AFE_CONN_24BIT_O05 BIT(5)
+#define AFE_CONN_24BIT_O04 BIT(4)
+#define AFE_CONN_24BIT_O03 BIT(3)
+#define AFE_CONN_24BIT_O02 BIT(2)
+#define AFE_CONN_24BIT_O01 BIT(1)
+#define AFE_CONN_24BIT_O00 BIT(0)
+
+/* AFE_HD_ENGEN_ENABLE */
+#define AFE_22M_PLL_EN BIT(0)
+#define AFE_24M_PLL_EN BIT(1)
+
+/* AFE_GAIN1_CON0 (0x0410) */
+#define AFE_GAIN1_CON0_EN_MASK GENMASK(0, 0)
+#define AFE_GAIN1_CON0_MODE_MASK GENMASK(7, 4)
+#define AFE_GAIN1_CON0_SAMPLE_PER_STEP_MASK GENMASK(15, 8)
+
+/* AFE_GAIN1_CON1 (0x0414) */
+#define AFE_GAIN1_CON1_MASK GENMASK(19, 0)
+
+/* AFE_GAIN1_CUR (0x0B78) */
+#define AFE_GAIN1_CUR_MASK GENMASK(19, 0)
+
+/* AFE_CM1_CON0 (0x0e50) */
+/* AFE_CM2_CON0 (0x0e60) */
+#define CM_AFE_CM_CH_NUM_MASK GENMASK(3, 0)
+#define CM_AFE_CM_CH_NUM(x) FIELD_PREP(CM_AFE_CM_CH_NUM_MASK, ((x) - 1))
+#define CM_AFE_CM_ON BIT(4)
+#define CM_AFE_CM_START_DATA_MASK GENMASK(11, 8)
+
+#define CM_AFE_CM1_VUL_SEL BIT(12)
+#define CM_AFE_CM1_IN_MODE_MASK GENMASK(19, 16)
+#define CM_AFE_CM2_TDM_SEL BIT(12)
+#define CM_AFE_CM2_CLK_SEL BIT(13)
+#define CM_AFE_CM2_GASRC1_OUT_SEL BIT(17)
+#define CM_AFE_CM2_GASRC2_OUT_SEL BIT(16)
+
+/* AFE_CM2_CONN* */
+#define CM2_AFE_CM2_CONN_CFG1(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG1_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG1_MASK GENMASK(4, 0)
+#define CM2_AFE_CM2_CONN_CFG2(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG2_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG2_MASK GENMASK(9, 5)
+#define CM2_AFE_CM2_CONN_CFG3(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG3_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG3_MASK GENMASK(14, 10)
+#define CM2_AFE_CM2_CONN_CFG4(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG4_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG4_MASK GENMASK(19, 15)
+#define CM2_AFE_CM2_CONN_CFG5(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG5_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG5_MASK GENMASK(24, 20)
+#define CM2_AFE_CM2_CONN_CFG6(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG6_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG6_MASK GENMASK(29, 25)
+#define CM2_AFE_CM2_CONN_CFG7(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG7_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG7_MASK GENMASK(4, 0)
+#define CM2_AFE_CM2_CONN_CFG8(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG8_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG8_MASK GENMASK(9, 5)
+#define CM2_AFE_CM2_CONN_CFG9(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG9_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG9_MASK GENMASK(14, 10)
+#define CM2_AFE_CM2_CONN_CFG10(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG10_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG10_MASK GENMASK(19, 15)
+#define CM2_AFE_CM2_CONN_CFG11(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG11_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG11_MASK GENMASK(24, 20)
+#define CM2_AFE_CM2_CONN_CFG12(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG12_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG12_MASK GENMASK(29, 25)
+#define CM2_AFE_CM2_CONN_CFG13(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG13_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG13_MASK GENMASK(4, 0)
+#define CM2_AFE_CM2_CONN_CFG14(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG14_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG14_MASK GENMASK(9, 5)
+#define CM2_AFE_CM2_CONN_CFG15(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG15_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG15_MASK GENMASK(14, 10)
+#define CM2_AFE_CM2_CONN_CFG16(x) FIELD_PREP(CM2_AFE_CM2_CONN_CFG16_MASK, (x))
+#define CM2_AFE_CM2_CONN_CFG16_MASK GENMASK(19, 15)
+
+/* AFE_CM1_CON* */
+#define CM_AFE_CM_UPDATE_CNT1_MASK GENMASK(15, 0)
+#define CM_AFE_CM_UPDATE_CNT1(x) FIELD_PREP(CM_AFE_CM_UPDATE_CNT1_MASK, (x))
+#define CM_AFE_CM_UPDATE_CNT2_MASK GENMASK(31, 16)
+#define CM_AFE_CM_UPDATE_CNT2(x) FIELD_PREP(CM_AFE_CM_UPDATE_CNT2_MASK, (x))
+
+#endif
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 10/18] ASoC: mediatek: mt8365: Add PCM DAI support
From: Alexandre Mergnat @ 2024-04-09 13:42 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Lee Jones, Flora Fu, Jaroslav Kysela, Takashi Iwai, Sumit Semwal,
Christian König, Catalin Marinas, Will Deacon, Rob Herring
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Alexandre Mergnat
In-Reply-To: <20240226-audio-i350-v3-0-16bb2c974c55@baylibre.com>
Add Pulse Code Modulation Device Audio Interface support for MT8365 SoC.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
sound/soc/mediatek/mt8365/mt8365-dai-pcm.c | 293 +++++++++++++++++++++++++++++
1 file changed, 293 insertions(+)
diff --git a/sound/soc/mediatek/mt8365/mt8365-dai-pcm.c b/sound/soc/mediatek/mt8365/mt8365-dai-pcm.c
new file mode 100644
index 000000000000..a5de47c69620
--- /dev/null
+++ b/sound/soc/mediatek/mt8365/mt8365-dai-pcm.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek 8365 ALSA SoC Audio DAI PCM Control
+ *
+ * Copyright (c) 2024 MediaTek Inc.
+ * Authors: Jia Zeng <jia.zeng@mediatek.com>
+ * Alexandre Mergnat <amergnat@baylibre.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/regmap.h>
+#include <sound/pcm_params.h>
+#include "mt8365-afe-clk.h"
+#include "mt8365-afe-common.h"
+
+struct mt8365_pcm_intf_data {
+ bool slave_mode;
+ bool lrck_inv;
+ bool bck_inv;
+ unsigned int format;
+};
+
+/* DAI Drivers */
+
+static void mt8365_dai_enable_pcm1(struct mtk_base_afe *afe)
+{
+ regmap_update_bits(afe->regmap, PCM_INTF_CON1,
+ PCM_INTF_CON1_EN, PCM_INTF_CON1_EN);
+}
+
+static void mt8365_dai_disable_pcm1(struct mtk_base_afe *afe)
+{
+ regmap_update_bits(afe->regmap, PCM_INTF_CON1,
+ PCM_INTF_CON1_EN, 0x0);
+}
+
+static int mt8365_dai_configure_pcm1(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt8365_afe_private *afe_priv = afe->platform_priv;
+ struct mt8365_pcm_intf_data *pcm_priv = afe_priv->dai_priv[MT8365_AFE_IO_PCM1];
+ bool slave_mode = pcm_priv->slave_mode;
+ bool lrck_inv = pcm_priv->lrck_inv;
+ bool bck_inv = pcm_priv->bck_inv;
+ unsigned int fmt = pcm_priv->format;
+ unsigned int bit_width = dai->sample_bits;
+ unsigned int val = 0;
+
+ if (!slave_mode) {
+ val |= PCM_INTF_CON1_MASTER_MODE |
+ PCM_INTF_CON1_BYPASS_ASRC;
+
+ if (lrck_inv)
+ val |= PCM_INTF_CON1_SYNC_OUT_INV;
+ if (bck_inv)
+ val |= PCM_INTF_CON1_BCLK_OUT_INV;
+ } else {
+ val |= PCM_INTF_CON1_SLAVE_MODE;
+
+ if (lrck_inv)
+ val |= PCM_INTF_CON1_SYNC_IN_INV;
+ if (bck_inv)
+ val |= PCM_INTF_CON1_BCLK_IN_INV;
+
+ // TODO: add asrc setting
+ }
+
+ val |= FIELD_PREP(PCM_INTF_CON1_FORMAT_MASK, fmt);
+
+ if (fmt == MT8365_PCM_FORMAT_PCMA ||
+ fmt == MT8365_PCM_FORMAT_PCMB)
+ val |= PCM_INTF_CON1_SYNC_LEN(1);
+ else
+ val |= PCM_INTF_CON1_SYNC_LEN(bit_width);
+
+ switch (substream->runtime->rate) {
+ case 48000:
+ val |= PCM_INTF_CON1_FS_48K;
+ break;
+ case 32000:
+ val |= PCM_INTF_CON1_FS_32K;
+ break;
+ case 16000:
+ val |= PCM_INTF_CON1_FS_16K;
+ break;
+ case 8000:
+ val |= PCM_INTF_CON1_FS_8K;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (bit_width > 16)
+ val |= PCM_INTF_CON1_24BIT | PCM_INTF_CON1_64BCK;
+ else
+ val |= PCM_INTF_CON1_16BIT | PCM_INTF_CON1_32BCK;
+
+ val |= PCM_INTF_CON1_EXT_MODEM;
+
+ regmap_update_bits(afe->regmap, PCM_INTF_CON1,
+ PCM_INTF_CON1_CONFIG_MASK, val);
+
+ return 0;
+}
+
+static int mt8365_dai_pcm1_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+
+ if (snd_soc_dai_active(dai))
+ return 0;
+
+ mt8365_afe_enable_main_clk(afe);
+
+ return 0;
+}
+
+static void mt8365_dai_pcm1_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+
+ if (snd_soc_dai_active(dai))
+ return;
+
+ mt8365_dai_disable_pcm1(afe);
+ mt8365_afe_disable_main_clk(afe);
+}
+
+static int mt8365_dai_pcm1_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ int ret;
+
+ if ((snd_soc_dai_stream_active_playback(dai) +
+ snd_soc_dai_stream_active_capture(dai)) > 1) {
+ dev_info(afe->dev, "%s '%s' active(%u-%u) already\n",
+ __func__, snd_pcm_stream_str(substream),
+ snd_soc_dai_stream_active_playback(dai),
+ snd_soc_dai_stream_active_capture(dai));
+ return 0;
+ }
+
+ ret = mt8365_dai_configure_pcm1(substream, dai);
+ if (ret)
+ return ret;
+
+ mt8365_dai_enable_pcm1(afe);
+
+ return 0;
+}
+
+static int mt8365_dai_pcm1_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt8365_afe_private *afe_priv = afe->platform_priv;
+ struct mt8365_pcm_intf_data *pcm_priv = afe_priv->dai_priv[MT8365_AFE_IO_PCM1];
+
+ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S:
+ pcm_priv->format = MT8365_PCM_FORMAT_I2S;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ pcm_priv->bck_inv = false;
+ pcm_priv->lrck_inv = false;
+ break;
+ case SND_SOC_DAIFMT_NB_IF:
+ pcm_priv->bck_inv = false;
+ pcm_priv->lrck_inv = true;
+ break;
+ case SND_SOC_DAIFMT_IB_NF:
+ pcm_priv->bck_inv = true;
+ pcm_priv->lrck_inv = false;
+ break;
+ case SND_SOC_DAIFMT_IB_IF:
+ pcm_priv->bck_inv = true;
+ pcm_priv->lrck_inv = true;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFM:
+ pcm_priv->slave_mode = true;
+ break;
+ case SND_SOC_DAIFMT_CBS_CFS:
+ pcm_priv->slave_mode = false;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_dai_ops mt8365_dai_pcm1_ops = {
+ .startup = mt8365_dai_pcm1_startup,
+ .shutdown = mt8365_dai_pcm1_shutdown,
+ .prepare = mt8365_dai_pcm1_prepare,
+ .set_fmt = mt8365_dai_pcm1_set_fmt,
+};
+
+static struct snd_soc_dai_driver mtk_dai_pcm_driver[] = {
+ {
+ .name = "PCM1",
+ .id = MT8365_AFE_IO_PCM1,
+ .playback = {
+ .stream_name = "PCM1 Playback",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_16000 |
+ SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_48000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S32_LE,
+ },
+ .capture = {
+ .stream_name = "PCM1 Capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_16000 |
+ SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_48000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S32_LE,
+ },
+ .ops = &mt8365_dai_pcm1_ops,
+ .symmetric_rate = 1,
+ .symmetric_sample_bits = 1,
+ }
+};
+
+/* DAI widget */
+
+static const struct snd_soc_dapm_widget mtk_dai_pcm_widgets[] = {
+ SND_SOC_DAPM_OUTPUT("PCM1 Out"),
+ SND_SOC_DAPM_INPUT("PCM1 In"),
+};
+
+/* DAI route */
+
+static const struct snd_soc_dapm_route mtk_dai_pcm_routes[] = {
+ {"PCM1 Playback", NULL, "O07"},
+ {"PCM1 Playback", NULL, "O08"},
+ {"PCM1 Out", NULL, "PCM1 Playback"},
+
+ {"I09", NULL, "PCM1 Capture"},
+ {"I22", NULL, "PCM1 Capture"},
+ {"PCM1 Capture", NULL, "PCM1 In"},
+};
+
+static int init_pcmif_priv_data(struct mtk_base_afe *afe)
+{
+ struct mt8365_afe_private *afe_priv = afe->platform_priv;
+ struct mt8365_pcm_intf_data *pcmif_priv;
+
+ pcmif_priv = devm_kzalloc(afe->dev, sizeof(struct mt8365_pcm_intf_data),
+ GFP_KERNEL);
+ if (!pcmif_priv)
+ return -ENOMEM;
+
+ afe_priv->dai_priv[MT8365_AFE_IO_PCM1] = pcmif_priv;
+ return 0;
+}
+
+int mt8365_dai_pcm_register(struct mtk_base_afe *afe)
+{
+ struct mtk_base_afe_dai *dai;
+
+ dai = devm_kzalloc(afe->dev, sizeof(*dai), GFP_KERNEL);
+ if (!dai)
+ return -ENOMEM;
+
+ list_add(&dai->list, &afe->sub_dais);
+ dai->dai_drivers = mtk_dai_pcm_driver;
+ dai->num_dai_drivers = ARRAY_SIZE(mtk_dai_pcm_driver);
+ dai->dapm_widgets = mtk_dai_pcm_widgets;
+ dai->num_dapm_widgets = ARRAY_SIZE(mtk_dai_pcm_widgets);
+ dai->dapm_routes = mtk_dai_pcm_routes;
+ dai->num_dapm_routes = ARRAY_SIZE(mtk_dai_pcm_routes);
+ return init_pcmif_priv_data(afe);
+}
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 16/18] arm64: dts: mediatek: add mt6357 audio codec support
From: Alexandre Mergnat @ 2024-04-09 13:42 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Lee Jones, Flora Fu, Jaroslav Kysela, Takashi Iwai, Sumit Semwal,
Christian König, Catalin Marinas, Will Deacon, Rob Herring
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Alexandre Mergnat
In-Reply-To: <20240226-audio-i350-v3-0-16bb2c974c55@baylibre.com>
Add audio codec support of MT6357 PMIC.
Update the file header.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
arch/arm64/boot/dts/mediatek/mt6357.dtsi | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt6357.dtsi b/arch/arm64/boot/dts/mediatek/mt6357.dtsi
index 3330a03c2f74..ade410851524 100644
--- a/arch/arm64/boot/dts/mediatek/mt6357.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6357.dtsi
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
* Copyright (c) 2020 MediaTek Inc.
- * Copyright (c) 2023 BayLibre Inc.
+ * Copyright (c) 2024 BayLibre Inc.
*/
#include <dt-bindings/input/input.h>
@@ -10,6 +10,9 @@ &pwrap {
mt6357_pmic: pmic {
compatible = "mediatek,mt6357";
+ mt6357_codec: codec {
+ };
+
regulators {
mt6357_vproc_reg: buck-vproc {
regulator-name = "vproc";
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 00/18] Add audio support for the MediaTek Genio 350-evk board
From: Alexandre Mergnat @ 2024-04-09 13:41 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Lee Jones, Flora Fu, Jaroslav Kysela, Takashi Iwai, Sumit Semwal,
Christian König, Catalin Marinas, Will Deacon, Rob Herring
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Alexandre Mergnat, Nicolas Belin
This serie aim to add the following audio support for the Genio 350-evk:
- Playback
- 2ch Headset Jack (Earphone)
- 1ch Line-out Jack (Speaker)
- 8ch HDMI Tx
- Capture
- 1ch DMIC (On-board Digital Microphone)
- 1ch AMIC (On-board Analogic Microphone)
- 1ch Headset Jack (External Analogic Microphone)
Of course, HDMI playback need the MT8365 display patches [1] and a DTS
change documented in "mediatek,mt8365-mt6357.yaml".
Rebase on top of sound/for-next branch and the
Angelo's serie "SoC: Cleanup MediaTek soundcard machine drivers" [2]
Work branch with all patches [5]
Applied patch:
- mfd: mt6397-core: register mt6357 sound codec
Test passed:
- mixer-test log: [3]
- pcm-test log: [4]
[1]: https://lore.kernel.org/all/20231023-display-support-v1-0-5c860ed5c33b@baylibre.com/
[2]: https://lore.kernel.org/all/20240313110147.1267793-1-angelogioacchino.delregno@collabora.com/
[3]: https://pastebin.com/pc43AVrT
[4]: https://pastebin.com/cCtGhDpg
[5]: https://gitlab.baylibre.com/baylibre/mediatek/bsp/linux/-/commits/sound/for-next/add-i350-audio-support
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
Changes in v3:
- Re-order documentation commit to fix dt_binding_check error.
- Remove $ref and add "mediatek," prefix to vaud28-supply property.
- Link to v2: https://lore.kernel.org/r/20240226-audio-i350-v2-0-3043d483de0d@baylibre.com
Changes in v2:
- Documentation fixed:
- Remove spurious description.
- Change property order to fit with dts coding style rules.
- micbias property: use microvolt value instead of index.
- mediatek,i2s-shared-clock property removed.
- mediatek,dmic-iir-on property removed.
- mediatek,dmic-irr-mode property removed.
- Change dmic-two-wire-mode => dmic-mode to be aligned with another SoC
- Remove the spurious 2nd reg of the afe.
- Manage IIR filter feature using audio controls.
- Fix audio controls to pass mixer-test and pcm-test.
- Refactor some const name according to feedbacks.
- Rework the codec to remove spurious driver data.
- Use the new common MTK probe functions for AFE PCM and sound card.
- Rework pinctrl probe in the soundcard driver.
- Remove spurious "const" variables in all files.
- Link to v1: https://lore.kernel.org/r/20240226-audio-i350-v1-0-4fa1cea1667f@baylibre.com
---
Alexandre Mergnat (16):
ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document
ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document
ASoC: dt-bindings: mt6357: Add audio codec document
dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
ASoC: mediatek: mt8365: Add common header
SoC: mediatek: mt8365: support audio clock control
ASoC: mediatek: mt8365: Add I2S DAI support
ASoC: mediatek: mt8365: Add ADDA DAI support
ASoC: mediatek: mt8365: Add DMIC DAI support
ASoC: mediatek: mt8365: Add PCM DAI support
ASoC: mediatek: mt8365: Add platform driver
ASoC: mediatek: Add MT8365 support
arm64: defconfig: enable mt8365 sound
arm64: dts: mediatek: add mt6357 audio codec support
arm64: dts: mediatek: add afe support for mt8365 SoC
arm64: dts: mediatek: add audio support for mt8365-evk
Nicolas Belin (2):
ASoc: mediatek: mt8365: Add a specific soundcard for EVK
ASoC: codecs: add MT6357 support
.../devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 +
.../bindings/sound/mediatek,mt8365-afe.yaml | 136 ++
.../bindings/sound/mediatek,mt8365-mt6357.yaml | 99 +
.../devicetree/bindings/sound/mt6357.yaml | 54 +
arch/arm64/boot/dts/mediatek/mt6357.dtsi | 5 +-
arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 98 +-
arch/arm64/boot/dts/mediatek/mt8365.dtsi | 46 +-
arch/arm64/configs/defconfig | 2 +
sound/soc/codecs/Kconfig | 7 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/mt6357.c | 1898 ++++++++++++++++
sound/soc/codecs/mt6357.h | 662 ++++++
sound/soc/mediatek/Kconfig | 20 +
sound/soc/mediatek/Makefile | 1 +
sound/soc/mediatek/mt8365/Makefile | 15 +
sound/soc/mediatek/mt8365/mt8365-afe-clk.c | 451 ++++
sound/soc/mediatek/mt8365/mt8365-afe-clk.h | 49 +
sound/soc/mediatek/mt8365/mt8365-afe-common.h | 491 +++++
sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 2275 ++++++++++++++++++++
sound/soc/mediatek/mt8365/mt8365-dai-adda.c | 315 +++
sound/soc/mediatek/mt8365/mt8365-dai-dmic.c | 347 +++
sound/soc/mediatek/mt8365/mt8365-dai-i2s.c | 854 ++++++++
sound/soc/mediatek/mt8365/mt8365-dai-pcm.c | 293 +++
sound/soc/mediatek/mt8365/mt8365-mt6357.c | 348 +++
sound/soc/mediatek/mt8365/mt8365-reg.h | 991 +++++++++
25 files changed, 9456 insertions(+), 8 deletions(-)
---
base-commit: 6a3d4a830e4e9de8e8aefc233d790bef4a5c0037
change-id: 20240226-audio-i350-4e11da088e55
Best regards,
--
Alexandre Mergnat <amergnat@baylibre.com>
_______________________________________________
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 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document
From: Alexandre Mergnat @ 2024-04-09 13:41 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Lee Jones, Flora Fu, Jaroslav Kysela, Takashi Iwai, Sumit Semwal,
Christian König, Catalin Marinas, Will Deacon, Rob Herring
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Alexandre Mergnat
In-Reply-To: <20240226-audio-i350-v3-0-16bb2c974c55@baylibre.com>
Add MT8365 audio front-end bindings
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
.../bindings/sound/mediatek,mt8365-afe.yaml | 136 +++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml
new file mode 100644
index 000000000000..d0759898b9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8365-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AFE PCM controller for MT8365
+
+maintainers:
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8365-afe-pcm
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: 26M clock
+ - description: mux for audio clock
+ - description: audio i2s0 mck
+ - description: audio i2s1 mck
+ - description: audio i2s2 mck
+ - description: audio i2s3 mck
+ - description: engen 1 clock
+ - description: engen 2 clock
+ - description: audio 1 clock
+ - description: audio 2 clock
+ - description: mux for i2s0
+ - description: mux for i2s1
+ - description: mux for i2s2
+ - description: mux for i2s3
+
+ clock-names:
+ items:
+ - const: top_clk26m_clk
+ - const: top_audio_sel
+ - const: audio_i2s0_m
+ - const: audio_i2s1_m
+ - const: audio_i2s2_m
+ - const: audio_i2s3_m
+ - const: engen1
+ - const: engen2
+ - const: aud1
+ - const: aud2
+ - const: i2s0_m_sel
+ - const: i2s1_m_sel
+ - const: i2s2_m_sel
+ - const: i2s3_m_sel
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ mediatek,dmic-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Indicates how many data pins are used to transmit two channels of PDM
+ signal. 1 means two wires, 0 means one wire. Default value is 0.
+ enum:
+ - 0 # one wire
+ - 1 # two wires
+
+ mediatek,topckgen:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek topckgen controller
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - mediatek,topckgen
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mt8365-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mediatek,mt8365-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ afe@11220000 {
+ compatible = "mediatek,mt8365-afe-pcm";
+ reg = <0 0x11220000 0 0x1000>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk26m>,
+ <&topckgen CLK_TOP_AUDIO_SEL>,
+ <&topckgen CLK_TOP_AUD_I2S0_M>,
+ <&topckgen CLK_TOP_AUD_I2S1_M>,
+ <&topckgen CLK_TOP_AUD_I2S2_M>,
+ <&topckgen CLK_TOP_AUD_I2S3_M>,
+ <&topckgen CLK_TOP_AUD_ENGEN1_SEL>,
+ <&topckgen CLK_TOP_AUD_ENGEN2_SEL>,
+ <&topckgen CLK_TOP_AUD_1_SEL>,
+ <&topckgen CLK_TOP_AUD_2_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S0_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S1_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S2_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S3_SEL>;
+ clock-names = "top_clk26m_clk",
+ "top_audio_sel",
+ "audio_i2s0_m",
+ "audio_i2s1_m",
+ "audio_i2s2_m",
+ "audio_i2s3_m",
+ "engen1",
+ "engen2",
+ "aud1",
+ "aud2",
+ "i2s0_m_sel",
+ "i2s1_m_sel",
+ "i2s2_m_sel",
+ "i2s3_m_sel";
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8365_POWER_DOMAIN_AUDIO>;
+ mediatek,dmic-mode = <1>;
+ mediatek,topckgen = <&topckgen>;
+ };
+ };
+
+...
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/4] Speed up boot with faster linear map creation
From: David Hildenbrand @ 2024-04-09 14:45 UTC (permalink / raw)
To: Ryan Roberts, Itaru Kitayama
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Donald Dutile, Eric Chanudet, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <e7af023f-39cd-4aa4-aa13-dd6aabea4cdf@arm.com>
On 09.04.24 16:39, Ryan Roberts wrote:
> On 09/04/2024 15:29, David Hildenbrand wrote:
>> On 09.04.24 16:13, Ryan Roberts wrote:
>>> On 09/04/2024 12:51, David Hildenbrand wrote:
>>>> On 09.04.24 13:29, David Hildenbrand wrote:
>>>>> On 09.04.24 13:22, David Hildenbrand wrote:
>>>>>> On 09.04.24 12:13, Itaru Kitayama wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 9, 2024, at 19:04, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>>>
>>>>>>>> On 09/04/2024 01:10, Itaru Kitayama wrote:
>>>>>>>>> Hi Ryan,
>>>>>>>>>
>>>>>>>>>> On Apr 8, 2024, at 16:30, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 06/04/2024 11:31, Itaru Kitayama wrote:
>>>>>>>>>>> Hi Ryan,
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote:
>>>>>>>>>>>> Hi Itaru,
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/04/2024 08:39, Itaru Kitayama wrote:
>>>>>>>>>>>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It turns out that creating the linear map can take a significant
>>>>>>>>>>>>>> proportion of
>>>>>>>>>>>>>> the total boot time, especially when rodata=full. And most of the
>>>>>>>>>>>>>> time is spent
>>>>>>>>>>>>>> waiting on superfluous tlb invalidation and memory barriers. This
>>>>>>>>>>>>>> series reworks
>>>>>>>>>>>>>> the kernel pgtable generation code to significantly reduce the number
>>>>>>>>>>>>>> of those
>>>>>>>>>>>>>> TLBIs, ISBs and DSBs. See each patch for details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The below shows the execution time of map_mem() across a couple of
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> systems with different RAM configurations. We measure after applying
>>>>>>>>>>>>>> each patch
>>>>>>>>>>>>>> and show the improvement relative to base (v6.9-rc2):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere
>>>>>>>>>>>>>> Altra
>>>>>>>>>>>>>> | VM, 16G | VM, 64G | VM, 256G | Metal,
>>>>>>>>>>>>>> 512G
>>>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>>>> | ms (%) | ms (%) | ms (%) |
>>>>>>>>>>>>>> ms (%)
>>>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442
>>>>>>>>>>>>>> (0%)
>>>>>>>>>>>>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796
>>>>>>>>>>>>>> (-78%)
>>>>>>>>>>>>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656
>>>>>>>>>>>>>> (-91%)
>>>>>>>>>>>>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257
>>>>>>>>>>>>>> (-93%)
>>>>>>>>>>>>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838
>>>>>>>>>>>>>> (-95%)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've
>>>>>>>>>>>>>> compile and
>>>>>>>>>>>>>> boot tested various PAGE_SIZE and VA size configs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Changes since v1 [1]
>>>>>>>>>>>>>> ====================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Added Tested-by tags (thanks to Eric and Itaru)
>>>>>>>>>>>>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
>>>>>>>>>>>>>> - Reordered patches (biggest impact & least controversial first)
>>>>>>>>>>>>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader
>>>>>>>>>>>>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync()
>>>>>>>>>>>>>> - Reverted generic p4d_index() which caused x86 build error.
>>>>>>>>>>>>>> Replaced with
>>>>>>>>>>>>>> unconditional p4d_index() define under arm64.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>> https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/<https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ryan Roberts (4):
>>>>>>>>>>>>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
>>>>>>>>>>>>>> arm64: mm: Batch dsb and isb when populating pgtables
>>>>>>>>>>>>>> arm64: mm: Don't remap pgtables for allocate vs populate
>>>>>>>>>>>>>> arm64: mm: Lazily clear pte table mappings from fixmap
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> arch/arm64/include/asm/fixmap.h | 5 +-
>>>>>>>>>>>>>> arch/arm64/include/asm/mmu.h | 8 +
>>>>>>>>>>>>>> arch/arm64/include/asm/pgtable.h | 13 +-
>>>>>>>>>>>>>> arch/arm64/kernel/cpufeature.c | 10 +-
>>>>>>>>>>>>>> arch/arm64/mm/fixmap.c | 11 +
>>>>>>>>>>>>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
>>>>>>>>>>>>>> 6 files changed, 319 insertions(+), 105 deletions(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 2.25.1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've build and boot tested the v2 on FVP, base is taken from your
>>>>>>>>>>>>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not
>>>>>>>>>>>>> oks, would you take a look at it? The mm ksefltests used is from your
>>>>>>>>>>>>> linux-rr repo too.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for taking a look at this.
>>>>>>>>>>>>
>>>>>>>>>>>> I can't reproduce your issue unfortunately; steps as follows on Apple
>>>>>>>>>>>> M2 VM:
>>>>>>>>>>>>
>>>>>>>>>>>> Config: arm64 defconfig + the following:
>>>>>>>>>>>>
>>>>>>>>>>>> # Squashfs for snaps, xfs for large file folios.
>>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZ4
>>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZO
>>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_XZ
>>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD
>>>>>>>>>>>> ./scripts/config --enable CONFIG_XFS_FS
>>>>>>>>>>>>
>>>>>>>>>>>> # For general mm debug.
>>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM
>>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE
>>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_RB
>>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS
>>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE
>>>>>>>>>>>> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK
>>>>>>>>>>>>
>>>>>>>>>>>> # For mm selftests.
>>>>>>>>>>>> ./scripts/config --enable CONFIG_USERFAULTFD
>>>>>>>>>>>> ./scripts/config --enable CONFIG_TEST_VMALLOC
>>>>>>>>>>>> ./scripts/config --enable CONFIG_GUP_TEST
>>>>>>>>>>>>
>>>>>>>>>>>> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes
>>>>>>>>>>>> (needed by
>>>>>>>>>>>> some mm selftests), with kernel command line to reserve hugetlbs and
>>>>>>>>>>>> other
>>>>>>>>>>>> features required by some mm selftests:
>>>>>>>>>>>>
>>>>>>>>>>>> "
>>>>>>>>>>>> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
>>>>>>>>>>>> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
>>>>>>>>>>>> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K
>>>>>>>>>>>> hugepages=0:2,1:2
>>>>>>>>>>>> "
>>>>>>>>>>>>
>>>>>>>>>>>> Ubuntu userspace running off XFS rootfs. Build and run mm selftests
>>>>>>>>>>>> from same
>>>>>>>>>>>> git tree.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Although I don't think any of this config should make a difference to
>>>>>>>>>>>> gup_longterm.
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like your errors are all "ftruncate() failed". I've seen this
>>>>>>>>>>>> problem on
>>>>>>>>>>>> our CI system. There it is due to running the tests from NFS file
>>>>>>>>>>>> system. What
>>>>>>>>>>>> filesystem are you using? Perhaps you are sharing into the FVP using
>>>>>>>>>>>> 9p? That
>>>>>>>>>>>> might also be problematic.
>>>>>>>>>>>
>>>>>>>>>>> That was it. This time I booted up the kernel including your series on
>>>>>>>>>>> QEMU on my M1 and executed the gup_longterm program without the ftruncate
>>>>>>>>>>> failures. When testing your kernel on FVP, I was executing the script
>>>>>>>>>>> from the FVP's host filesystem using 9p.
>>>>>>>>>>
>>>>>>>>>> I'm not sure exactly what the root cause is. Perhaps there isn't enough
>>>>>>>>>> space on
>>>>>>>>>> the disk? It might be worth enhancing the error log to provide the
>>>>>>>>>> errno in
>>>>>>>>>> tools/testing/selftests/mm/gup_longterm.c.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Attached is the strace’d gup_longterm executiong log on your
>>>>>>>>> pgtable-boot-speedup-v2 kernel.
>>>>>>>>
>>>>>>>> Sorry are you saying that it only fails with the pgtable-boot-speedup-v2
>>>>>>>> patch
>>>>>>>> set applied? I thought we previously concluded that it was independent of
>>>>>>>> that?
>>>>>>>> I was under the impression that it was filesystem related and not something
>>>>>>>> that
>>>>>>>> I was planning to investigate.
>>>>>>>
>>>>>>> No, irrespective of the kernel, if using 9p on FVP the test program fails.
>>>>>>> It is indeed 9p filesystem related, as I switched to using NFS all the
>>>>>>> issues are gone.
>>>>>>
>>>>>> Did it never work on 9p? If so, we might have to SKIP that test.
>>>>>>
>>>>>> openat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", O_RDWR|O_CREAT|O_EXCL,
>>>>>> 0600) = 3
>>>>>> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", 0) = 0
>>>>>> fstatfs(3, 0xffffe505a840) = -1 EOPNOTSUPP (Operation not
>>>>>> supported)
>>>>>> ftruncate(3, 4096) = -1 ENOENT (No such file or
>>>>>> directory)
>>>>>
>>>>> Note: I'm wondering if the unlinkat here is the problem that makes
>>>>> ftruncate() with 9p result in weird errors (e.g., the hypervisor
>>>>> unlinked the file and cannot reopen it for the fstatfs/ftruncate. ...
>>>>> which gives us weird errors here).
>>>>>
>>>>> Then, we should lookup the fs type in run_with_local_tmpfile() before
>>>>> the unlink() and simply skip the test if it is 9p.
>>>>
>>>> The unlink with 9p most certainly was a known issue in the past:
>>>>
>>>> https://gitlab.com/qemu-project/qemu/-/issues/103
>>>>
>>>> Maybe it's still an issue with older hypervisors (QEMU?)? Or it was never
>>>> completely resolved?
>>>
>>> I believe Itaru is running on FVP (Fixed Virtual Platform - "fast model" -
>>> Arm's architecture emulator). So QEMU won't be involved here. The FVP emulates
>>> a 9p device, so perhaps the bug is in there.
>>
>> Very likely.
>>
>>>
>>> Note that I see lots of "fallocate() failed" failures in gup_longterm when
>>> running on our CI system. This is a completely different setup; Real HW with
>>> Linux running bare metal using an NFS rootfs. I'm not sure if this is related.
>>> Logs show it failing consistently for the "tmpfile" and "local tmpfile" test
>>> configs. I also see a couple of these fails in the cow tests.
>>
>> What is the fallocate() errno you are getting? strace log would help (to see if
>> statfs also fails already)! Likely a similar NFS issue.
>
> Unfortunately this is a system I don't have access to. I've requested some of
> this triage to be done, but its fairly low priority unfortunately.
To work around these BUGs (?) elsewhere, we could simply skip the test
if get_fs_type() is not able to detect the FS type. Likely that's an
early indicator that the unlink() messed something up.
... doesn't feel right, though.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] regulator: mt6360: De-capitalize devicetree regulator subnodes
From: AngeloGioacchino Del Regno @ 2024-04-09 14:44 UTC (permalink / raw)
To: lgirdwood
Cc: broonie, matthias.bgg, angelogioacchino.delregno, gene_chen,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
The MT6360 regulator binding, the example in the MT6360 mfd binding, and
the devicetree users of those bindings are rightfully declaring MT6360
regulator subnodes with non-capital names, and luckily without using the
deprecated regulator-compatible property.
With this driver declaring capitalized BUCKx/LDOx as of_match string for
the node names, obviously no regulator gets probed: fix that by changing
the MT6360_REGULATOR_DESC macro to add a "match" parameter which gets
assigned to the of_match.
Fixes: d321571d5e4c ("regulator: mt6360: Add support for MT6360 regulator")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/regulator/mt6360-regulator.c | 32 +++++++++++++++++-----------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/mt6360-regulator.c b/drivers/regulator/mt6360-regulator.c
index ad6587a378d0..24cc9fc94e90 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -319,15 +319,15 @@ static unsigned int mt6360_regulator_of_map_mode(unsigned int hw_mode)
}
}
-#define MT6360_REGULATOR_DESC(_name, _sname, ereg, emask, vreg, vmask, \
- mreg, mmask, streg, stmask, vranges, \
- vcnts, offon_delay, irq_tbls) \
+#define MT6360_REGULATOR_DESC(match, _name, _sname, ereg, emask, vreg, \
+ vmask, mreg, mmask, streg, stmask, \
+ vranges, vcnts, offon_delay, irq_tbls) \
{ \
.desc = { \
.name = #_name, \
.supply_name = #_sname, \
.id = MT6360_REGULATOR_##_name, \
- .of_match = of_match_ptr(#_name), \
+ .of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulator"), \
.of_map_mode = mt6360_regulator_of_map_mode, \
.owner = THIS_MODULE, \
@@ -351,21 +351,29 @@ static unsigned int mt6360_regulator_of_map_mode(unsigned int hw_mode)
}
static const struct mt6360_regulator_desc mt6360_regulator_descs[] = {
- MT6360_REGULATOR_DESC(BUCK1, BUCK1_VIN, 0x117, 0x40, 0x110, 0xff, 0x117, 0x30, 0x117, 0x04,
+ MT6360_REGULATOR_DESC("buck1", BUCK1, BUCK1_VIN,
+ 0x117, 0x40, 0x110, 0xff, 0x117, 0x30, 0x117, 0x04,
buck_vout_ranges, 256, 0, buck1_irq_tbls),
- MT6360_REGULATOR_DESC(BUCK2, BUCK2_VIN, 0x127, 0x40, 0x120, 0xff, 0x127, 0x30, 0x127, 0x04,
+ MT6360_REGULATOR_DESC("buck2", BUCK2, BUCK2_VIN,
+ 0x127, 0x40, 0x120, 0xff, 0x127, 0x30, 0x127, 0x04,
buck_vout_ranges, 256, 0, buck2_irq_tbls),
- MT6360_REGULATOR_DESC(LDO6, LDO_VIN3, 0x137, 0x40, 0x13B, 0xff, 0x137, 0x30, 0x137, 0x04,
+ MT6360_REGULATOR_DESC("ldo6", LDO6, LDO_VIN3,
+ 0x137, 0x40, 0x13B, 0xff, 0x137, 0x30, 0x137, 0x04,
ldo_vout_ranges1, 256, 0, ldo6_irq_tbls),
- MT6360_REGULATOR_DESC(LDO7, LDO_VIN3, 0x131, 0x40, 0x135, 0xff, 0x131, 0x30, 0x131, 0x04,
+ MT6360_REGULATOR_DESC("ldo7", LDO7, LDO_VIN3,
+ 0x131, 0x40, 0x135, 0xff, 0x131, 0x30, 0x131, 0x04,
ldo_vout_ranges1, 256, 0, ldo7_irq_tbls),
- MT6360_REGULATOR_DESC(LDO1, LDO_VIN1, 0x217, 0x40, 0x21B, 0xff, 0x217, 0x30, 0x217, 0x04,
+ MT6360_REGULATOR_DESC("ldo1", LDO1, LDO_VIN1,
+ 0x217, 0x40, 0x21B, 0xff, 0x217, 0x30, 0x217, 0x04,
ldo_vout_ranges2, 256, 0, ldo1_irq_tbls),
- MT6360_REGULATOR_DESC(LDO2, LDO_VIN1, 0x211, 0x40, 0x215, 0xff, 0x211, 0x30, 0x211, 0x04,
+ MT6360_REGULATOR_DESC("ldo2", LDO2, LDO_VIN1,
+ 0x211, 0x40, 0x215, 0xff, 0x211, 0x30, 0x211, 0x04,
ldo_vout_ranges2, 256, 0, ldo2_irq_tbls),
- MT6360_REGULATOR_DESC(LDO3, LDO_VIN1, 0x205, 0x40, 0x209, 0xff, 0x205, 0x30, 0x205, 0x04,
+ MT6360_REGULATOR_DESC("ldo3", LDO3, LDO_VIN1,
+ 0x205, 0x40, 0x209, 0xff, 0x205, 0x30, 0x205, 0x04,
ldo_vout_ranges2, 256, 100, ldo3_irq_tbls),
- MT6360_REGULATOR_DESC(LDO5, LDO_VIN2, 0x20B, 0x40, 0x20F, 0x7f, 0x20B, 0x30, 0x20B, 0x04,
+ MT6360_REGULATOR_DESC("ldo5", LDO5, LDO_VIN2,
+ 0x20B, 0x40, 0x20F, 0x7f, 0x20B, 0x30, 0x20B, 0x04,
ldo_vout_ranges3, 128, 100, ldo5_irq_tbls),
};
--
2.44.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 0/4] Speed up boot with faster linear map creation
From: Ryan Roberts @ 2024-04-09 14:39 UTC (permalink / raw)
To: David Hildenbrand, Itaru Kitayama
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Donald Dutile, Eric Chanudet, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <d1aca51c-2433-4e06-a3ef-842e27371db6@redhat.com>
On 09/04/2024 15:29, David Hildenbrand wrote:
> On 09.04.24 16:13, Ryan Roberts wrote:
>> On 09/04/2024 12:51, David Hildenbrand wrote:
>>> On 09.04.24 13:29, David Hildenbrand wrote:
>>>> On 09.04.24 13:22, David Hildenbrand wrote:
>>>>> On 09.04.24 12:13, Itaru Kitayama wrote:
>>>>>>
>>>>>>
>>>>>>> On Apr 9, 2024, at 19:04, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>>
>>>>>>> On 09/04/2024 01:10, Itaru Kitayama wrote:
>>>>>>>> Hi Ryan,
>>>>>>>>
>>>>>>>>> On Apr 8, 2024, at 16:30, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>>>>
>>>>>>>>> On 06/04/2024 11:31, Itaru Kitayama wrote:
>>>>>>>>>> Hi Ryan,
>>>>>>>>>>
>>>>>>>>>> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote:
>>>>>>>>>>> Hi Itaru,
>>>>>>>>>>>
>>>>>>>>>>> On 05/04/2024 08:39, Itaru Kitayama wrote:
>>>>>>>>>>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that creating the linear map can take a significant
>>>>>>>>>>>>> proportion of
>>>>>>>>>>>>> the total boot time, especially when rodata=full. And most of the
>>>>>>>>>>>>> time is spent
>>>>>>>>>>>>> waiting on superfluous tlb invalidation and memory barriers. This
>>>>>>>>>>>>> series reworks
>>>>>>>>>>>>> the kernel pgtable generation code to significantly reduce the number
>>>>>>>>>>>>> of those
>>>>>>>>>>>>> TLBIs, ISBs and DSBs. See each patch for details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The below shows the execution time of map_mem() across a couple of
>>>>>>>>>>>>> different
>>>>>>>>>>>>> systems with different RAM configurations. We measure after applying
>>>>>>>>>>>>> each patch
>>>>>>>>>>>>> and show the improvement relative to base (v6.9-rc2):
>>>>>>>>>>>>>
>>>>>>>>>>>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere
>>>>>>>>>>>>> Altra
>>>>>>>>>>>>> | VM, 16G | VM, 64G | VM, 256G | Metal,
>>>>>>>>>>>>> 512G
>>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>>> | ms (%) | ms (%) | ms (%) |
>>>>>>>>>>>>> ms (%)
>>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442
>>>>>>>>>>>>> (0%)
>>>>>>>>>>>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796
>>>>>>>>>>>>> (-78%)
>>>>>>>>>>>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656
>>>>>>>>>>>>> (-91%)
>>>>>>>>>>>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257
>>>>>>>>>>>>> (-93%)
>>>>>>>>>>>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838
>>>>>>>>>>>>> (-95%)
>>>>>>>>>>>>>
>>>>>>>>>>>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've
>>>>>>>>>>>>> compile and
>>>>>>>>>>>>> boot tested various PAGE_SIZE and VA size configs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> Changes since v1 [1]
>>>>>>>>>>>>> ====================
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Added Tested-by tags (thanks to Eric and Itaru)
>>>>>>>>>>>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
>>>>>>>>>>>>> - Reordered patches (biggest impact & least controversial first)
>>>>>>>>>>>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader
>>>>>>>>>>>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync()
>>>>>>>>>>>>> - Reverted generic p4d_index() which caused x86 build error.
>>>>>>>>>>>>> Replaced with
>>>>>>>>>>>>> unconditional p4d_index() define under arm64.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/<https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ryan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ryan Roberts (4):
>>>>>>>>>>>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
>>>>>>>>>>>>> arm64: mm: Batch dsb and isb when populating pgtables
>>>>>>>>>>>>> arm64: mm: Don't remap pgtables for allocate vs populate
>>>>>>>>>>>>> arm64: mm: Lazily clear pte table mappings from fixmap
>>>>>>>>>>>>>
>>>>>>>>>>>>> arch/arm64/include/asm/fixmap.h | 5 +-
>>>>>>>>>>>>> arch/arm64/include/asm/mmu.h | 8 +
>>>>>>>>>>>>> arch/arm64/include/asm/pgtable.h | 13 +-
>>>>>>>>>>>>> arch/arm64/kernel/cpufeature.c | 10 +-
>>>>>>>>>>>>> arch/arm64/mm/fixmap.c | 11 +
>>>>>>>>>>>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
>>>>>>>>>>>>> 6 files changed, 319 insertions(+), 105 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 2.25.1
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've build and boot tested the v2 on FVP, base is taken from your
>>>>>>>>>>>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not
>>>>>>>>>>>> oks, would you take a look at it? The mm ksefltests used is from your
>>>>>>>>>>>> linux-rr repo too.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for taking a look at this.
>>>>>>>>>>>
>>>>>>>>>>> I can't reproduce your issue unfortunately; steps as follows on Apple
>>>>>>>>>>> M2 VM:
>>>>>>>>>>>
>>>>>>>>>>> Config: arm64 defconfig + the following:
>>>>>>>>>>>
>>>>>>>>>>> # Squashfs for snaps, xfs for large file folios.
>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZ4
>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZO
>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_XZ
>>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD
>>>>>>>>>>> ./scripts/config --enable CONFIG_XFS_FS
>>>>>>>>>>>
>>>>>>>>>>> # For general mm debug.
>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM
>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE
>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_RB
>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS
>>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE
>>>>>>>>>>> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK
>>>>>>>>>>>
>>>>>>>>>>> # For mm selftests.
>>>>>>>>>>> ./scripts/config --enable CONFIG_USERFAULTFD
>>>>>>>>>>> ./scripts/config --enable CONFIG_TEST_VMALLOC
>>>>>>>>>>> ./scripts/config --enable CONFIG_GUP_TEST
>>>>>>>>>>>
>>>>>>>>>>> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes
>>>>>>>>>>> (needed by
>>>>>>>>>>> some mm selftests), with kernel command line to reserve hugetlbs and
>>>>>>>>>>> other
>>>>>>>>>>> features required by some mm selftests:
>>>>>>>>>>>
>>>>>>>>>>> "
>>>>>>>>>>> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
>>>>>>>>>>> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
>>>>>>>>>>> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K
>>>>>>>>>>> hugepages=0:2,1:2
>>>>>>>>>>> "
>>>>>>>>>>>
>>>>>>>>>>> Ubuntu userspace running off XFS rootfs. Build and run mm selftests
>>>>>>>>>>> from same
>>>>>>>>>>> git tree.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Although I don't think any of this config should make a difference to
>>>>>>>>>>> gup_longterm.
>>>>>>>>>>>
>>>>>>>>>>> Looks like your errors are all "ftruncate() failed". I've seen this
>>>>>>>>>>> problem on
>>>>>>>>>>> our CI system. There it is due to running the tests from NFS file
>>>>>>>>>>> system. What
>>>>>>>>>>> filesystem are you using? Perhaps you are sharing into the FVP using
>>>>>>>>>>> 9p? That
>>>>>>>>>>> might also be problematic.
>>>>>>>>>>
>>>>>>>>>> That was it. This time I booted up the kernel including your series on
>>>>>>>>>> QEMU on my M1 and executed the gup_longterm program without the ftruncate
>>>>>>>>>> failures. When testing your kernel on FVP, I was executing the script
>>>>>>>>>> from the FVP's host filesystem using 9p.
>>>>>>>>>
>>>>>>>>> I'm not sure exactly what the root cause is. Perhaps there isn't enough
>>>>>>>>> space on
>>>>>>>>> the disk? It might be worth enhancing the error log to provide the
>>>>>>>>> errno in
>>>>>>>>> tools/testing/selftests/mm/gup_longterm.c.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Attached is the strace’d gup_longterm executiong log on your
>>>>>>>> pgtable-boot-speedup-v2 kernel.
>>>>>>>
>>>>>>> Sorry are you saying that it only fails with the pgtable-boot-speedup-v2
>>>>>>> patch
>>>>>>> set applied? I thought we previously concluded that it was independent of
>>>>>>> that?
>>>>>>> I was under the impression that it was filesystem related and not something
>>>>>>> that
>>>>>>> I was planning to investigate.
>>>>>>
>>>>>> No, irrespective of the kernel, if using 9p on FVP the test program fails.
>>>>>> It is indeed 9p filesystem related, as I switched to using NFS all the
>>>>>> issues are gone.
>>>>>
>>>>> Did it never work on 9p? If so, we might have to SKIP that test.
>>>>>
>>>>> openat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", O_RDWR|O_CREAT|O_EXCL,
>>>>> 0600) = 3
>>>>> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", 0) = 0
>>>>> fstatfs(3, 0xffffe505a840) = -1 EOPNOTSUPP (Operation not
>>>>> supported)
>>>>> ftruncate(3, 4096) = -1 ENOENT (No such file or
>>>>> directory)
>>>>
>>>> Note: I'm wondering if the unlinkat here is the problem that makes
>>>> ftruncate() with 9p result in weird errors (e.g., the hypervisor
>>>> unlinked the file and cannot reopen it for the fstatfs/ftruncate. ...
>>>> which gives us weird errors here).
>>>>
>>>> Then, we should lookup the fs type in run_with_local_tmpfile() before
>>>> the unlink() and simply skip the test if it is 9p.
>>>
>>> The unlink with 9p most certainly was a known issue in the past:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/issues/103
>>>
>>> Maybe it's still an issue with older hypervisors (QEMU?)? Or it was never
>>> completely resolved?
>>
>> I believe Itaru is running on FVP (Fixed Virtual Platform - "fast model" -
>> Arm's architecture emulator). So QEMU won't be involved here. The FVP emulates
>> a 9p device, so perhaps the bug is in there.
>
> Very likely.
>
>>
>> Note that I see lots of "fallocate() failed" failures in gup_longterm when
>> running on our CI system. This is a completely different setup; Real HW with
>> Linux running bare metal using an NFS rootfs. I'm not sure if this is related.
>> Logs show it failing consistently for the "tmpfile" and "local tmpfile" test
>> configs. I also see a couple of these fails in the cow tests.
>
> What is the fallocate() errno you are getting? strace log would help (to see if
> statfs also fails already)! Likely a similar NFS issue.
Unfortunately this is a system I don't have access to. I've requested some of
this triage to be done, but its fairly low priority unfortunately.
_______________________________________________
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 v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Lucas Stach @ 2024-04-09 14:36 UTC (permalink / raw)
To: Vitor Soares, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <e1552a3008a30ef7ed9097b4b80cda23ccb9e840.camel@gmail.com>
Am Dienstag, dem 09.04.2024 um 14:22 +0100 schrieb Vitor Soares:
> Hi Lucas,
>
> Thanks for your feedback.
>
> On Tue, 2024-04-09 at 11:13 +0200, Lucas Stach wrote:
> > Hi Vitor,
> >
> > Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> > > From: Vitor Soares <vitor.soares@toradex.com>
> > >
> > > The pgc_vpu_* nodes miss the reference to the power domain parent,
> > > leading the system to hang during the resume.
> > >
> > This change is not correct. The vpumix domain is controlled through
> > the
> > imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
> > domains in order to guarantee proper power sequencing.
> >
> > If the sequencing is incorrect for resume, it needs to be fixed in
> > the
> > blk-ctrl driver. I'll happily assist if you have any questions about
> > this intricate mix between GPC and blk-ctrl hardware/drivers.
>
> I'm new into the topic, so I tried to follow same approach as in imx8mp
> DT.
>
That's a good hint, the 8MP VPU GPC node additions missed my radar. The
direct dependency there between the GPC domains is equally wrong.
> I also checked the imx8mq DT and it only have one domain for the
> VPU in the GPC. It seem blk-ctrl also dependes on pgc_vpu_* to work
> properly.
>
> The blk-ctrl driver hangs on imx8m_blk_ctrl_power_on() when access the
> ip registers for the soft reset. I tried to power-up the before the
> soft reset, but it didn't work.
>
The runtime_pm_get_sync() at the start of that function should ensure
that bus GPC domain aka vpumix is powered up. Can you check if that is
happening?
Regards,
Lucas
> Do you have an idea how we can address this within blk-ctrl?
>
> Best regards,
> Vitor
>
> >
> > Regards,
> > Lucas
> >
> > > As these PU domains are nested inside the vpumix domain, let's
> > > reference
> > > it accordingly. After this change, the suspend/resume is working.
> > >
> > > Cc: Lucas Stach <l.stach@pengutronix.de>
> > > Cc: <stable@vger.kernel.org>
> > > Closes:
> > > https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> > > Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> > > Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> > > ---
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > index 8a1b42b94dce..97d0c6d23ad8 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> > > pgc_vpu_g1: power-domain@7
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUG1>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_vpu_g2: power-domain@8
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUG2>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_vpu_h1: power-domain@9
> > > {
> > > #power-domain-cells
> > > = <0>;
> > > reg =
> > > <IMX8MM_POWER_DOMAIN_VPUH1>;
> > > + power-domains =
> > > <&pgc_vpumix>;
> > > };
> > >
> > > pgc_dispmix:
> > > power-domain@10 {
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Speed up boot with faster linear map creation
From: David Hildenbrand @ 2024-04-09 14:29 UTC (permalink / raw)
To: Ryan Roberts, Itaru Kitayama
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Donald Dutile, Eric Chanudet, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <b5e68f81-f917-4f82-8e86-a691a0721291@arm.com>
On 09.04.24 16:13, Ryan Roberts wrote:
> On 09/04/2024 12:51, David Hildenbrand wrote:
>> On 09.04.24 13:29, David Hildenbrand wrote:
>>> On 09.04.24 13:22, David Hildenbrand wrote:
>>>> On 09.04.24 12:13, Itaru Kitayama wrote:
>>>>>
>>>>>
>>>>>> On Apr 9, 2024, at 19:04, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>
>>>>>> On 09/04/2024 01:10, Itaru Kitayama wrote:
>>>>>>> Hi Ryan,
>>>>>>>
>>>>>>>> On Apr 8, 2024, at 16:30, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>>>
>>>>>>>> On 06/04/2024 11:31, Itaru Kitayama wrote:
>>>>>>>>> Hi Ryan,
>>>>>>>>>
>>>>>>>>> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote:
>>>>>>>>>> Hi Itaru,
>>>>>>>>>>
>>>>>>>>>> On 05/04/2024 08:39, Itaru Kitayama wrote:
>>>>>>>>>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> It turns out that creating the linear map can take a significant
>>>>>>>>>>>> proportion of
>>>>>>>>>>>> the total boot time, especially when rodata=full. And most of the
>>>>>>>>>>>> time is spent
>>>>>>>>>>>> waiting on superfluous tlb invalidation and memory barriers. This
>>>>>>>>>>>> series reworks
>>>>>>>>>>>> the kernel pgtable generation code to significantly reduce the number
>>>>>>>>>>>> of those
>>>>>>>>>>>> TLBIs, ISBs and DSBs. See each patch for details.
>>>>>>>>>>>>
>>>>>>>>>>>> The below shows the execution time of map_mem() across a couple of
>>>>>>>>>>>> different
>>>>>>>>>>>> systems with different RAM configurations. We measure after applying
>>>>>>>>>>>> each patch
>>>>>>>>>>>> and show the improvement relative to base (v6.9-rc2):
>>>>>>>>>>>>
>>>>>>>>>>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere
>>>>>>>>>>>> Altra
>>>>>>>>>>>> | VM, 16G | VM, 64G | VM, 256G | Metal,
>>>>>>>>>>>> 512G
>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>> | ms (%) | ms (%) | ms (%) |
>>>>>>>>>>>> ms (%)
>>>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%)
>>>>>>>>>>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%)
>>>>>>>>>>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656 (-91%)
>>>>>>>>>>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257 (-93%)
>>>>>>>>>>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838 (-95%)
>>>>>>>>>>>>
>>>>>>>>>>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've
>>>>>>>>>>>> compile and
>>>>>>>>>>>> boot tested various PAGE_SIZE and VA size configs.
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> Changes since v1 [1]
>>>>>>>>>>>> ====================
>>>>>>>>>>>>
>>>>>>>>>>>> - Added Tested-by tags (thanks to Eric and Itaru)
>>>>>>>>>>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
>>>>>>>>>>>> - Reordered patches (biggest impact & least controversial first)
>>>>>>>>>>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader
>>>>>>>>>>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync()
>>>>>>>>>>>> - Reverted generic p4d_index() which caused x86 build error.
>>>>>>>>>>>> Replaced with
>>>>>>>>>>>> unconditional p4d_index() define under arm64.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>> https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/<https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ryan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ryan Roberts (4):
>>>>>>>>>>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
>>>>>>>>>>>> arm64: mm: Batch dsb and isb when populating pgtables
>>>>>>>>>>>> arm64: mm: Don't remap pgtables for allocate vs populate
>>>>>>>>>>>> arm64: mm: Lazily clear pte table mappings from fixmap
>>>>>>>>>>>>
>>>>>>>>>>>> arch/arm64/include/asm/fixmap.h | 5 +-
>>>>>>>>>>>> arch/arm64/include/asm/mmu.h | 8 +
>>>>>>>>>>>> arch/arm64/include/asm/pgtable.h | 13 +-
>>>>>>>>>>>> arch/arm64/kernel/cpufeature.c | 10 +-
>>>>>>>>>>>> arch/arm64/mm/fixmap.c | 11 +
>>>>>>>>>>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
>>>>>>>>>>>> 6 files changed, 319 insertions(+), 105 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 2.25.1
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've build and boot tested the v2 on FVP, base is taken from your
>>>>>>>>>>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not
>>>>>>>>>>> oks, would you take a look at it? The mm ksefltests used is from your
>>>>>>>>>>> linux-rr repo too.
>>>>>>>>>>
>>>>>>>>>> Thanks for taking a look at this.
>>>>>>>>>>
>>>>>>>>>> I can't reproduce your issue unfortunately; steps as follows on Apple
>>>>>>>>>> M2 VM:
>>>>>>>>>>
>>>>>>>>>> Config: arm64 defconfig + the following:
>>>>>>>>>>
>>>>>>>>>> # Squashfs for snaps, xfs for large file folios.
>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZ4
>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZO
>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_XZ
>>>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD
>>>>>>>>>> ./scripts/config --enable CONFIG_XFS_FS
>>>>>>>>>>
>>>>>>>>>> # For general mm debug.
>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM
>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE
>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_RB
>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS
>>>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE
>>>>>>>>>> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK
>>>>>>>>>>
>>>>>>>>>> # For mm selftests.
>>>>>>>>>> ./scripts/config --enable CONFIG_USERFAULTFD
>>>>>>>>>> ./scripts/config --enable CONFIG_TEST_VMALLOC
>>>>>>>>>> ./scripts/config --enable CONFIG_GUP_TEST
>>>>>>>>>>
>>>>>>>>>> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes
>>>>>>>>>> (needed by
>>>>>>>>>> some mm selftests), with kernel command line to reserve hugetlbs and other
>>>>>>>>>> features required by some mm selftests:
>>>>>>>>>>
>>>>>>>>>> "
>>>>>>>>>> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
>>>>>>>>>> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
>>>>>>>>>> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K hugepages=0:2,1:2
>>>>>>>>>> "
>>>>>>>>>>
>>>>>>>>>> Ubuntu userspace running off XFS rootfs. Build and run mm selftests
>>>>>>>>>> from same
>>>>>>>>>> git tree.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Although I don't think any of this config should make a difference to
>>>>>>>>>> gup_longterm.
>>>>>>>>>>
>>>>>>>>>> Looks like your errors are all "ftruncate() failed". I've seen this
>>>>>>>>>> problem on
>>>>>>>>>> our CI system. There it is due to running the tests from NFS file
>>>>>>>>>> system. What
>>>>>>>>>> filesystem are you using? Perhaps you are sharing into the FVP using
>>>>>>>>>> 9p? That
>>>>>>>>>> might also be problematic.
>>>>>>>>>
>>>>>>>>> That was it. This time I booted up the kernel including your series on
>>>>>>>>> QEMU on my M1 and executed the gup_longterm program without the ftruncate
>>>>>>>>> failures. When testing your kernel on FVP, I was executing the script
>>>>>>>>> from the FVP's host filesystem using 9p.
>>>>>>>>
>>>>>>>> I'm not sure exactly what the root cause is. Perhaps there isn't enough
>>>>>>>> space on
>>>>>>>> the disk? It might be worth enhancing the error log to provide the errno in
>>>>>>>> tools/testing/selftests/mm/gup_longterm.c.
>>>>>>>>
>>>>>>>
>>>>>>> Attached is the strace’d gup_longterm executiong log on your
>>>>>>> pgtable-boot-speedup-v2 kernel.
>>>>>>
>>>>>> Sorry are you saying that it only fails with the pgtable-boot-speedup-v2 patch
>>>>>> set applied? I thought we previously concluded that it was independent of
>>>>>> that?
>>>>>> I was under the impression that it was filesystem related and not something
>>>>>> that
>>>>>> I was planning to investigate.
>>>>>
>>>>> No, irrespective of the kernel, if using 9p on FVP the test program fails.
>>>>> It is indeed 9p filesystem related, as I switched to using NFS all the
>>>>> issues are gone.
>>>>
>>>> Did it never work on 9p? If so, we might have to SKIP that test.
>>>>
>>>> openat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", O_RDWR|O_CREAT|O_EXCL,
>>>> 0600) = 3
>>>> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", 0) = 0
>>>> fstatfs(3, 0xffffe505a840) = -1 EOPNOTSUPP (Operation not
>>>> supported)
>>>> ftruncate(3, 4096) = -1 ENOENT (No such file or directory)
>>>
>>> Note: I'm wondering if the unlinkat here is the problem that makes
>>> ftruncate() with 9p result in weird errors (e.g., the hypervisor
>>> unlinked the file and cannot reopen it for the fstatfs/ftruncate. ...
>>> which gives us weird errors here).
>>>
>>> Then, we should lookup the fs type in run_with_local_tmpfile() before
>>> the unlink() and simply skip the test if it is 9p.
>>
>> The unlink with 9p most certainly was a known issue in the past:
>>
>> https://gitlab.com/qemu-project/qemu/-/issues/103
>>
>> Maybe it's still an issue with older hypervisors (QEMU?)? Or it was never
>> completely resolved?
>
> I believe Itaru is running on FVP (Fixed Virtual Platform - "fast model" - Arm's architecture emulator). So QEMU won't be involved here. The FVP emulates a 9p device, so perhaps the bug is in there.
Very likely.
>
> Note that I see lots of "fallocate() failed" failures in gup_longterm when running on our CI system. This is a completely different setup; Real HW with Linux running bare metal using an NFS rootfs. I'm not sure if this is related. Logs show it failing consistently for the "tmpfile" and "local tmpfile" test configs. I also see a couple of these fails in the cow tests.
What is the fallocate() errno you are getting? strace log would help (to
see if statfs also fails already)! Likely a similar NFS issue.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: mm: drop VM_FAULT_BADMAP/VM_FAULT_BADACCESS
From: Catalin Marinas @ 2024-04-09 14:28 UTC (permalink / raw)
To: Kefeng Wang
Cc: Andrew Morton, Russell King, Will Deacon, linux-arm-kernel,
linux-mm
In-Reply-To: <20240407081211.2292362-2-wangkefeng.wang@huawei.com>
Hi Kefeng,
On Sun, Apr 07, 2024 at 04:12:10PM +0800, Kefeng Wang wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 405f9aa831bd..61a2acae0dca 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -500,9 +500,6 @@ static bool is_write_abort(unsigned long esr)
> return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
> }
>
> -#define VM_FAULT_BADMAP ((__force vm_fault_t)0x010000)
> -#define VM_FAULT_BADACCESS ((__force vm_fault_t)0x020000)
> -
> static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> struct pt_regs *regs)
> {
> @@ -513,6 +510,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> unsigned int mm_flags = FAULT_FLAG_DEFAULT;
> unsigned long addr = untagged_addr(far);
> struct vm_area_struct *vma;
> + int si_code;
I think we should initialise this to 0. Currently all paths seem to set
si_code to something meaningful but I'm not sure the last 'else' close
in this patch is guaranteed to always cover exactly those earlier code
paths updating si_code. I'm not talking about the 'goto bad_area' paths
since they set 'fault' to 0 but the fall through after the second (under
the mm lock) handle_mm_fault().
> if (kprobe_page_fault(regs, esr))
> return 0;
> @@ -572,9 +570,10 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
>
> if (!(vma->vm_flags & vm_flags)) {
> vma_end_read(vma);
> - fault = VM_FAULT_BADACCESS;
> + fault = 0;
> + si_code = SEGV_ACCERR;
> count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> - goto done;
> + goto bad_area;
> }
> fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
> @@ -599,15 +598,18 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> retry:
> vma = lock_mm_and_find_vma(mm, addr, regs);
> if (unlikely(!vma)) {
> - fault = VM_FAULT_BADMAP;
> - goto done;
> + fault = 0;
> + si_code = SEGV_MAPERR;
> + goto bad_area;
> }
>
> - if (!(vma->vm_flags & vm_flags))
> - fault = VM_FAULT_BADACCESS;
> - else
> - fault = handle_mm_fault(vma, addr, mm_flags, regs);
> + if (!(vma->vm_flags & vm_flags)) {
> + fault = 0;
> + si_code = SEGV_ACCERR;
> + goto bad_area;
> + }
What's releasing the mm lock here? Prior to this change, it is falling
through to mmap_read_unlock() below or handle_mm_fault() was releasing
the lock (VM_FAULT_RETRY, VM_FAULT_COMPLETED).
>
> + fault = handle_mm_fault(vma, addr, mm_flags, regs);
> /* Quick path to respond to signals */
> if (fault_signal_pending(fault, regs)) {
> if (!user_mode(regs))
> @@ -626,13 +628,11 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> mmap_read_unlock(mm);
>
> done:
> - /*
> - * Handle the "normal" (no error) case first.
> - */
> - if (likely(!(fault & (VM_FAULT_ERROR | VM_FAULT_BADMAP |
> - VM_FAULT_BADACCESS))))
> + /* Handle the "normal" (no error) case first. */
> + if (likely(!(fault & VM_FAULT_ERROR)))
> return 0;
>
> +bad_area:
> /*
> * If we are in kernel mode at this point, we have no context to
> * handle this fault with.
> @@ -667,13 +667,8 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
>
> arm64_force_sig_mceerr(BUS_MCEERR_AR, far, lsb, inf->name);
> } else {
> - /*
> - * Something tried to access memory that isn't in our memory
> - * map.
> - */
> - arm64_force_sig_fault(SIGSEGV,
> - fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
> - far, inf->name);
> + /* Something tried to access memory that out of memory map */
> + arm64_force_sig_fault(SIGSEGV, si_code, far, inf->name);
> }
We can get to the 'else' close after the second handle_mm_fault(). Do we
guarantee that 'fault == 0' in this last block? If not, maybe a warning
and some safe initialisation for 'si_code' to avoid leaking stack data.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] Add missing mmc statistics in DW GMAC
From: Serge Semin @ 2024-04-09 14:26 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Jose Abreu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240408012943.66508-1-minda.chen@starfivetech.com>
On Mon, Apr 08, 2024 at 09:29:41AM +0800, Minda Chen wrote:
> Add miss MMC statistic in DW GMAC
>
> base on 6.9-rc1
>
> changed
> v2:
> patch2 : remove mmc_rx_control_g due to it is gotten in
> ethtool_ops::get_eth_ctrl_stats.
The series has already been merged in. Just a small note about the
patches. Both the changes seems reasonable:
LPI-statistics for DW GMAC and DW QoS Eth,
and
Rx-Recv and Tx-oversize errors stat for DW GMAC and DW QoS Eth.
The former stats has originally been added for DW XGMAC and the later
stats aren't supported by DW XGMAC. So the provided change is
complete. Thanks.
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
-Serge(y)
>
> Minda Chen (2):
> net: stmmac: mmc_core: Add GMAC LPI statistics
> net: stmmac: mmc_core: Add GMAC mmc tx/rx missing statistics
>
> drivers/net/ethernet/stmicro/stmmac/mmc.h | 2 ++
> drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 15 +++++++++++++++
> .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 ++
> 3 files changed, 19 insertions(+)
>
>
> base-commit: 4cece764965020c22cff7665b18a012006359095
> --
> 2.17.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Arseniy Krasnov @ 2024-04-09 14:10 UTC (permalink / raw)
To: Rob Herring
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-mtd, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel, oxffffaa, kernel
In-Reply-To: <20240409134718.GA1050037-robh@kernel.org>
On 09.04.2024 16:47, Rob Herring wrote:
> On Mon, Apr 08, 2024 at 11:59:30AM +0300, Arseniy Krasnov wrote:
>> Boot ROM code on Meson requires that some pages on NAND must be written
>> in special mode: "short" ECC mode where each block is 384 bytes and
>> scrambling mode is on. Such pages located with the specified interval
>> within specified offset. Both interval and offset are located in the
>> device tree and used by driver if 'nand-is-boot-medium' is set for
>> NAND chip.
>>
>> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
>> ---
>> .../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> index 57b6957c8415..80ba5003ca70 100644
>> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
>> @@ -64,11 +64,25 @@ patternProperties:
>> items:
>> maximum: 0
>>
>> + amlogic,boot-page-last:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The NFC driver needs this information to select ECC
>> + algorithms supported by the boot ROM.
>> +
>> + amlogic,boot-page-step:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + The NFC driver needs this information to select ECC
>> + algorithms supported by the boot ROM (in pages).
>> +
>> unevaluatedProperties: false
>>
>> dependencies:
>> nand-ecc-strength: [nand-ecc-step-size]
>> nand-ecc-step-size: [nand-ecc-strength]
>> + amlogic,boot-page-last: [nand-is-boot-medium, amlogic,boot-page-step]
>> + amlogic,boot-page-step: [nand-is-boot-medium, amlogic,boot-page-last]
>
> You need quotes if using the inline syntax.
IIUC it must look like this:
amlogic,boot-page-last: [nand-is-boot-medium, "amlogic,boot-page-step"]
etc.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault (2)
From: Puranjay Mohan @ 2024-04-09 14:18 UTC (permalink / raw)
To: syzbot, akpm, alexei.starovoitov, andrii.nakryiko, bpf,
linux-arm-kernel, linux-kernel, linux-mm, linux, mark.rutland,
syzkaller-bugs
In-Reply-To: <00000000000044fca50615a82595@google.com>
syzbot <syzbot+186522670e6722692d86@syzkaller.appspotmail.com> writes:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> INFO: task hung in _vm_unmap_aliases
>
> INFO: task kworker/0:41:4201 blocked for more than 430 seconds.
> Not tainted 6.9.0-rc1-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:kworker/0:41 state:D stack:0 pid:4201 tgid:4201 ppid:2 flags:0x00000000
> Workqueue: events bpf_prog_free_deferred
> Call trace:
> [<8189ad40>] (__schedule) from [<8189b97c>] (__schedule_loop kernel/sched/core.c:6823 [inline])
> [<8189ad40>] (__schedule) from [<8189b97c>] (schedule+0x2c/0xfc kernel/sched/core.c:6838)
> r10:82c16005 r9:00000000 r8:82714be8 r7:00000002 r6:dfd0dd94 r5:84dd1800
> r4:84dd1800
> [<8189b950>] (schedule) from [<8189bf8c>] (schedule_preempt_disabled+0x18/0x24 kernel/sched/core.c:6895)
> r5:84dd1800 r4:82714be4
> [<8189bf74>] (schedule_preempt_disabled) from [<8189e86c>] (__mutex_lock_common kernel/locking/mutex.c:684 [inline])
> [<8189bf74>] (schedule_preempt_disabled) from [<8189e86c>] (__mutex_lock.constprop.0+0x2e8/0xae0 kernel/locking/mutex.c:752)
> [<8189e584>] (__mutex_lock.constprop.0) from [<8189f138>] (__mutex_lock_slowpath+0x14/0x18 kernel/locking/mutex.c:1040)
> r10:82c16005 r9:dfd0de20 r8:00000000 r7:ffffffff r6:00000000 r5:84c7a680
> r4:00000000
> [<8189f124>] (__mutex_lock_slowpath) from [<8189f178>] (mutex_lock+0x3c/0x40 kernel/locking/mutex.c:286)
> [<8189f13c>] (mutex_lock) from [<8049c624>] (_vm_unmap_aliases+0x60/0x2e8 mm/vmalloc.c:2788)
> [<8049c5c4>] (_vm_unmap_aliases) from [<804a04a8>] (vm_reset_perms mm/vmalloc.c:3235 [inline])
> [<8049c5c4>] (_vm_unmap_aliases) from [<804a04a8>] (vfree+0x170/0x1e4 mm/vmalloc.c:3314)
> r10:82c16005 r9:00000001 r8:00000000 r7:ffffffff r6:00000000 r5:84c7a680
> r4:00000000
> [<804a0338>] (vfree) from [<802edb08>] (module_memfree+0x30/0x50 kernel/module/main.c:1189)
> r9:84dd1800 r8:00000080 r7:00000000 r6:82c16000 r5:00001000 r4:7f055000
> [<802edad8>] (module_memfree) from [<803916b0>] (bpf_jit_free_exec+0x10/0x14 kernel/bpf/core.c:1058)
> r5:00001000 r4:dfe91000
> [<803916a0>] (bpf_jit_free_exec) from [<80391870>] (bpf_jit_binary_free kernel/bpf/core.c:1104 [inline])
> [<803916a0>] (bpf_jit_free_exec) from [<80391870>] (bpf_jit_free+0x68/0xe4 kernel/bpf/core.c:1228)
> [<80391808>] (bpf_jit_free) from [<80392958>] (bpf_prog_free_deferred+0x14c/0x164 kernel/bpf/core.c:2783)
> r5:845b0754 r4:845b0400
> [<8039280c>] (bpf_prog_free_deferred) from [<8026678c>] (process_one_work+0x1b8/0x508 kernel/workqueue.c:3254)
> r7:dddd00c0 r6:82c16000 r5:845b0754 r4:84d7cb00
> [<802665d4>] (process_one_work) from [<802674b0>] (process_scheduled_works kernel/workqueue.c:3335 [inline])
> [<802665d4>] (process_one_work) from [<802674b0>] (worker_thread+0x1ec/0x418 kernel/workqueue.c:3416)
> r10:84dd1800 r9:84d7cb2c r8:61c88647 r7:dddd00e0 r6:82604d40 r5:dddd00c0
> r4:84d7cb00
> [<802672c4>] (worker_thread) from [<802701c4>] (kthread+0x104/0x134 kernel/kthread.c:388)
> r10:00000000 r9:dfa55e90 r8:845d8e80 r7:84d7cb00 r6:802672c4 r5:84dd1800
> r4:84c66500
> [<802700c0>] (kthread) from [<80200104>] (ret_from_fork+0x14/0x30 arch/arm/kernel/entry-common.S:134)
> Exception stack(0xdfd0dfb0 to 0xdfd0dff8)
> dfa0: 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:802700c0 r4:84c66500
> INFO: task kworker/1:55:4229 blocked for more than 430 seconds.
> Not tainted 6.9.0-rc1-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:kworker/1:55 state:D stack:0 pid:4229 tgid:4229 ppid:2 flags:0x00000000
> Workqueue: events bpf_prog_free_deferred
> Call trace:
> [<8189ad40>] (__schedule) from [<8189b97c>] (__schedule_loop kernel/sched/core.c:6823 [inline])
> [<8189ad40>] (__schedule) from [<8189b97c>] (schedule+0x2c/0xfc kernel/sched/core.c:6838)
> r10:82c16205 r9:00000000 r8:82714be8 r7:00000002 r6:dfe39d94 r5:84e83c00
> r4:84e83c00
> [<8189b950>] (schedule) from [<8189bf8c>] (schedule_preempt_disabled+0x18/0x24 kernel/sched/core.c:6895)
> r5:84e83c00 r4:82714be4
> [<8189bf74>] (schedule_preempt_disabled) from [<8189e86c>] (__mutex_lock_common kernel/locking/mutex.c:684 [inline])
> [<8189bf74>] (schedule_preempt_disabled) from [<8189e86c>] (__mutex_lock.constprop.0+0x2e8/0xae0 kernel/locking/mutex.c:752)
> [<8189e584>] (__mutex_lock.constprop.0) from [<8189f138>] (__mutex_lock_slowpath+0x14/0x18 kernel/locking/mutex.c:1040)
> r10:82c16205 r9:dfe39e20 r8:00000000 r7:ffffffff r6:00000000 r5:84c7a240
> r4:00000000
> [<8189f124>] (__mutex_lock_slowpath) from [<8189f178>] (mutex_lock+0x3c/0x40 kernel/locking/mutex.c:286)
> [<8189f13c>] (mutex_lock) from [<8049c624>] (_vm_unmap_aliases+0x60/0x2e8 mm/vmalloc.c:2788)
> [<8049c5c4>] (_vm_unmap_aliases) from [<804a04a8>] (vm_reset_perms mm/vmalloc.c:3235 [inline])
> [<8049c5c4>] (_vm_unmap_aliases) from [<804a04a8>] (vfree+0x170/0x1e4 mm/vmalloc.c:3314)
> r10:82c16205 r9:00000001 r8:00000000 r7:ffffffff r6:00000000 r5:84c7a240
> r4:00000000
> [<804a0338>] (vfree) from [<802edb08>] (module_memfree+0x30/0x50 kernel/module/main.c:1189)
> r9:84e83c00 r8:00000180 r7:00000000 r6:82c16200 r5:00001000 r4:7f053000
> [<802edad8>] (module_memfree) from [<803916b0>] (bpf_jit_free_exec+0x10/0x14 kernel/bpf/core.c:1058)
> r5:00001000 r4:dfe73000
> [<803916a0>] (bpf_jit_free_exec) from [<80391870>] (bpf_jit_binary_free kernel/bpf/core.c:1104 [inline])
> [<803916a0>] (bpf_jit_free_exec) from [<80391870>] (bpf_jit_free+0x68/0xe4 kernel/bpf/core.c:1228)
> [<80391808>] (bpf_jit_free) from [<80392958>] (bpf_prog_free_deferred+0x14c/0x164 kernel/bpf/core.c:2783)
> r5:845b2b54 r4:845b2800
> [<8039280c>] (bpf_prog_free_deferred) from [<8026678c>] (process_one_work+0x1b8/0x508 kernel/workqueue.c:3254)
> r7:ddde40c0 r6:82c16200 r5:845b2b54 r4:845d9f80
> [<802665d4>] (process_one_work) from [<802674b0>] (process_scheduled_works kernel/workqueue.c:3335 [inline])
> [<802665d4>] (process_one_work) from [<802674b0>] (worker_thread+0x1ec/0x418 kernel/workqueue.c:3416)
> r10:84e83c00 r9:845d9fac r8:61c88647 r7:ddde40e0 r6:82604d40 r5:ddde40c0
> r4:845d9f80
> [<802672c4>] (worker_thread) from [<802701c4>] (kthread+0x104/0x134 kernel/kthread.c:388)
> r10:00000000 r9:dfde5e90 r8:84640600 r7:845d9f80 r6:802672c4 r5:84e83c00
> r4:84c66300
> [<802700c0>] (kthread) from [<80200104>] (ret_from_fork+0x14/0x30 arch/arm/kernel/entry-common.S:134)
> Exception stack(0xdfe39fb0 to 0xdfe39ff8)
> 9fa0: 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:802700c0 r4:84c66300
> NMI backtrace for cpu 0
> CPU: 0 PID: 31 Comm: khungtaskd Not tainted 6.9.0-rc1-syzkaller #0
> Hardware name: ARM-Versatile Express
> Call trace:
> [<818795bc>] (dump_backtrace) from [<818796b8>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:256)
> r7:00000000 r6:00000113 r5:60000193 r4:81fc4768
> [<818796a0>] (show_stack) from [<81896e70>] (__dump_stack lib/dump_stack.c:88 [inline])
> [<818796a0>] (show_stack) from [<81896e70>] (dump_stack_lvl+0x70/0x7c lib/dump_stack.c:114)
> [<81896e00>] (dump_stack_lvl) from [<81896e94>] (dump_stack+0x18/0x1c lib/dump_stack.c:123)
> r5:00000000 r4:00000001
> [<81896e7c>] (dump_stack) from [<81866994>] (nmi_cpu_backtrace+0x160/0x17c lib/nmi_backtrace.c:113)
> [<81866834>] (nmi_cpu_backtrace) from [<81866ae0>] (nmi_trigger_cpumask_backtrace+0x130/0x1d8 lib/nmi_backtrace.c:62)
> r7:00000000 r6:8260c590 r5:8261a88c r4:ffffffff
> [<818669b0>] (nmi_trigger_cpumask_backtrace) from [<802105b4>] (arch_trigger_cpumask_backtrace+0x18/0x1c arch/arm/kernel/smp.c:851)
> r9:8260c6f4 r8:00007b4d r7:8289dfe0 r6:00007d59 r5:8500ee04 r4:850d4b24
> [<8021059c>] (arch_trigger_cpumask_backtrace) from [<8034ec48>] (trigger_all_cpu_backtrace include/linux/nmi.h:160 [inline])
> [<8021059c>] (arch_trigger_cpumask_backtrace) from [<8034ec48>] (check_hung_uninterruptible_tasks kernel/hung_task.c:223 [inline])
> [<8021059c>] (arch_trigger_cpumask_backtrace) from [<8034ec48>] (watchdog+0x480/0x594 kernel/hung_task.c:380)
> [<8034e7c8>] (watchdog) from [<802701c4>] (kthread+0x104/0x134 kernel/kthread.c:388)
> r10:00000000 r9:df819e58 r8:82e98440 r7:00000000 r6:8034e7c8 r5:82ee8c00
> r4:82f42100
> [<802700c0>] (kthread) from [<80200104>] (ret_from_fork+0x14/0x30 arch/arm/kernel/entry-common.S:134)
> Exception stack(0xdf8ddfb0 to 0xdf8ddff8)
> dfa0: 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:802700c0 r4:82f42100
> Sending NMI from CPU 0 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 5655 Comm: kworker/1:259 Not tainted 6.9.0-rc1-syzkaller #0
> Hardware name: ARM-Versatile Express
> Workqueue: wg-crypt-wg0 wg_packet_encrypt_worker
> PC is at poly1305_final_arch+0x0/0x80 arch/arm/crypto/poly1305-glue.c:189
> LR is at poly1305_final include/crypto/poly1305.h:94 [inline]
> LR is at chacha20poly1305_crypt_sg_inplace+0x43c/0x4b4 lib/crypto/chacha20poly1305.c:320
> pc : [<80232f80>] lr : [<807fa0e4>] psr: 60000113
> sp : eafa1990 ip : eafa1990 fp : eafa1bb4
> r10: 00000000 r9 : 00000000 r8 : 00000000
> r7 : eafa19e0 r6 : 00000000 r5 : 00000000 r4 : eafa19f0
> r3 : 00000000 r2 : 00000000 r1 : eafa19f0 r0 : eafa1a68
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 30c5387d Table: 8461dec0 DAC: 00000000
> Call trace:
> [<807f9ca8>] (chacha20poly1305_crypt_sg_inplace) from [<807fa188>] (chacha20poly1305_encrypt_sg_inplace+0x2c/0x34 lib/crypto/chacha20poly1305.c:338)
> r10:00000000 r9:00000000 r8:00000074 r7:00000001 r6:84dca018 r5:00000000
> r4:00000074
> [<807fa15c>] (chacha20poly1305_encrypt_sg_inplace) from [<80bfb0f8>] (encrypt_packet+0x194/0x230 drivers/net/wireguard/send.c:216)
> r5:00000000 r4:00000074
> [<80bfaf64>] (encrypt_packet) from [<80bfb8d0>] (wg_packet_encrypt_worker+0xbc/0x270 drivers/net/wireguard/send.c:297)
> r10:846c86e8 r9:82f2a540 r8:00000000 r7:846c86a0 r6:8260eea8 r5:00000000
> r4:82f2a540
> [<80bfb814>] (wg_packet_encrypt_worker) from [<8026678c>] (process_one_work+0x1b8/0x508 kernel/workqueue.c:3254)
> r10:84032e05 r9:85156000 r8:00000180 r7:ddde40c0 r6:84032e00 r5:ff7ffcf4
> r4:8505ff00
> [<802665d4>] (process_one_work) from [<802674b0>] (process_scheduled_works kernel/workqueue.c:3335 [inline])
> [<802665d4>] (process_one_work) from [<802674b0>] (worker_thread+0x1ec/0x418 kernel/workqueue.c:3416)
> r10:85156000 r9:8505ff2c r8:61c88647 r7:ddde40e0 r6:82604d40 r5:ddde40c0
> r4:8505ff00
> [<802672c4>] (worker_thread) from [<802701c4>] (kthread+0x104/0x134 kernel/kthread.c:388)
> r10:00000000 r9:eaeb1e90 r8:84ed1a40 r7:8505ff00 r6:802672c4 r5:85156000
> r4:847e7040
> [<802700c0>] (kthread) from [<80200104>] (ret_from_fork+0x14/0x30 arch/arm/kernel/entry-common.S:134)
> Exception stack(0xeafa1fb0 to 0xeafa1ff8)
> 1fa0: 00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:802700c0 r4:847e7040
>
>
> Tested on:
>
> commit: 7deb8d88 arm32, bpf: Fix sign-extension mov instruction
> git tree: https://github.com/puranjaymohan/linux.git arm32_movsx_fix
> console output: https://syzkaller.appspot.com/x/log.txt?x=175200cb180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=43f1e0cbdb852271
> dashboard link: https://syzkaller.appspot.com/bug?extid=186522670e6722692d86
> compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: arm
>
> Note: no patches were applied.
I am not able to reproduce the above locally. I don't think it is
related to the change.
Thanks,
Puranjay
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: mediatek: mt8395-nio-12l: Fix MT6360 regulator nodes names
From: AngeloGioacchino Del Regno @ 2024-04-09 14:14 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, devicetree, linux-kernel,
linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-2-angelogioacchino.delregno@collabora.com>
Il 09/04/24 13:42, AngeloGioacchino Del Regno ha scritto:
> The regulators' node names for mt6360-regulator are supposed to be
> uppercase. Also, drop "-regulator" from the usb-otg-vbus node name
> to make all vregs to probe correctly.
>
> The alternative would've been to use regulator-compatible, but that's
> a deprecated property.
> Now all regulators are probing fine.
>
> Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> index e5d9b671a405..18182cf073fb 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> @@ -216,7 +216,7 @@ charger {
> compatible = "mediatek,mt6360-chg";
> richtek,vinovp-microvolt = <14500000>;
>
> - otg_vbus_regulator: usb-otg-vbus-regulator {
> + otg_vbus_regulator: usb-otg-vbus {
Reviewing and NACK'ing my own patch, I just noticed that everything apart the
usb-otg-vbus renaming is wrong.
The MT6360 regulator node names should not be capitalized as the bindings are
correct in this regard, and there already is one user (genio-1200-evk) apart
from NIO-12L declaring the wrong ones - so, the driver must be fixed, not the
other way around.
This patch will be cleaned up in v2.
Cheers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox