On 17 October 2016 at 04:41, Marek Olšák wrote:
> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer wrote:
>>
>> [ Adding Dan Williams and dri-devel ]
>>
>> On 14/10/16 03:28 AM, Shawn Starr wrote:
>>> Hello AMD folks,
>>>
>>> I have discovered a problem in Linus master that affects AMDGPU, nobod
ance of the hardware encoder a lot or it does
nothing.
--
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/20161017/a8331476/attachment-0001.html>
from Mike Lothian ---
rmmod -f amdgpu should do the trick
--
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/20161017/5e165
On 2016å¹´10æ16æ¥ 02:03, ayaka wrote:
> Hello:
>I meet a problem with eDP in rk3288 with the linux next 20161006,
> it is just like the early stage of 4.4
> kernel. I have added a eDP panel entry in the firefly reload board,
> once the kernel loaded analogix_dp-rockchip.ko, after printed
On 10/17/2016 08:57 AM, Mark yao wrote:
> On 2016å¹´10æ16æ¥ 02:03, ayaka wrote:
>> Hello:
>>I meet a problem with eDP in rk3288 with the linux next 20161006,
>> it is just like the early stage of 4.4
>> kernel. I have added a eDP panel entry in the firefly reload board,
>> once the kernel
g 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/20161017/37750c82/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/a6919bc8/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/675be1c6/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/1f6aece5/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/1838e525/attachment.html>
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/20161017/6b8cd027/attachment.html>
on AM335x. I think it should be just
"ti,da850-tilcdc".
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/a26c6f6e/attachment.sig>
On Thu, Oct 13, 2016 at 10:28:14AM -0700, Jim Bride wrote:
> On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote:
> > 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.
>
On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 Ã s 15:39 +0200, Maarten Lankhorst escreveu:
> > Op 08-10-16 om 02:11 schreef Lyude:
> > >
> > > Now that we've make skl_wm_levels make a little more sense, we can
> > > remove all of the redundant wm information. U
On Thu, Oct 13, 2016 at 10:54:51AM -0400, Alex Deucher wrote:
> On Thu, Oct 13, 2016 at 5:47 AM, Brian Starkey
> wrote:
> > Add some additional comments to more explicitly describe the meaning and
> > usage of the three CRTC modeset detection booleans: mode_changed,
> > connectors_changed and act
On Thu, Oct 13, 2016 at 05:04:36PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It supports the DRM_MODE_PAGE_FLIP_TARGET_* flags.
>
> Signed-off-by: Michel Dänzer
Ack on both patches.
-Daniel
> ---
>
> See
>
> https://cgit.freedesktop.org/~daenzer/xf86-video-amdgpu/commit/?id=b
On Thu, Oct 13, 2016 at 03:17:34PM +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2016, Maarten Lankhorst
> wrote:
> > Now that drm_crtc_index takes a const, the same can be done for
> > drm_crtc_mask.
> >
> > Signed-off-by: Maarten Lankhorst
>
> Reviewed-by: Jani Nikula
Applied to drm-misc, tha
On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> intermediate edid reads. This causes transient failures in CI which
> flags up the sporadic EDID read failures, which are recovered by
> rereading the EDID automat
On Fri, Oct 14, 2016 at 01:18:18PM +0100, Chris Wilson wrote:
> drm_atomic_state has a complicated single owner model that tracks the
> single reference from allocation through to destruction on another
> thread - or perhaps on a local error path. We can simplify this tracking
> by using reference
On Fri, Oct 14, 2016 at 07:50:13PM -0400, Rob Clark wrote:
> We had this wired up already internally but initially did not expose the
> property pending bikeshed about alpha and color management properties.
> I noted that drm-hwc2 was looking for this property, and a couple other
> drivers already
Hi Linus,
Just had a couple of amdgpu fixes and one core fix I wanted to get out
early to fix some regressions.
I'm sure I'll have more stuff this week for -rc2.
Signed tags should be working again.
Dave.
The following changes since commit 69405d3da98b48633b78a49403e4f9cdb7c6a0f5:
Merge tag
On Fri, Oct 14, 2016 at 07:55:51PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark
General comment: Some drivers (and I think this would be useful in
general) also dump state into debugfs with seq_file. And we have a bunch
of other places where unfortunately we duplicate dumping functions betw
ICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,
> HDMI_PICTURE_ASPECT_RESERVED,
> };
>
>
Acked-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/0d9dfcb6/attachment.sig>
On Fri, Oct 14, 2016 at 07:55:49PM -0400, Rob Clark wrote:
> Sometimes it is nice not to duplicate equivalent printk() and
> seq_printf() code.
>
> Signed-off-by: Rob Clark
Ok, maybe I should wait for coffee to kick in before commenting on patches
;-)
Two bits:
- kerneldoc for this pls, plus pu
Hello Tomasz:
Heiko told me you are in charge of the graphics part of chromium, I
think I had better told you the developing status of the xorg xserver in
rockchip. Currently the graphics department released a modification
version of xserver which would support the libMali, but the way to
supp
On Sun, 16 Oct 2016, ziegler at uni-freiburg.de wrote:
> If I hibernate from the console, thaw, and switch between the console
> and X, the gpu hangs itself. The machine becomes unresponsive except
> for the power button.
Please file a bug at [1], and attach the error state there.
Thanks,
Jani.
2016-10-17 9:12 GMT+02:00 Sekhar Nori :
> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>> On 15/10/16 20:42, Sekhar Nori wrote:
>>
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..32908ae 100644
--- a/arch/arm/boot/dts/da850.dtsi
>>
In fact this could happen in radeon_pci_shutdown. I tried reboot and
poweroff, kernel panic happened in both cases. Attachments are console
log and kernel config of 4.9-rc1 on linus's tree.
-- next part --
[ 14.275003] Rebooting in 10 seconds..[ 24.329266] ACPI MEMORY or
hook
>
> The series,
>
> Reviewed-by: Alexandre Courbot
>
Thank you Alexandre.
So is there a nouveau subtree this should go into? Or is it up to Dave
to pull it into drm?
Regards,
Ard.
___
Nouveau mailing list
Nouveau at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/dd13f85a/attachment.html>
On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
> On 15/10/16 20:42, Sekhar Nori wrote:
>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index f79e1b9..32908ae 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>
>>> @@
fferent.
The driver gets the version number from LCDC's register, and acts based
on that, so afaik the compatible string doesn't really affect the
functionality (as long as it matches).
But even if it works with the current driver, I don't think
"ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/b6ff5ea1/attachment.sig>
;https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/b3063fd9/attachment.sig>
> r-b with that bikeshed addressed or not?
Hello Daniel,
I have already acknowledged this comment, and I am publishing next set today
with rebase, addressing this comment.
So you can consider this one done.
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@f
Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
> Hello Tomasz:
> Heiko told me you are in charge of the graphics part of chromium, I
> think I had better told you the developing status of the xorg xserver in
> rockchip.
What I actually said was that Tomasz did the original VPU driv
On 2016å¹´10æ17æ¥ 15:12, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
>> Hello Tomasz:
>>Heiko told me you are in charge of the graphics part of chromium, I
>> think I had better told you the developing status of the xorg xserver in
>> rockchip.
> What
Op 17-10-16 om 08:05 schreef Daniel Vetter:
> On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote:
>> Em Qui, 2016-10-13 Ã s 15:39 +0200, Maarten Lankhorst escreveu:
>>> Op 08-10-16 om 02:11 schreef Lyude:
Now that we've make skl_wm_levels make a little more sense, we can
remove
On Sun, Oct 16, 2016 at 08:48:02PM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is the first step to split out the drm-misc trees into their own git
> repo.
> This just moves the integration trees into drm-nightly.git. Those are separate
> since I really like the idea of sharing one integration
Req Keys.
--
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/20161017/21fb6788/attachment.html>
Op 16-10-16 om 18:03 schreef Rob Clark:
> Currently with fence-array, we have a potential deadlock situation. If we
> fence_add_callback() on an array-fence, the array-fence's lock is aquired
> first, and in it's ->enable_signaling() callback, it will install cb's on
> it's array-member fences, so
On 10/17/2016 04:02 PM, Mark yao wrote:
> On 2016å¹´10æ17æ¥ 15:12, Heiko Stuebner wrote:
>> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
>>> Hello Tomasz:
>>>Heiko told me you are in charge of the graphics part of chromium, I
>>> think I had better told you the developing s
Now that we have the name "block" free once more, we can use it to point
to the start of a block within the edid.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/d
The "block" variable points to the entire edid, not individual blocks
despite it being named such.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/
Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() it
Thanks, Alex.
Patch was Reviewed-by: Rex Zhu
Best Regards
Rex
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Friday, October 14, 2016 11:14 PM
To: Dan Carpenter
Cc: Zhu, Rex; Maling list - DRI developers
Subject: Re: [bug report] drm/amd/powerplay: implemen
ng the rate you asked for other than by luck.
--
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/20161017/c289d532/attachment.html>
as scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/1b3dec7e/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/90d884d1/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/c3f35783/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/912331b9/attachment.html>
. Thanks!
--
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/20161017/d9d1e4ec/attachment.html>
tachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/7c1606b2/attachment-0001.html>
On Mon, Oct 17, 2016 at 09:35:14AM +0100, Chris Wilson wrote:
> Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> intermediate edid reads. This causes transient failures in CI which
> flags up the sporadic EDID read failures, which are recovered by
> rereading the EDID automat
As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)
This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.
V2: Address review co
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.
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Cc: Daniel Vetter
Cc: Emil Velikov
V2: rebase
V3: rebase
---
drivers/video/hd
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
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.
Signed-off-by: Shashank Sharma
Reviewed-by: Se
Please ignore this series, I mixed up one patch from LSPCON in here.
Will send the right series in few minutes.
Regards
Shashank
-Original Message-
From: Sharma, Shashank
Sent: Monday, October 17, 2016 4:52 PM
To: dri-devel at lists.freedesktop.org; jim.bride at linux.intel.com
Cc: inte
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
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
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
Reviewe
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.
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Cc: Daniel Vetter
Cc: Emil Velikov
V2: rebase
V3: rebase
---
drivers/video/hd
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.
Signed-off-by: Shashank Sharma
Reviewed-by: Se
vel/attachments/20161017/36d64c3f/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161017/d0a0b959/attachment-0001.html>
Hi,
On 17.10.2016 13:09, Arvind Yadav wrote:
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav
Subject prefix is incorrect.
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/e
Regards
Shashank
On 10/17/2016 5:01 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 17-10-2016 12:32, Shashank Sharma wrote:
>> 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
>>s
Hello,
On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
> On 17/10/16 10:12, Sekhar Nori wrote:
>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>> On 15/10/16 20:42, Sekhar Nori wrote:
> diff --git a/arch/arm/boot/dts/da850.dtsi
> b/arch/arm/boot/dts/da850.dtsi
> inde
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
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 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.
Signed-off-by: Shashank Sharma
Reviewed-by: Se
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
Reviewe
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.
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Reviewed-by: Jose Abreu
Acked-by: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Emil Ve
On Mon, Oct 17, 2016 at 2:38 AM, Daniel Vetter wrote:
> On Fri, Oct 14, 2016 at 07:55:49PM -0400, Rob Clark wrote:
>> Sometimes it is nice not to duplicate equivalent printk() and
>> seq_printf() code.
>>
>> Signed-off-by: Rob Clark
>
> Ok, maybe I should wait for coffee to kick in before comment
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/6394760b/attachment.html>
using TONGA). This is better, though you can hack
it on for omx.
--
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/20161017/e7d238a3/attachment.html>
On Mon, Oct 17, 2016 at 05:34:36PM +0530, Shashank Sharma wrote:
> 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
On Mon, Oct 17, 2016 at 09:35:13AM +0100, Chris Wilson wrote:
> Now that we have the name "block" free once more, we can use it to point
> to the start of a block within the edid.
>
> Signed-off-by: Chris Wilson
Merged the 2 prep patches to drm-misc for now. I'll wait with 3/3 until
you&Ville re
about just "ti,lcdc" ?
Maybe, and I agree that's the "correct" way, but looking at the history,
it's not just once or twice when we've suddenly found out some
difference or bug or such in an IP revision, or the integration to a
SoC, that can't be found based on the IP revision.
That's why I feel it's usually safer to have the SoC revision there in
the compatible string.
That said, we have only a few different old SoCs with LCDC (compared to,
say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/6c32126e/attachment.sig>
On Mon, Oct 17, 2016 at 07:59:51AM -0400, Rob Clark wrote:
> On Mon, Oct 17, 2016 at 2:38 AM, Daniel Vetter wrote:
> > On Fri, Oct 14, 2016 at 07:55:49PM -0400, Rob Clark wrote:
> >> Sometimes it is nice not to duplicate equivalent printk() and
> >> seq_printf() code.
> >>
> >> Signed-off-by: Rob
On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> 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
On Mon, Oct 17, 2016 at 8:30 AM, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 07:59:51AM -0400, Rob Clark wrote:
>> On Mon, Oct 17, 2016 at 2:38 AM, Daniel Vetter wrote:
>> > On Fri, Oct 14, 2016 at 07:55:49PM -0400, Rob Clark wrote:
>> >> Sometimes it is nice not to duplicate equivalent printk
On Mon, Oct 17, 2016 at 05:34:39PM +0530, Shashank Sharma wrote:
> 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.
>
> Signed-off-by: Shashank Sharma
> Reviewed-by: Sean Paul
Hi Rob,
On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> >>> LVDS is a physical layer specification defined i
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4a21a745c373..fc54f3f0a42c 100644
--- a/drivers/gpu/drm/exynos/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1915ec44f7eb..6672ea93ee73 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..5c0625e5dca1 100644
--- a/drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index db61aa5f32ef..414e848d8cbf 100644
--- a/drivers/gpu/drm/mediat
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_blend.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 85172a977bf3..70c03eb032fc 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/d
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9b17a66cf0e1..b5af77097033 100644
--- a/dr
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 3 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 ++--
drivers/gpu/drm/msm/msm_atomic.c | 16
Add for_each_(old,new)_(crtc,connector,plane)_in_state iterators, and
re-use for_each_*_in_state to be a iterator with the old and the new
state.
This will be less confusing than the previous case, in which
for_each_*_in_state could refer to the old or the new state.
The oldnew macro names are te
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2df06b703e3d..163b73b493bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
With the old users of for_each_obj_in_state gone, we can rename
for_each_oldnew_obj_in_state back to that name. It's slightly less
ugly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 34 ++---
drivers/gpu/drm/drm_blend.c
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c76ed9ee6a01..
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/omapdrm/omap_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1735c7accf72..74f9519878a2 100644
--- a/drivers/gpu/drm/omapdrm/omap_d
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index faa67624e1ed..0028335fc1bb 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 302 +++-
1 file changed, 157 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fcb6e5b55217..c8aba493fc17 100644
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 156 ++-
1 file changed, 80 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3bd3f6a93c12..d310abace86a 100644
Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
replace the old for_each_xxx_in_state ones. This is useful for >1 flip
depth and getting rid of all xxx->state dereferences.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 6 +++
drivers/gpu/drm/dr
1 - 100 of 195 matches
Mail list logo
