On Thu, Nov 9, 2023 at 11:02 PM Uwe Kleine-König
wrote:
> 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 ignored (apart
> from emitting a
Hi Uwe,
On Thu, Nov 9, 2023 at 11:02 PM Uwe Kleine-König
wrote:
> As described in the added code comment, a reference to .exit.text is ok
> for drivers registered via module_platform_driver_probe(). Make this
> explicit to prevent a section mismatch warning.
>
> Signed-off-by: Uwe Kleine-König
On 09/11/2023 19:05, Alim Akhtar wrote:
(...)
Please trim unrelated parts of response/quote before and after your message.
>> @@ -25,7 +25,15 @@ properties:
>>- samsung,exynos5250-hsi2c# Exynos5250 and Exynos5420
>>- samsung,exynos5260-hsi2c# Exynos5260
>>
On Mon, 6 Nov 2023 10:59:38 +0100
Janusz Krzysztofik wrote:
> Up to now we've been loading a KUnit test module in background and parsing
> in parallel its KTAP output with results from all the module's test cases.
> However, recent KUnit implementation is capable of executing only those
> test
On 09/11/2023 19:04, Conor Dooley wrote:
On Thu, Nov 09, 2023 at 10:00:05AM +0100, Neil Armstrong wrote:
Now this bindings is referred from amlogic,meson-gx-hhi-sysctrl.yaml and is
documented as a subnode of a simple-mfd, drop the invalid reg property.
I'd expect a note here tbh about how
On 09/11/2023 18:34, Conor Dooley wrote:
On Thu, Nov 09, 2023 at 10:00:03AM +0100, Neil Armstrong wrote:
Add a thirst example covering the meson-axg-hhi-sysctrl variant and more
What on earth is a thirst example? Some sort of "hysterical raisins"
type of thing?
My confusion about that word
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_util.c:118
dml_floor() warn: if statement not indented.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7224
Signed-off-by: Jiapeng Chong
---
On 2023/11/10 10:59, Mina Almasry wrote:
> On Thu, Nov 9, 2023 at 12:30 AM Paolo Abeni wrote:
>>
>> I'm trying to wrap my head around the whole infra... the above line is
>> confusing. Why do you increment dma_addr? it will be re-initialized in
>> the next iteration.
>>
>
> That is just a
Modify RESOURCE_GET_LAYOUT ioctl to handle the use case that query
correct stride for guest linear resource before it is created.
Signed-off-by: Julia Zhang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 26 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 47 --
From: Daniel Stone
This ioctl allows the guest to discover how the guest actually allocated
the underlying buffer, which allows buffers to be used for GL<->Vulkan
interop and through standard window systems. It's also a step towards
properly supporting modifiers in the guest.
---
This is to add a new ioctl RESOURCE_GET_LAYOUT to virtio-gpu to get the
information about how the host has actually allocated the buffer. It is
implemented to query the stride of linear buffer for dGPU prime on guest VM,
related mesa mr:
On 11/9/23 23:01, Uwe Kleine-König wrote:
in the series
https://lore.kernel.org/20231107091740.3924258-1-u.kleine-koe...@pengutronix.de
I suggested to replace module_platform_driver_probe() in the amifb
driver. Geert Uytterhoeven objected because the amiga platform has very
little RAM. This
Hi Owen,
On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler wrote:
>
> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
Thanks for the bug
Some functions are never used by the driver,
removing the functions declaration, it can be reducing program size,
and improving code readability and maintainability.
Signed-off-by: heminhong
---
drivers/gpu/drm/qxl/qxl_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
On 11/7/2023 5:35 AM, Jacek Lawrynowicz wrote:
From: Stanislaw Gruszka
Change to use work for timeout detection. Needed for thread_irq
conversion.
Signed-off-by: Stanislaw Gruszka
Missing SOB.
void ivpu_pm_cancel_recovery(struct ivpu_device *vdev)
{
+ drm_WARN_ON(>drm,
On 11/7/2023 5:35 AM, Jacek Lawrynowicz wrote:
From: Stanislaw Gruszka
This allow to simplify ivpu_ipc_receive() as now we do not have
to process all messages in aborted state - they will be freed in
ivpu_ipc_consumer_del().
Signed-off-by: Stanislaw Gruszka
Missing SOB.
-Jeff
On Thu, Nov 9, 2023 at 1:15 AM Paolo Abeni wrote:
>
> On Sun, 2023-11-05 at 18:44 -0800, Mina Almasry wrote:
> [...]
> > @@ -3421,7 +3446,7 @@ static inline struct page *skb_frag_page(const
> > skb_frag_t *frag)
> > */
> > static inline void __skb_frag_ref(skb_frag_t *frag)
> > {
> > -
On 11/7/2023 5:35 AM, Jacek Lawrynowicz wrote:
From: Stanislaw Gruszka
ivpu_ipc_dispatch is always called with irqs disabled. Add lockdep
assertion and remove unneeded _irqsave/_irqrestore.
Signed-off-by: Stanislaw Gruszka
Missing SOB.
-Jeff
On 11/7/2023 5:35 AM, Jacek Lawrynowicz wrote:
From: Stanislaw Gruszka
Now the cons->rx_msg_lock protects also 'abort' field so rename the lock.
Signed-off-by: Stanislaw Gruszka
Jacek, this is missing your SOB.
-Jeff
On Thu, Nov 9, 2023 at 12:30 AM Paolo Abeni wrote:
>
> I'm trying to wrap my head around the whole infra... the above line is
> confusing. Why do you increment dma_addr? it will be re-initialized in
> the next iteration.
>
That is just a mistake, sorry. Will remove this increment.
On Thu, Nov
On 11/9/2023 12:33, Daniele Ceraolo Spurio wrote:
On 11/6/2023 3:59 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a mechanism for reporting errors from fire and forget H2G
messages. This is the only way to find out about almost any error in
the GuC backend submission path.
For the "starry, 2081101qfh032011-53g" panel, it is stipulated in the
panel spec that MIPI needs to keep the LP11 state before the
lcm_reset pin is pulled high.
Fixes: 6069b66cd962 ("drm/panel: support for STARRY 2081101QFH032011-53G
MIPI-DSI panel")
Signed-off-by: xiazhengqiao
Reviewed-by:
On 2023-11-09 19:57, Luben Tuikov wrote:
> On 2023-11-09 19:16, Danilo Krummrich wrote:
[snip]
>> @@ -667,6 +771,8 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs);
>> * drm_sched_job_init - init a scheduler job
>> * @job: scheduler job to init
>> * @entity: scheduler entity to use
>> + * @credits:
On 11/9/2023 12:35 PM, Ville Syrjälä wrote:
On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote:
On 11/9/2023 11:30 AM, Ville Syrjälä wrote:
On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
We read RENDER_HEAD as a part of the flush. If GT is in
deeper sleep
On 11/10/23 01:27, Luben Tuikov wrote:
Define pr_fmt() as "[drm] " for DRM code using pr_*() facilities, especially
when no devices are available. This makes it easier to browse kernel logs.
Signed-off-by: Luben Tuikov
---
include/drm/drm_print.h | 14 ++
1 file changed, 14
On 2023-11-09 19:16, Danilo Krummrich wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a credit
> limit that corresponds to the number of jobs which can be sent to the
> hardware.
>
> This implies
From: John Harrison
If a context is blocked, unblocked and subitted repeatedly in rapid
succession, the driver can end up trying to enable the context while
the previous enable request is still in flight. This can lead to much
confusion in the state tracking.
Prevent that by checking the
From: John Harrison
The driver could sometimes send context enable/disable requests when a
previous request was still pending. This is not allowed. So stop doing
it.
Signed-off-by: John Harrison
John Harrison (2):
drm/i915/guc: Don't double enable a context
drm/i915/guc: Don't disable a
From: John Harrison
Various processes involve requesting GuC to disable a given context.
However context enable/disable is an asynchronous process in the GuC.
Thus, it is possible the previous enable request is still being
processed when the disable request is triggered. Having both enable
and
+LKML
On 11/9/23 7:47 AM, Jocelyn Falempe wrote:
On 09/11/2023 01:37, Kim Phillips wrote:
Hi, current linux kernel commit 90450a06162e
("Merge tag 'rcu-fixes-v6.7' of
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks")
and the attached config cause the following BUG when
Define pr_fmt() as "[drm] " for DRM code using pr_*() facilities, especially
when no devices are available. This makes it easier to browse kernel logs.
Signed-off-by: Luben Tuikov
---
include/drm/drm_print.h | 14 ++
1 file changed, 14 insertions(+)
diff --git
Hi,
On Wed, Nov 8, 2023 at 9:04 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Nov 8, 2023 at 7:45 AM Maxime Ripard wrote:
> >
> > > @@ -575,9 +599,18 @@ static int panel_edp_get_modes(struct drm_panel
> > > *panel,
> > >
> > > if (!p->edid)
> > > p->edid =
Hi,
On Tue, Nov 7, 2023 at 12:46 PM Hsin-Yi Wang wrote:
>
> Add a few generic edp panels used by mt8186 chromebooks.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
> ---
> no change.
> ---
> drivers/gpu/drm/panel/panel-edp.c | 51 +++
> 1 file
Hi,
On Tue, Nov 7, 2023 at 12:46 PM Hsin-Yi Wang wrote:
>
> Rename AUO 0x235c B116XTN02 to B116XTN02.3 according to decoding edid.
>
> Fixes: 3db2420422a5 ("drm/panel-edp: Add AUO B116XTN02, BOE
> NT116WHM-N21,836X2, NV116WHM-N49 V8.0")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hsin-Yi Wang
Hi,
On Tue, Nov 7, 2023 at 12:46 PM Hsin-Yi Wang wrote:
>
> Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of
> auo_b116xak01: T3=200, T12=500, T7_max = 50 according to decoding edid
> and datasheet.
>
> Fixes: da458286a5e2 ("drm/panel: Add support for AUO B116XAK01 panel")
>
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sent to the
hardware.
This implies that for each job, drivers need to account for the maximum
On 11/10/23 01:01, Luben Tuikov wrote:
Don't "wake up" the GPU scheduler unless the entity is ready, as well as we
can queue to the scheduler, i.e. there is no point in waking up the scheduler
for the entity unless the entity is ready.
Signed-off-by: Luben Tuikov
Fixes: bc8d6a9df99038
Use the same value as the downstream driver. This change is needed for CPHY
mode to work correctly.
Fixes: 8b034e6771113 ("drm/msm/dsi: add support for DSI-PHY on SM8550")
Signed-off-by: Jonathan Marek
---
v2: fixed the Fixes: line
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 2 +-
1 file
Don't "wake up" the GPU scheduler unless the entity is ready, as well as we
can queue to the scheduler, i.e. there is no point in waking up the scheduler
for the entity unless the entity is ready.
Signed-off-by: Luben Tuikov
Fixes: bc8d6a9df99038 ("drm/sched: Don't disturb the entity when in
Use the same value as the downstream driver. This change is needed for CPHY
mode to work correctly.
Fixes: 93f0ca6fd61c ("drm/msm/dsi: fix VREG_CTRL_1 value for 4nm cphy")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 2 +-
1 file changed, 1 insertion(+), 1
On 2023-11-09 18:41, Danilo Krummrich wrote:
> On 11/9/23 20:24, Danilo Krummrich wrote:
>> On 11/9/23 07:52, Luben Tuikov wrote:
>>> Hi,
>>>
>>> On 2023-11-07 19:41, Danilo Krummrich wrote:
On 11/7/23 05:10, Luben Tuikov wrote:
> Don't call drm_sched_select_entity() in
On 11/9/23 20:24, Danilo Krummrich wrote:
On 11/9/23 07:52, Luben Tuikov wrote:
Hi,
On 2023-11-07 19:41, Danilo Krummrich wrote:
On 11/7/23 05:10, Luben Tuikov wrote:
Don't call drm_sched_select_entity() in drm_sched_run_job_queue(). In fact,
rename __drm_sched_run_job_queue() to just
On 08/11/23 13:36, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
> - get_lut_index
> - lerp_u16
>
> v3:
> - Use include way of testing static functions (Arthur)
>
> Signed-off-by: Harry Wentland
>
Hello,
in the series
https://lore.kernel.org/20231107091740.3924258-1-u.kleine-koe...@pengutronix.de
I suggested to replace module_platform_driver_probe() in the amifb
driver. Geert Uytterhoeven objected because the amiga platform has very
little RAM. This series implements the alternative: Mark
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 ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
As described in the added code comment, a reference to .exit.text is ok
for drivers registered via module_platform_driver_probe(). Make this
explicit to prevent a section mismatch warning.
Signed-off-by: Uwe Kleine-König
---
drivers/video/fbdev/amifb.c | 8 +++-
1 file changed, 7
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it
From: Chris Morgan
Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
gaming device with a 3.5 inch screen powered by the Rockchip RK3566
SoC. The device is almost identical to the Anbernic RG353P except it
lacks eMMC, a function button, a touch screen, no UART headers on the
From: Chris Morgan
The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and
powered by the Rockchip RK3566 SoC. Group the Powkiddy RK3566 based
devices together as they are both extremely similar.
Signed-off-by: Chris Morgan
---
Documentation/devicetree/bindings/arm/rockchip.yaml
From: Chris Morgan
Add support for the Powkiddy RK2023, which is extremely similar to
existing devices from Anbernic.
Changes since V1:
- Necessary clock changes have been accepted to mainline, so removed
from this series.
From: Chris Morgan
Update the NewVision NV3051D compatible strings by adding a new panel,
the powkiddy,rk2023-panel, and removing another entry, the
anbernic,rg353v-panel. The rg353v-panel is exactly identical to the
rg353p-panel and is not currently in use by any existing device tree.
The
On 2023-11-09 14:55, Danilo Krummrich wrote:
> On 11/9/23 01:09, Danilo Krummrich wrote:
>> On 11/8/23 06:46, Luben Tuikov wrote:
>>> Hi,
>>>
>>> Could you please use my gmail address, the one one I'm responding from--I
>>> don't want
>>> to miss any DRM scheduler patches. BTW, the
Hello Kuogee,
On Thu, 9 Nov 2023 at 19:51, Kuogee Hsieh wrote:
>
>
> On 11/8/2023 10:27 AM, Abhinav Kumar wrote:
> >
> >
> > On 11/8/2023 10:10 AM, Kuogee Hsieh wrote:
> >>
> >> On 11/7/2023 1:23 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 7 Nov 2023 at 23:01, Kuogee Hsieh
> >>> wrote:
>
>
On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote:
>
> On 11/9/2023 11:30 AM, Ville Syrjälä wrote:
> > On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
> >> We read RENDER_HEAD as a part of the flush. If GT is in
> >> deeper sleep states, this could lead to read
On 11/6/2023 3:59 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Noticed that the hangcheck selftest is submitting a non-preemptoble
spinner. That means that even if the GuC does not die, the heartbeat
will still kick in and trigger a reset. Which is rather defeating the
purpose
On 11/6/2023 3:59 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a mechanism for reporting errors from fire and forget H2G
messages. This is the only way to find out about almost any error in
the GuC backend submission path. So it would be useful to know that it
is
On 11/8/23 22:34, Geert Uytterhoeven wrote:
Hi Helge,
On Wed, Nov 8, 2023 at 10:32 PM Helge Deller wrote:
On 11/8/23 22:06, Geert Uytterhoeven wrote:
On Tue, Nov 7, 2023 at 10:20 AM Uwe Kleine-König
wrote:
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any
On Wed, Nov 8, 2023 at 11:44 AM Krzysztof Kozlowski
wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
On 11/9/2023 11:30 AM, Ville Syrjälä wrote:
On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
We read RENDER_HEAD as a part of the flush. If GT is in
deeper sleep states, this could lead to read errors since we are
not using a forcewake. Safer to read a shadowed register
On 11/9/23 01:09, Danilo Krummrich wrote:
On 11/8/23 06:46, Luben Tuikov wrote:
Hi,
Could you please use my gmail address, the one one I'm responding from--I don't
want
to miss any DRM scheduler patches. BTW, the luben.tui...@amd.com email should
bounce
as undeliverable.
On 2023-11-07
On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
> We read RENDER_HEAD as a part of the flush. If GT is in
> deeper sleep states, this could lead to read errors since we are
> not using a forcewake. Safer to read a shadowed register instead.
IIRC shadowing is only thing for
On 11/9/23 07:52, Luben Tuikov wrote:
Hi,
On 2023-11-07 19:41, Danilo Krummrich wrote:
On 11/7/23 05:10, Luben Tuikov wrote:
Don't call drm_sched_select_entity() in drm_sched_run_job_queue(). In fact,
rename __drm_sched_run_job_queue() to just drm_sched_run_job_queue(), and let
it do just
On Wed, Nov 08, 2023 at 11:43:29AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
We read RENDER_HEAD as a part of the flush. If GT is in
deeper sleep states, this could lead to read errors since we are
not using a forcewake. Safer to read a shadowed register instead.
Cc: John Harrison
Cc: Daniele Ceraolo Spurio
Signed-off-by: Vinay Belgaumkar
---
On Wed, Nov 08, 2023 at 11:43:28AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
On Thu, Nov 09, 2023 at 03:42:38PM +, Dave Stevenson wrote:
> Hi Simon and Maxime
>
> On Thu, 9 Nov 2023 at 09:12, Maxime Ripard wrote:
> >
> > Hi Simon,
> >
> > On Thu, Nov 09, 2023 at 07:45:58AM +, Simon Ser wrote:
> > > User-space sometimes needs to allocate scanout-capable memory for
On 11/9/23 05:23, Luben Tuikov wrote:
On 2023-11-08 19:09, Danilo Krummrich wrote:
On 11/8/23 06:46, Luben Tuikov wrote:
Hi,
Could you please use my gmail address, the one one I'm responding from--I don't
want
to miss any DRM scheduler patches. BTW, the luben.tui...@amd.com email should
On Thu, Nov 09, 2023 at 03:31:44PM +, Simon Ser wrote:
> > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > not precise enough. Something with "cma"? Do we need to plan a naming
> > > scheme to accomodate for multiple vc4 devices?
> >
> > That's a general issue
Hi Simon
On Thu, 9 Nov 2023 at 17:46, Simon Ser wrote:
>
> On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
> wrote:
>
> > > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > > not precise enough. Something with "cma"? Do we need to plan a naming
> > >
On 11/9/23 17:03, Christian König wrote:
Am 09.11.23 um 16:50 schrieb Thomas Hellström:
[SNIP]
Did we get any resolution on this?
FWIW, my take on this is that it would be possible to get GPUVM to work both
with and without internal refcounting; If with, the driver needs a vm close to
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Wednesday, November 8, 2023 4:13 PM
> To: David Airlie ; Daniel Vetter ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ;
> Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley
> ; Alim Akhtar ; Andi
> Shyti ; Jonathan
Hi Allen,
On Tue, Oct 17, 2023 at 06:01:39PM +, Allen Ballway wrote:
> Cyernet T10C has a bad default PWM frequency causing the display to
> strobe when the brightness is less than 100%. Create a new quirk to use
> the value from the BIOS rather than the default register value.
>
>
On Thu, Nov 09, 2023 at 10:00:05AM +0100, Neil Armstrong wrote:
> Now this bindings is referred from amlogic,meson-gx-hhi-sysctrl.yaml and is
> documented as a subnode of a simple-mfd, drop the invalid reg property.
I'd expect a note here tbh about how removing reg & relying on being a
subnode of
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Wednesday, November 8, 2023 4:13 PM
> To: David Airlie ; Daniel Vetter ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ;
> Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley
> ; Alim Akhtar ; Andi
> Shyti ; Jonathan
On 11/8/2023 10:27 AM, Abhinav Kumar wrote:
On 11/8/2023 10:10 AM, Kuogee Hsieh wrote:
On 11/7/2023 1:23 PM, Dmitry Baryshkov wrote:
On Tue, 7 Nov 2023 at 23:01, Kuogee Hsieh
wrote:
On 11/6/2023 5:55 PM, Dmitry Baryshkov wrote:
On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh
wrote:
The
On Thu, Nov 09, 2023 at 10:00:04AM +0100, Neil Armstrong wrote:
> Since this bindings is referred from amlogic,meson-gx-hhi-sysctrl.yaml, drop
> the now
> useless description about the parent node and also drop the unnecessary
> example.
>
> Signed-off-by: Neil Armstrong
Acked-by: Conor
On Thursday, November 9th, 2023 at 16:42, Dave Stevenson
wrote:
> > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > not precise enough. Something with "cma"? Do we need to plan a naming
> > > scheme to accomodate for multiple vc4 devices?
> >
> > That's a
On Thu, Nov 09, 2023 at 10:00:03AM +0100, Neil Armstrong wrote:
> Add a thirst example covering the meson-axg-hhi-sysctrl variant and more
What on earth is a thirst example? Some sort of "hysterical raisins"
type of thing?
My confusion about that word aside,
Acked-by: Conor Dooley
Cheers,
Currently, only damage tracking for frame damage is supported. If a driver
needs to do buffer damage (e.g: the framebuffer attached to plane's state
has changed since the last page-flip), the damage helpers just fallback to
a full plane update.
Add en entry in the TODO about implementing buffer
The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.
Add that to the section, mention the different helpers that should be used
by drivers depending on the damage handling type used and refer to sites
To be used by drivers that do per-buffer (e.g: virtio-gpu) uploads (rather
than per-plane uploads), since these type of drivers need to handle buffer
damages instead of frame damages.
The drm_atomic_helper_buffer_damage_iter_init() has the same logic than
drm_atomic_helper_damage_iter_init() but
The driver does per-buffer uploads. It needs to use the damage helper that
handles buffer damages, rather than the helper that handles frame damages.
Suggested-by: Sima Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1
We need a similar drm_atomic_helper_buffer_damage_merged() helper function
that takes into account if a framebuffer attached to the plane has changed
since the last plane update (page-flip).
Since both damage helpers will share most of the current logic, move it to
an internal helper. The
The driver does per-buffer uploads. It needs to use the damage helper that
handles buffer damages, rather than the helper that handles frame damages.
Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the
primary plane")
Cc: # v6.4+
Reported-by: nerdopolis
Closes:
Hello,
This series is to fix an issue that surfaced after damage clipping was
enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
fb damage clips property for the primary plane").
After that change, flickering artifacts was reported to be present with
both weston and wlroots
For "auo,b101uan08.3" this panel, it is stipulated in the panel spec that
MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high.
BUG=b:309908277
TEST=emerge-kukui chromeos-kernel-5_10
Signed-off-by: Xuxin Xiong
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 +
1
For "auo,b101uan08.3" this panel, it is stipulated in the panel spec that
MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high.
BUG=b:309908277
TEST=emerge-kukui chromeos-kernel-5_10
Signed-off-by: Xuxin Xiong
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 +
1
On 09/11/2023 02:39, Mina Almasry wrote:
> On Wed, Nov 8, 2023 at 7:36 AM Edward Cree wrote:
>> If not then surely the way to return a memory area
>> in an io_uring idiom is just to post a new read sqe ('RX descriptor')
>> pointing into it, rather than explicitly returning it with setsockopt.
Am 09.11.23 um 16:50 schrieb Thomas Hellström:
[SNIP]
Did we get any resolution on this?
FWIW, my take on this is that it would be possible to get GPUVM to
work both with and without internal refcounting; If with, the driver
needs a vm close to resolve cyclic references, if without that's
Danilo, Christian
On 11/6/23 17:42, Danilo Krummrich wrote:
On Mon, Nov 06, 2023 at 04:10:50PM +0100, Christian König wrote:
Am 06.11.23 um 15:11 schrieb Danilo Krummrich:
On Mon, Nov 06, 2023 at 02:05:13PM +0100, Christian König wrote:
Am 06.11.23 um 13:16 schrieb Danilo Krummrich:
[SNIP]
Hi Simon and Maxime
On Thu, 9 Nov 2023 at 09:12, Maxime Ripard wrote:
>
> Hi Simon,
>
> On Thu, Nov 09, 2023 at 07:45:58AM +, Simon Ser wrote:
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> > is
On Thursday, November 9th, 2023 at 16:14, T.J. Mercier
wrote:
> > + exp_info.priv = vc4; / TODO: unregister when unloading */
> > +
>
> So unregistering a heap isn't currently possible, but we're trying to
> enable that here:
>
On Thu, Nov 9, 2023 at 7:14 AM José Pekkarinen
wrote:
>
> On 2023-11-09 11:06, Greg KH wrote:
> > On Thu, Nov 09, 2023 at 10:43:50AM +0200, José Pekkarinen wrote:
> >> On 2023-11-08 09:29, Greg KH wrote:
> >> > On Wed, Nov 08, 2023 at 08:54:35AM +0200, José Pekkarinen wrote:
> >> > > The
On Thursday, November 9th, 2023 at 13:14, Maira Canal wrote:
> On 11/9/23 04:45, Simon Ser wrote:
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> > is achieved via DRM dumb buffers: the v3d user-space
On Thu, 02 Nov 2023, Jani Nikula wrote:
> On Tue, 31 Oct 2023, Jani Nikula wrote:
>> v2 of https://patchwork.freedesktop.org/series/123384/
>>
>> Jani Nikula (6):
>> drm/edid: split out drm_eld.h from drm_edid.h
>> drm/eld: replace uint8_t with u8
>> drm/edid: include drm_eld.h only where
Thanks for the feedback Iago! I've replied to Maxime and I believe that
covers your questions as well.
On Thursday, November 9th, 2023 at 10:11, Maxime Ripard
wrote:
> > - Does this approach make sense to y'all in general?
>
> Makes sense to me :)
Great to hear!
> > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > not precise enough. Something with "cma"? Do we
On Wed, Nov 8, 2023 at 11:46 PM Simon Ser wrote:
>
> +int vc4_dma_heap_create(struct vc4_dev *vc4)
> +{
> + struct dma_heap_export_info exp_info;
> + struct dma_heap *heap;
> +
> + exp_info.name = "vc4"; /* TODO: allow multiple? */
> + exp_info.ops = _dma_heap_ops;
> +
From: Luben Tuikov
The GPU scheduler has now a variable number of run-queues, which are set up at
drm_sched_init() time. This way, each driver announces how many run-queues it
requires (supports) per each GPU scheduler it creates. Note, that run-queues
correspond to scheduler "priorities", thus
1 - 100 of 161 matches
Mail list logo
