On Fri, Oct 25, 2019 at 4:32 PM Rob Herring wrote:
>
> On Fri, Oct 25, 2019 at 5:51 PM John Stultz wrote:
> >
> > This binding specifies which CMA regions should be added to the
> > dmabuf heaps interface.
>
> Is this an ION DT binding in disguise? I thought I killed that. ;)
Maybe? I may not
Allow loading system and cma heap as a module instead of just as
a statically built in heap.
Since there isn't a good mechanism for dmabuf lifetime tracking
it isn't safe to allow the heap drivers to be unloaded, so these
drivers do not implement any module unloading functionality and
will show
Now that the DMA BUF heaps core code has been queued, I wanted
to send out some of the pending changes that I've been working
on.
For use with Android and their GKI effort, it is desired that
DMA BUF heaps are able to be loaded as modules. This is required
for migrating vendors off of ION which
From: Sandeep Patil
Export cma_get_name, cma_alloc, cma_release, cma_for_each_area
and dma_contiguous_default_area so that we can use these from
the dmabuf cma heap when it is built as module.
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian
This binding specifies which CMA regions should be added to the
dmabuf heaps interface.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Chenbo Feng
Cc: Alistair Strachan
In earlier versions of the dmabuf CMA heap, we added all CMA
areas as CMA heaps. Andrew noted this might not be desired,
and so we changed the code to only add the default CMA area.
This patch extends the earlier effort so that devices can
specifiy which CMA areas they want to add as dmabuf heaps
Adds example test entry to create and expose a camera cma region
via the dmabuf heaps interface
This isn't a patch I'm submitting to merge, but just an example
of how this functionality can be used, which I've used for
testing.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Laura Abbott
Cc: Benjamin
Now that the dmabuf heaps core code has been queued, I wanted to
submit for initial review some of the changes I have pending.
In previous versions, the dmabuf CMA heap added all CMA areas to
the dmabuf heaps interface. However, Andrew noted this may not
be desirable, so I've come up with a DT
Hi Dave, Daniel,
More new stuff for 5.5. I tested a back merge and it was clean.
The following changes since commit 1cd4d9eead73c004d08a58536dc726bd172eaaec:
drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)
are available in the Git repository at:
https://bugs.freedesktop.org/show_bug.cgi?id=112134
--- Comment #1 from Alex Deucher ---
You can grab the missing firmware from the linux firmware tree:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
--
You are receiving this mail because:
You are the
Applied. Thanks!
Alex
On Wed, Oct 23, 2019 at 11:09 AM Harry Wentland wrote:
>
> On 2019-10-19 3:32 a.m., Wambui Karuga wrote:
> > Remove unnecessary assignment for return value and have the
> > function return the required value directly.
> > Issue found by coccinelle:
> > @@
> > local
On Wed, 23 Oct 2019 17:45:11 +0200, Boris Brezillon wrote:
> The LTA089AC29000 and LT089AC29000 are not exactly the same. Let's add
> a new compatible for the LTA variant.
>
> Signed-off-by: Boris Brezillon
> ---
> .../bindings/display/panel/toshiba,lt089ac29000.txt | 5 -
> 1 file
On Thu, Oct 24, 2019 at 03:06:37PM +, Harry Wentland wrote:
> On 2019-10-23 8:00 p.m., Manasi Navare wrote:
> > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > Store this info as part fo
On Wed, Oct 23, 2019 at 05:45:08PM +0200, Boris Brezillon wrote:
> Add the data-mapping property to describe the output bus format and
> the bus-width property to describe the input bus format.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * New patch
> ---
>
Hi Linus,
Quiet week this week, which I suspect means some people just didn't
get around to sending me fixes pulls in time. This has 2 komeda and a
bunch of amdgpu fixes in it.
Thanks,
Dave.
drm-fixes-2019-10-25:
drm fixes for v5.4-rc5
komeda:
- typo fixes
- flushing pipes fix
amdgpu:
- Fix
https://bugs.freedesktop.org/show_bug.cgi?id=112134
--- Comment #2 from Samuele Decarli ---
Arch just updated their linux-firmware package: it now includes the missing
firmware, fixing the issue.
Thank you for your help though.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=112134
Samuele Decarli changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
The pull request you sent on Sat, 26 Oct 2019 05:31:01 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8caacaad78b69c4329c2ae9341ae7268ecfbf475
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Oct 25, 2019 at 09:23:47PM +0200, Hans de Goede wrote:
> Hi,
>
> On 21-10-2019 16:39, Ville Syrjälä wrote:
> > On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:
> >> Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
> >> vblank waits"), I am seeing an
On Fri, Oct 25, 2019 at 12:12:23PM +0200, Julia Lawall wrote:
>
>
> On Fri, 25 Oct 2019, Wambui Karuga wrote:
>
> > Replace open coded divisor calculations with the DIV_ROUND_UP kernel
> > macro for better readability.
> > Issue found using coccinelle:
> > @@
> > expression n,d;
> > @@
> > (
>
Applied. thanks!
Alex
On Wed, Oct 23, 2019 at 9:35 AM Harry Wentland wrote:
>
> On 2019-10-23 4:32 a.m., zhongshiqi wrote:
> > dc.c:583:null check is needed after using kzalloc function
> >
> > Signed-off-by: zhongshiqi
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> >
On Thu, Oct 24, 2019 at 01:43:04PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Sony ACX424AKP panel.
> Let's use YAML.
Also broken. Run 'make dt_binding_check'.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v3->v4:
> - Adjust to
Hi,
On 21-10-2019 16:39, Ville Syrjälä wrote:
On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices
On Sat, Oct 19, 2019 at 8:07 PM Chen Wandun wrote:
>
> From: Chenwandun
>
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c: In function
> dce_aux_configure_timeout:
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c: warning: variable timeout set
> but not used [-Wunused-but-set-variable]
>
>
On Thu, Oct 24, 2019 at 01:43:03PM +0200, 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:
On Mon, Oct 21, 2019 at 06:28:18AM +, Lin, Wayne wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, October 14, 2019 10:42 PM
> > To: Lin, Wayne
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > Subject: Re: [PATCH 4/4] drm/edid:
On Fri, Oct 25, 2019 at 10:08 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 25.10.19 um 09:47 schrieb Daniel Vetter:
> > On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
> >> Signed-off-by: Thomas Zimmermann
> >> ---
> >> drivers/gpu/drm/udl/udl_drv.c | 3 +
> >>
On Fri, Oct 25, 2019 at 1:36 PM Thierry Reding wrote:
>
> On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> > Hi,
> >
> > Thanks for your review and comments. Please see inline below.
> >
> > On Thu, Oct 24, 2019 at 4:20 AM Thierry Reding
> > wrote:
> > >
> > > On Tue, Oct 22, 2019
On Fri, Oct 25, 2019 at 7:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 25.10.19 um 17:46 schrieb Noralf Trønnes:
> >
> >
> > Den 25.10.2019 11.27, skrev Thomas Zimmermann:
> >> There are no users of drm_fb_helper_defio_init(), so we can remove
> >> it. The documenation around defio support is a
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by:
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DCDC1 as VDD supply
- PD7 gpio for lcd enable pin
- PD6 gpio for lcd reset pin
- PD5 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So add has_mod_clk quirk and process the mod clk accordingly.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
to have separate compatible for A64 on the same driver.
DSI_SCLK uses mod clock-names on dt-bindings, so the same
is not required for A64.
On that note
- A64 require
The MIPI DSI PHY controller on Allwinner A64 is similar
on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Signed-off-by: Jagan Teki
---
.../bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
1
Usage of clocks are varies between different Allwinner
DSI controllers. Clocking in A33 would need bus and
mod clocks where as A64 would need only bus clock.
To support this kind of clocking structure variants
in the same dsi driver, explicit handling of common
clock would require since the A64
This is v11 version for Allwinner A64 MIPI-DSI support
and here is the previous version set[1]
Changes for v11:
- fix dt-bindings for dphy
- fix dt-bindings for dsi controller
- add bus clock handling code
- tested on A64, A33 boards.
Changes for v10:
- updated dt-bindings as per .yaml format
-
Hi
Am 25.10.19 um 17:46 schrieb Noralf Trønnes:
>
>
> Den 25.10.2019 11.27, skrev Thomas Zimmermann:
>> There are no users of drm_fb_helper_defio_init(), so we can remove
>> it. The documenation around defio support is a bit misleading and
>> should mention compatibility issues with SHMEM
From: Colin Ian King
The variable ret is being assigned with a value that
is never read and is being re-assigned on the next statement.
The assignment is redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
https://bugzilla.kernel.org/show_bug.cgi?id=204559
the...@gmail.com changed:
What|Removed |Added
CC||the...@gmail.com
--- Comment #12 from
On Fri, Oct 25, 2019 at 09:30:03PM +0800, Cheng-Yi Chiang wrote:
> There will be multiple boards sharing this machine driver.
> Use compatible string to specify the use case.
>
> "rockchip,rockchip-audio-max98090" for max98090-only.
> "rockchip,rockchip-audio-hdmi" for HDMI-only
>
On 2019-10-25 6:18 p.m., Will Deacon wrote:
> On Fri, Oct 25, 2019 at 06:06:26PM +0200, Michel Dänzer wrote:
>> On 2019-10-25 1:04 p.m., Will Deacon wrote:
>>> In the highly unlikely event that we fail to allocate the "radeon-crtc"
>>> workqueue, we should bail cleanly rather than blindly march on
On Fri, Oct 25, 2019 at 06:06:26PM +0200, Michel Dänzer wrote:
> On 2019-10-25 1:04 p.m., Will Deacon wrote:
> > In the highly unlikely event that we fail to allocate the "radeon-crtc"
> > workqueue, we should bail cleanly rather than blindly march on with a
> > NULL pointer installed for the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #175 from Marko Popovic ---
(In reply to Shmerl from comment #174)
> Is it public? I can't join the room.
https://matrix.to/#/!XvwReLqAqwRmEzgmVh:matrix.org?via=matrix.org
Sorry, this should work
--
You are receiving this mail
On 2019-10-25 1:04 p.m., Will Deacon wrote:
> In the highly unlikely event that we fail to allocate the "radeon-crtc"
> workqueue, we should bail cleanly rather than blindly march on with a
> NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
> structure.
>
> This was reported
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #174 from Shmerl ---
Is it public? I can't join the room.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Am 25.10.19 um 17:56 schrieb Grodzovsky, Andrey:
> On 10/25/19 11:55 AM, Koenig, Christian wrote:
>> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>>> On 10/25/19 4:44 AM, Christian König wrote:
Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
> Problem:
> When run_job fails and HW
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #173 from Marko Popovic ---
https://matrix.to/#/!UiDmeMlfsLndmzmPhp:matrix.org?via=matrix.org
Here is a link to Matrix community, anyone interested should try to join.
--
You are receiving this mail because:
You are the assignee
On 10/25/19 11:55 AM, Koenig, Christian wrote:
> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>> On 10/25/19 4:44 AM, Christian König wrote:
>>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence
Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
> On 10/25/19 4:44 AM, Christian König wrote:
>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>> Problem:
>>> When run_job fails and HW fence returned is NULL we still signal
>>> the s_fence to avoid hangs but the user has no way of knowing if
Den 25.10.2019 11.27, skrev Thomas Zimmermann:
> The TODO item is misleading and makes it seem that fbdev emulation
> cannot be used with SHMEM. Rephrase the text to describe the current
> situation more correctly.
>
> Signed-off-by: Thomas Zimmermann
> ---
> Documentation/gpu/todo.rst | 8
Den 25.10.2019 11.27, skrev Thomas Zimmermann:
> There are no users of drm_fb_helper_defio_init(), so we can remove
> it. The documenation around defio support is a bit misleading and
> should mention compatibility issues with SHMEM helpers. Clarify this.
>
> Signed-off-by: Thomas Zimmermann
>
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #172 from Marko Popovic ---
(In reply to Shmerl from comment #171)
> (In reply to Marko Popovic from comment #170)
> > By the way if anyone is up for it, we can make a dedicated Discord chat room
> > for Navi linux users, so we
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #171 from Shmerl ---
(In reply to Marko Popovic from comment #170)
> By the way if anyone is up for it, we can make a dedicated Discord chat room
> for Navi linux users, so we don't bloat this bugtracker, since a lot of the
>
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #6 from tempel.jul...@gmail.com ---
Tested custom soft power play table via UPP on Polaris and it generally seems
to work well (might be able to test Navi at a later time).
However, there is the issue that the voltage gets reset
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #170 from Marko Popovic ---
By the way if anyone is up for it, we can make a dedicated Discord chat room
for Navi linux users, so we don't bloat this bugtracker, since a lot of the
comments are just random questions etc. Let me know
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #169 from Marko Popovic ---
(In reply to L.S.S. from comment #168)
> For the 5.4 kernel, I'm running 5.4-rc2 (from official Manjaro repo). Not
> sure when Manjaro Stable will receive its next update regarding kernels...
You can
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #168 from L.S.S. ---
For the 5.4 kernel, I'm running 5.4-rc2 (from official Manjaro repo). Not sure
when Manjaro Stable will receive its next update regarding kernels...
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #167 from Shmerl ---
(In reply to Marko Popovic from comment #166)
> when has it been accepted upstream?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7557d2783850eec199cae78dac561e9b7de181be
--
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #166 from Marko Popovic ---
(In reply to Shmerl from comment #165)
> (In reply to L.S.S. from comment #163)
> > This was captured on 5.4(rc)
>
> Just to clarify, do you have all the mentioned patches above applied?
> 5.4-rc4
On Fri, Oct 25, 2019 at 9:39 AM Geert Uytterhoeven wrote:
>
> Hi Rob,
>
> On Fri, Oct 25, 2019 at 4:25 PM Rob Herring wrote:
> > On Fri, Oct 25, 2019 at 8:07 AM Geert Uytterhoeven
> > wrote:
> > > On Fri, Jul 5, 2019 at 6:46 PM Rob Herring wrote:
> > > > Convert the common panel bindings to
On 10/25/19 4:44 AM, Christian König wrote:
> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>> Problem:
>> When run_job fails and HW fence returned is NULL we still signal
>> the s_fence to avoid hangs but the user has no way of knowing if
>> the actual HW job was ran and finished.
>>
>> Fix:
Hi
Am 25.10.19 um 15:32 schrieb Gerd Hoffmann:
> Hi,
>
>>> I had a flag to set this in the initial version of the shmem helper
>>> modeled after udl, but Thomas Hellstrom brought up a question and it was
>>> dropped. The issue was beyond my understanding:
>>>
>>> [PATCH v3 0/2] drm: Add shmem
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #165 from Shmerl ---
(In reply to L.S.S. from comment #163)
> This was captured on 5.4(rc)
Just to clarify, do you have all the mentioned patches above applied? 5.4-rc4
already includes the mask patch, but not the other two.
--
Hi Rob,
On Fri, Oct 25, 2019 at 4:25 PM Rob Herring wrote:
> On Fri, Oct 25, 2019 at 8:07 AM Geert Uytterhoeven
> wrote:
> > On Fri, Jul 5, 2019 at 6:46 PM Rob Herring wrote:
> > > Convert the common panel bindings to DT schema consolidating scattered
> > > definitions to a single schema
On 23/10/2019 17:45, Boris Brezillon wrote:
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding
On 23/10/2019 17:45, Boris Brezillon wrote:
> So that bridge drivers have a way to check/reject an atomic operation.
> The drm_atomic_bridge_chain_check() (which is just a wrapper around
> the ->atomic_check() hook) is called in place of
> drm_bridge_chain_mode_fixup() (when ->atomic_check() is
On 23/10/2019 17:45, Boris Brezillon wrote:
> Will be useful for bridge drivers that want to do bus format
> negotiation with their neighbours.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * Inline drm_bridge_chain_get_prev_bridge()
> * Fix the doc
>
> Changes in v2:
> * Fix the
On 23/10/2019 17:45, Boris Brezillon wrote:
> The [pre_]enable/[post_]disable hooks are passed the old atomic state.
> Update the doc and rename the arguments to make it clear.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * New patch
> ---
> drivers/gpu/drm/drm_bridge.c | 24
On Fri, Oct 25, 2019 at 8:07 AM Geert Uytterhoeven wrote:
>
> Hi Rob,
>
> On Fri, Jul 5, 2019 at 6:46 PM Rob Herring wrote:
> > Convert the common panel bindings to DT schema consolidating scattered
> > definitions to a single schema file.
> >
> > The 'simple-panel' binding just a collection of
On Wed, Oct 23, 2019 at 06:56:17PM +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
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Emily Deng
[ Upstream commit 526c654a8a0641d4289bf65effde4d6095bd8384 ]
Issue:
Will have follow error when reload driver:
[ 3986.567739] sysfs: cannot create duplicate filename
'/devices/pci:00/:00:07.0/drm_dp_aux_dev'
[ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G
Den 25.10.2019 14.20, skrev Thomas Zimmermann:
> (cc: Gerd)
>
> Hi
>
> Am 25.10.19 um 13:44 schrieb Noralf Trønnes:
>>
>>
>> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Reviewed-by: Mark Brown
Reviewed-by: Tomeu Vizoso
Acked-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 60 -
Instead of tracking per-slot utilisation track a single value for the
entire GPU. Ultimately it doesn't matter if the GPU is busy with only
vertex or a combination of vertex and fragment processing - if it's busy
then it's busy and devfreq should be scaling appropriately.
This also makes way for
The devfreq implementation in panfrost is unnecessarily open coded. It
also tracks utilisation metrics per slot which isn't very useful. Let's
tidy it up!
Changes since v1:
http://lkml.kernel.org/r/20190912112804.10104-1-steven.price%40arm.com
* Rebased onto latest drm-misc-next, specifically
On 23/10/2019 17:44, Boris Brezillon wrote:
> So that each element in the chain can easily access its predecessor.
> This will be needed to support bus format negotiation between elements
> of the bridge chain.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
>
> Changes in
Hi,
> > I had a flag to set this in the initial version of the shmem helper
> > modeled after udl, but Thomas Hellstrom brought up a question and it was
> > dropped. The issue was beyond my understanding:
> >
> > [PATCH v3 0/2] drm: Add shmem GEM library
> >
On 23/10/2019 17:44, Boris Brezillon wrote:
> To iterate over all bridges attached to a specific encoder.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
>
> Changes in v2:
> * New patch
> ---
> include/drm/drm_bridge.h | 11 +++
> 1
On 23/10/2019 17:44, Boris Brezillon wrote:
> And use it in drivers accessing the bridge->next field directly.
> This is part of our attempt to make the bridge chain a double-linked list
> based on the generic list helpers.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * Inline
On 23/10/2019 17:44, Boris Brezillon wrote:
> We are about to replace the single-linked bridge list by a double-linked
> one based on list.h, leading to the suppression of the encoder->bridge
> field. But before we can do that we must provide a
> drm_bridge_chain_get_first_bridge() bridge helper
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #164 from L.S.S. ---
EDIT: Did some analysis myself about the GCVM_L2_PROTECTION_FAULT errors...
In the errors last time contained this:
src_id:0 ring:40 vmid:7 pasid:32769
GCVM_L2_PROTECTION_FAULT_STATUS:0x00741A51 (only on first
On 23/10/2019 17:44, Boris Brezillon wrote:
> Change the prefix of bridge helpers targeting a bridge chain from
> drm_bridge_ to drm_bridge_chain_ to better reflect the fact that
> the operation will happen on all elements of chain, starting at the
> bridge passed in argument.
>
> Signed-off-by:
On Fri, Oct 25, 2019 at 12:33 AM Maxime Ripard wrote:
>
> On Thu, Oct 24, 2019 at 01:28:28PM +0530, Jagan Teki wrote:
> > On Thu, Oct 17, 2019 at 3:22 PM Maxime Ripard wrote:
> > >
> > > On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:
> > > > On Wed, Oct 16, 2019 at 1:33 PM Maxime
https://bugs.freedesktop.org/show_bug.cgi?id=111481
L.S.S. changed:
What|Removed |Added
Attachment #145807|0 |1
is obsolete|
Hi Rob,
On Fri, Jul 5, 2019 at 6:46 PM Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
>
> The 'simple-panel' binding just a collection of properties and not a
> complete binding itself. All of the 'simple-panel'
(cc: Gerd)
Hi
Am 25.10.19 um 13:44 schrieb Noralf Trønnes:
>
>
> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
>>> wrote
Hi
Am 25.10.19 um 09:40 schrieb Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=108941
--- Comment #3 from brai...@gmail.com ---
Patch https://patchwork.freedesktop.org/patch/314322/ fixes this issue for me.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Thu, Oct 24, 2019 at 02:38:53PM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 11:48:01AM +0100, Colin King wrote:
> > From: Colin Ian King
> >
> > Two different fixes have addressed the same memory leak of bin and
> > this now causes a double free of bin. While the individual memory
On Thu, Oct 24, 2019 at 09:46:58PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 20:28, Thierry Reding пишет:
> > On Thu, Oct 24, 2019 at 07:31:19PM +0300, Dmitry Osipenko wrote:
> >> 24.10.2019 19:21, Dmitry Osipenko пишет:
> >>> 24.10.2019 19:09, Dmitry Osipenko пишет:
> 24.10.2019 18:57,
Den 25.10.2019 13.44, skrev Noralf Trønnes:
>
>
> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
>>> wrote
Hi
Am 25.10.19 um 09:40 schrieb Daniel Vetter:
> On
Den 25.10.2019 12.12, skrev Thomas Zimmermann:
> Hi
>
> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann wrote
>>>
>>> Hi
>>>
>>> Am 25.10.19 um 09:40 schrieb Daniel Vetter:
On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
Hi Noralf
Am 25.10.19 um 13:22 schrieb Noralf Trønnes:
>
>
> Den 25.10.2019 10.00, skrev Daniel Vetter:
>> On Fri, Oct 25, 2019 at 09:47:46AM +0200, Daniel Vetter wrote:
>>> On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
Signed-off-by: Thomas Zimmermann
---
On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> Hi,
>
> Thanks for your review and comments. Please see inline below.
>
> On Thu, Oct 24, 2019 at 4:20 AM Thierry Reding
> wrote:
> >
> > On Tue, Oct 22, 2019 at 05:12:06PM -0700, Rajat Jain wrote:
> > > Certain laptops now come
1 - 100 of 157 matches
Mail list logo
