On Wed, Aug 22, 2018 at 04:57:33PM +0100, Brian Starkey wrote:
> On Wed, Aug 22, 2018 at 05:11:55PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom
> > wrote:
> > > On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote:
> > > > On Tue, Aug 21, 2018 at 09:26:39A
According to revision 1.00 of R-Car Gen3 SoC manual, writing to OTAR
register is valid only if the channel is equipped with a digital output
pad (DPAD).
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev,
On Fri, 3 Aug 2018 11:22:27 +0200
Boris Brezillon wrote:
> From: Eric Anholt
>
> Y_OFFSET field starts at bit 8 not 7.
>
> Signed-off-by: Eric Anholt
> Signed-off-by: Boris Brezillon
As discussed with Eric 2 weeks ago, I'm about to apply this series to
drm-misc-fixes. The rational behind t
According to revision 1.00 of R-Car Gen3 Soc manual, setting bits
PnMR[13:12] is only valid if the DU group has two channels.
It is then valid writing to PnMR[13:12] for:
R-Car H3 = DU group 0 and DU group 1
R-Car M3-W, M3-N: DU group 0 only
R-Car D3/E3: DU group 0 (no group 1)
It is always inval
On Thu, Aug 23, 2018 at 6:05 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
According to revision 1.00 of R-Car Gen3 Soc manual, only DU channels of
group 0 (DU0 and DU1) supports output control routing through register DORCR0.
For channels of group 1 (DU2 and DU3) which are only present on H3/M3-W/M3-N
SoCs, no routing options are available between super-imposition proce
According to revision 1.00 of R-Car Gen3 Soc manual, writing to ESCR
register of DU channels equipped with a display PLL (DPLL) is invalid.
Fix this by writing ESCR only for channels making use of the DU internal
post-divider to generate the dotclockout signal, with R-Car H3 ES1.x being
a notable
crtc_state is accessed by both vblank_handle() and the ordered
work_struct handle vkms_crc_work_handle() to retrieve and or update
the frame number for computed CRC.
Since work_struct can fail, add frame_end to account for missing frame
numbers.
use atomic_t witth appropriate flags for synchroniz
Hello Laurent,
Revision 1.00 has brought several updates on how to handle some registers
in the DU. In particular
- ESCR cannot be written for channels with a DPLL
- OTAR cannot be written for channels without a digital output pad
- routing superimposition processor output to pincontrollers thr
Hi all,
On 8/21/18 3:19 AM, Thomas Hellstrom wrote:
>>> #include "vmwgfx_drv.h"
>>> #include "vmwgfx_reg.h"
>>> @@ -4520,8 +4521,10 @@ int vmw_execbuf_ioctl(struct drm_device *dev,
>>> unsigned long data,
>>> return -EINVAL;
>>> }
>>>
>>> - if (arg.version > 1 &&
>>> -
On 08/23/2018 08:38 PM, Harry Wentland wrote:
> On 2018-08-17 10:11 AM, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>>
>> Signed-off-by: Hans Verkuil
>> Acked-by: Alex Deucher
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm
Am 24.08.2018 um 01:05 schrieb Jiandi An:
On 08/23/2018 01:47 AM, Christian König wrote:
Am 22.08.2018 um 22:57 schrieb Jiandi An:
On 08/22/2018 02:09 PM, Christian König wrote:
Am 22.08.2018 um 20:57 schrieb Jiandi An:
Framebuffer memory needs to be accessed decrypted. Ensure the
memory
Looks ok to me.
Reviewed-by: Mika Kahola
On Wed, 2018-08-15 at 12:08 +0200, Maarten Lankhorst wrote:
> This adds the possibility to test arbitrary enumerations in IGT
> without
> having to define mappings for each and every one.
>
> Changes since v1:
> - Add commit description.
> - Add try_prop
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #9 from Michel Dänzer ---
(In reply to Christopher from comment #7)
> After I first boot into gnome, with it running on xorg, as soon as I have
> logged in and click on activities on the gnome menu and select terminal,
> then the lit
https://bugs.freedesktop.org/show_bug.cgi?id=107627
Daniel Stone changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
On Fri, 24 Aug 2018 09:09:26 +0200
Boris Brezillon wrote:
> On Fri, 3 Aug 2018 11:22:27 +0200
> Boris Brezillon wrote:
>
> > From: Eric Anholt
> >
> > Y_OFFSET field starts at bit 8 not 7.
> >
> > Signed-off-by: Eric Anholt
> > Signed-off-by: Boris Brezillon
>
> As discussed with Eric
On Tue, 14 Aug 2018 17:05:29 +0200
Peter Rosin wrote:
> >> @@ -77,13 +79,29 @@ static int atmel_hlcdc_attach_endpoint(struct
> >> drm_device *dev, int endpoint)
> >>
> >> int atmel_hlcdc_create_outputs(struct drm_device *dev)
> >> {
> >> -int endpoint, ret = 0;
> >>
Op 23-08-18 om 17:11 schreef Alexandru Gheorghe:
> When doing suspend/resume drivers usually use the
> drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> state and then re-comitting it.
>
> The problems is that drm_crtc_state has a bool field called
> color_mgmt_changed, which
Hi Peter,
On Fri, 10 Aug 2018 15:03:55 +0200
Peter Rosin wrote:
> Hi!
>
> The background for these patches is that our PCB interface between
> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and
> this has to be described somewhere, or the atmel-hlcdc driver have no
> chance of
Hi Peter,
On Wed, 22 Aug 2018 13:50:47 +0200
Peter Rosin wrote:
> Hi!
>
> I just discovered that the atmel-hlcdc driver picks a pixel-clock
> way outside the given range when used with a panel with these
> timings from the device tree.
>
> panel-timing {
> // 1024x768 @ 60H
On 2018-08-24 12:37 a.m., Kristian H. Kristensen wrote:
> Benjamin Gaignard (2):
> tests/modetest: Add atomic support
> tests/util: Add support for stm module
>
> Christian König (7):
> amdgpu: stop using the hash table for fd_tab
> amdgpu: add handle table implementation v
Hi Lee,
On Wed, 15 Aug 2018 06:24:35 +0100
Lee Jones wrote:
> > +static const struct mfd_cell lcdc_cells[] = {
> > + {
> > + .name = "atmel-lcdc-pwm",
> > + .of_compatible = "atmel,lcdc-pwm",
> > + },
> > + {
> > + .name = "atmel-lcdc-dc",
> > + .of_
Hi,
On Fri, Aug 24, 2018 at 09:51:03AM +0200, Maarten Lankhorst wrote:
> Op 23-08-18 om 17:11 schreef Alexandru Gheorghe:
> > When doing suspend/resume drivers usually use the
> > drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> > state and then re-comitting it.
> >
> > The
Hi Sam,
On Sun, 12 Aug 2018 20:41:52 +0200
Sam Ravnborg wrote:
> New DRM based driver for at91sam9 SOC's that uses the
> Atmel LCDC IP core.
First of all, thanks for this contribution.
>
> This is first version of a patch set that adds
> drivers for the Atmel LCDC IP core.
> Posted for review
On Sun, 12 Aug 2018 20:46:23 +0200
Sam Ravnborg wrote:
> Use vendor name for directory, adding a suitable place
> for more atmel DRM drivers.
>
> Signed-off-by: Sam Ravnborg
> Cc: Boris Brezillon
> ---
> MAINTAINERS | 2 +-
> drivers/gpu/drm/Kco
On Thu, 16 Aug 2018 10:28:54 +0200
Nicolas Ferre wrote:
> On 15/08/2018 at 22:40, Sam Ravnborg wrote:
> > Hi Lee.
> >
> >>> +
> >>> +static const struct mfd_cell lcdc_cells[] = {
> >>> + {
> >>> + .name = "atmel-lcdc-pwm",
> >>> + .of_compatible = "atmel,lcdc-pwm",
> >>> + },
>
On Sun, 12 Aug 2018 20:46:24 +0200
Sam Ravnborg wrote:
> The LCDC IP used by some Atmel SOC's have a
> multifunction device that include two sub-devices:
> - pwm
> - display controller
>
> This binding describe the multi function device
> that act as root for the sub-devices
>
> The Atmel SOC's
On Sun, 12 Aug 2018 20:46:25 +0200
Sam Ravnborg wrote:
> The LCDC IP used by some Atmel SOC's have a
> multifunction device that include two sub-devices:
> - pwm
> - display controller
>
> This mfd device provide a regmap that can be used by the
> sub-devices to safely access the reg
cinelle script
Patch was compile tested with: omap2plus_defconfig (implies OMAP2_DSS_INIT=y)
Patch is against 4.18 (localversion-next is next-20180824)
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/ds
Hi John,
On Friday, 24 August 2018 00:12:46 EEST John Stultz wrote:
> On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart wrote:
> > On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote:
> >> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote:
> >>> On Thu, Aug 23, 2018 at 10:46:15AM +0300
On Fri, 24 Aug 2018 10:55:00 +0200
Peter Rosin wrote:
> If the divider used to get the pixel-clock is small, the granularity
> of the frequencies possible for the pixel-clock is quite coarse. E.g.
> requesting a pixel-clock of 65MHz with a sys_clk of 132MHz results
> in the divider being set to 3
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #10 from Christopher ---
(In reply to Michel Dänzer from comment #9)
> (In reply to Christopher from comment #7)
> > After I first boot into gnome, with it running on xorg, as soon as I have
> > logged in and click on activities on t
On Fri, 24 Aug 2018 10:55:01 +0200
Peter Rosin wrote:
> But only if the highest pixel-clock frequency lower than requested
> is significantly much less accurate that the lowest frequency higher
> than requested.
>
> I pulled "10 times" as the discriminator out of the hat, and went with
> that.
Op 24-08-18 om 10:18 schreef Alexandru-Cosmin Gheorghe:
> Hi,
>
> On Fri, Aug 24, 2018 at 09:51:03AM +0200, Maarten Lankhorst wrote:
>> Op 23-08-18 om 17:11 schreef Alexandru Gheorghe:
>>> When doing suspend/resume drivers usually use the
>>> drm_atomic_helper_suspend/drm_atomic_helper_resume pair
On 16-Aug-18 9:21 PM, Maarten Lankhorst wrote:
Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila:
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_
On 8/23/2018 9:30 PM, Jordan Crouse wrote:
On Thu, Aug 23, 2018 at 02:48:31PM +0530, Sharat Masetty wrote:
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if
https://bugs.freedesktop.org/show_bug.cgi?id=106707
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #12 from Lakshmi ---
Clos
On Fri, 24 Aug 2018, Boris Brezillon wrote:
> Hi Lee,
>
> On Wed, 15 Aug 2018 06:24:35 +0100
> Lee Jones wrote:
>
> > > +static const struct mfd_cell lcdc_cells[] = {
> > > + {
> > > + .name = "atmel-lcdc-pwm",
> > > + .of_compatible = "atmel,lcdc-pwm",
> > > + },
> > > + {
> >
https://bugs.freedesktop.org/show_bug.cgi?id=107337
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Lakshmi ---
Last
Hi Sergei,
Thank you for the patch.
On Tuesday, 5 June 2018 23:28:58 EEST Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
and taken in my tree.
> ---
> Documentation/devicetree/bindi
Hi Sergei,
Thank you for the patch.
On Tuesday, 5 June 2018 23:30:36 EEST Sergei Shtylyov wrote:
> Add support for the R-Car V3H (R8A77980) SoC to the LVDS encoder driver.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/gpu/drm/rcar-
Hi Sergei,
On Thursday, 23 August 2018 19:53:33 EEST Sergei Shtylyov wrote:
> On 06/05/2018 11:25 PM, Sergei Shtylyov wrote:
> > Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git'
> > repo. The purpose of these patches is to add the R-Car V3H (R8A77980)
> > support to the R
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> Two more worries for this patch.
>
>
>
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> > *
> > * @amn: our notifier
> >
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
[...]
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(&hmm->mirrors_sem);
> > }
> >
> > -static void hmm_invalidate_range_start(struct mmu
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*
* @a
On Fri 24-08-18 13:43:16, Christian König wrote:
> Am 24.08.2018 um 13:32 schrieb Michal Hocko:
> > On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> > > Two more worries for this patch.
> > >
> > >
> > >
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/a
On Thu, Aug 23, 2018 at 05:17:20PM -0400, Mikulas Patocka wrote:
>
>
> On Sun, 19 Aug 2018, Ville Syrjälä wrote:
>
> > On Fri, Aug 17, 2018 at 03:19:37PM -0400, Mikulas Patocka wrote:
> > > On Sun Ultra 5, it happens that the dot clock is not set up properly for
> > > some videomodes. For exampl
On Fri 24-08-18 13:57:52, Christian König wrote:
> Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
> > > That won't work like this there might be multiple
> > > invalidate_range_start()/invalidate_range_end() pairs open at the same
> > > time
On Fri, Aug 24, 2018 at 8:52 AM, Jani Nikula
wrote:
> On Wed, 22 Aug 2018, Rodrigo Vivi wrote:
>> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
>>> On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
>>>
>>> > - Sticking to fdo bugzilla and disabling gitlab issues for at least
>
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
Reviewed-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 1 -
1 file changed, 1 deletion(-)
diff -
stub fence will be used by timeline syncobj as well.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
---
drivers/gpu/drm/drm_syncobj.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index d
we can fetch timeline point fence after expanded.
v2: The parameter fence is the result of the function and should come last.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 5 +++--
drivers/gpu/drm/v3d/v3d_gem.c |
we can place a fence to a timeline point after expanded.
v2: change func parameter order
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 14 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
driver
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline semaphore.
syncobj fence and cb aren't need any more.
wait pt already contains sumission wait.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 69 ---
include/drm/drm_syncobj.h | 56 +---
2 files changed, 1 insertion(+), 124 delet
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++-
include/drm/drm_syncobj.h | 2 ++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu
normal syncobj can be unified to timeline syncobj.
The thingking is:
a. singal op always append to sinal list tail.
b. wait op always wait on last sinal point.
the driver indeed be simplified more.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 113
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
That won't work like this there might be multiple
invalidate_range_start()/invalidate_range_end() p
Patches #1-#4 are Reviewed-by: Christian König
I would squash patches #5-#8 into one and make sure that the patch is a
clean replacement of the existing functionality with the new one.
For example patch #5 still has some code move for the stub fence which
now seems unnecessary.
Regards,
Ch
This adds a very small and simple driver to read a virtual
display characteristic from the device tree and reflect it
back into DRM so a display driver in a virtual environment
knows how to configure its output.
This was created for the ARM RTSM aemv8a emulator as a way
forward to convert all ARM
This adds bindings for a virtual display to be used with displays
inside entirely virtual environments which do not emulate things
like monitors but just need timing information to be supplied to
its display controller.
This is inspired by earlier work by Liviu Dudau.
Cc: Liviu Dudau
Cc: Ryan Ha
+Noralf
Hi Sam,
On Sun, 12 Aug 2018 20:46:29 +0200
Sam Ravnborg wrote:
> This is a DRM based driver for the Atmel LCDC IP.
> There exist today a framebuffer based driver and
> this is a re-implmentation of the same on top of DRM.
>
> The rewrite was based on the original fbdev driver
> but the
On Fri 24-08-18 14:18:44, Christian König wrote:
> Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > On Fri 24-08-18 13:43:16, Christian König wrote:
> > [...]
> > > > > That won't work like t
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #30 from Jan Jurzitza ---
(In reply to Andrey Grodzovsky from comment #29)
> > ...
> This is just a warning meaning you use CPU to update GPU page tables, any
> reason why ? try passing kernel
> amdgpu.vm_update_mode=0 instead.
Y
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
On Fri 24-08-18 14:18:44, Christian König wrote:
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
Tha
On Fri 24-08-18 14:52:26, Christian König wrote:
> Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
> > Thiking about it some more, I can imagine that a notifier callback which
> > performs an allocation might trigger a memory reclaim and that in turn
> > might trigger a notifier to be invoked an
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a notifier callback which
performs an allocation might trigger a memory reclaim and that in turn
might
https://bugs.freedesktop.org/show_bug.cgi?id=107635
--- Comment #1 from Harry Wentland ---
Have you tried with nouveau disabled?
https://askubuntu.com/questions/841876/how-to-disable-nouveau-kernel-driver/951892#951892
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=107623
--- Comment #4 from Harry Wentland ---
Have you tried with nouveau disabled?
https://askubuntu.com/questions/841876/how-to-disable-nouveau-kernel-driver/951892#951892
--
You are receiving this mail because:
You are the assignee for the bug.__
On Fri 24-08-18 15:10:08, Christian König wrote:
> Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > Am 24.08.2018 um 14:33 schrieb Michal Hocko:
> > [...]
> > > > Thiking about it some more, I can imagine that a notifier callback which
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=107593
--- Comment #6 from Fermulator ---
"current kernels", more specifically?
(Fedora runs pretty bleeding edge kernel-wise)
If we have a "fix in kernel version X", and a different bug report to duplicate
against, we can close then then?
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=107560
--- Comment #8 from Fermulator ---
(fyi, to update, the issue hasn't presented itself in the past week, which is a
bit frustrating) - i had even ordered an HDMI cable to workaround the
DisplayPort problem ... but haven't installed it yet waiting
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a noti
On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> On 2018/08/24 20:36, Michal Hocko wrote:
> >> That is, this API seems to be currently used by only out-of-tree users.
> >> Since
> >> we can't check that nobody has memory allocation dependency, I think that
> >> hmm_invalidate_range_start() should r
On Fri 24-08-18 15:28:33, Christian König wrote:
> Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > > > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > > > Am 24.08.2018 um 14:33 schrieb M
Am 24.08.2018 um 15:40 schrieb Michal Hocko:
On Fri 24-08-18 15:28:33, Christian König wrote:
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2
On Fri, 27 Jul 2018, Satendra Singh Thakur wrote:
> Following changes are done to this func:
Just a drive-by observation, if your commit message lists a number of
changes, with "also", it's usually an indication they should be separate
patches.
BR,
Jani.
> 1. Currently there are many redundant
On Fri 24-08-18 15:44:03, Christian König wrote:
> Am 24.08.2018 um 15:40 schrieb Michal Hocko:
> > On Fri 24-08-18 15:28:33, Christian König wrote:
> > > Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > > > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > > > Am 24.08.2018 um 15:01 schrieb M
Hi Satendra,
On Fri, 27 Jul 2018 at 11:13, Satendra Singh Thakur
wrote:
> Following changes are done to this func:
I would certainly agree with Sean, Martin, and Jani's comments. This
patch was difficult to follow as it made so many changes at once.
Being a crucial function which has many subtle
https://bugs.freedesktop.org/show_bug.cgi?id=107593
--- Comment #7 from Michel Dänzer ---
(In reply to Fermulator from comment #6)
> "current kernels", more specifically?
4.16 or newer.
> If we have a "fix in kernel version X", and a different bug report to
> duplicate against, we can close the
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #24 from CheatCodesOfLife ---
(In reply to Andrey Grodzovsky from comment #23)
> (In reply to CheatCodesOfLife from comment #22)
> > You're welcome.
> >
> > Not the exact same problem, no. I can get a hard-lock by trying to use
> >
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #25 from CheatCodesOfLife ---
Created attachment 141269
--> https://bugs.freedesktop.org/attachment.cgi?id=141269&action=edit
debug files
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #26 from Andrey Grodzovsky ---
(In reply to CheatCodesOfLife from comment #25)
> Created attachment 141269 [details]
> debug files
Thanks a lot, i will find some time in the next few days to analyze it.
--
You are receiving this m
On Thu, Aug 23, 2018 at 07:56:12PM -0700, Kees Cook wrote:
> On Thu, Aug 23, 2018 at 6:05 PM, Gustavo A. R. Silva
> wrote:
> > One of the more common cases of allocation size calculations is finding
> > the size of a structure that has a zero-sized array at the end, along
> > with memory for some
On Fri, Aug 24, 2018 at 07:54:19PM +0900, Tetsuo Handa wrote:
> Two more worries for this patch.
[...]
>
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(&hmm->mirrors_sem);
> > }
> >
On Fri, Aug 24, 2018 at 03:24:04PM +0530, Sharat Masetty wrote:
>
>
> On 8/23/2018 9:30 PM, Jordan Crouse wrote:
> >On Thu, Aug 23, 2018 at 02:48:31PM +0530, Sharat Masetty wrote:
> >>Implement routines to estimate GPU busy time and fetching the
> >>current frequency for the polling interval. Thi
On Fri, Aug 24, 2018 at 3:20 AM Hans Verkuil wrote:
>
> On 08/23/2018 08:38 PM, Harry Wentland wrote:
> > On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> >> From: Hans Verkuil
> >>
> >> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
> >>
> >> Signed-off-by: Hans Verkuil
> >> Acked-by: A
On Wed, 22 Aug 2018, Chris Chiu wrote:
> On Fri, Jul 6, 2018 at 2:44 PM, Chris Chiu wrote:
>> On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä
>> wrote:
>>> On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote:
Hi,
We have few ASUS laptops X705FD (The new WiskyLake), X560UD (in
On Fri, Aug 24, 2018 at 02:33:41PM +0200, Michal Hocko wrote:
> On Fri 24-08-18 14:18:44, Christian König wrote:
> > Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > > On Fri 24-08-18 13:
On Fri, Aug 24, 2018 at 11:52:25PM +0900, Tetsuo Handa wrote:
> On 2018/08/24 22:32, Michal Hocko wrote:
> > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> >> I worry that (currently
> >> out-of-tree) users of this API are involving work / recursion.
> >
> > I do not give a slightest about out-of
Hi Boris.
On Fri, Aug 24, 2018 at 10:28:43AM +0200, Boris Brezillon wrote:
> On Sun, 12 Aug 2018 20:46:23 +0200
> Sam Ravnborg wrote:
>
> > Use vendor name for directory, adding a suitable place
> > for more atmel DRM drivers.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Boris Brezillon
> > --
Hi Boris.
> >
> > Both devices are supported today by the atmel_lcdfb driver.
> > For this new set of drivers the compatible strings was
> > selected to avoid clash with the existing compatible
> > strings used for the atmel_lcdfb driver to allow them
> > to co-exist.
>
> Hm, I think Rob comment
Hi Boris.
> > +The LCDC IP exposes two subdevices:
> > + - a PWM chip: see ../pwm/atmel-lcdc-pwm.txt
> > + - a Display Controller: see ../display/atmel/lcdc-display-controller.txt
> > +
> > +Example:
> > + lcdc0: lcdc@70 {
> > + compatible = "atmel,at91sam9263-lcdc-mfd";
> > +
On Thu, Aug 23, 2018 at 10:44 PM Laurent Carlier wrote:
>
> Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit :
> > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2
>
> -> Forbidden
>
> You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this
> server.
On Fri, Aug 24, 2018 at 1:13 AM Michel Dänzer wrote:
>
> On 2018-08-24 12:37 a.m., Kristian H. Kristensen wrote:
> > Benjamin Gaignard (2):
> > tests/modetest: Add atomic support
> > tests/util: Add support for stm module
> >
> > Christian König (7):
> > amdgpu: stop using the ha
On Fri, Aug 24, 2018 at 2:47 AM Boris Brezillon
wrote:
>
> On Tue, 14 Aug 2018 17:05:29 +0200
> Peter Rosin wrote:
>
> > >> @@ -77,13 +79,29 @@ static int atmel_hlcdc_attach_endpoint(struct
> > >> drm_device *dev, int endpoint)
> > >>
> > >> int atmel_hlcdc_create_outputs(struct
On 2018-08-24 6:27 p.m., Kristian Høgsberg wrote:
>
> I don't know what all is pending for libdrm, but I know that we've
> agreed on a very low bar for when to release libdrm:
>
>"The release criteria for libdrm is essentially "if you need a release,
> make one". There is no designated r
On Fri 24-08-18 23:52:25, Tetsuo Handa wrote:
> On 2018/08/24 22:32, Michal Hocko wrote:
> > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> >> I worry that (currently
> >> out-of-tree) users of this API are involving work / recursion.
> >
> > I do not give a slightest about out-of-tree modules. T
1 - 100 of 117 matches
Mail list logo
