http://inordinately.ewboynhado.com/ Make your loved one contented
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/d11906bd/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/d17e45ba/attachment.html>
t gotten to those yet.
I'll probably apply them later today.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/15d53193/attachment-0001.sig>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/1f417054/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=79591
--- Comment #7 from Stefan Ringel ---
(In reply to Martin Peres from comment #5)
> Sorry for the wait. Can you try to reproduce the issue with this patch?
Your patch works. Thanks. I cannot reproduce it with this patch.
--
You are receiving th
-nano-HOWTO.txt this section should
be named "Return:". But it seems that at least in DRM "Returns:" is used
much more often (89:31), so with or without this addressed:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/8517c445/attachment.sig>
ize: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/842e1a6d/attachment.sig>
On Sun, Jul 13, 2014 at 10:32:41PM +0200, Paul Bolle wrote:
> Paul Bolle schreef op wo 02-07-2014 om 10:53 [+0200]:
> > On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote:
> > > This does not ring any bells to me (but that doesn't prove anything). A
> > > bisect result would be awesome.
>
> The
On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote:
> Please test the below patch, thanks.
> -Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 82e7d57f0a8a..f0be855ddf45 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/dr
On Mon, Jul 14, 2014 at 09:13:40AM +0200, Paul Bolle wrote:
> On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote:
> > Please test the below patch, thanks.
> > -Daniel
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 82e7d57f0a8a..f
On 12.07.2014 18:00, Christian K?nig wrote:
> Am 11.07.2014 18:22, schrieb Alex Deucher:
>> On Fri, Jul 11, 2014 at 12:18 PM, Christian K?nig
>> wrote:
>>> Am 11.07.2014 18:05, schrieb Jerome Glisse:
>>>
On Fri, Jul 11, 2014 at 12:50:02AM +0300, Oded Gabbay wrote:
> To support HSA on KV,
On Sat, 2014-07-12 at 07:42 +1000, Dave Airlie wrote:
> > +/* The 64-bit ABI is the authoritative version. */
> > +#pragma pack(push, 8)
> > +
>
> Don't do this, pad and align things explicitly in structs.
>
> > +struct kfd_ioctl_create_queue_args {
> > + uint64_t ring_base_address;
On 11.07.2014 06:50, Oded Gabbay wrote:
> @@ -5876,8 +5871,13 @@ int cik_ib_parse(struct radeon_device *rdev, struct
> radeon_ib *ib)
> */
> int cik_vm_init(struct radeon_device *rdev)
> {
> - /* number of VMs */
> - rdev->vm_manager.nvm = 16;
> + /*
> + * number of VMs
> +
Am 14.07.2014 09:38, schrieb Michel D?nzer:
> On 11.07.2014 06:50, Oded Gabbay wrote:
>> @@ -5876,8 +5871,13 @@ int cik_ib_parse(struct radeon_device *rdev, struct
>> radeon_ib *ib)
>>*/
>> int cik_vm_init(struct radeon_device *rdev)
>> {
>> -/* number of VMs */
>> -rdev->vm_manage
part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/6deb7445/attachment.sig>
ure
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/192687c0/attachment.sig>
ot available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/ee381e94/attachment-0001.sig>
> I vote for HSA module that expose ioctl and is an intermediary with the
> kernel driver that handle the hardware. This gives a single point for
> HSA hardware and yes this enforce things for any hardware manufacturer.
> I am more than happy to tell them that this is it and nothing else if
> they
Hi Thierry,
Thank you for comment.
On 07/10/2014 04:38 PM, Thierry Reding wrote:
> On Thu, Jul 10, 2014 at 10:06:07AM +0900, YoungJun Cho wrote:
>> On 07/10/2014 12:22 AM, Thierry Reding wrote:
>>> On Tue, Jul 08, 2014 at 09:39:38AM +0900, YoungJun Cho wrote:
To support LCD I80 interface, th
you don't have to rely on polling. You
can simply pass control of the bus to the peripheral (via a BTA
sequence) and then wait for the peripheral to signal TE.
That said, I've been doing some research and it seems like we have a
somewhat similar feature on Tegra. What happens there is that there are
three GPIO pins that can be repurposed for TE signalling. But as opposed
to using them as interrupts the display controller can be configured to
use them, upon which it will automatically handle the TE signal by
sending the next frame.
So we have at least two very different implementations of this on two
different SoCs. Further the specification explicitly recommends using
the BTA sequence and DSI protocol to wait for TE. So I still think that
controllers that provide an additional, non-spec compliant method to
signal TE should handle it separately rather than within DSI. Otherwise
we essentially need to make the DSI "core" aware of all these quirks,
and I'd rather avoid that.
> As Inki commented before, I'll try to use remote-endpoint property of DSI
> device node in exynos DSIM driver and call FIMD notifier.
Sounds like it matches what I said above. I'm not a huge fan of
notifiers, but if it works for you I suppose that's fine. The
alternative would be to directly call a FIMD function, which is
somewhat more explicit than a notifier.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/ff0e3a59/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=79591
--- Comment #8 from Martin Peres ---
(In reply to Stefan Ringel from comment #7)
> (In reply to Martin Peres from comment #5)
>
> > Sorry for the wait. Can you try to reproduce the issue with this patch?
>
> Your patch works. Thanks. I cannot re
drm_display_mode. And
VSPDLYS as well as VSPDLYE sound like they may be vsync_start and
vsync_end of the same structure.
As for the others, maybe if you could explain what exactly they are we
may be able to find a better fit.
Thierry
-- next part --
A non-text attachmen
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #15 from EmanueL Czirai ---
Hi. I believe that I am in the exact same situation as the OP.
The system locks up in about 10 (or sometimes 14-15) seconds of boot time and I
don't have to go past typing my luks password to mount rootfs.
y not be all that many) there's always a transparent
RGB/LVDS bridge, so the "connector" is in fact LVDS, not RGB, even if
the display controller outputs RGB directly.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type:
Hi Thierry,
On 07/14/2014 06:41 PM, Thierry Reding wrote:
> On Mon, Jul 14, 2014 at 06:22:39PM +0900, YoungJun Cho wrote:
>> Hi Thierry,
>>
>> Thank you for comment.
>>
>> On 07/10/2014 04:38 PM, Thierry Reding wrote:
>>> On Thu, Jul 10, 2014 at 10:06:07AM +0900, YoungJun Cho wrote:
On 07/10/
A static analysis tool tells me that we could try to read an
uninitialized 'ret' value. Plug that.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/
shouldn't be a problem.
With the above, you could make the DSIM handle the TE signal interrupts
and trigger the DC using the new exynos_drm_crtc_send_frame() function.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/6e417fca/attachment.sig>
es/dri-devel/attachments/20140714/682931d2/attachment-0001.html>
We could be using uninitialized fields of the header in
drm_dp_encode_sideband_msg_hdr(), for instance hdr->somt is set to 1 in
the first patcket but never set to 0 otherwise.
Always clear the header at the start then.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #16 from EmanueL Czirai ---
Created attachment 142981
--> https://bugzilla.kernel.org/attachment.cgi?id=142981&action=edit
dmesg with radeon.test=3
with radeon.test=3 this took about 80 seconds to show me the boot screen text,
the s
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #17 from EmanueL Czirai ---
Created attachment 142991
--> https://bugzilla.kernel.org/attachment.cgi?id=142991&action=edit
dmesg with radeon.test=0
here is another dmesg in which the only thing that I've changed(from the
previous dm
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #18 from EmanueL Czirai ---
Created attachment 143001
--> https://bugzilla.kernel.org/attachment.cgi?id=143001&action=edit
kernel .config used in previous dmesgs
3.16-rc4
--
You are receiving this mail because:
You are watching th
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #19 from EmanueL Czirai ---
Created attachment 143011
--> https://bugzilla.kernel.org/attachment.cgi?id=143011&action=edit
ati catalyst screenshot of the Information tab when both graphic cards were on
found a screenshot of ATI Cata
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/c230e61c/attachment.html>
On Tue, Jul 8, 2014 at 9:59 AM, Daniel Drake wrote:
> Hi Sean,
>
Hi Daniel,
Sorry for the delay in response.
> While looking at the following commit I noticed something:
>
> commit f041b257a8997c8472a1013e9f252c3e2a1d879e
> Author: Sean Paul
> Date: Thu Jan 30 16:19:15 2014 -0500
>
> drm/
Close this bug because it does indeed run or keep it open for performance
> issues?
--
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/20140714/e3f61d69/attachment-0001.html>
On Sat, Jul 12, 2014 at 7:47 PM, Stefan Br?ns
wrote:
> Low/high bytes were for manufacturer and product ID were swapped.
> Monitor name in ELD data is not zero terminated, use length field from
> ELD data and initialize remaining bytes to 0.
>
> Signed-off-by: Stefan Br?ns
I squashed this into y
On Sat, Jul 12, 2014 at 7:47 PM, Stefan Br?ns
wrote:
> Valid values are 1 to 251 for 0 to 500 ms latency, 0 for unknown
> and 255 for audio/video unsupported by sink, according to HDMI 1.3 spec.
> Also matches Radeon HDA verb 0xf7b documentation.
>
> Signed-off-by: Stefan Br?ns
Applied. Thanks.
On Sat, Jul 12, 2014 at 7:47 PM, Stefan Br?ns
wrote:
> No need to continue with the loops once we've matched
> the appropriate connector.
> See commit 8a992ee14551eae53fd3ab6c2dc8e06ba6fff174
Applied. Thanks.
Alex
>
> Signed-off-by: Stefan Br?ns
> ---
> drivers/gpu/drm/radeon/dce6_afmt.c | 8
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/f6e58e99/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140714/95467b8a/attachment.html>
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/20140714/62ac4363/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/99142096/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #20 from EmanueL Czirai ---
Created attachment 143031
--> https://bugzilla.kernel.org/attachment.cgi?id=143031&action=edit
sloppy patch try
I modified your previous patch slightly(because some hunks failed and
compilation error), bu
.15 and 3.16.
Thanks in advance,
Christian.
--
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/20140714/07d83fcc/attachment.html>
Daniel Vetter schreef op ma 14-07-2014 om 09:18 [+0200]:
> On Mon, Jul 14, 2014 at 09:13:40AM +0200, Paul Bolle wrote:
> > On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 82e7d5
pts/Makefile.build:257: recipe for target
'drivers/gpu/drm/radeon/radeon_gem.o' failed
--
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/20140714/bbaf5b4f/attachment.html>
Inki,
You have acks, and you have the tested-bys you requested. Can you
please pick this up quickly so that we can have graphics working with
an upstream kernel on chromebooks?
Dave, if Inki keeps dragging his feet like this can you please apply
this series directly? These delays are ridiculous a
tel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/d57c6616/attachment.html>
if (count == 0)
> goto prune;
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 251b75e6bf7a..abaed07a4b3b 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -532,6 +532,7 @@ struct drm_connector {
> void *helper_private;
>
> /* forced on connector */
> + struct drm_cmdline_mode cmdline_mode;
> enum drm_connector_force force;
> uint32_t encoder_ids[DRM_CONNECTOR_MAX_ENCODER];
> struct drm_encoder *encoder; /* currently active encoder */
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 7997246d4039..28ead2b6f59b 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -77,7 +77,6 @@ struct drm_fb_helper_funcs {
>
> struct drm_fb_helper_connector {
> struct drm_connector *connector;
> - struct drm_cmdline_mode cmdline_mode;
> };
>
> struct drm_fb_helper {
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/13d872fd/attachment-0001.html>
ives/dri-devel/attachments/20140714/aca264e9/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/3f537457/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/39714d1c/attachment.html>
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/20140714/1b233846/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/d9da873b/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140714/9fe5f186/attachment.html>
or some drivers.
Closing.
--
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/20140714/de9a73bb/attachment-0001.html>
In some cases we fetch the edid in the detect() callback
in order to determine what sort of monitor is connected.
If that happens, don't fetch the edid again in the get_modes()
callback or we will leak the edid.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon
just updated 2 hours ago.
--
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/20140714/2f1c0863/attachment.html>
On 7/12/2014 3:29 AM, Daniel Vetter wrote:
> On Tue, Jul 08, 2014 at 10:31:59AM +0530, sonika.jindal at intel.com wrote:
>> From: Ville Syrj?l?
>>
>> Sprite planes support 180 degree rotation. The lower layers are now in
>> place, so hook in the standard rotation property to expose the feature
>
On Fri, Jul 11, 2014 at 10:38 AM, Alexandre Courbot
wrote:
> Hi Ben,
>
>
> On 07/11/2014 10:07 AM, Ben Skeggs wrote:
>>
>> On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot
>> wrote:
>>>
>>> This series adds support for reclocking on GK20A. The first two patches
>>> touch
>>> the clock subsyste
On Fri, Jul 11, 2014 at 7:54 PM, Peter De Schrijver
wrote:
> On Fri, Jul 11, 2014 at 03:49:06AM +0200, Alex Courbot wrote:
>> On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
>> > On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
>> >> This series adds support for reclocking on G
On Tue, Jun 17, 2014 at 8:02 PM, Stephane Viau wrote:
> Iommu support is slightly modified in order to make sure
> that MDP iommu is properly cleaned up if a probe deferral is
> requested. Before this change, IOMMU faults would occur if the
> probe failed (-EPROBE_DEFER).
>
> Signed-off-by: Stepha
64 matches
Mail list logo
