* [PATCH 0/2] drm/meson: add resume/suspend hooks
From: Neil Armstrong @ 2019-08-27 9:58 UTC (permalink / raw)
To: dri-devel
Cc: khilman, Neil Armstrong, linux-kernel, linux-arm-kernel,
linux-amlogic
This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
and the DW-HDMI Glue driver to correctly save state and disable HW before
suspend, and succesfully re-init the HW to recover functionnal display
after resume.
This serie has been tested on Amlogic G12A based SEI510 board, using
the newly accepted VRTC driver and the rtcwake utility.
Neil Armstrong (2):
drm/meson: dw_hdmi: add resume/suspend hooks
drm/meson: add resume/suspend hooks
drivers/gpu/drm/meson/meson_drv.c | 32 ++++++++
drivers/gpu/drm/meson/meson_dw_hdmi.c | 110 ++++++++++++++++++--------
2 files changed, 108 insertions(+), 34 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] drm/meson: dw_hdmi: add resume/suspend hooks
From: Neil Armstrong @ 2019-08-27 9:58 UTC (permalink / raw)
To: dri-devel
Cc: khilman, Neil Armstrong, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20190827095825.21015-1-narmstrong@baylibre.com>
Add the suspens and resume hooks to:
- reset the whole HDMI glue and HDMI controller on suspend
- re-init the HDMI glue and HDMI controller on resume
The HDMI glue init is refactored to be re-used from the resume hook.
It makes usage of dw_hdmi_resume() to recover a functionnal DDC bus.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 110 ++++++++++++++++++--------
1 file changed, 76 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index df3f9ddd2234..a722ddbfbede 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -799,6 +799,47 @@ static bool meson_hdmi_connector_is_available(struct device *dev)
return false;
}
+static void meson_dw_hdmi_init(struct meson_dw_hdmi *meson_dw_hdmi)
+{
+ struct meson_drm *priv = meson_dw_hdmi->priv;
+
+ /* Enable clocks */
+ regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0xffff, 0x100);
+
+ /* Bring HDMITX MEM output of power down */
+ regmap_update_bits(priv->hhi, HHI_MEM_PD_REG0, 0xff << 8, 0);
+
+ /* Reset HDMITX APB & TX & PHY */
+ reset_control_reset(meson_dw_hdmi->hdmitx_apb);
+ reset_control_reset(meson_dw_hdmi->hdmitx_ctrl);
+ reset_control_reset(meson_dw_hdmi->hdmitx_phy);
+
+ /* Enable APB3 fail on error */
+ if (!meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ writel_bits_relaxed(BIT(15), BIT(15),
+ meson_dw_hdmi->hdmitx + HDMITX_TOP_CTRL_REG);
+ writel_bits_relaxed(BIT(15), BIT(15),
+ meson_dw_hdmi->hdmitx + HDMITX_DWC_CTRL_REG);
+ }
+
+ /* Bring out of reset */
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi,
+ HDMITX_TOP_SW_RESET, 0);
+
+ msleep(20);
+
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi,
+ HDMITX_TOP_CLK_CNTL, 0xff);
+
+ /* Enable HDMI-TX Interrupt */
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_INTR_STAT_CLR,
+ HDMITX_TOP_INTR_CORE);
+
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_INTR_MASKN,
+ HDMITX_TOP_INTR_CORE);
+
+}
+
static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -922,40 +963,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
DRM_DEBUG_DRIVER("encoder initialized\n");
- /* Enable clocks */
- regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0xffff, 0x100);
-
- /* Bring HDMITX MEM output of power down */
- regmap_update_bits(priv->hhi, HHI_MEM_PD_REG0, 0xff << 8, 0);
-
- /* Reset HDMITX APB & TX & PHY */
- reset_control_reset(meson_dw_hdmi->hdmitx_apb);
- reset_control_reset(meson_dw_hdmi->hdmitx_ctrl);
- reset_control_reset(meson_dw_hdmi->hdmitx_phy);
-
- /* Enable APB3 fail on error */
- if (!meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
- writel_bits_relaxed(BIT(15), BIT(15),
- meson_dw_hdmi->hdmitx + HDMITX_TOP_CTRL_REG);
- writel_bits_relaxed(BIT(15), BIT(15),
- meson_dw_hdmi->hdmitx + HDMITX_DWC_CTRL_REG);
- }
-
- /* Bring out of reset */
- meson_dw_hdmi->data->top_write(meson_dw_hdmi,
- HDMITX_TOP_SW_RESET, 0);
-
- msleep(20);
-
- meson_dw_hdmi->data->top_write(meson_dw_hdmi,
- HDMITX_TOP_CLK_CNTL, 0xff);
-
- /* Enable HDMI-TX Interrupt */
- meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_INTR_STAT_CLR,
- HDMITX_TOP_INTR_CORE);
-
- meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_INTR_MASKN,
- HDMITX_TOP_INTR_CORE);
+ meson_dw_hdmi_init(meson_dw_hdmi);
/* Bridge / Connector */
@@ -991,6 +999,34 @@ static const struct component_ops meson_dw_hdmi_ops = {
.unbind = meson_dw_hdmi_unbind,
};
+static int __maybe_unused meson_dw_hdmi_pm_suspend(struct device *dev)
+{
+ struct meson_dw_hdmi *meson_dw_hdmi = dev_get_drvdata(dev);
+
+ if (!meson_dw_hdmi)
+ return 0;
+
+ /* Reset TOP */
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi,
+ HDMITX_TOP_SW_RESET, 0);
+
+ return 0;
+}
+
+static int __maybe_unused meson_dw_hdmi_pm_resume(struct device *dev)
+{
+ struct meson_dw_hdmi *meson_dw_hdmi = dev_get_drvdata(dev);
+
+ if (!meson_dw_hdmi)
+ return 0;
+
+ meson_dw_hdmi_init(meson_dw_hdmi);
+
+ dw_hdmi_resume(meson_dw_hdmi->hdmi);
+
+ return 0;
+}
+
static int meson_dw_hdmi_probe(struct platform_device *pdev)
{
return component_add(&pdev->dev, &meson_dw_hdmi_ops);
@@ -1003,6 +1039,11 @@ static int meson_dw_hdmi_remove(struct platform_device *pdev)
return 0;
}
+static const struct dev_pm_ops meson_dw_hdmi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(meson_dw_hdmi_pm_suspend,
+ meson_dw_hdmi_pm_resume)
+};
+
static const struct of_device_id meson_dw_hdmi_of_table[] = {
{ .compatible = "amlogic,meson-gxbb-dw-hdmi",
.data = &meson_dw_hdmi_gx_data },
@@ -1022,6 +1063,7 @@ static struct platform_driver meson_dw_hdmi_platform_driver = {
.driver = {
.name = DRIVER_NAME,
.of_match_table = meson_dw_hdmi_of_table,
+ .pm = &meson_dw_hdmi_pm_ops,
},
};
module_platform_driver(meson_dw_hdmi_platform_driver);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] drm/meson: add resume/suspend hooks
From: Neil Armstrong @ 2019-08-27 9:58 UTC (permalink / raw)
To: dri-devel
Cc: khilman, Neil Armstrong, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <20190827095825.21015-1-narmstrong@baylibre.com>
Add the suspend and resume hooks to:
- save and disable the entire DRM driver on suspend
- re-init the entire VPU subsystem on resume, to recover CRTC and pixel
generator functionnal usage after DDR suspend, then recover DRM driver
state
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_drv.c | 32 +++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 2310c96fff46..dc573ffd1f4c 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -361,6 +361,33 @@ static const struct component_master_ops meson_drv_master_ops = {
.unbind = meson_drv_unbind,
};
+static int __maybe_unused meson_drv_pm_suspend(struct device *dev)
+{
+ struct meson_drm *priv = dev_get_drvdata(dev);
+
+ if (!priv)
+ return 0;
+
+ return drm_mode_config_helper_suspend(priv->drm);
+}
+
+static int __maybe_unused meson_drv_pm_resume(struct device *dev)
+{
+ struct meson_drm *priv = dev_get_drvdata(dev);
+
+ if (!priv)
+ return 0;
+
+ meson_vpu_init(priv);
+ meson_venc_init(priv);
+ meson_vpp_init(priv);
+ meson_viu_init(priv);
+
+ drm_mode_config_helper_resume(priv->drm);
+
+ return 0;
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %pOF with %pOF\n",
@@ -452,11 +479,16 @@ static const struct of_device_id dt_match[] = {
};
MODULE_DEVICE_TABLE(of, dt_match);
+static const struct dev_pm_ops meson_drv_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(meson_drv_pm_suspend, meson_drv_pm_resume)
+};
+
static struct platform_driver meson_drm_platform_driver = {
.probe = meson_drv_probe,
.driver = {
.name = "meson-drm",
.of_match_table = dt_match,
+ .pm = &meson_drv_pm_ops,
},
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: CPUfreq fail on rk3399-firefly
From: Kever Yang @ 2019-08-27 9:59 UTC (permalink / raw)
To: Heiko Stuebner
Cc: kernel-build-reports, Kevin Hilman, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <8953975.ee0vQab4qn@phil>
Hi Heiko,
On 2019/8/27 上午10:14, Heiko Stuebner wrote:
> Hi Kever,
>
> Am Dienstag, 27. August 2019, 03:54:26 CEST schrieb Kever Yang:
>> On 2019/8/27 上午1:09, Kevin Hilman wrote:
>>> Kever Yang <kever.yang@rock-chips.com> writes:
>>>> I want to have a test with my board, I can get the Image and dtb
>>>> from the link for the job,
>>>>
>>>> but how can I get the randisk which is named initrd-SDbyy2.cpio.gz?
>>> The ramdisk images are here:
>>>
>>> https://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/arm64/base/
>>>
>>> in the kernelCI logs the ramdisk is slightly modified because the kernel
>>> modules have been inserted into the cpio archive.
>>>
>>> However, for the purposes of this test, you can just test with the
>>> unmodified rootfs.cpio.gz above.
>>
>> I try with this ramdisk, and it hangs at fan53555 init, but not get into
>> cpufreq.
>>
>> Any suggestion?
> My guess would be the fcs,suspend-voltage-selector maybe?
>
> I.e. old uboots somehow set the voltage gpio strangely, so you'd need
> fcs,suspend-voltage-selector = <0>
Both U-Boot and Kernel dts are still '<0>' for this property, and this
is correct setting for cpu_b;
> while newer uboots I think do configure the gpio, needing a value of <1>;
There is no 'vsel-gpio' in both upstream U-Boot and kernel dts, while
there is a "vsel-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;"
in rockchip kernel 4.4 dts. so I think there is no gpio setting on
upstream code?
And kernelci's test case, does not update the bootloader, only update
kernel.
Thanks,
- Kever
>
> So try to swap that number in the dts perhaps for a start?
>
>
> Heiko
>
>
>> My boot log:
>>
>> https://paste.ubuntu.com/p/WYZKPWp7sk/
>>
>> Thanks,
>>
>> - Kever
>>
>>> Kevin
>>>
>>>
>>>> Thanks,
>>>>
>>>> - Kever
>>>>
>>>> On 2019/8/24 上午1:03, Kevin Hilman wrote:
>>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>>
>>>>>> Kever Yang <kever.yang@rock-chips.com> writes:
>>>>>>
>>>>>>> Hi Kevin, Heiko,
>>>>>>>
>>>>>>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
>>>>>>>> Hi Heiko,
>>>>>>>>
>>>>>>>> Heiko Stuebner <heiko@sntech.de> writes:
>>>>>>>>
>>>>>>>>> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
>>>>>>>>>> [ resent with correct addr for linux-rockchip list ]
>>>>>>>>>>
>>>>>>>>>> Mark Brown <broonie@kernel.org> writes:
>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
>>>>>>>>>>>
>>>>>>>>>>> Today's -next started failing to boot defconfig on rk3399-firefly:
>>>>>>>>>>>
>>>>>>>>>>>> arm64:
>>>>>>>>>>>> defconfig:
>>>>>>>>>>>> gcc-8:
>>>>>>>>>>>> rk3399-firefly: 1 failed lab
>>>>>>>>>>> It hits a BUG() trying to set up cpufreq:
>>>>>>>>>>>
>>>>>>>>>>> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
>>>>>>>>>>> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
>>>>>>>>>>> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
>>>>>>>>>>> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
>>>>>>>>>>> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
>>>>>>>>>>> [ 87.495335] ------------[ cut here ]------------
>>>>>>>>>>> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
>>>>>>>>>>> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>>>>>>>>>>>
>>>>>>>>>>> I'm struggling to see anything relevant in the diff from yesterday, the
>>>>>>>>>>> unlisted frequency warnings were there in the logs yesterday but no oops
>>>>>>>>>>> and I'm not seeing any changes in cpufreq, clk or anything relevant
>>>>>>>>>>> looking.
>>>>>>>>>>>
>>>>>>>>>>> Full bootlog and other info can be found here:
>>>>>>>>>>>
>>>>>>>>>>> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
>>>>>>>>>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
>>>>>>>>>> makes the firefly board start working again.
>>>>>>>>>>
>>>>>>>>>> Note that the default defconfig enables the "performance" CPUfreq
>>>>>>>>>> governor as the default governor, so during kernel boot, it will always
>>>>>>>>>> switch to the max frequency.
>>>>>>>>>>
>>>>>>>>>> For fun, I set the default governor to "userspace" so the kernel
>>>>>>>>>> wouldn't make any OPP changes, and that leads to a slightly more
>>>>>>>>>> informative splat[1]
>>>>>>>>>>
>>>>>>>>>> There is still an OPP change happening because the detected OPP is not
>>>>>>>>>> one that's listed in the table, so it tries to change to a listed OPP
>>>>>>>>>> and fails in the bowels of clk_set_rate()
>>>>>>>>> Though I think that might only be a symptom as well.
>>>>>>>>> Both the PLL setting code as well as the actual cpu-clock implementation
>>>>>>>>> is unchanged since 2017 (and runs just fine on all boards in my farm).
>>>>>>>>>
>>>>>>>>> One source for these issues is often the regulator supplying the cpu
>>>>>>>>> going haywire - aka the voltage not matching the opp.
>>>>>>>>>
>>>>>>>>> As in this error-case it's CPU4 being set, this would mean it might
>>>>>>>>> be the big cluster supplied by the external syr825 (fan5355 clone)
>>>>>>>>> that might act up. In the Firefly-rk3399 case this is even stranger.
>>>>>>>>>
>>>>>>>>> There is a discrepancy between the "fcs,suspend-voltage-selector"
>>>>>>>>> between different bootloader versions (how the selection-pin is set up),
>>>>>>>>> so the kernel might actually write his requested voltage to the wrong
>>>>>>>>> register (not the one for actual voltage, but the second set used for
>>>>>>>>> the suspend voltage).
>>>>>>>>>
>>>>>>>>> Did you by chance swap bootloaders at some point in recent past?
>>>>>>>> No, haven't touched bootloader since I initially setup the board.
>>>>>>> The CPU voltage does not affect by bootloader for kernel should have its
>>>>>>> own opp-table,
>>>>>>>
>>>>>>> the bootloader may only affect the center/logic power supply.
>>>>>>>
>>>>>>>>> I'd assume [2] might actually be the same issue last year, though
>>>>>>>>> the CI-logs are not available anymore it seems.
>>>>>>>>>
>>>>>>>>> Could you try to set the vdd_cpu_b regulator to disabled, so that
>>>>>>>>> cpufreq for this cluster defers and see what happens?
>>>>>>>> Yes, this change[1] definitely makes things boot reliably again, so
>>>>>>>> there's defintiely something a bit unstable with this regulator, at
>>>>>>>> least on this firefly.
>>>>>>> Is it possible to target which patch introduce this bug? This board
>>>>>>> should have work correctly for a long time with upstream source code.
>>>>>> Unfortunately, it seems to be a regular, but intermittent failure, so
>>>>>> bisection is not producing anything reliable.
>>>>>>
>>>>>> You can see that both in mainline[1] and in linux-next[2] there are
>>>>>> periodic failures, but it's hard to see any patterns.
>>>>> Even worse, I (re)tested mainline for versions that were previously
>>>>> passing (v5.2, v5.3-rc5) and they are also failing now.
>>>>>
>>>>> They work again if I disable that regulator as suggested by Heiko.
>>>>>
>>>>> So this is increasingly pointing to failing hardware.
>>>>>
>>>>> Kevin
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/2] Add CCPI2 PMU support
From: Ganapatrao Kulkarni @ 2019-08-27 10:00 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, corbet@lwn.net, Jan Glauber,
Jayachandran Chandrasekharan Nair, gklkml16@gmail.com,
Robert Richter, will@kernel.org
Add Cavium Coherent Processor Interconnect (CCPI2) PMU
support in ThunderX2 Uncore driver.
v4:
Update with review comments [2].
Changed Counter read to 2 word read since single dword read is misbhehaving(hw issue).
[2] https://lkml.org/lkml/2019/7/23/231
v3: Rebased to 5.3-rc1
v2: Updated with review comments [1]
[1] https://lkml.org/lkml/2019/6/14/965
v1: initial patch
Ganapatrao Kulkarni (2):
Documentation: perf: Update documentation for ThunderX2 PMU uncore
driver
drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
.../admin-guide/perf/thunderx2-pmu.rst | 20 +-
drivers/perf/thunderx2_pmu.c | 258 +++++++++++++++---
2 files changed, 236 insertions(+), 42 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/2] Documentation: perf: Update documentation for ThunderX2 PMU uncore driver
From: Ganapatrao Kulkarni @ 2019-08-27 10:00 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, corbet@lwn.net, Jan Glauber,
Jayachandran Chandrasekharan Nair, gklkml16@gmail.com,
Robert Richter, will@kernel.org
In-Reply-To: <1566899990-18277-1-git-send-email-gkulkarni@marvell.com>
From: Ganapatrao Kulkarni <ganapatrao.kulkarni@marvell.com>
Add documentation for Cavium Coherent Processor Interconnect (CCPI2) PMU.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
.../admin-guide/perf/thunderx2-pmu.rst | 20 ++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/perf/thunderx2-pmu.rst b/Documentation/admin-guide/perf/thunderx2-pmu.rst
index 08e33675853a..01f158238ae1 100644
--- a/Documentation/admin-guide/perf/thunderx2-pmu.rst
+++ b/Documentation/admin-guide/perf/thunderx2-pmu.rst
@@ -3,24 +3,26 @@ Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
=============================================================
The ThunderX2 SoC PMU consists of independent, system-wide, per-socket
-PMUs such as the Level 3 Cache (L3C) and DDR4 Memory Controller (DMC).
+PMUs such as the Level 3 Cache (L3C), DDR4 Memory Controller (DMC) and
+Cavium Coherent Processor Interconnect (CCPI2).
The DMC has 8 interleaved channels and the L3C has 16 interleaved tiles.
Events are counted for the default channel (i.e. channel 0) and prorated
to the total number of channels/tiles.
-The DMC and L3C support up to 4 counters. Counters are independently
-programmable and can be started and stopped individually. Each counter
-can be set to a different event. Counters are 32-bit and do not support
-an overflow interrupt; they are read every 2 seconds.
+The DMC and L3C support up to 4 counters, while the CCPI2 supports up to 8
+counters. Counters are independently programmable to different events and
+can be started and stopped individually. None of the counters support an
+overflow interrupt. DMC and L3C counters are 32-bit and read every 2 seconds.
+The CCPI2 counters are 64-bit and assumed not to overflow in normal operation.
PMU UNCORE (perf) driver:
The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
-L3C devices. Each PMU can be used to count up to 4 events
-simultaneously. The PMUs provide a description of their available events
-and configuration options under sysfs, see
-/sys/devices/uncore_<l3c_S/dmc_S/>; S is the socket id.
+L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
+(CCPI2) events simultaneously. The PMUs provide a description of their
+available events and configuration options under sysfs, see
+/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
The driver does not support sampling, therefore "perf record" will not
work. Per-task perf sessions are also not supported.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
From: Ganapatrao Kulkarni @ 2019-08-27 10:00 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, corbet@lwn.net, Jan Glauber,
Jayachandran Chandrasekharan Nair, gklkml16@gmail.com,
Robert Richter, will@kernel.org
In-Reply-To: <1566899990-18277-1-git-send-email-gkulkarni@marvell.com>
CCPI2 is a low-latency high-bandwidth serial interface for inter socket
connectivity of ThunderX2 processors.
CCPI2 PMU supports up to 8 counters per socket. Counters are
independently programmable to different events and can be started and
stopped individually. The CCPI2 counters are 64-bit and do not overflow
in normal operation.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
drivers/perf/thunderx2_pmu.c | 258 ++++++++++++++++++++++++++++++-----
1 file changed, 225 insertions(+), 33 deletions(-)
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 43d76c85da56..d290d8ebbd53 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -16,23 +16,36 @@
* they need to be sampled before overflow(i.e, at every 2 seconds).
*/
-#define TX2_PMU_MAX_COUNTERS 4
+#define TX2_PMU_DMC_L3C_MAX_COUNTERS 4
+#define TX2_PMU_CCPI2_MAX_COUNTERS 8
+#define TX2_PMU_MAX_COUNTERS TX2_PMU_CCPI2_MAX_COUNTERS
+
+
#define TX2_PMU_DMC_CHANNELS 8
#define TX2_PMU_L3_TILES 16
#define TX2_PMU_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
-#define GET_EVENTID(ev) ((ev->hw.config) & 0x1f)
-#define GET_COUNTERID(ev) ((ev->hw.idx) & 0x3)
+#define GET_EVENTID(ev, mask) ((ev->hw.config) & mask)
+#define GET_COUNTERID(ev, mask) ((ev->hw.idx) & mask)
/* 1 byte per counter(4 counters).
* Event id is encoded in bits [5:1] of a byte,
*/
#define DMC_EVENT_CFG(idx, val) ((val) << (((idx) * 8) + 1))
+/* bits[3:0] to select counters, are indexed from 8 to 15. */
+#define CCPI2_COUNTER_OFFSET 8
+
#define L3C_COUNTER_CTL 0xA8
#define L3C_COUNTER_DATA 0xAC
#define DMC_COUNTER_CTL 0x234
#define DMC_COUNTER_DATA 0x240
+#define CCPI2_PERF_CTL 0x108
+#define CCPI2_COUNTER_CTL 0x10C
+#define CCPI2_COUNTER_SEL 0x12c
+#define CCPI2_COUNTER_DATA_L 0x130
+#define CCPI2_COUNTER_DATA_H 0x134
+
/* L3C event IDs */
#define L3_EVENT_READ_REQ 0xD
#define L3_EVENT_WRITEBACK_REQ 0xE
@@ -51,15 +64,28 @@
#define DMC_EVENT_READ_TXNS 0xF
#define DMC_EVENT_MAX 0x10
+#define CCPI2_EVENT_REQ_PKT_SENT 0x3D
+#define CCPI2_EVENT_SNOOP_PKT_SENT 0x65
+#define CCPI2_EVENT_DATA_PKT_SENT 0x105
+#define CCPI2_EVENT_GIC_PKT_SENT 0x12D
+#define CCPI2_EVENT_MAX 0x200
+
+#define CCPI2_PERF_CTL_ENABLE BIT(0)
+#define CCPI2_PERF_CTL_START BIT(1)
+#define CCPI2_PERF_CTL_RESET BIT(4)
+#define CCPI2_EVENT_LEVEL_RISING_EDGE BIT(10)
+#define CCPI2_EVENT_TYPE_EDGE_SENSITIVE BIT(11)
+
enum tx2_uncore_type {
PMU_TYPE_L3C,
PMU_TYPE_DMC,
+ PMU_TYPE_CCPI2,
PMU_TYPE_INVALID,
};
/*
- * pmu on each socket has 2 uncore devices(dmc and l3c),
- * each device has 4 counters.
+ * Each socket has 3 uncore devices associated with a PMU. The DMC and
+ * L3C have 4 32-bit counters and the CCPI2 has 8 64-bit counters.
*/
struct tx2_uncore_pmu {
struct hlist_node hpnode;
@@ -69,8 +95,10 @@ struct tx2_uncore_pmu {
int node;
int cpu;
u32 max_counters;
+ u32 counters_mask;
u32 prorate_factor;
u32 max_events;
+ u32 events_mask;
u64 hrtimer_interval;
void __iomem *base;
DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
@@ -92,7 +120,21 @@ static inline struct tx2_uncore_pmu *pmu_to_tx2_pmu(struct pmu *pmu)
return container_of(pmu, struct tx2_uncore_pmu, pmu);
}
-PMU_FORMAT_ATTR(event, "config:0-4");
+#define TX2_PMU_FORMAT_ATTR(_var, _name, _format) \
+static ssize_t \
+__tx2_pmu_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+ \
+static struct device_attribute format_attr_##_var = \
+ __ATTR(_name, 0444, __tx2_pmu_##_var##_show, NULL)
+
+TX2_PMU_FORMAT_ATTR(event, event, "config:0-4");
+TX2_PMU_FORMAT_ATTR(event_ccpi2, event, "config:0-9");
static struct attribute *l3c_pmu_format_attrs[] = {
&format_attr_event.attr,
@@ -104,6 +146,11 @@ static struct attribute *dmc_pmu_format_attrs[] = {
NULL,
};
+static struct attribute *ccpi2_pmu_format_attrs[] = {
+ &format_attr_event_ccpi2.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_format_attr_group = {
.name = "format",
.attrs = l3c_pmu_format_attrs,
@@ -114,6 +161,11 @@ static const struct attribute_group dmc_pmu_format_attr_group = {
.attrs = dmc_pmu_format_attrs,
};
+static const struct attribute_group ccpi2_pmu_format_attr_group = {
+ .name = "format",
+ .attrs = ccpi2_pmu_format_attrs,
+};
+
/*
* sysfs event attributes
*/
@@ -164,6 +216,19 @@ static struct attribute *dmc_pmu_events_attrs[] = {
NULL,
};
+TX2_EVENT_ATTR(req_pktsent, CCPI2_EVENT_REQ_PKT_SENT);
+TX2_EVENT_ATTR(snoop_pktsent, CCPI2_EVENT_SNOOP_PKT_SENT);
+TX2_EVENT_ATTR(data_pktsent, CCPI2_EVENT_DATA_PKT_SENT);
+TX2_EVENT_ATTR(gic_pktsent, CCPI2_EVENT_GIC_PKT_SENT);
+
+static struct attribute *ccpi2_pmu_events_attrs[] = {
+ &tx2_pmu_event_attr_req_pktsent.attr.attr,
+ &tx2_pmu_event_attr_snoop_pktsent.attr.attr,
+ &tx2_pmu_event_attr_data_pktsent.attr.attr,
+ &tx2_pmu_event_attr_gic_pktsent.attr.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_events_attr_group = {
.name = "events",
.attrs = l3c_pmu_events_attrs,
@@ -174,6 +239,11 @@ static const struct attribute_group dmc_pmu_events_attr_group = {
.attrs = dmc_pmu_events_attrs,
};
+static const struct attribute_group ccpi2_pmu_events_attr_group = {
+ .name = "events",
+ .attrs = ccpi2_pmu_events_attrs,
+};
+
/*
* sysfs cpumask attributes
*/
@@ -213,6 +283,13 @@ static const struct attribute_group *dmc_pmu_attr_groups[] = {
NULL
};
+static const struct attribute_group *ccpi2_pmu_attr_groups[] = {
+ &ccpi2_pmu_format_attr_group,
+ &pmu_cpumask_attr_group,
+ &ccpi2_pmu_events_attr_group,
+ NULL
+};
+
static inline u32 reg_readl(unsigned long addr)
{
return readl((void __iomem *)addr);
@@ -245,33 +322,58 @@ static void init_cntr_base_l3c(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
/* counter ctrl/data reg offset at 8 */
hwc->config_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event, cmask));
hwc->event_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event, cmask));
}
static void init_cntr_base_dmc(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
hwc->config_base = (unsigned long)tx2_pmu->base
+ DMC_COUNTER_CTL;
/* counter data reg offset at 0xc */
hwc->event_base = (unsigned long)tx2_pmu->base
- + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event));
+ + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event, cmask));
+}
+
+static void init_cntr_base_ccpi2(struct perf_event *event,
+ struct tx2_uncore_pmu *tx2_pmu)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ cmask = tx2_pmu->counters_mask;
+
+ hwc->config_base = (unsigned long)tx2_pmu->base
+ + CCPI2_COUNTER_CTL + (4 * GET_COUNTERID(event, cmask));
+ hwc->event_base = (unsigned long)tx2_pmu->base;
}
static void uncore_start_event_l3c(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, emask;
struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
/* event id encoded in bits [07:03] */
- val = GET_EVENTID(event) << 3;
+ val = GET_EVENTID(event, emask) << 3;
reg_writel(val, hwc->config_base);
local64_set(&hwc->prev_count, 0);
reg_writel(0, hwc->event_base);
@@ -284,10 +386,17 @@ static inline void uncore_stop_event_l3c(struct perf_event *event)
static void uncore_start_event_dmc(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, cmask, emask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
- int event_id = GET_EVENTID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx, event_id;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
+
+ idx = GET_COUNTERID(event, cmask);
+ event_id = GET_EVENTID(event, emask);
/* enable and start counters.
* 8 bits for each counter, bits[05:01] of a counter to set event type.
@@ -302,9 +411,14 @@ static void uncore_start_event_dmc(struct perf_event *event, int flags)
static void uncore_stop_event_dmc(struct perf_event *event)
{
- u32 val;
+ u32 val, cmask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ idx = GET_COUNTERID(event, cmask);
/* clear event type(bits[05:01]) to stop counter */
val = reg_readl(hwc->config_base);
@@ -312,27 +426,72 @@ static void uncore_stop_event_dmc(struct perf_event *event)
reg_writel(val, hwc->config_base);
}
+static void uncore_start_event_ccpi2(struct perf_event *event, int flags)
+{
+ u32 emask;
+ struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
+
+ /* Bit [09:00] to set event id.
+ * Bits [10], set level to rising edge.
+ * Bits [11], set type to edge sensitive.
+ */
+ reg_writel((CCPI2_EVENT_TYPE_EDGE_SENSITIVE |
+ CCPI2_EVENT_LEVEL_RISING_EDGE |
+ GET_EVENTID(event, emask)), hwc->config_base);
+
+ /* reset[4], enable[0] and start[1] counters */
+ reg_writel(CCPI2_PERF_CTL_RESET |
+ CCPI2_PERF_CTL_START |
+ CCPI2_PERF_CTL_ENABLE,
+ hwc->event_base + CCPI2_PERF_CTL);
+ local64_set(&event->hw.prev_count, 0ULL);
+}
+
+static void uncore_stop_event_ccpi2(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* disable and stop counter */
+ reg_writel(0, hwc->event_base + CCPI2_PERF_CTL);
+}
+
static void tx2_uncore_event_update(struct perf_event *event)
{
- s64 prev, delta, new = 0;
+ u64 prev, delta, new = 0;
struct hw_perf_event *hwc = &event->hw;
struct tx2_uncore_pmu *tx2_pmu;
enum tx2_uncore_type type;
u32 prorate_factor;
+ u32 cmask, emask;
tx2_pmu = pmu_to_tx2_pmu(event->pmu);
type = tx2_pmu->type;
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
prorate_factor = tx2_pmu->prorate_factor;
-
- new = reg_readl(hwc->event_base);
- prev = local64_xchg(&hwc->prev_count, new);
-
- /* handles rollover of 32 bit counter */
- delta = (u32)(((1UL << 32) - prev) + new);
+ if (type == PMU_TYPE_CCPI2) {
+ reg_writel(CCPI2_COUNTER_OFFSET +
+ GET_COUNTERID(event, cmask),
+ hwc->event_base + CCPI2_COUNTER_SEL);
+ new = reg_readl(hwc->event_base + CCPI2_COUNTER_DATA_H);
+ new = (new << 32) +
+ reg_readl(hwc->event_base + CCPI2_COUNTER_DATA_L);
+ prev = local64_xchg(&hwc->prev_count, new);
+ delta = new - prev;
+ } else {
+ new = reg_readl(hwc->event_base);
+ prev = local64_xchg(&hwc->prev_count, new);
+ /* handles rollover of 32 bit counter */
+ delta = (u32)(((1UL << 32) - prev) + new);
+ }
/* DMC event data_transfers granularity is 16 Bytes, convert it to 64 */
if (type == PMU_TYPE_DMC &&
- GET_EVENTID(event) == DMC_EVENT_DATA_TRANSFERS)
+ GET_EVENTID(event, emask) == DMC_EVENT_DATA_TRANSFERS)
delta = delta/4;
/* L3C and DMC has 16 and 8 interleave channels respectively.
@@ -351,6 +510,7 @@ static enum tx2_uncore_type get_tx2_pmu_type(struct acpi_device *adev)
} devices[] = {
{"CAV901D", PMU_TYPE_L3C},
{"CAV901F", PMU_TYPE_DMC},
+ {"CAV901E", PMU_TYPE_CCPI2},
{"", PMU_TYPE_INVALID}
};
@@ -380,7 +540,8 @@ static bool tx2_uncore_validate_event(struct pmu *pmu,
* Make sure the group of events can be scheduled at once
* on the PMU.
*/
-static bool tx2_uncore_validate_event_group(struct perf_event *event)
+static bool tx2_uncore_validate_event_group(struct perf_event *event,
+ int max_counters)
{
struct perf_event *sibling, *leader = event->group_leader;
int counters = 0;
@@ -403,7 +564,7 @@ static bool tx2_uncore_validate_event_group(struct perf_event *event)
* If the group requires more counters than the HW has,
* it cannot ever be scheduled.
*/
- return counters <= TX2_PMU_MAX_COUNTERS;
+ return counters <= max_counters;
}
@@ -439,7 +600,7 @@ static int tx2_uncore_event_init(struct perf_event *event)
hwc->config = event->attr.config;
/* Validate the group */
- if (!tx2_uncore_validate_event_group(event))
+ if (!tx2_uncore_validate_event_group(event, tx2_pmu->max_counters))
return -EINVAL;
return 0;
@@ -456,6 +617,10 @@ static void tx2_uncore_event_start(struct perf_event *event, int flags)
tx2_pmu->start_event(event, flags);
perf_event_update_userpage(event);
+ /* No hrtimer needed for CCPI2, 64-bit counters */
+ if (!tx2_pmu->hrtimer.function)
+ return;
+
/* Start timer for first event */
if (bitmap_weight(tx2_pmu->active_counters,
tx2_pmu->max_counters) == 1) {
@@ -510,11 +675,13 @@ static void tx2_uncore_event_del(struct perf_event *event, int flags)
{
struct tx2_uncore_pmu *tx2_pmu = pmu_to_tx2_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+ cmask = tx2_pmu->counters_mask;
tx2_uncore_event_stop(event, PERF_EF_UPDATE);
/* clear the assigned counter */
- free_counter(tx2_pmu, GET_COUNTERID(event));
+ free_counter(tx2_pmu, GET_COUNTERID(event, cmask));
perf_event_update_userpage(event);
tx2_pmu->events[hwc->idx] = NULL;
@@ -580,8 +747,10 @@ static int tx2_uncore_pmu_add_dev(struct tx2_uncore_pmu *tx2_pmu)
cpu_online_mask);
tx2_pmu->cpu = cpu;
- hrtimer_init(&tx2_pmu->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
+
+ if (tx2_pmu->hrtimer.function)
+ hrtimer_init(&tx2_pmu->hrtimer,
+ CLOCK_MONOTONIC, HRTIMER_MODE_REL);
ret = tx2_uncore_pmu_register(tx2_pmu);
if (ret) {
@@ -653,10 +822,13 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
switch (tx2_pmu->type) {
case PMU_TYPE_L3C:
- tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->max_counters = TX2_PMU_DMC_L3C_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_L3_TILES;
tx2_pmu->max_events = L3_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
+ tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
tx2_pmu->attr_groups = l3c_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
"uncore_l3c_%d", tx2_pmu->node);
@@ -665,10 +837,13 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->stop_event = uncore_stop_event_l3c;
break;
case PMU_TYPE_DMC:
- tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->max_counters = TX2_PMU_DMC_L3C_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_DMC_CHANNELS;
tx2_pmu->max_events = DMC_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
+ tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
tx2_pmu->attr_groups = dmc_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
"uncore_dmc_%d", tx2_pmu->node);
@@ -676,6 +851,21 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->start_event = uncore_start_event_dmc;
tx2_pmu->stop_event = uncore_stop_event_dmc;
break;
+ case PMU_TYPE_CCPI2:
+ /* CCPI2 has 8 counters */
+ tx2_pmu->max_counters = TX2_PMU_CCPI2_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x7;
+ tx2_pmu->prorate_factor = 1;
+ tx2_pmu->max_events = CCPI2_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1ff;
+ tx2_pmu->attr_groups = ccpi2_pmu_attr_groups;
+ tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_ccpi2_%d", tx2_pmu->node);
+ tx2_pmu->init_cntr_base = init_cntr_base_ccpi2;
+ tx2_pmu->start_event = uncore_start_event_ccpi2;
+ tx2_pmu->stop_event = uncore_stop_event_ccpi2;
+ tx2_pmu->hrtimer.function = NULL;
+ break;
case PMU_TYPE_INVALID:
devm_kfree(dev, tx2_pmu);
return NULL;
@@ -744,7 +934,9 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
if (cpu != tx2_pmu->cpu)
return 0;
- hrtimer_cancel(&tx2_pmu->hrtimer);
+ if (tx2_pmu->hrtimer.function)
+ hrtimer_cancel(&tx2_pmu->hrtimer);
+
cpumask_copy(&cpu_online_mask_temp, cpu_online_mask);
cpumask_clear_cpu(cpu, &cpu_online_mask_temp);
new_cpu = cpumask_any_and(
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/6] dma-mapping: remove arch_dma_mmap_pgprot
From: Paul Burton @ 2019-08-27 10:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k@lists.linux-m68k.org, Will Deacon,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Russell King, linux-mips@vger.kernel.org,
iommu@lists.linux-foundation.org, Geert Uytterhoeven,
Catalin Marinas, James Hogan, Guan Xuetao,
linux-arm-kernel@lists.infradead.org, Robin Murphy
In-Reply-To: <20190826132553.4116-4-hch@lst.de>
Hi Christoph,
On Mon, Aug 26, 2019 at 03:25:50PM +0200, Christoph Hellwig wrote:
> arch_dma_mmap_pgprot is used for two things:
>
> 1) to override the "normal" uncached page attributes for mapping
> memory coherent to devices that can't snoop the CPU caches
> 2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
> arm systems and some mips platforms
>
> Replace one with the pgprot_dmacoherent macro that is already provided
> by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
> handling to common code with an explicit arch opt-in.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
For the MIPS bits:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
> ---
> arch/arm/Kconfig | 2 +-
> arch/arm/mm/dma-mapping.c | 6 ------
> arch/arm64/Kconfig | 1 -
> arch/arm64/include/asm/pgtable.h | 4 ++++
> arch/arm64/mm/dma-mapping.c | 6 ------
> arch/m68k/Kconfig | 1 -
> arch/m68k/include/asm/pgtable_mm.h | 3 +++
> arch/m68k/kernel/dma.c | 3 +--
> arch/mips/Kconfig | 2 +-
> arch/mips/mm/dma-noncoherent.c | 8 --------
> include/linux/dma-noncoherent.h | 13 +++++++++++--
> kernel/dma/Kconfig | 12 +++++++++---
> kernel/dma/mapping.c | 8 +++++---
> 13 files changed, 35 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 24360211534a..217083caeabd 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -8,7 +8,7 @@ config ARM
> select ARCH_HAS_DEBUG_VIRTUAL if MMU
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
> - select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
> + select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FORTIFY_SOURCE
> select ARCH_HAS_KEEPINITRD
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index d42557ee69c2..d27b12f61737 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2402,12 +2402,6 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
> return dma_to_pfn(dev, dma_addr);
> }
>
> -pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> - unsigned long attrs)
> -{
> - return __get_dma_pgprot(attrs, prot);
> -}
> -
> void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> gfp_t gfp, unsigned long attrs)
> {
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3adcec05b1f6..dab9dda34206 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -13,7 +13,6 @@ config ARM64
> select ARCH_HAS_DEBUG_VIRTUAL
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_DMA_COHERENT_TO_PFN
> - select ARCH_HAS_DMA_MMAP_PGPROT
> select ARCH_HAS_DMA_PREP_COHERENT
> select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
> select ARCH_HAS_ELF_RANDOMIZE
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e09760ece844..6700371227d1 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -435,6 +435,10 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> #define pgprot_device(prot) \
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
> +#define pgprot_dmacoherent(prot) \
> + __pgprot_modify(prot, PTE_ATTRINDX_MASK, \
> + PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> +
> #define __HAVE_PHYS_MEM_ACCESS_PROT
> struct file;
> extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index bd2b039f43a6..676efcda51e6 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -11,12 +11,6 @@
>
> #include <asm/cacheflush.h>
>
> -pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> - unsigned long attrs)
> -{
> - return pgprot_writecombine(prot);
> -}
> -
> void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir)
> {
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index c518d695c376..a9e564306d3e 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -4,7 +4,6 @@ config M68K
> default y
> select ARCH_32BIT_OFF_T
> select ARCH_HAS_BINFMT_FLAT
> - select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
> select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
> select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
> diff --git a/arch/m68k/include/asm/pgtable_mm.h b/arch/m68k/include/asm/pgtable_mm.h
> index fe3ddd73a0cc..fde4534b974f 100644
> --- a/arch/m68k/include/asm/pgtable_mm.h
> +++ b/arch/m68k/include/asm/pgtable_mm.h
> @@ -169,6 +169,9 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
> ? (__pgprot((pgprot_val(prot) & _CACHEMASK040) | _PAGE_NOCACHE_S)) \
> : (prot)))
>
> +pgprot_t pgprot_dmacoherent(pgprot_t prot);
> +#define pgprot_dmacoherent(prot) pgprot_dmacoherent(prot)
> +
> #endif /* CONFIG_COLDFIRE */
> #include <asm-generic/pgtable.h>
> #endif /* !__ASSEMBLY__ */
> diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
> index 30cd59caf037..35064150e348 100644
> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -23,8 +23,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
> cache_push(page_to_phys(page), size);
> }
>
> -pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> - unsigned long attrs)
> +pgprot_t pgprot_dmacoherent(pgprot_t prot)
> {
> if (CPU_IS_040_OR_060) {
> pgprot_val(prot) &= ~_PAGE_CACHE040;
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index d50fafd7bf3a..fc88f68ea1ee 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1119,7 +1119,7 @@ config DMA_PERDEV_COHERENT
>
> config DMA_NONCOHERENT
> bool
> - select ARCH_HAS_DMA_MMAP_PGPROT
> + select ARCH_HAS_DMA_WRITE_COMBINE
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select ARCH_HAS_UNCACHED_SEGMENT
> select NEED_DMA_MAP_STATE
> diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
> index ed56c6fa7be2..1d4d57dd9acf 100644
> --- a/arch/mips/mm/dma-noncoherent.c
> +++ b/arch/mips/mm/dma-noncoherent.c
> @@ -65,14 +65,6 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
> return page_to_pfn(virt_to_page(cached_kernel_address(cpu_addr)));
> }
>
> -pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> - unsigned long attrs)
> -{
> - if (attrs & DMA_ATTR_WRITE_COMBINE)
> - return pgprot_writecombine(prot);
> - return pgprot_noncached(prot);
> -}
> -
> static inline void dma_sync_virt(void *addr, size_t size,
> enum dma_data_direction dir)
> {
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index 0bff3d7fac92..dd3de6d88fc0 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -3,6 +3,7 @@
> #define _LINUX_DMA_NONCOHERENT_H 1
>
> #include <linux/dma-mapping.h>
> +#include <asm/pgtable.h>
>
> #ifdef CONFIG_ARCH_HAS_DMA_COHERENCE_H
> #include <asm/dma-coherence.h>
> @@ -42,10 +43,18 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
> dma_addr_t dma_addr, unsigned long attrs);
> long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
> dma_addr_t dma_addr);
> -pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> - unsigned long attrs);
>
> #ifdef CONFIG_MMU
> +/*
> + * Page protection so that devices that can't snoop CPU caches can use the
> + * memory coherently. We default to pgprot_noncached which is usually used
> + * for ioremap as a safe bet, but architectures can override this with less
> + * strict semantics if possible.
> + */
> +#ifndef pgprot_dmacoherent
> +#define pgprot_dmacoherent(prot) pgprot_noncached(prot)
> +#endif
> +
> pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs);
> #else
> static inline pgprot_t dma_pgprot(struct device *dev, pgprot_t prot,
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 9decbba255fc..73c5c2b8e824 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -20,6 +20,15 @@ config ARCH_HAS_DMA_COHERENCE_H
> config ARCH_HAS_DMA_SET_MASK
> bool
>
> +#
> +# Select this option if the architecture needs special handling for
> +# DMA_ATTR_WRITE_COMBINE. Normally the "uncached" mapping should be what
> +# people thing of when saying write combine, so very few platforms should
> +# need to enable this.
> +#
> +config ARCH_HAS_DMA_WRITE_COMBINE
> + bool
> +
> config DMA_DECLARE_COHERENT
> bool
>
> @@ -45,9 +54,6 @@ config ARCH_HAS_DMA_PREP_COHERENT
> config ARCH_HAS_DMA_COHERENT_TO_PFN
> bool
>
> -config ARCH_HAS_DMA_MMAP_PGPROT
> - bool
> -
> config ARCH_HAS_FORCE_DMA_UNENCRYPTED
> bool
>
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index b0038ca3aa92..1b96616c9f20 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -161,9 +161,11 @@ pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
> (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
> (attrs & DMA_ATTR_NON_CONSISTENT)))
> return prot;
> - if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_MMAP_PGPROT))
> - return arch_dma_mmap_pgprot(dev, prot, attrs);
> - return pgprot_noncached(prot);
> +#ifdef CONFIG_ARCH_HAS_DMA_WRITE_COMBINE
> + if (attrs & DMA_ATTR_WRITE_COMBINE)
> + return pgprot_writecombine(prot);
> +#endif
> + return pgprot_dmacoherent(prot);
> }
> #endif /* CONFIG_MMU */
>
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] arm64: dts: meson-g12: specify suspend OPP
From: Neil Armstrong @ 2019-08-27 10:03 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
Tag the 1,2GHz OPP as suspend OPP to be set before going in suspend mode,
for the G12A, G12B and SM1 SoCs.
It has been reported that using various OPPs can lead to error or
resume with a different OPP from the ROM, thus use this safe OPP as
it is the default OPP used by the BL2 boot firmware.
Neil Armstrong (3):
arm64: dts: meson-g12a: specify suspend OPP
arm64: dts: meson-sm1: specify suspend OPP
arm64: dts: meson-g12b: specify suspend OPP
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 1 +
arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 1 +
4 files changed, 6 insertions(+)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] arm64: dts: meson-g12a: specify suspend OPP
From: Neil Armstrong @ 2019-08-27 10:03 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827100307.21661-1-narmstrong@baylibre.com>
Tag the 1,2GHz OPP as suspend OPP to be set before going in suspend mode.
It has been reported that using various OPPs can lead to error or
resume with a different OPP from the ROM, thus use this safe OPP as
it is the default OPP used by the BL2 boot firmware.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index 733a9d46fc4b..57c880c06a07 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -81,6 +81,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <731000>;
+ opp-suspend;
};
opp-1398000000 {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: meson-sm1: specify suspend OPP
From: Neil Armstrong @ 2019-08-27 10:03 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827100307.21661-1-narmstrong@baylibre.com>
Tag the 1,2GHz OPP as suspend OPP to be set before going in suspend mode.
It has been reported that using various OPPs can lead to error or
resume with a different OPP from the ROM, thus use this safe OPP as
it is the default OPP used by the BL2 boot firmware.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index e4830cbf7ed5..32e2de2614b1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -82,6 +82,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <780000>;
+ opp-suspend;
};
opp-1404000000 {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: meson-g12b: specify suspend OPP
From: Neil Armstrong @ 2019-08-27 10:03 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827100307.21661-1-narmstrong@baylibre.com>
Tag the 1,2GHz OPPs as suspend OPP to be set before going in suspend mode.
It has been reported that using various OPPs can lead to error or
resume with a different OPP from the ROM, thus use this safe OPP as
it is the default OPP used by the BL2 boot firmware on the 2 clusters.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi
index d61f43052a34..00ea181bc018 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d.dtsi
@@ -39,6 +39,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <781000>;
+ opp-suspend;
};
opp-1398000000 {
@@ -99,6 +100,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <751000>;
+ opp-suspend;
};
opp-1398000000 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi
index 046cc332d07f..d68323c6c780 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi
@@ -39,6 +39,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <731000>;
+ opp-suspend;
};
opp-1398000000 {
@@ -99,6 +100,7 @@
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <771000>;
+ opp-suspend;
};
opp-1398000000 {
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 6/6] MIPS: document mixing "slightly different CCAs"
From: Paul Burton @ 2019-08-27 10:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k@lists.linux-m68k.org, Will Deacon,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Russell King, linux-mips@vger.kernel.org,
iommu@lists.linux-foundation.org, Geert Uytterhoeven,
Catalin Marinas, James Hogan, Guan Xuetao,
linux-arm-kernel@lists.infradead.org, Robin Murphy
In-Reply-To: <20190826132553.4116-7-hch@lst.de>
Hi Christoph,
On Mon, Aug 26, 2019 at 03:25:53PM +0200, Christoph Hellwig wrote:
> Based on an email from Paul Burton, quoting section 4.8 "Cacheability and
> Coherency Attributes and Access Types" of "MIPS Architecture Volume 1:
> Introduction to the MIPS32 Architecture" (MD00080, revision 6.01).
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
> ---
> arch/mips/Kconfig | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index fc88f68ea1ee..aff1cadeea43 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1119,6 +1119,13 @@ config DMA_PERDEV_COHERENT
>
> config DMA_NONCOHERENT
> bool
> + #
> + # MIPS allows mixing "slightly different" Cacheability and Coherency
> + # Attribute bits. It is believed that the uncached access through
> + # KSEG1 and the implementation specific "uncached accelerated" used
> + # by pgprot_writcombine can be mixed, and the latter sometimes provides
> + # significant advantages.
> + #
> select ARCH_HAS_DMA_WRITE_COMBINE
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select ARCH_HAS_UNCACHED_SEGMENT
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
From: Matthias Brugger @ 2019-08-27 10:04 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <1566879121.29523.8.camel@mtksdaap41>
On 27/08/2019 06:12, Bibby Hsieh wrote:
>>>
>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>>> {
>>> - u32 arg_b;
>>> + struct cmdq_instruction *inst;
>>>
>>> if (event >= CMDQ_MAX_EVENT)
>>> return -EINVAL;
>>>
>>> - /*
>>> - * WFE arg_b
>>> - * bit 0-11: wait value
>>> - * bit 15: 1 - wait, 0 - no wait
>>> - * bit 16-27: update value
>>> - * bit 31: 1 - update, 0 - no update
>>> - */
>>
>> I have no strong opinion of CMDQ_WFE_OPTION but if you want to introduce it,
>> then please copy the comment over to include/linux/mailbox/mtk-cmdq-mailbox.h
>
> Ok. let's move the descriptions to header.
>>
>> Just one question, why did you call it _OPTION? It's not really expressive for me.
>
> Actually, _OPTION is come from our hardware design name...
>
Ok, then I'll stop bike-shedding. I leave it up to you to rename it or not.
Regards,
Matthias
_______________________________________________
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/5] soc: amlogic: Add support for Everything-Else power domains controller
From: Neil Armstrong @ 2019-08-27 10:11 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ulf.hansson, linux-pm, khilman, linux-kernel, linux-amlogic,
linux-arm-kernel
In-Reply-To: <CAFBinCDDygiafTwLgqB9BimqrmwxL2=HFQD8cX8CQL23AFZNXQ@mail.gmail.com>
On 27/08/2019 00:40, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Mon, Aug 26, 2019 at 10:10 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> On 25/08/2019 23:10, Martin Blumenstingl wrote:
>>> Hi Neil,
>>>
>>> thank you for this update
>>> I haven't tried this on the 32-bit SoCs yet, but I am confident that I
>>> can make it work by "just" adding the SoC specific bits!
>>>
>>> On Fri, Aug 23, 2019 at 11:06 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> [...]
>>>> +/* AO Offsets */
>>>> +
>>>> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
>>>> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
>>>> +
>>>> +/* HHI Offsets */
>>>> +
>>>> +#define HHI_MEM_PD_REG0 (0x40 << 2)
>>>> +#define HHI_VPU_MEM_PD_REG0 (0x41 << 2)
>>>> +#define HHI_VPU_MEM_PD_REG1 (0x42 << 2)
>>>> +#define HHI_VPU_MEM_PD_REG3 (0x43 << 2)
>>>> +#define HHI_VPU_MEM_PD_REG4 (0x44 << 2)
>>>> +#define HHI_AUDIO_MEM_PD_REG0 (0x45 << 2)
>>>> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
>>>> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
>>>> +#define HHI_VPU_MEM_PD_REG2 (0x4d << 2)
>>> should we switch to the actual register offsets like we did in the
>>> clock drivers?
>>
>> I find it simpler to refer to the numbers in the documentation...
> OK, I have no strong preference here
> for the 32-bit SoCs I will need to use the offsets based on the
> "amlogic,meson8b-pmu", "syscon" [0], so these will be magic anyways
>
> [...]
>>>> +#define VPU_HHI_MEMPD(__reg) \
>>>> + { __reg, BIT(8) }, \
>>>> + { __reg, BIT(9) }, \
>>>> + { __reg, BIT(10) }, \
>>>> + { __reg, BIT(11) }, \
>>>> + { __reg, BIT(12) }, \
>>>> + { __reg, BIT(13) }, \
>>>> + { __reg, BIT(14) }, \
>>>> + { __reg, BIT(15) }
>>> the Amlogic implementation from buildroot-openlinux-A113-201901 (the
>>> latest one I have)
>>> kernel/aml-4.9/drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hw/hdmi_tx_hw.c
>>> uses:
>>> hd_set_reg_bits(P_HHI_MEM_PD_REG0, 0, 8, 8)
>>> that basically translates to: GENMASK(15, 8) (which means we could
>>> drop this macro)
>>>
>>> the datasheet also states: 15~8 [...] HDMI memory PD (as a single
>>> 8-bit wide register)
>>
>> Yep, but the actual code setting the VPU power domain is in u-boot :
>>
>> drivers/vpu/aml_vpu_power_init.c:
>> 108 for (i = 8; i < 16; i++) {
>> 109 vpu_hiu_setb(HHI_MEM_PD_REG0, 0, i, 1);
>> 110 udelay(5);
>> 111 }
>>
>> the linux code is like never used here, my preference goes to the u-boot code
>> implementation.
> I see, let's keep your implementation then
>
>>>
>>> [...]
>>>> +static struct meson_ee_pwrc_domain_desc g12a_pwrc_domains[] = {
>>>> + [PWRC_G12A_VPU_ID] = VPU_PD("VPU", &g12a_pwrc_vpu, g12a_pwrc_mem_vpu,
>>>> + pwrc_ee_get_power, 11, 2),
>>>> + [PWRC_G12A_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
>>>> +};
>>>> +
>>>> +static struct meson_ee_pwrc_domain_desc sm1_pwrc_domains[] = {
>>>> + [PWRC_SM1_VPU_ID] = VPU_PD("VPU", &sm1_pwrc_vpu, sm1_pwrc_mem_vpu,
>>>> + pwrc_ee_get_power, 11, 2),
>>>> + [PWRC_SM1_NNA_ID] = TOP_PD("NNA", &sm1_pwrc_nna, sm1_pwrc_mem_nna,
>>>> + pwrc_ee_get_power),
>>>> + [PWRC_SM1_USB_ID] = TOP_PD("USB", &sm1_pwrc_usb, sm1_pwrc_mem_usb,
>>>> + pwrc_ee_get_power),
>>>> + [PWRC_SM1_PCIE_ID] = TOP_PD("PCI", &sm1_pwrc_pci, sm1_pwrc_mem_pcie,
>>>> + pwrc_ee_get_power),
>>>> + [PWRC_SM1_GE2D_ID] = TOP_PD("GE2D", &sm1_pwrc_ge2d, sm1_pwrc_mem_ge2d,
>>>> + pwrc_ee_get_power),
>>>> + [PWRC_SM1_AUDIO_ID] = MEM_PD("AUDIO", sm1_pwrc_mem_audio),
>>>> + [PWRC_SM1_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
>>>> +};
>>> my impression: I find this hard to read as it merges the TOP and
>>> Memory PD domains from above, adding some seemingly random "11, 2" for
>>> the VPU PD as well as pwrc_ee_get_power for some of the power domains
>>> personally I like the way we describe clk_regmap because it's easy to
>>> read (even though it adds a bit of boilerplate). I'm not sure if we
>>> can make it work here, but this (not compile tested) is what I have in
>>> mind (I chose two random power domains):
>>> [PWRC_SM1_VPU_ID] = {
>>> .name = "VPU",
>>> .top_pd = SM1_EE_PD(8),
>>> .mem_pds = {
>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG0),
>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG1),
>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG2),
>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG3),
>>> { HHI_VPU_MEM_PD_REG4, GENMASK(1, 0) },
>>> { HHI_VPU_MEM_PD_REG4, GENMASK(3, 2) },
>>> { HHI_VPU_MEM_PD_REG4, GENMASK(5, 4) },
>>> { HHI_VPU_MEM_PD_REG4, GENMASK(7, 6) },
>>> { HHI_MEM_PD_REG0, GENMASK(15, 8) },
>>> },
>>> .num_mem_pds = 9,
>>> .reset_names_count = 11,
>>> .clk_names_count = 2,
>>> },
>>> [PWRC_SM1_ETH_ID] = {
>>> .name = "ETH",
>>> .mem_pds = { HHI_MEM_PD_REG0, GENMASK(3, 2) },
>>> .num_mem_pds = 1,
>>> },
>>> ...
>>>
>>> I'd like to get Kevin's feedback on this
>>> what you have right now is probably good enough for the initial
>>> version of this driver. I'm bringing this discussion up because we
>>> will add support for more SoCs to this driver (we migrate GX over to
>>> it and I want to add 32-bit SoC support, which probably means at least
>>> Meson8 - assuming they kept the power domains identical between
>>> Meson8/8b/8m2).
>>
>> I find it more compact, but nothing is set in stone, you can refactor this as
>> will when adding meson8 support, no problems here.
> OK. if Kevin (or someone else) has feedback on this then I don't have
> to waste time if it turns out that it's not a great idea ;)
>
>>>
>>> [...]
>>>> +struct meson_ee_pwrc_domain {
>>>> + struct generic_pm_domain base;
>>>> + bool enabled;
>>>> + struct meson_ee_pwrc *pwrc;
>>>> + struct meson_ee_pwrc_domain_desc desc;
>>>> + struct clk_bulk_data *clks;
>>>> + int num_clks;
>>>> + struct reset_control *rstc;
>>>> + int num_rstc;
>>>> +};
>>>> +
>>>> +struct meson_ee_pwrc {
>>>> + struct regmap *regmap_ao;
>>>> + struct regmap *regmap_hhi;
>>>> + struct meson_ee_pwrc_domain *domains;
>>>> + struct genpd_onecell_data xlate;
>>>> +};
>>> (my impressions on this: I was surprised to find more structs down
>>> here, I expected them to be together with the other structs further
>>> up)
>>
>> These are the "live" structures, opposed to the static structures defining the
>> data and these are allocated and filled a probe time.
> I see, thanks for the explanation
>
>> I dislike changing static global data at runtime, this is why I clearly separated both.
> I didn't mean to make them static - the thing that caught my eye was
> that some of the structs are defined at the top of the driver while
> these two are define much further down
> I am used to having all struct definitions in one place
I'll let Kevin leave his feedback on this aswell.
>
>>>
>>>> +static bool pwrc_ee_get_power(struct meson_ee_pwrc_domain *pwrc_domain)
>>>> +{
>>>> + u32 reg;
>>>> +
>>>> + regmap_read(pwrc_domain->pwrc->regmap_ao,
>>>> + pwrc_domain->desc.top_pd->sleep_reg, ®);
>>>> +
>>>> + return (reg & pwrc_domain->desc.top_pd->sleep_mask);
>>> should this also check for top_pd->iso_* as well as mem_pd->*?
>>> if the top_pd part was optional we could even use the get_power
>>> callback for *all* power domains in this driver (right now audio and
>>> Ethernet don't have any get_power callback)
>>
>> We could, but how should we handle if one unexpected bit is set ? No idea...
> hmm, I see
> if we need it for other power domains then we can still implement it,
> so it's good for now
>
> [...]
>>> bonus question: what about the video decoder power domains?
>>> here is an example from vdec_1_start
>>> (drivers/staging/media/meson/vdec/vdec_1.c):
>>> /* Enable power for VDEC_1 */
>>> regmap_update_bits(core->regmap_ao, AO_RTI_GEN_PWR_SLEEP0,
>>> GEN_PWR_VDEC_1, 0);
>>> usleep_range(10, 20);
>>> [...]
>>> /* enable VDEC Memories */
>>> amvdec_write_dos(core, DOS_MEM_PD_VDEC, 0);
>>> /* Remove VDEC1 Isolation */
>>> regmap_write(core->regmap_ao, AO_RTI_GEN_PWR_ISO0, 0);
>>>
>>> (my point here is that it mixes video decoder "DOS" registers with
>>> AO_RTI_GEN_PWR registers)
>>> do we also want to add support for these "DOS" power domains to the
>>> meson-ee-pwrc driver?
>>> what about the AO_RTI_GEN_PWR part then - should we keep management
>>> for the video decoder power domain bits in AO_RTI_GEN_PWR as part of
>>> the video decoder driver?
>>
>> I left the decoders power domains aside so we can discuss it later on,
>> we should expose multiple power domains, but the driver would need to
>> be changed to support multiple power domains. But will loose the ability
>> to enable/disable each domain at will unless it created a sub-device for
>> each decoder and attaches the domain to to each device and use runtime pm.
>>
>> It's simpler to discuss it later on !
> OK - does this mean you and/or Maxime have "discuss decoder power
> domains" on your (long) TODO-list or do you want me to open this
> discussion after this driver is merged?
Both I think, let this be an open discussion !
Neil
>
>
> Martin
>
>
> [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/amlogic/pmu.txt
>
_______________________________________________
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/8] coresight: etm4x: Fixes for ETM v4.4 architecture updates.
From: Mike Leach @ 2019-08-27 10:12 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Coresight ML, linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190826214713.GA24690@xps15>
Hi Mathieu,
On Mon, 26 Aug 2019 at 22:47, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> Hi Mike,
>
>
> On Mon, Aug 19, 2019 at 09:57:13PM +0100, Mike Leach wrote:
> > ETMv4.4 adds in support for tracing secure EL2 (per arch 8.x updates).
>
> What is the name of the ETMv4.4 document? I can only find up to 4.2 on line.
>
Arm® Embedded Trace Macrocell
Architecture Specification
ETMv4.0 to ETMv4.4
ARM IHI0064F
Published 2018 - non-confidential.
So should be available.
> > Patch accounts for this new capability.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../hwtracing/coresight/coresight-etm4x-sysfs.c | 12 ++++++------
> > drivers/hwtracing/coresight/coresight-etm4x.c | 5 ++++-
> > drivers/hwtracing/coresight/coresight-etm4x.h | 15 +++++++++++----
> > 3 files changed, 21 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index 219c10eb752c..b6984be0c515 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -738,7 +738,7 @@ static ssize_t s_exlevel_vinst_show(struct device *dev,
> > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > struct etmv4_config *config = &drvdata->config;
> >
> > - val = BMVAL(config->vinst_ctrl, 16, 19);
> > + val = (config->vinst_ctrl & ETM_EXLEVEL_S_VICTLR_MASK) >> 16;
> > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > }
> >
> > @@ -754,8 +754,8 @@ static ssize_t s_exlevel_vinst_store(struct device *dev,
> > return -EINVAL;
> >
> > spin_lock(&drvdata->spinlock);
> > - /* clear all EXLEVEL_S bits (bit[18] is never implemented) */
> > - config->vinst_ctrl &= ~(BIT(16) | BIT(17) | BIT(19));
> > + /* clear all EXLEVEL_S bits */
> > + config->vinst_ctrl &= ~(ETM_EXLEVEL_S_VICTLR_MASK);
> > /* enable instruction tracing for corresponding exception level */
> > val &= drvdata->s_ex_level;
> > config->vinst_ctrl |= (val << 16);
> > @@ -773,7 +773,7 @@ static ssize_t ns_exlevel_vinst_show(struct device *dev,
> > struct etmv4_config *config = &drvdata->config;
> >
> > /* EXLEVEL_NS, bits[23:20] */
> > - val = BMVAL(config->vinst_ctrl, 20, 23);
> > + val = (config->vinst_ctrl & ETM_EXLEVEL_NS_VICTLR_MASK) >> 20;
> > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > }
> >
> > @@ -789,8 +789,8 @@ static ssize_t ns_exlevel_vinst_store(struct device *dev,
> > return -EINVAL;
> >
> > spin_lock(&drvdata->spinlock);
> > - /* clear EXLEVEL_NS bits (bit[23] is never implemented */
> > - config->vinst_ctrl &= ~(BIT(20) | BIT(21) | BIT(22));
> > + /* clear EXLEVEL_NS bits */
> > + config->vinst_ctrl &= ~(ETM_EXLEVEL_NS_VICTLR_MASK);
> > /* enable instruction tracing for corresponding exception level */
> > val &= drvdata->ns_ex_level;
> > config->vinst_ctrl |= (val << 20);
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index a128b5063f46..52b8876de157 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -629,6 +629,7 @@ static void etm4_init_arch_data(void *info)
> > * TRCARCHMAJ, bits[11:8] architecture major versin number
> > */
> > drvdata->arch = BMVAL(etmidr1, 4, 11);
> > + drvdata->config.arch = drvdata->arch;
> >
> > /* maximum size of resources */
> > etmidr2 = readl_relaxed(drvdata->base + TRCIDR2);
> > @@ -780,6 +781,7 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
> > static u64 etm4_get_access_type(struct etmv4_config *config)
> > {
> > u64 access_type = etm4_get_ns_access_type(config);
> > + u64 s_hyp = (config->arch & 0x0f) >= 0x4 ? ETM_EXLEVEL_S_HYP : 0;
> >
> > /*
> > * EXLEVEL_S, bits[11:8], don't trace anything happening
> > @@ -787,7 +789,8 @@ static u64 etm4_get_access_type(struct etmv4_config *config)
> > */
> > access_type |= (ETM_EXLEVEL_S_APP |
> > ETM_EXLEVEL_S_OS |
> > - ETM_EXLEVEL_S_HYP);
> > + s_hyp |
> > + ETM_EXLEVEL_S_MON);
> >
> > return access_type;
> > }
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 4523f10ddd0f..60bc2fb5159b 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -180,17 +180,22 @@
> > /* PowerDown Control Register bits */
> > #define TRCPDCR_PU BIT(3)
> >
> > -/* secure state access levels */
> > +/* secure state access levels - TRCACATRn */
> > #define ETM_EXLEVEL_S_APP BIT(8)
> > #define ETM_EXLEVEL_S_OS BIT(9)
> > -#define ETM_EXLEVEL_S_NA BIT(10)
> > -#define ETM_EXLEVEL_S_HYP BIT(11)
> > -/* non-secure state access levels */
> > +#define ETM_EXLEVEL_S_HYP BIT(10)
> > +#define ETM_EXLEVEL_S_MON BIT(11)
> > +/* non-secure state access levels - TRCACATRn */
> > #define ETM_EXLEVEL_NS_APP BIT(12)
> > #define ETM_EXLEVEL_NS_OS BIT(13)
> > #define ETM_EXLEVEL_NS_HYP BIT(14)
> > #define ETM_EXLEVEL_NS_NA BIT(15)
> >
> > +/* secure / non secure masks - TRCVICTLR, IDR3 */
> > +#define ETM_EXLEVEL_S_VICTLR_MASK GENMASK(19, 16)
> > +/* NS MON (EL3) mode never implemented */
> > +#define ETM_EXLEVEL_NS_VICTLR_MASK GENMASK(22, 20)
>
> It is hard to say without documentation but shouldn't this be GENMASK(23, 20)?
>
Per the comment above, EL3_NS is prohibited so the mask refers to only
the 3 allow bits (NS EL0 - EL2).
> > +
> > /**
> > * struct etmv4_config - configuration information related to an ETMv4
> > * @mode: Controls various modes supported by this ETM.
> > @@ -237,6 +242,7 @@
> > * @vmid_mask0: VM ID comparator mask for comparator 0-3.
> > * @vmid_mask1: VM ID comparator mask for comparator 4-7.
> > * @ext_inp: External input selection.
> > + * @arch: ETM architecture version (for arch dependent config).
> > */
> > struct etmv4_config {
> > u32 mode;
> > @@ -279,6 +285,7 @@ struct etmv4_config {
> > u32 vmid_mask0;
> > u32 vmid_mask1;
> > u32 ext_inp;
> > + u8 arch;
> > };
> >
> > /**
> > --
> > 2.17.1
> >
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Matthias Brugger @ 2019-08-27 10:13 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
linux-arm-kernel, ginny.chen
In-Reply-To: <1566878368.29523.1.camel@mtksdaap41>
On 27/08/2019 05:59, Bibby Hsieh wrote:
> On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
>>
>> On 20/08/2019 10:49, Bibby Hsieh wrote:
>>> GCE cannot know the register base address, this function
>>> can help cmdq client to get the cmdq_client_reg structure.
>>>
>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>> ---
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
>>> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
>>> 2 files changed, 50 insertions(+)
>>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index c53f8476c68d..80f75a1075b4 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -27,6 +27,35 @@ struct cmdq_instruction {
>>> u8 op;
>>> };
>>>
>>> +int cmdq_dev_get_client_reg(struct device *dev,
>>> + struct cmdq_client_reg *client_reg, int idx)
>>> +{
>>
>> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
>> properties we have and allocating these using a pointer to cmdq_client_reg in
>> cmdq_client?
>> We will have to free the pointer then in cmdq_mbox_destroy.
>>
>> Regards,
>> Matthias
>
> I don't think we need to keep the cmdq_client_reg in cmdq_client
> structure.
> Because our client will have own data structure, they will copy the
> client_reg information into their own structure.
>
> In the design now, we do not allocate the cmdq_client_reg, client pass
> the cmdq_client_reg pointer into this API.
> Client will destroy the pointer after they get the information they
> want.
>
My point wasn't so much about the lifecycle of the object, but the fact that we
add another call, which can be already full-filled by a necessary previous call
to cmdq_mbox_create. So I would prefer to add the information gathering for
cmdq_client_reg in this call, and let it live there for the time cmdq_client
lives. In the end we are talking about 40 bits of memory.
Regards,
Matthias
> Thanks for the comments so much.
>
> Bibby
>
>>
>>> + struct of_phandle_args spec;
>>> + int err;
>>> +
>>> + if (!client_reg)
>>> + return -ENOENT;
>>> +
>>> + err = of_parse_phandle_with_fixed_args(dev->of_node,
>>> + "mediatek,gce-client-reg",
>>> + 3, idx, &spec);
>>> + if (err < 0) {
>>> + dev_err(dev,
>>> + "error %d can't parse gce-client-reg property (%d)",
>>> + err, idx);
>>> +
>>> + return err;
>>> + }
>>> +
>>> + client_reg->subsys = (u8)spec.args[0];
>>> + client_reg->offset = (u16)spec.args[1];
>>> + client_reg->size = (u16)spec.args[2];
>>> + of_node_put(spec.np);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
>>> +
>>> static void cmdq_client_timeout(struct timer_list *t)
>>> {
>>> struct cmdq_client *client = from_timer(client, t, timer);
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index a345870a6d10..02ddd60b212f 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -15,6 +15,12 @@
>>>
>>> struct cmdq_pkt;
>>>
>>> +struct cmdq_client_reg {
>>> + u8 subsys;
>>> + u16 offset;
>>> + u16 size;
>>> +};
>>> +
>>> struct cmdq_client {
>>> spinlock_t lock;
>>> u32 pkt_cnt;
>>> @@ -24,6 +30,21 @@ struct cmdq_client {
>>> u32 timeout_ms; /* in unit of microsecond */
>>> };
>>>
>>> +/**
>>> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
>>> + * node of CMDQ client
>>> + * @dev: device of CMDQ mailbox client
>>> + * @client_reg: CMDQ client reg pointer
>>> + * @idx: the index of desired reg
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + *
>>> + * Help CMDQ client parsing the cmdq client reg
>>> + * from the device node of CMDQ client.
>>> + */
>>> +int cmdq_dev_get_client_reg(struct device *dev,
>>> + struct cmdq_client_reg *client_reg, int idx);
>>> +
>>> /**
>>> * cmdq_mbox_create() - create CMDQ mailbox client and channel
>>> * @dev: device of CMDQ mailbox client
>>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Chen-Yu Tsai @ 2019-08-27 10:28 UTC (permalink / raw)
To: Code Kipper
Cc: Linux-ALSA, linux-kernel, Maxime Ripard, Liam Girdwood,
Andrea Venturi (pers), linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <CAEKpxBn3g2hFaei6thAnAHX4nemrs9c_xWp1GheMfMS6+TJ7gQ@mail.gmail.com>
On Tue, Aug 27, 2019 at 4:35 PM Code Kipper <codekipper@gmail.com> wrote:
>
> On Tue, 27 Aug 2019 at 10:01, Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > On Tue, Aug 27, 2019 at 1:55 PM Code Kipper <codekipper@gmail.com> wrote:
> > >
> > > On Tue, 27 Aug 2019 at 06:13, Chen-Yu Tsai <wens@csie.org> wrote:
> > > >
> > > > On Tue, Aug 27, 2019 at 2:07 AM <codekipper@gmail.com> wrote:
> > > > >
> > > > > From: Marcus Cooper <codekipper@gmail.com>
> > > > >
> > > > > The regmap configuration is set up for the legacy block on the
> > > > > A83T whereas it uses the new block with a larger register map.
> > > >
> > > > Looking at the code Allwinner previously released [1], that doesn't seem to be
> > > > the case. Keep in mind that the register map shown in the user manual is for
> > > > the TDM interface, which we don't actually support right now.
> > >
> > > Should it matter what we support right now?, the block according to the user
> > > manual shows the bigger range. I don't have a A83T device and from what I
> >
> > There are a total of four I2S controllers on the A83T. Currently three of them
> > are listed in the dtsi file, which are _not_ the one shown in the user manual.
> > The one shown is the fourth one, which is the TDM controller.
>
> The configuration for the A83T suggests that it's a mixture of old and
> new which I don't
> think is the case considering it was released around the same time as
> the H3. There
> is enough similarity between the blocks for it to still work. For
> example on the H6
> we referenced by mistake the H3 block and we still got audio (with
> only slight distortion).
The difference with the A83T here is large enough that if you play anything
it will simply stall. I already reported it as broken and Maxime has sent
fixes.
> I would suggest to validate all of the i2s blocks we need to test
> using the internal loopback
> as that will also cover capture.
>
> >
> > It's not like we haven't seen this before. IIRC the A64 also had two variants
> > of the I2S interface. The one coupled with the audio codec was different from
> > the others.
>
> Yes...but the i2s of the audio codec was documented in the audio codec
> section. I've used
> this device to ensure that I've not broken anything in the old block
> with these new changes.
>
> >
> > > gather not many users do. But the compatible for the H3 has been removed
> > > and replaced with the settings for the A83T which also has default settings in
> > > registers further up than SUNXI_RXCHMAP.
> >
> > I'll sync up with Maxime on this.
> >
> > > >
> > > > The file shows the base address as 0x01c22800, and the last defined register
> > > > is SUNXI_RXCHMAP at 0x3c.
> > > >
> > > > The I2S driver [2] also shows that it is the old register map size, but with
> > > > TX_FIFO and INT_STA swapped around. This might mean that it would need a
> > > > separate regmap_config, as the read/write callbacks need to be changed to
> > > > fit the swapped registers.
> > > >
> > > > Finally, the TDM driver [3], which matches the TDM section in the manual, shows
> > > > a larger register map.
> > > >
> > > > A83T is SUN8IW6, while SUN8IW7 refers to the H3.
> > >
> > > Since when have we trusted Allwinner code?, the TDM labelled block
> > > clearly supports
> >
> > Since they haven't listed the I2S block in the user manual, so that is what we
> > have to go by.
> >
> > The TDM section in the user manual only lists the block at 0x1c23000. The memory
> > map says DAUDIO-[012] for addresses 0x1c22000, 0x1c22400, 0x1c22800, and TDM for
> > address 0x1c23000. One would assume this meant these are somewhat different.
> >
> > > I2S. The biggest use case for this block is getting HDMI audio working
> > > on the newer
> >
> > I understand that.
> >
> > > devices(LibreELEC nightlies has a user base of over 300) and I've tested this on
> > > numerous set ups over the last couple of years.
> >
> > Tested on the H3, correct?
>
> Yes....but only with the additional changes for multi-channel with my
> LibreELEC build.
> These changes I tested on my pine64 before pushing upstream.
>
> >
> > > Failing that reverting (3e9acd7ac693: "ASoC: sun4i-i2s: Remove
> > > duplicated quirks structure")
> > > would help.
> >
> > I'll take a look. IIRC it worked with the old layout, with the two registers
> > swapped, playing standard 48 KHz / 16 bit audio when I added supported for
> > the A83T. Then again maybe the stars were perfectly aligned. At the very least
> > we could separate A83T and H3 as you suggested.
Maxime has sent a patch reverting the merger.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] fdt: Update CRC check for rng-seed
From: Hsin-Yi Wang @ 2019-08-27 10:33 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel, Geert Uytterhoeven
Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32
from early_init_dt_verify() to early_init_dt_scan() since
early_init_dt_scan_chosen() may modify fdt to erase rng-seed.
However, arm and some other arch won't call early_init_dt_scan(), they
call early_init_dt_verify() then early_init_dt_scan_nodes().
Restore of_fdt_crc32 to early_init_dt_verify() then update it in
early_init_dt_scan_chosen() if fdt if updated.
Fixes: 428826f5358c ("fdt: add support for rng-seed")
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
drivers/of/fdt.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 7d97ab6d0e31..223d617ecfe1 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1086,6 +1086,10 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
/* try to clear seed so it won't be found. */
fdt_nop_property(initial_boot_params, node, "rng-seed");
+
+ /* update CRC check value */
+ of_fdt_crc32 = crc32_be(~0, initial_boot_params,
+ fdt_totalsize(initial_boot_params));
}
/* break now */
@@ -1176,6 +1180,8 @@ bool __init early_init_dt_verify(void *params)
/* Setup flat device-tree pointer */
initial_boot_params = params;
+ of_fdt_crc32 = crc32_be(~0, initial_boot_params,
+ fdt_totalsize(initial_boot_params));
return true;
}
@@ -1205,8 +1211,6 @@ bool __init early_init_dt_scan(void *params)
return false;
early_init_dt_scan_nodes();
- of_fdt_crc32 = crc32_be(~0, initial_boot_params,
- fdt_totalsize(initial_boot_params));
return true;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Mark Brown @ 2019-08-27 10:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: alsa-devel, lgirdwood, linux-kernel, codekipper, Chen-Yu Tsai,
linux-arm-kernel
In-Reply-To: <20190827093206.17919-1-mripard@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 547 bytes --]
On Tue, Aug 27, 2019 at 11:32:05AM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
>
> It turns out that while one I2S controller is described in the A83t
> datasheet, the driver supports another, undocumented, one that has been
> inherited from the older SoCs, while the documented one uses the new
> design.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- 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: Applied "ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs" to the asoc tree
From: Mark Brown @ 2019-08-27 10:46 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Linux-ALSA, Maxime Ripard, linux-kernel, Maxime Ripard,
Liam Girdwood, Marcus Cooper, linux-arm-kernel
In-Reply-To: <CAGb2v64vzcZbXqfW27cgobpQ-AXQjb2zanqotAR0ezw+6KCdpw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 809 bytes --]
On Tue, Aug 27, 2019 at 05:25:21PM +0800, Chen-Yu Tsai wrote:
> > From: Marcus Cooper <codekipper@gmail.com>
> The authorship of this patch looks to be wrong. Maybe it's a tooling issue.
> I imagine it might have happened if Maxime created the patches using
> `git format-patch` with his @bootlin.com address, then sent them with his
> @kernel.org address, and `git send-email` swapped out the "From:" header
> and prepended it to the body.
No idea. In any case it's kind of hard to fix at this point
since there's a merge in the way. This is why I like using
branches for things but Linus doesn't :/
> Either way the "From:" line looks odd in the commit log.
This is what git format-patch does when sending stuff via e-mail
if the author is different from the sender, it uses that to
override things.
[-- 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 3/8] coresight: etm4x: Add missing API to set EL match on address filters
From: Mike Leach @ 2019-08-27 10:55 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Coresight ML, linux-arm-kernel, Suzuki K. Poulose
In-Reply-To: <20190826225949.GC24690@xps15>
Hi Mathieu,
On Mon, 26 Aug 2019 at 23:59, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:15PM +0100, Mike Leach wrote:
> > TRCACATRn registers have match bits for secure and non-secure exception
> > levels which are not accessible by the sysfs API.
> > This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../coresight/coresight-etm4x-sysfs.c | 39 +++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index fa1d6a938f6c..7eab5d7d0b62 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1233,6 +1233,44 @@ static ssize_t addr_context_store(struct device *dev,
> > }
> > static DEVICE_ATTR_RW(addr_context);
> >
> > +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + val = BMVAL(config->addr_acc[idx], 14, 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8] */
> > + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> > + config->addr_acc[idx] |= (val << 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> > +
> > static ssize_t seq_idx_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > @@ -2038,6 +2076,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> > &dev_attr_addr_stop.attr,
> > &dev_attr_addr_ctxtype.attr,
> > &dev_attr_addr_context.attr,
> > + &dev_attr_addr_exlevel_s_ns.attr,
> > &dev_attr_seq_idx.attr,
> > &dev_attr_seq_state.attr,
> > &dev_attr_seq_event.attr,
>
> I'm ok with this patch but the new entry needs to be documented in [1].
It is in a later patch.
> But
> before moving forward with that I'm wondering if this is the way to go. Would
> it be better to consolidate type, ctxtype, context and exlevel_s_ns in a single
> entry, say addr_acc_type? We'd shed a fair amount of code and make it more
> simple for users to configure.
>
It will mean the user has less writes to do - but is it really simpler
to understand?
At present each feature takes the input value and interprets / shifts
it to set the relevant bits in the address comparator control
registers (context type being a string input rather than bit values).
The alternative is to require the user to understand the bit values -
which they may well do if they are referring to the ETM docs to
program in this detail, and provide a correct input value for their
requirements.
My addition adds to the API, rather than changes it, but if you prefer
we could go with an update to a single feature to control this value
in the comparator control registers.
Mike
>
> [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
>
> > --
> > 2.17.1
> >
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 2/3] ASoC: sun4i-i2s: Add regmap field to sign extend sample
From: Code Kipper @ 2019-08-27 10:55 UTC (permalink / raw)
To: Maxime Ripard
Cc: Linux-ALSA, linux-sunxi, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), Chen-Yu Tsai, Mark Brown, linux-arm-kernel
In-Reply-To: <20190827093429.fkh4cqbygxxyvkk3@flea>
On Tue, 27 Aug 2019 at 11:34, Maxime Ripard <mripard@kernel.org> wrote:
>
> On Mon, Aug 26, 2019 at 08:07:33PM +0200, codekipper@gmail.com wrote:
> > From: Marcus Cooper <codekipper@gmail.com>
> >
> > On the newer SoCs such as the H3 and A64 this is set by default
> > to transfer a 0 after each sample in each slot. However the A10
> > and A20 SoCs that this driver was developed on had a default
> > setting where it padded the audio gain with zeros.
> >
> > This isn't a problem whilst we have only support for 16bit audio
> > but with larger sample resolution rates in the pipeline then SEXT
> > bits should be cleared so that they also pad at the LSB. Without
> > this the audio gets distorted.
> >
> > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
>
> If anything, I'd like to have less regmap_fields rather than more of
> them. This is pretty easy to add to one of the callbacks, especially
> since the field itself has been completely reworked from one
> generation to the other.
>
ACK
That's fine....I've been doing that with the patches which follow this.
CK
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.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: Changing default kernel load address
From: Mark Rutland @ 2019-08-27 11:02 UTC (permalink / raw)
To: Noam Camus; +Cc: linux-arm-kernel
In-Reply-To: <CABhetiwRF2Gq3HeG_QNT6t3GtCNJzedeenn6vQC_0FYr5Ee+mA@mail.gmail.com>
On Mon, Aug 26, 2019 at 08:12:27PM +0300, Noam Camus wrote:
> Hi,
>
> I wish to change an arm64 machine kernel load address and I hope this
> forum can assist.
>
> In my current setup the KERNEL_START macro (_text) equals 128.5MB:
> KIMAGE_VADDR=128MB
> TEXT_OFFSET=512KB
>
> I wish to change kernel load address to reside on my internal RAM
> which locates beyond 4GB.
You shouldn't need to modify anything; the kernel can be loaded at any
2MiB-aligned physical address + TEXT_OFFSET. KERNEL_START and
KIMAGE_VADDR are virtual addresses and don't require a specific physical
address.
Please see:
https://www.kernel.org/doc/html/latest/arm64/booting.html
> Can someone tell what changes I need to do so kernel load address will
> be above 4GB.
>
> Note: I use FIT image to provide U-Boot the kernel Load address.
I don't know how FIT works, but the U-Boot "booti" command should do the
right thing if given an arm64 kernel Image.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BOOTWRAPPER PATCH] Enable TME for lower exception levels
From: Mark Rutland @ 2019-08-27 11:08 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel
In-Reply-To: <20190823145015.15974-1-will@kernel.org>
On Fri, Aug 23, 2019 at 03:50:15PM +0100, Will Deacon wrote:
> By default, TME is not available to exception levels below EL3, so
> enable it in SCR_EL3 if we detect that it is implemented.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Applied, thanks!
Mark.
> ---
> arch/aarch64/boot.S | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index 74705cded338..c2fe92c90297 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -48,6 +48,13 @@ _start:
> orr x0, x0, #(1 << 16) // AP key enable
> orr x0, x0, #(1 << 17) // AP insn enable
> 1:
> + /* Enable TME if present */
> + mrs x1, id_aa64isar0_el1
> + ubfx x1, x1, #24, #4
> + cbz x1, 1f
> +
> + orr x0, x0, #(1 << 34) // TME enable
> +1:
> #ifndef KERNEL_32
> orr x0, x0, #(1 << 10) // 64-bit EL2
> #endif
> --
> 2.11.0
>
_______________________________________________
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