2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae wrote:
2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸
achments/20160404/ea763a9c/attachment.html>
I've tried again without video parameter -- same outcome. I've also
applied Ville's patch "drm/i915: Read timings from the correct
transcoder in intel_crtc_mode_get()" (with teeny backport fix). It seems
this code is never called in my case though, since intel_lvds_init()
chooses to use the VBT
On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote:
> Might have been better as a separate migration patch and then a
> compaction patch. It's prefixed mm/compaction, but most changed are
> in mm/migrate.c
Indeed. The title is rather misleading but not sure it's a good idea
to separat
On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote:
> Add DT bindings documentation for the Mali Display Processor. The bindings
> describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar G
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/5d3fc52d/attachment.html>
Hello there,
1.
linux-4.6-rc2/drivers/gpu/drm/radeon/si_dpm.c:3788]: (style) Condition 'td==0'
is always true
Source code is
   enum r600_td td = R600_TD_DFLT;
   for (i = 0; i < R600_PM_NUMBER_OF_TC; i++)
       WREG32(CG_FFCT_0 + (i * 4), (UTC_0(r600_utc[i]) |
DTC_0(r600_dt
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/a51465b8/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160404/a389e020/attachment.html>
On Mon, Apr 04, 2016 at 12:16:02AM -0500, Rob Herring wrote:
> On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote:
> > Add DT bindings documentation for the Mali Display Processor. The bindings
> > describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
> >
> > Cc: Rob Herring
Op 31-03-16 om 22:23 schreef Rob Clark:
> In the atomic modesetting path, each driver simply wants to grab a ref
> to the exclusive fence from a reservation object to store in the incoming
> drm_plane_state, without doing the whole RCU dance. Since each driver
> will need to do this, lets make a h
On Fri, Apr 01, 2016 at 05:47:57PM +0100, Mark Rutland wrote:
> On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote:
> > Add DT bindings documentation for the Mali Display Processor. The bindings
> > describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
> >
> > Cc: Rob Herring
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/123718dc/attachment.html>
Am 03.04.2016 um 20:48 schrieb Eric Engestrom:
> Signed-off-by: Eric Engestrom
For this one Reviewed-by: Christian König
> ---
> amdgpu/amdgpu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 0851306..5d5a2c6 100644
> -
On Fri, Apr 01, 2016 at 01:13:02PM +1000, Dave Airlie wrote:
> Can you rebase this onto rc1? since I'm getting conflicts when I pull
> it, and I really shouldn't be.
>
> Dave.
Hi Dave,
Looks like my maintainership is off with a rocky start. Soon after pulling
Alexey's
patch another one has land
On Sat, Apr 02, 2016 at 08:42:24AM +0300, Dan Carpenter wrote:
> We accidentally return PTR_ERR(NULL) which is success instead of a
> negative error code.
>
> Fixes: 879e40bea6f2 ('drm: ARM HDLCD - get rid of devm_clk_put()')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/arm/hd
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/372959e4/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/e5e114b3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/c7029fbb/attachment.html>
Reported in bug #94811.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/85ed325e/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/ad8e5025/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160404/75f2ff98/attachment.html>
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/9b20f13b/attachment.html>
On 04/04/2016 07:12 AM, Minchan Kim wrote:
> On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote:
>> Might have been better as a separate migration patch and then a
>> compaction patch. It's prefixed mm/compaction, but most changed are
>> in mm/migrate.c
>
> Indeed. The title is rather
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/6e3242a2/attachment.html>
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".
v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.
v3: Drop work_busy, as there's a sizeable delay when
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/36781082/attachment.html>
lying btw.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/f9eb2ad8/attachment-0001.html>
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/3dd11532/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/3c3a3f40/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/e04a1d72/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/19f181cc/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/2b34a27f/attachment.html>
corruption is the same in both cases).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160404/45d811d4/attachment.html>
Hi Laurent,
On 01-04-2016 18:10, Laurent Pinchart wrote:
> Hi Jose,
>
> Thank you for the patch.
>
> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 31, 2016 at 10:06:37PM +, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
> > escreveu:
> > >
> > > From: Ville Syrjälä
> > >
> > > DP dual mode type 1 DVI adapt
On Mon, Apr 04, 2016 at 11:14:45AM +0800, Rob Kramer wrote:
> I've tried again without video parameter -- same outcome. I've also
> applied Ville's patch "drm/i915: Read timings from the correct
> transcoder in intel_crtc_mode_get()" (with teeny backport fix). It seems
> this code is never calle
"
EndSection
Section "Screen"
Identifier"SCREEN"
Option"AutoServerLayout" "on"
SubSection "Display"
Viewport 0 0
Modes"1440x900"
Depth 24
EndSubSection
EndSecti
On Sun, Apr 3, 2016 at 8:14 PM, Inki Dae wrote:
>
> 2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
>>> Hi Daniel,
>>>
>>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae wrote:
>>>
Hi Tomeu,
On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 3b8f652698f8..8305bbd2a4d7 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_
On Mon, Apr 4, 2016 at 11:41 AM, Rob Clark wrote:
> On Sun, Apr 3, 2016 at 8:14 PM, Inki Dae wrote:
>>
>> 2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
>>> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
Hi Daniel,
2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Ink
On Sat, Apr 02, 2016 at 11:08:06AM +0100, Paul Parsons wrote:
> Three of the VESA DMT timings in edid_est_modes[] are slightly off.
> 1. 640x480 at 72Hz vsync_end should be 492, not 491.
> 2. 640x480 at 60Hz clock should be 25175, not 25200.
> 3. 1024x768 at 75Hz clock should be 78750, not 78800.
>
On Mon, Apr 4, 2016 at 5:02 AM, Maarten Lankhorst
wrote:
> Op 31-03-16 om 22:23 schreef Rob Clark:
>> In the atomic modesetting path, each driver simply wants to grab a ref
>> to the exclusive fence from a reservation object to store in the incoming
>> drm_plane_state, without doing the whole RCU
One of the VESA DMT timings in drm_dmt_modes[] is slightly off.
1024x768 at 43Hz (interlaced) vsync_end should be 776, not 772.
This brings it into line with the identical timings in edid_est_modes[].
Signed-off-by: Paul Parsons
---
diff -ru a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edi
With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race condi
Unplugging MST displays usually causes underruns, so turn off underrun
reporting so people don't report false positives.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race condi
If you make it here other than through err_destroy_encoder, vc4->hdmi
is still NULL.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index d8b8649..fd
This patchset adds the missing pieces to make the Freescale
DCU DRM driver work on Freescale Vybrid.
Foremost, it adds support for the timing controller (TCON)
module. The module is between the Display Controller and the
actual output pins. It allows to alter the timings for RAW
TFT displays, but
Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
mixes the bus clock with the display controllers pixel clock. Tests
have shown that the gates in CCM_CCGR3/9 registers do not control
the DCU pixel clock, but only the register access clock (bus clock).
Fix this by defining the
Add the ipg (bus) clock for the TCON modules (Timing Controller). This
module is required by the new DCU DRM driver, since the display signals
pass through TCON.
Signed-off-by: Stefan Agner
---
drivers/clk/imx/clk-vf610.c | 3 +++
include/dt-bindings/clock/vf610-clock.h | 4 +++-
2 f
Fix error handling during probe by reordering initialization and
adding a error path which disables clock again. Also disable the
clock on remove.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 44 +++
1 file changed, 21 insertions(+), 23
The Vybrid DCU variant has two independent clock inputs, one
for the registers (IPG bus clock) and one for the pixel clock.
Support this distinction in the DCU DRM driver while staying
backward compatible for old device trees.
Signed-off-by: Stefan Agner
---
Documentation/devicetree/bindings/dis
Use the common clock framework to calculate the pixel clock
dividier. The previous implementation rounded down the calculated
factor. Thanks to the CLK_DIVIDER_ROUND_CLOSEST flag using the
common clock framework divider implementation improves the pixel
clock accuracy in some cases. Ontop of that i
Add driver for the TCON (timing controller) module. The TCON module
is a separate module attached after the DCU (display controller
unit). Each DCU instance has its own, directly connected TCON
instance. The DCU's RGB and timing signals are passing through
the TCON module. TCON can provide timing s
Add the dcu and tcon nodes to enable the Display Controller Unit
and Timing Controller in Vybrid's SoC level device-tree file.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vfxxx.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch
Enable dcu node which is used by the DCU DRM driver. Assign the 5.7"
EDT panel with VGA resolution which Toradex sells often with the
evaluation board.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 16 +++
arch/arm/boot/dts/vf-colibri.dtsi | 33 +
The DCU IP has distinct clock inputs for register access and the
pixel clocks, at least in some implementations. LS1021a seems to
use the same clock, therefore specify the same clock for "dcu"
and "pix".
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/ls1021a.dtsi | 5 +++--
1 file changed, 3
This adds new error checking to the function, psb_driver_load
for when the function, psb_mmu_inset_pfn_sequence fails to grab
memory for the internal function call to psb_pd_addr_end. In
addition we now implement this by checking for a error code
return value from the internal call to the function
This adds proper use of the variable ret by returning it
at the end of the function, psb_mmu_inset_pfn_sequence for
indicating to callers when an error has occurred. Further
more remove the unneeded double setting of ret to the error
code, -ENOMEM after checking if a call to the function,
Signed-o
60 matches
Mail list logo
