On Tue, Dec 06, 2016 at 05:41:05PM +0200, Michael S. Tsirkin wrote:
> __CHECK_ENDIAN__ isn't on by default presumably because
> it triggers too many sparse warnings for correct code.
> But virtio is now clean of these warnings, and
> we want to keep it this way - enable this for
> sparse builds.
>
On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen :
>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
>>> Add the dumb-vga-dac node to the board DT together with corresponding
>>> ports and vga connector. This allows to retrieve the edid inf
On Fri, Dec 02, 2016 at 11:44:54AM +0100, Lucas Stach wrote:
> The dumper is only a debugging aid so we don't want to invoke the OOM
> killer if buffer for the potentially large GPU state can't be vmalloced.
>
> Signed-off-by: Lucas Stach
Acked-by: Russell King
Thanks.
--
RMK's Patch system:
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/c218fdc3/attachment.html>
On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote:
>
> The mutex_spin_on_owner() function was originally marked noinline
> because it could be a major consumer of CPU cycles in a contended lock.
> Having it shown separately in the perf output will help the users have a
> better understan
From: Tvrtko Ursulin
Driver prefix is a bit redundant in debug messages. If we choose
not to log it we change debug messages which used to look like this:
[i915:edp_panel_off [i915]] Wait for panel power off time
to this:
[edp_panel_off [i915]] Wait for panel power off time
Signed-off-by: T
From: Tvrtko Ursulin
Eliminate _DRM_PRINTK macro and use drm_printk for all log levels.
This required drm_printk to vary the verbosity level of the logged
metadata depending on the log level.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_drv.c | 31 ++-
inc
From: Tvrtko Ursulin
Same as the previous patch did for drm_printk, allow for the
logging macros to pass in the driver set DRM_NAME.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_drv.c | 14 +++---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
include/drm/drmP.h
From: Tvrtko Ursulin
Instead of logging with the DRM core name, pass in the name explicitly
in order to allow individual drivers to have all their log messages
prefixed with their own name.
For instance i915, instead of:
[drm:edp_panel_off [i915]] Wait for panel power off time
would now log d
From: Tvrtko Ursulin
Define DRM_NAME to i915 so that the log messages we output change from:
[drm] RC6 on
to:
[i915] RC6 on
Since I wasn't around in the beginning of DRM I wonder whether that
was the intended purpose of DRM_NAME or if it was something else.
Today it looks a bit messy with
From: Tvrtko Ursulin
I wasn't here at the beginnings of DRM so I might have gotten this wrong,
however the existance of DRM_NAME suggested to me that the intention was to
allow individual drivers to override it and get appropriate prefixes in their
log messages.
I can't see that any driver is us
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/b1149566/attachment.html>
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/a58a6a95/attachment.html>
/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/ca91b559/attachment-0001.sig>
Hi Mark,
On Tuesday 06 Dec 2016 13:20:20 Mark Brown wrote:
> On Tue, Dec 06, 2016 at 02:46:55PM +0200, Laurent Pinchart wrote:
> > On Tuesday 06 Dec 2016 10:05:17 Mark Brown wrote:
> > > On Mon, Dec 05, 2016 at 11:16:22PM +0200, Laurent Pinchart wrote:
> > > > This has been discussed previously, a
On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state,
> unsigned int subclass,
>* mutex_unlock() handing the lock off to us, do a trylock
>* before testing the error conditions to
Hi Dave,
On 2016-11-28 18:55, Stefan Agner wrote:
> Hi Dave,
>
> Some fixes and cleanup, mainly around fbdev emulation. It also adds a
> new module parameter which allows to specify the color depth/bpp for
> the fbdev emulation (like the IMX DRM driver).
>
> There have been some fixes in that dr
Hi Tvrtko,
2016-12-06 Tvrtko Ursulin :
> From: Tvrtko Ursulin
>
> Driver prefix is a bit redundant in debug messages. If we choose
> not to log it we change debug messages which used to look like this:
>
> [i915:edp_panel_off [i915]] Wait for panel power off time
>
> to this:
>
> [edp_pane
__CHECK_ENDIAN__ isn't on by default presumably because
it triggers too many sparse warnings for correct code.
But virtio is now clean of these warnings, and
we want to keep it this way - enable this for
sparse builds.
Signed-off-by: Michael S. Tsirkin
---
It seems that there should be a better
virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
releases and acquires this lock. This causes a sparse warning. Add
appropriate annotations for sparse context checking.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
1 file changed, 2 i
When virtio_gpu_free_vbufs exits due to list empty, it does not
drop the free_vbufs lock that it took.
list empty is not expected to happen anyway, but it can't hurt to fix
this and drop the lock.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++-
1 file changed,
virtio_gpu_cmd_transfer_to_host_2d expects x and y
parameters in LE, but virtio_gpu_primary_plane_update
passes in the CPU format instead.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
I run latest sparse from git on virtio drivers
(turns out the version I had was rather outdated).
This patchset fixes a couple of bugs this uncovered,
and adds some annotations to make it sparse-clean.
In particular, endian-ness is often tricky,
so this patchset enabled endian-ness checks for spars
no. I changed the product to reflect the correct issue source.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/35068881/attachment.sig>
ize: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/d4935fbd/attachment.sig>
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/7b336421/attachment-0001.sig>
tion/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/5695986c/attachment.sig>
n-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1e6499f1/attachment.sig>
2016-12-05 Daniel Vetter :
> On Mon, Dec 05, 2016 at 12:03:46PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > We now support nonblocking commits on drm_atomic_helper_commit()
> > so the comment is not valid anymore.
> >
> > Signed-off-by: Gustavo Padovan
>
> Oops. Reviewed-b
On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
> +static inline int __sched
> +__ww_mutex_add_waiter(struct mutex_waiter *waiter,
> + struct mutex *lock,
> + struct ww_acquire_ctx *ww_ctx)
> +{
> + struct mutex_waiter *cur;
> +
> + if (!
Hello Jyri Sarha,
The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
driver" from Oct 31, 2016, leads to the following static checker
warning:
drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc()
warn: missing error code here? 'of_graph_get_remote_port
From: Gustavo Padovan
The destaging work is now fully complete.
Cc: Arve Hjønnevåg
Cc: Riley Andrews
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/TODO | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index
On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
> unsigned int subclass,
> struct mutex_waiter waiter;
> unsigned long flags;
> bool first = false;
> - struct ww_mutex *ww;
> i
On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
> +++ b/include/linux/ww_mutex.h
> @@ -222,11 +222,7 @@ extern int __must_check
> __ww_mutex_lock_interruptible(struct ww_mutex *lock,
> */
> static inline int ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
> *ctx)
>
On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote:
> On 1 December 2016 at 04:18, Jonathan Gray wrote:
> > DRI devices on OpenBSD are not in their own directory. They reside in
> > /dev with a large number of statically generated /dev nodes.
> >
> > Avoid stat'ing all of /dev on OpenBS
://lists.freedesktop.org/archives/dri-devel/attachments/20161206/720fbb93/attachment-0001.sig>
Hello,
On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote:
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> From: Magnus Damm
> >>
> >> For the DU to operate on R-Car Gen3 hardware a combination of DU
> >> and VSP devices
2016-12-06 16:03 GMT+01:00 Sekhar Nori :
> On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
>> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen :
>>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga
On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
> +++ b/kernel/locking/mutex.c
> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
> * access and not reliable.
> */
> static noinline
> -bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *own
From: Gustavo Padovan
Instead of dealing with crtc details inside drm_atomic.c we should
just export a function that creates a new crtc fence for us and
use that.
Suggested-by: Chris Wilson
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c| 16 +---
drivers/g
||g/show_bug.cgi?id=97980
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/062e3
||g/show_bug.cgi?id=98638
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/94b9b
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/0747db12/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/0e262557/attachment.html>
Hi Bartosz,
Thank you for the patch.
On Tuesday 06 Dec 2016 14:13:45 Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Go
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/db7147ba/attachment.html>
On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote:
> The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
> corresponding device tree bindings based on the DWC HDMI TX bindings
> model.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/renes
On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> tree binding by itself but is meant to be referenced by platform device
> tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> bindings to refer
Hey,
> Okay, so clearly this needs a kernel side NVMe specific allocator
> and locking so users don't step on each other..
Yup, ideally. That's why device dax isn't ideal for this application: it
doesn't provide any way to prevent users from stepping on each other.
> Or as Christoph says some ki
Hi Mark,
On Tuesday 06 Dec 2016 10:05:17 Mark Brown wrote:
> On Mon, Dec 05, 2016 at 11:16:22PM +0200, Laurent Pinchart wrote:
> > On Monday 05 Dec 2016 13:11:51 Bjorn Andersson wrote:
> >> Further more, a DT binding for a particular block should describe that
> >> block; so if we have three diffe
ing this mail because:
You are the assignee for the bug.
------ next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/67489c84/attachment.html>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.ph
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 69
1 file chang
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3
2016-12-05 13:49 GMT+01:00 Tomi Valkeinen :
> On 29/11/16 13:57, Bartosz Golaszewski wrote:
>> Add the dumb-vga-dac node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>
> It's a bit difficult to fo
On Tue, Dec 6, 2016 at 1:47 PM, Logan Gunthorpe wrote:
> Hey,
>
>> Okay, so clearly this needs a kernel side NVMe specific allocator
>> and locking so users don't step on each other..
>
> Yup, ideally. That's why device dax isn't ideal for this application: it
> doesn't provide any way to prevent
On 12/06/2016 01:29 PM, Peter Zijlstra wrote:
> On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote:
>> The mutex_spin_on_owner() function was originally marked noinline
>> because it could be a major consumer of CPU cycles in a contended lock.
>> Having it shown separately in the perf outp
On Tue, Dec 06, 2016 at 11:55:14AM +, Eric Engestrom wrote:
> On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote:
> > If we cannot acquire the mode_config.lock immediately, just back off and
>
> s/mode_config.lock/mode_config.mutex lock/ ?
Fixed
>
> > queue a new attempt after the pol
On 12/06/2016 08:53 AM, Daniel Vetter wrote:
> On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote:
>> On 2 December 2016 at 04:02, Marek Vasut wrote:
>>> Hi,
>>>
>>> as asked by Daniel, I collected the MXSFB DT Acks and the driver and
>>> wrapped it into PR (below).
>>
>> Hi Marek
>>
>> t
Hi Russell
I need the below fixup to make this build for me:
diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
index a18f156c8b66..64c0b4546fb2 100644
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -4,3 +4,5 @@ armada-y+= armada
user out
there.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/b95837c1/attachment-0001.sig>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/6c3e2521/attachment.html>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/9d0e3266/attachment.html>
ally don't want to ship
something based on it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1d6a3e60/attachment.html>
On Tuesday, 2016-12-06 11:37:15 +, Chris Wilson wrote:
> If we cannot acquire the mode_config.lock immediately, just back off and
s/mode_config.lock/mode_config.mutex lock/ ?
> queue a new attempt after the poll interval. This is mostly to stop the
> hung task spam when the system is deadlock
If we cannot acquire the mode_config.lock immediately, just back off and
queue a new attempt after the poll interval. This is mostly to stop the
hung task spam when the system is deadlocked, but it will also lessen
the load (in such extreme cases).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
On Tue, Dec 6, 2016 at 10:35 AM, Jordan Crouse
wrote:
> On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote:
>> On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote:
>>
>> > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
>> > only render to buffers that are marked as
On 12/06/2016 09:14 AM, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 08:51:31PM +0100, Thierry Reding wrote:
>> On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote:
>>> This series adds IOMMU support to Host1x and TegraDRM
>>> and adds support for the VIC host1x client so that
>>> h
On 2 December 2016 at 04:02, Marek Vasut wrote:
> Hi,
>
> as asked by Daniel, I collected the MXSFB DT Acks and the driver and
> wrapped it into PR (below).
Hi Marek
this isn't pullable as-is as it seems to be based on -next tree or something.
Please create pull requests based on a Linus or drm
On 12/06/2016 10:06 AM, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
>> +++ b/kernel/locking/mutex.c
>> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
>> * access and not reliable.
>> */
>> static noinline
>> -bool mutex_spi
On Mon, Dec 05, 2016 at 11:57:43AM -0800, Bjorn Andersson wrote:
> > + if (of_property_read_u32(pdev->dev.of_node, "qcom,pas-id", &pas_id)) {
>
> This is constant, so define it in the driver.
Little bit concerned it might not always be constant but I suppose we can cross
that bridge when we get t
On 06/12/16 10:42 AM, Mike Lothian wrote:
> Hi
>
> This patch (in drm-next and drm-intel-nightly) stops my system from
> booting, I don't see any errors, just a black screen and a reboot after
> the kernel has been selected
>
> I have confirmed that reverting this patch gets those two branches
>
Hi Daniel,
On 06-12-2016 08:23, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote:
>>> Hi Thierry,
>>>
>>>
>>> On 05-12-2016 11:14, Thierry Reding wrote:
On Mon, Dec 05, 2016 at 11:06:15AM +000
On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote:
> Hey,
>
> On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
> >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> >>> device-dax in
2016-12-05 Daniel Vetter :
> They're gone since 8a357d10043c ("drm: Nerf DRM_CONTROL nodes").
> Spotted while doing a full audit when revieng a similar patch from
> Nicolai for radeon.
>
> v2: Drink coffee first aka don't forget the unregister side.
>
> Cc: Dave Airlie
> Fixes: 8a357d10043c ("d
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/7cb9663f/attachment.sig>
On 06/12/16 05:07 AM, Alex Deucher wrote:
> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
> struct drm_device's ->control member is always NULL.
>
> In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses
> ->control->debugfs_root though. This results in the following
Dear DRM/DRI Maintainer,
The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git at github.com:superna/linux.git tags/meson-drm-for-4.10
for you to fetch changes up to 1de7ac686bb
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/db9770be/attachment-0001.html>
Hey,
On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
>>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
>>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
>>> device-dax instance under the nvme device, or if you already have the nvme
>>> sysfs path
> > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> > device-dax instance under the nvme device, or if you already have the nvme
> > sysfs path the dax instance(s) will appear under the "dax" sub
On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 02:19:48PM +, Jose Abreu wrote:
> > Hi Thierry,
> >
> >
> > On 05-12-2016 11:14, Thierry Reding wrote:
> > > On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
> > >> Hi Thierry,
> > >>
> > >>
>
On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote:
> > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
> > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote:
> > > > On Mon, Dec 05, 2016 at 0
On Tue 06 Dec 07:35 PST 2016, Jordan Crouse wrote:
> On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote:
> > On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote:
> >
> > > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
> > > only render to buffers that are marked a
Hi Dave,
Sorry for late. Just refactoring HDMI driver by using infoframe helper
function, fixing GSC Kconfig dependency issue and including trivial
cleanups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit f03ee46be9401e3434f52b
On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote:
> > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
> > > device-dax instance under the nvme device, or if you already have the
Am 06.12.2016 um 02:00 schrieb Michel Dänzer:
> On 06/12/16 05:07 AM, Alex Deucher wrote:
>> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
>> struct drm_device's ->control member is always NULL.
>>
>> In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses
>> ->control
On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote:
> On 2 December 2016 at 04:02, Marek Vasut wrote:
> > Hi,
> >
> > as asked by Daniel, I collected the MXSFB DT Acks and the driver and
> > wrapped it into PR (below).
>
> Hi Marek
>
> this isn't pullable as-is as it seems to be based o
On Mon, Dec 05, 2016 at 11:57:12AM -0800, Bjorn Andersson wrote:
> On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote:
>
> > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
> > only render to buffers that are marked as secure and inaccessible
> > to the kernel and user through a
On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the l
On Tue, Dec 06, 2016 at 02:01:37AM +, Mike Lothian wrote:
> Feel free to add a tested by from myself
>
> Thanks for the fix
>
> On Mon, 5 Dec 2016 at 20:33 Deucher, Alexander
> wrote:
>
> > > -Original Message-
> > > From: Nicolai Stange [mailto:nicstange at gmail.com]
> > > Sent: M
On Mon, Dec 05, 2016 at 12:33:28PM -0800, Manasi Navare wrote:
> On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> > Hm, tiny new bikeshed: I'd drop the _property postfix here. The function
> > name is already really long as-is, and the fact that the link status is
> > exposed as a p
On Mon, Dec 05, 2016 at 08:51:31PM +0100, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote:
> > This series adds IOMMU support to Host1x and TegraDRM
> > and adds support for the VIC host1x client so that
> > host1x can be tested on modern Tegra platforms.
> >
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requireme
On Tue, Dec 06, 2016 at 08:23:05AM +0100, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 04:27:35PM -0800, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's poss
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/e223522a/attachment-0001.html>
d off" if we switch to the console with
Ctrl-Alt-F2?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/5335d959/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161206/1b048001/attachment.html>
On 12/06/2016 02:08 AM, Dave Airlie wrote:
> On 2 December 2016 at 04:02, Marek Vasut wrote:
>> Hi,
>>
>> as asked by Daniel, I collected the MXSFB DT Acks and the driver and
>> wrapped it into PR (below).
>
> Hi Marek
Hi!
> this isn't pullable as-is as it seems to be based on -next tree or som
1 - 100 of 108 matches
Mail list logo
