On 10/02/15 21:37, Jan Vesely wrote:
> On Tue, 2015-02-10 at 00:27 +, Emil Velikov wrote:
>> On 10 February 2015 at 00:02, Jan Vesely wrote:
>>> On Mon, 2015-02-09 at 23:32 +, Emil Velikov wrote:
On 9 February 2015 at 21:39, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
Nic
On 02/02/15 00:14, Emil Velikov wrote:
> Hi all,
>
> As mentioned a couple of days ago at #dri-devel some(most) users of
> render nodes tend to rely on strict mapping between the primary and
> render node. I.e. something along the lines of
>
> fstat(render_fd, &sbuf);
> sprintf(primary_node
Because of iMX6 & Rockchip have differnet mpll config parameter,
than the cklvl & txlvl would be different, we also should seperate
this parmeter.
As for Rockchip HDMI, when pixle clock less than 148MHz, the cklvl &
txlvl should be set to 13. When pixel clock less than 74.25MHz the
cklvl & txlvl s
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
and single-ended test would failed when display mode is 74.25MHz.
- Fix some code style, leave space for next patches.
- For hdmi eye-diagram test, we turn on the Transmitter Trailer-B and
improve slopeboost to 25%-30% decreas
As for 1920x1080 display resolution, we should turn on the Transmitter
Trailer-B, and adjust slopeboost to 25%-35% decrease.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/
- const struct dw_hdmi_mpll_config *mpll_config =
-hdmi->plat_data->mpll_cfg;
- const struct dw_hdmi_curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr;
- const struct dw_hdmi_sym_term *sym_term = hdmi->plat_data->sym_term;
+ const struct dw_hdmi_plat_data *pl
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
and single-ended test would failed when display mode is 74.25MHz.
- Fix some code style, leave space for next patches.
- For hdmi eye-diagram test, we turn on the Transmitter Trailer-B and
improve slopeboost to 25%-30% decrease
org/archives/dri-devel/attachments/20150210/bfc437e7/attachment.html>
_BYTES 16
> +
> #define DP_AUX_I2C_WRITE 0x0
> #define DP_AUX_I2C_READ 0x1
> #define DP_AUX_I2C_STATUS0x2
> @@ -519,6 +521,9 @@ struct drm_dp_aux_msg {
> * transactions. The drm_dp_aux_register_i2c_bus() function registers an
> * I2C adapter that can be passed to drm_probe_ddc(). Upon removal, drivers
> * should call drm_dp_aux_unregister_i2c_bus() to remove the I2C adapter.
> + * The I2C adapter uses long transfers by default; if a partial response is
> + * received, the adapter will drop down to the size given by the partial
> + * response for this transaction only.
> *
> * Note that the aux helper code assumes that the .transfer() function
> * only modifies the reply field of the drm_dp_aux_msg structure. The
>
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/40b609b7/attachment.sig>
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter r
On 02/02/15 10:06, Jammy Zhou wrote:
> v2: Add drmGetMinorBase, and call drmOpenWithType in drmOpen
> v3: Pass 'type' to drmOpenByBusid and drmOpenDevice in drmOpenByName
>
> Signed-off-by: Jammy Zhou
> ---
> xf86drm.c | 63
> ---
> xf8
gt; libdrm.
> Namely the top one and most of the tests.
>
> -Emil
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/5ef9f5a3/attachment-0001.sig>
On Mon, Feb 09, 2015 at 07:03:26PM +0100, Daniel Vetter wrote:
> Just a little demo really. We probably need to introduce skl specific
> functions for a lot of the format validation stuff, or at least
> helpers. Specifically I think intel_framebuffer_init and
> intel_fb_align_height must be adjuste
Hello Boris,
On Tue, Feb 10, 2015 at 03:05:57PM +0100, Boris Brezillon wrote:
> On Tue, 10 Feb 2015 14:40:45 +0100
> Sylvain Rochet wrote:
> > +
> > +static SIMPLE_DEV_PM_OPS(atmel_hlcdc_dc_drm_pm_ops,
> > + atmel_hlcdc_dc_drm_suspend, atmel_hlcdc_dc_drm_resume);
> > +
>
> Do we really
On Tue, 10 Feb 2015 14:40:46 +0100
Sylvain Rochet wrote:
> Some LCD panels have back-powering issue when un-powered, allows users
> to use an alternate pinctrl "sleep" in order to clamp outputs to a
> wanted state at suspend.
>
> Signed-off-by: Sylvain Rochet
Acked-by: Boris Brezillon
> ---
Hi Sylvain,
On Tue, 10 Feb 2015 14:40:45 +0100
Sylvain Rochet wrote:
> On suspend: switch off CRTC if not already suspended with runtime PM
>
> On resume: switch on CRTC if we were not already suspended from runtime
> PM while suspending.
>
> Signed-off-by: Sylvain Rochet
> ---
> drivers/gpu
Some LCD panels have back-powering issue when un-powered, allows users
to use an alternate pinctrl "sleep" in order to clamp outputs to a
wanted state at suspend.
Signed-off-by: Sylvain Rochet
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On suspend: switch off CRTC if not already suspended with runtime PM
On resume: switch on CRTC if we were not already suspended from runtime
PM while suspending.
Signed-off-by: Sylvain Rochet
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 60
1 file changed, 60
This series depends on Boris' "[PATCH v2] drm: atmel-hlcdc: Atomic
mode-setting conversion"
<1423236143-6494-1-git-send-email-boris.brezillon at free-electrons.com>
plus a few fixes which are going to be in v3 of Boris' patch.
This series adds basic PM support for Atmel HLCDC.
Sylvain Rochet (
From: Alex Deucher
Enable at init and disable on fini. Workaround for hardware problems.
v2 (chk): extend commit message
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c| 21 -
drivers/gpu/drm/r
From: Christian König
Emit the EOP twice to avoid cache flushing problems.
Signed-off-by: Christian König
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers
mmit it works.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/6f9b9798/attachment.html>
Currently we don't support anything but X tiled. And for an easier
transition it makes a lot of sense to just keep requiring that X tiled
is properly fenced.
Which means we need to do absolutely nothing in old code to support fb
modifiers, yay!
v2: Fix the Y tiling check, noticed by Tvrtko.
v3:
This patch implements the virtual GEM driver with PRIME sharing which
allows vgem to import a gem object from other drivers for the purpose
of mmap-ing them to userspace. The mmap is done using the mmap
operation exported by other drivers.
v2: remove platform_device and do not attach to dma bufs
v
On Tue, Feb 10, 2015 at 11:01:56AM +, Chris Wilson wrote:
> On Mon, Feb 09, 2015 at 07:03:28PM +0100, Daniel Vetter wrote:
> > Just the usual paranoia ...
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_crtc.c | 17 +
> > 1 file changed, 17 insertions(+)
Currently we don't support anything but X tiled. And for an easier
transition it makes a lot of sense to just keep requiring that X tiled
is properly fenced.
Which means we need to do absolutely nothing in old code to support fb
modifiers, yay!
v2: Fix the Y tiling check, noticed by Tvrtko.
Cc:
From: Tvrtko Ursulin
To be used from the new addfb2 extension.
v2:
- Drop Intel-specific untiled modfier.
- Move to drm_fourcc.h.
- Document layouts a bit and denote them as platform-specific and not
useable for cross-driver sharing.
- Add Y-tiling for completeness.
- Drop special docstring ma
On 2015ë
02ì 10ì¼ 02:07, Gustavo Padovan wrote:
> 2015-02-09 Daniel Stone :
>
>> Hi Inki,
>>
>> On 9 February 2015 at 14:53, Inki Dae wrote:
>>> I'm merging this patch series but I found two issues. One is already
>>> pointed out.
>>
>> Fantastic - thanks a lot for doing this!
>>
>>> On 2015
https://bugzilla.kernel.org/show_bug.cgi?id=93001
--- Comment #1 from Joerg Esser ---
Created attachment 166271
--> https://bugzilla.kernel.org/attachment.cgi?id=166271&action=edit
vbios
--
You are receiving this mail because:
You are watching the assignee of the bug.
With this we can treat the fb format modifier completely independently
from the fencing mode in obj->tiling_mode in the initial plane code.
Which means new tiling modes without any gtt fence are now fully
support in the core i915 driver code.
v2: Also add pixel_format while at it, we need this to
No functional changes yet since intel_framebuffer_init would have
fixed this up for us. But this is prep work to be able to handle new
tiling layouts in the initial plane config code.
Follow-up patches will start to make use of this and switch over to fb
modifiers where needed.
Signed-off-by: Dan
On Tue, Feb 10, 2015 at 12:36:51PM +0100, Daniel Vetter wrote:
> On Tue, Feb 10, 2015 at 11:01:56AM +, Chris Wilson wrote:
> > On Mon, Feb 09, 2015 at 07:03:28PM +0100, Daniel Vetter wrote:
> > > Just the usual paranoia ...
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu
On Fri, Jan 30, 2015 at 2:39 PM, Bjorn Andersson wrote:
> On Fri, Jan 30, 2015 at 1:51 PM, Bjorn Andersson wrote:
>> On Tue, Jan 13, 2015 at 12:43 PM, Jilai Wang
>> wrote:
>>> Add HDMI HDCP support including HDCP PartI/II/III authentication.
>>> V1: Initial Change
>>> V2: Address Bjorn&Rob's co
On Tue, Feb 10, 2015 at 4:37 AM, Zhou, Jammy wrote:
> Ping... Any comments on these patches?
They look good to me.
Reviewed-by: Alex Deucher
>
> Regards,
> Jammy
>
> -Original Message-
> From: Jammy Zhou [mailto:Jammy.Zhou at amd.com]
> Sent: Monday, February 02, 2015 6:05 PM
> To: dri
On 02/09/2015 06:03 PM, Daniel Vetter wrote:
> Currently we don't support anything but X tiled. And for an easier
> transition it makes a lot of sense to just keep requiring that X tiled
> is properly fenced.
>
> Which means we need to do absolutely nothing in old code to support fb
> modifiers, y
On 02/09/2015 06:03 PM, Daniel Vetter wrote:
> From: Tvrtko Ursulin
>
> To be used from the new addfb2 extension.
>
> v2:
> - Drop Intel-specific untiled modfier.
> - Move to drm_fourcc.h.
> - Document layouts a bit and denote them as platform-specific and not
>useable for cross-driver sharin
On Mon, Feb 09, 2015 at 07:03:28PM +0100, Daniel Vetter wrote:
> Just the usual paranoia ...
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>
2015-02-10 Inki Dae :
> On 2015ë
02ì 10ì¼ 02:07, Gustavo Padovan wrote:
> > 2015-02-09 Daniel Stone :
> >
> >> Hi Inki,
> >>
> >> On 9 February 2015 at 14:53, Inki Dae wrote:
> >>> I'm merging this patch series but I found two issues. One is already
> >>> pointed out.
> >>
> >> Fantastic -
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/49d44c71/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/54af87f6/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/90e88a37/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/0962ba13/attachment-0001.html>
This patch is
Reviewed-by: Ian Romanick
On 02/09/2015 03:28 PM, Jan Vesely wrote:
> v2: Remove unrelated change in main()
>
> This is more consistent with the rest, and avoids potential undefined
> behavior (signed overflow) ind drmRandom()
>
> Signed-off-by: Jan Vesely
> ---
> xf86drmRandom
}
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-only-enable-kv-kb-dpm-interrupts-once-v3.patch
Type: text/x-diff
Size: 3723 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/b7f2e814/attachment.patch>
*.
I am not sure, but it feels like there is error changing dpm modes.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/
On Tue, Feb 10, 2015 at 8:26 AM, Christian König
wrote:
> From: Christian König
>
> Emit the EOP twice to avoid cache flushing problems.
>
> Signed-off-by: Christian König
> Cc: stable at vger.kernel.org
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 16 +++-
>
Ping... Any comments on these patches?
Regards,
Jammy
-Original Message-
From: Jammy Zhou [mailto:jammy.z...@amd.com]
Sent: Monday, February 02, 2015 6:05 PM
To: dri-devel at lists.freedesktop.org
Cc: Zhou, Jammy
Subject: [RFC PATCH 0/2] Add drmOpenWithType and drmOpenOnceWithType
For D
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/1098c06c/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/d98cc06e/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/9d63b177/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=66761
--- Comment #13 from KernelBug <3fdd1e5d at opayq.com> ---
Errr typos;
modern harcware/hardware...
I no longer 'see' any SystemIO range conflicts...
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=66761
--- Comment #12 from KernelBug <3fdd1e5d at opayq.com> ---
I was reently told that OpRegion is something that Linux doesn't use, or
something to do with modern harcware not using anymore, bottom line, it's not
being used is what I gather...
To be
chives/dri-devel/attachments/20150210/dfde1166/attachment.html>
|--- |INVALID
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/a30daa57/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/94d0e632/attachment-0001.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/b84750dc/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150210/28e888b2/attachment.html>
On 10 February 2015 at 00:02, Jan Vesely wrote:
> On Mon, 2015-02-09 at 23:32 +, Emil Velikov wrote:
>> On 9 February 2015 at 21:39, Jan Vesely wrote:
>> > Signed-off-by: Jan Vesely
>> Nice one Jan. I've sent similar fixes for drmOpenDevice and
>> drmGetStats a few days ago.
>>
>> Considerin
My notebook Samsung NP700G7A-S01PL was working stable for more than 2 years.
I was using 3.11, 3.17, 3.18, 3.19 (since rc1) and many more successfully.
First hang has happened on 2015-02-08 (23:30) with 3.19-rc5 I was
using for 3 weeks.
So what I'm seeing are two possibly related problems:
1) Ran
59 matches
Mail list logo
