Since i915_gem_create_context() function return error pointers,
the kernel_context() function does not return null, It returns error
pointers too. Using IS_ERR() to check the return value to fix this.
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 41
Am 21.12.21 um 17:03 schrieb Andrey Grodzovsky:
On 2021-12-21 2:02 a.m., Christian König wrote:
Am 20.12.21 um 20:22 schrieb Andrey Grodzovsky:
On 2021-12-20 2:17 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Restrict jobs resubmission to suspend case
only
Hi Stephen,
Am 22.12.21 um 04:50 schrieb Stephen Rothwell:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_fence.c
between commit:
67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared ones
v2")
from the
Since drm_prime_pages_to_sg() function return error pointers.
The drm_gem_shmem_get_sg_table() function returns error pointers too.
Using IS_ERR() to check the return value to fix this.
Fixes: f651c8b05542("drm/virtio: factor out the sg_table from
virtio_gpu_object")
Signed-off-by: Miaoqian Lin
Am Mi., 22. Dez. 2021 um 01:17 Uhr schrieb Lucas Stach :
>
> Some GPU heavy test programs manage to trigger the hangcheck quite often.
> If there are no other GPU users in the system and the test program
> exhibits a very regular structure in the commandstreams that are being
> submitted, we can
From: Ira Weiny
kmap() is being deprecated and these usages are all local to the thread
so there is no reason kmap_local_page() can't be used.
Replace kmap() calls with kmap_local_page().
Signed-off-by: Ira Weiny
---
NOTE: I'm sending as a follow on to the V1 patch. Please let me know if
Since almost drivers support fb modifiers, allow_fb_modifiers is
replaced with fb_modifiers_not_supported and removed.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_framebuffer.c| 6 +++---
drivers/gpu/drm/drm_ioctl.c | 2 +-
Set fb_modifiers_not_supported flag in legacy drivers whose planes
support non-linear layouts but does not support modifiers, and replace
allow_fb_modifiers with fb_modifiers_not_supported.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +++---
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers. However, there are legacy drivers such as radeon that do not
support modifiers but infer the actual layout of the underlying buffer.
Therefore, a new flag not_support_fb_modifires is introduced for these
legacy
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the DRM core should handle this
rather than open-coding in every driver.
In this patch series, these drivers expose format modifiers based on the
following
Hi Dave and Daniel,
Just four cleanups such as replacing the use of legacy interface,
implementing generic gem mmap,
fixing a build warning and dropping unnecessary code.
Please let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_fence.c
between commit:
67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared
ones v2")
from the drm-misc-fixes tree and commit:
40298cb45071 ("drm/nouveau: use the
21.12.2021 21:01, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 19:17, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
21.12.2021 13:58, Thierry Reding пишет:
..
The panel->ddc
Hi
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, December 22, 2021 5:56 AM
To: Thomas Zimmermann
Subject: Re: [PATCH] drm/ast: Support 1600x900 with 108MHz PCLK
On Mon, 2 Nov 2020 at 17:57, Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.10.20 um 08:42
Some GPU heavy test programs manage to trigger the hangcheck quite often.
If there are no other GPU users in the system and the test program
exhibits a very regular structure in the commandstreams that are being
submitted, we can end up with two distinct submits managing to trigger
the hangcheck
Hi,
On 12/22/21 01:11, Rajat Jain wrote:
> Add a static entry in the x86 table, to detect and wait for
> privacy-screen on some ChromeOS platforms.
>
> Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
> enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
Add a static entry in the x86 table, to detect and wait for
privacy-screen on some ChromeOS platforms.
Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
shall return EPROBE_DEFER until a platform driver
This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.
Note that ideally, we'd want this privacy screen driver to be probed
BEFORE the drm probe in order to avoid a drm probe deferral:
https://hansdegoede.livejournal.com/25948.html
In practise, I
On 2021-11-16 15:42:15, Lee Jones wrote:
> On Tue, 16 Nov 2021, Daniel Thompson wrote:
>
> > Hi Lee
> >
> > On Mon, Nov 15, 2021 at 09:34:50PM +0100, Marijn Suijten wrote:
> > > This patchset fixes WLED's handling of enabled-strings: besides some
> > > cleanup it is now actually possible to
On Mon, Dec 20, 2021 at 06:11:31PM +0100, Daniel Vetter wrote:
> On Mon, Dec 20, 2021 at 10:18:38AM +0100, Daniel Vetter wrote:
> > On Thu, Dec 02, 2021 at 10:51:12AM +0100, Claudio Suarez wrote:
> > > The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log
> > > calls in drm core, files
On 12/21/2021 05:37, Tvrtko Ursulin wrote:
On 20/12/2021 18:34, John Harrison wrote:
On 12/20/2021 07:00, Tvrtko Ursulin wrote:
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko
On Mon, 2 Nov 2020 at 17:57, Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.10.20 um 08:42 schrieb KuoHsiang Chou:
> > [New] Create the setting for 1600x900 @60Hz refresh rate
> > by 108MHz pixel-clock.
> >
> > Signed-off-by: KuoHsiang Chou
>
> Acked-by: Thomas Zimmermann
>
> I'll add your
From: John Harrison
A fault injection probe test hit a BUG_ON in a GuC error path. It
showed that the GuC code could potentially attempt to do many things
when the device is actually wedged. So, add a check in to prevent that.
v2: Use intel_gt_is_wedged instead of testing bits directly in the
Hi,
Thank you for testing it all.
21.12.2021 21:55, Jon Hunter пишет:
> Hi Dmitry, Thierry,
>
> On 30/11/2021 23:23, Dmitry Osipenko wrote:
>> Add runtime PM and OPP support to the Host1x driver. For the starter we
>> will keep host1x always-on because dynamic power management require a
>>
Yes, you can either do that, or if amdgpu is loaded, just read the data
from /sys/kernel/debug/dri/0/amdgpu_vbios
Alex
On Mon, Dec 20, 2021 at 3:06 AM 周宗敏 wrote:
>
>
> Dear Alex:
>
>
> I've never tried to get a VBIOS before, so can you tell me how to get a
> vbios image copy for you?
>
> I
From: John Harrison
There is a known (but exceedingly unlikely) race condition where the
asynchronous frequency management code could reduce the GT clock while
a GuC reload is in progress (during a full GT reset). A fix is in
progress but there are complex locking issues to be resolved. In the
From: John Harrison
If the GuC fails to load, it is useful to know what firmware file /
version was attempted. So move the version info report to before the
load attempt rather than only after a successful load.
If the GuC does fail to load, then make the error messages visible
rather than
From: John Harrison
Update to the latest GuC release.
The latest GuC firmware introduces a number of interface changes:
GuC may return NO_RESPONSE_RETRY message for requests sent over CTB.
Add support for this reply and try resending the request again as a
new CTB message.
A KLV
From: John Harrison
Update to the latest GuC version. This includes a suite of interface
changes and new features with corresponding i915 side changes.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Temporarily bump the GuC load timeout
drm/i915/guc: Update to GuC version
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
v4:
- Rebase.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile| 1 +
From: Christian König
First of all as discussed multiple times now kernel copies *must* always
wait for all fences in a BO before actually doing the copy. This is
mandatory.
Additional to that drop the handling when there can't be a shared slot
allocated on the source BO and just properly
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us
This is the first three already reviewed patches from the patch series titled
"Asynchronous vma unbinding", with an additional cleanup patch from Christian,
which would otherwise conflict heavily with this series.
Christian König (1):
drm/i915: remove questionable fence optimization during copy
From: Michał Winiarski
GGTT is currently available both through i915->ggtt and gt->ggtt, and we
eventually want to get rid of the i915->ggtt one.
Use to_gt() for all i915->ggtt accesses to help with the future
refactoring.
During the probe of i915 the early intiialization of the gt
On Sat, 18 Dec 2021 16:23:09 +0100, Marek Vasut wrote:
> Add compatible string for TI DS90CF364A, which is another LVDS to DPI
> decoder similar to DS90CF384A, except it is using smaller package and
> only provides 18bit DPI bus.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob
Hi Matt,
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 170bba913c30..128315aec517 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1630,7 +1630,7 @@ static int alloc_noa_wait(struct
On Fri, Dec 17, 2021 at 06:07:15PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Convert the Texas Instruments LP855x backlight device tree bindings from
> the free-form text format to json-schema.
>
> Signed-off-by: Thierry Reding
> ---
> .../bindings/leds/backlight/lp855x.txt
On Fri, 17 Dec 2021 18:07:14 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> LEDs can use rfkill events as a trigger source, so document these in the
> device tree bindings.
>
> Signed-off-by: Thierry Reding
> ---
> .../devicetree/bindings/leds/common.yaml| 17
From: Ville Syrjälä
Replace the slightly odd "#define NULL" thing with
a standard static inline stub.
Cc: Noralf Trønnes
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
include/drm/drm_mipi_dbi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Remove the counterproductive CONFIG_DEBUG_FS ifdef and just include
the debugfs dentry in drm_crtc always. This way we don't need
annoying ifdefs in the actual code with DEBUGFS=n. Also we don't
have these ifdefs around any of the other debugfs dentries either
so can't see
On Tue, Dec 21, 2021 at 08:52:09AM -0400, Rob Herring wrote:
> With 'unevaluatedProperties' support enabled, several SPI based display
> binding examples have warnings:
>
> Documentation/devicetree/bindings/display/panel/samsung,ld9040.example.dt.yaml:
> lcd@0: Unevaluated properties are not
On Tue, Dec 21, 2021 at 08:51:26AM -0400, Rob Herring wrote:
> With 'unevaluatedProperties' support enabled, the novatek,nt36672a
> binding has a new warning:
>
> Documentation/devicetree/bindings/display/panel/novatek,nt36672a.example.dt.yaml:
> panel@0: Unevaluated properties are not allowed
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
Add runtime PM and OPP support to the Host1x driver. For the starter we
will keep host1x always-on because dynamic power management require a major
refactoring of the driver code since lot's of code paths are missing the
RPM
Hi,
On 12/20/21 23:28, Rajat Jain wrote:
> Add a static entry in the x86 table, to detect and wait for
> privacy-screen on some ChromeOS platforms.
>
> Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
> enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
Hi,
On 12/20/21 23:28, Rajat Jain wrote:
> Allow a privacy screen provider to stash its private data pointer in the
> drm_privacy_screen, and update the drm_privacy_screen_register() call to
> accept that. Also introduce a *_get_drvdata() so that it can retrieved
> back when needed.
>
> This
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged. Also make
sure dp controller had been initialized before start dpcd read and write.
Changes in V4:
On Fri, 17 Dec 2021 17:43:20 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> This also adds the missing display-hub DT bindings that were not
> previously documented.
>
> Signed-off-by:
On 12/21/2021 10:11 AM, Ewins, Jon wrote:
On 12/20/2021 3:52 PM, Sundaresan, Sujaritha wrote:
On 12/16/2021 3:30 PM, Vinay Belgaumkar wrote:
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008,
On 12/20/2021 3:52 PM, Sundaresan, Sujaritha wrote:
On 12/16/2021 3:30 PM, Vinay Belgaumkar wrote:
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so
On 12/14/2021 5:50 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-12-09 13:35:07)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0766752..cfbc5e4 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@
21.12.2021 21:10, Robert Foss пишет:
> Hey Dmitry,
>
> On Sun, 19 Dec 2021 at 17:02, Dmitry Osipenko wrote:
>>
>> 19.10.2021 23:37, Dmitry Osipenko пишет:
>>> 19.10.2021 12:47, Robert Foss пишет:
Applied to drm-misc-next
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
Hi Rob,
Le mar., déc. 21 2021 at 08:52:09 -0400, Rob Herring
a écrit :
With 'unevaluatedProperties' support enabled, several SPI based
display
binding examples have warnings:
Documentation/devicetree/bindings/display/panel/samsung,ld9040.example.dt.yaml:
lcd@0: Unevaluated properties are
Hey Dmitry,
On Sun, 19 Dec 2021 at 17:02, Dmitry Osipenko wrote:
>
> 19.10.2021 23:37, Dmitry Osipenko пишет:
> > 19.10.2021 12:47, Robert Foss пишет:
> >> Applied to drm-misc-next
> >>
> >> On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
> >>>
> >>> This series adds couple improvements to
On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 19:17, Thierry Reding пишет:
> > On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 13:58, Thierry Reding пишет:
> >> ..
> >> The panel->ddc isn't used by the new panel-edp driver unless
Applied to drm-misc-next
Am Montag, 20. Dezember 2021, 12:06:28 CET schrieb Sascha Hauer:
> Add a device node to drm_encoder which corresponds with the port node
> in the DT description of the encoder. This allows drivers to find the
> of_graph link between a crtc and an encoder.
>
> Signed-off-by: Sascha Hauer
> ---
>
On 21/12/2021 16:07, Thomas Hellström wrote:
On Tue, 2021-12-21 at 14:02 +, Matthew Auld wrote:
On 17/12/2021 14:52, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma
before
calling unbind on the vma_resource.
Add the resulting unbind fence to the
On Sun, Dec 19, 2021 at 11:24:56PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
On Sun, Dec 19, 2021 at 11:24:55PM +0200, Andi Shyti wrote:
> From: Michał Winiarski
>
> GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> eventually want to get rid of the i915->ggtt one.
> Use to_gt() for all i915->ggtt accesses to help with the future
> refactoring.
>
21.12.2021 19:17, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 13:58, Thierry Reding пишет:
>> ..
>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>> compatible with "edp-panel". Hence the
On 2021-12-15 16:43:45, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2021-12-15 12:02:37)
> > On 14/12/2021 22:46, Marijn Suijten wrote:
> > > Hi all,
> > >
> > > On 2021-09-18 16:40:38, Marijn Suijten wrote:
> > >> On 2021-09-14 14:44:01, Stephen Boyd wrote:
> > >>> Quoting Marijn Suijten
On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 13:58, Thierry Reding пишет:
> ..
> The panel->ddc isn't used by the new panel-edp driver unless panel is
> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> either fail or crash
On 2021-12-21 2:59 a.m., Christian König wrote:
Am 20.12.21 um 23:17 schrieb Andrey Grodzovsky:
On 2021-12-20 2:20 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize
On Tue, 2021-12-21 at 14:02 +, Matthew Auld wrote:
> On 17/12/2021 14:52, Thomas Hellström wrote:
> > Implement async (non-blocking) unbinding by not syncing the vma
> > before
> > calling unbind on the vma_resource.
> > Add the resulting unbind fence to the object's dma_resv from where
> > it
On 2021-12-21 2:02 a.m., Christian König wrote:
Am 20.12.21 um 20:22 schrieb Andrey Grodzovsky:
On 2021-12-20 2:17 a.m., Christian König wrote:
Am 17.12.21 um 23:27 schrieb Andrey Grodzovsky:
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
21.12.2021 13:58, Thierry Reding пишет:
..
The panel->ddc isn't used by the new panel-edp driver unless panel is
compatible with "edp-panel". Hence the generic_edp_panel_probe() should
either fail or crash for a such "edp-panel" since panel->ddc isn't fully
instantiated,
From: Changcheng Deng
Fix the following coccicheck warning:
./drivers/gpu/drm/msm/msm_debugfs.c: 132: 0-23: WARNING: shrink_fops
should be defined with DEFINE_DEBUGFS_ATTRIBUTE
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for
debugfs files.
Reported-by: Zeal Robot
On Mon, Dec 20, 2021 at 12:06:19PM +0100, Sascha Hauer wrote:
> The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
> The binding differs slightly from the existing VOP binding, so add a new
> binding file for it.
>
> Signed-off-by: Sascha Hauer
> ---
>
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
> "vpll" is a misnomer. A clock input to a device should be named after
> the usage in the device, not after the clock that drives it. On the
> rk3568 the same clock is driven by the HPLL.
> To fix that, this patch renames the vpll
On 17/12/2021 14:52, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should
On Montag, 20. Dezember 2021 12:06:30 CET Sascha Hauer wrote:
> From: Andy Yan
>
> The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> It replaces the VOP unit found in the older Rockchip SoCs.
>
> This driver has been derived from the downstream Rockchip Kernel and
>
On 20/12/2021 18:34, John Harrison wrote:
On 12/20/2021 07:00, Tvrtko Ursulin wrote:
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
On 14/12/2021 15:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Log engine resets done by the
On Tue, Dec 21, 2021 at 1:52 PM Rob Herring wrote:
> With 'unevaluatedProperties' support enabled, several SPI based display
> binding examples have warnings:
(...)
> Fix all of these by adding a reference to spi-peripheral-props.yaml.
> With this, the description that the binding must follow
>
With 'unevaluatedProperties' support enabled, several SPI based display
binding examples have warnings:
Documentation/devicetree/bindings/display/panel/samsung,ld9040.example.dt.yaml:
lcd@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells',
'spi-max-frequency',
With 'unevaluatedProperties' support enabled, the st,stm32-dsi binding
has a new warning:
Documentation/devicetree/bindings/display/st,stm32-dsi.example.dt.yaml:
dsi@5a00: Unevaluated properties are not allowed ('panel-dsi@0' was
unexpected)
The documented child node name is 'panel', so
With 'unevaluatedProperties' support enabled, the novatek,nt36672a
binding has a new warning:
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.example.dt.yaml:
panel@0: Unevaluated properties are not allowed ('vddi0-supply',
'#address-cells', '#size-cells' were unexpected)
On Tuesday, December 21st, 2021 at 13:33, Dmitry Baryshkov
wrote:
> I'd still suggest to fix create_in_format_blob()
Yeah, I agree. I thought there were a good reason why create_in_format_blob()
behaves this way but can't find anything in the Git history, so fixing it to
behave as the
On Tue, 21 Dec 2021 at 13:50, Simon Ser wrote:
>
> On Tuesday, December 21st, 2021 at 11:48, Dmitry Baryshkov
> wrote:
>
> > I think the fix should be applied to the generic code.
>
> Related:
>
Quoting Antonio Borneo (2021-12-20 15:53:12)
> On Mon, 2021-12-20 at 14:54 +, Kieran Bingham wrote:
> > Hi Antonio,
> >
> > Quoting Antonio Borneo (2021-12-18 18:28:04)
> > > Commit 680532c50bca ("drm: adv7511: Add support for
> > > i2c_new_secondary_device") allows a device tree node to
On 17/12/2021 14:52, Thomas Hellström wrote:
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
On 17/12/2021 14:52, Thomas Hellström wrote:
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
On 17/12/2021 14:52, Thomas Hellström wrote:
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and
On Mon, Dec 20, 2021 at 07:12:03PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 18:27, Thierry Reding пишет:
> > On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> >> 20.12.2021 13:48, Thierry Reding пишет:
> >>> From: Thierry Reding
> >>>
> >>> Hi,
> >>>
> >>> this is an
On Tuesday, December 21st, 2021 at 11:48, Dmitry Baryshkov
wrote:
> I think the fix should be applied to the generic code.
Related:
https://lore.kernel.org/dri-devel/t1g_xNE6hgj1nTQfx2UWob1wbsCAxElBvWRwNSY_EzmlEe_9WWpq8-vQKyJPK6wZY8q8BqHl-KoGwS5V91VgN8lGIl3PJt7s2fkdsRd3y70=@emersion.fr/T/#u
On Tue, 21 Dec 2021 at 13:13, José Expósito wrote:
>
> Hi all,
>
> When setting IN_FORMATS, implementing the
> "drm_plane_funcs.format_mod_supported" function is mandatory to avoid
> exposing a bogus blob.
>
> This patchset adds a bit of documentation and fixes the issue in a
> couple of drivers
On Tue, 21 Dec 2021 at 13:13, José Expósito wrote:
>
> Adding format modifiers without implementing the function
> "drm_plane_funcs.format_mod_supported" exposes an invalid IN_FORMATS
> blob with modifiers but no formats to user-space.
I think the fix should be applied to the generic code. The
Overall looks good, but it is a bit repetitive to copy & paste this in all
drivers. It'd be nice to provide a core helper to do this, and then drivers
can just set format_mod_supported to the helper if they don't have more
involved logic. Thoughts?
See drm_plane_check_pixel_format, where the
Reviewed-by: Simon Ser
Please ping me in a week or so if nobody objected and this isn't merged.
Am 21.12.21 um 11:11 schrieb Thorsten Leemhuis:
Hi, this is your Linux kernel regression tracker speaking.
CCing Dave and Daniel.
On 15.12.21 23:32, Ben Skeggs wrote:
On Tue, 14 Dec 2021 at 19:19, Christian König
wrote:
Am 11.12.21 um 10:59 schrieb Stefan Fritsch:
On 09.12.21 11:23,
Implement the missing "drm_plane_funcs.format_mod_supported" function
to avoid exposing an invalid IN_FORMATS blob with modifiers but no
formats.
Signed-off-by: José Expósito
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8
1 file changed, 8 insertions(+)
diff --git
Implement the missing "drm_plane_funcs.format_mod_supported" function
to avoid exposing an invalid IN_FORMATS blob with modifiers but no
formats.
Signed-off-by: José Expósito
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 +++
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 +++
2 files
Adding format modifiers without implementing the function
"drm_plane_funcs.format_mod_supported" exposes an invalid IN_FORMATS
blob with modifiers but no formats to user-space.
This breaks the latest Weston [1]. For testing purposes, I extracted the
affected code to a standalone program [2].
Hi all,
When setting IN_FORMATS, implementing the
"drm_plane_funcs.format_mod_supported" function is mandatory to avoid
exposing a bogus blob.
This patchset adds a bit of documentation and fixes the issue in a
couple of drivers affected by the bug.
I reviewed all the other drivers and I didn't
Hi, this is your Linux kernel regression tracker speaking.
CCing Dave and Daniel.
On 15.12.21 23:32, Ben Skeggs wrote:
> On Tue, 14 Dec 2021 at 19:19, Christian König
> wrote:
>>
>> Am 11.12.21 um 10:59 schrieb Stefan Fritsch:
>>> On 09.12.21 11:23, Christian König wrote:
Always waiting
On Thu, Dec 02, 2021 at 02:26:59PM -0800, Stephen Boyd wrote:
> Replace 'struct master' with 'struct aggregate_device' and then rename
> 'master' to 'adev' everywhere in the code. While we're here, put a
> struct device inside the aggregate device so that we can register it
> with a bus_type in
On Thu, Dec 02, 2021 at 02:26:59PM -0800, Stephen Boyd wrote:
> Replace 'struct master' with 'struct aggregate_device' and then rename
> 'master' to 'adev' everywhere in the code. While we're here, put a
> struct device inside the aggregate device so that we can register it
> with a bus_type in
The pointer ptr is being assigned a value that is never read. The
pointer is being re-assigned later in a loop. The assignment is
redundant and can be removed.
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, Dec 20, 2021 at 12:21:47PM -0800, Rajat Jain wrote:
> Hi Dmitry,
>
> Thanks for the review. Please see inline.
>
> On Mon, Dec 20, 2021 at 11:42 AM Dmitry Torokhov
> wrote:
> >
> > Hi Rajat,
> >
> > On Fri, Dec 17, 2021 at 12:28:49PM -0800, Rajat Jain wrote:
> > > This adds the ACPI
1 - 100 of 105 matches
Mail list logo
