* [PATCH v9 00/12] Support PPTT for ARM64
From: Catalin Marinas @ 2018-05-17 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511235807.30834-1-jeremy.linton@arm.com>
On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> Jeremy Linton (12):
> drivers: base: cacheinfo: move cache_setup_of_node()
> drivers: base: cacheinfo: setup DT cache properties early
> cacheinfo: rename of_node to fw_token
> arm64/acpi: Create arch specific cpu to acpi id helper
> ACPI/PPTT: Add Processor Properties Topology Table parsing
> ACPI: Enable PPTT support on ARM64
> drivers: base cacheinfo: Add support for ACPI based firmware tables
> arm64: Add support for ACPI based firmware tables
> arm64: topology: rename cluster_id
> arm64: topology: enable ACPI/PPTT based CPU topology
> ACPI: Add PPTT to injectable table list
> arm64: topology: divorce MC scheduling domain from core_siblings
Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
can add it separately).
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Eric Anholt @ 2018-05-17 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1805171233500.7984@macbook-air>
Vince Weaver <vincent.weaver@maine.edu> writes:
> On Thu, 17 May 2018, Stefan Wahren wrote:
>
>>
>> > Eric Anholt <eric@anholt.net> hat am 17. Mai 2018 um 15:17 geschrieben:
>> >
>> >
>> > The a53 and a7 counters seem to match up, so we advertise a7 so that
>> > arm32 can probe.
>
> so how closely did you look at the a53/a7 differences? I see some major
> differences, especially with the CPU_CYCLES event (0xff vs 0x11).
I'm a bit lost in the code, but it seemed like the 0xff was a
placeholder for a bit of special behavior, but that the cpu_cycles ->
ARMV7_PERFCTR_CLOCK_CYCLES mapping got you that same value in the end.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/24fefc2e/attachment-0001.sig>
^ permalink raw reply
* [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Srinivas Kandagatla @ 2018-05-17 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517065544.GO20254@sirena.org.uk>
Thanks for the review.
On 17/05/18 07:55, Mark Brown wrote:
> On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote:
>
>> +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token)
>> +{
>> + struct q6afe_port *p = NULL;
>> + struct q6afe_port *ret = NULL;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&afe->port_list_lock, flags);
>> + list_for_each_entry(p, &afe->port_list, node)
>> + if (p->token == token) {
>> + ret = p;
>> + break;
>> + }
>> +
>> + spin_unlock_irqrestore(&afe->port_list_lock, flags);
>> + return ret;
>
> This lock only protects the list, it does nothing to ensure that the
> port we look up is still valid by the time we return to the caller.
> That means we won't crash during list traversal but does nothing to
> ensure we won't crash immediately afterwards if the port is deallocated
> just after we look it up. What stops that happening?
Each port is allocated and de-allocated in dai probe and remove calls
respectively.
Lets say... So for this case to happen the dai has to be removed (unload
module) at the same time when the interrupt callback happens due to
delayed response from previous commands.
This case would be almost impossible because all the calls to afe
service are synchronous with timeouts, if any of the previous calls
times out the respective caller would get an error, this should prevent
him from unloading the module in the first place.
thanks,
srini
>
^ permalink raw reply
* Applied "soc: qcom: apr: fix invalid msg_type check" to the asoc tree
From: Mark Brown @ 2018-05-17 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517160353.27561-1-srinivas.kandagatla@linaro.org>
The patch
soc: qcom: apr: fix invalid msg_type check
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e744619d056e6ec5cd9db38e55511a22dc463f89 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date: Thu, 17 May 2018 17:03:53 +0100
Subject: [PATCH] soc: qcom: apr: fix invalid msg_type check
Removed invalid msg_type check.
This also fixes below static checker warning:
apr.c:95:35: warning: comparison is always true due to limited range of
data type [-Wtype-limits]
warn: always true condition '(msg_type != 69864) => (0-u16max != 69864)'
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/soc/qcom/apr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/apr.c b/drivers/soc/qcom/apr.c
index 97f3622da535..57af8a537332 100644
--- a/drivers/soc/qcom/apr.c
+++ b/drivers/soc/qcom/apr.c
@@ -92,7 +92,7 @@ static int apr_callback(struct rpmsg_device *rpdev, void *buf,
}
msg_type = APR_HDR_FIELD_MT(hdr->hdr_field);
- if (msg_type >= APR_MSG_TYPE_MAX && msg_type != APR_BASIC_RSP_RESULT) {
+ if (msg_type >= APR_MSG_TYPE_MAX) {
dev_err(apr->dev, "APR: Wrong message type: %d\n", msg_type);
return -EINVAL;
}
--
2.17.0
^ permalink raw reply related
* [PATCH] arm64/sve: Write ZCR_EL1 on context switch only if changed
From: Catalin Marinas @ 2018-05-17 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526320269-27088-1-git-send-email-Dave.Martin@arm.com>
On Mon, May 14, 2018 at 06:51:09PM +0100, Dave P Martin wrote:
> Writes to ZCR_EL1 are self-synchronising, and so may be expensive
> in typical implementations.
>
> This patch adopts the approach used for costly system register
> writes elsewhere in the kernel: the system register write is
> suppressed if it would not change the stored value.
>
> Since the common case will be that of switching between tasks that
> use the same vector length as one another, prediction hit rates on
> the conditional branch should be reasonably good, with lower
> expected amortised cost than the unconditional execution of a
> heavyweight self-synchronising instruction.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Mark Brown @ 2018-05-17 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507b8b76-0846-a492-73e6-782b9953bc36@linaro.org>
On Thu, May 17, 2018 at 06:10:49PM +0100, Srinivas Kandagatla wrote:
> On 17/05/18 07:55, Mark Brown wrote:
> > On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote:
> > This lock only protects the list, it does nothing to ensure that the
> > port we look up is still valid by the time we return to the caller.
> > That means we won't crash during list traversal but does nothing to
> > ensure we won't crash immediately afterwards if the port is deallocated
> > just after we look it up. What stops that happening?
> Each port is allocated and de-allocated in dai probe and remove calls
> respectively.
> Lets say... So for this case to happen the dai has to be removed (unload
> module) at the same time when the interrupt callback happens due to delayed
> response from previous commands.
> This case would be almost impossible because all the calls to afe service
> are synchronous with timeouts, if any of the previous calls times out the
> respective caller would get an error, this should prevent him from unloading
> the module in the first place.
The user can also trigger manual unbinds without unloading the module,
and to be honet the scenario where the DSP has stopped responding well
and is delaying responses sounds like exactly the sort of time when
users might try to reload the driver...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/98b47dad/attachment.sig>
^ permalink raw reply
* [PATCH RFC 3/6] hwmon: Add support for RPi voltage sensor
From: Eric Anholt @ 2018-05-17 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517164320.GA30364@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> On Wed, May 16, 2018 at 09:59:01PM +0200, Stefan Wahren wrote:
>> Hi Guenter,
>>
>> > Guenter Roeck <linux@roeck-us.net> hat am 16. Mai 2018 um 20:21 geschrieben:
>> >
>> >
>> > On Wed, May 16, 2018 at 03:37:04PM +0200, Stefan Wahren wrote:
>> > > Currently there is no easy way to detect under-voltage conditions on a remote
>> > > Raspberry Pi. This hwmon driver retrieves the state of the under-voltage sensor
>> > > via mailbox interface. The handling based on Noralf's modifications to the
>> > > downstream firmware driver. In case of an under-voltage condition only an entry
>> > > is written to the kernel log.
>> > >
>> >
>> > My major concern is how this is displayed with the 'sensors' command.
>> > Can you test and report ?
>>
>> I get the following output:
>> rpi_volt-isa-0000
>> Adapter: ISA adapter
>> in0: N/A
>>
> Ok, that works.
Thanks for the quick review on this, Guenter! This driver is going to
help save a lot of people debugging time on rpis in the upstream kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/f9ce6988/attachment.sig>
^ permalink raw reply
* [PATCH v3] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-17 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517162532.GE17671@n2100.armlinux.org.uk>
On Thu, May 17, 2018 at 05:25:32PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 17, 2018 at 04:45:41PM +0100, Dave Martin wrote:
> > Stateful CPU architecture extensions may require the signal frame
> > to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> > However, changing this #define is an ABI break.
> >
> > To allow userspace the option of determining the signal frame size
> > in a more forwards-compatible way, this patch adds a new auxv entry
> > tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> > size that the process can observe during its lifetime.
> >
> > If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> > assume that the MINSIGSTKSZ #define is sufficient. This allows for
> > a consistent interface with older kernels that do not provide
> > AT_MINSIGSTKSZ.
> >
> > The idea is that libc could expose this via sysconf() or some
> > similar mechanism.
> >
> > There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> > about userspace's own stack overheads and should not pretend to
> > know.
>
> I'm really not sure I follow your logic here.
>
> POSIX requirements are here:
>
> http://pubs.opengroup.org/onlinepubs/000095399/functions/sigaltstack.html
>
> and the requirement there is that the MINSIGSTKSZ constant is defined
> in signal.h to indicate to user programs the minimum signal stack size
> that the system requires.
At the birth of an arch, someone has to make a prescient guess about how
big the signal frame will ever grow, or risk ABI breaks or new
personalities that would require the userspace world to be rebuilt.
POSIX doesn't envisage that an arch's user register state can possibly
grow (or at least, not that much).
Unfortunately, predicting the future isn't that easy.
MINSIGSTKSZ has been wrong in the past, too.
arm64's linux MINSIGSTKSZ was 4K for quite a while even though the arm64
signal frame is always bigger than that. This bug was hidden by a
different definition (5K) in glibc that was subsequently backported
into the kernel headers. But userspace doesn't use that definition, so
this tells us little about how much would break out there if the
definition is changed.
IIUC, x86's MINSIGSTKSZ (2K) isn't big enough for AVX-512 (possibly not
big enough even without AVX-512, though I haven't figured it out).
According to Michael Ellerman, powerpc may have a similar issue at some
point.
> I don't see how passing the minimum signal stack size via AT_MINSIGSTKSZ
> helps in any way, since you propose to make programs use a sysconf()
> call to get that, and that is not covered by POSIX. So you're asking
> programs to do something special for ARM64.
My idea is indeed to recommend that this gets hidden behind sysconf(),
so that programs can get a sensible value from there without needing to
know which architecture they are running on. I have a glibc patch that
I intend to post for discussion soon.
This would mean something like
#include <signal.h>
#include <unistd.h>
long size;
#ifdef _SC_MINSIGSTKSZ
size = sysconf(_SC_MINSIGSTKSZ);
#else
size = MINSIGSTKSZ;
#endif
Programs would of course have to migrate to this over time. I'm not
saying it's a magic bullet.
> Simply increasing MINSIGSTKSZ doesn't cause an ABI break - new programs
> built against an increased MINSIGSTKSZ results in more stack being
> allocated, which doesn't break the ABI in any way. The problem comes
Maybe not per se, but if userspace exchanges pointers to stacks across
object boundaries and assumes that they are MINSIGSTKSZ in size (say),
then a prorgam may disagree with a library about what this size is.
And it's hard to guarantee that there is no software abusing MINSIGSTKSZ
or using it for dubious purposes such as sizing objects that are not
bare stacks.
Consider:
struct thread {
/* ... */
char stack[MINSIGSTKSZ];
/* ... */
};
/* lib.so */
void dup_thread(struct thread *dest, struct thread const *src)
{
*dest = *src;
}
/* application */
/* ... */
struct thread t1, t2;
dup_thread(&t1, &t2);
I don't say whether this kind of thing is a good idea, but POSIX does
nothing to forbid it. If lib.so was built more recently and uses the
new, larger MINSIGSTKSZ, while the application uses the old, smaller
value then the call to dup_thread will trigger a buffer overflow.
Changing MINSIGSTKSZ also papers over the problem of ucontext_t
perhaps not covering the whole signal frame. If ucontexts ar
exchanged across object boundaries that use different definitions
of the type, then buffer overruns could easily happen. If ucontext_t is
not redefined, part of the context will fall outside it.
I plan to propose some ucontext API extensions for glibc to help
mitigate this, but again, software would need to be ported to use
them.
> when old programs built with the old MINSIGSTKSZ are run against a
> kernel requiring a larger MINSIGSTKSZ. It's almost the reverse problem
> - the kernel needs to know the MINSIGSTKSZ value that the problem was
> built with, but we don't have that facility either.
>
> > For arm64:
> >
> > The primary motivation for this interface is the Scalable Vector
> > Extension, which can require at least 4KB or so of extra space
> > in the signal frame for the largest hardware implementations.
>
> Presumably you only include the SVE state if the application makes use
> of SVE? Otherwise, you'd be saving and restoring a lot of state for
> features that are not being used.
Yes. A program has to actually execute an SVE instruction in order
for the full SVE register values to be context switched or included
in the signal frame.
> I suppose part of the issue is that SVE is supported but MINSIGSTKSZ
> is incorrect if this state has to be saved and restored, so there's
> apps out there using SVE with the too-small MINSIGSTKSZ value?
There's no hardware yet, so there should be no programs in the wild.
If we could simply change MINSIGSTKSZ, that would be great. But
redefining ucontext_t is more of a problem, and the two are rather
interrelated.
My current approach is to hide this from software by default, by
limiting the SVE vector length to a value small enough that the SVE
state fits in the original (5K-ish) arm64 signal frame. Only if the
distro/admin decides that it is safe to bump up this default, or
if an application explicitly asks for a larger size via a prctl()
is this limit increased.
This is not ideal, but there didn't seem to be any ideal solution.
In practice, MINSIGSTKSZ is hard to use correctly, and most programs
use SIGSTKSZ instead. As luck would have it, arm64's SIGSTKSZ is big
enough to cover the largest possible SVE signal frame.
The first round of SVE implementations are unlikely to exceed a
vector size of 512 bits, which again hides the problem.
All this buys some time for arm64 at least. This patch is more about
trying to find a better approach for the future.
If there's a better option available, I'd love to hear about it!
Cheers
---Dave
^ permalink raw reply
* [PATCH] mm/dmapool: localize page allocations
From: Sinan Kaya @ 2018-05-17 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Try to keep the pool closer to the device's NUMA node by changing kmalloc()
to kmalloc_node() and devres_alloc() to devres_alloc_node().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
mm/dmapool.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index 4d90a64..023f3d9 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -223,7 +223,7 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
{
struct dma_page *page;
- page = kmalloc(sizeof(*page), mem_flags);
+ page = kmalloc_node(sizeof(*page), mem_flags, dev_to_node(pool->dev));
if (!page)
return NULL;
page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation,
@@ -504,7 +504,8 @@ struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
{
struct dma_pool **ptr, *pool;
- ptr = devres_alloc(dmam_pool_release, sizeof(*ptr), GFP_KERNEL);
+ ptr = devres_alloc_node(dmam_pool_release, sizeof(*ptr), GFP_KERNEL,
+ dev_to_node(dev));
if (!ptr)
return NULL;
--
2.7.4
^ permalink raw reply related
* [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Srinivas Kandagatla @ 2018-05-17 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517172308.GX20254@sirena.org.uk>
On 17/05/18 18:23, Mark Brown wrote:
> On Thu, May 17, 2018 at 06:10:49PM +0100, Srinivas Kandagatla wrote:
>> On 17/05/18 07:55, Mark Brown wrote:
>>> On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote:
>
>>> This lock only protects the list, it does nothing to ensure that the
>>> port we look up is still valid by the time we return to the caller.
>>> That means we won't crash during list traversal but does nothing to
>>> ensure we won't crash immediately afterwards if the port is deallocated
>>> just after we look it up. What stops that happening?
>
>> Each port is allocated and de-allocated in dai probe and remove calls
>> respectively.
>
>> Lets say... So for this case to happen the dai has to be removed (unload
>> module) at the same time when the interrupt callback happens due to delayed
>> response from previous commands.
>
>> This case would be almost impossible because all the calls to afe service
>> are synchronous with timeouts, if any of the previous calls times out the
>> respective caller would get an error, this should prevent him from unloading
>> the module in the first place.
>
> The user can also trigger manual unbinds without unloading the module,
> and to be honet the scenario where the DSP has stopped responding well
> and is delaying responses sounds like exactly the sort of time when
> users might try to reload the driver...Yes, that is one possible usecase!
ref-counting port should stop that from happening.
I will add this in next spin!
thanks,
srini
^ permalink raw reply
* [PATCH] ghes_edac: enable HIP08 platform edac driver
From: James Morse @ 2018-05-17 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516182958.GB17092@pd.tnic>
Hi guys,
Tyler, Zhengqiang, I assume all your shipped platforms with HEST->GHES entries
also have DMI tables.
On 16/05/18 19:29, Borislav Petkov wrote:
> On Wed, May 16, 2018 at 02:38:38PM +0100, James Morse wrote:
>> XGene has its own edac driver, but it doesn't probe when booted via ACPI so
>> won't conflict with ghes_edac.
>
> Actually it will. EDAC core can have only one EDAC driver loaded. Don't
> ask me why - it has been that way since forever.
By won't probe I mean it only works on DT systems:
| static const struct of_device_id xgene_edac_of_match[] = {
| { .compatible = "apm,xgene-edac" },
| {},
| };
| .driver = {
| .name = "xgene-edac",
| .of_match_table = xgene_edac_of_match,
| },
To work on a system with GHES it would need an 'struct acpi_device_id' to
describe the HID (?) and populate driver's acpi_match_table.
> We can change it some
> day but frankly, I don't see reasoning for it. One driver can easily
> manage *all* error sources on a system, I'd say.
I agree, there is no reason to support two at the same time, if this happens
then there is probably something wrong with the platform (e.g. races with
firmware reading the same hardware registers), so we should make some noise.
Xgene's edac driver would be a good example of this, it looks like it reads data
from some mmio region, if something else is doing the same we're going to make a
mess.
>> So I think we're good to make the whitelist x86 only.
>> Your diff-hunk makes 'idx=-1', so we always get the 'Unfortunately' warning. I'd
>> like to suppress this unless force_load has been used.
>
> Yeah, we should handle that differently for ARM. Toshi added the idx
> thing in
>
> 5deed6b6a479 ("EDAC, ghes: Add platform check")
>
> to dump this when the platform is not whitelisted. So let's do that:
>
> ---
> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> index 863fbf3db29f..473aeec4b1da 100644
> --- a/drivers/edac/ghes_edac.c
> +++ b/drivers/edac/ghes_edac.c
> @@ -440,12 +440,16 @@ int ghes_edac_register(struct ghes *ghes, struct device *dev)
> struct mem_ctl_info *mci;
> struct edac_mc_layer layers[1];
> struct ghes_edac_dimm_fill dimm_fill;
> - int idx;
> + int idx = -1;
>
> - /* Check if safe to enable on this system */
> - idx = acpi_match_platform_list(plat_list);
> - if (!force_load && idx < 0)
> - return -ENODEV;
v4.17-rc5 has 'return 0' here. Wouldn't this change means no ghes can be
registered unless ghes_edac is also supported by the platform?
Shouldn't this be '0' for a silent failure?
> + if (IS_ENABLED(CONFIG_X86)) {
> + /* Check if safe to enable on this system */
> + idx = acpi_match_platform_list(plat_list);
> + if (!force_load && idx < 0)
> + return -ENODEV;
> + } else {
> + idx = 0;
> + }
>
> /*
> * We have only one logical memory controller to which all DIMMs belong.
Tested on Seattle and some cranky homebrew-no-DMI firmware:
Tested-by: James Morse <james.morse@arm.com>
With the ENODEV/0 thing above:
Reviewed-by: James Morse <james.morse@arm.com>
>> It looks like even the oldest Arm64 ACPI systems have dmi tables, so we can
>> probably require DMI or the 'force' flag.
>
> Well, with the hunk above it would still do ghes_edac_count_dimms() on
> ARM and if it fails to find something, it will set fake, which is a good
> sanity-check as it screams loudly. :)
Thanks,
James
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: James Morse @ 2018-05-17 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517021547.GJ24627@MiWiFi-R3L-srv>
Hi Baoquan,
On 17/05/18 03:15, Baoquan He wrote:
> On 05/17/18 at 10:10am, Baoquan He wrote:
>> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>>> We need to prevent firmware-reserved memory regions, particularly EFI
>>>>> memory map as well as ACPI tables, from being corrupted by loading
>>>>> kernel/initrd (or other kexec buffers). We also want to support memory
>>>>> allocation in top-down manner in addition to default bottom-up.
>>>>> So let's have arm64 specific arch_kexec_walk_mem() which will search
>>>>> for available memory ranges in usable memblock list,
>>>>> i.e. !NOMAP & !reserved,
>>>>
>>>>> instead of system resource tree.
>>>>
>>>> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
>>>> be safe in the EFI-memory-map/ACPI-tables case?
>>>>
>>>> It would be good to avoid having two ways of doing this, and I would like to
>>>> avoid having extra arch code...
>>>
>>> I know what you mean.
>>> /proc/iomem or system resource is, in my opinion, not the best place to
>>> describe memory usage of kernel but rather to describe *physical* hardware
>>> layout. As we are still discussing about "reserved" memory, I don't want
>>> to depend on it.
>>> Along with memblock list, we will have more accurate control over memory
>>> usage.
>>
>> In kexec-tools, we see any usable memory as candidate which can be used
>
> Here I said 'any', it's not accurate. Those memory which need be passed
> to 2nd kernel for use need be excluded, just as we have done in
> kexec-tools.
>
>> to load kexec kernel image/initrd etc. However kexec loading is a
>> preparation work, it just books those position for later kexec kernel
>> jumping after "kexec -e", that is why we need kexec_buf to remember
>> them and do the real content copy of kernel/initrd.
The problem we have on arm64 is /proc/iomem is being used for two things.
1) Kexec's this is memory I can book for the new kernel.
2) Kdump's this is memory I must describe for vmcore.
We get the memory map from UEFI via the EFI stub, and leave it in
memblock_reserved() memory. A new kexec kernel needs this to boot: it mustn't
overwrite it. The same goes for the ACPI tables, they could be reclaimed and
used as memory, but the new kexec kernel needs them to boot, they are
memblock_reserved() too.
If we knock all memblock_reserved() regions out of /proc/iomem then kdump
doesn't work, because /proc/iomem is only generated once. Its a snapshot. The
initcode/data is an example of memory we release from memblock_reserve() after
this, then gets used for data we need in the vmcore.
Ideally we would describe all this in /proc/iomem with:
| 8001e80000-83ff186fff : System RAM
| 8002080000-8002feffff : [Data you really need to boot]
kexec-tools should not overwrite 'data you really need to boot' unless it knows
what it is, and that the system will never need it again. (examples: overwrite
the ACPI tables when booting a non-acpi kernel, overwrite the UEFI memory map if
the DT has been regenerated for a non-uefi kernel)
But, kexec-tools doesn't parse those second level entries properly. We have a
bug in user-space, and a bug in the kernel.
Because /proc/iomem is being used for two things, and kexec-tools only parses
one level, I don't think we can fix this in the kernel without breaking one of
the use-cases. I think Akashi's fix user-space too approach is the most
pragmatic approach.
>> Here you use
>> memblock to search available memory, isn't it deviating too far away
>> from the original design in kexec-tools. Assume kexec loading and
>> kexec_file loading should be consistent on loading even though they are
>> done in different space, kernel space and user space.
Its much easier for us to parse memblock in the kernel as the helpers step over
the regions we know we don't want. For the resource list we would need to
strcmp(), and a bunch of handling for the second level entries.
Thanks,
James
^ permalink raw reply
* [PATCH v6 6/9] dt-bindings: counter: Document stm32 quadrature encoder
From: William Breathitt Gray @ 2018-05-17 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+a4s=5N6wUWifoHWQoornbDBY-UY2xrwj1kggNH4Q5pQ@mail.gmail.com>
On Thu, May 17, 2018 at 11:23:22AM -0500, Rob Herring wrote:
>On Wed, May 16, 2018 at 12:51 PM, William Breathitt Gray
><vilhelm.gray@gmail.com> wrote:
>> From: Benjamin Gaignard <benjamin.gaignard@st.com>
>
>v6? Where's v1-v5?
Hi Rob,
I apologize, I should have CC you on the rest of the patchset to give
you a better idea of the context of this particular patch. Benjamin
Gaignard authored this particular patch, so I'll leave it up to him to
respond to your inline comments, but I can at least provide a brief
history of the revisions of this patchset as a whole.
This patchset introduces a "Generic Counter" interface for drivers to
support various counter devices (tally counters, rotary encoders, etc.).
The v1 revision was submitted on 31 July 2017
(https://lkml.org/lkml/2017/7/31/514) as a wrapper over existing
IIO functionality. This implementation design was unsuitable for the
needs of Generic Counter API, so the v4 revision submitted on 14
December 2017 reimplemented the Generic Counter API as its own Counter
subsystem (https://lkml.org/lkml/2017/12/14/778).
The v5 revision was submitted on 9 March 2018
(https://lkml.org/lkml/2018/3/9/728) and introduced the STM32 Timer
quadrature encoder driver with Generic Counter interface support. I
should have CC you in that revision to comment on the dt-bindings patch,
but I overlooked it, so I made sure to CC you on this v6 revision.
William Breathitt Gray
>
>> Add bindings for STM32 Timer quadrature encoder.
>> It is a sub-node of STM32 Timer which implement the
>> counter part of the hardware.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>> ---
>> .../bindings/counter/stm32-timer-cnt.txt | 26 +++++++++++++++++++
>> .../devicetree/bindings/mfd/stm32-timers.txt | 7 +++++
>> 2 files changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>>
>> diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> new file mode 100644
>> index 000000000000..377728128bef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> @@ -0,0 +1,26 @@
>> +STMicroelectronics STM32 Timer quadrature encoder
>> +
>> +STM32 Timer provides quadrature encoder counter mode to detect
>
>'mode' does not sound like a sub-block of the timers block.
>
>> +angular position and direction of rotary elements,
>> +from IN1 and IN2 input signals.
>> +
>> +Must be a sub-node of an STM32 Timer device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required properties:
>> +- compatible: Must be "st,stm32-timer-counter".
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes,
>> + to set IN1/IN2 pins in mode of operation for Low-Power
>> + Timer input on external pin.
>> +
>> +Example:
>> + timers at 40010000 {
>> + compatible = "st,stm32-timers";
>> + ...
>> + counter {
>> + compatible = "st,stm32-timer-counter";
>
>Is there only 1? How is the counter addressed?
>
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&tim1_in_pins>;
>> + };
>> + };
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Peter Zijlstra @ 2018-05-17 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <307323036.63872.1526576126537@email.1und1.de>
On Thu, May 17, 2018 at 06:55:26PM +0200, Stefan Wahren wrote:
> > Vince Weaver <vincent.weaver@maine.edu> hat am 17. Mai 2018 um 18:34 geschrieben:
> > On Thu, 17 May 2018, Stefan Wahren wrote:
> > > > Eric Anholt <eric@anholt.net> hat am 17. Mai 2018 um 15:17 geschrieben:
> > > > The a53 and a7 counters seem to match up, so we advertise a7 so that
> > > > arm32 can probe.
> >
> > so how closely did you look at the a53/a7 differences? I see some major
> > differences, especially with the CPU_CYCLES event (0xff vs 0x11).
> >
> > The proper fix here might be to add a cortex-a53 PMU entry to the armv7
> > code rather than trying to treat it as a cortex-a7.
>
> we like to use the PMU of BCM2837 SoC (4x A53 cores) under arm32 and arm64.
>
> What is the right way (tm) to the define the DT compatibles?
> Does the arm32 PMU driver need patching for proper A53 support?
I'm completely clueless on all of this; Mark might have ideas.
^ permalink raw reply
* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: James Morse @ 2018-05-17 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517133653.GA27738@pd.tnic>
Hi Borislav,
On 17/05/18 14:36, Borislav Petkov wrote:
> On Wed, May 16, 2018 at 03:51:14PM +0100, James Morse wrote:
>> I thought this was safe because its just ghes_copy_tofrom_phys()s access to the
>> fixmap slots that needs mutual exclusion.
and here is where I was wrong: I was only looking at reading the data, we then
dump it in struct ghes assuming it can only be notified on once CPU at a time. Oops.
> For example:
> ghes->estatus from above, before the NMI fired, has gotten some nice
> scribbling over. AFAICT.
Yup, thanks for the example!
> Now, I don't know whether this can happen with the ARM facilities but if
> they're NMI-like, I don't see why not.
NOTIFY_SEA is synchronous so the error has to be something to do with the
instruction that was interrupted. In your example this would mean the APEI
code/data was corrupted, which there is little point trying to handle.
NOTIFY_{SEI, SDEI} on the other hand are asynchronous, so this could happen.
> Which means, that this code is not really reentrant and if should be
> fixed to be callable from different contexts, then it should use private
> buffers and be careful about locking.
... I need to go through this thing again to work out how the firmware-buffers
map on to estatus=>ghes ...
> Oh, and that
>
> if (in_nmi)
> lock()
> else
> lock_irqsave()
>
> pattern is really yucky. And it is an explosion waiting to happen.
The whole in_nmi()=>other-lock think looks like a hack to make a warning go
away. We could get the notification to take whatever lock is appropriate further
out, but it may mean some code duplication. (I'll put it on my list...)
Thanks,
James
^ permalink raw reply
* [PATCH] mm/dmapool: localize page allocations
From: Matthew Wilcox @ 2018-05-17 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526578581-7658-1-git-send-email-okaya@codeaurora.org>
On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote:
> Try to keep the pool closer to the device's NUMA node by changing kmalloc()
> to kmalloc_node() and devres_alloc() to devres_alloc_node().
Have you measured any performance gains by doing this? The thing is that
these allocations are for the metadata about the page, and the page is
going to be used by CPUs in every node. So it's not clear to me that
allocating it on the node nearest to the device is going to be any sort
of a win.
> @@ -504,7 +504,8 @@ struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
> {
> struct dma_pool **ptr, *pool;
>
> - ptr = devres_alloc(dmam_pool_release, sizeof(*ptr), GFP_KERNEL);
> + ptr = devres_alloc_node(dmam_pool_release, sizeof(*ptr), GFP_KERNEL,
> + dev_to_node(dev));
> if (!ptr)
> return NULL;
... are we really calling devres_alloc() for sizeof(void *)? That's sad.
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Dave Martin @ 2018-05-17 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517124006.ohygrrpg7z2moqqt@linutronix.de>
On Thu, May 17, 2018 at 02:40:06PM +0200, Sebastian Andrzej Siewior wrote:
> In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> code disables BH and expects that it is not preemptible. On -RT the
> task remains preemptible but remains the same CPU. This may corrupt the
Also, watch out for [1] which adds more of this stuff for KVM. This
not merged yet, but likely to land in v4.18.
> content of the SIMD registers if the task is preempted during
> saving/restoring those registers.
> Add a locallock around next to the local_bh_disable(). This fulfill the
> requirement that the code is not invoked again in different context on
> the same CPU while it remains preemptible.
Thanks for this.
*WARNING*: My RT-fu is weak to nonexistent, so don't assume that
anything I suggest below is correct without thinking carefully about
it :)
Anyway:
What we're really trying to achieve with the local_bh_disable/enable
stuff is exclusive access to the CPU FPSIMD registers and associated
metadata that tracks who they belong to.
> The preempt_disable() + local_bh_enable() combo in kernel_neon_begin()
> is not working on -RT. We don't use NEON in kernel mode on RT right now
> but this still should be addressed.
I think we effectively have two levels of locking here.
At the outer level, we want exclusive access to the FPSIMD registers.
This is what is needed between kernel_neon_begin() and
kernel_neon_end(), and maps onto the preempt_disable()/_enable() done
by these functions.
In context switch critical code, that's insufficient, and we also
need exclusive access to the metadata that tracks which task or context
owns the FPSIMD registers. This is what the local_bh_disable()/
_enable() achieves.
So does it make sense to have two locks (I'm assuming local locks are
implicitly percpu ?)
static inline void local_fpsimd_context_lock(void)
{
local_bh_disable();
local_lock(fpsimd_lock);
local_lock(fpsimd_context_lock);
}
static inline void local_fpsimd_context_unlock(void)
{
local_unlock(fpsimd_context_lock);
local_unlock(fpsimd_lock);
local_bh_enable();
}
kernel_neon_begin() could then do
local_fpsimd_context_lock();
/* ... */
preempt_disable();
local_unlock(fpsimd_context_lock);
... with the following in kernel_neon_end():
local_unlock(fpsimd_lock);
preempt_enable();
If kernel-mode NEON was considered harmful to RT due to the context
switch overheads, then the above might be overkill. SVE will be worse
in that regard, and also needs thinking about at some point -- I've not
looked at if from the RT angle at all.
In either case, I think abstracting the lock/unlock sequences out to
make the purpose clearer may be a good idea, even if we just have a
single local lock to manage.
There is one place where I mess with the FPSIMD context no lock held
because of a need to copy_from_user() straight into the context backing
store (we can't copy_from_user() with preemption disabled...)
I'm not sure whether RT will have any impact on this, but it probably
needs thinking about.
One more comment below...
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> arch/arm64/kernel/fpsimd.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index e7226c4c7493..3a5cd1908874 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -38,6 +38,7 @@
> #include <linux/signal.h>
> #include <linux/slab.h>
> #include <linux/sysctl.h>
> +#include <linux/locallock.h>
>
> #include <asm/fpsimd.h>
> #include <asm/cputype.h>
> @@ -235,7 +236,7 @@ static void sve_user_enable(void)
> * whether TIF_SVE is clear or set, since these are not vector length
> * dependent.
> */
> -
> +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> /*
> * Update current's FPSIMD/SVE registers from thread_struct.
> *
> @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> * non-SVE thread.
> */
> if (task == current) {
> + local_lock(fpsimd_lock);
> local_bh_disable();
>
> task_fpsimd_save();
> @@ -604,8 +606,10 @@ int sve_set_vector_length(struct task_struct *task,
> if (test_and_clear_tsk_thread_flag(task, TIF_SVE))
> sve_to_fpsimd(task);
>
> - if (task == current)
> + if (task == current) {
> + local_unlock(fpsimd_lock);
Is this misordered against local_bh_enable(), or doesn't it matter?
> local_bh_enable();
> + }
>
> /*
> * Force reallocation of task SVE state to the correct size
> @@ -838,6 +842,7 @@ asmlinkage void do_sve_acc(unsigned int esr, struct pt_regs *regs)
> sve_alloc(current);
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
>
> task_fpsimd_save();
> fpsimd_to_sve(current);
> @@ -849,6 +854,7 @@ asmlinkage void do_sve_acc(unsigned int esr, struct pt_regs *regs)
> if (test_and_set_thread_flag(TIF_SVE))
> WARN_ON(1); /* SVE access shouldn't have trapped */
>
> + local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
> @@ -926,6 +932,7 @@ void fpsimd_flush_thread(void)
> return;
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
>
> memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
> fpsimd_flush_task_state(current);
> @@ -967,6 +974,7 @@ void fpsimd_flush_thread(void)
>
> set_thread_flag(TIF_FOREIGN_FPSTATE);
>
> + local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
> @@ -980,7 +988,9 @@ void fpsimd_preserve_current_state(void)
> return;
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
> task_fpsimd_save();
> + local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
> @@ -1022,12 +1032,14 @@ void fpsimd_restore_current_state(void)
> return;
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> task_fpsimd_load();
> fpsimd_bind_to_cpu();
> }
>
> + local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
> @@ -1042,6 +1054,7 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
> return;
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
>
> current->thread.fpsimd_state.user_fpsimd = *state;
> if (system_supports_sve() && test_thread_flag(TIF_SVE))
> @@ -1052,6 +1065,7 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_bind_to_cpu();
>
> + local_unlock(fpsimd_lock);
> local_bh_enable();
> }
>
> @@ -1116,6 +1130,7 @@ void kernel_neon_begin(void)
> BUG_ON(!may_use_simd());
>
> local_bh_disable();
> + local_lock(fpsimd_lock);
>
> __this_cpu_write(kernel_neon_busy, true);
>
> @@ -1128,6 +1143,7 @@ void kernel_neon_begin(void)
> /* Invalidate any task state remaining in the fpsimd regs: */
> fpsimd_flush_cpu_state();
>
> + local_unlock(fpsimd_lock);
> preempt_disable();
>
> local_bh_enable();
The general approach looks reasonable, based on my guesswork about what
the local_lock/_unlocks are doing here.
Cheers
---Dave
[...]
[1] [PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576595.html
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Vince Weaver @ 2018-05-17 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517180758.GK12198@hirez.programming.kicks-ass.net>
On Thu, 17 May 2018, Peter Zijlstra wrote:
> On Thu, May 17, 2018 at 06:55:26PM +0200, Stefan Wahren wrote:
> > > Vince Weaver <vincent.weaver@maine.edu> hat am 17. Mai 2018 um 18:34 geschrieben:
> > > On Thu, 17 May 2018, Stefan Wahren wrote:
> > > > > Eric Anholt <eric@anholt.net> hat am 17. Mai 2018 um 15:17 geschrieben:
>
> > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that
> > > > > arm32 can probe.
> > >
> > > so how closely did you look at the a53/a7 differences? I see some major
> > > differences, especially with the CPU_CYCLES event (0xff vs 0x11).
> > >
> > > The proper fix here might be to add a cortex-a53 PMU entry to the armv7
> > > code rather than trying to treat it as a cortex-a7.
> >
> > we like to use the PMU of BCM2837 SoC (4x A53 cores) under arm32 and arm64.
> >
> > What is the right way (tm) to the define the DT compatibles?
> > Does the arm32 PMU driver need patching for proper A53 support?
>
> I'm completely clueless on all of this; Mark might have ideas.
Spending more time looking at it the only obvious differences are the
previously mentioned CYCLES difference, as well as the cortex-a7 has
18 events in the perf_cache_map but cortex-a53 only has 3. Plus probably
support for the various other features of the armv8v3 pmu that the a7
knows nothing about.
Is it hard to get lines in the DT changed once they are there? If we go
with cortex-a7 now, would it be possible to later drop that if proper
cortex-a53 support is added to the armv7 pmu driver? Or would that lead
to all kinds of back-compatability mess?
Vince
^ permalink raw reply
* [PATCH v2] pinctrl: pinctrl-single: Add functions to save and restore pinctrl context
From: Tony Lindgren @ 2018-05-17 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526532021-16387-1-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [180517 04:42]:
> This adds a pair of context save/restore functions to save/restore the
> state of a set of pinctrl registers. The context is lost during rtc only
> suspend with ddr in self-refresh on am43xx. Currently the save/restore
> is being done unconditionally. This will be optimized later with a
> pdata-quirk function which will allow is to save/restore only when doing
> the rtc only mode with ddr in self refresh.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>
> Changes in v2:
>
> * As this is needed only the in the suspend/resume path
> removed the cpu_pm notifier and added the save/restore in
> the suspend/resume calls.
> * Saving/Restoring unconditionally at the moment. This will
> be optimized later with the help of a pdata-quirk function.
Looks good to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v6 6/9] dt-bindings: counter: Document stm32 quadrature encoder
From: Benjamin Gaignard @ 2018-05-17 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+a4s=5N6wUWifoHWQoornbDBY-UY2xrwj1kggNH4Q5pQ@mail.gmail.com>
2018-05-17 18:23 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> On Wed, May 16, 2018 at 12:51 PM, William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
>> From: Benjamin Gaignard <benjamin.gaignard@st.com>
>
> v6? Where's v1-v5?
>
>> Add bindings for STM32 Timer quadrature encoder.
>> It is a sub-node of STM32 Timer which implement the
>> counter part of the hardware.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>> ---
>> .../bindings/counter/stm32-timer-cnt.txt | 26 +++++++++++++++++++
>> .../devicetree/bindings/mfd/stm32-timers.txt | 7 +++++
>> 2 files changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>>
>> diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> new file mode 100644
>> index 000000000000..377728128bef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> @@ -0,0 +1,26 @@
>> +STMicroelectronics STM32 Timer quadrature encoder
>> +
>> +STM32 Timer provides quadrature encoder counter mode to detect
>
> 'mode' does not sound like a sub-block of the timers block.
quadrature encoding is one of the counting modes of this hardware
block which is enable to count on other signals/triggers
>
>> +angular position and direction of rotary elements,
>> +from IN1 and IN2 input signals.
>> +
>> +Must be a sub-node of an STM32 Timer device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required properties:
>> +- compatible: Must be "st,stm32-timer-counter".
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes,
>> + to set IN1/IN2 pins in mode of operation for Low-Power
>> + Timer input on external pin.
>> +
>> +Example:
>> + timers at 40010000 {
>> + compatible = "st,stm32-timers";
>> + ...
>> + counter {
>> + compatible = "st,stm32-timer-counter";
>
> Is there only 1? How is the counter addressed?
Yes there is only one counter per hardware block.
Counter is addressed like the two others sub-nodes and the details
about parent mode are describe in stm32-timers.txt
Should I add them here too ? so example will be like that:
timers at 40010000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "st,stm32-timers";
reg = <0x40010000 0x400>;
clocks = <&rcc 0 160>;
clock-names = "int";
counter {
compatible = "st,stm32-timer-counter";
pinctrl-names = "default";
pinctrl-0 = <&tim1_in_pins>;
};
};
Benjamin
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
From: Nikita Yushchenko @ 2018-05-17 19:19 UTC (permalink / raw)
To: linux-arm-kernel
This adds rave-sp powerbutton and backlight devices to RDU1 device tree.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 0c99ac04ad08..98cc107098e0 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -581,6 +581,14 @@
watchdog {
compatible = "zii,rave-sp-watchdog";
};
+
+ backlight {
+ compatible = "zii,rave-sp-backlight";
+ };
+
+ pwrbutton {
+ compatible = "zii,rave-sp-pwrbutton";
+ };
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Vince Weaver @ 2018-05-17 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1805171422450.8529@macbook-air>
On Thu, 17 May 2018, Vince Weaver wrote:
> On Thu, 17 May 2018, Peter Zijlstra wrote:
> with cortex-a7 now, would it be possible to later drop that if proper
> cortex-a53 support is added to the armv7 pmu driver? Or would that lead
> to all kinds of back-compatability mess?
For what it's worth, the pi-foundation kernel bcm2710 device tree file
does:
arm-pmu {
#ifdef RPI364
compatible = "arm,armv8-pmuv3", "arm,cortex-a7-pmu";
#else
compatible = "arm,cortex-a7-pmu";
#endif
interrupt-parent = <&local_intc>;
interrupts = <9>;
};
Which is probably where I was getting the arm,armv8-pmuv3 from in my
original patch.
Vince
^ permalink raw reply
* [PATCH] mm/dmapool: localize page allocations
From: Sinan Kaya @ 2018-05-17 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517181815.GC26718@bombadil.infradead.org>
On 5/17/2018 2:18 PM, Matthew Wilcox wrote:
> On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote:
>> Try to keep the pool closer to the device's NUMA node by changing kmalloc()
>> to kmalloc_node() and devres_alloc() to devres_alloc_node().
> Have you measured any performance gains by doing this? The thing is that
> these allocations are for the metadata about the page, and the page is
> going to be used by CPUs in every node. So it's not clear to me that
> allocating it on the node nearest to the device is going to be any sort
> of a win.
>
It is true that this is metadata but it is one of the things that is most
frequently used in spite of its small size.
I don't think it makes any sense to cross a chip boundary for accessing a
pointer location on every single pool allocation.
Remember that the CPU core that is running this driver is most probably on
the same NUMA node as the device itself.
Also, if it was a one time init kind of thing, I'd say "yeah, leave it alone".
DMA pool is used by a wide range of drivers and it is used to allocate
fixed size buffers at runtime.
Performance impact changes depending on the driver in use. This particular
code is in use by network adapters as well as the NVMe driver. It does
have a wide range of impact.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] mm/dmapool: localize page allocations
From: Matthew Wilcox @ 2018-05-17 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9844a638-bc4e-46bd-133e-0c82a3e9d6ea@codeaurora.org>
On Thu, May 17, 2018 at 03:37:21PM -0400, Sinan Kaya wrote:
> On 5/17/2018 2:18 PM, Matthew Wilcox wrote:
> > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote:
> >> Try to keep the pool closer to the device's NUMA node by changing kmalloc()
> >> to kmalloc_node() and devres_alloc() to devres_alloc_node().
> > Have you measured any performance gains by doing this? The thing is that
> > these allocations are for the metadata about the page, and the page is
> > going to be used by CPUs in every node. So it's not clear to me that
> > allocating it on the node nearest to the device is going to be any sort
> > of a win.
> >
>
> It is true that this is metadata but it is one of the things that is most
> frequently used in spite of its small size.
>
> I don't think it makes any sense to cross a chip boundary for accessing a
> pointer location on every single pool allocation.
>
> Remember that the CPU core that is running this driver is most probably on
> the same NUMA node as the device itself.
Umm ... says who? If my process is running on NUMA node 5 and I submit
an I/O, it should be allocating from a pool on node 5, not from a pool
on whichever node the device is attached to.
If it actually makes a performance difference, then NVMe should allocate
one pool per queue, rather than one pool per device like it currently
does.
> Also, if it was a one time init kind of thing, I'd say "yeah, leave it alone".
> DMA pool is used by a wide range of drivers and it is used to allocate
> fixed size buffers at runtime.
* DMA Pool allocator
*
* Copyright 2001 David Brownell
* Copyright 2007 Intel Corporation
* Author: Matthew Wilcox <willy@linux.intel.com>
I know what it's used for.
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Florian Fainelli @ 2018-05-17 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1805171530080.8529@macbook-air>
On 05/17/2018 12:31 PM, Vince Weaver wrote:
> On Thu, 17 May 2018, Vince Weaver wrote:
>
>> On Thu, 17 May 2018, Peter Zijlstra wrote:
>> with cortex-a7 now, would it be possible to later drop that if proper
>> cortex-a53 support is added to the armv7 pmu driver? Or would that lead
>> to all kinds of back-compatability mess?
>
> For what it's worth, the pi-foundation kernel bcm2710 device tree file
> does:
>
> arm-pmu {
> #ifdef RPI364
> compatible = "arm,armv8-pmuv3", "arm,cortex-a7-pmu";
> #else
> compatible = "arm,cortex-a7-pmu";
> #endif
> interrupt-parent = <&local_intc>;
> interrupts = <9>;
> };
>
>
> Which is probably where I was getting the arm,armv8-pmuv3 from in my
> original patch.
I thought somehow that Marc Z. had unified
arch/arm/kernel/perf_event_v7.c and arch/arm64/kernel/perf_event.c into
a common driver entry point under drivers/perf/arm_pmu.c but I don't see
it and after about 15 minutes looking at it, it does not look as trivial
as I though to separate out those files so the ARMv8 PMU description can
be moved into a generic location for instance.
FWIW, Broadcom STB chips, even when 64-bit capable or often used with an
32-bit ARM kernel, so having the ARMv8 PMUs work under a 32-bit ARM
kernel would be great. The downstream solution we have sued thus far is
to find the closest compatible string to represent those, which is not
great...
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox