This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++
1
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fc607b22/attachment.html>
On 2014ë
11ì 06ì¼ 22:00, Krzysztof Kozlowski wrote:
> On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote:
>> On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
>>> On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/8d69d5a4/attachment.html>
iving 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/20141106/3d1aa9a1/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9ff4143d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=87791
--- Comment #5 from aCaB ---
Michel,
Thanks for your pointer and sorry for the late answer.
I'll try harder to find a reproducible case (firefox with some large animation
seems to trigger it some times).
In the meantime, if the lockup is a mesa b
Hi Gustavo,
On 2014ë
11ì 06ì¼ 21:38, Gustavo Padovan wrote:
>
> Hi Inki,
>
> Could you please give a review to this series?
It looks good to me. This patch series is just cleanup but not test so I
will merge them next week after testing if there is no any comment.
Thanks,
Inki Dae
>
>
On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
> On 06.11.2014 11:32, Inki Dae wrote:
>> This patch resolves temporarily infinite loop issue incurred
>> when Exynos drm driver is enabled and multi-platform kernel
>> is used by registering Exynos drm device object only in case
>> of Exyno
On Thu, Nov 06, 2014 at 04:49:21PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> drm_gem_object_release() called later in the drm_gem_cma_free_object()
> function already calls this, so there's no need to do this explicitly.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel Vette
On Thu, Nov 06, 2014 at 04:49:16PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Most of the functions already have the beginnings of kerneldoc comments
> but are using the wrong opening marker. Use the correct opening marker
> and flesh out the comments so that they can be integrated w
In all cases the text requires that new drivers are converted to the
atomic interfaces.
v2: Add overview for state handling.
v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba from the plane helpers compat list.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
-
On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> > The atomic users and helpers assume that there is always a obj->state
> > structure around. Which means drivers need to somehow create that at
> > driver load time. Also i
The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.
Finally the destroy/duplicate_state functions are an awful l
Hi Russell,
On Thursday 06 November 2014 00:54:51 Russell King - ARM Linux wrote:
> On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote:
> > (On a side note I believe treating the pitch and size arguments as inputs
> > could be a worthwhile extension to the API, but given that we have
Fix spelling of 'ioctl'.
Signed-off-by: Alex Pilon
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..3d274c1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_c
On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote:
>>> Proposal. Add a new boolean ->active to the crtc state, which will track
>>> the dpms state of the crtc. Add a helper to the atomic core functions
>>> which will compute ->active from the state update according to the
>>> proposals for issue
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: Inki Dae
---
drivers/gpu
From: ykk
dw-hdmi is under drm/bridge, so it should be the bridge mode.
hange off the encoder to dw_hdmi-imx.c, keep the connector &
birdge in dw_hdmi.c
Signed-off-by: ykk
Signed-off-by: Andy Yan
---
drivers/gpu/drm/bridge/dw_hdmi.c | 228 +++---
drivers/stagi
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers. Byte width access (writeb,
readb) generate an imprecise external abort.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/bridge/dw_hdmi.c | 53
1 file changed, 48 insertions(+),
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi
Signed-off-by: Andy Yan
---
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile
imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly difference, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.
To reuse the imx h
We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly difference, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only access by w
On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +retry:
> > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > + if (IS_ERR(crtc_state)) {
> > + r
On 2014ë
11ì 06ì¼ 18:29, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 03:23:27PM +0900, Inki Dae wrote:
>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
>>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
Hi,
I run 3.18-rc3 kernel on BeagleBone Black
On Thu, 06 Nov 2014 16:08:56 +0900
Michel Dänzer wrote:
> On 06.11.2014 03:06, Frederic Plourde wrote:
> > Many features, like animations, hardly depend on page flip timestamps
> > to work properly, but some DRM drivers do not correctly support page flip
> > timestamps (or not at all) and in tha
ent_list, list) {
> /*
>* Add components to master only in case that crtc and
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/78b63f14/attachment.bin>
On 2014ë
11ì 06ì¼ 17:49, Matwey V. Kornilov wrote:
> 2014-11-06 11:45 GMT+03:00 Inki Dae :
>> On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
>>> On 11/06/2014 07:23 AM, Inki Dae wrote:
On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 09:18:46PM +0400,
On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
> On 11/06/2014 07:23 AM, Inki Dae wrote:
>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
>>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
Hi,
I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have E
This patch adds support for the Hitachi TX23D38VM0CAA 9" WVGA TFT LCD panel
to the simple-panel driver.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizo
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d73744..fed0c8d60748 100644
--- a/Doc
This patch adds support for the Innolux G121I1-L01 12.1" TFT LCD panel
to the simple-panel driver.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal
Hi Dave,
A few more radeon fixes for 3.18:
- fix missing crtc unlock in MC setup
- set optimal CE ram config
- use gart rather than vram for DMA IB tests to avoid coherency issues with HDP
- fix a crasher with laptop mode and TDP scripts
The following changes since commit 66338feee458cb2b04e8f2b5
Hi Russell
I'm working on Designware hdmi-audio, also add it as a standard ALSA device.
Before I saw this email, I also planed to submit my patchs to upsteam.
I'm very grateful if you can email those patchs to us.
Best Regards.
äº 2014å¹´11æ04æ¥ 22:29, Russell King - ARM Linux åé:
> On T
On Thu, Nov 6, 2014 at 5:06 PM, Rob Clark wrote:
> On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> After a few atomic irc chats I've shockingly realized that I've completely
>> ignored dpms handling in my helper series. Oops.
>>
>> But there's a few things which are seriousl
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3930670e/attachment.html>
On Thu, Nov 6, 2014 at 10:49 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
> IOCTL, only the width, height, bpp and flags fields are inputs. The
> caller is not guaranteed to zero out or set handle, pitch and size.
> D
9 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/f280695e/attachment-0001.sig>
On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a discussi
t --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fcf157e9/attachment.sig>
From: Thierry Reding
dma_free_writecombine() must not be called on a buffer that couldn't be
allocated. Check for a valid virtual address before attempting to free
the memory to avoid a crash.
Reported-by: Sean Paul
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 2 +-
1 file
From: Thierry Reding
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding
---
Changes in v6:
- c
From: Thierry Reding
The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.
This was tested by injecting err
From: Thierry Reding
drm_gem_object_release() called later in the drm_gem_cma_free_object()
function already calls this, so there's no need to do this explicitly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_gem_cma_helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers
From: Thierry Reding
Some drivers treat the pitch and size fields as inputs and will use them
as minima provided by userspace so that they are only overwritten if the
minimal requirements of the driver exceed them.
This can cause strange behaviour when applications don't zero out these
fields, c
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise th
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible inputs, otherwise th
From: Thierry Reding
This function is similar to drm_gem_cma_dumb_create() but targetted at
kernel internal users so that they can override the pitch and size
requirements of the dumb buffer.
It is important to make this difference because the IOCTL says that the
pitch and size fields are to be
From: Thierry Reding
Most of the functions already have the beginnings of kerneldoc comments
but are using the wrong opening marker. Use the correct opening marker
and flesh out the comments so that they can be integrated with the DRM
DocBook document.
Signed-off-by: Thierry Reding
---
Changes
From: Thierry Reding
Use spaces consistently for indentation in the memory-management
section.
Acked-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 268 -
1 file changed, 134 insertions(+), 134 deletions(-)
diff --
From: Thierry Reding
While at it, adjust the drm_gem_handle_create() function declaration to
be more consistent with other functions in the file.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_gem.c | 11 +--
1 file changed, 5 insertions(+), 6 deletio
From: Thierry Reding
This second version addresses review comments from before. A new patch
is added that removes a redundant call to drm_gem_free_mmap_offset() in
the CMA GEM helpers.
Below is the cover letter from the first version for more background in
case anybody missed it the last time:
On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind
wrote:
> Added a4xx GPU support.
>
> Signed-off-by: Aravind Ganesan
> ---
> Resend the patch-set with the same thread-id
> Resend in patch-set format and with dri-devel at lists.freedesktop.org on
> the CC.
> drivers/gpu/drm/msm/Makefile
On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind
wrote:
> Register offsets have changed between a3xx and a4xx GPUs.
> To be able access these registers in common code, we create
> a lookup table, and set of read-write APIs to access the
> register through the lookup table.
>
> Signed-off-by: Ara
On Fri, Oct 31, 2014 at 11:07 AM, Ganesan, Aravind
wrote:
> Resend the patch-set with the same thread-id
> A set of three patches to support adreno 4xx GPUs in msm-drm:
> (1) Updated the a3xx and a4xx header files.
> (2) Handle register offset differences between a3xx and a4xx GPUs.
> (3) Added a4
On 06/11/14 15:44, Emil Velikov wrote:
> Hi Inki,
>
> With all respect,
>
> On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite
> loop issue incurred
>> when Exyno drm driver is enabled but all kms drivers
>> are disabled on Exynos board by returning -EPROBE_DEFER
>> only in case
Hi Inki,
With all respect,
On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite
loop issue incurred
> when Exyno drm driver is enabled but all kms drivers
> are disabled on Exynos board by returning -EPROBE_DEFER
> only in case that there is kms device registered.
>
I believe it'
On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter wrote:
>
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a discus
On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
>> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
>> set to 'y'.
>> The
On Thu, Nov 6, 2014 at 3:00 PM, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> v3: Review from Sean: Some spelling fixes and drop the misguided
> hunk to remove rgba from the plane he
On Thu, Nov 6, 2014 at 2:57 PM, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
>> > The atomic users and helpers assume that there is always a obj->state
>> > structure around. Which means drivers
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> thanks for your quick response.
>
> Am 06.11.2014 um 10:39 schrieb Jani Nikula:
>> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>>> Hi,
>>>
>>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>>> via a Docking Station (MST)
Hi,
On 2014ë
11ì 05ì¼ 02:18, Matwey V. Kornilov wrote:
> Hi,
>
> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
> set to 'y'.
> The issue here is that the platform probe/init goes to infinite loop
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/5dcde002/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b1634317/attachment.html>
On 11/06/2014 02:18 PM, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 12:35:48PM +0100, Andrzej Hajda wrote:
>> Exynos DSI driver uses DSI bus attach/detach callbacks to implement
>> panel hotplug mechanism. The patch moves panel attachment code
>> from .detect callback to DSI bus callbacks. It m
a DSI bus.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/09098297/attachment.sig>
On Thu, Nov 6, 2014 at 10:57 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> dma_free_writecombine() must not be called on a buffer that couldn't be
> allocated. Check for a valid virtual address before attempting to free
> the memory to avoid a crash.
>
> Reported-by: Sean Paul
nit: I'd p
On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote:
> On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
> > On 06.11.2014 11:32, Inki Dae wrote:
> >> This patch resolves temporarily infinite loop issue incurred
> >> when Exynos drm driver is enabled and multi-platform kernel
> >> is used by
On Thu, Nov 06, 2014 at 04:57:14PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The DRM driver's ->load() implementation didn't do a good job (no job at
> all really) cleaning up on failure. Fix that by undoing any prior setup
> when an error occurs. This requires a bit of rework to ma
On Thu, Nov 6, 2014 at 1:13 PM, Daniel Vetter wrote:
>
> On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> > On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > > +retry:
> > > + crtc_state = drm_atomic_ge
On Wed, Nov 5, 2014 at 5:01 PM, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote:
>> > + if (!crtc && crtc != set->crtc)
>>
>> I think this should be an ||
>
> Hm. My idea idea was actually something along the lines of
> diff --git a/drivers/gpu/drm/drm_atomic_helpe
On Wed, Nov 5, 2014 at 4:44 PM, Daniel Vetter wrote:
> I've applied all the other nits, replies to the more interesting bits
> below.
>
> On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
>> > + if (new_encoder != connector
On 06.11.2014 11:32, Inki Dae wrote:
> This patch resolves temporarily infinite loop issue incurred
> when Exynos drm driver is enabled and multi-platform kernel
> is used by registering Exynos drm device object only in case
> of Exynos SoC. So this patch will be replaced with more generic
> way la
2014-11-06 11:45 GMT+03:00 Inki Dae :
> On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
>> On 11/06/2014 07:23 AM, Inki Dae wrote:
>>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
> Hi,
>
> I run 3.18-rc3
On Sun, Nov 02, 2014 at 02:19:30PM +0100, Daniel Vetter wrote:
> So my original plan was that the drm core refcounts framebuffers like
> with the legacy ioctls. But that doesn't work for a bunch of reasons:
>
> - State objects might live longer than until the next fb change
> happens for a plane.
On Sun, Nov 02, 2014 at 02:19:29PM +0100, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 20 +++
On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> The atomic users and helpers assume that there is always a obj->state
> structure around. Which means drivers need to somehow create that at
> driver load time. Also it should obviously reset hardware state, so
> needs to be reset upo
On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> Currently there is no way to implement async flips using atomic, that
> essentially requires us to be able to cancel pending requests
> mid-flight.
>
> To be able to do that (and I guess we want this since vblank synced
> updates whic
On Sun, Nov 02, 2014 at 02:19:26PM +0100, Daniel Vetter wrote:
> No helper function to do it all yet provided since no driver has
> support for driver core fences yet. Which we'd need to make the
> implementation really generic.
>
> v2: Clarify async howto a bit per the discussion With Rob Clark.
>
On Sun, Nov 02, 2014 at 02:19:25PM +0100, Daniel Vetter wrote:
> This patch is for enabling async commits. It replaces an earlier
> approach which added an async boolean paramter to the ->prepare_fb
> callbacks. The idea is that prepare_fb picks up the right fence to
> synchronize against, which is
Exynos DSI driver uses DSI bus attach/detach callbacks to implement
panel hotplug mechanism. The patch moves panel attachment code
from .detect callback to DSI bus callbacks. It makes the code
simpler and more straightforward.
The patch removes also redundant and lock unprotected dpms_off call
from
On Thu, Oct 23, 2014 at 5:16 PM, Alexandre Courbot
wrote:
> Add the new flags argument to calls of (devm_)gpiod_get*() and
> remove any direction setting code afterwards.
>
> Currently both forms (with or without the flags argument)
> are valid thanks to transitional macros in
> . These macros wi
On Thu, Oct 23, 2014 at 6:46 PM, Andrzej Hajda wrote:
> On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
>> Add the new flags argument to calls of (devm_)gpiod_get*() and
>> remove any direction setting code afterwards.
>>
>> Currently both forms (with or without the flags argument)
>> are valid t
On Thu, Oct 23, 2014 at 6:45 PM, Andrzej Hajda wrote:
> On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
>> Add the new flags argument to calls of (devm_)gpiod_get*() and
>> remove any direction setting code afterwards.
>>
>> Currently both forms (with or without the flags argument)
>> are valid t
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
> via a Docking Station (MST).
>
> During Bootup all three displays work, even when X is started.
> However, if the laptop display is turned off once (either because of
> pow
Hi,
thanks for your quick response.
Am 06.11.2014 um 10:39 schrieb Jani Nikula:
> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>> Hi,
>>
>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>> via a Docking Station (MST).
>>
>> During Bootup all three displays work, even when
sure that we have one module
reference.
> Sure, document it better if you want, but I think something needs to be
> done differently if at all possible.
try_module_get() is the only way I know of that ensures that the code of
a module stays around. Everytime we give out a new reference to a record
we also need to increment the module reference count accordingly to make
sure the underlying code doesn't go away all of a sudden.
I guess that's not entirely accurate. The module reference count doesn't
have to be increment for every record reference, it only needs to track
each record. So the try_module_get() and module_put() could move into
registry_add() and registry_get(), respectively. But the ->owner field
would still be in the record structure.
Would that alleviate your concerns?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/1b589fb1/attachment.sig>
On Thu, Nov 6, 2014 at 10:44 AM, Lucas Stach wrote:
> Signed-off-by: Lucas Stach
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentatio
registry could easily implement as
well. But instead of passing around void * and type IDs as in the
interface tracker it could deal with real objects for proper type-
safety.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/44968ab0/attachment-0001.sig>
Hi all,
After a few atomic irc chats I've shockingly realized that I've completely
ignored dpms handling in my helper series. Oops.
But there's a few things which are seriously wrong with DPMS, so I've
figured I'll start a discussion about them first - converting to atomic
looks like a good time
Hi Inki,
Could you please give a review to this series?
Thanks.
Gustavo
2014-10-31 Gustavo Padovan :
> From: Gustavo Padovan
>
> It is not even used in this header anymore.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 -
> 1 file change
you need to fix this as soon as
possible because this currently causes all sorts of weirdness when
booting a multi-platform kernel on non-Exynos boards. Probably the
easiest for now would be to add some soc_is_exynos*() check at the very
beginning of exynos_drm_init().
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/98dcd330/attachment.sig>
On Thu, Nov 06, 2014 at 05:35:40PM +0800, Kuankuan.Yang wrote:
> I'm working on Designware hdmi-audio, also add it as a standard ALSA device.
> Before I saw this email, I also planed to submit my patchs to upsteam.
> I'm very grateful if you can email those patchs to us.
I've attached the set of p
Hi,
I have a Thinkpad T440s (Haswell) connected to two additional Monitors
via a Docking Station (MST).
During Bootup all three displays work, even when X is started.
However, if the laptop display is turned off once (either because of
power saving, or via xrandr), it fails to "come back".
That i
From: Thierry Reding
Various panels were missing the .bpc field which encodes the number of
bits per color. Not every display driver relies on this value, but since
the panels can be used with any display engine it must be specified so
that if a driver knows how to differentiate based on this fie
p://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b68612f2/attachment.sig>
Hi,
On last next (next-20141104, next-20141105) booting locks after
initializing Exynos DRM (Trats2 board):
[2.028283] [drm] Initialized drm 1.1.0 20060810
[ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
[ 240.510825] Not tainted 3.18.0-rc3-next-20141105 #794
[
> create mode 100644
> Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<
pplication/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/91983c87/attachment.sig>
1 - 100 of 115 matches
Mail list logo
