On Mon, May 18, 2015 at 11:24 PM, Dave Airlie wrote:
> On 19 May 2015 at 12:27, Michel Dänzer wrote:
>> On 19.05.2015 01:24, Alex Deucher wrote:
>>>
>>> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct
>>> *work)
>>> struct drm_connector *connector;
>>>
>>> /*
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/230a0fff/attachment.html>
.org/archives/dri-devel/attachments/20150518/c5d507d7/attachment.html>
TE;
>
vrefresh can legitimately be zero, which makes this FIMD_DEFAULT_FRAMERATE
assignment problematic rather than harmless.
If it's zero, you can find a vrefresh value with drm_mode_vrefresh, which
will calculate it for you.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/6b003875/attachment.html>
Hello Ben Skeggs,
The patch 639c308effb9: "drm/nouveau/fb: namespace + nvidia gpu names
(no binary change)" from Jan 14, 2015, leads to the following static
checker warning:
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c:1297
gk104_ram_train_init()
error: potential null derefe
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/20150518/76bb27de/attachment.html>
.340269] ---[ end trace 3e0a38b7fc789e38 ]---
[ 33.344890]
[ 33.368364] init: bluetooth main process (2019) terminated with status 1
[ 33.399413] init: bluetooth main process ended, respawning
* Starting Mount filesystems on boot
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/bb86abc7/attachment.html>
Panel DPMS got broken after adding support for atomic modesetting.
Fix it by making RGB output use of generic atomic DPMS helpers.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/rgb.c | 49 -
1 file changed, 17 insertions(+), 32 deletions(-)
h Mesa-lib
In this case, should I generate a xorg.conf then use it ?
Regards,
Kristof
--
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/20150518/c33bf74e/attachment.html>
On Mon, May 18, 2015 at 6:41 PM, Julian Margetson wrote:
> On 5/18/2015 4:59 PM, Alex Deucher wrote:
>
Snip
> * Starting NTP server ntpd [ 28.819002] Unable to handle kernel
> paging request for data at address 0x0008
> [ 28.860330] Faulting instruction address: 0xc04a5218
> [
On 5/18/2015 4:59 PM, Alex Deucher wrote:
> On Mon, May 18, 2015 at 1:48 PM, Julian Margetson wrote:
>> On 5/18/2015 12:08 PM, Alex Deucher wrote:
>>> On Sun, May 17, 2015 at 7:20 PM, Julian Margetson
>>> wrote:
Kernels 4.03 and 4.04 oops with HDMI connection on Acube Sam460ex amcc
460
On Fri, May 8, 2015 at 5:21 PM, Peter Zijlstra wrote:
>
> So I've not yet went through the entire series; but I'm wondering if its
> at all possible to re-use some of this work:
>
> lkml.kernel.org/r/1428453299-19121-1-git-send-email-sukadev at
> linux.vnet.ibm.com
>
> That's for a Power8 HV call
To allow for pmus that may have internal buffering (e.g. the hardware
itself writes out data to its own circular buffer which is only
periodically forwarded to userspace via perf) this ioctl enables
userspace to explicitly ensure it has received all samples before a
point in time.
v2: return int e
This makes sure we've stopped touching oacontrol before we start
resetting OA, PM and clock gating. Shouldn't strictly be needed since we
know that oacontrol will have been disabled before we start destroying
an event but it seems worth highlighting that update_oacontrol() could
still be running as
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer and this patch exposes that
capability to userspace via the perf interface.
To start with this only enables the A (aggregating) counters with the
simplest configuration requirements.
2015-05-18 Daniel Stone :
> Hi,
>
> On Monday, May 18, 2015, Gustavo Padovan wrote:
>
> > Hi Tobias,
> >
> > 2015-05-15 Tobias Jakobi >:
> > > I did another run with drm.debug=0xff and also tried to figure out where
> > the
> > > div-by-zero comes from.
> > >
> > > The only division I see is in
riginal barts launch. Most cards just used the
fan profile set up in the vbios.
--
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/atta
On 7 May 2015 15:58, "Chris Wilson" wrote:
>
> On Thu, May 07, 2015 at 03:15:50PM +0100, Robert Bragg wrote:
> > + /* We bypass the default perf core perf_paranoid_cpu() ||
> > + * CAP_SYS_ADMIN check by using the PERF_PMU_CAP_IS_DEVICE
> > + * flag and instead authenticate based on
offset = 0x%x, vaddr
= %p",
> > + dev_priv->oa_pmu.oa_buffer.gtt_offset,
> > + dev_priv->oa_pmu.oa_buffer.addr);
> > +
> > + return 0;
> > +
> > +err_unref:
> > + drm_gem_object_unreference_unlocked(&bo->base);
>
> But what I really what to say was:
> mutex deadlock^^^
Yikes, I've pushed an updated patch addressing this and can reply with a
new patch here in a bit.
Thanks,
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/284de99d/attachment-0001.html>
ar at
screen as before, maybe even worse. I've tested L4D2 only.
--
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/20150518/c32003c8/attachment.html>
ector_status_connected) {
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
+ DRM_INFO("connector_status_connected\n");
+
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
&&
radeon_dp_getsinktype(radeon_connector) ==
CONNECTOR_OBJECT_ID_DISPLAYPORT)
@@ -486,14 +490,21 @@ void radeon_audio_detect(struct drm_connector *connector,
else
radeon_encoder->audio = rdev->audio.hdmi_funcs;
+ DRM_INFO("audio: 0x%p\n", radeon_encoder->audio);
+
dig->afmt->pin = radeon_audio_get_pin(encoder);
if (drm_detect_monitor_audio(radeon_connector_edid(connector)))
{
+ DRM_INFO("enabling audio\n");
radeon_audio_enable(rdev, dig->afmt->pin, 0xf);
} else {
+ DRM_INFO("disabling audio\n");
radeon_audio_enable(rdev, dig->afmt->pin, 0);
dig->afmt->pin = NULL;
}
+ DRM_INFO("pin: 0x%p\n", dig->afmt->pin);
} else {
+ DRM_INFO("connector_status_disconnected\n");
+ DRM_INFO("pin: 0x%p\n", dig->afmt->pin);
radeon_audio_enable(rdev, dig->afmt->pin, 0);
dig->afmt->pin = NULL;
}
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-properly-select-encoder-in-radeon_audio_d.patch
Type: text/x-patch
Size: 3410 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/64d833b4/attachment-0001.bin>
Hi Tobias,
2015-05-15 Tobias Jakobi :
> Hello,
>
> I did another run with drm.debug=0xff and also tried to figure out where the
> div-by-zero comes from.
>
> The only division I see is in fimd_calc_clkdiv() (which is called by
> fimd_commit()). So it looks like 'ideal_clk' is zero when calling
On Mon, May 18, 2015 at 10:06:40AM +0200, Maarten Lankhorst wrote:
> Drivers may need to store the state of shared resources, such as PLLs
> or FIFO space, into the atomic state. Allow this by making it possible
> to subclass drm_atomic_state.
>
> Changes since v1:
> - Change member names for func
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4a6314b0/attachment.html>
, just ask.
--
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/20150518/125564a7/attachment-0001.html>
The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.
Signed-o
I2CM_ADDRESS became a MESS, fix it, also change guarding define
to __DW_HDMI_H__ , since the driver is not IMX specific.
Signed-off-by: Vladimir Zapolskiy
---
drivers/gpu/drm/bridge/dw_hdmi.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hd
This change adds support of internal HDMI I2C master controller,
originally the controller has its own separate driver written from
scratch http://patchwork.ozlabs.org/patch/405100 but due to shared
register space and interrupt with HDMI driver, it makes sense to
merge the code of both drivers.
Th
On Mon, May 18, 2015 at 3:04 PM, Christian König
wrote:
> On 18.05.2015 20:50, Denys Vlasenko wrote:
>>
>> On 05/18/2015 08:06 PM, Christian König wrote:
>>>
>>> I'm actually surprised how often people come along with that. The last
>>> time we tried this it caused a noticeable performance drop.
uff works on BE systems.
--
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/20150518/be21073d/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/28eefce8/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/20150518/cf18b1fd/attachment.html>
On 5/18/2015 12:08 PM, Alex Deucher wrote:
> On Sun, May 17, 2015 at 7:20 PM, Julian Margetson wrote:
>> Kernels 4.03 and 4.04 oops with HDMI connection on Acube Sam460ex amcc
>> 460ex powerpc board.
>>
>> 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 is the first bad commit
>>
>> commit 016a255b7835
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4652fca5/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/79cfefe3/attachment-0001.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/20150518/d4093caa/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/20150518/192d12d1/attachment.html>
- make it static
- fix mask/bool handling for last param
Signed-off-by: Alex Deucher
Cc: stable at vgter.kernel.org
---
drivers/gpu/drm/radeon/radeon_audio.c | 18 +-
drivers/gpu/drm/radeon/radeon_audio.h | 2 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/dr
Need to handle DVI where we way end up with an analog encoder
in some cases.
Reported-by: Julian Margetson
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_audio.c | 18 ++
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
2 file
Since we are messing with state in the worker.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 71
Retry the dpcd fetch several times. Some eDP panels
fail several times before the fetch is successful.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73530
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_dp.c | 20 +++-
1 file ch
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 8
drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 3e3290c..ed173d3 100644
0
> 419e000c 7d2903a6
> [ 34.212674] 4e800420 3860 4e800020 81231cd8 <81290008> 2f89
> 4d9e0020 7d2903a6
> [ 34.376219] ---[ end trace 803e15e46b991816 ]---
> [ 34.380843]
> * Starting Mount filesystems on boot[ OK ]
> *
>
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-properly-select-encoder-in-radeon_audio_d.patch
Type: text/x-patch
Size: 2848 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/22f77d32/attachment.bin>
Hi Dave,
drm-intel-next-2015-05-08:
- skl plane scaler support (Chandra Kondru)
- enable hsw cmd parser (Daniel and fix from Rebecca Palmer)
- skl dc5/6 support (low power display modes) from Suketu&Sunil
- dp compliance testing patches (Todd Previte)
- dp link training optimization (Mika Kahola)
Drivers may need to store the state of shared resources, such as PLLs
or FIFO space, into the atomic state. Allow this by making it possible
to subclass drm_atomic_state.
Changes since v1:
- Change member names for functions to atomic_state_(alloc,clear)
- Change __drm_atomic_state_new to drm_atom
PS : can someone tells me if it this an "abnornal" things in the last dmesg |
egrep 'drm|radeon' please ?
Thanks and have a nice day
Kristof
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachme
amd/amdkfd/cik_int.h
> create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.c
> create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.h
> create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>
âFixing Alex's email address.â
âSorry.â
--
Oded
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/1a96a4a1/attachment.html>
Hi Dave,
Here is the pull request of amdkfd for 4.2
drm-amdkfd-next-2015-05-18:
- Add the interrupts & events modules, including new IOCTLs to create and wait
on events. The HSA RT open source stack is mainly using events to know when
a dispatched work has been completed. In addition, this
On Fri, May 15, 2015 at 04:12:27PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> old_plane_state is already assigned to old_state->plane_states[i] inside
> for_each_plane_in_state(). Here we remove an the extra assignment.
>
> Signed-off-by: Gustavo Padovan
Applied to topic/drm-mis
On Wed, May 13, 2015 at 12:30:46PM +0100, Jon Hunter wrote:
> Commit 4f71d0cb76339 ("drm/dp: add a hw mutex around the transfer
> functions. (v2)"), renamed the functions drm_dp_aux_register_i2c_bus()
> and drm_dp_aux_unregister_i2c_bus() to drm_dp_aux_register() and
> drm_dp_aux_unregister(), resp
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/6ec13970/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4633cecc/attachment.html>
52 matches
Mail list logo
