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 of atomic support.
>>
>> These patches sits on top of t
Hello!
Some misc fixes. Patches are rebased on top of Gustavo's
cleanup series:
http://www.spinics.net/lists/linux-samsung-soc/msg43380.html
With best wishes,
Tobias
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-mixer.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
d
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 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
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.
This was tested with modetest's DRM plane test (from
the libdrm te
from Alex Deucher ---
I approve this request.
--
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/bc99fe8b/attachment.html>
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_funcs.
On Thu, Apr 02, 2015 at 05:59:36PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 02.04.2015, 16:43 +0100 schrieb Russell King - ARM
> Linux:
> > On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
> > > Hey all,
> > >
> > > this is the Etnaviv DRM driver for Vivante embedded GPUs. It is
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 changes
>
> If the drm_connector_find() call retur
On Fri, Apr 03, 2015 at 02:27:46PM -0700, Matt Roper wrote:
> Add tests for destination rectangle integer overflow before calling the
> driver's check function. This will ensure that the transitional plane
> helpers match the behavior of the full atomic helpers by always
> returning -ERANGE for pl
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
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
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
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
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 +++
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:
> 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
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 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
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 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 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
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
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, 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
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
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: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
>> > ---
on/io.c main.c `pkg-config --cflags --libs glfw3 epoxy`
--
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/fcaebd1d/attachment.html>
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
>
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
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/9267b078/attachment.html>
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
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
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
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 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
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
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
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|
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
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
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:
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 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 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
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 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ë
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ì 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ì 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:
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 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
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/f2a7302c/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 #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.
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
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
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
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>
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
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.
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:
> >
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>:
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>
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
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, 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 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_
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 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
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
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
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
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/9f501a14/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/75690ff5/attachment.html>
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>
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
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
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
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
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>
esktop.org/archives/dri-devel/attachments/20150407/99a3c55d/attachment.html>
1 - 100 of 112 matches
Mail list logo
