Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On 06/16/2013 07:57 AM, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and
cried.
Fixing up the console_lock mess around the fbdev notifier will be real work,
Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this email
is to share what we have to do so that other guys can be involved without
duplicated work.
1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
Hi all,
So I've taken a look again at the locking mess in our fbdev support and
cried.
Fixing up the console_lock mess around the fbdev
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
This macro doesn't need a semi-colon.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5cc7c0..592b0eb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,7 +1773,7
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, June 18, 2013 5:43 PM
To: Inki Dae
Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote:
This macro doesn't need a semi-colon.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Queued for -next, thanks for the patch.
-Daniel
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
Hi Mr. Dae,
Related to HDMI sound support in Alsa, I have posted a working RFC
exynos-hdmi to CDF complaint display driver. It registers a separate
sound card by registering hdmi audio codec dai and cpu-dai, as you
mentioned. But there is a problem with this approach that I2S being the
single cpu
Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
[...]
a display device driver. It shouldn't be used within a single driver
as a means of passing buffers between userspace and kernel space.
What I try to do is not really such ugly thing. What I try to do is to
notify that,
Thanks all,
On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote:
Hello Kishon,
On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
-Original Message-
From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid
On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks
Ville Syrjälä wrote:
On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio
On Mon, Jun 17, 2013 at 11:04:59PM +0200, Paul Bolle wrote:
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
That has already been fixed in linux-next.
This header was added in v3.10-rc1. The fix in linux-next will ship in
v3.11. Isn't that fix appropriate for (one of) the upcoming
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, June 18, 2013 5:43 PM
To: Inki Dae
Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
list'; 'Rob
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import() not to
Thanks Mr. Dae,
Please discard the REST of the patches in this series. I am posting a
another patch-set which has all the patches independent of hdmiphy
related changes.
regards,
Rahul Sharma.
On Mon, Jun 17, 2013 at 8:22 AM, Inki Dae inki@samsung.com wrote:
Applied.
Thanks,
Inki Dae
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #68 from Alex Deucher ag...@yahoo.com ---
Trig functions need slightly different setup on r6xx and r7xx+. See
tgsi_setup_trig() in r600_shader.c:
/*
* r600 - trunc to -PI..PI range
* r700 - normalize by dividing by 2PI
* see fdo
Hi,
On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
Thanks all,
On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote:
Hello Kishon,
On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
-Original
Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.
This set doesn't have changes for hdmiphy, which will posted
independently.
This set is based on drm-next branch of Inki Dae's tree at
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +
drivers/gpu/drm/exynos/regs-mixer.h |7 +
2 files changed, 44 insertions(+), 12
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.
Signed-off-by: Rahul Sharma
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/cros5250-common.dtsi
With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).
Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #69 from Marc Dietrich marvi...@gmx.de ---
I mean it cannot find the intrinsic at all:
# ./Release/bin/llc test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=r600
LLVM ERROR: Cannot select: 0x8a5570: f32 = fsin 0x8a5670 [ORD=2] [ID=3]
https://bugs.freedesktop.org/show_bug.cgi?id=65873
--- Comment #3 from Tom Stellard tstel...@gmail.com ---
These patches should fix the issue:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130617/178156.html
The first patch is unrelated to the bug, but it is required in order to
Checking up on this patch from a few months back that I'd like to get
included.. Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2].
However ajax has not yet provided comments. Is this SOL without feedback
from ajax?
[1]
https://bugs.freedesktop.org/show_bug.cgi?id=65822
Tom Stellard tstel...@gmail.com changed:
What|Removed |Added
Attachment #80967|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=65873
--- Comment #4 from Aaron Watry awa...@gmail.com ---
The good news is that the store error is gone...
Now I get a load error :/
LLVM ERROR: Cannot select: 0x2c92af0: i64,ch = load 0x21fe0c8, 0x2c924f0,
0x2c921f0LD4[undef](align=8), zext from
https://bugs.freedesktop.org/show_bug.cgi?id=65873
Aaron Watry awa...@gmail.com changed:
What|Removed |Added
Attachment #80971|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=65873
Aaron Watry awa...@gmail.com changed:
What|Removed |Added
Attachment #80972|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #70 from vincent v...@ovi.com ---
Created attachment 81040
-- https://bugs.freedesktop.org/attachment.cgi?id=81040action=edit
Add a cos/sin pattern
Andy, does current master work on your rv790 and Unigine ?
Marc, can you try the
https://bugs.freedesktop.org/show_bug.cgi?id=65822
--- Comment #5 from Aaron Watry awa...@gmail.com ---
Ack! You're right. I'm so used to the output being arg 0 from every other
piglit test that I neglected to check these.
With that and the index multiplier changed, these tests also pass on
Hi Joonyoung,
On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
Hi,
GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
dma_buf. We can use prime helpers for dma_buf by commit
89177644a7b6306e6084a89eab7e290f4bfef397 drm: add prime helpers, so
this patchset is
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #71 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #70)
Andy, does current master work on your rv790 and Unigine ?
Yes, Heaven 3.0 is working for me on master.
--
You are receiving this mail because:
You are the
Hello Adam,
Ping ?
Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
get_modes operation that just returns 0 ?
On Friday 14 June 2013 16:03:19 Daniel Vetter wrote:
On Fri, Jun 14, 2013 at 02:54:04AM +0200, Laurent Pinchart wrote:
On Friday 07 June 2013 10:50:55
On Tue, Jun 18, 2013 at 6:18 PM, Benoit Parrot bpar...@ti.com wrote:
The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in
On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of
Hi Ville,
On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
Hello,
On Wednesday 08 May 2013 15:52:10 Laurent Pinchart wrote:
On Wednesday 08 May 2013 16:40:54 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly.
The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/gpu/drm/drm_prime.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Ville,
On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The structures and strings involved with various pretty-print functions
On Wed, Jun 19, 2013 at 11:14 AM, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
(this
On 06/19/2013 08:02 AM, Laurent Pinchart wrote:
Hi Joonyoung,
On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
Hi,
GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
dma_buf. We can use prime helpers for dma_buf by commit
89177644a7b6306e6084a89eab7e290f4bfef397
https://bugs.freedesktop.org/show_bug.cgi?id=64913
--- Comment #13 from Krzysztof A. Sobiecki sob...@gmail.com ---
Is someone interested in this patch?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
+ mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.
This set is based on
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Tuesday, June 18, 2013 6:46 PM
To: Inki Dae
Cc: linux-samsung-...@vger.kernel.org; DRI mailing list
Subject: Re: exynos-drm-next todo work.
Hi Mr. Dae,
Related to HDMI sound support in Alsa, I have
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.
Required properties:
- compatible: value should be:
1) samsung,exynos4210-mixer
2)
Sure Seung-Woo,
I will update binding document along with this patch.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 10:54 AM, 김승우 sw0312@samsung.com wrote:
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable
Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.
This set is based on kukjin's for-next branch at
Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
On 06/18/13 14:09, Rahul Sharma wrote:
Hi Mr. Kukjin,
Kindly consider the following patches for review and integration.
(+ Mike)
Rahul, basically, looks good to me but I'm waiting for Mike's ack on
this series...
regards,
Rahul Sharma.
On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse j.gli...@gmail.com wrote:
Andy can you test (without your patch) and see if it helps with your issue :
The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in panel-info struct.
Signed-off-by: Benoit Parrot bpar...@ti.com
---
Our new idr implementation does its own locking, instead of forcing it
onto the callers like the old implementation.
Many of the existing idr users need locking for more than just
idr_alloc()/idr_remove()/idr_find() - they're taking refcounts and such
under their locks and we can't touch those.
The old idr_preload() used percpu buffers - since the
bitmap/radix/whatever tree only grew by fixed sized nodes, it only had
to ensure there was a node available in the percpu buffer and disable
preemption. This conveniently meant that you didn't have to pass the idr
you were going to allocate
Hi Rahul,
This patch looks good to me.
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds
Hi Rahul,
It looks good, at least, to me.
Best Regards,
- Seung-Woo Kim
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was
dy of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/b0467ba3/attachment.html>
ou should be able to make it work with just the use
> of fences, you don't need to keep the buffers locked for the entire
> duration,
> just plug in the last fence in the correct slots and you're done..
>
I'm afraid that I don't understand what you say. My approach doesn't use
dma fence stuff anymore. Maybe it seems missing something. Could you show
me simple example? A little summary is ok. Otherwise, where I can refer
to example codes?
Thanks,
Inki Dae
>
I'm not sure if the android sync api is compatible enough, but you
> shouldn't need to write code in this way to make it work..
> >>
> >> A few things that stand out from a casual glance:
> >>
> >> bool is_dmabuf_sync_supported(void)
> >> -> any code that needs CONFIG_DMABUF_SYNC should select it in their
> >> kconfig
> >> runtime enabling/disabling of synchronization is a recipe for disaster,
> >> remove the !CONFIG_DMABUF_SYNC fallbacks.
> >> NEVER add a runtime way to influence locking behavior.
> >>
> > Not enabling/disabling synchronization feature in runtime. That is
> > determined at build time.
> >
> >> Considering you're also holding dmaobj->lock for the entire duration, is
> >> there any point to not simply call begin_cpu_access/end_cpu_access, and
> >> forget this ugly code ever existed?
> > You mean mutex_lock(>lock)? Yeah, it seems unnecessary in that
> case.
> >
> >> I still don't see the problem you're trying to solve..
> >>
> > It's just to implement a thin sync framework coupling cache operation.
> This
> > approach is based on dma-buf for more generic implementation against
> android
> > sync driver or KDS.
> >
> > The described steps may be summarized as:
> > lock -> cache operation -> CPU or DMA access to a buffer/s ->
> unlock
> >
> > I think that there is no need to get complicated for such approach at
> least
> > for most devices sharing system memory. Simple is best.
> >
> >
> > Thanks,
> > Inki Dae
> >
> >> ~Maarten
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/59086e46/attachment-0001.html>
_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be followed if you're going to have
> a happy life.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/7711fdf9/attachment.html>
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote:
> That has already been fixed in linux-next.
This header was added in v3.10-rc1. The fix in linux-next will ship in
v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10
release candidate(s)?
Thanks,
Paul Bolle
https://bugs.freedesktop.org/show_bug.cgi?id=65822
--- Comment #3 from Aaron Watry ---
Created attachment 80969
--> https://bugs.freedesktop.org/attachment.cgi?id=80969=edit
Shader dumps from a radeon 7850 for test cases in attachment 80967
--
You are receiving this mail because:
You are the
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/8bd6117d/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/20130618/27a59044/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/3bbf381a/attachment.html>
p-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/88fd9c3b/attachment-0001.pgp>
Hi Mr. Kukjin,
Kindly consider the following patches for review and integration.
regards,
Rahul Sharma.
On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K
wrote:
> Hi,
> Tested this series on snow board and is working fine.
>
> Tested-by: Arun Kumar K
>
> Regards
> Arun
>
> On Mon, Jun 10, 2013
> -Original Message-
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 3:21 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
> Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
>
Hi
On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski
wrote:
> On 06/16/2013 07:57 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be real work,
>>
Hi all,
I'd like to discuss Exynos DRM TODO work.
There are features we have to solve and implement. The purpose of this email
is to share what we have to do so that other guys can be involved without
duplicated work.
1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> So I've taken a look again at the locking mess in our fbdev support and
>> cried.
>> Fixing up the console_lock mess around the fbdev notifier will be
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume
This macro doesn't need a semi-colon.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5cc7c0..592b0eb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,7 +1773,7 @@ int
> -Original Message-
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 5:43 PM
> To: Inki Dae
> Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
>
On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote:
> This macro doesn't need a semi-colon.
>
> Signed-off-by: Dan Carpenter
Queued for -next, thanks for the patch.
-Daniel
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e5cc7c0..592b0eb9
Hi Mr. Dae,
Related to HDMI sound support in Alsa, I have posted a working RFC
"exynos-hdmi to CDF complaint display driver". It registers a separate
sound card by registering hdmi audio codec dai and cpu-dai, as you
mentioned. But there is a problem with this approach that I2S being the
single
Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
[...]
>
> > a display device driver. It shouldn't be used within a single driver
> > as a means of passing buffers between userspace and kernel space.
>
> What I try to do is not really such ugly thing. What I try to do is to
> notify
Thanks all,
On Fri, Jun 14, 2013 at 11:39 AM, ??? wrote:
> Hello Kishon,
>
> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
>>>
>>>
-Original Message-
From: Sylwester Nawrocki [mailto:s.nawrocki at
ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without
On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
> ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l?
> >
> > Having both modes can be beneficial for video playback cases. If you can
> > match the video framerate exactly, and the audio and video clocks come
> > from the
Ville Syrj?l? wrote:
> On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
>> ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrj?l?
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video
y
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/767bb829/attachment.pgp>
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> So I'd like to ask for other DRM maintainers. How do you think about it? it
> seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
> Rob) and GEM CMA helper also have same issue Russell pointed out. I think
> not only
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
>
>
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Tuesday, June 18, 2013 5:43 PM
> > To: Inki Dae
> > Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
>
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
> On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> > What we need is something along the lines of:
> > (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> > or
> > (b) drm_gem_prime_import()
Thanks Mr. Dae,
Please discard the REST of the patches in this series. I am posting a
another patch-set which has all the patches independent of hdmiphy
related changes.
regards,
Rahul Sharma.
On Mon, Jun 17, 2013 at 8:22 AM, Inki Dae wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>
> 2013/6/14
*/
--
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/20130618/1c3bd184/attachment.html>
Hi,
On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> Thanks all,
>
> On Fri, Jun 14, 2013 at 11:39 AM, ??? wrote:
>> Hello Kishon,
>>
>> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> -Original
Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.
This set doesn't have changes for hdmiphy, which will posted
independently.
This set is based on drm-next branch of Inki Dae's tree at
1 - 100 of 128 matches
Mail list logo