* Re: [PATCH v2] treewide, serdev: change receive_buf() return type to size_t
From: patchwork-bot+chrome-platform @ 2024-03-25 1:54 UTC (permalink / raw)
To: Francesco Dolcini
Cc: gregkh, jirislaby, linux-bluetooth, linux-mediatek, linux-kernel,
linux-arm-kernel, greybus-dev, linux-iio, netdev, chrome-platform,
platform-driver-x86, linux-serial, linux-sound, francesco.dolcini,
luiz.dentz, johan, elder, jic23, lee, kuba, pabeni, edumazet,
davem, krzysztof.kozlowski, hdegoede, ilpo.jarvinen, bleung,
tzungbi, robh, Jonathan.Cameron
In-Reply-To: <20240122180551.34429-1-francesco@dolcini.it>
Hello:
This patch was applied to chrome-platform/linux.git (for-kernelci)
by Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
On Mon, 22 Jan 2024 19:05:51 +0100 you wrote:
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
>
> receive_buf() is called from ttyport_receive_buf() that expects values
> ">= 0" from serdev_controller_receive_buf(), change its return type from
> ssize_t to size_t.
>
> The need for this clean-up was noticed while fixing a warning, see
> commit 94d053942544 ("Bluetooth: btnxpuart: fix recv_buf() return value").
> Changing the callback prototype to return an unsigned seems the best way
> to document the API and ensure that is properly used.
>
> [...]
Here is the summary with links:
- [v2] treewide, serdev: change receive_buf() return type to size_t
https://git.kernel.org/chrome-platform/c/fed99212acae
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
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 04/14] drm/mediatek: Add DRM_MODE_ROTATE_0 to rotation property
From: CK Hu (胡俊光) @ 2024-03-25 1:52 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Bibby Hsieh (謝濟遠),
jason-ch.chen@mediatek.corp-partner.google.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, sean@poorly.run, matthias.bgg@gmail.com,
fshao@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <a5b00d343b922e726476e4b3c1973d44a05aacb3.camel@mediatek.com>
Hi, Shawn:
On Fri, 2024-03-22 at 17:02 +0800, CK Hu wrote:
> Hi, Shawn:
>
> On Fri, 2024-03-22 at 13:28 +0800, Shawn Sung wrote:
> > From: Hsiao Chien Sung <shawn.sung@mediatek.com>
> >
> > Always add DRM_MODE_ROTATE_0 to rotation property to meet
> > IGT's (Intel GPU Tools) requirement.
>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> >
> > Reviewed-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delregno@collabora.com>
> > Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 6 +++++-
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 21 +++++++++------------
> > drivers/gpu/drm/mediatek/mtk_plane.c | 2 +-
> > 3 files changed, 15 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> > b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> > index 26236691ce4c2..f7fe2e08dc8e2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> > @@ -192,7 +192,11 @@ unsigned int
> > mtk_ddp_comp_supported_rotations(struct mtk_ddp_comp *comp)
> > if (comp->funcs && comp->funcs->supported_rotations)
> > return comp->funcs->supported_rotations(comp->dev);
> >
> > - return 0;
> > + /*
> > + * In order to pass IGT tests, DRM_MODE_ROTATE_0 is required
> > when
> > + * rotation is not supported.
> > + */
> > + return DRM_MODE_ROTATE_0;
> > }
> >
> > static inline unsigned int mtk_ddp_comp_layer_nr(struct
> > mtk_ddp_comp
> > *comp)
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 0ebeaf9830d83..2a767a823c83a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -288,6 +288,10 @@ unsigned int mtk_ovl_layer_nr(struct device
> > *dev)
> >
> > unsigned int mtk_ovl_supported_rotations(struct device *dev)
> > {
> > + /*
> > + * although currently OVL can only do reflection,
> > + * reflect x + reflect y = rotate 180
> > + */
Sorry, this comment is not related to DRM_MODE_ROTATE_0, so after
removing this comment,
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
> > DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
> > }
> > @@ -296,27 +300,20 @@ int mtk_ovl_layer_check(struct device *dev,
> > unsigned int idx,
> > struct mtk_plane_state *mtk_state)
> > {
> > struct drm_plane_state *state = &mtk_state->base;
> > - unsigned int rotation = 0;
> >
> > - rotation = drm_rotation_simplify(state->rotation,
> > - DRM_MODE_ROTATE_0 |
> > - DRM_MODE_REFLECT_X |
> > - DRM_MODE_REFLECT_Y);
> > - rotation &= ~DRM_MODE_ROTATE_0;
> > -
> > - /* We can only do reflection, not rotation */
> > - if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
> > + /* check if any unsupported rotation is set */
> > + if (state->rotation & ~mtk_ovl_supported_rotations(dev))
> > return -EINVAL;
> >
> > /*
> > * TODO: Rotating/reflecting YUV buffers is not supported at
> > this time.
> > * Only RGB[AX] variants are supported.
> > + * Since DRM_MODE_ROTATE_0 means "no rotation", we
> > should not
> > + * reject layers with this property.
> > */
> > - if (state->fb->format->is_yuv && rotation != 0)
> > + if (state->fb->format->is_yuv && (state->rotation &
> > ~DRM_MODE_ROTATE_0))
> > return -EINVAL;
> >
> > - state->rotation = rotation;
> > -
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c
> > b/drivers/gpu/drm/mediatek/mtk_plane.c
> > index a74b26d359857..1723d4333f371 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_plane.c
> > @@ -338,7 +338,7 @@ int mtk_plane_init(struct drm_device *dev,
> > struct
> > drm_plane *plane,
> > return err;
> > }
> >
> > - if (supported_rotations & ~DRM_MODE_ROTATE_0) {
> > + if (supported_rotations) {
> > err = drm_plane_create_rotation_property(plane,
> > DRM_MODE_ROTAT
> > E_0,
> > supported_rota
> > tions);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch
From: Mark Brown @ 2024-03-25 0:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, kvm, James Morse, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, James Clark, Anshuman Khandual,
Dongli Zhang
In-Reply-To: <20240322170945.3292593-6-maz@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 461 bytes --]
On Fri, Mar 22, 2024 at 05:09:45PM +0000, Marc Zyngier wrote:
> In retrospect, it is fairly obvious that the FP state ownership
> is only meaningful for a given CPU, and that locating this
> information in the vcpu was just a mistake.
>
> Move the ownership tracking into the host data structure, and
> rename it from fp_state to fp_owner, which is a better description
> (name suggested by Mark Brown).
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- 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 v2 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch
From: Mark Brown @ 2024-03-25 0:27 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, kvm, James Morse, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, James Clark, Anshuman Khandual,
Dongli Zhang
In-Reply-To: <87edc0sr7z.wl-maz@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1635 bytes --]
On Sat, Mar 23, 2024 at 07:06:24PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > There's still the thing with the interaction with SME support - to
> > summarise what I think you're asking for the userspace ABI there:
> Well, the SME support is still pretty prospective, and this patch has
> no impact on an existing ABI.
Sure, hopefully I should have a new verison out this release - it was
mostly held up waiting for the ID register parsing framework you got
merged last release. Though holidays do make things a bit tight timing
wise.
> > - Add support for the V registers in the sysreg interface when SVE is
> > enabled.
> We already support the V registers with KVM_REG_ARM_CORE_REG(). Why
> would you add any new interface for this? The kernel should be
> perfectly capable of dealing with the placement of the data in the
> internal structures, and there is no need to tie the userspace ABI to
> how we deal with that placement (kvm_regs is already purely
> userspace).
This was referring to the fact that currently when SVE is enabled access
to the V registers as V registers via _CORE_REG() is blocked and they
can only be accessed as a subset of the Z registers (see the check at
the end of core_reg_size_from_offset() in guest.c).
> > then the implementation can do what it likes to achieve that, the most
> > obvious thing being to store in native format for the current hardware
> > mode based on SVCR.{SM,ZA}. Does that sound about right?
> Apart from the statement about the V registers, this seems OK. But
> again, I want to see this agreed with the QEMU folks.
Great, thanks.
[-- 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: Re: [PATCH 0/0] (proposed?) Add ACPI binding to Rockchip RK3xxx I2C bus
From: Shimrra Shai @ 2024-03-25 0:26 UTC (permalink / raw)
To: jonathan.cameron
Cc: heiko, linux-arm-kernel, linux-kernel, linux-rockchip,
max.schwarz, niyas.sait, shimmyshai00
In-Reply-To: <20240322103521.00001a12@Huawei.com>
Hey Jonathan,
Since I haven't heard a reply from you so far, and I've also done some more
research on the ClockInput options and stuff I'm soon going to ask the
firmware developers to commit the following updated ACPI bindings unless I
get comment there is still something wrong with them. I'm posting about it
here because this is going to have to be the base for any revisions to
these kernel patches I propose later and so I really want to make sure I
get both "sides" of this right (i.e. both the firmware and kernel). If I
don't hear back within a few days I'm going to just send this as-is and
see if it gets accepted by the firmware team.
Note also that the kernel CRU driver currently won't be able to do anything
with all the info in the CRU binding right now, but the UEFI firmware also
pre-initializes the unit so it isn't super necessary I think, I just
thought to add the binding so it can be referenced elsewhere in the tables.
I believe this is the "proper" way from comparing the descriptions of the
ClockInput tag and "clocks" DTB option; the DTB clocks options all
reference the CRU (which makes sense from description of the physical
hardware itself), so I am fairly confident this is "best", but if anyone
objects on this side I still want to hear it as soon as possible.
ACPI binding for the CRU:
Device (CRU_) {
/* coining a new _HID is unnecessary so long as compatible string exists */
Name (_CID, "PRP0001")
Name (_UID, 0)
Name (_CCA, 0)
Method (_CRS, 0x0, Serialized) {
Name (RBUF, ResourceTemplate() {
Memory32Fixed (ReadWrite, 0xfd7c0000, 0x5c000)
ClockInput (1100000000, 1, Hz, Fixed, "CLK0", 0)
ClockInput (786432000, 1, Hz, Fixed, "CLK1", 0)
ClockInput (850000000, 1, Hz, Fixed, "CLK2", 0)
ClockInput (1188000000, 1, Hz, Fixed, "CLK3", 0)
ClockInput (702000000, 1, Hz, Fixed, "CLK4", 0)
ClockInput (400000000, 1, Hz, Fixed, "CLK5", 0)
ClockInput (500000000, 1, Hz, Fixed, "CLK6", 0)
ClockInput (800000000, 1, Hz, Fixed, "CLK7", 0)
ClockInput (100000000, 1, Hz, Fixed, "CLK8", 0)
ClockInput (400000000, 1, Hz, Fixed, "CLK9", 0)
ClockInput (100000000, 1, Hz, Fixed, "CLKA", 0)
ClockInput (200000000, 1, Hz, Fixed, "CLKB", 0)
ClockInput (500000000, 1, Hz, Fixed, "CLKC", 0)
ClockInput (375000000, 1, Hz, Fixed, "CLKD", 0)
ClockInput (150000000, 1, Hz, Fixed, "CLKE", 0)
ClockInput (200000000, 1, Hz, Fixed, "CLKF", 0)
})
Return (RBUF)
}
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "rockchip,rk3588-cru" },
}
})
// PLL_PPLL
Device (CLK0) {
Name (_ADR, 0x0)
}
// PLL_AUPLL
Device (CLK1) {
Name (_ADR, 0x1)
}
// PLL_NPLL
Device (CLK2) {
Name (_ADR, 0x2)
}
// PLL_GPLL
Device (CLK3) {
Name (_ADR, 0x3)
}
// ACLK_CENTER_ROOT
Device (CLK4) {
Name (_ADR, 0x4)
}
// HCLK_CENTER_ROOT
Device (CLK5) {
Name (_ADR, 0x5)
}
// ACLK_CENTER_LOW_ROOT
Device (CLK6) {
Name (_ADR, 0x6)
}
// ACLK_TOP_ROOT
Device (CLK7) {
Name (_ADR, 0x7)
}
// PCLK_TOP_ROOT
Device (CLK8) {
Name (_ADR, 0x8)
}
// ACLK_LOW_TOP_ROOT
Device (CLK9) {
Name (_ADR, 0x9)
}
// PCLK_PMU0_ROOT
Device (CLKA) {
Name (_ADR, 0xa)
}
// HCLK_PMU_CM0_ROOT
Device (CLKB) {
Name (_ADR, 0xb)
}
// ACLK_VOP
Device (CLKC) {
Name (_ADR, 0xc)
}
// ACLK_BUS_ROOT
Device (CLKD) {
Name (_ADR, 0xd)
}
// CLK_150M_SRC
Device (CLKE) {
Name (_ADR, 0xe)
}
// CLK_GPU
Device (CLKF) {
Name (_ADR, 0xf)
}
}
ACPI bindings for I2C (I2C1 as example):
Device (I2C1) {
Name (_HID, "RKCP3001")
/* _CID is no longer required */
Name (_UID, 1)
Name (_CCA, 0)
Method (_CRS, 0x0, Serialized) {
Name (RBUF, ResourceTemplate() {
Memory32Fixed (ReadWrite, 0xfea90000, 0x1000)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 350 }
ClockInput (198000000, 1, Hz, Fixed, "\_SB_.CRU_", PCLK_I2C1)
ClockInput (198000000, 1, Hz, Fixed, "\_SB_.CRU_", BCLK_I2C1)
})
Return (RBUF)
}
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "#address-cells", 1 },
Package (2) { "#size-cells", 0 },
}
})
}
---
Shimmy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4.19 138/148] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324235012.1356413-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b5845f16a3a26..199cc39459198 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1719,7 +1719,8 @@ config RTC_DRV_MOXART
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 5.4 165/183] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324234638.1355609-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0ad8d84aeb339..22638878c9819 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1811,7 +1811,8 @@ config RTC_DRV_MOXART
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 5.10 214/238] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324234027.1354210-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 54cf5ec8f4019..8ddd334e049e1 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1833,7 +1833,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 5.15 283/317] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:34 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324233458.1352854-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e1bc5214494e2..ee59c82f9df18 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1814,7 +1814,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 6.1 396/451] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324231207.1351418-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index bb63edb507da4..87dc050ca004c 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1843,7 +1843,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 6.6 569/638] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 23:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324230116.1348576-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d7502433c78aa..92f46a6312c24 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1832,7 +1832,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 6.6 443/638] perf print-events: make is_event_supported() more robust
From: Sasha Levin @ 2024-03-24 22:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mark Rutland, Ian Rogers, James Clark, Marc Zyngier,
Hector Martin, John Garry, Leo Yan, Mike Leach, Suzuki K Poulose,
Thomas Richter, Will Deacon, linux-arm-kernel, Namhyung Kim,
Sasha Levin
In-Reply-To: <20240324230116.1348576-1-sashal@kernel.org>
From: Mark Rutland <mark.rutland@arm.com>
[ Upstream commit 25412c0364f7110faa6053c73e3fd47ca956b8c3 ]
Currently the perf tool doesn't detect support for extended event types
on Apple M1/M2 systems, and will not auto-expand plain PERF_EVENT_TYPE
hardware events into per-PMU events. This is due to the detection of
extended event types not handling mandatory filters required by the
M1/M2 PMU driver.
PMU drivers and the core perf_events code can require that
perf_event_attr::exclude_* filters are configured in a specific way and
may reject certain configurations of filters, for example:
(a) Many PMUs lack support for any event filtering, and require all
perf_event_attr::exclude_* bits to be clear. This includes Alpha's
CPU PMU, and ARM CPU PMUs prior to the introduction of PMUv2 in
ARMv7,
(b) When /proc/sys/kernel/perf_event_paranoid >= 2, the perf core
requires that perf_event_attr::exclude_kernel is set.
(c) The Apple M1/M2 PMU requires that perf_event_attr::exclude_guest is
set as the hardware PMU does not count while a guest is running (but
might be extended in future to do so).
In is_event_supported(), we try to account for cases (a) and (b), first
attempting to open an event without any filters, and if this fails,
retrying with perf_event_attr::exclude_kernel set. We do not account for
case (c), or any other filters that drivers could theoretically require
to be set.
Thus is_event_supported() will fail to detect support for any events
targeting an Apple M1/M2 PMU, even where events would be supported with
perf_event_attr:::exclude_guest set.
Since commit:
82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
... we use is_event_supported() to detect support for extended types,
with the PMU ID encoded into the perf_event_attr::type. As above, on an
Apple M1/M2 system this will always fail to detect that the event is
supported, and consequently we fail to detect support for extended types
even when these are supported, as they have been since commit:
5c816728651ae425 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
Due to this, the perf tool will not automatically expand plain
PERF_TYPE_HARDWARE events into per-PMU events, even when all the
necessary kernel support is present.
This patch updates is_event_supported() to additionally try opening
events with perf_event_attr::exclude_guest set, allowing support for
events to be detected on Apple M1/M2 systems. I believe that this is
sufficient for all contemporary CPU PMU drivers, though in future it may
be necessary to check for other combinations of filter bits.
I've deliberately changed the check to not expect a specific error code
for missing filters, as today ;the kernel may return a number of
different error codes for missing filters (e.g. -EACCESS, -EINVAL, or
-EOPNOTSUPP) depending on why and where the filter configuration is
rejected, and retrying for any error is more robust.
Note that this does not remove the need for commit:
a24d9d9dc096fc0d ("perf parse-events: Make legacy events lower priority than sysfs/JSON")
... which is still necessary so that named-pmu/event/ events work on
kernels without extended type support, even if the event name happens to
be the same as a PERF_EVENT_TYPE_HARDWARE event (e.g. as is the case for
the M1/M2 PMU's 'cycles' and 'instructions' events).
Fixes: 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@arm.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Cc: Hector Martin <marcan@marcan.st>
Cc: James Clark <james.clark@arm.com>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Leo Yan <leo.yan@linux.dev>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240126145605.1005472-1-mark.rutland@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/util/print-events.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/print-events.c b/tools/perf/util/print-events.c
index a7566edc86a3e..9bee082194d5e 100644
--- a/tools/perf/util/print-events.c
+++ b/tools/perf/util/print-events.c
@@ -232,7 +232,6 @@ void print_sdt_events(const struct print_callbacks *print_cb, void *print_state)
bool is_event_supported(u8 type, u64 config)
{
bool ret = true;
- int open_return;
struct evsel *evsel;
struct perf_event_attr attr = {
.type = type,
@@ -246,20 +245,32 @@ bool is_event_supported(u8 type, u64 config)
evsel = evsel__new(&attr);
if (evsel) {
- open_return = evsel__open(evsel, NULL, tmap);
- ret = open_return >= 0;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
- if (open_return == -EACCES) {
+ if (!ret) {
/*
- * This happens if the paranoid value
+ * The event may fail to open if the paranoid value
* /proc/sys/kernel/perf_event_paranoid is set to 2
- * Re-run with exclude_kernel set; we don't do that
- * by default as some ARM machines do not support it.
- *
+ * Re-run with exclude_kernel set; we don't do that by
+ * default as some ARM machines do not support it.
*/
evsel->core.attr.exclude_kernel = 1;
ret = evsel__open(evsel, NULL, tmap) >= 0;
}
+
+ if (!ret) {
+ /*
+ * The event may fail to open if the PMU requires
+ * exclude_guest to be set (e.g. as the Apple M1 PMU
+ * requires).
+ * Re-run with exclude_guest set; we don't do that by
+ * default as it's equally legitimate for another PMU
+ * driver to require that exclude_guest is clear.
+ */
+ evsel->core.attr.exclude_guest = 1;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
+ }
+
evsel__delete(evsel);
}
--
2.43.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 6.7 633/713] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 22:45 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324224720.1345309-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 3814e0845e772..b1e1d277d4593 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1832,7 +1832,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 6.7 495/713] perf print-events: make is_event_supported() more robust
From: Sasha Levin @ 2024-03-24 22:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mark Rutland, Ian Rogers, James Clark, Marc Zyngier,
Hector Martin, John Garry, Leo Yan, Mike Leach, Suzuki K Poulose,
Thomas Richter, Will Deacon, linux-arm-kernel, Namhyung Kim,
Sasha Levin
In-Reply-To: <20240324224720.1345309-1-sashal@kernel.org>
From: Mark Rutland <mark.rutland@arm.com>
[ Upstream commit 25412c0364f7110faa6053c73e3fd47ca956b8c3 ]
Currently the perf tool doesn't detect support for extended event types
on Apple M1/M2 systems, and will not auto-expand plain PERF_EVENT_TYPE
hardware events into per-PMU events. This is due to the detection of
extended event types not handling mandatory filters required by the
M1/M2 PMU driver.
PMU drivers and the core perf_events code can require that
perf_event_attr::exclude_* filters are configured in a specific way and
may reject certain configurations of filters, for example:
(a) Many PMUs lack support for any event filtering, and require all
perf_event_attr::exclude_* bits to be clear. This includes Alpha's
CPU PMU, and ARM CPU PMUs prior to the introduction of PMUv2 in
ARMv7,
(b) When /proc/sys/kernel/perf_event_paranoid >= 2, the perf core
requires that perf_event_attr::exclude_kernel is set.
(c) The Apple M1/M2 PMU requires that perf_event_attr::exclude_guest is
set as the hardware PMU does not count while a guest is running (but
might be extended in future to do so).
In is_event_supported(), we try to account for cases (a) and (b), first
attempting to open an event without any filters, and if this fails,
retrying with perf_event_attr::exclude_kernel set. We do not account for
case (c), or any other filters that drivers could theoretically require
to be set.
Thus is_event_supported() will fail to detect support for any events
targeting an Apple M1/M2 PMU, even where events would be supported with
perf_event_attr:::exclude_guest set.
Since commit:
82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
... we use is_event_supported() to detect support for extended types,
with the PMU ID encoded into the perf_event_attr::type. As above, on an
Apple M1/M2 system this will always fail to detect that the event is
supported, and consequently we fail to detect support for extended types
even when these are supported, as they have been since commit:
5c816728651ae425 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
Due to this, the perf tool will not automatically expand plain
PERF_TYPE_HARDWARE events into per-PMU events, even when all the
necessary kernel support is present.
This patch updates is_event_supported() to additionally try opening
events with perf_event_attr::exclude_guest set, allowing support for
events to be detected on Apple M1/M2 systems. I believe that this is
sufficient for all contemporary CPU PMU drivers, though in future it may
be necessary to check for other combinations of filter bits.
I've deliberately changed the check to not expect a specific error code
for missing filters, as today ;the kernel may return a number of
different error codes for missing filters (e.g. -EACCESS, -EINVAL, or
-EOPNOTSUPP) depending on why and where the filter configuration is
rejected, and retrying for any error is more robust.
Note that this does not remove the need for commit:
a24d9d9dc096fc0d ("perf parse-events: Make legacy events lower priority than sysfs/JSON")
... which is still necessary so that named-pmu/event/ events work on
kernels without extended type support, even if the event name happens to
be the same as a PERF_EVENT_TYPE_HARDWARE event (e.g. as is the case for
the M1/M2 PMU's 'cycles' and 'instructions' events).
Fixes: 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@arm.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Cc: Hector Martin <marcan@marcan.st>
Cc: James Clark <james.clark@arm.com>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Leo Yan <leo.yan@linux.dev>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240126145605.1005472-1-mark.rutland@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/util/print-events.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/print-events.c b/tools/perf/util/print-events.c
index b0fc48be623f3..4f67e8f00a4d6 100644
--- a/tools/perf/util/print-events.c
+++ b/tools/perf/util/print-events.c
@@ -232,7 +232,6 @@ void print_sdt_events(const struct print_callbacks *print_cb, void *print_state)
bool is_event_supported(u8 type, u64 config)
{
bool ret = true;
- int open_return;
struct evsel *evsel;
struct perf_event_attr attr = {
.type = type,
@@ -246,20 +245,32 @@ bool is_event_supported(u8 type, u64 config)
evsel = evsel__new(&attr);
if (evsel) {
- open_return = evsel__open(evsel, NULL, tmap);
- ret = open_return >= 0;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
- if (open_return == -EACCES) {
+ if (!ret) {
/*
- * This happens if the paranoid value
+ * The event may fail to open if the paranoid value
* /proc/sys/kernel/perf_event_paranoid is set to 2
- * Re-run with exclude_kernel set; we don't do that
- * by default as some ARM machines do not support it.
- *
+ * Re-run with exclude_kernel set; we don't do that by
+ * default as some ARM machines do not support it.
*/
evsel->core.attr.exclude_kernel = 1;
ret = evsel__open(evsel, NULL, tmap) >= 0;
}
+
+ if (!ret) {
+ /*
+ * The event may fail to open if the PMU requires
+ * exclude_guest to be set (e.g. as the Apple M1 PMU
+ * requires).
+ * Re-run with exclude_guest set; we don't do that by
+ * default as it's equally legitimate for another PMU
+ * driver to require that exclude_guest is clear.
+ */
+ evsel->core.attr.exclude_guest = 1;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
+ }
+
evsel__delete(evsel);
}
--
2.43.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 6.8 627/715] rtc: mt6397: select IRQ_DOMAIN instead of depending on it
From: Sasha Levin @ 2024-03-24 22:33 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Randy Dunlap, Arnd Bergmann, Eddie Huang, Sean Wang,
Matthias Brugger, linux-arm-kernel, linux-mediatek,
Alessandro Zummo, Alexandre Belloni, linux-rtc, Marc Zyngier,
Philipp Zabel, Peter Rosin, AngeloGioacchino Del Regno,
Sasha Levin
In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 544c42f798e1651dcb04fb0395219bf0f1c2607e ]
IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
it directly thru "make *config", so drivers should select it instead
of depending on it if they need it.
Relying on it being set for a dependency is risky.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on" for IRQ_DOMAIN to
"select" for RTC_DRV_MT6397.
Fixes: 04d3ba70a3c9 ("rtc: mt6397: add IRQ domain dependency")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eddie Huang <eddie.huang@mediatek.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Peter Rosin <peda@axentia.se>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e37a4341f442d..c63e32d012f23 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1858,7 +1858,8 @@ config RTC_DRV_MT2712
config RTC_DRV_MT6397
tristate "MediaTek PMIC based RTC"
- depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
+ depends on MFD_MT6397 || COMPILE_TEST
+ select IRQ_DOMAIN
help
This selects the MediaTek(R) RTC driver. RTC is part of MediaTek
MT6397 PMIC. You should enable MT6397 PMIC MFD before select
--
2.43.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 6.8 464/715] perf print-events: make is_event_supported() more robust
From: Sasha Levin @ 2024-03-24 22:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mark Rutland, Ian Rogers, James Clark, Marc Zyngier,
Hector Martin, John Garry, Leo Yan, Mike Leach, Suzuki K Poulose,
Thomas Richter, Will Deacon, linux-arm-kernel, Namhyung Kim,
Sasha Levin
In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org>
From: Mark Rutland <mark.rutland@arm.com>
[ Upstream commit 25412c0364f7110faa6053c73e3fd47ca956b8c3 ]
Currently the perf tool doesn't detect support for extended event types
on Apple M1/M2 systems, and will not auto-expand plain PERF_EVENT_TYPE
hardware events into per-PMU events. This is due to the detection of
extended event types not handling mandatory filters required by the
M1/M2 PMU driver.
PMU drivers and the core perf_events code can require that
perf_event_attr::exclude_* filters are configured in a specific way and
may reject certain configurations of filters, for example:
(a) Many PMUs lack support for any event filtering, and require all
perf_event_attr::exclude_* bits to be clear. This includes Alpha's
CPU PMU, and ARM CPU PMUs prior to the introduction of PMUv2 in
ARMv7,
(b) When /proc/sys/kernel/perf_event_paranoid >= 2, the perf core
requires that perf_event_attr::exclude_kernel is set.
(c) The Apple M1/M2 PMU requires that perf_event_attr::exclude_guest is
set as the hardware PMU does not count while a guest is running (but
might be extended in future to do so).
In is_event_supported(), we try to account for cases (a) and (b), first
attempting to open an event without any filters, and if this fails,
retrying with perf_event_attr::exclude_kernel set. We do not account for
case (c), or any other filters that drivers could theoretically require
to be set.
Thus is_event_supported() will fail to detect support for any events
targeting an Apple M1/M2 PMU, even where events would be supported with
perf_event_attr:::exclude_guest set.
Since commit:
82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
... we use is_event_supported() to detect support for extended types,
with the PMU ID encoded into the perf_event_attr::type. As above, on an
Apple M1/M2 system this will always fail to detect that the event is
supported, and consequently we fail to detect support for extended types
even when these are supported, as they have been since commit:
5c816728651ae425 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability")
Due to this, the perf tool will not automatically expand plain
PERF_TYPE_HARDWARE events into per-PMU events, even when all the
necessary kernel support is present.
This patch updates is_event_supported() to additionally try opening
events with perf_event_attr::exclude_guest set, allowing support for
events to be detected on Apple M1/M2 systems. I believe that this is
sufficient for all contemporary CPU PMU drivers, though in future it may
be necessary to check for other combinations of filter bits.
I've deliberately changed the check to not expect a specific error code
for missing filters, as today ;the kernel may return a number of
different error codes for missing filters (e.g. -EACCESS, -EINVAL, or
-EOPNOTSUPP) depending on why and where the filter configuration is
rejected, and retrying for any error is more robust.
Note that this does not remove the need for commit:
a24d9d9dc096fc0d ("perf parse-events: Make legacy events lower priority than sysfs/JSON")
... which is still necessary so that named-pmu/event/ events work on
kernels without extended type support, even if the event name happens to
be the same as a PERF_EVENT_TYPE_HARDWARE event (e.g. as is the case for
the M1/M2 PMU's 'cycles' and 'instructions' events).
Fixes: 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Ian Rogers <irogers@google.com>
Tested-by: James Clark <james.clark@arm.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Cc: Hector Martin <marcan@marcan.st>
Cc: James Clark <james.clark@arm.com>
Cc: John Garry <john.g.garry@oracle.com>
Cc: Leo Yan <leo.yan@linux.dev>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240126145605.1005472-1-mark.rutland@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/perf/util/print-events.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/print-events.c b/tools/perf/util/print-events.c
index 9e47712507cc2..b14d1a894abce 100644
--- a/tools/perf/util/print-events.c
+++ b/tools/perf/util/print-events.c
@@ -232,7 +232,6 @@ void print_sdt_events(const struct print_callbacks *print_cb, void *print_state)
bool is_event_supported(u8 type, u64 config)
{
bool ret = true;
- int open_return;
struct evsel *evsel;
struct perf_event_attr attr = {
.type = type,
@@ -246,20 +245,32 @@ bool is_event_supported(u8 type, u64 config)
evsel = evsel__new(&attr);
if (evsel) {
- open_return = evsel__open(evsel, NULL, tmap);
- ret = open_return >= 0;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
- if (open_return == -EACCES) {
+ if (!ret) {
/*
- * This happens if the paranoid value
+ * The event may fail to open if the paranoid value
* /proc/sys/kernel/perf_event_paranoid is set to 2
- * Re-run with exclude_kernel set; we don't do that
- * by default as some ARM machines do not support it.
- *
+ * Re-run with exclude_kernel set; we don't do that by
+ * default as some ARM machines do not support it.
*/
evsel->core.attr.exclude_kernel = 1;
ret = evsel__open(evsel, NULL, tmap) >= 0;
}
+
+ if (!ret) {
+ /*
+ * The event may fail to open if the PMU requires
+ * exclude_guest to be set (e.g. as the Apple M1 PMU
+ * requires).
+ * Re-run with exclude_guest set; we don't do that by
+ * default as it's equally legitimate for another PMU
+ * driver to require that exclude_guest is clear.
+ */
+ evsel->core.attr.exclude_guest = 1;
+ ret = evsel__open(evsel, NULL, tmap) >= 0;
+ }
+
evsel__delete(evsel);
}
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/3] rockchip: small DTS fixes for RK3399 Puma
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Rob Herring, Conor Dooley, Krzysztof Kozlowski, Quentin Schulz
Cc: Heiko Stuebner, Dragan Simic, linux-kernel, linux-rockchip,
devicetree, Quentin Schulz, linux-arm-kernel, Klaus Goger
In-Reply-To: <20240308-puma-diode-pu-v2-0-309f83da110a@theobroma-systems.com>
On Fri, 08 Mar 2024 16:46:06 +0100, Quentin Schulz wrote:
> There's a pull-up missing on a pin that is used as GPIO input for PCIe
> which will make the diode/level-shifter not let voltage pass and thus
> not allowing the state of the pin to change.
>
> Also add the missing regulators for the PCIe PHY+connector though this
> is purely cosmetic.
>
> [...]
Applied, thanks!
[1/3] arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 Puma
commit: e6b1168f37e3f86d9966276c5a3fff9eb0df3e5f
[2/3] arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma
commit: 945a7c8570916650a415757d15d83e0fa856a686
[3/3] arm64: dts: rockchip: add regulators for PCIe on RK3399 Puma Haikou
commit: d7ed698abc28b2886c9fc71d17ca6b023fcf47f3
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Iskander Amara, krzysztof.kozlowski+dt, linux-kernel,
linux-rockchip, conor+dt, angelogioacchino.delregno, devicetree,
robh+dt, linux-arm-kernel, dsimic, alexander.stein,
vahe.grigoryan
Cc: Heiko Stuebner, quentin.schulz
In-Reply-To: <20240308085243.69903-1-iskander.amara@theobroma-systems.com>
On Fri, 8 Mar 2024 09:52:42 +0100, Iskander Amara wrote:
> Q7_THRM# pin is connected to a diode on the module which is used
> as a level shifter, and the pin have a pull-down enabled by
> default. We need to configure it to internal pull-up, other-
> wise whenever the pin is configured as INPUT and we try to
> control it externally the value will always remain zero.
>
>
> [...]
Applied, thanks!
[1/2] arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
commit: 0ac417b8f124427c90ec8c2ef4f632b821d924cc
[2/2] arm64: dts: rockchip: fix alphabetical ordering RK3399 puma
commit: f0abb4b2c7acf3c3e4130dc3f54cd90cf2ae62bc
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] arm64: dts: rockchip: Add cache information to the SoC dtsi for RK356x
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Dragan Simic, linux-rockchip
Cc: Heiko Stuebner, Anand Moon, krzysztof.kozlowski+dt,
Diederik de Haas, conor+dt, devicetree, robh+dt, linux-arm-kernel
In-Reply-To: <2dee6dad8460b0c5f3b5da53cf55f735840efef1.1709957777.git.dsimic@manjaro.org>
On Sat, 9 Mar 2024 05:25:06 +0100, Dragan Simic wrote:
> Add missing cache information to the Rockchip RK356x SoC dtsi, to allow
> the userspace, which includes lscpu(1) that uses the virtual files provided
> by the kernel under the /sys/devices/system/cpu directory, to display the
> proper RK3566 and RK3568 cache information.
>
> Adding the cache information to the RK356x SoC dtsi also makes the following
> warning message in the kernel log go away:
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: Add cache information to the SoC dtsi for RK356x
commit: 8612169a05c5e979af033868b7a9b177e0f9fcdf
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] arm64: dts: rockchip: set PHY address of MT7531 switch to 0x1f
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Arınç ÜNAL, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Heiko Stuebner, linux-kernel, linux-rockchip, devicetree,
linux-arm-kernel, erkin.bozoglu, mithat.guner
In-Reply-To: <20240314-for-rockchip-mt7531-phy-address-v1-1-743b5873358f@arinc9.com>
On Thu, 14 Mar 2024 15:24:35 +0300, Arınç ÜNAL wrote:
> The MT7531 switch listens on PHY address 0x1f on an MDIO bus. I've got two
> findings that support this. There's no bootstrapping option to change the
> PHY address of the switch. The Linux driver hardcodes 0x1f as the PHY
> address of the switch. So the reg property on the device tree is currently
> ignored by the Linux driver.
>
> Therefore, describe the correct PHY address on Banana Pi BPI-R2 Pro that
> has this switch.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: set PHY address of MT7531 switch to 0x1f
commit: a2ac2a1b02590a22a236c43c455f421cdede45f5
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] arm64: dts: rockchip: Add cache information to the SoC dtsi for RK3328
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Dragan Simic, linux-rockchip
Cc: Heiko Stuebner, krzysztof.kozlowski+dt, Anand Moon, conor+dt,
didi.debian, devicetree, robh+dt, linux-arm-kernel
In-Reply-To: <a681b3c6dbf7b25b1527b11cea5ae0d6d1733714.1709958234.git.dsimic@manjaro.org>
On Sat, 9 Mar 2024 05:24:42 +0100, Dragan Simic wrote:
> Add missing cache information to the Rockchip RK3328 SoC dtsi, to allow
> the userspace, which includes lscpu(1) that uses the virtual files provided
> by the kernel under the /sys/devices/system/cpu directory, to display the
> proper RK3328 cache information.
>
> While there, use a more self-descriptive label for the L2 cache node, which
> also makes it more consistent with other SoC dtsi files.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: Add cache information to the SoC dtsi for RK3328
commit: 67a6a98575974416834c2294853b3814376a7ce7
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi CM5
From: Heiko Stuebner @ 2024-03-24 22:38 UTC (permalink / raw)
To: Andy Yan
Cc: Heiko Stuebner, krzysztof.kozlowski+dt, linux-kernel,
linux-rockchip, conor+dt, devicetree, linux-arm-kernel, dsimic
In-Reply-To: <20240324112833.2181961-1-andyshrk@163.com>
On Sun, 24 Mar 2024 19:28:33 +0800, Andy Yan wrote:
> According to the hardware design, the i2c address of audio codec es8316
> on Cool Pi CM5 is 0x10.
>
> This fix the read/write error like bellow:
> es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x0000000c] -6
> es8316 7-0011: ASoC: error at soc_component_write_no_lock on es8316.7-0011 for register: [0x00000003] -6
> es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6
> es8316 7-0011: ASoC: error at soc_component_read_no_lock on es8316.7-0011 for register: [0x00000016] -6
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: Fix the i2c address of es8316 on Cool Pi CM5
commit: 64da060dd4eb625646970d7c96a16de617412ec5
I've also adapted the node-name accordingly.
I.e. audio-codec@10 to reflect the fixed address.
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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 4/4] arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Marco Felsch, Marek Vasut,
Gregor Herburger, Hugo Villeneuve, Joao Paulo Goncalves,
Markus Niebel, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Philippe Schenker, Josua Mayer, Li Yang, devicetree, linux-kernel,
linux-mmc, linux-arm-kernel, linux-serial
In-Reply-To: <20240324214329.29988-1-wafgo01@gmail.com>
This commit adds device tree support for the NXP S32G3-based
S32G-VNP-RDB3 Board [1].
The S32G3 features an 8-core ARM Cortex-A53 based SoC developed by NXP.
The device tree files are derived from the official NXP downstream
Linux tree [2].
This addition encompasses a limited selection of peripherals that
are upstream-supported. Apart from the ARM System Modules
(GIC, Generic Timer, etc.), the following IPs have been validated:
* UART: fsl-linflexuart
* SDHC: fsl-imx-esdhc
Clock settings for the chip rely on ATF Firmware [3].
Pin control integration into the device tree is pending and currently
relies on Firmware/U-Boot settings [4].
These changes were validated using BSP39 Firmware/U-Boot from NXP [5].
The modifications enable booting the official Ubuntu 22.04 from NXP on
the RDB3 with default settings from the SD card and eMMC.
[1] https://www.nxp.com/design/design-center/designs/s32g3-vehicle-networking-reference-design:S32G-VNP-RDB3
[2] https://github.com/nxp-auto-linux/linux
[3] https://github.com/nxp-auto-linux/arm-trusted-firmware
[4] https://github.com/nxp-auto-linux/u-boot
[5] https://github.com/nxp-auto-linux/auto_yocto_bsp
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/s32g3.dtsi | 233 ++++++++++++++++++
.../boot/dts/freescale/s32g399a-rdb3.dts | 45 ++++
3 files changed, 279 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/s32g3.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2cb0212b63c6..e701008dbc7b 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -252,3 +252,4 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw74xx-rpidsi.dtb
dtb-$(CONFIG_ARCH_S32) += s32g274a-evb.dtb
dtb-$(CONFIG_ARCH_S32) += s32g274a-rdb2.dtb
dtb-$(CONFIG_ARCH_S32) += s32v234-evb.dtb
+dtb-$(CONFIG_ARCH_S32) += s32g399a-rdb3.dtb
diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
new file mode 100644
index 000000000000..c1b08992754b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright 2021-2023 NXP
+ *
+ * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
+ * Ciprian Costea <ciprianmarian.costea@nxp.com>
+ * Andra-Teodora Ilie <andra.ilie@nxp.com>
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "nxp,s32g3";
+ interrupt-parent = <&gic>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+
+ core2 {
+ cpu = <&cpu2>;
+ };
+
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+
+ core1 {
+ cpu = <&cpu5>;
+ };
+
+ core2 {
+ cpu = <&cpu6>;
+ };
+
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x2>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x3>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x100>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x101>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu6: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x102>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+
+ cpu7: cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x103>;
+ enable-method = "psci";
+ clocks = <&dfs 0>;
+ };
+ };
+
+ firmware {
+ scmi: scmi {
+ compatible = "arm,scmi-smc";
+ shmem = <&scmi_shmem>;
+ arm,smc-id = <0xc20000fe>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dfs: protocol@13 {
+ reg = <0x13>;
+ #clock-cells = <1>;
+ };
+
+ clks: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ scmi_shmem: shm@d0000000 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0xd0000000 0x0 0x80>;
+ no-map;
+ };
+ };
+
+ soc@0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0x80000000>;
+
+ uart0: serial@401c8000 {
+ compatible = "nxp,s32g3-linflexuart",
+ "fsl,s32v234-linflexuart";
+ reg = <0x401c8000 0x3000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ uart1: serial@401cc000 {
+ compatible = "nxp,s32g3-linflexuart",
+ "fsl,s32v234-linflexuart";
+ reg = <0x401cc000 0x3000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ uart2: serial@402bc000 {
+ compatible = "nxp,s32g3-linflexuart",
+ "fsl,s32v234-linflexuart";
+ reg = <0x402bc000 0x3000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+
+ usdhc0: mmc@402f0000 {
+ compatible = "nxp,s32g3-usdhc",
+ "nxp,s32g2-usdhc";
+ reg = <0x402f0000 0x1000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 32>,
+ <&clks 31>,
+ <&clks 33>;
+ clock-names = "ipg", "ahb", "per";
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@50800000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x50800000 0x10000>,
+ <0x50900000 0x200000>,
+ <0x50400000 0x2000>,
+ <0x50410000 0x2000>,
+ <0x50420000 0x2000>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* sec-phys */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* phys */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* virt */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>, /* hyp-phys */
+ <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW>; /* hyp-virt */
+ arm,no-tick-in-suspend;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts b/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
new file mode 100644
index 000000000000..9d674819876e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright 2021-2023 NXP
+ *
+ * NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3)
+ */
+
+/dts-v1/;
+
+#include "s32g3.dtsi"
+
+/ {
+ model = "NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3)";
+ compatible = "nxp,s32g399a-rdb3", "nxp,s32g3";
+
+ aliases {
+ mmc0 = &usdhc0;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ /* 4GiB RAM */
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0 0x80000000>,
+ <0x8 0x80000000 0 0x80000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&usdhc0 {
+ bus-width = <8>;
+ status = "okay";
+};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Gregor Herburger,
Marek Vasut, Marco Felsch, Hugo Villeneuve, Markus Niebel,
Matthias Schiffer, Stefan Wahren, Bjorn Helgaas, Yannic Moog,
Li Yang, devicetree, linux-kernel, linux-mmc, linux-arm-kernel,
linux-serial
In-Reply-To: <20240324214329.29988-1-wafgo01@gmail.com>
Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
driver works also on S32G3 platforms.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index 82eb7a24c857..466e7157308a 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -90,6 +90,9 @@ properties:
- enum:
- fsl,imxrt1170-usdhc
- const: fsl,imxrt1050-usdhc
+ - items:
+ - const: nxp,s32g3-usdhc
+ - const: nxp,s32g2-usdhc
reg:
maxItems: 1
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: serial: fsl-linflexuart: add compatible for S32G3
From: Wadim Mueller @ 2024-03-24 21:43 UTC (permalink / raw)
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Marco Felsch, Gregor Herburger,
Marek Vasut, Joao Paulo Goncalves, Markus Niebel,
Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Philippe Schenker, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-mmc, linux-arm-kernel, linux-serial
In-Reply-To: <20240324214329.29988-1-wafgo01@gmail.com>
Add a compatible string for the uart binding of NXP S32G3 platforms. Here
we use "s32v234-linflexuart" as fallback since the current linflexuart
driver can still work on S32G3.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
---
.../devicetree/bindings/serial/fsl,s32-linflexuart.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
index 7a105551fa6a..4171f524a928 100644
--- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
@@ -23,7 +23,9 @@ properties:
oneOf:
- const: fsl,s32v234-linflexuart
- items:
- - const: nxp,s32g2-linflexuart
+ - enum:
+ - nxp,s32g2-linflexuart
+ - nxp,s32g3-linflexuart
- const: fsl,s32v234-linflexuart
reg:
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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