https://bugs.freedesktop.org/show_bug.cgi?id=99403
--- Comment #10 from Roman Elshin ---
so it may be closed?
p.s. thanks a lot to all participated
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=106471
--- Comment #2 from Joshua Cogliati ---
The other video card is integrated into the motherboard, and the disabling the
integrated video with bios causes the boot to fail.
I could try the video card in a different computer, but that computer wou
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #197 from Sandeep ---
Anyway, thanks for fixing the bug, AMD devs! (or whoever else did it).
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #196 from Sandeep ---
Ah, I didn't know that. I thought it just disabled/enabled dpm...well,
it works so that's good.
It would be great if it worked out of the box though, without having to add
kernel parameters.
On Fri, May
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #3 from stu...@gmail.com ---
This is fixed in 15.0.3 on my machine.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #195 from Alex Deucher ---
(In reply to Sandeep from comment #194)
> So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> testing earlier.
>
> I tried using them now, with the 4.16.7 kernel, and replayed the API
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #194 from Sandeep ---
So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
testing earlier.
I tried using them now, with the 4.16.7 kernel, and replayed the APItrace file.
No crashes! Finally.
Well, this is still
On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 20:29:48 +0300
> Ville Syrjälä wrote:
>
> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 19:54:02 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Fri, May 11,
Maarten Lankhorst writes:
> Hey,
>
> Another pull request for drm-misc-next. Previous one was not applied yet,
> but only sending delta since last request:
> https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html
Note, I think this PR has a UABI regression in it:
https://patchwor
On Tue, Apr 24, 2018 at 9:58 PM, Felix Kuehling wrote:
> Reviewed-by: Felix Kuehling
>
> We could probably add a sanity check for n_devices to avoid user mode
> causing excessive memory allocations in the kernel. There is no good
> reason for this to be bigger than the number of GPUs in the syste
Ville Syrjälä writes:
> On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
>> On Fri, 11 May 2018 19:54:02 +0300
>> Ville Syrjälä wrote:
>>
>> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
>> > > On Fri, 11 May 2018 18:34:50 +0300
>> > > Ville Syrjälä wrote:
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.
I verified the value is present in eDP spec versions 1.3, 1.4 and 1
On Fri, 11 May 2018 20:29:48 +0300
Ville Syrjälä wrote:
> On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > On Fri, 11 May 2018 19:54:02 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > > On Fri, 11 May 2018 1
On Fri, 2018-05-11 at 18:03 +, Souza, Jose wrote:
> On Thu, 2018-05-10 at 17:54 -0700, Dhinakaran Pandiyan wrote:
> >
> > Entry corresponding to 220 us setup time was missing. I am not
> > aware
> > of
> > any specific bug this fixes, but this could potentially result in
> > enabling
> > PSR o
On Fri, May 11, 2018 at 11:05:24AM -0600, Jordan Crouse wrote:
> On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> > SoCs containing dpu have a MDSS top level wrapper
> > which includes sub-blocks as dpu, dsi, phy, dp etc.
> > MDSS top level wrapper manages common resources like
> > c
Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the erorrs,
that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constrains, so we could easily
end up in AXI or un
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #27 from Alex Deucher ---
Can you post your kernel config? I'm having trouble seeing how these crashes
are even possible.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 19:54:02 +0300
> Ville Syrjälä wrote:
>
> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 18:34:50 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Fri, May 11,
https://bugs.freedesktop.org/show_bug.cgi?id=106474
--- Comment #3 from Clemens Eisserer ---
unfortunately not on that machine :/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freed
On Fri, 11 May 2018 19:54:02 +0300
Ville Syrjälä wrote:
> On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > On Fri, 11 May 2018 18:34:50 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > > Applying an underscan
On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
>
> Each child device like mdp5, dsi etc. have a separate driver,
> but current
On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
>
> Currently, in dpu dr
On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 18:34:50 +0300
> Ville Syrjälä wrote:
>
> > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > Applying an underscan setup is just a matter of scaling all planes
> > > appropriately and adju
Hi Lin,
2018-05-09 12:22 GMT+02:00 Lin Huang :
> From: Chris Zhong
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Lin Huang
> ---
>
> Changes in v2:
> - upda
Hi Lin,
2018-05-11 16:43 GMT+02:00 Sean Paul :
> On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
>> If want to do training outside DP Firmware, need phy voltage swing
>> and pre_emphasis value.
>>
>> Signed-off-by: Lin Huang
>
> Adding Rob Herring so he has a hope of seeing this.
>
An
On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote:
> The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
> ILI9881c from Ilitek.
>
> Acked-by: Rob Herring
> Signed-off-by: Maxime Ripard
(...)
Bah, now I see this:
> + - power-gpios: a GPIO phandle for the power pin
Tha
On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote:
> > This makes sense once we got rid of plane->fb
> >
> > Will this go to drm-next?
>
> The plan is to push to drm-misc-next once we get all
> the ducks in a row.
>
Hi Maxime,
sorry that noone had much time to look at the driver.
But I can help out, hopefully.
On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> based on the Ilitek ILI9881c Controller. Add a driver for it, mode
On Fri, 11 May 2018 18:34:50 +0300
Ville Syrjälä wrote:
> On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > Applying an underscan setup is just a matter of scaling all planes
> > appropriately and adjusting the CRTC X/Y offset to account for the
> > horizontal and vertical bord
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #26 from jian-h...@endlessm.com ---
Yes. System can boot with modprobe.blacklist=amdgpu &
systemd.unit=multi-user.target.
This is the way that I tested and got the dmesg.
I booted with that configuration and got into command line en
On Fri, May 11, 2018 at 08:19:38PM +0530, Rajesh Yadav wrote:
> dpu_core_perf_crtc_update() is responsible for aggregating
> the data bus bandwidth and dpu core clock rate requirements
> and request the same for all active crtcs.
> Currently, there is no error handling support in this function
> so
On Fri, May 11, 2018 at 08:19:37PM +0530, Rajesh Yadav wrote:
> Now, since dpu_power_handle manages only bus scaling
> and power enable/disable notifications which are restricted
> to dpu driver, move dpu_power_handle to dpu folder.
>
> Changes in v2:
> - resolved conflict in dpu_unbind
>
On Fri, May 11, 2018 at 08:19:36PM +0530, Rajesh Yadav wrote:
> Currently, msm_drv was creating dpu_power_handle client
> which was used by dpu_dbg module to enable power resources
> before register debug dumping.
>
> Now since, the mdss core power resource handling is
> implemented via runtime_pm
On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote:
> The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
> ILI9881c from Ilitek.
>
> Acked-by: Rob Herring
> Signed-off-by: Maxime Ripard
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, May 11, 2018 at 08:19:34PM +0530, Rajesh Yadav wrote:
> Mdss main power supply (mdss_gdsc) is implemented as a
> generic power domain and mdss top level wrapper device
> manage it via runtime_pm. Remove custom power management
> code from dpu_power_handle.
>
> Changes in v2:
> - reso
On Fri, May 11, 2018 at 08:19:33PM +0530, Rajesh Yadav wrote:
> MDSS and dpu drivers manage their respective clocks via
> runtime_pm. Remove custom clock management code from
> dpu_power_handle.
>
> Also dpu core clock management code is restricted to
> dpu_core_perf module.
>
> Changes in v2:
>
On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> Applying an underscan setup is just a matter of scaling all planes
> appropriately and adjusting the CRTC X/Y offset to account for the
> horizontal and vertical border.
>
> Create an vc4_plane_underscan_adj() function doing that a
On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
>
> Each child device like mdp5, dsi etc. have a separate driver,
> but current
On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
>
> Currently, in dpu dr
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #17 from Thomas Martitz ---
Done, https://bugzilla.kernel.org/show_bug.cgi?id=199693
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dr
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #25 from Alex Deucher ---
Does the system boot ok with amdgpu blacklisted? E.g., append
modprobe.blacklist=amdgpu to the kernel command line in grub and boot to a
non-GUI runlevel.
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #16 from Alex Deucher ---
(In reply to Thomas Martitz from comment #15)
>
> So, what to do with this information / potential fix?
Please file a bug as per comment 10 and include that information.
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #15 from Thomas Martitz ---
I investigated the commit found by git bisect a bit more, and found that the
following patch (which reverts part of said commit) repairs resuming.
I can't tell the consequences, however reading the commit
On Wed, May 09, 2018 at 06:22:44PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying
Now that underscan props can be parsed by the core and assigned to
conn_state->underscan.xxx, we can rely on this implementation and get
rid of the nouveau-specific underscan props.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 39 +
We have 3 drivers defining the "underscan", "underscan hborder" and
"underscan vborder" properties (radeon, amd and nouveau) and we are
about to add the same kind of thing in VC4.
Define generic underscan props and add new fields to the drm_connector
state so that the property parsing logic can be
Now that the plane code takes the underscan setup into account, we can
safely attach the underscan props to the HDMI connector.
We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.
Note that these underscan props match pretty well the
overscan_{left,right
Applying an underscan setup is just a matter of scaling all planes
appropriately and adjusting the CRTC X/Y offset to account for the
horizontal and vertical border.
Create an vc4_plane_underscan_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are ready
Hello,
This is an attempt at providing generic support for underscan connector
props. We already have 3 drivers defining the same underscan, underscan
vborder and underscan hborder properties (amd, radeon and nouveau) and
I am about to add a new one, hence my proposal to put the prop parsing
code
https://bugs.freedesktop.org/show_bug.cgi?id=106471
--- Comment #1 from Alex Deucher ---
Does it work properly if you remove the nouveau card or switch the slots?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.
Changes in v2:
- resolved conflict in dpu_unbind
- dropped (Reviewed-by: Sean Paul) due to above change
Signed-off-b
dpu_core_perf_crtc_update() is responsible for aggregating
the data bus bandwidth and dpu core clock rate requirements
and request the same for all active crtcs.
Currently, there is no error handling support in this function
so there is no way caller can know if the perf request fails.
This change
Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.
Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle
https://bugs.freedesktop.org/show_bug.cgi?id=106474
--- Comment #2 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from dpu_power_handle
MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.
Also dpu core clock management code is restricted to
dpu_core_perf module.
Changes in v2:
- remove local variable to hold and return error code
in _dpu_
Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.
Changes in v2:
- resolved merge conflict in dpu_power_resource_init
- dropped (Reviewed
The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.
Use pm_runtime_get/put_sync calls on dpu device.
The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via runtime_p
The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.
Changes in v2:
- none
Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
---
Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.
Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss an
SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.
Currently, in dpu driver, all the power resource
management is part of power_handle which mana
MDSS top level device includes the common power resources
and it's corresponding driver (i.e. mdp5_mdss) handles call
to enable/disable runtime_pm for enabling these resources.
Remove redundant pm_runtime_enable call from msm_drv.
Changes in v2:
- none
Signed-off-by: Rajesh Yadav
Reviewe
SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.
Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.
Add mdss helper interface (msm_m
SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes
sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper
manages common resources like common clocks, main power supply and
interrupts for its sub-blocks.
But current dpu driver implementation is based on a flat
On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
> If want to do training outside DP Firmware, need phy voltage swing
> and pre_emphasis value.
>
> Signed-off-by: Lin Huang
Adding Rob Herring so he has a hope of seeing this.
> ---
> Changes in v2:
> - rebase
>
> Documentation/device
On Wed, May 09, 2018 at 06:22:42PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
FTR, I've previously reviewed this at
https://chromium-
On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> @@ -0,0 +1,297 @@
> +/*
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
This really should be the first line, and with a C++ style comment, as
in:
// SPDX-License-Identifier: (G
On Wed, May 09, 2018 at 06:22:41PM +0800, Lin Huang wrote:
> From: Chris Zhong
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Lin Huang
FTR, I've already d
The rcar DT overlays are missing symetrical remote-endpoint properties
in their graph nodes because the remote-endpoint is fixed up at
run-time. Disable the dtc 'graph-endpoint' warnings when compiling these
overlays. If this becomes a common problem for overlays, then perhaps
this check needs to b
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #14 from john-s...@gmx.net ---
Same Problem here (HP zbook 15u 5g).
https://bugzilla.kernel.org/show_bug.cgi?id=199609
Chen Yu recommended to write a request on amd-...@lists.freedesktop.org with no
success so far.
https://lists.fr
On Mon, 7 May 2018 17:25:30 +0200
Daniel Vetter wrote:
> On Mon, May 07, 2018 at 05:15:33PM +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote:
> > > We have 3 drivers defining the "underscan", "underscan hborder" and
> > > "underscan vborder" proper
On Tue, 8 May 2018 10:18:10 +1000
Ben Skeggs wrote:
> On 8 May 2018 at 04:26, Harry Wentland wrote:
> >
> >
> > On 2018-05-07 12:19 PM, Boris Brezillon wrote:
> >> On Mon, 7 May 2018 18:01:44 +0300
> >> Ville Syrjälä wrote:
> >>
> >>> On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillo
On Fri, May 11, 2018 at 07:15:42AM +0300, Haneen Mohammed wrote:
> This patch matches the sysfs name used in the unlinking with the
> linking function. Otherwise, remove_compat_control_link() fails to remove
> sysfs created by create_compat_control_link() in drm_dev_register().
>
> Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #13 from Thomas Martitz ---
I'll report the bug on the other site as well.
In my view: Loading the amdgpu module breaks resuming from suspend. Maybe the
module isn't correctly adapted to the changes made in generic subsystems
earli
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #12 from Michel Dänzer ---
That's debatable, given you bisected to a non-amdgpu commit, which affects WiFi
as well.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #11 from Thomas Martitz ---
I can suspend+resume just fine with amdgpu blacklisted, so I'm under the
impression that this is the right place.
--
You are receiving this mail because:
You are the assignee for the bug.
On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > as found on the Ai
https://bugs.freedesktop.org/show_bug.cgi?id=106473
--- Comment #2 from Matt Whitlock ---
(In reply to Michel Dänzer from comment #1)
> Does
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 help?
I've applied this patch and rebuilt Mesa. I'll reply
On Fri, 11 May 2018, Johan Hovold wrote:
> Hi Lee,
>
> On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> > A number of drivers have been using the wrong OF helper when doing
> > child-node
> > lookups during probe. This meant that they were doing tree-wide searches
> > rather
> >
2018년 05월 10일 23:27에 Souptick Joarder 이(가) 쓴 글:
> On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder
> wrote:
>> Use new return type vm_fault_t for fault handler
>> in struct vm_operations_struct.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Matthew Wilcox
>> ---
>> drivers/gpu/drm/ex
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #10 from Michel Dänzer ---
Looks like you should report this at
https://bugzilla.kernel.org/enter_bug.cgi?product=Power%20Management&component=Hibernation/Suspend
.
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=84740
Jani Saarinen changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #11 from Jani Saarine
https://bugs.freedesktop.org/show_bug.cgi?id=106473
--- Comment #1 from Michel Dänzer ---
Does
https://cgit.freedesktop.org/mesa/mesa/commit/?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2
help?
--
You are receiving this mail because:
You are the assignee for the bug.__
Hey,
Another pull request for drm-misc-next. Previous one was not applied yet,
but only sending delta since last request:
https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html
drm-misc-next-2018-05-11-1:
drm-misc-next for v4.18:
UAPI Changes:
- Aspect ratio support for 64:27 and
Op 09-05-18 om 22:24 schreef Daniel Vetter:
> On Tue, May 08, 2018 at 04:39:45PM +0530, Nautiyal, Ankit K wrote:
>> From: "Sharma, Shashank"
>>
>> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
>> - 64:27
>> - 256:135
>>
>> This patch:
>> - Adds new DRM flags for to represent these new aspe
Hi Lee,
On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> A number of drivers have been using the wrong OF helper when doing child-node
> lookups during probe. This meant that they were doing tree-wide searches
> rather
> than matching on child nodes and that the parent node could e
Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> Change how dma_fence_add_callback() behaves, when the fence
> has error-signaled by the time it is being add. After this commit,
> dma_fence_add_callback() returns the fence error, if it
> has error-signaled before dma_fence_add_callback() is called.
Quoting Ezequiel Garcia (2018-05-10 13:51:56)
> On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote:
> > Hi Ezequiel,
> >
> > On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote:
> > > Change how dma_fence_add_callback() behaves, when the fence
> > > has error-signaled by the time it is
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().
Signed-off-by: Haneen Mohammed
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 i
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Signed-off-by
On Wed, Apr 25, 2018 at 10:29 AM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault and huge_fault
> handler. For now, this is just documenting that the
> function returns a VM_FAULT value rather than an errno.
> Once all instances are converted, vm_fault_t will become
> a distinc
Currently ratelimit_state is protected with spin_lock. If the .lock is
taken at the moment of ___ratelimit() call, the message is suppressed to
make ratelimiting robust.
That results in the following issue issue:
CPU0 CPU1
-- ---
Use new return type vm_fault_t for fault handler in
struct vm_operations_struct. For now, this is just
documenting that the function returns a VM_FAULT
value rather than an errno. Once all instances are
converted, vm_fault_t will become a distinct type.
commit 1c8f422059ae ("mm: change return type
Hi Gerd /Daniel,
On Tue, Apr 24, 2018 at 6:05 PM, Gerd Hoffmann wrote:
> On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
>> > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
>> > > Use new return ty
On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 -
> drivers/g
On 04.05.2018 16:37, Thierry Reding wrote:
> From: Thierry Reding
>
> Attaching to and detaching from an IOMMU uses the same code sequence in
> every driver, so factor it out into separate helpers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/dc.c | 42 ++--
On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote:
> Hi Ezequiel,
>
> On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote:
> > Change how dma_fence_add_callback() behaves, when the fence
> > has error-signaled by the time it is being add. After this commit,
> > dma_fence_add_callback()
Hi Sean,
On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff
There are two issues with ratelimiting as far a I can see:
1. Messages may be lost even if their amount fit burst limit;
2. "suppressed" message may not be printed if there is no call to
___ratelimit() after interval ends.
I address (1) issue in the second patch.
While the (2) issue will requir
99 matches
Mail list logo