On Wed, Mar 08, 2023 at 10:10:24AM +0800, Jiasheng Jiang wrote:
> On Mon, 06 Mar 2023 18:07:13 +0800, Johan Hovold wrote:
> > This reverts commit 643b7d0869cc7f1f7a5ac7ca6bd25d88f54e31d0.
>
> The commit not only adds the allocation sanity check, but also adds the
> destroy_workqueue to release
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
Hello,
this patch series adapts the platform drivers below drivers/video/backlight to
use the .remove_new() callback. Compared to the traditional .remove() callback
.remove_new() returns no value. This is a good thing because the driver core
doesn't (and cannot) cope for errors during remove. The
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Fri, Mar 03, 2023 at 10:33:41PM +0800, Pin-yen Lin wrote:
> From: Prashant Malani
>
> When searching the device graph for device matches, check the
> remote-endpoint itself for a match.
>
> Some drivers register devices for individual endpoints. This allows
> the matcher code to evaluate
This was triggered by the fact that the webpage:
http://www.winischhofer.net/linuxsisvga.shtml
cannot be reached anymore.
Thomas Winischhofer is still reachable at the given email address, but he
has not been active since 2005.
Mark the SIS FRAMEBUFFER DRIVER as orphan to reflect the current
The recent fix for the deferred I/O by the commit
3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O
devices")
caused a regression when the same fb device is opened/closed while
it's being used. It resulted in a frozen screen even if something
is redrawn there after the
Am 08.03.23 um 03:26 schrieb Steven Rostedt:
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
Looks like there was a lock possibly used after free. But as commit
9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
workers") changed a lot of this code, I figured it
On 3/7/2023 9:33 PM, Ashutosh Dixit wrote:
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
For the requested_freq, we read it only if actual_freq is zero below
(meaning, GT is in C6). So then what is
According to commit 890cc39a8799 ("drivers: provide
devm_platform_get_and_ioremap_resource()"), convert
platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yang Li
---
On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from
>
> Would it be more accurate to say 'SLPC does not use rps->cur_freq' rather
> than it not using struct
On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > On newer generations, the GEN12_RPSTAT1 register contains more than freq
> > information, e.g. see GEN12_VOLTAGE_MASK. Therefore use only the freq bits
> > to decide whether to
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generations (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU
Expose intel_rps_get_requested_frequency_fw to read the requested freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support both host
turbo
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generation (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU
Expose intel_rps_read_actual_frequency_fw to read the actual/granted freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support MTL as well
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
> VMWGFX is the only remaining user of this and should probably moved over
> to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks buffer-id relocations on top of ttm
validations or
did you just find it too hard
Add a driver for panels using the Novatek NT36523 display driver IC.
Signed-off-by: Jianhua Lu
---
Changes in v3:
- Refactor source code
Changes in v2:
- Refactor and clean up source code
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig
Novatek NT36523 is a display driver IC used to drive DSI panels.
Signed-off-by: Jianhua Lu
Reviewed-by: Krzysztof Kozlowski
---
Changes in v3:
- pick up Krzysztof's R-b
Changes in v2:
- Drop unnecessary description
- dsi0 -> dsi
- Correct indentation
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
> Looks like there was a lock possibly used after free. But as commit
> 9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
> workers") changed a lot of this code, I figured it may be the culprit.
If I bothered to look
In a report for a regression in my code, I tried to run v6.3-rc1 through my
tests. It crashed at boot up on my first test (my start up tests do take a
long time, hence the 206 seconds of boot!).
[ 206.238782] [ cut here ]
[ 206.277786] DEBUG_LOCKS_WARN_ON(lock->magic
On Mon, 06 Mar 2023 18:07:13 +0800, Johan Hovold wrote:
> This reverts commit 643b7d0869cc7f1f7a5ac7ca6bd25d88f54e31d0.
The commit not only adds the allocation sanity check, but also adds the
destroy_workqueue to release the allocated priv->wq.
Therefore, revert the commit will cause memory leak.
On Tue, Mar 07, 2023 at 11:34:55PM +0100, Linus Walleij wrote:
> Hi Jianhua,
>
> thanks for your patch!
>
> It appears Konrad is working on a very similar driver, so I suggest merging
> them into one Novatek NT36523 driver.
>
> Possibly we can fix this up first and then add Konrads Lenovo-panel
On Tue, Mar 07, 2023 at 11:34:55PM +0100, Linus Walleij wrote:
> Hi Jianhua,
>
> thanks for your patch!
>
> It appears Konrad is working on a very similar driver, so I suggest merging
> them into one Novatek NT36523 driver.
>
> Possibly we can fix this up first and then add Konrads Lenovo-panel
On Sat, 25 Feb 2023 17:02:51 +0100, Krzysztof Kozlowski wrote:
> Convert the Toshiba TC358764 bridge bindings to DT schema.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../display/bridge/toshiba,tc358764.txt | 35
> .../display/bridge/toshiba,tc358764.yaml | 89
On Tue, Mar 07, 2023 at 11:22:35PM +0100, Linus Walleij wrote:
> On Mon, Feb 20, 2023 at 1:13 PM Jianhua Lu wrote:
>
> > Novatek NT36523 is a display driver IC used to drive DSI panels.
> >
> > Signed-off-by: Jianhua Lu
> > ---
> > Changes in v2:
> > - Drop unnecessary description
> > -
On Tue, 21 Feb 2023 18:09:55 +0100, Krzysztof Kozlowski wrote:
> Convert the Parade PS8622/PS8625 DisplayPort to LVDS Converter bindings
> to DT schema. Changes during conversion: add missing vdd12-supply, used
> by Linux driver.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
>
Set *q to NULL on errors, otherwise pqm_create_queue would free it
again.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
On 3/7/23 15:53, David Tadokoro wrote:
The fields blends_with_above and blends_with_below of struct
dc_plane_cap (defined in dc/dc.h) are boolean and set to true by
default. All instances of a dc_plane_cap maintain the default values of
both. Also, there is only one if statement that checks
On Thu, Jan 19, 2023 at 5:32 PM Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
> Compact smartphones.
>
> Signed-off-by: Konrad Dybcio
> Signed-off-by: Konrad Dybcio
> Reviewed-by: Krzysztof Kozlowski
Patch applied to
On Thu, Jan 19, 2023 at 5:32 PM Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
> of smartphone manufacturing, it is impossible to retrieve a better name
>
On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> If we unload the driver and wedge before the GSC worker is complete,
> the worker will hit an error on its submission to the GSC engine and
> then exit. This is hard to hit for a user, but it is reproducible
> with skipping
On Wed, 2023-03-01 at 18:25 +0100, Jakob Koschel wrote:
> + }
> }
>
> + BUG_ON(!pstate);
> nvkm_debug(subdev, "setting performance state %d\n", pstatei);
> clk->pstate = pstatei;
We should probably also replace this with
if (WARN_ON(!pstate)
On Wed, 2023-03-01 at 18:25 +0100, Jakob Koschel wrote:
> If potentially no valid element is found, 'pstate' would contain an
> invalid pointer past the iterator loop. To ensure 'pstate' is always
> valid, we only set it if the correct element was found. That allows
> adding a BUG_ON in case the
Actually hm, dim is warning me about this and making me realize there's
probably a better way to handle this, going to revoke the previous r-b I gave
and respond inline
On Tue, 2023-03-07 at 17:43 -0500, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> Will push upstream in just a moment
>
> On
* Danilo Krummrich [230306 10:46]:
> On 3/2/23 03:38, Liam R. Howlett wrote:
> > * Danilo Krummrich [230227 08:17]:
> >
> > ...
> > > > > Would this variant be significantly more efficient?
> > > >
> > > > Well, what you are doing is walking the tree to see if there's anything
> > > > there...
Reviewed-by: Lyude Paul
Will push upstream in just a moment
On Wed, 2023-03-01 at 18:25 +0100, Jakob Koschel wrote:
> This patch set includes two instances where the list iterator variable
> 'pstate' is implicitly assumed to be valid after the iterator loop.
> While in pratice that is most
Hi Jianhua,
thanks for your patch!
It appears Konrad is working on a very similar driver, so I suggest merging
them into one Novatek NT36523 driver.
Possibly we can fix this up first and then add Konrads Lenovo-panel with
a patch on top.
On Mon, Feb 20, 2023 at 1:13 PM Jianhua Lu wrote:
>
On Mon, Feb 20, 2023 at 1:13 PM Jianhua Lu wrote:
> Novatek NT36523 is a display driver IC used to drive DSI panels.
>
> Signed-off-by: Jianhua Lu
> ---
> Changes in v2:
> - Drop unnecessary description
> - dsi0 -> dsi
> - Correct indentation
I'd like Konrad and Neil to look at this
Hi Sascha,
Am Donnerstag, 16. Februar 2023, 11:24:44 CET schrieb Sascha Hauer:
> The different VOP variants support different maximum resolutions. Reject
> resolutions that are not supported by a specific variant.
>
> This hasn't been a problem in the upstream driver so far as 1920x1080
> has
On Tue, Mar 7, 2023 at 2:26 PM Konrad Dybcio wrote:
> Introduce support for the BOE panel with a NT36523W touch/driver IC
> found on some Lenovo Tab P11 devices. It's a 2000x1200, 24bit RGB
> MIPI DSI panel with integrated DCS-controlled backlight (that expects
> big-endian communication).
>
>
On Tue, Mar 7, 2023 at 2:26 PM Konrad Dybcio wrote:
> Add bindings for the 2000x1200px IPS panel found on Lenovo Tab P11/
> XiaoXin Pad devices.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Konrad Dybcio
(...)
> +$id:
>
Hi Dave and Daniel,
Here goes our first pull request towards 6.3.
drm-intel-next-2023-03-07:
Cross-subsystem Changes:
- MEI patches to fix suspend/resume issues with the i915's PXP. (Alexander)
Driver Changes:
- Registers helpers and clean-ups. (Lucas)
- PXP fixes and clean-ups. (Alan,
Javier Martinez Canillas writes:
[...]
>
>> +static size_t conversion_buf_size_mono(unsigned int dst_pitch, const struct
>> drm_rect *clip)
>> +{
>> +if (!dst_pitch) {
>> +unsigned int linepixels = drm_rect_width(clip) * 1;
>> +
>> +dst_pitch =
There are DRM fourcc formats that have pixels smaller than a byte, but the
conversion_buf_size() function assumes that pixels are a multiple of bytes
and use the struct drm_format_info .cpp field to calculate the dst_pitch.
Instead, calculate it by using the bits per pixel (bpp) and divide it by
On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> The GSC FW load is a slow process (up to 250 ms), so we defer it to a
> dedicated worker to avoid stalling the init flow for that long. However,
> we currently start this worker before the HW init is complete, so there
> is a
Hi Javier,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.3-rc1 next-20230307]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Bjorn Helgaas
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration, so the
driver doesn't need to do it itself.
Remove the
From: Bjorn Helgaas
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration, so the
driver doesn't need to do it itself.
Remove the
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-ttm-Fix-a-NULL-pointer-dereference/20230307-224931
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc
Hello Arthur,
Thanks a lot for your patch!
Arthur Grillo writes:
> Extend the existing test cases to test the conversion from XRGB to
> monochromatic.
>
> Signed-off-by: Arthur Grillo
> ---
[...]
> +static size_t conversion_buf_size_mono(unsigned int dst_pitch, const struct
>
There are DRM fourcc formats that have pixels smaller than a byte, but the
conversion_buf_size() function assumes that pixels are a multiple of bytes
and use the struct drm_format_info .cpp field to calculate the dst_pitch.
Instead, calculate it by using the bits per pixel (bpp) and char per
On Tue, Mar 7, 2023 at 10:48 AM Fabio Estevam wrote:
>
> On Tue, Mar 7, 2023 at 2:46 PM Randy Dunlap wrote:
> >
> > Since DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, the latter
> > should either be selected or DRM_MSM should depend on PM_DEVFREQ.
> > Since most drivers select PM_DEVFREQ
On Tue, Mar 7, 2023 at 2:46 PM Randy Dunlap wrote:
>
> Since DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, the latter
> should either be selected or DRM_MSM should depend on PM_DEVFREQ.
> Since most drivers select PM_DEVFREQ instead of depending on it,
> add a select here to satisfy kconfig.
k.ozlabs.org/project/devicetree-bindings/patch/20230307-topic-dsi_qcm-v3-1-8bd7e1add...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make su
On 3/7/23 21:25, Dmitry Osipenko wrote:
>> Not really a problem with this patchset, but having such branches looks
>> like a bug in the driver's GEM design. Whatever your GEM object needs or
>> does, it should be hidden in the implementation. Why is virtio doing this?
> There is another "VRAM"
On 12/02/2023 01:12, Dmitry Baryshkov wrote:
After fixing scaler version we are sure that sm8450 and sc8280xp vig
sblk's are duplicates of sm8250_vig_sblk and thus can be dropped.
I will probably partially withdraw or rework this patch to fix the
scaler->version handling. The rest of the
On 3/7/23 13:42, Thomas Zimmermann wrote:
> Hi
>
> Am 05.03.23 um 23:10 schrieb Dmitry Osipenko:
> [...]
>> *bo_ptr = bo;
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> index 4c09e313bebc..3f21512ff153 100644
>> ---
Hi Dmitry
On 3/7/2023 10:02 AM, Dmitry Baryshkov wrote:
On 12/02/2023 01:12, Dmitry Baryshkov wrote:
This huge series attempts to restructure the DPU HW catalog into a
manageable and reviewable data set. In order to ease review and testing
I merged all the necessary fixes into this series.
On 12/02/2023 01:12, Dmitry Baryshkov wrote:
This huge series attempts to restructure the DPU HW catalog into a
manageable and reviewable data set. In order to ease review and testing
I merged all the necessary fixes into this series. Also I cherry-picked
& slightly fixed Konrad's patch adding
On 3/7/23 17:55, Christian König wrote:
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock,
Since DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, the latter
should either be selected or DRM_MSM should depend on PM_DEVFREQ.
Since most drivers select PM_DEVFREQ instead of depending on it,
add a select here to satisfy kconfig.
WARNING: unmet direct dependencies detected for
Applied. Thanks.
Alex
On Mon, Mar 6, 2023 at 11:17 AM Felix Kuehling wrote:
>
> Looks like this patch got lost over the holidays. Alex, are you OK with
> applying this patch? Or are people looking for a more general solution
> to not build HW drivers for UML? FWIW:
>
> Acked-by: Felix Kuehling
From: Thomas Zimmermann
[ Upstream commit b1def7fadfa544bd2467581ce40b659583eb7e79 ]
Ast hardware scans out the primary plane from video memory, which
is in I/O-memory space. Hence init the damage handler's iosys_map
pointer as I/O memory.
Not all platforms support accessing I/O memory as
From: Kees Cook
[ Upstream commit 4076ea2419cf15bc1e1580f8b24ddf675fbdb02c ]
Both Coverity and GCC with -Wstringop-overflow noticed that
nvif_outp_acquire_dp() accidentally defined its second argument with 1
additional element:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
Hi Maarten
On Tue, 7 Mar 2023 at 16:25, AL13N wrote:
>
> AL13N schreef op 2023-03-06 17:34:
> > Hi,
> >
> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> > plymouth), the cause of no X is that EDID gives
Applied. Thanks!
On Sun, Mar 5, 2023 at 5:22 PM Husain Alshehhi wrote:
>
> Replace "isntance" with "instance".
>
> Signed-off-by: Husain Alshehhi
> ---
> .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h| 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git
On Mon, Mar 6, 2023 at 3:23 AM David Tadokoro wrote:
>
> From: David Tadokoro
>
> The amdgpu_dm_plane.h functions didn't have names that indicated where
> they were declared.
>
> To better filter results in debug tools like ftrace, prefix these
> functions with 'amdgpu_dm_plane_'.
>
> Note that
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the
fb_set_var would by called when user invokes ioctl with cmd
FBIOPUT_VSCREENINFO. User-provided data would finally reach
tgafb_check_var. In case var->pixclock is assigned to zero,
divide by zero would occur when checking whether reciprocal
of var->pixclock is too high.
Similar crashes have
Hello there,
I just ran the static analyser "cppcheck" over the source code of
linux-6.2-rc1. It said:
linux-6.3-rc1/drivers/gpu/drm/bridge/fsl-ldb.c:101:3: style: int result is
returned as long value. If the return value is long to avoid loss of
information, then you have loss of
Because H3 ES1 becomes an increasing maintenance burden and was only available
to a development group, we decided to remove upstream support for it. Here are
the patches to remove driver changes. Review tags have been gathered before
during an internal discussion. Only change since the internal
R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
and disable booting for this SoC. Public users only have ES2 onwards.
Signed-off-by:
AL13N schreef op 2023-03-06 17:34:
Hi,
I have a RPI4B connected on 2nd HDMI port (furthest away from power)
to a 4K TV, which works until 5.16, from 5.17 there is no X (or
plymouth), the cause of no X is that EDID gives nothing, and in the
journal; there is "Cannot find any crct or sizes". Only
st makes error cleanup easy!), UAPI-level fuzzing, countless broken
> Mesa builds, uptimes of 40+ days, and more.
>
> The explicit sync refactor significantly increases performance (and
> potential problems), but this version has survived a lot of torture
> with dEQP/piglit tests and
On 3/6/2023 9:35 PM, Bagas Sanjaya wrote:
Commit 2c204f3d53218d ("accel: add dedicated minor for accelerator
devices") adds link to accelerator nodes section of DRM internals doc
(Documentation/gpu/drm-internals.rst), but the target doesn't exist.
Instead, there is only an introduction doc for
On 3/7/23 11:25, Asahi Lina wrote:
DRM drivers need to be able to declare which driver-specific ioctls they
support. This abstraction adds the required types and a helper macro to
generate the ioctl definition inside the DRM driver.
Note that this macro is not usable until further bits of the
On Mon, 06 Mar 2023 11:32:42 +0100, Johan Hovold wrote:
> Make sure to unbind all subcomponents when binding the aggregate device
> fails.
>
>
Applied to drm/drm-misc (drm-misc-fixes).
Thanks!
Maxime
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v4: Drop unnecessary '&' from kerneldoc (emersion)
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
On Tue, Mar 7, 2023 at 3:28 PM Asahi Lina wrote:
>
> Adds the Asahi GPU driver UAPI. Note: this API is not yet stable and
> therefore not ready for merging!
>
> Signed-off-by: Asahi Lina
> ---
> include/uapi/drm/asahi_drm.h | 556
> +++
> 1 file changed,
On Tuesday, March 7th, 2023 at 16:10, Harry Wentland
wrote:
> * This enum is used to indicate DP VSC SDP Colorimetry formats.
> * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
> - * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
> + * DB18]
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc:
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc:
We use this by default but if userspace passes this explicitly
we should respect it.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-By: Joshua
From: Joshua Ashton
Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc:
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
We an use bitfields to track the support ones for HDMI
and DP. This allows us to print colorspaces in a consistent
manner without needing to know whether we're dealing with
DP or HDMI.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma
1 - 100 of 231 matches
Mail list logo
