[PATCH] scripts/kernel-doc: Improve Markdown results

[Jonathan Corbet]

On Fri, 4 Sep 2015 14:53:34 -0300
Danilo Cesar Lemes de Paula  wrote:

> In the last few days I sent three features:
> Markdown support (patch series 1)
> Cross-reference hyperlink support (patch series 1)
> in-struct-body documentation (series 2)
> 
> I assume you want a new patch series for the series 1, containing the
> feature itself and the fixes that I sent later, correct?

The cross-reference patch was merged, so there's no need to send that
again.  Anything else that isn't in mainline now should be resent as a
new series.

Thanks,

jon

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Russell King - ARM Linux]

On Fri, Sep 04, 2015 at 12:48:02PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson  
> wrote:
> > Russell,
> >
> > On Sat, Aug 8, 2015 at 9:10 AM, Russell King
> >  wrote:
> >> Adjust the pixel clock values in the N calculation to match the more
> >> accurate clock values we're given by the DRM subsystem, which are the
> >> kHz pixel rate, with any fractional kHz rounded down in the case of
> >> the non-240, non-480 line modes, or rounded up for the others.  So,
> >>
> >>  25.20 / 1.001 =>  25175
> >>  27.00 * 1.001 =>  27027
> >>  74.25 / 1.001 =>  74176
> >> 148.50 / 1.001 => 148352
> >>
> >> Signed-off-by: Russell King 
> >> ---
> >>  drivers/gpu/drm/bridge/dw_hdmi.c | 20 ++--
> >>  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > For what it's worth, I backported this change into my local 3.14-based
> > tree and it doesn't cause any problems, though it looks like the code
> > isn't being run in my case...
> >
> > I can confirm that the rates you list match the rates I actually see
> > requested by DRM, but in my current tree I've actually got something
> > that allows a little bit of "slop" in HDMI rates because my system
> > can't actually always make exactly the modes requested, but it appears
> > that getting "close enough" works, especially if your clock jitter is
> > low enough (because the sink needs to have a little bit of wiggle room
> > for jitter anyway).  For instance, when 25.175 is requested we
> > actually end up making 25.170732.
> >
> > In my tree this adjustment happens in mode_fixup by changing the
> > adj_mode.  In one particular case, some debug prints show:
> >   640x480, mode=2520, adj=25171000, actual=25170732
> >   freq=48000, pixel_clk=25171000, n=6144
> >
> > I'm not enough of an HDMI expert to say whether it's better to be
> > using n=6144 or n=6864 in this case, but audio does play with either
> > on the TV I tested.
> >
> > In any case, I'd say that your change at least makes things better
> > than they were, so I'd be in favor of taking it.  If someone later
> > decides that we should add a little margin to these numbers, then a
> > patch to add that could go atop yours.
> 
> Oh!  I just figured this out!  :)
> 
> Basically the spec is saying that you want both N and CTS to be
> integral.  ...as you say you really want:
>   CTS = (TMDS * N) / (128 * audio_freq)

In the case of software-programmed CTS and N values, they have to be
integral because there's no such thing as fractional division here.
The CTS and N values get sent across the HDMI link to the sink, and
they use those in a PLL like arrangement to derive the audio clock.

More "inteligent" hardware automatically measures the CTS number and
continually updates the sink, which allows the sink to remain in
sync with the audio at non-coherent rates.

> ...CTS has no other restrictions (other than being integral) and
> you're allowed a bit of slop for N (you aim for 128 * audio_freq but
> can go up or down a bit).

No.  Both CTS and N have to be accurate to generate the correct
sample rate from the TDMS clock.

> Apparently it's more important to optimize for the CTS formula working
> out then it is for getting close to "128 * audio freq".  ...and that's
> the reason for these special case N values...

The "128 * audio freq" is just a recommendation.  Going through the HDMI
spec's recommended values for various clock rates and sample rates
reveals that quite a number of them are far from this "recommendation".

So I wouldn't read too much into the "128 * audio freq" thing.

> So to put some numbers:
> 
> We're perfect when we have exactly 25.2:
>   25200 * 4096 / (128 * 32)
>   => 25200, so CTS for 25.2 MHz is 25200.  Perfect
> 
> ...but when we have 25.2 / 1.001 we get a non-integral CTS:
>   (25200 / 1.001) * 4096 / (128 * 32)
>   => 25174.82517482518
> 
> ...we can get an integral CTS and still remain in range if:
>   (25200 / 1.001) * 4576 / (128 * 32)
>   => 28125

Correct.  These are the values given in the HDMI specification for each
of your clock rates you mention above.

You can even use 4096 for N _provided_ the source measures and sends
the CTS value (that's basically what happens in the case of
"non-coherent" clocks.)

> In the case of Linux, I'm afraid we just don't have this type of
> accuracy in our APIs.

We don't have that kind of precision in the DRM API, but we do have the
precision in the clock API.

> The spec is talking about making 25.17482517482518 MHz.

+/- 0.5%, according to CEA-861-B.

> As I said, in my case I'm actually making 25170732.

... which is within 0.02%, so is within spec.

> In your case you're probably making the value that Linux
> asked you to make, AKA 25.175000 MHz.

... which is the spec value.

> Unsurprisingly, if you do the
> calculations with 25.175 MHz (or any integral kHz value) you don't
> have to do any 

[PATCH libdrm 14/17] tests/amdgpu: ensure tests work by using c99 initializers

[Emil Velikov]

On 4 September 2015 at 17:33, Alex Deucher  wrote:
> On Mon, Aug 24, 2015 at 1:08 PM, Alex Deucher  
> wrote:
>> On Mon, Aug 24, 2015 at 12:34 PM, Emil Velikov  
>> wrote:
>>> In the latest version of CUnit the fourth parameter of the CU_SuiteInfo
>>> struct is pSetUpFunc rather than *pTests.
>>>
>>> Seems like the CUnit ABI broke at some point, so let's the the robust
>>> thing and use c99 designated initializers to correctly populate the
>>> struct(s).
>>>
>>> Cc: Alex Deucher 
>>> Cc: Leo Liu 
>>> Signed-off-by: Emil Velikov 
>>
>> Reviewed-by: Alex Deucher 
>
> Any plans to push this?
>
Oops, I thought I did just after Chris's feedback.
Thanks for the reminder, they're in definitely in master now.

-Emil

[PATCH 11/15] drm/i915: Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/intel_acpi.c  | 2 +-
 drivers/gpu/drm/i915/intel_panel.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index d96eee1..8b13b9d 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -146,7 +146,7 @@ static bool intel_dsm_detect(void)

if (vga_count == 2 && has_dsm) {
acpi_get_name(intel_dsm_priv.dhandle, ACPI_FULL_PATHNAME, 
);
-   DRM_DEBUG_DRIVER("VGA switcheroo: detected DSM switching method 
%s handle\n",
+   DRM_DEBUG_DRIVER("vga_switcheroo: detected DSM switching method 
%s handle\n",
 acpi_method_name);
return true;
}
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index e2ab3f6..04f7d8e 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -809,7 +809,7 @@ void intel_panel_disable_backlight(struct intel_connector 
*connector)
return;

/*
-* Do not disable backlight on the vgaswitcheroo path. When switching
+* Do not disable backlight on the vga_switcheroo path. When switching
 * away from i915, the other client may depend on i915 to handle the
 * backlight. This will leave the backlight on unnecessarily when
 * another client is not activated.
-- 
1.8.5.2 (Apple Git-48)

[PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 sound/pci/hda/hda_controller.h |  2 +-
 sound/pci/hda/hda_intel.c  | 12 ++--
 sound/pci/hda/hda_intel.h  |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/pci/hda/hda_controller.h b/sound/pci/hda/hda_controller.h
index 314105c..7b635d6 100644
--- a/sound/pci/hda/hda_controller.h
+++ b/sound/pci/hda/hda_controller.h
@@ -153,7 +153,7 @@ struct azx {
unsigned int snoop:1;
unsigned int align_buffer_size:1;
unsigned int region_requested:1;
-   unsigned int disabled:1; /* disabled by VGA-switcher */
+   unsigned int disabled:1; /* disabled by vga_switcheroo */

 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e819013..45233731 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -337,7 +337,7 @@ enum {
 AZX_DCAPS_4K_BDLE_BOUNDARY | AZX_DCAPS_SNOOP_OFF)

 /*
- * VGA-switcher support
+ * vga_switcheroo support
  */
 #ifdef SUPPORT_VGA_SWITCHEROO
 #define use_vga_switcheroo(chip)   ((chip)->use_vga_switcheroo)
@@ -1076,12 +1076,12 @@ static void azx_vs_set_state(struct pci_dev *pci,
}
}
} else {
-   dev_info(chip->card->dev, "%s via VGA-switcheroo\n",
+   dev_info(chip->card->dev, "%s via vga_switcheroo\n",
 disabled ? "Disabling" : "Enabling");
if (disabled) {
pm_runtime_put_sync_suspend(card->dev);
azx_suspend(card->dev);
-   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+   /* when we get suspended by vga_switcheroo we end up in 
D3cold,
 * however we have no ACPI handle, so pci/acpi can't 
put us there,
 * put ourselves there */
pci->current_state = PCI_D3cold;
@@ -1121,7 +1121,7 @@ static void init_vga_switcheroo(struct azx *chip)
struct pci_dev *p = get_bound_vga(chip->pci);
if (p) {
dev_info(chip->card->dev,
-"Handle VGA-switcheroo audio client\n");
+"Handle vga_switcheroo audio client\n");
hda->use_vga_switcheroo = 1;
pci_dev_put(p);
}
@@ -1232,7 +1232,7 @@ static int azx_dev_free(struct snd_device *device)

 #ifdef SUPPORT_VGA_SWITCHEROO
 /*
- * Check of disabled HDMI controller by vga-switcheroo
+ * Check of disabled HDMI controller by vga_switcheroo
  */
 static struct pci_dev *get_bound_vga(struct pci_dev *pci)
 {
@@ -1917,7 +1917,7 @@ static int azx_probe(struct pci_dev *pci,

err = register_vga_switcheroo(chip);
if (err < 0) {
-   dev_err(card->dev, "Error registering VGA-switcheroo client\n");
+   dev_err(card->dev, "Error registering vga_switcheroo client\n");
goto out_free;
}

diff --git a/sound/pci/hda/hda_intel.h b/sound/pci/hda/hda_intel.h
index 354f0bb..ff0c4d6 100644
--- a/sound/pci/hda/hda_intel.h
+++ b/sound/pci/hda/hda_intel.h
@@ -35,7 +35,7 @@ struct hda_intel {
unsigned int irq_pending_warned:1;
unsigned int probe_continued:1;

-   /* VGA-switcheroo setup */
+   /* vga_switcheroo setup */
unsigned int use_vga_switcheroo:1;
unsigned int vga_switcheroo_registered:1;
unsigned int init_failed:1; /* delayed init failed */
-- 
1.8.5.2 (Apple Git-48)

[PATCH] drm/exynos: add cursor plane support

[Inki Dae]

On 2015년 09월 04일 16:19, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
>> Hi Gustavo,
>>
>> I had already a review but I didn't give any comment to you. Sorry about
>> that. This patch looks good to me but one thing isn't clear. Below is my
>> comment.
>>
>>
>> On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
>>> From: Gustavo Padovan 
>>>
>>> Set one of the planes for each crtc driver as a cursor plane enabled
>>> window managers to fully work on exynos.
>>>
>>> Signed-off-by: Gustavo Padovan 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
>>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
>>>  8 files changed, 31 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index b3c7307..79b2b22 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -33,7 +33,6 @@ struct decon_context {
>>> struct exynos_drm_plane planes[WINDOWS_NR];
>>> void __iomem*addr;
>>> struct clk  *clks[6];
>>> -   unsigned intdefault_win;
>>> unsigned long   irq_flags;
>>> int pipe;
>>> boolsuspended;
>>> @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
>>> *master, void *data)
>>> struct drm_device *drm_dev = data;
>>> struct exynos_drm_private *priv = drm_dev->dev_private;
>>> struct exynos_drm_plane *exynos_plane;
>>> -   enum drm_plane_type type;
>>> unsigned int zpos;
>>> int ret;
>>>  
>>> @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct 
>>> device *master, void *data)
>>> ctx->pipe = priv->pipe++;
>>>  
>>> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
>>> -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
>>> -   DRM_PLANE_TYPE_OVERLAY;
>>> ret = exynos_plane_init(drm_dev, >planes[zpos],
>>> -   1 << ctx->pipe, type, decon_formats,
>>> +   1 << ctx->pipe, decon_formats,
>>> ARRAY_SIZE(decon_formats), zpos);
>>> if (ret)
>>> return ret;
>>> }
>>>  
>>> -   exynos_plane = >planes[ctx->default_win];
>>> +   exynos_plane = >planes[DEFAULT_WIN];
>>> ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>>> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>>> _crtc_ops, ctx);
>>> @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct 
>>> platform_device *pdev)
>>> if (!ctx)
>>> return -ENOMEM;
>>>  
>>> -   ctx->default_win = 0;
>>> ctx->suspended = true;
>>> ctx->dev = dev;
>>> if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> index cbdb78e..f3826dc 100644
>>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> @@ -52,7 +52,6 @@ struct decon_context {
>>> struct clk  *eclk;
>>> struct clk  *vclk;
>>> void __iomem*regs;
>>> -   unsigned intdefault_win;
>>> unsigned long   irq_flags;
>>> booli80_if;
>>> boolsuspended;
>>> @@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
>>> *master, void *data)
>>> struct decon_context *ctx = dev_get_drvdata(dev);
>>> struct drm_device *drm_dev = data;
>>> struct exynos_drm_plane *exynos_plane;
>>> -   enum drm_plane_type type;
>>> unsigned int zpos;
>>> int ret;
>>>  
>>> @@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct 
>>> device *master, void *data)
>>> }
>>>  
>>> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
>>> -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
>>> -   DRM_PLANE_TYPE_OVERLAY;
>>> ret = exynos_plane_init(drm_dev, >planes[zpos],
>>> -   1 << ctx->pipe, type, decon_formats,
>>> +   1 << ctx->pipe, decon_formats,
>>> 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #6 from Lauri Gustafsson  ---
An interesting observation is that lspci shows my card as "Hawaii PRO [Radeon
R9 290]" (even though it's not), and dmesg says
"[6.072219] radeon :01:00.0: Invalid ROM contents"

-- 
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/20150904/604f6c02/attachment.html>

[PATCH] drm/exynos: add cursor plane support

[Gustavo Padovan]

Hi Inki,

2015-09-04 Inki Dae :

> Hi Gustavo,
> 
> I had already a review but I didn't give any comment to you. Sorry about
> that. This patch looks good to me but one thing isn't clear. Below is my
> comment.
> 
> 
> On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Set one of the planes for each crtc driver as a cursor plane enabled
> > window managers to fully work on exynos.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
> >  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
> >  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
> >  8 files changed, 31 insertions(+), 39 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > index b3c7307..79b2b22 100644
> > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > @@ -33,7 +33,6 @@ struct decon_context {
> > struct exynos_drm_plane planes[WINDOWS_NR];
> > void __iomem*addr;
> > struct clk  *clks[6];
> > -   unsigned intdefault_win;
> > unsigned long   irq_flags;
> > int pipe;
> > boolsuspended;
> > @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
> > *master, void *data)
> > struct drm_device *drm_dev = data;
> > struct exynos_drm_private *priv = drm_dev->dev_private;
> > struct exynos_drm_plane *exynos_plane;
> > -   enum drm_plane_type type;
> > unsigned int zpos;
> > int ret;
> >  
> > @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct 
> > device *master, void *data)
> > ctx->pipe = priv->pipe++;
> >  
> > for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> > -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> > -   DRM_PLANE_TYPE_OVERLAY;
> > ret = exynos_plane_init(drm_dev, >planes[zpos],
> > -   1 << ctx->pipe, type, decon_formats,
> > +   1 << ctx->pipe, decon_formats,
> > ARRAY_SIZE(decon_formats), zpos);
> > if (ret)
> > return ret;
> > }
> >  
> > -   exynos_plane = >planes[ctx->default_win];
> > +   exynos_plane = >planes[DEFAULT_WIN];
> > ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
> > ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> > _crtc_ops, ctx);
> > @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct 
> > platform_device *pdev)
> > if (!ctx)
> > return -ENOMEM;
> >  
> > -   ctx->default_win = 0;
> > ctx->suspended = true;
> > ctx->dev = dev;
> > if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> > diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > index cbdb78e..f3826dc 100644
> > --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > @@ -52,7 +52,6 @@ struct decon_context {
> > struct clk  *eclk;
> > struct clk  *vclk;
> > void __iomem*regs;
> > -   unsigned intdefault_win;
> > unsigned long   irq_flags;
> > booli80_if;
> > boolsuspended;
> > @@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
> > *master, void *data)
> > struct decon_context *ctx = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = data;
> > struct exynos_drm_plane *exynos_plane;
> > -   enum drm_plane_type type;
> > unsigned int zpos;
> > int ret;
> >  
> > @@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct 
> > device *master, void *data)
> > }
> >  
> > for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> > -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> > -   DRM_PLANE_TYPE_OVERLAY;
> > ret = exynos_plane_init(drm_dev, >planes[zpos],
> > -   1 << ctx->pipe, type, decon_formats,
> > +   1 << ctx->pipe, decon_formats,
> > ARRAY_SIZE(decon_formats), zpos);
> > if (ret)
> > 

[PATCH 2/2] drm/exynos: add cursor plane support

[Gustavo Padovan]

From: Gustavo Padovan 

Set one of the planes for each crtc driver as a cursor plane enabled
window managers to fully work on exynos.

Signed-off-by: Gustavo Padovan 

---
v2: use the top window for cursor on each crtc
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  4 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c |  4 ++--
 7 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2f393b1..4b8dd7c 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -24,6 +24,7 @@
 #include "exynos_drm_iommu.h"

 #define WINDOWS_NR 3
+#define CURSOR_WIN 2
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128

 struct decon_context {
@@ -450,8 +451,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->pipe = priv->pipe++;

for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
+   type = exynos_plane_get_type(zpos, CURSOR_WIN);
ret = exynos_plane_init(drm_dev, >planes[zpos],
1 << ctx->pipe, type, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7a6c069..aa0ae79 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -41,6 +41,7 @@
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 #define WINDOWS_NR 2
+#define CURSOR_WIN 1

 struct decon_context {
struct device   *dev;
@@ -630,8 +631,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
}

for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
+   type = exynos_plane_get_type(zpos, CURSOR_WIN);
ret = exynos_plane_init(drm_dev, >planes[zpos],
1 << ctx->pipe, type, decon_formats,
ARRAY_SIZE(decon_formats), zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7776768..caa5255 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -88,6 +88,7 @@

 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
+#define CURSOR_WIN 4

 struct fimd_driver_data {
unsigned int timing_base;
@@ -909,8 +910,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
ctx->pipe = priv->pipe++;

for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
-   DRM_PLANE_TYPE_OVERLAY;
+   type = exynos_plane_get_type(zpos, CURSOR_WIN);
ret = exynos_plane_init(drm_dev, >planes[zpos],
1 << ctx->pipe, type, fimd_formats,
ARRAY_SIZE(fimd_formats), zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 7148224..80b2151 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -208,6 +208,17 @@ static void exynos_plane_attach_zpos_property(struct 
drm_plane *plane,
drm_object_attach_property(>base, prop, zpos);
 }

+enum drm_plane_type exynos_plane_get_type(unsigned int zpos,
+ unsigned int cursor_win)
+{
+   if (zpos == DEFAULT_WIN)
+   return DRM_PLANE_TYPE_PRIMARY;
+   else if (zpos == cursor_win)
+   return DRM_PLANE_TYPE_CURSOR;
+   else
+   return DRM_PLANE_TYPE_OVERLAY;
+}
+
 int exynos_plane_init(struct drm_device *dev,
  struct exynos_drm_plane *exynos_plane,
  unsigned long possible_crtcs, enum drm_plane_type type,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h 
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index 476c934..abb641e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -9,6 +9,8 @@
  *
  */

+enum drm_plane_type 

[PATCH 1/2] drm/exynos: add global macro for the default primary plane

[Gustavo Padovan]

From: Gustavo Padovan 

Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
Some CRTCs were defining a variable to store the default window, but that
is not necessary as the default (primary) window is always the window zero.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   | 2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 5 ++---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 6 ++
 drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
 6 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 988df06..2f393b1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -33,7 +33,6 @@ struct decon_context {
struct exynos_drm_plane planes[WINDOWS_NR];
void __iomem*addr;
struct clk  *clks[6];
-   unsigned intdefault_win;
unsigned long   irq_flags;
int pipe;

@@ -451,7 +450,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->pipe = priv->pipe++;

for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
+   type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, >planes[zpos],
1 << ctx->pipe, type, decon_formats,
@@ -460,7 +459,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}

-   exynos_plane = >planes[ctx->default_win];
+   exynos_plane = >planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
_crtc_ops, ctx);
@@ -557,7 +556,6 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
if (!ctx)
return -ENOMEM;

-   ctx->default_win = 0;
ctx->dev = dev;
if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
ctx->i80_if = true;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 0776f38..7a6c069 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -52,7 +52,6 @@ struct decon_context {
struct clk  *eclk;
struct clk  *vclk;
void __iomem*regs;
-   unsigned intdefault_win;
unsigned long   irq_flags;
booli80_if;
int pipe;
@@ -631,7 +630,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
}

for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
+   type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, >planes[zpos],
1 << ctx->pipe, type, decon_formats,
@@ -640,7 +639,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}

-   exynos_plane = >planes[ctx->default_win];
+   exynos_plane = >planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
   _crtc_ops, ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5cb9bc3..058abd1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -22,6 +22,8 @@
 #define MAX_PLANE  5
 #define MAX_FB_BUFFER  4

+#define DEFAULT_WIN0
+
 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc, base)
 #define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index dc36e63..7776768 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -154,7 +154,6 @@ struct fimd_context {
struct clk  *lcd_clk;
void __iomem*regs;
 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #5 from Lauri Gustafsson  ---
Created attachment 118083
  --> https://bugs.freedesktop.org/attachment.cgi?id=118083=edit
Dmesg from 4.2 kernel DPM enabled before crash/hang

-- 
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/20150904/c05df9dd/attachment.html>

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Russell,

On Fri, Sep 4, 2015 at 5:27 PM, Russell King - ARM Linux
 wrote:
> On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
>>  wrote:
>> >> In your case you're probably making the value that Linux
>> >> asked you to make, AKA 25.175000 MHz.
>> >
>> > ... which is the spec value.
>>
>> This is where we're not on the same page.  Where in the spec does it
>> say 25.17500 MHz?  I see in the spec:
>>  25.2 / 1.001
>
> Section 4 of CEA-861-B, which defines the video clock rates and their
> accuracy of 0.5%.

Then perhaps you shouldn't be using a switch statement.  You won't
catch all values that are within .05% of (25.2 / 1.001).


>> ...and this is a crucial difference here.  Please double-check my math, but:
>>
>> (25175000 * 4576) / (128 * 32000.)
>> => 28125.1953125
>>
>> (25174825 * 4576) / (128 * 32000.)
>> => 28125.0
>>
>> This calculation is what led to my belief that the goal here is to
>> make an integral CTS.  If you have 25.175 MHZ clock and N of 4576 you
>> _will not_ have an integral CTS.  If you instead have 25.174825 MHz
>> clock and N of 4576 you _will_ have an integral CTS.
>
> Right, but 25.175 is close enough to 25.174825.  Do this calculation:
>
> 25175000 * 4576 / 28125 / 128
>
> That'll give you the resulting audio sample rate, which is 32000.222Hz.
> That's an error of... 0.00069%, which is probably around the typical
> error of your average crystal oscillator.  Really not worth bothering
> with.

OK, so do this calculation:

25175000 * 4096 / 25175 / 128

You get 32000.00

I'm not saying there's anything terribly wrong with 32000.222 Hz and
I'm sure it will work just dandy for you.  I'm saying that you're
adding complexity _and_ ending up with a slightly worse rate.

AKA: just replace your entire "compute_n" function with:

return (128 * freq) / 1000;

...and it's 100% simpler _and_ gets you a (marginally) better rate
(assuming you really have 22.175000).  If it was just about a
32000.222 vs 32000 I'd not be saying anything right now.  It's about
adding complexity.


>> Said another way:
>>
>> 1. The reason 25174825 Hz has a different N is to make an integral CTS.
>>
>> 2. If you are indeed making 25175000 then there is no need for a
>> different N to make an integral CTS
>>
>> 3. If you use 4576 for N but you're making 25175000 Hz, you end up in
>> a _worse_ position than if you use the standard 4096 for N.
>
> Total rubbish.  Sorry, but it is.
>
> Follow the code.  Pixel clock is 25175000.  For 32kHz, N will be 4576.
> 25175000 * 4576 = 1.152008e11.  Divide that by the audio clock rate
> (128 * 32000) gives 28125.19531.  Since we're using integer division,
> that gets rounded down to 28125.
>
> DRM uses a clock rate of "25175" to represent 25.2/1.001 modes.  So,
> if your hardware sets a video clock rate of 25.2MHz/1.001, then you
> end up with a sample rate of exactly 32kHz.  If you set exactly
> 25.175MHz, you end up with an approximate 32kHz sample rate - one
> which is 0.00069% in error, which is (excluse the language) fuck all
> different from exactly 32kHz.

Agree that the difference is negligible.

I will say that IMHO the kind folks who wrote the HDMI spec were still
trying their best to make that error 0.00%.  That's entirely the
reason that they have that table and they don't just use "(128 * freq)
/ 1000" for everything.

AKA, I can imagine something like:

Person 1: Is there any reason to pick a N value that's exactly (128 *
freq) / 1000?

Person 2: Not really

Person 1: Hrm, but I notice that I can get a tiny bit more accurate
audio clock when I have a pixel clock of (25.2 / 1.001) if I use a N
that's not (128 * freq) / 1000.  Is that OK?

Person 2: Yeah, go ahead.  Add it to the spec.

Person 1: OK.  I've got some nifty tables I can add.  Cool!  Now we
get exactly the right audio clock.

Person 2: Nice job!

...but I have no idea if that's really true.


> Are you _really_ going to continue arguing over a 0.00069% error?
> If you are, I'm not going to listen anymore - it's soo damned small
> that it's not worth bothering with.  At all.

Well, I think I've adequately expressed my opinion.  If you want to
land your patch, I certainly won't yell.  I think it adds extra
complexity and produces a (marginally) inferior audio rate, but that's
up to the folks who maintain the code to deal with.


>> As a side note: I realized one part of the HDMI spec that isn't trying
>> to make an integral value but still uses a different value for N: 297
>> MHz.  From the DesignWare spec I have it appears that 594 MHz is
>> similar.  For those cases it looks like we have:
>
> 297MHz _does_ work.
>
> 29700 * 3072 / 222750 = 128 * 32000 exactly.

I guess I didn't express myself clearly enough.  I'm saying that:

* The only reason I can discern for using non "(128 * freq) / 1000" N
values for rates < 297 Mhz is to try to make an integral CTS.

* For rates >= 297 MHz you could make CTS 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #4 from Lauri Gustafsson  ---
(In reply to Alex Deucher from comment #1)
> It's supported.  Please attach your xorg log, dmesg output and a copy of
> your vbios.  To get a copy of your vbios:
> (as root)
> (use lspci to get the bus id)
> cd /sys/bus/pci/devices/
> echo 1 > rom
> cat rom > /tmp/vbios.rom
> echo 0 > rom

Thanks for responding. I added the log and the ROM.
Still, even on the newest Linux from Git I get a display crash/hang whithout
disabling DPM in Kernel line, so I'm not sure if I can supply an Xorg log with
DPM switched on.
Performance on this freshly built kernel (without DPM) is still the same as
before: somewhat low.

-- 
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/20150904/3f3d3117/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #3 from Lauri Gustafsson  ---
Created attachment 118082
  --> https://bugs.freedesktop.org/attachment.cgi?id=118082=edit
My MSI r9 390 VBIOS ROM

-- 
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/20150904/08264c8d/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #2 from Lauri Gustafsson  ---
Created attachment 118081
  --> https://bugs.freedesktop.org/attachment.cgi?id=118081=edit
An xorg log on Linux 4.2 and dmp disabled

-- 
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/20150904/c231ef48/attachment.html>

[pull] amdgpu drm-next-4.3

[Alex Deucher]

Hi Dave,

A few more fixes for amdgpu from the last few days:
- Fix several copy paste typos
- Resume from suspend fixes for VCE
- Fix the GPU scheduler warning in kfifo_out
- Re-enable GPUVM fault interrupts which were inadvertently disabled
- GPUVM page table hang fix when paging

The following changes since commit bddf8026386927985ef6d0d11c3ba78f70b76bad:

  drm/amdgpu: set MEC doorbell range for Fiji (2015-09-02 12:35:52 -0400)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.3

for you to fetch changes up to 35c7a9526af75040fac744babd0fafe18b8fe0a1:

  drm/amdgpu: rename gmc_v8_0_init_compute_vmid (2015-09-04 16:36:28 -0400)


Alex Deucher (8):
  drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
  drm/amdgpu: use top down allocation for non-CPU accessible vram
  drm/amdgpu: fix typo in dce10 watermark setup
  drm/amdgpu: fix typo in dce11 watermark setup
  drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
  drm/amdgpu: fix warning in scheduler
  drm/amdgpu: fix vce3 instance handling
  drm/amdgpu: rename gmc_v8_0_init_compute_vmid

Christian König (2):
  drm/amdgpu: fix buffer placement under memory pressure
  drm/amdgpu: properly enable VM fault interrupts

Leo Liu (1):
  drm/amdgpu: remove ib test for the second VCE Ring

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c  |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   | 12 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   |  8 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  7 ++--
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c   |  4 +--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/fiji_smc.c |  8 +++--
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  6 ++--
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 16 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 17 +-
 drivers/gpu/drm/amd/amdgpu/iceland_smc.c  |  4 ++-
 drivers/gpu/drm/amd/amdgpu/tonga_smc.c|  8 +++--
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 48 +++
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c |  5 +--
 22 files changed, 127 insertions(+), 52 deletions(-)

[PATCH 10/10] drm/exynos: add pm_runtime to DECON 7

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 125 -
 1 file changed, 53 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index e4646e2..517ba7a 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -54,7 +54,6 @@ struct decon_context {
void __iomem*regs;
unsigned long   irq_flags;
booli80_if;
-   boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
@@ -85,9 +84,6 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
atomic_set(>wait_vsync_event, 1);

/*
@@ -119,13 +115,8 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
}

/* Wait for vsync, as disable channel takes effect at next vsync */
-   if (ch_enabled) {
-   unsigned int state = ctx->suspended;
-
-   ctx->suspended = 0;
+   if (ch_enabled)
decon_wait_for_vblank(ctx->crtc);
-   ctx->suspended = state;
-   }
 }

 static int decon_ctx_initialize(struct decon_context *ctx,
@@ -180,9 +171,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
struct drm_display_mode *mode = >base.state->adjusted_mode;
u32 val, clkdiv;

-   if (ctx->suspended)
-   return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -244,9 +232,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
-   return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);

@@ -269,9 +254,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
-   return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);

@@ -399,9 +381,6 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, true);
 }

@@ -419,9 +398,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];

-   if (ctx->suspended)
-   return;
-
/*
 * SHADOWCON/PRTCON register is used for enabling timing.
 *
@@ -518,9 +494,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
unsigned int win = plane->zpos;
u32 val;

-   if (ctx->suspended)
-   return;
-
/* protect windows */
decon_shadow_protect_win(ctx, win, true);

@@ -539,9 +512,6 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, false);
 }

@@ -565,39 +535,9 @@ static void decon_init(struct decon_context *ctx)
 static void decon_enable(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
-   int ret;
-
-   if (!ctx->suspended)
-   return;
-
-   ctx->suspended = false;

pm_runtime_get_sync(ctx->dev);

-   ret = clk_prepare_enable(ctx->pclk);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->aclk);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->eclk);
-   if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->vclk);
-   if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
-   return;
-   }
-
decon_init(ctx);

/* if vblank was enabled status, enable it again. */
@@ -612,9 +552,6 @@ static void decon_disable(struct exynos_drm_crtc 

[PATCH 09/10] drm/exynos: add pm_runtime to DECON 5433

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 89 ---
 1 file changed, 39 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 838a9c1..f0b7804 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -35,7 +35,6 @@ struct decon_context {
struct clk  *clks[6];
unsigned long   irq_flags;
int pipe;
-   boolsuspended;

 #define BIT_CLKS_ENABLED   0
 #define BIT_IRQS_ENABLED   1
@@ -65,9 +64,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
-   return -EPERM;
-
if (test_and_set_bit(0, >irq_flags)) {
val = VIDINTCON0_INTEN;
if (ctx->i80_if)
@@ -85,9 +81,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
if (test_and_clear_bit(0, >irq_flags))
writel(0, ctx->addr + DECON_VIDINTCON0);
 }
@@ -105,9 +98,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
struct drm_display_mode *mode = >base.mode;
u32 val;

-   if (ctx->suspended)
-   return;
-
/* enable clock gate */
val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
writel(val, ctx->addr + DECON_CMU);
@@ -230,9 +220,6 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, true);
 }

@@ -246,9 +233,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int pitch = state->fb->pitches[0];
u32 val;

-   if (ctx->suspended)
-   return;
-
val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
writel(val, ctx->addr + DECON_VIDOSDxA(win));

@@ -293,9 +277,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
unsigned int win = plane->zpos;
u32 val;

-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, win, true);

/* window disable */
@@ -316,9 +297,6 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, false);

if (ctx->i80_if)
@@ -351,22 +329,9 @@ static void decon_swreset(struct decon_context *ctx)
 static void decon_enable(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
-   int ret;
-   int i;
-
-   if (!ctx->suspended)
-   return;
-
-   ctx->suspended = false;

pm_runtime_get_sync(ctx->dev);

-   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
-   ret = clk_prepare_enable(ctx->clks[i]);
-   if (ret < 0)
-   goto err;
-   }
-
set_bit(BIT_CLKS_ENABLED, >enabled);

/* if vblank was enabled status, enable it again. */
@@ -376,11 +341,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
decon_commit(ctx->crtc);

return;
-err:
-   while (--i >= 0)
-   clk_disable_unprepare(ctx->clks[i]);
-
-   ctx->suspended = true;
 }

 static void decon_disable(struct exynos_drm_crtc *crtc)
@@ -388,9 +348,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
int i;

-   if (ctx->suspended)
-   return;
-
/*
 * We need to make sure that all windows are disabled before we
 * suspend that connector. Otherwise we might try to scan from
@@ -401,14 +358,9 @@ static void decon_disable(struct exynos_drm_crtc *crtc)

decon_swreset(ctx);

-   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++)
-   clk_disable_unprepare(ctx->clks[i]);
-
clear_bit(BIT_CLKS_ENABLED, >enabled);

pm_runtime_put_sync(ctx->dev);
-
-   ctx->suspended = true;
 }

 void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
@@ -475,7 +427,6 @@ err:
 static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable= decon_disable,
-   .commit = decon_commit,
.enable_vblank  = decon_enable_vblank,

[PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD

[Gustavo Padovan]

From: Gustavo Padovan 

Instead of having a .clock_enable callback enable the dp clock directly
from FIMD.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  | 13 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  5 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 +---
 3 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 6794982..aa11d18 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -37,11 +37,6 @@
 #define ctx_from_connector(c)  container_of(c, struct exynos_dp_device, \
connector)

-static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
-{
-   return to_exynos_crtc(dp->encoder.crtc);
-}
-
 static inline struct exynos_dp_device *encoder_to_dp(
struct drm_encoder *e)
 {
@@ -1068,7 +1063,6 @@ static void exynos_dp_mode_set(struct drm_encoder 
*encoder,
 static void exynos_dp_enable(struct drm_encoder *encoder)
 {
struct exynos_dp_device *dp = encoder_to_dp(encoder);
-   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

pm_runtime_get_sync(dp->dev);

@@ -1079,9 +1073,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
}
}

-   if (crtc->ops->clock_enable)
-   crtc->ops->clock_enable(dp_to_crtc(dp), true);
-
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
@@ -1091,7 +1082,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
 static void exynos_dp_disable(struct drm_encoder *encoder)
 {
struct exynos_dp_device *dp = encoder_to_dp(encoder);
-   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
@@ -1104,9 +1094,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
flush_work(>hotplug_work);
phy_power_off(dp->phy);

-   if (crtc->ops->clock_enable)
-   crtc->ops->clock_enable(dp_to_crtc(dp), false);
-
if (dp->panel) {
if (drm_panel_unprepare(dp->panel))
DRM_ERROR("failed to turnoff the panel\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5f1a4d6..ee60619 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -96,10 +96,6 @@ struct exynos_drm_plane {
  * @disable_plane: disable hardware specific overlay.
  * @te_handler: trigger to transfer video image at the tearing effect
  * synchronization signal if there is a page flip request.
- * @clock_enable: optional function enabling/disabling display domain clock,
- * called from exynos-dp driver before powering up (with
- * 'enable' argument as true) and after powering down (with
- * 'enable' as false).
  */
 struct exynos_drm_crtc;
 struct exynos_drm_crtc_ops {
@@ -120,7 +116,6 @@ struct exynos_drm_crtc_ops {
void (*atomic_flush)(struct exynos_drm_crtc *crtc,
  struct exynos_drm_plane *plane);
void (*te_handler)(struct exynos_drm_crtc *crtc);
-   void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0f17ae0..3cf2b80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -573,6 +573,23 @@ static void fimd_win_set_colkey(struct fimd_context *ctx, 
unsigned int win)
writel(keycon1, ctx->regs + WKEYCON1_BASE(win));
 }

+static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
+{
+   struct fimd_context *ctx = crtc->ctx;
+   u32 val;
+
+   /*
+* Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
+* clock. On these SoCs the bootloader may enable it but any
+* power domain off/on will reset it to disable state.
+*/
+   if (ctx->driver_data != _fimd_driver_data)
+   return;
+
+   val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
+   writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
+}
+
 /**
  * shadow_protect_win() - disable updating values from shadow registers at 
vsync
  *
@@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
if (test_and_clear_bit(0, >irq_flags))
fimd_enable_vblank(ctx->crtc);

+   fimd_dp_clock_enable(crtc, true);
+
fimd_commit(ctx->crtc);
 }

@@ -743,6 +762,8 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
struct fimd_context *ctx = crtc->ctx;
int i;

+   fimd_dp_clock_enable(crtc, false);
+
/*
 * We need to make sure that all windows 

[PATCH 07/10] drm/exynos: add pm_runtime to FIMD

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  1 -
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 91 +++
 3 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 79b2b22..838a9c1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.commit = decon_commit,
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
-   .commit = decon_commit,
.atomic_begin   = decon_atomic_begin,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f3826dc..e4646e2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
.mode_fixup = decon_mode_fixup,
-   .commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.wait_for_vblank = decon_wait_for_vblank,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0bbe537..0f17ae0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,7 +160,6 @@ struct fimd_context {
u32 vidout_con;
u32 i80ifcon;
booli80_if;
-   boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
@@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
-   return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);

@@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;

-   if (ctx->suspended)
-   return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);

@@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
 {
struct fimd_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
atomic_set(>wait_vsync_event, 1);

/*
@@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
*crtc)
int pipe = ctx->pipe;

/* ensure that vblank interrupt won't be reported to core */
-   ctx->suspended = false;
ctx->pipe = -1;

fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);

-   ctx->suspended = true;
ctx->pipe = pipe;
}

@@ -394,9 +382,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
void *timing_base = ctx->regs + driver_data->timing_base;
u32 val, clkdiv;

-   if (ctx->suspended)
-   return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -630,9 +615,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct fimd_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
fimd_shadow_protect_win(ctx, plane->zpos, true);
 }

@@ -641,9 +623,6 @@ static void fimd_atomic_flush(struct exynos_drm_crtc *crtc,
 {
struct fimd_context *ctx = crtc->ctx;

-   if (ctx->suspended)
-   return;
-
fimd_shadow_protect_win(ctx, plane->zpos, false);
 }

@@ -659,9 +638,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];

-   if (ctx->suspended)
-   return;
-
offset = plane->src_x * bpp;
offset += plane->src_y * pitch;

@@ -743,9 +719,6 @@ static void fimd_disable_plane(struct exynos_drm_crtc *crtc,

[PATCH 06/10] drm/exynos: Remove exynos_crtc commit() callback

[Gustavo Padovan]

From: Gustavo Padovan 

This callback is no longer used by any of the exynos_crtc drivers, remove
it.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  2 --
 2 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0872aa2f..deff5a7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -55,15 +55,6 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

-static void
-exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
-   if (exynos_crtc->ops->commit)
-   exynos_crtc->ops->commit(exynos_crtc);
-}
-
 static void exynos_crtc_atomic_begin(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
@@ -100,7 +91,6 @@ static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs 
= {
.enable = exynos_drm_crtc_enable,
.disable= exynos_drm_crtc_disable,
.mode_fixup = exynos_drm_crtc_mode_fixup,
-   .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
.atomic_begin   = exynos_crtc_atomic_begin,
.atomic_flush   = exynos_crtc_atomic_flush,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc56c3d..5f1a4d6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -86,7 +86,6 @@ struct exynos_drm_plane {
  * @enable: enable the device
  * @disable: disable the device
  * @mode_fixup: fix mode data before applying it
- * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
  * @wait_for_vblank: wait for vblank interrupt to make sure that
@@ -109,7 +108,6 @@ struct exynos_drm_crtc_ops {
bool (*mode_fixup)(struct exynos_drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
-   void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
-- 
2.1.0

[PATCH 05/10] drm/exynos: remove exynos_crtc commit() callback

[Gustavo Padovan]

From: Gustavo Padovan 

It turns out that .commit() was never executed, because
at the time .mode_set_nofb() called it ctx->suspended was still false
and .commit() would return. It removes the callback from FIMD DECON 7 and
DECON 5433.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2697ebc..0bbe537 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -888,7 +888,6 @@ static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.enable = fimd_enable,
.disable = fimd_disable,
.mode_fixup = fimd_mode_fixup,
-   .commit = fimd_commit,
.enable_vblank = fimd_enable_vblank,
.disable_vblank = fimd_disable_vblank,
.wait_for_vblank = fimd_wait_for_vblank,
-- 
2.1.0

[PATCH 04/10] drm/exynos: add pm_runtime to Mixer

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 125 +-
 1 file changed, 61 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2484277..dc48084 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -71,7 +71,6 @@ enum mixer_version_id {
 };

 enum mixer_flag_bits {
-   MXR_BIT_POWERED,
MXR_BIT_VSYNC,
 };

@@ -927,8 +926,6 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = _ctx->mixer_res;

__set_bit(MXR_BIT_VSYNC, _ctx->flags);
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return 0;

/* enable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -944,9 +941,6 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)

__clear_bit(MXR_BIT_VSYNC, _ctx->flags);

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
@@ -959,9 +953,6 @@ static void mixer_update_plane(struct exynos_drm_crtc *crtc,

DRM_DEBUG_KMS("win: %d\n", plane->zpos);

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
if (plane->zpos > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, plane);
else
@@ -977,9 +968,6 @@ static void mixer_disable_plane(struct exynos_drm_crtc 
*crtc,

DRM_DEBUG_KMS("win: %d\n", plane->zpos);

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
spin_lock_irqsave(>reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);

@@ -994,9 +982,6 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
int err;

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
if (err < 0) {
DRM_DEBUG_KMS("failed to acquire vblank counter\n");
@@ -1021,43 +1006,9 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 {
struct mixer_context *ctx = crtc->ctx;
struct mixer_resources *res = >mixer_res;
-   int ret;
-
-   if (test_bit(MXR_BIT_POWERED, >flags))
-   return;

pm_runtime_get_sync(ctx->dev);

-   ret = clk_prepare_enable(res->mixer);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the mixer clk [%d]\n", ret);
-   return;
-   }
-   ret = clk_prepare_enable(res->hdmi);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
-   return;
-   }
-   if (ctx->vp_enabled) {
-   ret = clk_prepare_enable(res->vp);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vp clk [%d]\n",
- ret);
-   return;
-   }
-   if (ctx->has_sclk) {
-   ret = clk_prepare_enable(res->sclk_mixer);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the " \
-  "sclk_mixer clk [%d]\n",
- ret);
-   return;
-   }
-   }
-   }
-
-   set_bit(MXR_BIT_POWERED, >flags);
-
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);

if (test_bit(MXR_BIT_VSYNC, >flags)) {
@@ -1070,29 +1021,15 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 static void mixer_disable(struct exynos_drm_crtc *crtc)
 {
struct mixer_context *ctx = crtc->ctx;
-   struct mixer_resources *res = >mixer_res;
int i;

-   if (!test_bit(MXR_BIT_POWERED, >flags))
-   return;
-
mixer_stop(ctx);
mixer_regs_dump(ctx);

for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);

-   clear_bit(MXR_BIT_POWERED, >flags);
-
-   clk_disable_unprepare(res->hdmi);
-   clk_disable_unprepare(res->mixer);
-   if (ctx->vp_enabled) {
-   clk_disable_unprepare(res->vp);
-   if (ctx->has_sclk)
-   clk_disable_unprepare(res->sclk_mixer);
-   }
-
-   pm_runtime_put_sync(ctx->dev);
+   pm_runtime_put(ctx->dev);
 }

 /* Only valid for Mixer version 16.0.33.0 */
@@ -1288,10 

[PATCH 03/10] drm/exynos: add pm_runtime to HDMI

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
 1 file changed, 39 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 932f7fa..5fcbdda 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -92,7 +92,6 @@ struct hdmi_context {
struct drm_device   *drm_dev;
struct drm_connectorconnector;
boolhpd;
-   boolpowered;
booldvi_mode;

void __iomem*regs;
@@ -1726,11 +1725,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
struct hdmi_context *hdata = encoder_to_hdmi(encoder);
struct hdmi_resources *res = >res;

-   if (hdata->powered)
-   return;
-
-   hdata->powered = true;
-
pm_runtime_get_sync(hdata->dev);

if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
@@ -1740,9 +1734,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
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);
-
hdmiphy_poweron(hdata);
hdmi_conf_apply(hdata);
 }
@@ -1754,9 +1745,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
struct drm_crtc *crtc = encoder->crtc;
const struct drm_crtc_helper_funcs *funcs = NULL;

-   if (!hdata->powered)
-   return;
-
/*
 * The SFRs of VP and Mixer are updated by Vertical Sync of
 * Timing generator which is a part of HDMI so the sequence
@@ -1778,9 +1766,6 @@ static void hdmi_disable(struct drm_encoder *encoder)

cancel_delayed_work(>hotplug_work);

-   clk_disable_unprepare(res->sclk_hdmi);
-   clk_disable_unprepare(res->hdmi);
-
/* reset pmu hdmiphy control bit to disable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
@@ -1788,8 +1773,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
regulator_bulk_disable(res->regul_count, res->regul_bulk);

pm_runtime_put_sync(hdata->dev);
-
-   hdata->powered = false;
 }

 static struct drm_encoder_helper_funcs exynos_hdmi_encoder_helper_funcs = {
@@ -2146,12 +2129,51 @@ static int hdmi_remove(struct platform_device *pdev)
return 0;
 }

+#ifdef CONFIG_PM_SLEEP
+static int exynos_hdmi_suspend(struct device *dev)
+{
+   struct hdmi_context *hdata = dev_get_drvdata(dev);
+   struct hdmi_resources *res = >res;
+
+   clk_disable_unprepare(res->sclk_hdmi);
+   clk_disable_unprepare(res->hdmi);
+
+   return 0;
+}
+
+static int exynos_hdmi_resume(struct device *dev)
+{
+   struct hdmi_context *hdata = dev_get_drvdata(dev);
+   struct hdmi_resources *res = >res;
+   int ret;
+
+   ret = clk_prepare_enable(res->hdmi);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
+   return ret;
+   }
+   ret = clk_prepare_enable(res->sclk_hdmi);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the sclk_mixer clk [%d]\n",
+ ret);
+   return ret;
+   }
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_hdmi_pm_ops = {
+   SET_RUNTIME_PM_OPS(exynos_hdmi_suspend, exynos_hdmi_resume, NULL)
+};
+
 struct platform_driver hdmi_driver = {
.probe  = hdmi_probe,
.remove = hdmi_remove,
.driver = {
.name   = "exynos-hdmi",
.owner  = THIS_MODULE,
+   .pm = _hdmi_pm_ops,
.of_match_table = hdmi_match_types,
},
 };
-- 
2.1.0

[PATCH 02/10] drm/exynos: add pm_runtime to DP

[Gustavo Padovan]

From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 40 +
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index c73aff1..6794982 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1070,8 +1070,7 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
struct exynos_dp_device *dp = encoder_to_dp(encoder);
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

-   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
-   return;
+   pm_runtime_get_sync(dp->dev);

if (dp->panel) {
if (drm_panel_prepare(dp->panel)) {
@@ -1083,13 +1082,10 @@ static void exynos_dp_enable(struct drm_encoder 
*encoder)
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), true);

-   clk_prepare_enable(dp->clock);
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
exynos_dp_commit(>encoder);
-
-   dp->dpms_mode = DRM_MODE_DPMS_ON;
 }

 static void exynos_dp_disable(struct drm_encoder *encoder)
@@ -1097,9 +1093,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
struct exynos_dp_device *dp = encoder_to_dp(encoder);
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

-   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
-   return;
-
if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
DRM_ERROR("failed to disable the panel\n");
@@ -1110,7 +1103,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
disable_irq(dp->irq);
flush_work(>hotplug_work);
phy_power_off(dp->phy);
-   clk_disable_unprepare(dp->clock);

if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), false);
@@ -1120,7 +1112,7 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
DRM_ERROR("failed to turnoff the panel\n");
}

-   dp->dpms_mode = DRM_MODE_DPMS_OFF;
+   pm_runtime_put_sync(dp->dev);
 }

 static struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
@@ -1216,7 +1208,6 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
int pipe, ret = 0;

dp->dev = >dev;
-   dp->dpms_mode = DRM_MODE_DPMS_OFF;

dp->video_info = exynos_dp_dt_parse_pdata(>dev);
if (IS_ERR(dp->video_info))
@@ -1341,6 +1332,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *panel_node, *bridge_node, *endpoint;
struct exynos_dp_device *dp;
+   int ret;

dp = devm_kzalloc(>dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -1369,11 +1361,23 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

-   return component_add(>dev, _dp_ops);
+   pm_runtime_enable(dev);
+
+   ret = component_add(>dev, _dp_ops);
+   if (ret)
+   goto err_disable_pm_runtime;
+
+   return ret;
+
+err_disable_pm_runtime:
+   pm_runtime_disable(dev);
+
+   return ret;
 }

 static int exynos_dp_remove(struct platform_device *pdev)
 {
+   pm_runtime_disable(>dev);
component_del(>dev, _dp_ops);

return 0;
@@ -1384,21 +1388,29 @@ static int exynos_dp_suspend(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_disable(>encoder);
+   clk_disable_unprepare(dp->clock);
+
return 0;
 }

 static int exynos_dp_resume(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(dp->clock);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   return ret;
+   }

-   exynos_dp_enable(>encoder);
return 0;
 }
 #endif

 static const struct dev_pm_ops exynos_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
+   SET_RUNTIME_PM_OPS(exynos_dp_suspend, exynos_dp_resume, NULL)
 };

 static const struct of_device_id exynos_dp_match[] = {
-- 
2.1.0

[PATCH 01/10] drm/exynos: do not start enabling DP at bind() phase

[Gustavo Padovan]

From: Gustavo Padovan 

The DP device will be properly enabled at the enable() call just
after the bind call finishes.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..c73aff1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1289,10 +1289,6 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

INIT_WORK(>hotplug_work, exynos_dp_hotplug);

-   phy_power_on(dp->phy);
-
-   exynos_dp_init_dp(dp);
-
ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler,
irq_flags, "exynos-dp", dp);
if (ret) {
-- 
2.1.0

[PATCH 00/10] drm/exynos: add pm_runtime support

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

This series adds proper runtime PM suport to CRTCs and Encoders, so
now instead of relying on 'suspended' or 'enabled' flags to track when
the CRTC or Encoder is enabled we let the pm_runtime subsystem do it for us
and remove all the flags. This is a important step to the atomic suspend/resume
support that will land in drm anytime soon.

Please review!

Gustavo

Gustavo Padovan (10):
  drm/exynos: do not start enabling DP at bind() phase
  drm/exynos: add pm_runtime to DP
  drm/exynos: add pm_runtime to HDMI
  drm/exynos: add pm_runtime to Mixer
  drm/exynos: remove exynos_crtc commit() callback
  drm/exynos: Remove exynos_crtc commit() callback
  drm/exynos: add pm_runtime to FIMD
  drm/exynos: Enable DP clock directly from FIMD
  drm/exynos: add pm_runtime to DECON 5433
  drm/exynos: add pm_runtime to DECON 7

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  90 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 126 +++--
 drivers/gpu/drm/exynos/exynos_dp_core.c   |  57 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  10 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   7 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 129 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  56 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 125 -
 8 files changed, 275 insertions(+), 325 deletions(-)

-- 
2.1.0

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Russell,

On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
 wrote:
>> Basically the spec is saying that you want both N and CTS to be
>> integral.  ...as you say you really want:
>>   CTS = (TMDS * N) / (128 * audio_freq)
>
> In the case of software-programmed CTS and N values, they have to be
> integral because there's no such thing as fractional division here.
> The CTS and N values get sent across the HDMI link to the sink, and
> they use those in a PLL like arrangement to derive the audio clock.
>
> More "inteligent" hardware automatically measures the CTS number and
> continually updates the sink, which allows the sink to remain in
> sync with the audio at non-coherent rates.
>
>> ...CTS has no other restrictions (other than being integral) and
>> you're allowed a bit of slop for N (you aim for 128 * audio_freq but
>> can go up or down a bit).
>
> No.  Both CTS and N have to be accurate to generate the correct
> sample rate from the TDMS clock.

I guess by "other" I meant no restrictions other than that, which is
listed above that "CTS = (TMDS * N) / (128 * audio_freq)".  Anyway,
sounds like we're on the same page here...


>> Apparently it's more important to optimize for the CTS formula working
>> out then it is for getting close to "128 * audio freq".  ...and that's
>> the reason for these special case N values...
>
> The "128 * audio freq" is just a recommendation.  Going through the HDMI
> spec's recommended values for various clock rates and sample rates
> reveals that quite a number of them are far from this "recommendation".
>
> So I wouldn't read too much into the "128 * audio freq" thing.

Again, same page.


>> So to put some numbers:
>>
>> We're perfect when we have exactly 25.2:
>>   25200 * 4096 / (128 * 32)
>>   => 25200, so CTS for 25.2 MHz is 25200.  Perfect
>>
>> ...but when we have 25.2 / 1.001 we get a non-integral CTS:
>>   (25200 / 1.001) * 4096 / (128 * 32)
>>   => 25174.82517482518
>>
>> ...we can get an integral CTS and still remain in range if:
>>   (25200 / 1.001) * 4576 / (128 * 32)
>>   => 28125
>
> Correct.  These are the values given in the HDMI specification for each
> of your clock rates you mention above.
>
> You can even use 4096 for N _provided_ the source measures and sends
> the CTS value (that's basically what happens in the case of
> "non-coherent" clocks.)
>
>> In the case of Linux, I'm afraid we just don't have this type of
>> accuracy in our APIs.
>
> We don't have that kind of precision in the DRM API, but we do have the
> precision in the clock API.

Yup.  On the same page.  See my suggestions of using the common clock framework.


>> The spec is talking about making 25.17482517482518 MHz.
>
> +/- 0.5%, according to CEA-861-B.
>
>> As I said, in my case I'm actually making 25170732.
>
> ... which is within 0.02%, so is within spec.

Yup, that's why we're doing it.  Note that total jitter has to be
under +/- 0.5% right?  ...so if you've got error here you've got to
make sure your clock is extra clean I think.


>> In your case you're probably making the value that Linux
>> asked you to make, AKA 25.175000 MHz.
>
> ... which is the spec value.

This is where we're not on the same page.  Where in the spec does it
say 25.17500 MHz?  I see in the spec:
 25.2 / 1.001

...and this is a crucial difference here.  Please double-check my math, but:

(25175000 * 4576) / (128 * 32000.)
=> 28125.1953125

(25174825 * 4576) / (128 * 32000.)
=> 28125.0

This calculation is what led to my belief that the goal here is to
make an integral CTS.  If you have 25.175 MHZ clock and N of 4576 you
_will not_ have an integral CTS.  If you instead have 25.174825 MHz
clock and N of 4576 you _will_ have an integral CTS.

Said another way:

1. The reason 25174825 Hz has a different N is to make an integral CTS.

2. If you are indeed making 25175000 then there is no need for a
different N to make an integral CTS

3. If you use 4576 for N but you're making 25175000 Hz, you end up in
a _worse_ position than if you use the standard 4096 for N.


>> Unsurprisingly, if you do the
>> calculations with 25.175 MHz (or any integral kHz value) you don't
>> have to do any special optimization to stay integral:
>>
>>   25175 * 4096 / (128 * 32)
>>   => 25175
>>
>>
>> So unless you have some way to know that the underlying clock is
>> actually (25.2 / 1.001) MHz and not just 25.175 MHz then your patch
>> looks wrong.
>
> I don't believe you can make that statement.  If you wish to take the
> lack of precision up with the authors of the CEA-861 and HDMI
> specifications, since they "approximate" to the values I have in this
> patch, and are what userspace passes in the mode structures to kernel
> space.

I will repeat my mantra: I'm a visitor here and decidedly not an
expert.  However, from my reading of the HDMI spec shows that the spec
itself is fine.  They are just assuming that you're providing a
25.174825 MHz clock and giving you optimized values for said clock.

If the current driver says 

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Rob Herring]

On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang  wrote:
> Hi Rob,
>
> 在 09/03/2015 04:17 AM, Rob Herring 写道:
>>
>> On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang  wrote:
>>>
>>> Some edp screen do not have hpd signal, so we can't just return
>>> failed when hpd plug in detect failed.
>>
>> This is a property of the panel (or connector perhaps), so this
>> property should be located there. At least, it is a common issue and
>> not specific to this chip. We could have an HDMI connector and failed
>> to hook up HPD for example. A connector node is also where hpd-gpios
>> should be located instead (and are already defined by
>> ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
>> binding, too.
>
>
> Yep, I agree with your front point, it is a property of panel, not specific
> to eDP controller, so this code should handle in connector logic.
>
> But another question, if we just leave this property to connector,
> then we would need to parse this property in analogix_dp-rockchip.c,
> and then make an hook in analogix_dp_core.c driver. This is not nice,
> and if there are some coming platform which alse want to use analogix_dp
> code and meet this "no-hpd" situation,  then they would need duplicate
> to parse this property and fill the hook in analogix_dp_core.c driver.
> So it's little bit conflict  :-)

Ideally, you would be able to just retrieve this quirk from the
connector or panel. Getting this property from your node vs. the port
you are attached to should not be much harder. Either the connector
struct can have this info or there can be a DT function that can walk
the graph and get it. Just don't open code the graph traversal in your
driver.

> Beside I can not understand your example very well. Do you mean
> that there are some HDMI monitor which also do not have HPD
> signal (just like some eDP panel do not have hpd too), and then
> the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want
> to help in this case, would you mind show some sample code  :-D

I don't know that there is h/w, but it is always possible HPD is not
hooked up or hooked up incorrectly some how.

If there is no HPD support, then hpd-gpios is not going to help you.

I think there are 3 cases to handle:
- HPD handled by bridge chip - The bridge driver knows it has this
capability. No DT properties are needed and no HPD properties on the
connector node imply the bridge chip should handle HPD functions.
- HPD handled by GPIO line (or some other block) - Indicated by
hpd-gpios present
- No or broken HPD - Indicated by "hpd-force" property.

>
>> Are there any eDP panels which don't have EDID and need panel details in
>> DT?
>
>
> Oh, I think you want to collect some info that belong to panel
> property but no indicate in panel EDID message, so those can
> be collect in eDP connector binding, is it right ?

Yes, and as Thierry pointed out we may need to know the exact panel even.

Rob

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Rob Herring]

On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner  wrote:
> Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed-off-by: Yakir Yang 
>
> [...]
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index bed0252..7d62f22 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>
> [...]
>
>>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>>
>>   ret = drm_connector_init(dp->drm_dev, connector,
>> -  _dp_connector_funcs,
>> +  _dp_connector_funcs,
>>DRM_MODE_CONNECTOR_eDP);
>>   if (ret) {
>>   DRM_ERROR("Failed to initialize connector with drm\n");
>>   return ret;
>>   }
>>
>> - drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>> + drm_connector_helper_add(connector,
>> +  _dp_connector_helper_funcs);
>>   drm_connector_register(connector);
>
> this should only run on exynos, as we're doing all our connector registration
> in the core driver after all components are bound, so I guess something like
> the following is needed:
>
>if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
>drm_connector_register(connector);

Yuck!

Surely there is a better way. From what I've seen of DRM, I have no
doubt this is needed, but really a better solution is needed. Surely
there can be a more generic way for the driver to determine if it
should handle the connector or not. This seems like a common problem
including one I have seen. What I'm working on has onchip DSI encoder
-> ADV7533 -> HDMI. The DSI encoder can also have a direct attached
panel. So I have to check for a bridge in the encoder driver and only
register the connector for the panel if a bridge is not attached.

Rob

[Bug 91881] regression: GPU lockups since mesa-11.0.0_rc1 on RV620 (r600) driver

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

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

--- Comment #2 from Alex Deucher  ---
r600 does not use llvm for graphics so that doesn't matter.  What version of
10.x was working?  Can you bisect?

-- 
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/20150904/f719da7f/attachment.html>

[Bug 91881] regression: GPU lockups since mesa-11.0.0_rc1 on RV620 (r600) driver

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

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

--- Comment #1 from markus gapp  ---
video card is:

lspci -v:

80:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620
LE [Radeon HD 3450] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. RV620 LE [Radeon HD 3450]
Flags: bus master, fast devsel, latency 0, IRQ 36
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at f000 (64-bit, non-prefetchable) [size=64K]
I/O ports at 1000 [size=256]
[virtual] Expansion ROM at f002 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Kernel driver in use: radeon
Kernel modules: radeon

-- 
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/20150904/a60105a0/attachment.html>

[Bug 91881] regression: GPU lockups since mesa-11.0.0_rc1 on RV620 (r600) driver

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

FT_RESET=0x0100
[   84.448603] radeon :80:00.0:   R_008010_GRBM_STATUS  = 0xA0003030
[   84.448605] radeon :80:00.0:   R_008014_GRBM_STATUS2 = 0x0003
[   84.448607] radeon :80:00.0:   R_000E50_SRBM_STATUS  = 0x200080C0
[   84.448610] radeon :80:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[   84.448612] radeon :80:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[   84.448614] radeon :80:00.0:   R_00867C_CP_BUSY_STAT = 0x
[   84.448616] radeon :80:00.0:   R_008680_CP_STAT  = 0x8010
[   84.448618] radeon :80:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[   84.448625] radeon :80:00.0: GPU reset succeeded, trying to resume
[   84.464433] [drm] PCIE gen 2 link speeds already enabled
[   84.466240] [drm] PCIE GART of 512M enabled (table at 0x00254000).
[   84.466265] radeon :80:00.0: WB enabled
[   84.466268] radeon :80:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x8800c9485c00
[   84.466978] radeon :80:00.0: fence driver on ring 5 use gpu addr
0x000521d0 and cpu addr 0xc900010121d0
[   84.498510] [drm] ring test on 0 succeeded in 1 usecs
[   84.674557] [drm] ring test on 5 succeeded in 1 usecs
[   84.674563] [drm] UVD initialized successfully.
[   84.696700] [drm] ib test on ring 0 succeeded in 0 usecs
[   85.346679] [drm] ib test on ring 5 succeeded


thank you very much

markus

-- 
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/20150904/9957916f/attachment-0001.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #1 from Alex Deucher  ---
It's supported.  Please attach your xorg log, dmesg output and a copy of your
vbios.  To get a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

-- 
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/20150904/4f8c7065/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

Bug ID: 91880
   Summary: Radeonsi on Grenada cards (r9 390) exceptionally
unstable and poorly performing
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: luutifa at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

I have an r9 390, and I had to disable DPM (on Linux 4.2) to get a stable
destop. The performance is less than half of r9 290 (which is almost the same
GPU) on the same driver.

How is Grenada support planned and can I get an estimate of it's arrival?

-- 
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/20150904/877b5e3c/attachment.html>

[PATCH] scripts/kernel-doc: Improve Markdown results

[Danilo Cesar Lemes de Paula]

On 09/02/2015 11:15 AM, Jonathan Corbet wrote:
> On Tue, 1 Sep 2015 14:57:33 -0300
> Danilo Cesar Lemes de Paula  wrote:
> 
>> Did you find time to check this patch? As you mentioned that you applied
>> the Markdown support for the linux-next tree, this patch might be needed
>> (maybe "wanted" is a better word).
> 
> Not quite what I said...I said I'd apply it right after the merge window
> so it can sit in linux-next through the full cycle.  It's a bit early to
> be pushing 4.4 stuff into linux-next now...
> 
> Beyond that, I wasn't sure where things stand with fixes... Can you send
> me a new patch set with this fix (and any others that might
> exist) integrated in?

Sure, but I'm a bit confused now (kernel noob here).

In the last few days I sent three features:
Markdown support (patch series 1)
Cross-reference hyperlink support (patch series 1)
in-struct-body documentation (series 2)

I assume you want a new patch series for the series 1, containing the
feature itself and the fixes that I sent later, correct?

Thanks,

Danilo

[PATCH 4/4] staging: android: lowmemorykiller: take per file badness into account

[Christian König]

From: Christian König 

Try to make better decisions which process to kill based on per
file OOM badness.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 drivers/staging/android/lowmemorykiller.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/android/lowmemorykiller.c 
b/drivers/staging/android/lowmemorykiller.c
index feafa17..baefe8f 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 

 static uint32_t lowmem_debug_level = 1;
 static short lowmem_adj[6] = {
@@ -75,6 +76,13 @@ static unsigned long lowmem_count(struct shrinker *s,
global_page_state(NR_INACTIVE_FILE);
 }

+static int lowmem_file_badness(const void *tasksize, struct file *file, 
unsigned n)
+{
+   *((int*)tasksize) += atomic_long_read(>f_oom_badness);
+
+   return 0;
+}
+
 static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc)
 {
struct task_struct *tsk;
@@ -139,6 +147,7 @@ static unsigned long lowmem_scan(struct shrinker *s, struct 
shrink_control *sc)
continue;
}
tasksize = get_mm_rss(p->mm);
+   iterate_fd(p->files, 0, lowmem_file_badness, );
task_unlock(p);
if (tasksize <= 0)
continue;
-- 
1.9.1

[PATCH 3/4] oom: take per file badness into account

[Christian König]

From: Christian König 

Try to make better decisions which process to kill based on
per file OOM badness.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 mm/oom_kill.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 2b665da..4bcb3f4 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 #define CREATE_TRACE_POINTS
 #include 
@@ -138,6 +139,19 @@ static bool oom_unkillable_task(struct task_struct *p,
 }

 /**
+ * oom_file_badness - add per file badness
+ * @points: pointer to summed up badness points
+ * @file: tasks open file
+ * @n: file descriptor id (unused)
+ */
+static int oom_file_badness(const void *points, struct file *file, unsigned n)
+{
+   *((long*)points) += atomic_long_read(>f_oom_badness);
+
+   return 0;
+}
+
+/**
  * oom_badness - heuristic function to determine which candidate task to kill
  * @p: task struct of which task we should calculate
  * @totalpages: total present RAM allowed for page allocation
@@ -171,6 +185,12 @@ unsigned long oom_badness(struct task_struct *p, struct 
mem_cgroup *memcg,
 */
points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
atomic_long_read(>mm->nr_ptes) + mm_nr_pmds(p->mm);
+
+   /*
+* Add how much memory a task uses in opened files, e.g. device drivers.
+*/
+   iterate_fd(p->files, 0, oom_file_badness, );
+
task_unlock(p);

/*
-- 
1.9.1

[PATCH 2/4] drm/gem: adjust per file OOM badness on handling buffers

[Christian König]

From: Christian König 

Large amounts of VRAM are usually not CPU accessible, so they are not mapped
into the processes address space. But since the device drivers usually support
swapping buffers from VRAM to system memory we can still run into an out of
memory situation when userspace starts to allocate to much.

This patch gives the OOM and lower memory killer another hint which process is
holding how many resources.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/drm_gem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 16a1647..17d14c1 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -282,6 +282,9 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
+
+   atomic_long_sub(obj->size >> PAGE_SHIFT, >filp->f_oom_badness);
+
drm_gem_object_handle_unreference_unlocked(obj);

return 0;
@@ -358,6 +361,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
}
}

+   atomic_long_add(obj->size >> PAGE_SHIFT,
+   _priv->filp->f_oom_badness);
+
return 0;
 }

@@ -717,6 +723,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);

+   atomic_long_sub(obj->size >> PAGE_SHIFT,
+   _priv->filp->f_oom_badness);
+
drm_gem_object_handle_unreference_unlocked(obj);

return 0;
-- 
1.9.1

[PATCH 1/4] fs: add per file OOM badness

[Christian König]

From: Christian König 

This allows device drivers to specify an additional badness for the OOM
and low memory killer when they allocate memory on behalf of userspace.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 fs/file_table.c| 1 +
 include/linux/fs.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/file_table.c b/fs/file_table.c
index 294174d..23b797d 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -136,6 +136,7 @@ struct file *get_empty_filp(void)
spin_lock_init(>f_lock);
mutex_init(>f_pos_lock);
eventpoll_init_file(f);
+   atomic_long_set(>f_oom_badness, 0);
/* f->f_version: 0 */
return f;

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 35ec87e..5a5d20a 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -861,6 +861,7 @@ struct file {
struct list_headf_tfile_llink;
 #endif /* #ifdef CONFIG_EPOLL */
struct address_space*f_mapping;
+   atomic_long_t   f_oom_badness;
 } __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */

 struct file_handle {
-- 
1.9.1

[RFC] Per file OOM badness

[Christian König]

Hello everyone,

I'm currently working on the issue that when device drivers allocate memory on
behalf of an application the OOM killer usually doesn't knew about that unless
the application also get this memory mapped into their address space.

This is especially annoying for graphics drivers where a lot of the VRAM
usually isn't CPU accessible and so doesn't make sense to map into the
address space of the process using it.

The problem now is that when an application starts to use a lot of VRAM those
buffers objects sooner or later get swapped out to system memory, but when we
now run into an out of memory situation the OOM killer obviously doesn't knew
anything about that memory and so usually kills the wrong process.

The following set of patches tries to address this problem by introducing a per
file OOM badness score, which device drivers can use to give the OOM killer a
hint how many resources are bound to a file descriptor so that it can make
better decisions which process to kill.

So question at every one: What do you think about this approach?

My biggest concern right now is the patches are messing with a core kernel
structure (adding a field to struct file). Any better idea? I'm considering
to put a callback into file_ops instead.

Best regards and feel free to tear this idea apart,
Christian.

create framebuffer device layer overlay

[Daniel Vetter]

On Fri, Sep 04, 2015 at 11:59:58AM +0200, Alex Vazquez wrote:
> Hi,all!
> 
> I'm using atmel-hlcdc driver to control a LCD panel and an application uses
> the /dev/fb0 framebuffer created by the driver. The display works fine
> except that the panel's standard orientation is landscape mode (480x275)
> and I need to use it in portrait mode (275x480).
> 
> I know that the driver allow rotation but is only for the overlays layers,
> and not the baselayer.
> 
> I have tested with modetest and i can do what i want.
> 
> I want to know if is posible create a device framebuffer from overlay layer
> use libdrm (e.g. /dev/fb1).

Legacy fbdev support really is only for debugging and stuff like that, if
you have a kms driver I highly recommend that you just use the dumb buffer
api and assign them to overlays like modetest. Ofc it would be technically
possible to create more legacy framebuffer devices, but I don't think
that's something which would be received with enthusiasm by upstream.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/exynos: add cursor plane support

[Inki Dae]

Hi Gustavo,

I had already a review but I didn't give any comment to you. Sorry about
that. This patch looks good to me but one thing isn't clear. Below is my
comment.


On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
>  8 files changed, 31 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index b3c7307..79b2b22 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   void __iomem*addr;
>   struct clk  *clks[6];
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   int pipe;
>   boolsuspended;
> @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   struct drm_device *drm_dev = data;
>   struct exynos_drm_private *priv = drm_dev->dev_private;
>   struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
>   unsigned int zpos;
>   int ret;
>  
> @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>  
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, decon_formats,
> + 1 << ctx->pipe, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
>   if (ret)
>   return ret;
>   }
>  
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>   _crtc_ops, ctx);
> @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   if (!ctx)
>   return -ENOMEM;
>  
> - ctx->default_win = 0;
>   ctx->suspended = true;
>   ctx->dev = dev;
>   if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index cbdb78e..f3826dc 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
>   struct clk  *eclk;
>   struct clk  *vclk;
>   void __iomem*regs;
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   booli80_if;
>   boolsuspended;
> @@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   struct decon_context *ctx = dev_get_drvdata(dev);
>   struct drm_device *drm_dev = data;
>   struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
>   unsigned int zpos;
>   int ret;
>  
> @@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>  
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, decon_formats,
> + 1 << ctx->pipe, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
>   if (ret)
>   return ret;
>   }
>  
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = 

[Bug 91780] Rendering issues with geometry shader

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

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

--- Comment #8 from Marek Olšák  ---
(In reply to Dave Airlie from comment #5)
> just fyi I tested this on CAICOS GPU and SUMO APU today,
> 
> and it renders fine on the SUMO but fails similarly on the CAICOS.
> 
> This is strange, and it might take someone from AMD doing some research for
> us.

I don't know of any hw bug related to GS that could cause this.

-- 
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/20150904/cc8c57bf/attachment.html>

[PATCH 8/9] drm: bridge/dw_hdmi: replace CTS calculation for the ACR

[Doug Anderson]

Russell,

On Sat, Aug 8, 2015 at 9:10 AM, Russell King
 wrote:
> Given the TDMS clock, audio sample rate, and the N parameter, we can
> calculate the CTS value for the audio clock regenerator (ACR) using the
> following calculation given in the HDMI specification:
>
> CTS = ftdms * N / (128 * fs)
>
> The specification says that the CTS value is an average value, which is
> true if the source hardware measures it.  Where source hardware needs it
> to be programmed, it is particularly difficult to alternate it between
> two values correctly to ensure that we achieve a correct "average"
> fractional value at the sink.
>
> Also, there's the problem that our "ftdms" is not a fully accurate
> value; it is rounded to a kHz value.  This introduces an unnecessary
> (and harmless) fractional value into the above equation for combinations
> like 148.5MHz/1.001 for 44100Hz - we still calculate the correct CTS
> value.
>
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 92 
> +++-
>  1 file changed, 16 insertions(+), 76 deletions(-)

If you take my feedback about your "drm: bridge/dw_hdmi: adjust pixel
clock values in N calculation" patch [1], all this math just works out
to "cts = pixel_clk / 1000".  ...but doing the math does future proof
us a bit, so it seems like a good idea.

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 


[1] https://patchwork.kernel.org/patch/6975221/

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Hi,

On Fri, Sep 4, 2015 at 11:21 AM, Doug Anderson  wrote:
> Russell,
>
> On Sat, Aug 8, 2015 at 9:10 AM, Russell King
>  wrote:
>> Adjust the pixel clock values in the N calculation to match the more
>> accurate clock values we're given by the DRM subsystem, which are the
>> kHz pixel rate, with any fractional kHz rounded down in the case of
>> the non-240, non-480 line modes, or rounded up for the others.  So,
>>
>>  25.20 / 1.001 =>  25175
>>  27.00 * 1.001 =>  27027
>>  74.25 / 1.001 =>  74176
>> 148.50 / 1.001 => 148352
>>
>> Signed-off-by: Russell King 
>> ---
>>  drivers/gpu/drm/bridge/dw_hdmi.c | 20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> For what it's worth, I backported this change into my local 3.14-based
> tree and it doesn't cause any problems, though it looks like the code
> isn't being run in my case...
>
> I can confirm that the rates you list match the rates I actually see
> requested by DRM, but in my current tree I've actually got something
> that allows a little bit of "slop" in HDMI rates because my system
> can't actually always make exactly the modes requested, but it appears
> that getting "close enough" works, especially if your clock jitter is
> low enough (because the sink needs to have a little bit of wiggle room
> for jitter anyway).  For instance, when 25.175 is requested we
> actually end up making 25.170732.
>
> In my tree this adjustment happens in mode_fixup by changing the
> adj_mode.  In one particular case, some debug prints show:
>   640x480, mode=2520, adj=25171000, actual=25170732
>   freq=48000, pixel_clk=25171000, n=6144
>
> I'm not enough of an HDMI expert to say whether it's better to be
> using n=6144 or n=6864 in this case, but audio does play with either
> on the TV I tested.
>
> In any case, I'd say that your change at least makes things better
> than they were, so I'd be in favor of taking it.  If someone later
> decides that we should add a little margin to these numbers, then a
> patch to add that could go atop yours.

Oh!  I just figured this out!  :)

Basically the spec is saying that you want both N and CTS to be
integral.  ...as you say you really want:
  CTS = (TMDS * N) / (128 * audio_freq)

...CTS has no other restrictions (other than being integral) and
you're allowed a bit of slop for N (you aim for 128 * audio_freq but
can go up or down a bit).
...and the TMDS frequency has no such restrictions for being integral
in their calculations.

Apparently it's more important to optimize for the CTS formula working
out then it is for getting close to "128 * audio freq".  ...and that's
the reason for these special case N values...


So to put some numbers:

We're perfect when we have exactly 25.2:
  25200 * 4096 / (128 * 32)
  => 25200, so CTS for 25.2 MHz is 25200.  Perfect

...but when we have 25.2 / 1.001 we get a non-integral CTS:
  (25200 / 1.001) * 4096 / (128 * 32)
  => 25174.82517482518

...we can get an integral CTS and still remain in range if:
  (25200 / 1.001) * 4576 / (128 * 32)
  => 28125

In the case of Linux, I'm afraid we just don't have this type of
accuracy in our APIs.  The spec is talking about making
25.17482517482518 MHz.  As I said, in my case I'm actually making
25170732.  In your case you're probably making the value that Linux
asked you to make, AKA 25.175000 MHz.  Unsurprisingly, if you do the
calculations with 25.175 MHz (or any integral kHz value) you don't
have to do any special optimization to stay integral:

  25175 * 4096 / (128 * 32)
  => 25175


So unless you have some way to know that the underlying clock is
actually (25.2 / 1.001) MHz and not just 25.175 MHz then your patch
looks wrong.


As a first step I'd suggest just removing all the special cases and
add a comment.  From real world testing it doesn't seem terribly
critical to be slightly off on CTS.  ...and in any case for any clock
rates except the small handful in the HDMI spec we'll be slightly off
on CTS anyway...

As a second step you could actually use the rate from "clk_get_rate()"
to see what clock rate was actually made.  You'll at least get Hz
here.  If you've somehow structured your machine to give you 25174825
Hz when DRM asked for 25175000 Hz (or if you redo the calculations and
ignore what DRM told you), then that would give you this slightly more
optimal rate.

As a third step you could somehow add the more detailed Hz information
to DRM (sounds like a big task, but I'm nowhere near a DRM expert).

As a fourth step you could try to write the code in a generic way to
figure out the best N / CTS to minimize error in the formula while
still staying within the required ranges.  If you did that, it
probably would belong in some generic helper and not in dw_hdmi...


...anyway, I'm not suggestion that you do everything above since I
think just removing the special cases is probably good enough.  ...but
if you wanted 

[PATCH libdrm 14/17] tests/amdgpu: ensure tests work by using c99 initializers

[Alex Deucher]

On Mon, Aug 24, 2015 at 1:08 PM, Alex Deucher  wrote:
> On Mon, Aug 24, 2015 at 12:34 PM, Emil Velikov  
> wrote:
>> In the latest version of CUnit the fourth parameter of the CU_SuiteInfo
>> struct is pSetUpFunc rather than *pTests.
>>
>> Seems like the CUnit ABI broke at some point, so let's the the robust
>> thing and use c99 designated initializers to correctly populate the
>> struct(s).
>>
>> Cc: Alex Deucher 
>> Cc: Leo Liu 
>> Signed-off-by: Emil Velikov 
>
> Reviewed-by: Alex Deucher 

Any plans to push this?

Thanks,

Alex

>
>> ---
>>  tests/amdgpu/amdgpu_test.c | 32 
>>  1 file changed, 24 insertions(+), 8 deletions(-)
>>
>> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
>> index 6568990..71f357c 100644
>> --- a/tests/amdgpu/amdgpu_test.c
>> +++ b/tests/amdgpu/amdgpu_test.c
>> @@ -58,14 +58,30 @@ int drm_amdgpu[MAX_CARDS_SUPPORTED];
>>
>>  /** The table of all known test suites to run */
>>  static CU_SuiteInfo suites[] = {
>> -   { "Basic Tests", suite_basic_tests_init,
>> - suite_basic_tests_clean, basic_tests },
>> -   { "BO Tests", suite_bo_tests_init,
>> - suite_bo_tests_clean, bo_tests },
>> -   { "CS Tests", suite_cs_tests_init,
>> - suite_cs_tests_clean, cs_tests },
>> -   { "VCE Tests", suite_vce_tests_init,
>> - suite_vce_tests_clean, vce_tests },
>> +   {
>> +   .pName = "Basic Tests",
>> +   .pInitFunc = suite_basic_tests_init,
>> +   .pCleanupFunc = suite_basic_tests_clean,
>> +   .pTests = basic_tests,
>> +   },
>> +   {
>> +   .pName = "BO Tests",
>> +   .pInitFunc = suite_bo_tests_init,
>> +   .pCleanupFunc = suite_bo_tests_clean,
>> +   .pTests = bo_tests,
>> +   },
>> +   {
>> +   .pName = "CS Tests",
>> +   .pInitFunc = suite_cs_tests_init,
>> +   .pCleanupFunc = suite_cs_tests_clean,
>> +   .pTests = cs_tests,
>> +   },
>> +   {
>> +   .pName = "VCE Tests",
>> +   .pInitFunc = suite_vce_tests_init,
>> +   .pCleanupFunc = suite_vce_tests_clean,
>> +   .pTests = vce_tests,
>> +   },
>> CU_SUITE_INFO_NULL,
>>  };
>>
>> --
>> 2.5.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Thierry Reding]

On Thu, Sep 03, 2015 at 04:55:59PM -0500, Rob Herring wrote:
> On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding  wrote:
> > On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote:
> > [...]
> >> Are there any eDP panels which don't have EDID and need panel details in 
> >> DT?
> >
> > Most panels need information other than EDID. They typically have some
> > requirements regarding the power up sequence that aren't to be found
> > anywhere in EDID or detectable by some other mechanism. A decision was
> > therefore made a long time ago to require panels to be listed in DT with
> > a specific compatible string. That way all of these details can be
> > stashed away in drivers that know how to deal with these kinds of
> > details.
> 
> I guess I was being hopeful that eDP was improving that situation.

Unfortunately not. eDP helps with a number of things (DPCD and link
training take care of a lot of the issues), but it doesn't provide a
solution for everything.

To my knowledge in most cases the power up sequence isn't strictly
necessary to get the panel to operate. But there have been instances
where this is absolutely required if you want to avoid visual artifacts
as you set a mode. A lot of panels that I've come across require
receiving a couple of frames before they guarantee that something will
actually be displayed on the screen. So if your code is too quickly
enabling backlight, and your backlight doesn't happen to have just the
right amount of ramp-up time you might end up seeing garbage on the
screen for a couple of frames.

It would be great if somebody came up with, say, an EDID extension to
describe these requirements, but I'm not sure if even that would give
us panels that could be driven with a generic driver. Often the power
supplies or reset/enable signals are very different across panels. So
describing it all generically would become messy rather quickly.

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

create framebuffer device layer overlay

[Alex Vazquez]

Hi,all!

I'm using atmel-hlcdc driver to control a LCD panel and an application uses
the /dev/fb0 framebuffer created by the driver. The display works fine
except that the panel's standard orientation is landscape mode (480x275)
and I need to use it in portrait mode (275x480).

I know that the driver allow rotation but is only for the overlays layers,
and not the baselayer.

I have tested with modetest and i can do what i want.

I want to know if is posible create a device framebuffer from overlay layer
use libdrm (e.g. /dev/fb1).

Thanks!
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/cc7abf73/attachment.html>

[PATCH] drm/bridge: fix platform_no_drv_owner.cocci warnings

[Thierry Reding]

On Fri, Aug 21, 2015 at 07:05:39PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/bridge/nxp-ptn3460.c:403:3-8: No need to set .owner here. The 
> core will do it.
> 
>  Remove .owner field if calls are used which set it automatically
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> 
> Signed-off-by: Fengguang Wu 
> ---
> 
>  nxp-ptn3460.c |1 -
>  1 file changed, 1 deletion(-)
Applied with a slightly reworded commit message.

Thanks,
Thierry
> 
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver
>   .remove = ptn3460_remove,
>   .driver = {
>   .name   = "nxp,ptn3460",
> - .owner  = THIS_MODULE,
>   .of_match_table = ptn3460_match,
>   },
>  };

Applied with a slightly reworded commit message.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150904/089f6056/attachment-0001.sig>

[PATCH] drm/bridge: fix platform_no_drv_owner.cocci warnings

[Thierry Reding]

On Fri, Aug 21, 2015 at 07:05:39PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/bridge/parade-ps8622.c:671:3-8: No need to set .owner here. 
> The core will do it.
> 
>  Remove .owner field if calls are used which set it automatically
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> 
> Signed-off-by: Fengguang Wu 
> ---
> 
>  parade-ps8622.c |1 -
>  1 file changed, 1 deletion(-)
> 
> --- a/drivers/gpu/drm/bridge/parade-ps8622.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8622.c
> @@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver =
>   .remove = ps8622_remove,
>   .driver = {
>   .name   = "ps8622",
> - .owner  = THIS_MODULE,
>   .of_match_table = ps8622_devices,
>   },
>  };

Applied with a slightly reworded commit message.

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

[PATCH 7/9] drm: bridge/dw_hdmi: remove ratio support from ACR code

[Doug Anderson]

Russell,

On Sat, Aug 8, 2015 at 9:10 AM, Russell King
 wrote:
> We never set the ratio for CTS/N calculation for the audio clock
> regenerator (ACR) to anything but 100, so this adds pointless
> complexity.  Should we support pixel repetition, we should update the
> CTS/N calculation code to use those parameters or the actual TMDS clock
> rate instead of a ratio.
>
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 44 
> 
>  1 file changed, 18 insertions(+), 26 deletions(-)

It looks like I've got a slightly older version of the driver in my
tree (based on some earlier mailing list postings), but backporting
this was pretty trivial and I've tried it in my 3.14 kernel.  It
doesn't cause any problems for me to remove the "radio" and I agree
that we should add it if/when pixel repetition is added.

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Russell,

On Sat, Aug 8, 2015 at 9:10 AM, Russell King
 wrote:
> Adjust the pixel clock values in the N calculation to match the more
> accurate clock values we're given by the DRM subsystem, which are the
> kHz pixel rate, with any fractional kHz rounded down in the case of
> the non-240, non-480 line modes, or rounded up for the others.  So,
>
>  25.20 / 1.001 =>  25175
>  27.00 * 1.001 =>  27027
>  74.25 / 1.001 =>  74176
> 148.50 / 1.001 => 148352
>
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

For what it's worth, I backported this change into my local 3.14-based
tree and it doesn't cause any problems, though it looks like the code
isn't being run in my case...

I can confirm that the rates you list match the rates I actually see
requested by DRM, but in my current tree I've actually got something
that allows a little bit of "slop" in HDMI rates because my system
can't actually always make exactly the modes requested, but it appears
that getting "close enough" works, especially if your clock jitter is
low enough (because the sink needs to have a little bit of wiggle room
for jitter anyway).  For instance, when 25.175 is requested we
actually end up making 25.170732.

In my tree this adjustment happens in mode_fixup by changing the
adj_mode.  In one particular case, some debug prints show:
  640x480, mode=2520, adj=25171000, actual=25170732
  freq=48000, pixel_clk=25171000, n=6144

I'm not enough of an HDMI expert to say whether it's better to be
using n=6144 or n=6864 in this case, but audio does play with either
on the TV I tested.

In any case, I'd say that your change at least makes things better
than they were, so I'd be in favor of taking it.  If someone later
decides that we should add a little margin to these numbers, then a
patch to add that could go atop yours.

Reviewed-by: Douglas Anderson 

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 11:04:40AM +0200, Thierry Reding wrote:
> Conversely, if the panel isn't capable of generating an HPD signal, then
> I don't think it would be appropriate to make it a DT property. It would
> be better to hard-code it in the driver, lest someone forget to set the
> property in DT and get stuck with a device that isn't operational.

There is another way to deal with this: DRM supports the idea of connector
forcing - where you can force the connector to think that it's connected
or disconnected.

One of the problems is that not many ARM DRM drivers implement it - maybe
it should be a requirement for code to be accepted? :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 5/9] drm: bridge/dw_hdmi: avoid being recursive in N calculation

[Doug Anderson]

Russell,

On Sat, Aug 8, 2015 at 9:10 AM, Russell King
 wrote:
> There's no need to be recursive when computing the N value for the ACR
> packet - we can instead calculate the multiplier prior to our switch()
> based lookup, and multiply the N value appropriately afterwards.
>
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)

For what it's worth, I backported this change into my local 3.14-based
tree and it worked for me.  It also looks good to me.

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Krzysztof Kozlowski]

On 03.09.2015 14:30, Yakir Yang wrote:
> Hi Krzysztof,
> 
> 在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道:
>> On 01.09.2015 14:49, Yakir Yang wrote:
>>> Split the dp core driver from exynos directory to bridge
>>> directory, and rename the core driver to analogix_dp_*,
>>> leave the platform code to analogix_dp-exynos.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v4:
>>> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
>>> propery.
>>> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
>>> "exynos_dp.c"
>>> - Take Archit suggest, create a separate folder for analogix code in
>>> bridge/
>>>
>>> Changes in v3:
>>> - Take Thierry Reding suggest, move exynos's video_timing code
>>>to analogix_dp-exynos platform driver, add get_modes method
>>>to struct analogix_dp_plat_data.
>>> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>>>
>>> Changes in v2:
>>> - Take Jingoo Han suggest, remove new copyright
>>> - Fix compiled failed dut to analogix_dp_device misspell
>>>
>>>   drivers/gpu/drm/bridge/Kconfig |2 +
>>>   drivers/gpu/drm/bridge/Makefile|1 +
>>>   drivers/gpu/drm/bridge/analogix/Kconfig|4 +
>>>   drivers/gpu/drm/bridge/analogix/Makefile   |1 +
>>>   .../analogix/analogix_dp_core.c}   |  817
>>> ++---
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  283 +
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1265
>>> 
>>>   .../analogix/analogix_dp_reg.h}|  258 ++--
>>>   drivers/gpu/drm/exynos/Kconfig |3 +-
>>>   drivers/gpu/drm/exynos/Makefile|2 +-
>>>   drivers/gpu/drm/exynos/exynos_dp.c |  306 +
>>>   drivers/gpu/drm/exynos/exynos_dp_core.h|  282 -
>>>   drivers/gpu/drm/exynos/exynos_dp_reg.c | 1259
>>> ---
>>>   include/drm/bridge/analogix_dp.h   |   24 +
>>>   14 files changed, 2357 insertions(+), 2150 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
>>>   rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
>>> bridge/analogix/analogix_dp_core.c} (50%)
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>>>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>>   rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
>>> bridge/analogix/analogix_dp_reg.h} (64%)
>>>   create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
>>>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>>>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>>>   create mode 100644 include/drm/bridge/analogix_dp.h
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>>> b/drivers/gpu/drm/bridge/Kconfig
>>> index 2de52a5..7b5b77a 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
>>>   ---help---
>>> Parade eDP-LVDS bridge chip driver.
>>>   +source "drivers/gpu/drm/bridge/analogix/Kconfig"
>>> +
>>>   endmenu
>>> diff --git a/drivers/gpu/drm/bridge/Makefile
>>> b/drivers/gpu/drm/bridge/Makefile
>>> index e2eef1c..5366c6b 100644
>>> --- a/drivers/gpu/drm/bridge/Makefile
>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
>>>   obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>>>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>>>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
>>> b/drivers/gpu/drm/bridge/analogix/Kconfig
>>> new file mode 100644
>>> index 000..5ff6551
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
>>> @@ -0,0 +1,4 @@
>>> +config DRM_ANALOGIX_DP
>>> +tristate
>>> +depends on DRM
>>> +select DRM_KMS_HELPER
>>> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
>>> b/drivers/gpu/drm/bridge/analogix/Makefile
>>> new file mode 100644
>>> index 000..9107b86
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> similarity index 50%
>>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index bed0252..7d62f22 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -1,14 +1,14 @@
>>>   /*
>>> - * Samsung SoC DP (Display Port) interface driver.
>>> - *
>>> - * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>>> - * Author: Jingoo Han 
>>> - *
>>> - * This program is free 

[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

[Krzysztof Kozlowski]

On 01.09.2015 15:07, Yakir Yang wrote:

Empty commit message. Please explain here why you want to add platform
device type support.

Actually the title is confusing. You are not adding support for platform
device types but rather adding a field containing type of device.


> Signed-off-by: Yakir Yang 
> ---
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Add GNU license v2 declared and samsung copyright
> 
>  drivers/gpu/drm/exynos/exynos_dp.c  |  1 +
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |  1 +
>  include/drm/bridge/analogix_dp.h| 16 
>  3 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 6060d2c..40ef727 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   dp->dev = dev;
>   dp->drm_dev = drm_dev;
>  
> + dp->plat_data.dev_type = EXYNOS_DP;
>   dp->plat_data.power_on = exynos_dp_poweron;
>   dp->plat_data.power_off = exynos_dp_poweroff;
>   dp->plat_data.get_modes = exynos_dp_get_modes;
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index efea045..4934271 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> + dp->plat_data.dev_type = RK3288_DP;
>   dp->plat_data.attach = NULL;
>   dp->plat_data.get_modes = NULL;
>   dp->plat_data.power_on = rockchip_dp_poweron;
> diff --git a/include/drm/bridge/analogix_dp.h 
> b/include/drm/bridge/analogix_dp.h
> index 8b4ffad..7209a64 100644
> --- a/include/drm/bridge/analogix_dp.h
> +++ b/include/drm/bridge/analogix_dp.h
> @@ -1,9 +1,25 @@
> +/*
> + * Analogix Core DP (Display Port) interface driver.
> + *
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */

Two questions:
1. Why this change is here? I would rather expect it at patch 3/16 when
you created this file... That is the usual time for adding copyrights.

2. Does this file contains previous Samsung work?

Best regards,
Krzysztof

>  #ifndef _ANALOGIX_DP_H_
>  #define _ANALOGIX_DP_H_
>  
>  #include 
>  
> +enum analogix_dp_devtype {
> + EXYNOS_DP,
> + RK3288_DP,
> +};
> +
>  struct analogix_dp_plat_data {
> + enum analogix_dp_devtype dev_type;
>   struct drm_panel *panel;
>  
>   int (*power_on)(struct analogix_dp_plat_data *);
> 

[PATCH] drm/exynos: add cursor plane support

[Daniel Vetter]

On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
> Hi Gustavo,
> 
> I had already a review but I didn't give any comment to you. Sorry about
> that. This patch looks good to me but one thing isn't clear. Below is my
> comment.
> 
> 
> On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Set one of the planes for each crtc driver as a cursor plane enabled
> > window managers to fully work on exynos.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
> >  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
> >  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
> >  8 files changed, 31 insertions(+), 39 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > index b3c7307..79b2b22 100644
> > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > @@ -33,7 +33,6 @@ struct decon_context {
> > struct exynos_drm_plane planes[WINDOWS_NR];
> > void __iomem*addr;
> > struct clk  *clks[6];
> > -   unsigned intdefault_win;
> > unsigned long   irq_flags;
> > int pipe;
> > boolsuspended;
> > @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
> > *master, void *data)
> > struct drm_device *drm_dev = data;
> > struct exynos_drm_private *priv = drm_dev->dev_private;
> > struct exynos_drm_plane *exynos_plane;
> > -   enum drm_plane_type type;
> > unsigned int zpos;
> > int ret;
> >  
> > @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct 
> > device *master, void *data)
> > ctx->pipe = priv->pipe++;
> >  
> > for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> > -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> > -   DRM_PLANE_TYPE_OVERLAY;
> > ret = exynos_plane_init(drm_dev, >planes[zpos],
> > -   1 << ctx->pipe, type, decon_formats,
> > +   1 << ctx->pipe, decon_formats,
> > ARRAY_SIZE(decon_formats), zpos);
> > if (ret)
> > return ret;
> > }
> >  
> > -   exynos_plane = >planes[ctx->default_win];
> > +   exynos_plane = >planes[DEFAULT_WIN];
> > ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
> > ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
> > _crtc_ops, ctx);
> > @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct 
> > platform_device *pdev)
> > if (!ctx)
> > return -ENOMEM;
> >  
> > -   ctx->default_win = 0;
> > ctx->suspended = true;
> > ctx->dev = dev;
> > if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
> > diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > index cbdb78e..f3826dc 100644
> > --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > @@ -52,7 +52,6 @@ struct decon_context {
> > struct clk  *eclk;
> > struct clk  *vclk;
> > void __iomem*regs;
> > -   unsigned intdefault_win;
> > unsigned long   irq_flags;
> > booli80_if;
> > boolsuspended;
> > @@ -691,7 +690,6 @@ static int decon_bind(struct device *dev, struct device 
> > *master, void *data)
> > struct decon_context *ctx = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = data;
> > struct exynos_drm_plane *exynos_plane;
> > -   enum drm_plane_type type;
> > unsigned int zpos;
> > int ret;
> >  
> > @@ -702,16 +700,14 @@ static int decon_bind(struct device *dev, struct 
> > device *master, void *data)
> > }
> >  
> > for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> > -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> > -   DRM_PLANE_TYPE_OVERLAY;
> > ret = exynos_plane_init(drm_dev, >planes[zpos],
> > -   1 << ctx->pipe, type, decon_formats,
> > +   1 << ctx->pipe, decon_formats,
> > ARRAY_SIZE(decon_formats), zpos);
> > if (ret)
> > 

[RFC 11/13] drm/dp: Add helper to dump DPCD

[Daniel Vetter]

On Thu, Sep 03, 2015 at 10:49:34AM -0700, Rafael Antognolli wrote:
> Hi, I'm back from vacation, so I'll be looking at this again.
> 
> On Thu, Aug 20, 2015 at 04:26:42PM -0700, Rafael Antognolli wrote:
> > On Mon, Aug 17, 2015 at 10:02:04AM +0300, Jani Nikula wrote:
> > > On Fri, 14 Aug 2015, Rafael Antognolli  
> > > wrote:
> > > > On Fri, Aug 14, 2015 at 02:56:55PM +0300, Jani Nikula wrote:
> > > >> On Wed, 12 Aug 2015, Thierry Reding  
> > > >> wrote:
> > > >> > From: Thierry Reding 
> > > >> >
> > > >> > The new drm_dp_dpcd_dump() helper dumps the contents of a DPCD to a
> > > >> > seq_file and can be used to make the DPCD available via debugfs for
> > > >> > example.
> > > >> 
> > > >> See i915/i915_debugfs.c for one DPCD dump implementation.
> > > >> 
> > > >> Around the time that was added, there was also some discussion (and
> > > >> patches [1]) to expose a read/write debugfs interface to DPCD, letting
> > > >> userspace access arbitrary DPCD registers.
> > > >> 
> > > >> Just this week there was some discussion about revisiting that. It was
> > > >> about accessing some proprietary panel features, but there's also the
> > > >> ease of debugging without having to keep updating the kernel to dump
> > > >> more.
> > > >> 
> > > >> I think it would be great to agree on a common debugfs interface to
> > > >> access DPCD arbitrarily. Last time I checked, the blocker to that was
> > > >> access to the aux channel from generic code; it's always driver
> > > >> specific. SMOP. ;)
> > > >
> > > > Do you mean it would require the generic code/interface to somehow route
> > > > this to the driver specific code? I am not sure yet how this works (if
> > > > there's something like it around), but I'll take a look.
> > > 
> > > Drivers can choose to support DP AUX any way they like, and they don't
> > > have to use the common helpers to do so. It's pretty much an
> > > implementation detail. I think we could require the use of the common
> > > helpers to support generic DPCD access from debugfs, but we'd still have
> > > to come up with a way to get hold of struct drm_dp_aux (again, driver
> > > internals) given a drm_connector in generic debugfs code.
> > 
> > I was under the assumption they always used the helpers, but I
> > understand that's not always the case.
> > 
> > Anyway, I was going to propose a new helper to "store" the drm_dp_aux
> > inside the drm_connector. And just expose something on debugfs if it was
> > used. Something like:
> > 
> > int drm_dp_aux_store(struct drm_dp_aux *aux,
> >  struct drm_connector *connector);
> > 
> > The helpers don't seem to know about drm_connector's though, so I'm not sure
> > this is a good approach.
> > 
> > > Thierry, do you see any problems with having a connector function to get
> > > hold of its drm_dp_aux?
> > 
> > Would this be a new function pointer inside struct drm_connector_funcs?
> > If so, I'm fine with this approach too.
> > 
> > Regarding the interface, you mentioned that you didn't like it because
> > it had a state. What about just dumping the content of the register into
> > dmesg when one tries to read it, and use a different sintaxe for
> > writing, passing both the register addr and the value?
> > 
> > Daniel had another suggestion, regarding an ioctl in debugfs, but I'm
> > not sure I clearly understand that yet.
> 
> Regarding the interface, this is the comment Daniel did a while ago:
> 
> "As mentioned in another thread I think the right approach here is to
> expose the dp aux interface through some ioctls in debugfs or dev
> somewhere, and then add simple tools on top of that. Similar to what we
> have with i2c. That would allow us to implement additional things on top
> like mst inspection or using the i2c-over-dp-aux sidechannel."
> 
> If exposing through an ioctl, shouldn't it be yet another DRM ioctl? And
> if not, then I should create another /dev node/file specifically for this
> purpose, right?
> 
> And if we are going with ioctls, I still don't understand exactly how it
> relates to debugfs.

ioctl on some file, either a /dev chardev or just something in debugfs.
And imo it doesn't make sense to have it as an ioctl on the drm device
node since then we'd need to add some form of multiplexing to select the
right dp aux bus (and with dp mst there's new ones for each port on a
downstream hub). I'd just go with copying the i2c design of a chardev for
each master.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 91871] link retraining for DP not possible with current design of Atomic modeset framework

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

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

Jani Nikula  changed:

   What|Removed |Added

 CC||conselvan2 at gmail.com,
   ||intel-gfx-bugs at lists.freede
   ||sktop.org
  Component|General |DRM/Intel
   Assignee|dri-devel at lists.freedesktop |intel-gfx-bugs at 
lists.freede
   |.org|sktop.org
 QA Contact||intel-gfx-bugs at lists.freede
   ||sktop.org

--- Comment #1 from Jani Nikula  ---
To be fair, the same limitation was there before atomic.

Part of the problem is our modeset sequence, which we can't easily backtrack if
the modeset fails at link training phase. Another part is that even if our
modeset sequence supported that, we couldn't just reduce the mode to
accommodate the lower link rate behind userspace's back. (We already pick the
lowest rate that can support the mode; there's no margin to reduce.) We'd have
to involve userspace somehow.

Drivers are free to use the drm dp helpers or use their own hooks for modeset.
I think we should look at this from drm/i915 perspective, at least at first, so
resassigning to DRM/Intel. If we come up with a way to negotiate this with
userspace, that should be a generic solution.

-- 
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/20150904/da09dccb/attachment.html>

[Bug 90889] Radeon driver with radeon.dpm=1 causes lockout

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

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

--- Comment #3 from lolwoot1234 at gmail.com ---
Issue still not fixed...
Early KMS doesn't really change anything
anything.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: