On 8/4/2016 1:36 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Tuesday 19 Jul 2016 12:06:41 Archit Taneja wrote:
>> Hi Dave,
>>
>> This is an update to the previous drm bridge pull request. The ADV7511
>> driver's conversion from slave encoder to bridge meant that its users
>> (the rcar-du kms
On 7 August 2016 at 07:59, Mike Marshall wrote:
> Hello everyone...
>
> I was out of the office yesterday, so I came in today to do the bisect...
Okay it appears cirrus doesn't set it's mode config functions until after
it sets up modesetting, which causes this to fail.
Probably need to audit ot
nel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6381 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/345c774b/attachment.obj>
Linus, Eric,
On Mon, 8 Aug 2016 14:19:23 -0700
Linus Torvalds wrote:
> On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman
> wrote:
> >
> > Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
> >
> > I am just about to head out the door on vacation until the end of the
> > mo
-
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 34064 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/7159db1f/attachment-0001.obj>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/eaaa0622/attachment.html>
cirrus_modeset_init() is initializing/registering the emulated fbdev
and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
!funcs->best_encoder is valid"), DRM internals can access/test some of
the fields in mode_config->funcs as part of the fbdev registration
process.
Make sure d
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/2bae6339/attachment.html>
+ Archit
On 08/09/2016 02:53 AM, Sean Paul wrote:
> Instead of just preparing the panel on bind, actually prepare/unprepare
> during modeset/disable. The panel must be prepared in order to read hpd
> status and edid, so we need to keep state around the prepares in order
> to ensure we don't accid
Sean,
On 08/09/2016 03:29 AM, Sean Paul wrote:
> From: Douglas Anderson
>
> When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
> quite correctly. Specifically if we've got the true clock 26667 Hz,
> we'll perform this calculation:
> 26667 / 1000 => 26
>
> Later
On 8 August 2016 at 19:40, Daniel Vetter wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
>> requires 37 bits to represent, but âintâ only ha
On 2016å¹´08æ09æ¥ 03:29, Sean Paul wrote:
> From: Douglas Anderson
>
> When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
> quite correctly. Specifically if we've got the true clock 26667 Hz,
> we'll perform this calculation:
> 26667 / 1000 => 26
>
> Later whe
On Mon, Aug 8, 2016 at 10:44 AM, Jose Abreu wrote:
> Hi,
>
> Currently I am working on some HDMI 2.0 features using the DRM
> infrastructure. I am mainly working in parsing the newly
> introduced EDID blocks such as HDMI Forum Vendor Specific Data
> Block, YCBCR 420 Video Data Block and YCBCR Capa
Hi Linus,
I thought I should dequeue this, some of these could have made -rc1 if I'd
had less illness. This contains a bunch of amdgpu fixes, and some i915
regression fixes.
It also contains some fixes for an older regression with some EDID
changes and some 6bpc panels.
Then there are the loc
On Sun, Jul 24, 2016 at 05:00:31PM +0200, Pavel Machek wrote:
> On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> > 2016-08-07 Pavel Machek :
> >
> > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > > Hi,
>
On Tue, Aug 09, 2016 at 10:35:57AM +0800, Yakir Yang wrote:
> + Archit
>
>
> On 08/09/2016 02:53 AM, Sean Paul wrote:
> > Instead of just preparing the panel on bind, actually prepare/unprepare
> > during modeset/disable. The panel must be prepared in order to read hpd
> > status and edid, so we
On Mon, Aug 08, 2016 at 05:04:03PM +0100, Brian Starkey wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
> > > Hi Russell,
> > >
> > > On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Lin
On Mon, Aug 08, 2016 at 05:25:38PM +0100, Jose Abreu wrote:
> Hi,
>
>
> On 05-08-2016 09:13, Chris Wilson wrote:
> > On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
> >> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
> >>> On Thu, Aug 04, 2016 at 06:13:18
On Mon, Aug 08, 2016 at 01:30:37PM -0400, Alex Deucher wrote:
> On Fri, Aug 5, 2016 at 8:30 PM, Lyude wrote:
> > While I was investigating an unrelated bug on the radeon driver, I noticed
> > that
> > it's become rather difficult to actually read through dmesg with drm.debug
> > turned on, on acc
On Mon, Aug 08, 2016 at 01:32:51PM -0500, Scot Doyle wrote:
> On Mon, 8 Aug 2016, Daniel Vetter wrote:
> > On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote:
> > > Hi all,
> > >
> > > I'm interested in discussing ways compositors could cooperate
> > > without CONFIG_VT/VT_VACTIVATE/VT_SET
On Mon, 08 Aug 2016 22:36:13 -0500
ebiederm at xmission.com (Eric W. Biederman) wrote:
> Boris Brezillon writes:
>
> > cirrus_modeset_init() is initializing/registering the emulated fbdev
> > and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> > !funcs->best_encoder is vali
Op 08-08-16 om 17:34 schreef Daniel Vetter:
> On Mon, Aug 8, 2016 at 1:23 PM, Maarten Lankhorst
> wrote:
>> There are two paths into intel_cleanup_plane_fb, the normal completion
>> path and the failure path.
>>
>> In the failure case, intel_cleanup_plane_fb is called before
>> drm_atomic_helper_s
Op 08-08-16 om 21:59 schreef Gustavo Padovan:
> 2016-08-08 Maarten Lankhorst :
>
>> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> When creating a sync_pt the name received wasn't used anywhere.
>>> Now we add it to the sync info debug output to make it easier to i
With gem requests reworked to only keep some memory around after
it's completed it's now mostly harmless to keep a reference to the
request until the state is destroyed. This makes it easy to hang
on to the request until the plane state is destroyed since it is
just a bunch of memory now.
On my 64
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs and also on the refactoring to the analogix_dp driver for using
the DP helpers (so it depends on those not-yet merged series).
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver
This backpointer allows DP helpers to access the connector it's being
used for.
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 63b8bd502444..f66cc8501d71 100644
---
Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16
include/drm/bridge/analogix_dp.h | 3 +++
2 files c
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +
1 fil
On Tue, Aug 09, 2016 at 12:15:51PM +0200, Maarten Lankhorst wrote:
> With gem requests reworked to only keep some memory around after
> it's completed it's now mostly harmless to keep a reference to the
> request until the state is destroyed. This makes it easy to hang
> on to the request until the
On Tue, Aug 09, 2016 at 12:51:32PM +0200, Tomeu Vizoso wrote:
> This backpointer allows DP helpers to access the connector it's being
> used for.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> include/drm/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm_dp_
Hi Dave,
Just one patch for -rc that fixes a printk format error.
Thanks,
Oded
The following changes since commit 36e9d08b58f44c3a02974c405ccaaa6ecfaf05b8:
drm/cirrus: Fix NULL pointer dereference when registering the fbdev
(2016-08-09 13:01:47 +1000)
are available in the git repository
Mulholland ---
I can confirm the problem is now fixed. Great job :D
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/8b9ac321/attachment.html>
Hey,
Op 08-08-16 om 23:03 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however,
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/fe514b8d/attachment.html>
ge to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/740246d5/attachment.html>
Subtest pread-oom: FAIL (186.552s)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/ba03995b/attachment-0001.html>
First part is just a bit of rst fallout to make drm doc builds warning free. But
then I started to split out parts of drm_crtc into their own files. framebuffers
and connectors are done, next up on my plans are encoders, and then the base
stuff around drm_mode_object, properties and blobs. I think
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-doc at vger.kernel.org
Signed-off-by: Daniel Vetter
---
- Move the common vtable stuff to the top
- Move "Tile Group" to a more appropriate heading level
- Throw away the old intro for the crtc helpers (it's entirely stale,
e.g. helpers have become modular years ago), and replace it with a
general intro about the motivation behind helpers.
- Reorder
While reviewing docs I spotted that we have a few functions that
really just don't fit into their containing helper library section.
Extract them and shovel them all into a new library for random one-off
aux stuff.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 9 ++
- Again adjust headings a bit, and don't mix up the initialization
sections with other stuff.
- Remove the doc for output polling, that vfunc is now properly
documented in the vfunc reference sections.
- Move the grab-bag with all the core stuff (i.e. drm_crtc.[hc]) to
the front for a more pr
- Readjust headings - we lost one level through the extraction into a
separate .rst file.
- Merge helper reference sections with the helper documentation - that
split was just an artifact of the docbook toolchain sucking at too
deep nesting levels. No such problems with sphinx.
- Move the cma
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 --
1
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus poi
Since the drm_event cleanup work (as prep for fence support) drivers
don't need to bother themselves any more with this, the drm event core
takes care of that.
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_c
It was added way back together with the dirty_fb ioctl, but neither
generic xfree86-modesetting nor the vmware driver use it. Everyone is
supposed to just unconditionally call the dirtyfb when they do
frontbuffer rendering.
And since unused uabi is bad uabi (there's reasons we require open
source
Accidentally the wrong file. Oops.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index c92afa82b130..3ae4c12aca08 100644
--- a/Documentation/gpu/drm-
- Move the intro section into a DOC comment, and update it slightly.
- kernel-doc for struct drm_framebuffer!
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 26 +--
drivers/gpu/drm/drm_framebuffer.c | 35 +++
include/drm/drm_framebuffer.h | 94 ++
It's really part of the core blob interface, and the drm_connector.c
extraction needs it too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 13 +++--
include/drm/drm_crtc.h | 6 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/dr
They're only used internally within the dp helpers. Also nuke the
kerneldoc (we only document the driver interface in the drm shared
functions). And move the header file from the public include/
directory to the source files into drm_crtc_helper_internal.h, similar
to how we already have drm_crtc_i
- Shuffle docs from drm-kms.rst into the structure docs where it makes
sense.
- Put the remaining bits into a new overview section.
One thing I've changed is around probing: Old docs says that you
_must_ use the probe helpers, which isn't correct. Helpers are always
optional.
Signed-off-by: Dan
Also start with drm_modeset.h with the core bits, since we need
to untangle this mess somehow. That allows us to move the drm_modes.h
include to the right spot, except for the temporary connector status
enum. That will get fixed as soon as drm_connector.h exists.
Signed-off-by: Daniel Vetter
---
There's not much point in kerneldoc if it's not included:
- It won't show up in the pretty html pages.
- The comments itself won't get parsed, which means 0day won't pick up
changes, resulting in stale docs fast.
Also, uapi really should be core, not helpers, so move drm_blend.c to
that. That al
Pulls in quite a lot of connector related structures (cmdline mode,
force/status enums, display info), but I think that all makes perfect
sense.
Also had to move a few more core kms object stuff into drm_modeset.h.
And as a first cleanup remove the kerneldoc for the 2 connector IOCTL
- DRM core d
No one looks at it, only i915/gma500 lvds even bother to fill it
out. I guess a very old plan was to use this for filtering modes,
but that's already done within the edid parser.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 5 -
drivers/gpu/drm/gma500/psb_int
We seem to have a bit a mess in how to describe the bus formats, with
a multitude of competing ways. Might be best to consolidate it all and
use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
modes.
Also move all the display_info related functions into drm_connector.c
(there's only
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason wh
On Tue, Aug 9, 2016 at 3:12 PM, Jose Abreu wrote:
> Will you send a new version of these patches? I have a patch
> ready that adds the new HDMI 2.0 modes to the CEA modes list in
> DRM but these modes require the addition of the new picture
> aspect ratio flags (64:27, 256:135). I can either wait
desktop.org/archives/dri-devel/attachments/20160809/996ef7c5/attachment.html>
org/archives/dri-devel/attachments/20160809/8f29aa92/attachment.html>
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason wh
Thanks Daniel.
Hi Joes,
As Daniel mentioned, I have already written a patch which adds all HDMI 2.0
modes in CEA DB, and it also completes all the VICs in the DB from 1-107 (we
have 1-64 now).
I was myself waiting for aspect ratio patches to get accepted, as I needed them
for the modes.
Will
Hmm.
I don't have a strong opinion on this, but IMO the original idea of
allowing a user-space driver to optimize away the dirty calls isn't a
bad one.
Since the xf86-video-vmware always assumed that all drms it has to deal
with has this property set it's not using it.
The modesetting driver could
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/a964b63a/attachment.html>
|return fail instead of pass |return fail instead of pass
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/54069
- and the compile was failing.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/a6b39035/attachment.html>
On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
wrote:
> Hmm.
>
> I don't have a strong opinion on this, but IMO the original idea of
> allowing a user-space driver to optimize away the dirty calls isn't a
> bad one.
> Since the xf86-video-vmware always assumed that all drms it has to deal
> wit
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/69d43492/attachment.html>
2016-08-09 Maarten Lankhorst :
> Op 08-08-16 om 21:59 schreef Gustavo Padovan:
> > 2016-08-08 Maarten Lankhorst :
> >
> >> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
> >>> From: Gustavo Padovan
> >>>
> >>> When creating a sync_pt the name received wasn't used anywhere.
> >>> Now we add it to t
This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
supported for HDMI 2.0 4k modes.
Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma
V2: Ad
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
V2: rebase
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/video/hdmi.c | 4 ++
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
V2: Rebase
Signed-off-by: Shashank Sharma
Rev
-ccflags-y += -I$(FULL_AMD_DAL_PATH)/dc/inc/
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/66c6ac24/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/69fd5f50/attachment-0001.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/50165dea/attachment.html>
On 09/08/16 03:59, Dave Airlie wrote:
> On 8 August 2016 at 19:40, Daniel Vetter wrote:
>> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>>> Hello there,
>>>
>>> Recent versions of gcc say this:
>>>
>>> include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
>>> requi
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/9f5e8637/attachment.html>
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Move the common vtable stuff to the top
> - Move "Tile Group" to a more appropriate heading level
> - Throw away the old intro for the crtc helpers (it's entirely stale,
> e.g. helpers have become modular years ago), and replace it with a
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/bfc330d8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=150731
--- Comment #3 from Jimi ---
I've now confirmed this issue on Fiji (R9 Fury) as well.
--
You are receiving this mail because:
You are watching the assignee of the bug.
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/bcef64aa/attachment.html>
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of â65535 << 20â
requires 37 bits to represent, but âintâ only has 32 bits
[-Wshift-overflow=]
Reported-by: David Binderman
Signed-off-by: Dave Gordon
Cc: Dave Airlie
---
include/drm/i915_drm.h | 2 +-
1 fi
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #4 from Jimi ---
Is this bug still happening? With my R9 Fury on amdgpu, cat
/sys/class/hwmon/hwmon0/pwm1 (well, in my case, it's hwmon2 because I have
another card), returns 35 on idle, not 0, but the fans are not running. Even
when
This enables panic message output support in simpledrm.
simpledrm has a fixed buffer that is set up to be scanned out
and the virtual address is already available.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 24
1 file changed, 24 inser
This adds support for outputting kernel messages on panic().
The drivers that supports it, provides a framebuffer that the
messages can be rendered on.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_internal
This patchset proposes a way to get output of kernel messages on the
display during panic(). The responsibility of the driver is to provide
a framebuffer with a virtual mapping that the messages can be rendered
on. Only linear RGB is supported in this version.
David Herrmann, who has worked on thi
This adds a way for in-kernel users to iterate over the available
DRM minors. The implementation is oops safe so the panic code
can safely use it.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_drv.c | 30 ++
include/drm/drmP.h| 13 +
2 fil
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #5 from Jimi ---
I managed to check the fans while pwm1 was giving values like 68, 61, and 56,
and they were not turned on. I don't know if that means anything, because the
card was still <40 degrees and definitely not too hot to touc
On Mon, Aug 08, 2016 at 05:48:20PM -0600, Shuah Khan wrote:
> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++--
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/fdc545c7/attachment.html>
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/93330e1e/attachment.html>
Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/i2c/tda998x_drv.c | 84 +
Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 71 --
1 file changed, 67 insertions(+), 4 d
Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.
With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI code
Changes since first version [1] of this series:
- "drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata"
- Change audio in tda998x pdata to audio_params to match the naming in
private data struct
- Skip IEC958_AES2 byte when writing status bytes to registers
- Turn AFM
1 - 100 of 140 matches
Mail list logo
