Re: [PATCH] media: meson: vdec: add G12/SM1 to module description
On 16/11/2020 05:30, Christian Hewitt wrote:
> The meson vdec driver also supports Amlogic G12/SM1 hardware.
>
> Signed-off-by: Christian Hewitt
> ---
> drivers/staging/media/meson/vdec/vdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/meson/vdec/vdec.c
> b/drivers/staging/media/meson/vdec/vdec.c
> index 5ccb3846c879..5d4db7a5b4b5 100644
> --- a/drivers/staging/media/meson/vdec/vdec.c
> +++ b/drivers/staging/media/meson/vdec/vdec.c
> @@ -1131,6 +1131,6 @@ static struct platform_driver meson_vdec_driver = {
> };
> module_platform_driver(meson_vdec_driver);
>
> -MODULE_DESCRIPTION("Meson video decoder driver for GXBB/GXL/GXM");
> +MODULE_DESCRIPTION("Meson video decoder driver for GXBB/GXL/GXM/G12/SM1");
> MODULE_AUTHOR("Maxime Jourdan ");
> MODULE_LICENSE("GPL");
>
Reviewed-by: Neil Armstrong
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder
On 15/11/2020 19:59, Martin Cerveny wrote: > Hello. > > On Thu, 5 Nov 2020, Hans Verkuil wrote: > >> Hi Martin, >> >> On 12/09/2020 16:30, Martin Cerveny wrote: >>> First patch extends cedrus capability to all decoders >>> because V3s missing MPEG2 decoder. >>> >>> Next two patches add system control node (SRAM C1) and >>> next three patches add support for Cedrus VPU. >>> >>> Tested on "Lichee Zero" V3s platform with testing LCD patch >>> ( https://github.com/mcerveny/linux/tree/v3s_videocodec_v4 ) >>> and V4L2 raw API testing utility >>> ( https://github.com/mcerveny/v4l2-request-test ): >>> - enabled LCD (DRM dual VI and sigle UI planes) >>> - added RGB panel >>> - enabled PWM >>> >>> There is low memory on V3s (64MB) and maximum must be available to CMA: >>> - CONFIG_CMA_SIZE_MBYTES=28 >>> - add swap to swapout other processes >>> - decrease buffers in v4l2-request-test (.buffers_count from 16 to 6) >>> >>> Only H.264 decoder working - MPEG and H.265 unsupported by V3s, >>> JPEG/MJPEG still unimplemented, encoder unimplemented >> >> When I tried to merged these patches I got merge conflicts. >> >> Possibly due to other 5.10 changes, but certainly because of conflicts >> with patches from Jernej: >> >> https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-4-jernej.skra...@siol.net/ >> https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skra...@siol.net/ >> >> I've merged Jerne's patches and posted a PR for that: >> https://patchwork.linuxtv.org/project/linux-media/patch/f3b8e5e2-5f0e-fb6f-e5b2-7f44f7e36...@xs4all.nl/ >> >> Can you rebase your patches on top of my branch that contains Jernej's >> patches? >> >> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.11e >> >> Once my PR is merged into the media_tree master I can take your rebased >> patches. > > I updated patches: > https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e > > BUT, commit (555 commits) for v5.10-1 > https://github.com/torvalds/linux/commit/fd5c32d80884268a381ed0e67cccef0b3d37750b > disrupts usability of Cedrus H.264 (at least for my Allwinner V3s): > > 1) colors are disrupted > > There are missing some initialization now. > > If I use "5.9" compatible code > (last bisect good point > https://github.com/torvalds/linux/commit/647412daeb454b6dad12a6c6961ab90aac9e5d29 > ) > then reboot (not power-off!) and use new code > ( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e ) > and colors are OK. Could this or the next issue be related to this bug fix? https://git.linuxtv.org/media_tree.git/commit/?h=fixes&id=9ac924b98728c3733c91c6c59fc410827d0da49f That fix isn't yet in our master tree. > > 2) decoding of complex streams fails > > ( https://github.com/mcerveny/v4l2-request-test/tree/v5.10 ) > - bbb-h264-all-i-32 - OK > - bbb-h264-32 - bad from frame 5 > - bbb-h264-high-32 - bad from frame 6 I think cedrus devs need to take a look at these issues. Regards, Hans > > best regards, > Martin > >>> Changes since v1: >>> - patch 0005 rename >>> - added testing description >>> >>> Martin Cerveny (6): >>> media: cedrus: Register all codecs as capability >>> dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s >>> compatibles >>> ARM: dts: sun8i: v3s: Add node for system control >>> media: cedrus: Add support for V3s >>> dt-bindings: media: cedrus: Add V3s compatible >>> ARM: dts: sun8i: v3s: Add video engine node >>> >>> .../allwinner,sun4i-a10-video-engine.yaml | 1 + >>> .../allwinner,sun4i-a10-system-control.yaml | 6 >>> arch/arm/boot/dts/sun8i-v3s.dtsi | 33 +++ >>> drivers/staging/media/sunxi/cedrus/cedrus.c | 28 +++- >>> drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++ >>> .../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++ >>> 6 files changed, 71 insertions(+), 1 deletion(-) >>> >> ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder
On Mon, 16 Nov 2020, Hans Verkuil wrote: On 15/11/2020 19:59, Martin Cerveny wrote: Hello. On Thu, 5 Nov 2020, Hans Verkuil wrote: Hi Martin, On 12/09/2020 16:30, Martin Cerveny wrote: First patch extends cedrus capability to all decoders because V3s missing MPEG2 decoder. Next two patches add system control node (SRAM C1) and next three patches add support for Cedrus VPU. Tested on "Lichee Zero" V3s platform with testing LCD patch ( https://github.com/mcerveny/linux/tree/v3s_videocodec_v4 ) and V4L2 raw API testing utility ( https://github.com/mcerveny/v4l2-request-test ): - enabled LCD (DRM dual VI and sigle UI planes) - added RGB panel - enabled PWM There is low memory on V3s (64MB) and maximum must be available to CMA: - CONFIG_CMA_SIZE_MBYTES=28 - add swap to swapout other processes - decrease buffers in v4l2-request-test (.buffers_count from 16 to 6) Only H.264 decoder working - MPEG and H.265 unsupported by V3s, JPEG/MJPEG still unimplemented, encoder unimplemented When I tried to merged these patches I got merge conflicts. Possibly due to other 5.10 changes, but certainly because of conflicts with patches from Jernej: https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-4-jernej.skra...@siol.net/ https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skra...@siol.net/ I've merged Jerne's patches and posted a PR for that: https://patchwork.linuxtv.org/project/linux-media/patch/f3b8e5e2-5f0e-fb6f-e5b2-7f44f7e36...@xs4all.nl/ Can you rebase your patches on top of my branch that contains Jernej's patches? https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.11e Once my PR is merged into the media_tree master I can take your rebased patches. I updated patches: https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e BUT, commit (555 commits) for v5.10-1 https://github.com/torvalds/linux/commit/fd5c32d80884268a381ed0e67cccef0b3d37750b disrupts usability of Cedrus H.264 (at least for my Allwinner V3s): 1) colors are disrupted There are missing some initialization now. If I use "5.9" compatible code (last bisect good point https://github.com/torvalds/linux/commit/647412daeb454b6dad12a6c6961ab90aac9e5d29 ) then reboot (not power-off!) and use new code ( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e ) and colors are OK. Could this or the next issue be related to this bug fix? https://git.linuxtv.org/media_tree.git/commit/?h=fixes&id=9ac924b98728c3733c91c6c59fc410827d0da49f That fix isn't yet in our master tree. Confirmed. It recovers colors ! 2) decoding of complex streams fails ( https://github.com/mcerveny/v4l2-request-test/tree/v5.10 ) - bbb-h264-all-i-32 - OK - bbb-h264-32 - bad from frame 5 - bbb-h264-high-32 - bad from frame 6 I think cedrus devs need to take a look at these issues. Maybe something wrong in my testing code, problematic commit swapped some variables between structures :-( I try to investigate more, regards Martin Regards, Hans best regards, Martin Changes since v1: - patch 0005 rename - added testing description Martin Cerveny (6): media: cedrus: Register all codecs as capability dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s compatibles ARM: dts: sun8i: v3s: Add node for system control media: cedrus: Add support for V3s dt-bindings: media: cedrus: Add V3s compatible ARM: dts: sun8i: v3s: Add video engine node .../allwinner,sun4i-a10-video-engine.yaml | 1 + .../allwinner,sun4i-a10-system-control.yaml | 6 arch/arm/boot/dts/sun8i-v3s.dtsi | 33 +++ drivers/staging/media/sunxi/cedrus/cedrus.c | 28 +++- drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++ .../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++ 6 files changed, 71 insertions(+), 1 deletion(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder
Hello. On Mon, 16 Nov 2020, Martin Cerveny wrote: On Mon, 16 Nov 2020, Hans Verkuil wrote: On 15/11/2020 19:59, Martin Cerveny wrote: On Thu, 5 Nov 2020, Hans Verkuil wrote: On 12/09/2020 16:30, Martin Cerveny wrote: First patch extends cedrus capability to all decoders because V3s missing MPEG2 decoder. Next two patches add system control node (SRAM C1) and next three patches add support for Cedrus VPU. Tested on "Lichee Zero" V3s platform with testing LCD patch ( https://github.com/mcerveny/linux/tree/v3s_videocodec_v4 ) and V4L2 raw API testing utility ( https://github.com/mcerveny/v4l2-request-test ): - enabled LCD (DRM dual VI and sigle UI planes) - added RGB panel - enabled PWM There is low memory on V3s (64MB) and maximum must be available to CMA: - CONFIG_CMA_SIZE_MBYTES=28 - add swap to swapout other processes - decrease buffers in v4l2-request-test (.buffers_count from 16 to 6) Only H.264 decoder working - MPEG and H.265 unsupported by V3s, JPEG/MJPEG still unimplemented, encoder unimplemented When I tried to merged these patches I got merge conflicts. Possibly due to other 5.10 changes, but certainly because of conflicts with patches from Jernej: https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-4-jernej.skra...@siol.net/ https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skra...@siol.net/ I've merged Jerne's patches and posted a PR for that: https://patchwork.linuxtv.org/project/linux-media/patch/f3b8e5e2-5f0e-fb6f-e5b2-7f44f7e36...@xs4all.nl/ Can you rebase your patches on top of my branch that contains Jernej's patches? https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.11e Once my PR is merged into the media_tree master I can take your rebased patches. I updated patches: https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e BUT, commit (555 commits) for v5.10-1 https://github.com/torvalds/linux/commit/fd5c32d80884268a381ed0e67cccef0b3d37750b disrupts usability of Cedrus H.264 (at least for my Allwinner V3s): 1) colors are disrupted There are missing some initialization now. If I use "5.9" compatible code (last bisect good point https://github.com/torvalds/linux/commit/647412daeb454b6dad12a6c6961ab90aac9e5d29 ) then reboot (not power-off!) and use new code ( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e ) and colors are OK. Could this or the next issue be related to this bug fix? https://git.linuxtv.org/media_tree.git/commit/?h=fixes&id=9ac924b98728c3733c91c6c59fc410827d0da49f That fix isn't yet in our master tree. Confirmed. It recovers colors ! 2) decoding of complex streams fails ( https://github.com/mcerveny/v4l2-request-test/tree/v5.10 ) - bbb-h264-all-i-32 - OK - bbb-h264-32 - bad from frame 5 - bbb-h264-high-32 - bad from frame 6 I think cedrus devs need to take a look at these issues. Maybe something wrong in my testing code, problematic commit swapped some variables between structures :-( I try to investigate more, regards Martin Yes. I found new format in ref_pic_list. I updated test application. All H.264 tests are working now. https://github.com/mcerveny/v4l2-request-test Is it necessary to release new "Patch V3" (rebased) series from https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e or not ? Regards, Martin Regards, Hans best regards, Martin Changes since v1: - patch 0005 rename - added testing description Martin Cerveny (6): media: cedrus: Register all codecs as capability dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s compatibles ARM: dts: sun8i: v3s: Add node for system control media: cedrus: Add support for V3s dt-bindings: media: cedrus: Add V3s compatible ARM: dts: sun8i: v3s: Add video engine node .../allwinner,sun4i-a10-video-engine.yaml | 1 + .../allwinner,sun4i-a10-system-control.yaml | 6 arch/arm/boot/dts/sun8i-v3s.dtsi | 33 +++ drivers/staging/media/sunxi/cedrus/cedrus.c | 28 +++- drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++ .../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++ 6 files changed, 71 insertions(+), 1 deletion(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder
On 16/11/2020 13:07, Martin Cerveny wrote: > Hello. > > On Mon, 16 Nov 2020, Martin Cerveny wrote: >> On Mon, 16 Nov 2020, Hans Verkuil wrote: >>> On 15/11/2020 19:59, Martin Cerveny wrote: On Thu, 5 Nov 2020, Hans Verkuil wrote: > On 12/09/2020 16:30, Martin Cerveny wrote: >> First patch extends cedrus capability to all decoders >> because V3s missing MPEG2 decoder. >> >> Next two patches add system control node (SRAM C1) and >> next three patches add support for Cedrus VPU. >> >> Tested on "Lichee Zero" V3s platform with testing LCD patch >> ( https://github.com/mcerveny/linux/tree/v3s_videocodec_v4 ) >> and V4L2 raw API testing utility >> ( https://github.com/mcerveny/v4l2-request-test ): >> - enabled LCD (DRM dual VI and sigle UI planes) >> - added RGB panel >> - enabled PWM >> >> There is low memory on V3s (64MB) and maximum must be available to CMA: >> - CONFIG_CMA_SIZE_MBYTES=28 >> - add swap to swapout other processes >> - decrease buffers in v4l2-request-test (.buffers_count from 16 to 6) >> >> Only H.264 decoder working - MPEG and H.265 unsupported by V3s, >> JPEG/MJPEG still unimplemented, encoder unimplemented > > When I tried to merged these patches I got merge conflicts. > > Possibly due to other 5.10 changes, but certainly because of conflicts > with patches from Jernej: > > https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-4-jernej.skra...@siol.net/ > https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skra...@siol.net/ > > I've merged Jerne's patches and posted a PR for that: > https://patchwork.linuxtv.org/project/linux-media/patch/f3b8e5e2-5f0e-fb6f-e5b2-7f44f7e36...@xs4all.nl/ > > Can you rebase your patches on top of my branch that contains Jernej's > patches? > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.11e > > Once my PR is merged into the media_tree master I can take your rebased > patches. I updated patches: https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e BUT, commit (555 commits) for v5.10-1 https://github.com/torvalds/linux/commit/fd5c32d80884268a381ed0e67cccef0b3d37750b disrupts usability of Cedrus H.264 (at least for my Allwinner V3s): 1) colors are disrupted There are missing some initialization now. If I use "5.9" compatible code (last bisect good point https://github.com/torvalds/linux/commit/647412daeb454b6dad12a6c6961ab90aac9e5d29 ) then reboot (not power-off!) and use new code ( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e ) and colors are OK. >>> >>> Could this or the next issue be related to this bug fix? >>> >>> https://git.linuxtv.org/media_tree.git/commit/?h=fixes&id=9ac924b98728c3733c91c6c59fc410827d0da49f >>> >>> That fix isn't yet in our master tree. >> >> Confirmed. It recovers colors ! >> 2) decoding of complex streams fails ( https://github.com/mcerveny/v4l2-request-test/tree/v5.10 ) - bbb-h264-all-i-32 - OK - bbb-h264-32 - bad from frame 5 - bbb-h264-high-32 - bad from frame 6 >>> >>> I think cedrus devs need to take a look at these issues. >> >> Maybe something wrong in my testing code, >> problematic commit swapped some variables between structures :-( >> >> I try to investigate more, regards Martin > > Yes. I found new format in ref_pic_list. > I updated test application. All H.264 tests are working now. > > https://github.com/mcerveny/v4l2-request-test > > Is it necessary to release new "Patch V3" (rebased) series from > https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e or not ? Yes, please! That would be much appreciated. Regards, Hans > > Regards, Martin > >>> Regards, >>> >>> Hans >>> best regards, Martin >> Changes since v1: >> - patch 0005 rename >> - added testing description >> >> Martin Cerveny (6): >> media: cedrus: Register all codecs as capability >> dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s >> compatibles >> ARM: dts: sun8i: v3s: Add node for system control >> media: cedrus: Add support for V3s >> dt-bindings: media: cedrus: Add V3s compatible >> ARM: dts: sun8i: v3s: Add video engine node >> >> .../allwinner,sun4i-a10-video-engine.yaml | 1 + >> .../allwinner,sun4i-a10-system-control.yaml | 6 >> arch/arm/boot/dts/sun8i-v3s.dtsi | 33 +++ >> drivers/staging/media/sunxi/cedrus/cedrus.c | 28 +++- >> drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++ >> .../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++ >> 6 files changed, 71 insertions(+), 1 deletion(-) >> > >>> >>
[PATCH 0/8] Move Hikey 970 USB support out of staging and add DT
This patch series finish addressing support for Hikey 970 USB. It moves the power management and USB3 drivers out of staging, adding the device tree changes required for USB3 to work on Hikey 970. Mauro Carvalho Chehab (8): phy: phy-hi3670-usb3: move driver from staging into phy spmi: hi6421-spmi-pmic: move driver from staging mfd: hi6421-spmi-pmic: move driver from staging regulator: hi6421v600-regulator: move it from staging arm64: dts: hisilicon: hi3670.dtsi: add I2C settings arm64: dts: hikey970-pinctrl.dtsi: add missing pinctrl settings dts: hisilicon: add support for USB3 on Hikey 970 dts: hisilicon: add support for the PMIC found on Hikey 970 .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 159 + .../bindings/phy/phy-hi3670-usb3.yaml | 72 ++ .../spmi/hisilicon,hisi-spmi-controller.yaml | 62 ++ MAINTAINERS | 24 +- .../boot/dts/hisilicon/hi3670-hikey970.dts| 124 +++- arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 135 .../boot/dts/hisilicon/hikey970-pinctrl.dtsi | 548 +- .../boot/dts/hisilicon/hikey970-pmic.dtsi | 197 + drivers/mfd/Kconfig | 15 + drivers/mfd/Makefile | 1 + drivers/mfd/hi6421-spmi-pmic.c| 342 + drivers/phy/hisilicon/Kconfig | 10 + drivers/phy/hisilicon/Makefile| 1 + drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++ drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile| 1 + drivers/regulator/hi6421v600-regulator.c | 478 + drivers/spmi/Kconfig | 9 + drivers/spmi/Makefile | 1 + drivers/spmi/hisi-spmi-controller.c | 358 ++ drivers/staging/Kconfig | 2 - drivers/staging/Makefile | 1 - drivers/staging/hikey9xx/Kconfig | 49 -- drivers/staging/hikey9xx/Makefile | 7 - drivers/staging/hikey9xx/TODO | 5 - drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 342 - .../staging/hikey9xx/hi6421v600-regulator.c | 478 - .../staging/hikey9xx/hisi-spmi-controller.c | 358 -- .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 159 - .../hisilicon,hisi-spmi-controller.yaml | 62 -- drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 -- drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 -- 32 files changed, 3183 insertions(+), 2240 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml create mode 100644 Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi create mode 100644 drivers/mfd/hi6421-spmi-pmic.c create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c create mode 100644 drivers/regulator/hi6421v600-regulator.c create mode 100644 drivers/spmi/hisi-spmi-controller.c delete mode 100644 drivers/staging/hikey9xx/Kconfig delete mode 100644 drivers/staging/hikey9xx/Makefile delete mode 100644 drivers/staging/hikey9xx/TODO delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c delete mode 100644 drivers/staging/hikey9xx/hi6421v600-regulator.c delete mode 100644 drivers/staging/hikey9xx/hisi-spmi-controller.c delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml delete mode 100644 drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.c delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.yaml -- 2.28.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/8] mfd: hi6421-spmi-pmic: move driver from staging
This driver is ready for mainstream. So, move it out of staging.
Signed-off-by: Mauro Carvalho Chehab
---
.../mfd/hisilicon,hi6421-spmi-pmic.yaml | 159
MAINTAINERS | 7 +
drivers/mfd/Kconfig | 15 +
drivers/mfd/Makefile | 1 +
drivers/mfd/hi6421-spmi-pmic.c| 342 ++
drivers/staging/hikey9xx/Kconfig | 16 -
drivers/staging/hikey9xx/Makefile | 1 -
drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 342 --
.../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 159
9 files changed, 524 insertions(+), 518 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
create mode 100644 drivers/mfd/hi6421-spmi-pmic.c
delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c
delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml
diff --git
a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
new file mode 100644
index ..80e74c261e05
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon 6421v600 SPMI PMIC
+
+maintainers:
+ - Mauro Carvalho Chehab
+
+description: |
+ HiSilicon 6421v600 should be connected inside a MIPI System Power Management
+ (SPMI) bus. It provides interrupts and power supply.
+
+ The GPIO and interrupt settings are represented as part of the top-level PMIC
+ node.
+
+ The SPMI controller part is provided by
+ drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml.
+
+properties:
+ $nodename:
+pattern: "pmic@[0-9a-f]"
+
+ compatible:
+const: hisilicon,hi6421v600-spmi
+
+ reg:
+maxItems: 1
+
+ '#interrupt-cells':
+const: 2
+
+ interrupt-controller:
+description:
+ Identify that the PMIC is capable of behaving as an interrupt controller.
+
+ gpios:
+maxItems: 1
+
+ regulators:
+type: object
+
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+patternProperties:
+ '^ldo[0-9]+@[0-9a-f]$':
+type: object
+
+$ref: "/schemas/regulator/regulator.yaml#"
+
+properties:
+ reg:
+description: Enable register.
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ vsel-reg:
+description: Voltage selector register.
+
+ enable-mask:
+description: Bitmask used to enable the regulator.
+
+ voltage-table:
+description: Table with the selector items for the voltage
regulator.
+minItems: 2
+maxItems: 16
+
+ off-on-delay-us:
+description: Time required for changing state to enabled in
microseconds.
+
+ startup-delay-us:
+description: Startup time in microseconds.
+
+ idle-mode-mask:
+description: Bitmask used to put the regulator on idle mode.
+
+ eco-microamp:
+description: Maximum current while on idle mode.
+
+required:
+ - reg
+ - vsel-reg
+ - enable-mask
+ - voltage-table
+ - off-on-delay-us
+ - startup-delay-us
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+examples:
+ - |
+/* pmic properties */
+
+pmic: pmic@0 {
+ compatible = "hisilicon,hi6421-spmi";
+ reg = <0 0>;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ gpios = <&gpio28 0 0>;
+
+ regulators {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ldo3: ldo3@16 {
+ reg = <0x16>;
+ vsel-reg = <0x51>;
+
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <200>;
+ regulator-boot-on;
+
+ enable-mask = <0x01>;
+
+ voltage-table = <150>, <155>, <160>, <165>,
+ <170>, <1725000>, <175>, <1775000>,
+ <180>, <1825000>, <185>, <1875000>,
+ <190>, <1925000>, <195>, <200>;
+ off-on-delay-us = <2>;
+ startup-delay-us = <120>;
+};
+
+ldo4: ldo4@17 { /* 40 PIN */
+ reg = <0x17>;
+ vsel-reg = <0x52>;
+
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <1725000>;
+ regulator-max-microvolt = <190>;
+ regulator-boot-on;
+
+ enable-mask = <0x01>;
+ idle-mode-mask = <0x10>;
+ eco-microamp = <1>;
+
[PATCH 2/8] spmi: hi6421-spmi-pmic: move driver from staging
The Hisilicon 6421v600 SPMI driver is ready for mainstream.
So, move it from staging.
Signed-off-by: Mauro Carvalho Chehab
---
.../spmi/hisilicon,hisi-spmi-controller.yaml | 62 +++
MAINTAINERS | 7 +
drivers/spmi/Kconfig | 9 +
drivers/spmi/Makefile | 1 +
drivers/spmi/hisi-spmi-controller.c | 358 ++
drivers/staging/hikey9xx/Kconfig | 11 -
drivers/staging/hikey9xx/Makefile | 1 -
.../staging/hikey9xx/hisi-spmi-controller.c | 358 --
.../hisilicon,hisi-spmi-controller.yaml | 62 ---
9 files changed, 437 insertions(+), 432 deletions(-)
create mode 100644
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
create mode 100644 drivers/spmi/hisi-spmi-controller.c
delete mode 100644 drivers/staging/hikey9xx/hisi-spmi-controller.c
delete mode 100644 drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml
diff --git
a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
new file mode 100644
index ..f2a56fa4e78e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/hisilicon,hisi-spmi-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon SPMI controller
+
+maintainers:
+ - Mauro Carvalho Chehab
+
+description: |
+ The HiSilicon SPMI BUS controller is found on some Kirin-based designs.
+ It is a MIPI System Power Management (SPMI) controller.
+
+ The PMIC part is provided by
+ drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml.
+
+properties:
+ $nodename:
+pattern: "spmi@[0-9a-f]"
+
+ compatible:
+const: hisilicon,kirin970-spmi-controller
+
+ reg:
+maxItems: 1
+
+ spmi-channel:
+description: |
+ number of the Kirin 970 SPMI channel where the SPMI devices are
connected.
+
+required:
+ - compatible
+ - reg
+ - spmi-channel
+
+patternProperties:
+ "^pmic@[0-9a-f]$":
+description: |
+ PMIC properties, which are specific to the used SPMI PMIC device(s).
+ When used in combination with HiSilicon 6421v600, the properties
+ are documented at
+ drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml.
+
+examples:
+ - |
+bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spmi: spmi@fff24000 {
+compatible = "hisilicon,kirin970-spmi-controller";
+status = "ok";
+reg = <0x0 0xfff24000 0x0 0x1000>;
+spmi-channel = <2>;
+
+pmic@0 {
+ /* pmic properties */
+};
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 14266bb79ff8..14bc7b45ed50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7987,6 +7987,13 @@ F: drivers/crypto/hisilicon/sec2/sec_crypto.c
F: drivers/crypto/hisilicon/sec2/sec_crypto.h
F: drivers/crypto/hisilicon/sec2/sec_main.c
+HISILICON SPMI CONTROLLER DRIVER FOR HIKEY 970
+M: Mauro Carvalho Chehab
+L: linux-ker...@vger.kernel.org
+S: Maintained
+F:
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
+F: drivers/spmi/hisi-spmi-controller.c
+
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab
L: de...@driverdev.osuosl.org
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index a53bad541f1a..2874b6c26028 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -11,6 +11,15 @@ menuconfig SPMI
if SPMI
+config SPMI_HISI3670
+ tristate "Hisilicon 3670 SPMI Controller"
+ select IRQ_DOMAIN_HIERARCHY
+ depends on HAS_IOMEM
+ help
+ If you say yes to this option, support will be included for the
+ built-in SPMI PMIC Arbiter interface on Hisilicon 3670
+ processors.
+
config SPMI_MSM_PMIC_ARB
tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
select IRQ_DOMAIN_HIERARCHY
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
index 55a94cadeffe..6e092e6f290c 100644
--- a/drivers/spmi/Makefile
+++ b/drivers/spmi/Makefile
@@ -4,4 +4,5 @@
#
obj-$(CONFIG_SPMI) += spmi.o
+obj-$(CONFIG_SPMI_HISI3670)+= hisi-spmi-controller.o
obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
diff --git a/drivers/spmi/hisi-spmi-controller.c
b/drivers/spmi/hisi-spmi-controller.c
new file mode 100644
index ..f831c43f4783
--- /dev/null
+++ b/drivers/spmi/hisi-spmi-controller.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * SPMI register addr
+ */
+#define SPMI_CHANNEL_OFFSET0x0300
+#define SPMI_SLAVE_OFFSET
[PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy
The phy USB3 driver for Hisilicon 970 (hi3670) is ready
for mainstream. Mode it from staging into the main driver's
phy/ directory.
Signed-off-by: Mauro Carvalho Chehab
---
.../bindings/phy/phy-hi3670-usb3.yaml | 72 ++
MAINTAINERS | 9 +-
drivers/phy/hisilicon/Kconfig | 10 +
drivers/phy/hisilicon/Makefile| 1 +
drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++
drivers/staging/hikey9xx/Kconfig | 11 -
drivers/staging/hikey9xx/Makefile | 2 -
drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 --
drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 --
9 files changed, 762 insertions(+), 757 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c
delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.c
delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.yaml
diff --git a/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
new file mode 100644
index ..125a5d6546ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,hi3670-usb3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon Kirin970 USB PHY
+
+maintainers:
+ - Mauro Carvalho Chehab
+description: |+
+ Bindings for USB3 PHY on HiSilicon Kirin 970.
+
+properties:
+ compatible:
+const: hisilicon,hi3670-usb-phy
+
+ "#phy-cells":
+const: 0
+
+ hisilicon,pericrg-syscon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: phandle of syscon used to control iso refclk.
+
+ hisilicon,pctrl-syscon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: phandle of syscon used to control usb tcxo.
+
+ hisilicon,sctrl-syscon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: phandle of syscon used to control phy deep sleep.
+
+ hisilicon,eye-diagram-param:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Eye diagram for phy.
+
+ hisilicon,tx-vboost-lvl:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: TX level vboost for phy.
+
+required:
+ - compatible
+ - hisilicon,pericrg-syscon
+ - hisilicon,pctrl-syscon
+ - hisilicon,sctrl-syscon
+ - hisilicon,eye-diagram-param
+ - hisilicon,tx-vboost-lvl
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb3_otg_bc: usb3_otg_bc@ff20 {
+compatible = "syscon", "simple-mfd";
+reg = <0x0 0xff20 0x0 0x1000>;
+
+usb_phy {
+ compatible = "hisilicon,hi3670-usb-phy";
+ #phy-cells = <0>;
+ hisilicon,pericrg-syscon = <&crg_ctrl>;
+ hisilicon,pctrl-syscon = <&pctrl>;
+ hisilicon,sctrl-syscon = <&sctrl>;
+ hisilicon,eye-diagram-param = <0xfdfee4>;
+ hisilicon,tx-vboost-lvl = <0x5>;
+};
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..14266bb79ff8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18083,7 +18083,7 @@ L: linux-...@vger.kernel.org
S: Maintained
F: drivers/usb/roles/intel-xhci-usb-role-switch.c
-USB IP DRIVER FOR HISILICON KIRIN
+USB IP DRIVER FOR HISILICON KIRIN 960
M: Yu Chen
M: Binghui Wang
L: linux-...@vger.kernel.org
@@ -18091,6 +18091,13 @@ S: Maintained
F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
F: drivers/phy/hisilicon/phy-hi3660-usb3.c
+USB IP DRIVER FOR HISILICON KIRIN 970
+M: Mauro Carvalho Chehab
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/hisilicon,kirin970-usb3.yaml
+F: drivers/phy/hisilicon/phy-kirin970-usb3.c
+
USB ISP116X DRIVER
M: Olav Kongas
L: linux-...@vger.kernel.org
diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
index 1c73053bcc98..4d008cfc279c 100644
--- a/drivers/phy/hisilicon/Kconfig
+++ b/drivers/phy/hisilicon/Kconfig
@@ -23,6 +23,16 @@ config PHY_HI3660_USB
To compile this driver as a module, choose M here.
+config PHY_HI3670_USB
+ tristate "hi3670 USB PHY support"
+ depends on (ARCH_HISI && ARM64) || COMPILE_TEST
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable this to support the HISILICON HI3670 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
config PHY_HISTB_COMBPHY
tristate "HiSilicon STB SoCs COMBPHY support"
depends on (ARCH_HISI && ARM64) || COMPILE_TEST
diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
index 92e874ae9c74..51729868145b 100644
--
[PATCH 4/8] regulator: hi6421v600-regulator: move it from staging
This driver is ready for mainstream. Move it out of staging.
Signed-off-by: Mauro Carvalho Chehab
---
MAINTAINERS | 7 +-
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile| 1 +
drivers/regulator/hi6421v600-regulator.c | 478 ++
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/hikey9xx/Kconfig | 11 -
drivers/staging/hikey9xx/Makefile | 3 -
drivers/staging/hikey9xx/TODO | 5 -
.../staging/hikey9xx/hi6421v600-regulator.c | 478 --
10 files changed, 489 insertions(+), 506 deletions(-)
create mode 100644 drivers/regulator/hi6421v600-regulator.c
delete mode 100644 drivers/staging/hikey9xx/Kconfig
delete mode 100644 drivers/staging/hikey9xx/Makefile
delete mode 100644 drivers/staging/hikey9xx/TODO
delete mode 100644 drivers/staging/hikey9xx/hi6421v600-regulator.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 450c7cbc6725..aa68aee9e684 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8000,12 +8000,7 @@ L: linux-ker...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
F: drivers/mfd/hi6421-spmi-pmic.c
-
-HISILICON STAGING DRIVERS FOR HIKEY 960/970
-M: Mauro Carvalho Chehab
-L: de...@driverdev.osuosl.org
-S: Maintained
-F: drivers/staging/hikey9xx/
+F: drivers/regulator/hi6421v600-regulator.c
HISILICON TRUE RANDOM NUMBER GENERATOR V2 SUPPORT
M: Zaibo Xu
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 020a00d6696b..08d302c87fa0 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -394,6 +394,15 @@ config REGULATOR_HI655X
This driver provides support for the voltage regulators of the
Hisilicon Hi655x PMIC device.
+config REGULATOR_HI6421V600
+ tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
+ depends on MFD_HI6421_SPMI && OF
+ depends on REGULATOR
+ help
+ This driver provides support for the voltage regulators on
+ HiSilicon Hi6421v600 PMU / Codec IC.
+ This is used on Kirin 3670 boards, like HiKey 970.
+
config REGULATOR_ISL9305
tristate "Intersil ISL9305 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6ebae516258e..45d1883de54b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_REGULATOR_FAN53880) += fan53880.o
obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
+obj-$(CONFIG_REGULATOR_HI6421V600) += hi6421v600-regulator.o
obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
diff --git a/drivers/regulator/hi6421v600-regulator.c
b/drivers/regulator/hi6421v600-regulator.c
new file mode 100644
index ..614b03c9ddfb
--- /dev/null
+++ b/drivers/regulator/hi6421v600-regulator.c
@@ -0,0 +1,478 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device driver for regulators in Hisi IC
+ *
+ * Copyright (c) 2013 Linaro Ltd.
+ * Copyright (c) 2011 Hisilicon.
+ *
+ * Guodong Xu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define rdev_dbg(rdev, fmt, arg...)\
+pr_debug("%s: %s: " fmt, (rdev)->desc->name, __func__, ##arg)
+
+struct hi6421v600_regulator {
+ struct regulator_desc rdesc;
+ struct hi6421_spmi_pmic *pmic;
+ u32 eco_mode_mask, eco_uA;
+};
+
+static DEFINE_MUTEX(enable_mutex);
+
+/*
+ * helper function to ensure when it returns it is at least 'delay_us'
+ * microseconds after 'since'.
+ */
+
+static int hi6421_spmi_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ struct hi6421v600_regulator *sreg = rdev_get_drvdata(rdev);
+ struct hi6421_spmi_pmic *pmic = sreg->pmic;
+ u32 reg_val;
+
+ reg_val = hi6421_spmi_pmic_read(pmic, rdev->desc->enable_reg);
+
+ rdev_dbg(rdev,
+"enable_reg=0x%x, val= 0x%x, enable_state=%d\n",
+rdev->desc->enable_reg,
+reg_val, (reg_val
[PATCH v3 3/6] ARM: dts: sun8i: v3s: Add node for system control
Allwinner V3s has system control and SRAM C1 region similar to H3.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 0c7341676921..70193512c222 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -161,6 +161,20 @@ syscon: system-control@1c0 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ sram_c: sram@1d0 {
+ compatible = "mmio-sram";
+ reg = <0x01d0 0x8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x01d0 0x8>;
+
+ ve_sram: sram-section@0 {
+ compatible =
"allwinner,sun8i-v3s-sram-c1",
+
"allwinner,sun4i-a10-sram-c1";
+ reg = <0x00 0x8>;
+ };
+ };
};
tcon0: lcd-controller@1c0c000 {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 6/6] ARM: dts: sun8i: v3s: Add video engine node
Allwinner V3S SoC has a video engine.
Add a node for it.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 70193512c222..e8f304125e2d 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -211,6 +211,16 @@ tcon0_out: port@1 {
};
};
+ video-codec@1c0e000 {
+ compatible = "allwinner,sun8i-v3s-video-engine";
+ reg = <0x01c0e000 0x1000>;
+ clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+<&ccu CLK_DRAM_VE>;
+ clock-names = "ahb", "mod", "ram";
+ resets = <&ccu RST_BUS_VE>;
+ interrupts = ;
+ allwinner,sram = <&ve_sram 1>;
+ };
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/6] ARM: dts: sun8i: v3s: Enable video decoder
First patch extends cedrus capability to all decoders because V3s missing MPEG2 decoder. Next two patches add system control node (SRAM C1) and next three patches add support for Cedrus VPU. Tested on "Lichee Zero" V3s platform with testing LCD patch ( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e ) and V4L2 raw API testing utility (updated to v5.10) ( https://github.com/mcerveny/v4l2-request-test ): - enabled LCD (DRM dual VI and sigle UI planes) - added RGB panel - enabled PWM - need additional patch https://git.linuxtv.org/media_tree.git/commit/?h=fixes&id=9ac924b98728c3733c91c6c59fc410827d0da49f There is low memory on V3s (64MB) and maximum must be available to CMA: - CONFIG_CMA_SIZE_MBYTES=28 - add swap to swapout other processes - decrease buffers in v4l2-request-test (.buffers_count from 16 to 8) Only H.264 decoder working - MPEG and H.265 unsupported by V3s, JPEG/MJPEG still unimplemented, encoder unimplemented best regards, Martin Changes since v2: - updated/rebased to https://git.linuxtv.org/hverkuil/media_tree.git/?h=for-v5.11e - some parts of patches implemeted by others - updated R40 Changes since v1: - patch 0005 rename - added testing description Martin Cerveny (6): media: cedrus: Register all codecs as capability dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s compatibles ARM: dts: sun8i: v3s: Add node for system control media: cedrus: Add support for V3s dt-bindings: media: cedrus: Add V3s compatible ARM: dts: sun8i: v3s: Add video engine node .../allwinner,sun4i-a10-video-engine.yaml | 1 + .../allwinner,sun4i-a10-system-control.yaml | 3 ++ arch/arm/boot/dts/sun8i-v3s.dtsi | 24 ++ drivers/staging/media/sunxi/cedrus/cedrus.c | 32 +-- drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++ .../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++ 6 files changed, 62 insertions(+), 2 deletions(-) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/6] dt-bindings: sram: allwinner, sun4i-a10-system-control: Add V3s compatibles
Allwinner V3s has system control similar to that in H3. Add compatibles for system control with SRAM C1 region. Signed-off-by: Martin Cerveny --- .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index b66a07e21d1e..bdd352b01434 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -92,6 +92,9 @@ patternProperties: - items: - const: allwinner,sun8i-h3-sram-c1 - const: allwinner,sun4i-a10-sram-c1 + - items: + - const: allwinner,sun8i-v3s-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - const: allwinner,sun8i-r40-sram-c1 - const: allwinner,sun4i-a10-sram-c1 -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 5/6] dt-bindings: media: cedrus: Add V3s compatible
Allwinner V3s SoC contains video engine. Add compatible for it. Signed-off-by: Martin Cerveny --- .../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml index 0d58bbcd24d3..2f7058f7760c 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml @@ -18,6 +18,7 @@ properties: - allwinner,sun7i-a20-video-engine - allwinner,sun8i-a33-video-engine - allwinner,sun8i-h3-video-engine + - allwinner,sun8i-v3s-video-engine - allwinner,sun8i-r40-video-engine - allwinner,sun50i-a64-video-engine - allwinner,sun50i-h5-video-engine -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/6] media: cedrus: Add support for V3s
V3s video engine runs at lower speed and support video decoder
for H.264 and JPEG/MJPEG only.
Signed-off-by: Martin Cerveny
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 3487554fab68..ee4e21b29374 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -518,6 +518,12 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant
= {
.mod_rate = 40200,
};
+static const struct cedrus_variant sun8i_v3s_cedrus_variant = {
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H264_DEC,
+ .mod_rate = 29700,
+};
+
static const struct cedrus_variant sun8i_r40_cedrus_variant = {
.capabilities = CEDRUS_CAPABILITY_UNTILED |
CEDRUS_CAPABILITY_MPEG2_DEC |
@@ -571,6 +577,10 @@ static const struct of_device_id cedrus_dt_match[] = {
.compatible = "allwinner,sun8i-h3-video-engine",
.data = &sun8i_h3_cedrus_variant,
},
+ {
+ .compatible = "allwinner,sun8i-v3s-video-engine",
+ .data = &sun8i_v3s_cedrus_variant,
+ },
{
.compatible = "allwinner,sun8i-r40-video-engine",
.data = &sun8i_r40_cedrus_variant,
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/6] media: cedrus: Register all codecs as capability
All codecs should have capabilities.
For example "Allwinner V3s" does not support "MPEG2".
Signed-off-by: Martin Cerveny
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 22 +--
drivers/staging/media/sunxi/cedrus/cedrus.h | 2 ++
.../staging/media/sunxi/cedrus/cedrus_video.c | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 9a102b7c1bb9..3487554fab68 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -486,47 +486,65 @@ static int cedrus_remove(struct platform_device *pdev)
}
static const struct cedrus_variant sun4i_a10_cedrus_variant = {
+ .capabilities = CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC,
.mod_rate = 32000,
};
static const struct cedrus_variant sun5i_a13_cedrus_variant = {
+ .capabilities = CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC,
.mod_rate = 32000,
};
static const struct cedrus_variant sun7i_a20_cedrus_variant = {
+ .capabilities = CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC,
.mod_rate = 32000,
};
static const struct cedrus_variant sun8i_a33_cedrus_variant = {
- .capabilities = CEDRUS_CAPABILITY_UNTILED,
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC,
.mod_rate = 32000,
};
static const struct cedrus_variant sun8i_h3_cedrus_variant = {
.capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC |
CEDRUS_CAPABILITY_H265_DEC,
.mod_rate = 40200,
};
static const struct cedrus_variant sun8i_r40_cedrus_variant = {
- .capabilities = CEDRUS_CAPABILITY_UNTILED,
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC,
.mod_rate = 29700,
};
static const struct cedrus_variant sun50i_a64_cedrus_variant = {
.capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC |
CEDRUS_CAPABILITY_H265_DEC,
.mod_rate = 40200,
};
static const struct cedrus_variant sun50i_h5_cedrus_variant = {
.capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC |
CEDRUS_CAPABILITY_H265_DEC,
.mod_rate = 40200,
};
static const struct cedrus_variant sun50i_h6_cedrus_variant = {
.capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_MPEG2_DEC |
+ CEDRUS_CAPABILITY_H264_DEC |
CEDRUS_CAPABILITY_H265_DEC,
.quirks = CEDRUS_QUIRK_NO_DMA_OFFSET,
.mod_rate = 6,
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 93c843ae14bb..30cdb15d6800 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -28,6 +28,8 @@
#define CEDRUS_CAPABILITY_UNTILED BIT(0)
#define CEDRUS_CAPABILITY_H265_DEC BIT(1)
+#define CEDRUS_CAPABILITY_H264_DEC BIT(2)
+#define CEDRUS_CAPABILITY_MPEG2_DECBIT(3)
#define CEDRUS_QUIRK_NO_DMA_OFFSET BIT(0)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 911f607d9b09..bdca23fc214b 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -38,10 +38,12 @@ static struct cedrus_format cedrus_formats[] = {
{
.pixelformat= V4L2_PIX_FMT_MPEG2_SLICE,
.directions = CEDRUS_DECODE_SRC,
+ .capabilities = CEDRUS_CAPABILITY_MPEG2_DEC,
},
{
.pixelformat= V4L2_PIX_FMT_H264_SLICE,
.directions = CEDRUS_DECODE_SRC,
+ .capabilities = CEDRUS_CAPABILITY_H264_DEC,
},
{
.pixelformat= V4L2_PIX_FMT_HEVC_SLICE,
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote: > 13.11.2020 20:28, Mark Brown пишет: > >> What should we do? > > As I keep saying the consumer driver should be enumerating the voltages > > it can set, if it can't find any and wants to continue then it can just > > skip setting voltages later on. If only some are unavailable then it > > probably wants to eliminate those specific OPPs instead. > I'm seeing a dummy regulator as a helper for consumer drivers which > removes burden of handling an absent (optional) regulator. Is this a > correct understanding of a dummy regulator? > Older DTBs don't have a regulator and we want to keep them working. This > is equal to a physically absent regulator and in this case it's an > optional regulator, IMO. No, you are failing to understand the purpose of this code. To reiterate unless the device supports operating with the supply physically absent then the driver should not be attempting to use regulator_get_optional(). That exists specifically for the case where the supply may be absent, nothing else. The dummy regulator is there precisely for the case where the system does not describe supplies that we know are required for the device to function, it fixes up that omission so we don't need to open code handling of this in every single consumer driver. Regulators that are present but not described by the firmware are a clearly different case to regulators that are not physically there, hardware with actually optional regulators will generally require some configuration for this case. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy
On Mon, Nov 16, 2020 at 01:59:27PM +0100, Mauro Carvalho Chehab wrote:
> The phy USB3 driver for Hisilicon 970 (hi3670) is ready
> for mainstream. Mode it from staging into the main driver's
s/Mode/Move/
> phy/ directory.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../bindings/phy/phy-hi3670-usb3.yaml | 72 ++
> MAINTAINERS | 9 +-
> drivers/phy/hisilicon/Kconfig | 10 +
> drivers/phy/hisilicon/Makefile| 1 +
> drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++
> drivers/staging/hikey9xx/Kconfig | 11 -
> drivers/staging/hikey9xx/Makefile | 2 -
> drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 --
> drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 --
I assume this is only a move? Use '-M' option.
> 9 files changed, 762 insertions(+), 757 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
> create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c
> delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.c
> delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
> b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
> new file mode 100644
> index ..125a5d6546ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/hisilicon,hi3670-usb3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Hisilicon Kirin970 USB PHY
> +
> +maintainers:
> + - Mauro Carvalho Chehab
> +description: |+
> + Bindings for USB3 PHY on HiSilicon Kirin 970.
> +
> +properties:
> + compatible:
> +const: hisilicon,hi3670-usb-phy
> +
> + "#phy-cells":
> +const: 0
> +
> + hisilicon,pericrg-syscon:
> +$ref: '/schemas/types.yaml#/definitions/phandle'
> +description: phandle of syscon used to control iso refclk.
> +
> + hisilicon,pctrl-syscon:
> +$ref: '/schemas/types.yaml#/definitions/phandle'
> +description: phandle of syscon used to control usb tcxo.
> +
> + hisilicon,sctrl-syscon:
> +$ref: '/schemas/types.yaml#/definitions/phandle'
> +description: phandle of syscon used to control phy deep sleep.
> +
> + hisilicon,eye-diagram-param:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Eye diagram for phy.
> +
> + hisilicon,tx-vboost-lvl:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: TX level vboost for phy.
> +
> +required:
> + - compatible
> + - hisilicon,pericrg-syscon
> + - hisilicon,pctrl-syscon
> + - hisilicon,sctrl-syscon
> + - hisilicon,eye-diagram-param
> + - hisilicon,tx-vboost-lvl
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + usb3_otg_bc: usb3_otg_bc@ff20 {
> +compatible = "syscon", "simple-mfd";
> +reg = <0x0 0xff20 0x0 0x1000>;
> +
> +usb_phy {
> + compatible = "hisilicon,hi3670-usb-phy";
> + #phy-cells = <0>;
> + hisilicon,pericrg-syscon = <&crg_ctrl>;
> + hisilicon,pctrl-syscon = <&pctrl>;
> + hisilicon,sctrl-syscon = <&sctrl>;
> + hisilicon,eye-diagram-param = <0xfdfee4>;
> + hisilicon,tx-vboost-lvl = <0x5>;
> +};
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e451dcce054f..14266bb79ff8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18083,7 +18083,7 @@ L:linux-...@vger.kernel.org
> S: Maintained
> F: drivers/usb/roles/intel-xhci-usb-role-switch.c
>
> -USB IP DRIVER FOR HISILICON KIRIN
> +USB IP DRIVER FOR HISILICON KIRIN 960
> M: Yu Chen
> M: Binghui Wang
> L: linux-...@vger.kernel.org
> @@ -18091,6 +18091,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
> F: drivers/phy/hisilicon/phy-hi3660-usb3.c
>
> +USB IP DRIVER FOR HISILICON KIRIN 970
> +M: Mauro Carvalho Chehab
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/phy/hisilicon,kirin970-usb3.yaml
> +F: drivers/phy/hisilicon/phy-kirin970-usb3.c
> +
> USB ISP116X DRIVER
> M: Olav Kongas
> L: linux-...@vger.kernel.org
> diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
> index 1c73053bcc98..4d008cfc279c 100644
> --- a/drivers/phy/hisilicon/Kconfig
> +++ b/drivers/phy/hisilicon/Kconfig
> @@ -23,6 +23,16 @@ config PHY_HI3660_USB
>
> To compile this driver as a module, choose M here.
>
> +config PHY_HI3670_USB
> + tristate "hi3670 USB PHY support"
> + depends on (ARCH_HISI && ARM64) || COMPILE_TEST
> + select GENERIC_PHY
> + select MFD_SYSCON
> + help
> +
Re: [PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy
On Mon, 16 Nov 2020 13:59:27 +0100, Mauro Carvalho Chehab wrote: > The phy USB3 driver for Hisilicon 970 (hi3670) is ready > for mainstream. Mode it from staging into the main driver's > phy/ directory. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../bindings/phy/phy-hi3670-usb3.yaml | 72 ++ > MAINTAINERS | 9 +- > drivers/phy/hisilicon/Kconfig | 10 + > drivers/phy/hisilicon/Makefile| 1 + > drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++ > drivers/staging/hikey9xx/Kconfig | 11 - > drivers/staging/hikey9xx/Makefile | 2 - > drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 -- > drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 -- > 9 files changed, 762 insertions(+), 757 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml > create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c > delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.c > delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/phy/phy-hi3670-usb3.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/phy/phy-hi3670-usb3.yaml# See https://patchwork.ozlabs.org/patch/1400895 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/8] spmi: hi6421-spmi-pmic: move driver from staging
On Mon, 16 Nov 2020 13:59:28 +0100, Mauro Carvalho Chehab wrote: > The Hisilicon 6421v600 SPMI driver is ready for mainstream. > > So, move it from staging. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../spmi/hisilicon,hisi-spmi-controller.yaml | 62 +++ > MAINTAINERS | 7 + > drivers/spmi/Kconfig | 9 + > drivers/spmi/Makefile | 1 + > drivers/spmi/hisi-spmi-controller.c | 358 ++ > drivers/staging/hikey9xx/Kconfig | 11 - > drivers/staging/hikey9xx/Makefile | 1 - > .../staging/hikey9xx/hisi-spmi-controller.c | 358 -- > .../hisilicon,hisi-spmi-controller.yaml | 62 --- > 9 files changed, 437 insertions(+), 432 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml > create mode 100644 drivers/spmi/hisi-spmi-controller.c > delete mode 100644 drivers/staging/hikey9xx/hisi-spmi-controller.c > delete mode 100644 > drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml:34:2: [warning] wrong indentation: expected 2 but found 1 (indentation) dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml: 'additionalProperties' is a required property /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml: ignoring, error in schema: warning: no schema found in file: ./Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.example.dts:29.20-31.15: Warning (unit_address_vs_reg): /example-0/bus/spmi@fff24000/pmic@0: node has a unit name, but no reg or ranges property /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.example.dt.yaml: spmi@fff24000: pmic@0: 'reg' is a required property From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/spmi/spmi.yaml See https://patchwork.ozlabs.org/patch/1400897 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/8] mfd: hi6421-spmi-pmic: move driver from staging
On Mon, 16 Nov 2020 13:59:29 +0100, Mauro Carvalho Chehab wrote: > This driver is ready for mainstream. So, move it out of staging. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 159 > MAINTAINERS | 7 + > drivers/mfd/Kconfig | 15 + > drivers/mfd/Makefile | 1 + > drivers/mfd/hi6421-spmi-pmic.c| 342 ++ > drivers/staging/hikey9xx/Kconfig | 16 - > drivers/staging/hikey9xx/Makefile | 1 - > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 342 -- > .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 159 > 9 files changed, 524 insertions(+), 518 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > create mode 100644 drivers/mfd/hi6421-spmi-pmic.c > delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c > delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml: 'additionalProperties' is a required property /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml: ignoring, error in schema: warning: no schema found in file: ./Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml See https://patchwork.ozlabs.org/patch/1400898 The base for the patch is generally the last rc1. Any dependencies should be noted. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/8] regulator: hi6421v600-regulator: move it from staging
On Mon, Nov 16, 2020 at 01:59:30PM +0100, Mauro Carvalho Chehab wrote:
> This driver is ready for mainstream. Move it out of staging.
There's quite a few issues here, to be honest I'm disappointed some of
them weren't caught during staging review, this needs fairly substantial
work and there's signs that this also applies to at least the MFD
portion.
This also appears to be missing a DT binding document, binding
documentation is required for anything with DT support.
> +config REGULATOR_HI6421V600
> + tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
> + depends on MFD_HI6421_SPMI && OF
> + depends on REGULATOR
This is inside an if REGULATOR block, as with all the other regulator
drivers it doesn't need a dependency on REGULATOR.
> --- /dev/null
> +++ b/drivers/regulator/hi6421v600-regulator.c
> @@ -0,0 +1,478 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device driver for regulators in Hisi IC
Please make the entire comment a C++ one so things look more
intentional.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Are we sure about *all* these includes?
> +#define rdev_dbg(rdev, fmt, arg...) \
> + pr_debug("%s: %s: " fmt, (rdev)->desc->name, __func__, ##arg)
If it is useful to copy this then put it in a header rather than
cut'n'pasting it. I'm not sure I see a pressing need for most of the
trace here, it looks to be duplicating a lot of things the core does for
you.
> +static DEFINE_MUTEX(enable_mutex);
Drivers shouldn't be declaring global variables, if this is required it
should be allocated in driver data.
> +/*
> + * helper function to ensure when it returns it is at least 'delay_us'
> + * microseconds after 'since'.
> + */
> +
> +static int hi6421_spmi_regulator_is_enabled(struct regulator_dev *rdev)
The helper function appears to have been removed?
> +{
> + struct hi6421v600_regulator *sreg = rdev_get_drvdata(rdev);
> + struct hi6421_spmi_pmic *pmic = sreg->pmic;
> + u32 reg_val;
> +
> + reg_val = hi6421_spmi_pmic_read(pmic, rdev->desc->enable_reg);
> +
> + rdev_dbg(rdev,
> + "enable_reg=0x%x, val= 0x%x, enable_state=%d\n",
> + rdev->desc->enable_reg,
> + reg_val, (reg_val & rdev->desc->enable_mask));
> +
> + return ((reg_val & rdev->desc->enable_mask) != 0);
> +}
It looks like it would be less code overall to just implement a regmap
for the MFD, even if it were only used in this driver - almost
everything in here is just a carbon copy of standard helpers that the
core provides for regmap devices. Doing it in the MFD would be more
idiomatic for everything though.
> +static int hi6421_spmi_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct hi6421v600_regulator *sreg = rdev_get_drvdata(rdev);
> + struct hi6421_spmi_pmic *pmic = sreg->pmic;
> +
> + /* cannot enable more than one regulator at one time */
> + mutex_lock(&enable_mutex);
> + usleep_range(HISI_REGS_ENA_PROTECT_TIME,
> + HISI_REGS_ENA_PROTECT_TIME + 1000);
> +
> + /* set enable register */
> + rdev_dbg(rdev,
> + "off_on_delay=%d us, enable_reg=0x%x, enable_mask=0x%x\n",
> + rdev->desc->off_on_delay, rdev->desc->enable_reg,
> + rdev->desc->enable_mask);
> +
> + hi6421_spmi_pmic_rmw(pmic, rdev->desc->enable_reg,
> + rdev->desc->enable_mask,
> + rdev->desc->enable_mask);
This is the one operation which is doing anything unusual and which I'd
expect to be open coded in the driver - obviously this is a pretty
simplistic implementation but it will work though as indicated above it
shouldn't be using a global, the mutex should be in driver data. I
guess you could use the mutex to protect a timestamp and use that to
figure out if a delay is actually needed?
> +static int hi6421_spmi_dt_parse(struct platform_device *pdev,
> + struct hi6421v600_regulator *sreg,
> + struct regulator_desc *rdesc)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + unsigned int *v_table;
> + int ret;
> +
> + ret = of_property_read_u32(np, "reg", &rdesc->enable_reg);
> + if (ret) {
> + dev_err(dev, "missing reg property\n");
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "vsel-reg", &rdesc->vsel_reg);
There is no way this stuff should be being parsed out of DT, we should
know the register map for the device and what regulators it has based
purely off knowing what device we have. Baking the register map into
the ABI is bad practice, it prevents us from improving our support for
the hardware without going and updating people's DTs.
> + /*
> +
Re: [PATCH 2/7] dt: bindings: add mt7621-pll device tree binding documentation
On Wed, 11 Nov 2020 17:30:08 +0100, Sergio Paracuellos wrote: > Adds device tree binding documentation for PLL controller in > the MT7621 SOC. > > Signed-off-by: Sergio Paracuellos > --- > .../bindings/clock/mediatek,mt7621-pll.yaml | 51 +++ > 1 file changed, 51 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Fix warning for static const char * array in audio_manager_module.c
On 11/15/20 9:17 AM, Greg Kroah-Hartman wrote:
> On Sun, Nov 15, 2020 at 03:53:16PM +0100, Emmanouil Perselis wrote:
>> This patch fixes the warning "static const char * array should
>> probably be static const char * const" in
>> drivers/staging/greybus/audio_manager_module.c
>> I think Greg's patch bot is telling you that you need
>> to carbon-copy the mailing list on your patch submission,
>> not just address it to the maintainers.
Added addresses to carbon copy.
>> -Alex
>>
>> Signed-off-by: Emmanouil Perselis
>> ---
>> drivers/staging/greybus/audio_manager_module.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/greybus/audio_manager_module.c
>> b/drivers/staging/greybus/audio_manager_module.c
>> index 2bfd804183c4..6ef7381f4e85 100644
>> --- a/drivers/staging/greybus/audio_manager_module.c
>> +++ b/drivers/staging/greybus/audio_manager_module.c
>> @@ -158,7 +158,7 @@ static void send_add_uevent(struct
>> gb_audio_manager_module *module)
>> char ip_devices_string[64];
>> char op_devices_string[64];
>>
>> -char *envp[] = {
>> +static const char * const envp[] = {
>> name_string,
>> vid_string,
>> pid_string,
>> --
>> 2.20.1
>>
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> a patch that has triggered this response. He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created. Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - Your patch was sent privately to Greg. Kernel development is done in
>public, please always cc: a public mailing list with a patch
>submission. Using the tool, scripts/get_maintainer.pl on the patch
>will tell you what mailing list to cc.
>
> - You did not specify a description of why the patch is needed, or
>possibly, any description at all, in the email body. Please read the
>section entitled "The canonical patch format" in the kernel file,
>Documentation/SubmittingPatches for what is needed in order to
>properly describe the change.
>
> - You did not write a descriptive Subject: for the patch, allowing Greg,
>and everyone else, to know what this patch is all about. Please read
>the section entitled "The canonical patch format" in the kernel file,
>Documentation/SubmittingPatches for what a proper Subject: line should
>look like.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
Signed-off-by: Emmanouil Perselis
---
drivers/staging/greybus/audio_manager_module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c
b/drivers/staging/greybus/audio_manager_module.c
index 2bfd804183c4..6ef7381f4e85 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -158,7 +158,7 @@ static void send_add_uevent(struct gb_audio_manager_module
*module)
char ip_devices_string[64];
char op_devices_string[64];
- char *envp[] = {
+ static const char * const envp[] = {
name_string,
vid_string,
pid_string,
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fix warning for static const char * array in audio_manager_module.c
Hi Emmanouil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.10-rc4 next-20201116]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Emmanouil-Perselis/Fix-warning-for-static-const-char-array-in-audio_manager_module-c/20201117-044852
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
0d79a48440f559ac939d1be2089757c5e4ab16c7
config: microblaze-randconfig-r011-20201116 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/69022592162daaee87b29588cd562da4439f0517
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Emmanouil-Perselis/Fix-warning-for-static-const-char-array-in-audio_manager_module-c/20201117-044852
git checkout 69022592162daaee87b29588cd562da4439f0517
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=microblaze
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/staging/greybus/audio_manager_module.c: In function
'send_add_uevent':
>> drivers/staging/greybus/audio_manager_module.c:162:3: error: initializer
>> element is not constant
162 | name_string,
| ^~~
drivers/staging/greybus/audio_manager_module.c:162:3: note: (near
initialization for 'envp[0]')
drivers/staging/greybus/audio_manager_module.c:163:3: error: initializer
element is not constant
163 | vid_string,
| ^~
drivers/staging/greybus/audio_manager_module.c:163:3: note: (near
initialization for 'envp[1]')
drivers/staging/greybus/audio_manager_module.c:164:3: error: initializer
element is not constant
164 | pid_string,
| ^~
drivers/staging/greybus/audio_manager_module.c:164:3: note: (near
initialization for 'envp[2]')
drivers/staging/greybus/audio_manager_module.c:165:3: error: initializer
element is not constant
165 | intf_id_string,
| ^~
drivers/staging/greybus/audio_manager_module.c:165:3: note: (near
initialization for 'envp[3]')
drivers/staging/greybus/audio_manager_module.c:166:3: error: initializer
element is not constant
166 | ip_devices_string,
| ^
drivers/staging/greybus/audio_manager_module.c:166:3: note: (near
initialization for 'envp[4]')
drivers/staging/greybus/audio_manager_module.c:167:3: error: initializer
element is not constant
167 | op_devices_string,
| ^
drivers/staging/greybus/audio_manager_module.c:167:3: note: (near
initialization for 'envp[5]')
>> drivers/staging/greybus/audio_manager_module.c:180:46: error: passing
>> argument 3 of 'kobject_uevent_env' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
180 | kobject_uevent_env(&module->kobj, KOBJ_ADD, envp);
| ^~~~
| |
| const char * const*
In file included from drivers/staging/greybus/audio_manager.h:11,
from drivers/staging/greybus/audio_manager_module.c:10:
include/linux/kobject.h:241:10: note: expected 'char **' but argument is of
type 'const char * const*'
241 |char *envp[]);
|~~^~
cc1: some warnings being treated as errors
vim +162 drivers/staging/greybus/audio_manager_module.c
8db00736d365b75 Svetlin Ankov 2016-01-13 151
8db00736d365b75 Svetlin Ankov 2016-01-13 152 static void
send_add_uevent(struct gb_audio_manager_module *module)
8db00736d365b75 Svetlin Ankov 2016-01-13 153 {
8db00736d365b75 Svetlin Ankov 2016-01-13 154 char name_string[128];
8db00736d365b75 Svetlin Ankov 2016-01-13 155 char vid_string[64];
8db00736d365b75 Svetlin Ankov 2016-01-13 156 char pid_string[64];
d0af1bd5f6f4497 Pankaj Bharadiya 2016-10-16 157 char intf_id_string[64];
a9234bfd6cec442 Vaibhav Agarwal2016-03-30 158 char
ip_devices_string[64];
a9234bfd6cec442 Vaibhav Agarwal2016-03-30 159 char
op_devices_string[64];
8db00736d365b75 Svetlin Ankov 2016-01-13 160
69022592162daae Emmanouil Perselis 2020-11-16
[PATCH] [media] omap4iss: return error code when omap4iss_get() failed
If omap4iss_get() failed, it need return error code in iss_probe().
Fixes: 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...")
Reported-by: Hulk Robot
Signed-off-by: Yang Yingliang
---
drivers/staging/media/omap4iss/iss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/omap4iss/iss.c
b/drivers/staging/media/omap4iss/iss.c
index e06ea7ea1e50..3dac35f68238 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -1236,8 +1236,10 @@ static int iss_probe(struct platform_device *pdev)
if (ret < 0)
goto error;
- if (!omap4iss_get(iss))
+ if (!omap4iss_get(iss)) {
+ ret = -EINVAL;
goto error;
+ }
ret = iss_reset(iss);
if (ret < 0)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fieldbus: use kobj_to_dev() to get device
Use kobj_to_dev() instead of container_of()
Signed-off-by: Ding Xiang
---
drivers/staging/fieldbus/dev_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fieldbus/dev_core.c
b/drivers/staging/fieldbus/dev_core.c
index 1ba0234cc60d..5aab734606ea 100644
--- a/drivers/staging/fieldbus/dev_core.c
+++ b/drivers/staging/fieldbus/dev_core.c
@@ -134,7 +134,7 @@ static struct attribute *fieldbus_attrs[] = {
static umode_t fieldbus_is_visible(struct kobject *kobj, struct attribute
*attr,
int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct fieldbus_dev *fb = dev_get_drvdata(dev);
umode_t mode = attr->mode;
--
2.28.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fix warning for static const char * array in audio_manager_module.c
Hi Emmanouil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.10-rc4 next-20201116]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Emmanouil-Perselis/Fix-warning-for-static-const-char-array-in-audio_manager_module-c/20201117-044852
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
0d79a48440f559ac939d1be2089757c5e4ab16c7
config: x86_64-randconfig-a006-20201115 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ace9653c11c6308401dcda2e8b26bf97e6e66e30)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/69022592162daaee87b29588cd562da4439f0517
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Emmanouil-Perselis/Fix-warning-for-static-const-char-array-in-audio_manager_module-c/20201117-044852
git checkout 69022592162daaee87b29588cd562da4439f0517
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/staging/greybus/audio_manager_module.c:162:3: error: initializer
>> element is not a compile-time constant
name_string,
^~~
>> drivers/staging/greybus/audio_manager_module.c:180:46: error: passing 'const
>> char *const [7]' to parameter of type 'char **' discards qualifiers in
>> nested pointer types
>> [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
kobject_uevent_env(&module->kobj, KOBJ_ADD, envp);
^~~~
include/linux/kobject.h:241:10: note: passing argument to parameter 'envp'
here
char *envp[]);
^
2 errors generated.
vim +162 drivers/staging/greybus/audio_manager_module.c
8db00736d365b7 Svetlin Ankov 2016-01-13 151
8db00736d365b7 Svetlin Ankov 2016-01-13 152 static void
send_add_uevent(struct gb_audio_manager_module *module)
8db00736d365b7 Svetlin Ankov 2016-01-13 153 {
8db00736d365b7 Svetlin Ankov 2016-01-13 154 char name_string[128];
8db00736d365b7 Svetlin Ankov 2016-01-13 155 char vid_string[64];
8db00736d365b7 Svetlin Ankov 2016-01-13 156 char pid_string[64];
d0af1bd5f6f449 Pankaj Bharadiya 2016-10-16 157 char intf_id_string[64];
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 158 char
ip_devices_string[64];
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 159 char
op_devices_string[64];
8db00736d365b7 Svetlin Ankov 2016-01-13 160
69022592162daa Emmanouil Perselis 2020-11-16 161 static const char *
const envp[] = {
8db00736d365b7 Svetlin Ankov 2016-01-13 @162 name_string,
8db00736d365b7 Svetlin Ankov 2016-01-13 163 vid_string,
8db00736d365b7 Svetlin Ankov 2016-01-13 164 pid_string,
d0af1bd5f6f449 Pankaj Bharadiya 2016-10-16 165 intf_id_string,
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 166
ip_devices_string,
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 167
op_devices_string,
8db00736d365b7 Svetlin Ankov 2016-01-13 168 NULL
8db00736d365b7 Svetlin Ankov 2016-01-13 169 };
8db00736d365b7 Svetlin Ankov 2016-01-13 170
8db00736d365b7 Svetlin Ankov 2016-01-13 171 snprintf(name_string,
128, "NAME=%s", module->desc.name);
8db00736d365b7 Svetlin Ankov 2016-01-13 172 snprintf(vid_string,
64, "VID=%d", module->desc.vid);
8db00736d365b7 Svetlin Ankov 2016-01-13 173 snprintf(pid_string,
64, "PID=%d", module->desc.pid);
d0af1bd5f6f449 Pankaj Bharadiya 2016-10-16 174
snprintf(intf_id_string, 64, "INTF_ID=%d", module->desc.intf_id);
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 175
snprintf(ip_devices_string, 64, "I/P DEVICES=0x%X",
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 176
module->desc.ip_devices);
a9234bfd6cec44 Vaibhav Agarwal2016-03-30 177
snprintf(op_devices_string, 64, "O/P DEVICES=0x%X",
a9234bfd6cec44 Vaibhav Agarwa
Re: [RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds
On 11/15/20 11:09 AM, Krzysztof Kozlowski wrote:
> COMMON_CLK is a user-selectable option with its own dependencies. The
> most important dependency is !HAVE_LEGACY_CLK. User-selectable drivers
> should not select COMMON_CLK because they will create a dependency cycle
> and build failures. For example on MIPS a configuration with COMMON_CLK
> (selected by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (selected by
> SOC_RT305X) is possible:
Ah, that makes sense.
>
> WARNING: unmet direct dependencies detected for COMMON_CLK
> Depends on [n]: !HAVE_LEGACY_CLK [=y]
> Selected by [y]:
> - SND_SUN8I_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y]
> &&
> (ARCH_SUNXI || COMPILE_TEST [=y]) && OF [=y] && (MACH_SUN8I || ARM64 &&
> ARCH_SUNXI || COMPILE_TEST [=y])
>
> /usr/bin/mips-linux-gnu-ld: drivers/clk/clk.o: in function `clk_set_rate':
> (.text+0xaeb4): multiple definition of `clk_set_rate';
> arch/mips/ralink/clk.o:(.text+0x88): first defined here
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/mach-sunxi/Kconfig | 1 +
> sound/soc/sunxi/Kconfig | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index eeadb1a4dcfe..4d9f9b6d329d 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -4,6 +4,7 @@ menuconfig ARCH_SUNXI
> depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_MMIO
> + select COMMON_CLK
This is not necessary, since ARCH_SUNXI depends (through ARCH_MULTI_V{5,7}) on
ARCH_MULTIPLATFORM, which selects COMMON_CLK already.
> select GENERIC_IRQ_CHIP
> select GPIOLIB
> select PINCTRL
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 69b9d8515335..ddcaaa98d3cb 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -14,7 +14,7 @@ config SND_SUN8I_CODEC
> tristate "Allwinner SUN8I audio codec"
> depends on OF
> depends on MACH_SUN8I || (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> - select COMMON_CLK
> + depends on COMMON_CLK
> select REGMAP_MMIO
> help
> This option enables the digital part of the internal audio codec for
>
For this file:
Reviewed-by: Samuel Holland
Thanks,
Samuel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/7] dt: bindings: add mt7621-pll device tree binding documentation
Hi Rob, On Mon, Nov 16, 2020 at 8:16 PM Rob Herring wrote: > > On Wed, 11 Nov 2020 17:30:08 +0100, Sergio Paracuellos wrote: > > Adds device tree binding documentation for PLL controller in > > the MT7621 SOC. > > > > Signed-off-by: Sergio Paracuellos > > --- > > .../bindings/clock/mediatek,mt7621-pll.yaml | 51 +++ > > 1 file changed, 51 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.yaml > > > > Reviewed-by: Rob Herring Thanks for the review. In that series there were two clock bindings relating the pll and gates, There were finally joined in only one binding and driver. This is done in the v3 of this series sent on friday. Thanks for your time in looking also into this new version, Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fix warning for static const char * array in audio_manager_module.c
On Mon, Nov 16, 2020 at 09:43:23PM +0100, Emmanouil Perselis wrote: > On 11/15/20 9:17 AM, Greg Kroah-Hartman wrote: > > On Sun, Nov 15, 2020 at 03:53:16PM +0100, Emmanouil Perselis wrote: > >> This patch fixes the warning "static const char * array should > >> probably be static const char * const" in > >> drivers/staging/greybus/audio_manager_module.c > > >> I think Greg's patch bot is telling you that you need > >> to carbon-copy the mailing list on your patch submission, > >> not just address it to the maintainers. > > Added addresses to carbon copy. Do you think this is the correct way to submit a patch that doesn't have to be hand-edited in order to apply it? Please make it match other submitted patches, but most importantly, actually test-build your changes to ensure that they are correct. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/8] phy: phy-hi3670-usb3: move driver from staging into phy
Em Mon, 16 Nov 2020 09:31:06 -0600 Rob Herring escreveu: > On Mon, Nov 16, 2020 at 01:59:27PM +0100, Mauro Carvalho Chehab wrote: > > The phy USB3 driver for Hisilicon 970 (hi3670) is ready > > for mainstream. Mode it from staging into the main driver's > > s/Mode/Move/ > > > phy/ directory. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > .../bindings/phy/phy-hi3670-usb3.yaml | 72 ++ > > MAINTAINERS | 9 +- > > drivers/phy/hisilicon/Kconfig | 10 + > > drivers/phy/hisilicon/Makefile| 1 + > > drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++ > > drivers/staging/hikey9xx/Kconfig | 11 - > > drivers/staging/hikey9xx/Makefile | 2 - > > drivers/staging/hikey9xx/phy-hi3670-usb3.c| 671 -- > > drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 72 -- > > I assume this is only a move? Use '-M' option. This is a move, although I explicitly disabled -M on this series, as both the driver code and DT may still require some review, as those patches are for subsystems that I haven't made any relevant contributions so far. Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds
On Mon, Nov 16, 2020 at 10:36:12PM -0600, Samuel Holland wrote:
> On 11/15/20 11:09 AM, Krzysztof Kozlowski wrote:
> > COMMON_CLK is a user-selectable option with its own dependencies. The
> > most important dependency is !HAVE_LEGACY_CLK. User-selectable drivers
> > should not select COMMON_CLK because they will create a dependency cycle
> > and build failures. For example on MIPS a configuration with COMMON_CLK
> > (selected by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (selected by
> > SOC_RT305X) is possible:
>
> Ah, that makes sense.
>
> >
> > WARNING: unmet direct dependencies detected for COMMON_CLK
> > Depends on [n]: !HAVE_LEGACY_CLK [=y]
> > Selected by [y]:
> > - SND_SUN8I_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC
> > [=y] &&
> > (ARCH_SUNXI || COMPILE_TEST [=y]) && OF [=y] && (MACH_SUN8I || ARM64
> > && ARCH_SUNXI || COMPILE_TEST [=y])
> >
> > /usr/bin/mips-linux-gnu-ld: drivers/clk/clk.o: in function
> > `clk_set_rate':
> > (.text+0xaeb4): multiple definition of `clk_set_rate';
> > arch/mips/ralink/clk.o:(.text+0x88): first defined here
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > arch/arm/mach-sunxi/Kconfig | 1 +
> > sound/soc/sunxi/Kconfig | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index eeadb1a4dcfe..4d9f9b6d329d 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -4,6 +4,7 @@ menuconfig ARCH_SUNXI
> > depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
> > select ARCH_HAS_RESET_CONTROLLER
> > select CLKSRC_MMIO
> > + select COMMON_CLK
>
> This is not necessary, since ARCH_SUNXI depends (through ARCH_MULTI_V{5,7}) on
> ARCH_MULTIPLATFORM, which selects COMMON_CLK already.
Thanks. I'll send a v2 with changes and your review.
Best regards,
Krzysztof
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
