[PATCH v3 24/24] video: fbdev-MMP: Remove call to memset after dma_alloc_coherent
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/video/fbdev/mmp/fb/mmpfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/mmp/fb/mmpfb.c
b/drivers/video/fbdev/mmp/fb/mmpfb.c
index e5b56f2199df..47bc7c59bbd8 100644
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@ -612,7 +612,6 @@ static int mmpfb_probe(struct platform_device *pdev)
ret = -ENOMEM;
goto failed_destroy_mutex;
}
- memset(fbi->fb_start, 0, fbi->fb_size);
dev_info(fbi->dev, "fb %dk allocated\n", fbi->fb_size/1024);
/* fb power on */
--
2.11.0
Re: [GIT PULL] Please pull hmm changes
The pull request you sent on Tue, 9 Jul 2019 19:24:21 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus-hmm has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fec88ab0af9706b2201e5daf377c5031c62d11f7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] Please pull hmm changes
On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe wrote: > > I'm sending it early as it is now a dependency for several patches in > mm's quilt. .. but I waited to merge it until I had time to review it more closely, because I expected the review to be painful. I'm happy to say that I was overly pessimistic, and that instead of finding things to hate, I found it all looking good. Particularly the whole "use reference counts properly, so that lifetimes make sense and all those nasty cases can't happen" parts. It's all merged, just waiting for the test-build to verify that I didn't miss anything (well, at least nothing obvious). Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the akpm-current tree with the drm tree
Hi all,
On Tue, 9 Jul 2019 10:06:45 +1000 Stephen Rothwell
wrote:
>
> On Mon, 24 Jun 2019 21:06:59 +1000 Stephen Rothwell
> wrote:
> >
> > On Mon, 24 Jun 2019 20:49:08 +1000 Stephen Rothwell
> > wrote:
> > >
> > > Today's linux-next merge of the akpm-current tree got a conflict in:
> > >
> > > mm/memory.c
> > >
> > > between commit:
> > >
> > > 29875a52915e ("mm: Add an apply_to_pfn_range interface")
> > >
> > > from the drm tree and commit:
> > >
> > > e972cea08fb3 ("mm/pgtable: drop pgtable_t variable from pte_fn_t
> > > functions")
> > >
> > > from the akpm-current tree.
> > >
> > > I fixed it up (see below my signature, then added the following merge
> > > resolution patch as well) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> > >
> > > From: Stephen Rothwell
> > > Date: Mon, 24 Jun 2019 20:40:46 +1000
> > > Subject: [PATCH] merge fixup for "mm: Add an apply_to_pfn_range interface"
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > include/linux/mm.h| 2 +-
> > > mm/as_dirty_helpers.c | 8 ++--
> > > 2 files changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 87d53de3dee4..4404e18443ef 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2673,7 +2673,7 @@ extern int apply_to_page_range(struct mm_struct
> > > *mm, unsigned long address,
> > > unsigned long size, pte_fn_t fn, void *data);
> > >
> > > struct pfn_range_apply;
> > > -typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
> > > +typedef int (*pter_fn_t)(pte_t *pte, unsigned long addr,
> > >struct pfn_range_apply *closure);
> > > struct pfn_range_apply {
> > > struct mm_struct *mm;
> > > diff --git a/mm/as_dirty_helpers.c b/mm/as_dirty_helpers.c
> > > index f600e31534fb..7c863626c2a4 100644
> > > --- a/mm/as_dirty_helpers.c
> > > +++ b/mm/as_dirty_helpers.c
> > > @@ -26,7 +26,6 @@ struct apply_as {
> > > /**
> > > * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
> > > * @pte: Pointer to the pte
> > > - * @token: Page table token, see apply_to_pfn_range()
> > > * @addr: The virtual page address
> > > * @closure: Pointer to a struct pfn_range_apply embedded in a
> > > * struct apply_as
> > > @@ -36,8 +35,7 @@ struct apply_as {
> > > *
> > > * Return: Always zero.
> > > */
> > > -static int apply_pt_wrprotect(pte_t *pte, pgtable_t token,
> > > - unsigned long addr,
> > > +static int apply_pt_wrprotect(pte_t *pte, unsigned long addr,
> > > struct pfn_range_apply *closure)
> > > {
> > > struct apply_as *aas = container_of(closure, typeof(*aas), base);
> > > @@ -78,7 +76,6 @@ struct apply_as_clean {
> > > /**
> > > * apply_pt_clean - Leaf pte callback to clean a pte
> > > * @pte: Pointer to the pte
> > > - * @token: Page table token, see apply_to_pfn_range()
> > > * @addr: The virtual page address
> > > * @closure: Pointer to a struct pfn_range_apply embedded in a
> > > * struct apply_as_clean
> > > @@ -91,8 +88,7 @@ struct apply_as_clean {
> > > *
> > > * Return: Always zero.
> > > */
> > > -static int apply_pt_clean(pte_t *pte, pgtable_t token,
> > > - unsigned long addr,
> > > +static int apply_pt_clean(pte_t *pte, unsigned long addr,
> > > struct pfn_range_apply *closure)
> > > {
> > > struct apply_as *aas = container_of(closure, typeof(*aas), base);
> > > --
> > > 2.20.1
> > >
> > > --
> > > Cheers,
> > > Stephen Rothwell
> > >
> > > diff --cc mm/memory.c
> > > index 462aa47f8878,f8a75528658a..e7e37fcbd687
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@@ -2037,12 -2036,11 +2035,11 @@@ static int apply_to_pte_range(struct pf
> > > {
> > > pte_t *pte;
> > > int err;
> > > - pgtable_t token;
> > > spinlock_t *uninitialized_var(ptl);
> > >
> > > -pte = (mm == _mm) ?
> > > +pte = (closure->mm == _mm) ?
> > > pte_alloc_kernel(pmd, addr) :
> > > -pte_alloc_map_lock(mm, pmd, addr, );
> > > +pte_alloc_map_lock(closure->mm, pmd, addr, );
> > > if (!pte)
> > > return -ENOMEM;
> > >
> > > @@@ -2050,10 -2048,8 +2047,8 @@@
> > >
> > > arch_enter_lazy_mmu_mode();
> > >
> > > - token = pmd_pgtable(*pmd);
> > > -
> > > do {
> > > - err = closure->ptefn(pte++, token, addr, closure);
> > > -err = fn(pte++, addr, data);
> > > ++err = closure->ptefn(pte++, addr,
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #98 from Diego Viola --- (In reply to Diego Viola from comment #96) > Created attachment 144786 [details] > Yet another workaround (patch) for xterm > > Replacing FontHeight for VDrawable seems to help. VDrawable is just a big number, so same thing as Comment 86. Nevermind. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).
https://bugzilla.kernel.org/show_bug.cgi?id=197327 Carlos Fagiani Junior (fagianijun...@gmail.com) changed: What|Removed |Added CC||fagianijun...@gmail.com --- Comment #9 from Carlos Fagiani Junior (fagianijun...@gmail.com) --- Same here Now using Fedora 30, but has the same error on Ubuntu, Mint, Arch... Freeze the system on nomral use, without play game, only using terminal and some browser. Arch wiki say about some kernel parameter if system freeze. Like amdgpu.vm_update_mode=3 https://wiki.archlinux.org/index.php/AMDGPU $ uname -a Linux localhost.localdomain 5.1.16-300.fc30.x86_64 #1 SMP Wed Jul 3 15:06:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux $ lspci -nnk | grep -A3 -E "VGA|3D" 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] [1002:6613] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:2b0a] Kernel driver in use: radeon Kernel modules: radeon, amdgpu $ lspci | grep -i vga 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] [terabytes@localhost ~]$ dmesg | grep -i "failed VCE resume" -A7 -B20 [4.866787] [TTM] Zone kernel: Available graphics memory: 4089250 kiB [4.866787] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [4.866788] [TTM] Initializing pool allocator [4.866791] [TTM] Initializing DMA pool allocator [4.866803] [drm] radeon: 2048M of VRAM memory ready [4.866804] [drm] radeon: 2048M of GTT memory ready. [4.866810] [drm] Loading oland Microcode [4.866901] [drm] Internal thermal controller with fan control [4.872771] [drm] radeon: dpm initialized [4.873740] [drm] Found VCE firmware/feedback version 50.0.1 / 17! [4.873745] [drm] GART: num cpu pages 524288, num gpu pages 524288 [4.875721] [drm] PCIE gen 3 link speeds already enabled [4.894854] [drm] PCIE GART of 2048M enabled (table at 0x001D6000). [4.894945] radeon :06:00.0: WB enabled [4.894948] radeon :06:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0xea0b3c38 [4.894949] radeon :06:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0xdcc08c7b [4.894950] radeon :06:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0xb65a3e68 [4.894951] radeon :06:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0xdb9596a3 [4.894952] radeon :06:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0xe2fb734a [4.895165] radeon :06:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xe02858d4 [4.996189] radeon :06:00.0: failed VCE resume (-110). [4.996192] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [4.996192] [drm] Driver supports precise vblank timestamp query. [4.996193] radeon :06:00.0: radeon: MSI limited to 32-bit [4.996241] radeon :06:00.0: radeon: using MSI. [4.996263] [drm] radeon: irq initialized. [5.205989] [drm] ring test on 0 succeeded in 1 usecs [5.205993] [drm] ring test on 1 succeeded in 1 usecs -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #60 from Michael Eagle --- I am seeing reports with old BIOS, such as F.19. I have a 15-cp0001na https://support.hp.com/ie-en/drivers/selfservice/hp-envy-15-cp-x360-convertible-pc/20270303/model/23086446 Latest available is F.42 Rev.A I am wondering if by any chance would be a match to other models also. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
I am seeing reports with old BIOS, such as F.19. I have a 15-cp0001na https://support.hp.com/ie-en/drivers/selfservice/hp-envy-15-cp-x360-convertible-pc/20270303/model/23086446 Latest available is F.42 Rev.A I am wondering if by any chance would be a match to other models also. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/6] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 51 +++
drivers/gpu/drm/drm_hdcp.c| 36 +++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +-
include/drm/drm_connector.h | 7
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 4 ++
8 files changed, 111 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index abe38bdf85ae..19ae119f1a5d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
state->hdr_output_metadata->base.id : 0;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 068d4b05f1be..1dea923badd3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -952,6 +952,57 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
*
+ * HDCP Content Type:
+ * This Enum property is used by the userspace to declare the content type
+ * of the display stream, to kernel. Here display stream stands for any
+ * display content that userspace intended to display through HDCP
+ * encryption.
+ *
+ * Content Type of a stream is decided by the owner of the stream, as
+ * "HDCP Type0" or "HDCP Type1".
+ *
+ * The value of the property can be one of the below:
+ * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ *
+ * When kernel starts the HDCP authentication (see "Content Protection"
+ * for details), it uses the content type in "HDCP Content Type"
+ * for performing the HDCP authentication with the display sink.
+ *
+ * Please note in HDCP spec versions, a link can be authenticated with
+ * HDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be
+ * authenticated with HDCP1.4 only for Content Type 0(though it is implicit
+ * in nature. As there is no reference for Content Type in HDCP1.4).
+ *
+ * HDCP2.2 authentication protocol itself takes the "Content Type" as a
+ * parameter, which is a input for the DP HDCP2.2 encryption algo.
+ *
+ * In case of Type 0 content protection request, kernel driver can choose
+ * either of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for
+ * "HDCP Type 0", a HDCP 2.2 capable repeater in the downstream can send
+ * that content to a HDCP 1.4 authenticated HDCP sink (Type0 link).
+ * But if the content is classified as
[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 --- Comment #5 from Daniel Kolesa (li...@octaforge.org) --- Nevermind. Seems like I was able to hit the same problem today. It did not happen on video playback though, just randomly, after about a day or two of uptime. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] docs: remove extra conf.py files
Now that the latex_documents are handled automatically, we can
remove those extra conf.py files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/conf.py | 10 --
Documentation/core-api/conf.py | 10 --
Documentation/crypto/conf.py | 10 --
Documentation/dev-tools/conf.py| 10 --
Documentation/doc-guide/conf.py| 10 --
Documentation/driver-api/80211/conf.py | 10 --
Documentation/driver-api/conf.py | 10 --
Documentation/driver-api/pm/conf.py| 10 --
Documentation/filesystems/conf.py | 10 --
Documentation/gpu/conf.py | 10 --
Documentation/input/conf.py| 10 --
Documentation/kernel-hacking/conf.py | 10 --
Documentation/maintainer/conf.py | 10 --
Documentation/media/conf.py| 12
Documentation/networking/conf.py | 10 --
Documentation/process/conf.py | 10 --
Documentation/sh/conf.py | 10 --
Documentation/sound/conf.py| 10 --
Documentation/userspace-api/conf.py| 10 --
Documentation/vm/conf.py | 10 --
Documentation/x86/conf.py | 10 --
21 files changed, 212 deletions(-)
delete mode 100644 Documentation/admin-guide/conf.py
delete mode 100644 Documentation/core-api/conf.py
delete mode 100644 Documentation/crypto/conf.py
delete mode 100644 Documentation/dev-tools/conf.py
delete mode 100644 Documentation/doc-guide/conf.py
delete mode 100644 Documentation/driver-api/80211/conf.py
delete mode 100644 Documentation/driver-api/conf.py
delete mode 100644 Documentation/driver-api/pm/conf.py
delete mode 100644 Documentation/filesystems/conf.py
delete mode 100644 Documentation/gpu/conf.py
delete mode 100644 Documentation/input/conf.py
delete mode 100644 Documentation/kernel-hacking/conf.py
delete mode 100644 Documentation/maintainer/conf.py
delete mode 100644 Documentation/media/conf.py
delete mode 100644 Documentation/networking/conf.py
delete mode 100644 Documentation/process/conf.py
delete mode 100644 Documentation/sh/conf.py
delete mode 100644 Documentation/sound/conf.py
delete mode 100644 Documentation/userspace-api/conf.py
delete mode 100644 Documentation/vm/conf.py
delete mode 100644 Documentation/x86/conf.py
diff --git a/Documentation/admin-guide/conf.py
b/Documentation/admin-guide/conf.py
deleted file mode 100644
index 86f738953799..
--- a/Documentation/admin-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel User Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'linux-user.tex', 'Linux Kernel User Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py
deleted file mode 100644
index db1f7659f3da..
--- a/Documentation/core-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Core-API Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'core-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/crypto/conf.py b/Documentation/crypto/conf.py
deleted file mode 100644
index 4335d251ddf3..
--- a/Documentation/crypto/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Crypto API'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'crypto-api.tex', 'Linux Kernel Crypto API manual',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/dev-tools/conf.py b/Documentation/dev-tools/conf.py
deleted file mode 100644
index 7faafa3f7888..
--- a/Documentation/dev-tools/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Development tools for the kernel"
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'dev-tools.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/doc-guide/conf.py b/Documentation/doc-guide/conf.py
deleted file mode 100644
index fd3731182d5a..
--- a/Documentation/doc-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Documentation Guide'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/80211/conf.py
b/Documentation/driver-api/80211/conf.py
deleted file mode 100644
index 4424b4b0b9c3..
--- a/Documentation/driver-api/80211/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux 802.11 Driver Developer's
[PATCH 0/8] docs: some improvements when producing PDF files
Hi Jon,
This series addresses your concerns related to CJK fonts that are
needed for translations.pdf.
It touches only the documentation build system, not the docs
themselves.
It ended to be bigger than I originally foreseen, as I found several issues
when running "make pdfdocs" for the distros that are recognized by
the scripts/sphinx-pre-install script.
It also took a lot of time, as I tested it with several VMs (each
one updated to latest packages):
- Fedora 30, CentOS 7, Mageia 7, ArchLinux, Ubuntu 18.04, Gentoo,
OpenSuse Tumbleweed.
Patch 1 addresses an issue that could be related to the fact that I
don't use openSUSE. Basically, I was unable to find the right package
for texlive to use CJK fonts on openSUSE. [1]. So, the first patch on this
series adds a workaround: if the needed CJK font is not found on a
system, conf.py won't use xeCjk extension. That sounds a good
thing to have, as other distros may not package it, or maybe the
one building the doc is not that interested on translations.pdf file;
[1] I actually found some, but they are not recognized with the
font name conf.py is expecting ("Noto Sans CJK SC"). Perhaps
SUSE uses a different name for those fonts?
Patch 2 fixes the logic with recognizes CentOS/RHEL;
Patch 3 is another workaround: CentOS 7 (and similar distros) don't
package all texlive packages we need. So, it just ignores PDF when
recommending packages on such distros, and point to a URL with
explains how to install TexLive outside distro-specific package
management (for the brave enough people);
Patch 4 fixes latexmk dependency on a few distros;
Patch 5 suppreses a Gentoo specific instruction if the user already
followed in the past;
Patch 6 is the one that actually does what you requested.
Patch 7 solves an issue when SPHINXDIRS is used with make pdfdocs:
right now, using it will produce a lot of warnings and won't do anything,
if a dir-specific conf.py file is not found. With the patch, latex_documents
are now properly updated when SPHINXDIRS is used.
Patch 8 is a cleanup: with patch 7 applied, we don't need to have anymore
any conf.py file due to pdfdocs.
With regard to the load_config.py extension, It keeps accepting custom
configuration. That's helpful if someone wants, for example, to have
something like:
Documentation/media/conf_nitpick.py
with would enable extra nitpick options if one wants that.
-
Jon,
Please let me know if you prefer if I submit those together with the big
pile of doc files I have, or if you prefer adding (some of?) them on your
tree after the merge window.
Regards,
Mauro
Mauro Carvalho Chehab (8):
docs: conf.py: only use CJK if the font is available
scripts/sphinx-pre-install: fix script for RHEL/CentOS
scripts/sphinx-pre-install: don't use LaTeX with CentOS 7
scripts/sphinx-pre-install: fix latexmk dependencies
scripts/sphinx-pre-install: cleanup Gentoo checks
scripts/sphinx-pre-install: seek for Noto CJK fonts for pdf output
docs: load_config.py: avoid needing a conf.py just due to LaTeX docs
docs: remove extra conf.py files
Documentation/admin-guide/conf.py | 10 ---
Documentation/conf.py | 13 ++-
Documentation/core-api/conf.py | 10 ---
Documentation/crypto/conf.py | 10 ---
Documentation/dev-tools/conf.py| 10 ---
Documentation/doc-guide/conf.py| 10 ---
Documentation/driver-api/80211/conf.py | 10 ---
Documentation/driver-api/conf.py | 10 ---
Documentation/driver-api/pm/conf.py| 10 ---
Documentation/filesystems/conf.py | 10 ---
Documentation/gpu/conf.py | 10 ---
Documentation/input/conf.py| 10 ---
Documentation/kernel-hacking/conf.py | 10 ---
Documentation/maintainer/conf.py | 10 ---
Documentation/media/conf.py| 12 ---
Documentation/networking/conf.py | 10 ---
Documentation/process/conf.py | 10 ---
Documentation/sh/conf.py | 10 ---
Documentation/sound/conf.py| 10 ---
Documentation/sphinx/load_config.py| 25 +-
Documentation/userspace-api/conf.py| 10 ---
Documentation/vm/conf.py | 10 ---
Documentation/x86/conf.py | 10 ---
scripts/sphinx-pre-install | 118 -
24 files changed, 131 insertions(+), 237 deletions(-)
delete mode 100644 Documentation/admin-guide/conf.py
delete mode 100644 Documentation/core-api/conf.py
delete mode 100644 Documentation/crypto/conf.py
delete mode 100644 Documentation/dev-tools/conf.py
delete mode 100644 Documentation/doc-guide/conf.py
delete mode 100644 Documentation/driver-api/80211/conf.py
delete mode 100644 Documentation/driver-api/conf.py
delete mode 100644 Documentation/driver-api/pm/conf.py
delete mode 100644 Documentation/filesystems/conf.py
delete mode 100644 Documentation/gpu/conf.py
delete mode 100644 Documentation/input/conf.py
delete mode 100644
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #97 from Diego Viola --- s/for/with/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #96 from Diego Viola --- Created attachment 144786 --> https://bugs.freedesktop.org/attachment.cgi?id=144786=edit Yet another workaround (patch) for xterm Replacing FontHeight for VDrawable seems to help. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dma-buf: Expand reservation_list to fill allocation
Am 12.07.19 um 10:03 schrieb Chris Wilson:
> Since kmalloc() will round up the allocation to the next slab size or
> page, it will normally return a pointer to a memory block bigger than we
> asked for. We can query for the actual size of the allocated block using
> ksize() and expand our variable size reservation_list to take advantage
> of that extra space.
>
> Signed-off-by: Chris Wilson
> Cc: Christian König
> Cc: Michel Dänzer
Reviewed-by: Christian König
BTW: I was wondering if we shouldn't replace the reservation_object_list
with a dma_fence_chain.
That would costs us a bit more memory and is slightly slower on querying
the fence in the container.
But it would be much faster on adding new fences and massively
simplifies waiting or returning all fences currently in the container.
Christian.
> ---
> drivers/dma-buf/reservation.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index a6ac2b3a0185..80ecc1283d15 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -153,7 +153,9 @@ int reservation_object_reserve_shared(struct
> reservation_object *obj,
> RCU_INIT_POINTER(new->shared[j++], fence);
> }
> new->shared_count = j;
> - new->shared_max = max;
> + new->shared_max =
> + (ksize(new) - offsetof(typeof(*new), shared)) /
> + sizeof(*new->shared);
>
> preempt_disable();
> write_seqcount_begin(>seq);
> @@ -169,7 +171,7 @@ int reservation_object_reserve_shared(struct
> reservation_object *obj,
> return 0;
>
> /* Drop the references to the signaled fences */
> - for (i = k; i < new->shared_max; ++i) {
> + for (i = k; i < max; ++i) {
> struct dma_fence *fence;
>
> fence = rcu_dereference_protected(new->shared[i],
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
