Hi Archit,
On 23-06-2017 10:36, Jose Abreu wrote:
> Currently HDMI 2.0 PHYs do not have a default configuration function.
>
> As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D
> PHYs we can provide the same default configuration function for both
> and still let user overwrit
Check for snd_pcm_ops structures that are only stored in the ops field of
a snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops. The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as
const also.
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #12 from Matias N. Goldberg ---
Thank you for adding this commit despite my futile email!
I am getting up to speed with Mesa's patch submission process, but I wouldn't
have had the time to fully read it until next week and resubmit
On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote:
>
> I've got next locked down, so whenever you open the merge
> window and I get back I'll send it to you.
Just checking in on this part.. I think the drm stuff it the major
missing piece for 4.13 now.
Linus
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #5 from Vedran Miletić ---
Few more random details:
1) monitor is attached via VGA, the only output on the motherboard
2) different monitors show the same behaviour
3) GDM vs SDDM, no difference
4) in both GDM and SDDM, the mouse curs
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #4 from Vedran Miletić ---
dmesg doesn't show anything suspicious:
[1.526705] [drm] radeon kernel modesetting enabled.
[1.537819] fb: switching to radeondrmfb from EFI VGA
[1.538312] radeon :00:01.0: VRAM: 512M 0x
Hi Daniel,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.12 next-20170707]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-Make-fbcon-a-built-time
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #3 from Vedran Miletić ---
Created attachment 132559
--> https://bugs.freedesktop.org/attachment.cgi?id=132559&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101723
Bug ID: 101723
Summary: hdmi unplug not changing connector status
Product: DRI
Version: unspecified
Hardware: All
OS: Linux (All)
Status: NEW
Severity: m
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #72 from Marek Olšák (mar...@gmail.com) ---
Additional piece of the puzzle to the Oland mystery:
1) Oland uses Verde's GB_ADDR_CONFIG in one place:
case CHIP_OLAND:
...
gb_addr_config = VERDE_GB
https://bugzilla.kernel.org/show_bug.cgi?id=196291
Christian König (christian.koe...@amd.com) changed:
What|Removed |Added
CC||christian.koe
https://bugzilla.kernel.org/show_bug.cgi?id=196291
Bug ID: 196291
Summary: amdgpu: Freeze because of syscall not returning
Product: Drivers
Version: 2.5
Kernel Version: 4.11.8
Hardware: x86-64
OS: Linux
Tree:
https://bugs.freedesktop.org/show_bug.cgi?id=101712
--- Comment #4 from guiscara...@gmail.com ---
(In reply to Julien Isorce from comment #3)
> Can you try to generate an apitrace (apt-get install apitrace, apitrace
> trace /path/to/application ). Then if you reproduce the issue with apitrace
> r
On Mon, Jul 03, 2017 at 10:41:23AM +0200, Philippe CORNU wrote:
> This patch adds documentation of device tree bindings for the
> Synopsys DesignWare MIPI DSI host controller.
>
> Signed-off-by: Philippe CORNU
> ---
> .../bindings/display/bridge/dw_mipi_dsi.txt| 32
> +++
On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote:
> On Fri, Jul 7, 2017 at 3:21 PM, Ville Syrjälä
> wrote:
> > On Fri, Jul 07, 2017 at 02:03:38PM +0200, Daniel Vetter wrote:
> >> On Thu, Jul 06, 2017 at 11:24:41PM +0300, ville.syrj...@linux.intel.com
> >> wrote:
> >> > From: Ville Sy
On Fri, Jun 30, 2017 at 8:47 AM, Christian König
wrote:
> Am 30.06.2017 um 04:24 schrieb Michel Dänzer:
>>
>> On 29/06/17 07:05 PM, Daniel Vetter wrote:
>>>
>>> On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
On 29/06/17 05:23 PM, Christian König wrote:
>
> Am 29.0
On Thu, Jul 6, 2017 at 10:57 PM, Mario Kleiner
wrote:
> The late 2009, 27 inch Apple iMac10,1 has an
> internal eDP display and an external Mini-
> Displayport output, driven by a DCE-3.2, RV730
> Radeon Mobility HD-4670.
>
> The machine worked fine in a dual-display setup
> with eDP panel + exter
On Fri, Jul 7, 2017 at 3:21 PM, Ville Syrjälä
wrote:
> On Fri, Jul 07, 2017 at 02:03:38PM +0200, Daniel Vetter wrote:
>> On Thu, Jul 06, 2017 at 11:24:41PM +0300, ville.syrj...@linux.intel.com
>> wrote:
>> > From: Ville Syrjälä
>> >
>> > For i915 GPU reset handling we'll want to be able to dupli
On Sun, Jul 02, 2017 at 04:40:01PM +0300, Laurent Pinchart wrote:
> On some R-Car SoCs a single VSP can serve multiple DU channels through
> multiple LIF instances in the VSP. The current DT bindings don't support
> specifying that kind of SoC integration scheme. Extend them with a VSP
> channel in
On Thu, Jul 06, 2017 at 10:25:23PM +0200, Christian König wrote:
> Am 06.07.2017 um 22:16 schrieb Felix Kuehling:
> > This allows drivers to check if a DMA-buf contains a GEM object and
> > whether it comes from the same driver. It may be from the same or a
> > different device.
> >
> > Signed-off
On Thu, Jul 6, 2017 at 9:00 AM, Daniel Vetter wrote:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
>
> v2: Dont' resurrect drm_vblank_cleanup.
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Ch
On Fri, Jul 07, 2017 at 02:03:38PM +0200, Daniel Vetter wrote:
> On Thu, Jul 06, 2017 at 11:24:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > For i915 GPU reset handling we'll want to be able to duplicate the state
> > that was last commited to the hardware. For
On Friday, 2017-06-30 03:56:55 +, coypu wrote:
> drmMalloc will zero out the memory for us
Good catch, thanks!
R-b and pushed.
In the future, can you provide your real name, and add a Signed-off-by: line?
Cheers,
Eric
> ---
> xf86drm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff -
On Thu, Jul 06, 2017 at 07:59:51AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Extending the reported/sw vblank counter to u64 makes sense imo, but do we
> > have to extend the driver interfaces too? If there's no 64 bit hw vblank
> > currently I think I'd be good to postpone that p
Check return value from call to of_match_device()
in order to prevent a NULL pointer dereference.
In case of NULL print error message and return.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/tegra/vic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/tegra/vic
Check return value from call to of_match_device()
in order to prevent a NULL pointer dereference.
In case of NULL print error message and return.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/tegra/sor.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.
In page_flip vblank is sent with no delay. Driver does not know when the
actual update is present on the display and has no means for getting
this information from a device. It is practically impossible to say
exactly *when* as there is also i.e. a usb delay.
When we are unable to determine when t
Hello,
(Cc Daniel)
On (07/06/17 19:28), Tetsuo Handa wrote:
> (...snipped...)
> [ 912.892027] kworker/3:3 D12120 3217 2 0x0080
> [ 912.892041] Workqueue: events console_callback
> [ 912.892042] Call Trace:
> [ 912.892047] __schedule+0x23f/0x5d0
> [ 912.892051] schedule+0x31/0
On Thu, Jul 06, 2017 at 08:36:00AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > A few nits below, but looks good otherwise.
>
> Thanks.
>
> >> static struct drm_pending_vblank_event *create_vblank_event(
> >> - struct drm_device *dev, uint64_t user_data)
> >> + s
On Thu, Jul 06, 2017 at 11:24:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> For i915 GPU reset handling we'll want to be able to duplicate the state
> that was last commited to the hardware. For that purpose let's start to
> track the commited state for each object an
On Thu, Jul 06, 2017 at 03:03:15PM +0200, Maarten Lankhorst wrote:
> Op 06-07-17 om 13:09 schreef Tomeu Vizoso:
> > Looks good to me:
> >
> > Reviewed-by: Tomeu Vizoso
> >
> > I guess you have tested this with IGT? In any case, I think it would
> > be good to mention how a patch has been tested in
https://bugs.freedesktop.org/show_bug.cgi?id=101714
--- Comment #1 from Matt ---
Also If relevant - I'm on Fiji hardware
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=101714
Bug ID: 101714
Summary: Complete System Freeze (displaycore staging 4.11)
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity:
On Fri, Jul 07, 2017 at 01:16:26AM -0500, Gustavo A. R. Silva wrote:
> Check return value from call to of_match_device()
> in order to prevent a NULL pointer dereference.
>
> In case of NULL print error message and return.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/tegra/vic
Hi Dave,
on first glance that looks rather good to me, but there is one things I
don't really like and I strongly think Marek will absolutely agree on
that: When we add a new CS function then let's get ride of all this
abstraction!
The new function should get an amdgpu_device_handle and a li
On Fri, Jul 7, 2017 at 4:39 AM, Sergey Senozhatsky
wrote:
> Hello,
>
> (Cc Daniel)
Oh the fun :-/
Imo it's complete misdesign of the console/printk stuff that it ends
up calling down into drm/kms drivers. There's no way this will ever
reliably work, and GFP_KERNEL is the least of your worries (t
https://bugs.freedesktop.org/show_bug.cgi?id=101712
--- Comment #3 from Julien Isorce ---
Can you try to generate an apitrace (apt-get install apitrace, apitrace trace
/path/to/application ). Then if you reproduce the issue with apitrace replay
application.trace you can attach it to this bug. (s
On 07/07/17 07:11, Gustavo A. R. Silva wrote:
> Check return value from call to of_match_device()
> in order to prevent a NULL pointer dereference.
>
> In case of NULL print error message and return.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/tegra/sor.c | 4
> 1 file
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 69133a7dd030d061a2c7a0334441cfe657e4b53f
commit: 580ae80d51e356fcf79b7f5059dce440f24a5d8d [72/612] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc
40 matches
Mail list logo
