tps://lists.freedesktop.org/archives/dri-devel/attachments/20161124/2ef8980a/attachment.html>
On Wed, Nov 23, 2016 at 02:11:29PM -0700, Logan Gunthorpe wrote:
> Perhaps I am not following what Serguei is asking for, but I
> understood the desire was for a complex GPU allocator that could
> migrate pages between GPU and CPU memory under control of the GPU
> driver, among other things. The d
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/8c415553/attachment.html>
data. The number is the timeout in ms.
--
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/20161124/2b3260e2/attachment.html>
On Wednesday, November 09, 2016 06:15:56 PM Hans de Goede wrote:
> acpi_video.c passed the ACPI_VIDEO_NOTIFY_* defines as type code to
> acpi_notifier_call_chain(). Move these defines to acpi/video.h so
> that acpi_notifier listeners can check the type code using these
> defines.
>
> Signed-off-by
t; Thanks,
> Rafael
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/181c64f2/attachment.sig>
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/d81886f9/attachment.html>
sparse produces these warnings:
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27: warning: incorrect type in
assignment (different address spaces)
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:expected char [noderef]
*screen_base
drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:got void *vmap
This is be
The maximum size of input or output rotation is 2047 x 2047.
Fixed an error on limitations.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 11 +--
include/uapi/drm/exynos_drm.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/d
On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote:
> This is RFC patch for adding a connector link-status property
> and making it atomic by adding it to the drm_connector_state.
> This is to make sure its wired properly in drm_atomic_connector_set_property
> and drm_atomic_connector_ge
On Wed, Nov 23, 2016 at 02:42:24PM -0500, Rob Clark wrote:
> On Wed, Nov 23, 2016 at 2:22 PM, Emil Velikov
> wrote:
> > On 23 November 2016 at 18:45, Rob Clark wrote:
> >> On Wed, Nov 23, 2016 at 1:18 PM, Emil Velikov >> gmail.com> wrote:
> >>> On 23 November 2016 at 07:26, Christian Gmeiner
>
Hi,
On 11/24/2016 10:43 AM, Kuninori Morimoto wrote:
>
> Hi Archit, David, and DRM ML
>
> I had heared that Archit is the maintainer of dw-hdmi driver, but am I wrong
> ??
> I'm posting this patch series since half year ago, but no response
> from him, and nothing happen (I got review from Russel
On Thu, 24 Nov 2016, Manasi Navare wrote:
> On Wed, Nov 23, 2016 at 03:07:30PM +0200, Jani Nikula wrote:
>> On Tue, 22 Nov 2016, Manasi Navare wrote:
>> > This patch adds support to handle automated DP compliance
>> > link training test requests. This patch has been tested with
>> > Unigraf DPR-1
On Wed, Nov 23, 2016 at 02:11:15PM +, Chris Wilson wrote:
> Use the color_adjust callback when reserving a node to check if
> inserting a node into this hole requires any additional space, and so if
> that space then conflicts with an existing allocation.
>
> Signed-off-by: Chris Wilson
> Cc:
2016ë
11ì 24ì¼ 16:51ì Hoegeun Kwon ì´(ê°) ì´ ê¸:
> The maximum size of input or output rotation is 2047 x 2047.
> Fixed an error on limitations.
You would need to consider other SoC - Exynos5250/5250/5410/5420/5433 because
other have different rotation limitations like below,
Exynos
aging fbdev drivers there until we have replacements.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/c4bf2385/attachment.sig>
2016-11-24 8:53 GMT+01:00 Daniel Vetter :
> On Wed, Nov 23, 2016 at 02:42:24PM -0500, Rob Clark wrote:
>> On Wed, Nov 23, 2016 at 2:22 PM, Emil Velikov
>> wrote:
>> > On 23 November 2016 at 18:45, Rob Clark wrote:
>> >> On Wed, Nov 23, 2016 at 1:18 PM, Emil Velikov > >> gmail.com> wrote:
>> >>>
Add an API to pass the timeout value (ns) from pipe->fence_finish(..)
to the kernel. The current API accepts ms and special handling is needed
for PIPE_TIMEOUT_INFINITE.
The idea is not to break old mesa (out-of-tree) + new libdrm.
Changes from v2 to v3:
- Builds at each step
- Keep the _ns pos
We need to pass through a timeout parameter to implement
pipe->fence_finish() properly. The new fxn accepts a timeout
in nanoseconds. Simplify etna_pipe_wait(..) by using
etna_pipe_wait_ns(..).
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv-symbol-check | 1 +
etnaviv/etnaviv_drmif.h
Also update all callers.
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv_bo.c | 2 +-
etnaviv/etnaviv_pipe.c | 2 +-
etnaviv/etnaviv_priv.h | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/etnaviv/etnaviv_bo.c b/etnaviv/etnaviv_bo.c
index 833f8bd..4ad0434 100644
2016-11-24 6:03 GMT+01:00 Sekhar Nori :
> On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
>> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>>> David Lechner writes:
>>>
On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
> 2016-11-22 23:23 GMT+01:00 David Lechner :
>> On 11/1
On Thu, 24 Nov 2016, Dave Young wrote:
> I see a lot of below warning:
No, we must not hide this under the carpet. There's a bug at fdo about
this, and we need to fix it.
BR,
Jani.
> [ 17.128256] WARNING: CPU: 1 PID: 95 at
> drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x201/0
On Wed, Nov 23, 2016 at 02:11:15PM +, Chris Wilson wrote:
> Use the color_adjust callback when reserving a node to check if
> inserting a node into this hole requires any additional space, and so if
> that space then conflicts with an existing allocation.
>
> Signed-off-by: Chris Wilson
> Cc:
> + if (priv->rev == 1)
> + reinit_completion(&tilcdc_crtc->palette_loaded);
> +
So when the crtc is disabled, you do this, so that on crtc enable the
driver would load palette? When is the crtc enabled if it hasn't been
disabled first? In other words, when will the palette loading in
tilcdc_crtc_enable() _not_ trigger for v1?
This looks a bit messy to me.
Why not just load the palette every time on crtc enable? And reinit the
completion in tilcdc_crtc_load_palette().
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/692b7df3/attachment.sig>
Currently the memory controller and master priorities drivers are
enabled in da850.dtsi. For boards for which there are no settings
defined, this makes these drivers emit error messages.
Disable the nodes in da850.dtsi and only enable them for da850-lcdk -
the only board that currently needs them.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/06791e3f/attachment-0001.sig>
ype: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/17d24e10/attachment.sig>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161124/62d05d41/attachment.sig>
On 11/24/16 11:29, Tomi Valkeinen wrote:
>> @@ -213,6 +274,13 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool
>> shutdown)
>> >__func__);
>> >}
>> >
>> > + /*
>> > + * LCDC will not retain the palette when reset. Make sure it gets
>> > + * reloaded
On 11/24/16 11:37, Tomi Valkeinen wrote:
> On 22/11/16 18:54, Jyri Sarha wrote:
>> The LCDC revision 2 documentation also mentions the mandatory palette
>> for true color modes. Even if the rev 2 LCDC appears to work just fine
>> without the palette being loaded loading it helps in testing the
>> f
ume palette has to be
loaded.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/b5e191b4/attachment.sig>
ignature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/e58a4704/attachment.sig>
Patch for the atmel-hlcdc driver:
Change pixel clock divider settings to resolve incorrect clock output
and reduce rounding to prevent clocking out of range.
Add support for the TDA19988 HDMI transmitter and possibly other
component based DRM drivers. Added device tree options to enable
require
https://bugzilla.kernel.org/show_bug.cgi?id=141741
Valentin QUEQUET changed:
What|Removed |Added
CC||valentin.quequet at gmail.com
--- Com
Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe:
> There is certainly nothing about the hardware that cares
> about ZONE_DEVICE vs System memory.
Well that is clearly not so simple. When your ZONE_DEVICE pages describe
a PCI BAR and another PCI device initiates a DMA to this address the DMA
subsys
ng at the registers to find out if they're intact is fine, but it's
just an optimization.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/be3d1117/attachment.sig>
at enable.
>
> Looking at the registers to find out if they're intact is fine, but it's
> just an optimization.
>
Yes, of course.
BR,
Jyri
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/c71c2559/attachment-0001.sig>
Hi all,
So it's finally done, drm-misc is split out into a separate repo:
https://cgit.freedesktop.org/drm-misc
The integration tree and rerere-cache was also split out, so that both
groups can update it:
https://cgit.freedesktop.org/drm-tip
To get there you need to update dim and re-run the s
erent things.
The current system suspend/resume in tilcdc looks fine.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/64cb4620/attachment.sig>
On Thu, 24 Nov 2016, Daniel Vetter wrote:
> To get there you need to update dim and re-run the setup steps:
Perhaps needless to say, but please report any hickups you see
immediately on IRC and/or in reply to this mail!
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On 23.11.2016 15:25, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 03:03:36PM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 23, 2016 at 12:25:22PM +0100, Nicolai Hähnle wrote:
>>> @@ -473,7 +476,14 @@ void __sched ww_mutex_unlock(struct ww_mutex *lock)
>>> */
>>> mutex_clear_owner(&lock->b
The drm_dev_alloc() function returns error pointers. It never returns
NULLs.
Fixes: 5e0df3a08f3d ("drm/hisilicon/hibmc: Add hisilicon hibmc drm master
driver")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm
On Thu, Nov 24, 2016 at 12:26:57PM +0100, Nicolai Hähnle wrote:
> I do believe we can win a bit by keeping the wait list sorted, if we also
> make sure that waiters don't add themselves in the first place if they see
> that a deadlock situation cannot be avoided.
>
> I will probably want to exte
On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra
wrote:
>
>> I do believe we can win a bit by keeping the wait list sorted, if we also
>> make sure that waiters don't add themselves in the first place if they see
>> that a deadlock situation cannot be avoided.
>>
>> I will probably want to extend
On Thu, Nov 24, 2016 at 12:52:25PM +0100, Daniel Vetter wrote:
> On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra
> wrote:
> >
> >> I do believe we can win a bit by keeping the wait list sorted, if we also
> >> make sure that waiters don't add themselves in the first place if they see
> >> that a
;t undestand the same mechanism could not be used for runtime
resume. Why should it matter if we configure the previous drm atomic
state after system suspend or simple LCDC power down suspend?
There may be some need for differentiation with more complex display
hardware, but I see no such need for tilcdc.
> Tomi
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/fbea7e11/attachment.sig>
On 24 November 2016 at 08:46, Christian Gmeiner
wrote:
> Add an API to pass the timeout value (ns) from pipe->fence_finish(..)
> to the kernel. The current API accepts ms and special handling is needed
> for PIPE_TIMEOUT_INFINITE.
>
> The idea is not to break old mesa (out-of-tree) + new libdrm.
>
om
the driver.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/0c5b695d/attachment.sig>
Hi Liviu, Russell,
I'd been meaning to try digging into this if it hadn't gone away since I
first noticed it, but I don't really have the time and it still happens
with 4.9-rc and today's -next. Representative splat below, but in
summary what happens is that if the HDLCD fails to probe, the TDA998
x.com/scan.php?page=news_item&px=AMD-DAL-21-November-2016
--
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/20161124/b8df3da
On 24/11/16 13:29, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote:
>> Hi Liviu, Russell,
>>
>> I'd been meaning to try digging into this if it hadn't gone away since I
>> first noticed it, but I don't really have the time and it still happens
>> with
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/88503f3c/attachment.html>
On 24/11/16 13:49, Robin Murphy wrote:
> On 24/11/16 13:29, Russell King - ARM Linux wrote:
>> On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote:
>>> Hi Liviu, Russell,
>>>
>>> I'd been meaning to try digging into this if it hadn't gone away since I
>>> first noticed it, but I don't real
On Thu, Nov 24, 2016 at 02:40:50PM +, Robin Murphy wrote:
> On 24/11/16 13:49, Robin Murphy wrote:
> > On 24/11/16 13:29, Russell King - ARM Linux wrote:
> >> On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote:
> >>> Hi Liviu, Russell,
> >>>
> >>> I'd been meaning to try digging into
On Thu, Nov 24, 2016 at 11:48 AM, Daniel Vetter
wrote:
> $ cd $DIM_PREFIX $ rm drm-intel-rerere drm-intel-nightly maintainer-tools
> -Rf
If you are using git worktree already (manually set up, dim only does
this since today) then there's a bit more cleanup required:
$ cd $DIM_PREFIX/DIM_DRM_INT
When CONFIG_PM_SLEEP is disabled, we get a harmless warning
drm/hisilicon/hibmc/hibmc_drm_drv.c:115:12: error: âhibmc_pm_resumeâ
defined but not used [-Werror=unused-function]
drm/hisilicon/hibmc/hibmc_drm_drv.c:97:12: error: âhibmc_pm_suspendâ
defined but not used [-Werror=unused-functi
On 2016-11-24 11:26 AM, Jason Gunthorpe wrote:
> On Thu, Nov 24, 2016 at 10:45:18AM +0100, Christian König wrote:
>> Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe:
>>> There is certainly nothing about the hardware that cares
>>> about ZONE_DEVICE vs System memory.
>> Well that is clearly not so
From: Ville Syrjälä
drm_atomic_crtc_needs_modeset() doesn't change the passed in
crtc state, so pass it as const.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.
On Thu, 24 Nov 2016, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_atomic_crtc_needs_modeset() doesn't change the passed in
> crtc state, so pass it as const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_atomic.h | 2 +-
> 1 fi
hanks,
Boyuan
--
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/20161124/c0b0b46d/attachment.html>
l pretty broken. See the attached asm. "s_mov vcc_hi, m0" looks
suspicious.
--
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/a
ame
function in enable just before turning the raster on.
I think I'll make a patch right away.
Cheers,
Jyri
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/15f01e3b/attachment.sig>
e 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/20161124/ea8be2f8/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161124/2159739d/attachment.html>
Hi Andy,
As the author of the DW-HDMI DT bindings this question is addressed to you,
but information from anyone is more than welcome.
The DT bindings specify two clocks named "iahb" and "isfr" but don't describe
them. While I assume that the "isfr" clock corresponds to the "isfrclk" input
sig
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/20161124/e312453f/attachment.html>
Hi Laurent,
On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart
wrote:
> Hi Andy,
>
> As the author of the DW-HDMI DT bindings this question is addressed to you,
> but information from anyone is more than welcome.
>
> The DT bindings specify two clocks named "iahb" and "isfr" but don't describe
> t
On Thu, Nov 24, 2016 at 8:16 PM, Vladimir Zapolskiy
wrote:
> correct, for your convenience the table is copied below:
>
> Clock name | Clock Root | Description
> ---++---
> iahbclk | ahb_clk_root | Bus clock
> icec
From: Fabio Estevam
The "gpr" property is i.MX specific and is documented at
Documentation/devicetree/bindings/display/imx/hdmi.txt, so
remove such non-standard property from the common binding doc.
Suggested-by: Vladimir Zapolskiy
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bin
ving 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/20161124/fcfeeb72/attachment.html>
I see a lot of below warning:
[ 17.128256] WARNING: CPU: 1 PID: 95 at drivers/gpu/drm/i915/intel_dp.c:1062
intel_dp_aux_transfer+0x201/0x240 [i915]
[ 17.128264] WARN_ON_ONCE(!msg->buffer != !msg->size)
[ 17.128267] Modules linked in:
[ 17.128273] kvm_intel kvm irqbypass i915 intel_gtt drm
On 11/24/16 at 10:53am, Jani Nikula wrote:
> On Thu, 24 Nov 2016, Dave Young wrote:
> > I see a lot of below warning:
>
> No, we must not hide this under the carpet. There's a bug at fdo about
> this, and we need to fix it.
It is not hiding it, just not repeating the warnings. But anyway I do
no
Hi Archit, David, and DRM ML
I had heared that Archit is the maintainer of dw-hdmi driver, but am I wrong ??
I'm posting this patch series since half year ago, but no response
from him, and nothing happen (I got review from Russell though).
Is Archit really maintainer ??
OTOH, get_maintainer.pl i
On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>> David Lechner writes:
>>
>>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
2016-11-22 23:23 GMT+01:00 David Lechner :
> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
On Thu, Nov 24, 2016 at 10:45:18AM +0100, Christian König wrote:
> Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe:
> >There is certainly nothing about the hardware that cares
> >about ZONE_DEVICE vs System memory.
> Well that is clearly not so simple. When your ZONE_DEVICE pages describe a
> PCI B
Hey,
On 24/11/16 02:45 AM, Christian König wrote:
> E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE.
> Not PCI device B (a SATA device) can directly read/write to it because
> it is on the same bus segment, but PCI device C (a network card for
> example) can't because it i
On 24.11.2016 12:56, Peter Zijlstra wrote:
> On Thu, Nov 24, 2016 at 12:52:25PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra
>> wrote:
>>>
I do believe we can win a bit by keeping the wait list sorted, if we also
make sure that waiters don't add themse
On Wed, Nov 23, 2016 at 06:25:21PM -0700, Logan Gunthorpe wrote:
>
>
> On 23/11/16 02:55 PM, Jason Gunthorpe wrote:
> >>> Only ODP hardware allows changing the DMA address on the fly, and it
> >>> works at the page table level. We do not need special handling for
> >>> RDMA.
> >>
> >> I am aware
On 24/11/16 09:42 AM, Jason Gunthorpe wrote:
> There are three cases to worry about:
> - Coherent long lived page table mirroring (RDMA ODP MR)
> - Non-coherent long lived page table mirroring (RDMA MR)
> - Short lived DMA mapping (everything else)
>
> Like you say below we have to handle sho
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call a
On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote:
> Hi Liviu, Russell,
>
> I'd been meaning to try digging into this if it hadn't gone away since I
> first noticed it, but I don't really have the time and it still happens
> with 4.9-rc and today's -next. Representative splat below, but
On Thu, Nov 24, 2016 at 12:40:37AM +, Sagalovitch, Serguei wrote:
> On Wed, Nov 23, 2016 at 02:11:29PM -0700, Logan Gunthorpe wrote:
>
> > Perhaps I am not following what Serguei is asking for, but I
> > understood the desire was for a complex GPU allocator that could
> > migrate pages between
Hi, Dave:
This branch include patches of fixing a typo, accurate dsi frame rate,
and fixing null pointer dereference.
Regards,
CK
The following changes since commit
9c763584b7c8911106bb77af7e648bef09af9d80:
Linux 4.9-rc6 (2016-11-20 13:52:19 -0800)
are available in the git repository at:
24.11.2016, 19:27, "Chen-Yu Tsai" :
> The panels shipped with Allwinner devices are very "generic", i.e.
> they do not have model numbers or reliable sources of information
> for the timings (that we know of) other than the fex files shipped
> on them. The dot clock frequency provided in the fex
The panels shipped with Allwinner devices are very "generic", i.e.
they do not have model numbers or reliable sources of information
for the timings (that we know of) other than the fex files shipped
on them. The dot clock frequency provided in the fex files have all
been rounded to the nearest MHz
Hi Archit
> > I had heared that Archit is the maintainer of dw-hdmi driver, but am I
> > wrong ??
> > I'm posting this patch series since half year ago, but no response
> > from him, and nothing happen (I got review from Russell though).
> > Is Archit really maintainer ??
> > OTOH, get_maintaine
On Thu, Nov 24, 2016 at 11:11:34AM -0700, Logan Gunthorpe wrote:
> * Regular DAX in the FS doesn't work at this time because the FS can
> move the file you think your transfer to out from under you. Though I
> understand there's been some work with XFS to solve that issue.
The file system will nev
87 matches
Mail list logo
