exynos_dsi_host_transfer() can be called through a panel driver while
DSI is turning down. It is possible because the function checks only
whether DSI is initialized or not, and there is a moment which DSI is
set by uninitialized, but DSI is still turning down. To prevent it,
DSI must be set by dis
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150608/21411697/attachment.html>
A race condition between drm_release and drm_mode_rmfb can result in
mdp5_crtc_disable() accessing mdp5_crtc->ctl when its already been set
to NULL by a complete_flip() which disables the crtc.
Move the ctl register write within complete_flip() when the crtc state
is disabled.
Signed-off-by: Arch
On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2015-06-07, Ville Syrjälä wrote:
> > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > > Hi
> > >
> > > On 2015-04-20, Dave Airlie wrote:
> > > [...]
> > > > The following changes since comm
In the commit below, I missed the connector allocation in the function
intel_sdvo_analog_init(), leading to those connectors to have a NULL
state pointer.
commit 08d9bc920d465d762cac9383249c19bf69a2
Author: Ander Conselvan de Oliveira
Date: Fri Apr 10 10:59:10 2015 +0300
drm/i915: Allo
On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote:
> On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > On 2015-06-07, Ville Syrjälä wrote:
> > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > > > Hi
> > > >
> > > >
> Also, like on radeon, this does not seems to be safe against fence seq
> wrap around. I know 64bits require a long uptime. But this might be
> something we will want to fix.
Well, I've got two good arguments that the current implementation is
fine as it is:
1. It was *your* suggestion to do so.
Hi Inki,
Those patches fixes issue of exynos_drm initialization with more than one
pipeline,
which is present in exynos_drm drivers for long time.
On most platforms at least two of three following pipelines are present:
1. VIDI.
2. FIMD/DECON -> DSI/DPI -> Panel.
3. MIXER/DECON -> HDMI -> TV.
In
Code registering different drivers and simple platform devices was dispersed
across multiple sub-modules. This patch moves it to one place. As a result
initialization code is shorter and cleaner and should simplify further
development.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exyn
In case there are multiple pipelines and deferred probe occurs, only components
of the first pipeline were bound. As a result only one pipeline was available.
The main cause of this issue was dynamic generation of component match table -
every component driver during probe registered itself on help
SoC checking code is not necessary anymore, as exynos_drm_match_add and
exynos_drm_platform_probe already properly handles situation when there are
no Exynos DRM components.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 27 +--
1 file changed,
Thanks for testing.
Forwarded Message
From: Stefan Lippers-Hollmann
To: Ander Conselvan de Oliveira
Subject: Re: [PATCH] drm/i915: Properly initialize SDVO analog
connectors
Date: Mon, 8 Jun 2015 12:16:04 +0200
Hi
On 2015-06-08, Ander Conselvan de Oliveira wrote:
> In the com
On Sat, 06 Jun 2015, Linus Torvalds wrote:
> On Fri, Jun 5, 2015 at 11:58 PM, Dave Airlie wrote:
>>
>> i915 has a bunch of fixes [..]
>
> .. but nof ix for the regression that Stefan Lippers-Hollmann
> reported? An oops in intel_modeset_update_connector_atomic_state() due
> to commit 08d9bc920d46
On Mon, 08 Jun 2015, Ander Conselvan de Oliveira wrote:
> In the commit below, I missed the connector allocation in the function
> intel_sdvo_analog_init(), leading to those connectors to have a NULL
> state pointer.
>
> commit 08d9bc920d465d762cac9383249c19bf69a2
> Author: Ander Conselvan de
to be optional to handle the i.MX,
though. Or perhaps a dummy regulator could be referenced, representing
the SoC-internal supply to the block. Maybe there even is a (SoC-
specific) way to control this internal regulator?
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/20150608/a9533e31/attachment.sig>
That computes
a default mode from the typical values of the display timings.
Alternatively you can also implement display timings support in your
display driver and directly use the ->get_timings() callback for the
panel you have.
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/20150608/f49c3f93/attachment.sig>
Hi David, Philipp, Andy, Russell,
On 19.05.2015 17:39, Andy Yan wrote:
> Hi Vladimir,
>Thanks for you patch.
>
> On 2015å¹´05æ18æ¥ 20:32, Vladimir Zapolskiy wrote:
>> I2CM_ADDRESS became a MESS, fix it, also change guarding define
>> to __DW_HDMI_H__ , since the driver is not IMX specific.
On Mon, Jun 08, 2015 at 04:02:58PM +0200, Thierry Reding wrote:
> On Sat, Jun 06, 2015 at 12:10:58AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote:
> > > Hi Thierry
> > >
> > > Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding:
>
to check parameters before
calling drmModeDirtyFB(...).
--
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/20150608/edb77
et(hdmi->dev,
> + hdmi->nsupplies, hdmi->supplies);
I think it'd be slightly more idiomatic to put hdmi->nsupplies on the
first line.
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/20150608/8280d80d/attachment.sig>
On 06/06/15 00:13, Dave Airlie wrote:
> On 6 June 2015 at 00:05, Jyri Sarha wrote:
>> David,
>> Please pull the contents of "Use DRM component API in tilcdc to
>> connect to tda998x" patch series[1] from:
>>
>> https://github.com/jsarha/linux.git linux-4.1.0-rc6-tilcdc-refactor
>
> I think I pulle
acts to make proper decisions, and wrong decisions can very
> well lead to serious headaches later on because we didn't model
> something correctly - and we're stuck with the wrong decisions for ever.
I feel the same way. Although there have been occasional exceptions to
the DT ABI stability rule if it could be proven that an existing binding
was completely wrong, I've made the experience that putting as little as
possible into DT (and at the same time resist the temptation of a
generic solution) helps keep the headaches in check.
Fortunately the dw-hdmi driver gets much of this right already (it's
helper code rather than a proper driver), so keeping things like power
supplies specific to a particular integration should be easy to do and
prevent potential future incompatibilities.
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/20150608/649817de/attachment-0001.sig>
Hello Dave,
I have prepare this serie of minor patches for drm-next.
Mainly it is fixing timing on HDMI to be compliant with CEA-861E spec.
It is also the chance for me to introduce you Vincent Abriou who will help me to
maintain sti drm driver.
Regards,
Benjamin
The following changes since com
Hello Thierry,
Am 05.06.2015 14:19, schrieb Thierry Reding:
> On Wed, May 06, 2015 at 09:49:33AM +0200, Heiko Schocher wrote:
>> The patch adds LG4573 parallel RGB panel driver with SPI control interface.
>> The driver uses drm_panel framework.
>
> This should be obvious by the location of the dri
Hi
On 2015-06-08, Ander Conselvan De Oliveira wrote:
> On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote:
> > On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> > > On 2015-06-07, Ville Syrjälä wrote:
> > > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Li
t moved the plane config to
be done after crtc enable. I dropped that patch.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150608/248ca9c0/attachment-0001.sig>
Hi Boris,
On 05/06/15 12:39, Boris Brezillon wrote:
> Hi Jon,
>
> On Fri, 5 Jun 2015 09:46:09 +0100
> Jon Hunter wrote:
>
>>
>> On 05/06/15 00:02, Paul Walmsley wrote:
>>> Hi folks
>>>
>>> just a brief comment on this one:
>>>
>>> On Thu, 30 Apr 2015, Boris Brezillon wrote:
>>>
Clock rates
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
> series of patches last year that, with a few changes, it's possible to
> let the algorithm I've used (dfs) to spit out all drivers which can be
> initialized in parallel.
Unf
On 06/06/15 07:09, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thursday 04 June 2015 12:02:58 Tomi Valkeinen wrote:
>> omap_crtc_disable() waits for pending page flips to finish. However,
>> omap_crtc_disable() is always called via omap_atomic_complete() and we
>> neve
On Mon, Jun 08, 2015 at 05:44:53PM +0200, Thierry Reding wrote:
> On Mon, Jun 08, 2015 at 03:29:26PM +0100, Russell King - ARM Linux wrote:
> > You're asking questions we have no real answers to - all we have is the
> > available documentation provided by Freescale - we don't even have the
> > Roch
On 08.06.2015 18:26, James Feeney wrote:
> atombios_crtc.c
>
> In multi-display configurations, especially with three or more displays,
> PLL/clock source allocations can fail when there are more crtc's than PLLs.
> When attempting to debug these PLL allocation failures in the source code, the
> er
> -Original Message-
> From: James Feeney [mailto:james at nurealm.net]
> Sent: Monday, June 08, 2015 1:10 PM
> To: Koenig, Christian; Deucher, Alexander
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: atombios_crtc.c - make error messages distinguishable "unable
> to allocate a PPL
https://bugzilla.kernel.org/show_bug.cgi?id=99651
Bug ID: 99651
Summary: third monitor connected via dvi does not work on
radeonhd 7770
Product: Drivers
Version: 2.5
Kernel Version: 4.0.5 and higher (tested on 4.1-rc7 also)
> -Original Message-
> From: James Feeney [mailto:james at nurealm.net]
> Sent: Monday, June 08, 2015 3:43 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: atombios_crtc.c - make error messages distinguishable "unable
> to allocate a PPL
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #17 from gitne at excite.co.jp ---
(In reply to Alex Deucher from comment #16)
> Created attachment 178141 [details]
> possible fix
>
> Does the attached patch help?
Thank you for proposing a possible solution. Unfortunately, I do not
On Sat, Jun 06, 2015 at 05:21:41PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/6/2015 6:30 AM, Matt Roper wrote:
> >On Thu, Jun 04, 2015 at 07:12:35PM +0530, Kausal Malladi wrote:
> >>From: Kausal Malladi
> >>
> >>This patch adds a new structure in DRM layer for Gamma color corre
On Sat, Jun 06, 2015 at 05:24:46PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/6/2015 6:30 AM, Matt Roper wrote:
> >On Thu, Jun 04, 2015 at 07:12:36PM +0530, Kausal Malladi wrote:
> >>From: Kausal Malladi
> >>
> >>This patch adds a new function to update color blob properties
> >
On Sat, Jun 06, 2015 at 05:34:45PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/6/2015 6:31 AM, Matt Roper wrote:
> >On Thu, Jun 04, 2015 at 07:12:37PM +0530, Kausal Malladi wrote:
> >>From: Kausal Malladi
> >>
> >>The atomic CRTC set infrastructure is not available yet. So, the a
atombios_crtc.c
In multi-display configurations, especially with three or more displays,
PLL/clock source allocations can fail when there are more crtc's than PLLs.
When attempting to debug these PLL allocation failures in the source code, the
error message displayed in the log, DRM_ERROR("unable
> DCE4 parts (like the 5570) only have an external clock if the OEM supplied
> it, hence not all boards have it. Also, the external clock source can only
> be used to drive native DP (DisplayPort), not non-DP outputs like DVI or HDMI
> or VGA or a passive DP to DVI/HDMI convertor. If you are usin
> Actually it's always the same error. The message just appears in that file
> multiple times for different hardware generations.
Which is fine, presupposing that the user already knows what hardware generation
they are using _and_ how the video card manufacturer actually implemented the
display i
Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
> Am 04.06.2015 um 22:39 schrieb Alexander Holler:
>
> > As it seems to have been forgotten or overread, I've mentioned in my
>> series of patches last year that, with a few changes, it's possible to
>> let the algorithm I've used (d
Am 08.06.2015 um 20:14 schrieb Alexander Holler:
> Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
>> Am 04.06.2015 um 22:39 schrieb Alexander Holler:
>>
>> > As it seems to have been forgotten or overread, I've mentioned in my
>>> series of patches last year that, with a few chan
On Fri, Jun 5, 2015 at 2:57 PM, Jerome Glisse wrote:
> On Tue, May 26, 2015 at 11:19:31PM -0400, Alex Deucher wrote:
>> This header defines the ioctl interface to the driver.
>>
>> v2: remove stale tiling defines
>> v3: add appropriate padding
>> v4: remove executable bits on header
>>
>> Acked-by
44 matches
Mail list logo
