Softlockup on boot with Cape Verde XT on many kernels
AFAIK this BIOS requires me to disable IGP to even use the discrete graphics. At least that's the first thing I had to do when I first installed the card and every time I wanted to change the monitor connection. Here's how "disabled" it is: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png 2015-01-14 23:46 GMT-03:00 Michel Dänzer : > On 15.01.2015 11:10, Federico wrote: > > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using > > softlockup_panic=1. > > > > Quite similar, but slightly different. Hopefully, useful. > > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png > > Looks like it hangs while reading the video BIOS ROM. > > If the integrated GPU is still enabled in the system BIOS setup, does > disabling it avoid the problem? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/de4ec6d0/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
Here's the 3.18 32-bits 60 lines per screen stack trace. Always using softlockup_panic=1. Quite similar, but slightly different. Hopefully, useful. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png 2015-01-14 21:10 GMT-03:00 Federico : > Here's a stacktrace with 60 lines. It is more complete. > It's 3.18 64 bits. > Next I'm going to try the same with a 32 bit kernel. > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298722/+files/20150114_205715.png > > > 2015-01-14 10:29 GMT-03:00 Federico : > > Here's a stack trace with soflockup_panic=1 using 50 lines per screen. >> >> >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png >> >> >> 2015-01-14 0:54 GMT-03:00 Michel Dänzer : >> >> On 14.01.2015 12:41, Federico wrote: >>> > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and >>> > I got a different stack trace. Shorter. It repeats itself every about >>> 30 >>> > seconds more or less. Keyboard lights don't flash. The same message >>> > keeps coming out. >>> > >>> > >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png >>> >>> That's again missing some of the information, but it doesn't look >>> directly related to the radeon driver. >>> >>> >>> -- >>> Earthling Michel Dänzer | http://www.amd.com >>> Libre software enthusiast | Mesa and X developer >>> >> >> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/e8a58aac/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
Here's a stacktrace with 60 lines. It is more complete. It's 3.18 64 bits. Next I'm going to try the same with a 32 bit kernel. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298722/+files/20150114_205715.png 2015-01-14 10:29 GMT-03:00 Federico : > Here's a stack trace with soflockup_panic=1 using 50 lines per screen. > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png > > > 2015-01-14 0:54 GMT-03:00 Michel Dänzer : > > On 14.01.2015 12:41, Federico wrote: >> > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and >> > I got a different stack trace. Shorter. It repeats itself every about 30 >> > seconds more or less. Keyboard lights don't flash. The same message >> > keeps coming out. >> > >> > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png >> >> That's again missing some of the information, but it doesn't look >> directly related to the radeon driver. >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/5350de28/attachment.html>
[PATCH] next: drm/atomic: Use copy_from_user to copy 64 bit data from user space
On Mon, Jan 12, 2015 at 09:12:17PM -0800, Guenter Roeck wrote:
> Copying 64 bit data from user space using get_user is not supported
> on all architectures, and may result in the following build error.
>
> ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
>
> Avoid the problem by using copy_from_user.
>
> Fixes: d34f20d6e2f2 ("drm: Atomic modeset ioctl")
> Cc: Rob Clark
> Signed-off-by: Guenter Roeck
Merged into my drm misc branch, thanks.
-Daniel
> ---
> Compile tested only.
>
> drivers/gpu/drm/drm_atomic.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1e38dfc..af3f3df 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1259,7 +1259,9 @@ retry:
> goto fail;
> }
>
> - if (get_user(prop_value, prop_values_ptr + copied_props)) {
> + if (copy_from_user(&prop_value,
> + prop_values_ptr + copied_props,
> + sizeof(prop_value))) {
> ret = -EFAULT;
> goto fail;
> }
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 01:54:06PM +, Jindal, Sonika wrote: > I think I am confused here.. > Since sprite plane handles this scaling and rotation in kernel, I thought it > should be taken care in driver for primary as well. Well, userspace still has to know how the src and dst coordinates relate to each other. Src coordinates are based on the memory layout. So src x=0,y=0 is the first pixel in memory. x=1,y=0 is the second pixel in memory etc. Dst coordinates are based on the display pipe. So dst x=0,y=0 is the first pixel that gets pushed out by the pipe for each frame. x=1,y=0 is the second pixel getting pushed out. Let's say we have a 4x2 FB and a display mode of 8x4. Then we want to use a sprite plane to present the FB with 0 and 90 degree rotation, and we want to position the sprite plane at coordinates 2,0 on the CRTC. It should look something like this: rotation=0 src: x1=0,y1=0,x2=4,y2=2 (w=4, h=2) dst: x1=2,y1=0,x2=6,y2=2 (w=4, h=2) FB:CRTC: 0,0 0,0 |abcd| | abcd | |efgh| | efgh | 4,2 || || 8,4 rotation=90 src=0,0 -> 4,2 (w=4, h=2) dst=2,0 -> 4,4 (w=2, h=4) FB:CRTC: 0,0 0,0 |abcd| | dh| |efgh| | cg| 4,2 | bf| | ae| 8,4 > >From the test, I don't really change the src sizes for primary as well as > >sprite to take care of 90/270 rotation. Sounds a bit buggy then. > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Wednesday, January 14, 2015 5:14 PM > To: Jindal, Sonika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > drm_plane_helper_check_update > > On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote: > > Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h. > > Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser > > than the min_hscale (which is no_scaling by default), so it returns -ERANGE. > > If you want no scaling then with 90/270 rotation then your src->w should be > equal to dst->h. Then the calculated vscale will be 1.0. If it's not, then > your test is passing in bad coordinates. > > > So, I think we _relaxed is the function which should be called to update > > the destination size appropriately. > > Please correct me if I am wrong. > > > > -Original Message- > > From: Jindal, Sonika > > Sent: Wednesday, January 14, 2015 3:06 PM > > To: 'Ville Syrjälä' > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > drm_plane_helper_check_update > > > > We do exactly like this for sprite plane (ie, rotate the rect, then check > > scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed) > > That's why I saw the need of this for primary plane as well. > > For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments > > and the rotated sizes are fine. But since we don't do any of those stuff > > for primary the destination size doesn't come right, and I get a little > > corrupted output after rotation. > > With this change, the rotated plane is properly adjusted in the viewport. > > So, I don't think it is a bug in test. > > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > > Sent: Wednesday, January 14, 2015 2:58 PM > > To: Jindal, Sonika > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > drm_plane_helper_check_update > > > > On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote: > > > > > > On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote: > > > > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote: > > > >> Taking rotation into account while checking the plane and > > > >> adjusting the sizes accordingly. > > > >> > > > >> Signed-off-by: Sonika Jindal > > > >> --- > > > >> drivers/gpu/drm/drm_plane_helper.c | 79 > > > >> ++-- > > > >> include/drm/drm_plane_helper.h |3 +- > > > >> 2 files changed, 77 insertions(+), 5 deletions(-) > > > >> > > > >> diff --git a/drivers/gpu/drm/drm_plane_helper.c > > > >> b/drivers/gpu/drm/drm_plane_helper.c > > > >> index f24c4cf..4badd69 100644 > > > >> --- a/drivers/gpu/drm/drm_plane_helper.c > > > >> +++ b/drivers/gpu/drm/drm_plane_helper.c > > > >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct > > > >> drm_plane *plane, > > > >>int max_scale, > > > >>bool can_position, > > > >>bool can_update_disabled, > > > >> -
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 --- Comment #9 from João Grego --- Having the same issue with HD5650. When using mesa 10.2.8 there was no problem, but when I upgraded to mesa 10.4.2 the entire system froze after loading a game, either new or saved. OS: Gentoo amd64 GPU: Radeon HD5650 GPU driver: xf86-video-ati 7.5.0 Mesa: 10.4.2 CPU: intel i3 M370 -- 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/20150114/d5c5bb34/attachment.html>
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 --- Comment #15 from Alex Deucher --- Created attachment 112228 --> https://bugs.freedesktop.org/attachment.cgi?id=112228&action=edit add some debugging output Based on the timing for the 1920x1080 at 120 timing from your xorg log, it looks like it should be just under the switch limit. Can you apply the attached patch and switch to the problematic mode and then attach your dmesg output so I can see what's happening? -- 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/20150114/8ea4dc0b/attachment.html>
[PATCH 00/24] radeon audio rework
On Wed, Jan 14, 2015 at 10:01 AM, Christian König wrote: > Am 13.01.2015 um 18:46 schrieb Alex Deucher: >> >> This patch set cleans up the radeon audio handling >> and also adds support for DP audio on all supported >> asics. > > > Apart from the white space problems and the changes from patch #5 the set is > Reviewed-by: Christian König I've pushed Slava's latest patch spin to my 3.20-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.20-wip Alex > > Regards. > Christian. > > >> >> Alex Deucher (1): >>drm/radeon: whitespace clean up in radeon_audio.c >> >> Slava Grigorev (23): >>radeon/audio: consolidate audio_init() functions >>radeon/audio: defined initial audio interface that gets initialized >> via detect() call >>radeon/audio: consolidate write_sad_regs() functions >>radeon/audio: consolidate write_speaker_allocation() functions >>radeon/audio: consolidate write_latency_fields() functions >>radeon/audio: consolidate audio_get_pin() functions >>radeon/audio: consolidate select_pin() functions >>radeon/audio: consolidate audio_enable() functions >>radeon/audio: consolidate audio_fini() functions >>radeon/audio: consolidate audio_set_dto() functions >>radeon/audio: consolidate update_avi_infoframe() functions >>radeon/audio: consolidate update_acr() functions >>radeon/audio: moved VBI packet programming to separate functions >>radeon: moved HDMI color depth programming to a separate function >>radeon/audio: removed unnecessary CRC control programing >>radeon/audio: set_avi_packet() function cleanup >>radeon/audio: moved audio packet programming to a separate function >>radeon/audio: moved mute programming to a separate function >>radeon/audio: removed unnecessary debug settings >>radeon/audio: consolidate audio_mode_set() functions >>radeon/audio: applied audio_dpms() and audio_mode_set() calls >>radeon/audio: moved audio caps programming to audio_hotplug() function >>radeon/audio: enable DP audio >> >> drivers/gpu/drm/radeon/Makefile| 2 +- >> drivers/gpu/drm/radeon/atombios_encoders.c | 29 +- >> drivers/gpu/drm/radeon/cik.c | 5 +- >> drivers/gpu/drm/radeon/dce3_1_afmt.c | 264 +- >> drivers/gpu/drm/radeon/dce6_afmt.c | 218 >> drivers/gpu/drm/radeon/evergreen.c | 7 +- >> drivers/gpu/drm/radeon/evergreen_hdmi.c| 478 -- >> drivers/gpu/drm/radeon/evergreen_reg.h | 15 + >> drivers/gpu/drm/radeon/evergreend.h| 1 + >> drivers/gpu/drm/radeon/ni.c| 18 +- >> drivers/gpu/drm/radeon/r600.c | 7 +- >> drivers/gpu/drm/radeon/r600_hdmi.c | 387 --- >> drivers/gpu/drm/radeon/radeon.h| 3 + >> drivers/gpu/drm/radeon/radeon_asic.c | 28 -- >> drivers/gpu/drm/radeon/radeon_asic.h | 8 - >> drivers/gpu/drm/radeon/radeon_audio.c | 765 >> + >> drivers/gpu/drm/radeon/radeon_audio.h | 84 >> drivers/gpu/drm/radeon/radeon_connectors.c | 8 + >> drivers/gpu/drm/radeon/radeon_mode.h | 1 + >> drivers/gpu/drm/radeon/rs600.c | 7 +- >> drivers/gpu/drm/radeon/rs690.c | 7 +- >> drivers/gpu/drm/radeon/rv770.c | 5 +- >> drivers/gpu/drm/radeon/si.c| 5 +- >> drivers/gpu/drm/radeon/sid.h | 10 + >> 24 files changed, 1458 insertions(+), 904 deletions(-) >> create mode 100644 drivers/gpu/drm/radeon/radeon_audio.c >> create mode 100644 drivers/gpu/drm/radeon/radeon_audio.h >> >
[PATCH] drm/radeon/radeon_fb: Remove unused function
On Tue, Jan 13, 2015 at 2:02 PM, Rickard Strandqvist
wrote:
> Remove the function radeon_fbdev_total_size() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_fb.c | 10 --
> drivers/gpu/drm/radeon/radeon_mode.h |1 -
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
> b/drivers/gpu/drm/radeon/radeon_fb.c
> index 0ea1db8..76adbdb 100644
> --- a/drivers/gpu/drm/radeon/radeon_fb.c
> +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> @@ -389,16 +389,6 @@ void radeon_fbdev_set_suspend(struct radeon_device
> *rdev, int state)
> fb_set_suspend(rdev->mode_info.rfbdev->helper.fbdev, state);
> }
>
> -int radeon_fbdev_total_size(struct radeon_device *rdev)
> -{
> - struct radeon_bo *robj;
> - int size = 0;
> -
> - robj = gem_to_radeon_bo(rdev->mode_info.rfbdev->rfb.obj);
> - size += radeon_bo_size(robj);
> - return size;
> -}
> -
> bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo
> *robj)
> {
> if (robj == gem_to_radeon_bo(rdev->mode_info.rfbdev->rfb.obj))
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 04db2fd..ec2014a 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -915,7 +915,6 @@ void dce8_program_fmt(struct drm_encoder *encoder);
> int radeon_fbdev_init(struct radeon_device *rdev);
> void radeon_fbdev_fini(struct radeon_device *rdev);
> void radeon_fbdev_set_suspend(struct radeon_device *rdev, int state);
> -int radeon_fbdev_total_size(struct radeon_device *rdev);
> bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo
> *robj);
>
> void radeon_fb_output_poll_changed(struct radeon_device *rdev);
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/radeon_i2c: Remove unused function
On Tue, Jan 13, 2015 at 2:09 PM, Rickard Strandqvist
wrote:
> Remove the function radeon_best_encoder() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |5 -
> drivers/gpu/drm/radeon/radeon_mode.h |2 --
> 2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
> b/drivers/gpu/drm/radeon/radeon_i2c.c
> index add6220..9590bcd 100644
> --- a/drivers/gpu/drm/radeon/radeon_i2c.c
> +++ b/drivers/gpu/drm/radeon/radeon_i2c.c
> @@ -1048,11 +1048,6 @@ struct radeon_i2c_chan *radeon_i2c_lookup(struct
> radeon_device *rdev,
> return NULL;
> }
>
> -struct drm_encoder *radeon_best_encoder(struct drm_connector *connector)
> -{
> - return NULL;
> -}
> -
> void radeon_i2c_get_byte(struct radeon_i2c_chan *i2c_bus,
> u8 slave_addr,
> u8 addr,
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 04db2fd..66c17e3 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -740,8 +740,6 @@ extern void radeon_router_select_ddc_port(struct
> radeon_connector *radeon_connec
> extern void radeon_router_select_cd_port(struct radeon_connector
> *radeon_connector);
> extern bool radeon_ddc_probe(struct radeon_connector *radeon_connector, bool
> use_aux);
>
> -extern struct drm_encoder *radeon_best_encoder(struct drm_connector
> *connector);
> -
> extern bool radeon_atombios_get_ppll_ss_info(struct radeon_device *rdev,
> struct radeon_atom_ss *ss,
> int id);
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/rv515: Remove unused function
On Tue, Jan 13, 2015 at 1:55 PM, Rickard Strandqvist
wrote:
> Remove the function rv515_ring_start() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_asic.h |1 -
> drivers/gpu/drm/radeon/rv515.c | 68
> --
> 2 files changed, 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index d8ace5b..52667b3 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -280,7 +280,6 @@ int rv515_init(struct radeon_device *rdev);
> void rv515_fini(struct radeon_device *rdev);
> uint32_t rv515_mc_rreg(struct radeon_device *rdev, uint32_t reg);
> void rv515_mc_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring *ring);
> void rv515_bandwidth_update(struct radeon_device *rdev);
> int rv515_resume(struct radeon_device *rdev);
> int rv515_suspend(struct radeon_device *rdev);
> diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
> index 8a477bf..cb966e6 100644
> --- a/drivers/gpu/drm/radeon/rv515.c
> +++ b/drivers/gpu/drm/radeon/rv515.c
> @@ -59,74 +59,6 @@ void rv515_debugfs(struct radeon_device *rdev)
> }
> }
>
> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring *ring)
> -{
> - int r;
> -
> - r = radeon_ring_lock(rdev, ring, 64);
> - if (r) {
> - return;
> - }
> - radeon_ring_write(ring, PACKET0(ISYNC_CNTL, 0));
> - radeon_ring_write(ring,
> - ISYNC_ANY2D_IDLE3D |
> - ISYNC_ANY3D_IDLE2D |
> - ISYNC_WAIT_IDLEGUI |
> - ISYNC_CPSCRATCH_IDLEGUI);
> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
> - radeon_ring_write(ring, PACKET0(R300_DST_PIPE_CONFIG, 0));
> - radeon_ring_write(ring, R300_PIPE_AUTO_CONFIG);
> - radeon_ring_write(ring, PACKET0(GB_SELECT, 0));
> - radeon_ring_write(ring, 0);
> - radeon_ring_write(ring, PACKET0(GB_ENABLE, 0));
> - radeon_ring_write(ring, 0);
> - radeon_ring_write(ring, PACKET0(R500_SU_REG_DEST, 0));
> - radeon_ring_write(ring, (1 << rdev->num_gb_pipes) - 1);
> - radeon_ring_write(ring, PACKET0(VAP_INDEX_OFFSET, 0));
> - radeon_ring_write(ring, 0);
> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
> - radeon_ring_write(ring, PACKET0(GB_AA_CONFIG, 0));
> - radeon_ring_write(ring, 0);
> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
> - radeon_ring_write(ring, PACKET0(GB_MSPOS0, 0));
> - radeon_ring_write(ring,
> - ((6 << MS_X0_SHIFT) |
> - (6 << MS_Y0_SHIFT) |
> - (6 << MS_X1_SHIFT) |
> - (6 << MS_Y1_SHIFT) |
> - (6 << MS_X2_SHIFT) |
> - (6 << MS_Y2_SHIFT) |
> - (6 << MSBD0_Y_SHIFT) |
> - (6 << MSBD0_X_SHIFT)));
> - radeon_ring_write(ring, PACKET0(GB_MSPOS1, 0));
> - radeon_ring_write(ring,
> - ((6 << MS_X3_SHIFT) |
> - (6 << MS_Y3_SHIFT) |
> - (6 << MS_X4_SHIFT) |
> - (6 << MS_Y4_SHIFT) |
> - (6 << MS_X5_SHIFT) |
> - (6 << MS_Y5_SHIFT) |
> - (6 << MSBD1_SHIFT)));
> - radeon_ring_write(ring, PACKET0(GA_ENHANCE, 0));
> - radeon_ring_write(ring, GA_DEADLOCK_CNTL | GA_FASTSYNC_CNTL);
> - radeon_ring_write(ring, PACKET0(GA_POLY_MODE, 0));
> - radeon_ring_write(ring, FRONT_PTYPE_TRIANGE | BACK_PTYPE_TRIANGE);
> - radeon_ring_write(ring, PACKET0(GA_ROUND_MODE, 0));
> - radeon_ring_write(ring, GEOMETRY_ROUND_NEAREST | COLOR_ROUND_NEAREST);
> - radeon_ring_write(ring, PACKET0(0x20C8, 0));
> - radeon_ring_write(ring, 0);
> - radeon_ring_unlock_commit(rdev, ring, false);
> -}
> -
> int rv515_mc_wait_for_idle(struct radeon_device *rdev)
> {
> unsigned i;
> --
> 1.7.10.4
>
[PATCH] gpu: drm: radeon: radeon_object: Remove unused function
On Sun, Jan 11, 2015 at 8:17 AM, Rickard Strandqvist
wrote:
> Remove the function radeon_bo_fbdev_mmap() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_object.c |6 --
> drivers/gpu/drm/radeon/radeon_object.h |2 --
> 2 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 99a960a..4f2515f 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -542,12 +542,6 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
> return 0;
> }
>
> -int radeon_bo_fbdev_mmap(struct radeon_bo *bo,
> -struct vm_area_struct *vma)
> -{
> - return ttm_fbdev_mmap(vma, &bo->tbo);
> -}
> -
> int radeon_bo_get_surface_reg(struct radeon_bo *bo)
> {
> struct radeon_device *rdev = bo->rdev;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 1b8ec79..1cf3cd9 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -143,8 +143,6 @@ extern void radeon_bo_fini(struct radeon_device *rdev);
> extern int radeon_bo_list_validate(struct radeon_device *rdev,
>struct ww_acquire_ctx *ticket,
>struct list_head *head, int ring);
> -extern int radeon_bo_fbdev_mmap(struct radeon_bo *bo,
> - struct vm_area_struct *vma);
> extern int radeon_bo_set_tiling_flags(struct radeon_bo *bo,
> u32 tiling_flags, u32 pitch);
> extern void radeon_bo_get_tiling_flags(struct radeon_bo *bo,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 88408] Black screen in Nuclear Dawn
https://bugs.freedesktop.org/show_bug.cgi?id=88408 --- Comment #1 from Iwo --- I need to correct myself on one thought. On Phoronix.com it's not mentioned by the author that the problem of black screen is present for radeonsi, that is what i've discovered by myself when i was testing nuclear dawn. I've just writed it wrong and it might seems that the radeonsi problem is writen by the author of phoronix.com. Here is a link to his article http://www.phoronix.com/scan.php?page=news_item&px=MTY3MDM -- 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/20150114/193723d3/attachment.html>
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 Alex Deucher changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|DRM/Radeon Version|git |unspecified Product|Mesa|DRI -- 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/20150114/73f75484/attachment.html>
[Bug 88408] Black screen in Nuclear Dawn
https://bugs.freedesktop.org/show_bug.cgi?id=88408 Bug ID: 88408 Summary: Black screen in Nuclear Dawn Product: Mesa Version: 10.4 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: igi31 at wp.pl I am using open source drivers for my AMD Radeon 7850 graphics card for few months now. I've tested many commercial linux games, but nuclear dawn seems to be broken on gallium3d. Main menu of the game is visualised perfectly, but if you are placed in Side Selection after the map has been loaded, there's a black screen. Sound works and the game is definetly running, but all you can see is map and nick's of other persons/bots. The map itself, including weapon, textures and objects are not seen on any level of graphical settings. Please, check it and confirm it that the problem persists on Open Source xf86-video-ati video driver using Mesa3D. I've read article on Phoronix.com that the game is running great under R600 Gallium3D driver and also Catalyst, but on radeonsi driver there is a problem with black screen. I also need to mention that this problem occurs in Wargame: European Escalation game on Steam. But there at least i can play with some of the settings set to minimal like water and shaders. This bug persists at least from mesa 10.2 to present. -- 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/20150114/5937e201/attachment.html>
boot delay with drm_kms_helper.edid_firmware
> >> mode helper, which is no longer supported by udev. > >> > >> Try ensuring you have the path right, and disable FW_LOADER_USER_HELPER > >> kernel config option. > >> > >> HTH, > >> Jani. > >> > >> -- > >> Jani Nikula, Intel Open Source Technology Center > >> > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Jani Nikula, Intel Open Source Technology Center > -- Mit freundlichen GrüÃen Robert W. Kuhn -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/1df41c95/attachment-0001.html>
[PATCH 00/24] radeon audio rework
Am 13.01.2015 um 18:46 schrieb Alex Deucher: > This patch set cleans up the radeon audio handling > and also adds support for DP audio on all supported > asics. Apart from the white space problems and the changes from patch #5 the set is Reviewed-by: Christian König Regards. Christian. > > Alex Deucher (1): >drm/radeon: whitespace clean up in radeon_audio.c > > Slava Grigorev (23): >radeon/audio: consolidate audio_init() functions >radeon/audio: defined initial audio interface that gets initialized > via detect() call >radeon/audio: consolidate write_sad_regs() functions >radeon/audio: consolidate write_speaker_allocation() functions >radeon/audio: consolidate write_latency_fields() functions >radeon/audio: consolidate audio_get_pin() functions >radeon/audio: consolidate select_pin() functions >radeon/audio: consolidate audio_enable() functions >radeon/audio: consolidate audio_fini() functions >radeon/audio: consolidate audio_set_dto() functions >radeon/audio: consolidate update_avi_infoframe() functions >radeon/audio: consolidate update_acr() functions >radeon/audio: moved VBI packet programming to separate functions >radeon: moved HDMI color depth programming to a separate function >radeon/audio: removed unnecessary CRC control programing >radeon/audio: set_avi_packet() function cleanup >radeon/audio: moved audio packet programming to a separate function >radeon/audio: moved mute programming to a separate function >radeon/audio: removed unnecessary debug settings >radeon/audio: consolidate audio_mode_set() functions >radeon/audio: applied audio_dpms() and audio_mode_set() calls >radeon/audio: moved audio caps programming to audio_hotplug() function >radeon/audio: enable DP audio > > drivers/gpu/drm/radeon/Makefile| 2 +- > drivers/gpu/drm/radeon/atombios_encoders.c | 29 +- > drivers/gpu/drm/radeon/cik.c | 5 +- > drivers/gpu/drm/radeon/dce3_1_afmt.c | 264 +- > drivers/gpu/drm/radeon/dce6_afmt.c | 218 > drivers/gpu/drm/radeon/evergreen.c | 7 +- > drivers/gpu/drm/radeon/evergreen_hdmi.c| 478 -- > drivers/gpu/drm/radeon/evergreen_reg.h | 15 + > drivers/gpu/drm/radeon/evergreend.h| 1 + > drivers/gpu/drm/radeon/ni.c| 18 +- > drivers/gpu/drm/radeon/r600.c | 7 +- > drivers/gpu/drm/radeon/r600_hdmi.c | 387 --- > drivers/gpu/drm/radeon/radeon.h| 3 + > drivers/gpu/drm/radeon/radeon_asic.c | 28 -- > drivers/gpu/drm/radeon/radeon_asic.h | 8 - > drivers/gpu/drm/radeon/radeon_audio.c | 765 > + > drivers/gpu/drm/radeon/radeon_audio.h | 84 > drivers/gpu/drm/radeon/radeon_connectors.c | 8 + > drivers/gpu/drm/radeon/radeon_mode.h | 1 + > drivers/gpu/drm/radeon/rs600.c | 7 +- > drivers/gpu/drm/radeon/rs690.c | 7 +- > drivers/gpu/drm/radeon/rv770.c | 5 +- > drivers/gpu/drm/radeon/si.c| 5 +- > drivers/gpu/drm/radeon/sid.h | 10 + > 24 files changed, 1458 insertions(+), 904 deletions(-) > create mode 100644 drivers/gpu/drm/radeon/radeon_audio.c > create mode 100644 drivers/gpu/drm/radeon/radeon_audio.h >
[PATCH 12/24] radeon/audio: consolidate update_acr() functions
Am 13.01.2015 um 18:46 schrieb Alex Deucher:
> From: Slava Grigorev
>
> Signed-off-by: Slava Grigorev
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/dce3_1_afmt.c| 38 +--
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 46 ++---
> drivers/gpu/drm/radeon/r600_hdmi.c | 117
> +---
> drivers/gpu/drm/radeon/radeon_audio.c | 99 +++
> drivers/gpu/drm/radeon/radeon_audio.h | 3 +
> 5 files changed, 176 insertions(+), 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> index 0accc5e..678909f 100644
> --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -167,6 +167,38 @@ void dce3_2_audio_set_dto(struct radeon_device *rdev,
> }
> }
>
> +void dce3_2_hdmi_update_acr(struct drm_encoder *encoder, long offset,
> +const struct radeon_hdmi_acr *acr)
> +{
> +struct drm_device *dev = encoder->dev;
> +struct radeon_device *rdev = dev->dev_private;
> +
> + WREG32(HDMI0_ACR_PACKET_CONTROL + offset,
> +HDMI0_ACR_SOURCE | /* select SW CTS value */
> +HDMI0_ACR_AUTO_SEND);/* allow hw to sent ACR packets when
> required */
> +
> +WREG32_P(HDMI0_ACR_32_0 + offset,
> + HDMI0_ACR_CTS_32(acr->cts_32khz),
> + ~HDMI0_ACR_CTS_32_MASK);
> +WREG32_P(HDMI0_ACR_32_1 + offset,
> + HDMI0_ACR_N_32(acr->n_32khz),
> + ~HDMI0_ACR_N_32_MASK);
> +
> +WREG32_P(HDMI0_ACR_44_0 + offset,
> + HDMI0_ACR_CTS_44(acr->cts_44_1khz),
> + ~HDMI0_ACR_CTS_44_MASK);
> +WREG32_P(HDMI0_ACR_44_1 + offset,
> + HDMI0_ACR_N_44(acr->n_44_1khz),
> + ~HDMI0_ACR_N_44_MASK);
> +
> +WREG32_P(HDMI0_ACR_48_0 + offset,
> + HDMI0_ACR_CTS_48(acr->cts_48khz),
> + ~HDMI0_ACR_CTS_48_MASK);
> +WREG32_P(HDMI0_ACR_48_1 + offset,
> + HDMI0_ACR_N_48(acr->n_48khz),
> + ~HDMI0_ACR_N_48_MASK);
Looks like spaces were used for indentation instead of tabs.
Christian.
> +}
> +
> /*
>* update the info frames with the data from the current display mode
>*/
> @@ -220,10 +252,6 @@ void dce3_1_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode *m
> radeon_audio_write_sad_regs(encoder);
> }
>
> - WREG32(HDMI0_ACR_PACKET_CONTROL + offset,
> -HDMI0_ACR_SOURCE | /* select SW CTS value - XXX verify that hw
> CTS works on all families */
> -HDMI0_ACR_AUTO_SEND); /* allow hw to sent ACR packets when
> required */
> -
> WREG32(HDMI0_VBI_PACKET_CONTROL + offset,
> HDMI0_NULL_SEND | /* send null packets when required */
> HDMI0_GC_SEND | /* send general control packets */
> @@ -255,7 +283,7 @@ void dce3_1_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode *m
> }
>
> radeon_update_avi_infoframe(encoder, buffer, sizeof(buffer));
> - r600_hdmi_update_ACR(encoder, mode->clock);
> + radeon_audio_update_acr(encoder, mode->clock);
>
> /* it's unknown what these bits do excatly, but it's indeed quite
> useful for debugging */
> WREG32(HDMI0_RAMP_CONTROL0 + offset, 0x00FF);
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index f2896e5..c2abab4 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -64,26 +64,34 @@ void dce4_audio_enable(struct radeon_device *rdev,
> WREG32(AZ_HOT_PLUG_CONTROL, tmp);
> }
>
> -/*
> - * update the N and CTS parameters for a given pixel clock rate
> - */
> -static void evergreen_hdmi_update_ACR(struct drm_encoder *encoder, uint32_t
> clock)
> +void evergreen_hdmi_update_acr(struct drm_encoder *encoder, long offset,
> + const struct radeon_hdmi_acr *acr)
> {
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> - struct radeon_hdmi_acr acr = r600_hdmi_acr(clock);
> - struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> - struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> - uint32_t offset = dig->afmt->offset;
> + int bpc = 8;
> +
> + if (encoder->crtc) {
> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> + bpc = radeon_crtc->bpc;
> + }
> +
> + if (bpc > 8)
> + WREG32(HDMI_ACR_PACKET_CONTROL + offset,
> +HDMI_ACR_AUTO_SEND); /* allow hw to sent ACR packets
> when required */
> + else
> + WREG32(HDMI_ACR_PACKET_CONTROL + offset,
> +HDMI_ACR_SOURCE | /* select SW CTS value */
> +HDMI_ACR_AUTO_SEND); /* allow hw to sent ACR packets
> when required */
>
> - WREG32(HDMI_ACR_32_0 + offset, HDMI_ACR_CTS_32(acr.cts_32khz));
> - WREG32(HDMI_ACR_32_1 + offs
[PATCH 05/24] radeon/audio: consolidate write_latency_fields() functions
Am 13.01.2015 um 18:46 schrieb Alex Deucher:
> From: Slava Grigorev
>
> Signed-off-by: Slava Grigorev
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/dce6_afmt.c | 16 +
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 33 --
> drivers/gpu/drm/radeon/radeon_audio.c | 62
> +
> drivers/gpu/drm/radeon/radeon_audio.h | 4 +++
> 4 files changed, 51 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> index a24c95a..96f298c 100644
> --- a/drivers/gpu/drm/radeon/dce6_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
> @@ -102,13 +102,11 @@ void dce6_afmt_select_pin(struct drm_encoder *encoder)
> }
>
> void dce6_afmt_write_latency_fields(struct drm_encoder *encoder,
> - struct drm_display_mode *mode)
> + struct drm_connector *connector, struct drm_display_mode *mode)
> {
> struct radeon_device *rdev = encoder->dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> - struct drm_connector *connector;
> - struct radeon_connector *radeon_connector = NULL;
> u32 tmp = 0, offset;
>
> if (!dig || !dig->afmt || !dig->afmt->pin)
> @@ -116,18 +114,6 @@ void dce6_afmt_write_latency_fields(struct drm_encoder
> *encoder,
>
> offset = dig->afmt->pin->offset;
>
> - list_for_each_entry(connector,
> &encoder->dev->mode_config.connector_list, head) {
> - if (connector->encoder == encoder) {
> - radeon_connector = to_radeon_connector(connector);
> - break;
> - }
> - }
> -
> - if (!radeon_connector) {
> - DRM_ERROR("Couldn't find encoder's connector\n");
> - return;
> - }
> -
> if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> if (connector->latency_present[1])
> tmp = VIDEO_LIPSYNC(connector->video_latency[1]) |
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 3a9bb04..aa8a31b 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -34,8 +34,6 @@
> #include "atom.h"
>
> extern void dce6_afmt_select_pin(struct drm_encoder *encoder);
> -extern void dce6_afmt_write_latency_fields(struct drm_encoder *encoder,
> -struct drm_display_mode *mode);
>
> /* enable the audio stream */
> static void dce4_audio_enable(struct radeon_device *rdev,
> @@ -90,26 +88,12 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder
> *encoder, uint32_t cloc
> WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
> }
>
> -static void dce4_afmt_write_latency_fields(struct drm_encoder *encoder,
> -struct drm_display_mode *mode)
> +void dce4_afmt_write_latency_fields(struct drm_encoder *encoder,
> + struct drm_connector *connector, struct drm_display_mode *mode)
> {
> struct radeon_device *rdev = encoder->dev->dev_private;
> - struct drm_connector *connector;
> - struct radeon_connector *radeon_connector = NULL;
> u32 tmp = 0;
>
> - list_for_each_entry(connector,
> &encoder->dev->mode_config.connector_list, head) {
> - if (connector->encoder == encoder) {
> - radeon_connector = to_radeon_connector(connector);
> - break;
> - }
> - }
> -
> - if (!radeon_connector) {
> - DRM_ERROR("Couldn't find encoder's connector\n");
> - return;
> - }
> -
> if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> if (connector->latency_present[1])
> tmp = VIDEO_LIPSYNC(connector->video_latency[1]) |
> @@ -123,7 +107,7 @@ static void dce4_afmt_write_latency_fields(struct
> drm_encoder *encoder,
> else
> tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255);
> }
> - WREG32(AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp);
> + WREG32_ENDPOINT(0, AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp);
> }
>
> void dce4_afmt_hdmi_write_speaker_allocation(struct drm_encoder *encoder,
> @@ -418,14 +402,11 @@ void evergreen_hdmi_setmode(struct drm_encoder
> *encoder, struct drm_display_mode
>
> /* fglrx sets 0x40 in 0x5f80 here */
>
> - if (ASIC_IS_DCE6(rdev)) {
> + if (ASIC_IS_DCE6(rdev))
> dce6_afmt_select_pin(encoder);
> - radeon_audio_write_sad_regs(encoder);
> - dce6_afmt_write_latency_fields(encoder, mode);
> - } else {
> - radeon_audio_write_sad_regs(encoder);
> - dce4_afmt_write_latency_fields(encoder, mode);
> - }
> +
> + radeon_audio_write_sad_regs(encoder);
> +
boot delay with drm_kms_helper.edid_firmware
On Wed, 14 Jan 2015, Robert Kuhn wrote:
> Hi,
>
> thanks for the answer. This is my kernel config:
>
> developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep
> FW_LOADER_USER_HELPER .config
Ah, you wouldn't have that since it's been added in v3.9.
> developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep DRM
> .config
> CONFIG_DRM=y
> CONFIG_DRM_KMS_HELPER=y
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> CONFIG_DRM_GEM_CMA_HELPER=y
> CONFIG_DRM_KMS_CMA_HELPER=y
> # CONFIG_DRM_I2C_CH7006 is not set
> # CONFIG_DRM_I2C_SIL164 is not set
> CONFIG_DRM_I2C_NXP_TDA998X=y
> # CONFIG_DRM_UDL is not set
> CONFIG_DRM_TILCDC=y
> # CONFIG_DRM_OMAP is not set
>
>
> I am quite sure that in the end kernel finds firmware because otherwise the
> display isn't working. I only get a image on the display if my edid file is
> used.
Okay, got it:
[ 62.751321] [drm] Got built-in EDID base block and 0 extensions from
"edid/1024x768.bin" for connector "HDMI-A-1"
the "built-in" here tells us the the EDID is embedded in the
drm_kms_helper module (drivers/gpu/drm/drm_edid_load.c). But first the
v3.8 kernel attempts to load the EDID from the filesystem, and fails,
then delegates to the (now deprecated) user mode helper, which fails
after a timeout. This is the delay you see. (See abb139e75c2c firmware:
teach the kernel to load firmware files directly from the filesystem.)
Starting from v3.13 the EDID firmware loader tries the built-in ones
first, bypassing the regular firmware loader completely if one is
found. (See 9066f83c055e drm: Try loading builtin EDIDs first.)
Your options are upgrading to at least v3.13 (but hey, why not go all
the way to v3.18 or later while at it?! ;) or making sure you have the
EDID firmware in the filesystem so that the kernel can load it
directly. The path is a concatenation of one of the below (from
drivers/base/firmware_class.c; fw_path_para comes from
firmware_class.path module parameter) and the firmware name, i.e.
drm_kms_helper.edid_firmware in this case:
static const char * const fw_path[] = {
fw_path_para,
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
"/lib/firmware"
};
Just put your edid to, say, /lib/firmware/path/to/edid and add module
parameter drm_kms_helper.edid_firmware=path/to/edid.
And thus concludes today's lesson in Linux archeology. Thank you for
your attention. ;)
BR,
Jani.
>
> Robert
>
>
> 2015-01-14 11:40 GMT+01:00 Jani Nikula :
>
>> On Wed, 14 Jan 2015, Robert Kuhn wrote:
>> > using drm_kms_helper.edid_firmware the boot time is much longer (~1min)
>> > than without it. I attach the boot log ("drm.debug=0x06"), one time
>> > with drm_kms_helper.edid_firmware, one time without.
>> >
>> > What could be the problem?
>> >
>> > I am using Kernel 3.8.13-bone69 on a Beaglebone black. I
>> > used drm_kms_helper.edid_firmware before and never saw this issue.
>>
>> Just a guess, kernel doesn't find the firmware and you fallback to user
>> mode helper, which is no longer supported by udev.
>>
>> Try ensuring you have the path right, and disable FW_LOADER_USER_HELPER
>> kernel config option.
>>
>> HTH,
>> Jani.
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/exynos: fix warning of vblank reference count
Prevented re-enabling the vblank interrupt by drm_vblank_off and
drm_vblank_get from mixer_wait_for_vblank returns error after
drm_vblank_off. We get below warnings without this error handling
because vblank reference count is mismatched by above sequence.
setting mode 1920x1080-60Hz at XR24 on connectors 16, crtc 13
[ 19.900793] [ cut here ]
[ 19.903959] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072
exynos_drm_crtc_finish_pageflip+0xac/0xdc()
[ 19.914076] Modules linked in:
[ 19.917116] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.19.0-rc4-00040-g3d729789-dirty #46
[ 19.925342] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 19.931437] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 19.939131] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[ 19.946329] [] (dump_stack) from []
(warn_slowpath_common+0x80/0xb0)
[ 19.954382] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 19.963132] [] (warn_slowpath_null) from []
(exynos_drm_crtc_finish_pageflip+0xac/0xdc)
[ 19.972841] [] (exynos_drm_crtc_finish_pageflip) from []
(mixer_irq_handler+0xdc/0x104)
[ 19.982546] [] (mixer_irq_handler) from []
(handle_irq_event_percpu+0x78/0x134)
[ 19.991555] [] (handle_irq_event_percpu) from []
(handle_irq_event+0x3c/0x5c)
[ 20.000395] [] (handle_irq_event) from []
(handle_fasteoi_irq+0xe0/0x1ac)
[ 20.008885] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x2c/0x3c)
[ 20.017463] [] (generic_handle_irq) from []
(__handle_domain_irq+0x7c/0xec)
[ 20.026128] [] (__handle_domain_irq) from []
(gic_handle_irq+0x30/0x68)
[ 20.034449] [] (gic_handle_irq) from []
(__irq_svc+0x40/0x74)
[ 20.041893] Exception stack(0xc06fff68 to 0xc06fffb0)
[ 20.046923] ff60: 52f6 c001b460
c06fe000 c07064e8
[ 20.055070] ff80: c04d743c c07392a2 c0739440 c06da340 ef7fca80
0100 c06fffb0
[ 20.063212] ffa0: c000f24c c000f250 6013
[ 20.068245] [] (__irq_svc) from []
(arch_cpu_idle+0x38/0x3c)
[ 20.075611] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x108/0x16c)
[ 20.083846] [] (cpu_startup_entry) from []
(start_kernel+0x3a0/0x3ac)
[ 20.091980] ---[ end trace 2c76ee0500489d1b ]---
Signed-off-by: Joonyoung Shim
---
It can be any root solution than this patch. Actually i'm not sure
whether it's right to call drm_vblank_get/put from mixer_wait_for_vblank
or to call mixer_wait_for_vblank from mixer_window_suspend.
drivers/gpu/drm/exynos/exynos_mixer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0dedb99..ed44cd4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1018,6 +1018,7 @@ static void mixer_win_disable(struct exynos_drm_crtc
*crtc, int zpos)
static void mixer_wait_for_vblank(struct exynos_drm_crtc *crtc)
{
struct mixer_context *mixer_ctx = crtc->ctx;
+ int err;
mutex_lock(&mixer_ctx->mixer_mutex);
if (!mixer_ctx->powered) {
@@ -1026,7 +1027,11 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc
*crtc)
}
mutex_unlock(&mixer_ctx->mixer_mutex);
- drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
+ err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
+ if (err < 0) {
+ DRM_DEBUG_KMS("failed to acquire vblank counter\n");
+ return;
+ }
atomic_set(&mixer_ctx->wait_vsync_event, 1);
--
1.9.1
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 --- Comment #14 from Clésio Luiz --- I tested now with 2 displays, the Benq monitor (DVI cable) at 120Hz and a Lg TV (HDMI cable) and the glitches disappear. When I disable the TV (from System Settings) and disconnect the cable, the glitches are still gone. Only when I restart the system the glitches come back. I should mention that any refresh rate above 60Hz triggers the problem, not only 120Hz. -- 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/20150114/4980798d/attachment.html>
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Wed, Jan 14, 2015 at 12:50:56PM +, Mark Brown wrote: > Trying to hook up a controller that doesn't natively support this format > to a device that uses it is definitely tricky, as well as describing the > physical hookup we also need to worry about how things look to userspace > - it's ideally going to want a single multi-channel audio stream. Trying to get the synchronisation correct for proper surround audio reproduction would also be interesting. I suspect that userspace would have to be taught specifically about a hardware setup like this - in order to ensure that the slave I2S blocks are ready before the master starts outputting the I2S clocks. I'm /not/ that thrilled with the whole idea; I'd much rather suggest that we should concentrate on sane setups, but we know that hardware engineers do create some silly setups "because they can". > I think from a binding point of view we need a way to say "this endpoint > on the link is constructed from these DAIs on the device side" and say > if this is TDM or multi-data, and what's driving the clocks. This seems to favour the "one DT port for I2S" model - possibly with multiple endpoints for each I2S channel (if desired). There's nothing in that model which would prevent having one end point for all four channels. To put that another way, we can remain flexible. Maybe we should document the binding indicating that for I2S, one port and one endpoint connected to one I2S block which supplies all I2S channels is the preferred model, but others are permitted but not necessarily guaranteed to work correctly. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[PATCH libdrm 2/2] Add new drmOpenRender function
Add a new function, drmOpenRender, that can be used to open render nodes. This
can be used in the same way that drmOpenControl is used to open control nodes.
Signed-off-by: Frank Binns
---
xf86drm.c | 40 ++--
xf86drm.h | 2 ++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index a23d029..345325a 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -87,6 +87,7 @@
#define DRM_NODE_CONTROL 0
#define DRM_NODE_PRIMARY 1
+#define DRM_NODE_RENDER 2
static drmServerInfoPtr drm_server_info;
@@ -305,6 +306,7 @@ static int chown_check_return(const char *path, uid_t
owner, gid_t group)
static int drmOpenDevice(long dev, int minor, int type)
{
stat_t st;
+const char *dev_name;
charbuf[64];
int fd;
mode_t devmode = DRM_DEV_MODE, serv_mode;
@@ -312,7 +314,21 @@ static int drmOpenDevice(long dev, int minor, int type)
uid_t user= DRM_DEV_UID;
gid_t group = DRM_DEV_GID, serv_group;
-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
minor);
+switch (type) {
+case DRM_NODE_PRIMARY:
+ dev_name = DRM_DEV_NAME;
+ break;
+case DRM_NODE_CONTROL:
+ dev_name = DRM_CONTROL_DEV_NAME;
+ break;
+case DRM_NODE_RENDER:
+ dev_name = DRM_RENDER_DEV_NAME;
+ break;
+default:
+ return -EINVAL;
+};
+
+sprintf(buf, dev_name, DRM_DIR_NAME, minor);
drmMsg("drmOpenDevice: node name is %s\n", buf);
if (drm_server_info) {
@@ -417,11 +433,26 @@ static int drmOpenMinor(int minor, int create, int type)
{
int fd;
char buf[64];
+const char *dev_name;
if (create)
return drmOpenDevice(makedev(DRM_MAJOR, minor), minor, type);
-sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
minor);
+switch (type) {
+case DRM_NODE_PRIMARY:
+ dev_name = DRM_DEV_NAME;
+ break;
+case DRM_NODE_CONTROL:
+ dev_name = DRM_CONTROL_DEV_NAME;
+ break;
+case DRM_NODE_RENDER:
+ dev_name = DRM_RENDER_DEV_NAME;
+ break;
+default:
+ return -EINVAL;
+};
+
+sprintf(buf, dev_name, DRM_DIR_NAME, minor);
if ((fd = open(buf, O_RDWR, 0)) >= 0)
return fd;
return -errno;
@@ -646,6 +677,11 @@ int drmOpenControl(int minor)
return drmOpenMinor(minor, 0, DRM_NODE_CONTROL);
}
+int drmOpenRender(int minor)
+{
+return drmOpenMinor(minor, 0, DRM_NODE_RENDER);
+}
+
/**
* Free the version information returned by drmGetVersion().
*
diff --git a/xf86drm.h b/xf86drm.h
index c024cc4..bfd0670 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -79,6 +79,7 @@ extern "C" {
#define DRM_DIR_NAME "/dev/dri"
#define DRM_DEV_NAME "%s/card%d"
#define DRM_CONTROL_DEV_NAME "%s/controlD%d"
+#define DRM_RENDER_DEV_NAME "%s/renderD%d"
#define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
#define DRM_ERR_NO_DEVICE (-1001)
@@ -552,6 +553,7 @@ do {register unsigned int __old __asm("o0");
\
extern int drmAvailable(void);
extern int drmOpen(const char *name, const char *busid);
extern int drmOpenControl(int minor);
+extern int drmOpenRender(int minor);
extern int drmClose(int fd);
extern drmVersionPtr drmGetVersion(int fd);
extern drmVersionPtr drmGetLibVersion(int fd);
--
1.8.5.4.gfd2
[PATCH libdrm 1/2] Rename DRM_NODE_RENDER to DRM_NODE_PRIMARY
Now that there are render nodes it doesn't seem appropriate for the type of
the card nodes to be DRM_NODE_RENDER. For this reason, rename this type to
DRM_NODE_PRIMARY as this name better represents the purpose of these nodes.
Signed-off-by: Frank Binns
---
tests/dristat.c | 2 +-
xf86drm.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/dristat.c b/tests/dristat.c
index 4f2ee80..449aa24 100644
--- a/tests/dristat.c
+++ b/tests/dristat.c
@@ -268,7 +268,7 @@ int main(int argc, char **argv)
for (i = 0; i < 16; i++) if (!minor || i == minor) {
sprintf(buf, DRM_DEV_NAME, DRM_DIR_NAME, i);
- fd = drmOpenMinor(i, 1, DRM_NODE_RENDER);
+ fd = drmOpenMinor(i, 1, DRM_NODE_PRIMARY);
if (fd >= 0) {
printf("%s\n", buf);
if (mask & DRM_BUSID) getbusid(fd);
diff --git a/xf86drm.c b/xf86drm.c
index d900b4b..a23d029 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -86,7 +86,7 @@
#define DRM_MSG_VERBOSITY 3
#define DRM_NODE_CONTROL 0
-#define DRM_NODE_RENDER 1
+#define DRM_NODE_PRIMARY 1
static drmServerInfoPtr drm_server_info;
@@ -444,7 +444,7 @@ int drmAvailable(void)
int retval = 0;
int fd;
-if ((fd = drmOpenMinor(0, 1, DRM_NODE_RENDER)) < 0) {
+if ((fd = drmOpenMinor(0, 1, DRM_NODE_PRIMARY)) < 0) {
#ifdef __linux__
/* Try proc for backward Linux compatibility */
if (!access("/proc/dri/0", R_OK))
@@ -485,7 +485,7 @@ static int drmOpenByBusid(const char *busid)
drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
for (i = 0; i < DRM_MAX_MINOR; i++) {
- fd = drmOpenMinor(i, 1, DRM_NODE_RENDER);
+ fd = drmOpenMinor(i, 1, DRM_NODE_PRIMARY);
drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
if (fd >= 0) {
/* We need to try for 1.4 first for proper PCI domain support
@@ -547,7 +547,7 @@ static int drmOpenByName(const char *name)
* already in use. If it's in use it will have a busid assigned already.
*/
for (i = 0; i < DRM_MAX_MINOR; i++) {
- if ((fd = drmOpenMinor(i, 1, DRM_NODE_RENDER)) >= 0) {
+ if ((fd = drmOpenMinor(i, 1, DRM_NODE_PRIMARY)) >= 0) {
if ((version = drmGetVersion(fd))) {
if (!strcmp(version->name, name)) {
drmFreeVersion(version);
@@ -591,7 +591,7 @@ static int drmOpenByName(const char *name)
if (*pt) { /* Found busid */
return drmOpenByBusid(++pt);
} else { /* No busid */
- return drmOpenDevice(strtol(devstring, NULL, 0),i,
DRM_NODE_RENDER);
+ return drmOpenDevice(strtol(devstring, NULL, 0),i,
DRM_NODE_PRIMARY);
}
}
}
--
1.8.5.4.gfd2
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
I think I am confused here..
Since sprite plane handles this scaling and rotation in kernel, I thought it
should be taken care in driver for primary as well.
>From the test, I don't really change the src sizes for primary as well as
>sprite to take care of 90/270 rotation.
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, January 14, 2015 5:14 PM
To: Jindal, Sonika
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote:
> Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h.
> Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser than
> the min_hscale (which is no_scaling by default), so it returns -ERANGE.
If you want no scaling then with 90/270 rotation then your src->w should be
equal to dst->h. Then the calculated vscale will be 1.0. If it's not, then your
test is passing in bad coordinates.
> So, I think we _relaxed is the function which should be called to update the
> destination size appropriately.
> Please correct me if I am wrong.
>
> -Original Message-
> From: Jindal, Sonika
> Sent: Wednesday, January 14, 2015 3:06 PM
> To: 'Ville Syrjälä'
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
> drm_plane_helper_check_update
>
> We do exactly like this for sprite plane (ie, rotate the rect, then check
> scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed)
> That's why I saw the need of this for primary plane as well.
> For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments
> and the rotated sizes are fine. But since we don't do any of those stuff for
> primary the destination size doesn't come right, and I get a little corrupted
> output after rotation.
> With this change, the rotated plane is properly adjusted in the viewport.
> So, I don't think it is a bug in test.
>
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Wednesday, January 14, 2015 2:58 PM
> To: Jindal, Sonika
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
> drm_plane_helper_check_update
>
> On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
> >
> > On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> > >> Taking rotation into account while checking the plane and
> > >> adjusting the sizes accordingly.
> > >>
> > >> Signed-off-by: Sonika Jindal
> > >> ---
> > >> drivers/gpu/drm/drm_plane_helper.c | 79
> > >> ++--
> > >> include/drm/drm_plane_helper.h |3 +-
> > >> 2 files changed, 77 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> > >> b/drivers/gpu/drm/drm_plane_helper.c
> > >> index f24c4cf..4badd69 100644
> > >> --- a/drivers/gpu/drm/drm_plane_helper.c
> > >> +++ b/drivers/gpu/drm/drm_plane_helper.c
> > >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
> > >> *plane,
> > >> int max_scale,
> > >> bool can_position,
> > >> bool can_update_disabled,
> > >> -bool *visible)
> > >> +bool *visible,
> > >> +unsigned int rotation)
> > >> {
> > >> int hscale, vscale;
> > >> +int crtc_x, crtc_y;
> > >> +unsigned int crtc_w, crtc_h;
> > >> +uint32_t src_x, src_y, src_w, src_h;
> > >>
> > >> if (!fb) {
> > >> *visible = false;
> > >> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
> > >> *plane,
> > >> return -EINVAL;
> > >> }
> > >>
> > >> +if (fb)
> > >> +drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> > >> +rotation);
> > >> +
> > >> /* Check scaling */
> > >> -hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> > >> -vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> > >> +hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale,
> > >> max_scale);
> > >> +vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale,
> > >> +max_scale);
> > > This is an unrelated change. Relaxed scaling allows the the
> > > src/dest rectangles to be reduced in size in order to keep the
> > > scaling ration within the min/max range. I suppose we should
> > > switch to using it to make the behaviour uniform across driv
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote:
> Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h.
> Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser than
> the min_hscale (which is no_scaling by default), so it returns -ERANGE.
If you want no scaling then with 90/270 rotation then your src->w should
be equal to dst->h. Then the calculated vscale will be 1.0. If it's not,
then your test is passing in bad coordinates.
> So, I think we _relaxed is the function which should be called to update the
> destination size appropriately.
> Please correct me if I am wrong.
>
> -Original Message-
> From: Jindal, Sonika
> Sent: Wednesday, January 14, 2015 3:06 PM
> To: 'Ville Syrjälä'
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
> drm_plane_helper_check_update
>
> We do exactly like this for sprite plane (ie, rotate the rect, then check
> scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed)
> That's why I saw the need of this for primary plane as well.
> For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments
> and the rotated sizes are fine. But since we don't do any of those stuff for
> primary the destination size doesn't come right, and I get a little corrupted
> output after rotation.
> With this change, the rotated plane is properly adjusted in the viewport.
> So, I don't think it is a bug in test.
>
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Wednesday, January 14, 2015 2:58 PM
> To: Jindal, Sonika
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
> drm_plane_helper_check_update
>
> On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
> >
> > On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> > >> Taking rotation into account while checking the plane and adjusting
> > >> the sizes accordingly.
> > >>
> > >> Signed-off-by: Sonika Jindal
> > >> ---
> > >> drivers/gpu/drm/drm_plane_helper.c | 79
> > >> ++--
> > >> include/drm/drm_plane_helper.h |3 +-
> > >> 2 files changed, 77 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> > >> b/drivers/gpu/drm/drm_plane_helper.c
> > >> index f24c4cf..4badd69 100644
> > >> --- a/drivers/gpu/drm/drm_plane_helper.c
> > >> +++ b/drivers/gpu/drm/drm_plane_helper.c
> > >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
> > >> *plane,
> > >> int max_scale,
> > >> bool can_position,
> > >> bool can_update_disabled,
> > >> -bool *visible)
> > >> +bool *visible,
> > >> +unsigned int rotation)
> > >> {
> > >> int hscale, vscale;
> > >> +int crtc_x, crtc_y;
> > >> +unsigned int crtc_w, crtc_h;
> > >> +uint32_t src_x, src_y, src_w, src_h;
> > >>
> > >> if (!fb) {
> > >> *visible = false;
> > >> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
> > >> *plane,
> > >> return -EINVAL;
> > >> }
> > >>
> > >> +if (fb)
> > >> +drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> > >> +rotation);
> > >> +
> > >> /* Check scaling */
> > >> -hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> > >> -vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> > >> +hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale,
> > >> max_scale);
> > >> +vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale,
> > >> +max_scale);
> > > This is an unrelated change. Relaxed scaling allows the the src/dest
> > > rectangles to be reduced in size in order to keep the scaling ration
> > > within the min/max range. I suppose we should switch to using it to
> > > make the behaviour uniform across drivers, but definitely should be
> > > done with a separate patch.
> > Since, I added drm_rect_rotate before this, it changes the src sizes
> > and it was giving me Invalid scaling if we don't let the sizes to be
> > changed using _relaxed functions. I am trying this for 90/270
> > rotation.
>
> That would indicate a bug somewhere. Pontetially the bug could be in whatever
> test you're using as well.
>
> > I can move it to a separate patch if required.
>
> We nee to figure out why you got the error first.
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
Softlockup on boot with Cape Verde XT on many kernels
On 14.01.2015 12:41, Federico wrote: > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and > I got a different stack trace. Shorter. It repeats itself every about 30 > seconds more or less. Keyboard lights don't flash. The same message > keeps coming out. > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png That's again missing some of the information, but it doesn't look directly related to the radeon driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Wed, Jan 14, 2015 at 11:46:58AM +0100, Philipp Zabel wrote: > So the question is mostly whether four I2S data pins with a single > shared WS/SCK input should be called "four I2S ports with shared clocks" > or "one I2S port with up to four data lanes". I'd lean towards the > latter. Yes, this is what we're doing for the Samsung CPU side controllers which implement this natively and seems to make sense here too - the different channels can't really work as separate interfaces in any practical way. > How audio2_i2s is forced to synchronize its clock output to audio1_i2s > is a problem their bindings will have to handle. Trying to hook up a controller that doesn't natively support this format to a device that uses it is definitely tricky, as well as describing the physical hookup we also need to worry about how things look to userspace - it's ideally going to want a single multi-channel audio stream. I think from a binding point of view we need a way to say "this endpoint on the link is constructed from these DAIs on the device side" and say if this is TDM or multi-data, and what's driving the clocks. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/c3dbce6d/attachment.sig>
boot delay with drm_kms_helper.edid_firmware
Hi,
thanks for the answer. This is my kernel config:
developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep
FW_LOADER_USER_HELPER .config
developer at ubuntu:~/beaglebone/debian-fw/bb-kernel/KERNEL$ grep DRM
.config
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
CONFIG_DRM_I2C_NXP_TDA998X=y
# CONFIG_DRM_UDL is not set
CONFIG_DRM_TILCDC=y
# CONFIG_DRM_OMAP is not set
I am quite sure that in the end kernel finds firmware because otherwise the
display isn't working. I only get a image on the display if my edid file is
used.
Robert
2015-01-14 11:40 GMT+01:00 Jani Nikula :
> On Wed, 14 Jan 2015, Robert Kuhn wrote:
> > using drm_kms_helper.edid_firmware the boot time is much longer (~1min)
> > than without it. I attach the boot log ("drm.debug=0x06"), one time
> > with drm_kms_helper.edid_firmware, one time without.
> >
> > What could be the problem?
> >
> > I am using Kernel 3.8.13-bone69 on a Beaglebone black. I
> > used drm_kms_helper.edid_firmware before and never saw this issue.
>
> Just a guess, kernel doesn't find the firmware and you fallback to user
> mode helper, which is no longer supported by udev.
>
> Try ensuring you have the path right, and disable FW_LOADER_USER_HELPER
> kernel config option.
>
> HTH,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
>
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/852526d3/attachment.html>
boot delay with drm_kms_helper.edid_firmware
On Wed, 14 Jan 2015, Robert Kuhn wrote:
> using drm_kms_helper.edid_firmware the boot time is much longer (~1min)
> than without it. I attach the boot log ("drm.debug=0x06"), one time
> with drm_kms_helper.edid_firmware, one time without.
>
> What could be the problem?
>
> I am using Kernel 3.8.13-bone69 on a Beaglebone black. I
> used drm_kms_helper.edid_firmware before and never saw this issue.
Just a guess, kernel doesn't find the firmware and you fallback to user
mode helper, which is no longer supported by udev.
Try ensuring you have the path right, and disable FW_LOADER_USER_HELPER
kernel config option.
HTH,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Wed, Jan 14, 2015 at 08:55:01AM +0100, Jean-Francois Moine wrote:
> On Tue, 13 Jan 2015 19:54:15 +
> Russell King - ARM Linux wrote:
>
> > On Tue, Jan 13, 2015 at 09:41:01PM +0200, Jyri Sarha wrote:
> > > On 01/13/2015 09:26 PM, Russell King - ARM Linux wrote:
> > > >SCLK: _~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_
> > > > WS:
> > > > __~
> > > >I2S1: llmmllmmllm
> > > >I2S2: llmmllmmllm
> > > >I2S3: llmmllmmllm
> > > >I2S4: llmmllmmllm
> > > >
> > > >So, what I'm saying is that it is_impossible_ to drive the TDA998x using
> > > >multiple I2S streams which are not produced by the same I2S block.
> > >
> > > This is besides the point, but it is possible that one of the multiple I2S
> > > blocks is the bit-clock and frame-clock master to the i2s bus and the
> > > others
> > > are slaves to it (banging their bits according to SCLK and WS of the I2S
> > > master). However, in this situation there really is only one i2s bus with
> > > multiple data pins.
> > >
> > > Just my 0.02⬠to this discussion.
> >
> > Right, that's about the only way it could work.
> >
> > To represent that in DT, I would imagine we'd need something like this:
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> > ...
> > port at 1 {/* AP1,2 = I2S */
> > #address-cells = <1>;
> > #size-cells = <0>;
> > port-type = "i2s";
> > reg = <0x01>; /* WS */
> > tda998x_i2s1: endpoint at 2 {
> > reg = <0x02>; /* AP1 */
> > remote-endpoint = <&audio1_i2s>;
> > };
> > tda998x_i2s2: endpoint at 4 {
> > reg = <0x04>; /* AP2 */
> > remote-endpoint = <&audio2_i2s>;
> > };
> > };
> >
> > where audio1_i2s is operating in master mode, and audio2_i2s is
> > operating in slave mode for both WS and SCLK.
> >
> > If we can agree on that, then I'm happy with the proposed binding.
> > (Remember that #address-cells and #size-cells are required in the
> > parent where we have reg= in the child.)
>
> #address-cells and #size-cells may be defined in any of the upper
> parent, so, as it is defined in the device, it is not needed in the
> port (see of_n_addr_cells in drivers/of/base.c).
That may be, but the documentation specifies that it should be given.
See Documentation/devicetree/bindings/graph.txt - maybe the docs need
fixing?
> Well, I am a bit lost between (only one source / many channels - I2S
> busses) and (many sources / one I2s bus!).
I think that's a matter of how the problem is viewed. :)
> Anyway, I don't understand your example.
> I'd expect that a port would be a DAI.
I view a DAI as a Linux abstraction, which doesn't really have any place
in DT. I'm looking at this problem from the electronics point of view.
> If yes, when playing is active, both endpoints receive an audio stream
> from the remote audio devices, and the AP register is always set to
> 0x07 (= 0x01 | 0x02 | 0x04).
> Then, it would have been simpler to have:
>
> #address-cells = <1>;
> #size-cells = <0>;
> ...
> port at 7 {/* AP1,2 = I2S */
> port-type = "i2s";
> reg = <0x07>;/* WS + AP1 + AP2 */
> tda998x_i2s1: endpoint at 1 {
> remote-endpoint = <&audio1_i2s>;
> };
> tda998x_i2s2: endpoint at 2 {
> remote-endpoint = <&audio2_i2s>;
> };
> };
>
> If no, the two DAIs must be created from the endpoints, permitting
> streaming on i2s1 alone, i2s2 alone or both i2s1+i2s2 at the same time.
How does that work - I mean, if we have i2s1 as the SCLK and WS master,
how can i2s2 run without i2s1?
I suppose I2S2 could be reprogrammed to be the master for both signals,
provided that I2S1 is programmed to be a slave before hand, but that
seems to be making things excessively complex (we'd need some way for
I2S1 and I2S2 to comunicate that state between themselves and negotiate
which to be the master.)
However, I'd suggest that if audio1_i2s always maps to HDMI front
left/right, audio1_i2s must always be enabled when audio playback is
required; there is no CA bit combination provided in HDMI where the
front L/R channels are optional. Hence, I'd suggest that audio1_i2s
must always be the master.
As we don't know, I'd suggest that we permit flexibility here. We
can use the reg property as you have below, and we just bitwise-or
the of_endpoint port/id together, al
[PATCH RFC 0/3] Make "ti,tilcdc,slave" DT binding more sensible
On 01/14/2015 08:57 AM, Jean-Francois Moine wrote: > On Tue, 13 Jan 2015 19:12:25 +0200 > Jyri Sarha wrote: > >> These patches are needed for Beaglebone-back HDMI audio. There is no >> direct dependency between these patches and the other (dts and ASoC) >> changes needed for the HDMI audio so these changes can be merged >> independently. I also feel that these changes make sense even without >> the HDMI audio. >> >> Best regards, >> Jyri >> >> Jyri Sarha (3): >>drm: encoder_slave: Add drm_i2c_encoder_attach() >>drm/tilcdc: slave: Add support for "i2c-slave" DT-parameter >>ARM: dts: am335x-boneblack: Use new binding in ti,tilcdc,slave node >> >> .../devicetree/bindings/drm/tilcdc/slave.txt |4 +- >> arch/arm/boot/dts/am335x-boneblack.dts |9 +++- >> drivers/gpu/drm/drm_encoder_slave.c| 51 >> >> drivers/gpu/drm/tilcdc/tilcdc_slave.c | 50 >> +++ >> include/drm/drm_encoder_slave.h|3 ++ >> 5 files changed, 95 insertions(+), 22 deletions(-) > > Instead of adding code to have the slave encoder working, it would be > simpler to change the way tilcdc uses the tda998x. > I already proposed such a patch: > > http://lists.freedesktop.org/archives/dri-devel/2014-March/056065.html > > and the changes in the tda998x driver have been done by Russell: > > commit: a8f4d4d63739e4bca459ff40636f1d9e4b7ef5e6 > drm/i2c: tda998x: allow re-use of tda998x support code > and > commit: c707c3619ca81f499a5ce032021405e989a96ff0 > drm/i2c: tda998x: add component support > Interesting. Would you still have the original branch somewhere? Manual applying the patches from the web-page is time consuming. Best regards, Jyri
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
Hi Russell,
thanks for the clarification.
Am Dienstag, den 13.01.2015, 19:54 + schrieb Russell King - ARM
Linux:
[...]
> To represent that in DT, I would imagine we'd need something like this:
>
> #address-cells = <1>;
> #size-cells = <0>;
> ...
> port at 1 {/* AP1,2 = I2S */
> #address-cells = <1>;
> #size-cells = <0>;
> port-type = "i2s";
> reg = <0x01>; /* WS */
> tda998x_i2s1: endpoint at 2 {
> reg = <0x02>; /* AP1 */
> remote-endpoint = <&audio1_i2s>;
> };
> tda998x_i2s2: endpoint at 4 {
> reg = <0x04>; /* AP2 */
> remote-endpoint = <&audio2_i2s>;
> };
> };
>
> where audio1_i2s is operating in master mode, and audio2_i2s is
> operating in slave mode for both WS and SCLK.
>
> If we can agree on that, then I'm happy with the proposed binding.
> (Remember that #address-cells and #size-cells are required in the
> parent where we have reg= in the child.)
So the question is mostly whether four I2S data pins with a single
shared WS/SCK input should be called "four I2S ports with shared clocks"
or "one I2S port with up to four data lanes". I'd lean towards the
latter.
How audio2_i2s is forced to synchronize its clock output to audio1_i2s
is a problem their bindings will have to handle.
regards
Philipp
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #16 from Arthur Marsh --- Created attachment 112211 --> https://bugs.freedesktop.org/attachment.cgi?id=112211&action=edit 2015011421dmesg.txt - GPU lock-up less than 2 minutes into video play-back. -- 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/20150114/b7da7a59/attachment-0001.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #15 from Arthur Marsh --- Upgraded to current Linus git head and tried again. This time there was no GPU reset associated with starting kdm (which had happened over the last few days), but the lock-up when playing the same video came less than 2 minutes into the video, much sooner than before. -- 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/20150114/5f8adfdd/attachment.html>
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
>
> On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> >> Taking rotation into account while checking the plane
> >> and adjusting the sizes accordingly.
> >>
> >> Signed-off-by: Sonika Jindal
> >> ---
> >> drivers/gpu/drm/drm_plane_helper.c | 79
> >> ++--
> >> include/drm/drm_plane_helper.h |3 +-
> >> 2 files changed, 77 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> >> b/drivers/gpu/drm/drm_plane_helper.c
> >> index f24c4cf..4badd69 100644
> >> --- a/drivers/gpu/drm/drm_plane_helper.c
> >> +++ b/drivers/gpu/drm/drm_plane_helper.c
> >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>int max_scale,
> >>bool can_position,
> >>bool can_update_disabled,
> >> - bool *visible)
> >> + bool *visible,
> >> + unsigned int rotation)
> >> {
> >>int hscale, vscale;
> >> + int crtc_x, crtc_y;
> >> + unsigned int crtc_w, crtc_h;
> >> + uint32_t src_x, src_y, src_w, src_h;
> >>
> >>if (!fb) {
> >>*visible = false;
> >> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>return -EINVAL;
> >>}
> >>
> >> + if (fb)
> >> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> >> + rotation);
> >> +
> >>/* Check scaling */
> >> - hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> >> - vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> >> + hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale, max_scale);
> >> + vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale, max_scale);
> > This is an unrelated change. Relaxed scaling allows the the src/dest
> > rectangles to be reduced in size in order to keep the scaling ration
> > within the min/max range. I suppose we should switch to using it to
> > make the behaviour uniform across drivers, but definitely should be
> > done with a separate patch.
> Since, I added drm_rect_rotate before this, it changes the src sizes and
> it was giving me
> Invalid scaling if we don't let the sizes to be changed using _relaxed
> functions. I am trying this
> for 90/270 rotation.
That would indicate a bug somewhere. Pontetially the bug could be in
whatever test you're using as well.
> I can move it to a separate patch if required.
We nee to figure out why you got the error first.
--
Ville Syrjälä
Intel OTC
Softlockup on boot with Cape Verde XT on many kernels
On 14.01.2015 03:20, Federico wrote: > I tried setting vga=791, but the panic messages done appear on screen, > only the normal kernel boot log until the key lights start flashing. Sounds like the panic happens after vesafb is already shut down in favour of radeon. > Also tried a video capture, but the text goes too fast even for the LCD > to update the image. > > Do you know how to set the console font size as a kernel parameter? Search for '8-.*font' in Documentation/svga.txt. Other possibilities would be serial console or possibly netconsole. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm: Adding rotation to drm_plane_helper_check_update
Taking rotation into account while checking the plane
and adjusting the sizes accordingly.
v2: Adding parameter in the callers in the same patch(Matt)
Removing unnecessary code and allowing scaling(Ville)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/drm_plane_helper.c | 44 ---
drivers/gpu/drm/i915/intel_display.c|6 ++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 +-
include/drm/drm_plane_helper.h |3 +-
4 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index f24c4cf..d6916af 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -138,7 +138,8 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
int max_scale,
bool can_position,
bool can_update_disabled,
- bool *visible)
+ bool *visible,
+ unsigned int rotation)
{
int hscale, vscale;
@@ -158,9 +159,13 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
return -EINVAL;
}
+ if (fb)
+ drm_rect_rotate(src, fb->width << 16, fb->height << 16,
+ rotation);
+
/* Check scaling */
- hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
- vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
+ hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale, max_scale);
if (hscale < 0 || vscale < 0) {
DRM_DEBUG_KMS("Invalid scaling of plane\n");
return -ERANGE;
@@ -182,6 +187,36 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
return -EINVAL;
}
+ if (*visible) {
+ /* check again in case clipping clamped the results */
+ hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
+ if (hscale < 0) {
+ DRM_DEBUG_KMS("Horizontal scaling factor out of
limits\n");
+ drm_rect_debug_print(src, true);
+ drm_rect_debug_print(dest, false);
+
+ return hscale;
+ }
+
+ vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
+ if (vscale < 0) {
+ DRM_DEBUG_KMS("Vertical scaling factor out of
limits\n");
+ drm_rect_debug_print(src, true);
+ drm_rect_debug_print(dest, false);
+
+ return vscale;
+ }
+
+ /* Make the source viewport size an exact multiple of the
scaling factors. */
+ drm_rect_adjust_size(src,
+ drm_rect_width(dest) * hscale - drm_rect_width(src),
+ drm_rect_height(dest) * vscale - drm_rect_height(src));
+
+ drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
+ rotation);
+
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_plane_helper_check_update);
@@ -258,7 +293,8 @@ int drm_primary_helper_update(struct drm_plane *plane,
struct drm_crtc *crtc,
&src, &dest, &clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
- false, false, &visible);
+ false, false, &visible,
+ DRM_ROTATE_0);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f40288f..d19ed4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12155,7 +12155,8 @@ intel_check_primary_plane(struct drm_plane *plane,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
- false, true, &state->visible);
+ false, true, &state->visible,
+ to_intel_plane(plane)->rotation);
if (ret)
return ret;
@@ -12429,7 +12430,8 @@ intel_check_cursor_plane(struct drm_plane *plane,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
-
[GIT PULL] drm: Add Atmel HLCDC driver
Le 09/01/2015 16:03, Boris Brezillon a wrote : > Dave, Thierry, Dave and Thierry, Is it possible for you to consider this pull-request? We would like to see it appearing as soon as possible in linux-next. Furthermore, we are pretty excited to see this long awaited driver running on our AT91 SoCs with a Mainline kernel. We missed several kernel releases and as everything seems accepted and well aligned now, we are looking forward being reassured by an inclusion of this code in the DRM git tree. Thanks, bye. Nicolas. > Here is the pull request for the Atmel HLCDC driver and its > dependencies (some modifications to drm/core and drm/panel to define > output bus format). > > I'm sending a pull request for this driver for several reasons: > > * The patch series has been around for 6 months (initial version here >[3]), and has seen 9 iterations, taking into account comments made >by reviewers. > > * It has received several Tested-by by various users/developers. > > * It has been Reviewed-by Rob Clark. > > * There has been no comment whatsoever since more than a month (see >[1] and [2] for the last modified version of these series). > > I'll be happy to take comments into account if any. But if there are no > more comments, please merge for 3.20. > > Best Regards, > > Boris > > [1]https://lkml.org/lkml/2014/12/1/717 > [2]http://thread.gmane.org/gmane.comp.video.dri.devel/118700 > [3]https://lkml.org/lkml/2014/6/9/487 > > The following changes since commit c93546a5e32bd788c22aefa072385f3784551c13: > > Merge tag 'topic/atomic-core-2015-01-05' of > git://anongit.freedesktop.org/drm-intel into drm-next (2015-01-09 09:22:40 > +1000) > > are available in the git repository at: > > > https://github.com/bbrezillon/linux-at91.git tags/atmel-hlcdc-drm-3.20 > > for you to fetch changes up to e7f6614add3dc7776abd803be7cbe96b6254b3f5: > > drm: add DT bindings documentation for atmel-hlcdc-dc driver (2015-01-09 > 14:55:08 +0100) > > > Boris Brezillon (5): > drm: add bus_formats and num_bus_formats fields to drm_display_info > drm: panel: simple-panel: add support for bus_format retrieval > drm: panel: simple-panel: add bus format information for foxlink panel > drm: add Atmel HLCDC Display Controller support > drm: add DT bindings documentation for atmel-hlcdc-dc driver > > .../devicetree/bindings/drm/atmel/hlcdc-dc.txt | 53 ++ > drivers/gpu/drm/Kconfig| 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/atmel-hlcdc/Kconfig| 11 + > drivers/gpu/drm/atmel-hlcdc/Makefile | 7 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 406 ++ > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 579 ++ > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 213 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 667 > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 398 ++ > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 319 > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 856 > + > drivers/gpu/drm/drm_crtc.c | 35 + > drivers/gpu/drm/panel/panel-simple.c | 6 + > include/drm/drm_crtc.h | 8 + > 15 files changed, 3561 insertions(+) > create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > > -- Nicolas Ferre
Softlockup on boot with Cape Verde XT on many kernels
Here's a stack trace with soflockup_panic=1 using 50 lines per screen. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298395/+files/20150114_100952.png 2015-01-14 0:54 GMT-03:00 Michel Dänzer : > On 14.01.2015 12:41, Federico wrote: > > I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and > > I got a different stack trace. Shorter. It repeats itself every about 30 > > seconds more or less. Keyboard lights don't flash. The same message > > keeps coming out. > > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png > > That's again missing some of the information, but it doesn't look > directly related to the radeon driver. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/21e13b36/attachment.html>
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
>> Taking rotation into account while checking the plane
>> and adjusting the sizes accordingly.
>>
>> Signed-off-by: Sonika Jindal
>> ---
>> drivers/gpu/drm/drm_plane_helper.c | 79
>> ++--
>> include/drm/drm_plane_helper.h |3 +-
>> 2 files changed, 77 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_plane_helper.c
>> b/drivers/gpu/drm/drm_plane_helper.c
>> index f24c4cf..4badd69 100644
>> --- a/drivers/gpu/drm/drm_plane_helper.c
>> +++ b/drivers/gpu/drm/drm_plane_helper.c
>> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
>> *plane,
>> int max_scale,
>> bool can_position,
>> bool can_update_disabled,
>> -bool *visible)
>> +bool *visible,
>> +unsigned int rotation)
>> {
>> int hscale, vscale;
>> +int crtc_x, crtc_y;
>> +unsigned int crtc_w, crtc_h;
>> +uint32_t src_x, src_y, src_w, src_h;
>>
>> if (!fb) {
>> *visible = false;
>> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
>> *plane,
>> return -EINVAL;
>> }
>>
>> +if (fb)
>> +drm_rect_rotate(src, fb->width << 16, fb->height << 16,
>> +rotation);
>> +
>> /* Check scaling */
>> -hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
>> -vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
>> +hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale, max_scale);
>> +vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale, max_scale);
> This is an unrelated change. Relaxed scaling allows the the src/dest
> rectangles to be reduced in size in order to keep the scaling ration
> within the min/max range. I suppose we should switch to using it to
> make the behaviour uniform across drivers, but definitely should be
> done with a separate patch.
Since, I added drm_rect_rotate before this, it changes the src sizes and
it was giving me
Invalid scaling if we don't let the sizes to be changed using _relaxed
functions. I am trying this
for 90/270 rotation. I can move it to a separate patch if required.
>> if (hscale < 0 || vscale < 0) {
>> DRM_DEBUG_KMS("Invalid scaling of plane\n");
>> return -ERANGE;
>> @@ -182,6 +190,68 @@ int drm_plane_helper_check_update(struct drm_plane
>> *plane,
>> return -EINVAL;
>> }
>>
>> +crtc_x = dest->x1;
>> +crtc_y = dest->y1;
>> +crtc_w = drm_rect_width(dest);
>> +crtc_h = drm_rect_height(dest);
> You don't adjust these in any way so they are not needed.
>
>> +
>> +if (*visible) {
>> +/* check again in case clipping clamped the results */
>> +hscale = drm_rect_calc_hscale(src, dest,
>> +DRM_PLANE_HELPER_NO_SCALING,
>> +DRM_PLANE_HELPER_NO_SCALING);
> First you allowed scaling and now you don't. What's up with that?
Hmm, so I can simply use min_scale and max_scale here.
>> +if (hscale < 0) {
>> +DRM_DEBUG_KMS("Horizontal scaling factor out of
>> limits\n");
>> +drm_rect_debug_print(src, true);
>> +drm_rect_debug_print(dest, false);
>> +
>> +return hscale;
>> +}
>> +
>> +vscale = drm_rect_calc_vscale(src, dest,
>> +DRM_PLANE_HELPER_NO_SCALING,
>> +DRM_PLANE_HELPER_NO_SCALING);
>> +if (vscale < 0) {
>> +DRM_DEBUG_KMS("Vertical scaling factor out of
>> limits\n");
>> +drm_rect_debug_print(src, true);
>> +drm_rect_debug_print(dest, false);
>> +
>> +return vscale;
>> +}
>> +
>> +/* Make the source viewport size an exact multiple of the
>> scaling factors. */
>> +drm_rect_adjust_size(src,
>> +drm_rect_width(dest) * hscale - drm_rect_width(src),
>> +drm_rect_height(dest) * vscale - drm_rect_height(src));
>> +
>> +drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
>> +rotation);
>> +
>> +/*
>> + * Hardware doesn't handle subpixel coordinates.
> That's a purely hardware specific detail. It should not be part of the
> helpers. And in any case the returned src coordinates must remain in
> fixed point format.
>
I was just trying to make it same as what we do in intel_check_sprite_plane.
So, looks like I can remove this one and the other pa
[PATCH 0/2] Adding rotattion to drm_plane_helper_check_update
On Tuesday 13 January 2015 11:42 PM, Matt Roper wrote: > On Tue, Jan 13, 2015 at 06:03:38PM +0530, Sonika Jindal wrote: >> This adds another parameter rotation to drm_plane_helper_check_update. >> This will enable this function to do to size updations based upon the >> rotation >> if any. >> Updated the calls to this function in i915 and drm. Rockchip driver also >> needs >> to be updated. > It looks like you add the new function parameter in patch 1, but don't > add it to the i915 callsites until patch 2 (and don't add it to the > rockchip driver at all in this series). That means that if someone is > bisecting the kernel and lands on this commit, some of the drivers will > fail to build, which isn't good. > > The callsites need to be updated at the same time that you add the > parameter; fortunately there are only four of them (two in i915, one in > the generic plane helper, and one in rockchip). For simplicity, you can > just pass the DRM_ROTATE_0 bit initially at the updated callsites when > you add the new parameter so that there's no change from the current > behavior for the existing callers. Then you can come back in later in > driver-specific patch(es) and pass the real rotation value the driver is > using and adjust the caller's functionality as appropriate. Sure, I will do this. Sonika > > Matt > >> Sonika Jindal (2): >>drm: Adding rotation to drm_plane_helper_check_update >>drm/i915: Passing rotation to drm_plane_helper_check_update >> >> drivers/gpu/drm/drm_plane_helper.c | 79 >> -- >> drivers/gpu/drm/i915/intel_display.c |6 ++- >> include/drm/drm_plane_helper.h |3 +- >> 3 files changed, 81 insertions(+), 7 deletions(-) >> >> -- >> 1.7.10.4 >>
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h.
Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser than
the min_hscale (which is no_scaling by default), so it returns -ERANGE.
So, I think we _relaxed is the function which should be called to update the
destination size appropriately.
Please correct me if I am wrong.
-Original Message-
From: Jindal, Sonika
Sent: Wednesday, January 14, 2015 3:06 PM
To: 'Ville Syrjälä'
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
drm_plane_helper_check_update
We do exactly like this for sprite plane (ie, rotate the rect, then check
scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed)
That's why I saw the need of this for primary plane as well.
For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments and
the rotated sizes are fine. But since we don't do any of those stuff for
primary the destination size doesn't come right, and I get a little corrupted
output after rotation.
With this change, the rotated plane is properly adjusted in the viewport.
So, I don't think it is a bug in test.
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, January 14, 2015 2:58 PM
To: Jindal, Sonika
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
>
> On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> >> Taking rotation into account while checking the plane and adjusting
> >> the sizes accordingly.
> >>
> >> Signed-off-by: Sonika Jindal
> >> ---
> >> drivers/gpu/drm/drm_plane_helper.c | 79
> >> ++--
> >> include/drm/drm_plane_helper.h |3 +-
> >> 2 files changed, 77 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> >> b/drivers/gpu/drm/drm_plane_helper.c
> >> index f24c4cf..4badd69 100644
> >> --- a/drivers/gpu/drm/drm_plane_helper.c
> >> +++ b/drivers/gpu/drm/drm_plane_helper.c
> >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>int max_scale,
> >>bool can_position,
> >>bool can_update_disabled,
> >> - bool *visible)
> >> + bool *visible,
> >> + unsigned int rotation)
> >> {
> >>int hscale, vscale;
> >> + int crtc_x, crtc_y;
> >> + unsigned int crtc_w, crtc_h;
> >> + uint32_t src_x, src_y, src_w, src_h;
> >>
> >>if (!fb) {
> >>*visible = false;
> >> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>return -EINVAL;
> >>}
> >>
> >> + if (fb)
> >> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> >> + rotation);
> >> +
> >>/* Check scaling */
> >> - hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> >> - vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> >> + hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale, max_scale);
> >> + vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale,
> >> +max_scale);
> > This is an unrelated change. Relaxed scaling allows the the src/dest
> > rectangles to be reduced in size in order to keep the scaling ration
> > within the min/max range. I suppose we should switch to using it to
> > make the behaviour uniform across drivers, but definitely should be
> > done with a separate patch.
> Since, I added drm_rect_rotate before this, it changes the src sizes
> and it was giving me Invalid scaling if we don't let the sizes to be
> changed using _relaxed functions. I am trying this for 90/270
> rotation.
That would indicate a bug somewhere. Pontetially the bug could be in whatever
test you're using as well.
> I can move it to a separate patch if required.
We nee to figure out why you got the error first.
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
We do exactly like this for sprite plane (ie, rotate the rect, then check
scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed)
That's why I saw the need of this for primary plane as well.
For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments and
the rotated sizes are fine. But since we don't do any of those stuff
for primary the destination size doesn't come right, and I get a little
corrupted output after rotation.
With this change, the rotated plane is properly adjusted in the viewport.
So, I don't think it is a bug in test.
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, January 14, 2015 2:58 PM
To: Jindal, Sonika
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to
drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote:
>
> On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote:
> > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> >> Taking rotation into account while checking the plane and adjusting
> >> the sizes accordingly.
> >>
> >> Signed-off-by: Sonika Jindal
> >> ---
> >> drivers/gpu/drm/drm_plane_helper.c | 79
> >> ++--
> >> include/drm/drm_plane_helper.h |3 +-
> >> 2 files changed, 77 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> >> b/drivers/gpu/drm/drm_plane_helper.c
> >> index f24c4cf..4badd69 100644
> >> --- a/drivers/gpu/drm/drm_plane_helper.c
> >> +++ b/drivers/gpu/drm/drm_plane_helper.c
> >> @@ -138,9 +138,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>int max_scale,
> >>bool can_position,
> >>bool can_update_disabled,
> >> - bool *visible)
> >> + bool *visible,
> >> + unsigned int rotation)
> >> {
> >>int hscale, vscale;
> >> + int crtc_x, crtc_y;
> >> + unsigned int crtc_w, crtc_h;
> >> + uint32_t src_x, src_y, src_w, src_h;
> >>
> >>if (!fb) {
> >>*visible = false;
> >> @@ -158,9 +162,13 @@ int drm_plane_helper_check_update(struct drm_plane
> >> *plane,
> >>return -EINVAL;
> >>}
> >>
> >> + if (fb)
> >> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> >> + rotation);
> >> +
> >>/* Check scaling */
> >> - hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> >> - vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> >> + hscale = drm_rect_calc_hscale_relaxed(src, dest, min_scale, max_scale);
> >> + vscale = drm_rect_calc_vscale_relaxed(src, dest, min_scale,
> >> +max_scale);
> > This is an unrelated change. Relaxed scaling allows the the src/dest
> > rectangles to be reduced in size in order to keep the scaling ration
> > within the min/max range. I suppose we should switch to using it to
> > make the behaviour uniform across drivers, but definitely should be
> > done with a separate patch.
> Since, I added drm_rect_rotate before this, it changes the src sizes
> and it was giving me Invalid scaling if we don't let the sizes to be
> changed using _relaxed functions. I am trying this for 90/270
> rotation.
That would indicate a bug somewhere. Pontetially the bug could be in whatever
test you're using as well.
> I can move it to a separate patch if required.
We nee to figure out why you got the error first.
--
Ville Syrjälä
Intel OTC
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Tue, 13 Jan 2015 19:54:15 +
Russell King - ARM Linux wrote:
> On Tue, Jan 13, 2015 at 09:41:01PM +0200, Jyri Sarha wrote:
> > On 01/13/2015 09:26 PM, Russell King - ARM Linux wrote:
> > >SCLK: _~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_
> > > WS: __~
> > >I2S1: llmmllmmllm
> > >I2S2: llmmllmmllm
> > >I2S3: llmmllmmllm
> > >I2S4: llmmllmmllm
> > >
> > >So, what I'm saying is that it is_impossible_ to drive the TDA998x using
> > >multiple I2S streams which are not produced by the same I2S block.
> >
> > This is besides the point, but it is possible that one of the multiple I2S
> > blocks is the bit-clock and frame-clock master to the i2s bus and the others
> > are slaves to it (banging their bits according to SCLK and WS of the I2S
> > master). However, in this situation there really is only one i2s bus with
> > multiple data pins.
> >
> > Just my 0.02⬠to this discussion.
>
> Right, that's about the only way it could work.
>
> To represent that in DT, I would imagine we'd need something like this:
>
> #address-cells = <1>;
> #size-cells = <0>;
> ...
> port at 1 {/* AP1,2 = I2S */
> #address-cells = <1>;
> #size-cells = <0>;
> port-type = "i2s";
> reg = <0x01>; /* WS */
> tda998x_i2s1: endpoint at 2 {
> reg = <0x02>; /* AP1 */
> remote-endpoint = <&audio1_i2s>;
> };
> tda998x_i2s2: endpoint at 4 {
> reg = <0x04>; /* AP2 */
> remote-endpoint = <&audio2_i2s>;
> };
> };
>
> where audio1_i2s is operating in master mode, and audio2_i2s is
> operating in slave mode for both WS and SCLK.
>
> If we can agree on that, then I'm happy with the proposed binding.
> (Remember that #address-cells and #size-cells are required in the
> parent where we have reg= in the child.)
#address-cells and #size-cells may be defined in any of the upper
parent, so, as it is defined in the device, it is not needed in the
port (see of_n_addr_cells in drivers/of/base.c).
Well, I am a bit lost between (only one source / many channels - I2S
busses) and (many sources / one I2s bus!).
Anyway, I don't understand your example.
I'd expect that a port would be a DAI.
If yes, when playing is active, both endpoints receive an audio stream
from the remote audio devices, and the AP register is always set to
0x07 (= 0x01 | 0x02 | 0x04).
Then, it would have been simpler to have:
#address-cells = <1>;
#size-cells = <0>;
...
port at 7 {/* AP1,2 = I2S */
port-type = "i2s";
reg = <0x07>; /* WS + AP1 + AP2 */
tda998x_i2s1: endpoint at 1 {
remote-endpoint = <&audio1_i2s>;
};
tda998x_i2s2: endpoint at 2 {
remote-endpoint = <&audio2_i2s>;
};
};
If no, the two DAIs must be created from the endpoints, permitting
streaming on i2s1 alone, i2s2 alone or both i2s1+i2s2 at the same time.
Then, it would have been simpler to define the DAIs from the ports:
#address-cells = <1>;
#size-cells = <0>;
...
port at 3 {/* AP1 = I2S */
port-type = "i2s";
reg = <0x03>; /* WS + AP1 */
tda998x_i2s1: endpoint {
remote-endpoint = <&audio1_i2s>;
};
};
port at 5 {/* AP2 = I2S */
port-type = "i2s";
reg = <0x05>; /* WS + AP2 */
tda998x_i2s1: endpoint {
remote-endpoint = <&audio1_i2s>;
};
};
--
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
boot delay with drm_kms_helper.edid_firmware
Hi,
using drm_kms_helper.edid_firmware the boot time is much longer (~1min)
than without it. I attach the boot log ("drm.debug=0x06"), one time
with drm_kms_helper.edid_firmware, one time without.
What could be the problem?
I am using Kernel 3.8.13-bone69 on a Beaglebone black. I
used drm_kms_helper.edid_firmware before and never saw this issue.
Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/80eae675/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: drm.log
Type: application/octet-stream
Size: 13749 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/80eae675/attachment-0001.obj>
[Intel-gfx] [PATCH] drm: Adding rotation to drm_plane_helper_check_update
On Wed, Jan 14, 2015 at 11:10:54AM +0530, Sonika Jindal wrote: > Taking rotation into account while checking the plane > and adjusting the sizes accordingly. > > v2: Adding parameter in the callers in the same patch(Matt) > Removing unnecessary code and allowing scaling(Ville) > > Signed-off-by: Sonika Jindal > --- ... > EXPORT_SYMBOL(drm_plane_helper_check_update); > @@ -258,7 +293,8 @@ int drm_primary_helper_update(struct drm_plane *plane, > struct drm_crtc *crtc, > &src, &dest, &clip, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > - false, false, &visible); > + false, false, &visible, > + DRM_ROTATE_0); I think this needs to be BIT(DRM_ROTATE_0)? ... > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index e7ca25b..4813a53 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -551,7 +551,8 @@ static int vop_update_plane_event(struct drm_plane *plane, > &src, &dest, &clip, > DRM_PLANE_HELPER_NO_SCALING, > DRM_PLANE_HELPER_NO_SCALING, > - can_position, false, &visible); > + can_position, false, &visible, > + DRM_ROTATE_0); Same here. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
[PATCH RFC 0/3] Make "ti,tilcdc,slave" DT binding more sensible
On Tue, 13 Jan 2015 19:12:25 +0200 Jyri Sarha wrote: > These patches are needed for Beaglebone-back HDMI audio. There is no > direct dependency between these patches and the other (dts and ASoC) > changes needed for the HDMI audio so these changes can be merged > independently. I also feel that these changes make sense even without > the HDMI audio. > > Best regards, > Jyri > > Jyri Sarha (3): > drm: encoder_slave: Add drm_i2c_encoder_attach() > drm/tilcdc: slave: Add support for "i2c-slave" DT-parameter > ARM: dts: am335x-boneblack: Use new binding in ti,tilcdc,slave node > > .../devicetree/bindings/drm/tilcdc/slave.txt |4 +- > arch/arm/boot/dts/am335x-boneblack.dts |9 +++- > drivers/gpu/drm/drm_encoder_slave.c| 51 > > drivers/gpu/drm/tilcdc/tilcdc_slave.c | 50 +++ > include/drm/drm_encoder_slave.h|3 ++ > 5 files changed, 95 insertions(+), 22 deletions(-) Instead of adding code to have the slave encoder working, it would be simpler to change the way tilcdc uses the tda998x. I already proposed such a patch: http://lists.freedesktop.org/archives/dri-devel/2014-March/056065.html and the changes in the tda998x driver have been done by Russell: commit: a8f4d4d63739e4bca459ff40636f1d9e4b7ef5e6 drm/i2c: tda998x: allow re-use of tda998x support code and commit: c707c3619ca81f499a5ce032021405e989a96ff0 drm/i2c: tda998x: add component support -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH] reservation: wait only with non-zero timeout specified (v3)
>> I think it would be best to leave timeout=0 returning 0. Not handling it >> differently gives the same semantics as used by fence_wait_time and >> wait_event_timeout. >> Are there really many cases in which you don't know if timeout = 0 before or >> not? >Yeah I think with this it's more important to be consistent with all the other >wait_something primitives the kernel exposes. Okay. I think we can live with that from driver perspective by handling timeout==0 and timeout>0 differently. But it should still be worth adding some notes for reservation_object_wait_timeout_rcu that the return value cannot be used to judge if the fences are signaled or not when timeout==0. Regards, Jammy
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 --- Comment #13 from Andreas Hartmetz --- I have a somewhat similar issue with radeonsi, latest everything (xorg, llvm, mesa) except Linux kernel which is 3.17.8, and Cape Verde PRO (aka Radeon HD 7750) hardware. The screen sometimes turns completely black for a frame. It happened a few times per hour. In the past this could be reliably avoided by pinning the power setting to min or max, but DPM changes prevented that fix from working. Now that I know this: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level (looks similar to the one that used to work a few kernels earlier?) I can avoid the problem again, but of course at the cost of power consumption. The underlying issue might be the same timing problem. I can file a new bug if you think it is a different issue. -- 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/20150114/b8546da8/attachment.html>
[Bug 90861] Panic on suspend from KDE with radeon
https://bugzilla.kernel.org/show_bug.cgi?id=90861 --- Comment #8 from Michel Dänzer --- (In reply to Jon Arne Jørgensen from comment #7) > I'm trying to bisect now, but I'm troubled by a gpu freeze bug in some of > the commits that crashes Xorg before I'm able to suspend the computer. > > It looks like a bug early in the v3.18 merge window, but I'm not sure if I > should skip the crashing commits while doing the bisect? I'd skip them for now. -- You are receiving this mail because: You are watching the assignee of the bug.
Softlockup on boot with Cape Verde XT on many kernels
I tried 3.16.0 just using radeon.dpm=0 (without softlockup_panic=1) and I got a different stack trace. Shorter. It repeats itself every about 30 seconds more or less. Keyboard lights don't flash. The same message keeps coming out. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298034/+files/20150114_003043.png 2015-01-13 23:19 GMT-03:00 Michel Dänzer : > On 14.01.2015 03:20, Federico wrote: > > I tried setting vga=791, but the panic messages done appear on screen, > > only the normal kernel boot log until the key lights start flashing. > > Sounds like the panic happens after vesafb is already shut down in > favour of radeon. > > > > Also tried a video capture, but the text goes too fast even for the LCD > > to update the image. > > > > Do you know how to set the console font size as a kernel parameter? > > Search for '8-.*font' in Documentation/svga.txt. > > Other possibilities would be serial console or possibly netconsole. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150114/c56e5bed/attachment.html>
