>
Two things,
a) pull request from ssh:// please fix scripts to generate git:// URLs,
b) ioctls with bool in them make me worry, four packed bool's even more,
4 packed bools with a 64-bit straight after them put me over the not
pulling this edge.
I don't trust bools in ioctl d
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/1544a560/attachment-0001.html>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/87e179f5/attachment.html>
> Don't pollute the dmesg with EDID read success message as an error.
> Printing as debug should be fine.
>
> Signed-off-by: Krzysztof Kozlowski
Right, dev_err() is not right.
Thank you for sending the patch.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/gpu/drm/exynos/exynos
ng 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/20150519/fd8d5605/attachment.html>
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;
>
> /* this should take a mutex */
> + mutex_lock(&mode_config->mutex);
This comment can be removed?
--
Earthling Mich
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;
>>
>> /* this should take a mutex */
>> + mutex_lock(&mode_config->mutex
straight after them put me over the not
pulling this edge.
>
> I don't trust bools in ioctl defintions, please use explicitly sized
types.
>
> Dave.
Thanks Dave,
No problem, I'll fix and resend it today.
Oded
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/69a311fc/attachment.html>
May 18 21:38:55 arcadia kernel: [0.00] Linux version
4.0.0-1-amd64 (debian-kernel at lists.debian.org) (gcc version 4.9.2
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)
May 18 21:38:55 arcadia kernel: [3.467818] [drm]
radeon/VERDE_mc2.bin: 31500 bytes
May 19 00:06:08 arcadia ker
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops
Hello,
the subject is missing "ps8622" before the :. Should I resend for that?
On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote:
> drivers/gpu/drm/bridge/ps8622.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
Best regards
Uwe
--
Pengutronix e.
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops
On Thu, 14 May 2015, Matt Roper wrote:
> On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
>> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
>> always on for wm calculation (v4)") fixes a null pointer dereference.
>> Setting the primary and cursor panes to false i
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also there is a variant to find optional gpios that returns NULL if
there is no
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/18a14bec/attachment.html>
On Mon, May 18, 2015 at 11:28:47PM -0400, Alex Deucher wrote:
> 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
From: frank
v3: switch to udev/sysfs for the enumeration
Signed-off-by: Frank Min
Reviewed-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jammy Zhou
---
Makefile.am | 7 +++--
xf86drm.c | 103
xf86drm.h | 19 ++
ent was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/f53621bb/attachment.sig>
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/20150519/5d4f030c/attachment.sig>
ignature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/dddba69a/attachment.sig>
Hello,
On Tue, May 19, 2015 at 10:06:54AM +0200, Thierry Reding wrote:
> On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote:
> > Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> > which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> > p
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is c
Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and
of_drm_find_bridge.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_bridge.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridg
¾Ð¼ она наÑÐ¸Ð½Ð°ÐµÑ ÑменÑÑаÑÑÑÑ Ð¸
игÑа вÑлеÑаеÑ
--
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/attachment
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/0c4de147/attachment.html>
with two different drawables,
each call destroying the previous drawable.
--
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/20150
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/65abb551/attachment-0001.html>
(60 before)
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/20150519/69bd7f8c/attachment.html>
Hello Kirill A. Shutemov,
The patch 026abc333205: "gma500: initial medfield merge" from Mar 8,
2012, leads to the following static checker warning:
drivers/gpu/drm/gma500/mdfld_intel_display.c:102
mdfldWaitForPipeEnable()
warn: masked condition '(temp & (1 << 30)) == 1' is always
On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
> Allow drm_bridge objects to link to each other in order to form an encoder
> chain. The requirement for creating a chain of bridges comes because the
> MSM drm driver uses up its encoder and bridge objects for blocks within
> the SoC
On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote:
> Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and
> of_drm_find_bridge.
>
> Signed-off-by: Archit Taneja
You also need to pull in the kerneldoc into the drm.tmpl DocBook template
to include into the drm do
Hi Vladimir,
Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy:
> 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
Acked-by: Philipp Zabel
regards
Philipp
Hi Dave,
Resending the pull request of amdkfd for 4.2 after fixing what you requested
(bool -> uint32_t and using git:// instead of ssh://)
drm-amdkfd-next-2015-05-19:
- Add the interrupts & events modules, including new IOCTLs to create and wait
on events. The HSA RT open source stack is main
Hi Vladimir,
Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy:
> 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
Acked-by: Philipp Zabel
regards
Philipp
Hi Vladimir,
Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy:
> 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 fro
Hi Sean,
I'm taking over this patch series from Kamil for the time being with his
permission (he's switching jobs and moving house so he can't spend any time
on this for a while).
On 05/13/15 13:10, Sean Young wrote:
> On Mon, May 04, 2015 at 07:32:59PM +0200, Kamil Debski wrote:
>> From: Hans Ve
Hi,
On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
>> Allow drm_bridge objects to link to each other in order to form an encoder
>> chain. The requirement for creating a chain of bridges comes because the
>> MSM drm driver uses up its
On 05/19/2015 03:07 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote:
>> Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and
>> of_drm_find_bridge.
>>
>> Signed-off-by: Archit Taneja
>
> You also need to pull in the kerneldoc into t
Hi,
I'm testing the vanilla kernel on prototype boards for Intel Skylake.
The graphics adapter on those boards identifies like this:
00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller])
Subsystem: 1734:121c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParE
On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
>> dma_alloc_coherent() can return memory in the vmalloc range.
>> virt_to_page() cannot handle such addresses and crashes. This
>> patch detects such cases and obtains the stru
+intel-gfx
On Tue, 19 May 2015, Rainer Koenig wrote:
> Hi,
>
> I'm testing the vanilla kernel on prototype boards for Intel Skylake.
> The graphics adapter on those boards identifies like this:
>
> 00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller])
> Subsystem: 1734:121c
>
drm_property_unreference_blob_locked() is static and unused,
drop it.
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f06..6e60f71 100644
---
Am 19.05.2015 um 13:41 schrieb Jani Nikula:
>
> For brand new platforms you should be running drm-intel-nightly branch
> from http://cgit.freedesktop.org/drm-intel.
Thanks, will try out next.
> Double check that you have either i915.preliminary_hw_support=1 module
> parameter set or CONFIG_DRM_
The recently added iommu code in the nouveau driver fails to build
when the IOMMU support is disabled:
drivers/gpu/drm/nouveau/nouveau_platform.c: In function
'nouveau_platform_probe_iommu':
drivers/gpu/drm/nouveau/nouveau_platform.c:113:41: error: 'const struct
iommu_ops' has no mem
To avoid t
eau/platform: probe IOMMU if present")
Acked-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/20150519/b896fe1c/attachment.sig>
Hello,
On 2015-05-18 23:02, Gustavo Padovan wrote:
> 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
>> > >
From: Alexey Skidanov
This patch fixes a bug where the number of watch points
was shown before it was actually calculated
Signed-off-by: Alexey Skidanov
Cc: stable at vger.kernel.org
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++--
1 file changed, 2 insertion
Hi Tobias,
On 19 May 2015 at 14:53, Tobias Jakobi wrote:
> On 2015-05-18 23:02, Gustavo Padovan wrote:
>> So better try this. Ideally fimd_mode_fixup should go away too, I'll do a
>> proper
>> patch once we know this works.
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/
Hi Dave,
Scattering of random drm core patches. Bunch of atomic prep work too, but
the final bits for blob properties, atomic modesets and lifting the
experimental tag on the atomic ioctl are still blocked on Daniel Stone
finalizing and testing the weston support for it. I hope that we can get
it
Hi Dave,
This pull request contains mainly some regression fixups and code cleanups.
Summary:
- Use generic function to get buffer count instead of specific one.
In case of Exynos DRM, There was a special case which decides pixel
format of a given buffer according to planer types, which is
The parallel-display driver used an undocumented, non-standard property
"fsl,panel" to optionally associate with a drm_panel device. This patch
fixes the driver to use the same OF graph bindings as the LDB driver
instead:
parallel-display {
compatible = "fsl,imx-parallel-display";
Hi,
this patch factors out the mostly identical imx_drm_encoder_get_mux_id and
rockchip_drm_encoder_get_mux_id functions into a common helper to parse
the active endpoint and two inline functions to return its id or port id.
All prerequisites are now upstream. I'd like to get an Acked-by from the
It is replaced by drm_of_encoder_active_endpoint_id.
Suggested-by: Daniel Kurtz
Reviewed-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
drivers/gpu/drm/rockch
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.
This can be used to determine input mux setting from endpoint or port ids.
Suggested-by: Daniel Kurtz
Reviewed-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
It is replaced by drm_of_encoder_active_port_id.
Suggested-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +-
drivers/gpu/drm/imx/imx-drm-core.c | 30 --
drivers/gpu/drm/imx/imx-drm.h | 2 --
drivers/gpu/drm/imx/imx-ld
This is a convenience function to add all planes for a crtc,
similar to add_affected_connectors. This will be used in
drm_atomic_helper_check_modeset, but drivers can call it too
when they need to recalculate all state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 32 +
Drivers may need to recalculate plane state when a modeset occurs,
not reliably adding them might cause hard to debug bugs.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/driv
drm_atomic_helper_commit_planes calls all atomic_begin's first,
then updates all planes, finally calling atomic_flush.
Some drivers may want to things like disabling irq's
from their atomic_begin, in which case a second call to atomic_begin
will splat. By using commit_planes_on_crtc on each crtc i
Hey Daniel,
On 2015-05-19 16:06, Daniel Stone wrote:
> Hi Tobias,
>
> On 19 May 2015 at 14:53, Tobias Jakobi
> wrote:
>> On 2015-05-18 23:02, Gustavo Padovan wrote:
>>> So better try this. Ideally fimd_mode_fixup should go away too, I'll
>>> do a
>>> proper
>>> patch once we know this works.
>
On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote:
> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra
> wrote:
> > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:
> >
> >> I've changed the uapi for configuring the i915_oa specific attributes
> >> when calling perf_event_ope
On Tue, May 19, 2015 at 9:40 AM, Uwe Kleine-König
wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Also there
On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
> On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> >On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
> >>+void drm_bridge_post_disable(struct drm_bridge *bridge)
> >>+{
> >>+ if (!bridge)
> >>+ return;
> >>+
> >>
Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_cr
This patch adds support for ARGB1555, ABGR1555, RGBA5551, and BGRA5551
in-memory formats.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 4
drivers/gpu/ipu-v3/ipu-cpmem.c | 44 +
2 files changed, 48 insertions(+)
diff --git a/dr
This patch allows to use the RGBX and RGBA 8:8:8:8 formats.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d13dbb6..d030990 100644
--- a/driv
Hi,
this series adds support for more alpha transpancy formats such as
RGBA 8:8:8:8, ARGB 1:5:5:5, and the more esoteric formats with 8-bit
alpha on a separate plane.
For the latter, new 2-plane RGB formats are added:
DRM_FORMAT_XRGB_A8
DRM_FORMAT_XBGR_A8
DRM_FORMAT_RGBX_A
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index d26b8be..0e6b868 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.
Signed-off-by: Ph
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 878a643..d13dbb6 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipu
The IPUv3 can read 8-bit alpha values from a separate plane buffer using a
companion IDMAC channel driven by the Alpha Transparency Controller (ATC)
for the graphics channels. The conditional read mechanism allows to reduce
memory bandwidth by skipping reads of color data for completely transparent
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gp
Need to handle DVI where we way end up with an analog encoder
in some cases.
v2: rework checks. always set use_digital for DVI-D, HDMI-A
Reported-by: Julian Margetson
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_audio.c | 20 +++-
On Tue, May 19, 2015 at 06:06:00PM +0200, Philipp Zabel wrote:
> Some hardware can read the alpha components separately and then
> conditionally fetch color components only for non-zero alpha values.
> This patch adds fourcc definitions for two-plane RGB formats with an
> 8-bit alpha channel on a s
On Tue, May 19, 2015 at 06:06:01PM +0200, Philipp Zabel wrote:
> The IPUv3 can read 8-bit alpha values from a separate plane buffer using a
> companion IDMAC channel driven by the Alpha Transparency Controller (ATC)
> for the graphics channels. The conditional read mechanism allows to reduce
> memo
On Tue, May 19, 2015 at 04:41:01PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_commit_planes calls all atomic_begin's first,
> then updates all planes, finally calling atomic_flush.
>
> Some drivers may want to things like disabling irq's
> from their atomic_begin, in which case a second c
OK,
so Daniel helped me track down this issue. It came from an incorrect
'clock-frequency' entry in my DTS. The freq was 50. Daniel
recommended 7060 which works 'fine' (and according to modetest
produces a 59Hz mode). I say 'fine' because I can't confirm that FIMD is
actually working.
Hi Tobias,
2015-05-19 Tobias Jakobi :
> OK,
>
> so Daniel helped me track down this issue. It came from an incorrect
> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended
> 7060 which works 'fine' (and according to modetest produces a 59Hz
> mode). I say 'fine' because
now.
--
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/20150519/4e95d716/attachment-0001.html>
Hi,
On 19 May 2015 at 19:43, Gustavo Padovan wrote:
> 2015-05-19 Tobias Jakobi :
>> so Daniel helped me track down this issue. It came from an incorrect
>> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended
>> 7060 which works 'fine' (and according to modetest produces
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/75a91ff4/attachment.html>
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/20150519/19246e8c/attachment.html>
)
OS|All |Linux (All)
--
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/20150519/b4ffac45/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150519/37896446/attachment.html>
rchives/dri-devel/attachments/20150519/c36d5bd5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/f5abc6be/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/c81e9a2c/attachment-0001.html>
This function was added recently but never used, and causes
a compile warning:
drivers/gpu/drm/drm_crtc.c:4324:13: warning:
'drm_property_unreference_blob_locked' defined but not used [-Wunused-function]
Removing that function avoids the warning. It can simply be put
back in case it is needed in
This problem happens using KMS surfaces and QXL driver.
To easy reproduce use KDE Plasma (which use surfaces a lot) and assure
you are using KMS surfaces (QXL driver on Fedora/RedHat has a patch to
stop using them). Open some complex application like LibreOffice and
after a while your machine get s
Hi Vladimir,
Thanks for you patch.
On 2015å¹´05æ18æ¥ 20:32, Vladimir Zapolskiy wrote:
> 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
Acked-by: Andy Yan
> ---
> drivers/
On 05/16, Mikko Perttunen wrote:
> On 05/15/2015 06:40 PM, Boris Brezillon wrote:
> >Hi Stephen,
> >
> >Adding Mikko in the loop (after all, he was the one complaining about
> >this signed long limitation in the first place, and I forgot to add
> >him in the Cc list :-/).
>
> I think I got it thro
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
There is NULL pointer check for sender after dereferencing sender in
__read_panel_data as below:-
struct drm_device *dev = sender->dev;
...
if (!sender || !data || !len)
And from codeflow
mdfld_dsi_get_panel_status --> mdfld_dsi_read_mcs --> __read_pane
Use the standard method to declare a bitmap array.
Joe Perches (12):
ARM: mach-imx: iomux-imx31: Use DECLARE_BITMAP
dmaengine: rcar-dmac: Use DECLARE_BITMAP
drm/amdkfd: Use DECLARE_BITMAP
drm/radeon: Use DECLARE_BITMAP
IB/ehca: Use DECLARE_BITMAP
bcache: Use DECLARE_BITMAP
spider_net
Use the generic mechanism to declare a bitmap instead of unsigned long.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/radeon/radeon.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 46eb0fa..d556733 1006
Use the generic mechanism to declare a bitmap instead of unsigned long.
It seems that "struct kfd_process.allocated_queue_bitmap" is unused.
Maybe it could be deleted instead.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 ++---
1 file changed, 2 insertions(+), 3 dele
94 matches
Mail list logo
