15-rc1: radeon modesetting fails

[Deucher, Alexander]

> -Original Message-
> From: Kertesz Laszlo [mailto:laszlo.kertesz at gmail.com]
> Sent: Tuesday, April 15, 2014 5:50 PM
> To: Borislav Petkov
> Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI
> developers; lkml
> Subject: Re: 15-rc1: radeon modesetting fails
> 
> Borislav Petkov wrote:
> > On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> >> Honestly didnt try that but i assume yes, since the screens go black
> >> when it should change resolution.
> >
> > Pls try it and let us know whether you see the machine booting further,
> > albeit without modesetting.
> >
> > Thanks.
> >
> 
> Yes, it is working that way. But no X, i assume this is expected.

Turning off modesetting basically disables the driver.

Alex

15-rc1: radeon modesetting fails

[Kertesz Laszlo]

Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
>> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
>> drm, mesa built from git today. I see nothing and receive no message
>> on the monitors (i have 2 identical ones, one on the DVI andother on
>> HDMI), but the system is running fine otherwise it seems, i could
>> switch to the console, log in and reboot blindly. Cristian's branch
>> didnt help.
>>
>> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
>
> Does booting with "radeon.modeset=0" help?
>
Honestly didnt try that but i assume yes, since the screens go black when it 
should change resolution.

-- 
O zi buna,
Kertesz Laszlo

15-rc1: radeon modesetting fails

[Kertesz Laszlo]

Alex Deucher wrote:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: 
>>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>>
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas 
>> Date:   Tue Mar 18 17:16:52 2014 +0100
>>
>>  drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
>
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.
>
> Alex
>
>>

Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa 
built from git today. I see nothing and receive no message on the monitors (i 
have 2 identical ones, one on the DVI andother on HDMI), but the system is 
running fine  otherwise it seems, i could switch to the console, log in and 
reboot blindly. Cristian's branch didnt help.

Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.

Attached dmesg (booted the unmodified rc1 kernel, switched to tty1 and rebooted 
blindly).

-- 
O zi buna,
Kertesz Laszlo
-- 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.15.0-rc1 (laca at laca-desktop) (gcc version 
4.8.2 (Debian 4.8.2-16) ) #2 SMP Mon Apr 14 19:27:37 EEST 2014
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.15.0-rc1 
root=UUID=89d577ec-47b9-4aa7-96a1-ad1f5092ead6 ro 
resume=UUID=bafe38cf-553c-433b-ae37-118bdeebbfac ignore_loglevel radeon.dpm=1 
it87.force_id=0x8728
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7cce] usable
[0.00] BIOS-e820: [mem 0x7ccf-0x7cd1] reserved
[0.00] BIOS-e820: [mem 0x7cd2-0x7cfe2fff] usable
[0.00] BIOS-e820: [mem 0x7cfe3000-0x7d0aefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7d0af000-0x7e1c4fff] reserved
[0.00] BIOS-e820: [mem 0x7e1c5000-0x7e1c5fff] usable
[0.00] BIOS-e820: [mem 0x7e1c6000-0x7e3cbfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7e3cc000-0x7e84] usable
[0.00] BIOS-e820: [mem 0x7e85-0x7efe0fff] reserved
[0.00] BIOS-e820: [mem 0x7efe1000-0x7eff] usable
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023eff] usable
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./F2A88X-D3H, BIOS F3 11/18/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x23f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B write-through
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 

15-rc1: radeon modesetting fails

[Borislav Petkov]

On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> Honestly didnt try that but i assume yes, since the screens go black
> when it should change resolution.

Pls try it and let us know whether you see the machine booting further,
albeit without modesetting.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #225 from Kajzer  ---
(In reply to comment #219)
> Also, my understanding was that this bug list is for DPM problems in the
> newest mesa.  If this is so, then I don't even know why are you in this
> thread in the first place, since you are using 9.2.

I'm here because the title of this thread says it all.

Maybe you should try to test your dpm issues with something more stable, just
install kernel 3.14, don't go crazy with git versions of X and Mesa, maybe your
current problems will go away.

-- 
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/20140415/b814cae0/attachment.html>

15-rc1: radeon modesetting fails

[Borislav Petkov]

On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
> drm, mesa built from git today. I see nothing and receive no message
> on the monitors (i have 2 identical ones, one on the DVI andother on
> HDMI), but the system is running fine otherwise it seems, i could
> switch to the console, log in and reboot blindly. Cristian's branch
> didnt help.
>
> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.

Does booting with "radeon.modeset=0" help?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Rahul Sharma]

On 15 April 2014 18:41, Tomasz Stanislawski  wrote:
> On 04/15/2014 11:42 AM, Rahul Sharma wrote:
>> Hi Tomasz,
>>
>> On 15 April 2014 14:57, Tomasz Stanislawski  
>> wrote:
>>> Adds support for limitation of maximal pixel clock of HDMI
>>> signal. This feature is needed on boards that contains
>>> lines or bridges with frequency limitations.
>>>
>>> Signed-off-by: Tomasz Stanislawski 
>>> ---
>>>  .../devicetree/bindings/video/exynos_hdmi.txt  |4 
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
>>>  include/media/s5p_hdmi.h   |1 +
>>>  3 files changed, 17 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> index f9187a2..8718f8d 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> @@ -28,6 +28,10 @@ Required properties:
>>>  - ddc: phandle to the hdmi ddc node
>>>  - phy: phandle to the hdmi phy node
>>>
>>> +Optional properties:
>>> +- max-pixel-clock: used to limit the maximal pixel clock if a board has 
>>> lines,
>>> +   connectors or bridges not capable of carring higher frequencies
>>> +
>>>  Example:
>>>
>>> hdmi {
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index 2a18f4e..404f1b7 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -195,6 +195,7 @@ struct hdmi_context {
>>> struct hdmi_resources   res;
>>>
>>> int hpd_gpio;
>>> +   u32 max_pixel_clock;
>>>
>>> enum hdmi_type  type;
>>>  };
>>> @@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector 
>>> *connector,
>>> if (ret)
>>> return MODE_BAD;
>>>
>>> +   if (mode->clock * 1000 > hdata->max_pixel_clock)
>>> +   return MODE_BAD;
>>> +
>>> ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
>>> if (ret < 0)
>>> return MODE_BAD;
>>> @@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
>>> *drm_hdmi_dt_parse_pdata
>>> return NULL;
>>> }
>>>
>>> +   of_property_read_u32(np, "max-pixel-clock", >max_pixel_clock);
>>> +
>>> return pd;
>>>  }
>>>
>>> @@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
>>> if (!pdata)
>>> return -EINVAL;
>>>
>>> +   if (!pdata->max_pixel_clock) {
>>> +   DRM_INFO("max-pixel-clock is zero, using INF\n");
>>> +   pdata->max_pixel_clock = U32_MAX;
>>> +   }
>>> +
>>> hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
>>> if (!hdata)
>>> return -ENOMEM;
>>> @@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
>>> hdata->type = drv_data->type;
>>>
>>> hdata->hpd_gpio = pdata->hpd_gpio;
>>> +   hdata->max_pixel_clock = pdata->max_pixel_clock;
>>> hdata->dev = dev;
>>>
>>> ret = hdmi_resources_init(hdata);
>>> diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
>>> index 181642b..7272d65 100644
>>> --- a/include/media/s5p_hdmi.h
>>> +++ b/include/media/s5p_hdmi.h
>>> @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
>>> int mhl_bus;
>>> struct i2c_board_info *mhl_info;
>>> int hpd_gpio;
>>> +   u32 max_pixel_clock;
>>>  };
>>
>> We have already removed Non DT support from the drm hdmi
>> driver. IMO we should not be extending the pdata struct.
>>
>> Regards,
>> Rahul Sharma
>
> Hi Rahul,
>
> This is not a non-DT patch. The s5p_hdmi_platform_data is
> generated from DT itself. This structure is just
> a parsed version of DT attributes.
>
> It may be a good idea to rename s5p_hdmi_platform_data
> to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
> or parse DT directly in probe function.
>
> I can prepare a patch for that.

Else we can completely remove the dependency from
s5p_hdmi_platform_data. We can directly assign to hdmi context
variables. Later we can remove that struct itself from include/.
What you say?

Regards,
Rahul Sharma

>
> Regards,
> Tomasz Stanislawski
>
>
>>
>>>
>>>  #endif /* S5P_HDMI_H */
>>> --
>>> 1.7.9.5
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #224 from Alex Deucher  ---
(In reply to comment #223)
> Ok, thanks for enlightening me. I had things confused. So this is a kernel
> bug list? I thought it is X-related.

https://bugs.freedesktop.org covers lots of projects including the drm kernel
drivers.  The product and component fields target different parts of the stack.
 In this case Product = DRI and Component = DRM/Radeon is the radeon kernel
driver.  Product = Mesa and Component = Drivers/Gallium/r600 would be the mesa
driver.

-- 
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/20140415/7151be50/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #223 from lockheed  ---
> It's part of the radeon kernel driver.  It doesn't matter what userspace
> drivers (mesa, xf86-video-ati) you use.

Ok, thanks for enlightening me. I had things confused. So this is a kernel bug
list? I thought it is X-related.

-- 
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/20140415/d066eaf4/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #222 from Alex Deucher  ---
(In reply to comment #221)
> > Mesa and dpm are unrelated.  This bug is about dpm stability on rv6xx asics
> > regardless of what version of the userspace drivers you are using.
> 
> So what is DPM dependant on/part of? xf86-video-ati?

It's part of the radeon kernel driver.  It doesn't matter what userspace
drivers (mesa, xf86-video-ati) you use.

-- 
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/20140415/03745b3f/attachment-0001.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #221 from lockheed  ---
> Mesa and dpm are unrelated.  This bug is about dpm stability on rv6xx asics
> regardless of what version of the userspace drivers you are using.

So what is DPM dependant on/part of? xf86-video-ati?

-- 
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/20140415/1019fd6c/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #220 from Alex Deucher  ---
(In reply to comment #219)
> 
> Also, my understanding was that this bug list is for DPM problems in the
> newest mesa.  If this is so, then I don't even know why are you in this
> thread in the first place, since you are using 9.2.

Mesa and dpm are unrelated.  This bug is about dpm stability on rv6xx asics
regardless of what version of the userspace drivers you are using.

-- 
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/20140415/106643e1/attachment.html>

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

[DaeSeok Youn]

2014-04-15 16:00 GMT+09:00 Ben Skeggs :
> - Original Message -
>> From: "Daeseok Youn" 
>> To: airlied at linux.ie
>> Cc: bskeggs at redhat.com, dri-devel at lists.freedesktop.org, linux-kernel 
>> at vger.kernel.org
>> Sent: Tuesday, 15 April, 2014 11:56:49 AM
>> Subject: [PATCH] drm/nouveau/clk: fix possible NULL pointer dereference
>>
>>
>> It need to be checking NULL before dereferencing.
> There's no dereference here.  It's an address calculation only.
Oh.. You're right.
But the address calculation doesn't need when "pstate" is NULL.
Can I re-send this patch after modifying subject and comment of this
patch properly?
Or drop this patch.

Thanks for review.

Regards,
Daeseok Youn.
>
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>>  drivers/gpu/drm/nouveau/core/subdev/clock/base.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> index dd62bae..a586d030 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
>> @@ -290,9 +290,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx)
>>   return 0;
>>
>>   pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
>> - cstate = >base;
>>   if (!pstate)
>>   return -ENOMEM;
>> + cstate = >base;
>>
>>   INIT_LIST_HEAD(>list);
>>
>> --
>> 1.7.4.4
>>
>>
>>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #219 from lockheed  ---
> Yeah, well it's a weird thing this problem, it crashes for you and it
> doesn't crash for me, you can boot every time and I can't boot every time,
> you see performance and features and I don't.
> 
> Although, regarding performance and features, I was only curious to see if
> some games from Steam which worked under catalyst will work with open
> driver, and they didn't.
> So for me I guess features are not there yet, performance maybe.

I don't game, so am not sure about performance. What I do know is the power
management got way better, and with current drivers I get temperatures
comparable (or even slightly lower) than with Catalysts.

What I think is key here, is that you are using 9.2, and I get my issues on
10.x.

Also, my understanding was that this bug list is for DPM problems in the newest
mesa.  If this is so, then I don't even know why are you in this thread in the
first place, since you are using 9.2.

-- 
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/20140415/0452c18f/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #218 from Kajzer  ---
(In reply to comment #217)
> Yeah, that's the whole point. Performance and features are already here.
> What is not here is working DPM. As it is now, if crashes profusely on our
> chips.

Yeah, well it's a weird thing this problem, it crashes for you and it doesn't
crash for me, you can boot every time and I can't boot every time, you see
performance and features and I don't.

Although, regarding performance and features, I was only curious to see if some
games from Steam which worked under catalyst will work with open driver, and
they didn't.
So for me I guess features are not there yet, performance maybe.

-- 
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/20140415/27a1f36c/attachment.html>

[Bug 76484] [radeonsi] Strike Suit Zero fail to start

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

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

Laurent carlier  changed:

   What|Removed |Added

 Blocks||77449

-- 
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/20140415/1ad29d2a/attachment.html>

Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

On 15/04/14 15:24, Rob Clark wrote:

> probably split out omap_plane_mode_set_internal(), call that directly
> from update_plane() for plane operations.  And then do the refcnt
> dance in the new omap_plane_mode_set() which calls _internal()..

We don't actually need that. This did the trick:

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index df1725247cca..3cf31ee59aac 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -225,6 +225,11 @@ int omap_plane_mode_set(struct drm_plane *plane,
omap_plane->apply_done_cb.arg = arg;
}

+   if (plane->fb)
+   drm_framebuffer_unreference(plane->fb);
+
+   drm_framebuffer_reference(fb);
+
plane->fb = fb;
plane->crtc = crtc;

@@ -241,11 +246,6 @@ static int omap_plane_update(struct drm_plane *plane,
struct omap_plane *omap_plane = to_omap_plane(plane);
omap_plane->enabled = true;

-   if (plane->fb)
-   drm_framebuffer_unreference(plane->fb);
-
-   drm_framebuffer_reference(fb);
-
/* omap_plane_mode_set() takes adjusted src */
switch (omap_plane->win.rotation & 0xf) {
case BIT(DRM_ROTATE_90):

With quick tests, works fine so far.

Still I have to say that the ref counting doesn't feel quite right (or
I'm missing something).

As far as I understand, the drm_mode_setplane() gets a ref to the fb,
and stores it in plane->fb. Why do we take a new ref in
omap_plane_update (or with the patch above, in omap_plane_mode_set), and
also store it in plane->fb there? Feels like the same task is done in
two places.

It looks to me like drm_mode_setplane() doesn't really presume that the
update_plane would set plane->fb or plane->crtc, as it does that itself
(and only if update_plane has succeeded).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/043584e0/attachment-0001.sig>

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Tomasz Stanislawski]

On 04/15/2014 03:42 PM, Rahul Sharma wrote:
> On 15 April 2014 18:41, Tomasz Stanislawski  
> wrote:
>> On 04/15/2014 11:42 AM, Rahul Sharma wrote:
>>> Hi Tomasz,
>>>
>>> On 15 April 2014 14:57, Tomasz Stanislawski  
>>> wrote:
 Adds support for limitation of maximal pixel clock of HDMI
 signal. This feature is needed on boards that contains
 lines or bridges with frequency limitations.

 Signed-off-by: Tomasz Stanislawski 
[snip]

 diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
 index 181642b..7272d65 100644
 --- a/include/media/s5p_hdmi.h
 +++ b/include/media/s5p_hdmi.h
 @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
 int mhl_bus;
 struct i2c_board_info *mhl_info;
 int hpd_gpio;
 +   u32 max_pixel_clock;
  };
>>>
>>> We have already removed Non DT support from the drm hdmi
>>> driver. IMO we should not be extending the pdata struct.
>>>
>>> Regards,
>>> Rahul Sharma
>>
>> Hi Rahul,
>>
>> This is not a non-DT patch. The s5p_hdmi_platform_data is
>> generated from DT itself. This structure is just
>> a parsed version of DT attributes.
>>
>> It may be a good idea to rename s5p_hdmi_platform_data
>> to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
>> or parse DT directly in probe function.
>>
>> I can prepare a patch for that.
> 
> Else we can completely remove the dependency from
> s5p_hdmi_platform_data. We can directly assign to hdmi context
> variables. Later we can remove that struct itself from include/.
> What you say?

This structure cannot be removed from include yet because it is used by s5p-tv 
driver.
However its usage can be removed from both drivers.
I can prepare both.

> 
> Regards,
> Rahul Sharma
> 

Regards,
Tomasz Stanislawski

>>
>> Regards,
>> Tomasz Stanislawski
>>
>>
>>>

  #endif /* S5P_HDMI_H */
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-devel at lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 

15-rc1: radeon modesetting fails

[Borislav Petkov]

On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian K?nig wrote:
> >Does reverting:
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> >fix the issue?  We may need to tweak the pll parameters for older asics.
> 
> Yeah, indeed the most likely cause. Please provide dmesg outputs created
> with drm.ebug=0xe for the old and the new kernel.

Hey, I finally haz 15-rc1+ running here. And I can even see something!

:-)

Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip
branch which didn't apply cleanly. So I ended up fixing the conflicts
and got the revert below.

With it, the machine booted fine, so it looks like the revert worked.

Christian, I'm sending dmesg outputs in another private mail to you
guys.

Thanks.

---
From: Borislav Petkov 
Date: Tue, 15 Apr 2014 16:00:58 +0200
Subject: [PATCH] Revert "drm/radeon: rework finding display PLL numbers v2"

This reverts commit 32167016076f714f0e35e287fbead7de0f1fb179.

Conflicts:
drivers/gpu/drm/radeon/radeon_display.c
---
 drivers/gpu/drm/radeon/radeon_display.c | 246 
 1 file changed, 90 insertions(+), 156 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 2f42912031ac..83891923ac2d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -34,8 +34,6 @@
 #include 
 #include 

-#include 
-
 static void avivo_crtc_load_lut(struct drm_crtc *crtc)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
@@ -802,57 +800,66 @@ int radeon_ddc_get_modes(struct radeon_connector 
*radeon_connector)
 }

 /* avivo */
+static void avivo_get_fb_div(struct radeon_pll *pll,
+u32 target_clock,
+u32 post_div,
+u32 ref_div,
+u32 *fb_div,
+u32 *frac_fb_div)
+{
+   u32 tmp = post_div * ref_div;

-/**
- * avivo_reduce_ratio - fractional number reduction
- *
- * @nom: nominator
- * @den: denominator
- * @nom_min: minimum value for nominator
- * @den_min: minimum value for denominator
- *
- * Find the greatest common divisor and apply it on both nominator and
- * denominator, but make nominator and denominator are at least as large
- * as their minimum values.
- */
-static void avivo_reduce_ratio(unsigned *nom, unsigned *den,
-  unsigned nom_min, unsigned den_min)
+   tmp *= target_clock;
+   *fb_div = tmp / pll->reference_freq;
+   *frac_fb_div = tmp % pll->reference_freq;
+
+if (*fb_div > pll->max_feedback_div)
+   *fb_div = pll->max_feedback_div;
+else if (*fb_div < pll->min_feedback_div)
+*fb_div = pll->min_feedback_div;
+}
+
+static u32 avivo_get_post_div(struct radeon_pll *pll,
+ u32 target_clock)
 {
-   unsigned tmp;
-
-   /* reduce the numbers to a simpler ratio */
-   tmp = gcd(*nom, *den);
-   *nom /= tmp;
-   *den /= tmp;
-
-   /* make sure nominator is large enough */
-if (*nom < nom_min) {
-   tmp = (nom_min + *nom - 1) / *nom;
-   *nom *= tmp;
-   *den *= tmp;
+   u32 vco, post_div, tmp;
+
+   if (pll->flags & RADEON_PLL_USE_POST_DIV)
+   return pll->post_div;
+
+   if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+   if (pll->flags & RADEON_PLL_IS_LCD)
+   vco = pll->lcd_pll_out_min;
+   else
+   vco = pll->pll_out_min;
+   } else {
+   if (pll->flags & RADEON_PLL_IS_LCD)
+   vco = pll->lcd_pll_out_max;
+   else
+   vco = pll->pll_out_max;
}

-   /* make sure the denominator is large enough */
-   if (*den < den_min) {
-   tmp = (den_min + *den - 1) / *den;
-   *nom *= tmp;
-   *den *= tmp;
+   post_div = vco / target_clock;
+   tmp = vco % target_clock;
+
+   if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+   if (tmp)
+   post_div++;
+   } else {
+   if (!tmp)
+   post_div--;
}
+
+   if (post_div > pll->max_post_div)
+   post_div = pll->max_post_div;
+   else if (post_div < pll->min_post_div)
+   post_div = pll->min_post_div;
+
+   return post_div;
 }

-/**
- * radeon_compute_pll_avivo - compute PLL paramaters
- *
- * @pll: information about the PLL
- * @dot_clock_p: resulting pixel clock
- * fb_div_p: resulting feedback divider
- * frac_fb_div_p: fractional part of the feedback divider
- * ref_div_p: resulting reference divider
- * post_div_p: resulting reference divider
- *
- * Try to calculate the PLL parameters to generate the given frequency:
- * 

[PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit

[Inki Dae]

> -Original Message-
> From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
> Sent: Monday, April 14, 2014 11:05 PM
> To: Inki Dae; 'Andrzej Hajda'
> Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell
King';
> dri-devel at lists.freedesktop.org; 'Marek Szyprowski'
> Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
> init/deinit
> 
> On 14.04.2014 15:55, Inki Dae wrote:
> > Hi Tomasz,
> >
> > Always thanks for your opinions.
> >
> >> -Original Message-
> >> From: linux-samsung-soc-owner at vger.kernel.org
> >> [mailto:linux-samsung-soc- owner at vger.kernel.org] On Behalf Of Tomasz
> >> Figa
> >> Sent: Monday, April 14, 2014 8:32 PM
> >> To: Inki Dae; 'Andrzej Hajda'
> >> Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell
> > King';
> >> dri-devel at lists.freedesktop.org; 'Marek Szyprowski'
> >> Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
> >> init/deinit
> >>
> >> Hi Inki,
> >>
> >> On 14.04.2014 13:04, Inki Dae wrote:
> >>>
> >>>
>  -Original Message-
>  From: Andrzej Hajda [mailto:a.hajda at samsung.com]
>  Sent: Monday, April 14, 2014 5:55 PM
>  To: Inki Dae
>  Cc: dri-devel at lists.freedesktop.org; moderated list:ARM/S5P EXYNOS
>  AR...; Kyungmin Park; Marek Szyprowski
>  Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
>  init/deinit
> 
>  On 04/12/2014 04:18 PM, Inki Dae wrote:
> > Hi Andrzej,
> >
> > Thanks for your contributions.
> >
> > 2014-04-11 23:11 GMT+09:00 Andrzej Hajda :
> >> Hi Inki,
> >>
> >> This patchset refactors drm device initialization. Details are
> >> described in respective patches. It is an alternative to DT
> >> supernode
>  concept.
> >>
> >> The first patch uses linker sections to get rid of ifdef macros,
> >> it is not
> > That's a good idea. :) We could avoid ugly #ifdef ~ #endif with
> > this
> >>> way.
> >
> >> essential for 2nd patch but it makes code more readable. Similar
> >> approach is used by irqchip, clks and clk_sources.
> > But 2nd patch doesn't seem reasnoable to me. Your approach is same
> > as existing one conceptually. I think we need to handle drm driver
> > in a different way from irqchip, clks and clk_sources.
> >
> > DRM driver means one integrated graphics card but in most embedded
> > systems, graphics and display relevant devices have separated
> > hardware resources. So we would need abstractional integrated
> > hardware, display-subsystem, super device. That is why I are
> > trying to use super device approach, and conceptually it would be
> > right solution. It wouldn't be not good to combine those separated
> > hardware somehow using specific codes.
> 
>  Conceptually both approaches are the same: we have number of
>  devices which should be ready before we can start super-device and
>  if any device is to be removed super-device should be removed before.
>  The difference is in 'details':
>  - super-node approach have list of components provided explicitly
>  in DT special node,
>  - in this approach list of components is constructed from devices
>  present in the system.
> 
>  Creating special DT node with information which is available anyway
>  seems to be redundant and against DT rules.
> 
> >>>
> >>> CCing Russell King,
> >>>
> >>> What is the special DT node? You mean device node from ports property?
> >>>
> >>> It is supposed  to use super device and its properties in mainline
> >>> so I don't see what it is against DT rules. If they are really
> >>> against DT rules, why component framework is in mainline?
> >>
> >> Component framework in mainline doesn't have anything in common with
DT.
> >> All it does is providing tools for handling cases where a subsystem
> >> can be initialized only after all components are available. It
> >> doesn't define any means of getting the list of components, it's a
> >> task for the user of this framework to provide it.
> >>
> >>>
> >>> As you said above, conceptually both approaches may be the same but
> >>> your approach has no any abstract hardware meaning one integrated
> >>> hardware. And if conceptually both approaches are the same, it would
> >>> be good to use existing infrastructure, component framework so there
> >>> is no any reason to add and use specific codes.
> >>
> >> What do you mean by "abstract hardware"? Physically, in the SoC,
> >> there is no single integrated hardware block, but multiple IPs and
> >> they need to be described this way in DT. There is nothing that
> >> prevents using them separately if a user doesn't want to use Exynos
> >> DRM. Exynos DRM is a
> >
> > I don't think that super device approach prevents using existing
> > device nodes separately. If a user doesn't want to use Exynos DRM, he
> > cannot declare the super node and each IP would work 

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #217 from lockheed  ---
> However, dpm was still working fine and that's the point of this topic I
> think :)
> Performance and mesa features will come in time I guess. Main thing for me is 
> dpm, powersaving.

Yeah, that's the whole point. Performance and features are already here. What
is not here is working DPM. As it is now, if crashes profusely on our chips.


> I mean, beside debian wheezy I can't even use catalyst, it's possible with a
> painful downgrading of xorg but I don't like that.
> With open drivers I can now use any distro without overheating.
> Yeah, opengl sucks (mesa) at the moment but things might change soon.

Try Arch.

-- 
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/20140415/eb33e624/attachment.html>

[PATCH] drm/exynos: balance framebuffer refcount

[Andrzej Hajda]

exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
Hi,

This patch fixes framebuffer refcount balancing. The issue
appeared after merge of universal plane related patches.
Similar issue affected omap [1].

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/104108

Regards
Andrzej
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e930d4f..1ef5ab9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -145,6 +145,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,

plane->crtc = crtc;
plane->fb = crtc->primary->fb;
+   drm_framebuffer_reference(plane->fb);

return 0;
 }
-- 
1.8.3.2

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Rahul Sharma]

Hi Tomasz,

On 15 April 2014 14:57, Tomasz Stanislawski  wrote:
> Adds support for limitation of maximal pixel clock of HDMI
> signal. This feature is needed on boards that contains
> lines or bridges with frequency limitations.
>
> Signed-off-by: Tomasz Stanislawski 
> ---
>  .../devicetree/bindings/video/exynos_hdmi.txt  |4 
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
>  include/media/s5p_hdmi.h   |1 +
>  3 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index f9187a2..8718f8d 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -28,6 +28,10 @@ Required properties:
>  - ddc: phandle to the hdmi ddc node
>  - phy: phandle to the hdmi phy node
>
> +Optional properties:
> +- max-pixel-clock: used to limit the maximal pixel clock if a board has 
> lines,
> +   connectors or bridges not capable of carring higher frequencies
> +
>  Example:
>
> hdmi {
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2a18f4e..404f1b7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -195,6 +195,7 @@ struct hdmi_context {
> struct hdmi_resources   res;
>
> int hpd_gpio;
> +   u32 max_pixel_clock;
>
> enum hdmi_type  type;
>  };
> @@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector 
> *connector,
> if (ret)
> return MODE_BAD;
>
> +   if (mode->clock * 1000 > hdata->max_pixel_clock)
> +   return MODE_BAD;
> +
> ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
> if (ret < 0)
> return MODE_BAD;
> @@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
> *drm_hdmi_dt_parse_pdata
> return NULL;
> }
>
> +   of_property_read_u32(np, "max-pixel-clock", >max_pixel_clock);
> +
> return pd;
>  }
>
> @@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
> if (!pdata)
> return -EINVAL;
>
> +   if (!pdata->max_pixel_clock) {
> +   DRM_INFO("max-pixel-clock is zero, using INF\n");
> +   pdata->max_pixel_clock = U32_MAX;
> +   }
> +
> hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
> if (!hdata)
> return -ENOMEM;
> @@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
> hdata->type = drv_data->type;
>
> hdata->hpd_gpio = pdata->hpd_gpio;
> +   hdata->max_pixel_clock = pdata->max_pixel_clock;
> hdata->dev = dev;
>
> ret = hdmi_resources_init(hdata);
> diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
> index 181642b..7272d65 100644
> --- a/include/media/s5p_hdmi.h
> +++ b/include/media/s5p_hdmi.h
> @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
> int mhl_bus;
> struct i2c_board_info *mhl_info;
> int hpd_gpio;
> +   u32 max_pixel_clock;
>  };

We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.

Regards,
Rahul Sharma

>
>  #endif /* S5P_HDMI_H */
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Tomasz Stanislawski]

On 04/15/2014 11:42 AM, Rahul Sharma wrote:
> Hi Tomasz,
> 
> On 15 April 2014 14:57, Tomasz Stanislawski  
> wrote:
>> Adds support for limitation of maximal pixel clock of HDMI
>> signal. This feature is needed on boards that contains
>> lines or bridges with frequency limitations.
>>
>> Signed-off-by: Tomasz Stanislawski 
>> ---
>>  .../devicetree/bindings/video/exynos_hdmi.txt  |4 
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
>>  include/media/s5p_hdmi.h   |1 +
>>  3 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index f9187a2..8718f8d 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -28,6 +28,10 @@ Required properties:
>>  - ddc: phandle to the hdmi ddc node
>>  - phy: phandle to the hdmi phy node
>>
>> +Optional properties:
>> +- max-pixel-clock: used to limit the maximal pixel clock if a board has 
>> lines,
>> +   connectors or bridges not capable of carring higher frequencies
>> +
>>  Example:
>>
>> hdmi {
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 2a18f4e..404f1b7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -195,6 +195,7 @@ struct hdmi_context {
>> struct hdmi_resources   res;
>>
>> int hpd_gpio;
>> +   u32 max_pixel_clock;
>>
>> enum hdmi_type  type;
>>  };
>> @@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector 
>> *connector,
>> if (ret)
>> return MODE_BAD;
>>
>> +   if (mode->clock * 1000 > hdata->max_pixel_clock)
>> +   return MODE_BAD;
>> +
>> ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
>> if (ret < 0)
>> return MODE_BAD;
>> @@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
>> *drm_hdmi_dt_parse_pdata
>> return NULL;
>> }
>>
>> +   of_property_read_u32(np, "max-pixel-clock", >max_pixel_clock);
>> +
>> return pd;
>>  }
>>
>> @@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
>> if (!pdata)
>> return -EINVAL;
>>
>> +   if (!pdata->max_pixel_clock) {
>> +   DRM_INFO("max-pixel-clock is zero, using INF\n");
>> +   pdata->max_pixel_clock = U32_MAX;
>> +   }
>> +
>> hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
>> if (!hdata)
>> return -ENOMEM;
>> @@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
>> hdata->type = drv_data->type;
>>
>> hdata->hpd_gpio = pdata->hpd_gpio;
>> +   hdata->max_pixel_clock = pdata->max_pixel_clock;
>> hdata->dev = dev;
>>
>> ret = hdmi_resources_init(hdata);
>> diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
>> index 181642b..7272d65 100644
>> --- a/include/media/s5p_hdmi.h
>> +++ b/include/media/s5p_hdmi.h
>> @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
>> int mhl_bus;
>> struct i2c_board_info *mhl_info;
>> int hpd_gpio;
>> +   u32 max_pixel_clock;
>>  };
> 
> We have already removed Non DT support from the drm hdmi
> driver. IMO we should not be extending the pdata struct.
> 
> Regards,
> Rahul Sharma

Hi Rahul,

This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.

It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.

I can prepare a patch for that.

Regards,
Tomasz Stanislawski


> 
>>
>>  #endif /* S5P_HDMI_H */
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

[Alexandre Courbot]

On Mon, Apr 14, 2014 at 5:35 PM, Ben Skeggs  wrote:
> On Fri, Apr 11, 2014 at 5:34 PM, Alexandre Courbot  
> wrote:
>> On 04/11/2014 04:31 PM, Ben Skeggs wrote:
>>>
>>> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot 
>>> wrote:

 On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs  wrote:
>
> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>  wrote:
>>
>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>>>
>>> GK20A's timer is directly attached to the system timer and cannot be
>>> calibrated. Skip the calibration phase on that chip since the
>>> corresponding registers do not exist.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>   drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19
>>> +--
>>>   1 file changed, 13 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> index c0bdd10358d7..822fe0d8a871 100644
>>> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
>>>if (ret)
>>>return ret;
>>>
>>> + /* gk20a does not have the calibration registers */
>>> + if (device->chipset == 0xea)
>>> + goto skip_clk_init;
>>
>>
>> I'm concerned that this won't scale in the future. Perhaps a better
>> solution would be to add a "flags" or "features" field to struct
>> nouveau_device along with feature bits such as HAS_CALIBRATION or
>> similar.
>>
>> That way we don't have to touch this code for every new future Tegra
>> chip. Unless perhaps if there's a reason to expect things to change in
>> newer generations.
>
> I've already handled this in a slightly different way in the tree I'd
> previously pointed Alex at (I think!), as I needed to do the same for
> GM107.
>
> Should just be able to use that implementation (so, just change the
> probe patch) here too.


 I will skip this patch and use your implementation then. Btw,
 shouldn't the source file for the GK20A implementation be named nvea.c
 instead of gk20a.c?
>>>
>>> For the Maxwell stuff I've been using "gm107" now too.  Since we're
>>> working with you guys these days it seems better to use the same names
>>> for things ;)
>>
>>
>> So would you like us to use the same naming scheme as well? So far all my
>> patches use "nvea.c" whenever I need to add code.
> If it's not too much of a problem at this point, then that'd be good.
> Right before I send -next for the next merge window I'll likely do a
> mass rename anyway, so if we can get your patches merged before then
> (which would be really good!), it doesn't matter much.

No problem, I will update the naming to follow what you did with the
timer driver and gm107.

Hopefully I will soon manage to carve out some time to rebase these
patches and send v2.

15-rc1: radeon modesetting fails

[Christian König]

> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.

Yeah, indeed the most likely cause. Please provide dmesg outputs created 
with drm.ebug=0xe for the old and the new kernel.

Christian.

Am 15.04.2014 15:06, schrieb Alex Deucher:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: 
>>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas 
>> Date:   Tue Mar 18 17:16:52 2014 +0100
>>
>>  drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue?  We may need to tweak the pll parameters for older asics.
>
> Alex
>
>> Thanks.
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

[Sachin Kamat]

On 15 April 2014 14:48, Sylwester Nawrocki  wrote:
> On 15/04/14 10:41, Sachin Kamat wrote:
>> On 15 April 2014 11:17, YoungJun Cho  wrote:
>>> This patch adds sysreg device node, and sysreg property to fimd device node
>>> which is required to use I80 interface.
>>>
>>> Signed-off-by: YoungJun Cho 
>>> Signed-off-by: Inki Dae 
>>> Signed-off-by: Kyungmin Park 
>>> ---
>>>  arch/arm/boot/dts/exynos5.dtsi |6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
>>> index 258dca4..f938bbb 100644
>>> --- a/arch/arm/boot/dts/exynos5.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5.dtsi
>>> @@ -88,12 +88,18 @@
>>> status = "disabled";
>>> };
>>>
>>> +   sys_reg: syscon at 1005 {
>>> +   compatible = "samsung,exynos5-sysreg", "syscon";
>>
>> Do we really need a separate string for this? Can't we use
>> "samsung,exynos4-sysreg" itself?
>
> Currently only "syscon" is meaningful in Linux, and we add second SoC
> specific compatible to be able to distinguish between various SoC
> revisions, should any SoC specific quirks be handled in future.
> Thus there is no much point in adding "samsung,exynos4-sysreg" to
> exynos5.dtsi. We could as well only leave "syscon" entry alone.
> My suggestion is to keep "samsung,exynos5-sysreg", so for instance
> Exynos4 and Exynos5 SOC series SYSREG blocks can be identified in
> an OS.

Yes, this sounds reasonable.

-- 
With warm regards,
Sachin

Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

On 15/04/14 13:10, Rob Clark wrote:

> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
> 
> I suspect there is some way in omap_crtc that I must have assumed the
> ref the crtc held to the fb was sufficient for the plane to hold the
> same ref.  Which is no longer the case.  So somewhere between
> omap_crtc and it's primary plane, there now needs to be an extra level
> of ref/unref.  So ref should have gone up to 5.

I still quite lost here... Looking at the non-primary plane's fb ref
counting, some drivers add and remove refs to fb in
plane->plane_update(). But not all.

For omapdrm, update_plane takes a ref, but I'm not quite sure who frees
that ref. Nothing in omap_plane.c seems to do that.

Maybe the ref taken in omapdrm's update_plane is the "same" one that
should be taken for the primary plane also. But I'm not sure where that
should be taken, and if I do take the ref, then I guess it's freed
somewhere else than in omapdrm.

Taking and releasing refs in totally different places is really bad
practice =).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/e1cde621/attachment-0001.sig>

[RFC PATCH 14/14] ARM: dts: exynos5420: add dsi node

[YoungJun Cho]

This patch adds common part of dsi node.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5420.dtsi |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index f0184c7..aa2350a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -422,6 +422,20 @@
#phy-cells = <1>;
};

+   dsi at 1450 {
+   compatible = "samsung,exynos5420-mipi-dsi";
+   reg = <0x1450 0x1>;
+   interrupts = <0 82 0>;
+   samsung,power-domain = <_pd>;
+   phys = <_phy 1>;
+   phy-names = "dsim";
+   clocks = < 411>, < 146>;
+   clock-names = "bus_clk", "pll_clk";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
fimd at 1440 {
samsung,power-domain = <_pd>;
clocks = < 147>, < 421>;
-- 
1.7.9.5

[RFC PATCH 13/14] ARM: dts: exynos5420: add mipi-phy node

[YoungJun Cho]

This patch adds mipi-phy node for MIPI-DSI device.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5420.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..f0184c7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -416,6 +416,12 @@
phy-names = "dp";
};

+   mipi_phy: video-phy at 10040714 {
+   compatible = "samsung,s5pv210-mipi-video-phy";
+   reg = <0x10040714 12>;
+   #phy-cells = <1>;
+   };
+
fimd at 1440 {
samsung,power-domain = <_pd>;
clocks = < 147>, < 421>;
-- 
1.7.9.5

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

[YoungJun Cho]

This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = "disabled";
};

+   sys_reg: syscon at 1005 {
+   compatible = "samsung,exynos5-sysreg", "syscon";
+   reg = <0x1005 0x500>;
+   };
+
fimd at 1440 {
compatible = "samsung,exynos5250-fimd";
interrupt-parent = <>;
reg = <0x1440 0x4>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <18 4>, <18 5>, <18 6>;
+   samsung,sysreg = <_reg>;
status = "disabled";
};

-- 
1.7.9.5

[RFC PATCH 11/14] ARM: dts: exynos4: add system register node

[YoungJun Cho]

This patch adds sysreg property to fimd device node which is required
to use I80 interface.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3d14cdb..a10aa50 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -528,6 +528,7 @@
clocks = < 140>, < 283>;
clock-names = "sclk_fimd", "fimd";
samsung,power-domain = <_lcd0>;
+   samsung,sysreg = <_reg>;
status = "disabled";
};
 };
-- 
1.7.9.5

[RFC PATCH 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c |  544 +
 3 files changed, 552 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E3FA0
+   tristate "S6E3FA0 DSI command mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c 
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..784a614
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,544 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+struct s6e3fa0 {
+   struct device   *dev;
+   struct drm_panelpanel;
+
+   struct regulator_bulk_data  supplies[2];
+   struct gpio_desc*reset_gpio;
+   struct gpio_desc*det_gpio;
+   struct gpio_desc*te_gpio;
+   unsigned intpower_on_delay;
+   unsigned intreset_delay;
+   unsigned intinit_delay;
+   struct videomodevm;
+   unsigned intwidth_mm;
+   unsigned intheight_mm;
+
+   unsigned char   id;
+   unsigned char   vddm;
+   unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+   {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+   {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+   {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+   {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+   {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+   {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+   {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+   {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+   {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+   {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+   {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+   {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+   {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+   {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+   {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+   {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+   {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+   {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+   {0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+   {0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+   {0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
+   {0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
+   {0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
+   {0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
+   {0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
+   {0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
+};
+
+static int 

[RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   52 
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..5986899
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,52 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+  - power-on-delay: delay after turning regulators on [ms]
+  - reset-delay: delay after reset sequence [ms]
+  - init-delay: delay after initialization sequence [ms]
+  - panel-width-mm: physical panel width [mm]
+  - panel-height-mm: physical panel height [mm]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel {
+   compatible = "samsung,s6e3fa0";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpio = < 4 0>;
+   power-on-delay= <10>;
+   reset-delay = <5>;
+   init-delay = <120>;
+   panel-width-mm = <71>;
+   panel-height-mm = <126>;
+
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <1080>;
+   vactive = <1920>;
+   hfront-porch = <2>;
+   hback-porch = <2>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <4>;
+   vsync-len = <1>;
+   };
+   };
+   };
-- 
1.7.9.5

[RFC PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

[YoungJun Cho]

The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.

In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  101 ---
 1 file changed, 80 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 

@@ -54,9 +55,12 @@

 /* FIFO memory AC characteristic register */
 #define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
 #define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register */
 #define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG   0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c

 /* DSIM_STATUS */
 #define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_INITIALIZED BIT(1)
 #define DSIM_STATE_CMD_LPM BIT(2)

+struct exynos_dsi_driver_data {
+   unsigned int plltmr_reg;
+
+   unsigned int has_freqband:1;
+};
+
 struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {

spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+   struct exynos_dsi_driver_data *driver_data;
 };

 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
 #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)

+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+   .plltmr_reg = 0x50,
+   .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+   .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+   { .compatible = "samsung,exynos4210-mipi-dsi",
+ .data = _dsi_driver_data },
+   { .compatible = "samsung,exynos5420-mipi-dsi",
+ .data = _dsi_driver_data },
+   { }
+};
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+   struct platform_device *pdev)
+{
+   const struct of_device_id *of_id =
+   of_match_device(exynos_dsi_of_match, >dev);
+
+   return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
 static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
 {
if (wait_for_completion_timeout(>completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct 
exynos_dsi *dsi,
 static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
 {
-   static const unsigned long freq_bands[] = {
-   100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-   270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-   510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-   770 * MHZ, 870 * MHZ, 950 * MHZ,
-   };
+   struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
unsigned long fin, fout;
-   int timeout, band;
+   int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi 
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+   dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);

-   for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
-   if (fout < freq_bands[band])
-   break;
+   writel(500, dsi->reg_base + driver_data->plltmr_reg);
+
+   reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+   if (driver_data->has_freqband) {
+   static const unsigned long freq_bands[] = {
+   100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+   270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+   510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
+   770 * MHZ, 870 * MHZ, 950 * MHZ,
+   };
+   int band;

-   dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n", fout,
-   p, m, s, band);
+   for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
+   if (fout < freq_bands[band])
+

[RFC PATCH 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible

[YoungJun Cho]

This patch adds exynos5420 SoC support.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/video/exynos_dsim.txt  |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 33b5730..9bbf82b 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -1,7 +1,9 @@
 Exynos MIPI DSI Master

 Required properties:
-  - compatible: "samsung,exynos4210-mipi-dsi"
+  - compatible: value should be one of the following
+   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
+   "samsung,exynos5420-mipi-dsi" /* for Exynos5420 Soc */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
1.7.9.5

[RFC PATCH 06/14] drm/exynos: support MIPI DSI command mode

[YoungJun Cho]

This patch adds I80 interface for FIMD to support command mode panel.

For this, the below features are added:
- Set display interface mode relevant registers properly according to the
  interface type from DT
- Add TE interrupt handler
  . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
- Add trigger feature
  . In case of command mode panel, FIMD should set trigger bit,
so that image data has to be transferred to display bus or lcd panel.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig   |1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 +-
 include/drm/drm_mipi_dsi.h   |2 +
 include/video/samsung_fimd.h |3 +-
 8 files changed, 270 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..f4d34f0 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
+   select MFD_SYSCON
help
  Choose this option if you want to use Exynos FIMD for DRM.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1419d11..d902d64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -491,3 +491,14 @@ void exynos_drm_crtc_complete_scanout(struct 
drm_framebuffer *fb)
manager->ops->wait_for_vblank(manager);
}
 }
+
+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
+{
+   struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
+   int ret = 0;
+
+   if (manager->ops->te_handler)
+   ret = manager->ops->te_handler(manager);
+
+   return ret;
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index c27b66c..8482df2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -32,4 +32,6 @@ void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int 
zpos);
 void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
 void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);

+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c5cf68..7cb0baf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -186,6 +186,7 @@ struct exynos_drm_display {
  * @win_commit: apply hardware specific overlay data to registers.
  * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
+ * @te_handler: call driver specific TE handler callback.
  */
 struct exynos_drm_manager;
 struct exynos_drm_manager_ops {
@@ -207,6 +208,7 @@ struct exynos_drm_manager_ops {
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+   int (*te_handler)(struct exynos_drm_manager *mgr);
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2cf1f0b..179f2fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -23,6 +23,7 @@
 #include 
 #include 

+#include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"

 /* returns true iff both arguments logically differs */
@@ -1032,10 +1033,22 @@ static ssize_t exynos_dsi_host_transfer(struct 
mipi_dsi_host *host,
return (ret < 0) ? ret : xfer.rx_done;
 }

+static int exynos_dsi_host_te_handler(struct mipi_dsi_host *host)
+{
+   struct exynos_dsi *dsi = host_to_dsi(host);
+   struct drm_encoder *encoder = dsi->encoder;
+
+   if (!(dsi->state & DSIM_STATE_ENABLED))
+   return -EPERM;
+
+   return exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
 static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.attach = exynos_dsi_host_attach,
.detach = exynos_dsi_host_detach,
.transfer = exynos_dsi_host_transfer,
+   .te_handler = exynos_dsi_host_te_handler,
 };

 static int exynos_dsi_poweron(struct exynos_dsi *dsi)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..a7a2018 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 

[RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

[YoungJun Cho]

In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt bindings.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/video/samsung-fimd.txt |9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..924c2e1 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,15 @@ 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 used to control the system registers
+- vidout-i80-ldi: boolean to support i80 interface instead of rgb one
+- cs-setup: clock cycles for the active period of address signal enable until
+   chip select is enable in i80 interface
+- wr-setup: clock cycles for the active period of CS signal enable until
+   write signal is enable in i80 interface
+- wr-act: clock cycles for the active period of CS enable in i80 interface
+- wr-hold: clock cycles for the active period of CS disable until write signal
+   is disable in i80 interface

 The device node can contain 'port' child nodes according to the bindings 
defined
 in [2]. The following are properties specific to those nodes:
-- 
1.7.9.5

[RFC PATCH 04/14] ARM: dts: add exynos5 compatible to sysreg

[YoungJun Cho]

This patch adds sysreg support for exynos5 SoCs.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../devicetree/bindings/arm/samsung/sysreg.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt 
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..fd71581 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
 Properties:
  - compatible : should contain "samsung,-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+   For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon";
  - reg : offset and length of the register set.

 Example:
-- 
1.7.9.5

[RFC PATCH 03/14] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e930d4f..1419d11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)

if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
-   wait_event(exynos_crtc->pending_flip_queue,
-   atomic_read(_crtc->pending_flip) == 0);
+   wait_event_timeout(exynos_crtc->pending_flip_queue,
+   !atomic_read(_crtc->pending_flip),
+   HZ/20);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}

-- 
1.7.9.5

[RFC PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

[YoungJun Cho]

Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)

 static int exynos_dsi_init(struct exynos_dsi *dsi)
 {
-   exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi->irq);
exynos_dsi_wait_for_reset(dsi);
+   exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);

return 0;
-- 
1.7.9.5

[RFC PATCH 01/14] drm/exynos: dsi: move the Eot packets configuration point

[YoungJun Cho]

This configuration could be used in MIPI DSI command mode also.

Signed-off-by: YoungJun Cho 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eb73e3b..956e5f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -472,8 +472,6 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)

if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
reg |= DSIM_MFLUSH_VS;
-   if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
-   reg |= DSIM_EOT_DISABLE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
reg |= DSIM_SYNC_INFORM;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -490,6 +488,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_HSA_MODE;
}

+   if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+   reg |= DSIM_EOT_DISABLE;
+
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
-- 
1.7.9.5

[RFC PATCH 00/14] drm/exynos: support MIPI DSI command mode display

[YoungJun Cho]

This patch series includes the following:
- FIMD I80 interface
- DSI command mode interface for Exynos5420
- S6E3FA0 command mode type panel driver
- Some bugs modification

The patch series is based on exynos-drm-next branch.

Thank you.
Best regards YJ

YoungJun Cho (14):
  drm/exynos: dsi: move the Eot packets configuration point
  drm/exynos: dsi: delay setting clocks after reset
  drm/exynos: use wait_event_timeout() for safety usage
  ARM: dts: add exynos5 compatible to sysreg
  ARM: dts: samsung-fimd: add I80 specific properties
  drm/exynos: support MIPI DSI command mode
  ARM: dts: exynos_dsim: add exynos5420 Soc compatible
  drm/exynos: dsi: add driver data to support Exynos5420
  ARM: dts: s6e3fa0: add DT bindings
  drm/panel: add S6E3FA0 driver
  ARM: dts: exynos4: add system register node
  ARM: dts: exynos5: add system register support
  ARM: dts: exynos5420: add mipi-phy node
  ARM: dts: exynos5420: add dsi node

 .../devicetree/bindings/arm/samsung/sysreg.txt |1 +
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   52 ++
 .../devicetree/bindings/video/exynos_dsim.txt  |4 +-
 .../devicetree/bindings/video/samsung-fimd.txt |9 +
 arch/arm/boot/dts/exynos4.dtsi |1 +
 arch/arm/boot/dts/exynos5.dtsi |6 +
 arch/arm/boot/dts/exynos5420.dtsi  |   20 +
 drivers/gpu/drm/exynos/Kconfig |1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   16 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  121 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  280 --
 drivers/gpu/drm/panel/Kconfig  |7 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c  |  544 
 include/drm/drm_mipi_dsi.h |2 +
 include/video/samsung_fimd.h   |3 +-
 18 files changed, 1001 insertions(+), 71 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

-- 
1.7.9.5

[Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

[Rahul Sharma]

-- Forwarded message --
From:  
Date: 15 April 2014 14:32
Subject: [Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal
error "Unexpected 64bit argument detected"
To: dri-devel at lists.freedesktop.org


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

Bug ID: 74121
   Summary: [3.15-rc1] Exynos: Sandbox report fatal error
"Unexpected 64bit argument detected"
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc1
  Hardware: Other
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: r.sh.open at gmail.com
Regression: No

Sandbox crashing with 3.15-rc1 stating below fatal error. This was working in
till 3.14 Stable.

---
[1925:1925:0101/000305:FATAL:sandbox_bpf.cc(202)] Unexpected 64bit argument
detected
[1860:1860:1231/160305:FATAL:gpu_process_transport_factory.cc(210)] Failed to
create UI context, but can't use software compositing with browser threaded
compositing. Aborting.
Handling SIGCHLD.
Successfully wrote to child pipe.
bootstrap_helper: ReserveBottomPages: NULL pointer guard page errno=22
---

[This is my first bug. Please let me know if things are not upto the mark.]

--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #216 from Kajzer  ---
(In reply to comment #215)
> (In reply to comment #214)
> > On my RV635 things are really great, still not a single crash, DPM working
> > without any issues.
> > Running 24/7 for weeks.
> > 
> 
> Try mesa 10.1 or 10.2
> I thought that is the whole point of using open drivers on Radeon - to use
> the superior 10.1+ drivers over Catalyst and feature-, performance, and
> powersaving- gutted Mesa 9.2

I did, had to go back to 9.2 though, there were some strange artifacts
(textures were sometimes bizarre) on few games and in xbmc , not on desktop.
However, dpm was still working fine and that's the point of this topic I think
:)
Performance and mesa features will come in time I guess.
Main thing for me is dpm, powersaving.
I mean, beside debian wheezy I can't even use catalyst, it's possible with a
painful downgrading of xorg but I don't like that.
With open drivers I can now use any distro without overheating.
Yeah, opengl sucks (mesa) at the moment but things might change soon.

-- 
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/20140415/4425fdd0/attachment.html>

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

[Sachin Kamat]

On 15 April 2014 11:17, YoungJun Cho  wrote:
> This patch adds sysreg device node, and sysreg property to fimd device node
> which is required to use I80 interface.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos5.dtsi |6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index 258dca4..f938bbb 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,12 +88,18 @@
> status = "disabled";
> };
>
> +   sys_reg: syscon at 1005 {
> +   compatible = "samsung,exynos5-sysreg", "syscon";

Do we really need a separate string for this? Can't we use
"samsung,exynos4-sysreg" itself?

-- 
With warm regards,
Sachin

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

[Daniel Vetter]

On Tue, Apr 15, 2014 at 12:22 PM, Ville Syrj?l?
 wrote:
> Although I'm not sure EINVAL is the best choice here. Maybe ENOSYS?

We return -EINVAL everywhere else where we don't support a giving
config, e.g. lack of dpll, unsupported plane scaling, pixel format
mismatch of the primary plane (since we don't yet have per-gen lists
of supported formats for the primary plane) and so on. So I've figured
-EINVAL is good enough until we have something better with the test
mode for atomic modesets.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

15-rc1: radeon modesetting fails

[Borislav Petkov]

Hi Christian,

On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
> Hi Borislav,
> 
> that's a known issue and should be fixed in the next rc, see this
> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
> 
> You might also want to try my branch with 3.15 fixes which includes
> the necessary patch for this: 
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
> 
> Let me know if that branch works for you or not.

so I went and merged your branch as you suggested. Btw, on its tip it
has:

commit ec02666dd0791312b5820e1a9a023681d99d07ec
Author: Quentin Casasnovas 
Date:   Tue Mar 18 17:16:52 2014 +0100

drm/radeon: memory leak on bo reservation failure. v2

(just checking whether I got the right one)

and, unfortunately, no change - same problem. Let me know if I should
bisect the subset of 59 radeon patches which went in during the merge
window...

Btw, just in case, I went and updated radeon firmware in
/lib/firmware/radeon/ from upstream but it didn't change anything.

Thanks.

[RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings

[Sachin Kamat]

On 15 April 2014 11:17, YoungJun Cho  wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings, delays
> and physical size.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   52 
> 
>  1 file changed, 52 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> new file mode 100644
> index 000..5986899
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,52 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - display-timings: timings for the connected panel as described by [1]
> +
> +Optional properties:
> +  - power-on-delay: delay after turning regulators on [ms]
> +  - reset-delay: delay after reset sequence [ms]
> +  - init-delay: delay after initialization sequence [ms]
> +  - panel-width-mm: physical panel width [mm]
> +  - panel-height-mm: physical panel height [mm]
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +   panel {

How about panel at 0?

> +   compatible = "samsung,s6e3fa0";
> +   reg = <0>;




-- 
With warm regards,
Sachin

Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

On 15/04/14 13:29, Andrzej Hajda wrote:

> I have experienced similar problem with exynos_drm. I have found that
> in exynos_drm_crtc_mode_set there is line:
> 
>   plane->fb = crtc->primary->fb;
> 
> without drm_framebuffer_reference.
> In result drm_framebuffer_remove dereferences it twice:
> - because of crtc->primary->fb == fb,
> - because of fb being on dev->mode_config.plane_list
> 
> I am not sure how it should be solved properly, but adding
> drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.
> 
> In omap_plane_mode_set there is also assignment:
> 
>   plane->fb = fb
> 
> without drm_framebuffer_reference so maybe it can be solved the same way.

The omap_plane_mode_set() is called also when using non-primary planes.
For those the refcounting goes right at the moment (I think), so adding
drm_framebuffer_reference() at that func would break it.

I guess I could check if the plane is primary, and add ref only then. Or
add the ref in omap_crtc, before it calls omap_plane_mode_set(). Both
feel a bit hacky...

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/8d4e301b/attachment-0001.sig>

[RFC PATCH 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible

[Sachin Kamat]

On 15 April 2014 11:17, YoungJun Cho  wrote:
> This patch adds exynos5420 SoC support.

This patch just updates binding documentation :)

> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/video/exynos_dsim.txt  |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
> b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> index 33b5730..9bbf82b 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> @@ -1,7 +1,9 @@
>  Exynos MIPI DSI Master
>
>  Required properties:
> -  - compatible: "samsung,exynos4210-mipi-dsi"
> +  - compatible: value should be one of the following
> +   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
> +   "samsung,exynos5420-mipi-dsi" /* for Exynos5420 Soc */
s/Soc/SoC



-- 
With warm regards,
Sachin

[RFC PATCH 14/14] ARM: dts: exynos5420: add dsi node

[Sachin Kamat]

Hi YoungJun,

On 15 April 2014 11:17, YoungJun Cho  wrote:
> This patch adds common part of dsi node.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |   14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index f0184c7..aa2350a 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -422,6 +422,20 @@
> #phy-cells = <1>;
> };
>
> +   dsi at 1450 {
> +   compatible = "samsung,exynos5420-mipi-dsi";
> +   reg = <0x1450 0x1>;
> +   interrupts = <0 82 0>;
> +   samsung,power-domain = <_pd>;
> +   phys = <_phy 1>;
> +   phy-names = "dsim";
> +   clocks = < 411>, < 146>;

Please use macros instead of numbers.

> +   clock-names = "bus_clk", "pll_clk";
> +   status = "disabled";

nit: Move this to the end for readability.

-- 
With warm regards,
Sachin

[RFC PATCH 04/14] ARM: dts: add exynos5 compatible to sysreg

[Sachin Kamat]

Hi YoungJun,

On 15 April 2014 11:17, YoungJun Cho  wrote:
> This patch adds sysreg support for exynos5 SoCs.

The patch title and commit description seem a bit off here. This patch does
not add support per se. It only updates the binding documentaion.

-- 
With warm regards,
Sachin

[Bug 73901] Kernel crash after modprobe radeon runpm=1

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to Pali Roh?r from comment #13)
> (In reply to Alex Deucher from comment #11)
> > Created attachment 132311 [details]
> > avoid a possible crash when runpm is forced on non-ATPX systems
> > 
> > Fix runpm=1 handling on non-PX systems.
> 
> It is not possible to apply this patch on top of 3.14 nor on top of linus
> master (55101e2d6ce1c780f6ee8fee5f37306971aac6cd)
> 
> linux/drivers/gpu/drm/radeon$ patch -p5 -i
> 0002-drm-radeon-don-t-allow-runpm-1-on-systems-with-out-A.patch
> patching file radeon_kms.c
> Hunk #1 FAILED at 107.
> 1 out of 1 hunk FAILED -- saving rejects to file radeon_kms.c.rej

It relies on other patches in the radeon -fixes tree.  It should apply against:
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip

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

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

[Ville Syrjälä]

On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote:
> After thinking about this topic a bit more I've reached the conclusion
> that implementing this doesn't make sense:
> 
> - The locking is all wrong: set_config(NULL) will also unlink encoders
>   and connectors, but those links are protected with the mode_config
>   mutex. In the ->disable_plane callback we only hold all modeset
>   locks, but eventually we want to switch to just grabbing the
>   per-crtc (and maybe per-plane) locks as needed, maybe based on
>   ww_mutexes. Having a callback which absolutely needs all modeset
>   locks is bad for this conversion.
> 
>   Note that the same isn't true for the provided ->update_plane since
>   we've audited the crtc helpers to make sure that not encoder or
>   connector links are changed.
> 
> - There's no way to re-enable the plane with an ->update_plane: The
>   connectors/encoder links are lost and so we can't re-enable the
>   CRTC. Even without that issue the driver might have reassigned some
>   shared resources (as opposed to e.g. DPMS off, where drivers are not
>   allowed to do that to make sure the CRTC can be enabled again).
> 
> - The semantics don't make much sense: Userspace asked to scan out
>   black (or some other color if the driver supports a background
>   color), not that the screen be disabled.
> 
> - Implementing proper primary plane support (i.e. actually disabling
>   the primary plane without disabling the CRTC) is really simple, at
>   least if all the hw needs is flipping a bit. The big task is
>   auditing all the interactions with other ioctls when the CRTC is on
>   but there's no primary plane (e.g. pageflips). And some of that work
>   still needs to be done.
> 
> Cc: Matt Roper 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrj?l? 

Although I'm not sure EINVAL is the best choice here. Maybe ENOSYS?

> ---
>  drivers/gpu/drm/drm_plane_helper.c | 33 +
>  1 file changed, 5 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 9263fd5efa58..9540ff9f97fe 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -205,9 +205,9 @@ EXPORT_SYMBOL(drm_primary_helper_update);
>   *
>   * Provides a default plane disable handler for primary planes.  This is 
> handler
>   * is called in response to a userspace SetPlane operation on the plane with 
> a
> - * NULL framebuffer parameter.  We call the driver's modeset handler with a 
> NULL
> - * framebuffer to disable the CRTC if no other planes are currently enabled.
> - * If other planes are still enabled on the same CRTC, we return -EBUSY.
> + * NULL framebuffer parameter.  It unconditionally fails the disable call 
> with
> + * -EINVAL the only way to disable the primary plane without driver support 
> is
> + * to disable the entier CRTC. Which does not match the plane ->disable hook.
>   *
>   * Note that some hardware may be able to disable the primary plane without
>   * disabling the whole CRTC.  Drivers for such hardware should provide their
> @@ -216,34 +216,11 @@ EXPORT_SYMBOL(drm_primary_helper_update);
>   * disabled primary plane).
>   *
>   * RETURNS:
> - * Zero on success, error code on failure
> + * Unconditionally returns -EINVAL.
>   */
>  int drm_primary_helper_disable(struct drm_plane *plane)
>  {
> - struct drm_plane *p;
> - struct drm_mode_set set = {
> - .crtc = plane->crtc,
> - .fb = NULL,
> - };
> -
> - if (plane->crtc == NULL || plane->fb == NULL)
> - /* Already disabled */
> - return 0;
> -
> - list_for_each_entry(p, >dev->mode_config.plane_list, head)
> - if (p != plane && p->fb) {
> - DRM_DEBUG_KMS("Cannot disable primary plane while other 
> planes are still active on CRTC.\n");
> - return -EBUSY;
> - }
> -
> - /*
> -  * N.B.  We call set_config() directly here rather than
> -  * drm_mode_set_config_internal() since drm_mode_setplane() already
> -  * handles the basic refcounting and we don't need the special
> -  * cross-CRTC refcounting (no chance of stealing connectors from
> -  * other CRTC's with this update).
> -  */
> - return plane->crtc->funcs->set_config();
> + return -EINVAL;
>  }
>  EXPORT_SYMBOL(drm_primary_helper_disable);
>  
> -- 
> 1.9.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

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

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

--- Comment #5 from Alex Deucher  ---
It might be easier to just test Christian's fixes branch here:
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip

Does disabling dpm help?  Append radeon.dpm=0 to the kernel command line in
grub.  If that helps, the patches I mentioned may 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/20140415/fadbf0ac/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #215 from lockheed  ---
(In reply to comment #214)
> On my RV635 things are really great, still not a single crash, DPM working
> without any issues.
> Running 24/7 for weeks.
> 

Try mesa 10.1 or 10.2
I thought that is the whole point of using open drivers on Radeon - to use the
superior 10.1+ drivers over Catalyst and feature-, performance, and
powersaving- gutted Mesa 9.2

-- 
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/20140415/86c192b7/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #214 from Kajzer  ---
On my RV635 things are really great, still not a single crash, DPM working
without any issues.
Running 24/7 for weeks.

However, still seeing dark screen on boot sometimes, eventually it's going to
boot and then it's golden.
Not a big issue though would love to see that fixed finally,

-- 
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/20140415/d158351e/attachment.html>

[PATCH 4/4] drm/radeon: don't allow runpm=1 on systems with out ATPX

[Alex Deucher]

vgaswitcheroo and the ATPX ACPI methods are required to
power down the dGPU.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_kms.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 9337820..f4a9c5d 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -107,11 +107,9 @@ int radeon_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
flags |= RADEON_IS_PCI;
}

-   if (radeon_runtime_pm == 1)
-   flags |= RADEON_IS_PX;
-   else if ((radeon_runtime_pm == -1) &&
-radeon_has_atpx() &&
-((flags & RADEON_IS_IGP) == 0))
+   if ((radeon_runtime_pm != 0) &&
+   radeon_has_atpx() &&
+   ((flags & RADEON_IS_IGP) == 0))
flags |= RADEON_IS_PX;

/* radeon_device_init should report only fatal error
-- 
1.8.3.1

[PATCH 3/4] drm/radeon: fix ATPX detection on non-VGA GPUs

[Alex Deucher]

Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA.  This
properly detects ATPX on those laptops.

Based on a patch from: Pali Roh?r 

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
Cc: airlied at gmail.com
---
 drivers/gpu/drm/radeon/radeon_atpx_handler.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index dedea72..a9fb0d0 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -528,6 +528,13 @@ static bool radeon_atpx_detect(void)
has_atpx |= (radeon_atpx_pci_probe_handle(pdev) == true);
}

+   /* some newer PX laptops mark the dGPU as a non-VGA display device */
+   while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_OTHER << 8, pdev)) != 
NULL) {
+   vga_count++;
+
+   has_atpx |= (radeon_atpx_pci_probe_handle(pdev) == true);
+   }
+
if (has_atpx && vga_count == 2) {
acpi_get_name(radeon_atpx_priv.atpx.handle, ACPI_FULL_PATHNAME, 
);
printk(KERN_INFO "VGA switcheroo: detected switching method %s 
handle\n",
-- 
1.8.3.1

[PATCH 2/4] drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)

[Alex Deucher]

Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.

v2: fix the vblank and vrefresh helpers as well

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/r600_dpm.c  | 35 +++
 drivers/gpu/drm/radeon/radeon_pm.c | 28 
 2 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_dpm.c 
b/drivers/gpu/drm/radeon/r600_dpm.c
index cbf7e32..9c61b74 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -158,16 +158,18 @@ u32 r600_dpm_get_vblank_time(struct radeon_device *rdev)
u32 line_time_us, vblank_lines;
u32 vblank_time_us = 0x; /* if the displays are off, vblank 
time is max */

-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   radeon_crtc = to_radeon_crtc(crtc);
-   if (crtc->enabled && radeon_crtc->enabled && 
radeon_crtc->hw_mode.clock) {
-   line_time_us = (radeon_crtc->hw_mode.crtc_htotal * 
1000) /
-   radeon_crtc->hw_mode.clock;
-   vblank_lines = radeon_crtc->hw_mode.crtc_vblank_end -
-   radeon_crtc->hw_mode.crtc_vdisplay +
-   (radeon_crtc->v_border * 2);
-   vblank_time_us = vblank_lines * line_time_us;
-   break;
+   if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   radeon_crtc = to_radeon_crtc(crtc);
+   if (crtc->enabled && radeon_crtc->enabled && 
radeon_crtc->hw_mode.clock) {
+   line_time_us = 
(radeon_crtc->hw_mode.crtc_htotal * 1000) /
+   radeon_crtc->hw_mode.clock;
+   vblank_lines = 
radeon_crtc->hw_mode.crtc_vblank_end -
+   radeon_crtc->hw_mode.crtc_vdisplay +
+   (radeon_crtc->v_border * 2);
+   vblank_time_us = vblank_lines * line_time_us;
+   break;
+   }
}
}

@@ -181,14 +183,15 @@ u32 r600_dpm_get_vrefresh(struct radeon_device *rdev)
struct radeon_crtc *radeon_crtc;
u32 vrefresh = 0;

-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   radeon_crtc = to_radeon_crtc(crtc);
-   if (crtc->enabled && radeon_crtc->enabled && 
radeon_crtc->hw_mode.clock) {
-   vrefresh = radeon_crtc->hw_mode.vrefresh;
-   break;
+   if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   radeon_crtc = to_radeon_crtc(crtc);
+   if (crtc->enabled && radeon_crtc->enabled && 
radeon_crtc->hw_mode.clock) {
+   vrefresh = radeon_crtc->hw_mode.vrefresh;
+   break;
+   }
}
}
-
return vrefresh;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index e0a664d..4fc1ec9 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1406,12 +1406,14 @@ static void radeon_pm_compute_clocks_old(struct 
radeon_device *rdev)

rdev->pm.active_crtcs = 0;
rdev->pm.active_crtc_count = 0;
-   list_for_each_entry(crtc,
-   >mode_config.crtc_list, head) {
-   radeon_crtc = to_radeon_crtc(crtc);
-   if (radeon_crtc->enabled) {
-   rdev->pm.active_crtcs |= (1 << radeon_crtc->crtc_id);
-   rdev->pm.active_crtc_count++;
+   if (rdev->num_crtc && rdev->mode_info.mode_config_initialized) {
+   list_for_each_entry(crtc,
+   >mode_config.crtc_list, head) {
+   radeon_crtc = to_radeon_crtc(crtc);
+   if (radeon_crtc->enabled) {
+   rdev->pm.active_crtcs |= (1 << 
radeon_crtc->crtc_id);
+   rdev->pm.active_crtc_count++;
+   }
}
}

@@ -1478,12 +1480,14 @@ static void radeon_pm_compute_clocks_dpm(struct 
radeon_device *rdev)
/* update active crtc counts */
rdev->pm.dpm.new_active_crtcs = 0;
rdev->pm.dpm.new_active_crtc_count = 0;
-   list_for_each_entry(crtc,
-   >mode_config.crtc_list, head) {
-   radeon_crtc = to_radeon_crtc(crtc);
-   if (crtc->enabled) {
-   

[PATCH 1/4] drm/radeon: properly unregister hwmon interface (v2)

[Alex Deucher]

Need to properly unregister the hwmon device on driver
unload.

v2: minor clean up

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_pm.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index ee738a5..e0a664d 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -603,7 +603,6 @@ static const struct attribute_group *hwmon_groups[] = {
 static int radeon_hwmon_init(struct radeon_device *rdev)
 {
int err = 0;
-   struct device *hwmon_dev;

switch (rdev->pm.int_thermal_type) {
case THERMAL_TYPE_RV6XX:
@@ -616,11 +615,11 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_KV:
if (rdev->asic->pm.get_temperature == NULL)
return err;
-   hwmon_dev = hwmon_device_register_with_groups(rdev->dev,
- "radeon", rdev,
- hwmon_groups);
-   if (IS_ERR(hwmon_dev)) {
-   err = PTR_ERR(hwmon_dev);
+   rdev->pm.int_hwmon_dev = 
hwmon_device_register_with_groups(rdev->dev,
+  
"radeon", rdev,
+  
hwmon_groups);
+   if (IS_ERR(rdev->pm.int_hwmon_dev)) {
+   err = PTR_ERR(rdev->pm.int_hwmon_dev);
dev_err(rdev->dev,
"Unable to register hwmon device: %d\n", err);
}
@@ -632,6 +631,12 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
return err;
 }

+static void radeon_hwmon_fini(struct radeon_device *rdev)
+{
+   if (rdev->pm.int_hwmon_dev)
+   hwmon_device_unregister(rdev->pm.int_hwmon_dev);
+}
+
 static void radeon_dpm_thermal_work_handler(struct work_struct *work)
 {
struct radeon_device *rdev =
@@ -1353,6 +1358,8 @@ static void radeon_pm_fini_old(struct radeon_device *rdev)
device_remove_file(rdev->dev, _attr_power_method);
}

+   radeon_hwmon_fini(rdev);
+
if (rdev->pm.power_state)
kfree(rdev->pm.power_state);
 }
@@ -1372,6 +1379,8 @@ static void radeon_pm_fini_dpm(struct radeon_device *rdev)
}
radeon_dpm_fini(rdev);

+   radeon_hwmon_fini(rdev);
+
if (rdev->pm.power_state)
kfree(rdev->pm.power_state);
 }
-- 
1.8.3.1

[PATCH 0/6] drm/omap: Misc fixes

[Tomi Valkeinen]

Hi,

On 11/04/14 10:23, Archit Taneja wrote:
> These are based over Tomi's 3.15/omapdrm-fixes branch.
> 
> Archit Taneja (5):
>   drm/omap: gem sync: wait on correct events
>   drm/omap: Fix crash when using LCD3 overlay manager
>   drm/omap: Allow allocation of larger buffers
>   drm/omap: Use old_fb to synchronize between successive page flips
>   drm/omap: protect omap_crtc's event with event_lock spinlock
> 
> Subhajit Paul (1):
>   drm/omap: Fix memory leak in omap_gem_op_async

I've added all of these except "Allow allocation of larger buffers" to
my omapdrm-fixes branch. I needed to do some small changes for the last
two, but quite minor.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/2e6edd55/attachment-0001.sig>

Possible fb ref count issue with drm_plane_force_disable()

[Andrzej Hajda]

On 04/15/2014 12:10 PM, Rob Clark wrote:
> On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen  
> wrote:
>> On 14/04/14 11:43, Tomi Valkeinen wrote:
>>> On 11/04/14 14:50, Ville Syrj?l? wrote:
>>>
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
>
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?

 That's the reference that was taken by the drm_mode_setplane() when it
 succesfully called the .update_plane() hook.
>>>
>>> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
>>> only used for "proper" planes, not for crtc primary planes, right?
>>>
>>> At least I don't see drm_mode_setplane() in my stack traces, and git
>>> grep doesn't show it called via any other means than ioctl.
>>>
>>> I am not using any planes from my app, just the crtc and (indirectly)
>>> its primary plane.
>>
>> So here's a summary of the fb refs and unrefs. It still seems to me that the
>> drm_plane_force_disable does an extra unref. Either that, or omapdrm is 
>> missing
>> something that takes the matching reference.
>>
>> A line like this in the summary below:
>>
>> 2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup
>>
>> Means that "2" is the number I assigned to that ref, and there's a matching
>> unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and 
>> ref
>> count is 3. And the rest of the line shows rough idea of the stack trace 
>> where
>> the ref/unref happens.
>>
>>
>> # DRM_IOCTL_MODE_ADDFB 2
>> 0)  kref_init
>> 1) ref36/2  drm_mode_addfb2
>>
>> # DRM_IOCTL_MODE_SETCRTC
>> 2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup
>> 3) ref36/4  drm_mode_setcrtc / drm_mode_set_config_internal
>> 2) unref36/3drm_mode_setcrtc
>>
>> # pin new fb
>> 4) ref36/4  apply_worker / omap_plane_pre_apply
>>
>>
>> # BREAK
>>
>>
>> # RELEASE
>> 1) unref36/3drm_release / drm_fb_release / __drm_framebuffer_unregister
>> 3) unref36/2drm_release / drm_fb_release / drm_framebuffer_remove / 
>> drm_mode_set_config_internal
>> ?) unref36/1drm_release / drm_fb_release / drm_framebuffer_remove / 
>> drm_plane_force_disable
>> 0) unref36/0drm_release / drm_fb_release / drm_framebuffer_remove
>>
>> # unpin old fb
>> 4) unref36/-1   flip_worker / unpin_worker / drm_framebuffer_unreference
>>
> 
> Ok, sorry to take so long to comment on the thread, it took me a while
> before I had an idea ;-)
> 
> so, what triggers this is that previously drm_framebuffer_remove() did
> not process private planes.  But now the fb shows up attached to a
> plane as well, the crtc's primary plane.
> 
> I suspect there is some way in omap_crtc that I must have assumed the
> ref the crtc held to the fb was sufficient for the plane to hold the
> same ref.  Which is no longer the case.  So somewhere between
> omap_crtc and it's primary plane, there now needs to be an extra level
> of ref/unref.  So ref should have gone up to 5.

I have experienced similar problem with exynos_drm. I have found that
in exynos_drm_crtc_mode_set there is line:

plane->fb = crtc->primary->fb;

without drm_framebuffer_reference.
In result drm_framebuffer_remove dereferences it twice:
- because of crtc->primary->fb == fb,
- because of fb being on dev->mode_config.plane_list

I am not sure how it should be solved properly, but adding
drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.

In omap_plane_mode_set there is also assignment:

plane->fb = fb

without drm_framebuffer_reference so maybe it can be solved the same way.

Regards
Andrzej

> 
> BR,
> -R
> 
> 
>>
>> All the other unrefs I can explain, except the drm_plane_force_disable() one.
>>
>>  Tomi
>>
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

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

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

--- Comment #22 from Ilya Tumaykin  ---
Reproducible with 3.14.0 kernel.

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

Possible fb ref count issue with drm_plane_force_disable()

[Tomi Valkeinen]

On 14/04/14 11:43, Tomi Valkeinen wrote:
> On 11/04/14 14:50, Ville Syrj?l? wrote:
> 
>>> So the explicit unref done by drm_plane_force_disable() seems a bit out
>>> of place. I can't figure out which drm_framebuffer_reference() would be
>>> the matching one for the unref done by drm_plane_force_disable().
>>>
>>> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
>>> extra in drm_plane_force_disable()?
>>
>> That's the reference that was taken by the drm_mode_setplane() when it
>> succesfully called the .update_plane() hook.
> 
> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
> only used for "proper" planes, not for crtc primary planes, right?
> 
> At least I don't see drm_mode_setplane() in my stack traces, and git
> grep doesn't show it called via any other means than ioctl.
> 
> I am not using any planes from my app, just the crtc and (indirectly)
> its primary plane.

So here's a summary of the fb refs and unrefs. It still seems to me that the
drm_plane_force_disable does an extra unref. Either that, or omapdrm is missing
something that takes the matching reference.

A line like this in the summary below:

2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup

Means that "2" is the number I assigned to that ref, and there's a matching
unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and ref
count is 3. And the rest of the line shows rough idea of the stack trace where
the ref/unref happens.


# DRM_IOCTL_MODE_ADDFB 2
0)  kref_init
1) ref36/2  drm_mode_addfb2

# DRM_IOCTL_MODE_SETCRTC
2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup
3) ref36/4  drm_mode_setcrtc / drm_mode_set_config_internal
2) unref36/3drm_mode_setcrtc

# pin new fb
4) ref36/4  apply_worker / omap_plane_pre_apply


# BREAK


# RELEASE
1) unref36/3drm_release / drm_fb_release / __drm_framebuffer_unregister
3) unref36/2drm_release / drm_fb_release / drm_framebuffer_remove / 
drm_mode_set_config_internal
?) unref36/1drm_release / drm_fb_release / drm_framebuffer_remove / 
drm_plane_force_disable
0) unref36/0drm_release / drm_fb_release / drm_framebuffer_remove

# unpin old fb
4) unref36/-1   flip_worker / unpin_worker / drm_framebuffer_unreference


All the other unrefs I can explain, except the drm_plane_force_disable() one.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140415/1db17cda/attachment-0001.sig>

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Lucas Stach]

Am Dienstag, den 15.04.2014, 11:27 +0200 schrieb Tomasz Stanislawski:
> Adds support for limitation of maximal pixel clock of HDMI
> signal. This feature is needed on boards that contains
> lines or bridges with frequency limitations.
> 
> Signed-off-by: Tomasz Stanislawski 
> ---
>  .../devicetree/bindings/video/exynos_hdmi.txt  |4 
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
>  include/media/s5p_hdmi.h   |1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index f9187a2..8718f8d 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -28,6 +28,10 @@ Required properties:
>  - ddc: phandle to the hdmi ddc node
>  - phy: phandle to the hdmi phy node
>  
> +Optional properties:
> +- max-pixel-clock: used to limit the maximal pixel clock if a board has 
> lines,
> + connectors or bridges not capable of carring higher frequencies
> +
>  Example:
>  
>   hdmi {
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2a18f4e..404f1b7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -195,6 +195,7 @@ struct hdmi_context {
>   struct hdmi_resources   res;
>  
>   int hpd_gpio;
> + u32 max_pixel_clock;
>  
>   enum hdmi_type  type;
>  };
> @@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector 
> *connector,
>   if (ret)
>   return MODE_BAD;
>  
> + if (mode->clock * 1000 > hdata->max_pixel_clock)
> + return MODE_BAD;
> +
This should be MODE_CLOCK_HIGH

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

15-rc1: radeon modesetting fails

[Christian König]

Hi Borislav,

that's a known issue and should be fixed in the next rc, see this 
bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009

You might also want to try my branch with 3.15 fixes which includes the 
necessary patch for this: 
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip

Let me know if that branch works for you or not.

Regards,
Christian.

Am 15.04.2014 09:02, schrieb Borislav Petkov:
> Hi guys,
>
> so I'm booting 15-rc1 + tip/master and around the time modesetting gets
> initialized, the screen blanks and on it appears a message from the
> monitors:
>
> "The current input timing is not supported by the monitor display.
> Please change your input timing to 1920x1200 at 60Hz or any other monitor
> listed timing as per the monitor specifications."
>
> The box is still responsive, I can reboot it with Ctrl-Alt-Del but
> screens are blank.
>
> If I boot with radeon.modeset=0, I see the normal nomodeset big letters
> on the console and not very optimal screen resolution.
>
> Diffing drm init chatter from dmesg shows only this:
>
> --- /tmp/working2014-04-15 08:40:21.979985352 +0200
> +++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
> @@ -44,4 +44,5 @@
>   [drm]pitch is 7680
>   fbcon: radeondrmfb (fb0) is primary device
>   radeon :01:00.0: fb0: radeondrmfb frame buffer device
> -[drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0
> +[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
> +
>
> Below is the whole thing, btw.
>
> Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
> bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
>
> git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
> 59
>
> Thanks.
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
> [drm] register mmio base: 0xFEA2
> [drm] register mmio size: 65536
> [drm] Detected VRAM RAM=512M, BAR=256M
> [drm] RAM width 128bits DDR
> [drm] radeon: 512M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Loading RV635 Microcode
> [drm] Internal thermal controller without fan control
> [drm] radeon: power management initialized
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
> [drm] PCIE GART of 512M enabled (table at 0x0004).
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] ring test on 0 succeeded in 0 usecs
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   DVI-I-1
> [drm]   HPD1
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY
> [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [drm] Connector 1:
> [drm]   DIN-1
> [drm]   Encoders:
> [drm] TV1: INTERNAL_KLDSCP_DAC2
> [drm] Connector 2:
> [drm]   DVI-I-2
> [drm]   HPD2
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
> [drm] fb mappable at 0xC0141000
> [drm] vram apper at 0xC000
> [drm] size 9216000
> [drm] fb depth is 24
> [drm]pitch is 7680
> fbcon: radeondrmfb (fb0) is primary device
> radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
>

[PATCH] drm/radeon: memory leak on bo reservation failure. v2

[Christian König]

From: Quentin Casasnovas 

On bo reservation failure, we end up leaking fpriv.

v2 (chk): rebased and added missing free on vm failure as well

Fixes: 5e386b574cf7e1 ("drm/radeon: fix missing bo reservation")
Cc: stable at vger.kernel.org
Cc: Christian K?nig 
Cc: Alex Deucher 
Signed-off-by: Quentin Casasnovas 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_kms.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 9337820..fb3d13f 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -574,12 +574,17 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
}

r = radeon_vm_init(rdev, >vm);
-   if (r)
+   if (r) {
+   kfree(fpriv);
return r;
+   }

r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
-   if (r)
+   if (r) {
+   radeon_vm_fini(rdev, >vm);
+   kfree(fpriv);
return r;
+   }

/* map the ib pool buffer read only into
 * virtual address space */
-- 
1.9.1

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

[Tomasz Stanislawski]

Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.

Signed-off-by: Tomasz Stanislawski 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |4 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
 include/media/s5p_hdmi.h   |1 +
 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node

+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+   connectors or bridges not capable of carring higher frequencies
+
 Example:

hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources   res;

int hpd_gpio;
+   u32 max_pixel_clock;

enum hdmi_type  type;
 };
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;

+   if (mode->clock * 1000 > hdata->max_pixel_clock)
+   return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
if (ret < 0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
return NULL;
}

+   of_property_read_u32(np, "max-pixel-clock", >max_pixel_clock);
+
return pd;
 }

@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;

+   if (!pdata->max_pixel_clock) {
+   DRM_INFO("max-pixel-clock is zero, using INF\n");
+   pdata->max_pixel_clock = U32_MAX;
+   }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata->type = drv_data->type;

hdata->hpd_gpio = pdata->hpd_gpio;
+   hdata->max_pixel_clock = pdata->max_pixel_clock;
hdata->dev = dev;

ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+   u32 max_pixel_clock;
 };

 #endif /* S5P_HDMI_H */
-- 
1.7.9.5

[PATCHv2 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

[Tomasz Stanislawski]

This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |7 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 47c6e85..2a18f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -204,6 +204,10 @@ struct hdmiphy_config {
u8 conf[32];
 };

+struct hdmi_driver_data exynos4210_hdmi_driver_data = {
+   .type   = HDMI_TYPE13,
+};
+
 struct hdmi_driver_data exynos4212_hdmi_driver_data = {
.type   = HDMI_TYPE14,
 };
@@ -2032,6 +2036,9 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata

 static struct of_device_id hdmi_match_types[] = {
{
+   .compatible = "samsung,exynos4210-hdmi",
+   .data = _hdmi_driver_data,
+   }, {
.compatible = "samsung,exynos5-hdmi",
.data = _hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {

 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = "samsung,exynos4210-mixer",
+   .data   = _mxr_drv_data,
+   }, {
.compatible = "samsung,exynos5-mixer",
.data   = _mxr_drv_data,
}, {
-- 
1.7.9.5

[PATCHv2 2/4] drm: exynos: mixer: fix using usleep() in atomic context

[Tomasz Stanislawski]

This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ce28881..e3306c8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx)
/* waiting until VP_SRESET_PROCESSING is 0 */
if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
break;
-   usleep_range(1, 12000);
+   mdelay(10);
}
WARN(tries == 0, "failed to reset Video Processor\n");
 }
-- 
1.7.9.5

[PATCHv2 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

[Tomasz Stanislawski]

This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..47c6e85 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 {
struct device_node *np = dev->of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;

pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;

-   if (!of_find_property(np, "hpd-gpio", )) {
+   pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
+   if (!gpio_is_valid(pd->hpd_gpio)) {
DRM_ERROR("no hpd gpio property found\n");
-   goto err_data;
+   return NULL;
}

-   pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
-
return pd;
-
-err_data:
-   return NULL;
 }

 static struct of_device_id hdmi_match_types[] = {
-- 
1.7.9.5

[PATCHv2 0/4] drm: exynos: update/fixes to HDMI driver

[Tomasz Stanislawski]

Hi everyone,
This patchset adds 4 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.

All comments are welcome.

Regards,
Tomasz Stanislawski

Changelog:

v2:
* fix check with gpio_is_valid()
* use U32_MAX instead of ULONG_MAX to be 64-bit-friendly
* use hdmi_driver_data as hdmi's compatile data

v1:
* initial version

Tomasz Stanislawski (4):
  drm: exynos: hdmi: simplify extracting hpd-gpio from DT
  drm: exynos: mixer: fix using usleep() in atomic context
  drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210
SoC
  drm: exynos: hdmi: add support for pixel clock limitation

 .../devicetree/bindings/video/exynos_hdmi.txt  |4 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   30 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |5 +++-
 include/media/s5p_hdmi.h   |1 +
 4 files changed, 31 insertions(+), 9 deletions(-)

-- 
1.7.9.5

linux-next: manual merge of the drm-intel tree with the tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem_context.c between commit 691e6415c891
("drm/i915: Always use kref tracking for all contexts") from the
drm-intel-fixes tree and commit ad2ac08bf34b ("drm/i915: Make contexts
non-snooped on non-LLC platforms") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem_context.c
index d72db15afa02,30b355afb362..
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@@ -231,32 -232,40 +231,40 @@@ __create_hw_context(struct drm_device *
return ERR_PTR(-ENOMEM);

kref_init(>ref);
 -  ctx->obj = i915_gem_alloc_object(dev, dev_priv->hw_context_size);
 -  INIT_LIST_HEAD(>link);
 -  if (ctx->obj == NULL) {
 -  kfree(ctx);
 -  DRM_DEBUG_DRIVER("Context object allocated failed\n");
 -  return ERR_PTR(-ENOMEM);
 -  }
 +  list_add_tail(>link, _priv->context_list);

 -  /*
 -   * Try to make the context utilize L3 as well as LLC.
 -   *
 -   * On VLV we don't have L3 controls in the PTEs so we
 -   * shouldn't touch the cache level, especially as that
 -   * would make the object snooped which might have a
 -   * negative performance impact.
 -   */
 -  if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev)) {
 -  ret = i915_gem_object_set_cache_level(ctx->obj,
 -I915_CACHE_L3_LLC);
 -  /* Failure shouldn't ever happen this early */
 -  if (WARN_ON(ret))
 +  if (dev_priv->hw_context_size) {
 +  ctx->obj = i915_gem_alloc_object(dev, 
dev_priv->hw_context_size);
 +  if (ctx->obj == NULL) {
 +  ret = -ENOMEM;
goto err_out;
 -  }
 +  }

-   if (INTEL_INFO(dev)->gen >= 7) {
 -  list_add_tail(>link, _priv->context_list);
++  /*
++   * Try to make the context utilize L3 as well as LLC.
++   *
++   * On VLV we don't have L3 controls in the PTEs so we
++   * shouldn't touch the cache level, especially as that
++   * would make the object snooped which might have a
++   * negative performance impact.
++   */
++  if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev)) {
 +  ret = i915_gem_object_set_cache_level(ctx->obj,
 +
I915_CACHE_L3_LLC);
 +  /* Failure shouldn't ever happen this early */
 +  if (WARN_ON(ret))
 +  goto err_out;
 +  }
 +  }

/* Default context will never have a file_priv */
 -  if (file_priv == NULL)
 -  return ctx;
 -
 -  ret = idr_alloc(_priv->context_idr, ctx, DEFAULT_CONTEXT_ID, 0,
 -  GFP_KERNEL);
 -  if (ret < 0)
 -  goto err_out;
 +  if (file_priv != NULL) {
 +  ret = idr_alloc(_priv->context_idr, ctx,
 +  DEFAULT_CONTEXT_ID, 0, GFP_KERNEL);
 +  if (ret < 0)
 +  goto err_out;
 +  } else
 +  ret = DEFAULT_CONTEXT_ID;

ctx->file_priv = file_priv;
ctx->id = ret;
-- 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/20140415/8a812e23/attachment.sig>

[RFC PATCH 12/14] ARM: dts: exynos5: add system register support

[Sylwester Nawrocki]

On 15/04/14 10:41, Sachin Kamat wrote:
> On 15 April 2014 11:17, YoungJun Cho  wrote:
>> This patch adds sysreg device node, and sysreg property to fimd device node
>> which is required to use I80 interface.
>>
>> Signed-off-by: YoungJun Cho 
>> Signed-off-by: Inki Dae 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  arch/arm/boot/dts/exynos5.dtsi |6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
>> index 258dca4..f938bbb 100644
>> --- a/arch/arm/boot/dts/exynos5.dtsi
>> +++ b/arch/arm/boot/dts/exynos5.dtsi
>> @@ -88,12 +88,18 @@
>> status = "disabled";
>> };
>>
>> +   sys_reg: syscon at 1005 {
>> +   compatible = "samsung,exynos5-sysreg", "syscon";
> 
> Do we really need a separate string for this? Can't we use
> "samsung,exynos4-sysreg" itself?

Currently only "syscon" is meaningful in Linux, and we add second SoC
specific compatible to be able to distinguish between various SoC
revisions, should any SoC specific quirks be handled in future.
Thus there is no much point in adding "samsung,exynos4-sysreg" to
exynos5.dtsi. We could as well only leave "syscon" entry alone.
My suggestion is to keep "samsung,exynos5-sysreg", so for instance
Exynos4 and Exynos5 SOC series SYSREG blocks can be identified in
an OS.

--
Regards,
Sylwester

[PATCH] drm/radeon: fix VCE fence command

[Christian König]

Am 15.04.2014 00:13, schrieb Deucher, Alexander:
>> -Original Message-
>> From: Christoph Jaeger [mailto:christophjaeger at linux.com]
>> Sent: Monday, April 14, 2014 6:10 PM
>> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie
>> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; 
>> Christoph
>> Jaeger
>> Subject: [PATCH] drm/radeon: fix VCE fence command
>>
>> Due to a type mismatch that causes an implicit type conversion, the
>> upper 32 bits of the GPU address have been zeroed out when adding to the
>> command buffer.
>>
>> Picked up by Coverity - CID 1198624.
>>
>> Signed-off-by: Christoph Jaeger 
> Good catch!

Indeed.

>
> Reviewed-by: Alex Deucher 

Added to my 3.15 fixes queue.

Thanks,
Christian.

>
>> ---
>>   drivers/gpu/drm/radeon/radeon_vce.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
>> b/drivers/gpu/drm/radeon/radeon_vce.c
>> index 76e9904..ced53dd 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vce.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vce.c
>> @@ -613,7 +613,7 @@ void radeon_vce_fence_emit(struct radeon_device
>> *rdev,
>> struct radeon_fence *fence)
>>   {
>>  struct radeon_ring *ring = >ring[fence->ring];
>> -uint32_t addr = rdev->fence_drv[fence->ring].gpu_addr;
>> +uint64_t addr = rdev->fence_drv[fence->ring].gpu_addr;
>>
>>  radeon_ring_write(ring, VCE_CMD_FENCE);
>>  radeon_ring_write(ring, addr);
>> --
>> 1.9.0

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

[Daeseok Youn]

It need to be checking NULL before dereferencing.

Signed-off-by: Daeseok Youn 
---
 drivers/gpu/drm/nouveau/core/subdev/clock/base.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
index dd62bae..a586d030 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
@@ -290,9 +290,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx)
return 0;

pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
-   cstate = >base;
if (!pstate)
return -ENOMEM;
+   cstate = >base;

INIT_LIST_HEAD(>list);

-- 
1.7.4.4

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

[Daniel Vetter]

After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:

- The locking is all wrong: set_config(NULL) will also unlink encoders
  and connectors, but those links are protected with the mode_config
  mutex. In the ->disable_plane callback we only hold all modeset
  locks, but eventually we want to switch to just grabbing the
  per-crtc (and maybe per-plane) locks as needed, maybe based on
  ww_mutexes. Having a callback which absolutely needs all modeset
  locks is bad for this conversion.

  Note that the same isn't true for the provided ->update_plane since
  we've audited the crtc helpers to make sure that not encoder or
  connector links are changed.

- There's no way to re-enable the plane with an ->update_plane: The
  connectors/encoder links are lost and so we can't re-enable the
  CRTC. Even without that issue the driver might have reassigned some
  shared resources (as opposed to e.g. DPMS off, where drivers are not
  allowed to do that to make sure the CRTC can be enabled again).

- The semantics don't make much sense: Userspace asked to scan out
  black (or some other color if the driver supports a background
  color), not that the screen be disabled.

- Implementing proper primary plane support (i.e. actually disabling
  the primary plane without disabling the CRTC) is really simple, at
  least if all the hw needs is flipping a bit. The big task is
  auditing all the interactions with other ioctls when the CRTC is on
  but there's no primary plane (e.g. pageflips). And some of that work
  still needs to be done.

Cc: Matt Roper 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane_helper.c | 33 +
 1 file changed, 5 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 9263fd5efa58..9540ff9f97fe 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -205,9 +205,9 @@ EXPORT_SYMBOL(drm_primary_helper_update);
  *
  * Provides a default plane disable handler for primary planes.  This is 
handler
  * is called in response to a userspace SetPlane operation on the plane with a
- * NULL framebuffer parameter.  We call the driver's modeset handler with a 
NULL
- * framebuffer to disable the CRTC if no other planes are currently enabled.
- * If other planes are still enabled on the same CRTC, we return -EBUSY.
+ * NULL framebuffer parameter.  It unconditionally fails the disable call with
+ * -EINVAL the only way to disable the primary plane without driver support is
+ * to disable the entier CRTC. Which does not match the plane ->disable hook.
  *
  * Note that some hardware may be able to disable the primary plane without
  * disabling the whole CRTC.  Drivers for such hardware should provide their
@@ -216,34 +216,11 @@ EXPORT_SYMBOL(drm_primary_helper_update);
  * disabled primary plane).
  *
  * RETURNS:
- * Zero on success, error code on failure
+ * Unconditionally returns -EINVAL.
  */
 int drm_primary_helper_disable(struct drm_plane *plane)
 {
-   struct drm_plane *p;
-   struct drm_mode_set set = {
-   .crtc = plane->crtc,
-   .fb = NULL,
-   };
-
-   if (plane->crtc == NULL || plane->fb == NULL)
-   /* Already disabled */
-   return 0;
-
-   list_for_each_entry(p, >dev->mode_config.plane_list, head)
-   if (p != plane && p->fb) {
-   DRM_DEBUG_KMS("Cannot disable primary plane while other 
planes are still active on CRTC.\n");
-   return -EBUSY;
-   }
-
-   /*
-* N.B.  We call set_config() directly here rather than
-* drm_mode_set_config_internal() since drm_mode_setplane() already
-* handles the basic refcounting and we don't need the special
-* cross-CRTC refcounting (no chance of stealing connectors from
-* other CRTC's with this update).
-*/
-   return plane->crtc->funcs->set_config();
+   return -EINVAL;
 }
 EXPORT_SYMBOL(drm_primary_helper_disable);

-- 
1.9.2

[PATCH 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

[Joonyoung Shim]

Hi Tomasz,

On 04/15/2014 12:00 AM, Tomasz Stanislawski wrote:
> This patch add proper compatibles for Mixer and HDMI chip
> available on exynos4210 SoCs.
>
> Signed-off-by: Tomasz Stanislawski 
> ---
>   drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
>   drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
>   2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index d2d6e2e..6fa63ea 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data 
> *drm_hdmi_dt_parse_pdata
>   
>   static struct of_device_id hdmi_match_types[] = {
>   {
> + .compatible = "samsung,exynos4210-hdmi",
> + .data   = (void *)HDMI_TYPE13,

It's consistent with others to use struct hdmi_driver_data like
exynos5_hdmi_driver_data.

> + }, {
>   .compatible = "samsung,exynos5-hdmi",
>   .data = _hdmi_driver_data,
>   }, {
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index e3306c8..fd8a9a0 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = 
> {
>   
>   static struct of_device_id mixer_match_types[] = {
>   {
> + .compatible = "samsung,exynos4210-mixer",
> + .data   = _mxr_drv_data,
> + }, {
>   .compatible = "samsung,exynos5-mixer",
>   .data   = _mxr_drv_data,
>   }, {

[PATCH] drm/radeon: memory leak on bo reservation failure. v2

[Alex Deucher]

On Tue, Apr 15, 2014 at 5:28 AM, Christian K?nig
 wrote:
> From: Quentin Casasnovas 
>
> On bo reservation failure, we end up leaking fpriv.
>
> v2 (chk): rebased and added missing free on vm failure as well
>
> Fixes: 5e386b574cf7e1 ("drm/radeon: fix missing bo reservation")
> Cc: stable at vger.kernel.org
> Cc: Christian K?nig 
> Cc: Alex Deucher 
> Signed-off-by: Quentin Casasnovas 
> Signed-off-by: Christian K?nig 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_kms.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 9337820..fb3d13f 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -574,12 +574,17 @@ int radeon_driver_open_kms(struct drm_device *dev, 
> struct drm_file *file_priv)
> }
>
> r = radeon_vm_init(rdev, >vm);
> -   if (r)
> +   if (r) {
> +   kfree(fpriv);
> return r;
> +   }
>
> r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
> -   if (r)
> +   if (r) {
> +   radeon_vm_fini(rdev, >vm);
> +   kfree(fpriv);
> return r;
> +   }
>
> /* map the ib pool buffer read only into
>  * virtual address space */
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 74121] [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

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

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

--- Comment #1 from Rahul Sharma  ---
-- Forwarded message --
From:  
Date: 15 April 2014 14:32
Subject: [Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal
error "Unexpected 64bit argument detected"
To: dri-devel at lists.freedesktop.org


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

Bug ID: 74121
   Summary: [3.15-rc1] Exynos: Sandbox report fatal error
"Unexpected 64bit argument detected"
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc1
  Hardware: Other
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: r.sh.open at gmail.com
Regression: No

Sandbox crashing with 3.15-rc1 stating below fatal error. This was working in
till 3.14 Stable.

---
[1925:1925:0101/000305:FATAL:sandbox_bpf.cc(202)] Unexpected 64bit argument
detected
[1860:1860:1231/160305:FATAL:gpu_process_transport_factory.cc(210)] Failed to
create UI context, but can't use software compositing with browser threaded
compositing. Aborting.
Handling SIGCHLD.
Successfully wrote to child pipe.
bootstrap_helper: ReserveBottomPages: NULL pointer guard page errno=22
---

[This is my first bug. Please let me know if things are not upto the mark.]

--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

15-rc1: radeon modesetting fails

[Alex Deucher]

On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov  wrote:
> Hi Christian,
>
> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian K?nig wrote:
>> Hi Borislav,
>>
>> that's a known issue and should be fixed in the next rc, see this
>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>
>> You might also want to try my branch with 3.15 fixes which includes
>> the necessary patch for this: 
>> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>
>> Let me know if that branch works for you or not.
>
> so I went and merged your branch as you suggested. Btw, on its tip it
> has:
>
> commit ec02666dd0791312b5820e1a9a023681d99d07ec
> Author: Quentin Casasnovas 
> Date:   Tue Mar 18 17:16:52 2014 +0100
>
> drm/radeon: memory leak on bo reservation failure. v2
>
> (just checking whether I got the right one)
>
> and, unfortunately, no change - same problem. Let me know if I should
> bisect the subset of 59 radeon patches which went in during the merge
> window...
>
> Btw, just in case, I went and updated radeon firmware in
> /lib/firmware/radeon/ from upstream but it didn't change anything.

Does reverting:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
fix the issue?  We may need to tweak the pll parameters for older asics.

Alex

>
> Thanks.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 74121] New: [3.15-rc1] Exynos: Sandbox report fatal error "Unexpected 64bit argument detected"

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

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

Bug ID: 74121
   Summary: [3.15-rc1] Exynos: Sandbox report fatal error
"Unexpected 64bit argument detected"
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc1
  Hardware: Other
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: r.sh.open at gmail.com
Regression: No

Sandbox crashing with 3.15-rc1 stating below fatal error. This was working in
till 3.14 Stable.

---
[1925:1925:0101/000305:FATAL:sandbox_bpf.cc(202)] Unexpected 64bit argument
detected
[1860:1860:1231/160305:FATAL:gpu_process_transport_factory.cc(210)] Failed to
create UI context, but can't use software compositing with browser threaded
compositing. Aborting.
Handling SIGCHLD.
Successfully wrote to child pipe.
bootstrap_helper: ReserveBottomPages: NULL pointer guard page errno=22
---

[This is my first bug. Please let me know if thing are not upto the mark.]

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

15-rc1: radeon modesetting fails

[Borislav Petkov]

Hi guys,

so I'm booting 15-rc1 + tip/master and around the time modesetting gets
initialized, the screen blanks and on it appears a message from the
monitors:

"The current input timing is not supported by the monitor display.
Please change your input timing to 1920x1200 at 60Hz or any other monitor
listed timing as per the monitor specifications."

The box is still responsive, I can reboot it with Ctrl-Alt-Del but
screens are blank.

If I boot with radeon.modeset=0, I see the normal nomodeset big letters
on the console and not very optimal screen resolution.

Diffing drm init chatter from dmesg shows only this:

--- /tmp/working2014-04-15 08:40:21.979985352 +0200
+++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
@@ -44,4 +44,5 @@
 [drm]pitch is 7680
 fbcon: radeondrmfb (fb0) is primary device
 radeon :01:00.0: fb0: radeondrmfb frame buffer device
-[drm] Initialized radeon 2.37.0 20080528 for :01:00.0 on minor 0
+[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0
+

Below is the whole thing, btw.

Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?

git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
59

Thanks.

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
[drm] register mmio base: 0xFEA2
[drm] register mmio size: 65536
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Loading RV635 Microcode
[drm] Internal thermal controller without fan control
[drm] radeon: power management initialized
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 512M enabled (table at 0x0004).
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I-1
[drm]   HPD1
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm]   DIN-1
[drm]   Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I-2
[drm]   HPD2
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] fb mappable at 0xC0141000
[drm] vram apper at 0xC000
[drm] size 9216000
[drm] fb depth is 24
[drm]pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
radeon :01:00.0: fb0: radeondrmfb frame buffer device
[drm] Initialized radeon 2.38.0 20080528 for :01:00.0 on minor 0

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Possible fb ref count issue with drm_plane_force_disable()

[Rob Clark]

On Tue, Apr 15, 2014 at 6:44 AM, Tomi Valkeinen  
wrote:
> On 15/04/14 13:29, Andrzej Hajda wrote:
>
>> I have experienced similar problem with exynos_drm. I have found that
>> in exynos_drm_crtc_mode_set there is line:
>>
>>   plane->fb = crtc->primary->fb;
>>
>> without drm_framebuffer_reference.
>> In result drm_framebuffer_remove dereferences it twice:
>> - because of crtc->primary->fb == fb,
>> - because of fb being on dev->mode_config.plane_list
>>
>> I am not sure how it should be solved properly, but adding
>> drm_framebuffer_reference in exynos_drm_crtc_mode_set helps.
>>
>> In omap_plane_mode_set there is also assignment:
>>
>>   plane->fb = fb
>>
>> without drm_framebuffer_reference so maybe it can be solved the same way.
>
> The omap_plane_mode_set() is called also when using non-primary planes.
> For those the refcounting goes right at the moment (I think), so adding
> drm_framebuffer_reference() at that func would break it.
>
> I guess I could check if the plane is primary, and add ref only then. Or
> add the ref in omap_crtc, before it calls omap_plane_mode_set(). Both
> feel a bit hacky...

probably split out omap_plane_mode_set_internal(), call that directly
from update_plane() for plane operations.  And then do the refcnt
dance in the new omap_plane_mode_set() which calls _internal()..

BR,
-R

>  Tomi
>
>

[Bug 73901] Kernel crash after modprobe radeon runpm=1

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

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

--- Comment #13 from Pali Roh?r  ---
(In reply to Alex Deucher from comment #11)
> Created attachment 132311 [details]
> avoid a possible crash when runpm is forced on non-ATPX systems
> 
> Fix runpm=1 handling on non-PX systems.

It is not possible to apply this patch on top of 3.14 nor on top of linus
master (55101e2d6ce1c780f6ee8fee5f37306971aac6cd)

linux/drivers/gpu/drm/radeon$ patch -p5 -i
0002-drm-radeon-don-t-allow-runpm-1-on-systems-with-out-A.patch
patching file radeon_kms.c
Hunk #1 FAILED at 107.
1 out of 1 hunk FAILED -- saving rejects to file radeon_kms.c.rej

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

[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes

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

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

--- Comment #4 from nine at detonation.org ---
(In reply to comment #3)
> Does this patch set help:
> http://lists.freedesktop.org/archives/dri-devel/2014-April/057512.html

Which tree does this apply to?

I applied it to 3.14 but the third patch was rejected and the resulting kernel
crashed on any attempt to open a GL window.

On Linus' master the third patch was rejected as well but at least I was able
to enable desktop effects and start mplayer. Still got problems with the screen
suddenly going blank and the system freezing (had those before as well but much
less frequently, maybe due to lower GL usage).

-- 
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/20140415/c9f193bb/attachment-0001.html>

[Bug 73901] Kernel crash after modprobe radeon runpm=1

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

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

--- Comment #12 from Pali Roh?r  ---
(In reply to Alex Deucher from comment #10)
> Created attachment 132301 [details]
> fix ATPX detection on non-VGA dGPUs
> 
> Thanks for sorting this out.

This patch is same as mine, already tested and is working.

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

[Bug 71891] 3.13 fails to boot with the radeon module

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

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

--- Comment #16 from sdh  ---
ping.

I guess the above response got lost in the huge amount of mails you must be
receiving :)

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

[PATCH] drm/plane-helper: Don't fake-implement primary plane disabling

[Matt Roper]

On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote:
> After thinking about this topic a bit more I've reached the conclusion
> that implementing this doesn't make sense:
> 
> - The locking is all wrong: set_config(NULL) will also unlink encoders
>   and connectors, but those links are protected with the mode_config
>   mutex. In the ->disable_plane callback we only hold all modeset
>   locks, but eventually we want to switch to just grabbing the
>   per-crtc (and maybe per-plane) locks as needed, maybe based on
>   ww_mutexes. Having a callback which absolutely needs all modeset
>   locks is bad for this conversion.
> 
>   Note that the same isn't true for the provided ->update_plane since
>   we've audited the crtc helpers to make sure that not encoder or
>   connector links are changed.
> 
> - There's no way to re-enable the plane with an ->update_plane: The
>   connectors/encoder links are lost and so we can't re-enable the
>   CRTC. Even without that issue the driver might have reassigned some
>   shared resources (as opposed to e.g. DPMS off, where drivers are not
>   allowed to do that to make sure the CRTC can be enabled again).
> 
> - The semantics don't make much sense: Userspace asked to scan out
>   black (or some other color if the driver supports a background
>   color), not that the screen be disabled.
> 
> - Implementing proper primary plane support (i.e. actually disabling
>   the primary plane without disabling the CRTC) is really simple, at
>   least if all the hw needs is flipping a bit. The big task is
>   auditing all the interactions with other ioctls when the CRTC is on
>   but there's no primary plane (e.g. pageflips). And some of that work
>   still needs to be done.
> 
> Cc: Matt Roper 
> Signed-off-by: Daniel Vetter 

Yeah, I agree this is probably a better way to go.

Reviewed-by: Matt Roper 


Matt

> ---
>  drivers/gpu/drm/drm_plane_helper.c | 33 +
>  1 file changed, 5 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 9263fd5efa58..9540ff9f97fe 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -205,9 +205,9 @@ EXPORT_SYMBOL(drm_primary_helper_update);
>   *
>   * Provides a default plane disable handler for primary planes.  This is 
> handler
>   * is called in response to a userspace SetPlane operation on the plane with 
> a
> - * NULL framebuffer parameter.  We call the driver's modeset handler with a 
> NULL
> - * framebuffer to disable the CRTC if no other planes are currently enabled.
> - * If other planes are still enabled on the same CRTC, we return -EBUSY.
> + * NULL framebuffer parameter.  It unconditionally fails the disable call 
> with
> + * -EINVAL the only way to disable the primary plane without driver support 
> is
> + * to disable the entier CRTC. Which does not match the plane ->disable hook.
>   *
>   * Note that some hardware may be able to disable the primary plane without
>   * disabling the whole CRTC.  Drivers for such hardware should provide their
> @@ -216,34 +216,11 @@ EXPORT_SYMBOL(drm_primary_helper_update);
>   * disabled primary plane).
>   *
>   * RETURNS:
> - * Zero on success, error code on failure
> + * Unconditionally returns -EINVAL.
>   */
>  int drm_primary_helper_disable(struct drm_plane *plane)
>  {
> - struct drm_plane *p;
> - struct drm_mode_set set = {
> - .crtc = plane->crtc,
> - .fb = NULL,
> - };
> -
> - if (plane->crtc == NULL || plane->fb == NULL)
> - /* Already disabled */
> - return 0;
> -
> - list_for_each_entry(p, >dev->mode_config.plane_list, head)
> - if (p != plane && p->fb) {
> - DRM_DEBUG_KMS("Cannot disable primary plane while other 
> planes are still active on CRTC.\n");
> - return -EBUSY;
> - }
> -
> - /*
> -  * N.B.  We call set_config() directly here rather than
> -  * drm_mode_set_config_internal() since drm_mode_setplane() already
> -  * handles the basic refcounting and we don't need the special
> -  * cross-CRTC refcounting (no chance of stealing connectors from
> -  * other CRTC's with this update).
> -  */
> - return plane->crtc->funcs->set_config();
> + return -EINVAL;
>  }
>  EXPORT_SYMBOL(drm_primary_helper_disable);
>  
> -- 
> 1.9.2
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Possible fb ref count issue with drm_plane_force_disable()

[Rob Clark]

On Tue, Apr 15, 2014 at 5:16 AM, Tomi Valkeinen  
wrote:
> On 14/04/14 11:43, Tomi Valkeinen wrote:
>> On 11/04/14 14:50, Ville Syrj?l? wrote:
>>
 So the explicit unref done by drm_plane_force_disable() seems a bit out
 of place. I can't figure out which drm_framebuffer_reference() would be
 the matching one for the unref done by drm_plane_force_disable().

 Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
 extra in drm_plane_force_disable()?
>>>
>>> That's the reference that was taken by the drm_mode_setplane() when it
>>> succesfully called the .update_plane() hook.
>>
>> But drm_mode_setplane() is called via DRM_IOCTL_MODE_SETPLANE, which is
>> only used for "proper" planes, not for crtc primary planes, right?
>>
>> At least I don't see drm_mode_setplane() in my stack traces, and git
>> grep doesn't show it called via any other means than ioctl.
>>
>> I am not using any planes from my app, just the crtc and (indirectly)
>> its primary plane.
>
> So here's a summary of the fb refs and unrefs. It still seems to me that the
> drm_plane_force_disable does an extra unref. Either that, or omapdrm is 
> missing
> something that takes the matching reference.
>
> A line like this in the summary below:
>
> 2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup
>
> Means that "2" is the number I assigned to that ref, and there's a matching
> unref with 2) prefix later. ref36/2 means that FB ID 36 was referenced, and 
> ref
> count is 3. And the rest of the line shows rough idea of the stack trace where
> the ref/unref happens.
>
>
> # DRM_IOCTL_MODE_ADDFB 2
> 0)  kref_init
> 1) ref36/2  drm_mode_addfb2
>
> # DRM_IOCTL_MODE_SETCRTC
> 2) ref36/3  drm_mode_setcrtc / drm_framebuffer_lookup
> 3) ref36/4  drm_mode_setcrtc / drm_mode_set_config_internal
> 2) unref36/3drm_mode_setcrtc
>
> # pin new fb
> 4) ref36/4  apply_worker / omap_plane_pre_apply
>
>
> # BREAK
>
>
> # RELEASE
> 1) unref36/3drm_release / drm_fb_release / __drm_framebuffer_unregister
> 3) unref36/2drm_release / drm_fb_release / drm_framebuffer_remove / 
> drm_mode_set_config_internal
> ?) unref36/1drm_release / drm_fb_release / drm_framebuffer_remove / 
> drm_plane_force_disable
> 0) unref36/0drm_release / drm_fb_release / drm_framebuffer_remove
>
> # unpin old fb
> 4) unref36/-1   flip_worker / unpin_worker / drm_framebuffer_unreference
>

Ok, sorry to take so long to comment on the thread, it took me a while
before I had an idea ;-)

so, what triggers this is that previously drm_framebuffer_remove() did
not process private planes.  But now the fb shows up attached to a
plane as well, the crtc's primary plane.

I suspect there is some way in omap_crtc that I must have assumed the
ref the crtc held to the fb was sufficient for the plane to hold the
same ref.  Which is no longer the case.  So somewhere between
omap_crtc and it's primary plane, there now needs to be an extra level
of ref/unref.  So ref should have gone up to 5.

BR,
-R


>
> All the other unrefs I can explain, except the drm_plane_force_disable() one.
>
>  Tomi
>
>

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

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

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

Nicholas Miell  changed:

   What|Removed |Added

 Blocks||77449

-- 
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/20140415/39928a55/attachment.html>

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference

[Ben Skeggs]

- Original Message -
> From: "Daeseok Youn" 
> To: airlied at linux.ie
> Cc: bskeggs at redhat.com, dri-devel at lists.freedesktop.org, linux-kernel 
> at vger.kernel.org
> Sent: Tuesday, 15 April, 2014 11:56:49 AM
> Subject: [PATCH] drm/nouveau/clk: fix possible NULL pointer dereference
> 
> 
> It need to be checking NULL before dereferencing.
There's no dereference here.  It's an address calculation only.

> 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/gpu/drm/nouveau/core/subdev/clock/base.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> index dd62bae..a586d030 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> @@ -290,9 +290,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx)
>   return 0;
>  
>   pstate = kzalloc(sizeof(*pstate), GFP_KERNEL);
> - cstate = >base;
>   if (!pstate)
>   return -ENOMEM;
> + cstate = >base;
>  
>   INIT_LIST_HEAD(>list);
>  
> --
> 1.7.4.4
> 
> 
> 

[PATCH] drm/radeon: fix VCE fence command

[Christoph Jaeger]

Due to a type mismatch that causes an implicit type conversion, the
upper 32 bits of the GPU address have been zeroed out when adding to the
command buffer.

Picked up by Coverity - CID 1198624.

Signed-off-by: Christoph Jaeger 
---
 drivers/gpu/drm/radeon/radeon_vce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index 76e9904..ced53dd 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -613,7 +613,7 @@ void radeon_vce_fence_emit(struct radeon_device *rdev,
   struct radeon_fence *fence)
 {
struct radeon_ring *ring = >ring[fence->ring];
-   uint32_t addr = rdev->fence_drv[fence->ring].gpu_addr;
+   uint64_t addr = rdev->fence_drv[fence->ring].gpu_addr;

radeon_ring_write(ring, VCE_CMD_FENCE);
radeon_ring_write(ring, addr);
-- 
1.9.0

[PATCH v2 8/8] imx-drm: ipu-dc: Disable DC module when not in use

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  2 ++
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 14 --
 drivers/staging/imx-drm/ipuv3-crtc.c|  8 ++--
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 8678ad1..c2c6fab 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -115,8 +115,10 @@ struct ipu_dc *ipu_dc_get(struct ipu_soc *ipu, int 
channel);
 void ipu_dc_put(struct ipu_dc *dc);
 int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di *di, bool interlaced,
u32 pixel_fmt, u32 width);
+void ipu_dc_enable(struct ipu_soc *ipu);
 void ipu_dc_enable_channel(struct ipu_dc *dc);
 void ipu_dc_disable_channel(struct ipu_dc *dc);
+void ipu_dc_disable(struct ipu_soc *ipu);

 /*
  * IPU Display Interface (di) functions
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 280e494..93b2709 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -224,12 +224,16 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di 
*di, bool interlaced,
writel(0x0, dc->base + DC_WR_CH_ADDR);
writel(width, priv->dc_reg + DC_DISP_CONF2(dc->di));

-   ipu_module_enable(priv->ipu, IPU_CONF_DC_EN);
-
return 0;
 }
 EXPORT_SYMBOL_GPL(ipu_dc_init_sync);

+void ipu_dc_enable(struct ipu_soc *ipu)
+{
+   ipu_module_enable(ipu, IPU_CONF_DC_EN);
+}
+EXPORT_SYMBOL_GPL(ipu_dc_enable);
+
 void ipu_dc_enable_channel(struct ipu_dc *dc)
 {
int di;
@@ -286,6 +290,12 @@ void ipu_dc_disable_channel(struct ipu_dc *dc)
 }
 EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);

+void ipu_dc_disable(struct ipu_soc *ipu)
+{
+   ipu_module_disable(ipu, IPU_CONF_DC_EN);
+}
+EXPORT_SYMBOL_GPL(ipu_dc_disable);
+
 static void ipu_dc_map_config(struct ipu_dc_priv *priv, enum ipu_dc_map map,
int byte_num, int offset, int mask)
 {
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index c771ac1..4c6262f 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -60,10 +60,12 @@ struct ipu_crtc {

 static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
 {
+   struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
+
if (ipu_crtc->enabled)
return;

-   /* TODO: Enable DC module here, right now it is never disabled */
+   ipu_dc_enable(ipu);
ipu_plane_enable(ipu_crtc->plane[0]);
/* Start DC channel and DI after IDMAC */
ipu_dc_enable_channel(ipu_crtc->dc);
@@ -74,6 +76,8 @@ static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)

 static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
 {
+   struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
+
if (!ipu_crtc->enabled)
return;

@@ -81,7 +85,7 @@ static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
ipu_dc_disable_channel(ipu_crtc->dc);
ipu_di_disable(ipu_crtc->di);
ipu_plane_disable(ipu_crtc->plane[0]);
-   /* TODO: Disable DC module here */
+   ipu_dc_disable(ipu);

ipu_crtc->enabled = 0;
 }
-- 
1.9.1

[PATCH v2 7/8] imx-drm: ipuv3-crtc: Change display enable/disable order

[Philipp Zabel]

Now that ipu_dc_disable_channel correctly waits for the channel to finish,
we can reorder the enable/disable order to first stop the DC and DI and
only then disable the IDMAC. Enabling is done the other way around: IDMAC
first, then DC, then DI.

This avoids an issue where sometimes the channel would not correctly start,
leading to non-working LVDS displays.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipuv3-crtc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index c48f640..c771ac1 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -63,9 +63,11 @@ static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
if (ipu_crtc->enabled)
return;

-   ipu_di_enable(ipu_crtc->di);
-   ipu_dc_enable_channel(ipu_crtc->dc);
+   /* TODO: Enable DC module here, right now it is never disabled */
ipu_plane_enable(ipu_crtc->plane[0]);
+   /* Start DC channel and DI after IDMAC */
+   ipu_dc_enable_channel(ipu_crtc->dc);
+   ipu_di_enable(ipu_crtc->di);

ipu_crtc->enabled = 1;
 }
@@ -75,9 +77,11 @@ static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
if (!ipu_crtc->enabled)
return;

-   ipu_plane_disable(ipu_crtc->plane[0]);
+   /* Stop DC channel and DI before IDMAC */
ipu_dc_disable_channel(ipu_crtc->dc);
ipu_di_disable(ipu_crtc->di);
+   ipu_plane_disable(ipu_crtc->plane[0]);
+   /* TODO: Disable DC module here */

ipu_crtc->enabled = 0;
 }
-- 
1.9.1

[PATCH v2 6/8] imx-drm: imx-dp: When disabling the DP foreground channel, wait until the DP background channel is finished before disabling the IDMAC channel

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 6980fa1..d90f82a 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
@@ -277,6 +277,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
writel(0, flow->base + DP_FG_POS);
ipu_srm_dp_sync_update(priv->ipu);

+   if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
+   ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
+
mutex_unlock(>mutex);
 }
 EXPORT_SYMBOL_GPL(ipu_dp_disable_channel);
-- 
1.9.1

[PATCH v2 5/8] imx-drm: ipu-dp: Split disabling the DP foreground channel from disabling the DP module

[Philipp Zabel]

The former has to be done before disabling the DMFC, the latter has to be
done afterwards. Otherwise the DMFC FIFOs never get cleared properly.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  2 +
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68 +++--
 drivers/staging/imx-drm/ipuv3-plane.c   |  4 ++
 3 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 2966e42..8678ad1 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -153,8 +153,10 @@ void ipu_dmfc_put(struct dmfc_channel *dmfc);

 struct ipu_dp *ipu_dp_get(struct ipu_soc *ipu, unsigned int flow);
 void ipu_dp_put(struct ipu_dp *);
+int ipu_dp_enable(struct ipu_soc *ipu);
 int ipu_dp_enable_channel(struct ipu_dp *dp);
 void ipu_dp_disable_channel(struct ipu_dp *dp);
+void ipu_dp_disable(struct ipu_soc *ipu);
 int ipu_dp_setup_channel(struct ipu_dp *dp,
enum ipu_color_space in, enum ipu_color_space out);
 int ipu_dp_set_window_pos(struct ipu_dp *, u16 x_pos, u16 y_pos);
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 58f87c8..6980fa1 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
@@ -215,10 +215,9 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
 }
 EXPORT_SYMBOL_GPL(ipu_dp_setup_channel);

-int ipu_dp_enable_channel(struct ipu_dp *dp)
+int ipu_dp_enable(struct ipu_soc *ipu)
 {
-   struct ipu_flow *flow = to_flow(dp);
-   struct ipu_dp_priv *priv = flow->priv;
+   struct ipu_dp_priv *priv = ipu->dp_priv;

mutex_lock(>mutex);

@@ -227,15 +226,28 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)

priv->use_count++;

-   if (dp->foreground) {
-   u32 reg;
+   mutex_unlock(>mutex);

-   reg = readl(flow->base + DP_COM_CONF);
-   reg |= DP_COM_CONF_FG_EN;
-   writel(reg, flow->base + DP_COM_CONF);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_dp_enable);

-   ipu_srm_dp_sync_update(priv->ipu);
-   }
+int ipu_dp_enable_channel(struct ipu_dp *dp)
+{
+   struct ipu_flow *flow = to_flow(dp);
+   struct ipu_dp_priv *priv = flow->priv;
+   u32 reg;
+
+   if (!dp->foreground)
+   return 0;
+
+   mutex_lock(>mutex);
+
+   reg = readl(flow->base + DP_COM_CONF);
+   reg |= DP_COM_CONF_FG_EN;
+   writel(reg, flow->base + DP_COM_CONF);
+
+   ipu_srm_dp_sync_update(priv->ipu);

mutex_unlock(>mutex);

@@ -247,25 +259,35 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
 {
struct ipu_flow *flow = to_flow(dp);
struct ipu_dp_priv *priv = flow->priv;
+   u32 reg, csc;
+
+   if (!dp->foreground)
+   return;

mutex_lock(>mutex);

-   priv->use_count--;
+   reg = readl(flow->base + DP_COM_CONF);
+   csc = reg & DP_COM_CONF_CSC_DEF_MASK;
+   if (csc == DP_COM_CONF_CSC_DEF_FG)
+   reg &= ~DP_COM_CONF_CSC_DEF_MASK;

-   if (dp->foreground) {
-   u32 reg, csc;
+   reg &= ~DP_COM_CONF_FG_EN;
+   writel(reg, flow->base + DP_COM_CONF);

-   reg = readl(flow->base + DP_COM_CONF);
-   csc = reg & DP_COM_CONF_CSC_DEF_MASK;
-   if (csc == DP_COM_CONF_CSC_DEF_FG)
-   reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+   writel(0, flow->base + DP_FG_POS);
+   ipu_srm_dp_sync_update(priv->ipu);

-   reg &= ~DP_COM_CONF_FG_EN;
-   writel(reg, flow->base + DP_COM_CONF);
+   mutex_unlock(>mutex);
+}
+EXPORT_SYMBOL_GPL(ipu_dp_disable_channel);

-   writel(0, flow->base + DP_FG_POS);
-   ipu_srm_dp_sync_update(priv->ipu);
-   }
+void ipu_dp_disable(struct ipu_soc *ipu)
+{
+   struct ipu_dp_priv *priv = ipu->dp_priv;
+
+   mutex_lock(>mutex);
+
+   priv->use_count--;

if (!priv->use_count)
ipu_module_disable(priv->ipu, IPU_CONF_DP_EN);
@@ -275,7 +297,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)

mutex_unlock(>mutex);
 }
-EXPORT_SYMBOL_GPL(ipu_dp_disable_channel);
+EXPORT_SYMBOL_GPL(ipu_dp_disable);

 struct ipu_dp *ipu_dp_get(struct ipu_soc *ipu, unsigned int flow)
 {
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c 
b/drivers/staging/imx-drm/ipuv3-plane.c
index 27a8d73..5697e59 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -239,6 +239,8 @@ err_out:

 void ipu_plane_enable(struct ipu_plane *ipu_plane)
 {
+   if (ipu_plane->dp)
+   ipu_dp_enable(ipu_plane->ipu);
ipu_dmfc_enable_channel(ipu_plane->dmfc);
ipu_idmac_enable_channel(ipu_plane->ipu_ch);
if (ipu_plane->dp)
@@ -257,6 +259,8 @@ void ipu_plane_disable(struct ipu_plane *ipu_plane)

[PATCH v2 4/8] imx-drm: ipu-dc: Wait for DC_FC_1 / DP_SF_END interrupt

[Philipp Zabel]

Wait for the DC Frame Complete or DP Sync Flow End interrupts
before disabling DC channels.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Moved disable_irq() out of dc_irq_handler()
---
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++--
 1 file changed, 50 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index d5de8bb..280e494 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "../imx-drm.h"
@@ -110,6 +111,9 @@ struct ipu_dc_priv {
struct device   *dev;
struct ipu_dc   channels[IPU_DC_NUM_CHANNELS];
struct mutexmutex;
+   struct completion   comp;
+   int dc_irq;
+   int dp_irq;
 };

 static void dc_link_event(struct ipu_dc *dc, int event, int addr, int priority)
@@ -239,38 +243,46 @@ void ipu_dc_enable_channel(struct ipu_dc *dc)
 }
 EXPORT_SYMBOL_GPL(ipu_dc_enable_channel);

+static irqreturn_t dc_irq_handler(int irq, void *dev_id)
+{
+   struct ipu_dc *dc = dev_id;
+   u32 reg;
+
+   reg = readl(dc->base + DC_WR_CH_CONF);
+   reg &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
+   writel(reg, dc->base + DC_WR_CH_CONF);
+
+   /* The Freescale BSP kernel clears DIx_COUNTER_RELEASE here */
+
+   complete(>priv->comp);
+   return IRQ_HANDLED;
+}
+
 void ipu_dc_disable_channel(struct ipu_dc *dc)
 {
struct ipu_dc_priv *priv = dc->priv;
+   int irq, ret;
u32 val;
-   int irq = 0, timeout = 50;

+   /* TODO: Handle MEM_FG_SYNC differently from MEM_BG_SYNC */
if (dc->chno == 1)
-   irq = IPU_IRQ_DC_FC_1;
+   irq = priv->dc_irq;
else if (dc->chno == 5)
-   irq = IPU_IRQ_DP_SF_END;
+   irq = priv->dp_irq;
else
return;

-   /* should wait for the interrupt here */
-   mdelay(50);
+   init_completion(>comp);
+   enable_irq(irq);
+   ret = wait_for_completion_timeout(>comp, msecs_to_jiffies(50));
+   disable_irq(irq);
+   if (ret <= 0) {
+   dev_warn(priv->dev, "DC stop timeout after 50 ms\n");

-   if (dc->di == 0)
-   val = 0x0002;
-   else
-   val = 0x0020;
-
-   /* Wait for DC triple buffer to empty */
-   while ((readl(priv->dc_reg + DC_STAT) & val) != val) {
-   usleep_range(2000, 2);
-   timeout -= 2;
-   if (timeout <= 0)
-   break;
+   val = readl(dc->base + DC_WR_CH_CONF);
+   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
+   writel(val, dc->base + DC_WR_CH_CONF);
}
-
-   val = readl(dc->base + DC_WR_CH_CONF);
-   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
-   writel(val, dc->base + DC_WR_CH_CONF);
 }
 EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);

@@ -340,7 +352,7 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
struct ipu_dc_priv *priv;
static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
0x78, 0, 0x94, 0xb4};
-   int i;
+   int i, ret;

priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -361,6 +373,23 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
priv->channels[i].base = priv->dc_reg + channel_offsets[i];
}

+   priv->dc_irq = ipu_map_irq(ipu, IPU_IRQ_DC_FC_1);
+   if (!priv->dc_irq)
+   return -EINVAL;
+   ret = devm_request_irq(dev, priv->dc_irq, dc_irq_handler, 0, NULL,
+  >channels[1]);
+   if (ret < 0)
+   return ret;
+   disable_irq(priv->dc_irq);
+   priv->dp_irq = ipu_map_irq(ipu, IPU_IRQ_DP_SF_END);
+   if (!priv->dp_irq)
+   return -EINVAL;
+   ret = devm_request_irq(dev, priv->dp_irq, dc_irq_handler, 0, NULL,
+  >channels[5]);
+   if (ret < 0)
+   return ret;
+   disable_irq(priv->dp_irq);
+
writel(DC_WR_CH_CONF_WORD_SIZE_24 | DC_WR_CH_CONF_DISP_ID_PARALLEL(1) |
DC_WR_CH_CONF_PROG_DI_ID,
priv->channels[1].base + DC_WR_CH_CONF);
-- 
1.9.1