* Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
From: Emil Velikov @ 2020-02-20 12:00 UTC (permalink / raw)
To: Ville Syrjala
Cc: Neil Armstrong, ML nouveau, Guido Günther, ML dri-devel,
Andrzej Hajda, Laurent Pinchart, Sam Ravnborg, Thomas Hellstrom,
Joonyoung Shim, Stefan Mavrodiev, Jerry Han, VMware Graphics,
Jagan Teki, Robert Chiras, Icenowy Zheng, Jonas Karlman,
Intel Graphics Development, Ben Skeggs, linux-amlogic,
Vincent Abriou, Jernej Skrabec, Purism Kernel Team, Seung-Woo Kim,
Kyungmin Park
In-Reply-To: <20200219203544.31013-5-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro in ch7006_mode.c
Speaking of ch7006_mode.c, it has its own "fixed vrefresh", which
doesn't seem to be used anywhere.
One could potentially nuke it, although it can be a completely separate patch.
This patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce PG_state_uninitialised
From: Jan Beulich @ 2020-02-20 11:59 UTC (permalink / raw)
To: David Woodhouse
Cc: sstabellini@kernel.org, julien@xen.org, wl@xen.org,
konrad.wilk@oracle.com, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
george.dunlap@citrix.com, jeff.kubascik@dornerworks.com,
Xia, Hongyan, stewart.hildebrand@dornerworks.com,
xen-devel@lists.xenproject.org
In-Reply-To: <f5b6325a469352585d7cf1d7d01d2dc4a2f2af8f.camel@infradead.org>
On 07.02.2020 19:04, David Woodhouse wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -488,7 +488,8 @@ void share_xen_page_with_guest(struct page_info *page, struct domain *d,
>
> page_set_owner(page, d);
> smp_wmb(); /* install valid domain ptr before updating refcnt. */
> - ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> + ASSERT((page->count_info & ~PGC_xen_heap) == PGC_state_inuse ||
> + (page->count_info & ~PGC_xen_heap) == PGC_state_uninitialised);
Can uninitialized pages really make it here?
> @@ -1389,6 +1391,16 @@ static void free_heap_pages(
> ASSERT(order <= MAX_ORDER);
> ASSERT(node >= 0);
>
> + if ( page_state_is(pg, uninitialised) )
> + {
> + init_heap_pages(pg, 1 << order, need_scrub);
> + /*
> + * init_heap_pages() will call back into free_heap_pages() for
> + * each page but cannot keep recursing because each page will
> + * be set to PGC_state_inuse first.
> + */
> + return;
> + }
> spin_lock(&heap_lock);
Can you also add a blank line above here please?
> @@ -1780,11 +1792,10 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
> * latter is not on a MAX_ORDER boundary, then we reserve the page by
> * not freeing it to the buddy allocator.
> */
> -static void init_heap_pages(
> - struct page_info *pg, unsigned long nr_pages)
> +static void init_heap_pages(struct page_info *pg, unsigned long nr_pages,
> + bool scrub)
Is this new parameter strictly needed, i.e. can free_heap_pages()
be called with uninitialized pages which need scrubbing? (The
code change is simple enough, and hence may warrant keeping, but
then the commit message could indicate so in case this isn't a
strict requirement.)
> @@ -2301,10 +2316,11 @@ int assign_pages(
> for ( i = 0; i < (1 << order); i++ )
> {
> ASSERT(page_get_owner(&pg[i]) == NULL);
> - ASSERT(!pg[i].count_info);
> + ASSERT(pg[i].count_info == PGC_state_inuse ||
> + pg[i].count_info == PGC_state_uninitialised);
Same question here: Can uninitialized pages make it here? If
so, wouldn't it be better to correct this, rather than having
the more permissive assertion?
> page_set_owner(&pg[i], d);
> smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
> - pg[i].count_info = PGC_allocated | 1;
> + pg[i].count_info |= PGC_allocated | 1;
This is too relaxed for my taste: I understand you want to
retain page state, but I suppose other bits would want clearing
nevertheless.
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -72,12 +72,13 @@
> * { inuse, offlining, offlined, free, broken_offlining, broken }
> */
> #define PGC_state PG_mask(7, 9)
> -#define PGC_state_inuse PG_mask(0, 9)
> +#define PGC_state_uninitialised PG_mask(0, 9)
> #define PGC_state_offlining PG_mask(1, 9)
> #define PGC_state_offlined PG_mask(2, 9)
> #define PGC_state_free PG_mask(3, 9)
> #define PGC_state_broken_offlining PG_mask(4, 9)
> #define PGC_state_broken PG_mask(5, 9)
> +#define PGC_state_inuse PG_mask(6, 9)
Would imo be nice if this most common state was actually
either 1 or 7, for easy recognition. But the most suitable
value to pick may also depend on the outcome of one of the
comments on patch 1.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 04/12] drm: Nuke mode->vrefresh
From: Emil Velikov @ 2020-02-20 12:00 UTC (permalink / raw)
To: Ville Syrjala
Cc: Neil Armstrong, ML nouveau, Guido Günther, ML dri-devel,
Andrzej Hajda, Thierry Reding, Laurent Pinchart, Sam Ravnborg,
Thomas Hellstrom, Joonyoung Shim, Stefan Mavrodiev, Jerry Han,
VMware Graphics, Jagan Teki, Robert Chiras, Icenowy Zheng,
Jonas Karlman, Intel Graphics Development, Ben Skeggs,
linux-amlogic, Vincent Abriou, Jernej Skrabec, Purism Kernel Team,
Seung-Woo Kim, Kyungmin Park
In-Reply-To: <20200219203544.31013-5-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro in ch7006_mode.c
Speaking of ch7006_mode.c, it has its own "fixed vrefresh", which
doesn't seem to be used anywhere.
One could potentially nuke it, although it can be a completely separate patch.
This patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] gstreamer: Fix reproducibility issue around libcap
From: Richard Purdie @ 2020-02-20 12:00 UTC (permalink / raw)
To: Martin Hundebøll, openembedded-core
In-Reply-To: <f7970658-f3a4-051c-cd6b-b40d2b72b61c@geanix.com>
On Thu, 2020-02-20 at 12:56 +0100, Martin Hundebøll wrote:
> On 19/02/2020 16.23, Richard Purdie wrote:
> > Add an option to avoid builds depending on the presence of setcap
> > from the host system.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > .../gstreamer/gstreamer1.0/capfix.patch | 37 +++++++++++++++++++
> > .../gstreamer/gstreamer1.0_1.16.1.bb | 2 +
> > 2 files changed, 39 insertions(+)
> > create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> >
> > diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> > new file mode 100644
> > index 00000000000..7ca3d5ad4a6
> > --- /dev/null
> > +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> > @@ -0,0 +1,37 @@
> > +Currently gstreamer configuration depends on whether setcap is found on the host
> > +system. Turn this into a configure option to make builds deterinistic.
> > +
> > +RP 2020/2/19
> > +Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > +Upstream-Status: Pending
> > +
> > +Index: gstreamer-1.16.1/libs/gst/helpers/meson.build
> > +===================================================================
> > +--- gstreamer-1.16.1.orig/libs/gst/helpers/meson.build
> > ++++ gstreamer-1.16.1/libs/gst/helpers/meson.build
> > +@@ -73,7 +73,12 @@ if have_ptp
> > + endif
> > + endif
> > +
> > +- setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> > ++ setcap_feature = get_option('setcap')
> > ++ if setcap_feature.disabled()
> > ++ setcap = find_program('dontexist', required : false)
> > ++ else
> > ++ setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> > ++ endif
>
> I think this can be simplified by using get_option() directly for the
> "required" argument:
>
> setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap',
> required : get_option('setcap'))
Yes, that looks better. I'm no meson expert, this is the first time
I've touched it.
I'd love if it someone was able to get this resolved with upstream.
I've been trying to work on getting various things fixed upstream (e.g.
some of the perl changes) but I'm having to take a practical view in
some areas. Getting the autobuilder stable/working sanely is currently
more of a priority than getting involved in a discussion with upstream
on something I know little about :/.
I've merged this patch but if anyone wants to improve it, I'm fine with
that.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 04/12] drm: Nuke mode->vrefresh
From: Emil Velikov @ 2020-02-20 12:00 UTC (permalink / raw)
To: Ville Syrjala
Cc: Neil Armstrong, ML nouveau, Guido Günther, ML dri-devel,
Andrzej Hajda, Laurent Pinchart, Sam Ravnborg, Thomas Hellstrom,
Joonyoung Shim, Stefan Mavrodiev, Jerry Han, VMware Graphics,
Jagan Teki, Robert Chiras, Icenowy Zheng, Jonas Karlman,
Intel Graphics Development, Ben Skeggs, linux-amlogic,
Vincent Abriou
In-Reply-To: <20200219203544.31013-5-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> - Fix __MODE() macro in ch7006_mode.c
Speaking of ch7006_mode.c, it has its own "fixed vrefresh", which
doesn't seem to be used anywhere.
One could potentially nuke it, although it can be a completely separate patch.
This patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [yocto] Bitbake returning non-zero due to sstate errors
From: Paul Barker @ 2020-02-20 11:59 UTC (permalink / raw)
To: Richard Purdie; +Cc: Yocto discussion list
In-Reply-To: <bfe6eb79ff352439c3ed5d53757421dce5e0b17d.camel@linuxfoundation.org>
On Thu, 20 Feb 2020 at 11:36, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2020-02-20 at 11:26 +0000, Paul Barker wrote:
> > In my new CI setup I'm using an sstate mirror which seems to have
> > some
> > occasional download issues. This results in the setscene task
> > failing.
> > For example:
> >
> > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> > do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> > file://fd/sstate:qt3d:armv7at2hf-neon-linux-
> > gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> > 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-
> > neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> > neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> > 74_package_write_ipk.tgz
> > anywhere. The paths that were searched were:
> > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> > /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> > ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> > do_package_write_ipk_setscene: No suitable staging package found
> > ERROR: Logfile of failure stored in:
> > /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-
> > linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-
> > r0/temp/log.do_package_write_ipk_setscene.10524
> > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> > do_package_write_ipk_setscene: Failed
> > WARNING: Setscene task
> > (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-
> > qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> > failed with exit code '1' - real task will be run instead
> >
> > As indicated in the final warning message there the real tasks run
> > since no sstate artifact is available. These tasks succeed:
> >
> > NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> > do_package_write_ipk: Succeeded
> >
> > The result is a successful build of the desired images. However, the
> > build is marked as a failure due to those sstate errors:
> >
> > Summary: There were 11 ERROR messages shown, returning a non-zero
> > exit code.
> >
> > Is this the expected behaviour? The final images are built correctly.
> > I can't see any simple way to mask those setscene errors but I might
> > be missing something.
> >
> > The full log can be seen at
> > https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> > I'm on the zeus branch here, I'll try to re-test on master later if I
> > can.
>
> We've discussed this before and it can be argued either way.
>
> Personally, I worry about why artefacts "disappear" and this is why its
> an error, files should not be disappearing part way through a build.
>
> From a bitbake perspective, a task really did fail and task failures
> are errors. The fact it was able to recover is a bonus.
>
> Perhaps it should be a warning now we have levels of warnings that are
> meaningful. Previously we threw so many, this would have been one more
> lost amongst many. I know many people don't like the behaviour.
I'm now looking into this...
In sstate_checkhashes() we mark sstate as available if
fetcher.checkstatus() succeeds. Then at a later point
sstate_setscene() calls sstate_installpkg() calls pstaging_fetch()
calls fetcher.download() to actually get the sstate artifact. If the
artifact is removed from the mirror between these two accesses (due to
an sstate mirror clean up running in parallel to a build), or if there
is an intermittent download failure we could see checkstatus() succeed
then download() fail.
I don't think we should ignore all setscene errors but in the specific
case where it's the download step that fails I think that should be a
warning. Or it could be an error by default with a variable we can set
to turn it into a warning. Does that sound reasonable? If so I'll work
up a patch.
Thanks,
Paul
^ permalink raw reply
* Re: [RFC] Volume control across multiple registers
From: Mark Brown @ 2020-02-20 11:59 UTC (permalink / raw)
To: Dan Murphy; +Cc: lgirdwood, perex, tiwai, alsa-devel, linux-kernel
In-Reply-To: <2f74b971-4a6a-016f-8121-4da941eeccef@ti.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Wed, Feb 19, 2020 at 03:11:47PM -0600, Dan Murphy wrote:
> I was looking at using the DAPM calls and use PGA_E and define an event but
> there really is no good way to get the current volume setting.
Store it in a variable in the driver's private data (there's a number of
examples of doing that for various controls, the process doesn't change
just because it's a volume), or if you've got a register cache it could
be just as easy to do the register reads and combine the values.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] Dump QCOW2 metadata
From: Max Reitz @ 2020-02-20 11:58 UTC (permalink / raw)
To: Andrey Shinkevich, qemu-block; +Cc: kwolf, vsementsov, qemu-devel, armbru, den
In-Reply-To: <1578990137-308222-1-git-send-email-andrey.shinkevich@virtuozzo.com>
[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]
On 14.01.20 09:22, Andrey Shinkevich wrote:
> The information about QCOW2 metadata allocations in an image ELF-file is
> helpful for finding issues with the image data integrity.
Sorry that I’m replying only so late – but I don’t know why we need this
in qemu, and this cover letter doesn’t provide a justification. I mean,
it isn’t too complex (from the diffstat), but wouldn’t it be better to
just have a script for this?
I suppose one reason to put it in qemu/qemu-img is that a script
wouldn’t be packaged by distributions. So if a user has a corrupted
image, with this series we could tell them to run qemu-img check -M and
put the output somewhere. With a script, we’d first have to tell them
to download the script. But then again, downloading a script (that
should be part of the qemu repository) doesn’t seem too much trouble to
me either.
So I’m curious as to whether you had a specific reason in mind when you
decided to implement this as part of qemu itself?
(I suppose the additional complexity is fully limited to the check
infrastructure, so it wouldn’t interfere with the rest of the qcow2
driver. Hm. Fair enough.)
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 3/5] powerpc/irq: Use current_stack_pointer in check_stack_overflow()
From: Michael Ellerman @ 2020-02-20 11:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>
From: Christophe Leroy <christophe.leroy@c-s.fr>
The purpose of check_stack_overflow() is to verify that the stack has
not overflowed.
To really know whether the stack pointer is still within boundaries,
the check must be done directly on the value of r1.
So use current_stack_pointer, which returns the current value of r1,
rather than current_stack_frame() which causes a frame to be created
and then returns that value.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/435e0030e942507766cbef5bc95f906262d2ccf2.1579849665.git.christophe.leroy@c-s.fr
---
arch/powerpc/kernel/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 02118c18434d..c7d6f5cdffdb 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -602,7 +602,7 @@ static inline void check_stack_overflow(void)
#ifdef CONFIG_DEBUG_STACKOVERFLOW
long sp;
- sp = current_stack_frame() & (THREAD_SIZE-1);
+ sp = current_stack_pointer & (THREAD_SIZE - 1);
/* check for stack overflow: is there less than 2KB free? */
if (unlikely(sp < 2048)) {
--
2.21.1
v3: s/get_sp()/current_stack_pointer/
^ permalink raw reply related
* Please pull mmc mmc-2-20-2020
From: Peng Fan @ 2020-02-20 11:58 UTC (permalink / raw)
To: u-boot
Hi Tom
Please pull mmc-2-20-2020.
I redo CI with Masahiro's fix, and no issue.
------------------------------------
sdhci: code clean-up and fix cache coherency problem
enable cache snooping on mpc830x
Fix build error when MMC_WRITE disabled
------------------------------------
CI:
https://travis-ci.org/MrVan/u-boot/builds/652853505
Thanks,
Peng.
The following changes since commit f2a73d6867ef973fbb8471cc87058205999b5e5c:
Merge tag 'u-boot-stm32-20200214' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2020-02-14 07:31:47 -0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-2-20-2020
for you to fetch changes up to 4155ad9aac9474610038b525da9eec8ad9afbc12:
mmc: sdhci: fix missing cache invalidation after reading by DMA (2020-02-20 15:09:57 +0800)
----------------------------------------------------------------
Bharat Kumar Reddy Gooty (1):
drivers: mmc: rpmb: Use R1 response
Jaehoon Chung (1):
mmc: fix the build error when MMC_WRITE is disabled
Masahiro Yamada (14):
mmc: sdhci-cadence: send tune request twice to work around errata
mmc: check the return value of mmc_select_mode_and_width()
mmc: remove unneeded forward declarations
dma-mapping: fix the prototype of dma_map_single()
dma-mapping: fix the prototype of dma_unmap_single()
dma-mapping: move dma_map_(un)single() to <linux/dma-mapping.h>
dma-mapping: add <asm/dma-mapping.h> for all architectures
mmc: sdhci: put the aligned buffer pointer to struct sdhci_host
mmc: sdhci: reduce code duplication for aligned buffer
mmc: sdhci: use lower_32_bit2() and upper_32_bits() for setting adma_addr
mmc: sdhci: remove unneeded casts
mmc: add mmc_get_dma_dir() helper
mmc: sdhci: use dma_map_single() instead of flush_cache() before DMA
mmc: sdhci: fix missing cache invalidation after reading by DMA
Rasmus Villemoes (1):
mmc: fsl_esdhc: actually enable cache snooping on mpc830x
arch/arc/include/asm/dma-mapping.h | 1 +
arch/arm/include/asm/dma-mapping.h | 29 +----------------------------
arch/m68k/include/asm/dma-mapping.h | 1 +
arch/microblaze/include/asm/dma-mapping.h | 1 +
arch/mips/include/asm/dma-mapping.h | 1 +
arch/nds32/include/asm/dma-mapping.h | 27 +--------------------------
arch/powerpc/include/asm/dma-mapping.h | 1 +
arch/riscv/include/asm/dma-mapping.h | 29 +----------------------------
arch/sandbox/include/asm/dma-mapping.h | 1 +
arch/sh/include/asm/dma-mapping.h | 1 +
arch/x86/include/asm/dma-mapping.h | 29 +----------------------------
arch/xtensa/include/asm/dma-mapping.h | 1 +
drivers/dma/ti/k3-udma.c | 2 +-
drivers/mmc/fsl_esdhc.c | 15 +++++++++++++--
drivers/mmc/mmc.c | 8 +++-----
drivers/mmc/rpmb.c | 5 +++++
drivers/mmc/sdhci-cadence.c | 21 +++++++++++++++++----
drivers/mmc/sdhci.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------
drivers/mmc/tmio-common.c | 5 ++---
drivers/mtd/nand/raw/denali.c | 5 ++---
drivers/net/altera_tse.c | 2 +-
drivers/net/ftmac110.c | 2 +-
drivers/net/macb.c | 4 ++--
drivers/soc/ti/k3-navss-ringacc.c | 2 +-
drivers/ufs/ufs.c | 2 +-
drivers/usb/cdns3/gadget.c | 2 +-
drivers/usb/dwc3/core.c | 8 ++++----
drivers/usb/dwc3/gadget.c | 2 +-
drivers/usb/gadget/udc/udc-core.c | 4 ++--
include/linux/dma-mapping.h | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/mmc.h | 6 ++++++
include/sdhci.h | 3 +++
32 files changed, 187 insertions(+), 192 deletions(-)
create mode 100644 arch/arc/include/asm/dma-mapping.h
create mode 100644 arch/m68k/include/asm/dma-mapping.h
create mode 100644 arch/microblaze/include/asm/dma-mapping.h
create mode 100644 arch/mips/include/asm/dma-mapping.h
create mode 100644 arch/powerpc/include/asm/dma-mapping.h
create mode 100644 arch/sandbox/include/asm/dma-mapping.h
create mode 100644 arch/sh/include/asm/dma-mapping.h
create mode 100644 arch/xtensa/include/asm/dma-mapping.h
create mode 100644 include/linux/dma-mapping.h
^ permalink raw reply
* Re: [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed
From: Lu Baolu @ 2020-02-20 11:58 UTC (permalink / raw)
To: Daniel Drake; +Cc: bhelgaas, linux, iommu, dwmw2, jonathan.derrick
In-Reply-To: <20200220100607.9044-1-drake@endlessm.com>
Hi,
On 2020/2/20 18:06, Daniel Drake wrote:
>> On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>>> With respect, this is problematical. The parent and all subdevices share
>>> a single translation entry. The DMA mask should be consistent.
>>>
>>> Otherwise, for example, subdevice A has 64-bit DMA capability and uses
>>> an identity domain for DMA translation. While subdevice B has 32-bit DMA
>>> capability and is forced to switch to DMA domain. Subdevice A will be
>>> impacted without any notification.
> Looking closer, this problematic codepath may already be happening for VMD,
> under intel_iommu_add_device(). Consider this function running for a VMD
> subdevice, we hit:
>
> domain = iommu_get_domain_for_dev(dev);
>
> I can't quite grasp the code flow here, but domain->type now always seems
> to return the domain type of the real DMA device, which seems like pretty
> reasonable behaviour.
>
> if (domain->type == IOMMU_DOMAIN_DMA) {
>
> and as detailed in previous mails, the real VMD device seems to be in a DMA
> domain by default, so we continue.
>
> if (device_def_domain_type(dev) == IOMMU_DOMAIN_IDENTITY) {
>
> Now we checked the default domain type of the subdevice. This seems rather
> likely to return IDENTITY because that's effectively the default type...
>
> ret = iommu_request_dm_for_dev(dev);
> if (ret) {
> dmar_remove_one_dev_info(dev);
> dmar_domain->flags |= DOMAIN_FLAG_LOSE_CHILDREN;
> domain_add_dev_info(si_domain, dev);
> dev_info(dev,
> "Device uses a private identity domain.\n");
> }
> }
>
> and now we're doing the bad stuff that Lu pointed out: we only have one
> mapping shared for all the subdevices, so if we end up changing it for one
> subdevice, we're likely to be breaking another.
Yes. Agreed.
By the way, do all subdevices stay in a same iommu group?
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH v2 1/2] struct_union_enum_specifier: always initialize sym->scope
From: Oleg Nesterov @ 2020-02-20 11:57 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Alexey Gladkov, linux-sparse
In-Reply-To: <20200220005602.gd22zbd7c5qy4t6k@ltop.local>
On 02/20, Luc Van Oostenryck wrote:
>
> On Wed, Feb 19, 2020 at 05:29:11PM +0100, Oleg Nesterov wrote:
> > Currently it is not possible to figure out the scope of the private
> > struct/union/enum type, its ->scope is NULL because bind_symbol() is
> > not called.
> >
> > Change struct_union_enum_specifier() to set sym->scope = block_scope
> > in this case, this is what bind_symbol() does when type has a name.
>
> Thanks.
> I've just changed the comment to "used by dissect"
Great, thanks!
> because
> elsewhere the scope or toplevel()s only relevant for symbols.
Cough... can't resist ;)
Not really, see struct_union_enum_specifier()->is_outer_scope(). But
yes sure, this is only when ->ident != NULL.
Oleg.
^ permalink raw reply
* Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap().
From: Kirill A. Shutemov @ 2020-02-20 11:57 UTC (permalink / raw)
To: Brian Geffon
Cc: Andrew Morton, Michael S . Tsirkin, Arnd Bergmann, linux-kernel,
linux-mm, linux-api, Andy Lutomirski, Will Deacon,
Andrea Arcangeli, Sonny Rao, Minchan Kim, Joel Fernandes, Yu Zhao,
Jesse Barnes, Florian Weimer
In-Reply-To: <20200218173221.237674-1-bgeffon@google.com>
On Tue, Feb 18, 2020 at 09:32:20AM -0800, Brian Geffon wrote:
> When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is
> set, the source mapping will not be removed. The remap operation
> will be performed as it would have been normally by moving over the
> page tables to the new mapping. The old vma will have any locked
> flags cleared, have no pagetables, and any userfaultfds that were
> watching that range will continue watching it.
>
> For a mapping that is shared or not anonymous, MREMAP_DONTUNMAP will cause
> the mremap() call to fail. Because MREMAP_DONTUNMAP always results in moving
> a VMA you MUST use the MREMAP_MAYMOVE flag. The final result is two
> equally sized VMAs where the destination contains the PTEs of the source.
>
> We hope to use this in Chrome OS where with userfaultfd we could write
> an anonymous mapping to disk without having to STOP the process or worry
> about VMA permission changes.
>
> This feature also has a use case in Android, Lokesh Gidra has said
> that "As part of using userfaultfd for GC, We'll have to move the physical
> pages of the java heap to a separate location. For this purpose mremap
> will be used. Without the MREMAP_DONTUNMAP flag, when I mremap the java
> heap, its virtual mapping will be removed as well. Therefore, we'll
> require performing mmap immediately after. This is not only time consuming
> but also opens a time window where a native thread may call mmap and
> reserve the java heap's address range for its own usage. This flag
> solves the problem."
>
> v5 -> v6:
> - Code cleanup suggested by Kirill.
>
> v4 -> v5:
> - Correct commit message to more accurately reflect the behavior.
> - Clear VM_LOCKED and VM_LOCKEDONFAULT on the old vma.
>
> Signed-off-by: Brian Geffon <bgeffon@google.com>
> ---
> include/uapi/linux/mman.h | 5 +-
> mm/mremap.c | 103 ++++++++++++++++++++++++++++++--------
> 2 files changed, 85 insertions(+), 23 deletions(-)
>
> diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
> index fc1a64c3447b..923cc162609c 100644
> --- a/include/uapi/linux/mman.h
> +++ b/include/uapi/linux/mman.h
> @@ -5,8 +5,9 @@
> #include <asm/mman.h>
> #include <asm-generic/hugetlb_encode.h>
>
> -#define MREMAP_MAYMOVE 1
> -#define MREMAP_FIXED 2
> +#define MREMAP_MAYMOVE 1
> +#define MREMAP_FIXED 2
> +#define MREMAP_DONTUNMAP 4
>
> #define OVERCOMMIT_GUESS 0
> #define OVERCOMMIT_ALWAYS 1
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 1fc8a29fbe3f..fa27103502c5 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -318,8 +318,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
> static unsigned long move_vma(struct vm_area_struct *vma,
> unsigned long old_addr, unsigned long old_len,
> unsigned long new_len, unsigned long new_addr,
> - bool *locked, struct vm_userfaultfd_ctx *uf,
> - struct list_head *uf_unmap)
> + bool *locked, unsigned long flags,
> + struct vm_userfaultfd_ctx *uf, struct list_head *uf_unmap)
> {
> struct mm_struct *mm = vma->vm_mm;
> struct vm_area_struct *new_vma;
> @@ -408,11 +408,46 @@ static unsigned long move_vma(struct vm_area_struct *vma,
> if (unlikely(vma->vm_flags & VM_PFNMAP))
> untrack_pfn_moved(vma);
>
> + if (unlikely(!err && (flags & MREMAP_DONTUNMAP))) {
> + if (vm_flags & VM_ACCOUNT) {
> + /* Always put back VM_ACCOUNT since we won't unmap */
> + vma->vm_flags |= VM_ACCOUNT;
> +
> + vm_acct_memory(vma_pages(new_vma));
> + }
> +
> + /*
> + * locked_vm accounting: if the mapping remained the same size
> + * it will have just moved and we don't need to touch locked_vm
> + * because we skip the do_unmap. If the mapping shrunk before
> + * being moved then the do_unmap on that portion will have
> + * adjusted vm_locked. Only if the mapping grows do we need to
> + * do something special; the reason is locked_vm only accounts
> + * for old_len, but we're now adding new_len - old_len locked
> + * bytes to the new mapping.
> + */
> + if (vm_flags & VM_LOCKED && new_len > old_len) {
> + mm->locked_vm += (new_len - old_len) >> PAGE_SHIFT;
> + *locked = true;
> + }
> +
> + /* We always clear VM_LOCKED[ONFAULT] on the old vma */
> + vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> +
> + goto out;
> + }
> +
> if (do_munmap(mm, old_addr, old_len, uf_unmap) < 0) {
> /* OOM: unable to split vma, just get accounts right */
> vm_unacct_memory(excess >> PAGE_SHIFT);
> excess = 0;
> }
> +
> + if (vm_flags & VM_LOCKED) {
> + mm->locked_vm += new_len >> PAGE_SHIFT;
> + *locked = true;
> + }
> +out:
> mm->hiwater_vm = hiwater_vm;
>
> /* Restore VM_ACCOUNT if one or two pieces of vma left */
> @@ -422,16 +457,12 @@ static unsigned long move_vma(struct vm_area_struct *vma,
> vma->vm_next->vm_flags |= VM_ACCOUNT;
> }
>
> - if (vm_flags & VM_LOCKED) {
> - mm->locked_vm += new_len >> PAGE_SHIFT;
> - *locked = true;
> - }
> -
> return new_addr;
> }
>
> static struct vm_area_struct *vma_to_resize(unsigned long addr,
> - unsigned long old_len, unsigned long new_len, unsigned long *p)
> + unsigned long old_len, unsigned long new_len, unsigned long flags,
> + unsigned long *p)
> {
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma = find_vma(mm, addr);
> @@ -453,6 +484,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
> return ERR_PTR(-EINVAL);
> }
>
> + if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) ||
> + vma->vm_flags & VM_SHARED))
> + return ERR_PTR(-EINVAL);
> +
> if (is_vm_hugetlb_page(vma))
> return ERR_PTR(-EINVAL);
>
> @@ -497,7 +532,7 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
>
> static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> unsigned long new_addr, unsigned long new_len, bool *locked,
> - struct vm_userfaultfd_ctx *uf,
> + unsigned long flags, struct vm_userfaultfd_ctx *uf,
> struct list_head *uf_unmap_early,
> struct list_head *uf_unmap)
> {
> @@ -505,7 +540,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> struct vm_area_struct *vma;
> unsigned long ret = -EINVAL;
> unsigned long charged = 0;
> - unsigned long map_flags;
> + unsigned long map_flags = 0;
>
> if (offset_in_page(new_addr))
> goto out;
> @@ -534,9 +569,11 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> if ((mm->map_count + 2) >= sysctl_max_map_count - 3)
> return -ENOMEM;
>
> - ret = do_munmap(mm, new_addr, new_len, uf_unmap_early);
> - if (ret)
> - goto out;
> + if (flags & MREMAP_FIXED) {
> + ret = do_munmap(mm, new_addr, new_len, uf_unmap_early);
> + if (ret)
> + goto out;
> + }
>
> if (old_len >= new_len) {
> ret = do_munmap(mm, addr+new_len, old_len - new_len, uf_unmap);
> @@ -545,13 +582,26 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> old_len = new_len;
> }
>
> - vma = vma_to_resize(addr, old_len, new_len, &charged);
> + vma = vma_to_resize(addr, old_len, new_len, flags, &charged);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> goto out;
> }
>
> - map_flags = MAP_FIXED;
> + /*
> + * MREMAP_DONTUNMAP expands by new_len - (new_len - old_len), we will
> + * check that we can expand by new_len and vma_to_resize will handle
> + * the vma growing which is (new_len - old_len).
> + */
< Sorry for delay. >
I have hard time understanding the case when new_len != old_len.
Correct me if I'm wrong, but looks like that you change the size of old
mapping to be the new_len and then create a new of the same new_len.
This doesn't look right to me.
In my opinion, MREMAP_DONTUNMAP has to leave the old mapping intact. And
create the new mapping adjusted to the new_len.
Other option is to force new_len == old_len if MREMAP_DONTUNMAP is
specified. It would simplify the implementation. And I don't see why
anybody would really want anything else.
> + if (flags & MREMAP_DONTUNMAP &&
> + !may_expand_vm(mm, vma->vm_flags, new_len >> PAGE_SHIFT)) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + if (flags & MREMAP_FIXED)
> + map_flags |= MAP_FIXED;
> +
> if (vma->vm_flags & VM_MAYSHARE)
> map_flags |= MAP_SHARED;
>
> @@ -561,10 +611,16 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
> if (offset_in_page(ret))
> goto out1;
>
> - ret = move_vma(vma, addr, old_len, new_len, new_addr, locked, uf,
> + /* We got a new mapping */
> + if (!(flags & MREMAP_FIXED))
> + new_addr = ret;
> +
> + ret = move_vma(vma, addr, old_len, new_len, new_addr, locked, flags, uf,
> uf_unmap);
> +
> if (!(offset_in_page(ret)))
> goto out;
Not related to the effort directly, but do we really use offset_in_page()
as a substitute for IS_ERR() here. That's disgusting.
> +
> out1:
> vm_unacct_memory(charged);
>
> @@ -609,12 +665,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> addr = untagged_addr(addr);
> new_addr = untagged_addr(new_addr);
>
> - if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
> + if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_DONTUNMAP))
> return ret;
>
> if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
> return ret;
>
> + /* MREMAP_DONTUNMAP is always a move */
> + if (flags & MREMAP_DONTUNMAP && !(flags & MREMAP_MAYMOVE))
> + return ret;
> +
> if (offset_in_page(addr))
> return ret;
>
> @@ -632,9 +692,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> if (down_write_killable(¤t->mm->mmap_sem))
> return -EINTR;
>
> - if (flags & MREMAP_FIXED) {
> + if (flags & (MREMAP_FIXED | MREMAP_DONTUNMAP)) {
> ret = mremap_to(addr, old_len, new_addr, new_len,
> - &locked, &uf, &uf_unmap_early, &uf_unmap);
> + &locked, flags, &uf, &uf_unmap_early,
> + &uf_unmap);
> goto out;
> }
>
> @@ -662,7 +723,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> /*
> * Ok, we need to grow..
> */
> - vma = vma_to_resize(addr, old_len, new_len, &charged);
> + vma = vma_to_resize(addr, old_len, new_len, flags, &charged);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> goto out;
> @@ -712,7 +773,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> }
>
> ret = move_vma(vma, addr, old_len, new_len, new_addr,
> - &locked, &uf, &uf_unmap);
> + &locked, flags, &uf, &uf_unmap);
> }
> out:
> if (offset_in_page(ret)) {
> --
> 2.25.0.265.gbab2e86ba0-goog
>
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Andy Shevchenko @ 2020-02-20 11:57 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <CAHp75Vd3KN81qxOWJQ7v=GimSLtVymur_iPsf91pka1STc1nfA@mail.gmail.com>
On Thu, Feb 20, 2020 at 1:46 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Feb 20, 2020 at 12:57 PM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
...
> > Also I don't understand yet, what you want me to do.
>
> I have issues with kstrto() not playing with simple numbers (boolean
s/simple/simple and single/
> is a special case, but still a number at the end).
> I also don't feel good with too narrow usage of the newly introduced helper
>
> > Assume I'd be
> > willing to use simple_strtoul, I'd still want to have a function that
> > gives me a dev_t from a given string. Should I put this directly in my
> > led-trigger driver?
>
> I see the following possibilities:
(above doesn't imply the necessity of simple_strto*() use)
> a) put it inside the caller and forget about generic helper
> b) do a generic helper, but 1/ in string_*() namespace, 2/ with a
> delimiter parameter and 3/ possibility to take negative numbers
>
> In b) case, add to the commit message how many potential _existing_
> users may be converted to this.
> Also it would be good to have two versions strict (only \n at the end
> is allowed) and non-strict (based on the amount of users for each
> group).
And don't forget to extend lib/test_string.c accordingly.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jiri Olsa @ 2020-02-20 11:56 UTC (permalink / raw)
To: Jin Yao
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20200220005902.8952-1-yao.jin@linux.intel.com>
On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
> For perf report on stripped binaries it is currently impossible to do
> annotation. The annotation state is all tied to symbols, but there are
> either no symbols, or symbols are not covering all the code.
>
> We should support the annotation functionality even without symbols.
>
> The first patch uses al_addr to print because it's easy to dump
> the instructions from this address in binary for branch mode.
>
> The second patch supports the annotation on stripped binary.
>
> Jin Yao (2):
> perf util: Print al_addr when symbol is not found
> perf annotate: Support interactive annotation of code without symbols
looks good, but I'm getting crash when annotating unresolved kernel address:
jirka
Samples: 14 of event 'cycles:u', Event count (approx.): 1822321
Overhead Command Shared Object Symbol
26.86% ls libc-2.30.so [.] __strcoll_l ▒
17.03% ls ls [.] 0x0000000000008968 ▒
13.10% ls [unknown] [k] 0xffffffff81c00ae7 ▒
13.02% ls ld-2.30.so [.] _dl_cache_libcmp ▒
12.84% ls libc-2.30.so [.] _int_malloc ▒
11.94% ls libc-2.30.so [.] __memcpy_chk ▒
5.21% ls ld-2.30.so [.] __GI___tunables_init ▒
▒
Program received signal SIGSEGV, Segmentation fault. ▒
add_annotate_opt (browser=0xec34a0, act=0x7fffffffabf0, optstr=0x7fffffffab70, ms=0xdbdb60, addr=18446744071591430887) at ui/browsers/hists.c:2500 ▒
2500 if (ms->map->dso->annotate_warned) ▒
Missing separate debuginfos, use: dnf debuginfo-install brotli-1.0.7-6.fc31.x86_64 bzip2-libs-1.0.8-1.fc31.x86_64 cyrus-sasl-lib-2.1.27-2.fc31.x86_64 elfutils-debuginfod-client-0.178-7.fc31.x86_64 elfutils-libelf-0.178-7.fc31.x86_64 elfutils-libs-0.178-7.fc31.x86_64 glib2-2.62.5-1.fc31.x86_64 keyutils-libs-1.6-3.fc31.x86_64 krb5-libs-1.17-46.fc31.x86_64 libbabeltrace-1.5.7-2.fc31.x86_64 libcap-2.26-6.fc31.x86_64 libcom_err-1.45.5-1.fc31.x86_64 libcurl-7.66.0-1.fc31.x86_64 libgcc-9.2.1-1.fc31.x86_64 libidn2-2.3.0-1.fc31.x86_64 libnghttp2-1.40.0-1.fc31.x86_64 libpsl-0.21.0-2.fc31.x86_64 libselinux-2.9-5.fc31.x86_64 libssh-0.9.3-1.fc31.x86_64 libunwind-1.3.1-5.fc31.x86_64 libuuid-2.34-4.fc31.x86_64 libxcrypt-4.4.14-1.fc31.x86_64 libzstd-1.4.4-1.fc31.x86_64 openldap-2.4.47-3.fc31.x86_64 openssl-libs-1.1.1d-2.fc31.x86_64 pcre-8.43-3.fc31.x86_64 pcre2-10.34-6.fc31.x86_64 perl-libs-5.30.1-449.fc31.x86_64 popt-1.16-18.fc31.x86_64 python2-libs-2.7.17-1.fc31.x86_64 slang-2.3.2-6.fc31.x86_64 xz-libs-5.2.4-6.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64 ▒
(gdb) bt ▒
#0 add_annotate_opt (browser=0xec34a0, act=0x7fffffffabf0, optstr=0x7fffffffab70, ms=0xdbdb60, addr=18446744071591430887) at ui/browsers/hists.c:2500 ▒
#1 0x000000000061caf9 in perf_evsel__hists_browse (evsel=0xc58860, nr_events=1, helpline=0xef69f0 "Tip: Show current config key-value pairs: perf config --list", left_exits=false, hbt=0x0, min_pcnt=0, ▒
env=0xc5c7b0, warn_lost_event=true, annotation_opts=0x7fffffffb518) at ui/browsers/hists.c:3265 ▒
#2 0x000000000061dbc2 in perf_evlist__tui_browse_hists (evlist=0xc55ed0, help=0xef69f0 "Tip: Show current config key-value pairs: perf config --list", hbt=0x0, min_pcnt=0, env=0xc5c7b0, warn_lost_event=true, ▒
annotation_opts=0x7fffffffb518) at ui/browsers/hists.c:3569 ▒
#3 0x00000000004511e4 in report__browse_hists (rep=0x7fffffffb380) at builtin-report.c:630 ▒
#4 0x00000000004521db in __cmd_report (rep=0x7fffffffb380) at builtin-report.c:975 ▒
#5 0x000000000045444a in cmd_report (argc=0, argv=0x7fffffffd820) at builtin-report.c:1540 ▒
#6 0x00000000004e384a in run_builtin (p=0xa5b370 <commands+240>, argc=1, argv=0x7fffffffd820) at perf.c:312 ▒
#7 0x00000000004e3ab7 in handle_internal_command (argc=1, argv=0x7fffffffd820) at perf.c:364 ▒
#8 0x00000000004e3bfe in run_argv (argcp=0x7fffffffd67c, argv=0x7fffffffd670) at perf.c:408 ▒
#9 0x00000000004e3fca in main (argc=1, argv=0x7fffffffd820) at perf.c:538 ▒
(gdb) ▒
^ permalink raw reply
* [PATCH v3 2/5] powerpc: Add current_stack_pointer as a register global
From: Michael Ellerman @ 2020-02-20 11:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>
From: Christophe Leroy <christophe.leroy@c-s.fr>
current_stack_frame() doesn't return the stack pointer, but the
caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement
__get_SP() as a function not a define") and commit
acf620ecf56c ("powerpc: Rename __get_SP() to current_stack_pointer()")
for details.
In some cases this is overkill or incorrect, as it doesn't return the
current value of r1.
So add a current_stack_pointer register global to get the value of r1
directly.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Split out of other patch, tweak change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/435e0030e942507766cbef5bc95f906262d2ccf2.1579849665.git.christophe.leroy@c-s.fr
---
arch/powerpc/include/asm/reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1b1ffdba6097..da5cab038e25 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1450,6 +1450,8 @@ static inline void mtsrin(u32 val, u32 idx)
extern unsigned long current_stack_frame(void);
+register unsigned long current_stack_pointer asm("r1");
+
extern unsigned long scom970_read(unsigned int address);
extern void scom970_write(unsigned int address, unsigned long value);
--
2.21.1
v3: Split out, and use current_stack_pointer not get_sp()
^ permalink raw reply related
* Re: [PATCH] gstreamer: Fix reproducibility issue around libcap
From: Martin Hundebøll @ 2020-02-20 11:56 UTC (permalink / raw)
To: Richard Purdie, openembedded-core
In-Reply-To: <20200219152355.123718-1-richard.purdie@linuxfoundation.org>
Hi,
On 19/02/2020 16.23, Richard Purdie wrote:
> Add an option to avoid builds depending on the presence of setcap
> from the host system.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> .../gstreamer/gstreamer1.0/capfix.patch | 37 +++++++++++++++++++
> .../gstreamer/gstreamer1.0_1.16.1.bb | 2 +
> 2 files changed, 39 insertions(+)
> create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
>
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> new file mode 100644
> index 00000000000..7ca3d5ad4a6
> --- /dev/null
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> @@ -0,0 +1,37 @@
> +Currently gstreamer configuration depends on whether setcap is found on the host
> +system. Turn this into a configure option to make builds deterinistic.
> +
> +RP 2020/2/19
> +Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> +Upstream-Status: Pending
> +
> +Index: gstreamer-1.16.1/libs/gst/helpers/meson.build
> +===================================================================
> +--- gstreamer-1.16.1.orig/libs/gst/helpers/meson.build
> ++++ gstreamer-1.16.1/libs/gst/helpers/meson.build
> +@@ -73,7 +73,12 @@ if have_ptp
> + endif
> + endif
> +
> +- setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> ++ setcap_feature = get_option('setcap')
> ++ if setcap_feature.disabled()
> ++ setcap = find_program('dontexist', required : false)
> ++ else
> ++ setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> ++ endif
I think this can be simplified by using get_option() directly for the
"required" argument:
setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap',
required : get_option('setcap'))
// Martin
> +
> + # user/group to change to in gst-ptp-helper
> + ptp_helper_setuid_user = get_option('ptp-helper-setuid-user')
> +Index: gstreamer-1.16.1/meson_options.txt
> +===================================================================
> +--- gstreamer-1.16.1.orig/meson_options.txt
> ++++ gstreamer-1.16.1/meson_options.txt
> +@@ -26,6 +26,7 @@ option('libunwind', type : 'feature', va
> + option('libdw', type : 'feature', value : 'auto', description : 'Use libdw to generate better backtraces from libunwind')
> + option('dbghelp', type : 'feature', value : 'auto', description : 'Use dbghelp to generate backtraces')
> + option('bash-completion', type : 'feature', value : 'auto', description : 'Install bash completion files')
> ++option('setcap', type : 'feature', value : 'auto', description : 'Use setcap')
> +
> + # Common feature options
> + option('examples', type : 'feature', value : 'auto', yield : true)
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> index 6b8a5a0eb01..68f5ca649fe 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> @@ -21,6 +21,7 @@ SRC_URI = " \
> file://0002-meson-build-gir-even-when-cross-compiling-if-introsp.patch \
> file://0003-meson-Add-valgrind-feature.patch \
> file://0004-meson-Add-option-for-installed-tests.patch \
> + file://capfix.patch \
> "
> SRC_URI[md5sum] = "c505fb818b36988daaa846e9e63eabe8"
> SRC_URI[sha256sum] = "02211c3447c4daa55919c5c0f43a82a6fbb51740d57fc3af0639d46f1cf4377d"
> @@ -39,6 +40,7 @@ PACKAGECONFIG[unwind] = "-Dlibunwind=enabled,-Dlibunwind=disabled,libunwind"
> PACKAGECONFIG[dw] = "-Dlibdw=enabled,-Dlibdw=disabled,elfutils"
> PACKAGECONFIG[bash-completion] = "-Dbash-completion=enabled,-Dbash-completion=disabled,bash-completion"
> PACKAGECONFIG[tools] = "-Dtools=enabled,-Dtools=disabled"
> +PACKAGECONFIG[setcap] = "-Dsetcap=enabled,-Dsetcap=disabled,libcap"
>
> # TODO: put this in a gettext.bbclass patch
> def gettext_oemeson(d):
>
^ permalink raw reply
* Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd
From: Martin Jansa @ 2020-02-20 11:55 UTC (permalink / raw)
To: Mikko.Rapeli; +Cc: j.armandohernandez.j, yocto
In-Reply-To: <20200220081404.GF104502@korppu>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
On Thu, Feb 20, 2020 at 08:14:04AM +0000, Mikko.Rapeli@bmw.de wrote:
> On Wed, Feb 19, 2020 at 10:57:41PM +0100, Martin Jansa wrote:
> > > DEPENDS_class-target += "systemd"
> >
> > You surely meant
> > DEPENDS_append_class-target = " systemd"
> > here
>
> Yes, quite likely. Tough reason why += doesn't work is a mystery to me :)
>
> I hack things until "bitbake -e" shows the right things for the recipes.
I agree it's a bit confusing at first (I was doing the same long time
ago, before bitbake -e was even showing the history of evaluation), but
everybody who uses bitbake often should learn this simple difference:
FOO_append_override = " bar"
is "conditional" append, so it will append "bar" only when "override" is
being used
FOO_override += "bar"
always appends to "FOO_override" and then it overrides whole "FOO" variable
There are other more subtle differences like "+=" adds leading space,
_append doesn't and _append is processed later (which is important when
appending to variable set with ?=), but the above difference is a must
to know.
Also
FOO_append += "bar"
is just silly way how to add leading space to the value, one should
always use
FOO_append = " bar"
when appending to space separated list (like DEPENDS).
Cheers,
> -Mikko
>
> > On Wed, Feb 19, 2020 at 10:48 PM Mikko Rapeli <mikko.rapeli@bmw.de> wrote:
> >
> > > Hi,
> > >
> > > On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > > > Hello,
> > > >
> > > > I have a recipe that builds a library. The recipe specifies an
> > > additional package "${PN}-systemd" along with other systemd related
> > > variables and finally it instructs that the package should be built with
> > > "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> > > this recipe to nativesdk because I need this library on it. When trying to
> > > build the corresponding nativesdk package, the build fails at the
> > > configuration step (i.e. "do_configure") claiming it cannot find the
> > > package systemd.
> > > >
> > > > Is there a way I can install the -already-generated libraries into my
> > > SDK (potentially via the corresponding nativesdk recipe) without having to
> > > rebuild the package? Or do I need to somehow include such systemd package
> > > in my sdk (which I don't think I need at all)?
> > > >
> > > > Any hints and pointers as to were to look at are very well appreciated.
> > > > Thanks.
> > >
> > > Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> > > "systemd"
> > > etc.
> > >
> > > There may be relevant use cases to build some of systemd components or
> > > tools
> > > to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> > > "nativesdk" etc
> > > in a bbappend to systemd.
> > >
> > > Hope this helps,
> > >
> > > -Mikko
> > >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* Re: Questions about logic_pio
From: Jiaxun Yang @ 2020-02-20 11:55 UTC (permalink / raw)
To: John Garry
Cc: Wei Xu, bhelgaas, andyshevchenko, Arnd Bergmann, linux-kernel,
Linux Mips
In-Reply-To: <e3ddd7de-54b2-bdba-2233-6ace40072430@huawei.com>
---- 在 星期四, 2020-02-20 18:52:38 John Garry <john.garry@huawei.com> 撰写 ----
Also Cc MIPS list to check other's opinions.
Hi John.
Thanks for your kind explanation, however, I think this way is
violating how I/O ports supposed to work, at least in MIPS world.
> >>
> >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
> >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
> >> cpu_address. In my opinion, for direct MMIO access, logic_pio address should always
> >> equal to hw address,
>
> I'm not sure what you mean by simply the hw address.
>
I meant hw_start should always equal to io_start.
MIPS have their own wrapped inl/outl functions, doing the samething with
PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.
Originally, the I/O ports layout seems like this:
00000020-00000021 : pic1
00000060-0000006f : i8042
00000070-00000077 : rtc0
000000a0-000000a1 : pic2
00000170-00000177 : pata_atiixp
000001f0-000001f7 : pata_atiixp
00000376-00000376 : pata_atiixp
000003f6-000003f6 : pata_atiixp
00000800-000008ff : acpi
00001000-00001008 : piix4_smbus
00004000-0003ffff : pci io space
00004000-00004fff : PCI Bus 0000:01
00004000-000040ff : 0000:01:05.0
00005000-00005fff : PCI Bus 0000:03
00005000-0000501f : 0000:03:00.0
But with PCI_IOBASE defined, I got this:
host bridge /bus@10000000/pci@10000000 ranges:
MEM 0x0040000000..0x007fffffff -> 0x0040000000
IO 0x0000004000..0x0000007fff -> 0x0000004000
resource collision: [io 0x0000-0x3fff] conflicts with pic1 [io 0x0020-0x0021]
Because io_start was allocated to 0x0 by Logic PIO.
There are a lot of devices that have fixed ioports thanks to x86's legacy.
For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
and they can't be managed by logic pio subsystem.
Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
started from 0x4000 in bus side, but then, Logic PIO remapped to PCI_IOBASE + 0x0.
The real address should be PCI_IOBASE + 0x4000,
hardware never got correctly informed about that. And there is still no way to
transform to correct address as it's inside the MMIO_LIMIT.
So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
rather than just check the range provided doesn't overlap each other or exceed
the MMIO_LIMIT.
Thanks.
--
Jiaxun Yang
^ permalink raw reply
* [PATCH v3 1/5] powerpc: Rename current_stack_pointer() to current_stack_frame()
From: Michael Ellerman @ 2020-02-20 11:51 UTC (permalink / raw)
To: linuxppc-dev
current_stack_pointer(), which was called __get_SP(), used to just
return the value in r1.
But that caused problems in some cases, so it was turned into a
function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
function not a define").
Because it's a function in a separate compilation unit to all its
callers, it has the effect of causing a stack frame to be created, and
then returns the address of that frame. This is good in some cases
like those described in the above commit, but in other cases it's
overkill, we just need to know what stack page we're on.
On some other arches current_stack_pointer is just a register global
giving the stack pointer, and we'd like to do that too. So rename our
current_stack_pointer() to current_stack_frame() to make that
possible.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/perf_event.h | 2 +-
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/kernel/irq.c | 4 ++--
arch/powerpc/kernel/misc.S | 4 ++--
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/stacktrace.c | 6 +++---
6 files changed, 10 insertions(+), 10 deletions(-)
v3: New.
diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
index 7426d7a90e1e..eed3954082fa 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -32,7 +32,7 @@
do { \
(regs)->result = 0; \
(regs)->nip = __ip; \
- (regs)->gpr[1] = current_stack_pointer(); \
+ (regs)->gpr[1] = current_stack_frame(); \
asm volatile("mfmsr %0" : "=r" ((regs)->msr)); \
} while (0)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1aa46dff0957..1b1ffdba6097 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1448,7 +1448,7 @@ static inline void mtsrin(u32 val, u32 idx)
#define proc_trap() asm volatile("trap")
-extern unsigned long current_stack_pointer(void);
+extern unsigned long current_stack_frame(void);
extern unsigned long scom970_read(unsigned int address);
extern void scom970_write(unsigned int address, unsigned long value);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5c9b11878555..02118c18434d 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -602,7 +602,7 @@ static inline void check_stack_overflow(void)
#ifdef CONFIG_DEBUG_STACKOVERFLOW
long sp;
- sp = current_stack_pointer() & (THREAD_SIZE-1);
+ sp = current_stack_frame() & (THREAD_SIZE-1);
/* check for stack overflow: is there less than 2KB free? */
if (unlikely(sp < 2048)) {
@@ -647,7 +647,7 @@ void do_IRQ(struct pt_regs *regs)
void *cursp, *irqsp, *sirqsp;
/* Switch to the irq stack to handle this */
- cursp = (void *)(current_stack_pointer() & ~(THREAD_SIZE - 1));
+ cursp = (void *)(current_stack_frame() & ~(THREAD_SIZE - 1));
irqsp = hardirq_ctx[raw_smp_processor_id()];
sirqsp = softirq_ctx[raw_smp_processor_id()];
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 974f65f79a8e..65f9f731c229 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -110,7 +110,7 @@ _GLOBAL(longjmp)
li r3, 1
blr
-_GLOBAL(current_stack_pointer)
+_GLOBAL(current_stack_frame)
PPC_LL r3,0(r1)
blr
-EXPORT_SYMBOL(current_stack_pointer)
+EXPORT_SYMBOL(current_stack_frame)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e730b8e522b0..110db94cdf3c 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2051,7 +2051,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
sp = (unsigned long) stack;
if (sp == 0) {
if (tsk == current)
- sp = current_stack_pointer();
+ sp = current_stack_frame();
else
sp = tsk->thread.ksp;
}
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index e2a46cfed5fd..c477b8585a29 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -57,7 +57,7 @@ void save_stack_trace(struct stack_trace *trace)
{
unsigned long sp;
- sp = current_stack_pointer();
+ sp = current_stack_frame();
save_context_stack(trace, sp, current, 1);
}
@@ -71,7 +71,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
return;
if (tsk == current)
- sp = current_stack_pointer();
+ sp = current_stack_frame();
else
sp = tsk->thread.ksp;
@@ -131,7 +131,7 @@ static int __save_stack_trace_tsk_reliable(struct task_struct *tsk,
}
if (tsk == current)
- sp = current_stack_pointer();
+ sp = current_stack_frame();
else
sp = tsk->thread.ksp;
--
2.21.1
^ permalink raw reply related
* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
To: Michael Kao
Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm, linux-kernel,
Eduardo Valentin, Rob Herring, linux-mediatek, hsinyi,
Matthias Brugger, Zhang Rui, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>
On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>> 1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>> status = "disabled";
>>> };
>>>
>>> + thermal: thermal@1100b000 {
>>> + #thermal-sensor-cells = <1>;
>>> + compatible = "mediatek,mt8183-thermal";
>>> + reg = <0 0x1100b000 0 0x1000>;
>>> + interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
>
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.
Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
To: Michael Kao
Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm, linux-kernel,
Eduardo Valentin, Rob Herring, linux-mediatek, hsinyi,
Matthias Brugger, Zhang Rui, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>
On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>> 1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>> status = "disabled";
>>> };
>>>
>>> + thermal: thermal@1100b000 {
>>> + #thermal-sensor-cells = <1>;
>>> + compatible = "mediatek,mt8183-thermal";
>>> + reg = <0 0x1100b000 0 0x1000>;
>>> + interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
>
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.
Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
To: Michael Kao
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Matthias Brugger, hsinyi, linux-pm, srv_heupstream, devicetree,
linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>
On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>> 1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>> status = "disabled";
>>> };
>>>
>>> + thermal: thermal@1100b000 {
>>> + #thermal-sensor-cells = <1>;
>>> + compatible = "mediatek,mt8183-thermal";
>>> + reg = <0 0x1100b000 0 0x1000>;
>>> + interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
>
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.
Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Thomas Monjalon @ 2020-02-20 11:51 UTC (permalink / raw)
To: Nagadheeraj Rottela, Akhil Goyal; +Cc: dev, jsrikanth@marvell.com
In-Reply-To: <VE1PR04MB66394AC008E0F17DB28A8FB1E6130@VE1PR04MB6639.eurprd04.prod.outlook.com>
20/02/2020 12:07, Akhil Goyal:
> >
> > Address the defects reported by coverity: Unintended sign extension
> > and Out-of-bounds access.
> >
> > Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
> >
> > Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
> > Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
> >
> > Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
> > ---
> Thomas,
>
> Can you take this directly on master.
No sorry, I can't because there is no review and test.
And I think we should not have general patches for Coverity defects.
Instead we must do one patch per issue. Here two:
- sign of constants
- out-of-bound access
In each patch, we must have a description of the consequence of the issue.
Thanks
^ permalink raw reply
* [PATCH V2] arm64: dts: ipq6018: Add a few device nodes
From: Sivaprakash Murugesan @ 2020-02-20 11:50 UTC (permalink / raw)
To: agross, bjorn.andersson, robh+dt, mark.rutland, linux-arm-msm,
devicetree, linux-kernel
Cc: sivaprak
add i2c, spi, crypto, rng, watchdog, peripheral nodes, also add
support for wcss Q6 remoteproc driver and enable hw mutex, smem,
mailbox, smp2p and rpmsg drivers
Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
---
[V2] * Addressed review comments from Stephen
This patch depends on Sricharan's ipq6018 dts patch
https://patchwork.kernel.org/patch/11340681/
arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts | 34 ++++
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 226 +++++++++++++++++++++++++++
2 files changed, 260 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
index 897b4b2..b31117a 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
+++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
@@ -28,3 +28,37 @@
pinctrl-names = "default";
status = "ok";
};
+
+&i2c_1 {
+ pinctrl-0 = <&i2c_1_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+};
+
+&spi_0 {
+ cs-select = <0>;
+ status = "ok";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ compatible = "n25q128a11";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&tlmm {
+ i2c_1_pins: i2c-1-pins {
+ pins = "gpio42", "gpio43";
+ function = "blsp2_i2c";
+ drive-strength = <8>;
+ };
+
+ spi_0_pins: spi-0-pins {
+ pins = "gpio38", "gpio39", "gpio40", "gpio41";
+ function = "blsp0_spi";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 0fb44e5..1aa8d85 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-ipq6018.h>
+#include <dt-bindings/reset/qcom,gcc-ipq6018.h>
/ {
#address-cells = <2>;
@@ -69,6 +70,18 @@
};
};
+ firmware {
+ scm {
+ compatible = "qcom,scm";
+ };
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
pmuv8: pmu {
compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) |
@@ -89,6 +102,22 @@
reg = <0x0 0x48500000 0x0 0x00200000>;
no-map;
};
+
+ smem_region: memory@4aa00000 {
+ reg = <0x0 0x4aa00000 0x0 0x00100000>;
+ no-map;
+ };
+
+ q6_region: memory@4ab00000 {
+ reg = <0x0 0x4ab00000 0x0 0x02800000>;
+ no-map;
+ };
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_region>;
+ hwlocks = <&tcsr_mutex 0>;
};
soc: soc {
@@ -98,6 +127,36 @@
dma-ranges;
compatible = "simple-bus";
+ prng: qrng@e1000 {
+ compatible = "qcom,prng-ee";
+ reg = <0xe3000 0x1000>;
+ clocks = <&gcc GCC_PRNG_AHB_CLK>;
+ clock-names = "core";
+ };
+
+ cryptobam: dma@704000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x00704000 0x20000>;
+ interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <1>;
+ qcom,controlled-remotely = <1>;
+ qcom,config-pipe-trust-reg = <0>;
+ };
+
+ crypto: crypto@73a000 {
+ compatible = "qcom,crypto-v5.1";
+ reg = <0x0073a000 0x6000>;
+ clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
+ <&gcc GCC_CRYPTO_AXI_CLK>,
+ <&gcc GCC_CRYPTO_CLK>;
+ clock-names = "iface", "bus", "core";
+ dmas = <&cryptobam 2>, <&cryptobam 3>;
+ dma-names = "rx", "tx";
+ };
+
tlmm: pinctrl@1000000 {
compatible = "qcom,ipq6018-pinctrl";
reg = <0x01000000 0x300000>;
@@ -125,6 +184,26 @@
#reset-cells = <1>;
};
+ tcsr_mutex_regs: syscon@1905000 {
+ compatible = "syscon";
+ reg = <0x01905000 0x8000>;
+ };
+
+ tcsr_q6: syscon@1945000 {
+ compatible = "syscon";
+ reg = <0x01945000 0xe000>;
+ };
+
+ blsp_dma: dma@7884000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x07884000 0x2b000>;
+ interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ };
+
blsp1_uart3: serial@78b1000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x078b1000 0x200>;
@@ -135,6 +214,66 @@
status = "disabled";
};
+ spi_0: spi@78b5000 {
+ compatible = "qcom,spi-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b5000 0x600>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <50000000>;
+ clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 12>, <&blsp_dma 13>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ spi_1: spi@78b6000 {
+ compatible = "qcom,spi-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b6000 0x600>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <50000000>;
+ clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 14>, <&blsp_dma 15>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ i2c_0: i2c@78b6000 {
+ compatible = "qcom,i2c-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b6000 0x600>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+ <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+ clock-names = "iface", "core";
+ clock-frequency = <400000>;
+ dmas = <&blsp_dma 15>, <&blsp_dma 14>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ i2c_1: i2c@78b7000 { /* BLSP1 QUP2 */
+ compatible = "qcom,i2c-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b7000 0x600>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+ <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+ clock-names = "iface", "core";
+ clock-frequency = <400000>;
+ dmas = <&blsp_dma 17>, <&blsp_dma 16>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
intc: interrupt-controller@b000000 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -146,6 +285,21 @@
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ watchdog@b017000 {
+ compatible = "qcom,kpss-wdt";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x0b017000 0x40>;
+ clocks = <&sleep_clk>;
+ timeout-sec = <10>;
+ };
+
+ apcs_glb: mailbox@b111000 {
+ compatible = "qcom,ipq8074-apcs-apps-global";
+ reg = <0x0b111000 0xc>;
+
+ #mbox-cells = <1>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
@@ -213,5 +367,77 @@
};
};
+ q6v5_wcss: remoteproc@cd00000 {
+ compatible = "qcom,ipq8074-wcss-pil";
+ reg = <0x0cd00000 0x4040>,
+ <0x004ab000 0x20>;
+ reg-names = "qdsp6",
+ "rmb";
+ interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
+ <&wcss_smp2p_in 0 0>,
+ <&wcss_smp2p_in 1 0>,
+ <&wcss_smp2p_in 2 0>,
+ <&wcss_smp2p_in 3 0>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ resets = <&gcc GCC_WCSSAON_RESET>,
+ <&gcc GCC_WCSS_BCR>,
+ <&gcc GCC_WCSS_Q6_BCR>;
+
+ reset-names = "wcss_aon_reset",
+ "wcss_reset",
+ "wcss_q6_reset";
+
+ clocks = <&gcc GCC_PRNG_AHB_CLK>;
+ clock-names = "prng";
+
+ qcom,halt-regs = <&tcsr_q6 0xa000 0xd000 0x0>;
+
+ qcom,smem-states = <&wcss_smp2p_out 0>,
+ <&wcss_smp2p_out 1>;
+ qcom,smem-state-names = "shutdown",
+ "stop";
+
+ memory-region = <&q6_region>;
+
+ glink-edge {
+ interrupts = <GIC_SPI 321 IRQ_TYPE_EDGE_RISING>;
+ qcom,remote-pid = <1>;
+ mboxes = <&apcs_glb 8>;
+
+ qrtr_requests {
+ qcom,glink-channels = "IPCRTR";
+ };
+ };
+ };
+
+ };
+
+ wcss: wcss-smp2p {
+ compatible = "qcom,smp2p";
+ qcom,smem = <435>, <428>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 322 IRQ_TYPE_EDGE_RISING>;
+
+ mboxes = <&apcs_glb 9>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <1>;
+
+ wcss_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ wcss_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
};
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.