--
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/20140606/2f3c845c/attachment.html>
On Fri, 6 Jun 2014 10:22:51 -0700 "Paul E. McKenney" wrote:
> On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote:
> > From: Behalf Of Ken Helias
> > > All other add functions for lists have the new item as first argument and
> > > the
> > > position where it is added as second argument
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/48597e21/attachment.html>
unning without problems for 45 minutes now.
--
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/20140606/f1168dc0/attachment-0001.html>
On Fri, Jun 06, 2014 at 08:51:31AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > > Hi
> > >
> > > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > > On Fri, Jun 06
Hi Dave !
So your AST KMS driver in -next is blowing up on my power8 box :-)
There are several issues that I want to discuss here (YC Chen on CC
might also have some valuable input here) before I send you patches
to fix it :-)
* First, accessors. The first obvious cause for blowing up for me is
Hi Dave !
So your AST driver in -next is blowing up on my power8 box :-)
There are several issues that I want to discuss here (YC Chen on CC
might also have some valuable input here).
* First, accessors. The first obvious cause for blowing up for me is
that you are using the "old style" PIO offs
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #27 from Alex Deucher ---
Created attachment 138421
--> https://bugzilla.kernel.org/attachment.cgi?id=138421&action=edit
possible fix
Does this patch help? If not, can you try increasing the size of the delay and
see if that helps?
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #26 from Alex Deucher ---
Ok, so it appears your dGPU never powered up properly. You just see the
problem now because prior to the runpm patch (which dynamically turns the dGPU
on/off) it was always left on.
--
You are receiving thi
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #25 from Teofilis Martisius ---
Created attachment 138411
--> https://bugzilla.kernel.org/attachment.cgi?id=138411&action=edit
Dmesg output from 3.12, fails to turn on dGPU
--
You are receiving this mail because:
You are watching t
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #24 from Teofilis Martisius ---
Hi,
Thank you once again for quick response.
Ok, a while ago I added radeon.no_wb=1 as without it I was getting display
corruption. That problem seems to be gone now, so there's no reason to keep
that
"Add linux-next specific files for 20140606"
v2:
Splitted into two patches
reduced number of Cc
drivers/gpu/drm/drm_hashtab.c| 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
drivers/staging/
Tomi/Jean can you please ack merging this through drm-intel trees? It
just exports the vga and dummy consoles so that i915 can do what it
needs to do.
Thanks, Daniel
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> w
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/20140606/bfe7bf42/attachment.html>
15_address_space *vm)
> {
> + if (drm_mm_initialized(&vm->mm)) {
> + drm_mm_takedown(&vm->mm);
> + list_del(&vm->global_link);
> + }
> intel_gmch_remove();
> }
>
-- 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/20140606/774c4762/attachment.sig>
From: Behalf Of Ken Helias
> All other add functions for lists have the new item as first argument and the
> position where it is added as second argument. This was changed for no good
> reason in this function and makes using it unnecessary confusing.
>
> Also the naming of the arguments in hlist
The initial state at boot is assumed to be disconnected, and we hope
to receive an interrupt to update the status. Let's be more explicit
about the current state - reading the PHY status register tells us
the current level of the hotplug signal, which we can report back in
the _detect() method.
S
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/b737ffd5/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #23 from Alex Deucher ---
Sorry, I should have been more clear, on kernel 3.12, does the dGPU switch on
again properly after via debugfs after you've disabled it via debugfs? The
problem you are sseing is that the GPU turns off ok, bu
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Let them eat mincemeat pie.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_params.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there. So check for it and keep it enabled if we see it
> already on. Based on an earlier fix from Kristian.
>
> v2: honor modparam if set too (Daniel)
> read out a
On Thu, Jun 05, 2014 at 06:30:57PM +0100, Peter Griffin wrote:
> The C99 specification states in section 6.11.5:
>
> The placement of a storage-class specifier other than at the beginning
> of the declaration specifiers in a declaration is an obsolescent
> feature.
This is definitely the right ch
On Fri, 06 Jun 2014, Dave Airlie wrote:
> From: Dave Airlie
>
> The DP1.2 spec has some bits for forced load sensing on VGA dongles,
> however the apple dongle I have doesn't do DP 1.2 yet, so I dug into
> its vendor specific area and found a register that seems to correspond
> to load detected o
From: Dave Airlie
The DP1.2 spec has some bits for forced load sensing on VGA dongles,
however the apple dongle I have doesn't do DP 1.2 yet, so I dug into
its vendor specific area and found a register that seems to correspond
to load detected on the outputs.
The main reason I need this was at L
Query to find out how many compute units on a GPU.
Useful for OpenCL usermode drivers.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c| 12 +++-
drivers/gpu/drm/radeon/evergreen.c | 12
drivers/gpu/drm/radeon/ni.c | 12
drivers/gpu/
On Fri, Jun 06, 2014 at 02:04:21PM +0300, Jani Nikula wrote:
> Do we have any need to differentiate between this and what VBT has? We
> could just treat dev_priv->vbt as "VBT or what BIOS did", and do
> dev_priv->vbt.lvds_use_ssc = true; here, possibly with a
> DRM_DEBUG_KMS. It would simplify code
--
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/0e3f08e4/attachment.sig>
I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left wh
Xu
Cc: dri-devel at lists.freedesktop.org
Cc: e1000-devel at lists.sourceforge.net
Cc: netdev at vger.kernel.org
Cc: devel at driverdev.osuosl.org
Cc: linux-fsdevel at vger.kernel.org
Cc: b.a.t.m.a.n at lists.open-mesh.org
Cc: bridge at lists.linux-foundation.org
---
Patch based on "Add linux-next sp
On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> >> Hi
> >>
> >> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> >> wrote:
> >> > A bunch of issues:
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/2bcd10ce/attachment.html>
Hi
On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
>> wrote:
>> > A bunch of issues:
>> > - We should not kick out the default console (which is tracked in
>> > con
On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote:
> From: Behalf Of Ken Helias
> > All other add functions for lists have the new item as first argument and
> > the
> > position where it is added as second argument. This was changed for no good
> > reason in this function and makes usi
The clock driver usually complains when a clock is being prepared
before setting its rate. It is the case here for "core_clk" which
needs to be set at 19.2 MHz before we attempt a prepare_enable().
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 ++
drivers/gpu/drm
On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > A bunch of issues:
> > - We should not kick out the default console (which is tracked in
> > conswitchp), so check for that.
> > - Add better error codes so calle
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/babeb0aa/attachment.html>
On Fri, Jun 06, 2014 at 09:16:13AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > I don't fully understand the magic of the vt register/unregister
> > logic, but apparently everything but the inital console (as set
> > in the conswitchp pointer)
On Fri, Jun 06, 2014 at 09:28:03AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > Touching the VGA resources on an IVB EFI machine causes hard hangs when
> > we then kick out the efifb. Ouch.
> >
> > Apparently this also prevents unclaimed regist
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbco
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> A bunch of issues:
> - We should not kick out the default console (which is tracked in
> conswitchp), so check for that.
> - Add better error codes so callers can differentiate between "something
> went wrong" and "your driver isn't re
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> I don't fully understand the magic of the vt register/unregister
> logic, but apparently everything but the inital console (as set
> in the conswitchp pointer) is marked with FLAG_MODULE. Which means
> if something unregistered the boot vt
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Otherwise the loop will never stop since we don't make any
> forward progress. Noticed while breaking this accidentally
> in a painful attempt to make vga_con unregistering work.
>
> With this patch we'll bail out on the first attempt, whi
On Fri, Jun 06, 2014 at 08:38:36AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Bunch of stuff for 3.16 still:
> - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've
> squeezed this in since it's a regression compared to vbios and we've
> been ridiculed about it a bit too often .
On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > Hi
> >
> > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> > >> Hi
> > >>
> > >> On Thu
urceforge.net
> Cc: netdev at vger.kernel.org
> Cc: devel at driverdev.osuosl.org
> Cc: linux-fsdevel at vger.kernel.org
> Cc: b.a.t.m.a.n at lists.open-mesh.org
> Cc: bridge at lists.linux-foundation.org
> ---
> Patch based on "Add linux-next specific files for 20140606&qu
On Fri, Jun 6, 2014 at 4:03 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
>
>
> drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
> drivers/gpu/drm/i915/intel_fbdev.c:39
Hi Dave,
Bunch of stuff for 3.16 still:
- Mipi dsi panel support for byt. Finally! From Shobhit&others. I've
squeezed this in since it's a regression compared to vbios and we've
been ridiculed about it a bit too often ...
- connection_mutex deadlock fix in get_connector (only affects i915).
-
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/b1cb38cd/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #22 from Teofilis Martisius ---
Ok,
I tried playing around with Linux 3.12, that's the last stable version before
that commit.
Booted with parameters:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64
root=UUID=...
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #21 from Teofilis Martisius ---
Created attachment 138351
--> https://bugzilla.kernel.org/attachment.cgi?id=138351&action=edit
Dmesg output from 3.15rc8 without radeon.dpm=1 switch
Dmesg output from 3.15rc8 without radeon.dpm=1 swit
On Fri, Jun 06, 2014 at 02:56:43PM +0100, Russell King wrote:
> The initial state at boot is assumed to be disconnected, and we hope
> to receive an interrupt to update the status. Let's be more explicit
> about the current state - reading the PHY status register tells us
> the current level of th
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/5acf1f44/attachment.html>
eceiving 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/20140606/3c4d3b62/attachment.html>
On Fri, Jun 6, 2014 at 12:48 AM, Ajay kumar wrote:
> +Device tree list
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> exynos_dp supports a simple bridge chain with ptn3460 bridge
>> and an LVDS panel attached to it.
>> This patch creates the bridge chain with ptn3460 as the head
>>
On Fri, Jun 6, 2014 at 12:47 AM, Ajay kumar wrote:
> +Device tree list
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually pow
On Fri, Jun 6, 2014 at 12:46 AM, Ajay kumar wrote:
> + Device tree list
>
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> From: Vincent Palatin
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin
>> Signed-off-
+Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> exynos_dp supports a simple bridge chain with ptn3460 bridge
> and an LVDS panel attached to it.
> This patch creates the bridge chain with ptn3460 as the head
> of the list and panel_binder being the tail.
>
> Also, DERER_PRO
+Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have
+ Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> From: Vincent Palatin
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Sean Paul
> Signed-off-by:
From: Rahul Sharma
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drive
From: Vincent Palatin
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin
Signed-off-by: Andrew Bresticker
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/drm/bridge/ps8622.t
exynos_dp supports a simple bridge chain with ptn3460 bridge
and an LVDS panel attached to it.
This patch creates the bridge chain with ptn3460 as the head
of the list and panel_binder being the tail.
Also, DERER_PROBE for exynos_dp is tested with this patch.
Signed-off-by: Ajay Kumar
---
.../d
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/LVDS panels.
The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BACKLIGHT_EN pin to
enable/ disable the backlight.
Sometimes, we can have LCD
Modify the driver to invoke callbacks for the next bridge
in the bridge chain.
Also, remove the drm_connector implementation from ptn3460,
since the same is implemented using panel_binder.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/ptn3460.c| 136 +-
Add a dummy bridge which binds all of the drm_bridge callbacks
to corresponding drm_panel callbacks.
In theory, this is just a glue layer for the last bridge and
the panel attached to it.
This driver also implements the required drm_connector ops
for the encoder(on which the entire bridge chain i
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff L
Add helper functions to create bridge chain and to call the
corresponding next_bridge functions.
Signed-off-by: Ajay Kumar
Suggested-by: Rob Clark
---
include/drm/drm_crtc.h | 72
1 file changed, 72 insertions(+)
diff --git a/include/drm/drm_c
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
This patchset also consolidates vario
68 matches
Mail list logo
