dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

[PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe
by Javier Martinez Canillas 07 Jun '22

07 Jun '22

Hello, The patches in this series contain mostly changes suggested by Daniel Vetter Thomas Zimmermann. They aim to fix existing races between the Generic System Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration. For example, it is currently possible for sysfb to register a platform device after a real DRM driver was registered and requested to remove the conflicting framebuffers. Or is possible for a simple{fb,drm} to match with a device previously registered by sysfb, even after a real driver is present. A symptom of this issue, was worked around with the commit fb561bf9abde ("fbdev: Prevent probing generic drivers if a FB is already registered") but that's really a hack and should be reverted instead. This series attempt to fix it more correctly and revert the mentioned hack. That will also allow to make the num_registered_fb variable not visible to drivers anymore, since that's internal to fbdev core. Pach 1 is just a simple cleanup in preparation for later patches. Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow disabling sysfb and attempt to unregister registered devices respectively. Patch 3 changes how is dealt with conflicting framebuffers unregistering, rather than having a variable to determine if a lock should be take, it just drops the lock before unregistering the platform device. Patch 4 changes the fbdev core to not attempt to unregister devices that were registered by sysfb, let the same code doing the registration to also handle the unregistration. Patch 5 fixes the race that exists between sysfb devices registration and fbdev framebuffer devices registration, by disabling the sysfb when a DRM or fbdev driver requests to remove conflicting framebuffers. Patch 6 is the revert patch that was posted by Daniel before but dropped from his set and finally patch 7 is the one that makes num_registered_fb private to fbmem.c, to not allow drivers to use it anymore. The patches were tested on a rpi4 with the vc4, simpledrm and simplefb drivers, using different combinations of built-in and as a module. For example, having simpledrm as a module and loading it after the vc4 driver probed would not register a DRM device, which happens now without the patches from this series. Best regards, Javier Changes in v5: - Move the sysfb_disable() call at conflicting framebuffers again to avoid the need of a DRIVER_FIRMWARE capability flag. - Add Daniel Vetter's Reviewed-by tag again since reverted to the old patch that he already reviewed in v2. - Drop patches that added a DRM_FIRMWARE capability and use them since the case those prevented could be ignored (Daniel Vetter). Changes in v4: - Make sysfb_disable() to also attempt to unregister a device. - Drop call to sysfb_disable() in fbmem since is done in other places now. - Add patch to make registered_fb[] private. - Add patches that introduce the DRM_FIRMWARE capability and usage. Changes in v3: - Add Thomas Zimmermann's Reviewed-by tag to patch #1. - Call sysfb_disable() when a DRM dev and a fbdev are registered rather than when conflicting framebuffers are removed (Thomas Zimmermann). - Call sysfb_disable() when a fbdev framebuffer is registered rather than when conflicting framebuffers are removed (Thomas Zimmermann). - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot. - Rebase on top of latest drm-misc-next branch. Changes in v2: - Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter). - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter). - Explain in the commit message that fbmem has to unregister the device as fallback if a driver registered the device itself (Daniel Vetter). - Also explain that fallback in a comment in the code (Daniel Vetter). - Don't encode in fbmem the assumption that sysfb will always register platform devices (Daniel Vetter). - Add a FIXME comment about drivers registering devices (Daniel Vetter). - Explain in the commit message that fbmem has to unregister the device as fallback if a driver registered the device itself (Daniel Vetter). - Also explain that fallback in a comment in the code (Daniel Vetter). - Don't encode in fbmem the assumption that sysfb will always register platform devices (Daniel Vetter). - Add a FIXME comment about drivers registering devices (Daniel Vetter). - Drop RFC prefix since patches were already reviewed by Daniel Vetter. - Add Daniel Reviewed-by tags to the patches. Daniel Vetter (2): Revert "fbdev: Prevent probing generic drivers if a FB is already registered" fbdev: Make registered_fb[] private to fbmem.c Javier Martinez Canillas (5): firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer firmware: sysfb: Add helpers to unregister a pdev and disable registration fbdev: Restart conflicting fb removal loop when unregistering devices fbdev: Make sysfb to unregister its own registered devices fbdev: Disable sysfb device registration when removing conflicting FBs .../driver-api/firmware/other_interfaces.rst | 6 ++ drivers/firmware/sysfb.c | 91 +++++++++++++++++-- drivers/firmware/sysfb_simplefb.c | 16 ++-- drivers/video/fbdev/core/fbmem.c | 67 +++++++++++--- drivers/video/fbdev/efifb.c | 11 --- drivers/video/fbdev/simplefb.c | 11 --- include/linux/fb.h | 8 +- include/linux/sysfb.h | 29 +++++- 8 files changed, 178 insertions(+), 61 deletions(-) -- 2.35.1

5 26

[PATCH] drm/bridge: lt9611uxc: Cancel only driver's work
by Bjorn Andersson 07 Jun '22

07 Jun '22

During device remove care needs to be taken that no work is pending before it removes the underlying DRM bridge etc, but this can be done on the specific work rather than waiting for the flush of the system-wide workqueue. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c index 3d62e6bf6892..310b3b194491 100644 --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c @@ -982,7 +982,7 @@ static int lt9611uxc_remove(struct i2c_client *client) struct lt9611uxc *lt9611uxc = i2c_get_clientdata(client); disable_irq(client->irq); - flush_scheduled_work(); + cancel_work_sync(&lt9611uxc->work); lt9611uxc_audio_exit(lt9611uxc); drm_bridge_remove(&lt9611uxc->bridge); -- 2.35.1

3 2

[PATCH v4 00/13] drm/msm: drm scheduler conversion and cleanups
by Rob Clark 07 Jun '22

07 Jun '22

From: Rob Clark <robdclark(a)chromium.org> Conversion to gpu_scheduler, and bonus removal of drm_gem_object_put_locked() v2: Fix priority mixup (msm UAPI has lower numeric priority value as higher priority, inverse of drm/scheduler) and add some comments in the UAPI header to clarify. Now that we move active refcnt get into msm_gem_submit, add a patch to mark all bos busy before pinning, to avoid evicting bos used in same batch. Fix bo locking for cmdstream dumping ($debugfs/n/{rd,hangrd}) v3: Add a patch to drop submit bo_list and instead use -EALREADY to detect errors with same obj appearing multiple times in the submit ioctl bos table. Otherwise, with struct_mutex locking dropped, we'd need to move insertion into and removal from bo_list under the obj lock. v4: One last small tweak, drop unused wait_queue_head_t in msm_fence_context Rob Clark (13): drm/msm: Docs and misc cleanup drm/msm: Small submitqueue creation cleanup drm/msm: drop drm_gem_object_put_locked() drm: Drop drm_gem_object_put_locked() drm/msm/submit: Simplify out-fence-fd handling drm/msm: Consolidate submit bo state drm/msm: Track "seqno" fences by idr drm/msm: Return ERR_PTR() from submit_create() drm/msm: Conversion to drm scheduler drm/msm: Drop submit bo_list drm/msm: Drop struct_mutex in submit path drm/msm: Utilize gpu scheduler priorities drm/msm/gem: Mark active before pinning drivers/gpu/drm/drm_gem.c | 22 -- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +- drivers/gpu/drm/msm/msm_drv.c | 30 +- drivers/gpu/drm/msm/msm_fence.c | 42 --- drivers/gpu/drm/msm/msm_fence.h | 3 - drivers/gpu/drm/msm/msm_gem.c | 94 +----- drivers/gpu/drm/msm/msm_gem.h | 47 +-- drivers/gpu/drm/msm/msm_gem_submit.c | 344 ++++++++++++-------- drivers/gpu/drm/msm/msm_gpu.c | 46 +-- drivers/gpu/drm/msm/msm_gpu.h | 78 ++++- drivers/gpu/drm/msm/msm_rd.c | 6 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 70 +++- drivers/gpu/drm/msm/msm_ringbuffer.h | 12 + drivers/gpu/drm/msm/msm_submitqueue.c | 53 ++- include/drm/drm_gem.h | 2 - include/uapi/drm/msm_drm.h | 14 +- 24 files changed, 516 insertions(+), 391 deletions(-) -- 2.31.1

4 34

[PATCH v2 0/2] drm/meson: Fix refcount leak
by Miaoqian Lin 07 Jun '22

07 Jun '22

The following patchset fix two refcount leak bugs. The cause of the bugs are missing of_node_put() after of_graph_get_remote_node(). changes in v2: - patch#2:Fixed patch in meson_encoder_hdmi_init, call of_node_put() after of_find_device_by_node() and error paths before that. noted by Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> (patch#1: no changes since v1) v1 link: patch#1: https://lore.kernel.org/r/20220531144818.26943-1-linmq006@gmail.com/ patch#2: https://lore.kernel.org/r/20220531144818.26943-2-linmq006@gmail.com/ Miaoqian Lin (2): drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_init drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init drivers/gpu/drm/meson/meson_encoder_cvbs.c | 1 + drivers/gpu/drm/meson/meson_encoder_hdmi.c | 15 +++++++++++---- 2 files changed, 12 insertions(+), 4 deletions(-) -- 2.25.1

3 5

[REGRESSION] VGA output with AST 2600 graphics.
by Jocelyn Falempe 07 Jun '22

07 Jun '22

Hi, I've found a regression in the ast driver, for AST2600 hardware. before the upstream commit f9bd00e0ea9d https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… The ast driver handled AST 2600 chip like an AST 2500. After this commit, it uses some default values, more like the older AST chip. There are a lot of places in the driver like this: https://elixir.bootlin.com/linux/v5.18.1/source/drivers/gpu/drm/ast/ast_pos… where it checks for (AST2300 || AST2400 || AST2500) but not for AST2600. This makes the VGA output, to be blurred and flickered with whites lines on AST2600. The issue is present since v5.11 For v5.11~v5.17 I propose a simple workaround (as there are no other reference to AST2600 in the driver): --- a/drivers/gpu/drm/ast/ast_main.c +++ b/drivers/gpu/drm/ast/ast_main.c @@ -146,7 +146,8 @@ static int ast_detect_chip(struct drm_device *dev, bool *need_post) /* Identify chipset */ if (pdev->revision >= 0x50) { - ast->chip = AST2600; + /* Workaround to use the same codepath for AST2600 */ + ast->chip = AST2500; drm_info(dev, "AST 2600 detected\n"); } else if (pdev->revision >= 0x40) { ast->chip = AST2500; starting from v5.18, there is another reference to AST2600 in the code https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ast/ast_main.… So I think someone with good aspeed knowledge should review all locations where there is a test for AST2500, and figure out what should be done for AST2600 Thanks, -- Jocelyn

3 4

Re: [PATCH 2/2] vfio: Replace the iommu notifier with a device list
by Jason Gunthorpe 07 Jun '22

07 Jun '22

On Tue, Jun 07, 2022 at 07:44:37AM +0200, Christoph Hellwig wrote: > On Mon, Jun 06, 2022 at 09:34:36PM -0300, Jason Gunthorpe wrote: > > + if (!list_empty(&iommu->device_list)) { > > + mutex_lock(&iommu->device_list_lock); > > + mutex_unlock(&iommu->lock); > > + > > + list_for_each_entry(device, > > + &iommu->device_list, > > + iommu_entry) > > + device->ops->dma_unmap( > > + device, dma->iova, dma->size); > > + > > + mutex_unlock(&iommu->device_list_lock); > > + mutex_lock(&iommu->lock); > > + } > > I wonder if factoring this into a little helper instead of the > very deep indentation might be a bit better for readability. > > > +static void vfio_iommu_type1_register_device(void *iommu_data, > > + struct vfio_device *vdev) > > { > > struct vfio_iommu *iommu = iommu_data; > > > > + if (!vdev->ops->dma_unmap) > > + return; > > > > + mutex_lock(&iommu->lock); > > + mutex_lock(&iommu->device_list_lock); > > + list_add(&vdev->iommu_entry, &iommu->device_list); > > + mutex_unlock(&iommu->device_list_lock); > > + mutex_unlock(&iommu->lock); > > Why do we need both iommu->lock and the device_list_lock everywhere? Not everwhere, all the readers are using only one of the locks. The list empty calls that were previously unlocked are done under the iommu->lock and only the list iteration was done under the device_list. > Maybe explain the locking scheme somewhere so that people don't have > to guess, because it seems to me that just using iommu->lock would > be enough right now. The expectation is that the dma_umap callback will re-enter the type1 driver via vfio_unpin_pages calls and this will recurse back onto the iommu->lock - so it must be dropped before invoking the callback. I'll add a note Jason

1 0

[PATCH v3 0/4] Add RZ/G2L Display support
by Biju Das 07 Jun '22

07 Jun '22

RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video signal processor (VSPD) and Display unit(DU). The output of LCDC is connected to Display parallel interface and MIPI link video interface. This patch series aims to add basic display support on RZ/G2L SMARC EVK platform. The output from DSI is connected to ADV7535. The DU controller is similar to R-Car as it is connected to VSPD, so most of code is based on R-Car with new CRTC/DRM driver specific to RZ/G2L V2->v3: * Added new bindings for RZ/G2L DU * Removed indirection and created new DRM driver based on R-Car DU v1->v2: * Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du' * Updated commit description for bindings * Removed LCDC references from bindings * Changed clock name from du.0->aclk from bindings * Changed reset name from du.0->du from bindings * Replaced crtc_helper_funcs->rcar_crtc_helper_funcs * Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU * Replaced rzg2l-lcdc-drm->rzg2l-du-drm * Added forward declaration for struct reset_control [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205… RFC->v1: * Changed minItems->maxItems for renesas,vsps. * Added RZ/G2L LCDC driver with special handling for CRTC reusing most of RCar DU code * Fixed the comments for num_rpf from rpf's->RPFs/ and vsp->VSP. RFC: https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612… Biju Das (4): dt-bindings: display: Document Renesas RZ/G2L DU bindings drm: rcar-du: Fix typo drm: rcar-du: Add num_rpf to struct rcar_du_device_info drm: rcar-du: Add RZ/G2L DU Support .../bindings/display/renesas,rzg2l-du.yaml | 159 ++++ drivers/gpu/drm/rcar-du/Kconfig | 16 +- drivers/gpu/drm/rcar-du/Makefile | 9 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 17 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 8 +- drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c | 745 +++++++++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h | 104 +++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.c | 192 +++++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.h | 102 +++ drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c | 113 +++ drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h | 29 + drivers/gpu/drm/rcar-du/rzg2l_du_group.h | 32 + drivers/gpu/drm/rcar-du/rzg2l_du_kms.c | 782 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_kms.h | 43 + drivers/gpu/drm/rcar-du/rzg2l_du_regs.h | 64 ++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c | 420 ++++++++++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h | 93 +++ drivers/gpu/drm/rcar-du/rzg2l_du_writeback.c | 247 ++++++ drivers/gpu/drm/rcar-du/rzg2l_du_writeback.h | 42 + 20 files changed, 3212 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_group.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_writeback.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_writeback.h -- 2.25.1

4 16

[PATCH v2 0/5] drm/ast: Connector cleanups and polling
by Thomas Zimmermann 07 Jun '22

07 Jun '22

Various cleanups to ast's conenctor code. Simplifies the code, adds support for using VGA and ASTDP connectors at the same time, and initializes polling of the connector status. Patch 1 was first posted at [1], so this patchset starts at version 2. The implementation of detect_ctx in patch 3 has been added to DRM helpers as it will be useful for other drivers, such as mgag200 and udl. Thomas Zimmermann (5): drm/ast: Support multiple outputs drm/ast: Fix updating the connector's EDID property drm/ast: Support output polling drm/ast: Fail probing if DCC channel could not be initialized drm/ast: Remove struct ast_{vga,sil164}_connector drivers/gpu/drm/ast/ast_dp.c | 5 +- drivers/gpu/drm/ast/ast_dp501.c | 2 +- drivers/gpu/drm/ast/ast_drv.h | 30 +----- drivers/gpu/drm/ast/ast_i2c.c | 7 +- drivers/gpu/drm/ast/ast_main.c | 21 ++-- drivers/gpu/drm/ast/ast_mode.c | 165 ++++++++++------------------- drivers/gpu/drm/ast/ast_post.c | 2 +- drivers/gpu/drm/drm_probe_helper.c | 35 ++++++ include/drm/drm_probe_helper.h | 3 + 9 files changed, 116 insertions(+), 154 deletions(-) base-commit: 2c8cc5cd20e28afe6b63acb28890e5f57d9bf055 -- 2.36.1

3 20

[RESEND 00/14] Add Mediatek MT6370 PMIC support
by ChiaEn Wu 07 Jun '22

07 Jun '22

From: ChiaEn Wu <chiaen_wu(a)richtek.com> Sorry, for the patch dependency, we resend this patch series and we're sorry for any inconvenience that we may have caused. This patch series add Mediatek MT6370 PMIC support. The MT6370 is a highly-integrated smart power management IC, which includes a single cell Li-Ion/Li-Polymer switching battery charger, a USB Type-C & Power Delivery (PD) controller, dual Flash LED current sources, a RGB LED driver, a backlight WLED driver, a display bias driver and a general LDO for portable devices. Alice Chen (3): dt-bindings: leds: Add Mediatek MT6370 flashlight binding leds: mt6370: Add Mediatek MT6370 Indicator support leds: flashlight: mt6370: Add Mediatek MT6370 flashlight support ChiYuan Huang (7): dt-bindings: usb: Add Mediatek MT6370 TCPC binding dt-bindings: leds: mt6370: Add Mediatek mt6370 indicator dt-bindings: backlight: Add Mediatek MT6370 backlight binding dt-bindings: mfd: Add Mediatek MT6370 binding mfd: mt6370: Add Mediatek MT6370 support usb: typec: tcpci_mt6370: Add Mediatek MT6370 tcpci driver regulator: mt6370: Add mt6370 DisplayBias and VibLDO support ChiaEn Wu (4): dt-bindings: power: supply: Add Mediatek MT6370 Charger binding iio: adc: mt6370: Add Mediatek MT6370 support power: supply: mt6370: Add Mediatek MT6370 charger driver video: backlight: mt6370: Add Mediatek MT6370 support .../backlight/mediatek,mt6370-backlight.yaml | 110 ++ .../leds/mediatek,mt6370-flashlight.yaml | 48 + .../leds/mediatek,mt6370-indicator.yaml | 57 + .../bindings/mfd/mediatek,mt6370.yaml | 282 ++++ .../power/supply/mediatek,mt6370-charger.yaml | 60 + .../bindings/usb/mediatek,mt6370-tcpc.yaml | 35 + drivers/iio/adc/Kconfig | 9 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/mt6370-adc.c | 257 ++++ drivers/leds/Kconfig | 11 + drivers/leds/Makefile | 1 + drivers/leds/flash/Kconfig | 9 + drivers/leds/flash/Makefile | 1 + drivers/leds/flash/leds-mt6370-flash.c | 665 ++++++++++ drivers/leds/leds-mt6370.c | 994 +++++++++++++++ drivers/mfd/Kconfig | 13 + drivers/mfd/Makefile | 1 + drivers/mfd/mt6370.c | 273 ++++ drivers/power/supply/Kconfig | 11 + drivers/power/supply/Makefile | 1 + drivers/power/supply/mt6370-charger.c | 1132 +++++++++++++++++ drivers/regulator/Kconfig | 8 + drivers/regulator/Makefile | 1 + drivers/regulator/mt6370-regulator.c | 389 ++++++ drivers/usb/typec/tcpm/Kconfig | 8 + drivers/usb/typec/tcpm/Makefile | 1 + drivers/usb/typec/tcpm/tcpci_mt6370.c | 212 +++ drivers/video/backlight/Kconfig | 8 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/mt6370-backlight.c | 338 +++++ .../dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 + include/dt-bindings/mfd/mediatek,mt6370.h | 83 ++ 32 files changed, 5038 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml create mode 100644 Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml create mode 100644 Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml create mode 100644 Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml create mode 100644 drivers/iio/adc/mt6370-adc.c create mode 100644 drivers/leds/flash/leds-mt6370-flash.c create mode 100644 drivers/leds/leds-mt6370.c create mode 100644 drivers/mfd/mt6370.c create mode 100644 drivers/power/supply/mt6370-charger.c create mode 100644 drivers/regulator/mt6370-regulator.c create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6370.c create mode 100644 drivers/video/backlight/mt6370-backlight.c create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h create mode 100644 include/dt-bindings/mfd/mediatek,mt6370.h -- 2.25.1

7 31

[PATCH v3 0/7] drm/mgag200: Various cleanups
by Thomas Zimmermann 07 Jun '22

07 Jun '22

Various small fixes and clean-up patches for mgag200. Tested on Matrix G200EH hardware. v3: * fix commit message in 1/7 to say 'drm/mgag200' (Jocelyn) v2: * comment on memory constraints on early G200SE-A * fix connector DDC helper Thomas Zimmermann (7): drm/mgag200: Acquire I/O lock while reading EDID drm/mgag200: Fail on I2C initialization errors drm/mgag200: Implement connector's get_modes with helper drm/mgag200: Switch I2C code to managed cleanup drm/mgag200: Remove struct mga_connector drm/mgag200: Test memory requirements in drm_mode_config_funcs.mode_valid drm/mgag200: Split up connector's mode_valid helper drivers/gpu/drm/drm_probe_helper.c | 36 ++++ drivers/gpu/drm/mgag200/mgag200_drv.h | 13 +- drivers/gpu/drm/mgag200/mgag200_i2c.c | 32 ++- drivers/gpu/drm/mgag200/mgag200_mode.c | 259 +++++++++++-------------- include/drm/drm_probe_helper.h | 2 + 5 files changed, 169 insertions(+), 173 deletions(-) -- 2.36.1

2 8

← Newer
1
...
55
56
57
58
59
60
61
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022