https://bugzilla.kernel.org/show_bug.cgi?id=207005
--- Comment #2 from toki1990 (destekerdemon...@gmail.com) ---
Created attachment 288103
--> https://bugzilla.kernel.org/attachment.cgi?id=288103&action=edit
Video screenshot for game starting artifact graphical corruption
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=207005
--- Comment #1 from toki1990 (destekerdemon...@gmail.com) ---
Created attachment 288101
--> https://bugzilla.kernel.org/attachment.cgi?id=288101&action=edit
Video screenshot for instant artifact graphical corruption.
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=207005
Bug ID: 207005
Summary: amd polaris (rx 470) strange instant
artifacts/graphical corruptions
Product: Drivers
Version: 2.5
Kernel Version: 5.5.13 and 5.6rc7
Hardware: x
Oops, completely forgot to link to the work_struct version of this patch:
[1]
https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4
On Fri, 2020-03-27 at 16:29 -0400, Lyude Paul wrote:
> Adding Tejun to this thread per-Daniel's suggestion on IRC.
>
> Hi
Adding Tejun to this thread per-Daniel's suggestion on IRC.
Hi Tejun! So, I don't know what your experience with modesetting related stuff
is so I'll quickly explain some important concepts here regarding scanlines,
vblanks, etc. If you already understand this, feel free to skip this next
paragrap
Hi Rob.
On Wed, Mar 25, 2020 at 04:05:38PM -0600, Rob Herring wrote:
> The 'adi,adxl345' definition is a duplicate as there's a full binding in:
> Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
>
> The trivial-devices binding doesn't capture that 'adi,adxl346' has a
> fallback compa
>-Original Message-
>From: Marek Szyprowski
>Sent: Friday, March 27, 2020 12:21 PM
>To: dri-devel@lists.freedesktop.org; linux-samsung-...@vger.kernel.org;
>linux-ker...@vger.kernel.org
>Cc: Marek Szyprowski ;
>sta...@vger.kernel.org; Bartlomiej Zolnierkiewicz
>; Maarten Lankhorst
>; Maxim
Hi CK,
On 26/03/2020 00:05, CK Hu wrote:
> Hi, Matthias:
>
> On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote:
>>
>> On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
>>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
>>> replace mtk_ddp_add_comp_to_path() and
On Fri, Mar 27, 2020 at 04:45:09PM +0100, Wolfram Sang wrote:
>
> > > > > Move away from the deprecated API.
> > > > >
> > > > > Signed-off-by: Wolfram Sang
> > > >
> > > > patches 1,6, are:
> > > > Acked-by: Alex Deucher
> > > Should we commit all to drm-misc-next?
> >
> > I'm fine to see it g
The pull request you sent on Fri, 27 Mar 2020 16:58:46 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-03-27
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7bf8df68cba0536479aead32297e47908922582c
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
Scatterlist elements contains both pages and DMA addresses, but one
should not assume 1:1 relation between them. The sg->length is the size
of the physical memory chunk described by the sg->page, while
sg_dma_len(sg) is the size of the DMA (IO virtual) chunk described by
the sg_dma_address(sg).
Th
> > > > Move away from the deprecated API.
> > > >
> > > > Signed-off-by: Wolfram Sang
> > >
> > > patches 1,6, are:
> > > Acked-by: Alex Deucher
> > Should we commit all to drm-misc-next?
>
> I'm fine to see it go through whatever tree makes sense.
I'd suggest drm-misc-next to minimize merge
On Fri, Mar 27, 2020 at 11:25 AM Sam Ravnborg wrote:
>
> On Fri, Mar 27, 2020 at 10:25:16AM -0400, Alex Deucher wrote:
> > On Thu, Mar 26, 2020 at 5:35 PM Wolfram Sang
> > wrote:
> > >
> > > Move away from the deprecated API.
> > >
> > > Signed-off-by: Wolfram Sang
> >
> > patches 1,6, are:
> >
On Fri, Mar 27, 2020 at 10:25:16AM -0400, Alex Deucher wrote:
> On Thu, Mar 26, 2020 at 5:35 PM Wolfram Sang
> wrote:
> >
> > Move away from the deprecated API.
> >
> > Signed-off-by: Wolfram Sang
>
> patches 1,6, are:
> Acked-by: Alex Deucher
Should we commit all to drm-misc-next?
Sam
On Thu, Mar 26, 2020 at 5:35 PM Wolfram Sang
wrote:
>
> Move away from the deprecated API.
>
> Signed-off-by: Wolfram Sang
patches 1,6, are:
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
> 2 files changed
On Fri, Mar 27, 2020 at 6:25 AM Shane Francis wrote:
>
> Hello Marek,
>
> On Fri, Mar 27, 2020 at 9:00 AM Marek Szyprowski
> wrote:
> > > I have tested the above patch against my original issues with amdgpu
> > > and radeon drivers and everything is still working as expected.
> > >
> > > Sorry I
Hi,
On 26/03/2020 10:36, Pekka Paalanen wrote:
> On Wed, 25 Mar 2020 17:18:15 +0100
> Neil Armstrong wrote:
>
>> Hi,
>>
>> On 25/03/2020 14:49, Pekka Paalanen wrote:
>>> On Wed, 25 Mar 2020 11:24:15 +0100
>>> Neil Armstrong wrote:
>>>
Hi,
On 25/03/2020 10:04, Simon Ser wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
wrote:
> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
> > > wrote:
> > > >
> > > > recently we wanted to updat
Signed-off-by: Maya Rashish
---
drivers/gpu/drm/nouveau/include/nvif/list.h | 353
1 file changed, 353 deletions(-)
delete mode 100644 drivers/gpu/drm/nouveau/include/nvif/list.h
diff --git a/drivers/gpu/drm/nouveau/include/nvif/list.h
b/drivers/gpu/drm/nouveau/include/nvi
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek wrote:
>
> recently we wanted to update xilinx intc driver and we found that function
> which we wanted to remove is still wired by ancient Xilinx PowerPC
> platforms. Here is the thread about it.
> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-
On Fri, Mar 27, 2020 at 07:27:56AM +, Mun, Gwan-gyeong wrote:
> On Fri, 2020-03-20 at 13:57 +0200, Laurent Pinchart wrote:
> > Hi Jani,
> >
> > On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> > > On Fri, 20 Mar 2020, Jani Nikula
> > > wrote:
> > > > On Tue, 11 Feb 2020, Gwan-gy
The VBT fields match the DPCD data, so use the same helper.
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
Stop overriding the VBT defined value for rc_model_size.
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ca299a
Move the intialization of the rc_model_size from the common code into
encoder code, allowing different encoders to specify the size according
to their needs. Keep using the hard coded value in the encoders for now
to make this a non-functional change.
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signe
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other size
Use the new drm_dsc_dp_rc_buffer_size() helper to simplify rc buffer
size computation. No functional changes.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 37 -
1 fi
The PPS is supposed to reflect the DSC config instead of hard coding the
rc_model_size. Make it so.
Currently all users of drm_dsc_pps_payload_pack() hard code the size to
8192 also in the DSC config, so this change should have no impact, other
than allowing the drivers to use other sizes as neede
Add a helper for calculating the rc buffer size from the DCPD offsets
DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dsc.c | 27 +++
include/d
Hello Marek,
On Fri, Mar 27, 2020 at 9:00 AM Marek Szyprowski
wrote:
> > I have tested the above patch against my original issues with amdgpu
> > and radeon drivers and everything is still working as expected.
> >
> > Sorry I missed this in my original patches.
>
> No problem. Thanks for testing!
Hi,
On 3/26/20 6:55 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 4:10 PM Hans de Goede wrote:
Currently drivers using drm_fbdev_generic_setup() end up with a single
empty aperture in their fb_info struct.
Not having the proper info in the apertures list causes
register_framebuffer to not
On Wed, Mar 25, 2020 at 11:05 PM Rob Herring wrote:
> Numerous schemas are missing 'additionalProperties: false' statements which
> ensures a binding doesn't have any extra undocumented properties or child
> nodes. Fixing this reveals various missing properties, so let's fix all
> those occurrenc
Hi Christian,
On 2020-03-27 09:11, Christian König wrote:
> Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
>> On 2020-03-25 10:07, Shane Francis wrote:
>>> As dma_map_sg can reorganize scatter-gather lists in a
>>> way that can cause some later segments to be empty we should
>>> always use the sg_
Hi Shane
On 2020-03-27 09:55, Shane Francis wrote:
> On Fri, Mar 27, 2020 at 8:24 AM Marek Szyprowski
> wrote:
>> Scatterlist elements contains both pages and DMA addresses, but in general,
>> one cannot assume 1:1 relation between them. The sg->length is the size of
>> the physical memory chunk
On Fri, Mar 27, 2020 at 8:24 AM Marek Szyprowski
wrote:
>
> Scatterlist elements contains both pages and DMA addresses, but in general,
> one cannot assume 1:1 relation between them. The sg->length is the size of
> the physical memory chunk described by sg->page, while sg_dma_length(sg) is
> the s
On Wed, 25 Mar 2020, Rob Herring wrote:
> Numerous schemas are missing 'additionalProperties: false' statements which
> ensures a binding doesn't have any extra undocumented properties or child
> nodes. Fixing this reveals various missing properties, so let's fix all
> those occurrences.
>
> Cc:
On Wed, 25 Mar 2020, Rob Herring wrote:
> Setting 'additionalProperties: false' is frequently omitted, but is
> important in order to check that there aren't extra undocumented
> properties in a binding.
>
> Ideally, we'd just add this automatically and make this the default, but
> there's some c
On 2020-03-27 08:54, Marek Szyprowski wrote:
> On 2020-03-25 10:07, Shane Francis wrote:
>> As dma_map_sg can reorganize scatter-gather lists in a
>> way that can cause some later segments to be empty we should
>> always use the sg_dma_len macro to fetch the actual length.
>>
>> This could now be 0
On Fri, 20 Mar 2020 14:42:51 +0100,
Bartlomiej Zolnierkiewicz wrote:
>
>
> On 3/19/20 4:49 PM, Takashi Iwai wrote:
> > On Wed, 11 Mar 2020 10:32:27 +0100,
> > Takashi Iwai wrote:
> >>
> >> Hi,
> >>
> >> here is a series of trivial patches just to convert suspicious
> >> snprintf() usages with the
Scatterlist elements contains both pages and DMA addresses, but in general,
one cannot assume 1:1 relation between them. The sg->length is the size of
the physical memory chunk described by sg->page, while sg_dma_length(sg) is
the size of the DMA (IO virtual) chunk described by sg_dma_address(sg).
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2020-03-27:
Fixes for instability on Baytrail and Haswell;
Ice Lake RPS; Sandy Bridge RC6; and few others around
GT hangchec/reset; livelock; and a null dereference.
Thanks,
Rodrigo.
The following changes since commit cb7adfd6ad12a11902ebe374be
Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
Hi All,
On 2020-03-25 10:07, Shane Francis wrote:
As dma_map_sg can reorganize scatter-gather lists in a
way that can cause some later segments to be empty we should
always use the sg_dma_len macro to fetch the actual length.
This could now be 0 a
Adding support for visionox rm69299 panel driver and adding bindings for the
same panel.
Harigovindan P (2):
dt-bindings: display: add visionox rm69299 panel variant
drm/panel: add support for rm69299 visionox panel driver
.../display/panel/visionox,rm69299.yaml | 58
drivers/gp
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
- Updating licen
This patch is still valid as no changes to panel orientation quirks
have been done. Someone can review this to merge?
El mar., 30 jul. 2019 a las 21:49, David Santamaría Rogado
() escribió:
>
> This adds the HD version of Lenovo Ideapad D330
> and FHD version of Lenovo Ideapad Miix 320.
>
> This s
Hi All,
On 2020-03-25 10:07, Shane Francis wrote:
> As dma_map_sg can reorganize scatter-gather lists in a
> way that can cause some later segments to be empty we should
> always use the sg_dma_len macro to fetch the actual length.
>
> This could now be 0 and not need to be mapped to a page or
> a
On 26.02.2020 11:13, Marek Szyprowski wrote:
> Don't confuse user with meaningless warning about failure in getting
> regulators in case of deferred probe.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/sii9234.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> di
On 10.03.2020 11:34, Marek Szyprowski wrote:
> Analogix_dp driver acquires all its resources in the ->bind() callback,
> what is a bit against the component driver based approach, where the
> driver initialization is split into a probe(), where all resources are
> gathered, and a bind(), where all
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
dif
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VS
Added state readout for DP HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/dis
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file chang
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Byte
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and intel_dp_hdr
It adds an unpack function for DRM infoframe for dynamic range and
mastering infoframe readout. It unpacks CTA-861-G DRM infoframe DataBytes
contained in the binary buffer into a structured frame of the HDMI Dynamic
Range and Mastering (DRM) infoframe.
CTA-861-G DRM infoframe spec is used for HDR
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed configs
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i91
On Fri, 2020-03-20 at 13:57 +0200, Laurent Pinchart wrote:
> Hi Jani,
>
> On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> > On Fri, 20 Mar 2020, Jani Nikula
> > wrote:
> > > On Tue, 11 Feb 2020, Gwan-gyeong Mun
> > > wrote:
> > > > It adds an unpack only function for DRM infoframe
Hi Linus,
Pretty quiet some minor sg mapping fixes for 3 drivers, and a single
oops fix for the scheduler.
I'm hoping nobody tries to send me a fixes pull today but I'll keep an
eye out of the weekend.
Dave.
drm-fixes-2020-03-27:
drm fixes for 5.6-rc8/final
radeon/amdgpu/dma-buf:
- sg list fixe
64 matches
Mail list logo
