Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel p
On 2024-08-01, Jocelyn Falempe wrote:
> * I tried to use the new nbcon interface, but didn't get any message
> from the write_atomic() callback, but the goal is to use that when
> it's ready.
Be aware that the write_atomic() callback _must_ also print from NMI
context. write_thread() may be th
drm_log is a simple logger that uses the drm_client API to print the kmsg boot
log on the screen.
This is not a full replacement to fbcon, as it will only print the kmsg.
It will never handle user input, or a terminal because this is better done in
userspace.
If you're curious on how it looks li
By default, each DRM scheduler instance creates an ordered workqueue for
submission, and each workqueue creation allocates a new lockdep map.
This becomes problematic when a DRM scheduler is created for every user
queue (e.g., in DRM drivers with firmware schedulers like Xe) due to the
limited numb
This adds display sharing support in tidss display driver along with an
example overlay devicetree file using which can be used to enable display
sharing on AM62x devices with device manager core i.e. R5F expected to run
a custom firmware which supports corresponding display sharing
configuration.
Extend DPU driver with experimental support for even more MDP5
platforms: MSM8937, MSM8917, MSM8953.
As with other MDP5 devices, one has to pass `msm.prefer_mdp5=false`
kernel param to test DPU driver insead of using MDP5.
Dependencies: [1]
[1] https://patchwork.freedesktop.org/series/123294/
D
On 6/29/2023 12:29 AM, Pekka Paalanen wrote:
On Wed, 28 Jun 2023 09:40:21 -0700
Jessica Zhang wrote:
On 6/28/2023 12:34 AM, Pekka Paalanen wrote:
On Tue, 27 Jun 2023 15:10:19 -0700
Abhinav Kumar wrote:
On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
On 28/06/2023 00:27, Jessica Zhang
On 6/27/2023 3:10 PM, Abhinav Kumar wrote:
On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
On 28/06/2023 00:27, Jessica Zhang wrote:
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri,
On Wed, 28 Jun 2023 09:40:21 -0700
Jessica Zhang wrote:
> On 6/28/2023 12:34 AM, Pekka Paalanen wrote:
> > On Tue, 27 Jun 2023 15:10:19 -0700
> > Abhinav Kumar wrote:
> >
> >> On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
> >>> On 28/06/2023 00:27, Jessica Zhang wrote:
>
>
> >>>
On 6/28/2023 12:34 AM, Pekka Paalanen wrote:
On Tue, 27 Jun 2023 15:10:19 -0700
Abhinav Kumar wrote:
On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
On 28/06/2023 00:27, Jessica Zhang wrote:
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wr
On Tue, 27 Jun 2023 15:10:19 -0700
Abhinav Kumar wrote:
> On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
> > On 28/06/2023 00:27, Jessica Zhang wrote:
> >>
> >>
> >> On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
> >>> On Mon, 26 Jun 2023 16:02:50 -0700
> >>> Jessica Zhang wrote:
> >>>
>
On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:
On 28/06/2023 00:27, Jessica Zhang wrote:
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zha
On 28/06/2023 00:27, Jessica Zhang wrote:
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FIL
On 6/27/2023 12:58 AM, Pekka Paalanen wrote:
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When t
On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang wrote:
> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> >> properties. When the color fill value is set, and the
On Tue, 27 Jun 2023 at 03:45, Jessica Zhang wrote:
>
>
>
> On 6/26/2023 5:06 PM, Dmitry Baryshkov wrote:
> > On 27/06/2023 02:02, Jessica Zhang wrote:
> >>
> >>
> >> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> >>> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> Introduce an
On 6/26/2023 5:06 PM, Dmitry Baryshkov wrote:
On 27/06/2023 02:02, Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill
On 27/06/2023 02:02, Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL,
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL, memory fetch will be disabled.
Thinking
This series introduces KUnit[1] tests for TTM (Translation Table Manager)
subsystem, a memory manager used by graphics drivers to create and manage
memory buffers across different memory domains, such as system memory
or VRAM.
Unit tests implemented here cover two data structures:
- ttm_device -
From: Frieder Schrempf
This patchset contains a proposal to fix the initialization flow for
the display pipeline used on our i.MX8MM Kontron boards:
i.MX8MM LCDIF -> i.MX8MM DSIM -> TI SN65DSI84 -> 7" LVDS Panel
Without these changes the display works most of the time, but fails
to come up oc
On Thu, 30 Mar 2023 at 14:16, Konrad Dybcio wrote:
>
>
>
> On 30.03.2023 13:15, Dmitry Baryshkov wrote:
> > On 30/03/2023 14:06, Konrad Dybcio wrote:
> >>
> >>
> >> On 30.03.2023 00:24, Dmitry Baryshkov wrote:
> >>> Konrad brought up the topic of scaling the MX domain according to the
> >>> OPP ch
On 30.03.2023 13:15, Dmitry Baryshkov wrote:
> On 30/03/2023 14:06, Konrad Dybcio wrote:
>>
>>
>> On 30.03.2023 00:24, Dmitry Baryshkov wrote:
>>> Konrad brought up the topic of scaling the MX domain according to the
>>> OPP changes. Here is my RFC for this functionality. I post it as an RFC
>>>
On 30/03/2023 14:06, Konrad Dybcio wrote:
On 30.03.2023 00:24, Dmitry Baryshkov wrote:
Konrad brought up the topic of scaling the MX domain according to the
OPP changes. Here is my RFC for this functionality. I post it as an RFC
for two reasons:
1) I'm not sure that we should scale MX if we a
On 30.03.2023 00:24, Dmitry Baryshkov wrote:
> Konrad brought up the topic of scaling the MX domain according to the
> OPP changes. Here is my RFC for this functionality. I post it as an RFC
> for two reasons:
>
> 1) I'm not sure that we should scale MX if we are not scaling main
> voltage foll
Konrad brought up the topic of scaling the MX domain according to the
OPP changes. Here is my RFC for this functionality. I post it as an RFC
for two reasons:
1) I'm not sure that we should scale MX if we are not scaling main
voltage following the CPR3
2) With this patchset I'm getting the follow
On 11/8/2022 12:52 AM, Ville Syrjälä wrote:
On Mon, Nov 07, 2022 at 07:34:43PM -0800, Rob Clark wrote:
On Mon, Nov 7, 2022 at 4:22 PM Jessica Zhang wrote:
On 11/7/2022 2:09 PM, Rob Clark wrote:
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä
On Mon, Nov 07, 2022 at 07:34:43PM -0800, Rob Clark wrote:
> On Mon, Nov 7, 2022 at 4:22 PM Jessica Zhang
> wrote:
> >
> >
> >
> > On 11/7/2022 2:09 PM, Rob Clark wrote:
> > > On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 11/7/2022 11:37 AM, Ville Syrj
On Mon, Nov 7, 2022 at 4:22 PM Jessica Zhang wrote:
>
>
>
> On 11/7/2022 2:09 PM, Rob Clark wrote:
> > On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> >>> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >>
On 11/7/2022 2:09 PM, Rob Clark wrote:
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color
On Mon, Nov 07, 2022 at 09:37:08PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> > Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> > properties. When the color fill value is set, and the framebuffer is set
> > to NULL, memory fetch w
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
>
>
>
> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> >> properties. When the color fill value is set, and the
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL, memory fetch will be disabled.
Thinking
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> properties. When the color fill value is set, and the framebuffer is set
> to NULL, memory fetch will be disabled.
Thinking a bit more universally I wonder if there sho
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL, memory fetch will be disabled.
In addition, loosen the NULL FB checks within the atomic commit callstack
to allow a NULL FB when color_fill is nonzero an
On Mon, Oct 24, 2022 at 6:10 PM Alex Deucher wrote:
>
> On Mon, Oct 24, 2022 at 10:41 AM Oded Gabbay wrote:
> >
> > On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote:
> > >
> > > On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote:
> > > >
> > > > In the last couple of months we had a discussion
On Tue, Oct 25, 2022 at 10:34 AM Jason Gunthorpe wrote:
>
> On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote:
>
> > E.g., the kfd node provides platform level compute
> > topology information; e.g., the NUMA details for connected GPUs and
> > CPUs, non-GPU compute node information, cac
On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote:
> E.g., the kfd node provides platform level compute
> topology information; e.g., the NUMA details for connected GPUs and
> CPUs, non-GPU compute node information, cache level topologies, etc.
See, this is exactly what I'm talking abo
On Tue, Oct 25, 2022 at 7:15 AM Jason Gunthorpe wrote:
>
> On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote:
>
> > The userspace for those is normally bespoke like ROCm, which uses
> > amdkfd, and amdkfd doesn't operate like most device files from what I
> > know, so I'm not sure we'd w
On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote:
> The userspace for those is normally bespoke like ROCm, which uses
> amdkfd, and amdkfd doesn't operate like most device files from what I
> know, so I'm not sure we'd want it to operate as an accel device.
I intensely dislike this dir
On Tue, 25 Oct 2022 at 12:21, John Hubbard wrote:
>
> On 10/24/22 05:43, Oded Gabbay wrote:
>
> Hi Oded,
>
> The patches make sense to me. I'm still just reading through and looking
> for minor issues, but at a high level it seems to match what the LPC
> discussions pointed to.
>
> >> What's your
On 10/24/22 05:43, Oded Gabbay wrote:
Hi Oded,
The patches make sense to me. I'm still just reading through and looking
for minor issues, but at a high level it seems to match what the LPC
discussions pointed to.
What's your opinion on the long-term prospect of DRM vs accel? I assume
that over
On Mon, Oct 24, 2022 at 10:41 AM Oded Gabbay wrote:
>
> On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote:
> >
> > On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote:
> > >
> > > In the last couple of months we had a discussion [1] about creating a new
> > > subsystem for compute accelerator dev
On Mon, Oct 24, 2022 at 4:55 PM Alex Deucher wrote:
>
> On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote:
> >
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that was done by DRM
On Sat, Oct 22, 2022 at 5:46 PM Oded Gabbay wrote:
>
> In the last couple of months we had a discussion [1] about creating a new
> subsystem for compute accelerator devices in the kernel.
>
> After an analysis that was done by DRM maintainers and myself, and following
> a BOF session at the Linux
On Mon, Oct 24, 2022 at 01:55:56PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 22.10.22 um 23:46 schrieb Oded Gabbay:
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that was done
On Mon, Oct 24, 2022 at 2:56 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 22.10.22 um 23:46 schrieb Oded Gabbay:
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that was done by DRM ma
Hi
Am 22.10.22 um 23:46 schrieb Oded Gabbay:
In the last couple of months we had a discussion [1] about creating a new
subsystem for compute accelerator devices in the kernel.
After an analysis that was done by DRM maintainers and myself, and following
a BOF session at the Linux Plumbers confer
On Sun, Oct 23, 2022 at 09:02:49PM +0700, Bagas Sanjaya wrote:
> On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote:
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that wa
On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote:
> In the last couple of months we had a discussion [1] about creating a new
> subsystem for compute accelerator devices in the kernel.
>
> After an analysis that was done by DRM maintainers and myself, and following
> a BOF session at th
In the last couple of months we had a discussion [1] about creating a new
subsystem for compute accelerator devices in the kernel.
After an analysis that was done by DRM maintainers and myself, and following
a BOF session at the Linux Plumbers conference a few weeks ago [2], we
decided to create a
On Thu, Sep 01, 2022 at 12:15:24PM +0300, Dmitry Baryshkov wrote:
> Johan Hovold has reported that returning a probe deferral from the
> msm_dp_modeset_init() can cause issues because the IRQ is not freed
> properly. This (compile-tested only) series tries to fix the issue by
> moving devm_request_
On 08/09/2022 20:05, Dmitry Baryshkov wrote:
>
> On 30/08/2022 06:33, Abhinav Kumar wrote:
>> As reported on https://gitlab.freedesktop.org/drm/msm/-/issues/17, currently
>> there is no mechanism to limit the display output to the pluggable displays
>> and it lets users connect any monitor on any
On 30/08/2022 06:33, Abhinav Kumar wrote:
As reported on https://gitlab.freedesktop.org/drm/msm/-/issues/17, currently
there is no mechanism to limit the display output to the pluggable displays
and it lets users connect any monitor on any chipset based device.
This can lead to undefined behav
On Thu, Sep 01, 2022 at 12:15:24PM +0300, Dmitry Baryshkov wrote:
> Johan Hovold has reported that returning a probe deferral from the
> msm_dp_modeset_init() can cause issues because the IRQ is not freed
> properly. This (compile-tested only) series tries to fix the issue by
> moving devm_request_
On Thu, Sep 01, 2022 at 12:21:36PM +0300, Dmitry Baryshkov wrote:
> On 01/09/2022 12:20, Johan Hovold wrote:
> > On Thu, Sep 01, 2022 at 12:15:24PM +0300, Dmitry Baryshkov wrote:
> >> Johan Hovold has reported that returning a probe deferral from the
> >> msm_dp_modeset_init() can cause issues beca
On 01/09/2022 12:20, Johan Hovold wrote:
On Thu, Sep 01, 2022 at 12:15:24PM +0300, Dmitry Baryshkov wrote:
Johan Hovold has reported that returning a probe deferral from the
msm_dp_modeset_init() can cause issues because the IRQ is not freed
properly. This (compile-tested only) series tries to f
On Thu, Sep 01, 2022 at 12:15:24PM +0300, Dmitry Baryshkov wrote:
> Johan Hovold has reported that returning a probe deferral from the
> msm_dp_modeset_init() can cause issues because the IRQ is not freed
> properly. This (compile-tested only) series tries to fix the issue by
> moving devm_request_
Johan Hovold has reported that returning a probe deferral from the
msm_dp_modeset_init() can cause issues because the IRQ is not freed
properly. This (compile-tested only) series tries to fix the issue by
moving devm_request_irq() to the probe callback.
Dmitry Baryshkov (3):
drm/msm/dp: fold dis
As reported on https://gitlab.freedesktop.org/drm/msm/-/issues/17, currently
there is no mechanism to limit the display output to the pluggable displays
and it lets users connect any monitor on any chipset based device.
This can lead to undefined behavior because lets say the display
advertises an
An RFC (or rather RFT, Request-for-Testing) series adding support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR. Note, it was compile-tested only. This
bridge is the last one used on the Qualcomm platforms (in
upstream-supported devices) and thus it is the only bridge that prevents
us from removing support f
Hi Suraj,
On Thu, Apr 28, 2022 at 05:51:47AM +, Kandpal, Suraj wrote:
> ++Laurent ,Dmitry, and Abhinav
>
> Hi,
> Can you have a look at the private implementation i915 is currently going
> with till
> we can figure out how to work with drm core .
No, sorry, I barely have time to follow up
++Laurent ,Dmitry, and Abhinav
Hi,
Can you have a look at the private implementation i915 is currently going with
till
we can figure out how to work with drm core .
Regards,
Suraj Kandpal
> A patch series was floated in the drm mailing list which aimed to change the
> drm_connector and drm_enco
A patch series was floated in the drm mailing list which aimed to change
the drm_connector and drm_encoder fields to pointer in the
drm_connector_writeback structure, this received a huge pushback from
the community but since i915 expects each connector present in the
drm_device list to be a intel_
The suballocation manager itself is not dependent on any implementation detail,
and can be made generic. I want to potentially use it inside i915, as it looks
like a clean implementation to do so. :)
Looking for feedback and some testing, as I don't have a amdgpu/radeon myself.
Only compile tested
Hi, Simon
On 2022/01/06 8:57, Simon Ser wrote:
Thanks for working on this! I've pushed a patch [1] to drm-misc-next which
touches the same function, can you rebase your patches on top of it?
[1]: https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
I understand. I will rebase th
Thanks for working on this! I've pushed a patch [1] to drm-misc-next which
touches the same function, can you rebase your patches on top of it?
[1]: https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
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 sugge
Hi,
Currently, v3d only supports single in/out syncobj per submission (in
v3d_submit_cl we have two in_sync, one for bin and another for render
job); however, Vulkan queue submit operations expect multiples wait and
signal semaphores. This series extending v3d interface and job
dependency operatio
On Wed, 19 May 2021 11:53:37 +0300
Pekka Paalanen wrote:
...
> TL;DR:
>
> I would summarise my comments so far into these:
>
> - Telling the kernel the color spaces and letting it come up with
> whatever color transformation formula from those is not enough,
> because it puts the render in
On Tue, 18 May 2021 10:19:25 -0400
Harry Wentland wrote:
> On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
> > On Mon, 17 May 2021 15:39:03 -0400
> > Vitaly Prosyak wrote:
> >
> >> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
...
> >>> I suspect that this is not about tone mapping at al
On 2021-05-18 16:19, Harry Wentland wrote:
On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
On Mon, 17 May 2021 15:39:03 -0400
Vitaly Prosyak wrote:
On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wr
On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
> On Mon, 17 May 2021 15:39:03 -0400
> Vitaly Prosyak wrote:
>
>> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
>>> On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
> On
On Mon, 17 May 2021 15:39:03 -0400
Vitaly Prosyak wrote:
> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
> > On 2021-05-17 10:57, Pekka Paalanen wrote:
> >> On Fri, 14 May 2021 17:05:11 -0400
> >> Harry Wentland wrote:
> >>
> >>> On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> >>> > On
On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
...
>> ## Mastering Luminance
On 2021-05-17 10:57, Pekka Paalanen wrote:
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
...
>> ## Mastering Luminances
>>
>> Now we are able to use the PQ 2084 EOTF to
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
> On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> > On Mon, 26 Apr 2021 13:38:49 -0400
> > Harry Wentland wrote:
...
> >> ## Mastering Luminances
> >>
> >> Now we are able to use the PQ 2084 EOTF to define the luminance of
> >> pixels
On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 13:38:49 -0400
> Harry Wentland wrote:
>
>> ## Introduction
>>
>> We are looking to enable HDR support for a couple of single-plane and
>> multi-plane scenarios. To do this effectively we recommend new
>> interfaces to drm_plan
On 2021-04-30 6:39 a.m., Shashank Sharma wrote:
> Hello Pekka,
>
> On 30/04/21 15:13, Pekka Paalanen wrote:
>> On Wed, 28 Apr 2021 13:24:27 +0530
>> Shashank Sharma wrote:
>>
>>> Assuming these details, A compositor will look for DRM color properties
>>> like these:
>>>
>>> 1. Degamma plane p
Hello Pekka,
On 30/04/21 15:13, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 13:24:27 +0530
> Shashank Sharma wrote:
>
>> Assuming these details, A compositor will look for DRM color properties like
>> these:
>>
>> 1. Degamma plane property : To make buffers linear for Gamut mapping
>>
>> 2. Gamu
On Wed, 28 Apr 2021 13:24:27 +0530
Shashank Sharma wrote:
> Assuming these details, A compositor will look for DRM color properties like
> these:
>
> 1. Degamma plane property : To make buffers linear for Gamut mapping
>
> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020
>
Hello Harry,
Many of us in the mail chain have discussed this before, on what is the right
way to blend and tone map a SDR and a HDR buffer from same/different color
spaces, and what kind of DRM plane properties will be needed.
As you can see from the previous comments, that the majority of the
On Mon, 26 Apr 2021 13:38:49 -0400
Harry Wentland wrote:
> ## Introduction
>
> We are looking to enable HDR support for a couple of single-plane and
> multi-plane scenarios. To do this effectively we recommend new
> interfaces to drm_plane. Below I'll give a bit of background on HDR
> and why we
On Mon, Apr 26, 2021 at 01:38:49PM -0400, Harry Wentland wrote:
>
> ## Introduction
>
> We are looking to enable HDR support for a couple of single-plane and
> multi-plane scenarios. To do this effectively we recommend new
> interfaces to drm_plane. Below I'll give a bit of background on HDR and
## Introduction
We are looking to enable HDR support for a couple of single-plane and
multi-plane scenarios. To do this effectively we recommend new interfaces to
drm_plane. Below I'll give a bit of background on HDR and why we propose these
interfaces.
## Defining a pixel's luminance
Curr
Hi
Am 20.02.21 um 15:37 schrieb Melissa Wen:
Adding support to overlay type in addition to primary and cursor plane.
The planes composition relies on the z order of the active planes and
only occurs if there is a primary plane (as in the current behavior).
The first patch decouples cursor from
Adding support to overlay type in addition to primary and cursor plane.
The planes composition relies on the z order of the active planes and
only occurs if there is a primary plane (as in the current behavior).
The first patch decouples cursor from crtc_init. It initializes the CRTC
only with pri
@lists.freedesktop.org
; amd-...@lists.freedesktop.org
Cc: Huang, Ray ; Koenig, Christian
Subject: Re: [RFC PATCH 0/3] add ttm trace event support
Not a bad start, but that needs quite some more work.
First of all please rebase on top of current drm-misc-next, a whole
bunch of the stuff you want to trace here
Not a bad start, but that needs quite some more work.
First of all please rebase on top of current drm-misc-next, a whole
bunch of the stuff you want to trace here was already removed or is
about to be removed.
Then concentrate on the necessary trace points, for example
ttm:ttm_bo_device_ini
the kernel ftrace can better help analyze the kernel running status.
add some trace events to support TTM.
add trace events list:
ttm:ttm_bo_add_mem_to_lru
ttm:ttm_bo_del_from_lru
ttm:ttm_bo_move_mem
ttm:ttm_bo_wait
ttm:ttm_bo_evict
ttm:ttm_bo_swapout
ttm:ttm_bo_device_init
ttm:ttm_bo_device_rele
After the last round submitting the system-uncached heap, I got
some feedback that Daniel would like to see it demonstrated with
a mesa based system. I'm still working on such a gralloc
implementation (using the db845c), but along with other work, so
I don't yet have something to share there.
How
Hi All,
Currently drm debugfs files are created using drm_debugfs_create_files()
on request.
This series introduces new functions and infrastructure that will enable
the mass creation of debugfs files during drm_dev_register(). Drivers can
request for the creation of debugfs files at any time usin
> From: Chia-I Wu
> Sent: Saturday, February 22, 2020 2:21 AM
>
> On Fri, Feb 21, 2020 at 7:59 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote:
> > > > From: Chia-I Wu
> > > > Sent: Friday, February 21, 2020 12:51 PM
> > > > If you think it is
Hi,
> > The plan is for virtio-gpu device to reserve a huge memory region in
> > the guest. Memslots may be added dynamically or statically to back
> > the region.
>
> so the region is marked as E820_RESERVED to prevent guest kernel
> from using it for other purpose and then virtio-gpu device
On Fri, Feb 21, 2020 at 7:59 AM Sean Christopherson
wrote:
>
> On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote:
> > > From: Chia-I Wu
> > > Sent: Friday, February 21, 2020 12:51 PM
> > > If you think it is the best for KVM to inspect hva to determine the memory
> > > type with page gr
On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote:
> > From: Chia-I Wu
> > Sent: Friday, February 21, 2020 12:51 PM
> > If you think it is the best for KVM to inspect hva to determine the memory
> > type with page granularity, that is reasonable and should work for us too.
> > The usersp
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 12:51 PM
>
> (resend because gmail did not format to plain text...)
>
> On Thu, Feb 20, 2020 at 8:45 PM Chia-I Wu wrote:
> >
> >
> >
> > On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
> >>
> >> > From: Chia-I Wu
> >> > Sent: Friday, Febr
(resend because gmail did not format to plain text...)
On Thu, Feb 20, 2020 at 8:45 PM Chia-I Wu wrote:
>
>
>
> On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
>>
>> > From: Chia-I Wu
>> > Sent: Friday, February 21, 2020 6:24 AM
>> >
>> > On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
>
On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
> > From: Chia-I Wu
> > Sent: Friday, February 21, 2020 6:24 AM
> >
> > On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin
> wrote:
> > >
> > > > From: Tian, Kevin
> > > > Sent: Thursday, February 20, 2020 10:05 AM
> > > >
> > > > > From: Chia-I Wu
>
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 6:24 AM
>
> On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
> >
> > > From: Tian, Kevin
> > > Sent: Thursday, February 20, 2020 10:05 AM
> > >
> > > > From: Chia-I Wu
> > > > Sent: Thursday, February 20, 2020 3:37 AM
> > > >
> > > > On Wed,
1 - 100 of 236 matches
Mail list logo
