On 6/7/23 08:31, Dario Binacchi wrote:
> Add compatible to panel-simple for Rocktech Displays Limited
> RK043FN48H 4.3" 480x272 LCD-TFT panel.
>
> Signed-off-by: Dario Binacchi
> Acked-by: Conor Dooley
Reviewed-by: Raphael Gallais-Pou
Thanks,
Raphaël
Thomas Zimmermann writes:
Hello Thomas,
> Hi Javierm,
>
> I've read through the patches and they look correct to me.
>
> Reviewed-by: Thomas Zimmermann
>
Thanks a lot for your review!
> But I had one question about the page size. You round up to multiples of
> page_size in several places. Th
Otherwise its failed to pass basic compile test on platform without
REGMAP_MMIO selected by defconfig
make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64-
SYNCinclude/config/auto.conf.cmd
Checking missing-syscalls for N32
CALLscripts/checksyscalls.sh
Checking missing-s
Thomas Zimmermann writes:
> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
Thomas Zimmermann writes:
> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
On 02/06/2023 09:40, Keith Zhao wrote:
> Add bindings for JH7110 display subsystem which
> has a display controller verisilicon dc8200
> and an HDMI interface.
>
> Signed-off-by: Keith Zhao
> ---
> .../display/verisilicon/starfive-hdmi.yaml| 93 +++
> .../display/verisilicon/ver
Thomas Zimmermann writes:
> Struct lv5207lp_platform_data refers to a platform device within
> the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.devi
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Can
On 02/06/2023 09:40, Keith Zhao wrote:
> Add the dc controller and hdmi node for the Starfive JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> .../jh7110-starfive-visionfive-2.dtsi | 87 +++
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 46 ++
> 2 files chang
Thomas Zimmermann writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Can
On 6/6/2023 10:56 PM, Andi Shyti wrote:
Hi Nirmoy,
On Tue, Jun 06, 2023 at 10:27:55PM +0200, Nirmoy Das wrote:
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link
On 6/7/2023 8:20 AM, Andrzej Hajda wrote:
On 06.06.2023 22:27, Nirmoy Das wrote:
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequ
Thomas Zimmermann writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez
Thomas Zimmermann writes:
> Call device_remove_file() with the same device that has been used
> for device_create_file(), which is the hardware device stored in
> struct fb_info.device. Prepares fbdev for making struct fb_info.dev
> optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on plat
On Wed, 07 Jun 2023, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wed, Jun 07, 2023 at 12:39:44AM +0300, Jani Nikula wrote:
>> On Tue, 06 Jun 2023, Laurent Pinchart wrote:
>> > On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
>> >> @@ -777,7 +793,7 @@ int drm_client_modeset_probe(str
Hi,
On Wed, 07 Jun 2023 08:31:33 +0200, Dario Binacchi wrote:
> The series adds support for the display on the stm32f746-disco board,
> along with a generic patch that adds the "bpp" parameter to the stm-drm
> module. The intention is to allow users to size, within certain limits,
> the memory foo
Hi Thomas,
Thanks for your series!
Over the past few days, I have been giving this some thought, that's
why I am replying only now...
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann wrote:
> Add the new config option FB_DEVICE. If enabled, fbdev provides
> traditional userspace interfaces in d
Am Mittwoch, 7. Juni 2023, 00:37:53 CEST schrieb Conor Dooley:
> On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote:
> > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu:
> > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote:
> > > >> Add bindings for JH7110 displ
Hi Guys,
so I checked, the kernel I am running has this commit
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
/commit/?id=08da182175db4c7f80850354849d95f2670e8cd9) applied already!
https://github.com/ju6ge/linux/commit/917680e6056aa288cac288d3afd2745d372beb61u
And the bug
This reverts commit 1040e424353f5f4d39f6f3aa8723eb3bd6ea6446.
It used an incorrect way to use drm_* functions. Only drm_device ptrs
should be passed, but the mentioned commit passed mipi_dsi_host ptr.
It worked by accident due to macro magic.
Reported-by: Jani Nikula
Reviewed-by: Jani Nikula
Si
On Tue, 06 Jun 2023 20:34:19 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > - DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(dev, "\n");
>
> This message is pretty useless, it could be dropped on top of this
> series.
Okay.
> > - DRM_DEBUG_KMS("\n");
>
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +--
On Tue, 06 Jun 2023 23:19:28 +0530, Laurent Pinchart wrote:
> The idea would be to include the drm_print_deprecated.h header in
> drivers that still use the deprecated macros.
Yeah, what I meant was in a "first pass" kind of sense.
> > Not every file can be seen at a case-by-case basis or by cocc
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/d
On Tue, 06 Jun 2023 20:27:06 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > if (!ctx_entry) {
> > - DRM_DEBUG("out of memory\n");
> > + drm_dbg_core(dev, "out of memory\n");
>
> This message could also be dropped.
Okay.
> >
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/drm/drm_context.c| 4 ++
drm_print.h says DRM_INFO is deprecated in favor of drm_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/gpu/drm/drm_pci.c| 2 +-
4 files cha
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c |
On 6/1/2023 10:00 AM, Luca Weiss wrote:
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cf
On Tue, 06 Jun 2023 20:35:45 +0530, Laurent Pinchart wrote:
> This is a nice series, thank you for working on that.
>
> Now that the deprecated macros are used in drivers only, would it make
> sense to move them to a drm_print_deprecated.h header, to make sure no
> new driver uses them ?
Sure, bu
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c | 21 ++---
drivers/gpu/drm/drm
On Tue, 06 Jun 2023 19:53:22 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> Any plan to remove it from drivers as well ? If not you should mention
> in the commit message (probably in the subject line itself) that you're
> only addressing the DRM core.
>
>
Hi Conor,
Hey Keith,
On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote:
Add bindings for JH7110 display subsystem which
has a display controller verisilicon dc8200
and an HDMI interface.
Signed-off-by: Keith Zhao
---
.../display/verisilicon/starfive-hdmi.yaml| 93
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
include/drm/drm_print.h
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
On Tue, 06 Jun 2023 20:14:52 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > if (!crtcs || !modes || !enabled || !offsets) {
> > - DRM_ERROR("Memory allocation failed\n");
> > + drm_err(client->dev, "Memory allocation failed\n"
This patchset aims to remove usages of deprecated DRM_* macros from the
files residing in drivers/gpu/drm root.
In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DR
On 2023/6/7 14:41, Maxime Ripard wrote:
> On Tue, Jun 06, 2023 at 11:37:53PM +0100, Conor Dooley wrote:
>> On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote:
>> > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu:
>> > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zha
There are a couple of superfluous print statements using the drm_*
macros, which do stuff like printing newlines, print OOM messages
(OOM while allocating memory is already supposed to be noisy), and
printing strings like "Initialised" with no extra info whatsoever.
Thus, remove a couple of these
On Tue, 06 Jun 2023 20:16:25 +0530, Laurent Pinchart wrote:
> I would write
>
> drm: Remove usage of deprecated DRM_INFO in DRM core
>
> The "drm: " prefix doesn't imply you're touching the core only, you
> could do a tree-wide change that also touches all drivers.
Okay, will send a v10 with the
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Us
On Tue, 06 Jun 2023 18:25:37 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> Any chance we could prevent this from happening by turning the macros
> into inline functions ?
The next patch in the series almost does that, with a function introduced
as Jani men
drm_print.h says DRM_NOTE is deprecated in favor of drm_notice().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_displayid.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
drm_print.h says DRM_INFO is deprecated in favor of drm_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/gpu/drm/drm_pci.c| 2 +-
4 files cha
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Us
drm_print.h says DRM_NOTE is deprecated in favor of drm_notice().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_displayid.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/d
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
drivers/gpu/drm/drm_dma.c
Hi,
On 2023/6/6 23:28, Doug Anderson wrote:
Hi,
On Tue, Jun 6, 2023 at 12:56 AM Su Hui wrote:
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5.
Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip")
Signed-off-by: Su Hui
---
drivers/gpu/drm/bridge/ti-sn65dsi
On 6/1/2023 10:00 AM, Luca Weiss wrote:
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/d
This patchset aims to remove usages of deprecated DRM_* macros from the
DRM core (i.e. drivers/gpu/drm/*.c).
In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DRM_D
On Tue, 06 Jun 2023 19:35:12 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> On Tue, Jun 06, 2023 at 04:15:16PM +0530, Siddh Raman Pant wrote:
> > Comments say macros DRM_DEBUG_* are deprecated in favor of
> > drm_dbg_*(NULL, ...), but they have broken suppor
This reverts commit 1040e424353f5f4d39f6f3aa8723eb3bd6ea6446.
It used an incorrect way to use drm_* functions. Only drm_device ptrs
should be passed, but the mentioned commit passed mipi_dsi_host ptr.
It worked by accident due to macro magic.
Reported-by: Jani Nikula
Reviewed-by: Jani Nikula
Re
Thomas Zimmermann writes:
> Pass the hardware device to the DMA helpers dma_alloc_wc(), dma_mmap_wc()
> and dma_free_coherent(). The fbdev device that is currently being used is
> a software device and does not provide DMA memory.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier M
Hi Thomas,
Thanks for your patch!
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann wrote:
> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
> device optional. If the new option has not been selected, fbdev
> does not create a files in devfs or sysfs.
>
> Most modern Linux systems
Hi all,
sorry for not being able to chime in earlier.
> In Biju's particular use case, the i2c device responds to two addresses,
> which is the standard i2c ancillary use case. However, what's special
Not quite. ancillary is used when a *driver* needs to take care of two
addresses. We already h
Hi Keith,
Am Freitag, dem 02.06.2023 um 15:40 +0800 schrieb Keith Zhao:
> Add a basic platform driver of the DRM driver for JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> MAINTAINERS | 2 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile
Hi Dave and Daniel,
here's the weekly PR for drm-misc-next.
Best regards
Thomas
drm-misc-next-2023-06-07:
drm-misc-next for v6.5:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
* bridge
* imx: Fix module linking
* tc358762: Support reset GPIO
* meson
* Add
Thomas Zimmermann writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_info() and fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Do not assing the Linux device to struct fb_info.dev. The call to
> register_framebuffer() initializes the field to the fbdev device.
> Drivers should not override its value.
>
> Fixes a bug where the driver incorrectly decreases the hardware
> device's reference count
Thomas Zimmermann writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_dbg() and fb_err() instead. Prepares fbdev for making struct
> fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javie
Thomas Zimmermann writes:
> Replace the use of the fbdev software device, stored in struct
> fb_info.dev, with the hardware device from struct fb_info.device
> in load_waveform(). The device is only used for printing errors
> with dev_err().
>
> This change aligns load_waveform() with the rest of
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regard
Thomas Zimmermann writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Review
> I think the return value isn't checked at all, so you could
> simply return below "-ENODEV" for all cases (instead of "return ret").
> Then you don't need the e_nodev label and can simplify the flow.
I noticed that the software evolution was continued with an other change
variant.
fbdev: imstt
> The exception handling was incomplete.
>
> The label “error” was used to jump to another pointer check despite of
> the detail in the implementation of the function “imsttfb_probe”
> that it was determined already that the corresponding variable
> contained a null pointer.
>
> * Thus use more app
Thomas Zimmermann writes:
> Do not assign the hardware device to struct fb_info.dev. The
> field references the fbdev software device, which is unrelated.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platform
[Public]
It's
https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next?ref_type=heads.
Latest patches including yours's will be pushed to this branch after a while.
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of Sui
> Jingfeng
> Sent: Wednesday, June 7
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the cleanup calls for both data
> structures. The init calls are already in the correct order.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Benjamin Herrenschmidt
> ---
Reviewed
Thomas Zimmermann writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> Benjamin Herrenschmidt
> ---
Rev
Thomas Zimmermann writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regard
Thomas Zimmermann writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Antonino Daplas
> ---
Review
Thomas Zimmermann writes:
> Fix case were dev_err() is being called with struct fb_info.dev.
> Use fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On Tue, 6 Jun 2023 17:53:52 -0300
Arthur Grillo wrote:
> Support a 1D gamma LUT with interpolation for each color channel on the
> VKMS driver. Add a check for the LUT length by creating
> vkms_atomic_check().
>
> Tested with:
> igt@kms_color@gamma
> igt@kms_color@legacy-gamma
> igt@kms_color@i
Acked-by: Christian König
While you are at it: It's beneficial for drivers to implement the flush
callback on the file descriptor.
This way you can still send a SIGKILL when a terminating application
waits for the entity to be flushed out to the hardware and all the
pending jobs are cancele
Hello Krzysztof,
uto, 6. lip 2023. u 16:43 Krzysztof Kozlowski
napisao je:
>
> On 06/06/2023 16:07, Paulo Pavacic wrote:
> > Added fannal to vendor-prefixes and dt bindings for Fannal C3004.
> > Fannal C3004 is a 480x800 MIPI DSI Panel which requires
> > DCS initialization sequences with certain
Hi Sui,
Le mercredi 07 juin 2023 à 13:30 +0800, Sui Jingfeng a écrit :
> The single map_noncoherent member of struct drm_gem_dma_object may
> not
> sufficient for describing the backing memory of the GEM buffer
> object.
>
> Especially on dma-coherent systems, the backing memory is both cached
>
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland
wrote:
> We an use bitfields to track the support ones for HDMI
Typo: "We can"
On 07/06/2023 08:07, Laurent Pinchart wrote:
Hello Jiasheng,
Thank you for the patch.
On Wed, Jun 07, 2023 at 10:05:29AM +0800, Jiasheng Jiang wrote:
Add check for dma_set_mask() and return the error if it fails.
Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
S
On Tue, May 16, 2023 at 09:28:27AM +0100, Diogo Ivo wrote:
> Hello,
>
> This patch series enables the use of the GM20B GPU in the
> Google Pixel C.
>
> Patch 1 adds the needed regulator DT node for the GPU.
>
> Patch 2 enables the GPU in the DT.
Hello,
Gentle ping on these patches.
Thank you,
On Tuesday, June 6th, 2023 at 22:26, Harry Wentland
wrote:
> -int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
> +int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
> + u32 supported_colorspaces)
>
From: Andrzej Kacprowski
Wait for AON bit in HOST_SS_CPR_RST_CLR to return 0 before
starting VPUIP power up sequence, otherwise the VPU device
may sporadically fail to boot.
An error in power up sequence is propagated to the runtime
power management - the device will be in an error state
until t
Hi Sui,
Le mercredi 07 juin 2023 à 15:22 +0800, Sui Jingfeng a écrit :
> Otherwise its failed to pass basic compile test on platform without
> REGMAP_MMIO selected by defconfig
>
> make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64-
>
> SYNC include/config/auto.conf.cmd
> Che
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland
wrote:
> + if (supported_colorspaces != 0 && (colorspaces & BIT(i)) == 0)
This patch actually also introduces a change in behavior: passing no
colorspace will make the function advertise all colorspaces. I have a
hard time understa
Hi,
On 2023/6/7 17:09, Chen, Guchun wrote:
[Public]
It's
https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next?ref_type=heads.
Latest patches including yours's will be pushed to this branch after a while.
Now I know, thanks for your kindness reply.
Regards,
Guchun
On 07/06/2023 11:29, Paulo Pavacic wrote:
> Hello Krzysztof,
>
> uto, 6. lip 2023. u 16:43 Krzysztof Kozlowski
> napisao je:
>>
>> On 06/06/2023 16:07, Paulo Pavacic wrote:
>>> Added fannal to vendor-prefixes and dt bindings for Fannal C3004.
>>> Fannal C3004 is a 480x800 MIPI DSI Panel which req
Add a panel entry for the AUO B116XAB01.4 edp panel, found in the Acer
Chromebook Spin 311 (CP311-3H) laptop.
Signed-off-by: Laura Nao
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
Ok, thanks
On 2023/6/7 17:46, Paul Cercueil wrote:
Hi Sui,
Le mercredi 07 juin 2023 à 15:22 +0800, Sui Jingfeng a écrit :
Otherwise its failed to pass basic compile test on platform without
REGMAP_MMIO selected by defconfig
make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64-
Hi,
On 2023/6/7 17:36, Paul Cercueil wrote:
Hi Sui,
Le mercredi 07 juin 2023 à 13:30 +0800, Sui Jingfeng a écrit :
The single map_noncoherent member of struct drm_gem_dma_object may
not
sufficient for describing the backing memory of the GEM buffer
object.
Especially on dma-coherent systems,
From: Sui Jingfeng
Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend the driver for the PCI device support.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc:
From: Sui Jingfeng
There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same core. Thus, this patch
set is trying to add PCI device driver support to etnaviv.
v6:
* Fix build issue on system without CONFIG_PCI enabled
v7:
From: Sui Jingfeng
Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI GPUs. So don't rage
quit if there is no CLK subsystem support.
For the GPU in LS7A1000 and LS2K1000, the working frequency of the GPU is
tuned by co
From: Sui Jingfeng
struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
The idea is to avoid leaking its members outside. The err
From: Sui Jingfeng
This patch adds PCI driver support on top of what we already have. Take
the GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device
driver. There is only one GPU core for the GC1000 in the LS7A1000 and
LS2K1000. Therefore, component frameworks can be avoided.
Cc: L
From: Sui Jingfeng
Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.
Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.
C
From: Sui Jingfeng
After introducing the etnaviv_of_first_available_node() helper, the
creation of the virtual master platform device can also be simplified.
So, switch to etnaviv_create_virtual_master() function.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc:
From: Sui Jingfeng
Adds another code path to allow bypass component frameworks, A platform
with a single GPU core could probably try the non-component code path.
This patch is for code sharing, no functional change.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc
From: Sui Jingfeng
Loongson CPUs maintain cache coherency by hardware, which means that the
data in the CPU cache is identical to the data in main system memory. As
for the peripheral device, most of Loongson chips chose to define the
peripherals as DMA coherent by default, device drivers do not
Hi Wolfram,
> Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
>
> Hi all,
>
> sorry for not being able to chime in earlier.
>
> > In Biju's particular use case, the i2c device responds to two
> > addresses, which is the standard i2c ancillary use case. However,
> > wh
1 - 100 of 233 matches
Mail list logo
