Am 21.04.20 um 04:41 schrieb YueHaibing:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c: In function amdgpu_job_submit:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:148:26: warning: variable priority set
but not used [-Wunused-but-set-variable]
commit 33abcb1f5a17 ("drm/amdgpu: set compute queue priority a
Am 21.04.20 um 04:41 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
---
Changes since V1:
*commit message improve
*code style refactoring
Link for V1:
*
https://nam11.safelinks.protection.outlook.com/?url
20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
> Explicitly check if the imported buffer has been mapped as contiguous in
> the DMA address space, what is required by all Exynos DRM CRTC drivers.
> While touching this, set buffer flags depending on the availability of
> the IOMMU.
>
> Signed-off
On Wed, Apr 15, 2020 at 09:40:12AM +0200, Daniel Vetter wrote:
> Because it is.
Indeed.
Acked-by: Gerd Hoffmann
take care,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 15, 2020 at 09:40:34AM +0200, Daniel Vetter wrote:
> This is leftovers from the old drm_driver->load callback
> upside-down issues. It doesn't do anything for not-hotplugged
> connectors since drm_dev_register takes care of that.
>
> Signed-off-by: Daniel Vetter
> Cc: Gerd Hoffmann
>
Am 21.04.20 um 09:36 schrieb Bernard Zhao:
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and no need to protect pr_debug.
Well that change looks rather superfluous to me.
This is for freeing memory which by definition can only be done once and
so the should be exactl
Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > I think the the patch should be dropped for now before the issue is
> > properly addressed. Either by backporting the mainline fixes or if
> > those are too big and there indeed is a
On Mon, Apr 20, 2020 at 01:03:39PM -0700, John Stultz wrote:
> On Mon, Apr 20, 2020 at 1:22 AM Christian Brauner
> wrote:
> > On Thu, Apr 16, 2020 at 12:25:08PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> > > > But I do think we can mark it
Am 21.04.20 um 10:03 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Link for V1:
*https://nam11.safel
Hi Inki,
On 21.04.2020 09:38, Inki Dae wrote:
> 20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
>> Explicitly check if the imported buffer has been mapped as contiguous in
>> the DMA address space, what is required by all Exynos DRM CRTC drivers.
>> While touching this, set buffer flags depending o
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN_ON over WARN_ON.
>
> Signed-off-by: Pankaj Bharadiya
> ---
> drivers/gpu/drm/i915/i91
On Mon, 06 Apr 2020, Pankaj Bharadiya
wrote:
> struct drm_device specific drm_WARN* macros include device information
> in the backtrace, so we know what device the warnings originate from.
>
> Prefer drm_WARN_ON over WARN_ON.
>
> Conversion is done with below sementic patch:
>
> @@
> identifier
On Sat, Apr 18, 2020 at 02:39:17PM +0800, Caicai wrote:
> When a qxl resource is released, the list that needs to be released is
> fetched from the linked list ring and cleared. When you empty the list,
> instead of trying to determine whether the ttm buffer object for each
> qxl in the list is loc
On 2020-04-15 at 13:01:21 +0300, Jani Nikula wrote:
> On Tue, 07 Apr 2020, Jeevan B wrote:
> > From: Oleg Vasilev
> >
> > Currently, downstream port type is only reported in debugfs. This
> > information should be considered important since it reflects the actual
> > physical connector type. Some
On 2020-04-15 at 13:01:59 +0300, Jani Nikula wrote:
> On Tue, 07 Apr 2020, Jeevan B wrote:
> > From: Oleg Vasilev
> >
> > Since DP-specific information is stored in driver's structures, every
> > driver needs to implement subconnector property by itself.
> >
> > v2: updates to match previous comm
Am 21.04.20 um 10:44 schrieb 赵军奎:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..5424bd921a7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Bug ID: 207383
Summary: [Regression] 5.7-rc: amdgpu/polaris11 gpf:
amdgpu_atomic_commit_tail
Product: Drivers
Version: 2.5
Kernel Version: 5.7-rc1, 5.7-rc2
Hardware: Al
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #1 from Duncan (1i5t5.dun...@cox.net) ---
Created attachment 288651
--> https://bugzilla.kernel.org/attachment.cgi?id=288651&action=edit
automated boot-time dmesg dump
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Regression|No |Yes
--- Comment #2 from D
On Tue, Apr 21, 2020 at 11:24:39AM +0300, Jani Nikula wrote:
> On Mon, 06 Apr 2020, Pankaj Bharadiya
> wrote:
> > struct drm_device specific drm_WARN* macros include device information
> > in the backtrace, so we know what device the warnings originate from.
> >
> > Prefer drm_WARN_ON over WARN_O
Hi Kernel Janitors,
Here is another idea that someone could work on, fixing the
IS_ERR_OR_NULL() checks in the xen driver.
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen
On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
> > Add a new macro helper to combine the usual init sequence in drivers,
> > consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> > triplet. This allows us to remove the
On Tue, Apr 21, 2020 at 08:52:02AM +0300, Tomi Valkeinen wrote:
> On 20/04/2020 19:01, Daniel Thompson wrote:
> > On Fri, Apr 17, 2020 at 02:33:12PM +0300, Tomi Valkeinen wrote:
> > > led_bl_parse_levels() is rather difficult to follow. Rewrite it with a
> > > more obvious code flow.
> >
> > ... t
This converts the Synopsis MIPI DSI binding documentation to yaml and
should be quite straightforward. I've added a missing ref clk and also
added Philippe as maintainer b/c he's the original txt author following
the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org.
Cc: Rob Herr
On 15/04/2020 10:39, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 15 ---
1 file changed, 4
On 15/04/2020 10:39, Daniel Vetter wrote:
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_crtc
On 15/04/2020 10:40, Daniel Vetter wrote:
Not used anymore since the switch to suspend/resume helpers.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.h | 2 --
1 file changed, 2 deletions(-)
Am 21.04.20 um 13:17 schrieb Bernard Zhao:
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
NAK, failure to create sysfs nodes are not critical.
Christian.
Signed-off-by: Bernard
On 4/21/20 1:19 PM, Frederic Barrat wrote:
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 39eec9031487..a62795079d9c 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -19,6 +19,7 @@ config CXL
select CXL_BASE
select CXL_AFU_DRIVER_OPS
On 21/04/2020 13:48, Daniel Thompson wrote:
On Tue, Apr 21, 2020 at 08:52:02AM +0300, Tomi Valkeinen wrote:
On 20/04/2020 19:01, Daniel Thompson wrote:
On Fri, Apr 17, 2020 at 02:33:12PM +0300, Tomi Valkeinen wrote:
led_bl_parse_levels() is rather difficult to follow. Rewrite it with a
more ob
It turns out there aren't that many of these in xen.
$ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
drivers/gpu/drm/xen/xen_drm_front_gem.c:120:i
On 21/04/2020 14:26, Tomi Valkeinen wrote:
The led-backlight.txt is
a bit lacking (another thing to improve...) but led-backlight mimics
pwm-backlight, and pwm-backlight.txt says
default-brightness-level: The default brightness level (index into the array
defined by the "brightness-levels" prop
On Mon, Apr 20, 2020 at 01:04:20PM +0300, Pekka Paalanen wrote:
> On Mon, 20 Apr 2020 11:27:04 +0300
> Pekka Paalanen wrote:
>
> > On Fri, 17 Apr 2020 16:17:18 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > Hi,
> > > >
>
On Mon, Apr 20, 2020 at 12:21:24PM +0200, Neil Armstrong wrote:
> On 17/04/2020 20:14, Daniel Vetter wrote:
> > On Fri, Apr 17, 2020 at 6:05 PM Neil Armstrong
> > wrote:
> >>
> >> On 17/04/2020 17:07, Daniel Vetter wrote:
>
> [...]
>
> >
> > Yup there's a number of parametried modifiers. As lo
On Fri, Apr 17, 2020 at 02:18:11PM +0200, H. Nikolaus Schaller wrote:
> Hi Maxime,
> I have started to test v5.7-rc1 and can't fully boot the GTA04
> device any more.
>
> What I see in the log is:
>
> [ 28.567840] [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge
> driver to make c
On Mon, Apr 20, 2020 at 04:03:23PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 20, 2020 at 10:14 AM Jani Nikula
> wrote:
> > On Fri, 17 Apr 2020, Jason Gunthorpe wrote:
> > > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote:
> > >> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergman
On Fri, Apr 17, 2020 at 03:40:48PM -0400, Lyude Paul wrote:
> Since we'll be allocating resources for kthread_create_worker() in the
> next commit (which could fail and require us to clean up the mess),
> let's simplify the cleanup process a bit by registering a
> drm_vblank_init_release() action f
On Fri, Apr 17, 2020 at 05:03:56PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Apr 17, 2020 at 04:16:28PM -0400, Lyude Paul wrote:
> > Hey Tejun! So I ended up rewriting the drm_vblank_work stuff so that it used
> > kthread_worker. Things seem to work alright now. But while we're doing just
> > f
Hi,
On 4/17/20 1:55 PM, Jani Nikula wrote:
On Fri, 17 Apr 2020, Pekka Paalanen wrote:
On Wed, 15 Apr 2020 17:40:46 +0200
Hans de Goede wrote:
Hi,
On 4/15/20 5:28 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Hans de Goede wrote:
ii. Currently the "privacy-screen" property added by Rajat's
On Mon, Apr 20, 2020 at 05:00:59PM -0600, Jonathan Corbet wrote:
> On Mon, 20 Apr 2020 10:41:15 +0300
> Gal Pressman wrote:
>
> > Fix a couple of typos: "as" -> "has" and "int" -> "in".
> >
> > Signed-off-by: Gal Pressman
>
> Applied, thanks.
Also applied to drm-misc-next, the dma-buf stuff i
On Tue, Apr 21, 2020 at 02:37:41PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/17/20 1:55 PM, Jani Nikula wrote:
> > On Fri, 17 Apr 2020, Pekka Paalanen wrote:
> > > On Wed, 15 Apr 2020 17:40:46 +0200
> > > Hans de Goede wrote:
> > >
> > > > Hi,
> > > >
> > > > On 4/15/20 5:28 PM, Jani Nikula w
Hi Dave, Daniel,
just a friendly reminder to merge these changes. They don't seem to be
in the upstream tree yet.
Best regards
Thomas
Am 14.04.20 um 11:07 schrieb Thomas Zimmermann:
> Hi Dave, Daniel,
>
> with 5.7-rc1 being tagged, here's the first PR for drm-next-misc for what
> will become L
On Tue, Mar 24, 2020 at 04:19:31PM +0100, Lubomir Rintel wrote:
> This is a driver for video encoder with VGA and DVI/HDMI outputs.
>
> There is no documentation for the chip -- the operation was guessed from
> what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
> come from th
On Tue, 21 Apr 2020, Daniel Vetter wrote:
> On Mon, Apr 20, 2020 at 04:03:23PM +0200, Arnd Bergmann wrote:
>> On Mon, Apr 20, 2020 at 10:14 AM Jani Nikula
>> wrote:
>> > On Fri, 17 Apr 2020, Jason Gunthorpe wrote:
>> > > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote:
>> > >> On F
Also cc'ing a bunch of the usual suspects interested in bridges (and
also panels, since same discussion there I think).
-Daniel
On Tue, Apr 21, 2020 at 2:54 PM Daniel Vetter wrote:
>
> On Tue, Mar 24, 2020 at 04:19:31PM +0100, Lubomir Rintel wrote:
> > This is a driver for video encoder with VGA
Hi,
Changes in v2:
- Drop "backlight: led_bl: rewrite led_bl_parse_levels()". The patch
changed the behavior, and the new behavior may not be wanted. So lets
drop this for now.
- "backlight: led_bl: fix led -> backlight brightness mapping" will now
use max brightness if LED's brightness is
The code that maps the LED default brightness to backlight levels has
two issues: 1) if the default brightness is the first backlight level
(usually 0), the code fails to find it, and 2) when the code fails to
find a backlight level, it ends up using max_brightness + 1 as the
default brightness.
F
Fix issues reported by checkpatch. No functional changes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight
There's no need to set 'levels' to NULL.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366..c4
led_bl does not lock 'led_access' when calling led_sysfs_disable and
led_sysfs_enable, causing the below WARN. Add the locking.
WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
led_sysfs_disable+0x4c/0x5c
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/back
Am 21.04.20 um 14:09 schrieb 赵军奎:
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger
Am 21.04.20 um 14:22 schrieb Bernard Zhao:
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
You could improve the subject line and commit message a bit, e.g.
something like:
[PATCH] drm/amdgpu: cleanup coding style in amdkfd a
Hi Jani,
On Tue, Apr 21, 2020 at 2:58 PM Jani Nikula wrote:
> On Tue, 21 Apr 2020, Daniel Vetter wrote:
> > On Mon, Apr 20, 2020 at 04:03:23PM +0200, Arnd Bergmann wrote:
> >> On Mon, Apr 20, 2020 at 10:14 AM Jani Nikula
> >> wrote:
> >> > On Fri, 17 Apr 2020, Jason Gunthorpe wrote:
> >> > > O
On Tue, Apr 21, 2020 at 3:05 PM Geert Uytterhoeven wrote:
>
> Hi Jani,
>
> On Tue, Apr 21, 2020 at 2:58 PM Jani Nikula
> wrote:
> > On Tue, 21 Apr 2020, Daniel Vetter wrote:
> > > On Mon, Apr 20, 2020 at 04:03:23PM +0200, Arnd Bergmann wrote:
> > >> On Mon, Apr 20, 2020 at 10:14 AM Jani Nikula
On Tue, Apr 21, 2020 at 2:50 PM Michał Winiarski wrote:
>
> From: Michał Winiarski
>
> Control nodes are no longer with us.
> While we still need to preserve render nodes numbering, there's no need
> to reserve the range formerly used for control. Let's repurpose it to be
> used by primary and re
On 21/04/2020 14:16, Daniel Vetter wrote:
> On Mon, Apr 20, 2020 at 12:21:24PM +0200, Neil Armstrong wrote:
>> On 17/04/2020 20:14, Daniel Vetter wrote:
>>> On Fri, Apr 17, 2020 at 6:05 PM Neil Armstrong
>>> wrote:
On 17/04/2020 17:07, Daniel Vetter wrote:
>>
>> [...]
>>
>>>
>>> Yup the
On Tue, 21 Apr 2020, Daniel Vetter wrote:
> To clarify what I was aiming for with my mail: I'm not worried about
> fbdev here, I'm just worried that this will come back, and we'll grow
> select somewhere else until it's become a big & totally horrible mess.
> I think a lot of the backlight selects
Suspend need to wait running jobs finish and put hardware in
poweroff state. Resume need to re-init hardware.
v2:
1. add misc patches to prepare enable runtime pm
2. fix pmu command wait time out on mali400 gpu
3. do power and clock gating when suspend
4. do runtime pm
Qiang Yu (10):
drm/lima:
Simplify module init/exit with module_platform_driver.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index bbbdc8455e2f..91bf5b305e9d 1
We need to flush TLB anyway before every task start, and the
page directory will be set to empty vm after suspend/resume,
so always set it to the task vm even no ctx switch happens.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_mmu.c | 3 +--
drivers/gpu/drm/lima/lima_sched.c | 14 +++
When error task list is full, print the process info where
the error task come from for debug usage.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_sched.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_
For being used by both device init/fini and suspend/resume.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 105 +++--
1 file changed, 68 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_device.c
b/drivers/gpu/drm/lima/lima_device.c
For called when PM do resume/suspend.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_bcast.c| 25
drivers/gpu/drm/lima/lima_bcast.h| 2 ++
drivers/gpu/drm/lima/lima_device.c | 4 +++
drivers/gpu/drm/lima/lima_device.h | 2 +-
drivers/gpu/drm/lima/lima_dlbu.
No need to handle this check before calling lima_vm_put.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_sched.c | 7 ++-
drivers/gpu/drm/lima/lima_vm.h| 3 ++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/
Add driver pm system and runtime hardware resume/suspend ops.
Note this won't enable runtime pm of the device yet.
v2:
Do clock and power gating when suspend/resume.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 90 ++
drivers/gpu/drm/lima/lima_dev
Enable runtime pm by default so GPU suspend when idle
for 200ms. This value can be changed by
autosuspend_delay_ms in device's power sysfs dir.
On Allwinner H3 lima_device_resume takes ~40us and
lima_device_suspend takes ~20us.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 21
Prepare resume/suspend PM.
v2:
Fix lima_pmu_wait_cmd timeout when mali400 case.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.h | 2 ++
drivers/gpu/drm/lima/lima_pmu.c| 53 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/
Used for device resume/suspend in the following commits.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_devfreq.c | 24
drivers/gpu/drm/lima/lima_devfreq.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu
On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>
> Hi Dave, Daniel,
>
> just a friendly reminder to merge these changes. They don't seem to be
> in the upstream tree yet.
Dave noticed and pinged me on irc that there's some changes in core mm
in this one. That patch is correctly acked by
The Amlogic S805X/Y uses the same die as the S905X, but with more
limited graphics capabilities.
This adds a soc version detection adding specific limitations on the HDMI
mode selections.
Here, we limit to HDMI 1.3a max HDMI PHY clock frequency.
Signed-off-by: Neil Armstrong
---
drivers/gpu/dr
aa_mk_null_file is using simple_pin_fs/simple_release_fs with local
variables as arguments, for what would amount to a simple
vfs_kern_mount/mntput pair if everything was inlined. Just use
the normal filesystem API since the reference counting is not needed
here (it is a local variable and always
libfs.c has many functions that are useful to implement dentry and inode
operations, but not many at the filesystem level. As a result, code to
create files and inodes has a lot of duplication, to the point that
tracefs has copied several hundred lines from debugfs.
The main two libfs.c functions
Simplify passing the count and mount to simple_pin_fs and
simple_release_fs by wrapping them in the simple_fs struct,
in preparation for adding more high level operations to
fs/libfs.c
There is no functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
drivers/gpu/drm/drm_drv.
libfs.c has many functions that are useful to implement dentry and inode
operations, but not many at the filesystem level. Start adding file
creation wrappers, the simplest returns an anonymous inode.
There is no functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
drivers/
It is a common special case for new_inode to initialize the
time to the current time and the inode to get_next_ino().
Introduce a core function that does it.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/libfs.c | 20
include/linux/fs.h | 1 +
2 files changed, 21
The only difference, compared to the pre-existing code, is that symlink
creation now triggers fsnotify_create. This was a bug in the debugfs
code, since for example vfs_symlink does call fsnotify_create.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/debugfs/inode.c | 144 +---
There is no semantic change intended; the code in the libfs.c
functions in fact was derived from debugfs and tracefs code.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/tracefs/inode.c | 86 --
1 file changed, 7 insertions(+), 79 deletions(-)
diff
A bunch of code is duplicated between debugfs and tracefs, unify it to the
libfs library.
The code is very similar, except that dentry and inode creation are unified
into a single function (unlike start_creating in debugfs and tracefs, which
only takes care of dentries). This adds an output param
On Tue, Apr 21, 2020 at 03:44:10PM +0200, Neil Armstrong wrote:
> The Amlogic S805X/Y uses the same die as the S905X, but with more
> limited graphics capabilities.
>
> This adds a soc version detection adding specific limitations on the HDMI
> mode selections.
>
> Here, we limit to HDMI 1.3a max
Hi
Am 21.04.20 um 12:45 schrieb Daniel Vetter:
> On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
>>> Add a new macro helper to combine the usual init sequence in drivers,
>>> consisting of a kzalloc + devm_drm_dev_init + drmm_add
Hi
Am 21.04.20 um 15:41 schrieb Daniel Vetter:
> On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>>
>> Hi Dave, Daniel,
>>
>> just a friendly reminder to merge these changes. They don't seem to be
>> in the upstream tree yet.
>
> Dave noticed and pinged me on irc that there's some chang
On 2020-04-19 9:50 p.m., Randy Dunlap wrote:
> Fix a kernel-doc warning of missing struct field desription:
>
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:331: warning: Function
> parameter or member 'hdcp_workqueue' not described in 'amdgpu_display_manager'
>
> Fixes: 52704fcaf74b ("d
On 2020-04-19 9:50 p.m., Randy Dunlap wrote:
> Fix a kernel-doc warning of missing struct field desription:
>
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function parameter or
> member 'vm' not described in 'amdgpu_vm_eviction_lock'
>
> Fixes: a269e44989f3 ("drm/amdgpu: Avoid reclai
On Tue, 21 Apr 2020 14:15:52 +0200
Daniel Vetter wrote:
> On Mon, Apr 20, 2020 at 01:04:20PM +0300, Pekka Paalanen wrote:
> > On Mon, 20 Apr 2020 11:27:04 +0300
> > Pekka Paalanen wrote:
> >
> > > On Fri, 17 Apr 2020 16:17:18 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Fri, Apr 17,
Am 20.04.20 um 03:50 schrieb Randy Dunlap:
Fix a kernel-doc warning of missing struct field desription:
../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function parameter or
member 'vm' not described in 'amdgpu_vm_eviction_lock'
Can't we just document the function parameter instead? Sh
Quoting Daniel Vetter (2020-04-21 15:13:34)
> On Tue, Apr 21, 2020 at 2:50 PM Michał Winiarski wrote:
> >
> > From: Michał Winiarski
> >
> > Control nodes are no longer with us.
> > While we still need to preserve render nodes numbering, there's no need
> > to reserve the range formerly used for
Am 21.04.20 um 16:33 schrieb Christian König:
Am 20.04.20 um 03:50 schrieb Randy Dunlap:
Fix a kernel-doc warning of missing struct field desription:
../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function
parameter or member 'vm' not described in 'amdgpu_vm_eviction_lock'
Can't we j
On Tuesday, April 21, 2020 4:33 PM, Pekka Paalanen wrote:
> I'd love to volunteer for writing the Weston code to make use of "get me
> sane default state" UAPI, but I'm afraid I'm not in that much control
> of my time.
I'm interested in this problem too. If someone writes the kernel side,
I'll g
On Tue, 21 Apr 2020 14:37:41 +0200
Hans de Goede wrote:
> TL;DR: Yes there will be races, because of both userspace +
> the firmware having; and potentially using r/w access to
> the privacy-screen state. But in practice I expect these
> to not really be an issue. Important here is that userspace
Am 21.04.20 um 15:39 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel
On 21/04/2020 15:59, Daniel Vetter wrote:
> On Tue, Apr 21, 2020 at 03:44:10PM +0200, Neil Armstrong wrote:
>> The Amlogic S805X/Y uses the same die as the S905X, but with more
>> limited graphics capabilities.
>>
>> This adds a soc version detection adding specific limitations on the HDMI
>> mode
On Tue, Apr 21, 2020 at 03:46:29PM +0300, Tomi Valkeinen wrote:
> The code that maps the LED default brightness to backlight levels has
> two issues: 1) if the default brightness is the first backlight level
> (usually 0), the code fails to find it, and 2) when the code fails to
> find a backlight
On 15/04/2020 19:33, Daniel Vetter wrote:
> On Wed, Apr 15, 2020 at 02:29:28AM +0300, Eugeniy Paltsev wrote:
>> The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
>> encoders. Support them with a platform driver to provide platform glue
>> data to the dw-hdmi driver.
>>
>> Acked-b
-next 20200421 with the above two patches
applied.
Thank you,
Adrian
Adrian Ratiu (8):
drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
drm: bridge: synopsis: add dsi v1.01 support
drm: imx: Add i.MX 6 MIPI DSI
Register existence, address/offsets, field layouts, reserved bits and
so on differ between MIPI-DSI versions and between SoC vendor boards.
Despite these differences the hw IP and protocols are mostly the same
so the generic bridge can be made to compensate these differences.
The current Rockchip
This provides an example DT binding for the MIPI DSI host controller
present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
Cc: Rob Herring
Cc: Neil Armstrong
Cc: Fabio Estevam
Cc: Laurent Pinchart
Cc: devicet...@vger.kernel.org
Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signe
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 c
The stm mipi-dsi platform driver added a version test in
commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
so that HW revisions other than v1.3x get rejected. The rockchip
driver had no such check and just assumed register layouts are
v1.3x compatible.
Having such tests was a good idea
The Synopsis MIPI DSI v1.01 host controller is quite widely used
on platforms like i.mx6 and is not very different from the other
versions like the 1.31/1.30 used on rockchip/stm. The protocols
appear to be the same, only the register layout is different and
the newer versions have new features sym
In order to support multiple versions of the Synopsis MIPI DSI host
controller, which have different register layouts but almost identical
HW protocols, we add a regmap infrastructure which can abstract away
register accesses for platform drivers using the bridge.
The controller HW revision is det
1 - 100 of 203 matches
Mail list logo
