* RE: About upstreaming ArmChina NPU driver
From: Dejia Shang @ 2024-04-03 9:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, Toby Huang, Chengkun Sun
In-Reply-To: <20240328103205.seht2hbog3o4giv5@bogus>
> -----Original Message-----
> From: Sudeep Holla <sudeep.holla@arm.com>
> Sent: 2024年3月28日 18:32
> To: Dejia Shang <Dejia.Shang@armchina.com>
> Cc: ogabbay@kernel.org; Sudeep Holla <sudeep.holla@arm.com>;
> airlied@redhat.com; daniel@ffwll.ch; linux-kernel@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: About upstreaming ArmChina NPU driver
>
> On Thu, Mar 28, 2024 at 07:46:01AM +0000, Dejia Shang wrote:
> > IMPORTANT NOTICE: The contents of this email and any attachments may
> > be privileged and confidential. If you are not the intended recipient,
> > please delete the email immediately. It is strictly prohibited to
> > disclose the contents to any other person, use it for any purpose, or
> > store or copy the information in any medium. Thank you. ©Arm
> > Technology (China) Co., Ltd copyright and reserve all rights.
> > 重要提示：本邮件（包括任何附件）可能含有专供明确的个人或目的
> 使用的机密信息，并受法律保护。如果您并非该收件人，请立即删除此
> 邮件。严禁通过任何
> > 渠道，以任何目的，向任何人披露、储存或复制邮件信息或者据此采
> 取任何行动。感谢您的配合。 ©安谋科技（中国）有限公司 版权所有并
> 保留一切权利。
>
> You need to get this fixed, otherwise people will delete this email as you have
> suggested and/or refrain from responding to this email.
>
> Please talk to your local IT and get a setup without this disclaimer for all
> mailing list activities.
Now fixed. I did not realize that because the server auto appended that disclaimer. Thanks for your reminder!
Best Regards,
Dejia
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Andy Shevchenko @ 2024-04-03 9:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue,
Krzysztof Kozlowski, Arnd Bergmann, Uwe Kleine-König,
linux-input, linux-stm32, linux-arm-kernel
In-Reply-To: <20240403080702.3509288-8-arnd@kernel.org>
On Wed, Apr 03, 2024 at 10:06:25AM +0200, Arnd Bergmann wrote:
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> When compile tested with W=1 on x86_64 with driver as built-in:
>
> stmpe-ts.c:371:34: error: unused variable 'stmpe_ts_ids' [-Werror,-Wunused-const-variable]
...
> -static const struct of_device_id stmpe_ts_ids[] = {
> +static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
__maybe_unused?
Why not adding it into .driver as you have done in another patch in this series?
> { .compatible = "st,stmpe-ts", },
> { },
> };
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: mediatek: vcodec: fix the error sizeimage for 10bit bitstream
From: Yunfei Dong @ 2024-04-03 9:30 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Sebastian Fricke,
Nicolas Dufresne, Hans Verkuil, AngeloGioacchino Del Regno,
Benjamin Gaignard, Nathan Hebert
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
The sizeimage of each plane are calculated the same way for 8bit and
10bit bitstream. Need to enlarge the sizeimage with simeimage*5/4 for
10bit bitstream when try and set fmt.
Fixes: 9d86be9bda6c ("media: mediatek: vcodec: Add driver to support 10bit")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 47 ++++++++++++++-----
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index 9107707de6c4..45209894f1fe 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -259,6 +259,7 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
pix_fmt_mp->num_planes = 1;
pix_fmt_mp->plane_fmt[0].bytesperline = 0;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ unsigned int dram_y, dram_c, dram_y_10bit, dram_c_10bit;
int tmp_w, tmp_h;
/*
@@ -280,22 +281,42 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
(pix_fmt_mp->height + 64) <= frmsize->max_height)
pix_fmt_mp->height += 64;
- mtk_v4l2_vdec_dbg(0, ctx,
- "before resize wxh=%dx%d, after resize wxh=%dx%d, sizeimage=%d",
- tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
- pix_fmt_mp->width * pix_fmt_mp->height);
+ dram_y = pix_fmt_mp->width * pix_fmt_mp->height;
+ dram_c = dram_y / 2;
+
+ dram_y_10bit = dram_y * 5 / 4;
+ dram_c_10bit = dram_y_10bit / 2;
pix_fmt_mp->num_planes = fmt->num_planes;
- pix_fmt_mp->plane_fmt[0].sizeimage =
- pix_fmt_mp->width * pix_fmt_mp->height;
- pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
-
- if (pix_fmt_mp->num_planes == 2) {
- pix_fmt_mp->plane_fmt[1].sizeimage =
- (pix_fmt_mp->width * pix_fmt_mp->height) / 2;
- pix_fmt_mp->plane_fmt[1].bytesperline =
- pix_fmt_mp->width;
+ if (pix_fmt_mp->num_planes == 1) {
+ if (ctx->is_10bit_bitstream) {
+ pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
+ pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit + dram_c_10bit;
+ } else {
+ pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
+ pix_fmt_mp->plane_fmt[0].sizeimage = dram_y + dram_c;
+ }
+ } else {
+ if (ctx->is_10bit_bitstream) {
+ pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
+ pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width * 5 / 4;
+
+ pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit;
+ pix_fmt_mp->plane_fmt[1].sizeimage = dram_c_10bit;
+ } else {
+ pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
+ pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width;
+
+ pix_fmt_mp->plane_fmt[0].sizeimage = dram_y;
+ pix_fmt_mp->plane_fmt[1].sizeimage = dram_c;
+ }
}
+
+ mtk_v4l2_vdec_dbg(0, ctx,
+ "before resize:%dx%d, after resize:%dx%d, sizeimage=0x%x_0x%x",
+ tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
+ pix_fmt_mp->plane_fmt[0].sizeimage,
+ pix_fmt_mp->plane_fmt[1].sizeimage);
}
pix_fmt_mp->flags = 0;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 00/18] Improve PCI memory mapping API
From: Manivannan Sadhasivam @ 2024-04-03 9:25 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <2cdc7045-e277-4d1f-ad7c-66e4ac819a41@kernel.org>
On Wed, Apr 03, 2024 at 04:58:42PM +0900, Damien Le Moal wrote:
> On 4/3/24 16:50, Manivannan Sadhasivam wrote:
> > On Sat, Mar 30, 2024 at 01:19:10PM +0900, Damien Le Moal wrote:
> >> This series introduces the new functions pci_epc_map_align(),
> >> pci_epc_mem_map() and pci_epc_mem_unmap() to improve handling of the
> >> PCI address mapping alignment constraints of endpoint controllers in a
> >> controller independent manner.
> >>
> >> The issue fixed is that the fixed alignment defined by the "align" field
> >> of struct pci_epc_features assumes that the alignment of the endpoint
> >> memory used to map a RC PCI address range is independent of the PCI
> >> address being mapped. But that is not the case for the rk3399 SoC
> >> controller: in endpoint mode, this controller uses the lower bits of the
> >> local endpoint memory address as the lower bits for the PCI addresses
> >> for data transfers. That is, when mapping local memory, one must take
> >> into account the number of bits of the RC PCI address that change from
> >> the start address of the mapping.
> >>
> >> To fix this, the new endpoint controller method .map_align is introduced
> >> and called from pci_epc_map_align(). This method is optional and for
> >> controllers that do not define it, the mapping information returned
> >> is based of the fixed alignment constraint as defined by the align
> >> feature.
> >>
> >> The functions pci_epc_mem_map() is a helper function which obtains
> >> mapping information, allocates endpoint controller memory according to
> >> the mapping size obtained and maps the memory. pci_epc_mem_map() unmaps
> >> and frees the endpoint memory.
> >>
> >> This series is organized as follows:
> >> - Patch 1 tidy up the epc core code
> >> - Patch 2 and 3 introduce the new map_align endpoint controller method
> >> and related epc functions.
> >> - Patch 4 to 6 modify the test endpoint driver to use these new
> >> functions and improve the code of this driver.
> >
> > While posting the next version, please split the endpoint patches into a
> > separate series. It helps in code review and can be applied separately.
>
> Which patches ? They are all endpoint related:
> (1) Core code
> (2) test function driver
Till patch 6, that's why I inlined my reply at the 3rd point.
> (3) rockchip rk3399 controller
>
> (2) and (3) depend on the patches in (1), so splitting the series is a big
> possible only if (1) is applied first, so that is a source of delays and breaks
> the context of the patches...
>
If you split patches 1-6 and post the rest of the Rockchip patches as a follow
up, it perfectly makes sense.
- Mani
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Shreeya Patel @ 2024-04-03 9:24 UTC (permalink / raw)
To: mchehab, hverkuil, hverkuil-cisco
Cc: heiko, robh, krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd,
p.zabel, shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <20240327225057.672304-1-shreeya.patel@collabora.com>
On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
> This series implements support for the Synopsys DesignWare
> HDMI RX Controller, being compliant with standard HDMI 1.4b
> and HDMI 2.0.
>
Hi Mauro and Hans,
I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
Thanks,
Shreeya Patel
> Features that are currently supported by the HDMI RX driver
> have been tested on rock5b board using a HDMI to micro-HDMI cable.
> It is recommended to use a good quality cable as there were
> multiple issues seen during testing the driver.
>
> Please note the below information :-
> * While testing the driver on rock5b we noticed that the binary BL31
> from Rockchip contains some unknown code to get the HDMI-RX PHY
> access working. With TF-A BL31, the HDMI-RX PHY doesn't work as
> expected since there are no interrupts seen for rk_hdmirx-hdmi
> leading to some failures in the driver [0].
> * We have tested the working of OBS studio with HDMIRX driver and
> there were no issues seen.
> * We also tested and verified the support for interlaced video.
>
> [0] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a/-/issues/1
>
> To test the HDMI RX Controller driver, following example commands can be used :-
>
> root@debian-rockchip-rock5b-rk3588:~# v4l2-ctl --verbose -d /dev/video0 \
> --set-fmt-video=width=1920,height=1080,pixelformat='BGR3' --stream-mmap=4 \
> --stream-skip=3 --stream-count=100 --stream-to=/home/hdmiin4k.raw --stream-poll
>
> root@debian-rockchip-rock5b-rk3588:~# ffmpeg -f rawvideo -vcodec rawvideo \
> -s 1920x1080 -r 60 -pix_fmt bgr24 -i /home/hdmiin4k.raw output.mkv
>
>
> Following is the v4l2-compliance test result :-
>
> root@debian-rockchip-rock5b-rk3588:~# v4l2-compliance -d /dev/video0
> v4l2-compliance 1.27.0-5174, 64 bits, 64-bit time_t
> v4l2-compliance SHA: d700deb14368 2024-01-18 12:19:05
>
> Compliance test for snps_hdmirx device /dev/video0:
>
> Driver Info:
> Driver name : snps_hdmirx
> Card type : snps_hdmirx
> Bus info : platform: snps_hdmirx
> Driver version : 6.8.0
> Capabilities : 0x84201000
> Video Capture Multiplanar
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04201000
> Video Capture Multiplanar
> Streaming
> Extended Pix Format
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> test invalid ioctls: OK
>
> Allow for multiple opens:
> test second /dev/video0 open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
>
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
>
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
>
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
>
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
> test VIDIOC_DV_TIMINGS_CAP: OK
> test VIDIOC_G/S_EDID: OK
>
> Control ioctls (Input 0):
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 2 Private Controls: 0
>
> Format ioctls (Input 0):
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not Supported)
>
> Codec ioctls (Input 0):
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>
> Buffer ioctls (Input 0):
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test CREATE_BUFS maximum buffers: OK
> test VIDIOC_EXPBUF: OK
> test Requests: OK (Not Supported)
>
> Total for snps_hdmirx device /dev/video0: 46, Succeeded: 46, Failed: 0, Warnings: 0
>
> Changes in v3 :-
> - Use v4l2-common helpers in the HDMIRX driver
> - Rename cma node and phandle names
> - Elaborate the comment to explain 160MiB calculation
> - Move &hdmi_receiver_cma to the rock5b dts file
> - Add information about interlaced video testing in the
> cover-letter
>
> Changes in v2 :-
> - Fix checkpatch --strict warnings
> - Move the dt-binding include file changes in a separate patch
> - Add a description for the hardware in the dt-bindings file
> - Rename resets, vo1 grf and HPD properties
> - Add a proper description for grf and vo1-grf phandles in the
> bindings
> - Rename the HDMI RX node name to hdmi-receiver
> - Include gpio header file in binding example to fix the
> dt_binding_check failure
> - Move hdmirx_cma node to the rk3588.dtsi file
> - Add an entry to MAINTAINERS file for the HDMIRX driver
>
> Shreeya Patel (6):
> dt-bindings: reset: Define reset id used for HDMI Receiver
> clk: rockchip: rst-rk3588: Add reset line for HDMI Receiver
> dt-bindings: media: Document HDMI RX Controller
> arm64: dts: rockchip: Add device tree support for HDMI RX Controller
> media: platform: synopsys: Add support for hdmi input driver
> MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver
>
> .../bindings/media/snps,dw-hdmi-rx.yaml | 132 +
> MAINTAINERS | 8 +
> .../boot/dts/rockchip/rk3588-pinctrl.dtsi | 41 +
> .../boot/dts/rockchip/rk3588-rock-5b.dts | 19 +
> arch/arm64/boot/dts/rockchip/rk3588.dtsi | 56 +
> drivers/clk/rockchip/rst-rk3588.c | 1 +
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 1 +
> drivers/media/platform/synopsys/Kconfig | 3 +
> drivers/media/platform/synopsys/Makefile | 2 +
> .../media/platform/synopsys/hdmirx/Kconfig | 18 +
> .../media/platform/synopsys/hdmirx/Makefile | 4 +
> .../platform/synopsys/hdmirx/snps_hdmirx.c | 2726 +++++++++++++++++
> .../platform/synopsys/hdmirx/snps_hdmirx.h | 394 +++
> .../synopsys/hdmirx/snps_hdmirx_cec.c | 289 ++
> .../synopsys/hdmirx/snps_hdmirx_cec.h | 46 +
> .../dt-bindings/reset/rockchip,rk3588-cru.h | 2 +
> 17 files changed, 3743 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> create mode 100644 drivers/media/platform/synopsys/Kconfig
> create mode 100644 drivers/media/platform/synopsys/Makefile
> create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
> create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
>
> --
> 2.39.2
>
> _______________________________________________
> Kernel mailing list -- kernel@mailman.collabora.com
> To unsubscribe send an email to kernel-leave@mailman.collabora.com
> This list is managed by https://mailman.collabora.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] GPIO regression fixes for n8x0
From: Tony Lindgren @ 2024-04-03 9:22 UTC (permalink / raw)
To: soc
Cc: arm, linux-omap, linux-arm-kernel, Tony Lindgren, Aaro Koskinen,
Linus Walleij, Ulf Hansson
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v6.9/n8x0-fixes-signed
for you to fetch changes up to 4421405e3634a3189b541cf1e34598e44260720d:
ARM: OMAP2+: fix USB regression on Nokia N8x0 (2024-03-08 11:02:38 +0200)
Sorry this got delayed a bit as I had some SSD issue, please feel free
to merge whenever suitable.
----------------------------------------------------------------
GPIO regression fixes for n8x0
A series of fixes for n8x0 GPIO regressions caused by the changes to use
GPIO descriptors.
----------------------------------------------------------------
Aaro Koskinen (6):
ARM: OMAP2+: fix bogus MMC GPIO labels on Nokia N8x0
ARM: OMAP2+: fix N810 MMC gpiod table
mmc: omap: fix broken slot switch lookup
mmc: omap: fix deferred probe
mmc: omap: restore original power up/down steps
ARM: OMAP2+: fix USB regression on Nokia N8x0
arch/arm/mach-omap2/board-n8x0.c | 23 +++++++++----------
drivers/mmc/host/omap.c | 48 ++++++++++++++++++++++++++--------------
2 files changed, 41 insertions(+), 30 deletions(-)
_______________________________________________
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 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Manivannan Sadhasivam @ 2024-04-03 9:21 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <eb580d64-1110-479a-9a0b-c2f1eacd23e7@kernel.org>
On Wed, Apr 03, 2024 at 04:54:32PM +0900, Damien Le Moal wrote:
> On 4/3/24 16:45, Manivannan Sadhasivam wrote:
> > On Sat, Mar 30, 2024 at 01:19:12PM +0900, Damien Le Moal wrote:
> >> Some endpoint controllers have requirements on the alignment of the
> >> controller physical memory address that must be used to map a RC PCI
> >> address region. For instance, the rockchip endpoint controller uses
> >> at most the lower 20 bits of a physical memory address region as the
> >> lower bits of an RC PCI address. For mapping a PCI address region of
> >> size bytes starting from pci_addr, the exact number of address bits
> >> used is the number of address bits changing in the address range
> >> [pci_addr..pci_addr + size - 1].
> >>
> >> For this example, this creates the following constraints:
> >> 1) The offset into the controller physical memory allocated for a
> >> mapping depends on the mapping size *and* the starting PCI address
> >> for the mapping.
> >> 2) A mapping size cannot exceed the controller windows size (1MB) minus
> >> the offset needed into the allocated physical memory, which can end
> >> up being a smaller size than the desired mapping size.
> >>
> >> Handling these constraints independently of the controller being used in
> >> a PCI EP function driver is not possible with the current EPC API as
> >> it only provides the ->align field in struct pci_epc_features.
> >> Furthermore, this alignment is static and does not depend on a mapping
> >> pci address and size.
> >>
> >> Solve this by introducing the function pci_epc_map_align() and the
> >> endpoint controller operation ->map_align to allow endpoint function
> >> drivers to obtain the size and the offset into a controller address
> >> region that must be used to map an RC PCI address region. The size
> >> of the physical address region provided by pci_epc_map_align() can then
> >> be used as the size argument for the function pci_epc_mem_alloc_addr().
> >> The offset into the allocated controller memory can be used to
> >> correctly handle data transfers. Of note is that pci_epc_map_align() may
> >> indicate upon return a mapping size that is smaller (but not 0) than the
> >> requested PCI address region size. For such case, an endpoint function
> >> driver must handle data transfers in fragments.
> >>
> >
> > Is there any incentive in exposing pci_epc_map_align()? I mean, why can't it be
> > hidden inside the new alloc() API itself?
>
> I could drop pci_epc_map_align(), but the idea here was to have an API that is
> not restrictive. E.g., a function driver could allocate memory, keep it and
> repetedly use map_align and map() function to remap it to different PCI
> addresses. With your suggestion, that would not be possible.
>
Is there any requirement currently? If not, let's try to introduce it when the
actual requirement comes.
> >
> > Furthermore, is it possible to avoid the map_align() callback and handle the
> > alignment within the EPC driver?
>
> I am not so sure that this is possible because handling the alignment can
> potentially result in changing the amount of memory to allocate, based on the
> PCI address also. So the allocation API would need to change, a lot.
>
Hmm, looking at patch 11/18, I think it might become complicated.
- Mani
> >> + /*
> >> + * Assume a fixed alignment constraint as specified by the controller
> >> + * features.
> >> + */
> >> + features = pci_epc_get_features(epc, func_no, vfunc_no);
> >> + if (!features || !features->align) {
> >> + map->map_pci_addr = pci_addr;
> >> + map->map_size = size;
> >> + map->map_ofst = 0;
> >
> > These values are overwritten anyway below.
>
> Looks like "return" got dropped. Bug. Will re-add it.
>
>
> --
> Damien Le Moal
> Western Digital Research
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
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 3/4] dt-bindings: watchdog: aspeed-wdt: Add aspeed,scu
From: PeterYin @ 2024-04-03 9:18 UTC (permalink / raw)
To: Andrew Jeffery, Rob Herring
Cc: patrick, Wim Van Sebroeck, Guenter Roeck, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-watchdog, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <ab76b0549172cf3e33d6242fa9ea3e6a87b4a58e.camel@codeconstruct.com.au>
Thanks, I can wait you update it and send a new version for wdt driver.
Andrew Jeffery 於 4/2/24 20:09 寫道:
> I had a patch converting it in a local branch which I've now sent:
>
> https://lore.kernel.org/all/20240402120118.282035-1-andrew@codeconstruct.com.au/
>
> Perhaps we can pull it into this series?
_______________________________________________
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 32/34] ASoC: remove incorrect of_match_ptr/ACPI_PTR annotations
From: Andy Shevchenko @ 2024-04-03 9:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexandre Belloni, Akihiko Odaki, Kuninori Morimoto,
Linus Walleij, alsa-devel, linux-kernel, Srinivas Kandagatla,
Sylwester Nawrocki, Claudiu Beznea, Rob Herring, Yinchuan Guo,
Takashi Iwai, Uwe Kleine-König, Arnd Bergmann, linux-sound,
Alper Nebi Yasak, Mark Brown, Jaroslav Kysela, linux-arm-kernel,
AngeloGioacchino Del Regno, Oder Chiou, Liam Girdwood,
Krzysztof Kozlowski, Banajit Goswami
In-Reply-To: <20240403080702.3509288-33-arnd@kernel.org>
On Wed, Apr 03, 2024 at 10:06:50AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When building with CONFIG_OF and/or CONFIG_ACPI disabled but W=1 extra
> warnings enabled, a lot of driver cause a warning about an unused
> ID table:
>
> sound/soc/atmel/sam9x5_wm8731.c:187:34: error: unused variable 'sam9x5_wm8731_of_match' [-Werror,-Wunused-const-variable]
> sound/soc/codecs/rt5514-spi.c:496:34: error: unused variable 'rt5514_of_match' [-Werror,-Wunused-const-variable]
> sound/soc/samsung/aries_wm8994.c:524:34: error: unused variable 'samsung_wm8994_of_match' [-Werror,-Wunused-const-variable]
>
> The fix is always to just remove the of_match_ptr() and ACPI_PTR() wrappers
> that remove the reference, rather than adding another #ifdef just for build
> testing for a configuration that doesn't matter in practice.
...
> index d6cdb6d9fdd6..ffc105759994 100644
> --- a/sound/soc/amd/acp3x-rt5682-max9836.c
> +++ b/sound/soc/amd/acp3x-rt5682-max9836.c
> @@ -543,7 +543,7 @@ MODULE_DEVICE_TABLE(acpi, acp3x_audio_acpi_match);
> static struct platform_driver acp3x_audio = {
> .driver = {
> .name = "acp3x-alc5682-max98357",
> - .acpi_match_table = ACPI_PTR(acp3x_audio_acpi_match),
> + .acpi_match_table = acp3x_audio_acpi_match,
> .pm = &snd_soc_pm_ops,
> },
> .probe = acp3x_probe,
Replace acpi_match_device() by device_get_match_data() and acpi.h by
mod_devicetable.h + property.h.
I really would like to see agnostic drivers (when they don't need of*.h/acpi.h
to be included as "proxy" headers).
With this, the change probably needs to be separated from this patch.
If you address as suggested,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
The rest I haven't checked, it might be possible to do something similar there
as well.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 32/34] ASoC: remove incorrect of_match_ptr/ACPI_PTR annotations
From: Krzysztof Kozlowski @ 2024-04-03 9:06 UTC (permalink / raw)
To: Arnd Bergmann, linux-kernel, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Claudiu Beznea, Nicolas Ferre,
Alexandre Belloni, Oder Chiou, Srinivas Kandagatla,
Banajit Goswami, Sylwester Nawrocki
Cc: Arnd Bergmann, Alper Nebi Yasak, Kuninori Morimoto, Akihiko Odaki,
Linus Walleij, Yinchuan Guo, Uwe Kleine-König, Rob Herring,
AngeloGioacchino Del Regno, linux-sound, alsa-devel,
linux-arm-kernel
In-Reply-To: <20240403080702.3509288-33-arnd@kernel.org>
On 03/04/2024 10:06, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When building with CONFIG_OF and/or CONFIG_ACPI disabled but W=1 extra
> warnings enabled, a lot of driver cause a warning about an unused
> ID table:
>
> sound/soc/atmel/sam9x5_wm8731.c:187:34: error: unused variable 'sam9x5_wm8731_of_match' [-Werror,-Wunused-const-variable]
> sound/soc/codecs/rt5514-spi.c:496:34: error: unused variable 'rt5514_of_match' [-Werror,-Wunused-const-variable]
> sound/soc/samsung/aries_wm8994.c:524:34: error: unused variable 'samsung_wm8994_of_match' [-Werror,-Wunused-const-variable]
>
> The fix is always to just remove the of_match_ptr() and ACPI_PTR() wrappers
> that remove the reference, rather than adding another #ifdef just for build
> testing for a configuration that doesn't matter in practice.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/amd/acp3x-rt5682-max9836.c | 2 +-
> sound/soc/atmel/sam9x5_wm8731.c | 2 +-
> sound/soc/codecs/rt5514-spi.c | 2 +-
> sound/soc/qcom/lpass-sc7280.c | 2 +-
> sound/soc/samsung/aries_wm8994.c | 2 +-
I sent it already as well:
https://lore.kernel.org/all/20230310214333.274903-5-krzysztof.kozlowski@linaro.org/
and Mark did not pick it up, I guess for the same reason as SPI.
Best regards,
Krzysztof
_______________________________________________
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 31/34] spi: remove incorrect of_match_ptr annotations
From: Krzysztof Kozlowski @ 2024-04-03 9:05 UTC (permalink / raw)
To: Arnd Bergmann, linux-kernel, Mark Brown, Neil Armstrong,
Kevin Hilman, Heiko Stuebner, Andi Shyti
Cc: Arnd Bergmann, Jerome Brunet, Martin Blumenstingl, Alim Akhtar,
Li Zetao, Jonathan Cameron, Rob Herring, Yang Yingliang,
Andy Shevchenko, Luis de Arquer, Tudor Ambarus, Sam Protsenko,
Peter Griffin, Jaewon Kim, linux-spi, linux-arm-kernel,
linux-amlogic, linux-rockchip, linux-samsung-soc
In-Reply-To: <20240403080702.3509288-32-arnd@kernel.org>
On 03/04/2024 10:06, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When building with CONFIG_OF disabled but W=1 extra warnings enabled,
> a couple of driver cause a warning about an unused ID table:
>
> drivers/spi/spi-armada-3700.c:806:34: error: unused variable 'a3700_spi_dt_ids' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-orion.c:614:34: error: unused variable 'orion_spi_of_match_table' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-pic32-sqi.c:673:34: error: unused variable 'pic32_sqi_of_ids' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-pic32.c:850:34: error: unused variable 'pic32_spi_of_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-rockchip.c:1020:34: error: unused variable 'rockchip_spi_dt_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-s3c64xx.c:1642:34: error: unused variable 's3c64xx_spi_dt_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-st-ssc4.c:439:34: error: unused variable 'stm_spi_match' [-Werror,-Wunused-const-variable]
>
> These appear to all be copied from the same original driver, so fix them at the
> same time by removing the unnecessary of_match_ptr() annotation. As far as I
> can tell, all these drivers are only actually used on configurations that
> have CONFIG_OF enabled.
I think I already tried to fix all of these, but Mark rejected my patches:
https://lore.kernel.org/all/7a65d775-cf07-4393-8b10-2cef4d5266ab@sirena.org.uk/
All of the changes here look the same as my patchset, I also got there
some Acks.
Best regards,
Krzysztof
_______________________________________________
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 31/34] spi: remove incorrect of_match_ptr annotations
From: Andy Shevchenko @ 2024-04-03 9:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Mark Brown, Neil Armstrong, Kevin Hilman,
Heiko Stuebner, Andi Shyti, Krzysztof Kozlowski, Arnd Bergmann,
Jerome Brunet, Martin Blumenstingl, Alim Akhtar, Li Zetao,
Jonathan Cameron, Rob Herring, Yang Yingliang, Luis de Arquer,
Tudor Ambarus, Sam Protsenko, Peter Griffin, Jaewon Kim,
linux-spi, linux-arm-kernel, linux-amlogic, linux-rockchip,
linux-samsung-soc
In-Reply-To: <20240403080702.3509288-32-arnd@kernel.org>
On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When building with CONFIG_OF disabled but W=1 extra warnings enabled,
> a couple of driver cause a warning about an unused ID table:
>
> drivers/spi/spi-armada-3700.c:806:34: error: unused variable 'a3700_spi_dt_ids' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-orion.c:614:34: error: unused variable 'orion_spi_of_match_table' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-pic32-sqi.c:673:34: error: unused variable 'pic32_sqi_of_ids' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-pic32.c:850:34: error: unused variable 'pic32_spi_of_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-rockchip.c:1020:34: error: unused variable 'rockchip_spi_dt_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-s3c64xx.c:1642:34: error: unused variable 's3c64xx_spi_dt_match' [-Werror,-Wunused-const-variable]
> drivers/spi/spi-st-ssc4.c:439:34: error: unused variable 'stm_spi_match' [-Werror,-Wunused-const-variable]
I would drop these 'drivers/spi/' parts as we know they are all in the same folder.
> These appear to all be copied from the same original driver, so fix them at the
> same time by removing the unnecessary of_match_ptr() annotation. As far as I
> can tell, all these drivers are only actually used on configurations that
> have CONFIG_OF enabled.
LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v11 6/7] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- remove status property in ptn5110 nodes
- fix dt-schema warnings
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- use compatible "nxp,ptn5110", "tcpci"
Changes in v10:
- no changes
Changes in v11:
- remove "sleep" pinctrl state
- add newline
---
.../boot/dts/freescale/imx93-11x11-evk.dts | 119 ++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 9921ea13ab48..fc340d4573ce 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include <dt-bindings/usb/pd.h>
#include "imx93.dtsi"
/ {
@@ -104,6 +105,81 @@ &mu2 {
status = "okay";
};
+&lpi2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ status = "okay";
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+ typec1_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ data-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ op-sink-microwatt = <15000000>;
+ self-powered;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+
+ ptn5110_2: tcpc@51 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x51>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+ typec2_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ data-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ op-sink-microwatt = <15000000>;
+ self-powered;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec2_dr_sw: endpoint {
+ remote-endpoint = <&usb2_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+};
+
&eqos {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eqos>;
@@ -156,6 +232,42 @@ &lpuart5 {
status = "okay";
};
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb2_drd_sw: endpoint {
+ remote-endpoint = <&typec2_dr_sw>;
+ };
+ };
+};
+
&usdhc1 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc1>;
@@ -222,6 +334,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
>;
};
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v11 5/7] arm64: dts: imx93: add usb nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
There are 2 USB controllers on i.MX93. Add them.
Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa9352LA/CA
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- fix format as suggested by Alexander
- change compatible from fsl,imx8mm-usb to fsl,imx93-usb
Changes in v3:
- replace deprecated fsl,usbphy with phys as suggested by Alexander
- reorder nodes
Changes in v4:
- fix the alignment
Changes in v5:
- rename usb_wakeup_clk to usb_wakeup
Changes in v6:
- rename usb_ctrl_root_clk to usb_ctrl_root
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- no changes
---
arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index 601c94e1fac8..77b3009b048e 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -183,6 +183,20 @@ mqs2: mqs2 {
status = "disabled";
};
+ usbphynop1: usbphynop1 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+ clock-names = "main_clk";
+ };
+
+ usbphynop2: usbphynop2 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+ clock-names = "main_clk";
+ };
+
soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -1167,6 +1181,50 @@ media_blk_ctrl: system-controller@4ac10000 {
status = "disabled";
};
+ usbotg1: usb@4c100000 {
+ compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+ reg = <0x4c100000 0x200>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+ <&clk IMX93_CLK_HSIO_32K_GATE>;
+ clock-names = "usb_ctrl_root", "usb_wakeup";
+ assigned-clocks = <&clk IMX93_CLK_HSIO>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+ assigned-clock-rates = <133000000>;
+ phys = <&usbphynop1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ status = "disabled";
+ };
+
+ usbmisc1: usbmisc@4c100200 {
+ compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x4c100200 0x200>;
+ #index-cells = <1>;
+ };
+
+ usbotg2: usb@4c200000 {
+ compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+ reg = <0x4c200000 0x200>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+ <&clk IMX93_CLK_HSIO_32K_GATE>;
+ clock-names = "usb_ctrl_root", "usb_wakeup";
+ assigned-clocks = <&clk IMX93_CLK_HSIO>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+ assigned-clock-rates = <133000000>;
+ phys = <&usbphynop2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ status = "disabled";
+ };
+
+ usbmisc2: usbmisc@4c200200 {
+ compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x4c200200 0x200>;
+ #index-cells = <1>;
+ };
+
ddr-pmu@4e300dc0 {
compatible = "fsl,imx93-ddr-pmu";
reg = <0x4e300dc0 0x200>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v11 4/7] ARM: dts: imx6: remove fsl,anatop property from usb controller node
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
This property is not needed for usb controller. The usb phy needs it
instead.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v7:
- new patch
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- not remove fsl,anatop for imx6ul.dtsi since it's already removed
Changes in v11:
- no changes
---
arch/arm/boot/dts/nxp/imx/imx6sll.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
index 3659fd5ecfa6..ddeb5b37fb78 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
@@ -683,7 +683,6 @@ usbotg1: usb@2184000 {
clocks = <&clks IMX6SLL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
- fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
rx-burst-size-dword = <0x10>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
index 0de359d62a47..6d3deba60de5 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
@@ -929,7 +929,6 @@ usbotg1: usb@2184000 {
clocks = <&clks IMX6SX_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
- fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
rx-burst-size-dword = <0x10>;
@@ -957,7 +956,6 @@ usbh: usb@2184400 {
fsl,usbphy = <&usbphynop1>;
fsl,usbmisc = <&usbmisc 2>;
phy_type = "hsic";
- fsl,anatop = <&anatop>;
dr_mode = "host";
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v11 3/7] arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Enable 2 USB nodes and add 2 PTN5150 nodes on i.MX8ULP evk board.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- fix format as suggusted by Fabio
- add PTN5150 nodes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- fix indent
- adjust order
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 84 +++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 24bb253b938d..e937e5f8fa8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -127,12 +127,70 @@ &lpi2c7 {
pinctrl-1 = <&pinctrl_lpi2c7>;
status = "okay";
+ ptn5150_1: typec@1d {
+ compatible = "nxp,ptn5150";
+ reg = <0x1d>;
+ int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec1>;
+ status = "disabled";
+ };
+
pcal6408: gpio@21 {
compatible = "nxp,pcal9554b";
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ ptn5150_2: typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec2>;
+ status = "disabled";
+ };
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy1 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb2>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc2 {
+ status = "okay";
};
&usdhc0 {
@@ -224,6 +282,32 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA 0x20
>;
};
+ pinctrl_typec1: typec1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF3__PTF3 0x3
+ >;
+ };
+
+ pinctrl_typec2: typec2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF5__PTF5 0x3
+ >;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF2__USB0_ID 0x10003
+ MX8ULP_PAD_PTF4__USB0_OC 0x10003
+ >;
+ };
+
+ pinctrl_usb2: usb2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTD23__USB1_ID 0x10003
+ MX8ULP_PAD_PTF6__USB1_OC 0x10003
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
MX8ULP_PAD_PTD1__SDHC0_CMD 0x3
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v11 1/7] dt-bindings: usb: usbmisc-imx: add fsl,imx8ulp-usbmisc compatible
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
Add "fsl,imx8ulp-usbmisc" compatible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v3:
- new patch due to missed this little one
Changes in v4:
- no changes
Changes in v5:
- add Acked-by tag
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- no changes
---
Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
index 2d3589d284b2..0a6e7ac1b37e 100644
--- a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
@@ -33,6 +33,7 @@ properties:
- fsl,imx7ulp-usbmisc
- fsl,imx8mm-usbmisc
- fsl,imx8mn-usbmisc
+ - fsl,imx8ulp-usbmisc
- const: fsl,imx7d-usbmisc
- const: fsl,imx6q-usbmisc
- items:
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v11 2/7] arm64: dts: imx8ulp: add usb nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Add USB nodes on i.MX8ULP platform which has 2 USB controllers.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- no changes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- drop usbphy aliases
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- adjust reg order
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index c4a0082f30d3..cbed01bb8cc0 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -472,6 +472,68 @@ usdhc2: mmc@298f0000 {
status = "disabled";
};
+ usbotg1: usb@29900000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29900000 0x200>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USB0>;
+ phys = <&usbphy1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc1: usbmisc@29900200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29900200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@29910000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29910000 0x10000>;
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ usbotg2: usb@29920000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29920000 0x200>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USDHC2_USB1>;
+ phys = <&usbphy2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc2: usbmisc@29920200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29920200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@29930000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29930000 0x10000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
fec: ethernet@29950000 {
compatible = "fsl,imx8ulp-fec", "fsl,imx6ul-fec", "fsl,imx6q-fec";
reg = <0x29950000 0x10000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: tlb: Fix TLBI RANGE operand
From: Marc Zyngier @ 2024-04-03 8:58 UTC (permalink / raw)
To: Gavin Shan
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will, akpm,
apopple, mark.rutland, ryan.roberts, rananta, yangyicong,
v-songbaohua, yezhenyu2, yihyu, shan.gavin
In-Reply-To: <20240403064929.1438475-1-gshan@redhat.com>
On Wed, 03 Apr 2024 07:49:29 +0100,
Gavin Shan <gshan@redhat.com> wrote:
>
> KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
> bitmap is collected by VMM and the corresponding PTEs need to be
> write-protected again. Unfortunately, the operand passed to the TLBI
> RANGE instruction isn't correctly sorted out by commit d1d3aa98b1d4
> ("arm64: tlb: Use the TLBI RANGE feature in arm64"). It leads to
> crash on the destination VM after live migration because some of the
> dirty pages are missed.
>
> For example, I have a VM where 8GB memory is assigned, starting from
> 0x40000000 (1GB). Note that the host has 4KB as the base page size.
> All TLBs for VM can be covered by one TLBI RANGE operation. However,
> I receives 0xffff708000040000 as the operand, which is wrong and the
> correct one should be 0x00007f8000040000. From the wrong operand, we
> have 3 and 1 for SCALE (bits[45:44) and NUM (bits943:39], only 1GB
> instead of 8GB memory is covered.
>
> Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI
> RANGE operand are provided.
>
> Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64")
> Cc: stable@kernel.org # v5.10+
> Reported-by: Yihuang Yu <yihyu@redhat.com>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
> arch/arm64/include/asm/tlbflush.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 3b0e8248e1a4..07c4fb4b82b4 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -166,7 +166,7 @@ static inline unsigned long get_trans_granule(void)
> */
> #define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
> #define __TLBI_RANGE_NUM(pages, scale) \
> - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
> + ((((pages) >> (5 * (scale) + 1)) - 1) & TLBI_RANGE_MASK)
>
> /*
> * TLB Invalidation
This looks pretty wrong, by the very definition of the comment that's
just above:
<quote>
/*
* Generate 'num' values from -1 to 30 with -1 rejected by the
* __flush_tlb_range() loop below.
*/
</quote>
With your change, num can't ever be negative, and that breaks
__flush_tlb_range_op():
<quote>
num = __TLBI_RANGE_NUM(pages, scale); \
if (num >= 0) { \
addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
scale, num, tlb_level); \
__tlbi(r##op, addr); \
if (tlbi_user) \
__tlbi_user(r##op, addr); \
start += __TLBI_RANGE_PAGES(num, scale) << PAGE_SHIFT; \
pages -= __TLBI_RANGE_PAGES(num, scale); \
} \
scale--; \
</quote>
We'll then shove whatever value we've found in the TLBI operation,
leading to unknown results instead of properly adjusting the scale to
issue a smaller invalidation.
I think the problem is that you are triggering NUM=31 and SCALE=3,
which the current code cannot handle as per the comment above
__flush_tlb_range_op() (we can't do NUM=30 and SCALE=4, obviously).
Can you try the untested patch below?
Thanks,
M.
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 3b0e8248e1a4..b71a1cece802 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -379,10 +379,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
* 3. If there is 1 page remaining, flush it through non-range operations. Range
* operations can only span an even number of pages. We save this for last to
* ensure 64KB start alignment is maintained for the LPA2 case.
- *
- * Note that certain ranges can be represented by either num = 31 and
- * scale or num = 0 and scale + 1. The loop below favours the latter
- * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
*/
#define __flush_tlb_range_op(op, start, pages, stride, \
asid, tlb_level, tlbi_user, lpa2) \
@@ -407,6 +403,7 @@ do { \
\
num = __TLBI_RANGE_NUM(pages, scale); \
if (num >= 0) { \
+ num += 1; \
addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
scale, num, tlb_level); \
__tlbi(r##op, addr); \
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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 v9 07/21] virt: geniezone: Add vm capability check
From: Yi-De Wu (吳一德) @ 2024-04-03 8:50 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, catalin.marinas@arm.com,
conor+dt@kernel.org, richardcochran@gmail.com,
Yingshiuan Pan (潘穎軒),
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
Ze-yu Wang (王澤宇),
angelogioacchino.delregno@collabora.com, will@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
quic_tsoni@quicinc.com, MY Chuang (莊明躍),
Kevenny Hsieh (謝宜芸),
devicetree@vger.kernel.org,
PeiLun Suei (隋培倫),
Liju-clr Chen (陳麗如), dbrazdil@google.com,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Shawn Hsiao (蕭志祥), linux-doc@vger.kernel.org,
Chi-shen Yeh (葉奇軒)
In-Reply-To: <c027bf67-e9b2-4eb2-9dee-a47a9c3bdd8a@collabora.com>
On Thu, 2024-02-01 at 10:44 +0100, AngeloGioacchino Del Regno wrote:
> Il 29/01/24 09:32, Yi-De Wu ha scritto:
> > From: "Yingshiuan Pan" <yingshiuan.pan@mediatek.com>
> >
> > Inquire the `capability support` on GenieZone hypervisor.
> > Example:
> > `GZVM_CAP_PROTECTED_VM` or `GZVM_CAP_VM_GPA_SIZE`.
> >
> > Signed-off-by: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
> > Signed-off-by: Jerry Wang <ze-yu.wang@mediatek.com>
> > Signed-off-by: kevenny hsieh <kevenny.hsieh@mediatek.com>
> > Signed-off-by: Liju Chen <liju-clr.chen@mediatek.com>
> > Signed-off-by: Yi-De Wu <yi-de.wu@mediatek.com>
> > ---
> > arch/arm64/geniezone/gzvm_arch_common.h | 2 +
> > arch/arm64/geniezone/vm.c | 122
> > ++++++++++++++++++++++++
> > drivers/virt/geniezone/gzvm_main.c | 27 ++++++
> > drivers/virt/geniezone/gzvm_vm.c | 21 ++++
> > include/linux/gzvm_drv.h | 5 +
> > include/uapi/linux/gzvm.h | 31 ++++++
> > 6 files changed, 208 insertions(+)
> >
> > diff --git a/arch/arm64/geniezone/gzvm_arch_common.h
> > b/arch/arm64/geniezone/gzvm_arch_common.h
> > index 2f66e496dfae..383af0829f11 100644
> > --- a/arch/arm64/geniezone/gzvm_arch_common.h
> > +++ b/arch/arm64/geniezone/gzvm_arch_common.h
> > @@ -13,6 +13,7 @@ enum {
> > GZVM_FUNC_DESTROY_VM = 1,
> > GZVM_FUNC_SET_MEMREGION = 4,
> > GZVM_FUNC_PROBE = 12,
> > + GZVM_FUNC_ENABLE_CAP = 13,
>
> GZVM_FUNC_PROBE = 12,
> GZVM_FUNC_ENABLE_CAP,
>
Given that this is an API from the kernel to the hypervisor, it may be
utilized with various toolchains. Our intention is to explicitly assign
values to prevent any unexpected compiler behavior. For further
details, we'd like to refer to the discussion below.
https://lore.kernel.org/all/20200318125003.GA2727094@kroah.com/
> > NR_GZVM_FUNC,
> > };
> >
>
> Regards,
> Angelo
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 1/7] dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong, Conor Dooley
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
The MNT Reform 2 CM4 adapter can be populated with any Raspberry Pi CM4
compatible module such as a BPI-CM4 Module, document that.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 949537cea6be..b66b93b8bfd3 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -157,6 +157,7 @@ properties:
items:
- enum:
- bananapi,bpi-cm4io
+ - mntre,reform2-cm4
- const: bananapi,bpi-cm4
- const: amlogic,a311d
- const: amlogic,g12b
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Andy Shevchenko @ 2024-04-03 8:44 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan, Peng Fan (OSS), Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <Zg0N8S05D329BVjN@pluto>
On Wed, Apr 3, 2024 at 11:06 AM Cristian Marussi
<cristian.marussi@arm.com> wrote:
> On Tue, Apr 02, 2024 at 07:39:44PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 2, 2024 at 6:58 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> > > On Tue, Apr 02, 2024 at 04:06:06PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 2, 2024 at 10:48 AM Cristian Marussi
> > > > <cristian.marussi@arm.com> wrote:
> > > > > On Sun, Mar 31, 2024 at 01:44:28PM +0000, Peng Fan wrote:
> > > > > > > Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti:
...
> > > > > > > > +#include <linux/module.h>
> > > > > > > > +#include <linux/scmi_protocol.h>
> > > > > > > > +#include <linux/slab.h>
> > > > > > >
> > > > > > > This is semi-random list of headers. Please, follow IWYU principle (include
> > > > > > > what you use). There are a lot of inclusions I see missing (just in the context of
> > > > > > > this page I see bits.h, types.h, and asm/byteorder.h).
> > > > > >
> > > > > > Is there any documentation about this requirement?
> > > > > > Some headers are already included by others.
> > > >
> > > > The documentation here is called "a common sense".
> > > > The C language is built like this and we expect that nobody will
> > > > invest into the dependency hell that we have already, that's why IWYU
> > > > principle, please follow it.
> > >
> > > Yes, but given that we have a growing number of SCMI protocols there is a
> > > common local protocols.h header to group all includes needed by any
> > > protocols: the idea behind this (and the devm_ saga down below) was to ease
> > > development of protocols, since there are lots of them and growing, given
> > > the SCMI spec is extensible.
> >
> > Yes, and what you are effectively suggesting is: "Technical debt? Oh,
> > fine, we do not care!" This is not good. I'm in a long term of
> > cleaning up the dependency hell in the kernel (my main focus is
> > kernel.h for now) and I am talking from my experience. I do not like
> > what people are doing in 95% of the code, that's why I really want to
> > stop the bad practices as soon as possible.
>
> Not at all, the aim was exactly the opposite, avoiding that some protocol
> could have been written without all the needed includes: since a basic set
> of headers is definitely common to any protocol you may think to write,
> grouping all there was meant to avoid this...I thought that by moving the
> problem away in one single internal common header was easier to monitor.
Which may or may not be okay. It plays too smart, so the end developer
won't care about real headers they need as they are the only ones who
know the source code in the best possible way.
> I certainly maybe wrong, but I dont see how you can deduce I dont care...
See above, the protocols.h it's a reincarnation (much less twisted and
ugly, though) of something like kernel.h. Do you know why we have a
split to headers instead of having everything in one? It speeds up a
build, it separates namespace (to the extent of what we call
"namespace" in C language), it makes the modularization (of the source
code) better (easier to avoid considering what's not needed), and so
on. I don't think making a "common" header is a good idea.
> ...and maybe, only maybe, what that 95% of people is trying to do in their
> horrible code is to deliver the best reasonably possible thing within their
> timeline while you are barking at them in chase of never to be released utter
> perfection.
Yeah. That's why it's good to teach people about many aspects of the C
language (which is not popular, in particular due to these nuances,
nowadays and we are starving for good developers).
> > Last to add, but not least is that your code may be used as an example
> > for others, hence we really have to do our best in order to avoid bad
> > design, practices, and cargo cults. If this requires more refactoring
> > of the existing code, then do it sooner than later.
...
> > > > > Andy made (mostly) the same remarks on this same patch ~1-year ago on
> > > > > this same patch while it was posted by Oleksii.
> > > > >
> > > > > And I told that time that most of the remarks around devm_ usage were
> > > > > wrong due to how the SCMI core handles protocol initialization (using a
> > > > > devres group transparently).
> > > > >
> > > > > This is what I answered that time.
> > > > >
> > > > > https://lore.kernel.org/linux-arm-kernel/ZJ78hBcjAhiU+ZBO@e120937-lin/#t
> > > > >
> > > > > I wont repeat myself, but, in a nutshell the memory allocation like it
> > > > > is now is fine: a bit happens via devm_ at protocol initialization, the
> > > > > other is doe via explicit kmalloc at runtime and freed via kfree at
> > > > > remove time (if needed...i.e. checking the present flag of some structs)
> > > >
> > > > This sounds like a mess. devm_ is expected to be used only for the
> > > > ->probe() stage, otherwise you may consider cleanup.h (__free() macro)
> > > > to have automatic free at the paths where memory is not needed.
> > >
> > > Indeed, this protocol_init code is called by the SCMI core once for all when
> > > an SCMI driver tries at first to use this specific protocol by 'getting' its
> > > protocol_ops, so it is indeed called inside the probe chain of the driver:
> > > at this point you *can* decide to use devres to allocate memory and be assured
> > > that if the init fails, or when the driver cease to use this protocol (calling
> > > its remove()) and no other driver is using it, all the stuff that have been
> > > allocated related to this protocol will be released by the core for you.
> > > (using an internal devres group)
> > >
> > > Without this you should handle manually all the deallocation manually on
> > > the init error-paths AND also provide all the cleanup explicitly when
> > > the protocol is no more used by any driver (multiple users of the same
> > > protocol instance are possible)...for all protocols.
> >
> > Yes. Is it a problem?
>
> Well, no, but is it not a repetitive and error-prone process ?
Yes. That's why we now have cleanup.h. Please, consider using it instead.
> Is it not the exact reason why devres management exist in first place, to avoid
> repetitive manual alloc/free of resources and related pitfalls ? (even though
> certainly it is normally used in a more conventional and straightforward way)
No. Its scope is to clean the probe-remove parts, one should not
spread it otherwise and one definitely should know its limitations and
corner cases (I even gave some examples back in ca. 2017 in one of my
presentation WRT typical mistakes the developers make
> The idea was to give some sort of aid in the SCMI stack for writing protocols,
> so regarding mem_mgmt, I just built on top of devres facilities, not invented
> anything, to try to avoid repetitions and let the core handle mem allocs/free
> during the probe phases as much as possible: in pinctrl case would be
> particularly trivial to instead manually allocate stuff at init (due to many
> lazy delayed allocations) but other protocols need a lot more to be done at init,
> frequently in a loop to allocate multiple resources descriptors, and manually
> undoing all of that on each error-path and on cleanup is definitely error-prone
> and a pain.
I understand the motivation, but again, devm is a beast in the corner
cases. I believe Laurent Pinchart gave a presentation about how bad
devm can hit you if you don't know what you are doing (OTOH it's hard
to know with devm).
> Last but not least, this whole thing was designed to address the needs of the
> protocols that existed at that time....it is only now with pinctrl lazy-allocations
> at runtime that the ugly cohexistence of devm_ and non-devm allocations became a
> thing....so clearly the thing needs to be improved/rethinked...even dropped if no
> more fitting...
>
> ... or alternatively since devres allocations are anyway optional, you could just
> use regular kmalloc/kfree for this protocol and avoid this dual handling...
Probably, just have a look at cleanup.h.
> ...this was just to put things in context...and I'll happily let Sudeep decide
> what he prefers in the immediate for pinctrl or more in general about all the
> scmi devres, that I've got enough of these pleasant interactions for now...
As I said, it's your call, I'm not preventing you from applying
whatever is going on in the SCMI subsystem. Just tried to point out
the problem(s).
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 5/7] riscv: mm: accelerate pagefault when badaccess
From: Kefeng Wang @ 2024-04-03 8:38 UTC (permalink / raw)
To: akpm
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexander Gordeev, Gerald Schaefer, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, x86, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, surenb, linux-mm,
Kefeng Wang
In-Reply-To: <20240403083805.1818160-1-wangkefeng.wang@huawei.com>
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no need to retry with mmap_lock
again. Since the page faut is handled under per-VMA lock, count it as
a vma lock event with VMA_LOCK_SUCCESS.
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/riscv/mm/fault.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 3ba1d4dde5dd..b3fcf7d67efb 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -292,7 +292,10 @@ void handle_page_fault(struct pt_regs *regs)
if (unlikely(access_error(cause, vma))) {
vma_end_read(vma);
- goto lock_mmap;
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ tsk->thread.bad_cause = SEGV_ACCERR;
+ bad_area_nosemaphore(regs, code, addr);
+ return;
}
fault = handle_mm_fault(vma, addr, flags | FAULT_FLAG_VMA_LOCK, regs);
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/7] s390: mm: accelerate pagefault when badaccess
From: Kefeng Wang @ 2024-04-03 8:38 UTC (permalink / raw)
To: akpm
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexander Gordeev, Gerald Schaefer, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, x86, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, surenb, linux-mm,
Kefeng Wang
In-Reply-To: <20240403083805.1818160-1-wangkefeng.wang@huawei.com>
The vm_flags of vma already checked under per-VMA lock, if it is a
bad access, directly handle error, no need to retry with mmap_lock
again. Since the page faut is handled under per-VMA lock, count it
as a vma lock event with VMA_LOCK_SUCCESS.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/s390/mm/fault.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index c421dd44ffbe..162ca2576fd4 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -325,7 +325,8 @@ static void do_exception(struct pt_regs *regs, int access)
goto lock_mmap;
if (!(vma->vm_flags & access)) {
vma_end_read(vma);
- goto lock_mmap;
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ return handle_fault_error_nolock(regs, SEGV_ACCERR);
}
fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/7] arm64: mm: accelerate pagefault when VM_FAULT_BADACCESS
From: Kefeng Wang @ 2024-04-03 8:38 UTC (permalink / raw)
To: akpm
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexander Gordeev, Gerald Schaefer, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, x86, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, surenb, linux-mm,
Kefeng Wang
In-Reply-To: <20240403083805.1818160-1-wangkefeng.wang@huawei.com>
The vm_flags of vma already checked under per-VMA lock, if it is a
bad access, directly set fault to VM_FAULT_BADACCESS and handle error,
no need to retry with mmap_lock again, the latency time reduces 34% in
'lat_sig -P 1 prot lat_sig' from lmbench testcase.
Since the page faut is handled under per-VMA lock, count it as a vma lock
event with VMA_LOCK_SUCCESS.
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/mm/fault.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 9bb9f395351a..405f9aa831bd 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -572,7 +572,9 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
if (!(vma->vm_flags & vm_flags)) {
vma_end_read(vma);
- goto lock_mmap;
+ fault = VM_FAULT_BADACCESS;
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ goto done;
}
fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox