Am 05.04.23 um 03:35 schrieb Dmitry Baryshkov:
On Mon, 03 Apr 2023 14:45:30 +0200, Thomas Zimmermann wrote:
Convert msm' fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups. As
with most other drivers' fbdev emulation, fbdev i
Am 04.04.23 um 20:08 schrieb Matthew Brost:
On Tue, Apr 04, 2023 at 12:02:03PM -0600, Zeng, Oak wrote:
Hi Matt, Thomas,
Some very bold out of box thinking in this area:
1. so you want to use drm scheduler and dma-fence for long running workload.
Why you want to do this in the first place? Wha
Hi Marek,
thanks for the quick and detailed review!
On Wed, 5 Apr 2023 05:28:16 +0200
Marek Vasut wrote:
> On 4/4/23 09:37, Luca Ceresoli wrote:
>
> [...]
>
> > @@ -177,28 +183,25 @@ static void fsl_ldb_atomic_enable(struct drm_bridge
> > *bridge,
> > clk_prepare_enable(fsl_ldb->clk);
>
Hello Zack,
Thanks for your patch.
Zack Rusin writes:
> From: Zack Rusin
>
> Many drivers (in particular all of the virtualized drivers) do not
> implement vblank handling. Assuming vblank is always present
> leads to crashes.
>
> Fix the crashes by making sure the device supports vblank bef
Am 04.04.23 um 15:37 schrieb Matthew Brost:
On Tue, Apr 04, 2023 at 11:13:28AM +0200, Christian König wrote:
Hi,
Am 04.04.23 um 02:22 schrieb Matthew Brost:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches fi
On 04/04/2023 19:04, Yang, Fei wrote:
Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO
creation
On 01/04/2023 09:38, fei.y...@intel.com wrote:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycl
On 4/4/23 1:18 PM, Daniel Vetter wrote:
Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting devices, just call to aperture_detach_devices() to detach
the device that matches the same PCI BAR / aperture range. Since the
former is just a wrapper of the latter plus a s
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
v2: Unfortunately the framebuffer sits outside of the pci bars for
gma500, and so only
There might be cases where the host attach is deferred, use dev_err_probe
to add more detailed information to /sys/kernel/debug/devices_deferred.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/driver
On Wed, Apr 05, 2023 at 12:53:29AM +0300, Dmitry Baryshkov wrote:
> On 04/04/2023 22:16, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> > > On 08/03/2023 17:53, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > For an atomic commit updating a s
On Wed, Apr 05, 2023 at 09:35:45AM +0200, Javier Martinez Canillas wrote:
>
> Hello Zack,
>
> Thanks for your patch.
>
> Zack Rusin writes:
>
> > From: Zack Rusin
> >
> > Many drivers (in particular all of the virtualized drivers) do not
> > implement vblank handling. Assuming vblank is alway
Hi Alexander,
Thank you for the patch.
On Wed, Apr 05, 2023 at 09:52:23AM +0200, Alexander Stein wrote:
> There might be cases where the host attach is deferred, use dev_err_probe
> to add more detailed information to /sys/kernel/debug/devices_deferred.
>
> Signed-off-by: Alexander Stein
Revie
On Wed, Apr 5, 2023 at 9:49 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
> > not be any difference.
> >
> > v2: Un
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
v2: Unfortunately the framebuffer
On Wed, Apr 05, 2023 at 12:00:23AM +0300, Ville Syrjälä wrote:
> On Tue, Apr 04, 2023 at 10:46:00PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 03, 2023 at 09:07:35AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > What does vblank have to do with num_crtcs? Well, this was technically
dev_warn() and similar require a training \n.
Signed-off-by: Luca Ceresoli
---
drivers/gpu/drm/bridge/fsl-ldb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index 6bac160b395b..bb13a9143edd 100644
--- a/dr
The LDB driver currently checks whether dual mode is used, otherwise it
assumes only channel 0 is in use. Add support for using only channel 1. In
device tree terms, this means linking port 2 only.
Doing this cleanly requires changing the logic of the probe functions from
this:
1. use of_graph_g
Hi Patrik
Am 05.04.23 um 10:05 schrieb Patrik Jakobsson:
On Wed, Apr 5, 2023 at 9:49 AM Thomas Zimmermann wrote:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there
If the crtc is being switched on or off then the semantics of
computing the timestampe of the next vblank is somewhat ill-defined.
And indeed, the code splats with a warning in the timestamp
computation code. Specifically it hits the check to make sure that
atomic drivers have full set up the timin
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
I do own an Intel DN2800MT board with gma500 hardware. [1] It has a PCIe
x1 slot. I n
On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 03/04/2023 20:40, Joshua Ashton wrote:
> > Hello all!
> >
> > I would like to propose a new API for allowing processes to control
> > the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
> >
> > The main reason for thi
Hi Laurent,
On Wed, 5 Apr 2023 05:30:48 +0300
Laurent Pinchart wrote:
> Hi Luca,
>
> On Tue, Apr 04, 2023 at 04:12:51PM +0200, Luca Ceresoli wrote:
> > On Wed, 29 Mar 2023 13:16:22 +0200 Hans Verkuil wrote:
> >
> > > Hi Luca,
> > >
> > > I finally found the time to test this series. It look
On Wed, Apr 05, 2023 at 09:41:23AM +0200, Christian König wrote:
> Am 04.04.23 um 15:37 schrieb Matthew Brost:
> > On Tue, Apr 04, 2023 at 11:13:28AM +0200, Christian König wrote:
> > > Hi,
> > >
> > > Am 04.04.23 um 02:22 schrieb Matthew Brost:
> > > > Hello,
> > > >
> > > > As a prerequisite to
On Wed, Apr 05, 2023 at 09:30:11AM +0200, Christian König wrote:
> Am 04.04.23 um 20:08 schrieb Matthew Brost:
> > On Tue, Apr 04, 2023 at 12:02:03PM -0600, Zeng, Oak wrote:
> > > Hi Matt, Thomas,
> > >
> > > Some very bold out of box thinking in this area:
> > >
> > > 1. so you want to use drm s
On Wed, Apr 05, 2023 at 08:50:06AM +0800, Qiang Yu wrote:
> Applied to drm-misc-next, sorry for the trouble.
No worries, I already complained to Lucas/etnaviv people that the sched
revert should have been at least posted/discussed on dri-devel. Imo this
isn't on you.
-Daniel
>
> Regards,
> Qiang
On Tue, Apr 04, 2023 at 01:59:33PM -0700, Aaron Plattner wrote:
> On 4/4/23 1:18 PM, Daniel Vetter wrote:
> > Instead of calling aperture_remove_conflicting_devices() to remove the
> > conflicting devices, just call to aperture_detach_devices() to detach
> > the device that matches the same PCI BAR
On 4/4/23 14:36, Daniel Vetter wrote:
> There's a few reasons the kernel should not spam dmesg on bad
> userspace ioctl input:
> - at warning level it results in CI false positives
> - it allows userspace to drown dmesg output, potentially hiding real
> issues.
>
> None of the other generic EINV
On 05/04/2023 10:31, Luca Ceresoli wrote:
> Hi Laurent,
>
> On Wed, 5 Apr 2023 05:30:48 +0300
> Laurent Pinchart wrote:
>
>> Hi Luca,
>>
>> On Tue, Apr 04, 2023 at 04:12:51PM +0200, Luca Ceresoli wrote:
>>> On Wed, 29 Mar 2023 13:16:22 +0200 Hans Verkuil wrote:
>>>
Hi Luca,
I f
Am 05.04.23 um 10:34 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 09:41:23AM +0200, Christian König wrote:
Am 04.04.23 um 15:37 schrieb Matthew Brost:
On Tue, Apr 04, 2023 at 11:13:28AM +0200, Christian König wrote:
Hi,
Am 04.04.23 um 02:22 schrieb Matthew Brost:
Hello,
As a prerequisite
From: Robert Foss
On Wed, 5 Apr 2023 09:52:23 +0200, Alexander Stein wrote:
> There might be cases where the host attach is deferred, use dev_err_probe
> to add more detailed information to /sys/kernel/debug/devices_deferred.
>
>
Applied, thanks!
[1/1] drm/bridge: ti-sn65dsi83: use dev_err_pr
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > > This one nukes all framebuffers, which is a bit much. In reality
> > > gma500 is igpu and never shipped with
Hi Dave & Daniel -
drm-intel-fixes-2023-04-05:
drm/i915 fixes for v6.3-rc6:
- Fix DP MST DSC M/N calculation to use compressed bpp
- Fix racy use-after-free in perf ioctl
- Fix context runtime accounting
- Fix handling of GT reset during HuC loading
- Fix use of unsigned vm_fault_t for error val
From: Robert Foss
On Wed, 5 Apr 2023 10:10:56 +0200, Luca Ceresoli wrote:
> dev_warn() and similar require a training \n.
>
>
Applied, thanks!
[1/2] drm: bridge: ldb: add missing \n in dev_warn() string
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8cc0b604f234
[2/2] drm: bridge:
On Wed, Apr 05, 2023 at 10:53:26AM +0200, Christian König wrote:
> Am 05.04.23 um 10:34 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2023 at 09:41:23AM +0200, Christian König wrote:
> > > Am 04.04.23 um 15:37 schrieb Matthew Brost:
> > > > On Tue, Apr 04, 2023 at 11:13:28AM +0200, Christian König wro
On Wed, Apr 05, 2023 at 10:19:55AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
> > not be any difference.
>
>
On 05/04/2023 09:28, Daniel Vetter wrote:
On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
wrote:
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
The
On Wed, 5 Apr 2023 at 11:11, Tvrtko Ursulin
wrote:
>
>
> On 05/04/2023 09:28, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> On 03/04/2023 20:40, Joshua Ashton wrote:
> >>> Hello all!
> >>>
> >>> I would like to propose a new API for a
On Tue, Apr 04, 2023 at 10:18:37PM +0200, Daniel Vetter wrote:
> Only really pci devices have a business setting this - it's for
> figuring out whether the legacy vga stuff should be nuked too. And
> with the preceeding two patches those are all using the pci version of
> this.
>
> Which means for
Hi
Am 05.04.23 um 10:59 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu
On Mon, Apr 03, 2023 at 11:51:50AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2023 09:19, Julien Stephan wrote:
> > From: Phi-bang Nguyen
> >
> > This is a new driver that supports the MIPI CSI CD-PHY for mediatek
> > mt8365 soc
> >
> > Signed-off-by: Louis Kuo
> > Signed-off-by: Phi-bang Nguye
On Wed, Apr 05, 2023 at 10:50:37AM +0200, Hans Verkuil wrote:
[...]
> Note that this driver will stay in staging since it still fails when I try to
> capture from two sensors at the same time: syncpoint errors start appearing
> in that case. I think there are locking issues. I think I have someone
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 10:59 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
> > > > Hi
> > > >
> > > > Am 04.04.
On Wed, Apr 05, 2023 at 12:04:04PM +0300, Jani Nikula wrote:
>
> Hi Dave & Daniel -
>
> drm-intel-fixes-2023-04-05:
> drm/i915 fixes for v6.3-rc6:
> - Fix DP MST DSC M/N calculation to use compressed bpp
> - Fix racy use-after-free in perf ioctl
> - Fix context runtime accounting
> - Fix handling
Hi,
thanks you for the time and effort for reviewing.
On 2023/4/4 19:03, Javier Martinez Canillas wrote:
Javier Martinez Canillas writes:
[...]
/*
* Remove the device from the device hierarchy. This is the right thing
-* to do for firmware-based DRM drivers, such a
Am 05.04.23 um 11:07 schrieb Daniel Vetter:
[SNIP]
I would approach it from the complete other side. This component here is a
tool to decide what job should run next.
How that is then signaled and run should not be part of the scheduler, but
another more higher level component.
This way you al
Add a panel entry with delay_200_500_e50 for the AUO NE135FBM-N41
version 8.1, found on a number of ACER laptops, including the
Swift 3 (SF313-52, SF313-53), Chromebook Spin 513 (CP513-2H) and
others.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file
On Wed, 5 Apr 2023 at 11:57, Christian König wrote:
>
> Am 05.04.23 um 11:07 schrieb Daniel Vetter:
> > [SNIP]
> >> I would approach it from the complete other side. This component here is a
> >> tool to decide what job should run next.
> >>
> >> How that is then signaled and run should not be par
Daniel Vetter writes:
> Drivers are supposed to fix this up if needed if they don't outright
> reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> sizes in fb_set_var()").
>
Should have a Fixes: tag ? I understand what was uncovered by that commit
but it help distros to figure o
Daniel Vetter writes:
> The fb_check_var hook is supposed to validate all this stuff. Any
> errors from fb_set_par are considered driver/hw issues and resulting
> in dmesg warnings.
>
> Luckily we do fix up the pixclock already, so this is all fine.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten
On 2023/4/5 17:55, Sui Jingfeng wrote:
Hi,
thanks you for the time and effort for reviewing.
On 2023/4/4 19:03, Javier Martinez Canillas wrote:
Javier Martinez Canillas writes:
[...]
/*
* Remove the device from the device hierarchy. This is the
right thing
- * to do
On 4/4/2023 5:30 PM, Andrzej Hajda wrote:
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-
Daniel Vetter writes:
> Apparently drivers need to check all this stuff themselves, which for
> most things makes sense I guess. And for everything else we luck out,
> because modern distros stopped supporting any other fbdev drivers than
> drm ones and I really don't want to argue anymore about
On 4/4/2023 6:23 PM, Andi Shyti wrote:
Hi Nirmoy,
On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
why do we need this mechanism? What was the logic behind? These
are all questions peopl
Hi
Am 05.04.23 um 11:38 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 10:59 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.0
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common
code")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 +
drivers/g
Meta: I'm trying to unblock myself by limiting each reply to a narrow-ish
topic. Otherwise it's just too much. Here's the first.
On Tue, Mar 07, 2023 at 11:25:29PM +0900, Asahi Lina wrote:
> The DRM GEM subsystem is the DRM memory management subsystem used by
> most modern drivers. Add a Rust abst
From: Robert Foss
On Mon, 3 Apr 2023 21:02:42 +0200, Marek Vasut wrote:
> Do not generate the HS front and back porch gaps, the HSA gap and
> EOT packet, as per "SN65DSI83 datasheet SLLSEC1I - SEPTEMBER 2012
> - REVISED OCTOBER 2020", page 22, these packets are not required.
> This makes the TI S
On Tue, Mar 07, 2023 at 11:25:33PM +0900, Asahi Lina wrote:
> DMA fences are the internal synchronization primitive used for DMA
> operations like GPU rendering, video en/decoding, etc. Add an
> abstraction to allow Rust drivers to interact with this subsystem.
>
> Note: This uses a raw spinlock l
Thomas Zimmermann writes:
[...]
>
> Your comment says that it calls a PCI function to clean up to vgacon.
> That comment explains what is happening, not why. And how the PCI and
> vgacon code work together is non-obvious.
>
> Again, here's my proposal for gma500:
>
> // call this from psb_pci_
On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter wrote:
>
> Uh all the rust helper wrappers for all the kernel in a single file does
> not sound good. Can we not split these up into each subsystem, and then
> maybe instead of sprinkling #ifdef all over a .c file Make the compilation
> of that file con
On Tue, Apr 4, 2023 at 12:13 AM Marek Vasut wrote:
>
> Do not generate the HS front and back porch gaps, the HSA gap and
> EOT packet, as these packets are not required. This makes the bridge
> work with Samsung DSIM on i.MX8MM and i.MX8MP.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
On Tue, Apr 4, 2023 at 12:13 AM Marek Vasut wrote:
>
> Do not generate the HS front and back porch gaps, the HSA gap and
> EOT packet, as these packets are not required. This makes the bridge
> work with Samsung DSIM on i.MX8MM and i.MX8MP.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
On Wed, Apr 05, 2023 at 01:19:47PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter wrote:
> >
> > Uh all the rust helper wrappers for all the kernel in a single file does
> > not sound good. Can we not split these up into each subsystem, and then
> > maybe instead of spri
On Mon, Mar 13, 2023 at 07:07:09PM -0700, Boqun Feng wrote:
> On Mon, Mar 13, 2023 at 12:49:57PM -0500, Faith Ekstrand wrote:
> > On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote:
> > > On 10/03/2023 06.16, Faith Ekstrand wrote:
> > > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> > >
Hi,
On 03.04.2023 19:22, Jeffrey Hugo wrote:
> On 3/27/2023 9:54 AM, Jeffrey Hugo wrote:
>> This series introduces a driver under the accel subsystem (QAIC -
>> Qualcomm AIC) for the Qualcomm Cloud AI 100 product (AIC100). AIC100 is
>> a PCIe adapter card that hosts a dedicated machine learning i
Daniel Vetter writes:
> Since vgaarb has been promoted to be a core piece of the pci subsystem
> we don't have to open code random guesses anymore, we actually know
> this in a platform agnostic way, and there's no need for an x86
> specific hack. See also 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
>
Daniel Vetter writes:
> Only really pci devices have a business setting this - it's for
> figuring out whether the legacy vga stuff should be nuked too. And
> with the preceeding two patches those are all using the pci version of
> this.
>
> Which means for all other callers primary == false and
Daniel Vetter writes:
> Otherwise it's bit silly, and we might throw out the driver for the
> screen the user is actually looking at. I haven't found a bug report
> for this case yet, but we did get bug reports for the analog case
> where we're throwing out the efifb driver.
>
> v2: Flip the chec
Daniel Vetter writes:
> A few reasons for this:
>
> - It's really the only one where this matters. I tried looking around,
> and I didn't find any non-pci vga-compatible controllers for x86
> (since that's the only platform where we had this until a few
> patches ago), where a driver partic
Daniel Vetter writes:
> With the preceeding patches it's become defunct. Also I'm about to add
> a different boolean argument, so it's better to keep the confusion
> down to the absolute minimum.
>
> v2: Since the hypervfb patch got droppped (it's only a pci device for
> gen1 vm, not for gen2) th
Daniel Vetter writes:
> Instead of calling aperture_remove_conflicting_devices() to remove the
> conflicting devices, just call to aperture_detach_devices() to detach
> the device that matches the same PCI BAR / aperture range. Since the
> former is just a wrapper of the latter plus a sysfb_disab
On Fri, 31 Mar 2023 19:28:31 +0530, Vinod Polimera wrote:
> while in virtual terminal with PSR enabled, there will be
> no atomic commits triggered resulting in no screen update.
> Update the dirtyfb flag into plane state during atomic check
> to flush the pixel data explicitly.
>
> Avoid schedu
Daniel Vetter writes:
> vga_default_device really is supposed to cover all corners, at least
> for x86. Additionally checking for rom shadowing should be redundant,
> because the bios/fw only does that for the boot vga device.
>
> If this turns out to be wrong, then most likely that's a special c
Hi Nirmoy,
> > > Add a mechanism to keep existing data when creating
> > > a ttm object with I915_BO_ALLOC_USER flag.
> > why do we need this mechanism? What was the logic behind? These
> > are all questions people might have when checking this commit.
> > Please be a bit more explicative.
>
>
>
On Wed, Apr 05, 2023 at 10:16:50AM +0200, Daniel Vetter wrote:
> If the crtc is being switched on or off then the semantics of
> computing the timestampe of the next vblank is somewhat ill-defined.
> And indeed, the code splats with a warning in the timestamp
> computation code. Specifically it hit
The tlv320aic32x4 PLL clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a cal
The tlv320aic32x4 divider clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The determine_rate hook allows to select the proper parent and its rate
for a given clock configuration. On another hand, set_parent is there to
change the parent of a mux.
Some clocks provide a set_parent hook but don't implement
determine_rate. In such a case, set_parent is pretty much useless s
On 4/5/23 09:30, Luca Ceresoli wrote:
[...]
@@ -311,10 +314,23 @@ static int fsl_ldb_probe(struct platform_device *pdev)
if (IS_ERR(fsl_ldb->regmap))
return PTR_ERR(fsl_ldb->regmap);
- /* Locate the panel DT node. */
- panel_node = of_graph_get_remote_node(dev
Am 04.04.23 um 22:06 schrieb Thomas Hellström:
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error message if
eviction was interrupted"). It would
On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter wrote:
>
> Ok if this is just interim I think it's fine. Would still be good to have
> the MAINTAINERS entry though even just to cover the interim state. Least
> because I'm assuming that when things are split up you'd still want to
> keep the rust list
On Tue, Mar 07, 2023 at 11:25:34PM +0900, Asahi Lina wrote:
> DRM Sync Objects are a container for a DMA fence, and can be waited on
> signaled, exported, and imported from userspace. Add a Rust abstraction
> so Rust DRM drivers can support this functionality.
>
> Signed-off-by: Asahi Lina
> ---
Hello Maxime,
On Wed Mar 29, 2023 at 9:58 PM CEST, Maxime Ripard wrote:
> > In order to preserve semantic correctness however, I propose to preface
> > the change with a patch that renames sun4i_dotclock and tcon-pixel-clock
> > such that dot/pixel is replaced with d/data. What do you think?
>
> I
On Wed, Apr 5, 2023 at 2:26 PM Jacek Lawrynowicz
wrote:
>
> Hi,
>
> On 03.04.2023 19:22, Jeffrey Hugo wrote:
> > On 3/27/2023 9:54 AM, Jeffrey Hugo wrote:
> >> This series introduces a driver under the accel subsystem (QAIC -
> >> Qualcomm AIC) for the Qualcomm Cloud AI 100 product (AIC100). AIC1
Hi,
On 4/4/23 21:25, Daniel Vetter wrote:
On Tue, Apr 04, 2023 at 07:02:23PM +, Matthew Brost wrote:
On Tue, Apr 04, 2023 at 08:14:01PM +0200, Thomas Hellström (Intel) wrote:
On 4/4/23 15:10, Christian König wrote:
Am 04.04.23 um 14:54 schrieb Thomas Hellström:
Hi, Christian,
On 4/4/23
Hi Andi,
On 4/5/2023 1:53 PM, Andi Shyti wrote:
Hi Nirmoy,
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
why do we need this mechanism? What was the logic behind? These
are all questions people might have when checking this commit.
Please be a
On 4/5/23 14:32, Christian König wrote:
Am 04.04.23 um 22:06 schrieb Thomas Hellström:
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error messa
On Wed, Apr 05, 2023 at 02:32:12PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 5, 2023 at 1:23 PM Daniel Vetter wrote:
> >
> > Ok if this is just interim I think it's fine. Would still be good to have
> > the MAINTAINERS entry though even just to cover the interim state. Least
> > because I'm assumin
Am 05.04.23 um 14:35 schrieb Thomas Hellström:
Hi,
On 4/4/23 21:25, Daniel Vetter wrote:
On Tue, Apr 04, 2023 at 07:02:23PM +, Matthew Brost wrote:
On Tue, Apr 04, 2023 at 08:14:01PM +0200, Thomas Hellström (Intel)
wrote:
On 4/4/23 15:10, Christian König wrote:
Am 04.04.23 um 14:54 schri
From: Robert Foss
On Fri, 31 Mar 2023 11:02:04 +0800, Pin-yen Lin wrote:
> The default hpd_wait_us in panel_edp.c is 2 seconds. This makes the
> sleep time in the polling of _ps8640_wait_hpd_asserted become 200ms.
> Change it to a constant 20ms to speed up the function.
>
>
Applied, thanks!
[
On Wed, Apr 05, 2023 at 02:39:35PM +0200, Christian König wrote:
> Am 05.04.23 um 14:35 schrieb Thomas Hellström:
> > Hi,
> >
> > On 4/4/23 21:25, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2023 at 07:02:23PM +, Matthew Brost wrote:
> > > > On Tue, Apr 04, 2023 at 08:14:01PM +0200, Thomas Hell
From: Martin Krastev
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
On 5.04.23 г. 7:56 ч., Zack Rusin wrote:
From: Zack Rusin
Many drivers (in particular all of the virtualized drivers) do not
implement vblank handling. Assuming vblank is always present
leads to crashes.
Fix the c
Hi Maxime,
Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
> On Fri, Mar 24, 2023 at 08:58:48PM +, Aidan MacDonald wrote:
> > > > My suggestion: add a per-clock bitmap to keep track of which
> > > > parents
> > > > are allowed. Any operation that would select a parent clock not
>
Il 30/01/23 13:38, Xiaoyong Lu ha scritto:
Add mediatek av1 decoder linux driver which use the stateless API in
MT8195.
Signed-off-by: Xiaoyong Lu
Reviewed-by: AngeloGioacchino Del Regno
On MT8195 Tomato
Tested-by: AngeloGioacchino Del Regno
Hi Maxime,
Le mardi 04 avril 2023 à 12:11 +0200, Maxime Ripard a écrit :
> The Ingenic CGU clocks implements a mux with a set_parent hook, but
> doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name
> implies,
> change the parent of a
On Tue, Apr 04, 2023 at 07:48:27PM +, Matthew Brost wrote:
> On Tue, Apr 04, 2023 at 09:25:52PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 07:02:23PM +, Matthew Brost wrote:
> > > On Tue, Apr 04, 2023 at 08:14:01PM +0200, Thomas Hellström (Intel) wrote:
> > > >
> > > > On 4/4/
On Wed, Apr 05, 2023 at 01:16:27PM +0200, Javier Martinez Canillas wrote:
> Thomas Zimmermann writes:
>
> [...]
>
> >
> > Your comment says that it calls a PCI function to clean up to vgacon.
> > That comment explains what is happening, not why. And how the PCI and
> > vgacon code work togethe
On Wed, Apr 05, 2023 at 12:52:12PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > Apparently drivers need to check all this stuff themselves, which for
> > most things makes sense I guess. And for everything else we luck out,
> > because modern distros stopped supporting any
On Wed, Apr 05, 2023 at 12:21:11PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > Drivers are supposed to fix this up if needed if they don't outright
> > reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> > sizes in fb_set_var()").
> >
>
> Should have a F
On Wed, Apr 05, 2023 at 03:35:19PM +0300, Oded Gabbay wrote:
> On Wed, Apr 5, 2023 at 2:26 PM Jacek Lawrynowicz
> wrote:
> >
> > Hi,
> >
> > On 03.04.2023 19:22, Jeffrey Hugo wrote:
> > > On 3/27/2023 9:54 AM, Jeffrey Hugo wrote:
> > >> This series introduces a driver under the accel subsystem (QA
1 - 100 of 254 matches
Mail list logo
