Hello, Greg
Sorry, I am newcomer, and I don't know why couldn't use #ifdefs? I only refer
some kernel code(V4.19) in drivers/hwtracing/intel_th/msu.c.
Could you tell me why? And I tell my workmate to avoid the same case.
If I define a config in Kconfig, and static inline function in .h file,
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with a divider max value of say 16,
the
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with the
divider clock implementation, I am re-working it as of now. Basically
what is wrong is that with a divider max value of say 16, the driver
attempts to craft the max value into a
On 30/09/2019 19:13, Matt Roper wrote:
> CRTC background color kernel patches were written about 2.5 years ago
> and floated on the upstream mailing list, but since no opensource
> userspace materialized, we never actually merged them. However the
> corresponding IGT test did get merged and has
From: Daniel Kurtz
When setting a new display mode, dw_hdmi_setup() calls
dw_hdmi_enable_video_path(), which disables all hdmi clocks, including
the audio clock.
We should only (re-)enable the audio clock if audio was already enabled
when setting the new mode.
Without this patch, on RK3288,
On Sat, Sep 28, 2019 at 10:23 PM james qian wang (Arm Technology
China) wrote:
>
> On Wed, Sep 25, 2019 at 03:58:31PM -0700, Derek Basehore wrote:
> > Devicetree systems can set panel orientation via a panel binding, but
> > there's no way, as is, to propagate this setting to the connector,
> >
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple
The previous version of this series was posted in February here:
https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html
Right before we merged this in February Maarten noticed that we should
be setting up the initial property state in a CRTC reset function (which
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
We should support readout and verification of crtc background color as
we do with other pipe state. Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.
At boot time
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Hi Linus,
On Mon, Sep 16, 2019 at 05:22:07PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
> > On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
> > wrote:
> >
> > > If we agree in principle, I would like to have the very first 3 patches
> > > in
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
Some platforms are not able to maintain the color transformation
state after a system suspend/resume cycle.
Set the colog_mgmt_changed flag so that CMM on the CRTCs in
the suspend state are reapplied after system resume.
Signed-off-by: Ezequiel Garcia
---
This is an RFC, and it's mostly based
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
This reverts commit c87fb38df19da3362a0e20df1aad852100995ead,
which conflicts with adding driver-specific behavior in
atomic_commit_tail().
No functional changes expected on this commit, but just preparation
for the upcoming gamma LUT support.
Cc: Sean Paul
Signed-off-by: Ezequiel Garcia
---
Let's support Gamma LUT configuration on RK3288 SoCs.
In order to do so, this series adds a new and optional
address resource.
A separate address resource is required because on this RK3288,
the LUT address is after the MMU address, which is requested
by the iommu driver. This prevents the
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #8 from Marko Popovic ---
(In reply to Doug Ty from comment #7)
> (In reply to Marko Popovic from comment #6)
> > (In reply to Doug Ty from comment #5)
> > > I've been getting this too with Minecraft:
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #7 from Doug Ty ---
(In reply to Marko Popovic from comment #6)
> (In reply to Doug Ty from comment #5)
> > I've been getting this too with Minecraft:
> > https://bugs.freedesktop.org/show_bug.cgi?id=111669
> >
> > For my
On 30/09/2019 18:10, Adam Ford wrote:
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I
On Fri, 27 Sep 2019 16:25:13 +
Parav Pandit wrote:
> Hi Alex,
>
>
> > -Original Message-
> > From: Alex Williamson
> > Sent: Tuesday, September 24, 2019 6:07 PM
> > To: Jason Wang
> > Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> > ker...@vger.kernel.org;
+Doug, Heiko:
On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> When resuming from system suspend, the DU driver is
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #152 from ReddestDream ---
Kernel 5.4-rc1, the first kernel version that includes the Vega 20 patches
noted by Alex Deucher, is now out and in linux-mainline on Arch Linux AUR. :)
I plan to do some testing of this version over the
The 'debug_data' variable gets printed in debug statements without a
prior initialization in the function
hubbub1_verify_allow_pstate_change_high, as reported when building with
gcc 9.1.0:
warning: ‘debug_data’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
290 |
Could anyone please review the patch below & let me know if any other ideas
please?
https://patchwork.freedesktop.org/patch/332806/?series=66837=3
Thanks,
> -Original Message-
> From: S, Srinivasan
> Sent: Wednesday, September 25, 2019 8:33 PM
> To: 'Ville Syrjälä'
> Cc: Navare,
On Fri, Sep 27, 2019 at 9:59 AM Krzysztof Kozlowski wrote:
>
> On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski
> wrote:
> >
> > From: Maciej Falkowski
> >
> > Convert Samsung Image Scaler to newer dt-schema format.
> >
> > Signed-off-by: Maciej Falkowski
> > Signed-off-by: Marek Szyprowski
>
On 30/09/2019 17:26, Steven Price wrote:
On 30/09/2019 16:24, Robin Murphy wrote:
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
On Mon, Sep 30, 2019 at 11:26 AM Steven Price wrote:
>
> On 30/09/2019 16:24, Robin Murphy wrote:
> > Although going full "dma-coherent" ends badly due to GEM objects still
> > being forcibly mapped non-cacheable, we can at least take advantage of
> > Juno's ACE-lite integration to skip cache
On Mon, Sep 30, 2019 at 10:25 AM Robin Murphy wrote:
>
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own
On 9/30/19 7:12 PM, Linus Torvalds wrote:
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
to cover cases when a THP is mapped with PTEs. To me it's not a big
stretch to make it cover multiple pages too.
I
On Mon, Sep 30, 2019 at 04:24:58PM +0100, Robin Murphy wrote:
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
>
> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
> to cover cases when a THP is mapped with PTEs. To me it's not a big
> stretch to make it cover multiple pages too.
I agree that is closer, but it does make
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explenation of the issue as a in-code comment
RFC comment (copied from last sent):
We are quite sure that there is a higher amount of bridges affected by
Hi Ayan,
Could we preserve Ray's authorship on this patch?
On Mon, Sep 30, 2019 at 04:44:38PM +, Ayan Halder wrote:
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Changes from v1:-
>
Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
denote the 16x16 block u-interleaved format used in Arm Utgard and
Midgard GPUs.
Changes from v1:-
1. Reserved the upper four bits (out of the 56 bits assigned to each vendor)
to denote the category of Arm specific modifiers.
On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
wrote:
>
> On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > still happens with your patch applied. The machine simply gets shut down.
> >
> > dmesg can be found here:
> >
From: Christian König
This feature is only used by vmwgfx and superflous for everybody else.
v2: use vmw_buffer_object instead of vmw_user_bo.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 --
drivers/gpu/drm/ttm/ttm_bo_util.c
On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> still happens with your patch applied. The machine simply gets shut down.
>
> dmesg can be found here:
>
On 30/09/2019 16:24, Robin Murphy wrote:
> Although going full "dma-coherent" ends badly due to GEM objects still
> being forcibly mapped non-cacheable, we can at least take advantage of
> Juno's ACE-lite integration to skip cache maintenance for pagetables.
>
> CC: Rob Herring
> CC: Tomeu
still happens with your patch applied. The machine simply gets shut down.
dmesg can be found here:
https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt
If there are no other things to try out, I will post the
Bring dmabuf sharing through implementing prime_import_sg_table callback.
This will help to validate userspace conformance in prime configurations
without using any actual hardware (e.g. in the cloud).
This enables kms_prime IGT testcase on vkms.
V2:
- Rodrigo: styleguide + return code check
Hi,
On Tue, Sep 24, 2019 at 02:40:54PM +0200, megous hlavni wrote:
> > > On first run of the X server, only the black screen and the layer
> > > containing the cursor is visible. Switching to console and back
> > > corrects the situation.
> > >
> > > I have dumped registers, and found out
> Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
> >> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
> >>> As far as I can see by your second patch QXL is just using exported
> >>> (that
Neil Armstrong writes:
> Hi Kevin,
>
> On 25/09/2019 21:31, Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> On some SoCs, the VPU is in a power-domain and needs runtime PM
>> enabled and used in order to keep the power domain on.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>>
On Mon, Sep 30, 2019 at 05:15:53PM +0300, Jyri Sarha wrote:
> From: Arnd Bergmann
>
> This was apparently dropped by accident in a recent
> cleanup, causing a build failure in some configurations now:
>
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
> function
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
CC: Rob Herring
CC: Tomeu Vizoso
Signed-off-by: Robin Murphy
---
This isn't
Since we now have bindings for Mali Midgard GPUs, let's use them to
describe Juno's GPU subsystem, if only because we can. Juno sports a
Mali-T624 integrated behind an MMU-400 (as a gesture towards
virtualisation), in their own dedicated power domain with DVFS
controlled by the SCP.
CC: Liviu
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #6 from Marko Popovic ---
(In reply to Doug Ty from comment #5)
> I've been getting this too with Minecraft:
> https://bugs.freedesktop.org/show_bug.cgi?id=111669
>
> For my particular case at least, AMD_DEBUG=nodma seems to fix
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
> > Let's see what Tero says, but yeah, something is odd here. I expected
> > the max divider to be 16 with Tero's patch, but I don't see it having
> > that effect. I can get the div to 31.
> >
> Am 30.09.2019 um 16:27 schrieb Tomi Valkeinen :
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
>> Let's see what Tero says, but yeah, something is odd here. I expected the
>> max divider to be 16 with Tero's patch, but I don't see it having that
>> effect. I can get the div to 31.
>> You
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> +static int system_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> +
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> +
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I can get the div to 31.
You can see this from the clock register 0x48004e40 (CM_CLKSEL_DSS).
On 30/09/2019 17:12, Adam Ford wrote:
I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.
Sorry for all the spam, but I moved both of them to 31 from 32, and it
From: Arnd Bergmann
This was apparently dropped by accident in a recent
cleanup, causing a build failure in some configurations now:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
function 'devm_pinctrl_get_select_default'
On Mon, Sep 30, 2019 at 9:04 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
> >
> > On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> > wrote:
> > >
> > >
> > > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > > >
> > > > The best action here is probably to
On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > >
> > > The best action here is probably to drop the max-div value for this clock
> > > to 16. Can someone check
On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller wrote:
>
>
> > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> >
> > The best action here is probably to drop the max-div value for this clock
> > to 16. Can someone check this with their display setup and see what
> > happens? Attached patch
From: Ville Syrjälä
Use the new drm_rect_init() helper where appropriate.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git
From: Ville Syrjälä
Add a helper to initialize a rectangle from x/y/w/h information.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fc7c14627ee2..cd0106135b6a
From: Ville Syrjälä
Use the newly introduced drm_rect_translate_to() instead
of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
From: Ville Syrjälä
Add a helper to translate a rectangle to an absolute position.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6195820aa5c5..fc7c14627ee2
On 9/6/19 2:47 PM, John Stultz wrote:
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a
> Am 30.09.2019 um 10:53 schrieb Tero Kristo :
>
> The best action here is probably to drop the max-div value for this clock to
> 16. Can someone check this with their display setup and see what happens?
> Attached patch should do the trick.
I have checked on GTA04 and OpenPandora (DM3730
On Fri, Sep 20, 2019 at 10:15:41AM +0800, Qiang Yu wrote:
> Hi guys,
>
> I'd like to know the status of this patch? I expect a v2 adding some
> comments/macros about the high bit plan would be enough?
>
> @Raymond & @Brian do you still need another long process to send out a
> v2 patch? If so, I
On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch:
>
> On 05.09.19 15:34, Jaak Ristioja wrote:
> > On 05.09.19 10:14, Gerd Hoffmann wrote:
> >> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
> >>> Hello!
> >>>
> >>> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> >>> I originally filed the issue on
Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
>> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
>>> As far as I can see by your second patch QXL is just using exported
>>> (that is not
On 26/09/2019 23:08, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
>> use the correct max fractional PLL value for G12A VPU.
>>
>> With this fix, we can finally setup the 1024x768-60 mode.
>>
>> Fixes: 202b9808f8ed
Hi Steven,
On 27/09/2019 17:00, Steven Price wrote:
> On 27/09/2019 12:48, Neil Armstrong wrote:
>> Hi,
>>
>> On 27/09/2019 13:27, Neil Armstrong wrote:
>>> Hi Steven,
>>>
>>> Thanks for your prompt reaction !
>>>
>>> On 27/09/2019 12:48, Steven Price wrote:
On 27/09/2019 10:55, Steven Price
On Mon, Sep 30, 2019 at 7:48 AM Tero Kristo wrote:
>
> On 30/09/2019 15:41, Adam Ford wrote:
> > On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
> >>
> >> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On 27/09/2019 18:47, Tomi Valkeinen wrote:
> On 27/09/2019 18:37,
That is not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++
include/drm/ttm/ttm_bo_api.h | 5 --
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch should be functional
On Fri, Sep 27, 2019 at 09:39:48AM -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov
> wrote:
> >
> > > Call it "walk_page_mapping()". And talk extensively about how the
> > > locking differs a lot from the usual "walk_page_vma()" things.
> >
> > Walking mappings
On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > > On Tue, Sep 17, 2019
On 30/09/2019 15:41, Adam Ford wrote:
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
>
> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 27/09/2019 18:47, Tomi Valkeinen wrote:
> >> On 27/09/2019 18:37, Tero Kristo wrote:
> >>
> >>> If you can provide details about what clock framework / driver does
> >>> wrong
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #63 from Doug Ty ---
(In reply to Matthias Müller from comment #58)
> Don't know where to report as the navi-firmware is not in the
> kernel-firmware, yet?
Not sure if this is correct, but I've created a separate issue for these
https://bugs.freedesktop.org/show_bug.cgi?id=111869
--- Comment #2 from Doug Ty ---
Created attachment 145595
--> https://bugs.freedesktop.org/attachment.cgi?id=145595=edit
divide-error_09-30-x2.txt
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111869
Bug ID: 111869
Summary: Navi "divide error" hang
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: not set
https://bugs.freedesktop.org/show_bug.cgi?id=111869
--- Comment #1 from Doug Ty ---
Created attachment 145594
--> https://bugs.freedesktop.org/attachment.cgi?id=145594=edit
divide-error_09-30.txt
--
You are receiving this mail because:
You are the assignee for the
Fix both the string and the struct member being printed.
Changes since v1:
- Now with a bonus grammar fix, too.
Fixes: 264b9436d23b ("drm/komeda: Enable writeback split support")
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 4 ++--
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #5 from Doug Ty ---
I've been getting this too with Minecraft:
https://bugs.freedesktop.org/show_bug.cgi?id=111669
For my particular case at least, AMD_DEBUG=nodma seems to fix it
--
You are receiving this mail because:
You are
On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey wrote:
>
> Hi James,
>
> On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
> China) wrote:
> > This function is used to convert drm_color_ctm S31.32 sign-magnitude
> > value to komeda required Q2.12 2's complement
> >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=205049
--- Comment #1 from le...@onet.pl ---
Created attachment 285243
--> https://bugzilla.kernel.org/attachment.cgi?id=285243=edit
output of uname -a with garbled graphics
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=205049
Bug ID: 205049
Summary: garbled graphics
Product: Drivers
Version: 2.5
Kernel Version: 5.2.15-200
Hardware: x86-64
OS: Linux
Tree: Mainline
Hi Laurent,
On 07/07/2019 21:18, Laurent Pinchart wrote:
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In
Hi James,
On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm_color_ctm S31.32 sign-magnitude
> value to komeda required Q2.12 2's complement
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
>
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The unspoken, legacy rule used in the past was to make user-space figure
out the zpos from object IDs. However some drivers break this rule,
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> These new format is supported by some rockchip socs:
>
> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>
> Signed-off-by: Sandy Huang
> ---
>
On Fri, Sep 27, 2019 at 06:28:51PM -0700, Jeykumar Sankaran wrote:
> The mode_config max width/height values determine the maximum
> resolution the pixel reader can handle.
Not according to the docs I "fixed" a while ago.
> But the same values are
> used to restrict the size of the framebuffer
OMAP2 and OMAP3/AM4 have limitations with the scaler:
- OMAP2 can only scale XRGB
- OMAP3/AM4 can only scale XRGB, RGB565, YUYV and UYVY
The driver doesn't check these limitations, which leads to sync-lost
floods.
This patch adds a check for the pixel formats when scaling.
From: Alejandro Hernandez
A "HDMI I2C Master Error" is sometimes reported with the current DDC SCL
timings. The current settings for a 10us SCL period (100 KHz) causes the
error with some displays. This patch increases the SCL signal period
from 10us to 10.2us, with the new settings the error
Commit d49cd15550d9d4495f6187425318c245d58cb63f ("OMAPDSS: DISPC: lock
access to DISPC_CONTROL & DISPC_CONFIG") added locking to
mgr_fld_write(). This was needed in omapfb times due to lack of good
locking, especially in the case of both V4L2 and fbdev layers using the
DSS driver.
This is not
Avoid unnecessary copy in mgr_fld_read/write by taking a pointer to the
reg_resc and using that.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
From: Jyri Sarha
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
Hi,
This is v2 of the series. Changes compared to v1:
Dropped (Jyri will work on them):
- drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
- drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Added:
- drm/omap: avoid copy in mgr_fld_read/write
-
If use_mclk is false, mclk_mode is written to a register without
initialization. This doesn't cause any ill effects as the written value
is not used when use_mclk is false.
To fix this, write use_mclk only when use_mclk is true.
Signed-off-by: Tomi Valkeinen
---
Currently the HDMI driver uses always limited range RGB output. This
patch improves the behavior by using limited range only if the output is
identified as a HDMI display, and VIC > 1.
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 121
1 - 100 of 148 matches
Mail list logo
