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/20131024/c226e17c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131024/fcb80b2a/attachment.html>
Hi,
On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote:
> Add simple-phy driver to support a single register
> PHY interfaces present on Exynos4 SoC.
How are these PHY interfaces modelled in the SoC? Where does the register
actually reside?
>
> Signed-off-by: Tomasz Stanislawski
> --
in
the background didn't make it on the screenshot).
R600_DEBUG=nosb
--
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/20
ut that is not shown here.
This is with R600_DEBUG="".
--
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/20131024/59ad8d78/attachment.html>
Hi,
On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote:
> Use default handler of_phy_simple_xlate() when NULL is passed as argument to
> of_phy_provider_register().
>
> Signed-off-by: Tomasz Stanislawski
> ---
> drivers/phy/phy-core.c |2 +-
> 1 file changed, 1 insertion(+), 1 de
On Thu, Oct 24, 2013 at 5:48 PM, Matt Roper
wrote:
> On Mon, Oct 14, 2013 at 01:26:45PM -0400, Rob Clark wrote:
>> Break the mutable state of a plane out into a separate structure
>> and use atomic properties mechanism to set plane attributes. This
>> makes it easier to have some helpers for pla
On Wed, Oct 23, 2013 at 05:36:18PM -0400, Alex Deucher wrote:
> On Sat, Oct 19, 2013 at 10:15 PM, Daniel Mota Leite
> > to the current frequencies. In that app, the powerstate 1 is called
> > battery and the powerstate 2 is called performance.
> >
> > I can switch the two and reflash, but t
Hi Dave,
drm-intel-next-2013-10-18:
- CRC support from Damien and He Shuang. Long term this should allow us to
test an awful lot modesetting corner cases automatically. So for me as
the maintainer this is really big.
- HDMI audio fix from Jani.
- VLV dpll computation code refactoring from Vill
2013/10/23 Rob Clark :
> On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote:
>> Look at omapdrm, nouveau, and radeon drm drivers.
>
>
> btw, please don't look at omapdrm as a "good" example in this regard.
> The layering is really not a good idea and for a long time caused a
> lot of problems, which
On 10/16/2013 07:33 AM, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote:
>> v5:
>> 1 Introduce video.use_native_backlight module parameter and set its
>> value to false by default as suggested by Rafael. For Win8 systems
>> which have broken ACPI video backligh
Correct spelling typo in drivers/gpu/drm/exynos
Signed-off-by: Masanari Iida
# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
# On branch exynos_typo
# Changes to be comm
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131024/78e18dd6/attachment.html>
ou 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/20131024/208a81a9/attachment.html>
2013/10/23 Sean Paul :
> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote:
>>> As I mentioned earlier, display_ops is needed to have no any
>>> dependency of drm framework directly like below,
>>>
>>> DRM Framework
>>>
Jiri Kosina writes:
> On Mon, 21 Oct 2013, Egbert Eich wrote:
>
> > > On Thu, 3 Oct 2013, Daniel Vetter wrote:
> > >
> > > > Can you please attach full dmesg from boot up to the first WARN with
> > > > drm.debug=0xe? This really shouldn't happen and indicates a bug
> > > > somewhere .
On Thu, 24 Oct 2013, Egbert Eich wrote:
> > > > > Can you please attach full dmesg from boot up to the first WARN with
> > > > > drm.debug=0xe? This really shouldn't happen and indicates a bug
> > > > > somewhere ...
> > > >
> > > > A bit difficult ... I originally thought that it was r
On Mon, Oct 14, 2013 at 01:26:45PM -0400, Rob Clark wrote:
> Break the mutable state of a plane out into a separate structure
> and use atomic properties mechanism to set plane attributes. This
> makes it easier to have some helpers for plane->set_property()
> and for checking for invalid params.
uveau-oops.jpg
Type: image/jpeg
Size: 1083671 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/78073692/attachment-0001.jpg>
op 09-10-13 16:39, Maarten Lankhorst schreef:
> Hey,
>
> op 08-10-13 19:37, John Stultz schreef:
>> On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling wrote:
>>> On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
>>> wrote:
Depending on feedback I'll try reflashing my nexus 7 to stock android, a
On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote:
> On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote:
> >
> > In our platform, we hit the the stolen region initialization failure case,
> > such as below log:
> > [drm:i915_stolen_to_physical] *ERROR* conflict detected with
mal bindings. They
should use CDF DT helper functions to get the port and endpoint
information. The helper functions would do the assuming.
Tomi
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/e003f000/attachment-0001.pgp>
; > power sequence, so I believe we should have a generic panel compatible
> > > > > string that would use modes described in DT for the common case. Only
> > > > > if a panel required something more complex which can't (or which
> > > > > could, but won't for any reason) accurately be described in DT would
> > > > > you need to extend the driver.
> > > >
> > > > I don't see the point quite frankly. You seem to be assuming that every
> > > > panel will only be used in a single board.
> > >
> > > No, but in practice that's often the case, at least for boards with .dts
> > > files in the mainline kernel.
> > >
> > > > However what you're proposing will require the mode timings to be
> > > > repeated in every board's DT file, if the same panel is ever used on
> > > > more than a single board.
> > >
> > > Is that a problem ? You could #include a .dtsi for the panel that would
> > > specify the video mode if you want to avoid multiple copies.
> >
> > Yes, I don't think it's desirable to duplicate data needlessly in DT. It
> > also makes the binding more difficult to use. If I know that the panel
> > is one supported by the simple-panel binding, I can just go and add the
> > right compatible value without having to bother looking up the mode
> > timings and duplicating them. That way DT writers get to concern
> > themselves only with the variable data.
>
> I've had a quick chat with Dave Airlie and Hans de Goede yesterday about
> this.
> As most panels will use standard timings, Hans proposed adding a timings
> property that would reference the standard timings the panel uses (this could
> be a string or integer defined in include/dt-bindings/...). In most case DT
> would just have a single property to select the timings, and only in more
> complex cases where the system designer wants to use custom timings would the
> timings need to be manually defined.
We can do the same thing within the kernel. We already have a list of
standard EDID/HDMI/CEA display modes, so we could similarly add a new
list of common display panel modes and make each driver reference that
instead of defining a custom one.
And that still enables us to add a property that would allow DT writers
to override the display mode if they need to.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/1183d002/attachment.pgp>
On Thu, 24 Oct 2013, Jiri Kosina wrote:
> I have this:
>
> [357128.184113] [drm] HPD interrupt storm detected on connector DP-3:
> switching from hotplug detection to polling
>
> It appeared in the log approximately 5 seconds after resume has been
> completed.
Okay, and it just happened durin
On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote:
>
> In our platform, we hit the the stolen region initialization failure case,
> such as below log:
> [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region:
> [0x7b00]
>
> And it causes the dev_priv->mm.stol
I believe we should have a generic panel compatible
> > > > string that would use modes described in DT for the common case. Only
> > > > if a panel required something more complex which can't (or which
> > > > could, but won't for any reason) accurately be described in DT would
> > > > you need to extend the driver.
> > >
> > > I don't see the point quite frankly. You seem to be assuming that every
> > > panel will only be used in a single board.
> >
> > No, but in practice that's often the case, at least for boards with .dts
> > files in the mainline kernel.
> >
> > > However what you're proposing will require the mode timings to be
> > > repeated in every board's DT file, if the same panel is ever used on
> > > more than a single board.
> >
> > Is that a problem ? You could #include a .dtsi for the panel that would
> > specify the video mode if you want to avoid multiple copies.
>
> Yes, I don't think it's desirable to duplicate data needlessly in DT. It
> also makes the binding more difficult to use. If I know that the panel
> is one supported by the simple-panel binding, I can just go and add the
> right compatible value without having to bother looking up the mode
> timings and duplicating them. That way DT writers get to concern
> themselves only with the variable data.
I've had a quick chat with Dave Airlie and Hans de Goede yesterday about this.
As most panels will use standard timings, Hans proposed adding a timings
property that would reference the standard timings the panel uses (this could
be a string or integer defined in include/dt-bindings/...). In most case DT
would just have a single property to select the timings, and only in more
complex cases where the system designer wants to use custom timings would the
timings need to be manually defined.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/8c2fc646/attachment-0001.pgp>
n't the number of endpoints
a system property rather than a device property ? If a port of a device is
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
I've CC'ed Sylwester Nawrocki and Guennadi Liakhovetski, the V4L2 DT bindings
authors, as well as the linux-media list, to get their opinion on this.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131024/357027a1/attachment.pgp>
omapdrm (un)registers irqs inside an irq handler. The problem is that
the (un)register function uses dispc_runtime_get/put() to enable the
clocks, and those functions are not irq safe by default.
This was kind of fixed in 48664b21aeeffb40c5fa06843f18052e2c4ec9ef
(OMAPDSS: DISPC: set irq_safe for r
On 09/29/2013 05:12 PM, Daniel Vetter wrote:
> Please boot with drm.debug=0xe, reproduce the WARN and then attach the
> full dmesg.
>
This is a segfault on kernel 3.11.3. There's no X started yet, but one
s2ram cycle.
Attached is the complete dmesg with drm.debug=0xe or on
http://pastebin.com/ra
On Mon, 21 Oct 2013, Egbert Eich wrote:
> > On Thu, 3 Oct 2013, Daniel Vetter wrote:
> >
> > > Can you please attach full dmesg from boot up to the first WARN with
> > > drm.debug=0xe? This really shouldn't happen and indicates a bug
> > > somewhere ...
> >
> > A bit difficult ... I origi
On Thu, Oct 24, 2013 at 2:50 AM, Tomi Valkeinen
wrote:
> omapdrm (un)registers irqs inside an irq handler. The problem is that
> the (un)register function uses dispc_runtime_get/put() to enable the
> clocks, and those functions are not irq safe by default.
>
> This was kind of fixed in 48664b21ae
https://bugzilla.kernel.org/show_bug.cgi?id=63391
--- Comment #8 from Tasev Nikola ---
Hi,
I start the bisect yesterday between 3.12-rc1 and 3.12-rc2.
I will report when i'm finish.
--
You are receiving this mail because:
You are watching the assignee of the bug.
blob.
--
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/20131024/49d19429/attachment.html>
33 matches
Mail list logo
