art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/34ffed6a/attachment.html>
eiving 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/652ba763/attachment.html>
t;http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/0ff3f0f6/attachment.html>
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/4d45d210/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/cbf7a602/attachment.html>
re 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/3bcfce08/attachment.html>
On Tue, Jun 18, 2013 at 6:18 PM, Benoit Parrot 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 panel-info
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'.
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
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
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
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |4 ++--
2
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
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
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
---
arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
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
---
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +
drivers/gpu/drm/exynos/regs-mixer.h |7 +
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git
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
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt|
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
> -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';
>
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
ced the
'_' with '-' in the filename. The updated tests pass on my Llano APU.
--
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/ea77b44f/attachment.html>
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:
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
---
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
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
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.
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130618/9c67558e/attachment.html>
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
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
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
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
> -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-
>
output
--
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/64c9ab90/attachment-0001.html>
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
p-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/88fd9c3b/attachment-0001.pgp>
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>
ID quirks to explicitly set a mode
> drm: Add EDID force quirk for MMT Monitor2Go HD+
>
> drivers/gpu/drm/drm_edid.c | 89
> ++
> 1 file changed, 89 insertions(+)
>
> --
> 1.7.11.7
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/f791e077/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/20130618/1c3bd184/attachment.html>
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
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()
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
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
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski wrote:
> On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote:
>> Andy can you test (without your patch) and see if it helps with your issue :
>> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-scheduling-in.patch
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
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
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
>
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
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
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 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
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
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,
>>
_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>
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>
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>
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>
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>
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>
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
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
1 - 100 of 128 matches
Mail list logo
