Hi
Am 07.02.20 um 17:41 schrieb Daniel Vetter:
> On Fri, Feb 07, 2020 at 03:16:02PM +0100, Thomas Zimmermann wrote:
>> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
>> the set function, drm_helper_connector_dpms(), wouldn't support it
>> anyway. So keep the pointer to NULL.
>>
Quoting Daniel Vetter (2020-02-04 15:01:46)
> This catches the majority of drivers (unfortunately not if we take
> users into account, because all the big drivers have at least a
> lastclose hook).
>
> With the prep patches out of the way all drm state is fully protected
> and either prevents or c
Quoting Daniel Vetter (2020-02-04 15:01:45)
> We want to only take the BKL on crap drivers, but to know whether
> we have a crap driver we first need to look it up. Split this shuffle
> out from the main BKL-disabling patch, for more clarity. Historical
> aside: When the kernel-wide BKL was removed
Hi
Am 07.02.20 um 17:27 schrieb Daniel Vetter:
> On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 07.02.20 um 14:59 schrieb Ville Syrjala:
From: Ville Syrjälä
The docs say possible
> -Original Message-
> From: Mun, Gwan-gyeong
> Sent: Sunday, February 9, 2020 9:05 AM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org
> Subject: Re: [PATCH v3 04/17] drm/i915/dp: Add writing of DP SDPs (Secondary
>
On 2/10/20 4:39 AM, Nicolas Boichat wrote:
On Fri, Feb 7, 2020 at 4:13 PM Tomeu Vizoso wrote:
On 2/7/20 8:42 AM, Nicolas Boichat wrote:
On Fri, Feb 7, 2020 at 2:18 PM Tomeu Vizoso wrote:
Some more changes are still required to get devfreq working, and of course
I do not have a userspace d
adding dri-devel
Am 04.02.20 um 20:17 schrieb Eric Anholt:
> vc4 changes are:
>
> Acked-by: Eric Anholt
>
> On Thu, Jan 23, 2020 at 6:00 AM Thomas Zimmermann wrote:
>>
>> VBLANK callbacks in struct drm_driver are deprecated in favor of
>> their equivalents in struct drm_crtc_funcs. Convert vc4
On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
>
> I've sent out a v4 version of the format modifier patches which avoid
> caching values in the nouveau_framebuffer struct. It will have a few
> trivial conflicts with your series, but should make them structurally
> compatible.
>
> I'm fine with
On 29/11/2019 17:23, Jyri Sarha wrote:
To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
should be selected atomatically by the drivers using it.
Signed-o
Hi
Am 10.02.20 um 09:20 schrieb Ben Skeggs:
> On Sat, 8 Feb 2020 at 07:10, James Jones wrote:
>>
>> I've sent out a v4 version of the format modifier patches which avoid
>> caching values in the nouveau_framebuffer struct. It will have a few
>> trivial conflicts with your series, but should make
On Sun, 9 Feb 2020 at 22:56, Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Thanks!
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc
On 29/11/2019 17.23, Jyri Sarha wrote:
> To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
> configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
> SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
> should be selected atomatically by the drivers using it.
Hi Thierry,
On 02/12/2019 15:07, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2019 at 11:39:50AM +0200, Tomi Valkeinen wrote:
The panel datasheet says that the panel samples at falling edge, but
does not say anything about h/v sync signals. Testing shows that if t
Hi Andrzej,
On 21/01/2020 11:46, Tomi Valkeinen wrote:
Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
max 165MHz.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 13 +
1 f
On 10.02.2020 09:21, Tomi Valkeinen wrote:
> Hi Andrzej,
>
> On 21/01/2020 11:46, Tomi Valkeinen wrote:
>> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
>> max 165MHz.
>>
>> Signed-off-by: Tomi Valkeinen
>> Reviewed-by: Andrzej Hajda
>> Reviewed-by: Laurent Pinchart
>>
On Fri, Feb 07, 2020 at 03:16:01PM +0100, Thomas Zimmermann wrote:
> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
> the set function, drm_helper_connector_dpms(), wouldn't support it
> anyway. So keep the pointer to NULL.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd
On 2/7/20 12:01 AM, Finn Thain wrote:
> This patch resolves these compiler errors and warnings --
>
> CC drivers/video/fbdev/g364fb.o
> drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
> drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this
> function)
> dr
Hi Quentin,
Thank you for the review, please find my comments below.
On 2/7/20 12:04 PM, Quentin Perret wrote:
On Thursday 06 Feb 2020 at 13:46:37 (+), lukasz.l...@arm.com wrote:
2. Core APIs
@@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework.
Drivers are
Pointer to structure array is assumed not NULL by default. It has
the consequence to raise a kernel panic when it's not the case.
Basically, running at least a RTX2080TI on Xen makes a bad mmio error
which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
code, it's assumed to be n
syzbot has bisected this bug to:
commit f75f91574617a3c6fbc821c6b156f5777a59d0ed
Author: Chris Wilson
Date: Tue May 15 14:31:49 2018 +
drm/i915: Shrink search list for active timelines
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=121dc6b5e0
start commit: 90568ecf
This binding is for the tft displays based on ilitek,ili9486.
ozzmaker,piscreen and waveshare,rpi-lcd-35 are such displays
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
v3 changes:
* no changes
v4 chang
On Fri, Feb 7, 2020 at 5:38 AM wrote:
>
> On 2020-02-06 20:29, Jeffrey Hugo wrote:
> > On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P
> > wrote:
> >>
> >> For a given byte clock, if VCO recalc value is exactly same as
> >> vco set rate value, vco_set_rate does not get called assuming
> >> VCO is a
The goal of this series is to get the displays based on ilitek,ili9486
working.
Ozzmaker, Piscreen and waveshare,rpi-lcd-35 are such displays.
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
* assignment of dbi_command before registration
* made
On Wed 05 Feb 11:24 PST 2020, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 4, 2020 at 11:02 PM Sharat Masetty
> wrote:
> >
> > + power-domains = <&gpucc CX_GDSC>, <&gpucc GX_GDSC>;
>
> I should note that this is going to be a PITA to land because the
> patch adding "GX_GDSC
On Fri, 7 Feb 2020 at 06:27, Nicolas Boichat wrote:
>
> When there is a single power domain per device, the core will
> ensure the power domain is switched on (so it is technically
> equivalent to having not power domain specified at all).
>
> However, when there are multiple domains, as in MT8183
This adds support fot ilitek,ili9486 based displays with shift register
in front of controller.
Ozzmaker,Piscreen and Waveshare,rpi-lcd-35 are such displays.
Acked-by: Sam Ravnborg (v4)
Reviewed-by: Noralf Tronnes (v4)
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* assignment of dbi_comma
On 2020-02-06 20:29, Jeffrey Hugo wrote:
On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P
wrote:
For a given byte clock, if VCO recalc value is exactly same as
vco set rate value, vco_set_rate does not get called assuming
VCO is already set to required value. But Due to GDSC toggle,
VCO values ar
On Sun, 9 Feb 2020 at 13:50, Nicolas Boichat wrote:
>
> On Fri, Feb 7, 2020 at 10:26 PM Ulf Hansson wrote:
> >
> > On Fri, 7 Feb 2020 at 06:27, Nicolas Boichat wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power domain is switched on (so it is
> + for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
> + if (!pfdev->pm_domain_devs[i])
> + break;
I'm not totally familiar with this code, but should this be a break or
just a continue?
signature.asc
Description: PGP signature
__
Hi,
On 10/02/2020 10:05, Tomi Valkeinen wrote:
> On 10/02/2020 10:49, Andrzej Hajda wrote:
>
>>> Is this ok to merge?
>>
>>
>> Yes, If I remember you have merge rights. If not, let me know.
>
> Yes, I have.
>
> Generally speaking, how do you manage bridge patches? If you give
> reviewed-by/ack
Hi Thomas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.6-rc1 next-20200210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base&#x
Hi,
On 02/02/2020 19:23, Sam Ravnborg wrote:
> Hi Marek.
>
> On Mon, Jan 27, 2020 at 03:20:22AM +0100, Marek Vasut wrote:
>> Add DT bindings for ITE IT6251 LVDS-to-eDP bridge.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Daniel Vetter
>> Cc: Rob Herring
>> Cc: Sean Cross
>> Cc: devicet...@vger.ker
On 13/01/2020 14:31, Tomi Valkeinen wrote:
> Hi Andrzej,
>
> On 09/12/2019 16:45, Andrey Smirnov wrote:
>> + Chris Healy
>>
>> On Mon, Dec 9, 2019 at 12:27 AM Tomi Valkeinen wrote:
>>>
>>> Link training fails with:
>>>
>>> Link training timeout waiting for LT_LOOPDONE!
>>> main link enable
On 10/02/2020 10:49, Andrzej Hajda wrote:
Is this ok to merge?
Yes, If I remember you have merge rights. If not, let me know.
Yes, I have.
Generally speaking, how do you manage bridge patches? If you give reviewed-by/acked-by, does it mean
it's good for the sender to push to drm-misc-next
On 15/01/2020 13:56, Geert Uytterhoeven wrote:
> The code was changed to call drm_connector_init_with_ddc() instead of
> drm_connector_init(), but the corresponding error message was not
> updated.
>
> Fixes: cfb444552926989f ("drm/bridge: ti-tfp410: Provide ddc symlink in
> connector sysfs direc
On 21/01/2020 09:27, Bogdan Togorean wrote:
> This patch-set add support for ADV7535 part in ADV7511 driver.
>
> ADV7535 and ADV7533 are pin to pin compatible parts but ADV7535
> support TMDS clock upto 148.5Mhz and resolutions up to 1080p@60Hz.
>
> ---
> Changes in v4:
> - get out ADV7533 v1p2
On 10.02.2020 10:05, Tomi Valkeinen wrote:
> On 10/02/2020 10:49, Andrzej Hajda wrote:
>
>>> Is this ok to merge?
>>
>> Yes, If I remember you have merge rights. If not, let me know.
> Yes, I have.
>
> Generally speaking, how do you manage bridge patches? If you give
> reviewed-by/acked-by, does i
Call drm_dev_unregister() first in bochs_pci_remove(). Hook
bochs_unload() into the new .release callback, to make sure cleanup
is done when all users are gone.
Add ready bool to state struct and move bochs_hw_fini() call from
bochs_unload() to bochs_pci_remove() to make sure hardware is not
touc
Hi,
I smoke-tested the patchset by running X11, Weston and fbdev emulation
on ast and udl. No apparent problems found, so
Tested-by: Thomas Zimmermann
Best regards
Thomas
Am 04.02.20 um 16:01 schrieb Daniel Vetter:
> CI didn't like my test-with tag :-/
>
> Test-with: 20200128112549.172135-1-d
On 31/01/2020 12:15, Peter Ujfalusi wrote:
> Hi,
>
> Changes since v3:
> - bindings/example: Fixed the node name
> - bindings/example: Added include for GPIO_ACTIVE_LOW and fixed up the gpio
> binding
> - driver: Moved the label for goto in tc358768_calc_pll()
> - driver: Replace
On 29/11/2019 16:23, Jyri Sarha wrote:
> To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
> configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
> SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
> should be selected atomatically by the drivers using it.
>
Move final cleanups from cirrus_pci_remove() to the new callback.
Add drm_atomic_helper_shutdown() call to cirrus_pci_remove().
Set pointers to NULL after iounmap() and check them before using
them to make sure we don't touch released hardware.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/c
On 18/12/2019 13:12, Enric Balletbo i Serra wrote:
> Fix the 'manged' typo with 'managed' in the drm_panel_bridge_add
> kernel-doc documentation.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/gpu/drm/bridge/panel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On 21/01/2020 11:24, Yannick Fertre wrote:
> From: Yannick Fertré
>
> Sometime the post_disable function is missing (not registered).
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
Split virtio_gpu_deinit(), move the drm shutdown and release to
virtio_gpu_release(). Also free vbufs in case we can't queue them.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_display.c | 1 -
drivers/gpu/drm/virtio/virtgpu_drv.
The PWM backlight still supports passing a enable GPIO line as
platform data using the legacy API.
It turns out that ever board using this mechanism except one
is pass .enable_gpio = -1. So we drop all these cargo-culted -1's
from all instances of this platform data in the kernel.
The remaning b
The code in the Corgi backlight driver can be considerably
simplified by moving to GPIO descriptors and lookup tables
from the board files instead of passing GPIO numbers using
the old API.
Make sure to encode inversion semantics for the Akita and
Spitz platforms inside the GPIO lookup table and d
Hi Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.6-rc1 next-20200210]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '-
Hi
Am 07.02.20 um 20:50 schrieb Alex Deucher:
> These are deprecated and the drm will soon start warning when drivers still
> use them. It was a long and twisty road, but seems to work.
>
> v2: Add additional patch (13/15) which should fix the crash reported by
> Thomas Zimmermann.
> v3: Fix dp
On Sun, Jan 12, 2020 at 6:15 PM Geert Uytterhoeven wrote:
> Replace the call to the custom non-existing function by a standard
> BUILD_BUG() invocation.
>
> Suggested-by: Masahiro Yamada
> Signed-off-by: Geert Uytterhoeven
Thanks, applied and queued for v5.7.
Gr{oetje,eeting}s,
On 07/02/2020 05:26, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
>
> We extend the framework in a generic manner so that we could
> support more than 2 regulators, if required.
>
> Signed-off-by:
Reorder calls in qxl_device_fini(). Cleaning up gem & ttm
might trigger qxl commands, so we should do that before
releaseing command rings.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_kms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/
Move final cleanups to qxl_drm_release() callback.
Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv
Gerd Hoffmann (2):
drm/qxl: reorder calls in qxl_device_fini().
drm/qxl: add drm_driver.release callback.
drivers/gpu/drm/qxl/qxl_drv.c | 26 +++---
drivers/gpu/drm/qxl/qxl_kms.c | 8
2 files changed, 23 insertions(+), 11 deletions(-)
--
2.18.1
On 07/02/2020 05:26, Nicolas Boichat wrote:
> When there is a single power domain per device, the core will
> ensure the power domain is switched on (so it is technically
> equivalent to having not power domain specified at all).
>
> However, when there are multiple domains, as in MT8183 Bifrost
>
On Mon, Feb 10, 2020 at 11:15:04AM +0100, Linus Walleij wrote:
> The code in the Corgi backlight driver can be considerably
> simplified by moving to GPIO descriptors and lookup tables
> from the board files instead of passing GPIO numbers using
> the old API.
>
> Make sure to encode inversion sem
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #1 from Marco (rodomar...@protonmail.com) ---
Just tested under 5.5.2 stock kernel (besides ZFS module) and the same problem
show up. Log attached.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #2 from Marco (rodomar...@protonmail.com) ---
Created attachment 287275
--> https://bugzilla.kernel.org/attachment.cgi?id=287275&action=edit
amdgpu crash with stock kernel
--
You are receiving this mail because:
You are watching th
On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> On 07/02/2020 20:45, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:18, Jyri Sarha wrote:
> >>> The old implementation of placing planes on the CRTC while configuring
> >>> the
On Fri, Feb 07, 2020 at 01:26:24PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
Reviwed-by: Mark Brown
signature.asc
Description: PGP signature
__
On Mon, Feb 10, 2020 at 11:15:46AM +0100, Linus Walleij wrote:
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted -1'
On Sun, Feb 9, 2020 at 9:53 PM CK Hu wrote:
>
> Hi, Evan:
>
> On Fri, 2020-02-07 at 16:34 +0800, CK Hu wrote:
> > Hi, Evan:
> >
> > On Fri, 2020-02-07 at 15:23 +1100, Evan Benn wrote:
> > > The cursor and primary planes were hard coded.
> > > Now search for them for passing to drm_crtc_init_with_p
On Mon, 10 Feb 2020 at 11:15, Linus Walleij wrote:
>
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted -1's
> from a
On Mon, Feb 10, 2020 at 10:38:01AM +0100, Gerd Hoffmann wrote:
> Call drm_dev_unregister() first in bochs_pci_remove(). Hook
> bochs_unload() into the new .release callback, to make sure cleanup
> is done when all users are gone.
>
> Add ready bool to state struct and move bochs_hw_fini() call fr
On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
> Move final cleanups to qxl_drm_release() callback.
> Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 26 +++---
> 1 file change
This allows it to call the function without the lock held.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1104c8857b7..e12fc2c2d165 1
Ghost BOs need to stick with the resv object only when the origin is imported.
This is a low hanging fruit to avoid OOM situations on evictions.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/d
This series of patches cleans up TTMs delayed delete handling.
The core of the new handling is that we new only have a single reference
counter instead of two and use kref_get_unless_zero() to grab BOs from the LRU
during eviction.
This reduces the overhead of LRU moves and allows us to properl
This allows release_notify to add and remove fences from deleted objects.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4d16103
This patch reworks the whole delayed deletion of BOs which aren't idle.
Instead of having two counters for the BO structure we resurrect the BO
when we find that a deleted BO is not idle yet.
This has many advantages, especially that we don't need to
increment/decrement the BOs reference counter
The function is always called with deleted BOs.
While at it cleanup the indentation as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo
When non-imported BOs are resurrected for delayed delete we replace
the dma_resv object to allow for easy reclaiming of the resources.
v2: move that to ttm_bo_individualize_resv
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 +-
1 file changed, 9 insertions(+), 1 d
Hello there,
Source code is
unsigned int vsync_rate_hz = 0;
struct dc_static_screen_params params = {0};
/* Calculate number of static frames before generating interrupt to
* enter PSR.
*/
unsigned int frame_time_microsec = 100 / vsync_rate_hz;
Suggest code rework.
Commit f5a98bfe7b37 ("dt-bindings: display: Convert Allwinner display
pipeline to schemas") introduced a YAML schema for the Allwinner TCON DT
binding, but the H6 TCON-TV compatible was mistakenly set to fallback on
the A83t's, while the initial documentation and the DT are using R40's.
Fix that.
Hello there,
linux-5.6-rc1/drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c:33:33:
error: Buffer is accessed out of bounds: hdcp->auth.msg.hdcp1.bksv
[bufferAccessOutOfBounds]
Source code is
memcpy(&n, hdcp->auth.msg.hdcp1.bksv, sizeof(uint64_t));
Field bksv is only five bytes lo
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
In function dcn10_post_unlock_program_front_end:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2623:29:
warning: variable stream_status set but not used [-Wunused-but-set-variable]
commit bbf5f6c3f83b ("dr
Hi Dave, Daniel,
Now that -rc1 is out, here's the first drm-misc-next PR. All things
considered it's been pretty quiet, the diffstat being scary mostly
because of the conversion of device tree bindings to YAML and a new
driver.
Maxime
drm-misc-next-2020-02-10:
drm-misc-next for 5.7:
UAPI Change
On 10/02/2020 15:21, Ville Syrjälä wrote:
> On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
>> On 07/02/2020 20:45, Ville Syrjälä wrote:
>>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
On 07/02/2020 20:18, Jyri Sarha wrote:
> The old implementation of placing pl
On Mon, Feb 10, 2020 at 05:44:19PM +0200, Jyri Sarha wrote:
> On 10/02/2020 15:21, Ville Syrjälä wrote:
> > On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:45, Ville Syrjälä wrote:
> >>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> On 07/02/20
https://bugzilla.kernel.org/show_bug.cgi?id=205169
--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
Patch has been upstream for a while:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e29be9e0bbbf9cb3d718c5c48382b1420ce0749
--
You are receiving this m
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #3 from Marco (rodomar...@protonmail.com) ---
Same thing with linux-amd-drm-next, dmesg attached. Any pointers to the cause?
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #4 from Marco (rodomar...@protonmail.com) ---
Created attachment 287277
--> https://bugzilla.kernel.org/attachment.cgi?id=287277&action=edit
dmesg for amd-drm-next
--
You are receiving this mail because:
You are watching the assign
Lucas - Ping on my question and also I attached this temporary solution
for etnaviv to clarify my point. If that something acceptable for now at
least i can do the same for v3d where it requires a bit more code changes.
Andrey
On 2/6/20 10:49 AM, Andrey Grodzovsky wrote:
Well a revert would b
Den 10.02.2020 16.06, skrev Daniel Vetter:
> On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
>> Move final cleanups to qxl_drm_release() callback.
>> Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
>>
>> Signed-off-by: Gerd Hoffmann
>> ---
>> drivers/gpu/drm/qxl/qxl_d
(adding back Daniel)
Den 10.02.2020 17.57, skrev Noralf Trønnes:
>
>
> Den 10.02.2020 16.06, skrev Daniel Vetter:
>> On Mon, Feb 10, 2020 at 12:37:52PM +0100, Gerd Hoffmann wrote:
>>> Move final cleanups to qxl_drm_release() callback.
>>> Add drm_atomic_helper_shutdown() call to qxl_pci_remove()
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpac
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().
While computing, we'll also fill out the infoframes.enable bitmask
appropriately.
v2: Wrap a long line.
v4: Use struct drm_device logging macros
v5: Fix typo [Uma]
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
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
In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.
And it stores computed dp vsc sdp to infoframes.
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
It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.
enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
And
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
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to pack DP HDR Metadata In
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
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_
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
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
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
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
1 - 100 of 152 matches
Mail list logo
