https://bugs.freedesktop.org/show_bug.cgi?id=103100
--- Comment #1 from Nicolai Hähnle ---
Thanks for the report. The bisection result makes perfect sense, as the version
bump can change how Mesa behaves. Could you please provide the version of Mesa
you're using? (The output of glxinfo contains t
Hi Tomi,
On 08/22/2017 11:44 AM, Tomi Valkeinen wrote:
> Hi Hans,
>
>>>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> On 11/08/17 13:57, Tomi Valkeinen wrote:
>>>
I'm doing some testing with this serie
Wei Yongjun writes:
> In case of error, the function of_graph_get_remote_node() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test..
Looks good.
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
Hi Dave,
Here goes
drm-intel-fixes-2017-10-11:
Three fixes for stable:
- Use crtc_state_is_legacy_gamma in intel_color_check (Maarten)
- Read timings from the correct transcoder (Ville).
- Fix HDMI on BSW (Jani).
Other fixes:
- eDP fixes (Manasi)
- Silence compiler warnings (Chris)
- Order two
Add devm_backlight_get and the corresponding release
function because some drivers use devres versions of functions
for requiring device resources.
Signed-off-by: Meghana Madhyastha
---
Changes in v9:
-Change function name from devm_backlight_get_release to
devm_backlight_put because it is more
Rename tinydrm_of_find_backlight to backlight_get and move it
to linux/backlight.c so that it can be used by other drivers.
Signed-off-by: Meghana Madhyastha
---
Changes in v9:
-None
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 --
drivers/gpu/drm/tinydrm/mi0283qt
Move the helper functions enable_backlight and disable_backlight
from tinydrm-helpers.c to backlight.h as static inline functions so
that they can be used by other drivers.
Signed-off-by: Meghana Madhyastha
---
Changes in v9:
-None
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 55 ---
Move drm helper functions from tinydrm-helpers to linux/backlight for
ease of use by callers in other drivers.
Changes in v9:
-Change function name from devm_backlight_get_release to
devm_backlight_put because it is more apt name.
Meghana Madhyastha (3):
drm/tinydrm: Move helper functions from
Op 11-10-17 om 22:40 schreef Harry Wentland:
> On 2017-10-11 03:46 PM, Maarten Lankhorst wrote:
>> Op 11-10-17 om 20:55 schreef Leo:
>>>
>>> On 2017-10-11 10:30 AM, Maarten Lankhorst wrote:
Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
> From: "Leo (Sunpeng) Li"
>
> Use the cor
Nickey Yang writes:
> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater
Sean Paul writes:
> Would it be easier for you to respin this into your series, or for me
> to just apply it to drm-misc-next?
Yeah, I don't see any particular hurry to getting just the time widening
patch merged as it doesn't change any external interfaces. I'll go ahead
and respin my series us
On 2017-10-11 03:46 PM, Maarten Lankhorst wrote:
> Op 11-10-17 om 20:55 schreef Leo:
>>
>>
>> On 2017-10-11 10:30 AM, Maarten Lankhorst wrote:
>>> Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
From: "Leo (Sunpeng) Li"
Use the correct for_each_new/old_* iterators instead of for_ea
On Wed, Oct 11, 2017 at 4:18 PM, Keith Packard wrote:
> Sean Paul writes:
>
>> It looks like perhaps Keith missed one of the comment tweaks that you have
>> below.
>>
>> Keith, perhaps you can rebase your widening patch on this one?
>
> I'm easy; either order works for me just fine. Having the ti
Sean Paul writes:
> It looks like perhaps Keith missed one of the comment tweaks that you have
> below.
>
> Keith, perhaps you can rebase your widening patch on this one?
I'm easy; either order works for me just fine. Having the time
change separated from the sequence change might be nice?
--
Arnd Bergmann writes:
> That is an interesting coincidence, I created my patch earlier this week
> without having any idea that others were looking at the same files.
My requirements were to support 64-bit vblank counts and ns precision
vblank timing for Vulkan; obviously using ktime_t was a goo
https://bugs.freedesktop.org/show_bug.cgi?id=103102
--- Comment #9 from Hadrien ---
(In reply to Michel Dänzer from comment #7)
> Is there any chance you can bisect between 4.12.5 and 4.12.6?
I think this is the next step to diagnose that problem. I've never built and
installed my own kernel bef
Hi Dave,
Here's the latest from -misc-fixes. We have fixes for a reference leak, and a
race.
Following Jani's lead, I've setup dim to sign my pull requests. You can find my
public key at https://pgp.key-server.io/0x732C002572DCAF79
drm-misc-fixes-2017-10-11:
Core Changes:
- sync_file: Fix race i
Op 11-10-17 om 20:55 schreef Leo:
>
>
> On 2017-10-11 10:30 AM, Maarten Lankhorst wrote:
>> Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
>>> From: "Leo (Sunpeng) Li"
>>>
>>> Use the correct for_each_new/old_* iterators instead of for_each_*
>>>
>>> List of affected functions:
>>>
>>> amdgpu_dm
On 2017-10-11 10:30 AM, Maarten Lankhorst wrote:
Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
From: "Leo (Sunpeng) Li"
Use the correct for_each_new/old_* iterators instead of for_each_*
List of affected functions:
amdgpu_dm_find_first_crtc_matching_connector: use for_each_new
- Ol
On Mon, 09 Oct 2017, Daniel Stone wrote:
> Hey,
>
> On 9 October 2017 at 11:30, Jani Nikula wrote:
>> On Tue, 03 Oct 2017, Jani Nikula wrote:
>>> I merged this last week with Daniel's IRC ack. We'll need to give people
>>> a little bit of time before updating nightly.conf. Sorry for the
>>> inco
On Wed, Oct 11, 2017 at 7:36 PM, Sean Paul wrote:
> On Wed, Oct 11, 2017 at 05:20:12PM +0200, Arnd Bergmann wrote:
>
> Hi Arnd,
> Keith posted something very similar with:
> <20171011004514.9500-2-kei...@keithp.com> "drm: Widen vblank UAPI to 64 bits.
> Change vblank time to ktime_t"
>
> It looks
On Tue, Oct 10, 2017 at 05:45:13PM -0700, Keith Packard wrote:
> Place drm_event_vblank in a new union that includes that and a bare
> drm_event structure. This will allow new members of that union to be
> added in the future without changing code related to the existing vbl
> event type.
>
> Assi
On Tue, Oct 10, 2017 at 05:45:14PM -0700, Keith Packard wrote:
> These provide crtc-id based functions instead of pipe-number, while
> also offering higher resolution time (ns) and wider frame count (64)
> as required by the Vulkan API.
>
> v2:
>
> * Check for DRIVER_MODESET in new crtc-based vb
Hi Dave, more v4.15 features.
Our tooling now supports signed tags, this one is probably the
first. Maybe we can make them mandatory in the long run.
drm-intel-next-2017-09-29:
2nd batch of v4.15 features:
- lib/scatterlist updates, use for userptr allocations (Tvrtko)
- Fixed point wrapper cle
On Wed, Oct 11, 2017 at 08:51:06AM +, Mark Brown wrote:
> On Tue, Oct 10, 2017 at 08:03:00AM +0100, Mark Brown wrote:
> > Hi all,
> >
> > After merging the drm-misc-fixes tree, today's linux-next build
> > (x86_allmodconfig) failed like this:
> >
> > CC [M] drivers/gpu/drm/i915/i915_gem_ev
On Wed, Oct 11, 2017 at 05:20:12PM +0200, Arnd Bergmann wrote:
> The drm vblank handling uses 'timeval' to store timestamps in either
> monotonic or wall-clock time base. In either case, it reads the current
> time as a ktime_t in get_drm_timestamp() and converts it from there.
>
> This is a bit s
On Wed, Oct 11, 2017 at 11:17:16AM +, Wei Yongjun wrote:
> In case of error, the function of_graph_get_remote_node() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test..
>
> Signed-off-by: Wei Yongjun
Reviewed-by: Sean Paul
https://bugs.freedesktop.org/show_bug.cgi?id=103102
--- Comment #8 from Alex Deucher ---
Does the patch on this bug help?
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--
You are receiving this mail because:
You are the assignee for the bug.___
d
https://bugs.freedesktop.org/show_bug.cgi?id=103102
--- Comment #7 from Michel Dänzer ---
Is there any chance you can bisect between 4.12.5 and 4.12.6?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Maarten Lankhorst
> Sent: Wednesday, October 11, 2017 10:30 AM
> To: Li, Sun peng (Leo); airl...@gmail.com; amd-...@lists.freedesktop.org
> Cc: Wentland, Harry; dri-devel@lists.freedesktop.org
On Wed, Oct 11, 2017 at 6:41 AM, Christian König
wrote:
> Am 11.10.2017 um 11:21 schrieb Colin King:
>>
>> From: Colin Ian King
>>
>> The function uvd_v6_0_enc_get_destroy_msg is local to the source and
>> does not need to be in global scope, so make it static.
>>
>> Cleans up sparse warning:
>>
On Mon, 09 Oct 2017, Thierry Reding wrote:
> On Mon, Oct 09, 2017 at 12:29:57PM +0300, Jani Nikula wrote:
>> Falling back to the lowest value is likely the only thing we can do, but
>> doing it silently seems like a bad thing to do. Catch it early and make
>> loud noises.
>>
>> Cc: Alex Deucher
From: "Leo (Sunpeng) Li"
Use the correct for_each_new/old_* iterators instead of for_each_*
List of affected functions:
amdgpu_dm_find_first_crtc_matching_connector: use for_each_new
- Old from_state_var flag was always choosing the new state
amdgpu_dm_display_resume: use for_each_new
On Wed, 11 Oct 2017, Alex Ivanov wrote:
> On 11.10.2017 12:04, Daniel Vetter wrote:
>>
>> Why exactly is the existing dpms ioctl not good enough? it's implemented
>> as the "DPMS" property attached to connectors, but that's the only
>> difference compared to your code here.
>>
>> Also, that one do
On 11 October 2017 at 16:20, Arnd Bergmann wrote:
> There is a risk of overflowing vblank timestamps in 2038 or 2106 if
> someone sets the drm_timestamp_monotonic module parameter to zero.
>
> I found no indication of anyone ever setting the parameter, or
> complaining about the default being wron
There is a risk of overflowing vblank timestamps in 2038 or 2106 if
someone sets the drm_timestamp_monotonic module parameter to zero.
I found no indication of anyone ever setting the parameter, or
complaining about the default being wrong, after it was introduced
as a way to handle backwards-comp
The drm vblank handling uses 'timeval' to store timestamps in either
monotonic or wall-clock time base. In either case, it reads the current
time as a ktime_t in get_drm_timestamp() and converts it from there.
This is a bit suspicious, as users of 'timeval' often suffer from
the time_t overflow in
On Wed, 11 Oct 2017, Meghana Madhyastha wrote:
> On Wed, Oct 11, 2017 at 04:56:25PM +0300, Jani Nikula wrote:
>> On Wed, 11 Oct 2017, Meghana Madhyastha wrote:
>> > Add devm_backlight_get and the corresponding release
>> > function because some drivers use devres versions of functions
>> > for re
On Wed, Oct 11, 2017 at 4:18 PM, Ilia Mirkin wrote:
> On Wed, Oct 11, 2017 at 9:46 AM, Bjorn Helgaas wrote:
>> On Wed, Oct 11, 2017 at 08:54:05AM -0400, Ilia Mirkin wrote:
>>> On Wed, Oct 11, 2017 at 7:47 AM, Bjorn Helgaas wrote:
>>> > /* do magic */
>>> > nvif_mask(&device->object, 0x088488
Op 11-10-17 om 16:24 schreef sunpeng...@amd.com:
> From: "Leo (Sunpeng) Li"
>
> Use the correct for_each_new/old_* iterators instead of for_each_*
>
> List of affected functions:
>
> amdgpu_dm_find_first_crtc_matching_connector: use for_each_new
> - Old from_state_var flag was always choosing
On Wed, Oct 11, 2017 at 04:56:25PM +0300, Jani Nikula wrote:
> On Wed, 11 Oct 2017, Meghana Madhyastha wrote:
> > Add devm_backlight_get and the corresponding release
> > function because some drivers use devres versions of functions
> > for requiring device resources.
> >
> > Signed-off-by: Megha
On Wed, Oct 11, 2017 at 9:46 AM, Bjorn Helgaas wrote:
> On Wed, Oct 11, 2017 at 08:54:05AM -0400, Ilia Mirkin wrote:
>> On Wed, Oct 11, 2017 at 7:47 AM, Bjorn Helgaas wrote:
>> > /* do magic */
>> > nvif_mask(&device->object, 0x088488, (1 << 25), (1 << 25));
>> >
>> > Wow, that *is* inscrutab
On Wed, 11 Oct 2017, Meghana Madhyastha wrote:
> Add devm_backlight_get and the corresponding release
> function because some drivers use devres versions of functions
> for requiring device resources.
>
> Signed-off-by: Meghana Madhyastha
> ---
> Changes in v8:
> -Put the devres version to backli
On Wed, Oct 11, 2017 at 12:56:33PM +0100, Daniel Stone wrote:
> Hi Alex,
>
> On 11 October 2017 at 12:22, Alex Ivanov wrote:
> > On 11.10.2017 13:13, Daniel Stone wrote:
> >> If people are doing fancy new compositors without DPMS support, then I
> >> recommend they use an existing compositor base
On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote:
> I assume it's easy to produce an actual failure here? Why haven't we
> seen bug reports about this?
The bug was detected with static analysis. You have to enable a debug
feature in the .config if you want sleeping with spinlock hel
https://bugs.freedesktop.org/show_bug.cgi?id=103187
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Marta Löfst
https://bugs.freedesktop.org/show_bug.cgi?id=103188
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Marta Löfst
The delays between video data and backlight enable and between backlight
disable and end of video data are given as >= 160 ms in the datasheet.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/panel/pane
The vsync length should be 10 lines, as specified in the data sheet.
This gets the actual refresh rate closer to nominal 60 Hz given the
9 MHz pixel clock.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
For LCD interface controllers that support configuring polarity of
pixel clock and data enable signal, specify bus flags in the panel
descriptor.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-
On Wed, Oct 11, 2017 at 7:47 AM, Bjorn Helgaas wrote:
> On Mon, Oct 09, 2017 at 10:41:38AM -0400, Ilia Mirkin wrote:
>> Hello,
>>
>> As a bit of background, all NVIDIA GPUs since GT215 have an audio
>> subfunction for HDMI(/DP) audio to be sent to the sink. This generally
>> works.
>>
>> However s
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36e0e803d3d7fb3d74e9086ad7c749123661589e
commit: 939d749ad6649c4123daf63a8bc053ea97ad2218 [899/925] drm/sun4i: hdmi: Add
support for controller hardware variants
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueab
On Tue, 15 Aug 2017 16:47:20 -0700
Eric Anholt wrote:
> We need the following things to happen in sequence:
>
> DSI host creation
> DSI device creation in the panel driver (needs DSI host)
> DSI device attach from panel to host.
> DSI drm_panel_add()
> DSI encoder creation
> DSI encoder's DRM pa
On Tue, 15 Aug 2017 16:47:19 -0700
Eric Anholt wrote:
> The incoming mode might have a missing vrefresh field if it came from
> drmModeSetCrtc(), which the kernel is supposed to calculate using
> drm_mode_vrefresh(). We could either use that or the adjusted_mode's
> original vrefresh value.
>
>
Hi Alex,
On 11 October 2017 at 12:22, Alex Ivanov wrote:
> On 11.10.2017 13:13, Daniel Stone wrote:
>> If people are doing fancy new compositors without DPMS support, then I
>> recommend they use an existing compositor base, such as libweston
>> (others are also available) which actually implemen
On Tue, 15 Aug 2017 16:47:18 -0700
Eric Anholt wrote:
> We want the adjusted_mode->clock to be the actual clock we're
> expecting to program, so that consumers see the right values for clock
> and vrefresh.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/
On Thu, 17 Aug 2017 14:04:55 -0700
Eric Anholt wrote:
> VC4's DSI1 has a bug where the AXI connection is broken for 32-bit
> writes from the CPU, so we use the DMA engine to DMA 32-bit values
> into registers instead. That sleeps, so we can't do it from the top
> half.
>
> As a solution (sugges
On Tue, Oct 10, 2017 at 10:16:30PM -0600, Haneen Mohammed wrote:
> Remove old comment style used by doxygen.
> And remove comment left from commit 99cdb35e787b ("drm/doc: move printf
> helpers out of drmP.h") after refactoring drmP.h.
>
> Signed-off-by: Haneen Mohammed
> ---
> include/drm/drm_de
On Tue, Oct 10, 2017 at 10:13:36PM -0600, Haneen Mohammed wrote:
> Extract DRM_* debug macros from drmP.h to drm_debug.h and move printting
> related functions from drm_drv.[hc] to drm_debug.[hc].
>
> Update kerneldoc include directives accordingly.
>
> Signed-off-by: Haneen Mohammed
> ---
> Do
On Wed, 27 Sep 2017 12:32:09 -0700
Eric Anholt wrote:
> The documentation said to use src_w here, and I didn't consider that
> we actually needed to be using pitch somewhere in our setup. Fixes
> scanout on my DSI panel when X11 does initial setup with 1920x1080
> HDMI and 800x480 DSI both at 0,
On Wed, Oct 04, 2017 at 11:47:32AM +0100, Mark Brown wrote:
> On Fri, Sep 29, 2017 at 04:23:01PM +0800, Chen-Yu Tsai wrote:
> > This patch adds a macro regmap_field_read_poll_timeout that works
> > similar to the readx_poll_timeout defined in linux/iopoll.h, except
> > that this can also return the
On 11.10.2017 13:13, Daniel Stone wrote:
I'm sorry, but this is not the right way to go about things. If Xorg
or GNOME Shell or Weston or whatever thinks the monitor is DPMS-off,
the fact that someone else has forcibly switched it back on will not
make them continue painting.
User should disab
On 09.10.2017 10:44, Sean Young wrote:
> Hi,
>
> On Thu, Sep 21, 2017 at 12:46:04PM +0100, Sean Young wrote:
>> On Mon, Sep 18, 2017 at 04:37:52PM +0200, Hans Verkuil wrote:
>>> On 09/18/2017 04:15 PM, Maciej Purski wrote:
Hi Hans,
some time ago in reply to your email I described what mes
On 11.10.2017 12:04, Daniel Vetter wrote:
Why exactly is the existing dpms ioctl not good enough? it's implemented
as the "DPMS" property attached to connectors, but that's the only
difference compared to your code here.
Also, that one doesn't have any XXX about atomic like yours.
I also hav
On Tue, Oct 10, 2017 at 2:42 PM, Aishwarya Pant wrote:
> pipe is an unsigned int and less than zero comparison for unsigned
> values is always false.
>
> Detected using the following cocci script:
>
> @@
> unsigned int i;
> @@
> * i < 0
>
Thanks
Reviewed-by: Rob Clark
> Signed-off-by: Aishwary
Am 11.10.2017 um 11:21 schrieb Colin King:
From: Colin Ian King
The function uvd_v6_0_enc_get_destroy_msg is local to the source and
does not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'uvd_v6_0_enc_get_destroy_msg' was not declared. Should it be
static?
S
Add devm_backlight_get and the corresponding release
function because some drivers use devres versions of functions
for requiring device resources.
Signed-off-by: Meghana Madhyastha
---
Changes in v8:
-Put the devres version to backlight.c along with backlight_get.
drivers/gpu/drm/tinydrm/mi028
On 10/11/2017 02:56 PM, Boris Brezillon wrote:
Hi Archit,
On Thu, 7 Sep 2017 15:06:13 +0530
Archit Taneja wrote:
+
+static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
+{
+ struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
+ struct cdns_dsi *dsi = inp
Rename tinydrm_of_find_backlight to backlight_get and move it
to linux/backlight.c so that it can be used by other drivers.
Signed-off-by: Meghana Madhyastha
---
Changes in v8:
-Changed the name of the tinydrm_of_find_backlight to backlight_get and moved
it to
backlight.c
drivers/gpu/drm/tiny
Hi,
On 11 October 2017 at 08:46, Alex Ivanov wrote:
> Display power management should be available to user no matter whether
> display server implements it or not and should be made server agnostic
> (X.Org, Wayland compositor), without need of TTY change.
>
> Reasons:
> 1. User implements an own
On Tue, Oct 10, 2017 at 10:13:36PM -0600, Haneen Mohammed wrote:
> -/**
> - * Debug output.
> - *
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_DEV_DEBUG(dev, fmt, args...) \
> - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_
Move the helper functions enable_backlight and disable_backlight
from tinydrm-helpers.c to backlight.h as static inline functions so
that they can be used by other drivers.
Signed-off-by: Meghana Madhyastha
---
Changes in v8:
-This patch was not present in the earlier versions.
drivers/gpu/drm/
Move drm helper functions from tinydrm-helpers to linux/backlight for
ease of use by callers in other drivers.
Changes in v8:
-Move backlight_enable and backlight_disable to linux/backlight.h
as static inline functions.
-Move drm_of_find_backlight to backlight.c and rename it to
backlight_get.
From: Lucas Stach
The PRE has a bug where a software write to the CTRL register can block
the setting of the ENABLE bit by the hardware in auto repeat mode. When
this happens the PRE will fail to handle new jobs. To work around this
software must not write to CTRL register when the PRE store engi
From: Lucas Stach
Wait for both double buffer to be filled when first starting a channel.
This makes channel startup a lot more reliable, probably because it allows
the internal state machine to settle before the requests from the IPU are
coming in.
Signed-off-by: Lucas Stach
[p.za...@pengutron
https://bugs.freedesktop.org/show_bug.cgi?id=103175
--- Comment #6 from Andy Furniss ---
I tried latest 4.15-wip and it's still low perf.
On this test the perf was OK ish initially but degraded over the first 20
seconds.
For added hassle it seems that between 4.13 and 4.14-rc1 something changed
Dear Hoegeun,
On 2017-10-11 07:49, Hoegeun Kwon wrote:
Hi Marek,
Currently, IPP v2 and gsc do not seem to have any code to
check for hardware limits. How can I check the hardware limits
of device(gsc, rotator, ...) at IPP v2?
From userspace one can issue DRM_IOCTL_EXYNOS_IPP_GET_LIMITS ioctl
https://bugs.freedesktop.org/show_bug.cgi?id=103188
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=103168
Martin Peres changed:
What|Removed |Added
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@li
https://bugs.freedesktop.org/show_bug.cgi?id=103187
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=103168
Martin Peres changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede
https://bugs.freedesktop.org/show_bug.cgi?id=103107
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=103094
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=102616
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=102417
Martin Peres changed:
What|Removed |Added
i915 platform|APL |BXT
--
You are receiving this mail beca
Hi,
While reading the mgag200 driver I noticed something that looks wrong.
In mgag200_main.c mga_probe_vram function:
orig1 = ioread8(mem + offset);
orig2 = ioread8(mem + offset + 0x100);
...
iowrite16(orig1, mem + offset);
iowrite16(orig2, mem + offset + 0x100);
I do not
Hi Archit,
On Thu, 7 Sep 2017 15:06:13 +0530
Archit Taneja wrote:
>
> > +
> > +static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
> > +{
> > + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> > + struct cdns_dsi *dsi = input_to_dsi(input);
> > + u32 val;
> >
From: Colin Ian King
The function uvd_v6_0_enc_get_destroy_msg is local to the source and
does not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'uvd_v6_0_enc_get_destroy_msg' was not declared. Should it be
static?
Signed-off-by: Colin Ian King
---
drivers/gp
On 11/10/17 02:45 AM, Keith Packard wrote:
> These provide crtc-id based functions instead of pipe-number, while
> also offering higher resolution time (ns) and wider frame count (64)
> as required by the Vulkan API.
>
> v2:
>
> * Check for DRIVER_MODESET in new crtc-based vblank ioctls
>
>
On Wed, Oct 11, 2017 at 10:46:44AM +0300, Alex Ivanov wrote:
> Display power management should be available to user no matter whether
> display server implements it or not and should be made server agnostic
> (X.Org, Wayland compositor), without need of TTY change.
>
> Reasons:
> 1. User implement
On Tue, Oct 10, 2017 at 08:03:00AM +0100, Mark Brown wrote:
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build
> (x86_allmodconfig) failed like this:
>
> CC [M] drivers/gpu/drm/i915/i915_gem_evict.o
> drivers/gpu/drm/i915/i915_gem_evict.c: In function ‘i915_gem_evict
On Wed, Oct 11, 2017 at 4:00 PM, Maxime Ripard
wrote:
> On Tue, Oct 10, 2017 at 03:19:57AM +, Chen-Yu Tsai wrote:
>> Hi everyone,
>>
>> This is v4 of my A31 HDMI support series. The DTS patches depend on
>> the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged.
>> The DRM patches d
On Tue, Oct 10, 2017 at 03:19:57AM +, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v4 of my A31 HDMI support series. The DTS patches depend on
> the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged.
> The DRM patches depend on "regmap: add iopoll-like polling macro for
> regmap_
Display power management should be available to user no matter whether
display server implements it or not and should be made server agnostic
(X.Org, Wayland compositor), without need of TTY change.
Reasons:
1. User implements an own universal power management daemon. He has no
interest to deal wi
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #56 from erhar...@mailbox.org ---
Further on this bug only manifests on the ATI/AMD side. NVIDIA cards do not
seem to have a problem with this new PCIe feature activated in commit
60db3a4d8cc9073cf56264785197ba75ee1caca4.
On the same
https://bugs.freedesktop.org/show_bug.cgi?id=103187
Chris Wilson changed:
What|Removed |Added
Component|DRM/Intel |IGT
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=103188
Chris Wilson changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
2017-10-10 21:18 GMT+09:00 Matthew Wilcox :
> On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
>> Reducing the header dependency will help for speeding the kernel
>> build, suppressing unnecessary recompile of objects during
>> git-bisect'ing, etc.
>
> Well, does it? You could prov
This patchset move debug macros from drmP.h into drm_debug.h and move
printting related functions from drm_drv.[hc] to drm_debug.[hc].
In addition, it fixes old comment style.
Haneen Mohammed (2):
drm: Extract drm_debug.[hc]
drm: Update old comment style
Documentation/gpu/drm-uapi.rst | 9
On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
> Reducing the header dependency will help for speeding the kernel
> build, suppressing unnecessary recompile of objects during
> git-bisect'ing, etc.
Well, does it? You could provide measurements showing before/after
time to compil
1 - 100 of 111 matches
Mail list logo
