- 19 Jul, 2022 12 commits
-
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-2-tzimmermann@suse.de
-
Marek Vasut authored
The ST7701 initialization sequence is well parametrized, split the GIP programming sequence, which is fully custom completely undocumented TFT matrix specific magic register programming sequence into separate callback so other TFT matrix definitions can add their own GIP sequence. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Guido Günther <agx@sigxcpu.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220710194437.289042-9-marex@denx.de
-
Marek Vasut authored
Instead of hard-coding TFT matrix voltage and timing settings, which can even lead to permanent TFT matrix damage, parametrize them in TFT matrix descriptor. Signed-off-by:
-
Marek Vasut authored
The horizontal pixel count is a property of the TFT matrix. Currently the driver hard-codes content of this register to specific value which is only compatible with one TFT matrix, likely the TS8550B one. Calculate the horizontal pixel count from the mode instead. Signed-off-by:
-
Marek Vasut authored
Define DSI_CMD2_BK0_PORCTRL_VBP_MASK and DSI_CMD2_BK0_PORCTRL_VFP_MASK and move the vertical back and front porch calculation from macros into the st7701_init_sequence() function, so it is clear what this does. No functional change. Signed-off-by:
-
Marek Vasut authored
The vertical line count is a property of the TFT matrix. Currently the driver hard-codes content of this register to specific value which is only compatible with one TFT matrix, likely the TS8550B one. Calculate the vertical line count from the mode instead. Signed-off-by:
-
Marek Vasut authored
The gamma correction values are specific to the TFT which is attached to the ST7701 TFT matrix driver, move the gamma correction values from what incorrectly looks like common init sequence into TFT matrix specific settings. While doing so, add macros which defined fields within the gamma register file and a macro which mimics FIELD_PREP except works with constant expressions. Signed-off-by:
-
Marek Vasut authored
The ST7701 and ST7701S all have two voltage supplies, one for internal logic and one for the TFT matrix driver. The supplies are not property of the TFT matrix driver, so move them to common ST7701 code. Signed-off-by:
-
Marek Vasut authored
The ST7701(S) is capable of DSI burst mode, which is more energy efficient than the non-burst modes. Make use of it. The ST7701(S) is capable of DSI non-continuous clock, since it sources the TFT matrix driver clock from internal clock source. The DSI non-continuous clock further reduce power utilization. The ST7701(S) uses DSI LPM for command transmissions, make sure this is configured correctly in the DSI mode flags. Signed-off-by:
-
Marek Vasut authored
The ST7701 and ST7701S are TFT matrix drivers with integrated multi protocol decoder capable of DSI/DPI/SPI input and 480x360...864 line TFT matrix output. Currently the only supported input is DSI. The protocol decoder is separate from the TFT matrix driver and is always capable of handling all of DSI non-burst mode with sync pulses or sync events as well as DSI burst mode. Move the DSI mode configuration from TFT matrix driver properties to common ST7701 code, because this is common to all TFT matrices. Signed-off-by:
-
shaomin Deng authored
there is a repeated word "in", so remove it. Signed-off-by:
shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
shaomin Deng authored
remove the rebundant word "the" from comments. Signed-off-by:
-
- 18 Jul, 2022 8 commits
-
-
Christian König authored
Make it clear that DMA_RESV_USAGE_BOOKKEEP can be used for explicit synced user space submissions as well and document the rules around adding the same fence with different usages. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220712131201.131475-1-christian.koenig@amd.com
-
shaomin Deng authored
there is a repeated word "or" in comments, so remove it. Signed-off-by:
-
allen chen authored
Speed up video clock calculation and remove redundant video debug message. Signed-off-by:
Pin-Yen Lin <treapking@chromium.org> Signed-off-by:
Allen Chen <allen.chen@ite.com.tw> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
allen chen authored
Use i2c bus to read/write when it6505 power off will occur i2c error. Add this check will prevent i2c error when it6505 power off. Signed-off-by:
-
allen chen authored
Change power sequence to meet it6505 data sheet requirement when boot on. Signed-off-by:
-
Pin-Yen Lin authored
Send DPCD DP_SET_POWER_D0 command to the monitor in .atomic_enable callback. Without this command, some monitors won't show up again after changing the resolution. Fixes: 46ca7da7 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream") Signed-off-by:
-
Javier Martinez Canillas authored
Data writes for the ssd130x 4-wire SPI protocol need special handling, due the Data/Command control (D/C) pin having to be toggled prior to the write. The regmap API only allowed drivers to provide .reg_{read,write} callbacks to do per register read/write, but didn't provide a way for drivers to do the same for bulk read/writes. For this reason, a custom regmap bus was used by the driver just to define a bulk write callback that implements the D/C pin toggling. But the regmap API has been extended to support defining bulk read/write handlers, so the custom regmap bus is not needed anymore and could just be dropped. Signed-off-by:Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220618174338.2253021-1-javierm@redhat.com
-
Laurent Pinchart authored
Add FourCCs for two missing permutations of the packed YUV 4:4:4 color components, namely AVUY and XVUY. These formats are needed by the NXP i.MX8 ISI. While the ISI is supported by a V4L2 device (corresponding formats have been submitted to V4L2), it is handled in userspace by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220616185210.22018-1-laurent.pinchart@ideasonboard.com
-
- 16 Jul, 2022 13 commits
-
-
Sam Ravnborg authored
- Fix comments using wrong style - Drop repeated word This fixes all checkpatch complains and makes the file a little bit easier to read - as the eye is not distracted by the style violations. Suggested-by:
-
Sam Ravnborg authored
The macros for texture 1 setting all used continuation on a new line, resulting in a highly ureadable definition. Merge the lines so they are each on a single line. As a nice side-effect this fixes a number of checkpatch warnings: "WARNING: please, no spaces at the start of a line". Suggested-by:
-
Sam Ravnborg authored
The license for the via_3d_reg header is MIT - so use the shorter SPDX tag to identify the license. Suggested-by:
-
Sam Ravnborg authored
Updated the 3d_reg header file to match what is used by the openchrome driver. This verifies that the two drivers can use the same header file. The file is a verbatim copy from the openchrome repo - a few style issues will be fixed in following commits. Signed-off-by:
-
Sam Ravnborg authored
With this change the driver is now a signle file driver. The only remaning heder file describes the HW and can be shared with the new openchrome driver. Signed-off-by:
-
Sam Ravnborg authored
Embed the header file in via_drv.h and the code in via_dri1. All functions are made static as there are no more external users. Signed-off-by:
-
Sam Ravnborg authored
Embed some of the header file in via_drv.h and the rest in via_dri1.c While embedding deleted extra empty lines and functions that has no external users are made static. Signed-off-by:
-
Sam Ravnborg authored
All functions are made static as there are no more external users. The file had new copyrights that are kept. Signed-off-by:
-
Sam Ravnborg authored
All functions are made static as there are no more external users. The file had a new copyright that is kept. Signed-off-by:
-
Sam Ravnborg authored
All functions was made static as there are no external users. Signed-off-by:
-
Sam Ravnborg authored
A few functions has no external use and are made static. Signed-off-by:
-
Sam Ravnborg authored
Moved the copyright notices so all copyrights are kept. A few variables was made static as there are no more users outside this file. Signed-off-by:
-
Sam Ravnborg authored
The via driver implements the DRI1 interface, and we have a new implementation of the via driver coming that supports atomic modesetting. It is not acceptable just to replace the existing driver so this is first step to make it a single-file implementation allowing it to stay without interfering with the new driver. Signed-off-by:
-
- 15 Jul, 2022 5 commits
-
-
Tom Rix authored
clang static analysis reports drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c:68:17: warning: The right operand of '*' is a garbage value [core.UndefinedBinaryOperatorResult] switch (!!data * *ver) { ^ ~~~~ A switch statement with only a default should be reduced to an if. If nvbios_pmuEp() returns 0, via the data variable, the output info parameter is not used. So set info only when data is not 0. The struct nvbios_pmuE only has the type and data elements. Since both of these are explicitly set, memset is not needed. So remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Christian König authored
This re-applys commit 708d19d9. The original problem this was reverted for was found and the correct fix will be merged to drm-misc-next-fixes. Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220714132315.587217-2-christian.koenig@amd.com
-
Christian König authored
This re-applys commit 5e3f1e77. The original problem this was reverted for was found and the correct fix will be merged to drm-misc-next-fixes. Signed-off-by:
-
Javier Martinez Canillas authored
There are some struct drm_driver fields that are required by drivers since drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION. But it can be possible that a driver has a bug and did not set some of the fields, which leads to drm_copy_field() attempting to copy a NULL pointer: [ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : __pi_strlen+0x14/0x150 [ +0.003895] lr : drm_copy_field+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] __pi_strlen+0x14/0x150 [ +0.003537] drm_version+0x84/0xac [ +0.003448] drm_ioctl_kernel+0xa8/0x16c [ +0.003975] drm_ioctl+0x270/0x580 [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc [ +0.003978] invoke_syscall+0x78/0x100 [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4 [ +0.004767] do_el0_svc+0x38/0x4c [ +0.003357] el0_svc+0x34/0x100 [ +0.003185] el0t_64_sync_handler+0x11c/0x150 [ +0.004418] el0t_64_sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]--- Reported-by:
Peter Robinson <pbrobinson@gmail.com> Signed-off-by:
-
Javier Martinez Canillas authored
The strlen() function returns a size_t which is an unsigned int on 32-bit arches and an unsigned long on 64-bit arches. But in the drm_copy_field() function, the strlen() return value is assigned to an 'int len' variable. Later, the len variable is passed as copy_from_user() third argument that is an unsigned long parameter as well. In theory, this can lead to an integer overflow via type conversion. Since the assignment happens to a signed int lvalue instead of a size_t lvalue. In practice though, that's unlikely since the values copied are set by DRM drivers and not controlled by userspace. But using a size_t for len is the correct thing to do anyways. Signed-off-by:
-
- 13 Jul, 2022 2 commits
-
-
Maxime Ripard authored
devm_pm_runtime_enable() simplifies the driver a bit since it will call pm_runtime_disable() automatically through a device-managed action. Acked-by:
-
Maxime Ripard authored
At bind time, vc4_v3d_bind() will read a register to retrieve the v3d version and make sure it's a version we're compatible with. However, the v3d has an optional clock that is enabled only after the register read-out and a power domain that wasn't enabled at all in the bind implementation. This was working fine at boot because both were enabled, but resulted in the version check failing if we were unbinding and rebinding the driver because the unbinding would have turned them off. The fix isn't as easy as calling pm_runtime_resume_and_get() prior to the register access to power up the power domain though. Indeed, the runtime_resume implementation will enable the clock mentioned above, call vc4_v3d_init_hw() and then vc4_irq_enable(). Prior to the previous patch, vc4_irq_enable() needed to occur after our call to platform_get_irq() and vc4_irq_install(), since vc4_irq_enable() used to call enable_irq() and vc4_irq_install() will call request_irq(). vc4_irq_install() will also do some register access, so needs the power domain to be on. So we ended up in a situation where vc4_v3d_runtime_resume() needed vc4_irq_install() to have been called before, and vc4_irq_install() needed vc4_v3d_runtime_resume(). The previous patch removed the enable_irq() call in vc4_irq_enable() and thus removed the dependency of vc4_v3d_runtime_resume() on vc4_irq_install(). Thus, we can now rework our bind implementation to call pm_runtime_resume_and_get() before our register access to make sure the power domain is on. vc4_v3d_runtime_resume() also takes care of turning the clock on and calling vc4_v3d_init_hw() so we can remove them from bind. Acked-by:
-
