date:20130821

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

--- Comment #4 from Tom Stellard  ---
(In reply to comment #3)
> Got a different backtrace with:
> * OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
> * OpenGL version string: 2.1 Mesa 9.3.0-devel (git-f53b634)
> * LLVM-3.4svn r188604
> 

This should be fixed by:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130819/185162.html

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

[Bug 68389] [radeonsi]Black screen in unigine-tropics

 7ms
Loading "core/properties/unigine.prop" 2 properties 0ms
Unigine~# world_load tropics
Loading "tropics.cpp" 219ms
Loading "demos/tropics/tropics.mat" 40 materials 769ms
Loading "tropics.world" 10461ms
Unigine~# render_hdr 1 && render_srgb 0 && render_restart
Release
Unigine~# render_stereo 0 && render_restart
Tropics: SIInstrInfo.cpp:94: virtual void
llvm::SIInstrInfo::copyPhysReg(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned int,
bool) const: Assertion `AMDGPU::SReg_32RegClass.contains(SrcReg)' failed.
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'tgsi'.
1.  Running pass 'Post-RA pseudo instruction expansion pass' on function
'@main'
./1024x768_windowed.sh : ligne 13 :  9548 Abandon (core
dumped)./bin/Tropics -video_app opengl -sound_app openal -extern_define RELEASE
-system_script tropics/unigine.cpp -engine_config ../data/unigine.cfg
-data_path ../ -video_fullscreen 0 -video_mode -1 -video_width 1024
-video_height 768

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

[Bug 68391] [radeonsi] Crash unigine-sanctuary

e_water.mat" 1 material 63 shaders 14ms
Loading "core/materials/unigine_skies.mat" 1 material 19 shaders 19ms
Loading "core/materials/unigine_decals.mat" 1 material 69 shaders 8ms
Loading "core/properties/unigine.prop" 2 properties 1ms
Unigine~# world_load sanctuary
Loading "sanctuary.cpp" 74ms
Loading "sanctuary/sanctuary.mat" 54 materials 411ms
Loading "sanctuary.world" 9211ms
Unigine~# render_hdr 0 && render_srgb 0 && render_restart
Unigine~# render_stereo 0 && render_restart
Sanctuary: AMDGPUInstrInfo.cpp:109: virtual void
llvm::AMDGPUInstrInfo::storeRegToStackSlot(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock::iterator, unsigned int, bool, int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterInfo*) const: Assertion
`!"Not Implemented"' failed.
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'tgsi'.
1.  Running pass 'Greedy Register Allocator' on function '@main'
./1024x768_windowed.sh : ligne 13 :  9263 Abandon (core
dumped)./bin/Sanctuary -video_app opengl -sound_app openal -extern_define
RELEASE -system_script sanctuary/unigine.cpp -engine_config ../data/unigine.cfg
-data_path ../ -video_fullscreen 0 -video_mode -1 -video_width 1024
-video_height 768

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

DPM on Radeon HD6570

2013-08-21 19:55 keltez?ssel, Alex Deucher ?rta:
> On Wed, Aug 21, 2013 at 1:49 PM, Boszormenyi Zoltan  wrote:
>> Hi,
>>
>> thanks for your response.
>>
>> 2013-08-21 17:39 keltez?ssel, Alex Deucher ?rta:
>>
>>> On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan
>>> wrote:
 Hi,

 I read this Phoronix article:
 http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1

 Congrats to the progress achieved so far.

 However, I can see an interesting deviation for HD6570 from the
 observed trend of other chips.

 r600g can reach 80+ percent of the performance of Catalyst
 for most HD6xxx chips except for 6570, where the performance
 is around 10-20 percent.

 Do you have a theory about this difference?
 Maybe DPM doesn't work as intended on HD6570?

>>> Are you seeing the same results on your board?  If so are the results
>>> roughly the same with dpm enabled vs. disabled?  If so I doubt there
>>> is a problem with dpm.  On older dGPUs like this one dpm won't really
>>> improve performance since the cards come up with relatively high
>>> clocks by default.  It's mainly for saving power when the GPU is idle.
>> I have enabled dpm:
>> $ cat /proc/cmdline
>> BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
>> root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1
>> radeon.dpm=1 LANG=hu_HU.UTF-8
>>
>> I have just tried "openarena 0.8.5" again with forced "low" performance.
>> Results is 26.87fps with low performance, 59.40-59.70fps with forced high
>> performance.
>>
> Sounds like you are refresh rate limited.  Try disabling
> swapbufferswait in your xorg.conf:
>
> Section "Device"
>  Identifier  "card0"
>  Driver  "iradeon"
>  Option "SwapbuffersWait" "false"
> EndSection
>
> and disable vsync in the 3D driver, set env var:
> vblank_mode=0

vblank_mode was already 0 before:

[zozo at localhost ~]$ cat .drirc

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


I have added this:

[root at localhost xorg.conf.d]# pwd
/etc/X11/xorg.conf.d
[root at localhost xorg.conf.d]# cat 99-vblank.conf
Section "Device"
 Identifier"card0"
 Driver"radeon"
 Option"SwapbuffersWait" "false"
EndSection

With forced high performance, I got 118.73 fps. Wow. :-)

> Also what does the performance look like with dpm disabled?

Same as forced high with dpm enabled.

> Anyway, it doesn't sound like dpm is an issue.

Indeed, dpm works as intended.
Something was misconfigured at Phoronix then.

Thanks for resolving this for me,
Zolt?n B?sz?rm?nyi

>
> Alex
>
 I have this kind of video card, so I wanted to test it myself.
 The exact model of my card is:

 http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#

>>> Note that a lot of 6570 cards, including yours use DD3 memory rather
>>> than GDDR5 so they will have fairly limited memory bandwidth.
>> I know. The 6570 tested by Phoronix must be GDDR5
>> but it's not mentioned specifically.
>>
>> Best regards,
>> Zolt?n B?sz?rm?nyi
>>
>>
>>> Alex
>>>
 I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
 http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

 I haven't tested Catalyst but my r600g results mostly match
 the ones in the article even with a different CPU.

 Best regards,
 Zolt?n B?sz?rm?nyi

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

[Bug 68389] [radeonsi]Black screen in unigine-tropics

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

--- Comment #2 from Hohahiu  ---
I can confirm the bug as in the case of unigine-sanctuary. My hardware is Intel
4000+ AMD 7750M. I ran unigine-sanctuary with DRI_PRIME.
My software:
openSUSE 12.3 x86_64
kernel 3.11.rc-6
Mesa-git
llvm-svn
radeon-git

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

[Bug 68391] [radeonsi] Crash unigine-sanctuary

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

--- Comment #1 from Hohahiu  ---
The same error. My hardware is Intel 4000+ AMD 7750M. I ran unigine-sanctuary
with DRI_PRIME.
My software:
openSUSE 12.3 x86_64
kernel 3.11.rc-6
Mesa-git
llvm-svn
radeon-git

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

[PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration

On Wed Aug 14 12:43:30 PDT 2013, Sebastian Hesselbarth wrote:
> From: Russell King 
> 
> This patch adds tda998x specific parameters to allow it to be configured
> for different boards using it. Also, this implements rudimentary audio
> support for S/PDIF attached controllers.

It seems that this patch mixes two different functions:
- configuration
- audio

About configuration, why don't you use the standard way to set the
device parameters, i.e. board info and DT?

> Signed-off-by: Russell King 
> Signed-off-by: Sebastian Hesselbarth 
> Tested-by: Darren Etheridge 
> ---
> Changelog:
> for v1:
> - set AUDIO_DIV to SERCLK/16 for modes with pixclk >100MHz
> - also calculate CTS
> v1->v2:
> - Remove CTS calculation as it isn't used in current TDA998x setup
>   (Reported by Russell King)
> - Remove debug left-over (Reported by Russell King)
> - Use correct tda998x include (Reported by Russell King)
> 
> Cc: David Airlie 
> Cc: Darren Etheridge 
> Cc: Rob Clark 
> Cc: Russell King 
> Cc: Daniel Vetter 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c |  268 
> +++--
>  include/drm/i2c/tda998x.h |   30 +
>  2 files changed, 290 insertions(+), 8 deletions(-)
>  create mode 100644 include/drm/i2c/tda998x.h
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 527d11b..2b64dfa 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
[snip]
> @@ -344,6 +390,23 @@ fail:
>   return ret;
>  }
>  
> +static void
> +reg_write_range(struct drm_encoder *encoder, uint16_t reg, uint8_t *p, int 
> cnt)
> +{
> + struct i2c_client *client = drm_i2c_encoder_get_client(encoder);
> + uint8_t buf[cnt+1];
> + int ret;
> +
> + buf[0] = REG2ADDR(reg);
> + memcpy([1], p, cnt);
> +
> + set_page(encoder, reg);
> +
> + ret = i2c_master_send(client, buf, cnt + 1);
> + if (ret < 0)
> + dev_err(>dev, "Error %d writing to 0x%x\n", ret, reg);
> +}
> +

It seems simpler to reserve one byte in the caller buffer for the
register address and avoid a memcpy.

>  static uint8_t
>  reg_read(struct drm_encoder *encoder, uint16_t reg)
>  {
> @@ -412,7 +475,7 @@ tda998x_reset(struct drm_encoder *encoder)
>   reg_write(encoder, REG_SERIALIZER,   0x00);
>   reg_write(encoder, REG_BUFFER_OUT,   0x00);
>   reg_write(encoder, REG_PLL_SCG1, 0x00);
> - reg_write(encoder, REG_AUDIO_DIV,0x03);
> + reg_write(encoder, REG_AUDIO_DIV,AUDIO_DIV_SERCLK_8);
>   reg_write(encoder, REG_SEL_CLK,  SEL_CLK_SEL_CLK1 | 
> SEL_CLK_ENA_SC_CLK);
>   reg_write(encoder, REG_PLL_SCGN1,0xfa);
>   reg_write(encoder, REG_PLL_SCGN2,0x00);
> @@ -424,11 +487,184 @@ tda998x_reset(struct drm_encoder *encoder)
>   reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
>  }
>  
> +static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
> +{
> + uint8_t sum = 0;
> +
> + while (bytes--)
> + sum += *buf++;
> + return (255 - sum) + 1;
> +}

Simpler:

static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
{
int sum = 0;/* avoid byte computation */

while (bytes--)
sum -= *buf++;  /* avoid a substraction */
return sum;
}

> +
> +#define HB(x) (x)
> +#define PB(x) (HB(2) + 1 + (x))
> +
> +static void
> +tda998x_write_if(struct drm_encoder *encoder, uint8_t bit, uint16_t addr,
> +  uint8_t *buf, size_t size)
> +{
> + buf[PB(0)] = tda998x_cksum(buf, size);
> +
> + reg_clear(encoder, REG_DIP_IF_FLAGS, bit);
> + reg_write_range(encoder, addr, buf, size);
> + reg_set(encoder, REG_DIP_IF_FLAGS, bit);
> +}
> +
> +static void
> +tda998x_write_aif(struct drm_encoder *encoder, struct tda998x_encoder_params 
> *p)
> +{
> + uint8_t buf[PB(5) + 1];
> +
> + buf[HB(0)] = 0x84;
> + buf[HB(1)] = 0x01;
> + buf[HB(2)] = 10;

Why don't you use the constants which are defined in hdmi.h?

> + buf[PB(0)] = 0;
> + buf[PB(1)] = p->audio_frame[1] & 0x07; /* CC */
> + buf[PB(2)] = p->audio_frame[2] & 0x1c; /* SF */
> + buf[PB(4)] = p->audio_frame[4];
> + buf[PB(5)] = p->audio_frame[5] & 0xf8; /* DM_INH + LSV */
> +
> + tda998x_write_if(encoder, DIP_IF_FLAGS_IF4, REG_IF4_HB0, buf,
> +  sizeof(buf));
> +}
> +
> +static void
> +tda998x_write_avi(struct drm_encoder *encoder, struct drm_display_mode *mode)
> +{
> + uint8_t buf[PB(13) + 1];
> +
> + memset(buf, 0, sizeof(buf));
> + buf[HB(0)] = 0x82;
> + buf[HB(1)] = 0x02;
> + buf[HB(2)] = 13;
> + buf[PB(4)] = drm_match_cea_mode(mode);
> +
> + tda998x_write_if(encoder, DIP_IF_FLAGS_IF2, REG_IF2_HB0, buf,
> +  sizeof(buf));
> +}
> +
> +static void

[PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration

On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
> From: Russell King 
> 
> The video-input-port (VIP) is highly configurable. This prepares
> current driver to allow to configure VIP configuration, as some
> boards connect lcd controller and TDA998x "pin-swapped" and depend
> on VIP to swap the pins by register configuration.
> 
> Signed-off-by: Russell King 
> Tested-by: Darren Etheridge 
> Tested-by: Sebastian Hesselbarth 
[snip]

AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is
no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0
of the Dove lcd for RGB or YUV formats).

Which board needs a special VIP configuration?

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

2013-08-21 Thread Ilia Mirkin

The code expects non-VRAM mem nodes to have a pages list. If that's not
set, it will do a null deref down the line. Warn on that condition and
return an error.

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

Reported-by: Pasi K?rkk?inen 
Tested-by: Pasi K?rkk?inen 
Signed-off-by: Ilia Mirkin 
Cc:  # 3.8+
---

I don't exactly understand what's going on, but this is just a
straightforward way to avoid a null deref that you see happens in the
bug. I haven't figured out the root cause of this, but it's getting
well into the "I have no idea how TTM works" space. However this seems
like a bit of defensive programming -- nouveau_vm_map_sg will pass
node->pages as a list down, which will be dereferenced by
nvc0_vm_map_sg. Perhaps the other arguments should make that
dereferencing not happen, but it definitely was happening here, as you
can see in the bug.

Ben/Maarten, I'll let you judge whether this check is appropriate,
since like I hope I was able to convey above, I'm just not really sure :)

 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index cdc3282..191145d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, struct 
nouveau_bo *nvbo,
struct nouveau_mem *node = mem->mm_node;
int ret;

+   /* If we ever get here for a non-vram mem node that doesn't
+* have pages, we will end up doing a null deref in
+* nouveau_vm_map_sg. */
+   if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages))
+   return -EINVAL;
+
ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages <<
 PAGE_SHIFT, node->page_shift,
 NV_MEM_ACCESS_RW, vma);
-- 
1.8.1.5

DPM on Radeon HD6570

2013-08-21 18:30 keltez?ssel, Grigori Goronzy ?rta:
> On 21.08.2013 16:31, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> I read this Phoronix article:
>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>
>> Congrats to the progress achieved so far.
>>
>> However, I can see an interesting deviation for HD6570 from the
>> observed trend of other chips.
>>
>> r600g can reach 80+ percent of the performance of Catalyst
>> for most HD6xxx chips except for 6570, where the performance
>> is around 10-20 percent.
>>
>> Do you have a theory about this difference?
>> Maybe DPM doesn't work as intended on HD6570?
>>
>
> There are some ways to check if DPM functions correctly.
>
> The kernel log (dmesg) contains a dump of the PowerPlay tables, search for 
> "power 
> state". It's possible that tables aren't read correctly or flaky to start 
> with.

Here it is:

[2.252567] [drm] Internal thermal controller with fan control
[2.252619] == power state 0 ==
[2.252621]  ui class: none
[2.252622]  internal class: boot
[2.252624]  caps:
[2.252625]  uvdvclk: 0 dclk: 0
[2.252627]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252628]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252629]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252630]  status: c r b
[2.252632] == power state 1 ==
[2.252632]  ui class: performance
[2.252633]  internal class: none
[2.252635]  caps:
[2.252636]  uvdvclk: 0 dclk: 0
[2.252637]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252640]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.252641]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252642]  status:
[2.252643] == power state 2 ==
[2.252644]  ui class: none
[2.252645]  internal class: uvd
[2.252646]  caps: video
[2.252647]  uvdvclk: 7 dclk: 56000
[2.252651]  power level 0sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252652]  power level 1sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252653]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252654]  status:
[2.257099] switching from power state:
[2.257105]  ui class: none
[2.257107]  internal class: boot
[2.257109]  caps:
[2.257111]  uvdvclk: 0 dclk: 0
[2.257113]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257114]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257116]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257117]  status: c b
[2.257129] switching to power state:
[2.257130]  ui class: performance
[2.257132]  internal class: none
[2.257133]  caps:
[2.257135]  uvdvclk: 0 dclk: 0
[2.257137]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257139]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.257140]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.257141]  status: r
[2.258555] [drm] radeon: dpm initialized


>
> You can also monitor the precise runtime power level (clocks and voltages) of 
> the GPU 
> with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe dynamic switching does not 
> work for 
> some reason, and the GPU always uses the lowest level even under load. Just 
> run some 
> demanding OpenGL app and check that file to see if the GPU switches the power 
> level.

Just running this loop:

[root at localhost ~]# while `/bin/true` ; do cat 
/sys/kernel/debug/dri/0/radeon_pm_info ; 
sleep 1 ; done

while the terminal is sufficiently large on the screen results in changing 
power levels:

uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000

DPM on Radeon HD6570

Hi,

thanks for your response.

2013-08-21 17:39 keltez?ssel, Alex Deucher ?rta:
> On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan  wrote:
>> Hi,
>>
>> I read this Phoronix article:
>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>
>> Congrats to the progress achieved so far.
>>
>> However, I can see an interesting deviation for HD6570 from the
>> observed trend of other chips.
>>
>> r600g can reach 80+ percent of the performance of Catalyst
>> for most HD6xxx chips except for 6570, where the performance
>> is around 10-20 percent.
>>
>> Do you have a theory about this difference?
>> Maybe DPM doesn't work as intended on HD6570?
>>
> Are you seeing the same results on your board?  If so are the results
> roughly the same with dpm enabled vs. disabled?  If so I doubt there
> is a problem with dpm.  On older dGPUs like this one dpm won't really
> improve performance since the cards come up with relatively high
> clocks by default.  It's mainly for saving power when the GPU is idle.

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64 
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1 
radeon.dpm=1 
LANG=hu_HU.UTF-8

I have just tried "openarena 0.8.5" again with forced "low" performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

>
>> I have this kind of video card, so I wanted to test it myself.
>> The exact model of my card is:
>> http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#
>>
> Note that a lot of 6570 cards, including yours use DD3 memory rather
> than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zolt?n B?sz?rm?nyi

>
> Alex
>
>> I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=457463
>>
>> I haven't tested Catalyst but my r600g results mostly match
>> the ones in the article even with a different CPU.
>>
>> Best regards,
>> Zolt?n B?sz?rm?nyi
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes

2013-08-21 Thread bugzilla-dae...@bugzilla.kernel.org

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

Harald Judt  changed:

   What|Removed |Added

 Status|NEEDINFO|CLOSED
 Resolution|--- |CODE_FIX

--- Comment #22 from Harald Judt  ---
This was a problem with the power management of the radeon graphics driver and
should be fixed in 3.11, as long as one disables UVD with an unofficial
radeon.no_uvd=1 patch. Since this is solved for me now, thanks for your help.

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

[PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support

This patch adds lock and poll callbacks to dma buf file operations,
and these callbacks will be called by fcntl and select system calls.

fcntl and select system calls can be used to wait for the completion
of DMA or CPU access to a shared dmabuf. The difference of them is
fcntl system call takes a lock after the completion but select system
call doesn't. So in case of fcntl system call, it's useful when a task
wants to access a shared dmabuf without any broken. On the other hand,
it's useful when a task wants to just wait for the completion.

Changelog v2:
- Add select system call support.
  . The purpose of this feature is to wait for the completion of DMA or
CPU access to a dmabuf without that caller locks the dmabuf again
after the completion.
That is useful when caller wants to be aware of the completion of
DMA access to the dmabuf, and the caller doesn't use intefaces for
the DMA device driver.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/base/dma-buf.c |   81 
 1 files changed, 81 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 4aca57a..f16a396 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 static inline int is_dma_buf_file(struct file *);
@@ -80,9 +81,89 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
 }

+static unsigned int dma_buf_poll(struct file *filp,
+   struct poll_table_struct *poll)
+{
+   struct dma_buf *dmabuf;
+   struct dmabuf_sync_reservation *robj;
+   int ret = 0;
+
+   if (!is_dma_buf_file(filp))
+   return POLLERR;
+
+   dmabuf = filp->private_data;
+   if (!dmabuf || !dmabuf->sync)
+   return POLLERR;
+
+   robj = dmabuf->sync;
+
+   mutex_lock(>lock);
+
+   robj->polled = true;
+
+   /*
+* CPU or DMA access to this buffer has been completed, and
+* the blocked task has been waked up. Return poll event
+* so that the task can get out of select().
+*/
+   if (robj->poll_event) {
+   robj->poll_event = false;
+   mutex_unlock(>lock);
+   return POLLIN | POLLOUT;
+   }
+
+   /*
+* There is no anyone accessing this buffer so just return.
+*/
+   if (!robj->locked) {
+   mutex_unlock(>lock);
+   return POLLIN | POLLOUT;
+   }
+
+   poll_wait(filp, >poll_wait, poll);
+
+   mutex_unlock(>lock);
+
+   return ret;
+}
+
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   struct dma_buf *dmabuf;
+   unsigned int type;
+   bool wait = false;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+   dmabuf_sync_single_unlock(dmabuf);
+   return 0;
+   }
+
+   /* convert flock type to dmabuf sync type. */
+   if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+   type = DMA_BUF_ACCESS_W;
+   else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+   type = DMA_BUF_ACCESS_R;
+   else
+   return -EINVAL;
+
+   if (fl->fl_flags & FL_SLEEP)
+   wait = true;
+
+   /* TODO. the locking to certain region should also be considered. */
+
+   return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
+   .poll   = dma_buf_poll,
+   .lock   = dma_buf_lock,
 };

 /*
-- 
1.7.5.4

[PATCH v7 1/2] dmabuf-sync: Add a buffer synchronization framework

This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism, and has been rebased
on linux-3.11-rc6.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framework can be used for all dma devices using
system memory as dma buffer, especially for most ARM based SoCs.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
1. Register dmabufs to a sync object - A task gets a new sync object and
can add one or more dmabufs that the task wants to access.
This registering should be performed when a device context or an event
context such as a page flip event is created or before CPU accesses a shared
buffer.

dma_buf_sync_get(a sync object, a dmabuf);

2. Lock a sync object - A task tries to lock all dmabufs added in its own
sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
and DMA. Taking a lock means that others cannot access all locked dmabufs
until the task that locked the corresponding dmabufs, unlocks all the locked
dmabufs.
This locking should be performed before DMA or CPU accesses these dmabufs.

dma_buf_sync_lock(a sync object);

3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
object. The unlock means that the DMA or CPU accesses to the dmabufs have
been completed so that others may access them.
This unlocking should be performed after DMA or CPU has completed accesses
to the dmabufs.

dma_buf_sync_unlock(a sync object);

4. Unregister one or all dmabufs from a sync object - A task unregisters
the given dmabufs from the sync object. This means that the task dosen't
want to lock the dmabufs.
The unregistering should be performed after DMA or CPU has completed
accesses to the dmabufs or when dma_buf_sync_lock() is failed.

dma_buf_sync_put(a sync object, a dmabuf);
dma_buf_sync_put_all(a sync object);

The described steps may be summarized as:
get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put

This framework includes the following two features.
1. read (shared) and write (exclusive) locks - A task is required to declare
the access type when the task tries to register a dmabuf;
READ, WRITE, READ DMA, or WRITE DMA.

The below is example codes,
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(...);
...

dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
...

And the below can be used as access types:
DMA_BUF_ACCESS_R - CPU will access a buffer for read.
DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
write.

2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
A task may never try to unlock a buffer after taking a lock to the buffer.
In this case, a timer handler to the corresponding sync object is called
in five (default) seconds and then the timed-out buffer is unlocked by work
queue handler to avoid lockups and to enforce resources of the buffer.

The below is how to use interfaces for

[PATCH v7 0/2] Introduce buffer synchronization framework

Hi all,

This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and
has been rebased on linux-3.11-rc6.

The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

For generic user mode interface, we have used fcntl and select system
call[3]. As you know, user application sees a buffer object as a dma-buf
file descriptor. So fcntl() call with the file descriptor means to lock
some buffer region being managed by the dma-buf object. And select() call
means to wait for the completion of CPU or DMA access to the dma-buf
without locking. For more detail, you can refer to the dma-buf-sync.txt
in Documentation/

There are some cases we should use this buffer synchronization framework.
One of which is to primarily enhance GPU rendering performance on Tizen
platform in case of 3d app with compositing mode that 3d app draws
something in off-screen buffer, and Web app.

In case of 3d app with compositing mode which is not a full screen mode,
the app calls glFlush to submit 3d commands to GPU driver instead of
glFinish for more performance. The reason we call glFlush is that glFinish
blocks caller's task until the execution of the 2d commands is completed.
Thus, that makes GPU and CPU more idle. As result, 3d rendering performance
with glFinish is quite lower than glFlush. However, the use of glFlush has
one issue that the a buffer shared with GPU could be broken when CPU
accesses the buffer at once after glFlush because CPU cannot be aware of
the completion of GPU access to the buffer. Of course, the app can be aware
of that time using eglWaitGL but this function is valid only in case of the
same process.

The below summarizes how app's window is displayed on Tizen platform:
1. X client requests a window buffer to Xorg.
2. X client draws something in the window buffer using CPU.
3. X client requests SWAP to Xorg.
4. Xorg notifies a damage event to Composite Manager.
5. Composite Manager gets the window buffer (front buffer) through
   DRI2GetBuffers.
6. Composite Manager composes the window buffer and its own back buffer
   using GPU. At this time, eglSwapBuffers is called: internally, 3d
   commands are flushed to gpu driver.
7. Composite Manager requests SWAP to Xorg.
8. Xorg performs drm page flip. At this time, the window buffer is
   displayed on screen.

Web app based on HTML5 also has the same issue. Web browser and its web app
are different process. The web app draws something in its own pixmap buffer,
and then the web browser gets a window buffer from Xorg, and then composites
the pixmap buffer with the window buffer. And finally, page flip.

Thus, in such cases, a shared buffer could be broken as one process draws
something in pixmap buffer using CPU, when other process composites the
pixmap buffer with window buffer using GPU without any locking mechanism.
That is why we need user land locking interface, fcntl system call.

And last one is a deferred page flip issue. This issue is that a window
buffer rendered can be displayed on screen in about 32ms in worst case:
assume that the gpu rendering is completed within 16ms.
That can be incurred when compositing a pixmap buffer with a window buffer
using GPU and when vsync is just started. At this time, Xorg waits for
a vblank event to get a window buffer so

DPM on Radeon HD6570

2013-08-21 Thread Grigori Goronzy

On 21.08.2013 16:31, Boszormenyi Zoltan wrote:
> Hi,
>
> I read this Phoronix article:
> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>
> Congrats to the progress achieved so far.
>
> However, I can see an interesting deviation for HD6570 from the
> observed trend of other chips.
>
> r600g can reach 80+ percent of the performance of Catalyst
> for most HD6xxx chips except for 6570, where the performance
> is around 10-20 percent.
>
> Do you have a theory about this difference?
> Maybe DPM doesn't work as intended on HD6570?
>

There are some ways to check if DPM functions correctly.

The kernel log (dmesg) contains a dump of the PowerPlay tables, search 
for "power state". It's possible that tables aren't read correctly or 
flaky to start with.

You can also monitor the precise runtime power level (clocks and 
voltages) of the GPU with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe 
dynamic switching does not work for some reason, and the GPU always uses 
the lowest level even under load. Just run some demanding OpenGL app and 
check that file to see if the GPU switches the power level.

You should probably file a bug on bugs.freedesktop.org (product DRI, 
component DRM/radeon) and attach dmesg output and anything else that 
might be useful.

Best regards
Grigori

[PATCH 09/12] drm/edid: Move HDMI_IDENTIFIER to hdmi.h

2013-08-21 Thread Damien Lespiau

On Mon, Aug 19, 2013 at 09:31:42PM +0200, Thierry Reding wrote:
> On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote:
> > On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
> > > On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
> > > [...]
> > > > +#define HDMI_IDENTIFIER 0x000c03
> > > 
> > > HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI?
> > 
> > This identifier is not infoframe specific, it's the IEEE OUI:
> > 
> >   http://standards.ieee.org/develop/regauth/oui/oui.txt
> > 
> > would HDMI_IEEE_OUI suit you?
> 
> Yes, that sounds much better. Or perhaps IEEE_OUI_HDMI? From a quick
> grep through the kernel code using the OUI as a prefix seems to be
> slightly more common. If we ever end up adding a header to collect
> OUIs it'd be useful to namespace them somehow.

Hopefully we can agree that HDMI_IEEE_OUI is fine :) Would you mind
having a look at the two patches introduced to address your comments

  HDMI 4k support v4
  http://lists.freedesktop.org/archives/dri-devel/2013-August/043988.html

Patches 11 and 14.

Thanks,

-- 
Damien

[Bug 65254] opengl flicker in xbmc / glxgears

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

--- Comment #17 from Vladi  ---
so far after disabling radeon.dpm I dont see the reboots. but my screen is
still seeing the artifacts/flicker

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

[Bug 68391] New: [radeonsi] Crash unigine-sanctuary

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

  Priority: medium
Bug ID: 68391
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi] Crash unigine-sanctuary
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: grantipak at gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

ArchLinux x32; kernel 3.10; llvm - svn; mesa - git; Radeon HD 7950.

behem0th at ArchLinux ~ $ unigine-sanctuary 
fullscreen? Please enter 1 or 0. (1 = yes, 0 = no)
0
video width? e.g. 1024

video height? e.g. 768

Loading "/home/behem0th/.Unigine Sanctuary/unigine.cfg"...
Engine::init(): clear video settings for "Gallium 0.4 on AMD TAHITI 2.1 Mesa
9.3.0-devel (git-10aa367)"
Loading "libGL.so.1"...
Loading "libopenal.so.1"...
Set 640x480 windowed video mode
Set 1.00 gamma value
Unigine engine http://unigine.com/
Binary: Linux 32bit GCC 4.3.2 Release May 20 2010
App path:  /opt/unigine-sanctuary/bin/
Data path: /opt/unigine-sanctuary/data/
Save path: /home/behem0th/.Unigine Sanctuary/

 System 
System: Linux 3.10.0-1-ARCH i686
CPU: AMD Phenom(tm) 9550 Quad-Core Processor 2199MHz MMX+ 3DNow!+ SSE SSE2 SSE3
SSE4A HTT
GPU: Gallium 0.4 on AMD TAHITI 2.1 Mesa 9.3.0-devel (git-10aa367)
System memory: 8095 Mb
Video memory:  256 Mb

 MathLib 
Set SSE3 simd processor

 Sound 
Renderer: OpenAL Soft
OpenAL vendor:   OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version:  1.1 ALSOFT 1.15.1
Found AL_EXT_LINEAR_DISTANCE
Found AL_EXT_OFFSET
Found ALC_EXT_EFX
Found EFX Filter
Found EFX Reverb
Found EAX Reverb
Found QUAD16 format
Found 51CHN16 format
Found 61CHN16 format
Found 71CHN16 format
Maximum sources: 256
Maximum effect slots:4
Maximum auxiliary sends: 2

 Render 
GLRender::GLRender(): Unknown GPU
OpenGL vendor:   X.Org
OpenGL renderer: Gallium 0.4 on AMD TAHITI
OpenGL version:  2.1 Mesa 9.3.0-devel (git-10aa367)
Found required GL_ARB_map_buffer_range
Found required GL_ARB_vertex_array_object
Found required GL_ARB_vertex_buffer_object
Found required GL_ARB_half_float_vertex
Found required GL_ARB_half_float_pixel
Found required GL_ARB_occlusion_query
Found required GL_EXT_texture3D
Found required GL_EXT_texture_cube_map
Found required GL_EXT_texture_sRGB
Found required GL_EXT_texture_swizzle
Found required GL_ARB_shader_object
Found required GL_ARB_vertex_shader
Found required GL_ARB_fragment_shader
Found required GL_ARB_draw_buffers
Found required GL_ARB_framebuffer_object
Found required GL_EXT_framebuffer_blit
Found required GL_EXT_framebuffer_multisample
Found optional GL_ARB_draw_instanced
Found optional GL_ARB_draw_elements_base_vertex
Found optional GL_ARB_texture_rg
Found optional GL_EXT_texture_array
Found optional GL_ARB_texture_multisample
Found optional GL_ARB_texture_compression
Found optional GL_ARB_texture_compression_rgtc
Found optional GL_ARB_seamless_cube_map
Shading language:  1.30
Maximum texture size:  16384
Maximum texture units: 32
Maximum draw buffers:  8

 Physics 
Physics: Multi-threaded

 Interpreter 
Version: 2.31

Loading "sanctuary/unigine.cpp" 124ms
Loading "demos/sanctuary/locale/unigine.en" dictionary
Loading "core/materials/unigine_post.mat" 12 materials 12 shaders 0ms
Loading "core/materials/unigine_render.mat" 34 materials 77 shaders 14ms
Loading "core/materials/unigine_meshes.mat" 16 materials 9350 shaders 105ms
Loading "core/materials/unigine_terrains.mat" 1 material 293 shaders 4ms
Loading "core/materials/unigine_grass.mat" 1 material 81 shaders 8ms
Loading "core/materials/unigine_particles.mat" 1 material 43 shaders 7ms
Loading "core/materials/unigine_billboards.mat" 1 material 33 shaders 8ms
Loading "core/materials/unigine_volumes.mat" 5 materials 29 shaders 18ms
Loading "core/materials/unigine_guis.mat" 1 material 24 shaders 3ms
Loading "core/materials/unigine_water.mat" 1 material 63 shaders 21ms
Loading "core/materials/unigine_skies.mat" 1 material 19 shaders 25ms
Loading "core/materials/unigine_decals.mat" 1 material 69 shaders 10ms
Loading "core/properties/unigine.prop" 2 properties 1ms
Unigine~# world_load sanctuary
Loading "sanctuary.cpp" 104ms
Loading "sanctuary/sanctuary.mat" 54 materials 640ms
Loading "sanctuary.world" 13950ms
Unigine~# render_hdr 0 && render_srgb 0 && render_restart
LLVM ERROR: ran out of registers during register allocation
AL lib: (EE) alc_cleanup: 1 device not closed

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

[PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework


Thanks for the review,
Inki Dae

> -Original Message-
> From: linux-fbdev-owner at vger.kernel.org [mailto:linux-fbdev-
> owner at vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, August 21, 2013 4:22 AM
> To: Inki Dae
> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; linux-media at vger.kernel.org; linaro-
> kernel at lists.linaro.org; kyungmin.park at samsung.com;
> myungjoo.ham at samsung.com
> Subject: Re: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer
> synchronization framework
> 
> On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
> > This patch adds a buffer synchronization framework based on DMA BUF[1]
> > and and based on ww-mutexes[2] for lock mechanism.
> >
> > The purpose of this framework is to provide not only buffer access
> control
> > to CPU and DMA but also easy-to-use interfaces for device drivers and
> > user application. This framework can be used for all dma devices using
> > system memory as dma buffer, especially for most ARM based SoCs.
> >
> > Changelog v6:
> > - Fix sync lock to multiple reads.
> > - Add select system call support.
> >   . Wake up poll_wait when a dmabuf is unlocked.
> > - Remove unnecessary the use of mutex lock.
> > - Add private backend ops callbacks.
> >   . This ops has one callback for device drivers to clean up their
> > sync object resource when the sync object is freed. For this,
> > device drivers should implement the free callback properly.
> > - Update document file.
> >
> > Changelog v5:
> > - Rmove a dependence on reservation_object: the reservation_object is
> used
> >   to hook up to ttm and dma-buf for easy sharing of reservations across
> >   devices. However, the dmabuf sync can be used for all dma devices;
> v4l2
> >   and drm based drivers, so doesn't need the reservation_object anymore.
> >   With regared to this, it adds 'void *sync' to dma_buf structure.
> > - All patches are rebased on mainline, Linux v3.10.
> >
> > Changelog v4:
> > - Add user side interface for buffer synchronization mechanism and
> update
> >   descriptions related to the user side interface.
> >
> > Changelog v3:
> > - remove cache operation relevant codes and update document file.
> >
> > Changelog v2:
> > - use atomic_add_unless to avoid potential bug.
> > - add a macro for checking valid access type.
> > - code clean.
> >
> > The mechanism of this framework has the following steps,
> > 1. Register dmabufs to a sync object - A task gets a new sync object
> and
> > can add one or more dmabufs that the task wants to access.
> > This registering should be performed when a device context or an
> event
> > context such as a page flip event is created or before CPU accesses
a
> shared
> > buffer.
> >
> > dma_buf_sync_get(a sync object, a dmabuf);
> >
> > 2. Lock a sync object - A task tries to lock all dmabufs added in
its
> own
> > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid
> dead
> > lock issue and for race condition between CPU and CPU, CPU and DMA,
> and DMA
> > and DMA. Taking a lock means that others cannot access all locked
> dmabufs
> > until the task that locked the corresponding dmabufs, unlocks all
the
> locked
> > dmabufs.
> > This locking should be performed before DMA or CPU accesses these
> dmabufs.
> >
> > dma_buf_sync_lock(a sync object);
> >
> > 3. Unlock a sync object - The task unlocks all dmabufs added in its
> own sync
> > object. The unlock means that the DMA or CPU accesses to the dmabufs
> have
> > been completed so that others may access them.
> > This unlocking should be performed after DMA or CPU has completed
> accesses
> > to the dmabufs.
> >
> > dma_buf_sync_unlock(a sync object);
> >
> > 4. Unregister one or all dmabufs from a sync object - A task
> unregisters
> > the given dmabufs from the sync object. This means that the task
> dosen't
> > want to lock the dmabufs.
> > The unregistering should be performed after DMA or CPU has completed
> > accesses to the dmabufs or when dma_buf_sync_lock() is failed.
> >
> > dma_buf_sync_put(a sync object, a dmabuf);
> > dma_buf_sync_put_all(a sync object);
> >
> > The described steps may be summarized as:
> > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put
> >
> > This framework includes the following two features.
> > 1. read (shared) and write (exclusive) locks - A task is required to
> declare
> > the access type when the task tries to register a dmabuf;
> > READ, WRITE, READ DMA, or WRITE DMA.
> >
> > The below is example codes,
> > struct dmabuf_sync *sync;
> >
> > sync = dmabuf_sync_init(...);
> > ...
> >
> > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
> > ...
> >
> > And the below can be used as access types:
> > DMA_BUF_ACCESS_R - CPU will access a buffer for

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

2013-08-21 Thread Simon Horman

On Sat, Aug 10, 2013 at 07:28:30AM +1000, Dave Airlie wrote:
> On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart
>  wrote:
> > Hi Dave,
> >
> > On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
> >> On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman  
> >> wrote:
> >> > On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
> >> >> Hi Dave,
> >> >>
> >> >> (CC'ing Simon Horman, the shmobile tree maintainer)
> >> >>
> >> >> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> >> >> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> >> >> > > Hi Dave,
> >> >> > >
> >> >> > > I've got a couple of arch/arm/ patches that depend on this series 
> >> >> > > and
> >> >> > > that I would like to get merged in v3.12. They should go upstream
> >> >> > > through the arm-soc tree. Would you be able to provide a stable
> >> >> > > branch with this patch set based on one of the 3.11-rcX tags ?
> >> >> > > Ideally that branch should have as little patches as possible other
> >> >> > > than this set.
> >> >> >
> >> >> > Yeah that shouldn't be a problem, though is there any interface 
> >> >> > changes
> >> >> > or things with this wrt drm-next?
> >> >> >
> >> >> > i.e. will this tree build on v3.11-rcX and drm-next?
> >> >>
> >> >> They depend on a fix that went in between -rc1 and -rc2. You can base 
> >> >> the
> >> >> branch on any -rc >= 2.
> >> >
> >> > An rc2 or rc3 base would be ideal for me, but any rc would be fine.
> >>
> >> So the problem with making a stable branch is we have conflicts in other
> >> places that have already been solved in drm-next,
> >>
> >> is there any problem with using Laurent's tree directly as the stable 
> >> point?
> >
> > As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and pushed 
> > the
> > result to
> >
> > git://linuxtv.org/pinchartl/fbdev.git drm/next/du
> >
> >  b/drivers/gpu/drm/rcar-du/Kconfig   |7
> >  b/drivers/gpu/drm/rcar-du/Makefile  |   10 -
> >  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 
> > +-
> >  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
> >  b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
> >  b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
> >  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
> >  b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
> >  b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
> >  b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
> >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 +
> >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
> >  b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
> >  b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
> >  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
> >  b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
> >  b/include/linux/platform_data/rcar-du.h |   34 ++-
> >  drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 ---
> >  drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
> >  drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
> >  drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
> >  27 files changed, 1665 insertions(+), 861 deletions(-)
> >
> > Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/
> > patches on top of this drm/next/du branch.
> 
> Actually small change
> 
> Simon can you use
> 
> git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12
> 
> as I've merged this tree with an S-o-b on the merge commit, so other
> people will know it has gone via me.

Sorry for the delayed response.

I had assumed that the reason I was having trouble fetching
the remote above was related to the internet connection at the
end of the world that I was in turn at the end while on holidays.

However, it seems that I am unable to fetch the remote from my office
either. This may well be a fault at my end, but its not something
I can readily think of a work around for other than trying from home a
little later.

# git remote add airlied git://git.freedesktop.org/~airlied/linux
# git fetch airlied
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

[Bug 68389] [radeonsi]Black screen in unigine-tropics

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

Vladimir Ysikov  changed:

   What|Removed |Added

  Attachment #84399|text/plain  |image/png
  mime type||

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

[Bug 68389] [radeonsi]Black screen in unigine-tropics

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

--- Comment #1 from Vladimir Ysikov  ---
Created attachment 84403
  --> https://bugs.freedesktop.org/attachment.cgi?id=84403=edit
Shader dump from unigine-tropics

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

[Bug 68389] New: [radeonsi]Black screen in unigine-tropics

 function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
Unigine~# quit
Close "libopenal.so.1"
Close "libGL.so.1"
Memory usage: 64b
Allocations:  1
Shutdown

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

DPM on Radeon HD6570

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zolt?n B?sz?rm?nyi

[PATCH 3/3] drm/exynos: fimd: move platform data parsing to separate function

The patch moves platfrom_data and device tree parsing
to separate function.

Signed-off-by: Andrzej Hajda 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 63 
 1 file changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 6afcaf1..130dea5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -122,7 +122,7 @@ struct fimd_context {
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;

-   struct exynos_drm_panel_info *panel;
+   struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
 };

@@ -164,7 +164,7 @@ static void *fimd_get_panel(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);

-   return ctx->panel;
+   return >panel;
 }

 static int fimd_check_mode(struct device *dev, struct drm_display_mode *mode)
@@ -244,7 +244,7 @@ static void fimd_apply(struct device *subdrv_dev)
 static void fimd_commit(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
-   struct exynos_drm_panel_info *panel = ctx->panel;
+   struct exynos_drm_panel_info *panel = >panel;
struct videomode *vm = >vm;
struct fimd_driver_data *driver_data;
u32 val;
@@ -755,7 +755,7 @@ static void fimd_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)

 static int fimd_configure_clocks(struct fimd_context *ctx, struct device *dev)
 {
-   struct videomode *vm = >panel->vm;
+   struct videomode *vm = >panel.vm;
unsigned long clk;

ctx->bus_clk = devm_clk_get(dev, "fimd");
@@ -892,24 +892,13 @@ static int fimd_activate(struct fimd_context *ctx, bool 
enable)
return 0;
 }

-static int fimd_probe(struct platform_device *pdev)
+static int fimd_get_platform_data(struct fimd_context *ctx, struct device *dev)
 {
-   struct device *dev = >dev;
-   struct fimd_context *ctx;
-   struct exynos_drm_subdrv *subdrv;
-   struct exynos_drm_fimd_pdata *pdata;
-   struct exynos_drm_panel_info *panel;
-   struct resource *res;
-   int win;
-   int ret = -EINVAL;
-
if (dev->of_node) {
struct videomode *vm;
-   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata)
-   return -ENOMEM;
+   int ret;

-   vm = >panel.vm;
+   vm = >panel.vm;
ret = of_get_videomode(dev->of_node, vm, OF_USE_NATIVE_MODE);
if (ret) {
DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
@@ -917,31 +906,45 @@ static int fimd_probe(struct platform_device *pdev)
}

if (vm->flags & DISPLAY_FLAGS_VSYNC_LOW)
-   pdata->vidcon1 |= VIDCON1_INV_VSYNC;
+   ctx->vidcon1 |= VIDCON1_INV_VSYNC;
if (vm->flags & DISPLAY_FLAGS_HSYNC_LOW)
-   pdata->vidcon1 |= VIDCON1_INV_HSYNC;
+   ctx->vidcon1 |= VIDCON1_INV_HSYNC;
if (vm->flags & DISPLAY_FLAGS_DE_LOW)
-   pdata->vidcon1 |= VIDCON1_INV_VDEN;
+   ctx->vidcon1 |= VIDCON1_INV_VDEN;
if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
-   pdata->vidcon1 |= VIDCON1_INV_VCLK;
+   ctx->vidcon1 |= VIDCON1_INV_VCLK;
} else {
-   pdata = dev->platform_data;
+   struct exynos_drm_fimd_pdata *pdata = dev->platform_data;
if (!pdata) {
DRM_ERROR("no platform data specified\n");
return -EINVAL;
}
+   ctx->vidcon0 = pdata->vidcon0;
+   ctx->vidcon1 = pdata->vidcon1;
+   ctx->default_win = pdata->default_win;
+   ctx->panel = pdata->panel;
}

-   panel = >panel;
-   if (!panel) {
-   dev_err(dev, "panel is null.\n");
-   return -EINVAL;
-   }
+   return 0;
+}
+
+static int fimd_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct fimd_context *ctx;
+   struct exynos_drm_subdrv *subdrv;
+   struct resource *res;
+   int win;
+   int ret = -EINVAL;

ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

+   ret = fimd_get_platform_data(ctx, dev);
+   if (ret)
+   return ret;
+
ret = fimd_configure_clocks(ctx, dev);
if (ret)
return ret;
@@ -968,10 +971,6 @@ static int fimd_probe(struct platform_device *pdev)
}

ctx->driver_data = drm_fimd_get_driver_data(pdev);
-   ctx->vidcon0 = pdata->vidcon0;
-   ctx->vidcon1 =

[PATCH 2/3] drm/exynos: fimd: get signal polarities from device tree

The patch adds code to get signal polarization setting
from device tree display-timings node.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a183ea7..6afcaf1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -915,6 +915,15 @@ static int fimd_probe(struct platform_device *pdev)
DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
return ret;
}
+
+   if (vm->flags & DISPLAY_FLAGS_VSYNC_LOW)
+   pdata->vidcon1 |= VIDCON1_INV_VSYNC;
+   if (vm->flags & DISPLAY_FLAGS_HSYNC_LOW)
+   pdata->vidcon1 |= VIDCON1_INV_HSYNC;
+   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
+   pdata->vidcon1 |= VIDCON1_INV_VDEN;
+   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   pdata->vidcon1 |= VIDCON1_INV_VCLK;
} else {
pdata = dev->platform_data;
if (!pdata) {
-- 
1.8.1.2

[PATCH 1/3] drm/exynos: fimd: replace struct fb_videomode with videomode

The patch replaces all occurrences of struct fb_videomode by
more accurate struct videomode. The change allows to remove
mode conversion function and simplifies clock divider calculation.
Clock configuration is moved to separate function.

Signed-off-by: Andrzej Hajda 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 131 +-
 include/drm/exynos_drm.h  |   3 +-
 3 files changed, 70 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index de7c7b2..e082efb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -29,35 +29,6 @@ struct exynos_drm_connector {
uint32_tdpms;
 };

-/* convert exynos_video_timings to drm_display_mode */
-static inline void
-convert_to_display_mode(struct drm_display_mode *mode,
-   struct exynos_drm_panel_info *panel)
-{
-   struct fb_videomode *timing = >timing;
-
-   mode->clock = timing->pixclock / 1000;
-   mode->vrefresh = timing->refresh;
-
-   mode->hdisplay = timing->xres;
-   mode->hsync_start = mode->hdisplay + timing->right_margin;
-   mode->hsync_end = mode->hsync_start + timing->hsync_len;
-   mode->htotal = mode->hsync_end + timing->left_margin;
-
-   mode->vdisplay = timing->yres;
-   mode->vsync_start = mode->vdisplay + timing->lower_margin;
-   mode->vsync_end = mode->vsync_start + timing->vsync_len;
-   mode->vtotal = mode->vsync_end + timing->upper_margin;
-   mode->width_mm = panel->width_mm;
-   mode->height_mm = panel->height_mm;
-
-   if (timing->vmode & FB_VMODE_INTERLACED)
-   mode->flags |= DRM_MODE_FLAG_INTERLACE;
-
-   if (timing->vmode & FB_VMODE_DOUBLE)
-   mode->flags |= DRM_MODE_FLAG_DBLSCAN;
-}
-
 static int exynos_drm_connector_get_modes(struct drm_connector *connector)
 {
struct exynos_drm_connector *exynos_connector =
@@ -112,7 +83,9 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
return 0;
}

-   convert_to_display_mode(mode, panel);
+   drm_display_mode_from_videomode(>vm, mode);
+   mode->width_mm = panel->width_mm;
+   mode->height_mm = panel->height_mm;
connector->display_info.width_mm = mode->width_mm;
connector->display_info.height_mm = mode->height_mm;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f8889d2..a183ea7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -21,6 +21,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 

@@ -36,6 +37,8 @@
  * CPU Interface.
  */

+#define FIMD_DEFAULT_FRAMERATE 60
+
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
@@ -242,7 +245,7 @@ static void fimd_commit(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
-   struct fb_videomode *timing = >timing;
+   struct videomode *vm = >vm;
struct fimd_driver_data *driver_data;
u32 val;

@@ -254,22 +257,22 @@ static void fimd_commit(struct device *dev)
writel(ctx->vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);

/* setup vertical timing values. */
-   val = VIDTCON0_VBPD(timing->upper_margin - 1) |
-  VIDTCON0_VFPD(timing->lower_margin - 1) |
-  VIDTCON0_VSPW(timing->vsync_len - 1);
+   val = VIDTCON0_VBPD(vm->vback_porch - 1) |
+  VIDTCON0_VFPD(vm->vfront_porch - 1) |
+  VIDTCON0_VSPW(vm->vsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);

/* setup horizontal timing values.  */
-   val = VIDTCON1_HBPD(timing->left_margin - 1) |
-  VIDTCON1_HFPD(timing->right_margin - 1) |
-  VIDTCON1_HSPW(timing->hsync_len - 1);
+   val = VIDTCON1_HBPD(vm->hback_porch - 1) |
+  VIDTCON1_HFPD(vm->hfront_porch - 1) |
+  VIDTCON1_HSPW(vm->hsync_len - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);

/* setup horizontal and vertical display size. */
-   val = VIDTCON2_LINEVAL(timing->yres - 1) |
-  VIDTCON2_HOZVAL(timing->xres - 1) |
-  VIDTCON2_LINEVAL_E(timing->yres - 1) |
-  VIDTCON2_HOZVAL_E(timing->xres - 1);
+   val = VIDTCON2_LINEVAL(vm->vactive - 1) |
+  VIDTCON2_HOZVAL(vm->hactive - 1) |
+  VIDTCON2_LINEVAL_E(vm->vactive - 1) |
+

[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree

Hi,

This patch series adds signal polarities parsing from display-timings
devicetree node. To do it efficiently struct fb_videomode is replaced
with struct videomode and some additional code cleaning is performed.

The patches are for drm-exynos/exynos-drm-next branch.

Regards
Andrzej Hajda

Andrzej Hajda (3):
  drm/exynos: fimd: replace struct fb_videomode with videomode
  drm/exynos: fimd: get signal polarities from device tree
  drm/exynos: fimd: move platform data parsing to separate function

 drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 189 +-
 include/drm/exynos_drm.h  |   3 +-
 3 files changed, 103 insertions(+), 122 deletions(-)

-- 
1.8.1.2

[PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support

2013-08-21 Thread David Herrmann

Hi

On Wed, Aug 21, 2013 at 12:33 PM, Inki Dae  wrote:
> This patch adds lock and poll callbacks to dma buf file operations,
> and these callbacks will be called by fcntl and select system calls.
>
> fcntl and select system calls can be used to wait for the completion
> of DMA or CPU access to a shared dmabuf. The difference of them is
> fcntl system call takes a lock after the completion but select system
> call doesn't. So in case of fcntl system call, it's useful when a task
> wants to access a shared dmabuf without any broken. On the other hand,
> it's useful when a task wants to just wait for the completion.

1)
So how is that supposed to work in user-space? I don't want to block
on a buffer, but get notified once I can lock it. So I do:
  select(..dmabuf..)
Once it is finished, I want to use it:
  flock(..dmabuf..)
However, how can I guarantee the flock will not block? Some other
process might have locked it in between. So I do a non-blocking
flock() and if it fails I wait again? Looks ugly and un-predictable.

2)
What do I do if some user-space program holds a lock and dead-locks?

3)
How do we do modesetting in atomic-context in the kernel? There is no
way to lock the object. But this is required for panic-handlers and
more importantly the kdb debugging hooks.
Ok, I can live with that being racy, but would still be nice to be considered.

4)
Why do we need locks? Aren't fences enough? That is, in which
situation is a lock really needed?
If we assume we have two writers A and B (DMA, CPU, GPU, whatever) and
they have no synchronization on their own. What do we win by
synchronizing their writes? Ok, yeah, we end up with either A or B and
not a mixture of both. But if we cannot predict whether we get A or B,
I don't know why we care at all? It's random, so a mixture would be
fine, too, wouldn't it?

So if user-space doesn't have any synchronization on its own, I don't
see why we need an implicit sync on a dma-buf. Could you describe a
more elaborate use-case?

I think the problems we need to fix are read/write syncs. So we have a
write that issues the DMA+write plus a fence and passes the buf plus
fence to the reader. The reader waits for the fence and then issues
the read plus fence. It passes the fence back to the writer. The
writer waits for the fence again and then issues the next write if
required.

This has the following advantages:
 - fences are _guaranteed_ to finish in a given time period. Locks, on
the other hand, might never be freed (of the holder dead-locks, for
instance)
 - you avoid any stalls. That is, if a writer releases a buffer and
immediately locks it again, the reader side might stall if it didn't
lock it in exactly the given window. You have no control to guarantee
the reader ever gets access. You would need a synchronization in
user-space between the writer and reader to guarantee that. This makes
the whole lock useles, doesn't it?

Cheers
David

> Changelog v2:
> - Add select system call support.
>   . The purpose of this feature is to wait for the completion of DMA or
> CPU access to a dmabuf without that caller locks the dmabuf again
> after the completion.
> That is useful when caller wants to be aware of the completion of
> DMA access to the dmabuf, and the caller doesn't use intefaces for
> the DMA device driver.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/base/dma-buf.c |   81 
> 
>  1 files changed, 81 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 4aca57a..f16a396 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  static inline int is_dma_buf_file(struct file *);
> @@ -80,9 +81,89 @@ static int dma_buf_mmap_internal(struct file *file, struct 
> vm_area_struct *vma)
> return dmabuf->ops->mmap(dmabuf, vma);
>  }
>
> +static unsigned int dma_buf_poll(struct file *filp,
> +   struct poll_table_struct *poll)
> +{
> +   struct dma_buf *dmabuf;
> +   struct dmabuf_sync_reservation *robj;
> +   int ret = 0;
> +
> +   if (!is_dma_buf_file(filp))
> +   return POLLERR;
> +
> +   dmabuf = filp->private_data;
> +   if (!dmabuf || !dmabuf->sync)
> +   return POLLERR;
> +
> +   robj = dmabuf->sync;
> +
> +   mutex_lock(>lock);
> +
> +   robj->polled = true;
> +
> +   /*
> +* CPU or DMA access to this buffer has been completed, and
> +* the blocked task has been waked up. Return poll event
> +* so that the task can get out of select().
> +*/
> +   if (robj->poll_event) {
> +   robj->poll_event = false;
> +   mutex_unlock(>lock);
> +   return POLLIN | POLLOUT;
> +   }
> +
> +   /*
> +* There is no anyone accessing this buffer so

DPM on Radeon HD6570

On Wed, Aug 21, 2013 at 1:49 PM, Boszormenyi Zoltan  wrote:
> Hi,
>
> thanks for your response.
>
> 2013-08-21 17:39 keltez?ssel, Alex Deucher ?rta:
>
>> On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan 
>> wrote:
>>>
>>> Hi,
>>>
>>> I read this Phoronix article:
>>> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>>>
>>> Congrats to the progress achieved so far.
>>>
>>> However, I can see an interesting deviation for HD6570 from the
>>> observed trend of other chips.
>>>
>>> r600g can reach 80+ percent of the performance of Catalyst
>>> for most HD6xxx chips except for 6570, where the performance
>>> is around 10-20 percent.
>>>
>>> Do you have a theory about this difference?
>>> Maybe DPM doesn't work as intended on HD6570?
>>>
>> Are you seeing the same results on your board?  If so are the results
>> roughly the same with dpm enabled vs. disabled?  If so I doubt there
>> is a problem with dpm.  On older dGPUs like this one dpm won't really
>> improve performance since the cards come up with relatively high
>> clocks by default.  It's mainly for saving power when the GPU is idle.
>
>
> I have enabled dpm:
> $ cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
> root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1
> radeon.dpm=1 LANG=hu_HU.UTF-8
>
> I have just tried "openarena 0.8.5" again with forced "low" performance.
> Results is 26.87fps with low performance, 59.40-59.70fps with forced high
> performance.
>

Sounds like you are refresh rate limited.  Try disabling
swapbufferswait in your xorg.conf:

Section "Device"
Identifier  "card0"
Driver  "iradeon"
Option "SwapbuffersWait" "false"
EndSection

and disable vsync in the 3D driver, set env var:
vblank_mode=0

Also what does the performance look like with dpm disabled?

Anyway, it doesn't sound like dpm is an issue.

Alex

>
>>
>>> I have this kind of video card, so I wanted to test it myself.
>>> The exact model of my card is:
>>>
>>> http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#
>>>
>> Note that a lot of 6570 cards, including yours use DD3 memory rather
>> than GDDR5 so they will have fairly limited memory bandwidth.
>
>
> I know. The 6570 tested by Phoronix must be GDDR5
> but it's not mentioned specifically.
>
> Best regards,
> Zolt?n B?sz?rm?nyi
>
>
>>
>> Alex
>>
>>> I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=457463
>>>
>>> I haven't tested Catalyst but my r600g results mostly match
>>> the ones in the article even with a different CPU.
>>>
>>> Best regards,
>>> Zolt?n B?sz?rm?nyi
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

Hi Simon,

On Wednesday 21 August 2013 17:36:12 Simon Horman wrote:
> On Sat, Aug 10, 2013 at 07:28:30AM +1000, Dave Airlie wrote:
> > On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart wrote:
> > > On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
> > >> On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman wrote:
> > >> > On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
> > >> >> Hi Dave,
> > >> >> 
> > >> >> (CC'ing Simon Horman, the shmobile tree maintainer)
> > >> >> 
> > >> >> On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
> > >> >> > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
> > >> >> > > Hi Dave,
> > >> >> > > 
> > >> >> > > I've got a couple of arch/arm/ patches that depend on this
> > >> >> > > series and that I would like to get merged in v3.12. They should
> > >> >> > > go upstream through the arm-soc tree. Would you be able to
> > >> >> > > provide a stable branch with this patch set based on one of the
> > >> >> > > 3.11-rcX tags ?
> > >> >> > > Ideally that branch should have as little patches as possible
> > >> >> > > other than this set.
> > >> >> > 
> > >> >> > Yeah that shouldn't be a problem, though is there any interface
> > >> >> > changes or things with this wrt drm-next?
> > >> >> > 
> > >> >> > i.e. will this tree build on v3.11-rcX and drm-next?
> > >> >> 
> > >> >> They depend on a fix that went in between -rc1 and -rc2. You can
> > >> >> base the branch on any -rc >= 2.
> > >> > 
> > >> > An rc2 or rc3 base would be ideal for me, but any rc would be fine.
> > >> 
> > >> So the problem with making a stable branch is we have conflicts in
> > >> other places that have already been solved in drm-next,
> > >> 
> > >> is there any problem with using Laurent's tree directly as the stable
> > >> point?
> > >
> > > As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and
> > > pushed the result to
> > > 
> > > git://linuxtv.org/pinchartl/fbdev.git drm/next/du
> > >  
> > >  b/drivers/gpu/drm/rcar-du/Kconfig   |7
> > >  b/drivers/gpu/drm/rcar-du/Makefile  |   10 -
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 ++--
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
> > >  b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
> > >  b/include/linux/platform_data/rcar-du.h |   34 ++-
> > >  drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 
> > >  drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
> > >  drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
> > >  drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
> > >  27 files changed, 1665 insertions(+), 861 deletions(-)
> > > 
> > > Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/
> > > patches on top of this drm/next/du branch.
> > 
> > Actually small change
> > 
> > Simon can you use
> > 
> > git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12
> > 
> > as I've merged this tree with an S-o-b on the merge commit, so other
> > people will know it has gone via me.
> 
> Sorry for the delayed response.
> 
> I had assumed that the reason I was having trouble fetching
> the remote above was related to the internet connection at the
> end of the world that I was in turn at the end while on holidays.
> 
> However, it seems that I am unable to fetch the remote from my office
> either. This may well be a fault at my end, but its not something
> I can readily think of a work around for other than trying from home a
> little later.
> 
> # git remote add airlied git://git.freedesktop.org/~airlied/linux
> # git fetch airlied
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

The URL I use is

[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module

2013-08-21 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #10 from Alex Deucher  ---
Glad it's working.  Please mark this bug as a duplicate of bug 60674.

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

[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

2013-08-21 Thread Liu Ying

On 08/20/2013 11:40 PM, Fabio Estevam wrote:
> On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying  wrote:
> 
>> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt 
>> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> index 5a90a72..90e923e 100644
>> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
>> @@ -89,8 +89,6 @@ clocks and IDs.
>> gpu3d_shader74
>> ipu1_podf   75
>> ipu2_podf   76
>> -   ldb_di0_podf77
>> -   ldb_di1_podf78
>> ipu1_di0_pre79
>> ipu1_di1_pre80
>> ipu2_di0_pre81
> 
> This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
> 

I find there is a 'hole' in 
Documentation/devicetree/bindings/clock/imx5-clock.txt as well.
The 'hole' was taken by tve_di(26) clock before.

Is this more acceptable?

ldb_di0_podf_unused77
ldb_di1_podf_unused78

Liu Ying

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

2013-08-21 Thread Martin Peres

On 16/08/2013 09:14, Pali Roh?r wrote:
> On Thursday 15 August 2013 18:21:51 Martin Peres wrote:
>> On 15/08/2013 03:24, Pali Roh?r wrote:
>>> On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
 On 14/08/2013 05:02, Pali Roh?r wrote:
> On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
>> On 13/08/2013 09:53, Pali Roh?r wrote:
>>> On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
> wrote:
 On 13/08/2013 09:23, Pali Roh?r wrote:
> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
 ...

 You can check the temperature by running nvidia-settings.
 If you can't see the temperature in it, then nvidia
 doesn't support it on your card and
 I'm not sure we should :s

 Thanks for the vbios you sent me in private. For the
 others, the reason why he doesn't have temperature
 anymore is because his vbios lacks sensor calibration
 values.
>>> In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
>>> "Thermal Settings" is:
>>>
>>> Thermal Sensor Information:
>>> ID: 0
>>> Target: GPU
>>> Provider: GPU Internal
>>> Temperature: 70 C (now)
>>>
>>> I looked in Windows program SpeedFan. It found Nvidia PCI
>>> card and reported "GPU Temp" about 68-70 C. So it looks
>>> like both nvidia driver and windows SpeedFan program
>>> reading same values.
>> Great, I'll cook you a patch in a bit and you'll see what
>> the temperature is like. It won't be perfectly accurate
>> but there is some kind of default for nvidia cards of this
>> generation.
> Ok, send me patch and I can try it if it will work and
> report similar values as windows or nvidia driver.
 Sorry for the late answer.

 Please test this patch. Be aware that temperature with nouveau
 will be higher than with the blob.
 I only want to see if nouveau reports a temperature.

 The only way to be sure if the values are good-enough would be
 to use the blob and run:
 nvapeek 0x15b0
 Please send me the result along with the temperature reported
 by nvidia at the time of the peek.

 Martin

 PS: This patch has only be compile-tested, I don't have access
 to an nv4x right now.
>>> Hello,
>>>
>>> now after patch nouveau report temperature:
>>>
>>> $ sensors
>>> ...
>>> nouveau-pci-0500
>>> Adapter: PCI adapter
>>> temp1:+63.0?C  (high = +95.0?C, hyst =  +3.0?C)
>>>
>>>  (crit = +145.0?C, hyst =  +2.0?C)
>>>  (emerg = +135.0?C, hyst =  +5.0?C)
>> Ok, that was expected ;)
>>
>>> ...
>>>
>>> I found that nvidia binary driver has command line utility
>>> nvidia-smi which report same temperature as X utility nvidia-
>>> settings. So I will use nvidia-smi (if it is OK).
>>>
>>> And after reboot nvidia report another temperature value:
>>>
>>> $ nvidia-smi -q -d TEMPERATURE
>>> ...
>>> GPU :05:00.0
>>>
>>>   Temperature
>>>   
>>>   Gpu : 70 C
>>>
>>> Immediately I called nvapeek command:
>>>
>>> $ nvapeek 0x15b0
>>> 15b0: 108e
>>>
>>> So value reported by nouveau is lower than value reported by
>>> nvidia binary driver.
>> As you didn't run nvapeek 15b0 when running nouveau it is hard to tell
>> if it is due to
>> calibration values or because the temperature was lower.
>>
> I run it and it always reported value 00ff (also when temperature 
> changed).

Seems like we may not calibrate the ADC correctly, this is weird.
>
>> Could you please read the temperature + peek 15b0 when running nouveau?
>>
>> Anyway, it is weird because I cannot find 70?C with 0x8e as an input
>> temperature and with
>> the current default values :o
>>
> My idea is that register does not contains temperature. Both nouveau and
> nvidia driver when show different temperature it does not show different 
> output
> from "nvapeek 0x15b0".
>
> Now I started computer with nouveau driver. Temperature is incresing, but
> nvapeek 0x15b0 is still same.
>
> So do you really needs other tests with nvapeek 0x15b0? Is that register
> correct?

I want you to be really sure that 15b0 doesn't change with temperature 
ON THE
PROPRIETARY driver. This is very serious if this is not the case.

If this is not the case, then you must have an i2c device from which the 
blob is
reading temperature and this device isn't detected by Nouveau.

[PATCH 0/3] refactor some ldb related clocks

2013-08-21 Thread Liu Ying

On 08/21/2013 09:59 AM, Shawn Guo wrote:
> Hi Ying,
> 
> On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
>>> While I admit to having introduced the combination of 1/3.5 fixed
>>> divider and configurable 1/1,1/2 divder clocks to describe this
>>> fractional divider for the reasons you state, I think the correct
>>> solution would be to improve the table divider to support fractional
>>> values and get rid of the virtual ldb_di_div_3_5 clocks, not
>>> introduce more virtual clocks.
>>
>> Yes, it's good to support fractional values for the table divider(not sure 
>> if there is any plan for this).
>> I see there is something similar in 'include/linux/sh_clk.h'.
> 
> Yeah, I agree with Philipp on improving table divider to support
> fractional values.  Would you like to work on that?
> 
> Shawn
> 

I don't have a plan to work on that now.

Liu Ying

DPM on Radeon HD6570

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan  wrote:
> Hi,
>
> I read this Phoronix article:
> http://www.phoronix.com/scan.php?page=article=amd_hd6000_dpm=1
>
> Congrats to the progress achieved so far.
>
> However, I can see an interesting deviation for HD6570 from the
> observed trend of other chips.
>
> r600g can reach 80+ percent of the performance of Catalyst
> for most HD6xxx chips except for 6570, where the performance
> is around 10-20 percent.
>
> Do you have a theory about this difference?
> Maybe DPM doesn't work as intended on HD6570?
>

Are you seeing the same results on your board?  If so are the results
roughly the same with dpm enabled vs. disabled?  If so I doubt there
is a problem with dpm.  On older dGPUs like this one dpm won't really
improve performance since the cards come up with relatively high
clocks by default.  It's mainly for saving power when the GPU is idle.

> I have this kind of video card, so I wanted to test it myself.
> The exact model of my card is:
> http://www.sapphiretech.com/presentation/product/?cid=1=3=1087=1176==1=0#
>

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

Alex

> I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=457463
>
> I haven't tested Catalyst but my r600g results mostly match
> the ones in the article even with a different CPU.
>
> Best regards,
> Zolt?n B?sz?rm?nyi
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH/RFC v3 06/19] video: display: OF support

2013-08-21 Thread Philipp Zabel

Hi Laurent,

Am Mittwoch, den 21.08.2013, 03:02 +0200 schrieb Laurent Pinchart:
> Hi Philipp,
> 
> On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> > Hi Laurent,
> > 
> > thanks for this update. I'm very happy about the move to the display entity
> > model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
> > in a single device - this will allow to use a unified device tree binding
> > scheme.
> 
> Thanks for the support :-)
> 
> > I'm still trying to see how this all fits together, so far I have only one
> > comment, below.
> > 
> > Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
> > [...]
> > 
> > > +static int display_of_parse_dt(struct display_entity_notifier *notifier,
> > > +struct list_head *entities,
> > > +struct device_node *node)
> > > +{
> > > + struct display_entity_of *entity;
> > > + struct device_node *remote;
> > > + struct device_node *ep = NULL;
> > > + struct device_node *next;
> > > + unsigned int num_entities = 0;
> > > + int ret = 0;
> > > +
> > > + /* Walk the device tree and build a list of nodes. */
> > > + dev_dbg(notifier->dev, "parsing node %s\n", node->full_name);
> > > +
> > > + while (1) {
> > > + next = display_of_get_next_endpoint(node, ep);
> > > + if (next == NULL)
> > > + break;
> > > +
> > > + of_node_put(ep);
> > > + ep = next;
> > > +
> > > + dev_dbg(notifier->dev, "handling endpoint %s\n", ep->full_name);
> > > +
> > > + remote = display_of_get_remote_port_parent(ep);
> > > + if (remote == NULL)
> > > + continue;
> > > +
> > > + /* Skip entities that we have already processed. */
> > > + if (display_of_find_entity(entities, remote) || remote == node) 
> > > {
> > > + dev_dbg(notifier->dev,
> > > + "entity %s already in list, skipping\n",
> > > + remote->full_name);
> > > + continue;
> > > + }
> > 
> > device tree nodes with status = "disabled" should be skipped here:
> > 
> > if (!of_device_is_available(remote)) {
> > dev_dbg(notifier->dev,
> > "entity %s is disabled, skipping\n",
> > remote->full_name);
> > continue;
> > }
> > 
> > Otherwise the completion notification will never be delivered if there
> > are any disabled entities in the graph.
> 
> That's a good point, but if a device is disabled, why would it be in the DT 
> graph in the first place ? Do you have a use case for this ?

This is mostly about separate encoders inside the SoC, which are always
present but not useful unless the board designer connected something to
the external pads. Those might be contained in the SoC .dtsi but have
status = "disabled" set for board device tree writers' convenience.
My use case would be the LVDS encoder bridge or the Synopsys Designware
HDMI TX on i.MX6.

regards
Philipp

[PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework

2013-08-21 Thread Konrad Rzeszutek Wilk

> > > +EXPORT_SYMBOL(is_dmabuf_sync_supported);
> > 
> > _GPL ?
> > 
> > I would also prefix it with 'dmabuf_is_sync_supported' just to make
> > all of the libraries call start with 'dmabuf'
> > 
> 
> Seems better. Will change it to dmabuf_is_sync_supported, and use
> EXPORT_SYMBOL_GPL.

One thing thought - while I suggest that you use GPL variant
I think you should check who the consumers are. As in, if nvidia
wants to use it it might make their lawyers unhappy - and in turn
means that their engineers won't be able to use these symbols.

So - if there is a strong argument to not have it GPL - then please
say so.

[PATCH] nouveau: fix reclocking on nv40

2013-08-21 Thread Ben Skeggs

On Mon, Aug 19, 2013 at 4:59 PM, Pali Roh?r  wrote:
> On Friday 16 August 2013 14:57:07 Pali Roh?r wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from pll_calc to ret.
>>
>> Signed-off-by: Pali Roh?r 
>> Signed-off-by: Martin Peres 
>> ---
>>  drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
>> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
>> 100644
>> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
>> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
>> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
>> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>>   pll->vco2.max_freq = 0;
>>
>> - pclk->pll_calc(pclk, pll, clk, );
>> + ret = pclk->pll_calc(pclk, pll, clk, );
>>   if (ret == 0)
>>   return -ERANGE;
>
> Hello, it is possible to include this patch in 3.11?
> Or it is too late now and need to wait for 3.12?
I've picked up the patch and will submit it in my next 3.11-fixes pull request.

Thanks,
Ben.

>
> --
> Pali Roh?r
> pali.rohar at gmail.com
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 0/3] refactor some ldb related clocks

2013-08-21 Thread Shawn Guo

Hi Ying,

On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote:
> > While I admit to having introduced the combination of 1/3.5 fixed
> > divider and configurable 1/1,1/2 divder clocks to describe this
> > fractional divider for the reasons you state, I think the correct
> > solution would be to improve the table divider to support fractional
> > values and get rid of the virtual ldb_di_div_3_5 clocks, not
> > introduce more virtual clocks.
> 
> Yes, it's good to support fractional values for the table divider(not sure if 
> there is any plan for this).
> I see there is something similar in 'include/linux/sh_clk.h'.

Yeah, I agree with Philipp on improving table divider to support
fractional values.  Would you like to work on that?

Shawn

[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)

2013-08-21 Thread Michel Dänzer

On Die, 2013-08-20 at 13:16 -0400, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays.  Atombios tends to do things
> like:
> 
> struct object {
> u8 version;
> u8 num_elements;
> u32 elements[1]; /* num_elements entries */
> };
> 
> We then do things like the following in the driver code:
> 
> for (i = 0; i < atom_object->num_elements; i++) {
> driver_object[i] = atom_object->elements[i];
> }
> 
> With previous versions of gcc this used to work fine, but with
> 4.7 and 4.8, it seems to generate code that wanders off into the
> weeds.
> 
> According to:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> The traditional way of handling variably sized arrays (ISO C90)
> is to use an array length of 1.  Gcc allows you to use an array
> length of 0 and newer versions of gcc only seem to do the
> right thing when 0 is used.

[...]

> diff --git a/drivers/gpu/drm/radeon/atombios.h 
> b/drivers/gpu/drm/radeon/atombios.h
> index 16b120c..3f1f011 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
[...]
> @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE 
> //Above 4 object table
[...]
>  typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT 
> //usSrcDstTableOffset pointing to this structure
>  {
>UCHAR   ucNumberOfSrc;
> -  USHORT  usSrcObjectID[1];
> +  USHORT  usSrcObjectID[0];
>UCHAR   ucNumberOfDst;
> -  USHORT  usDstObjectID[1];
> +  USHORT  usDstObjectID[0];
>  }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

[...]

> @@ -6194,8 +6194,8 @@ typedef struct _ATOM_INIT_REG_INDEX_FORMAT{
>  typedef struct _ATOM_INIT_REG_BLOCK{
>   USHORT  
> usRegIndexTblSize;
>   
> //size of asRegIndexBuf
>   USHORT  
> usRegDataBlkSize; 
>   
> //size of ATOM_MEMORY_SETTING_DATA_BLOCK
> - ATOM_INIT_REG_INDEX_FORMAT  asRegIndexBuf[1];
> - ATOM_MEMORY_SETTING_DATA_BLOCK  asRegDataBuf[1];
> + ATOM_INIT_REG_INDEX_FORMAT  asRegIndexBuf[0];
> + ATOM_MEMORY_SETTING_DATA_BLOCK  asRegDataBuf[0];
>  }ATOM_INIT_REG_BLOCK;
>  
>  #define END_OF_REG_INDEX_BLOCK  0x0
> @@ -6938,8 +6938,8 @@ typedef struct _ATOM_DISP_OUT_INFO
>ATOM_COMMON_TABLE_HEADER sHeader;  
>   USHORT ptrTransmitterInfo;
>   USHORT ptrEncoderInfo;
> - ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
> - ASIC_ENCODER_INFO  asEncoderInfo[1];
> + ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
> + ASIC_ENCODER_INFO  asEncoderInfo[0];
>  }ATOM_DISP_OUT_INFO;
>  
>  typedef struct _ATOM_DISP_OUT_INFO_V2
> @@ -6948,8 +6948,8 @@ typedef struct _ATOM_DISP_OUT_INFO_V2
>   USHORT ptrTransmitterInfo;
>   USHORT ptrEncoderInfo;
>USHORT ptrMainCallParserFar;  // direct address of main 
> parser call in VBIOS binary. 
> - ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
> - ASIC_ENCODER_INFO  asEncoderInfo[1];
> + ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
> + ASIC_ENCODER_INFO  asEncoderInfo[0];
>  }ATOM_DISP_OUT_INFO_V2;

I'm not sure how these structs are supposed to work, before or after
this change... The compiler can't know how to access the fields after
the first variably-sized array?


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

2013-08-21 Thread Shawn Guo

On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote:
> Quoting Fabio Estevam (2013-08-20 08:40:52)
> > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying  wrote:
> > 
> > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt 
> > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > index 5a90a72..90e923e 100644
> > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> > > @@ -89,8 +89,6 @@ clocks and IDs.
> > > gpu3d_shader74
> > > ipu1_podf   75
> > > ipu2_podf   76
> > > -   ldb_di0_podf77
> > > -   ldb_di1_podf78
> > > ipu1_di0_pre79
> > > ipu1_di1_pre80
> > > ipu2_di0_pre81
> > 
> > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
> 
> How does this fit in with the idea of having a stable binding/ABI? Seems
> like changing this would be a bad idea for devices in the field that
> have older DTBs.

We should be safe since none of existing DTBs refers to the clocks (they
are not leaf clocks in the whole clock tree but some interconnection
ones).

Shawn

[PATCH/RFC v3 00/19] Common Display Framework

2013-08-21 Thread Sascha Hauer

On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
>  wrote:
> > Hi Rob,
> >
> >> Or maybe, put another way, I still think we should still optimize for the
> >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP 
> >> bridge
> >> in the capture path, and if you had something like an FPGA where that was
> >> cheap to do maybe you even would (for fun). But if in the real world, there
> >> are only one or two cases of actual hw using the same bridge in a capture
> >> pipeline which is normally used in display pipelines, then duplicating some
> >> small bit of code for that abnormal case if it makes things easier for the
> >> common case, seems like a reasonable trade-off to me.
> >
> > That was my opinion as well until I started working on a Xilinx platform.
> > There's dozens of IP cores there that are used in both capture and display
> > pipelines.
> 
> or maybe just some helper lib's to handling the register level programming?
> 
> Anyways, I guess you can call it a "worse is better" thing, but if you
> can get 90% of the desired effect for 10% of the work, take the
> simpler solution.  I don't think we should make things more layered or
> more difficult for one exceptional case.
> 
> 
> > Furthermore, FPGA display pipelines being made of individual IP cores, we 
> > need
> > a way to write one driver per IP core and make them all interact. The 
> > recently
> > proposed drm_bridge is one possible solution to this issue (and to a 
> > different
> > but similar issue that trigerred the development of drm_bridge), but it's in
> > my opinion not generic enough. We're facing several problems that are 
> > related,
> > it would really be a shame not to solve them with a good enough framework.
> 
> well, I've been working on DSI panel support in msm drm, and also been
> looking at the patches to add DSI support in i915.  And the panel
> interface ends up looking basically like the drm_bridge interface.
> Perhaps the only thing not generic there is the name.
> 
> >> I mean, take a DSI panel driver, for example.. anything but a trivial panel
> >> driver, you are going to want to expose some custom properties on the
> >> connector for controlling non-standard features. So you end up with both
> >> cdf_foo for the common part, and drm_foo for gluing in the properties. And
> >> now these two parts which otherwise would be one, end up having to stay in
> >> sync merged through different trees, etc. It seems a lot like making my 
> >> life
> >> more difficult for a fairly hypothetical gain ;-)
> >
> > The DSI panel driver should not be split into two parts. It should 
> > implement a
> > CDF entity, any glue needed for DRM will not be part of the panel driver.
> 
> right, but that glue ends up needing to be *somewhere*, which makes it
> the 2nd part.
> 
> >> Or, take an hdmi or DP bridge. To use any of the common
> >> infrastructure/helpers in drm, you end up implementing a generic interface,
> >> where both the producer and consumer is inside drm. Which just seems a bit
> >> pointless and extra hoops to jump through. Especially when we discover that
> >> we need to extend/enhance the common interface outside of drm to make it
> >> work. (I'm thinking of display_entity_control_ops::get_modes() here, but 
> >> I'm
> >> sure there are more examples.) And I think we'll run into similar issues
> >> with display_entity_control_ops::set_state(), since the on<->off sequencing
> >> can get hairy when the upstream/downstream entity is fed a clk by the
> >> downstream/upstream entity. And similarly, I think we'll go through a few
> >> revisions of DSI panel/bus params before we have everything that everyone
> >> needs.
> >
> > I don't see where needing multiple revisions of a patch set would be bad :-)
> 
> I mean over multiple kernel revisions, as people start adding support
> for new hw and run into limitations of the "framework".

A framework can be changed, extended and fixed. In the end we talking
about a completely in-kernel framework for which we do not have to
maintain a stable API.

> 
> We've already figured out that just having enable() and disable() is
> not sufficient for displayport link training.  I'm not sure what else
> we'll discover.

It's pretty much expected that other things will be discovered, but this
will also happen with all sub-drm-driver frameworks we currently have.

> 
> I'm not saying not to solve (most of these) problems.. I don't think
> chaining multiple drm_bridge's is impossible, I can think of at least
> two ways to implement it.  But I think we should solve that as someone
> is adding support for hw that uses this.  This (a) lets us break
> things up into smaller more incremental changes (drm_bridge is
> *considerably* smaller than the current CDF patchset), and (b) avoids
> us solving the wrong problems.
> 
> btw, I think DT bindings is orthogonal to this discussion.

Not really. The common display framework is

[PATCH/RFC v3 00/19] Common Display Framework

2013-08-21 Thread Rob Clark

On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer  wrote:
> On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
>> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
>>  wrote:
>> > Hi Rob,
>> >
>> >> Or maybe, put another way, I still think we should still optimize for the
>> >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP 
>> >> bridge
>> >> in the capture path, and if you had something like an FPGA where that was
>> >> cheap to do maybe you even would (for fun). But if in the real world, 
>> >> there
>> >> are only one or two cases of actual hw using the same bridge in a capture
>> >> pipeline which is normally used in display pipelines, then duplicating 
>> >> some
>> >> small bit of code for that abnormal case if it makes things easier for the
>> >> common case, seems like a reasonable trade-off to me.
>> >
>> > That was my opinion as well until I started working on a Xilinx platform.
>> > There's dozens of IP cores there that are used in both capture and display
>> > pipelines.
>>
>> or maybe just some helper lib's to handling the register level programming?
>>
>> Anyways, I guess you can call it a "worse is better" thing, but if you
>> can get 90% of the desired effect for 10% of the work, take the
>> simpler solution.  I don't think we should make things more layered or
>> more difficult for one exceptional case.
>>
>>
>> > Furthermore, FPGA display pipelines being made of individual IP cores, we 
>> > need
>> > a way to write one driver per IP core and make them all interact. The 
>> > recently
>> > proposed drm_bridge is one possible solution to this issue (and to a 
>> > different
>> > but similar issue that trigerred the development of drm_bridge), but it's 
>> > in
>> > my opinion not generic enough. We're facing several problems that are 
>> > related,
>> > it would really be a shame not to solve them with a good enough framework.
>>
>> well, I've been working on DSI panel support in msm drm, and also been
>> looking at the patches to add DSI support in i915.  And the panel
>> interface ends up looking basically like the drm_bridge interface.
>> Perhaps the only thing not generic there is the name.
>>
>> >> I mean, take a DSI panel driver, for example.. anything but a trivial 
>> >> panel
>> >> driver, you are going to want to expose some custom properties on the
>> >> connector for controlling non-standard features. So you end up with both
>> >> cdf_foo for the common part, and drm_foo for gluing in the properties. And
>> >> now these two parts which otherwise would be one, end up having to stay in
>> >> sync merged through different trees, etc. It seems a lot like making my 
>> >> life
>> >> more difficult for a fairly hypothetical gain ;-)
>> >
>> > The DSI panel driver should not be split into two parts. It should 
>> > implement a
>> > CDF entity, any glue needed for DRM will not be part of the panel driver.
>>
>> right, but that glue ends up needing to be *somewhere*, which makes it
>> the 2nd part.
>>
>> >> Or, take an hdmi or DP bridge. To use any of the common
>> >> infrastructure/helpers in drm, you end up implementing a generic 
>> >> interface,
>> >> where both the producer and consumer is inside drm. Which just seems a bit
>> >> pointless and extra hoops to jump through. Especially when we discover 
>> >> that
>> >> we need to extend/enhance the common interface outside of drm to make it
>> >> work. (I'm thinking of display_entity_control_ops::get_modes() here, but 
>> >> I'm
>> >> sure there are more examples.) And I think we'll run into similar issues
>> >> with display_entity_control_ops::set_state(), since the on<->off 
>> >> sequencing
>> >> can get hairy when the upstream/downstream entity is fed a clk by the
>> >> downstream/upstream entity. And similarly, I think we'll go through a few
>> >> revisions of DSI panel/bus params before we have everything that everyone
>> >> needs.
>> >
>> > I don't see where needing multiple revisions of a patch set would be bad 
>> > :-)
>>
>> I mean over multiple kernel revisions, as people start adding support
>> for new hw and run into limitations of the "framework".
>
> A framework can be changed, extended and fixed. In the end we talking
> about a completely in-kernel framework for which we do not have to
> maintain a stable API.

oh sure, this is why I'd be absolutely against exposing this to
userspace currently..

But my only point here was that an in-drm framework, all the fix-ups
due to a framework change are sorted out before Dave sends his pull
req to linus.  We do this on a semi-regular basis already in drm
already.

Anyways, not a show-stopper thing.. just (in my mind) one additional
inconvenience (and not really the biggest one) about having the
"framework" outside of drm.  I'm more concerned about just having the
"display entity" code at a layer below the helpers and property api's
that I'd like to use in drm.

And just to be clear, part of my negative experience about this is the
omapdss/omapdrm

[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module

2013-08-21 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #9 from Eastern Heart  ---
(In reply to Alex Deucher from comment #8)
> (In reply to Eastern Heart from comment #7)
> > 
> > Although I haven't apply this patch, can I ask: will this patch be merged to
> > linux-3.10.7?
> 
> It should make it's way to 3.10 eventually.  I'm not sure which 3.10.x
> version it will end up in.

Today I have get my Compaq 511 back. The patch works! And I'm trying to enjoy
uvd hardware decode.

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

[Bug 66967] Dota 2 crashes with r600g when starting the tutorial

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

--- Comment #4 from Tilman Sauerbeck  ---
(In reply to comment #3)
> I'm not sure if I and others experience the same problem as you, but when I
> try to start the first tutorial mission in DotA 2 (or change the resolution
> in the options menu), the game crashes.

I can change the resolution just fine.

> It seems to boil down to a general shader issue with Mesa, as users with
> Intel & R600 drivers are having the problems. When one delete certain shader
> files the game will start.

Nope, deleting/renaming the fxc subdirectory doesn't help on my system.

Looks like I'm seeing a different problem than you are.

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

[PATCH/RFC v3 06/19] video: display: OF support

Hi Philipp,

On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> Hi Laurent,
> 
> thanks for this update. I'm very happy about the move to the display entity
> model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
> in a single device - this will allow to use a unified device tree binding
> scheme.

Thanks for the support :-)

> I'm still trying to see how this all fits together, so far I have only one
> comment, below.
> 
> Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
> [...]
> 
> > +static int display_of_parse_dt(struct display_entity_notifier *notifier,
> > +  struct list_head *entities,
> > +  struct device_node *node)
> > +{
> > +   struct display_entity_of *entity;
> > +   struct device_node *remote;
> > +   struct device_node *ep = NULL;
> > +   struct device_node *next;
> > +   unsigned int num_entities = 0;
> > +   int ret = 0;
> > +
> > +   /* Walk the device tree and build a list of nodes. */
> > +   dev_dbg(notifier->dev, "parsing node %s\n", node->full_name);
> > +
> > +   while (1) {
> > +   next = display_of_get_next_endpoint(node, ep);
> > +   if (next == NULL)
> > +   break;
> > +
> > +   of_node_put(ep);
> > +   ep = next;
> > +
> > +   dev_dbg(notifier->dev, "handling endpoint %s\n", ep->full_name);
> > +
> > +   remote = display_of_get_remote_port_parent(ep);
> > +   if (remote == NULL)
> > +   continue;
> > +
> > +   /* Skip entities that we have already processed. */
> > +   if (display_of_find_entity(entities, remote) || remote == node) 
> > {
> > +   dev_dbg(notifier->dev,
> > +   "entity %s already in list, skipping\n",
> > +   remote->full_name);
> > +   continue;
> > +   }
> 
> device tree nodes with status = "disabled" should be skipped here:
> 
> if (!of_device_is_available(remote)) {
> dev_dbg(notifier->dev,
> "entity %s is disabled, skipping\n",
> remote->full_name);
> continue;
> }
> 
> Otherwise the completion notification will never be delivered if there
> are any disabled entities in the graph.

That's a good point, but if a device is disabled, why would it be in the DT 
graph in the first place ? Do you have a use case for this ?

> > +   entity = kzalloc(sizeof(*entity), GFP_KERNEL);
> > +   if (entity == NULL) {
> > +   of_node_put(remote);
> > +   ret = -ENOMEM;
> > +   break;
> > +   }
> > +
> > +   dev_dbg(notifier->dev, "adding remote entity %s to list\n",
> > +   remote->full_name);
> > +
> > +   entity->node = remote;
> > +   list_add_tail(>list, entities);
> > +   num_entities++;
> > +   }
> > +
> > +   of_node_put(ep);
> > +
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   return num_entities;
> > +}
> 
> [...]

-- 
Regards,

Laurent Pinchart

[PATCH 0/2] update pixel format setting to fimd driver

2013-08-21 Thread Tomasz Figa

Hi Inki,

On Tuesday 20 of August 2013 14:45:10 Inki Dae wrote:
> This patch series fix pixel format setting according to
> drm_framebuffer's pixel_format, and check if a given window
> supports alpha channel or not.
> 
> Inki Dae (2):
>   drm/exynos: fix fimd pixel format setting
>   drm/exynos: check a pixel format to a particular window layer
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   45
> -- 1 files changed, 24 insertions(+), 21
> deletions(-)

For the whole series:

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

[Bug 67994] Lockup with UVD and DPM on RV730

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

--- Comment #11 from Timoth?e Ravier  ---
Created attachment 84362
  --> https://bugs.freedesktop.org/attachment.cgi?id=84362=edit
X server logs

Note: if I quickly kill the second mplayer right after the start of the video I
can avoid the crash, but UVD won't work anymore and mplayer will permanently
end with some errors (if VDPAU is forced):

Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU
acceleration) [libavcodec]
Selected audio codec: ATSC A/52A (AC-3) [libavcodec]
AUDIO: 48000 Hz, 2 ch, floatle, 384.0 kbit/12.50% (ratio: 48000->384000)
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
VIDEO:  1280x720  23.976 fps0.0 kbps ( 0.0 kB/s)
VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration 
[   vdpau] Failed creating VDPAU decoder: An invalid/unsupported
VdpDecoderProfile value was supplied.
FATAL: Cannot initialize video driver.
VIDEO:  1280x720  23.976 fps0.0 kbps ( 0.0 kB/s)
VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration 
[   vdpau] Failed creating VDPAU decoder: An invalid/unsupported
VdpDecoderProfile value was supplied.
FATAL: Cannot initialize video driver.
[h264_vdpau @ 0x7f736c111cc0]decode_slice_header error
[h264_vdpau @ 0x7f736c111cc0]no frame!
Error while decoding frame!

FATAL: Could not initialize video filters (-vf) or video output (-vo).

But right after that my X session was killed and the X server kept exiting with
bus errors when starting new ones (see attached log).

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

Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support

Hi Rob,

On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
 On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
  MIPI DBI is a configurable-width parallel display bus that transmits
  commands and data.
  
  Add a new DBI Linux bus type that implements the usual bus
  infrastructure (including devices and drivers (un)registration and
  matching, and bus configuration and access functions).
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
  
   drivers/video/display/Kconfig|   8 ++
   drivers/video/display/Makefile   |   1 +
   drivers/video/display/mipi-dbi-bus.c | 234 ++
   include/video/display.h  |   4 +
   include/video/mipi-dbi-bus.h | 125 +++
   5 files changed, 372 insertions(+)
   create mode 100644 drivers/video/display/mipi-dbi-bus.c
   create mode 100644 include/video/mipi-dbi-bus.h

[snip]

  diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h
  new file mode 100644
  index 000..876b69d
  --- /dev/null
  +++ b/include/video/mipi-dbi-bus.h

[snip]

  +struct mipi_dbi_device {
  +   const char *name;
  +   int id;
  +   struct device dev;
 
 just fwiw, we need the framework to be agnostic of the association between
 devices and entities in the framework. Some things that are multiple
 entities may actually map to a single device in hw

I haven't written down that requirement, but I've kept it in mind while 
designing CDF. We have similar use cases in V4L2.

 (and possibly visa versa?).

I don't think that would be needed, but if you can think of a use case I'm all 
ears.

 Otherwise we end up having to create fake devices in some cases. Really the
 entities, or objects, or whatever you call 'em should just extend some
 kref'd base class. Sort of like how existing kms objects extend
 drm_mode_object.

struct display_entity {
struct list_head list;
struct device *dev;
struct module *owner;
struct kref ref;

char name[32];
struct media_entity entity;

const struct display_entity_ops *ops;

void(*release)(struct display_entity *ent);
};

(from patch 02/19)

 So any 'struct device' moves down into the derived class, not in the base
 class. Configuration data is passed in separate, not grabbed out of dev-
 platform_data, etc. Probably there is room for some helpers to pull stuff
 out of DT/ACPI/whatever.

struct mipi_dbi_device is not a display entity, it's a physical device plugged 
on a DBI bus. It's thus similar in purpose to struct pci_device or struct 
platform_device. The DBI device driver will then create one or more display 
entities depending on its needs.

  +   const struct mipi_dbi_device_id *id_entry;
  +   struct mipi_dbi_bus *bus;
  +
  +   unsigned int flags;
  +   unsigned int bus_width;
  +   unsigned int data_width;
  +};

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH/RFC v3 00/19] Common Display Framework

Hi Rob,

On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
 On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
  Hi everybody,
  
  Here's the third RFC of the Common Display Framework.
  
  I won't repeat all the background information from the versions one and
  two here, you can read it at http://lwn.net/Articles/512363/ and
  http://lwn.net/Articles/526965/.
  
  This RFC isn't final. Given the high interest in CDF and the urgent tasks
  that kept delaying the next version of the patch set, I've decided to
  release v3 before completing all parts of the implementation. Known
  missing items are
  
  - documentation: kerneldoc and this cover letter should provide basic
information, more extensive documentation will likely make it to v4.
  
  - pipeline configuration and control: generic code to configure and
control display pipelines (in a nutshell, translating high-level mode
setting and DPMS calls to low-level entity operations) is missing. Video
and stream control operations have been carried over from v2, but will
need to be revised for v4.
  
  - DSI support: I still have no DSI hardware I can easily test the code on.
 
 tbh, I kinda think that DSI and bridge chips are the things we should focus
 on first.. that seems what is most important for current and new hardware. 
 Back-filling to handle older/simpler panels can be done later.

That sounds reasonable (although I still believe DSI is only part of the 
issue), but I'll need help with that, as the Renesas platforms I work on don't 
have a DSI bus.

  Special thanks go to
  
  - Renesas for inviting me to LinuxCon Japan 2013 where I had the
opportunity to validate the CDF v3 concepts with Alexandre Courbot
(NVidia) and Tomasz Figa (Samsung).
  
  - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me.
  
  - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we
had  there greatly helped moving CDF forward.
  
  - And of course all the developers who showed interest in CDF and spent
time sharing ideas, reviewing patches and testing code.
  
  I have to confess I was a bit lost and discouraged after all the CDF-
  related meetings during which we have discussed how to move from v2 to v3.
  With every meeting I was hoping to run the implementation through use
  cases of various interesting parties and narrow down the scope of the huge
  fuzzy beast that CDF was. With every meeting the scope actually broadened,
  with no clear path at sight anywhere.
  
  Earlier this year I was about to drop one of the requirements on which I
  had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two
  HDMI transmitters as use cases for that feature (with only out-of-tree
  drivers so far), I just thought the involved completely wasn't worth it
  and that I should implement CDF v3 as a DRM/KMS-only helper framework.
  However, a seemingly unrelated discussion with Xilinx developers showed
  me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a
  larger library of IP cores that can be used in camera capture pipelines
  and in display pipelines. The two use cases suddenly became tens or even
  hundreds of use cases that I couldn't ignore anymore.
 
 Hmm, I'm still not really convinced ;-)
 
 Or maybe, put another way, I still think we should still optimize for the
 common case. I mean I'm sure you *can* design hw that has an LVDS-DP bridge
 in the capture path, and if you had something like an FPGA where that was
 cheap to do maybe you even would (for fun). But if in the real world, there
 are only one or two cases of actual hw using the same bridge in a capture
 pipeline which is normally used in display pipelines, then duplicating some
 small bit of code for that abnormal case if it makes things easier for the
 common case, seems like a reasonable trade-off to me.

That was my opinion as well until I started working on a Xilinx platform. 
There's dozens of IP cores there that are used in both capture and display 
pipelines.

Furthermore, FPGA display pipelines being made of individual IP cores, we need 
a way to write one driver per IP core and make them all interact. The recently 
proposed drm_bridge is one possible solution to this issue (and to a different 
but similar issue that trigerred the development of drm_bridge), but it's in 
my opinion not generic enough. We're facing several problems that are related, 
it would really be a shame not to solve them with a good enough framework.

 I mean, take a DSI panel driver, for example.. anything but a trivial panel
 driver, you are going to want to expose some custom properties on the
 connector for controlling non-standard features. So you end up with both
 cdf_foo for the common part, and drm_foo for gluing in the properties. And
 now these two parts which otherwise would be one, end up having to stay in
 sync merged through different trees, etc. It seems a lot like making my life
 more difficult for

Re: [PATCH/RFC v3 00/19] Common Display Framework

2013-08-21 Thread Rob Clark

On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Rob,

 On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
 On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
  Hi everybody,
 
  Here's the third RFC of the Common Display Framework.
 
  I won't repeat all the background information from the versions one and
  two here, you can read it at http://lwn.net/Articles/512363/ and
  http://lwn.net/Articles/526965/.
 
  This RFC isn't final. Given the high interest in CDF and the urgent tasks
  that kept delaying the next version of the patch set, I've decided to
  release v3 before completing all parts of the implementation. Known
  missing items are
 
  - documentation: kerneldoc and this cover letter should provide basic
information, more extensive documentation will likely make it to v4.
 
  - pipeline configuration and control: generic code to configure and
control display pipelines (in a nutshell, translating high-level mode
setting and DPMS calls to low-level entity operations) is missing. Video
and stream control operations have been carried over from v2, but will
need to be revised for v4.
 
  - DSI support: I still have no DSI hardware I can easily test the code on.

 tbh, I kinda think that DSI and bridge chips are the things we should focus
 on first.. that seems what is most important for current and new hardware.
 Back-filling to handle older/simpler panels can be done later.

 That sounds reasonable (although I still believe DSI is only part of the
 issue), but I'll need help with that, as the Renesas platforms I work on don't
 have a DSI bus.

  Special thanks go to
 
  - Renesas for inviting me to LinuxCon Japan 2013 where I had the
opportunity to validate the CDF v3 concepts with Alexandre Courbot
(NVidia) and Tomasz Figa (Samsung).
 
  - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me.
 
  - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we
had  there greatly helped moving CDF forward.
 
  - And of course all the developers who showed interest in CDF and spent
time sharing ideas, reviewing patches and testing code.
 
  I have to confess I was a bit lost and discouraged after all the CDF-
  related meetings during which we have discussed how to move from v2 to v3.
  With every meeting I was hoping to run the implementation through use
  cases of various interesting parties and narrow down the scope of the huge
  fuzzy beast that CDF was. With every meeting the scope actually broadened,
  with no clear path at sight anywhere.
 
  Earlier this year I was about to drop one of the requirements on which I
  had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two
  HDMI transmitters as use cases for that feature (with only out-of-tree
  drivers so far), I just thought the involved completely wasn't worth it
  and that I should implement CDF v3 as a DRM/KMS-only helper framework.
  However, a seemingly unrelated discussion with Xilinx developers showed
  me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a
  larger library of IP cores that can be used in camera capture pipelines
  and in display pipelines. The two use cases suddenly became tens or even
  hundreds of use cases that I couldn't ignore anymore.

 Hmm, I'm still not really convinced ;-)

 Or maybe, put another way, I still think we should still optimize for the
 common case. I mean I'm sure you *can* design hw that has an LVDS-DP bridge
 in the capture path, and if you had something like an FPGA where that was
 cheap to do maybe you even would (for fun). But if in the real world, there
 are only one or two cases of actual hw using the same bridge in a capture
 pipeline which is normally used in display pipelines, then duplicating some
 small bit of code for that abnormal case if it makes things easier for the
 common case, seems like a reasonable trade-off to me.

 That was my opinion as well until I started working on a Xilinx platform.
 There's dozens of IP cores there that are used in both capture and display
 pipelines.

or maybe just some helper lib's to handling the register level programming?

Anyways, I guess you can call it a worse is better thing, but if you
can get 90% of the desired effect for 10% of the work, take the
simpler solution.  I don't think we should make things more layered or
more difficult for one exceptional case.


 Furthermore, FPGA display pipelines being made of individual IP cores, we need
 a way to write one driver per IP core and make them all interact. The recently
 proposed drm_bridge is one possible solution to this issue (and to a different
 but similar issue that trigerred the development of drm_bridge), but it's in
 my opinion not generic enough. We're facing several problems that are related,
 it would really be a shame not to solve them with a good enough framework.

well, I've been working on DSI panel support in msm drm, and also

i915 producing warnings with kernel 3.11-rc5

2013-08-21 Thread Michael S. Tsirkin

I see lots of warning like this with 3.11-rc5 on my thinkpad t40.

[197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in 
adjusted_mode.flags (expected 1, found 0)
[197481.739283] [ cut here ]
[197481.739352] WARNING: CPU: 0 PID: 556 at 
drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x5cf/0xa50 [i915]()
[197481.739355] pipe state doesn't match!
[197481.739358] Modules linked in: fuse ebtable_nat xt_CHECKSUM 
nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle 
ip6t_REJECT nf_conntrack_ipv6 bridge nf_defrag_ipv6 stp llc iptable_nat 
nf_nat_ipv4 nf_nat be2iscsi iscsi_boot_sysfs iptable_mangle bnx2i 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack lockd nf_conntrack sunrpc cnic 
ebtable_filter uio cxgb4i cxgb4 ebtables ip6table_filter ip6_tables cxgb3i 
cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core 
iscsi_tcp libiscsi_tcp rfcomm libiscsi scsi_transport_iscsi bnep arc4 iwldvm 
mac80211 btusb snd_hda_codec_hdmi iwlwifi snd_hda_codec_conexant snd_hda_intel 
snd_hda_codec bluetooth vhost_net cfg80211 tun macvtap macvlan iTCO_wdt 
uvcvideo iTCO_vendor_support snd_usb_audio vhost snd_usbmidi_lib 
videobuf2_vmalloc
[197481.739440]  snd_hwdep kvm_intel videobuf2_memops videobuf2_core videodev 
snd_rawmidi thinkpad_acpi e1000e kvm snd_seq rfkill i2c_i801 snd_seq_device 
snd_pcm snd_page_alloc snd_timer pcspkr lpc_ich mfd_core snd ptp tpm_tis 
pps_core wmi soundcore tpm tpm_bios binfmt_misc uinput i915 firewire_ohci 
firewire_core crc_itu_t i2c_algo_bit drm_kms_helper sdhci_pci sdhci drm 
mmc_core i2c_core video
[197481.739492] CPU: 0 PID: 556 Comm: X Tainted: GW3.11.0-rc5-mst 
#253
[197481.739497] Hardware name: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 
04/05/2012
[197481.739501]  205e 88020be47828 81672e9d 
88020be47868
[197481.739509]  8105c52c  88021270fc70 
88021241d000
[197481.739516]  0001 88021270fc78 88021270f800 
88020be47948
[197481.739523] Call Trace:
[197481.739537]  [81672e9d] dump_stack+0x6a/0x7d
[197481.739547]  [8105c52c] warn_slowpath_common+0x8c/0xc0
[197481.739555]  [8105c65e] warn_slowpath_fmt+0x6e/0x70
[197481.739589]  [a00c9385] ? i915_read32+0x75/0x130 [i915]
[197481.739617]  [a00c9385] ? i915_read32+0x75/0x130 [i915]
[197481.739657]  [a0104315] ? intel_lvds_get_config+0x45/0xb0 [i915]
[197481.739692]  [a00f377f] check_crtc_state+0x5cf/0xa50 [i915]
[197481.739730]  [a00faa85] intel_modeset_check_state+0x2e5/0x7c0 
[i915]
[197481.739758]  [a00c8eeb] ? i915_write32+0xdb/0x140 [i915]
[197481.739792]  [a0103f7c] intel_crt_dpms+0x8c/0xd0 [i915]
[197481.739826]  [a0057643] 
drm_mode_obj_set_property_ioctl+0x393/0x3b0 [drm]
[197481.739854]  [a0057692] 
drm_mode_connector_property_set_ioctl+0x32/0x40 [drm]
[197481.739880]  [a004964a] drm_ioctl+0x3da/0x660 [drm]
[197481.739893]  [81142695] ? __free_pages+0x45/0x50
[197481.739923]  [a0057660] ? 
drm_mode_obj_set_property_ioctl+0x3b0/0x3b0 [drm]
[197481.739933]  [8129ecda] ? file_has_perm+0xaa/0xb0
[197481.739977]  [a0130b75] i915_compat_ioctl+0x45/0x50 [i915]
[197481.739985]  [811ee9f6] compat_sys_ioctl+0x106/0x13a0
[197481.739994]  [8119dce9] ? file_sb_list_del+0x49/0x50
[197481.740001]  [8107bd35] ? task_work_add+0x55/0x70
[197481.740008]  [8119de15] ? fput+0x75/0xb0
[197481.740017]  [810e3c2b] ? __audit_syscall_exit+0x23b/0x2e0
[197481.740027]  [8168221c] sysenter_dispatch+0x7/0x21
[197481.740031] ---[ end trace 60b3bfa00b791b28 ]---


The graphics card is:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)

Anyone interested in debugging the source of these warnings?

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

Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

2013-08-21 Thread Mike Turquette

Quoting Fabio Estevam (2013-08-20 08:40:52)
 On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying ying@freescale.com wrote:
 
  diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt 
  b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
  index 5a90a72..90e923e 100644
  --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
  +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
  @@ -89,8 +89,6 @@ clocks and IDs.
  gpu3d_shader74
  ipu1_podf   75
  ipu2_podf   76
  -   ldb_di0_podf77
  -   ldb_di1_podf78
  ipu1_di0_pre79
  ipu1_di1_pre80
  ipu2_di0_pre81
 
 This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc

How does this fit in with the idea of having a stable binding/ABI? Seems
like changing this would be a bad idea for devices in the field that
have older DTBs.

Regards,
Mike

 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC v3 06/19] video: display: OF support

Hi Philipp,

On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
 Hi Laurent,
 
 thanks for this update. I'm very happy about the move to the display entity
 model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
 in a single device - this will allow to use a unified device tree binding
 scheme.

Thanks for the support :-)

 I'm still trying to see how this all fits together, so far I have only one
 comment, below.
 
 Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
 [...]
 
  +static int display_of_parse_dt(struct display_entity_notifier *notifier,
  +  struct list_head *entities,
  +  struct device_node *node)
  +{
  +   struct display_entity_of *entity;
  +   struct device_node *remote;
  +   struct device_node *ep = NULL;
  +   struct device_node *next;
  +   unsigned int num_entities = 0;
  +   int ret = 0;
  +
  +   /* Walk the device tree and build a list of nodes. */
  +   dev_dbg(notifier-dev, parsing node %s\n, node-full_name);
  +
  +   while (1) {
  +   next = display_of_get_next_endpoint(node, ep);
  +   if (next == NULL)
  +   break;
  +
  +   of_node_put(ep);
  +   ep = next;
  +
  +   dev_dbg(notifier-dev, handling endpoint %s\n, ep-full_name);
  +
  +   remote = display_of_get_remote_port_parent(ep);
  +   if (remote == NULL)
  +   continue;
  +
  +   /* Skip entities that we have already processed. */
  +   if (display_of_find_entity(entities, remote) || remote == node) 
  {
  +   dev_dbg(notifier-dev,
  +   entity %s already in list, skipping\n,
  +   remote-full_name);
  +   continue;
  +   }
 
 device tree nodes with status = disabled should be skipped here:
 
 if (!of_device_is_available(remote)) {
 dev_dbg(notifier-dev,
 entity %s is disabled, skipping\n,
 remote-full_name);
 continue;
 }
 
 Otherwise the completion notification will never be delivered if there
 are any disabled entities in the graph.

That's a good point, but if a device is disabled, why would it be in the DT 
graph in the first place ? Do you have a use case for this ?

  +   entity = kzalloc(sizeof(*entity), GFP_KERNEL);
  +   if (entity == NULL) {
  +   of_node_put(remote);
  +   ret = -ENOMEM;
  +   break;
  +   }
  +
  +   dev_dbg(notifier-dev, adding remote entity %s to list\n,
  +   remote-full_name);
  +
  +   entity-node = remote;
  +   list_add_tail(entity-list, entities);
  +   num_entities++;
  +   }
  +
  +   of_node_put(ep);
  +
  +   if (ret  0)
  +   return ret;
  +
  +   return num_entities;
  +}
 
 [...]

-- 
Regards,

Laurent Pinchart

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

[Bug 66967] Dota 2 crashes with r600g when starting the tutorial

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

--- Comment #4 from Tilman Sauerbeck til...@code-monkey.de ---
(In reply to comment #3)
 I'm not sure if I and others experience the same problem as you, but when I
 try to start the first tutorial mission in DotA 2 (or change the resolution
 in the options menu), the game crashes.

I can change the resolution just fine.

 It seems to boil down to a general shader issue with Mesa, as users with
 Intel  R600 drivers are having the problems. When one delete certain shader
 files the game will start.

Nope, deleting/renaming the fxc subdirectory doesn't help on my system.

Looks like I'm seeing a different problem than you are.

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

Re: [PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)

2013-08-21 Thread Michel Dänzer

On Die, 2013-08-20 at 13:16 -0400, Alex Deucher wrote:
 Newer versions of gcc seem to wander off into no-man's land
 when using variably sized arrays.  Atombios tends to do things
 like:
 
 struct object {
 u8 version;
 u8 num_elements;
 u32 elements[1]; /* num_elements entries */
 };
 
 We then do things like the following in the driver code:
 
 for (i = 0; i  atom_object-num_elements; i++) {
 driver_object[i] = atom_object-elements[i];
 }
 
 With previous versions of gcc this used to work fine, but with
 4.7 and 4.8, it seems to generate code that wanders off into the
 weeds.
 
 According to:
 http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
 The traditional way of handling variably sized arrays (ISO C90)
 is to use an array length of 1.  Gcc allows you to use an array
 length of 0 and newer versions of gcc only seem to do the
 right thing when 0 is used.

[...]

 diff --git a/drivers/gpu/drm/radeon/atombios.h 
 b/drivers/gpu/drm/radeon/atombios.h
 index 16b120c..3f1f011 100644
 --- a/drivers/gpu/drm/radeon/atombios.h
 +++ b/drivers/gpu/drm/radeon/atombios.h
[...]
 @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE 
 //Above 4 object table
[...]
  typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT 
 //usSrcDstTableOffset pointing to this structure
  {
UCHAR   ucNumberOfSrc;
 -  USHORT  usSrcObjectID[1];
 +  USHORT  usSrcObjectID[0];
UCHAR   ucNumberOfDst;
 -  USHORT  usDstObjectID[1];
 +  USHORT  usDstObjectID[0];
  }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

[...]

 @@ -6194,8 +6194,8 @@ typedef struct _ATOM_INIT_REG_INDEX_FORMAT{
  typedef struct _ATOM_INIT_REG_BLOCK{
   USHORT  
 usRegIndexTblSize;
   
 //size of asRegIndexBuf
   USHORT  
 usRegDataBlkSize; 
   
 //size of ATOM_MEMORY_SETTING_DATA_BLOCK
 - ATOM_INIT_REG_INDEX_FORMAT  asRegIndexBuf[1];
 - ATOM_MEMORY_SETTING_DATA_BLOCK  asRegDataBuf[1];
 + ATOM_INIT_REG_INDEX_FORMAT  asRegIndexBuf[0];
 + ATOM_MEMORY_SETTING_DATA_BLOCK  asRegDataBuf[0];
  }ATOM_INIT_REG_BLOCK;
  
  #define END_OF_REG_INDEX_BLOCK  0x0
 @@ -6938,8 +6938,8 @@ typedef struct _ATOM_DISP_OUT_INFO
ATOM_COMMON_TABLE_HEADER sHeader;  
   USHORT ptrTransmitterInfo;
   USHORT ptrEncoderInfo;
 - ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
 - ASIC_ENCODER_INFO  asEncoderInfo[1];
 + ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
 + ASIC_ENCODER_INFO  asEncoderInfo[0];
  }ATOM_DISP_OUT_INFO;
  
  typedef struct _ATOM_DISP_OUT_INFO_V2
 @@ -6948,8 +6948,8 @@ typedef struct _ATOM_DISP_OUT_INFO_V2
   USHORT ptrTransmitterInfo;
   USHORT ptrEncoderInfo;
USHORT ptrMainCallParserFar;  // direct address of main 
 parser call in VBIOS binary. 
 - ASIC_TRANSMITTER_INFO  asTransmitterInfo[1];
 - ASIC_ENCODER_INFO  asEncoderInfo[1];
 + ASIC_TRANSMITTER_INFO  asTransmitterInfo[0];
 + ASIC_ENCODER_INFO  asEncoderInfo[0];
  }ATOM_DISP_OUT_INFO_V2;

I'm not sure how these structs are supposed to work, before or after
this change... The compiler can't know how to access the fields after
the first variably-sized array?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

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

[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module

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

--- Comment #9 from Eastern Heart zxd123...@hotmail.com ---
(In reply to Alex Deucher from comment #8)
 (In reply to Eastern Heart from comment #7)
  
  Although I haven't apply this patch, can I ask: will this patch be merged to
  linux-3.10.7?
 
 It should make it's way to 3.10 eventually.  I'm not sure which 3.10.x
 version it will end up in.

Today I have get my Compaq 511 back. The patch works! And I'm trying to enjoy
uvd hardware decode.

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

RE: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework

Thanks for the review,
Inki Dae

 -Original Message-
 From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
 ow...@vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk
 Sent: Wednesday, August 21, 2013 4:22 AM
 To: Inki Dae
 Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux-
 arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org; linaro-
 ker...@lists.linaro.org; kyungmin.p...@samsung.com;
 myungjoo@samsung.com
 Subject: Re: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer
 synchronization framework

 On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote:
  This patch adds a buffer synchronization framework based on DMA BUF[1]
  and and based on ww-mutexes[2] for lock mechanism.

  The purpose of this framework is to provide not only buffer access
 control
  to CPU and DMA but also easy-to-use interfaces for device drivers and
  user application. This framework can be used for all dma devices using
  system memory as dma buffer, especially for most ARM based SoCs.

  Changelog v6:
  - Fix sync lock to multiple reads.
  - Add select system call support.
. Wake up poll_wait when a dmabuf is unlocked.
  - Remove unnecessary the use of mutex lock.
  - Add private backend ops callbacks.
. This ops has one callback for device drivers to clean up their
  sync object resource when the sync object is freed. For this,
  device drivers should implement the free callback properly.
  - Update document file.

  Changelog v5:
  - Rmove a dependence on reservation_object: the reservation_object is
 used
to hook up to ttm and dma-buf for easy sharing of reservations across
devices. However, the dmabuf sync can be used for all dma devices;
 v4l2
and drm based drivers, so doesn't need the reservation_object anymore.
With regared to this, it adds 'void *sync' to dma_buf structure.
  - All patches are rebased on mainline, Linux v3.10.

  Changelog v4:
  - Add user side interface for buffer synchronization mechanism and
 update
descriptions related to the user side interface.

  Changelog v3:
  - remove cache operation relevant codes and update document file.

  Changelog v2:
  - use atomic_add_unless to avoid potential bug.
  - add a macro for checking valid access type.
  - code clean.

  The mechanism of this framework has the following steps,
  1. Register dmabufs to a sync object - A task gets a new sync object
 and
  can add one or more dmabufs that the task wants to access.
  This registering should be performed when a device context or an
 event
  context such as a page flip event is created or before CPU accesses
a
 shared
  buffer.

  dma_buf_sync_get(a sync object, a dmabuf);

  2. Lock a sync object - A task tries to lock all dmabufs added in
its
 own
  sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid
 dead
  lock issue and for race condition between CPU and CPU, CPU and DMA,
 and DMA
  and DMA. Taking a lock means that others cannot access all locked
 dmabufs
  until the task that locked the corresponding dmabufs, unlocks all
the
 locked
  dmabufs.
  This locking should be performed before DMA or CPU accesses these
 dmabufs.

  dma_buf_sync_lock(a sync object);

  3. Unlock a sync object - The task unlocks all dmabufs added in its
 own sync
  object. The unlock means that the DMA or CPU accesses to the dmabufs
 have
  been completed so that others may access them.
  This unlocking should be performed after DMA or CPU has completed
 accesses
  to the dmabufs.

  dma_buf_sync_unlock(a sync object);

  4. Unregister one or all dmabufs from a sync object - A task
 unregisters
  the given dmabufs from the sync object. This means that the task
 dosen't
  want to lock the dmabufs.
  The unregistering should be performed after DMA or CPU has completed
  accesses to the dmabufs or when dma_buf_sync_lock() is failed.

  dma_buf_sync_put(a sync object, a dmabuf);
  dma_buf_sync_put_all(a sync object);

  The described steps may be summarized as:
  get - lock - CPU or DMA access to a buffer/s - unlock - put

  This framework includes the following two features.
  1. read (shared) and write (exclusive) locks - A task is required to
 declare
  the access type when the task tries to register a dmabuf;
  READ, WRITE, READ DMA, or WRITE DMA.

  The below is example codes,
  struct dmabuf_sync *sync;

  sync = dmabuf_sync_init(...);
  ...

  dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
  ...

  And the below can be used as access types:
  DMA_BUF_ACCESS_R - CPU will access a buffer for read.
  DMA_BUF_ACCESS_W - CPU will access a buffer for read or
 write.
  DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
  DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or

[PATCH v7 0/2] Introduce buffer synchronization framework

Hi all,

This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and
has been rebased on linux-3.11-rc6.

The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

For generic user mode interface, we have used fcntl and select system
call[3]. As you know, user application sees a buffer object as a dma-buf
file descriptor. So fcntl() call with the file descriptor means to lock
some buffer region being managed by the dma-buf object. And select() call
means to wait for the completion of CPU or DMA access to the dma-buf
without locking. For more detail, you can refer to the dma-buf-sync.txt
in Documentation/

There are some cases we should use this buffer synchronization framework.
One of which is to primarily enhance GPU rendering performance on Tizen
platform in case of 3d app with compositing mode that 3d app draws
something in off-screen buffer, and Web app.

In case of 3d app with compositing mode which is not a full screen mode,
the app calls glFlush to submit 3d commands to GPU driver instead of
glFinish for more performance. The reason we call glFlush is that glFinish
blocks caller's task until the execution of the 2d commands is completed.
Thus, that makes GPU and CPU more idle. As result, 3d rendering performance
with glFinish is quite lower than glFlush. However, the use of glFlush has
one issue that the a buffer shared with GPU could be broken when CPU
accesses the buffer at once after glFlush because CPU cannot be aware of
the completion of GPU access to the buffer. Of course, the app can be aware
of that time using eglWaitGL but this function is valid only in case of the
same process.

The below summarizes how app's window is displayed on Tizen platform:
1. X client requests a window buffer to Xorg.
2. X client draws something in the window buffer using CPU.
3. X client requests SWAP to Xorg.
4. Xorg notifies a damage event to Composite Manager.
5. Composite Manager gets the window buffer (front buffer) through
   DRI2GetBuffers.
6. Composite Manager composes the window buffer and its own back buffer
   using GPU. At this time, eglSwapBuffers is called: internally, 3d
   commands are flushed to gpu driver.
7. Composite Manager requests SWAP to Xorg.
8. Xorg performs drm page flip. At this time, the window buffer is
   displayed on screen.

Web app based on HTML5 also has the same issue. Web browser and its web app
are different process. The web app draws something in its own pixmap buffer,
and then the web browser gets a window buffer from Xorg, and then composites
the pixmap buffer with the window buffer. And finally, page flip.

Thus, in such cases, a shared buffer could be broken as one process draws
something in pixmap buffer using CPU, when other process composites the
pixmap buffer with window buffer using GPU without any locking mechanism.
That is why we need user land locking interface, fcntl system call.

And last one is a deferred page flip issue. This issue is that a window
buffer rendered can be displayed on screen in about 32ms in worst case:
assume that the gpu rendering is completed within 16ms.
That can be incurred when compositing a pixmap buffer with a window buffer
using GPU and when vsync is just started. At this time, Xorg waits for
a vblank event to get a window buffer so

[PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support

This patch adds lock and poll callbacks to dma buf file operations,
and these callbacks will be called by fcntl and select system calls.

fcntl and select system calls can be used to wait for the completion
of DMA or CPU access to a shared dmabuf. The difference of them is
fcntl system call takes a lock after the completion but select system
call doesn't. So in case of fcntl system call, it's useful when a task
wants to access a shared dmabuf without any broken. On the other hand,
it's useful when a task wants to just wait for the completion.

Changelog v2:
- Add select system call support.
  . The purpose of this feature is to wait for the completion of DMA or
CPU access to a dmabuf without that caller locks the dmabuf again
after the completion.
That is useful when caller wants to be aware of the completion of
DMA access to the dmabuf, and the caller doesn't use intefaces for
the DMA device driver.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/base/dma-buf.c |   81 
 1 files changed, 81 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 4aca57a..f16a396 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -29,6 +29,7 @@
 #include linux/export.h
 #include linux/debugfs.h
 #include linux/seq_file.h
+#include linux/poll.h
 #include linux/dmabuf-sync.h
 
 static inline int is_dma_buf_file(struct file *);
@@ -80,9 +81,89 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
return dmabuf-ops-mmap(dmabuf, vma);
 }
 
+static unsigned int dma_buf_poll(struct file *filp,
+   struct poll_table_struct *poll)
+{
+   struct dma_buf *dmabuf;
+   struct dmabuf_sync_reservation *robj;
+   int ret = 0;
+
+   if (!is_dma_buf_file(filp))
+   return POLLERR;
+
+   dmabuf = filp-private_data;
+   if (!dmabuf || !dmabuf-sync)
+   return POLLERR;
+
+   robj = dmabuf-sync;
+
+   mutex_lock(robj-lock);
+
+   robj-polled = true;
+
+   /*
+* CPU or DMA access to this buffer has been completed, and
+* the blocked task has been waked up. Return poll event
+* so that the task can get out of select().
+*/
+   if (robj-poll_event) {
+   robj-poll_event = false;
+   mutex_unlock(robj-lock);
+   return POLLIN | POLLOUT;
+   }
+
+   /*
+* There is no anyone accessing this buffer so just return.
+*/
+   if (!robj-locked) {
+   mutex_unlock(robj-lock);
+   return POLLIN | POLLOUT;
+   }
+
+   poll_wait(filp, robj-poll_wait, poll);
+
+   mutex_unlock(robj-lock);
+
+   return ret;
+}
+
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+   struct dma_buf *dmabuf;
+   unsigned int type;
+   bool wait = false;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   if ((fl-fl_type  F_UNLCK) == F_UNLCK) {
+   dmabuf_sync_single_unlock(dmabuf);
+   return 0;
+   }
+
+   /* convert flock type to dmabuf sync type. */
+   if ((fl-fl_type  F_WRLCK) == F_WRLCK)
+   type = DMA_BUF_ACCESS_W;
+   else if ((fl-fl_type  F_RDLCK) == F_RDLCK)
+   type = DMA_BUF_ACCESS_R;
+   else
+   return -EINVAL;
+
+   if (fl-fl_flags  FL_SLEEP)
+   wait = true;
+
+   /* TODO. the locking to certain region should also be considered. */
+
+   return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
+   .poll   = dma_buf_poll,
+   .lock   = dma_buf_lock,
 };
 
 /*
-- 
1.7.5.4

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

[PATCH v7 1/2] dmabuf-sync: Add a buffer synchronization framework

This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism, and has been rebased
on linux-3.11-rc6.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framework can be used for all dma devices using
system memory as dma buffer, especially for most ARM based SoCs.

Changelog v7:
Fix things pointed out by Konrad Rzeszutek Wilk,
- Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
- Make sure to unlock and unreference all dmabuf objects
  when dmabuf_sync_fini() is called.
- Add more comments.
- Code cleanups.

Changelog v6:
- Fix sync lock to multiple reads.
- Add select system call support.
  . Wake up poll_wait when a dmabuf is unlocked.
- Remove unnecessary the use of mutex lock.
- Add private backend ops callbacks.
  . This ops has one callback for device drivers to clean up their
sync object resource when the sync object is freed. For this,
device drivers should implement the free callback properly.
- Update document file.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
1. Register dmabufs to a sync object - A task gets a new sync object and
can add one or more dmabufs that the task wants to access.
This registering should be performed when a device context or an event
context such as a page flip event is created or before CPU accesses a shared
buffer.

dma_buf_sync_get(a sync object, a dmabuf);

2. Lock a sync object - A task tries to lock all dmabufs added in its own
sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
and DMA. Taking a lock means that others cannot access all locked dmabufs
until the task that locked the corresponding dmabufs, unlocks all the locked
dmabufs.
This locking should be performed before DMA or CPU accesses these dmabufs.

dma_buf_sync_lock(a sync object);

3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
object. The unlock means that the DMA or CPU accesses to the dmabufs have
been completed so that others may access them.
This unlocking should be performed after DMA or CPU has completed accesses
to the dmabufs.

dma_buf_sync_unlock(a sync object);

4. Unregister one or all dmabufs from a sync object - A task unregisters
the given dmabufs from the sync object. This means that the task dosen't
want to lock the dmabufs.
The unregistering should be performed after DMA or CPU has completed
accesses to the dmabufs or when dma_buf_sync_lock() is failed.

dma_buf_sync_put(a sync object, a dmabuf);
dma_buf_sync_put_all(a sync object);

The described steps may be summarized as:
get - lock - CPU or DMA access to a buffer/s - unlock - put

This framework includes the following two features.
1. read (shared) and write (exclusive) locks - A task is required to declare
the access type when the task tries to register a dmabuf;
READ, WRITE, READ DMA, or WRITE DMA.

The below is example codes,
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(...);
...

dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
...

And the below can be used as access types:
DMA_BUF_ACCESS_R - CPU will access a buffer for read.
DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
write.

2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
A task may never try to unlock a buffer after taking a lock to the buffer.
In this case, a timer handler to the corresponding sync object is called
in five (default) seconds and then the timed-out buffer is unlocked by work
queue handler to avoid lockups and to enforce resources of the buffer.

The below is how to use interfaces for device

Re: [GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

Hi Simon,

On Wednesday 21 August 2013 17:36:12 Simon Horman wrote:
 On Sat, Aug 10, 2013 at 07:28:30AM +1000, Dave Airlie wrote:
  On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart wrote:
   On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
   On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman wrote:
On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
Hi Dave,

(CC'ing Simon Horman, the shmobile tree maintainer)

On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
 On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
  Hi Dave,
  
  I've got a couple of arch/arm/ patches that depend on this
  series and that I would like to get merged in v3.12. They should
  go upstream through the arm-soc tree. Would you be able to
  provide a stable branch with this patch set based on one of the
  3.11-rcX tags ?
  Ideally that branch should have as little patches as possible
  other than this set.
 
 Yeah that shouldn't be a problem, though is there any interface
 changes or things with this wrt drm-next?
 
 i.e. will this tree build on v3.11-rcX and drm-next?

They depend on a fix that went in between -rc1 and -rc2. You can
base the branch on any -rc = 2.

An rc2 or rc3 base would be ideal for me, but any rc would be fine.
   
   So the problem with making a stable branch is we have conflicts in
   other places that have already been solved in drm-next,
   
   is there any problem with using Laurent's tree directly as the stable
   point?
  
   As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and
   pushed the result to
   
   git://linuxtv.org/pinchartl/fbdev.git drm/next/du

b/drivers/gpu/drm/rcar-du/Kconfig   |7
b/drivers/gpu/drm/rcar-du/Makefile  |   10 -
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 ++--
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
b/include/linux/platform_data/rcar-du.h |   34 ++-
drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 
drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
27 files changed, 1665 insertions(+), 861 deletions(-)
   
   Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/
   patches on top of this drm/next/du branch.
  
  Actually small change
  
  Simon can you use
  
  git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12
  
  as I've merged this tree with an S-o-b on the merge commit, so other
  people will know it has gone via me.
 
 Sorry for the delayed response.
 
 I had assumed that the reason I was having trouble fetching
 the remote above was related to the internet connection at the
 end of the world that I was in turn at the end while on holidays.
 
 However, it seems that I am unable to fetch the remote from my office
 either. This may well be a fault at my end, but its not something
 I can readily think of a work around for other than trying from home a
 little later.
 
 # git remote add airlied git://git.freedesktop.org/~airlied/linux
 # git fetch airlied
 fatal: Could not read from remote repository.
 
 Please make sure you have the correct access rights
 and the repository exists.

The URL I use is git://people.freedesktop.org/~airlied/linux

-- 
Regards,

Laurent Pinchart

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

[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module

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

--- Comment #10 from Alex Deucher alexdeuc...@gmail.com ---
Glad it's working.  Please mark this bug as a duplicate of bug 60674.

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

Re: [PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support

2013-08-21 Thread David Herrmann

Hi

On Wed, Aug 21, 2013 at 12:33 PM, Inki Dae inki@samsung.com wrote:
 This patch adds lock and poll callbacks to dma buf file operations,
 and these callbacks will be called by fcntl and select system calls.

 fcntl and select system calls can be used to wait for the completion
 of DMA or CPU access to a shared dmabuf. The difference of them is
 fcntl system call takes a lock after the completion but select system
 call doesn't. So in case of fcntl system call, it's useful when a task
 wants to access a shared dmabuf without any broken. On the other hand,
 it's useful when a task wants to just wait for the completion.

1)
So how is that supposed to work in user-space? I don't want to block
on a buffer, but get notified once I can lock it. So I do:
  select(..dmabuf..)
Once it is finished, I want to use it:
  flock(..dmabuf..)
However, how can I guarantee the flock will not block? Some other
process might have locked it in between. So I do a non-blocking
flock() and if it fails I wait again? Looks ugly and un-predictable.

2)
What do I do if some user-space program holds a lock and dead-locks?

3)
How do we do modesetting in atomic-context in the kernel? There is no
way to lock the object. But this is required for panic-handlers and
more importantly the kdb debugging hooks.
Ok, I can live with that being racy, but would still be nice to be considered.

4)
Why do we need locks? Aren't fences enough? That is, in which
situation is a lock really needed?
If we assume we have two writers A and B (DMA, CPU, GPU, whatever) and
they have no synchronization on their own. What do we win by
synchronizing their writes? Ok, yeah, we end up with either A or B and
not a mixture of both. But if we cannot predict whether we get A or B,
I don't know why we care at all? It's random, so a mixture would be
fine, too, wouldn't it?

So if user-space doesn't have any synchronization on its own, I don't
see why we need an implicit sync on a dma-buf. Could you describe a
more elaborate use-case?

I think the problems we need to fix are read/write syncs. So we have a
write that issues the DMA+write plus a fence and passes the buf plus
fence to the reader. The reader waits for the fence and then issues
the read plus fence. It passes the fence back to the writer. The
writer waits for the fence again and then issues the next write if
required.

This has the following advantages:
 - fences are _guaranteed_ to finish in a given time period. Locks, on
the other hand, might never be freed (of the holder dead-locks, for
instance)
 - you avoid any stalls. That is, if a writer releases a buffer and
immediately locks it again, the reader side might stall if it didn't
lock it in exactly the given window. You have no control to guarantee
the reader ever gets access. You would need a synchronization in
user-space between the writer and reader to guarantee that. This makes
the whole lock useles, doesn't it?

Cheers
David

 Changelog v2:
 - Add select system call support.
   . The purpose of this feature is to wait for the completion of DMA or
 CPU access to a dmabuf without that caller locks the dmabuf again
 after the completion.
 That is useful when caller wants to be aware of the completion of
 DMA access to the dmabuf, and the caller doesn't use intefaces for
 the DMA device driver.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/base/dma-buf.c |   81 
 
  1 files changed, 81 insertions(+), 0 deletions(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 4aca57a..f16a396 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -29,6 +29,7 @@
  #include linux/export.h
  #include linux/debugfs.h
  #include linux/seq_file.h
 +#include linux/poll.h
  #include linux/dmabuf-sync.h

  static inline int is_dma_buf_file(struct file *);
 @@ -80,9 +81,89 @@ static int dma_buf_mmap_internal(struct file *file, struct 
 vm_area_struct *vma)
 return dmabuf-ops-mmap(dmabuf, vma);
  }

 +static unsigned int dma_buf_poll(struct file *filp,
 +   struct poll_table_struct *poll)
 +{
 +   struct dma_buf *dmabuf;
 +   struct dmabuf_sync_reservation *robj;
 +   int ret = 0;
 +
 +   if (!is_dma_buf_file(filp))
 +   return POLLERR;
 +
 +   dmabuf = filp-private_data;
 +   if (!dmabuf || !dmabuf-sync)
 +   return POLLERR;
 +
 +   robj = dmabuf-sync;
 +
 +   mutex_lock(robj-lock);
 +
 +   robj-polled = true;
 +
 +   /*
 +* CPU or DMA access to this buffer has been completed, and
 +* the blocked task has been waked up. Return poll event
 +* so that the task can get out of select().
 +*/
 +   if (robj-poll_event) {
 +   robj-poll_event = false;
 +   mutex_unlock(robj-lock);
 +   return POLLIN | POLLOUT;
 +   }
 +
 +

Re: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework

2013-08-21 Thread Konrad Rzeszutek Wilk

   +EXPORT_SYMBOL(is_dmabuf_sync_supported);
  
  _GPL ?
  
  I would also prefix it with 'dmabuf_is_sync_supported' just to make
  all of the libraries call start with 'dmabuf'
  
 
 Seems better. Will change it to dmabuf_is_sync_supported, and use
 EXPORT_SYMBOL_GPL.

One thing thought - while I suggest that you use GPL variant
I think you should check who the consumers are. As in, if nvidia
wants to use it it might make their lawyers unhappy - and in turn
means that their engineers won't be able to use these symbols.

So - if there is a strong argument to not have it GPL - then please
say so. 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

DPM on Radeon HD6570


Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: [PATCH/RFC v3 00/19] Common Display Framework

2013-08-21 Thread Sascha Hauer

On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
 On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Rob,
 
  Or maybe, put another way, I still think we should still optimize for the
  common case. I mean I'm sure you *can* design hw that has an LVDS-DP 
  bridge
  in the capture path, and if you had something like an FPGA where that was
  cheap to do maybe you even would (for fun). But if in the real world, there
  are only one or two cases of actual hw using the same bridge in a capture
  pipeline which is normally used in display pipelines, then duplicating some
  small bit of code for that abnormal case if it makes things easier for the
  common case, seems like a reasonable trade-off to me.
 
  That was my opinion as well until I started working on a Xilinx platform.
  There's dozens of IP cores there that are used in both capture and display
  pipelines.
 
 or maybe just some helper lib's to handling the register level programming?
 
 Anyways, I guess you can call it a worse is better thing, but if you
 can get 90% of the desired effect for 10% of the work, take the
 simpler solution.  I don't think we should make things more layered or
 more difficult for one exceptional case.
 
 
  Furthermore, FPGA display pipelines being made of individual IP cores, we 
  need
  a way to write one driver per IP core and make them all interact. The 
  recently
  proposed drm_bridge is one possible solution to this issue (and to a 
  different
  but similar issue that trigerred the development of drm_bridge), but it's in
  my opinion not generic enough. We're facing several problems that are 
  related,
  it would really be a shame not to solve them with a good enough framework.
 
 well, I've been working on DSI panel support in msm drm, and also been
 looking at the patches to add DSI support in i915.  And the panel
 interface ends up looking basically like the drm_bridge interface.
 Perhaps the only thing not generic there is the name.
 
  I mean, take a DSI panel driver, for example.. anything but a trivial panel
  driver, you are going to want to expose some custom properties on the
  connector for controlling non-standard features. So you end up with both
  cdf_foo for the common part, and drm_foo for gluing in the properties. And
  now these two parts which otherwise would be one, end up having to stay in
  sync merged through different trees, etc. It seems a lot like making my 
  life
  more difficult for a fairly hypothetical gain ;-)
 
  The DSI panel driver should not be split into two parts. It should 
  implement a
  CDF entity, any glue needed for DRM will not be part of the panel driver.
 
 right, but that glue ends up needing to be *somewhere*, which makes it
 the 2nd part.
 
  Or, take an hdmi or DP bridge. To use any of the common
  infrastructure/helpers in drm, you end up implementing a generic interface,
  where both the producer and consumer is inside drm. Which just seems a bit
  pointless and extra hoops to jump through. Especially when we discover that
  we need to extend/enhance the common interface outside of drm to make it
  work. (I'm thinking of display_entity_control_ops::get_modes() here, but 
  I'm
  sure there are more examples.) And I think we'll run into similar issues
  with display_entity_control_ops::set_state(), since the on-off sequencing
  can get hairy when the upstream/downstream entity is fed a clk by the
  downstream/upstream entity. And similarly, I think we'll go through a few
  revisions of DSI panel/bus params before we have everything that everyone
  needs.
 
  I don't see where needing multiple revisions of a patch set would be bad :-)
 
 I mean over multiple kernel revisions, as people start adding support
 for new hw and run into limitations of the framework.

A framework can be changed, extended and fixed. In the end we talking
about a completely in-kernel framework for which we do not have to
maintain a stable API.

 
 We've already figured out that just having enable() and disable() is
 not sufficient for displayport link training.  I'm not sure what else
 we'll discover.

It's pretty much expected that other things will be discovered, but this
will also happen with all sub-drm-driver frameworks we currently have.

 
 I'm not saying not to solve (most of these) problems.. I don't think
 chaining multiple drm_bridge's is impossible, I can think of at least
 two ways to implement it.  But I think we should solve that as someone
 is adding support for hw that uses this.  This (a) lets us break
 things up into smaller more incremental changes (drm_bridge is
 *considerably* smaller than the current CDF patchset), and (b) avoids
 us solving the wrong problems.
 
 btw, I think DT bindings is orthogonal to this discussion.

Not really. The common display framework is about splitting the pipeline
into its components and adding a common view to the components. It's CDF
helper code that can translate a DT binding

Re: [GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

2013-08-21 Thread Simon Horman

On Sat, Aug 10, 2013 at 07:28:30AM +1000, Dave Airlie wrote:
 On Sat, Aug 10, 2013 at 7:25 AM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Dave,
 
  On Saturday 10 August 2013 06:45:05 Dave Airlie wrote:
  On Thu, Aug 8, 2013 at 11:39 AM, Simon Horman ho...@verge.net.au wrote:
   On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote:
   Hi Dave,
  
   (CC'ing Simon Horman, the shmobile tree maintainer)
  
   On Thursday 08 August 2013 10:57:33 Dave Airlie wrote:
On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote:
 Hi Dave,

 I've got a couple of arch/arm/ patches that depend on this series 
 and
 that I would like to get merged in v3.12. They should go upstream
 through the arm-soc tree. Would you be able to provide a stable
 branch with this patch set based on one of the 3.11-rcX tags ?
 Ideally that branch should have as little patches as possible other
 than this set.
   
Yeah that shouldn't be a problem, though is there any interface 
changes
or things with this wrt drm-next?
   
i.e. will this tree build on v3.11-rcX and drm-next?
  
   They depend on a fix that went in between -rc1 and -rc2. You can base 
   the
   branch on any -rc = 2.
  
   An rc2 or rc3 base would be ideal for me, but any rc would be fine.
 
  So the problem with making a stable branch is we have conflicts in other
  places that have already been solved in drm-next,
 
  is there any problem with using Laurent's tree directly as the stable 
  point?
 
  As agreed on IRC, I've rebased the patches on top of v3.11-rc3 and pushed 
  the
  result to
 
  git://linuxtv.org/pinchartl/fbdev.git drm/next/du
 
   b/drivers/gpu/drm/rcar-du/Kconfig   |7
   b/drivers/gpu/drm/rcar-du/Makefile  |   10 -
   b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  255 
  +-
   b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   13 -
   b/drivers/gpu/drm/rcar-du/rcar_du_drv.c |  173 +++---
   b/drivers/gpu/drm/rcar-du/rcar_du_drv.h |   63 +-
   b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  202 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   49 +
   b/drivers/gpu/drm/rcar-du/rcar_du_group.c   |  187 
   b/drivers/gpu/drm/rcar-du/rcar_du_group.h   |   50 +
   b/drivers/gpu/drm/rcar-du/rcar_du_kms.c |  165 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_kms.h |   29 ---
   b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  131 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   25 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  196 +
   b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   46 +
   b/drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  170 +-
   b/drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   26 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_regs.h|   94 --
   b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   96 ++
   b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |   23 ++
   b/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   69 +++
   b/include/linux/platform_data/rcar-du.h |   34 ++-
   drivers/gpu/drm/rcar-du/rcar_du_lvds.c  |  216 ---
   drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |   24 --
   drivers/gpu/drm/rcar-du/rcar_du_vga.c   |  149 
   drivers/gpu/drm/rcar-du/rcar_du_vga.h   |   24 --
   27 files changed, 1665 insertions(+), 861 deletions(-)
 
  Can you merge that into drm-next ? Simon, you can base the r8a7790 arch/
  patches on top of this drm/next/du branch.
 
 Actually small change
 
 Simon can you use
 
 git://git.freedesktop.org/~airlied/linux drm-rcar-for-v3.12
 
 as I've merged this tree with an S-o-b on the merge commit, so other
 people will know it has gone via me.

Sorry for the delayed response.

I had assumed that the reason I was having trouble fetching
the remote above was related to the internet connection at the
end of the world that I was in turn at the end while on holidays.

However, it seems that I am unable to fetch the remote from my office
either. This may well be a fault at my end, but its not something
I can readily think of a work around for other than trying from home a
little later.

# git remote add airlied git://git.freedesktop.org/~airlied/linux
# git fetch airlied
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.



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

Re: [PATCH/RFC v3 06/19] video: display: OF support

2013-08-21 Thread Philipp Zabel

Hi Laurent,

Am Mittwoch, den 21.08.2013, 03:02 +0200 schrieb Laurent Pinchart:
 Hi Philipp,
 
 On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
  Hi Laurent,
  
  thanks for this update. I'm very happy about the move to the display entity
  model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
  in a single device - this will allow to use a unified device tree binding
  scheme.
 
 Thanks for the support :-)
 
  I'm still trying to see how this all fits together, so far I have only one
  comment, below.
  
  Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
  [...]
  
   +static int display_of_parse_dt(struct display_entity_notifier *notifier,
   +struct list_head *entities,
   +struct device_node *node)
   +{
   + struct display_entity_of *entity;
   + struct device_node *remote;
   + struct device_node *ep = NULL;
   + struct device_node *next;
   + unsigned int num_entities = 0;
   + int ret = 0;
   +
   + /* Walk the device tree and build a list of nodes. */
   + dev_dbg(notifier-dev, parsing node %s\n, node-full_name);
   +
   + while (1) {
   + next = display_of_get_next_endpoint(node, ep);
   + if (next == NULL)
   + break;
   +
   + of_node_put(ep);
   + ep = next;
   +
   + dev_dbg(notifier-dev, handling endpoint %s\n, ep-full_name);
   +
   + remote = display_of_get_remote_port_parent(ep);
   + if (remote == NULL)
   + continue;
   +
   + /* Skip entities that we have already processed. */
   + if (display_of_find_entity(entities, remote) || remote == node) 
   {
   + dev_dbg(notifier-dev,
   + entity %s already in list, skipping\n,
   + remote-full_name);
   + continue;
   + }
  
  device tree nodes with status = disabled should be skipped here:
  
  if (!of_device_is_available(remote)) {
  dev_dbg(notifier-dev,
  entity %s is disabled, skipping\n,
  remote-full_name);
  continue;
  }
  
  Otherwise the completion notification will never be delivered if there
  are any disabled entities in the graph.
 
 That's a good point, but if a device is disabled, why would it be in the DT 
 graph in the first place ? Do you have a use case for this ?

This is mostly about separate encoders inside the SoC, which are always
present but not useful unless the board designer connected something to
the external pads. Those might be contained in the SoC .dtsi but have
status = disabled set for board device tree writers' convenience.
My use case would be the LVDS encoder bridge or the Synopsys Designware
HDMI TX on i.MX6.

regards
Philipp

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

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

2013-08-21 Thread Martin Peres


On 16/08/2013 09:14, Pali Rohár wrote:

On Thursday 15 August 2013 18:21:51 Martin Peres wrote:

On 15/08/2013 03:24, Pali Rohár wrote:

On Thursday 15 August 2013 04:07:24 Martin Peres wrote:

On 14/08/2013 05:02, Pali Rohár wrote:

On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:

On 13/08/2013 09:53, Pali Rohár wrote:

On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres

wrote:

On 13/08/2013 09:23, Pali Rohár wrote:

On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:

...

You can check the temperature by running nvidia-settings.
If you can't see the temperature in it, then nvidia
doesn't support it on your card and
I'm not sure we should :s

Thanks for the vbios you sent me in private. For the
others, the reason why he doesn't have temperature
anymore is because his vbios lacks sensor calibration
values.

In nvidia-settings tab GPU 0 - (GeForce 6600 GT) --
Thermal Settings is:

Thermal Sensor Information:
ID: 0
Target: GPU
Provider: GPU Internal
Temperature: 70 C (now)

I looked in Windows program SpeedFan. It found Nvidia PCI
card and reported GPU Temp about 68-70 C. So it looks
like both nvidia driver and windows SpeedFan program
reading same values.

Great, I'll cook you a patch in a bit and you'll see what
the temperature is like. It won't be perfectly accurate
but there is some kind of default for nvidia cards of this
generation.

Ok, send me patch and I can try it if it will work and
report similar values as windows or nvidia driver.

Sorry for the late answer.

Please test this patch. Be aware that temperature with nouveau
will be higher than with the blob.
I only want to see if nouveau reports a temperature.

The only way to be sure if the values are good-enough would be
to use the blob and run:
nvapeek 0x15b0
Please send me the result along with the temperature reported
by nvidia at the time of the peek.

Martin

PS: This patch has only be compile-tested, I don't have access
to an nv4x right now.

Hello,

now after patch nouveau report temperature:

$ sensors
...
nouveau-pci-0500
Adapter: PCI adapter
temp1:+63.0°C  (high = +95.0°C, hyst =  +3.0°C)

 (crit = +145.0°C, hyst =  +2.0°C)
 (emerg = +135.0°C, hyst =  +5.0°C)

Ok, that was expected ;)


...

I found that nvidia binary driver has command line utility
nvidia-smi which report same temperature as X utility nvidia-
settings. So I will use nvidia-smi (if it is OK).

And after reboot nvidia report another temperature value:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0

  Temperature
  
  Gpu : 70 C


Immediately I called nvapeek command:

$ nvapeek 0x15b0
15b0: 108e

So value reported by nouveau is lower than value reported by
nvidia binary driver.

As you didn't run nvapeek 15b0 when running nouveau it is hard to tell
if it is due to
calibration values or because the temperature was lower.


I run it and it always reported value 00ff (also when temperature changed).


Seems like we may not calibrate the ADC correctly, this is weird.



Could you please read the temperature + peek 15b0 when running nouveau?

Anyway, it is weird because I cannot find 70°C with 0x8e as an input
temperature and with
the current default values :o


My idea is that register does not contains temperature. Both nouveau and
nvidia driver when show different temperature it does not show different output
from nvapeek 0x15b0.

Now I started computer with nouveau driver. Temperature is incresing, but
nvapeek 0x15b0 is still same.

So do you really needs other tests with nvapeek 0x15b0? Is that register
correct?


I want you to be really sure that 15b0 doesn't change with temperature 
ON THE

PROPRIETARY driver. This is very serious if this is not the case.

If this is not the case, then you must have an i2c device from which the 
blob is

reading temperature and this device isn't detected by Nouveau.

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

Re: [PATCH/RFC v3 00/19] Common Display Framework

2013-08-21 Thread Rob Clark

On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
 On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Rob,
 
  Or maybe, put another way, I still think we should still optimize for the
  common case. I mean I'm sure you *can* design hw that has an LVDS-DP 
  bridge
  in the capture path, and if you had something like an FPGA where that was
  cheap to do maybe you even would (for fun). But if in the real world, 
  there
  are only one or two cases of actual hw using the same bridge in a capture
  pipeline which is normally used in display pipelines, then duplicating 
  some
  small bit of code for that abnormal case if it makes things easier for the
  common case, seems like a reasonable trade-off to me.
 
  That was my opinion as well until I started working on a Xilinx platform.
  There's dozens of IP cores there that are used in both capture and display
  pipelines.

 or maybe just some helper lib's to handling the register level programming?

 Anyways, I guess you can call it a worse is better thing, but if you
 can get 90% of the desired effect for 10% of the work, take the
 simpler solution.  I don't think we should make things more layered or
 more difficult for one exceptional case.


  Furthermore, FPGA display pipelines being made of individual IP cores, we 
  need
  a way to write one driver per IP core and make them all interact. The 
  recently
  proposed drm_bridge is one possible solution to this issue (and to a 
  different
  but similar issue that trigerred the development of drm_bridge), but it's 
  in
  my opinion not generic enough. We're facing several problems that are 
  related,
  it would really be a shame not to solve them with a good enough framework.

 well, I've been working on DSI panel support in msm drm, and also been
 looking at the patches to add DSI support in i915.  And the panel
 interface ends up looking basically like the drm_bridge interface.
 Perhaps the only thing not generic there is the name.

  I mean, take a DSI panel driver, for example.. anything but a trivial 
  panel
  driver, you are going to want to expose some custom properties on the
  connector for controlling non-standard features. So you end up with both
  cdf_foo for the common part, and drm_foo for gluing in the properties. And
  now these two parts which otherwise would be one, end up having to stay in
  sync merged through different trees, etc. It seems a lot like making my 
  life
  more difficult for a fairly hypothetical gain ;-)
 
  The DSI panel driver should not be split into two parts. It should 
  implement a
  CDF entity, any glue needed for DRM will not be part of the panel driver.

 right, but that glue ends up needing to be *somewhere*, which makes it
 the 2nd part.

  Or, take an hdmi or DP bridge. To use any of the common
  infrastructure/helpers in drm, you end up implementing a generic 
  interface,
  where both the producer and consumer is inside drm. Which just seems a bit
  pointless and extra hoops to jump through. Especially when we discover 
  that
  we need to extend/enhance the common interface outside of drm to make it
  work. (I'm thinking of display_entity_control_ops::get_modes() here, but 
  I'm
  sure there are more examples.) And I think we'll run into similar issues
  with display_entity_control_ops::set_state(), since the on-off 
  sequencing
  can get hairy when the upstream/downstream entity is fed a clk by the
  downstream/upstream entity. And similarly, I think we'll go through a few
  revisions of DSI panel/bus params before we have everything that everyone
  needs.
 
  I don't see where needing multiple revisions of a patch set would be bad 
  :-)

 I mean over multiple kernel revisions, as people start adding support
 for new hw and run into limitations of the framework.

 A framework can be changed, extended and fixed. In the end we talking
 about a completely in-kernel framework for which we do not have to
 maintain a stable API.

oh sure, this is why I'd be absolutely against exposing this to
userspace currently..

But my only point here was that an in-drm framework, all the fix-ups
due to a framework change are sorted out before Dave sends his pull
req to linus.  We do this on a semi-regular basis already in drm
already.

Anyways, not a show-stopper thing.. just (in my mind) one additional
inconvenience (and not really the biggest one) about having the
framework outside of drm.  I'm more concerned about just having the
display entity code at a layer below the helpers and property api's
that I'd like to use in drm.

And just to be clear, part of my negative experience about this is the
omapdss/omapdrm split.  I just see cfd outside of drm as encouraging
others to make the same mistake.


 We've already figured out that just having enable() and disable() is
 not sufficient for displayport link training.  I'm not sure what

[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree

Hi,

This patch series adds signal polarities parsing from display-timings
devicetree node. To do it efficiently struct fb_videomode is replaced
with struct videomode and some additional code cleaning is performed.

The patches are for drm-exynos/exynos-drm-next branch.

Regards
Andrzej Hajda

Andrzej Hajda (3):
  drm/exynos: fimd: replace struct fb_videomode with videomode
  drm/exynos: fimd: get signal polarities from device tree
  drm/exynos: fimd: move platform data parsing to separate function

 drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 189 +-
 include/drm/exynos_drm.h  |   3 +-
 3 files changed, 103 insertions(+), 122 deletions(-)

-- 
1.8.1.2

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

[PATCH 1/3] drm/exynos: fimd: replace struct fb_videomode with videomode

The patch replaces all occurrences of struct fb_videomode by
more accurate struct videomode. The change allows to remove
mode conversion function and simplifies clock divider calculation.
Clock configuration is moved to separate function.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 131 +-
 include/drm/exynos_drm.h  |   3 +-
 3 files changed, 70 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index de7c7b2..e082efb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -29,35 +29,6 @@ struct exynos_drm_connector {
uint32_tdpms;
 };
 
-/* convert exynos_video_timings to drm_display_mode */
-static inline void
-convert_to_display_mode(struct drm_display_mode *mode,
-   struct exynos_drm_panel_info *panel)
-{
-   struct fb_videomode *timing = panel-timing;
-
-   mode-clock = timing-pixclock / 1000;
-   mode-vrefresh = timing-refresh;
-
-   mode-hdisplay = timing-xres;
-   mode-hsync_start = mode-hdisplay + timing-right_margin;
-   mode-hsync_end = mode-hsync_start + timing-hsync_len;
-   mode-htotal = mode-hsync_end + timing-left_margin;
-
-   mode-vdisplay = timing-yres;
-   mode-vsync_start = mode-vdisplay + timing-lower_margin;
-   mode-vsync_end = mode-vsync_start + timing-vsync_len;
-   mode-vtotal = mode-vsync_end + timing-upper_margin;
-   mode-width_mm = panel-width_mm;
-   mode-height_mm = panel-height_mm;
-
-   if (timing-vmode  FB_VMODE_INTERLACED)
-   mode-flags |= DRM_MODE_FLAG_INTERLACE;
-
-   if (timing-vmode  FB_VMODE_DOUBLE)
-   mode-flags |= DRM_MODE_FLAG_DBLSCAN;
-}
-
 static int exynos_drm_connector_get_modes(struct drm_connector *connector)
 {
struct exynos_drm_connector *exynos_connector =
@@ -112,7 +83,9 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
return 0;
}
 
-   convert_to_display_mode(mode, panel);
+   drm_display_mode_from_videomode(panel-vm, mode);
+   mode-width_mm = panel-width_mm;
+   mode-height_mm = panel-height_mm;
connector-display_info.width_mm = mode-width_mm;
connector-display_info.height_mm = mode-height_mm;
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f8889d2..a183ea7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -21,6 +21,7 @@
 #include linux/pm_runtime.h
 
 #include video/of_display_timing.h
+#include video/of_videomode.h
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
 
@@ -36,6 +37,8 @@
  * CPU Interface.
  */
 
+#define FIMD_DEFAULT_FRAMERATE 60
+
 /* position control register for hardware window 0, 2 ~ 4.*/
 #define VIDOSD_A(win)  (VIDOSD_BASE + 0x00 + (win) * 16)
 #define VIDOSD_B(win)  (VIDOSD_BASE + 0x04 + (win) * 16)
@@ -242,7 +245,7 @@ static void fimd_commit(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx-panel;
-   struct fb_videomode *timing = panel-timing;
+   struct videomode *vm = panel-vm;
struct fimd_driver_data *driver_data;
u32 val;
 
@@ -254,22 +257,22 @@ static void fimd_commit(struct device *dev)
writel(ctx-vidcon1, ctx-regs + driver_data-timing_base + VIDCON1);
 
/* setup vertical timing values. */
-   val = VIDTCON0_VBPD(timing-upper_margin - 1) |
-  VIDTCON0_VFPD(timing-lower_margin - 1) |
-  VIDTCON0_VSPW(timing-vsync_len - 1);
+   val = VIDTCON0_VBPD(vm-vback_porch - 1) |
+  VIDTCON0_VFPD(vm-vfront_porch - 1) |
+  VIDTCON0_VSPW(vm-vsync_len - 1);
writel(val, ctx-regs + driver_data-timing_base + VIDTCON0);
 
/* setup horizontal timing values.  */
-   val = VIDTCON1_HBPD(timing-left_margin - 1) |
-  VIDTCON1_HFPD(timing-right_margin - 1) |
-  VIDTCON1_HSPW(timing-hsync_len - 1);
+   val = VIDTCON1_HBPD(vm-hback_porch - 1) |
+  VIDTCON1_HFPD(vm-hfront_porch - 1) |
+  VIDTCON1_HSPW(vm-hsync_len - 1);
writel(val, ctx-regs + driver_data-timing_base + VIDTCON1);
 
/* setup horizontal and vertical display size. */
-   val = VIDTCON2_LINEVAL(timing-yres - 1) |
-  VIDTCON2_HOZVAL(timing-xres - 1) |
-  VIDTCON2_LINEVAL_E(timing-yres - 1) |
-  VIDTCON2_HOZVAL_E(timing-xres - 1);
+   val = VIDTCON2_LINEVAL(vm-vactive - 1) |
+

[PATCH 2/3] drm/exynos: fimd: get signal polarities from device tree

The patch adds code to get signal polarization setting
from device tree display-timings node.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a183ea7..6afcaf1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -915,6 +915,15 @@ static int fimd_probe(struct platform_device *pdev)
DRM_ERROR(failed: of_get_videomode() : %d\n, ret);
return ret;
}
+
+   if (vm-flags  DISPLAY_FLAGS_VSYNC_LOW)
+   pdata-vidcon1 |= VIDCON1_INV_VSYNC;
+   if (vm-flags  DISPLAY_FLAGS_HSYNC_LOW)
+   pdata-vidcon1 |= VIDCON1_INV_HSYNC;
+   if (vm-flags  DISPLAY_FLAGS_DE_LOW)
+   pdata-vidcon1 |= VIDCON1_INV_VDEN;
+   if (vm-flags  DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   pdata-vidcon1 |= VIDCON1_INV_VCLK;
} else {
pdata = dev-platform_data;
if (!pdata) {
-- 
1.8.1.2

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

[PATCH 3/3] drm/exynos: fimd: move platform data parsing to separate function

The patch moves platfrom_data and device tree parsing
to separate function.

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 63 
 1 file changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 6afcaf1..130dea5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -122,7 +122,7 @@ struct fimd_context {
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
 
-   struct exynos_drm_panel_info *panel;
+   struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
 };
 
@@ -164,7 +164,7 @@ static void *fimd_get_panel(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
 
-   return ctx-panel;
+   return ctx-panel;
 }
 
 static int fimd_check_mode(struct device *dev, struct drm_display_mode *mode)
@@ -244,7 +244,7 @@ static void fimd_apply(struct device *subdrv_dev)
 static void fimd_commit(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);
-   struct exynos_drm_panel_info *panel = ctx-panel;
+   struct exynos_drm_panel_info *panel = ctx-panel;
struct videomode *vm = panel-vm;
struct fimd_driver_data *driver_data;
u32 val;
@@ -755,7 +755,7 @@ static void fimd_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)
 
 static int fimd_configure_clocks(struct fimd_context *ctx, struct device *dev)
 {
-   struct videomode *vm = ctx-panel-vm;
+   struct videomode *vm = ctx-panel.vm;
unsigned long clk;
 
ctx-bus_clk = devm_clk_get(dev, fimd);
@@ -892,24 +892,13 @@ static int fimd_activate(struct fimd_context *ctx, bool 
enable)
return 0;
 }
 
-static int fimd_probe(struct platform_device *pdev)
+static int fimd_get_platform_data(struct fimd_context *ctx, struct device *dev)
 {
-   struct device *dev = pdev-dev;
-   struct fimd_context *ctx;
-   struct exynos_drm_subdrv *subdrv;
-   struct exynos_drm_fimd_pdata *pdata;
-   struct exynos_drm_panel_info *panel;
-   struct resource *res;
-   int win;
-   int ret = -EINVAL;
-
if (dev-of_node) {
struct videomode *vm;
-   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata)
-   return -ENOMEM;
+   int ret;
 
-   vm = pdata-panel.vm;
+   vm = ctx-panel.vm;
ret = of_get_videomode(dev-of_node, vm, OF_USE_NATIVE_MODE);
if (ret) {
DRM_ERROR(failed: of_get_videomode() : %d\n, ret);
@@ -917,31 +906,45 @@ static int fimd_probe(struct platform_device *pdev)
}
 
if (vm-flags  DISPLAY_FLAGS_VSYNC_LOW)
-   pdata-vidcon1 |= VIDCON1_INV_VSYNC;
+   ctx-vidcon1 |= VIDCON1_INV_VSYNC;
if (vm-flags  DISPLAY_FLAGS_HSYNC_LOW)
-   pdata-vidcon1 |= VIDCON1_INV_HSYNC;
+   ctx-vidcon1 |= VIDCON1_INV_HSYNC;
if (vm-flags  DISPLAY_FLAGS_DE_LOW)
-   pdata-vidcon1 |= VIDCON1_INV_VDEN;
+   ctx-vidcon1 |= VIDCON1_INV_VDEN;
if (vm-flags  DISPLAY_FLAGS_PIXDATA_NEGEDGE)
-   pdata-vidcon1 |= VIDCON1_INV_VCLK;
+   ctx-vidcon1 |= VIDCON1_INV_VCLK;
} else {
-   pdata = dev-platform_data;
+   struct exynos_drm_fimd_pdata *pdata = dev-platform_data;
if (!pdata) {
DRM_ERROR(no platform data specified\n);
return -EINVAL;
}
+   ctx-vidcon0 = pdata-vidcon0;
+   ctx-vidcon1 = pdata-vidcon1;
+   ctx-default_win = pdata-default_win;
+   ctx-panel = pdata-panel;
}
 
-   panel = pdata-panel;
-   if (!panel) {
-   dev_err(dev, panel is null.\n);
-   return -EINVAL;
-   }
+   return 0;
+}
+
+static int fimd_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   struct fimd_context *ctx;
+   struct exynos_drm_subdrv *subdrv;
+   struct resource *res;
+   int win;
+   int ret = -EINVAL;
 
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
+   ret = fimd_get_platform_data(ctx, dev);
+   if (ret)
+   return ret;
+
ret = fimd_configure_clocks(ctx, dev);
if (ret)
return ret;
@@ -968,10 +971,6 @@ static int fimd_probe(struct platform_device *pdev)
}
 
ctx-driver_data = drm_fimd_get_driver_data(pdev);
-

Re: DPM on Radeon HD6570

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan zbos...@pr.hu wrote:
Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

Are you seeing the same results on your board? If so are the results
roughly the same with dpm enabled vs. disabled? If so I doubt there
is a problem with dpm. On older dGPUs like this one dpm won't really
improve performance since the cards come up with relatively high
clocks by default. It's mainly for saving power when the GPU is idle.

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

Alex

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: DPM on Radeon HD6570

2013-08-21 Thread Grigori Goronzy


On 21.08.2013 16:31, Boszormenyi Zoltan wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?



There are some ways to check if DPM functions correctly.

The kernel log (dmesg) contains a dump of the PowerPlay tables, search 
for power state. It's possible that tables aren't read correctly or 
flaky to start with.


You can also monitor the precise runtime power level (clocks and 
voltages) of the GPU with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe 
dynamic switching does not work for some reason, and the GPU always uses 
the lowest level even under load. Just run some demanding OpenGL app and 
check that file to see if the GPU switches the power level.


You should probably file a bug on bugs.freedesktop.org (product DRI, 
component DRM/radeon) and attach dmesg output and anything else that 
might be useful.


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

Re: [PATCH 09/12] drm/edid: Move HDMI_IDENTIFIER to hdmi.h

2013-08-21 Thread Damien Lespiau

On Mon, Aug 19, 2013 at 09:31:42PM +0200, Thierry Reding wrote:
 On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote:
  On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
   On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
   [...]
+#define HDMI_IDENTIFIER 0x000c03
   
   HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI?
  
  This identifier is not infoframe specific, it's the IEEE OUI:
  
http://standards.ieee.org/develop/regauth/oui/oui.txt
  
  would HDMI_IEEE_OUI suit you?
 
 Yes, that sounds much better. Or perhaps IEEE_OUI_HDMI? From a quick
 grep through the kernel code using the OUI as a prefix seems to be
 slightly more common. If we ever end up adding a header to collect
 OUIs it'd be useful to namespace them somehow.

Hopefully we can agree that HDMI_IEEE_OUI is fine :) Would you mind
having a look at the two patches introduced to address your comments

  HDMI 4k support v4
  http://lists.freedesktop.org/archives/dri-devel/2013-August/043988.html

Patches 11 and 14.

Thanks,

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

[Bug 68389] New: [radeonsi]Black screen in unigine-tropics

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

  Priority: medium
Bug ID: 68389
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [radeonsi]Black screen in unigine-tropics
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: granti...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 84399
  -- https://bugs.freedesktop.org/attachment.cgi?id=84399action=edit
Black screen in unigine-tropics

Subj!

ArchLinux x32; kernel 3.10; llvm - svn; mesa - git; Radeon HD 7950.

behem0th@ArchLinux ~ $ unigine-tropics_1024x768_windowed.sh 
Loading /home/behem0th/.Unigine Tropics/unigine.cfg...
Loading libGL.so.1...
Loading libopenal.so.1...
Set 1024x768 windowed video mode
Set 1.00 gamma value
Unigine engine http://unigine.com/
Binary: Linux 32bit GCC 4.3.2 Release May 20 2010
App path:  /opt/unigine-tropics/bin/
Data path: /opt/unigine-tropics/data/
Save path: /home/behem0th/.Unigine Tropics/

 System 
System: Linux 3.10.0-1-ARCH i686
CPU: AMD Phenom(tm) 9550 Quad-Core Processor 2200MHz MMX+ 3DNow!+ SSE SSE2 SSE3
SSE4A HTT
GPU: Gallium 0.4 on AMD TAHITI 2.1 Mesa 9.3.0-devel (git-10aa367)
System memory: 8095 Mb
Video memory:  256 Mb

 MathLib 
Set SSE3 simd processor

 Sound 
Renderer: OpenAL Soft
OpenAL vendor:   OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version:  1.1 ALSOFT 1.15.1
Found AL_EXT_LINEAR_DISTANCE
Found AL_EXT_OFFSET
Found ALC_EXT_EFX
Found EFX Filter
Found EFX Reverb
Found EAX Reverb
Found QUAD16 format
Found 51CHN16 format
Found 61CHN16 format
Found 71CHN16 format
Maximum sources: 256
Maximum effect slots:4
Maximum auxiliary sends: 2

 Render 
GLRender::GLRender(): Unknown GPU
OpenGL vendor:   X.Org
OpenGL renderer: Gallium 0.4 on AMD TAHITI
OpenGL version:  2.1 Mesa 9.3.0-devel (git-10aa367)
Found required GL_ARB_map_buffer_range
Found required GL_ARB_vertex_array_object
Found required GL_ARB_vertex_buffer_object
Found required GL_ARB_half_float_vertex
Found required GL_ARB_half_float_pixel
Found required GL_ARB_occlusion_query
Found required GL_EXT_texture3D
Found required GL_EXT_texture_cube_map
Found required GL_EXT_texture_sRGB
Found required GL_EXT_texture_swizzle
Found required GL_ARB_shader_object
Found required GL_ARB_vertex_shader
Found required GL_ARB_fragment_shader
Found required GL_ARB_draw_buffers
Found required GL_ARB_framebuffer_object
Found required GL_EXT_framebuffer_blit
Found required GL_EXT_framebuffer_multisample
Found optional GL_ARB_draw_instanced
Found optional GL_ARB_draw_elements_base_vertex
Found optional GL_ARB_texture_rg
Found optional GL_EXT_texture_array
Found optional GL_ARB_texture_multisample
Found optional GL_ARB_texture_compression
Found optional GL_ARB_texture_compression_rgtc
Found optional GL_ARB_seamless_cube_map
Shading language:  1.30
Maximum texture size:  16384
Maximum texture units: 32
Maximum draw buffers:  8

 Physics 
Physics: Multi-threaded

 Interpreter 
Version: 2.31

Loading tropics/unigine.cpp 126ms
Loading demos/tropics/locale/unigine.ru dictionary
Loading core/materials/unigine_post.mat 12 materials 12 shaders 0ms
Loading core/materials/unigine_render.mat 34 materials 77 shaders 13ms
Loading core/materials/unigine_meshes.mat 16 materials 9350 shaders 99ms
Loading core/materials/unigine_terrains.mat 1 material 293 shaders 5ms
Loading core/materials/unigine_grass.mat 1 material 81 shaders 8ms
Loading core/materials/unigine_particles.mat 1 material 43 shaders 7ms
Loading core/materials/unigine_billboards.mat 1 material 33 shaders 8ms
Loading core/materials/unigine_volumes.mat 5 materials 29 shaders 15ms
Loading core/materials/unigine_guis.mat 1 material 24 shaders 2ms
Loading core/materials/unigine_water.mat 1 material 63 shaders 20ms
Loading core/materials/unigine_skies.mat 1 material 19 shaders 25ms
Loading core/materials/unigine_decals.mat 1 material 69 shaders 11ms
Loading core/properties/unigine.prop 2 properties 1ms
Unigine~# world_load tropics
Loading tropics.cpp 320ms
Loading demos/tropics/tropics.mat 40 materials 812ms
Loading tropics.world 15813ms
Unigine~# render_hdr 1  render_srgb 0  render_restart
Release
GLShader::loadFragment(): error in
core/shaders/render/fragment_occlusion_blur.shader file
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_TEXTURE_MULTISAMPLE,HAS_ARB_DRAW_INSTANCED
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no matching function for call to `texelFetch2DOffset(sampler2D,
ivec2, int, ivec2)'
0:0(0): error: no

[Bug 68389] [radeonsi]Black screen in unigine-tropics

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

--- Comment #1 from Vladimir Ysikov granti...@gmail.com ---
Created attachment 84403
  -- https://bugs.freedesktop.org/attachment.cgi?id=84403action=edit
Shader dump from unigine-tropics

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

[Bug 68389] [radeonsi]Black screen in unigine-tropics

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

Vladimir Ysikov granti...@gmail.com changed:

   What|Removed |Added

  Attachment #84399|text/plain  |image/png
  mime type||

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

[Bug 68391] New: [radeonsi] Crash unigine-sanctuary

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

  Priority: medium
Bug ID: 68391
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [radeonsi] Crash unigine-sanctuary
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: granti...@gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

ArchLinux x32; kernel 3.10; llvm - svn; mesa - git; Radeon HD 7950.

behem0th@ArchLinux ~ $ unigine-sanctuary 
fullscreen? Please enter 1 or 0. (1 = yes, 0 = no)
0
video width? e.g. 1024

video height? e.g. 768

Loading /home/behem0th/.Unigine Sanctuary/unigine.cfg...
Engine::init(): clear video settings for Gallium 0.4 on AMD TAHITI 2.1 Mesa
9.3.0-devel (git-10aa367)
Loading libGL.so.1...
Loading libopenal.so.1...
Set 640x480 windowed video mode
Set 1.00 gamma value
Unigine engine http://unigine.com/
Binary: Linux 32bit GCC 4.3.2 Release May 20 2010
App path:  /opt/unigine-sanctuary/bin/
Data path: /opt/unigine-sanctuary/data/
Save path: /home/behem0th/.Unigine Sanctuary/

 System 
System: Linux 3.10.0-1-ARCH i686
CPU: AMD Phenom(tm) 9550 Quad-Core Processor 2199MHz MMX+ 3DNow!+ SSE SSE2 SSE3
SSE4A HTT
GPU: Gallium 0.4 on AMD TAHITI 2.1 Mesa 9.3.0-devel (git-10aa367)
System memory: 8095 Mb
Video memory:  256 Mb

 MathLib 
Set SSE3 simd processor

 Sound 
Renderer: OpenAL Soft
OpenAL vendor:   OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version:  1.1 ALSOFT 1.15.1
Found AL_EXT_LINEAR_DISTANCE
Found AL_EXT_OFFSET
Found ALC_EXT_EFX
Found EFX Filter
Found EFX Reverb
Found EAX Reverb
Found QUAD16 format
Found 51CHN16 format
Found 61CHN16 format
Found 71CHN16 format
Maximum sources: 256
Maximum effect slots:4
Maximum auxiliary sends: 2

 Render 
GLRender::GLRender(): Unknown GPU
OpenGL vendor:   X.Org
OpenGL renderer: Gallium 0.4 on AMD TAHITI
OpenGL version:  2.1 Mesa 9.3.0-devel (git-10aa367)
Found required GL_ARB_map_buffer_range
Found required GL_ARB_vertex_array_object
Found required GL_ARB_vertex_buffer_object
Found required GL_ARB_half_float_vertex
Found required GL_ARB_half_float_pixel
Found required GL_ARB_occlusion_query
Found required GL_EXT_texture3D
Found required GL_EXT_texture_cube_map
Found required GL_EXT_texture_sRGB
Found required GL_EXT_texture_swizzle
Found required GL_ARB_shader_object
Found required GL_ARB_vertex_shader
Found required GL_ARB_fragment_shader
Found required GL_ARB_draw_buffers
Found required GL_ARB_framebuffer_object
Found required GL_EXT_framebuffer_blit
Found required GL_EXT_framebuffer_multisample
Found optional GL_ARB_draw_instanced
Found optional GL_ARB_draw_elements_base_vertex
Found optional GL_ARB_texture_rg
Found optional GL_EXT_texture_array
Found optional GL_ARB_texture_multisample
Found optional GL_ARB_texture_compression
Found optional GL_ARB_texture_compression_rgtc
Found optional GL_ARB_seamless_cube_map
Shading language:  1.30
Maximum texture size:  16384
Maximum texture units: 32
Maximum draw buffers:  8

 Physics 
Physics: Multi-threaded

 Interpreter 
Version: 2.31

Loading sanctuary/unigine.cpp 124ms
Loading demos/sanctuary/locale/unigine.en dictionary
Loading core/materials/unigine_post.mat 12 materials 12 shaders 0ms
Loading core/materials/unigine_render.mat 34 materials 77 shaders 14ms
Loading core/materials/unigine_meshes.mat 16 materials 9350 shaders 105ms
Loading core/materials/unigine_terrains.mat 1 material 293 shaders 4ms
Loading core/materials/unigine_grass.mat 1 material 81 shaders 8ms
Loading core/materials/unigine_particles.mat 1 material 43 shaders 7ms
Loading core/materials/unigine_billboards.mat 1 material 33 shaders 8ms
Loading core/materials/unigine_volumes.mat 5 materials 29 shaders 18ms
Loading core/materials/unigine_guis.mat 1 material 24 shaders 3ms
Loading core/materials/unigine_water.mat 1 material 63 shaders 21ms
Loading core/materials/unigine_skies.mat 1 material 19 shaders 25ms
Loading core/materials/unigine_decals.mat 1 material 69 shaders 10ms
Loading core/properties/unigine.prop 2 properties 1ms
Unigine~# world_load sanctuary
Loading sanctuary.cpp 104ms
Loading sanctuary/sanctuary.mat 54 materials 640ms
Loading sanctuary.world 13950ms
Unigine~# render_hdr 0  render_srgb 0  render_restart
LLVM ERROR: ran out of registers during register allocation
AL lib: (EE) alc_cleanup: 1 device not closed

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

Re: DPM on Radeon HD6570

Hi,

thanks for your response.

2013-08-21 17:39 keltezéssel, Alex Deucher írta:

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan zbos...@pr.hu wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1 radeon.dpm=1
LANG=hu_HU.UTF-8

I have just tried openarena 0.8.5 again with forced low performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:
http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zoltán Böszörményi

Alex

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: DPM on Radeon HD6570

On Wed, Aug 21, 2013 at 1:49 PM, Boszormenyi Zoltan zbos...@pr.hu wrote:
Hi,

thanks for your response.

2013-08-21 17:39 keltezéssel, Alex Deucher írta:

On Wed, Aug 21, 2013 at 10:31 AM, Boszormenyi Zoltan zbos...@pr.hu
wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?

I have enabled dpm:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git0.1.fc20.x86_64
root=UUID=00df37a2-be3d-46fe-963a-ca08977fc5f6 ro quiet rhgb radeon.audio=1
radeon.dpm=1 LANG=hu_HU.UTF-8

I have just tried openarena 0.8.5 again with forced low performance.
Results is 26.87fps with low performance, 59.40-59.70fps with forced high
performance.

Sounds like you are refresh rate limited. Try disabling
swapbufferswait in your xorg.conf:

Section Device
Identifier card0
Driver iradeon
Option SwapbuffersWait false
EndSection

and disable vsync in the 3D driver, set env var:
vblank_mode=0

Also what does the performance look like with dpm disabled?

Anyway, it doesn't sound like dpm is an issue.

Alex

I have this kind of video card, so I wanted to test it myself.
The exact model of my card is:

http://www.sapphiretech.com/presentation/product/?cid=1gid=3sgid=1087pid=1176psn=lid=1leg=0#

Note that a lot of 6570 cards, including yours use DD3 memory rather
than GDDR5 so they will have fairly limited memory bandwidth.

I know. The 6570 tested by Phoronix must be GDDR5
but it's not mentioned specifically.

Best regards,
Zoltán Böszörményi

Alex

I have installed kernel 3.11-rc6 on Fedora 19 using this koji kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=457463

I haven't tested Catalyst but my r600g results mostly match
the ones in the article even with a different CPU.

Best regards,
Zoltán Böszörményi

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

Re: DPM on Radeon HD6570


2013-08-21 18:30 keltezéssel, Grigori Goronzy írta:

On 21.08.2013 16:31, Boszormenyi Zoltan wrote:

Hi,

I read this Phoronix article:
http://www.phoronix.com/scan.php?page=articleitem=amd_hd6000_dpmnum=1

Congrats to the progress achieved so far.

However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.

r600g can reach 80+ percent of the performance of Catalyst
for most HD6xxx chips except for 6570, where the performance
is around 10-20 percent.

Do you have a theory about this difference?
Maybe DPM doesn't work as intended on HD6570?



There are some ways to check if DPM functions correctly.

The kernel log (dmesg) contains a dump of the PowerPlay tables, search for power 
state. It's possible that tables aren't read correctly or flaky to start with.


Here it is:

[2.252567] [drm] Internal thermal controller with fan control
[2.252619] == power state 0 ==
[2.252621]  ui class: none
[2.252622]  internal class: boot
[2.252624]  caps:
[2.252625]  uvdvclk: 0 dclk: 0
[2.252627]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252628]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252629]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252630]  status: c r b
[2.252632] == power state 1 ==
[2.252632]  ui class: performance
[2.252633]  internal class: none
[2.252635]  caps:
[2.252636]  uvdvclk: 0 dclk: 0
[2.252637]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.252640]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.252641]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252642]  status:
[2.252643] == power state 2 ==
[2.252644]  ui class: none
[2.252645]  internal class: uvd
[2.252646]  caps: video
[2.252647]  uvdvclk: 7 dclk: 56000
[2.252651]  power level 0sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252652]  power level 1sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252653]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.252654]  status:
[2.257099] switching from power state:
[2.257105]  ui class: none
[2.257107]  internal class: boot
[2.257109]  caps:
[2.257111]  uvdvclk: 0 dclk: 0
[2.257113]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257114]  power level 1sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257116]  power level 2sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257117]  status: c b
[2.257129] switching to power state:
[2.257130]  ui class: performance
[2.257132]  internal class: none
[2.257133]  caps:
[2.257135]  uvdvclk: 0 dclk: 0
[2.257137]  power level 0sclk: 1 mclk: 15000 vddc: 900 
vddci: 0
[2.257139]  power level 1sclk: 4 mclk: 8 vddc: 1000 
vddci: 0
[2.257140]  power level 2sclk: 65000 mclk: 8 vddc: 1050 
vddci: 0
[2.257141]  status: r
[2.258555] [drm] radeon: dpm initialized




You can also monitor the precise runtime power level (clocks and voltages) of the GPU 
with /sys/kernel/debug/dri/0/radeon_pm_info. Maybe dynamic switching does not work for 
some reason, and the GPU always uses the lowest level even under load. Just run some 
demanding OpenGL app and check that file to see if the GPU switches the power level.


Just running this loop:

[root@localhost ~]# while `/bin/true` ; do cat /sys/kernel/debug/dri/0/radeon_pm_info ; 
sleep 1 ; done


while the terminal is sufficiently large on the screen results in changing 
power levels:

uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 0sclk: 1 mclk: 15000 vddc: 900 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk: 65000 mclk: 8 vddc: 1050 vddci: 0
uvdvclk: 0 dclk: 0
power level 2sclk:

[Bug 65254] opengl flicker in xbmc / glxgears

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

--- Comment #17 from Vladi vl...@aresgate.net ---
so far after disabling radeon.dpm I dont see the reboots. but my screen is
still seeing the artifacts/flicker

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

Re: [PATCH v2 4/8] drm/i2c: tda998x: prepare for video input configuration

On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
 From: Russell King rmk+kernel at arm.linux.org.uk
 
 The video-input-port (VIP) is highly configurable. This prepares
 current driver to allow to configure VIP configuration, as some
 boards connect lcd controller and TDA998x pin-swapped and depend
 on VIP to swap the pins by register configuration.
 
 Signed-off-by: Russell King rmk+kernel at arm.linux.org.uk
 Tested-by: Darren Etheridge detheridge at ti.com
 Tested-by: Sebastian Hesselbarth sebastian.hesselbarth at gmail.com
[snip]

AFAIK, the TI boards have no pin-swapped, nor has the Cubox (there is
no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0
of the Dove lcd for RGB or YUV formats).

Which board needs a special VIP configuration?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration

On Wed Aug 14 12:43:30 PDT 2013, Sebastian Hesselbarth wrote:
 From: Russell King rmk+kernel at arm.linux.org.uk
 
 This patch adds tda998x specific parameters to allow it to be configured
 for different boards using it. Also, this implements rudimentary audio
 support for S/PDIF attached controllers.

It seems that this patch mixes two different functions:
- configuration
- audio

About configuration, why don't you use the standard way to set the
device parameters, i.e. board info and DT?

 Signed-off-by: Russell King rmk+kernel at arm.linux.org.uk
 Signed-off-by: Sebastian Hesselbarth sebastian.hesselbarth at gmail.com
 Tested-by: Darren Etheridge detheridge at ti.com
 ---
 Changelog:
 for v1:
 - set AUDIO_DIV to SERCLK/16 for modes with pixclk 100MHz
 - also calculate CTS
 v1-v2:
 - Remove CTS calculation as it isn't used in current TDA998x setup
   (Reported by Russell King)
 - Remove debug left-over (Reported by Russell King)
 - Use correct tda998x include (Reported by Russell King)
 
 Cc: David Airlie airlied at linux.ie
 Cc: Darren Etheridge detheridge at ti.com
 Cc: Rob Clark robdclark at gmail.com
 Cc: Russell King rmk+kernel at arm.linux.org.uk
 Cc: Daniel Vetter daniel.vetter at ffwll.ch
 Cc: dri-devel at lists.freedesktop.org
 Cc: linux-kernel at vger.kernel.org
 ---
  drivers/gpu/drm/i2c/tda998x_drv.c |  268 
 +++--
  include/drm/i2c/tda998x.h |   30 +
  2 files changed, 290 insertions(+), 8 deletions(-)
  create mode 100644 include/drm/i2c/tda998x.h
 
 diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
 b/drivers/gpu/drm/i2c/tda998x_drv.c
 index 527d11b..2b64dfa 100644
 --- a/drivers/gpu/drm/i2c/tda998x_drv.c
 +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
[snip]
 @@ -344,6 +390,23 @@ fail:
   return ret;
  }
  
 +static void
 +reg_write_range(struct drm_encoder *encoder, uint16_t reg, uint8_t *p, int 
 cnt)
 +{
 + struct i2c_client *client = drm_i2c_encoder_get_client(encoder);
 + uint8_t buf[cnt+1];
 + int ret;
 +
 + buf[0] = REG2ADDR(reg);
 + memcpy(buf[1], p, cnt);
 +
 + set_page(encoder, reg);
 +
 + ret = i2c_master_send(client, buf, cnt + 1);
 + if (ret  0)
 + dev_err(client-dev, Error %d writing to 0x%x\n, ret, reg);
 +}
 +

It seems simpler to reserve one byte in the caller buffer for the
register address and avoid a memcpy.

  static uint8_t
  reg_read(struct drm_encoder *encoder, uint16_t reg)
  {
 @@ -412,7 +475,7 @@ tda998x_reset(struct drm_encoder *encoder)
   reg_write(encoder, REG_SERIALIZER,   0x00);
   reg_write(encoder, REG_BUFFER_OUT,   0x00);
   reg_write(encoder, REG_PLL_SCG1, 0x00);
 - reg_write(encoder, REG_AUDIO_DIV,0x03);
 + reg_write(encoder, REG_AUDIO_DIV,AUDIO_DIV_SERCLK_8);
   reg_write(encoder, REG_SEL_CLK,  SEL_CLK_SEL_CLK1 | 
 SEL_CLK_ENA_SC_CLK);
   reg_write(encoder, REG_PLL_SCGN1,0xfa);
   reg_write(encoder, REG_PLL_SCGN2,0x00);
 @@ -424,11 +487,184 @@ tda998x_reset(struct drm_encoder *encoder)
   reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
  }
  
 +static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
 +{
 + uint8_t sum = 0;
 +
 + while (bytes--)
 + sum += *buf++;
 + return (255 - sum) + 1;
 +}

Simpler:

static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
{
int sum = 0;/* avoid byte computation */

while (bytes--)
sum -= *buf++;  /* avoid a substraction */
return sum;
}

 +
 +#define HB(x) (x)
 +#define PB(x) (HB(2) + 1 + (x))
 +
 +static void
 +tda998x_write_if(struct drm_encoder *encoder, uint8_t bit, uint16_t addr,
 +  uint8_t *buf, size_t size)
 +{
 + buf[PB(0)] = tda998x_cksum(buf, size);
 +
 + reg_clear(encoder, REG_DIP_IF_FLAGS, bit);
 + reg_write_range(encoder, addr, buf, size);
 + reg_set(encoder, REG_DIP_IF_FLAGS, bit);
 +}
 +
 +static void
 +tda998x_write_aif(struct drm_encoder *encoder, struct tda998x_encoder_params 
 *p)
 +{
 + uint8_t buf[PB(5) + 1];
 +
 + buf[HB(0)] = 0x84;
 + buf[HB(1)] = 0x01;
 + buf[HB(2)] = 10;

Why don't you use the constants which are defined in hdmi.h?

 + buf[PB(0)] = 0;
 + buf[PB(1)] = p-audio_frame[1]  0x07; /* CC */
 + buf[PB(2)] = p-audio_frame[2]  0x1c; /* SF */
 + buf[PB(4)] = p-audio_frame[4];
 + buf[PB(5)] = p-audio_frame[5]  0xf8; /* DM_INH + LSV */
 +
 + tda998x_write_if(encoder, DIP_IF_FLAGS_IF4, REG_IF4_HB0, buf,
 +  sizeof(buf));
 +}
 +
 +static void
 +tda998x_write_avi(struct drm_encoder *encoder, struct drm_display_mode *mode)
 +{
 + uint8_t buf[PB(13) + 1];
 +
 + memset(buf, 0, sizeof(buf));
 + buf[HB(0)] = 0x82;
 + buf[HB(1)] = 0x02;
 + buf[HB(2)] = 13;
 + buf[PB(4)] = drm_match_cea_mode(mode);
 +
 + tda998x_write_if(encoder, DIP_IF_FLAGS_IF2, REG_IF2_HB0, buf,
 +  sizeof(buf));
 +}
 +
 +static void

Re: DPM on Radeon HD6570