On 2015ë
04ì 07ì¼ 15:59, Joonyoung Shim wrote:
> It's more reasonable to use src_x and src_y to represent source as
> counterpart of destination(crtc). Already we are using src_width and
> src_height for width and height of source.
1 thourgh 2, Applied.
Thanks,
Inki Dae
>
> Signed-off-by:
On 2015ë
04ì 07ì¼ 08:14, Tobias Jakobi wrote:
> Use the correct spelling for 'progressive'.
1 through 3, Applied.
Thanks,
Inki Dae
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.
On 2015ë
04ì 02ì¼ 18:52, Hyungwon Hwang wrote:
> Because the helper function which calls this callback checks whether
> it is registered or not. It is not necessary if it does nothing.
> So it would be better to remove the function for clarity.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by:
On 2015ë
04ì 01ì¼ 13:14, Hyungwon Hwang wrote:
>>From the commit "drm/exynos: fix the execution order in FIMD
> initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
> checking code is removed improperly. This patch fix the regression.
Applied.
Thanks,
Inki Dae
>
> Signed-o
On 2015ë
03ì 28ì¼ 01:08, Krzysztof Kozlowski wrote:
> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
>
> The reason for this suggested Andrz
On Tue, Apr 07, 2015 at 06:59:59PM +0200, Christian Gmeiner wrote:
> Hi Lucas.
>
> 2015-04-07 17:29 GMT+02:00 Lucas Stach :
> > And I don't get why each core needs to have a single device node. IMHO
> > this is purely an implementation decision weather to have one device
> > node for all cores or
On 2015ë
04ì 07ì¼ 20:57, Hyungwon Hwang wrote:
> This patch adds support for Exynos5433 mipi dsi.
With this and other dsi relevant patches, display doesn't work - the
screen is flickered and booting is halted. I think there is something
you missed. Check it out again.
Thanks,
Inki Dae
>
>
On 2015ë
04ì 07ì¼ 20:57, Hyungwon Hwang wrote:
> This patch makes the driver use arrays for clocks, register address,
> and values. By doing this, it becomes easier to add support for another
> SoC.
This patch includes three types. First is to use an array for clocks,
second is to use macro,
On 2015ë
04ì 07ì¼ 20:57, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly.
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes for v3:
I don't know if I can really help with this, but I'm going to try to
reproduce this on my board tomorrow.
With best wishes,
Tobias
Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-07 Inki Dae :
>
>> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
On 20
On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
MIC must be initilized by MIPI DSI when it is being bound.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
.../devicetree/bindings/video/exynos_dsim.txt | 23 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c|
This patch adds support for Exynos5433 mipi dsi.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support for
This patch makes the driver use arrays for clocks, register address,
and values. By doing this, it becomes easier to add support for another
SoC.
Signed-off-by: Hyungwon Hwang
---
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
in version 2.
Changes f
This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
is actually not the pll input clock for dsi. The pll input clock comes
from the board's oscillator directly.
Signed-off-by: Hyungwon Hwang
---
Changes for v3:
- Newly added
Changes for v4:
- None
.../devicetree/bindings/vid
MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.
Signed-off-by: Hyungwon Hwan
When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the o
From: Joonyoung Shim
DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.
Signed-off-by: Joonyoung Shim
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change file names and variable names of decon to represnt exynos5433
This patchset is based on the git(branch name: exynos-drm-next) which is
maintained by Inki Dae.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/...
This patchset adds 2 new device drivers, decon and mic, and adds support for
Exynos5433 mipi dsi. To enable display in a Exynos5433 board, d
could even prevent new users from
transitioning to Linux.
--
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/20150407/c5f4616b/at
On 2015ë
03ì 04ì¼ 23:02, Marek Szyprowski wrote:
> From: Beata Michalska
>
> As for now there is no validation of incoming buffer
> enqueue request as far as the gem buffers are being
> concerned. This might lead to some undesired cases
> when the driver tries to operate on invalid buffers
>
. I am confused if I am
actually doing anything here.
--
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/20150407/2b66feab/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/3c1a738a/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/60e190e0/attachment.html>
esktop.org/archives/dri-devel/attachments/20150407/99a3c55d/attachment.html>
On 2015ë
04ì 07ì¼ 16:06, Inki Dae wrote:
> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on ex
i as second screen
with xrandr from X already started.
--
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/20150407/ddad95c6/attachment.html>
On Tue, Apr 07, 2015 at 02:52:31PM +0200, Lucas Stach wrote:
> Am Dienstag, den 07.04.2015, 11:46 +0100 schrieb Russell King - ARM
> Linux:
> >
> > For both Vivante and Etnaviv, it's already the accepted way that 2D
> > cores need the full context loaded for each operation, and the few
> > userspa
Signed-off-by: John Hunter
---
drivers/gpu/drm/drm_atomic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 57efdbe..0537f32 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -7
Hi Lucas.
2015-04-07 17:29 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 17:13 +0200 schrieb Christian Gmeiner:
>> 2015-04-07 17:01 GMT+02:00 Lucas Stach :
>> > Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:
>> >>
>> >>
>> >> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/75690ff5/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/9f501a14/attachment.html>
On Tue, Apr 7, 2015 at 12:59 PM, Christian Gmeiner
wrote:
>>> And each Core(/FE) has its own device node. Does this make any sense?
>>>
>> And I don't get why each core needs to have a single device node. IMHO
>> this is purely an implementation decision weather to have one device
>> node for all
On Tue, Apr 07, 2015 at 11:29:43AM -0300, Paulo Zanoni wrote:
> 2015-04-06 23:11 GMT-03:00 Todd Previte :
> > For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
> > device must attempt at least 7 times to read the EDID when it receives an
> > I2C defer. The normal DRM code m
Am Dienstag, den 07.04.2015, 17:13 +0200 schrieb Christian Gmeiner:
> 2015-04-07 17:01 GMT+02:00 Lucas Stach :
> > Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:
> >>
> >>
> >> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher
> >> wrote:
> >> On Tue, Apr 7, 2015 at 3:46 AM, Lu
On Tue, Apr 07, 2015 at 03:56:07PM +0200, Maarten Lankhorst wrote:
> If kref_put_mutex returns true then the caller or the put function is
> responsible
> for unlocking the mutex.
This patch introduces the kref_put_mutex() usage, so this commit
message is rather confusing.
>
> Signed-off-by: Ma
On 04/ 1/15 09:15 AM, Emil Velikov wrote:
> The former does not imply the latter and vice-versa. One such example is
> the Sun compiler.
>
> v2: Add missing closing brakets. (Alan)
s/brakets/brackets/
Other than that, looks good to me.
Reviewed-by: Alan Coopersmith
>
> Cc: Alan Coopersmith
>
On Tue, Apr 07, 2015 at 04:23:55PM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 07-04-15 om 16:19 schreef Ville Syrjälä:
> > On Tue, Apr 07, 2015 at 03:56:07PM +0200, Maarten Lankhorst wrote:
> >> If kref_put_mutex returns true then the caller or the put function is
> >> responsible
> >> for u
2015-04-07 17:01 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:
>>
>>
>> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher
>> wrote:
>> On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach
>> wrote:
>> > Am Sonntag, den 05.04.2015, 21:41 +0200
Am Dienstag, den 07.04.2015, 16:52 +0200 schrieb Christian Gmeiner:
> 2015-04-07 16:38 GMT+02:00 Alex Deucher :
> > On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach
> > wrote:
> >> Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
> >>> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Li
I don't believe anyone has RE'd anything yet.
>
> Multicore with a single FE is just a single pipe with chip selects set
> to the available backends and mirrored pagetables for the MMUs. With
> more than one FE you get more than one pipe which is more like a SLI
> setup on the desktop, where userspace has to deal with splitting the
> render targets into portions for each GPU.
Yes, the galcore makes this a configuration option at build time supporting
both configs.
> One more reason to keep things in one DRM device, as I think no one
> wants to deal with syncing pagetables across different devices.
>
> Regards,
> Lucas
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/2d286a01/attachment.html>
ure it is easier that cirrus.
>
> cheers,
> Gerd
>
>
>
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachmen
On 07.04.2015 16:52, Christian Gmeiner wrote:
> 2015-04-07 16:38 GMT+02:00 Alex Deucher :
>> On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach
>> wrote:
>>> Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux >>> arm.linux.org.uk>:
On Wed, Mar 11, 2015 at 11:51:06AM +0200, Jani Nikula wrote:
> They are not to be modified.
>
> Generated using the semantic patch:
>
> @@
> @@
> (
> const struct drm_crtc_helper_funcs *
> |
> - struct drm_crtc_helper_funcs *
> + const struct drm_crtc_helper_funcs *
> )
>
> @@
> @@
> (
> con
Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:
>
>
> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher
> wrote:
> On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach
> wrote:
> > Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian
> Gmeiner:
> >
2015-04-07 16:38 GMT+02:00 Alex Deucher :
> On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach wrote:
>> Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
>>> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux >> arm.linux.org.uk>:
>>> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas S
combination is present depends on the asic.
>
>
That reminds me. We should also have in the back of our heads that compute
is supported by the newer Vivante chips. We will also need to support
multiple independent 3d cores as that support has shown up in the V5
galcore drivers.
-Jon
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/b3c04641/attachment-0001.html>
Hey,
Op 07-04-15 om 16:19 schreef Ville Syrjälä:
> On Tue, Apr 07, 2015 at 03:56:07PM +0200, Maarten Lankhorst wrote:
>> If kref_put_mutex returns true then the caller or the put function is
>> responsible
>> for unlocking the mutex.
> This patch introduces the kref_put_mutex() usage, so this c
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #20 from Frederik vom Hofe ---
That fixes it for me.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On 04/07/2015 03:26 AM, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-05 Inki Dae :
>
>> Hi,
>>
>> 2015-04-04 3:09 GMT+09:00 Gustavo Padovan :
>>> From: Gustavo Padovan
>>>
>>> Run dpms operations through the atomic intefaces. This basically removes
>>> the .dpms() callback from econders an
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> While the VP (video processor) supports arbitrary scaling
> of its input, the mixer just supports a simple 2x (line
> doubling) scaling. Expose this functionality and exit
> early when an unsupported scaling configuration is
> encountered.
>
> Th
On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes the full support for atomic modesetting on exynos. I've
>>> split the patches in the various phases
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> The messages are redundant since 'check_fb_gem_memory_type'
> already prints out exactly the same string when it fails.
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +++
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> Use the correct spelling for 'progressive'.
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> drivers/gpu/drm/exynos/regs-mix
Calculation ratio from exynos_drm plane codes, then each hw drivers can
use it without extra operation. Also this fixes width and height of
source used for actual crtc shown via screen.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4
drivers/gpu/drm/exynos/e
It's more reasonable to use src_x and src_y to represent source as
counterpart of destination(crtc). Already we are using src_width and
src_height for width and height of source.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 4 ++--
drivers/gpu/drm/exynos/exynos
From: Gustavo Padovan
Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms
If kref_put_mutex returns true then the caller or the put function is
responsible
for unlocking the mutex.
Signed-off-by: Maarten Lankhorst
---
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 1e6ae1458f7a..7a592d7e398b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem
> On Thu, Apr 02, 2015 at 10:29:52AM -0400, Rob Clark wrote:
>> So, from a quick look, it seems like there is a lot of potential to
>> split the v4l part out into some drm helpers.. it looks pretty
>> generic(ish), or at least it could be with some strategically placed
>> vfuncs in drm_v4l2_helper_
On Tue, Apr 7, 2015 at 3:29 PM, George McCollister
wrote:
> Looks like these are the magic bits that need to be set:
>
> dpll |= (7<<9) | (1<<13) | (1<<14);
>
> Anyone happen to have proper descriptions for these bits so I could
> add them to psb_intel_reg.h or thoughts on how/where an option coul
On Tue, Apr 07, 2015 at 07:38:50PM +0800, John Hunter wrote:
> Signed-off-by: John Hunter
Applied to topic/drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/d
Adding drm helper function to return plane pointer from index where
index is a returned by drm_plane_index.
v2:
-avoided nested loop by adding loop count (Daniel)
v3:
-updated patch header prefix to 'drm' (Matt)
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Chandra Konduru
---
drivers
r Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/5f4015c3/attachment.html>
Am Dienstag, den 07.04.2015, 12:31 +0100 schrieb Russell King - ARM
Linux:
> On Tue, Apr 07, 2015 at 11:05:50AM +0200, Lucas Stach wrote:
> > A pipe is now simply a channel to a single GPU core. If a given core is
> > able to execute 2d, 3d or vg state is a matter of looking at the feature
> > bits
https://bugzilla.kernel.org/show_bug.cgi?id=89731
--- Comment #4 from Alex Deucher ---
Can you try the latest patch on bug 61891?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Am Dienstag, den 07.04.2015, 11:46 +0100 schrieb Russell King - ARM
Linux:
> On Tue, Apr 07, 2015 at 11:20:10AM +0200, Lucas Stach wrote:
> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> > > What role does GPU power management plays here? For the context switching
> > > it
Hi Inki,
2015-04-07 Inki Dae :
> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> > 2015-04-06 19:46 GMT+09:00 Inki Dae :
> >> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan
> >>>
> >>> Hi,
> >>>
> >>> Here goes the full support for atomic modesetting on exynos.
Looks like these are the magic bits that need to be set:
dpll |= (7<<9) | (1<<13) | (1<<14);
Anyone happen to have proper descriptions for these bits so I could
add them to psb_intel_reg.h or thoughts on how/where an option could
be exposed to enable these?
On Mon, Apr 6, 2015 at 4:48 PM, George
https://bugzilla.kernel.org/show_bug.cgi?id=93701
--- Comment #19 from Alex Deucher ---
Updated patches here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes
--
You are receiving this mail because:
You are watching the assignee of the bug.
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/f2a7302c/attachment-0001.html>
Hi Jianwei,
On 2015-04-07 08:44, Jianwei.Wang at freescale.com wrote:
> Hi Stefan,
>
> Thank you for your review and testing on Vybrid F610 device. This driver
> just implement the basic functions and it only support the exported
> framebuffer access. Some DRM interfaces are not implemented now
Add writeback support in msm kms framework.
V1: Initial change
V2: Address Rob/Paul/Emil's comments
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/Kconfig | 10 +
drivers/gpu/drm/msm/Makefile | 7 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
If the GEM object is imported, drm_prime_gem_destroy needs to be
called to clean up dma buffer related information.
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/msm_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index
On Tue, 07 Apr 2015, Daniel Vetter wrote:
> On Fri, Apr 03, 2015 at 10:45:29AM +0300, Tommi Rantala wrote:
>> Regression in commit 2caa80e72b57c6216aec6f6a11fcfb4fec46daa0
>> Author: Daniel Vetter
>> Date: Sun Feb 22 11:38:36 2015 +0100
>>
>> drm: Fix deadlock due to getconnector locking c
Hi Inki,
2015-04-07 Inki Dae :
> On 2015ë
04ì 07ì¼ 16:06, Inki Dae wrote:
> > On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> >> 2015-04-06 19:46 GMT+09:00 Inki Dae :
> >>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> Here
On Tue, Apr 07, 2015 at 11:05:50AM +0200, Lucas Stach wrote:
> A pipe is now simply a channel to a single GPU core. If a given core is
> able to execute 2d, 3d or vg state is a matter of looking at the feature
> bits for this pipe. Why would we need a full blown DRM device for that?
> On i.MX6 you
Am Dienstag, den 07.04.2015, 11:58 +0200 schrieb Christian Gmeiner:
> Hi Lucas.
>
> 2015-04-07 11:47 GMT+02:00 Lucas Stach :
> > Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
> >> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
> >> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb
Hi Lucas.
2015-04-07 11:47 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
>> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
>> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
>> >> Hi Lucas
>> >>
>> >> 2015-04-07 9:35 GMT+02:00 Lucas S
versus post-
condition, as follows:
...
if (++aux->i2c_defer_count < 7)
...
...
>
>> + retry--;
>> usleep_range(400, 500);
>> continue;
>>
>> --
>> 1.9.1
>>
>> ___
>> 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/20150407/4bdb1406/attachment.html>
Am Dienstag, den 07.04.2015, 11:40 +0200 schrieb Christian Gmeiner:
> 2015-04-07 11:20 GMT+02:00 Lucas Stach :
> > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> >> Hi Lucas
> >>
> >> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
> >> > Am Sonntag, den 05.04.2015, 21:26 +0200 schri
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/9267b078/attachment.html>
On Tue, Apr 07, 2015 at 11:20:10AM +0200, Lucas Stach wrote:
> Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> > What role does GPU power management plays here? For the context switching
> > it could make sense. But for the 2d core the context is so small that
> > it does not
On Do, 2015-04-02 at 17:52 +0200, Marc-André Lureau wrote:
> Perhaps that condition should be changed:
> + BUG_ON(size >= MAX_INLINE_CMD_SIZE);
Done.
thanks,
Gerd
2015-04-07 11:20 GMT+02:00 Lucas Stach :
> Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
>> Hi Lucas
>>
>> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
>> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
>> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> >> > Fro
2015-04-06 23:11 GMT-03:00 Todd Previte :
> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
> device must attempt at least 7 times to read the EDID when it receives an
> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
> or not the response is a
Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner:
> Hi Lucas
>
> 2015-04-07 9:35 GMT+02:00 Lucas Stach :
> > Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> >> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> >> > From: Christian Gmeiner
> >> >
> >> > This is a co
Am Dienstag, den 07.04.2015, 10:03 +0200 schrieb Christian Gmeiner:
> Hi Lucas
>
> 2015-04-07 9:46 GMT+02:00 Lucas Stach :
> > Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
> >> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux >> arm.linux.org.uk>:
> >> > On Thu, Apr 02, 2
Hi Lucas
2015-04-07 9:35 GMT+02:00 Lucas Stach :
> Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> > From: Christian Gmeiner
>> >
>> > This is a consolidation by Russell King of Christian's drm work.
>> >
>> > Signed-off-by: Christ
Hi,
> I think at least I should give it a try. If it is really impossible to
> convert, then
> we should talk about whether we should deprecate it in the future.
Feel free to try. I don't mind being proven wrong ;)
> And I hope to treat cirrus as an test filed, it's a easier driver, so
> I c
On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach wrote:
> Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux > arm.linux.org.uk>:
>> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
>> >> While this isn't the case on i
Hi Lucas,
2015-04-07 9:26 GMT+02:00 Lucas Stach :
> Am Sonntag, den 05.04.2015, 20:51 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 17:30 GMT+02:00 Lucas Stach :
>> > Allows userspace to properly synchronize with the GPU when accessing
>> > buffers.
>> >
>> > Signed-off-by: Lucas Stach
>> > ---
Hi Lucas
2015-04-07 9:24 GMT+02:00 Lucas Stach :
> Hi Christian,
>
> Am Sonntag, den 05.04.2015, 20:32 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
>> > IOMMUv2 support isn't implemented yet, so don't pretend it is there.
>> >
>> > Signed-off-by: Lucas Stach
>> > -
Hi Lucas
2015-04-07 9:46 GMT+02:00 Lucas Stach :
> Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
>> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux > arm.linux.org.uk>:
>> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
>> >> While this isn't the case on i.M
Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux arm.linux.org.uk>:
> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
> >> While this isn't the case on i.MX6 a single GPU pipe can have
> >> multiple rendering ba
2015-04-02 17:30 GMT+02:00 Lucas Stach :
> Dumb buffers must be only used as backing storage for scanout
> only surfaces. Any acceleration operation on them is not allowed.
>
> So there is no point in having dumb buffer support in a driver
> that isn't able to drive any scanout hardware.
>
> Signed
Hi Lucas
2015-04-02 17:30 GMT+02:00 Lucas Stach :
> This is a simple rename without functional changes.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/staging/etnaviv/etnaviv_drv.c | 10 +-
> drivers/staging/etnaviv/etnaviv_drv.h | 12 ++--
> drivers/staging/etnaviv/e
Am Sonntag, den 05.04.2015, 21:26 +0200 schrieb Christian Gmeiner:
> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> > From: Christian Gmeiner
> >
> > This is a consolidation by Russell King of Christian's drm work.
> >
> > Signed-off-by: Christian Gmeiner
> > Signed-off-by: Russell King
> > ---
[..
Am Sonntag, den 05.04.2015, 20:51 +0200 schrieb Christian Gmeiner:
> 2015-04-02 17:30 GMT+02:00 Lucas Stach :
> > Allows userspace to properly synchronize with the GPU when accessing
> > buffers.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/staging/etnaviv/etnaviv_gem.c | 18 +--
Hi Christian,
Am Sonntag, den 05.04.2015, 20:32 +0200 schrieb Christian Gmeiner:
> 2015-04-02 17:29 GMT+02:00 Lucas Stach :
> > IOMMUv2 support isn't implemented yet, so don't pretend it is there.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/staging/etnaviv/etnaviv_gpu.c | 10
On Do, 2015-04-02 at 09:57 +0800, John Hunter wrote:
> Hi Daniel,
> Sorry to disturb you, I realized you are a busy man of the community.
> So I did some work before I email you.
>
>
> I submit my proposal as you suggest, convert the two virtual driver
> (CIRRUS
> and BOCHS, if I remember it rig
1 - 100 of 112 matches
Mail list logo
