Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
We want single instance of reset sem across all
reset clients because in case of XGMI we should stop
access cross device MMIO because any of them could be
in a reset in the moment.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
The reset domain contains register access semaphor
now and so needs to be present as long as each device
in a hive needs it and so it cannot be binded to XGMI
hive life cycle.
Adress this by making reset domain refcounted and pointed
by each member
Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
No need to to trigger another work queue inside the work queue.
v3:
Problem:
Extra reset caused by host side FLR notification
following guest side triggered reset.
Fix: Preven qeuing flr_work from mailbox irq if guest
already executing a
Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Am 08.02.22 um 17:19 schrieb Andrey Grodzovsky:
On 2022-02-08 06:25, Lazar, Lijo wrote:
On 2/2/2022 10:56 PM, Andrey Grodzovsky wrote:
The reset domain contains register access semaphor
now and so needs to be present as long as each device
in a hive needs it and so it cannot be binded to
On Tue, 2022-02-08 at 17:55 -0800, Abhinav Kumar wrote:
>
> Are you suggesting something like below?
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 42dcf96..14203d0 100644
> --- a/fs/sysfs/file.c
>
No, for sure not, but I guess from the looks of this patch there's no
way to do
On 07/02/2022 18:35, Maxime Ripard wrote:
The omap KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Full Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in
On 07/02/2022 18:35, Maxime Ripard wrote:
The omap KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index and the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in omap_plane_reset(). However, the helpers
On 07/02/2022 18:35, Maxime Ripard wrote:
While the omap_plane_init() function calls
drm_plane_create_zpos_property() with an initial value of 0,
omap_plane_reset() will force it to another value depending on the plane
type.
Fix the discrepancy by setting the initial zpos value to the same
Am 08.02.22 um 16:12 schrieb Matthew Auld:
Make sure we pull in the kernel-doc for this.
Reported-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
Reviewed-by: Christian König
---
Documentation/gpu/drm-mm.rst | 9 +
1 file changed, 9
Hi Bjorn,
1. I will change the edp_out label to mdss_edp_out.
2. The "pm8350c_pwm" node is part of the dependent series mentioned in the
cover letter. Below is the patch for the same:
Hi Matthias,
I will implement the changes.
Thank you,
Sankeerth
-Original Message-
From: Matthias Kaehlcke
Sent: Wednesday, February 9, 2022 3:54 AM
To: Sankeerth Billakanti (QUIC)
Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
freedr...@lists.freedesktop.org;
On Mon, Feb 07, 2022 at 12:36:42PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
First release of GuC for DG2.
Signed-off-by: John Harrison
CC: Tomasz Mistat
CC: Ramalingam C
CC: Daniele Ceraolo Spurio
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen wrote:
> Randy Dunlap wrote:
> > On 2/8/22 12:10, Thinh Nguyen wrote:
> >> Randy Dunlap wrote:
> >>> On 2/3/22 19:21, Thinh Nguyen wrote:
> Ah.. It's because I don't use old.config as the base config. I use
> x86_64_defconfig as the base plus some
The nouveau driver depends on include/linux/list.h instead of
nvif/list.h, so remove the obstacle-nvif/list.h.
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/nouveau/include/nvif/list.h | 353
1 file changed, 353 deletions(-)
delete mode 100644
On Wed, Feb 09, 2022 at 07:23:04AM +0100, Thomas Zimmermann wrote:
Hi
Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
Replace all occurance of cache_clflush_range with
drm_clflush_virt_range. This will prevent compile errors on non-x86
platforms.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
Signed-off-by: Michael Cheng
---
Hi
Am 08.02.22 um 11:45 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
-
Em Tue, 8 Feb 2022 02:45:08 -0800
Lucas De Marchi escreveu:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
> -
Hi Andrey,
I have been testing your patch and it seems fine till now.
Best Regards,
Jingwen Chen
On 2022/2/3 上午2:57, Andrey Grodzovsky wrote:
> Just another ping, with Shyun's help I was able to do some smoke testing on
> XGMI SRIOV system (booting and triggering hive reset)
> and for now
If successful ida_simple_get() calls are not undone when needed, some
additional memory may be allocated and wasted.
Here, an ID between 0 and MAX_INT is required. If this ID is >=100, it is
not taken into account and is wasted. It should be released.
Instead of calling ida_simple_remove(), take
On Wed, 26 Jan 2022 15:55:42 +0100, Sascha Hauer wrote:
> The VOP2 is the display output controller on the RK3568. Add the node
> for it to the dtsi file along with the required display-subsystem node
> and the iommu node.
>
> changes since v3:
> - Bring back gamma_lut regs
> - Drop redundant
On Wed, 26 Jan 2022 15:55:38 +0100, Sascha Hauer wrote:
> The rk3568 HDMI has an additional clock that needs to be enabled for the
> HDMI controller to work. The purpose of that clock is not clear. It is
> named "hclk" in the downstream driver, so use the same name.
>
> Signed-off-by: Sascha
On Wed, 26 Jan 2022 15:55:37 +0100, Sascha Hauer wrote:
> The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs
> needed for the HDMI port. Add the binding for these supplies.
>
> Signed-off-by: Sascha Hauer
> ---
> .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11
On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
[..]
> @@ -500,28 +482,27 @@ void free_devmap_managed_page(struct page *page)
> */
> page->mapping = NULL;
> page->pgmap->ops->page_free(page);
> +
> + /*
> +* Reset the page count to 1 to prepare for
On Wed, 26 Jan 2022 15:55:36 +0100, Sascha Hauer wrote:
> "vpll" is a misnomer. A clock input to a device should be named after
> the usage in the device, not after the clock that drives it. On the
> rk3568 the same clock is driven by the HPLL.
> This patch adds "ref" as a new alternative clock
On Wed, 26 Jan 2022 15:55:35 +0100, Sascha Hauer wrote:
> None of the upstream device tree files has a "unwedge" pinctrl
> specified. Make it optional.
>
> Signed-off-by: Sascha Hauer
> ---
> .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
> 1 file changed, 1
On Sun, 23 Jan 2022 17:38:08 +, Caleb Connolly wrote:
> Add SHIFT vendor prefix, SHIFT make various devices such as the SHIF6mq
> phone.
>
> Signed-off-by: Caleb Connolly
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by:
On Sun, 23 Jan 2022 17:37:41 +, Caleb Connolly wrote:
> Document a new compatible string for the second panel variant.
>
> Signed-off-by: Caleb Connolly
> ---
> .../devicetree/bindings/display/panel/visionox,rm69299.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
On Sat, 22 Jan 2022 15:56:05 +0800, Yunfei Dong wrote:
> Adds decoder dt-bindings for mt8186.
>
> Signed-off-by: Yunfei Dong
> ---
> .../bindings/media/mediatek,vcodec-subdev-decoder.yaml| 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring
On Thu, 13 Jan 2022 16:51:11 +0200, Jami Kettunen wrote:
> From: AngeloGioacchino Del Regno
>
> Add yaml binding for msm8998 dpu1 support.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> Signed-off-by: Jami Kettunen
> ---
> .../bindings/display/msm/dpu-msm8998.yaml | 219
Hi Johannes
On 2/8/2022 1:54 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
I am checking what usermode sees and will get back ( I didnt see an
error do most likely it was EOF ). I didnt follow the second part.
I think probably it got -ENODEV, looking at
On 13/01/2022 17:51, Jami Kettunen wrote:
From: AngeloGioacchino Del Regno
The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though
this driver does actually handle both, if present: add the two in
preparation for adding support for SoCs having them.
Signed-off-by: AngeloGioacchino
Eliminate the following coccicheck warning:
./drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:2087:27-38: ERROR: bo_buckets
is NULL but dereferenced.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 6 ++
1 file changed, 2 insertions(+), 4
Hi Melissa,
On 2/8/22 07:40, Melissa Wen wrote:
On 01/21, Igor Torrente wrote:
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
include/linux/dma-buf-map.h
between commit:
e8c1f36157ce ("dma-buf-map: Fix dot vs comma in example")
from the drm tree and commit:
7938f4218168 ("dma-buf-map: Rename to iosys-map")
from the drm-intel tree.
I
[AMD Official Use Only]
This patch is reviewed by Shaoyun.liu
Since other patches are suggested by other engineer and they may already od
some review on them , so I will leave them to continue review the rest
patches.
Regards
Shaoyun.liu
-Original Message-
From: Grodzovsky,
We want single instance of reset sem across all
reset clients because in case of XGMI we should stop
access cross device MMIO because any of them could be
in a reset in the moment.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
Since now all GPU resets are serialzied there is no need for this.
This patch also reverts 'drm/amdgpu: race issue when jobs on 2 ring timeout'
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 89 ++
1 file
The reset domain contains register access semaphor
now and so needs to be present as long as each device
in a hive needs it and so it cannot be binded to XGMI
hive life cycle.
Adress this by making reset domain refcounted and pointed
by each member of the hive and the hive itself.
v4:
Fix crash
This functions needs to be split into 2 parts where
one is called only once for locking single instance of
reset_domain's sem and reset flag and the other part
which handles MP1 states should still be called for
each device in XGMI hive.
Signed-off-by: Andrey Grodzovsky
---
Since we have a single instance of reset semaphore which we
lock only once even for XGMI hive we don't need the nested
locking hint anymore.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
We should have a single instance per entrire reset domain.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 1 +
Since we serialize all resets no need to protect from concurrent
resets.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 -
No need to to trigger another work queue inside the work queue.
v3:
Problem:
Extra reset caused by host side FLR notification
following guest side triggered reset.
Fix: Preven qeuing flr_work from mailbox irq if guest
already executing a reset.
Suggested-by: Liu Shaoyun
Signed-off-by: Andrey
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
---
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize all possible
GPU recoveries to gurantee no concurrency there.
For TDR call the original recovery function directly since
it's already executed from within the wq. For others just
use a wrapper to
Defined a reset_domain struct such that
all the entities that go through reset
together will be serialized one against
another. Do it for both single device and
XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Daniel Vetter
Suggested-by: Christian König
Reviewed-by: Christian
This patchset is based on earlier work by Boris[1] that allowed to have an
ordered workqueue at the driver level that will be used by the different
schedulers to queue their timeout work. On top of that I also serialized
any GPU reset we trigger from within amdgpu code to also go through the same
On 2/8/22 22:08, Daniel Vetter wrote:
> This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
>
> With
>
> commit 27599aacbaefcbf2af7b06b0029459bbf682000d
> Author: Thomas Zimmermann
> Date: Tue Jan 25 10:12:18 2022 +0100
>
> fbdev: Hot-unplug firmware fb devices on forced
Hello Daniel,
On 2/8/22 22:08, Daniel Vetter wrote:
> Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
> code we initialize the cursor_work completely when we allocate the
> fbcon_ops structure, instead of trying to cope with console
> re-initialization.
>
Maybe also make
On Mon, Feb 7, 2022 at 3:49 PM Dan Williams wrote:
>
> On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
> >
> > Move the check for the actual pgmap types that need the free at refcount
> > one behavior into the out of line helper, and thus avoid the need to
> > pull memremap.h into mm.h.
On 2/8/22 22:27, Christoph Niedermaier wrote:
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Thursday, February 3, 2022 12:46 AM
Hi Christoph,
Hi Laurent,
On Tue, Feb 01, 2022 at 12:07:17PM +0100, Christoph Niedermaier wrote:
Without the data-mapping devicetree
On Tue 08 Feb 07:18 PST 2022, Sankeerth Billakanti wrote:
> Enable the eDP display panel support without HPD on sc7280 platform.
>
> Signed-off-by: Sankeerth Billakanti
> ---
>
> Changes in v2:
> - sort node references alphabetically
> - improve readability
> - move the pwm pinctrl to
It looks like for this series I forgot to Cc dri-devel, although these
patches are the same as the ones in
https://patchwork.freedesktop.org/series/99711/,
just extracted since not dependent on the iosys-map discussion.
Lucas De Marchi
On Mon, Feb 07, 2022 at 11:01:39PM -0800, Lucas De Marchi
On Tue, Feb 08, 2022 at 02:45:09AM -0800, Lucas De Marchi wrote:
> Add a variant of shmem_read() that takes a iosys_map pointer rather
> than a plain pointer as argument. It's mostly a copy __shmem_rw() but
> adapting the api and removing the write support since there's currently
> only need to
On 2/8/22 22:08, Daniel Vetter wrote:
> Avoids two forward declarations, and more importantly, matches what
> I've done in my fbcon scrolling restore patches - so I need this to
> avoid a bunch of conflicts in rebasing since we ended up merging
> Helge's series instead.
>
> Signed-off-by: Daniel
On Tue, Feb 08, 2022 at 02:45:08AM -0800, Lucas De Marchi wrote:
> First the simplest ones:
>
> - iosys_map_memset(): when abstracting system and I/O memory,
> just like the memcpy() use case, memset() also has dedicated
> functions to be called for using IO memory.
>
On 08.02.2022 22:05, Jordan Justen wrote:
> i915_drm.h now defines the format of the returned
> DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
> the black box GuC software, it should verify that the data matches
> that format before sending it to user-space.
>
> The
Tvrtko Ursulin writes:
> Will GuC folks be reviewing this work?
I don't know. If you mean the i915 devs interfacing with the GuC, I know
John/Rodrigo seemed a bit resistant writing the patches to give
userspace this trivial format guarantee on the blob.
So, I hoped they would write the patches
On Wed, 9 Feb 2022 at 00:21, Bjorn Andersson wrote:
>
> On Wed 19 Jan 15:14 PST 2022, Dmitry Baryshkov wrote:
>
> > On 28/12/2021 07:59, Bjorn Andersson wrote:
> > > The Qualcomm SM8350 platform comes with a single DisplayPort controller,
> > > add support for this in the DisplayPort driver.
> >
On Tue, Feb 08, 2022 at 08:48:43PM +0530, Sankeerth Billakanti wrote:
> Enable the eDP display panel support without HPD on sc7280 platform.
>
> Signed-off-by: Sankeerth Billakanti
> ---
>
> Changes in v2:
> - sort node references alphabetically
> - improve readability
> - move the pwm
Opened the issue at https://gitlab.freedesktop.org/drm/intel/-/issues/5077 ,
included dmesg + video. Feel free to let me know if you need any more info, or
need me to try any patches
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> >
On 08.02.2022 22:05, Jordan Justen wrote:
> From: John Harrison
>
> Implement support for fetching the hardware description table from the
> GuC. The call is made twice - once without a destination buffer to
> query the size and then a second time to fill in the buffer.
>
> Note that the
On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> >
> I am checking what usermode sees and will get back ( I didnt see an
> error do most likely it was EOF ). I didnt follow the second part.
I think probably it got -ENODEV, looking at kernfs_file_read_iter().
> If the file descriptor
Hi Johannes
On 2/8/2022 1:12 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote:
It opened the file rightaway but could not finish reading.
The device gets deleted so the corresponding /data will disappear too (
as the data node is under devcd*/data)
Yeah but
On Wed 19 Jan 15:14 PST 2022, Dmitry Baryshkov wrote:
> On 28/12/2021 07:59, Bjorn Andersson wrote:
> > The Qualcomm SM8350 platform comes with a single DisplayPort controller,
> > add support for this in the DisplayPort driver.
> >
> > Signed-off-by: Bjorn Andersson
>
> Reviewed-by: Dmitry
On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote:
>
> It opened the file rightaway but could not finish reading.
>
> The device gets deleted so the corresponding /data will disappear too (
> as the data node is under devcd*/data)
Yeah but even if the file disappears, the open file
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Acked-by: Sam Ravnborg
Signed-off-by:
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
v2: I typoed the config name (0day)
Cc: kernel test robot
Cc: Jens Frederich
Cc: Jon Nettleton
Cc: Greg Kroah-Hartman
Cc:
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock
It doesn't ever fail anymore.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 37 +++-
1 file changed, 13
It's only one flag and slightly tidier code.
Acked-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Claudio Suarez
---
drivers/video/fbdev/core/fbcon.c | 11
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Sam
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc:
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Sam Ravnborg (v1)
Reviewed-by: Geert Uytterhoeven (v1)
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Du
Hi all,
Second round, mostly just compile fixed and some minor polish to commit
messages. Also MAINTAINERS patch and fbcon scrolling patches are out
because they landed already.
There's still a handful here that need review (and somehow intel-gfx-ci
just keeled over on this).
Cheers, Daniel
On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
> There are cases where depending on the size of the devcoredump and the speed
> at which the usermode reads the dump, it can take longer than the current 5
> mins
> timeout.
>
> This can lead to incomplete dumps as the device is deleted
Hi Johannes
Thanks for the response.
On 2/8/2022 12:35 PM, Johannes Berg wrote:
On Tue, 2022-02-08 at 11:44 -0800, Abhinav Kumar wrote:
There are cases where depending on the size of the devcoredump and the speed
at which the usermode reads the dump, it can take longer than the current 5 mins
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
---
include/uapi/drm/i915_drm.h | 32
1 file changed, 32 insertions(+)
diff --git
i915_drm.h now defines the format of the returned
DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
the black box GuC software, it should verify that the data matches
that format before sending it to user-space.
The verification makes a single simple pass through the blob
From: Rodrigo Vivi
The DRM_I915_QUERY_HWCONFIG_BLOB query item returns a blob of data
which it receives from the GuC software. This blob provides some
useful data about the hardware for drivers.
Although the blob is not fully documented at this time, the basic
format is an array of u32 values.
This is John/Rodrigo's 2 patches with some minor changes, and I added
2 patches.
"drm/i915/uapi: Add query for hwconfig blob" was changed:
* Rename DRM_I915_QUERY_HWCONFIG_TABLE to DRM_I915_QUERY_HWCONFIG_BLOB
as requested by Joonas.
* Reword commit message
* I added Acked-by to this
1 - 100 of 292 matches
Mail list logo
