Hi Marek,
2015-12-11 20:27 GMT+09:00 Marek Szyprowski :
> Hi Inki,
>
>
> On 2015-12-11 10:57, Inki Dae wrote:
>>
>> Hi Marek,
>>
>> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>>
>>> Hi Inki,
>>>
>>> On 2015-12-11 10:02, Inki Dae wrote:
Hi Marek,
I found ou
hader code size which is likely too
short for a lot of shaders...]
--
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/2015
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/bdcba369/attachment.html>
/GRID\
Autosport/bin/GridAutosport 2>| cat - >
/home/juergen/gridAutosport_console(date +%Y%m%d-%H%M%S).txt
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedeskt
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/f20dc31d/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/ea2489dd/attachment.html>
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/9ed7afb6/attachment.html>
Hi Dave,
drm-intel-next-2015-12-04-1:
This is the "fix igt basic test set issues" edition.
- more PSR fixes from Rodrigo, getting closer
- tons of fifo underrun fixes from Ville
- runtime pm fixes from Imre, Daniel Stone
- fix SDE interrupt handling properly (Jani Nikula)
- hsw/bdw fdi modeset seq
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/1b9d71a6/attachment-0001.html>
Hi Marek,
2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 2015-12-11 10:02, Inki Dae wrote:
>> Hi Marek,
>>
>> I found out why NULL point access happened. That was incurred by below your
>> patch,
>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane
On Wed, Dec 09, 2015 at 04:20:10PM -0500, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
>
> v2: don't try to hexdump the universe if driver returns -errno, and
> change the "too many retries" traces to DRM_ERROR()
>
> Signed-
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/51fd3f1c/attachment.html>
On Wed, Dec 09, 2015 at 04:20:09PM -0500, Rob Clark wrote:
Something small missing here perhaps. The patch subject is not part
of the commit message body.
> 1) don't let other threads trying to bang on aux channel interrupt the
> defer timeout/logic
> 2) don't let other threads interrupt the i2c
Hi Matthias,
thanks for your reply. It would be helpful if you could trim the quoted
text a bit when replying to a small part of a huge patch like this.
Am Freitag, den 11.12.2015, 18:10 +0100 schrieb Matthias Brugger:
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm
On 30/11/15 22:07, Philipp Zabel wrote:
> From: CK Hu
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
>
> Signed-off-by: CK Hu
> Signed-off-by: Y
2015ë
12ì 10ì¼ 21:59ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hello,
>
> On 2015-12-10 12:35, Inki Dae wrote:
>> Hi Marek,
>>
>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>> This patch fixes trashed display of buffers cropped to very small width.
>>> Even if DMA is uns
Hi Marek,
I found out why NULL point access happened. That was incurred by below your
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the pla
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/5cd5ebe7/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/9564a2ac/attachment.html>
On Fri, Dec 11, 2015 at 05:15:40PM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 10:02:45AM +, Russell King - ARM Linux wrote:
> > On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if
> > > people would li
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/d9e1f683/attachment-0001.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/e174350b/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/7b6eea2b/attachment.html>
On Fri, Dec 11, 2015 at 10:02:45AM +, Russell King - ARM Linux wrote:
> On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if
> > people would like these in now, also anything I've missed on the list.
>
> I would de
On Fri, Dec 11, 2015 at 01:58:59PM +0100, LABBE Corentin wrote:
> My latest commit introduce some case where a valid mode, could be
> rejected.
> simple_strtox functions stop at first non-digit character, but kstrtox
> not.
> So args like "video=HDMI-A-1:720x480-16 at 60" will be reject when checki
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/4e2e15cd/attachment.html>
On 12/11/2015 01:27 PM, Tomi Valkeinen wrote:
>
> On 11/12/15 08:14, Archit Taneja wrote:
>
>> Is it possible to make omapfb get some of the old files (apply.c,
>> overlay.c, manager.c, sysfs files etc)? It might be helpful to have git
>> associate these files with omapfb/omap_vout since they hav
/linux/x86_64/clone.S:109
--
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/20151211/90e94079/attachment-0001.html>
Hey all,
Hopefully all my sub-maintainers are awake and reading this.
So since Xmas is coming up and I've got an impending new arrival, I'm
betting this merge window might get a bit haphazard. So I'd like
people to start telling me now via git pull's what they'd like to get
in.
I've seen etnaviv
.so[7fc131919000+931000]
I will try to get a backtrace with gdb.
--
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/20151211/af
644 include/uapi/drm/vc4_drm.h
[ signature.asc: application/pgp-signature ]
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attach
Hi Dave,
2015ë
12ì 11ì¼ 15:58ì Dave Airlie ì´(ê°) ì´ ê¸:
> Hey all,
>
> Hopefully all my sub-maintainers are awake and reading this.
>
> So since Xmas is coming up and I've got an impending new arrival, I'm
> betting this merge window might get a bit haphazard. So I'd like
> people to
iving 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/20151211/67c1ac4b/attachment.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/8b579b43/attachment.html>
On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> Hey all,
Hi Dave,
>
> Hopefully all my sub-maintainers are awake and reading this.
>
> So since Xmas is coming up and I've got an impending new arrival, I'm
> betting this merge window might get a bit haphazard. So I'd like
> people
On Wed, 25 Nov 2015 18:07:59 +0100
Daniel Vetter wrote:
> Unfortunately the entire improved docbook project died at KS in a
> massive bikeshed. So we need to carry this around in drm private trees
> forever :(
I don't think that's an entirely helpful way to look at things, honestly.
Changing how
Update MAINTAINERS file for HDLCD driver.
Cc: Greg KH
Cc: Andrew Morton
Cc: Mauro Carvalho Chehab
Cc: David S. Miller
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cba790b..4208dae 100644
--- a/MAINTAINER
ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.
Signed-off-by: Liviu Dudau
Acked-by: Sudeep Holla
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +++---
1 file ch
The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.
Cc: David Airlie
Cc: Robin Murphy
Signed-off-by: Liviu Dudau
Acked-by: Daniel
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display
This series adds support for ARM's HDLCD display controller found in Juno
and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a
single digital encoder (DVI or HDMI).
Most of the dependencies for this patch series are now queued for the next
release or are already in the mainline.
On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> This adds the device nodes for 2D, 3D and VG GPU cores.
>
> Signed-off-by: Russell King
> Signed-off-by: Lucas Stach
> ---
> arch/arm/boot/dts/imx6dl.dtsi | 5 +
> arch/arm/boot/dts/imx6q.dtsi | 15 +++
> arch/ar
On 11.12.2015 14:37, Julia Lawall wrote:
> The ttm_backend_func structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Christian König
>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
> driver
The ttm_backend_func structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |2 +-
drivers/gpu/drm/ast/ast_ttm.c |2 +-
drivers/gpu/drm/bochs/bochs_mm.c|2 +
On 2015å¹´12æ02æ¥ 22:18, Daniel Stone wrote:
> Hi Mark,
> Thanks for getting back to this.
>
> On 1 December 2015 at 09:31, Mark yao wrote:
>> On 2015å¹´12æ01æ¥ 16:18, Daniel Stone wrote:
>>> On 1 December 2015 at 03:26, Mark Yao wrote:
> + for_each_crtc_in_state(state, crtc, crtc
My latest commit introduce some case where a valid mode, could be
rejected.
simple_strtox functions stop at first non-digit character, but kstrtox
not.
So args like "video=HDMI-A-1:720x480-16 at 60" will be reject when checking
16 at .
Discussions about this change comes to the conclusion that the
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
--- a/
ri-devel/attachments/20151211/b3f7ec3c/attachment.html>
Linus's tree
(0bd0f1e6d40aa16c4d507b1fff27163a7e7711f5) I'm not sure if it's related
--
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/20151211/232af207/attachment.html>
Hi Inki,
On 2015-12-11 10:57, Inki Dae wrote:
> Hi Marek,
>
> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>> Hi Inki,
>>
>> On 2015-12-11 10:02, Inki Dae wrote:
>>> Hi Marek,
>>>
>>> I found out why NULL point access happened. That was incurred by below your
>>> patch,
>>> [PA
Hi Dave -
Here are some i915 fixes for v4.4, sorry for being late this week.
BR,
Jani.
The following changes since commit 527e9316f8ec44bd53d90fb9f611fa752bb9:
Linux 4.4-rc4 (2015-12-06 15:43:12 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel ta
On 12/10/2015 07:55 PM, Tomi Valkeinen wrote:
> Hi,
>
> Here's an RFC series to fix the mess we have at the moment with
> omapdrm/omapfb/omapdss.
>
> First, a short background on the current status. We have the following
> entities:
>
> * omapdss, located in drivers/video/fbdev/omap2/dss/. This i
The following code pattern exists in some DRM drivers:
ddev = drm_dev_alloc(&driver, parent_dev);
drm_dev_set_unique(ddev, dev_name(parent_dev));
(Sometimes dev_name(ddev->dev) is used, which is the same.)
As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/0964
drm_dev_set_unique() uses a format string to define the unique name of a
device. This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().
Even though this second kind of call does not introduce security
problems, because t
Hi Inki,
On 2015-12-11 10:02, Inki Dae wrote:
> Hi Marek,
>
> I found out why NULL point access happened. That was incurred by below your
> patch,
> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>
> When another crtc driver is hotplugged in runtime such as HDMI or VID
On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if
> people would like these in now, also anything I've missed on the list.
I would definitely like to see etnaviv make it in for the next merge
window, but that depends
n-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/e1faa44e/attachment.sig>
On Thu, Dec 10, 2015 at 11:13:56PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> IMO the override_edid should override any default EDID for the
> connector, whether that came in via the connector helper ->get_modes()
> vfunc or via the firmware EDID mechanism.
>
> C
On Thu, Dec 03, 2015 at 11:14:08PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Turns out I broke mode pruning when the connector mode lists changes
> without the connector getting disconnected in between. Mostly a problem
> for i-g-t EDID forcing stuff I suppose, b
On Tue, Dec 08, 2015 at 06:41:54PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Show a sensible name for the plane in debug mesages. The driver
> may supply its own name, otherwise the core genrates the name
> ("plane-0", "plane-1" etc.).
>
> v2: kstrdup() the name
On Wed, Dec 09, 2015 at 12:52:58AM +0100, Nicolas Iooss wrote:
> On 12/09/2015 12:28 AM, Emil Velikov wrote:
> > On 8 December 2015 at 22:12, Nicolas Iooss
> > wrote:
> >> drm_dev_set_unique() uses a format string to define the unique name of a
> >> device. This feature is not used as currently
Hi Linus,
Not too much this time.
One nouveau workaround extended to a few more GPUs.
Some amdgpu big endian fixes, and a regression fixer.
Some vmwgfx fixes
One ttm locking fix.
One vgaarb fix.
Dave.
The following changes since commit aa53685549a2cfb5f175b0c4a20bc9aa1e5a1b85:
Merge branch
rnel: Fixing recursive fault but reboot is needed!
-- Reboot --
--
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/20151211/c32049bb/attachment-0001.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/14f76293/attachment.html>
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/b67ecc5a/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151211/10e7e9f4/attachment.html>
66 matches
Mail list logo
