[Bug 7770] PCI domain mismatch between X server and kernel, leaving clients unable to use direct rendering

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

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

Matt Turner  changed:

   What|Removed |Added

 Blocks|79039   |

-- 
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/20140521/5156d629/attachment.html>

[Bug 7770] PCI domain mismatch between X server and kernel, leaving clients unable to use direct rendering

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

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

Matt Turner  changed:

   What|Removed |Added

 Blocks||79039

-- 
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/20140521/062cc15f/attachment.html>

[PATCH v2 04/18] video: add command mode and command mode display timing

[YoungJun Cho]

Hi Therry

On 05/21/2014 08:02 PM, Thierry Reding wrote:
> On Wed, May 21, 2014 at 01:42:56PM +0900, YoungJun Cho wrote:
>> This patch is based on videomode and display_timing relevant codes.
>> To support command mode panel, it does not need to guide its timing
>> information to the display controller like video mode panel,
>> but it requires signal timings to transfer video data.
>> So this patch adds cmdmode struct, cmdmode_display_timing struct and
>> the according helper functions to convert cmdmode_display_timing
>> to a generic cmdmode.
>
> Can you point me to relevant documentation? I wasn't able to find it by
> a quick scan through the DSI specification.
>

I'm sorry to say that there is no specific one document.

I referred to several ones, CPU interface, I80 interface and
DBI document(last time you said it).
I think this is good to check it.
[ http://cache.freescale.com/files/dsp/doc/app_note/AN4180.pdf ]

And I asked panel vendor custom service centre also.

Thank you.
Best regards YJ

> Thierry
>

[PATCH] drm/exynos: use 4WORD dma burst length for small fbs

[Inki Dae]

Hi Rahul,

On 2014? 05? 07? 20:25, Rahul Sharma wrote:
> From: Rahul Sharma 
> 
> In case of exynos, setting dma-burst to 16Word causes permanent
> tearing for very small buffers, e.g. cursor buffer. Burst Mode
> switching, which is based on overlay size is not recommended as
> overlay size varies a lot towards the end of the screen. This
> causes unstable DMA which results into tearing again.
> 
> Rendering small buffers with lower burst size doesn't
> cause any noticable performance overhead. 128 pixel width is
> selected based on mulitple experiments with exynos5 SoCs.
> 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Prathyush K 
> ---
> Based on Inki Dae's exynos-drm-next branch.
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 40fd6cc..ef56077 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -38,6 +38,7 @@
>   */
>  
>  #define FIMD_DEFAULT_FRAMERATE 60
> +#define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>  
>  /* position control register for hardware window 0, 2 ~ 4.*/
>  #define VIDOSD_A(win)(VIDOSD_BASE + 0x00 + (win) * 16)
> @@ -446,6 +447,19 @@ static void fimd_win_set_pixfmt(struct fimd_context 
> *ctx, unsigned int win)
>  
>   DRM_DEBUG_KMS("bpp = %d\n", win_data->bpp);
>  
> + /*
> +  * In case of exynos, setting dma-burst to 16Word causes permanent
> +  * tearing for very small buffers, e.g. cursor buffer. Burst Mode
> +  * switching which is based on overlay size is not recommended as
> +  * overlay size varies alot towards the end of the screen and rapid
> +  * movement causes unstable DMA which results into iommu crash/tear.

FIMD has width limitation so width of hardware overlay may need to be
aligned to 16 pixels.
We had faced with similar issue and the issue had been resolved by
aligning it to 16 pixels.

So can you try to align it instead of changing burst len size?

Thanks,
Inki Dae

> +  */
> +
> + if (win_data->fb_width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> + val &= ~WINCONx_BURSTLEN_MASK;
> + val |= WINCONx_BURSTLEN_4WORD;
> + }
> +
>   writel(val, ctx->regs + WINCON(win));
>  }
>  
> 

[PATCH] radeon: Use time_before()

[Manuel Schölling]

To be future-proof and for better readability the time comparisons are modified
to use time_before() instead of plain, error-prone math.

Signed-off-by: Manuel Sch?lling 
---
 drivers/gpu/drm/radeon/radeon_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index f30b842..b08db66 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1592,7 +1592,7 @@ static void radeon_dynpm_idle_work_handler(struct 
work_struct *work)
 * to false since we want to wait for vbl to avoid flicker.
 */
if (rdev->pm.dynpm_planned_action != DYNPM_ACTION_NONE &&
-   jiffies > rdev->pm.dynpm_action_timeout) {
+   time_before(rdev->pm.dynpm_action_timeout, jiffies)) {
radeon_pm_get_dynpm_state(rdev);
radeon_pm_set_clocks(rdev);
}
-- 
1.7.10.4

[PATCH v2 02/18] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

Hi Daniel,

On 05/21/2014 03:45 PM, Daniel Kurtz wrote:
> On Wed, May 21, 2014 at 2:28 PM, YoungJun Cho  wrote:
>> Hi Daniel
>>
>>
>> On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
>>>
>>> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho 
>>> wrote:

 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.
 And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip() when
 exynos_drm_crtc_mode_set_commit() is failed.

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

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index 95c9435..3bf091d 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -69,8 +69,10 @@ 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);
 +   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
 +   !atomic_read(_crtc->pending_flip),
 +   HZ/20))
 +   atomic_set(_crtc->pending_flip, 0);
>>>
>>>
>>> I meant that changing this to wait_event_timeout() seems to be masking
>>> the original problem, that pending_flip wasn't being cleared.
>>
>>
>> Yes, I agree.
>>
>> The original purpose of this patch is to avoid lock-up during modetest (with
>> test_vsync) with command mode panel.
>> In MIPI DSI command mode interface, the display controller can not generate
>> VSYNC signal and uses TE signal instead which is generated by panel.
>> If there is an abnormal power off or reset condition, it is possible that

At first, I omitted the keyword "panel" at previous reply.
The abnormal power off or reset condition could be happened in panel
which generates TE signal.

>> the display controller misses the TE signal and it makes lock-up.
>> So I needed this patch.
>
> If flips are not completing on MIPI DSI, may I recommend that you
> start a timer when scheduling such a flip in the MIPI DSI driver that
> will expire after a timeout.  In that timer's expiration handler, you

The MIPI DSI doesn't take care page flip operation at all.
And the exynos_drm_crtc_finish_page_flip() is called only by interrupt 
handler of display controllers.
So there is no suitable place to set time-out for this.

> can then go through the normal process of completing a flip.  This
> would make the timeout transparent to the generic exynos_drm_crtc
> layer, which can then do its normal flip complete processing: send
> pending vblank events, put vblank, clear pending_flip, etc.
> Does that make sense?
> Is it possible?

This function is exynos_drm_crtc_dpms() and my patch is for DPMS OFF case.
That means all page flip operations should be finished already to
control DPMS off and in almost every case, there is no problem.

But if there is an issue like this lock-up, I think it should escape 
this condition.

Thank you.
Best regards YJ

>
> -Dan
>
>>> Now that you are now clearing pending_flip in the error path, you
>>> don't need the timeout, right?
>>>
>>
>> There might be my missing point. Would you explain more detail?
>>
>>
>> Thank you.
>> Best regards YJ
>>
>>> -Dan
>>>
   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
   }

 @@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
 *crtc,
   spin_lock_irq(>event_lock);
   drm_vblank_put(dev, exynos_crtc->pipe);
   list_del(>base.link);
 +   atomic_set(_crtc->pending_flip, 0);
   spin_unlock_irq(>event_lock);

   goto out;
 --
 1.7.9.5

>>>
>>
>

[PATCH v3 05/16] drm: sti: add HDA driver

[Thierry Reding]

On Tue, May 20, 2014 at 03:56:15PM +0200, Benjamin Gaignard wrote:
> Add driver to support analog TV ouput.

Unfortunate that this has the same abbreviation as High-Definition
Audio...

> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
[...]
> +/* Video DACs control */
> +#define VIDEO_DACS_CONTROL_MASK 0x0FFF
> +#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
> +#define DAC_CFG_HD_OFF_SHIFT5
> +#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
> +#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */

syscfg is starting to look more and more like it could be a syscon
driver or some other specialized, platform-specific driver.

> +/* Index (in supported modes table) of the preferred video mode */
> +#define HDA_PREF_MODE_IDX   0

I don't think this symbolic name is particularly useful.

> +/* Reference to the hda device */
> +struct device *hda_dev;

This shouldn't be needed.

> +static void sti_hda_configure_awg(struct sti_hda *hda, u32 *awg_instr, int 
> nb)
> +{
> + int i;

unsigned

> +/*
> + * Get modes
> + *
> + * @drm_connector: pointer on the drm connector
> + *
> + * Return number of modes
> + */
> +static int sti_hda_get_modes(struct drm_connector *drm_connector)
> +{
> + struct drm_device *dev = drm_connector->dev;
> + struct drm_display_mode *mode;
> + int i, count;

unsigned for i. count should probably stay signed since DRM uses that
throughout.

> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + for (i = 0, count = 0; i < ARRAY_SIZE(hda_supported_modes); i++) {

You can initialize count when it's declared to make the loop more
idiomatic.

> + mode = drm_mode_duplicate(dev, _supported_modes[i].mode);
> + if (!mode)
> + continue;
> + mode->vrefresh = drm_mode_vrefresh(mode);
> +
> + /* Set the preferred mode */
> + if (i == HDA_PREF_MODE_IDX)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> +
> + drm_mode_probed_add(drm_connector, mode);
> + count++;
> + }
> +
> + drm_mode_sort(_connector->modes);
> +
> + return count;
> +}
> +
> +

Gratuituous newline.

> +static int sti_hda_probe(struct platform_device *pdev)
> +{
[...]
> +}
> +
> +static int sti_hda_remove(struct platform_device *pdev)
> +{
[...]
> +}
> +
> +static struct of_device_id hda_match_types[] = {
> + {
> +  .compatible = "st,stih416-hda",
> +  },
> + {
> +  .compatible = "st,stih407-hda",
> +  },
> + { /* end node */ }
> +};
> +MODULE_DEVICE_TABLE(of, hda_match_types);
> +
> +struct platform_driver sti_hda_driver = {
> + .driver = {
> +.name = "sti-hda",
> +.owner = THIS_MODULE,
> +.of_match_table = hda_match_types,
> +},
> + .probe = sti_hda_probe,
> + .remove = sti_hda_remove,
> +};
> +
> +module_platform_driver(sti_hda_driver);
> +
> +MODULE_LICENSE("GPL");

Same comments here as for all previous patches.

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

[PATCH v3 04/16] drm: sti: add I2C client driver for HDMI

[Thierry Reding]

On Tue, May 20, 2014 at 03:56:14PM +0200, Benjamin Gaignard wrote:
> Add I2C client driver to retrieve EDID.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/gpu/drm/sti/Makefile  |  3 ++-
>  drivers/gpu/drm/sti/sti_ddc.c | 56 
> +++
>  2 files changed, 58 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/sti/sti_ddc.c

With my comments about DDC in the previous patch addressed this can be
completely dropped.

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

[PATCH v3 03/16] drm: sti: add HDMI driver

[Thierry Reding]

lier, hence only 24bit color.
> +  */
> + for (i = 0; i < NB_PLL_MODE; i++) {
> + if (ckpxpll >= pllmodes[i].min && ckpxpll <= pllmodes[i].max)
> + pllctrl |= HDMI_SRZ_PLL_CFG_MODE(pllmodes[i].mode);
> + }
> +
> + freqvco = tmdsck * 10;
> + if (freqvco <= 42500UL)
> + pllctrl |= HDMI_SRZ_PLL_CFG_VCOR(HDMI_SRZ_PLL_CFG_VCOR_425MHZ);
> + else if (freqvco <= 85000UL)
> + pllctrl |= HDMI_SRZ_PLL_CFG_VCOR(HDMI_SRZ_PLL_CFG_VCOR_850MHZ);
> + else if (freqvco <= 17UL)
> + pllctrl |= HDMI_SRZ_PLL_CFG_VCOR(HDMI_SRZ_PLL_CFG_VCOR_1700MHZ);
> + else if (freqvco <= 297000UL)
> + pllctrl |= HDMI_SRZ_PLL_CFG_VCOR(HDMI_SRZ_PLL_CFG_VCOR_3000MHZ);
> + else {
> + DRM_ERROR("PHY serializer clock out of range\n");
> + goto err;
> + }

This could be a table.

> +
> + /*
> +  * Configure and power up the PHY PLL
> +  */
> + hdmi->event_received = false;
> + DRM_DEBUG_DRIVER("pllctrl = 0x%x\n", pllctrl);
> + writel(pllctrl, hdmi->regs + HDMI_SRZ_PLL_CFG);
> +
> + /* wait PLL interrupt */
> + wait_event_interruptible_timeout(hdmi->wait_event,
> +  hdmi->event_received == true,
> +  msecs_to_jiffies
> +  (HDMI_TIMEOUT_PLL_LOCK));
> +
> + if ((readl(hdmi->regs + HDMI_STA) & HDMI_STA_DLL_LCK) == 0) {
> + DRM_ERROR("hdmi phy pll not locked\n");
> + goto err;
> + }

There doesn't seem to be a need for this to be strictly interrupt
driven. A simple timed loop would do equally well.

> + DRM_DEBUG_DRIVER("got PHY PLL Lock\n");
> +
> + /*
> +  * To configure the source termination and pre-emphasis appropriately
> +  * for different high speed TMDS clock frequencies a phy configuration
> +  * table must be provided, tailored to the SoC and board combination.
> +  */
> + for (i = 0; i < NB_HDMI_PHY_CONFIG; i++) {
> + if ((hdmiphy_config[i].min_tmds_freq <= tmdsck) &&
> + (hdmiphy_config[i].max_tmds_freq >= tmdsck)) {
> + val = hdmiphy_config[i].config[0];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_1);
> + val = hdmiphy_config[i].config[1];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_2);
> + val = hdmiphy_config[i].config[2];
> + writel(val, hdmi->regs + HDMI_SRZ_TAP_3);
> + val = hdmiphy_config[i].config[3];
> + val |= HDMI_SRZ_CTRL_EXTERNAL_DATA_EN;
> + val &= ~HDMI_SRZ_CTRL_POWER_DOWN;
> + writel(val, hdmi->regs + HDMI_SRZ_CTRL);
> +
> + DRM_DEBUG_DRIVER("serializer cfg 0x%x 0x%x 0x%x 0x%x\n",
> +  hdmiphy_config[i].config[0],
> +  hdmiphy_config[i].config[1],
> +  hdmiphy_config[i].config[2],
> +  hdmiphy_config[i].config[3]);
> + return 0;
> + }
> + }
> +
> + /*
> +  * Default, power up the serializer with no pre-emphasis or source
> +  * termination.
> +  */

Should this case produce a warning?

> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_1);
> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_2);
> + writel(0x0, hdmi->regs + HDMI_SRZ_TAP_3);
> + writel(HDMI_SRZ_CTRL_EXTERNAL_DATA_EN, hdmi->regs + HDMI_SRZ_CTRL);
> +
> + return 0;
> +
> +err:
> + disable_pll_rejection(hdmi);
> +
> + return -1;
> +}
[...]

> +/*
> + * Debugfs
> + */
> +#define HDMI_DBG_DUMP(reg) seq_printf(m, "\n %-25s 0x%08X", #reg, \
> + readl(hdmi->regs + reg))
> +void sti_hdmi_tx3g0c55phy_show(struct sti_hdmi *hdmi, struct seq_file *m)
> +{
> + HDMI_DBG_DUMP(HDMI_SRZ_PLL_CFG);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_1);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_2);
> + HDMI_DBG_DUMP(HDMI_SRZ_TAP_3);
> + HDMI_DBG_DUMP(HDMI_SRZ_CTRL);
> + seq_puts(m, "\n");

Why the empty line? Is this supposed to be used as part of a larger
file? I'd recommend against doing that and rather have one debugfs entry
for each device's register file.

> diff --git a/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c 
> b/drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
[...]

Mostly the same comments apply here as for the other PHY.

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

[Bug 79035] radeonsi: Unigine Sanctuary shadows

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

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

--- Comment #4 from smoki  ---

 So what we can see on this picture example :). If we look up at the little
windows we can see much darker shadows then it needs to be, if we look down
shadows are just missing, if wee look right - pillar and statue does not have
its shadow, etc...

-- 
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/20140521/89cb13b9/attachment.html>

[Bug 79035] radeonsi: Unigine Sanctuary shadows

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

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

--- Comment #3 from smoki  ---
Created attachment 99533
  --> https://bugs.freedesktop.org/attachment.cgi?id=99533=edit
swrast

-- 
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/20140521/e449d130/attachment.html>

[Bug 79035] radeonsi: Unigine Sanctuary shadows

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

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

--- Comment #2 from smoki  ---
Created attachment 99532
  --> https://bugs.freedesktop.org/attachment.cgi?id=99532=edit
fglrx

-- 
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/20140521/50d23759/attachment.html>

[Bug 79035] radeonsi: Unigine Sanctuary shadows

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

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

--- Comment #1 from smoki  ---
Created attachment 99531
  --> https://bugs.freedesktop.org/attachment.cgi?id=99531=edit
radeonsi

-- 
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/20140521/037bd52b/attachment-0001.html>

[Bug 79035] New: radeonsi: Unigine Sanctuary shadows

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

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

  Priority: medium
Bug ID: 79035
  Assignee: dri-devel at lists.freedesktop.org
   Summary: radeonsi: Unigine Sanctuary shadows
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: smoki00790 at gmail.com
  Hardware: Other
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Debian Sid current 32 & 64 i have both separete, can compile everything,
compare with fglrx, etc... but can't fix this bug myself :). Hardware is Radeon
8400 aka  R3, that is on Athlon 5350 APU.

 So all in all, shadows are broken in Unigine Sanctuary demo. 

 Fglrx and swrast behave fine.

 Some other user at phoronix, compared 7790 Bonaire (which also show a bug)
with Intel HD 2500 and i can say intel works fine, so intel does not show this
bug. He also made video of this demo which showing an issue:
http://www.phoronix.com/forums/showthread.php?100327-Catalyst-14-4-Has-Advantages-Over-Linux-3-15-Mesa-10-3-Git=418131#post418131

-- 
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/20140521/ad410124/attachment.html>

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

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

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

--- Comment #22 from Christian K?nig  ---
(In reply to Tasev Nikola from comment #21)
> Hi
> 
> With the ref_div_max 124 everything works fine.
> Should i try another value just let me now.

I'm going to submit a patch with value 114, just to have some more room for
errors.

I know that values below 100 causes problems for another user, so when 114
works for you we probably found the sweet spot.

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

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

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

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

--- Comment #21 from Tasev Nikola  ---
Hi

With the ref_div_max 124 everything works fine.
Should i try another value just let me now.

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

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #27 from smoki  ---
(In reply to comment #26)
> Does it look different from radeonsi with any other Mesa driver? E.g.
> Unigine might use the GL_ARB_shadow_ambient extension, which is supported by
> fglrx but not by Mesa.

 Swrast is OK, behave much like fglrx :). But radeonsi's shadows looks broken
in various ways, they are darker, missing and missplaced... i will open
separete bug for the issue today.

-- 
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/20140521/a3d047bd/attachment.html>

[PATCH] drm/exynos: Fix PTN3460 dependency

[Thierry Reding]

On Tue, May 20, 2014 at 11:15:25AM +0200, Jean Delvare wrote:
> The following configuration options combination:
> 
> CONFIG_DRM_EXYNOS_DP=y
> CONFIG_DRM_PTN3460=m
> 
> currently leads to the following linker failure:
> 
> drivers/built-in.o: In function `exynos_drm_attach_lcd_bridge':
> .../drivers/gpu/drm/exynos/exynos_dp_core.c:1004:
> undefined reference to `ptn3460_init'
> 
> This is because ptn3460_init can't be implemented in a module while
> its caller is built into the kernel. So add the proper dependency in
> Kconfig so that the above can't happen.
> 
> I moved DRM_PTN3460 earlier in Kconfig, next to the I2C helper module
> section, so that the user has a chance to select it before moving to
> the Exynos-specific section.
> 
> IMHO the proper way to solve the problem would be to turn ptn3460 into
> a clean I2C driver, similar to the other I2C helper chip drivers. It's
> the only way to not sink into impossible-to-guess dependencies. Then
> ptn3460 could even be moved together with the other I2C helper chip
> drivers.

FWIW, various ideas have been discussed to solve this problem. The most
recent agreement I think was to create a registry for bridge drivers to
register DRM bridge objects against and allow drivers to look them up.
That way we can get rid of the various *_init() functions that currently
need to be called directly from within DRM drivers.

I'm not aware of anybody working on this currently, hence I think this
is an appropriate fix in the meantime:

Reviewed-by: Thierry Reding 
-- 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/20140521/92cc54e9/attachment.sig>

[PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup

[Thierry Reding]

On Wed, May 14, 2014 at 05:09:45PM +0530, Naveen Krishna Chatradhi wrote:
> exynos_drm_init() does probing of various drivers like dp_panel,
> hdmi, fimd, mixer, etc in an order and finally binds them together.
> 
> Some of the drm devices (Eg: dp_panel) try to do regulator_get()
> and enable few supplies during their probe.
> Chances are that, these devices may get probed before the respective
> supply/PMIC is hooked.  In such cases, dp_panel would continue with
> "dummy regulator". Which is not what the system wants.
> 
> Lets give the core connectivity and regulators modules some time
> to hookup the supplies before Exynos DRM devices comes into picture.
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> This change is proposed after
> 1. Discussing with I2C/SPI & DMA subsystem maintainers and Others
>@ https://lkml.org/lkml/2014/5/9/333
>Trying to change the I2C, SPI and DMA drivers as subsys_initcall()
>Which was strictly opposed, as a flaw was found in DRM subsystem.
> 
> 2. -EPROBE_DEFER won't work well with the current sequency of
> platform_driver_register()s in exynos_drm_init()

Then this is the problem that you need to fix. If the driver doesn't
handle -EPROBE_DEFER properly then that means the driver is broken. No
amount of initcall ordering can fix this for you.

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

[PATCH v3 02/16] drm: sti: add VTAC drivers

[Thierry Reding]

vtac_tx_of_match? Or if you can unify both drivers: vtac_of_match. If
some parameterization is required to make Tx and Rx work in one driver
you could add different compatible strings here for each. More likely
though I think that information could be derived from context.

> + {
> +  .compatible = "st,stih416-vtac-tx",
> +  }, {
> +  /* end node */
> +  }
> +};

Strange indentation here.

> +MODULE_DEVICE_TABLE(of, vtac_tx_match_types);
> +
> +struct platform_driver sti_vtac_tx_driver = {
> + .driver = {
> +.name = "sti-vtac-tx",
> +.owner = THIS_MODULE,
> +.of_match_table = vtac_tx_match_types,
> +},

And here.

> diff --git a/drivers/gpu/drm/sti/sti_vtac_utils.h 
> b/drivers/gpu/drm/sti/sti_vtac_utils.h
[...]
> +/* Number of phyts per pixel */

What's a "phyt"?

> +#define VTAC_2_5_PPP 0x0005
> +#define VTAC_3_PPP   0x0006
> +#define VTAC_4_PPP   0x0008
> +#define VTAC_5_PPP   0x000A
> +#define VTAC_6_PPP   0x000C
> +#define VTAC_13_PPP  0x001A
> +#define VTAC_14_PPP  0x001C
> +#define VTAC_15_PPP  0x001E
> +#define VTAC_16_PPP  0x0020
> +#define VTAC_17_PPP  0x0022
> +#define VTAC_18_PPP  0x0024
> +
> +/* enable bits */
> +#define EVEN_PARITY  (1 << 13)
> +#define ODD_PARITY   (1 << 12)
> +#define SW_RST_AUTOC (1 << 1)
> +#define ENABLE   (1 << 0)

These could probably use a VTAC_ prefix for consistency.

> +
> +/*
> + * VTAC mode structure
> + *
> + * @type: main, aux or dvo device
> + * @vid_in_width: Video Data Resolution

These are probably obvious if you know the hardware or can look at the
datasheet, but I have no idea what this field for example means. I had
initially thought that it would contain some number of pixels, but the
table of modes below taught me better. Having some explanation of the
fields in this structure could be useful.

> + * @phyts_width: Width of phyt buses(phyt low and phyt high).
> + * @phyts_per_pixel: Number of phyts sent per pixel
> + */
> +struct sti_vtac_mode {
> + int type;
> + int vid_in_width;
> + int phyts_width;
> + int phyts_per_pixel;
> +};
> +
> +static struct sti_vtac_mode vtac_modes[] = {
> + {VTAC_MAIN, 0x2, 0x2, VTAC_5_PPP}, /* Main RGB 12 */
> + {VTAC_AUX, 0x1, 0x0, VTAC_17_PPP}, /* Aux 10 */
> +};

This doesn't really belong in a header. If you manage to unify both VTAC
Tx and Rx you can simply move this into the VTAC driver source file and
not expose it beyond that at all.

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

[PATCH 3/3] drm/i915: use async hpd_irq_event function on resume

[Daniel Vetter]

On Wed, May 21, 2014 at 08:00:22AM -0700, Jesse Barnes wrote:
> On Wed, 21 May 2014 08:52:34 +0200
> Daniel Vetter  wrote:
> 
> > On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote:
> > > Gets the detect code (which may take awhile) out of the resume path,
> > > speeding things up a bit.
> > > 
> > > Signed-off-by: Jesse Barnes 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 302495f..571f688 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -606,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, 
> > > bool restore_gtt_mappings)
> > >   intel_hpd_init(dev);
> > >   dev_priv->enable_hotplug_processing = true;
> > >   /* Config may have changed between suspend and resume */
> > > - drm_helper_hpd_irq_event(dev);
> > > + async_schedule(drm_helper_hpd_irq_event_async, dev);
> > 
> > Does that really help all that much? I've thought the driver core
> > sychnronizes all the async workers again once resume is done. I'm better
> > to schedule this as a fully async work with e.g. a 1s delay, like we do
> > with the rps resume work.
> 
> That might be better, I'll check on the synchronization.  I thought
> async_schedule was the new hotness we were supposed to use everywhere...

It's pretty cool for easy async in driver load/resume since it autosyncs.
You can even create more async domains if you need finer-grained sync
points. But if we know that we can be more lenient than full sync before
our driver load/resume completes we need to use classical work queues.

But for stuff like doing paralle modeset restore async domains look like
the right thing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v3 01/16] drm: sti: add VTG driver

[Thierry Reding]

gt; diff --git a/drivers/gpu/drm/sti/sti_vtg.h b/drivers/gpu/drm/sti/sti_vtg.h
> new file mode 100644
> index 000..da67eb3
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/sti_vtg.h
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013
> + * Author: Benjamin Gaignard  for 
> STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _STI_VTG_H_
> +#define _STI_VTG_H_
> +
> +#include 

Why do you need this include? I don't see anything in this file that's
defined in platform_device.h.

> +#include 

You don't actually need to include these here. You can simply forward
declare the structures (which works because you only pass around
pointers to them) like so:

struct drm_display_mode;
struct notifier_block;

> +
> +extern struct device *vtg_main;
> +extern struct device *vtg_aux;
> +
> +int vtg_set_config(struct device *dev, const struct drm_display_mode *mode);
> +int vtg_register_client(struct device *dev, struct notifier_block *nb);
> +int vtg_unregister_client(struct device *dev, struct notifier_block *nb);
> +
> +#endif
> diff --git a/drivers/gpu/drm/sti/sti_vtg_utils.c 
> b/drivers/gpu/drm/sti/sti_vtg_utils.c
> new file mode 100644
> index 000..06bb4b4
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/sti_vtg_utils.c
> @@ -0,0 +1,99 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013
> + * Author: Benjamin Gaignard  for 
> STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +
> +#include "sti_vtg_utils.h"
> +#include "sti_vtg.h"
> +
> +struct device *vtg_main;
> +struct device *vtg_aux;

I don't think these should be here. There is always a better way than
globals.

> +int sti_vtg_setconfig(int main_aux, const struct drm_display_mode *mode)
> +{
> + if (main_aux == VTG_MAIN && vtg_main)
> + return vtg_set_config(vtg_main, mode);
> +
> + if (main_aux == VTG_AUX && vtg_aux)
> + return vtg_set_config(vtg_aux, mode);
> +
> + return 1;
> +}
> +
> +int sti_vtg_register_client(int main_aux, struct notifier_block *nb)
> +{
> + if (main_aux == VTG_MAIN && vtg_main)
> + return vtg_register_client(vtg_main, nb);
> +
> + if (main_aux == VTG_AUX && vtg_aux)
> + return vtg_register_client(vtg_aux, nb);
> +
> + return 1;
> +}
> +
> +int sti_vtg_unregister_client(int main_aux, struct notifier_block *nb)
> +{
> + if (main_aux == VTG_MAIN && vtg_main)
> + return vtg_unregister_client(vtg_main, nb);
> +
> + if (main_aux == VTG_AUX && vtg_aux)
> + return vtg_unregister_client(vtg_aux, nb);
> +
> + return 1;
> +}
> +
> +/*
> + *   ActiveFrontSync   Back  Active
> + *   RegionPorch  Porch  Region
> + * <---><>0<-><><->
> + *
> + *   ///|   |  ///|
> + *  /// |   | /// |
> + * ///  |...|///  |
> + *0___  x/ymin   x/ymax
> + *
> + * <--[hv]display--> <--[hv]display-->
> + * <--[hv]sync_start->   <--[hv]sync_start-
> + * <--[hv]sync_end--->   <--[hv]sync_end---
> + * <--[hv]total> <--[hv]total--
> + */
> +
> +/*
> + * sti_vtg_get_line_number
> + *
> + * @mode: display mode to be used
> + * @y:line
> + *
> + * Return the line number according to the display mode taking
> + * into account the Sync and Back Porch information.
> + * Video frame line numbers start at 1, y starts at 0.
> + * In interlaced modes the start line is the field line number of the odd
> + * field, but y is still defined as a progressive frame.
> + */
> +u32 sti_vtg_get_line_number(struct drm_display_mode mode, int y)
> +{
> + int start_line = mode.vtotal - mode.vsync_start + 1;
> +
> + if (mode.flags & DRM_MODE_FLAG_INTERLACE)
> + start_line *= 2;
> +
> + return start_line + y;
> +}
> +
> +/*
> + * sti_vtg_get_pixel_number
> + *
> + * @mode: display mode to be used
> + * @x:row
> + *
> + * Return the pixel number according to the display mode taking
> + * into account the Sync and Back Porch information.
> + * Pixels are counted from 0.
> + */
> +u32 sti_vtg_get_pixel_number(struct drm_display_mode mode, int x)
> +{
> + return mode.htotal - mode.hsync_start + x;
> +}

It's somewhat unclear as to what the purpose is of these. Perhaps it
will become clearer when I see them used in a subsequent patch.

Also it looks like the comments are supposed to be kernel-doc, but they
aren't really.

> diff --git a/drivers/gpu/drm/sti/sti_vtg_utils.h 
> b/drivers/gpu/drm/sti/sti_vtg_utils.h
> new file mode 100644
> index 000..fea2852
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/sti_vtg_utils.h
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013
> + * Authors: Benjamin Gaignard 
> + *  Fabien Dessenne 
> + *  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _STI_VTG_UTILS_H_
> +#define _STI_VTG_UTILS_H_
> +
> +#include 
> +
> +#define WAIT_NEXT_VSYNC_MS  50 /*ms*/

What is this used for?

> +#define VTG_MAIN0
> +#define VTG_AUX 1
> +
> +#define VTG_TOP_FIELD_EVENT 1
> +#define VTG_BOTTOM_FIELD_EVENT  2

I would hope that we can get rid of these somehow.

> +int sti_vtg_setconfig(int main_aux, const struct drm_display_mode *mode);
> +int sti_vtg_register_client(int main_aux, struct notifier_block *nb);
> +int sti_vtg_unregister_client(int main_aux, struct notifier_block *nb);

And these.

It's intriguing hardware I must say, and certainly a challenge since
it's so different from other DRM drivers. And it's taken quite some time
to go through this one file, so I won't be able to review all patches in
one go.

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

[PATCH v3 01/16] drm: sti: add VTG driver

[Lee Jones]

> Video Time Generator drivers are used to synchronize the compositor
> and tvout hardware IPs by providing line count, sample count,
> synchronization signals (HSYNC, VSYNC) and top and bottom fields indication.
> VTG are used by pair for each data path (main or auxiliary): one for master 
> and one for slave.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/sti/Kconfig |  11 +
>  drivers/gpu/drm/sti/Makefile|   3 +
>  drivers/gpu/drm/sti/sti_vtg.c   | 468 
> 
>  drivers/gpu/drm/sti/sti_vtg.h   |  20 ++
>  drivers/gpu/drm/sti/sti_vtg_utils.c |  99 
>  drivers/gpu/drm/sti/sti_vtg_utils.h |  29 +++
>  8 files changed, 633 insertions(+)
>  create mode 100644 drivers/gpu/drm/sti/Kconfig
>  create mode 100644 drivers/gpu/drm/sti/Makefile
>  create mode 100644 drivers/gpu/drm/sti/sti_vtg.c
>  create mode 100644 drivers/gpu/drm/sti/sti_vtg.h
>  create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.c
>  create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d1cc2f6..0e30029 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -201,3 +201,5 @@ source "drivers/gpu/drm/tegra/Kconfig"
>  source "drivers/gpu/drm/panel/Kconfig"
>  
>  source "drivers/gpu/drm/bridge/Kconfig"
> +
> +source "drivers/gpu/drm/sti/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 5e792b0..44f7b17 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_QXL) += qxl/
>  obj-$(CONFIG_DRM_BOCHS) += bochs/
>  obj-$(CONFIG_DRM_MSM) += msm/
>  obj-$(CONFIG_DRM_TEGRA) += tegra/
> +obj-$(CONFIG_DRM_STI) += sti/
>  obj-y+= i2c/
>  obj-y+= panel/
>  obj-y+= bridge/
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> new file mode 100644
> index 000..3fff278
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -0,0 +1,11 @@
> +config DRM_STI
> + bool "DRM Support for STMicroelectronics SoC stiH41x Series"
> + depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
> + help
> +   Choose this option to enable DRM on STM stiH41x chipset
> +
> +config VTG_STI
> + bool "Video Timing Generator for STMicroelectronics SoC stiH41x Series"
> + depends on DRM_STI
> + help
> +   Choose this option to enable VTG on STM stiH41x chipset
> diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
> new file mode 100644
> index 000..33216e1
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/Makefile
> @@ -0,0 +1,3 @@
> +ccflags-y := -Iinclude/drm

Why is this required?

> +obj-$(CONFIG_VTG_STI) += sti_vtg.o sti_vtg_utils.o
> diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
> new file mode 100644
> index 000..75d7125
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/sti_vtg.c
> @@ -0,0 +1,468 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013

2014

> + * Authors: Benjamin Gaignard 
> + *  Fabien Dessenne 
> + *  Vincent Abriou 
> + *  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sti_vtg_utils.h"
> +#include "sti_vtg.h"
> +
> +#define VTG_TYPE_MASTER 0
> +#define VTG_TYPE_SLAVE_BY_EXT0  1
> +
> +/* registers offset */
> +#define VTG_MODE 0x
> +#define VTG_CLKLN0x0008
> +#define VTG_HLFLN0x000C
> +#define VTG_DRST_AUTOC   0x0010
> +#define VTG_VID_TFO  0x0040
> +#define VTG_VID_TFS  0x0044
> +#define VTG_VID_BFO  0x0048
> +#define VTG_VID_BFS  0x004C
> +
> +#define VTG_HOST_ITS 0x0078
> +#define VTG_HOST_ITS_BCLR0x007C
> +#define VTG_HOST_ITM_BCLR0x0088
> +#define VTG_HOST_ITM_BSET0x008C
> +
> +#define VTG_H_HD_1   0x00C0
> +#define VTG_TOP_V_VD_1   0x00C4
> +#define VTG_BOT_V_VD_1   0x00C8
> +#define VTG_TOP_V_HD_1   0x00CC
> +#define VTG_BOT_V_HD_1   0x00D0
> +
> +#define VTG_H_HD_2   0x00E0
> +#define VTG_TOP_V_VD_2   0x00E4
> +#define VTG_BOT_V_VD_2   0x00E8
> +#define VTG_TOP_V_HD_2   0x00EC
> +#define VTG_BOT_V_HD_2   0x00F0
> +
> +#define VTG_H_HD_3   0x0100
> +#define VTG_TOP_V_VD_3   0x0104
> +#define VTG_BOT_V_VD_3   0x0108
> +#define VTG_TOP_V_HD_3   0x010C
> +#define VTG_BOT_V_HD_3   0x0110
> +
> +/* IRQ mask */
> +#define VTG_IRQ_TOP_FIELD_MASK (1L << 1)
> +#define VTG_IRQ_BOTTOM_FIELD_MASK  (1L << 0)

BIT()

> +#define VTG_IRQ_MASK(VTG_IRQ_TOP_FIELD_MASK | \
> +

[PATCH 3/5] drm/radeon: Setup HDMI_CONTROL for hdmi deep color gcp's.

[Rafał Miłecki]

On 21 May 2014 15:51, Alex Deucher  wrote:
> On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki  wrote:
>> What about using helper:
>>
>> WREG32_P(HDMI_CONTROL + offset,
>> val,
>> ~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));
>
> We could.  I don't think it really makes much difference one way or
> the other though.  I don't really have a strong preference.

OK. It's up to you.

-- 
Rafa?

[PATCH resend 4/4] acpi-video: Add use native backlight quirk for the ThinkPad W530

[Hans de Goede]

Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering 
backlight"
is also needed.

https://bugzilla.redhat.com/show_bug.cgi?id=1093171

Cc: stable at vger.kernel.org
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 47b7e21..8309100 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -515,6 +515,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = 
{
},
},
{
+.callback = video_set_use_native_backlight,
+.ident = "ThinkPad W530",
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"),
+   },
+   },
+   {
.callback = video_set_use_native_backlight,
.ident = "ThinkPad X1 Carbon",
.matches = {
-- 
1.9.0

[PATCH resend 3/4] acpi-video: Unregister the backlight device if a raw one shows up later

[Hans de Goede]

When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.

This causes video.use_native_backlight=1 to not have the desired result.

This patch fixes this by adding a backlight notifier and when a raw
backlight is registered or unregistered re-doing the
acpi_video_verify_backlight_support() check.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/video.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index ba6e4d7..47b7e21 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -151,6 +151,7 @@ struct acpi_video_enumerated_device {
 struct acpi_video_bus {
struct acpi_device *device;
bool backlight_registered;
+   bool backlight_notifier_registered;
u8 dos_setting;
struct acpi_video_enumerated_device *attached_array;
u8 attached_count;
@@ -162,6 +163,7 @@ struct acpi_video_bus {
struct input_dev *input;
char phys[32];  /* for input device */
struct notifier_block pm_nb;
+   struct notifier_block backlight_nb;
 };

 struct acpi_video_device_flags {
@@ -1828,6 +1830,9 @@ static int acpi_video_bus_register_backlight(struct 
acpi_video_bus *video)
 {
struct acpi_video_device *dev;

+   if (video->backlight_registered)
+   return 0;
+
if (!acpi_video_verify_backlight_support())
return 0;

@@ -1972,6 +1977,56 @@ static void acpi_video_bus_remove_notify_handler(struct 
acpi_video_bus *video)
video->input = NULL;
 }

+static int acpi_video_backlight_notify(struct notifier_block *nb,
+   unsigned long val, void *bd)
+{
+   struct backlight_device *backlight = bd;
+   struct acpi_video_bus *video;
+
+   /* acpi_video_verify_backlight_support only cares about raw devices */
+   if (backlight->props.type != BACKLIGHT_RAW)
+   return NOTIFY_DONE;
+
+   video = container_of(nb, struct acpi_video_bus, backlight_nb);
+
+   switch (val) {
+   case BACKLIGHT_REGISTERED:
+   if (!acpi_video_verify_backlight_support())
+   acpi_video_bus_unregister_backlight(video);
+   break;
+   case BACKLIGHT_UNREGISTERED:
+   acpi_video_bus_register_backlight(video);
+   break;
+   }
+
+   return NOTIFY_OK;
+}
+
+static int acpi_video_bus_add_backlight_notify_handler(
+   struct acpi_video_bus *video)
+{
+   int error;
+
+   video->backlight_nb.notifier_call = acpi_video_backlight_notify;
+   video->backlight_nb.priority = 0;
+   error = backlight_register_notifier(>backlight_nb);
+   if (error == 0)
+   video->backlight_notifier_registered = true;
+
+   return error;
+}
+
+static int acpi_video_bus_remove_backlight_notify_handler(
+   struct acpi_video_bus *video)
+{
+   if (!video->backlight_notifier_registered)
+   return 0;
+
+   video->backlight_notifier_registered = false;
+
+   return backlight_unregister_notifier(>backlight_nb);
+}
+
 static int acpi_video_bus_put_devices(struct acpi_video_bus *video)
 {
struct acpi_video_device *dev, *next;
@@ -2053,6 +2108,7 @@ static int acpi_video_bus_add(struct acpi_device *device)

acpi_video_bus_register_backlight(video);
acpi_video_bus_add_notify_handler(video);
+   acpi_video_bus_add_backlight_notify_handler(video);

return 0;

@@ -2076,6 +2132,7 @@ static int acpi_video_bus_remove(struct acpi_device 
*device)

video = acpi_driver_data(device);

+   acpi_video_bus_remove_backlight_notify_handler(video);
acpi_video_bus_remove_notify_handler(video);
acpi_video_bus_unregister_backlight(video);
acpi_video_bus_put_devices(video);
-- 
1.9.0

[PATCH resend 2/4] backlight: Add backlight device (un)registration notification

[Hans de Goede]

Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.

Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.

By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.

Signed-off-by: Hans de Goede 
---
 drivers/video/backlight/backlight.c | 40 +
 include/linux/backlight.h   |  7 +++
 2 files changed, 47 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index bd2172c..4280890 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -23,6 +23,7 @@

 static struct list_head backlight_dev_list;
 static struct mutex backlight_dev_list_mutex;
+static struct blocking_notifier_head backlight_notifier;

 static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
@@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const 
char *name,
list_add(_bd->entry, _dev_list);
mutex_unlock(_dev_list_mutex);

+   blocking_notifier_call_chain(_notifier,
+BACKLIGHT_REGISTERED, new_bd);
+
return new_bd;
 }
 EXPORT_SYMBOL(backlight_device_register);
@@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device 
*bd)
pmac_backlight = NULL;
mutex_unlock(_backlight_mutex);
 #endif
+
+   blocking_notifier_call_chain(_notifier,
+BACKLIGHT_UNREGISTERED, bd);
+
mutex_lock(>ops_lock);
bd->ops = NULL;
mutex_unlock(>ops_lock);
@@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, 
void *res,
 }

 /**
+ * backlight_register_notifier - get notified of backlight (un)registration
+ * @nb: notifier block with the notifier to call on backlight (un)registration
+ *
+ * @return 0 on success, otherwise a negative error code
+ *
+ * Register a notifier to get notified when backlight devices get registered
+ * or unregistered.
+ */
+int backlight_register_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_notifier, nb);
+}
+EXPORT_SYMBOL(backlight_register_notifier);
+
+/**
+ * backlight_unregister_notifier - unregister a backlight notifier
+ * @nb: notifier block to unregister
+ *
+ * @return 0 on success, otherwise a negative error code
+ *
+ * Register a notifier to get notified when backlight devices get registered
+ * or unregistered.
+ */
+int backlight_unregister_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_notifier, nb);
+}
+EXPORT_SYMBOL(backlight_unregister_notifier);
+
+/**
  * devm_backlight_device_register - resource managed 
backlight_device_register()
  * @dev: the device to register
  * @name: the name of the device
@@ -544,6 +582,8 @@ static int __init backlight_class_init(void)
backlight_class->pm = _class_dev_pm_ops;
INIT_LIST_HEAD(_dev_list);
mutex_init(_dev_list_mutex);
+   BLOCKING_INIT_NOTIFIER_HEAD(_notifier);
+
return 0;
 }

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7264742..adb14a8 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -40,6 +40,11 @@ enum backlight_type {
BACKLIGHT_TYPE_MAX,
 };

+enum backlight_notification {
+   BACKLIGHT_REGISTERED,
+   BACKLIGHT_UNREGISTERED,
+};
+
 struct backlight_device;
 struct fb_info;

@@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device 
*dev,
 extern void backlight_force_update(struct backlight_device *bd,
   enum backlight_update_reason reason);
 extern bool backlight_device_registered(enum backlight_type type);
+extern int backlight_register_notifier(struct notifier_block *nb);
+extern int backlight_unregister_notifier(struct notifier_block *nb);

 #define to_backlight_device(obj) container_of(obj, struct backlight_device, 
dev)

-- 
1.9.0

[PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backlight

[Hans de Goede]

acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.

Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.

Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).

This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.

Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.

This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.

This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.

Note this effectively reverts commit 5bead799

Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 630f6e8..2c1e4aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -31,7 +31,6 @@
  */

 #include 
-#include 

 #include "nouveau_drm.h"
 #include "nouveau_reg.h"
@@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
struct nouveau_device *device = nv_device(drm->device);
struct drm_connector *connector;

-#ifdef CONFIG_ACPI
-   if (acpi_video_backlight_support()) {
-   NV_INFO(drm, "ACPI backlight interface available, "
-"not registering our own\n");
-   return 0;
-   }
-#endif
-
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
-- 
1.9.0

[PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau

[Hans de Goede]

Hi All,

I know it has not been that long since the last send of this series, but
it has been very quiet, and I would like to see some discussion on it
(or it being applied at once, that is fine too :)

This patch-set adds backlight device (un)registration notification and
makes acpi-video listen to it, so that video.use_native_backlight=1 still
works if a raw interface gets loaded *after* acpi-video has been initialized.

It also changes nouveau to always register its raw interface, as all the other
kms drivers do, acpi_video_backlight_support() is only intended to avoid the
loading of multiple (possibly conflicting) firmware drivers, not to avoid
loading raw drivers.

In the mean time I've gotten feedback from a user with a laptop which needs
video.use_native_backlight=1 and uses nouveau, and he has confirmed that this
patch-set works as advertised, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1093171

Regards,

Hans

[PATCH v2 02/18] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

Hi Daniel

On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho  
> wrote:
>> 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.
>> And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip() when
>> exynos_drm_crtc_mode_set_commit() is failed.
>>
>> Signed-off-by: YoungJun Cho 
>> Acked-by: Inki Dae 
>> Acked-by: Kyungmin Park 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_crtc.c |7 +--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 95c9435..3bf091d 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -69,8 +69,10 @@ 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);
>> +   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>> +   !atomic_read(_crtc->pending_flip),
>> +   HZ/20))
>> +   atomic_set(_crtc->pending_flip, 0);
>
> I meant that changing this to wait_event_timeout() seems to be masking
> the original problem, that pending_flip wasn't being cleared.

Yes, I agree.

The original purpose of this patch is to avoid lock-up during modetest 
(with test_vsync) with command mode panel.
In MIPI DSI command mode interface, the display controller can not 
generate VSYNC signal and uses TE signal instead which is generated by 
panel.
If there is an abnormal power off or reset condition, it is possible 
that the display controller misses the TE signal and it makes lock-up.
So I needed this patch.

> Now that you are now clearing pending_flip in the error path, you
> don't need the timeout, right?
>

There might be my missing point. Would you explain more detail?

Thank you.
Best regards YJ

> -Dan
>
>>  drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>>  }
>>
>> @@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
>> *crtc,
>>  spin_lock_irq(>event_lock);
>>  drm_vblank_put(dev, exynos_crtc->pipe);
>>  list_del(>base.link);
>> +   atomic_set(_crtc->pending_flip, 0);
>>  spin_unlock_irq(>event_lock);
>>
>>  goto out;
>> --
>> 1.7.9.5
>>
>

[PATCH v2] drm/exynos: use regmap interface to set hdmiphy control bit in pmu

[Rahul Sharma]

Hi Inki, Tomasz,

Any comment on this patch?

Regards,
Rahul Sharma

On 20 May 2014 10:36, Rahul Sharma  wrote:
> Exynos drm hdmi driver used to get dummy hdmiphy clock to
> control the PMU bit for hdmiphy. This bit needs to be set
> before setting any resolution to hdmi hardware. This was
> handled using dummy hdmiphy clock which is removed here.
>
> PMU is already defined as system controller for exynos
> SoCs. Hdmi driver is modified to control the phy enable bit
> inside PMU using regmap interfaces.
>
> Devicetree binding document for hdmi is also updated.
>
> Signed-off-by: Rahul Sharma 
> ---
> V2:
>   1) Squashed hdmiphy clock cleanup patch.
>   2) Addressed comments related to indentation, using
>  BIT macro while definnig bits and using IS_ERR check
>  while verifying regmap handle.
>
> This patch is based on exynos-drm-next branch.
>
>  .../devicetree/bindings/video/exynos_hdmi.txt  |2 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   27 
> ++--
>  drivers/gpu/drm/exynos/regs-hdmi.h |4 +++
>  3 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 75ada04..1fd8cf9 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -28,6 +28,7 @@ Required properties:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>  - ddc: phandle to the hdmi ddc node
>  - phy: phandle to the hdmi phy node
> +- samsung,syscon-phandle: phandle for system controller node for PMU.
>
>  Example:
>
> @@ -38,4 +39,5 @@ Example:
> hpd-gpio = < 7 1>;
> ddc = <_ddc_node>;
> phy = <_phy_node>;
> +   samsung,syscon-phandle = <_system_controller>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index b03e721..f5e188f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -38,6 +38,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include 
>
> @@ -81,7 +83,6 @@ struct hdmi_resources {
> struct clk  *sclk_hdmi;
> struct clk  *sclk_pixel;
> struct clk  *sclk_hdmiphy;
> -   struct clk  *hdmiphy;
> struct clk  *mout_hdmi;
> struct regulator_bulk_data  *regul_bulk;
> int regul_count;
> @@ -208,6 +209,7 @@ struct hdmi_context {
> const struct hdmiphy_config *phy_confs;
> unsigned intphy_conf_count;
>
> +   struct regmap   *pmureg;
> enum hdmi_type  type;
>  };
>
> @@ -2013,7 +2015,10 @@ static void hdmi_poweron(struct exynos_drm_display 
> *display)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> -   clk_prepare_enable(res->hdmiphy);
> +   /* set pmu hdmiphy control bit to enable hdmiphy */
> +   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> +   PMU_HDMI_PHY_ENABLE_BIT, 1);
> +
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -2040,7 +2045,11 @@ static void hdmi_poweroff(struct exynos_drm_display 
> *display)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> -   clk_disable_unprepare(res->hdmiphy);
> +
> +   /* reset pmu hdmiphy control bit to disable hdmiphy */
> +   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> +   PMU_HDMI_PHY_ENABLE_BIT, 0);
> +
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> pm_runtime_put_sync(hdata->dev);
> @@ -2143,11 +2152,6 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> -   res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> -   if (IS_ERR(res->hdmiphy)) {
> -   DRM_ERROR("failed to get clock 'hdmiphy'\n");
> -   goto fail;
> -   }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> @@ -2353,6 +2357,13 @@ static int hdmi_probe(struct platform_device *pdev)
> goto err_hdmiphy;
> }
>
> +   hdata->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> +   "samsung,syscon-phandle");
> +   if (IS_ERR(hdata->pmureg)) {
> +   DRM_ERROR("syscon regmap lookup failed.\n");
> +   goto err_hdmiphy;
> +   

[PATCH] drm/gem: remove obsolete BUG_ON

[Daniel Vetter]

On Wed, May 21, 2014 at 02:16:26PM +0200, David Herrmann wrote:
> The shmem subsystem supports relocating pages on swap-in in case it was
> loaded into the wrong zone. This was implemented 2 years ago in:
> 
> commit bde05d1ccd512696b09db9dd2e5f33ad19152605
> Author: Hugh Dickins 
> Date:   Tue May 29 15:06:38 2012 -0700
> 
> shmem: replace page if mapping excludes its zone
> 
> If a driver requires pages to be in a specific zone, they _must_ set the
> correct GFP flags (like __GFP_DMA32) in mapping_gfp_mask(mapping). shmem
> will make sure that any page leaving the swap-cache is located in a
> compatible zone.
> 
> Signed-off-by: David Herrmann 

Imo the BUG_ON is nice since we want to make sure this never blows up. We
have a similar one in i915_gem.c since we do have platforms with 32bit
limits that support more than 4G or ram.

Imo better to update the comment and state that this is fixed now, but
better be paranoid.
-Daniel
> ---
>  drivers/gpu/drm/drm_gem.c | 19 ---
>  1 file changed, 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 9909bef..a6146ab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -473,25 +473,6 @@ struct page **drm_gem_get_pages(struct drm_gem_object 
> *obj, gfp_t gfpmask)
>   if (IS_ERR(p))
>   goto fail;
>   pages[i] = p;
> -
> - /* There is a hypothetical issue w/ drivers that require
> -  * buffer memory in the low 4GB.. if the pages are un-
> -  * pinned, and swapped out, they can end up swapped back
> -  * in above 4GB.  If pages are already in memory, then
> -  * shmem_read_mapping_page_gfp will ignore the gfpmask,
> -  * even if the already in-memory page disobeys the mask.
> -  *
> -  * It is only a theoretical issue today, because none of
> -  * the devices with this limitation can be populated with
> -  * enough memory to trigger the issue.  But this BUG_ON()
> -  * is here as a reminder in case the problem with
> -  * shmem_read_mapping_page_gfp() isn't solved by the time
> -  * it does become a real issue.
> -  *
> -  * See this thread: http://lkml.org/lkml/2011/7/11/238
> -  */
> - BUG_ON((gfpmask & __GFP_DMA32) &&
> - (page_to_pfn(p) >= 0x0010UL));
>   }
>  
>   return pages;
> -- 
> 1.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #50 from Christian K?nig  ---
(In reply to comment #47)
> When using the radeon.lockup_timeout=0 eglinfo (and every other egl apps)
> never finishes, probably waiting for a fence, but I still can switch tty.

That was expected, it probably just waits forever for some results.

> That's with kernel 3.12+ (otoh with 3.14.3 if I try to run a egl app, I have
> garbage on display and my monitor shutdown, and is never brought up, there
> is probably others issues introduced after hawaii commit as suggested)

That's why I suggested to work over the network, trying to debug gfx hardware
while the hardware is in use (e.g. it's your output device for debug messages)
is usually pointless.

> The radeon_fence_info are the same between several run.

Yeah, and the values are pretty interesting:

--- ring 0 ---
Last signaled fence 0x0001
Last emitted0x0002
...
Last sync to ring 3 0x0009

--- ring 3 ---
Last signaled fence 0x0001
Last emitted0x0009

Ring 0 is the 3D engine, ring 3 is the DMA engine. What we see here is that we
submitted some commands to the DMA engine which then got stuck.

The 3D engine is just waiting for the DMA to continue as well.

Try to load the radeon module with radeon.test=3 on the kernel command line
(keep in mind that this can take a while and will probably crash as well).

-- 
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/20140521/4cf7e204/attachment-0001.html>

[PATCH 11/12] [RFC] drm/irq: More robustness in drm_vblank_on|off

[Daniel Vetter]

On Wed, May 21, 2014 at 02:53:00PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> > If we want to use this functionality in generic helpers to make
> > sure that all drivers have somewhat sane vblank handling across
> > modesets/dpms, we need to make it work for all drivers. But some
> > don't support interrupts and hence also not vblank waits.
> > 
> > Just return early on such drivers.
> > 
> > Note that with pageflips drivers are free to implement them however
> > they wish to.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> I'm confused. This seems to be the very same patch as 09/12. But since
> you've already merged this I guess it must have resolved itself
> somehow...

Screwed up the patch sending and submitted two patch 09/12. This one
really is just rfc and I didn't pull it in yet.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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

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

--- Comment #26 from Michel D?nzer  ---
(In reply to comment #25)
>  In comparation with fglrx, radeon have blackiness with some lighting
> invilved :).

Does it look different from radeonsi with any other Mesa driver? E.g. Unigine
might use the GL_ARB_shadow_ambient extension, which is supported by fglrx but
not by Mesa.


Please realize that 'black pixels' is not specific enough to characterize a
single bug. This report is getting unmanageable, please track issues in
separate apps in separate reports and stop mixing in more here.

-- 
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/20140521/02e8b5ff/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #49 from vincent  ---
Do you know which commits I should cherry-pick ?

-- 
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/20140521/57802969/attachment.html>

[PATCH 00/12] irq vblank handling rework

[Thierry Reding]

On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrj?l? wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrj?l? 
> > 
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> > sane but I didn't go reading through the drivers to figure out if they
> > would fall over or work.
> 
> Oh, the rfc was really just that. I don't have any plans to burn my hands
> trying to merge those patches ;-) Especially since interest from non-i915
> hackers seems to be low.

I think that's mostly because nobody except i915 has a testsuite that
would even remotely be able to uncover any of these issues. =)

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

[PATCH 11/12] [RFC] drm/irq: More robustness in drm_vblank_on|off

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> If we want to use this functionality in generic helpers to make
> sure that all drivers have somewhat sane vblank handling across
> modesets/dpms, we need to make it work for all drivers. But some
> don't support interrupts and hence also not vblank waits.
> 
> Just return early on such drivers.
> 
> Note that with pageflips drivers are free to implement them however
> they wish to.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 6 ++
>  1 file changed, 6 insertions(+)

I'm confused. This seems to be the very same patch as 09/12. But since
you've already merged this I guess it must have resolved itself
somehow...

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

[PATCH 09/12] drm/irq: Lack of interrupt support in drm_vblank_on|off

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:12PM +0200, Daniel Vetter wrote:
> If we want to use this functionality in generic helpers to make
> sure that all drivers have somewhat sane vblank handling across
> modesets/dpms, we need to make it work for all drivers. But some
> don't support interrupts and hence also not vblank waits.
> 
> Just return early on such drivers.
> 
> Note that with pageflips drivers are free to implement them however
> they wish to.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 6 ++
>  1 file changed, 6 insertions(+)

Reviewed-by: Thierry Reding 
-- 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/20140521/a554a5fa/attachment.sig>

[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

[Thierry Reding]

On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof. So let's rip it all out.
> 
> Hmm. drm_update_vblank_count() will now see some kind of diff between
> the last and current value when the registers got cloberred. So the
> vblank counter reported to userspace will jump. But I guess that's fine
> as long as userspace realizes that the counter is not at all reliable
> across modesets.

I think that's a fair assumption. Modeset is kind of a heavy operation
and I wouldn't expect applications to perform one all that often. That
should be even more true of applications that rely on the counters. At
least that would be my expectation.

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

[PATCH v2 02/18] drm/exynos: use wait_event_timeout() for safety usage

[Daniel Kurtz]

On Wed, May 21, 2014 at 2:28 PM, YoungJun Cho  wrote:
> Hi Daniel
>
>
> On 05/21/2014 03:01 PM, Daniel Kurtz wrote:
>>
>> On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho 
>> wrote:
>>>
>>> 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.
>>> And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip() when
>>> exynos_drm_crtc_mode_set_commit() is failed.
>>>
>>> Signed-off-by: YoungJun Cho 
>>> Acked-by: Inki Dae 
>>> Acked-by: Kyungmin Park 
>>> ---
>>>   drivers/gpu/drm/exynos/exynos_drm_crtc.c |7 +--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index 95c9435..3bf091d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -69,8 +69,10 @@ 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);
>>> +   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>>> +   !atomic_read(_crtc->pending_flip),
>>> +   HZ/20))
>>> +   atomic_set(_crtc->pending_flip, 0);
>>
>>
>> I meant that changing this to wait_event_timeout() seems to be masking
>> the original problem, that pending_flip wasn't being cleared.
>
>
> Yes, I agree.
>
> The original purpose of this patch is to avoid lock-up during modetest (with
> test_vsync) with command mode panel.
> In MIPI DSI command mode interface, the display controller can not generate
> VSYNC signal and uses TE signal instead which is generated by panel.
> If there is an abnormal power off or reset condition, it is possible that
> the display controller misses the TE signal and it makes lock-up.
> So I needed this patch.

If flips are not completing on MIPI DSI, may I recommend that you
start a timer when scheduling such a flip in the MIPI DSI driver that
will expire after a timeout.  In that timer's expiration handler, you
can then go through the normal process of completing a flip.  This
would make the timeout transparent to the generic exynos_drm_crtc
layer, which can then do its normal flip complete processing: send
pending vblank events, put vblank, clear pending_flip, etc.
Does that make sense?
Is it possible?

-Dan

>> Now that you are now clearing pending_flip in the error path, you
>> don't need the timeout, right?
>>
>
> There might be my missing point. Would you explain more detail?
>
>
> Thank you.
> Best regards YJ
>
>> -Dan
>>
>>>  drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>>>  }
>>>
>>> @@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
>>> *crtc,
>>>  spin_lock_irq(>event_lock);
>>>  drm_vblank_put(dev, exynos_crtc->pipe);
>>>  list_del(>base.link);
>>> +   atomic_set(_crtc->pending_flip, 0);
>>>  spin_unlock_irq(>event_lock);
>>>
>>>  goto out;
>>> --
>>> 1.7.9.5
>>>
>>
>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #48 from Michel D?nzer  ---
(In reply to comment #42)
> There is only one buffer_map(READ), in si_get_backend_mask, right after the
> buffer_map(WRITE) from si_get_backend_mask.

Please make sure the kernel has the commit(s) necessary to provide the backend
mask to userspace, so si_get_backend_mask() doesn't need to fall back to this
method.

-- 
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/20140521/3c85e774/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #47 from vincent  ---
When using the radeon.lockup_timeout=0 eglinfo (and every other egl apps) never
finishes, probably waiting for a fence, but I still can switch tty. That's with
kernel 3.12+ (otoh with 3.14.3 if I try to run a egl app, I have garbage on
display and my monitor shutdown, and is never brought up, there is probably
others issues introduced after hawaii commit as suggested)

The radeon_fence_info are the same between several run.

-- 
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/20140521/d3f7bb41/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #46 from vincent  ---
Created attachment 99513
  --> https://bugs.freedesktop.org/attachment.cgi?id=99513=edit
radeon_fence_info with egl second run

-- 
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/20140521/b31b3250/attachment-0001.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #45 from vincent  ---
Created attachment 99512
  --> https://bugs.freedesktop.org/attachment.cgi?id=99512=edit
radeon_fence_info with egl first run

-- 
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/20140521/948df6f7/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #44 from vincent  ---
Created attachment 99511
  --> https://bugs.freedesktop.org/attachment.cgi?id=99511=edit
radeon_fence_info before running eglinfo

-- 
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/20140521/7c88724d/attachment.html>

[PATCH] drm/gem: remove obsolete BUG_ON

[David Herrmann]

The shmem subsystem supports relocating pages on swap-in in case it was
loaded into the wrong zone. This was implemented 2 years ago in:

commit bde05d1ccd512696b09db9dd2e5f33ad19152605
Author: Hugh Dickins 
Date:   Tue May 29 15:06:38 2012 -0700

shmem: replace page if mapping excludes its zone

If a driver requires pages to be in a specific zone, they _must_ set the
correct GFP flags (like __GFP_DMA32) in mapping_gfp_mask(mapping). shmem
will make sure that any page leaving the swap-cache is located in a
compatible zone.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_gem.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9909bef..a6146ab 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -473,25 +473,6 @@ struct page **drm_gem_get_pages(struct drm_gem_object 
*obj, gfp_t gfpmask)
if (IS_ERR(p))
goto fail;
pages[i] = p;
-
-   /* There is a hypothetical issue w/ drivers that require
-* buffer memory in the low 4GB.. if the pages are un-
-* pinned, and swapped out, they can end up swapped back
-* in above 4GB.  If pages are already in memory, then
-* shmem_read_mapping_page_gfp will ignore the gfpmask,
-* even if the already in-memory page disobeys the mask.
-*
-* It is only a theoretical issue today, because none of
-* the devices with this limitation can be populated with
-* enough memory to trigger the issue.  But this BUG_ON()
-* is here as a reminder in case the problem with
-* shmem_read_mapping_page_gfp() isn't solved by the time
-* it does become a real issue.
-*
-* See this thread: http://lkml.org/lkml/2011/7/11/238
-*/
-   BUG_ON((gfpmask & __GFP_DMA32) &&
-   (page_to_pfn(p) >= 0x0010UL));
}

return pages;
-- 
1.9.3

[PATCH 04/12] drm: Add drm_vblank_on()

[Daniel Vetter]

On Wed, May 21, 2014 at 01:32:35PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> > From: Ville Syrj?l? 
> > 
> > drm_vblank_off() will turn off vblank interrupts, but as long as the
> > refcount is elevated drm_vblank_get() will not re-enable them. This
> > is a problem is someone is holding a vblank reference while a modeset is
> > happening, and the driver requires vblank interrupt to work during that
> > time.
> > 
> > Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
> > re-enabled vblank interrupts if the refcount is already elevated. This
> > will allow drivers to choose the specific places in the modeset sequence
> > at which vblank interrupts get disabled and enabled.
> > 
> > Testcase: igt/kms_flip/*-vs-suspend
> > Signed-off-by: Ville Syrj?l? 
> > [danvet: Add Testcase tag for the igt I've written.]
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_irq.c| 72 
> > ++--
> >  drivers/gpu/drm/i915/intel_display.c |  8 
> >  include/drm/drmP.h   |  1 +
> >  3 files changed, 62 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 13d671ed3421..dd786d84daab 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -840,6 +840,41 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, int crtc)
> >  }
> >  
> >  /**
> > + * drm_vblank_enable - enable the vblank interrupt on a CRTC
> > + * @dev: DRM device
> > + * @crtc: CRTC in question
> > + */
> 
> Perhaps the kernel-doc here should contain some of what's described in
> the commit message? Also a "Return:" section would be useful here to
> specify what's an error and what isn't.
> 
> > +static int drm_vblank_enable(struct drm_device *dev, int crtc)
> 
> On second thought, since this is a local function, my comments above
> apply to drm_vblank_on() below rather than drm_vblank_enable().

Yeah, we don't pull this into the kerneldoc, only functions exported to
drivers. Follow-up patch should (hopefully) sufficiently pimp the
kerneldoc for drm_vblank_on. If not please complain.

> 
> > +{
> > +   int ret = 0;
> > +
> > +   assert_spin_locked(>vbl_lock);
> > +
> > +   spin_lock(>vblank_time_lock);
> > +
> > +   if (!dev->vblank[crtc].enabled) {
> > +   /* Enable vblank irqs under vblank_time_lock protection.
> > +* All vblank count & timestamp updates are held off
> > +* until we are done reinitializing master counter and
> > +* timestamps. Filtercode in drm_handle_vblank() will
> > +* prevent double-accounting of same vblank interval.
> > +*/
> 
> Coding style:
> 
>   /*
>* Enable...
>*/
> 
> ?

Yeah, will polish.
> 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> 
> Perhaps split off the i915 changes into a separate patch?

Yeah, should have. But I've got fed up with the conflicts this topic
branch caused so pulled it in. I'll apply your review feedback as
follow-up patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 02/12] drm: Make the vblank disable timer per-crtc

[Daniel Vetter]

On Wed, May 21, 2014 at 01:17:49PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:04PM +0200, Daniel Vetter wrote:
> > From: Ville Syrj?l? 
> > 
> > Currently there's one per-device vblank disable timer, and it gets
> > reset wheneven the vblank refcount for any crtc drops to zero. That
> 
> "whenever"
> 
> > means that one crtc could accidentally be keeping the vblank interrupts
> > for other crtcs enabled even if there are no users for them. Make the
> > disable timer per-crtc to avoid this issue.
> 
> Very pedantically: s/crtc/CRTC/ and maybe even s/vblank/VBLANK/. Feel
> free to ignore those, though. =)
> 
> Also, and I may have asked before, why do we even need this timer? Why
> not simply disable interrupts when the last vblank reference goes away?

Without intricate knowledge of where exactly the vblank interrupt fires
wrt the hw frame counter the enabling/disabling of the vblank machinery as
implemented in drm_irq.c is racy. Which means we shouldn't do it all the
time.

In i915 we are now solid enough with vblank handling in general and also
well-covered in tests that we'll attempt to kill the disabling timer as
the next step. Since keeping vblanks going when we don't need them if you
have a hw vblank counter seriously hampers deep sleep states residency.

But given how bug-riddled our vblank code was I want to move slowly. And
we need to keep the hack for all those drivers which haven't properly been
audited and tested (i.e. everyone else).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 02/18] drm/exynos: use wait_event_timeout() for safety usage

[Daniel Kurtz]

On Wed, May 21, 2014 at 12:42 PM, YoungJun Cho  wrote:
> 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.
> And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip() when
> exynos_drm_crtc_mode_set_commit() is failed.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 95c9435..3bf091d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -69,8 +69,10 @@ 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);
> +   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
> +   !atomic_read(_crtc->pending_flip),
> +   HZ/20))
> +   atomic_set(_crtc->pending_flip, 0);

I meant that changing this to wait_event_timeout() seems to be masking
the original problem, that pending_flip wasn't being cleared.
Now that you are now clearing pending_flip in the error path, you
don't need the timeout, right?

-Dan

> drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> }
>
> @@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
> *crtc,
> spin_lock_irq(>event_lock);
> drm_vblank_put(dev, exynos_crtc->pipe);
> list_del(>base.link);
> +   atomic_set(_crtc->pending_flip, 0);
> spin_unlock_irq(>event_lock);
>
> goto out;
> --
> 1.7.9.5
>

[PATCH v2 18/18] ARM: dts: exynos5420: add dsi node

[YoungJun Cho]

This patch adds common part of dsi node.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-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 6fde5fd..43b6852 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -478,6 +478,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 = < CLK_DSIM1>, < CLK_SCLK_MIPI1>;
+   clock-names = "bus_clk", "pll_clk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
fimd at 1440 {
samsung,power-domain = <_pd>;
clocks = < CLK_SCLK_FIMD1>, < CLK_FIMD1>;
-- 
1.7.9.5

[PATCH v2 17/18] ARM: dts: exynos5420: add mipi-phy node

[YoungJun Cho]

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

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-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 c3a9a66..6fde5fd 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -472,6 +472,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 = < CLK_SCLK_FIMD1>, < CLK_FIMD1>;
-- 
1.7.9.5

[PATCH v2 16/18] 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 
Acked-by: Inki Dae 
Acked-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 79d0608..95ee496 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -81,12 +81,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

[PATCH v2 15/18] 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 
Acked-by: Inki Dae 
Acked-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 2f8bcd0..abfcbe2 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -534,6 +534,7 @@
clocks = < CLK_SCLK_FIMD0>, < CLK_FIMD0>;
clock-names = "sclk_fimd", "fimd";
samsung,power-domain = <_lcd0>;
+   samsung,sysreg = <_reg>;
status = "disabled";
};
 };
-- 
1.7.9.5

[PATCH v2 14/18] 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 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c |  568 +
 3 files changed, 576 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..fa51237 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 CMDMODE_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..da73916
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,568 @@
+/*
+ * 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 
+
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER   0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT   0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL   0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM   0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1   0xf0
+#define MCS_PANEL_UPDATE   0xf7
+#define MCS_KEY_LEV2   0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL   0x15
+
+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;
+   struct cmdmode  cm;
+
+   unsigned intpower_on_delay;
+   unsigned intreset_delay;
+   unsigned intinit_delay;
+   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)
+
+/* VDD Memory Lookup Table contains pairs of {ReadValue, WriteValue} */
+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, 

[PATCH v2 13/18] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   45 
 1 file changed, 45 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..c9a3fbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,45 @@
+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-gpios: a GPIO spec for the reset pin
+  - det-gpios: a GPIO spec for the OLED detection pin
+  - te-gpios: a GPIO spec for the TE pin
+  - cmdmode-display-timings: command mode interface timings for the connected
+  panel as described by [1]
+
+Optional properties:
+
+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/cmdmode-display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel at 0 {
+   compatible = "samsung,s6e3fa0";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 4 0>;
+   det-gpios = < 6 0>;
+   te-gpios = < 7 0>;
+
+   cmdmode-display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <1080>;
+   vactive = <1920>;
+   cs-setup = <0>;
+   wr-setup = <0>;
+   wr-active = <1>;
+   wr-hold = <0>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v2 12/18] 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 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  157 ++-
 1 file changed, 135 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 783d7a5..35d636b 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 
 #include 
@@ -55,9 +56,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)
@@ -201,6 +205,24 @@
 #define DSIM_PLL_M(x)  ((x) << 4)
 #define DSIM_PLL_S(x)  ((x) << 1)

+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x)  (((x) & 0x1ff) << 0)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x)  ((x) << 8)
+#define DSIM_PHYTIMING_HS_EXIT(x)  ((x) << 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) << 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) << 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) << 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x)   ((x) << 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x)  ((x) << 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) << 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) << 0)
+
 #define DSI_MAX_BUS_WIDTH  4
 #define DSI_NUM_VIRTUAL_CHANNELS   4
 #define DSI_TX_FIFO_SIZE   2048
@@ -234,6 +256,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;
@@ -263,11 +291,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)))
@@ -341,14 +397,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;
@@ -369,18 +420,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); 

[PATCH v2 11/18] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings

[YoungJun Cho]

This patch adds relevant to exynos5420 compatible for exynos5420 SoC support.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-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..29bf3b2 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 SoCs */
   - 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

[PATCH v2 10/18] drm/exynos: fimd: support I80 interface

[YoungJun Cho]

To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
  page flip request, and implements TE handler to call trigger function.
- Sets command mode timings configuration.
- Sets ideal(pixel) clock is 2 times faster than the original one to
  generate frame done IRQ prior to the next TE signal.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig   |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |  277 +-
 include/video/samsung_fimd.h |3 +-
 3 files changed, 237 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_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 173ee97..9d585f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,11 +20,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
 #include 
 #include 
+#include 

 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
@@ -60,6 +63,24 @@
 /* color key value register for hardware window 1 ~ 4. */
 #define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))

+/* i80 / RGB trigger control register */
+#define TRIGCON0x1A4
+#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
+#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON 0x000
+#define VIDOUT_CON_F_I80_LDI0  (0x2 << 8)
+
+/* i80 interface control for main LDI register */
+#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
+#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)((x) << 16)
+#define LCD_WR_SETUP(x)((x) << 12)
+#define LCD_WR_ACT(x)  ((x) << 8)
+#define LCD_WR_HOLD(x) ((x) << 4)
+#define I80IFEN_ENABLE (1 << 0)
+
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5

@@ -67,10 +88,14 @@

 struct fimd_driver_data {
unsigned int timing_base;
+   unsigned int lcdblk_off;
+   unsigned int lcdblk_vt_shift;
+   unsigned int lcdblk_bypass_shift;

unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+   unsigned int has_vidoutcon:1;
 };

 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -81,12 +106,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {

 static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
+   .lcdblk_off = 0x210,
+   .lcdblk_vt_shift = 10,
+   .lcdblk_bypass_shift = 1,
.has_shadowcon = 1,
 };

 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
+   .lcdblk_off = 0x214,
+   .lcdblk_vt_shift = 24,
+   .lcdblk_bypass_shift = 15,
.has_shadowcon = 1,
+   .has_vidoutcon = 1,
 };

 struct fimd_win_data {
@@ -111,15 +143,23 @@ struct fimd_context {
struct clk  *bus_clk;
struct clk  *lcd_clk;
void __iomem*regs;
+   struct regmap   *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long   irq_flags;
+   u32 vidcon0;
u32 vidcon1;
+   u32 vidout_con;
+   u32 i80ifcon;
+   booli80_if;
boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
+   atomic_twin_updated;
+   atomic_ttriggering;
+   spinlock_t  win_updated_lock;

struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
@@ -242,6 +282,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * 

[PATCH v2 09/18] drm/exynos: dsi: add TE handler to support command mode interface

[YoungJun Cho]

To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 0a4e3ce..783d7a5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -24,6 +24,7 @@
 #include 
 #include 

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

 /* returns true iff both arguments logically differs */
@@ -1033,10 +1034,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)
-- 
1.7.9.5

[PATCH v2 08/18] drm/exynos: add TE handler to support MIPI DSI command mode interface

[YoungJun Cho]

To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
to notify it to the display controller.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |3 +++
 include/drm/drm_mipi_dsi.h   |8 
 4 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 3bf091d..504e023 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -511,3 +511,14 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device 
*drm_dev,

return -EPERM;
 }
+
+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 9f74b10..875d93d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -36,4 +36,11 @@ void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, 
int zpos);
 int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);

+/*
+ * This function calls the crtc device(manager)'s te_handler() callback
+ * to trigger to transfer video image at the tearing effect synchronization
+ * signal.
+ */
+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 e82e620..54b08d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -181,6 +181,8 @@ 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: trigger to transfer video image at the tearing effect
+ * synchronization signal if there is a page flip request.
  */
 struct exynos_drm_manager;
 struct exynos_drm_manager_ops {
@@ -199,6 +201,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/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df1..f6d4c85 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,13 @@ struct mipi_dsi_msg {
  * @detach: detach DSI device from DSI host
  * @transfer: send and/or receive DSI packet, return number of received bytes,
  *   or error
+ * @te_handler: call the crtc te_handler() callback from DSI host.
+ * The panel generates tearing effect synchronization signal
+ * between MCU and FB to display video images.
+ * And the display controller should trigger to transfer video
+ * image at this signal.
+ * So the panel receives the TE IRQ, then calls this handler
+ * to notify it to the display controller.
  */
 struct mipi_dsi_host_ops {
int (*attach)(struct mipi_dsi_host *host,
@@ -57,6 +64,7 @@ struct mipi_dsi_host_ops {
  struct mipi_dsi_device *dsi);
ssize_t (*transfer)(struct mipi_dsi_host *host,
struct mipi_dsi_msg *msg);
+   int (*te_handler)(struct mipi_dsi_host *host);
 };

 /**
-- 
1.7.9.5

[PATCH v2 07/18] ARM: dts: samsung-fimd: add I80 specific properties

[YoungJun Cho]

In case of using MIPI command mode interface panel,
the relevant registers should be set.
So this patch adds relevant DT bindings.

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

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..6bf93e9 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,8 @@ Optional Properties:
 - display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
+- samsung,sysreg: handle to syscon used to control the system registers
+- vidout-i80-ldi: boolean to support i80 interface instead of rgb one

 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

[PATCH v2 06/18] ARM: dts: sysreg: add exynos5 compatible to DT bindings

[YoungJun Cho]

This patch adds relevant to exynos5 compatible for exynos5 SoCs.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-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

[PATCH v2 05/18] drm_modes: add command mode helpers

[YoungJun Cho]

This patch adds helper functions to convert cmdmode
to drm_display_mode

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/drm_modes.c |   59 +++
 include/drm/drm_modes.h |   12 +
 2 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index bedf189..8977381 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -37,6 +37,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 

 #include "drm_crtc_internal.h"
@@ -651,6 +653,63 @@ EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
 #endif /* CONFIG_OF */
 #endif /* CONFIG_VIDEOMODE_HELPERS */

+#ifdef CONFIG_CMDMODE_HELPERS
+int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+   struct drm_display_mode *dmode)
+{
+   dmode->hdisplay = cm->hactive;
+   dmode->htotal = dmode->hsync_end = dmode->hsync_start = dmode->hdisplay;
+
+   dmode->vdisplay = cm->vactive;
+   dmode->vtotal = dmode->vsync_end = dmode->vsync_start = dmode->vdisplay;
+
+   dmode->clock = cm->pixelclock / 1000;
+
+   dmode->cs_setup = cm->cs_setup;
+   dmode->wr_setup = cm->wr_setup;
+   dmode->wr_active = cm->wr_active;
+   dmode->wr_hold = cm->wr_hold;
+
+   dmode->flags = 0;
+   drm_mode_set_name(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_cmdmode);
+
+#ifdef CONFIG_OF
+/**
+ * of_get_drm_cmdmode_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to 
be
+ * read from DT. To get multiple modes start with
+ * of_get_cmdmode_display_timings and work with that instead.
+ */
+int of_get_drm_cmdmode_display_mode(struct device_node *np,
+   struct drm_display_mode *dmode, int index)
+{
+   struct cmdmode cm;
+   int ret;
+
+   ret = of_get_cmdmode(np, , index);
+   if (ret)
+   return ret;
+
+   drm_display_mode_from_cmdmode(, dmode);
+
+   pr_debug("%s: got %dx%d display mode from %s\n",
+   of_node_full_name(np), cm.hactive, cm.vactive, np->name);
+   drm_mode_debug_printmodeline(dmode);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_cmdmode_display_mode);
+#endif /* CONFIG_OF */
+#endif /* CONFIG_CMDMODE_HELPERS */
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..0d29754 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -144,6 +144,12 @@ struct drm_display_mode {
int vrefresh;   /* in Hz */
int hsync;  /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+
+   /* Command mode info - refers to video/cmdmode.h */
+   int cs_setup;
+   int wr_setup;
+   int wr_active;
+   int wr_hold;
 };

 /* mode specified on the command line */
@@ -176,6 +182,7 @@ static inline bool drm_mode_is_stereo(const struct 
drm_display_mode *mode)

 struct drm_connector;
 struct drm_cmdline_mode;
+struct cmdmode;

 struct drm_display_mode *drm_mode_create(struct drm_device *dev);
 void drm_mode_destroy(struct drm_device *dev, struct drm_display_mode *mode);
@@ -200,6 +207,11 @@ void drm_display_mode_from_videomode(const struct 
videomode *vm,
 int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode,
int index);
+extern int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+  struct drm_display_mode *dmode);
+extern int of_get_drm_cmdmode_display_mode(struct device_node *np,
+  struct drm_display_mode *dmode,
+  int index);

 void drm_mode_set_name(struct drm_display_mode *mode);
 int drm_mode_hsync(const struct drm_display_mode *mode);
-- 
1.7.9.5

[PATCH v2 04/18] video: add command mode and command mode display timing

[YoungJun Cho]

This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_display_timing struct and
the according helper functions to convert cmdmode_display_timing
to a generic cmdmode.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/video/Kconfig |3 +
 drivers/video/Makefile|2 +
 drivers/video/cmdmode.c   |   42 ++
 drivers/video/cmdmode_display_timing.c|   26 
 drivers/video/of_cmdmode.c|   55 
 drivers/video/of_cmdmode_display_timing.c |  212 +
 include/video/cmdmode.h   |   67 +
 include/video/cmdmode_display_timing.h|   59 
 include/video/of_cmdmode.h|   19 +++
 include/video/of_cmdmode_display_timing.h |   26 
 10 files changed, 511 insertions(+)
 create mode 100644 drivers/video/cmdmode.c
 create mode 100644 drivers/video/cmdmode_display_timing.c
 create mode 100644 drivers/video/of_cmdmode.c
 create mode 100644 drivers/video/of_cmdmode_display_timing.c
 create mode 100644 include/video/cmdmode.h
 create mode 100644 include/video/cmdmode_display_timing.h
 create mode 100644 include/video/of_cmdmode.h
 create mode 100644 include/video/of_cmdmode_display_timing.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c7b4f0f..7090ee5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -38,6 +38,9 @@ config VGASTATE
 config VIDEOMODE_HELPERS
bool

+config CMDMODE_HELPERS
+   bool
+
 config HDMI
bool

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..619dd99 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -8,6 +8,8 @@ obj-y += backlight/
 obj-y+= fbdev/

 obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += cmdmode_display_timing.o cmdmode.o
 ifeq ($(CONFIG_OF),y)
 obj-$(CONFIG_VIDEOMODE_HELPERS) += of_display_timing.o of_videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += of_cmdmode_display_timing.o of_cmdmode.o
 endif
diff --git a/drivers/video/cmdmode.c b/drivers/video/cmdmode.c
new file mode 100644
index 000..3d3eeb8
--- /dev/null
+++ b/drivers/video/cmdmode.c
@@ -0,0 +1,42 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 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 
+
+void cmdmode_from_timing(const struct cmdmode_display_timing *cmdt,
+   struct cmdmode *cm)
+{
+   cm->pixelclock = cmdt->pixelclock;
+   cm->hactive = cmdt->hactive;
+   cm->vactive = cmdt->vactive;
+   cm->cs_setup = cmdt->cs_setup;
+   cm->wr_setup = cmdt->wr_setup;
+   cm->wr_active = cmdt->wr_active;
+   cm->wr_hold = cmdt->wr_hold;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timing);
+
+int cmdmode_from_timings(const struct cmdmode_display_timings *cmdts,
+   struct cmdmode *cm, unsigned int index)
+{
+   struct cmdmode_display_timing *cmdt;
+
+   cmdt = cmdmode_display_timings_get(cmdts, index);
+   if (!cmdt)
+   return -EINVAL;
+
+   cmdmode_from_timing(cmdt, cm);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timings);
diff --git a/drivers/video/cmdmode_display_timing.c 
b/drivers/video/cmdmode_display_timing.c
new file mode 100644
index 000..88bab08
--- /dev/null
+++ b/drivers/video/cmdmode_display_timing.c
@@ -0,0 +1,26 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 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 
+
+void cmdmode_display_timings_release(struct cmdmode_display_timings *cmdts)
+{
+   if (cmdts->timings) {
+   unsigned int i;
+
+   for (i = 0; i < cmdts->num_timings; i++)
+   kfree(cmdts->timings[i]);
+   kfree(cmdts->timings);
+   }
+   kfree(cmdts);
+}
+EXPORT_SYMBOL_GPL(cmdmode_display_timings_release);
diff --git a/drivers/video/of_cmdmode.c b/drivers/video/of_cmdmode.c
new file mode 100644
index 000..d63294e
--- /dev/null
+++ b/drivers/video/of_cmdmode.c
@@ -0,0 +1,55 @@
+/*
+ * generic cmdmode helper
+ *
+ * Copyright (c) 2014 YoungJun Cho 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under 

[PATCH v2 03/18] ARM: dts: video: add command mode display timing DT bindings

[YoungJun Cho]

This patch adds DT bindings for command mode display timing.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 .../bindings/video/cmdmode-display-timing.txt  |   64 
 1 file changed, 64 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/cmdmode-display-timing.txt

diff --git a/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt 
b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
new file mode 100644
index 000..7cedfe4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
@@ -0,0 +1,64 @@
+cmdmode-display-timing bindings
+===
+
+cmdmode-display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+   provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - clock-frequency: display clock in Hz
+ - hactive, vactive: display resolution
+ - cs-setup: clock cycles for the active period of address signal is enabled
+   until chip select is enabled.
+ - wr-setup: clock cycles for the active period of CS signal is enabled until
+   write signal is enabled.
+ - wr-active: clock cycles for the active period of CS is enabled.
+ - wr-hold: clock cycles for the active period of CS is disabled until write
+   signal is disabled.
+
+optional properties:
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+  VCLK(internal)  __|??|_|??|_|??|_|??|_|??
+:::::
+  Address Output  --:|:::
+  Chip Select ???|::|??
+ | WR-SETUP+1 || WR-HOLD+1  |
+ |<-->||<-->|
+  Write Enable||???
+  | WR-ACTIVE+1|
+  |<-->|
+  Video Data  --
+
+Example:
+
+   cmdmode-display-timings {
+   native-mode = <>;
+   timing0: 1080p24 {
+   /* 1920x1080p24 */
+   clock-frequency = <5200>;
+   hactive = <1920>;
+   vactive = <1080>;
+   cs-setup = <0>;
+   wr-setup = <0>;
+   wr-active = <1>;
+   wr-hold = <0>;
+   };
+   };
-- 
1.7.9.5

[PATCH v2 02/18] 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.
And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip() when
exynos_drm_crtc_mode_set_commit() is failed.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..3bf091d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,10 @@ 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);
+   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
+   !atomic_read(_crtc->pending_flip),
+   HZ/20))
+   atomic_set(_crtc->pending_flip, 0);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}

@@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(>event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(>base.link);
+   atomic_set(_crtc->pending_flip, 0);
spin_unlock_irq(>event_lock);

goto out;
-- 
1.7.9.5

[PATCH v2 01/18] 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 
Acked-by: Inki Dae 
Acked-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 84661fe..0a4e3ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -473,8 +473,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)
@@ -491,6 +489,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

[PATCH v2 00/18] drm/exynos: support MIPI DSI command mode display

[YoungJun Cho]

Hi,

This series is for the Exynos DRM driver to support MIPI DSI command mode
display and based on exynos-drm-next branch.

The previous patches,
RFC: http://www.spinics.net/lists/dri-devel/msg58898.html
V1: http://www.spinics.net/lists/dri-devel/msg59291.html

Changelog v2:
- Rebases for latest exynos-drm-next branch
- Fixes typo and removes unnecessary error log (commented by Andrzej Hazda)
- Adds missed pendlig_flip flag clear points (commented by Daniel Kurtz)

Patches 1 and 2 fix trivial bugs.

Patches 3 and 4 introduce command mode and command mode display timing.
These are based on video mode and (video mode) display timing.
The MIPI DSI command mode interface panel does not require (video mode) display
timing, but it requires signal timings to distinguish command data and video
data so command mode and command mode display timing are used for it.

Patch 5 converts command mode to drm display mode.

Patches 6, 7, 8, 9 and 10 implement FIMD(display controller) I80 interface.
The MIPI DSI command mode interface panel generates Tearing Effect
synchronization signal between MCU and FB to display video image,
and FIMD should trigger to transfer video image at this signal.
So the panel should receive the TE IRQ then calls TE handler chains to notify
it to the FIMD.

Patches 11 and 12 implement to use Exynos5420 SoC DSI driver which is different
from previous Exynos4 SoCs for some registers control.

Patches 13 and 14 introduce MIPI DSI command interface Samsung S6E3FA0 AMOLED
5.7" LCD panel driver.

Patch 15 is device tree source file for Exynos4 SoCs to support MIPI DSI
command mode.

The others are device tree source files for Exynos5420 to support MIPI DSI
(command mode) driver.

I welcome any comments.

Thank you.
Best regards YJ

YoungJun Cho (18):
  drm/exynos: dsi: move the EoT packets configuration point
  drm/exynos: use wait_event_timeout() for safety usage
  ARM: dts: video: add command mode display timing DT bindings
  video: add command mode and command mode display timing
  drm_modes: add command mode helpers
  ARM: dts: sysreg: add exynos5 compatible to DT bindings
  ARM: dts: samsung-fimd: add I80 specific properties
  drm/exynos: add TE handler to support MIPI DSI command mode interface
  drm/exynos: dsi: add TE handler to support command mode interface
  drm/exynos: fimd: support I80 interface
  ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings
  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  |   45 ++
 .../bindings/video/cmdmode-display-timing.txt  |   64 +++
 .../devicetree/bindings/video/exynos_dsim.txt  |4 +-
 .../devicetree/bindings/video/samsung-fimd.txt |2 +
 arch/arm/boot/dts/exynos4.dtsi |1 +
 arch/arm/boot/dts/exynos5.dtsi |6 +
 arch/arm/boot/dts/exynos5420.dtsi  |   20 +
 drivers/gpu/drm/drm_modes.c|   59 ++
 drivers/gpu/drm/exynos/Kconfig |1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |7 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|3 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  175 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  277 --
 drivers/gpu/drm/panel/Kconfig  |7 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c  |  568 
 drivers/video/Kconfig  |3 +
 drivers/video/Makefile |2 +
 drivers/video/cmdmode.c|   42 ++
 drivers/video/cmdmode_display_timing.c |   26 +
 drivers/video/of_cmdmode.c |   55 ++
 drivers/video/of_cmdmode_display_timing.c  |  212 
 include/drm/drm_mipi_dsi.h |8 +
 include/drm/drm_modes.h|   12 +
 include/video/cmdmode.h|   67 +++
 include/video/cmdmode_display_timing.h |   59 ++
 include/video/of_cmdmode.h |   19 +
 include/video/of_cmdmode_display_timing.h  |   26 +
 include/video/samsung_fimd.h   |3 +-
 31 files changed, 1722 insertions(+), 71 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 create mode 100644 
Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
 create mode 100644 drivers/video/cmdmode.c
 create 

[PATCH 05/12] drm/i915: Remove drm_vblank_pre/post_modeset calls

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:07PM +0200, Daniel Vetter wrote:
> Originally these functions have been for user modesetting drivers to
> ensure vblank processing doesn't fall over completely around modeset
> changes. This has been carried over ever since then.
> 
> Now that Ville cleaned our vblank handling with an explicit
> drm_vblank_off/on braket when disabling/enabling crtcs. So this seems

s/braket/bracket/

> to be unnecessary now.

Should we document that drivers should start converting to this new set
of functions? Maybe deprecate the drm_vblank_pre/post_modeset()?

> The most important side effect was that due to
> the delayed vblank disabling we have been pretty much guaranteed to
> receive a vblank interrupt soonish after a crtc was enabled.

I don't understand what this sentence means and whether it relates to
code prior to or after this patch.

> Note that our vblank handling across modeset is still fairly decent
> fubar - we don't actually handle vblank counter all to well.
> drm_update_vblank_count will make sure that the frame counter always
> rolls forward, but userspace isn't really all to ready to cope with
> the big jumps this causes.
> 
> This isn't a big mostly because the hardware retains the frame

Not a big what?

> counter. But with runtime pm and also across suspend/resume we fall
> over.
> 
> Fixing this is a lot more involved and also needs som i-g-ts. So
> material for another patch series.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 858c393b051f..d0eff53a8ad1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7207,15 +7207,10 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
>   struct intel_encoder *encoder;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct drm_display_mode *mode = _crtc->config.requested_mode;
> - int pipe = intel_crtc->pipe;
>   int ret;
>  
> - drm_vblank_pre_modeset(dev, pipe);
> -
>   ret = dev_priv->display.crtc_mode_set(crtc, x, y, fb);
>  
> - drm_vblank_post_modeset(dev, pipe);
> -
>   if (ret != 0)

Nit: There's now a blank line between ret = ... and if (...).

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

[PATCH 04/12] drm: Add drm_vblank_on()

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> From: Ville Syrj?l? 
> 
> drm_vblank_off() will turn off vblank interrupts, but as long as the
> refcount is elevated drm_vblank_get() will not re-enable them. This
> is a problem is someone is holding a vblank reference while a modeset is
> happening, and the driver requires vblank interrupt to work during that
> time.
> 
> Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
> re-enabled vblank interrupts if the refcount is already elevated. This
> will allow drivers to choose the specific places in the modeset sequence
> at which vblank interrupts get disabled and enabled.
> 
> Testcase: igt/kms_flip/*-vs-suspend
> Signed-off-by: Ville Syrj?l? 
> [danvet: Add Testcase tag for the igt I've written.]
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c| 72 
> ++--
>  drivers/gpu/drm/i915/intel_display.c |  8 
>  include/drm/drmP.h   |  1 +
>  3 files changed, 62 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 13d671ed3421..dd786d84daab 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -840,6 +840,41 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, int crtc)
>  }
>  
>  /**
> + * drm_vblank_enable - enable the vblank interrupt on a CRTC
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + */

Perhaps the kernel-doc here should contain some of what's described in
the commit message? Also a "Return:" section would be useful here to
specify what's an error and what isn't.

> +static int drm_vblank_enable(struct drm_device *dev, int crtc)

On second thought, since this is a local function, my comments above
apply to drm_vblank_on() below rather than drm_vblank_enable().

> +{
> + int ret = 0;
> +
> + assert_spin_locked(>vbl_lock);
> +
> + spin_lock(>vblank_time_lock);
> +
> + if (!dev->vblank[crtc].enabled) {
> + /* Enable vblank irqs under vblank_time_lock protection.
> +  * All vblank count & timestamp updates are held off
> +  * until we are done reinitializing master counter and
> +  * timestamps. Filtercode in drm_handle_vblank() will
> +  * prevent double-accounting of same vblank interval.
> +  */

Coding style:

/*
 * Enable...
 */

?

> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c

Perhaps split off the i915 changes into a separate patch?

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

[PATCH 03/12] drm: Make blocking vblank wait return when the vblank interrupts get disabled

[Thierry Reding]

On Wed, May 21, 2014 at 01:20:55PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> > From: Ville Syrj?l? 
> > 
> > If there's a blocking vblank wait in progress while the vblank interrupt
> > gets disabled, the current code will just let the vblank wait time out.
> > Instead make it return immediately when vblank interrupts get disabled.
> 
> Can this even happen? drm_wait_vblank() takes a vblank reference earlier
> and drops it right before returning. But perhaps this will become
> obvious since from a quick peek some of the subsequent patches seem like
> they will make it possible to force VBLANK off?

Ah, it seems like drm_vblank_off() can already do exactly that, in which
case this makes sense:

Reviewed-by: Thierry Reding 
-- 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/20140521/c6a60c92/attachment.sig>

[PATCH 03/12] drm: Make blocking vblank wait return when the vblank interrupts get disabled

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> From: Ville Syrj?l? 
> 
> If there's a blocking vblank wait in progress while the vblank interrupt
> gets disabled, the current code will just let the vblank wait time out.
> Instead make it return immediately when vblank interrupts get disabled.

Can this even happen? drm_wait_vblank() takes a vblank reference earlier
and drops it right before returning. But perhaps this will become
obvious since from a quick peek some of the subsequent patches seem like
they will make it possible to force VBLANK off?

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

[PATCH 02/12] drm: Make the vblank disable timer per-crtc

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:04PM +0200, Daniel Vetter wrote:
> From: Ville Syrj?l? 
> 
> Currently there's one per-device vblank disable timer, and it gets
> reset wheneven the vblank refcount for any crtc drops to zero. That

"whenever"

> means that one crtc could accidentally be keeping the vblank interrupts
> for other crtcs enabled even if there are no users for them. Make the
> disable timer per-crtc to avoid this issue.

Very pedantically: s/crtc/CRTC/ and maybe even s/vblank/VBLANK/. Feel
free to ignore those, though. =)

Also, and I may have asked before, why do we even need this timer? Why
not simply disable interrupts when the last vblank reference goes away?

Generally, though:

Reviewed-by: Thierry Reding 
-- 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/20140521/6f0a88e7/attachment.sig>

[PATCH 01/12] drm: Use correct spinlock flavor in drm_vblank_get()

[Thierry Reding]

On Wed, May 14, 2014 at 08:51:03PM +0200, Daniel Vetter wrote:
> From: Peter Hurley 
> 
> The irq flags state is already established by the outer
> spin_lock_irqsave(); re-disabling irqs is redundant.
> 
> Signed-off-by: Peter Hurley 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Thierry Reding 
-- 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/20140521/9631ba16/attachment-0001.sig>

[PATCH v2 04/18] video: add command mode and command mode display timing

[Thierry Reding]

On Wed, May 21, 2014 at 01:42:56PM +0900, YoungJun Cho wrote:
> This patch is based on videomode and display_timing relevant codes.
> To support command mode panel, it does not need to guide its timing
> information to the display controller like video mode panel,
> but it requires signal timings to transfer video data.
> So this patch adds cmdmode struct, cmdmode_display_timing struct and
> the according helper functions to convert cmdmode_display_timing
> to a generic cmdmode.

Can you point me to relevant documentation? I wasn't able to find it by
a quick scan through the DSI specification.

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

[PATCH 11/11] i915: mst topology dumper in debugfs (v0.2)

[Dave Airlie]

From: Dave Airlie 

use the mst helper code to dump the topology in debugfs.

v0.2: drop is_mst check - as we want to dump other info

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 88e944f..2d455ed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2378,6 +2378,28 @@ struct pipe_crc_info {
enum pipe pipe;
 };

+static int i915_dp_mst_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_encoder *encoder;
+   struct intel_encoder *intel_encoder;
+   struct intel_digital_port *intel_dig_port;
+   drm_modeset_lock_all(dev);
+   list_for_each_entry(encoder, >mode_config.encoder_list, head) {
+   intel_encoder = to_intel_encoder(encoder);
+   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
+   continue;
+   intel_dig_port = enc_to_dig_port(encoder);
+   if (!intel_dig_port->dp.can_mst)
+   continue;
+
+   drm_dp_mst_dump_topology(m, _dig_port->dp.mst_mgr);
+   }
+   drm_modeset_unlock_all(dev);
+   return 0;
+}
+
 static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
 {
struct pipe_crc_info *info = inode->i_private;
@@ -3813,6 +3835,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_pc8_status", i915_pc8_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_display_info", i915_display_info, 0},
+   {"i915_dp_mst_info", i915_dp_mst_info, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)

-- 
1.9.0

[PATCH 10/11] i915: add DP 1.2 MST support (v0.5)

[Dave Airlie]

From: Dave Airlie 

This adds DP 1.2 MST support on Haswell systems.

Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.

b) it introduces a new MST output type.

c) it really annoys the state checker, as the connector that is
connected at the start, goes into disconnected, and its encoder
it active, and things blow up, need to look into how to solve that.

d) the intel userspace driver needs changes to use this, -modesetting
should work okay.

e) it might contain a race condition big enough to eat you.

f) its hardcoded to 4 lanes 5.4Ghz. - TODO.

Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders

Changes since v0.2:
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.

Changes since v0.3:
updates for mst apis
more state checker fixes
irq handling improvements
fbcon handling support
improved reference counting of link - fixes redocking.

Changes since v0.4:
handle gpu reset hpd reinit without oopsing
check link status on HPD irqs
fix suspend/resume

TODO:
possibly further state checker fixes

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_dma.c   |  10 +
 drivers/gpu/drm/i915/i915_drv.c   |  13 +-
 drivers/gpu/drm/i915/i915_drv.h   |  14 +
 drivers/gpu/drm/i915/i915_irq.c   | 110 ++-
 drivers/gpu/drm/i915/intel_ddi.c  | 114 +--
 drivers/gpu/drm/i915/intel_display.c  |  59 +++-
 drivers/gpu/drm/i915/intel_dp.c   | 230 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   | 538 ++
 drivers/gpu/drm/i915/intel_drv.h  |  45 ++-
 drivers/gpu/drm/i915/intel_fbdev.c|   5 +
 drivers/gpu/drm/i915/intel_opregion.c |   1 +
 12 files changed, 1091 insertions(+), 49 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dp_mst.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b1445b7..6cf2b95 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -52,6 +52,7 @@ i915-y += dvo_ch7017.o \
  intel_crt.o \
  intel_ddi.o \
  intel_dp.o \
+ intel_dp_mst.o \
  intel_dsi_cmd.o \
  intel_dsi.o \
  intel_dsi_pll.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 58f2c46..3040869 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1677,6 +1677,13 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto out_mtrrfree;
}

+   dev_priv->dp_wq = alloc_ordered_workqueue("i915-dp", 0);
+   if (dev_priv->dp_wq == NULL) {
+   DRM_ERROR("Failed to create our dp workqueue.\n");
+   ret = -ENOMEM;
+   goto out_freewq;
+   }
+
intel_irq_init(dev);
intel_uncore_sanitize(dev);

@@ -1752,6 +1759,8 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
pm_qos_remove_request(_priv->pm_qos);
+   destroy_workqueue(dev_priv->dp_wq);
+out_freewq:
destroy_workqueue(dev_priv->wq);
 out_mtrrfree:
arch_phys_wc_del(dev_priv->gtt.mtrr);
@@ -1856,6 +1865,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);

+   destroy_workqueue(dev_priv->dp_wq);
destroy_workqueue(dev_priv->wq);
pm_qos_remove_request(_priv->pm_qos);

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 254b323..6b18779 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -447,7 +447,6 @@ static int i915_drm_freeze(struct drm_device *dev)

cancel_delayed_work_sync(_priv->rps.delayed_resume_work);

-   drm_irq_uninstall(dev);
dev_priv->enable_hotplug_processing = false;
/*
 * Disable CRTCs directly since we want to preserve sw state
@@ -458,6 +457,9 @@ static int i915_drm_freeze(struct drm_device *dev)
dev_priv->display.crtc_disable(crtc);
mutex_unlock(>mode_config.mutex);

+   intel_dp_mst_suspend(dev);
+   drm_irq_uninstall(dev);
+
intel_modeset_suspend_hw(dev);
}

@@ -578,6 +580,15 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)

intel_modeset_init_hw(dev);

+   {
+   unsigned long irqflags;
+   spin_lock_irqsave(_priv->irq_lock, irqflags);
+  

[PATCH 09/11] drm/i915: check connector->encoder before using it.

[Dave Airlie]

From: Dave Airlie 

DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 16 +---
 drivers/gpu/drm/i915/i915_irq.c  |  4 
 drivers/gpu/drm/i915/intel_display.c | 25 ++---
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..88e944f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2279,13 +2279,15 @@ static void intel_connector_info(struct seq_file *m,
seq_printf(m, "\tCEA rev: %d\n",
   connector->display_info.cea_rev);
}
-   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
-   intel_encoder->type == INTEL_OUTPUT_EDP)
-   intel_dp_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
-   intel_hdmi_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
-   intel_lvds_info(m, intel_connector);
+   if (intel_encoder) {
+   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_encoder->type == INTEL_OUTPUT_EDP)
+   intel_dp_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
+   intel_hdmi_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
+   intel_lvds_info(m, intel_connector);
+   }

seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, >modes, head)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afa5519..5852dee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1016,6 +1016,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
dev_priv->hpd_event_bits = 0;
list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (intel_encoder->hpd_pin > HPD_NONE &&
dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark == 
HPD_MARK_DISABLED &&
@@ -1046,6 +1048,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)

list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
if (intel_encoder->hot_plug)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b39d036..75b2aaf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4600,20 +4600,23 @@ static void intel_connector_check_state(struct 
intel_connector *connector)
 "wrong connector dpms state\n");
WARN(connector->base.encoder != >base,
 "active connector not linked to encoder\n");
-   WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");

-   encoder_enabled = encoder->get_hw_state(encoder, );
-   WARN(!encoder_enabled, "encoder not enabled\n");
-   if (WARN_ON(!encoder->base.crtc))
-   return;
+   if (encoder) {
+   WARN(!encoder->connectors_active,
+"encoder->connectors_active not set\n");
+
+   encoder_enabled = encoder->get_hw_state(encoder, );
+   WARN(!encoder_enabled, "encoder not enabled\n");
+   if (WARN_ON(!encoder->base.crtc))
+   return;

-   crtc = encoder->base.crtc;
+   crtc = encoder->base.crtc;

-   WARN(!crtc->enabled, "crtc not enabled\n");
-   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
-   WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
+   WARN(!crtc->enabled, "crtc not enabled\n");
+   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
+   WARN(pipe != to_intel_crtc(crtc)->pipe,
+"encoder active on the wrong pipe\n");
+   }
}
 }

-- 
1.9.0

[PATCH 08/11] i915: split some DP modesetting code into a separate function

[Dave Airlie]

From: Dave Airlie 

this is just prep work for mst support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/intel_ddi.c | 20 +---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e96..a5b8b76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI link training failed!\n");
 }

+void intel_ddi_mode_set_dp(struct intel_encoder *encoder)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(>base);
+
+   intel_dp->DP = intel_dig_port->saved_port_bits |
+   DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
+   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
+
+}
+
 static void intel_ddi_mode_set(struct intel_encoder *encoder)
 {
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
@@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct intel_encoder 
*encoder)
crtc->eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
-   struct intel_digital_port *intel_dig_port =
-   enc_to_dig_port(>base);
-
-   intel_dp->DP = intel_dig_port->saved_port_bits |
-  DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
-   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
-
+   intel_ddi_mode_set_dp(encoder);
if (intel_dp->has_audio) {
DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n",
 pipe_name(crtc->pipe));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b885df1..8e41cdc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_config *pipe_config);

+void intel_ddi_mode_set_dp(struct intel_encoder *encoder);

 /* intel_display.c */
 const char *intel_output_name(int output);
-- 
1.9.0

[PATCH 07/11] drm/helper: add Displayport multi-stream helper (v0.5)

[Dave Airlie]

From: Dave Airlie 

This is the initial import of the helper for displayport multistream.

It consists of a topology manager, init/destroy/set mst state

It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs

connector detect and edid retrieval interface.

It supports i2c device over DP 1.2 sideband msg protocol (EDID reads only)

bandwidth manager API via vcpi allocation and payload updating,
along with a helper to check the ACT status.

Objects:
MST topology manager - one per toplevel MST capable GPU port - not sure if this 
should be higher level again
MST branch unit - one instance per plugged branching unit - one at top of 
hierarchy - others hanging from ports
MST port - one port per port reported by branching units, can have MST units 
hanging from them as well.

Changes since initial posting:
a) add a mutex responsbile for the queues, it locks the sideband and msg slots, 
and msgs to transmit state
b) add worker to handle connection state change events, for MST device chaining 
and hotplug
c) add a payload spinlock
d) add path sideband msg support
e) fixup enum path resources transmit
f) reduce max dpcd msg to 16, as per DP1.2 spec.
g) separate tx queue kicking from irq processing and move irq acking back to 
drivers.

Changes since v0.2:
a) reorganise code,
b) drop ACT forcing code
c) add connector naming interface using path property
d) add topology dumper helper
e) proper reference counting and lookup for ports and mstbs.
f) move tx kicking into a workq
g) add aux locking - this should be redone
h) split teardown into two parts
i) start working on documentation on interface.

Changes since v0.3:
a) vc payload locking and tracking fixes
b) add hotplug callback into driver - replaces crazy return 1 scheme
c) txmsg + mst branch device refcount fixes
d) don't bail on mst shutdown if device is gone
e) change irq handler to take all 4 bytes of SINK_COUNT + ESI vectors
f) make DP payload updates timeout longer - observed on docking station redock
g) add more info to debugfs dumper

Changes since v0.4:
a) suspend/resume support
b) more debugging in debugfs

TODO:
misc features

Signed-off-by: Dave Airlie 
---
 Documentation/DocBook/drm.tmpl|6 +
 drivers/gpu/drm/Makefile  |2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 2739 +
 include/drm/drm_dp_mst_helper.h   |  507 ++
 4 files changed, 3253 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dp_mst_topology.c
 create mode 100644 include/drm/drm_dp_mst_helper.h

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 83dd0b0..1883976 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2296,6 +2296,12 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_dp_helper.c
 
 
+  Display Port MST Helper Functions Reference
+!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
+!Iinclude/drm/drm_dp_mst_helper.h
+!Edrivers/gpu/drm/drm_dp_mst_topology.c
+
+
   EDID Helper Functions Reference
 !Edrivers/gpu/drm/drm_edid.c
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 48e38ba..712b73e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o

 drm-usb-y   := drm_usb.o

-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o 
drm_dp_mst_topology.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
new file mode 100644
index 000..ebd9292
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -0,0 +1,2739 @@
+/*
+ * Copyright ? 2014 Red Hat
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR 

[PATCH 06/11] drm: add a path blob property

[Dave Airlie]

From: Dave Airlie 

This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c | 26 ++
 include/drm/drm_crtc.h |  5 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8bf87a6..06b9255 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1165,6 +1165,7 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
 {
struct drm_property *edid;
struct drm_property *dpms;
+   struct drm_property *dev_path;

/*
 * Standard properties (apply to all connectors)
@@ -1179,6 +1180,12 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
   ARRAY_SIZE(drm_dpms_enum_list));
dev->mode_config.dpms_property = dpms;

+   dev_path = drm_property_create(dev,
+  DRM_MODE_PROP_BLOB |
+  DRM_MODE_PROP_IMMUTABLE,
+  "PATH", 0);
+   dev->mode_config.path_property = dev_path;
+
return 0;
 }

@@ -3637,6 +3644,25 @@ done:
return ret;
 }

+int drm_mode_connector_set_path_property(struct drm_connector *connector,
+char *path)
+{
+   struct drm_device *dev = connector->dev;
+   int ret, size;
+   size = strlen(path) + 1;
+
+   connector->path_blob_ptr = drm_property_create_blob(connector->dev,
+   size, path);
+   if (!connector->path_blob_ptr)
+   return -EINVAL;
+
+   ret = drm_object_property_set_value(>base,
+   dev->mode_config.path_property,
+   connector->path_blob_ptr->base.id);
+   return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_path_property);
+
 /**
  * drm_mode_connector_update_edid_property - update the edid property of a 
connector
  * @connector: drm connector
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 55bc523..e33959b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -500,6 +500,8 @@ struct drm_connector {
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;

+   struct drm_property_blob *path_blob_ptr;
+
uint8_t polled; /* DRM_CONNECTOR_POLL_* */

/* requested DPMS state */
@@ -774,6 +776,7 @@ struct drm_mode_config {
struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
+   struct drm_property *path_property;
struct drm_property *plane_type_property;

/* DVI-I properties */
@@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device *dev);
 extern void drm_mode_config_reset(struct drm_device *dev);
 extern void drm_mode_config_cleanup(struct drm_device *dev);

+extern int drm_mode_connector_set_path_property(struct drm_connector 
*connector,
+   char *path);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
 extern int drm_object_property_set_value(struct drm_mode_object *obj,
-- 
1.9.0

[PATCH 05/11] drm/fb_helper: allow adding/removing connectors later

[Dave Airlie]

From: Dave Airlie 

This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c | 53 +
 include/drm/drm_fb_helper.h |  4 
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04d3fd3..a184204 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -105,6 +105,58 @@ fail:
 }
 EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);

+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector)
+{
+   struct drm_fb_helper_connector **temp;
+   struct drm_fb_helper_connector *fb_helper_connector;
+
+   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
+   if (fb_helper->connector_count + 1 > 
fb_helper->connector_info_alloc_count) {
+   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector) * (fb_helper->connector_count + 1), GFP_KERNEL);
+   if (!temp)
+   return -ENOMEM;
+
+   fb_helper->connector_info_alloc_count = 
fb_helper->connector_count + 1;
+   fb_helper->connector_info = temp;
+   }
+
+
+   fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector), 
GFP_KERNEL);
+   if (!fb_helper_connector)
+   return -ENOMEM;
+
+   fb_helper_connector->connector = connector;
+   fb_helper->connector_info[fb_helper->connector_count++] = 
fb_helper_connector;
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
+
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+  struct drm_connector *connector)
+{
+   struct drm_fb_helper_connector *fb_helper_connector;
+   int i, j;
+
+   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
+
+   for (i = 0; i < fb_helper->connector_count; i++) {
+   if (fb_helper->connector_info[i]->connector == connector)
+   break;
+   }
+
+   if (i == fb_helper->connector_count)
+   return -EINVAL;
+   fb_helper_connector = fb_helper->connector_info[i];
+
+   for (j = i + 1; j < fb_helper->connector_count; j++) {
+   fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
+   }
+   fb_helper->connector_count--;
+   kfree(fb_helper_connector);
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
+
 static int drm_fb_helper_parse_command_line(struct drm_fb_helper *fb_helper)
 {
struct drm_fb_helper_connector *fb_helper_conn;
@@ -534,6 +586,7 @@ int drm_fb_helper_init(struct drm_device *dev,
kfree(fb_helper->crtc_info);
return -ENOMEM;
}
+   fb_helper->connector_info_alloc_count = dev->mode_config.num_connector;
fb_helper->connector_count = 0;

for (i = 0; i < crtc_count; i++) {
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6e622f7..4abb415 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -86,6 +86,7 @@ struct drm_fb_helper {
int crtc_count;
struct drm_fb_helper_crtc *crtc_info;
int connector_count;
+   int connector_info_alloc_count;
struct drm_fb_helper_connector **connector_info;
struct drm_fb_helper_funcs *funcs;
struct fb_info *fbdev;
@@ -128,4 +129,7 @@ struct drm_display_mode *
 drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn,
  int width, int height);

+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector);
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+  struct drm_connector *connector);
 #endif
-- 
1.9.0

[PATCH 04/11] drm/crtc: add interface to reinitialise the legacy mode group

[Dave Airlie]

From: Dave Airlie 

This can be called to update things after dynamic connectors/encoders
are created/deleted.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 include/drm/drm_crtc.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f1753e6..8bf87a6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1421,6 +1421,15 @@ int drm_mode_group_init_legacy_group(struct drm_device 
*dev,
 }
 EXPORT_SYMBOL(drm_mode_group_init_legacy_group);

+void drm_reinit_primary_mode_group(struct drm_device *dev)
+{
+   drm_modeset_lock_all(dev);
+   drm_mode_group_destroy(>primary->mode_group);
+   drm_mode_group_init_legacy_group(dev, >primary->mode_group);
+   drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_reinit_primary_mode_group);
+
 /**
  * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
  * @out: drm_mode_modeinfo struct to return to the user
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c6b9e8a..55bc523 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -916,6 +916,7 @@ extern const char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
 extern void drm_mode_group_destroy(struct drm_mode_group *group);
+extern void drm_reinit_primary_mode_group(struct drm_device *dev);
 extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
-- 
1.9.0

[PATCH 03/11] drm/i915: add some registers need for displayport MST support.

[Dave Airlie]

From: Dave Airlie 

These are just from the Haswell spec.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_reg.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5386,6 +5386,7 @@ enum punit_power_well {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)

 /* DisplayPort Transport Control */
@@ -5395,6 +5396,7 @@ enum punit_power_well {
 #define  DP_TP_CTL_ENABLE  (1<<31)
 #define  DP_TP_CTL_MODE_SST(0<<27)
 #define  DP_TP_CTL_MODE_MST(1<<27)
+#define  DP_TP_CTL_FORCE_ACT   (1<<25)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1<<18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1<<15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7<<8)
@@ -5409,8 +5411,13 @@ enum punit_power_well {
 #define DP_TP_STATUS_A 0x64044
 #define DP_TP_STATUS_B 0x64144
 #define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B)
-#define  DP_TP_STATUS_IDLE_DONE(1<<25)
-#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_IDLE_DONE(1<<25)
+#define  DP_TP_STATUS_ACT_SENT (1<<24)
+#define  DP_TP_STATUS_MODE_STATUS_MST  (1<<23)
+#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC2  (3 << 8)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC1  (3 << 4)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC0  (3 << 0)

 /* DDI Buffer Control */
 #define DDI_BUF_CTL_A  0x64000
-- 
1.9.0

[PATCH 02/11] drm: add DP MST encoder type

[Dave Airlie]

From: Dave Airlie 

This adds an encoder type for DP MST encoders.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c  | 1 +
 include/uapi/drm/drm_mode.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -227,6 +227,7 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
+   { DRM_MODE_ENCODER_DPMST, "DP MST" },
 };

 static const struct drm_prop_enum_list drm_subpixel_enum_list[] =
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..719add4 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -181,6 +181,7 @@ struct drm_mode_get_plane_res {
 #define DRM_MODE_ENCODER_TVDAC 4
 #define DRM_MODE_ENCODER_VIRTUAL 5
 #define DRM_MODE_ENCODER_DSI   6
+#define DRM_MODE_ENCODER_DPMST 7

 struct drm_mode_get_encoder {
__u32 encoder_id;
-- 
1.9.0

[PATCH 01/11] drm/dp_helper: add defines for DP 1.2 and MST support.

[Dave Airlie]

From: Dave Airlie 

This just adds the defines from the DP 1.2 spec, which we
will use later.

Signed-off-by: Dave Airlie 
---
 include/drm/drm_dp_helper.h | 78 +
 1 file changed, 78 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index cfcacec..879836d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -37,6 +37,7 @@
  * eDP: Embedded DisplayPort version 1
  * DPI: DisplayPort Interoperability Guideline v1.1a
  * 1.2: DisplayPort 1.2
+ * MST: Multistream Transport - part of DP 1.2a
  *
  * 1.2 formally includes both eDP and DPI definitions.
  */
@@ -103,9 +104,14 @@
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */

 /* Multiple stream transport */
+#define DP_FAUX_CAP0x020   /* 1.2 */
+# define DP_FAUX_CAP_1 (1 << 0)
+
 #define DP_MSTM_CAP0x021   /* 1.2 */
 # define DP_MST_CAP(1 << 0)

+#define DP_GUID0x030   /* 1.2 */
+
 #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
 # define DP_PSR_IS_SUPPORTED1
 #define DP_PSR_CAPS 0x071   /* XXX 1.2? */
@@ -221,6 +227,16 @@
 # define DP_PSR_CRC_VERIFICATION   (1 << 2)
 # define DP_PSR_FRAME_CAPTURE  (1 << 3)

+#define DP_ADAPTER_CTRL0x1a0
+# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE   (1 << 0)
+
+#define DP_BRANCH_DEVICE_CTRL  0x1a1
+# define DP_BRANCH_DEVICE_IRQ_HPD  (1 << 0)
+
+#define DP_PAYLOAD_ALLOCATE_SET0x1c0
+#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
+#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2
+
 #define DP_SINK_COUNT  0x200
 /* prior to 1.2 bit 7 was reserved mbz */
 # define DP_GET_SINK_COUNT(x)  x) & 0x80) >> 1) | ((x) & 0x3f))
@@ -230,6 +246,9 @@
 # define DP_REMOTE_CONTROL_COMMAND_PENDING  (1 << 0)
 # define DP_AUTOMATED_TEST_REQUEST (1 << 1)
 # define DP_CP_IRQ (1 << 2)
+# define DP_MCCS_IRQ   (1 << 3)
+# define DP_DOWN_REP_MSG_RDY   (1 << 4) /* DP MST */
+# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */
 # define DP_SINK_SPECIFIC_IRQ  (1 << 6)

 #define DP_LANE0_1_STATUS  0x202
@@ -294,6 +313,13 @@
 #define DP_TEST_SINK   0x270
 #define DP_TEST_SINK_START (1 << 0)

+#define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
+# define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
+# define DP_PAYLOAD_ACT_HANDLED (1 << 1)
+
+#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1   /* 1.2 MST */
+/* up to ID_SLOT_63 at 0x2ff */
+
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
@@ -303,6 +329,21 @@
 # define DP_SET_POWER_D30x2
 # define DP_SET_POWER_MASK  0x3

+#define DP_SIDEBAND_MSG_DOWN_REQ_BASE  0x1000   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REP_BASE0x1200   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_DOWN_REP_BASE  0x1400   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600   /* 1.2 MST */
+
+#define DP_SINK_COUNT_ESI  0x2002   /* 1.2 */
+/* 0-5 sink count */
+# define DP_SINK_COUNT_CP_READY (1 << 6)
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0   0x2003   /* 1.2 */
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1   0x2004   /* 1.2 */
+
+#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
+
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
 # define DP_PSR_RFB_STORAGE_ERROR   (1 << 1)
@@ -319,6 +360,43 @@
 # define DP_PSR_SINK_INTERNAL_ERROR 7
 # define DP_PSR_SINK_STATE_MASK 0x07

+/* DP 1.2 Sideband message defines */
+/* peer device type - DP 1.2a Table 2-92 */
+#define DP_PEER_DEVICE_NONE0x0
+#define DP_PEER_DEVICE_SOURCE_OR_SST   0x1
+#define DP_PEER_DEVICE_MST_BRANCHING   0x2
+#define DP_PEER_DEVICE_SST_SINK0x3
+#define DP_PEER_DEVICE_DP_LEGACY_CONV  0x4
+
+/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */
+#define DP_LINK_ADDRESS0x01
+#define DP_CONNECTION_STATUS_NOTIFY0x02
+#define DP_ENUM_PATH_RESOURCES 0x10
+#define DP_ALLOCATE_PAYLOAD0x11
+#define DP_QUERY_PAYLOAD   0x12
+#define DP_RESOURCE_STATUS_NOTIFY  0x13
+#define DP_CLEAR_PAYLOAD_ID_TABLE  0x14
+#define DP_REMOTE_DPCD_READ0x20
+#define DP_REMOTE_DPCD_WRITE   0x21
+#define DP_REMOTE_I2C_READ 0x22
+#define DP_REMOTE_I2C_WRITE0x23
+#define DP_POWER_UP_PHY0x24
+#define DP_POWER_DOWN_PHY  0x25
+#define 

[RFC] DisplayPort MST support

[Dave Airlie]

Hey,

So this set is pretty close to what I think we should be merging initially,

Since the last set, it makes fbcon and suspend/resume work a lot better,

I've also fixed a couple of bugs in -intel that make things work a lot
better.

I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked
to add 3 monitor support.

It still generates a fair few i915 state checker backtraces, and some
of them are fairly hard to work out, it might be we should just tone
down the state checker for encoders/connectors with no actual hw backing
them.

Dave.

[PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup

[Naveen Krishna Ch]

Hello Everyone,

On 14 May 2014 17:09, Naveen Krishna Chatradhi  wrote:
> exynos_drm_init() does probing of various drivers like dp_panel,
> hdmi, fimd, mixer, etc in an order and finally binds them together.
>
> Some of the drm devices (Eg: dp_panel) try to do regulator_get()
> and enable few supplies during their probe.
> Chances are that, these devices may get probed before the respective
> supply/PMIC is hooked.  In such cases, dp_panel would continue with
> "dummy regulator". Which is not what the system wants.
>
> Lets give the core connectivity and regulators modules some time
> to hookup the supplies before Exynos DRM devices comes into picture.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> This change is proposed after
> 1. Discussing with I2C/SPI & DMA subsystem maintainers and Others
>@ https://lkml.org/lkml/2014/5/9/333
>Trying to change the I2C, SPI and DMA drivers as subsys_initcall()
>Which was strictly opposed, as a flaw was found in DRM subsystem.
>
> 2. -EPROBE_DEFER won't work well with the current sequency of
> platform_driver_register()s in exynos_drm_init()
>
> 3. bridge_panel mechanism is under RFC and no conclusions were drawn yet.
>
> We should be able to probe each DRM device independently and let PROBE_DEFER
> take care of dependencies. But, this could cause lot of bootup time.
>
> late_initcall() of DRM works well and fixes all the above issues for now.
> Kindly suggest, if an alternative/better mechanism is out there.
>
> Thanks,
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 4cef88f..78c185a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -692,7 +692,7 @@ static void exynos_drm_exit(void)
> platform_driver_unregister(_drm_platform_driver);
>  }
>
> -module_init(exynos_drm_init);
> +late_initcall(exynos_drm_init);
>  module_exit(exynos_drm_exit);
>
>  MODULE_AUTHOR("Inki Dae ");
Kindly, show some light on this change.
Also adding more reviewers.
> --
> 1.7.9.5
>



-- 
Shine bright,
(: Nav :)

[Bug 70053] hard machine hang when switching to battery power with DPM enabled on Trinity APU

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

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

Lucas Stach  changed:

   What|Removed |Added

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

--- Comment #7 from Lucas Stach  ---
Already fixed in 3.12 final.

-- 
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/20140521/e171c45b/attachment.html>

[PATCH 00/12] irq vblank handling rework

[Ville Syrjälä]

On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrj?l? wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrj?l? 
> > 
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> > sane but I didn't go reading through the drivers to figure out if they
> > would fall over or work.
> 
> Oh, the rfc was really just that. I don't have any plans to burn my hands
> trying to merge those patches ;-) Especially since interest from non-i915
> hackers seems to be low.
> 
> > About the reset_vblank_counter(), I think we might still need it to keep
> > the counter sane when the power well goes off. But I think we have
> > other problems on that front esp. with suspend to disk. There the counter
> > should definitely get reset on all platforms, so we migth apply any kind
> > of diff to the user visible value. The fix would likely be to skip the
> > diff adjustment when resuming.
> > 
> > I tried to take a quick look at that yesterday but there was something
> > really fishy happening as the code didn't seem to observe the wraparound
> > at all, even though I confirmed w/ intel_reg_read that it definitely
> > did appear to wrap. I'll take another look at it today.
> > 
> > Another idea might be to rip out the diff adjustment altogether. That
> > should just mean that the user visible counter wouldn't advance at all
> > between drm_vblank_off() and drm_vblank_on(). But that might actually
> > be the sane thing to do. Maybe we should just do a +1 there to make
> > sure we don't report the same value before and after modeset. It should
> > fix both the suspend problems and the power well problem.
> 
> Hm, like I've mentioned yesterday on irc the tests I have actually pass,
> at least if I throw your sanitize_crtc patch on top. vblank frame counter
> values monotonically increase across suspend/resume, runtime pm and
> anything else I manged to throw at it. And the limit in the test is 100
> frames later, but I've only observed a few tens at most.
> 
> So I think the code as-is actually works. Whether intentional or not is
> still under dispute though ;-)
> 
> The real problem I have with the hsw counter reset is that the same issue
> should affect _any_ platform where we support runtime pm. Like snb or byt.
> But the code isn't there. Also if we have such a bug then it will also
> affect hibernate and suspend to disk. Which means that this should be done
> in drm_crtc_vblank_off/on, not in the guts of some random platforms
> runtime pm code.
> 
> So in my opinion the hsw vblank_count reset code needs to go anyway
> because:
> - Either it isn't need any more (and we have the tests for this now) and
>   it's just cargo-culted duct-tape.
> - Or we need, but then it's in the wrong spot.
> 
> Given that can you reconsider that patch please?

Yeah. So as discussed on irc I think the right fix would be to sample
the current counter in drm_vblank_on(), stick it into
dev->vblank[crtc].last, but skip the diff adjustment to the user visible
counter (maybe just +1 to make sure we never report the same value on
both sides of a modeset). That should cover both the suspend case and the
power well case. I can go and experiment with this a bit...

So I agree that the current code isn't the way things should be done.
And since I now have an idea how it should be done, I'm fine with
ripping the current thing out. So you can add:
Reviewed-by: Ville Syrj?l? 

-- 
Ville Syrj?l?
Intel OTC

[Intel-gfx] [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes

[Daniel Vetter]

On Tue, May 20, 2014 at 07:31:33PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrj?l? 
> > 
> > If a pipe is already active when we init/resume there might not be a
> > full modeset afterwards so drm_vblank_on() may not get called. In such
> > a case if someone is holding a vblank reference across a suspend/resume
> > cycle drm_vblank_get() called after resuming won't re-enable the vblank
> > interrupts.
> > 
> > So in order to make sure vblank interrupts get re-enabled post-resume,
> > call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
> > active.
> > 
> > v2: Also drm_vblank_off() if the pipe got disabled magically
> > 
> > Signed-off-by: Ville Syrj?l? 
> 
> This seems to duct-tape over the funny failure I'm seeing on my snb where
> kms_flip/vblank-vs-modeset|dpms-suspend work nicely, but
> kms_flip/vblank-vs-suspend has some totally hilarious random vblank frame
> counter after the modeset.
> 
> Testecase: igt/kms_flip/vblank-vs-suspend
> Tested-by: Daniel Vetter 
> 
> Now the problem I have: We already call this in the crtc_enable hook. Why
> does calling this here again add the necessary magic?
> 
> /me has no clue

Well, we can figure this out later.

Queued for -next, thanks for the patch.
-Daniel
> 
> Cheers, Daniel
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9420f4f..2e9f0b0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc 
> > *crtc)
> > reg = PIPECONF(crtc->config.cpu_transcoder);
> > I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
> >  
> > +   /* restore vblank interrupts to correct state */
> > +   if (crtc->active)
> > +   drm_vblank_on(dev, crtc->pipe);
> > +   else
> > +   drm_vblank_off(dev, crtc->pipe);
> > +
> > /* We need to sanitize the plane -> pipe mapping first because this will
> >  * disable the crtc (and hence change the state) if it is wrong. Note
> >  * that gen4+ has a fixed plane -> pipe mapping.  */
> > -- 
> > 1.8.5.5
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 00/12] irq vblank handling rework

[Ville Syrjälä]

For everything but the reset_vblank_counter() thing:
Reviewed-by: Ville Syrj?l? 

And another caveat: I only glanced at the crtc_helper stuff. It looks
sane but I didn't go reading through the drivers to figure out if they
would fall over or work.

About the reset_vblank_counter(), I think we might still need it to keep
the counter sane when the power well goes off. But I think we have
other problems on that front esp. with suspend to disk. There the counter
should definitely get reset on all platforms, so we migth apply any kind
of diff to the user visible value. The fix would likely be to skip the
diff adjustment when resuming.

I tried to take a quick look at that yesterday but there was something
really fishy happening as the code didn't seem to observe the wraparound
at all, even though I confirmed w/ intel_reg_read that it definitely
did appear to wrap. I'll take another look at it today.

Another idea might be to rip out the diff adjustment altogether. That
should just mean that the user visible counter wouldn't advance at all
between drm_vblank_off() and drm_vblank_on(). But that might actually
be the sane thing to do. Maybe we should just do a +1 there to make
sure we don't report the same value before and after modeset. It should
fix both the suspend problems and the power well problem.

On Wed, May 14, 2014 at 08:51:02PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> This is Ville's vblank rework series, slightly pimped. I've added kerneldoc,
> some polish and also some additional nasty igt testcases for these crtc on/off
> vs vblank issues. Seems all to hold together nicely.
> 
> Now one thing I wanted to do is roll this out across all drm drivers, but that
> looks ugly: Many drivers don't support vblanks really, and I couldn't fully
> audit whether they'd e.g. blow up when userspace tries to use the vblank wait
> ioctl. But I think we want to have more sanity since otherwise userspace is
> doomed to carry countless ugly hacks around forever.
> 
> The last two patches are my attempt at that. By doing the drm_vblank_on/off
> dance in the crtc helpers after we know that the crtc is on/off we should have
> at least a somewhat sane baseline behaviour. Note that since drm_vblank_on/off
> are idempotent drivers are free to call these functions in their callback at 
> an
> earlier time, where it makes more sense. But at least it's guaranteed to 
> happen.
> 
> Otoh drivers still need to manually complete pageflips, so this doesn't solve
> all the issues. But until we have a solid cross-driver testsuite for these
> corner-cases (all the interesting stuff happens when you race vblank waits
> against concurrent modesets, dpms, or system/runtime suspend/resume) we're
> pretty much guaranteed to have some that works at best occasionally and is
> guaranteed to have different behaviour in corner cases. Note that the patches
> won't degrade behaviour for existing drivers, the drm core changes simply 
> allow
> us to finally fix things up correctly.
> 
> I guess in a way this is a more generic discussion for the drm subsystem at
> large.
> 
> Coments and review highly welcome.
> 
> Cheers, Daniel
> 
> Daniel Vetter (8):
>   drm/i915: Remove drm_vblank_pre/post_modeset calls
>   drm/doc: Discourage usage of MODESET_CTL ioctl
>   drm/irq: kerneldoc polish
>   drm/irq: Add kms-native crtc interface functions
>   drm/i915: rip our vblank reset hacks for runtime PM
>   drm/i915: Accurately initialize fifo underrun state on gmch platforms
>   [RFC] drm/irq: More robustness in drm_vblank_on|off
>   [RFC] drm/crtc-helper: Enforce sane vblank counter semantics
> 
> Peter Hurley (1):
>   drm: Use correct spinlock flavor in drm_vblank_get()
> 
> Ville Syrj?l? (3):
>   drm: Make the vblank disable timer per-crtc
>   drm: Make blocking vblank wait return when the vblank interrupts get
> disabled
>   drm: Add drm_vblank_on()
> 
>  Documentation/DocBook/drm.tmpl   |  16 +-
>  drivers/gpu/drm/drm_crtc_helper.c|  12 ++
>  drivers/gpu/drm/drm_irq.c| 377 
> ++-
>  drivers/gpu/drm/i915/i915_irq.c  |   4 +-
>  drivers/gpu/drm/i915/intel_display.c |  36 ++--
>  drivers/gpu/drm/i915/intel_drv.h |   2 -
>  drivers/gpu/drm/i915/intel_pm.c  |  40 
>  include/drm/drmP.h   |  10 +-
>  8 files changed, 341 insertions(+), 156 deletions(-)
> 
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[PATCH 02/18] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

Hi Daniel

Thank you for comments.

On 05/20/2014 07:02 PM, Daniel Kurtz wrote:
> On Wed, May 14, 2014 at 2:26 PM, YoungJun Cho  wrote:
>>
>> 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.
>
>
> This solution looks like we aren't really handling some conditions
> completely (such as "panel reset"?). In cases where this timeout can
> occur, shouldn't we be clearing pending_flip when we detect that the
> flip will never complete?
>

Nice catch!.

The others except pending_flip issue are done in drm_vblank_off() 
instead of exynos_drm_crtc_finish_pageflip() at this case.

I'll do it for this routine and exynos_drm_crtc_page_flip() also.
There is a leak point in exynos_drm_crtc_page_flip() when 
exynos_drm_crtc_mode_set_commit() is failed.

Thank you.
Best regards YJ

> -Dan
>
>>
>>
>> Signed-off-by: YoungJun Cho 
>> Acked-by: Inki Dae 
>> Acked-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 95c9435..485fa26 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
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 00/12] irq vblank handling rework

[Daniel Vetter]

On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrj?l? wrote:
> For everything but the reset_vblank_counter() thing:
> Reviewed-by: Ville Syrj?l? 
> 
> And another caveat: I only glanced at the crtc_helper stuff. It looks
> sane but I didn't go reading through the drivers to figure out if they
> would fall over or work.

Oh, the rfc was really just that. I don't have any plans to burn my hands
trying to merge those patches ;-) Especially since interest from non-i915
hackers seems to be low.

> About the reset_vblank_counter(), I think we might still need it to keep
> the counter sane when the power well goes off. But I think we have
> other problems on that front esp. with suspend to disk. There the counter
> should definitely get reset on all platforms, so we migth apply any kind
> of diff to the user visible value. The fix would likely be to skip the
> diff adjustment when resuming.
> 
> I tried to take a quick look at that yesterday but there was something
> really fishy happening as the code didn't seem to observe the wraparound
> at all, even though I confirmed w/ intel_reg_read that it definitely
> did appear to wrap. I'll take another look at it today.
> 
> Another idea might be to rip out the diff adjustment altogether. That
> should just mean that the user visible counter wouldn't advance at all
> between drm_vblank_off() and drm_vblank_on(). But that might actually
> be the sane thing to do. Maybe we should just do a +1 there to make
> sure we don't report the same value before and after modeset. It should
> fix both the suspend problems and the power well problem.

Hm, like I've mentioned yesterday on irc the tests I have actually pass,
at least if I throw your sanitize_crtc patch on top. vblank frame counter
values monotonically increase across suspend/resume, runtime pm and
anything else I manged to throw at it. And the limit in the test is 100
frames later, but I've only observed a few tens at most.

So I think the code as-is actually works. Whether intentional or not is
still under dispute though ;-)

The real problem I have with the hsw counter reset is that the same issue
should affect _any_ platform where we support runtime pm. Like snb or byt.
But the code isn't there. Also if we have such a bug then it will also
affect hibernate and suspend to disk. Which means that this should be done
in drm_crtc_vblank_off/on, not in the guts of some random platforms
runtime pm code.

So in my opinion the hsw vblank_count reset code needs to go anyway
because:
- Either it isn't need any more (and we have the tests for this now) and
  it's just cargo-culted duct-tape.
- Or we need, but then it's in the wrong spot.

Given that can you reconsider that patch please?

Thanks, Daniel

> 
> On Wed, May 14, 2014 at 08:51:02PM +0200, Daniel Vetter wrote:
> > Hi all,
> > 
> > This is Ville's vblank rework series, slightly pimped. I've added kerneldoc,
> > some polish and also some additional nasty igt testcases for these crtc 
> > on/off
> > vs vblank issues. Seems all to hold together nicely.
> > 
> > Now one thing I wanted to do is roll this out across all drm drivers, but 
> > that
> > looks ugly: Many drivers don't support vblanks really, and I couldn't fully
> > audit whether they'd e.g. blow up when userspace tries to use the vblank 
> > wait
> > ioctl. But I think we want to have more sanity since otherwise userspace is
> > doomed to carry countless ugly hacks around forever.
> > 
> > The last two patches are my attempt at that. By doing the drm_vblank_on/off
> > dance in the crtc helpers after we know that the crtc is on/off we should 
> > have
> > at least a somewhat sane baseline behaviour. Note that since 
> > drm_vblank_on/off
> > are idempotent drivers are free to call these functions in their callback 
> > at an
> > earlier time, where it makes more sense. But at least it's guaranteed to 
> > happen.
> > 
> > Otoh drivers still need to manually complete pageflips, so this doesn't 
> > solve
> > all the issues. But until we have a solid cross-driver testsuite for these
> > corner-cases (all the interesting stuff happens when you race vblank waits
> > against concurrent modesets, dpms, or system/runtime suspend/resume) we're
> > pretty much guaranteed to have some that works at best occasionally and is
> > guaranteed to have different behaviour in corner cases. Note that the 
> > patches
> > won't degrade behaviour for existing drivers, the drm core changes simply 
> > allow
> > us to finally fix things up correctly.
> > 
> > I guess in a way this is a more generic discussion for the drm subsystem at
> > large.
> > 
> > Coments and review highly welcome.
> > 
> > Cheers, Daniel
> > 
> > Daniel Vetter (8):
> >   drm/i915: Remove drm_vblank_pre/post_modeset calls
> >   drm/doc: Discourage usage of MODESET_CTL ioctl
> >   drm/irq: kerneldoc polish
> >   drm/irq: Add kms-native crtc interface functions
> >   drm/i915: rip our vblank reset hacks for runtime PM
> >   drm/i915: Accurately initialize fifo 

[Bug 76558] [radeon] GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten

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

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

Fabio Pedretti  changed:

   What|Removed |Added

  Attachment #99497|dmesg after the lockup with |dmesg after the lockup with
description|kernel 3.13.0-24.47, got|Ubuntu kernel 3.13.0-24.47
   |switching to a VT   |(based on 3.13.9)

-- 
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/20140521/94cc22c0/attachment.html>

[Bug 76558] [radeon] GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten

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

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

Fabio Pedretti  changed:

   What|Removed |Added

  Attachment #96295|dmesg after the lockup, got |dmesg after the lockup with
description|switching to a VT   |Ubuntu kernel 3.11.0-18.32
   ||(based on 3.11.10.4)

-- 
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/20140521/03ba0088/attachment.html>

[Bug 76558] [radeon] GPU lockup: radeon: wait for empty RBBM fifo failed ! when playing sauerbraten

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

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

--- Comment #3 from Fabio Pedretti  ---
Created attachment 99497
  --> https://bugs.freedesktop.org/attachment.cgi?id=99497=edit
dmesg after the lockup with kernel 3.13.0-24.47, got switching to a VT

Here is an updated dmesg with kernel 3.13.9 (ubuntu 3.13.0-24.47), only
relevant difference is "on ring 0" is added to this line:
[11757.716140] radeon :01:00.0: GPU lockup (waiting for 0x0003dd41
last fence id 0x0003dd40 on ring 0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140521/96600a25/attachment.html>

[PATCH 3/5] drm/radeon: Setup HDMI_CONTROL for hdmi deep color gcp's.

[Alex Deucher]

On Wed, May 21, 2014 at 1:58 AM, Rafa? Mi?ecki  wrote:
> On 21 May 2014 01:17, Alex Deucher  wrote:
>> +   val = RREG32(HDMI_CONTROL + offset);
>> +   val &= ~HDMI_DEEP_COLOR_ENABLE;
>> +   val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
>> +
>
>> +   switch (bpc) {
>> (...)
>> +   }
>> +
>> +   WREG32(HDMI_CONTROL + offset, val);
>
> What about using helper:
>
> WREG32_P(HDMI_CONTROL + offset,
> val,
> ~(HDMI_DEEP_COLOR_ENABLE | HDMI_DEEP_COLOR_DEPTH_MASK));

We could.  I don't think it really makes much difference one way or
the other though.  I don't really have a strong preference.

Alex

[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

[Sumit Semwal]

Hi Bjorn,

On 21 May 2014 04:50, Bjorn Helgaas  wrote:
> On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
>> Update some descriptions for API arguments and descriptions.
>>
>> Signed-off-by: Gioh Kim 
>
> I applied this to my "dma-api" branch for v3.16, thanks!
As always, I would queue this up for my dma-buf pull request, along
with other dma-buf changes.

Thanks and best regards,
~Sumit.
>
>> ---
>>  Documentation/dma-buf-sharing.txt |   14 --
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/dma-buf-sharing.txt 
>> b/Documentation/dma-buf-sharing.txt
>> index 505e711..aadd901 100644
>> --- a/Documentation/dma-buf-sharing.txt
>> +++ b/Documentation/dma-buf-sharing.txt
>> @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the 
>> following steps:
>>size_t size, int flags,
>>const char *exp_name)
>>
>> -   If this succeeds, dma_buf_export allocates a dma_buf structure, and 
>> returns a
>> -   pointer to the same. It also associates an anonymous file with this 
>> buffer,
>> -   so it can be exported. On failure to allocate the dma_buf object, it 
>> returns
>> -   NULL.
>> +   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and
>> +   returns a pointer to the same. It also associates an anonymous file with 
>> this
>> +   buffer, so it can be exported. On failure to allocate the dma_buf object,
>> +   it returns NULL.
>>
>> 'exp_name' is the name of exporter - to facilitate information while
>> debugging.
>> @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the 
>> following steps:
>> drivers and/or processes.
>>
>> Interface:
>> -  int dma_buf_fd(struct dma_buf *dmabuf)
>> +  int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>>
>> This API installs an fd for the anonymous file associated with this 
>> buffer;
>> returns either 'fd', or error.
>> @@ -157,7 +157,9 @@ to request use of buffer for allocation.
>> "dma_buf->ops->" indirection from the users of this interface.
>>
>> In struct dma_buf_ops, unmap_dma_buf is defined as
>> -  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
>> +  void (*unmap_dma_buf)(struct dma_buf_attachment *,
>> +struct sg_table *,
>> +enum dma_data_direction);
>>
>> unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
>> map_dma_buf, this API also must be implemented by the exporter.
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks and regards,

Sumit Semwal
Graphics Engineer - Graphics working group
Linaro.org ? Open source software for ARM SoCs