https://bugs.freedesktop.org/show_bug.cgi?id=101787
Bug ID: 101787
Summary: colours all messed up
Product: Mesa
Version: 17.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
https://bugs.freedesktop.org/show_bug.cgi?id=101787
Michel Dänzer changed:
What|Removed |Added
Component|Drivers/DRI/R100|Drivers/Gallium/r600
--
You are receiv
On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
> So, if you think this is wrong, can you fix this warning in a way that
> you'd like?
As I replied previously [1], with more background, fixing the warnings
properly, in a way that actually improves the code instead of making it
worse, would mean a
On 13.07.2017 16:13, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic. Add a
> driver for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/panel/Kconfig | 9 +-
> drivers/gpu/drm/panel/Makefile | 1 +-
> dr
This series should shut up all warnings introduced by gcc-6 or gcc-7 on
today's linux-next, as observed in "allmodconfig" builds on x86,
arm and arm64.
I have sent some of these before, but some others are new, as I had
at some point disabled the -Wint-in-bool-context warning in my
randconfig test
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ata/libata-core.c: In function 'ata_timing_quantize':
drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest
'&&' instead [-Wint-in-bool-context]
This slightly rearranges the macro to simpli
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ide/ide-timings.c: In function 'ide_timing_quantize':
drivers/ide/ide-timings.c:112:24: error: '*' in boolean context, suggest '&&'
instead [-Werror=int-in-bool-context]
q->setup = EZ(t->setup * 1000, T);
gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
operand in ?: will always be 'true', suggest explicit middle operand
[-Werror=parenthes
In some configurations, topology_physical_package_id() is trivially
defined as '-1' for any input, resulting a comparison that is
always true:
drivers/acpi/processor_thermal.c: In function ‘cpufreq_set_cur_state’:
drivers/acpi/processor_thermal.c:137:36: error: self-comparison always
evaluates to
We test whether a bit is set in a mask here, which is correct
but gcc warns about it as it thinks it might be confusing:
drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in
boolean context, the expression will always evaluate to 'true'
[-Werror=int-in-bool-context]
Thi
The setsign() macro gets called with an integer argument in a
few places, leading to a harmless warning in gcc-7:
arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in
boolean context [-Werror=int-in-bool-context]
This
FIFO_MODE is an macro expression with a '<<' operator, which
gcc points out could be misread as a '<':
drivers/input/misc/adxl34x.c: In function 'adxl34x_probe':
drivers/input/misc/adxl34x.c:799:36: error: '<<' in boolean context, did you
mean '<' ? [-Werror=int-in-bool-context]
This converts th
gcc warns when MODULES_VADDR/END is defined to the same value as
VMALLOC_START/VMALLOC_END, e.g. on x86-32:
fs/proc/kcore.c: In function ‘add_modules_range’:
fs/proc/kcore.c:622:161: error: self-comparison always evaluates to false
[-Werror=tautological-compare]
if (/*MODULES_VADDR != VMALLOC_S
With ccache in combination with gcc-6, we get a harmless warning for the sfi
subsystem,
as ccache only sees the preprocessed source:
drivers/sfi/sfi_core.c: In function ‘sfi_map_table’:
drivers/sfi/sfi_core.c:175:53: error: self-comparison always evaluates to true
[-Werror=tautological-compare]
gcc-7 points out an older regression:
drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context,
did you mean '<' ? [-Werror=int-in-bool-context]
The original code had 'unsigned short' here, but incorr
When using ccache, we get a harmless warning about the fact that
we use the result of a multiplication as a condition:
drivers/infiniband/core/uverbs_main.c: In function 'ib_uverbs_write':
drivers/infiniband/core/uverbs_main.c:787:40: error: '*' in boolean context,
suggest '&&' instead [-Werror=i
gcc thinks that interpreting a multiplication result as a bool
is confusing:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean
context, suggest '&&' instead [-Werror=int-in-bool-context]
In this i
When we pass the result of a multiplication as the timeout, we
can get a warning:
drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest '&&'
instead [-Werror=int-in-bool-context]
drivers/mfd/arizona-core.c:247:195: error: '*' in boolean context, suggest '&&'
instead [-Werror
v4l2_subdev_call is a macro returning whatever the callback return
type is, usually 'int'. With gcc-7 and ccache, this can lead to
many wanings like:
media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate':
media/platform/pxa_camera.c:766:27: error: ?: using integer constants in
bool
/linux/commits/Maxime-Ripard/drm-sun4i-Allwinner-MIPI-DSI-support/20170714-123103
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin
On Thu, 13 Jul 2017, Sean Paul wrote:
> On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote:
>> The problem is that we have a distributed cache - every committer has
>> a copy. Which means even just a slight clock skew will make sure that
>> a naive gc algorithm results in lots of thrash
On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
> When we pass the result of a multiplication as the timeout, we
> can get a warning:
>
> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
> '&&' instead [-Werror=int-in-bool-context]
> drivers/mfd/arizona-core.c:24
On Fri, 14 Jul 2017, Arnd Bergmann wrote:
> gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle
> operand in ?: will always be 'true',
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
Allows gdb to access contents of user mode mapped BOs. VRAM access
requires the driver to implement a new callback in ttm_bo_driver.
One more comment additionally to what Michel already wrote below, apart
from that it looks good to me.
Signed-
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
Allows gdb to access contents of user mode mapped VRAM BOs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2 ++
2 files changed, 61 i
On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
> We test whether a bit is set in a mask here, which is correct
> but gcc warns about it as it thinks it might be confusing:
>
> drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in
> boolean context, the expression
/linux/commits/Maxime-Ripard/drm-sun4i-Allwinner-MIPI-DSI-support/20170714-123103
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin
On Fri, Jul 14, 2017 at 11:55 AM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote:
>> When we pass the result of a multiplication as the timeout, we
>> can get a warning:
>>
>> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest
>> '&&' instead [
On Fri, Jul 14, 2017 at 11:25:12AM +0200, Arnd Bergmann wrote:
> This series should shut up all warnings introduced by gcc-6 or gcc-7 on
> today's linux-next, as observed in "allmodconfig" builds on x86,
> arm and arm64.
>
> I have sent some of these before, but some others are new, as I had
> at
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:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which c
On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote:
> On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote:
>> We test whether a bit is set in a mask here, which is correct
>> but gcc warns about it as it thinks it might be confusing:
>>
>> drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: usi
On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C wrote:
On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
On Thu,
On Fri, Jul 14, 2017 at 12:52 AM, Rajendra Nayak wrote:
> Hi Rob,
>
> On 07/11/2017 11:50 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to add a flag for clks and p
On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
>> Dear All,
>>
>> I am looking for an solution to have early smooth splashscreen on the
>> Linux system with Weston and drm-backend.
>>
>> I tried showing splashscreen using Linux logo and
Adding drm_add_modes_noedid_cea API for supporting cea modes
for drm devices which does not have panel framework or edid
support.
Protocols like SDI whic have minimal support in linux kernel can
benifit from this.
There is already a API drm_add_modes_noedid, but that supports only
dmt modes.
Sign
On 14/07/17 00:31, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Thursday 13 Jul 2017 18:49:19 Kieran Bingham wrote:
>> On 26/06/17 19:12, Laurent Pinchart wrote:
>>> New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
>>> as well as a new VSP2-D variant on V3M and V3H SoCs. Add
Hi,
On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
wrote:
> In the earlier display engine designs, any register access while a commit
> is pending is forbidden.
>
> One of the symptoms is that reading a register will return another, random,
> register value which can lead to register corruptions
On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
wrote:
> Huarui Lighting makes display panel, add it to the list of panels.
I could not find any information on "Huarui Lighting" within the
context of LCD panels. The company I found makes LED lighting
fixtures, floodlights, and high power LED driv
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
CP States defined:
DRM_CP_UNSUPPORTED - CP is not supported
DRM_CP_DISABLE - CP is disabled
DRM_CP_ENABLE - CP is enabled
V2: Red
https://bugs.freedesktop.org/show_bug.cgi?id=101528
--- Comment #5 from Sverd Johnsen ---
Works for me on 4.11.10. Display off, MCLK is low and card temperature is 27°C
as expected. Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101528
Sverd Johnsen changed:
What|Removed |Added
Resolution|--- |FIXED
Summary|RX460 Memory c
Changing:
- if (!frob()) {
+ if (frob() == 0) {
is a totally pointless change. They're both bad, because they're doing
success testing instead of failure testing, but probably the second one
is slightly worse.
This warning seems dumb. I can't imagine it has even a 10% success rate
at finding r
On Fri, Jul 14, 2017 at 2:05 PM, Dan Carpenter wrote:
> Changing:
>
> - if (!frob()) {
> + if (frob() == 0) {
>
> is a totally pointless change. They're both bad, because they're doing
> success testing instead of failure testing, but probably the second one
> is slightly worse.
>
> This warning
On Fri, Jul 14, 2017 at 11:36:56AM +0200, Arnd Bergmann wrote:
> @@ -1158,7 +1158,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
>*/
> fmt_src.pad = pad->index;
> fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> - if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL,
Ah... I see why it's complaining about these ones in particular...
I don't agree with it as a static analysis dev, and I don't like the
changes too much. But since it's only generating a hand full of
warnings then I don't care.
regards,
dan carpenter
___
On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
> I don't agree with it as a static analysis dev...
What I mean is if it's a macro that returns -ENODEV or a function that
returns -ENODEV, they should both be treated the same. The other
warnings this check prints are quite clever.
On Thu, Jul 06, 2017 at 03:05:19PM +0200, Maarten Lankhorst wrote:
> Op 06-07-17 om 15:00 schreef Daniel Vetter:
> > With deferred fbdev setup we always need to forward hotplug events,
> > even if fbdev isn't fully set up yet. Otherwise the deferred setup
> > will neer happen.
> >
> > Originally th
On Fri, Jul 14, 2017 at 12:57:23PM +0300, Jani Nikula wrote:
> On Thu, 13 Jul 2017, Sean Paul wrote:
> > On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote:
> >> The problem is that we have a distributed cache - every committer has
> >> a copy. Which means even just a slight clock skew
On Thu, Jul 13, 2017 at 06:25:27PM +0200, Peter Rosin wrote:
> The legacy path implements setcmap in terms of crtc .gamma_set.
>
> The atomic path implements setcmap by directly updating the crtc gamma_lut
> property.
>
> This has a couple of benefits:
> - it makes the redundant fb helpers .load_
On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote:
> On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> >> Dear All,
> >>
> >> I am looking for an solution to have early smooth splashscreen on the
> >> Linux system with Weston
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - C
On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.
>
> Acked-by: Daniel Ve
On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.
>
> Acked-by: Daniel Ve
https://bugs.freedesktop.org/show_bug.cgi?id=26345
Ленар changed:
What|Removed |Added
i915 platform||ALL
Hardware|x86 (IA32)
On Thu, Jul 13, 2017 at 6:04 AM, wrote:
> From: Patrick Bruenn
>
> This is a fix for the CX9020 Embedded PC. On that device the 24-bit
> parallel-display signal of the imx53 is combined with an I2C channel
> and converted to DVI-D port. Devicetree magic always requires a panel
> connected to the
On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote:
> Make it more clear that post commit return ret is really return 0,
>
> and add a missing drm_atomic_helper_cleanup_planes when
> drm_atomic_helper_wait_for_fences fails.
>
> Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition
On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver.
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kerne
While this is no build dependency, etnaviv will only work correctly on most
systems if CMA and DMA_CMA are enabled. Select both options if available to
avoid users ending up with a non-working GPU due to a lacking kernel config.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/Kconfig | 2
On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> > We want to change swap_state to wait indefinitely, but to do this
> > swap_state should wait interruptibly. This requires propagating
> > the error to each driver.
On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state could previously never fail, in order to still
> continue it would set a limit of 10s on waiting for previous updates to
> complete,
> then it moved forward. This can be very bad when ignoring previou
On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> MSM has its own busy tracking, which means the swap_state call can be
On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Jonatha
On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> VC4 has its own nonblocking modeset tracking through the vc4->async_m
On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote:
> Now that all drivers check the return value, convert swap_state to
> __must_check. This is done separately to force build warnings if we
> missed a driver.
>
> Signed-off-by: Maarten Lankhorst
Maybe squash in with the next comm
On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_
On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
>> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
>> usage we could convert to WARN_ONCE?
>
> Shooting the messenger is generally considered uncool :)
That's never
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 123 ++
1 file changed,
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Generic DRM support is available here [1] and will be merged once
this pa
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 90 +--
lib/igt_kms.h | 3 ++
2 files changed, 59 insertions(+
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h | 1 +
lib/igt_crc.c
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 6 +-
lib/igt_kms.h | 7 +
tests/Makefile.s
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76 ++-
lib/igt_kms.h | 16 ++
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 63 +++
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
wrote:
> The conversion is a nice catch, but i'd like to have a bit more context, see
> below!
>
> With a better description:
>
> Tobias Klausmann
I don't think it was meant as a serious patch. WARN_ON_ONCE should
work. The fix isn't to remove a
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Correctly handle different page sizes in the memory accounting.
>
> Signed-off-by: Christian König
I'd split this patch in two, one to remove the no_wait and
interruptible flags and one to add the size parameter
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Remove unused defines and variables. Also stop computing the
> gfp_flags when they aren't used.
>
> No intended functional change.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/
On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote:
> Ok, a network outage gave me time to go hunting. Indeed it is a bad
> interaction with the tree DRM merged into. All DRM did was to slip a
> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> things no longer wa
On Fri, Jul 14, 2017 at 11:20:01AM -0400, Ilia Mirkin wrote:
> On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
> wrote:
> > The conversion is a nice catch, but i'd like to have a bit more context, see
> > below!
> >
> > With a better description:
> >
> > Tobias Klausmann
>
> I don't think it
On Thu, Jul 13, 2017 at 03:50:56PM +0200, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> > Dear All,
> >
> > I am looking for an solution to have early smooth splashscreen on the
> > Linux system with Weston and drm-backend.
> >
> > I tried showing splashscreen using
On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> > Urgh, is for some mysterious reason the __bug_table section of modules
> > ending up in RO memory?
> >
> > I forever get lost in that link magic :/
>
> +1
>
> drm.ko
>
On Thu, Jul 13, 2017 at 9:56 AM, Christian König
wrote:
> From: Christian König
>
> Try to allocate huge pages when it makes sense.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 217
> ---
> 1 file changed, 169 insertions(+),
Hi Mikko, Thierry,
While setting up my Jetson TK1 using the mainline kernel I discovered that the
HDMI output
didn't work.
After some more debugging I discovered that this commit
404bfb78daf3bedafb0bfab24947059575cbea3d
(gpu: host1x: Add IOMMU support) was the culprit.
As far as I understand i
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
> This patch checks encoder level support for YCBCR420 outputs.
> The logic goes as simple as this:
> If the input mode is YCBCR420-only mode: prepare HDMI for
> YCBCR420 output, else continue with RGB output mode.
>
> It checks if t
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
> To support ycbcr output, we need a pipe CSC block to do
> RGB->YCBCR conversion.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
>
On 17-06-29 22:49:44, Ville Syrjälä wrote:
[snip]
... but here it's ALIGN(formats_offset+formats_size). I think we should
be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
make sure the header size always stays a multiple of 8 bytes.
That's mainly because the design of the
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote:
> Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format,
> which is currently supported on HDMI 2.0 sources/sinks. Due to lower
> chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half
> the pixel clock
On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote:
> On 17-06-29 22:49:44, Ville Syrjälä wrote:
>
> [snip]
>
> >
> >... but here it's ALIGN(formats_offset+formats_size). I think we should
> >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
> >make sure the header s
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the clea
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using drm_atomi
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 de
2017-07-11 Chris Wilson :
> Quoting Chris Wilson (2017-02-14 12:40:01)
> > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> > memory (8802538683d0)
> > [ 236.828642]
> > 42001e7f0008
> > [ 236.839543] i i i i u
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
NAK. This takes unintentionally insane code and turns it intentionally
insane. Any non-zero return is considered an error.
The right f
On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
wrote:
>
> NAK. This takes unintentionally insane code and turns it intentionally
> insane. Any non-zero return is considered an error.
>
> The right fix is almost certainly to just return -EINVAL unconditionally.
Btw, this is why I hate compiler w
On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote:
> FIFO_MODE is an macro expression with a '<<' operator, which
> gcc points out could be misread as a '<':
Yeah, no, NAK again.
We don't make the code look worse just because gcc is being a f*cking
moron about things.
This warning is clearly
Quoting Daniel Vetter (2017-07-14 20:14:37)
> The legacy plane->fb pointer is refcounted by calling
> drm_atomic_clean_old_fb().
>
> In practice this isn't a real problem because:
> - The caller in the i915 gpu reset code restores the original state
> again, which means the plane->fb pointer won
Quoting Daniel Vetter (2017-07-14 20:14:38)
> First thing we need to do is unregister the fbdev instance, but we
> can't just go ahead and kfree it. That must wait until the hotplug and
> polling work are stopped, since they can race with the with the
> teardown. That means we need to split up the
On Fri, Jul 14, 2017 at 3:09 PM, Dan Carpenter wrote:
> On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote:
>> I don't agree with it as a static analysis dev...
>
> What I mean is if it's a macro that returns -ENODEV or a function that
> returns -ENODEV, they should both be treated the
1 - 100 of 121 matches
Mail list logo
