On 20/04/2022 04:45, Abhinav Kumar wrote:
Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1
Hi,
On 19/04/2022 17:20, Rob Herring wrote:
On Tue, Apr 19, 2022 at 12:33:01PM +0530, Aradhya Bhatia wrote:
The DSS IP on the ti-am65x soc supports an additional register space,
named "common1". Further. the IP services a maximum number of 2
interrupts.
Add the missing register space "common1"
On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
On 20/04/2022 04:45, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v2:
- remove multiple empty lines at the end of the
On 20/04/2022 04:46, Abhinav Kumar wrote:
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
changes in v2:
- split the w
Learning about the DRM subsystem could be quite overwhelming for newcomers
but there are lots of useful talks, slides and articles available that can
help to understand the needed concepts and ease the learning curve.
There are also simple DRM drivers that can be used as example about how a
DRM dr
On 20/04/2022 04:46, Abhinav Kumar wrote:
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it
On 19-04-22, 09:08, Liu Ying wrote:
> Hi,
>
> This is the v8 series to add i.MX8qxp LVDS PHY mode support for the Mixel
> PHY in the Freescale i.MX8qxp SoC.
>
> The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
> MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by
On Wed, Apr 13, 2022 at 7:11 AM Xiaomeng Tong wrote:
>
> Instead of exiting the loop as expected when an entry is found, the
> list_for_each_entry() continues until the traversal is complete. To
> avoid potential executing 'ret = gma_backlight_init(dev);' repeatly,
> goto outside the loop when fou
Hello Thomas,
Thanks a lot for re-spinning your series.
On 4/19/22 12:04, Thomas Zimmermann wrote:
> A workaround makes fbdev hot-unplugging work for framebuffers without
> device. The only user for this feature was offb. As each OF framebuffer
> now has an associated platform device, the workaro
Hi Zack,
Am 20.04.22 um 05:56 schrieb Zack Rusin:
On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
Rework the internals of the dma_resv object to allow adding more than
one
write fence and remember for each fence what purpose it had.
This allows removing the workaround from amdgpu whi
Since version 5.13, the standard syscon bindings have been added
to all clps711x DT nodes, so we can now use the more general
syscon_regmap_lookup_by_phandle function to get the syscon pointer.
Signed-off-by: Alexander Shiyan
---
drivers/video/fbdev/clps711x-fb.c | 3 +--
1 file changed, 1 inser
On 4/20/22 01:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The palmld header is almost unused in drivers, the only
> remaining thing now is the PATA device address, which should
> really be passed as a resource.
>
> Cc: Jens Axboe
> Cc: linux-...@vger.kernel.org
> Acked-by: Robert Jarzmik
On 20/04/2022 04:46, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v2:
- add the writeback parts to dpu_encoder_helper_phys_cleanup
- rebase on tip of msm-next and fix related dependencies
- get
On 20/04/2022 04:46, Abhinav Kumar wrote:
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
changes in v2:
- rebase on msm-next and fix related dependencies namely
the irq cleanup
- move cdp_cfg, aspace out o
On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
> If the device is already in a runtime PM enabled state
> pm_runtime_get_sync() will return 1, so a test for negative
> value should be used to check for errors.
>
> Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_syn
On 20/04/2022 04:46, Abhinav Kumar wrote:
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with
On 20/04/2022 04:46, Abhinav Kumar wrote:
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
-
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Cai-Huoqing/drm-nvdla-Add-driver-support-for-NVDLA/20220419-220255
base: git://anongit.freedesktop.org/drm/drm drm-next
config: h8300-randconfig-r014-202204
On 20/04/2022 04:46, Abhinav Kumar wrote:
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atom
Hi,
22. 4. 12. 13:19에 Dan Carpenter 이(가) 쓴 글:
> On Tue, Apr 12, 2022 at 10:01:20AM +0900, Inki Dae wrote:
>> Hi Dan Carpenter.
>>
>> Same patch[1] was posted so I will pick it up.
>>
>> [1]
>> https://protect2.fireeye.com/v1/url?k=94e9d569-f562c05f-94e85e26-000babff9b5d-4d4f5b20cfffa24c&q=1&e=72
On 2022/4/20 15:51, Maxime Ripard wrote:
> On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
>> If the device is already in a runtime PM enabled state
>> pm_runtime_get_sync() will return 1, so a test for negative
>> value should be used to check for errors.
>>
>> Also, we need to cal
On Fri, 15 Apr 2022 18:25:12 +0200, Stefan Wahren wrote:
> From: Dave Stevenson
>
> If a call to rpi_touchscreen_i2c_write from rpi_touchscreen_probe
> fails before mipi_dsi_device_register_full is called, then
> in trying to log the error message if uses ts->dsi->dev when
> it is still NULL.
>
On Fri, 15 Apr 2022 18:25:13 +0200, Stefan Wahren wrote:
> From: Dave Stevenson
>
> The panel has a prepare call which is before video starts, and an
> enable call which is after.
> The Toshiba bridge should be configured before video, so move
> the relevant power and initialisation calls to prep
On Mon, 11 Apr 2022 10:43:25 +0800, Zheng Bin wrote:
> If CONFIG_DRM_VC4=y, CONFIG_RASPBERRYPI_FIRMWARE=m, CONFIG_COMPILE_TEST=n,
> bulding fails:
>
> drivers/gpu/drm/vc4/vc4_drv.o: In function `vc4_drm_bind':
> vc4_drv.c:(.text+0x320): undefined reference to `rpi_firmware_get'
> vc4_drv.c:(.text+
Hello,
The patches in this series are mostly changes suggested by Daniel Vetter
to fix some race conditions that exists between the fbdev core (fbmem)
and sysfb with regard to device registration and removal.
For example, it is currently possible for sysfb to register a platform
device after a re
This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v2)
Changes in v2:
- Rebase on top of latest drm-misc-ne
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, calls remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a races when
drivers register framebuffer devices. But if a conflicting framebuffer
device i
These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v2)
Changes in v2:
- Add k
The platform devices registered in sysfb match with a firmware-based fbdev
or DRM driver, that are used to have early graphics using framebuffers set
up by the system firmware.
Real DRM drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic
if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()
to allocate memory, when request size is exceeds kmalloc limit, it will
cause allocate memory fail.
e.g: when ttm want to create a BO with 1TB size, it maybe fail.
Signed-off-by: Yang Wang
---
drivers/gpu/drm/ttm/ttm_tt.c
Am 20.04.22 um 10:56 schrieb Yang Wang:
if the __GFP_ZERO is set, the kvmalloc() can't fallback to use vmalloc()
Hui what? Why should kvmalloc() not be able to fallback to vmalloc()
when __GFP_ZERO is set?
And even that is really the case then that sounds like a bug in kvmalloc().
Regards,
[AMD Official Use Only]
From: Koenig, Christian
Sent: Wednesday, April 20, 2022 5:00 PM
To: Wang, Yang(Kevin) ; dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exceeds kmalloc
limit
.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
base: git://anongit.freedesktop.org/d
Hello!
On 4/19/22 4:36 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> A recent cleanup patch removed the only reference to a local variable
> in some configurations.
>
> Move the variable into the one block it is still used in, inside
> of an #ifdef, to avoid this warning.
>
> Fixes: 9d77
i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.
Instead the lock needs to be taken before actually checking.
v2: move struct declaration
Cc: Chris Wilson
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.free
lmodconfig
(https://download.01.org/0day-ci/archive/20220420/202204201710.5gcg1puu-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmo
On Tue, Apr 19, 2022 at 11:08 PM Laurent Pinchart
wrote:
>
> On Tue, Apr 19, 2022 at 06:16:07PM +0200, Robert Foss wrote:
> > On Tue, 19 Apr 2022 at 11:41, Jagan Teki wrote:
> > >
> > > On Tue, Apr 19, 2022 at 2:44 PM Marek Szyprowski
> > > wrote:
> > > >
> > > > If panel_bridge_attach() happens
On Wed, 2022-04-20 at 13:00 +0530, Vinod Koul wrote:
> On 19-04-22, 09:08, Liu Ying wrote:
> > Hi,
> >
> > This is the v8 series to add i.MX8qxp LVDS PHY mode support for the
> > Mixel
> > PHY in the Freescale i.MX8qxp SoC.
> >
> > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in
>
Am 20.04.22 um 11:07 schrieb Wang, Yang(Kevin):
[AMD Official Use Only]
*From:* Koenig, Christian
*Sent:* Wednesday, April 20, 2022 5:00 PM
*To:* Wang, Yang(Kevin) ;
dri-devel@lists.freedesktop.org ;
amd-...@lists.fre
Move DisplayPort, HDMI and various other display helpers from KMS
helpers into a new module. Adapt all drivers.
This patch is part of an on-going effort to reduce the minimum size
of DRM when linked into the kernel binary. The helpers for various
display and video-output standards are not required
Give the Makefile a bit more structure by putting rules for core,
helpers, drivers, etc next to each other.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/Makefile | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --
Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.
Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The
Replace the DP-helper module with a display-helper module. The
support for DisplayPort becomes an internal option that drivers
have to select. Update all related Kconfig and Makefile rules.
Besides the existing code for DisplayPort, the new module will
contain helpers for other video-output standa
DSC is the Display Stream Compression standard for DisplayPort. Move
the DSC code into display/ and split the header into files for protocol
core and DRM helpers. Adapt all users of the code. No functional
changes.
To avoid the proliferation of Kconfig options, DSC is part of DRM's
support for Dis
Move DRM's HMDI helpers into the display/ subdirectoy and add it
to DRM's display helpers. Update all affected drivers. No functional
changes.
The HDMI helpers were implemented in the EDID and connector code, but
are actually unrelated. With the move to the display-helper library, we
can remove th
Move DRM's HDCP helper library into the display/ subdirectory and add
it to DRM's display helpers. Split the header file into core and helpers.
Update all affected drivers. No functional changes.
v2:
* fix include statements (Jani, Javier)
* update Kconfig symbols
Signed-off-by: T
Move DisplayPort protocol constants and structures into the new
header drm_dp.h, which can be used by DRM core components. The
existing header drm_dp_helper.h now only contains helper code for
graphics drivers. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Lyude Paul
Revie
SCDC is the Status and Control Data Channel for HDMI. Move the SCDC
helpers into display/ and split the header into files for core and
helpers. Update all affected drivers. No functional changes.
To avoid the proliferation of Kconfig options, SCDC is part of DRM's
support for HDMI. If necessary, a
On Mon, 4 Apr 2022 17:45:11 -0300
Igor Torrente wrote:
> This commit is the groundwork to introduce new formats to the planes and
> writeback buffer. As part of it, a new buffer metadata field is added to
> `vkms_writeback_job`, this metadata is represented by the `vkms_composer`
> struct.
Hi,
[AMD Official Use Only]
Hi Chris,
you misunderstood background about this case.
although we expect this test case to fail, it should fail at the location where
the Bo actual memory is actually allocated. now the code logic will cause the
failure to allocate memory to store DMA address.
e.g: t
On Wed, Apr 20, 2022 at 11:24 AM Sergei Shtylyov
wrote:
> On 4/19/22 4:36 PM, Arnd Bergmann wrote:
>
> > From: Arnd Bergmann
> >
> > A recent cleanup patch removed the only reference to a local variable
> > in some configurations.
> >
> > Move the variable into the one block it is still used in,
Hi everyone,
These patches replace the calls to drm_detect_hdmi_monitor() with the
more efficient drm_display_info.is_hdmi in the VC4 driver and, since
this makes the vc4_hdmi_encoder struct redundant, also removes it.
Thanks,
José Expósito
v1:
https://lore.kernel.org/dri-devel/20220406165514.6
Once EDID is parsed, the monitor HDMI support information is cached in
drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video().
This driver calls drm_detect_hdmi_monitor() to receive the same
information and stores its own cached value in
vc4_hdmi_encoder.hdmi_monitor, which is less efficient.
Av
The vc4_hdmi_encoder struct was used exclusively to cache the value
returned by drm_detect_hdmi_monitor() in order to avoid calling it
multiple times.
Now that drm_detect_hdmi_monitor() has been replaced with
drm_display_info.is_hdmi, there is no need to have an extra struct.
Remove vc4_hdmi_enco
Hi Kevin,
no, the test case should already fail in amdgpu_bo_validate_size().
If we have a system with 2TiB of memory where the test case could
succeed then we should increase the requested size to something larger.
And if the underlying core Linux kernel functions don't allow
allocations as
Hello Thomas,
On 4/20/22 13:08, Thomas Zimmermann wrote:
[snip]
> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -1,6 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_DW_HDMI
> tristate
> + select DRM_DISPLAY_HDMI_HELP
On 4/20/22 13:09, Thomas Zimmermann wrote:
> SCDC is the Status and Control Data Channel for HDMI. Move the SCDC
> helpers into display/ and split the header into files for core and
> helpers. Update all affected drivers. No functional changes.
>
> To avoid the proliferation of Kconfig options, SC
Hi
Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:
Hello Thomas,
On 4/20/22 13:08, Thomas Zimmermann wrote:
[snip]
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_DW_HDMI
already checked the possible races and said that the late
connector registration is fine.
> Also, what happens if the panel bridge is detached and reattached ? If I
> recall correctly, registering new connectors at runtime is at least
> partly supported for DP MST, but I'm not sure
On 4/20/22 14:21, Thomas Zimmermann wrote:
> Hi
>
> Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:
>> Hello Thomas,
>>
>> On 4/20/22 13:08, Thomas Zimmermann wrote:
>>
>> [snip]
>>
>>> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> @@ -1
On Mon, 4 Apr 2022 17:45:12 -0300
Igor Torrente wrote:
> Currently the blend function only accepts XRGB_ and ARGB_
> as a color input.
>
> This patch refactors all the functions related to the plane composition
> to overcome this limitation.
>
> A new internal format(`struct pixel`) is
[AMD Official Use Only]
Hi Chirs,
yes, right, the amdgpu drive rwill use amdgpu_bo_validate_size() function to
verify bo size,
but when driver try to allocate VRAM domain bo fail, the amdgpu driver will
fall back to allocate domain = (GTT | VRAM) bo.
please check following code, it will cause
[AMD Official Use Only]
Hi Chris,
1) Change the test case to use something larger than 1TiB.
sure, we can increase the size of BO and make test pass,
but if user really want to allocate 1TB GTT BO, we have no reason to let it
fail? right?
the system availed memory about 2T, but it will still fai
[AMD Official Use Only]
From: Koenig, Christian
Sent: Wednesday, April 20, 2022 8:56 PM
To: Wang, Yang(Kevin) ; Christian König
; dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: fix ttm tt init fail when size exc
Hi
Am 20.04.22 um 14:26 schrieb Javier Martinez Canillas:
On 4/20/22 14:21, Thomas Zimmermann wrote:
Hi
Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:
Hello Thomas,
On 4/20/22 13:08, Thomas Zimmermann wrote:
[snip]
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/dr
On Mon, 4 Apr 2022 17:45:13 -0300
Igor Torrente wrote:
> We will break the current assumption that the primary plane has the
Hi,
I'd say "remove" rather than "break". Breaking sounds bad but this is
good. :-)
> same size and position as CRTC.
...and that the primary plane is the bottom-most
On Mon, 4 Apr 2022 17:45:14 -0300
Igor Torrente wrote:
> This will be useful to write tests that depends on these formats.
>
> ARGB and XRGB follows the a similar implementation of the former formats.
> Just adjusting for 16 bits per channel.
>
> V3: Adapt the handlers to the new format introd
On 4/20/22 15:12, Thomas Zimmermann wrote:
[snip]
>>>
>> Right, but that wasn't my question. I wondered why for example DRM_DW_HDMI
>> Kconfig needs to select both DRM_DISPLAY_HDMI_HELPER and DRM_DISPLAY_HELPER
>> since DRM_DISPLAY_HDMI_HELPER already selects DRM_DISPLAY_HELPER.
>>
>
> Oh, well.
On 4/20/2022 6:26 PM, Christian König wrote:
Am 20.04.22 um 14:54 schrieb Wang, Yang(Kevin):
[AMD Official Use Only]
Hi Chris,
1) Change the test case to use something larger than 1TiB.
sure, we can increase the size of BO and make test pass,
but if user really want to allocate 1TB GTT BO
On Wed, Apr 20, 2022 at 04:05:35PM +0800, Miaoqian Lin wrote:
>
> On 2022/4/20 15:51, Maxime Ripard wrote:
> > On Wed, Apr 20, 2022 at 12:49:48AM +, Miaoqian Lin wrote:
> >> If the device is already in a runtime PM enabled state
> >> pm_runtime_get_sync() will return 1, so a test for negative
Hi Dave & Daniel,
Here go drm-intel-fixes for v5.18-rc4.
Two display fixes: Disable VRR if user disables it from panel settings
and avoid claiming PSR2 is enabled when it is not supported by config.
Regards, Joonas
***
drm-intel-fixes-2022-04-20:
- Unset enable_psr2_sel_fetch if PSR2 detectio
Hi,
On Tue, Apr 19, 2022 at 06:38:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The battery driver uses a lot of GPIO lines, hardcoded from a
> machine header file.
>
> Change it to use a gpiod lookup table instead.
>
> Reviewed-by: Sebastian Reichel
> Acked-by: Sebastian Reichel
On Wed, Apr 20, 2022 at 3:43 PM Sebastian Reichel wrote:
> > @@ -15,11 +15,16 @@
> > #include
>
> This should be now.
>
Fixed now, thanks!
Arnd
If the device is already in a runtime PM enabled state
pm_runtime_get_sync() will return 1.
Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
fails, so use pm_runtime_resume_and_get() instead. this function
will handle this.
Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
S
Hello Ian,
On Wed, Apr 20, 2022 at 09:57:27AM -0400, Ian Cowan wrote:
> On Wed, Apr 20, 2022 at 08:47:11AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 19, 2022 at 03:21:28PM -0400, Ian Cowan wrote:
> > > Removed an unnecessary semicolon at the end of a macro call
> > >
> > > Signed-off-by: Ian
On Tue, Apr 19, 2022 at 03:36:56PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> As a preparation for cleaning up the omap1 headers, start
> including linux/soc/ti/omap1-soc.h directly so we can
> keep calling cpu_is_omap1510().
>
> Signed-off-by: Arnd Bergmann
Acked-by: Greg Kroah-Har
On Thu, Apr 07, 2022 at 11:34:08AM +0200, Paul Kocialkowski wrote:
> With the previous rework of drm_of_find_panel_or_bridge only
> -EPROBE_DEFER is returned while previous behavior allowed -ENODEV
> to be returned when the port/endpoint is either missing or unavailable.
>
> Make the default retur
On 4/20/22 16:36, Uwe Kleine-König wrote:
> Hello Ian,
>
> On Wed, Apr 20, 2022 at 09:57:27AM -0400, Ian Cowan wrote:
>> On Wed, Apr 20, 2022 at 08:47:11AM +0200, Uwe Kleine-König wrote:
>>> On Tue, Apr 19, 2022 at 03:21:28PM -0400, Ian Cowan wrote:
Removed an unnecessary semicolon at the end
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 1/7] dt-bindings: display: renesas,du: Document
> r9a07g044l bindings
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Mar 16, 2022 at 01:10:54PM +, Biju Das wrote:
> > Extend the Renesas DU display bindings to support the
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 2/7] drm: rcar-du: Add num_rpf to struct
> rcar_du_device_info
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Mar 16, 2022 at 01:10:55PM +, Biju Das wrote:
> > Number of RPF's VSP is different on R-Car and RZ/G2L R-Car G
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 3/7] drm: rcar-du: Add max_width and max_height to
> struct rcar_du_device_info
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Mar 16, 2022 at 01:10:56PM +, Biju Das wrote:
> > There are some differences related to max fr
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 4/7] drm: rcar-du: Move rcar_du_output_name() to
> rcar_du_common.c
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Mar 16, 2022 at 01:10:57PM +, Biju Das wrote:
> > RZ/G2L SoC's does not have group/plane registers compare
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v2 5/7] drm: rcar-du: Factorise
> rcar_du_{atomic_check,modeset_init}
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Mar 16, 2022 at 01:10:58PM +, Biju Das wrote:
> > RZ/G2L SoC's does not have group/plane registers compared
On Tue, 19 Apr 2022 23:48:19 +0200, Javier Martinez Canillas wrote:
> The current compatible strings for SSD130x I2C controllers contain both an
> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
> and also that are for devices that can be accessed over an I2C bus.
>
> Bu
Hello Rob,
On 4/20/22 18:15, Rob Herring wrote:
> On Tue, 19 Apr 2022 23:48:19 +0200, Javier Martinez Canillas wrote:
>> The current compatible strings for SSD130x I2C controllers contain both an
>> "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
>> and also that are for
Hi folks:
Here is the PR of gvt-next. Thanks so much for the patience.
Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the
GVT-g with the
new MDEV interfaces:
- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jaso
On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table f
On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:
On 20/04/2022 04:45, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v2:
On 4/19/22 23:48, Javier Martinez Canillas wrote:
> Hello,
>
> This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
> support for SSD130x OLED controllers that can be accessed over a SPI bus.
>
> The driver is quite similar to existing ssd130x-i2c driver that is used by
> I2
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
On 4/19/2022 11:59 PM, Dmitry Baryshkov wrote:
On 20/04/2022 04:46, Abhinav Kumar wrote:
Add changes to support writeback module in the dpu_hw_ctl
interface.
changes in v2:
- keep only the wb specific changes to reset_intf_cfg
- use cfg->intf / cfg->wb to identify intf or wb
- us
On 4/20/22 17:47, Javier Martinez Canillas wrote:
[snip]
>>
>>> When I built this, it appeared to succeed. I used the command "make
>>> M=/drivers/staging/fbtft modules". Is this incorrect? For reference this
>>> is my first patch so it's highly likely I did this incorrectly.
>>
>
> You are just
On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
> ⚠ External Email
>
> Hi Zack,
>
> Am 20.04.22 um 05:56 schrieb Zack Rusin:
> > On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> > > Rework the internals of the dma_resv object to allow adding more
> > > than
> > > one
> > > wr
Am 20.04.22 um 19:38 schrieb Zack Rusin:
On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
⚠ External Email
Hi Zack,
Am 20.04.22 um 05:56 schrieb Zack Rusin:
On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
Rework the internals of the dma_resv object to allow adding more
tha
On Wed, 20 Apr 2022 13:43:51 -0300
Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > Hi folks:
> >
> > Here is the PR of gvt-next. Thanks so much for the patience.
> >
> > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> > th
On 4/20/2022 12:44 AM, Dmitry Baryshkov wrote:
On 20/04/2022 04:46, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v2:
- add the writeback parts to dpu_encoder_helper_phys_cleanup
- rebase on tip of msm-next
On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote:
> On Wed, 20 Apr 2022 13:43:51 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > > Hi folks:
> > >
> > > Here is the PR of gvt-next. Thanks so much for the patience.
> > >
> > >
On Wed, 20 Apr 2022 at 20:01, Abhinav Kumar wrote:
>
>
>
> On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:
> > On 20/04/2022 04:45, Abhinav Kumar wrote:
> >> Add the dpu_hw_wb abstraction to program registers related to the
> >> writeback block. These will be invoked once all the configuration
> >>
Hi Dmitry
Sorry, I missed answering one question.
On 4/20/2022 10:49 AM, Dmitry Baryshkov wrote:
On Wed, 20 Apr 2022 at 20:01, Abhinav Kumar wrote:
On 4/20/2022 12:20 AM, Dmitry Baryshkov wrote:
On 20/04/2022 04:45, Abhinav Kumar wrote:
Add the dpu_hw_wb abstraction to program registers
1 - 100 of 209 matches
Mail list logo
