This new debugfs will expose the currently using bpc by crtc.
It is very useful for verifying whether we enter the correct
output color depth from IGT.
This patch will also add the connector's max supported bpc to
"i915_display_info" debugfs.
Example:
cat /sys/kernel/debug/dri/0/crtc-0/i915_curre
This series will expose the Connector's max supported bpc via connector
debugfs and Crtc's current bpc via crtc debugfs. Also move the existing
vendor specific "output_bpc" logic to drm.
Test-with: 20220408065143.1485069-2-bhanuprakash.mo...@intel.com
Bhanuprakash Modem (3):
drm/debug: Expose c
As drm_connector already have the display_info, instead of creating
"output_bpc" debugfs in vendor specific driver, move the logic to
the drm layer.
This patch will also move "Current" bpc to the crtc debugfs from
connector debugfs, since we are getting this info from crtc_state.
Cc: Harry Wentla
It's useful to know the connector's max supported bpc for IGT
testing. Expose it via a debugfs file on the connector "output_bpc".
Example: cat /sys/kernel/debug/dri/0/DP-1/output_bpc
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/d
The sequence for Source DP PHY CTS automation[1]:
1- Emulate successful Link Training
2- Short HPD and Change link rates and number of lanes
3- Short HPD and Change PHY test pattern and swing/pre-emp levels
With DP PHY CTS setup as follow:
[DPTX + on board LTTPR]--Main Link--->[Scope]
On Tue, Apr 05, 2022 at 03:32:50PM +0100, Robin Murphy wrote:
> Defer the IOMMU domain setup until after successfully binding
> components, so we can figure out IOMMU support directly from the VOP
> devices themselves, rather than manually inferring it from the DT (which
> also fails to account for
On Thu, Apr 7, 2022 at 2:20 PM Dave Airlie wrote:
>
> I think this should fix the amdgpu splat you have been seeing since rc1.
Not the machine I'm currently traveling with, but I'll double-check
when I'm back home.
Thanks,
Linus
The pull request you sent on Fri, 8 Apr 2022 10:19:47 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1831fed559732b132aef0ea8261ac77e73f7eadf
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Thu, Apr 07, 2022 at 09:18:39AM -0700, Matt Roper wrote:
The intent of the version check in the mmap ioctl was to maintain
support for existing platforms (i.e., ADL/RPL and earlier), but drop
support on all future igpu platforms. As we've seen on the dgpu side,
the hardware teams are using a
On Thu, Apr 07, 2022 at 05:45:32PM +0100, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_ge
On 2022/3/23 21:11, Rob Herring wrote:
On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
On 2022/3/23 04:49, Rob Herring wrote:
+/*
+ * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
+ *
+ * @index : output channel index, 0 for DVO0, 1 for DVO1
+ */
+struct lsdc_i2
On Fri, Apr 8, 2022 at 3:50 AM Helge Deller wrote:
>
> On 4/4/22 10:47, Zheyu Ma wrote:
> > The userspace program could pass any values to the driver through
> > ioctl() interface. If the driver doesn't check the value of 'pixclock',
> > it may cause divide error.
> >
> > Fix this by checking whet
On Thu, Apr 07, 2022 at 05:45:32PM +0100, Matthew Auld wrote:
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_ge
On Fri, Apr 08, 2022 at 09:36:17AM +0800, CK Hu wrote:
> Hi, Jitao & Rex:
>
> Please help to comment on this patch.
Hi Chuang,
I already sent a v2 of this patch [1] because I forgot to add the Fixes tag.
Sorry for the noise.
Thanks,
Nícolas
[1] https://lore.kernel.org/all/20220408013950.674477
The configuration for mt8192 was incorrectly using the output formats
from mt8173. Since the output formats for mt8192 are instead the same
ones as for mt8183, which require two bus samples per pixel, the
pixelclock and DDR edge setting were misconfigured. This made external
displays unable to show
Read the irq flags, like which edge to trigger on, from the devicetree
and use those when registering the irq instead of hardcoding them.
In case none was specified, fallback to falling edge trigger.
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 8 ++
As defined in the anx7625 dt-binding, the analogix,lane0-swing and
analogix,lane1-swing properties are uint8 arrays. Yet, the driver was
reading the array as if it were of uint32 and masking to 8-bit before
writing to the registers. This means that a devicetree written in
accordance to the dt-bindi
The configuration for mt8192 was incorrectly using the output formats
from mt8173. Since the output formats for mt8192 are instead the same
ones as for mt8183, which require two bus samples per pixel, the
pixelclock and DDR edge setting were misconfigured. This made external
displays unable to show
rrors
Caused by commit
7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
I have used the drm-misc tree from next-20220407 for today.
--
Cheers,
Stephen Rothwell
pgpGebA24DTlK.pgp
Description: OpenPGP digital signature
Hi,
On Thu, Apr 7, 2022 at 4:46 PM Dmitry Baryshkov
wrote:
>
> > The way I'm arguing it should work is that:
> >
> > 1. A whole bunch of the DP init code should move to the DP driver's
> > probe function. This includes parsing the DT, acquiring clocks,
> > getting a handle to our PHY, and IO mapp
Hi,
On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
wrote:
>
> The ps8640 driver looks 'working by coincidence'. It calls
> dp_aux_populate, then immediately after the function returns it checks
> for the panel. If panel-edp is built as a module, the probe might fail
> easily.
> The anx7625 drive
Hi Linus,
Main set of fixes for rc2, mostly amdgpu, but some dma-fence fixups as
well, along with some other misc ones. I think this should fix the
amdgpu splat you have been seeing since rc1.
Regards,
Dave.
drm-fixes-2022-04-08:
drm fixes for 5.18-rc2
dma-fence:
- fix warning about fence conta
On Fri, 8 Apr 2022 at 02:35, Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 7, 2022 at 3:03 PM Abhinav Kumar
> wrote:
> >
> > Hi Doug
> >
> > Thanks for the response, some comments below.
> >
> > Abhinav
> > On 4/7/2022 1:47 PM, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Apr 7, 2022 at 1:1
On Thu, 7 Apr 2022 at 23:11, Abhinav Kumar wrote:
>
> Hi Doug and Dmitry
>
> Sorry, but I caught up on this email just now.
>
> Some comments below.
>
> Thanks
>
> Abhinav
> On 4/7/2022 10:07 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC)
> > w
Hi,
On Thu, Apr 7, 2022 at 3:03 PM Abhinav Kumar wrote:
>
> Hi Doug
>
> Thanks for the response, some comments below.
>
> Abhinav
> On 4/7/2022 1:47 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 1:11 PM Abhinav Kumar
> > wrote:
> >>
> >> Hi Doug and Dmitry
> >>
> >> Sorry, but
Eliminate the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c:477:2-3:
Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar wrote:
>
> Hi Rob and Daniel
>
> On 4/7/2022 3:51 PM, Rob Clark wrote:
> > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> >>> The stuff never really worked, and leads to lots of
Hi Rob and Daniel
On 4/7/2022 3:51 PM, Rob Clark wrote:
On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang wrote:
On 3/31/2022 8:20 AM, Daniel Vetter wrote:
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things
On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang wrote:
>
>
>
> On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
> >
> > For async updates we now have a mo
Hi Doug
Thanks for the response, some comments below.
Abhinav
On 4/7/2022 1:47 PM, Doug Anderson wrote:
Hi,
On Thu, Apr 7, 2022 at 1:11 PM Abhinav Kumar wrote:
Hi Doug and Dmitry
Sorry, but I caught up on this email just now.
Some comments below.
Thanks
Abhinav
On 4/7/2022 10:07 AM, Dou
cayman_default_state and cayman_default_size are only
used in ni.c. Single file symbols should be static.
So move their definitions to cayman_blit_shaders.h
and change their storage-class-specifier to static.
Remove unneeded cayman_blit_shader.c
cayman_ps/vs definitions were removed with
commit
On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>
> Hi Simon,
>
> On 4/7/22 18:51, Simon Ser wrote:
> > Very nice plan! Big +1 for the overall approach.
>
> Thanks.
>
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
On 4/7/2022 08:49, Tvrtko Ursulin wrote:
On 03/06/2021 17:48, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing ever
Hi,
On Thu, Apr 7, 2022 at 1:11 PM Abhinav Kumar wrote:
>
> Hi Doug and Dmitry
>
> Sorry, but I caught up on this email just now.
>
> Some comments below.
>
> Thanks
>
> Abhinav
> On 4/7/2022 10:07 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC)
From: Rob Clark
The fourth param is size, rather than range_end.
Note that we could increase the address space size if we had a way to
prevent buffers from spanning a 4G split, mostly just to avoid fw bugs
with 64b math.
Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetable
The MODULE_DEVICE_TABLE already creates proper alias for platform
driver. Having another MODULE_ALIAS causes the alias to be duplicated.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/armada/armada_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_dr
Hi Doug and Dmitry
Sorry, but I caught up on this email just now.
Some comments below.
Thanks
Abhinav
On 4/7/2022 10:07 AM, Doug Anderson wrote:
Hi,
On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC)
wrote:
Hi Dmitry and Doug,
Hi,
On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshko
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that could be used to lookup the correct device into from an array.
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI
instead of I2C. For the latter, a control byte that contains a D/C# field
The current compatible strings for SSD130x I2C controllers contain an -fb
suffix, this seems to indicate that are for a fbdev driver. But the DT is
supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add new ones that don't have
the
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the compatible strings, properties and examples for SPI.
Signed-off-by: Javier Martinez Canillas
---
.../bindings/display/solomon,ssd1307fb.yaml | 89 +++
1 file changed, 71 insertions
The current compatible strings for SSD130x I2C controllers contain an -fb
suffix, this seems to indicate that are for a fbdev driver. But the DT is
supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add a new enum that contains
comp
Hello,
This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
support for SSD130x OLED controllers that can be accessed through a SPI.
The driver is quite similar to existing ssd130x-i2c driver that is used by
I2C controllers, but there is a difference in the protocol used by
On 4/4/22 10:47, Zheyu Ma wrote:
> The userspace program could pass any values to the driver through
> ioctl() interface. If the driver doesn't check the value of 'pixclock',
> it may cause divide error.
>
> Fix this by checking whether 'pixclock' is zero in the function
> i740fb_check_var().
>
> T
On 4/7/22 11:01, cgel@gmail.com wrote:
> From: Lv Ruyi
>
> of_parse_phandle returns node pointer with refcount incremented,
> use of_node_put() on it when done.
>
> Reported-by: Zeal Robot
> Signed-off-by: Lv Ruyi
applied.
Thanks!
Helge
> ---
> drivers/video/fbdev/imxfb.c | 2 ++
> 1 file
On Thu, 07 Apr 2022, Imre Deak wrote:
> The next patch needs a way to read a DPCD register without the preceding
> wake-up read in drm_dp_dpcd_read(). Export drm_dp_dpcd_access() to allow
> this.
I think I'd rather you added a special "probe" function for this
specific purpose. I think drm_dp_dpc
On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede said:
Below you covered our usual /sys/class/backlight device friends... what about
DDC monitor controls? These function similarly but just remotely control a
screen via I2C and also suffer from the same problems of "need root" and "have
to do some
The driver currently hard-codes DSI lane count to two, however the chip
is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT
property and program the result into DSI_CTRL register.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Robert Foss
It is necessary to specify the number of connected/used DSI data lanes when
using the DSI input port of this bridge. Document the 'data-lanes' property
of the DSI input port.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Rob Herring
Cc: Robert Foss
Cc:
The next patch needs a way to read a DPCD register without the preceding
wake-up read in drm_dp_dpcd_read(). Export drm_dp_dpcd_access() to allow
this.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/dp/drm_dp.c| 19 +--
include/drm/dp/drm_dp_
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Thursday, April 7, 2022 12:08
> To: Kai-Heng Feng
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Maling list - DRI developers de...@lists.freedesktop.org>; LKML ; amd-
> gfx list ; Chiu, Solomon
On Tue, 05 Apr 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the PNPID decoding available for other users.
>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_edid.h | 21 +
> 1 file changed,
Seems my first mail didn't come through so here's second time for this patch:
Reviewed-by: Juha-Pekka Heikkila
On Mon, Apr 4, 2022 at 4:39 PM Imre Deak wrote:
>
> From: Matt Roper
>
> The render/media engines on DG2 unify render compression and media
> compression into a single format for the
Le mercredi 06 avril 2022 à 15:23 -0400, Nicolas Dufresne a écrit :
> Hi Yunfei,
>
> Le jeudi 31 mars 2022 à 10:48 +0800, Yunfei Dong a écrit :
> > Add support for VP9 decoding using the stateless API,
> > as supported by MT8192. And the drivers is lat and core architecture.
> >
> > Signed-off-by
On 4/6/22 21:06, Robin Murphy wrote:
> On 2022-04-06 15:32, Dmitry Osipenko wrote:
>> On 4/5/22 17:19, Robin Murphy wrote:
>>> Remove the pointless check. host1x_drm_wants_iommu() cannot return true
>>> unless an IOMMU exists for the host1x platform device, which at the
>>> moment
>>> means the iom
On Thu, Apr 7, 2022 at 2:21 AM Christian König
wrote:
>
> Am 06.04.22 um 18:50 schrieb Grigory Vasilyev:
> > Instead of the 'amdgpu_ring_priority_level' type,
> > the 'amdgpu_gfx_pipe_priority' type was used,
> > which is an error when setting ring priority.
> > This is a minor error, but may caus
Hi Simon,
On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.
Thanks.
> On Thursday, April 7th, 2022 at 17:38, Hans de Goede
> wrote:
>
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max pr
On Thu, Apr 7, 2022 at 1:32 PM Harry Wentland wrote:
>
>
>
> On 2022-04-07 12:07, Alex Deucher wrote:
> > Actually this just causes another warning. Dropped for now. More below.
> >
> > On Thu, Apr 7, 2022 at 11:52 AM Alex Deucher wrote:
> >>
> >> Applied. Thanks!
> >>
> >> Alex
> >>
> >> On T
On 2022-04-07 12:07, Alex Deucher wrote:
> Actually this just causes another warning. Dropped for now. More below.
>
> On Thu, Apr 7, 2022 at 11:52 AM Alex Deucher wrote:
>>
>> Applied. Thanks!
>>
>> Alex
>>
>> On Thu, Apr 7, 2022 at 10:18 AM Harry Wentland
>> wrote:
>>>
>>>
>>>
>>> On 20
Applied. Thanks!
Alex
On Mon, Apr 4, 2022 at 11:57 AM Harry Wentland wrote:
>
>
>
> On 2022-04-04 11:43, Tom Rix wrote:
> >
> > On 4/4/22 8:22 AM, Harry Wentland wrote:
> >>
> >> On 2022-04-03 10:21, Tom Rix wrote:
> >>> Smatch reports this issue
> >>> hdcp1_execution.c:500:29: warning: functio
On Tue, Apr 05, 2022 at 07:29:22PM +0200, Daniel Vetter wrote:
> On Tue, 5 Apr 2022 at 18:45, Greg KH wrote:
> >
> > On Tue, Apr 05, 2022 at 06:12:59PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 05, 2022 at 03:33:17PM +0200, Greg KH wrote:
> > > > On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert
On Thu, Apr 7, 2022 at 8:21 AM Kai-Heng Feng
wrote:
>
> DP/HDMI audio on AMD PRO VII stops working after S3:
> [ 149.450391] amdgpu :63:00.0: amdgpu: MODE1 reset
> [ 149.450395] amdgpu :63:00.0: amdgpu: GPU mode1 reset
> [ 149.450494] amdgpu :63:00.0: amdgpu: GPU psp mode1 reset
> [
Hi,
On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC)
wrote:
>
> Hi Dmitry and Doug,
>
> > Hi,
> >
> > On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov
> > wrote:
> > >
> > > On 05/04/2022 20:02, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Tue, Apr 5, 2022 at 5:54 AM Dmitry Bary
On 07/04/2022 17:49, Christian König wrote:
Am 07.04.22 um 18:45 schrieb Matthew Auld:
I guess this was missed in the conversion or something.
Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Daniel Vetter
My best guess is that
|Reviewed-by: Nirmoy Das |
On 4/7/2022 1:06 PM, Matthew Auld wrote:
Ensure we check that the size is compatible with the requested
page_size. For tiny objects that are automatically annotated with
TTM_PL_FLAG_CONTIGUOUS(since they fit within a single page), we
currently end up silently overridin
On Thu, Apr 07, 2022 at 11:15:26AM +0200, Lucas Stach wrote:
> Am Mittwoch, dem 06.04.2022 um 15:08 -0500 schrieb Rob Herring:
> > On Wed, 06 Apr 2022 18:01:15 +0200, Lucas Stach wrote:
> > > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > > core with a little bit of SoC i
Le jeudi 31 mars 2022 à 10:48 +0800, Yunfei Dong a écrit :
> Add support for VP9 decoding using the stateless API,
> as supported by MT8192. And the drivers is lat and core architecture.
>
> Signed-off-by: George Sun
> Signed-off-by: Xiaoyong Lu
> Signed-off-by: Yunfei Dong
> Reviewed-by: Angel
There is possible circular locking dependency detected on event_mutex.
To break this possible circular locking, this patch move setting fail
safe mode out of event_mutex scope.
Fixes: d4aca422539c ("drm/msm/dp: always add fail-safe mode into connector
mode list")
Signed-off-by: Kuogee Hsieh
---
Very nice plan! Big +1 for the overall approach.
On Thursday, April 7th, 2022 at 17:38, Hans de Goede
wrote:
> The drm_connector brightness properties
> ===
>
> bl_brightness: rw 0-int32_max property controlling the brightness setting
> of the connected displ
Am 07.04.22 um 18:45 schrieb Matthew Auld:
I guess this was missed in the conversion or something.
Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Daniel Vetter
My best guess is that this is a rebase/merge conflict. I'm 100% su
All of CI is just failing with the following, which prevents loading of
the module:
i915 :03:00.0: [drm] *ERROR* Scratch setup failed
Best guess is that this comes from the pin_map() for the scratch page,
which does an i915_gem_object_wait_moving_fence() somewhere. It looks
like this now
I guess this was missed in the conversion or something.
Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_deps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
On Wed, Apr 6, 2022 at 11:27 PM Saurabh Sengar
wrote:
>
> Added error message when the size of requested framebuffer is more then
> the allocated size by vmbus mmio region for framebuffer
>
> Signed-off-by: Saurabh Sengar
> ---
> v1 -> v2 : Corrected Sign-off
>
> drivers/gpu/drm/hyperv/hyperv_dr
The intent of the version check in the mmap ioctl was to maintain
support for existing platforms (i.e., ADL/RPL and earlier), but drop
support on all future igpu platforms. As we've seen on the dgpu side,
the hardware teams are using a more fine-grained numbering system for IP
version numbers thes
Actually this just causes another warning. Dropped for now. More below.
On Thu, Apr 7, 2022 at 11:52 AM Alex Deucher wrote:
>
> Applied. Thanks!
>
> Alex
>
> On Thu, Apr 7, 2022 at 10:18 AM Harry Wentland wrote:
> >
> >
> >
> > On 2022-04-07 02:00, Haowen Bai wrote:
> > > Smatch reports the f
Applied. Thanks!
Alex
On Thu, Apr 7, 2022 at 8:21 AM Kai-Heng Feng
wrote:
>
> DP/HDMI audio on AMD PRO VII stops working after S3:
> [ 149.450391] amdgpu :63:00.0: amdgpu: MODE1 reset
> [ 149.450395] amdgpu :63:00.0: amdgpu: GPU mode1 reset
> [ 149.450494] amdgpu :63:00.0: amdgpu
Applied. Thanks!
Alex
On Thu, Apr 7, 2022 at 10:18 AM Harry Wentland wrote:
>
>
>
> On 2022-04-07 02:00, Haowen Bai wrote:
> > Smatch reports the following:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2174
> > dcn10_enable_vblanks_synchronization() warn: if statement
On 4/6/22 03:24, Zheyu Ma wrote:
> On Wed, Apr 6, 2022 at 2:23 AM Helge Deller wrote:
>>
>> On 4/5/22 19:46, Ondrej Zary wrote:
>>> On Tuesday 05 April 2022 08:33:57 Helge Deller wrote:
Hello Geert,
On 4/4/22 13:46, Geert Uytterhoeven wrote:
> Hi Helge,
>
> On Sun, Apr 3
On 03/06/2021 17:48, Matthew Brost wrote:
From: John Harrison
The meaning of 'default' for the enable_guc module parameter has been
updated to accurately reflect what is supported on current platforms.
So start using the defaults instead of forcing everything off.
Although, note that right no
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Fiona Buckner (pheonix...@gmail.com) changed:
What|Removed |Added
CC||pheonix...@gmail.co
As discussed already several times in the past:
https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
The current userspace API for brightness control offered by
/sys/class/backlight devices has various iss
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem.
Nice
From: Tvrtko Ursulin
Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based scheduling
On Thu, Apr 07, 2022 at 08:27:39AM +, Yassine Oudjana wrote:
> On Thursday, April 7th, 2022 at 12:08 PM, Maxime Ripard
> wrote:
> > I've been piling up few fixes already for other platforms, could you
> > also test ?
> >
> > https://github.com/mripard/linux/tree/rpi/clk-improvements-more-fixe
From: Tvrtko Ursulin
Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.
This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem.
Nice
From: Tvrtko Ursulin
Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based scheduling
Add some helpers to figure out the EDID extension block count, block
count, size, pointers to blocks.
Unfortunately, we'll need to cast away the const in a few places where
we actually need to access the data.
v2: fix s/j/i/ introduced in a rebase
Signed-off-by: Jani Nikula
---
drivers/gpu/drm
On Thu, 07 Apr 2022, Zhi Wang wrote:
> diff --git a/drivers/gpu/drm/i915/intel_gvt.h
> b/drivers/gpu/drm/i915/intel_gvt.h
> index d7d3fb6186fd..7665d7cf0bdd 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.h
> +++ b/drivers/gpu/drm/i915/intel_gvt.h
> @@ -26,7 +26,17 @@
>
> struct drm_i915_private
> Wiadomość napisana przez Sascha Hauer w dniu
> 07.04.2022, o godz. 12:16:
>
>
> Yes, and it raises a few more ;)
pls see at end of email: DRI state with playback
>
>>
>> player:
>>
>> 2022-04-06 17:52:26.424487 I Display: Geometry: 1920x1080+0+0 Size(Qt):
>> 930mmx530mm
>> 2022-04-06
Patch merged to amd-staging-drm-next.
Thanks a lot!
On 2022-04-05 15:32, Simon Ser wrote:
I've tested this patch and it fixes my bug [1]. Thanks!
Tested-by: Simon Ser
[1]: https://gitlab.freedesktop.org/drm/amd/-/issues/1734>
Hi Dmitry and Doug,
> Hi,
>
> On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov
> wrote:
> >
> > On 05/04/2022 20:02, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Apr 5, 2022 at 5:54 AM Dmitry Baryshkov
> > > wrote:
> > >>> 3. For DP and eDP HPD means something a little different.
> > >>>
On 2022-04-07 02:00, Haowen Bai wrote:
> Smatch reports the following:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2174
> dcn10_enable_vblanks_synchronization() warn: if statement not indented
>
> Signed-off-by: Haowen Bai
Reviewed-by: Harry Wentland
Harry
> ---
>
On 2022-04-07 01:52, Haowen Bai wrote:
> The pointer dc is dereferencing pointer plane_state before plane_state
> is being null checked. Fix this by assigning plane_state->ctx->dc to
> dc only if plane_state is not NULL, otherwise just NULL.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/d
On Thu, 2022-04-07 at 08:01 +0200, Christian König wrote:
> Am 07.04.22 um 04:56 schrieb Zack Rusin:
> > From: Zack Rusin
> >
> > Drivers duplicate the code required to add debugfs entries for
> > various
> > ttm resource managers. To fix it add common TTM resource manager
> > code that each driv
Hi Dmitry,
> > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > wrote:
> > > > > >
> > > > > > The panel-edp driver modes needs to be validated differently
> > > > > > from DP because the link capabilities are not available for EDP by
> that time.
> > > > > >
> > > > > > Signed-
On 4/7/22 15:31, Laurent Pinchart wrote:
Hi Alexandre,
On Thu, Apr 07, 2022 at 02:41:58PM +0200, Alexandre TORGUE wrote:
On 3/6/22 18:39, Laurent Pinchart wrote:
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corres
Dear Arunpravin,
Thank you for your patch.
Am 07.04.22 um 07:46 schrieb Arunpravin Paneer Selvam:
- Switch to drm buddy allocator
- Add resource cursor support for drm buddy
I though after the last long discussion, you would actually act on the
review comments. Daniel wrote a good summary,
On 2022.04.07 03:19:43 -0400, Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> MMIO tracking table needs to be separated from GVT-g.
>
Looks fine to me. Thanks!
Rev
Reviewed-by: Juha-Pekka Heikkila
On 4.4.2022 16.38, Imre Deak wrote:
From: Matt Roper
The render/media engines on DG2 unify render compression and media
compression into a single format for the first time, using the Tile 4
layout for main surfaces. The compression algorithm is different from
On 4/6/22 19:29, Chen-Yu Tsai wrote:
Pushed this series to drm-misc (drm-misc-next), thanks again for your patches!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
1 - 100 of 226 matches
Mail list logo
