The driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/imx/dcss/dcss-kms.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c
b/drivers/
Hi
Am 10.03.21 um 03:50 schrieb nerdopolis:
On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote:
Hey
On request of Noralf, I picked up the patches and prepared v5. Works fine with
Xorg, if configured according to:
https://lists.freedesktop.org/archives/dri-devel/2014-January/
On Sun, 28 Feb 2021, Konrad Dybcio wrote:
> Document the newly added PMI8994 compatible.
>
> Signed-off-by: Konrad Dybcio
Applied, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good (with the metioned fix in
https://lore.kernel.org/lkml/
On Tue, Mar 09, 2021 at 04:53:41PM +0100, Christoph Hellwig wrote:
> Add a new alloc_anon_inode helper that allocates an inode on
> the anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good!
Reviewed-by: Christian Brauner
___
d
Hi,
This is the v5 series to add some DRM bridge drivers support
for i.MX8qm/qxp SoCs.
The bridges may chain one by one to form display pipes to support
LVDS displays. The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.
The DPU KMS driver can be found at:
https://www.spinics.ne
This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
The RGB pixels with padding low per component are transmitted on a 30-bit
input bus(10-bit per component) from a display controller or a 36-bit
output bu
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two scre
This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
pixel combiner. The RGB pixels with padding low per component are
transmitted on a 30-bit input bus(10-bit per component) from a display
controller o
This patch adds bindings for i.MX8qm/qxp pixel combiner.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Use enum instead of oneOf + const for the reg property of pixel combiner
This patch adds bindings for i.MX8qm/qxp display pixel link.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Require all four pixel link output ports. (Laurent)
* Mention pixel
This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays). It consists of two distinct
functions, a pixel transfer function and a c
This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
Signed-off-by: Liu Ying
---
v4->v5:
* No change.
v3->v4:
* Add 'fsl,sc-resource' property. (Rob)
v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls PXL2DPI.
v1->v2:
* Use graph schema. (Laurent)
.../
This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
Signed-off-by: Liu Ying
---
v4->v5:
* Newly introduced in v5. (Rob)
.../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 202 +
1 file changed, 202 insertions(+)
create mode 100644 Documentation/d
This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI). The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color c
This patch adds a helper to support LDB drm bridge drivers for
i.MX SoCs. Helper functions supported by this helper should
implement common logics for all LDB modules embedded in i.MX SoCs.
Signed-off-by: Liu Ying
---
v4->v5:
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB
This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v4->v5:
* No change.
v3->v4:
* Add Rob's R-b tag.
v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls LDB.
v1->v2:
* Use graph schema. (Laurent)
*
This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 24bpp parallel input color format and can map
the input to VESA or JEIDA standards. The two channels cannot be used
simultaneo
This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 30bpp parallel input color format and can
map the input to VESA or JEIDA standards. The two channels can be used
simultaneously
Add myself as the maintainer of DRM bridge drivers for i.MX SoCs.
Signed-off-by: Liu Ying
---
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 63bd69
On Wed, Mar 10, 2021 at 09:58:06AM +0100, Christoph Hellwig wrote:
> On Fri, Mar 05, 2021 at 10:00:12AM +, Will Deacon wrote:
> > > But one thing I'm not sure about is whether
> > > IO_PGTABLE_QUIRK_ARM_OUTER_WBWA is something that other devices
> > > *should* be using as well, but just haven't
Den 10.03.2021 05.55, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> Depending on how long it takes for the DMA mask dependency patch to show
>>> up in drm-misc-next, I will either publish a new version or apply the
>>> current and provide patches with the necessary fixes.
>>
>> In case I apply
it-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-writeback-Use-simple-encoder/20210310-153629
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
05a59d79793d482f628a31753c671f2e92178a21
config: x86_64-randconfig-m001-20210308 (a
Hi Liu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on robh/for-next drm-intel/for-linux-next
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot
On 08. 03. 21 20:20, Alex Deucher wrote:
> Should be fixed here:
> https://patchwork.freedesktop.org/patch/423250/
>
> Alex
Thanks, it works for me! I tried only the first patch from the series,
the rest didn't look relevant to me. I can try that too.
I didn't test it thoroughly (I don't know ho
Hi Liu,
Thank you for the patch.
On Wed, Mar 10, 2021 at 05:55:26PM +0800, Liu Ying wrote:
> This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
> RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
> pixel combiner. The RGB pixels with padding low pe
Hi Liu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on robh/for-next drm-intel/for-linux-next
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot
Hi Liu,
Thank you for the patch.
On Wed, Mar 10, 2021 at 05:55:25PM +0800, Liu Ying wrote:
> This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
> and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
> The RGB pixels with padding low per component are tran
There's no need to give the page an address_space. Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's set now, and that was the only reason to
set the address_space in the first place.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/video/fb
&st7789v_fops,
+ DRM_GEM_CMA_DRIVER_OPS_VMAP,
+ .debugfs_init = mipi_dbi_debugfs_init,
+ .name = "st7789v",
+ .desc = "Sitronix ST7789R",
+ .date = "20210310",
+ .major
From: "Carlis"
Document support for the Waveshare 2inch LCD module display, which is a
240x320 2" TFT display driven by a Sitronix ST7789V TFT Controller.
Signed-off-by: Carlis
---
.../bindings/display/sitronix,st7789v.yaml | 72 ++
1 file changed, 72 insertions(+)
From: Mark Yacoub
On initializing the framebuffer, call drm_any_plane_has_format to do a
check if the modifier is supported. drm_any_plane_has_format calls
dm_plane_format_mod_supported which is extended to validate that the
modifier is on the list of the plane's supported modifiers.
The bug was
Disabling GFXOFF via the quirk list fixes a hardware lockup in
Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
Signed-off-by: Daniel Gomez
---
This patch is a continuation of the work here:
https://lkml.org/lkml/2021/2/3/122 where a hardware lockup was discussed and
a dma_fence deadlock was provoke
One more update. without changing any cmake files the following cmdline
should work:
cmake ../llvm-project/libclc/
-DLLVM_CONFIG=/usr/local/llvm-git/bin/llvm-config
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc
Jan
On Wed, Mar 10, 2021 at 1:20 AM Jan Vesely wrote:
> hi,
>
> s
On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez wrote:
>
> Disabling GFXOFF via the quirk list fixes a hardware lockup in
> Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
>
> Signed-off-by: Daniel Gomez
> ---
>
> This patch is a continuation of the work here:
> https://lkml.org/lkml/2021/2/3/122 where
On 2021-02-09 18:43:54 [+0100], Christian König wrote:
> Hi Sebastian,
Hi Christian,
> to be honest I'm thinking about that for quite some time now and I don't
> think that this is possible without a severe rewrite of the driver.
>
> The problem is simply that we have a lot of functions which dea
On Wednesday, March 10, 2021 4:10:35 AM EST Thomas Zimmermann wrote:
> Hi
>
> Am 10.03.21 um 03:50 schrieb nerdopolis:
> > On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote:
> >> Hey
> >>
> >> On request of Noralf, I picked up the patches and prepared v5. Works fine
> >> with
> >>
Qa
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
+ "failed to find bridge for companion bridge: %d\n", ret);
>> + goto out;
>> + }
>> +
>> + DRM_DEV_DEBUG_DRIVER(dev,
>> + "dual-link configuration detected (companion bridge %pOF)\n",
>> + companion);
>> +
>>
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
Sent from ProtonMail mobile
Original Message
On Mar 10, 2021, 12:10, wrote:
> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> o
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
On Wed, Mar 10, 2021 at 06:38:07PM +, William Kucharski wrote:
> Looks good, just one super minor nit inline.
> > @@ -228,13 +202,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> >
> > BUG_ON(!fbdefio);
> > cancel_delayed_work_sync(&info->deferred_work);
> > -
> > - /* clear
On Tue, Mar 09, 2021 at 10:09:13AM +0530, Ankit Nautiyal wrote:
> Currently the FRL training mode (Concurrent, Sequential) and
> training type (Normal, Extended) are not defined properly and
> are passed as bool values in drm_helpers for pcon
> configuration for FRL training.
>
> This patch:
> -Ad
On Tue, Mar 09, 2021 at 03:54:09PM +0200, Jani Nikula wrote:
> If there's no need to change it, it should be const. There's more to be
> done, but start off with changes that make follow-up work easier. No
> functional changes.
>
> Signed-off-by: Jani Nikula
const is good.
Reviewed-by: Ville Sy
There's no need to give the page an address_space. Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's handled now, and that was the only reason to
set the address_space in the first place.
Signed-off-by: Matthew Wilcox (Oracle)
Reviewed-by: Chri
On Tue, Mar 09, 2021 at 03:54:10PM +0200, Jani Nikula wrote:
> We'll be adding more DisplayID specific functions going forward, so
> start off by splitting out a few functions to a separate file.
>
> We don't bother with exporting the functions; at least for now they
> should be needed solely with
Hi Hillf,
Le lun. 8 mars 2021 à 11:47, Hillf Danton a écrit :
On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
With the module parameter ingenic-drm.cached_gem_buffers, it is
possible
to specify that we want GEM buffers backed by non-coherent memory.
This dramatically speeds up so
Hi Thomas,
Le lun. 8 mars 2021 à 9:41, Thomas Zimmermann a
écrit :
Hi Paul,
having individual functions for each mode only makes sense if the
decision is at compile time. But in patch 5, you're working around
your earlier design by introducing in-driver helpers that select the
correct CMA
On Tue, Mar 09, 2021 at 03:54:11PM +0200, Jani Nikula wrote:
> Iterating DisplayID blocks across sections (in EDID extensions) is
> unnecessarily complicated for the caller. Implement DisplayID iterators
> to go through all blocks in all sections.
>
> Usage example:
>
> const struct display
On Tue, Mar 09, 2021 at 03:54:12PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 23 ++-
> 1 file changed, 6 insertions(+), 17 d
On Wed, 10 Mar 2021 at 17:48, Maxime Ripard wrote:
>
> Hi Dave,
>
> On Wed, Mar 10, 2021 at 09:50:29AM +1000, Dave Airlie wrote:
> > I'm mostly sending this to the -misc maintainers because
> > drm-misc-fixes is based on rc1 at present.
> >
> > This needs to be *rebased* not merged up to 5.12-rc2.
On Tue, Mar 09, 2021 at 03:54:13PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 25 +
> 1 file changed, 9 insertions(+), 16
On Tue, Mar 09, 2021 at 03:54:14PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. Remove excessive debug
> logging while at it, no other functional changes.
>
> The old displayid iterator becomes unused; remove it as well as make
> drm_find_displayid_extension() static.
>
Hi Liu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on robh/for-next drm-intel/for-linux-next
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot apply
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #5 from Bat Malin (bat_ma...@abv.bg) ---
Issue still present in 5.11.5
1.335057] amdgpu: Clock is not in range of specified clock range for watermark
from DAL! Using highest water mark set.
--
You may reply to this email to add a c
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #6 from Bat Malin (bat_ma...@abv.bg) ---
No change in the code of 5.12-rc2...
for (i = 0; i < dep_mclk_table->count; i++) {
for (j = 0; j < dep_sclk_table->count; j++) {
valid_entry = false;
libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time
both used libdrm and so did the Intel X11 back-end. The SNA back-end
for X11
still need more expert to review, so just a gentle ping for this patch
On Wed, May 27, 2020 at 4:35 PM Stephen Boyd wrote:
>
> Quoting dillon.min...@gmail.com (2020-05-27 00:27:29)
> > From: dillon min
> >
> > This is due to misuse \u2018PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
> > 'PLL_SAI' i
On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
Umm... The only problem I see here is the lifetime rules for
that module, and that's not something introduced in this patchset.
Said that, looks like the logics around that place is d
Looks good, just one super minor nit inline.
Reviewed-by: William Kucharski
> On Mar 10, 2021, at 6:51 AM, Matthew Wilcox (Oracle)
> wrote:
>
> There's no need to give the page an address_space. Leaving the
> page->mapping as NULL will cause the VM to handle set_page_dirty()
> the same way t
still need more expert to review, so just a gentle ping for this patch
On Wed, May 27, 2020 at 4:35 PM Stephen Boyd wrote:
>
> Quoting dillon.min...@gmail.com (2020-05-27 00:27:30)
> > From: dillon min
> >
> > stm32's clk driver register two ltdc gate clk to clk core by
> > clk_hw_register_gate(
On Tue, Mar 09, 2021 at 04:53:43PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
Are you changing the lifetime rules for that module?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
eb_copy_relocations() only do unsafe_put_user(), it only
requires write access to user.
Use user_write_access_begin() instead of user_access_begin().
Signed-off-by: Christophe Leroy
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
d
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
From: Sean Paul
This patch adds some newlines which are missing from debug messages.
This will prevent logs from being stacked up in dmesg.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
From: Sean Paul
One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert
it to the new shiny.
Signed-off-by: Sean Paul
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/d
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
Hi Dave, Daniel,
Fixes for 5.12.
The following changes since commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff:
drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie
(2021-03-03 23:05:16 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux
On 2021-03-09 11:50 a.m., Felix Kuehling wrote:
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld:
On Wed, Mar 10, 2021 at 8:11 PM Dave Airlie wrote:
>
> On Wed, 10 Mar 2021 at 17:48, Maxime Ripard wrote:
> >
> > Hi Dave,
> >
> > On Wed, Mar 10, 2021 at 09:50:29AM +1000, Dave Airlie wrote:
> > > I'm mostly sending this to the -misc maintainers because
> > > drm-misc-fixes is based on rc1 at pr
+Zbigniew for review
On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson wrote:
> - ("drm/panel-simple: Don't wait longer for HPD...") new for v2.
> - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2.
I couldn't find these patches in my inbox but my concern would
be that at some point panel-simple
Hi,
On Wed, Mar 10, 2021 at 3:25 PM Linus Walleij wrote:
>
> On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson
> wrote:
>
> > - ("drm/panel-simple: Don't wait longer for HPD...") new for v2.
> > - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2.
>
> I couldn't find these pa
Looks good; my apologies for missing the leftover declaration of struct page in
the same routine which you also found and removed this time around.
> On Mar 10, 2021, at 11:55 AM, Matthew Wilcox (Oracle)
> wrote:
>
> There's no need to give the page an address_space. Leaving the
> page->mappi
On Thu, Mar 11, 2021 at 12:47 AM Doug Anderson wrote:
> I guess what I'd say in summary is:
>
> * If you object to the retries in simple panel, I still hope the rest
> of the series can land.
>
> * If somehow this panel gets out into real users hands and we find
> that the retries are necessary a
Hi,
On Wed, Mar 10, 2021 at 4:57 PM Linus Walleij wrote:
>
> On Thu, Mar 11, 2021 at 12:47 AM Doug Anderson wrote:
>
> > I guess what I'd say in summary is:
> >
> > * If you object to the retries in simple panel, I still hope the rest
> > of the series can land.
> >
> > * If somehow this panel g
Jason Ekstrand writes:
> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
> which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time
> both used libdrm and so did the Intel X11 ba
On Wed, 10 Mar 2021 19:01:01 + Paul Cercueil wrote:
>Le lun. 8 mars 2021 � 11:47, Hillf Danton a �crit :
>> On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
>>> With the module parameter ingenic-drm.cached_gem_buffers, it is
>>> possible
>>> to specify that we want GEM buffers backe
1. make function mmhub_v1_7_setup_vm_pt_regs static
2. indent a if statement
Signed-off-by: Oak Zeng
Reported-by: kernel test robot
Reported-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c | 2 +-
2 files changed, 3 insertions(+
ioremap_cache is not supported on some architecture
such as s390. Put the codes into a #ifdef to fix
some compile error reported by test robot.
Signed-off-by: Oak Zeng
Reported-by: Kernel test robot
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
From: Dave Airlie
The index variable should only be increased in one place.
Noticed this while trying to track down another oops.
v2: use while loop.
Fixes: f295c8cfec83 ("drm/nouveau: fix dma syncing warning with debugging on.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau
Hi Laurent,
On Wed, 2021-03-10 at 15:24 +0200, Laurent Pinchart wrote:
> Hi Liu,
>
> Thank you for the patch.
Thanks for your review.
>
> On Wed, Mar 10, 2021 at 05:55:26PM +0800, Liu Ying wrote:
> > This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
> > RGB666_1X36_CPA
Hi
Am 10.03.21 um 20:02 schrieb Paul Cercueil:
Hi Thomas,
Le lun. 8 mars 2021 à 9:41, Thomas Zimmermann a
écrit :
Hi Paul,
having individual functions for each mode only makes sense if the
decision is at compile time. But in patch 5, you're working around
your earlier design by introducin
88 matches
Mail list logo
