We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
Cc:
Signed-of
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: h
Both adp8860 and adp8870 define some extensions to the
backlight class. This causes warnings:
Warning: /sys/class/backlight//ambient_light_level is
defined 2 times: /sys/class/backlight//ambient_light_level:8
/sys/class/backlight//ambient_light_level:30
Warning: /sys/class/back
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
Documentation/ABI/st
On Fri, Oct 30, 2020 at 1:30 AM Linus Walleij wrote:
> The driver includes but doesn't use any symbols
> from this file.
>
> Cc: Magnus Damm
> Cc: Geert Uytterhoeven
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Linus Walleij
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytter
[New] Create the setting for 1600x900 @60Hz refresh rate
by 108MHz pixel-clock.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_tables.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index d665dd5af5dd..8
https://bugzilla.kernel.org/show_bug.cgi?id=209939
--- Comment #4 from Janpieter Sollie (janpieter.sol...@edpnet.be) ---
sorry, no, still the same ...
just to be sure, if I do this, this overrides settings in
/etc/modprobe.d/amdgpu.conf, right?
--
You are receiving this mail because:
You are wat
Am 30.10.20 um 01:07 schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_ttm.c: In function 'nouveau_ttm_init':
drivers/gpu/drm/nouveau/nouveau_ttm.c:320:19: error: implicit declarati
Am 30.10.20 um 08:57 schrieb Deepak R Varma:
On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function wi
On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote:
> On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> > > function in place of the
On Thu, 29 Oct 2020 21:53:34 +0100
Marcin Kocur wrote:
> Hello,
>
> this is the output of turning off and on my display (using power button):
...
> The monitor was visible in xrandr as DP-2, after power off and on it's
> visible as DP-3 (DP-2 is still there "disconnected").
>
> It's troubles
On Fri, 30 Oct 2020 09:30:01 +0200
Tomi Valkeinen wrote:
> On 30/10/2020 00:48, Laurent Pinchart wrote:
>
> >>> And, hmm... It's too easy to get confused with these, but... If the
> >>> bridge defines timings, and
> >>> timings->input_bus_flags != 0, should we always pick that, even if we got
The HDMI controller cannot go above a certain pixel rate limit depending on
the generations, but that limit is only enforced in mode_valid at the
moment, which means that we won't advertise modes that exceed that limit,
but the userspace is still free to try to setup a mode that would.
Implement a
Fix the missing clk_disable_unprepare() before return
from tegra_sor_init() in the error handling case.
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/tegra/sor.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/
On Wed, Oct 28, 2020 at 01:30:32PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Wed, 8 Jul 2020 at 15:46, Maxime Ripard wrote:
> >
> > Since the components for a given device in ASoC are identified by their
> > name, it makes sense to add one even though it's not strictly necessary.
> >
> > Si
Correct spelling in one of the comment.
s/defalut/default/p
Signed-off-by: Bhaskar Chowdhury
---
CCing Greg becasue it touched drivers file. Trivial though.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gp
Hi maxime,
On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
>
> Add a property to o
On Wed, Oct 28, 2020 at 08:49:11PM +0100, Daniel Vetter wrote:
> On Wed, Oct 28, 2020 at 04:15:26PM -0300, Jason Gunthorpe wrote:
> > Since commit 9a40401cfa13 ("lib/scatterlist: Do not limit max_segment to
> > PAGE_ALIGNED values") the max_segment input to sg_alloc_table_from_pages()
> > does not
The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's
not used consistently (vc4_drv's bind calls it in its error path, but
doesn't in unbind), and we can make that automatic through a managed
action. Let's remove the requirement to call vc4_bo_cache_destroy.
Fixes: c826a6e10644
On 10/30/20 1:20 AM, Linus Walleij wrote:
This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that
The job queue needs to be cleaned up using vc4_gem_destroy, but it's
not used consistently (vc4_drv's bind calls it in its error path, but
doesn't in unbind), and we can make that automatic through a managed
action. Let's remove the requirement to call vc4_gem_destroy.
Fixes: d5b1a78a772f ("drm/vc
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
Use kmemdup() for instructions using kmalloc() + memcpy(). More
information here: https://lwn.net/Articles/198928/
Issue reported by coccinelle script: scripts/coccinelle/api/memdup.cocci
Signed-off-by: Deepak R Varma
---
Changes since v1:
- Update patch subject and log message to match propos
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
Using drmm_mode_config_init instead of drm_mode_config_init allows us to
cleanup a bit the error path.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
These register reads and writes are sometimes directly next to each
other in the register address space. Let's use regmap bulk read/write
APIs to get the data with one transfer instead of multiple i2c
transfers. This helps cut down on the number of transfers in the case of
something like reading an
Hi!
Thanks for your review
On Thu, Oct 29, 2020 at 09:51:04AM +0100, Daniel Vetter wrote:
> On Wed, Oct 28, 2020 at 01:41:01PM +0100, Maxime Ripard wrote:
> > We've had a number of muxing corner-cases with specific ways to reproduce
> > them, so let's document them to make sure they aren't lost a
We can simplify a bit the bind code, its error path and unbind by using
the managed devm_drm_dev_alloc function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 4 ++--
drivers/gpu/drm/vc4/vc4_drv.c | 27 ++-
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
driv
Fix the following sparse warning:
drivers/dma-buf/heaps/system_heap.c:23:17: warning: symbol 'sys_heap' was not
declared. Should it be static?
sys_heap has only call within system_heap.c
It should be static
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/dma-buf/heaps/system_heap.
Quoting Doug Anderson (2020-10-29 09:22:55)
> Hi,
>
> On Wed, Oct 28, 2020 at 6:12 PM Stephen Boyd wrote:
> >
> > We should be setting the drm_dp_aux_msg::reply field if a NACK or a
> > SHORT reply happens.
>
> I don't think you update the "reply" field for SHORT, right? You just
> return a dif
Mauro Carvalho Chehab writes:
> There are some ABI documents that, while they don't generate
> any warnings, they have issues when parsed by get_abi.pl script
> on its output result.
>
> Address them, in order to provide a clean output.
>
> Signed-off-by: Mauro Carvalho Chehab
> diff --git a/D
On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> > function in place of the debugfs_create_file() function will make the
> > file operation struct "
From: Thomas Gleixner
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
C
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
maneuvers.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Changed the property name
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
1 file cha
The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
per clock cycle, and cannot deal with odd timings.
Let's reject any mode with such timings.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- s/broken/unsupported/
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12
Hi!
On Wed, Oct 28, 2020 at 01:42:20PM +, Dave Stevenson wrote:
> Hi Maxime
>
> On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote:
> >
> > The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> > per clock cycle, and cannot deal with odd timings.
> >
> > Let's reject any
In order to make the vc4_kms_load code and error path a bit easier to
read and extend, add functions to create state objects, and use managed
actions to cleanup if needed.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 --
drivers/gpu/drm/vc4/vc4_kms.c | 78 +
We have a helper to retrieve the vc4_dev structure from the drm_device one
when needed, so let's use it consistently.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hvs.c | 4 ++--
drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/driv
On Thu, 29 Oct 2020 15:28:34 -0700 John Stultz wrote:
> On Thu, Oct 29, 2020 at 12:10 AM Hillf Danton wrote:
> > On Thu, 29 Oct 2020 00:16:24 + John Stultz wrote:
> > > @@ -194,6 +210,9 @@ static int system_heap_mmap(struct dma_buf *dmabuf,
> > > struct vm_area_struct *vma)
> > > struct
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
On Thu, 2020-10-29 at 23:27 +0800, Chun-Kuang Hu wrote:
> mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_mipi_dsi_phy driver into phy driver folder.
>
> Signed-off-by: Chun-Kuang Hu
> ---
> dri
Hi Nicolas,
On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> Hi maxime,
>
> On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS r
On Thu, 29 Oct 2020 21:04:30 -0700 John Stultz wrote:
>
> But I'll try to share my thoughts:
>
> So the system heap allows for allocation of non-contiguous buffers
> (currently allocated from page_alloc), which we keep track using
> sglists.
> Since the resulting dmabufs are shared between multip
The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
HDMI cable right in the middle of the first Wifi channel.
Add a property to our HDMI controller, that could be reused by other
similar HDMI controllers, to
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel wi
On Fri, Oct 30, 2020 at 01:47:05PM +0530, Sumera Priyadarsini wrote:
> On Fri, 30 Oct, 2020, 1:32 PM Greg KH, wrote:
>
> > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote:
> > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > > On Fri, Oct 30, 2020 at 08:52:45AM +053
On Thu, 29 Oct 2020 12:34:51 -0700 John Stultz wrote:
>
> As for your comment on HPAGE_PMD_ORDER (9 on arm64/arm) and
> PAGE_ALLOC_COSTLY_ORDER(3), I'm not totally sure I understand your
> question? Are you suggesting those values would be more natural orders
> to choose from?
The numbers, 9 and
On Thu, Oct 29, 2020 at 10:49:22AM +, Dave Stevenson wrote:
> On Thu, 29 Oct 2020 at 09:17, Maxime Ripard wrote:
> >
> > Hi!
> >
> > On Wed, Oct 28, 2020 at 01:42:20PM +, Dave Stevenson wrote:
> > > Hi Maxime
> > >
> > > On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote:
> > > >
> > > > T
Quoting Stephen Boyd (2020-10-28 18:11:51)
> @@ -72,6 +74,7 @@
> #define SN_AUX_ADDR_19_16_REG 0x74
> #define SN_AUX_ADDR_15_8_REG 0x75
> #define SN_AUX_ADDR_7_0_REG0x76
> +#define SN_AUX_ADDR_MASK GENMASK(19, 0)
> #de
Hi Dave, Daniel,
Here's the first round of fixes for drm-misc
Maxime
drm-misc-fixes-2020-10-29:
First round of drm-misc-fixes with a couple of leftovers from
drm-misc-fixes next.
Some reset fixes for the mantix panel, some fixes for a scaler issue on
sun4i, many kernel-doc fixes and various fix
This patch series cleans up the DDC code a little bit so that
it is more efficient time wise and supports grabbing the EDID
of the eDP panel over the aux channel. I timed this on a board
I have on my desk and it takes about 20ms to grab the EDID out
of the panel and make sure it is valid.
The firs
There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
chip and some resolutions, most notably 1440p at 60Hz.
In such a case, we can either reject entirely the mode, or lower slightly
the pixel frequency to remove the overlap. Let's go for the latter.
Signed-off-by: Maxime Ri
Align instructions split across multiple lines as per the coding
standards. Issue flagged by checkpatch script.
Signed-off-by: Deepak R Varma
---
Please note: This is a project task specific patch.
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 10 +-
1 file changed, 5 insertions(+), 5 del
On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugf
On Wed, Oct 28, 2020 at 01:49:29PM +, Dave Stevenson wrote:
> s/convertion/conversion in subject line
>
> On Wed, 28 Oct 2020 at 12:37, Maxime Ripard wrote:
> >
> > Most of the helpers to retrieve vc4 structures from the DRM base structures
> > rely on the fact that the first member of the vc
Use the DDC connection to read the EDID from the eDP panel instead of
relying on the panel to tell us the modes.
Reviewed-by: Douglas Anderson
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: Sean Paul
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 +
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/navi10_ppt.c:2527:35:
warning: ‘navi10_i2c_algo’
defined but not used [-Wunused-const-variable=]
static const struct i2c_algorithm navi10_i2c_algo = {
^~~
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack,
On Thu, 2020-10-29 at 19:07 +0100, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> > Hi maxime,
> >
> > On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of
There's no reason we need to wait here to poll a register over i2c. The
i2c bus is inherently slow and delays are practically part of the
protocol because we have to wait for the device to respond to any
request for a register. Let's rely on the sleeping of the i2c controller
instead of adding any
We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or to
Hi,
On 29/10/2020 23:20, Sam Ravnborg wrote:
> Hi Anitha.
>
> On Thu, Oct 29, 2020 at 02:27:52PM -0700, Anitha Chrisanthus wrote:
>> This patch adds bindings for Intel KeemBay Display
>>
>> v2: review changes from Rob Herring
>> v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
On 29/10/2020 23:22, Sam Ravnborg wrote:
> Hi Anitha.
>
> On Thu, Oct 29, 2020 at 02:27:53PM -0700, Anitha Chrisanthus wrote:
>> This patch adds bindings for Intel KeemBay MIPI DSI
>>
>> Signed-off-by: Anitha Chrisanthus
>> Cc: Sam Ravnborg
>> Cc: Thomas Zimmermann
>> Cc: Daniel Vetter
>
> Th
On 22/09/2020 16:16, Robin Murphy wrote:
> Hi all,
>
> Here's a quick v2 with the tags so far picked up and some inline
> commentary about the shareability domains for the pagetable code.
>
> Robin.
>
>
> Robin Murphy (3):
> iommu/io-pgtable-arm: Support coherency for Mali LPAE
> drm/panfro
On Fri, 30 Oct 2020 10:40:46 +0200
Tomi Valkeinen wrote:
> Hi Boris,
>
> On 30/10/2020 10:08, Boris Brezillon wrote:
> > The "propagate output flags" and soon to be added "use
> > timing->input_flags if present" logic should only be used as a fallback
> > for bridges that do not support dynamic
On Fri, Oct 30, 2020 at 9:30 AM Tomi Valkeinen wrote:
>
> On 29/10/2020 15:22, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbcon: remove s
On Friday, October 30, 2020 9:09 AM, Pekka Paalanen wrote:
> On Thu, 29 Oct 2020 21:53:34 +0100
> Marcin Kocur marcin2...@gmail.com wrote:
>
> > Hello,
> > this is the output of turning off and on my display (using power button):
>
> ...
>
> > The monitor was visible in xrandr as DP-2, after powe
On Thu, Oct 29, 2020 at 08:00:59PM +0100, Maxime Ripard wrote:
> The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's
> not used consistently (vc4_drv's bind calls it in its error path, but
> doesn't in unbind), and we can make that automatic through a managed
> action. Let's re
On Thu, Oct 29, 2020 at 08:01:04PM +0100, Maxime Ripard wrote:
> In order to make the vc4_kms_load code and error path a bit easier to
> read and extend, add functions to create state objects, and use managed
> actions to cleanup if needed.
>
> Signed-off-by: Maxime Ripard
Nice. With an s/drmm_a
On Thu, Oct 29, 2020 at 06:00:58PM -0700, Abhinav Kumar wrote:
> Currently drm_atomic_print_state() internally allocates and uses a
> drm_info printer. Allow it to accept any drm_printer type so that
> the API can be leveraged even for taking drm snapshot.
>
> Rename the drm_atomic_print_state() t
On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> > Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varm
On Thu, 29 Oct 2020 17:00:47 +
Steven Price wrote:
> The mutex within the panfrost_queue_state should have the lifetime of
> the queue, however it was erroneously initialised/destroyed during
> panfrost_job_{open,close} which is called every time a client
> opens/closes the drm node.
>
> Mov
Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > Hi Guido,
> >
> > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > > So far the unmap from gpu address space only happened when dropping the
> >
On Fri, Oct 30, 2020 at 10:15:21AM +0100, Daniel Vetter wrote:
> On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote:
> > On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> > > Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH
On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > Hi Guido,
> > >
> > > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > > > So
Am Freitag, den 30.10.2020, 10:33 +0100 schrieb Daniel Vetter:
> On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> > Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > > Hi Guido,
> > > >
> > > > A
On Fri, 30 Oct 2020, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: https://lists.archive
Am 30.10.20 um 09:25 schrieb Greg KH:
On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
Am 30.10.20 um 08:57 schrieb Deepak R Varma:
On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
Using DEFINE_DEBUGFS_ATT
On 30/10/2020 07:08, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
Fixes: 1a11a88cfd9a ("drm/panfr
On 30/10/2020 07:40, Mauro Carvalho Chehab wrote:
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukj
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire u
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical se
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Wi
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: And
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
Hi all
Another update of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.35090
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from ded
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is lo
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Acked-by: Tomasz Figa
Signed-off-b
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings,
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedic
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, sinc
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/
Prep work to make drm_device->driver const.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Evan Quan
Cc: Felix Kuehling
Cc: Hawking Zhang
Cc: Andrey Grodzovsky
Cc: Luben Tuikov
Cc: Thomas Zimmermann
Cc: Monk Liu
Cc: Yintian Tao
Cc: Dennis Li
Cc: shaoyunl
Cc: B
1 - 100 of 162 matches
Mail list logo
