This is MT2701 DRM support RFC v3, based on 4.7-rc1.
Most codes are the same, except some register changed.
For example:
- DISP_OVL address offset changed, color format definition changed.
- DISP_RDMA fifo size changed.
- DISP_COLOR offset changed.
We add a new component DISP_BLS, and the conn
Add MT8173 prefix for hardware related macros.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 60
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT Shen
---
drivers/gpu/drm/media
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6
drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 42 +
This patch adds the device nodes for the DISP function blocks for MT2701
Signed-off-by: YT Shen
---
arch/arm/boot/dts/mt2701.dtsi | 106 +
1 file changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index
Hi Daniel,
Thank you for the patch.
On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote:
> Rockchip just blew up here on testing, because I removed some "is this
> crtc already disabled/enabled" state tracking from callbacks (not needed
> with atomic). Turns out that was needed to work around r
Hi Javier,
2016ë
06ì 02ì¼ 23:20ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
> hardware trigger support to the FIMD controller driver. But this broke
> the display in at least the Exynos5800 Peach Pi Chromebook.
>
> So
Hello,
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to access
more than a single parameter of the format, leading to inefficiencies due
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Cc: Rob Clark
Cc: linux-arm-msm
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Cc: Liviu Dudau
diff --git a/drivers/gpu
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
In the tilcdc_crtc_mode_set() function compute the hardware register
value directly from the pixel format instead of computing the number of
bits per pixels first.
Signed-o
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to mult
Turn the drm_format_*() helpers into wrappers around the drm_format_info
lookup function to centralize all format information in a single place.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fourcc.c | 180 ---
1 file changed, 34 insertions(+), 1
Replace calls to the drm_format_*() helper functions with direct use of
the drm_format_info structure. This improves efficiency by removing
duplicate lookups.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 100 +---
drivers/gpu/drm/drm_f
The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.
The
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/sti/sti_gdp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Cc: Benjamin Gaignard
Cc: Vincent Abriou
The driver doesn't need the color depth, only the number of bits per
pixel. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +++---
drivers/gpu/drm/cirrus/cirrus_main.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
Cc: Dave Airlie
The driver uses drm_fb_get_bpp_depth() to check whether it can support
the format requested by userspace when creating a framebuffer. This
isn't the right API, as it doesn't differentiate between RGB formats
other than on a depth and bpp basis.
Fixing this requires non trivial changes to the drive
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
2 files changed, 7 insertion
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/radeon/radeon_fb.c | 14 +++---
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
2 files changed, 9 insertions(+)
The driver is the last users of the drm_fb_get_bpp_depth() function. It
should ideally be converted to use struct drm_mode_fb_cmd2 instead of
the legacy struct drm_mode_fb_cmd internally, but that will require
broad changes across the code base. As a first step, replace
drm_fb_get_bpp_depth() with
The function is only used by the drm_helper_mode_fill_fb_struct() core
function to fill the drm_framebuffer bpp and depth fields, used by
drivers that haven't been converted to use pixel formats directly yet.
It should not be used by new drivers, so inline it in its only caller.
Signed-off-by: Lau
The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/gpu.tmpl | 5 +
drivers/gpu/drm/Makefile | 2 +-
drivers
Hello,
(Repost with the drivers maintainers CC'ed, sorry about the noise)
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to access
more
The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/gpu.tmpl | 5 +
drivers/gpu/drm/Makefile | 2 +-
drivers
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to mult
Turn the drm_format_*() helpers into wrappers around the drm_format_info
lookup function to centralize all format information in a single place.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fourcc.c | 180 ---
1 file changed, 34 insertions(+), 1
Replace calls to the drm_format_*() helper functions with direct use of
the drm_format_info structure. This improves efficiency by removing
duplicate lookups.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 100 +---
drivers/gpu/drm/drm_f
The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.
The
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Cc: Rob Clark
Cc: linux-arm-msm
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/sti/sti_gdp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Cc: Benjamin Gaignard
Cc: Vincent Abriou
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Cc: Liviu Dudau
diff --git a/drivers/gpu
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
In the tilcdc_crtc_mode_set() function compute the hardware register
value directly from the pixel format instead of computing the number of
bits per pixels first.
Signed-o
The driver doesn't need the color depth, only the number of bits per
pixel. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +++---
drivers/gpu/drm/cirrus/cirrus_main.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
Cc: Dave Airlie
The driver uses drm_fb_get_bpp_depth() to check whether it can support
the format requested by userspace when creating a framebuffer. This
isn't the right API, as it doesn't differentiate between RGB formats
other than on a depth and bpp basis.
Fixing this requires non trivial changes to the drive
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
2 files changed, 7 insertion
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/radeon/radeon_fb.c | 14 +++---
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
2 files changed, 9 insertions(+)
The driver is the last users of the drm_fb_get_bpp_depth() function. It
should ideally be converted to use struct drm_mode_fb_cmd2 instead of
the legacy struct drm_mode_fb_cmd internally, but that will require
broad changes across the code base. As a first step, replace
drm_fb_get_bpp_depth() with
The function is only used by the drm_helper_mode_fill_fb_struct() core
function to fill the drm_framebuffer bpp and depth fields, used by
drivers that haven't been converted to use pixel formats directly yet.
It should not be used by new drivers, so inline it in its only caller.
Signed-off-by: Lau
On 09.06.2016 08:32, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 10 +-
> drivers/gpu/drm/amd
c_minimal.so:${LD_PRELOAD}"
export LD_PRELOAD
#fi
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/6dfec10c/attachment.html>
Hi Boris,
On 6/8/2016 6:00 PM, Boris Brezillon wrote:
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
>
> Signed-off-by: Boris Brezillon
> Tested-by: Nicolas Ferre
> ---
> Hi Archit,
>
> I recently learned you were the drm/bridge maintaine
ping ?
2016-05-13 8:29 GMT+02:00 Mathieu Malaterre :
> AGP mode is unstable on PowerPC
>
> Signed-off-by: Mathieu Malaterre
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv
On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
> runtime pm ref leaks.
>
> Patches 1 to 8 are identical to v1.
>
> Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver
> unload. Based on feedback
On 06/09/2016 01:32 AM, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/sti/sti_gdp.c | 6 +++---
> 1 file changed, 3 insertions(
On Mon, Jun 06, 2016 at 04:29:04PM +0300, Mika Kahola wrote:
> Read DisplayPort downstream port capabilities. Depending on
> the DP port the capabilities are defined in length of 1 byte
> or 4 bytes depending if the detailed capability information is
> available.
>
> Signed-off-by: Mika Kahola
>
Hi Archit,
On Thu, 9 Jun 2016 12:15:00 +0530
Archit Taneja wrote:
> Hi Boris,
>
> On 6/8/2016 6:00 PM, Boris Brezillon wrote:
> > Add basic support for the sii902x RGB -> HDMI bridge.
> > This driver does not support audio output yet.
> >
> > Signed-off-by: Boris Brezillon
> > Tested-by: Nicol
On Mon, Jun 06, 2016 at 04:29:05PM +0300, Mika Kahola wrote:
> Helper routine to read out DisplayPort branch device type. The spec
> defines these type as following
>
> 0 DisplayPort
> 1 Analog VGA
> 2 DVI
> 3 HDMI
> 4 Others without EDID support
> 5
On Mon, Jun 06, 2016 at 04:29:06PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported pixel rate
> for DisplayPort legay VGA converter or TMDS clock rate
> for other digital legacy converters. The helper returns
> clock rate in kHz.
>
> Signed-off-by: Mika Kahola
> ---
> dr
On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported bits per
> component for DisplayPort legay converters.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 31 +++
> include/drm/drm_dp_hel
On Mon, Jun 06, 2016 at 04:29:11PM +0300, Mika Kahola wrote:
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The regist
On Wed, Jun 08, 2016 at 10:45:34PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jun 08, 2016 at 04:07:59PM -0300, Gustavo Padovan wrote:
> > Hi Greg,
> >
> > Any comment on this?
>
> I am just starting to catch up on patches, please give me some time,
> staging patches are at the bottom of my prior
On Thu, Jun 09, 2016 at 01:36:30AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote:
> > Rockchip just blew up here on testing, because I removed some "is this
> > crtc already disabled/enabled" state tracking from
On Thu, Jun 09, 2016 at 02:32:05AM +0300, Laurent Pinchart wrote:
> The drm_crtc.c file is a mess, making the ABI documentation confusing
> since all functions are in the same bag. Split the format-related
> helpers to a new drm_fourcc.c file.
>
> Signed-off-by: Laurent Pinchart
> ---
> Document
On Thu, Jun 09, 2016 at 02:32:06AM +0300, Laurent Pinchart wrote:
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to
> access more th
In order to handle devices that need to use the adapter prior to it
being registered with the system, we first need to split out the
initialisation of the adapter out of i2c_register_adapter.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Wolfram Sang
Cc: linux-i2c at vger.kernel.org
Cc: l
In order to allow drivers to call i2c_init_adapter as a separate step,
and to allow other drivers to continue skipping the call, mark the
adapter as initialised upon i2c_init_adapter() and ignore multiple
calls.
The choice of how to introduce an "already-initialised" check into the
existing i2c_ad
Some drivers require use of their i2c adapter long before they can add
the adapter to userspace (i.e. before they establish and expose their
objects in the sysfs kobject tree). Currently i2c_add_adapter()
registers the adapter with userspace, which causes a conflict in the
ordering of the driver's
On Thu, Jun 09, 2016 at 02:32:12AM +0300, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
> 1 file chan
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> Just a bit of drive-by ocd.
>
> v2: Improve per Liviu's feedback.
>
> Cc: Liviu Dudau
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_atomic.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/drm/drm_atomic.h b/incl
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> atomic_flush seems to be the right place, right after we commit the
> plane updates. Again use the fullproof version, since the pipe might
> be off.
>
> Cc: Boris Brezillon
> Cc: Maxime Ripard
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/s
Hi Vincent,
On Thursday 09 Jun 2016 09:52:05 Vincent ABRIOU wrote:
> On 06/09/2016 01:32 AM, Laurent Pinchart wrote:
> > The driver needs the number of bytes per pixel, not the bpp and depth
> > info meant for fbdev compatibility. Use the right API.
> >
> > Signed-off-by: Laurent Pinchart
> > --
Hi Michel,
On Thursday 09 Jun 2016 10:42:54 Michel Dänzer wrote:
> On 09.06.2016 08:32, Laurent Pinchart wrote:
> > The driver needs the number of bytes per pixel, not the bpp and depth
> > info meant for fbdev compatibility. Use the right API.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/3fbeae6a/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/064258c6/attachment-0001.html>
The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/gpu.tmpl | 5 +
drivers/gpu/drm/Makefile | 2 +-
drivers
On Thu, Jun 09, 2016 at 12:54:08PM +0300, Laurent Pinchart wrote:
> The drm_crtc.c file is a mess, making the ABI documentation confusing
> since all functions are in the same bag. Split the format-related
> helpers to a new drm_fourcc.c file.
>
> Signed-off-by: Laurent Pinchart
Applied to drm-m
On Wed, Jun 08, 2016 at 02:19:00PM +0200, Daniel Vetter wrote:
> Split out from my big nonblocking atomic commit helper code as prep
> work. While add it, also add some neat asciiart to document how it's
> supposed to be used.
>
> v2: Resurrect misplaced hunk in the kerneldoc.
>
> Tested-by: Tome
of Dying Light use core profile.
Anyway i think this is not mesa bug.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
Hi Daniel,
On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> >
> > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > >
> > > The drm core has a nice ready-made helper for exactly the simple case
> > > where it should fire
Hi David
ping ?
> These removes unneeded error message from Renesas DU driver.
> Current this unneeded error message makes user confuse.
>
> Kuninori Morimoto (2):
> drm: rcar-du: error message is not needed for drm_vblank_init()
> drm: rcar-du: error message is not needed for EPROB
On Thu, 2016-06-09 at 11:02 +0300, Ville Syrjälä wrote:
> On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> > Helper routine to read out maximum supported bits per
> > component for DisplayPort legay converters.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/drm_dp
Provide a small convenience wrapper that set/get the
display brightness value
Cc: John Stultz
Cc: Sumit Semwal
Cc: Archit Taneja
Cc: Rob Clark
Cc: Jani Nikula
Signed-off-by: Vinay Simha BN
--
v1:
*tested in nexus7 2nd gen.
v2:
* implemented jani review comments
-functions name mapped
* Peter Ujfalusi [160607 06:41]:
> Hi Tony, Tomi
>
> as you have requested I have created the immutable branch containing the
> mach-omap2 touching patches only from the omapdss header cleanup.
>
> As I have mentioned in the v3 cover letter I have the other branch
> containing the whole series:
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Thursday, June 9, 2016 11:14 AM
> To: Kahola, Mika
> Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
> jim.bride at linux.intel.com; daniel.vetter at ffwll.ch
> Subj
es
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/ec488bc4/attachment-0001.obj>
drivers/gpu/drm/i915/i915_irq.c:2688: warning: No description found for
parameter 'dev_priv'
drivers/gpu/drm/i915/i915_irq.c:2688: warning: No description found for
parameter 'fmt'
drivers/gpu/drm/i915/i915_irq.c:2688: warning: Excess function parameter
'dev&#
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Bug ID: 119861
Summary: Kernel BUG() when Xorg server is started
Product: Drivers
Version: 2.5
Kernel Version: 4.7-rc2
Hardware: x86-64
OS: Linux
Tree: Mainli
https://bugzilla.kernel.org/show_bug.cgi?id=119861
--- Comment #1 from Dmitrii Tcvetkov ---
Created attachment 219401
--> https://bugzilla.kernel.org/attachment.cgi?id=219401&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119861
--- Comment #2 from Dmitrii Tcvetkov ---
Created attachment 219411
--> https://bugzilla.kernel.org/attachment.cgi?id=219411&action=edit
Xorg.conf
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Dmitrii Tcvetkov changed:
What|Removed |Added
Attachment #219391|application/octet-stream|text/plain
mime type|
Hi Laurent,
On 06/09/2016 11:17 AM, Laurent Pinchart wrote:
> Hi Vincent,
>
> On Thursday 09 Jun 2016 09:52:05 Vincent ABRIOU wrote:
>> On 06/09/2016 01:32 AM, Laurent Pinchart wrote:
>>> The driver needs the number of bytes per pixel, not the bpp and depth
>>> info meant for fbdev compatibility.
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Dmitrii Tcvetkov changed:
What|Removed |Added
Summary|Kernel BUG() when Xorg |Kernel BUG() when Xorg
https://bugzilla.kernel.org/show_bug.cgi?id=119861
--- Comment #3 from Dmitrii Tcvetkov ---
Created attachment 219421
--> https://bugzilla.kernel.org/attachment.cgi?id=219421&action=edit
kernel config
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=119861
Dmitrii Tcvetkov changed:
What|Removed |Added
Attachment #219421|application/octet-stream|text/plain
mime type|
On Thu, Jun 09, 2016 at 10:52:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 02:32:06AM +0300, Laurent Pinchart wrote:
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across different helper
> > functions in
On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > >
> > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > >
> > > > The drm core has
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/cc4e8c74/attachment.html>
On Thu, Jun 09, 2016 at 03:23:17PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 09, 2016 at 10:52:23AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 02:32:06AM +0300, Laurent Pinchart wrote:
> > > Various pieces of information about DRM formats (number of planes, color
> > > depth, chroma
On Thu, Jun 09, 2016 at 02:40:28PM +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 03:23:17PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 09, 2016 at 10:52:23AM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 09, 2016 at 02:32:06AM +0300, Laurent Pinchart wrote:
> > > > Various pieces of info
On Thu, Jun 09, 2016 at 12:48:31PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
On Thu, Jun 09, 2016 at 04:05:11PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 09, 2016 at 02:40:28PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 03:23:17PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 09, 2016 at 10:52:23AM +0200, Daniel Vetter wrote:
> > > > On Thu, Jun 09, 2016 at
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/77ae00a6/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160609/de4cb8e6/attachment.html>
On Thu, Jun 09, 2016 at 01:27:55PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Thu, 2016-06-09 at 15:23 +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 12:48:31PM +, Alexey Brodkin wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
On 9 June 2016 at 13:53, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 10:45:34PM -0700, Greg Kroah-Hartman wrote:
>> On Wed, Jun 08, 2016 at 04:07:59PM -0300, Gustavo Padovan wrote:
>> > Hi Greg,
>> >
>> > Any comment on this?
>>
>> I am just starting to catch up on patches, please give me some
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> Right now still all blocking, no worker anywhere to be seen.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Maarten Lankhorst
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> Simply split intel_atomic_commit in half and place the new
> nonblocking commit helpers at the right spots.
>
> NOTE: There's still trouble with obj->frontbuffer bits getting mangled
> when pipelining atomic commits.
>
> v2:
> - Remove the check for non
From: Alex Xie
Add comment to describe some variables otherwise.
Signed-off-by: Alex Xie
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a
1 - 100 of 156 matches
Mail list logo
