truct 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:
>>> -
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
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,
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
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,
>
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
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>
ions 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>
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>
uld 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
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/46133d71/attachment.html>
ttp://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
> > > >
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
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
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/1ceff024/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/7692f1e5/attachment-0001.html>
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?
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>
...
>>
>>
>> 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, 1st patch for
adding
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.
> >
> >
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
> >
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130421/fe61d2e4/attachment.html>
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/
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130421/778a29a5/attachment.html>
org/archives/dri-devel/attachments/20130421/c221ac63/attachment.html>
dri-devel/attachments/20130421/e839e5cb/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130421/94f6422a/attachment.html>
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>
; .name = "exynos-drm-fimc",
> .owner = THIS_MODULE,
> .pm = _pm_ops,
> diff --git a/drivers/gpu/drm/exynos/regs-fimc.h
> b/drivers/gpu/drm/exynos/regs-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>
> --
> 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>
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 #46 from udo udo...@xs4all.nl ---
Booted 3.7.8.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #47 from udo udo...@xs4all.nl ---
And it crashed, booted.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #26 from Hristo Venev mustrum...@gmail.com ---
Sadly the problem still remains.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
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
On Apr 20, 2013 8:56 PM, Inki Dae inki@samsung.com wrote:
2013/4/19 Vikas Sajjan vikas.saj...@linaro.org
Hi Inki Dae and Viresh,
On 8 April 2013 16:41, Viresh Kumar viresh.ku...@linaro.org wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to
On 20 April 2013 20:56, Inki Dae inki@samsung.com 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
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org 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
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/
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
On 20 April 2013 20:56, Inki Dae inki@samsung.com 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.
https://bugs.freedesktop.org/show_bug.cgi?id=63762
--- Comment #1 from Alex Deucher ag...@yahoo.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #36 from Alex Deucher ag...@yahoo.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #37 from Alex Deucher ag...@yahoo.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #27 from Alex Deucher ag...@yahoo.com ---
(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?
--
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), I found that the FIMD
clocks were pulled down by the CCF.
If
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #48 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #49 from udo udo...@xs4all.nl ---
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
Hi Inki,
On Sunday 21 of April 2013 23:05:45 Inki Dae wrote:
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote:
On 20 April 2013 20:56, Inki Dae inki@samsung.com wrote:
Sorry for being late. I think clk_prepare/unprepare are nothing
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
2013/4/21 Tomasz Figa tomasz.f...@gmail.com
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF),
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #50 from udo udo...@xs4all.nl ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #38 from Niels Ole Salscheider niels_...@salscheider-online.de ---
Created attachment 78307
-- https://bugs.freedesktop.org/attachment.cgi?id=78307action=edit
dma_fill function
I considered to implement Marek's proposal by adding a
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #51 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #39 from Marek Olšák mar...@gmail.com ---
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
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 out and
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #40 from D. Hugh Redelmeier h...@mimosa.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=63748
--- Comment #2 from dinolib dino...@libero.it ---
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
2013/4/14 Alex Deucher alexdeuc...@gmail.com:
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com 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
2013/4/21 Rafał Miłecki zaj...@gmail.com:
2013/4/14 Alex Deucher alexdeuc...@gmail.com:
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
We need interrupts on format change for R6xx only, where hardware seems
to be somehow bugged and requires setting audio info manually.
On Sun, Apr 21, 2013 at 3:15 PM, Rafał Miłecki zaj...@gmail.com wrote:
2013/4/21 Rafał Miłecki zaj...@gmail.com:
2013/4/14 Alex Deucher alexdeuc...@gmail.com:
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
We need interrupts on format change for R6xx only, where
https://bugs.freedesktop.org/show_bug.cgi?id=63730
--- Comment #5 from Jrh jharbesto...@gmail.com ---
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:
2013/4/21 Alex Deucher alexdeuc...@gmail.com:
On Sun, Apr 21, 2013 at 3:15 PM, Rafał Miłecki zaj...@gmail.com wrote:
2013/4/21 Rafał Miłecki zaj...@gmail.com:
2013/4/14 Alex Deucher alexdeuc...@gmail.com:
On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
We need
2013/4/18 alexdeuc...@gmail.com:
From: Alex Deucher alexander.deuc...@amd.com
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
2013/4/19 Alex Deucher alexdeuc...@gmail.com:
On Fri, Apr 19, 2013 at 2:10 AM, Rafał Miłecki zaj...@gmail.com wrote:
2013/4/18 alexdeuc...@gmail.com:
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- case
On Fri, Apr 19, 2013 at 1:01 PM, Rafał Miłecki zaj...@gmail.com 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
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
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.
From: Imre Deak imre.d...@intel.com
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
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
77 matches
Mail list logo
