* [PATCH v2 23/27] coresight: tmc-etr: Handle driver mode specific ETR buffers
From: Mathieu Poirier @ 2018-05-09 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a16587f9-bb0f-e806-9c8d-ee4af0e8b805@arm.com>
On 8 May 2018 at 15:51, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 05/08/2018 06:18 PM, Mathieu Poirier wrote:
>>
>> On Tue, May 01, 2018 at 10:10:53AM +0100, Suzuki K Poulose wrote:
>>>
>>> Since the ETR could be driven either by SYSFS or by perf, it
>>> becomes complicated how we deal with the buffers used for each
>>> of these modes. The ETR driver cannot simply free the current
>>> attached buffer without knowing the provider (i.e, sysfs vs perf).
>>>
>>> To solve this issue, we provide:
>>> 1) the driver-mode specific etr buffer to be retained in the drvdata
>>> 2) the etr_buf for a session should be passed on when enabling the
>>> hardware, which will be stored in drvdata->etr_buf. This will be
>>> replaced (not free'd) as soon as the hardware is disabled, after
>>> necessary sync operation.
>>>
>>> The advantages of this are :
>>>
>>> 1) The common code path doesn't need to worry about how to dispose
>>> an existing buffer, if it is about to start a new session with a
>>> different buffer, possibly in a different mode.
>>> 2) The driver mode can control its buffers and can get access to the
>>> saved session even when the hardware is operating in a different
>>> mode. (e.g, we can still access a trace buffer from a sysfs mode
>>> even if the etr is now used in perf mode, without disrupting the
>>> current session.)
>>>
>>> Towards this, we introduce a sysfs specific data which will hold the
>>> etr_buf used for sysfs mode of operation, controlled solely by the
>>> sysfs mode handling code.
>>
>>
>> Thinking further on this... I toyed with the idea of doing the same thing
>> when
>> working on the original driver and decided against it. Do we really have
>> a case
>> where users would want to use sysFS and perf alternatively? To me this
>> looks
>> overdesigned.
>>
>> If we are going to go that way we need to enact the same behavior for
>> ETB10 and
>> ETF... And take it out of this set as it is already substantial enough.
>
>
> The difference between ETB10/ETF and ETR is the usage of the buffer. The
> former uses an internal buffer and we always have to copy it out to an
> external buffer for consumption. Now this external buffer is actually
> separate for each mode, i.e sysfs and perf. Also the data is copied
> out right after we disable the HW. This ensures that the interleaved
> mode doesn't corrupt each others data.
Hi Suzuki,
When I wrote my original comment I was under the impression that
ETB10/ETF's drvdata->buf was used for both sysFS and perf, but after
going back to the code find it isn't the case. As such a user can
call sysFS and perf session alternately without destroying the results
acquired from the previous trace scenario. This is also what your
patch is providing, enacting the same (desired) behaviour we currently
have.
I'm good with this one.
Mathieu
>
> However, the ETR doesn't have an internal buffer and uses the System RAM.
> That brings in the problem of one mode using the "buffer" as
> described by the drvdata. So, eventually either mode could write to
> the buffer allocated by the other mode before it is consumed by the
> end user (via syfs read or perf). That brings in the challenge of
> managing the buffer safely, switching back and forth the buffer
> (with the right size and pages) for each mode without any interferences.
> That also implies, one mode must be able to free the left-over buffer
> from the previous mode safely (which could be potentially linked to
> other data structures maintained by the mode). And that makes it more
> complex. e.g, we must leave the sysfs trace data for collection and
> meanwhile the perf could grab the ETR for its usage. The perf mode
> might not know the mode of the existing buffer and thus wouldn't know
> how to free it properly.
>
> This is why we need buffers per mode which can be managed by
> each mode. i.e, both allocated, used and more importantly free'd
> appropriately.
>
> Cheers
> Suzuki
^ permalink raw reply
* [PATCH v7 02/16] arm64: Use update{,_tsk}_thread_flag()
From: Dave Martin @ 2018-05-09 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f444acee-b558-7dbb-97bd-bbf716b20ebd@arm.com>
On Wed, May 09, 2018 at 05:55:51PM +0100, Marc Zyngier wrote:
> On 09/05/18 17:27, Dave Martin wrote:
> > On Wed, May 09, 2018 at 05:17:28PM +0100, Will Deacon wrote:
> >> Hi Dave,
> >>
> >> On Wed, May 09, 2018 at 05:12:51PM +0100, Dave Martin wrote:
> >>> This patch uses the new update_thread_flag() helpers to simplify a
> >>> couple of if () set; else clear; constructs.
> >>>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> >>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> >>> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >>> Cc: Will Deacon <will.deacon@arm.com>
> >>> ---
> >>> arch/arm64/kernel/fpsimd.c | 19 +++++++------------
> >>> 1 file changed, 7 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> >>> index 87a3536..0c4e7e0 100644
> >>> --- a/arch/arm64/kernel/fpsimd.c
> >>> +++ b/arch/arm64/kernel/fpsimd.c
> >
> > [...]
> >
> >>> @@ -902,7 +900,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> >>> if (current->mm)
> >>> task_fpsimd_save();
> >>>
> >>> - if (next->mm) {
> >>> + if (next->mm)
> >>> /*
> >>> * If we are switching to a task whose most recent userland
> >>> * FPSIMD state is already in the registers of *this* cpu,
> >>> @@ -910,13 +908,10 @@ void fpsimd_thread_switch(struct task_struct *next)
> >>> * the TIF_FOREIGN_FPSTATE flag so the state will be loaded
> >>> * upon the next return to userland.
> >>> */
> >>> - if (__this_cpu_read(fpsimd_last_state.st) ==
> >>> - &next->thread.uw.fpsimd_state
> >>> - && next->thread.fpsimd_cpu == smp_processor_id())
> >>> - clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> >>> - else
> >>> - set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> >>> - }
> >>> + update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> >>> + __this_cpu_read(fpsimd_last_state.st) !=
> >>> + &next->thread.uw.fpsimd_state ||
> >>> + next->thread.fpsimd_cpu != smp_processor_id());
> >>
> >> Given the multi-line comment and this multi-line call, I'd be inclined to
> >> leave the curlies in place and then use a local bool for the complex
> >> condition.
> >
> > Hey, curlies cost money, you know.
> >
> >> With that:
> >>
> >> Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > Are you content to see this merged without the change? It doesn't seem
> > worth a respin of the whole series just for this. I agree the code
> > would be clearer, but this patch doesn't actually make it worse IMHO.
> >
> > If I respin for some reason though, I can address this and add your Ack.
>
> I'm happy to perform the change myself when applying the series if there
> is no additional comment that would lead to a respin.
OK, feel free to apply the following if it looks good for you.
Cheers
---Dave
--8<--
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 32898a8..b0d29b7 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -906,7 +906,7 @@ void fpsimd_thread_switch(struct task_struct *next)
if (current->mm)
fpsimd_save();
- if (next->mm)
+ if (next->mm) {
/*
* If we are switching to a task whose most recent userland
* FPSIMD state is already in the registers of *this* cpu,
@@ -914,10 +914,13 @@ void fpsimd_thread_switch(struct task_struct *next)
* the TIF_FOREIGN_FPSTATE flag so the state will be loaded
* upon the next return to userland.
*/
+ bool wrong_task = __this_cpu_read(fpsimd_last_state.st) !=
+ &next->thread.uw.fpsimd_state;
+ bool wrong_cpu = next->thread.fpsimd_cpu != smp_processor_id();
+
update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
- __this_cpu_read(fpsimd_last_state.st) !=
- &next->thread.uw.fpsimd_state ||
- next->thread.fpsimd_cpu != smp_processor_id());
+ wrong_task || wrong_cpu);
+ }
}
void fpsimd_flush_thread(void)
^ permalink raw reply related
* [PATCH 8/8] firmware: arm_scmi: simplify exit path by returning on error
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
Yet another nasty indentation left out during code restructuring. It's
must simpler to return on error instead of having unnecessary indentation.
Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 4087d6c50ecd..e996395af5f2 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -687,11 +687,12 @@ static int scmi_remove(struct platform_device *pdev)
list_del(&info->node);
mutex_unlock(&scmi_list_mutex);
- if (!ret) {
- /* Safe to free channels since no more users */
- ret = idr_for_each(idr, scmi_mbox_free_channel, idr);
- idr_destroy(&info->tx_idr);
- }
+ if (ret)
+ return ret;
+
+ /* Safe to free channels since no more users */
+ ret = idr_for_each(idr, scmi_mbox_free_channel, idr);
+ idr_destroy(&info->tx_idr);
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 7/8] firmware: arm_scmi: improve exit paths and code readability
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
The existing code intends the good path to reduce the code which is so
uncommon. It's obvious to have more readable code with a goto used for
the error path. This patch adds more appropriate error paths and makes
code more readable. It also moves a error logging outside the scope of
locking.
Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/bus.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index f2760a596c28..472c88ae1c0f 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -125,13 +125,13 @@ scmi_device_create(struct device_node *np, struct device *parent, int protocol)
int id, retval;
struct scmi_device *scmi_dev;
- id = ida_simple_get(&scmi_bus_id, 1, 0, GFP_KERNEL);
- if (id < 0)
- return NULL;
-
scmi_dev = kzalloc(sizeof(*scmi_dev), GFP_KERNEL);
if (!scmi_dev)
- goto no_mem;
+ return NULL;
+
+ id = ida_simple_get(&scmi_bus_id, 1, 0, GFP_KERNEL);
+ if (id < 0)
+ goto free_mem;
scmi_dev->id = id;
scmi_dev->protocol_id = protocol;
@@ -141,13 +141,15 @@ scmi_device_create(struct device_node *np, struct device *parent, int protocol)
dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
retval = device_register(&scmi_dev->dev);
- if (!retval)
- return scmi_dev;
+ if (retval)
+ goto put_dev;
+ return scmi_dev;
+put_dev:
put_device(&scmi_dev->dev);
- kfree(scmi_dev);
-no_mem:
ida_simple_remove(&scmi_bus_id, id);
+free_mem:
+ kfree(scmi_dev);
return NULL;
}
@@ -171,9 +173,9 @@ int scmi_protocol_register(int protocol_id, scmi_prot_init_fn_t fn)
spin_lock(&protocol_lock);
ret = idr_alloc(&scmi_protocols, fn, protocol_id, protocol_id + 1,
GFP_ATOMIC);
+ spin_unlock(&protocol_lock);
if (ret != protocol_id)
pr_err("unable to allocate SCMI idr slot, err %d\n", ret);
- spin_unlock(&protocol_lock);
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 6/8] firmware: arm_scmi: remove unnecessary bitmap_zero
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
kcalloc zeros the memory and it's totally unnecessary to zero the bitmap
again using bitmap_zero. This patch just drops the unnecessary use of
the bitmap_zero in the context.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/driver.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 33d2b78af3ff..4087d6c50ecd 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -636,8 +636,6 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
if (!info->xfer_alloc_table)
return -ENOMEM;
- bitmap_zero(info->xfer_alloc_table, desc->max_msg);
-
/* Pre-initialize the buffer pointer to pre-allocated buffers */
for (i = 0, xfer = info->xfer_block; i < desc->max_msg; i++, xfer++) {
xfer->rx.buf = devm_kcalloc(dev, sizeof(u8), desc->max_msg_size,
--
2.7.4
^ permalink raw reply related
* [PATCH 5/8] firmware: arm_scmi: drop unused `con_priv` structure member
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
Initially con_priv was supposedly used for transport specific data when
the SCMI driver had an abstraction to communicate with different mailbox
controllers. But after some discussions, the idea was dropped but this
variable slipped through the cracks.
This patch gets rid of this unused variable.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/common.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 41b03e46cca8..937a930ce87d 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -86,9 +86,7 @@ struct scmi_msg {
* buffer for the rx path as we use for the tx path.
* @done: completion event
*/
-
struct scmi_xfer {
- void *con_priv;
struct scmi_msg_hdr hdr;
struct scmi_msg tx;
struct scmi_msg rx;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/8] firmware: arm_scmi: rename scmi_xfer_{init,get,put}
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
Just after the initial patches were queued, Jonathan Cameron mentioned
that scmi_one_xfer_{get_put} were not very clear and suggested to use
scmi_xfer_{alloc,free}. While I agree to some extent, the reason not to
have alloc/free as these are preallocated buffers and these functions
just returns a reference to free slot in that preallocated array.
However it was agreed to drop "_one" as it's implicit that we are always
dealing with one slot anyways.
This patch updates the name accordingly dropping "_one" in both {get,put}
functions. Also scmi_one_xfer_init is renamed as scmi_xfer_get_init to
reflect the fact that it gets the free slots and then initialise it.
Reported-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/base.c | 23 +++++++++++++----------
drivers/firmware/arm_scmi/clock.c | 24 ++++++++++++------------
drivers/firmware/arm_scmi/common.h | 4 ++--
drivers/firmware/arm_scmi/driver.c | 20 ++++++++++----------
drivers/firmware/arm_scmi/perf.c | 28 ++++++++++++++--------------
drivers/firmware/arm_scmi/power.c | 16 ++++++++--------
drivers/firmware/arm_scmi/sensors.c | 20 ++++++++++----------
7 files changed, 69 insertions(+), 66 deletions(-)
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index c36ded9dbb83..9dff33ea6416 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -37,7 +37,7 @@ static int scmi_base_attributes_get(const struct scmi_handle *handle)
struct scmi_msg_resp_base_attributes *attr_info;
struct scmi_revision_info *rev = handle->version;
- ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_ATTRIBUTES,
SCMI_PROTOCOL_BASE, 0, sizeof(*attr_info), &t);
if (ret)
return ret;
@@ -49,7 +49,7 @@ static int scmi_base_attributes_get(const struct scmi_handle *handle)
rev->num_agents = attr_info->num_agents;
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -81,7 +81,7 @@ scmi_base_vendor_id_get(const struct scmi_handle *handle, bool sub_vendor)
size = ARRAY_SIZE(rev->vendor_id);
}
- ret = scmi_one_xfer_init(handle, cmd, SCMI_PROTOCOL_BASE, 0, size, &t);
+ ret = scmi_xfer_get_init(handle, cmd, SCMI_PROTOCOL_BASE, 0, size, &t);
if (ret)
return ret;
@@ -89,7 +89,8 @@ scmi_base_vendor_id_get(const struct scmi_handle *handle, bool sub_vendor)
if (!ret)
memcpy(vendor_id, t->rx.buf, size);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
+
return ret;
}
@@ -110,7 +111,7 @@ scmi_base_implementation_version_get(const struct scmi_handle *handle)
struct scmi_xfer *t;
struct scmi_revision_info *rev = handle->version;
- ret = scmi_one_xfer_init(handle, BASE_DISCOVER_IMPLEMENT_VERSION,
+ ret = scmi_xfer_get_init(handle, BASE_DISCOVER_IMPLEMENT_VERSION,
SCMI_PROTOCOL_BASE, 0, sizeof(*impl_ver), &t);
if (ret)
return ret;
@@ -121,7 +122,8 @@ scmi_base_implementation_version_get(const struct scmi_handle *handle)
rev->impl_ver = le32_to_cpu(*impl_ver);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
+
return ret;
}
@@ -144,7 +146,7 @@ static int scmi_base_implementation_list_get(const struct scmi_handle *handle,
u32 tot_num_ret = 0, loop_num_ret;
struct device *dev = handle->dev;
- ret = scmi_one_xfer_init(handle, BASE_DISCOVER_LIST_PROTOCOLS,
+ ret = scmi_xfer_get_init(handle, BASE_DISCOVER_LIST_PROTOCOLS,
SCMI_PROTOCOL_BASE, sizeof(*num_skip), 0, &t);
if (ret)
return ret;
@@ -173,7 +175,7 @@ static int scmi_base_implementation_list_get(const struct scmi_handle *handle,
tot_num_ret += loop_num_ret;
} while (loop_num_ret);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -196,7 +198,7 @@ static int scmi_base_discover_agent_get(const struct scmi_handle *handle,
int ret;
struct scmi_xfer *t;
- ret = scmi_one_xfer_init(handle, BASE_DISCOVER_AGENT,
+ ret = scmi_xfer_get_init(handle, BASE_DISCOVER_AGENT,
SCMI_PROTOCOL_BASE, sizeof(__le32),
SCMI_MAX_STR_SIZE, &t);
if (ret)
@@ -208,7 +210,8 @@ static int scmi_base_discover_agent_get(const struct scmi_handle *handle,
if (!ret)
memcpy(name, t->rx.buf, SCMI_MAX_STR_SIZE);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
+
return ret;
}
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index e6f17825db79..3874666a8a14 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -77,7 +77,7 @@ static int scmi_clock_protocol_attributes_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_clock_protocol_attributes *attr;
- ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_ATTRIBUTES,
SCMI_PROTOCOL_CLOCK, 0, sizeof(*attr), &t);
if (ret)
return ret;
@@ -90,7 +90,7 @@ static int scmi_clock_protocol_attributes_get(const struct scmi_handle *handle,
ci->max_async_req = attr->max_async_req;
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -101,7 +101,7 @@ static int scmi_clock_attributes_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_clock_attributes *attr;
- ret = scmi_one_xfer_init(handle, CLOCK_ATTRIBUTES, SCMI_PROTOCOL_CLOCK,
+ ret = scmi_xfer_get_init(handle, CLOCK_ATTRIBUTES, SCMI_PROTOCOL_CLOCK,
sizeof(clk_id), sizeof(*attr), &t);
if (ret)
return ret;
@@ -115,7 +115,7 @@ static int scmi_clock_attributes_get(const struct scmi_handle *handle,
else
clk->name[0] = '\0';
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -132,7 +132,7 @@ scmi_clock_describe_rates_get(const struct scmi_handle *handle, u32 clk_id,
struct scmi_msg_clock_describe_rates *clk_desc;
struct scmi_msg_resp_clock_describe_rates *rlist;
- ret = scmi_one_xfer_init(handle, CLOCK_DESCRIBE_RATES,
+ ret = scmi_xfer_get_init(handle, CLOCK_DESCRIBE_RATES,
SCMI_PROTOCOL_CLOCK, sizeof(*clk_desc), 0, &t);
if (ret)
return ret;
@@ -186,7 +186,7 @@ scmi_clock_describe_rates_get(const struct scmi_handle *handle, u32 clk_id,
clk->list.num_rates = tot_rate_cnt;
err:
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -196,7 +196,7 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
int ret;
struct scmi_xfer *t;
- ret = scmi_one_xfer_init(handle, CLOCK_RATE_GET, SCMI_PROTOCOL_CLOCK,
+ ret = scmi_xfer_get_init(handle, CLOCK_RATE_GET, SCMI_PROTOCOL_CLOCK,
sizeof(__le32), sizeof(u64), &t);
if (ret)
return ret;
@@ -211,7 +211,7 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
*value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -222,7 +222,7 @@ static int scmi_clock_rate_set(const struct scmi_handle *handle, u32 clk_id,
struct scmi_xfer *t;
struct scmi_clock_set_rate *cfg;
- ret = scmi_one_xfer_init(handle, CLOCK_RATE_SET, SCMI_PROTOCOL_CLOCK,
+ ret = scmi_xfer_get_init(handle, CLOCK_RATE_SET, SCMI_PROTOCOL_CLOCK,
sizeof(*cfg), 0, &t);
if (ret)
return ret;
@@ -235,7 +235,7 @@ static int scmi_clock_rate_set(const struct scmi_handle *handle, u32 clk_id,
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -246,7 +246,7 @@ scmi_clock_config_set(const struct scmi_handle *handle, u32 clk_id, u32 config)
struct scmi_xfer *t;
struct scmi_clock_set_config *cfg;
- ret = scmi_one_xfer_init(handle, CLOCK_CONFIG_SET, SCMI_PROTOCOL_CLOCK,
+ ret = scmi_xfer_get_init(handle, CLOCK_CONFIG_SET, SCMI_PROTOCOL_CLOCK,
sizeof(*cfg), 0, &t);
if (ret)
return ret;
@@ -257,7 +257,7 @@ scmi_clock_config_set(const struct scmi_handle *handle, u32 clk_id, u32 config)
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 0821662a4633..41b03e46cca8 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -95,9 +95,9 @@ struct scmi_xfer {
struct completion done;
};
-void scmi_one_xfer_put(const struct scmi_handle *h, struct scmi_xfer *xfer);
+void scmi_xfer_put(const struct scmi_handle *h, struct scmi_xfer *xfer);
int scmi_do_xfer(const struct scmi_handle *h, struct scmi_xfer *xfer);
-int scmi_one_xfer_init(const struct scmi_handle *h, u8 msg_id, u8 prot_id,
+int scmi_xfer_get_init(const struct scmi_handle *h, u8 msg_id, u8 prot_id,
size_t tx_size, size_t rx_size, struct scmi_xfer **p);
int scmi_handle_put(const struct scmi_handle *handle);
struct scmi_handle *scmi_handle_get(struct device *dev);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 6fee11f06a66..33d2b78af3ff 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -295,7 +295,7 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m)
*
* Return: 0 if all went fine, else corresponding error.
*/
-static struct scmi_xfer *scmi_one_xfer_get(const struct scmi_handle *handle)
+static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle)
{
u16 xfer_id;
struct scmi_xfer *xfer;
@@ -324,14 +324,14 @@ static struct scmi_xfer *scmi_one_xfer_get(const struct scmi_handle *handle)
}
/**
- * scmi_one_xfer_put() - Release a message
+ * scmi_xfer_put() - Release a message
*
* @handle: Pointer to SCMI entity handle
* @xfer: message that was reserved by scmi_xfer_get
*
* This holds a spinlock to maintain integrity of internal data structures.
*/
-void scmi_one_xfer_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
+void scmi_xfer_put(const struct scmi_handle *handle, struct scmi_xfer *xfer)
{
unsigned long flags;
struct scmi_info *info = handle_to_scmi_info(handle);
@@ -436,7 +436,7 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
}
/**
- * scmi_one_xfer_init() - Allocate and initialise one message
+ * scmi_xfer_get_init() - Allocate and initialise one message
*
* @handle: Pointer to SCMI entity handle
* @msg_id: Message identifier
@@ -445,13 +445,13 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
* @rx_size: receive message size
* @p: pointer to the allocated and initialised message
*
- * This function allocates the message using @scmi_one_xfer_get and
+ * This function allocates the message using @scmi_xfer_get and
* initialise the header.
*
* Return: 0 if all went fine with @p pointing to message, else
* corresponding error.
*/
-int scmi_one_xfer_init(const struct scmi_handle *handle, u8 msg_id, u8 prot_id,
+int scmi_xfer_get_init(const struct scmi_handle *handle, u8 msg_id, u8 prot_id,
size_t tx_size, size_t rx_size, struct scmi_xfer **p)
{
int ret;
@@ -464,7 +464,7 @@ int scmi_one_xfer_init(const struct scmi_handle *handle, u8 msg_id, u8 prot_id,
tx_size > info->desc->max_msg_size)
return -ERANGE;
- xfer = scmi_one_xfer_get(handle);
+ xfer = scmi_xfer_get(handle);
if (IS_ERR(xfer)) {
ret = PTR_ERR(xfer);
dev_err(dev, "failed to get free message slot(%d)\n", ret);
@@ -500,7 +500,7 @@ int scmi_version_get(const struct scmi_handle *handle, u8 protocol,
__le32 *rev_info;
struct scmi_xfer *t;
- ret = scmi_one_xfer_init(handle, PROTOCOL_VERSION, protocol, 0,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_VERSION, protocol, 0,
sizeof(*version), &t);
if (ret)
return ret;
@@ -511,7 +511,7 @@ int scmi_version_get(const struct scmi_handle *handle, u8 protocol,
*version = le32_to_cpu(*rev_info);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -539,7 +539,7 @@ scmi_is_protocol_implemented(const struct scmi_handle *handle, u8 prot_id)
}
/**
- * scmi_handle_get() - Get the SCMI handle for a device
+ * scmi_handle_get() - Get the SCMI handle for a device
*
* @dev: pointer to device for which we want SCMI handle
*
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 611ab08e6174..2a219b1261b1 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -115,7 +115,7 @@ static int scmi_perf_attributes_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_perf_attributes *attr;
- ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_ATTRIBUTES,
SCMI_PROTOCOL_PERF, 0, sizeof(*attr), &t);
if (ret)
return ret;
@@ -133,7 +133,7 @@ static int scmi_perf_attributes_get(const struct scmi_handle *handle,
pi->stats_size = le32_to_cpu(attr->stats_size);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -145,7 +145,7 @@ scmi_perf_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_msg_resp_perf_domain_attributes *attr;
- ret = scmi_one_xfer_init(handle, PERF_DOMAIN_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PERF_DOMAIN_ATTRIBUTES,
SCMI_PROTOCOL_PERF, sizeof(domain),
sizeof(*attr), &t);
if (ret)
@@ -171,7 +171,7 @@ scmi_perf_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
memcpy(dom_info->name, attr->name, SCMI_MAX_STR_SIZE);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -194,7 +194,7 @@ scmi_perf_describe_levels_get(const struct scmi_handle *handle, u32 domain,
struct scmi_msg_perf_describe_levels *dom_info;
struct scmi_msg_resp_perf_describe_levels *level_info;
- ret = scmi_one_xfer_init(handle, PERF_DESCRIBE_LEVELS,
+ ret = scmi_xfer_get_init(handle, PERF_DESCRIBE_LEVELS,
SCMI_PROTOCOL_PERF, sizeof(*dom_info), 0, &t);
if (ret)
return ret;
@@ -237,7 +237,7 @@ scmi_perf_describe_levels_get(const struct scmi_handle *handle, u32 domain,
} while (num_returned && num_remaining);
perf_dom->opp_count = tot_opp_cnt;
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
sort(perf_dom->opp, tot_opp_cnt, sizeof(*opp), opp_cmp_func, NULL);
return ret;
@@ -250,7 +250,7 @@ static int scmi_perf_limits_set(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_perf_set_limits *limits;
- ret = scmi_one_xfer_init(handle, PERF_LIMITS_SET, SCMI_PROTOCOL_PERF,
+ ret = scmi_xfer_get_init(handle, PERF_LIMITS_SET, SCMI_PROTOCOL_PERF,
sizeof(*limits), 0, &t);
if (ret)
return ret;
@@ -262,7 +262,7 @@ static int scmi_perf_limits_set(const struct scmi_handle *handle, u32 domain,
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -273,7 +273,7 @@ static int scmi_perf_limits_get(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_perf_get_limits *limits;
- ret = scmi_one_xfer_init(handle, PERF_LIMITS_GET, SCMI_PROTOCOL_PERF,
+ ret = scmi_xfer_get_init(handle, PERF_LIMITS_GET, SCMI_PROTOCOL_PERF,
sizeof(__le32), 0, &t);
if (ret)
return ret;
@@ -288,7 +288,7 @@ static int scmi_perf_limits_get(const struct scmi_handle *handle, u32 domain,
*min_perf = le32_to_cpu(limits->min_level);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -299,7 +299,7 @@ static int scmi_perf_level_set(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_perf_set_level *lvl;
- ret = scmi_one_xfer_init(handle, PERF_LEVEL_SET, SCMI_PROTOCOL_PERF,
+ ret = scmi_xfer_get_init(handle, PERF_LEVEL_SET, SCMI_PROTOCOL_PERF,
sizeof(*lvl), 0, &t);
if (ret)
return ret;
@@ -311,7 +311,7 @@ static int scmi_perf_level_set(const struct scmi_handle *handle, u32 domain,
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -321,7 +321,7 @@ static int scmi_perf_level_get(const struct scmi_handle *handle, u32 domain,
int ret;
struct scmi_xfer *t;
- ret = scmi_one_xfer_init(handle, PERF_LEVEL_GET, SCMI_PROTOCOL_PERF,
+ ret = scmi_xfer_get_init(handle, PERF_LEVEL_GET, SCMI_PROTOCOL_PERF,
sizeof(u32), sizeof(u32), &t);
if (ret)
return ret;
@@ -333,7 +333,7 @@ static int scmi_perf_level_get(const struct scmi_handle *handle, u32 domain,
if (!ret)
*level = le32_to_cpu(*(__le32 *)t->rx.buf);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index 087c2876cdf2..cfa033b05aed 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -63,7 +63,7 @@ static int scmi_power_attributes_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_power_attributes *attr;
- ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_ATTRIBUTES,
SCMI_PROTOCOL_POWER, 0, sizeof(*attr), &t);
if (ret)
return ret;
@@ -78,7 +78,7 @@ static int scmi_power_attributes_get(const struct scmi_handle *handle,
pi->stats_size = le32_to_cpu(attr->stats_size);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -90,7 +90,7 @@ scmi_power_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
struct scmi_xfer *t;
struct scmi_msg_resp_power_domain_attributes *attr;
- ret = scmi_one_xfer_init(handle, POWER_DOMAIN_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, POWER_DOMAIN_ATTRIBUTES,
SCMI_PROTOCOL_POWER, sizeof(domain),
sizeof(*attr), &t);
if (ret)
@@ -109,7 +109,7 @@ scmi_power_domain_attributes_get(const struct scmi_handle *handle, u32 domain,
memcpy(dom_info->name, attr->name, SCMI_MAX_STR_SIZE);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -120,7 +120,7 @@ scmi_power_state_set(const struct scmi_handle *handle, u32 domain, u32 state)
struct scmi_xfer *t;
struct scmi_power_set_state *st;
- ret = scmi_one_xfer_init(handle, POWER_STATE_SET, SCMI_PROTOCOL_POWER,
+ ret = scmi_xfer_get_init(handle, POWER_STATE_SET, SCMI_PROTOCOL_POWER,
sizeof(*st), 0, &t);
if (ret)
return ret;
@@ -132,7 +132,7 @@ scmi_power_state_set(const struct scmi_handle *handle, u32 domain, u32 state)
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -142,7 +142,7 @@ scmi_power_state_get(const struct scmi_handle *handle, u32 domain, u32 *state)
int ret;
struct scmi_xfer *t;
- ret = scmi_one_xfer_init(handle, POWER_STATE_GET, SCMI_PROTOCOL_POWER,
+ ret = scmi_xfer_get_init(handle, POWER_STATE_GET, SCMI_PROTOCOL_POWER,
sizeof(u32), sizeof(u32), &t);
if (ret)
return ret;
@@ -153,7 +153,7 @@ scmi_power_state_get(const struct scmi_handle *handle, u32 domain, u32 *state)
if (!ret)
*state = le32_to_cpu(*(__le32 *)t->rx.buf);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
diff --git a/drivers/firmware/arm_scmi/sensors.c b/drivers/firmware/arm_scmi/sensors.c
index bbb469fea0ed..27f2092b9882 100644
--- a/drivers/firmware/arm_scmi/sensors.c
+++ b/drivers/firmware/arm_scmi/sensors.c
@@ -79,7 +79,7 @@ static int scmi_sensor_attributes_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_sensor_attributes *attr;
- ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
+ ret = scmi_xfer_get_init(handle, PROTOCOL_ATTRIBUTES,
SCMI_PROTOCOL_SENSOR, 0, sizeof(*attr), &t);
if (ret)
return ret;
@@ -95,7 +95,7 @@ static int scmi_sensor_attributes_get(const struct scmi_handle *handle,
si->reg_size = le32_to_cpu(attr->reg_size);
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -108,7 +108,7 @@ static int scmi_sensor_description_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_resp_sensor_description *buf;
- ret = scmi_one_xfer_init(handle, SENSOR_DESCRIPTION_GET,
+ ret = scmi_xfer_get_init(handle, SENSOR_DESCRIPTION_GET,
SCMI_PROTOCOL_SENSOR, sizeof(__le32), 0, &t);
if (ret)
return ret;
@@ -150,7 +150,7 @@ static int scmi_sensor_description_get(const struct scmi_handle *handle,
*/
} while (num_returned && num_remaining);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -162,7 +162,7 @@ scmi_sensor_configuration_set(const struct scmi_handle *handle, u32 sensor_id)
struct scmi_xfer *t;
struct scmi_msg_set_sensor_config *cfg;
- ret = scmi_one_xfer_init(handle, SENSOR_CONFIG_SET,
+ ret = scmi_xfer_get_init(handle, SENSOR_CONFIG_SET,
SCMI_PROTOCOL_SENSOR, sizeof(*cfg), 0, &t);
if (ret)
return ret;
@@ -173,7 +173,7 @@ scmi_sensor_configuration_set(const struct scmi_handle *handle, u32 sensor_id)
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -185,7 +185,7 @@ static int scmi_sensor_trip_point_set(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_set_sensor_trip_point *trip;
- ret = scmi_one_xfer_init(handle, SENSOR_TRIP_POINT_SET,
+ ret = scmi_xfer_get_init(handle, SENSOR_TRIP_POINT_SET,
SCMI_PROTOCOL_SENSOR, sizeof(*trip), 0, &t);
if (ret)
return ret;
@@ -198,7 +198,7 @@ static int scmi_sensor_trip_point_set(const struct scmi_handle *handle,
ret = scmi_do_xfer(handle, t);
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
@@ -209,7 +209,7 @@ static int scmi_sensor_reading_get(const struct scmi_handle *handle,
struct scmi_xfer *t;
struct scmi_msg_sensor_reading_get *sensor;
- ret = scmi_one_xfer_init(handle, SENSOR_READING_GET,
+ ret = scmi_xfer_get_init(handle, SENSOR_READING_GET,
SCMI_PROTOCOL_SENSOR, sizeof(*sensor),
sizeof(u64), &t);
if (ret)
@@ -227,7 +227,7 @@ static int scmi_sensor_reading_get(const struct scmi_handle *handle,
*value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
}
- scmi_one_xfer_put(handle, t);
+ scmi_xfer_put(handle, t);
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/8] firmware: arm_scmi: rename get_transition_latency and add_opps_to_device
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
Most of the scmi code follows the suggestion from Greg KH on a totally
different thread[0] to have the subsystem name first, followed by the
noun and finally the verb with couple of these exceptions.
This patch fixes them so that all the functions names are aligned to
on practice.
[0] https://www.spinics.net/lists/arm-kernel/msg583673.html
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/cpufreq/scmi-cpufreq.c | 4 ++--
drivers/firmware/arm_scmi/perf.c | 10 +++++-----
include/linux/scmi_protocol.h | 10 +++++-----
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index b4dbc77459b6..50b1551ba894 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -117,7 +117,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
return -ENODEV;
}
- ret = handle->perf_ops->add_opps_to_device(handle, cpu_dev);
+ ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
if (ret) {
dev_warn(cpu_dev, "failed to add opps to the device\n");
return ret;
@@ -164,7 +164,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
/* SCMI allows DVFS request for any domain from any CPU */
policy->dvfs_possible_from_any_cpu = true;
- latency = handle->perf_ops->get_transition_latency(handle, cpu_dev);
+ latency = handle->perf_ops->transition_latency_get(handle, cpu_dev);
if (!latency)
latency = CPUFREQ_ETERNAL;
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 987c64d19801..611ab08e6174 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -349,8 +349,8 @@ static int scmi_dev_domain_id(struct device *dev)
return clkspec.args[0];
}
-static int scmi_dvfs_add_opps_to_device(const struct scmi_handle *handle,
- struct device *dev)
+static int scmi_dvfs_device_opps_add(const struct scmi_handle *handle,
+ struct device *dev)
{
int idx, ret, domain;
unsigned long freq;
@@ -383,7 +383,7 @@ static int scmi_dvfs_add_opps_to_device(const struct scmi_handle *handle,
return 0;
}
-static int scmi_dvfs_get_transition_latency(const struct scmi_handle *handle,
+static int scmi_dvfs_transition_latency_get(const struct scmi_handle *handle,
struct device *dev)
{
struct perf_dom_info *dom;
@@ -432,8 +432,8 @@ static struct scmi_perf_ops perf_ops = {
.level_set = scmi_perf_level_set,
.level_get = scmi_perf_level_get,
.device_domain_id = scmi_dev_domain_id,
- .get_transition_latency = scmi_dvfs_get_transition_latency,
- .add_opps_to_device = scmi_dvfs_add_opps_to_device,
+ .transition_latency_get = scmi_dvfs_transition_latency_get,
+ .device_opps_add = scmi_dvfs_device_opps_add,
.freq_set = scmi_dvfs_freq_set,
.freq_get = scmi_dvfs_freq_get,
};
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index a171c1e293e8..f4c9fc0fc755 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -85,8 +85,8 @@ struct scmi_clk_ops {
* @level_set: sets the performance level of a domain
* @level_get: gets the performance level of a domain
* @device_domain_id: gets the scmi domain id for a given device
- * @get_transition_latency: gets the DVFS transition latency for a given device
- * @add_opps_to_device: adds all the OPPs for a given device
+ * @transition_latency_get: gets the DVFS transition latency for a given device
+ * @device_opps_add: adds all the OPPs for a given device
* @freq_set: sets the frequency for a given device using sustained frequency
* to sustained performance level mapping
* @freq_get: gets the frequency for a given device using sustained frequency
@@ -102,10 +102,10 @@ struct scmi_perf_ops {
int (*level_get)(const struct scmi_handle *handle, u32 domain,
u32 *level, bool poll);
int (*device_domain_id)(struct device *dev);
- int (*get_transition_latency)(const struct scmi_handle *handle,
+ int (*transition_latency_get)(const struct scmi_handle *handle,
struct device *dev);
- int (*add_opps_to_device)(const struct scmi_handle *handle,
- struct device *dev);
+ int (*device_opps_add)(const struct scmi_handle *handle,
+ struct device *dev);
int (*freq_set)(const struct scmi_handle *handle, u32 domain,
unsigned long rate, bool poll);
int (*freq_get)(const struct scmi_handle *handle, u32 domain,
--
2.7.4
^ permalink raw reply related
* [PATCH 2/8] firmware: arm_scmi: fix kernel-docs documentation
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
There are few missing descriptions for function parameters and structure
members along with certain instances where excessive function parameters
or structure members are described.
This patch fixes all of those warnings.
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/base.c | 20 +++++++++--------
drivers/firmware/arm_scmi/common.h | 7 ++++--
drivers/firmware/arm_scmi/driver.c | 45 ++++++++++++++++++++------------------
include/linux/scmi_protocol.h | 8 +++++++
4 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index 0d3806c0d432..c36ded9dbb83 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -26,7 +26,7 @@ struct scmi_msg_resp_base_attributes {
* scmi_base_attributes_get() - gets the implementation details
* that are associated with the base protocol.
*
- * @handle - SCMI entity handle
+ * @handle: SCMI entity handle
*
* Return: 0 on success, else appropriate SCMI error.
*/
@@ -50,14 +50,15 @@ static int scmi_base_attributes_get(const struct scmi_handle *handle)
}
scmi_one_xfer_put(handle, t);
+
return ret;
}
/**
* scmi_base_vendor_id_get() - gets vendor/subvendor identifier ASCII string.
*
- * @handle - SCMI entity handle
- * @sub_vendor - specify true if sub-vendor ID is needed
+ * @handle: SCMI entity handle
+ * @sub_vendor: specify true if sub-vendor ID is needed
*
* Return: 0 on success, else appropriate SCMI error.
*/
@@ -97,7 +98,7 @@ scmi_base_vendor_id_get(const struct scmi_handle *handle, bool sub_vendor)
* implementation 32-bit version. The format of the version number is
* vendor-specific
*
- * @handle - SCMI entity handle
+ * @handle: SCMI entity handle
*
* Return: 0 on success, else appropriate SCMI error.
*/
@@ -128,8 +129,8 @@ scmi_base_implementation_version_get(const struct scmi_handle *handle)
* scmi_base_implementation_list_get() - gets the list of protocols it is
* OSPM is allowed to access
*
- * @handle - SCMI entity handle
- * @protocols_imp - pointer to hold the list of protocol identifiers
+ * @handle: SCMI entity handle
+ * @protocols_imp: pointer to hold the list of protocol identifiers
*
* Return: 0 on success, else appropriate SCMI error.
*/
@@ -173,15 +174,16 @@ static int scmi_base_implementation_list_get(const struct scmi_handle *handle,
} while (loop_num_ret);
scmi_one_xfer_put(handle, t);
+
return ret;
}
/**
* scmi_base_discover_agent_get() - discover the name of an agent
*
- * @handle - SCMI entity handle
- * @id - Agent identifier
- * @name - Agent identifier ASCII string
+ * @handle: SCMI entity handle
+ * @id: Agent identifier
+ * @name: Agent identifier ASCII string
*
* An agent id of 0 is reserved to identify the platform itself.
* Generally operating system is represented as "OSPM"
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index e8f332c9c469..0821662a4633 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -51,8 +51,11 @@ struct scmi_msg_resp_prot_version {
* @id: The identifier of the command being sent
* @protocol_id: The identifier of the protocol used to send @id command
* @seq: The token to identify the message. when a message/command returns,
- * the platform returns the whole message header unmodified including
- * the token.
+ * the platform returns the whole message header unmodified including
+ * the token
+ * @status: Status of the transfer once it's complete
+ * @poll_completion: Indicate if the transfer needs to be polled for
+ * completion or interrupt mode is used
*/
struct scmi_msg_hdr {
u8 id;
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 917786d91f55..6fee11f06a66 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -51,7 +51,7 @@ enum scmi_error_codes {
SCMI_ERR_MAX
};
-/* List of all SCMI devices active in system */
+/* List of all SCMI devices active in system */
static LIST_HEAD(scmi_list);
/* Protection for the entire list */
static DEFINE_MUTEX(scmi_list_mutex);
@@ -68,7 +68,6 @@ static DEFINE_MUTEX(scmi_list_mutex);
struct scmi_xfers_info {
struct scmi_xfer *xfer_block;
unsigned long *xfer_alloc_table;
- /* protect transfer allocation */
spinlock_t xfer_lock;
};
@@ -94,6 +93,7 @@ struct scmi_desc {
* @payload: Transmit/Receive mailbox channel payload area
* @dev: Reference to device in the SCMI hierarchy corresponding to this
* channel
+ * @handle: Pointer to SCMI entity handle
*/
struct scmi_chan_info {
struct mbox_client cl;
@@ -104,7 +104,7 @@ struct scmi_chan_info {
};
/**
- * struct scmi_info - Structure representing a SCMI instance
+ * struct scmi_info - Structure representing a SCMI instance
*
* @dev: Device pointer
* @desc: SoC description for this instance
@@ -113,9 +113,9 @@ struct scmi_chan_info {
* implementation version and (sub-)vendor identification.
* @minfo: Message info
* @tx_idr: IDR object to map protocol id to channel info pointer
- * @protocols_imp: list of protocols implemented, currently maximum of
+ * @protocols_imp: List of protocols implemented, currently maximum of
* MAX_PROTOCOLS_IMP elements allocated by the base protocol
- * @node: list head
+ * @node: List head
* @users: Number of users of this instance
*/
struct scmi_info {
@@ -221,9 +221,7 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m)
xfer_id = MSG_XTRACT_TOKEN(ioread32(&mem->msg_header));
- /*
- * Are we even expecting this?
- */
+ /* Are we even expecting this? */
if (!test_bit(xfer_id, minfo->xfer_alloc_table)) {
dev_err(dev, "message for %d is not expected!\n", xfer_id);
return;
@@ -248,6 +246,8 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m)
*
* @hdr: pointer to header containing all the information on message id,
* protocol id and sequence id.
+ *
+ * Return: 32-bit packed command header to be sent to the platform.
*/
static inline u32 pack_scmi_header(struct scmi_msg_hdr *hdr)
{
@@ -282,9 +282,9 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m)
}
/**
- * scmi_one_xfer_get() - Allocate one message
+ * scmi_xfer_get() - Allocate one message
*
- * @handle: SCMI entity handle
+ * @handle: Pointer to SCMI entity handle
*
* Helper function which is used by various command functions that are
* exposed to clients of this driver for allocating a message traffic event.
@@ -326,8 +326,8 @@ static struct scmi_xfer *scmi_one_xfer_get(const struct scmi_handle *handle)
/**
* scmi_one_xfer_put() - Release a message
*
- * @minfo: transfer info pointer
- * @xfer: message that was reserved by scmi_one_xfer_get
+ * @handle: Pointer to SCMI entity handle
+ * @xfer: message that was reserved by scmi_xfer_get
*
* This holds a spinlock to maintain integrity of internal data structures.
*/
@@ -374,12 +374,12 @@ static bool scmi_xfer_done_no_timeout(const struct scmi_chan_info *cinfo,
/**
* scmi_do_xfer() - Do one transfer
*
- * @info: Pointer to SCMI entity information
+ * @handle: Pointer to SCMI entity handle
* @xfer: Transfer to initiate and wait for response
*
* Return: -ETIMEDOUT in case of no response, if transmit error,
- * return corresponding error, else if all goes well,
- * return 0.
+ * return corresponding error, else if all goes well,
+ * return 0.
*/
int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
{
@@ -438,9 +438,9 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
/**
* scmi_one_xfer_init() - Allocate and initialise one message
*
- * @handle: SCMI entity handle
+ * @handle: Pointer to SCMI entity handle
* @msg_id: Message identifier
- * @msg_prot_id: Protocol identifier for the message
+ * @prot_id: Protocol identifier for the message
* @tx_size: transmit message size
* @rx_size: receive message size
* @p: pointer to the allocated and initialised message
@@ -478,13 +478,16 @@ int scmi_one_xfer_init(const struct scmi_handle *handle, u8 msg_id, u8 prot_id,
xfer->hdr.poll_completion = false;
*p = xfer;
+
return 0;
}
/**
* scmi_version_get() - command to get the revision of the SCMI entity
*
- * @handle: Handle to SCMI entity information
+ * @handle: Pointer to SCMI entity handle
+ * @protocol: Protocol identifier for the message
+ * @version: Holds returned version of protocol.
*
* Updates the SCMI information in the internal data structure.
*
@@ -541,7 +544,7 @@ scmi_is_protocol_implemented(const struct scmi_handle *handle, u8 prot_id)
* @dev: pointer to device for which we want SCMI handle
*
* NOTE: The function does not track individual clients of the framework
- * and is expected to be maintained by caller of SCMI protocol library.
+ * and is expected to be maintained by caller of SCMI protocol library.
* scmi_handle_put must be balanced with successful scmi_handle_get
*
* Return: pointer to handle if successful, NULL on error
@@ -572,7 +575,7 @@ struct scmi_handle *scmi_handle_get(struct device *dev)
* @handle: handle acquired by scmi_handle_get
*
* NOTE: The function does not track individual clients of the framework
- * and is expected to be maintained by caller of SCMI protocol library.
+ * and is expected to be maintained by caller of SCMI protocol library.
* scmi_handle_put must be balanced with successful scmi_handle_get
*
* Return: 0 is successfully released
@@ -595,7 +598,7 @@ int scmi_handle_put(const struct scmi_handle *handle)
}
static const struct scmi_desc scmi_generic_desc = {
- .max_rx_timeout_ms = 30, /* we may increase this if required */
+ .max_rx_timeout_ms = 30, /* We may increase this if required */
.max_msg = 20, /* Limited by MBOX_TX_QUEUE_LEN */
.max_msg_size = 128,
};
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index b458c87b866c..a171c1e293e8 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -189,6 +189,14 @@ struct scmi_sensor_ops {
* @perf_ops: pointer to set of performance protocol operations
* @clk_ops: pointer to set of clock protocol operations
* @sensor_ops: pointer to set of sensor protocol operations
+ * @perf_priv: pointer to private data structure specific to performance
+ * protocol(for internal use only)
+ * @clk_priv: pointer to private data structure specific to clock
+ * protocol(for internal use only)
+ * @power_priv: pointer to private data structure specific to power
+ * protocol(for internal use only)
+ * @sensor_priv: pointer to private data structure specific to sensors
+ * protocol(for internal use only)
*/
struct scmi_handle {
struct device *dev;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/8] firmware: arm_scmi: improve code readability using bitfield accessor macros
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-1-git-send-email-sudeep.holla@arm.com>
By using FIELD_{FIT,GET,PREP} and GENMASK macro accessors we can avoid
some clumpsy custom shifting and masking macros and also improve the
code better readability.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/arm_scmi/common.h | 9 +++++----
drivers/firmware/arm_scmi/driver.c | 31 ++++++++++++++-----------------
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 0c30234f9098..e8f332c9c469 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -7,6 +7,7 @@
* Copyright (C) 2018 ARM Ltd.
*/
+#include <linux/bitfield.h>
#include <linux/completion.h>
#include <linux/device.h>
#include <linux/errno.h>
@@ -14,10 +15,10 @@
#include <linux/scmi_protocol.h>
#include <linux/types.h>
-#define PROTOCOL_REV_MINOR_BITS 16
-#define PROTOCOL_REV_MINOR_MASK ((1U << PROTOCOL_REV_MINOR_BITS) - 1)
-#define PROTOCOL_REV_MAJOR(x) ((x) >> PROTOCOL_REV_MINOR_BITS)
-#define PROTOCOL_REV_MINOR(x) ((x) & PROTOCOL_REV_MINOR_MASK)
+#define PROTOCOL_REV_MINOR_MASK GENMASK(15, 0)
+#define PROTOCOL_REV_MAJOR_MASK GENMASK(31, 16)
+#define PROTOCOL_REV_MAJOR(x) (u16)(FIELD_GET(PROTOCOL_REV_MAJOR_MASK, (x)))
+#define PROTOCOL_REV_MINOR(x) (u16)(FIELD_GET(PROTOCOL_REV_MINOR_MASK, (x)))
#define MAX_PROTOCOLS_IMP 16
#define MAX_OPPS 16
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 14b147135a0c..917786d91f55 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -29,16 +29,12 @@
#include "common.h"
-#define MSG_ID_SHIFT 0
-#define MSG_ID_MASK 0xff
-#define MSG_TYPE_SHIFT 8
-#define MSG_TYPE_MASK 0x3
-#define MSG_PROTOCOL_ID_SHIFT 10
-#define MSG_PROTOCOL_ID_MASK 0xff
-#define MSG_TOKEN_ID_SHIFT 18
-#define MSG_TOKEN_ID_MASK 0x3ff
-#define MSG_XTRACT_TOKEN(header) \
- (((header) >> MSG_TOKEN_ID_SHIFT) & MSG_TOKEN_ID_MASK)
+#define MSG_ID_MASK GENMASK(7, 0)
+#define MSG_TYPE_MASK GENMASK(9, 8)
+#define MSG_PROTOCOL_ID_MASK GENMASK(17, 10)
+#define MSG_TOKEN_ID_MASK GENMASK(27, 18)
+#define MSG_XTRACT_TOKEN(hdr) FIELD_GET(MSG_TOKEN_ID_MASK, (hdr))
+#define MSG_TOKEN_MAX (MSG_XTRACT_TOKEN(MSG_TOKEN_ID_MASK) + 1)
enum scmi_error_codes {
SCMI_SUCCESS = 0, /* Success */
@@ -255,9 +251,9 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m)
*/
static inline u32 pack_scmi_header(struct scmi_msg_hdr *hdr)
{
- return ((hdr->id & MSG_ID_MASK) << MSG_ID_SHIFT) |
- ((hdr->seq & MSG_TOKEN_ID_MASK) << MSG_TOKEN_ID_SHIFT) |
- ((hdr->protocol_id & MSG_PROTOCOL_ID_MASK) << MSG_PROTOCOL_ID_SHIFT);
+ return FIELD_PREP(MSG_ID_MASK, hdr->id) |
+ FIELD_PREP(MSG_TOKEN_ID_MASK, hdr->seq) |
+ FIELD_PREP(MSG_PROTOCOL_ID_MASK, hdr->protocol_id);
}
/**
@@ -621,9 +617,9 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
struct scmi_xfers_info *info = &sinfo->minfo;
/* Pre-allocated messages, no more than what hdr.seq can support */
- if (WARN_ON(desc->max_msg >= (MSG_TOKEN_ID_MASK + 1))) {
- dev_err(dev, "Maximum message of %d exceeds supported %d\n",
- desc->max_msg, MSG_TOKEN_ID_MASK + 1);
+ if (WARN_ON(desc->max_msg >= MSG_TOKEN_MAX)) {
+ dev_err(dev, "Maximum message of %d exceeds supported %ld\n",
+ desc->max_msg, MSG_TOKEN_MAX);
return -EINVAL;
}
@@ -840,7 +836,8 @@ static int scmi_probe(struct platform_device *pdev)
if (of_property_read_u32(child, "reg", &prot_id))
continue;
- prot_id &= MSG_PROTOCOL_ID_MASK;
+ if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
+ dev_err(dev, "Out of range protocol %d\n", prot_id);
if (!scmi_is_protocol_implemented(handle, prot_id)) {
dev_err(dev, "SCMI protocol %d not implemented\n",
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] firmware: arm_scmi: trivial cleanups
From: Sudeep Holla @ 2018-05-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This contains all of the trivial review comments that were not addressed
as the series was queued for v4.17 and were not critical.
Regards,
Sudeep
Sudeep Holla (8):
firmware: arm_scmi: improve code readability using bitfield accessor
macros
firmware: arm_scmi: fix kernel-docs documentation
firmware: arm_scmi: rename get_transition_latency and
add_opps_to_device
firmware: arm_scmi: rename scmi_xfer_{init,get,put}
firmware: arm_scmi: drop unused `con_priv` structure member
firmware: arm_scmi: remove unnecessary bitmap_zero
firmware: arm_scmi: improve exit paths and code readability
firmware: arm_scmi: simplify exit path by returning on error
drivers/cpufreq/scmi-cpufreq.c | 4 +-
drivers/firmware/arm_scmi/base.c | 43 +++++++-------
drivers/firmware/arm_scmi/bus.c | 22 ++++----
drivers/firmware/arm_scmi/clock.c | 24 ++++----
drivers/firmware/arm_scmi/common.h | 22 ++++----
drivers/firmware/arm_scmi/driver.c | 109 ++++++++++++++++++------------------
drivers/firmware/arm_scmi/perf.c | 38 ++++++-------
drivers/firmware/arm_scmi/power.c | 16 +++---
drivers/firmware/arm_scmi/sensors.c | 20 +++----
include/linux/scmi_protocol.h | 18 ++++--
10 files changed, 166 insertions(+), 150 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Dave Martin @ 2018-05-09 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b53227b8-8532-a395-184d-dc2b3654f607@arm.com>
On Wed, May 09, 2018 at 05:54:25PM +0100, Marc Zyngier wrote:
> On 09/05/18 17:12, Dave Martin wrote:
> > This patch refactors KVM to align the host and guest FPSIMD
> > save/restore logic with each other for arm64. This reduces the
> > number of redundant save/restore operations that must occur, and
> > reduces the common-case IRQ blackout time during guest exit storms
> > by saving the host state lazily and optimising away the need to
> > restore the host state before returning to the run loop.
> >
> > Four hooks are defined in order to enable this:
> >
> > * kvm_arch_vcpu_run_map_fp():
> > Called on PID change to map necessary bits of current to Hyp.
> >
> > * kvm_arch_vcpu_load_fp():
> > Set up FP/SIMD for entering the KVM run loop (parse as
> > "vcpu_load fp").
> >
> > * kvm_arch_vcpu_ctxsync_fp():
> > Get FP/SIMD into a safe state for re-enabling interrupts after a
> > guest exit back to the run loop.
> >
> > For arm64 specifically, this involves updating the host kernel's
> > FPSIMD context tracking metadata so that kernel-mode NEON use
> > will cause the vcpu's FPSIMD state to be saved back correctly
> > into the vcpu struct. This must be done before re-enabling
> > interrupts because kernel-mode NEON may be used by softirqs.
> >
> > * kvm_arch_vcpu_put_fp():
> > Save guest FP/SIMD state back to memory and dissociate from the
> > CPU ("vcpu_put fp").
> >
> > Also, the arm64 FPSIMD context switch code is updated to enable it
> > to save back FPSIMD state for a vcpu, not just current. A few
> > helpers drive this:
> >
> > * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
> > mark this CPU as having context fp (which may belong to a vcpu)
> > currently loaded in its registers. This is the non-task
> > equivalent of the static function fpsimd_bind_to_cpu() in
> > fpsimd.c.
> >
> > * task_fpsimd_save():
> > exported to allow KVM to save the guest's FPSIMD state back to
> > memory on exit from the run loop.
> >
> > * fpsimd_flush_state():
> > invalidate any context's FPSIMD state that is currently loaded.
> > Used to disassociate the vcpu from the CPU regs on run loop exit.
> >
> > These changes allow the run loop to enable interrupts (and thus
> > softirqs that may use kernel-mode NEON) without having to save the
> > guest's FPSIMD state eagerly.
> >
> > Some new vcpu_arch fields are added to make all this work. Because
> > host FPSIMD state can now be saved back directly into current's
> > thread_struct as appropriate, host_cpu_context is no longer used
> > for preserving the FPSIMD state. However, it is still needed for
> > preserving other things such as the host's system registers. To
> > avoid ABI churn, the redundant storage space in host_cpu_context is
> > not removed for now.
> >
> > arch/arm is not addressed by this patch and continues to use its
> > current save/restore logic. It could provide implementations of
> > the helpers later if desired.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> >
> > ---
> >
> > Dropped Reviewed-bys due to non-trivial changes.
> >
> > Changes since v6:
> >
> > * Don't define kvm_arch_vcpu_run_pid_change() unless CONFIG_KVM=y.
> >
> > <asm/kvm_host.h> may be used for its declarations even with
> > CONFIG_KVM=n (e.g., in asm-offsets.c).
> >
> > This patch avoids conflicts with the core headers in this config.
> >
> > * Rebind current's FP state to the cpu in vcpu_put() if it is
> > still loaded, to ensure that the SVE trapping setup for userspace is
> > properly restored.
> >
> > Requested by Marc Zyngier:
> >
> > * Add a comment to explain the purpose of update_fp_enabled().
> >
> > * Migrate vcpu_arch.flags definitions to kvm_host.h.
> >
> > * Eliminate magic NULL semantics for vcpu_arch.host_fpsimd_state so
> > that we can just assign this pointer once in the pid_change hook.
> >
> > A new flag KVM_ARM64_FP_HOST flag is added to capture the former
> > semantics of vcpu->arch.host_fpsimd_state != NULL.
> Thanks for the additional rework, that looks much better now.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Cool, thanks for wrapping your head around it.
Cheers
---Dave
^ permalink raw reply
* [PATCH v7 02/16] arm64: Use update{,_tsk}_thread_flag()
From: Marc Zyngier @ 2018-05-09 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509162753.GP7753@e103592.cambridge.arm.com>
On 09/05/18 17:27, Dave Martin wrote:
> On Wed, May 09, 2018 at 05:17:28PM +0100, Will Deacon wrote:
>> Hi Dave,
>>
>> On Wed, May 09, 2018 at 05:12:51PM +0100, Dave Martin wrote:
>>> This patch uses the new update_thread_flag() helpers to simplify a
>>> couple of if () set; else clear; constructs.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> ---
>>> arch/arm64/kernel/fpsimd.c | 19 +++++++------------
>>> 1 file changed, 7 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>>> index 87a3536..0c4e7e0 100644
>>> --- a/arch/arm64/kernel/fpsimd.c
>>> +++ b/arch/arm64/kernel/fpsimd.c
>
> [...]
>
>>> @@ -902,7 +900,7 @@ void fpsimd_thread_switch(struct task_struct *next)
>>> if (current->mm)
>>> task_fpsimd_save();
>>>
>>> - if (next->mm) {
>>> + if (next->mm)
>>> /*
>>> * If we are switching to a task whose most recent userland
>>> * FPSIMD state is already in the registers of *this* cpu,
>>> @@ -910,13 +908,10 @@ void fpsimd_thread_switch(struct task_struct *next)
>>> * the TIF_FOREIGN_FPSTATE flag so the state will be loaded
>>> * upon the next return to userland.
>>> */
>>> - if (__this_cpu_read(fpsimd_last_state.st) ==
>>> - &next->thread.uw.fpsimd_state
>>> - && next->thread.fpsimd_cpu == smp_processor_id())
>>> - clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
>>> - else
>>> - set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
>>> - }
>>> + update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
>>> + __this_cpu_read(fpsimd_last_state.st) !=
>>> + &next->thread.uw.fpsimd_state ||
>>> + next->thread.fpsimd_cpu != smp_processor_id());
>>
>> Given the multi-line comment and this multi-line call, I'd be inclined to
>> leave the curlies in place and then use a local bool for the complex
>> condition.
>
> Hey, curlies cost money, you know.
>
>> With that:
>>
>> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Are you content to see this merged without the change? It doesn't seem
> worth a respin of the whole series just for this. I agree the code
> would be clearer, but this patch doesn't actually make it worse IMHO.
>
> If I respin for some reason though, I can address this and add your Ack.
I'm happy to perform the change myself when applying the series if there
is no additional comment that would lead to a respin.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Marc Zyngier @ 2018-05-09 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-9-git-send-email-Dave.Martin@arm.com>
On 09/05/18 17:12, Dave Martin wrote:
> This patch refactors KVM to align the host and guest FPSIMD
> save/restore logic with each other for arm64. This reduces the
> number of redundant save/restore operations that must occur, and
> reduces the common-case IRQ blackout time during guest exit storms
> by saving the host state lazily and optimising away the need to
> restore the host state before returning to the run loop.
>
> Four hooks are defined in order to enable this:
>
> * kvm_arch_vcpu_run_map_fp():
> Called on PID change to map necessary bits of current to Hyp.
>
> * kvm_arch_vcpu_load_fp():
> Set up FP/SIMD for entering the KVM run loop (parse as
> "vcpu_load fp").
>
> * kvm_arch_vcpu_ctxsync_fp():
> Get FP/SIMD into a safe state for re-enabling interrupts after a
> guest exit back to the run loop.
>
> For arm64 specifically, this involves updating the host kernel's
> FPSIMD context tracking metadata so that kernel-mode NEON use
> will cause the vcpu's FPSIMD state to be saved back correctly
> into the vcpu struct. This must be done before re-enabling
> interrupts because kernel-mode NEON may be used by softirqs.
>
> * kvm_arch_vcpu_put_fp():
> Save guest FP/SIMD state back to memory and dissociate from the
> CPU ("vcpu_put fp").
>
> Also, the arm64 FPSIMD context switch code is updated to enable it
> to save back FPSIMD state for a vcpu, not just current. A few
> helpers drive this:
>
> * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
> mark this CPU as having context fp (which may belong to a vcpu)
> currently loaded in its registers. This is the non-task
> equivalent of the static function fpsimd_bind_to_cpu() in
> fpsimd.c.
>
> * task_fpsimd_save():
> exported to allow KVM to save the guest's FPSIMD state back to
> memory on exit from the run loop.
>
> * fpsimd_flush_state():
> invalidate any context's FPSIMD state that is currently loaded.
> Used to disassociate the vcpu from the CPU regs on run loop exit.
>
> These changes allow the run loop to enable interrupts (and thus
> softirqs that may use kernel-mode NEON) without having to save the
> guest's FPSIMD state eagerly.
>
> Some new vcpu_arch fields are added to make all this work. Because
> host FPSIMD state can now be saved back directly into current's
> thread_struct as appropriate, host_cpu_context is no longer used
> for preserving the FPSIMD state. However, it is still needed for
> preserving other things such as the host's system registers. To
> avoid ABI churn, the redundant storage space in host_cpu_context is
> not removed for now.
>
> arch/arm is not addressed by this patch and continues to use its
> current save/restore logic. It could provide implementations of
> the helpers later if desired.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>
> ---
>
> Dropped Reviewed-bys due to non-trivial changes.
>
> Changes since v6:
>
> * Don't define kvm_arch_vcpu_run_pid_change() unless CONFIG_KVM=y.
>
> <asm/kvm_host.h> may be used for its declarations even with
> CONFIG_KVM=n (e.g., in asm-offsets.c).
>
> This patch avoids conflicts with the core headers in this config.
>
> * Rebind current's FP state to the cpu in vcpu_put() if it is
> still loaded, to ensure that the SVE trapping setup for userspace is
> properly restored.
>
> Requested by Marc Zyngier:
>
> * Add a comment to explain the purpose of update_fp_enabled().
>
> * Migrate vcpu_arch.flags definitions to kvm_host.h.
>
> * Eliminate magic NULL semantics for vcpu_arch.host_fpsimd_state so
> that we can just assign this pointer once in the pid_change hook.
>
> A new flag KVM_ARM64_FP_HOST flag is added to capture the former
> semantics of vcpu->arch.host_fpsimd_state != NULL.
Thanks for the additional rework, that looks much better now.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Replace '_' with '-' in node names
From: Sudeep Holla @ 2018-05-09 16:48 UTC (permalink / raw)
To: linux-arm-kernel
The latest DTC throws warnings for character '_' in the node names.
Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
The general recommendation is to use character '-' for all the node names.
This patch fixes the warnings following the recommendation.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 7b8ff5b3b912..58e73131ecef 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -77,19 +77,19 @@
compatible = "arm,vexpress-sysreg";
reg = <0x010000 0x1000>;
- v2m_led_gpios: sys_led {
+ v2m_led_gpios: sys-led {
compatible = "arm,vexpress-sysreg,sys_led";
gpio-controller;
#gpio-cells = <2>;
};
- v2m_mmc_gpios: sys_mci {
+ v2m_mmc_gpios: sys-mci {
compatible = "arm,vexpress-sysreg,sys_mci";
gpio-controller;
#gpio-cells = <2>;
};
- v2m_flash_gpios: sys_flash {
+ v2m_flash_gpios: sys-flash {
compatible = "arm,vexpress-sysreg,sys_flash";
gpio-controller;
#gpio-cells = <2>;
--
2.7.4
^ permalink raw reply related
* [PATCH v7 06/16] arm64/sve: Refactor user SVE trap maintenance for external use
From: Marc Zyngier @ 2018-05-09 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509164125.GQ7753@e103592.cambridge.arm.com>
On 09/05/18 17:41, Dave Martin wrote:
> On Wed, May 09, 2018 at 05:36:30PM +0100, Marc Zyngier wrote:
>> On 09/05/18 17:12, Dave Martin wrote:
>>> In preparation for optimising the way KVM manages switching the
>>> guest and host FPSIMD state, it is necessary to provide a means for
>>> code outside arch/arm64/kernel/fpsimd.c to restore the user trap
>>> configuration for SVE correctly for the current task.
>>>
>>> Rather than requiring external code to duplicate the maintenance
>>> explicitly, this patch wraps moves the trap maintenenace to
>>> fpsimd_bind_to_cpu(), since it is logically part of the work of
>>> associating the current task with the cpu.
>>>
>>> Because fpsimd_bind_to_cpu() is rather a cryptic name to publish
>>> alongside fpsimd_bind_state_to_cpu(), the former function is
>>> renamed to fpsimd_bind_task_to_cpu() to make its purpose more
>>> explicit.
>>>
>>> This patch makes appropriate changes to ensure that
>>> fpsimd_bind_task_to_cpu() is always called alongside
>>> task_fpsimd_load(), so that the trap maintenance continues to be
>>> done in every situation where it was done prior to this patch.
>>>
>>> As a side-effect, the metadata updates done by
>>> fpsimd_bind_task_to_cpu() now change from conditional to
>>> unconditional in the "already bound" case of sigreturn. This is
>>> harmless, and a couple of extra stores on this slow path will not
>>> impact performance. I consider this a reasonable price to pay for
>>> a slightly cleaner interface.
>>>
>>> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>>> ---
>>> arch/arm64/kernel/fpsimd.c | 28 ++++++++++++++--------------
>>> 1 file changed, 14 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>
> [...]
>
>>> @@ -1006,6 +996,16 @@ static void fpsimd_bind_to_cpu(void)
>>> last->st = ¤t->thread.uw.fpsimd_state;
>>> last->sve_in_use = test_thread_flag(TIF_SVE);
>>> current->thread.fpsimd_cpu = smp_processor_id();
>>> +
>>> + if (system_supports_sve()) {
>>
>> Is it worth moving the last->sve_in_use assignment here? If the system
>> doesn't have SVE, the assignment is always 0, and we probably don't need
>> to do it at all. It could avoid the double call to test_thread_flag.
>
> Could do now that you point it out ... but patch 13 gets rid of it
> entirely anyway. This is (was) part of the (now legacy) mechanism for
> working round KVM's inability to lazily save the host SVE state.
>
> If I respin I could tweak it here, but it would be purely cosmetic from
> the whole-series point of view.
Nah, don't even bother.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 3/3] arm64: dts: juno/rtsm: re-structure motherboard includes
From: Sudeep Holla @ 2018-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-1-git-send-email-sudeep.holla@arm.com>
It is a bit unorthodox to just include a file in the middle of a another
DTS file, it breaks the pattern from other device trees and also makes
it really hard to reference things across the files with phandles.
Restructure the include for the Juno/RTSM motherboards to happen at the
top of the file, reference the target nodes directly, and indent the
motherboard .dtsi files to reflect their actual depth in the hierarchy.
This is a purely syntactic change that result in the same DTB files from
the DTS/DTSI files. This is based on similar patch from Linus Walleij
for ARM Vexpress platforms.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 3 +--
arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 4 ++++
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 4 ++--
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 5 ++++-
4 files changed, 11 insertions(+), 5 deletions(-)
Hi,
Posting this patch with -b(aka ignore-spaces option for review purpose.
Regards,
Sudeep
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index b74e462c6658..ce56a4acda4f 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include "juno-clocks.dtsi"
+#include "juno-motherboard.dtsi"
/ {
/*
@@ -795,8 +796,6 @@
<0 0 10 &gic 0 0 0 167 IRQ_TYPE_LEVEL_HIGH>,
<0 0 11 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>,
<0 0 12 &gic 0 0 0 169 IRQ_TYPE_LEVEL_HIGH>;
-
- /include/ "juno-motherboard.dtsi"
};
site2: tlx at 60000000 {
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index 70e3409d86a3..1792b074e9a3 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -7,6 +7,8 @@
*
*/
+/ {
+ smb at 8000000 {
mb_clk24mhz: clk24mhz {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -287,3 +289,5 @@
};
};
};
+ };
+};
diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
index 06c8117e812a..602f63f72c37 100644
--- a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
+++ b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
@@ -12,6 +12,8 @@
/memreserve/ 0x80000000 0x00010000;
+#include "rtsm_ve-motherboard.dtsi"
+
/ {
model = "RTSM_VE_AEMv8A";
compatible = "arm,rtsm_ve,aemv8a", "arm,vexpress";
@@ -162,7 +164,5 @@
<0 0 40 &gic 0 40 4>,
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
-
- /include/ "rtsm_ve-motherboard.dtsi"
};
};
diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
index 1134e5d8df18..d2dbc3f39263 100644
--- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
@@ -7,7 +7,8 @@
*
* VEMotherBoard.lisa
*/
-
+/ {
+ smb at 8000000 {
motherboard {
arm,v2m-memory-map = "rs1";
compatible = "arm,vexpress,v2m-p1", "simple-bus";
@@ -274,3 +275,5 @@
};
};
};
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: juno: replace '_' with '-' in node names
From: Sudeep Holla @ 2018-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-1-git-send-email-sudeep.holla@arm.com>
The latest DTC throws warnings for character '_' in the node names.
Warning (node_name_chars_strict): /thermal-zones/big_cluster: Character '_' not recommended in node name
Warning (node_name_chars_strict): /thermal-zones/little_cluster: Character '_' not recommended in node name
Warning (node_name_chars_strict): /smb at 8000000/motherboard/gpio_keys: Character '_' not recommended in node name
Warning (node_name_chars_strict): /pmu_a57: Character '_' not recommended in node name
Warning (node_name_chars_strict): /pmu_a53: Character '_' not recommended in node name
The general recommendation is to use character '-' for all the node names.
This patch fixes the warnings following the recommendation.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ++--
arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 2 +-
arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++--
arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++--
arch/arm64/boot/dts/arm/juno.dts | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index b2fedaab3fcc..b74e462c6658 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -572,14 +572,14 @@
thermal-sensors = <&scpi_sensors0 3>;
};
- big_cluster_thermal_zone: big_cluster {
+ big_cluster_thermal_zone: big-cluster {
polling-delay = <1000>;
polling-delay-passive = <100>;
thermal-sensors = <&scpi_sensors0 21>;
status = "disabled";
};
- little_cluster_thermal_zone: little_cluster {
+ little_cluster_thermal_zone: little-cluster {
polling-delay = <1000>;
polling-delay-passive = <100>;
thermal-sensors = <&scpi_sensors0 22>;
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index 4b38195a8bea..70e3409d86a3 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -54,7 +54,7 @@
regulator-always-on;
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
power-button {
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index c52c5c40dede..2c5db03f226c 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -201,7 +201,7 @@
};
};
- pmu_a57 {
+ pmu-a57 {
compatible = "arm,cortex-a57-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
@@ -209,7 +209,7 @@
<&A57_1>;
};
- pmu_a53 {
+ pmu-a53 {
compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index a90982ceda35..c51950f4a1b6 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -201,7 +201,7 @@
};
};
- pmu_a72 {
+ pmu-a72 {
compatible = "arm,cortex-a72-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
@@ -209,7 +209,7 @@
<&A72_1>;
};
- pmu_a53 {
+ pmu-a53 {
compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index c9236c4b967d..2b2bf39c30ef 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -200,7 +200,7 @@
};
};
- pmu_a57 {
+ pmu-a57 {
compatible = "arm,cortex-a57-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
@@ -208,7 +208,7 @@
<&A57_1>;
};
- pmu_a53 {
+ pmu-a53 {
compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: juno: Fix "debounce-interval" property misspelling
From: Sudeep Holla @ 2018-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
"debounce_interval" was never supported in the bindings. It should be
"debounce-interval". Moreover, latest DTC complains the following:
Warning (property_name_chars_strict): debounce_interval: Character '_' not recommended in property name
This patch fixes the above warning by using the correct property as
per the bindings.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index 69804c5f1197..4b38195a8bea 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -58,42 +58,42 @@
compatible = "gpio-keys";
power-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <116>;
label = "POWER";
gpios = <&iofpga_gpio0 0 0x4>;
};
home-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <102>;
label = "HOME";
gpios = <&iofpga_gpio0 1 0x4>;
};
rlock-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <152>;
label = "RLOCK";
gpios = <&iofpga_gpio0 2 0x4>;
};
vol-up-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <115>;
label = "VOL+";
gpios = <&iofpga_gpio0 3 0x4>;
};
vol-down-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <114>;
label = "VOL-";
gpios = <&iofpga_gpio0 4 0x4>;
};
nmi-button {
- debounce_interval = <50>;
+ debounce-interval = <50>;
wakeup-source;
linux,code = <99>;
label = "NMI";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: Restructure Vexpress motherboard includes
From: Sudeep Holla @ 2018-05-09 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180427185404.19205-1-linus.walleij@linaro.org>
On 27/04/18 19:54, Linus Walleij wrote:
> It is a bit unorthodox to just include a file in the middle
> of a another DTS file, it breaks the pattern from other device
> trees and also makes it really hard to reference things
> across the files with phandles.
>
> Restructure the include for the Versatile Express motherboards
> to happen at the top of the file, reference the target nodes
> directly, and indent the motherboard .dtsi files to reflect
> their actual depth in the hiearchy.
>
> This is a purely syntactic change that result in the same
> DTB files from the DTS/DTSI files.
>
Please copy me and Lorenzo also in future.
Applied now(with typo in hierarchy fixed), thanks.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v7 06/16] arm64/sve: Refactor user SVE trap maintenance for external use
From: Dave Martin @ 2018-05-09 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dad74a47-26f4-d38f-a9c4-e60fc9d1a07a@arm.com>
On Wed, May 09, 2018 at 05:36:30PM +0100, Marc Zyngier wrote:
> On 09/05/18 17:12, Dave Martin wrote:
> > In preparation for optimising the way KVM manages switching the
> > guest and host FPSIMD state, it is necessary to provide a means for
> > code outside arch/arm64/kernel/fpsimd.c to restore the user trap
> > configuration for SVE correctly for the current task.
> >
> > Rather than requiring external code to duplicate the maintenance
> > explicitly, this patch wraps moves the trap maintenenace to
> > fpsimd_bind_to_cpu(), since it is logically part of the work of
> > associating the current task with the cpu.
> >
> > Because fpsimd_bind_to_cpu() is rather a cryptic name to publish
> > alongside fpsimd_bind_state_to_cpu(), the former function is
> > renamed to fpsimd_bind_task_to_cpu() to make its purpose more
> > explicit.
> >
> > This patch makes appropriate changes to ensure that
> > fpsimd_bind_task_to_cpu() is always called alongside
> > task_fpsimd_load(), so that the trap maintenance continues to be
> > done in every situation where it was done prior to this patch.
> >
> > As a side-effect, the metadata updates done by
> > fpsimd_bind_task_to_cpu() now change from conditional to
> > unconditional in the "already bound" case of sigreturn. This is
> > harmless, and a couple of extra stores on this slow path will not
> > impact performance. I consider this a reasonable price to pay for
> > a slightly cleaner interface.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > ---
> > arch/arm64/kernel/fpsimd.c | 28 ++++++++++++++--------------
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
[...]
> > @@ -1006,6 +996,16 @@ static void fpsimd_bind_to_cpu(void)
> > last->st = ¤t->thread.uw.fpsimd_state;
> > last->sve_in_use = test_thread_flag(TIF_SVE);
> > current->thread.fpsimd_cpu = smp_processor_id();
> > +
> > + if (system_supports_sve()) {
>
> Is it worth moving the last->sve_in_use assignment here? If the system
> doesn't have SVE, the assignment is always 0, and we probably don't need
> to do it at all. It could avoid the double call to test_thread_flag.
Could do now that you point it out ... but patch 13 gets rid of it
entirely anyway. This is (was) part of the (now legacy) mechanism for
working round KVM's inability to lazily save the host SVE state.
If I respin I could tweak it here, but it would be purely cosmetic from
the whole-series point of view.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v7 06/16] arm64/sve: Refactor user SVE trap maintenance for external use
From: Marc Zyngier @ 2018-05-09 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-7-git-send-email-Dave.Martin@arm.com>
On 09/05/18 17:12, Dave Martin wrote:
> In preparation for optimising the way KVM manages switching the
> guest and host FPSIMD state, it is necessary to provide a means for
> code outside arch/arm64/kernel/fpsimd.c to restore the user trap
> configuration for SVE correctly for the current task.
>
> Rather than requiring external code to duplicate the maintenance
> explicitly, this patch wraps moves the trap maintenenace to
> fpsimd_bind_to_cpu(), since it is logically part of the work of
> associating the current task with the cpu.
>
> Because fpsimd_bind_to_cpu() is rather a cryptic name to publish
> alongside fpsimd_bind_state_to_cpu(), the former function is
> renamed to fpsimd_bind_task_to_cpu() to make its purpose more
> explicit.
>
> This patch makes appropriate changes to ensure that
> fpsimd_bind_task_to_cpu() is always called alongside
> task_fpsimd_load(), so that the trap maintenance continues to be
> done in every situation where it was done prior to this patch.
>
> As a side-effect, the metadata updates done by
> fpsimd_bind_task_to_cpu() now change from conditional to
> unconditional in the "already bound" case of sigreturn. This is
> harmless, and a couple of extra stores on this slow path will not
> impact performance. I consider this a reasonable price to pay for
> a slightly cleaner interface.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/kernel/fpsimd.c | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 5fc0595..60404eb 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -257,16 +257,6 @@ static void task_fpsimd_load(void)
> sve_vq_from_vl(current->thread.sve_vl) - 1);
> else
> fpsimd_load_state(¤t->thread.uw.fpsimd_state);
> -
> - if (system_supports_sve()) {
> - /* Toggle SVE trapping for userspace if needed */
> - if (test_thread_flag(TIF_SVE))
> - sve_user_enable();
> - else
> - sve_user_disable();
> -
> - /* Serialised by exception return to user */
> - }
> }
>
> /*
> @@ -998,7 +988,7 @@ void fpsimd_signal_preserve_current_state(void)
> * Associate current's FPSIMD context with this cpu
> * Preemption must be disabled when calling this function.
> */
> -static void fpsimd_bind_to_cpu(void)
> +static void fpsimd_bind_task_to_cpu(void)
> {
> struct fpsimd_last_state_struct *last =
> this_cpu_ptr(&fpsimd_last_state);
> @@ -1006,6 +996,16 @@ static void fpsimd_bind_to_cpu(void)
> last->st = ¤t->thread.uw.fpsimd_state;
> last->sve_in_use = test_thread_flag(TIF_SVE);
> current->thread.fpsimd_cpu = smp_processor_id();
> +
> + if (system_supports_sve()) {
Is it worth moving the last->sve_in_use assignment here? If the system
doesn't have SVE, the assignment is always 0, and we probably don't need
to do it at all. It could avoid the double call to test_thread_flag.
> + /* Toggle SVE trapping for userspace if needed */
> + if (test_thread_flag(TIF_SVE))
> + sve_user_enable();
> + else
> + sve_user_disable();
> +
> + /* Serialised by exception return to user */
> + }
> }
>
> /*
> @@ -1022,7 +1022,7 @@ void fpsimd_restore_current_state(void)
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> task_fpsimd_load();
> - fpsimd_bind_to_cpu();
> + fpsimd_bind_task_to_cpu();
> }
>
> local_bh_enable();
> @@ -1045,9 +1045,9 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
> fpsimd_to_sve(current);
>
> task_fpsimd_load();
> + fpsimd_bind_task_to_cpu();
>
> - if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE))
> - fpsimd_bind_to_cpu();
> + clear_thread_flag(TIF_FOREIGN_FPSTATE);
>
> local_bh_enable();
> }
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix OF graph endpoint node names
From: Sudeep Holla @ 2018-05-09 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508150952.24562-1-robh@kernel.org>
On 08/05/18 16:09, Rob Herring wrote:
> OF graph endpoint node names should be 'endpoint'. Fix the following
> warnings found by dtc:
>
> Warning (graph_endpoint): /hdlcd at 7ff50000/port/hdlcd1-endpoint: graph endpont node nameshould be 'endpoint'
> Warning (graph_endpoint): /hdlcd at 7ff60000/port/hdlcd0-endpoint: graph endpont node nameshould be 'endpoint'
> Warning (graph_endpoint): /i2c at 7ffa0000/hdmi-transmitter at 70/port/tda998x-0-endpoint: graph endpont node name should be 'endpoint'
> Warning (graph_endpoint): /i2c at 7ffa0000/hdmi-transmitter at 71/port/tda998x-1-endpoint: graph endpont node name should be 'endpoint'
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Thanks Robs, both patches applied.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v7 02/16] arm64: Use update{,_tsk}_thread_flag()
From: Dave Martin @ 2018-05-09 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509161728.GC26671@arm.com>
On Wed, May 09, 2018 at 05:17:28PM +0100, Will Deacon wrote:
> Hi Dave,
>
> On Wed, May 09, 2018 at 05:12:51PM +0100, Dave Martin wrote:
> > This patch uses the new update_thread_flag() helpers to simplify a
> > couple of if () set; else clear; constructs.
> >
> > No functional change.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/kernel/fpsimd.c | 19 +++++++------------
> > 1 file changed, 7 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > index 87a3536..0c4e7e0 100644
> > --- a/arch/arm64/kernel/fpsimd.c
> > +++ b/arch/arm64/kernel/fpsimd.c
[...]
> > @@ -902,7 +900,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> > if (current->mm)
> > task_fpsimd_save();
> >
> > - if (next->mm) {
> > + if (next->mm)
> > /*
> > * If we are switching to a task whose most recent userland
> > * FPSIMD state is already in the registers of *this* cpu,
> > @@ -910,13 +908,10 @@ void fpsimd_thread_switch(struct task_struct *next)
> > * the TIF_FOREIGN_FPSTATE flag so the state will be loaded
> > * upon the next return to userland.
> > */
> > - if (__this_cpu_read(fpsimd_last_state.st) ==
> > - &next->thread.uw.fpsimd_state
> > - && next->thread.fpsimd_cpu == smp_processor_id())
> > - clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> > - else
> > - set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> > - }
> > + update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> > + __this_cpu_read(fpsimd_last_state.st) !=
> > + &next->thread.uw.fpsimd_state ||
> > + next->thread.fpsimd_cpu != smp_processor_id());
>
> Given the multi-line comment and this multi-line call, I'd be inclined to
> leave the curlies in place and then use a local bool for the complex
> condition.
Hey, curlies cost money, you know.
> With that:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Are you content to see this merged without the change? It doesn't seem
worth a respin of the whole series just for this. I agree the code
would be clearer, but this patch doesn't actually make it worse IMHO.
If I respin for some reason though, I can address this and add your Ack.
Cheers
---Dave
^ permalink raw reply
* [PATCH v7 02/16] arm64: Use update{,_tsk}_thread_flag()
From: Will Deacon @ 2018-05-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-3-git-send-email-Dave.Martin@arm.com>
Hi Dave,
On Wed, May 09, 2018 at 05:12:51PM +0100, Dave Martin wrote:
> This patch uses the new update_thread_flag() helpers to simplify a
> couple of if () set; else clear; constructs.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/fpsimd.c | 19 +++++++------------
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 87a3536..0c4e7e0 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -618,10 +618,8 @@ int sve_set_vector_length(struct task_struct *task,
> task->thread.sve_vl = vl;
>
> out:
> - if (flags & PR_SVE_VL_INHERIT)
> - set_tsk_thread_flag(task, TIF_SVE_VL_INHERIT);
> - else
> - clear_tsk_thread_flag(task, TIF_SVE_VL_INHERIT);
> + update_tsk_thread_flag(task, TIF_SVE_VL_INHERIT,
> + flags & PR_SVE_VL_INHERIT);
>
> return 0;
> }
> @@ -902,7 +900,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> if (current->mm)
> task_fpsimd_save();
>
> - if (next->mm) {
> + if (next->mm)
> /*
> * If we are switching to a task whose most recent userland
> * FPSIMD state is already in the registers of *this* cpu,
> @@ -910,13 +908,10 @@ void fpsimd_thread_switch(struct task_struct *next)
> * the TIF_FOREIGN_FPSTATE flag so the state will be loaded
> * upon the next return to userland.
> */
> - if (__this_cpu_read(fpsimd_last_state.st) ==
> - &next->thread.uw.fpsimd_state
> - && next->thread.fpsimd_cpu == smp_processor_id())
> - clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> - else
> - set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> - }
> + update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> + __this_cpu_read(fpsimd_last_state.st) !=
> + &next->thread.uw.fpsimd_state ||
> + next->thread.fpsimd_cpu != smp_processor_id());
Given the multi-line comment and this multi-line call, I'd be inclined to
leave the curlies in place and then use a local bool for the complex
condition.
With that:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ 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