Hi,
I don't think it's not required, each tree has each own mailing list. don't
need to post all patches to samsung-soc list.
Thank you,
Kyungmin Park
On Mon, Apr 22, 2013 at 4:20 AM, Tomasz Figa wrote:
> Several entries in MAINTAINERS file related to Samsung SoCs do not point
> to linux-samsu
Hi, Mr. Vikas
Please fix the below typos Viresh pointed out and my comments.
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Monday, April 01, 2013 5:51 PM
> To: Vikas Sajjan
> Cc: dri-devel@lists.freedesktop.org; linux-samsung-...@vger.kernel.org;
> jy0
2013/4/19 Alex Deucher :
> On Fri, Apr 19, 2013 at 2:10 AM, Rafał Miłecki wrote:
>> 2013/4/18 :
>>> - switch (radeon_encoder->encoder_id) {
>>> - case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>>> - case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>>> - WREG32_P(R600_AUDIO_TI
On 21 April 2013 20:13, Tomasz Figa wrote:
> 3) after those two changes, all that remains is to fix compliance with
> Common Clock Framework, in other words:
>
> s/clk_enable/clk_prepare_enable/
>
> and
>
> s/clk_disable/clk_disable_unprepare/
We don't have to call clk_{un}prepare() everytime fo
Hi Tomasz,
CCing Mr. Ham
2013/4/21 Tomasz Figa
> Hi Inki,
>
> On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > 2013/4/21 Tomasz Figa
> >
> > > Hi,
> > >
> > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > > While mig
CC [M] drivers/gpu/drm/drm_edid.o
drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_sad’:
drivers/gpu/drm/drm_edid.c:2549:4: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement]
Reported-by: Dieter Nützel
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/drm_
2013/4/22 Dieter Nützel :
> CC [M] drivers/gpu/drm/drm_edid.o
> drivers/gpu/drm/drm_edid.c: In Funktion »drm_edid_to_sad«:
> drivers/gpu/drm/drm_edid.c:2550:4: Warnung: ISO-C90 verbietet gemischte
> Deklarationen und Code [-Wdeclaration-after-statement]
I'm glad you're not using Chinese LANG... ;
From: Laurent Pinchart
Test whether the pixel format changes in the mode set handler, and
perform a full mode set instead of a mode set base if it does.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/
From: Laurent Pinchart
A page flip is not a mode set, changing the frame buffer pixel format
doesn't make sense and isn't handled by most drivers anyway. Disallow
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/driver
Hello,
Here's the second version of two small KMS mode set fixes.
Changes since v1:
- Only check fb->pixel_format to determine if the pixel format has changed
in 1/2.
Laurent Pinchart (2):
drm: Don't allow page flip to change pixel format
drm: Perform a full mode set when the pixel format
Several entries in MAINTAINERS file related to Samsung SoCs do not point
to linux-samsung-soc mailing list, which is supposed to collect all
Samsung SoC-related threads, to ease following of Samsung SoC-related
work. This leads to a problem with people skipping this mailing list in
their posts, eve
vance.
>
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/9f1676ef/attachment.html>
t fimd_remove(struct platform_device
> > > *pdev)>
> > > if (ctx->suspended)
> > >
> > > goto out;
> > >
> > > - clk_disable(ctx->lcd_clk);
> > > - clk_disable(ctx->bus_clk);
> > > + clk_unprepare(ctx->lcd_clk);
> > > + clk_unprepare(ctx->bus_clk);
> >
> > This looks wrong again.. You still need to call clk_disable() to make
> > clk enabled
> > count zero...
>
> Viresh is right again here.
>
>
Ok, you two guys say together this looks wrong so I'd like to take more
checking. I thought that clk->clk_enable is 1 at here and it would be 0 by
pm_runtimg_put_sync(). Is there any my missing point?
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/e7c1f06e/attachment.html>
2013/4/19 Alex Deucher :
> On Fri, Apr 19, 2013 at 2:10 AM, Rafa? Mi?ecki wrote:
>> 2013/4/18 :
>>> - switch (radeon_encoder->encoder_id) {
>>> - case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>>> - case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>>> - WREG32_P(R600_AUDIO_TI
2013/4/18 :
> From: Alex Deucher
>
> Register audio callbacks for asic where we support
> audio. Cleans up the code and makes it easier to
> add support for newer asics.
Ack
--
Rafa?
2013/4/21 Alex Deucher :
> On Sun, Apr 21, 2013 at 3:15 PM, Rafa? Mi?ecki wrote:
>> 2013/4/21 Rafa? Mi?ecki :
>>> 2013/4/14 Alex Deucher :
On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
> We need interrupts on format change for R6xx only, where hardware seems
> to be somehow b
Several entries in MAINTAINERS file related to Samsung SoCs do not point
to linux-samsung-soc mailing list, which is supposed to collect all
Samsung SoC-related threads, to ease following of Samsung SoC-related
work. This leads to a problem with people skipping this mailing list in
their posts, eve
2013/4/21 Rafa? Mi?ecki :
> 2013/4/14 Alex Deucher :
>> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
>>> We need interrupts on format change for R6xx only, where hardware seems
>>> to be somehow bugged and requires setting audio info manually.
>>
>> Can you confirm that this is actually n
2013/4/14 Alex Deucher :
> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> Can you confirm that this is actually needed on older chips? AFAIK,
> i
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/29c96a69/attachment.html>
ts should be taken out and shot.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2013042
h the requested files
as soon as possible.
--
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/20130421/2fb7d546/attachment.html>
ns called in place of the
currently broken code?
--
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/20130421/7707be68/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/20130421/121d4edb/attachment.html>
fore? I could help you with
it if you want to.
--
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/20130421/dd6211c4/attachment.html>
On Fri, Apr 19, 2013 at 1:01 PM, Rafa? Mi?ecki wrote:
> Some devices (ATI/AMD cards) don't support passing ELD struct to the
> hardware but just require filling specific registers and then the
> hardware/firmware does the rest. In such cases we need to read the info
> from SAD blocks and put them
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/46133d71/attachment.html>
Hi guys,
not sure when/why we added the TLS ABI tag, so we only run on kernels
> 2.4.20, but it seems to break systems which install multiple libGLs
and using /etc/ld.so.conf to order access to them.
I'm not sure really care about this, but we might in the future,
distros appear to have being dro
From: Imre Deak
In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.
Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one
Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object
i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close.
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/70b8d8ef/attachment.html>
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > > On 20 April 2013 20:56, Inki Dae wrote:
> > > > Sorry for being late. I think clk_prepare/unprepare are nothing to
> > > > do
> > > > yet in c
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/f3c8481a/attachment.html>
On Sun, Apr 21, 2013 at 3:15 PM, Rafa? Mi?ecki wrote:
> 2013/4/21 Rafa? Mi?ecki :
>> 2013/4/14 Alex Deucher :
>>> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki wrote:
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio
CC [M] drivers/gpu/drm/drm_edid.o
drivers/gpu/drm/drm_edid.c: In Funktion »drm_edid_to_sad«:
drivers/gpu/drm/drm_edid.c:2550:4: Warnung: ISO-C90 verbietet gemischte
Deklarationen und Code [-Wdeclaration-after-statement]
Regards,
Dieter
___
dri-devel
On Fri, Apr 19, 2013 at 1:01 PM, Rafał Miłecki wrote:
> Some devices (ATI/AMD cards) don't support passing ELD struct to the
> hardware but just require filling specific registers and then the
> hardware/firmware does the rest. In such cases we need to read the info
> from SAD blocks and put them
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/1ceff024/attachment.html>
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/20130421/7692f1e5/attachment-0001.html>
appears to
just be the vram window.
--
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/20130421/47e97884/attachment.html>
On 20 April 2013 20:56, Inki Dae wrote:
> Sorry for being late. I think clk_prepare/unprepare are nothing to do yet in
> case of Exynos but those might be used for in the future so your patch looks
> good to me as is.
>
> Applied. :)
And you think the comments i gave were incorrect then? Why?
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/862ca7e1/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/210bf8b3/attachment.html>
2013/4/19 Alex Deucher :
> On Fri, Apr 19, 2013 at 2:10 AM, Rafał Miłecki wrote:
>> 2013/4/18 :
>>> - switch (radeon_encoder->encoder_id) {
>>> - case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>>> - case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>>> - WREG32_P(R600_AUDIO_TI
;>> count zero...
>>
>>
>> Viresh had an suggestion, that the original code had a call
clk_disable() in fimd_remove(), which is really NOT required as there is NO
clk_enable() in fimd_probe() and we can right away delete clk_disable()
from fimd_remove().
>>
>> And also i think i should be breaking this patch into 2,
2013/4/18 :
> From: Alex Deucher
>
> Register audio callbacks for asic where we support
> audio. Cleans up the code and makes it easier to
> add support for newer asics.
Ack
--
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://
2013/4/21 Alex Deucher :
> On Sun, Apr 21, 2013 at 3:15 PM, Rafał Miłecki wrote:
>> 2013/4/21 Rafał Miłecki :
>>> 2013/4/14 Alex Deucher :
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
> We need interrupts on format change for R6xx only, where hardware seems
> to be somehow b
https://bugs.freedesktop.org/show_bug.cgi?id=63730
--- Comment #5 from Jrh ---
I am also seeing this on a foxconn nt-a3500 that has a radeon hd6310 - part of
the amd fusion. If you want additional information, let me know.
Regards.
--
You are receiving this mail because:
You are the assignee f
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> On 20 April 2013 20:56, Inki Dae wrote:
> > Sorry for being late. I think clk_prepare/unprepare are nothing to do
> > yet in case of Exynos but those might be used for in the future so
> > your patch looks good to me as is.
> >
> > Applied
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), I found that the FIMD
> > clocks were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > dr
On Sun, Apr 21, 2013 at 3:15 PM, Rafał Miłecki wrote:
> 2013/4/21 Rafał Miłecki :
>> 2013/4/14 Alex Deucher :
>>> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio
2013/4/21 Rafał Miłecki :
> 2013/4/14 Alex Deucher :
>> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
>>> We need interrupts on format change for R6xx only, where hardware seems
>>> to be somehow bugged and requires setting audio info manually.
>>
>> Can you confirm that this is actually n
2013/4/14 Alex Deucher :
> On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki wrote:
>> We need interrupts on format change for R6xx only, where hardware seems
>> to be somehow bugged and requires setting audio info manually.
>
> Can you confirm that this is actually needed on older chips? AFAIK,
> i
https://bugs.freedesktop.org/show_bug.cgi?id=63748
--- Comment #2 from dinolib ---
I'm sorry, I'm not able to bisect mesa. Never done.
Actually in our repositories we have mesa 9.0.2. No other version in test
repositories.
I pasted the dmesg output in the description. I'll attach the requested
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #40 from D. Hugh Redelmeier ---
Thanks, Neils, for the patch in comment #38.
Warning: the following comments are made with no understanding of X code.
"writting" should be "writing"
What is 0x000f? I would find the code cleare
On Fri, 2013-04-12 at 11:26 -0400, Alex Deucher wrote:
> Hi Ben,
>
> Attached are patches for the Linux firmware tree to update to the
> latest ucode for UVD support and adds support for the new Oland GPUs.
>
> Thanks!
Applied, thanks.
Ben.
--
Ben Hutchings
All extremists should be taken ou
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/fe61d2e4/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #39 from Marek Olšák ---
BTW today I have implemented buffer clearing using streamout. I'll send my
patches to mesa-dev later today. We can use DMA later for selected chipsets. (I
assume there'll be some quirks with DMA)
--
You are
Is the updated firmware for UVD support going to make its way at some point to
the linux-firmware tree[0], as I believe this is what most distros currently
use to get the Radeon firmware?
-Carlos
[0] https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #51 from Alexandre Demers ---
(In reply to comment #50)
> It crashed so we'll go for 3.7.5.
I'm sure 3.7.0 will already display the problem. It was probably introduced
between 3.6 and 3.7-rc1. Have you ever bisected before? I could h
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #38 from Niels Ole Salscheider ---
Created attachment 78307
--> https://bugs.freedesktop.org/attachment.cgi?id=78307&action=edit
dma_fill function
I considered to implement Marek's proposal by adding a dma_fill function that
works
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #50 from udo ---
It crashed so we'll go for 3.7.5.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > > On 20 April 2013 20:56, Inki Dae wrote:
> > > > Sorry for being late. I think clk_prepare/unprepare are nothing to
> > > > do
> > > > yet in c
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130421/778a29a5/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #49 from udo ---
No messages that I could find in /var/log/messages. Xorg.0.log or so didn't
help.
Doing 3.7.6. since shortly after that unplanned boot. So far it's OK.
--
You are receiving this mail because:
You are the assignee fo
org/archives/dri-devel/attachments/20130421/c221ac63/attachment.html>
2013/4/21 Tomasz Figa
> On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> > On 20 April 2013 20:56, Inki Dae wrote:
> > > Sorry for being late. I think clk_prepare/unprepare are nothing to do
> > > yet in case of Exynos but those might be used for in the future so
> > > your patch looks
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #48 from Alexandre Demers ---
(In reply to comment #47)
> And it crashed, booted.
Any message in your logs?
And I think you now have a reference to bisect.
--
You are receiving this mail because:
You are the assignee for the bug.
2013/4/21 Tomasz Figa
> Hi,
>
> On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > While migrating to common clock framework (CCF), I found that the FIMD
> > > clocks were pulled down by the CCF.
> > > If CCF finds any clock(s) which has
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #27 from Alex Deucher ---
(In reply to comment #26)
> Sadly the problem still remains.
Which problem? Does that kernel act like radeon with fglrx loaded first, or
still like radeon without fglrx loaded at all?
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #37 from Alex Deucher ---
(In reply to comment #35)
>
> Wait: according to http://dri.freedesktop.org/wiki/GART/ the GART seems to
> enable the video card to access the computer's memory, not the other way
> around. So I don't see h
dri-devel/attachments/20130421/e839e5cb/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #36 from Alex Deucher ---
(In reply to comment #34)
> I'm not saying that comment #29 is wrong. I'm saying that the existing code
> ought to have been written to handle this case. Clearly one solution is to
> replace the code as sug
https://bugs.freedesktop.org/show_bug.cgi?id=63762
--- Comment #1 from Alex Deucher ---
Try a newer mesa. 9.1 has significant performance improvements for TF2.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/94f6422a/attachment.html>
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
> On 20 April 2013 20:56, Inki Dae wrote:
> > Sorry for being late. I think clk_prepare/unprepare are nothing to do
> > yet in case of Exynos but those might be used for in the future so
> > your patch looks good to me as is.
> >
> > Applied
Is the updated firmware for UVD support going to make its way at some point to
the linux-firmware tree[0], as I believe this is what most distros currently
use to get the Radeon firmware?
-Carlos
[0] https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
_
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), I found that the FIMD
> > clocks were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > dr
On 20 April 2013 20:56, Inki Dae wrote:
> Sorry for being late. I think clk_prepare/unprepare are nothing to do yet in
> case of Exynos but those might be used for in the future so your patch looks
> good to me as is.
>
> Applied. :)
And you think the comments i gave were incorrect then? Why?
___
On Apr 20, 2013 8:56 PM, "Inki Dae" wrote:
>
>
>
>
> 2013/4/19 Vikas Sajjan
>>
>> Hi Inki Dae and Viresh,
>>
>> On 8 April 2013 16:41, Viresh Kumar wrote:
>>>
>>> On 8 April 2013 16:37, Vikas Sajjan wrote:
>>> > While migrating to common clock framework (CCF), I found that the
FIMD clocks
>>> >
https://bugs.freedesktop.org/show_bug.cgi?id=63714
--- Comment #3 from ryszardz...@yahoo.com ---
yes it in did seems like a coding frenzy took place in recent days ;). using
kernel 3.9.0-rc7 and applying around ~50 newest patches from
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10 t
u 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/20130421/a1db4816/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #26 from Hristo Venev ---
Sadly the problem still remains.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.
fimc.h
> index b4f9ca1..3049613 100644
> --- a/drivers/gpu/drm/exynos/regs-fimc.h
> +++ b/drivers/gpu/drm/exynos/regs-fimc.h
> @@ -661,9 +661,8 @@
> #define EXYNOS_CLKSRC_SCLK (1 << 1)
>
> /* SYSREG for FIMC writeback */
> -#define SYSREG_CAMERA_BLK (S3C_VA_SYS + 0x0218)
> -#define SYSREG_ISP_BLK (S3C_VA_SYS + 0x020c)
> -#define SYSREG_FIMD0WB_DEST_MASK (0x3 << 23)
> -#define SYSREG_FIMD0WB_DEST_SHIFT 23
> +#define SYSREG_CAMERA_BLK (0x0218)
> +#define SYSREG_FIMD0WB_DEST_MASK (0x3 << 23)
> +#define SYSREG_FIMD0WB_DEST_SHIFT 23
>
> #endif /* EXYNOS_REGS_FIMC_H */
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/8e551642/attachment-0001.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/20130421/bc6da303/attachment-0001.html>
t;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/480a5062/attachment.html>
able() ( if we want remove dependency on RUNTIME PM )
> in fimd_probe() for CCF migration another one for idea of replacing
> clk_disable() with adding clk_disable_unprepare() (since we will be adding
> clk_prepare_enable() in probe ) in fimd_remove() .
>
> Mr. Inki Dae any thoughts on this.
>
>
Sorry for being late. I think clk_prepare/unprepare are nothing to do yet
in case of Exynos but those might be used for in the future so your patch
looks good to me as is.
Applied. :)
Thanks,
Inki Dae
> --
> Thanks and Regards
> Vikas Sajjan
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/fa92e05e/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #47 from udo ---
And it crashed, booted.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.f
89 matches
Mail list logo
