Sorry for late.
I started to test and migrate them to exynos-drm-next yesterday. So I
guess that you can see your patch series on exynos-drm-next today night
or tomorrow.
Thanks,
Inki Dae
On 2014ë
11ì 12ì¼ 23:13, Gustavo Padovan wrote:
> Hi Inki,
>
> 2014-11-06 Inki Dae :
>
>>
>> Hi Gust
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #13 from Michel Dänzer ---
Marek, can you bisect or otherwise narrow down what kernel change caused the
problem for you?
--
You are receiving this mail because:
You are watching the assignee of the bug.
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/93a75952/attachment.html>
vel/attachments/20141113/620dfcee/attachment.html>
work if you remove that patch?
--
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/20141113/e768b2e4/attachment.html>
s 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/20141113/713cfbf7/attachment.html>
This patch set fixes null pointer dereference issue incurred when
Exynos drm driver is closed. And it rebases a existing cleanup patch
posted by Andrzej on top of exynos-drm-fixes after the infinite loop
and null pointer dereference issues are resolved.
Andrzej Hajda (1):
drm/exynos: remove ifde
From: Andrzej Hajda
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.
Changelog v2:
- Rebased.
- Consider non kms drive
This patch fixes null pointer dereference issue incurred
when ipp driver is enabled and Exynos drm driver is closed.
Non kms driver should register its own sub driver to setup necessary
resources, which is done by load(). So null pointer dereference
occurs when ipp driver is enabled and Exynos drm
On 2014ë
11ì 07ì¼ 15:12, YoungJun Cho wrote:
> This patch supports Exynos4415 SoC.
>
Applied.
Thanks,
Inki Dae
> Signed-off-by: YoungJun Cho
> Acked-by: Kyungmin Park
> ---
> Documentation/devicetree/bindings/video/exynos_dsim.txt | 1 +
> drivers/gpu/drm/exynos/exynos_drm_dsi.c
On 2014ë
11ì 07ì¼ 15:12, YoungJun Cho wrote:
> This patch supports Exynos4415 SoC.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: YoungJun Cho
> Acked-by: Kyungmin Park
> ---
> Documentation/devicetree/bindings/video/samsung-fimd.txt | 1 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c
On 2014ë
10ì 31ì¼ 23:17, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> It is not even used in this header anymore.
All patches, Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 -
> 1 file changed, 1 deletion(-)
>
On 2014ë
10ì 07ì¼ 21:01, Andrzej Hajda wrote:
> Hi Inki,
>
> Many Exynos DRM drivers uses global variables to represent associated devices
> in Exynos DRM internal framework. It is quite confusing, it adds data
> duplication
> and finally it does not allow to handle more than one device in s
On 2014ë
11ì 12ì¼ 18:42, Vivek Gautam wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Vivek Gautam
> Ack
On 2014ë
10ì 01ì¼ 15:19, YoungJun Cho wrote:
> The exynos_drm_crtc_dpms() waits until pended page flip
> queue is empty, calls the drm_vblank_off() then calls
> manager->ops->dpms() when mode is DRM_MODE_DPMS_OFF.
> The fimd_dpms() is one of manager->ops->dpms()s and
> finally calls fimd_windo
On 2014ë
10ì 01ì¼ 15:19, YoungJun Cho wrote:
> The ENWIN_F in WINCON# register and C#_EN_Fs in SHADOWCON register
> should be always matched together, so adds fimd_channel_win()
> to clean up code.
> And this fimd_channel_win() should be called before unprotecting
> window in fimd_win_commit()
On 12.11.2014 02:54, Marcus Overhagen wrote:
> This crash occured after about a day with 3.18.0-rc3
Is it a regression? If yes, can you bisect?
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
On 2014ë
10ì 01ì¼ 15:19, YoungJun Cho wrote:
> The I80 interface uses SYS_WE and SYS_CS to process
> 1 pixel data, so it requires the twice faster clock
> than the pixel clock.
> And the frame done interrupt should occurr prior to
> the next TE signal, H/W guy recommends to use as 1.73
> times
ile my systems were newer ones (TURKS, ARUBA),
so this issue might be specific to chip model.
--
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/20141113/9bd2c5a1/attachment.html>
Hi Inki,
On 11/13/2014 06:12 PM, Inki Dae wrote:
> On 2014ë
10ì 01ì¼ 15:19, YoungJun Cho wrote:
>> The I80 interface uses SYS_WE and SYS_CS to process
>> 1 pixel data, so it requires the twice faster clock
>> than the pixel clock.
>> And the frame done interrupt should occurr prior to
>> the
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/78995136/attachment.html>
On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > If clwb is available on the system, use it in drm_clflush_virt_range.
> > If clwb is not available, fall back to clflushopt if you can.
> > If clflushopt is not supported, fall all the
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/6160525a/attachment-0001.html>
Hi there,
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)
$ sudo lspci -v -s 00:02
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)
(prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device 2213
On 11/12/2014 12:31 AM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org
> wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=87891
>>
>>
On Wed, Nov 12, 2014 at 10:39:24AM +, Mel Gorman wrote:
> On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
> > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > > On Tue, 11 Nov 2014 18:36:2
On Thu, 13 Nov 2014, olivier.fambon at free.fr wrote:
> Hi there,
>
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)
>
> $ sudo lspci -v -s 00:02
> 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e)
> (prog-if 00 [VGA c
available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/087ff657/attachment-0001.sig>
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/48eb908d/attachment.sig>
ble
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/bf839dbe/attachment.sig>
(-)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/4aca6f00/attachment.sig>
Hi Dave, one regression fix from Chris.
BR,
Jani.
The following changes since commit 03dca708521d30153fc5c7e2ff136f780a7372c9:
Merge tag 'drm-intel-fixes-2014-11-07' of
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-11-10 10:05:37
+1000)
are available in the git repository at
t Y: -1
Relative upper-left X: -1
Relative upper-left Y: -1
--
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/20141113/bd26503d/attachment.html>
On 11/13/2014 09:50 AM, Inki Dae wrote:
> On 2014ë
10ì 07ì¼ 21:01, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Many Exynos DRM drivers uses global variables to represent associated devices
>> in Exynos DRM internal framework. It is quite confusing, it adds data
>> duplication
>> and finally it doe
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/0cadff95/attachment.html>
hout that patch? Passing radeon.audio=0 would do?
--
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/20141113/b4d5c225/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/7d74621c/attachment.html>
We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only be access
CHECK: Alignment should match open parenthesis
+ if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+ (hdmi->vic == 12) || (hdmi->vic == 13) ||
CHECK: braces {} should be used on all arms of this statement
+ if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+ else {
[...]
Sign
drm driver may probe before the i2c bus, so the driver should
defer probing until it is available
Signed-off-by: Andy Yan
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter
Changes in v3: None
Cha
IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.
To reuse the imx
Signed-off-by: Andy Yan
---
Changes in v9: None
Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/drm/bri
Signed-off-by: Andy Yan
---
Changes in v9: None
Changes in v8:
- Add documentation for rockchip dw hdmi
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 +
On 13/11/14 12:57, Andy Yan wrote:
> rk3288 hdmi is compatible with Designware hdmi
>
> this patch is depend on patch by Mark Yao Add drm
> driver for Rockchip Socs
>
> see https://lkml.org/lkml/2014/10/8/201
>
> Signed-off-by: Andy Yan
> Signed-off-by: Yakir Yang
>
> ---
>
> Changes in v9
Hi ZubairLK:
thanks for your review.
On 2014å¹´11æ13æ¥ 21:09, Zubair Lutfullah Kakakhel wrote:
>
> On 13/11/14 12:57, Andy Yan wrote:
>> rk3288 hdmi is compatible with Designware hdmi
>>
>> this patch is depend on patch by Mark Yao Add drm
>> driver for Rockchip Socs
>>
>> see https://lkml.or
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi driver out
to drm/bridge and rename imx-hdmi to dw_hdmi
Signed-off-by: Andy Yan
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes i
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa i-love.sakura.ne.jp> wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
> > deadlock.")
> > changed to
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width accesses (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- move some modification to patch#6
From: Yakir Yang
keep the connector & birdge in dw_hdmi.c, handle encoder
in dw_hdmi-imx.c, as most of the encoder operation are
platform specific such as crtc select and panel format
set
Signed-off-by: Andy Yan
Signed-off-by: Yakir Yang
---
Changes in v9: None
Changes in v8: None
Changes in
rk3288 hdmi is compatible with Designware hdmi
this patch is depend on patch by Mark Yao Add drm
driver for Rockchip Socs
see https://lkml.org/lkml/2014/10/8/201
Signed-off-by: Andy Yan
Signed-off-by: Yakir Yang
---
Changes in v9:
- move some phy configuration to platform driver
Changes in
attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/508a/attachment.sig>
Hi Inki,
This patchset contains various fixes and improvements to exynos_drm
components: mixer, hdmi and crtc.
Patchset is based on exynos-drm-next-todo.
Regards
Andrzej
Andrzej Hajda (7):
drm/exynos/hdmi: fix edid memory leak
drm/exynos/hdmi: fix interrupt clearing
drm/exynos/mixer: cor
edid returned by drm_get_edid should be freed.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 56
Specification advises to clear vsync indicator before configuring vsync.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.
INT_EN cache field was updated only by mixer_enable_vblank.
The patch adds update also by mixer_disable_vblank function.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/driver
The driver used incorrect flags to clear interrupt status.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos
The driver uses bool protected by mutex to track power state.
The patch replaces this combo with single bit and atomic bitops.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 51 ++-
1 file changed, 14 insertions(+), 37 deletions(-)
diff
Driver uses only VSYNC interrupts, so we need to cache VSYNC bit state only.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/e
exynos_drm_crtc_disable_vblank can be called when drm initialization fails.
In such case some structures are not initialized, so the function
should check it. The patch adds necessary checks.
It fixes following Oops:
[1.521834] Unable to handle kernel NULL pointer dereference at virtual
addres
On Thu, Nov 13, 2014 at 08:38:23AM -0800, Andy Lutomirski wrote:
> On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
> >
> > On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > > On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > > > If clwb is available on the system, use it in drm_
On Thu, Nov 13, 2014 at 06:11:33PM +0100, Borislav Petkov wrote:
> On Thu, Nov 13, 2014 at 08:38:23AM -0800, Andy Lutomirski wrote:
> > On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
> > >
> > > On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > > > On 11/11/2014 10:43 AM, Ros
On Thu, Nov 13, 2014 at 07:33:54PM +0200, Ville Syrjälä wrote:
> We use it both ways in i915. So please don't break it.
Haha, we started from Intel with Ross' patch and made a full circle
back. Maybe you guys should talk about it.
LOL. :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate u
On Thu, Nov 13, 2014 at 06:47:34PM +0100, Borislav Petkov wrote:
> On Thu, Nov 13, 2014 at 07:33:54PM +0200, Ville Syrjälä wrote:
> > We use it both ways in i915. So please don't break it.
>
> Haha, we started from Intel with Ross' patch and made a full circle
> back. Maybe you guys should talk
On Thu, Nov 13, 2014 at 07:33:54PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 13, 2014 at 06:11:33PM +0100, Borislav Petkov wrote:
> > On Thu, Nov 13, 2014 at 08:38:23AM -0800, Andy Lutomirski wrote:
> > > On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
> > > >
> > > > On Wed, Nov 12, 2014 at 0
A few of the sprite-related function names in i915 are very similar
(intel_plane_disable() vs intel_disable_plane() or
intel_enable_planes() vs intel_crtc_enable_planes()) and don't make it
clear whether they only operate on sprite planes, or whether they also
apply to all universal plane types. R
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_sprite.c | 16
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
Now that we have hooks to enable the atomic plane helpers, we can use
the plane helpers for our .update_plane() and .disable_plane()
entrypoints.
Even though we'd already refactored our plane handling code into
check/commit, we still have to rework some of that logic here as we make
the transition
We'll want to use this from the atomic plane helpers, so ensure it can
be called outside intel_display.c.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/g
Add the new driver entrypoints that will be called by the atomic plane
helpers.
This patch does not actually switch over to the new plane helpers yet,
so there should be no functional change here. Also note that although
plane programming was already split into check/prepare/commit steps,
some of
The userspace-requested plane coordinates are now stored in
plane->state.base (and the i915-adjusted values are stored in
plane->state), so we no longer use the coordinate fields in intel_plane
or the orig_{src,dst} fields in intel_plane_state. Drop them.
Signed-off-by: Matt Roper
---
drivers/g
This series takes another step along the path to atomic modeset / nuclear
pageflip by transitioning the i915 driver to the new atomic plane helpers
provided by Daniel Vetter in:
http://lists.freedesktop.org/archives/dri-devel/2014-November/071623.html
Previous work by Gustavo Padovan had alread
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/093a5fd9/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141113/44d1e3fd/attachment.html>
We'll want to call this from the type-agnostic atomic plane helper
hooks. Since it's not sprite-specific anymore, more it to
intel_display.c as well.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 21 +
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
dri
On Thu, 13 Nov 2014 10:43:21 -0800
Matt Roper wrote:
> We'll want to call this from the type-agnostic atomic plane helper
> hooks. Since it's not sprite-specific anymore, more it to
> intel_display.c as well.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_display.c | 21
On Thu, Nov 13, 2014 at 11:11:38AM -0800, Bob Paauwe wrote:
> On Thu, 13 Nov 2014 10:43:21 -0800
> Matt Roper wrote:
>
> > We'll want to call this from the type-agnostic atomic plane helper
> > hooks. Since it's not sprite-specific anymore, more it to
> > intel_display.c as well.
> >
> > Signed
On Thu, Nov 13, 2014 at 11:11:38AM -0800, Bob Paauwe wrote:
> On Thu, 13 Nov 2014 10:43:21 -0800
> Matt Roper wrote:
>
> > We'll want to call this from the type-agnostic atomic plane helper
> > hooks. Since it's not sprite-specific anymore, more it to
> > intel_display.c as well.
> >
> > Signed
Hi!
Could we perhaps get an ack from Radeon / Nouveau as well?
Thanks,
Thomas
On 11/12/2014 12:55 PM, Thomas Hellstrom wrote:
> It happens on occasion that developers of generic user-space applications
> abuse the dumb buffer API to get hold of drm buffers that they can both
> mmap() and use fo
On Thu, 13 Nov 2014 11:12:01 -0800
Matt Roper wrote:
> On Thu, Nov 13, 2014 at 11:11:38AM -0800, Bob Paauwe wrote:
> > On Thu, 13 Nov 2014 10:43:21 -0800
> > Matt Roper wrote:
> >
> > > We'll want to call this from the type-agnostic atomic plane helper
> > > hooks. Since it's not sprite-specif
On Thu, 13 Nov 2014 10:43:24 -0800
Matt Roper wrote:
> Add the new driver entrypoints that will be called by the atomic plane
> helpers.
>
> This patch does not actually switch over to the new plane helpers yet,
> so there should be no functional change here. Also note that although
> plane pro
v6: Update entries to reflect new name & location of driver
Signed-off-by: Oded Gabbay
---
CREDITS | 7 +++
MAINTAINERS | 10 ++
2 files changed, 17 insertions(+)
diff --git a/CREDITS b/CREDITS
index bb62788..c56d8aa 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1197,6 +1197,13 @@ S:
Hi,
I'm pleased to announce that AMD has published the full code of the HSA
Runtime library.
The code can be found at:
https://github.com/HSAFoundation/HSA-Runtime-Reference-Source
As I stated in the amdkfd v5 cover letter, this release, coupled with the r600
LLVM back-end, provides a complete u
On Thu, 13 Nov 2014 10:43:20 -0800
Matt Roper wrote:
> Signed-off-by: Matt Roper
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_display.c | 28 ++--
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> drivers/gpu/drm/i915/intel_sprite.c | 16 --
On Thu, 13 Nov 2014 10:43:23 -0800
Matt Roper wrote:
> We'll want to use this from the atomic plane helpers, so ensure it can
> be called outside intel_display.c.
>
> Signed-off-by: Matt Roper
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i91
On Thu, 13 Nov 2014 10:43:22 -0800
Matt Roper wrote:
> A few of the sprite-related function names in i915 are very similar
> (intel_plane_disable() vs intel_disable_plane() or
> intel_enable_planes() vs intel_crtc_enable_planes()) and don't make it
> clear whether they only operate on sprite plan
On Thu, 13 Nov 2014 10:43:25 -0800
Matt Roper wrote:
> Now that we have hooks to enable the atomic plane helpers, we can use
> the plane helpers for our .update_plane() and .disable_plane()
> entrypoints.
>
> Even though we'd already refactored our plane handling code into
> check/commit, we sti
On Thu, 13 Nov 2014 10:43:26 -0800
Matt Roper wrote:
> The userspace-requested plane coordinates are now stored in
> plane->state.base (and the i915-adjusted values are stored in
> plane->state), so we no longer use the coordinate fields in intel_plane
> or the orig_{src,dst} fields in intel_plan
On Thu, Nov 13, 2014 at 11:46:25AM -0800, Bob Paauwe wrote:
> On Thu, 13 Nov 2014 10:43:24 -0800
> Matt Roper wrote:
...
> > +
> > +/**
> > + * intel_plane_destroy_state - destroy plane state
> > + * @plane: drm plane
> > + *
> > + * Allocates and returns a copy of the plane state (both common and
On Thu, Nov 13, 2014 at 09:23:02PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 13, 2014 at 11:11:38AM -0800, Bob Paauwe wrote:
> > On Thu, 13 Nov 2014 10:43:21 -0800
> > Matt Roper wrote:
> >
> > > We'll want to call this from the type-agnostic atomic plane helper
> > > hooks. Since it's not spr
Add the new driver entrypoints that will be called by the atomic plane
helpers.
This patch does not actually switch over to the new plane helpers yet,
so there should be no functional change here. Also note that although
plane programming was already split into check/prepare/commit steps,
some of
Now that we have hooks to enable the atomic plane helpers, we can use
the plane helpers for our .update_plane() and .disable_plane()
entrypoints.
Even though we'd already refactored our plane handling code into
check/commit, we still have to rework some of that logic here as we make
the transition
Signed-off-by: Matt Roper
---
Documentation/DocBook/drm.tmpl| 5 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 10 ++
2 files changed, 15 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9449cd6..fefee7d 100644
--- a/Docume
On Thu, Nov 13, 2014 at 02:51:32PM -0800, Matt Roper wrote:
> Add the new driver entrypoints that will be called by the atomic plane
> helpers.
>
> This patch does not actually switch over to the new plane helpers yet,
> so there should be no functional change here. Also note that although
> plan
On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
>
> On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > > If clwb is available on the system, use it in drm_clflush_virt_range.
> > > If clwb is not available, fall back to clflushopt
On Wed, 2014-11-12 at 15:12 +0100, Borislav Petkov wrote:
> On Wed, Nov 12, 2014 at 01:38:45PM +, Anvin, H Peter wrote:
> > No, it doesn't. x86 requires 3.4+ at a minimum.
>
> The only test I see is:
>
> #if GCC_VERSION < 30200
> # error Sorry, your compiler is too old - please upgrade it.
>
re you using any special i915 cmdline options?
Nope.
Thanks a lot,
Emmanuel
-- next part --
A non-text attachment was scrubbed...
Name: kernel_bad.tar.xz
Type: application/octet-stream
Size: 16184 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dr
On Fri, 14 Nov 2014 05:09:55 +0400
Andrey Utkin wrote:
> There's no such thing as "list_struct".
I guess there isn't.
>
> Signed-off-by: Andrey Utkin
Acked-by: Steven Rostedt
-- Steve
> ---
> drivers/gpu/drm/radeon/mkregtable.c | 24
> drivers/media/pci/cx18/cx1
97 matches
Mail list logo
