On Tue, 2023-04-04 at 23:26 +0200, Das, Nirmoy wrote:
>
> On 4/4/2023 8:27 PM, Ville Syrjälä wrote:
> > On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote:
> > > Stolen memory is not usable for MTL A0 stepping beyond
> > > certain access size and we have no control over userspace
> > >
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 before using
it.
Fixes crashes on boot, as in:
Oops: [#1] PREEMPT
On Fri, 24 Mar 2023 10:28:45 +0100, Neil Armstrong wrote:
> A few fixes to pass the DT bindings check successfully
> for sm8450 qrd & hdk DTs.
>
> The following are still needed to pass all the checks:
> -
> https://lore.kernel.org/r/20230308082424.140224-3-manivannan.sadhasi...@linaro.org
> -
Hi Geert,
On Fri, Mar 31, 2023 at 04:48:06PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> Currently, there are two drivers for the LCD controller on Renesas
> SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
> 1. sh_mobile_lcdcfb, using the fbdev framework,
> 2. shmob_drm,
Hi Geert,
Thank you for the patch.
On Fri, Mar 31, 2023 at 04:48:11PM +0200, Geert Uytterhoeven wrote:
> The LCD Controller supported by the drm-shmob driver is not only present
> on SuperH SH-Mobile SoCs, but also on Renesas ARM SH/R-Mobile SoCs.
> Make its option visible, so the user can
Hi Geert,
Thank you for the patch.
On Fri, Mar 31, 2023 at 04:48:10PM +0200, Geert Uytterhoeven wrote:
> Set up generic fbdev emulation, to enable support for the Linux console.
>
> Use 16 as the preferred depth, as that is a good compromise between
> colorfulness and resource utilization, and
Hi Geert,
Thank you for the patch.
On Fri, Mar 31, 2023 at 04:48:09PM +0200, Geert Uytterhoeven wrote:
> The SH-Mobile DRM driver uses the legacy drm_crtc_init(), which
> advertizes only the formats in safe_modeset_formats[] (XR24 and AR24) as
> being supported.
>
> Switch to
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);
/* Program LDB_CTRL */
- reg = LDB_CTRL_CH0_ENABLE;
-
- if (fsl_ldb->lvds_dual_link)
- reg
Hi Geert,
Thank you for the patch.
On Fri, Mar 31, 2023 at 04:48:08PM +0200, Geert Uytterhoeven wrote:
> DRM_FORMAT_XRGB aka XR24 is the modus francus of DRM, and should be
> supported by all drivers.
>
> The handling for DRM_FORMAT_XRGB is similar to DRM_FORMAT_ARGB,
> just ignore
Hi Geert,
Thank you for the patch.
On Fri, Mar 31, 2023 at 04:48:07PM +0200, Geert Uytterhoeven wrote:
> Replace the printing of hexadecimal fourcc format codes by
> pretty-printed format names, using the "%p4cc" format specifier.
I really like %p4cc :-) I makes things much neater.
>
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 looks OK, except for this
> > patch.
>
> Thank you very much for taking the time!
>
> > The
Hi,
On Fri, Mar 31, 2023 at 6:59 AM Vinod Polimera
wrote:
>
> Certain flags like dirty_fb will be updated into the plane state
> during crtc atomic_check. Allow those updates during PSR commit.
>
> Reported-by: Bjorn Andersson
> Link:
Hi,
On Fri, Mar 31, 2023 at 6:59 AM Vinod Polimera
wrote:
>
> While in virtual terminal mode with PSR enabled, there will be
> no atomic commits triggered without dirty_fb being set. This
> will create a notion of no screen update. Allow atomic commit
> when dirty_fb ioctl is issued, so that it
On Tue, 04 Apr 2023 14:53:29 -0400, Tom Rix wrote:
> smatch reports
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:658:26: warning: symbol
> 'msm8x76_config' was not declared. Should it be static?
>
> This variable is only used in one file so should be static.
>
>
> [...]
Applied, thanks!
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 in msm is now just
> another DRM client that
On Mon, 13 Feb 2023 03:11:40 -0800, Kalyan Thota wrote:
> This series will enable color features on sc7280 target which has
> primary panel as eDP
>
> The series removes DSPP allocation based on encoder type and allows
> the DSPP reservation based on user request via CTM.
>
> The series will
On Wed, 29 Mar 2023 10:30:26 +0100, Colin Ian King wrote:
> There is a spelling mistake in a dev_error message. Fix it.
>
>
Applied, thanks!
[1/1] drm/msm/mdss: Fix spelling mistake "Unuspported" -> "Unsupported"
https://gitlab.freedesktop.org/lumag/msm/-/commit/44310e2964f2
Best
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Theoretically since sm8150 we should be using a single CTL for the
source split case, but since we do not support it for now, fallback to
DPU_CTL_SPLIT_DISPLAY.
Did you mean split panel case?
Signed-off-by: Dmitry Baryshkov
---
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
For sm8150+ the DPU_CTL_SPLIT_DISPLAY should be replaced with
DPU_CTL_ACTIVE_CFG support (which supports having a single CTL for both
interfaces in a split). Add comments where this conversion is required.
Signed-off-by: Dmitry Baryshkov
On 05/04/2023 04:00, Abhinav Kumar wrote:
On 4/4/2023 5:43 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:39, Abhinav Kumar wrote:
On 4/4/2023 5:33 PM, Dmitry Baryshkov wrote:
On 05/04/2023 01:12, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Duplicate sm8450 catalog entries to sm8550 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 32 ++-
1 file changed, 31 insertions(+), 1
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Duplicate qcm2290 catalog entries to sm6115 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 4/4/2023 5:37 PM, Dmitry Baryshkov wrote:
On 05/04/2023 01:30, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and
On 4/4/2023 5:43 PM, Dmitry Baryshkov wrote:
On 05/04/2023 03:39, Abhinav Kumar wrote:
On 4/4/2023 5:33 PM, Dmitry Baryshkov wrote:
On 05/04/2023 01:12, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL
On 29/03/2023 12:30, Colin Ian King wrote:
There is a spelling mistake in a dev_error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/msm/msm_mdss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Applied to drm-misc-next, sorry for the trouble.
Regards,
Qiang
On Wed, Apr 5, 2023 at 3:28 AM Daniel Vetter wrote:
>
> On Tue, Apr 04, 2023 at 04:17:33PM +0100, Emil Velikov wrote:
> > On Tue, 4 Apr 2023 at 08:13, wrote:
> > >
> > > From: Qiang Yu
> > >
> > > Upstream has reverted the
On 05/04/2023 03:39, Abhinav Kumar wrote:
On 4/4/2023 5:33 PM, Dmitry Baryshkov wrote:
On 05/04/2023 01:12, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL
blocks,
so switch it to CTL_SC7280_MASK too.
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Changes in v3:
- Split from previous patch
- Initialized hdisplay as uncompressed pclk per line at
There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.
This series moves these
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Changes in V2:
- Added a Fixes tag
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Changes in V2:
- *_calculate_initial_scale_value --> *_set_initial_scale_value
- Split pkt_per_line and eol_byte_num changes to a separate patch
- Moved pclk_per_line calculation to hdisplay adjustment in `if (dsc)`
block of
Currently, pkt_per_line is calculated by dividing slice_per_intf by
slice_count. This is incorrect, as slice_per_intf should be divided by
slice_per_pkt, which is not always equivalent to slice_count as it is
possible for there to be multiple soft slices per interface even though
a panel only
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Changes in v3:
- Reworded slice_last_group_size calculation to
`(dsc->slice_width + 2) % 3`
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
---
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to improve readability
- Dropped unused bpp
On 4/4/2023 5:33 PM, Dmitry Baryshkov wrote:
On 05/04/2023 01:12, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d
On 05/04/2023 01:30, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x280) otherwise.
On 05/04/2023 01:19, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8) otherwise.
On 05/04/2023 01:12, Abhinav Kumar wrote:
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d ("drm/msm/dpu: add support
for SM8450") had all
On 4/3/23 18:17, Christian König wrote:
> Am 02.04.23 um 18:48 schrieb Dmitry Osipenko:
>> Don't assert held dma-buf reservation lock on memory mapping of exported
>> buffer.
>>
>> We're going to change dma-buf mmap() locking policy such that exporters
>> will have to handle the lock. The previous
On 4/4/2023 4:56 PM, Jessica Zhang wrote:
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Changes in v3:
- Split from previous patch
-
On 4/4/2023 4:56 PM, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to
Hi!
On 2023-04-04 04:50, Christian König wrote:
> Adding a bunch of people who have been involved in this before.
>
> Am 03.04.23 um 22:15 schrieb Joshua Ashton:
>> On 4/3/23 20:54, Christian König wrote:
>>> Am 03.04.23 um 21:40 schrieb Joshua Ashton:
[SNIP]
Anyway, please let me know
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Changes in v3:
- Split from previous patch
- Initialized hdisplay as uncompressed pclk per line at
Currently, pkt_per_line is calculated by dividing slice_per_intf by
slice_count. This is incorrect, as slice_per_intf should be divided by
slice_per_pkt, which is not always equivalent to slice_count as it is
possible for there to be multiple soft slices per interface even though
a panel only
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Changes in v3:
- Reworded slice_last_group_size calculation to
`(dsc->slice_width + 2) % 3`
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
---
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to improve readability
- Dropped unused bpp
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Changes in V2:
- *_calculate_initial_scale_value --> *_set_initial_scale_value
- Split pkt_per_line and eol_byte_num changes to a separate patch
- Moved pclk_per_line calculation to hdisplay adjustment in `if (dsc)`
block of
There are some overlap in calculations for MSM-specific DSC variables between
DP and DSI. In addition, the calculations for initial_scale_value and
det_thresh_flatness that are defined within the DSC 1.2 specifications, but
aren't yet included in drm_dsc_helper.c.
This series moves these
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Changes in V2:
- Added a Fixes tag
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Duplicate sm8250 catalog entries to sc7180 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 4/4/2023 6:06 AM, Dmitry Baryshkov wrote:
Duplicate sm8150 catalog entries to sc8180x to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x280) otherwise.
Signed-off-by: Konrad Dybcio
[DB: fixed some
On Monday, April 3, 2023 9:48:40 AM PDT Ville Syrjälä wrote:
> On Mon, Apr 03, 2023 at 09:35:32AM -0700, Matt Roper wrote:
> > On Mon, Apr 03, 2023 at 07:02:08PM +0300, Ville Syrjälä wrote:
> > > On Fri, Mar 31, 2023 at 11:38:30PM -0700, fei.y...@intel.com wrote:
> > > > From: Fei Yang
> > > >
>
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8) otherwise.
Signed-off-by: Konrad Dybcio
[DB: fixed some of
On 4/4/2023 6:05 AM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d ("drm/msm/dpu: add support
for SM8450") had all (relevant at that time) bit spelled
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Move aperture management out of the fbdev code. It is unrelated
and needs to run even if fbdev support has been disabled. Call
the helper at the top of msm_drm_init() to take over hardware
from other drivers.
v2:
* bind all subdevices before
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 single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that
On 04/04/2023 21:53, Tom Rix wrote:
smatch reports
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:658:26: warning: symbol
'msm8x76_config' was not declared. Should it be static?
This variable is only used in one file so should be static.
Signed-off-by: Tom Rix
---
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display. The DRM core
calls both, the old callbacks and the new client helpers,
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Define the module's parameter 'fbdev' in fbdev code. No other code
uses it. No functional changes, but simplifies the later conversion
to struct drm_client.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/msm_drv.c | 10 ++
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Remove struct msm_fbdev, which is an empty wrapper around struct
drm_fb_helper. Use the latter directly. No functional changes.
v2:
* kfree fbdev helper instance on init errors (Dmitri)
Signed-off-by: Thomas Zimmermann
---
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Move aperture management out of the fbdev code. It is unrelated
and needs to run even if fbdev support has been disabled. Call
the helper at the top of msm_drm_init() to take over hardware
from other drivers.
v2:
* bind all subdevices before
On 03/04/2023 15:45, Thomas Zimmermann wrote:
Include to get the declaration of devm_ioremap() on
sparc64. No functional changes.
Signed-off-by: Thomas Zimmermann
Reported-by: kernel test robot
Link: https://lore.kernel.org/oe-kbuild-all/202303301856.zsmpwzjj-...@intel.com/
---
On 4/4/2023 8:27 PM, Ville Syrjälä wrote:
On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote:
Stolen memory is not usable for MTL A0 stepping beyond
certain access size and we have no control over userspace
access size of /dev/fb which can be backed by stolen memory.
So disable stolen
On Tue, Apr 4, 2023 at 10:18 PM 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
I think it's spelled "preceding"
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
> > correct, but you'd have to go look at where num_crtcs is initialized
On Tue, Apr 04, 2023 at 10:31:58PM +0200, Daniel Vetter wrote:
> On Tue, Apr 04, 2023 at 08:19:37PM +, Matthew Brost wrote:
> > On Tue, Apr 04, 2023 at 10:11:59PM +0200, Daniel Vetter wrote:
> > > On Tue, 4 Apr 2023 at 22:04, Matthew Brost
> > > wrote:
> > > >
> > > > On Tue, Apr 04, 2023 at
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
> correct, but you'd have to go look at where num_crtcs is initialized to
> understand why. Lets just replace it with the simpler and more
On Mon, Apr 03, 2023 at 10:50:34AM -0700, Rob Clark wrote:
> On Mon, Apr 3, 2023 at 9:25 AM Nathan Chancellor wrote:
> >
> > On Mon, Apr 03, 2023 at 09:03:14AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > This should fix a crash that was reported on ast (and possibly other
> > >
On Tue, Apr 04, 2023 at 08:19:37PM +, Matthew Brost wrote:
> On Tue, Apr 04, 2023 at 10:11:59PM +0200, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 22:04, Matthew Brost wrote:
> > >
> > > On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> > > > On Tue, 4 Apr 2023 at 15:10,
On Tue, Apr 04, 2023 at 10:11:59PM +0200, Daniel Vetter wrote:
> On Tue, 4 Apr 2023 at 22:04, Matthew Brost wrote:
> >
> > On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> > > On Tue, 4 Apr 2023 at 15:10, Christian König
> > > wrote:
> > > >
> > > > Am 04.04.23 um 14:54 schrieb
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_disable() call,
and now that's done
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 case
which should be added to the
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) there is one leftover user in an
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 participating in the aperture claim
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 check around to make it clear it's a
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
drivers/pci")
This should not
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 we can remove
it now.
v2:
-
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 using the pci helpers won't be enough. Otoh if we
On Tue, 4 Apr 2023 at 22:04, Matthew Brost wrote:
>
> On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 15:10, Christian König
> > wrote:
> > >
> > > Am 04.04.23 um 14:54 schrieb Thomas Hellström:
> > > > Hi, Christian,
> > > >
> > > > On 4/4/23 11:09,
When hitting an error, the error path forgot to unmap dma mappings and
could call set_pages_wb() on already uncached pages.
Fix this by introducing a common ttm_pool_free_range() function that
does the right thing.
v2:
- Simplify that common function (Christian König)
v3:
- Rename that common
When swapping in, or under memory pressure ttm_tt_populate() may sleep
for a substantiable amount of time. Allow interrupts during the sleep.
This will also allow us to inject -EINTR errors during swapin in upcoming
patches.
Also avoid returning VM_FAULT_OOM, since that will confuse the core
mm,
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
Reduce the page max order to the system PMD size, as we can then be nicer
to the system and avoid splitting
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 be nice to have these reviewed and
merged while
On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> On Tue, 4 Apr 2023 at 15:10, Christian König wrote:
> >
> > Am 04.04.23 um 14:54 schrieb Thomas Hellström:
> > > Hi, Christian,
> > >
> > > On 4/4/23 11:09, Christian König wrote:
> > >> Am 04.04.23 um 02:22 schrieb Matthew Brost:
>
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/23 15:10, Christian König wrote:
> > > > Am 04.04.23 um 14:54 schrieb
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 Lankhorst
Cc: Maxime Ripard
Cc:
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()").
Reported-by: syzbot+20dcf81733d43ddff...@syzkaller.appspotmail.com
Link:
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 who needs to
check stuff.
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but since the entire fb_var_screeninfo structure is uapi
we'd need to either add a new
On Tue, Apr 04, 2023 at 08:25:59AM +0800, yq882...@163.com wrote:
> From: Qiang Yu
>
> This reverts commit 4a66f3da99dcb4dcbd28544110636b50adfb0f0d.
>
> This is due to the depend commit has been reverted on upstream:
> baad10973fdb ("Revert "drm/scheduler: track GPU active time per entity"")
>
On Tue, Apr 04, 2023 at 04:17:33PM +0100, Emil Velikov wrote:
> On Tue, 4 Apr 2023 at 08:13, wrote:
> >
> > From: Qiang Yu
> >
> > Upstream has reverted the dependant commit
> > df622729ddbf ("drm/scheduler: track GPU active time per entity""),
> > but this patchset has been pushed to
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 11:09,
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 single CRTC (ie. a pageflip) calculate
> > the next vblank time, and inform the fence(s) of that deadline.
> >
> > v2: Comment
On Tue, 4 Apr 2023 at 19:29, Tvrtko Ursulin
wrote:
>
>
> On 04/04/2023 14:52, Matthew Brost wrote:
> > On Tue, Apr 04, 2023 at 10:43:03AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 04/04/2023 01:22, Matthew Brost wrote:
> >>> Hello,
> >>>
> >>> As a prerequisite to merging the new Intel Xe DRM
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 11:09, Christian König wrote:
> > > > Am 04.04.23 um 02:22 schrieb Matthew Brost:
>
On Tue, 4 Apr 2023 at 15:10, Christian König wrote:
>
> Am 04.04.23 um 14:54 schrieb Thomas Hellström:
> > Hi, Christian,
> >
> > On 4/4/23 11:09, Christian König wrote:
> >> Am 04.04.23 um 02:22 schrieb Matthew Brost:
> >>> From: Thomas Hellström
> >>>
> >>> For long-running workloads, drivers
On Mon, Apr 03, 2023 at 06:09:10PM +, Anusha Srivatsa wrote:
-Original Message-
From: De Marchi, Lucas
Sent: Wednesday, March 29, 2023 8:46 PM
To: Srivatsa, Anusha
Cc: intel...@lists.freedesktop.org; Harrison, John C
; Ceraolo Spurio, Daniele
; dri-devel@lists.freedesktop.org;
smatch reports
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:658:26: warning: symbol
'msm8x76_config' was not declared. Should it be static?
This variable is only used in one file so should be static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +-
1 file changed, 1
Insert a parameterized test for the drm_rect_rotate_inv() to ensure its
correctness and prevent future regressions. The test covers all rotation
modes.
It uses the same test cases from drm_test_rect_rotate().
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_rect_test.c | 11
1 - 100 of 341 matches
Mail list logo
