On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> >> It seems that I got no responses so far for clarification requests
> >> according to the documentation in a direction I hoped for.
> >
> > That's because you are pretty unresponsive to direction.
>
> From which places did you get this impression
On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote:
> > > It seems that I got no responses so far for clarification requests
> > > according to the documentation in a direction I hoped for.
> >
> > That's because you are pretty unresponsive to direction.
>
> From which places did you get
On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote:
> >> Omit an extra message for a memory allocation failure in these functions.
> …
> > nak, unlike many others, these message give extra info on which
> > allocation failed, that can be useful.
>
> Can a default allocation failure
Calculate scaling parameters and call appropriate scaler set up
function.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 12 +++-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 115 +---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 --
3 files change
Till now, plane selection was hardcoded to first overlay in first UI
channel.
It turns out that overlays don't fit well in current DRM design, because
they can't be blended together or scaled independetly when they are set
to same channel.
Beause of that, always use only first overlay in each cha
While DE2 driver works, parts of the code are not in optimal place. Reorder
it so it will be easier to support multiple planes.
This commit doesn't do any functional change besides removing two not
very useful debug messages.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_a
Since current DE2 driver doesn't know how to scale yet, add atomic check
function which checks that.
Nice side effect of that function is that populates clipped coordinates
and checks visibility of the plane. That data will be used in the
future.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/dr
Basic principle of operation when using YUV framebuffer is that chroma
planes have to be upscaled to same size as luma.
Because of that, expand DE2 scaler library to support that.
BSP driver uses another set of FIR filter coefficients for YUV planes.
Signed-off-by: Jernej Skrabec
---
drivers/g
On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> >> Can a default allocation failure report provide the information
> >> which you might expect so far?
> >
> > You should be able to answer that question yourself.
>
> I can not answer this detail completely myself because my kn
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or not.
This new property will tell which set of base addresses to take.
0 - first mixer or second mixer with VEP support
1 - second mixer without VEP support
Sign
DE2 have many CSC units - channel input CSC, channel output CSC and
mixer output CSC and maybe more.
Fortunately, they have all same register layout, only base offsets
differs.
Add support only for channel output CSC for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile
On Mon, Nov 27, 2017 at 03:33:13PM -0600, Andrew F. Davis wrote:
> On 11/27/2017 01:07 PM, Joe Perches wrote:
> > On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
> >> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
> >>> From: Markus Elfring
> >>> Date: Sun, 26 Nov 2017 19:46:09 +0100
>
+nouv...@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_an
On 11/27/2017 01:07 PM, Joe Perches wrote:
> On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
>> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
>>> From: Markus Elfring
>>> Date: Sun, 26 Nov 2017 19:46:09 +0100
>>>
>>> Omit an extra message for a memory allocation failure in these funct
This commit expands translation of DRM YUV format to HW specific
information.
It doesn't do any functional changes.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 147 +++-
drivers/gpu/drm/sun4i/sun8i_mixer.h | 16
2 files changed,
On Mon, Nov 27, 2017 at 08:22:51PM +0100, Ladislav Michl wrote:
> On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> > >> Can a default allocation failure report provide the information
> > >> which you might expect so far?
> > >
> > > You should be able to answer that question y
Now that we have properly clipped coordinates in plane state structure,
use them.
This also fixes bug where source x and y were adjusted for negative
value, but width and height weren't. It wasn't discovered because
primary plane usually doesn't have negative coordinates.
Signed-off-by: Jernej Sk
Support for multiple UI planes can now be easily enabled just by adding
more planes with different index.
For now, add immutable zpos property.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 38 +
1 file changed, 17 insertions(+), 21
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
>
>
> On 11/23/2017 03:11 AM, Christian König wrote:
>> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
>>> On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
> On 11/22/2017 05:09 AM, Christian Köni
This commit adds basic support for VI planes. They are meant for video
overlay and because of that they support YUV formats too. However, using
YUV planes is not straightforward, so only RGB support for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 40 +++---
Currently only a few RGB formats are supported by the DE2 driver. Add
support for all formats supported by the HW.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 19 -
drivers/gpu/drm/sun4i/sun8i_mixer.c | 134
drivers/gpu/drm/su
Current DE2 driver is very basic and uses a lot of magic constants since
there is no documentation and knowledge about it was limited at the time.
With studying BSP source code, deeper knowledge was gained which allows
to improve mainline driver considerably.
At the beginning of this series, some
Now that we have all required bits, add support for YUV formats.
DRM subsystem doesn't know YUV411 semi-planar format, so leave that out
for now.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_layer.c | 56 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 110 +++
Scaler library currently supports scaling only RGB planes on VI planes.
Coefficients and algorithm which ones to select are taken from BSP driver.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Makefile | 2 +-
drivers/gpu/drm/sun4i/sun8i_scaler.c | 667
Change zpos of VI plane so it is above primary.
Clearly this works only if mixer supports only one VI plane, but it is
good enough for testing and developing.
Proper solution with zpos property should be developed instead.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c |
+dri-devel@lists.freedesktop.org
On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_a
No all SoCs support scaling on all channels. For example, V3s support
scaling only on VI channels. Because of that, add additional
configuration bitmask which tells which channel support scaler.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 +
drivers/gpu/drm/sun4i/su
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.
Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
intel_guc_fw.c")
Cc: Michal Wajdeczko
Signed-off-by: Jonathan Neuschäfer
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed,
Since the time initial DE2 driver was written, some knowledge was gained
what setting are really necessary and what most of the magic values
mean.
This commit renames some of the macro names to better fit the real
meaning, replace default values with self explaining macros where
possible and remov
On 2017-11-27 11:00 +0200, Laurent Pinchart wrote:
> On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote:
> > On 2017-11-05 11:41 -0500, Nick Bowler wrote:
[...]
> > > Bisection implicates the following commit:
> > >
> > > 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 141432
Addresses-Coverity-ID: 141433
Addresses-Coverity-ID: 141434
Addresses-Coverity-ID: 141435
Addresses-Coverity-ID: 141436
Addresses-Coverity-ID: 1357360
Addresse
Hello there,
linux-4.15-rc1/drivers/gpu/drm/i915/gvt/cmd_parser.c:1640]: (style) Checking if
unsigned variable 'bb_size' is less than zero.
Source code is
/* get the size of the batch buffer */
bb_size = find_bb_size(s);
if (bb_size < 0)
return -EINVAL;
but
static int fin
It seems that I got no responses so far for clarification requests
according to the documentation in a direction I hoped for.
>>>
>>> That's because you are pretty unresponsive to direction.
>>
>> From which places did you get this impression?
>
> Perhaps from the text that you have writ
On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
wrote:
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.
Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
intel_guc_fw.c")
Cc: Michal Wajdeczko
Signed-off-by: Jonathan
On Mon, Nov 27, 2017 at 05:07:04PM +0100, Jernej Škrabec wrote:
> Hi Maxime,
>
> Dne ponedeljek, 27. november 2017 ob 16:41:29 CET je Maxime Ripard napisal(a):
> > It seems like the mixer can only run properly when clocked at 150MHz. In
> > order to have something more robust than simply a fire-an
Hi,
On Tue, Nov 28, 2017 at 12:19:44AM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 27, 2017 at 11:41 PM, Maxime Ripard
> wrote:
> > Add support for the A83T display pipeline.
> >
> > Reviewed-by: Chen-Yu Tsai
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/devicetree/bindings/display/s
Hi,
On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard napisal(a):
> > Add support for the A83T display pipeline.
> >
> > Reviewed-by: Chen-Yu Tsai
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/devic
> How many times have I told you to include the reason for
> your patches in your proposed commit message?
It might be useful to look again.
> Too often.
I answered this feedback to some degree.
> Many people do not know that a generic kmalloc does a
> dump_stack() on OOM.
This is another in
Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky:
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
On 11/23/2017 03:11 AM, Christian König wrote:
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/
On Fri, Nov 24, 2017 at 07:48:22AM +0100, Greg KH wrote:
> On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
> > Rainer Fiebig wrote:
> > > Maarten Lankhorst wrote:
> > >> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> > >>> Jani Nikula wrote:
> > On Sun, 19 Nov 2017, Greg KH wrot
On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> It seems that I got no responses so far for clarification requests
> according to the documentation in a direction I hoped for.
> >>>
> >>> That's because you are pretty unresponsive to direction.
> >>
> >> From which places did you get t
On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> > How many times have I told you to include the reason for
> > your patches in your proposed commit message?
>
> It might be useful to look again.
>
>
> > Too often.
>
> I answered this feedback to some degree.
>
>
> > Many people do not know that
https://bugzilla.kernel.org/show_bug.cgi?id=197925
beniwtv (beni...@relamp.tk) changed:
What|Removed |Added
CC||beni...@relamp.tk
--- Comme
Hi Brian,
On 11/28/2017 02:05 AM, Brian Norris wrote:
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> parent driver might need to own this. Instead, let's return our
> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
And many thanks for this cleanup.
On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
> enabled?
I doubt SWIOTLB provides any benefit for you.
Can you test if Christian's patch fixes the problem with SWIOTLB disabled?
--
Earthling Michel Dänzer
>> I got an other impression. The probability for disagreements is increasing
>> in relation to the number of contributors to which I show change
>> possibilities.
>
> No. You should learn from the previous submissions what concerns people
> have and address them up front.
The concerns can vary
Hi,
On Mon, Nov 27, 2017 at 04:46:32PM +0800, Chen-Yu Tsai wrote:
> The sun4i DRM driver maintains a list of compatible strings it uses to
> check if a device node within the display component graph is a TCON.
> The TCON driver also has this list, used to bind the TCON driver to
> the device. Thes
>>> Many people do not know that a generic kmalloc does a
>>> dump_stack() on OOM.
>>
>> This is another interesting information, isn't it?
>>
>> It is expected that the function “devm_kzalloc” has got a similar property.
>
>
> You don't have to expect this. Go look at the definition of devm_kza
On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote:
> On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > the same code. E
Hi and sorry for the delayed reply!
> Hi Kees,
>
> On Sat, 25 Nov 2017 12:57:04 -0800
> Kees Cook wrote:
>
> > On Wed, Nov 22, 2017 at 11:57 PM, Daniel Vetter wrote:
> > > On Wed, Nov 22, 2017 at 07:21:00PM +0100, Boris Brezillon wrote:
> > >> On Wed, 22 Nov 2017 19:13:09 +0100
> > >> Daniel
On Sat, Nov 25, 2017 at 06:33:39PM +0100, Hans de Goede wrote:
> Ideally we could use the VBT for this, that would be simple, in
> intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
> connector->display_info.panel_orientation accordingly and call
> drm_connector_init_panel_orientation_p
>>> On 28.11.17 at 10:12, wrote:
> In theory the BIOS would search for address space and won't find
> anything, so the hotplug operation should fail even before it reaches
> the kernel in the first place.
How would the BIOS know what the OS does or plans to do? I think
it's the other way around
On Sat, Nov 25, 2017 at 08:27:31PM +0100, Hans de Goede wrote:
> This fixes the following make kerneldocs messages:
>
> ./include/drm/drm_mode_config.h:772: warning: No description found for
> parameter 'modifiers_property'
> ./include/drm/drm_mode_config.h:772: warning: Excess struct member
> '
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
> Hi All,
>
> Here is v6 of my series to add a "panel orientation" property to
> the drm-connector for the LCD panel to let userspace know about LCD
> panels which are not mounted upright, as well as detecting upside-down
> panels with
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel in the first place.
How would the BIOS know what the OS does or plans to do
>> How will this aspect evolve further?
>
> I do not follow.
Interesting …
> This is OMAP framebuffer driver, so in this case, there is zero variation.
How much are you interested to compare differences in build results
also for this software module because of varying parameters?
Which parame
>>> On 28.11.17 at 11:17, wrote:
> Am 28.11.2017 um 10:46 schrieb Jan Beulich:
> On 28.11.17 at 10:12, wrote:
>>> In theory the BIOS would search for address space and won't find
>>> anything, so the hotplug operation should fail even before it reaches
>>> the kernel in the first place.
>> Ho
On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> Hi,
>
> This series is to add new drm formats needed by some Xilinx IPs.
> Some formats have unique characteristics such as pixels not being
> byte-aligned. For instance, some 10bit formats have 2bit padding
> after every 3-10bit compone
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once
We now have a generic dw-mipi-dsi bridge driver.So we send
this patchs to moving rockchip dw-mipi-dsi driver to that
in order to add new features(dual mipi support).
Update ROCKCHIP DSI controller driver that uses the Synopsys
DesignWare MIPI DSI host controller bridge.
ChangeLog:
v2:
add err_p
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
Signed-off-by: Brian Norris
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Archit Taneja
Acked
This patch update documentation of device tree bindings for the rockchip
DSI controller based on the Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 ++
1 file changed, 19 insertions(+), 4 de
Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.
So adjust it.
Signed-off-by: Nickey Yang
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +
This patch update mipi node for RK3399 DSI controller
based on the Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.
v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
fix typo, use of_device_get
Hi Archit,
On 2017年11月28日 14:27, Archit Taneja wrote:
Hi,
Thanks a lot for working on this. Some comments below.
Those comments have fixed in patch_v3
https://patchwork.kernel.org/patch/10079857/
Thanks for review.
On 11/28/2017 07:25 AM, Nickey Yang wrote:
Add the ROCKCHIP DSI controller
On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote:
> > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > > Almost all drivers usin
fbdev is closed for new drivers, drm won't take anything but atomic
drivers.
Cc: Greg Kroah-Hartman
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Sudip Mukherjee
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/staging/sm750fb/TODO | 4 ++--
On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
> Some drivers like i915 start with crtc's enabled, but with deferred
> fbcon setup they were no longer disabled as part of fbdev setup.
> Headless units could no longer enter pc3 state because the crtc was
> still enabled.
>
> Fix
On Fri, Sep 8, 2017 at 6:47 PM, Krzysztof Kozlowski wrote:
> On Thu, Aug 24, 2017 at 03:33:59PM +0200, Andrzej Hajda wrote:
>> Since i80/command mode is determined in runtime by propagating info
>> from panel this property can be removed.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> arch/arm64/b
>> I am not going to “verify” your update suggestion by my evolving approaches
>> around the semantic patch language (Coccinelle software) at the moment.
>
> As you are sending patches as Markus Elfring
I am contributing also some update suggestions.
> I would expect you take Coccinelle's sugge
Am 28.11.2017 um 11:53 schrieb Jan Beulich:
On 28.11.17 at 11:17, wrote:
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel
https://bugs.freedesktop.org/show_bug.cgi?id=103743
--- Comment #7 from Nicolai Hähnle ---
Created attachment 135749
--> https://bugs.freedesktop.org/attachment.cgi?id=135749&action=edit
patch for related issue
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=103743
--- Comment #8 from Nicolai Hähnle ---
Created attachment 135750
--> https://bugs.freedesktop.org/attachment.cgi?id=135750&action=edit
patch to fix this issue
Two patches for LLVM attached that fix the issue for me.
--
You are receiving thi
On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote:
> > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 24, 2017 at 06:53:3
Hi Brian,
Thank you for the patch.
I'd mention dw-mipi-dsi in the subject line as the directory contains the dw-
hdmi driver as well that this patch doesn't touch.
On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
This is a false positive, but I wonder if it is really necessary to put
the assignment in the conditional test expression.
julia
-- Forwarded message --
Date: Tue, 28 Nov 2017 13:23:36 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [PATCH] drm/nouveau/
https://bugs.freedesktop.org/show_bug.cgi?id=103953
Bug ID: 103953
Summary: [DC] Polaris10: Missing modes when enabling DC
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=103953
--- Comment #1 from Dominik Paulus ---
Created attachment 135752
--> https://bugs.freedesktop.org/attachment.cgi?id=135752&action=edit
dmesg with default settings
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=103953
--- Comment #2 from Dominik Paulus ---
Created attachment 135753
--> https://bugs.freedesktop.org/attachment.cgi?id=135753&action=edit
Xorg.log with dc enabled
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote:
> On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
> > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote:
> > > > On Mon, Nov 27, 2017 at 11:27
https://bugs.freedesktop.org/show_bug.cgi?id=103953
--- Comment #3 from Dominik Paulus ---
Created attachment 135754
--> https://bugs.freedesktop.org/attachment.cgi?id=135754&action=edit
Xorg.log with dc disabled
--
You are receiving this mail because:
You are the assignee for the bug.___
Am 27.11.2017 um 13:31 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
tests/amdgpu/amdgpu_test.c | 2 +-
tests/amdgpu/amdgpu_test.h | 5
tests/amdgpu/cs_tests.c| 64 +++---
3 files changed,
On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote:
> Put include in alphabetic order
Why???
That should not matter at all.
I'll take this, but really, ick ick ick ick ick.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
On Mon, Nov 06, 2017 at 04:59:45PM +0100, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones
2017-11-28 14:20 GMT+01:00 Greg KH :
> On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote:
>> Put include in alphabetic order
>
> Why???
Mainly because the next patch in the series adds new includes and I have
decide to split clean-up and new feature patches
>
> That should not mat
Hi,
On 28-11-17 11:27, Daniel Vetter wrote:
On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
Hi All,
Here is v6 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well
On Tue, Nov 28, 2017 at 02:34:00PM +0100, Benjamin Gaignard wrote:
> 2017-11-28 14:20 GMT+01:00 Greg KH :
> > On Mon, Nov 06, 2017 at 04:59:44PM +0100, Benjamin Gaignard wrote:
> >> Put include in alphabetic order
> >
> > Why???
>
> Mainly because the next patch in the series adds new includes and
Hi Daniel,
On 2017-11-20 08:33, Daniel Vetter wrote:
On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
On 26 October 2017 at 11:37, Inki Dae wrote:
Improving Exynos DRM HDMI and Mixer drivers and also adding
HDMI audio support.
在 2017-11-28 04:57，Jernej Skrabec 写道：
Base addresses of channel output CSC (CCSC) depends whether mixer in
question is first or second and if it is second, if supports VEP or
not.
This new property will tell which set of base addresses to take.
0 - first mixer or second mixer with VEP support
在 2017-11-28 17:02，Maxime Ripard 写道：
Hi,
On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard
napisal(a):
> Add support for the A83T display pipeline.
>
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Maxime Ripard
>
On Tue, Nov 28, 2017 at 12:04:04AM -0800, Joe Perches wrote:
> On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote:
> > > > It seems that I got no responses so far for clarification requests
> > > > according to the documentation in a direction I hoped for.
> > >
> > > That's because you ar
On Tue, Nov 28, 2017 at 09:51:13AM +0100, Michal Wajdeczko wrote:
> On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
> wrote:
>
> > Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
> > The file has been renamed.
> >
> > Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename int
On Tue, Nov 28, 2017 at 11:15:37AM +0100, SF Markus Elfring wrote:
> >>> Many people do not know that a generic kmalloc does a
> >>> dump_stack() on OOM.
> >>
> >> This is another interesting information, isn't it?
> >>
> >> It is expected that the function “devm_kzalloc” has got a similar property
Hi Rob,
thanks for your feedback, the changes will be included in V2 of the
patch-series.
Jan
> Von: Rob Herring
> Gesendet: Sonntag, 26. November 2017 20:24
> On Thu, Nov 23, 2017 at 01:55:54PM +0100, Jan Tuerk wrote:
> > This patch adds support for the emtrion GmbH emCON-MX6 modules.
> > They
On Tue, Nov 28, 2017 at 11:50:14AM +0100, SF Markus Elfring wrote:
> >> How will this aspect evolve further?
> >
> > I do not follow.
>
> Interesting …
>
> > This is OMAP framebuffer driver, so in this case, there is zero variation.
>
> How much are you interested to compare differences in buil
Hi,
On 28-11-17 11:28, Daniel Vetter wrote:
On Sat, Nov 25, 2017 at 08:27:31PM +0100, Hans de Goede wrote:
This fixes the following make kerneldocs messages:
./include/drm/drm_mode_config.h:772: warning: No description found for
parameter 'modifiers_property'
./include/drm/drm_mode_config.h:7
Hello Thomas Hellstrom,
The patch d80efd5cb3de: "drm/vmwgfx: Initial DX support" from Aug 10,
2015, leads to the following static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_so.c:335 vmw_view_add()
error: buffer overflow 'vmw_view_define_sizes' 3 <= 3
drivers/gpu/drm/vmwgfx/vm
Reviewed-by: Andrey Grodzovsky
Thanks,
Andrey
On 11/27/2017 09:57 AM, Gustavo A. R. Silva wrote:
dm_new_crtc_state->stream and disconnected_acrtc are being dereferenced
before they are null checked, hence there is a potential null pointer
dereference.
Fix this by null checking such pointers
1 - 100 of 188 matches
Mail list logo
