On Fri, Sep 20, 2019 at 9:11 AM Dave Airlie wrote:
>
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 4bb6a9d5d9a8289673c4cb0786d44be8a63c21db
commit: 1af22383829864299102ca0c2eab458f755a9971 [5/7] drm/i915/display:
Extract i9xx_read_luts()
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
host at probe time") landed in -next the HiKey board would fail
to boot, looping:
adv7511 2-0039: failed to find dsi host
messages over and over. Andrzej Hajda suggested this is due to a
circular dependency issue, and that the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #53 from Sebastian Meyer ---
Just compiled the latest mainline kernel from a few hours ago with the merge of
drm-next-2019-09-18 and tried again.
Hi Artur,
On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds minor improvements to the exynos-bus driver.
>
> Signed-off-by: Artur Świgoń
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/devfreq/exynos-bus.c | 66 ++--
> 1
Hi guys,
I'd like to know the status of this patch? I expect a v2 adding some
comments/macros about the high bit plan would be enough?
@Raymond & @Brian do you still need another long process to send out a
v2 patch? If so, I can help to prepare a v2 patch according to your
previous mail.
Hi,
As I already replied on v1, patch1/2/3 clean-up code
for readability without any behavior changes.
I think that you better to merge patch1/2/3 to one patch.
On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds a new static function,
Hi Artur,
I tried to just build this patch on mainline kernel or linux-next.
But, when I applied them, merge conflict happens. You didn't develop
them on latest version. Please rebase them based on latest mainline kernel.
On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote:
> Hi Artur,
>
> On v1, I
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Christopher Snowhill (kod...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #29 from Brian Schott ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #28)
>
> Could you test this commit
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2016/
>
Hi Artur,
On v1, I mentioned that we need to discuss how to change
the v2 for this. But, I have not received any reply from you on v1.
And, without your reply from v1, you just send v2.
I think that it is not proper development sequence.
I have spent many times to review your patches
and also
https://bugs.freedesktop.org/show_bug.cgi?id=111234
--- Comment #4 from jamespharve...@gmail.com ---
Just ran into this for my first time. I've had pretty consistent problems with
the potentially related bug that Nicholas Kazlauskas mentioned at
https://bugzilla.kernel.org/show_bug.cgi?id=204181
> Hmm. My merge isn't identical to that. It's close though. Different
> order for one #define which might be just from you and me merging
> different directions.
>
> But I also ended up removing the .gem_prime_export initialization to
> drm_gem_prime_export, because it's the default if none
This still needs to be moved into an atomic helper so it can be reused by
other drivers
...
...
however, I've had this patch series on my mind for a while and something
occurred to me that would be a lot easier. Why exactly are we not just
enabling DSC wherever it's supported, regardless of
Reviewed-by: Lyude Paul
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: David Francis
>
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This
Great work!
Reviewed-by: Lyude Paul
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: David Francis
>
> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
> support virtual DPCD registers, but do support DSC.
> The DSC caps can be read from the physical aux,
> like in SST
This also needs to be squashed into the previous two patches. There's no point
in using drm_dp_atomic_find_vcpi_slots() or drm_dp_atomic_release_vcpi_slots()
without drm_dp_mst_atomic_check(), since the VCPI allocations setup by the two
functions aren't validated until then.
On Wed, 2019-09-18 at
The pull request you sent on Fri, 20 Sep 2019 05:08:55 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-09-18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/574cc4539762561d96b456dbc0544d8898bd4c6e
Thank you!
--
Deet-doot-dot, I am a bot.
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Complying with new MST atomic check requirements.
> The driver needs to call this function on every
> atomic check to reset the VCPI slots if new state
> disables
> [how]
> - Verify that it is a MST
On Thu, Sep 19, 2019 at 12:09 PM Dave Airlie wrote:
>
> There are a few merge conflicts across the board, we have a shared
> rerere cache which meant I hadn't noticed them until I avoided the
> cache.
> https://cgit.freedesktop.org/drm/drm/log/?h=drm-5.4-merge
> contains what we've done, none of
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: a51a5ad4b8daf0dd0a437d51a19c2baa98953675
commit: a5784d79d1577c00e6e81f892cde52593546a5f4 [3698/3724] drm/amdkcl: drop
kcl_dma_fence_set_error
reproduce:
# apt-get install sparse
# sparse version:
Ok, so reviewing this is kind of difficult because this series doesn't apply
to drm-tip, and also doesn't make any mention of what branch it's supposed to
apply to. So there's no way for me to apply any of these changes in my tree to
get an idea of how things look overall with these patches
On Wed, Aug 28, 2019 at 2:51 PM Raul E Rangel wrote:
>
> dcn20_resource.c:2636:9: error: missing braces around initializer
> [-Werror=missing-braces]
> struct _vcs_dpi_voltage_scaling_st
> calculated_states[MAX_CLOCK_LIMIT_STATES] = {0};
> ^
> Fixes: 7ed4e6352c16f ("drm/amd/display:
https://bugs.freedesktop.org/show_bug.cgi?id=111691
Michael Haworth changed:
What|Removed |Added
Summary|hardware cursor corruption |inconsistent cursor
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #14 from Mirek Kratochvil (exa@gmail.com) ---
Created attachment 285069
--> https://bugzilla.kernel.org/attachment.cgi?id=285069=edit
syslog from 5.2.16 with warnings
--
You are receiving this mail because:
You are watching
Dne četrtek, 19. september 2019 ob 22:03:26 CEST je Roman Stratiienko
napisal(a):
> Hello guys,
>
> Actually, I beleive this is True solution, and current one is wrong. Let
> me explain why.
>
> De2. 0 was designed to match Android hwcomposer hal requirements IMO.
> You can easily agree with
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #13 from Mirek Kratochvil (exa@gmail.com) ---
After the BIOS upgrade the kernel parameters can be removed, but the kernel
(5.2.16) now locks up when entering XFCE (it survives lightdm though). The
error is almost same as as in the
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #10 from Michael Haworth ---
issue occurs with the closed source drivers too, on kernel 4.15 (linux mint
19.2) but to a much lesser extent
--
You are receiving this mail because:
You are the assignee for the
On 2019-09-18 12:30 p.m., Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=111633
--- Comment #1 from vakevk+freedesktopbugzi...@gmail.com ---
Another one, different stacktrace.
BUG: kernel NULL pointer dereference, address: 0360
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present
https://bugs.freedesktop.org/show_bug.cgi?id=111077
Matt Turner changed:
What|Removed |Added
CC|matts...@gmail.com |
--- Comment #44 from Matt Turner ---
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #52 from Matthias Müller ---
Comment on attachment 145436
--> https://bugs.freedesktop.org/attachment.cgi?id=145436
Log of divide error
i just encountered a "random" freeze, too.
And because it seems to be something "new", i
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #51 from Matthias Müller ---
Created attachment 145436
--> https://bugs.freedesktop.org/attachment.cgi?id=145436=edit
Log of divide error
--
You are receiving this mail because:
You are the assignee for the
Iago Toral Quiroga writes:
> Extends the user space ioctl for CL submissions so it can include a request
> to flush the cache once the CL execution has completed. Fixes memory
> write violation messages reported by the kernel in workloads involving
> shader memory writes (SSBOs, shader images,
As between HDMI and DP have different colorspaces, in order to distinguish
colorspace of DP and HDMI, it renames drm_mode_create_colorspace_property()
function to drm_mode_create_hdmi_colorspace_property() function for HDMI
connector.
In order to apply changed drm api, i915 driver has channged.
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe
Because between HDMI and DP have different colorspaces, it adds
drm_mode_create_dp_colorspace_property() function for creating of DP
colorspace property.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. In order to handle colorspace of
drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings()
function into intel_ddi_pre_enable_dp(). And it also rename
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
And in order to distinguish colorspace bwtween DP and HDMI connector, it
adds a handling of drm_mode_create_dp_colorspace_property() to
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it
On Wed, 2019-09-18 at 17:13 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:49AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles
> > Infoframe SDP
> > header and data block setup for HDR Static Metadata. It enables
> > writing of
> > HDR
On Wed, 2019-09-18 at 17:08 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:46AM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property()
On Wed, 2019-09-18 at 17:15 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:45AM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct
On Thu, Sep 19, 2019 at 7:30 PM Maxime Ripard wrote:
>
> The newer Allwinner SoCs have a different layers controller than the older
> ones. Jernej wrote that support and has been reviewing patches for a while
> now, so let's make him a formal reviewer.
>
> Signed-off-by: Maxime Ripard
Haz
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #30 from Gabriel C ---
(In reply to Gabriel C from comment #29)
> Michael,
>
> I see the same on a Ryzen 7 35750H APU + RX 560x Nitro5 Laptop.
It is 3750H :-)
--
You are receiving this mail because:
You are the assignee for the
On Thu, Sep 19, 2019 at 7:36 PM Chen-Yu Tsai wrote:
>
> On Fri, Sep 20, 2019 at 1:30 AM Maxime Ripard wrote:
> >
> > The DRM drivers are more than about the A10 now, so let's make the entry
> > name a bit more generic.
> >
> > Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #29 from Gabriel C ---
Michael,
I see the same on a Ryzen 7 35750H APU + RX 560x Nitro5 Laptop.
reverting
https://github.com/freedesktop/xorg-xf86-video-amdgpu/commit/a2b32e72fdaff3007a79b84929997d8176c2d512
fixes the problem for
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: a51a5ad4b8daf0dd0a437d51a19c2baa98953675
commit: 5165cd1453625e59650a1ed9b0f269b41529e421 [3711/3724] Revert "Revert
"drm/amd/autoconf: Test whether vm_fault->{address/vma} is available""
config:
Hi!
Dne sreda, 18. september 2019 ob 13:05:41 CEST je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> According to Allwinner DE2.0 Specification REV 1.0, vi layer supports the
> following pixel formats: ABGR_, ARGB_, BGRA_, RGBA_
It's true that DE2
On Wed, Sep 18, 2019 at 01:42:09PM +, Lisovskiy, Stanislav wrote:
> On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Allow drivers to call drm_atomic_helper_check_modeset() without
> > having the crtc helper funcs specified. i915 doesn't need those
> >
Dne četrtek, 19. september 2019 ob 19:17:54 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 19, 2019 at 03:37:03PM +0300, roman.stratiie...@globallogic.com
wrote:
> > From: Roman Stratiienko
> >
> > DE2.0 blender does not take into the account alpha channel of vi layer.
> > Thus makes
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #20 from vlad@ivanov.email ---
Still seeing the warning with 5.4.0-0.rc0.git2.2.fc32.x86_64; waking up doesn't
work. This is fedora kernel though and there's a possibility those patches
aren't integrated there yet; is there a way to
On Thu, Sep 19, 2019 at 10:03 AM yu kuai wrote:
>
> Fixes gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:431: warning: Excess function
> parameter 'sw' description in 'vcn_v2_5_disable_clock_gating'
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:550: warning: Excess function
> parameter 'sw'
Hi Andrzej,
thanks for your comments!
On Thu, Sep 19, 2019 at 03:56:45PM +0200, Andrzej Hajda wrote:
> On 14.09.2019 18:11, Guido Günther wrote:
> > Hi Andrzej,
> > thanks for having a look!
> >
> > On Fri, Sep 13, 2019 at 11:31:43AM +0200, Andrzej Hajda wrote:
> >> On 09.09.2019 04:25, Guido
On Fri, Sep 20, 2019 at 1:30 AM Maxime Ripard wrote:
>
> The DRM drivers are more than about the A10 now, so let's make the entry
> name a bit more generic.
>
> Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a
> while, is a maintainer of the Allwinner platform for an even
The newer Allwinner SoCs have a different layers controller than the older
ones. Jernej wrote that support and has been reviewing patches for a while
now, so let's make him a formal reviewer.
Signed-off-by: Maxime Ripard
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git
The DRM drivers are more than about the A10 now, so let's make the entry
name a bit more generic.
Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a
while, is a maintainer of the Allwinner platform for an even longer time,
and has drm-misc commit access. Let's make it formal
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #43 from rol...@rptd.ch ---
Sorry, but this is rude. I waited for an answer on my result of testing the
patch (as requested) and that's what I get as answer? I can continue trying to
find a reproducible task but then please say that
Hi,
On Thu, Sep 19, 2019 at 03:37:03PM +0300, roman.stratiie...@globallogic.com
wrote:
> From: Roman Stratiienko
>
> DE2.0 blender does not take into the account alpha channel of vi layer.
> Thus makes overlaying of this layer totally opaque.
> Using vi layer as bottom solves this issue.
>
>
On 2019-09-18 6:31 p.m., Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On Mon, Sep 9, 2019 at 11:22 AM Steven Price wrote:
>
> On 09/09/2019 16:41, Rob Herring wrote:
> > On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
> >>
> >> On 04/09/2019 13:30, Mark Brown wrote:
> >>> The panfrost driver requests a supply using regulator_get_optional()
> >>> but both the
On Fri, Sep 13, 2019 at 11:03 AM Steven Price wrote:
>
> When handling a GPU page fault addr_to_drm_mm_node() is used to
> translate the GPU address to a buffer object. However it is possible for
> the buffer object to be freed after the function has returned resulting
> in a use-after-free of
Hello Christoph, everyone,
On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
>
> Here is yet another pass at the dma-buf heaps patchset Andrew
> and I have been working on which tries to destage a fair chunk
> of ION functionality.
>
> The patchset implements per-heap devices which can be opened
>
On Thu, Sep 19, 2019 at 9:45 AM Harry Wentland wrote:
>
> On 2019-09-18 3:53 p.m., Arnd Bergmann wrote:
> > Without CONFIG_DEBUG_FS, we get a warning for an unused
> > variable:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error:
> > unused variable 'source'
Am 19.09.19 um 16:28 schrieb Sven Van Asbroeck:
> Hi Christian,
>
> On Thu, Sep 19, 2019 at 4:05 AM Koenig, Christian
> wrote:
>>> +out4:
>>> + kfree(i2s_pdata);
>>> +out3:
>>> + kfree(adev->acp.acp_res);
>>> +out2:
>>> + kfree(adev->acp.acp_cell);
>>> +out1:
>>> +
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-09-19 16:28:41)
> > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson
> > wrote:
> > >
> > > It is expected that processes will pass dma-buf fd between drivers, and
> > > only using the fd themselves for mmaping and
Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
in __lock_release"), @nested is no longer used in lock_release(), so
remove it from all lock_release() calls and friends.
Signed-off-by: Qian Cai
---
drivers/gpu/drm/drm_connector.c | 2 +-
Quoting Daniel Vetter (2019-09-19 16:28:41)
> On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
> >
> > It is expected that processes will pass dma-buf fd between drivers, and
> > only using the fd themselves for mmaping and synchronisation ioctls.
> > However, it may be convenient for an
On Wed, Sep 18, 2019 at 8:04 AM Liviu Dudau wrote:
>
> On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > Hi all,
>
> Hi,
>
> >
> > On Tue, 17 Sep 2019 at 13:53, Daniel Vetter wrote:
> > > On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> > > > Let us ignore how the
Hi Dave, Daniel,
A few fixes for 5.4.
The following changes since commit 945b584c94f8c665b2df3834a8a6a8faf256cd5f:
Merge branch 'linux-5.4' of git://github.com/skeggsb/linux into drm-next
(2019-09-17 16:31:34 +1000)
are available in the Git repository at:
On Thu, Sep 19, 2019 at 11:33:58AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds a debugfs entry to surface the entry and exit times as
> well as the calculated delay.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
> Link to v2:
>
From: Sean Paul
This patch adds a debugfs entry to surface the entry and exit times as
well as the calculated delay.
Suggested-by: Daniel Vetter
Signed-off-by: Sean Paul
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-3-s...@poorly.run
Changes in v2:
- Added
On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
>
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance
On Thu, Sep 19, 2019 at 04:10:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder wrote:
> >
> > On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
> >
> > Hi All,
> > Thanks for your suggestions.
> >
> > > Hi Liviu,
> > >
> > > On Wed, 18 Sep 2019 at 13:04,
It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface.
Hi!
Dne četrtek, 19. september 2019 ob 15:54:49 CEST je Cheng-Yi Chiang
napisal(a):
> Use two dai_links. One for HDMI and one for max98090.
> With this setup, audio can play to speaker and HDMI selectively.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
>
On Thu, Sep 05, 2019 at 12:41:27PM +0200, Daniel Vetter wrote:
> On Wed, Sep 4, 2019 at 10:29 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Since the dirtyfb ioctl doesn't give us any hints as to which plane is
> > scanning out the fb it's marking as damaged, we need to loop through
> >
From: Markus Elfring
Date: Thu, 19 Sep 2019 16:51:38 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/pxafb.c | 10 +-
1 file changed, 1
On Wed, Sep 18, 2019 at 09:57:07PM +0200, Arnd Bergmann wrote:
> Without this header file, compile-testing may run into a missing
> declaration:
>
> drivers/gpu/drm/msm/msm_gpu.c:444:4: error: implicit declaration of function
> 'put_task_struct' [-Werror,-Wimplicit-function-declaration]
>
>
On Thursday, 19 September 2019 14:30:02 BST Mihail Atanassov wrote:
> When initially turning a crtc on, drm_reset_vblank_timestamp will
> set the vblank timestamp to 0 for any driver that doesn't provide
> a ->get_vblank_timestamp() hook.
>
> Unfortunately, the FLIP_COMPLETE event depends on that
From: Markus Elfring
Date: Thu, 19 Sep 2019 16:26:56 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/ocfb.c | 9 +
1 file changed, 1
The following patchset adds interconnect[1][2] framework support to the
exynos-bus devfreq driver. Extending the devfreq driver with interconnect
capabilities started as a response to the issue referenced in [3]. The
patches can be subdivided into four logical groups:
(a) Refactoring the existing
From: Marek Szyprowski
This patch adds interconnect support to exynos-mixer. Please note that the
mixer works the same as before when CONFIG_INTERCONNECT is 'n'.
Co-developed-by: Artur Świgoń
Signed-off-by: Marek Szyprowski
Signed-off-by: Artur Świgoń
---
From: Artur Świgoń
The exynos-bus devfreq driver is extended with interconnect functionality
by a subsequent patch. This patch removes a check from the interconnect
framework that prevents interconnect from working on exynos-bus, in which
every bus is a separate interconnect provider.
From: Artur Świgoń
This patch improves code readability by changing the following construct:
>if (cond)
>goto passive;
>foo();
>goto out;
>passive:
>bar();
>out:
into this:
>if (cond)
>bar();
>else
>foo();
Signed-off-by: Artur Świgoń
---
From: Ville Syrjälä
Dump out the plane/crtc id/name in the failure debug messages.
Makes a bit easier to figure out which plane exactly has failed
when you have tons of them.
Cc: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
1 file changed, 7
From: Ville Syrjälä
When the calculate scaling factors are out of range let's
print out the calculated value and the min/max. Should make
life a bit less confusing when decoding failure logs.
I decided to print them in decimal rather than hex. Not sure
which people prefer but maybe this is less
From: Ville Syrjälä
We may want to dump out the calculated scaling factor(s) when
they exceed the limits. To achieve that we need to return the
error code and scaling factor separately.
Side note: the code in dpu_plane_validate_multirect_v2()
looks rather dubious on account of it not using
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2019-09-19:
- Extend old HSW workaround to fix some GPU hangs on Haswell GT2
- Fix return error code on GEM mmap.
- White list a chicken bit register for push constants legacy mode on Mesa
- Fix resume issue related to GGTT restore
- Remove
On Wed, Sep 18, 2019 at 04:07:29PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Currently the self refresh idle timer is a const set by the crtc. This
> is fine if the self refresh entry/exit times are well-known for all
> panels used on that crtc. However panels and workloads can vary quite a
On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder wrote:
>
> On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
>
> Hi All,
> Thanks for your suggestions.
>
> > Hi Liviu,
> >
> > On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone
On Thu, 19 Sep 2019, Gerd Hoffmann wrote:
> There is little reason for the from/to logic, printing a subset of
> the bits can be done by simply shifting/masking value if needed.
>
> Also use for_each_set_bit().
Oh, I don't know why I stumbled upon and reviewed a patch that had
already been
The scheduler uses a (currently private) fixed_power_int() in its load
average computation for computing powers of numbers 0 < x < 1
expressed as fixed-point numbers, which is also what we want here. But
that requires the scale to be a power-of-2.
We could (and a following patch will) change to
lightness*1000 is nowhere near overflowing 32 bits, so we can just use
an ordinary 32/32 division, which is much cheaper than the 64/32 done
via do_div().
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The "break-even" point for the two formulas is L==8, which is also
what the code actually implements. [Incidentally, at that point one
has Y=0.008856, not 0.08856].
Moreover, all the sources I can find say the linear factor is 903.3
rather than 902.3, which makes sense since then the formulas
On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
Hi All,
Thanks for your suggestions.
> Hi Liviu,
>
> On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > I totally agree. Framebuffers aren't about the underlying
Hi
Am 19.09.19 um 14:53 schrieb Rohan Garg:
> DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
>
> Changes in v2:
> - Hoist the IOCTL up into the drm_driver framework
>
> Signed-off-by: Rohan Garg
> ---
>
1 - 100 of 178 matches
Mail list logo
