[no subject]

[Yonatan Maman]

From: Yonatan Maman 

Date: Mon, 7 Oct 2024 14:48:26 +0300
Subject: [PATCH v2 0/2] drm/nouveau/dmem: Fix Memory Leaking and Device 
Channels configuration

This patch series addresses two critical issues in the Nouveau driver
related to device channels, error handling, and memory leaks.

- Memory Leak in migrate_to_ram: The migrate_to_ram function was
  identified as leaking memory when a copy push command fails. This
  results in the function returning a dirty HIGH_USER page, which can
  expose sensitive information and pose a security risk. To mitigate
  this vulnerability, the patch ensures that a zero page is allocated for
  the destination page, thereby preventing memory leaks and enhancing
  driver security in case of failure.

- Privileged Error in Copy Engine Channel: An error was observed when
  the nouveau_dmem_copy_one function is executed, leading to a Host Copy
  Engine Privileged error on channel 1. The patch resolves this by
  adjusting the Copy Engine channel configuration to permit privileged
  push commands, resolving the error.

Changes since V1:
- Fixed version according to Danilo Krummrich's comments.

Yonatan Maman (2):
  nouveau/dmem: Fix privileged error in copy engine channel
  nouveau/dmem: Fix memory leak in `migrate_to_ram` upon copy error

 drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.34.1

[no subject]

[Simon Horman]

Bcc: 
Subject: Re: [PATCH v9 3/8] x86/vmware: Introduce VMware hypercall API
Reply-To: 
In-Reply-To: <683225e0-1cd3-4dea-bb68-086d46b23...@broadcom.com>

+ Joe Perches

On Wed, May 22, 2024 at 04:39:57PM -0700, Alexey Makhalov wrote:
> Hi Simon, apologize for long delay
> 
> On 5/11/24 8:02 AM, Simon Horman wrote:
> > > diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
> > 
> > ...
> > 
> > > +static inline
> > > +unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
> > > + uint32_t *out1, uint32_t *out2)
> > 
> > nit: u32 is preferred over uint32_t.
> >   Likewise elsewhere in this patch-set.
> Good to know. Can you please shed a light on the reason?
> I still see bunch of stdint style uint32_t in arch/x86.

Perhaps there is a document on this that I should know about.
But AFAIK, u32 and so on are Linux kernel types,
while uint32_t are C99-standard types.

Joe, are you able to shed any further light on this?

...

[no subject]

[Rob Clark]

Hi Dave,

A few fixes for v6.8, description below

The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:

  drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2024-02-07

for you to fetch changes up to 8d35217149daa33358c284aca6a56d5ab92cfc6c:

  drm/msm/mdss: specify cfg bandwidth for SDM670 (2024-01-25 14:36:04 -0800)


Fixes for v6.8-rc4

DPU:
- fix for kernel doc warnings and smatch warnings in dpu_encoder
- fix for smatch warning in dpu_encoder
- fix the bus bandwidth value for SDM670

DP:
- fixes to handle unknown bpc case correctly for DP. The current code was
  spilling over into other bits of DP configuration register, had to be
  fixed to avoid the extra shifts which were causing the spill over
- fix for MISC0 programming in DP driver to program the correct
  colorimetry value

GPU:
- dmabuf vmap fix
- a610 UBWC corruption fix (incorrect hbb)
- revert a commit that was making GPU recovery unreliable


Abhinav Kumar (1):
  drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup

Dmitry Baryshkov (1):
  drm/msm/mdss: specify cfg bandwidth for SDM670

Kuogee Hsieh (2):
  drm/msms/dp: fixed link clock divider bits be over written in
BPC unknown case
  drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case

Randy Dunlap (1):
  drm/msm/dpu: fix kernel-doc warnings

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  8 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  |  3 ++-
 drivers/gpu/drm/msm/dp/dp_ctrl.c|  5 -
 drivers/gpu/drm/msm/dp/dp_link.c| 22 ++
 drivers/gpu/drm/msm/dp/dp_reg.h |  3 +++
 drivers/gpu/drm/msm/msm_mdss.c  |  1 +
 6 files changed, 22 insertions(+), 20 deletions(-)

[no subject]

[Marek Szyprowski]

Subject: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE

Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH")
disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch.
This innocent change has a significant side-effect on the ARM's
multi_v7_defconfig, because FB_BACKLIGHT symbol is no longer selected,
what in turn leaves BACKLIGHT_CLASS_DEVICE symbol selected only as
a module. The latter disables some backlight related code in the DRM
core, because the DRM core is set to be compiled-in in this defconfig.
This leaves all DRM display panels without integrated backlight control,
even if the needed modules have been properly loaded and probed.

Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 8f7445729cd0..b2955dcb5a53 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -777,6 +777,7 @@ CONFIG_FB_EFI=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SIMPLE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
 CONFIG_BACKLIGHT_GPIO=y
-- 
2.34.1

[no subject]

[Andrew Worsley]

   This patch fix's the failure of the frame buffer driver on my Asahi kernel
which prevented X11 from starting on my Apple M1 laptop. It seems like a 
straight
forward failure to follow the procedure described in drivers/video/aperture.c
to remove the ealier driver. This patch is very simple and minimal. Very likely
there may be better ways to fix this and very like there may be other drivers
which have the same problem but I submit this so at least there is
an interim fix for my problem.

Thanks

Andrew Worsley

[no subject]

[Brandon Pollack]

Any progress on this?  Is it ok if yi...@chromium.org and I do the
followups on this patch so that we can also submit the Hotplug patch I
wrote (that's now archived?).

[no subject]

[Danila Chernetsov]

Date: Sat, 11 Mar 2023 19:00:03 +
Subject: [PATCH 5.10 1/1] drm/amdgpu: add error handling for 
drm_fb_helper_initial_config

The type of return value of drm_fb_helper_initial_config is int, which may 
return wrong result, so we add error handling for it to reclaim memory resource,
and return when an error occurs.   

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: d38ceaf99ed0 (drm/amdgpu: add core driver (v4))
Signed-off-by: Danila Chernetsov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 43f29ee0e3b0..e445a2c9f569 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -348,8 +348,17 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
if (!amdgpu_device_has_dc_support(adev))
drm_helper_disable_unused_functions(adev_to_drm(adev));
 
-   drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);
-   return 0;
+   ret = drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);
+   if (ret)
+   goto fini;
+
+   return 0;
+
+fini:
+   drm_fb_helper_fini(&rfbdev->helper);
+
+   kfree(rfbdev);
+   return ret;
 }
 
 void amdgpu_fbdev_fini(struct amdgpu_device *adev)
-- 
2.25.1

[no subject]

[Denis Arefev]

Date: Thu, 10 Nov 2022 16:47:26 +0300
Subject: [PATCH] drm/amdgpu/display: Add pointer check

Return value of a function 'dc_create_state' is
dereferenced at amdgpu_dm.c:2027 without checking for null

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Denis Arefev 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0f7749e9424d..529483997154 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1960,7 +1960,9 @@ static int dm_resume(void *handle)
dc_release_state(dm_state->context);
dm_state->context = dc_create_state(dm->dc);
/* TODO: Remove dc_state->dccg, use dc->dccg directly. */
-   dc_resource_state_construct(dm->dc, dm_state->context);
+   if (dm_state->context) {
+   dc_resource_state_construct(dm->dc, dm_state->context);
+   }
 
/* Before powering on DC we need to re-initialize DMUB. */
r = dm_dmub_hw_init(adev);
-- 
2.25.1

[no subject]

[Denis Arefev]

Date: Tue, 22 Nov 2022 15:51:44 +0300
Subject: [PATCH] powerplay: hwmgr: added result check

The return value of the 'div64_s64'
function called in ppevvmath.h:371
was not checked.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Denis Arefev 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
index dac29fe6cfc6..82aa7130d143 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppevvmath.h
@@ -357,6 +357,7 @@ static fInt fDivide (fInt X, fInt Y)
 {
fInt fZERO, fQuotient;
int64_t longlongX, longlongY;
+   int64_t result;
 
fZERO = ConvertToFraction(0);
 
@@ -367,10 +368,11 @@ static fInt fDivide (fInt X, fInt Y)
longlongY = (int64_t)Y.full;
 
longlongX = longlongX << 16; /*Q(16,16) -> Q(32,32) */
+   longlongY = longlongY << 16;
 
-   div64_s64(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = 
Q(16,16) Back to original format */
+   result = div64_s64(longlongX, longlongY);
 
-   fQuotient.full = (int)longlongX;
+   fQuotient = ConvertToFraction((int)result);
return fQuotient;
 }
 
-- 
2.25.1

[no subject]

[Christian König]

Just sending that out once more to intel-gfx to let the CI systems take
a look.

No functional change compared to the last version.

Christian.

[no subject]

[Christian König]

Just sending that to intel-gfx to let the CI systems take a look at it.

Regards,
Christian.

[no subject]

[Dave Airlie]

Hey Linus,

pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about
what I'd expect for rc6.

Regards,
Dave.

drm-fixes-2022-05-06:
drm fixes for 5.18-rc6

fbdev:
- hotunplugging fix

amdgpu:
- Fix a xen dom0 regression on APUs
- Fix a potential array overflow if a receiver were to
  send an erroneous audio channel count

msm:
- lockdep fix.

it6505:
- kconfig fix
The following changes since commit 672c0c5173427e6b3e2a9bbb7be51ceeec78093a:

  Linux 5.18-rc5 (2022-05-01 13:57:58 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-06

for you to fetch changes up to 5727375215b0915f28806c337a7ba9835efd340b:

  Merge tag 'drm-msm-fixes-2022-04-30' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes (2022-05-06
11:22:03 +1000)


drm fixes for 5.18-rc6

fbdev:
- hotunplugging fix

amdgpu:
- Fix a xen dom0 regression on APUs
- Fix a potential array overflow if a receiver were to
  send an erroneous audio channel count

msm:
- lockdep fix.

it6505:
- kconfig fix


Dave Airlie (3):
  Merge tag 'amd-drm-fixes-5.18-2022-05-04' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2022-05-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-msm-fixes-2022-04-30' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes

Fabien Parent (1):
  drm/bridge: ite-it6505: add missing Kconfig option select

Harry Wentland (1):
  drm/amd/display: Avoid reading audio pattern past AUDIO_CHANNELS_COUNT

Javier Martinez Canillas (1):
  fbdev: Make fb_release() return -ENODEV if fbdev was unregistered

Kuogee Hsieh (1):
  drm/msm/dp: remove fail safe mode related code

Marek Marczykowski-Górecki (1):
  drm/amdgpu: do not use passthrough mode in Xen dom0

 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  4 +++-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |  2 +-
 drivers/gpu/drm/bridge/Kconfig   |  1 +
 drivers/gpu/drm/msm/dp/dp_display.c  |  6 --
 drivers/gpu/drm/msm/dp/dp_panel.c| 11 ---
 drivers/gpu/drm/msm/dp/dp_panel.h|  1 -
 drivers/video/fbdev/core/fbmem.c |  5 -
 7 files changed, 9 insertions(+), 21 deletions(-)

[no subject]

[Christian König]

Hi Daniel,

rebased on top of all the changes in drm-misc-next now and hopefully
ready for 5.19.

I think I addressed all concern, but there was a bunch of rebase fallout
from i915, so better to double check that once more.

Regards,
Christian.

[no subject]

[shashank singh]

Hello everyone, my name is Shashank Singh. I hope this is the right
platform to reach out to the 'X.org' community. I was curious about the
X.org Endless Vacation of Code. Is this program still active?

[no subject]

[Dmitry Baryshkov]

>From Dmitry Baryshkov  # This line is ignored.
From: Dmitry Baryshkov 
Reply-To: 
Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code
In-Reply-To: 

There is no need to request most of hardware blocks through the resource
manager (RM), since typically there is 1:1 or N:1 relationship between
corresponding blocks. Each LM is tied to the single PP. Each MERGE_3D
can be used by the specified pair of PPs.  Each DSPP is also tied to
single LM. So instead of allocating them through the RM, get them via
static configuration.

Depends on: 
https://lore.kernel.org/linux-arm-msm/20210515190909.1809050-1-dmitry.barysh...@linaro.org

Changes since v1:
 - Split into separate patch series to ease review.


Dmitry Baryshkov (6):
  drm/msm/dpu: get DSPP blocks directly rather than through RM
  drm/msm/dpu: get MERGE_3D blocks directly rather than through RM
  drm/msm/dpu: get PINGPONG blocks directly rather than through RM
  drm/msm/dpu: get INTF blocks directly rather than through RM
  drm/msm/dpu: drop unused lm_max_width from RM
  drm/msm/dpu: simplify peer LM handling

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  54 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   5 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   8 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h  |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  53 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 310 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |  18 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h  |   9 +-
 16 files changed, 115 insertions(+), 401 deletions(-)

[no subject]

[Dave Airlie]

Hi Linus,

Regular fixes for final, there is a ttm regression fix, dp-mst fix,
one amdgpu revert, two i915 fixes, and some misc fixes for sun4i,
xlnx, and vc4.

All pretty quiet and don't think we have any known outstanding regressions.

Dave.

drm-fixes-2021-02-12:
drm fixes for 5.11-rc8

ttm:
- page pool regression fix.

dp_mst:
- Don't report un-attached ports as connected

amdgpu:
- Blank screen fix

i915:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking

sun4i:
- tcon1 sync polarity fix
- Always set HDMI clock rate
- Fix H6 HDMI PHY config
- Fix H6 max frequency

vc4:
- Fix buffer overflow

xlnx:
- Fix memory leak
The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:

  Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12

for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab:

  Merge branch 'drm-misc-fixes' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12
13:38:51 +1000)


drm fixes for 5.11-rc8

ttm:
- page pool regression fix.

dp_mst:
- Don't report un-attached ports as connected

amdgpu:
- Blank screen fix

i915:
- Ensure Type-C FIA is powered when initializing
- Fix overlay frontbuffer tracking

sun4i:
- tcon1 sync polarity fix
- Always set HDMI clock rate
- Fix H6 HDMI PHY config
- Fix H6 max frequency

vc4:
- Fix buffer overflow

xlnx:
- Fix memory leak


Alex Deucher (1):
  Revert "drm/amd/display: Update NV1x SR latency values"

Christian König (1):
  drm/ttm: make sure pool pages are cleared

Dave Airlie (3):
  Merge tag 'amd-drm-fixes-5.11-2021-02-10' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2021-02-11' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-misc-fixes' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Imre Deak (2):
  drm/dp_mst: Don't report ports connected if nothing is attached to them
  drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it

Jernej Skrabec (4):
  drm/sun4i: tcon: set sync polarity for tcon1 channel
  drm/sun4i: dw-hdmi: always set clock rate
  drm/sun4i: Fix H6 HDMI PHY configuration
  drm/sun4i: dw-hdmi: Fix max. frequency for H6

Maxime Ripard (1):
  drm/vc4: hvs: Fix buffer overflow with the dlist handling

Quanyang Wang (1):
  drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable

Ville Syrjälä (1):
  drm/i915: Fix overlay frontbuffer tracking

 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  4 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  |  1 +
 drivers/gpu/drm/i915/display/intel_overlay.c   | 17 +++---
 drivers/gpu/drm/i915/display/intel_tc.c| 67 --
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 ++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 10 +---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |  1 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++--
 drivers/gpu/drm/ttm/ttm_pool.c | 10 
 drivers/gpu/drm/vc4/vc4_plane.c| 18 --
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++--
 12 files changed, 122 insertions(+), 78 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Juan Fernando Diosdado Ramirez]

Ayuda
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[sandy . 8925]

Signed-off-by: Sandeep Raghuraman 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Dave Airlie]

The goal here is to make the ttm_tt object just represent a
memory backing store, and now whether the store is bound to a
global translation table. It moves binding up to the bo level.

There's a lot more work on removing the global TT from the core
of TTM, but this seems like a good start.

Dave.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Rob Clark]

Hi Dave,

A few fixes, mostly fallout from the address space refactor and dpu
color processing.


The following changes since commit 1cb2c4a2c89b2004a36399860c85a1af9b3fcba7:

  Revert "drm/msm/dpu: add support for clk and bw scaling for display"
(2020-06-01 20:56:18 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2020-06-25

for you to fetch changes up to 30480e6ed508e3ff7a3e03c975696aa5196ffe8a:

  drm/msm: Fix up the rest of the messed up address sizes (2020-06-22
12:12:29 -0700)


Bernard Zhao (1):
  drm/msm: fix potential memleak in error branch

Chen Tao (1):
  drm/msm/dpu: fix error return code in dpu_encoder_init

Eric Anholt (2):
  drm/msm: Fix address space size after refactor.
  drm/msm: Fix setup of a6xx create_address_space.

John Stultz (1):
  drm/msm: Fix 0xlub in "Refactor address space initialization"

Jordan Crouse (1):
  drm/msm: Fix up the rest of the messed up address sizes

Kalyan Thota (1):
  drm/msm/dpu: request for display color blocks based on hw catalog entry

Krishna Manikandan (1):
  drm/msm/dpu: allow initialization of encoder locks during encoder init

 drivers/gpu/drm/msm/adreno/a2xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c|  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c|  2 +-
 drivers/gpu/drm/msm/msm_submitqueue.c   |  4 +++-
 9 files changed, 21 insertions(+), 15 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Ville Syrjälä]

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Message-ID: <20200226115708.gh13...@intel.com>
References: <20200219203544.31013-1-ville.syrj...@linux.intel.com>
 

 <20200219203544.31013-5-ville.syrj...@linux.intel.com>
 <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com>
 <20200225112114.ga13...@intel.com>
 <3ca785f2-9032-aaf9-0965-8657d3111...@samsung.com>
 <20200225154506.gf13...@intel.com>
 <20200225192720.gg13...@intel.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)

On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
>  wrote:
> 
> > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
> 
> That's impressive :D
> 
> > Unfortunately it found a lot of strange stuff:
> 
> I will answer for the weirdness I caused.
> 
> I have long suspected that a whole bunch of the "simple" displays
> are not simple but contains a display controller and memory.
> That means that the speed over the link to the display and
> actual refresh rate on the actual display is asymmetric because
> well we are just updating a RAM, the resolution just limits how
> much data we are sending, the clock limits the speed on the
> bus over to the RAM on the other side.

IMO even in command mode mode->clock should probably be the actual
dotclock used by the display. If there's another clock for the bus
speed/etc. it should be stored somewhere else.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Rob Clark]

Hi Dave,

This time around:

+ OCMEM support to enable the couple generations that had shared OCMEM
  rather than GMEM exclusively for the GPU (late a3xx and I think basically
  all of a4xx).  Bjorn and Brian decided to land this through the drm
  tree to avoid having to coordinate merge requests.
+ a510 support, and various associated display support
+ the usual misc cleanups and fixes

The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
  Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-11-05

for you to fetch changes up to e20c9284c8f212081afc28471daaac9b0d54252f:

  drm/msm/adreno: Add support for Adreno 510 GPU (2019-11-04 13:18:31 -0800)


AngeloGioacchino Del Regno (6):
  drm/msm/mdp5: Add optional TBU and TBU_RT clocks
  dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks
  drm/msm/mdp5: Add configuration for msm8x76
  drm/msm/dsi: Add configuration for 28nm PLL on family B
  drm/msm/dsi: Add configuration for 8x76
  drm/msm/adreno: Add support for Adreno 510 GPU

Arnd Bergmann (1):
  drm/msm: include linux/sched/task.h

Ben Dooks (2):
  drm/msm: make a5xx_show and a5xx_gpu_state_put static
  drm/msm/mdp5: make config variables static

Brian Masney (6):
  dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
  dt-bindings: display: msm: gmu: add optional ocmem property
  soc: qcom: add OCMEM driver
  drm/msm/gpu: add ocmem init/cleanup functions
  soc: qcom: ocmem: add missing includes
  drm/msm/hdmi: silence -EPROBE_DEFER warning

Drew Davenport (7):
  drm/msm/dpu: Remove unused variables
  drm/msm/dpu: Remove unused macro
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm: Remove unused function arguments

Krzysztof Wilczynski (1):
  drm/msm/dsi: Move static keyword to the front of declarations

Rob Clark (4):
  firmware: qcom: scm: add OCMEM lock/unlock interface
  firmware: qcom: scm: add support to restore secure config to qcm_scm-32
  drm/msm: fix rd dumping for split-IB1
  drm/msm: always dump buffer base/size

Sean Paul (1):
  drm/msm: Sanitize the modeset_is_locked checks in dpu

Stephan Gerhold (1):
  drm/msm/dsi: Implement qcom, dsi-phy-regulator-ldo-mode for 28nm PHY

zhengbin (11):
  drm/msm/dpu: Remove set but not used variable 'priv' in dpu_kms.c
  drm/msm/dpu: Remove set but not used variable 'priv' in
dpu_encoder_phys_vid.c
  drm/msm/dpu: Remove set but not used variable 'priv' in dpu_core_irq.c
  drm/msm/dpu: Remove set but not used variables 'dpu_cstate', 'priv'
  drm/msm/dpu: Remove set but not used variables 'cmd_enc', 'priv'
  drm/msm/dpu: Remove set but not used variables 'mode', 'dpu_kms', 'priv'
  drm/msm/mdp5: Remove set but not used variable 'fmt'
  drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup
  drm/msm/dsi: Remove set but not used variable 'lpx'
  drm/msm/dsi: Remove set but not used variable 'lp'
  drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in modeset_init

 .../devicetree/bindings/display/msm/gmu.txt|  51 +++
 .../devicetree/bindings/display/msm/mdp5.txt   |   2 +
 .../devicetree/bindings/sram/qcom,ocmem.yaml   |  96 +
 drivers/firmware/qcom_scm-32.c |  52 ++-
 drivers/firmware/qcom_scm-64.c |  12 +
 drivers/firmware/qcom_scm.c|  53 +++
 drivers/firmware/qcom_scm.h|   9 +
 drivers/gpu/drm/msm/Kconfig|   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  28 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h  |   3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |  25 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h  |   3 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  |  79 +++-
 drivers/gpu/drm/msm/adreno/a5xx_power.c|   7 +
 drivers/gpu/drm/msm/adreno/adreno_device.c |  15 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  40 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  15 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c   |  43 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  21 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  20 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  39 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  15 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  60 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c   |   6 +-
 drivers/gpu/drm/msm/d

[no subject]

[Rob Herring]

Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes

With further testing of recent changes with lockdep and other locking
checks enabled, we've found several bugs in the shrinker code and one
sleep while atomic in panfrost_gem_open(). This series addresses those
issues.

Delaying the unmapping of pages turns out to be a bad idea. Instead we 
need to rework panfrost_mmu_unmap() to not do a runtime PM resume which 
takes several locks and causes more lockdep warnings. Unfortunately, 
there initially appeared to be some mismatches between the runtime PM 
state and the h/w. The result is several fixes to the runtime PM 
initialization and handling in jobs. With this, the changes to 
panfrost_mmu_unmap() are working correctly.

v2:
 - Drop already applied 'drm/panfrost: Fix sleeping while atomic in 
   panfrost_gem_open'
 - Runtime PM clean-ups
 - Keep panfrost_gem_purge and use mutex_trylock there
 - Rework panfrost_mmu_unmap runtime PM

Rob

Rob Herring (8):
  drm/panfrost: Fix possible suspend in panfrost_remove
  drm/panfrost: Rework runtime PM initialization
  drm/panfrost: Hold runtime PM reference until jobs complete
  drm/shmem: Do dma_unmap_sg before purging pages
  drm/shmem: Use mutex_trylock in drm_gem_shmem_purge
  drm/panfrost: Use mutex_trylock in panfrost_gem_purge
  drm/panfrost: Rework page table flushing and runtime PM interaction
  drm/panfrost: Remove unnecessary flushing from tlb_inv_context

 drivers/gpu/drm/drm_gem_shmem_helper.c| 13 -
 drivers/gpu/drm/panfrost/panfrost_device.c|  9 
 drivers/gpu/drm/panfrost/panfrost_drv.c   | 16 ---
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  | 11 +++--
 drivers/gpu/drm/panfrost/panfrost_job.c   | 16 ---
 drivers/gpu/drm/panfrost/panfrost_mmu.c   | 47 +--
 include/drm/drm_gem_shmem_helper.h|  2 +-
 7 files changed, 59 insertions(+), 55 deletions(-)

-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Sam Ravnborg]

The first three patches prepare for the removal of drmP.h.
The last patch remove use of drmP.h and replace with necessary
include files to fix build.

Build tested with various configs and various architectures.

I had preferred that the via driver was replaced by the
openchrome driver, but until we have it then we need
to deal with the legacy via driver when removing old cruft
in the drm subsystem.

v3:
- Use static inline functions for the read/write operations (Emil)
- Use dedicated *_mask_or() and *_mask_and() (Emil)
- Replace DRM_WAIT_ON in same path that introduces VIA_WAIT_ON (Emil)
- Collected r-b's
- Changelog adjustments
- Rebased on top of drm-misc-next

v2:
- Add a copy of DRM_WAIT_ON to the via driver, keeping
  the changes to this legacy driver to a minimum.
  This also gives much more confidence that the
  driver continues to work as there is no changes
  in logic. Therefore dropped "RFT".
- Added Cc: Michel Dänzer  to all
  patches, as Michael have commented on the series.

Sam

Sam Ravnborg (4):
  drm/via: drop use of DRM(READ|WRITE) macros
  drm/via: copy DRM_WAIT_ON as VIA_WAIT_ON and use it
  drm/via: make via_drv.h self-contained
  drm/via: drop use of drmP.h

 drivers/gpu/drm/via/via_dma.c  | 43 +++-
 drivers/gpu/drm/via/via_dmablit.c  | 41 ++-
 drivers/gpu/drm/via/via_drv.c  |  7 +++-
 drivers/gpu/drm/via/via_drv.h  | 83 +++---
 drivers/gpu/drm/via/via_irq.c  | 54 +
 drivers/gpu/drm/via/via_map.c  |  6 ++-
 drivers/gpu/drm/via/via_mm.c   |  7 +++-
 drivers/gpu/drm/via/via_verifier.c | 22 +-
 drivers/gpu/drm/via/via_video.c|  5 ++-
 9 files changed, 182 insertions(+), 86 deletions(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Dave Airlie]

Hey Linus,

A small bit more lively this week but not majorly so. I'm away in
Japan next week for family holiday, so I'll be pretty disconnected,
I've asked Daniel to do fixes for the week while I'm out.

core:
- Allow fb changes in async commits (drivers as well)

udmabuf:
- Unmap scatterlist when unmapping udmabuf

komeda:
- oops, dma mapping and warning fixes

arm-hdlcd:
- clock fixes,
- mode validation fix

i915:
- Add a missing Icelake workaround
- GVT - DMA map fault fix and enforcement fixes

Dave.
amdgpu:
- DCE resume fix
- New raven variation updates



drm-fixes-2019-06-07:
drm i915, amdgpu, arm display, atomic update fixes
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:

  Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-06-07

for you to fetch changes up to e659b4122cf9e0938b80215de6c06823fb4cf796:

  Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-06-07
10:41:33 +1000)


drm i915, amdgpu, arm display, atomic update fixes


Aleksei Gimbitskii (2):
  drm/i915/gvt: Check if cur_pt_type is valid
  drm/i915/gvt: Assign NULL to the pointer after memory free.

Chengming Gui (1):
  drm/amd/powerplay: add set_power_profile_mode for raven1_refresh

Colin Xu (3):
  drm/i915/gvt: Update force-to-nonpriv register whitelist
  drm/i915/gvt: Fix GFX_MODE handling
  drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler

Dan Carpenter (1):
  drm/komeda: Potential error pointer dereference

Dave Airlie (5):
  Merge tag 'drm-intel-fixes-2019-06-03' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-5.2' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2019-06-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'malidp-fixes' of git://linux-arm.org/linux-ld into drm-fixes
  Merge tag 'drm-intel-fixes-2019-06-06' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Gao, Fred (1):
  drm/i915/gvt: Fix cmd length of VEB_DI_IECP

Helen Koike (5):
  drm/rockchip: fix fb references in async update
  drm/amd: fix fb references in async update
  drm/msm: fix fb references in async update
  drm/vc4: fix fb references in async update
  drm: don't block fb changes for async plane updates

Joonas Lahtinen (2):
  Merge tag 'gvt-fixes-2019-05-30' of
https://github.com/intel/gvt-linux into drm-intel-fixes
  Merge tag 'gvt-fixes-2019-06-05' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Louis Li (1):
  drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

Lowry Li (Arm Technology China) (1):
  drm/komeda: fixing of DMA mapping sg segment warning

Lucas Stach (1):
  udmabuf: actually unmap the scatterlist

Prike Liang (1):
  drm/amd/amdgpu: add RLC firmware to support raven1 refresh

Robin Murphy (2):
  drm/arm/hdlcd: Actually validate CRTC modes
  drm/arm/hdlcd: Allow a bit of clock tolerance

Tina Zhang (1):
  drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack

Tvrtko Ursulin (1):
  drm/i915/icl: Add WaDisableBankHangMode

Weinan Li (1):
  drm/i915/gvt: add F_CMD_ACCESS flag for wa regs

Wen He (1):
  drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times

Xiaolin Zhang (1):
  drm/i915/gvt: save RING_HEAD into vreg when vgpu switched out

Xiong Zhang (1):
  drm/i915/gvt: refine ggtt range validation

YueHaibing (1):
  drm/komeda: remove set but not used variable 'kcrtc'

james qian wang (Arm Technology China) (1):
  drm/komeda: Constify the usage of komeda_component/pipeline/dev_funcs

 drivers/dma-buf/udmabuf.c  |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 12 -
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  3 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c|  1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 31 +++--
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  1 +
 .../gpu/drm/arm/display/komeda/d71/d71_component.c |  8 ++--
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   |  4 +-
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c|  6 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h|  8 ++--
 .../gpu/drm/arm/display/komeda/komeda_pipeline.c   |  4 +-
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   | 10 ++---
 drivers/gpu/drm/arm/dis

[no subject]

[Thomas Meyer]

From tho...@m3y3r.de Sun May 26 13:49:04 2019
Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated
To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch,
 dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patch: Cocci
X-Mailer: DiffSplit
Message-ID: <1558871364611-249425076-1-diffsplit-tho...@m3y3r.de>
References: <1558871364605-1026448693-0-diffsplit-tho...@m3y3r.de>
In-Reply-To: <1558871364605-1026448693-0-diffsplit-tho...@m3y3r.de>
X-Serial-No: 1

Make sure (of/i2c/platform)_device_id tables are NULL terminated.

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c 
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
@@ -198,6 +198,7 @@ static const struct of_device_id omapdss
{ .compatible = "toppoly,td028ttec1" },
{ .compatible = "tpo,td028ttec1" },
{ .compatible = "tpo,td043mtea1" },
+   {},
 };
 
 static int __init omapdss_boot_init(void)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Dave Airlie]

Hi Linus,

Just a couple of fixes PRs for rc1,

One MAINTAINERS address change, two panels fixes, and set of amdgpu
fixes (build fixes, display fixes and some others).

Thanks
Dave.

drm-next-2018-08-24:
amdgpu and panel/misc fixes.
The following changes since commit 3d63a3c14741ed015948943076f3c6a2f2cd7b27:

  Merge tag 'drm-msm-next-2018-08-10' of
git://people.freedesktop.org/~robclark/linux into drm-next (2018-08-17
10:46:51 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-08-24

for you to fetch changes up to 3e20e97c2d55fb18e4b06d16478edc757483b7db:

  Merge tag 'drm-misc-next-fixes-2018-08-23-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-08-24
13:41:03 +1000)


amdgpu and panel/misc fixes.


Alex Deucher (1):
  drm/amdgpu/display: disable eDP fast boot optimization on DCE8

Christian König (3):
  drm/amdgpu: fix incorrect use of fcheck
  drm/amdgpu: fix incorrect use of drm_file->pid
  drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3

Dave Airlie (3):
  Merge tag 'drm-misc-next-fixes-2018-08-22' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
  Merge branch 'drm-next-4.19' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-misc-next-fixes-2018-08-23-1' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next

Dmytro Laktyushkin (3):
  drm/amd/display: fix dp_ss_control vbios flag parsing
  drm/amd/display: make dp_ss_off optional
  drm/amd/display: fix dentist did ranges

Evan Quan (1):
  drm/amdgpu: set correct base for THM/NBIF/MP1 IP

Kai-Heng Feng (1):
  drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80

Leo (Sunpeng) Li (2):
  Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0
with CONFIG_X86"
  drm/amd/display: Don't build DCN1 when kcov is enabled

Samson Tam (1):
  drm/amd/display: Do not retain link settings

Sean Paul (2):
  drm/panel: simple: tv123wam: Add unprepare delay
  MAINTAINERS: drm-misc: Change seanpaul's email address

Yintian Tao (2):
  drm/amdgpu: access register without KIQ
  drm/powerplay: enable dpm under pass-through

 MAINTAINERS|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   | 103 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  21 ++---
 drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c   |   3 +
 drivers/gpu/drm/amd/amdgpu/vi.c|   4 +-
 drivers/gpu/drm/amd/display/Kconfig|   6 ++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  10 +-
 drivers/gpu/drm/amd/display/dc/Makefile|   2 +-
 .../amd/display/dc/bios/command_table_helper2.c|   2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile  |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   |  21 -
 drivers/gpu/drm/amd/display/dc/core/dc_debug.c |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   6 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  12 +--
 drivers/gpu/drm/amd/display/dc/dc.h|   2 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  |   6 +-
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.h  |   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c|  18 ++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.h|   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c  |   6 +-
 .../drm/amd/display/dc/dce/dce_stream_encoder.c|  20 ++--
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  10 +-
 drivers/gpu/drm/amd/display/dc/gpio/Makefile   |   2 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c   |   4 +-
 drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c |   4 +-
 drivers/gpu/drm/amd/display/dc/i2caux/Makefile |   2 +-
 drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c |   4 +-
 drivers/gpu/drm/amd/display/dc/inc/core_types.h|   7 +-
 drivers/gpu/drm/amd/display/dc/irq/Makefile|   2 +-
 drivers/gpu/drm/amd/display/dc/irq/irq_service.c   |   2 +-
 drivers/gpu/drm/amd/display/dc/os_types.h  |   2 +-
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |   4 +-
 drivers/gpu/drm/drm_edid.c |   3 +
 drivers/gpu/drm/panel/panel-simple.c   |   3 +
 35 files changed, 161 insertions(+), 142 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Dave Airlie]

Hi Linus, (apologies for blank body pull earlier)

This is the drm fixes for rc4. It's a bit larger than I'd like but the
exynos cleanups are pretty mechanical, and I'd rather have them in
sooner rather than later so we can avoid too much conflicts around
them. The non-mechanincal exynos changes are mostly fixes for new
feature recently introduced.

i915:
GVT and GGTT mapping fixes

amdgpu:
HDMI2.0 4K@60 Hz regression
Hotplug fixes for dual-GPU laptops to make power management better
Misc vega12 bios fixes, a race fix and some typos.

sii8620 bridge: small fixes around mode setting

core: use kvzalloc to allocate blob property memory.

If the exynos changes are too much, I'm happy to push back, and the
blank pull was thanks to baby induced sleep deprivation, fat fingers
and gmail.

Thanks,
Dave.

drm-fixes-2018-07-06:
amdgpu, i915, exynos, udl, sii8620 and core fixes
The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:

  Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-07-06

for you to fetch changes up to c78d1f9d95a9f2cd5546c64f5315f54681dd6055:

  Merge tag 'exynos-drm-fixes-for-v4.18-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2018-07-06 10:47:02 +1000)


amdgpu, i915, exynos, udl, sii8620 and core fixes


Alex Deucher (2):
  drm/amdgpu: fix swapped emit_ib_size in vce3
  drm/amdgpu/pm: fix display count in non-DC path

Andrzej Pietrasiewicz (1):
  drm/exynos: scaler: Reset hardware before starting the operation

Chris Wilson (1):
  drm/i915: Try GGTT mmapping whole object as partial

Dave Airlie (4):
  Merge tag 'drm-misc-fixes-2018-07-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2018-07-05' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.18' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.18-rc4' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Evan Quan (3):
  drm/amd/powerplay: correct vega12 thermal support as true
  drm/amd/powerplay: correct vega12 bootup values settings
  drm/amd/powerplay: smc_dpm_info structure change

Jani Nikula (1):
  Merge tag 'gvt-fixes-2018-07-03' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Lyude Paul (3):
  drm/amdgpu: Make struct amdgpu_atif private to amdgpu_acpi.c
  drm/amdgpu: Add amdgpu_atpx_get_dhandle()
  drm/amdgpu: Dynamically probe for ATIF handle (v2)

Maciej Purski (3):
  drm/bridge/sii8620: Send AVI infoframe in all MHL versions
  drm/bridge/sii8620: Fix display of packed pixel modes
  drm/bridge/sii8620: Fix link mode selection

Marek Szyprowski (10):
  drm/exynos: ipp: Rework checking for the correct buffer formats
  drm/exynos: rotator: Fix DRM_MODE_REFLECT_{X,Y} interpretation
  drm/exynos: scaler: Fix support for YUV420, YUV422 and YUV444 modes
  drm/exynos: gsc: Use real buffer width for configuring the hardware
  drm/exynos: gsc: Increase Exynos5433 buffer width alignment to 16 pixels
  drm/exynos: gsc: Fix DRM_MODE_REFLECT_{X,Y} interpretation
  drm/exynos: gsc: Fix support for NV16/61, YUV420/YVU420 and YUV422 modes
  drm/exynos: fimc: Use real buffer width for configuring the hardware
  drm/exynos: decon5433: Fix per-plane global alpha for XRGB modes
  drm/exynos: decon5433: Fix WINCONx reset value

Michel Dänzer (1):
  drm: Use kvzalloc for allocating blob property memory

Mikita Lipski (2):
  drm/amd/display: adding ycbcr420 pixel encoding for hdmi
  drm/amd/display: add a check for display depth validity

Mikulas Patocka (1):
  drm/udl: fix display corruption of the last line

Nicolai Hähnle (1):
  drm/amdgpu: fix user fence write race condition

Stefan Agner (1):
  drm/exynos: ipp: use correct enum type

Thomas Zimmermann (3):
  drm/exynos: Replace drm_framebuffer_{un/reference} with put,get functions
  drm/exynos: Replace drm_gem_object_unreference_unlocked with put function
  drm/exynos: Replace drm_dev_unref with drm_dev_put

Xiaolin Zhang (1):
  drm/i915/gvt: changed DDI mode emulation type

Zhao Yan (1):
  drm/i915/gvt: fix a bug of partially write ggtt enties

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  46 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   | 131 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   4 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  49 +++-
 dri

[no subject]

[rosdi ablatiff]

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Meghana Madhyastha]

linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul 
,ker...@martin.sperl.org
Cc: 
Bcc: 
Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers
Reply-To: 
In-Reply-To: 

On Sun, Mar 04, 2018 at 06:38:42PM +0100, Noralf Trønnes wrote:
> 
> Den 02.03.2018 12.11, skrev Meghana Madhyastha:
> >On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote:
> >>[cc += linux-rpi-ker...@lists.infradead.org]
> >>
> >>On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote:
> >>>I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls
> >>>spi_split_transfers_maxsize to split large chunks for spi dma transfers.
> >>>I then removed chunk splitting in the tinydrm spi helper (as now the core
> >>>is handling the chunk splitting). However, although the SPI HW should be
> >>>able to accomodate up to 65535 bytes for dma transfers, the splitting of
> >>>chunks to 65535 bytes results in a dma transfer time out error. However,
> >>>when the chunks are split to < 64 bytes it seems to work fine.
> >>Hm, that is really odd, how did you test this exactly, what did you
> >>use as SPI slave?  It contradicts our own experience, we're using
> >>Micrel KSZ8851 Ethernet chips as SPI slave on spi0 of a BCM2837
> >>and can send/receive messages via DMA to the tune of several hundred
> >>bytes without any issues.  In fact, for messages < 96 bytes, DMA is
> >>not used at all, so you've probably been using interrupt mode,
> >>see the BCM2835_SPI_DMA_MIN_LENGTH macro in spi-bcm2835.c.
> >Hi Lukas,
> >
> >I think you are right. I checked it and its not using the DMA mode which
> >is why its working with 64 bytes.
> >Noralf, that leaves us back to the
> >initial time out problem. I've tried doing the message splitting in
> >spi_sync as well as spi_pump_messages. Martin had explained that DMA
> >will wait for
> >the SPI HW to set the send_more_data line, but the SPI-HW itself will
> >stop triggering it when SPI_LEN is 0 causing DMA to wait forever. I
> >thought if we split it before itself, the SPI_LEN will not go to zero
> >thus preventing this problem, however it didn't work and started
> >hanging. So I'm a little uncertain as to how to proceed and debug what
> >exactly has caused the time out due to the asynchronous methods.
> 
> I did a quick test and at least this is working:
> 
> int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
>              struct spi_transfer *header, u8 bpw, const void *buf,
>              size_t len)
> {
>     struct spi_transfer tr = {
>         .bits_per_word = bpw,
>         .speed_hz = speed_hz,
>         .tx_buf = buf,
>         .len = len,
>     };
>     struct spi_message m;
>     size_t maxsize;
>     int ret;
> 
>     maxsize = tinydrm_spi_max_transfer_size(spi, 0);
> 
>     if (drm_debug & DRM_UT_DRIVER)
>         pr_debug("[drm:%s] bpw=%u, maxsize=%zu, transfers:\n",
>              __func__, bpw, maxsize);
> 
>     spi_message_init(&m);
>     m.spi = spi;
>     if (header)
>         spi_message_add_tail(header, &m);
>     spi_message_add_tail(&tr, &m);
> 
>     ret = spi_split_transfers_maxsize(spi->controller, &m, maxsize,
> GFP_KERNEL);
>     if (ret)
>         return ret;
> 
>     tinydrm_dbg_spi_message(spi, &m);
> 
>     return spi_sync(spi, &m);
> }
> EXPORT_SYMBOL(tinydrm_spi_transfer);
> 
> 
> Log:
> [   39.015644] [drm:mipi_dbi_fb_dirty [mipi_dbi]] Flushing [FB:36] x1=0,
> x2=320, y1=0, y2=240
> 
> [   39.018079] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2a, par=00 00 01
> 3f
> [   39.018129] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018152] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2a]
> [   39.018231] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018248] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 01 3f]
> 
> [   39.018330] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2b, par=00 00 00
> ef
> [   39.018347] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018362] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2b]
> [   39.018396] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018428] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 00 ef]
> 
> [   39.018487] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2c, len=153600
> [   39.018502] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018517] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2c]
> [   39.018565] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018594] tr(0): speed=48MHz, bpw=8, len=65532, tx_buf=[c6 18 c6 18
> c6 18 c6 18 c6 18 c6 18 c6 18 c6 18 ...]
> [   39.018608] tr(1): speed=48MHz, bpw=8, len=65532, tx_buf=[06 18 06 18
> 06 18 06 18 06 18 06 18 06 18 06 18 ...]
> [   39.018621] tr(2): speed=48MHz, bpw=8, len=22536, tx_buf=[10 82 10 82
> 10 82 10 82 10 82 10 82 18 e3 18 e3 ...]
Hi Noralf,

Yes this works but splitting in the spi subsystem doesn't seem to work.
So this means that spi_split_transfers_maxsize is working.
Should I just

[no subject]

[Dave Airlie]

Hi Linus,

This is the main set of fixes for rc4, one amdgpu fix, some exynos
regression fixes, some msm fixes and some i915 and GVT fixes.

I've got a second regression fix for some DP chips that might be a bit
large, but I think we'd like to land it now, I'll send it along
tomorrow, once you are happy with this set.

Dave.

The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b:

  Linux 4.12-rc3 (2017-05-28 17:20:53 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc4

for you to fetch changes up to 400129f0a3ae989c30b37104bbc23b35c9d7a9a4:

  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2017-06-01 12:07:48 +1000)


msm/exynos/i915/amdgpu fixes


Changbin Du (1):
  drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache

Chris Wilson (1):
  drm/i915/selftests: Silence compiler warning in igt_ctx_exec

Chuanxiao Dong (2):
  drm/i915: set initialised only when init_context callback is NULL
  drm/i915/gvt: Disable compression workaround for Gen9

Daniel Vetter (2):
  Revert "drm/i915: Restore lost "Initialized i915" welcome message"
  drm/exynos: Merge pre/postclose hooks

Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2017-05-29' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'msm-fixes-4.12-rc4' of
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.12' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Eric Anholt (2):
  drm/msm: Expose our reservation object when exporting a dmabuf.
  drm/msm: Reuse dma_fence_release.

Hans de Goede (1):
  drm/i915: Fix new -Wint-in-bool-context gcc compiler warning

Hoegeun Kwon (2):
  drm/exynos: dsi: Fix the parse_dt function
  drm/exynos: dsi: Remove bridge node reference in removal

Inki Dae (1):
  drm/exynos: clean up description of exynos_drm_crtc

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-05-25' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Joonas Lahtinen (1):
  drm/i915: Do not sync RCU during shrinking

Jordan Crouse (2):
  drm/msm: Take the mutex before calling msm_gem_new_impl
  drm/msm: Fix the check for the command size

Leo Liu (1):
  drm/amdgpu: Program ring for vce instance 1 at its register space

Matthew Auld (1):
  drm/i915: use vma->size for appgtt allocate_va_range

Philipp Zabel (1):
  drm/msm: for array in-fences, check if all backing fences are
from our own context before waiting

Rob Clark (4):
  drm/msm: select PM_OPP
  drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()
  drm/msm/gpu: check legacy clk names in get_clocks()
  drm/msm/mdp5: release hwpipe(s) for unused planes

Tobias Klauser (1):
  drm/msm: constify irq_domain_ops

Ville Syrjälä (1):
  drm/i915: Stop pretending to mask/unmask LPE audio interrupts

 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 95 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 26 +++
 drivers/gpu/drm/i915/gvt/execlist.c   | 30 ---
 drivers/gpu/drm/i915/gvt/handlers.c   | 30 ---
 drivers/gpu/drm/i915/i915_drv.c   |  4 -
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c  |  5 --
 drivers/gpu/drm/i915/i915_irq.c   | 15 ++--
 drivers/gpu/drm/i915/i915_reg.h   |  2 +-
 drivers/gpu/drm/i915/intel_lpe_audio.c| 36 -
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_context.c |  8 +-
 drivers/gpu/drm/msm/Kconfig   |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  9 ++-
 drivers/gpu/drm/msm/msm_drv.c |  1 +
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_fence.c   | 10 +--
 drivers/gpu/drm/msm/msm_gem.c |  6 ++
 drivers/gpu/drm/msm/msm_gem_prime.c   |  7 ++
 drivers/gpu/drm/msm/msm_gem_submit.c  | 14 ++--
 drivers/gpu/drm/msm/msm_gpu.c |  4 +-
 24 files changed, 169 insertions(+), 154 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

[Heliogabalo Santos Jugon]

hi,

I'm a new programmer, i just was wondering if i can get some docs to
start learning DRI. I googled a lot but i didn't find a starter
documentation. Some refs will be apreciated

thx

No subject

[Maxime Ripard]

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges

Hi,

This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.

Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.

This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.

Let me know what you think,
Maxime

Changes from v4:
  - Removed unused functions

Changes from v3:
  - Depends on OF in Kconfig
  - Fixed typos in the driver comments
  - Removed the mention of a "passive" bridge in the bindings doc
  - Made the strcuture const
  - Removed the nops and best_encoders implementations
  - Removed the call to drm_bridge_enable in the sun4i driver

Changes from v2:
  - Changed the compatible as suggested
  - Rebased on top 4.8

Changes from v1:
  - Switch to using a vga-connector
  - Use drm_encoder bridge pointer instead of doing our own
  - Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
  - Switch to of_i2c_get_adapter by node, and put the reference when done
  - Rebased on linux-next 

Maxime Ripard (5):
  drm/sun4i: rgb: Remove the bridge enable/disable functions
  drm/bridge: Add RGB to VGA bridge support
  ARM: sun5i: a13-olinuxino: Enable VGA bridge
  ARM: multi_v7: enable VGA bridge
  ARM: sunxi: Enable VGA bridge

 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts  |  54 +
 arch/arm/configs/multi_v7_defconfig|   1 +
 arch/arm/configs/sunxi_defconfig   |   1 +
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c| 229 +
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |   6 -
 8 files changed, 341 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

-- 
2.9.3

No subject

[Carlos Palminha]

With patch 
http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha
 at synopsys.com
i2c slave encoder drivers no longer need to implement dummy mode_fixup function.

This patch set nukes the dummy functions from i2c slave encoder drivers.

(changes made on top of Daniel Vetter topic/drm-misc branch)

[no subject]

[Markus Trippelsdorf]

On 2014.09.07 at 23:47 -0400, Alex Deucher wrote:
> On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
>  wrote:
> > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> >> Let me know if it works for you, cause we don't really have any hardware
> >> any more to test it.
> >
> > I've tested your patch series today (using drm-next-3.18 from
> > ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> > videos. While it sometimes works as expected, it stalled the GPU far too
> > often to be usable. The stalls are not recoverable and the machine ends
> > up with a black sreen, but still accepts SysRq keyboard inputs.
> 
> 
> Does it work any better if dpm is disabled?

Unfortunately no. The symptoms are unchanged.

-- 
Markus

[no subject]

[Alex Deucher]

On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
 wrote:
> On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
>> Let me know if it works for you, cause we don't really have any hardware
>> any more to test it.
>
> I've tested your patch series today (using drm-next-3.18 from
> ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> videos. While it sometimes works as expected, it stalled the GPU far too
> often to be usable. The stalls are not recoverable and the machine ends
> up with a black sreen, but still accepts SysRq keyboard inputs.


Does it work any better if dpm is disabled?

Alex

>
> Here are some logs:
>
> vdpauinfo:
> display: :0   screen: 0
> API version: 1
> Information string: G3DVL VDPAU Driver Shared Library version 1.0
>
> Video surface:
>
> name   width height types
> ---
> 420 8192  8192  NV12 YV12
> 422 8192  8192  UYVY YUYV
> 444 8192  8192  Y8U8V8A8 V8U8Y8A8
>
> Decoder capabilities:
>
> name   level macbs width height
> ---
> MPEG1 0  9216  2048  1152
> MPEG2_SIMPLE  3  9216  2048  1152
> MPEG2_MAIN3  9216  2048  1152
> H264_BASELINE41  9216  2048  1152
> H264_MAIN41  9216  2048  1152
> H264_HIGH41  9216  2048  1152
> VC1_ADVANCED  4  9216  2048  1152
>
> Output surface:
>
> name  width height nat types
> 
> B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
>
> Bitmap surface:
>
> name  width height
> --
> B8G8R8A8  8192  8192
> R8G8B8A8  8192  8192
> R10G10B10A2   8192  8192
> B10G10R10A2   8192  8192
> A88192  8192
>
> Video mixer:
>
> feature namesup
> 
> DEINTERLACE_TEMPORAL y
> DEINTERLACE_TEMPORAL_SPATIAL -
> INVERSE_TELECINE -
> NOISE_REDUCTION  y
> SHARPNESSy
> LUMA_KEY -
> HIGH QUALITY SCALING - L1-
> HIGH QUALITY SCALING - L2-
> HIGH QUALITY SCALING - L3-
> HIGH QUALITY SCALING - L4-
> HIGH QUALITY SCALING - L5-
> HIGH QUALITY SCALING - L6-
> HIGH QUALITY SCALING - L7-
> HIGH QUALITY SCALING - L8-
> HIGH QUALITY SCALING - L9-
>
> parameter name  sup  min  max
> -
> VIDEO_SURFACE_WIDTH  y48 2048
> VIDEO_SURFACE_HEIGHT y48 1152
> CHROMA_TYPE  y
> LAYERS   y 04
>
> attribute name  sup  min  max
> -
> BACKGROUND_COLOR y
> CSC_MATRIX   y
> NOISE_REDUCTION_LEVELy  0.00 1.00
> SHARPNESS_LEVEL  y -1.00 1.00
> LUMA_KEY_MIN_LUMAy
> LUMA_KEY_MAX_LUMAy
>
>
> Sep  7 14:03:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
> Sep  7 14:03:45 x4 kernel: [drm] radeon kernel modesetting enabled.
> Sep  7 14:03:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
> 0x1002:0x9614 0x1043:0x834D).
> Sep  7 14:03:45 x4 kernel: [drm] register mmio base: 0xFBEE
> Sep  7 14:03:45 x4 kernel: [drm] register mmio size: 65536
> Sep  7 14:03:45 x4 kernel: ATOM BIOS: 113
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 
> - 0xC7FF (128M used)
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 
> - 0xBFFF
> Sep  7 14:03:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
> Sep  7 14:03:45 x4 kernel: [drm] RAM width 32bits DDR
> Sep  7 14:03:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
> 4083350 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
> 2097152 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing pool allocator
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing DMA pool allocator
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
> Sep  7 14:03:45 x4 kernel: [drm] Loading RS780 Microcode
> Sep  7 14:03:45 x4 kernel: == power state 0 ==
> Sep  7 14:03:45 x4 kernel:  ui class: none
> Sep  7 14:03:45 x4 kernel:  internal class: boot
> Sep  7 14:03:45 x4 kernel:  caps: video
> Sep  7 14:03:45 x4 kernel:  uvdvclk: 0 dclk: 0
> Sep  7 14:03:45 x4 kernel:  power level 0sclk: 500

[no subject]

[Markus Trippelsdorf]

On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> Let me know if it works for you, cause we don't really have any hardware 
> any more to test it.

I've tested your patch series today (using drm-next-3.18 from
~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
videos. While it sometimes works as expected, it stalled the GPU far too
often to be usable. The stalls are not recoverable and the machine ends
up with a black sreen, but still accepts SysRq keyboard inputs.

Here are some logs:

vdpauinfo:
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
420 8192  8192  NV12 YV12 
422 8192  8192  UYVY YUYV 
444 8192  8192  Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name   level macbs width height
---
MPEG1 0  9216  2048  1152
MPEG2_SIMPLE  3  9216  2048  1152
MPEG2_MAIN3  9216  2048  1152
H264_BASELINE41  9216  2048  1152
H264_MAIN41  9216  2048  1152
H264_HIGH41  9216  2048  1152
VC1_ADVANCED  4  9216  2048  1152

Output surface:

name  width height nat types

B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Bitmap surface:

name  width height
--
B8G8R8A8  8192  8192
R8G8B8A8  8192  8192
R10G10B10A2   8192  8192
B10G10R10A2   8192  8192
A88192  8192

Video mixer:

feature namesup

DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION  y
SHARPNESSy
LUMA_KEY -
HIGH QUALITY SCALING - L1-
HIGH QUALITY SCALING - L2-
HIGH QUALITY SCALING - L3-
HIGH QUALITY SCALING - L4-
HIGH QUALITY SCALING - L5-
HIGH QUALITY SCALING - L6-
HIGH QUALITY SCALING - L7-
HIGH QUALITY SCALING - L8-
HIGH QUALITY SCALING - L9-

parameter name  sup  min  max
-
VIDEO_SURFACE_WIDTH  y48 2048
VIDEO_SURFACE_HEIGHT y48 1152
CHROMA_TYPE  y  
LAYERS   y 04

attribute name  sup  min  max
-
BACKGROUND_COLOR y  
CSC_MATRIX   y  
NOISE_REDUCTION_LEVELy  0.00 1.00
SHARPNESS_LEVEL  y -1.00 1.00
LUMA_KEY_MIN_LUMAy  
LUMA_KEY_MAX_LUMAy  


Sep  7 14:03:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Sep  7 14:03:45 x4 kernel: [drm] radeon kernel modesetting enabled.
Sep  7 14:03:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
0x1002:0x9614 0x1043:0x834D).
Sep  7 14:03:45 x4 kernel: [drm] register mmio base: 0xFBEE
Sep  7 14:03:45 x4 kernel: [drm] register mmio size: 65536
Sep  7 14:03:45 x4 kernel: ATOM BIOS: 113
Sep  7 14:03:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 - 
0xC7FF (128M used)
Sep  7 14:03:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
Sep  7 14:03:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Sep  7 14:03:45 x4 kernel: [drm] RAM width 32bits DDR
Sep  7 14:03:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
4083350 kiB
Sep  7 14:03:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
2097152 kiB
Sep  7 14:03:45 x4 kernel: [TTM] Initializing pool allocator
Sep  7 14:03:45 x4 kernel: [TTM] Initializing DMA pool allocator
Sep  7 14:03:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Sep  7 14:03:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Sep  7 14:03:45 x4 kernel: [drm] Loading RS780 Microcode
Sep  7 14:03:45 x4 kernel: == power state 0 ==
Sep  7 14:03:45 x4 kernel:  ui class: none
Sep  7 14:03:45 x4 kernel:  internal class: boot 
Sep  7 14:03:45 x4 kernel:  caps: video 
Sep  7 14:03:45 x4 kernel:  uvdvclk: 0 dclk: 0
Sep  7 14:03:45 x4 kernel:  power level 0sclk: 5 
vddc_index: 2
Sep  7 14:03:45 x4 kernel:  power level 1sclk: 5 
vddc_index: 2
Sep  7 14:03:45 x4 kernel:  status: c r b 
Sep  7 14:03:45 x4 kernel: == power state 1 ==
Sep  7 14:03:45 x4 kernel:  ui class: performance
Sep  7 14:03:45 x4 kernel:  internal class: none
Sep  7 14:03:

[no subject]

[Christian König]

Let me know if it works for you, cause we don't really have any hardware 
any more to test it.

Christian.

Am 24.08.2014 um 15:34 schrieb Mike Lothian:
>
> Thanks for this
>
> Good work
>
> On 24 Aug 2014 14:15, "Christian K?nig"  > wrote:
>
> Hello everyone,
>
> the following patches add UVD support for older ASICs (RV6xx,
> RS[78]80, RV7[79]0). For everybody wanting to test it I've also
> uploaded a branch to FDO:
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
> 
>
> Additionally to the patches you need UVD firmware as well, which
> can be found at the usual location:
> http://people.freedesktop.org/~agd5f/radeon_ucode/
> 
>
> A small Mesa patch is needed as well, cause the older hardware
> doesn't support field based output of video frames. So
> unfortunately VDPAU/OpenGL interop won't work either.
>
> We can only provide best effort support for those older ASICs, but
> at least on my RS[78]80 based laptop it seems to work perfectly fine.
>
> Happy testing,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

-- next part --
An HTML attachment was scrubbed...
URL: 

No subject

[Christian König]

Hello everyone,

the following patches add UVD support for older ASICs (RV6xx, RS[78]80, 
RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: 
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release

Additionally to the patches you need UVD firmware as well, which can be found 
at the usual location: http://people.freedesktop.org/~agd5f/radeon_ucode/

A small Mesa patch is needed as well, cause the older hardware doesn't support 
field based output of video frames. So unfortunately VDPAU/OpenGL interop won't 
work either.

We can only provide best effort support for those older ASICs, but at least on 
my RS[78]80 based laptop it seems to work perfectly fine.

Happy testing,
Christian.

[no subject]

[Mike Lothian]

Thanks for this

Good work
On 24 Aug 2014 14:15, "Christian K?nig"  wrote:

> Hello everyone,
>
> the following patches add UVD support for older ASICs (RV6xx, RS[78]80,
> RV7[79]0). For everybody wanting to test it I've also uploaded a branch to
> FDO:
> http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
>
> Additionally to the patches you need UVD firmware as well, which can be
> found at the usual location:
> http://people.freedesktop.org/~agd5f/radeon_ucode/
>
> A small Mesa patch is needed as well, cause the older hardware doesn't
> support field based output of video frames. So unfortunately VDPAU/OpenGL
> interop won't work either.
>
> We can only provide best effort support for those older ASICs, but at
> least on my RS[78]80 based laptop it seems to work perfectly fine.
>
> Happy testing,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 

No subject

[Thomas Hellstrom]

After a previous patch series and a discussion with Daniel Vetter and
David Herrmann, I've reworked the patches a bit. Please review.

Patch 5 is already reviewed.

/Thomas

>From Thomas Hellstrom  # This line is ignored.
From: Thomas Hellstrom 
Subject: 
In-Reply-To: 

No subject

[Christian König]

Hey Alex,

here are my patches for reworking the ring function pointers and separating out 
the UVD and DMA rings.

Everything is rebased on your drm-next-3.12-wip branch, please review and add 
them to your branch.

Thanks,
Christian.

[no subject]

[Alex Deucher]

On Tue, Aug 13, 2013 at 5:56 AM, Christian K?nig
 wrote:
> Hey Alex,
>
> here are my patches for reworking the ring function pointers and separating 
> out the UVD and DMA rings.
>
> Everything is rebased on your drm-next-3.12-wip branch, please review and add 
> them to your branch.

Patches look good to me.  I've added them to my 3.12 tree.

Alex

[no subject]

[Christian König]

Hey Alex,

here are my patches for reworking the ring function pointers and separating out 
the UVD and DMA rings.

Everything is rebased on your drm-next-3.12-wip branch, please review and add 
them to your branch.

Thanks,
Christian.

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

No subject

[Robert Schwebel]

, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: 
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

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

[no subject]

[Robert Schwebel]

, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: 
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

issue is that changing it will break any app relying on it being REALTIME 
clock. 

No subject

0x0314e050:  0x61010006: STATE_BASE_ADDRESS
0x0314e054:  0x0001:general state base address 0x
0x0314e058:  0x0001:surface state base address 0x
0x0314e05c:  0x0001:indirect state base address 0x
0x0314e060:  0x0001:instruction state base address 0x
0x0314e064:  0x1001:general state upper bound 0x1000
0x0314e068:  0x1001:indirect state upper bound 0x1000
0x0314e06c:  0x1001:instruction state upper bound 0x1000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e00016384 0048  000ab700 dirty purgeable render uncached
...
  11e3 4096 0011  000ab700 purgeable render uncached
  11e2b000 4096 0011  000ab700 purgeable render uncached
  10e43000 4096 0011  000ab700 render uncached
  10e44000 4096 0011  000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[no subject]

[Sascha Hauer]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

Ok, I'll try to put the GEM stuff into helper functions. Would you care
to review/test it? I have something else to do right now but I hope I'll
be there next week.

Sascha

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

No subject

i don't think kernel is the right place for it, for instance you need
to set the primary surface thing, i don't want to parse cmd stream in
kernel to figure that out. I would rather have userspace tool that
postprocess thing and convert it to proper AMD dump format.

Cheers,
Jerome

[no subject]

[Sascha Hauer]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

I totally agree. Having to track other drivers for bug fixes to apply
them on the own driver is not very convenient. As answered to Rob I do
not really have a clue how to accomplish this.

> 
> The code in question can be found at
> https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8
> 
> Btw. the imx-drm.h is missing in your patch.

Oops, here it is for reference, will include it in the next round.


#ifndef _IMX_DRM_H_
#define _IMX_DRM_H_

/**
 * User-desired buffer creation information structure.
 *
 * @size: requested size for the object.
 *  - this size value would be page-aligned internally.
 * @flags: user request for setting memory type or cache attributes.
 * @handle: returned handle for the object.
 */
struct imx_drm_gem_create {
unsigned int size;
unsigned int flags;
unsigned int handle;
};

struct imx_drm_device;
struct imx_drm_crtc;

struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
};

int imx_drm_add_crtc(struct drm_crtc *crtc,
struct imx_drm_crtc **new_crtc,
const struct drm_crtc_funcs *crtc_funcs,
const struct drm_crtc_helper_funcs *crtc_helper_funcs,
const struct imx_drm_crtc_helper_funcs *ec_helper_funcs,
struct module *owner);
int imx_drm_remove_crtc(struct imx_drm_crtc *);
int imx_drm_init_drm(struct platform_device *pdev,
int preferred_bpp);
int imx_drm_exit_drm(void);

int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_crtc_vblank_put(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc);

/*
 * imx drm buffer entry structure.
 *
 * @paddr: physical address of allocated memory.
 * @vaddr: kernel virtual address of allocated memory.
 * @size: size of allocated memory.
 */
struct imx_drm_buf_entry {
dma_addr_t paddr;
void __iomem *vaddr;
unsigned int size;
};

/* get physical memory information of a drm framebuffer. */
struct imx_drm_buf_entry *imx_drm_fb_get_buf(struct drm_framebuffer *fb);

struct imx_drm_encoder;
int imx_drm_add_encoder(struct drm_encoder *encoder,
struct imx_drm_encoder **new_enc,
struct module *owner);
int imx_drm_remove_encoder(struct imx_drm_encoder *);

struct imx_drm_connector;
int imx_drm_add_connector(struct drm_connector *connector,
struct imx_drm_connector **new_con,
struct module *owner);
int imx_drm_remove_connector(struct imx_drm_connector *);

void imx_drm_mode_config_init(struct drm_device *drm);

#define to_imx_drm_gem_obj(x)   container_of(x,\
struct imx_drm_gem_obj, base)

struct imx_drm_gem_obj {
struct drm_gem_object base;
struct imx_drm_buf_entry *entry;
};

/* unmap a buffer from user space. */
int imx_drm_gem_munmap_ioctl(struct drm_device *drm, void *data,
struct drm_file *file_priv);

/* initialize gem object. */
int imx_drm_gem_init_object(struct drm_gem_object *obj);

/* free gem object. */
void imx_drm_gem_free_object(struct drm_gem_object *gem_obj);

/* create memory region for drm framebuffer. */
int imx_drm_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *drm, struct drm_mode_create_dumb *args);

/* map memory region for drm framebuffer to user space. */
int imx_drm_gem_dumb_map_offset(struct drm_file *file_priv,
struct drm_devi

[no subject]

[Lars-Peter Clausen]

On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> Hi All,
> 
> The following adds a drm/kms driver for the Freescale i.MX LCDC
> controller. Most notable change to the last SDRM based version is that
> the SDRM layer has been removed and the driver now is purely i.MX
> specific. I hope that this is more acceptable now.
> 
> Another change is that the probe is now devicetree based. For now I
> took the easy way out and only put an edid blob into the devicetree.
> I haven't documented the binding yet, I would add that when the rest
> is considered ok.
> 
> Comments very welcome.
> 

Hi,

I really liked the sdrm layer. At least some bits of it. I've been working
on a "simple" DRM driver as well. The hardware has no fancy acceleration
features, just a simple buffer and some scanout logic. I'm basically using
the same gem buffer structure and the buffer is also allocated using
dma_alloc_writecombine, which means we can probably share all of the GEM
handling code and probably also most of the fbdev code. I also started with
the Exynos GEM code as a template, but reworked it later to be more like the
UDL code, which made it a bit more compact. I think it would be a good idea
to put at least the GEM handling in some common code as I expect that we'll
see more similar "simple" DRM drivers pop up.

The code in question can be found at
https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8

Btw. the imx-drm.h is missing in your patch.

- Lars

> Thanks
>  Sascha
> 
> 
> Sascha Hauer (2):
>   DRM: add Freescale i.MX LCDC driver
>   pcm038 lcdc support
> 
>  arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
>  arch/arm/boot/dts/imx27.dtsi   |7 +
>  arch/arm/mach-imx/clock-imx27.c|1 +
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/imx/Kconfig|   18 +
>  drivers/gpu/drm/imx/Makefile   |8 +
>  drivers/gpu/drm/imx/imx-drm-core.c |  745 
> 
>  drivers/gpu/drm/imx/imx-fb.c   |  179 +++
>  drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
>  drivers/gpu/drm/imx/imx-gem.c  |  343 +
>  drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
>  drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
>  13 files changed, 2363 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/Makefile
>  create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fb.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
>  create mode 100644 drivers/gpu/drm/imx/imx-gem.c
>  create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
>  create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

[Sascha Hauer]

Hi All,

The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.

Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.

Comments very welcome.

Thanks
 Sascha


Sascha Hauer (2):
  DRM: add Freescale i.MX LCDC driver
  pcm038 lcdc support

 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/imx/Kconfig|   18 +
 drivers/gpu/drm/imx/Makefile   |8 +
 drivers/gpu/drm/imx/imx-drm-core.c |  745 
 drivers/gpu/drm/imx/imx-fb.c   |  179 +++
 drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
 drivers/gpu/drm/imx/imx-gem.c  |  343 +
 drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
 drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
 13 files changed, 2363 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/Kconfig
 create mode 100644 drivers/gpu/drm/imx/Makefile
 create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
 create mode 100644 drivers/gpu/drm/imx/imx-fb.c
 create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
 create mode 100644 drivers/gpu/drm/imx/imx-gem.c
 create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
 create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c

[no subject]

[Sascha Hauer]

Hi All,

The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.

Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.

Comments very welcome.

Thanks
 Sascha


Sascha Hauer (2):
  DRM: add Freescale i.MX LCDC driver
  pcm038 lcdc support

 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/imx/Kconfig|   18 +
 drivers/gpu/drm/imx/Makefile   |8 +
 drivers/gpu/drm/imx/imx-drm-core.c |  745 
 drivers/gpu/drm/imx/imx-fb.c   |  179 +++
 drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
 drivers/gpu/drm/imx/imx-gem.c  |  343 +
 drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
 drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
 13 files changed, 2363 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/Kconfig
 create mode 100644 drivers/gpu/drm/imx/Makefile
 create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
 create mode 100644 drivers/gpu/drm/imx/imx-fb.c
 create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
 create mode 100644 drivers/gpu/drm/imx/imx-gem.c
 create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
 create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

is still queued, which I don't completely like but at least the
pinning and hw use of the userspace buffer is just temporary and not
able to exist for an indefinite amount of time.

BR,
-R

> Thanks,
> Inki Dae
>
>> So I'm really not sure the best way to move this forward, maybe a very
>> clear set of use cases of where stuff plugs into this, and why dma-buf
>> or some other method isn't sufficient, but I'm having trouble getting
>> past the fact its setting a dangerous precedent.
>>
>> Dave.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

> Those two checks could probably be combined into one (< values || > values)
> for further simplification.

Answer:
Fixed. The new function was just copy-paste, but your suggestion is good.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d3aaeb6..6014413 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3033,6 +3033,24 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+static bool drm_property_change_is_valid(struct drm_property *property,
+__u64 value)
+{
+   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   return false;
+   if (property->flags & DRM_MODE_PROP_RANGE) {
+   if (value < property->values[0] || value > property->values[1])
+   return false;
+   return true;
+   } else {
+   int i;
+   for (i = 0; i < property->num_values; i++)
+   if (property->values[i] == value)
+   return true;
+   return false;
+   }
+}
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -3069,28 +3087,9 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
}
property = obj_to_property(obj);

-   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   if (!drm_property_change_is_valid(property, out_resp->value))
goto out;

-   if (property->flags & DRM_MODE_PROP_RANGE) {
-   if (out_resp->value < property->values[0])
-   goto out;
-
-   if (out_resp->value > property->values[1])
-   goto out;
-   } else {
-   int found = 0;
-   for (i = 0; i < property->num_values; i++) {
-   if (property->values[i] == out_resp->value) {
-   found = 1;
-   break;
-   }
-   }
-   if (!found) {
-   goto out;
-   }
-   }
-
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
if (connector->funcs->dpms)
-- 
1.7.10

No subject

> Please add that to the error message and use printk_once() since we only
> really want to annoy the user the first time.

For each time we see the message, we need to increase the value by 1, so instead
of using printk_once, I just added this information to the message. Anyway, we
shouldn't be seeing this message too many times, since we don't add new
properties that often.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0a22ef8..37bb7ab 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2819,7 +2819,7 @@ void drm_property_destroy(struct drm_device *dev, struct 
drm_property *property)
 }
 EXPORT_SYMBOL(drm_property_destroy);

-int drm_connector_attach_property(struct drm_connector *connector,
+void drm_connector_attach_property(struct drm_connector *connector,
   struct drm_property *property, uint64_t init_val)
 {
int i;
@@ -2828,13 +2828,13 @@ int drm_connector_attach_property(struct drm_connector 
*connector,
if (connector->property_ids[i] == 0) {
connector->property_ids[i] = property->base.id;
connector->property_values[i] = init_val;
-   break;
+   return;
}
}

-   if (i == DRM_CONNECTOR_MAX_PROPERTY)
-   return -EINVAL;
-   return 0;
+   WARN(1, "Failed to attach connector property. Please increase "
+   "DRM_CONNECTOR_MAX_PROPERTY by 1 for each time you see this "
+   "message\n");
 }
 EXPORT_SYMBOL(drm_connector_attach_property);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f35e7ed..036faec 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -910,8 +910,8 @@ extern int drmfb_remove(struct drm_device *dev, struct 
drm_framebuffer *fb);
 extern void drm_crtc_probe_connector_modes(struct drm_device *dev, int maxX, 
int maxY);
 extern bool drm_crtc_in_use(struct drm_crtc *crtc);

-extern int drm_connector_attach_property(struct drm_connector *connector,
- struct drm_property *property, uint64_t 
init_val);
+extern void drm_connector_attach_property(struct drm_connector *connector,
+ struct drm_property *property, 
uint64_t init_val);
 extern struct drm_property *drm_property_create(struct drm_device *dev, int 
flags,
const char *name, int 
num_values);
 extern struct drm_property *drm_property_create_enum(struct drm_device *dev, 
int flags,
-- 
1.7.10

No subject

> 
> Perhaps we could add a debug message here for catch the unhandled types..
> 
This shouldn't happen. The previous checks should eliminate all objects that
don't have properties. The only possibility I can think of is if we add
properties to a new kind of object and forget to include it in the switch...
In this case, we'll still return -EINVAL, which is good.

No subject

> How about adding obj->properties.count to avoid having to count every
> time?
I just blindly followed the connector properties example. But your idea is good,
so I implemented it. Fixed, but in a new patch near the end of the series.
Putting the in the end of the series should make it easier to review IMHO.

> Just add the trailing comma to the last line as well. Otherwise we keep
> on having ugly diffs when new ioctls are added.
Fixed.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 19a289f..b6783f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2875,6 +2875,58 @@ int drm_connector_property_get_value(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_property_get_value);

+void drm_object_attach_property(struct drm_mode_object *obj,
+   struct drm_property *property,
+   uint64_t init_val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == 0) {
+   obj->properties->ids[i] = property->base.id;
+   obj->properties->values[i] = init_val;
+   return;
+   }
+   }
+
+   WARN(1, "Failed to attach object property (type: 0x%x). Please "
+   "increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see "
+   "this message on the same object type.\n", obj->type);
+}
+EXPORT_SYMBOL(drm_object_attach_property);
+
+int drm_object_property_set_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == property->base.id) {
+   obj->properties->values[i] = val;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_set_value);
+
+int drm_object_property_get_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t *val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == property->base.id) {
+   *val = obj->properties->values[i];
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_get_value);
+
 int drm_mode_getproperty_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -3148,6 +3200,136 @@ out:
return ret;
 }

+static int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
+  struct drm_property *property,
+  uint64_t value)
+{
+   int ret = -EINVAL;
+   struct drm_connector *connector = obj_to_connector(obj);
+
+   /* Do DPMS ourselves */
+   if (property == connector->dev->mode_config.dpms_property) {
+   if (connector->funcs->dpms)
+   (*connector->funcs->dpms)(connector, (int)value);
+   ret = 0;
+   } else if (connector->funcs->set_property)
+   ret = connector->funcs->set_property(connector, property, 
value);
+
+   /* store the property value if successful */
+   if (!ret)
+   drm_connector_property_set_value(connector, property, value);
+   return ret;
+}
+
+int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_mode_obj_get_properties *arg = data;
+   struct drm_mode_object *obj;
+   int ret = 0;
+   int i;
+   int copied = 0;
+   int props_count = 0;
+   uint32_t __user *props_ptr;
+   uint64_t __user *prop_values_ptr;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(&dev->mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg->obj_id, arg->obj_type);
+   if (!obj) {
+   ret = -EINVAL;
+   goto out;
+   }
+   if (!obj->properties) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /* Assume [ prop, 0, prop ] won't happen (if we ever delete properties,
+* we need to remove the gap inside the array). */
+   for (props_count = 0; props_count < DRM_OBJECT_MAX_PROPERTY &&
+   obj->properties->ids[props_count] != 0; props_count++)
+   ;
+
+   /* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it. */
+   if ((arg->count_props >= props_count) && props_count) {
+   copied = 0;
+   props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
+   prop_values_ptr = (uint64_t __user *)(unsig

No subject

>
Subject: [PATCH 1/1] =A0=A0=A0 drivers/gpu/drm/i915: Fixed uninitialized=A0variables (warnings).MIME-Version: 1.0Content-Type: text/plain;=
 charset=3DUTF-8Content-Transfer-Encoding: 8bitAs you see, this=
 modifications were really very important because if the remain variable re=
ceives a value lower or equals than 0 from the args->size variable, inde=
ed, a bad behavior could ocurrs.
Let me explain:The variable ret would never be initialized if the f=
unction doesn't enter inside of the loop. So that, the function will re=
turn a strange (undefined) value when it reaches the final.If you&#=
39;ve a better solution or if I commited a mistake in my changes, please ta=
lk me about. I'm sure I'm a newcomer, hehe.
I'm using the GCC: gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)=
Warnings received during make operation:utroz at utrozpc:~/linux$ =
make > make_output=A0=A0=A0 : In function =91i915_gem_pread_ioctl=92=
:drivers/gpu/drm/i915/i915_gem.c:455:21: warning: =91ret=92 may be used=
 uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_gem.c:390:38: note: =91ret=92 was declared heredrivers/gpu/drm/i915/i915_gem.c: In function =91i915_gem_pwrite_ioctl=92:=
drivers/gpu/drm/i915/i915_gem.c:871:21: warning: =91ret=92 may be used =
uninitialized in this function [-Wuninitialized]
drivers/gpu/drm/i915/i915_gem.c:797:38: note: =91ret=92 was declared hereSigned-off-by: Raphael S.Carvalho rsc.utroz at gmail.com>---=A0drivers/gpu/drm/i915/i915_=
gem.c |=A0=A0 12 ++--
=A01 files changed, 10 insertions(+), 2 deletions(-)diff --git a/dr=
ivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.cindex 0d=
1e4b7..b0a0004 100644--- a/drivers/gpu/drm/i915/i915_gem.c+++ b/dri=
vers/gpu/drm/i915/i915_gem.c
@@ -392,6 +392,10 @@ i915_gem_shmem_pread_slow(struct drm_device *dev,=
=A0=A0=A0=A0=A0 user_data =3D (char __user *) (uintptr_t) args->data=
_ptr;=A0=A0=A0=A0 remain =3D args->size;+=A0=A0=A0 if (remain &l=
t;=3D 0) {+=A0=A0=A0 =A0=A0=A0 ret =3D -EINVAL;
+=A0=A0=A0 =A0=A0=A0 goto final;+=A0=A0=A0 }=A0=A0=A0=A0=A0 obj=
_do_bit17_swizzling =3D i915_gem_object_needs_bit17_swizzle(obj);=A0@@ -451,7 +455,7 @@ out:=A0=A0=A0=A0 /* Fixup: Kill any reinstated bac=
king storage pages */=A0=A0=A0=A0 if (obj->madv =3D=3D __I915_MADV_P=
URGED)
=A0=A0=A0=A0 =A0=A0=A0 i915_gem_object_truncate(obj);-+final:=
=A0=A0=A0=A0 return ret;=A0}=A0@@ -799,6 +803,10 @@ i915_gem_sh=
mem_pwrite_slow(struct drm_device *dev,=A0=A0=A0=A0=A0 user_data =
=3D (char __user *) (uintptr_t) args->data_ptr;
=A0=A0=A0=A0 remain =3D args->size;+=A0=A0=A0 if (remain <=3D 0) =
{+=A0=A0=A0 =A0=A0=A0 ret =3D -EINVAL;+=A0=A0=A0 =A0=A0=A0 goto fin=
al;+=A0=A0=A0 }=A0=A0=A0=A0=A0 obj_do_bit17_swizzling =3D i915_=
gem_object_needs_bit17_swizzle(obj);=A0@@ -867,7 +875,7 @@ out:
=A0=A0=A0=A0 =A0=A0=A0 i915_gem_clflush_object(obj);=A0=A0=A0=A0 =A0=A0=
=A0 intel_gtt_chipset_flush();=A0=A0=A0=A0 }-+final:=A0=A0=
=A0=A0 return ret;=A0}=A0-- 1.7.5.4

--14dae934064bfe938b04c007d705--

No subject

than escalating the bug into a random failure.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

No subject

No subject

No subject

No subject

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.

No subject

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.

[no subject]

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.
>From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
>allows it trough range limited flag... obviously limiting by the range.
>From our code:
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
 * - detailed modes from extension blocks
 * - CVT 3-byte code modes
 * - standard timing codes
 * - established timing codes
 * - modes inferred from GTF or CVT range information
 *
 * We get this pretty much right.

Not actually so right... We were inferring just using GTF... not CVT or even 
GTF2.
This patch not just add some common cvt modes but also allows some modes been 
inferred when using gtf2 as well.

Cheers,
Rodrigo.

>From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi 
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
 allows range limited ones trough EDID.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_edid.c   |   37 +-
 drivers/gpu/drm/drm_edid_modes.h |  101 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector 
*connector, struct edid *edid,
return modes;
 }
 
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector->dev;
+
+   for (i = 0; i < drm_num_cvt_inferred_modes; i++) {
+   if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+   newmode = drm_mode_duplicate(dev, 
&drm_cvt_inferred_modes[i]);
+   if (newmode) {
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   }
+
+   return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
-   int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
+   int timing_level = standard_timing_level(closure->edid);
 
-   if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
+   if (data->type == EDID_DETAIL_MONITOR_RANGE)
+   switch (timing_level) {
+   case LEVEL_DMT:
+   break;
+   case LEVEL_GTF:
+   case LEVEL_GTF2:
closure->modes += drm_gtf_modes_for_range(closure->connector,
  closure->edid,
  timing);
+   break;
+   case LEVEL_CVT:
+   closure->modes += drm_cvt_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
+   break;
+   }
 }
 
 static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
 static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
 
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+   /* 640x480@60Hz */
+   { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 23750  640, 664,
+  720, 800, 0, 480, 483, 487, 500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 800x600@60Hz */
+   { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+  912, 1024, 0, 600, 603, 607, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 900x600@60Hz */
+   { DRM_MODE("900x600", DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+  1088, 1216, 0, 600, 603, 609, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x576@60Hz */
+   { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+  1160, 1296, 0, 576, 579, 584, 599, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x768@60Hz */
+   { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+  1176, 1328, 0, 768, 771, 775, 798, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_M

[no subject]

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.
>From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
>allows it trough range limited flag... obviously limiting by the range.
>From our code:
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
 * - detailed modes from extension blocks
 * - CVT 3-byte code modes
 * - standard timing codes
 * - established timing codes
 * - modes inferred from GTF or CVT range information
 *
 * We get this pretty much right.

Not actually so right... We were inferring just using GTF... not CVT or even 
GTF2.
This patch not just add some common cvt modes but also allows some modes been 
inferred when using gtf2 as well.

Cheers,
Rodrigo.

>From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi 
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
 allows range limited ones trough EDID.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_edid.c   |   37 +-
 drivers/gpu/drm/drm_edid_modes.h |  101 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector 
*connector, struct edid *edid,
return modes;
 }
 
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector->dev;
+
+   for (i = 0; i < drm_num_cvt_inferred_modes; i++) {
+   if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+   newmode = drm_mode_duplicate(dev, 
&drm_cvt_inferred_modes[i]);
+   if (newmode) {
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   }
+
+   return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
-   int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
+   int timing_level = standard_timing_level(closure->edid);
 
-   if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
+   if (data->type == EDID_DETAIL_MONITOR_RANGE)
+   switch (timing_level) {
+   case LEVEL_DMT:
+   break;
+   case LEVEL_GTF:
+   case LEVEL_GTF2:
closure->modes += drm_gtf_modes_for_range(closure->connector,
  closure->edid,
  timing);
+   break;
+   case LEVEL_CVT:
+   closure->modes += drm_cvt_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
+   break;
+   }
 }
 
 static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
 static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
 
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+   /* 640x480@60Hz */
+   { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 23750  640, 664,
+  720, 800, 0, 480, 483, 487, 500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 800x600@60Hz */
+   { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+  912, 1024, 0, 600, 603, 607, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 900x600@60Hz */
+   { DRM_MODE("900x600", DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+  1088, 1216, 0, 600, 603, 609, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x576@60Hz */
+   { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+  1160, 1296, 0, 576, 579, 584, 599, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x768@60Hz */
+   { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+  1176, 1328, 0, 768, 771, 775, 798, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_M

No subject

[Benjamin Herrenschmidt]

Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).

This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.

Signed-off-by: Benjamin Herrenschmidt 
---

Please send to Linus asap, without this, it crashes on the G5

 drivers/gpu/drm/nouveau/nouveau_bios.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 637afe7..80963d0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -177,14 +177,15 @@ bios_shadow_pci(struct nvbios *bios)

if (!pci_enable_rom(pdev)) {
void __iomem *rom = pci_map_rom(pdev, &length);
-   if (rom) {
+   if (rom && length) {
bios->data = kmalloc(length, GFP_KERNEL);
if (bios->data) {
memcpy_fromio(bios->data, rom, length);
bios->length = length;
}
-   pci_unmap_rom(pdev, rom);
}
+   if (rom)
+   pci_unmap_rom(pdev, rom);

pci_disable_rom(pdev);
}
-- 
1.7.9.5

No subject

when the corresponding pins are not actually hooked up to anything.  In
these cases, there is no NAK, nor timeout, nor any other indication from
the GMBUS controller that a transaction fails.  The first gmbus
transaction timeout is caught by the "wait_for" timeout, causing the
transition to bit-banging mode for subsequent (failed) attempts.

This might be what was meant by the following note in the GPIO_CTL
description:
  "The registers that control digital display (HDMI/DVI, DisplayPort)
pins should only be utilized if the Port Detected bit in the related
control register is set to 1."
(http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf,
section 2.2.2)

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 73431ed..154fedd 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -380,8 +380,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
 */
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
 10)) {
-   DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
-adapter->name);
+   DRM_ERROR("GMBUS [%s] timed out waiting for idle\n",
+ adapter->name);
ret = -ETIMEDOUT;
}
I915_WRITE(GMBUS0 + reg_offset, 0);
@@ -396,7 +396,7 @@ clear_err:
 */
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
 10))
-   DRM_INFO("GMBUS [%s] timed out after NAK\n", adapter->name);
+   DRM_ERROR("GMBUS [%s] timed out after NAK\n", adapter->name);

/* Toggle the Software Clear Interrupt bit. This has the effect
 * of resetting the GMBUS controller and so clearing the
@@ -421,8 +421,8 @@ clear_err:
goto out;

 timeout:
-   DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin 
%d\n",
-bus->adapter.name, bus->reg0 & 0xff);
+   DRM_ERROR("GMBUS [%s] timed out, falling back to bit banging on pin 
%d\n",
+ bus->adapter.name, bus->reg0 & 0xff);
I915_WRITE(GMBUS0 + reg_offset, 0);

/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-- 
1.7.7.3

No subject

makes me afraid of some weird GTT flushing issue, given the adventures
we had with VT-d on that hardware where we idle the gpu before any GTT
updates. I wonder what would happen if we idled the GPU before any GTT
updates even when VT-d wasn't running...

> The latest thinking on the hibernate issues is kernel one sets up an
> fbcon, hibernate restores the old memory and the GTT still points at
> the pages,
> then something writes to the console and overwrites real memory., just
> a working theory, nobody has proven it yet.

Presumably the resumed kernel will not be able to write to the console
until the i915 driver is running again, at which point it will have
updated all of the GTT entries. And, presumably the booted kernel won't
be writing to the console after it has loaded the resumed kernel memory?

-- 
keith.packard at intel.com

No subject

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry.  And if you use the hwmod device entry,
you have to match the name used for that entry.

Regards,

Andy

No subject

k in return path of radeon_fence_count_emitted" fixes=0Athe problem. Tested=
 on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88.=0A=0A=0AThanks,=0A=0AMik=
ko

No subject

sl-to-tgsi.

BTW in which commit was the new ioctl disabled? I mean, I can understand th=
at if I don't have kernel with support for the new ioctl it breaks the test=
s,
however if the ioctl was disabled later shouldn't be current git working un=
less another regression happened?

> Anyway, sorry, I won't probably help you with this bug anytime soon.

Well, I don't care much for piglit, I just want to make sure r300g don't ge=
t too rusty now when the development has moved to new drivers.

--=20
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
--- You are receiving this mail because: ---
You are the assignee for the bug.=

No subject

disable the output polling during suspend. The following patch seems to
get rid of the problems I'm seeing. Does this look okay to you?

No subject

dangerball: intel_tris.c:128: intel_extend_inline: Assertion 'intel->prim.flush
== intel_flush_inline_primitive' failed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

GPU lockup CP stall for more than 1msec
Jan 23 23:53:54 thoregon kernel: [17121.080137] GPU lockup (waiting
for 0x002080B7 last fence id 0x002080B6)
Jan 23 23:53:54 thoregon kernel: [17121.096334] radeon :07:00.0:
GPU softreset
Jan 23 23:53:54 thoregon kernel: [17121.096341] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 23 23:53:54 thoregon kernel: [17121.096346] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.096351] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.096362] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 23 23:53:54 thoregon kernel: [17121.111386] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 23 23:53:54 thoregon kernel: [17121.127378] radeon :07:00.0:
R_008010_GRBM_STATUS=0x3028
Jan 23 23:53:54 thoregon kernel: [17121.127384] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.127390] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.128393] radeon :07:00.0:
GPU reset succeed
Jan 23 23:53:54 thoregon kernel: [17121.10] [drm] PCIE GART of
512M enabled (table at 0x0004).
Jan 23 23:53:54 thoregon kernel: [17121.133364] radeon :07:00.0: WB enabled
Jan 23 23:53:54 thoregon kernel: [17121.133370] [drm] fence driver on
ring 0 use gpu addr 0x2c00 and cpu addr 0x8803286e5c00
Jan 23 23:53:54 thoregon kernel: [17121.179627] [drm] ring test on 0
succeeded in 1 usecs
Jan 23 23:53:54 thoregon kernel: [17121.179653] [drm] ib test on ring
0 succeeded in 1 usecs

There where no messages about X getting stuck ("blocked for more than
120 seconds"), but after trying to access the system and failing
SysRq+W reported this:
Jan 24 08:08:20 thoregon kernel: [46786.741180] SysRq : Show Blocked State
Jan 24 08:08:20 thoregon kernel: [46786.741190]   task
   PC stack   pid father
Jan 24 08:08:20 thoregon kernel: [46786.741270] X   D
880337d50a00 0  3047   3026 0x0044
Jan 24 08:08:20 thoregon kernel: [46786.741281]  880327eacac0
0086 880327d52e00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741292]  88031be9bfd8
00010a00 88031be9a000 88031be9bfd8
Jan 24 08:08:20 thoregon kernel: [46786.741301]  00010a00
880327eacac0 00010a00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741310] Call Trace:
Jan 24 08:08:20 thoregon kernel: [46786.741326]  []
? schedule_timeout+0x157/0x220
Jan 24 08:08:20 thoregon kernel: [46786.741336]  []
? run_timer_softirq+0x240/0x240
Jan 24 08:08:20 thoregon kernel: [46786.741346]  []
? radeon_fence_wait+0x239/0x3b0
Jan 24 08:08:20 thoregon kernel: [46786.741356]  []
? wake_up_bit+0x40/0x40
Jan 24 08:08:20 thoregon kernel: [46786.741364]  []
? radeon_ib_get+0x257/0x2e0
Jan 24 08:08:20 thoregon kernel: [46786.741372]  []
? radeon_cs_ioctl+0x27a/0x4d0
Jan 24 08:08:20 thoregon kernel: [46786.741381]  []
? drm_ioctl+0x3e4/0x490
Jan 24 08:08:20 thoregon kernel: [46786.741389]  []
? radeon_cs_finish_pages+0xa0/0xa0
Jan 24 08:08:20 thoregon kernel: [46786.741398]  []
? do_page_fault+0x199/0x420
Jan 24 08:08:20 thoregon kernel: [46786.741406]  []
? mmap_region+0x1dc/0x570
Jan 24 08:08:20 thoregon kernel: [46786.741414]  []
? do_vfs_ioctl+0x96/0x4e0
Jan 24 08:08:20 thoregon kernel: [46786.741422]  []
? sys_ioctl+0x49/0x90
Jan 24 08:08:20 thoregon kernel: [46786.741430]  []
? system_call_fastpath+0x16/0x1b

I did search my logs for more GPU lockups after noting that this also
happened with 3.2.
The first lockup in my logs occurred on Nov 4 under 3.1. But until
3.3-rc1 X always was able to resume normal operations.

My best guess for the cause of the GPU lockups seems to be the upgrade
from xf86-video-ati-6.14.2 to 6.14.3, but 3.3-rc1 seems to have an
independent bug that prevents X to recover from a GPU lockup/reset.

>> Of course it would be best if we did not lockup in the first place.
>
> Not sure if this is important: I also upgraded to mesa 8.0-rc1 before
> the first hang, but after switching back to 3.2 but still using mesa
> 8.0 I did not have any problems.
> Except the KDE desktop effects there should not have been any OpenGL
> programs running.
> The screen saver itself is just turning the screens off via the KDE
> power profile.
>
> I will report again, when I succeeded in triggering the GPU lockup again...
>
> Torsten

No subject

/usr/sbin/run-crons && /usr/sbin/run-crons)
Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0:
GPU lockup CP stall for more than 1msec
Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting
for 0x0003F1F2 last fence id 0x0003F1F1)
Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0:
GPU softreset
Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0:
GPU lockup CP stall for more than 1msec
Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting
for 0x0003F1F2 last fence id 0x0003F1F1)
Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0:
GPU softreset
Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.636359] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 21 19:39:41 thoregon kernel: [ 6364.636370] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 21 19:39:41 thoregon kernel: [ 6364.651219] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 21 19:39:41 thoregon kernel: [ 6364.667212] radeon :07:00.0:
R_008010_GRBM_STATUS=0x3028
Jan 21 19:39:41 thoregon kernel: [ 6364.667217] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.667223] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 21 19:39:41 thoregon kernel: [ 6364.668226] radeon :07:00.0:
GPU reset succeed
Jan 21 19:39:41 thoregon kernel: [ 6364.673142] [drm] PCIE GART of
512M enabled (table at 0x0004).
Jan 21 19:39:41 thoregon kernel: [ 6364.673177] radeon :07:00.0: WB enabled
Jan 21 19:39:41 thoregon kernel: [ 6364.673184] [drm] fence driver on
ring 0 use gpu addr 0x2c00 and cpu addr 0x880328636c00
Jan 21 19:39:41 thoregon kernel: [ 6364.719445] [drm] ring test on 0
succeeded in 1 usecs
Jan 21 19:40:01 thoregon cron[3975]: (root) CMD (test -x
/usr/sbin/run-crons && /usr/sbin/run-crons)
Jan 21 19:43:37 thoregon kernel: [ 6600.390150] INFO: task X:3098
blocked for more than 120 seconds.
Jan 21 19:43:37 thoregon kernel: [ 6600.390157] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 21 19:43:37 thoregon kernel: [ 6600.390163] X   D
880337d50a00 0  3098   3077 0x0040
Jan 21 19:43:37 thoregon kernel: [ 6600.390174]  88031df15080
0086 8802f5087300 00010a00
Jan 21 19:43:37 thoregon kernel: [ 6600.390185]  88031bf79fd8
00010a00 88031bf78000 88031bf79fd8
Jan 21 19:43:37 thoregon kernel: [ 6600.390194]  00010a00
88031df15080 00010a00 00010a00
Jan 21 19:43:37 thoregon kernel: [ 6600.390203] Call Trace:
Jan 21 19:43:37 thoregon kernel: [ 6600.390219]  []
? __mutex_lock_slowpath+0xc8/0x140
Jan 21 19:43:37 thoregon kernel: [ 6600.390230]  []
? mutex_lock+0x1a/0x40
Jan 21 19:43:37 thoregon kernel: [ 6600.390239]  []
? radeon_ib_get+0x52/0x230
Jan 21 19:43:37 thoregon kernel: [ 6600.390249]  []
? r600_ib_test+0x5a/0x300
Jan 21 19:43:37 thoregon kernel: [ 6600.390258]  []
? rv770_startup+0xf7e/0x1590
Jan 21 19:43:37 thoregon kernel: [ 6600.390267]  []
? rv770_resume+0x2c/0x90
Jan 21 19:43:37 thoregon kernel: [ 6600.390275]  []
? radeon_gpu_reset+0x11e/0x160
Jan 21 19:43:37 thoregon kernel: [ 6600.390284]  []
? radeon_fence_wait+0x363/0x3b0
Jan 21 19:43:37 thoregon kernel: [ 6600.390293]  []
? wake_up_bit+0x40/0x40
Jan 21 19:43:37 thoregon kernel: [ 6600.390301]  []
? radeon_ib_get+0x1e7/0x230
Jan 21 19:43:37 thoregon kernel: [ 6600.390310]  []
? radeon_cs_ioctl+0x27a/0x4d0
Jan 21 19:43:37 thoregon kernel: [ 6600.390319]  []
? drm_ioctl+0x3e4/0x490
Jan 21 19:43:37 thoregon kernel: [ 6600.390327]  []
? radeon_cs_finish_pages+0xa0/0xa0
Jan 21 19:43:37 thoregon kernel: [ 6600.390336]  []
? do_page_fault+0x199/0x420
Jan 21 19:43:37 thoregon kernel: [ 6600.390344]  []
? mmap_region+0x1dc/0x570
Jan 21 19:43:37 thoregon kernel: [ 6600.390352]  []
? do_vfs_ioctl+0x96/0x4e0
Jan 21 19:43:37 thoregon kernel: [ 6600.390359]  []
? __schedule+0x28c/0x630
Jan 21 19:43:37 thoregon kernel: [ 6600.390366]  []
? sys_ioctl+0x49/0x90
Jan 21 19:43:37 thoregon kernel: [ 6600.390375]  []
? system_call_fastpath+0x16/0x1b
Jan 21 19:45:08 thoregon kernel: [ 6691.864440] SysRq : Emergency Sync
Jan 21 19:45:08 thoregon kernel: [ 6691.864838] Emergency Sync complete
Jan 21 19:45:14 thoregon kernel: [ 6697.476112] SysRq : Emergency Remount R/O
Jan 21 19:46:33 thoregon kernel: [0.00] Linux version
3.3.0-rc1 (root at thoregon) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0,
pie-0.4.6) ) #1 SMP Fri Jan 20 09:54:26 CET 2012

I did not have any trouble with 3.2 or earlier kernel,

No subject

symbol is exported without explicit consent of the original author 
(regardless of what we think about GPL/proprietary modules covtroversy). 
So if NVidia needs to link DMA buffer sharing against their proprietary 
driver, they should have explicit permission from the original author to 
turn its symbols into EXPORT_SYMBOL.

-- Ilija

No subject

this sort of thing, nouveau is a good solution its just not going to
beat the binary driver in a lot of ways, just not sure whether I care
enough yet.

Dave.

No subject

However softpipe does not have polygons disappearing at all, so it would appear
to be a r300g problem. PrBoom uses GL_TRIANGLE_STRIPs to draw the walls, so
this is probably unrelated to this bug.

And another thing I noticed fixed. The OGLSB4th Edition chapter 16 vertexblend
draws the shiny light correctly (before it was slightly garbled, it would be a
bright white but with distorted red/white/pink in the middle).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

Dec 11 17:16:36 nf7 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 11 17:16:37 nf7 kernel: [drm] radeon kernel modesetting enabled.
Dec 11 17:16:37 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI
19 (level, high) -> IRQ 19
Dec 11 17:16:37 nf7 kernel: [drm] initializing kernel modesetting (RV670
0x1002:0x9515 0x174B:0x0028).
Dec 11 17:16:37 nf7 kernel: [drm] register mmio base: 0xE100
Dec 11 17:16:37 nf7 kernel: [drm] register mmio size: 65536
Dec 11 17:16:37 nf7 kernel: ATOM BIOS: 
Dec 11 17:16:37 nf7 kernel: [drm] AGP mode requested: 8
Dec 11 17:16:37 nf7 kernel: agpgart-nvidia :00:00.0: AGP 3.0 bridge
Dec 11 17:16:37 nf7 kernel: agpgart-nvidia :00:00.0: putting AGP V3 device
into 8x mode
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: putting AGP V3 device into 8x
mode
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: GTT: 256M 0xC000 -
0xCFFF
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: VRAM: 512M 0xA000 -
0xBFFF (512M used)
Dec 11 17:16:37 nf7 kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Dec 11 17:16:37 nf7 kernel: [drm] RAM width 256bits DDR
Dec 11 17:16:37 nf7 kernel: [TTM] Zone  kernel: Available graphics memory:
451408 kiB.
Dec 11 17:16:37 nf7 kernel: [TTM] Initializing pool allocator.
Dec 11 17:16:37 nf7 kernel: [drm] radeon: 512M of VRAM memory ready
Dec 11 17:16:37 nf7 kernel: [drm] radeon: 256M of GTT memory ready.
Dec 11 17:16:37 nf7 kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Dec 11 17:16:37 nf7 kernel: [drm] Driver supports precise vblank timestamp
query.
Dec 11 17:16:37 nf7 kernel: [drm] radeon: irq initialized.
Dec 11 17:16:37 nf7 kernel: [drm] GART: num cpu pages 65536, num gpu pages
65536
Dec 11 17:16:37 nf7 kernel: [drm] Loading RV670 Microcode
Dec 11 17:16:37 nf7 kernel: BUG: unable to handle kernel NULL pointer
dereference at   (null)
Dec 11 17:16:37 nf7 kernel: IP: [] radeon_ttm_tt_populate+0xb0/0x160
[radeon]
Dec 11 17:16:37 nf7 kernel: *pde =  
Dec 11 17:16:37 nf7 kernel: Oops: 0002 [#1] PREEMPT 
Dec 11 17:16:37 nf7 kernel: Modules linked in: radeon(+) ttm drm_kms_helper drm
i2c_algo_bit i2c_core cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit
softcursor fb fbdev ehci_hcd nvidia_agp agpgart ohci_hcd usbhid usbcore
usb_common snd_intel8x0 snd_ac97_codec ac97_bus forcedeth
Dec 11 17:16:37 nf7 kernel: 
Dec 11 17:16:37 nf7 kernel: Pid: 2313, comm: modprobe Not tainted
3.2.0-rc1-10801-g32faa34 #1/NF7-S/NF7 (nVidia-nForce2)
Dec 11 17:16:37 nf7 kernel: EIP: 0060:[] EFLAGS: 00010202 CPU: 0
Dec 11 17:16:37 nf7 kernel: EIP is at radeon_ttm_tt_populate+0xb0/0x160
[radeon]
Dec 11 17:16:37 nf7 kernel: EAX: 3311c000 EBX: c14ec4c0 ECX:  EDX:

Dec 11 17:16:37 nf7 kernel: ESI:  EDI: f306cd20 EBP: f60e7bb0 ESP:
f60e7b7c
Dec 11 17:16:37 nf7 kernel:  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
Dec 11 17:16:37 nf7 kernel: Process modprobe (pid: 2313, ti=f60e6000
task=f7310290 task.ti=f60e6000)
Dec 11 17:16:37 nf7 kernel: Stack:
Dec 11 17:16:37 nf7 kernel:  1000    
f696e000 f60e7bf8 
Dec 11 17:16:37 nf7 kernel:  f694882c f8b6ff0e f306cd20 f60e7c1c f696e44c
f60e7bc0 f8b6fcab f694882c
Dec 11 17:16:37 nf7 kernel:   f60e7bf8 f8b70fb7 f696e43c f696e494
f8010114 f6948860 
Dec 11 17:16:37 nf7 kernel: Call Trace:
Dec 11 17:16:37 nf7 kernel:  [] ?
ttm_tt_set_placement_caching+0xe/0x1c0 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_tt_bind+0x3b/0x60 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_handle_move_mem+0x2e7/0x320
[ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_move_buffer+0x105/0x120 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ?
ttm_mem_global_alloc_zone+0xc4/0x150 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_validate+0xa5/0x150 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_init+0x2c2/0x3b0 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] radeon_bo_create+0x1ac/0x2b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] ? radeon_bo_create+0x2b0/0x2b0
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_wb_init+0x17d/0x1b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] r600_startup+0x27a/0x7b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] ?
radeon_gart_table_vram_alloc+0x4b/0x60 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] r600_init+0x12f/0x280 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_device_init+0x308/0x4f0
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] ? radeon_combios_fini+0x10/0x10
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_driver_load_kms+0x84/0x110
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] drm_get_pci_dev+0x141/0x250 [drm]
Dec 11 17:16:37 nf7 kernel:  [] ? kmem_cache_alloc_trace+0x3f/0x120
Dec 11 17:16:37 nf7 kernel:  [] ? sysfs_do_create_link+0x14e/0x1c0
Dec 11 17:16:37 nf7 kernel:  [] radeon_pci_probe+0x85/0xb8 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] local_pci_probe+0x13/0x20
Dec 11 17:16:37 nf7 kernel:  [] pci_device_probe+0x5f/0x90
Dec 11 17:16:37 nf7 kernel:  [] driver_probe_device+0xfe/0x180

No subject

Windows.

There are only two physical keys:
 - power-on button
 - "keyboard"-labeled button, which seems to do nothing
   hardware-related; it triggers an event caught up by acer_wmi.
   I think all it does is telling the OS: "hey, pull up the software
   virtual keyboard on the second display".

> >  - there are a some unhandled WMI events logged from the acer-wmi
> >module [3] when closing the lid, opening it, and most importantly,
> >when the (main) screen is turned on or off by DPMS.
> > 
> 
> I will look at your dsdt and log from acer-wmi then try to improve
> acer-wmi.

Thanks a lot!

> > What do you think? I haven't really succeeded in nailing the source of
> > the issue down, but here are a few possibilities I'm thinking of:
> > 
> >  - the driver is not aware it can drive two LVDS displays (not very
> >likely, and it has worked once, see above)
> > 
> >  - there is some kind of switch that is able to turn the second screen
> >on or off (I'm thinking of something like rfkill). If so, it looks
> >like something non-standard and undocumented. This would explain
> >the WMI events (see the last note above)
> > 
> 
> What's the behavior of Windows?

I meant an internal switch that would be controlled by GPIO or
such. It doesn't seem very likely though...

> >  - buggy ACPI implementation. I tried to extract then recompile the
> >DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth
> >noticing is that line in dmesg:
> > "pci:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 
> > 0x1d"
> > 
> > 
> > The Archlinux userland is:
> >  - libdrm 2.4.27
> >  - xorg-server 1.11.2
> >  - intel-dri 7.11.1
> >  - xf86-video-intel 2.17.0
> > 
> > 
> > Please let me know if there are any other details I should provide.
> > Regards,
> > Baptiste
> > 
> > Attachments:
> > [1] dmesg-DSM-functions.log - drm errors when booting normally
> > [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline
> > [3] acer_wmi.log - WMI events that land in dmesg
> > [4] dsdt - /sys/firmware/acpi/tables/DSDT
> 
> Please also attached on dmidecode log.

See [3] for dmidecode, I've also provided the dsdt [4] again.
Here is also everything related to ACPI in dmesg [5].

> Thank's a lot!
> Joey Lee

Let me know if there's anything else I can provide,
Baptiste

[1] http://lists.freedesktop.org/archives/intel-gfx/2010-October/008339.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=29821
[3] http://zorun.tonbnc.fr/lkml/dmidecode
[4] http://zorun.tonbnc.fr/lkml/dsdt
[5] http://zorn.tonbnc.fr/lkml/dmesg-acpi.log

No subject

start_kernel
|-> setup_arch
|-> x86_init.oem.arch_setup = xen_arch_setup

|-> check_bugs
|-> identify_boot_cpu
|-> identify_cpu
|-> select_idle_routine


so xen_arch_setup will set pm_idle and select_idle_routine will honour
it. I'm being told this is run either in the dom0 or the paravirt guest
and if so, I don't see any issue with this for baremetal. So you can
have my ACK provided this is tested on baremetal too.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

No subject

allocating request. Though, it's unlikely cause if request is NULL
then BUG_ON will be hit in i915_add_request(). So, to unify the callee
uses of i915_add_request(), I'm proposing the following patch. Please
let me know what do you guys think. If you guys agree, I can sent a
formal patch.

Index: work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
===
--- work.orig/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
+++ work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
@@ -1736,8 +1736,6 @@ i915_add_request(struct intel_ring_buffe
int was_empty;
int ret;

-   BUG_ON(request == NULL);
-
ret = ring->add_request(ring, &seqno);
if (ret)
return ret;
@@ -2002,9 +2000,11 @@ i915_gem_retire_work_handler(struct work
ret = i915_gem_flush_ring(ring,
  0, I915_GEM_GPU_DOMAINS);
request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (ret || request == NULL ||
-   i915_add_request(ring, NULL, request))
-   kfree(request);
+   if (request) {
+   ret = i915_add_request(ring, NULL, request);
+   if (ret)
+   kfree(request);
+   }
}

idle &= list_empty(&ring->request_list);


Thanks,
Rakib

No subject

are looking for. I recognize that it disrupts your current views/plans on 
how this should be done, but I do want to work with you to find a suitable 
middle ground that covers most of the possiblities.

In case you are looking at my code to follow the above-described 
scenarios, please make sure you pull the latest stuff from my github 
repository. I have been pushing new stuff since my original annoucement.


> I still foresee problems with tiling, we generally don't encourage
> accel code to live in the kernel, and you'll really want a
> tiled->untiled blit for this thing,

Accel code should not go into the kernel (that I fully agree) and there is 
nothing here that would behove us to do so. Restricting my comments to 
Radeon GPU (which is the only one that I know well enough), shaders for 
blit copy live in the kernel and irrespective of VCRTCM work. I rely on 
them to move the frame buffer out of VRAM to CTD device but I don't add 
any additional features.

Now for detiling, I think that it should be the responsibility of the 
receiving CTD device, not the GPU pushing the data (Alan mentioned that 
during the initial set of comments, and although I didn't say anything to 
it that has been my view as well).

Even if you wanted to use GPU for detiling (which I'll explain shortly why 
you should not), it would not require any new accel code in the kernel. It 
would merely require one bit flip in the setup of blit copy that already 
lives in the kernel.

However, de-tiling in GPU is a bad idea for two reasons. I tried to do 
that just as an experiment on Radeon GPUs and watched with the PCI Express 
analyzer what happens on the bus (yeah, I have some "heavy weapons" in my 
lab). Normally a tile is a continuous array of memory locations in VRAM. 
If blit-copy function is told to assume tiled source and linear 
destination (de-tiling) it will read a continuous set of addresses in 
VRAM, but then scatter 8 rows of 8 pixels each on non-contignuous set of 
addresses of the destination. If the destination is the PCI-Express bus, 
it will result in 8 32-byte write transactions instead of 2 128-byte 
transactions per each tile. That will choke the throughput of the bus 
right there.

BTW, this is the crux of the blit-copy performance improvement that you 
got from me back in October. Since blit-copy deals with copying a linear 
array, playing with tiled/non-tiled bits only affects the order in which 
addresses are accessed, so the trick was to get rid of short PCIe 
transactions and also shape up linear to rectangle mapping to make address 
pattern more friendly for the host.


> also for Intel GPUs where you have
> UMA, would you read from the UMA.
>

Yes the read would be from UMA. I have not yet looked at Intel GPUs in 
detail, so I don't have an answer for you on what problems would pop up 
and how to solve them, but I'll be glad to revisit the Intel discussion 
once I do some homework.

Some initial thoughts is that frame buffer in Intel are at the end of the 
day pages in the system memory, so anyone/anything can get to them if they 
are correctly mapped.


> It also doesn't solve the optimus GPU problem in any useful fashion,
> since it can't deal with all the use cases, so we still have to write
> an alternate solution that can deal with them, so we just end up with
> two answers.
>

Can you elaborate on some specific use cases that are of your concern? I 
have had this case in mind and I think I can make it work. First I would 
have to add CTD functionality to Intel driver. That should be 
straightforward. Once I get there, I'll be ready to experiment and we'll 
probably be in better position to discuss the specifics then (i.e. when we 
have something working to compare with what you did in PRIME experiemnt), 
but it would be good to know your specific concerns early.


thanks,

Ilija

No subject

When the root cause will be discovered, we should allow both of course. But
so far, all the attempts on this weren't successful.

-- 
Eugeni Dodonov


--bcaec54306ded2a5b704b258e725
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 18:15, Matthew Garrett <=
span dir=3D"ltr">mjg at 
redhat.com&g=
t; wrote:

On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard w=
rote:

> + =A0 =A0 /*
> + =A0 =A0 =A0* Only enable RC6 if all dma remapping is disabled, or if=

> + =A0 =A0 =A0* there's no iommu present in the machine.
> + =A0 =A0 =A0*/
> + =A0 =A0 if (INTEL_INFO(dev)->gen =3D=3D 6)
> + =A0 =A0 =A0 =A0 =A0 =A0 return no_iommu || dmar_disabled;

So the user has to choose between 5W of power saving or having dmar? =
And
we default to giving them dmar?From the latest invest=
igations, it is either this, or random gpu hangs and crashes when both are =
enabled :(.When the root cause will be discovered, we should allow =
both of course. But so far, all the attempts on this weren't successful=
.

-- Eugeni Dodonovhttp://eugeni.dodonov.net/"=
 target=3D"_blank">

--bcaec54306ded2a5b704b258e725--

No subject

some other method before passing the frame off to the overlay.

Rather disappointing, and seemingly not of too much use.  But, I'd like
to expose what functionality there is in any case.

Ben.

> 
> v2: fix ABI of get_plane - move format_type_ptr to the end
> 
> Acked-by: Alan Cox 
> Reviewed-by: Rob Clark 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/drm_crtc.c |  257 
> +++-
>  drivers/gpu/drm/drm_drv.c  |3 +
>  include/drm/drm.h  |3 +
>  include/drm/drm_crtc.h |   75 +-
>  include/drm/drm_mode.h |   33 ++
>  5 files changed, 368 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fe738f0..804ef12 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
>   struct drm_device *dev = fb->dev;
>   struct drm_crtc *crtc;
> + struct drm_plane *plane;
>   struct drm_mode_set set;
>   int ret;
>  
> @@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>   }
>   }
>  
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->fb == fb) {
> + /* should turn off the crtc */
> + ret = plane->funcs->disable_plane(plane);
> + if (ret)
> + DRM_ERROR("failed to disable plane with busy 
> fb\n");
> + }
> + }
> +
>   drm_mode_object_put(dev, &fb->base);
>   list_del(&fb->head);
>   dev->mode_config.num_fb--;
> @@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
>  
> +int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> +unsigned long possible_crtcs,
> +const struct drm_plane_funcs *funcs,
> +uint32_t *formats, uint32_t format_count)
> +{
> + mutex_lock(&dev->mode_config.mutex);
> +
> + plane->dev = dev;
> + drm_mode_object_get(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> + plane->funcs = funcs;
> + plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> +   GFP_KERNEL);
> + if (!plane->format_types) {
> + DRM_DEBUG_KMS("out of memory when allocating plane\n");
> + drm_mode_object_put(dev, &plane->base);
> + return -ENOMEM;
> + }
> +
> + memcpy(plane->format_types, formats, format_count);
> + plane->format_count = format_count;
> + plane->possible_crtcs = possible_crtcs;
> +
> + list_add_tail(&plane->head, &dev->mode_config.plane_list);
> + dev->mode_config.num_plane++;
> +
> + mutex_unlock(&dev->mode_config.mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_init);
> +
> +void drm_plane_cleanup(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + kfree(plane->format_types);
> + drm_mode_object_put(dev, &plane->base);
> + list_del(&plane->head);
> + dev->mode_config.num_plane--;
> + mutex_unlock(&dev->mode_config.mutex);
> +}
> +EXPORT_SYMBOL(drm_plane_cleanup);
> +
>  /**
>   * drm_mode_create - create a new display mode
>   * @dev: DRM device
> @@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
>   INIT_LIST_HEAD(&dev->mode_config.encoder_list);
>   INIT_LIST_HEAD(&dev->mode_config.property_list);
>   INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
> + INIT_LIST_HEAD(&dev->mode_config.plane_list);
>   idr_init(&dev->mode_config.crtc_idr);
>  
>   mutex_lock(&dev->mode_config.mutex);
> @@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   struct drm_encoder *encoder, *enct;
>   struct drm_framebuffer *fb, *fbt;
>   struct drm_property *property, *pt;
> + struct drm_plane *plane, *plt;
>  
>   list_for_each_entry_safe(encoder, enct, &dev->mode_config.encoder_list,
>head) {
> @@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   crtc->funcs->destroy(crtc);
>   }
>  
> + list_for_each_entry_safe(plane, plt, &dev->mode_config.plane_list,
> +  head) {
> + plane->funcs->destroy(plane);
> + }
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>  
> @@ -1466,6 +1526,197 @@ out:
>  }
>  
>  /**
> + * drm_mode_getplane_res - get plane info
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
> + *
> + * Return an plane count and set of IDs.
> + */
> +int drm_mode_getplane_res(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_get_plane_res *plane_resp = data;
> + struct drm

No subject

be -EREMOTEIO, which could be caused by transmission error so it should be
retried.

-- 
Eugeni Dodonov


--bcaec51f8fc3b70e6504af85018a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2011 at 18:41, Keith Packard keithp at 
keithp.com> wrote:

On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov eugeni.dodonov at 
intel.com> =
wrote:

> + =A0 =A0 =A0 =A0 =A0 =A0 if (ret =3D=3D -ENXIO) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DRM_DEBUG_KMS("drm: ski=
pping non-existent adapter %s\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 adapter->name);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> + =A0 =A0 =A0 =A0 =A0 =A0 }

This seems good to me; are there additional error values which should=

also be considered fatal and not subject to retry?From what I've checked, the other return error value in this context c=
ould be -EREMOTEIO, which could be caused by transmission error so it shoul=
d be retried.

=A0-- Eugeni Dodonovhttp://eugeni.dodonov.net/"; =
target=3D"_blank">

--bcaec51f8fc3b70e6504af85018a--

No subject

install libtxc_dxtn

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
evict flags, then i guess it got evicted on first bo allocation which
is strange, maybe first bo has some lpfn constraint.

>> > =A0 =A0 =A0 =A0Second question I have is how are monochrome cursor ima=
ges
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> You can hide the cursor limitation from userspace and pretend supporting
>> rgb cursor.
>
> So just return -ENXIO in that case.

No, so far there is no format specification for cursor, so userspace
can send monochrome or you can accept rgb from userspace and convert
to monochrome inside the kernel, but i think it's better to just
assume userspace sends you monochrome.

Cheers,
Jerome

No subject

[Inki Dae]

Hi, Dave.



I am sending a mail I wonder where are we on this. I had sent DRM Driver
patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any
comments from you.



You can refer to these patches I sent from links below.

v1: < https://lwn.net/Articles/454380/ >

v2: < http://www.spinics.net/lists/kernel/msg1224275.html >

v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >

v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >

v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >



and also you can refer to our working repository below.

< http://git.infradead.org/users/kmpark/linux-2.6-samsung >

Branch name : dev/samsung-drm



If there are any problems regarding our driver then please give me your
comments or advices so that we are going to prepare next patch; otherwise we
wish our driver be applied to mainline.



Thanks,

Inki Dae.

-- next part --
An HTML attachment was scrubbed...
URL: 

[no subject]

[Inki Dae]

Hi, Dave.

 

I am sending a mail I wonder where are we on this. I had sent DRM Driver
patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any
comments from you.

 

You can refer to these patches I sent from links below.

v1: < https://lwn.net/Articles/454380/ >

v2: < http://www.spinics.net/lists/kernel/msg1224275.html >

v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >

v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >

v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >

 

and also you can refer to our working repository below.

< http://git.infradead.org/users/kmpark/linux-2.6-samsung >

Branch name : dev/samsung-drm

 

If there are any problems regarding our driver then please give me your
comments or advices so that we are going to prepare next patch; otherwise we
wish our driver be applied to mainline.

 

Thanks,

Inki Dae.

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

No subject

Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_drv.h |1 -
 drivers/gpu/drm/i915/intel_dp.c |   59 --
 2 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
-   int panel_t3, panel_t12;

struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fbc19e4..7ebbdff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+   int panel_power_up_delay;
+   int panel_power_down_delay;
 };

 /**
@@ -838,7 +840,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 pp;
+   u32 pp, pp_status;

if (!is_edp(intel_dp))
return;
@@ -847,10 +849,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 * If the panel wasn't on, make sure there's not a currently
 * active PP sequence before enabling AUX VDD.
 */
-   if (!(I915_READ(PCH_PP_STATUS) & PP_ON)) {
-   DRM_DEBUG_KMS("eDP VDD was not on\n");
-   msleep(dev_priv->panel_t3);
-   }
+   pp_status = I915_READ(PCH_PP_STATUS);

pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -860,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   if (!(pp_status & PP_ON)) {
+   msleep(intel_dp->panel_power_up_delay);
+   DRM_DEBUG_KMS("eDP VDD was not on\n");
+   }
 }

 static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -880,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);

/* Make sure sequencer is idle before allowing subsequent activity */
-   msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   msleep(intel_dp->panel_power_down_delay);
 }

 /* Returns true if the panel was already on when called */
@@ -921,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp 
*intel_dp)
return false;
 }

-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
 {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -939,6 +942,7 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
pp &= ~POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+   msleep(intel_dp->panel_power_down_delay);

if (wait_for((I915_READ(PCH_PP_STATUS) & idle_off_mask) == 0, 5000))
DRM_ERROR("panel off wait timed out: 0x%08x\n",
@@ -1044,7 +1048,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder)

if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
-   ironlake_edp_panel_off(dev);
+   ironlake_edp_panel_off(encoder);
if (!is_pch_edp(intel_

No subject

> Please report at bugs.freedesktop.org
This also happens with the wine tests. I wanted to add this on the Mesa bug,
but I don't have my password at the moment(different keychain). For the Mesa
devs debugging the tests may be easier than debugging NFS:MW.

(see: http://bugs.winehq.org/show_bug.cgi?id=22459#c6)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

No subject

Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_drv.h |1 -
 drivers/gpu/drm/i915/intel_dp.c |   56 --
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
-   int panel_t3, panel_t12;

struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41b1e05..f1d6105 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+   int panel_power_up_delay;
+   int panel_power_down_delay;
 };

 /**
@@ -848,10 +850,6 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 * active PP sequence before enabling AUX VDD.
 */
pp_status = I915_READ(PCH_PP_STATUS);
-   if (!(pp_status & PP_ON)) {
-   DRM_DEBUG_KMS("eDP VDD was not on\n");
-   msleep(dev_priv->panel_t3);
-   }

pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -861,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   if (!(pp_status & PP_ON)) {
+   msleep(intel_dp->panel_power_up_delay);
+   DRM_DEBUG_KMS("eDP VDD was not on\n");
+   }
 }

 static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -881,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);

/* Make sure sequencer is idle before allowing subsequent activity */
-   msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   msleep(intel_dp->panel_power_down_delay);
 }

 /* Returns true if the panel was already on when called */
@@ -922,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp 
*intel_dp)
return false;
 }

-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
 {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -940,6 +942,7 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
pp &= ~POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+   msleep(intel_dp->panel_power_down_delay);

if (wait_for((I915_READ(PCH_PP_STATUS) & idle_off_mask) == 0, 5000))
DRM_ERROR("panel off wait timed out: 0x%08x\n",
@@ -1045,7 +1048,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder)

if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
-   ironlake_edp_panel_off(dev);
+   ironlake_edp_panel_off(encoder);
if (!is_pch_edp(intel_dp))
ironlake_edp_pll_on(encoder);
else
@@ -1088,7 +1091,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
if (is_edp(intel_dp))
-   ironlake_edp_panel_off(dev);
+   ironlake_edp_panel_off(e

No subject

legacy interface provided on top of DRM/KMS driver mostly via helper
functions.  With this approach, you get the richer KMS API (and all
the related plumbing for hotplug, EDID parsing, multi-head support,
flipping, etc) for userspace stuff that needs that, but can keep the
fbdev userspace interface for legacy apps.  It is the best of both
worlds.  There isn't really any good reason to propagate standalone
fbdev driver anymore.

BR,
-R

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

No subject

bisecting brought me to commit
288d5abec8314ae50fe6692f324b0444acae8486. Reverting seems to work as
microcode is loaded with compiled in firmware and radeon kms driver.


That's

commit 288d5abec8314ae50fe6692f324b0444acae8486
Author: Linus Torvalds 
Date:   Wed Aug 3 22:03:29 2011 -1000

Boot up with usermodehelper disabled

--=20
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=3Demail
--- You are receiving this mail because: ---
You are watching the assignee of the bug.=

No subject

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.