On 10/9/18 8:10 AM, Mikko Perttunen wrote:
> Reviewed-by: Mikko Perttnuen
Thank you :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ioremap_prot() with flag set to 0 relies on a hack in
__ioremap_caller() which adds PAGE_KERNEL flags when the
handed flags don't look like a valid set of flags
(ie don't include _PAGE_PRESENT)
The intention being to map cached memory, use ioremap_cache() instead.
Signed-off-by: Christophe Leroy
To reduce the complexity of flag_array, and allow the removal of
default 0 value of non existing flags, lets have one flag_array
table for each platform family with only the really existing flags.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/Makefile
__P and __S flags are the same for all platform and should remain
as is in the future, so avoid duplication.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 20
arch/powerpc/include/asm/pgtable.h | 1
In order to allow their use in nohash/32/pgtable.h, we have to move the
following helpers in nohash/[32:64]/pgtable.h:
- pte_mkwrite()
- pte_mkdirty()
- pte_mkyoung()
- pte_wrprotect()
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/pgtable.h
Get rid of platform specific _PAGE_ in powerpc common code and
use helpers instead.
mm/dump_linuxpagetables.c will be handled separately
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 9 +++--
arch/powerpc/include/asm/n
In order to avoid multiple conversions, handover directly a
pgprot_t to map_kernel_page() as already done for radix.
Do the same for __ioremap_caller() and __ioremap_at().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/include/asm/book3s/6
On Tue, Oct 9, 2018 at 10:14 AM Nathan Chancellor
wrote:
>
> When building the kernel with Clang with defconfig and CONFIG_64BIT
> disabled, vmlinux fails to link because of the BUILD_BUG in
> _print_param.
>
> ld: drivers/gpu/drm/i915/i915_params.o: in function `i915_params_dump':
> i915_params.c
book3s/32 doesn't define _PAGE_EXEC, so no need to use it.
All other platforms define _PAGE_EXEC so no need to check
it is not NUL when not book3s/32.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
arch/powerpc/mm/pgtable.
The following page flags in pte-common.h can be dropped:
_PAGE_ENDIAN is only used in mm/fsl_booke_mmu.c and is defined in
asm/nohash/32/pte-fsl-booke.h
_PAGE_4K_PFN is nowhere defined nor used
_PAGE_READ, _PAGE_WRITE and _PAGE_PTE are only defined and used
in book3s/64
The following page flags
Cache related flags like _PAGE_COHERENT and _PAGE_WRITETHRU
are defined on most platforms. The platforms not defining
them don't define any alternative. So we can give them a NUL
value directly for those platforms directly.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/
The 'access' parameter of hash_preload() is either 0 or _PAGE_EXEC.
Among the two versions of hash_preload(), only the PPC64 one is
doing something with this 'access' parameter.
In order to remove the use of _PAGE_EXEC outside platform code,
'access' parameter is replaced by 'is_exec' which will b
_PAGE_PRIVILEGED corresponds to the SH bit which doesn't protect
against user access but only disables ASID verification on kernel
accesses. User access is controlled with _PMD_USER flag.
Name it _PAGE_SH instead of _PAGE_PRIVILEGED
_PAGE_HUGE corresponds to the SPS bit which doesn't really tells
In many places, ioremap_prot() and __ioremap() can be replaced with
higher level functions like ioremap(), ioremap_coherent(),
ioremap_cache(), ioremap_wc() ...
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/btext.c | 2 +-
arch/powerpc/kernel/crash_dump.c | 2 +-
Set PAGE_KERNEL directly in the caller and do not rely on a
hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
As already done for PPC64, use pgprot_cache() helpers instead of
_PAGE_XXX flags in PPC32 ioremap() derived functions.
Signed-off-by: Christophe Leroy
---
arch/powerpc/includ
The base kernel PAGE_ definition sets are more or less platform
specific. Lets distribute them close to platform _PAGE_XXX flags
definition, and customise them to their exact platform flags.
Also defines _PAGE_PSIZE and _PTE_NONE_MASK for each platform
allthough they are defined as 0.
Do the
Today flags like for instance _PAGE_RW or _PAGE_USER are used through
common parts of code.
Using those directly in common parts of code have proven to lead to
mistakes or misbehaviour, because their use is not always as trivial
as one could think.
For instance, (flags & _PAGE_USER) == 0 isn't eno
Do not include pte-common.h in nohash/32/pgtable.h
As that was the last includer, get rid of pte-common.h
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/pgtable.h | 23 +--
arch/powerpc/include/asm/pte-common.h|
The 40xx defines _PAGE_HWWRITE while others don't.
The 8xx defines _PAGE_RO instead of _PAGE_RW.
The 8xx defines _PAGE_PRIVILEGED instead of _PAGE_USER.
The 8xx defines _PAGE_HUGE and _PAGE_NA while others don't.
Lets those platforms redefine pte_write(), pte_wrprotect() and
pte_mkwrite() and get
In the same spirit as already done in pte query helpers,
this patch changes pte setting helpers to perform endian
conversions on the constants rather than on the pte value.
In the meantime, it changes pte_access_permitted() to use
pte helpers for the same reason.
Signed-off-by: Christophe Leroy
nohash/64 only uses book3e PTE flags, so it doesn't need pte-common.h
This also allows to drop PAGE_SAO and H_PAGE_4K_PFN from pte_common.h
as they are only used by PPC64
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/64/pgtable.h | 16 +++
In order to avoid using generic _PAGE_XXX flags in powerpc
core functions, define helpers for all needed flags:
- pte_mkuser() and pte_mkprivileged() to set/unset and/or
unset/set _PAGE_USER and/or _PAGE_PRIVILEGED
- pte_hashpte() to check if _PAGE_HASHPTE is set.
- pte_ci() check if cache is inhib
_PAGE_NO_CACHE is a platform specific flag. In addition, this flag
is misleading because one would think it requests a noncached page
whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED
_PAGE_NO_CACHE alone means write combined noncached page, so lets
use ioremap_wc() instead.
_PAGE_WRITET
When building the kernel with Clang with defconfig and CONFIG_64BIT
disabled, vmlinux fails to link because of the BUILD_BUG in
_print_param.
ld: drivers/gpu/drm/i915/i915_params.o: in function `i915_params_dump':
i915_params.c:(.text+0x56): undefined reference to
`__compiletime_assert_191'
This
Other arches have ioremap_wt() to map IO areas write-through.
Implement it on PPC as well in order to avoid drivers using
__ioremap(_PAGE_WRITETHRU)
Also implement ioremap_coherent() to avoid drivers using
__ioremap(_PAGE_COHERENT)
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/io
_PAGE_WRITETHRU is a target specific flag. Prefer generic functions.
Acked-by: Geert Uytterhoeven
Signed-off-by: Christophe Leroy
---
drivers/block/z2ram.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
index d0c5bc4e0703..cfb
As done for book3s/64, add necessary flags/defines in
book3s/32/pgtable.h and do not include pte-common.h
It allows in the meantime to remove all related hash
definitions from pte-common.h and to also remove
_PAGE_EXEC default as _PAGE_EXEC is defined on all
platforms except book3s/32.
Reviewed-b
Now the pte-common.h is only for nohash platforms, lets
move pte_user() helper out of pte-common.h to put it
together with other helpers.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/pgtable.h | 10 ++
arch/powerpc/include/asm/pte-com
If TASK_COMM_LEN is made bigger DRM client name will be truncated. Avoid that.
Signed-off-by: Michał Mirosław
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm
On Tue, 2018-10-09 at 13:51 +, Christophe Leroy wrote:
> _PAGE_WRITETHRU is a target specific flag. Prefer generic functions.
>
> Acked-by: Geert Uytterhoeven
> Signed-off-by: Christophe Leroy
Hi Geert,
All patches that have been applied to this driver since 2005 are API refactoring
patche
On Fri, 5 Oct 2018 12:21:20 -0400
"Kazlauskas, Nicholas" wrote:
> On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
> > Hi,
> >
> > I have a somewhat of my own view on what would be involved with VRR,
> > and I'd like to hear what you think of it. Comments inline.
> >
> >
> > On Tue, 25 Sep 2018 0
https://bugs.freedesktop.org/show_bug.cgi?id=108260
--- Comment #2 from taij...@posteo.de ---
Same error also occurs with the latest drm-next-4.20-wip as of commit
e5560166811c07862d7ed9790674b2763c71f12e.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hello together,
On Tuesday, 9 October 2018 19:01:58 CEST Bjorn Helgaas wrote:
> > > Do you happen to know if Windows has the same problem? I.e., if you
> > > boot an old version of Windows with a new GPU, and unplug the VGA
> > > cable, does Windows crash? If Windows can figure out how to handle
On Mon, Oct 8, 2018 at 11:12 PM Vladimir Zapolskiy wrote:
> From: Sandeep Jain
(...)
> +- ti,pixel-clock-edge : Selects Pixel Clock Edge.
> + Possible values are "<1>" or "<0>".
> + If "ti,pixel-clock-edge" is High <1>, output data is strobed on the
> + Rising edge of the PCLK.
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.
MDSS is one of
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c|
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.
MDSS is one of the interconnect consumers which uses the interconne
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
-none
Signed-off-by: Sravanthi Kollukuduru
---
Documentation/devicetree/bindings
In the current kernel, then kzalloc() can't fail for small allocations,
but if it did fail then we would have a NULL dereference in the error
handling. Also in dlfb_usb_disconnect() if "info" were NULL then it
would cause an Oops inside the unregister_framebuffer() function but it
can't be NULL so
On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
> In situations where a component fails to bind, a previously
> successfully bound component might already registered itself
> with the DRM framework (e.g. an encoder). When the master
> component then calls drm_mode_config_cleanup, we e
[adding Lucas]
On 10.10.2018 12:38, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
>> In situations where a component fails to bind, a previously
>> successfully bound component might already registered itself
>> with the DRM framework (e.g. an enco
On Wed, Oct 10, 2018 at 01:02:16PM +0200, Stefan Agner wrote:
> [adding Lucas]
>
> On 10.10.2018 12:38, Russell King - ARM Linux wrote:
> > On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
> >> In situations where a component fails to bind, a previously
> >> successfully bound compone
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #32 from Cristian Aravena Romero (carav...@gmail.com) ---
Hello,
The kernel 4.18.13 works correctly?
Best regards,
--
Cristian Aravena Romero (caravena)
--
You are receiving this mail because:
You are watching the assignee of the b
This adds support for the 3.5" LCD panel from Lemaker, sold for use with
BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
requires an active-low DE signal
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file chang
Some panels need an active-low data enable (DE) signal for the RGB
interface. This requires flipping a bit in the TCON0 polarity register
when setting up the mode for the RGB interface.
Add a new helper function to match specific bus flags and use it to set
the polarity inversion bit for the DE si
This adds the backlight panel, power, pwm and tcon0 device-tree bindings
required for supporting the 3.5" LCD from Lemaker on the BananaPi M1.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 89
1 file changed, 89 insertions(+)
diff --git
This adds the pin muxing definition for configuring the PD pins in LCD0
mode for a RGB888 format to the sun7i device-tree.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arc
On Tue, 09 Oct 2018, Nick Desaulniers wrote:
> On Tue, Oct 9, 2018 at 10:14 AM Nathan Chancellor
> wrote:
>>
>> When building the kernel with Clang with defconfig and CONFIG_64BIT
>> disabled, vmlinux fails to link because of the BUILD_BUG in
>> _print_param.
>>
>> ld: drivers/gpu/drm/i915/i915_p
https://bugs.freedesktop.org/show_bug.cgi?id=107898
Marvin Damschen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 10/10/2018 03:14 AM, Pekka Paalanen wrote:
On Fri, 5 Oct 2018 12:21:20 -0400
"Kazlauskas, Nicholas" wrote:
On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
Hi,
I have a somewhat of my own view on what would be involved with VRR,
and I'd like to hear what you think of it. Comments inline.
O
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #33 from Harry Wentland (harry.wentl...@amd.com) ---
Yes, it should. GregKH reverted the offending commit in 4.18.13.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Sorry for late response, just back from vacation.
Indeed I do have commit rights, I am back now and will finalize
this work soon.
Thanks for the reviews.
Andrey
On 10/03/2018 02:22 PM, Marek Olšák wrote:
Yes, Andrey has commit rights.
Marek
On Wed, Oct 3, 2018 at 10:34 AM Christian König
On Wed, Oct 10, 2018 at 03:29:51PM +0530, Viresh Kumar wrote:
> On 27-09-18, 11:23, Georgi Djakov wrote:
> > On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > > Add the "opp-interconnect-bw" property to specify the
> > > average and peak bandwidth for an interconnect path for
> > > a specific operat
On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> On 27-08-18, 09:11, Jordan Crouse wrote:
> > Add the nodes to describe the Adreno GPU and GMU devices.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++
> > 1 fi
On Tue, Oct 09, 2018 at 10:46:41PM -0700, Jeykumar Sankaran wrote:
> On 2018-10-09 11:07, Sean Paul wrote:
> > On Mon, Oct 08, 2018 at 09:27:18PM -0700, Jeykumar Sankaran wrote:
> > > Layer mixer/pingpong block counts and hw ctl block counts
> > > will not be same for all the topologies (e.g. layer
On Tue, Oct 09, 2018 at 11:15:02PM -0700, Jeykumar Sankaran wrote:
> On 2018-10-09 13:41, Sean Paul wrote:
> > On Mon, Oct 08, 2018 at 09:27:39PM -0700, Jeykumar Sankaran wrote:
> > > Instead of letting encoder make a centralized reservation for
> > > all of its display DRM components, this path sp
On Tue, Oct 09, 2018 at 11:03:24PM -0700, Jeykumar Sankaran wrote:
> On 2018-10-09 12:57, Sean Paul wrote:
> > On Mon, Oct 08, 2018 at 09:27:41PM -0700, Jeykumar Sankaran wrote:
> > > Since HW reservations are happening through atomic_check
> > > and all the display commits are catered by a single
https://bugs.freedesktop.org/show_bug.cgi?id=108014
--- Comment #9 from Harry Wentland ---
> All of that being said, that means this is a lot more severe then I thought!
> :), phew.
Do you mean less severe?
>
>
> Now onto the actual patch that you sent: what exactly is this supposed to be
On Wed, Oct 10, 2018 at 08:01:49PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:29, Jordan Crouse wrote:
> > On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > > Add the nodes to describe the Adreno GPU and GMU devices.
> > > >
> > >
On Mon, Oct 08, 2018 at 09:27:25PM -0700, Jeykumar Sankaran wrote:
> Use the hw block pointers stored in crtc state to
> release them back to RM resource pool. This change
> is made to uncouple RM reservation from encoder_id.
> Separate change is submitted to clean up RM of
> encoder id tagging.
>
On Mon, Oct 08, 2018 at 09:27:26PM -0700, Jeykumar Sankaran wrote:
> HW blocks reserved for a display are stored in crtc state.
> No one outside RM is interested in using these API's for
> HW block list iterations.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gp
On Mon, Oct 08, 2018 at 09:27:27PM -0700, Jeykumar Sankaran wrote:
> hw_mdp block is common for displays. No need
> to reserve per display.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ++-
> drivers/gpu/drm/msm/disp/dpu1
On Wed, Oct 10, 2018 at 01:41:31PM +0200, Paul Kocialkowski wrote:
> Some panels need an active-low data enable (DE) signal for the RGB
> interface. This requires flipping a bit in the TCON0 polarity register
> when setting up the mode for the RGB interface.
>
> Add a new helper function to match
On Mon, Oct 08, 2018 at 09:27:28PM -0700, Jeykumar Sankaran wrote:
> Now that we have crtc state tracking the reserved
> HW resources, we have access to them after atomic swap.
> So avoid reserving the resources in mode_set.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
>
On Wed, Oct 10, 2018 at 01:41:32PM +0200, Paul Kocialkowski wrote:
> This adds support for the 3.5" LCD panel from Lemaker, sold for use with
> BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
> requires an active-low DE signal
>
> Signed-off-by: Paul Kocialkowski
> ---
> dr
On Mon, Oct 08, 2018 at 09:27:29PM -0700, Jeykumar Sankaran wrote:
> This flag was introduced as a fix to notify modeset complete
> when hw reservations were happening in both atomic_check
> and atomic_commit paths. Now that we are reserving only in
> atomic_check, we can get rid of this flag.
>
>
On Wed, Oct 10, 2018 at 01:41:33PM +0200, Paul Kocialkowski wrote:
> This adds the pin muxing definition for configuring the PD pins in LCD0
> mode for a RGB888 format to the sun7i device-tree.
>
> Signed-off-by: Paul Kocialkowski
OUr policy so far has been that if there's no user for that pin g
On Mon, Oct 08, 2018 at 09:27:30PM -0700, Jeykumar Sankaran wrote:
> Usage of hw block iterators are only RM internal. Instead
> of using generic void pointers for HW blocks, use dpu
> specific structure. It helps us to get rid of duplicate
> hw block id's maintained in RM wrapper.
>
> Signed-off-
https://bugs.freedesktop.org/show_bug.cgi?id=108317
Bug ID: 108317
Summary: [Polaris] Black Textures on Polaris only in Cemu Zelda
Breath of the Wild
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
O
https://bugs.freedesktop.org/show_bug.cgi?id=108317
John Galt changed:
What|Removed |Added
Version|XOrg git|DRI git
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=108307
--- Comment #5 from Alex Deucher ---
Sounds like it may be related to:
https://bugzilla.kernel.org/show_bug.cgi?id=200087
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108307
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #2 from John Galt ---
Created attachment 141977
--> https://bugs.freedesktop.org/attachment.cgi?id=141977&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #1 from John Galt ---
Created attachment 141976
--> https://bugs.freedesktop.org/attachment.cgi?id=141976&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #3 from John Galt ---
Created attachment 141978
--> https://bugs.freedesktop.org/attachment.cgi?id=141978&action=edit
Screenshot of the issue
--
You are receiving this mail because:
You are the assignee for the bug.__
On Mon, Oct 08, 2018 at 09:27:31PM -0700, Jeykumar Sankaran wrote:
> RM was using encoder id's to tag HW block's to reserve
> and retrieve later for display pipeline. Now
> that all the reserved HW blocks for a display are
> maintained in its crtc state, no retrieval is needed.
> This patch cleans
On Mon, Oct 08, 2018 at 09:27:32PM -0700, Jeykumar Sankaran wrote:
> Get rid of hw block pointer in RM iter as we can
> access the same through dpu_hw_blk.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 ++
> 1 file chan
https://bugs.freedesktop.org/show_bug.cgi?id=108317
John Galt changed:
What|Removed |Added
Summary|[Polaris] Black Textures on |[Polaris] Black Textures
On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:48, Jordan Crouse wrote:
> > qcom,level comes straight from:
> >
> > https://lore.kernel.org/lkml/20180627045234.27403-2-rna...@codeaurora.org/
> >
> > But in this case instead of using the CPU to program the RPMh we
On Mon, Oct 08, 2018 at 09:27:33PM -0700, Jeykumar Sankaran wrote:
> Encoder uses test_only flag to differentiate RM reservations
> invoked from atomic check and atomic_commit phases.
> After reserving the HW blocks, if test_only was set, RM
> releases the reservation. Retains them if not. Since we
BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
FB_BACKLIGHT prevents it from being built as a module. There
doesn't seem to be any particularly good reason for this, so
switch FB_BACKLIGHT over to tristate.
Signed-off-by: Rob Clark
---
drivers/video/fbdev/Kconfig| 2 +-
dr
https://bugs.freedesktop.org/show_bug.cgi?id=108318
Bug ID: 108318
Summary: [Polaris] Glitches in New Super Mario Brothers U in
Cemu on Polaris only (recent)
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #1 from John Galt ---
Created attachment 141981
--> https://bugs.freedesktop.org/attachment.cgi?id=141981&action=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #2 from John Galt ---
Created attachment 141982
--> https://bugs.freedesktop.org/attachment.cgi?id=141982&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #3 from John Galt ---
Created attachment 141983
--> https://bugs.freedesktop.org/attachment.cgi?id=141983&action=edit
screenshot of the issue
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108318
--- Comment #4 from John Galt ---
I forgot to mention, if IRC works better for communication for anyone, I'm
TheRealJohnGalt on Freenode #radeon.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #4 from John Galt ---
I forgot to mention, if IRC works better for communication for anyone, I'm
TheRealJohnGalt on Freenode #radeon.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108318
John Galt changed:
What|Removed |Added
Attachment #141980|dmesg from boo |dmesg from boot to the
description|
On 10/10/18, Rob Clark wrote:
> BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
> FB_BACKLIGHT prevents it from being built as a module. There
> doesn't seem to be any particularly good reason for this, so
> switch FB_BACKLIGHT over to tristate.
>
> Signed-off-by: Rob Clark
I don't
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #3 from quirin.blae...@freenet.de ---
(In reply to Alex Deucher from comment #1)
> Is this a regression? If so, can you bisect?
which is the first release supporting RX560?
--
You are receiving this mail because:
You are watching t
Add bindings for Snapdragon 845 DisplayPort and
display-port PLL driver.
Signed-off-by: Chandan Uddaraju
---
.../devicetree/bindings/display/msm/dp.txt | 249 +
.../devicetree/bindings/display/msm/dpu.txt| 16 +-
2 files changed, 261 insertions(+), 4 deletion
These patches add support for Display-Port driver on SnapDragon 845 hardware.
It adds
DP driver and DP PLL driver files along with the needed device-tree bindings.
The block diagram of DP driver is shown below:
+-+
|DRM FRAMEWORK|
+
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Signed-off-by: Chandan Uddaraju
---
drivers/gpu/drm/msm/Kconfig | 16 +
drivers/gpu/
On Wed, Oct 10, 2018 at 10:15:57AM -0700, Chandan Uddaraju wrote:
> Add bindings for Snapdragon 845 DisplayPort and
> display-port PLL driver.
>
This won't get Rob Herring's review unless it's sent to the devicetree list.
> Signed-off-by: Chandan Uddaraju
> ---
> .../devicetree/bindings/displa
On 2018-10-10 10:15, Chandan Uddaraju wrote:
These patches add support for Display-Port driver on SnapDragon 845
hardware. It adds
DP driver and DP PLL driver files along with the needed device-tree
bindings.
The block diagram of DP driver is shown below:
+-+
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #39 from Martin Pilarski ---
I can confirm that the issue is fixed with the initial fix.
glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-de
On Tue, Oct 09, 2018 at 04:44:24PM -0400, Lyude Paul wrote:
> It appears when testing my previous fix for some of the legacy
> modesetting issues with MST, I misattributed some kernel splats that
> started appearing on my machine after a rebase as being from upstream.
> But it appears they actually
On 2018-10-10 07:29, Sean Paul wrote:
On Tue, Oct 09, 2018 at 10:46:41PM -0700, Jeykumar Sankaran wrote:
On 2018-10-09 11:07, Sean Paul wrote:
> On Mon, Oct 08, 2018 at 09:27:18PM -0700, Jeykumar Sankaran wrote:
> > Layer mixer/pingpong block counts and hw ctl block counts
> > will not be same f
On 2018-10-10 07:36, Sean Paul wrote:
On Tue, Oct 09, 2018 at 11:03:24PM -0700, Jeykumar Sankaran wrote:
On 2018-10-09 12:57, Sean Paul wrote:
> On Mon, Oct 08, 2018 at 09:27:41PM -0700, Jeykumar Sankaran wrote:
> > Since HW reservations are happening through atomic_check
> > and all the display
On Wed, Oct 10, 2018 at 10:15:58AM -0700, Chandan Uddaraju wrote:
> Add the needed displayPort files to enable DP driver
> on msm target.
>
> "dp_display" module is the main module that calls into
> other sub-modules. "dp_drm" file represents the interface
> between DRM framework and DP driver.
>
1 - 100 of 175 matches
Mail list logo
