https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #41 from Niels Ole Salscheider ---
As I said before, the dma_fill function is based on dma_copy and I tried to
keep the diff small. But you are right, this could be improved.
> Have you created a patch to get these functions called i
platform_device_register_simple() never returns NULL, but IS_ERR_OR_NULL macro
is used for checking return value in exynos drm driver.
Signed-off-by: Seung-Woo Kim
---
This patch is based on exynos-drm-next branch.
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
drivers/gpu/drm/exynos/exyno
https://bugs.freedesktop.org/show_bug.cgi?id=63714
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Christian K
https://bugs.freedesktop.org/show_bug.cgi?id=63730
Christian König changed:
What|Removed |Added
Attachment #78270|0 |1
is obsolete|
The hdmi common device registration function does not need extern definition
and for error case and unregister case, exynos_drm_hdmi_pdev should be cleared.
Signed-off-by: Seung-Woo Kim
---
This commit is based on exynos-drm-next and my previous commit "drm/exynos: fix
wrong return check for plat
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
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> 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/
2013/4/22 Tomasz Figa
> 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 c
On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
>> 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
On 04/22/2013 12:03 PM, Inki Dae wrote:
> > Also looks good to me. But what if power domain was disabled without pm
> > runtime? In this case, you must enable the power domain at machine code
> or
> > bootloader somewhere. This way would not only need some hard codes to
> turn
> >
2013/4/22 Sylwester Nawrocki
> On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > Also looks good to me. But what if power domain was disabled
> without pm
> > > runtime? In this case, you must enable the power domain at machine
> code or
> > > bootloader somewhere. This way would not only
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > Also looks good to me. But what if power domain was disabled without
> > > pm
> > > runtime? In this case, you must enable the power domain at machine
> > > code or
> >
Hi Mr Dae,
On 22 April 2013 11:19, Inki Dae wrote:
> 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
On 22 April 2013 15:26, Tomasz Figa wrote:
> Can you assure that in future SoCs, on which this driver will be used, this
> assumption will still hold true or even that in current Exynos driver this
> behavior won't be changed?
Probably yes.. Registers for enabling/disabling these clocks should al
On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > Also looks good to me. But what if power domain was disabled without
> > > > pm
> > > > runtime? In this case, you
2013/4/22 Tomasz Figa
> On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > Also looks good to me. But what if power domain was disabled
> without
> > > > pm
> > > > runtime? In this case, you must enable the power domain a
2013/4/22 Rafael J. Wysocki
> On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > > Also looks good to me. But what if power domain was disabled
> without
> > > > >
On Monday 22 of April 2013 12:05:49 Sylwester Nawrocki wrote:
> On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> > On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> >> On 21 April 2013 20:13, Tomasz Figa wrote:
> >>> 3) after those two changes, all that remains is to fix compliance with
> >>>
On Mon, Apr 22, 2013 at 1:43 AM, Rafał Miłecki wrote:
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=62466
--- Comment #3 from l...@mail.ru ---
I am also affected by this bug.
I use Debian Linux Mint Edition (current Debian Testing, minus 10-20 days lag).
Further info is below.
GPU is: HD5850, 1920x1080 via DVI.
I get repeatable lockups in game Urban
https://bugs.freedesktop.org/show_bug.cgi?id=62466
l...@mail.ru changed:
What|Removed |Added
Severity|normal |major
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=62466
--- Comment #4 from l...@mail.ru ---
This does not affect HyperZ for me, BUT the dmesg lockup message is EXACTLY the
same.
I also found out, that it happens at certain "angles" and "positions" (when
player is in certain location and his "viewport
https://bugs.freedesktop.org/show_bug.cgi?id=63748
--- Comment #3 from l...@mail.ru ---
I am sure 62466 is either duplicate, or I am having exactly the same issue, but
posted the info into 62466. Affects me as well.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=63748
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=62466
Alex Deucher changed:
What|Removed |Added
CC||dino...@libero.it
--- Comment #5 from Ale
2013/4/22 Vikas Sajjan
>
> Hi Mr Dae,
>
> On 22 April 2013 11:19, Inki Dae wrote:
>
>> 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
From: Alex Deucher
Reported-by: Dan Carpenter
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios.h|2 ++
drivers/gpu/drm/radeon/radeon_atombios.c |6 ++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=63730
--- Comment #7 from Johannes Hirte ---
I've already tested this by myself and can confirm that this fix the problem.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Reported-by: Dan Carpenter
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios.h|2 ++
> drivers/gpu/drm/radeon/radeon_atombios.c |6 ++
> 2 files changed, 4 in
On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
wrote:
> On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
>> From: Alex Deucher
>>
>> Reported-by: Dan Carpenter
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/atombios.h|2 ++
>> drivers/gpu/drm
On Mon, Apr 22, 2013 at 10:18:09AM -0400, Alex Deucher wrote:
> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
> wrote:
> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
> >> From: Alex Deucher
> >>
> >> Reported-by: Dan Carpenter
> >> Signed-off-by: Alex Deucher
> >>
On Mon, Apr 22, 2013 at 10:31 AM, Dan Carpenter
wrote:
> On Mon, Apr 22, 2013 at 10:18:09AM -0400, Alex Deucher wrote:
>> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
>> wrote:
>> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
>> >> From: Alex Deucher
>> >>
>> >> Rep
Hi,
On 04/19/2013 01:26 PM, Eunchul Kim wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> index d812c57..bc8411a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> @@ -76,6 +76
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #52 from udo ---
W.r.t. bisecting I found the info at http://webchick.net/node/99.
Next week I do not have to go to work so I could give it a try.
Where do I get the sources from?
And what sha1's refer to all radeon commits in 3.7-rc1
Hi Inki,
On 04/20/2013 06:11 PM, Inki Dae wrote:
> Hi Sylwester,
>
> DRM FIMC driver could be more cleaned up with this patch series. And your
> third
> patch
> And just minor issue. The second patch has build warnings like below,
>
> WARNING: static const char * array should probably be static
On Mon, 2013-04-22 at 10:18 -0400, Alex Deucher wrote:
> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
> wrote:
> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
> >> From: Alex Deucher
> >>
> >> Reported-by: Dan Carpenter
> >> Signed-off-by: Alex Deucher
> >> ---
>
On 04/20/2013 06:21 PM, Inki Dae wrote:
> +static int fimc_parse_dt(struct fimc_context *ctx)
> +{
> + struct device_node *node = ctx->dev->of_node;
> +
> + if (!of_property_read_bool(node, "samsung,lcd-wb"))
> + return -ENODEV;
>
>
>
> Isn't the
On 04/19/2013 01:38 PM, Eunchul Kim wrote:
>> static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
>> @@ -1628,7 +1617,9 @@ static int fimc_ippdrv_start(struct device *dev, enum
>> drm_exynos_ipp_cmd cmd)
>> fimc_handle_lastend(ctx, true);
>>
>> /* setup F
Am 21.04.2013 23:53, schrieb Alex Deucher:
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
2013/4/22 Christian König :
> Found one more minor nitpick in this patch:
>
>
>> + if (cea_db_tag(db) == AUDIO_BLOCK) {
>> + dbl = cea_db_payload_len(db);
>> + int j;
>> +
>
>
> That's code after declaration and so complained on by the compi
On Mon, Apr 22, 2013 at 11:29 AM, Michel Dänzer wrote:
> On Mon, 2013-04-22 at 10:18 -0400, Alex Deucher wrote:
>> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
>> wrote:
>> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...@gmail.com wrote:
>> >> From: Alex Deucher
>> >>
>> >> Reported-b
On Mon, Apr 22, 2013 at 12:12 PM, Rafał Miłecki wrote:
> 2013/4/22 Christian König :
>> Found one more minor nitpick in this patch:
>>
>>
>>> + if (cea_db_tag(db) == AUDIO_BLOCK) {
>>> + dbl = cea_db_payload_len(db);
>>> + int j;
>>> +
>>
>
On Mon, 2013-04-22 at 12:15 -0400, Alex Deucher wrote:
> On Mon, Apr 22, 2013 at 11:29 AM, Michel Dänzer wrote:
> > On Mon, 2013-04-22 at 10:18 -0400, Alex Deucher wrote:
> >> On Mon, Apr 22, 2013 at 10:08 AM, Dan Carpenter
> >> wrote:
> >> > On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeuc...
From: Alex Deucher
Uses a different register than DCE3 asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_hdmi.c | 15 ---
drivers/gpu/drm/radeon/r600d.h |7 ++-
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r60
Just realized at a ThinkPad T420 with i915 and a stable Gentoo Linux today
these messages with kernel v3.9-rc7-173-g830ac85 :
2013-04-22T18:34:23.365+02:00 n22 kernel: [drm:__gen6_gt_force_wake_get]
*ERROR* Timed out waiting for forcewake to ack request.
2013-04-22T18:34:23.365+02:00 n22 kernel:
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #28 from Hristo Venev ---
The kernel acts the same way as it did before.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@list
https://bugs.freedesktop.org/show_bug.cgi?id=63632
--- Comment #4 from Tom Stellard ---
(In reply to comment #3)
> (In reply to comment #2)
> > I can't reproduce this with LLVM r179895 and Mesa
> > 12eab7cc564a6928197f9b87ded9e368e56976f0
> >
> > Have you done full rebuilds of both projects?
>
https://bugs.freedesktop.org/show_bug.cgi?id=63632
--- Comment #5 from Andy Furniss ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I can't reproduce this with LLVM r179895 and Mesa
> > > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > >
> > > Have you don
Carlos Corbacho writes:
> 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?
It is already there. I think there is the usual caching problem with the
cgi
https://bugs.freedesktop.org/show_bug.cgi?id=63762
Pablo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #42 from Jerome Glisse ---
As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
visual for everything ...
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #43 from Fredrik Höglund ---
(In reply to comment #42)
> As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> visual for everything ...
I've pushed a patch to the stable branch in KDE that should fix this issue
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #44 from D. Hugh Redelmeier ---
Jerome Glisse in comment #30:
"Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl
so that it does not pick msaa visual for gnome-shell."
Thanks!
I am (even today) experiencin
This patch added exynos-drm-ipp platform device registration to the exynos drm
driver. When DT is enabled, platform devices need to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Donghwa Le
commit ae1287865f5361fa138d4d3b1b6277908b54eac9
Author: Dave Airlie
Date: Thu Jan 24 16:12:41 2013 +1000
fbcon: don't lose the console font across generic->chip driver switch
uses a pointer in vc->vc_font.data to load font into the new driver.
However if the font is actually freed, we need
Hi Dave,
On 2013-04-18 12:21, Tomi Valkeinen wrote:
> On 2013-04-18 12:09, Tomi Valkeinen wrote:
>> On 2013-04-18 11:37, Christoph Fritz wrote:
>
>>> With linux-next this patch breaks compiling here because DPI now depends
>>> on DSI - but my omap3 board here doesn't use DSI at all:
>>>
>>> drive
On Thu, Apr 18, 2013 at 06:33:21PM +0100, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them, together with the
> Common Display Framework.
>
> The DT provides information about the hardware configuration
> and limitations (eg. the
On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher wrote:
> On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski wrote:
>> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher wrote:
>>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski wrote:
Every day or so, I'll click something and my screens go blank for
I'm troubleshooting an interesting problem where the i915_hotplug_work_func is
eating up a lot of time in a couple of kworker threads. The interesting part of
the problem is that this only happens with one particular model of monitor
which I haven't gotten to the bottom of yet. But that's not th
On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
> On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher wrote:
> > On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski
> > wrote:
> >> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher wrote:
> >>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski
> >>
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
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
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
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
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... ;
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_
clk_disable(ctx->bus_clk);
> + fimd_activate(ctx, false);
>
> + pm_runtime_put_noidle(dev);
> pm_runtime_set_suspended(dev);
> - pm_runtime_put_sync(dev);
> -
> -out:
> - pm_runtime_disable(dev);
>
> First, pm_runtime_disable() will prevent any further runtime PM operations
> that could change ctx->suspended state. Then, if ctx->suspended is true,
> there is no need to suspend anything and we can leave. Otherwise, we power
> down the hardware manually - which will work with both CONFIG_PM_RUNTIME
> enabled and disabled, and then mark the hardware as suspended and free
> remaining reference in runtime PM core. Note that pm_runtime_put_noidle
> just decreases the reference counter and nothing else.
>
> 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/
>
>
Also looks good to me. But what if power domain was disabled without pm
runtime? In this case, you must enable the power domain at machine code or
bootloader somewhere. This way would not only need some hard codes to turn
the power domain on but also not manage power management fully. This is
same as only the use of pm runtime interface(needing some hard codes
without pm runtime) so I don't prefer to add clk_enable/disable to fimd
probe(). I quite tend to force only the use of pm runtime as possible. So
please add the hard codes to machine code or bootloader like you did for
power domain if you want to use drm fimd without pm runtime.
Thanks,
Inki Dae
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" 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/20130422/f799ba97/attachment-0001.html>
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
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
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
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/
Hi, Mr. Vikas
Please fix the below typos Viresh pointed out and my comments.
> -Original Message-
> From: Viresh Kumar [mailto:viresh.kumar at linaro.org]
> Sent: Monday, April 01, 2013 5:51 PM
> To: Vikas Sajjan
> Cc: dri-devel at lists.freedesktop.org; linux-samsung-soc at vger.kernel.o
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
ed
> F: drivers/mmc/host/sdhci-s3c.c
>
> --
> 1.8.2.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/307083cb/attachment.html>
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/49849d99/attachment.html>
platform_device_register_simple() never returns NULL, but IS_ERR_OR_NULL macro
is used for checking return value in exynos drm driver.
Signed-off-by: Seung-Woo Kim
---
This patch is based on exynos-drm-next branch.
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
drivers/gpu/drm/exynos/exyno
K?nig ---
k, then let's close this tracker.
--
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/20130422/732adef8/attachm
ng 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/20130422/d90564f9/attachment.html>
The hdmi common device registration function does not need extern definition
and for error case and unregister case, exynos_drm_hdmi_pdev should be cleared.
Signed-off-by: Seung-Woo Kim
---
This commit is based on exynos-drm-next and my previous commit "drm/exynos: fix
wrong return check for plat
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
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> 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/
IG_PM_RUNTIME is not
> enabled.
> > > Note that pm_runtime_get_sync() after marking the device as active with
> > > pm_runtime_set_active() won't result in calling fimd_runtime_resume(),
> > > because the device is considered already resumed.
> > >
> > > 2) in fimd_remove():
> > >
> > > + pm_runtime_disable(dev);
> > > +
> > > if (ctx->suspended)
> > > - goto out;
> > > + return 0;
> > >
> > >
> > > - clk_disable(ctx->lcd_clk);
> > > - clk_disable(ctx->bus_clk);
> > >
> > > + fimd_activate(ctx, false);
> > >
> > > + pm_runtime_put_noidle(dev);
> > > pm_runtime_set_suspended(dev);
> > > - pm_runtime_put_sync(dev);
> > > -
> > > -out:
> > > - pm_runtime_disable(dev);
> > >
> > > First, pm_runtime_disable() will prevent any further runtime PM
> operations
> > > that could change ctx->suspended state. Then, if ctx->suspended is
> true,
> > > there is no need to suspend anything and we can leave. Otherwise, we
> power
> > > down the hardware manually - which will work with both
> CONFIG_PM_RUNTIME
> > > enabled and disabled, and then mark the hardware as suspended and free
> > > remaining reference in runtime PM core. Note that pm_runtime_put_noidle
> > > just decreases the reference counter and nothing else.
> > >
> > > 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/
> >
> >
> > Also looks good to me. But what if power domain was disabled without pm
> > runtime? In this case, you must enable the power domain at machine code
> or
> > bootloader somewhere. This way would not only need some hard codes to
> turn
> > the power domain on but also not manage power management fully. This is
> same
> > as only the use of pm runtime interface(needing some hard codes without
> pm
> > runtime) so I don't prefer to add clk_enable/disable to fimd probe(). I
> quite
> > tend to force only the use of pm runtime as possible. So please add the
> hard
> > codes to machine code or bootloader like you did for power domain if you
> > want to use drm fimd without pm runtime.
>
> That's not how the runtime PM, clock subsystems work:
>
> 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be kept
> powered on all the time.
>
> 2) Common Clock Framework will always gate all clocks that have zero
> enable_count. Note that CCF support for Exynos is already merged for 3.10
> and
> it will be the only available clock support method for Exynos.
>
> AFAIK, drivers must work correctly in both cases, with CONFIG_PM_RUNTIME
> enabled and disabled.
>
>
Then is the driver worked correctly if the power domain to this device was
disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()? I
think, in this case, the device wouldn't be worked correctly because the
power of the device remains off. So you must enable the power domain
somewhere. What is the difference between these two cases?
> Best regards,
> Tomasz
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/24cd0720/attachment-0001.html>
On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
>> 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
On 04/22/2013 12:03 PM, Inki Dae wrote:
> > Also looks good to me. But what if power domain was disabled without pm
> > runtime? In this case, you must enable the power domain at machine code
> or
> > bootloader somewhere. This way would not only need some hard codes to
> turn
> >
Sylwester
> ___
> 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/20130422/c2e62ab4/attachment.html>
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > Also looks good to me. But what if power domain was disabled without
> > > pm
> > > runtime? In this case, you must enable the power domain at machine
> > > code or
> >
obably patch v5??)
>
>So you mean I should work on v3 version, and keep the
clk_prepare_enable() code as is in fimd_clock() and just remove the
clk_disable_unprepare() and also clk_disable() from fimd_remove(), right?
Viresh and Tomaz Figa, let me know if these changes are fine with you guys.
Thanks,
> Inki Dae
>
> >
> > You are doing things at the right place but i have a suggestion. Are you
> > doing
> > anything in your clk_prepare() atleast for this device? Probably not.
> >
> > If not, then its better to call clk_prepare/unprepare only once at
> > probe/remove
> > and keep clk_enable/disable calls as is.
> >
> > --
> > viresh
>
>
--
Thanks and Regards
Vikas Sajjan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/e444e9a5/attachment-0001.html>
On 22 April 2013 15:26, Tomasz Figa wrote:
> Can you assure that in future SoCs, on which this driver will be used, this
> assumption will still hold true or even that in current Exynos driver this
> behavior won't be changed?
Probably yes.. Registers for enabling/disabling these clocks should al
On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote:
> On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
> > On 04/22/2013 12:03 PM, Inki Dae wrote:
> > > > Also looks good to me. But what if power domain was disabled without
> > > > pm
> > > > runtime? In this case, you
and with clk_enable(). Could you guarantee the driver to
be worked correctly only adding clk_enable() to probe() without
CONFIG_PM_RUNTIME? as I said before, what if the power domain to the device
was disabled?
> Rafael, Kevin, do you have any opinion on this?
>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Kernel and System Framework
>
> ___
> 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/20130422/bf04724c/attachment.html>
he
device couldn't be worked correctly without turning the power domain on
only calling clk_enable(). In this case, the power domain must be enabled
at machine code or bootloader. And the machine without CONFIG_PM_RUNTIME
would assume that their own drivers always are enabled so the devices would
be worked correctly. Is there any my missing point?
Thanks,
Inki Dae
Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" 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/20130422/bdba92db/attachment-0001.html>
On Monday 22 of April 2013 12:05:49 Sylwester Nawrocki wrote:
> On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> > On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> >> On 21 April 2013 20:13, Tomasz Figa wrote:
> >>> 3) after those two changes, all that remains is to fix compliance with
> >>>
On Mon, Apr 22, 2013 at 1:43 AM, Rafa? Mi?ecki wrote:
> 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
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/19bf9634/attachment.html>
vel/attachments/20130422/4564f299/attachment.html>
eeded in 0 usecs
[27140.833977] [drm] ib test succeeded in 1 usecs
--
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/20130422/bcefe7eb/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/e29a38aa/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130422/82b82bec/attachment.html>
nts/20130422/551fcbd4/attachment.html>
gt; Just remove the above codes. It seems that clk_disable(also
>> clk_disable_unprepare) isn't needed because it will be done by
>> pm_runtime_put_sync and please re-post it(probably patch v5??)
>>
>>So you mean I should work on v3 version, and keep the
> clk_prepare_enable() code as is in fimd_clock() and just remove the
> clk_disable_unprepare() and also clk_disable() from fimd_remove(), right?
>
>
Right, please post it. And adding clk_enable() to probe() is another issue
so this could be discussed later. As is this patch is needed for CCF
support.
> Viresh and Tomaz Figa, let me know if these changes are fine with you guys.
>
> Thanks,
>> Inki Dae
>>
>> >
>> > You are doing things at the right place but i have a suggestion. Are you
>> > doing
>> > anything in your clk_prepare() atleast for this device? Probably not.
>> >
>> > If not, then its better to call clk_prepare/unprepare only once at
>> > probe/remove
>> > and keep clk_enable/disable calls as is.
>> >
>> > --
>> > viresh
>>
>>
>
>
> --
> 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/20130422/3d07d998/attachment-0001.html>
1 - 100 of 126 matches
Mail list logo
