est 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: 23761 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/d423ad00/attachment-0001.obj>
an.
Will do on weekend and mail you about results.
--
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/20150929/1adad92c/attachment.html>
ast time and can do it once more for BARTS.
--
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/20150929/365e6e34/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/790bdc1b/attachment.html>
On Thu, Sep 24, 2015 at 04:26:28PM +0300, Jani Nikula wrote:
> On Thu, 24 Sep 2015, "davej at codemonkey.org.uk" codemonkey.org.uk> wrote:
> > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
> > > Hey,
> > >
> > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
g 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/20150929/f103e46f/attachment.html>
We can now kill a number of glue functions which were sitting between
the common tda998x code and the drm encoder/connector methods. This
results in slightly cleaner code.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 80 +++
1 file chan
Kill the redundant tda998x_priv2 structure now that its only member is
the struct tda998x_priv.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 80 +++
1 file changed, 38 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda9
Move the DRM connector structure into struct tda998x_priv from the old
struct tda998x_priv2.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers
Remove the encoder pointer from struct tda998x_priv, moving the encoder
itself from struct tda998x_priv2 here.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda
Remove the DRM slave encoder compatibility from the TDA998x driver. We
now use the component helpers to manage the binding of DRM sub-drivers.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 146 +++---
1 file changed, 8 insertions(+), 138 del
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 71 +--
1 file changed, 31 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 1285fb354813..1c6fc245514f 100644
--- a/driv
As reading the interrupt registers clears the outstanding interrupts, we
must process all received interrupts to avoid dropping any. Rearrange
the code to achieve this, and properly check for a HPD interrupt from
the CEC_RXSHPDINT register.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/td
C99 types are against the style of the Linux kernel. Convert to using
Linus-friendly types. See https://lwn.net/Articles/113367/ for more
information.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 74 +++
1 file changed, 37 insertions(+
Commit 6833d26ef823 ("drm: tda998x: Fix EDID read timeout on HDMI
connect") used a weak scheme to try and delay reading EDID on a HDMI
connect event. It is weak because delaying the notification of a
hotplug event does not stop userspace from trying to read the EDID
within the 100ms delay.
The so
Rather than always reporting that the interrupt was handled, we should
report whether we did handle the interrupt. Arrange to report IRQ_NONE
for cases where we found nothing to do.
This allows us to (eventually) recover from stuck-IRQ problems, rather
than causing the kernel to solidly lock up.
There is no way 'priv' can be NULL in tda998x_irq_thread() - this can
only happen if request_threaded_irq() was passed a NULL priv pointer,
and we would have crashed long before then if that was the case.
We also always ensure that priv->encoder is correctly setup, which
must have been initialised
Hi,
Here's my currently queued TDA998x development work for 4.4.
* Remove some useless NULL checks here variables can't be NULL.
* Return IRQ_HANDLED only if we handled the IRQ, otherwise return
IRQ_NONE. This avoids locking the system up if the IRQ gets stuck.
* Re-implement a previous patch
Move the wakeup for the frame wait into the armada plane work, to
ensure that it is woken up every time we run a work.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
Convert the overlay plane to use the generic armada plane worker
infrastructure which is shared with the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 48 +
drivers/gpu/drm/armada/armada_crtc.h| 20 ++
dri
Add a plane work implementation, and move the CRTC framebuffer flip
work to it for the primary plane. The idea is to have a common
plane work implementation for both the primary and overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 102 --
Both the CRTC and overlay frames have their own wait queues. It would
make more sense if these were part of the plane - the primary plane for
the CRTC and overlay plane for the overlay.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 22 ++
drivers/
Move the locking for armada_drm_vbl_event_remove() into itself, which
makes this function symmetrical with armada_drm_vbl_event_add().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 2 ++
drivers/gpu/drm/armada/armada_overlay.c | 2 --
2 files changed, 2 insertions(+),
It is not necessary to write dplane->ctrl0 under the CRTC spinlock, as
this is only accessed under process context where the DRM locks will
protect us instead.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Move the write to clear the DMA enable bit, and augment it with clearing
the graphics enable bit for the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 12 ++--
drivers/gpu/drm/armada/armada_overlay.c | 1 -
2 files changed, 10 insertions(+), 3
Provide a common helper to disable either the overlay or the primary
plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 33 +++--
drivers/gpu/drm/armada/armada_crtc.h| 3 +++
drivers/gpu/drm/armada/armada_overlay.c | 7 +--
3 fi
Allocate our own primary plane as an armada_plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
inde
Use drm_primary_helper_create_plane() to create our primary plane, and
register the CRTC with drm_crtc_init_with_planes(). This enables the
primary plane to be initialised with the supported format information.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 34 ++
Introduce a generic armada_plane struct which will eventually be used
for both the primary and overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.h| 5 +
drivers/gpu/drm/armada/armada_overlay.c | 17 +
2 files changed, 14 insertions(+), 8
Use the new drm_universal_plane_init() rather than the legacy
drm_plane_init().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/ar
Rather than using a spinlock, use xchg() to atomically update
dplane->old_fb. This allows us to eliminate dplane->lock.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm
We have two identical places in the overlay code which retire the drm
framebuffer. Factor these out into a common function.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 37 +++--
1 file changed, 17 insertions(+), 20 deletions(-)
diff --g
Include an _ovl infix into the overlay identifiers to separate them from
the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 55 ++---
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/armada/armad
We can do better with armada_drm_crtc_complete_frame_work() - we can
avoid taking the event lock unless a call to drm_send_vblank_event()
is required, and using cmpxchg() and xchg(), we can eliminate the
locking around dcrtc->frame_work entirely.
Signed-off-by: Russell King
---
drivers/gpu/drm/a
When the CRTC is in low power mode, it isn't running, and so there's
no point keeping the CRTC clock enabled. Disable the CRTC clock during
DPMS.
We need to re-enable it in the mode_set callback to ensure that the
variant's compute_clock() continues to see its clock in the expected
state (enabled
Use drm_plane_force_disable() to disable the overlay plane on a mode_set
rather than coding this ourselves.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
Our vblank event code belongs in armada_crtc.c rather than the core of
the driver. Move it there.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 46 ++--
drivers/gpu/drm/armada/armada_crtc.h | 17 +
drivers/gpu/drm/armada/armad
Now that the transition of TDA998x to the component helpers is complete,
remove the non-componentised support from the Armada DRM driver. All
outputs are expected to use the component helpers from now on.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig | 9 ---
drivers/
Here are my queued changes for the Armada DRM driver, for the upcoming
4.4 merge window.
These changes are about updating the driver to some of the more recent
DRM APIs, and removing the non-component support now that has
stabilised. This results in all of armada_output and armada_slave
being rem
On Tue, Sep 29, 2015 at 10:53:02AM +0300, Jani Nikula wrote:
> On Tue, 29 Sep 2015, Rafael Antognolli wrote:
> > This new test makes some basic testing on the proposed drm_dp_aux_dev
> > interface. If the feature is enabled and the drm_dp_aux_dev class is
> > present, it will check for available D
On 09/29/2015 05:55 PM, Yakir Yang wrote:
>
>
> On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
>> When doing the initial setup both the hclk and the aclk need to be
>> enabled otherwise the board will simply hang. This only occurs when
>> building the vop driver as a module, when its built-in the i
On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> Hi Daniel,
>
> On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > > This is u
Hi Sjoerd
We double check this problem, yes, board will hang if aclk is disabled
when setting vop register.
Acked-by: Mark Yao
Thanks for this fix.
On 2015å¹´09æ29æ¥ 17:28, Sjoerd Simons wrote:
> When doing the initial setup both the hclk and the aclk need to be
> enabled otherwise
From: Gustavo Padovan
CRTC's mode_fixup() isn't used anymore in exynos, remove it.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/dr
From: Gustavo Padovan
The only thing mode_fixup was doing was set the adjusted_mode->vrefresh to
60, but it already has the value of 60 when the decon_mode_fixup() is
called. That means this call is actually pointless and can be removed.
Signed-off-by: Gustavo Padovan
---
This is untested as I
From: Gustavo Padovan
The only thing mode_fixup was doing was set the adjusted_mode->vrefresh to
60, but it already has the value of 60 when the fimd_mode_fixup() is
called. That means this call is actually pointless and can be removed.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos
On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
> When doing the initial setup both the hclk and the aclk need to be
> enabled otherwise the board will simply hang. This only occurs when
> building the vop driver as a module, when its built-in the initial setup
> happens to run before the clock fram
On Tue, Sep 29, 2015 at 5:38 PM, Stephen Boyd wrote:
> On 09/29, Rob Clark wrote:
>> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
>> index c1e4325..e1ac97f 100644
>> --- a/drivers/firmware/qcom_scm-32.c
>> +++ b/drivers/firmware/qcom_scm-32.c
>> @@ -500,6 +500,59 @@
Hi Daniel,
On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > This is useful to determine which connector owns this AUX channel.
> >
> > WTF? I
On Tue, Sep 29, 2015 at 02:39:49PM +0200, Christian König wrote:
> On 29.09.2015 13:40, Daniel Vetter wrote:
> >On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
> >>From: Chunming Zhou
> >>
> >>This implements the cgs interface for allocating
> >>GPU memory.
> >>
> >>Reviewed-by: Jam
On Tue, Sep 29, 2015 at 10:55:39PM +0800, kbuild test robot wrote:
> Hi Robert,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please
> ignore]
>
> config: i386-defconfig (attached as .config)
> reproduce:
> git checkout a1d59679ae8f3e7e7659e9723ae3fc69af2532e6
> # s
Thanks Ville for the review, I'm addressing all the issues but have some
questions on the ones mentioned below:
On Tue, Sep 29, 2015 at 05:09:23PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 28, 2015 at 04:45:36PM -0700, Rafael Antognolli wrote:
> > This module is heavily based on i2c-dev. Once lo
On Mon, Sep 28, 2015 at 04:45:36PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
>
> It's possible to know which connector owns this aux channel by looking
> at the re
On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> Hi Rafael,
>
> On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > This is useful to determine which connector owns this AUX channel.
>
> WTF? I posted a patch in August which does exactly that:
> http://lists.free
On 09/25/15 18:50, Arnaud Pouliquen wrote:
> Hello Jyri,
>
> Yes using or not DRM bridge we should be able to have a common
> implementation
>
> Please find,my answer belows
>
> BR,
> Arnaud
>
> On 09/25/2015 04:11 PM, Jyri Sarha wrote:
>> Despite my earlier comment this implementation and the rela
*dev)
> if (!pin || !pci_has_managed_irq(dev))
> return;
>
> + /* Keep IOAPIC pin configuration when suspending */
> + if (dev->dev.power.is_prepared)
> + return;
> +#ifdef CONFIG_PM
> + if (dev->dev.power.runtime_status == RPM_SUSPENDING)
> + return;
> +#endif
> +
> entry = acpi_pci_irq_lookup(dev, pin);
> if (!entry)
> return;
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Gather-debug-info.patch
Type: text/x-patch
Size: 4983 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/c2df64ff/attachment-0001.bin>
Maybe line 294 should become an unlock and should be moved under 295?
julia
On Tue, 29 Sep 2015, kbuild test robot wrote:
> CC: kbuild-all at 01.org
> In-Reply-To: <1443513993-5228-2-git-send-email-daniel.vetter at ffwll.ch>
> TO: Daniel Vetter
> CC: DRI Development
> CC: Daniel Vetter , Intel
On Tue, Sep 29, 2015 at 01:07:25PM +0200, Thierry Reding wrote:
> On Fri, Sep 25, 2015 at 10:29:51AM +0200, Philipp Zabel wrote:
> > Am Montag, den 21.09.2015, 15:15 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote:
> > > > On Wed, Sep 16,
On Mon, 28 Sep 2015, Jens Axboe wrote:
> Hi,
>
> Running 4.3-rc on a new laptop, and I notice that I get these whenever
> powertop --auto-tune is run:
>
> [14954.927920] [ cut here ]
> [14954.927926] WARNING: CPU: 1 PID: 14297 at drivers/gpu/drm/drm_atomic.c:889
> drm_atom
On Tue, 29 Sep 2015, Daniel Vetter wrote:
> With atomic drivers we need to make sure that (at least in general)
> property reads hold the right locks. But the legacy dpms property is
> special and can be read locklessly. Since userspace loves to just
> randomly look at that all the time (like with
Hi Daniel,
Thank you for the patch.
On Monday 28 September 2015 21:46:35 Daniel Vetter wrote:
> ->load is deprecated, bus functions are deprecated and everyone
> should use drm_dev_alloc®ister.
>
> So update the .tmpl (and pull a bunch of the overview docs into the
> sourcecode to increase chanc
On Tue, Sep 29, 2015 at 4:10 PM, Dave Airlie wrote:
> On 30 September 2015 at 01:41, Alex Deucher wrote:
>> On Tue, Sep 29, 2015 at 11:20 AM, Daniel Vetter wrote:
>>> On Tue, Sep 29, 2015 at 02:39:49PM +0200, Christian König wrote:
On 29.09.2015 13:40, Daniel Vetter wrote:
>On Thu, Ju
On Tue, Sep 29, 2015 at 04:28:15PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Monday 28 September 2015 21:46:35 Daniel Vetter wrote:
> > ->load is deprecated, bus functions are deprecated and everyone
> > should use drm_dev_alloc®ister.
> >
> > So update the
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #7 from Alex Deucher ---
Perhaps the radeon driver should just not attempt to register a backlight
interface on Macs since they seem to use the gmux for backlight control. Some
one with more knowledge of mac hw should probably commen
For now, since the GPU is the only upstream consumer, just stuff this
into drm/msm. Eventually if we have other consumers, we'll have to
split this out and make the allocation less hard coded. But I'll punt
on that until I better understand the non-gpu uses-cases (and whether
the allocation *real
Update generated headers to pull in OCMEM register definitions.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 9 +-
drivers/gpu/drm/msm/adreno/a3xx.xml.h | 27 --
drivers/gpu/drm/msm/adreno/a4xx.xml.h | 15 ++--
drivers/gpu/drm/msm/adreno
Add interfaces needed for configuring OCMEM.
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-32.c | 53
drivers/firmware/qcom_scm-64.c | 16 +++
drivers/firmware/qcom_scm.c| 61 ++
drivers/firmware/qc
Signed-off-by: Rob Clark
---
include/linux/qcom_scm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index c536b70..e407c0a 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -26,6 +26,8 @@ struct qcom_scm_hdcp_req {
Add missing #include for types.h to have u32, etc. And fwd declare
'struct cpumask'.
Signed-off-by: Rob Clark
---
include/linux/qcom_scm.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 46d41e4..c536b70 100644
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index e9c306b..c1e4325 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-
Updates for review comments, plus a couple misc qcom-scm fixes
>From original cover-letter:
For devices such as 8x74 and 8084, which have a separate OCMEM block
used by the GPU (and some other devices), rather than an internal GMEM
block inside the GPU, we need a driver to power up and configure
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/20150929/e113cc07/attachment.html>
The minimal sampling period is now configurable via a
dev.i915.oa_event_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Rob
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_pe
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
Adds a static OA unit, MUX + B Counter configuration for basic '3D'
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drv.h| 5 ++
drivers/gpu/drm/i
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl comparable to perf_event_open
that opens a file descriptor for an event source.
Based on our initial experience aiming to use the core perf
infrastructure, this interface is inspired by perf, but focused on
exposing metrics about work running on Gen graph
After some recent progress enabling the Observation Architecture unit
for Gen8+, we can hopefully paint a fairly complete picture of the
requirements for supporting the unit from Haswell to Skylake and so
I'm looking again at the challenges in upstreaming this work.
Considering this, it looked lik
On 09/29, Rob Clark wrote:
> On Tue, Sep 29, 2015 at 5:38 PM, Stephen Boyd wrote:
> > On 09/29, Rob Clark wrote:
> >> diff --git a/drivers/firmware/qcom_scm-32.c
> >> b/drivers/firmware/qcom_scm-32.c
> >> index c1e4325..e1ac97f 100644
> >> --- a/drivers/firmware/qcom_scm-32.c
> >> +++ b/drivers/f
On Thu, Sep 24, 2015 at 5:57 PM, Sudip Mukherjee
wrote:
> On Wed, Sep 09, 2015 at 06:20:40PM +0530, Sudip Mukherjee wrote:
>> If backing->stolen is true then we were freeing backing by calling
>> psb_gtt_free_range() but we called it again after unlocking the mutex.
>> Lets make it NULL after free
On Mon, Sep 28, 2015 at 5:16 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Instead of only enabling the backlight (which seems to set it to max
> brightness), just re-set the current backlight level, which also takes
> care of enabling the backlight if necessary.
>
> Only the radeon_atom_e
Hi Rafael,
On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> This is useful to determine which connector owns this AUX channel.
WTF? I posted a patch in August which does exactly that:
http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html
Can also be pulled i
On 29.09.2015 13:40, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
>> From: Chunming Zhou
>>
>> This implements the cgs interface for allocating
>> GPU memory.
>>
>> Reviewed-by: Jammy Zhou
> I don't see that review anywhere on a m-l ... where is it?
Jammy
On 09/29, Rob Clark wrote:
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index c1e4325..e1ac97f 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -500,6 +500,59 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req,
> u3
On 09/29, Rob Clark wrote:
> Add missing #include for types.h to have u32, etc. And fwd declare
> 'struct cpumask'.
>
> Signed-off-by: Rob Clark
> ---
We should change the arguments for the implementation too.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Found
On 09/29, Rob Clark wrote:
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On Tue, 2015-09-29 at 18:58 +0800, Yakir Yang wrote:
>
> On 09/29/2015 05:55 PM, Yakir Yang wrote:
> >
> >
> > On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
> > > When doing the initial setup both the hclk and the aclk need to
> > > be
> > > enabled otherwise the board will simply hang. This only
On Fri, Sep 25, 2015 at 7:36 AM, Dan Carpenter
wrote:
> The "i" variable should be signed or it leads to a crash in the error
> handling code.
>
> Fixes: 1d263474c441 ('drm/amdgpu: unwind properly in amdgpu_cs_parser_init()')
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
>
> diff --gi
On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
> From: Chunming Zhou
>
> This implements the cgs interface for allocating
> GPU memory.
>
> Reviewed-by: Jammy Zhou
I don't see that review anywhere on a m-l ... where is it?
I stumbled over this patch because it adds a new dev->s
es, I'm loosing interest myself in trying to
> > get them merged, especially ones which are getting on for being 2 years
> > old.
>
> I'm still very interested to see at least the "gpu: imx: fix support for
> interlaced modes" and "gpu: imx: simplify sync polarity setting" merged.
> May I take them into the imx-drm tree separately?
The "gpu: imx:" patches sound like they are standalone, so taking them
through the imx-drm tree would be the easiest.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/8b2a31bc/attachment.sig>
On Tue, Sep 29, 2015 at 04:50:36PM +0800, Jiang Liu wrote:
> So could you please help to apply the attached debug patch to gather
> more information about the regression?
Sure, just did.
I'm sending you a full s/r cycle attempt caught over serial in a private
message.
Thanks.
--
Regards/Gruss,
completely struct_mutex free with the goal to untangle the
> last hold-outs of that lock in the drm core.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-cgs-remove-import_gpu_mem.patch
Type: text/x-patch
Size: 3760 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/1e0f0d74/attachment-0001.bin>
Hi Gerd,
On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
> On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > >
hierry Reding2013-11-28 700 ssize_t (*transfer)(struct
drm_dp_aux *aux,
c197db75 Thierry Reding2013-11-28 701 struct
drm_dp_aux_msg *msg);
e9cf6194 Todd Previte 2014-11-04 702 unsigned i2c_nack_count,
i2c_defer_count;
c197db75 Thierry Reding2013-11-28 @703 };
c197db75 Thierry Reding2013-11-28 704
c197db75 Thierry Reding2013-11-28 705 ssize_t drm_dp_dpcd_read(struct
drm_dp_aux *aux, unsigned int offset,
c197db75 Thierry Reding2013-11-28 706 void *buffer,
size_t size);
c197db75 Thierry Reding2013-11-28 707 ssize_t drm_dp_dpcd_write(struct
drm_dp_aux *aux, unsigned int offset,
c197db75 Thierry Reding2013-11-28 708void *buffer,
size_t size);
c197db75 Thierry Reding2013-11-28 709
c197db75 Thierry Reding2013-11-28 710 /**
c197db75 Thierry Reding2013-11-28 711 * drm_dp_dpcd_readb() - read a
single byte from the DPCD
:: The code at line 703 was first introduced by commit
:: c197db75ff5c1d4f015c7668a3715e230a5d7e27 drm/dp: Add AUX channel
infrastructure
:: TO: Thierry Reding
:: CC: Thierry Reding
---
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: 6062 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/c948814c/attachment-0001.obj>
tachments/20150929/c14adf29/attachment-0001.html>
org.log
--
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/20150929/90bbb2ce/attachment.html>
When doing the initial setup both the hclk and the aclk need to be
enabled otherwise the board will simply hang. This only occurs when
building the vop driver as a module, when its built-in the initial setup
happens to run before the clock framework shuts of unused clocks
(including the aclk).
Whi
l is ok after Alt-Tab the bring back a reduced window.
--
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/20150929/271195a3/attachment.html>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_audio.c
between commit:
b8abe859c9d6 ("drm/i915: Always call the adjusted mode 'adjusted_mode'")
from the drm-intel tree and commit:
9e5a3b529e84 ("drm: Remove the 'mode' argument from dr
1 - 100 of 136 matches
Mail list logo
