Re: [PATCH v3 1/6] remoteproc: Introduce custom dump function for each remoteproc segment
On Fri 27 Jul 08:19 PDT 2018, Sibi Sankar wrote:
> Introduce custom dump function per remoteproc segment. It is responsible
> for filling the device memory segment associated with coredump
>
> Signed-off-by: Sibi Sankar
> ---
> drivers/remoteproc/remoteproc_core.c | 15 ++-
> include/linux/remoteproc.h | 3 +++
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 283b258f5e0f..ec56cd822b26 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1183,13 +1183,18 @@ static void rproc_coredump(struct rproc *rproc)
> phdr->p_align = 0;
>
> ptr = rproc_da_to_va(rproc, segment->da, segment->size);
> - if (!ptr) {
> - dev_err(>dev,
> +
> + if (segment->dump) {
> + segment->dump(rproc, ptr, segment->size, data + offset);
rproc_da_to_va() is an exported symbol, so if you pass segment to the
dump function the driver can, if it needs to, call the function itself.
A typical use case, that I see, is to use the custom dump function to
write out CPU or hardware state to the dump file, in which case the "da"
won't be valid.
So please make this call dump(rproc, segment, data + offset) and move
the rproc_da_to_va() into the else block.
> + } else {
> + if (!ptr) {
> + dev_err(>dev,
> "invalid coredump segment (%pad, %zu)\n",
> >da, segment->size);
> - memset(data + offset, 0xff, segment->size);
> - } else {
> - memcpy(data + offset, ptr, segment->size);
> + memset(data + offset, 0xff, segment->size);
> + } else {
> + memcpy(data + offset, ptr, segment->size);
> + }
> }
>
> offset += phdr->p_filesz;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index e3c5d856b6da..0fbb01a9955c 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -399,6 +399,8 @@ enum rproc_crash_type {
> * @node:list node related to the rproc segment list
> * @da: device address of the segment
> * @size:size of the segment
> + * @dump:custom dump function to fill device memory segment associated
> + * with coredump
> */
> struct rproc_dump_segment {
> struct list_head node;
> @@ -406,6 +408,7 @@ struct rproc_dump_segment {
> dma_addr_t da;
> size_t size;
>
> + void (*dump)(struct rproc *rproc, void *ptr, size_t len, void *priv);
"priv" isn't the best name to represent the memory to which you expect
dump to write to. Please call it "dest".
> loff_t offset;
> };
Regards,
Bjorn
[GIT] Sparc
I've been moving so haven't had access to my Sparc boxes during this time. That's been resolved, and now I can get the patches flowing again. 1) Minor fallthru comment tweaks from Gustavo A. R. Silva. 2) VLA removal from Kees Cook. 3) Make sparc vdso Makefile match x86, from Masahiro Yamada. 4) Fix clock divider programming in mach64 driver, from Mikulas Patocka. Please pull, thanks a lot! The following changes since commit c1d84a1b42ef70d8ae601df9cadedc7ed4f1beb1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-10-06 02:11:30 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git for you to fetch changes up to b7dc10b64f6190a008f05baf697d4d8fa9b8ed51: sparc64: fix fall-through annotation (2018-10-07 22:42:02 -0700) Colin Ian King (1): oradax: remove redundant null check before kfree Gustavo A. R. Silva (2): sparc32: fix fall-through annotation sparc64: fix fall-through annotation Kees Cook (1): sparc64: viohs: Remove VLA usage Masahiro Yamada (1): sparc: vdso: clean-up vdso Makefile Mikulas Patocka (1): mach64: detect the dot clock divider correctly on sparc Rob Herring (2): sparc: Convert to using %pOFn instead of device_node.name sbus: Use of_get_child_by_name helper arch/sparc/kernel/auxio_64.c | 4 ++-- arch/sparc/kernel/kgdb_32.c | 2 +- arch/sparc/kernel/kgdb_64.c | 2 +- arch/sparc/kernel/power.c| 4 ++-- arch/sparc/kernel/prom_32.c | 26 +- arch/sparc/kernel/prom_64.c | 68 ++-- arch/sparc/kernel/viohs.c| 12 +--- arch/sparc/vdso/Makefile | 8 +++- drivers/sbus/char/openprom.c | 11 +-- drivers/sbus/char/oradax.c | 3 +-- drivers/video/fbdev/aty/atyfb.h | 3 ++- drivers/video/fbdev/aty/atyfb_base.c | 7 --- drivers/video/fbdev/aty/mach64_ct.c | 10 +- 13 files changed, 78 insertions(+), 82 deletions(-)
Re: [PATCH v2 2/6] ARM: dts: axp81x: add AC power supply subnode
Hi Oskari,
On Sun, Oct 07, 2018 at 12:18:32AM +0300, Oskari Lemmela wrote:
> Add AC power supply subnode for AXP81X PMIC.
>
> Signed-off-by: Oskari Lemmela
> ---
> arch/arm/boot/dts/axp81x.dtsi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> index 043c717dcef1..67c17151b584 100644
> --- a/arch/arm/boot/dts/axp81x.dtsi
> +++ b/arch/arm/boot/dts/axp81x.dtsi
> @@ -69,6 +69,11 @@
> };
> };
>
> + ac_power_supply: ac-power-supply {
> + compatible = "x-powers,axp813-ac-power-supply";
> + status = "disabled";
> + };
> +
IIRC, when it's a DT node of something that has no address (register or
bus address), we order alphabetically the DT nodes within the same
parent node. So here, we would put it before axp_adc.
Thanks,
Quentin
signature.asc
Description: PGP signature
Re: [PATCH v3 4/6] remoteproc: qcom: q6v5-pil: Add custom dump function for modem
On Fri 27 Jul 08:20 PDT 2018, Sibi Sankar wrote:
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
> b/drivers/remoteproc/qcom_q6v5_pil.c
[..]
> +static void qcom_q6v5_dump_segment(struct rproc *rproc, void *ptr, size_t
> len,
> +void *priv)
> +{
> + int ret = 0;
> + struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
> + static u32 pending_mask;
I dislike that this is a static variable. And it tracks the segments
that has already been dumped, i.e. the !pending.
> +
> + /* Unlock mba before copying segments */
> + if (!qproc->mba_loaded)
> + ret = q6v5_mba_load(qproc);
> +
> + if (!ptr || ret)
> + memset(priv, 0xff, len);
> + else
> + memcpy(priv, ptr, len);
> +
> + pending_mask++;
This is a "count" and not a "mask".
I can see a few different cases where one would like to be able to pass
custom data/information from the segment-registration to the dump
function. So how about adding a "void *priv" to the dump segment.
For this particular case we could typecast segment->priv to an unsigned
long (as this is always the same size) and use that as a bitmask, which
we use to update pending_mask.
> + if (pending_mask == qproc->valid_mask) {
> + if (qproc->mba_loaded)
> + q6v5_mba_reclaim(qproc);
> + pending_mask = 0;
> + }
I think it would be cleaner to reset pending_mask in the start function,
and then return early in this function when we have dumped all the
segments.
If so can pending_mask == 0 and pending_mask == all be the triggers for
loading and reclaiming the mba? So we don't have two different trackers
for this?
> +}
> +
Regards,
Bjorn
Re: [PATCH V3 0/4] Changes for SDCC5 version
On Sun 07 Oct 01:07 PDT 2018, Craig wrote:
> Any updates on this?
>
FWIW I used qcom,sdhci-msm-v5 on QCS404 successfully.
Regards,
Bjorn
> On 25 September 2018 16:39:33 BST, Craig wrote:
> >
> >
> >On 25 September 2018 12:17:26 BST, Veerabhadrarao Badiganti
> > wrote:
> >>
> >>On 9/25/2018 1:18 AM, Craig Tatlor wrote:
> >>> What socs have you tested this on?
> >>> On sdm660 it seems to crash device
> >>> when writing pwr ctl.
> >>
> >>Hi
> >>We have tested this on SDM845.
> >>SDM660 also has SDCC5 controller, so you would need to define
> >>"qcom,sdhci-msm-v5" in your platform dt.
> >>Can you confirm if you have defined this?
> >>
> >Hi,
> >Yes my DT entry is as follows
> >
> >sdhc_1: sdhci@f9824900 {
> >
> >compatible = "qcom,sdhci-msm-v5";
> >
> >reg = <0xc0c4000 0x1000>, <0xc0c5000 0x1000>;
> >
> >interrupts = ;
> >
> >interrupt-names = "pwr_irq";
> >
> >
> >bus-width = <8>;
> >
> >non-removable;
> >
> >
> >vmmc-supply = <_l4>;
> >
> >vqmmc-supply = <_l8>;
> >
> >
> >pinctrl-names = "default";
> >
> >pinctrl-0 = <_clk _cmd _data _rclk>;
> >
> >
> >clocks = < GCC_SDCC1_APPS_CLK>, < GCC_SDCC1_AHB_CLK>;
> >
> >clock-names = "core", "iface";
> >
> >};
> >
> >>BTW, can you please share few details of the platform that you are
> >>checking?
> >>We are not aware of any dev platform based on SDM660. This is just for
> >
> >>my info
> >
> >I'm checking on the sony xperia xa2 (pioneer) smartphone.
> >>
> >>> On Tue, Jun 19, 2018 at 11:09:17AM +0530, Vijay Viswanath wrote:
> With SDCC5, the MCI register space got removed and the offset/order
> >>of
> several registers have changed. Based on SDCC version used and the
> >>register,
> we need to pick the base address and offset.
>
> Depends on patch series: "[PATCH V5 0/2] mmc: sdhci-msm:
> >Configuring
> >>IO_PAD support for sdhci-msm"
>
> Changes since RFC:
> Dropped voltage regulator changes in sdhci-msm
> Split the "Register changes for sdcc V5" patch
> Instead of checking mci removal for deciding which base addr to
> >>use,
> new function pointers are defined for the 2 variants of sdcc:
> 1) MCI present
> 2) V5 (mci removed)
> Instead of string comparing with the compatible string from DT
> >>file,
> the sdhci_msm_probe will now pick the data associated with the
> compatible entry and use it to load variant specific address
> >>offsets
> and msm variant specific read/write ops.
>
> Changes since V1:
> Removed unused msm_reab & msm_writeb APIs
> Changed certain register addresses from uppercase to lowercase hex
> letters
> Removed extra lines and spaces
> Split "[PATCH V1 0/3] Changes for SDCC5 version" patch into two,
> one for Documentation and other for the driver changes.
>
> Changes since V2:
> Used lower case for macro function defenitions
> Removed unused function pointers for msm_readb & msm_writeb
>
>
> Sayali Lokhande (3):
> mmc: sdhci-msm: Define new Register address map
> Documentation: sdhci-msm: Add new compatible string for SDCC v5
> mmc: host: Register changes for sdcc V5
>
> Vijay Viswanath (1):
> mmc: sdhci-msm: Add msm version specific ops and data structures
>
> .../devicetree/bindings/mmc/sdhci-msm.txt | 7 +-
> drivers/mmc/host/sdhci-msm.c | 511
> >>-
> 2 files changed, 391 insertions(+), 127 deletions(-)
>
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation
> >>Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >a
> >>Linux Foundation Collaborative Project.
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> >>linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >>Thanks,
> >>Veera
>
> --
> Sent from my
RE: [PATCH V3] cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull
Hi, Viresh
Anson Huang
Best Regards!
> -Original Message-
> From: Viresh Kumar
> Sent: Monday, October 8, 2018 2:04 PM
> To: Anson Huang
> Cc: r...@rjwysocki.net; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx
> Subject: Re: [PATCH V3] cpufreq: imx6q: read OCOTP through nvmem for
> imx6ul/imx6ull
>
> On 08-10-18, 09:10, Anson Huang wrote:
> > On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because the
> > ocotp clock needs to be enabled first. Add support for reading OCOTP
> > through the nvmem API, and keep the old method there to support old
> > dtb.
> >
> > Signed-off-by: Anson Huang
> > ---
> > changes since V2:
> > Add put node when reading ocotp register done.
> > drivers/cpufreq/imx6q-cpufreq.c | 53
> > -
> > 1 file changed, 36 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/cpufreq/imx6q-cpufreq.c
> > b/drivers/cpufreq/imx6q-cpufreq.c index b2ff423..38b67f8 100644
> > --- a/drivers/cpufreq/imx6q-cpufreq.c
> > +++ b/drivers/cpufreq/imx6q-cpufreq.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -290,20 +291,33 @@ static void
> imx6q_opp_check_speed_grading(struct device *dev)
> > #define OCOTP_CFG3_6ULL_SPEED_792MHZ 0x2
> > #define OCOTP_CFG3_6ULL_SPEED_900MHZ 0x3
> >
> > -static void imx6ul_opp_check_speed_grading(struct device *dev)
> > +static int imx6ul_opp_check_speed_grading(struct device *dev)
> > {
> > - struct device_node *np;
> > - void __iomem *base;
> > u32 val;
> > + int ret = 0;
> >
> > - np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> > - if (!np)
> > - return;
> > + if (of_find_property(dev->of_node, "nvmem-cells", NULL)) {
> > + ret = nvmem_cell_read_u32(dev, "speed_grade", );
> > + if (ret)
> > + return ret;
> > + } else {
> > + struct device_node *np;
> > + void __iomem *base;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> > + if (!np)
> > + return -ENOENT;
> > +
> > + base = of_iomap(np, 0);
>
> You could have done of_node_put(np); right here and remove the below two
> calls to the same.
Thanks for the suggestion, please help review V4.
Anson.
>
> > + if (!base) {
> > + dev_err(dev, "failed to map ocotp\n");
> > + of_node_put(np);
> > + return -EFAULT;
> > + }
> >
> > - base = of_iomap(np, 0);
> > - if (!base) {
> > - dev_err(dev, "failed to map ocotp\n");
> > - goto put_node;
> > + val = readl_relaxed(base + OCOTP_CFG3);
> > + iounmap(base);
> > + of_node_put(np);
> > }
>
> --
> viresh
[PATCH] RCU: Adjust the comment of function rcu_is_watching
From: Zhouyi Zhou
Because RCU avoids interrupting idle CPUs, rcu_is_watching is used to
test whether or not it is currently legal to run RCU read-side
critical sections on this CPU.
First sentence and last sentence of current comment for rcu_is_watching
have opposite meaning of what is expected.
Signed-off-by: Zhouyi Zhou
---
kernel/rcu/tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0b760c1..adb04ea 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1010,12 +1010,12 @@ void rcu_irq_enter_irqson(void)
}
/**
- * rcu_is_watching - see if RCU thinks that the current CPU is idle
+ * rcu_is_watching - see if RCU thinks that the current CPU is not idle
*
* Return true if RCU is watching the running CPU, which means that this
* CPU can safely enter RCU read-side critical sections. In other words,
- * if the current CPU is in its idle loop and is neither in an interrupt
- * or NMI handler, return true.
+ * if the current CPU is not in its idle loop or is in an interrupt or
+ * NMI handler, return true.
*/
bool notrace rcu_is_watching(void)
{
--
2.1.4
Re: [PATCH v2 0/6] AXP8x3 AC and battery power supply support
Hi Oskari, On Sun, Oct 07, 2018 at 12:18:30AM +0300, Oskari Lemmela wrote: > AXP813 AC power supply support with input current and > voltage limiting support. > > AXP803 AC and battery power supply support. > Great to see a new developer taking interest in those PMICs :) I received the v2 patch series as answers of the v1 patch series, you would want to fix that by sending a separate patch series. Using the name of the cover letter of the patch series and the author, it's usually good enough to find previous versions if we need to, you don't need to send the new patch series as answers of the first patch series. Thanks, Quentin signature.asc Description: PGP signature
Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled
在 2018年10月08日 13:37, Borislav Petkov 写道: > On Mon, Oct 08, 2018 at 11:30:56AM +0800, lijiang wrote: >> Yes. As previously mentioned, the correct patch is this one: > > No, that chunk is not needed and I removed it. But I'd leave it as > an exercise to you to figure out why... or to prove me wrong with a > .config. > > :-) > I used this ".config" to compile kernel in the attachment, and got a compile error. Would you like to have a try? [root@hp-dl385g10-03 linux]# make ARCH=i386 -j32 .. LD vmlinux.o MODPOST vmlinux.o fs/proc/vmcore.o：In function ‘read_from_oldmem’： /home/linux/fs/proc/vmcore.c:127：undefined reference to ‘copy_oldmem_page_encrypted’ make: *** [vmlinux] error 1 Regards, Lianbo i386_config.gz Description: application/gzip
Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm
On 2018/10/08 15:14, Yong-Taek Lee wrote:
>> On 2018/10/08 10:19, Yong-Taek Lee wrote:
>>> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
>>> oom_adj, bool legacy)
>>> struct mm_struct *mm = NULL;
>>> struct task_struct *task;
>>> int err = 0;
>>> + int mm_users = 0;
>>>
>>> task = get_proc_task(file_inode(file));
>>> if (!task)
>>> @@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int
>>> oom_adj, bool legacy)
>>> struct task_struct *p = find_lock_task_mm(task);
>>>
>>> if (p) {
>>> - if (atomic_read(>mm->mm_users) > 1) {
>>> + mm_users = atomic_read(>mm->mm_users);
>>> + if ((mm_users > 1) && (mm_users !=
>>> get_nr_threads(p))) {
>>
>> How can this work (even before this patch)? When clone(CLONE_VM without
>> CLONE_THREAD/CLONE_SIGHAND)
>> is requested, copy_process() calls copy_signal() in order to copy
>> sig->oom_score_adj and
>> sig->oom_score_adj_min before calling copy_mm() in order to increment
>> mm->mm_users, doesn't it?
>> Then, we will get two different "struct signal_struct" with different
>> oom_score_adj/oom_score_adj_min
>> but one "struct mm_struct" shared by two thread groups.
>>
>
> Are you talking about race between __set_oom_adj and copy_process?
> If so, i agree with your opinion. It can not set oom_score_adj properly for
> copied process if __set_oom_adj
> check mm_users before copy_process calls copy_mm after copy_signal. Please
> correct me if i misunderstood anything.
You understand it correctly.
Reversing copy_signal() and copy_mm() is not sufficient either. We need to use
a read/write lock
(read lock for copy_process() and write lock for __set_oom_adj()) in order to
make sure that
the thread created by clone() becomes reachable from for_each_process() path in
__set_oom_adj().
>
>>> mm = p->mm;
>>> atomic_inc(>mm_count);
>>> }
>
[PATCH V4 2/4] rpmsg: glink: Add support to handle signals command
Remote peripherals send signal notifications over glink with commandID 15.
Add support to send and receive the signal command and convert the signals
from NATIVE to TIOCM while receiving and vice versa while sending.
Signed-off-by: Chris Lew
Signed-off-by: Arun Kumar Neelakantam
---
drivers/rpmsg/qcom_glink_native.c | 126 ++
1 file changed, 126 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index e2ce4e6..e90f543 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
+ * Copyright (c) 2018, The Linux Foundation.
* Copyright (c) 2016-2017, Linaro Ltd
*/
@@ -17,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -150,6 +152,8 @@ enum {
* @intent_req_lock: Synchronises multiple intent requests
* @intent_req_result: Result of intent request
* @intent_req_comp: Completion for intent_req signalling
+ * @lsigs: local side signals
+ * @rsigs: remote side signals
*/
struct glink_channel {
struct rpmsg_endpoint ept;
@@ -181,6 +185,10 @@ struct glink_channel {
struct mutex intent_req_lock;
bool intent_req_result;
struct completion intent_req_comp;
+
+ unsigned int lsigs;
+ unsigned int rsigs;
+
};
#define to_glink_channel(_ept) container_of(_ept, struct glink_channel, ept)
@@ -201,9 +209,15 @@ struct glink_channel {
#define RPM_CMD_TX_DATA_CONT 12
#define RPM_CMD_READ_NOTIF 13
#define RPM_CMD_RX_DONE_W_REUSE14
+#define RPM_CMD_SIGNALS15
#define GLINK_FEATURE_INTENTLESS BIT(1)
+#define NATIVE_DTR_SIG BIT(31)
+#define NATIVE_CTS_SIG BIT(30)
+#define NATIVE_CD_SIG BIT(29)
+#define NATIVE_RI_SIG BIT(28)
+
static void qcom_glink_rx_done_work(struct work_struct *work);
static struct glink_channel *qcom_glink_alloc_channel(struct qcom_glink *glink,
@@ -957,6 +971,76 @@ static int qcom_glink_rx_open_ack(struct qcom_glink
*glink, unsigned int lcid)
return 0;
}
+/**
+ * qcom_glink_send_signals() - convert a signal cmd to wire format and
transmit
+ * @glink: The transport to transmit on.
+ * @channel: The glink channel
+ * @sigs: The signals to encode.
+ *
+ * Return: 0 on success or standard Linux error code.
+ */
+static int qcom_glink_send_signals(struct qcom_glink *glink,
+ struct glink_channel *channel,
+ u32 sigs)
+{
+ struct glink_msg msg;
+
+ /* convert signals from TIOCM to NATIVE */
+ sigs &= 0x0fff;
+ if (sigs & TIOCM_DTR)
+ sigs |= NATIVE_DTR_SIG;
+ if (sigs & TIOCM_RTS)
+ sigs |= NATIVE_CTS_SIG;
+ if (sigs & TIOCM_CD)
+ sigs |= NATIVE_CD_SIG;
+ if (sigs & TIOCM_RI)
+ sigs |= NATIVE_RI_SIG;
+
+ msg.cmd = cpu_to_le16(RPM_CMD_SIGNALS);
+ msg.param1 = cpu_to_le16(channel->lcid);
+ msg.param2 = cpu_to_le32(sigs);
+
+ return qcom_glink_tx(glink, , sizeof(msg), NULL, 0, true);
+}
+
+static int qcom_glink_handle_signals(struct qcom_glink *glink,
+unsigned int rcid, unsigned int signals)
+{
+ struct glink_channel *channel;
+ unsigned long flags;
+ u32 old;
+
+ spin_lock_irqsave(>idr_lock, flags);
+ channel = idr_find(>rcids, rcid);
+ spin_unlock_irqrestore(>idr_lock, flags);
+ if (!channel) {
+ dev_err(glink->dev, "signal for non-existing channel\n");
+ return -EINVAL;
+ }
+
+ old = channel->rsigs;
+
+ /* convert signals from NATIVE to TIOCM */
+ if (signals & NATIVE_DTR_SIG)
+ signals |= TIOCM_DSR;
+ if (signals & NATIVE_CTS_SIG)
+ signals |= TIOCM_CTS;
+ if (signals & NATIVE_CD_SIG)
+ signals |= TIOCM_CD;
+ if (signals & NATIVE_RI_SIG)
+ signals |= TIOCM_RI;
+ signals &= 0x0fff;
+
+ channel->rsigs = signals;
+
+ if (channel->ept.sig_cb) {
+ channel->ept.sig_cb(channel->ept.rpdev, channel->ept.priv,
+ old, channel->rsigs);
+ }
+
+ return 0;
+}
+
static irqreturn_t qcom_glink_native_intr(int irq, void *data)
{
struct qcom_glink *glink = data;
@@ -1018,6 +1102,10 @@ static irqreturn_t qcom_glink_native_intr(int irq, void
*data)
qcom_glink_handle_intent_req_ack(glink, param1, param2);
qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
break;
+ case RPM_CMD_SIGNALS:
+ qcom_glink_handle_signals(glink, param1, param2);
+ qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+ break;
default:
[PATCH V4 3/4] rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support
Add TICOMGET and TIOCMSET ioctl support for rpmsg char device nodes
to get/set the low level transport signals.
Signed-off-by: Arun Kumar Neelakantam
---
drivers/rpmsg/rpmsg_char.c | 53 +++---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index a76b963..b136684 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
+ * Copyright (c) 2018, The Linux Foundation.
* Copyright (c) 2016, Linaro Ltd.
* Copyright (c) 2012, Michal Simek
* Copyright (c) 2012, PetaLogix
@@ -19,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -266,15 +268,60 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp,
poll_table *wait)
return mask;
}
+static int rpmsg_eptdev_tiocmset(struct file *fp, unsigned int cmd,
+int __user *arg)
+{
+ struct rpmsg_eptdev *eptdev = fp->private_data;
+ u32 set, clear, val;
+ int ret;
+
+ ret = get_user(val, arg);
+ if (ret)
+ return ret;
+ set = clear = 0;
+ switch (cmd) {
+ case TIOCMBIS:
+ set = val;
+ break;
+ case TIOCMBIC:
+ clear = val;
+ break;
+ case TIOCMSET:
+ set = val;
+ clear = ~val;
+ break;
+ }
+
+ set &= TIOCM_DTR | TIOCM_RTS | TIOCM_CD | TIOCM_RI;
+ clear &= TIOCM_DTR | TIOCM_RTS | TIOCM_CD | TIOCM_RI;
+
+ return rpmsg_set_signals(eptdev->ept, set, clear);
+}
+
static long rpmsg_eptdev_ioctl(struct file *fp, unsigned int cmd,
unsigned long arg)
{
struct rpmsg_eptdev *eptdev = fp->private_data;
+ int ret;
- if (cmd != RPMSG_DESTROY_EPT_IOCTL)
- return -EINVAL;
+ switch (cmd) {
+ case TIOCMGET:
+ ret = rpmsg_get_signals(eptdev->ept);
+ if (ret >= 0)
+ ret = put_user(ret, (int __user *)arg);
+ break;
+ case TIOCMSET:
+ case TIOCMBIS:
+ case TIOCMBIC:
+ ret = rpmsg_eptdev_tiocmset(fp, cmd, (int __user *)arg);
+ break;
+ case RPMSG_DESTROY_EPT_IOCTL:
+ ret = rpmsg_eptdev_destroy(>dev, NULL);
+ default:
+ ret = -EINVAL;
+ }
- return rpmsg_eptdev_destroy(>dev, NULL);
+ return ret;
}
static const struct file_operations rpmsg_eptdev_fops = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V4 1/4] rpmsg: core: Add signal API support
Some transports like Glink support the state notifications between
clients using signals similar to serial protocol signals.
Signed-off-by: Chris Lew
Signed-off-by: Arun Kumar Neelakantam
---
drivers/rpmsg/rpmsg_core.c | 41 +
drivers/rpmsg/rpmsg_internal.h | 5 +
include/linux/rpmsg.h | 26 ++
3 files changed, 72 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 8122807..3d7458a 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -2,6 +2,7 @@
/*
* remote processor messaging bus
*
+ * Copyright (c) 2018, The Linux Foundation.
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
*
@@ -283,6 +284,42 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept,
u32 src, u32 dst,
}
EXPORT_SYMBOL(rpmsg_trysend_offchannel);
+/**
+ * rpmsg_get_signals() - get the signals for this endpoint
+ * @ept: the rpmsg endpoint
+ *
+ * Returns signal bits on success and an appropriate error value on failure.
+ */
+int rpmsg_get_signals(struct rpmsg_endpoint *ept)
+{
+ if (WARN_ON(!ept))
+ return -EINVAL;
+ if (!ept->ops->get_signals)
+ return -EOPNOTSUPP;
+
+ return ept->ops->get_signals(ept);
+}
+EXPORT_SYMBOL(rpmsg_get_signals);
+
+/**
+ * rpmsg_set_signals() - set the remote signals for this endpoint
+ * @ept: the rpmsg endpoint
+ * @set: set mask for signals
+ * @clear: clear mask for signals
+ *
+ * Returns 0 on success and an appropriate error value on failure.
+ */
+int rpmsg_set_signals(struct rpmsg_endpoint *ept, u32 set, u32 clear)
+{
+ if (WARN_ON(!ept))
+ return -EINVAL;
+ if (!ept->ops->set_signals)
+ return -EOPNOTSUPP;
+
+ return ept->ops->set_signals(ept, set, clear);
+}
+EXPORT_SYMBOL(rpmsg_set_signals);
+
/*
* match an rpmsg channel with a channel info struct.
* this is used to make sure we're not creating rpmsg devices for channels
@@ -468,6 +505,10 @@ static int rpmsg_dev_probe(struct device *dev)
rpdev->ept = ept;
rpdev->src = ept->addr;
+
+ if (rpdrv->signals)
+ ept->sig_cb = rpdrv->signals;
+
}
err = rpdrv->probe(rpdev);
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 0d791c3..033656d 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -2,6 +2,7 @@
/*
* remote processor messaging bus internals
*
+ * Copyright (c) 2018, The Linux Foundation.
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
*
@@ -46,6 +47,8 @@ struct rpmsg_device_ops {
* @trysend: see @rpmsg_trysend(), required
* @trysendto: see @rpmsg_trysendto(), optional
* @trysend_offchannel:see @rpmsg_trysend_offchannel(), optional
+ * @get_signals: see @rpmsg_get_signals(), optional
+ * @set_signals: see @rpmsg_set_signals(), optional
*
* Indirection table for the operations that a rpmsg backend should implement.
* In addition to @destroy_ept, the backend must at least implement @send and
@@ -65,6 +68,8 @@ struct rpmsg_endpoint_ops {
void *data, int len);
__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
poll_table *wait);
+ int (*get_signals)(struct rpmsg_endpoint *ept);
+ int (*set_signals)(struct rpmsg_endpoint *ept, u32 set, u32 clear);
};
int rpmsg_register_device(struct rpmsg_device *rpdev);
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 9fe156d..48c8ae3 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -2,6 +2,7 @@
/*
* Remote processor messaging
*
+ * Copyright (c) 2018 The Linux Foundation.
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
* All rights reserved.
@@ -60,6 +61,7 @@ struct rpmsg_device {
};
typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *, u32);
+typedef int (*rpmsg_rx_sig_t)(struct rpmsg_device *, void *, u32, u32);
/**
* struct rpmsg_endpoint - binds a local rpmsg address to its user
@@ -67,6 +69,7 @@ struct rpmsg_device {
* @refcount: when this drops to zero, the ept is deallocated
* @cb: rx callback handler
* @cb_lock: must be taken before accessing/changing @cb
+ * @sig_cb: rx serial signal handler
* @addr: local rpmsg address
* @priv: private data for the driver's use
*
@@ -89,6 +92,7 @@ struct rpmsg_endpoint {
struct kref refcount;
rpmsg_rx_cb_t cb;
struct mutex cb_lock;
+ rpmsg_rx_sig_t sig_cb;
u32 addr;
void *priv;
@@ -102,6 +106,7 @@ struct rpmsg_endpoint {
* @probe: invoked when a matching rpmsg channel (i.e. device) is found
* @remove: invoked when the rpmsg channel is removed
* @callback: invoked when an
[PATCH V4 4/4] rpmsg: char: Add signal callback and POLLPRI support
Register a callback to get the signal notifications from rpmsg and
send POLLPRI mask to indicate the signal change in POLL system call.
Signed-off-by: Arun Kumar Neelakantam
---
drivers/rpmsg/rpmsg_char.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index b136684..8a3cbe9 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -64,6 +64,7 @@ struct rpmsg_ctrldev {
* @queue_lock:synchronization of @queue operations
* @queue: incoming message queue
* @readq: wait object for incoming queue
+ * @sig_pending:state of signal notification
*/
struct rpmsg_eptdev {
struct device dev;
@@ -78,6 +79,8 @@ struct rpmsg_eptdev {
spinlock_t queue_lock;
struct sk_buff_head queue;
wait_queue_head_t readq;
+
+ bool sig_pending;
};
static int rpmsg_eptdev_destroy(struct device *dev, void *data)
@@ -122,6 +125,18 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void
*buf, int len,
return 0;
}
+static int rpmsg_sigs_cb(struct rpmsg_device *rpdev, void *priv,
+u32 old, u32 new)
+{
+ struct rpmsg_eptdev *eptdev = priv;
+
+ eptdev->sig_pending = true;
+
+ /* wake up any blocking processes, waiting for signal notification */
+ wake_up_interruptible(>readq);
+ return 0;
+}
+
static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
{
struct rpmsg_eptdev *eptdev = cdev_to_eptdev(inode->i_cdev);
@@ -138,6 +153,7 @@ static int rpmsg_eptdev_open(struct inode *inode, struct
file *filp)
return -EINVAL;
}
+ ept->sig_cb = rpmsg_sigs_cb;
eptdev->ept = ept;
filp->private_data = eptdev;
@@ -157,6 +173,7 @@ static int rpmsg_eptdev_release(struct inode *inode, struct
file *filp)
eptdev->ept = NULL;
}
mutex_unlock(>ept_lock);
+ eptdev->sig_pending = false;
/* Discard all SKBs */
while (!skb_queue_empty(>queue)) {
@@ -263,6 +280,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp,
poll_table *wait)
if (!skb_queue_empty(>queue))
mask |= EPOLLIN | EPOLLRDNORM;
+ if (eptdev->sig_pending)
+ mask |= POLLPRI;
+
mask |= rpmsg_poll(eptdev->ept, filp, wait);
return mask;
@@ -306,6 +326,7 @@ static long rpmsg_eptdev_ioctl(struct file *fp, unsigned
int cmd,
switch (cmd) {
case TIOCMGET:
+ eptdev->sig_pending = false;
ret = rpmsg_get_signals(eptdev->ept);
if (ret >= 0)
ret = put_user(ret, (int __user *)arg);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V4 0/4] Add TIOCM Signals support for RPMSG char devices
Glink transport support signals to exchange state notification between local and remote side clients. Adding support to send/receive the signal command and notify the clients through callback and POLL notification. Changes since v1: - Split the patches as per functional areas like core, char, glink - Add set, clear mask for TIOCMSET - Merge the char signal callback and POLLPRI patches Changes since v2: - Modify the rpmsg_get_signals function prototype Changes since v3: - Correct the TICOMGET case handling as per new rpmsg_get_signals prototype - Update the rpmsg_get_signals function header Arun Kumar Neelakantam (4): rpmsg: core: Add signal API support rpmsg: glink: Add support to handle signals command rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support rpmsg: char: Add signal callback and POLLPRI support drivers/rpmsg/qcom_glink_native.c | 126 ++ drivers/rpmsg/rpmsg_char.c| 74 +- drivers/rpmsg/rpmsg_core.c| 41 + drivers/rpmsg/rpmsg_internal.h| 5 ++ include/linux/rpmsg.h | 26 5 files changed, 269 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: linux-next: build failure after merge of the irqchip tree
Hi Stephen,
On Mon, 08 Oct 2018 04:06:21 +0100,
Stephen Rothwell wrote:
>
> [1 ]
> Hi Marc,
>
> After merging the irqchip tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/irqchip/irq-madera.c:21:
> include/linux/irqchip/irq-madera.h: In function 'madera_get_irq_mapping':
> include/linux/irqchip/irq-madera.h:99:37: error: 'struct madera' has no
> member named 'irq_data'; did you mean 'irq_dev'?
> return regmap_irq_get_virq(madera->irq_data, irq);
> ^~~~
> irq_dev
> drivers/irqchip/irq-madera.c: In function 'madera_irq_probe':
> drivers/irqchip/irq-madera.c:217:34: error: 'struct madera' has no member
> named 'irq_data'; did you mean 'irq_dev'?
>_irq_chip, >irq_data);
> ^~~~
> irq_dev
> drivers/irqchip/irq-madera.c: In function 'madera_irq_remove':
> drivers/irqchip/irq-madera.c:238:43: error: 'struct madera' has no member
> named 'irq_data'; did you mean 'irq_dev'?
> regmap_del_irq_chip(madera->irq, madera->irq_data);
>^~~~
>irq_dev
>
> Caused by commit
>
> b817ff5c9509 ("irqchip: Add driver for Cirrus Logic Madera codecs")
>
> I have used the irqchip tree from next-20181005 for today.
Thanks for doing that. I've now dropped this commit from irqchip-next.
Richard, I'll let you route this patch to the appropriate tree.
Cheers,
M.
--
Jazz is not dead, it just smell funny.
Re: [PATCH 0/9] Implement wake event support on Tegra186 and later
Quoting Lina Iyer (2018-09-25 10:16:05) > Thanks Linus, for bringing this to my attention. > > Hi Thierry, > > On Tue, Sep 25 2018 at 03:57 -0600, Thierry Reding wrote: > >On Tue, Sep 25, 2018 at 10:48:39AM +0200, Linus Walleij wrote: > >> Hi Thierry, > >> > >> thanks for working on the wakeup business! > >> > >> This patch gets me a bit confused on our different approaches > >> toward wakeups in the kernel, so I included Lina, Marc and Ulf > >> to see if we can get some common understanding. > >> > >> On Fri, Sep 21, 2018 at 12:25 PM Thierry Reding > >> wrote: > >> > >> > The following is a set of patches that allow certain interrupts to be > >> > used as wakeup sources on Tegra186 and later. To implement this, each > >> > of the GPIO controllers' IRQ domain needs to become hierarchical, and > >> > parented to the PMC domain. The PMC domain in turn implements a new > >> > IRQ domain that is a child to the GIC IRQ domain. > >> > > >> > The above ensures that the interrupt chip implementation of the PMC is > >> > called at the correct time. The ->irq_set_type() and ->irq_set_wake() > >> > implementations program the PMC wake registers in a way to enable the > >> > given interrupts as wakeup sources. > >> > > >> > This is based on a suggestion from Thomas Gleixner that resulted from > >> > the following thread: > >> > > >> > https://lkml.org/lkml/2018/9/13/1042 [...] > > > >Yes, there was some good discussion in that thread which helped me come > >up with this solution. I think it's pretty elegant because it allows all > >of this interaction to happen almost automatically via the existing > >infrastructure. I'm not sure the same could be applied to the PDC, > >though, because of the need to manually replay the interrupt. That's not > >something I think can be done with just the simple parent/child > >relationship that we use on Tegra. > > > I wasn't able to use the hierarchy because not all GPIOs and the summary > line are routed to the PDC. But I am exploring options of hierarchy as > well. > From reading this thread (and https://lkml.org/lkml/2018/9/17/756) it looks almost exactly the same. The only difference is that Nvidia Tegra does the replay in hardware whereas Qualcomm SDM845 decided to replay the irq in software. Either way, the gpio controller has two parent domains, one is wakeup capable (PDC or PMC) and the other is not (GIC) and some wakeup capable irqs only go through the PDC/PMC and then to the GIC (e.g. RTC) instead of through gpio first. And it sounds like not all gpios are wakeup capable in both designs. The plan to have the gpio to wakeup capable irq map live in DT for the PMC sounds good too. That way, the wakeup domain alloc function can figure things out and redirect gpios by itself while the gpio controller doesn't need to do anything special besides ask for wakeup to be set and fail if the parent can't support it. Can hierarchical irq domains entirely replace the chained irqchip code in gpiolib? That would be interesting.
[PATCH] platform/x86: touchscreen_dmi: Add info for the Trekstor Primetab T13B tablet
Add touchscreen info for the Trekstor Primetab T13B tablet.
Reviewed-by: Hans de Goede
Signed-off-by: Marian Cepok
---
drivers/platform/x86/touchscreen_dmi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
index cb204f973491..c07954f0efc6 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -381,6 +381,22 @@ static const struct ts_dmi_data
trekstor_primebook_c13_data = {
.properties = trekstor_primebook_c13_props,
};
+static const struct property_entry trekstor_primetab_t13b_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2500),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1900),
+ PROPERTY_ENTRY_STRING("firmware-name",
+ "gsl1680-trekstor-primetab-t13b.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ { }
+};
+
+static const struct ts_dmi_data trekstor_primetab_t13b_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = trekstor_primetab_t13b_props,
+};
+
static const struct property_entry trekstor_surftab_twin_10_1_props[] = {
PROPERTY_ENTRY_U32("touchscreen-size-x", 1900),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
@@ -648,6 +664,14 @@ static const struct dmi_system_id touchscreen_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "Primebook C13"),
},
},
+ {
+ /* Trekstor Primetab T13B */
+ .driver_data = (void *)_primetab_t13b_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TREKSTOR"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Primetab T13B"),
+ },
+ },
{
/* TrekStor SurfTab twin 10.1 ST10432-8 */
.driver_data = (void *)_surftab_twin_10_1_data,
--
2.17.1
[PATCH v11 3/3]: perf record: extend trace writing to multi AIO
Multi AIO trace writing allows caching more kernel data into userspace
memory postponing trace writing for the sake of overall profiling data
thruput increase. It could be seen as kernel data buffer extension into
userspace memory.
With aio-cblocks option value different from 0, current default value,
tool has capability to cache more and more data into user space
along with delegating spill to AIO.
That allows avoiding suspend at record__aio_sync() between calls of
record__mmap_read_evlist() and increase profiling data thruput for
the cost of userspace memory.
Signed-off-by: Alexey Budankov
---
Changes in v10:
- added description of aio-cblocks option into perf-record.txt
---
tools/perf/Documentation/perf-record.txt | 6 +++
tools/perf/builtin-record.c | 58 +++-
tools/perf/util/evlist.c | 6 +--
tools/perf/util/evlist.h | 2 +-
tools/perf/util/mmap.c | 76 ++--
tools/perf/util/mmap.h | 7 +--
6 files changed, 115 insertions(+), 40 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 246dee081efd..7f43a05908ed 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -435,6 +435,12 @@ Specify vmlinux path which has debuginfo.
--buildid-all::
Record build-id of all DSOs regardless whether it's actually hit or not.
+--aio-cblocks
+Use control blocks for asynchronous (Posix AIO) trace writing (max: 4).
+Default value is 0 that enables serial (none-AIO) trace writing mode.
+AIO mode is supported only when linking Perf tool binary with libc library
+providing implementation for Posix AIO API.
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c66ae23e3939..016f521fcaf0 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -196,16 +196,35 @@ static int record__aio_complete(struct perf_mmap *md,
struct aiocb *cblock)
return rc;
}
-static void record__aio_sync(struct perf_mmap *md)
+static int record__aio_sync(struct perf_mmap *md, bool sync_all)
{
- struct aiocb *cblock = >cblock;
+ struct aiocb **aiocb = md->aiocb;
+ struct aiocb *cblocks = md->cblocks;
struct timespec timeout = { 0, 1000 * 1000 * 1 }; /* 1ms */
+ int i, do_suspend;
do {
- if (cblock->aio_fildes == -1 || record__aio_complete(md,
cblock))
- return;
+ do_suspend = 0;
+ for (i = 0; i < md->nr_cblocks; ++i) {
+ if (cblocks[i].aio_fildes == -1 ||
record__aio_complete(md, [i])) {
+ if (sync_all)
+ aiocb[i] = NULL;
+ else
+ return i;
+ } else {
+ /*
+* Started aio write is not complete yet
+* so it has to be waited before the
+* next allocation.
+*/
+ aiocb[i] = [i];
+ do_suspend = 1;
+ }
+ }
+ if (!do_suspend)
+ return -1;
- while (aio_suspend((const struct aiocb**), 1, ))
{
+ while (aio_suspend((const struct aiocb **)aiocb,
md->nr_cblocks, )) {
if (!(errno == EAGAIN || errno == EINTR))
pr_err("failed to sync perf data, error: %m\n");
}
@@ -430,11 +449,14 @@ static int record__mmap_evlist(struct record *rec,
struct perf_evlist *evlist)
{
struct record_opts *opts = >opts;
+ int nr_cblocks = 0;
char msg[512];
-
+#ifdef HAVE_AIO_SUPPORT
+ nr_cblocks = opts->nr_cblocks;
+#endif
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode) < 0) {
+opts->auxtrace_snapshot_mode, nr_cblocks) < 0)
{
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -632,7 +654,7 @@ static void record__mmap_read_sync(struct record *rec)
struct perf_mmap *map = [i];
if (map->base)
- record__aio_sync(map);
+ record__aio_sync(map, true);
}
}
#endif
@@ -674,12 +696,13 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
}
#ifdef HAVE_AIO_SUPPORT
Re: [PATCH v2 3/6] arm64: dts: allwinner: axp803: add AC and battery power supplies
Hi Oskari,
On Sun, Oct 07, 2018 at 12:18:33AM +0300, Oskari Lemmela wrote:
> AXP803 is compatible with AXP813. Add DT nodes ADC, GPIO,
> AC and battery power supplies.
>
> Signed-off-by: Oskari Lemmela
> ---
> arch/arm64/boot/dts/allwinner/axp803.dtsi | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi
> b/arch/arm64/boot/dts/allwinner/axp803.dtsi
> index e5eae8bafc42..533987b2fe7a 100644
> --- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
> @@ -49,6 +49,37 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> + axp_adc: adc {
> + compatible = "x-powers,axp813-adc";
> + #io-channel-cells = <1>;
> + };
> +
> + axp_gpio: gpio {
> + compatible = "x-powers,axp813-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio0_ldo: gpio0-ldo {
> + pins = "GPIO0";
> + function = "ldo";
> + };
> +
> + gpio1_ldo: gpio1-ldo {
> + pins = "GPIO1";
> + function = "ldo";
> + };
> + };
> +
> + ac_power_supply: ac-power-supply {
> + compatible = "x-powers,axp813-ac-power-supply";
> + status = "disabled";
> + };
> +
Same as the patch before, I'd put it before axp_adc.
Thanks,
Quentin
signature.asc
Description: PGP signature
Re: [PATCH V4] cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull
On 08-10-18, 14:07, Anson Huang wrote:
> On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because
> the ocotp clock needs to be enabled first. Add support for reading
> OCOTP through the nvmem API, and keep the old method there to
> support old dtb.
>
> Signed-off-by: Anson Huang
> ---
> changes since V3:
> put node earlier to save one line code.
> drivers/cpufreq/imx6q-cpufreq.c | 52
> +++--
> 1 file changed, 35 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index b2ff423..8cfee0a 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -290,20 +291,32 @@ static void imx6q_opp_check_speed_grading(struct device
> *dev)
> #define OCOTP_CFG3_6ULL_SPEED_792MHZ 0x2
> #define OCOTP_CFG3_6ULL_SPEED_900MHZ 0x3
>
> -static void imx6ul_opp_check_speed_grading(struct device *dev)
> +static int imx6ul_opp_check_speed_grading(struct device *dev)
> {
> - struct device_node *np;
> - void __iomem *base;
> u32 val;
> + int ret = 0;
>
> - np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> - if (!np)
> - return;
> + if (of_find_property(dev->of_node, "nvmem-cells", NULL)) {
> + ret = nvmem_cell_read_u32(dev, "speed_grade", );
> + if (ret)
> + return ret;
> + } else {
> + struct device_node *np;
> + void __iomem *base;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> + if (!np)
> + return -ENOENT;
> +
> + base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!base) {
> + dev_err(dev, "failed to map ocotp\n");
> + return -EFAULT;
> + }
>
> - base = of_iomap(np, 0);
> - if (!base) {
> - dev_err(dev, "failed to map ocotp\n");
> - goto put_node;
> + val = readl_relaxed(base + OCOTP_CFG3);
> + iounmap(base);
> }
>
> /*
> @@ -314,7 +327,6 @@ static void imx6ul_opp_check_speed_grading(struct device
> *dev)
>* 2b'11: 9Hz on i.MX6ULL only;
>* We need to set the max speed of ARM according to fuse map.
>*/
> - val = readl_relaxed(base + OCOTP_CFG3);
> val >>= OCOTP_CFG3_SPEED_SHIFT;
> val &= 0x3;
>
> @@ -334,9 +346,7 @@ static void imx6ul_opp_check_speed_grading(struct device
> *dev)
> dev_warn(dev, "failed to disable 900MHz OPP\n");
> }
>
> - iounmap(base);
> -put_node:
> - of_node_put(np);
> + return ret;
> }
>
> static int imx6q_cpufreq_probe(struct platform_device *pdev)
> @@ -394,10 +404,18 @@ static int imx6q_cpufreq_probe(struct platform_device
> *pdev)
> }
>
> if (of_machine_is_compatible("fsl,imx6ul") ||
> - of_machine_is_compatible("fsl,imx6ull"))
> - imx6ul_opp_check_speed_grading(cpu_dev);
> - else
> + of_machine_is_compatible("fsl,imx6ull")) {
> + ret = imx6ul_opp_check_speed_grading(cpu_dev);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + if (ret) {
> + dev_err(cpu_dev, "failed to read ocotp: %d\n",
> + ret);
> + return ret;
> + }
> + } else {
> imx6q_opp_check_speed_grading(cpu_dev);
> + }
>
> /* Because we have added the OPPs here, we must free them */
> free_opp = true;
Acked-by: Viresh Kumar
--
viresh
[PATCH V4] cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull
On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because
the ocotp clock needs to be enabled first. Add support for reading
OCOTP through the nvmem API, and keep the old method there to
support old dtb.
Signed-off-by: Anson Huang
---
changes since V3:
put node earlier to save one line code.
drivers/cpufreq/imx6q-cpufreq.c | 52 +++--
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index b2ff423..8cfee0a 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -290,20 +291,32 @@ static void imx6q_opp_check_speed_grading(struct device
*dev)
#define OCOTP_CFG3_6ULL_SPEED_792MHZ 0x2
#define OCOTP_CFG3_6ULL_SPEED_900MHZ 0x3
-static void imx6ul_opp_check_speed_grading(struct device *dev)
+static int imx6ul_opp_check_speed_grading(struct device *dev)
{
- struct device_node *np;
- void __iomem *base;
u32 val;
+ int ret = 0;
- np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
- if (!np)
- return;
+ if (of_find_property(dev->of_node, "nvmem-cells", NULL)) {
+ ret = nvmem_cell_read_u32(dev, "speed_grade", );
+ if (ret)
+ return ret;
+ } else {
+ struct device_node *np;
+ void __iomem *base;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
+ if (!np)
+ return -ENOENT;
+
+ base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!base) {
+ dev_err(dev, "failed to map ocotp\n");
+ return -EFAULT;
+ }
- base = of_iomap(np, 0);
- if (!base) {
- dev_err(dev, "failed to map ocotp\n");
- goto put_node;
+ val = readl_relaxed(base + OCOTP_CFG3);
+ iounmap(base);
}
/*
@@ -314,7 +327,6 @@ static void imx6ul_opp_check_speed_grading(struct device
*dev)
* 2b'11: 9Hz on i.MX6ULL only;
* We need to set the max speed of ARM according to fuse map.
*/
- val = readl_relaxed(base + OCOTP_CFG3);
val >>= OCOTP_CFG3_SPEED_SHIFT;
val &= 0x3;
@@ -334,9 +346,7 @@ static void imx6ul_opp_check_speed_grading(struct device
*dev)
dev_warn(dev, "failed to disable 900MHz OPP\n");
}
- iounmap(base);
-put_node:
- of_node_put(np);
+ return ret;
}
static int imx6q_cpufreq_probe(struct platform_device *pdev)
@@ -394,10 +404,18 @@ static int imx6q_cpufreq_probe(struct platform_device
*pdev)
}
if (of_machine_is_compatible("fsl,imx6ul") ||
- of_machine_is_compatible("fsl,imx6ull"))
- imx6ul_opp_check_speed_grading(cpu_dev);
- else
+ of_machine_is_compatible("fsl,imx6ull")) {
+ ret = imx6ul_opp_check_speed_grading(cpu_dev);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ if (ret) {
+ dev_err(cpu_dev, "failed to read ocotp: %d\n",
+ ret);
+ return ret;
+ }
+ } else {
imx6q_opp_check_speed_grading(cpu_dev);
+ }
/* Because we have added the OPPs here, we must free them */
free_opp = true;
--
2.7.4
RE: Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm
>On 2018/10/08 10:19, Yong-Taek Lee wrote:
>> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
>> oom_adj, bool legacy)
>> struct mm_struct *mm = NULL;
>> struct task_struct *task;
>> int err = 0;
>> + int mm_users = 0;
>>
>> task = get_proc_task(file_inode(file));
>> if (!task)
>> @@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int
>> oom_adj, bool legacy)
>> struct task_struct *p = find_lock_task_mm(task);
>>
>> if (p) {
>> - if (atomic_read(>mm->mm_users) > 1) {
>> + mm_users = atomic_read(>mm->mm_users);
>> + if ((mm_users > 1) && (mm_users !=
>> get_nr_threads(p))) {
>
> How can this work (even before this patch)? When clone(CLONE_VM without
> CLONE_THREAD/CLONE_SIGHAND)
> is requested, copy_process() calls copy_signal() in order to copy
> sig->oom_score_adj and
> sig->oom_score_adj_min before calling copy_mm() in order to increment
> mm->mm_users, doesn't it?
> Then, we will get two different "struct signal_struct" with different
> oom_score_adj/oom_score_adj_min
> but one "struct mm_struct" shared by two thread groups.
>
Are you talking about race between __set_oom_adj and copy_process?
If so, i agree with your opinion. It can not set oom_score_adj properly for
copied process if __set_oom_adj
check mm_users before copy_process calls copy_mm after copy_signal. Please
correct me if i misunderstood anything.
>> mm = p->mm;
>> atomic_inc(>mm_count);
>> }
[PATCH v11 1/3]: perf util: map data buffer for preserving collected data
The map->data buffer is used to preserve map->base profiling data
for writing to disk. AIO map->cblock is used to queue corresponding
map->data buffer for asynchronous writing.
Signed-off-by: Alexey Budankov
---
Changes in v10:
- moved specific code to perf_mmap__aio_mmap(), perf_mmap__aio_munmap()
- adjusted error reporting by using %m
Changes in v9:
- implemented NO_AIO and HAVE_AIO_SUPPORT defines to cover cases of
libc implementations without Posix AIO API support
Changes in v7:
- implemented handling record.aio setting from perfconfig file
Changes in v6:
- adjusted setting of priorities for cblocks;
Changes in v5:
- reshaped layout of data structures;
- implemented --aio option;
Changes in v4:
- converted mmap()/munmap() to malloc()/free() for mmap->data buffer
management
Changes in v2:
- converted zalloc() to calloc() for allocation of mmap_aio array,
- cleared typo and adjusted fallback branch code;
---
tools/perf/Makefile.config | 5 +
tools/perf/Makefile.perf | 7 ++-
tools/perf/util/evlist.c | 4 +++-
tools/perf/util/mmap.c | 48 +-
tools/perf/util/mmap.h | 11 +++
5 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index f6d1a03c7523..2e90f4ce9214 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -355,6 +355,11 @@ endif # NO_LIBELF
ifeq ($(feature-glibc), 1)
CFLAGS += -DHAVE_GLIBC_SUPPORT
+ ifndef NO_AIO
+ifndef BIONIC
+CFLAGS += -DHAVE_AIO_SUPPORT
+endif
+ endif
endif
ifdef NO_DWARF
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 92514fb3689f..7becc6a72cf2 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -97,8 +97,13 @@ include ../scripts/utilities.mak
# Define LIBCLANGLLVM if you DO want builtin clang and llvm support.
# When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if
# llvm-config is not in $PATH.
-
+#
# Define NO_CORESIGHT if you do not want support for CoreSight trace decoding.
+#
+# Define NO_AIO if you do not want support of Posix AIO based trace
+# streaming for record mode. Currently Posix AIO trace streaming is
+# supported only when linking with glibc.
+#
# As per kernel Makefile, avoid funny character set dependencies
unexport LC_ALL
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index be440df29615..af2f8c965d7a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1029,7 +1029,9 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* So should not be passed through const pointer.
*/
struct mmap_params mp;
-
+#ifdef HAVE_AIO_SUPPORT
+ mp.nr_cblocks = 0;
+#endif
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
if (!evlist->mmap)
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index cdb95b3a1213..db8f16f8a363 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -153,8 +153,19 @@ void __weak auxtrace_mmap_params__set_idx(struct
auxtrace_mmap_params *mp __mayb
{
}
+#ifdef HAVE_AIO_SUPPORT
+static void perf_mmap__aio_munmap(struct perf_mmap *map)
+{
+ if (map->data)
+ zfree(>data);
+}
+#endif
+
void perf_mmap__munmap(struct perf_mmap *map)
{
+#ifdef HAVE_AIO_SUPPORT
+ perf_mmap__aio_munmap(map);
+#endif
if (map->base != NULL) {
munmap(map->base, perf_mmap__mmap_len(map));
map->base = NULL;
@@ -164,8 +175,40 @@ void perf_mmap__munmap(struct perf_mmap *map)
auxtrace_mmap__munmap(>auxtrace_mmap);
}
+#ifdef HAVE_AIO_SUPPORT
+static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
+{
+ int delta_max;
+
+ map->nr_cblocks = mp->nr_cblocks;
+ if (map->nr_cblocks) {
+ map->data = malloc(perf_mmap__mmap_len(map));
+ if (!map->data) {
+ pr_debug2("failed to allocate data buffer, error %m\n");
+ return -1;
+ }
+ /*
+* Use cblock.aio_fildes value different from -1
+* to denote started aio write operation on the
+* cblock so it requires explicit record__aio_sync()
+* call prior the cblock may be reused again.
+*/
+ map->cblock.aio_fildes = -1;
+ /*
+* Allocate cblock with max priority delta to
+* have faster aio write system calls.
+*/
+ delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
+ map->cblock.aio_reqprio = delta_max;
+ }
+
+ return 0;
+}
+#endif
+
int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int
cpu)
{
+ int rc = 0;
/*
* The last one will be done at
Re: [PATCH v3] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
(Resend due to broken email client) any reviews for this?
On 25 September 2018 18:35:58 BST, Craig Tatlor wrote:
>From: Taniya Das
>
>Add support for the global clock controller found on SDM660
>based devices. This should allow most non-multimedia device
>drivers to probe and control their clocks.
>Based on CAF implementation.
>
>Signed-off-by: Taniya Das
>[craig: rename parents to fit upstream, and other cleanups]
>Signed-off-by: Craig Tatlor
>---
>Changes from V1:
>Change authorship
>Add sdm630 compatible
> .../devicetree/bindings/clock/qcom,gcc.txt|1 +
> drivers/clk/qcom/Kconfig |9 +
> drivers/clk/qcom/Makefile |1 +
> drivers/clk/qcom/gcc-sdm660.c | 2480 +
> include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++
> 5 files changed, 2650 insertions(+)
> create mode 100644 drivers/clk/qcom/gcc-sdm660.c
> create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h
>
>diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
>b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
>index 664ea1fd6c76..e498ad2e8db8 100644
>--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
>+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
>@@ -38,6 +38,8 @@ Required properties :
> "qcom,gcc-msm8996"
> "qcom,gcc-msm8998"
> "qcom,gcc-mdm9615"
>+ "qcom,gcc-sdm630"
>+ "qcom,gcc-sdm660"
> "qcom,gcc-sdm845"
>
> - reg : shall contain base register location and length
>diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
>index 5b181b182f40..4d478b261dfe 100644
>--- a/drivers/clk/qcom/Kconfig
>+++ b/drivers/clk/qcom/Kconfig
>@@ -243,6 +243,15 @@ config SDM_CAMCC_845
> Support for the camera clock controller on SDM845 devices.
> Say Y if you want to support camera devices and camera
>functionality.
>
>+config SDM_GCC_660
>+ tristate "SDM660 Global Clock Controller"
>+ select QCOM_GDSC
>+ depends on COMMON_CLK_QCOM
>+ help
>+Support for the global clock controller on SDM660 devices.
>+Say Y if you want to use peripheral devices such as UART, SPI,
>+i2C, USB, UFS, SDDC, PCIe, etc.
>+
> config SDM_GCC_845
> tristate "SDM845 Global Clock Controller"
> select QCOM_GDSC
>diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
>index 935f142bc155..ab892f6d847c 100644
>--- a/drivers/clk/qcom/Makefile
>+++ b/drivers/clk/qcom/Makefile
>@@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o
> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o
> obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
>+obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
> obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
> obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
>diff --git a/drivers/clk/qcom/gcc-sdm660.c
>b/drivers/clk/qcom/gcc-sdm660.c
>new file mode 100644
>index ..641bba611b5f
>--- /dev/null
>+++ b/drivers/clk/qcom/gcc-sdm660.c
>@@ -0,0 +1,2480 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
>+ * Copyright (c) 2018, Craig Tatlor.
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+#include
>+
>+#include "common.h"
>+#include "clk-regmap.h"
>+#include "clk-alpha-pll.h"
>+#include "clk-rcg.h"
>+#include "clk-branch.h"
>+#include "reset.h"
>+#include "gdsc.h"
>+
>+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
>+
>+enum {
>+ P_XO,
>+ P_SLEEP_CLK,
>+ P_GPLL0,
>+ P_GPLL1,
>+ P_GPLL4,
>+ P_GPLL0_EARLY_DIV,
>+ P_GPLL1_EARLY_DIV,
>+};
>+
>+static const struct parent_map
>gcc_parent_map_xo_gpll0_gpll0_early_div[] = {
>+ { P_XO, 0 },
>+ { P_GPLL0, 1 },
>+ { P_GPLL0_EARLY_DIV, 6 },
>+};
>+
>+static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[]
>= {
>+ "xo",
>+ "gpll0",
>+ "gpll0_early_div",
>+};
>+
>+static const struct parent_map gcc_parent_map_xo_gpll0[] = {
>+ { P_XO, 0 },
>+ { P_GPLL0, 1 },
>+};
>+
>+static const char * const gcc_parent_names_xo_gpll0[] = {
>+ "xo",
>+ "gpll0",
>+};
>+
>+static const struct parent_map
>gcc_parent_map_xo_gpll0_sleep_clk_gpll0_early_div[] = {
>+ { P_XO, 0 },
>+ { P_GPLL0, 1 },
>+ { P_SLEEP_CLK, 5 },
>+ { P_GPLL0_EARLY_DIV, 6 },
>+};
>+
>+static const char * const
>gcc_parent_names_xo_gpll0_sleep_clk_gpll0_early_div[] = {
>+ "xo",
>+ "gpll0",
>+ "sleep_clk",
>+ "gpll0_early_div",
>+};
>+
>+static const struct parent_map gcc_parent_map_xo_sleep_clk[] = {
>+ { P_XO, 0 },
>+ { P_SLEEP_CLK, 5 },
>+};
>+
>+static const char * const gcc_parent_names_xo_sleep_clk[] = {
>+
Re: [PATCH v3 6/6] remoteproc: qcom: q6v5-pil: Assign the relocated address
On Fri 27 Jul 08:20 PDT 2018, Sibi Sankar wrote:
> Assign the relocated base of the modem image, as the offsets
> from the virtual memory might not be based on the physical
> address.
>
In order to get this merged before the first call to rproc_da_to_va() I
applied this patch to rproc-next.
Thanks,
Bjorn
> Signed-off-by: Sibi Sankar
> ---
> drivers/remoteproc/qcom_q6v5_pil.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
> b/drivers/remoteproc/qcom_q6v5_pil.c
> index 22bb049c3e7f..b1296d614b8b 100644
> --- a/drivers/remoteproc/qcom_q6v5_pil.c
> +++ b/drivers/remoteproc/qcom_q6v5_pil.c
> @@ -862,6 +862,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
> }
>
> mpss_reloc = relocate ? min_addr : qproc->mpss_phys;
> + qproc->mpss_reloc = mpss_reloc;
> /* Load firmware segments */
> for (i = 0; i < ehdr->e_phnum; i++) {
> phdr = [i];
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
RE: [PATCH 0/6] cpuidle: menu: Fixes, optimizations and cleanups
On 2018.10.03 23:56 Rafael J. Wysocki wrote: > On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote: >> >> Hi All, >> >> This series fixes a couple of issues with the menu governor, optimizes it >> somewhat and makes a couple of cleanups in it. Please refer to the >> patch changelogs for details. >> >> All of the changes in the series are straightforward in my view. The >> first two patches are fixes, the rest is optimizations and cleanups. > > I'm inclined to take this stuff in for 4.20 if nobody has problems > with it, so please have a look if you care (and you should, because > the code in question is run on all tickless systems out there). Hi Rafael, I did tests with kernel 4.19-rc6 as a baseline reference and then with 8 of your patches (&8patches in the graphs legend): cpuidle: menu: Replace data->predicted_us with local variable . as required to get this set of 6 to then apply. This set of 6 patches. cpuidle: poll_state: Revise loop termination condition Recall I also did some testing in late August [1], with a kernel that was just a few hundred commits before 4.19-rc1. The baseline is now way different. While I don't know why, I bisected the kernel and either made a mistake, or it was: first bad commit: [06e386a1db54ab6a671e103e929b590f7a88f0e3] Merge tag 'fbdev-v4.19' of https://github.com/bzolnier/linux Anyway, and for reference, included on some of the graphs is the old data from late August (legend name "4.18+3rjw (Aug test)") Test 1: A Thomas Ilsche type "powernightmare" test: (forever ((10 times - variable usec sleep) 0.999 seconds sleep) X 40 staggered threads. Where the "variable" was from 0.05 to 5 in steps of 0.05, for the first ~200 minutes of the test. (note: overheads mean that actual loop times are quite different.) And then from 5 to 50 in steps of 1, for the remaining 100 minutes of the test. (Shortened by 900 minutes from the way the test was done in August.) Each step ran for 2 minutes. The system was idle for 1 minute at the start, and a few minutes at the end of the graphs. The power and idle statistics graphs are here: http://fast.smythies.com/linux-pm/k419/k419-pn-sweep-rjw.htm Observations: While the graphs are pretty and such, the only significant difference is the idle state 0 percentages go down a lot with the 8 patches. However the number of idle state 0 entries per minute goes up. To present the same information in a different way a trace was done (at 9 Gigabytes in 2 minutes): &8patches Idle State 0: Total Entries: 10091412 : time (seconds): 49.447025 Idle State 1: Total Entries: 49332297 : time (seconds): 375.943064 Idle State 2: Total Entries: 311810 : time (seconds): 2.626403 k4.19-rc6 Idle State 0: Total Entries: 9162465 : time (seconds): 70.650566 Idle State 1: Total Entries: 47592671 : time (seconds): 373.625083 Idle State 2: Total Entries: 266212 : time (seconds): 2.278159 Conclusions: Behaves as expected. Test 2: pipe test 2 CPUs, one core. CPU test: The average loop times graph is here: http://fast.smythies.com/linux-pm/k419/k419-rjw-pipe-1core.png The power and idle statistics graphs are here: http://fast.smythies.com/linux-pm/k419/k419-rjw-pipe-1core.htm Conclusions: Better performance at the cost of more power with the patch set, but late August had both better performance and less power. Overall idle entries and exits are about the same, but way way more idle state 0 entries and exits with the patch set. Supporting: trace summary (note: such a heavy load on the trace system (~6 gigabytes in 2 minutes) costs about 25% in performance): k4.16-rc6 pipe Idle State 0: Total Entries: 76638 : time (seconds): 0.193166 Idle State 1: Total Entries: 37825999 : time (seconds): 23.886772 Idle State 2: Total Entries: 49 : time (seconds): 0.007908 &8patches Idle State 0: Total Entries: 37632104 : time (seconds): 26.097220 Idle State 1: Total Entries: 397 : time (seconds): 0.020021 Idle State 2: Total Entries: 208 : time (seconds): 0.031052 With rjw 8 patch set (1st col is usecs duration, 2nd col is number of occurrences in 2 minutes): Idle State: 0 Summary: 0 24401500 1 13153259 2 19807 3 32731 4 802 5 346 6 1554 7 20087 8 1849 9 150 10 9 11 10 Idle State: 1 Summary: 0 29 1 44 2 15 3 45 4 5 5 26 6 2 7 24 8 4 9 21 10 6 11 39 12 15 13 38 14 14 15 27 16 10 17 12 18 1 35 1 89 1 135 1 678 1 991 2 995 3 996 1 997 8 998 1 999 1 Kernel 4.19-rc6 reference: Idle State: 0 Summary: 0 17212 1 7516 2 34737 3 14763 4 2312 5 74 6 3 7 3 8 3 9 4 10 5 11 5 40 1 Idle State: 1 Summary: 0 36073601 1 1662728 2 67985 3 106 4 22 5 8 6 2214 7 11037 8 7110 9 1156 10 1 11 1 13 2 23 1 29 1 99 1 554 1 620 1 846 1 870 1 936 1 944 1 963 1 972 1 989 1 991 1 993 1 994 1 995 2 996 2 997 6 998 3 Test 3: iperf test: Method: Be an iperf client to 3 servers at once. Packets are small on purpose, we want the highest frequency of packets, not fastest payload delivery. Performance: Kernel 4.19: 79.9 + 23.5 + 32.8 = 136.2 Mbits/Sec. &8patches: 78.6 + 23.2 + 33.0 =
Re: [PATCH V3] cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull
On 08-10-18, 09:10, Anson Huang wrote:
> On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because
> the ocotp clock needs to be enabled first. Add support for reading
> OCOTP through the nvmem API, and keep the old method there to
> support old dtb.
>
> Signed-off-by: Anson Huang
> ---
> changes since V2:
> Add put node when reading ocotp register done.
> drivers/cpufreq/imx6q-cpufreq.c | 53
> -
> 1 file changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index b2ff423..38b67f8 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -290,20 +291,33 @@ static void imx6q_opp_check_speed_grading(struct device
> *dev)
> #define OCOTP_CFG3_6ULL_SPEED_792MHZ 0x2
> #define OCOTP_CFG3_6ULL_SPEED_900MHZ 0x3
>
> -static void imx6ul_opp_check_speed_grading(struct device *dev)
> +static int imx6ul_opp_check_speed_grading(struct device *dev)
> {
> - struct device_node *np;
> - void __iomem *base;
> u32 val;
> + int ret = 0;
>
> - np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> - if (!np)
> - return;
> + if (of_find_property(dev->of_node, "nvmem-cells", NULL)) {
> + ret = nvmem_cell_read_u32(dev, "speed_grade", );
> + if (ret)
> + return ret;
> + } else {
> + struct device_node *np;
> + void __iomem *base;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
> + if (!np)
> + return -ENOENT;
> +
> + base = of_iomap(np, 0);
You could have done of_node_put(np); right here and remove the below two calls
to the same.
> + if (!base) {
> + dev_err(dev, "failed to map ocotp\n");
> + of_node_put(np);
> + return -EFAULT;
> + }
>
> - base = of_iomap(np, 0);
> - if (!base) {
> - dev_err(dev, "failed to map ocotp\n");
> - goto put_node;
> + val = readl_relaxed(base + OCOTP_CFG3);
> + iounmap(base);
> + of_node_put(np);
> }
--
viresh
Re: protected pins and debugfs
Quoting Sodagudi Prasad (2018-10-03 05:38:24)
>
> for (i = 0; i < chip->ngpio; i++, gpio++) {
> + label = gpiochip_is_requested(chip, i);
> + if (!label)
> + continue;
> msm_gpio_dbg_show_one(s, NULL, chip, i, gpio);
> - seq_puts(s, "\n");
> }
> }
>
Does something not work with the following code in
msm_gpio_dbg_show_one()?
if (!gpiochip_line_is_valid(chip, offset))
return;
[PATCH v11 2/3]: perf record: enable asynchronous trace writing
Trace file offset is read once before mmaps iterating loop and written
back after all performance data enqueued for aio writing. Trace file offset
is incremented linearly after every successful aio write operation.
record__aio_sync() blocks till completion of started AIO operation
and then proceeds.
record__mmap_read_sync() implements a barrier for all incomplete
aio write requests.
Signed-off-by: Alexey Budankov
---
Changes in v11:
- replacing the both lseek() syscalls in every loop iteration by the only
two syscalls just before and after the loop at record__mmap_read_evlist()
and advancing *in-flight* off file pos value at perf_mmap__aio_push()
Changes in v10:
- avoided lseek() setting file pos back in case of record__aio_write() failure
- compacted code selecting between serial and AIO streaming
- optimized call places of record__mmap_read_sync()
Changes in v9:
- enable AIO streaming only when --aio-cblocks option is specified explicitly
Changes in v8:
- split AIO completion check into separate record__aio_complete()
Changes in v6:
- handled errno == EAGAIN case from aio_write();
Changes in v5:
- data loss metrics decreased from 25% to 2x in trialed configuration;
- avoided nanosleep() prior calling aio_suspend();
- switched to per cpu multi record__aio_sync() aio
- record_mmap_read_sync() now does global barrier just before
switching trace file or collection stop;
- resolved livelock on perf record -e intel_pt// -- dd if=/dev/zero
of=/dev/null count=10
Changes in v4:
- converted void *bf to struct perf_mmap *md in signatures
- written comment in perf_mmap__push() just before perf_mmap__get();
- written comment in record__mmap_read_sync() on possible restarting
of aio_write() operation and releasing perf_mmap object after all;
- added perf_mmap__put() for the cases of failed aio_write();
Changes in v3:
- written comments about nanosleep(0.5ms) call prior aio_suspend()
to cope with intrusiveness of its implementation in glibc;
- written comments about rationale behind coping profiling data
into mmap->data buffer;
---
tools/perf/builtin-record.c | 168 ++--
tools/perf/perf.h | 3 +
tools/perf/util/mmap.c | 76
tools/perf/util/mmap.h | 5 ++
4 files changed, 246 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 0980dfe3396b..c66ae23e3939 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -124,6 +124,112 @@ static int record__write(struct record *rec, struct
perf_mmap *map __maybe_unuse
return 0;
}
+#ifdef HAVE_AIO_SUPPORT
+static int record__aio_write(struct aiocb *cblock, int trace_fd,
+ void *buf, size_t size, off_t off)
+{
+ int rc;
+
+ cblock->aio_fildes = trace_fd;
+ cblock->aio_buf= buf;
+ cblock->aio_nbytes = size;
+ cblock->aio_offset = off;
+ cblock->aio_sigevent.sigev_notify = SIGEV_NONE;
+
+ do {
+ rc = aio_write(cblock);
+ if (rc == 0) {
+ break;
+ } else if (errno != EAGAIN) {
+ cblock->aio_fildes = -1;
+ pr_err("failed to queue perf data, error: %m\n");
+ break;
+ }
+ } while (1);
+
+ return rc;
+}
+
+static int record__aio_complete(struct perf_mmap *md, struct aiocb *cblock)
+{
+ void *rem_buf;
+ off_t rem_off;
+ size_t rem_size;
+ int rc, aio_errno;
+ ssize_t aio_ret, written;
+
+ aio_errno = aio_error(cblock);
+ if (aio_errno == EINPROGRESS)
+ return 0;
+
+ written = aio_ret = aio_return(cblock);
+ if (aio_ret < 0) {
+ if (aio_errno != EINTR)
+ pr_err("failed to write perf data, error: %m\n");
+ written = 0;
+ }
+
+ rem_size = cblock->aio_nbytes - written;
+
+ if (rem_size == 0) {
+ cblock->aio_fildes = -1;
+ /*
+* md->refcount is incremented in perf_mmap__push() for
+* every enqueued aio write request so decrement it because
+* the request is now complete.
+*/
+ perf_mmap__put(md);
+ rc = 1;
+ } else {
+ /*
+* aio write request may require restart with the
+* reminder if the kernel didn't write whole
+* chunk at once.
+*/
+ rem_off = cblock->aio_offset + written;
+ rem_buf = (void *)(cblock->aio_buf + written);
+ record__aio_write(cblock, cblock->aio_fildes,
+ rem_buf, rem_size, rem_off);
+ rc = 0;
+ }
+
+ return rc;
+}
+
+static void record__aio_sync(struct perf_mmap *md)
+{
+ struct aiocb *cblock
Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"
On Sat, Oct 06, 2018 at 09:39:05AM -0400, Steven Rostedt wrote: > On Sat, 6 Oct 2018 14:12:11 +0200 > Peter Zijlstra wrote: > > > On Fri, Oct 05, 2018 at 09:51:11PM -0400, Steven Rostedt wrote: > > > +#define arch_dynfunc_trampoline(name, def) \ > > > + asm volatile ( \ > > > + ".globl dynfunc_" #name "; \n\t"\ > > > + "dynfunc_" #name ": \n\t" \ > > > + "jmp " #def " \n\t" \ > > > + ".balign 8 \n \t" \ > > > + : : : "memory" ) > > > > Bah, what is it with you people and trampolines. Why can't we, just like > > jump_label, patch the call directly? > > > > The whole call+jmp thing is silly, don't do that. It just wrecks I$ and > > is slower for no real reason afaict. > > My first attempt was to do just that. But to add a label at the > call site required handling all the parameters too. See my branch: > ftrace/jump_function-v1 for how ugly it got (and it didn't work). Can't we hijack the relocation records for these functions before they get thrown out in the (final) link pass or something?
Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for QCS404
On 10/7/2018 7:01 PM, Vinod wrote:
Hi Taniya,
Thanks for the review, It would be great if you can strip the irrelevant
context while replying, makes it easier for people to follow.
On 06-10-18, 23:28, Taniya Das wrote:
+static struct clk_rcg2 pclk0_clk_src = {
+ .cmd_rcgr = 0x4d000,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = gcc_parent_map_12,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "pclk0_clk_src",
+ .parent_names = gcc_parent_names_12,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
Please remove the NOCACHE flag for all display RCGs as there are no real
requirement.
Thanks for the suggestion, will do
+++ b/include/dt-bindings/clock/qcom,gcc-qcs404.h
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GCC_QCS404_H
+#define _DT_BINDINGS_CLK_QCOM_GCC_QCS404_H
+
+#define APSS_AHB_CLK_SRC 0
+#define BLSP1_QUP0_I2C_APPS_CLK_SRC1
+#define BLSP1_QUP0_SPI_APPS_CLK_SRC2
+#define BLSP1_QUP1_I2C_APPS_CLK_SRC3
+#define BLSP1_QUP1_SPI_APPS_CLK_SRC4
+#define BLSP1_QUP2_I2C_APPS_CLK_SRC5
+#define BLSP1_QUP2_SPI_APPS_CLK_SRC6
+#define BLSP1_QUP3_I2C_APPS_CLK_SRC7
+#define BLSP1_QUP3_SPI_APPS_CLK_SRC8
+#define BLSP1_QUP4_I2C_APPS_CLK_SRC9
+#define BLSP1_QUP4_SPI_APPS_CLK_SRC10
+#define BLSP1_UART0_APPS_CLK_SRC 11
+#define BLSP1_UART1_APPS_CLK_SRC 12
+#define BLSP1_UART2_APPS_CLK_SRC 13
+#define BLSP1_UART3_APPS_CLK_SRC 14
+#define BLSP2_QUP0_I2C_APPS_CLK_SRC15
+#define BLSP2_QUP0_SPI_APPS_CLK_SRC16
+#define BLSP2_UART0_APPS_CLK_SRC 17
+#define BYTE0_CLK_SRC 18
+#define EMAC_CLK_SRC 19
+#define EMAC_PTP_CLK_SRC 20
+#define ESC0_CLK_SRC 21
+#define GCC_APSS_AHB_CLK 22
+#define GCC_APSS_AXI_CLK 23
+#define GCC_BIMC_APSS_AXI_CLK 24
+#define GCC_BIMC_GFX_CLK 25
+#define GCC_BIMC_MDSS_CLK 26
+#define GCC_BLSP1_AHB_CLK 27
+#define GCC_BLSP1_QUP0_I2C_APPS_CLK28
+#define GCC_BLSP1_QUP0_SPI_APPS_CLK29
+#define GCC_BLSP1_QUP1_I2C_APPS_CLK30
+#define GCC_BLSP1_QUP1_SPI_APPS_CLK31
+#define GCC_BLSP1_QUP2_I2C_APPS_CLK32
+#define GCC_BLSP1_QUP2_SPI_APPS_CLK33
+#define GCC_BLSP1_QUP3_I2C_APPS_CLK34
+#define GCC_BLSP1_QUP3_SPI_APPS_CLK35
+#define GCC_BLSP1_QUP4_I2C_APPS_CLK36
+#define GCC_BLSP1_QUP4_SPI_APPS_CLK37
+#define GCC_BLSP1_UART0_APPS_CLK 38
+#define GCC_BLSP1_UART1_APPS_CLK 39
+#define GCC_BLSP1_UART2_APPS_CLK 40
+#define GCC_BLSP1_UART3_APPS_CLK 41
+#define GCC_BLSP2_AHB_CLK 42
+#define GCC_BLSP2_QUP0_I2C_APPS_CLK43
+#define GCC_BLSP2_QUP0_SPI_APPS_CLK44
+#define GCC_BLSP2_UART0_APPS_CLK 45
+#define GCC_BOOT_ROM_AHB_CLK 46
+#define GCC_DCC_CLK47
+#define GCC_GENI_IR_H_CLK 48
+#define GCC_ETH_AXI_CLK49
+#define GCC_ETH_PTP_CLK50
+#define GCC_ETH_RGMII_CLK 51
+#define GCC_ETH_SLAVE_AHB_CLK 52
+#define GCC_GENI_IR_S_CLK 53
+#define GCC_GP1_CLK54
+#define GCC_GP2_CLK55
+#define GCC_GP3_CLK56
+#define GCC_MDSS_AHB_CLK 57
+#define GCC_MDSS_AXI_CLK 58
+#define GCC_MDSS_BYTE0_CLK 59
+#define GCC_MDSS_ESC0_CLK 60
+#define GCC_MDSS_HDMI_APP_CLK 61
+#define GCC_MDSS_HDMI_PCLK_CLK 62
+#define GCC_MDSS_MDP_CLK 63
+#define GCC_MDSS_PCLK0_CLK 64
+#define GCC_MDSS_VSYNC_CLK 65
+#define GCC_OXILI_AHB_CLK 66
Re: [PATCH v5 4/7] dmaengine: xilinx_dma: program hardware supported buffer length
On Tue, Oct 2, 2018 at 4:56 PM Vinod wrote:
>
> On 28-09-18, 08:53, Andrea Merello wrote:
> > On Tue, Sep 18, 2018 at 6:25 PM Vinod wrote:
>
> > > > @@ -964,7 +968,7 @@ static int xilinx_dma_calc_copysize(struct
> > > > xilinx_dma_chan *chan,
> > > > int size, int done)
> > > > {
> > > > size_t copy = min_t(size_t, size - done,
> > > > - XILINX_DMA_MAX_TRANS_LEN);
> > > > + chan->xdev->max_buffer_len);
> > >
> > > hmm why not add max_buffer_len in patch 1 again, and then use default
> > > len as XILINX_DMA_MAX_TRANS_LEN and add multiple lengths here :)
> >
> > Sorry, I'm not getting your point. Could you please elaborate the "add
> > multiple lengths here" thing ?
>
> IIRC (sorry been travelling and vacation), add
> chan->xdev->max_buffer_len in patch 1 and initialize it to
> XILINX_DMA_MAX_TRANS_LEN. Then in subsequent patches update the length.
Ah ok. IMO introducing max_buffer_len seems more related to what 4/7
does (actually getting the max transfer len from DT, thus it is not
constant anymore) rather than to what 1/7 does (commonizing the
calculation of transfer len as it is).. This is why I've introduced it
in 4/7..
.. But if you prefer this way, I'll change this :) .. Maybe we can
change 1/7 commit message so that this change looks less off-topic..
But I have not found a very good title yet.. Something like "Prepare
for DMA copy size calculation rework" ?
> --
> ~Vinod
Re: [PATCH v3 5/6] remoteproc: qcom: q6v5-pil: Register segments/dumpfn for coredump
On Fri 27 Jul 08:20 PDT 2018, Sibi Sankar wrote:
> Register the MDT segments and custom dumpfn with the remoteproc core
> dump functionality.
>
> Signed-off-by: Sibi Sankar
> ---
> drivers/remoteproc/qcom_q6v5_pil.c | 40 ++
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
> b/drivers/remoteproc/qcom_q6v5_pil.c
> index ac3342f9ea5a..22bb049c3e7f 100644
> --- a/drivers/remoteproc/qcom_q6v5_pil.c
> +++ b/drivers/remoteproc/qcom_q6v5_pil.c
> @@ -1058,10 +1058,50 @@ static void *q6v5_da_to_va(struct rproc *rproc, u64
> da, int len)
> return qproc->mpss_region + offset;
> }
>
> +static int qcom_q6v5_register_dump_segments(struct rproc *rproc,
> + const struct firmware *fw_unused)
How about naming it mba_fw instead of unused? Just as unused, but easier
to understand why it isn't used.
> +{
> + const struct firmware *fw;
> + const struct elf32_phdr *phdrs;
> + const struct elf32_phdr *phdr;
> + const struct elf32_hdr *ehdr;
> + struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
No need for an explicit typecast from void *.
The rest looks good!
Regards,
Bjorn
linux-next: manual merge of the akpm-current tree with the compiler-attributes tree
Hi all,
Today's linux-next merge of the akpm-current tree got conflicts in:
include/linux/compiler-gcc.h
include/linux/compiler_types.h
between commit:
a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version
checks")
from the compiler-attributes tree and commit:
b6fbc7334215 ("include/linux/compiler*.h: add version detection to
asm_volatile_goto")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/compiler-gcc.h
index cfac027e1625,d8d314bfc23e..
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@@ -116,8 -130,34 +116,8 @@@
#define randomized_struct_fields_end } __randomize_layout;
#endif
-/*
- * When used with Link Time Optimization, gcc can optimize away C functions or
- * variables which are referenced only from assembly code. __visible tells
the
- * optimizer that something else uses this function or variable, thus
preventing
- * this.
- */
-#define __visible __attribute__((externally_visible))
-
-/* gcc version specific checks */
-
-#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
-/*
- * __assume_aligned(n, k): Tell the optimizer that the returned
- * pointer can be assumed to be k modulo n. The second argument is
- * optional (default 0), so we use a variadic macro to make the
- * shorthand.
- *
- * Beware: Do not apply this to functions which may return
- * ERR_PTRs. Also, it is probably unwise to apply it to functions
- * returning extra information in the low bits (but in that case the
- * compiler should see some alignment anyway, when the return value is
- * massaged by 'flags = ptr & 3; ptr &= ~3;').
- */
-#define __assume_aligned(a, ...) __attribute__((__assume_aligned__(a, ##
__VA_ARGS__)))
-#endif
-
/*
- * GCC 'asm goto' miscompiles certain code sequences:
+ * GCC < 4.8.2 'asm goto' miscompiles certain code sequences:
*
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
*
diff --cc include/linux/compiler_types.h
index 3439d7d0249a,c2ded31a4cec..
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@@ -130,6 -140,21 +130,10 @@@ struct ftrace_likely_data
# define randomized_struct_fields_end
#endif
-#ifndef __visible
-#define __visible
-#endif
-
-/*
- * Assume alignment of return value.
- */
-#ifndef __assume_aligned
-#define __assume_aligned(a, ...)
-#endif
-
+ #ifndef asm_volatile_goto
+ #define asm_volatile_goto(x...) asm goto(x)
+ #endif
+
/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
pgpOrUde8GueC.pgp
Description: OpenPGP digital signature
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Quoting Anson Huang (2018-09-03 00:20:53) > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote: > > > > Quoting Peng Fan (2018-08-12 18:15:41) > > > >> Hi Anson, > > > >> > > > > -Original Message- > > > > From: Anson Huang > > > > Sent: 2018年8月8日 12:39 > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > ker...@pengutronix.de; Fabio Estevam ; > > > > mturque...@baylibre.com; sb...@kernel.org; > > > > linux-arm-ker...@lists.infradead.org; > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Cc: dl-linux-imx > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > Clock framework will enable those clocks registered with > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array > > > > during clock > > > initialization now. > > > > > > Will it be more flexible to parse dts saying "critical-clocks = > > > " > > > or "init-on-arrary=" > > > and enable those clocks? > > > >>> > > > >>> Parsing the clocks arrays from dtb is another way of enabling > > > >>> critical clocks, but for current i.MX6/7 platforms, we implement > > > >>> it in same way as most of other SoCs, currently I did NOT see any > > > >>> necessity of putting them in dtb, just adding flag during clock > > > >>> registering is more simple, if there is any special requirement > > > >>> for different clocks set to be enabled, then we can add support to > > > >>> enable > > the method of parsing critical-clocks from dtb. Just my two cents. > > > >> > > > >> Thinking about OP-TEE want to use one device, but it's clocks are > > > >> registered by Linux, because there is no module in Linux side use > > > >> it, it will shutdown the clock, which cause OP-TEE could not access the > > device. > > > >> > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to > > > >> make sure the clocks are not shutdown by Linux. > > > >> > > > >> However adding a new property in clk node and let driver code parse > > > >> the dts, there is no need to modify clk driver code when OP-TEE needs > > another device clock. > > > >> > > > > > > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE > > > > driver in Linux probe, acquire clocks, and keep the clks enabled > > > > forever? > > > > > > Sounds reasonable, but how could this be done without introducing > > > platform-specific stuff in the OP-TEE driver? > > > > > > > Why is that a goal? > > I do NOT think we should consider such case in this patch series, whatever > OP-TEE needs for its own > feature, it should do necessary operations either in its driver or somewhere > else by adding new patch. > Why can't we add clks to the op-tee node in DT's /firmware container? Then any clks in there can be turned on forever and left enabled by the linux driver?
Re: [PATCH v10 10/10] mtd: maps: gpio-addr-flash: Add support for device-tree devices
Hi Boris On Fri, Oct 5, 2018 at 9:32 PM Boris Brezillon wrote: > > On Fri, 5 Oct 2018 20:12:43 +0200 > Ricardo Ribalda Delgado wrote: > > > > > I think I know what might be the issue. on cfi_cmdset_002.c > > cfi_amdstd_reset can be called in parrallel to cfi_amdstd_destroy. > > > > maybe we should call > > unregister_reboot_notifier(>reboot_notifier); > > before > > cfi_amdstd_reset(mtd) > > > > need to try that on real hw with some strategical printfs :P. But that > > will ahve to wait til Monday > > No problem, nothing urgent here. Have a nice weekend. Just updated my kernel version (4.14.53 -> 4.14.69) with you last github and I do not see the crash anymore. So I guess we are good to go. Thanks! -- Ricardo Ribalda
Re: linux-next: build warning after merge of the nand tree
Hi Stephen,
Stephen Rothwell wrote on Mon, 8 Oct 2018
11:38:42 +1100:
> Hi Boris,
Boris is still there but I'm in charge of the NAND tree these days (and
the one to blame too for this one :) ).
>
> After merging the nand tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/mtd/nand/raw/nand_toshiba.c: In function
> 'toshiba_nand_read_page_benand':
> drivers/mtd/nand/raw/nand_toshiba.c:54:19: warning: unused variable 'mtd'
> [-Wunused-variable]
> struct mtd_info *mtd = nand_to_mtd(chip);
>^~~
> drivers/mtd/nand/raw/nand_toshiba.c: In function
> 'toshiba_nand_read_subpage_benand':
> drivers/mtd/nand/raw/nand_toshiba.c:68:19: warning: unused variable 'mtd'
> [-Wunused-variable]
> struct mtd_info *mtd = nand_to_mtd(chip);
>^~~
>
> Introduced by commit
>
> fe8b76ec9886 ("mtd: rawnand: toshiba: Pass a single nand_chip object to the
> status helper")
Thanks for the warning, I'll correct it for tomorrow.
Kind regards,
Miquèl
linux-next: build failure after merge of the akpm tree
Hi all,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
arch/x86/mm/kaslr.c:26:10: fatal error: linux/bootmem.h: No such file or
directory
#include
^
Caused by patch
"mm: remove include/linux/bootmem.h"
interacting with commit
3a387c6d96e6 ("x86/kaslr, ACPI/NUMA: Fix KASLR build error")
from the tip tree.
I have added the following patch for today:
From: Stephen Rothwell
Date: Mon, 8 Oct 2018 18:57:00 +1100
Subject: [PATCH] x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal
Signed-off-by: Stephen Rothwell
---
arch/x86/mm/kaslr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index b3471388288d..ad80bdc690c1 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
#include
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpBtZcPEWbkU.pgp
Description: OpenPGP digital signature
Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"
> On Oct 8, 2018, at 12:21 AM, Peter Zijlstra wrote: > >> On Sat, Oct 06, 2018 at 09:39:05AM -0400, Steven Rostedt wrote: >> On Sat, 6 Oct 2018 14:12:11 +0200 >> Peter Zijlstra wrote: >> On Fri, Oct 05, 2018 at 09:51:11PM -0400, Steven Rostedt wrote: +#define arch_dynfunc_trampoline(name, def)\ +asm volatile (\ +".globl dynfunc_" #name "; \n\t"\ +"dynfunc_" #name ": \n\t"\ +"jmp " #def " \n\t"\ +".balign 8 \n \t"\ +: : : "memory" ) >>> >>> Bah, what is it with you people and trampolines. Why can't we, just like >>> jump_label, patch the call directly? >>> >>> The whole call+jmp thing is silly, don't do that. It just wrecks I$ and >>> is slower for no real reason afaict. >> >> My first attempt was to do just that. But to add a label at the >> call site required handling all the parameters too. See my branch: >> ftrace/jump_function-v1 for how ugly it got (and it didn't work). > > Can't we hijack the relocation records for these functions before they > get thrown out in the (final) link pass or something? I could be talking out my arse here, but I thought we could do this, too, then changed my mind. The relocation records give us the location of the call or jump operand, but they don’t give the address of the beginning of the instruction. If the instruction crosses a cache line boundary, don’t we need to use the int3 patching trick? And that requires knowing which byte to patch with int3. Or am I wrong and can the CPUs we care about correctly handle a locked write to part of an instruction that crosses a cache line boundary?
Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled
在 2018年10月08日 16:00, Borislav Petkov 写道:
> On Mon, Oct 08, 2018 at 03:11:56PM +0800, lijiang wrote:
>> I used this ".config" to compile kernel in the attachment, and got a compile
>> error.
>> Would you like to have a try?
>>
>> [root@hp-dl385g10-03 linux]# make ARCH=i386 -j32
>> ..
>> LD vmlinux.o
>> MODPOST vmlinux.o
>> fs/proc/vmcore.o：In function ‘read_from_oldmem’：
>> /home/linux/fs/proc/vmcore.c:127：undefined reference to
>> ‘copy_oldmem_page_encrypted’
>> make: *** [vmlinux] error 1
>
> Thanks, that triggered here. Ok, I guess something like this, to avoid
> the ugly ifdeffery:
>
> ---
> diff --git a/arch/x86/kernel/crash_dump_32.c b/arch/x86/kernel/crash_dump_32.c
> index 33ee47670b99..8696800f2eea 100644
> --- a/arch/x86/kernel/crash_dump_32.c
> +++ b/arch/x86/kernel/crash_dump_32.c
> @@ -80,6 +80,16 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> return csize;
> }
>
> +/*
> + * 32-bit parrot version to avoid build errors.
> + */
> +ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t
> csize,
> +unsigned long offset, int userbuf)
> +{
> + WARN_ON_ONCE(1);
> + return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
> +}
> +
It looks like a good way to avoid the 'ifdefined', and it's also good enough
for i386.
But for other architectures, such as POWERPC/ARM..., we will also have to add
the same
function for every architecture. Otherwise, i guess that they also have a same
compile
error on other architectures.
Sometimes, it's hard to make a choice.
Regards,
Lianbo
> static int __init kdump_buf_page_init(void)
> {
> int ret = 0;
>
>
>
Re: [PATCH] sched/dl : return accurate release rq lock info
On 06/10/18 09:08, Peng Hao wrote: > find_lock_later_rq may or not releease rq lock when return > later_rq=NULL, but it is fuzzy. > If not releasing rq lock, it is unnecessary to re-call > pick_next_pushable_dl_task. > > Signed-off-by: Peng Hao Subject has whitespaces problems and changelog might be improved. Other then that patch looks good, thanks! Acked-by: Juri Lelli
Re: [PATCH AUTOSEL 4.18 27/48] sound: enable interrupt after dma buffer initialization
On Mon, 08 Oct 2018 11:34:12 +0200,
Mark Brown wrote:
>
> On Fri, Oct 05, 2018 at 12:14:03PM -0400, Sasha Levin wrote:
> > From: Yu Zhao
> >
> > [ Upstream commit b61749a89f826eb61fc59794d9e4697bd246eb61 ]
> >
> > In snd_hdac_bus_init_chip(), we enable interrupt before
> > snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
> > been acquired and irq handler uses the dma buffer, kernel may crash
> > when interrupt comes in.
>
> CCing Takashi who's the maintainer here for review.
This is OK to take as a stable. This shouldn't break, at least.
thanks,
Takashi
> >
> > Fix the problem by postponing enabling irq after dma buffer
> > initialization. And warn once on null dma buffer pointer during the
> > initialization.
> >
> > Reviewed-by: Takashi Iwai
> > Signed-off-by: Yu Zhao
> > Signed-off-by: Mark Brown
> > Signed-off-by: Sasha Levin
> > ---
> > sound/hda/hdac_controller.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
> > index 560ec0986e1a..11057d9f84ec 100644
> > --- a/sound/hda/hdac_controller.c
> > +++ b/sound/hda/hdac_controller.c
> > @@ -40,6 +40,8 @@ static void azx_clear_corbrp(struct hdac_bus *bus)
> > */
> > void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus)
> > {
> > + WARN_ON_ONCE(!bus->rb.area);
> > +
> > spin_lock_irq(>reg_lock);
> > /* CORB set up */
> > bus->corb.addr = bus->rb.addr;
> > @@ -479,13 +481,15 @@ bool snd_hdac_bus_init_chip(struct hdac_bus *bus,
> > bool full_reset)
> > /* reset controller */
> > azx_reset(bus, full_reset);
> >
> > - /* initialize interrupts */
> > + /* clear interrupts */
> > azx_int_clear(bus);
> > - azx_int_enable(bus);
> >
> > /* initialize the codec command I/O */
> > snd_hdac_bus_init_cmd_io(bus);
> >
> > + /* enable interrupts after CORB/RIRB buffers are initialized above */
> > + azx_int_enable(bus);
> > +
> > /* program the position buffer */
> > if (bus->use_posbuf && bus->posbuf.addr) {
> > snd_hdac_chip_writel(bus, DPLBASE, (u32)bus->posbuf.addr);
> > --
> > 2.17.1
> >
> [2 signature.asc ]
>
[tip:x86/asm] x86/vdso: Introduce helper functions for CPU and node number
Commit-ID: ffebbaedc8616cffe648202e364dce6a045d65a2
Gitweb: https://git.kernel.org/tip/ffebbaedc8616cffe648202e364dce6a045d65a2
Author: Chang S. Bae
AuthorDate: Tue, 18 Sep 2018 16:08:58 -0700
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:41:10 +0200
x86/vdso: Introduce helper functions for CPU and node number
Clean up the CPU/node number related code a bit, to make it more apparent
how we are encoding/extracting the CPU and node fields from the
segment limit.
No change in functionality intended.
[ mingo: Wrote new changelog. ]
Suggested-by: Andy Lutomirski
Suggested-by: Thomas Gleixner
Signed-off-by: Chang S. Bae
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Markus T Metzger
Cc: Peter Zijlstra
Cc: Ravi Shankar
Cc: Rik van Riel
Link:
http://lkml.kernel.org/r/1537312139-5580-8-git-send-email-chang.seok@intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/entry/vdso/vgetcpu.c | 9 +
arch/x86/entry/vdso/vma.c | 19 +++
arch/x86/include/asm/segment.h | 41 +
arch/x86/include/asm/vgtod.h | 26 --
4 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/arch/x86/entry/vdso/vgetcpu.c b/arch/x86/entry/vdso/vgetcpu.c
index 8ec3d1f4ce9a..de78fc9cd963 100644
--- a/arch/x86/entry/vdso/vgetcpu.c
+++ b/arch/x86/entry/vdso/vgetcpu.c
@@ -13,14 +13,7 @@
notrace long
__vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused)
{
- unsigned int p;
-
- p = __getcpu();
-
- if (cpu)
- *cpu = p & VGETCPU_CPU_MASK;
- if (node)
- *node = p >> 12;
+ vdso_read_cpu_node(cpu, node);
return 0;
}
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 0b114aafcedc..39b5584c5808 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -339,20 +339,15 @@ static void vgetcpu_cpu_init(void *arg)
{
int cpu = smp_processor_id();
struct desc_struct d = { };
- unsigned long node = 0;
-#ifdef CONFIG_NUMA
- node = cpu_to_node(cpu);
-#endif
+ unsigned long cpudata = vdso_encode_cpu_node(cpu, cpu_to_node(cpu));
+
if (static_cpu_has(X86_FEATURE_RDTSCP))
- write_rdtscp_aux((node << 12) | cpu);
+ write_rdtscp_aux(cpudata);
+
+ /* Store CPU and node number in limit */
+ d.limit0 = cpudata;
+ d.limit1 = cpudata >> 16;
- /*
-* Store cpu number in limit so that it can be loaded
-* quickly in user space in vgetcpu. (12 bits for the CPU
-* and 8 bits for the node)
-*/
- d.limit0 = cpu | ((node & 0xf) << 12);
- d.limit1 = node >> 4;
d.type = 5; /* RO data, expand down, accessed */
d.dpl = 3; /* Visible to user code */
d.s = 1;/* Not a system segment */
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index e3e788ea52e5..4d1f6cc62e13 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -224,6 +224,47 @@
#define GDT_ENTRY_TLS_ENTRIES 3
#define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES* 8)
+#ifdef CONFIG_X86_64
+
+/* Bit size and mask of CPU number stored in the per CPU data (and TSC_AUX) */
+#define VDSO_CPU_SIZE 12
+#define VDSO_CPU_MASK 0xfff
+
+#ifndef __ASSEMBLY__
+
+/* Helper functions to store/load CPU and node numbers */
+
+static inline unsigned long vdso_encode_cpu_node(int cpu, unsigned long node)
+{
+ return ((node << VDSO_CPU_SIZE) | cpu);
+}
+
+static inline void vdso_read_cpu_node(unsigned *cpu, unsigned *node)
+{
+ unsigned int p;
+
+ /*
+* Load CPU and node number from GDT. LSL is faster than RDTSCP
+* and works on all CPUs. This is volatile so that it orders
+* correctly with respect to barrier() and to keep GCC from cleverly
+* hoisting it out of the calling function.
+*
+* If RDPID is available, use it.
+*/
+ alternative_io ("lsl %[seg],%[p]",
+ ".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */
+ X86_FEATURE_RDPID,
+ [p] "=a" (p), [seg] "r" (__CPU_NUMBER_SEG));
+
+ if (cpu)
+ *cpu = (p & VDSO_CPU_MASK);
+ if (node)
+ *node = (p >> VDSO_CPU_SIZE);
+}
+
+#endif /* !__ASSEMBLY__ */
+#endif /* CONFIG_X86_64 */
+
#ifdef __KERNEL__
/*
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 4e81ea920722..056a61c8c5c7 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -77,30 +77,4 @@ static inline void gtod_write_end(struct vsyscall_gtod_data
*s)
++s->seq;
}
-#ifdef CONFIG_X86_64
-
-#define VGETCPU_CPU_MASK 0xfff
-
-static inline
Re: [PATCH v6 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
Hi Pranith,
On Sat, Jul 7, 2018 at 11:22 AM Pranith Kumar wrote:
>
> Hi Ganapatrao,
>
>
> On Wed, Jun 20, 2018 at 11:33 PM, Ganapatrao Kulkarni
> wrote:
>
> > +
> > +enum thunderx2_uncore_l3_events {
> > + L3_EVENT_NONE,
> > + L3_EVENT_NBU_CANCEL,
> > + L3_EVENT_DIB_RETRY,
> > + L3_EVENT_DOB_RETRY,
> > + L3_EVENT_DIB_CREDIT_RETRY,
> > + L3_EVENT_DOB_CREDIT_RETRY,
> > + L3_EVENT_FORCE_RETRY,
> > + L3_EVENT_IDX_CONFLICT_RETRY,
> > + L3_EVENT_EVICT_CONFLICT_RETRY,
> > + L3_EVENT_BANK_CONFLICT_RETRY,
> > + L3_EVENT_FILL_ENTRY_RETRY,
> > + L3_EVENT_EVICT_NOT_READY_RETRY,
> > + L3_EVENT_L3_RETRY,
> > + L3_EVENT_READ_REQ,
> > + L3_EVENT_WRITE_BACK_REQ,
> > + L3_EVENT_INVALIDATE_NWRITE_REQ,
> > + L3_EVENT_INV_REQ,
> > + L3_EVENT_SELF_REQ,
> > + L3_EVENT_REQ,
> > + L3_EVENT_EVICT_REQ,
> > + L3_EVENT_INVALIDATE_NWRITE_HIT,
> > + L3_EVENT_INVALIDATE_HIT,
> > + L3_EVENT_SELF_HIT,
> > + L3_EVENT_READ_HIT,
> > + L3_EVENT_MAX,
> > +};
> > +
> > +enum thunderx2_uncore_dmc_events {
> > + DMC_EVENT_NONE,
> > + DMC_EVENT_COUNT_CYCLES,
> > + DMC_EVENT_RES2,
> > + DMC_EVENT_RES3,
> > + DMC_EVENT_RES4,
> > + DMC_EVENT_RES5,
> > + DMC_EVENT_RES6,
> > + DMC_EVENT_RES7,
> > + DMC_EVENT_RES8,
> > + DMC_EVENT_READ_64B_TXNS,
> > + DMC_EVENT_READ_BELOW_64B_TXNS,
> > + DMC_EVENT_WRITE_TXNS,
> > + DMC_EVENT_TXN_CYCLES,
> > + DMC_EVENT_DATA_TRANSFERS,
> > + DMC_EVENT_CANCELLED_READ_TXNS,
> > + DMC_EVENT_CONSUMED_READ_TXNS,
> > + DMC_EVENT_MAX,
> > +};
>
> Can you please provide a link to where these counters are documented?
> It is not clear what each counter does especially for the L3C events.
I will add brief description of each event in Documentation.
>
> Also, what counter do you need to use to get L3 hit/miss ratio? I
> think this is the most useful counter related to L3.
L3C cache Hit Ratio = (L3_READ_HIT + L3_INV_N_WRITE_HIT +
L3_INVALIDATE_HIT) / (L3_READ_REQ + L3_INV_N_WRITE_REQ +
L3_INVALIDATE_REQ)
>
> Thanks,
> --
> Pranith
thanks
Ganapat
[tip:x86/asm] x86/vdso: Initialize the CPU/node NR segment descriptor earlier
Commit-ID: b2e2ba578e016a091eb31565849990fe68c7c599
Gitweb: https://git.kernel.org/tip/b2e2ba578e016a091eb31565849990fe68c7c599
Author: Chang S. Bae
AuthorDate: Tue, 18 Sep 2018 16:08:59 -0700
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:41:10 +0200
x86/vdso: Initialize the CPU/node NR segment descriptor earlier
Currently the CPU/node NR segment descriptor (GDT_ENTRY_CPU_NUMBER) is
initialized relatively late during CPU init, from the vCPU code, which
has a number of disadvantages, such as hotplug CPU notifiers and SMP
cross-calls.
Instead just initialize it much earlier, directly in cpu_init().
This reduces complexity and increases robustness.
[ mingo: Wrote new changelog. ]
Suggested-by: H. Peter Anvin
Suggested-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Linus Torvalds
Cc: Markus T Metzger
Cc: Peter Zijlstra
Cc: Ravi Shankar
Cc: Rik van Riel
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1537312139-5580-9-git-send-email-chang.seok@intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/entry/vdso/vma.c| 33 +
arch/x86/kernel/cpu/common.c | 24
2 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 39b5584c5808..3f9d43f26f63 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -332,35 +332,6 @@ static __init int vdso_setup(char *s)
return 0;
}
__setup("vdso=", vdso_setup);
-#endif
-
-#ifdef CONFIG_X86_64
-static void vgetcpu_cpu_init(void *arg)
-{
- int cpu = smp_processor_id();
- struct desc_struct d = { };
- unsigned long cpudata = vdso_encode_cpu_node(cpu, cpu_to_node(cpu));
-
- if (static_cpu_has(X86_FEATURE_RDTSCP))
- write_rdtscp_aux(cpudata);
-
- /* Store CPU and node number in limit */
- d.limit0 = cpudata;
- d.limit1 = cpudata >> 16;
-
- d.type = 5; /* RO data, expand down, accessed */
- d.dpl = 3; /* Visible to user code */
- d.s = 1;/* Not a system segment */
- d.p = 1;/* Present */
- d.d = 1;/* 32-bit */
-
- write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_CPU_NUMBER, ,
DESCTYPE_S);
-}
-
-static int vgetcpu_online(unsigned int cpu)
-{
- return smp_call_function_single(cpu, vgetcpu_cpu_init, NULL, 1);
-}
static int __init init_vdso(void)
{
@@ -370,9 +341,7 @@ static int __init init_vdso(void)
init_vdso_image(_image_x32);
#endif
- /* notifier priority > KVM */
- return cpuhp_setup_state(CPUHP_AP_X86_VDSO_VMA_ONLINE,
-"x86/vdso/vma:online", vgetcpu_online, NULL);
+ return 0;
}
subsys_initcall(init_vdso);
#endif /* CONFIG_X86_64 */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 44c4ef3d989b..a148d18a1ef0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1669,6 +1669,29 @@ static void wait_for_master_cpu(int cpu)
#endif
}
+#ifdef CONFIG_X86_64
+static void setup_getcpu(int cpu)
+{
+ unsigned long cpudata = vdso_encode_cpu_node(cpu,
early_cpu_to_node(cpu));
+ struct desc_struct d = { };
+
+ if (static_cpu_has(X86_FEATURE_RDTSCP))
+ write_rdtscp_aux(cpudata);
+
+ /* Store CPU and node number in limit. */
+ d.limit0 = cpudata;
+ d.limit1 = cpudata >> 16;
+
+ d.type = 5; /* RO data, expand down, accessed */
+ d.dpl = 3; /* Visible to user code */
+ d.s = 1;/* Not a system segment */
+ d.p = 1;/* Present */
+ d.d = 1;/* 32-bit */
+
+ write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_CPU_NUMBER, ,
DESCTYPE_S);
+}
+#endif
+
/*
* cpu_init() initializes state that is per-CPU. Some data is already
* initialized (naturally) in the bootstrap process, such as the GDT
@@ -1706,6 +1729,7 @@ void cpu_init(void)
early_cpu_to_node(cpu) != NUMA_NO_NODE)
set_numa_node(early_cpu_to_node(cpu));
#endif
+ setup_getcpu(cpu);
me = current;
RE: [PATCH 1/1] MAINTAINERS: imx: include drivers/firmware/imx path
> > diff --git a/MAINTAINERS b/MAINTAINERS index 9ad052a..d1fb824 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -1462,6 +1462,7 @@ F:arch/arm/mach-mxs/ > > F: arch/arm/boot/dts/imx* > > F: arch/arm/configs/imx*_defconfig > > F: drivers/clk/imx/ > > +F: drivers/firmware/imx/ > > Please add include/linux/firmware/imx/ too. > Sorry for missing it. Will update now. Regards Dong Aisheng > Shawn > > > F: drivers/soc/imx/ > > F: include/soc/imx/ > > > > -- > > 2.7.4 > >
Re: [PATCH v8 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On Mon, Oct 08, 2018 at 03:29:52PM +0530, Viresh Kumar wrote: > On 08-10-18, 10:40, Niklas Cassel wrote: > > > + ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain", > > > + "#freq-domain-cells", 0, ); > > > > Hello Taniya, > > > > in your DT binding, you use > > > > #freq-domains-cells = <1> > > > > Yet here you parse for "#freq-domain-cells". > > And what is the problem with that ? Or are you suggesting her to call > of_parse_phandle_with_fixed_args() ? Hello Viresh, #freq-domain-cells != #freq-domains-cells The code should parse for the exact same property name as stated in the DT binding. Kind regards, Niklas
Re: [PATCH v8 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On 10/8/2018 4:08 PM, Niklas Cassel wrote: On Mon, Oct 08, 2018 at 03:29:52PM +0530, Viresh Kumar wrote: On 08-10-18, 10:40, Niklas Cassel wrote: + ret = of_parse_phandle_with_args(cpu_np, "qcom,freq-domain", + "#freq-domain-cells", 0, ); Hello Taniya, in your DT binding, you use #freq-domains-cells = <1> Yet here you parse for "#freq-domain-cells". And what is the problem with that ? Or are you suggesting her to call of_parse_phandle_with_fixed_args() ? Hello Viresh, #freq-domain-cells != #freq-domains-cells The code should parse for the exact same property name as stated in the DT binding. Kind regards, Niklas The extra 's' was a typo, would fix it in the next patch. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. --
Re: [PATCH v11 2/3]: perf record: enable asynchronous trace writing
On Mon, Oct 08, 2018 at 09:17:11AM +0300, Alexey Budankov wrote:
SNIP
> static int record__mmap_read_evlist(struct record *rec, struct perf_evlist
> *evlist,
> bool overwrite)
> {
> @@ -520,7 +644,10 @@ static int record__mmap_read_evlist(struct record *rec,
> struct perf_evlist *evli
> int i;
> int rc = 0;
> struct perf_mmap *maps;
> -
> +#ifdef HAVE_AIO_SUPPORT
> + int trace_fd = rec->data.file.fd;
> + off_t off;
> +#endif
> if (!evlist)
> return 0;
>
> @@ -531,14 +658,34 @@ static int record__mmap_read_evlist(struct record *rec,
> struct perf_evlist *evli
> if (overwrite && evlist->bkw_mmap_state != BKW_MMAP_DATA_PENDING)
> return 0;
>
> +#ifdef HAVE_AIO_SUPPORT
> + off = lseek(trace_fd, 0, SEEK_CUR);
> +#endif
> for (i = 0; i < evlist->nr_mmaps; i++) {
> struct perf_mmap *map = [i];
>
> if (map->base) {
> - if (perf_mmap__push(map, rec, record__pushfn) != 0) {
> - rc = -1;
> - goto out;
> +#ifdef HAVE_AIO_SUPPORT
> + if (!rec->opts.nr_cblocks) {
> +#endif
maybe it'd be less confusing having something like
rec->opts.aio.enabled
or aio__is_enabled() global with the dummy counterpart
jirka
Re: [PATCH] KVM: LAPIC: Tune lapic_timer_advance_ns automatically
On Mon, 8 Oct 2018 at 05:02, Liran Alon wrote:
>
>
>
> > On 28 Sep 2018, at 9:12, Wanpeng Li wrote:
> >
> > From: Wanpeng Li
> >
> > In cloud environment, lapic_timer_advance_ns is needed to be tuned for
> > every CPU
> > generations, and every host kernel versions(the
> > kvm-unit-tests/tscdeadline_latency.flat
> > is 5700 cycles for upstream kernel and 9600 cycles for our 3.10 product
> > kernel,
> > both preemption_timer=N, Skylake server).
> >
> > This patch adds the capability to automatically tune lapic_timer_advance_ns
> > step by step, the initial value is 1000ns as d0659d946be05 (KVM: x86: add
> > option to advance tscdeadline hrtimer expiration) recommended, it will be
> > reduced when it is too early, and increased when it is too late. The
> > guest_tsc
> > and tsc_deadline are hard to equal, so we assume we are done when the delta
> > is within a small scope e.g. 100 cycles. This patch reduces latency
> > (kvm-unit-tests/tscdeadline_latency, busy waits, preemption_timer enabled)
> > from ~2600 cyles to ~1200 cyles on our Skylake server.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/kvm/lapic.c | 7 +++
> > arch/x86/kvm/x86.c | 2 +-
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index fbb0e6d..b756f12 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -70,6 +70,8 @@
> > #define APIC_BROADCAST0xFF
> > #define X2APIC_BROADCAST 0xul
> >
> > +static bool __read_mostly lapic_timer_advance_adjust_done = false;
> > +
> > static inline int apic_test_vector(int vec, void *bitmap)
> > {
> > return test_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
> > @@ -1492,6 +1494,11 @@ void wait_lapic_expire(struct kvm_vcpu *vcpu)
> > if (guest_tsc < tsc_deadline)
> > __delay(min(tsc_deadline - guest_tsc,
> > nsec_to_cycles(vcpu, lapic_timer_advance_ns)));
> > + if (!lapic_timer_advance_adjust_done) {
> > + lapic_timer_advance_ns += (s64)(guest_tsc - tsc_deadline) / 8;
>
> I don’t understand how this “/ 8” converts between guest TSC units to host
> nanoseconds.
Oh, I miss it. In addition, /8 here I mean adjust
lapic_timer_advance_ns step by step. I can observe big fluctuated
value between early and late when running real guest os like linux
instead of kvm-unit-tests. After more testing, I saw
lapic_timer_advance_ns can be overflow since the delta between
guest_tsc and tsc_deadline is too huge.
>
> I think that instead you should do something like:
> s64 ns = (s64)(guest_tsc - tsc_deadline) * 100ULL;
> do_div(ns, vcpu->arch.virtual_tsc_khz);
> lapic_timer_advance_ns += ns;
>
> > + if (abs(guest_tsc - tsc_deadline) < 100)
>
> I would put this “100” hard-coded value as some “#define” to make code more
> clear.
How about something like below:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index fbb0e6d..354eb13c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -70,6 +70,9 @@
#define APIC_BROADCAST0xFF
#define X2APIC_BROADCAST0xul
+static bool __read_mostly lapic_timer_advance_adjust_done = false;
+#define LAPIC_TIMER_ADVANCE_ADJUST_DONE 100
+
static inline int apic_test_vector(int vec, void *bitmap)
{
return test_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
@@ -1472,7 +1475,7 @@ static bool lapic_timer_int_injected(struct
kvm_vcpu *vcpu)
void wait_lapic_expire(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *apic = vcpu->arch.apic;
-u64 guest_tsc, tsc_deadline;
+u64 guest_tsc, tsc_deadline, ns;
if (!lapic_in_kernel(vcpu))
return;
@@ -1492,6 +1495,19 @@ void wait_lapic_expire(struct kvm_vcpu *vcpu)
if (guest_tsc < tsc_deadline)
__delay(min(tsc_deadline - guest_tsc,
nsec_to_cycles(vcpu, lapic_timer_advance_ns)));
+if (!lapic_timer_advance_adjust_done) {
+if (guest_tsc < tsc_deadline) {
+ns = (tsc_deadline - guest_tsc) * 100ULL;
+do_div(ns, vcpu->arch.virtual_tsc_khz);
+lapic_timer_advance_ns -= min((unsigned int)ns,
lapic_timer_advance_ns / 8);
+} else {
+ns = (guest_tsc - tsc_deadline) * 100ULL;
+do_div(ns, vcpu->arch.virtual_tsc_khz);
+lapic_timer_advance_ns += min((unsigned int)ns,
lapic_timer_advance_ns / 8);
+}
+if (ns < LAPIC_TIMER_ADVANCE_ADJUST_DONE)
+lapic_timer_advance_adjust_done = true;
+}
}
static void start_sw_tscdeadline(struct kvm_lapic *apic)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ca71773..1f3f955 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -136,7 +136,7 @@ static u32 __read_mostly tsc_tolerance_ppm = 250;
module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR);
/* lapic timer advance (tscdeadline mode only) in nanoseconds */
Re: [RFC v3 1/1] ns: add binfmt_misc to the user namespace
On Sat, Oct 6, 2018 at 8:04 AM Andrei Vagin wrote:
> On Thu, Oct 04, 2018 at 12:50:22AM +0200, Laurent Vivier wrote:
> > This patch allows to have a different binfmt_misc configuration
> > for each new user namespace. By default, the binfmt_misc configuration
> > is the one of the host, but if the binfmt_misc filesystem is mounted
> > in the new namespace a new empty binfmt instance is created and used
> > in this namespace.
> >
> > For instance, using "unshare" we can start a chroot of an another
> > architecture and configure the binfmt_misc interpreter without being root
> > to run the binaries in this chroot.
> >
> > Signed-off-by: Laurent Vivier
> > ---
> > fs/binfmt_misc.c | 85 +++---
> > include/linux/user_namespace.h | 15 ++
> > kernel/user.c | 14 ++
> > kernel/user_namespace.c| 9
> > 4 files changed, 95 insertions(+), 28 deletions(-)
> >
> > diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> > index aa4a7a23ff99..78780bc87506 100644
> > --- a/fs/binfmt_misc.c
> > +++ b/fs/binfmt_misc.c
> > @@ -38,9 +38,6 @@ enum {
> > VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
> > };
> >
> > -static LIST_HEAD(entries);
> > -static int enabled = 1;
> > -
> > enum {Enabled, Magic};
> > #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
> > #define MISC_FMT_OPEN_BINARY (1 << 30)
> > @@ -60,10 +57,7 @@ typedef struct {
> > struct file *interp_file;
> > } Node;
> >
> > -static DEFINE_RWLOCK(entries_lock);
> > static struct file_system_type bm_fs_type;
> > -static struct vfsmount *bm_mnt;
> > -static int entry_count;
> >
> > /*
> > * Max length of the register string. Determined by:
> > @@ -85,13 +79,13 @@ static int entry_count;
> > * if we do, return the node, else NULL
> > * locking is done in load_misc_binary
> > */
> > -static Node *check_file(struct linux_binprm *bprm)
> > +static Node *check_file(struct user_namespace *ns, struct linux_binprm
> > *bprm)
> > {
> > char *p = strrchr(bprm->interp, '.');
> > struct list_head *l;
> >
> > /* Walk all the registered handlers. */
> > - list_for_each(l, ) {
> > + list_for_each(l, >binfmt_ns->entries) {
> > Node *e = list_entry(l, Node, list);
> > char *s;
> > int j;
> > @@ -133,17 +127,18 @@ static int load_misc_binary(struct linux_binprm *bprm)
> > struct file *interp_file = NULL;
> > int retval;
> > int fd_binary = -1;
> > + struct user_namespace *ns = current_user_ns();
> >
> > retval = -ENOEXEC;
> > - if (!enabled)
> > + if (!ns->binfmt_ns->enabled)
> > return retval;
> >
> > /* to keep locking time low, we copy the interpreter string */
> > - read_lock(_lock);
> > - fmt = check_file(bprm);
> > + read_lock(>binfmt_ns->entries_lock);
>
> It looks like ns->binfmt_ns isn't protected by any lock and
> ns->binfmt_ns can be changed between read_lock() and read_unlock().
>
> This can be fixed if ns->binfmt_ns will be dereferenced only once in
> this function:
>
> struct binfmt_namespace *binfmt_ns = ns->binfmt_ns;
Technically, wouldn't you want READ_ONCE(ns->binfmt_ns)?
[PATCH] lib/vsprintf: Remove %pCr remnant in comment
Support for "%pCr" was removed, but a reference in a comment was
forgotten.
Fixes: 666902e42fd8344b ("lib/vsprintf: Remove atomic-unsafe support for %pCr")
Signed-off-by: Geert Uytterhoeven
---
Probably this wasn't noticed due to commit 5e4ee7b13b522d07 ("printk:
synchronize %p formatting documentation") removing another reference.
---
lib/vsprintf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index b1909ca755932539..095a677f89c02442 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1832,7 +1832,6 @@ static char *ptr_to_id(char *buf, char *end, void *ptr,
struct printf_spec spec)
* (legacy clock framework) of the clock
* - 'Cn' For a clock, it prints the name (Common Clock Framework) or address
*(legacy clock framework) of the clock
- * - 'Cr' For a clock, it prints the current rate of the clock
* - 'G' For flags to be printed as a collection of symbolic strings that would
* construct the specific value. Supported flags given by option:
* p page flags (see struct page) given as pointer to unsigned long
--
2.17.1
linux-next: manual merge of the akpm tree with the jc_docs tree
Hi all,
Today's linux-next merge of the akpm tree got conflicts in:
Documentation/memory-hotplug.txt
Documentation/admin-guide/mm/memory-hotplug.rst
between commits:
6bf53999a3a2 ("docs: move memory hotplug description into admin-guide/mm")
98cee6742c80 ("docs/vm: split memory hotplug notifier description to
Documentation/core-api")
from the jc_docs tree and patch:
"memory-hotplug.txt: add some details about locking internals"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/admin-guide/mm/memory-hotplug.rst
index 0b9c83effaa4,ce4faa5530fa..
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@@ -413,6 -413,128 +413,46 @@@ Need more implementation yet...
- Notification completion of remove works by OS to firmware.
- Guard from remove if not yet.
-Memory hotplug event notifier
-=
-
-Hotplugging events are sent to a notification queue.
-
-There are six types of notification defined in include/linux/memory.h:
-
-MEM_GOING_ONLINE
- Generated before new memory becomes available in order to be able to
- prepare subsystems to handle memory. The page allocator is still unable
- to allocate from the new memory.
-
-MEM_CANCEL_ONLINE
- Generated if MEMORY_GOING_ONLINE fails.
-
-MEM_ONLINE
- Generated when memory has successfully brought online. The callback may
- allocate pages from the new memory.
-
-MEM_GOING_OFFLINE
- Generated to begin the process of offlining memory. Allocations are no
- longer possible from the memory but some of the memory to be offlined
- is still in use. The callback can be used to free memory known to a
- subsystem from the indicated memory block.
-
-MEM_CANCEL_OFFLINE
- Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from
- the memory block that we attempted to offline.
-
-MEM_OFFLINE
- Generated after offlining memory is complete.
-
-A callback routine can be registered by calling::
-
- hotplug_memory_notifier(callback_func, priority)
-
-Callback functions with higher values of priority are called before callback
-functions with lower values.
-
-A callback function must have the following prototype::
-
- int callback_func(
-struct notifier_block *self, unsigned long action, void *arg);
-
-The first argument of the callback function (self) is a pointer to the block
-of the notifier chain that points to the callback function itself.
-The second argument (action) is one of the event types described above.
-The third argument (arg) passes a pointer of struct memory_notify::
-
- struct memory_notify {
- unsigned long start_pfn;
- unsigned long nr_pages;
- int status_change_nid_normal;
- int status_change_nid_high;
- int status_change_nid;
- }
-
-- start_pfn is start_pfn of online/offline memory.
-- nr_pages is # of pages of online/offline memory.
-- status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
- is (will be) set/clear, if this is -1, then nodemask status is not changed.
-- status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask
- is (will be) set/clear, if this is -1, then nodemask status is not changed.
-- status_change_nid is set node id when N_MEMORY of nodemask is (will be)
- set/clear. It means a new(memoryless) node gets new memory by online and a
- node loses all memory. If this is -1, then nodemask status is not changed.
-
- If status_changed_nid* >= 0, callback should create/discard structures for
the
- node if necessary.
-
-The callback routine shall return one of the values
-NOTIFY_DONE, NOTIFY_OK, NOTIFY_BAD, NOTIFY_STOP
-defined in include/linux/notifier.h
-
-NOTIFY_DONE and NOTIFY_OK have no effect on the further processing.
-
-NOTIFY_BAD is used as response to the MEM_GOING_ONLINE, MEM_GOING_OFFLINE,
-MEM_ONLINE, or MEM_OFFLINE action to cancel hotplugging. It stops
-further processing of the notification queue.
-
-NOTIFY_STOP stops further processing of the notification queue.
-
+
+ Locking Internals
+ =
+
+ When adding/removing memory that uses memory block devices (i.e. ordinary
RAM),
+ the device_hotplug_lock should be held to:
+
+ - synchronize against online/offline requests (e.g. via sysfs). This way,
memory
+ block devices can only be accessed (.online/.state attributes) by user
+ space once memory has been fully added. And when removing memory, we
+ know nobody is in critical sections.
+ -
Re: [PATCH 1/1] MAINTAINERS: imx: include drivers/firmware/imx path
On Sun, Oct 07, 2018 at 09:24:17PM +0800, Dong Aisheng wrote: > Due to newly added IMX SCU firmware support, let's add > drivers/firmware/imx into maintainership. > > Cc: Shawn Guo > Cc: Arnd Bergmann > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Dong Aisheng > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9ad052a..d1fb824 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1462,6 +1462,7 @@ F: arch/arm/mach-mxs/ > F: arch/arm/boot/dts/imx* > F: arch/arm/configs/imx*_defconfig > F: drivers/clk/imx/ > +F: drivers/firmware/imx/ Please add include/linux/firmware/imx/ too. Shawn > F: drivers/soc/imx/ > F: include/soc/imx/ > > -- > 2.7.4 >
Re: [PATCH v3] spi: spi-ep93xx: Use dma_data_direction for ep93xx_spi_dma_{finish,prepare}
On Fri, Oct 05, 2018 at 12:25:09PM -0700, Nathan Chancellor wrote:
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
> enumeration type 'enum dma_transfer_direction' to different enumeration
> type 'enum dma_data_direction' [-Wenum-conversion]
> nents = dma_map_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
> ^~~~
> ./include/linux/dma-mapping.h:428:58: note: expanded from macro
> 'dma_map_sg'
> #define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, 0)
> ^
> drivers/spi/spi-ep93xx.c:348:57: warning: implicit conversion from
> enumeration type 'enum dma_transfer_direction' to different enumeration
> type 'enum dma_data_direction' [-Wenum-conversion]
> dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
> ~~^~~~
> ./include/linux/dma-mapping.h:429:62: note: expanded from macro
> 'dma_unmap_sg'
> #define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
> ~~ ^
> drivers/spi/spi-ep93xx.c:377:56: warning: implicit conversion from
> enumeration type 'enum dma_transfer_direction' to different enumeration
> type 'enum dma_data_direction' [-Wenum-conversion]
> dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
> ~~^~~~
> ./include/linux/dma-mapping.h:429:62: note: expanded from macro
> 'dma_unmap_sg'
> #define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
> ~~ ^
> 3 warnings generated.
>
> dma_{,un}map_sg expect an enum of type dma_data_direction but this
> driver uses dma_transfer_direction for everything. Convert the driver to
> use dma_data_direction for these two functions.
>
> There are two places that strictly require an enum of type
> dma_transfer_direction: the direction member in struct dma_slave_config
> and the direction parameter in dmaengine_prep_slave_sg. To avoid using
> an explicit cast, add a simple function, ep93xx_dma_data_to_trans_dir,
> to safely map between the two types because they are not 1 to 1 in
> meaning.
>
> Signed-off-by: Nathan Chancellor
Looks good to me,
Reviewed-by: Mika Westerberg
Re: [PATCH RFC 1/1] hugetlbfs: introduce truncation/fault mutex to avoid races
On Sun, Oct 07, 2018 at 04:38:48PM -0700, Mike Kravetz wrote: > The following hugetlbfs truncate/page fault race can be recreated > with programs doing something like the following. > > A huegtlbfs file is mmap(MAP_SHARED) with a size of 4 pages. At > mmap time, 4 huge pages are reserved for the file/mapping. So, > the global reserve count is 4. In addition, since this is a shared > mapping an entry for 4 pages is added to the file's reserve map. > The first 3 of the 4 pages are faulted into the file. As a result, > the global reserve count is now 1. > > Task A starts to fault in the last page (routines hugetlb_fault, > hugetlb_no_page). It allocates a huge page (alloc_huge_page). > The reserve map indicates there is a reserved page, so this is > used and the global reserve count goes to 0. > > Now, task B truncates the file to size 0. It starts by setting > inode size to 0(hugetlb_vmtruncate). It then unmaps all mapping > of the file (hugetlb_vmdelete_list). Since task A's page table > lock is not held at the time, truncation is not blocked. Truncation > removes the 3 pages from the file (remove_inode_hugepages). When > cleaning up the reserved pages (hugetlb_unreserve_pages), it notices > the reserve map was for 4 pages. However, it has only freed 3 pages. > So it assumes there is still (4 - 3) 1 reserved pages. It then > decrements the global reserve count by 1 and it goes negative. > > Task A then continues the page fault process and adds it's newly > acquired page to the page cache. Note that the index of this page > is beyond the size of the truncated file (0). The page fault process > then notices the file has been truncated and exits. However, the > page is left in the cache associated with the file. > > Now, if the file is immediately deleted the truncate code runs again. > It will find and free the one page associated with the file. When > cleaning up reserves, it notices the reserve map is empty. Yet, one > page freed. So, the global reserve count is decremented by (0 - 1) -1. > This returns the global count to 0 as it should be. But, it is > possible for someone else to mmap this file/range before it is deleted. > If this happens, a reserve map entry for the allocated page is created > and the reserved page is forever leaked. > > To avoid all these conditions, let's simply prevent faults to a file > while it is being truncated. Add a new truncation specific rw mutex > to hugetlbfs inode extensions. faults take the mutex in read mode, > truncation takes in write mode. Hm. Don't we have already a lock for this? I mean i_mmap_lock. -- Kirill A. Shutemov
[PATCH 02/10] swiotlb: mark is_swiotlb_buffer static
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 1 -
kernel/dma/swiotlb.c| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 965be92c33b5..7ef541ce8f34 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -121,7 +121,6 @@ static inline unsigned int swiotlb_max_segment(void) {
return 0; }
#endif
extern void swiotlb_print_info(void);
-extern int is_swiotlb_buffer(phys_addr_t paddr);
extern void swiotlb_set_max_segment(unsigned int);
extern const struct dma_map_ops swiotlb_dma_ops;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9062b14bc7f4..26d3af52956f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -429,7 +429,7 @@ void __init swiotlb_exit(void)
max_segment = 0;
}
-int is_swiotlb_buffer(phys_addr_t paddr)
+static int is_swiotlb_buffer(phys_addr_t paddr)
{
return paddr >= io_tlb_start && paddr < io_tlb_end;
}
--
2.19.0
Re: [PATCH] md/bitmap: use mddev_suspend/resume instead of ->quiesce()
On Fri, Sep 28, 2018 at 8:30 PM Shaohua Li wrote:
>
> On Thu, Sep 27, 2018 at 10:07:57AM +0200, Jack Wang wrote:
> > From: Jack Wang
> >
> > After 9e1cc0a54556 ("md: use mddev_suspend/resume instead of ->quiesce()")
> > We still have similar left in bitmap functions.
> >
> > Replace quiesce() with mddev_suspend/resume.
> >
> > Also move md_bitmap_create out of mddev_suspend. and move mddev_resume
> > after md_bitmap_destroy. as we did in set_bitmap_file.
> >
> > Signed-off-by: Jack Wang
> > Reviewed-by: Gioh Kim
> >
> > ---
> > v2->v1: add reviewed-by.
> > ---
> > drivers/md/md-bitmap.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
> > index 2fc8c113977f..c369f1753ea6 100644
> > --- a/drivers/md/md-bitmap.c
> > +++ b/drivers/md/md-bitmap.c
> > @@ -2123,7 +2123,7 @@ int md_bitmap_resize(struct bitmap *bitmap, sector_t
> > blocks,
> > }
> >
> > if (!init)
> > - bitmap->mddev->pers->quiesce(bitmap->mddev, 1);
> > + mddev_suspend(bitmap->mddev);
>
>
> mddev_suspend is supposed to be called with reconfig_mutex hold. At least one
> place this isn't true with this change, for example, raid_preresume doesn't
> call md_bitmap_resize with the lock hold. Could you please double check the
> lock usage?
You're right, I missed this one, will double check.
Thanks for review!
--
Jack Wang
Linux Kernel Developer
ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Tel: +49 30 577 008 042
Fax: +49 30 577 008 299
Email:jinpu.w...@profitbricks.com
URL: https://www.profitbricks.de
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm
On 2018/10/08 17:38, Yong-Taek Lee wrote:
>>
>> On 2018/10/08 15:14, Yong-Taek Lee wrote:
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> + int mm_users = 0;
>
> task = get_proc_task(file_inode(file));
> if (!task)
> @@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct task_struct *p = find_lock_task_mm(task);
>
> if (p) {
> - if (atomic_read(>mm->mm_users) > 1) {
> + mm_users = atomic_read(>mm->mm_users);
> + if ((mm_users > 1) && (mm_users !=
> get_nr_threads(p))) {
How can this work (even before this patch)? When clone(CLONE_VM without
CLONE_THREAD/CLONE_SIGHAND)
is requested, copy_process() calls copy_signal() in order to copy
sig->oom_score_adj and
sig->oom_score_adj_min before calling copy_mm() in order to increment
mm->mm_users, doesn't it?
Then, we will get two different "struct signal_struct" with different
oom_score_adj/oom_score_adj_min
but one "struct mm_struct" shared by two thread groups.
>>>
>>> Are you talking about race between __set_oom_adj and copy_process?
>>> If so, i agree with your opinion. It can not set oom_score_adj properly for
>>> copied process if __set_oom_adj
>>> check mm_users before copy_process calls copy_mm after copy_signal. Please
>>> correct me if i misunderstood anything.
>>
>> You understand it correctly.
>>
>> Reversing copy_signal() and copy_mm() is not sufficient either. We need to
>> use a read/write lock
>> (read lock for copy_process() and write lock for __set_oom_adj()) in order
>> to make sure that
>> the thread created by clone() becomes reachable from for_each_process() path
>> in __set_oom_adj().
>>
>
> Thank you for your suggestion. But i think it would be better to seperate to
> 2 issues. How about think these
> issues separately because there are no dependency between race issue and my
> patch. As i already explained,
> for_each_process path is meaningless if there is only one thread group with
> many threads(mm_users > 1 but
> no other thread group sharing same mm). Do you have any other idea to avoid
> meaningless loop ?
Yes. I suggest reverting commit 44a70adec910d692 ("mm, oom_adj: make sure
processes
sharing mm have same view of oom_score_adj") and commit 97fd49c2355ffded ("mm,
oom:
kill all tasks sharing the mm").
>
>>>
> mm = p->mm;
> atomic_inc(>mm_count);
> }
>>>
>>
>
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
On Mon, Oct 08, 2018 at 09:37:59AM +1000, Dave Airlie wrote: > On Mon, 8 Oct 2018 at 08:56, Al Viro wrote: > > We can surround it with "explanations" until we get something that more or > > less fits, but then we'd need to reanalyse them every time an upstream > > change gets merged. And the lack of textual conflicts is not a good thing > > in such situations, obviously. > We do this already for the GPL (hence the GPLv2 only, and syscall exceptions). That works reasonably well for licenses because people reading licenses tend to do so in a rather detail oriented fashion so it's not that big an obstacle to have something that's a bit harder to follow. It's not clear to me that the same thing is going to apply to people reading codes of conduct, especially those looking for reassurance from them. It might be OK but it's probably worth thinking about. signature.asc Description: PGP signature
Re: linux-next: manual merge of the tip tree with the pm tree
On Mon, Oct 08, 2018 at 12:05:02PM +0200, Rafael J. Wysocki wrote:
> On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote:
> >
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/idle/intel_idle.c
> >
> > between commit:
> >
> > a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
> >
> > from the pm tree and commit:
> >
> > f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --=20
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/idle/intel_idle.c
> > index 791b8a366e6e,c4bb67ed8da3..
> > --- a/drivers/idle/intel_idle.c
> > +++ b/drivers/idle/intel_idle.c
> > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
> > .disable_promotion_to_c1e =3D true,
> > };
> > =20
> > -#define ICPU(model, cpu) \
> > - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) }
> > -
> > static const struct x86_cpu_id intel_idle_ids[] __initconst =3D {
> > - ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM_G, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_WESTMERE, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_ATOM_BONNELL, idle_cpu_atom),
> > - ICPU(INTEL_FAM6_ATOM_BONNELL_MID, idle_cpu_lincroft),
> > - ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem),
> > - ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb),
> > - ICPU(INTEL_FAM6_SANDYBRIDGE_X, idle_cpu_snb),
> > - ICPU(INTEL_FAM6_ATOM_SALTWELL, idle_cpu_atom),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier),
> > - ICPU(INTEL_FAM6_ATOM_AIRMONT, idle_cpu_cht),
> > - ICPU(INTEL_FAM6_IVYBRIDGE, idle_cpu_ivb),
> > - ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt),
> > - ICPU(INTEL_FAM6_HASWELL_CORE, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_X, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_HASWELL_GT3E, idle_cpu_hsw),
> > - ICPU(INTEL_FAM6_ATOM_SILVERMONT_X, idle_cpu_avn),
> > - ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_BROADWELL_XEON_D, idle_cpu_bdw),
> > - ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl),
> > - ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl),
> > - ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, idle_cpu_skl),
> > - ICPU(INTEL_FAM6_SKYLAKE_X, idle_cpu_skx),
> > - ICPU(INTEL_FAM6_XEON_PHI_KNL, idle_cpu_knl),
> > - ICPU(INTEL_FAM6_XEON_PHI_KNM, idle_cpu_knl),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT, idle_cpu_bxt),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> > - ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv),
> > + INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM_G, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(NEHALEM_EX, idle_cpu_nehalem),
> > - INTEL_CPU_FAM6(ATOM_PINEVIEW, idle_cpu_atom),
> > - INTEL_CPU_FAM6(ATOM_LINCROFT, idle_cpu_lincroft),
> > ++ INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom),
> > ++ INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft),
> > + INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
> > + INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
> > + INTEL_CPU_FAM6(SANDYBRIDGE_X, idle_cpu_snb),
> > - INTEL_CPU_FAM6(ATOM_CEDARVIEW, idle_cpu_atom),
> > - INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt),
> > - INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
> > ++ INTEL_CPU_FAM6(ATOM_SALTWELL, idle_cpu_atom),
> > ++
Re: [PATCH] Video: vgastate: fixed a spacing coding style
On 08/24/2018 02:49 PM, Mehdi Bounya wrote: > Removed a space between function name and open parant. > > Signed-off-by: Mehdi Bounya Patch queued for 4.20, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics
[PATCH] staging: erofs: add SPDX identifer
Add SPDX identifier to simplify header and remove whole license text Signed-off-by: Loic Tourlonias --- drivers/staging/erofs/lz4defs.h | 23 ++- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/staging/erofs/lz4defs.h b/drivers/staging/erofs/lz4defs.h index 00a0b58a0871..bdb1022981d8 100644 --- a/drivers/staging/erofs/lz4defs.h +++ b/drivers/staging/erofs/lz4defs.h @@ -1,32 +1,13 @@ #ifndef __LZ4DEFS_H__ #define __LZ4DEFS_H__ +// SPDX-License-Identifier: BSD-2-Clause /* * lz4defs.h -- common and architecture specific defines for the kernel usage * LZ4 - Fast LZ compression algorithm * Copyright (C) 2011-2016, Yann Collet. - * BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php) - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions are - * met: - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above - * copyright notice, this list of conditions and the following disclaimer - * in the documentation and/or other materials provided with the - * distribution. - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * * You can contact the author at : * - LZ4 homepage : http://www.lz4.org * - LZ4 source repository : https://github.com/lz4/lz4 -- 2.17.1
Re: linux-next: manual merge of the drivers-x86 tree with the tip tree
On Mon, Oct 8, 2018 at 6:44 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> drivers/platform/x86/intel_int0002_vgpio.c
>
> between commit:
>
> f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
>
> from the tip tree and commit:
>
> 96402de65afc ("platform/x86: intel_int0002_vgpio: Enable the driver on Bay
> Trail platforms")
>
> from the drivers-x86 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Looks good to me!
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/platform/x86/intel_int0002_vgpio.c
> index e89ad4964dc1,c958a628c375..
> --- a/drivers/platform/x86/intel_int0002_vgpio.c
> +++ b/drivers/platform/x86/intel_int0002_vgpio.c
> @@@ -57,11 -54,7 +54,7 @@@
> #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
>
> static const struct x86_cpu_id int0002_cpu_ids[] = {
> - /*
> - * Limit ourselves to Cherry Trail for now, until testing shows we
> - * need to handle the INT0002 device on Baytrail too.
> - *ICPU(INTEL_FAM6_ATOM_SILVERMONT),* Valleyview, Bay Trail *
> - */
> - ICPU(INTEL_FAM6_ATOM_SILVERMONT1), /* Valleyview, Bay Trail */
> ++ ICPU(INTEL_FAM6_ATOM_SILVERMONT), /* Valleyview, Bay Trail */
> ICPU(INTEL_FAM6_ATOM_AIRMONT), /* Braswell, Cherry Trail */
> {}
> };
--
With Best Regards,
Andy Shevchenko
Re: linux-next: manual merge of the drivers-x86 tree with the tip tree
On Mon, Oct 8, 2018 at 6:48 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> drivers/platform/x86/intel_mid_powerbtn.c
>
> between commit:
>
> f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
>
> from the tip tree and commit:
>
> a8b60e484f3d ("platform/x86: intel_mid_powerbtn: Get rid of custom ICPU()
> macro")
>
> from the drivers-x86 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks!
Looks good to me.
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/platform/x86/intel_mid_powerbtn.c
> index 5ad44204a9c3,a8c0fbb7f799..
> --- a/drivers/platform/x86/intel_mid_powerbtn.c
> +++ b/drivers/platform/x86/intel_mid_powerbtn.c
> @@@ -121,12 -112,9 +112,9 @@@ static const struct mid_pb_ddata mrfld_
> .setup = mrfld_setup,
> };
>
> - #define ICPU(model, ddata)\
> - { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (kernel_ulong_t)
> }
> -
> static const struct x86_cpu_id mid_pb_cpu_ids[] = {
> - ICPU(INTEL_FAM6_ATOM_SALTWELL_MID, mfld_ddata),
> - ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,mrfld_ddata),
> - INTEL_CPU_FAM6(ATOM_PENWELL,mfld_ddata),
> - INTEL_CPU_FAM6(ATOM_MERRIFIELD, mrfld_ddata),
> ++ INTEL_CPU_FAM6(ATOM_SALTWELL_MID, mfld_ddata),
> ++ INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, mrfld_ddata),
> {}
> };
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v11 2/3]: perf record: enable asynchronous trace writing
On Mon, Oct 08, 2018 at 09:17:11AM +0300, Alexey Budankov wrote:
SNIP
> static int record__mmap_read_evlist(struct record *rec, struct perf_evlist
> *evlist,
> bool overwrite)
> {
> @@ -520,7 +644,10 @@ static int record__mmap_read_evlist(struct record *rec,
> struct perf_evlist *evli
> int i;
> int rc = 0;
> struct perf_mmap *maps;
> -
> +#ifdef HAVE_AIO_SUPPORT
> + int trace_fd = rec->data.file.fd;
> + off_t off;
> +#endif
> if (!evlist)
> return 0;
>
> @@ -531,14 +658,34 @@ static int record__mmap_read_evlist(struct record *rec,
> struct perf_evlist *evli
> if (overwrite && evlist->bkw_mmap_state != BKW_MMAP_DATA_PENDING)
> return 0;
>
> +#ifdef HAVE_AIO_SUPPORT
> + off = lseek(trace_fd, 0, SEEK_CUR);
> +#endif
> for (i = 0; i < evlist->nr_mmaps; i++) {
> struct perf_mmap *map = [i];
>
> if (map->base) {
> - if (perf_mmap__push(map, rec, record__pushfn) != 0) {
> - rc = -1;
> - goto out;
> +#ifdef HAVE_AIO_SUPPORT
> + if (!rec->opts.nr_cblocks) {
> +#endif
> + if (perf_mmap__push(map, rec, record__pushfn)
> != 0) {
> + rc = -1;
> + goto out;
> + }
> +#ifdef HAVE_AIO_SUPPORT
> + } else {
> + /*
> + * Call record__aio_sync() to wait till
> map->data buffer
> + * becomes available after previous aio write
> request.
> + */
> + record__aio_sync(map);
> + if (perf_mmap__aio_push(map, rec,
> record__aio_pushfn, ) != 0) {
> + lseek(trace_fd, off, SEEK_SET);
> + rc = -1;
> + goto out;
> + }
> }
> +#endif
I really don't like this.. let's have some aio_... function with its
dummy counterpart to be called in here.. and again.. if we realyl must
have this compiled optionaly, which I'm not convinced of
jirka
Re: [PATCH v2 6/6] power: supply: add AC power supply driver for AXP813
Hi Oskari,
On Sun, Oct 07, 2018 at 12:18:36AM +0300, Oskari Lemmela wrote:
> AXP813 and AXP803 PMICs can control input current and
> minimum voltage.
>
> Both of these values are configurable.
>
> Signed-off-by: Oskari Lemmela
> ---
> drivers/power/supply/axp20x_ac_power.c | 92 ++
> 1 file changed, 92 insertions(+)
>
> diff --git a/drivers/power/supply/axp20x_ac_power.c
> b/drivers/power/supply/axp20x_ac_power.c
> index 0771f951b11f..92a92354f6f0 100644
> --- a/drivers/power/supply/axp20x_ac_power.c
> +++ b/drivers/power/supply/axp20x_ac_power.c
> @@ -27,6 +27,16 @@
> #define AXP20X_PWR_STATUS_ACIN_PRESENT BIT(7)
> #define AXP20X_PWR_STATUS_ACIN_AVAIL BIT(6)
>
> +#define AXP813_VHOLD_MASKGENMASK(5, 3)
> +#define AXP813_VHOLD_UV_TO_BIT(x)x) / 10) - 40) << 3)
> +#define AXP813_VHOLD_REG_TO_UV(x)\
> + (x) & AXP813_VHOLD_MASK) >> 3) + 40) * 10)
> +
> +#define AXP813_CURR_LIMIT_MASK GENMASK(2, 0)
> +#define AXP813_CURR_LIMIT_UA_TO_BIT(x) (((x) / 50) - 3)
> +#define AXP813_CURR_LIMIT_REG_TO_UA(x) \
> + x) & AXP813_CURR_LIMIT_MASK) + 3) * 50)
> +
> #define DRVNAME "axp20x-ac-power-supply"
>
> struct axp20x_ac_power {
> @@ -102,6 +112,55 @@ static int axp20x_ac_power_get_property(struct
> power_supply *psy,
>
> return 0;
>
> + case POWER_SUPPLY_PROP_VOLTAGE_MIN:
> + ret = regmap_read(power->regmap, AXP813_ACIN_PATH_CTRL, );
> + if (ret)
> + return ret;
> +
> + val->intval = AXP813_VHOLD_REG_TO_UV(reg);
> +
> + return 0;
> +
> + case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> + ret = regmap_read(power->regmap, AXP813_ACIN_PATH_CTRL, );
> + if (ret)
> + return ret;
> +
> + val->intval = AXP813_CURR_LIMIT_REG_TO_UA(reg);
> +
> + return 0;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int axp20x_ac_power_set_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *val)
> +{
Argh, missed this one in the first version. Since you're introducing it
with the AXP813 and it isn't used with the AXP20X, I'd name it
axp813_ac_power_set_property. I'll let Maxime or Chen-Yu confirm though.
With the modification in the header from the previous patch in this
patch,
Reviewed-by: Quentin Schulz
Thanks!
Quentin
signature.asc
Description: PGP signature
Re: [PATCH] reset: socfpga: add an early reset driver for SoCFPGA
Hi Dinh, On Fri, 2018-10-05 at 15:23 -0500, Dinh Nguyen wrote: > Hi Philipp, > > I apologize, but I just realized that I forgot to test this patch > against the SoCFPGA ARM64 platform. I just tested against that platform > and this patch is preventing that board from booting. > > I need to redo this patch. > > If its not too late, can you remove this patch from reset/next? That's fine, I've dropped the patch from reset/next. regards Philipp
Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled
On Mon, Oct 08, 2018 at 03:11:56PM +0800, lijiang wrote:
> I used this ".config" to compile kernel in the attachment, and got a compile
> error.
> Would you like to have a try?
>
> [root@hp-dl385g10-03 linux]# make ARCH=i386 -j32
> ..
> LD vmlinux.o
> MODPOST vmlinux.o
> fs/proc/vmcore.o：In function ‘read_from_oldmem’：
> /home/linux/fs/proc/vmcore.c:127：undefined reference to
> ‘copy_oldmem_page_encrypted’
> make: *** [vmlinux] error 1
Thanks, that triggered here. Ok, I guess something like this, to avoid
the ugly ifdeffery:
---
diff --git a/arch/x86/kernel/crash_dump_32.c b/arch/x86/kernel/crash_dump_32.c
index 33ee47670b99..8696800f2eea 100644
--- a/arch/x86/kernel/crash_dump_32.c
+++ b/arch/x86/kernel/crash_dump_32.c
@@ -80,6 +80,16 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
return csize;
}
+/*
+ * 32-bit parrot version to avoid build errors.
+ */
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+ unsigned long offset, int userbuf)
+{
+ WARN_ON_ONCE(1);
+ return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+}
+
static int __init kdump_buf_page_init(void)
{
int ret = 0;
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Anson Huang Best Regards! > -Original Message- > From: Stephen Boyd > Sent: Monday, October 8, 2018 3:41 PM > To: ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > mturque...@baylibre.com; s.ha...@pengutronix.de; shawn...@kernel.org; > Anson Huang ; Fabio Estevam > ; Jerome Forissier ; > Peng Fan ; Rob Herring > Cc: dl-linux-imx > Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > Quoting Anson Huang (2018-09-03 00:20:53) > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote: > > > > > Quoting Peng Fan (2018-08-12 18:15:41) > > > > >> Hi Anson, > > > > >> > > > > > -Original Message- > > > > > From: Anson Huang > > > > > Sent: 2018年8月8日 12:39 > > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > > ker...@pengutronix.de; Fabio Estevam > > > > > ; mturque...@baylibre.com; > > > > > sb...@kernel.org; linux-arm-ker...@lists.infradead.org; > > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > Cc: dl-linux-imx > > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on > > > > > array > > > > > > > > > > Clock framework will enable those clocks registered with > > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array > > > > > during clock > > > > initialization now. > > > > > > > > Will it be more flexible to parse dts saying "critical-clocks = > > > > " > > > > or "init-on-arrary=" > > > > and enable those clocks? > > > > >>> > > > > >>> Parsing the clocks arrays from dtb is another way of enabling > > > > >>> critical clocks, but for current i.MX6/7 platforms, we > > > > >>> implement it in same way as most of other SoCs, currently I > > > > >>> did NOT see any necessity of putting them in dtb, just adding > > > > >>> flag during clock registering is more simple, if there is any > > > > >>> special requirement for different clocks set to be enabled, > > > > >>> then we can add support to enable > > > the method of parsing critical-clocks from dtb. Just my two cents. > > > > >> > > > > >> Thinking about OP-TEE want to use one device, but it's clocks > > > > >> are registered by Linux, because there is no module in Linux > > > > >> side use it, it will shutdown the clock, which cause OP-TEE > > > > >> could not access the > > > device. > > > > >> > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag > > > > >> to make sure the clocks are not shutdown by Linux. > > > > >> > > > > >> However adding a new property in clk node and let driver code > > > > >> parse the dts, there is no need to modify clk driver code when > > > > >> OP-TEE needs > > > another device clock. > > > > >> > > > > > > > > > > If OP-TEE needs linux to keep things on then why can't the > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks > > > > > enabled > forever? > > > > > > > > Sounds reasonable, but how could this be done without introducing > > > > platform-specific stuff in the OP-TEE driver? > > > > > > > > > > Why is that a goal? > > > > I do NOT think we should consider such case in this patch series, > > whatever OP-TEE needs for its own feature, it should do necessary operations > either in its driver or somewhere else by adding new patch. > > > > Why can't we add clks to the op-tee node in DT's /firmware container? > Then any clks in there can be turned on forever and left enabled by the linux > driver? I did NOT run op-tee with Linux-next kernel before, can you advise more? And I think if op-tee has such requirement, can we have another patch to cover it? I believe all other i.MX platforms also have same requirements if considering op-tee support, so I think it should be another topic, what do you think? Anson.
Re: [PATCH] media: vivid: Support 480p for webcam capture
On 06/10/18 11:29, Keiichi Watanabe wrote:
> Hi all,
>
> On Fri, Oct 5, 2018 at 6:18 PM, Hans Verkuil wrote:
>> On 10/03/18 09:08, Keiichi Watanabe wrote:
>>> I think 480p is a common frame size and it's worth supporting in vivid.
>>> But, my patch might be ad-hoc. Actually, I'm not sure which values are
>>> suitable for the intervals.
>>
>> I can apply this ad-hoc patch as-is.
>>
>> Or do you want to postpone this and work on a more generic solution?
>> Although I am not sure what that would look like.
>
> I prefer providing a more flexible way rather than this ad-hoc patch.
> It would be helpful if there is a way of changing supported frame sizes
> easily.
> Perhaps, Kieran and me would use it, at least:)
>
o/
>>
>> Proposals are welcome!
>>
>> The main purpose of this code is to have something that kind of acts like
>> a real webcam that has various resolutions, and a slower framerate for
>> higher resolutions (as you would expect).
>
> This sounds reasonable, so I guess we can keep this way as default and
> provide a way for specifying extra frame sizes as an option.
>
> For example, how about a module option like this?
> "webcam_sizes=640x480@15,320x240@30"
>
> If this parameter is passed to vivid, vivid works like a webcam that
> supports the following 7 pairs of frame size and fps:
> - 5 pairs of frame sizes and fps, as with the current implementation
> - 640x480 (15fps)
> - 320x240 (30fps)
I like the concept of being able to specify as a module parameter.
Perhaps we could have a magic marker on the string to define if the
existing frame sizes should be kept - or if this is just a complete
override ?
vivid.webcam=640x480@15,320x240@30 # Specify sizes explicitly
vivid.webcam=+640x480@15,320x240@30 # Append to existing frames
^ Magic Marker
We might of course want multiple rates per frame,
vivid.webcam=640x480@15-25-30-90-120, # Separator to be defined...
>
> If this parameter is not passed, vivid's behavior won't change from
> the current one.
>
> How do you think?
>
> We might want to stop using the default framesizes, i.e. vivid only
> supports framesize/fps that passed as the option.
> But, if we do so, the parameter will become mandatory and it would be
> annoying.
I think mandatory would be annoying yes.
Thus my suggestion for a magic marker above :)
--
Kieran
> So, I personally like to keep the default framesizes.
>
> Best regards,
> Kei
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> We might want to add a more flexible/extensible way to specify frame sizes.
>>> e.g. passing frame sizes and intervals as module parameters
>>>
>>> Kei
>>>
>>> On Wed, Oct 3, 2018 at 4:06 PM, Keiichi Watanabe
>>> wrote:
Support 640x480 as a frame size for video input devices of vivid.
Signed-off-by: Keiichi Watanabe
---
drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 58e14dd1dcd3..da80bf4bc365 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
};
/* The number of discrete webcam framesizes */
-#define VIVID_WEBCAM_SIZES 5
+#define VIVID_WEBCAM_SIZES 6
/* The number of discrete webcam frameintervals */
#define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
@@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
static const struct v4l2_frmsize_discrete
webcam_sizes[VIVID_WEBCAM_SIZES] = {
{ 320, 180 },
{ 640, 360 },
+ { 640, 480 },
{ 1280, 720 },
{ 1920, 1080 },
{ 3840, 2160 },
@@ -75,6 +76,8 @@ static const struct v4l2_fract
webcam_intervals[VIVID_WEBCAM_IVALS] = {
{ 1, 5 },
{ 1, 10 },
{ 1, 15 },
+ { 1, 15 },
+ { 1, 25 },
{ 1, 25 },
{ 1, 30 },
{ 1, 50 },
--
2.19.0.605.g01d371f741-goog
>>
--
Regards
--
Kieran
Re: [PATCH] kasan: convert kasan/quarantine_lock to raw_spinlock
On Fri, Oct 5, 2018 at 6:33 PM, Sebastian Andrzej Siewior
wrote:
> On 2018-10-05 18:30:18 [+0200], To Clark Williams wrote:
>> This is the minimum to get this working on RT splat free. There is one
>> memory deallocation with irqs off which should work on RT in its current
>> way.
>> Once this and the on_each_cpu() invocation, I was wondering if…
>
> the patch at the bottom wouldn't work just fine for everyone.
> It would have the beaty of annotating the locking scope a little and
> avoiding the on_each_cpu() invocation. No local_irq_save() but actually
> the proper locking primitives.
> I haven't fully decoded the srcu part in the code.
>
> Wouldn't that work for you?
Hi Sebastian,
This seems to beak quarantine_remove_cache( ) in the sense that some
object from the cache may still be in quarantine when
quarantine_remove_cache() returns. When quarantine_remove_cache()
returns all objects from the cache must be purged from quarantine.
That srcu and irq trickery is there for a reason.
This code is also on hot path of kmallock/kfree, an additional
lock/unlock per operation is expensive. Adding 2 locked RMW per
kmalloc is not something that should be done only out of refactoring
reasons.
The original message from Clark mentions that the problem can be fixed
by just changing type of spinlock. This looks like a better and
simpler way to resolve the problem to me.
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> mm/kasan/quarantine.c | 45 +--
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 3a8ddf8baf7dc..8ed595960e3c1 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -39,12 +39,13 @@
> * objects inside of it.
> */
> struct qlist_head {
> + spinlock_t lock;
> struct qlist_node *head;
> struct qlist_node *tail;
> size_t bytes;
> };
>
> -#define QLIST_INIT { NULL, NULL, 0 }
> +#define QLIST_INIT {.head = NULL, .tail = NULL, .bytes = 0 }
>
> static bool qlist_empty(struct qlist_head *q)
> {
> @@ -95,7 +96,9 @@ static void qlist_move_all(struct qlist_head *from, struct
> qlist_head *to)
> * The object quarantine consists of per-cpu queues and a global queue,
> * guarded by quarantine_lock.
> */
> -static DEFINE_PER_CPU(struct qlist_head, cpu_quarantine);
> +static DEFINE_PER_CPU(struct qlist_head, cpu_quarantine) = {
> + .lock = __SPIN_LOCK_UNLOCKED(cpu_quarantine.lock),
> +};
>
> /* Round-robin FIFO array of batches. */
> static struct qlist_head global_quarantine[QUARANTINE_BATCHES];
> @@ -183,12 +186,13 @@ void quarantine_put(struct kasan_free_meta *info,
> struct kmem_cache *cache)
> * beginning which ensures that it either sees the objects in per-cpu
> * lists or in the global quarantine.
> */
> - local_irq_save(flags);
> + q = raw_cpu_ptr(_quarantine);
> + spin_lock_irqsave(>lock, flags);
>
> - q = this_cpu_ptr(_quarantine);
> qlist_put(q, >quarantine_link, cache->size);
> if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
> qlist_move_all(q, );
> + spin_unlock(>lock);
>
> spin_lock(_lock);
> WRITE_ONCE(quarantine_size, quarantine_size + temp.bytes);
> @@ -203,10 +207,10 @@ void quarantine_put(struct kasan_free_meta *info,
> struct kmem_cache *cache)
> if (new_tail != quarantine_head)
> quarantine_tail = new_tail;
> }
> - spin_unlock(_lock);
> + spin_unlock_irqrestore(_lock, flags);
> + } else {
> + spin_unlock_irqrestore(>lock, flags);
> }
> -
> - local_irq_restore(flags);
> }
>
> void quarantine_reduce(void)
> @@ -284,21 +288,11 @@ static void qlist_move_cache(struct qlist_head *from,
> }
> }
>
> -static void per_cpu_remove_cache(void *arg)
> -{
> - struct kmem_cache *cache = arg;
> - struct qlist_head to_free = QLIST_INIT;
> - struct qlist_head *q;
> -
> - q = this_cpu_ptr(_quarantine);
> - qlist_move_cache(q, _free, cache);
> - qlist_free_all(_free, cache);
> -}
> -
> /* Free all quarantined objects belonging to cache. */
> void quarantine_remove_cache(struct kmem_cache *cache)
> {
> unsigned long flags, i;
> + unsigned int cpu;
> struct qlist_head to_free = QLIST_INIT;
>
> /*
> @@ -308,7 +302,20 @@ void quarantine_remove_cache(struct kmem_cache *cache)
> * achieves the first goal, while synchronize_srcu() achieves the
> * second.
> */
> - on_each_cpu(per_cpu_remove_cache, cache, 1);
> + /* get_online_cpus() invoked by caller */
> + for_each_online_cpu(cpu) {
> + struct qlist_head *q;
> + unsigned long flags;
> + struct qlist_head to_free = QLIST_INIT;
> +
> + q =
Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V
On 08/10/2018 10:29, Yi Sun wrote: > Follow PV spinlock mechanism to implement the callback functions > to allow the CPU idling and kicking operations on Hyper-V. > > Cc: "K. Y. Srinivasan" > Cc: Haiyang Zhang > Cc: Stephen Hemminger > Cc: Thomas Gleixner > Cc: Michael Kelley (EOSG) > Cc: Juergen Gross > Signed-off-by: Yi Sun Reviewed-by: Juergen Gross Juergen
Re: [PATCH v2] mm: don't raise MEMCG_OOM event due to failed high-order allocation
On Thu, Oct 04, 2018 at 09:41:09PM +, Roman Gushchin wrote: > I was reported that on some of our machines containers were restarted > with OOM symptoms without an obvious reason. Despite there were almost > no memory pressure and plenty of page cache, MEMCG_OOM event was > raised occasionally, causing the container management software to > think, that OOM has happened. However, no tasks have been killed. > > The following investigation showed that the problem is caused by > a failing attempt to charge a high-order page. In such case, the > OOM killer is never invoked. As shown below, it can happen under > conditions, which are very far from a real OOM: e.g. there is plenty > of clean page cache and no memory pressure. > > There is no sense in raising an OOM event in this case, as it might > confuse a user and lead to wrong and excessive actions (e.g. restart > the workload, as in my case). > > Let's look at the charging path in try_charge(). If the memory usage > is about memory.max, which is absolutely natural for most memory cgroups, > we try to reclaim some pages. Even if we were able to reclaim > enough memory for the allocation, the following check can fail due to > a race with another concurrent allocation: > > if (mem_cgroup_margin(mem_over_limit) >= nr_pages) > goto retry; > > For regular pages the following condition will save us from triggering > the OOM: > >if (nr_reclaimed && nr_pages <= (1 << PAGE_ALLOC_COSTLY_ORDER)) >goto retry; > > But for high-order allocation this condition will intentionally fail. > The reason behind is that we'll likely fall to regular pages anyway, > so it's ok and even preferred to return ENOMEM. > > In this case the idea of raising MEMCG_OOM looks dubious. > > Fix this by moving MEMCG_OOM raising to mem_cgroup_oom() after > allocation order check, so that the event won't be raised for high > order allocations. This change doesn't affect regular pages allocation > and charging. > > Signed-off-by: Roman Gushchin > Acked-by: David Rientjes > Acked-by: Michal Hocko > Cc: Johannes Weiner > Cc: Vladimir Davydov Acked-by: Johannes Weiner
Re: [PATCH 2/2] irqchip: ti-sci-intr: Add support for Interrupt Router driver
Hi Marc,
On 10/6/2018 3:25 PM, Marc Zyngier wrote:
Hi Lokesh,
On Sat, 06 Oct 2018 08:28:12 +0100,
Lokesh Vutla wrote:
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for multiplexing of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
I assume that this co-processor only deals with the routing itself,
and doesn't need to be talked to during interrupt processing, right?
Yes, that's right.
Add support for Interrupt Router driver over TISCI protocol.
Signed-off-by: Lokesh Vutla
---
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 11 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-intr.c | 325 ++
4 files changed, 338 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-intr.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a23778b68d74..cf3c834f8cee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14626,6 +14626,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: drivers/irqchip/irq-ti-sci-intr.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 96451b581452..9a965fe22043 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -374,6 +374,17 @@ config QCOM_PDC
Power Domain Controller driver to manage and configure wakeup
IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
+config TI_SCI_INTR_IRQCHIP
+ tristate "TISCI based Interrupt Router irqchip driver"
+ depends on TI_SCI_PROTOCOL && ARCH_K3
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt router
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt router irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
I don't really see the point of making this user-selectable. If you're
compiling support for a given platform, this platform configuration
fragment should itself select the necessary dependencies for the
system to work as expected. Here, you are leaving the choice to the
user, with a 50% chance of getting a system that doesn't boot...
There are 2 reasons why I made it tristate:
- Not all interrupts go through this irqchip(At least in the AM6 SoC
using this). Most of the legacy peripherals still are directly connected
to GIC
- TI_SCI_PROTOCOL is defined as tristate.
If you still feel I should not make it user-selectable, I can drop it.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b822199445ff..44bf65606d60 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -89,3 +89,4 @@ obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
obj-$(CONFIG_NDS32)+= irq-ativic32.o
obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
+obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
diff --git a/drivers/irqchip/irq-ti-sci-intr.c
b/drivers/irqchip/irq-ti-sci-intr.c
new file mode 100644
index ..f04fe6da1b09
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Router irqchip driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define TI_SCI_IS_EVENT_IRQBIT(31)
+
+#define HWIRQ_TO_DEVID(HWIRQ) (((HWIRQ) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(HWIRQ) ((HWIRQ) & (TI_SCI_IRQ_ID_MASK))
nit: s/(HWIRQ)/(hwirq)/g
okay.
+
+/**
+ * struct ti_sci_intr_irq_domain - Structure representing a TISCI based
+ *Interrupt Router IRQ domain.
+ * @sci: Pointer to TISCI handle
+ * @dst_irq: TISCI resource pointer representing destination irq controller.
+ * @dst_id:TISCI device ID of the destination irq controller.
+ */
+struct ti_sci_intr_irq_domain {
+ const struct ti_sci_handle *sci;
+ struct ti_sci_resource
Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions
Hi, On 27.09.2018 10:14, Maxime Ripard wrote: On Wed, Sep 26, 2018 at 10:19:22PM +0200, Hans de Goede wrote: On 26-09-18 16:44, Frieder Schrempf wrote: Hi, On Fri, Feb 09, 2018 at 03:01:00PM +0100, Ulf Hansson wrote: [...] I'd like to know if any progress has been made on that problem (I may have missed patches). Had you had the time to look at the issue? I have looked at the issue, but not manage to cook some patches for it. However, it's on my top of my TODO list for mmc. No promises, but perhaps and hopefully I manage to get something posted during the coming release cycle. I would be interested in a ESP8089 driver in mainline and that's why I want to pick up this discussion. What is the current status of the "mmc_reprobe_device" implementation, that Hans was explaining and Ulf wanted to provide some months ago? Ulf did eventually write a new way to deal with this and then Quentin did manage to get the esp8089 driver to work with it, the new function to use for this is added by this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=1433269c4d2461be1f36db5dbb453976b38996ff I'm not sure what the status of upstreaming the ep8089 driver is now that we've this in place. Quentin, do you have a version of the esp8089 driver somewhere which will work correctly with the new mmc_sw_reset() function? Also what is the status of adding this driver to say staging? IIRC, we tried to get it into staging, and we got told that it was too nice for staging at this point. So we're basically stuck somewhere between staging and !staging, with the driver being too nice for the former, and not nice enough for the latter :) Ok, and is there someone willing to continue upstreaming the driver? Maybe someone can rebase and resend the latest approach? After all it looks like a lot of work has already been done. Thanks, Frieder
Re: general protection fault in gcmaes_crypt_by_sg
(add the TLS maintainers) On 6 October 2018 at 15:04, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:12ffaa1197f5 Add linux-next specific files for 20181005 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=16cb780640 > kernel config: https://syzkaller.appspot.com/x/.config?x=d6b058a7232046f > dashboard link: https://syzkaller.appspot.com/bug?extid=c5048caf67d09ee24549 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+c5048caf67d09ee24...@syzkaller.appspotmail.com > > @ : renamed from ip6gre0 > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] PREEMPT SMP KASAN > CPU: 1 PID: 1510 Comm: syz-executor0 Not tainted 4.19.0-rc6-next-20181005+ > #88 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:scatterwalk_start include/crypto/scatterwalk.h:73 [inline] > RIP: 0010:gcmaes_crypt_by_sg+0x56f/0x2110 > arch/x86/crypto/aesni-intel_glue.c:834 > Code: c1 e9 03 80 3c 11 00 0f 85 bf 18 00 00 48 8d 78 08 48 89 84 24 50 01 > 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <0f> b6 14 11 84 d2 > 74 09 80 fa 03 0f 8e 6b 15 00 00 44 8b 60 08 48 > RSP: 0018:8801852bf120 EFLAGS: 00010202 > RAX: RBX: 88019023c6b0 RCX: 0001 > RDX: dc00 RSI: 8359e06c RDI: 0008 > RBP: 8801852bf520 R08: 8801850c4300 R09: 8801befb0060 > R10: 8801852bf7b0 R11: 8801852bf7db R12: 000d > R13: 000d R14: 8801852bf238 R15: 8801852bf7d0 > FS: 025d3940() GS:8801daf0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 001b2d128000 CR3: 0001cd273000 CR4: 001406e0 > DR0: 2000 DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0600 > Call Trace: > gcmaes_encrypt.constprop.17+0x7d7/0x1190 > arch/x86/crypto/aesni-intel_glue.c:929 > generic_gcmaes_encrypt+0x12d/0x186 arch/x86/crypto/aesni-intel_glue.c:1294 > crypto_aead_encrypt include/crypto/aead.h:364 [inline] > gcmaes_wrapper_encrypt+0x162/0x200 arch/x86/crypto/aesni-intel_glue.c:1127 > crypto_aead_encrypt include/crypto/aead.h:364 [inline] > tls_do_encryption net/tls/tls_sw.c:534 [inline] > tls_push_record+0xc12/0x17f0 net/tls/tls_sw.c:583 > tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:597 > tls_handle_open_record net/tls/tls_main.c:155 [inline] > tls_sk_proto_close+0x439/0x750 net/tls/tls_main.c:272 > inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428 > inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458 > __sock_release+0xd7/0x250 net/socket.c:580 > sock_close+0x19/0x20 net/socket.c:1142 > __fput+0x3bc/0xa70 fs/file_table.c:279 > fput+0x15/0x20 fs/file_table.c:312 > task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] > syscall_return_slowpath arch/x86/entry/common.c:268 [inline] > do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x411051 > Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48 > 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 > c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 > RSP: 002b:7fff40f9a8d0 EFLAGS: 0293 ORIG_RAX: 0003 > RAX: RBX: 0004 RCX: 00411051 > RDX: 001b2da2 RSI: RDI: 0003 > RBP: R08: 49ccd1ef R09: 49ccd1f3 > R10: 7fff40f9a800 R11: 0293 R12: > R13: 0001 R14: 010c R15: > Modules linked in: > ---[ end trace a8f523110d8ca375 ]--- > RIP: 0010:scatterwalk_start include/crypto/scatterwalk.h:73 [inline] > RIP: 0010:gcmaes_crypt_by_sg+0x56f/0x2110 > arch/x86/crypto/aesni-intel_glue.c:834 > Code: c1 e9 03 80 3c 11 00 0f 85 bf 18 00 00 48 8d 78 08 48 89 84 24 50 01 > 00 00 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <0f> b6 14 11 84 d2 > 74 09 80 fa 03 0f 8e 6b 15 00 00 44 8b 60 08 48 > RSP: 0018:8801852bf120 EFLAGS: 00010202 > RAX: RBX: 88019023c6b0 RCX: 0001 > RDX: dc00 RSI: 8359e06c RDI: 0008 > RBP: 8801852bf520 R08: 8801850c4300 R09: 8801befb0060 > R10: 8801852bf7b0 R11: 8801852bf7db R12: 000d > R13: 000d R14: 8801852bf238 R15: 8801852bf7d0 > FS: 025d3940()
Re: [PATCH v9 7/7] dt-bindings: ufshcd-pltfrm: Add core reset string
On 2018-09-27 23:06, Rob Herring wrote: On Thu, Sep 20, 2018 at 09:28:00PM -0700, Can Guo wrote: From: Can Guo Add core reset support string for UFS. Signed-off-by: Amit Nischal Signed-off-by: Can Guo --- Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index c39dfef..6b697c4 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -11,6 +11,11 @@ Required properties: "qcom,ufshc" - interrupts: - reg : +- reset : reset specifier pair consists of phandle for the reset provider + and reset lines used by this controller. It is mandatory for + QCOM SDM845 platform. +- reset-names : reset signal name strings sorted in the same order as the + resets property. It is mandatory for QCOM SDM845 platform. This already exists as of 4.19 under optional properties. (And you can't add new required properties anyways.) Thank you Rob, I also found the newly merged change from Huawei on 4.19. Then our code would need a small change to parse the new reset-names string. Optional properties: - phys : phandle to UFS PHY node @@ -64,6 +69,8 @@ Example: clocks = < 0>, < 0>, < 0>; clock-names = "core_clk", "ref_clk", "iface_clk"; freq-table-hz = <1 2>, <0 0>, <0 0>; + resets = ; + reset-names = "core_reset"; And the name should be "rst" (or omitted). Sure, got it, thank you. phys = <>; phy-names = "ufsphy"; }; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 5/6] mfd: axp20x: add support AXP803 AC and battery power supplies
Hi Oskari,
On Sun, Oct 07, 2018 at 12:18:35AM +0300, Oskari Lemmela wrote:
> AXP803 is compatible with AXP813.
> Adding needed cells for AC and battery power supplies.
>
> AXP813 AC power supply cell added.
>
> Signed-off-by: Oskari Lemmela
> ---
> drivers/mfd/axp20x.c | 22 +-
> include/linux/mfd/axp20x.h | 1 +
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 0be511dd93d0..215f0b009728 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -731,8 +731,23 @@ static const struct mfd_cell axp803_cells[] = {
> .name = "axp221-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> + }, {
> + .name = "axp20x-regulator"
> + }, {
> + .name = "axp20x-gpio",
> + .of_compatible = "x-powers,axp813-gpio",
> + }, {
> + .name = "axp813-adc",
> + .of_compatible = "x-powers,axp813-adc",
> + }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp813-battery-power-supply",
> + }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp813-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> },
> - { .name = "axp20x-regulator" },
> };
>
> static const struct mfd_cell axp806_self_working_cells[] = {
> @@ -778,6 +793,11 @@ static const struct mfd_cell axp813_cells[] = {
> }, {
> .name = "axp20x-battery-power-supply",
> .of_compatible = "x-powers,axp813-battery-power-supply",
> + }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp813-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
I'll let Maxime or Chen-Yu tell you what they want but I think we could
have two different commits, one for AXP803 and one for AXP813. I don't
think we care about having one commit per added resource for the axp803
though.
> },
> };
>
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index 517e60eecbcb..2302b620d238 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -266,6 +266,7 @@ enum axp20x_variants {
> #define AXP288_RT_BATT_V_H 0xa0
> #define AXP288_RT_BATT_V_L 0xa1
>
> +#define AXP813_ACIN_PATH_CTRL0x3a
You're not using it in this patch, please keep this change in the commit
where its use is introduced.
Thanks,
Quentin
signature.asc
Description: PGP signature
Re: [PATCH 0/6] cpuidle: menu: Fixes, optimizations and cleanups
Hi Doug, On Mon, Oct 8, 2018 at 8:02 AM Doug Smythies wrote: > > On 2018.10.03 23:56 Rafael J. Wysocki wrote: > > On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki > > wrote: > >> > >> Hi All, > >> > >> This series fixes a couple of issues with the menu governor, optimizes it > >> somewhat and makes a couple of cleanups in it. Please refer to the > >> patch changelogs for details. > >> > >> All of the changes in the series are straightforward in my view. The > >> first two patches are fixes, the rest is optimizations and cleanups. > > > > I'm inclined to take this stuff in for 4.20 if nobody has problems > > with it, so please have a look if you care (and you should, because > > the code in question is run on all tickless systems out there). > > Hi Rafael, > > I did tests with kernel 4.19-rc6 as a baseline reference and then > with 8 of your patches (&8patches in the graphs legend): > > cpuidle: menu: Replace data->predicted_us with local variable > . as required to get this set of 6 to then apply. > This set of 6 patches. > cpuidle: poll_state: Revise loop termination condition > > Recall I also did some testing in late August [1], with > a kernel that was just a few hundred commits before 4.19-rc1. > The baseline is now way different. While I don't know why, > I bisected the kernel and either made a mistake, or it was: > > first bad commit: [06e386a1db54ab6a671e103e929b590f7a88f0e3] > Merge tag 'fbdev-v4.19' of https://github.com/bzolnier/linux > > Anyway, and for reference, included on some of the graphs > is the old data from late August (legend name "4.18+3rjw > (Aug test)") > > Test 1: A Thomas Ilsche type "powernightmare" test: > (forever ((10 times - variable usec sleep) 0.999 seconds sleep) X 40 > staggered threads. > Where the "variable" was from 0.05 to 5 in steps of 0.05, for the first ~200 > minutes of the test. > (note: overheads mean that actual loop times are quite different.) > And then from 5 to 50 in steps of 1, for the remaining 100 minutes of the > test. > (Shortened by 900 minutes from the way the test was done in August.) > Each step ran for 2 minutes. The system was idle for 1 minute at the start, > and a few > minutes at the end of the graphs. > > The power and idle statistics graphs are here: > http://fast.smythies.com/linux-pm/k419/k419-pn-sweep-rjw.htm > > Observations: > > While the graphs are pretty and such, the only significant > difference is the idle state 0 percentages go down a lot > with the 8 patches. However the number of idle state 0 > entries per minute goes up. To present the same information > in a different way a trace was done (at 9 Gigabytes in > 2 minutes): The difference in the idle state 0 usage is a consequence of the "poll idle" patch and is expected. > &8patches > Idle State 0: Total Entries: 10091412 : time (seconds): 49.447025 > Idle State 1: Total Entries: 49332297 : time (seconds): 375.943064 > Idle State 2: Total Entries: 311810 : time (seconds): 2.626403 > > k4.19-rc6 > Idle State 0: Total Entries: 9162465 : time (seconds): 70.650566 > Idle State 1: Total Entries: 47592671 : time (seconds): 373.625083 > Idle State 2: Total Entries: 266212 : time (seconds): 2.278159 > > Conclusions: Behaves as expected. Right. :-) > Test 2: pipe test 2 CPUs, one core. CPU test: > > The average loop times graph is here: > http://fast.smythies.com/linux-pm/k419/k419-rjw-pipe-1core.png > > The power and idle statistics graphs are here: > http://fast.smythies.com/linux-pm/k419/k419-rjw-pipe-1core.htm > > Conclusions: > > Better performance at the cost of more power with > the patch set, but late August had both better performance > and less power. > > Overall idle entries and exits are about the same, but way > way more idle state 0 entries and exits with the patch set. Same as above (and expected too). > Supporting: trace summary (note: such a heavy load on the trace > system (~6 gigabytes in 2 minutes) costs about 25% in performance): > > k4.16-rc6 pipe > Idle State 0: Total Entries: 76638 : time (seconds): 0.193166 > Idle State 1: Total Entries: 37825999 : time (seconds): 23.886772 > Idle State 2: Total Entries: 49 : time (seconds): 0.007908 > > &8patches > Idle State 0: Total Entries: 37632104 : time (seconds): 26.097220 > Idle State 1: Total Entries: 397 : time (seconds): 0.020021 > Idle State 2: Total Entries: 208 : time (seconds): 0.031052 > > With rjw 8 patch set (1st col is usecs duration, 2nd col > is number of occurrences in 2 minutes): > > Idle State: 0 Summary: > 0 24401500 > 1 13153259 > 2 19807 > 3 32731 > 4 802 > 5 346 > 6 1554 > 7 20087 > 8 1849 > 9 150 > 10 9 > 11 10 > > Idle State: 1 Summary: > 0 29 > 1 44 > 2 15 > 3 45 > 4 5 > 5 26 > 6 2 > 7 24 > 8 4 > 9 21 > 10 6 > 11 39 > 12 15 > 13 38 > 14 14 > 15 27 > 16 10 > 17 12 > 18 1 > 35 1 > 89 1 > 135 1 > 678 1 > 991 2 > 995 3 > 996 1 > 997 8 > 998 1 > 999 1 > > Kernel 4.19-rc6 reference: > > Idle State: 0 Summary: > 0 17212 > 1 7516 > 2 34737 > 3 14763 > 4 2312 > 5 74 > 6 3 > 7 3 > 8
Re: [PATCH] staging: emxx_udc: remove unused code
Hi, On 10/8/18 9:33 AM, Loic Tourlonias wrote: > Remove useless code inside if_0 endif > > Signed-off-by: Loic Tourlonias > --- > drivers/staging/emxx_udc/emxx_udc.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/staging/emxx_udc/emxx_udc.h > b/drivers/staging/emxx_udc/emxx_udc.h > index 8337e38c238a..78fa60192a14 100644 > --- a/drivers/staging/emxx_udc/emxx_udc.h > +++ b/drivers/staging/emxx_udc/emxx_udc.h > @@ -10,10 +10,6 @@ > > > /*---*/ > /*- Default undef */ > -#if 0 > -#define DEBUG > -#define UDC_DEBUG_DUMP > -#endif > Don't remove that code. This is a common practice for debugging. Whenever the developer needs to debug something in the whole driver, he/she just has to change that #if 0 to #if 1 and then all the code under DEBUG and UDC_DEBUG_DUMP will be enabled. Notice that UDC_DEBUG_DUMP is being used in drivers/staging/emxx_udc/emxx_udc.c Thanks -- Gustavo
Re: [tip:x86/hyperv] x86/hyperv: Enable PV qspinlock for Hyper-V
On 18-10-02 13:38:55, Juergen Gross wrote:
> > +static void hv_qlock_wait(u8 *byte, u8 val)
> > +{
> > + unsigned long msr_val;
> > +
> > + if (READ_ONCE(*byte) != val)
> > + return;
> > +
> > + /*
> > +* Read HV_X64_MSR_GUEST_IDLE MSR can trigger the guest's
> > +* transition to the idle power state which can be exited
> > +* by an IPI even if IF flag is disabled.
> > +*/
>
> What if interrupts are enabled? Won't a kick happening here just
> interrupt and then the following rdmsr result in a hang?
>
> I believe the correct way would be to:
>
> - disable interrupts before above READ_ONCE() and restore them
> after the rdmsrl()
>
> - return early if in_nmi()
>
> similar as the kvm specific variant is doing it.
>
>
> Juergen
Thank you for the suggestion! That is a possible case. I will submit
a new version in soon.
BRs,
Yi Sun
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Hi Josh,
On Sun, Oct 7, 2018 at 1:35 PM Josh Triplett wrote:
> On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allowed.
> >
> > Avoid any ambiguity by removing the list, to ensure "a harassment-free
> > experience for everyone", period.
>
> I would suggest reading the commit message that added this in the first
> place. "Explicit guidelines have demonstrated success in other projects
> and other areas of the kernel." See also various comparisons of codes of
The first paragraph of the commit message (the "why" part) is exactly the
part we've been waiting for a clarification since the inception of the
commit...
> conduct, which make the same point. The point of this list is precisely
> to serve as one such explicit guideline; removing it would rather defeat
> the purpose.
Then (at least) the list should be marked containing examples, cfr. the other
examples in the document.
> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.
There are precedents:
Until recent, the file named "COPYING" (which you referred to in another
email related to patching the CoC), was a verbatim copy of the GPL, with
clarifications added at the top.
Documentation/process/code-of-conduct.rst is already a slightly modified
version of the original.
Now, if amending the CoC locally is not an option, I'm afraid a plain revert
is the only option, like for any other commit that breaks the userspace ABI
(Linux kernel developers are also users ;-), until the raised issues have
been resolved upstream.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[tip:x86/asm] x86/fsgsbase/64: Introduce FS/GS base helper functions
Commit-ID: b1378a561fd16afdd96ef0bc912b1bcd2b85a68e
Gitweb: https://git.kernel.org/tip/b1378a561fd16afdd96ef0bc912b1bcd2b85a68e
Author: Chang S. Bae
AuthorDate: Tue, 18 Sep 2018 16:08:53 -0700
Committer: Ingo Molnar
CommitDate: Mon, 8 Oct 2018 10:41:08 +0200
x86/fsgsbase/64: Introduce FS/GS base helper functions
Introduce FS/GS base access functionality via ,
not yet used by anything directly.
Factor out task_seg_base() from x86/ptrace.c and rename it to
x86_fsgsbase_read_task() to make it part of the new helpers.
This will allow us to enhance FSGSBASE support and eventually enable
the FSBASE/GSBASE instructions.
An "inactive" GS base refers to a base saved at kernel entry
and being part of an inactive, non-running/stopped user-task.
(The typical ptrace model.)
Here are the new functions:
x86_fsbase_read_task()
x86_gsbase_read_task()
x86_fsbase_write_task()
x86_gsbase_write_task()
x86_fsbase_read_cpu()
x86_fsbase_write_cpu()
x86_gsbase_read_cpu_inactive()
x86_gsbase_write_cpu_inactive()
As an advantage of the unified namespace we can now see all FS/GSBASE
API use in the kernel via the following 'git grep' pattern:
$ git grep x86_.*sbase
[ mingo: Wrote new changelog. ]
Based-on-code-from: Andy Lutomirski
Suggested-by: Ingo Molnar
Signed-off-by: Chang S. Bae
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Markus T Metzger
Cc: Peter Zijlstra
Cc: Ravi Shankar
Cc: Rik van Riel
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1537312139-5580-3-git-send-email-chang.seok@intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/fsgsbase.h | 50
arch/x86/kernel/process_64.c| 124
arch/x86/kernel/ptrace.c| 51 ++---
3 files changed, 179 insertions(+), 46 deletions(-)
diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
new file mode 100644
index ..1ab465ee23fe
--- /dev/null
+++ b/arch/x86/include/asm/fsgsbase.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_FSGSBASE_H
+#define _ASM_FSGSBASE_H 1
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_X86_64
+
+#include
+
+unsigned long x86_fsgsbase_read_task(struct task_struct *task,
+unsigned short selector);
+
+/*
+ * Read/write a task's fsbase or gsbase. This returns the value that
+ * the FS/GS base would have (if the task were to be resumed). These
+ * work on current or on a different non-running task.
+ */
+unsigned long x86_fsbase_read_task(struct task_struct *task);
+unsigned long x86_gsbase_read_task(struct task_struct *task);
+int x86_fsbase_write_task(struct task_struct *task, unsigned long fsbase);
+int x86_gsbase_write_task(struct task_struct *task, unsigned long gsbase);
+
+/* Helper functions for reading/writing FS/GS base */
+
+static inline unsigned long x86_fsbase_read_cpu(void)
+{
+ unsigned long fsbase;
+
+ rdmsrl(MSR_FS_BASE, fsbase);
+ return fsbase;
+}
+
+void x86_fsbase_write_cpu(unsigned long fsbase);
+
+static inline unsigned long x86_gsbase_read_cpu_inactive(void)
+{
+ unsigned long gsbase;
+
+ rdmsrl(MSR_KERNEL_GS_BASE, gsbase);
+ return gsbase;
+}
+
+void x86_gsbase_write_cpu_inactive(unsigned long gsbase);
+
+#endif /* CONFIG_X86_64 */
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_FSGSBASE_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index ea5ea850348d..2a53ff8d1baf 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_IA32_EMULATION
/* Not included via unistd.h */
#include
@@ -286,6 +287,129 @@ static __always_inline void load_seg_legacy(unsigned
short prev_index,
}
}
+unsigned long x86_fsgsbase_read_task(struct task_struct *task,
+unsigned short selector)
+{
+ unsigned short idx = selector >> 3;
+ unsigned long base;
+
+ if (likely((selector & SEGMENT_TI_MASK) == 0)) {
+ if (unlikely(idx >= GDT_ENTRIES))
+ return 0;
+
+ /*
+* There are no user segments in the GDT with nonzero bases
+* other than the TLS segments.
+*/
+ if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
+ return 0;
+
+ idx -= GDT_ENTRY_TLS_MIN;
+ base = get_desc_base(>thread.tls_array[idx]);
+ } else {
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
+ struct ldt_struct *ldt;
+
+ /*
+* If performance here mattered, we could protect the LDT
+* with RCU. This is a slow path, though, so we can just
+* take the mutex.
+*/
+
Re: [PATCH v8 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On 08-10-18, 12:38, Niklas Cassel wrote: > On Mon, Oct 08, 2018 at 03:29:52PM +0530, Viresh Kumar wrote: > > On 08-10-18, 10:40, Niklas Cassel wrote: > > > > + ret = of_parse_phandle_with_args(cpu_np, > > > > "qcom,freq-domain", > > > > + "#freq-domain-cells", 0, ); > > > > > > Hello Taniya, > > > > > > in your DT binding, you use > > > > > > #freq-domains-cells = <1> > > > > > > Yet here you parse for "#freq-domain-cells". > > > > And what is the problem with that ? Or are you suggesting her to call > > of_parse_phandle_with_fixed_args() ? > > Hello Viresh, > > #freq-domain-cells != #freq-domains-cells > > The code should parse for the exact same property name as stated in the > DT binding. Oh, I missed that both the names are different here. It makes sense now :) -- viresh
[PATCH V2 1/1] MAINTAINERS: imx: include drivers/firmware/imx path
Due to newly added IMX SCU firmware support, let's add drivers/firmware/imx into maintainership. Cc: Shawn Guo Cc: Arnd Bergmann Cc: linux-kernel@vger.kernel.org Signed-off-by: Dong Aisheng --- v2: * add missing include/linux/firmware/imx --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9ad052a..eee17f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1462,7 +1462,9 @@ F:arch/arm/mach-mxs/ F: arch/arm/boot/dts/imx* F: arch/arm/configs/imx*_defconfig F: drivers/clk/imx/ +F: drivers/firmware/imx/ F: drivers/soc/imx/ +F: include/linux/firmware/imx/ F: include/soc/imx/ ARM/FREESCALE VYBRID ARM ARCHITECTURE -- 2.7.4
Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution
On Sat, Oct 6, 2018 at 4:10 AM Aleksa Sarai wrote:
> On 2018-10-05, Jann Horn wrote:
> > > What if we took rename_lock (call it nd->r_seq) at the start of the
> > > resolution, and then only tried the __d_path-style check
> > >
> > > if (read_seqretry(_lock, nd->r_seq) ||
> > > read_seqretry(_lock, nd->m_seq))
> > > /* do the __d_path lookup. */
> > >
> > > That way you would only hit the slow path if there were concurrent
> > > renames or mounts *and* you are doing a path resolution with
> > > AT_THIS_ROOT or AT_BENEATH. I've attached a modified patch that does
> > > this (and after some testing it also appears to work).
> >
> > Yeah, I think that might do the job.
>
> *phew* I was all out of other ideas. :P
>
> > > ---
> > > fs/namei.c | 49 ++---
> > > 1 file changed, 46 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 6f995e6de6b1..12c9be175cb4 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -493,7 +493,7 @@ struct nameidata {
> > > struct path root;
> > > struct inode*inode; /* path.dentry.d_inode */
> > > unsigned intflags;
> > > - unsignedseq, m_seq;
> > > + unsignedseq, m_seq, r_seq;
> > > int last_type;
> > > unsigneddepth;
> > > int total_link_count;
> > > @@ -1375,6 +1375,27 @@ static int follow_dotdot_rcu(struct nameidata *nd)
> > > return -EXDEV;
> > > break;
> > > }
> > > + if (unlikely((nd->flags & (LOOKUP_BENEATH |
> > > LOOKUP_CHROOT)) &&
> > > +(read_seqretry(_lock, nd->r_seq) ||
> > > + read_seqretry(_lock, nd->m_seq {
> > > + char *pathbuf, *pathptr;
> > > +
> > > + nd->r_seq = read_seqbegin(_lock);
> > > + /* Cannot take m_seq here. */
> > > +
> > > + pathbuf = kmalloc(PATH_MAX, GFP_ATOMIC);
> > > + if (!pathbuf)
> > > + return -ECHILD;
> > > + pathptr = __d_path(>path, >root, pathbuf,
> > > PATH_MAX);
> > > + kfree(pathbuf);
> >
> > You're doing this check before actually looking up the parent, right?
> > So as long as I don't trigger the "path_equal(>path, >root)"
> > check that you do for O_BENEATH, escaping up by one level is possible,
> > right? You should probably move this check so that it happens after
> > following "..".
>
> Yup, you're right. I'll do that.
>
> > (Also: I assume that you're going to get rid of that memory allocation
> > in a future version.)
>
> Sure. Would you prefer adding some scratch space in nameidata, or that I
> change __d_path so it accepts NULL as the buffer (and thus it doesn't
> actually do any string operations)?
Well, I think accepting a NULL buffer would be much cleaner; but keep
in mind that I'm just someone making suggestions, Al Viro is the one
who has to like your code. :P
> > > if (nd->path.dentry != nd->path.mnt->mnt_root) {
> > > int ret = path_parent_directory(>path);
> > > if (ret)
> > > @@ -2269,6 +2311,9 @@ static const char *path_init(struct nameidata *nd,
> > > unsigned flags)
> > > nd->last_type = LAST_ROOT; /* if there are only slashes... */
> > > nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT;
> > > nd->depth = 0;
> > > + nd->m_seq = read_seqbegin(_lock);
> > > + nd->r_seq = read_seqbegin(_lock);
> >
> > This means that now, attempting to perform a lookup while something is
> > holding the rename_lock will spin on the lock. I don't know whether
> > that's a problem in practice though. Does anyone on this thread know
> > whether this is problematic?
>
> I could make it so that we only take _lock
> if (nd->flags & (FOLLOW_BENEATH | FOLLOW_CHROOT)),
> since it's not used outside of that path.
I think that might be a sensible change; but as I said, I don't
actually know whether it's necessary, and it would be very helpful if
someone who actually knows commented on this.
Re: [PATCH v2 25/29] drm: sun4i: add quirks for TCON TOP
On Mon, Oct 8, 2018 at 6:20 PM Maxime Ripard wrote:
>
> On Mon, Oct 08, 2018 at 05:06:45PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Oct 8, 2018 at 4:51 PM Maxime Ripard
> > wrote:
> > >
> > > On Sun, Oct 07, 2018 at 11:39:01AM +0200, Jernej Skrabec wrote:
> > > > From: Icenowy Zheng
> > > >
> > > > Some SoCs, such as H6, doesn't have a full-featured TCON TOP.
> > > >
> > > > Add quirks support for TCON TOP.
> > > >
> > > > Currently the presence of TCON_TV1 and DSI is controlled via the quirks
> > > > structure.
> > > >
> > > > Signed-off-by: Icenowy Zheng
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 43 --
> > > > 1 file changed, 34 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > index 37158548b447..ed13233cad88 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > @@ -9,11 +9,17 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > #include "sun8i_tcon_top.h"
> > > >
> > > > +struct sun8i_tcon_top_quirks {
> > > > + bool has_tcon_tv1;
> > > > + bool has_dsi;
> > > > +};
> > > > +
> > > > static bool sun8i_tcon_top_node_is_tcon_top(struct device_node *node)
> > > > {
> > > > return !!of_match_node(sun8i_tcon_top_of_table, node);
> > > > @@ -121,10 +127,13 @@ static int sun8i_tcon_top_bind(struct device
> > > > *dev, struct device *master,
> > > > struct platform_device *pdev = to_platform_device(dev);
> > > > struct clk_hw_onecell_data *clk_data;
> > > > struct sun8i_tcon_top *tcon_top;
> > > > + const struct sun8i_tcon_top_quirks *quirks;
> > > > struct resource *res;
> > > > void __iomem *regs;
> > > > int ret, i;
> > > >
> > > > + quirks = of_device_get_match_data(>dev);
> > > > +
> > > > tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
> > > > if (!tcon_top)
> > > > return -ENOMEM;
> > > > @@ -187,15 +196,23 @@ static int sun8i_tcon_top_bind(struct device
> > > > *dev, struct device *master,
> > > >_top->reg_lock,
> > > >TCON_TOP_TCON_TV0_GATE, 0);
> > > >
> > > > - clk_data->hws[CLK_TCON_TOP_TV1] =
> > > > - sun8i_tcon_top_register_gate(dev, "tcon-tv1", regs,
> > > > - _top->reg_lock,
> > > > - TCON_TOP_TCON_TV1_GATE, 1);
> > > > + if (quirks->has_tcon_tv1) {
> > > > + clk_data->hws[CLK_TCON_TOP_TV1] =
> > > > + sun8i_tcon_top_register_gate(dev, "tcon-tv1",
> > > > regs,
> > > > + _top->reg_lock,
> > > > +
> > > > TCON_TOP_TCON_TV1_GATE, 1);
> > > > + } else {
> > > > + clk_data->hws[CLK_TCON_TOP_TV1] = NULL;
> > > > + }
> > > >
> > > > - clk_data->hws[CLK_TCON_TOP_DSI] =
> > > > - sun8i_tcon_top_register_gate(dev, "dsi", regs,
> > > > - _top->reg_lock,
> > > > - TCON_TOP_TCON_DSI_GATE, 2);
> > > > + if (quirks->has_dsi) {
> > > > + clk_data->hws[CLK_TCON_TOP_DSI] =
> > > > + sun8i_tcon_top_register_gate(dev, "dsi", regs,
> > > > + _top->reg_lock,
> > > > +
> > > > TCON_TOP_TCON_DSI_GATE, 2);
> > > > + } else {
> > > > + clk_data->hws[CLK_TCON_TOP_DSI] = NULL;
> > >
> > > clk_data has been kzalloc'd so its content is already NULL.
> > >
> > > And you shouldn't have brackets for single line blocks.
> > >
> > > with that fixed,
> >
> > FYI checkpatch.pl complains if you use brackets for the if block
> > but not for the else block. They should be matching.
>
> Checkpatch might not warn on this, but
> https://www.kernel.org/doc/Documentation/process/coding-style.rst,
> section 3 is pretty clear on whether we should use them or not.
Right. What I'm pointing out what checkpatch.pl complains about is
shown in the second last example in section 3:
This does not apply if only one branch of a conditional statement
is a single
statement; in the latter case use braces in both branches:
Which is where I think your comment on "shouldn't have brackets for
single line blocks"
is pointing in the opposite direction.
ChenYu
Re: [PATCH v11 1/3]: perf util: map data buffer for preserving collected data
On Mon, Oct 08, 2018 at 09:14:29AM +0300, Alexey Budankov wrote:
SNIP
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index be440df29615..af2f8c965d7a 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -1029,7 +1029,9 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
> unsigned int pages,
>* So should not be passed through const pointer.
>*/
> struct mmap_params mp;
> -
> +#ifdef HAVE_AIO_SUPPORT
> + mp.nr_cblocks = 0;
> +#endif
> if (!evlist->mmap)
> evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
> if (!evlist->mmap)
> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
> index cdb95b3a1213..db8f16f8a363 100644
> --- a/tools/perf/util/mmap.c
> +++ b/tools/perf/util/mmap.c
> @@ -153,8 +153,19 @@ void __weak auxtrace_mmap_params__set_idx(struct
> auxtrace_mmap_params *mp __mayb
> {
> }
>
> +#ifdef HAVE_AIO_SUPPORT
> +static void perf_mmap__aio_munmap(struct perf_mmap *map)
> +{
> + if (map->data)
> + zfree(>data);
> +}
if we really need to keep this optional for compilation,
please make it as single block with dummy functions
for when it's not compiled in, like:
#ifdef
static void perf_mmap__aio_munmap(struct perf_mmap *map)
{
if (map->data)
zfree(>data);
}
#else
static void perf_mmap__aio_munmap(struct perf_mmap *map) { }
#endif
thanks,
jirka
> +#endif
> +
> void perf_mmap__munmap(struct perf_mmap *map)
> {
> +#ifdef HAVE_AIO_SUPPORT
> + perf_mmap__aio_munmap(map);
> +#endif
> if (map->base != NULL) {
> munmap(map->base, perf_mmap__mmap_len(map));
> map->base = NULL;
> @@ -164,8 +175,40 @@ void perf_mmap__munmap(struct perf_mmap *map)
> auxtrace_mmap__munmap(>auxtrace_mmap);
> }
SNIP
Re: [PATCH v11 2/3]: perf record: enable asynchronous trace writing
On Mon, Oct 08, 2018 at 09:17:11AM +0300, Alexey Budankov wrote:
SNIP
> struct option;
> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
> index db8f16f8a363..ecaa5b5eb3ed 100644
> --- a/tools/perf/util/mmap.c
> +++ b/tools/perf/util/mmap.c
> @@ -367,6 +367,82 @@ int perf_mmap__push(struct perf_mmap *md, void *to,
> return rc;
> }
>
> +#ifdef HAVE_AIO_SUPPORT
> +int perf_mmap__aio_push(struct perf_mmap *md, void *to,
> + int push(void *to, struct aiocb *cblock, void *buf,
> size_t size, off_t off),
> + off_t *off)
> +{
seems like this could be defined static within builtin-record object,
is there a reason why it's in here?
thanks,
jirka
CHECKPATCH: strange warning on alignment modifier
Hi,
I have the following fragment of code:
+struct my_struct {
+ atomic_long_t l __aligned(sizeof(atomic_long_t));
+} __aligned(sizeof(atomic_long_t));
triggering this warning, when fed to checkpatch.pl:
WARNING: function definition argument 'atomic_long_t' should also have
an identifier name
#19: FILE: path/to/file.h
+ atomic_long_t l __aligned(sizeof(atomic_long_t));
gcc [(Ubuntu 7.3.0-16ubuntu3) 7.3.0] seems to be happy about it
I am using the HEAD from mainline.
My intent is to specify the alignment of both the field and the
structure (yes, probably redundant in this single-field case).
If I am doing something wrong, I can't figure out what it is, but I
don't understand why the WARNING is mentioning a function definition.
--
igor
Re: [PATCH v6 8/8] x86/vdso: Move out the CPU initialization
* Chang S. Bae wrote: > The CPU and node number will be written, as early enough, > to the segment limit of per CPU data and TSC_AUX MSR entry. > The information has been retrieved by vgetcpu in user space > and will be also loaded from the paranoid entry, when > FSGSBASE enabled. > > The new setup function is named after the getcpu(2) system > call, and will be called during each CPU initialization > (before setting up IST). It makes a facility useful to both > the kernel and userspace unconditionally available much > sooner. > > The change brings a substantial code removal. The redundant > setting of the segment in entry/vdso/vma.c and hotplug > notifier are removed. The title and the changelog is totally unreadable, full of grammar errors which makes it actively misleading... A good changelog should explain not what it does, but _why_ it is done: x86/vdso: Initialize the CPU/node NR segment descriptor earlier Currently the CPU/node NR segment descriptor (GDT_ENTRY_CPU_NUMBER) is initialized relatively late during CPU init, from the vCPU code, which has a number of disadvantages, such as hotplug CPU notifiers and SMP cross-calls. Instead just initialize it much earlier, directly in cpu_init(). This reduces complexity and increases robustness. I've edited the changelog, but please keep this in mind for future submissions. I also made a number of other cleanups to the code, will push them out after some testing. Thanks, Ingo
RE: Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm
>
>On 2018/10/08 15:14, Yong-Taek Lee wrote:
>>> On 2018/10/08 10:19, Yong-Taek Lee wrote:
@@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int
oom_adj, bool legacy)
struct mm_struct *mm = NULL;
struct task_struct *task;
int err = 0;
+ int mm_users = 0;
task = get_proc_task(file_inode(file));
if (!task)
@@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int
oom_adj, bool legacy)
struct task_struct *p = find_lock_task_mm(task);
if (p) {
- if (atomic_read(>mm->mm_users) > 1) {
+ mm_users = atomic_read(>mm->mm_users);
+ if ((mm_users > 1) && (mm_users !=
get_nr_threads(p))) {
>>>
>>> How can this work (even before this patch)? When clone(CLONE_VM without
>>> CLONE_THREAD/CLONE_SIGHAND)
>>> is requested, copy_process() calls copy_signal() in order to copy
>>> sig->oom_score_adj and
>>> sig->oom_score_adj_min before calling copy_mm() in order to increment
>>> mm->mm_users, doesn't it?
>>> Then, we will get two different "struct signal_struct" with different
>>> oom_score_adj/oom_score_adj_min
>>> but one "struct mm_struct" shared by two thread groups.
>>>
>>
>> Are you talking about race between __set_oom_adj and copy_process?
>> If so, i agree with your opinion. It can not set oom_score_adj properly for
>> copied process if __set_oom_adj
>> check mm_users before copy_process calls copy_mm after copy_signal. Please
>> correct me if i misunderstood anything.
>
> You understand it correctly.
>
> Reversing copy_signal() and copy_mm() is not sufficient either. We need to
> use a read/write lock
> (read lock for copy_process() and write lock for __set_oom_adj()) in order to
> make sure that
> the thread created by clone() becomes reachable from for_each_process() path
> in __set_oom_adj().
>
Thank you for your suggestion. But i think it would be better to seperate to 2
issues. How about think these
issues separately because there are no dependency between race issue and my
patch. As i already explained,
for_each_process path is meaningless if there is only one thread group with
many threads(mm_users > 1 but
no other thread group sharing same mm). Do you have any other idea to avoid
meaningless loop ?
>>
mm = p->mm;
atomic_inc(>mm_count);
}
>>
>
Re: linux-next: manual merge of the akpm tree with the jc_docs tree
On 08/10/2018 10:13, Mike Rapoport wrote:
> On Mon, Oct 08, 2018 at 06:38:40PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the akpm tree got conflicts in:
>>
>> Documentation/memory-hotplug.txt
>> Documentation/admin-guide/mm/memory-hotplug.rst
>>
>> between commits:
>>
>> 6bf53999a3a2 ("docs: move memory hotplug description into admin-guide/mm")
>> 98cee6742c80 ("docs/vm: split memory hotplug notifier description to
>> Documentation/core-api")
>>
>> from the jc_docs tree and patch:
>>
>> "memory-hotplug.txt: add some details about locking internals"
>>
>> from the akpm tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>
> Somehow I've managed to miss the patches from David :(
>
> I should have called the new
> Documentation/core-api/memory-hotplug-notifier.rst memory-hotplug.rst and
> then the details about locking would fit there just fine.
>
Yes, my changes certainly don't belong into the admin guide, so having
internal memory-hotplug.rst sounds good to me.
> I can do the renaming and add the patch
>
> "memory-hotplug.txt: add some details about locking internals"
>
> on top of the jc_docs tree.
>
> Does it sound Ok?
>
Fine with me.
Thanks!
--
Thanks,
David / dhildenb
Re: [PATCH V3 2/13] KVM/MMU: Add tlb flush with range helper function
Hi Paolo:
Thanks for your review. Sorry for later response due to holiday.
On Mon, Oct 1, 2018 at 11:26 PM Paolo Bonzini wrote:
>
> On 27/09/2018 05:48, Tianyu Lan wrote:
> > +
> > + if (range && kvm_x86_ops->tlb_remote_flush_with_range) {
> > + /*
> > + * Read tlbs_dirty before flushing tlbs in order
> > + * to track dirty tlbs during flushing.
> > + */
> > + long dirty_count = smp_load_acquire(>tlbs_dirty);
> > +
> > + ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
> > + cmpxchg(>tlbs_dirty, dirty_count, 0);
>
> This is wrong, because it's not the entire TLB that is flushed. So you
> cannot do the cmpxchg here.
Yes, nice catch. Will update in the next version.
--
Best regards
Tianyu Lan
Re: [PATCH AUTOSEL 4.18 28/48] sound: don't call skl_init_chip() to reset intel skl soc
On Mon, 08 Oct 2018 11:34:25 +0200,
Mark Brown wrote:
>
> On Fri, Oct 05, 2018 at 12:14:04PM -0400, Sasha Levin wrote:
> > From: Yu Zhao
> >
> > [ Upstream commit 75383f8d39d4c0fb96083dd460b7b139fbdac492 ]
> >
> > Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
> > 1) sets bus->chip_init to prevent multiple entrances before device
> > is stopped; 2) enables interrupt.
>
> And here.
This one should be OK as a stable fix, too.
thanks,
Takashi
> >
> > We shouldn't use it for the purpose of resetting device only because
> > 1) when we really want to initialize device, we won't be able to do
> > so; 2) we are ready to handle interrupt yet, and kernel crashes when
> > interrupt comes in.
> >
> > Rename azx_reset() to snd_hdac_bus_reset_link(), and use it to reset
> > device properly.
> >
> > Fixes: 60767abcea3d ("ASoC: Intel: Skylake: Reset the controller in probe")
> > Reviewed-by: Takashi Iwai
> > Signed-off-by: Yu Zhao
> > Signed-off-by: Mark Brown
> > Signed-off-by: Sasha Levin
> > ---
> > include/sound/hdaudio.h | 1 +
> > sound/hda/hdac_controller.c | 7 ---
> > sound/soc/intel/skylake/skl.c | 2 +-
> > 3 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
> > index c052afc27547..138e976a2ba2 100644
> > --- a/include/sound/hdaudio.h
> > +++ b/include/sound/hdaudio.h
> > @@ -355,6 +355,7 @@ void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus);
> > void snd_hdac_bus_stop_cmd_io(struct hdac_bus *bus);
> > void snd_hdac_bus_enter_link_reset(struct hdac_bus *bus);
> > void snd_hdac_bus_exit_link_reset(struct hdac_bus *bus);
> > +int snd_hdac_bus_reset_link(struct hdac_bus *bus, bool full_reset);
> >
> > void snd_hdac_bus_update_rirb(struct hdac_bus *bus);
> > int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int
> > status,
> > diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
> > index 11057d9f84ec..74244d8e2909 100644
> > --- a/sound/hda/hdac_controller.c
> > +++ b/sound/hda/hdac_controller.c
> > @@ -385,7 +385,7 @@ void snd_hdac_bus_exit_link_reset(struct hdac_bus *bus)
> > EXPORT_SYMBOL_GPL(snd_hdac_bus_exit_link_reset);
> >
> > /* reset codec link */
> > -static int azx_reset(struct hdac_bus *bus, bool full_reset)
> > +int snd_hdac_bus_reset_link(struct hdac_bus *bus, bool full_reset)
> > {
> > if (!full_reset)
> > goto skip_reset;
> > @@ -410,7 +410,7 @@ static int azx_reset(struct hdac_bus *bus, bool
> > full_reset)
> > skip_reset:
> > /* check to see if controller is ready */
> > if (!snd_hdac_chip_readb(bus, GCTL)) {
> > - dev_dbg(bus->dev, "azx_reset: controller not ready!\n");
> > + dev_dbg(bus->dev, "controller not ready!\n");
> > return -EBUSY;
> > }
> >
> > @@ -425,6 +425,7 @@ static int azx_reset(struct hdac_bus *bus, bool
> > full_reset)
> >
> > return 0;
> > }
> > +EXPORT_SYMBOL_GPL(snd_hdac_bus_reset_link);
> >
> > /* enable interrupts */
> > static void azx_int_enable(struct hdac_bus *bus)
> > @@ -479,7 +480,7 @@ bool snd_hdac_bus_init_chip(struct hdac_bus *bus, bool
> > full_reset)
> > return false;
> >
> > /* reset controller */
> > - azx_reset(bus, full_reset);
> > + snd_hdac_bus_reset_link(bus, full_reset);
> >
> > /* clear interrupts */
> > azx_int_clear(bus);
> > diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
> > index f0d9793f872a..c7cdfa4a7076 100644
> > --- a/sound/soc/intel/skylake/skl.c
> > +++ b/sound/soc/intel/skylake/skl.c
> > @@ -844,7 +844,7 @@ static int skl_first_init(struct hdac_ext_bus *ebus)
> > return -ENXIO;
> > }
> >
> > - skl_init_chip(bus, true);
> > + snd_hdac_bus_reset_link(bus, true);
> >
> > snd_hdac_bus_parse_capabilities(bus);
> >
> > --
> > 2.17.1
> >
> [2 signature.asc ]
>
Re: WARNING in request_end
syzbot has found a reproducer for the following crash on: HEAD commit:0238df646e62 Linux 4.19-rc7 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16daaa8540 kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d dashboard link: https://syzkaller.appspot.com/bug?extid=ef054c4d3f64cd7f7cec compiler: gcc (GCC) 8.0.1 20180413 (experimental) userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119bf2e640 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1760f80640 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ef054c4d3f64cd7f7...@syzkaller.appspotmail.com 8021q: adding VLAN 0 to HW filter on device team0 8021q: adding VLAN 0 to HW filter on device team0 WARNING: CPU: 1 PID: 7459 at fs/fuse/dev.c:390 request_end+0x82e/0xaa0 fs/fuse/dev.c:390 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 7459 Comm: syz-executor659 Not tainted 4.19.0-rc7+ #176 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x254/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:request_end+0x82e/0xaa0 fs/fuse/dev.c:390 Code: 3c 03 0f 8f 6f fe ff ff 48 8b bd f0 fe ff ff e8 78 63 3b ff e9 5e fe ff ff e8 1e f3 f7 fe 0f 0b e9 b0 fa ff ff e8 12 f3 f7 fe <0f> 0b e9 f0 fa ff ff e8 16 ca c1 fe e8 71 63 3b ff e9 5b fb ff ff RSP: 0018:8801c65e7328 EFLAGS: 00010293 RAX: 8801cd3362c0 RBX: 8801cba17000 RCX: 8286dd65 RDX: RSI: 8286e27e RDI: 0007 RBP: 8801c65e7458 R08: 8801cd3362c0 R09: ed00391cd5bf R10: ed00391cd5bf R11: 8801c8e6adfb R12: 110038cbce6a R13: 8801c8e6ad80 R14: 8801cba17030 R15: 8801c65e7430 fuse_dev_do_write+0x192e/0x36e0 fs/fuse/dev.c:1915 fuse_dev_write+0x19a/0x240 fs/fuse/dev.c:1939 call_write_iter include/linux/fs.h:1808 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6b8/0x9f0 fs/read_write.c:487 vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __ia32_sys_write+0x71/0xb0 fs/read_write.c:607 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline] do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7f43ca9 Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:f7efd1fc EFLAGS: 0246 ORIG_RAX: 0004 RAX: ffda RBX: 0003 RCX: 22c0 RDX: 0050 RSI: RDI: RBP: 003d0f00 R08: R09: R10: R11: R12: R13: R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH 1/2] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Marc, On Saturday 06 October 2018 03:32 PM, Marc Zyngier wrote: On Sat, 06 Oct 2018 08:28:11 +0100, Lokesh Vutla wrote: Add the DT binding documentation for Interrupt router driver. Signed-off-by: Lokesh Vutla --- .../interrupt-controller/ti,sci-intr.txt | 83 +++ MAINTAINERS | 1 + 2 files changed, 84 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt new file mode 100644 index ..681ca53cc5fb --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt @@ -0,0 +1,83 @@ +Texas Instruments K3 Interrupt Router += + +The Interrupt Router (INTR) module provides a mechanism to mux M +interrupt inputs to N interrupt outputs, where all M inputs are selectable +to be driven per N output. There is one register per output (MUXCNTL_N) that +controls the selection. + + + Interrupt Router + +--+ + | Inputs Outputs | ++---+| +--+ | +| GPIO |--->| | irq0 | | Host IRQ ++---+| +--+ | controller + |.+-+ | +---+ ++---+|.| 0 | |->| GIC | +| INTA |--->|.+-+ | +---+ ++---+|. . | + | +--+ . | + | | irqM |+-+ | + | +--+| N | | + | +-+ | + +--+ + +Configuration of these MUXCNTL_N registers is done by a system controller +(like the Device Memory and Security Controller on K3 AM654 SoC). System +controller will keep track of the used and unused registers within the Router. +Driver should request the system controller to get the range of GIC IRQs +assigned to the requesting hosts. It is the drivers responsibility to keep +track of GIC IRQs. I would drop the GIC here, and replace it by "parent interrupt controller", as nothing here is GIC specific + +Communication between the host processor running an OS and the system +controller happens through a protocol called TI System Control Interface +(TISCI protocol). For more details refer: +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt + +TISCI Interrupt Router Node: + +- compatible: Must be "ti,sci-intr". +- interrupt-controller:Identifies the node as an interrupt controller +- #interrupt-cells:Specifies the number of cells needed to encode an + interrupt source. The value should be 3. + First cell should contain the TISCI device ID of source + Second cell should contain the interrupt source offset + within the device + Third cell specifies the trigger type as defined + in interrupts.txt in this directory. Are all trigger types supported? Nope, only level interrupts are supported. Will fix it in v2. +- interrupt-parent:phandle of irq parent for TISCI intr. The parent must + use the same interrupt-cells format as GIC. Why that constraint? From what I can see, the two are fairly independent, and the constraint looks more of a Linux driver issue than a DT constraint. Driver when calling irq_domain_alloc_irqs_parent(), the fwspec node that gets passed assumes that parent is gic. parameters are filled in with such assumption. Do you suggest anything to make it more generic? +- ti,sci: Phandle to TI-SCI compatible System controller node. +- ti,sci-dst-id: TISCI device ID of the destination IRQ controller. +- ti,sci-rm-range-girq:Tuple corresponding to unique TISCI resource type that + defines the dst host irq ranges assigned to this + interrupt router from this host context. + Tuple should be of format . + Thanks a lot for the review. Also, I need a suggestion regarding one more interrupt controller(Interrupt Aggregator) on the same SoC controlled by TISCI_PROTOCOL. The Interrupt Aggregator (INTA) provides a centralized machine which handles the termination of system events to that they can be coherently processed by the host(s) in the system. Integration looks something similar https://pastebin.ubuntu.com/p/T32vbrwsch/ . Configuration of the Intmap registers that maps global
Re: [PATCH] media: vivid: Support 480p for webcam capture
On 08/10/18 10:00, Hans Verkuil wrote:
> On 10/08/2018 10:35 AM, Kieran Bingham wrote:
>> On 06/10/18 11:29, Keiichi Watanabe wrote:
>>> Hi all,
>>>
>>> On Fri, Oct 5, 2018 at 6:18 PM, Hans Verkuil wrote:
On 10/03/18 09:08, Keiichi Watanabe wrote:
> I think 480p is a common frame size and it's worth supporting in vivid.
> But, my patch might be ad-hoc. Actually, I'm not sure which values are
> suitable for the intervals.
I can apply this ad-hoc patch as-is.
Or do you want to postpone this and work on a more generic solution?
Although I am not sure what that would look like.
>>>
>>> I prefer providing a more flexible way rather than this ad-hoc patch.
>>> It would be helpful if there is a way of changing supported frame sizes
>>> easily.
>>> Perhaps, Kieran and me would use it, at least:)
>>>
>>
>> o/
>>
Proposals are welcome!
The main purpose of this code is to have something that kind of acts like
a real webcam that has various resolutions, and a slower framerate for
higher resolutions (as you would expect).
>>>
>>> This sounds reasonable, so I guess we can keep this way as default and
>>> provide a way for specifying extra frame sizes as an option.
>>>
>>> For example, how about a module option like this?
>>> "webcam_sizes=640x480@15,320x240@30"
>>>
>>> If this parameter is passed to vivid, vivid works like a webcam that
>>> supports the following 7 pairs of frame size and fps:
>>> - 5 pairs of frame sizes and fps, as with the current implementation
>>> - 640x480 (15fps)
>>> - 320x240 (30fps)
>>
>> I like the concept of being able to specify as a module parameter.
>>
>> Perhaps we could have a magic marker on the string to define if the
>> existing frame sizes should be kept - or if this is just a complete
>> override ?
>
> No, just override. It's hard otherwise since you would have to keep the
> lists sorted by resolution/fps.
>
> If you want to set it yourself, then just do a complete override.
OK. That's reasonable for me.
@@ -9,3 +9,0 @@ suggestion
- magic-marker
>> vivid.webcam=640x480@15,320x240@30 # Specify sizes explicitly
>> vivid.webcam=+640x480@15,320x240@30 # Append to existing frames
>> ^ Magic Marker
>>
>> We might of course want multiple rates per frame,
>>
>> vivid.webcam=640x480@15-25-30-90-120, # Separator to be defined...
>
> Stick to @, so: vivid.webcam=640x480@15@25@30@90@120
Yes, of course that makes a lot more sense now I see it :-)
--
Kieran
> This looks like a good proposal to me.
>
> BTW, I still would like to add 640x480 added to the default list:
> it's a common resolution and it makes sense to add it.
>
> So I plan to accept the patch regardless.
>
> Regards,
>
> Hans
>
>>
>>
>>>
>>> If this parameter is not passed, vivid's behavior won't change from
>>> the current one.
>>>
>>> How do you think?
>>>
>>> We might want to stop using the default framesizes, i.e. vivid only
>>> supports framesize/fps that passed as the option.
>>> But, if we do so, the parameter will become mandatory and it would be
>>> annoying.
>>
>> I think mandatory would be annoying yes.
>>
>> Thus my suggestion for a magic marker above :)
>>
>> --
>> Kieran
>>
>>
>>> So, I personally like to keep the default framesizes.
>>>
>>> Best regards,
>>> Kei
>>>
Regards,
Hans
>
> We might want to add a more flexible/extensible way to specify frame
> sizes.
> e.g. passing frame sizes and intervals as module parameters
>
> Kei
>
> On Wed, Oct 3, 2018 at 4:06 PM, Keiichi Watanabe
> wrote:
>> Support 640x480 as a frame size for video input devices of vivid.
>>
>> Signed-off-by: Keiichi Watanabe
>> ---
>> drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
>> b/drivers/media/platform/vivid/vivid-vid-cap.c
>> index 58e14dd1dcd3..da80bf4bc365 100644
>> --- a/drivers/media/platform/vivid/vivid-vid-cap.c
>> +++ b/drivers/media/platform/vivid/vivid-vid-cap.c
>> @@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
>> };
>>
>> /* The number of discrete webcam framesizes */
>> -#define VIVID_WEBCAM_SIZES 5
>> +#define VIVID_WEBCAM_SIZES 6
>> /* The number of discrete webcam frameintervals */
>> #define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
>>
>> @@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
>> static const struct v4l2_frmsize_discrete
>> webcam_sizes[VIVID_WEBCAM_SIZES] = {
>> { 320, 180 },
>> { 640, 360 },
>> + { 640, 480 },
>> { 1280, 720 },
>> { 1920, 1080 },
>> { 3840, 2160 },
>> @@ -75,6 +76,8 @@ static const struct v4l2_fract
>> webcam_intervals[VIVID_WEBCAM_IVALS] = {
>> { 1, 5 },
