Hi Linus,
A varied bunch of fixes, one for an API regression with connectors,
otherwise amdgpu and i915 have
a bunch of varied fixes, the shrinker ones being the most important.
Dave.
The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52:
Linux 4.12-rc6 (2017-06-19 22:19
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #3 from Nick Sarnie ---
As a final piece of information, if I compile LLVM with asserts enabled, I get
the following assert
mpv:
/var/tmp/portage/sys-devel/llvm-/work/llvm-/lib/Target/AMDGPU/SIPeepholeSDWA.cpp:719:
bool {ano
https://bugs.freedesktop.org/show_bug.cgi?id=101222
--- Comment #8 from Mikko Autio ---
(In reply to Harry Wentland from comment #5)
> Thanks, Mikko. Looks good. Do you want to send a patch to amd-gfx? If not
> I'll create a patch with description and title for it.
I'll let you think of a descri
https://bugs.freedesktop.org/show_bug.cgi?id=101222
--- Comment #7 from Mikko Autio ---
(In reply to James Le Cuirot from comment #6)
> (In reply to Mikko Autio from comment #4)
> > Attached patch fixes multi-channel HDMI audio on my RX 460.
>
> I was about to shower you with praise but sadly th
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #2 from Nick Sarnie ---
Created attachment 132152
--> https://bugs.freedesktop.org/attachment.cgi?id=132152&action=edit
bad R600_DEBUG=fs,vs,gs,ps,cs
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #1 from Nick Sarnie ---
Created attachment 132151
--> https://bugs.freedesktop.org/attachment.cgi?id=132151&action=edit
good R600_DEBUG=fs,vs,gs,ps,cs
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101561
Bug ID: 101561
Summary: [bisected] [llvm] Blue color shift on videos in MPV
when using vo=opengl[-hq]
Product: Mesa
Version: git
Hardware: Other
OS: All
On 22/06/17 11:45 PM, Eric Engestrom wrote:
> On Thursday, 2017-06-22 10:42:21 +0900, Michel Dänzer wrote:
>>
>> Also, there are downsides to exposing library API calls as inline
>> functions: E.g. if drmIoctl(2) ever needs a change (worst case a
>> security bug fix), every user has to be recompile
On 2017-06-21 20:28, Daniel Vetter wrote:
> Like with panning and modesetting, and like with those, stick with
> simple drm_modeset_locking_all for the legacy path, and the full
> atomic dance for atomic drivers.
>
> This means a bit more boilerplate since setting up the atomic state
> machinery i
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24 -
Hi,
Presently, the 64bit IO functions are not very usable in drivers because
they are not universally available in all architectures. This leads to
a bunch of hacks in the kernel to work around this. (See the last 3
patches in this series.) As part of my switchtec_ntb submission which
added anothe
Drivers no longer have any need for these callbacks, and there are no
users. Zap. Zap-zap-zzzap-p-pp-p.
Signed-off-by: Peter Rosin
---
include/drm/drm_fb_helper.h | 32
include/drm/drm_modeset_helper_vtables.h | 16
2 files changed,
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 -
Thanks for Heiko's review and Rob's Ack.
Seems no more confuse, pushed to drm-misc-next.
Thanks.
On 2017年06月09日 15:10, Mark Yao wrote:
RK3399 and RK3288 shared the same HDMI IP controller, only some
light difference with GRF configure, and an external VPLL clock
need to configure.
base on Yak
Hi!
While trying to get CLUT support for the atmel_hlcdc driver, and
specifically for the emulated fbdev interface, I received some
push-back that my feeble in-driver attempts should be solved
by the core. This is my attempt to do it right.
I have obviously not tested all of this with more than a
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 27 +++
1 file chan
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
totally obsolete.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 154
1 file changed, 63 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.
On 2017-06-22 08:36, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote:
>> On 2017-06-21 09:38, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
t
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.
All layers of all supported chips support this, the only variable is the
base address of the lookup table in the register map.
Acked-by: Daniel Vetter
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 14 +
On 06/21/2017 10:28 AM, Daniel Vetter wrote:
> Almost right but still racy, it's called before the interrupts are
> uninstalled. So let's just drop it.
>
> Cc: Marek Vasut
> Signed-off-by: Daniel Vetter
Reviewed-by: Marek Vasut
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
> 1 file change
Now that ioread64 and iowrite64 are always available we don't
need the ugly ifdefs to change their implementation when they
are not.
Signed-off-by: Logan Gunthorpe
Cc: "Horia Geantă"
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
---
drivers/crypto/caam/regs.h | 29 ---
On 6/22/2017 2:36 PM, Alan Cox wrote:
I think that makes sense for the platforms with that problem. I'm not
sure there are many that can't do it for mmio at least. 486SX can't do it
and I guess some ARM32 but I think almost everyone else can including
most 32bit x86.
What's more of a problem is
Currently, ioread64 and iowrite64 are not impleminted in the generic
iomap implementation. The prototypes are defined if CONFIG_64BIT is set
but there is no actual implementation.
Seeing the functions are not universally available, they are unusable
for driver developers. This leads to ugly hacks
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/
This is a prep patch for adding a universal iowrite64.
The patch is to prevent compiler warnings when we add iowrite64 that
would occur because there is an unnecessary volatile in this driver.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu/d
Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
universally available, it makes them unusable for driver developers.
This leads to ugly hacks such as those at the top of
drivers/ntb/hw/intel/ntb_hw_intel.c
This
On 6/22/2017 11:29 AM, Stephen Bates wrote:
+#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
Logan, thanks for taking this cleanup on. I think this should be iowrite64 not
iowrite32?
Yup, good catch. Thanks. I'll fix it in a v2 of this series.
Logan
___
Now that ioread64 and iowrite64 are available generically we can
remove the hack at the top of ntb_hw_intel.c that patches them in
when they are not available.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
---
drivers/ntb/hw/intel/ntb_hw_intel.c | 30
The redundant fb helpers .gamma_set and .gamma_get are no longer
used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/gma500/framebuffer.c | 22 --
On 06/22/2017 09:48 AM, Logan Gunthorpe wrote:
Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.
For this, we simply use calls that chain two 32-bit operations.
(mostly becaus
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
totally obsolete.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 151 +---
1 file changed, 63 insertions(+), 88 deletions(-)
This is an alternative version rebased on t
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 27 +++
1 file chan
Now that we can expect iowrite64 to always exist the hack is no longer
necessary so we just call iowrite64 directly.
Signed-off-by: Logan Gunthorpe
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: David Airlie
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
1 file changed, 6 deletions(-)
diff --gi
Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.
For this, we simply use calls that chain two 32-bit operations.
(mostly because I don't really understand the alpha architectur
Add heuristic to decide that AUX or PWM pin should use for
backlight brightness adjustment and modify i915 param description
to have auto, force disable, and force enable.
The heuristic to determine that using AUX pin is better than using
PWM pin is that the panel support any of the feature list h
On 6/22/2017 2:14 PM, Alan Cox wrote:
If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.
Yes, I understand that.
The thing is that every user that's currently
On 22/06/2017 at 07:03, Peter Rosin wrote:
> Hi!
>
> This series adds support for an 8-bit clut mode in the atmel-hlcdc
> driver.
>
> Changes since v4:
>
> - Added .clut_offset for overlay2 at 0xe00 for sama5d4 (unconfirmed if 0xe00
> is the correct offset, but I'll eat my hat if it's not ther
The redundant fb helper .load_lut is no longer used, and can not
work right without also providing the fb helpers .gamma_set and
.gamma_get thus rendering the code in this driver suspect.
Just remove the dead code.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/stm/ltdc.c | 12
dri
On 6/22/2017 2:08 PM, Alan Cox wrote:
But this does not do the same thing as an ioread64 with regards to
atomicity or side effects on the device. The same is true of the other
hacks. You either have a real 64bit single read/write from MMIO space or
you don't. You can't fake it.
Yes, I know. But
This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Signed-off-by: Puthikorn Voravootivat
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/i915_params
The default implementation should be used.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..cc00ce3 100
Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.
Signed-off-by: Puthikorn V
The redundant fb helpers .gamma_set and .gamma_get are no longer used.
Remove the dead code.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/armada/armada_crtc.c | 10 --
drivers/gpu/drm/armada/armada_crtc.h | 2 --
drivers/gpu/drm/armada/armada_fbdev.c | 2 --
3 files changed, 14 del
On 6/22/2017 3:03 PM, Arnd Bergmann wrote:
Drivers that want a non-atomic variant should include either
include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h
depending on what they need. Drivers that require 64-bit I/O should
probably just depend on CONFIG_64BIT and maybe
drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
now always kept up to date by drm_fb_helper_setcmap.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_fb_helper.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers
This patch set contain 3 patches which are already reviewed by DK.
Another 6 patches in previous version was already merged in v7 and v9.
- First patch sets the PWM freqency to match data in panel vbt.
- Next patch adds heuristic to determine whether we should use AUX
or PWM pin to adjust panel b
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 8
dr
Hi!
This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.
Changes since v4:
- Added .clut_offset for overlay2 at 0xe00 for sama5d4 (unconfirmed if 0xe00
is the correct offset, but I'll eat my hat if it's not there). The sama5d4
overlay2 is indeed there, it is just AWOL i
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 5 ---
dr
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++
https://bugzilla.kernel.org/show_bug.cgi?id=196117
--- Comment #5 from Paul K. Gerke (paulkge...@craftware.nl) ---
I finally found some time to test some other kernel versions. Instead of the
suggested 4.10.5 kernel from the link posted above, I tried kernel 4.10.0-rc5+.
The errors are *different*
Hi all,
On Wed, 21 Jun 2017 15:32:39 +0200 Marek Szyprowski
wrote:
>
> On 2017-06-20 15:16, Christoph Hellwig wrote:
> > On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
> >> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
> >>
> >> Contacts: Mar
https://bugs.freedesktop.org/show_bug.cgi?id=101222
--- Comment #6 from James Le Cuirot ---
(In reply to Mikko Autio from comment #4)
> Attached patch fixes multi-channel HDMI audio on my RX 460.
I was about to shower you with praise but sadly that patch made no difference
here. :(
--
You are
On Thu, Jun 22, 2017 at 10:09 PM, Logan Gunthorpe wrote:
> On 6/22/2017 2:08 PM, Alan Cox wrote:
>>
>> But this does not do the same thing as an ioread64 with regards to
>> atomicity or side effects on the device. The same is true of the other
>> hacks. You either have a real 64bit single read/wri
On Thu, 22 Jun 2017 07:03:09 +0200
Peter Rosin wrote:
> Hi!
>
> This series adds support for an 8-bit clut mode in the atmel-hlcdc
> driver.
Applied to drm-misc-next.
Thanks,
Boris
>
> Changes since v4:
>
> - Added .clut_offset for overlay2 at 0xe00 for sama5d4 (unconfirmed if 0xe00
> is
On Thu, 22 Jun 2017 10:48:14 -0600
Logan Gunthorpe wrote:
> Alpha implements its own io operation and doesn't use the
> common library. Thus to make ioread64 and iowrite64 globally
> available we need to add implementations for alpha.
>
> For this, we simply use calls that chain two 32-bit opera
This has proven immensely useful for debugging memory leaks and
overallocation (which is a rather serious concern on the platform,
given that we typically run at about 256MB of CMA out of up to 1GB
total memory, with framebuffers that are about 8MB ecah).
The state of the art without this is to du
On Thu, Jun 22, 2017 at 4:28 PM, kbuild test robot
wrote:
>
> Signed-off-by: Fengguang Wu
Applied. thanks!
> ---
> gfx_v9_0.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> in
On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe wrote:
> On 6/22/2017 2:14 PM, Alan Cox wrote:
> > If a platform doesn't support 64bit I/O operations from the CPU then you
> > either need to use some kind of platform/architecture specific interface
> > if present or accept you don't have one.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 09c17284731e42dbe4c6d334603e9c05ba1219ae
commit: 18924c719e1d2b194f93ef757584b814421f22a5 [2278/9292] drm/amdgpu/gfx9:
allow updating gfx mgpg state
reproduce:
# apt-get install sparse
git c
Signed-off-by: Fengguang Wu
---
gfx_v9_0.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index a1e1b7aa..f2ae6f3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/
When we are enabling a CRTC, drm_crtc_vblank_get() is called before
drm_crtc_vblank_on(), which is not supposed to happen (hence the
WARN_ON() in the code). To solve the problem, we delay the 'update
display list' operation after the CRTC is actually enabled.
Signed-off-by: Boris Brezillon
---
d
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks suc
Hi Dave,
I was hoping I wouldn't have to send a pull this week, but alas, we have a
regression fix to broken userspace. The issue was that we were sending stale
property
values from GETCONNECTOR after probing modes. The patch grabs the property
values after probe to ensure everything is cohesive.
Daniel Vetter writes:
> On Wed, Jun 21, 2017 at 11:50:01AM -0700, Eric Anholt wrote:
>> Now that we're using the atomic helpers for fence waits, we can use
>> the same codepath as drm_atomic_helper_commit() does for async,
>> getting rid of our custom vc4_commit struct.
>
> \o/
>
> On the series:
Mario Kleiner writes:
> With instantaneous high precision vblank timestamping
> that updates at leading edge of vblank, the emulated
> "hw vblank counter" from vblank timestamping which
> increments at leading edge of vblank, and reliable
> page flip execution and completion at leading edge
> of
https://bugs.freedesktop.org/show_bug.cgi?id=100612
elizabethx.de.la.torre.m...@intel.com changed:
What|Removed |Added
Status|NEEDINFO|REOPENED
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=100612
elizabethx.de.la.torre.m...@intel.com changed:
What|Removed |Added
Version|unspecified |17.0
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=100612
elizabethx.de.la.torre.m...@intel.com changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.f
Signed-off-by: Eric Anholt
---
This fixup would be squashed into patch 1 of your series.
drivers/gpu/drm/stm/ltdc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 7d7e889f09c3..d1d28348512b 100644
--- a/drivers/
The clock gets enabled early on in init, since it's required in order
to read registers. If only devm_clk_prepare_enable() was a thing!
Signed-off-by: Eric Anholt
---
This fixup, if you like, I would slip in before patch 1 of your series.
drivers/gpu/drm/stm/ltdc.c | 10 ++
1 file cha
https://bugs.freedesktop.org/show_bug.cgi?id=93715
--- Comment #4 from Gert Wollny ---
For me it works correctly with current mesa-git and a 6870 HD (Barts).
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
> -Original Message-
> From: linux-...@googlegroups.com [mailto:linux-...@googlegroups.com] On
> Behalf Of Logan Gunthorpe
> Sent: Thursday, June 22, 2017 9:48 AM
> To: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org;
> linux-...@googlegroups.com; linux-al...@vger.kernel.org; l
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #10 from Gert Wollny ---
Looks good on Barts (6870) (mesa-git 903e1047) that actually uses r600g.
When replaying the trace I see an api issue message though:
1430: message: api issue 1: FBO incomplete: no attachments and default w
On Thu, Jun 22, 2017 at 2:17 AM, Mark Yao wrote:
> RK3399 and RK3288 shared the same HDMI IP controller, only some light
> difference with GRF configure.
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Mark Yao
> ---
> Changes in v3.1:
> Correct documentation compatible's format(Rob Herring).
>
On Tue, Jun 20, 2017 at 04:18:15PM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Convert non-ascii up and down arrows to '^' and 'v'
>
> Signed-off-by: Frank Rowand
> ---
> .../devicetree/bindings/display/panel/display-timing.txt | 16
>
> 1 file changed, 8 in
https://bugs.freedesktop.org/show_bug.cgi?id=101222
--- Comment #5 from Harry Wentland ---
Thanks, Mikko. Looks good. Do you want to send a patch to amd-gfx? If not I'll
create a patch with description and title for it.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101222
--- Comment #4 from Mikko Autio ---
Created attachment 132140
--> https://bugs.freedesktop.org/attachment.cgi?id=132140&action=edit
fix
Attached patch fixes multi-channel HDMI audio on my RX 460.
--
You are receiving this mail because:
You
On Wed, Jun 21, 2017 at 08:28:03PM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is Thierry's deferred fbdev setup series, with the locking rework almost
> entirely redone. The much wider scope is to get rid of drm_modeset_lock_all
> calls for atomic drivers and remove users of the fairly nasty
>
On Thursday, 2017-06-22 10:42:21 +0900, Michel Dänzer wrote:
> On 22/06/17 08:16 AM, Eric Engestrom wrote:
> > As Chad [1] puts it:
> >> it's excessive to jump through the PLT into a shared object for a mere
> >> ioctl wrapper.
> >
> > [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/
Hi Jose,
On Tuesday 13 Jun 2017 15:11:27 Jose Abreu wrote:
> Hi Laurent,
>
> Sorry for the late reply!
No worries.
> On 10-06-2017 09:50, Laurent Pinchart wrote:
> > On Friday 09 Jun 2017 13:53:12 Jose Abreu wrote:
> >> On 09-06-2017 12:04, Jose Abreu wrote:
> >>> Currently HDMI 2.0 PHYs do not
When the caller maps their dmabuf and we return an sg_table, the caller
doesn't expect the pages beneath that sg_table to vanish on a whim (i.e.
under mempressure). The contract is that the pages are pinned for the
duration of the mapping (from dma_buf_map_attachment() to
dma_buf_unmap_attachment).
Quoting Chris Wilson (2017-06-22 14:30:08)
> static void *vgem_prime_vmap(struct drm_gem_object *obj)
> {
> + struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
> long n_pages = obj->size >> PAGE_SHIFT;
> struct page **pages;
> void *addr;
>
> - pages = drm_ge
On Thu, 22 Jun 2017 15:16:47 +0200
Andrzej Hajda wrote:
> On 22.06.2017 14:41, Boris Brezillon wrote:
> > On Thu, 22 Jun 2017 14:29:07 +0200
> > Andrzej Hajda wrote:
> >
> >> On 22.06.2017 11:23, Boris Brezillon wrote:
> >>> On Thu, 22 Jun 2017 13:47:43 +0530
> >>> Archit Taneja wrote:
> >>
When the caller maps their dmabuf and we return an sg_table, the caller
doesn't expect the pages beneath that sg_table to vanish on a whim (i.e.
under mempressure). The contract is that the pages are pinned for the
duration of the mapping (from dma_buf_map_attachment() to
dma_buf_unmap_attachment).
On 22.06.2017 14:41, Boris Brezillon wrote:
> On Thu, 22 Jun 2017 14:29:07 +0200
> Andrzej Hajda wrote:
>
>> On 22.06.2017 11:23, Boris Brezillon wrote:
>>> On Thu, 22 Jun 2017 13:47:43 +0530
>>> Archit Taneja wrote:
>>>
On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
> 2017-06-20 1
On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote:
> There's no reason for drivers to call this, and all the ones I've
> removed looked very fishy:
> - Proper quiescenting of the vblank machinery should be done by
> calling drm_crtc_vblank_off(), which is best done by shutting down
> the en
On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote:
> Both drivers shut down all crtc beforehand already, which will shut up
> any pending vblank (the only thing vblank_cleanup really does is
> disable the disable timer). Hence we don't need this here and can
> remove it.
>
> Cc: Alex Deucher
>
On Thu, 22 Jun 2017 14:29:07 +0200
Andrzej Hajda wrote:
> On 22.06.2017 11:23, Boris Brezillon wrote:
> > On Thu, 22 Jun 2017 13:47:43 +0530
> > Archit Taneja wrote:
> >
> >> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
> >>> 2017-06-20 19:31 GMT+02:00 Eric Anholt :
> Archit Tan
On 22.06.2017 11:23, Boris Brezillon wrote:
> On Thu, 22 Jun 2017 13:47:43 +0530
> Archit Taneja wrote:
>
>> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
>>> 2017-06-20 19:31 GMT+02:00 Eric Anholt :
Archit Taneja writes:
> On 06/16/2017 08:13 PM, Eric Anholt wrote:
>>
On 06/22/2017 08:06 AM, Peter Rosin wrote:
> The redundant fb helper .load_lut is no longer used, and can not
> work right without also providing the fb helpers .gamma_set and
> .gamma_get thus rendering the code in this driver suspect.
>
Hi Peter,
STM32 chipsets supports 8-bit CLUT mode but th
On 21 June 2017 at 18:23, Eric Anholt wrote:
> Taken from make headers_install of drm-misc-next
> (34c8ea400ff6383b028f63df2453914163afc07c)
Oh! I'd somehow totally missed the kernel modifier support. Pushed with review.
Cheers,
Daniel
___
dri-devel ma
Regards
Shashank
On 6/22/2017 12:35 PM, Daniel Vetter wrote:
On Wed, Jun 21, 2017 at 04:04:06PM +0530, Shashank Sharma wrote:
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mod
On 06/22/2017 10:17 AM, Archit Taneja wrote:
>
>
> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
>> 2017-06-20 19:31 GMT+02:00 Eric Anholt :
>>> Archit Taneja writes:
>>>
On 06/16/2017 08:13 PM, Eric Anholt wrote:
> Archit Taneja writes:
>
>> On 06/16/2017 02:11 AM, Eric A
On Thu, 22 Jun 2017 13:47:43 +0530
Archit Taneja wrote:
> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
> > 2017-06-20 19:31 GMT+02:00 Eric Anholt :
> >> Archit Taneja writes:
> >>
> >>> On 06/16/2017 08:13 PM, Eric Anholt wrote:
> Archit Taneja writes:
>
> > On 06/16/2
Hi All,
As discussed during the review of v2 here is a new version of the vboxvideo
driver, now with all files converted to kernel coding style, making the
entire patch 100% checkpatch clean (with the exception of some -ENOSYS
warnings).
Still TODO is converting the driver to the atomic modesetti
Hi, Jose：
The value of RK3399 reg HDMI_CONFIG2_ID is 0xf3.
Using hdmi_phy_configure_dwc_hdmi_3d_tx() for hdmi 2.0 phy, we test
all HDMI video mode(including 594MHz) and it woks good.
And our customer has pass the HDMI CTS.
If you send a patch with a general config function fo
https://bugs.freedesktop.org/show_bug.cgi?id=101499
--- Comment #17 from Carlo Caione ---
Created attachment 132130
--> https://bugs.freedesktop.org/attachment.cgi?id=132130&action=edit
dm_plane_helper_prepare_fb with AMDGPU_GEM_DOMAIN_GTT
> Right, sorry, with DC you need to tweak dm_plane_hel
On Wed, Jun 21, 2017 at 10:38:43AM +0100, Jose Abreu wrote:
> Hi Daniel, Alexey,
>
>
> On 25-05-2017 15:19, Jose Abreu wrote:
> > Now that we have a callback to check if crtc supports a given mode
> > we can use it in arcpgu so that we restrict the number of probbed
> > modes to the ones we can a
1 - 100 of 121 matches
Mail list logo
