* Re: [PATCH v8 1/3] perf: cs-etm: Move mapping of Trace ID and cpu into helper function
From: Leo Yan @ 2023-03-30 3:13 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Mike Leach, linux-perf-users, linux-arm-kernel, coresight,
linux-kernel, suzuki.poulose, peterz, mingo, will, mark.rutland,
alexander.shishkin, jolsa, namhyung, gankulkarni, darren,
James Clark
In-Reply-To: <ZCS4XJaWg7NvaWb7@kernel.org>
On Wed, Mar 29, 2023 at 07:14:52PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > Not here, I'll check after a call:
> >
> > 50 9.90 ubuntu:18.04-x-arm : FAIL gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)
> > arch/arm/util/cs-etm.c: In function 'cs_etm_save_ete_header':
> > arch/arm/util/cs-etm.c:720:29: error: implicit declaration of function 'coresight_get_trace_id' [-Werror=implicit-function-declaration]
> > data[CS_ETE_TRCTRACEIDR] = coresight_get_trace_id(cpu);
> > ^~~~~~~~~~~~~~~~~~~~~~
>
> This function was removed in:
>
> Author: Mike Leach <mike.leach@linaro.org>
> Date: Wed Mar 29 12:14:21 2023 +0100
>
> perf cs-etm: Update record event to use new Trace ID protocol
>
> Trace IDs are now dynamically allocated.
>
> I'm removing this series from perf-tools-next, please address this issue
> and send a v9.
I can reproduce this building failure. I am curious for how to verify
building for patch wise, the link [1] gives me some hints and below
command works for me:
$ git rebase -i --exec "make -C tools/perf clean && \
make -C tools/perf VF=1 DEBUG=1 CORESIGHT=1 && \
make -C tools/perf clean && \
make -C tools/perf VF=1 DEBUG=1" HEAD~3
Thanks,
Leo
[1] https://stackoverflow.com/questions/26983700/git-run-shell-command-for-each-commit
_______________________________________________
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 0/4] Add TPS6594 PMIC support on several boards
From: Nishanth Menon @ 2023-03-30 3:00 UTC (permalink / raw)
To: Esteban Blanc
Cc: vigneshr, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, sterzik, u-kumar1,
jneanne, jpanis
In-Reply-To: <20230329142948.833800-1-eblanc@baylibre.com>
$subject: minor comment: you don't need a v1 for the first version of
the patch series.
On 16:29-20230329, Esteban Blanc wrote:
> TPS6594 is a Power Management IC which provides regulators and others
> features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
> PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can
> communicate through the I2C or SPI interfaces.
> TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
>
> This should be applied on top of other patch series:
> - https://lore.kernel.org/all/20230327154101.211732-1-jpanis@baylibre.com/
> For core MFD driver
> - https://lore.kernel.org/all/20230328091448.648452-1-eblanc@baylibre.com/
> For regulator driver
OK - lets see these driver support get into an kernel rc1 tag before
looking at these patches for merge in this cycle, though this does
hold up other series
Such as https://lore.kernel.org/all/20230313-mcasp_upstream-v9-6-6d937efe4ec4@ti.com/
>
> This serie adds device tree nodes for TI TPS6594 PMICs found in the
> following boards:
> - j721eXSOMXEVM:
> Link: https://www.ti.com/tool/J721EXSOMXEVM
> - j721s2:
> Link: https://www.ti.com/tool/J721S2XSOMXEVM
> - j7200XSOMXEVM:
> Link: https://www.ti.com/tool/J7200XSOMXEVM
> - AM62A-SKEVM:
> Link: https://www.ti.com/tool/SK-AM62A-LP
>
> Esteban Blanc (2):
> arm64: dts: ti: k3-j7200-som-p0: Add TP6594 family PMICs
> arm64: dts: ti: k3-j721s2-som-p0: Add TP6594 family PMICs
>
> Jerome Neanne (1):
> arm64: dts: ti: k3-j721e-som-p0: Add TP6594 family PMICs
>
> Julien Panis (1):
> arm64: dts: ti: k3-am62a7-sk: Add support for TPS6593 PMIC
>
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 94 +++++++++
> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 170 +++++++++++++++
> arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi | 169 +++++++++++++++
> arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 208 +++++++++++++++++++
> 4 files changed, 641 insertions(+)
>
> --
> 2.39.2
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/6] arm64: defconfig: Enable audio drivers for TI K3 SoCs
From: Nishanth Menon @ 2023-03-30 2:54 UTC (permalink / raw)
To: Jai Luthra
Cc: Vignesh Raghavendra, Tero Kristo, Catalin Marinas, Will Deacon,
Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, linux-kernel,
devicetree, Aradhya Bhatia, Devarsh Thakkar, Jayesh Choudhary,
Andrew Davis
In-Reply-To: <20230313-mcasp_upstream-v9-1-6d937efe4ec4@ti.com>
$subject: I think you meant to state TLV320AIC3106 is needed for AM62 SK
boards than K3 SoCs ;)
On 16:00-20230329, Jai Luthra wrote:
> TI's K3 platform uses McASP as the digital audio interface on the SoCs.
> AM62x and AM62A based starter kits also use the TLV320AIC3106 codec with
> a 3.5mm jack for analog audio input and output.
>
> Signed-off-by: Jai Luthra <j-luthra@ti.com>
> Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
> ---
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ca3569261713..aa36792b6822 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -904,6 +904,8 @@ CONFIG_SND_SOC_LPASS_WSA_MACRO=m
> CONFIG_SND_SOC_LPASS_VA_MACRO=m
> CONFIG_SND_SOC_LPASS_RX_MACRO=m
> CONFIG_SND_SOC_LPASS_TX_MACRO=m
> +CONFIG_SND_SOC_DAVINCI_MCASP=m
> +CONFIG_SND_SOC_TLV320AIC3X_I2C=m
> CONFIG_SND_SIMPLE_CARD=m
> CONFIG_SND_AUDIO_GRAPH_CARD=m
> CONFIG_SND_AUDIO_GRAPH_CARD2=m
>
> --
> 2.40.0
>
please pay attention to savedefconfig output.
Something like this is more appropriate?
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ca3569261713..a13119aecaa1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -877,6 +877,7 @@ CONFIG_SND_SOC_TEGRA210_AMX=m
CONFIG_SND_SOC_TEGRA210_ADX=m
CONFIG_SND_SOC_TEGRA210_MIXER=m
CONFIG_SND_SOC_TEGRA_AUDIO_GRAPH_CARD=m
+CONFIG_SND_SOC_DAVINCI_MCASP=m
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_ES7134=m
CONFIG_SND_SOC_ES7241=m
@@ -891,6 +892,7 @@ CONFIG_SND_SOC_SIMPLE_MUX=m
CONFIG_SND_SOC_TAS2552=m
CONFIG_SND_SOC_TAS571X=m
CONFIG_SND_SOC_TLV320AIC32X4_I2C=m
+CONFIG_SND_SOC_TLV320AIC3X_I2C=m
CONFIG_SND_SOC_WCD9335=m
CONFIG_SND_SOC_WCD934X=m
CONFIG_SND_SOC_WM8524=m
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
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] scsi: ufs: core: Make UFS_MCQ_NUM_DEV_CMD_QUEUES a module parameter
From: Powen Kao (高伯文) @ 2023-03-30 2:52 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
jejb@linux.ibm.com, avri.altman@wdc.com, bvanassche@acm.org,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
alim.akhtar@samsung.com, linux-arm-kernel@lists.infradead.org,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com
Cc: Peter Wang (王信友),
Eddie Huang (黃智傑),
Jiajie Hao (郝加节),
CC Chou (周志杰),
Alice Chao (趙珮均), wsd_upstream,
Chun-Hung Wu (巫駿宏),
Chaotian Jing (井朝天),
Naomi Chu (朱詠田),
Stanley Chu (朱原陞),
Mason Zhang (章辉)
In-Reply-To: <9266aa1b-2d63-43d5-f06e-5a228bc131be@acm.org>
On Tue, 2023-03-28 at 20:17 -0700, Bart Van Assche wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On 3/28/23 03:29, Po-Wen Kao wrote:
> > A dedicated queue for dev commands is not mandatory, hence let
> > UFS_MCQ_NUM_DEV_CMD_QUEUES become module parameter `dev_cmd_queues`
> > to allow sharing first hw queue for dev commands.
>
> Which queue is selected for device management commands?
Queue 0 is selected by default.
@@ -423,8 +441,11 @@ int ufshcd_mcq_init(struct ufs_hba *hba)
/* The very first HW queue serves device commands */
hba->dev_cmd_queue = &hba->uhq[0];
>
> What is the impact of this change? If a device command is queued on a
> queue with multiple pending commands, does that mean that it can take
> long for the device command to reach the UFS device?
>
> The answer to the above questions should be in the patch description.
> Please expand the patch description.
I will make commit message clear in next update.
> > +unsigned int dev_cmd_queues = 1;
> > +module_param_cb(dev_cmd_queues, &dev_cmd_queue_count_ops,
> > &dev_cmd_queues, 0644);
> > +MODULE_PARM_DESC(dev_cmd_queues,
> > + "Number of queues used for dev command. Default
> > value is 1");
>
> I prefer a solution that does not require any new kernel module
> parameters. That means either a dedicated device command queue for
> all
> host controllers or no dedicated device command queue for any host
> controller.
The motivation of this patch is to adapt UFS driver to different host
hardware. IMHO, some host may implement a dedicated (extra) queue for
dev commands but not all does. In general, one hw queue per CPU (IO
queue) topology is desired, hence sharing a hw queue is inevitable on those host without a dedicated dev cmd queue. The host with dedicated queue will keep the benifit of having fast channel for dev commands.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 6/6] arm64: dts: ti: k3-am62a7-sk: Enable audio on AM62A
From: Nishanth Menon @ 2023-03-30 2:50 UTC (permalink / raw)
To: Jai Luthra
Cc: Vignesh Raghavendra, Tero Kristo, Catalin Marinas, Will Deacon,
Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, linux-kernel,
devicetree, Aradhya Bhatia, Devarsh Thakkar, Jayesh Choudhary,
Andrew Davis
In-Reply-To: <20230313-mcasp_upstream-v9-6-6d937efe4ec4@ti.com>
On 16:01-20230329, Jai Luthra wrote:
> Add nodes for audio codec and sound card, enable the audio serializer
> (McASP1) under use and update pinmux.
>
> The codec (TLV320AIC3106) is also supplied with a DVDD 1.8V supply from
> the PMIC (TPS6593x) on the SK. [1] As the PMIC driver and devicetree
> node is missing, skip describing DVDD for now and manually set the OCMV
> voltage.
Please drop the am62a7 series from this patch series. once you add PMIC
device tree property, then lets add the dvdd properly rather than
reworking this again.
>
> Link: https://www.ti.com/lit/zip/sprr459 [1]
> Signed-off-by: Jai Luthra <j-luthra@ti.com>
> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 77 +++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index 2296d656323c..8d7087e5f9e4 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -123,6 +123,41 @@ led-0 {
> default-state = "off";
> };
> };
> +
> + tlv320_mclk: clk-0 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <12288000>;
> + };
> +
> + codec_audio: sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "AM62Ax-SKEVM";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone Jack",
> + "Line", "Line In",
> + "Microphone", "Microphone Jack";
> + simple-audio-card,routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT",
> + "LINE1L", "Line In",
> + "LINE1R", "Line In",
> + "MIC3R", "Microphone Jack",
> + "Microphone Jack", "Mic Bias";
> + simple-audio-card,format = "dsp_b";
> + simple-audio-card,bitclock-master = <&sound_master>;
> + simple-audio-card,frame-master = <&sound_master>;
> + simple-audio-card,bitclock-inversion;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&mcasp1>;
> + };
> +
> + sound_master: simple-audio-card,codec {
> + sound-dai = <&tlv320aic3106>;
> + clocks = <&tlv320_mclk>;
> + };
> + };
> };
>
> &main_pmx0 {
> @@ -201,6 +236,15 @@ AM62AX_IOPAD(0x130, PIN_INPUT, 0) /* (AB17) RGMII1_TXC */
> AM62AX_IOPAD(0x12c, PIN_INPUT, 0) /* (W16) RGMII1_TX_CTL */
> >;
> };
> +
> + main_mcasp1_pins_default: main-mcasp1-pins-default {
> + pinctrl-single,pins = <
> + AM62AX_IOPAD(0x090, PIN_INPUT, 2) /* (L19) GPMC0_BE0n_CLE.MCASP1_ACLKX */
> + AM62AX_IOPAD(0x098, PIN_INPUT, 2) /* (R18) GPMC0_WAIT0.MCASP1_AFSX */
> + AM62AX_IOPAD(0x08c, PIN_OUTPUT, 2) /* (K19) GPMC0_WEn.MCASP1_AXR0 */
> + AM62AX_IOPAD(0x084, PIN_INPUT, 2) /* (L18) GPMC0_ADVn_ALE.MCASP1_AXR2 */
> + >;
> + };
> };
>
> &main_i2c0 {
> @@ -235,6 +279,19 @@ exp1: gpio@22 {
> "MCASP1_FET_SEL", "UART1_FET_SEL",
> "PD_I2C_IRQ", "IO_EXP_TEST_LED";
> };
> +
> + tlv320aic3106: audio-codec@1b {
> + #sound-dai-cells = <0>;
> + compatible = "ti,tlv320aic3106";
> + reg = <0x1b>;
> + ai3x-micbias-vg = <1>; /* 2.0V */
> + ai3x-ocmv = <1>; /* 1.5V */
> +
> + /* Regulators */
> + AVDD-supply = <&vcc_3v3_sys>;
> + IOVDD-supply = <&vcc_3v3_sys>;
> + DRVDD-supply = <&vcc_3v3_sys>;
> + };
> };
>
> &sdhci1 {
> @@ -303,3 +360,23 @@ cpsw3g_phy0: ethernet-phy@0 {
> ti,min-output-impedance;
> };
> };
> +
> +&mcasp1 {
> + status = "okay";
> + #sound-dai-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcasp1_pins_default>;
> +
> + op-mode = <0>; /* MCASP_IIS_MODE */
> + tdm-slots = <2>;
> +
> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
> + 1 0 2 0
> + 0 0 0 0
> + 0 0 0 0
> + 0 0 0 0
> + >;
> + tx-num-evt = <32>;
> + rx-num-evt = <32>;
> +};
>
> --
> 2.40.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
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 v7 1/5] clk: Introduce devm_clk_hw_register_gate_parent_data()
From: Peng Fan @ 2023-03-30 2:25 UTC (permalink / raw)
To: Marek Vasut, linux-clk@vger.kernel.org, sboyd@kernel.org,
Abel Vesa
Cc: Fabio Estevam, Adam Ford, Alexander Stein, Abel Vesa, Jacky Bai,
Krzysztof Kozlowski, Laurent Pinchart, Luca Ceresoli, Lucas Stach,
Marco Felsch, Michael Turquette, dl-linux-imx,
Pengutronix Kernel Team, Richard Cochran, Rob Herring,
Sascha Hauer, Shawn Guo, Stephen Boyd, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20230301163257.49005-1-marex@denx.de>
Hi Stephen, Abel
Would you merge this patchset from Marek for next tree?
Thanks,
Peng.
> Subject: [PATCH v7 1/5] clk: Introduce
> devm_clk_hw_register_gate_parent_data()
>
> Add an API for clock gate that uses parent_data for the parent instead of a
> string parent_name.
>
> Reviewed-by: Peng Fan <peng.fan@nxp.com>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon-kit
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Abel Vesa <abelvesa@kernel.org>
> Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Jacky Bai <ping.bai@nxp.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Marco Felsch <m.felsch@pengutronix.de>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Peng Fan <peng.fan@nxp.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-clk@vger.kernel.org
> ---
> V3: New patch
> V4: - Rebase on next 20230223
> V5: Add TB from Adam and Alexander
> V6: Add RB from Fabio
> V7: Add RB from Peng
> ---
> include/linux/clk-provider.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index
> 842e72a5348fa..92b7c794c6272 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -608,6 +608,25 @@ struct clk *clk_register_gate(struct device *dev,
> const char *name,
> __devm_clk_hw_register_gate((dev), NULL, (name), (parent_name),
> NULL, \
> NULL, (flags), (reg), (bit_idx), \
> (clk_gate_flags), (lock))
> +
> +/**
> + * devm_clk_hw_register_gate - register a gate clock with the clock
> +framework
> + * @dev: device that is registering this clock
> + * @name: name of this clock
> + * @parent_data: parent clk data
> + * @flags: framework-specific flags for this clock
> + * @reg: register address to control gating of this clock
> + * @bit_idx: which bit in the register controls gating of this clock
> + * @clk_gate_flags: gate-specific flags for this clock
> + * @lock: shared register lock for this clock */ #define
> +devm_clk_hw_register_gate_parent_data(dev, name, parent_data, flags, \
> + reg, bit_idx, clk_gate_flags, \
> + lock) \
> + __devm_clk_hw_register_gate((dev), NULL, (name), NULL, NULL,
> \
> + (parent_data), (flags), (reg), (bit_idx), \
> + (clk_gate_flags), (lock))
> +
> void clk_unregister_gate(struct clk *clk); void
> clk_hw_unregister_gate(struct clk_hw *hw); int clk_gate_is_enabled(struct
> clk_hw *hw);
> --
> 2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] arm64: dts: ti: k3-am625-sk: Enable Type-C dual-role
From: Nishanth Menon @ 2023-03-30 2:16 UTC (permalink / raw)
To: vigneshr, Roger Quadros
Cc: Nishanth Menon, kristo, srk, r-gunasekaran, linux-arm-kernel,
linux-usb, linux-kernel, devicetree
In-Reply-To: <20230328124315.123778-1-rogerq@kernel.org>
Hi Roger Quadros,
On Tue, 28 Mar 2023 15:43:13 +0300, Roger Quadros wrote:
> This series enables Type-C port on USB0.
> Series is based on [1]
>
> Although k3-am625-lp-sk USB is exactly the same as on k3-am625-sk,
> it is missing the IRQ line from Type-C chip which is currently
> required as per chip's DT binding. So we don't add Type-C support
> for k3-am625-lp-sk till h/w is fixed or polling mode support for
> Type-C chip is accepted [2]
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1]. I picked v1
version with v2 updates in commit message to help stable, while at it,
I had to rewrite history a bit so that cherry-pick to stable won't be a
problem.
Thank you!
[1/2] arm64: dts: ti: k3-am625-sk: Add ti,vbus-divider property to usbss1
commit: 49af4ecdd8ad2a964dbb9f2e7e50082433b37f98
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
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] drm/mediatek: Add ovl_adaptor get format function
From: Nancy Lin (林欣螢) @ 2023-03-30 1:48 UTC (permalink / raw)
To: CK Hu (胡俊光), p.zabel@pengutronix.de,
matthias.bgg@gmail.com, chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: dri-devel@lists.freedesktop.org,
Shawn Sung (宋孝謙),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Singo Chang (張興國),
Project_Global_Chrome_Upstream_Group,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <ceb353983d48c5a0a967de7ea256dbe6a5de6bed.camel@mediatek.com>
Hi CK,
Thanks for the review.
On Wed, 2023-03-29 at 08:15 +0000, CK Hu (胡俊光) wrote:
> Hi, Nancy:
>
> On Wed, 2023-03-29 at 09:59 +0800, Nancy.Lin wrote:
> > Add ovl_adaptor get_format and get_num_formats component function.
> > The two functions are need for getting the supported format in
> > mtk_plane_init().
> >
> > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 ++
> > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 24
> > +++++++++++++++++++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
> > 3 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 0d28b2e2069c..da2de17b84e9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -124,6 +124,8 @@ void mtk_ovl_adaptor_start(struct device *dev);
> > void mtk_ovl_adaptor_stop(struct device *dev);
> > unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
> > struct device *mtk_ovl_adaptor_dma_dev_get(struct device *dev);
> > +const u32 *mtk_ovl_adaptor_get_formats(struct device *dev);
> > +size_t mtk_ovl_adaptor_get_num_formats(struct device *dev);
> >
> > void mtk_rdma_bypass_shadow(struct device *dev);
> > int mtk_rdma_clk_enable(struct device *dev);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > index 046217828ab3..b5d28c392c57 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
> > @@ -25,6 +25,20 @@
> > #define MTK_OVL_ADAPTOR_RDMA_MAX_WIDTH 1920
> > #define MTK_OVL_ADAPTOR_LAYER_NUM 4
> >
> > +static const u32 formats[] = {
> > + DRM_FORMAT_XRGB8888,
> > + DRM_FORMAT_ARGB8888,
> > + DRM_FORMAT_BGRX8888,
> > + DRM_FORMAT_BGRA8888,
> > + DRM_FORMAT_ABGR8888,
> > + DRM_FORMAT_XBGR8888,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_RGB565,
> > + DRM_FORMAT_UYVY,
> > + DRM_FORMAT_YUYV,
> > +};
> > +
> > enum mtk_ovl_adaptor_comp_type {
> > OVL_ADAPTOR_TYPE_RDMA = 0,
> > OVL_ADAPTOR_TYPE_MERGE,
> > @@ -297,6 +311,16 @@ void mtk_ovl_adaptor_disable_vblank(struct
> > device *dev)
> > mtk_ethdr_disable_vblank(ovl_adaptor-
> > > ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
> >
> > }
> >
> > +const u32 *mtk_ovl_adaptor_get_formats(struct device *dev)
> > +{
> > + return formats;
>
> The supported formats depend on the mdp-rdma hardware capability, so
> get formats from mdp-rdma driver.
>
> Regards,
> CK
>
OK, I will add mdp-rdma supported format api for ovl_adaptor.
Regards,
Nancy
> > +}
> > +
> > +size_t mtk_ovl_adaptor_get_num_formats(struct device *dev)
> > +{
> > + return ARRAY_SIZE(formats);
> > +}
> > +
> > void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex
> > *mutex)
> > {
> > mtk_mutex_add_comp(mutex, DDP_COMPONENT_MDP_RDMA0);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 1a0c4f7e352a..f114da4d36a9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -410,6 +410,8 @@ static const struct mtk_ddp_comp_funcs
> > ddp_ovl_adaptor = {
> > .disconnect = mtk_ovl_adaptor_disconnect,
> > .add = mtk_ovl_adaptor_add_comp,
> > .remove = mtk_ovl_adaptor_remove_comp,
> > + .get_formats = mtk_ovl_adaptor_get_formats,
> > + .get_num_formats = mtk_ovl_adaptor_get_num_formats,
> > };
> >
> > static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX]
> > =
> > {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND 1/6] dt-bindings: memory-controllers: mediatek,smi-common: add mt8365
From: Yong Wu (吴勇) @ 2023-03-30 1:53 UTC (permalink / raw)
To: amergnat@baylibre.com, matthias.bgg@gmail.com,
krzysztof.kozlowski@linaro.org,
angelogioacchino.delregno@collabora.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <20230207-iommu-support-v1-1-4a902f9aa412@baylibre.com>
On Wed, 2023-03-29 at 11:52 +0200, Alexandre Mergnat wrote:
>
> Add binding description for mediatek,mt8365-smi-common
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
> ---
> .../devicetree/bindings/memory-controllers/mediatek,smi-
> common.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/memory-
> controllers/mediatek,smi-common.yaml
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-
> common.yaml
> index a8fda30cccbb..d599a190952f 100644
> --- a/Documentation/devicetree/bindings/memory-
> controllers/mediatek,smi-common.yaml
> +++ b/Documentation/devicetree/bindings/memory-
> controllers/mediatek,smi-common.yaml
> @@ -49,6 +49,10 @@ properties:
> - const: mediatek,mt7623-smi-common
> - const: mediatek,mt2701-smi-common
>
> + - items:
> + - const: mediatek,mt8365-smi-common
> + - const: mediatek,mt8186-smi-common
> +
mt8365 is not same with mt8186.
From the code, the bus_sel for mt8186 is:
.bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(4) | F_MMU1_LARB(7),
the bus_sel for mt8365 is:
.bus_sel = F_MMU1_LARB(2) | F_MMU1_LARB(4),
I guess we should add a independent "mediatek,mt8365-smi-common".
> reg:
> maxItems: 1
>
>
> --
> 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
* Re: [PATCH RESEND 6/6] arm64: dts: mediatek: add iommu support for mt8365 SoC
From: Yong Wu (吴勇) @ 2023-03-30 1:52 UTC (permalink / raw)
To: amergnat@baylibre.com, matthias.bgg@gmail.com,
krzysztof.kozlowski@linaro.org,
angelogioacchino.delregno@collabora.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <20230207-iommu-support-v1-6-4a902f9aa412@baylibre.com>
On Wed, 2023-03-29 at 11:52 +0200, Alexandre Mergnat wrote:
>
> Add iommu support in the SoC DTS using the 4 local arbiters (LARBs)
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: arm64: Add FEAT_TLBIRANGE support
From: Oliver Upton @ 2023-03-30 1:19 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Oliver Upton, Marc Zyngier, Ricardo Koller, Reiji Watanabe,
James Morse, Alexandru Elisei, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Catalin Marinas, Jing Zhang, Colton Lewis,
linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <20230206172340.2639971-3-rananta@google.com>
On Mon, Feb 06, 2023 at 05:23:35PM +0000, Raghavendra Rao Ananta wrote:
> Define a generic function __kvm_tlb_flush_range() to
> invalidate the TLBs over a range of addresses. The
> implementation accepts 'op' as a generic TLBI operation.
> Upcoming patches will use this to implement IPA based
> TLB invalidations (ipas2e1is).
>
> If the system doesn't support FEAT_TLBIRANGE, the
> implementation falls back to flushing the pages one by one
> for the range supplied.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_asm.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 43c3bc0f9544d..995ff048e8851 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -221,6 +221,24 @@ DECLARE_KVM_NVHE_SYM(__per_cpu_end);
> DECLARE_KVM_HYP_SYM(__bp_harden_hyp_vecs);
> #define __bp_harden_hyp_vecs CHOOSE_HYP_SYM(__bp_harden_hyp_vecs)
>
> +#define __kvm_tlb_flush_range(op, mmu, start, end, level, tlb_level) do { \
> + unsigned long pages, stride; \
> + \
> + stride = kvm_granule_size(level); \
Hmm... There's a rather subtle and annoying complication here that I
don't believe is handled.
Similar to what I said in the last spin of the series, there is no
guarantee that a range of IPAs is mapped at the exact same level
throughout. Dirty logging and memslots that aren't hugepage aligned
could lead to a mix of mapping levels being used within a range of the
IPA space.
> + start = round_down(start, stride); \
> + end = round_up(end, stride); \
> + pages = (end - start) >> PAGE_SHIFT; \
> + \
> + if ((!system_supports_tlb_range() && \
> + (end - start) >= (MAX_TLBI_OPS * stride)) || \
Doesn't checking for TLBIRANGE above eliminate the need to test against
MAX_TLBI_OPS?
> + pages >= MAX_TLBI_RANGE_PAGES) { \
> + __kvm_tlb_flush_vmid(mmu); \
> + break; \
> + } \
> + \
> + __flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false); \
> +} while (0)
> +
> extern void __kvm_flush_vm_context(void);
> extern void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu);
> extern void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t ipa,
> --
> 2.39.1.519.gcb327c4b5f-goog
>
>
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/7] KVM: arm64: Implement __kvm_tlb_flush_range_vmid_ipa()
From: Oliver Upton @ 2023-03-30 0:59 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Oliver Upton, Marc Zyngier, Ricardo Koller, Reiji Watanabe,
James Morse, Alexandru Elisei, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Catalin Marinas, Jing Zhang, Colton Lewis,
linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <20230206172340.2639971-4-rananta@google.com>
On Mon, Feb 06, 2023 at 05:23:36PM +0000, Raghavendra Rao Ananta wrote:
> Define __kvm_tlb_flush_range_vmid_ipa() (for VHE and nVHE)
bikeshed: Personally, I find that range implies it takes an address as an
argument already. Maybe just call it __kvm_tlb_flush_vmid_range()
> to flush a range of stage-2 page-tables using IPA in one go.
> If the system supports FEAT_TLBIRANGE, the following patches
> would conviniently replace global TLBI such as vmalls12e1is
> in the map, unmap, and dirty-logging paths with ripas2e1is
> instead.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_asm.h | 3 +++
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 12 ++++++++++++
> arch/arm64/kvm/hyp/nvhe/tlb.c | 28 ++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/vhe/tlb.c | 24 ++++++++++++++++++++++++
> 4 files changed, 67 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 995ff048e8851..80a8ea85e84f8 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -79,6 +79,7 @@ enum __kvm_host_smccc_func {
> __KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
> __KVM_HOST_SMCCC_FUNC___pkvm_init_vcpu,
> __KVM_HOST_SMCCC_FUNC___pkvm_teardown_vm,
> + __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_range_vmid_ipa,
> };
>
> #define DECLARE_KVM_VHE_SYM(sym) extern char sym[]
> @@ -243,6 +244,8 @@ extern void __kvm_flush_vm_context(void);
> extern void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu);
> extern void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t ipa,
> int level);
> +extern void __kvm_tlb_flush_range_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t start,
> + phys_addr_t end, int level, int tlb_level);
> extern void __kvm_tlb_flush_vmid(struct kvm_s2_mmu *mmu);
>
> extern void __kvm_timer_set_cntvoff(u64 cntvoff);
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 728e01d4536b0..5787eee4c9fe4 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -125,6 +125,17 @@ static void handle___kvm_tlb_flush_vmid_ipa(struct kvm_cpu_context *host_ctxt)
> __kvm_tlb_flush_vmid_ipa(kern_hyp_va(mmu), ipa, level);
> }
>
> +static void handle___kvm_tlb_flush_range_vmid_ipa(struct kvm_cpu_context *host_ctxt)
> +{
> + DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
> + DECLARE_REG(phys_addr_t, start, host_ctxt, 2);
> + DECLARE_REG(phys_addr_t, end, host_ctxt, 3);
> + DECLARE_REG(int, level, host_ctxt, 4);
> + DECLARE_REG(int, tlb_level, host_ctxt, 5);
> +
> + __kvm_tlb_flush_range_vmid_ipa(kern_hyp_va(mmu), start, end, level, tlb_level);
> +}
> +
> static void handle___kvm_tlb_flush_vmid(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
> @@ -315,6 +326,7 @@ static const hcall_t host_hcall[] = {
> HANDLE_FUNC(__kvm_vcpu_run),
> HANDLE_FUNC(__kvm_flush_vm_context),
> HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa),
> + HANDLE_FUNC(__kvm_tlb_flush_range_vmid_ipa),
> HANDLE_FUNC(__kvm_tlb_flush_vmid),
> HANDLE_FUNC(__kvm_flush_cpu_context),
> HANDLE_FUNC(__kvm_timer_set_cntvoff),
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index d296d617f5896..7398dd00445e7 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -109,6 +109,34 @@ void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
> __tlb_switch_to_host(&cxt);
> }
>
> +void __kvm_tlb_flush_range_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t start,
> + phys_addr_t end, int level, int tlb_level)
> +{
> + struct tlb_inv_context cxt;
> +
> + dsb(ishst);
> +
> + /* Switch to requested VMID */
> + __tlb_switch_to_guest(mmu, &cxt);
> +
> + __kvm_tlb_flush_range(ipas2e1is, mmu, start, end, level, tlb_level);
> +
> + /*
> + * Range-based ipas2e1is flushes only Stage-2 entries, and since the
> + * VA isn't available for Stage-1 entries, flush the entire stage-1.
> + */
nit: if we are going to preserve some of the commentary over in
__kvm_tlb_flush_vmid_ipa(), I would prefer just an exact copy/paste.
But, FWIW, I think you can just elide the clarifying comments altogether
since the relationship between stage-1 and stage-2 invalidations is
already documented.
> + dsb(ish);
> + __tlbi(vmalle1is);
> + dsb(ish);
> + isb();
> +
> + /* See the comment below in __kvm_tlb_flush_vmid_ipa() */
Same comment as above.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/7] KVM: arm64: Implement kvm_arch_flush_remote_tlbs_range()
From: Oliver Upton @ 2023-03-30 0:53 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Oliver Upton, Marc Zyngier, Ricardo Koller, Reiji Watanabe,
James Morse, Alexandru Elisei, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Catalin Marinas, Jing Zhang, Colton Lewis,
linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <20230206172340.2639971-5-rananta@google.com>
On Mon, Feb 06, 2023 at 05:23:37PM +0000, Raghavendra Rao Ananta wrote:
> Implement kvm_arch_flush_remote_tlbs_range() for arm64,
> such that it can utilize the TLBI range based instructions
> if supported.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/kvm/mmu.c | 15 +++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index dee530d75b957..211fab0c1de74 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -1002,6 +1002,9 @@ struct kvm *kvm_arch_alloc_vm(void);
> #define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS
> int kvm_arch_flush_remote_tlbs(struct kvm *kvm);
>
> +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE
> +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages);
> +
> static inline bool kvm_vm_is_protected(struct kvm *kvm)
> {
> return false;
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index e98910a8d0af6..409cb187f4911 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -91,6 +91,21 @@ int kvm_arch_flush_remote_tlbs(struct kvm *kvm)
> return 0;
> }
>
> +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages)
> +{
> + phys_addr_t start, end;
> +
> + if (!system_supports_tlb_range())
> + return -EOPNOTSUPP;
There's multiple layers of fallback throughout this series, as it would
appear that deep in __kvm_tlb_flush_range() you're blasting the whole
VMID if either the range is too large or the feature isn't supported.
Is it possible to just normalize on a single spot to gate the use of
range-based invalidations? I have a slight preference for doing it deep
in the handler, as it keeps the upper layers of code a bit more
readable.
> + start = start_gfn << PAGE_SHIFT;
> + end = (start_gfn + pages) << PAGE_SHIFT;
> +
> + kvm_call_hyp(__kvm_tlb_flush_range_vmid_ipa, &kvm->arch.mmu,
> + start, end, KVM_PGTABLE_MAX_LEVELS - 1, 0);
> + return 0;
> +}
> +
> static bool kvm_is_device_pfn(unsigned long pfn)
> {
> return !pfn_is_map_memory(pfn);
> --
> 2.39.1.519.gcb327c4b5f-goog
>
>
--
Thanks,
Oliver
_______________________________________________
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 7/7] KVM: arm64: Create a fast stage-2 unmap path
From: Oliver Upton @ 2023-03-30 0:42 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Oliver Upton, Marc Zyngier, Ricardo Koller, Reiji Watanabe,
James Morse, Alexandru Elisei, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Catalin Marinas, Jing Zhang, Colton Lewis,
linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <20230206172340.2639971-8-rananta@google.com>
On Mon, Feb 06, 2023 at 05:23:40PM +0000, Raghavendra Rao Ananta wrote:
> The current implementation of the stage-2 unmap walker
> traverses the entire page-table to clear and flush the TLBs
> for each entry. This could be very expensive, especially if
> the VM is not backed by hugepages. The unmap operation could be
> made efficient by disconnecting the table at the very
> top (level at which the largest block mapping can be hosted)
> and do the rest of the unmapping using free_removed_table().
> If the system supports FEAT_TLBIRANGE, flush the entire range
> that has been disconnected from the rest of the page-table.
>
> Suggested-by: Ricardo Koller <ricarkol@google.com>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/kvm/hyp/pgtable.c | 44 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 0858d1fa85d6b..af3729d0971f2 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -1017,6 +1017,49 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
> return 0;
> }
>
> +/*
> + * The fast walker executes only if the unmap size is exactly equal to the
> + * largest block mapping supported (i.e. at KVM_PGTABLE_MIN_BLOCK_LEVEL),
> + * such that the underneath hierarchy at KVM_PGTABLE_MIN_BLOCK_LEVEL can
> + * be disconnected from the rest of the page-table without the need to
> + * traverse all the PTEs, at all the levels, and unmap each and every one
> + * of them. The disconnected table is freed using free_removed_table().
> + */
> +static int fast_stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
> + enum kvm_pgtable_walk_flags visit)
> +{
> + struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
> + kvm_pte_t *childp = kvm_pte_follow(ctx->old, mm_ops);
> + struct kvm_s2_mmu *mmu = ctx->arg;
> +
> + if (!kvm_pte_valid(ctx->old) || ctx->level != KVM_PGTABLE_MIN_BLOCK_LEVEL)
> + return 0;
> +
> + if (!stage2_try_break_pte(ctx, mmu))
> + return -EAGAIN;
> +
> + /*
> + * Gain back a reference for stage2_unmap_walker() to free
> + * this table entry from KVM_PGTABLE_MIN_BLOCK_LEVEL - 1.
> + */
> + mm_ops->get_page(ctx->ptep);
Doesn't this run the risk of a potential UAF if the refcount was 1 before
calling stage2_try_break_pte()? IOW, stage2_try_break_pte() will drop
the refcount to 0 on the page before this ever gets called.
Also, AFAICT this misses the CMOs that are required on systems w/o
FEAT_FWB. Without them it is possible that the host will read something
other than what was most recently written by the guest if it is using
noncacheable memory attributes at stage-1.
I imagine the actual bottleneck is the DSB required after every
CMO/TLBI. Theoretically, the unmap path could be updated to:
- Perform the appropriate CMOs for every valid leaf entry *without*
issuing a DSB.
- Elide TLBIs entirely that take place in the middle of the walk
- After the walk completes, dsb(ish) to guarantee that the CMOs have
completed and the invalid PTEs are made visible to the hardware
walkers. This should be done implicitly by the TLBI implementation
- Invalidate the [addr, addr + size) range of IPAs
This would also avoid over-invalidating stage-1 since we blast the
entire stage-1 context for every stage-2 invalidation. Thoughts?
> + mm_ops->free_removed_table(childp, ctx->level);
> + return 0;
> +}
> +
--
Thanks,
Oliver
_______________________________________________
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 6/7] KVM: arm64: Break the table entries using TLBI range instructions
From: Oliver Upton @ 2023-03-30 0:17 UTC (permalink / raw)
To: Raghavendra Rao Ananta
Cc: Oliver Upton, Marc Zyngier, Ricardo Koller, Reiji Watanabe,
James Morse, Alexandru Elisei, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Catalin Marinas, Jing Zhang, Colton Lewis,
linux-arm-kernel, kvmarm, linux-kernel, kvm
In-Reply-To: <20230206172340.2639971-7-rananta@google.com>
nit: s/break/invalidate/g
There is a rather important degree of nuance there. 'Break' as it
relates to break-before-make implies that the PTE is made invalid and
visible to hardware _before_ a subsequent invalidation. There will be
systems that relax this requirement and also support TLBIRANGE.
On Mon, Feb 06, 2023 at 05:23:39PM +0000, Raghavendra Rao Ananta wrote:
Some nitpicking on the changelog:
> Currently, when breaking up the stage-2 table entries, KVM
'breaking up stage-2 table entries' is rather ambiguous. Instead
describe the operation taking place on the page tables (i.e. hugepage
collapse).
> would flush the entire VM's context using 'vmalls12e1is'
> TLBI operation. One of the problematic situation is collapsing
> table entries into a hugepage, specifically if the VM is
> faulting on many hugepages (say after dirty-logging). This
> creates a performance penality for the guest whose pages have
typo: penalty
> already been faulted earlier as they would have to refill their
> TLBs again.
>
> Hence, if the system supports it, use __kvm_tlb_flush_range_vmid_ipa()
> to flush only the range of pages governed by the table entry,
> while leaving other TLB entries alone. An upcoming patch also
> takes advantage of this when breaking up table entries during
> the unmap operation.
Language regarding an upcoming patch isn't necessary, as this one stands
on its own (implements and uses a range-based invalidation helper).
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> ---
> arch/arm64/kvm/hyp/pgtable.c | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index b11cf2c618a6c..0858d1fa85d6b 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -686,6 +686,20 @@ static bool stage2_try_set_pte(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_
> return cmpxchg(ctx->ptep, ctx->old, new) == ctx->old;
> }
>
> +static void kvm_pgtable_stage2_flush_range(struct kvm_s2_mmu *mmu, u64 start, u64 end,
> + u32 level, u32 tlb_level)
> +{
> + if (system_supports_tlb_range())
You also check this in __kvm_tlb_flush_range(), ideally this should be
done exactly once per call.
> + kvm_call_hyp(__kvm_tlb_flush_range_vmid_ipa, mmu, start, end, level, tlb_level);
> + else
> + /*
> + * Invalidate the whole stage-2, as we may have numerous leaf
> + * entries below us which would otherwise need invalidating
> + * individually.
> + */
> + kvm_call_hyp(__kvm_tlb_flush_vmid, mmu);
> +}
> +
> /**
> * stage2_try_break_pte() - Invalidates a pte according to the
> * 'break-before-make' requirements of the
> @@ -721,10 +735,13 @@ static bool stage2_try_break_pte(const struct kvm_pgtable_visit_ctx *ctx,
> * Perform the appropriate TLB invalidation based on the evicted pte
> * value (if any).
> */
> - if (kvm_pte_table(ctx->old, ctx->level))
> - kvm_call_hyp(__kvm_tlb_flush_vmid, mmu);
> - else if (kvm_pte_valid(ctx->old))
> + if (kvm_pte_table(ctx->old, ctx->level)) {
> + u64 end = ctx->addr + kvm_granule_size(ctx->level);
> +
> + kvm_pgtable_stage2_flush_range(mmu, ctx->addr, end, ctx->level, 0);
> + } else if (kvm_pte_valid(ctx->old)) {
> kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu, ctx->addr, ctx->level);
> + }
>
> if (stage2_pte_is_counted(ctx->old))
> mm_ops->put_page(ctx->ptep);
> --
> 2.39.1.519.gcb327c4b5f-goog
>
>
--
Thanks,
Oliver
_______________________________________________
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 -next] spi: rockchip-sfc: Use devm_platform_get_and_ioremap_resource()
From: Mark Brown @ 2023-03-30 0:15 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Yang.Lee, heiko, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <e01a753e-aea2-5489-e436-2ec0f3fedb64@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 584 bytes --]
On Wed, Mar 29, 2023 at 08:18:27AM +0100, Tudor Ambarus wrote:
> On 3/29/23 07:06, Yang.Lee wrote:
> > Because the maintainer list of each SPI driver file is not identical, I am worried about causing trouble for too many people, so I split it into multiple patches based on this.
> The change is trivial enough to don't bother at all. Here's an example:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4b23603a251d24022f2fa48ee67610eb245a4115
No, it's fine - it doesn't really get in the way and can be
helpful to people doing backports.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/17] Improve the MT8365 SoC and EVK board support
From: Kevin Hilman @ 2023-03-30 0:09 UTC (permalink / raw)
To: Alexandre Mergnat, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Matthias Brugger, AngeloGioacchino Del Regno,
Chaotian Jing, Ulf Hansson, Wenbin Mei, Linus Walleij,
Zhiyong Tao, Bernhard Rosenkränzer
Cc: linux-watchdog, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-mmc, linux-gpio, Alexandre Bailon,
Fabien Parent, Amjad Ouled-Ameur, Alexandre Mergnat,
Krzysztof Kozlowski
In-Reply-To: <20230203-evk-board-support-v3-0-0003e80e0095@baylibre.com>
Alexandre Mergnat <amergnat@baylibre.com> writes:
> This commits are based on the Fabien Parent <fparent@baylibre.com> work.
>
> The purpose of this series is to add the following HWs / IPs support for
> the mt8365-evk board:
> - Watchdog
> - Power Management Integrated Circuit "PMIC" wrapper
> - MT6357 PMIC
> - MultiMediaCard "MMC" & Secure Digital "SD" controller
> - USB controller
> - Ethernet MAC controller
>
> Add CPU Freq & IDLE support for this board.
>
> This series depends to another one which add support for MT8365 SoC and
> EVK board [1].
It seems to depend on more than that series. In order to test this, I
tried applying this series on top of Bero's minimal support (now in
linux-next), and it does not apply cleanly.
Could you please list all the dependencies that are not yet upstream.
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v14 1/4] asm-generic,arm64: create task variant of access_ok
From: Oleg Nesterov @ 2023-03-29 23:54 UTC (permalink / raw)
To: Gregory Price
Cc: Arnd Bergmann, Gregory Price, linux-kernel, linux-doc,
linux-arm-kernel, Linux-Arch, avagin, Peter Zijlstra,
Andy Lutomirski, krisman, Thomas Gleixner, Jonathan Corbet, shuah,
Catalin Marinas, Will Deacon, Mark Rutland, tongtiangen,
Robin Murphy
In-Reply-To: <ZCQMsWNfkMJ0xHSy@memverge.com>
On 03/29, Gregory Price wrote:
>
> Last note on this before I push up another patch set.
>
> The change from __get_user to get_user also introduces a call to
> might_fault() which adds a larger callstack for every syscall /
> dispatch. This turns into a might_sleep and might_reschedule, which
> represent a very different pattern of execution from before.
might_fault() is nop unless CONFIG_PROVE_LOCKING || DEBUG_ATOMIC_SLEEP.
Again, I won't really argue with task_access_ok(). Just I am not sure
2/4 gives enough justification for this new helper with unclear semantics
(until we ensure that access_ok() doesn't depend on current).
Oleg.
_______________________________________________
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] iommu/rockchip: Add missing set_platform_dma_ops callback
From: Jason Gunthorpe @ 2023-03-29 23:42 UTC (permalink / raw)
To: Steven Price
Cc: Heiko Stuebner, Joerg Roedel, Will Deacon, Robin Murphy, iommu,
linux-arm-kernel, linux-kernel, linux-rockchip
In-Reply-To: <20230324111127.221640-1-steven.price@arm.com>
On Fri, Mar 24, 2023 at 11:11:27AM +0000, Steven Price wrote:
> Similar to exynos, we need a set_platform_dma_ops() callback for proper
> operation on ARM 32 bit after recent changes in the IOMMU framework
> (detach ops removal). But also the use of a NULL domain is confusing.
>
> Rework the code to have a singleton rk_identity_domain which is assigned
> to domain when using an identity mapping rather than "detaching". This
> makes the code easier to reason about.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v1[1]:
>
> * Reworked the code to avoid a NULL domain, instead a singleton
> rk_identity_domain is used instead. The 'detach' language is no
> longer used.
>
> [1] https://lore.kernel.org/r/20230315164152.333251-1-steven.price%40arm.com
>
> drivers/iommu/rockchip-iommu.c | 50 ++++++++++++++++++++++++++--------
> 1 file changed, 39 insertions(+), 11 deletions(-)
Aside from the pm stuff this looks OK to me
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] perf: No samples found when using kcore + coresight
From: Yang Shi @ 2023-03-29 23:25 UTC (permalink / raw)
To: James Clark
Cc: Leo Yan, linux-perf-users, LAK, coresight,
Linux Kernel Mailing List, mathieu.poirier, adrian.hunter,
Jiri Olsa, acme, mike.leach, Will Deacon, suzuki.poulose, yang
In-Reply-To: <64db6d95-8aca-48cc-80e1-e68211922071@arm.com>
On Wed, Mar 29, 2023 at 9:08 AM James Clark <james.clark@arm.com> wrote:
>
>
>
> On 14/03/2023 00:36, Leo Yan wrote:
> > On Mon, Mar 13, 2023 at 11:15:44AM -0700, Yang Shi wrote:
> >
> > [...]
> >
> >>> Just a quick summary, here we have two issues:
> >>>
> >>> - With command:
> >>> perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \
> >>> -- taskset --cpu-list 1 uname",
> >>>
> >>> perf doesn't enable "text poke" attribution.
> >>
> >> No, it enables "text poke" and perf fails to decode coresight trace
> >> data too. It doesn't matter whether "--kcore" is after or before "-e
> >> cs/etm/@tmc_etf63/k".
> >
> > Understand now. Thanks for correction, if so we can ignore this one.
> >
> > Leo
>
> To me it looks like it's only --per-thread and --kcore together that
> cause the issue. I can't see if that was mentioned previously in this
> thread.
If "--pre-thread" is not passed in, perf record failed with "failed to
mmap with 12 (Cannot allocate memory)". Sorry for not mentioning this
in the first place. I was quite focused on --kcore and didn't realize
they may be related.
>
> If it is --per-thread that's causing the issue then I think I have an
> idea why it might be. There are some assumptions and different paths
> taken in decoding in that mode that aren't correct. It causes some other
> issues to do with ordering and timestamps as well and I wanted to fix it
> previously. I wouldn't say that the text-poke change has caused a
> regression, as decoding in this mode was always a bit buggy.
>
> Maybe this is another reason to fix it properly.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND] wifi: mt76: mt7921e: Set memory space enable in PCI_COMMAND if unset
From: Sean Wang @ 2023-03-29 23:24 UTC (permalink / raw)
To: Mario Limonciello
Cc: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, Matthias Brugger,
Anson Tsao, Kalle Valo, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20230329195758.7384-1-mario.limonciello@amd.com>
Hi,
On Wed, Mar 29, 2023 at 1:18 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> When the BIOS has been configured for Fast Boot, systems with mt7921e
> have non-functional wifi. Turning on Fast boot caused both bus master
> enable and memory space enable bits in PCI_COMMAND not to get configured.
>
> The mt7921 driver already sets bus master enable, but explicitly check
> and set memory access enable as well to fix this problem.
>
> Tested-by: Anson Tsao <anson.tsao@amd.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> Original patch was submitted ~3 weeks ago with no comments.
> Link: https://lore.kernel.org/all/20230310170002.200-1-mario.limonciello@amd.com/
> ---
> drivers/net/wireless/mediatek/mt76/mt7921/pci.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> index cb72ded37256..aa1a427b16c2 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> @@ -263,6 +263,7 @@ static int mt7921_pci_probe(struct pci_dev *pdev,
> struct mt76_dev *mdev;
> u8 features;
> int ret;
> + u16 cmd;
>
> ret = pcim_enable_device(pdev);
> if (ret)
> @@ -272,6 +273,11 @@ static int mt7921_pci_probe(struct pci_dev *pdev,
> if (ret)
> return ret;
>
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if (!(cmd & PCI_COMMAND_MEMORY)) {
> + cmd |= PCI_COMMAND_MEMORY;
> + pci_write_config_word(pdev, PCI_COMMAND, cmd);
> + }
If PCI_COMMAND_MEMORY is required in any circumstance, then we don't
need to add a conditional check and OR it with PCI_COMMAND_MEMORY.
Also, I will try the patch on another Intel machine to see if it worked.
Sean
> pci_set_master(pdev);
>
> ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> --
> 2.34.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 5/6] soc: mediatek: mtk-pmic-wrap: Add support for MT6331 w/ MT6332 companion
From: Alexandre Mergnat @ 2023-03-29 23:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, flora.fu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel, phone-devel, ~postmarketos/upstreaming
In-Reply-To: <20230324094205.33266-6-angelogioacchino.delregno@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Regards,
Alexandre
Le ven. 24 mars 2023 à 10:42, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> a écrit :
>
> Add support for the MT6331 PMIC and for its companion MT6332 PMIC.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 47 ++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 366e40b802e4..ceeac43f7bd1 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -170,6 +170,40 @@ static const u32 mt6323_regs[] = {
> [PWRAP_DEW_RDDMY_NO] = 0x01a4,
> };
>
> +static const u32 mt6331_regs[] = {
> + [PWRAP_DEW_DIO_EN] = 0x018c,
> + [PWRAP_DEW_READ_TEST] = 0x018e,
> + [PWRAP_DEW_WRITE_TEST] = 0x0190,
> + [PWRAP_DEW_CRC_SWRST] = 0x0192,
> + [PWRAP_DEW_CRC_EN] = 0x0194,
> + [PWRAP_DEW_CRC_VAL] = 0x0196,
> + [PWRAP_DEW_MON_GRP_SEL] = 0x0198,
> + [PWRAP_DEW_CIPHER_KEY_SEL] = 0x019a,
> + [PWRAP_DEW_CIPHER_IV_SEL] = 0x019c,
> + [PWRAP_DEW_CIPHER_EN] = 0x019e,
> + [PWRAP_DEW_CIPHER_RDY] = 0x01a0,
> + [PWRAP_DEW_CIPHER_MODE] = 0x01a2,
> + [PWRAP_DEW_CIPHER_SWRST] = 0x01a4,
> + [PWRAP_DEW_RDDMY_NO] = 0x01a6,
> +};
> +
> +static const u32 mt6332_regs[] = {
> + [PWRAP_DEW_DIO_EN] = 0x80f6,
> + [PWRAP_DEW_READ_TEST] = 0x80f8,
> + [PWRAP_DEW_WRITE_TEST] = 0x80fa,
> + [PWRAP_DEW_CRC_SWRST] = 0x80fc,
> + [PWRAP_DEW_CRC_EN] = 0x80fe,
> + [PWRAP_DEW_CRC_VAL] = 0x8100,
> + [PWRAP_DEW_MON_GRP_SEL] = 0x8102,
> + [PWRAP_DEW_CIPHER_KEY_SEL] = 0x8104,
> + [PWRAP_DEW_CIPHER_IV_SEL] = 0x8106,
> + [PWRAP_DEW_CIPHER_EN] = 0x8108,
> + [PWRAP_DEW_CIPHER_RDY] = 0x810a,
> + [PWRAP_DEW_CIPHER_MODE] = 0x810c,
> + [PWRAP_DEW_CIPHER_SWRST] = 0x810e,
> + [PWRAP_DEW_RDDMY_NO] = 0x8110,
> +};
> +
> static const u32 mt6351_regs[] = {
> [PWRAP_DEW_DIO_EN] = 0x02F2,
> [PWRAP_DEW_READ_TEST] = 0x02F4,
> @@ -1182,6 +1216,8 @@ static int mt8186_regs[] = {
>
> enum pmic_type {
> PMIC_MT6323,
> + PMIC_MT6331,
> + PMIC_MT6332,
> PMIC_MT6351,
> PMIC_MT6357,
> PMIC_MT6358,
> @@ -2041,6 +2077,16 @@ static const struct pwrap_slv_type pmic_mt6323 = {
> PWRAP_SLV_CAP_SECURITY,
> };
>
> +static const struct pwrap_slv_type pmic_mt6331 = {
> + .dew_regs = mt6331_regs,
> + .type = PMIC_MT6331,
> + .comp_dew_regs = mt6332_regs,
> + .comp_type = PMIC_MT6332,
> + .regops = &pwrap_regops16,
> + .caps = PWRAP_SLV_CAP_SPI | PWRAP_SLV_CAP_DUALIO |
> + PWRAP_SLV_CAP_SECURITY,
> +};
> +
> static const struct pwrap_slv_type pmic_mt6351 = {
> .dew_regs = mt6351_regs,
> .type = PMIC_MT6351,
> @@ -2086,6 +2132,7 @@ static const struct pwrap_slv_type pmic_mt6397 = {
>
> static const struct of_device_id of_slave_match_tbl[] = {
> { .compatible = "mediatek,mt6323", .data = &pmic_mt6323 },
> + { .compatible = "mediatek,mt6331", .data = &pmic_mt6331 },
> { .compatible = "mediatek,mt6351", .data = &pmic_mt6351 },
> { .compatible = "mediatek,mt6357", .data = &pmic_mt6357 },
> { .compatible = "mediatek,mt6358", .data = &pmic_mt6358 },
> --
> 2.40.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] soc: mediatek: pwrap: Add support for MT6795 Helio X10
From: Alexandre Mergnat @ 2023-03-29 23:07 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, flora.fu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel, phone-devel, ~postmarketos/upstreaming
In-Reply-To: <20230324094205.33266-7-angelogioacchino.delregno@collabora.com>
" or
Le ven. 24 mars 2023 à 10:42, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> a écrit :
>
> Add the necessary bits to support the MT6795 Helio X10 smartphone SoC:
> this is always paired with a MT6331 PMIC, with MT6332 companion.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 131 ++++++++++++++++++++++++++-
> 1 file changed, 130 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index ceeac43f7bd1..20d32328382a 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -639,6 +639,91 @@ static int mt6779_regs[] = {
> [PWRAP_WACS2_VLDCLR] = 0xC28,
> };
>
> +static int mt6795_regs[] = {
> + [PWRAP_MUX_SEL] = 0x0,
> + [PWRAP_WRAP_EN] = 0x4,
> + [PWRAP_DIO_EN] = 0x8,
> + [PWRAP_SIDLY] = 0xc,
> + [PWRAP_RDDMY] = 0x10,
> + [PWRAP_SI_CK_CON] = 0x14,
> + [PWRAP_CSHEXT_WRITE] = 0x18,
> + [PWRAP_CSHEXT_READ] = 0x1c,
> + [PWRAP_CSLEXT_START] = 0x20,
> + [PWRAP_CSLEXT_END] = 0x24,
> + [PWRAP_STAUPD_PRD] = 0x28,
> + [PWRAP_STAUPD_GRPEN] = 0x2c,
> + [PWRAP_EINT_STA0_ADR] = 0x30,
> + [PWRAP_EINT_STA1_ADR] = 0x34,
> + [PWRAP_STAUPD_MAN_TRIG] = 0x40,
> + [PWRAP_STAUPD_STA] = 0x44,
> + [PWRAP_WRAP_STA] = 0x48,
> + [PWRAP_HARB_INIT] = 0x4c,
> + [PWRAP_HARB_HPRIO] = 0x50,
> + [PWRAP_HIPRIO_ARB_EN] = 0x54,
> + [PWRAP_HARB_STA0] = 0x58,
> + [PWRAP_HARB_STA1] = 0x5c,
> + [PWRAP_MAN_EN] = 0x60,
> + [PWRAP_MAN_CMD] = 0x64,
> + [PWRAP_MAN_RDATA] = 0x68,
> + [PWRAP_MAN_VLDCLR] = 0x6c,
> + [PWRAP_WACS0_EN] = 0x70,
> + [PWRAP_INIT_DONE0] = 0x74,
> + [PWRAP_WACS0_CMD] = 0x78,
> + [PWRAP_WACS0_RDATA] = 0x7c,
> + [PWRAP_WACS0_VLDCLR] = 0x80,
> + [PWRAP_WACS1_EN] = 0x84,
> + [PWRAP_INIT_DONE1] = 0x88,
> + [PWRAP_WACS1_CMD] = 0x8c,
> + [PWRAP_WACS1_RDATA] = 0x90,
> + [PWRAP_WACS1_VLDCLR] = 0x94,
> + [PWRAP_WACS2_EN] = 0x98,
> + [PWRAP_INIT_DONE2] = 0x9c,
> + [PWRAP_WACS2_CMD] = 0xa0,
> + [PWRAP_WACS2_RDATA] = 0xa4,
> + [PWRAP_WACS2_VLDCLR] = 0xa8,
> + [PWRAP_INT_EN] = 0xac,
> + [PWRAP_INT_FLG_RAW] = 0xb0,
> + [PWRAP_INT_FLG] = 0xb4,
> + [PWRAP_INT_CLR] = 0xb8,
> + [PWRAP_SIG_ADR] = 0xbc,
> + [PWRAP_SIG_MODE] = 0xc0,
> + [PWRAP_SIG_VALUE] = 0xc4,
> + [PWRAP_SIG_ERRVAL] = 0xc8,
> + [PWRAP_CRC_EN] = 0xcc,
> + [PWRAP_TIMER_EN] = 0xd0,
> + [PWRAP_TIMER_STA] = 0xd4,
> + [PWRAP_WDT_UNIT] = 0xd8,
> + [PWRAP_WDT_SRC_EN] = 0xdc,
> + [PWRAP_WDT_FLG] = 0xe0,
> + [PWRAP_DEBUG_INT_SEL] = 0xe4,
> + [PWRAP_DVFS_ADR0] = 0xe8,
> + [PWRAP_DVFS_WDATA0] = 0xec,
> + [PWRAP_DVFS_ADR1] = 0xf0,
> + [PWRAP_DVFS_WDATA1] = 0xf4,
> + [PWRAP_DVFS_ADR2] = 0xf8,
> + [PWRAP_DVFS_WDATA2] = 0xfc,
> + [PWRAP_DVFS_ADR3] = 0x100,
> + [PWRAP_DVFS_WDATA3] = 0x104,
> + [PWRAP_DVFS_ADR4] = 0x108,
> + [PWRAP_DVFS_WDATA4] = 0x10c,
> + [PWRAP_DVFS_ADR5] = 0x110,
> + [PWRAP_DVFS_WDATA5] = 0x114,
> + [PWRAP_DVFS_ADR6] = 0x118,
> + [PWRAP_DVFS_WDATA6] = 0x11c,
> + [PWRAP_DVFS_ADR7] = 0x120,
> + [PWRAP_DVFS_WDATA7] = 0x124,
> + [PWRAP_SPMINF_STA] = 0x128,
> + [PWRAP_CIPHER_KEY_SEL] = 0x12c,
> + [PWRAP_CIPHER_IV_SEL] = 0x130,
> + [PWRAP_CIPHER_EN] = 0x134,
> + [PWRAP_CIPHER_RDY] = 0x138,
> + [PWRAP_CIPHER_MODE] = 0x13c,
> + [PWRAP_CIPHER_SWRST] = 0x140,
> + [PWRAP_DCM_EN] = 0x144,
> + [PWRAP_DCM_DBC_PRD] = 0x148,
> + [PWRAP_EXT_CK] = 0x14c,
> +};
> +
> static int mt6797_regs[] = {
> [PWRAP_MUX_SEL] = 0x0,
> [PWRAP_WRAP_EN] = 0x4,
> @@ -1230,6 +1315,7 @@ enum pwrap_type {
> PWRAP_MT2701,
> PWRAP_MT6765,
> PWRAP_MT6779,
> + PWRAP_MT6795,
> PWRAP_MT6797,
> PWRAP_MT6873,
> PWRAP_MT7622,
> @@ -1650,6 +1736,20 @@ static void pwrap_init_chip_select_ext(struct pmic_wrapper *wrp, u8 hext_write,
> static int pwrap_common_init_reg_clock(struct pmic_wrapper *wrp)
> {
> switch (wrp->master->type) {
> + case PWRAP_MT6795:
> + if (wrp->slave->type == PMIC_MT6331) {
> + const u32 *dew_regs = wrp->slave->dew_regs;
> +
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_RDDMY_NO], 0x8);
> +
> + if (wrp->slave->comp_type == PMIC_MT6332) {
> + dew_regs = wrp->slave->comp_dew_regs;
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_RDDMY_NO], 0x8);
> + }
> + }
> + pwrap_writel(wrp, 0x88, PWRAP_RDDMY);
> + pwrap_init_chip_select_ext(wrp, 15, 15, 15, 15);
> + break;
> case PWRAP_MT8173:
> pwrap_init_chip_select_ext(wrp, 0, 4, 2, 2);
> break;
> @@ -1744,6 +1844,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> case PWRAP_MT2701:
> case PWRAP_MT6765:
> case PWRAP_MT6779:
> + case PWRAP_MT6795:
> case PWRAP_MT6797:
> case PWRAP_MT8173:
> case PWRAP_MT8186:
> @@ -1914,6 +2015,19 @@ static int pwrap_mt2701_init_soc_specific(struct pmic_wrapper *wrp)
> return 0;
> }
>
> +static int pwrap_mt6795_init_soc_specific(struct pmic_wrapper *wrp)
> +{
> + pwrap_writel(wrp, 0xf, PWRAP_STAUPD_GRPEN);
> +
> + if (wrp->slave->type == PMIC_MT6331)
> + pwrap_writel(wrp, 0x1b4, PWRAP_EINT_STA0_ADR);
> +
> + if (wrp->slave->comp_type == PMIC_MT6332)
> + pwrap_writel(wrp, 0x8112, PWRAP_EINT_STA1_ADR);
> +
> + return 0;
> +}
> +
> static int pwrap_mt7622_init_soc_specific(struct pmic_wrapper *wrp)
> {
> pwrap_writel(wrp, 0, PWRAP_STAUPD_PRD);
> @@ -1949,7 +2063,8 @@ static int pwrap_init(struct pmic_wrapper *wrp)
> if (wrp->rstc_bridge)
> reset_control_reset(wrp->rstc_bridge);
>
> - if (wrp->master->type == PWRAP_MT8173) {
> + if (wrp->master->type == PWRAP_MT8173 ||
> + wrp->master->type == PWRAP_MT6795) {
I would prefer to put a switch case like it's done in
"pwrap_common_init_reg_clock" or
"pwrap_init_cipher".
My second choice (which isn't aligned with the current
implementation), is to add boolean
capabilities in the "struct pmic_wrapper_type".
> /* Enable DCM */
> pwrap_writel(wrp, 3, PWRAP_DCM_EN);
> pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD);
> @@ -2185,6 +2300,19 @@ static const struct pmic_wrapper_type pwrap_mt6779 = {
> .init_soc_specific = NULL,
> };
>
> +static const struct pmic_wrapper_type pwrap_mt6795 = {
> + .regs = mt6795_regs,
> + .type = PWRAP_MT6795,
> + .arb_en_all = 0x3f,
> + .int_en_all = ~(u32)(BIT(31) | BIT(2) | BIT(1)),
> + .int1_en_all = 0,
> + .spi_w = PWRAP_MAN_CMD_SPI_WRITE,
> + .wdt_src = PWRAP_WDT_SRC_MASK_NO_STAUPD,
> + .caps = PWRAP_CAP_RESET | PWRAP_CAP_DCM,
> + .init_reg_clock = pwrap_common_init_reg_clock,
> + .init_soc_specific = pwrap_mt6795_init_soc_specific,
TBH, I don't know if variables should be reordered in alphabetic order
or keep the order of other structures.
it's just to notify.
> +};
> +
> static const struct pmic_wrapper_type pwrap_mt6797 = {
> .regs = mt6797_regs,
> .type = PWRAP_MT6797,
> @@ -2318,6 +2446,7 @@ static const struct of_device_id of_pwrap_match_tbl[] = {
> { .compatible = "mediatek,mt2701-pwrap", .data = &pwrap_mt2701 },
> { .compatible = "mediatek,mt6765-pwrap", .data = &pwrap_mt6765 },
> { .compatible = "mediatek,mt6779-pwrap", .data = &pwrap_mt6779 },
> + { .compatible = "mediatek,mt6795-pwrap", .data = &pwrap_mt6795 },
> { .compatible = "mediatek,mt6797-pwrap", .data = &pwrap_mt6797 },
> { .compatible = "mediatek,mt6873-pwrap", .data = &pwrap_mt6873 },
> { .compatible = "mediatek,mt7622-pwrap", .data = &pwrap_mt7622 },
> --
> 2.40.0
>
Regards,
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] mailbox: apple: Move driver into soc/apple and stop using the subsystem
From: Hector Martin @ 2023-03-29 22:53 UTC (permalink / raw)
To: Jassi Brar
Cc: Sven Peter, Alyssa Rosenzweig, Janne Grunau, linux-kernel, asahi,
linux-arm-kernel
In-Reply-To: <CABb+yY2=B2p5JhZiBE_mZLe3y16EUgVsUHK62LnRgaKa1-ptLg@mail.gmail.com>
On 30/03/2023 01.04, Jassi Brar wrote:
> On Tue, Mar 28, 2023 at 8:14 AM Hector Martin <marcan@marcan.st> wrote:
>>
>> Once upon a time, Apple machines had some mailbox hardware, and we had
>> to write a driver for it. And since it was a mailbox, it felt natural to
>> use the Linux mailbox subsystem.
>>
>> More than a year later, it has become evident that was not the right
>> decision.
>>
>> Linux driver class subsystems generally exist for a few purposes:
>> 1. To allow mixing and matching generic producers and consumers.
>> 2. To implement common code that is likely to be shared across drivers,
>> and do so correctly so correct code only has to be written once.
>> 3. To force drivers into a "correct" design, such that driver authors
>> avoid common pitfalls.
>>
> The Mailbox subsystem is meant to serve (2) and possibly (3).
> We never aimed for (1), we can't... because the firmware on the remote
> end is also a part of "local hardware" -- keeping every bit of
> hardware the same, if just the f/w changes you may have to change the
> linux side driver.
Right, I'm just explaining why this isn't like i2c/spi and similar
subsystems. The value proposition is significantly weaker with mailbox
for this reason.
>> 2. The mailbox subsystem implements a bunch of common code for queuing,
>> but we don't need that because our hardware has hardware queues. It
>> also implements a bunch of common code for supporting multiple
>> channels, but we don't need that because our hardware only has one
>> channel (it has "endpoints" but those are just tags that are part of
>> the message).
>>
> In note-1, you complain it is not standard/flexible enough, and here
> its support for features, that you don't need, become a problem?
It has features we don't need that introduce bugs and complexity, while
missing features we *do* need. So yes, it's doubly a problem.
>> On top of this, the mailbox subsystem makes design
>> decisions unsuitable for our use case. Its queuing implementation
>> has a fixed queue size and fails sends when full instead of pushing
>> back by blocking, which is completely unsuitable for high-traffic
>> mailboxes with hard reliability requirements, such as ours. We've
>> also run into multiple issues around using mailbox in an atomic
>> context (required for SMC reboot/shutdown requests).
>>
> I don't think you ever shared the issues you were struggling with.
I did try to send a patch clarifying/cleaning up inconsistent usage of
the atomic codepath in other drivers, and you rejected it. At that point
I gave up in trying to contribute to cleaning up the existing mess,
because you're clearly not interested. I have some downstream fixes for
the atomic codepath and I don't think they even fix all the problems,
because we still run into issues. The design of the mailbox core is just
bizarre and makes it very hard to reason about the corner cases through
the whole queuing business.
It's a big chunk of complexity and bug-prone design and it just doesn't
make any sense for us to spend time on this if cleaning things up is
going to be an uphill battle *and* in the end the subsystem still does
nothing useful for us. It's just using the subsystem for the sake of
using it at that point. It makes no sense.
As for the other issue, there's a giant comment around the queue length
define:
> /*
> * The length of circular buffer for queuing messages from a client.
> * 'msg_count' tracks the number of buffered messages while 'msg_free'
> * is the index where the next message would be buffered.
> * We shouldn't need it too big because every transfer is interrupt
> * triggered and if we have lots of data to transfer, the interrupt
> * latencies are going to be the bottleneck, not the buffer length.
> * Besides, mbox_send_message could be called from atomic context and
> * the client could also queue another message from the notifier 'tx_done'
> * of the last transfer done.
> * REVISIT: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
> * print, it needs to be taken from config option or somesuch.
> */
> #define MBOX_TX_QUEUE_LEN 20
This issue is clearly known, and it doesn't take a lot of thinking to
realize that *any* queue length limit coupled with hard-fails on message
sends instead of pushback is just unsuitable for many use cases. Maybe
all existing mailbox users have intrinsically synchronous use cases that
keep the queue idle enough, or maybe they're just broken only in corner
cases that haven't come back to the mailbox subsystem yet. Either way,
as far as I'm concerned this is broken by design in the general case.
> Not to mean there can be no limitation but I knew a platform that ran
> a virtual block-device and custom filesystem over the mailbox, and it
> was good for a camera product that needs high bandwidth image
> transfer.
I guess it worked for them, but it's been breaking our GPU use case. So
if it's working for other people, I guess that's fine. But it's
definitely not working for us, and I'm not inclined to try to fix the
issues if nobody else has a problem.
Working on common code has the inherent risk that any changes can break
other users and I have no way to test every other mailbox user. There
are real *costs* associated with having common code, especially for
boutique things like mailbox which are highly heterogeneous and used on
all kinds of weird systems no single developer can hope to have access to.
So if you say it's working well for other people, all the more reason
for us to move away and leave them alone instead of trying to make major
changes to fix everything that isn't working for us and risk breaking
others.
>> Jassi: Ideally I'd like to get an ack on this and merge it all through
>> asahi-soc, so we don't have to play things patch-by-patch across
>> multiple merge cycles to avoid potentially broken intermediate states.
>>
> Instead of every platform implementing their own message queuing and
> handling mechanism and parsing producer-comsumer links from the DT,
> there is a reusable code in drivers/mailbox.
As I said, we don't need nor want message queuing (yes, this is the bulk
of the complexity of the subsystem and really the source of a lot of the
pain, especially once you start throwing atomic into the mix). Other
mailbox hardware might, and that's fine. It's just not for us.
Especially not if it falls over when the queue gets full like it does.
I'm not saying the mailbox subsystem shouldn't exist, I'm saying it
might be a good idea as it stands for *some* mailbox
producers/consumers/use cases, but not *all*, and in this case, not ours.
As for the DT links, that's ~25 lines of code.
> And there is a reason the reduction in code with this patchset is
> meager -- you anyway have to implement your platform specific stuff.
Think about it for a second. We are ceasing use of the subsystem, which
under any reasonable expectation would require us to *add* code to
duplicate functionality. Indeed there's one new small function to deal
with the OF phandle lookup. And there's also a whole new header file
with prototypes that are a facsimile of the core mailbox API too. But
overall the total LOC is down, because we more than make that up by
removing overhead caused by having to bend to the wills of the subsystem
and work around its issues (and we'd be removing even more if the
upstream driver already had the new features like runtime-PM and
workarounds for more issues).
> But if redoing mailbox overall saves you complexity, I am ok with it.
Is that an ack? :-)
- Hector
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/6] soc: mediatek: mtk-pmic-wrap: Add support for companion PMICs
From: Alexandre Mergnat @ 2023-03-29 22:40 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, flora.fu,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel, phone-devel, ~postmarketos/upstreaming
In-Reply-To: <20230324094205.33266-5-angelogioacchino.delregno@collabora.com>
Le ven. 24 mars 2023 à 10:42, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> a écrit :
>
> Some PMICs are designed to work with a companion part, which provides
> more regulators and/or companion devices such as LED controllers,
> display backlight controllers, battery charging, fuel gauge, etc:
> this kind of PMICs are usually present in smartphone platforms, where
> tight integration is required.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 73 ++++++++++++++++++++++------
> 1 file changed, 59 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index a33a1b1820cb..366e40b802e4 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -47,6 +47,7 @@
>
> /* macro for device wrapper default value */
> #define PWRAP_DEW_READ_TEST_VAL 0x5aa5
> +#define PWRAP_DEW_COMP_READ_TEST_VAL 0xa55a
> #define PWRAP_DEW_WRITE_TEST_VAL 0xa55a
>
> /* macro for manual command */
> @@ -1222,12 +1223,16 @@ struct pwrap_slv_regops {
> * struct pwrap_slv_type - PMIC device wrapper definitions
> * @dew_regs: Device Wrapper (DeW) register offsets
> * @type: PMIC Type (model)
> + * @comp_dew_regs: Device Wrapper (DeW) register offsets for companion device
> + * @comp_type: Companion PMIC Type (model)
> * @regops: Register R/W ops
> * @caps: Capability flags for the target device
> */
> struct pwrap_slv_type {
> const u32 *dew_regs;
> enum pmic_type type;
> + const u32 *comp_dew_regs;
> + enum pmic_type comp_type;
> const struct pwrap_slv_regops *regops;
> u32 caps;
> };
> @@ -1548,9 +1553,12 @@ static int pwrap_init_dual_io(struct pmic_wrapper *wrp)
> {
> int ret;
> bool read_ok, tmp;
> + bool comp_read_ok = true;
>
> /* Enable dual IO mode */
> pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_DIO_EN], 1);
> + if (wrp->slave->comp_dew_regs)
> + pwrap_write(wrp, wrp->slave->comp_dew_regs[PWRAP_DEW_DIO_EN], 1);
>
> /* Check IDLE & INIT_DONE in advance */
> ret = readx_poll_timeout(pwrap_is_fsm_idle_and_sync_idle, wrp, tmp, tmp,
> @@ -1564,8 +1572,14 @@ static int pwrap_init_dual_io(struct pmic_wrapper *wrp)
>
> /* Read Test */
> read_ok = pwrap_pmic_read_test(wrp, wrp->slave->dew_regs, PWRAP_DEW_READ_TEST_VAL);
> - if (!read_ok) {
> - dev_err(wrp->dev, "Read failed on DIO mode.\n");
> + if (wrp->slave->comp_dew_regs)
> + comp_read_ok = pwrap_pmic_read_test(wrp, wrp->slave->comp_dew_regs,
> + PWRAP_DEW_COMP_READ_TEST_VAL);
> + if (!read_ok || !comp_read_ok) {
> + dev_err(wrp->dev, "Read failed on DIO mode. Main PMIC %s%s\n",
> + !read_ok ? "fail" : "success",
> + wrp->slave->comp_dew_regs && !comp_read_ok ?
> + ", Companion PMIC fail" : "");
> return -EFAULT;
> }
>
> @@ -1640,19 +1654,41 @@ static bool pwrap_is_cipher_ready(struct pmic_wrapper *wrp)
> return pwrap_readl(wrp, PWRAP_CIPHER_RDY) & 1;
> }
>
> -static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
> +static bool __pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp, const u32 *dew_regs)
> {
> u32 rdata;
> int ret;
>
> - ret = pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_RDY],
> - &rdata);
> + ret = pwrap_read(wrp, dew_regs[PWRAP_DEW_CIPHER_RDY], &rdata);
> if (ret)
> return false;
>
> return rdata == 1;
> }
>
> +
Remove this extra line please.
> +static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
> +{
> + bool ret = __pwrap_is_pmic_cipher_ready(wrp, wrp->slave->dew_regs);
> +
> + if (!ret)
> + return ret;
> +
> + /* If there's any companion, wait for it to be ready too */
> + if (wrp->slave->comp_dew_regs)
> + ret = __pwrap_is_pmic_cipher_ready(wrp, wrp->slave->comp_dew_regs);
> +
> + return ret;
> +}
> +
> +static void pwrap_config_cipher(struct pmic_wrapper *wrp, const u32 *dew_regs)
> +{
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x1);
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
> + pwrap_write(wrp, dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
> +}
> +
> static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> {
> int ret;
> @@ -1689,10 +1725,11 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
> }
>
> /* Config cipher mode @PMIC */
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x1);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
> - pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
> + pwrap_config_cipher(wrp, wrp->slave->dew_regs);
> +
> + /* If there is any companion PMIC, configure cipher mode there too */
> + if (wrp->slave->comp_type > 0)
> + pwrap_config_cipher(wrp, wrp->slave->comp_dew_regs);
>
> switch (wrp->slave->type) {
> case PMIC_MT6397:
> @@ -1754,6 +1791,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
>
> static int pwrap_init_security(struct pmic_wrapper *wrp)
> {
> + u32 crc_val;
> int ret;
>
> /* Enable encryption */
> @@ -1762,14 +1800,21 @@ static int pwrap_init_security(struct pmic_wrapper *wrp)
> return ret;
>
> /* Signature checking - using CRC */
> - if (pwrap_write(wrp,
> - wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1))
> - return -EFAULT;
> + ret = pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1);
> + if (ret == 0 && wrp->slave->comp_dew_regs)
> + ret = pwrap_write(wrp, wrp->slave->comp_dew_regs[PWRAP_DEW_CRC_EN], 0x1);
>
> pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
> pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
> - pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
> - PWRAP_SIG_ADR);
> +
> + /* CRC value */
> + crc_val = wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL];
> + if (wrp->slave->comp_dew_regs)
> + crc_val |= wrp->slave->comp_dew_regs[PWRAP_DEW_CRC_VAL] << 16;
IMHO, the number 16 should be replaced by a define even if I guess
it's a simple shift value.
> +
> + pwrap_writel(wrp, crc_val, PWRAP_SIG_ADR);
> +
> + /* PMIC Wrapper Arbiter priority */
> pwrap_writel(wrp,
> wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
>
> --
> 2.40.0
>
Sounds good to me.
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Regards,
Alex
_______________________________________________
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