https://bugs.freedesktop.org/show_bug.cgi?id=103107
Marta Löfstedt changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |knikk...@gmail.com
|
Quoting Andy Shevchenko (2018-02-14 15:41:57)
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Chris Wilson
Note depends on rc1 backmerge.
-Chris
_
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #22 from arne_woer...@yahoo.com ---
(In reply to Alex Deucher from comment #20)
> Is it the firmware that caused the regression? Does everything work with
> the old firmware?
i did the following experiments:
1.
via kernel parameter
On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > >>>
On Thu, Feb 15, 2018 at 12:17 PM, Tomasz Figa wrote:
> On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy wrote:
>> On 14/02/18 10:33, Vivek Gautam wrote:
>>>
>>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote:
>>>
>>> Adding Jordan to this thread as well.
>>>
On Wed, Feb 14, 2018 at 6:13 PM
On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark wrote:
> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse
> wrote:
>> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>>
>>> - When submitting commands to the GPU, the GPU driver will
>>> pm_runtime_get_sync() on the GPU device, which will
On Thu, Feb 15, 2018 at 1:03 AM, Robin Murphy wrote:
> On 14/02/18 10:33, Vivek Gautam wrote:
>>
>> On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote:
>>
>> Adding Jordan to this thread as well.
>>
>>> On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
>>> wrote:
Hi Tomasz,
On We
Hi Dave,
Here goes drm-intel-fixes-2018-02-14-1:
There are important fixes for VLV with MIPI/DSI panels,
2 clean-up patches needed for this MIPI/DSI fix,
and many fixes for GEM including fixes for Perf OA and PMU,
and fixes on scheduler and preemption.
This also includes GVT fixes: "This has one
Let's sync CNL ids with Spec and kernel.
Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
Add Cannonlake PCI IDs for another SKU.")' and
commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'
Cc: James Ausmus
Cc: Lucas De Marchi
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
i
Abandoning this series as a new version was submitted for the review
"[RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver"
On Tue, Dec 19, 2017 at 11:29:17AM -0800, Kim, Dongwon wrote:
> Upload of intial version of hyper_DMABUF driver enabling
> DMA_BUF exchange between two different VMs in virt
Hi Sergei,
On Wednesday, 14 February 2018 20:39:59 EET Sergei Shtylyov wrote:
> On 02/14/2018 09:13 PM, Laurent Pinchart wrote:
> > From: Sergei Shtylyov
> >
> > After the recent corrections to the R-Car gen2/3 LVDS startup code,
> > already similar enough at their ends rcar_lvds_enable_gen{2|3}
The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7794.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
i
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
- Remove the DU reg-names property
---
arch/arm/boot/dts/r8a7791-koelsch.dts |
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
- Remove the DU reg-names property
---
arch/arm/boot/dts/r8a7793-gose.dts | 10
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
- Remove the DU reg-names property
---
.../boot/dts/renesas/r8a7795-es1-salvat
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
- Remove the DU reg-names property
---
arch/arm/boot/dts/r8a7790-lager.dts | 2
The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Fixed LVDS compatible string
Changes since v1:
- Remove the DU reg-names property
---
arch/arm64/boot/dts/renesas/r8a7796-m3u
The DU DT bindings have been updated to drop the reg-names property.
Update the r8a7792 device tree accordingly.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7792.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
i
The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Changes since v1:
- Remove the LVDS reg range from the example
- Remove the reg-names property
---
.../devicetree/bindings/
The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched l
The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Changes since v1:
- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- F
Hello,
This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.
To fix the, patches 01/12 and
The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.
Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.
Signed-off-
https://bugs.freedesktop.org/show_bug.cgi?id=104762
--- Comment #19 from Christoph Haag ---
(In reply to Christoph Haag from comment #18)
> To be fair, the segfaults are fixed, but sddm and plasmashell randomly not
> working/rendering until the shader cache(s) are deleted is still happening.
> Un
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #21 from Alex Deucher ---
(In reply to arne_woerner from comment #13)
> 1. (on Manjaro Linux) it is not enough to downgrade linux-firmware... u also
> need to do a mkinitcpio... :)
> 2. downgrading the directory /usr/lib/firmware/amd
On Wednesday, February 14, 2018 7:01 AM wrote:
>
> Exynos5, Exynos4 and S5PV210 platforms have been converted to
> use Device Tree and Exynos DRM driver long time ago. Remove
> dead platform code for these platforms and update Kconfig
> s3c-fb entry accordingly.
>
> Cc: Jingoo Han
Acked-by: Ji
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #20 from Alex Deucher ---
(In reply to arne_woerner from comment #19)
> ok...
>
> but why is it necessary to use that old amdgpu firmware,
> if it was some other part of the kernel?
>
> i cant find the change log of those firmware
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #19 from arne_woer...@yahoo.com ---
ok...
but why is it necessary to use that old amdgpu firmware,
if it was some other part of the kernel?
i cant find the change log of those firmware files...
could there be something, that does no
> Actually this was brought up to me already, there's a fix on the mailing list
> for this I reviewed a little while ago from nvidia that we should pull in:
>
> https://patchwork.freedesktop.org/patch/203205/
>
> Would you guys mind confirming that this patch fixes your issues?
It works on my am
https://bugs.freedesktop.org/show_bug.cgi?id=104439
--- Comment #7 from Urs Fleisch ---
Created attachment 137362
--> https://bugs.freedesktop.org/attachment.cgi?id=137362&action=edit
Bisect stopping a commit with lockup but not distortion
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=104439
--- Comment #6 from Urs Fleisch ---
Since Arch Linux switched to kernel 4.14 for linux-lts (and the standard linux
package is at 4.15), I now have the choice between two kernels which do not
work with my Intel graphics Q35, this gives me quite s
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #4 from Harry Wentland ---
How bad is the flicker? Would you be able to take a video showing the flicker
and post it (youtube or anywhere, really)?
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #3 from denisgolo...@yandex.ru ---
Adding amdgpu.dc=1 amdgpu.dc_log=1 indeed make flickering much less frequent.
However, I can still reproduce them when turning redshift on and off.
No logs in dmesg and messages with amdgpu appear t
On Wed, Feb 14, 2018 at 2:35 PM, Tom St Denis wrote:
> This will break umr since we source the headers from the kernel. The kernel
> might not use them but the different IP blocks have deltas that umr is aware
> of.
>
> One might argue that we should then publish the headers somewhere else that
>
This will break umr since we source the headers from the kernel. The
kernel might not use them but the different IP blocks have deltas that
umr is aware of.
One might argue that we should then publish the headers somewhere else
that is public but the kernel is our vehicle right now.
Thought
Forward Error Correction is supported on DP 1.4.
This patch adds corresponding DPCD register definitions.
v2: Add dri-devel mailing list to the CC list(Jani)
v3: Change names, add missing masks (Manasi)
v4: Add missing shifts to mask (Manasi)
v5: Arrange the definitions in ascending order
of th
From: Ville Syrjälä
Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.
CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it
From: Ville Syrjälä
Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Russell King - ARM Linux
Cc: Ilia Mirkin
Cc: Hans
From: Ville Syrjälä
Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.
On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program
From: Ville Syrjälä
On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.
The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's go
From: Ville Syrjälä
Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties,
and the i915 implementation I did on top. I tossed in a few core
updates as well: plane state dump, and the BT.2020 constant luminance
variant.
Apparently nouveau is already exposing a "iturbt_709" bool pro
From: Ville Syrjälä
Include color_enconding and color_range in the plane state dump.
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Russell King - ARM Linux
Cc: Ilia Mirkin
Cc: Hans Verkuil
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Jyri Sarha
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
BT.2020 specifies two YCbCr<->RGB conversion formulas. The more
traditional non-constant luminance and a more complicate one constant
luminance one. Add an enum value for the constant luminance variant
as well in case someone has hardware supporting it.
Cc: Harry Wentland
Cc
From: Ville Syrjälä
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).
On CHV pipe B we w
From: Jyri Sarha
Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are
Actually this was brought up to me already, there's a fix on the mailing list
for this I reviewed a little while ago from nvidia that we should pull in:
https://patchwork.freedesktop.org/patch/203205/
Would you guys mind confirming that this patch fixes your issues?
On Wed, 2018-02-14 at 18:41 +
On Wed, Feb 14, 2018 at 1:17 PM, jsanka wrote:
>
>
> On 2/13/2018 12:00 PM, Rob Clark wrote:
>>
>> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul wrote:
>>>
>>> Hi dri-devel,
>>> Qualcomm has been working for the past few weeks on forward porting their
>>> downstream drm driver from 4.14 to mainline.
I think your idea of having the extra kerneldoc as a seperate patch to make
this easier to backport should work fine :). Thanks for the good work!
Reviewed-by: Lyude Paul
On Wed, 2018-02-14 at 08:41 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output pol
https://bugs.freedesktop.org/show_bug.cgi?id=105095
--- Comment #1 from Roland Scheidegger ---
Is that BARTS specific?
My piglit runs with Juniper (HD 5750) show this test passing (and generally
there's no difference in the driver between these two chips).
(Albeit I never ran it with this specifi
From: Colin Ian King
Don't populate the const read-only arrays int_reg on the stack but instead
make them static. Makes the object code smaller by over 80 bytes:
Before:
textdata bss dec hex filename
280248936 192 371529120 drivers/gpu/ipu-v3/ipu-common.o
Afte
Rodrigo Vivi writes:
> On Wed, Feb 07, 2018 at 09:32:35PM +, Pandiyan, Dhinakaran wrote:
>>
>>
>>
>> On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
>> > On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
>> > > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pand
On 02/14/2018 09:13 PM, Laurent Pinchart wrote:
> From: Sergei Shtylyov
>
> After the recent corrections to the R-Car gen2/3 LVDS startup code, already
> similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
> a merge and it's becoming actually necessary with the addition o
On 2/13/2018 12:00 PM, Rob Clark wrote:
On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul wrote:
Hi dri-devel,
Qualcomm has been working for the past few weeks on forward porting their
downstream drm driver from 4.14 to mainline. Please consider this PR as a
request for review, rather than an attemp
Hello,
This patch series fixes the LVDS startup sequence for Gen2 and Gen3
SoCs, and then proceeds to refactoring the code to merge the Gen2 and
Gen3 implementations in preparation for V3M support.
The patches have been previously posted as part of the following series.
[PATCH 0/2] Fix LVDS sta
From: Sergei Shtylyov
According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.
While at it, also fix the comment preceding the first LVDCR0 write
Brief refresh of the a6xx GPU support for drm/msm
(v1 found here https://patchwork.freedesktop.org/series/37428/)
Thanks to Lucas for his comments, more comments gladly welcomed. I know it is
hard when you are reviewing code that won't be immediately coming to a device
near you but any feedback wi
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +++
2 files changed, 1982 in
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the H
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #18 from Alex Deucher ---
(In reply to arne_woerner from comment #17)
> yup:
> i mean: i did not test, which one is necessary...
> so i cannot say, if all three r necessary, or if just one/two of them
> suffice...
>
> tomorrow i wil
From: Sergei Shtylyov
According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.
Fixes: e947eccbeba4 ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by:
From: Sergei Shtylyov
After the recent corrections to the R-Car gen2/3 LVDS startup code, already
similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
a merge and it's becoming actually necessary with the addition of the R-Car
V3M (R8A77970) support -- this gen3 SoC has gen
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #17 from arne_woer...@yahoo.com ---
(In reply to Alex Deucher from comment #15)
> (In reply to arne_woerner from comment #14)
> > _but_ they both need at least one of these kernel parameters in the
> > grub.cfg:
> > amdgpu.si_support
Hi Sergei,
Thank you for the patch.
On Friday, 19 January 2018 20:29:21 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the LVDS encoder driver.
> Note that there are some differences with the other R-Car gen3 SoCs, e.g.
> LVDPLLCR has the same layout as in the R-Car
Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
constant and adds missing HDMI_I2S_SEL_DATA0.
The value of bit field selecting SDATA_1 (pin_sel_3) is also changed,
so it is 3 as suggested in the Exynos TRMs.
Signed-of
Hi Inki,
On 02/14/2018 06:57 AM, Inki Dae wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a4b75a46f946..abd84cbcf1c2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -1068,10 +10
On Thu, Feb 01, 2018 at 11:32:25AM +0100, Lucas Stach wrote:
> Hi Jordan,
>
> just some drive-by comments:
Drive by comments are the best.
> Am Mittwoch, den 31.01.2018, 11:25 -0700 schrieb Jordan Crouse:
> > Add support for the A6XX family of Adreno GPUs. The biggest addition
> > is the GMU (Gr
Hi Sergei,
On Tuesday, 16 January 2018 17:42:41 EET Laurent Pinchart wrote:
> On Saturday, 13 January 2018 11:25:31 EET Sergei Shtylyov wrote:
> > On 1/13/2018 1:15 AM, Laurent Pinchart wrote:
> According to the latest revisions of the R-Car gen3 manual, the LVDS
> mode must be set befor
On 01/13/2018 12:40 AM, Laurent Pinchart wrote:
> According to the latest versions of both the Gen2 and Gen3 datasheets,
> the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all
Not quite so with R-Car D3/E3 (which have the low boundary of 5 MHz) But we
don't
support them yet an
On Wed, Feb 14, 2018 at 1:46 AM, Bjorn Andersson
wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on 8974 and
Hi Sergei,
Thank you for the patch.
On Friday, 19 January 2018 20:29:20 EET Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car LVDS bindings.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/bridge/re
On Tue, Feb 13, 2018 at 10:46:58PM -0800, Bjorn Andersson wrote:
> Interrupt commands causes the CP to trigger an interrupt as the command
> is processed, regardless of the GPU being done processing previous
> commands. This is seen by the interrupt being delivered before the
> fence is written on
Hi Laurent,
Thankyou for the patch.
On 12/01/18 03:20, Laurent Pinchart wrote:
> On Gen3 hardware the VSP compositor is required for display. Enable it
> by default in the kernel configuration. The option is kept
> user-configurable for testing purpose on Gen2 platforms.
>
> Signed-off-by: Laure
On Tue, Feb 13, 2018 at 3:00 PM, Rob Clark wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul wrote:
>> Hi dri-devel,
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, r
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #18 from Ainola ---
I applied the patch to 4.15.3 on archlinux and have tested with xset dpms force
{standby,suspend} with success.
--
You are receiving this mail because:
You are the assignee for the bug.__
On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse wrote:
> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
>>
>> - When submitting commands to the GPU, the GPU driver will
>> pm_runtime_get_sync() on the GPU device, which will automatically do
>> the same on all the linked suppliers, wh
On 14/02/18 10:33, Vivek Gautam wrote:
On Wed, Feb 14, 2018 at 2:46 PM, Tomasz Figa wrote:
Adding Jordan to this thread as well.
On Wed, Feb 14, 2018 at 6:13 PM, Vivek Gautam
wrote:
Hi Tomasz,
On Wed, Feb 14, 2018 at 11:08 AM, Tomasz Figa wrote:
On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gau
On 14/02/18 17:39, Laurent Pinchart wrote:
>> I have to admit I didn't go through every line of the patches, but
>> overall I think this looks good. The only problem is the support for
>> DSS6, which I mentioned in the other mail.
>>
>> We don't have DSS6 support in mainline, but it's a critical t
On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote:
> Hi Jordan,
>
> On Wed, Feb 14, 2018 at 1:42 AM, Jordan Crouse wrote:
> > On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
> >> Hi Vivek,
> >>
> >> Thanks for the patch. Please see my comments inline.
> >>
> >> On Wed, Feb
Hi Tomi,
On Wednesday, 14 February 2018 15:24:53 EET Tomi Valkeinen wrote:
> Hi,
>
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > Hello,
> >
> > Most of this series has previously been posted as part of "[PATCH 00/48]
> > omapdrm: Merge omapdrm and omapdss". With "[PATCH v2 00/15] omapdrm:
> >
https://bugs.freedesktop.org/show_bug.cgi?id=105095
Bug ID: 105095
Summary: piglit arb_vertex_type_2_10_10_10_rev-array_types
failed for BARTS
Product: Mesa
Version: 17.3
Hardware: Other
OS: All
Hi Tomi,
On Wednesday, 14 February 2018 10:31:17 EET Tomi Valkeinen wrote:
> Hi,
>
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > The dss_device is the top-level component in the omapdss driver. Give
> > the omapdrm driver access to the dss_device pointer in order to obtain
> > pointers to all
On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> On 2018-02-14 03:08 PM, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> >>> Dear drm-misc maintainers,
> >>>
> >>> On Sun, Feb 11, 2018 at 10:38
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h| 1198
.../drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h| 1068 -
2 files changed, 2266 deletio
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h | 795 -
.../drm/amd/include/asic_reg/uvd/uvd_5_0_enum.h| 1211
.../drm/amd/include/asic_reg/uvd/
Hello
This patchset remove several headers which are not used by any source
file.
Regards
Change since v1:
- splited in multiple patchs
Change since v2
- Use --irreversible-delete for format-patch
Corentin Labbe (13):
drm/amd/include: remove unused asic_reg/oss headers
drm/amd/include: rem
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../gpu/drm/amd/include/asic_reg/smu/smu_6_0_d.h | 148 -
.../drm/amd/include/asic_reg/smu/smu_6_0_sh_mask.h | 715 ---
.../gpu/drm/amd/include/asic_reg/smu/smu_7_1_0_d.h | 1344
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/dce/dce_11_2_enum.h | 6813
.../drm/amd/include/asic_reg/dce/dce_8_0_enum.h| 1117
2 files changed, 7930 deletions(-)
delete
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/umc/umc_6_0_default.h | 31 -
.../drm/amd/include/asic_reg/umc/umc_6_0_offset.h | 52 --
2 files changed, 83 deletions(-)
d
displayobject.h is not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
drivers/gpu/drm/amd/include/displayobject.h | 249
1 file changed, 249 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/include/displayobject.h
diff --git a
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../amd/include/asic_reg/sdma0/sdma0_4_0_default.h | 286 -
.../amd/include/asic_reg/sdma1/sdma1_4_0_default.h | 282
2 files changed, 568 deleti
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h | 2791 ---
.../drm/amd/include/asic_reg/gca/gfx_8_1_enum.h| 6808 --
.../drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h | 21
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h| 412 -
drivers/gpu/drm/amd/powerplay/inc/pp_feature.h | 67
2 files changed, 479 deletions(-)
delete m
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../gpu/drm/amd/include/asic_reg/vce/vce_1_0_d.h | 64 --
.../drm/amd/include/asic_reg/vce/vce_1_0_sh_mask.h | 99 --
2 files changed, 163 deletions(-)
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/bif/bif_5_0_enum.h| 1198
.../drm/amd/include/asic_reg/bif/bif_5_1_enum.h| 1068 -
2 files changed, 2266 deletio
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../amd/include/asic_reg/nbif/nbif_6_1_sh_mask.h | 10281 ---
1 file changed, 10281 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/nbif/nbif_6_1_
All thoses headers are not used by any source files.
Lets just remove them.
Signed-off-by: Corentin Labbe
---
.../drm/amd/include/asic_reg/oss/oss_2_4_enum.h| 1340 --
.../drm/amd/include/asic_reg/oss/oss_3_0_1_enum.h | 1464 ---
.../drm/amd/include/asic_reg/
On 2018-02-14 03:08 PM, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
>> Op 14-02-18 om 09:46 schreef Lukas Wunner:
>>> Dear drm-misc maintainers,
>>>
>>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
Fix a deadlock on hybrid graphics lap
On Wed, 14 Feb 2018, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 02:48:29PM +0100, Hans Verkuil wrote:
>> Yes, your patches I've seen, but the 12 from Ramalingam I haven't seen.
>> At least not on dri-devel. It's a bit weird.
>
> Ahh, I'm sorry I misunderstood. I think Ram may have sent those to in
Hi,
On 14 February 2018 at 13:50, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 07:22:53AM -0500, Rob Clark wrote:
>> On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone wrote:
>> > This one I guess you can't get around though. Can they still run from
>> > the one plane, or do you secretly consume two pl
1 - 100 of 159 matches
Mail list logo
