On 06/15/2017 11:24 PM, Eric Anholt wrote:
ERR_PTR() needs a negative errno argument.
Thanks, I'll queue it to drm-misc-next-fixes once it's opened.
Archit
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/bridge/panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Hi Mike,
On 16 June 2017 at 05:48, Mike Mestnik wrote:
> I can tell by the 2 color(green and violet) rendering that this driver
> is experimental. Attached is kern.log from some testing I've done.
>
You might be interested in the following bug report. It's the first
hit on google under "radv doo
On 06/16/2017 02:11 AM, Eric Anholt wrote:
If the panel-bridge is being set up after the drm_mode_config_reset(),
then the connector's state would never get initialized, and we'd
dereference the NULL in the hotplug path. We also need to register
the connector, so that userspace can get at it.
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commi
Signed-off-by: Archit Taneja
---
rnndb/hdmi/hdmi.xml | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml
index 69b4828..2bbae43 100644
--- a/rnndb/hdmi/hdmi.xml
+++ b/rnndb/hdmi/hdmi.xml
@@ -457,25 +457,25 @@ xsi:schemaLoc
Signed-off-by: Archit Taneja
---
rnndb/hdmi/hdmi.xml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml
index 2bbae43..76d88a1 100644
--- a/rnndb/hdmi/hdmi.xml
+++ b/rnndb/hdmi/hdmi.xml
@@ -94,6 +94,12 @@ xsi:schemaLocation="http://nouveau.freedesk
Without doing anything in unprepare, the HDMI driver isn't able to
switch modes successfully. Calling set_rate with a new rate results
in an un-locked PLL.
If we reset the PLL in unprepare, the PLL is able to lock with the
new rate.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi
- Add HDMI_INFOFRAME_CONTROL1 register and its bitfields.
- Fix up the HDMI timing registers bitfield widths to 13 bits so that
values greater than 4095 can be written to them. The older chips
(APQ8064 etc) only have 12 bit width for these fields, but KMS won't
let them try to write widths >
A 2 pixel wide pink strip was observed on the left end of some HDMI
monitors configured in a HDMI mode.
It turned out that we were missing out on configuring AVI infoframes, and
unlike APQ8064, the 8x96 HDMI H/W seems to be sensitive to that.
Add configuration of AVI infoframes. While at it, make
Some fixes that makes HDMI more stable on 8x96:
- Make PLL switch to different freqs successfully (when switching between
modes).
- Add AVI infoframes to reemove the pink strips seen on some monitors.
- Update some of the HDMI timing bitfields so that they can take in
values > 4K.
The display
I can tell by the 2 color(green and violet) rendering that this driver
is experimental. Attached is kern.log from some testing I've done.
Jun 15 22:14:47 agartha kernel: [0.00] Command line:
BOOT_IMAGE=/vmlinuz-4.11.0-trunk-amd64
root=UUID=05127f71-6704-4c13-9401-48496c61e0fe ro
rootfla
Hi Linus,
This is the main fixes pull for 4.12-rc6, all pretty normal for this
stage, nothing really stands out. The mxsfb one is probably the
largest and it's for a black screen boot problem.
Dave.
The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:
Linux 4.12-rc5 (2
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
v2: rebase onto other changes.
v1-Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 93 ++
On 2017-06-15 10:26, Marek Vasut wrote:
> On 06/15/2017 05:12 PM, Fabio Estevam wrote:
>> Hi Marek,
>>
>> On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut wrote:
>>
>>> I'm currently on vacation, try one more time and if it doesn't work out
>>> (which means this trivial list is not really working?), I'
On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> arch/hexagon/include/asm/dma-mapping.h | 2 --
> arch/hexagon/kernel/dma.c | 12 +---
> arch/hexagon/kernel/hexagon_ksyms.c| 1 -
> 3 files changed, 9 insertion
On 2017-06-13 17:30, Boris Brezillon wrote:
> Hi Peter,
>
> On Tue, 13 Jun 2017 16:34:25 +0200
> Peter Rosin wrote:
>
>> Hi!
>>
>> I need color lookup support for the atmel-hlcdc driver, and had a peek
>> at the code. I also looked at the drivers/gpu/drm/stm driver and came
>> up with the below
On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote:
> This implementation is simply bogus - hexagon only has a simple
> direct mapped DMA implementation and thus doesn't care about the
> address.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/hexagon/include/asm/dma-mapping.h |
Remove unnecessary variable _misc_ and refactor the code.
A value is assigned to variable _misc_ at lines 1002 and 1004
and then overwritten at line 1127, just before it can be used.
Besides, this variable is only being used as an argument when
calling macro WREG8() and, it is not implied in any o
On 2017-06-15 01:11, Aaro Koskinen wrote:
> Hi,
>
> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> is no display.
>
> Bisected to:
>
> a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> Author: Peter Uj
On Mon, Jun 12, 2017 at 12:24 PM, Carlo Caione wrote:
> On Tue, May 9, 2017 at 7:03 PM, Deucher, Alexander
> wrote:
>>> -Original Message-
>>> From: Daniel Drake [mailto:dr...@endlessm.com]
>>> Sent: Tuesday, May 09, 2017 12:55 PM
>>> To: dri-devel; amd-...@lists.freedesktop.org; Deucher,
On 06/15/2017 05:12 PM, Fabio Estevam wrote:
> Hi Marek,
>
> On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut wrote:
>
>> I'm currently on vacation, try one more time and if it doesn't work out
>> (which means this trivial list is not really working?), I'll send a PR
>> sometime mid-month.
>
> Tried
Remove unnecessary variable smc_result and simplify the logic related.
Variable smc_result is only being used to store the return value of function
si_send_msg_to_smc() and then compare this value against constant
PPSMC_Result_OK. In other cases this variable is not even used after
storing a value
On 2017-06-15 13:54, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 13:47:35 +0200
> Peter Rosin wrote:
>
>> On 2017-06-15 12:15, Boris Brezillon wrote:
>>> On Thu, 15 Jun 2017 11:54:29 +0200
>>> Peter Rosin wrote:
>>>
On 2017-06-13 17:30, Boris Brezillon wrote:
> Hi Peter,
>
>>>
From: Peter Rosin
Remove the layer.
Fixes: 5b9fb5e6c6c7 ("drm: atmel-hlcdc: add support for sama5d4 SoCs")
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/atmel-
Hi Rob,
I can see how we can trigger the shrinker on objB while holding objA->lock. So,
the nested lock with class SHRINKER makes sense.
However, I’m trying to figure how the get_pages/vmap/fault path on an objA can
end up triggering the shrinker on objA itself. As objA itself would not be
purg
On 2017-06-15 11:37, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 11:24:13 +0200
> Peter Rosin wrote:
>
>> From: Peter Rosin
>>
>> Remove the layer.
>
> Duh. It was present in the datasheet I had. Just downloaded last
> version of the datasheet and it's no longer there.
Heh.
> Nicolas, there'
Bonjour Laurent!
I was wondering why you choose to name the lvds-encoder.c driver like so.
(https://github.com/torvalds/linux/commit/67cc3e22b00f9027eaa0902ecf52ac5f4f5cac97)
The driver is clearly a drm_bridge, nested in the drm/bridge subdir... so why
not "lvds-bridge.c"?
Also, the associated b
On 2017-06-15 12:15, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 11:54:29 +0200
> Peter Rosin wrote:
>
>> On 2017-06-13 17:30, Boris Brezillon wrote:
>>> Hi Peter,
>>>
>>> On Tue, 13 Jun 2017 16:34:25 +0200
>>> Peter Rosin wrote:
>>>
Hi!
I need color lookup support for the atm
rc6 is this Sunday most likely which means I'll be mostly finished
merging at that point.
nouveau and msm are known outstanding, but I've talked to those,
anyone else got something I should know about?
Dave.
___
dri-devel mailing list
dri-devel@lists.fr
Eric Anholt writes:
> [ Unknown signature status ]
> Boris Brezillon writes:
>
>> On Tue, 06 Jun 2017 13:27:09 -0700
>> Eric Anholt wrote:
>>
>>> Boris Brezillon writes:
>>>
>>> > The VC4 KMS driver is implementing its own ->atomic_commit() but there
>>> > are a few generic helpers we can use
Boris Brezillon writes:
> There are two problems related to VBLANK handling in the current CRTC
> driver:
>
> * VBLANK events are missed when the CRTC is being disabled because the
> driver does not wait till the end of the frame before stopping the
> HVS and PV blocks. In this case, we shoul
With this squashed in, the vc4 patch is:
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
---
Without this, the cursor never moved :)
drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
ind
Just a reminder.
Thanks.
On 06/09/2017 05:30 PM, Andrey Grodzovsky wrote:
Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
After dumping the atomic state I relized that in this case there was
not even one C
On Thu, Jun 15, 2017 at 5:59 PM, Susheelendra, Sushmita
wrote:
> Hi Rob,
>
> I can see how we can trigger the shrinker on objB while holding objA->lock.
> So, the nested lock with class SHRINKER makes sense.
> However, I’m trying to figure how the get_pages/vmap/fault path on an objA
> can end up
Boris Brezillon writes:
> Hi Eric,
>
> On Wed, 7 Jun 2017 17:13:36 -0700
> Eric Anholt wrote:
>
>> This allows mesa to set the tiling format for a BO and have that
>> tiling format be respected by mesa on the other side of an
>> import/export (and by vc4 scanout in the kernel), without defining
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #68 from i...@posteo.net ---
(In reply to Alex Deucher from comment #67)
> Do you get flickering at 144Hz without forcing the mclk to high? I.e.,
> without these patches:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linu
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #18 from Alex Deucher ---
The VCE regression is fixed. If you want to try those patches, they are
available here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.13-wip
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #67 from Alex Deucher ---
(In reply to iuno from comment #66)
> (In reply to Alex Deucher from comment #65)
> >
> > Yes, that is independent of the patch in attachment 131983 [details]
> > [review]
> > [review]. The driver disables
Hi -misc committers,
I just sent out the last drm-misc-next pull request for 4.13. Once Dave has
applied it to drm-next, I'll perform a backmerge (there is a single patch
erroneously committed to drm-misc-next-fixes which prevents fast-forward) and
the branch will be open for fixes.
Sean
--
Sea
Hi Dave,
Here's the final drm-misc-next request for 4.13, we'll switch over to
drm-misc-next-fixes for 4.13 with drm-misc-next now targetting 4.14. I'll send
out a separate email to -misc committers to ensure we're all on the same page.
The drm_panel_bridge change introduced a little bit of instab
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #66 from i...@posteo.net ---
(In reply to Alex Deucher from comment #65)
>
> Yes, that is independent of the patch in attachment 131983 [details]
> [review]. The driver disables dynamic mclk switching for refresh rates
> above 120 hz
This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.
v2: Set the same default orientation as the closed source firmware
used, which is the best for viewing angle.
v3: Rewrite as an i2c client driver
This doesn't yet cover input, but the driver does get the display
working when the firmware is disabled from talking to our I2C lines.
Signed-off-by: Eric Anholt
---
.../panel/raspberrypi,7inch-touchscreen.txt| 49 ++
1 file changed, 49 insertions(+)
create mode 1006
This commit is not intended to be merged. Instead we will use
overlays to enable the panel, and this commit is just a demo of how
things get wired up.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 5
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 5
The DPHY spec requires a much larger T_INIT than I was specifying
before. In the absence of clear specs from the slave of what their
timing is, just use the value that the firmware was using.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++-
1 file changed, 11 inse
If the panel-bridge is being set up after the drm_mode_config_reset(),
then the connector's state would never get initialized, and we'd
dereference the NULL in the hotplug path. We also need to register
the connector, so that userspace can get at it.
Signed-off-by: Eric Anholt
---
drivers/gpu/d
The logic was all right in the end, the name was just backwards.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 15f6d5005ab9..629d372633e6
After splitting the panel driver out into a panel and bridge due to
panel review, the feedback from bridge maintainers was that it didn't
make sense as a bridge. I completely agree with them. This series
returns the driver to being a panel, but this time probing as an i2c
client rather than a DSI
I'm not sure what changed where I started getting vrefresh=0 from the
mode to be fixed up.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 629d3
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #65 from Alex Deucher ---
(In reply to iuno from comment #64)
> (In reply to Alex Deucher from comment #63)
> >
> > Are you forcing the power state to high? The mclk shouldn't be affected by
> > the display clock.
>
> No, setting t
Hi Dave,
Here's this week's pull. Nothing worth noting beyond the onelines and summaries.
drm-misc-fixes-2017-06-15:
Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra sta
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #64 from i...@posteo.net ---
(In reply to Alex Deucher from comment #63)
>
> Are you forcing the power state to high? The mclk shouldn't be affected by
> the display clock.
No, setting the refresh rate to 144 results in high mclk, e
On Thu, Jun 15, 2017 at 01:53:15PM -0400, Sean Paul wrote:
> On Fri, May 05, 2017 at 03:01:41PM -0300, Fabio Estevam wrote:
> > According to the eLCDIF initialization steps listed in the MX6SX
> > Reference Manual the eLCDIF block reset is mandatory.
> >
> > Without performing the eLCDIF reset th
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #63 from Alex Deucher ---
(In reply to iuno from comment #62)
> It works for me, too, but I already said that ;-)
>
> However, the problem Pavel describes is another bothersome issue. PowerPlay
> changes to the higher memory DPM stat
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #62 from i...@posteo.net ---
It works for me, too, but I already said that ;-)
However, the problem Pavel describes is another bothersome issue. PowerPlay
changes to the higher memory DPM state which results in ~40 Watts (Hawaii;
esti
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #17 from Alex Deucher ---
(In reply to Carlo Caione from comment #16)
> I see. The problem is that the garbage lines result in a very bad experience
> for the user. Do you have any idea how to fix / mitigate that?
If it's related to
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #61 from Pavel Bordukov ---
(In reply to Alex Deucher from comment #60)
> Created attachment 131983 [details] [review]
> possible fix
It works for me (MG279Q, R9 290x, vanilla 4.11.4, echo high >
/sys/class/drm/card0/device/power_dpm
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #16 from Carlo Caione ---
I see. The problem is that the garbage lines result in a very bad experience
for the user. Do you have any idea how to fix / mitigate that?
--
You are receiving this mail because:
You are the assignee for
ERR_PTR() needs a negative errno argument.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/bridge/panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 99f9a4beb859..67fe19e5a9c6 100644
--- a/drivers/gpu/d
On Fri, May 05, 2017 at 03:01:41PM -0300, Fabio Estevam wrote:
> According to the eLCDIF initialization steps listed in the MX6SX
> Reference Manual the eLCDIF block reset is mandatory.
>
> Without performing the eLCDIF reset the display shows garbage content
> when the kernel boots.
>
> In earl
Smaller scope reduces visibility of variable and makes usage of
uninitialized variable less possible.
Changes in v2:
- separate declaration and initialization
Changes in v3:
- add missing signed-off-by tag
Signed-off-by: Dawid Kurek
---
drivers/gpu/drm/drm_atomic.c | 3 ++-
1 fi
On 15/06/17, Sean Paul wrote:
> On Thu, Jun 15, 2017 at 04:04:36PM +0200, Dawid Kurek wrote:
> > Smaller scope reduces visibility of variable and makes usage of
> > uninitialized variable less possible.
> >
> > Changes in v2:
> > - separate declaration and initialization
>
> Your patch is mis
On Thu, Jun 15, 2017 at 04:04:36PM +0200, Dawid Kurek wrote:
> Smaller scope reduces visibility of variable and makes usage of
> uninitialized variable less possible.
>
> Changes in v2:
> - separate declaration and initialization
Your patch is missing Signed-off-by tag
Sean
> ---
> drive
On Wed, Jun 14, 2017 at 10:39:42AM -0400, mathieu.larou...@matrox.com wrote:
> From: Mathieu Larouche
>
> - Changed the HiPri value for G200e4 to always be 0.
> - Added Bandwith limitation to block resolution above 1920x1200x60Hz
>
> Signed-off-by: Mathieu Larouche
Applied to -misc-fixes w
Yes, we should check for features, not for some standard version that
implements some/all of those features. But not convinced we need any
featur flags for the other things you listed. Aren't we already doing
all those things anyway?
Yep, I realized you will come back with this point, while typi
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #15 from Alex Deucher ---
(In reply to Carlo Caione from comment #14)
>
> Fortunately it disappears after ~2 seconds when plymouth kicks in. My
> impression is that the visual corruption is triggered again when
> interpreting some a
On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
> > On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 6/15/2017 8:13 PM, Ville Syrjälä wrote
On 15/06/17, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Dawid Kurek wrote:
> > On 15/06/17, Jani Nikula wrote:
> >> Separate declaration and initialization would lead to a cleaner patch
> >> and result.
> >
> > I saw combining declaration and initialization is quite common, i.e. in
> > drm_atomic f
Regards
Shashank
On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR4
tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head: 43240bbd871e2c8f89584d369278a3d18680d9ea
commit: fa6d095eb23a8b1aae78d221879032497f6e457f [2/20] drm/tegra: Add driver
documentation
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: conve
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #14 from Carlo Caione ---
> not likely related.
Alright, any hint where to start looking? As I said before it looks like the
visual corruption (this https://pasteboard.co/qrC9mh4p.jpg) at boot starts at
[drm] amdgpu atom DIG backli
On Wed, Jun 14, 2017 at 11:35:18PM +0200, Dawid Kurek wrote:
> Forward declarations in C are great but I'm pretty sure one is enough.
Applied to drm-misc-next
Thanks,
Sean
>
> Signed-off-by: Dawid Kurek
> ---
> include/drm/drm_connector.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --
On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two
Quoting kbuild test robot (2017-06-15 16:23:12)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check
> before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive
> or usb_free_urb is not needed. Maybe consider reorganizing relevant code to
> avoid passing
Hi Dave,
A few more patches for 4.13. Mostly bug fixes and code cleanup. This is on
top of my pull request from last week.
The following changes since commit b58c11314a1706bf094c489ef5cb28f76478c704:
drm/amdgpu: drop deprecated drm_get_pci_dev and drm_put_dev (2017-06-08
10:54:39 -0400)
ar
If your username on fd.o differs from your local username, you'll run
into issues while setting up dim.
Let's use regexp to filter remotes so it doesn't fail.
Signed-off-by: Lionel Landwerlin
---
dim | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/dim b/dim
index
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #13 from Alex Deucher ---
(In reply to Carlo Caione from comment #12)
> Also (in case it is useful for the corruption issue):
>
not likely related.
> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Devi
Regards
Shashank
On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 o
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #12 from Carlo Caione ---
Also (in case it is useful for the corruption issue):
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Device 9874 (rev ca)
...
03:00.0 Display controller: Advanced Micro Devices, I
drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid
passing NULL values.
NULL check before some freeing functions
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: 8c45cec48e5871f93e56650f7e476d4ea7174a0e
commit: d55495b4dcce2efb4656edfe211eb0bfb27c3387 [2/3] drm/i915: Use
vma->exec_entry as our double-entry placeholder
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #11 from Carlo Caione ---
Yes, that solves the panic issue, thank you. I still have the corruption at
boot though, any idea what that can be?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #60 from Alex Deucher ---
Created attachment 131983
--> https://bugs.freedesktop.org/attachment.cgi?id=131983&action=edit
possible fix
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi Marek,
On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut wrote:
> I'm currently on vacation, try one more time and if it doesn't work out
> (which means this trivial list is not really working?), I'll send a PR
> sometime mid-month.
Tried your suggestion, but it did not work.
Could you please con
On Thu, 15 Jun 2017, Dawid Kurek wrote:
> On 15/06/17, Jani Nikula wrote:
>> Separate declaration and initialization would lead to a cleaner patch
>> and result.
>
> I saw combining declaration and initialization is quite common, i.e. in
> drm_atomic file. Personally, I also prefer those in one st
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #10 from Alex Deucher ---
Created attachment 131982
--> https://bugs.freedesktop.org/attachment.cgi?id=131982&action=edit
possible fix
This patch should fix the issue.
--
You are receiving this mail because:
You are the assignee
Hi Dave, a GVT fix and a couple of rotation related fixes.
BR,
Jani.
The following changes since commit ef6c4d75e35345f8f362d6754bcd9a28292a897c:
drm/i915: fix warning for unused variable (2017-06-08 17:09:44 +0300)
are available in the git repository at:
git://anongit.freedesktop.org/git
On Thu, Jun 15, 2017 at 07:01:38PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC
https://bugs.freedesktop.org/show_bug.cgi?id=101387
--- Comment #9 from Alex Deucher ---
Can you please attach a copy of your vbios?
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
--
You are receiving this mail because:
You
On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
>
> These blocks are:
>
> - YCBCR420vd
On 15/06/17, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Dawid Kurek wrote:
> > Smaller scope reduces visibility of variable and makes usage of
> > uninitialized variable less possible.
> > ---
> > drivers/gpu/drm/drm_atomic.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > d
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #59 from i...@posteo.net ---
(In reply to Eike from comment #56)
> Sorry to correct you, but my monitor has not been faultier than any other
> MG279Q that was bought before 2017.
Mine is bought before 2017 and it ain't broken.
> BTW
Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical
OR operators to build up a value to be written in the
REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it
should have used bitwise operators.
Signed-off-by: Liviu Dudau
Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support")
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #66 from siyia (eutychio...@gmail.com) ---
Regression persists with kernel 4.11.5, but
https://bugzilla.kernel.org/attachment.cgi?id=256949 thankfully works and fixes
the issue.
--
You are receiving this mail because:
You are watchin
Smaller scope reduces visibility of variable and makes usage of
uninitialized variable less possible.
Changes in v2:
- separate declaration and initialization
---
drivers/gpu/drm/drm_atomic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.
On Thu, Jun 15, 2017 at 02:18:23AM +0300, Dmitry Osipenko wrote:
> I've dropped the two "GART restoring" patches from the series, postponing
> them till a full solution of GART utilization would be ready.
>
> The "Forbid relocation address shifting in the firewall" patch has been
> reverted to v1,
Regards
Shashank
On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 mo
On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA
---
This is roughly based on Chris's suggestion, in particular the part
about using mutex_lock_nested(). It's not *exactly* the same, in
particular msm_obj->lock protects a bit more than just backing store
and we don't currently track a pin_count. (Instead we currently
keep pages pinned until the
1 - 100 of 125 matches
Mail list logo
