[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #7 from fredrik at obra.se ---
No, still no signal

-- 
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/20140625/938dbbb7/attachment.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

Alex Deucher  changed:

   What|Removed |Added

 Attachment #101763|0   |1
is obsolete||

--- Comment #6 from Alex Deucher  ---
Created attachment 101773
  --> https://bugs.freedesktop.org/attachment.cgi?id=101773=edit
testing patch

Does this patch help?

-- 
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/20140625/fc3075be/attachment-0001.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #5 from fredrik at obra.se ---
Not really. Now i get a "no signal" error from my TV.

-- 
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/20140625/dc5d446c/attachment.html>

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Inki Dae]

On 2014? 06? 25? 19:42, Rahul Sharma wrote:
> Thanks Inki,
> 
> One more thing. mixer_layer_update is only called on for mixer version;
> MXR_VER_16_0_33_0, MXR_VER_128_0_0_184. This condition
> should have taken care of Exynos4 scenarios. What you say?
> 

There was my missing point. :) Already considered. ignore my comment.

Thanks,
Inki Dae

> Regards,
> Rahul Sharma.
> 
> On 24 June 2014 20:20, Inki Dae  wrote:
>> 2014-06-24 20:38 GMT+09:00 Andreas F?rber :
>>> Am 24.06.2014 07:21, schrieb Inki Dae:
 On 2014? 06? 23? 14:32, Rahul Sharma wrote:
> Allowing only one layer update per vsync can cause issues
> while there are update available for both layers. There is
> a good amount of possibility to loose updates if we allow
> single update per vsync.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index d359501..6773b03 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context 
> *ctx, int win)
>  static void mixer_layer_update(struct mixer_context *ctx)
>  {
>  struct mixer_resources *res = >mixer_res;
> -u32 val;
> -
> -val = mixer_reg_read(res, MXR_CFG);
>
> -/* allow one update per vsync only */
> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);

 Rahul, it looks good to me and ok as is. But above codes don't consider
 Exynos4 series. In case of Exynos4xxx SoC,
 MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
 register are reserved fields. So can you work that patch to be
 considered for Exynos4xxx SoC? That patch would be additional one.

 Anyway, will apply it as is, and I will wait for the additional patch.
>>>
>>> If it's not too late, could you fix up "multiple" in the subject? :)
>>
>> Corrected. :)
>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Cheers,
>>> Andreas
>>>
>>> --
>>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
>>> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #4 from Alex Deucher  ---
Created attachment 101763
  --> https://bugs.freedesktop.org/attachment.cgi?id=101763=edit
limit bpc to 10

Does this patch help?

-- 
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/20140625/6e76cd44/attachment.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #3 from fredrik at obra.se ---
Created attachment 101762
  --> https://bugs.freedesktop.org/attachment.cgi?id=101762=edit
proper kernel-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/20140625/fc044594/attachment.html>

[PATCH 3/3] ARM: dts: exynos5250: Add sysreg phandle to FIMD node

[Ajay Kumar]

Add sysreg phandle to FIMD node so that we are able
to control DISP1BLK configuration in FIMD driver.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5250.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a..2527403 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -758,6 +758,7 @@
fimd at 1440 {
clocks = < CLK_SCLK_FIMD1>, < CLK_FIMD1>;
clock-names = "sclk_fimd", "fimd";
+   samsung,sysreg-phandle = <_system_controller>;
};

adc: adc at 12D1 {
-- 
1.7.9.5

[PATCH 2/3] ARM: dts: exynos5420: Add sysreg phandle to FIMD node

[Ajay Kumar]

Add sysreg phandle to FIMD node so that we are able
to control DISP1BLK configuration in FIMD driver.

Signed-off-by: Ajay Kumar 
---
 arch/arm/boot/dts/exynos5420.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..4be3090 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -521,6 +521,7 @@
samsung,power-domain = <_pd>;
clocks = < CLK_SCLK_FIMD1>, < CLK_FIMD1>;
clock-names = "sclk_fimd", "fimd";
+   samsung,sysreg-phandle = <_system_controller>;
};

adc: adc at 12D1 {
-- 
1.7.9.5

[PATCH 1/3] drm/exynos: Control DISP1BLK system register in FIMD

[Ajay Kumar]

Exynos SOC have a DISP1BLK register where we can select
the path for FIMD output. We can redirect the video data
directly to DP/MIPI interface, or we can pass it via
image enhancement chips.

Since we don't use any image enhancement chips in exynos-drm,
we need to set FIMD BYPASS in DISP1BLK.

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/video/samsung-fimd.txt |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   19 +++
 include/video/samsung_fimd.h   |5 +
 3 files changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..034e3458 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,8 @@ Optional Properties:
 - display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
+- samsung,sysreg-phandle - handle to syscon node, used to control the system
+  registers for DISP1BLK.

 The device node can contain 'port' child nodes according to the bindings 
defined
 in [2]. The following are properties specific to those nodes:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..a3c855b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -68,6 +70,7 @@

 struct fimd_driver_data {
unsigned int timing_base;
+   unsigned int sysreg_disp1blk_offset;

unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
@@ -83,11 +86,13 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
 static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
.has_shadowcon = 1,
+   .sysreg_disp1blk_offset = 0x210,
 };

 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+   .sysreg_disp1blk_offset = 0x214,
 };

 struct fimd_win_data {
@@ -112,6 +117,7 @@ struct fimd_context {
struct clk  *bus_clk;
struct clk  *lcd_clk;
void __iomem*regs;
+   struct regmap   *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
@@ -760,6 +766,12 @@ static int fimd_poweron(struct exynos_drm_manager *mgr)

pm_runtime_get_sync(ctx->dev);

+   if (ctx->sysreg)
+   regmap_update_bits(ctx->sysreg,
+  ctx->driver_data->sysreg_disp1blk_offset,
+  FIMDBYPASS_MASK,
+  FIMDBYPASS << FIMDBYPASS_SHIFT);
+
ret = clk_prepare_enable(ctx->bus_clk);
if (ret < 0) {
DRM_ERROR("Failed to prepare_enable the bus clk [%d]\n", ret);
@@ -998,6 +1010,13 @@ static int fimd_probe(struct platform_device *pdev)
if (IS_ERR(ctx->display))
return PTR_ERR(ctx->display);

+   ctx->sysreg = syscon_regmap_lookup_by_phandle(
+   pdev->dev.of_node, "samsung,sysreg-phandle");
+   if (IS_ERR(ctx->sysreg)) {
+   DRM_INFO("DISP1BLK system register is not configured\n");
+   ctx->sysreg = NULL;
+   }
+
pm_runtime_enable(>dev);

ret = component_add(>dev, _component_ops);
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..b92267d 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -462,3 +462,8 @@
 #define FIMD_V8_VIDTCON2   0x20018
 #define FIMD_V8_VIDTCON3   0x2001C
 #define FIMD_V8_VIDCON10x20004
+
+/* SYSREG DISP1BLK definitions */
+#define FIMDBYPASS_SHIFT   15
+#define FIMDBYPASS_MASK(1 << FIMDBYPASS_SHIFT)
+#define FIMDBYPASS 1
-- 
1.7.9.5

[PATCH 0/3] drm/exynos: add framework to control DISP1BLK setting

[Ajay Kumar]

This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Exynos SOC have a DISP1BLK register where we can select
the path for FIMD output. We can redirect the video data
directly to DP/MIPI interface, or we can pass it via
image enhancement chips.

Since we don't use any image enhancement chips in exynos-drm,
we need to set FIMD BYPASS in DISP1BLK.

This patchset is tested for basic display + DPMS + S2R on snow and peach_pit.

Ajay Kumar (3):
  [PATCH 1/3] drm/exynos: Control DISP1BLK system register in FIMD
  [PATCH 2/3] ARM: dts: exynos5420: Add sysreg phandle to FIMD node
  [PATCH 3/3] ARM: dts: exynos5250: Add sysreg phandle to FIMD node

 .../devicetree/bindings/video/samsung-fimd.txt |2 ++
 arch/arm/boot/dts/exynos5250.dtsi  |1 +
 arch/arm/boot/dts/exynos5420.dtsi  |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   19 +++
 include/video/samsung_fimd.h   |5 +
 5 files changed, 28 insertions(+)

-- 
1.7.9.5

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #2 from Alex Deucher  ---
Can you attach the dmesg with drm.debug=1 before you start X?  All the
important information is cut off.  E.g., boot into single user mode (append 1
to the kernel command line in grub).

-- 
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/20140625/d3399cfb/attachment.html>

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

--- Comment #1 from fredrik at obra.se ---
Created attachment 101760
  --> https://bugs.freedesktop.org/attachment.cgi?id=101760=edit
Xorg 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/20140625/63d19679/attachment.html>

[Bug 80531] New: 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80531

  Priority: medium
Bug ID: 80531
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 3.16-rc2 hdmi output resolution out of range Cape
Verde PRO [Radeon HD 7750]
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: fredrik at obra.se
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 101759
  --> https://bugs.freedesktop.org/attachment.cgi?id=101759=edit
dmesg with drm.debug=1

With 3.16-rc2 my tripple screen setup breaks. 

DisplayPort-0 connected 1920x1200 <- ok
HDMI-0 connected 1920x1080 <- (tv) resolution out of range
DVI-0 connected 1680x1050 <- ok

All screens work during bootup before X starts.
ddx driver 7.3.0.

-- 
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/20140625/ce67ddcc/attachment.html>

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Michel Dänzer]

On 25.06.2014 03:13, Dieter N?tzel wrote:
> Am 24.06.2014 12:05, schrieb Michel D?nzer:
>> On 24.06.2014 05:32, Dieter N?tzel wrote:
>>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>>>>> On 18.06.2014 18:14, Christian K?nig wrote:
>>>>>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>>>>>>
>>>>>>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
>>>>>>> completion
>>>>>>> event has impossible msc [x-1] < target_msc [x]
>>> [...]
>>> I can reliable generate such lines in Xorg.0.log with KWin cube desktop
>>> effect.
>>>
>>> Rotate screens with mouse wheel or screen switcher => new entry in
>>> Xorg.0.log. If it happens I notice ('see') flip delay.
>>
>> I was only able to reproduce it a couple of times even with that, but not
>> at all yet with the patch below. Does it help for you as well?
> 
> Will try in the next run.
> 
> My daughter generated kernel crash for us.;-)
> See would open up a zoom image in Konqi of a new Waveboard for here girl
> friends...
> 
> But I could only take images with my mobile.
> kernel BUG at drivers/gpu/drm/drm_irq.c:976!

I was able to reproduce all these issues, and the attached three patches
fix them for me. Please let me know if you can still trigger the panic
or the diagnostic error messages in patch 2 somehow. If everything works
fine for you as well with these, I'll submit them with the error
messages in patch 2 changed to debug messages.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-Only-enable-and-handle-pageflip-interrupt.patch
Type: text/x-patch
Size: 7644 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140625/8fe306b3/attachment-0003.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-Track-the-status-of-a-page-flip-more-expl.patch
Type: text/x-patch
Size: 4049 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140625/8fe306b3/attachment-0004.bin>
------ next part --
A non-text attachment was scrubbed...
Name: 0003-drm-radeon-Avoid-sending-page-flip-completion-event-.patch
Type: text/x-patch
Size: 2814 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140625/8fe306b3/attachment-0005.bin>

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Rahul Sharma]

Thanks Inki,

One more thing. mixer_layer_update is only called on for mixer version;
MXR_VER_16_0_33_0, MXR_VER_128_0_0_184. This condition
should have taken care of Exynos4 scenarios. What you say?

Regards,
Rahul Sharma.

On 24 June 2014 20:20, Inki Dae  wrote:
> 2014-06-24 20:38 GMT+09:00 Andreas F?rber :
>> Am 24.06.2014 07:21, schrieb Inki Dae:
>>> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
 Allowing only one layer update per vsync can cause issues
 while there are update available for both layers. There is
 a good amount of possibility to loose updates if we allow
 single update per vsync.

 Signed-off-by: Rahul Sharma 
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index d359501..6773b03 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context 
 *ctx, int win)
  static void mixer_layer_update(struct mixer_context *ctx)
  {
  struct mixer_resources *res = >mixer_res;
 -u32 val;
 -
 -val = mixer_reg_read(res, MXR_CFG);

 -/* allow one update per vsync only */
 -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
 -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
 +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>>>
>>> Rahul, it looks good to me and ok as is. But above codes don't consider
>>> Exynos4 series. In case of Exynos4xxx SoC,
>>> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
>>> register are reserved fields. So can you work that patch to be
>>> considered for Exynos4xxx SoC? That patch would be additional one.
>>>
>>> Anyway, will apply it as is, and I will wait for the additional patch.
>>
>> If it's not too late, could you fix up "multiple" in the subject? :)
>
> Corrected. :)
>
> Thanks,
> Inki Dae
>
>>
>> Cheers,
>> Andreas
>>
>> --
>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
>> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Russell King - ARM Linux]

On Wed, Jun 25, 2014 at 11:32:46AM -0300, Ezequiel Garc?a wrote:
> (Ccing Guido back)
> 
> Hello Russell, Darren,
> 
> On 25 Jun 02:00 PM, Russell King - ARM Linux wrote:
> > On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > > If I recall, the late_initcall stuff was done to try and make sure the  
> > > tda998x/i2c subsystem came up before tilcdc.
> 
> That doesn't make any sense. Using late_initcall for the tilcdc DRM
> driver would make the tilcdc DRM get probed before any other regular
> module_init driver, including the tda998x encoder.

A module_init() is a device_initcall(), which is at level 6.  A
late_initcall() is at level 7.  Level 6 initcalls are run before level
7 initcalls.  The tda998x is a module_init(), so the tda998x gets
initialised *before* tilcdc's late_initcall().

Now, if you build everything as a module, then you have no initialisation
ordering, and you can't rely on any kind of order.  Initialisation
functions can even run in parallel on different CPUs due to modules being
loaded from userspace in a multi-threaded way.  So anything which relies
on a certain initcall ordering is fundamentally broken if it can be
modular.

> > There's a solution to that...
> 
> A solution to *what* ?

Maybe if you left the context above that line in place, you might
understand that my "that" refers to what was discussed in that
context.  That being the initialisation ordering.

Convention and proper Internet etiquette is to trim the quoted text
and place relies below the paragraph to which they refer, the quoted
paragraph giving the context to the reply.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 00/22] Add and use pci_zalloc_consistent

[John W. Linville]

On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> Adding the helper reduces object code size as well as overall
> source size line count.
> 
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
> 
> Done with a simple cocci script and some typing.
> 
> Joe Perches (22):

>   ipw2100: Use pci_zalloc_consistent
>   mwl8k: Use pci_zalloc_consistent
>   rtl818x: Use pci_zalloc_consistent
>   rtlwifi: Use pci_zalloc_consistent

Sure, fine by me.

-- 
John W. LinvilleSomeday the world will need a hero, and you
linville at tuxdriver.com   might be all we have.  Be ready.

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/25 14:48, Paolo Bonzini wrote:
> Il 22/06/2014 10:25, Chen, Tiejun ha scritto:
>> In qemu-upstream, as you commented we can't create this as a ISA class
>> type explicitly.
>
> Note I didn't say that QEMU doesn't like having two ISA bridges.
>
> I commented that the firmware will see two ISA bridges and will try to
> initialize both of them.  It currently doesn't just because it only
> knows of two southbridge PCI IDs, and both of them are old or relatively
> old (PIIX3/4 and ICH9).
>
> But what would happen if you did graphics passthrough on a machine with
> an ICH9 southbridge?  Your code will create the PIIX4 ISA bridge, and
> will create an ICH9 southbridge just to please the i915 driver.  The
> BIOS will recognize the ICH9's vendor/device ids and try to initialize
> it.  It will write to the configuration space to set up PCI PIRQ[A-H]
> routing, for example, which makes no sense since your ICH9 is just a
> dummy device.
>

Thanks for your detailed explanation.

> Second problem.  Your IGD passthrough code currently works with QEMU's
> PIIX4-based machine.  But what happens if you try to extend it, so that

Yes, current xen machine, xenpv, is based on pii4, and also I don't 
known if we will plan to migrate to q35 or others. So its hard to 
further say more now.

> it works with QEMU's ICH9-based machine?  That's a more modern machine
> that has a PCIe chipset and hence has its ISA bridge at 00:1f.0.  Now

But even in this case, could we set the real vendor/device ids for that 
ISA bridge at 00:1f.0? If not, what's broken?

> you have a conflict.
>
> In other words, if you want IGD passthrough in QEMU, you need a solution
> that is future-proof.
>
>> So we compromise by faking this ISA bridge without ISA
>> class type setting (as I recall you already said this way is slightly
>> better).
>
> It is only slightly better, but the right solution is to fix the driver.
>   There is absolutely zero reason why a graphics driver should know
> about the vendor/device ids of the PCH.

This means we have to fix this both on Linux and Windows but I'm not 
sure if this is feasible to us.

>
> The right way could be to make QEMU add a vendor-specific capability to
> the video device. The driver can probe for that capability before

Do you mean we can pick two unused offsets in the configuration space of 
the video device as a vendor-specific capability to hold the 
vendor/device ids of the PCH?

> looking at the PCI bus.  QEMU can add the capability to the list, it is
> easy because all accesses to the video device's configuration space trap
> to QEMU.  Then you do not need to add fake devices to the machine.
>
> In fact, it would be nice if Intel added such a capability on the next
> generation of integrated graphics, too.  On real hardware, ACPI or some

Maybe, but even this would be implemented, shouldn't we need to be 
compatible with those old generations?

Thanks
Tiejun

> other kind of firmware can probe the PCH at 00:1f.0 and initialize that
> vendor-specific capability.  QEMU would just forward the value from the
> host, so that virtualized guests never depend on the PCH at 00:1f.0.
>
> Paolo
>
>> Maybe we will figure better way in the future. But anyway, this
>> is always registered as 00:15.0, right? So I think the i915 driver can
>> go back to probe the devfn like the native environment.
>
>
>

drm/i915 KMS regression in Linux 3.16-rc2 (with git bisect result)

[Tom Van Braeckel]

Hi,

There seems to be a regression in the upcoming Linux 3.16-rc2 release
candidate that I bisected down to this first bad commit:
[dbb42748ac4929987c1449ecb296b39ef8956b62] drm/i915: Move the C3 LP
write bit setup to gen3_init_clock_gating() for KMS.

The regression is that during the Ubuntu boot process, the monitor
becomes blank and displays "no signal, going to sleep". This happens
around Kernel Mode Setting time, and does not occur with the
"nomodeset" kernel parameter.

The machine under test is a HP-branded single core Intel Pentium 4 CPU
@ 3.00GHz with this GPU:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ
Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device 3012
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915


I confirmed that this regression still exists with the latest version
of Linus' tree.

Kind regards and thanks for all your hard work!

Tom Van Braeckel.
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-rc2+ (tom at box) (gcc version 4.8.2 
(Ubuntu 4.8.2-19ubuntu1) ) #20 SMP Wed Jun 25 14:34:25 CEST 2014
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   NSC Geode by NSC
[0.00]   Cyrix CyrixInstead
[0.00]   Centaur CentaurHauls
[0.00]   Transmeta GenuineTMx86
[0.00]   Transmeta TransmetaCPU
[0.00]   UMC UMC UMC UMC
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f7cf2ff] usable
[0.00] BIOS-e820: [mem 0x7f7cf300-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Hewlett-Packard HP Compaq dc7600 Ultra-slim Desktop/09FCh, 
BIOS 786D1 v01.03 05/18/2005
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x7f7cf max_arch_pfn = 0x100
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E7FFF write-protect
[0.00]   E8000-E write-back
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 07F80 mask FFF80 uncachable
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] original variable MTRRs
[0.00] reg 0, base: 0GB, range: 2GB, type WB
[0.00] reg 1, base: 2040MB, range: 8MB, type UC
[0.00] total RAM covered: 2040M
[0.00] Found optimal setting for mtrr clean up
[0.00]  gran_size: 64K  chunk_size: 16M num_reg: 2  lose 
cover RAM: 0G
[0.00] New variable MTRRs
[0.00] reg 0, base: 0GB, range: 2GB, type WB
[0.00] reg 1, base: 2040MB, range: 8MB, type UC
[0.00] found SMP MP-table at [mem 0x000fe700-0x000fe70f] mapped at 
[c00fe700]
[0.00] Scanning 1 areas for low memory corruption
[0.00] initial memory mapped: [mem 0x-0x01ff]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x3780-0x379f]
[0.00]  [mem 0x3780-0x379f] page 2M
[0.00] init_memory_mapping: [mem 0x3400-0x377f]
[0.00]  [mem 0x3400-0x377f] page 2M
[0.00] init_memory_mapping: [mem 

drm/i915 KMS regression in Linux 3.16-rc2 (with git bisect result)

[Chris Wilson]

On Wed, Jun 25, 2014 at 03:03:44PM +0200, Tom Van Braeckel wrote:
> Hi,
> 
> There seems to be a regression in the upcoming Linux 3.16-rc2 release
> candidate that I bisected down to this first bad commit:
> [dbb42748ac4929987c1449ecb296b39ef8956b62] drm/i915: Move the C3 LP
> write bit setup to gen3_init_clock_gating() for KMS.

Can you attach the dmesg with rc2 and dbb4274 reverted?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Russell King - ARM Linux]

On Wed, Jun 25, 2014 at 02:00:42PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >> Use module_init instead of late_initcall, as is the norm for modular
> >> drivers.
> >>
> >> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> >> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> >> but it does not explain why. Tests show it's working properly with
> >> module_init.
> >>
> >
> > If I recall, the late_initcall stuff was done to try and make sure the  
> > tda998x/i2c subsystem came up before tilcdc. However it didn't always  
> > work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try  
> > and ensure the ordering.  This might be why changing back to module_init  
> > is fine (and I agree with your assessment from my testing).
> 
> There's a solution to that... I have patches which convert the tda998x
> driver to also register into the component helpers as well as remaining
> as a drm slave device.  This makes it possible to transition tilcdc to
> use the component helper to solve the initialisation ordering.
> 
> I'll (re-)post them later today.

Except Daniel Mack will not be receiving any copies of them:

  zonque at gmail.com
SMTP error from remote mail server after end of data:
host gmail-smtp-in.l.google.com [2a00:1450:400c:c03::1a]:
550-5.7.1 [2001:4d48:ad52:3201:214:fdff:fe10:1be6  12] Our system has
550-5.7.1 detected that this message is likely unsolicited mail. To reduce 
the
550-5.7.1 amount of spam sent to Gmail, this message has been blocked. 
Please
550-5.7.1 visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en=188131 
for
550 5.7.1 more information. fs8si6627678wib.99 - gsmtp

Google's anti-ham filter seems to be working perfectly, allowing spam
through and blocking real messages... as usual.  And as usual, google
provides no support for this crap.  Gmail has a history of increasingly
blocking legitimate email in their alleged anti-spam fight.  Don't use
gmail.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Russell King - ARM Linux]

On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
>> Use module_init instead of late_initcall, as is the norm for modular
>> drivers.
>>
>> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
>> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
>> but it does not explain why. Tests show it's working properly with
>> module_init.
>>
>
> If I recall, the late_initcall stuff was done to try and make sure the  
> tda998x/i2c subsystem came up before tilcdc. However it didn't always  
> work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try  
> and ensure the ordering.  This might be why changing back to module_init  
> is fine (and I agree with your assessment from my testing).

There's a solution to that... I have patches which convert the tda998x
driver to also register into the component helpers as well as remaining
as a drm slave device.  This makes it possible to transition tilcdc to
use the component helper to solve the initialisation ordering.

I'll (re-)post them later today.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 80029] [bisected] HDMI Errors on drm-next & Linus's tree

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80029

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Alex Deucher  ---
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c868229da7014fc988a8d506264c43c1fcf7f21

-- 
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/20140625/ec555281/attachment.html>

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78221

--- Comment #15 from Alex Deucher  ---
Any luck narrowing down what fixed it in 3.15 or what broke it again in 3.16?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 24.06.2014 19:14, Christian K?nig wrote:
> Am 24.06.2014 08:49, schrieb Michel D?nzer:
>> On 23.06.2014 18:56, Christian K?nig wrote:
>>> Am 23.06.2014 10:15, schrieb Michel D?nzer:
 On 19.06.2014 18:45, Christian K?nig wrote:

> I think even when we revert to the old code we have a couple of
> unsolved
> problems with the VM support or in the driver in general where we
> should
> try to understand the underlying reason for it instead of applying
> more
> workarounds.
 I'm not suggesting applying more workarounds but going back to a known
 more stable state. It seems like we've maneuvered ourselves to a rather
 uncomfortable position from there, with no clear way to a better place.
 But if we basically started from the 3.14 state again, we have a few
 known hurdles like mine and Marek's Bonaire etc. which we know any
 further improvements will have to pass before they can be considered
 for
 general consumption.
>>> Yeah agree, especially on the uncomfortable position.
>>>
>>> Please try with the two attached patches applied on top of 3.15 and
>>> retest. They should revert back to the old implementation.
>> Unfortunately, X fails to start with these, see the attached excerpt
>> from dmesg.
> 
> My fault, incorrectly solved a merge conflict and then failed to test
> the right kernel.
> 
> BTW: Wasn't there an option to tell grup to use the latest installed
> kernel instead of the one with the highest version number? Can't seem to
> find that any more.

No idea, unfortunately.


> Please try attached patches instead,

With these patches, 3.15 just survived two piglit runs on my Bonaire,
one with the GART poisoning fix and one without. It never survived a
single run before.

Acked-and-Tested-by: Michel D?nzer 


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79850

--- Comment #17 from Sylvain BERTRAND  ---
> All I'm asking is to follow the X radeon execution flow in gdb.
When I gdb can_flip on fedora rawhide, the inner fonction source was wrong
regarding the instruction pointer.
That, probably because of code optimization, then I gdb the assembly. This is
much more work. Would have been much easier recompiling with the right printf.
But I'm not interested in learning fedora SDK...
> Not sure how that is relevant.
For the reason stated above, it is, unfortunately. But you did not know.

I'll check if the instruction pointer is in sync with source code for this
function.

-- 
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/20140625/03d6bf59/attachment.html>

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Ezequiel García]

Hi Russell,

On 25 Jun 03:46 PM, Russell King - ARM Linux wrote:
> > 
> > That doesn't make any sense. Using late_initcall for the tilcdc DRM
> > driver would make the tilcdc DRM get probed before any other regular
> > module_init driver, including the tda998x encoder.
> 
> A module_init() is a device_initcall(), which is at level 6.  A
> late_initcall() is at level 7.  Level 6 initcalls are run before level
> 7 initcalls.  The tda998x is a module_init(), so the tda998x gets
> initialised *before* tilcdc's late_initcall().
> 

Oh, thanks a lot for correcting me.

> Now, if you build everything as a module, then you have no initialisation
> ordering, and you can't rely on any kind of order.  Initialisation
> functions can even run in parallel on different CPUs due to modules being
> loaded from userspace in a multi-threaded way.  So anything which relies
> on a certain initcall ordering is fundamentally broken if it can be
> modular.
> 

OK, but is there any outstanding issue with the tilcdc initialization, either
when compiled as built-in or as modules, *after* this patchset?

Of course, this driver only worked as built-in (see the horrible bugs we are
fixing here, that prevented unloading and re-loading it). This series fixes
all such bugs, and also adds the required changes to allow to build everything
as a module.

Again, I can't see any issues that remain to be fixed after this patchset.
When compiled as built-in, the tilcdc DRM will be defered and once the tda998x
is ready, the tilcdc DRM will load properly.

When compiled as module you can load any of them in any order. If the tda998x
module is not loaded by the time you load the tilcdc module, the former will
get loaded.

Hm... now that I think about this. We still get into trouble if the tda998x
is built as module, but the tilcdc is built-in. Shouldn't we just forbid that?
Either both built-ins or both as modules?

> > > There's a solution to that...
> > 
> > A solution to *what* ?
> 
> Maybe if you left the context above that line in place, you might
> understand that my "that" refers to what was discussed in that
> context.  That being the initialisation ordering.
> 
> Convention and proper Internet etiquette is to trim the quoted text
> and place relies below the paragraph to which they refer, the quoted
> paragraph giving the context to the reply.
> 

Yeah, sorry about that.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[Bug 79980] Random radeonsi crashes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #23 from agapito  ---
Kernel 3.10.44 is affected also ! I am using my Intel Graphic Card for now. I
had this bug every 15 minuts watching flash content.

My graphic card is HD 7950 using HDMI output.

-- 
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/20140625/7e7e044f/attachment.html>

[PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls

[Ezequiel García]

On 24 Jun 05:06 PM, Darren Etheridge wrote:
> 
> On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >The TI tilcdc driver is designed with a notion of submodules. Currently,
> >at unload time, these submodules are iterated and destroyed.
> >
> >Now that the tilcdc remove order is fixed, this can be handled perfectly
> 
> I am not sure I understand the first part of the above sentence - did
> something change with tilcdc ordering?

Yes, patch [PATCH/RESEND 6/9] drm/tilcdc: fix release order on exit changes
the tilcdc remove ordering. 

Currently, the tilcdc DRM is removed with this:

tilcdc_tfp410_fini();
tilcdc_slave_fini();
tilcdc_panel_fini();
platform_driver_unregister(_platform_driver);

Which is wrong as you shouldn't remove the tilcdc "modules" (panel, slave,
tfp410) before the DRM driver itself. So the above patch fixed it to be:

platform_driver_unregister(_platform_driver);
tilcdc_panel_fini();
tilcdc_slave_fini();
tilcdc_tfp410_fini();

> I think you a referring to previous
> patches in your series which really mean tilcdc can actually unload now.  So
> really the method this patch uses could always have been used, it just
> wasn't for some reason?
> 

No, I believe this patch which removes the tilcdc sub-module destroy
infrastructure can only be applied *after* the above remove order is fixed
(iow, the 6/9 patch mentioned above).

In other words, only once you have a proper remove() that releases things
in the right order you can rely in the kernel and avoid any custom
implementation.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Sascha Hauer]

On Wed, Jun 25, 2014 at 09:43:27AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> > On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > > +
> > >  /*
> > >   * Bitfield of Display Interface signal polarities.
> > >   */
> > > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > >   unsigned clksel_en:1;
> > >   unsigned clkidle_en:1;
> > >   unsigned data_pol:1;/* true = inverted */
> > > - unsigned clk_pol:1; /* true = rising edge */
> > > + unsigned clk_pol:1;
> > >   unsigned enable_pol:1;
> > >   unsigned Hsync_pol:1;   /* true = active high */
> > >   unsigned Vsync_pol:1;
> > 
> > ...can we rename the flags to more meaningful names instead?
> > 
> > unsigned clk_pol_rising_edge:1;
> > unsigned enable_pol_high:1;
> > unsigned hsync_active_high:1;
> > unsigned vsync_active_high:1;
> 
> Now look at patch 7, where these become tri-state:
> - don't change
> - rising edge/active high
> - falling edge/active low
> 
> So your suggestion is not a good idea.

Hm, you're right.

Still I think we should add a prefix to make the context of the flags
clear.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Denis Carikli]

On 06/25/2014 06:48 AM, Sascha Hauer wrote:
>> +#define ENABLE_POL_LOW  0
>> +#define ENABLE_POL_HIGH 1
>
> Adding defines without a proper namespace (IPU_) outside a driver
> private header file is not nice. Anyway, instead of adding the
> defines ...
Fixed in "imx-drm: use defines for clock polarity settings" and in 
"imx-drm: Use drm_display_mode timings flags.".

Denis.

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Denis Carikli]

On 06/24/2014 05:06 PM, Russell King - ARM Linux wrote:
 > It would be better if you separate the
> binding documentation updates from the other functional changes too.
Fixed.

Denis.

[PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init

[Ezequiel García]

(Ccing Guido back)

Hello Russell, Darren,

On 25 Jun 02:00 PM, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >> Use module_init instead of late_initcall, as is the norm for modular
> >> drivers.
> >>
> >> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> >> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> >> but it does not explain why. Tests show it's working properly with
> >> module_init.
> >>
> >
> > If I recall, the late_initcall stuff was done to try and make sure the  
> > tda998x/i2c subsystem came up before tilcdc.

That doesn't make any sense. Using late_initcall for the tilcdc DRM
driver would make the tilcdc DRM get probed before any other regular
module_init driver, including the tda998x encoder.

> > However it didn't always  
> > work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try  
> > and ensure the ordering.  This might be why changing back to module_init  
> > is fine (and I agree with your assessment from my testing).

That commit is adds a proper probe deferal mechanism in case the
i2c is not available. OMAP is special because it has its own nasty initcall
to probe the i2c busses. However, that should be fixed and then i2c would be
always probed *after* the DRM, as per the ordering in drivers/Makefile.

> 
> There's a solution to that...

A solution to *what* ?

> I have patches which convert the tda998x
> driver to also register into the component helpers as well as remaining
> as a drm slave device.  This makes it possible to transition tilcdc to
> use the component helper to solve the initialisation ordering.
> 

AFAIK, there's no issue with the initialisation ordering, except that the
DRM driver is currently probed before the TDA998x encoder and so the probe
is defered. Unless I'm missing something that's very easy to fix, you just
need to change the link order to guarantee that i2c encoders are probed
*before* the DRM drivers that require them.

I have just posted a very simple patch to fix it, but it seems Thierry wasn't
happy with it, not sure why yet [1].

[1] http://www.spinics.net/lists/dri-devel/msg61987.html
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH v14 05/10] ARM: dts: imx5*, imx6*: correct display-timings nodes.

[Shawn Guo]

On Tue, Jun 24, 2014 at 04:01:58PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> > The imx-drm driver can't use the de-active and
> > pixelclk-active display-timings properties yet.
> > 
> > Instead the data-enable and the pixel data clock
> > polarity are hardcoded in the imx-drm driver.
> > 
> > So theses properties are now set to keep
> > the same behaviour when imx-drm will start
> > using them.
> > 
> > Signed-off-by: Denis Carikli 
> 
> This patch needs either an ack from the arm-soc/iMX maintainers, or
> they need to merge it.  As there's little positive agreement on the
> series, I can understand why there's reluctance to merge it.
> 
> So, can we start having some acks from people please, or at least
> commitments to merge this patch when the others are deemed to be
> acceptable.  If not, can we have explanations why this should not
> be merged.

I will be happy to merge dts change through IMX tree once the
binding/diver part gets accepted/applied.

Shawn

[Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/24 10:59, Zhenyu Wang wrote:
> On 2014.06.19 17:53:51 +0800, Tiejun Chen wrote:
>> Originally the reason to probe ISA bridge instead of Dev31:Fun0
>> is to make graphics device passthrough work easy for VMM, that
>> only need to expose ISA bridge to let driver know the real
>> hardware underneath. This is a requirement from virtualization
>> team. Especially in that virtualized environments, XEN, there
>> is irrelevant ISA bridge in the system with that legacy qemu
>> version specific to xen, qemu-xen-traditional. So to work
>> reliably, we should scan through all the ISA bridge devices
>> and check for the first match, instead of only checking the
>> first one.
>>
>> But actually, qemu-xen-traditional, is always enumerated with
>> Dev31:Fun0, 00:1f.0 as follows:
>>
>> hw/pt-graphics.c:
>>
>> intel_pch_init()
>>  |
>>  + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
>>
>> so this mean that isa bridge is still represented with Dev31:Func0
>> like the native OS. Furthermore, currently we're pushing VGA
>> passthrough support into qemu upstream, and with some discussion,
>> we wouldn't set the bridge class type and just expose this devfn.
>>
>> So we just go back to check devfn to make life normal.
>>
>> Signed-off-by: Tiejun Chen 
>
> This was added historically when supporting graphics device passthrough.
> Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
> on device 31: func0 as far as I know. Looks good to me.
>
> Reviewed-by: Zhenyu Wang 
>

Thanks for your review.

Do you know when this can be applied?

Tiejun

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Denis Carikli]

On 06/25/2014 12:04 AM, Thierry Reding wrote:
>> because on this very simple display board, we only have DVI LVDS signals
>> without the I2C to detect the display.
>
> That's unfortunate. In that case perhaps a better approach would be to
> add a video timings node to the device that provides the DVI output?
I've just done that.

Should I resend now? The goal is to avoid as much as possible extra 
versions.

Also, as I said before in a response to "[PATCH v14 09/10] ARM: dts: 
mbimx51sd: Add display support.", the LCD regulator was inverted, it 
worked while inverted because of a bug which is now fixed by:
"imx-drm: parallel-display: Fix DPMS default state."

Right now, I don't have any other changes for this serie beside a simple 
rebase of "dts: imx5*, imx6*: correct display-timings rebased".

Denis.

[PATCH v14 07/10] imx-drm: Use drm_display_mode timings flags.

[Russell King - ARM Linux]

On Mon, Jun 16, 2014 at 12:11:21PM +0200, Denis Carikli wrote:
> The previous hardware behaviour was kept if the
> flags are not set.

I'd like to throw in a patch that I've been carrying for a bit now.
It conflicts with your patches, but I'm happy to fix that conflict
locally (and have been doing so for a while now.)

This is related to a slightly different issue - knowing which types
of bridges are bound to a particualar DI.  This matters in part for
selecting the clock routing - as things currently stand, the last
bridge to call imx_drm_panel_format*() gets its way with this.  With
this change, we can see which bridges are bound, and make the
appropriate decision.  At the moment, we are saved from things going
awry as we don't support cloning outputs.

The relevence to your patch set is that some bridges require clk_pol
to be configured appropriately - HDMI requires clk_pol = 0 in order to
work correctly (with the opposite edge, the image is noisy.)

While this approach only allows us to identify the types of bridges
connected to a DI rather than uniquely identifing the bridges themselves,
I think this is not only an improvement, but also a simplification of
the current code, and allows better decisions about things like clk_pol
to be made.

I'm sending it here because it is relevent to Denis' patch set - I will
also send it out separately if people want it separately, though that
will go to a reduced Cc list.

From: Russell King 
Subject: [PATCH] imx-drm: core: handling of DI clock flags to
 ipu_crtc_mode_set()

We do not need to track the state of the IPU DI's clock flags by having
each display bridge calling back into imx-drm-core, and then back out
into ipuv3-crtc.c.

ipuv3-crtc can instead just scan the list of encoders to retrieve their
type, and build up a picture of which types of encoders are attached.
We can then use this information to configure the IPU DI clocking mode
without any uncertainty - if we have multiple bridges connected to the
same DI, if one of them requires a synchronous DI clock, that's what we
must use.

Signed-off-by: Russell King 
---
 drivers/staging/imx-drm/imx-drm-core.c |  3 +--
 drivers/staging/imx-drm/imx-drm.h  |  2 +-
 drivers/staging/imx-drm/ipuv3-crtc.c   | 40 +++---
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index def8280d7ee6..6d9376c760ad 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -115,8 +115,7 @@ int imx_drm_panel_format_pins(struct drm_encoder *encoder,
helper = _crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return helper->set_interface_pix_fmt(encoder->crtc,
-   encoder->encoder_type, interface_pix_fmt,
-   hsync_pin, vsync_pin);
+   interface_pix_fmt, hsync_pin, vsync_pin);
return 0;
 }
 EXPORT_SYMBOL_GPL(imx_drm_panel_format_pins);
diff --git a/drivers/staging/imx-drm/imx-drm.h 
b/drivers/staging/imx-drm/imx-drm.h
index 7453ae00c412..3c559ccd6af0 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -17,7 +17,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
 struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
-   int (*set_interface_pix_fmt)(struct drm_crtc *crtc, u32 encoder_type,
+   int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
u32 pix_fmt, int hsync_pin, int vsync_pin);
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 7fec438d8c54..af09032aedb0 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -51,7 +51,6 @@ struct ipu_crtc {
struct drm_framebuffer  *newfb;
int irq;
u32 interface_pix_fmt;
-   unsigned long   di_clkflags;
int di_hsync_pin;
int di_vsync_pin;
 };
@@ -146,10 +145,13 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
   int x, int y,
   struct drm_framebuffer *old_fb)
 {
+   struct drm_device *dev = crtc->dev;
+   struct drm_encoder *encoder;
struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
-   int ret;
struct ipu_di_signal_cfg sig_cfg = {};
+   unsigned long encoder_types = 0;
u32 out_pixel_fmt;
+   int ret;

dev_dbg(ipu_crtc->dev, "%s: mode->hdisplay: %d\n", __func__,
mode->hdisplay);
@@ -165,6 +167,24 @@ static int 

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Paolo Bonzini]

Il 25/06/2014 09:34, Chen, Tiejun ha scritto:
> On 2014/6/25 14:48, Paolo Bonzini wrote:
>> Second problem.  Your IGD passthrough code currently works with QEMU's
>> PIIX4-based machine.  But what happens if you try to extend it, so that
>
> Yes, current xen machine, xenpv, is based on pii4, and also I don't
> known if we will plan to migrate to q35 or others. So its hard to
> further say more now.
>
>> it works with QEMU's ICH9-based machine?  That's a more modern machine
>> that has a PCIe chipset and hence has its ISA bridge at 00:1f.0.  Now
>
> But even in this case, could we set the real vendor/device ids for that
> ISA bridge at 00:1f.0? If not, what's broken?

The config space layout changes for different vendor/device ids, so the 
guest firmware only works if you have the right vendor/device id.

>> It is only slightly better, but the right solution is to fix the driver.
>>   There is absolutely zero reason why a graphics driver should know
>> about the vendor/device ids of the PCH.
>
> This means we have to fix this both on Linux and Windows but I'm not
> sure if this is feasible to us.

You have to do it if you want this feature in QEMU in a future-proof way.

You _can_ provide the ugly PIIX4-specific hack as a compatibility 
fallback (and this patch is okay to make the compatibility fallback less 
hacky).  However, I don't think QEMU should accept the patch for IGD 
passthrough unless Intel is willing to make drivers 
virtualization-friendly.  Once you assign the IGD, it is not that 
integrated anymore and the drivers must take that into account.

It is worthwhile pointing out that neither AMD nor nVidia need any of this.

>> The right way could be to make QEMU add a vendor-specific capability to
>> the video device. The driver can probe for that capability before
>
> Do you mean we can pick two unused offsets in the configuration space of
> the video device as a vendor-specific capability to hold the
> vendor/device ids of the PCH?

Yes, either that or add a new capability (which lets you choose the 
offsets more freely).

If the IGD driver needs config space fields of the MCH, those fields 
could also be mirrored in the new capability.  QEMU would forward them 
automatically.

It could even be a new BAR, which gives even more freedom to allocate 
the fields.

>> looking at the PCI bus.  QEMU can add the capability to the list, it is
>> easy because all accesses to the video device's configuration space trap
>> to QEMU.  Then you do not need to add fake devices to the machine.
>>
>> In fact, it would be nice if Intel added such a capability on the next
>> generation of integrated graphics, too.  On real hardware, ACPI or some
>
> Maybe, but even this would be implemented, shouldn't we need to be
> compatible with those old generations?

Yes.

- old generation / old driver: use 00:1f.0 hack, only guaranteed to work 
on PIIX4-based virtual guest

- old generation / new driver: use 00:1f.0 hack on real hardware, use 
capability on 00:02.0 on virtual guest, can work on PCIe virtual guest

- new generation / old driver: doesn't exist

- new generation / new driver: always use capability on 00:02.0, can 
work on PCIe virtual guest.

Paolo

[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver

[Jingoo Han]

On Tuesday, June 24, 2014 11:15 PM, Andrzej Hajda wrote:
> On 06/24/2014 03:14 PM, Ajay kumar wrote:
> > On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda  
> > wrote:
> >> Hi Ajay,
> >>
> >> On 06/24/2014 01:09 PM, Ajay Kumar wrote:
> >>> Add the missing setting for DP CLKCON register.
> >>>
> >>> This register is present on Exynos5 based FIMD controllers,
> >>> and needs to be used if we are using DP.
> >>>
> >>> Signed-off-by: Ajay Kumar 
> >>> ---
> >>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
> >>>  include/video/samsung_fimd.h |4 
> >>>  2 files changed, 9 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> >>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> index 33161ad..5d3045d 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> >>> @@ -72,6 +72,7 @@ struct fimd_driver_data {
> >>>   unsigned int has_shadowcon:1;
> >>>   unsigned int has_clksel:1;
> >>>   unsigned int has_limited_fmt:1;
> >>> + unsigned int has_dp_clkcon:1;
> >>>  };
> >>>
> >>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> >>> @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
> >>> = {
> >>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
> >>>   .timing_base = 0x2,
> >>>   .has_shadowcon = 1,
> >>> + .has_dp_clkcon = 1,
> >>>  };
> >>>
> >>>  struct fimd_win_data {
> >>> @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager 
> >>> *mgr)
> >>>   if (clkdiv > 1)
> >>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
> >>>
> >>> + if (ctx->driver_data->has_dp_clkcon)
> >>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
> >>> +
> >> This code always enables the clock on exynos5. As I understand it should
> >> be enabled only if DP is used.
> > Right!
> > But, when I searched for the display interface,
> > only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
> > So, I thought adding this in driver_data for exynos5 should be fine.

No, it should be selectable. Even some exynos5 based boards use MIPI LCD.

> 
> Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.
> 
> >
> > Inki/Andrej - Shall I add it as an optional DT property?
> 
> No, property is redundant. The simplest solution could be to use
> CONFIG_DRM_EXYNOS_DP
> macro but it is quite ugly.

Right, CONFIG_DRM_EXYNOS_DP is the simplest. But, the macro doesn't
look good.

> I guess extending little bit exynos_drm framework to allow detection of
> DP in fimd would be better.

I agree on Andrzej's opinion.

Best regards,
Jingoo Han

> 
> Regards
> Andrzej
> 
> >
> > Ajay
> >>
> >>>   writel(val, ctx->regs + VIDCON0);
> >>>  }
> >>>
> >>> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> >>> index b039320..d8f4b0b 100644
> >>> --- a/include/video/samsung_fimd.h
> >>> +++ b/include/video/samsung_fimd.h
> >>> @@ -435,6 +435,10 @@
> >>>  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0)
> >>>  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0)
> >>>
> >>> +/* Video clock enable for DP */
> >>> +#define DP_CLKCON0x27C
> >>> +#define DP_CLK_ENABLE0x2
> >>> +
> >>>  /* Notes on per-window bpp settings
> >>>   *
> >>>   * Value Win0 Win1 Win2 Win3 Win 4
> >>>

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78221

--- Comment #14 from t3st3r at mail.ru ---
Nono, v3.15 (release) is okay on my GPU in regard to this bug. That what makes
testing patch tricky.

Bug has been here since unknown. I can tell for sure it plagued all 3.15RCs
(maybe earlier versions as well). But between 3.15rc8 and 3.15 release, bunch
of last-minute DRM fixes landed (0a4ae727d6aa459247b027387edb6ff99f657792).
Except everything else, it corrected this GPU deadlock problem. So v3.15 (the
one and the only) does not exposes that bug.

When I gave a try to v3.16rc1, I figured out bug re-appeared. Hence, looked
like regression in 3.16RCs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Russell King - ARM Linux]

On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote:
> On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> > +
> >  /*
> >   * Bitfield of Display Interface signal polarities.
> >   */
> > @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
> > unsigned clksel_en:1;
> > unsigned clkidle_en:1;
> > unsigned data_pol:1;/* true = inverted */
> > -   unsigned clk_pol:1; /* true = rising edge */
> > +   unsigned clk_pol:1;
> > unsigned enable_pol:1;
> > unsigned Hsync_pol:1;   /* true = active high */
> > unsigned Vsync_pol:1;
> 
> ...can we rename the flags to more meaningful names instead?
> 
>   unsigned clk_pol_rising_edge:1;
>   unsigned enable_pol_high:1;
>   unsigned hsync_active_high:1;
>   unsigned vsync_active_high:1;

Now look at patch 7, where these become tri-state:
- don't change
- rising edge/active high
- falling edge/active low

So your suggestion is not a good idea.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Paolo Bonzini]

Il 22/06/2014 10:25, Chen, Tiejun ha scritto:
> In qemu-upstream, as you commented we can't create this as a ISA class
> type explicitly.

Note I didn't say that QEMU doesn't like having two ISA bridges.

I commented that the firmware will see two ISA bridges and will try to 
initialize both of them.  It currently doesn't just because it only 
knows of two southbridge PCI IDs, and both of them are old or relatively 
old (PIIX3/4 and ICH9).

But what would happen if you did graphics passthrough on a machine with 
an ICH9 southbridge?  Your code will create the PIIX4 ISA bridge, and 
will create an ICH9 southbridge just to please the i915 driver.  The 
BIOS will recognize the ICH9's vendor/device ids and try to initialize 
it.  It will write to the configuration space to set up PCI PIRQ[A-H] 
routing, for example, which makes no sense since your ICH9 is just a 
dummy device.

Second problem.  Your IGD passthrough code currently works with QEMU's 
PIIX4-based machine.  But what happens if you try to extend it, so that 
it works with QEMU's ICH9-based machine?  That's a more modern machine 
that has a PCIe chipset and hence has its ISA bridge at 00:1f.0.  Now 
you have a conflict.

In other words, if you want IGD passthrough in QEMU, you need a solution 
that is future-proof.

> So we compromise by faking this ISA bridge without ISA
> class type setting (as I recall you already said this way is slightly
> better).

It is only slightly better, but the right solution is to fix the driver. 
  There is absolutely zero reason why a graphics driver should know 
about the vendor/device ids of the PCH.

The right way could be to make QEMU add a vendor-specific capability to 
the video device. The driver can probe for that capability before 
looking at the PCI bus.  QEMU can add the capability to the list, it is 
easy because all accesses to the video device's configuration space trap 
to QEMU.  Then you do not need to add fake devices to the machine.

In fact, it would be nice if Intel added such a capability on the next 
generation of integrated graphics, too.  On real hardware, ACPI or some 
other kind of firmware can probe the PCH at 00:1f.0 and initialize that 
vendor-specific capability.  QEMU would just forward the value from the 
host, so that virtualized guests never depend on the PCH at 00:1f.0.

Paolo

> Maybe we will figure better way in the future. But anyway, this
> is always registered as 00:15.0, right? So I think the i915 driver can
> go back to probe the devfn like the native environment.

[PATCH v14 04/10] imx-drm: use defines for clock polarity settings

[Sascha Hauer]

On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli 
> ---
> ChangeLog v13->v14:
> - Rebased
> ChangeLog 12->v13:
> - No changes
> ChangeLog 11->v12:
> - Improved the define names to match the hardware:
>   ENABLE_POL is not a clock signal but instead an enable signal.
> 
> ChangeLog v9->v10:
> - New patch which was splitted out from:
>   "staging: imx-drm: Use de-active and pixelclk-active display-timings.".
> - Fixes many issues in "staging: imx-drm: Use de-active and pixelclk-active
>   display-timings.":
>   - More clear meaning of the polarity settings.
>   - The SET_CLK_POL and SET_DE_POL masks are not
> needed anymore.
> ---
>  drivers/gpu/ipu-v3/ipu-di.c  |4 ++--
>  drivers/staging/imx-drm/ipuv3-crtc.c |4 ++--
>  include/video/imx-ipu-v3.h   |8 +++-
>  3 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
> index c490ba4..d00f357 100644
> --- a/drivers/gpu/ipu-v3/ipu-di.c
> +++ b/drivers/gpu/ipu-v3/ipu-di.c
> @@ -595,7 +595,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
> ipu_di_signal_cfg *sig)
>   }
>   }
>  
> - if (sig->clk_pol)
> + if (sig->clk_pol == CLK_POL_POSEDGE)
>   di_gen |= DI_GEN_POLARITY_DISP_CLK;
>  
>   ipu_di_write(di, di_gen, DI_GENERAL);
> @@ -606,7 +606,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
> ipu_di_signal_cfg *sig)
>   reg = ipu_di_read(di, DI_POL);
>   reg &= ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);
>  
> - if (sig->enable_pol)
> + if (sig->enable_pol == ENABLE_POL_HIGH)
>   reg |= DI_POL_DRDY_POLARITY_15;
>   if (sig->data_pol)
>   reg |= DI_POL_DRDY_DATA_POLARITY;
> diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
> b/drivers/staging/imx-drm/ipuv3-crtc.c
> index 720868b..7fec438 100644
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -165,8 +165,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
>   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
>   sig_cfg.Vsync_pol = 1;
>  
> - sig_cfg.enable_pol = 1;
> - sig_cfg.clk_pol = 0;
> + sig_cfg.enable_pol = ENABLE_POL_HIGH;
> + sig_cfg.clk_pol = CLK_POL_NEGEDGE;
>   sig_cfg.width = mode->hdisplay;
>   sig_cfg.height = mode->vdisplay;
>   sig_cfg.pixel_fmt = out_pixel_fmt;
> diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
> index 3e43e22..305 100644
> --- a/include/video/imx-ipu-v3.h
> +++ b/include/video/imx-ipu-v3.h
> @@ -27,6 +27,12 @@ enum ipuv3_type {
>  
>  #define IPU_PIX_FMT_GBR24v4l2_fourcc('G', 'B', 'R', '3')
>  
> +#define CLK_POL_NEGEDGE  0
> +#define CLK_POL_POSEDGE  1
> +
> +#define ENABLE_POL_LOW   0
> +#define ENABLE_POL_HIGH  1

Adding defines without a proper namespace (IPU_) outside a driver
private header file is not nice. Anyway, instead of adding the
defines ...

> +
>  /*
>   * Bitfield of Display Interface signal polarities.
>   */
> @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
>   unsigned clksel_en:1;
>   unsigned clkidle_en:1;
>   unsigned data_pol:1;/* true = inverted */
> - unsigned clk_pol:1; /* true = rising edge */
> + unsigned clk_pol:1;
>   unsigned enable_pol:1;
>   unsigned Hsync_pol:1;   /* true = active high */
>   unsigned Vsync_pol:1;

...can we rename the flags to more meaningful names instead?

unsigned clk_pol_rising_edge:1;
unsigned enable_pol_high:1;
unsigned hsync_active_high:1;
unsigned vsync_active_high:1;

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 80419] XCOM: Enemy Unknown Causes lockup

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80419

--- Comment #13 from Michel D?nzer  ---
(In reply to comment #11)
> For now, Xorg.0.log.old seems to better match up with the time of the error,
> and shows a mumber of EQ overflow errors that aren't in Xorg.0.log.

Those are just symptoms of the GPU hang, they don't say anything about its
cause.

The corresponding dmesg output should be available in /var/log/kern.log* as
well.

Also, I wonder if this is reproducible enough to create an apitrace reproducing
it?

-- 
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/20140625/cda05075/attachment.html>

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80141

--- Comment #10 from Michel D?nzer  ---
The patches from
http://lists.freedesktop.org/archives/dri-devel/2014-June/062305.html seem to
improve stability with 3.15 for me.

-- 
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/20140625/6da47c44/attachment.html>

[Bug 42787] Video flickers on X1200 / RS690 over DVI

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42787

xerofoify at gmail.com changed:

   What|Removed |Added

 CC||xerofoify at gmail.com

--- Comment #4 from xerofoify at gmail.com ---
Please check if this bug is still on newer kernel releases.
Otherwise you should this bug as it's now fixed:)
Cheers Nick

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78221

--- Comment #13 from Alex Deucher  ---
Sorry, I misread your comments and thought it was broken on 3.15 as well.  You
can follow the thread here:
http://lists.freedesktop.org/archives/dri-devel/2014-June/062305.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 80015] Transparency glitches in native Civilization 5 (Civ5) port

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80015

--- Comment #5 from Alex Deucher  ---
http://lists.freedesktop.org/archives/mesa-dev/2014-June/062167.html

-- 
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/20140625/be99508c/attachment.html>

[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34772

xerofoify at gmail.com changed:

   What|Removed |Added

 CC||xerofoify at gmail.com

--- Comment #23 from xerofoify at gmail.com ---
This bug needs to be tested against a newer kernel to see if it's fixed.
Cheers Nick

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 79773] Enabling DPM results in crash for R270X PITCAIRN

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79773

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 76490 ***

-- 
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/20140625/f516e01b/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=76490

Alex Deucher  changed:

   What|Removed |Added

 CC||dex+fdobugzilla at dragonslave
   ||.de

--- Comment #15 from Alex Deucher  ---
*** Bug 79773 has been marked as a duplicate of this bug. ***

-- 
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/20140625/caf3953b/attachment.html>

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79850

--- Comment #16 from Michel D?nzer  ---
(In reply to comment #15)
> Don't take it personally,

Don't worry.

> but I don't usually work on MIT/BSD licensed code on my free time because of
> ethics.

All I'm asking is to follow the X radeon execution flow in gdb.


> Moreover, I follow the page flip thread on DRI dev mailing list... things
> seems still broken there.

Since the problem here is that page flipping is not actually used, none of that
applies of course.


> The fedora rawhide SDK is a pain, and my dev systems are clean 64 bits (then
> no steam/games debugging).

Not sure how that is relevant.

-- 
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/20140625/9abcbfbf/attachment.html>

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78221

--- Comment #12 from t3st3r at mail.ru ---
And what I'm supposed to test if patch is against 3.15? Because 3.15 release is
fine "on its own" and does not exposes this bug. So its impossible to see if
bug appears -> apply patch -> check that bug is gone (which looks most logical
course of actions to me, unless I got something wrong). Because 3.15 lacks this
bug even before patch.

Bug appears to be fixed between 3.15-rc8 and 3.15 as result of mentioned merge.
Then bug reappeared at 3.16-rc1 (and up) as result of other merges. So it would
be logical if patch is against some 3.15-rc* or 3.16-rc*? Unfortunately, they
have so many changes related to VM management that it's not like if I'm cool
enough to port patch to these versions myself (most notably, radeon_vm.c
changes are quite complicated). So I cant see if GPU lockup is gone after
patching some "known-bad" version.

Or you mean something like this: take 3.15 (which is ok) and check that patch
does not breaks anything? But it wouldn't be direct check if bug is actually
gone, right?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

linux-next: Tree for Jun 19 (drm/i915)

[Rafael J. Wysocki]

On Tuesday, June 24, 2014 02:43:02 PM Jani Nikula wrote:
> On Thu, 19 Jun 2014, Randy Dunlap  wrote:
> > On 06/18/14 23:16, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> The powerpc allyesconfig is again broken more than usual.
> >> 
> >> Changes since 20140618:
> >> 
> >
> > on i386:
> >
> > CONFIG_ACPI is not enabled.
> >
> >   CC  drivers/gpu/drm/i915/i915_drv.o
> > ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
> > ../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit declaration of 
> > function 'acpi_target_system_state' [-Werror=implicit-function-declaration]
> > ../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' 
> > undeclared (first use in this function)
> > ../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared identifier 
> > is reported only once for each function it appears in
> >   CC  net/dccp/qpolicy.o
> > cc1: some warnings being treated as errors
> > make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1
> 
> Thanks for the report, we'll fix it.
> 
> Can anyone explain why include/linux/acpi_bus.h has #ifdef
> CONFIG_ACPI_SLEEP and conditional build for a dummy inline version of
> acpi_target_system_state(), *but* that does not get included or used if
> CONFIG_ACPI=n? Additionally, the combination of CONFIG_ACPI=y and
> CONFIG_ACPI_SLEEP=n does not seem to work at all.

These two things look like bugs to me.  Most likely not tested thoruoughly
enough.

> So we'll really have to sprinkle #ifdef CONFIG_ACPI all over, instead of
> neatly using the dummy versions that someone has gone through the
> trouble of adding?

No, we don't have to.

Rafael

[PATCH 2/2 v2] x86, ia64: Merge common vga fixup code

[Bruno Prémont]

The fixup code for PCI VGA devices in ia64 and x86 is mostly identical.

Merge it into a single function called from both sides.

The common code is moved to vgaarb.c which makes in dependant on
CONFIG_VGA_ARB.

Tested-by: Anibal Francisco Martinez Cortina 
Cc: Matthew Garrett 
Signed-off-by: Bruno Pr?mont 
---

Changes since v1:
  Added Tested-by, Cc

 arch/ia64/pci/fixup.c| 77 ++--
 arch/x86/pci/fixup.c | 76 +--
 drivers/gpu/vga/vgaarb.c | 75 ++
 include/linux/vgaarb.h   | 37 +++
 4 files changed, 116 insertions(+), 149 deletions(-)

diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index 9ed5bef..5df22f9 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -9,85 +9,14 @@

 #include 

-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From information provided by "Jon Smirl" 
- *
- * The standard boot ROM sequence for an x86 machine uses the BIOS
- * to select an initial video card for boot display. This boot video
- * card will have it's BIOS copied to C in system RAM.
- * IORESOURCE_ROM_SHADOW is used to associate the boot video
- * card with this copy. On laptops this copy has to be used since
- * the main ROM may be compressed or combined with another image.
- * See pci_map_rom() for use of this flag. Before marking the device
- * with IORESOURCE_ROM_SHADOW check if a vga_default_device is already set
- * by either arch cde or vga-arbitration, if so only apply the fixup to this
- * already determined primary video card.
- */
-
-static void pci_fixup_video(struct pci_dev *pdev)
+static void pci_ia64_fixup_video(struct pci_dev *pdev)
 {
-   struct pci_dev *bridge;
-   struct pci_bus *bus;
-   u16 config;
-
if ((strcmp(ia64_platform_name, "dig") != 0)
&& (strcmp(ia64_platform_name, "hpzx1")  != 0))
return;
/* Maybe, this machine supports legacy memory map. */

-   if (!vga_default_device()) {
-   resource_size_t start, end;
-   int i;
-
-   /* Does firmware framebuffer belong to us? */
-   for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
-   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
-   continue;
-
-   start = pci_resource_start(pdev, i);
-   end  = pci_resource_end(pdev, i);
-
-   if (!start || !end)
-   continue;
-
-   if (screen_info.lfb_base >= start &&
-   (screen_info.lfb_base + screen_info.lfb_size) < 
end)
-   vga_set_default_device(pdev);
-   }
-   }
-
-   /* Is VGA routed to us? */
-   bus = pdev->bus;
-   while (bus) {
-   bridge = bus->self;
-
-   /*
-* From information provided by
-* "David Miller" 
-* The bridge control register is valid for PCI header
-* type BRIDGE, or CARDBUS. Host to PCI controllers use
-* PCI header type NORMAL.
-*/
-   if (bridge
-   &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
-  ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
-   pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
-   );
-   if (!(config & PCI_BRIDGE_CTL_VGA))
-   return;
-   }
-   bus = bus->parent;
-   }
-   if (!vga_default_device() || pdev == vga_default_device()) {
-   pci_read_config_word(pdev, PCI_COMMAND, );
-   if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
-   pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
-   vga_set_default_device(pdev);
-   }
-   }
+   pci_fixup_video(pdev);
 }
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
-   PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
+   PCI_CLASS_DISPLAY_VGA, 8, pci_ia64_fixup_video);
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 7246cf2..b599847 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -302,81 +302,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,   
PCI_DEVICE_ID_INTEL_MCH_PB1,pcie_r
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_MCH_PC, 
pcie_rootport_aspm_quirk);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_MCH_PC1,
pcie_rootport_aspm_quirk);

-/*
- * Fixup to mark boot BIOS video selected by BIOS before it changes
- *
- * From 

[PATCH/RESEND 1/9] drm/i2c: tda998x: move drm_i2c_encoder_destroy call

[Guido Martínez]

Hi Russell,

On Tue, Jun 24, 2014 at 05:38:13PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 17, 2014 at 11:17:03AM -0300, Guido Mart?nez wrote:
> > Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
> > as part of the release procedure. Such calls need to access the I2C bus
> > and therefore, we need to call them before drm_i2c_encoder_destroy()
> > which unregisters the I2C device.
> > 
> > This commit moves the latter so it's done afterwards.
> > 
> > Signed-off-by: Guido Mart?nez 
> > Signed-off-by: Ezequiel Garc?a 
> > Cc:  #v3.9+
> 
> You really should have sent this with me in the To: header as I'm now the
> maintainer of this driver.  Yes, this is a valid fix, and I'll apply it
> shortly.  Thanks.
Sorry about that, I'm still kind of new to this whole deal. I'll keep it
mind for future patches.

Thanks,
Guido


> > ---
> >  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index 240c331..db9515f 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1183,7 +1183,6 @@ static void
> >  tda998x_encoder_destroy(struct drm_encoder *encoder)
> >  {
> > struct tda998x_priv *priv = to_tda998x_priv(encoder);
> > -   drm_i2c_encoder_destroy(encoder);
> >  
> > /* disable all IRQs and free the IRQ handler */
> > cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
> > @@ -1193,6 +1192,7 @@ tda998x_encoder_destroy(struct drm_encoder *encoder)
> >  
> > if (priv->cec)
> > i2c_unregister_device(priv->cec);
> > +   drm_i2c_encoder_destroy(encoder);
> > kfree(priv);
> >  }
> >  
> > -- 
> > 2.0.0
> > 
> 
> -- 
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Guido Mart?nez, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Bruno Prémont]

With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Matthew Garrett introduced a efifb vga_default_device() so that EFI
systems that do not load shadow VBIOS or setup VGA get proper value for
boot_vga PCI sysfs attribute on the corresponding PCI device.

Xorg is refusing to detect devices when boot_vga=0 which is the case on
some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".

Note: When vga_default_device() is set boot_vga PCI sysfs attribute
reflects its state. When unset this attribute is 1 whenever
IORESOURCE_ROM_SHADOW flag is set.

With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting
sysfb/efifb optional.

Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video().

Tested-by: Anibal Francisco Martinez Cortina 
Cc: Matthew Garrett 
Cc: stable at vger.kernel.org
Signed-off-by: Bruno Pr?mont 
---

Changes since v1:
  Added Tested-by, Cc

 arch/ia64/pci/fixup.c   | 21 +
 arch/x86/include/asm/vga.h  |  6 --
 arch/x86/pci/fixup.c| 21 +
 drivers/video/fbdev/efifb.c | 38 --
 4 files changed, 42 insertions(+), 44 deletions(-)

diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..9ed5bef 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -37,6 +37,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
return;
/* Maybe, this machine supports legacy memory map. */

+   if (!vga_default_device()) {
+   resource_size_t start, end;
+   int i;
+
+   /* Does firmware framebuffer belong to us? */
+   for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+   continue;
+
+   start = pci_resource_start(pdev, i);
+   end  = pci_resource_end(pdev, i);
+
+   if (!start || !end)
+   continue;
+
+   if (screen_info.lfb_base >= start &&
+   (screen_info.lfb_base + screen_info.lfb_size) < 
end)
+   vga_set_default_device(pdev);
+   }
+   }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
 #define vga_readb(x) (*(x))
 #define vga_writeb(x, y) (*(y) = (x))

-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
 #endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 94ae9ae..7246cf2 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -325,6 +325,27 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;

+   if (!vga_default_device()) {
+   resource_size_t start, end;
+   int i;
+
+   /* Does firmware framebuffer belong to us? */
+   for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+   continue;
+
+   start = pci_resource_start(pdev, i);
+   end  = pci_resource_end(pdev, i);
+
+   if (!start || !end)
+   continue;
+
+   if (screen_info.lfb_base >= start &&
+   (screen_info.lfb_base + screen_info.lfb_size) < 
end)
+   vga_set_default_device(pdev);
+   }
+   }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ae9618f..a033180 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -19,8 +19,6 @@

 static bool request_mem_succeeded = false;

-static struct pci_dev *default_vga;
-
 static struct fb_var_screeninfo efifb_defined = {
.activate   = FB_ACTIVATE_NOW,
.height = -1,
@@ -84,18 +82,6 @@ static struct fb_ops efifb_ops = {
.fb_imageblit   = cfb_imageblit,
 };

-struct pci_dev *vga_default_device(void)
-{
-   return default_vga;
-}
-
-EXPORT_SYMBOL_GPL(vga_default_device);
-
-void vga_set_default_device(struct pci_dev *pdev)
-{
-   default_vga = pdev;
-}
-
 static int efifb_setup(char *options)
 {
char *this_opt;
@@ 

[PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls

[Guido Martínez]

On Tue, Jun 24, 2014 at 05:06:24PM -0500, Darren Etheridge wrote:
> Guido,
> 
> On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >The TI tilcdc driver is designed with a notion of submodules. Currently,
> >at unload time, these submodules are iterated and destroyed.
> >
> >Now that the tilcdc remove order is fixed, this can be handled perfectly
> 
> I am not sure I understand the first part of the above sentence - did
> something change with tilcdc ordering?  I think you a referring to previous
> patches in your series which really mean tilcdc can actually unload now.
Right, I guess I got a bit dizzy while writing that commit log :). If we
find the patch reasonable I'll send a better explanation.

> So really the method this patch uses could always have been used, it
> just wasn't for some reason?
Yes, I think so.

> I have tested all of the other patches in your series and all looks good on
> BeagleBone Black and AM335xEVM, I tested as both built-ins and modules and
> can load/unload on BeagleBone Black with HDMI enabled correctly.
Nice to hear that :)

> I want to play around a bit more with this particular patch, to try and
> understand how it differs from Rob's original intent with his module
> registration/deregistration scheme.  I prefer your method, but do we loose
> anything that Rob's originally had in mind?
Nothing really comes to mind, but I may be wrong on this...

Thanks a lot for your review!

> Darren
> 
> >by the kernel using the device infrastructure, since each submodule
> >is a kernel driver itself, and they are only destroy()'ed at unload
> >time. Therefore we move the destroy() functionality to each submodule's
> >remove().
> >
> >Also, remove some checks in the unloading process since the new code
> >guarantees the resources are allocated and need a release.
> >
> >Signed-off-by: Guido Mart?nez 
> >---
> >  drivers/gpu/drm/tilcdc/Module.symvers  |  0
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c|  6 --
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
> >  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 36 
> > +-
> >  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 26 +---
> >  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 34 
> > 
> >  6 files changed, 50 insertions(+), 53 deletions(-)
> >  create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
> >
> >diff --git a/drivers/gpu/drm/tilcdc/Module.symvers 
> >b/drivers/gpu/drm/tilcdc/Module.symvers
> >new file mode 100644
> >index 000..e69de29
> >diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> >b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >index 006a30e..2c860c4 100644
> >--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >@@ -120,7 +120,6 @@ static int cpufreq_transition(struct notifier_block *nb,
> >  static int tilcdc_unload(struct drm_device *dev)
> >  {
> > struct tilcdc_drm_private *priv = dev->dev_private;
> >-struct tilcdc_module *mod, *cur;
> >
> > drm_fbdev_cma_fini(priv->fbdev);
> > drm_kms_helper_poll_fini(dev);
> >@@ -149,11 +148,6 @@ static int tilcdc_unload(struct drm_device *dev)
> >
> > pm_runtime_disable(dev->dev);
> >
> >-list_for_each_entry_safe(mod, cur, _list, list) {
> >-DBG("destroying module: %s", mod->name);
> >-mod->funcs->destroy(mod);
> >-}
> >-
> > kfree(priv);
> >
> > return 0;
> >diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> >b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >index 0938036..7596c14 100644
> >--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >@@ -98,7 +98,6 @@ struct tilcdc_module;
> >  struct tilcdc_module_ops {
> > /* create appropriate encoders/connectors: */
> > int (*modeset_init)(struct tilcdc_module *mod, struct drm_device *dev);
> >-void (*destroy)(struct tilcdc_module *mod);
> >  #ifdef CONFIG_DEBUG_FS
> > /* create debugfs nodes (can be NULL): */
> > int (*debugfs_init)(struct tilcdc_module *mod, struct drm_minor *minor);
> >diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> >b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> >index b085dcc..2f6efae 100644
> >--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> >+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> >@@ -282,21 +282,8 @@ static int panel_modeset_init(struct tilcdc_module 
> >*mod, struct drm_device *dev)
> > return 0;
> >  }
> >
> >-static void panel_destroy(struct tilcdc_module *mod)
> >-{
> >-struct panel_module *panel_mod = to_panel_module(mod);
> >-
> >-if (panel_mod->timings)
> >-display_timings_release(panel_mod->timings);
> >-
> >-tilcdc_module_cleanup(mod);
> >-kfree(panel_mod->info);
> >-kfree(panel_mod);
> >-}
> >-
> >  static const struct tilcdc_module_ops panel_module_ops = {
> > .modeset_init = panel_modeset_init,
> >-.destroy = panel_destroy,
> >  };
> >
> >  /*
> >@@ -372,6 +359,7 @@ static int panel_probe(struct platform_device *pdev)
> 

[PATCH v14 06/10] drm: drm_display_mode: add signal polarity flags

[Thierry Reding]

On Tue, Jun 24, 2014 at 03:57:46PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 12:11:20PM +0200, Denis Carikli wrote:
> > We need a way to pass signal polarity informations
> >   between DRM panels, and the display drivers.
> > 
> > To do that, a pol_flags field was added to drm_display_mode.
> > 
> > Signed-off-by: Denis Carikli 
> 
> This patch needs an ack from the DRM people - can someone review it
> please?  This series has now been round 14 revisions and it's about
> time it was properly reviewed - or a statement made if it's
> unacceptable.

I didn't follow all of the earlier discussions around this, but it seems
to me like data-enable polarity and the pixel data edge flags are
properties of the interface rather than the video mode.

struct drm_display_mode represents the video timings and I'm not sure if
it's a good idea to extend it with this type of information.

Maybe we need to add a separate type of device to store these parameters
(much like we've done for MIPI DSI devices).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140625/400d1e9e/attachment.sig>

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Thierry Reding]

On Tue, Jun 24, 2014 at 11:56:39PM +0200, Eric B?nard wrote:
> Hi Thierry,
> 
> Le Tue, 24 Jun 2014 23:49:37 +0200,
> Thierry Reding  a ?crit :
> 
> > On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
> > [...]
> > > diff --git 
> > > a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
> > > b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> > [...]
> > > @@ -0,0 +1,7 @@
> > > +Eukrea DVI-SVGA (800x600 pixels) DVI output.
> > [...]
> > > diff --git 
> > > a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> > > b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> > [...]
> > > @@ -0,0 +1,7 @@
> > > +Eukrea DVI-VGA (640x480 pixels) DVI output.
> > 
> > DVI outputs shouldn't be using the panel framework and this binding at
> > all. DVI usually has the means to determine all of this by itself. Why
> > do you need to represent this as a panel in device tree?
> > 
> because on this very simple display board, we only have DVI LVDS signals
> without the I2C to detect the display.

That's unfortunate. In that case perhaps a better approach would be to
add a video timings node to the device that provides the DVI output?

The panel bindings are really for internal panels and should define all
of their properties. That's also why they need a specific compatible
string.

What the above two bindings define are really "connectors" with a fixed
resolution rather than panels.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140625/157429d0/attachment.sig>

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Thierry Reding]

On Tue, Jun 24, 2014 at 02:52:11PM -0500, Rob Herring wrote:
> On Tue, Jun 24, 2014 at 10:06 AM, Russell King - ARM Linux  arm.linux.org.uk> wrote:
[...]
> > On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
[...]
> >> diff --git 
> >> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> >> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
[...]
> >> @@ -0,0 +1,7 @@
> >> +Eukrea DVI-VGA (640x480 pixels) DVI output.
> >> +
> >> +Required properties:
> >> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
> >> +
> >> +This binding is compatible with the simple-panel binding, which is 
> >> specified
> >> +in simple-panel.txt in this directory.
> 
> Seems like we could just have a list of compatible strings rather than
> a mostly duplicated file.

We've been doing it this way for all other panels.

> >> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> >> b/drivers/gpu/drm/panel/panel-simple.c
> >> index a251361..adc40a7 100644
> >> --- a/drivers/gpu/drm/panel/panel-simple.c
> >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> >> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
> >>   },
> >>  };
> >>
> >> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
> >> + .clock = 6500,
> >> + .hdisplay = 320,
> >> + .hsync_start = 320 + 38,
> >> + .hsync_end = 320 + 38 + 20,
> >> + .htotal = 320 + 38 + 20 + 30,
> >> + .vdisplay = 240,
> >> + .vsync_start = 240 + 15,
> >> + .vsync_end = 240 + 15 + 4,
> >> + .vtotal = 240 + 15 + 4 + 3,
> >> + .vrefresh = 60,
> >> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
> >> +  DRM_MODE_FLAG_POL_DE_LOW,
> 
> Why aren't you using:
> 
> Documentation/devicetree/bindings/video/display-timing.txt

Because it's redundant information. We need to have a compatible for the
panel in the device tree anyway and that already implicitly defines the
display mode.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Eric Bénard]

Hi Thierry,

Le Tue, 24 Jun 2014 23:49:37 +0200,
Thierry Reding  a ?crit :

> On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
> [...]
> > diff --git 
> > a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
> > b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> [...]
> > @@ -0,0 +1,7 @@
> > +Eukrea DVI-SVGA (800x600 pixels) DVI output.
> [...]
> > diff --git 
> > a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> > b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> [...]
> > @@ -0,0 +1,7 @@
> > +Eukrea DVI-VGA (640x480 pixels) DVI output.
> 
> DVI outputs shouldn't be using the panel framework and this binding at
> all. DVI usually has the means to determine all of this by itself. Why
> do you need to represent this as a panel in device tree?
> 
because on this very simple display board, we only have DVI LVDS signals
without the I2C to detect the display.

Best regards
Eric

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 24.06.2014 12:05, schrieb Michel D?nzer:
> On 24.06.2014 05:32, Dieter N?tzel wrote:
>> Am 23.06.2014 21:46, schrieb Dieter N?tzel:
>>> Am 23.06.2014 11:34, schrieb Michel D?nzer:
 On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>> 
>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
>> completion
>> event has impossible msc [x-1] < target_msc [x]
>> 
>> messages in the X log file which have been popping up in bug 
>> reports
>> lately.
>> This also results in 0s being returned to the client for the MSC 
>> and
>> timestamp of the swap completion, which could cause all kinds of 
>> bad
>> behaviour.
> First of all thanks for looking into it. Are you getting this on
> 3.16 or
> 3.15?
 
 I haven't actually run into this myself yet. I thought I'd seen it 
 in
 several bug reports, but right now I can only find
 https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
 to
 include the page flipping changes from 3.16.
>>> 
>>> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug 
>>> report.
>>> But only the lines in Xorg.0.log.
>>> NO signs of any damage/error in use.
>>> 
>>> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
>>> 
>>> I've tried 3.15-rc7 + Christian's pflip rework (did some little
>>> handwork), too.
>>> It was solid but I saw the reported flip/black distortion in the 
>>> below
>>> part during Kwin 4.13 cube screen effect (rotation). Your fix for
>>> 3.16-rc1 fixed that.
> 
> That's good to hear.
> 
> 
>> I can reliable generate such lines in Xorg.0.log with KWin cube 
>> desktop
>> effect.
>> 
>> Rotate screens with mouse wheel or screen switcher => new entry in
>> Xorg.0.log. If it happens I notice ('see') flip delay.
> 
> I was only able to reproduce it a couple of times even with that, but 
> not
> at all yet with the patch below. Does it help for you as well?

You have my Tested-by: for it.
Can't reproduce it any longer with your patch below.
Even that it didn't apply ontop of 3.16-rc2, but
most of the time I know what I'm doing...;-)

Now some little Fu?ball watching!

Cheers,
Dieter

> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8b575a4..8350f8c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -336,14 +336,19 @@ void radeon_crtc_handle_flip(struct
> radeon_device *rdev, int crtc_id)
> struct radeon_crtc *radeon_crtc = 
> rdev->mode_info.crtcs[crtc_id];
> struct radeon_flip_work *work;
> unsigned long flags;
> +   struct timeval vblank_time;
> +   u32 vblank_seq;
> 
> /* this can happen at init */
> if (radeon_crtc == NULL)
> return;
> 
> +   vblank_seq = drm_vblank_count_and_time(rdev->ddev, crtc_id,
> _time);
> +
> spin_lock_irqsave(>ddev->event_lock, flags);
> work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (work == NULL ||
> +   (vblank_seq - work->event->event.sequence) > (1<<23)) {
> spin_unlock_irqrestore(>ddev->event_lock, flags);
> return;
> }
> @@ -379,6 +384,7 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> 
> struct drm_crtc *crtc = _crtc->base;
> struct drm_framebuffer *fb = work->fb;
> +   struct timeval vblank_time;
> 
> uint32_t tiling_flags, pitch_pixels;
> uint64_t base;
> @@ -466,6 +472,10 @@ static void radeon_flip_work_func(struct
> work_struct *__work)
> goto pflip_cleanup;
> }
> 
> +   work->event->event.sequence =
> +   drm_vblank_count_and_time(crtc->dev, 
> radeon_crtc->crtc_id,
> + _time) + 1;
> +
> /* We borrow the event spin lock for protecting flip_work */
> spin_lock_irqsave(>dev->event_lock, flags);

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Inki Dae]

2014-06-24 20:38 GMT+09:00 Andreas F?rber :
> Am 24.06.2014 07:21, schrieb Inki Dae:
>> On 2014? 06? 23? 14:32, Rahul Sharma wrote:
>>> Allowing only one layer update per vsync can cause issues
>>> while there are update available for both layers. There is
>>> a good amount of possibility to loose updates if we allow
>>> single update per vsync.
>>>
>>> Signed-off-by: Rahul Sharma 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
>>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index d359501..6773b03 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, 
>>> int win)
>>>  static void mixer_layer_update(struct mixer_context *ctx)
>>>  {
>>>  struct mixer_resources *res = >mixer_res;
>>> -u32 val;
>>> -
>>> -val = mixer_reg_read(res, MXR_CFG);
>>>
>>> -/* allow one update per vsync only */
>>> -if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
>>> -mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>>> +mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>>
>> Rahul, it looks good to me and ok as is. But above codes don't consider
>> Exynos4 series. In case of Exynos4xxx SoC,
>> MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
>> register are reserved fields. So can you work that patch to be
>> considered for Exynos4xxx SoC? That patch would be additional one.
>>
>> Anyway, will apply it as is, and I will wait for the additional patch.
>
> If it's not too late, could you fix up "multiple" in the subject? :)

Corrected. :)

Thanks,
Inki Dae

>
> Cheers,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Thierry Reding]

On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
[...]
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
[...]
> @@ -0,0 +1,7 @@
> +Eukrea DVI-SVGA (800x600 pixels) DVI output.
[...]
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
[...]
> @@ -0,0 +1,7 @@
> +Eukrea DVI-VGA (640x480 pixels) DVI output.

DVI outputs shouldn't be using the panel framework and this binding at
all. DVI usually has the means to determine all of this by itself. Why
do you need to represent this as a panel in device tree?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

[GIT PULL] exynos-drm-fixes

[inki....@samsung.com]

Hi Dave,

   This pull-request fixes hdmi power-off order issue, mixer issues
   related to power on/off, and includes trivial fixups.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:

  Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to 5d39b9ee8b16b57fdbc065b91ebdd4ac03dab568:

  drm/exynos: enable vsync interrupt while waiting for vblank (2014-06-24 
23:44:50 +0900)


Andrzej Hajda (1):
  drm/exynos: disable unused windows on apply

Dan Carpenter (1):
  drm/exynos: change zero to NULL for sparse

Inki Dae (1):
  drm/exynos: hdmi: fix power order issue

Rahul Sharma (5):
  drm/exynos: set power state variable after enabling clocks and power
  drm/exynos: stop mixer before gating clocks during poweroff
  drm/exynos: allow multiple layer updates per vsync for mixer
  drm/exynos: soft reset mixer before reconfigure after power-on
  drm/exynos: enable vsync interrupt while waiting for vblank

Sachin Kamat (1):
  drm/exynos: Fix de-registration ordering

Tomasz Figa (1):
  drm/exynos: dpi: Fix NULL pointer dereference with legacy bindings

 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |8 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c |   19 
 drivers/gpu/drm/exynos/exynos_mixer.c|   50 +-
 drivers/gpu/drm/exynos/regs-mixer.h  |1 +
 7 files changed, 63 insertions(+), 21 deletions(-)

[Nouveau] [PATCH v2 2/3] drm/ttm: introduce dma cache sync helpers

[Alexandre Courbot]

On Tue, Jun 24, 2014 at 10:58 PM, Lucas Stach  wrote:
> Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot:
>> On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach  
>> wrote:
>> > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
>> >> op 24-06-14 14:23, Alexandre Courbot schreef:
>> >> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot > >> > nvidia.com> wrote:
>> >> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote:
>> >> >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote:
>> >>  On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
>> >> > From: Lucas Stach 
>> >> >
>> >> > On architectures for which access to GPU memory is non-coherent,
>> >> > caches need to be flushed and invalidated explicitly at the
>> >> > appropriate places. Introduce two small helpers to make things
>> >> > easy for TTM-based drivers.
>> >> 
>> >>  Have you run this with DMA API debugging enabled?  I suspect you 
>> >>  haven't,
>> >>  and I recommend that you do.
>> >> >>>
>> >> >>> # cat /sys/kernel/debug/dma-api/error_count
>> >> >>> 162621
>> >> >>>
>> >> >>> (??? ???)
>> >> >>
>> >> >> *puts table back on its feet*
>> >> >>
>> >> >> So, yeah - TTM memory is not allocated using the DMA API, hence we 
>> >> >> cannot
>> >> >> use the DMA API to sync it. Thanks Russell for pointing it out.
>> >> >>
>> >> >> The only alternative I see here is to flush the CPU caches when 
>> >> >> syncing for
>> >> >> the device, and invalidate them for the other direction. Of course if 
>> >> >> the
>> >> >> device has caches on its side as well the opposite operation must also 
>> >> >> be
>> >> >> done for it. Guess the only way is to handle it all by ourselves here. 
>> >> >> :/
>> >> > ... and it really sucks. Basically if we cannot use the DMA API here
>> >> > we will lose the convenience of having a portable API that does just
>> >> > the right thing for the underlying platform. Without it we would have
>> >> > to duplicate arm_iommu_sync_single_for_cpu/device() and we would only
>> >> > have support for ARM.
>> >> >
>> >> > The usage of the DMA API that we are doing might be illegal, but in
>> >> > essence it does exactly what we need - at least for ARM. What are the
>> >> > alternatives?
>> >> Convert TTM to use the dma api? :-)
>> >
>> > Actually TTM already has a page alloc backend using the DMA API. It's
>> > just not used for the standard case right now.
>>
>> Indeed, and Nouveau even already makes use of it if CONFIG_SWIOTLB is
>> set apparently.
>>
>> > I would argue that we should just use this page allocator (which has the
>> > side effect of getting pages from CMA if available -> you are actually
>> > free to change the caching) and do away with the other allocator in the
>> > ARM case.
>>
>> Mm? Does it mean that CMA memory is not mapped into lowmem? That would
>> certainly help in the present case, but I wonder how useful it will be
>> once the iommu support is in place. Will also need to consider
>> performance of such coherent memory for e.g. user-space mappings.
>>
>> Anyway, I will experiment a bit with this tomorrow, thanks!
>
> CMA memory is reserved before the lowmem section mapping is set up. It
> is then mapped with individual 4k pages before giving it back to the
> buddy allocator.
> This means CMA pages in use by the kernel are mapped into lowmem, but
> they are actually unmapped from lowmem once you allocate them as DMA
> memory.

Thanks for the explanation. I really need to spend more time studying
the DMA allocator. I wonder if all this is already explained somewhere
in Documentation/ ?

[PATCH 1/2 v2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

[Matthew Garrett]

On Wed, 2014-06-25 at 00:55 +0200, Bruno Pr?mont wrote:

> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting
> sysfb/efifb optional.
> 

Both look good to me.

Acked-by: Matthew Garrett 

-- 
Matthew Garrett