Am 21.10.19 um 20:09 schrieb Navid Emamdoost:
> In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
> and returns an errno, before returning the allocated memory for fence
> should be released.
>
> Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
> Si
On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> Add support in CMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_cma_dumb_create() always creates a kernel mapping as
> before. drm_gem_cma_dumb_create_
https://bugzilla.kernel.org/show_bug.cgi?id=204965
--- Comment #3 from David (dav@gmx.com) ---
Thanks for the replies. Yes, looks like a dupe; I'll try to apply the last
patch attached as soon as I've read up on how patch works. You can close this I
guess.
--
You are receiving this mail beca
We get these warnings when build kernel W=1:
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes]
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no previous
prototype for ‘panfrost_perfcnt_sampl
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v3:
* Fix typo in comments
Cc: Juston Li
Cc: Imre Deak
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry We
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref tr
Does what it says on the tin.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
d
Currently, we enable hotplug detection only after we re-enable the
display. However, this is too late if we're planning on sending sideband
messages during the resume process - which we'll need to do in order to
reprobe the topology on resume.
So, enable hotplug events before reinitializing the di
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when updatin
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then there
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both o
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Note that we already do this in delayed_destroy_work (renamed from
destroy_connector_work in
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging ti
Currently, MST lacks locking in a lot of places that really should have
some sort of locking. Hotplugging and link address code paths are some
of the offenders here, as there is actually nothing preventing us from
running a link address probe while at the same time handling a
connection status upda
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold &mgr->lock, destroying MSTBs from this
context wo
This is the final portion of the large series for adding MST
suspend/resume reprobing that I've been working on for quite a while
now. In addition, I:
* Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
* Added s
On Tue, 22 Oct 2019 at 01:49, Sean Paul wrote:
>
> On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote:
> >
> > Hi,
> >
> > On 18/10/2019 23:11, Sean Paul wrote:
> > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> > > wrote:
> > >>
> > >> Hi Sean,
> > >>
> > >> On 17/10/2019 22:26, Sean Pau
On Mon, Oct 21, 2019 at 01:48:35PM -0400, Sean Paul wrote:
> On Mon, Oct 21, 2019 at 03:01:56PM +, Mihail Atanassov wrote:
> > I'll be the main point of contact.
> >
> > Cc: James Qian Wang (Arm Technology China)
> > Cc: Liviu Dudau
> > Signed-off-by: Mihail Atanassov
>
> Acked-by: Sean Pa
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option
https://bugs.freedesktop.org/show_bug.cgi?id=112008
--- Comment #6 from babblebo...@gmail.com ---
This may be useful to you!
[4.603742] [drm:amdgpu_dm_initialize_drm_device [amdgpu]]
amdgpu_dm_connector_init()
[4.604326] [drm:dm_dp_aux_transfer [amdgpu]] Op: Read, addr: , SideBand
Ms
On Mon, 07 Oct 2019, Ingo Molnar wrote:
I suppose this will be carried in -mm?
I've just sent out a new patchset for -tip that only modified the pat
tree. It seems that this series will at least take some more time due to
the mmu_notifier rework being done - and there was some worries about
the
Hi!
On Tue, 2019-10-22 at 07:44:26 +1100, Stephen Rothwell wrote:
> Fixes tag
>
> Fixes: 7a074e96 ("aio: implement io_pgetevents")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
> Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> or late
Hi all,
[Some people didn't get this due to a typo]
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning
On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The only two users of this are now converted to use mmu_range_notifier,
> > delete all the code and update hmm.rst.
>
> I guess i sh
On Wed, Oct 16, 2019 at 06:35:15AM +, Oleksandr Andrushchenko wrote:
> On 10/16/19 8:11 AM, Jürgen Groß wrote:
> > On 15.10.19 20:12, Jason Gunthorpe wrote:
> >> From: Jason Gunthorpe
> >>
> >> DMA_SHARED_BUFFER can not be enabled by the user (it represents a
> >> library
> >> set in the kern
On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > Since that reader is not locked we need release semantics here to
> > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > structure when it observes the pointer.
>
> I thought the mm_take_all_locks() would have
On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> > On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
> >
> >>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
> >>> called while holding mm->m
On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
> > +/**
> > + * mmu_range_read_retry - End a read side critical section against a VA
> > range
> > + * mrn: The range under lock
> > + * seq: The return of the paired mmu_range_read_begin()
> > + *
> > + * This MUST be called under a
On Mon, Oct 21, 2019 at 02:28:46PM +, Koenig, Christian wrote:
> Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> > On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> >> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> >>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christ
On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote:
> On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
> > This is still being tested, but I figured to send it to start getting help
> > from the xen, amd and hfi drivers which I cannot test here.
>
> Sorry for the delay, I never seen t
On Mon, Oct 21, 2019 at 02:40:41PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> > scif_dma, vhost, gntdev, hmm) drivers are using a commo
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter. Remove it, as the cast prevents
further compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
Hi all,
Casting parameters in debugfs_create_*() calls prevents the compiler
from performing some checks.
Hence this patch series removes superfluous casts, or reworks code to no
longer need the casts.
All patches can be applied independently, there are no dependencies.
Thanks for your c
In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
and returns an errno, before returning the allocated memory for fence
should be released.
Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/am
* Adam Ford [191016 06:53]:
> With the removal of the panel-dpi from the omap drivers, the
> LCD no longer works. This patch points the device tree to
> a newly created panel named "logicpd,type28"
>
> Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
>
> Signed-off-by: Adam Ford
> Ack
pon., 21 paź 2019 o 12:45 Daniel Thompson
napisał(a):
>
> On Sat, Oct 19, 2019 at 10:35:50AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > The GPIO backlight driver currently requests the line 'as is', without
> > acively setting its direction. This can lead to problems:
This series adds support for CMA/DMA users to skip kernel mappings for
GEM allocations. The DMA API only guarantees a kernel mapping at
allocation time. Creating mappings with vmap() after allocation may or
may not work as not all allocations have a struct page. As virtual
memory space is limited o
Now that we have the DRM_MODE_DUMB_KERNEL_MAP flag to indicate whether
or not a kernel mapping is required, the Rockchip driver can be
converted to using the generic fbdev emulation.
This patch makes full use of the generic fbdev emulation by using its
drm_client callbacks. This means that
drm_mod
In preparation to allow DRM CMA users to adjust the DMA_ATTR_* flags,
convert the CMA helper code to use the dma_*_attr APIs instead of the
dma_*_wc variants.
Only the DMA_ATTR_WRITE_COMBINE and DMA_ATTR_NO_WARN attributes are set
in this commit, so there's no functional change.
Cc: Maarten Lankh
The only reason the Mediatek driver doesn't use the CMA helpers is it
sets DMA_ATTR_NO_KERNEL_MAPPING and does a vmap() on demand. Using
vmap() is not even guaranteed to work as DMA buffers may not have a
struct page. Now that the CMA helpers support setting
DMA_ATTR_NO_KERNEL_MAPPING as needed or
drm_gem_cma_dumb_create_internal() is not supposed to be used for
.dumb_create directly. drm_gem_cma_dumb_create() should be used instead.
If we do that, we might as well convert over to using
DRM_GEM_CMA_VMAP_DRIVER_OPS instead.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
drm_mode_create_dumb. This flag is for internal kernel use to indicate
if dumb buffer allocation needs a kernel mapping. This is needed only for
CMA where creating a kernel mapping or not has to be decided at allocation
time because creatin
Add support in CMA helpers to handle callers specifying
DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
change. drm_gem_cma_dumb_create() always creates a kernel mapping as
before. drm_gem_cma_dumb_create_internal() lets the caller set the flags
as desired. Therefore, updat
In the implementation of nouveau_bo_alloc() if it fails to determine the
target page size via pi, then the allocated memory for nvbo should be
released.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/nouveau/nouveau
Hi all,
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from inc
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
f
> In the impelementation of v3d_submit_cl_ioctl() there are two memory leaks.
Please avoid another typo also in this change description.
> … If kcalloc fails to allocate memory for bin then
> render->base should be put. Also, if v3d_job_init() fails to initialize
> bin->base then allocated memor
On Mon, Oct 21, 2019 at 07:24:53PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > > Since that reader is not locked we need release semantics here to
> > > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > > structure when i
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so plu
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so plu
On Mon, Oct 21, 2019 at 06:57:42PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> > On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > > From: Jason Gunthorpe
> > >
> > > The only two users of this are now converted to use mmu_ra
On Mon, Oct 21, 2019 at 06:54:25PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
>
> > > +/**
> > > + * mmu_range_read_retry - End a read side critical section against a VA
> > > range
> > > + * mrn: The range under lock
> > > + * seq: The return o
On Mon, Oct 21, 2019 at 12:03 PM John Stultz wrote:
>
> Lucky number 13! :)
>
> Last week in v12 I had re-added some symbol exports to support
> later patches I have pending to enable loading heaps from
> modules. He reminded me that back around v3 (its been awhile!) I
By "He" I mean Brian here.
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Lucky number 13! :)
Last week in v12 I had re-added some symbol exports to support
later patches I have pending to enable loading heaps from
modules. He reminded me that back around v3 (its been awhile!) I
had removed those exports due to concerns about the fact that we
don't support module remova
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds th
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cr
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
C
Le mer. 9 oct. 2019 à 09:13, Benjamin Gaignard
a écrit :
>
> Few for_each macro set variables that are never used later which led
> to generate unused-but-set-variable warnings.
> Add (void)(foo) inside the macros to remove these warnings
>
Gentle ping,
Thanks,
Benjamin
> Signed-off-by: Benjamin
In the impelementation of v3d_submit_cl_ioctl() there are two memory
leaks. One is when allocation for bin fails, and the other is when bin
initialization fails. If kcalloc fails to allocate memory for bin then
render->base should be put. Also, if v3d_job_init() fails to initialize
bin->base then a
On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_range_start/end and immediatel
On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The only two users of this are now converted to use mmu_range_notifier,
> delete all the code and update hmm.rst.
I guess i should point out that the reasons for hmm_mirror and hmm
was for:
1) Maybe
On Tue, Oct 15, 2019 at 03:12:30PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_mirror's handling of ranges does not use a sequence count which
> results in this bug:
>
> CPU0 CPU1
> hmm_range_wait_u
On Mon, Oct 21, 2019 at 2:36 AM Brian Starkey wrote:
> On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote:
> > On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> > > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> > >
> > > As in v3:
> > >
> > > * Avoid EXPORT_SYMBOL
On Tue, Oct 15, 2019 at 03:12:28PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead f
On Tue, Oct 15, 2019 at 03:12:31PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Only the function calls are stubbed out with static inlines that always
> fail. This is the standard way to write a header for an optional component
> and makes it easier for drivers that only optionally
On Tue, Oct 15, 2019 at 03:12:29PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Of the 13 users of mmu_notifiers, 8 of them use only
> invalidate_range_start/end() and immediately intersect the
> mmu_notifier_range with some kind of internal list of VAs. 4 use an
> interval tree (i9
Based on work by Bjorn Andersson
The bridge can be configured to use 1, 2, or 4 DP lanes. This
configuration is independent of the input DSI lanes. Right now, the
driver assumes that there is 1:1 mapping of input lanes to output lanes
which is not correct and does not work for manu devices such
On Mon, Oct 21, 2019 at 03:01:56PM +, Mihail Atanassov wrote:
> I'll be the main point of contact.
>
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Signed-off-by: Mihail Atanassov
Acked-by: Sean Paul
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff
> Am 21.10.2019 um 19:25 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191021 15:46]:
>>> Am 21.10.2019 um 17:07 schrieb Rob Herring :
>>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
>>> wrote:
+Optional properties:
+- timer: the timer to be used by the driver.
ba6fa6e905d8fe81da4591d3e7a65878:
drm/i915: Update DRIVER_DATE to 20191021 (2019-10-21 12:56:07 +0300)
UAPI Changes:
- Introduce a versioning of the i915-perf uapi (Lionel)
- Add support for perf configuration queries (Lionel)
Allow li
On Mon, Oct 21, 2019 at 01:47:19PM -0400, Sean Paul wrote:
> On Mon, Oct 21, 2019 at 06:34:25PM +0200, Stephan Gerhold wrote:
> > The DSI PHY regulator supports two regulator modes: LDO and DCDC.
> > This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
> > device tree property.
> >
On Mon, Oct 21, 2019 at 06:34:25PM +0200, Stephan Gerhold wrote:
> The DSI PHY regulator supports two regulator modes: LDO and DCDC.
> This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
> device tree property.
>
> However, at the moment only the 20nm PHY driver actually implemen
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #4 from tempel.jul...@gmail.com ---
Thanks for the hint @ Andrew Sheldon, SPPT being possible on Linux totally
passed me by. Will test it with my cheap Polaris card first, which made me
stick with custom fan curve anyway.
Regarding t
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #3 from zamundaa...@gmail.com ---
I have the same (or at least a similar) bug.
/sys/class/drm/card1/device/hwmon/hwmon3/power1_cap_max in my case gives the
default 220W (value: 22000).
$ cat /sys/class/drm/card0/device/pp_od_clk_v
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +Optional properties:
> >> +- timer: the timer to be used by the driver.
> >
> > Needs a better description and vendor prefix at
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +- reg: Physical base addresses and lengths of the register areas.
> >
> > How many?
>
> I assume there is only one. At least
On 10/21/19 4:50 PM, Daniel Vetter wrote:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I haven't checke
Extra detail (normally off) almost never hurts.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 11 +++
drivers/gpu/drm/arm/display/komeda/komeda_event.c | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/
It's possible to get multiple events in a single frame/flip, so add an
option to print them all.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 ++
drivers/gpu/drm/arm/display/komeda/komeda_event.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-
It's potentially useful information when diagnosing error/warn IRQs, so
dump it to dmesg with a drm_info_printer. Hide this extra debug dumping
behind another komeda_dev->err_verbosity bit.
Note that there's not much sense in dumping it for INFO events,
since the VSYNC event will swamp the log.
S
Named 'err_verbosity', currently with only 1 active bit in that
replicates the existing level - print error events once per flip.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 14 --
Now that there's a debugfs node to control the same, remove the
config option.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/Kconfig | 6 --
drivers/gpu/drm/arm/display/komeda/Makefile | 5 ++---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 6 --
3
Hi everyone,
This is a smallish series that tries to remove some build-time
configurability in komeda and replace it with a debugfs control. Later
patches in the series add some extra functionality which I found useful
during my debugging sessions, so I figured I'd bake it in.
I've preserved the
The DSI PHY regulator supports two regulator modes: LDO and DCDC.
This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
device tree property.
However, at the moment only the 20nm PHY driver actually implements
that option. Add a check in the 28nm PHY driver to program the
registers
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #117 from har...@gmx.de ---
...are this craches more frequently with VSYNC enabled?
If yes, it could be the same thing like this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=110777
--
You are receiving this mail because:
You
Convert generic PWM controller bindings to DT schema format using
json-schema. The consumer bindings are provided by dt-schema.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Stephen Boyd
Acked-by: Paul Walmsley
---
Changes since v3:
1. Remove pwm-consumers.yaml as they do not give anything ne
Convert Samsung PWM (S3C, S5P and Exynos SoCs) bindings to DT schema
format using json-schema.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
---
Changes since v3:
1. Add reviewed-by.
Changes since v2:
1. Add additionalProperties: false.
Changes since v1:
1. Indent example with
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
This is still being tested, but I figured to send it to start getting help
from the xen, amd and hfi drivers which I cannot test here.
Sorry for the delay, I never seen this. Was not on Cc list and didn't
register to me it impacted hfi. I'll take a
On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 18/10/2019 23:11, Sean Paul wrote:
> > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> > wrote:
> >>
> >> Hi Sean,
> >>
> >> On 17/10/2019 22:26, Sean Paul wrote:
> >>
> >>> concern for those. The omap OMAP_BO_MEM_* changes th
On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote:
> On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg
> wrote:
> >
> > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote:
> > > > I really would like to provide you more information about such
> > > > workaround but I'm not aware
Hi Rob,
> Am 21.10.2019 um 17:07 schrieb Rob Herring :
>
> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> wrote:
>>
>> The Imagination PVR/SGX GPU is part of several SoC from
>> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
>> and others.
>>
>> Here we describe how the
On 2019-10-21 11:03 a.m., Siqueira, Rodrigo wrote:
> Commit d7cd0e05 introduced a change at DP_DSC_THROUGHPUT_MODE_0_170
> which is not aligned with the spec. This commit replace 15 << 4 by
> 15 << 0 for DP_DSC_THROUGHPUT_MODE_0_170 in order to make it follow the
> specification.
>
> Cc: Harry Wen
Remove unneeded indentation in blank line and space at end of line.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/st,stm32-dsi.yaml | 2 +-
Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
d
On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller wrote:
>
> The Imagination PVR/SGX GPU is part of several SoC from
> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
> and others.
>
> Here we describe how the SGX processor is interfaced to
> the SoC (registers, interrupt etc.).
>
On Fri, Oct 18, 2019 at 1:24 PM Linus Walleij wrote:
>
> This adds a starting point for processing and defining generic
> bindings used by DSI panels. We just define one single bool
> property to force the panel into video mode for now.
>
> Cc: devicet...@vger.kernel.org
> Suggested-by: Rob Herrin
1 - 100 of 185 matches
Mail list logo