[pull] radeon drm-next-3.16

[Alex Deucher]

Hi Dave,

Some additional patches for radeon for 3.16 now that -fixes has been merged.

- Gart fix for all asics r6xx+
- Add some VM tuning parameters
- misc fixes

The following changes since commit 4c0dae57873edb1560b738c6519361c5ecd443ae:

  drm/doc: Fix nouveau typo (2014-06-10 09:34:43 +1000)

are available in the git repository at:

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

for you to fetch changes up to 685d54b330d0f15c4f6c7bdf51e009aab0d6a750:

  drm/radeon: Move fb update from radeon_flip_work_func to 
radeon_crtc_page_flip (2014-06-09 22:09:12 -0400)


Alex Deucher (4):
  drm/radeon: add missing vce init case for hawaii
  drm/radeon: add query for number of active CUs
  Revert "drm/radeon: use variable UVD clocks"
  drm/radeon/dpm: powertune updates for SI

Christian K?nig (8):
  drm/radeon: use lower_32_bits where appropriate
  drm/radeon: stop poisoning the GART TLB
  drm/radeon: remove range check from *_gart_set_page
  drm/radeon: use the SDMA on for buffer moves on CIK again
  drm/radeon: rename alt_domain to allowed_domains
  drm/radeon: make VM size a module parameter (v2)
  drm/radeon: make vm_block_size a module parameter
  drm/radeon: add debugfs file to trigger GPU reset

Mario Kleiner (2):
  drm/edid: Store all supported hdmi deep color modes in drm_display_info
  drm/radeon: hdmi deep color modes must obey clock limit of sink.

Michel D?nzer (1):
  drm/radeon: Move fb update from radeon_flip_work_func to 
radeon_crtc_page_flip

 drivers/gpu/drm/drm_edid.c |  3 ++
 drivers/gpu/drm/radeon/atombios_crtc.c |  3 ++
 drivers/gpu/drm/radeon/cik.c   | 18 +---
 drivers/gpu/drm/radeon/cik_sdma.c  | 26 +-
 drivers/gpu/drm/radeon/evergreen.c | 12 
 drivers/gpu/drm/radeon/ni.c| 16 +--
 drivers/gpu/drm/radeon/r100.c  |  8 ++
 drivers/gpu/drm/radeon/r300.c  |  7 ++---
 drivers/gpu/drm/radeon/r600.c  | 11 +---
 drivers/gpu/drm/radeon/radeon.h| 22 +--
 drivers/gpu/drm/radeon/radeon_asic.c   |  4 +--
 drivers/gpu/drm/radeon/radeon_asic.h   | 12 +---
 drivers/gpu/drm/radeon/radeon_connectors.c | 31 +
 drivers/gpu/drm/radeon/radeon_cs.c |  8 +++---
 drivers/gpu/drm/radeon/radeon_device.c | 44 +++---
 drivers/gpu/drm/radeon/radeon_display.c|  6 ++--
 drivers/gpu/drm/radeon/radeon_drv.c| 11 +++-
 drivers/gpu/drm/radeon/radeon_fence.c  | 22 ++-
 drivers/gpu/drm/radeon/radeon_kms.c| 16 +++
 drivers/gpu/drm/radeon/radeon_mode.h   |  1 +
 drivers/gpu/drm/radeon/radeon_object.c |  9 +++---
 drivers/gpu/drm/radeon/radeon_pm.c |  3 ++
 drivers/gpu/drm/radeon/radeon_uvd.c|  3 +-
 drivers/gpu/drm/radeon/radeon_vce.c|  1 +
 drivers/gpu/drm/radeon/radeon_vm.c | 28 +--
 drivers/gpu/drm/radeon/rs400.c |  7 +
 drivers/gpu/drm/radeon/rs600.c | 11 
 drivers/gpu/drm/radeon/rv770.c |  3 ++
 drivers/gpu/drm/radeon/si.c| 17 +---
 drivers/gpu/drm/radeon/si_dma.c|  8 +++---
 drivers/gpu/drm/radeon/si_dpm.c| 13 +++--
 drivers/gpu/drm/radeon/uvd_v2_2.c  |  2 +-
 include/drm/drm_crtc.h |  3 ++
 include/uapi/drm/radeon_drm.h  |  2 +-
 34 files changed, 285 insertions(+), 106 deletions(-)

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Shawn Guo]

On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>  wrote:
> 
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
> > should report the current state of the hotplug detection.
> 
> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for
> HDMI cable connection.
> 
> > Remember that this code detects off the HPD signal - if the HPD signal
> > has not been correctly wired up, this patch is not going to help (really
> > it comes down to a hardware fault, which I'm not trying to solve with
> > this patch.)
> >
> > What I'm trying to resolve with this patch is that the state detected
> > on properly wired up systems corresponds with the real initial state of
> > the interface at initialisation time.
> >
> > The problem with the current code is that we start off assuming that the
> > interface is disconnected, and we rely on an interrupt arriving to change
> > that state.  If for whatever reason that interrupt does not arrive, then,
> > even if the HPD signal is active, we continue believing that the interface
> > is not connected.
> >
> > I seem to remember discussion in the past that the HPD signal is not
> > wired up on SabreSD.  Really, this needs to be a DT flag to indicate
> 
> It is sabrelite board that does not have HPD signal not wired up.
> 
> sabresd does have HPD signal connected.
> 
> The HDMI undetected issue I am seeing on sabresd seems to be related
> to the simultaneous usage of HDMI and LVDS.
> 
> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
> cable is correctly detected and HDMI is shown right after boot.

This is a known limitation.

http://thread.gmane.org/gmane.linux.ports.arm.kernel/315968/focus=318559

Shawn

[PATCH] drm/radeon: Move fb update from radeon_flip_work_func to radeon_crtc_page_flip

[Alex Deucher]

On Mon, Jun 9, 2014 at 9:21 PM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> Fixes WARN()s from the DRM core since the page flip rework.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77521
> Signed-off-by: Michel D?nzer 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index a4e725c..5ed6170 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -462,9 +462,6 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
> /* We borrow the event spin lock for protecting flip_work */
> spin_lock_irqsave(>dev->event_lock, flags);
>
> -   /* update crtc fb */
> -   crtc->primary->fb = fb;
> -
> /* set the proper interrupt */
> radeon_irq_kms_pflip_irq_get(rdev, radeon_crtc->crtc_id);
>
> @@ -539,6 +536,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
> }
> radeon_crtc->flip_work = work;
>
> +   /* update crtc fb */
> +   crtc->primary->fb = fb;
> +
> spin_unlock_irqrestore(>dev->event_lock, flags);
>
> queue_work(radeon_crtc->flip_queue, >flip_work);
> --
> 2.0.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Mon, Jun 09, 2014 at 03:47:46PM -0300, Fabio Estevam wrote:
> Also tested keeping LVDS parent as PLL5 and reverted this commit:
> 
> commit 17b9b3b9e88ac6564689283a08034faf2c048fdb
> Author: Sascha Hauer 
> Date:   Mon Apr 14 16:20:39 2014 +0200
> 
> ARM: imx6q: clk: Parent DI clocks to video PLL via di_pre_sel
> 
> Route the video PLL to the display interface clocks via the di_pre_sel
> and di_sel muxes by default.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Philipp Zabel 
> Tested-by: Russell King 
> Signed-off-by: Shawn Guo 
> 
> 
> ,then HDMI and LVDS work at the same time.

Right, so the problem isn't at the HDMI level, but at the DI level... so
that's where we need to debug what's being setup.  I left some debugging
in ipu-di.c - could you try enabling that please?

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

[Bug 79852] New: Mesa-10.2.1/src/gallium/state_trackers/vega/api_params.c:60: possible bad if test ?

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

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

  Priority: medium
Bug ID: 79852
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Mesa-10.2.1/src/gallium/state_trackers/vega/api_params
.c:60: possible bad if test ?
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: dcb314 at hotmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

[Mesa-10.2.1/src/gallium/state_trackers/vega/api_params.c:60]: (warning)
Logical disjunction always evaluates to true: count >= 0 || count <= 128.

  return (!(count % 4) && (count >= 0 || count <= VEGA_MAX_SCISSOR_RECTS *
4));

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

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

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

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

--- Comment #1 from Sylvain BERTRAND  ---
Created attachment 100768
  --> https://bugs.freedesktop.org/attachment.cgi?id=100768=edit
dmesg

-- 
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/20140609/23d761bd/attachment.html>

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

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

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

  Priority: medium
Bug ID: 79850
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [awesomenauts][radeonsi] pageflip is clearly missing
vblank with vsync on
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: sylvain.bertrand at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 100767
  --> https://bugs.freedesktop.org/attachment.cgi?id=100767=edit
Xorg.0.log

While playing the game, I can see the page flip tearing happening at the top of
the screen with vsync on.

log files included.

-- 
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/20140609/339313ee/attachment.html>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Mon, Jun 09, 2014 at 03:38:55PM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam  wrote:
> >> I wonder if the problem is that HDMI and LVDS are interfering with each
> >> other wrt the required pixel clock, and LVDS is winning.  If we have
> >> HDMI enabled, many HDMI sinks will only work if we set one of their
> >> supported modes (with the dot clock within 1% - though some sinks are
> >> more lenient).
> >
> > Yes, it seems this is the case.
> 
> I tested not using pll5 as the parent of LVDS:
> 
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -439,12 +439,6 @@ static void __init imx6q_clocks_init(struct device_node 
> *cc
> clk_register_clkdev(clk[gpt_ipg_per], "per", "imx-gpt.0");
> clk_register_clkdev(clk[enet_ref], "enet_ref", NULL);
> 
> -   if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
> -   cpu_is_imx6dl()) {
> -   clk_set_parent(clk[ldb_di0_sel], clk[pll5_video_div]);
> -   clk_set_parent(clk[ldb_di1_sel], clk[pll5_video_div]);
> -   }
> -
> clk_set_parent(clk[ipu1_di0_pre_sel], clk[pll5_video_div]);
> clk_set_parent(clk[ipu1_di1_pre_sel], clk[pll5_video_div]);
> clk_set_parent(clk[ipu2_di0_pre_sel], clk[pll5_video_div]);
> 
> 
> Then the HDMI detection works fine and I get images on both HDMI and LVDS.
> 
> I understand that many LVDS panels need a frequency range that can
> only be obtained via PLL5 though.

HDMI pretty much fundamentally requires PLL5.

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

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Mon, Jun 09, 2014 at 03:15:16PM -0300, Fabio Estevam wrote:
> With HDMI cable connected (no image is seen on HDMI, only on lvds cable):
> 
> imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 0

Right, so it does know that the HDMI sink is connected...

> imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: got edid: width[51] x height[28]
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 13850
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 13850
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode

And the mode it's setting has a pixel clock frequency of 138.5MHz here.

> If I disconnect/reconnect the HDMI cable (then image is seen on both
> HDMI and LVDS):
> 
> root at freescale /$ imx-hdmi 12.hdmi: EVENT=plugout
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 13850
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: got edid: width[51] x height[28]
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 13850
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 13850
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode

And here it again configures 138.5MHz pixel clock - same as above.  So,
from this we can't see any difference in the setup, and we can say that
it's not mode->clock which is the problem.

> Now booting the kernel with HDMI disconnected:
> 
> imx-hdmi 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
> imx-hdmi 12.hdmi: hdmi_set_clk_regenerator: samplerate=48000
> ratio=100  pixelclk=7425  N=6144 cts=74250
> imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)

Right, so here it knows that there's nothing connected.

> imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
> Console: switching to colour frame buffer device 128x48

So it selects an initial mode based upon the LVDS device configuration.

> And after connecting the HDMI cable:
> 
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 0
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: got edid: width[51] x height[28]
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 7880
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx-hdmi 12.hdmi: final pixclk = 7880
> imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
> 
> Image is seen on both LVDS and HDMI monitor, but HDMI resolution is
> not correct (this is a different bug though).

I'm guessing that here, DRM kept the original configuration rather than
selecting one appropriate to the newly connected device.

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

[PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro

[Alexandre Courbot]

On Mon, May 19, 2014 at 6:22 PM, Lucas Stach  wrote:
> Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
>> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
>> > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
>> > flushed for a memory write to take effect. Not doing so results in
>> > synchronization issues, especially after writing to BOs.
>>
>> It seems to me that the above is generally true for all architectures,
>> not just ARM.
>>
> No, on PCI coherent arches, like x86 and some PowerPCs, the GPU will
> snoop the CPU caches and therefore an explicit cache flush is not
> required.
>
>> Also: s/explicitely/explicitly/
>>
>> > This patch introduces a macro that flushes the caches on ARM and
>> > translates to a no-op on other architectures, and uses it when
>> > writing to in-memory BOs. It will also be useful for implementations of
>> > instmem that access shared memory directly instead of going through
>> > PRAMIN.
>>
>> Presumably instmem can access shared memory on all architectures, so
>> this doesn't seem like a property of the architecture but rather of the
>> memory pool backing the instmem.
>>
>> In that case I wonder if this shouldn't be moved into an operation that
>> is implemented by the backing memory pool and be a noop where the cache
>> doesn't need explicit flushing.
>>
>> > diff --git a/drivers/gpu/drm/nouveau/core/os.h 
>> > b/drivers/gpu/drm/nouveau/core/os.h
>> > index d0ced94ca54c..274b4460bb03 100644
>> > --- a/drivers/gpu/drm/nouveau/core/os.h
>> > +++ b/drivers/gpu/drm/nouveau/core/os.h
>> > @@ -38,4 +38,21 @@
>> >  #endif /* def __BIG_ENDIAN else */
>> >  #endif /* !ioread32_native */
>> >
>> > +#if defined(__arm__)
>> > +
>> > +#define nv_cpu_cache_flush_area(va, size)  \
>> > +do {   \
>> > +   phys_addr_t pa = virt_to_phys(va);  \
>> > +   __cpuc_flush_dcache_area(va, size); \
>> > +   outer_flush_range(pa, pa + size);   \
>> > +} while (0)
>>
>> Couldn't this be a static inline function?
>>
>> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
>> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> [...]
>> > index 0886f47e5244..b9c9729c5733 100644
>> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> > @@ -437,8 +437,10 @@ nouveau_bo_wr16(struct nouveau_bo *nvbo, unsigned 
>> > index, u16 val)
>> > mem = [index];
>> > if (is_iomem)
>> > iowrite16_native(val, (void __force __iomem *)mem);
>> > -   else
>> > +   else {
>> > *mem = val;
>> > +   nv_cpu_cache_flush_area(mem, 2);
>> > +   }
>> >  }
>> >
>> >  u32
>> > @@ -461,8 +463,10 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned 
>> > index, u32 val)
>> > mem = [index];
>> > if (is_iomem)
>> > iowrite32_native(val, (void __force __iomem *)mem);
>> > -   else
>> > +   else {
>> > *mem = val;
>> > +   nv_cpu_cache_flush_area(mem, 4);
>> > +   }
>>
>> This looks rather like a sledgehammer to me. Effectively this turns nvbo
>> into an uncached buffer. With additional overhead of constantly flushing
>> caches. Wouldn't it make more sense to locate the places where these are
>> called and flush the cache after all the writes have completed?
>>
> I don't think the explicit flushing for those things makes sense. I
> think it is a lot more effective to just map the BOs write-combined on
> PCI non-coherent arches. This way any writes will be buffered. Reads
> will be slow, but I don't think nouveau is reading back a lot from those
> buffers.
> Using the write-combining buffer doesn't need any additional
> synchronization as it will get flushed on pushbuf kickoff anyways.

I tried to go that way, and something interesting happened.

What I did: remove this patch and instead set the following caching
parameters for the TTM_PL_TT case in nouveau_bo_init_mem_type():

man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;

What happened: no runtime errors as what happened when caching is
enabled. However, many of the vertex and texture buffers seem to be
partially corrupted. In glmark2 the 3d models had many vertices (but
not all) at the wrong position. Note that not all the scenes ended up
being corrupted - in particular, when two consecutive scenes used the
same model, the second instance would be uncorrupted.

Forcing the caching to TTM_PL_FLAG_UNCACHED led to the same result.
What is interesting is that while data like vertices and textures got
corrupted, pushbuffers and shader programs seem to be just fine, as I
could not see any runtime error.

I don't really understand what kind of caching behavior could lead to
that. If anyone has any idea, I'd love to hear.

Thanks,
Alex.

[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object image

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

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

--- Comment #3 from pavol at klacansky.com ---
As I mentioned, I use CPU as OpenCL device using APP SDK.

I have a problem with OpenGL OpenCL interop. OpenCL from AMD APP SDK works
fine, the problem is when I use Gallium driver for OpenGL, I get corrupted
image.

-- 
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/20140609/b9a7d070/attachment.html>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>  wrote:
> 
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
> > should report the current state of the hotplug detection.
> 
> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for
> HDMI cable connection.

Good, so that means we're reporting the correct status to the DRM layer.
Please post the kernel boot messages, one with the HDMI cable disconnected,
and one with a HDMI sink connected.

> The HDMI undetected issue I am seeing on sabresd seems to be related
> to the simultaneous usage of HDMI and LVDS.
> 
> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
> cable is correctly detected and HDMI is shown right after boot.

I wonder if the problem is that HDMI and LVDS are interfering with each
other wrt the required pixel clock, and LVDS is winning.  If we have
HDMI enabled, many HDMI sinks will only work if we set one of their
supported modes (with the dot clock within 1% - though some sinks are
more lenient).

I think the Novena people have run into this issue, but I've not seen
much in the way of contributions back, despite them making use of my
patches...

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

[patch] gma500: remove duplicate FB_REG09 define

[Jani Nikula]

Patrik, Alan -

Should you add a MAINTAINERS entry for gma500 with one or both of you as
maintainers? What's the status?

BR,
Jani.


On Mon, 09 Jun 2014, Dan Carpenter  wrote:
> The FB_REG09 define is cut and pasted twice so we can remove the second
> instance.
>
> Signed-off-by: Dan Carpenter 
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
> b/drivers/gpu/drm/gma500/mid_bios.c
> index a97e38e..d75ecb3 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -39,7 +39,6 @@ static void mid_get_fuse_settings(struct drm_device *dev)
>  #define FB_REG06 0xD0810600
>  #define FB_MIPI_DISABLE  (1 << 11)
>  #define FB_REG09 0xD0810900
> -#define FB_REG09 0xD0810900
>  #define FB_SKU_MASK  0x7000
>  #define FB_SKU_SHIFT 12
>  #define FB_SKU_100 0
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #32 from Alex Deucher  ---
Created attachment 138641
  --> https://bugzilla.kernel.org/attachment.cgi?id=138641=edit
testing patch

Does this patch help?  Note, this will probably break regular suspend/resume,
so just test it for switcheroo.

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

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #31 from Alex Deucher  ---
Ok, it appears powering up the dGPU has never worked properly on your system. 
As a workaround for now you can disable runpm by adding radeon.runpm=0.  I can
add a quirk to the driver to disable runpm on your system by default until
someone figures out how to fix it.

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

[patch] gma500: remove duplicate FB_REG09 define

[Dan Carpenter]

The FB_REG09 define is cut and pasted twice so we can remove the second
instance.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index a97e38e..d75ecb3 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -39,7 +39,6 @@ static void mid_get_fuse_settings(struct drm_device *dev)
 #define FB_REG06 0xD0810600
 #define FB_MIPI_DISABLE  (1 << 11)
 #define FB_REG09 0xD0810900
-#define FB_REG09 0xD0810900
 #define FB_SKU_MASK  0x7000
 #define FB_SKU_SHIFT 12
 #define FB_SKU_100 0

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #30 from Teofilis Martisius  ---
Created attachment 138631
  --> https://bugzilla.kernel.org/attachment.cgi?id=138631=edit
dmesg output for 3.15-rc8 patched with delay of 200

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

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #29 from Teofilis Martisius  ---
Created attachment 138621
  --> https://bugzilla.kernel.org/attachment.cgi?id=138621=edit
dmesg output for 3.12.21 patched with delay of 200

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

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #28 from Teofilis Martisius  ---
Hello,

Sorry for the delay, I had other plans for the weekend.

The patch did not help. I tried it with default delay of 20, and then I tried
it with delay set to 200 (200 what? milliseconds?). I tried both default delay
and 200 delay on both 3.12.21 and on 3.15rc8, no luck. I changed the patch to
increase the delay and to print out the delay- you can see it in dmesg. I have
attached the dmesg output for the 200 delay runs for 3.12.21 and 3.15rc8.

I ran the kernels with following boot parameters:

3.12.21: BOOT_IMAGE=/boot/vmlinuz-3.12.21d200 root=UUID=xxx ro quiet
radeon.audio=0 modeset=1

3.15.0-rc8 BOOT_IMAGE=/boot/vmlinuz-3.15.0-rc8teo root=xxx ro quiet
radeon.audio=0 modeset=1 radeon.runpm=0

Sincerely,
Teofilis Martisius

diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index b512c00..0574d56 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1093,8 +1093,10 @@ static void radeon_switcheroo_set_state(struct pci_dev
*pdev, enum vga_switchero
/* don't suspend or resume card normally */
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;

-   if (d3_delay < 20 && radeon_switcheroo_quirk_long_wakeup(pdev))
-   dev->pdev->d3_delay = 20;
+   if (d3_delay < 200 /*&&
radeon_switcheroo_quirk_long_wakeup(pdev)*/) {
+   dev->pdev->d3_delay = 200;
+   printk(KERN_INFO "radeon: d3 delay set to 200\n");
+   }

radeon_resume_kms(dev, true, true);

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

[Bug 76223] [radeonsi] luxmark segfault

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

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

--- Comment #6 from Aaron Watry  ---
If you're building from luxrays source, can you also try disabling image
support and seeing if the error changes?

For a source build, go to scenes/luxball/luxball.cfg, and add:
accelerator.imagestorage.enable = 1

When I do that, I get some errors related to missing built-in functions that
libclc is probably failing to provide:

[LuxRays] [OpenCL device::AMD CEDARIntersect] QBVH compilation error:
ray_funcs.cl:43:14: error: use of undeclared identifier 'INFINITY'
ray->maxt = INFINITY;
^
qbvh_kernel.cl:119:17: warning: implicit declaration of function 'isnotequal'
is invalid in C99
int4 cond = isnotequal(divisor, (float4)0.f) & isgreaterequal(b0,
(float4)0.f) &
^
qbvh_kernel.cl:119:52: warning: implicit declaration of function
'isgreaterequal' is invalid in C99
int4 cond = isnotequal(divisor, (float4)0.f) & isgreaterequal(b0,
(float4)0.f) &
   ^
qbvh_kernel.cl:121:4: warning: implicit declaration of function 'isgreater' is
invalid in C99
isgreater(t, ray4->mint);
^
qbvh_kernel.cl:206:21: warning: implicit declaration of function 'signbit' is
invalid in C99
const int signs0 = signbit(ray4.dx.s0);
   ^

[SLG] OpenCL ERROR: clBuildProgram(CL_BUILD_PROGRAM_FAILURE)

-- 
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/20140609/53373df8/attachment.html>

[Bug 76223] [radeonsi] luxmark segfault

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

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

--- Comment #5 from Aaron Watry  ---
Created attachment 100762
  --> https://bugs.freedesktop.org/attachment.cgi?id=100762=edit
slg4 log with CEDAR

What command are you running this with?  Is it just running bin/slg4 as built
from the luxrays source?

I believe that I have built the luxrays repository with changeset 2099 (a.k.a.
7459cd8a9583 as quoted as a changeset hash in your backtrace), but every time
that I attempt to run bin/slg4, I get OpenCL errors due to missing image format
support in clover.  

Log from bin/slg4 attached.

I believe that the line causing the error *might* be in
src/luxrays/accelerators/qbvhaccel.cpp:411

cl::Image2D *qbvhBuff = new cl::Image2D(oclContext,
CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,
cl::ImageFormat(CL_RGBA, CL_UNSIGNED_INT32),
nodeWidth, nodeHeight, 0, inodes);

-- 
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/20140609/bfaad6be/attachment.html>

[PATCH v2 7/7] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

[Boris BREZILLON]

Enable LCD related nodes and reference panel node in the hlcdc (High
LCD Controller) controller on sama5d3xek boards.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d31ek.dts | 24 
 arch/arm/boot/dts/sama5d33ek.dts | 24 
 arch/arm/boot/dts/sama5d34ek.dts | 24 
 arch/arm/boot/dts/sama5d36ek.dts | 24 
 4 files changed, 96 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d31ek.dts b/arch/arm/boot/dts/sama5d31ek.dts
index 04eec0d..338f4c3 100644
--- a/arch/arm/boot/dts/sama5d31ek.dts
+++ b/arch/arm/boot/dts/sama5d31ek.dts
@@ -33,6 +33,14 @@
status = "okay";
};

+   hlcdc: hlcdc at f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = < 3 0>;
+   };
+   };
+
macb1: ethernet at f802c000 {
status = "okay";
};
@@ -46,6 +54,22 @@
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d33ek.dts b/arch/arm/boot/dts/sama5d33ek.dts
index cbd6a3f..f2ab41d 100644
--- a/arch/arm/boot/dts/sama5d33ek.dts
+++ b/arch/arm/boot/dts/sama5d33ek.dts
@@ -36,9 +36,33 @@
macb0: ethernet at f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc at f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = < 3 0>;
+   };
+   };
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
index 878aa16..0d0049c 100644
--- a/arch/arm/boot/dts/sama5d34ek.dts
+++ b/arch/arm/boot/dts/sama5d34ek.dts
@@ -46,6 +46,14 @@
macb0: ethernet at f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc at f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = < 3 0>;
+   };
+   };
};
};

@@ -56,6 +64,22 @@
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d36ek.dts b/arch/arm/boot/dts/sama5d36ek.dts
index 59576c6..8350358 100644
--- a/arch/arm/boot/dts/sama5d36ek.dts
+++ b/arch/arm/boot/dts/sama5d36ek.dts
@@ -41,12 +41,36 @@
status = "okay";
};

+   hlcdc: hlcdc at f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = < 3 0>;
+   };
+   };
+
macb1: ethernet at f802c000 {
status = "okay";
};
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
-- 
1.8.3.2

[PATCH v2 6/7] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi

[Boris BREZILLON]

Add LCD panel related nodes (backlight, regulators and panel) to the
sama5d3 Display Module dtsi.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xdm.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi 
b/arch/arm/boot/dts/sama5d3xdm.dtsi
index 035ab72..7eb849f 100644
--- a/arch/arm/boot/dts/sama5d3xdm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xdm.dtsi
@@ -38,4 +38,36 @@
};
};
};
+
+   bl_reg: backlight_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "backlight-power-supply";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   status = "disabled";
+   };
+
+   panel_reg: panel_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "panel-power-supply";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   status = "disabled";
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <_pwm 0 5 0>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   power-supply = <_reg>;
+   status = "disabled";
+   };
+
+   panel: panel {
+   compatible = "foxlink,fl500wvr00-a0t", "simple-panel";
+   backlight = <>;
+   power-supply = <_reg>;
+   status = "disabled";
+   };
 };
-- 
1.8.3.2

[PATCH v2 5/7] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs

[Boris BREZILLON]

Define the HLCDC (High LCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36).

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 2186b89..02a7012 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -116,6 +116,32 @@
};
};

+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", 
"slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", 
"rgb-565", "rgb-666", "rgb-888";
+   pinctrl-0 = <_lcd_base>;
+   pinctrl-1 = <_lcd_base 
_lcd_rgb444>;
+   pinctrl-2 = <_lcd_base 
_lcd_rgb565>;
+   pinctrl-3 = <_lcd_base 
_lcd_rgb666>;
+   pinctrl-4 = <_lcd_base 
_lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
+
pmc: pmc at fc00 {
periphck {
lcdc_clk: lcdc_clk {
-- 
1.8.3.2

[PATCH v2 4/7] ARM: at91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

[Boris BREZILLON]

The HLCDC (High LCD Controller) IP supports 4 different output mode
(RGB444, RGB565, RGB666 and RGB888) and the pin muxing depends on the
chosen RGB mode.

Split the pin definition to be able to set the pin config according to the
selected mode.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 127 -
 1 file changed, 96 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 85d3027..2186b89 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -15,38 +15,103 @@
apb {
pinctrl at f200 {
lcd {
-   pinctrl_lcd: lcd-0 {
+   pinctrl_lcd_pwm: lcd-pwm-0 {
+   atmel,pins = ;/* LCDPWM */
+   };
+
+   pinctrl_lcd_base: lcd-base-0 {
+   atmel,pins =
+   ; /* LCDPCK */
+   };
+
+   pinctrl_lcd_rgb444: lcd-rgb-0 {
+   atmel,pins =
+   ; /* LCDD11 pin */
+   };
+
+   pinctrl_lcd_rgb565: lcd-rgb-1 {
+   atmel,pins =
+   ; /* LCDD15 pin */
+   };
+
+   pinctrl_lcd_rgb666: lcd-rgb-2 {
+   atmel,pins =
+   ; /* LCDD17 pin */
+   };
+
+   pinctrl_lcd_rgb888: lcd-rgb-3 {
atmel,pins =
-   ; /* PE28 periph C LCDD23 pin */
+   ; /* LCDD23 pin */
};
};
};
-- 
1.8.3.2

[PATCH v2 3/7] drm: add Atmel HLCDC Display Controller support

[Boris BREZILLON]

The Atmel HLCDC (High LCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller support at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  59 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 529 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 477 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 178 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 701 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 417 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c| 351 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 658 +++
 drivers/gpu/drm/atmel_hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel_hlcdc/Makefile   |   8 +
 14 files changed, 3410 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
 create mode 100644 drivers/gpu/drm/atmel_hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel_hlcdc/Makefile

diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
new file mode 100644
index 000..594bdb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
@@ -0,0 +1,59 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,hlcdc-dc"
+ - interrupts: the HLCDC interrupt definition
+ - pinctrl-names: the pin control state names. Should contain "default",
+   "rgb-444", "rgb-565", "rgb-666" and "rgb-888".
+ - pinctrl-[0-4]: should contain the pinctrl states described by pinctrl
+   names.
+ - atmel,panel: Should contain a phandle with 2 parameters.
+   The first cell is a phandle to a DRM panel device
+   The second cell encodes the RGB mode, which can take the following values:
+   * 0: RGB444
+   * 1: RGB565
+   * 2: RGB666
+   * 3: RGB888
+   The third cell encodes specific flags describing LCD signals configuration
+   (see Atmel's datasheet for a full description of these fields):
+   * bit 0: HSPOL: Horizontal Synchronization Pulse Polarity
+   * bit 1: VSPOL: Vertical Synchronization Pulse Polarity
+   * bit 2: VSPDLYS: Vertical Synchronization Pulse Start
+   * bit 3: VSPDLYE: Vertical Synchronization Pulse End
+   * bit 4: DISPPOL: Display Signal Polarity
+   * bit 7: DISPDLY: LCD Controller Display Power Signal Synchronization
+   * bit 12: VSPSU: LCD Controller Vertical synchronization Pulse Setup 
Configuration
+   * bit 13: VSPHO: LCD Controller Vertical synchronization Pulse Hold 
Configuration
+   * bit 16-20: GUARDTIME: LCD DISPLAY Guard Time
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <_lcd_base>;
+   pinctrl-1 = <_lcd_base _lcd_rgb444>;
+   pinctrl-2 = <_lcd_base _lcd_rgb565>;
+   pinctrl-3 = <_lcd_base _lcd_rgb666>;
+   pinctrl-4 = <_lcd_base _lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+  

[PATCH v2 2/7] pwm: add support for atmel-hlcdc-pwm device

[Boris BREZILLON]

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.

This driver add support for this PWM device.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  40 
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c  | 216 +
 4 files changed, 266 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
 create mode 100644 drivers/pwm/pwm-atmel-hlcdc.c

diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt 
b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
new file mode 100644
index 000..5e2ba87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
@@ -0,0 +1,40 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) PWM driver
+
+The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
+See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,hlcdc-pwm"
+ - pinctr-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the pinctrl states described by pinctrl
+   default.
+ - #pwm-cells: should be set to 3.
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <_lcd_base>;
+   pinctrl-1 = <_lcd_base _lcd_rgb444>;
+   pinctrl-2 = <_lcd_base _lcd_rgb565>;
+   pinctrl-3 = <_lcd_base _lcd_rgb666>;
+   pinctrl-4 = <_lcd_base _lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..7186242 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -50,6 +50,15 @@ config PWM_ATMEL
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel.

+config PWM_ATMEL_HLCDC_PWM
+   tristate "Atmel HLCDC PWM support"
+   depends on MFD_ATMEL_HLCDC
+   help
+ Generic PWM framework driver for Atmel HLCDC PWM.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
 config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..a245519 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PWM)   += core.o
 obj-$(CONFIG_PWM_SYSFS)+= sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
+obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)  += pwm-atmel-hlcdc.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
new file mode 100644
index 000..080e43e
--- /dev/null
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_HLCDC_PWMCVAL_MASK   (0xff << 8)
+#define ATMEL_HLCDC_PWMCVAL(x) (((x) & 0xff) << 8)
+#define ATMEL_HLCDC_PWMPOL BIT(4)
+#define ATMEL_HLCDC_PWMPS_MASK 0x7
+#define ATMEL_HLCDC_PWMPS_MAX  0x6
+#define 

[PATCH v2 1/7] mfd: add atmel-hlcdc driver

[Boris BREZILLON]

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip

Add support for the MFD device which will just retrieve HLCDC clocks and
create a regmap so that subdevices can access the HLCDC register range
concurrently.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/mfd/atmel-hlcdc.txt|  41 
 drivers/mfd/Kconfig|  11 ++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-hlcdc.c  | 116 +
 include/linux/mfd/atmel-hlcdc.h|  78 ++
 5 files changed, 247 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
 create mode 100644 drivers/mfd/atmel-hlcdc.c
 create mode 100644 include/linux/mfd/atmel-hlcdc.h

diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt 
b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
new file mode 100644
index 000..f5b69cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
@@ -0,0 +1,41 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,sama5d3-hlcdc"
+ - reg: base address and size of the HLCDC device registers.
+ - clock-names: the name of the 3 clocks requested by the HLCDC device.
+   Should contain "periph_clk", "sys_clk" and "slow_clk".
+ - clocks: should contain the 3 clocks requested by the HLCDC device.
+
+The HLCDC IP exposes two subdevices:
+ - a PWM chip: see Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
+ - a Display Controller: see 
Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <_lcd_base>;
+   pinctrl-1 = <_lcd_base _lcd_rgb444>;
+   pinctrl-2 = <_lcd_base _lcd_rgb565>;
+   pinctrl-3 = <_lcd_base _lcd_rgb666>;
+   pinctrl-4 = <_lcd_base _lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ee8204c..82777f6 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,17 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.

+config MFD_ATMEL_HLCDC
+   tristate "Atmel HLCDC (High LCD Controller)"
+   select MFD_CORE
+   select REGMAP_MMIO
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC (High
+ LCD Controller) IP (i.e. at91sam9n12, at91sam9x5 family or sama5d3
+ family).
+ This MFD device exposes two subdevices: a PWM chip and a Display
+ Controller.
+
 config MFD_BCM590XX
tristate "Broadcom BCM590xx PMUs"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..5f25b0d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_MFD_PM8921_CORE)   += pm8921-core.o ssbi.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_INTEL_MSIC)   += intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
new file mode 100644
index 000..e4636e8
--- /dev/null
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the 

[PATCH v2 0/7] drm: add support for Atmel HLCDC Display Controller

[Boris BREZILLON]

Hello,

This patch series adds support for Atmel HLCDC (High LCD Controller)
available on some Atmel SoCs (i.e. the sama5d3 family).

The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device that exposes 2 subdevices: a display
controller and a PWM chip.
This also solves a circular dependency issue preventing HLCDC driver from
unloading.
The HLCDC request a drm_panel device, which request a backlight device
(a PWM backlight), which depends on a PWM which is provided by the HLCDC
driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).

The current implementation only support sama5d3 SoCs but other SoCs should
be easily ported by defining new compatible strings and adding HLCDC
description structures for these SoCs.

The drivers supports basic CRTC functionalities, several overlays and an
hardware cursor.

It alse supports several RGB format on all planes and some YUV formats on
the HEO overlay plane, though YUV formats have not been tested yet.

Best Regards,

Boris

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor

Boris BREZILLON (7):
  mfd: add atmel-hlcdc driver
  pwm: add support for atmel-hlcdc-pwm device
  drm: add Atmel HLCDC Display Controller support
  ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
configs
  ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
  ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi
  ARM: at91/dt: enable the LCD panel on sama5d3xek boards

 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  59 ++
 .../devicetree/bindings/mfd/atmel-hlcdc.txt|  41 ++
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  40 ++
 arch/arm/boot/dts/sama5d31ek.dts   |  24 +
 arch/arm/boot/dts/sama5d33ek.dts   |  24 +
 arch/arm/boot/dts/sama5d34ek.dts   |  24 +
 arch/arm/boot/dts/sama5d36ek.dts   |  24 +
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 153 -
 arch/arm/boot/dts/sama5d3xdm.dtsi  |  32 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 529 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 477 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 178 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 701 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 417 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c| 351 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 658 +++
 drivers/gpu/drm/atmel_hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel_hlcdc/Makefile   |   8 +
 drivers/mfd/Kconfig|  11 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-hlcdc.c  | 116 
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c  | 216 +++
 include/linux/mfd/atmel-hlcdc.h|  78 +++
 29 files changed, 4173 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
 create mode 100644 drivers/gpu/drm/atmel_hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel_hlcdc/Makefile
 create mode 100644 drivers/mfd/atmel-hlcdc.c
 create mode 100644 drivers/pwm/pwm-atmel-hlcdc.c
 create mode 100644 include/linux/mfd/atmel-hlcdc.h

-- 
1.8.3.2

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
 wrote:

> Right, so the problem isn't at the HDMI level, but at the DI level... so
> that's where we need to debug what's being setup.  I left some debugging
> in ipu-di.c - could you try enabling that please?

Sure, will capture the logs tomorrow morning because I don't have
access to the HDMI monitor at the moment.

Thanks

[Bug 79842] Performance drop since mesa 10.1.4

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

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

--- Comment #4 from Grigori Goronzy  ---
Probably related to this:

http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.1=1ba2298131924daf34b4504ba748a782c5189f48

Anisotropic filtering was broken in radeonsi, and that fixed it. Anisotropic
filtering has some overhead, which explains the slightly reduced performance.

This patch was applied to 10.1 and 10.2 branches as well as master.

-- 
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/20140609/9d4ee611/attachment.html>

[Bug 79842] Performance drop since mesa 10.1.4

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

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

--- Comment #3 from Alex Deucher  ---
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/20140609/e62d924f/attachment.html>

[Bug 77521] radeon: Horizontal lines of semi-random contents are sometimes displayed

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

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

--- Comment #2 from Martin Andersson  ---
(In reply to Michel D?nzer from comment #1)
> Created attachment 138561 [details]
> Move fb update from radeon_flip_work_func() to radeon_crtc_page_flip()
> 
> This (untested) patch should fix at least the warnings in dmesg, not sure
> about the visual artifacts though.

Yep, the warnings are now gone, but the artifacts are still there

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

[PATCH 5/5] drm/i915: Kick out vga console

[Tomi Valkeinen]

Hi,

On 06/06/14 18:20, Daniel Vetter wrote:
> Tomi/Jean can you please ack merging this through drm-intel trees? It
> just exports the vga and dummy consoles so that i915 can do what it
> needs to do.

Acked-by: Tomi Valkeinen 

 Tomi


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

[Bug 79842] Performance drop since mesa 10.1.4

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

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

--- Comment #2 from Tom Guder  ---
Created attachment 100757
  --> https://bugs.freedesktop.org/attachment.cgi?id=100757=edit
Unigine Valley worse

-- 
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/20140609/aeb9df01/attachment.html>

[Bug 79842] Performance drop since mesa 10.1.4

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

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

--- Comment #1 from Tom Guder  ---
Created attachment 100756
  --> https://bugs.freedesktop.org/attachment.cgi?id=100756=edit
Unigine Valley good

-- 
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/20140609/c8e945db/attachment.html>

[Bug 79842] New: Performance drop since mesa 10.1.4

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

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

  Priority: medium
Bug ID: 79842
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Performance drop since mesa 10.1.4
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: kontakt at ib-guder.de
  Hardware: Other
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 100755
  --> https://bugs.freedesktop.org/attachment.cgi?id=100755=edit
The results from fumark benchmark

Hello.

I've noticed a performancedrop since mesa 10.1.4 (and also with 10.2.1 now). I
ran fumark_benchmark and unigine_valley. I append the results for fumark. I
don't know if it is kernel or mesa problem.

I use radeonsi.

Best regards!
Tom

-- 
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/20140609/27ce5733/attachment.html>

[Bug 79551] DRI_PRIME not working

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

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

--- Comment #8 from Maxim  ---
(In reply to comment #7)
> (In reply to comment #6)
> > if in /etc/environment set DRI_PRIME=1 and in /etc/xprofile set xcompmgr -c 
> > &
> > some apps will display with artifacts (part of window freezes when 
> > scrolling)
> 
> Apps using PRIME, or others?
> 
> BTW, just xcompmgr -a should be enough, no need for -c.

others.
Today I've tested with DRI_PRIME=0. Same lags. It's appear, when xcompmgr
running.

-- 
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/20140609/f49c46a2/attachment.html>

[PATCH] drm/exynos: disable unused windows on apply

[Andrzej Hajda]

The patch disables non-enabled HW windows on applying
configuration, it will allow to clear windows enabled
by bootloader.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bb45ab2..33161ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -741,6 +741,8 @@ static void fimd_apply(struct exynos_drm_manager *mgr)
win_data = >win_data[i];
if (win_data->enabled)
fimd_win_commit(mgr, i);
+   else
+   fimd_win_disable(mgr, i);
}

fimd_commit(mgr);
-- 
1.9.1

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 3:38 PM, Fabio Estevam  wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam  wrote:
>>> I wonder if the problem is that HDMI and LVDS are interfering with each
>>> other wrt the required pixel clock, and LVDS is winning.  If we have
>>> HDMI enabled, many HDMI sinks will only work if we set one of their
>>> supported modes (with the dot clock within 1% - though some sinks are
>>> more lenient).
>>
>> Yes, it seems this is the case.
>
> I tested not using pll5 as the parent of LVDS:
>
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -439,12 +439,6 @@ static void __init imx6q_clocks_init(struct device_node 
> *cc
> clk_register_clkdev(clk[gpt_ipg_per], "per", "imx-gpt.0");
> clk_register_clkdev(clk[enet_ref], "enet_ref", NULL);
>
> -   if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
> -   cpu_is_imx6dl()) {
> -   clk_set_parent(clk[ldb_di0_sel], clk[pll5_video_div]);
> -   clk_set_parent(clk[ldb_di1_sel], clk[pll5_video_div]);
> -   }
> -
> clk_set_parent(clk[ipu1_di0_pre_sel], clk[pll5_video_div]);
> clk_set_parent(clk[ipu1_di1_pre_sel], clk[pll5_video_div]);
> clk_set_parent(clk[ipu2_di0_pre_sel], clk[pll5_video_div]);
>
>
> Then the HDMI detection works fine and I get images on both HDMI and LVDS.
>
> I understand that many LVDS panels need a frequency range that can
> only be obtained via PLL5 though.

Also tested keeping LVDS parent as PLL5 and reverted this commit:

commit 17b9b3b9e88ac6564689283a08034faf2c048fdb
Author: Sascha Hauer 
Date:   Mon Apr 14 16:20:39 2014 +0200

ARM: imx6q: clk: Parent DI clocks to video PLL via di_pre_sel

Route the video PLL to the display interface clocks via the di_pre_sel
and di_sel muxes by default.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 
Tested-by: Russell King 
Signed-off-by: Shawn Guo 


,then HDMI and LVDS work at the same time.

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam  wrote:
>> I wonder if the problem is that HDMI and LVDS are interfering with each
>> other wrt the required pixel clock, and LVDS is winning.  If we have
>> HDMI enabled, many HDMI sinks will only work if we set one of their
>> supported modes (with the dot clock within 1% - though some sinks are
>> more lenient).
>
> Yes, it seems this is the case.

I tested not using pll5 as the parent of LVDS:

--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -439,12 +439,6 @@ static void __init imx6q_clocks_init(struct device_node *cc
clk_register_clkdev(clk[gpt_ipg_per], "per", "imx-gpt.0");
clk_register_clkdev(clk[enet_ref], "enet_ref", NULL);

-   if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
-   cpu_is_imx6dl()) {
-   clk_set_parent(clk[ldb_di0_sel], clk[pll5_video_div]);
-   clk_set_parent(clk[ldb_di1_sel], clk[pll5_video_div]);
-   }
-
clk_set_parent(clk[ipu1_di0_pre_sel], clk[pll5_video_div]);
clk_set_parent(clk[ipu1_di1_pre_sel], clk[pll5_video_div]);
clk_set_parent(clk[ipu2_di0_pre_sel], clk[pll5_video_div]);


Then the HDMI detection works fine and I get images on both HDMI and LVDS.

I understand that many LVDS panels need a frequency range that can
only be obtained via PLL5 though.

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 2:49 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
>> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>>  wrote:
>>
>> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
>> > should report the current state of the hotplug detection.
>>
>> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for
>> HDMI cable connection.
>
> Good, so that means we're reporting the correct status to the DRM layer.
> Please post the kernel boot messages, one with the HDMI cable disconnected,
> and one with a HDMI sink connected.

With HDMI cable connected (no image is seen on HDMI, only on lvds cable):

imx-ipuv3 240.ipu: IPUv3H probed
imx-ipuv3 280.ipu: IPUv3H probed
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
mmcblk0: mmc1:0007 SD4GB 3.70 GiB
[drm] No driver support for vblank timestamp query.
 mmcblk0: unknown partition table
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
imx-hdmi 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
imx-hdmi 12.hdmi: hdmi_set_clk_regenerator: samplerate=48000
ratio=100  pixelclk=7425  N=6144 cts=74250
imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
imx-hdmi 12.hdmi: EVENT=plugin
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 0
imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: got edid: width[51] x height[28]
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 13850
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 13850
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode

If I disconnect/reconnect the HDMI cable (then image is seen on both
HDMI and LVDS):

root at freescale /$ imx-hdmi 12.hdmi: EVENT=plugout
imx-hdmi 12.hdmi: EVENT=plugin
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 13850
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: got edid: width[51] x height[28]
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 13850
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 13850
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode

Now booting the kernel with HDMI disconnected:

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
mmcblk0: mmc1:0007 SD4GB 3.70 GiB
[drm] No driver support for vblank timestamp query.
 mmcblk0: unknown partition table
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
imx-hdmi 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
imx-hdmi 12.hdmi: hdmi_set_clk_regenerator: samplerate=48000
ratio=100  pixelclk=7425  N=6144 cts=74250
imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
Console: switching to colour frame buffer device 128x48
imx-drm display-subsystem.11: fb0:  frame buffer device
imx-drm display-subsystem.11: registered panic notifier
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0

And after connecting the HDMI cable:

imx-hdmi 12.hdmi: EVENT=plugin
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 0
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: got edid: width[51] x height[28]
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 7880
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode
imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
imx-hdmi 12.hdmi: final pixclk = 7880
imx-hdmi 12.hdmi: imx_hdmi_setup DVI mode

Image is seen on both LVDS and HDMI monitor, but HDMI resolution is
not correct (this is a different bug though).

>
>> The HDMI undetected issue I am seeing on sabresd seems to be related
>> to the simultaneous usage of HDMI and LVDS.
>>
>> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
>> cable is correctly detected and HDMI is shown right after boot.
>
> I wonder if the problem is that HDMI and LVDS are interfering with each
> other wrt the required pixel clock, and LVDS is winning.  If we have
> HDMI enabled, many HDMI sinks will only work if we set one of their
> supported modes (with the dot clock within 1% - though some sinks are
> more lenient).

Yes, it 

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote:
> Russell,
> 
> On Fri, Jun 6, 2014 at 10:56 AM, Russell King
>  wrote:
> > The initial state at boot is assumed to be disconnected, and we hope
> > to receive an interrupt to update the status.  Let's be more explicit
> > about the current state - reading the PHY status register tells us
> > the current level of the hotplug signal, which we can report back in
> > the _detect() method.
> >
> > Signed-off-by: Russell King 
> 
> I have applied this patch against 3.15 and I still have the following
> issue on a mx6qsabresd:
> 
> If I boot the kernel with the HDMI cable connected, no HDMI image
> comes up. In order to get HDMI working I need to remove and then
> reconnect the cable.
> 
> Still haven't had a chance to debug this though.

Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
should report the current state of the hotplug detection.

Remember that this code detects off the HPD signal - if the HPD signal
has not been correctly wired up, this patch is not going to help (really
it comes down to a hardware fault, which I'm not trying to solve with
this patch.)

What I'm trying to resolve with this patch is that the state detected
on properly wired up systems corresponds with the real initial state of
the interface at initialisation time.

The problem with the current code is that we start off assuming that the
interface is disconnected, and we rely on an interrupt arriving to change
that state.  If for whatever reason that interrupt does not arrive, then,
even if the HPD signal is active, we continue believing that the interface
is not connected.

I seem to remember discussion in the past that the HPD signal is not
wired up on SabreSD.  Really, this needs to be a DT flag to indicate
that the connectivity on the platform is not correct, and we should
fallback to using RXSENSE detection and/or DDC polling (both of which
are sub-standard and incorrect to the HDMI spec.)

I'd suggest a standard HDMI interface property like:

hotplug-detect = "hpd" | "rxsense" | "ddc"

defaulting to the standard hpd method.

As I've said in the past, my problem with just going with DDC polling
for everything is that the connected HDMI sink is permitted to update
the EDID EEPROM (when it does, it is required to lower and re-raise the
HPD signal.)  If we are polling DDC, we may hit the situation where the
EDID EEPROM is mid-update and possibly end up with corrupted data (though
there's a checksum to save us from this.)

While I2C is multi-master, we're talking about consumer stuff here, and
I bet I2C arbitration on the DDC bus is not something that is tested.
I would not be surprised if the assumption is made that when HPD is
lowered, the HDMI sink has exclusive access to the EEPROM and doesn't
need to be concerned with arbitration.

RXSENSE has the problem that it doesn't detect EDID updates (there's no
requirement for a HDMI sink to make RXSENSE on a source go inactive
across an EDID update.)

So, I would much rather go by the spec, using the HPD signal on devices
where that signal is correctly wired, and only fall back to other methods
(which cause us to go against the standard) where the hardware is buggy.

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

[PATCH] drm/doc: Fix nouveau typo

[Damien Lespiau]

Signed-off-by: Damien Lespiau 
---
 Documentation/DocBook/drm.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index efef637..0854aed 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3045,7 +3045,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   noveau
+   nouveau
NV10 Overlay
"colorkey"
RANGE
-- 
1.8.3.1

[PATCH 3/3] drm/i915: Fix the confusing comment about the ioctl limits

[Damien Lespiau]

It was reported that this comment was confusing, and indeed it is.

Signed-off-by: Damien Lespiau 
---
 include/uapi/drm/i915_drm.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ff57f07..eacd063 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -171,8 +171,12 @@ typedef struct _drm_i915_sarea {
 #define I915_BOX_TEXTURE_LOAD  0x8
 #define I915_BOX_LOST_CONTEXT  0x10

-/* I915 specific ioctls
- * The device specific ioctl range is 0x40 to 0x79.
+/*
+ * i915 specific ioctls.
+ *
+ * The device specific ioctl range is [DRM_COMMAND_BASE, DRM_COMMAND_END) ie
+ * [0x40, 0xa0) (a0 is excluded) and those defines are offsets from
+ * DRM_COMMAND_BASE.
  */
 #define DRM_I915_INIT  0x00
 #define DRM_I915_FLUSH 0x01
-- 
1.8.3.1

[PATCH 2/3] drm: Driver-specific ioctls range from 0x40 to 0x9f

[Damien Lespiau]

DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.

Signed-off-by: Damien Lespiau 
---
 include/uapi/drm/drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9abbeb9..b0b8556 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -780,7 +780,7 @@ struct drm_prime_handle {

 /**
  * Device specific ioctls should only be in their respective headers
- * The device specific ioctl range is from 0x40 to 0x99.
+ * The device specific ioctl range is from 0x40 to 0x9f.
  * Generic IOCTLS restart at 0xA0.
  *
  * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and
-- 
1.8.3.1

[PATCH 1/3] drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()

[Damien Lespiau]

I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy & paste
rather than anything else.

Let's just remove it for plain ARRAY_SIZE().

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/armada/armada_drv.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 drivers/gpu/drm/gma500/psb_drv.c| 2 +-
 drivers/gpu/drm/i810/i810_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
 drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
 drivers/gpu/drm/mga/mga_state.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
 drivers/gpu/drm/r128/r128_state.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
 drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
 drivers/gpu/drm/savage/savage_bci.c | 2 +-
 drivers/gpu/drm/sis/sis_mm.c| 2 +-
 drivers/gpu/drm/via/via_dma.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 include/drm/drmP.h  | 2 --
 20 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 567cfbd..8ab3cd1 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -402,7 +402,7 @@ static struct platform_driver armada_drm_platform_driver = {

 static int __init armada_drm_init(void)
 {
-   armada_drm_driver.num_ioctls = DRM_ARRAY_SIZE(armada_ioctls);
+   armada_drm_driver.num_ioctls = ARRAY_SIZE(armada_ioctls);
return platform_driver_register(_drm_platform_driver);
 }
 module_init(armada_drm_init);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 87461d4..ddb5003 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -569,7 +569,7 @@ static int exynos_drm_platform_probe(struct platform_device 
*pdev)
int ret;

pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
+   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(_driver);
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 59ea45e..6e8fe9e 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -477,7 +477,7 @@ static struct drm_driver driver = {
.lastclose = psb_driver_lastclose,
.preclose = psb_driver_preclose,

-   .num_ioctls = DRM_ARRAY_SIZE(psb_ioctls),
+   .num_ioctls = ARRAY_SIZE(psb_ioctls),
.device_is_agp = psb_driver_device_is_agp,
.irq_preinstall = psb_irq_preinstall,
.irq_postinstall = psb_irq_postinstall,
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index aeace37..e88bac1 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1251,7 +1251,7 @@ const struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_FLIP, i810_flip_bufs, DRM_AUTH|DRM_UNLOCKED),
 };

-int i810_max_ioctl = DRM_ARRAY_SIZE(i810_ioctls);
+int i810_max_ioctl = ARRAY_SIZE(i810_ioctls);

 /**
  * Determine if the device really is AGP or not.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 93c0e1a..7c63b18 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2025,7 +2025,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };

-int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
+int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);

 /*
  * This is really ugly: Because old userspace abused the linux agp interface to
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c 
b/drivers/gpu/drm/i915/i915_ioc32.c
index 3c59584..2e0613e 100644
--- a/drivers/gpu/drm/i915/i915_ioc32.c
+++ b/drivers/gpu/drm/i915/i915_ioc32.c
@@ -208,7 +208,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
if (nr < DRM_COMMAND_BASE)
return drm_compat_ioctl(filp, cmd, arg);

-   if (nr < DRM_COMMAND_BASE + DRM_ARRAY_SIZE(i915_compat_ioctls))
+   if (nr < DRM_COMMAND_BASE + ARRAY_SIZE(i915_compat_ioctls))
fn = i915_compat_ioctls[nr - DRM_COMMAND_BASE];

if (fn != NULL)
diff --git a/drivers/gpu/drm/mga/mga_ioc32.c b/drivers/gpu/drm/mga/mga_ioc32.c
index 86b4bb8..729bfd5 100644
--- a/drivers/gpu/drm/mga/mga_ioc32.c
+++ b/drivers/gpu/drm/mga/mga_ioc32.c
@@ -214,7 +214,7 @@ long mga_compat_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
if (nr < DRM_COMMAND_BASE)
return 

[PATCH 0/3] A couple of fixes about the ioctl number split

[Damien Lespiau]

It was reported a long time ago the various comments about the DRM/driver
specific ioctl split were confusing. So tried to fix that.

Patch #1 is a bonus patch that removes DRM_ARRAY_SIZE().

-- 
Damien

Damien Lespiau (3):
  drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()
  drm: Driver-specific ioctls range from 0x40 to 0x9f
  drm/i915: Fix the confusing comment about the ioctl limits

 drivers/gpu/drm/armada/armada_drv.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 drivers/gpu/drm/gma500/psb_drv.c| 2 +-
 drivers/gpu/drm/i810/i810_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
 drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
 drivers/gpu/drm/mga/mga_state.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
 drivers/gpu/drm/r128/r128_state.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
 drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
 drivers/gpu/drm/savage/savage_bci.c | 2 +-
 drivers/gpu/drm/sis/sis_mm.c| 2 +-
 drivers/gpu/drm/via/via_dma.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 include/drm/drmP.h  | 2 --
 include/uapi/drm/drm.h  | 2 +-
 include/uapi/drm/i915_drm.h | 8 ++--
 22 files changed, 26 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH] drm: Remove spurious ';'

[Damien Lespiau]

One small step after another, the never-ending crusade towards better
code continues.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/ast/ast_post.c  | 4 ++--
 drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c   | 2 +-
 drivers/gpu/drm/nouveau/core/engine/graph/ctxnvf0.c | 2 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nv50.c| 2 +-
 drivers/gpu/drm/radeon/radeon_bios.c| 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 4e5ea38..38d437f 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -1083,7 +1083,7 @@ static void get_ddr3_info(struct ast_private *ast, struct 
ast2300_dram_param *pa
case AST_DRAM_4Gx16:
param->dram_config = 0x133;
break;
-   }; /* switch size */
+   } /* switch size */

switch (param->vram_size) {
default:
@@ -1454,7 +1454,7 @@ static void get_ddr2_info(struct ast_private *ast, struct 
ast2300_dram_param *pa
case AST_DRAM_4Gx16:
param->dram_config = 0x123;
break;
-   }; /* switch size */
+   } /* switch size */

switch (param->vram_size) {
default:
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 5e05dbc..a8ffc8c 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1087,7 +1087,7 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
break;
default:
break;
-   };
+   }
dp->dpms_mode = mode;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index f1b8587..482127f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -152,7 +152,7 @@ static void exynos_dpi_dpms(struct exynos_drm_display 
*display, int mode)
break;
default:
break;
-   };
+   }
ctx->dpms_mode = mode;
 }

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 489ffd2..87885d8 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -148,7 +148,7 @@ static int handle_dsi_error(struct mdfld_dsi_pkg_sender 
*sender, u32 mask)
break;
case BIT(14):
/*wait for all fifo empty*/
-   /*wait_for_all_fifos_empty(sender)*/;
+   /*wait_for_all_fifos_empty(sender)*/
break;
case BIT(15):
dev_dbg(sender->dev->dev, "No Action required\n");
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvf0.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvf0.c
index 0fab95e..dec03f0 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvf0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvf0.c
@@ -842,7 +842,7 @@ nvf0_grctx_generate_mods(struct nvc0_graph_priv *priv, 
struct nvc0_grctx *info)
u16 magic3 = 0x0648;
magic[gpc][0]  = 0x1000 | (magic0 << 16) | offset;
magic[gpc][1]  = 0x | (magic1 << 16);
-   offset += 0x0324 * (priv->tpc_nr[gpc] - 1);;
+   offset += 0x0324 * (priv->tpc_nr[gpc] - 1);
magic[gpc][2]  = 0x1000 | (magic2 << 16) | offset;
magic[gpc][3]  = 0x | (magic3 << 16);
offset += 0x0324;
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/nv50.c
index 2c7809e..1a2d564 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv50.c
@@ -901,7 +901,7 @@ nv50_graph_ctor(struct nouveau_object *parent, struct 
nouveau_object *engine,
nv_engine(priv)->sclass = nvaf_graph_sclass;
break;

-   };
+   }

/* unfortunate hw bug workaround... */
if (nv_device(priv)->chipset != 0x50 &&
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 9ab3097..6a03624 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -626,7 +626,7 @@ static bool radeon_acpi_vfct_bios(struct radeon_device 
*rdev)
vhdr->DeviceID != rdev->pdev->device) {
DRM_INFO("ACPI VFCT table is not for this card\n");
goto out_unmap;
-   };
+   }

if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
vhdr->ImageLength > tbl_size) {
DRM_ERROR("ACPI VFCT image truncated\n");
-- 
1.8.3.1

[PATCH] drm/doc: Add the "type" plane property to the list of properties

[Damien Lespiau]

Matt aded this plane property before we had a table giving a summary of
the properties. Add it there.

Cc: Matt Roper 
Signed-off-by: Damien Lespiau 
---
 Documentation/DocBook/drm.tmpl | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 0854aed..ba405fe 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2466,7 +2466,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
?EDID?
BLOB | IMMUTABLE
@@ -2482,6 +2482,14 @@ void intel_crt_init(struct drm_device *dev)
Contains DPMS operation mode value.


+   Plane
+   ?type?
+   ENUM | IMMUTABLE
+   { "Overlay", "Primary", "Cursor" }
+   Plane
+   Plane type
+   
+   
DVI-I
?subconnector?
ENUM
-- 
1.8.3.1

[PATCH] drm/msm/hdmi: set hdp clock rate before prepare_enable call

[Rob Clark]

On Mon, Jun 9, 2014 at 1:56 PM, Stephen Boyd  wrote:
> On 06/06/14 07:03, Stephane Viau wrote:
>> The clock driver usually complains when a clock is being prepared
>> before setting its rate. It is the case here for "core_clk" which
>> needs to be set at 19.2 MHz before we attempt a prepare_enable().
>
> That's only true in the downstream vendor kernel. Upstream we detect all
> rates when clocks are registered. Given that 19.2Mhz is the default rate
> out of reset for this clock this patch is fairly useless.
>

well, I've got this patch (with a slight tweak) queued up already..
I'm tempted to keep it, unless downstream kernel can be fixed, just to
make it easier to sync things back to downstream kernel..

BR,
-R

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>

ast2400 woes

[Benjamin Herrenschmidt]

On Mon, 2014-06-09 at 02:41 +, YC Chen wrote:
> Hi Benjamin,
> After confirm with our h/w designer, ast2400 did not support
> big-endian as you said. We support it in our previous product(PCI
> revision < 0x20) for frame buffer access. So, the possible solution is
> made in sw level for big-endian support. May we know the impact if we
> did not support it in h/w design? We will consider to support it in
> next generation.

So the open power products are migrating toward mostly little endian
environments where the problem is not present. But we still have a
strong big endian legacy which would be nice to support.

SW swapping is not a simple thing to do. A large part of the problem is
that the X server (and the software stack above it mostly) have the
native pixel format defined at compile time and is always BE on BE
machines. So swapping requires hooks in various places and reduce
performance. The two main cases are:

 - "Modern" distros such as fedora don't use the old style X DDX. They
use the KMS Linux driver and the "modesetting" DDX which is
unaccelerated and uses ShadowFB. We can add a swapping hook into there,
but it will result in an even slower setup (and it's already pretty slow
as it is). 

 - The old DDX relies on the HW swapping. X will always draw in native
format and since the old DDX draws directly into the FB, all
non-accelerated accesses would have to be wrapped and swapped. It's even
harder to do than the KMS case since it's not a single point that needs
hooking and all fb ops must be wrapped.

My recommendation here for future HW if you want to consider bringing BE
support back in is to not swap at the PCIe interface level however.
Leave that alone..

Simply provide a way to define the pixel format to be BE on the output
pipe (CRTC) and 2D engine. IE. When the pixels are *consumed* from
memory by the chip, not on the path between PCI and memory.

PCIe-level swapping doesn't work well from experience, especially when
manipulating objects of different bit depth in the same fb such as
32-bit pixmaps and 8-bit alpha masks.

> The default MMIO is enabled since the products PCI revision >= 0x20.
> The possible solution is check the value of 0x3c3 through MMIO. If the
> value is 0xFF, then you must enable it through PCI IO.

Will the value be 0xff because that's what the chip responds or will the
chip not respond which *happens* to return 0xff on some x86 chipsets ?
(ie, target abort).

Because in the latter case, this will cause errors ranging from machine
checks to EEH freeze on powerpc platforms. In fact, some x86 platforms
are also configured to not ignore PCI errors and will fail in nasty ways
with such a procedure.

Can you confirm which specific bit of which register will enable MMIO ?
What I can do is do that whenever IO space has been properly allocated
(ie, is supported by the platform) and assume that MMIO is already
enabled on platforms that don't support IO.

Also, about the 0x380 difference in offset between IO and MMIO, is that
always like that ? The documentation doesn't mention this at all...

Cheers,
Ben.

> Regards,
> 
> Y.C. Chen
> 
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org] 
> Sent: Saturday, June 07, 2014 3:16 PM
> To: Dave Airlie
> Cc: dri-devel at lists.freedesktop.org; YC Chen
> Subject: Re: ast2400 woes
> 
> On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:
> 
> > IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO
> use 
> > the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42, can
> it 
> > be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
> > 
> > On my AST2400 at least, even when MMIO is disabled, 0x3c3 still 
> > responds so it works but is that valid for all chips ? Or do I need
> to 
> > favor the PIO path if PIO is available in that case for older
> chipsets 
> > ?
> 
> Note: I have it working now with a couple of patches that i'll send
> when I've cleaned them up, though I still need answers to the earlier
> questions so we can make sure we don't break earlier chipset support
> on x86.
> 
> However, YC, the Endian control bits in extended CRTC register A2 seem
> to have no effect at all. With a big endian kernel I get the wrong
> endian on graphics regardless of the setting of that register !
> 
> Is endian swapping supported on the AST2400 ?
> 
> Also what is the exact effect of that register ? Does it affect access
> from PCI to the framebuffer or does it affect the way the CRTC
> consumes pixels from the framebuffer ? Is is supposed to have an
> effect on register accesses ?
> 
> Cheers,
> Ben.
> 
> 

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

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

--- Comment #13 from Alex Deucher  ---
(In reply to swoorupj from comment #12)
> Hi Alex,
> 
> I have reported the same issue in bugs.freedesktop. I tried out the 3.15
> linux kernel in archlinux just today. And this issue is still prevalent to
> me. 

Is it the same commit (6c7bccea390853bdec5b76fe31fc50f3b36f75d5) that caused
the regression for you as well?  If not, you are experienceing a different
issue.

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

[PATCH] drm/exynos: remove hardware overlays disable from fimd probe

[Inki Dae]

On 2014? 06? 02? 20:48, Andrzej Hajda wrote:
> On 06/02/2014 12:42 PM, Andrzej Hajda wrote:
>> On 06/02/2014 12:11 PM, Tomasz Figa wrote:
>>> Hi Rahul, Andrzej,
>>>
>>> On 02.06.2014 11:42, Rahul Sharma wrote:
 On 2 June 2014 14:41, Andrzej Hajda  wrote:
> Hi Rahul,
>
> On 05/28/2014 08:11 AM, Rahul Sharma wrote:
>> System hangs when FIMD registers are accessed to disable
>> hardware overlays. This is because of the clocks which are
>> not enabled before register access.
>>
>> 'Hardware overlay disable' is cleaned from the FIMD probe.
>>
>> Signed-off-by: Rahul Sharma 
>
> This patch causes regression on some exynos4210-universal_c210 devices,
> everything works expect colors are incorrect - it seems blue component
> is very dark, almost black.
>

 Oh Sorry for that. I did not see any problem on 5250/5420/5800. I do 
 not
 have setup for 4210. Better we should revert this patch.

 Would you please help me by verifying the following patch on 4210? This
 is an alternate solution to the same problem.

 http://www.mail-archive.com/linux-samsung-soc at 
 vger.kernel.org/msg31426.html

 Thanks Andrej, for bringing it to notice.
>>>
>>> I don't see how this patch could introduce such regression, as all the
>>> affected registers seem to be properly reconfigured in fimd_win_commit()
>>> anyway.
>>>
>>> IMHO instead of reverting the patch, this issue should be investigated
>>> and fixed properly.
>>>
>>> Best regards,
>>> Tomasz
>>>
>>
>> I am looking at the problem, it is quite strange as it happens only on
>> one of two targets I have access to. Anyway it seems that something
>> should be added to fimd initialization sequence if we want to remove hw
>> accessing code from probe.
> 
> The problem is that fimd does not clear unused windows.
> Simple patch which helps:
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 2ec634f..b58fce2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -741,6 +741,8 @@ static void fimd_apply(struct exynos_drm_manager *mgr)
> win_data = >win_data[i];
> if (win_data->enabled)
> fimd_win_commit(mgr, i);
> +   else
> +   fimd_win_disable(mgr, i);
> }
> 
> fimd_commit(mgr);
> 
> But I am not fully familiar with window management code, so I do not
> know if it does not breaks other stuff.

It looks good to me. Can you post it?

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>
>> Regards
>> Andrzej
>>
> 
> 

[GIT PULL] drm/panel: Changes for v3.16-rc1

[Thierry Reding]

[Resending with the list on Cc]

Hi Dave,

The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:

  Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-3.16-rc1

for you to fetch changes up to a333f7ad1db5e77eea411b058d95a5d3587ab141:

  drm/panel: simple - Add AUO B133XTN01 panel support (2014-06-09 12:17:21 
+0200)

Thanks,
Thierry


drm/panel: Changes for v3.16-rc1

This set of commits contains a couple of fixes to existing panel drivers
and support for some new panels.

One commit touches the DRM core in that in modifies the MIPI DSI support
to hook up the shutdown function so that drivers can provide code that's
run on shutdown. This is used by a subsequent commit to make the simple
panel driver power off the backlight on shutdown.


Andrzej Hajda (1):
  drm/panel: ld9040: add power control sequence

Dan Carpenter (1):
  drm/panel: s6e8aa0: silence array overflow warning

Philipp Zabel (1):
  drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

Stefan Agner (1):
  drm/panel: add support for EDT ET057090DHU panel

St?phane Marchesin (1):
  drm/panel: simple - Add AUO B133XTN01 panel support

Thierry Reding (2):
  drm/dsi: Support device shutdown
  drm/panel: simple - Disable panel on shutdown

 Documentation/devicetree/bindings/panel/auo,b133xtn01.txt|  7 +++
 Documentation/devicetree/bindings/panel/edt,et057090dhu.txt  |  7 +++
 Documentation/devicetree/bindings/panel/edt,et070080dh6.txt  | 10 ++
 Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt | 10 ++
 drivers/gpu/drm/drm_mipi_dsi.c   | 10 ++
 drivers/gpu/drm/panel/panel-ld9040.c |  3 +++
 drivers/gpu/drm/panel/panel-s6e8aa0.c|  1 +
 drivers/gpu/drm/panel/panel-simple.c | 99 
+++
 include/drm/drm_mipi_dsi.h   |  2 ++
 9 files changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b133xtn01.txt
 create mode 100644 Documentation/devicetree/bindings/panel/edt,et057090dhu.txt
 create mode 100644 Documentation/devicetree/bindings/panel/edt,et070080dh6.txt
 create mode 100644 Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/c1ce3ac5/attachment.sig>

[GIT PULL] drm/tegra: Changes for v3.16-rc1

[Thierry Reding]

  |  33 
+++--
 drivers/gpu/drm/tegra/dpaux.c   |  31 

 drivers/gpu/drm/tegra/drm.c |  36 
--
 drivers/gpu/drm/tegra/drm.h |  58 
++
 drivers/gpu/drm/tegra/dsi.c | 250 
+---
 drivers/gpu/drm/tegra/dsi.h |  10 
 drivers/gpu/drm/tegra/gem.c |   3 +-
 drivers/gpu/drm/tegra/gr2d.c|   8 +--
 drivers/gpu/drm/tegra/gr3d.c|   8 +--
 drivers/gpu/drm/tegra/hdmi.c| 202 
+++---
 drivers/gpu/drm/tegra/hdmi.h|   5 ++
 drivers/gpu/drm/tegra/rgb.c |  31 
+++-
 drivers/gpu/drm/tegra/sor.c | 478 
---
 drivers/gpu/drm/tegra/sor.h |   4 ++
 drivers/gpu/host1x/bus.c|  12 ++---
 include/drm/drmP.h  |   2 +
 26 files changed, 1446 insertions(+), 688 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/bus.c
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140609/15e39dff/attachment-0001.sig>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 11:33 AM, Shawn Guo  wrote:
> On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
>> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>>  wrote:
>>
>> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
>> > should report the current state of the hotplug detection.
>>
>> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for
>> HDMI cable connection.
>>
>> > Remember that this code detects off the HPD signal - if the HPD signal
>> > has not been correctly wired up, this patch is not going to help (really
>> > it comes down to a hardware fault, which I'm not trying to solve with
>> > this patch.)
>> >
>> > What I'm trying to resolve with this patch is that the state detected
>> > on properly wired up systems corresponds with the real initial state of
>> > the interface at initialisation time.
>> >
>> > The problem with the current code is that we start off assuming that the
>> > interface is disconnected, and we rely on an interrupt arriving to change
>> > that state.  If for whatever reason that interrupt does not arrive, then,
>> > even if the HPD signal is active, we continue believing that the interface
>> > is not connected.
>> >
>> > I seem to remember discussion in the past that the HPD signal is not
>> > wired up on SabreSD.  Really, this needs to be a DT flag to indicate
>>
>> It is sabrelite board that does not have HPD signal not wired up.
>>
>> sabresd does have HPD signal connected.
>>
>> The HDMI undetected issue I am seeing on sabresd seems to be related
>> to the simultaneous usage of HDMI and LVDS.
>>
>> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
>> cable is correctly detected and HDMI is shown right after boot.
>
> This is a known limitation.
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/315968/focus=318559

There were versions of linux-next that hdmi and lvds works at the same
time without problems.

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
 wrote:

> Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
> should report the current state of the hotplug detection.

/sys/class/drm/card0-HDMI-A-1/status returns the correct state for
HDMI cable connection.

> Remember that this code detects off the HPD signal - if the HPD signal
> has not been correctly wired up, this patch is not going to help (really
> it comes down to a hardware fault, which I'm not trying to solve with
> this patch.)
>
> What I'm trying to resolve with this patch is that the state detected
> on properly wired up systems corresponds with the real initial state of
> the interface at initialisation time.
>
> The problem with the current code is that we start off assuming that the
> interface is disconnected, and we rely on an interrupt arriving to change
> that state.  If for whatever reason that interrupt does not arrive, then,
> even if the HPD signal is active, we continue believing that the interface
> is not connected.
>
> I seem to remember discussion in the past that the HPD signal is not
> wired up on SabreSD.  Really, this needs to be a DT flag to indicate

It is sabrelite board that does not have HPD signal not wired up.

sabresd does have HPD signal connected.

The HDMI undetected issue I am seeing on sabresd seems to be related
to the simultaneous usage of HDMI and LVDS.

If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
cable is correctly detected and HDMI is shown right after boot.

[PATCH] drm/msm/hdmi: set hdp clock rate before prepare_enable call

[Stephen Boyd]

On 06/06/14 07:03, Stephane Viau wrote:
> The clock driver usually complains when a clock is being prepared
> before setting its rate. It is the case here for "core_clk" which
> needs to be set at 19.2 MHz before we attempt a prepare_enable().

That's only true in the downstream vendor kernel. Upstream we detect all
rates when clocks are registered. Given that 19.2Mhz is the default rate
out of reset for this clock this patch is fairly useless.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

Russell,

On Fri, Jun 6, 2014 at 10:56 AM, Russell King
 wrote:
> The initial state at boot is assumed to be disconnected, and we hope
> to receive an interrupt to update the status.  Let's be more explicit
> about the current state - reading the PHY status register tells us
> the current level of the hotplug signal, which we can report back in
> the _detect() method.
>
> Signed-off-by: Russell King 

I have applied this patch against 3.15 and I still have the following
issue on a mx6qsabresd:

If I boot the kernel with the HDMI cable connected, no HDMI image
comes up. In order to get HDMI working I need to remove and then
reconnect the cable.

Still haven't had a chance to debug this though.

[PATCH] drm/doc: Fix nouveau typo

[Alex Deucher]

On Mon, Jun 9, 2014 at 9:40 AM, Damien Lespiau  
wrote:
> Signed-off-by: Damien Lespiau 

Reviewed-by: Alex Deucher 

> ---
>  Documentation/DocBook/drm.tmpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index efef637..0854aed 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3045,7 +3045,7 @@ void intel_crt_init(struct drm_device *dev)
> TBD
> 
> 
> -   noveau
> +   nouveau
> NV10 Overlay
> "colorkey"
> RANGE
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm: Driver-specific ioctls range from 0x40 to 0x9f

[Alex Deucher]

On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau  
wrote:
> DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.
>
> Signed-off-by: Damien Lespiau 

Reviewed-by: Alex Deucher 

> ---
>  include/uapi/drm/drm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 9abbeb9..b0b8556 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -780,7 +780,7 @@ struct drm_prime_handle {
>
>  /**
>   * Device specific ioctls should only be in their respective headers
> - * The device specific ioctl range is from 0x40 to 0x99.
> + * The device specific ioctl range is from 0x40 to 0x9f.
>   * Generic IOCTLS restart at 0xA0.
>   *
>   * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #13 from Kertesz Laszlo  ---
I DO have set radeon.dpm=1 in the kernel command line.
Its there since this option was introduced (didnt remove it when it became
default).

-- 
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/20140609/a3133c0a/attachment.html>

[PATCH 1/3] drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()

[Alex Deucher]

On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau  
wrote:
> I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
> in a few places. I suspect its usage has been spread by copy & paste
> rather than anything else.
>
> Let's just remove it for plain ARRAY_SIZE().
>
> Signed-off-by: Damien Lespiau 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/armada/armada_drv.c | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
>  drivers/gpu/drm/gma500/psb_drv.c| 2 +-
>  drivers/gpu/drm/i810/i810_dma.c | 2 +-
>  drivers/gpu/drm/i915/i915_dma.c | 2 +-
>  drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
>  drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
>  drivers/gpu/drm/mga/mga_state.c | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
>  drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
>  drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
>  drivers/gpu/drm/r128/r128_state.c   | 2 +-
>  drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
>  drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
>  drivers/gpu/drm/savage/savage_bci.c | 2 +-
>  drivers/gpu/drm/sis/sis_mm.c| 2 +-
>  drivers/gpu/drm/via/via_dma.c   | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
>  include/drm/drmP.h  | 2 --
>  20 files changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 567cfbd..8ab3cd1 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -402,7 +402,7 @@ static struct platform_driver armada_drm_platform_driver 
> = {
>
>  static int __init armada_drm_init(void)
>  {
> -   armada_drm_driver.num_ioctls = DRM_ARRAY_SIZE(armada_ioctls);
> +   armada_drm_driver.num_ioctls = ARRAY_SIZE(armada_ioctls);
> return platform_driver_register(_drm_platform_driver);
>  }
>  module_init(armada_drm_init);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 87461d4..ddb5003 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -569,7 +569,7 @@ static int exynos_drm_platform_probe(struct 
> platform_device *pdev)
> int ret;
>
> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
> +   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>
>  #ifdef CONFIG_DRM_EXYNOS_FIMD
> ret = platform_driver_register(_driver);
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 59ea45e..6e8fe9e 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -477,7 +477,7 @@ static struct drm_driver driver = {
> .lastclose = psb_driver_lastclose,
> .preclose = psb_driver_preclose,
>
> -   .num_ioctls = DRM_ARRAY_SIZE(psb_ioctls),
> +   .num_ioctls = ARRAY_SIZE(psb_ioctls),
> .device_is_agp = psb_driver_device_is_agp,
> .irq_preinstall = psb_irq_preinstall,
> .irq_postinstall = psb_irq_postinstall,
> diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
> index aeace37..e88bac1 100644
> --- a/drivers/gpu/drm/i810/i810_dma.c
> +++ b/drivers/gpu/drm/i810/i810_dma.c
> @@ -1251,7 +1251,7 @@ const struct drm_ioctl_desc i810_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I810_FLIP, i810_flip_bufs, DRM_AUTH|DRM_UNLOCKED),
>  };
>
> -int i810_max_ioctl = DRM_ARRAY_SIZE(i810_ioctls);
> +int i810_max_ioctl = ARRAY_SIZE(i810_ioctls);
>
>  /**
>   * Determine if the device really is AGP or not.
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 93c0e1a..7c63b18 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -2025,7 +2025,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>  };
>
> -int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> +int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
>
>  /*
>   * This is really ugly: Because old userspace abused the linux agp interface 
> to
> diff --git a/drivers/gpu/drm/i915/i915_ioc32.c 
> b/drivers/gpu/drm/i915/i915_ioc32.c
> index 3c59584..2e0613e 100644
> --- a/drivers/gpu/drm/i915/i915_ioc32.c
> +++ b/drivers/gpu/drm/i915/i915_ioc32.c
> @@ -208,7 +208,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
> if (nr < DRM_COMMAND_BASE)
> return drm_compat_ioctl(filp, cmd, arg);
>
> -   if (nr < DRM_COMMAND_BASE + DRM_ARRAY_SIZE(i915_compat_ioctls))
> +   if (nr < DRM_COMMAND_BASE + ARRAY_SIZE(i915_compat_ioctls))
> fn = i915_compat_ioctls[nr - DRM_COMMAND_BASE];
>
> if (fn != NULL)
> diff --git a/drivers/gpu/drm/mga/mga_ioc32.c 

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #12 from Arno Schuring  ---
I have upgraded my bios from 25.1 to 25.3, issue remains. I will browse the
BIOS for overclocking settings, but I didn't change any; so if they do effect
this, then it's the factory-defaults causing this.

This is a wild guess, but the symptoms to me look like a spurious watchdog
kicking in, given that the system appears fully functional right up until the
reboot, no errors are logged and there is a delay between the modprobe and the
reboot.

@Kertesz: according to Alex in comment #1, "forcing dpm=1 will enable extra
debugging output". Possibly that's why you're not seeing those lines.

-- 
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/20140609/7cceb3f6/attachment.html>

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

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

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

--- Comment #7 from Michel D?nzer  ---
(In reply to comment #6)
> Just to be clear, there's still a bug in Xorg segfaulting, right? Should it
> be able to survive GPU hangs?

If you can get a gdb backtrace with debugging symbols for
/usr/lib/xorg/modules/dri/radeonsi_dri.so and /usr/lib/libglamor.so.0, we can
see what we can do. But realistically, it's not always possible to recover
gracefully from GPU hangs.

-- 
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/20140609/dc0109d4/attachment.html>

[PATCH] drm/doc: Add the "type" plane property to the list of properties

[Matt Roper]

On Mon, Jun 09, 2014 at 02:20:22PM +0100, Damien Lespiau wrote:
> Matt aded this plane property before we had a table giving a summary of
> the properties. Add it there.
> 
> Cc: Matt Roper 
> Signed-off-by: Damien Lespiau 

Reviewed-by: Matt Roper 

> ---
>  Documentation/DocBook/drm.tmpl | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 0854aed..ba405fe 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2466,7 +2466,7 @@ void intel_crt_init(struct drm_device *dev)
>   Description/Restrictions
>   
>   
> - DRM
> + DRM
>   Generic
>   ?EDID?
>   BLOB | IMMUTABLE
> @@ -2482,6 +2482,14 @@ void intel_crt_init(struct drm_device *dev)
>   Contains DPMS operation mode value.
>   
>   
> + Plane
> + ?type?
> + ENUM | IMMUTABLE
> + { "Overlay", "Primary", "Cursor" }
> + Plane
> + Plane type
> + 
> + 
>   DVI-I
>   ?subconnector?
>   ENUM
> -- 
> 1.8.3.1
> 

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

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

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

--- Comment #5 from Michel D?nzer  ---
I can't reproduce this with glamor from xserver Git, can you try that?

If not, or if it still happens with that, please get a backtrace with gdb, and
make sure /usr/lib/xorg/modules/dri/radeonsi_dri.so and
/usr/lib/xorg/modules/extensions/libglx.so have debugging symbols.

-- 
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/20140609/3ea4ce8e/attachment.html>

[Bug 79551] DRI_PRIME not working

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

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

--- Comment #7 from Michel D?nzer  ---
(In reply to comment #6)
> if in /etc/environment set DRI_PRIME=1 and in /etc/xprofile set xcompmgr -c &
> some apps will display with artifacts (part of window freezes when scrolling)

Apps using PRIME, or others?

BTW, just xcompmgr -a should be enough, no need for -c.

-- 
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/20140609/26635a42/attachment.html>

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

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

swoorupj at gmail.com changed:

   What|Removed |Added

 CC||swoorupj at gmail.com

--- Comment #12 from swoorupj at gmail.com ---
Hi Alex,

I have reported the same issue in bugs.freedesktop. I tried out the 3.15 linux
kernel in archlinux just today. And this issue is still prevalent to me. 

Resuming from suspend still results a blank screen using the radeon module in
the kernel.

dmesg logs: http://ix.io/cSi

I have a AMD A6-4400M APU that integrates  Radeon HD 7520G.

Kind Regards,
Swoorup Joshi

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

[Bug 77521] radeon: Horizontal lines of semi-random contents are sometimes displayed

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

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

--- Comment #1 from Michel D?nzer  ---
Created attachment 138561
  --> https://bugzilla.kernel.org/attachment.cgi?id=138561=edit
Move fb update from radeon_flip_work_func() to radeon_crtc_page_flip()

This (untested) patch should fix at least the warnings in dmesg, not sure about
the visual artifacts though.

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

[Bug 79806] Performance degradation after resume

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

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

--- Comment #1 from Gabor Enyedi  ---
/sys/kernel/debug/dri/64/radeon_pm_info also shows, that the card always stays
in the lowest performance level.

-- 
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/20140609/952b267a/attachment.html>

[Bug 77531] radeonsi: kaveri: mouse cursor corruption on wayland/weston session

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

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

Alvaro Fernando Garc?a  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Alvaro Fernando Garc?a  
---
I've uploaded a patch to weston bugtracker, so I think the bug can be closed
here as invalid.

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

ast2400 woes

[YC Chen]

Hi Benjamin,
After confirm with our h/w designer, ast2400 did not support big-endian as you 
said. We support it in our previous product(PCI revision < 0x20) for frame 
buffer access. So, the possible solution is made in sw level for big-endian 
support. May we know the impact if we did not support it in h/w design? We will 
consider to support it in next generation.
The default MMIO is enabled since the products PCI revision >= 0x20. The 
possible solution is check the value of 0x3c3 through MMIO. If the value is 
0xFF, then you must enable it through PCI IO.

Regards,

Y.C. Chen

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
Sent: Saturday, June 07, 2014 3:16 PM
To: Dave Airlie
Cc: dri-devel at lists.freedesktop.org; YC Chen
Subject: Re: ast2400 woes

On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:

> IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO use 
> the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42, can it 
> be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
> 
> On my AST2400 at least, even when MMIO is disabled, 0x3c3 still 
> responds so it works but is that valid for all chips ? Or do I need to 
> favor the PIO path if PIO is available in that case for older chipsets 
> ?

Note: I have it working now with a couple of patches that i'll send when I've 
cleaned them up, though I still need answers to the earlier questions so we can 
make sure we don't break earlier chipset support on x86.

However, YC, the Endian control bits in extended CRTC register A2 seem to have 
no effect at all. With a big endian kernel I get the wrong endian on graphics 
regardless of the setting of that register !

Is endian swapping supported on the AST2400 ?

Also what is the exact effect of that register ? Does it affect access from PCI 
to the framebuffer or does it affect the way the CRTC consumes pixels from the 
framebuffer ? Is is supposed to have an effect on register accesses ?

Cheers,
Ben.

[Bug 77531] radeonsi: kaveri: mouse cursor corruption on wayland/weston session

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

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

--- Comment #6 from Alvaro Fernando Garc?a  
---
I've repoerted the bug to weston bugzilla.

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

Thanks for answering!

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

[Bug 77531] radeonsi: kaveri: mouse cursor corruption on wayland/weston session

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #5 from Alex Deucher  ---
This isn't a driver bug.  It's a weston bug.  Weston assumes all hardware
cursors are 64x64 pixels, but newer radeon hardware only supports 128x128 pixel
cursors. Weston should be updated to query the kernel kms driver and see what
size cursors it supports.  See this patch I wrote for xf86-video-modesetting:
http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/commit/?id=677935b2d20f54f21c645b5eb386b6c9485fee5f

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

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

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

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

--- Comment #4 from Alex Deucher  ---
The driver only knows two states: on and off.  All of the other intermediate
dpms states other than on map to off in the driver.  Note that vbetool goes
behind the drivers back and messes with the hardware so it's likely to cause
problems.

-- 
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/20140609/4f044f54/attachment.html>

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #11 from mmstickman at gmail.com ---
If I recall correctly, I used AMD Radeon RAM when I built the system. I can't
say whether or not the bug still occurs on the machine I posted this bug with
because I built it as an office PC for someone else. Being a production
machine, I didn't have any kind of boosters or overclocking features enabled. I
think it's more than likely something to do with MSI's implementation of FM2/+

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