ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/3ed5ff96/attachment.html>
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
> >>
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>
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 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
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
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
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
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
what distro are you using?
--
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/a0b35efe/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>
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>
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
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 #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=63762
Pablo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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>
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>
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:
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 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, alexdeucher
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
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
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
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 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, alexdeucher at gmail.com wrote:
> >> From: Alex Deucher
> >>
> >> Reported-by: Dan Carpenter
> >> Signed-off-by: Alex Deucher
>
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, alexdeucher at gmail.com wrote:
> >> From: Alex Deucher
> >>
> >> Reported-by: Dan Carpenter
> >> Signed-off-by: Alex Deucher
> >> ---
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
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
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
On Mon, Apr 22, 2013 at 10:03:13AM -0400, alexdeucher at 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
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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/053a11a4/attachment.html>
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
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
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 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
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>
n 3.7-rc1??
--
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/0d9c011b/attachment.html>
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?
>
gt; + unsigned long pll_min, unsigned long pll_max,
> + dsi_pll_calc_func func, void *data)
> +{
> + return false;
> +}
> +
> #endif
>
> /* DPI */
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-OMAPDSS-DPI-f
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 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
> >>>
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
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>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/3bdf2ebb/attachment.html>
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130422/82b82bec/attachment.html>
nts/20130422/551fcbd4/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/e29a38aa/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>
vel/attachments/20130422/4564f299/attachment.html>
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>
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
> >
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
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
> >
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;
>>> +
>>
>
d suggest moving up the new
> member, clarifying its name and/or adding a comment explaining what it
> is for.
> Looks good to me other than that.
Sounds good. v3 attached.
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-endian-bugs-in-radeon_atom_get_clock_.patch
Type: text/x-patch
Size: 2716 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/6625079e/attachment.bin>
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 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/
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
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>
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
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
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, alexdeucher at gmail.com wrote:
>> >> From: Alex Deucher
>> >>
>> >>
xed in v2 which is attached.
>
> I'm confused by this patch as well. I assumed the datatypes were
> determined by the hardware spec.
I'm not sure I follow. The atombios interpretor requires data in
little endian format.
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-endian-bugs-in-radeon_atom_get_clock_.patch
Type: text/x-patch
Size: 2723 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/94213d69/attachment.bin>
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
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/
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:
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.
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
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...
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, 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
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
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
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>
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
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
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
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
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
> >> ---
>
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
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,
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
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130422/49849d99/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
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
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: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: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
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
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/
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... ;
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
https://bugs.freedesktop.org/show_bug.cgi?id=62466
Alex Deucher changed:
What|Removed |Added
CC||dino...@libero.it
--- Comment #5 from Ale
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=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.
__
1 - 100 of 126 matches
Mail list logo
