[PATCH V4 RESEND 2/3] arm64: dts: imx8qxp: Move watchdog node into scu node
From: Anson Huang
i.MX system controller watchdog has pretimeout function which
depends on i.MX SCU driver, so it should be a subnode of SCU.
Signed-off-by: Anson Huang
---
No change, just rebase the patch to top of linux-next.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index fbfae90..9f52da6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -157,6 +157,11 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ timeout-sec = <60>;
+ };
};
timer {
@@ -525,9 +530,4 @@
power-domains = <&pd IMX_SC_R_GPIO_7>;
};
};
-
- watchdog {
- compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
- timeout-sec = <60>;
- };
};
--
2.7.4
[PATCH V4 RESEND 3/3] watchdog: imx_sc: Add pretimeout support
From: Anson Huang
i.MX system controller watchdog can support pretimeout IRQ
via general SCU MU IRQ, it depends on IMX_SCU and driver MUST
be probed after SCU IPC ready, then enable corresponding SCU
IRQ group and register SCU IRQ notifier, when watchdog pretimeout
IRQ fires, SCU MU IRQ will be handled and watchdog pretimeout
notifier will be called to handle the event.
Signed-off-by: Anson Huang
Reviewed-by: Guenter Roeck
---
No change, just rebase the patch to top of linux-next.
---
drivers/watchdog/Kconfig | 1 +
drivers/watchdog/imx_sc_wdt.c | 116 +++---
2 files changed, 98 insertions(+), 19 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ffe7545..975e573 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -717,6 +717,7 @@ config IMX2_WDT
config IMX_SC_WDT
tristate "IMX SC Watchdog"
depends on HAVE_ARM_SMCCC
+ depends on IMX_SCU
select WATCHDOG_CORE
help
This is the driver for the system controller watchdog
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
index 49848b6..6ecc03f 100644
--- a/drivers/watchdog/imx_sc_wdt.c
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -33,11 +34,19 @@
#define SC_TIMER_WDOG_ACTION_PARTITION 0
+#define SC_IRQ_WDOG1
+#define SC_IRQ_GROUP_WDOG 1
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, );
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+struct imx_sc_wdt_device {
+ struct watchdog_device wdd;
+ struct notifier_block wdt_notifier;
+};
+
static int imx_sc_wdt_ping(struct watchdog_device *wdog)
{
struct arm_smccc_res res;
@@ -85,24 +94,66 @@ static int imx_sc_wdt_set_timeout(struct watchdog_device
*wdog,
return res.a0 ? -EACCES : 0;
}
+static int imx_sc_wdt_set_pretimeout(struct watchdog_device *wdog,
+unsigned int pretimeout)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_PRETIME_WDOG,
+ pretimeout * 1000, 0, 0, 0, 0, 0, &res);
+ if (res.a0)
+ return -EACCES;
+
+ wdog->pretimeout = pretimeout;
+
+ return 0;
+}
+
+static int imx_sc_wdt_notify(struct notifier_block *nb,
+unsigned long event, void *group)
+{
+ struct imx_sc_wdt_device *imx_sc_wdd =
+container_of(nb,
+ struct imx_sc_wdt_device,
+ wdt_notifier);
+
+ if (event & SC_IRQ_WDOG &&
+ *(u8 *)group == SC_IRQ_GROUP_WDOG)
+ watchdog_notify_pretimeout(&imx_sc_wdd->wdd);
+
+ return 0;
+}
+
+static void imx_sc_wdt_action(void *data)
+{
+ struct notifier_block *wdt_notifier = data;
+
+ imx_scu_irq_unregister_notifier(wdt_notifier);
+ imx_scu_irq_group_enable(SC_IRQ_GROUP_WDOG,
+SC_IRQ_WDOG,
+false);
+}
+
static const struct watchdog_ops imx_sc_wdt_ops = {
.owner = THIS_MODULE,
.start = imx_sc_wdt_start,
.stop = imx_sc_wdt_stop,
.ping = imx_sc_wdt_ping,
.set_timeout = imx_sc_wdt_set_timeout,
+ .set_pretimeout = imx_sc_wdt_set_pretimeout,
};
-static const struct watchdog_info imx_sc_wdt_info = {
+static struct watchdog_info imx_sc_wdt_info = {
.identity = "i.MX SC watchdog timer",
.options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
- WDIOF_MAGICCLOSE | WDIOF_PRETIMEOUT,
+ WDIOF_MAGICCLOSE,
};
static int imx_sc_wdt_probe(struct platform_device *pdev)
{
+ struct imx_sc_wdt_device *imx_sc_wdd;
+ struct watchdog_device *wdog;
struct device *dev = &pdev->dev;
- struct watchdog_device *imx_sc_wdd;
int ret;
imx_sc_wdd = devm_kzalloc(dev, sizeof(*imx_sc_wdd), GFP_KERNEL);
@@ -111,42 +162,69 @@ static int imx_sc_wdt_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, imx_sc_wdd);
- imx_sc_wdd->info = &imx_sc_wdt_info;
- imx_sc_wdd->ops = &imx_sc_wdt_ops;
- imx_sc_wdd->min_timeout = 1;
- imx_sc_wdd->max_timeout = MAX_TIMEOUT;
- imx_sc_wdd->parent = dev;
- imx_sc_wdd->timeout = DEFAULT_TIMEOUT;
+ wdog = &imx_sc_wdd->wdd;
+ wdog->info = &imx_sc_wdt_info;
+ wdog->ops = &imx_sc_wdt_ops;
+ wdog->min_timeout = 1;
+ wdog->max_timeout = MAX_TIMEOUT;
+ wdog->parent = dev;
+ wdog->timeout = DEFAULT_TIMEOUT;
- watchdog_init_timeout(imx_sc_wdd, 0, dev);
- watchdog_stop_on_reboot(imx_sc_wdd);
- watchdog_stop_on_unre
[PATCH V4 RESEND 1/3] dt-bindings: watchdog: move i.MX system controller watchdog binding to SCU
From: Anson Huang
i.MX system controller watchdog depends on SCU driver to support
interrupt function, so it needs to be subnode of SCU node in DT,
binding doc should be moved to fsl,scu.txt as well.
Signed-off-by: Anson Huang
Reviewed-by: Rob Herring
---
No changes, just rebase the patch to top of linux-next.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 15 ++
.../bindings/watchdog/fsl-imx-sc-wdt.txt | 24 --
2 files changed, 15 insertions(+), 24 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index f378922..a575e42 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -145,6 +145,16 @@ Optional Child nodes:
- Data cells of ocotp:
Detailed bindings are described in bindings/nvmem/nvmem.txt
+Watchdog bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+ "fsl,imx8qxp-sc-wdt"
+ followed by "fsl,imx-sc-wdt";
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
Example (imx8qxp):
-
aliases {
@@ -207,6 +217,11 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ timeout-sec = <60>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
b/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
deleted file mode 100644
index 02b87e9..000
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-sc-wdt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Freescale i.MX System Controller Watchdog
-
-i.MX system controller watchdog is for i.MX SoCs with system controller inside,
-the watchdog is managed by system controller, users can ONLY communicate with
-system controller from secure mode for watchdog operations, so Linux i.MX
system
-controller watchdog driver will call ARM SMC API and trap into
ARM-Trusted-Firmware
-for watchdog operations, ARM-Trusted-Firmware is running at secure EL3 mode and
-it will request system controller to execute the watchdog operation passed from
-Linux kernel.
-
-Required properties:
-- compatible: Should be :
- "fsl,imx8qxp-sc-wdt"
- followed by "fsl,imx-sc-wdt";
-
-Optional properties:
-- timeout-sec : Contains the watchdog timeout in seconds.
-
-Examples:
-
-watchdog {
- compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
- timeout-sec = <60>;
-};
--
2.7.4
Re: [PATCH 7/8] cpufreq: mediatek: add opp notification for SVS support
On Thu, May 16, 2019 at 9:08 AM Andrew-sh.Cheng wrote: > bool need_voltage_tracking; > + struct mutex lock; /* avoid notify and policy race condition */ > + struct notifier_block opp_nb; > + int opp_cpu; > + unsigned long opp_freq; > }; > > static LIST_HEAD(dvfs_info_list); > @@ -239,6 +243,7 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy > *policy, > vproc = dev_pm_opp_get_voltage(opp); > dev_pm_opp_put(opp); > > + mutex_lock(&info->lock); Should init mutex, otherwise it'll get lockdep warning: [0.587055] Call trace: [0.587069] dump_backtrace+0x0/0x168 [0.587077] show_stack+0x20/0x2c [0.587086] dump_stack+0xe4/0x134 [0.587095] register_lock_class+0x3e8/0x4b0 [0.587103] __lock_acquire+0xac/0x14e8 [0.587110] lock_acquire+0x1d0/0x208 [0.587118] __mutex_lock_common+0xc0/0xb40 [0.587126] mutex_lock_nested+0x40/0x50 [0.587135] mtk_cpufreq_set_target+0xcc/0x2a8 [0.587143] __cpufreq_driver_target+0x438/0x4d8 [0.587150] cpufreq_online+0x5b4/0x6e0 [0.587156] cpufreq_add_dev+0x4c/0x84 [0.587164] subsys_interface_register+0xb8/0x10c [0.587171] cpufreq_register_driver+0x11c/0x1c0 [0.587178] mtk_cpufreq_probe+0x378/0x4b8 [0.587185] platform_drv_probe+0x80/0xb0 [0.587192] really_probe+0x114/0x28c [0.587198] driver_probe_device+0x64/0xfc [0.587205] __device_attach_driver+0xb8/0xd0 [0.587211] bus_for_each_drv+0x88/0xd0 [0.587218] __device_attach+0xb0/0x134 [0.587224] device_initial_probe+0x20/0x2c [0.587230] bus_probe_device+0x34/0x94 [0.587238] device_add+0x520/0x5b4 [0.587245] platform_device_add+0x17c/0x208 [0.587252] platform_device_register_full+0xc0/0x100 [0.587261] mtk_cpufreq_driver_init+0x8c/0xdc [0.587268] do_one_initcall+0x1c0/0x3e0 [0.587276] do_initcall_level+0x1f4/0x224 [0.587282] do_basic_setup+0x34/0x4c [0.587288] kernel_init_freeable+0x10c/0x194 [0.587295] kernel_init+0x14/0x100 [0.587302] ret_from_fork+0x10/0x18 [0.587510] cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 1248000 KHz
Re: [PATCH] mm: mlockall error for flag MCL_ONFAULT
On Fri 24-05-19 17:43:04, Daniel Jordan wrote: > [ Adding linux-api and some of the people who were involved in the > MCL_ONFAULT/mlock2/etc discussions. Author of the Fixes patch appears to > have moved on. ] > > On Wed, May 22, 2019 at 11:23:37AM +, Potyra, Stefan wrote: > > If mlockall() is called with only MCL_ONFAULT as flag, > > it removes any previously applied lockings and does > > nothing else. > > The change looks reasonable. Hard to imagine any application relies on it, > and > they really shouldn't be if they are. Debian codesearch turned up only a few > cases where stress-ng was doing this for unknown reasons[1] and this change > isn't gonna break those. In this case I think changing the syscall's behavior > is justified. > > > This behavior is counter-intuitive and doesn't match the > > Linux man page. > > I'd quote it for the changelog: > > For mlockall(): > > EINVAL Unknown flags were specified or MCL_ONFAULT was specified with‐ > out either MCL_FUTURE or MCL_CURRENT. > > With that you can add > > Reviewed-by: Daniel Jordan > > [1] > https://sources.debian.org/src/stress-ng/0.09.50-1/stress-mlock.c/?hl=203#L203 Well spotted and the fix looks reasonable as well. Quoting the man page seems useful as well. Acked-by: Michal Hocko Thanks! -- Michal Hocko SUSE Labs
[PATCH V2] arm64/mm: Change BUG_ON() to VM_BUG_ON() in [pmd|pud]_set_huge()
There are no callers for the functions which will pass unaligned physical addresses. Hence just change these BUG_ON() checks into VM_BUG_ON() which gets compiled out unless CONFIG_VM_DEBUG is enabled. Signed-off-by: Anshuman Khandual Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Ard Biesheuvel --- Changes in V2: - Use VM_BUG_ON() instead of BUG_ON() as per Ard Biesheuvel arch/arm64/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index a1bfc44..2637ff3 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -980,7 +980,7 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot) pud_val(new_pud))) return 0; - BUG_ON(phys & ~PUD_MASK); + VM_BUG_ON(phys & ~PUD_MASK); set_pud(pudp, new_pud); return 1; } @@ -996,7 +996,7 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot) pmd_val(new_pmd))) return 0; - BUG_ON(phys & ~PMD_MASK); + VM_BUG_ON(phys & ~PMD_MASK); set_pmd(pmdp, new_pmd); return 1; } -- 2.7.4
Re: [PATCH 1/2 v2] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
On 24.05.19 15:46, Andy Shevchenko wrote:
On Fri, May 24, 2019 at 01:29:34PM +0200, Stefan Roese wrote:
On 24.05.19 13:11, Andy Shevchenko wrote:
On Fri, May 24, 2019 at 1:21 PM Mika Westerberg
wrote:
On Fri, May 24, 2019 at 11:48:24AM +0200, Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
support is added (2nd patch in this patch series) on x86 platforms using
ACPI.
Here Mika's comments from 2016-08-09:
"
I noticed that with v4.8-rc1 serial console of some of our Broxton
systems does not work properly anymore. I'm able to see output but input
does not work.
I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
("tty/serial/8250: use mctrl_gpio helpers").
The reason why it fails is that in ACPI we do not have names for GPIOs
(except when _DSD is used) so we use the "idx" to index into _CRS GPIO
resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
UART device in Broxton has following (simplified) ACPI description:
Device (URT4)
{
...
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x003A
}
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x003D
}
})
In this case it finds the first GPIO (0x003A which happens to be RX pin
for that UART), turns it into GPIO which then breaks input for the UART
device. This also breaks systems with bluetooth connected to UART (those
typically have some GPIOs in their _CRS).
Any ideas how to fix this?
We cannot just drop the _CRS index lookup fallback because that would
break many existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
We have a board where ASL provides _DSD for CTS and RxD pins.
I'm afraid this won't work on it.
With "won't work" you mean, that the GPIO can't be used for modem
control in this case in the current implementation (with this
patchset)? Or do you mean, that the breakage (input does not work
on Broxton systems) will not be solved by this patch?
It will solve RxD case, due to mctrl doesn't count RxD as a "control" line.
Though we have CTS pin defined for the same purpose, which means the hardware
flow control won't work on a subset of Broxton boards.
If its the former, then I think that solving this issue is something
for a new patch, to support modem-control on such platforms as well
(if needed).
Please note that this patch is not trying to get modem-control working
on such ACPI based systems.
I understand that. At the same time it should not break existing systems.
Its targeted for device-tree enabled
platforms, using the 8250 serial driver, here specifically a MIPS
MT7688 based board. And just wants to fix the latter issue mentioned
above so that the 8250 modem-control support can be accepted in
mainline.
As I said already we have to distinguish *the purpose* of these GPIOs.
(like CTS).
Can we apply this if and only if the device has no ACPI companion device?
In this case DT will work as you expect and ACPI won't be broken.
So your suggestion is to add a has_acpi_companion() check before
mctrl_gpio_init() is called in serial8250_register_8250_port() and
then only use the gpio related mctrl, if the GPIO's are really used?
I can certainly change patch 2/2 to do this. It would be great though,
if you (or someone else) could test this on such a ACPI based platform,
as I don't have access to such a board.
Thanks,
Stefan
Re: [v6 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
Yang Shi writes:
> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
> and some other vm counters still get inc'ed by one even though a whole
> THP (512 pages) gets swapped out.
>
> This doesn't make too much sense to memory reclaim. For example, direct
> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
> could fulfill it. But, if nr_reclaimed is not increased correctly,
> direct reclaim may just waste time to reclaim more pages,
> SWAP_CLUSTER_MAX * 512 pages in worst case.
>
> And, it may cause pgsteal_{kswapd|direct} is greater than
> pgscan_{kswapd|direct}, like the below:
>
> pgsteal_kswapd 122933
> pgsteal_direct 26600225
> pgscan_kswapd 174153
> pgscan_direct 14678312
>
> nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
> break some page reclaim logic, e.g.
>
> vmpressure: this looks at the scanned/reclaimed ratio so it won't
> change semantics as long as scanned & reclaimed are fixed in parallel.
>
> compaction/reclaim: compaction wants a certain number of physical pages
> freed up before going back to compacting.
>
> kswapd priority raising: kswapd raises priority if we scan fewer pages
> than the reclaim target (which itself is obviously expressed in order-0
> pages). As a result, kswapd can falsely raise its aggressiveness even
> when it's making great progress.
>
> Other than nr_scanned and nr_reclaimed, some other counters, e.g.
> pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
> too since they are user visible via cgroup, /proc/vmstat or trace
> points, otherwise they would be underreported.
>
> When isolating pages from LRUs, nr_taken has been accounted in base
> page, but nr_scanned and nr_skipped are still accounted in THP. It
> doesn't make too much sense too since this may cause trace point
> underreport the numbers as well.
>
> So accounting those counters in base page instead of accounting THP as
> one page.
>
> nr_dirty, nr_unqueued_dirty, nr_congested and nr_writeback are used by
> file cache, so they are not impacted by THP swap.
>
> This change may result in lower steal/scan ratio in some cases since
> THP may get split during page reclaim, then a part of tail pages get
> reclaimed instead of the whole 512 pages, but nr_scanned is accounted
> by 512, particularly for direct reclaim. But, this should be not a
> significant issue.
>
> Cc: "Huang, Ying"
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: "Kirill A . Shutemov"
> Cc: Hugh Dickins
> Cc: Shakeel Butt
> Cc: Hillf Danton
> Signed-off-by: Yang Shi
> ---
> v6: Fixed the other double account issue introduced by v5 per Huang Ying
> v5: Fixed sc->nr_scanned double accounting per Huang Ying
> Added some comments to address the concern about premature OOM per Hillf
> Danton
> v4: Fixed the comments from Johannes and Huang Ying
> v3: Removed Shakeel's Reviewed-by since the patch has been changed
> significantly
> Switched back to use compound_order per Matthew
> Fixed more counters per Johannes
> v2: Added Shakeel's Reviewed-by
> Use hpage_nr_pages instead of compound_order per Huang Ying and William
> Kucharski
>
> mm/vmscan.c | 47 +++
> 1 file changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b65bc50..378edff 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1118,6 +1118,7 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> int may_enter_fs;
> enum page_references references = PAGEREF_RECLAIM_CLEAN;
> bool dirty, writeback;
> + unsigned int nr_pages;
>
> cond_resched();
>
> @@ -1129,7 +1130,10 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
>
> VM_BUG_ON_PAGE(PageActive(page), page);
>
> - sc->nr_scanned++;
> + nr_pages = 1 << compound_order(page);
> +
> + /* Account the number of base pages even though THP */
> + sc->nr_scanned += nr_pages;
>
> if (unlikely(!page_evictable(page)))
> goto activate_locked;
> @@ -1250,7 +1254,7 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> case PAGEREF_ACTIVATE:
> goto activate_locked;
> case PAGEREF_KEEP:
> - stat->nr_ref_keep++;
> + stat->nr_ref_keep += nr_pages;
> goto keep_locked;
> case PAGEREF_RECLAIM:
> case PAGEREF_RECLAIM_CLEAN:
> @@ -1306,6 +1310,15 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> }
>
> /*
> + * THP may get split above, need minus tail pages and update
> + * nr_pages to avoid accounting tail pages twice.
> +
Re: [PATCH v3 2/2] arm64: cacheinfo: Update cache_line_size detected from DT or PPTT
Hi Greg,
On 2019/5/27 14:08, Greg KH wrote:
> On Mon, May 27, 2019 at 10:06:08AM +0800, Shaokun Zhang wrote:
>> cache_line_size is derived from CTR_EL0.CWG field and is called mostly
>> for I/O device drivers. For HiSilicon certain plantform, like the
>> Kunpeng920 server SoC, cache line sizes are different between L1/2
>> cache and L3 cache while L1 cache line size is 64-byte and L3 is 128-byte,
>> but CTR_EL0.CWG is misreporting using L1 cache line size.
>>
>> We shall correct the right value which is important for I/O performance.
>> Let's update the cache line size if it is detected from DT or PPTT
>> information.
>>
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Sudeep Holla
>> Cc: Jeremy Linton
>> Cc: Zhenfa Qiu
>> Reported-by: Zhenfa Qiu
>> Suggested-by: Catalin Marinas
>> Signed-off-by: Shaokun Zhang
>> ---
>> arch/arm64/include/asm/cache.h | 6 +-
>> arch/arm64/kernel/cacheinfo.c | 11 +++
>> 2 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
>> index 926434f413fa..758af6340314 100644
>> --- a/arch/arm64/include/asm/cache.h
>> +++ b/arch/arm64/include/asm/cache.h
>> @@ -91,11 +91,7 @@ static inline u32 cache_type_cwg(void)
>>
>> #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>>
>> -static inline int cache_line_size(void)
>> -{
>> -u32 cwg = cache_type_cwg();
>> -return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
>> -}
>> +int cache_line_size(void);
>>
>> /*
>> * Read the effective value of CTR_EL0.
>> diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
>> index 0bf0a835122f..3d54b0024246 100644
>> --- a/arch/arm64/kernel/cacheinfo.c
>> +++ b/arch/arm64/kernel/cacheinfo.c
>> @@ -28,6 +28,17 @@
>> #define CLIDR_CTYPE(clidr, level) \
>> (((clidr) & CLIDR_CTYPE_MASK(level)) >> CLIDR_CTYPE_SHIFT(level))
>>
>> +int cache_line_size(void)
>> +{
>> +u32 cwg = cache_type_cwg();
>> +
>> +if (coherency_max_size != 0)
>> +return coherency_max_size;
>
> Ah, you use it here.
>
Yeah, we check it here.
>> +
>> +return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
>
> Shouldn't you set the variable if it is 0 here as well?
>
As discussed this with Catalin,
https://www.spinics.net/lists/arm-kernel/msg723848.html
I think it is unnecessary, if coherency_max_size is not detected from firmware,
We will return the cpu core reporting value as the cache line size and
coherency_max_size won't be used in other place.
>> +}
>> +EXPORT_SYMBOL(cache_line_size);
>
> EXPORT_SYMBOL_GPL()?
>
Ok.
Thanks,
Shaokun
> thanks,
>
> greg k-h
>
> .
>
Re: [PATCH v18 1/3] proc: add /proc//arch_status
On 2019/5/24 11:18, Andrew Morton wrote: > On Thu, 25 Apr 2019 22:32:17 +0800 Aubrey Li > wrote: > >> The architecture specific information of the running processes >> could be useful to the userland. Add /proc//arch_status >> interface support to examine process architecture specific >> information externally. > > I'll give this an > > Acked-by: Andrew Morton Thanks! > > from a procfs POV and shall let the x86 maintainers worry about it. > > I must say I'm a bit surprised that we don't already provide some form > of per-process CPU-specific info anywhere in procfs. Something to > piggy-back this onto. But I can't find such a thing. > > I assume we've already discussed why this is a new procfs file rather > than merely a new line in /proc//status. If so, please add the > reasoning to the changelog. If not, please discuss now ;) > Andy and Thomas may want to give more comments. The discussion was that we don't want /proc/PID/status to be different on different architectures. It would be better to separate the arch staff into its own file /proc/PID/ arch_status and make sure that everything in it is namespaced. Thanks, -Aubrey
Re: [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
On Wed 22-05-19 17:42:13, Mark Rutland wrote: > On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote: > > On Thu 16-05-19 11:23:54, Mark Rutland wrote: > > > Hi Michal, > > > > > > On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote: > > > > On Tue 14-05-19 14:30:05, Anshuman Khandual wrote: > > > > > The arm64 pagetable dump code can race with concurrent modification > > > > > of the > > > > > kernel page tables. When a leaf entries are modified concurrently, > > > > > the dump > > > > > code may log stale or inconsistent information for a VA range, but > > > > > this is > > > > > otherwise not harmful. > > > > > > > > > > When intermediate levels of table are freed, the dump code will > > > > > continue to > > > > > use memory which has been freed and potentially reallocated for > > > > > another > > > > > purpose. In such cases, the dump code may dereference bogus > > > > > addressses, > > > > > leading to a number of potential problems. > > > > > > > > > > Intermediate levels of table may by freed during memory hot-remove, > > > > > or when > > > > > installing a huge mapping in the vmalloc region. To avoid racing with > > > > > these > > > > > cases, take the memory hotplug lock when walking the kernel page > > > > > table. > > > > > > > > Why is this a problem only on arm64 > > > > > > It looks like it's not -- I think we're just the first to realise this. > > > > > > AFAICT x86's debugfs ptdump has the same issue if run conccurently with > > > memory hot remove. If 32-bit arm supported hot-remove, its ptdump code > > > would have the same issue. > > > > > > > and why do we even care for debugfs? Does anybody rely on this thing > > > > to be reliable? Do we even need it? Who is using the file? > > > > > > The debugfs part is used intermittently by a few people working on the > > > arm64 kernel page tables. We use that both to sanity-check that kernel > > > page tables are created/updated correctly after changes to the arm64 mmu > > > code, and also to debug issues if/when we encounter issues that appear > > > to be the result of kernel page table corruption. > > > > OK, I see. Thanks for the clarification. > > > > > So while it's rare to need it, it's really useful to have when we do > > > need it, and I'd rather not remove it. I'd also rather that it didn't > > > have latent issues where we can accidentally crash the kernel when using > > > it, which is what this patch is addressing. > > > > While I agree, do we rather want to document that you shouldn't be using > > the debugging tool while the hotplug is ongoing because you might get a > > garbage or crash the kernel in the worst case? In other words is the > > absolute correctness worth the additional maint. burden wrt. to future > > hotplug changes? > > I don't think that it's reasonable for this code to bring down the > kernel unless the kernel page tables are already corrupt. I agree we > should minimize the impact on other code, and I'm happy to penalize > ptdump so long as it's functional and safe. > > I would like it to be possible to use the ptdump code to debug > hot-remove, so I'd rather not make the two mutually exclusive. I'd also > like it to be possible to use this in-the-field, and for that asking an > admin to potentially crash their system isn't likely to fly. OK, fair enough. > > > > I am asking because I would really love to make mem hotplug locking less > > > > scattered outside of the core MM than more. Most users simply shouldn't > > > > care. Pfn walkers should rely on pfn_to_online_page. > > Jut to check, is your plan to limit access to the hotplug lock, or to > redesign the locking scheme? To change the locking to lock hotpluged ranges rather than having a global lock as the operation is inherently pfn range scoped. > > > I'm not sure if that would help us here; IIUC pfn_to_online_page() alone > > > doesn't ensure that the page remains online. Is there a way to achieve > > > that other than get_online_mems()? > > > > You have to pin the page to make sure the hotplug is not going to > > offline it. > > I'm not exactly sure how pinning works -- is there a particular set of > functions I should look at for that? Pinning (get_page) on any page of the range will deffer the hotremove operation and therefore the page tables cannot go away as well. That being said, I thought the API is mostly for debugging and "you should better know what you are doing" kinda thing (based on debugfs being used here). If this is really useful in its current form and should be used also while the hotremove is in progress then ok. Once we actually get to rework the locking then we will have another spot to handle but that's the life. -- Michal Hocko SUSE Labs
[PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()
The `resource` in do_prlimit() is controlled by userspace via syscall:
setrlimit(defined in kernel/sys.c), hence leading to a potential exploitation
of the Spectre variant 1 vulnerability.
The relevant code in do_prlimit() is as below：
if (resource >= RLIM_NLIMITS)
return -EINVAL;
...
rlim = tsk->signal->rlim + resource;// use resource as index
...
*old_rlim = *rlim;
Fix this by sanitizing resource before using it to index tsk->signal->rlim.
Signed-off-by: Dianzhang Chen
---
kernel/sys.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sys.c b/kernel/sys.c
index bdbfe8d..7eba1ca 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1532,6 +1532,8 @@ int do_prlimit(struct task_struct *tsk, unsigned int
resource,
if (resource >= RLIM_NLIMITS)
return -EINVAL;
+
+ resource = array_index_nospec(resource, RLIM_NLIMITS);
if (new_rlim) {
if (new_rlim->rlim_cur > new_rlim->rlim_max)
return -EINVAL;
--
2.7.4
Re: [PATCH v1 4/6] dmaengine: fsl-edma: add i.mx7ulp edma2 version support
On 2019-05-27 at 06:34 +, Vinod Koul wrote:
> On 10-05-19, 10:14, Robin Gong wrote:
> >
> >
> > + if (of_device_is_compatible(np, "fsl,imx7ulp-edma")) {
> > + fsl_edma->dmamux_nr = 1;
> > + fsl_edma->version = v3;
> well this is not really scalable, we will keep adding versions and
> compatible and expanding this check. So it would make sense to create
> a
> driver data table which can be set for compatible and we use those
> values and avoid these runtime checks for compatible.
>
> Btw the binding documentation should precede the code usage, so this
> patch should come after that
>
Okay, will update in v2.
Re: [PATCH 3/4] staging: kpc2000: add missing spaces in core.c
On Fri, May 24, 2019 at 01:08:01PM +0200, Simon Sandström wrote:
> Fixes checkpatch.pl errors "space required before the open brace '{'"
> and "(foo*)" should be "(foo *)".
>
> Signed-off-by: Simon Sandström
> ---
> drivers/staging/kpc2000/kpc2000/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/kpc2000/kpc2000/core.c
> b/drivers/staging/kpc2000/kpc2000/core.c
> index 40f65f96986b..bb3b427a72b1 100644
> --- a/drivers/staging/kpc2000/kpc2000/core.c
> +++ b/drivers/staging/kpc2000/kpc2000/core.c
> @@ -308,7 +308,7 @@ static long kp2000_cdev_ioctl(struct file *filp, unsigned
> int ioctl_num,
>
> dev_dbg(&pcard->pdev->dev, "kp2000_cdev_ioctl(filp = [%p], ioctl_num =
> 0x%08x, ioctl_param = 0x%016lx) pcard = [%p]\n", filp, ioctl_num,
> ioctl_param, pcard);
>
> - switch (ioctl_num){
> + switch (ioctl_num) {
> case KP2000_IOCTL_GET_CPLD_REG: return
> readq(pcard->sysinfo_regs_base + REG_CPLD_CONFIG);
> case KP2000_IOCTL_GET_PCIE_ERROR_REG: return
> readq(pcard->sysinfo_regs_base + REG_PCIE_ERROR_COUNT);
>
> @@ -326,7 +326,7 @@ static long kp2000_cdev_ioctl(struct file *filp, unsigned
> int ioctl_num,
> temp.ddna = pcard->ddna;
> temp.cpld_reg = readq(pcard->sysinfo_regs_base +
> REG_CPLD_CONFIG);
>
> - ret = copy_to_user((void*)ioctl_param, (void*)&temp,
> sizeof(temp));
> + ret = copy_to_user((void *)ioctl_param, (void *)&temp,
> sizeof(temp));
> if (ret)
> return -EFAULT;
This should really be written like so:
if (copy_to_user((void __user *)ioctl_param, &temp,
sizeof(temp)))
return -EFAULT;
temp is really the wrong name. "temp" is for temperatures. "tmp" means
temporary. But also "tmp" is wrong here because it's not a temporary
variable. It's better to call it "regs" here.
regards,
dan carpenter
Re: [PATCH 1/1] eventfd new tag EFD_VPOLL: generate epoll events
On Sun, May 26, 2019 at 04:25:21PM +0200, Renzo Davoli wrote:
> This patch implements an extension of eventfd to define file descriptors
> whose I/O events can be generated at user level. These file descriptors
> trigger notifications for [p]select/[p]poll/epoll.
>
> This feature is useful for user-level implementations of network stacks
> or virtual device drivers as libraries.
How can this be used to create a "virtual device driver"? Do you have
any examples of this new interface being used anywhere?
Also, meta-comment, you should provide some sort of test to kselftests
for your new feature so that it can actually be tested, as well as a man
page update (separately).
> Development and porting of code often requires to find the way to wait for I/O
> events both coming from file descriptors and generated by user-level code
> (e.g.
> user-implemented net stacks or drivers). While it is possible to provide a
> partial support (e.g. using pipes or socketpairs), a clean and complete
> solution is still missing (as far as I have seen); e.g. I have not seen any
> clean way to generate EPOLLPRI, EPOLLERR, etc.
What's wrong with pipes or sockets for stuff like this? Why is epoll
required?
> This proposal is based on a new tag for eventfd2(2): EFD_VPOLL.
>
> This statement:
> fd = eventfd(EPOLLOUT, EFD_VPOLL | EFD_CLOEXEC);
> creates a file descriptor for I/O event generation. In this case EPOLLOUT is
> initially true.
>
> Likewise all the other eventfs services, read(2) and write(2) use a 8-byte
> integer argument.
>
> read(2) returns the current state of the pending events.
>
> The argument of write(2) is an or-composition of a control command
> (EFD_VPOLL_ADDEVENTS, EFD_VPOLL_DELEVENTS or EFD_VPOLL_MODEVENTS) and the
> bitmap of events to be added, deleted to the current set of pending events.
> EFD_VPOLL_MODEVENTS completely redefines the set of pending events.
>
> e.g.:
> uint64_t request = EFD_VPOLL_ADDEVENTS | EPOLLIN | EPOLLPRI;
> write(fd, &request, sizeof(request);
> adds EPOLLIN and EPOLLPRI to the set of pending events.
>
> These are examples of messages asking for a feature like EFD_VPOLL:
> https://stackoverflow.com/questions/909189/simulating-file-descriptor-in-user-space
> https://stackoverflow.com/questions/1648147/running-a-simple-tcp-server-with-poll-how-do-i-trigger-events-artificially
> ... and I need it to write networking and device modules for vuos:
> https://github.com/virtualsquare/vuos
> (it is the new codebase of ViewOS, see www.virtualsquare.org).
>
> EXAMPLE:
> The following program creates an eventfd/EFD_VPOLL file descriptor and then
> forks
> a child process. While the parent waits for events using epoll_wait the child
> generates a sequence of events. When the parent receives an event (or a set
> of events)
> it prints it and disarm it.
> The following shell session shows a sample run of the program:
> timeout...
> timeout...
> GOT event 1
> timeout...
> GOT event 1
> timeout...
> GOT event 3
> timeout...
> GOT event 2
> timeout...
> GOT event 4
> timeout...
> GOT event 10
>
> Program source:
> #include
> #include
> #include
> #include
> #include
> #include /* Definition of uint64_t */
>
> #ifndef EFD_VPOLL
> #define EFD_VPOLL (1 << 1)
> #define EFD_VPOLL_ADDEVENTS (1UL << 32)
> #define EFD_VPOLL_DELEVENTS (2UL << 32)
> #define EFD_VPOLL_MODEVENTS (3UL << 32)
> #endif
>
> #define handle_error(msg) \
> do { perror(msg); exit(EXIT_FAILURE); } while (0)
>
> static void vpoll_ctl(int fd, uint64_t request) {
> ssize_t s;
> s = write(fd, &request, sizeof(request));
> if (s != sizeof(uint64_t))
> handle_error("write");
> }
>
> int
> main(int argc, char *argv[])
> {
> int efd, epollfd;
> struct epoll_event ev;
> ev.events = EPOLLIN | EPOLLRDHUP | EPOLLERR | EPOLLOUT | EPOLLHUP |
> EPOLLPRI;
> ev.data.u64 = 0;
>
> efd = eventfd(0, EFD_VPOLL | EFD_CLOEXEC);
> if (efd == -1)
> handle_error("eventfd");
> epollfd = epoll_create1(EPOLL_CLOEXEC);
> if (efd == -1)
> handle_error("epoll_create1");
> if (epoll_ctl(epollfd, EPOLL_CTL_ADD, efd, &ev) == -1)
> handle_error("epoll_ctl");
>
> switch (fork()) {
> case 0:
> sleep(3);
> vpoll_ctl(efd, EFD_VPOLL_ADDEVENTS | EPOLLIN);
> sleep(2);
> vpoll_ctl(efd, EFD_VPOLL_ADDEVENTS | EPOLLIN);
> sleep(2);
> vpoll_ctl(efd, EFD_VPOLL_ADDEVENTS | EPOLLIN |
> EPOLLPRI);
> sleep(2);
> vpoll_ctl(efd, EFD_VPOLL_ADDEVENTS | EPOLLPRI);
> sleep(2);
> vpoll_ctl(efd, EFD_VPOLL_ADDEVENTS | EPOLLOUT);
> sleep(2);
> vpo
Re: [PATCH][next] ASoC: cx2072x: fix spelling mistake "configued" -> "configured"
On Sat, 25 May 2019 22:32:44 +0200,
Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err error message. Fit it.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Takashi Iwai
thanks,
Takashi
> ---
> sound/soc/codecs/cx2072x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c
> index e8e6fd2e97b6..f25376789c5c 100644
> --- a/sound/soc/codecs/cx2072x.c
> +++ b/sound/soc/codecs/cx2072x.c
> @@ -933,7 +933,7 @@ static int cx2072x_hw_params(struct snd_pcm_substream
> *substream,
> return frame_size;
>
> if (cx2072x->mclk_rate == 0) {
> - dev_err(dev, "Master clock rate is not configued\n");
> + dev_err(dev, "Master clock rate is not configured\n");
> return -EINVAL;
> }
>
> --
> 2.20.1
>
>
Re: [PATCH -next] ASoC: cx2072x: remove set but not used variable 'is_right_j '
On Sat, 25 May 2019 14:32:04 +0200, YueHaibing wrote: > > Fixes gcc '-Wunused-but-set-variable' warning: > > sound/soc/codecs/cx2072x.c: In function cx2072x_config_i2spcm: > sound/soc/codecs/cx2072x.c:679:6: warning: variable is_right_j set but not > used [-Wunused-but-set-variable] > > It's never used and can be removed. > > Signed-off-by: YueHaibing Reviewed-by: Takashi Iwai thanks, Takashi > --- > sound/soc/codecs/cx2072x.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c > index 23d2b25fe04c..a066ef83de1a 100644 > --- a/sound/soc/codecs/cx2072x.c > +++ b/sound/soc/codecs/cx2072x.c > @@ -676,7 +676,6 @@ static int cx2072x_config_i2spcm(struct cx2072x_priv > *cx2072x) > unsigned int bclk_rate = 0; > int is_i2s = 0; > int has_one_bit_delay = 0; > - int is_right_j = 0; > int is_frame_inv = 0; > int is_bclk_inv = 0; > int pulse_len = 1; > @@ -740,7 +739,6 @@ static int cx2072x_config_i2spcm(struct cx2072x_priv > *cx2072x) > > case SND_SOC_DAIFMT_RIGHT_J: > is_i2s = 1; > - is_right_j = 1; > pulse_len = frame_len / 2; > break; > > -- > 2.17.1 > > >
Re: [PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()
On Mon, May 27, 2019 at 03:23:08PM +0800, Dianzhang Chen wrote:
> The `resource` in do_prlimit() is controlled by userspace via syscall:
> setrlimit(defined in kernel/sys.c), hence leading to a potential exploitation
> of the Spectre variant 1 vulnerability.
> The relevant code in do_prlimit() is as below：
>
> if (resource >= RLIM_NLIMITS)
> return -EINVAL;
> ...
> rlim = tsk->signal->rlim + resource;// use resource as index
> ...
> *old_rlim = *rlim;
>
> Fix this by sanitizing resource before using it to index tsk->signal->rlim.
>
> Signed-off-by: Dianzhang Chen
> ---
> kernel/sys.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index bdbfe8d..7eba1ca 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1532,6 +1532,8 @@ int do_prlimit(struct task_struct *tsk, unsigned int
> resource,
>
> if (resource >= RLIM_NLIMITS)
> return -EINVAL;
> +
> + resource = array_index_nospec(resource, RLIM_NLIMITS);
> if (new_rlim) {
> if (new_rlim->rlim_cur > new_rlim->rlim_max)
> return -EINVAL;
Could you please explain in details how array_index_nospec is different
from resource >= RLIM_NLIMITS? Since I don't get how it is related to
spectre issue.
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On 5/27/19 5:51 AM, Tomasz Figa wrote: > On Tue, May 21, 2019 at 9:27 PM Hans Verkuil wrote: >> >> On 5/21/19 11:09 AM, Tomasz Figa wrote: >>> Hi Stan, >>> >>> On Mon, May 20, 2019 at 11:47 PM Stanimir Varbanov >>> wrote: Hi Tomasz, On 4/24/19 3:39 PM, Tomasz Figa wrote: > On Wed, Apr 24, 2019 at 9:15 PM Stanimir Varbanov > wrote: >> >> Hi Hans, >> >> On 2/15/19 3:44 PM, Hans Verkuil wrote: >>> Hi Stanimir, >>> >>> I never paid much attention to this patch series since others were busy >>> discussing it and I had a lot of other things on my plate, but then I >>> heard >>> that this patch made G_FMT blocking. >> >> OK, another option could be to block REQBUF(CAPTURE) until event from hw >> is received that the stream is parsed and the resolution is correctly >> set by application. Just to note that I'd think to this like a temporal >> solution until gstreamer implements v4l events. >> >> Is that looks good to you? > > Hmm, I thought we concluded that gstreamer sets the width and height > in OUTPUT queue before querying the CAPTURE queue and so making the > driver calculate the CAPTURE format based on what's set on OUTPUT > would work fine. Did I miss something? Nobody is miss something. First some background about how Venus implements stateful codec API. The Venus firmware can generate two events "sufficient" and "insufficient" buffer requirements (this includes decoder output buffer size and internal/scratch buffer sizes). Presently I always set minimum possible decoder resolution no matter what the user said, and by that way I'm sure that "insufficient" event will always be triggered by the firmware (the other reason to take this path is because this is the least-common-divider for all supported Venus hw/fw versions thus common code in the driver). The reconfiguration (during codec Initialization sequence) is made from STREAMON(CAPTURE) context. Now, to make that re-configuration happen I need to wait for "insufficient" event from firmware in order to know the real coded resolution. In the case of gstreamer where v4l2_events support is missing I have to block (wait for firmware event) REQBUF(CAPTURE) (vb2::queue_setup) or STREAMON(CAPTURE) (vb2::start_streaming). I tried to set the coded resolution to the firmware as-is it set by gstreamer but then I cannot receive the "sufficient" event for VP8 and VP9 codecs. So I return back to the solution with minimum resolution above. I'm open for suggestions. >>> >>> I think you could still keep setting the minimum size and wait for the >>> "insufficient" event. At the same time, you could speculatively >>> advertise the expected "sufficient" size on the CAPTURE queue before >>> the hardware signals those. Even if you mispredict them, you'll get >>> the event, update the CAPTURE resolution and send the source change >>> event to the application, which would then give you the correct >>> buffers. Would that work for you? >> >> As I understand it this still would require event support, which gstreamer >> doesn't have. > > I don't think it matches what I remember from the earlier discussion. > As long as Gstreamer sets the visible resolution (from the container > AFAIR) on OUTPUT, the driver would adjust it to something that is > expected to be the right framebuffer resolution and so Gstreamer would > be able to continue. Of course if the expected value doesn't match, it > wouldn't work, but it's the same as currently for Coda AFAICT. > >> >> I think it is OK to have REQBUFS sleep in this case. However, I would only > > Why REQBUFS? While that could possibly allow us to allocate the right > buffers, Gstreamer wouldn't be able to know the right format, because > it would query it before REQBUFS, wouldn't it? Oops, you are right. It's got to be in G_FMT(CAPTURE), but *only* if nobody subscribed to the SOURCE_CHANGE event. > > For this reason, s5p-mfc makes G_FMT(CAPTURE) blocking and if we > decide to forcefully keep the compatibility, even with in drivers, we > should probably do the same here. > >> enable this behavior if the application didn't subscribe to the SOURCE_CHANGE >> event. That's easy enough to check in the driver. And that means that if the >> application is well written, then the driver will behave in a completely >> standard way that the compliance test can check. > > I guess one could have some helpers for this. They would listen to the > source change events internally and block / wake-up appropriate ioctls > whenever necessary. I really do not want this for new drivers. gstreamer should be fixed. A blocking G_FMT is just plain bad. Only those drivers that do this, can still block if nobody subscribed to EVENT_SOURCE_CHANGE. > Another question: If we intend this to be implemented in new drivers >
Re: [v6 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
On 5/27/19 3:06 PM, Huang, Ying wrote:
Yang Shi writes:
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
And, it may cause pgsteal_{kswapd|direct} is greater than
pgscan_{kswapd|direct}, like the below:
pgsteal_kswapd 122933
pgsteal_direct 26600225
pgscan_kswapd 174153
pgscan_direct 14678312
nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
break some page reclaim logic, e.g.
vmpressure: this looks at the scanned/reclaimed ratio so it won't
change semantics as long as scanned & reclaimed are fixed in parallel.
compaction/reclaim: compaction wants a certain number of physical pages
freed up before going back to compacting.
kswapd priority raising: kswapd raises priority if we scan fewer pages
than the reclaim target (which itself is obviously expressed in order-0
pages). As a result, kswapd can falsely raise its aggressiveness even
when it's making great progress.
Other than nr_scanned and nr_reclaimed, some other counters, e.g.
pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
too since they are user visible via cgroup, /proc/vmstat or trace
points, otherwise they would be underreported.
When isolating pages from LRUs, nr_taken has been accounted in base
page, but nr_scanned and nr_skipped are still accounted in THP. It
doesn't make too much sense too since this may cause trace point
underreport the numbers as well.
So accounting those counters in base page instead of accounting THP as
one page.
nr_dirty, nr_unqueued_dirty, nr_congested and nr_writeback are used by
file cache, so they are not impacted by THP swap.
This change may result in lower steal/scan ratio in some cases since
THP may get split during page reclaim, then a part of tail pages get
reclaimed instead of the whole 512 pages, but nr_scanned is accounted
by 512, particularly for direct reclaim. But, this should be not a
significant issue.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: Hillf Danton
Signed-off-by: Yang Shi
---
v6: Fixed the other double account issue introduced by v5 per Huang Ying
v5: Fixed sc->nr_scanned double accounting per Huang Ying
Added some comments to address the concern about premature OOM per Hillf
Danton
v4: Fixed the comments from Johannes and Huang Ying
v3: Removed Shakeel's Reviewed-by since the patch has been changed significantly
Switched back to use compound_order per Matthew
Fixed more counters per Johannes
v2: Added Shakeel's Reviewed-by
Use hpage_nr_pages instead of compound_order per Huang Ying and William
Kucharski
mm/vmscan.c | 47 +++
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b65bc50..378edff 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1118,6 +1118,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
int may_enter_fs;
enum page_references references = PAGEREF_RECLAIM_CLEAN;
bool dirty, writeback;
+ unsigned int nr_pages;
cond_resched();
@@ -1129,7 +1130,10 @@ static unsigned long shrink_page_list(struct list_head *page_list,
VM_BUG_ON_PAGE(PageActive(page), page);
- sc->nr_scanned++;
+ nr_pages = 1 << compound_order(page);
+
+ /* Account the number of base pages even though THP */
+ sc->nr_scanned += nr_pages;
if (unlikely(!page_evictable(page)))
goto activate_locked;
@@ -1250,7 +1254,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
case PAGEREF_ACTIVATE:
goto activate_locked;
case PAGEREF_KEEP:
- stat->nr_ref_keep++;
+ stat->nr_ref_keep += nr_pages;
goto keep_locked;
case PAGEREF_RECLAIM:
case PAGEREF_RECLAIM_CLEAN:
@@ -1306,6 +1310,15 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
}
/*
+* THP may get split above, need minus tail pages and update
+* nr_pages to avoid accounting tail pages twice.
+*/
+ if ((nr_pages > 1) && !PageTransHuge(page)) {
+ sc->nr_scanned -= (nr_pages - 1);
+ nr_pages = 1;
+ }
Re: [RFC 5/7] mm: introduce external memory hinting API
Sorry for the late response. I miseed your comment. :(
On Tue, May 21, 2019 at 05:31:13PM +0200, Oleg Nesterov wrote:
> On 05/20, Minchan Kim wrote:
> >
> > + rcu_read_lock();
> > + tsk = pid_task(pid, PIDTYPE_PID);
> > + if (!tsk) {
> > + rcu_read_unlock();
> > + goto err;
> > + }
> > + get_task_struct(tsk);
> > + rcu_read_unlock();
> > + mm = mm_access(tsk, PTRACE_MODE_ATTACH_REALCREDS);
> > + if (!mm || IS_ERR(mm)) {
> > + ret = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH;
> > + if (ret == -EACCES)
> > + ret = -EPERM;
> > + goto err;
> > + }
> > + ret = madvise_core(tsk, start, len_in, behavior);
>
> IIUC, madvise_core(tsk) plays with tsk->mm->mmap_sem. But this tsk can exit
> and
> nullify its ->mm right after mm_access() succeeds.
You're absolutely right. I will fix it via passing mm_struct instead of
task_struct.
Thanks!
>
> another problem is that pid_task(pid) can return a zombie leader, in this case
> mm_access() will fail while it shouldn't.
I'm sorry. I didn't notice that. However, I couldn't understand your point.
Why do you think mm_access shouldn't fail even though pid_task returns
a zombie leader? I thought it's okay since the target process is exiting
so hinting operation would be meaniness for the process.
Re: [PATCH v2 02/10] media: rc: sunxi: Add A31 compatible
Hi,
On Mon, May 27, 2019 at 12:25:28AM +0200, Clément Péron wrote:
> Allwiner A31 has a different memory mapping so add the compatible
> we will need it later.
>
> Signed-off-by: Clément Péron
> ---
> drivers/media/rc/sunxi-cir.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 307e44714ea0..29ac33b68596 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -319,6 +319,7 @@ static int sunxi_ir_remove(struct platform_device *pdev)
> static const struct of_device_id sunxi_ir_match[] = {
> { .compatible = "allwinner,sun4i-a10-ir", },
> { .compatible = "allwinner,sun5i-a13-ir", },
> + { .compatible = "allwinner,sun6i-a31-ir", },
We should also move from reset_get_optional to the non optional
variant for the A31, and ignore it otherwise.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: Issue with Broadcom wireless in 5.2rc1 (was Re: [PATCH] mmc: sdhci: queue work after sdhci_defer_done())
On 26/05/19 10:58 PM, Brian Masney wrote:
> On Sun, May 26, 2019 at 08:42:21PM +0200, Arend Van Spriel wrote:
>> On 5/26/2019 2:21 PM, Brian Masney wrote:
>>> + Broadcom wireless maintainers
>>>
>>> On Fri, May 24, 2019 at 11:49:58AM -0400, Brian Masney wrote:
On Fri, May 24, 2019 at 03:17:13PM +0300, Adrian Hunter wrote:
> On 24/05/19 2:10 PM, Brian Masney wrote:
>> WiFi stopped working on the LG Nexus 5 phone and the issue was bisected
>> to the commit c07a48c26519 ("mmc: sdhci: Remove finish_tasklet") that
>> moved from using a tasklet to a work queue. That patch also changed
>> sdhci_irq() to return IRQ_WAKE_THREAD instead of finishing the work when
>> sdhci_defer_done() is true. Change it to queue work to the complete work
>> queue if sdhci_defer_done() is true so that the functionality is
>> equilivent to what was there when the finish_tasklet was present. This
>> corrects the WiFi breakage on the Nexus 5 phone.
>>
>> Signed-off-by: Brian Masney
>> Fixes: c07a48c26519 ("mmc: sdhci: Remove finish_tasklet")
>> ---
>> [ ... ]
>>
>> drivers/mmc/host/sdhci.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 97158344b862..3563c3bc57c9 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -3115,7 +3115,7 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
>> continue;
>> if (sdhci_defer_done(host, mrq)) {
>> -result = IRQ_WAKE_THREAD;
>> +queue_work(host->complete_wq,
>> &host->complete_work);
>
> The IRQ thread has a lot less latency than the work queue, which is why it
> is done that way.
>
> I am not sure why you say this change is equivalent to what was there
> before, nor why it fixes your problem.
>
> Can you explain some more?
[ ... ]
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c calls
sdio_claim_host() and it appears to never return.
This is because SDHCI is using the IRQ thread to process the SDIO card
interrupt (sdio_run_irqs()). When the card driver tries to use the card, it
causes interrupts which deadlocks since c07a48c26519 ("mmc: sdhci: Remove
finish_tasklet") has moved the tasklet processing to the IRQ thread.
I would expect to be able to use the IRQ thread to complete requests, and it
is desirable to do so because it is lower latency.
Probably, SDHCI should use sdio_signal_irq() which queues a work item, and
is what other drivers are doing.
I will investigate some more and send a patch.
Re: [RFC 6/7] mm: extend process_madvise syscall to support vector arrary
On Tue, May 21, 2019 at 12:37:26PM +0200, Michal Hocko wrote: > On Tue 21-05-19 19:26:13, Minchan Kim wrote: > > On Tue, May 21, 2019 at 08:24:21AM +0200, Michal Hocko wrote: > > > On Tue 21-05-19 11:48:20, Minchan Kim wrote: > > > > On Mon, May 20, 2019 at 11:22:58AM +0200, Michal Hocko wrote: > > > > > [Cc linux-api] > > > > > > > > > > On Mon 20-05-19 12:52:53, Minchan Kim wrote: > > > > > > Currently, process_madvise syscall works for only one address range > > > > > > so user should call the syscall several times to give hints to > > > > > > multiple address range. > > > > > > > > > > Is that a problem? How big of a problem? Any numbers? > > > > > > > > We easily have 2000+ vma so it's not trivial overhead. I will come up > > > > with number in the description at respin. > > > > > > Does this really have to be a fast operation? I would expect the monitor > > > is by no means a fast path. The system call overhead is not what it used > > > to be, sigh, but still for something that is not a hot path it should be > > > tolerable, especially when the whole operation is quite expensive on its > > > own (wrt. the syscall entry/exit). > > > > What's different with process_vm_[readv|writev] and vmsplice? > > If the range needed to be covered is a lot, vector operation makes senese > > to me. > > I am not saying that the vector API is wrong. All I am trying to say is > that the benefit is not really clear so far. If you want to push it > through then you should better get some supporting data. I measured 1000 madvise syscall vs. a vector range syscall with 1000 ranges on ARM64 mordern device. Even though I saw 15% improvement but absoluate gain is just 1ms so I don't think it's worth to support. I will drop vector support at next revision. Thanks for the review, Michal!
Re: lib/test_overflow.c causes WARNING and tainted kernel
On 25/05/2019 17.33, Randy Dunlap wrote: > On 3/13/19 7:53 PM, Kees Cook wrote: >> Hi! >> >> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap wrote: >>> >>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT. >>> >>> In the first test_kmalloc() in test_overflow_allocation(): >>> >>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0 >>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 >>> __alloc_pages_nodemask+0x33f/0x540 >>> [...] >>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]--- >>> [54375.079313] test_overflow: kmalloc detected saturation >> >> Yup! This is expected and operating as intended: it is exercising the >> allocator's detection of insane allocation sizes. :) >> >> If we want to make it less noisy, perhaps we could add a global flag >> the allocators could check before doing their WARNs? >> >> -Kees > > I didn't like that global flag idea. I also don't like the kernel becoming > tainted by this test. Me neither. Can't we pass __GFP_NOWARN from the testcases, perhaps with a module parameter to opt-in to not pass that flag? That way one can make the overflow module built-in (and thus run at boot) without automatically tainting the kernel. The vmalloc cases do not take gfp_t, would they still cause a warning? BTW, I noticed that the 'wrap to 8K' depends on 64 bit and pagesize==4096; for 32 bit the result is 20K, while if the pagesize is 64K one gets 128K and 512K for 32/64 bit size_t, respectively. Don't know if that's a problem, but it's easy enough to make it independent of pagesize (just make it 9*4096 explicitly), and if we use 5 instead of 9 it also becomes independent of sizeof(size_t) (wrapping to 16K). Rasmus
Re: [v6 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
Yang Shi writes:
> On 5/27/19 3:06 PM, Huang, Ying wrote:
>> Yang Shi writes:
>>
>>> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
>>> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
>>> and some other vm counters still get inc'ed by one even though a whole
>>> THP (512 pages) gets swapped out.
>>>
>>> This doesn't make too much sense to memory reclaim. For example, direct
>>> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
>>> could fulfill it. But, if nr_reclaimed is not increased correctly,
>>> direct reclaim may just waste time to reclaim more pages,
>>> SWAP_CLUSTER_MAX * 512 pages in worst case.
>>>
>>> And, it may cause pgsteal_{kswapd|direct} is greater than
>>> pgscan_{kswapd|direct}, like the below:
>>>
>>> pgsteal_kswapd 122933
>>> pgsteal_direct 26600225
>>> pgscan_kswapd 174153
>>> pgscan_direct 14678312
>>>
>>> nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
>>> break some page reclaim logic, e.g.
>>>
>>> vmpressure: this looks at the scanned/reclaimed ratio so it won't
>>> change semantics as long as scanned & reclaimed are fixed in parallel.
>>>
>>> compaction/reclaim: compaction wants a certain number of physical pages
>>> freed up before going back to compacting.
>>>
>>> kswapd priority raising: kswapd raises priority if we scan fewer pages
>>> than the reclaim target (which itself is obviously expressed in order-0
>>> pages). As a result, kswapd can falsely raise its aggressiveness even
>>> when it's making great progress.
>>>
>>> Other than nr_scanned and nr_reclaimed, some other counters, e.g.
>>> pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
>>> too since they are user visible via cgroup, /proc/vmstat or trace
>>> points, otherwise they would be underreported.
>>>
>>> When isolating pages from LRUs, nr_taken has been accounted in base
>>> page, but nr_scanned and nr_skipped are still accounted in THP. It
>>> doesn't make too much sense too since this may cause trace point
>>> underreport the numbers as well.
>>>
>>> So accounting those counters in base page instead of accounting THP as
>>> one page.
>>>
>>> nr_dirty, nr_unqueued_dirty, nr_congested and nr_writeback are used by
>>> file cache, so they are not impacted by THP swap.
>>>
>>> This change may result in lower steal/scan ratio in some cases since
>>> THP may get split during page reclaim, then a part of tail pages get
>>> reclaimed instead of the whole 512 pages, but nr_scanned is accounted
>>> by 512, particularly for direct reclaim. But, this should be not a
>>> significant issue.
>>>
>>> Cc: "Huang, Ying"
>>> Cc: Johannes Weiner
>>> Cc: Michal Hocko
>>> Cc: Mel Gorman
>>> Cc: "Kirill A . Shutemov"
>>> Cc: Hugh Dickins
>>> Cc: Shakeel Butt
>>> Cc: Hillf Danton
>>> Signed-off-by: Yang Shi
>>> ---
>>> v6: Fixed the other double account issue introduced by v5 per Huang Ying
>>> v5: Fixed sc->nr_scanned double accounting per Huang Ying
>>> Added some comments to address the concern about premature OOM per
>>> Hillf Danton
>>> v4: Fixed the comments from Johannes and Huang Ying
>>> v3: Removed Shakeel's Reviewed-by since the patch has been changed
>>> significantly
>>> Switched back to use compound_order per Matthew
>>> Fixed more counters per Johannes
>>> v2: Added Shakeel's Reviewed-by
>>> Use hpage_nr_pages instead of compound_order per Huang Ying and
>>> William Kucharski
>>>
>>> mm/vmscan.c | 47 +++
>>> 1 file changed, 35 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>> index b65bc50..378edff 100644
>>> --- a/mm/vmscan.c
>>> +++ b/mm/vmscan.c
>>> @@ -1118,6 +1118,7 @@ static unsigned long shrink_page_list(struct
>>> list_head *page_list,
>>> int may_enter_fs;
>>> enum page_references references = PAGEREF_RECLAIM_CLEAN;
>>> bool dirty, writeback;
>>> + unsigned int nr_pages;
>>> cond_resched();
>>> @@ -1129,7 +1130,10 @@ static unsigned long
>>> shrink_page_list(struct list_head *page_list,
>>> VM_BUG_ON_PAGE(PageActive(page), page);
>>> - sc->nr_scanned++;
>>> + nr_pages = 1 << compound_order(page);
>>> +
>>> + /* Account the number of base pages even though THP */
>>> + sc->nr_scanned += nr_pages;
>>> if (unlikely(!page_evictable(page)))
>>> goto activate_locked;
>>> @@ -1250,7 +1254,7 @@ static unsigned long shrink_page_list(struct
>>> list_head *page_list,
>>> case PAGEREF_ACTIVATE:
>>> goto activate_locked;
>>> case PAGEREF_KEEP:
>>> - stat->nr_ref_keep++;
>>> + stat->nr_ref_keep += nr_pages;
>>> goto keep_locked;
>>> case PAGEREF_RECLAIM:
>>> case PAGEREF_RECLAIM_CLEAN:
>>> @@ -1306,6 +1310,15 @@
Re: [PATCH -next] scsi: megaraid_sas: remove set but not used variable 'cur_state'
On Sat, May 25, 2019 at 6:08 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/scsi/megaraid/megaraid_sas_base.c: In function
> megasas_transition_to_ready:
> drivers/scsi/megaraid/megaraid_sas_base.c:3900:6: warning: variable cur_state
> set but not used [-Wunused-but-set-variable]
>
> It's not used any more since commit 7218df69e360 ("[SCSI]
> megaraid_sas: use the firmware boot timeout when waiting for commands")
>
> Signed-off-by: YueHaibing
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 25281a2eb424..39d173ed5b69 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -3897,7 +3897,6 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
> int i;
> u8 max_wait;
> u32 fw_state;
> - u32 cur_state;
> u32 abs_state, curr_abs_state;
>
> abs_state = instance->instancet->read_fw_status_reg(instance);
> @@ -3918,7 +3917,6 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
>abs_state & MFI_STATE_FAULT_SUBCODE,
> __func__);
> if (ocr) {
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_FAULT;
> break;
> } else {
> dev_printk(KERN_DEBUG, &instance->pdev->dev,
> "System Register set:\n");
> @@ -3944,7 +3942,6 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
> &instance->reg_set->inbound_doorbell);
>
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_WAIT_HANDSHAKE;
> break;
>
> case MFI_STATE_BOOT_MESSAGE_PENDING:
> @@ -3960,7 +3957,6 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
> &instance->reg_set->inbound_doorbell);
>
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_BOOT_MESSAGE_PENDING;
> break;
>
> case MFI_STATE_OPERATIONAL:
> @@ -3993,7 +3989,6 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
> &instance->reg_set->inbound_doorbell);
>
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_OPERATIONAL;
> break;
>
> case MFI_STATE_UNDEFINED:
> @@ -4001,32 +3996,26 @@ megasas_transition_to_ready(struct megasas_instance
> *instance, int ocr)
> * This state should not last for more than 2 seconds
> */
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_UNDEFINED;
> break;
>
> case MFI_STATE_BB_INIT:
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_BB_INIT;
> break;
>
> case MFI_STATE_FW_INIT:
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_FW_INIT;
> break;
>
> case MFI_STATE_FW_INIT_2:
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_FW_INIT_2;
> break;
>
> case MFI_STATE_DEVICE_SCAN:
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_DEVICE_SCAN;
> break;
>
> case MFI_STATE_FLUSH_CACHE:
> max_wait = MEGASAS_RESET_WAIT_TIME;
> - cur_state = MFI_STATE_FLUSH_CACHE;
> break;
>
> default:
> --
> 2.17.1
>
>
Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER
On Tue, May 21, 2019 at 08:26:28AM +0200, Michal Hocko wrote: > On Tue 21-05-19 11:55:33, Minchan Kim wrote: > > On Mon, May 20, 2019 at 11:28:01AM +0200, Michal Hocko wrote: > > > [cc linux-api] > > > > > > On Mon 20-05-19 12:52:54, Minchan Kim wrote: > > > > System could have much faster swap device like zRAM. In that case, > > > > swapping > > > > is extremely cheaper than file-IO on the low-end storage. > > > > In this configuration, userspace could handle different strategy for > > > > each > > > > kinds of vma. IOW, they want to reclaim anonymous pages by MADV_COLD > > > > while it keeps file-backed pages in inactive LRU by MADV_COOL because > > > > file IO is more expensive in this case so want to keep them in memory > > > > until memory pressure happens. > > > > > > > > To support such strategy easier, this patch introduces > > > > MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER options in madvise(2) like > > > > that /proc//clear_refs already has supported same filters. > > > > They are filters could be Ored with other existing hints using top two > > > > bits > > > > of (int behavior). > > > > > > madvise operates on top of ranges and it is quite trivial to do the > > > filtering from the userspace so why do we need any additional filtering? > > > > > > > Once either of them is set, the hint could affect only the interested > > > > vma > > > > either anonymous or file-backed. > > > > > > > > With that, user could call a process_madvise syscall simply with a > > > > entire > > > > range(0x0 - 0x) but either of MADV_ANONYMOUS_FILTER and > > > > MADV_FILE_FILTER so there is no need to call the syscall range by range. > > > > > > OK, so here is the reason you want that. The immediate question is why > > > cannot the monitor do the filtering from the userspace. Slightly more > > > work, all right, but less of an API to expose and that itself is a > > > strong argument against. > > > > What I should do if we don't have such filter option is to enumerate all of > > vma via /proc//maps and then parse every ranges and inode from string, > > which would be painful for 2000+ vmas. > > Painful is not an argument to add a new user API. If the existing API > suits the purpose then it should be used. If it is not usable, we can > think of a different way. I measured 1568 vma parsing overhead of /proc//maps in ARM64 modern mobile CPU. It takes 60ms and 185ms on big cores depending on cpu governor. It's never trivial.
Re: [PATCH v2 03/10] ARM: dts: sunxi: prefer A31 instead of A13 for ir
On Mon, May 27, 2019 at 12:25:29AM +0200, Clément Péron wrote: > Since A31, memory mapping of the IR driver has changed. > > Prefer the A31 bindings instead of A13. > > Signed-off-by: Clément Péron > --- > arch/arm/boot/dts/sun6i-a31.dtsi | 2 +- > arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +- > arch/arm/boot/dts/sun9i-a80.dtsi | 2 +- > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- Can you split the H3 in a separate patch? this will go through a separate branch. Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH -next] scsi: megaraid_sas: remove set but not used variables 'host' and 'wait_time'
On Sat, May 25, 2019 at 6:14 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warnings:
>
> drivers/scsi/megaraid/megaraid_sas_base.c: In function megasas_suspend:
> drivers/scsi/megaraid/megaraid_sas_base.c:7269:20: warning: variable host set
> but not used [-Wunused-but-set-variable]
> drivers/scsi/megaraid/megaraid_sas_base.c: In function megasas_aen_polling:
> drivers/scsi/megaraid/megaraid_sas_base.c:8397:15: warning: variable
> wait_time set but not used [-Wunused-but-set-variable]
>
> 'host' is never used since introduction in
> commit 31ea7088974c ("[SCSI] megaraid_sas: add hibernation support")
>
> 'wait_time' is not used since commit
> 11c71cb4ab7c ("megaraid_sas: Do not allow PCI access during OCR")
>
> Signed-off-by: YueHaibing
Acked-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 92e576228d5f..ed0f6ca578e5 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -7239,11 +7239,9 @@ static void megasas_shutdown_controller(struct
> megasas_instance *instance,
> static int
> megasas_suspend(struct pci_dev *pdev, pm_message_t state)
> {
> - struct Scsi_Host *host;
> struct megasas_instance *instance;
>
> instance = pci_get_drvdata(pdev);
> - host = instance->host;
> instance->unload = 1;
>
> dev_info(&pdev->dev, "%s is called\n", __func__);
> @@ -8367,7 +8365,7 @@ megasas_aen_polling(struct work_struct *work)
> struct megasas_instance *instance = ev->instance;
> union megasas_evt_class_locale class_locale;
> int event_type = 0;
> - u32 seq_num, wait_time = MEGASAS_RESET_WAIT_TIME;
> + u32 seq_num;
> int error;
> u8 dcmd_ret = DCMD_SUCCESS;
>
> @@ -8377,10 +8375,6 @@ megasas_aen_polling(struct work_struct *work)
> return;
> }
>
> - /* Adjust event workqueue thread wait time for VF mode */
> - if (instance->requestorId)
> - wait_time = MEGASAS_ROUTINE_WAIT_TIME_VF;
> -
> /* Don't run the event workqueue thread if OCR is running */
> mutex_lock(&instance->reset_mutex);
>
> --
> 2.17.1
>
>
Re: [PATCH] [media] saa7164: fix remove_proc_entry warning
On 5/4/19 9:10 AM, Kefeng Wang wrote:
> if saa7164_proc_create() fails, saa7164_fini() will trigger a warning,
>
> name 'saa7164'
> WARNING: CPU: 1 PID: 6311 at fs/proc/generic.c:672
> remove_proc_entry+0x1e8/0x3a0
> ? remove_proc_entry+0x1e8/0x3a0
> ? try_stop_module+0x7b/0x240
> ? proc_readdir+0x70/0x70
> ? rcu_read_lock_sched_held+0xd7/0x100
> saa7164_fini+0x13/0x1f [saa7164]
> __x64_sys_delete_module+0x30c/0x480
> ? __ia32_sys_delete_module+0x480/0x480
> ? __x64_sys_clock_gettime+0x11e/0x1c0
> ? __x64_sys_timer_create+0x1a0/0x1a0
> ? trace_hardirqs_off_caller+0x40/0x180
> ? do_syscall_64+0x18/0x450
> do_syscall_64+0x9f/0x450
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Fix it by checking the return of proc_create_single() before
> calling remove_proc_entry().
>
> Signed-off-by: Kefeng Wang
> ---
> drivers/media/pci/saa7164/saa7164-core.c | 31 +++-
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/pci/saa7164/saa7164-core.c
> b/drivers/media/pci/saa7164/saa7164-core.c
> index 05f25c9bb308..51dff0d84399 100644
> --- a/drivers/media/pci/saa7164/saa7164-core.c
> +++ b/drivers/media/pci/saa7164/saa7164-core.c
> @@ -1122,16 +1122,23 @@ static int saa7164_proc_show(struct seq_file *m, void
> *v)
> return 0;
> }
>
> +static struct proc_dir_entry *saa7164_pe;
Add empty line to separate this global from the function.
> static int saa7164_proc_create(void)
> {
> - struct proc_dir_entry *pe;
> -
> - pe = proc_create_single("saa7164", S_IRUGO, NULL, saa7164_proc_show);
> - if (!pe)
> + saa7164_pe = proc_create_single("saa7164", S_IRUGO, NULL,
> saa7164_proc_show);
> + if (!saa7164_pe)
> return -ENOMEM;
>
> return 0;
> }
Add empty line to separate the two functions.
> +static void saa7164_proc_destory(void)
destory -> destroy
> +{
> + if (saa7164_pe)
> + remove_proc_entry("saa7164", NULL);
> +}
> +#else
> +static int saa7164_proc_create(void) { return 0; }
> +static void saa7164_proc_destory(void) {}
> #endif
>
> static int saa7164_thread_function(void *data)
> @@ -1503,19 +1510,21 @@ static struct pci_driver saa7164_pci_driver = {
>
> static int __init saa7164_init(void)
> {
> - printk(KERN_INFO "saa7164 driver loaded\n");
> + int ret = pci_register_driver(&saa7164_pci_driver);
> +
> + if (ret)
> + return ret;
>
> -#ifdef CONFIG_PROC_FS
> saa7164_proc_create();
> -#endif
> - return pci_register_driver(&saa7164_pci_driver);
> +
> + printk(KERN_INFO "saa7164 driver loaded\n");
> +
> + return 0;
> }
>
> static void __exit saa7164_fini(void)
> {
> -#ifdef CONFIG_PROC_FS
> - remove_proc_entry("saa7164", NULL);
> -#endif
> + saa7164_proc_destory();
> pci_unregister_driver(&saa7164_pci_driver);
> }
>
>
Regards,
Hans
Re: [PATCH 0/2] net: macb: Add support for SiFive FU540-C000
On Mai 24 2019, Yash Shah wrote: > Hi Andreas, > > On Thu, May 23, 2019 at 6:19 PM Andreas Schwab wrote: >> >> On Mai 23 2019, Yash Shah wrote: >> >> > On FU540, the management IP block is tightly coupled with the Cadence >> > MACB IP block. It manages many of the boundary signals from the MACB IP >> > This patchset controls the tx_clk input signal to the MACB IP. It >> > switches between the local TX clock (125MHz) and PHY TX clocks. This >> > is necessary to toggle between 1Gb and 100/10Mb speeds. >> >> Doesn't work for me: >> >> [ 365.842801] macb: probe of 1009.ethernet failed with error -17 >> > > Make sure you have applied all the patches needed for testing found at > dev/yashs/ethernet branch of: Nope, try reloading the module. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [RFC 0/7] introduce memory hinting API for external process
On Thu, May 23, 2019 at 10:07:17PM +0900, Minchan Kim wrote:
> On Wed, May 22, 2019 at 09:01:33AM -0700, Daniel Colascione wrote:
> > On Wed, May 22, 2019 at 9:01 AM Christian Brauner
> > wrote:
> > >
> > > On Wed, May 22, 2019 at 08:57:47AM -0700, Daniel Colascione wrote:
> > > > On Wed, May 22, 2019 at 8:48 AM Christian Brauner
> > > > wrote:
> > > > >
> > > > > On Wed, May 22, 2019 at 08:17:23AM -0700, Daniel Colascione wrote:
> > > > > > On Wed, May 22, 2019 at 7:52 AM Christian Brauner
> > > > > > wrote:
> > > > > > > I'm not going to go into yet another long argument. I prefer
> > > > > > > pidfd_*.
> > > > > >
> > > > > > Ok. We're each allowed our opinion.
> > > > > >
> > > > > > > It's tied to the api, transparent for userspace, and
> > > > > > > disambiguates it
> > > > > > > from process_vm_{read,write}v that both take a pid_t.
> > > > > >
> > > > > > Speaking of process_vm_readv and process_vm_writev: both have a
> > > > > > currently-unused flags argument. Both should grow a flag that tells
> > > > > > them to interpret the pid argument as a pidfd. Or do you support
> > > > > > adding pidfd_vm_readv and pidfd_vm_writev system calls? If not, why
> > > > > > should process_madvise be called pidfd_madvise while
> > > > > > process_vm_readv
> > > > > > isn't called pidfd_vm_readv?
> > > > >
> > > > > Actually, you should then do the same with process_madvise() and give
> > > > > it
> > > > > a flag for that too if that's not too crazy.
> > > >
> > > > I don't know what you mean. My gut feeling is that for the sake of
> > > > consistency, process_madvise, process_vm_readv, and process_vm_writev
> > > > should all accept a first argument interpreted as either a numeric PID
> > > > or a pidfd depending on a flag --- ideally the same flag. Is that what
> > > > you have in mind?
> > >
> > > Yes. For the sake of consistency they should probably all default to
> > > interpret as pid and if say PROCESS_{VM_}PIDFD is passed as flag
> > > interpret as pidfd.
> >
> > Sounds good to me!
>
> Then, I want to change from pidfd to pid at next revsion and stick to
> process_madvise as naming. Later, you guys could define PROCESS_PIDFD
> flag and change all at once every process_xxx syscall friends.
>
> If you are faster so that I see PROCESS_PIDFD earlier, I am happy to
> use it.
Hi Folks,
I don't want to consume a new API argument too early so want to say
I will use process_madvise with pidfs argument because I agree with
Daniel that we don't need to export implmentation on the syscall name.
I hope every upcoming new syscall with process has by default pidfs
so people are familiar with pidfd slowly so finallly they forgot pid
in the long run so naturally replace pid with pidfs.
Re: [v6 PATCH 2/2] mm: vmscan: correct some vmscan counters for THP swapout
On 5/27/19 3:55 PM, Huang, Ying wrote:
Yang Shi writes:
On 5/27/19 3:06 PM, Huang, Ying wrote:
Yang Shi writes:
Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after
swapped out"), THP can be swapped out in a whole. But, nr_reclaimed
and some other vm counters still get inc'ed by one even though a whole
THP (512 pages) gets swapped out.
This doesn't make too much sense to memory reclaim. For example, direct
reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP
could fulfill it. But, if nr_reclaimed is not increased correctly,
direct reclaim may just waste time to reclaim more pages,
SWAP_CLUSTER_MAX * 512 pages in worst case.
And, it may cause pgsteal_{kswapd|direct} is greater than
pgscan_{kswapd|direct}, like the below:
pgsteal_kswapd 122933
pgsteal_direct 26600225
pgscan_kswapd 174153
pgscan_direct 14678312
nr_reclaimed and nr_scanned must be fixed in parallel otherwise it would
break some page reclaim logic, e.g.
vmpressure: this looks at the scanned/reclaimed ratio so it won't
change semantics as long as scanned & reclaimed are fixed in parallel.
compaction/reclaim: compaction wants a certain number of physical pages
freed up before going back to compacting.
kswapd priority raising: kswapd raises priority if we scan fewer pages
than the reclaim target (which itself is obviously expressed in order-0
pages). As a result, kswapd can falsely raise its aggressiveness even
when it's making great progress.
Other than nr_scanned and nr_reclaimed, some other counters, e.g.
pgactivate, nr_skipped, nr_ref_keep and nr_unmap_fail need to be fixed
too since they are user visible via cgroup, /proc/vmstat or trace
points, otherwise they would be underreported.
When isolating pages from LRUs, nr_taken has been accounted in base
page, but nr_scanned and nr_skipped are still accounted in THP. It
doesn't make too much sense too since this may cause trace point
underreport the numbers as well.
So accounting those counters in base page instead of accounting THP as
one page.
nr_dirty, nr_unqueued_dirty, nr_congested and nr_writeback are used by
file cache, so they are not impacted by THP swap.
This change may result in lower steal/scan ratio in some cases since
THP may get split during page reclaim, then a part of tail pages get
reclaimed instead of the whole 512 pages, but nr_scanned is accounted
by 512, particularly for direct reclaim. But, this should be not a
significant issue.
Cc: "Huang, Ying"
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Mel Gorman
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: Hillf Danton
Signed-off-by: Yang Shi
---
v6: Fixed the other double account issue introduced by v5 per Huang Ying
v5: Fixed sc->nr_scanned double accounting per Huang Ying
Added some comments to address the concern about premature OOM per Hillf
Danton
v4: Fixed the comments from Johannes and Huang Ying
v3: Removed Shakeel's Reviewed-by since the patch has been changed significantly
Switched back to use compound_order per Matthew
Fixed more counters per Johannes
v2: Added Shakeel's Reviewed-by
Use hpage_nr_pages instead of compound_order per Huang Ying and William
Kucharski
mm/vmscan.c | 47 +++
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b65bc50..378edff 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1118,6 +1118,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
int may_enter_fs;
enum page_references references = PAGEREF_RECLAIM_CLEAN;
bool dirty, writeback;
+ unsigned int nr_pages;
cond_resched();
@@ -1129,7 +1130,10 @@ static unsigned long
shrink_page_list(struct list_head *page_list,
VM_BUG_ON_PAGE(PageActive(page), page);
-sc->nr_scanned++;
+ nr_pages = 1 << compound_order(page);
+
+ /* Account the number of base pages even though THP */
+ sc->nr_scanned += nr_pages;
if (unlikely(!page_evictable(page)))
goto activate_locked;
@@ -1250,7 +1254,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
case PAGEREF_ACTIVATE:
goto activate_locked;
case PAGEREF_KEEP:
- stat->nr_ref_keep++;
+ stat->nr_ref_keep += nr_pages;
goto keep_locked;
case PAGEREF_RECLAIM:
case PAGEREF_RECLAIM_CLEAN:
@@ -1306,6 +1310,15 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
}
/*
+* THP may get split above, need minus tail pages and update
+* nr_pages to avoid accounting tail pages twice.
+*/
+ if ((nr_pages > 1) && !PageTransHuge(page)) {
+
Re: [PATCH V4 4/4] arm64/mm: Enable memory hot remove
On 05/21/2019 03:50 PM, David Hildenbrand wrote:
> On 20.05.19 07:18, Anshuman Khandual wrote:
>> The arch code for hot-remove must tear down portions of the linear map and
>> vmemmap corresponding to memory being removed. In both cases the page
>> tables mapping these regions must be freed, and when sparse vmemmap is in
>> use the memory backing the vmemmap must also be freed.
>>
>> This patch adds a new remove_pagetable() helper which can be used to tear
>> down either region, and calls it from vmemmap_free() and
>> ___remove_pgd_mapping(). The sparse_vmap argument determines whether the
>> backing memory will be freed.
>>
>> While freeing intermediate level page table pages bail out if any of it's
>> entries are still valid. This can happen for partially filled kernel page
>> table either from a previously attempted failed memory hot add or while
>> removing an address range which does not span the entire page table page
>> range.
>>
>> The vmemmap region may share levels of table with the vmalloc region. Take
>> the kernel ptl so that we can safely free potentially-shared tables.
>>
>> While here update arch_add_memory() to handle __add_pages() failures by
>> just unmapping recently added kernel linear mapping. Now enable memory hot
>> remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
>>
>> This implementation is overall inspired from kernel page table tear down
>> procedure on X86 architecture.
>>
>> Signed-off-by: Anshuman Khandual
>> ---
>> arch/arm64/Kconfig | 3 +
>> arch/arm64/mm/mmu.c | 212
>> +++-
>> 2 files changed, 213 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 4780eb7..ce24427 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -267,6 +267,9 @@ config HAVE_GENERIC_GUP
>> config ARCH_ENABLE_MEMORY_HOTPLUG
>> def_bool y
>>
>> +config ARCH_ENABLE_MEMORY_HOTREMOVE
>> +def_bool y
>> +
>> config SMP
>> def_bool y
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a1bfc44..0cf0d41 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -733,6 +733,187 @@ int kern_addr_valid(unsigned long addr)
>>
>> return pfn_valid(pte_pfn(pte));
>> }
>> +
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +static void free_hotplug_page_range(struct page *page, ssize_t size)
>> +{
>> +WARN_ON(PageReserved(page));
>> +free_pages((unsigned long)page_address(page), get_order(size));
>> +}
>> +
>> +static void free_hotplug_pgtable_page(struct page *page)
>> +{
>> +free_hotplug_page_range(page, PAGE_SIZE);
>> +}
>> +
>> +static void free_pte_table(pte_t *ptep, pmd_t *pmdp, unsigned long addr)
>> +{
>> +struct page *page;
>> +int i;
>> +
>> +for (i = 0; i < PTRS_PER_PTE; i++) {
>> +if (!pte_none(ptep[i]))
>> +return;
>> +}
>> +
>> +page = pmd_page(READ_ONCE(*pmdp));
>> +pmd_clear(pmdp);
>> +__flush_tlb_kernel_pgtable(addr);
>> +free_hotplug_pgtable_page(page);
>> +}
>> +
>> +static void free_pmd_table(pmd_t *pmdp, pud_t *pudp, unsigned long addr)
>> +{
>> +struct page *page;
>> +int i;
>> +
>> +if (CONFIG_PGTABLE_LEVELS <= 2)
>> +return;
>> +
>> +for (i = 0; i < PTRS_PER_PMD; i++) {
>> +if (!pmd_none(pmdp[i]))
>> +return;
>> +}
>> +
>> +page = pud_page(READ_ONCE(*pudp));
>> +pud_clear(pudp);
>> +__flush_tlb_kernel_pgtable(addr);
>> +free_hotplug_pgtable_page(page);
>> +}
>> +
>> +static void free_pud_table(pud_t *pudp, pgd_t *pgdp, unsigned long addr)
>> +{
>> +struct page *page;
>> +int i;
>> +
>> +if (CONFIG_PGTABLE_LEVELS <= 3)
>> +return;
>> +
>> +for (i = 0; i < PTRS_PER_PUD; i++) {
>> +if (!pud_none(pudp[i]))
>> +return;
>> +}
>> +
>> +page = pgd_page(READ_ONCE(*pgdp));
>> +pgd_clear(pgdp);
>> +__flush_tlb_kernel_pgtable(addr);
>> +free_hotplug_pgtable_page(page);
>> +}
>> +
>> +static void
>> +remove_pte_table(pmd_t *pmdp, unsigned long addr,
>> +unsigned long end, bool sparse_vmap)
>> +{
>> +struct page *page;
>> +pte_t *ptep, pte;
>> +unsigned long start = addr;
>> +
>> +for (; addr < end; addr += PAGE_SIZE) {
>> +ptep = pte_offset_kernel(pmdp, addr);
>> +pte = READ_ONCE(*ptep);
>> +
>> +if (pte_none(pte))
>> +continue;
>> +
>> +WARN_ON(!pte_present(pte));
>> +if (sparse_vmap) {
>> +page = pte_page(pte);
>> +free_hotplug_page_range(page, PAGE_SIZE);
>> +}
>> +pte_clear(&init_mm, addr, ptep);
>> +}
>> +flush_tlb_kernel_range(start, end);
>> +}
>> +
>> +static void
>> +remove_pmd_table(pud_t *pudp, unsigned long addr,
>> +unsigned long end, bool sparse_vmap)
>> +{
>> +unsigned l
Великденски бонуси
Здравейте, съвременното доплащане на храна под формата на ваучери за храна, които могат да бъдат използвани в най-голямата мрежа от заведения за хранене в страната, е инструмент, който ефективно повишава ефективността на персонала. Изборът на нашите ваучери за храна като форма на социална придобивка са за работодателя не само придобиване на продуктивен и мотивиран екип, но и носят финансови облаги - стойността на изразходваните средства не се облагат с данък. Радваме се да Ви представим още повече предимства, които бихте получили с ползването на нашите ваучери, като например ползите за служителите Ви и ще Ви разкажа за възможностите при тяхното използване - моля, обадете се. Радослав Добрев Head of HR Benefit Team www.eatforyou.eu
[PATCH v2] mm: mlockall error for flag MCL_ONFAULT
If mlockall() is called with only MCL_ONFAULT as flag,
it removes any previously applied lockings and does
nothing else.
This behavior is counter-intuitive and doesn't match the
Linux man page.
For mlockall():
EINVAL Unknown flags were specified or MCL_ONFAULT was specified with‐
out either MCL_FUTURE or MCL_CURRENT.
Consequently, return the error EINVAL, if only MCL_ONFAULT
is passed. That way, applications will at least detect that
they are calling mlockall() incorrectly.
Fixes: b0f205c2a308 ("mm: mlock: add mlock flags to enable VM_LOCKONFAULT
usage")
Signed-off-by: Stefan Potyra
Reviewed-by: Daniel Jordan
Acked-by: Michal Hocko
---
mm/mlock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index e492a155c51a..03f39cbdd4c4 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -797,7 +797,8 @@ SYSCALL_DEFINE1(mlockall, int, flags)
unsigned long lock_limit;
int ret;
- if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT)))
+ if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT)) ||
+ flags == MCL_ONFAULT)
return -EINVAL;
if (!can_do_mlock())
--
2.20.1
Re: [PATCH v2 03/10] ARM: dts: sunxi: prefer A31 instead of A13 for ir
Hi Maxime, On Mon, 27 May 2019 at 09:47, Maxime Ripard wrote: > > On Mon, May 27, 2019 at 12:25:29AM +0200, Clément Péron wrote: > > Since A31, memory mapping of the IR driver has changed. > > > > Prefer the A31 bindings instead of A13. > > > > Signed-off-by: Clément Péron > > --- > > arch/arm/boot/dts/sun6i-a31.dtsi | 2 +- > > arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +- > > arch/arm/boot/dts/sun9i-a80.dtsi | 2 +- > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- > > Can you split the H3 in a separate patch? this will go through a > separate branch. Ok I will, Thanks, Clément > > Thanks! > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
[PATCH net-next 0/2] Add hw offload of TC flower on MSCC Ocelot
This patch series enables hardware offload for flower filter used in
traffic controller on MSCC Ocelot board.
The patch series is based on:
commit 6ab1f192dcb4 ("net: mscc: ocelot: Implement port policers via tc
command")
CC: Alexandre Belloni
CC: Microchip Linux Driver Support
CC: Rob Herring
CC: Mark Rutland
CC: Ralf Baechle
CC: Paul Burton
CC: James Hogan
CC: "David S. Miller"
CC: linux-m...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: net...@vger.kernel.org
Horatiu Vultur (2):
net: mscc: ocelot: Add support for tcam
net: mscc: ocelot: Hardware ofload for tc flower filter
arch/mips/boot/dts/mscc/ocelot.dtsi | 5 +-
drivers/net/ethernet/mscc/Makefile| 2 +-
drivers/net/ethernet/mscc/ocelot.c| 13 +
drivers/net/ethernet/mscc/ocelot.h| 8 +
drivers/net/ethernet/mscc/ocelot_ace.c| 779 ++
drivers/net/ethernet/mscc/ocelot_ace.h| 232 +
drivers/net/ethernet/mscc/ocelot_board.c | 1 +
drivers/net/ethernet/mscc/ocelot_flower.c | 345 +
drivers/net/ethernet/mscc/ocelot_regs.c | 11 +
drivers/net/ethernet/mscc/ocelot_s2.h | 64 +++
drivers/net/ethernet/mscc/ocelot_tc.c | 16 +-
drivers/net/ethernet/mscc/ocelot_vcap.h | 403
12 files changed, 1870 insertions(+), 9 deletions(-)
create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.c
create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.h
create mode 100644 drivers/net/ethernet/mscc/ocelot_flower.c
create mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
create mode 100644 drivers/net/ethernet/mscc/ocelot_vcap.h
--
2.7.4
[PATCH net-next 1/2] net: mscc: ocelot: Add support for tcam
Add ACL support using the TCAM. Using ACL it is possible to create rules
in hardware to filter/redirect frames.
Signed-off-by: Horatiu Vultur
---
arch/mips/boot/dts/mscc/ocelot.dtsi | 5 +-
drivers/net/ethernet/mscc/Makefile | 2 +-
drivers/net/ethernet/mscc/ocelot.c | 13 +
drivers/net/ethernet/mscc/ocelot.h | 8 +
drivers/net/ethernet/mscc/ocelot_ace.c | 779 +++
drivers/net/ethernet/mscc/ocelot_ace.h | 227 +
drivers/net/ethernet/mscc/ocelot_board.c | 1 +
drivers/net/ethernet/mscc/ocelot_regs.c | 11 +
drivers/net/ethernet/mscc/ocelot_s2.h| 64 +++
drivers/net/ethernet/mscc/ocelot_vcap.h | 403
10 files changed, 1510 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.c
create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.h
create mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
create mode 100644 drivers/net/ethernet/mscc/ocelot_vcap.h
diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi
b/arch/mips/boot/dts/mscc/ocelot.dtsi
index 90c60d4..33ae74a 100644
--- a/arch/mips/boot/dts/mscc/ocelot.dtsi
+++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
@@ -132,11 +132,12 @@
<0x127 0x100>,
<0x128 0x100>,
<0x180 0x8>,
- <0x188 0x1>;
+ <0x188 0x1>,
+ <0x106 0x1>;
reg-names = "sys", "rew", "qs", "port0", "port1",
"port2", "port3", "port4", "port5", "port6",
"port7", "port8", "port9", "port10", "qsys",
- "ana";
+ "ana", "s2";
interrupts = <21 22>;
interrupt-names = "xtr", "inj";
diff --git a/drivers/net/ethernet/mscc/Makefile
b/drivers/net/ethernet/mscc/Makefile
index 5e694dc..bf4a710 100644
--- a/drivers/net/ethernet/mscc/Makefile
+++ b/drivers/net/ethernet/mscc/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0 OR MIT)
obj-$(CONFIG_MSCC_OCELOT_SWITCH) += mscc_ocelot_common.o
mscc_ocelot_common-y := ocelot.o ocelot_io.o
-mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o
+mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o ocelot_ace.o
obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += ocelot_board.o
diff --git a/drivers/net/ethernet/mscc/ocelot.c
b/drivers/net/ethernet/mscc/ocelot.c
index 3ec7864..4b8bd3e 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -22,6 +22,7 @@
#include
#include "ocelot.h"
+#include "ocelot_ace.h"
#define TABLE_UPDATE_SLEEP_US 10
#define TABLE_UPDATE_TIMEOUT_US 10
@@ -130,6 +131,13 @@ static void ocelot_mact_init(struct ocelot *ocelot)
ocelot_write(ocelot, MACACCESS_CMD_INIT, ANA_TABLES_MACACCESS);
}
+static void ocelot_vcap_enable(struct ocelot *ocelot, struct ocelot_port *port)
+{
+ ocelot_write_gix(ocelot, ANA_PORT_VCAP_S2_CFG_S2_ENA |
+ANA_PORT_VCAP_S2_CFG_S2_IP6_CFG(0xa),
+ANA_PORT_VCAP_S2_CFG, port->chip_port);
+}
+
static inline u32 ocelot_vlant_read_vlanaccess(struct ocelot *ocelot)
{
return ocelot_read(ocelot, ANA_TABLES_VLANACCESS);
@@ -1682,6 +1690,9 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
/* Basic L2 initialization */
ocelot_vlan_port_apply(ocelot, ocelot_port);
+ /* Enable vcap lookups */
+ ocelot_vcap_enable(ocelot, ocelot_port);
+
return 0;
err_register_netdev:
@@ -1716,6 +1727,7 @@ int ocelot_init(struct ocelot *ocelot)
ocelot_mact_init(ocelot);
ocelot_vlan_init(ocelot);
+ ocelot_ace_init(ocelot);
for (port = 0; port < ocelot->num_phys_ports; port++) {
/* Clear all counters (5 groups) */
@@ -1828,6 +1840,7 @@ void ocelot_deinit(struct ocelot *ocelot)
{
destroy_workqueue(ocelot->stats_queue);
mutex_destroy(&ocelot->stats_lock);
+ ocelot_ace_deinit();
}
EXPORT_SYMBOL(ocelot_deinit);
diff --git a/drivers/net/ethernet/mscc/ocelot.h
b/drivers/net/ethernet/mscc/ocelot.h
index 9514979..3430174 100644
--- a/drivers/net/ethernet/mscc/ocelot.h
+++ b/drivers/net/ethernet/mscc/ocelot.h
@@ -69,6 +69,7 @@ enum ocelot_target {
QSYS,
REW,
SYS,
+ S2,
HSIO,
TARGET_MAX,
};
@@ -335,6 +336,13 @@ enum ocelot_reg {
SYS_CM_DATA_RD,
SYS_CM_OP,
SYS_CM_DATA,
+ S2_CORE_UPDATE_CTRL = S2 << TARGET_OFFSET,
+ S2_CORE_MV_CFG,
+ S2_CACHE_ENTRY_DAT,
+ S2_CACHE_MASK_DAT,
+ S2_CACHE_ACTION_DAT,
+ S2_CACHE_CNT_DAT,
+ S2_CACHE_TG_DAT,
};
enum ocelot_regfield {
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ac
[PATCH net-next 2/2] net: mscc: ocelot: Hardware ofload for tc flower filter
Hardware offload of port filtering are now supported via tc command using
flower filter. ACL rules are used to enable the hardware offload.
The following keys are supported:
vlan_id
vlan_prio
dst_mac/src_mac for non IP frames
dst_ip/src_ip
dst_port/src_port
The following actions are supported:
trap
drop
These filters are supported only on the ingress schedulare.
Add:
tc qdisc add dev eth3 ingress
tc filter ad dev eth3 parent : ip_proto ip flower \
ip_proto tcp dst_port 80 action drop
Signed-off-by: Horatiu Vultur
---
drivers/net/ethernet/mscc/Makefile| 2 +-
drivers/net/ethernet/mscc/ocelot_ace.h| 5 +
drivers/net/ethernet/mscc/ocelot_flower.c | 345 ++
drivers/net/ethernet/mscc/ocelot_tc.c | 16 +-
4 files changed, 361 insertions(+), 7 deletions(-)
create mode 100644 drivers/net/ethernet/mscc/ocelot_flower.c
diff --git a/drivers/net/ethernet/mscc/Makefile
b/drivers/net/ethernet/mscc/Makefile
index bf4a710..9a36c26 100644
--- a/drivers/net/ethernet/mscc/Makefile
+++ b/drivers/net/ethernet/mscc/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0 OR MIT)
obj-$(CONFIG_MSCC_OCELOT_SWITCH) += mscc_ocelot_common.o
mscc_ocelot_common-y := ocelot.o ocelot_io.o
-mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o ocelot_ace.o
+mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o ocelot_ace.o
ocelot_flower.o
obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += ocelot_board.o
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.h
b/drivers/net/ethernet/mscc/ocelot_ace.h
index c84e608..d621683 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.h
+++ b/drivers/net/ethernet/mscc/ocelot_ace.h
@@ -224,4 +224,9 @@ int ocelot_ace_rule_stats_update(struct ocelot_ace_rule
*rule);
int ocelot_ace_init(struct ocelot *ocelot);
void ocelot_ace_deinit(void);
+int ocelot_setup_tc_block_flower_bind(struct ocelot_port *port,
+ struct tc_block_offload *f);
+void ocelot_setup_tc_block_flower_unbind(struct ocelot_port *port,
+struct tc_block_offload *f);
+
#endif /* _MSCC_OCELOT_ACE_H_ */
diff --git a/drivers/net/ethernet/mscc/ocelot_flower.c
b/drivers/net/ethernet/mscc/ocelot_flower.c
new file mode 100644
index 000..5ec3031
--- /dev/null
+++ b/drivers/net/ethernet/mscc/ocelot_flower.c
@@ -0,0 +1,345 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Microsemi Ocelot Switch driver
+ * Copyright (c) 2019 Microsemi Corporation
+ */
+
+#include
+#include
+
+#include "ocelot_ace.h"
+
+struct ocelot_port_block {
+ struct ocelot_acl_block *block;
+ struct ocelot_port *port;
+};
+
+static u16 get_prio(u32 prio)
+{
+ /* prio starts from 0x1000 while the ids starts from 0 */
+ return prio >> 16;
+}
+
+static int ocelot_flower_parse_action(struct tc_cls_flower_offload *f,
+ struct ocelot_ace_rule *rule)
+{
+ const struct flow_action_entry *a;
+ int i;
+
+ if (f->rule->action.num_entries != 1)
+ return -EOPNOTSUPP;
+
+ flow_action_for_each(i, a, &f->rule->action) {
+ switch (a->id) {
+ case FLOW_ACTION_DROP:
+ rule->action = OCELOT_ACL_ACTION_DROP;
+ break;
+ case FLOW_ACTION_TRAP:
+ rule->action = OCELOT_ACL_ACTION_TRAP;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+ }
+
+ return 0;
+}
+
+static int ocelot_flower_parse(struct tc_cls_flower_offload *f,
+ struct ocelot_ace_rule *ocelot_rule)
+{
+ struct flow_rule *rule = tc_cls_flower_offload_flow_rule(f);
+ struct flow_dissector *dissector = rule->match.dissector;
+
+ if (dissector->used_keys &
+ ~(BIT(FLOW_DISSECTOR_KEY_CONTROL) |
+ BIT(FLOW_DISSECTOR_KEY_BASIC) |
+ BIT(FLOW_DISSECTOR_KEY_PORTS) |
+ BIT(FLOW_DISSECTOR_KEY_VLAN) |
+ BIT(FLOW_DISSECTOR_KEY_IPV4_ADDRS) |
+ BIT(FLOW_DISSECTOR_KEY_IPV6_ADDRS) |
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS))) {
+ return -EOPNOTSUPP;
+ }
+
+ if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_CONTROL)) {
+ struct flow_match_control match;
+
+ flow_rule_match_control(rule, &match);
+ }
+
+ if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
+ struct flow_match_eth_addrs match;
+ u16 proto = ntohs(f->common.protocol);
+
+ /* The hw support mac matches only for MAC_ETYPE key,
+* therefore if other matches(port, tcp flags, etc) are added
+* then just bail out
+*/
+ if ((dissector->used_keys &
+ (BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) |
+BIT(FLOW_DISSECTOR_KEY_BASIC)
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Mon, May 27, 2019 at 4:39 PM Hans Verkuil wrote: > > On 5/27/19 5:51 AM, Tomasz Figa wrote: > > On Tue, May 21, 2019 at 9:27 PM Hans Verkuil wrote: > >> > >> On 5/21/19 11:09 AM, Tomasz Figa wrote: > >>> Hi Stan, > >>> > >>> On Mon, May 20, 2019 at 11:47 PM Stanimir Varbanov > >>> wrote: > > Hi Tomasz, > > On 4/24/19 3:39 PM, Tomasz Figa wrote: > > On Wed, Apr 24, 2019 at 9:15 PM Stanimir Varbanov > > wrote: > >> > >> Hi Hans, > >> > >> On 2/15/19 3:44 PM, Hans Verkuil wrote: > >>> Hi Stanimir, > >>> > >>> I never paid much attention to this patch series since others were > >>> busy > >>> discussing it and I had a lot of other things on my plate, but then I > >>> heard > >>> that this patch made G_FMT blocking. > >> > >> OK, another option could be to block REQBUF(CAPTURE) until event from > >> hw > >> is received that the stream is parsed and the resolution is correctly > >> set by application. Just to note that I'd think to this like a temporal > >> solution until gstreamer implements v4l events. > >> > >> Is that looks good to you? > > > > Hmm, I thought we concluded that gstreamer sets the width and height > > in OUTPUT queue before querying the CAPTURE queue and so making the > > driver calculate the CAPTURE format based on what's set on OUTPUT > > would work fine. Did I miss something? > > Nobody is miss something. > > First some background about how Venus implements stateful codec API. > > The Venus firmware can generate two events "sufficient" and > "insufficient" buffer requirements (this includes decoder output buffer > size and internal/scratch buffer sizes). Presently I always set minimum > possible decoder resolution no matter what the user said, and by that > way I'm sure that "insufficient" event will always be triggered by the > firmware (the other reason to take this path is because this is the > least-common-divider for all supported Venus hw/fw versions thus common > code in the driver). The reconfiguration (during codec Initialization > sequence) is made from STREAMON(CAPTURE) context. Now, to make that > re-configuration happen I need to wait for "insufficient" event from > firmware in order to know the real coded resolution. > > In the case of gstreamer where v4l2_events support is missing I have to > block (wait for firmware event) REQBUF(CAPTURE) (vb2::queue_setup) or > STREAMON(CAPTURE) (vb2::start_streaming). > > I tried to set the coded resolution to the firmware as-is it set by > gstreamer but then I cannot receive the "sufficient" event for VP8 and > VP9 codecs. So I return back to the solution with minimum resolution > above. > > I'm open for suggestions. > >>> > >>> I think you could still keep setting the minimum size and wait for the > >>> "insufficient" event. At the same time, you could speculatively > >>> advertise the expected "sufficient" size on the CAPTURE queue before > >>> the hardware signals those. Even if you mispredict them, you'll get > >>> the event, update the CAPTURE resolution and send the source change > >>> event to the application, which would then give you the correct > >>> buffers. Would that work for you? > >> > >> As I understand it this still would require event support, which gstreamer > >> doesn't have. > > > > I don't think it matches what I remember from the earlier discussion. > > As long as Gstreamer sets the visible resolution (from the container > > AFAIR) on OUTPUT, the driver would adjust it to something that is > > expected to be the right framebuffer resolution and so Gstreamer would > > be able to continue. Of course if the expected value doesn't match, it > > wouldn't work, but it's the same as currently for Coda AFAICT. > > > >> > >> I think it is OK to have REQBUFS sleep in this case. However, I would only > > > > Why REQBUFS? While that could possibly allow us to allocate the right > > buffers, Gstreamer wouldn't be able to know the right format, because > > it would query it before REQBUFS, wouldn't it? > > Oops, you are right. It's got to be in G_FMT(CAPTURE), but *only* if > nobody subscribed to the SOURCE_CHANGE event. > > > > > For this reason, s5p-mfc makes G_FMT(CAPTURE) blocking and if we > > decide to forcefully keep the compatibility, even with in drivers, we > > should probably do the same here. > > > >> enable this behavior if the application didn't subscribe to the > >> SOURCE_CHANGE > >> event. That's easy enough to check in the driver. And that means that if > >> the > >> application is well written, then the driver will behave in a completely > >> standard way that the compliance test can check. > > > > I guess one could have some helpers for this. They would listen to the > > source change events internally and block / wake-up appropriate ioctls >
Re: [PATCH v2 02/10] media: rc: sunxi: Add A31 compatible
Hi Maxime,
On Mon, 27 May 2019 at 09:47, Maxime Ripard wrote:
>
> Hi,
>
> On Mon, May 27, 2019 at 12:25:28AM +0200, Clément Péron wrote:
> > Allwiner A31 has a different memory mapping so add the compatible
> > we will need it later.
> >
> > Signed-off-by: Clément Péron
> > ---
> > drivers/media/rc/sunxi-cir.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> > index 307e44714ea0..29ac33b68596 100644
> > --- a/drivers/media/rc/sunxi-cir.c
> > +++ b/drivers/media/rc/sunxi-cir.c
> > @@ -319,6 +319,7 @@ static int sunxi_ir_remove(struct platform_device *pdev)
> > static const struct of_device_id sunxi_ir_match[] = {
> > { .compatible = "allwinner,sun4i-a10-ir", },
> > { .compatible = "allwinner,sun5i-a13-ir", },
> > + { .compatible = "allwinner,sun6i-a31-ir", },
>
> We should also move from reset_get_optional to the non optional
> variant for the A31, and ignore it otherwise.
Should this be done in this series ?
Thanks,
Clément
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[RESEND PATCH v5 1/5] ARM: dts: da850: add cpu node and operating points to DT
From: David Lechner
This adds a cpu node and operating points to the common da850.dtsi file.
All operating points above 300MHz are disabled by default.
Regulators need to be hooked up on a per-board basis.
Signed-off-by: David Lechner
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 50
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 559659b399d0..0c9a8e78f748 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -20,6 +20,56 @@
reg = <0xc000 0x0>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu: cpu@0 {
+ compatible = "arm,arm926ej-s";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&psc0 14>;
+ operating-points-v2 = <&opp_table>;
+ };
+ };
+
+ opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp_100: opp100-1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <100 95 105>;
+ };
+
+ opp_200: opp110-2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <110 105 116>;
+ };
+
+ opp_300: opp120-3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <120 114 132>;
+ };
+
+ /*
+* Original silicon was 300MHz max, so higher frequencies
+* need to be enabled on a per-board basis if the chip is
+* capable.
+*/
+
+ opp_375: opp120-37500 {
+ status = "disabled";
+ opp-hz = /bits/ 64 <37500>;
+ opp-microvolt = <120 114 132>;
+ };
+
+ opp_456: opp130-45600 {
+ status = "disabled";
+ opp-hz = /bits/ 64 <45600>;
+ opp-microvolt = <130 125 135>;
+ };
+ };
+
arm {
#address-cells = <1>;
#size-cells = <1>;
--
2.21.0
[RESEND PATCH v5 4/5] ARM: dts: da850-evm: enable cpufreq
From: Bartosz Golaszewski
Enable cpufreq-dt support for da850-evm. The cvdd is supplied by the
tps65070 pmic with configurable output voltage. By default da850-evm
boards support frequencies up to 375MHz so enable this operating
point.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Adam Ford
---
arch/arm/boot/dts/da850-evm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index f04bc3e15332..f94bb38fdad9 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -191,6 +191,19 @@
};
};
+&cpu {
+ cpu-supply = <&vdcdc3_reg>;
+};
+
+/*
+ * The standard da850-evm kits and SOM's are 375MHz so enable this operating
+ * point by default. Higher frequencies must be enabled for custom boards with
+ * other variants of the SoC.
+ */
+&opp_375 {
+ status = "okay";
+};
+
&sata {
status = "okay";
};
--
2.21.0
[RESEND PATCH v5 3/5] ARM: dts: da850-lcdk: enable cpufreq
From: David Lechner
Add a fixed regulator for the da850-lcdk board along with board-specific
CPU configuration.
Signed-off-by: David Lechner
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 26f453dc8370..b36d5e36bcf1 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -155,12 +155,48 @@
};
};
};
+
+ cvdd: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "cvdd";
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <130>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&ref_clk {
clock-frequency = <2400>;
};
+&cpu {
+ cpu-supply = <&cvdd>;
+};
+
+/*
+ * LCDK has a fixed CVDD of 1.3V, so only operating points >= 300MHz are
+ * valid. Unfortunately due to a problem with the DA8XX OHCI controller, we
+ * can't enable more than one OPP by default, since the controller sometimes
+ * becomes unresponsive after a transition. Fix the frequency at 456 MHz.
+ */
+
+&opp_100 {
+ status = "disabled";
+};
+
+&opp_200 {
+ status = "disabled";
+};
+
+&opp_300 {
+ status = "disabled";
+};
+
+&opp_456 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
--
2.21.0
Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
Hey Chanwoo,
Thanks a lot for reviewing the patch. Like I
had indicated earlier we decided to go with
a simpler approach instead on qualcomm SoCs.
I am happy to re-spin this patch with your
comments addressed if we do find other users
for this feature.
On 2019-04-12 13:09, Chanwoo Choi wrote:
Hi,
I agree this approach absolutely.
Just I add some comments. Please check it.
On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
From: Saravana Kannan
Many CPU architectures have caches that can scale independent of the
CPUs. Frequency scaling of the caches is necessary to make sure the
cache
is not a performance bottleneck that leads to poor performance and
power. The same idea applies for RAM/DDR.
To achieve this, this patch add support for cpu based scaling to the
passive governor. This is accomplished by taking the current frequency
of each CPU frequency domain and then adjusts the frequency of the
cache
(or any devfreq device) based on the frequency of the CPUs. It listens
to CPU frequency transition notifiers to keep itself up to date on the
current CPU frequency.
To decide the frequency of the device, the governor does one of the
following:
* Constructs a CPU frequency to device frequency mapping table from
required-opps property of the devfreq device's opp_table
* Scales the device frequency in proportion to the CPU frequency. So,
if
the CPUs are running at their max frequency, the device runs at its
max frequency. If the CPUs are running at their min frequency, the
device runs at its min frequency. It is interpolated for frequencies
in between.
Signed-off-by: Saravana Kannan
[Sibi: Integrated cpu-freqmap governor into passive_governor]
Signed-off-by: Sibi Sankar
---
drivers/devfreq/Kconfig| 4 +
drivers/devfreq/governor_passive.c | 276
-
include/linux/devfreq.h| 43 -
3 files changed, 315 insertions(+), 8 deletions(-)
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6a172d338f6d..9a45f464a56b 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
device. This governor does not change the frequency by itself
through sysfs entries. The passive governor recommends that
devfreq device uses the OPP table to get the frequency/voltage.
+ Alternatively the governor can also be chosen to scale based on
+ the online CPUs current frequency. A CPU frequency to device
+ frequency mapping table(s) is auto-populated by the governor
+ for this purpose.
comment "DEVFREQ Drivers"
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 3bc29acbd54e..2506682b233b 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -11,10 +11,63 @@
*/
#include
+#include
+#include
+#include
#include
#include
+#include
+#include
#include "governor.h"
+static unsigned int xlate_cpufreq_to_devfreq(struct
devfreq_passive_data *data,
+unsigned int cpu)
+{
+ unsigned int cpu_min, cpu_max;
+ struct devfreq *devfreq = (struct devfreq *)data->this;
+ unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
+ unsigned long *freq_table = devfreq->profile->freq_table;
+ struct device *dev = devfreq->dev.parent;
+ struct devfreq_map *map;
+ int opp_cnt, i;
+
+ if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
+ freq = 0;
+ goto out;
goto out -> return 0;
+ }
+
+ /* Use Interpolation if map is not available */
+ cpu_freq = data->state[cpu]->freq;
+ if (!data->map) {
+ cpu_min = data->state[cpu]->min_freq;
+ cpu_max = data->state[cpu]->max_freq;
+ if (freq_table) {
+ dev_min = freq_table[0];
+ dev_max = freq_table[devfreq->profile->max_state - 1];
Actually, it is not always true. The devfreq recommend the ascending
order for
'freq_table'. But, it is not mandatory. Also, some devfreq device uses
the
decending order for 'freq_table'. So, a patch[1] was considering the
order
when getting the minimum/maximum frequency from freq_table.
If you want to get the minimum/maximum frequency, you have to consider
the order
of 'freq_table' as the patch[1].
[1] df5cf4a36178 ("PM / devfreq: Fix handling of min/max_freq == 0")
/* Get minimum frequency according to sorting order */
+ if (freq_table[0] < freq_table[df->profile->max_state -
1])
+ value = freq_table[0];
+ else
+ value = freq_table[df->profile->max_state - 1];
+ } else {
+ if (devfreq->max_freq <= devfreq->min_freq)
+ return 0;
+ dev_min = devfreq->min_freq
[RESEND PATCH v5 2/5] ARM: dts: da850-lego-ev3: enable cpufreq
From: David Lechner
Add a fixed regulator for the LEGO EV3 board along with board-specific
CPU configuration.
Signed-off-by: David Lechner
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lego-ev3.dts | 30
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 66fcadf0ba91..553717f84483 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -125,6 +125,15 @@
amp-supply = <&>;
};
+ cvdd: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "cvdd";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
/*
* This is a 5V current limiting regulator that is shared by USB,
* the sensor (input) ports, the motor (output) ports and the A/DC.
@@ -204,6 +213,27 @@
clock-frequency = <2400>;
};
+&cpu {
+ cpu-supply = <&cvdd>;
+};
+
+/* since we have a fixed regulator, we can't run at these points */
+&opp_100 {
+ status = "disabled";
+};
+
+&opp_200 {
+ status = "disabled";
+};
+
+/*
+ * The SoC is actually the 456MHz version, but because of the fixed regulator
+ * This is the fastest we can go.
+ */
+&opp_375 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
--
2.21.0
[RESEND PATCH v5 5/5] ARM: davinci_all_defconfig: Enable CPUFREQ_DT
From: David Lechner This sets CONFIG_CPUFREQ_DT=m in davinci_all_defconfig. This is used for frequency scaling on device tree boards. Signed-off-by: David Lechner Signed-off-by: Bartosz Golaszewski --- arch/arm/configs/davinci_all_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index 4a8cad4d3707..9a32a8c0f873 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -45,6 +45,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m +CONFIG_CPUFREQ_DT=m CONFIG_CPU_IDLE=y CONFIG_NET=y CONFIG_PACKET=y -- 2.21.0
Re: [PATCH v4] locking/lock_events: Use this_cpu_add() when necessary
On Fri, May 24, 2019 at 03:42:22PM -0400, Waiman Long wrote:
> +#ifdef CONFIG_DEBUG_PREEMPT
> +#define lockevent_percpu_inc(x) this_cpu_inc(x)
> +#define lockevent_percpu_add(x, v) this_cpu_add(x, v)
> +#else
> +#define lockevent_percpu_inc(x) __this_cpu_inc(x)
> +#define lockevent_percpu_add(x, v) __this_cpu_add(x, v)
> +#endif
That's disguisting... I see Linus already applied it, but yuck. That's
what we have raw_cpu_*() for.
Something like the below perhaps.
---
diff --git a/kernel/locking/lock_events.h b/kernel/locking/lock_events.h
index 46b71af8eef2..8c7e7d25f09c 100644
--- a/kernel/locking/lock_events.h
+++ b/kernel/locking/lock_events.h
@@ -31,50 +31,13 @@ enum lock_events {
DECLARE_PER_CPU(unsigned long, lockevents[lockevent_num]);
/*
- * The purpose of the lock event counting subsystem is to provide a low
- * overhead way to record the number of specific locking events by using
- * percpu counters. It is the percpu sum that matters, not specifically
- * how many of them happens in each cpu.
- *
- * It is possible that the same percpu counter may be modified in both
- * the process and interrupt contexts. For architectures that perform
- * percpu operation with multiple instructions, it is possible to lose
- * count if a process context percpu update is interrupted in the middle
- * and the same counter is updated in the interrupt context. Therefore,
- * the generated percpu sum may not be precise. The error, if any, should
- * be small and insignificant.
- *
- * For those architectures that do multi-instruction percpu operation,
- * preemption in the middle and moving the task to another cpu may cause
- * a larger error in the count. Again, this will be few and far between.
- * Given the imprecise nature of the count and the possibility of resetting
- * the count and doing the measurement again, this is not really a big
- * problem.
- *
- * To get a better picture of what is happening under the hood, it is
- * suggested that a few measurements should be taken with the counts
- * reset in between to stamp out outliner because of these possible
- * error conditions.
- *
- * To minimize overhead, we use __this_cpu_*() in all cases except when
- * CONFIG_DEBUG_PREEMPT is defined. In this particular case, this_cpu_*()
- * will be used to avoid the appearance of unwanted BUG messages.
- */
-#ifdef CONFIG_DEBUG_PREEMPT
-#define lockevent_percpu_inc(x)this_cpu_inc(x)
-#define lockevent_percpu_add(x, v) this_cpu_add(x, v)
-#else
-#define lockevent_percpu_inc(x)__this_cpu_inc(x)
-#define lockevent_percpu_add(x, v) __this_cpu_add(x, v)
-#endif
-
-/*
- * Increment the PV qspinlock statistical counters
+ * Increment the statistical counters. use raw_cpu_inc() because of lower
+ * overhead and we don't care if we loose the occasional update.
*/
static inline void __lockevent_inc(enum lock_events event, bool cond)
{
if (cond)
- lockevent_percpu_inc(lockevents[event]);
+ raw_cpu_inc(lockevents[event]);
}
#define lockevent_inc(ev)__lockevent_inc(LOCKEVENT_ ##ev, true)
@@ -82,7 +45,7 @@ static inline void __lockevent_inc(enum lock_events event,
bool cond)
static inline void __lockevent_add(enum lock_events event, int inc)
{
- lockevent_percpu_add(lockevents[event], inc);
+ raw_cpu_add(lockevents[event], inc);
}
#define lockevent_add(ev, c) __lockevent_add(LOCKEVENT_ ##ev, c)
[RESEND PATCH v5 0/5] ARM: da850: enable cpufreq in DT mode
From: Bartosz Golaszewski Note: resending rebased on top of v5.2-rc2 === This series adds cpufreq-dt operating points for da850 boards supported with device tree (da850-lcdk, da850-lego-ev3, da850-evm). Last patch enables CPUFREQ_DT in davinci_all_defconfig. v1 -> v2: - use the VDCDC3_1.2V regulator as cpu-supply on da850-evm v2 -> v3: - drop patch 1, as the revision tag is in fact correctly passed to the kernel by u-boot - only enable the 375 operating point for da850-evm as this is the standard frequency for this board v3 -> v4: - split the first patch into three separate changesets: one adding the operating points to the main dtsi and two enabling cpufreq on da850-lego-ev3 and da850-lcdk - remove the operating point not mentioned in the datasheet (415 MHz) - fix commit message in patch 4/5 v4 -> v5: - only enable a single OPP for da850-lcdk due to the problem with the OHCI controller becoming unresponsive after cpufreq transitions - fix the name of the pmic on da850-evm Bartosz Golaszewski (1): ARM: dts: da850-evm: enable cpufreq David Lechner (4): ARM: dts: da850: add cpu node and operating points to DT ARM: dts: da850-lego-ev3: enable cpufreq ARM: dts: da850-lcdk: enable cpufreq ARM: davinci_all_defconfig: Enable CPUFREQ_DT arch/arm/boot/dts/da850-evm.dts| 13 +++ arch/arm/boot/dts/da850-lcdk.dts | 36 +++ arch/arm/boot/dts/da850-lego-ev3.dts | 30 arch/arm/boot/dts/da850.dtsi | 50 ++ arch/arm/configs/davinci_all_defconfig | 1 + 5 files changed, 130 insertions(+) -- 2.21.0
Re: [PATCH] jbd2: fix typo in comment of journal_submit_inode_data_buffers
On Sat 25-05-19 17:12:51, Liu Song wrote: > From: Liu Song > > delayed/dealyed > > Signed-off-by: Liu Song Thanks. You can add: Reviewed-by: Jan Kara Honza > --- > fs/jbd2/commit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c > index 150cc030b4d7..0395ca016235 100644 > --- a/fs/jbd2/commit.c > +++ b/fs/jbd2/commit.c > @@ -184,7 +184,7 @@ static int journal_wait_on_commit_record(journal_t > *journal, > /* > * write the filemap data using writepage() address_space_operations. > * We don't do block allocation here even for delalloc. We don't > - * use writepages() because with dealyed allocation we may be doing > + * use writepages() because with delayed allocation we may be doing > * block allocation in writepages(). > */ > static int journal_submit_inode_data_buffers(struct address_space *mapping) > -- > 2.20.1 > > -- Jan Kara SUSE Labs, CR
Re: 5.1 and 5.1.1: BUG: unable to handle kernel paging request at ffffea0002030000
On Mon, May 27, 2019 at 08:23:01AM +0200, Oleksandr Natalenko wrote: > On Fri, May 24, 2019 at 01:31:46PM +0100, Mel Gorman wrote: > > On Fri, May 24, 2019 at 01:43:29PM +0200, Oleksandr Natalenko wrote: > > > > Please use the offset 0xb9 > > > > > > > > addr2line -i -e /usr/src/linux/vmlinux `printf "0x%lX" $((0x$ADDR+0xb9)) > > > > > > > > -- > > > > Mel Gorman > > > > SUSE Labs > > > > > > Cc'ing myself since i observe such a behaviour sometimes right after KVM > > > VM is launched. No luck with reproducing it on demand so far, though. > > > > > > > It's worth testing the patch at > > https://lore.kernel.org/lkml/1558689619-16891-1-git-send-email-suzuki.poul...@arm.com/T/#u > > It is reported [1] that this fixes the issue. > > Thanks. > > [1] https://github.com/NixOS/nixpkgs/issues/61909 > Thanks! The patch has been picked up by Andrew and it's marked for -stable. It should make its way into a stable release eventually. -- Mel Gorman SUSE Labs
[PATCH -mm] mm, swap: Simplify total_swapcache_pages() with get_swap_device()
From: Huang Ying
total_swapcache_pages() may race with swapper_spaces[] allocation and
freeing. Previously, this is protected with a swapper_spaces[]
specific RCU mechanism. To simplify the logic/code complexity, it is
replaced with get/put_swap_device(). The code line number is reduced
too. Although not so important, the swapoff() performance improves
too because one synchronize_rcu() call during swapoff() is deleted.
Signed-off-by: "Huang, Ying"
Cc: Hugh Dickins
Cc: Paul E. McKenney
Cc: Minchan Kim
Cc: Johannes Weiner
Cc: Tim Chen
Cc: Mel Gorman
Cc: Jérôme Glisse
Cc: Michal Hocko
Cc: Andrea Arcangeli
Cc: Yang Shi
Cc: David Rientjes
Cc: Rik van Riel
Cc: Jan Kara
Cc: Dave Jiang
Cc: Daniel Jordan
Cc: Andrea Parri
---
mm/swap_state.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/mm/swap_state.c b/mm/swap_state.c
index f509cdaa81b1..b84c58b572ca 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -73,23 +73,19 @@ unsigned long total_swapcache_pages(void)
unsigned int i, j, nr;
unsigned long ret = 0;
struct address_space *spaces;
+ struct swap_info_struct *si;
- rcu_read_lock();
for (i = 0; i < MAX_SWAPFILES; i++) {
- /*
-* The corresponding entries in nr_swapper_spaces and
-* swapper_spaces will be reused only after at least
-* one grace period. So it is impossible for them
-* belongs to different usage.
-*/
- nr = nr_swapper_spaces[i];
- spaces = rcu_dereference(swapper_spaces[i]);
- if (!nr || !spaces)
+ /* Prevent swapoff to free swapper_spaces */
+ si = get_swap_device(swp_entry(i, 1));
+ if (!si)
continue;
+ nr = nr_swapper_spaces[i];
+ spaces = swapper_spaces[i];
for (j = 0; j < nr; j++)
ret += spaces[j].nrpages;
+ put_swap_device(si);
}
- rcu_read_unlock();
return ret;
}
@@ -611,20 +607,16 @@ int init_swap_address_space(unsigned int type, unsigned
long nr_pages)
mapping_set_no_writeback_tags(space);
}
nr_swapper_spaces[type] = nr;
- rcu_assign_pointer(swapper_spaces[type], spaces);
+ swapper_spaces[type] = spaces;
return 0;
}
void exit_swap_address_space(unsigned int type)
{
- struct address_space *spaces;
-
- spaces = swapper_spaces[type];
+ kvfree(swapper_spaces[type]);
nr_swapper_spaces[type] = 0;
- rcu_assign_pointer(swapper_spaces[type], NULL);
- synchronize_rcu();
- kvfree(spaces);
+ swapper_spaces[type] = NULL;
}
static inline void swap_ra_clamp_pfn(struct vm_area_struct *vma,
--
2.20.1
Re: [RFC PATCH 0/6] x86/mm: Flush remote and local TLBs concurrently
On Sat, May 25, 2019 at 01:21:57AM -0700, Nadav Amit wrote: > The proposed changes should also improve the performance of other > invocations of on_each_cpu(). Hopefully, no one has relied on the > behavior of on_each_cpu() that functions were first executed remotely > and only then locally. Oh gawd... I actually have vague memories of code doing exactly that, but I can't for the life of me remember where :/:
RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: Add temperature sensor node
Hi Leo,
> -Original Message-
> From: Li Yang
> Sent: 2019年5月25日 6:32
> To: Andy Tang
> Cc: Shawn Guo ; Rob Herring ;
> Mark Rutland ; moderated list:ARM/FREESCALE
> IMX / MXC ARM ARCHITECTURE ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; lkml
> Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: Add temperature sensor
> node
>
> Caution: EXT Email
>
> On Thu, May 23, 2019 at 8:30 PM Yuantian Tang
> wrote:
> >
> > Add nxp sa56004 chip node for temperature monitor.
> >
> > Signed-off-by: Yuantian Tang
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 5 +
> > arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 5 +
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > index b359068d9605..31fd626dd344 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > @@ -131,6 +131,11 @@
> > compatible = "atmel,24c512";
> > reg = <0x57>;
> > };
> > +
> > + temp@4c {
>
> The recommended name for temperature senor in dts spec is
> temperature-sensor.
I didn't find the spec for this recommendation. Could you please provide the
link?
I like to update it to temp-sensor though.
>
> > + compatible = "nxp,sa56004";
>
> The binding says the following property is required. If it is not the case,
> probably we should update the binding.
> - vcc-supply: vcc regulator for the supply voltage.
I will add the vcc-supply to comply this requirement.
Thanks,
Andy
>
> > + reg = <0x4c>;
> > + };
> > };
> >
> > i2c@5 {
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > index f9c272fb0738..012b3f8696b7 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> > @@ -119,6 +119,11 @@
> > compatible = "nxp,pcf2129";
> > reg = <0x51>;
> > };
> > +
> > + temp@4c {
> > + compatible = "nxp,sa56004";
> > + reg = <0x4c>;
> > + };
> > };
> > };
> > };
> > --
> > 2.17.1
> >
Re: [RFC PATCH 2/6] cpumask: Purify cpumask_next()
On Sat, May 25, 2019 at 01:21:59AM -0700, Nadav Amit wrote: > cpumask_next() has no side-effects. Mark it as pure. It would be good to have a few word on why... because apparently you found this makes a difference. > Cc: "David S. Miller" > Signed-off-by: Nadav Amit > --- > include/linux/cpumask.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h > index 147bdec42215..20df46705f9c 100644 > --- a/include/linux/cpumask.h > +++ b/include/linux/cpumask.h > @@ -209,7 +209,7 @@ static inline unsigned int cpumask_last(const struct > cpumask *srcp) > return find_last_bit(cpumask_bits(srcp), nr_cpumask_bits); > } > > -unsigned int cpumask_next(int n, const struct cpumask *srcp); > +unsigned int __pure cpumask_next(int n, const struct cpumask *srcp); > > /** > * cpumask_next_zero - get the next unset cpu in a cpumask > -- > 2.20.1 >
[PATCH] scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE
At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line number is not
decoded correctly by 'decode_stacktrace.sh':
$ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \
CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
/scratch/linux-arm64 \
/nfs/debian/lib/modules/4.20.0-devel
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash
If addr2line from the toolchain is used the decoded line number is correct:
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash
Signed-off-by: Manuel Traut
---
scripts/decode_stacktrace.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index bcdd45df3f51..a7a36209a193 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -73,7 +73,7 @@ parse_symbol() {
if [[ "${cache[$module,$address]+isset}" == "isset" ]]; then
local code=${cache[$module,$address]}
else
- local code=$(addr2line -i -e "$objfile" "$address")
+ local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile"
"$address")
cache[$module,$address]=$code
fi
--
2.20.1
[PATCH 2/2] arm64: replace _BITUL() with BIT()
Now that BIT() can be used from assembly code, replace _BITUL() with equivalent BIT(). Signed-off-by: Masahiro Yamada --- arch/arm64/include/asm/sysreg.h | 82 - 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 902d75b60914..3bcd8294acc0 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -20,7 +20,7 @@ #ifndef __ASM_SYSREG_H #define __ASM_SYSREG_H -#include +#include #include /* @@ -458,31 +458,31 @@ #define SYS_ZCR_EL12 sys_reg(3, 5, 1, 2, 0) /* Common SCTLR_ELx flags. */ -#define SCTLR_ELx_DSSBS(_BITUL(44)) -#define SCTLR_ELx_ENIA (_BITUL(31)) -#define SCTLR_ELx_ENIB (_BITUL(30)) -#define SCTLR_ELx_ENDA (_BITUL(27)) -#define SCTLR_ELx_EE(_BITUL(25)) -#define SCTLR_ELx_IESB (_BITUL(21)) -#define SCTLR_ELx_WXN (_BITUL(19)) -#define SCTLR_ELx_ENDB (_BITUL(13)) -#define SCTLR_ELx_I(_BITUL(12)) -#define SCTLR_ELx_SA (_BITUL(3)) -#define SCTLR_ELx_C(_BITUL(2)) -#define SCTLR_ELx_A(_BITUL(1)) -#define SCTLR_ELx_M(_BITUL(0)) +#define SCTLR_ELx_DSSBS(BIT(44)) +#define SCTLR_ELx_ENIA (BIT(31)) +#define SCTLR_ELx_ENIB (BIT(30)) +#define SCTLR_ELx_ENDA (BIT(27)) +#define SCTLR_ELx_EE(BIT(25)) +#define SCTLR_ELx_IESB (BIT(21)) +#define SCTLR_ELx_WXN (BIT(19)) +#define SCTLR_ELx_ENDB (BIT(13)) +#define SCTLR_ELx_I(BIT(12)) +#define SCTLR_ELx_SA (BIT(3)) +#define SCTLR_ELx_C(BIT(2)) +#define SCTLR_ELx_A(BIT(1)) +#define SCTLR_ELx_M(BIT(0)) #define SCTLR_ELx_FLAGS(SCTLR_ELx_M | SCTLR_ELx_A | SCTLR_ELx_C | \ SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB) /* SCTLR_EL2 specific flags. */ -#define SCTLR_EL2_RES1 ((_BITUL(4)) | (_BITUL(5)) | (_BITUL(11)) | (_BITUL(16)) | \ -(_BITUL(18)) | (_BITUL(22)) | (_BITUL(23)) | (_BITUL(28)) | \ -(_BITUL(29))) -#define SCTLR_EL2_RES0 ((_BITUL(6)) | (_BITUL(7)) | (_BITUL(8)) | (_BITUL(9)) | \ -(_BITUL(10)) | (_BITUL(13)) | (_BITUL(14)) | (_BITUL(15)) | \ -(_BITUL(17)) | (_BITUL(20)) | (_BITUL(24)) | (_BITUL(26)) | \ -(_BITUL(27)) | (_BITUL(30)) | (_BITUL(31)) | \ +#define SCTLR_EL2_RES1 ((BIT(4)) | (BIT(5)) | (BIT(11)) | (BIT(16)) | \ +(BIT(18)) | (BIT(22)) | (BIT(23)) | (BIT(28)) | \ +(BIT(29))) +#define SCTLR_EL2_RES0 ((BIT(6)) | (BIT(7)) | (BIT(8)) | (BIT(9)) | \ +(BIT(10)) | (BIT(13)) | (BIT(14)) | (BIT(15)) | \ +(BIT(17)) | (BIT(20)) | (BIT(24)) | (BIT(26)) | \ +(BIT(27)) | (BIT(30)) | (BIT(31)) | \ (0xefffUL << 32)) #ifdef CONFIG_CPU_BIG_ENDIAN @@ -504,23 +504,23 @@ #endif /* SCTLR_EL1 specific flags. */ -#define SCTLR_EL1_UCI (_BITUL(26)) -#define SCTLR_EL1_E0E (_BITUL(24)) -#define SCTLR_EL1_SPAN (_BITUL(23)) -#define SCTLR_EL1_NTWE (_BITUL(18)) -#define SCTLR_EL1_NTWI (_BITUL(16)) -#define SCTLR_EL1_UCT (_BITUL(15)) -#define SCTLR_EL1_DZE (_BITUL(14)) -#define SCTLR_EL1_UMA (_BITUL(9)) -#define SCTLR_EL1_SED (_BITUL(8)) -#define SCTLR_EL1_ITD (_BITUL(7)) -#define SCTLR_EL1_CP15BEN (_BITUL(5)) -#define SCTLR_EL1_SA0 (_BITUL(4)) - -#define SCTLR_EL1_RES1 ((_BITUL(11)) | (_BITUL(20)) | (_BITUL(22)) | (_BITUL(28)) | \ -(_BITUL(29))) -#define SCTLR_EL1_RES0 ((_BITUL(6)) | (_BITUL(10)) | (_BITUL(13)) | (_BITUL(17)) | \ -(_BITUL(27)) | (_BITUL(30)) | (_BITUL(31)) | \ +#define SCTLR_EL1_UCI (BIT(26)) +#define SCTLR_EL1_E0E (BIT(24)) +#define SCTLR_EL1_SPAN (BIT(23)) +#define SCTLR_EL1_NTWE (BIT(18)) +#define SCTLR_EL1_NTWI (BIT(16)) +#define SCTLR_EL1_UCT (BIT(15)) +#define SCTLR_EL1_DZE (BIT(14)) +#define SCTLR_EL1_UMA (BIT(9)) +#define SCTLR_EL1_SED (BIT(8)) +#define SCTLR_EL1_ITD (BIT(7)) +#define SCTLR_EL1_CP15BEN (BIT(5)) +#define SCTLR_EL1_SA0 (BIT(4)) + +#define SCTLR_EL1_RES1 ((BIT(11)) | (BIT(20)) | (BIT(22)) | (BIT(28)) | \ +(BIT(29))) +#define SCTLR_EL1_RES0 ((BIT(6)) | (BIT(10)) | (BIT(13)) | (BIT(17)) | \ +(BIT(27)) | (BIT(30)) | (BIT(31)) | \ (0xefffUL << 32)) #ifdef CONFIG_CPU_BIG_ENDIAN @@ -735,13 +735,13 @@ #define ZCR_ELx_LEN_SIZE 9 #define ZCR_ELx_LEN_MASK 0x1ff -#define CPACR_EL1_ZEN_EL1EN(_BITUL(16)) /* enable EL1 access */ -#define CPACR_EL1_ZEN_EL0EN(_BITUL(17)) /* enable EL0 access, if EL1EN set */ +#define CPACR_EL1_ZEN_EL1EN(BIT(16)) /* enable EL1 access */ +#define CPACR_EL1_ZEN_EL0EN(BIT(17)) /* enable EL0 access, if EL1EN
[PATCH 0/2] Allow assembly code to use BIT(), GENMASK(), etc. and clean-up arm64 header
Some in-kernel headers use _BITUL() instead of BIT(). arch/arm64/include/asm/sysreg.h arch/s390/include/asm/*.h I think the reason is because BIT() is currently not available in assembly. It hard-codes 1UL, which is not available in assembly. 1/2 replaced 1UL -> UL(1) 0UL -> UL(0) 1ULL -> ULL(1) 0ULL -> ULL(0) With this, there is no more restriction that prevents assembly code from using them. 2/2 is a clean-up as as example. I can contribute to cleanups of arch/s390/, etc. once this series lands in upstream. I hope both patches can go in the arm64 tree. Masahiro Yamada (2): linux/bits.h: make BIT(), GENMASK(), and friends available in assembly arm64: replace _BITUL() with BIT() arch/arm64/include/asm/sysreg.h | 82 - include/linux/bits.h| 17 --- 2 files changed, 51 insertions(+), 48 deletions(-) -- 2.17.1
[PATCH 1/2] linux/bits.h: make BIT(), GENMASK(), and friends available in assembly
BIT(), GENMASK(), etc. are useful to define register bits of hardware. However, low-level code is often written in assembly, where they are not available due to the hard-coded 1UL, 0UL. In fact, in-kernel headers such as arch/arm64/include/asm/sysreg.h use _BITUL() instead of BIT() so that the register bit macros are available in assembly. Using macros in include/uapi/linux/const.h have two reasons: [1] For use in uapi headers We should use underscore-prefixed variants for user-space. [2] For use in assembly code Since _BITUL() does not use hard-coded 1UL, it can be used as an alternative of BIT(). For [2], it is pretty easy to change BIT() etc. for use in assembly. This allows to replace _BUTUL() in kernel headers with BIT(). Signed-off-by: Masahiro Yamada --- include/linux/bits.h | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/include/linux/bits.h b/include/linux/bits.h index 2b7b532c1d51..669d69441a62 100644 --- a/include/linux/bits.h +++ b/include/linux/bits.h @@ -1,13 +1,15 @@ /* SPDX-License-Identifier: GPL-2.0 */ #ifndef __LINUX_BITS_H #define __LINUX_BITS_H + +#include #include -#define BIT(nr)(1UL << (nr)) -#define BIT_ULL(nr)(1ULL << (nr)) -#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) +#define BIT(nr)(UL(1) << (nr)) +#define BIT_ULL(nr)(ULL(1) << (nr)) +#define BIT_MASK(nr) (UL(1) << ((nr) % BITS_PER_LONG)) #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) -#define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG)) +#define BIT_ULL_MASK(nr) (ULL(1) << ((nr) % BITS_PER_LONG_LONG)) #define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG) #define BITS_PER_BYTE 8 @@ -17,10 +19,11 @@ * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. */ #define GENMASK(h, l) \ - (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h + (((~UL(0)) - (UL(1) << (l)) + 1) & \ +(~UL(0) >> (BITS_PER_LONG - 1 - (h #define GENMASK_ULL(h, l) \ - (((~0ULL) - (1ULL << (l)) + 1) & \ -(~0ULL >> (BITS_PER_LONG_LONG - 1 - (h + (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h #endif /* __LINUX_BITS_H */ -- 2.17.1
Re: [PATCH net-next v2 1/2] i2c: acpi: export i2c_acpi_find_adapter_by_handle
On Fri, May 24, 2019 at 05:53:01PM -0700, Ruslan Babayev wrote:
> +struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle);
> #else
> static inline bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
>struct acpi_resource_i2c_serialbus
> **i2c)
> @@ -996,6 +998,10 @@ static inline struct i2c_client
> *i2c_acpi_new_device(struct device *dev,
> {
> return NULL;
> }
> +struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
This should be static inline, I think.
> +{
> + return NULL;
> +}
> #endif /* CONFIG_ACPI */
>
> #endif /* _LINUX_I2C_H */
> --
> 2.17.1
Re: [PATCH RESEND] input: adp5589: Add gpio_set_multiple interface
Hi Dmitry,
Thank you for your review
On Thu, 2019-05-23 at 00:18 -0700, Dmitry Torokhov wrote:
> [External]
>
>
> Hi Bogdan,
>
> On Tue, May 21, 2019 at 11:38:22AM +0300, Bogdan Togorean wrote:
> > This patch implements the gpio_set_multiple interface for ADP558x
> > chip.
> >
> > Signed-off-by: Bogdan Togorean
> > ---
> > drivers/input/keyboard/adp5589-keys.c | 25
> > +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/adp5589-keys.c
> > b/drivers/input/keyboard/adp5589-keys.c
> > index 2835fba71c33..143871bd60ef 100644
> > --- a/drivers/input/keyboard/adp5589-keys.c
> > +++ b/drivers/input/keyboard/adp5589-keys.c
> > @@ -416,6 +416,30 @@ static void adp5589_gpio_set_value(struct
> > gpio_chip *chip,
> > mutex_unlock(&kpad->gpio_lock);
> > }
> >
> > +static void adp5589_gpio_set_multiple(struct gpio_chip *chip,
> > + unsigned long *mask, unsigned
> > long *bits)
> > +{
> > + struct adp5589_kpad *kpad = container_of(chip, struct
> > adp5589_kpad, gc);
> > + u8 bank, reg_mask, reg_bits;
> > +
> > + mutex_lock(&kpad->gpio_lock);
> > +
> > + for (bank = 0; bank <= kpad->var->bank(kpad->var->maxgpio);
> > bank++) {
> > + if (bank > kpad->var->bank(get_bitmask_order(*mask) -
> > 1))
> > + break;
>
> I wonder if we should have:
>
> last_gpio = min(kpad->var->maxgpio, get_bitmask_order(*mask)
> - 1);
> last_bank = kpad->var->bank(last_bank);
> for (bank = 0; bank <= last_bank; bank++) {
> ...
> }
I agree this can be made more clear in the way you proposed.
>
> > + reg_mask = mask[bank / sizeof(*mask)] >>
> > +((bank % sizeof(*mask)) * BITS_PER_BYTE);
> > + reg_bits = bits[bank / sizeof(*bits)] >>
> > +((bank % sizeof(*bits)) * BITS_PER_BYTE);
>
> This s really hard to parse. We know that "bank" is a byte, and mask
> is
> long, we do not have to be this roundabout it.
Here main reasons for doing this complexity were to support 64bit/32bit
architectures (differet long size) and to avoid use of magic values
(BITS_PER_BYTE)
>
> > + kpad->dat_out[bank] &= ~reg_mask;
> > + kpad->dat_out[bank] |= reg_bits & reg_mask;
> > + adp5589_write(kpad->client, kpad->var-
> > >reg(ADP5589_GPO_DATA_OUT_A) + bank,
> > + kpad->dat_out[bank]);
> > + }
>
> However the biggest issue is that this implementation seems to ignore
> the kpad->gpiomap that translates GPIO numbers as seen by gpiolib to
> GPIO numbers used by the chip. You need to reshuffle the mask and
> bits,
> and only then do the writes.
>
> Given the complexities, does set_multiple really save anything?
>
We have a critical application where we need to set multiple GPIOs that
are on the same bank simultaneously. No delay accepted. So this was the
usecase which led to implementation of set_multiple_interface for this
chip.
> Thanks.
>
> --
> Dmitry
Thank you,
Bogdan
Re: Linux in KVM guest segfaults when hosts runs Linux 5.1
On Tue, May 14, 2019 at 08:51:28AM +0200, Marc Haber wrote: > On Mon, May 13, 2019 at 04:10:35PM +0200, Radim Krčmář wrote: > > 2019-05-12 13:53+0200, Marc Haber: > > > since updating my home desktop machine to kernel 5.1.1, KVM guests > > > started on that machine segfault after booting: > > [...] > > > Any idea short of bisecting? > > > > It has also been spotted by Borislav and the fix [1] should land in the > > next kernel update, thanks for the report. > > 1: https://patchwork.kernel.org/patch/10936271/ > > I can confirm that this patch fixes the segfaults for me. And it is not yet in Linux 5.1.5. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[PATCH 2/2] drm/i915/gvt: Support delivering page flip event to userspace
Use the eventfd based signaling mechanism provided by vfio/display
to deliver vGPU framebuffer page flip event to userspace.
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 31 +
drivers/gpu/drm/i915/gvt/dmabuf.h | 1 +
drivers/gpu/drm/i915/gvt/gvt.c | 1 +
drivers/gpu/drm/i915/gvt/gvt.h | 2 ++
drivers/gpu/drm/i915/gvt/handlers.c | 2 ++
drivers/gpu/drm/i915/gvt/kvmgt.c| 7 +++
6 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 4e1e425189ba..f2ed45616d72 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -538,6 +538,35 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
unsigned int dmabuf_id)
return ret;
}
+static void release_flip_eventfd_ctx(struct intel_vgpu *vgpu)
+{
+ struct eventfd_ctx **trigger = &vgpu->page_flip_trigger;
+
+ if (*trigger) {
+ eventfd_ctx_put(*trigger);
+ *trigger = NULL;
+ }
+}
+
+int intel_vgpu_set_flip_eventfd(struct intel_vgpu *vgpu, int fd)
+{
+ struct eventfd_ctx *trigger;
+
+ if (fd == -1) {
+ release_flip_eventfd_ctx(vgpu);
+ } else if (fd >= 0) {
+ trigger = eventfd_ctx_fdget(fd);
+ if (IS_ERR(trigger)) {
+ gvt_vgpu_err("eventfd_ctx_fdget failed\n");
+ return PTR_ERR(trigger);
+ }
+ vgpu->page_flip_trigger = trigger;
+ } else
+ return -EINVAL;
+
+ return 0;
+}
+
void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
{
struct list_head *pos, *n;
@@ -561,4 +590,6 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
}
mutex_unlock(&vgpu->dmabuf_lock);
+
+ release_flip_eventfd_ctx(vgpu);
}
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
b/drivers/gpu/drm/i915/gvt/dmabuf.h
index 5f8f03fb1d1b..4d9caa3732d2 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.h
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
@@ -62,6 +62,7 @@ struct intel_vgpu_dmabuf_obj {
int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args);
int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned int dmabuf_id);
+int intel_vgpu_set_flip_eventfd(struct intel_vgpu *vgpu, int fd);
void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu);
#endif
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 43f4242062dd..7fd4afa432ef 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -184,6 +184,7 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.get_gvt_attrs = intel_get_gvt_attrs,
.vgpu_query_plane = intel_vgpu_query_plane,
.vgpu_get_dmabuf = intel_vgpu_get_dmabuf,
+ .vgpu_set_flip_eventfd = intel_vgpu_set_flip_eventfd,
.write_protect_handler = intel_vgpu_page_track_handler,
.emulate_hotplug = intel_vgpu_emulate_hotplug,
};
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index f5a328b5290a..86ca223f9a60 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -229,6 +229,7 @@ struct intel_vgpu {
struct completion vblank_done;
u32 scan_nonprivbb;
+ struct eventfd_ctx *page_flip_trigger;
};
/* validating GM healthy status*/
@@ -570,6 +571,7 @@ struct intel_gvt_ops {
struct attribute_group ***intel_vgpu_type_groups);
int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
+ int (*vgpu_set_flip_eventfd)(struct intel_vgpu *vgpu, int fd);
int (*write_protect_handler)(struct intel_vgpu *, u64, void *,
unsigned int);
void (*emulate_hotplug)(struct intel_vgpu *vgpu, bool connected);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 18f01eeb2510..1b5455888bdf 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -763,6 +763,8 @@ static int pri_surf_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
else
set_bit(event, vgpu->irq.flip_done_event[pipe]);
+ eventfd_signal(vgpu->page_flip_trigger, 1);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index a68addf95c23..00c75bd76bc0 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1547,6 +1547,13 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
dmabuf_fd = intel_gvt_ops->vgpu_get_dmabuf(vgpu, dmabuf_id);
return dmabuf_fd;
+ } else if (cmd == VFIO_DEVICE_SET_GFX_FLIP_EVENTFD) {
+ __s32 event_fd;
+
+ if (get_user(event_fd, (__s32 __user *)arg))
+ return -E
[PATCH 0/2] Deliver vGPU page flip event to userspace
This series introduces VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set the eventfd based signaling mechanism in vfio display. vGPU can use this eventfd to deliver the framebuffer page flip event to userspace. Tina Zhang (2): vfio: ABI for setting mdev display flip eventfd drm/i915/gvt: Support delivering page flip event to userspace drivers/gpu/drm/i915/gvt/dmabuf.c | 31 + drivers/gpu/drm/i915/gvt/dmabuf.h | 1 + drivers/gpu/drm/i915/gvt/gvt.c | 1 + drivers/gpu/drm/i915/gvt/gvt.h | 2 ++ drivers/gpu/drm/i915/gvt/handlers.c | 2 ++ drivers/gpu/drm/i915/gvt/kvmgt.c| 7 +++ include/uapi/linux/vfio.h | 12 +++ 7 files changed, 56 insertions(+) -- 2.17.1
[PATCH 1/2] vfio: ABI for setting mdev display flip eventfd
Add VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set eventfd
based signaling mechanism to deliver vGPU framebuffer page flip
event to userspace.
Signed-off-by: Tina Zhang
---
include/uapi/linux/vfio.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 02bb7ad6e986..27300597717f 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -696,6 +696,18 @@ struct vfio_device_ioeventfd {
#define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 16)
+/**
+ * VFIO_DEVICE_SET_GFX_FLIP_EVENTFD - _IOW(VFIO_TYPE, VFIO_BASE + 17, __s32)
+ *
+ * Set eventfd based signaling mechanism to deliver vGPU framebuffer page
+ * flip event to userspace. A value of -1 is used to stop the page flip
+ * delivering.
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+
+#define VFIO_DEVICE_SET_GFX_FLIP_EVENTFD _IO(VFIO_TYPE, VFIO_BASE + 17)
+
/* API for Type1 VFIO IOMMU */
/**
--
2.17.1
[PATCH v2 0/7] add edma2 for i.mx7ulp
From: Robin Gong This patch set add new version of edma for i.mx7ulp, the main changes are as belows: 1. only one dmamux. 2. another clock dma_clk except dmamux clk. 3. 16 independent interrupts instead of only one interrupt for all channels. For the first change, need modify fsl-edma-common.c and mcf-edma, so create the first two patches to prepare without any function impact. For the third change, need request single irq for every channel with the legacy handler. But actually 2 dma channels share one interrupt(16 channel interrupts, but 32 channels.),ch0/ch16,ch1/ch17... For now, just simply request irq without IRQF_SHARED flag, since 16 channels are enough on i.mx7ulp whose M4 domain own some peripherals. change from v1: 1. Check .data of 'of_device_id' in probe instead of compatible name. 2. pull binding doc patch before driver patch. Robin Gong (7): dmaengine: fsl-edma: add dmamux_nr for next version dmaengine: mcf-edma: update to 'dmamux_nr' dmaengine: fsl-edma-common: move dmamux register to another single function dmaengine: fsl-edma-common: version check for v2 instead dt-bindings: dma: fsl-edma: add new i.mx7ulp-edma dmaengine: fsl-edma: add i.mx7ulp edma2 version support ARM: dts: imx7ulp: add edma device node Documentation/devicetree/bindings/dma/fsl-edma.txt | 44 -- arch/arm/boot/dts/imx7ulp.dtsi | 28 +++ drivers/dma/fsl-edma-common.c | 74 +++-- drivers/dma/fsl-edma-common.h | 4 + drivers/dma/fsl-edma.c | 95 +++--- drivers/dma/mcf-edma.c | 1 + 6 files changed, 204 insertions(+), 42 deletions(-) -- 2.7.4
[PATCH v2 6/7] dmaengine: fsl-edma: add i.mx7ulp edma2 version support
From: Robin Gong
Add edma2 for i.mx7ulp by version v3, since v2 has already
been used by mcf-edma.
The big changes based on v1 are belows:
1. only one dmamux.
2. another clock dma_clk except dmamux clk.
3. 16 independent interrupts instead of only one interrupt for
all channels.
Signed-off-by: Robin Gong
---
drivers/dma/fsl-edma-common.c | 18 +-
drivers/dma/fsl-edma-common.h | 3 ++
drivers/dma/fsl-edma.c| 84 ++-
3 files changed, 96 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index 45d70d3..0d9915c 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -90,6 +90,19 @@ static void mux_configure8(struct fsl_edma_chan *fsl_chan,
void __iomem *addr,
iowrite8(val8, addr + off);
}
+void mux_configure32(struct fsl_edma_chan *fsl_chan, void __iomem *addr,
+u32 off, u32 slot, bool enable)
+{
+ u32 val;
+
+ if (enable)
+ val = EDMAMUX_CHCFG_ENBL << 24 | slot;
+ else
+ val = EDMAMUX_CHCFG_DIS;
+
+ iowrite32(val, addr + off * 4);
+}
+
void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
unsigned int slot, bool enable)
{
@@ -102,7 +115,10 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
slot = EDMAMUX_CHCFG_SOURCE(slot);
- mux_configure8(fsl_chan, muxaddr, ch_off, slot, enable);
+ if (fsl_chan->edma->version == v3)
+ mux_configure32(fsl_chan, muxaddr, ch_off, slot, enable);
+ else
+ mux_configure8(fsl_chan, muxaddr, ch_off, slot, enable);
}
EXPORT_SYMBOL_GPL(fsl_edma_chan_mux);
diff --git a/drivers/dma/fsl-edma-common.h b/drivers/dma/fsl-edma-common.h
index 21a9cfd..2b0cc8e 100644
--- a/drivers/dma/fsl-edma-common.h
+++ b/drivers/dma/fsl-edma-common.h
@@ -124,6 +124,7 @@ struct fsl_edma_chan {
dma_addr_t dma_dev_addr;
u32 dma_dev_size;
enum dma_data_direction dma_dir;
+ charchan_name[16];
};
struct fsl_edma_desc {
@@ -138,6 +139,7 @@ struct fsl_edma_desc {
enum edma_version {
v1, /* 32ch, Vybrid, mpc57x, etc */
v2, /* 64ch Coldfire */
+ v3, /* 32ch, i.mx7ulp */
};
struct fsl_edma_engine {
@@ -145,6 +147,7 @@ struct fsl_edma_engine {
void __iomem*membase;
void __iomem*muxbase[DMAMUX_NR];
struct clk *muxclk[DMAMUX_NR];
+ struct clk *dmaclk;
u32 dmamux_nr;
struct mutexfsl_edma_mutex;
u32 n_chans;
diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c
index 7b65ef4..055f430 100644
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -165,6 +165,51 @@ fsl_edma_irq_init(struct platform_device *pdev, struct
fsl_edma_engine *fsl_edma
return 0;
}
+static int
+fsl_edma2_irq_init(struct platform_device *pdev,
+ struct fsl_edma_engine *fsl_edma)
+{
+ struct device_node *np = pdev->dev.of_node;
+ int i, ret, irq;
+ int count = 0;
+
+ count = of_irq_count(np);
+ dev_info(&pdev->dev, "%s Found %d interrupts\r\n", __func__, count);
+ if (count <= 2) {
+ dev_err(&pdev->dev, "Interrupts in DTS not correct.\n");
+ return -EINVAL;
+ }
+ /*
+* 16 channel independent interrupts + 1 error interrupt on i.mx7ulp.
+* 2 channel share one interrupt, for example, ch0/ch16, ch1/ch17...
+* For now, just simply request irq without IRQF_SHARED flag, since 16
+* channels are enough on i.mx7ulp whose M4 domain own some peripherals.
+*/
+ for (i = 0; i < count; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return -ENXIO;
+
+ sprintf(fsl_edma->chans[i].chan_name, "eDMA2-CH%02d", i);
+
+ /* The last IRQ is for eDMA err */
+ if (i == count - 1)
+ ret = devm_request_irq(&pdev->dev, irq,
+ fsl_edma_err_handler,
+ 0, "eDMA2-ERR", fsl_edma);
+ else
+
+ ret = devm_request_irq(&pdev->dev, irq,
+ fsl_edma_tx_handler, 0,
+ fsl_edma->chans[i].chan_name,
+ fsl_edma);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static void fsl_edma_irq_exit(
struct platform_device *pdev, struct fsl_edma_engine *fsl_edma)
{
@@ -184,8 +229,17 @@ static void fsl_disable_clocks(struct
[PATCH v2 5/7] dt-bindings: dma: fsl-edma: add new i.mx7ulp-edma
From: Robin Gong
More channel interrupts, one more clock, and only one
dmamux on i.mx7ulp-edma.
Signed-off-by: Robin Gong
---
Documentation/devicetree/bindings/dma/fsl-edma.txt | 44 +++---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt
b/Documentation/devicetree/bindings/dma/fsl-edma.txt
index 97e213e..29dd3cc 100644
--- a/Documentation/devicetree/bindings/dma/fsl-edma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
@@ -9,15 +9,16 @@ group, DMAMUX0 or DMAMUX1, but not both.
Required properties:
- compatible :
- "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
+ - "fsl,imx7ulp-edma" for eDMA2 used similar to that on i.mx7ulp
- reg : Specifies base physical address(s) and size of the eDMA registers.
The 1st region is eDMA control register's address and size.
The 2nd and the 3rd regions are programmable channel multiplexing
control register's address and size.
- interrupts : A list of interrupt-specifiers, one for each entry in
- interrupt-names.
-- interrupt-names : Should contain:
- "edma-tx" - the transmission interrupt
- "edma-err" - the error interrupt
+ interrupt-names on vf610 similar SoC. But for i.mx7ulp per channel
+ per transmission interrupt, total 16 channel interrupt and 1
+ error interrupt(located in the last), no interrupt-names list on
+ i.mx7ulp for clean on dts.
- #dma-cells : Must be <2>.
The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
Specific request source can only be multiplexed by specific channels
@@ -28,6 +29,7 @@ Required properties:
- clock-names : A list of channel group clock names. Should contain:
"dmamux0" - clock name of mux0 group
"dmamux1" - clock name of mux1 group
+ Note: No dmamux0 on i.mx7ulp, but another 'dma' clk added on i.mx7ulp.
- clocks : A list of phandle and clock-specifier pairs, one for each entry in
clock-names.
@@ -35,6 +37,10 @@ Optional properties:
- big-endian: If present registers and hardware scatter/gather descriptors
of the eDMA are implemented in big endian mode, otherwise in little
mode.
+- interrupt-names : Should contain the below on vf610 similar SoC but not used
+ on i.mx7ulp similar SoC:
+ "edma-tx" - the transmission interrupt
+ "edma-err" - the error interrupt
Examples:
@@ -52,8 +58,36 @@ edma0: dma-controller@40018000 {
clock-names = "dmamux0", "dmamux1";
clocks = <&clks VF610_CLK_DMAMUX0>,
<&clks VF610_CLK_DMAMUX1>;
-};
+}; /* vf610 */
+edma1: dma-controller@4008 {
+ #dma-cells = <2>;
+ compatible = "fsl,imx7ulp-edma";
+ reg = <0x4008 0x2000>,
+ <0x4021 0x1000>;
+ dma-channels = <32>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+/* last is eDMA2-ERR interrupt */
+;
+ clock-names = "dma", "dmamux0";
+ clocks = <&pcc2 IMX7ULP_CLK_DMA1>,
+<&pcc2 IMX7ULP_CLK_DMA_MUX1>;
+}; /* i.mx7ulp */
* DMA clients
DMA client drivers that uses the DMA function must use the format described
--
2.7.4
[PATCH v2 3/7] dmaengine: fsl-edma-common: move dmamux register to another single function
From: Robin Gong
Prepare for edmav2 on i.mx7ulp whose dmamux register is 32bit. No function
impacted.
Signed-off-by: Robin Gong
---
drivers/dma/fsl-edma-common.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index c9a17fc..bb24251 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -77,6 +77,19 @@ void fsl_edma_disable_request(struct fsl_edma_chan *fsl_chan)
}
EXPORT_SYMBOL_GPL(fsl_edma_disable_request);
+static void mux_configure8(struct fsl_edma_chan *fsl_chan, void __iomem *addr,
+ u32 off, u32 slot, bool enable)
+{
+ u8 val8;
+
+ if (enable)
+ val8 = EDMAMUX_CHCFG_ENBL | slot;
+ else
+ val8 = EDMAMUX_CHCFG_DIS;
+
+ iowrite8(val8, addr + off);
+}
+
void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
unsigned int slot, bool enable)
{
@@ -89,10 +102,7 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
slot = EDMAMUX_CHCFG_SOURCE(slot);
- if (enable)
- iowrite8(EDMAMUX_CHCFG_ENBL | slot, muxaddr + ch_off);
- else
- iowrite8(EDMAMUX_CHCFG_DIS, muxaddr + ch_off);
+ mux_configure8(fsl_chan, muxaddr, ch_off, slot, enable);
}
EXPORT_SYMBOL_GPL(fsl_edma_chan_mux);
--
2.7.4
[PATCH v2 2/7] dmaengine: mcf-edma: update to 'dmamux_nr'
From: Robin Gong
Update to 'dmamux_nr' instead of static macro DMAMUX_NR since
new version edma only has one dmamux.
Signed-off-by: Robin Gong
---
drivers/dma/fsl-edma-common.c | 2 +-
drivers/dma/mcf-edma.c| 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index 680b2a0..c9a17fc 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -84,7 +84,7 @@ void fsl_edma_chan_mux(struct fsl_edma_chan *fsl_chan,
void __iomem *muxaddr;
unsigned int chans_per_mux, ch_off;
- chans_per_mux = fsl_chan->edma->n_chans / DMAMUX_NR;
+ chans_per_mux = fsl_chan->edma->n_chans / fsl_chan->edma->dmamux_nr;
ch_off = fsl_chan->vchan.chan.chan_id % chans_per_mux;
muxaddr = fsl_chan->edma->muxbase[ch / chans_per_mux];
slot = EDMAMUX_CHCFG_SOURCE(slot);
diff --git a/drivers/dma/mcf-edma.c b/drivers/dma/mcf-edma.c
index 7de54b2f..4484190 100644
--- a/drivers/dma/mcf-edma.c
+++ b/drivers/dma/mcf-edma.c
@@ -189,6 +189,7 @@ static int mcf_edma_probe(struct platform_device *pdev)
/* Set up version for ColdFire edma */
mcf_edma->version = v2;
+ mcf_edma->dmamux_nr = DMAMUX_NR;
mcf_edma->big_endian = 1;
if (!mcf_edma->n_chans) {
--
2.7.4
[PATCH v2 1/7] dmaengine: fsl-edma: add dmamux_nr for next version
From: Robin Gong
Next version of edma such as edmav2 on i.mx7ulp has only one dmamux.
Add dmamux_nr instead of static macro define 'DMAMUX_NR'. No any
function change here.
Signed-off-by: Robin Gong
---
drivers/dma/fsl-edma-common.h | 1 +
drivers/dma/fsl-edma.c| 11 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.h b/drivers/dma/fsl-edma-common.h
index c53f76e..21a9cfd 100644
--- a/drivers/dma/fsl-edma-common.h
+++ b/drivers/dma/fsl-edma-common.h
@@ -145,6 +145,7 @@ struct fsl_edma_engine {
void __iomem*membase;
void __iomem*muxbase[DMAMUX_NR];
struct clk *muxclk[DMAMUX_NR];
+ u32 dmamux_nr;
struct mutexfsl_edma_mutex;
u32 n_chans;
int txirq;
diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c
index d641ef8..7b65ef4 100644
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -96,7 +96,7 @@ static struct dma_chan *fsl_edma_xlate(struct of_phandle_args
*dma_spec,
struct fsl_edma_engine *fsl_edma = ofdma->of_dma_data;
struct dma_chan *chan, *_chan;
struct fsl_edma_chan *fsl_chan;
- unsigned long chans_per_mux = fsl_edma->n_chans / DMAMUX_NR;
+ unsigned long chans_per_mux = fsl_edma->n_chans / fsl_edma->dmamux_nr;
if (dma_spec->args_count != 2)
return NULL;
@@ -206,6 +206,7 @@ static int fsl_edma_probe(struct platform_device *pdev)
return -ENOMEM;
fsl_edma->version = v1;
+ fsl_edma->dmamux_nr = DMAMUX_NR;
fsl_edma->n_chans = chans;
mutex_init(&fsl_edma->fsl_edma_mutex);
@@ -217,7 +218,7 @@ static int fsl_edma_probe(struct platform_device *pdev)
fsl_edma_setup_regs(fsl_edma);
regs = &fsl_edma->regs;
- for (i = 0; i < DMAMUX_NR; i++) {
+ for (i = 0; i < fsl_edma->dmamux_nr; i++) {
char clkname[32];
res = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
@@ -295,7 +296,7 @@ static int fsl_edma_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev,
"Can't register Freescale eDMA engine. (%d)\n", ret);
- fsl_disable_clocks(fsl_edma, DMAMUX_NR);
+ fsl_disable_clocks(fsl_edma, fsl_edma->dmamux_nr);
return ret;
}
@@ -304,7 +305,7 @@ static int fsl_edma_probe(struct platform_device *pdev)
dev_err(&pdev->dev,
"Can't register Freescale eDMA of_dma. (%d)\n", ret);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma, DMAMUX_NR);
+ fsl_disable_clocks(fsl_edma, fsl_edma->dmamux_nr);
return ret;
}
@@ -323,7 +324,7 @@ static int fsl_edma_remove(struct platform_device *pdev)
fsl_edma_cleanup_vchan(&fsl_edma->dma_dev);
of_dma_controller_free(np);
dma_async_device_unregister(&fsl_edma->dma_dev);
- fsl_disable_clocks(fsl_edma, DMAMUX_NR);
+ fsl_disable_clocks(fsl_edma, fsl_edma->dmamux_nr);
return 0;
}
--
2.7.4
[PATCH v2 4/7] dmaengine: fsl-edma-common: version check for v2 instead
From: Robin Gong
The next v3 i.mx7ulp edma is based on v1, so change version
check logic for v2 instead.
Signed-off-by: Robin Gong
---
drivers/dma/fsl-edma-common.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index bb24251..45d70d3 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -657,26 +657,26 @@ void fsl_edma_setup_regs(struct fsl_edma_engine *edma)
edma->regs.erql = edma->membase + EDMA_ERQ;
edma->regs.eeil = edma->membase + EDMA_EEI;
- edma->regs.serq = edma->membase + ((edma->version == v1) ?
- EDMA_SERQ : EDMA64_SERQ);
- edma->regs.cerq = edma->membase + ((edma->version == v1) ?
- EDMA_CERQ : EDMA64_CERQ);
- edma->regs.seei = edma->membase + ((edma->version == v1) ?
- EDMA_SEEI : EDMA64_SEEI);
- edma->regs.ceei = edma->membase + ((edma->version == v1) ?
- EDMA_CEEI : EDMA64_CEEI);
- edma->regs.cint = edma->membase + ((edma->version == v1) ?
- EDMA_CINT : EDMA64_CINT);
- edma->regs.cerr = edma->membase + ((edma->version == v1) ?
- EDMA_CERR : EDMA64_CERR);
- edma->regs.ssrt = edma->membase + ((edma->version == v1) ?
- EDMA_SSRT : EDMA64_SSRT);
- edma->regs.cdne = edma->membase + ((edma->version == v1) ?
- EDMA_CDNE : EDMA64_CDNE);
- edma->regs.intl = edma->membase + ((edma->version == v1) ?
- EDMA_INTR : EDMA64_INTL);
- edma->regs.errl = edma->membase + ((edma->version == v1) ?
- EDMA_ERR : EDMA64_ERRL);
+ edma->regs.serq = edma->membase + ((edma->version == v2) ?
+ EDMA64_SERQ : EDMA_SERQ);
+ edma->regs.cerq = edma->membase + ((edma->version == v2) ?
+ EDMA64_CERQ : EDMA_CERQ);
+ edma->regs.seei = edma->membase + ((edma->version == v2) ?
+ EDMA64_SEEI : EDMA_SEEI);
+ edma->regs.ceei = edma->membase + ((edma->version == v2) ?
+ EDMA64_CEEI : EDMA_CEEI);
+ edma->regs.cint = edma->membase + ((edma->version == v2) ?
+ EDMA64_CINT : EDMA_CINT);
+ edma->regs.cerr = edma->membase + ((edma->version == v2) ?
+ EDMA64_CERR : EDMA_CERR);
+ edma->regs.ssrt = edma->membase + ((edma->version == v2) ?
+ EDMA64_SSRT : EDMA_SSRT);
+ edma->regs.cdne = edma->membase + ((edma->version == v2) ?
+ EDMA64_CDNE : EDMA_CDNE);
+ edma->regs.intl = edma->membase + ((edma->version == v2) ?
+ EDMA64_INTL : EDMA_INTR);
+ edma->regs.errl = edma->membase + ((edma->version == v2) ?
+ EDMA64_ERRL : EDMA_ERR);
if (edma->version == v2) {
edma->regs.erqh = edma->membase + EDMA64_ERQH;
--
2.7.4
[PATCH v2 7/7] ARM: dts: imx7ulp: add edma device node
From: Robin Gong
Add edma device node in dts.
Signed-off-by: Robin Gong
---
arch/arm/boot/dts/imx7ulp.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index d6b7110..b4f7adf 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -100,6 +100,34 @@
reg = <0x4000 0x80>;
ranges;
+ edma1: dma-controller@4008 {
+ #dma-cells = <2>;
+ compatible = "fsl,imx7ulp-edma";
+ reg = <0x4008 0x2000>,
+ <0x4021 0x1000>;
+ dma-channels = <32>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ clock-names = "dma", "dmamux0";
+ clocks = <&pcc2 IMX7ULP_CLK_DMA1>,
+<&pcc2 IMX7ULP_CLK_DMA_MUX1>;
+ };
+
lpuart4: serial@402d {
compatible = "fsl,imx7ulp-lpuart";
reg = <0x402d 0x1000>;
--
2.7.4
[PATCH v2] rcu: Don't return a value from rcu_assign_pointer()
Quoting Paul [1]:
"Given that a quick (and perhaps error-prone) search of the uses
of rcu_assign_pointer() in v5.1 didn't find a single use of the
return value, let's please instead change the documentation and
implementation to eliminate the return value."
[1] https://lkml.kernel.org/r/20190523135013.gl28...@linux.ibm.com
Signed-off-by: Andrea Parri
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
Cc: r...@vger.kernel.org
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Mark Rutland
Cc: Matthew Wilcox
Cc: Sasha Levin
---
Changes in v2:
- Fix documentation and style (Paul E. McKenney)
- Improve subject line (Mark Rutland)
---
Documentation/RCU/whatisRCU.txt | 8
include/linux/rcupdate.h | 5 ++---
tools/include/linux/rcu.h | 4 ++--
tools/testing/radix-tree/linux/rcupdate.h | 2 +-
4 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 981651a8b65d2..7e1a8721637ab 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -212,7 +212,7 @@ synchronize_rcu()
rcu_assign_pointer()
- typeof(p) rcu_assign_pointer(p, typeof(p) v);
+ void rcu_assign_pointer(p, typeof(p) v);
Yes, rcu_assign_pointer() -is- implemented as a macro, though it
would be cool to be able to declare a function in this manner.
@@ -220,9 +220,9 @@ rcu_assign_pointer()
The updater uses this function to assign a new value to an
RCU-protected pointer, in order to safely communicate the change
- in value from the updater to the reader. This function returns
- the new value, and also executes any memory-barrier instructions
- required for a given CPU architecture.
+ in value from the updater to the reader. This macro does not
+ evaluate to an rvalue, but it does execute any memory-barrier
+ instructions required for a given CPU architecture.
Perhaps just as important, it serves to document (1) which
pointers are protected by RCU and (2) the point at which a
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index a8ed624da5556..0c9b92799abc7 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -367,7 +367,7 @@ static inline void rcu_preempt_sleep_check(void) { }
* other macros that it invokes.
*/
#define rcu_assign_pointer(p, v) \
-({ \
+do { \
uintptr_t _r_a_p__v = (uintptr_t)(v); \
rcu_check_sparse(p, __rcu); \
\
@@ -375,8 +375,7 @@ static inline void rcu_preempt_sleep_check(void) { }
WRITE_ONCE((p), (typeof(p))(_r_a_p__v)); \
else \
smp_store_release(&p, RCU_INITIALIZER((typeof(p))_r_a_p__v)); \
- _r_a_p__v;\
-})
+} while (0)
/**
* rcu_swap_protected() - swap an RCU and a regular pointer
diff --git a/tools/include/linux/rcu.h b/tools/include/linux/rcu.h
index 7d02527e5bcea..9554d3fa54f33 100644
--- a/tools/include/linux/rcu.h
+++ b/tools/include/linux/rcu.h
@@ -19,7 +19,7 @@ static inline bool rcu_is_watching(void)
return false;
}
-#define rcu_assign_pointer(p, v) ((p) = (v))
-#define RCU_INIT_POINTER(p, v) p=(v)
+#define rcu_assign_pointer(p, v) do { (p) = (v); } while (0)
+#define RCU_INIT_POINTER(p, v) do { (p) = (v); } while (0)
#endif
diff --git a/tools/testing/radix-tree/linux/rcupdate.h
b/tools/testing/radix-tree/linux/rcupdate.h
index fd280b070fdb1..fed468fb0c78d 100644
--- a/tools/testing/radix-tree/linux/rcupdate.h
+++ b/tools/testing/radix-tree/linux/rcupdate.h
@@ -7,6 +7,6 @@
#define rcu_dereference_raw(p) rcu_dereference(p)
#define rcu_dereference_protected(p, cond) rcu_dereference(p)
#define rcu_dereference_check(p, cond) rcu_dereference(p)
-#define RCU_INIT_POINTER(p, v) (p) = (v)
+#define RCU_INIT_POINTER(p, v) do { (p) = (v); } while (0)
#endif
--
2.7.4
Thinkpad X60 fails to boot while "hot"
Hi! So if you compile a kernel, then reboot, boot will hang after "Freeing SMP alternatives memory" (and then wastes power, making thermal situation even worse). Unfortunately, threshold for non-booting system is quite low, fan does _not_ go full speed after reboot. Annoying for kernel development :-(. Force power off, wait for a while, power on, and it works again. The bug is there for a long long time... probably 4.0 is affected, probably even older. Any ideas? Has someone seen something similar? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Wow! Microsoft Loves Linux!
Good afternoon from Singapore, I did a Google search on "Microsoft Loves Linux". Google search URL: https://www.google.com/search?q=microsoft+loves+linux Tons of results show up. Lots of good reads. -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
[PATCH v11 0/6] Add basic node support for Mediatek MT8183 SoC
MT8183 is a SoC based on 64bit ARMv8 architecture. It contains 4 CA53 and 4 CA73 cores. MT8183 share many HW IP with MT65xx series. This patchset was tested on MT8183 evaluation board and use correct clock to shell. Based on v5.2-rc1 Change in v11: New add spi node, efuse node, pinctrl node, auxadc node, and capacity-dmips-mhz field Change in v10: Add the L2 cache node to prevent warning on unable to detect cache hierarchy. Change in v9: Remove pio node since binding is not documented yet Change in v8: 1. Fix interrupt-parent of pio node 2. Remove pinfunc.h and spi node patches Change in v7: 1. Place all the MMIO peripherals under one or more simple-bus nodes 2. Make the pinfunc.h and spi node into seperate patch 3. Modify SPIs pamerater from 4 back to 3 and remove patch "support 4 interrupt parameters for sysirq" 4. Rename intpol-controller to interrupt-controller 5. Rename pinctrl@1000b000 to pinctrl@10005000 Change in v6: 1. Remove power and iommu nodes 2. Fix dtb build warning 3. Fix pinctrl binding doc 4. Fix '_' in node names Change in v5: 1. Collect all device tree nodes to the last patch 2. Add PMU 3. Add Signed-off-by 4. Remove clock driver code and binding doc 5. Add pinctrl, iommu, spi, and pwrap nodes Change in v4: 1. Correct syntax error in dtsi 2. Add MT8183 clock support Change in v3: 1. Fill out GICC, GICH, GICV regions 2. Update Copyright to 2018 Change in v2: 1. Split dt-bindings into different patches 2. Correct bindings for supported SoCs (mtk-uart.txt) Ben Ho (1): arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile Erin Lo (1): arm64: dts: mt8183: add spi node Hsin-Yi, Wang (1): arm64: dts: mt8183: add capacity-dmips-mhz Michael Mei (1): arm64: dts: mt8183: add efuse and Mediatek Chip id node to read Zhiyong Tao (2): arm64: dts: mt8183: add pinctrl device node arm64: dts: mt8183: Add auxadc device node arch/arm64/boot/dts/mediatek/Makefile | 1 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 140 ++ arch/arm64/boot/dts/mediatek/mt8183.dtsi| 447 3 files changed, 588 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi -- 1.8.1.1.dirty
[PATCH v11 4/6] arm64: dts: mt8183: Add auxadc device node
From: Zhiyong Tao
Add auxadc device node for MT8183
Signed-off-by: Zhiyong Tao
Signed-off-by: Erin Lo
---
This patch is based on patch "https://patchwork.kernel.org/patch/10913941/";.
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 4
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 10 ++
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 9b52559..49909ac 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -26,6 +26,10 @@
};
};
+&auxadc {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index e74ea21..5672c18 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -245,6 +245,16 @@
clock-names = "spi", "wrap";
};
+ auxadc: auxadc@11001000 {
+ compatible = "mediatek,mt8183-auxadc",
+"mediatek,mt8173-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
1.8.1.1.dirty
[PATCH v11 2/6] arm64: dts: mt8183: add capacity-dmips-mhz
From: "Hsin-Yi, Wang"
Pinned the frequency to the max and run dhrystone to get the value.
little cpu: 11071 (max freq: 1989000)
big cpu: 15293 (max freq: 1989000)
11071 : 15293 ~= 741 : 1024
Signed-off-by: Erin Lo
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bf..5b34ec6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -56,6 +56,7 @@
compatible = "arm,cortex-a53";
reg = <0x000>;
enable-method = "psci";
+ capacity-dmips-mhz = <741>;
};
cpu1: cpu@1 {
@@ -63,6 +64,7 @@
compatible = "arm,cortex-a53";
reg = <0x001>;
enable-method = "psci";
+ capacity-dmips-mhz = <741>;
};
cpu2: cpu@2 {
@@ -70,6 +72,7 @@
compatible = "arm,cortex-a53";
reg = <0x002>;
enable-method = "psci";
+ capacity-dmips-mhz = <741>;
};
cpu3: cpu@3 {
@@ -77,6 +80,7 @@
compatible = "arm,cortex-a53";
reg = <0x003>;
enable-method = "psci";
+ capacity-dmips-mhz = <741>;
};
cpu4: cpu@100 {
@@ -84,6 +88,7 @@
compatible = "arm,cortex-a73";
reg = <0x100>;
enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
};
cpu5: cpu@101 {
@@ -91,6 +96,7 @@
compatible = "arm,cortex-a73";
reg = <0x101>;
enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
};
cpu6: cpu@102 {
@@ -98,6 +104,7 @@
compatible = "arm,cortex-a73";
reg = <0x102>;
enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
};
cpu7: cpu@103 {
@@ -105,6 +112,7 @@
compatible = "arm,cortex-a73";
reg = <0x103>;
enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
};
};
--
1.8.1.1.dirty
[PATCH v11 5/6] arm64: dts: mt8183: add spi node
Add spi DTS node to the mt8183 and mt8183-evb.
Signed-off-by: Mengqi Zhang
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 105
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 78 +
2 files changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 49909ac..d8e555c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -30,6 +30,111 @@
status = "okay";
};
+&pio {
+ spi_pins_0: spi0{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_1: spi1{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_2: spi2{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_3: spi3{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_4: spi4{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+
+ spi_pins_5: spi5{
+ pins_spi{
+ pinmux = ,
+,
+,
+;
+ bias-disable;
+ };
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_0>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_1>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_2>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_3>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_4>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+};
+
+&spi5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_5>;
+ mediatek,pad-select = <0>;
+ status = "okay";
+
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5672c18..2e3063f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -285,6 +285,84 @@
status = "disabled";
};
+ spi0: spi@1100a000 {
+ compatible = "mediatek,mt8183-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1100a000 0 0x1000>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL_D5_D2>,
+<&topckgen CLK_TOP_MUX_SPI>,
+<&infracfg CLK_INFRA_SPI0>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi1: spi@1101 {
+ compatible = "mediatek,mt8183-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1101 0 0x1000>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL_D5_D2>,
+<&topckgen CLK_TOP_MUX_SPI>,
+<&infracfg CLK_INFRA_SPI1>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi2: spi@11012000 {
+ compatible = "mediatek,mt8183-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11012000 0 0x1000>;
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SYSPLL_D5_D2>,
+<&topckgen CLK_
Re: [PATCH v2 6/7] dmaengine: fsl-edma: add i.mx7ulp edma2 version support
On Mon, May 27, 2019 at 04:51:17PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong
>
> +static const struct of_device_id fsl_edma_dt_ids[] = {
> + { .compatible = "fsl,vf610-edma", .data = (void *)v1 },
> + { .compatible = "fsl,imx7ulp-edma", .data = (void *)v3 },
> + { /* sentinel */ }
Please put a struct type behind the .data pointer so that you can
configure...
> +};
> +MODULE_DEVICE_TABLE(of, fsl_edma_dt_ids);
> +
> @@ -218,6 +272,22 @@ static int fsl_edma_probe(struct platform_device *pdev)
> fsl_edma_setup_regs(fsl_edma);
> regs = &fsl_edma->regs;
>
> + if (fsl_edma->version == v3) {
> + fsl_edma->dmamux_nr = 1;
...things like this...
> @@ -264,7 +334,11 @@ static int fsl_edma_probe(struct platform_device *pdev)
> }
>
> edma_writel(fsl_edma, ~0, regs->intl);
> - ret = fsl_edma_irq_init(pdev, fsl_edma);
> +
> + if (fsl_edma->version == v3)
> + ret = fsl_edma2_irq_init(pdev, fsl_edma);
> + else
> + ret = fsl_edma_irq_init(pdev, fsl_edma);
...and this one in that struct rather than littering the code more and
more with such version tests.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v11 3/6] arm64: dts: mt8183: add pinctrl device node
From: Zhiyong Tao
The commit adds pinctrl device node for mt8183
Signed-off-by: Zhiyong Tao
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b34ec6..e74ea21 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include "mt8183-pinfunc.h"
/ {
compatible = "mediatek,mt8183";
@@ -204,6 +205,30 @@
#clock-cells = <1>;
};
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8183-pinctrl";
+ reg = <0 0x10005000 0 0x1000>,
+ <0 0x11f2 0 0x1000>,
+ <0 0x11e8 0 0x1000>,
+ <0 0x11e7 0 0x1000>,
+ <0 0x11e9 0 0x1000>,
+ <0 0x11d3 0 0x1000>,
+ <0 0x11d2 0 0x1000>,
+ <0 0x11c5 0 0x1000>,
+ <0 0x11f3 0 0x1000>,
+ <0 0x1000b000 0 0x1000>;
+ reg-names = "iocfg0", "iocfg1", "iocfg2",
+ "iocfg3", "iocfg4", "iocfg5",
+ "iocfg6", "iocfg7", "iocfg8",
+ "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 192>;
+ interrupt-controller;
+ interrupts = ;
+ #interrupt-cells = <2>;
+ };
+
apmixedsys: syscon@1000c000 {
compatible = "mediatek,mt8183-apmixedsys", "syscon";
reg = <0 0x1000c000 0 0x1000>;
--
1.8.1.1.dirty
[PATCH v11 6/6] arm64: dts: mt8183: add efuse and Mediatek Chip id node to read
From: Michael Mei
support for reading chip ID and efuse
Signed-off-by: Michael Mei
Signed-off-by: Erin Lo
---
This patch is based on this patch:
https://patchwork.kernel.org/patch/10953029/
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 2e3063f..c2749c4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -156,6 +156,15 @@
compatible = "simple-bus";
ranges;
+ soc_data: soc_data@800 {
+ compatible = "mediatek,mt8183-efuse",
+"mediatek,efuse";
+ reg = <0 0x0800 0 0x0010>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@c00 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
@@ -369,6 +378,12 @@
#clock-cells = <1>;
};
+ efuse: efuse@11f1 {
+ compatible = "mediatek,mt8183-efuse",
+"mediatek,efuse";
+ reg = <0 0x11f1 0 0x1000>;
+ };
+
mfgcfg: syscon@1300 {
compatible = "mediatek,mt8183-mfgcfg", "syscon";
reg = <0 0x1300 0 0x1000>;
--
1.8.1.1.dirty
[PATCH v11 1/6] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Ben Ho
Add basic chip support for Mediatek 8183, include
uart node with correct uart clocks, pwrap device
Add clock controller nodes, include topckgen, infracfg,
apmixedsys and subsystem.
Signed-off-by: Ben Ho
Signed-off-by: Erin Lo
Signed-off-by: Seiya Wang
Signed-off-by: Weiyi Lu
Signed-off-by: Hsin-Hsiung Wang
Signed-off-by: Eddie Huang
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 +++
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 311
3 files changed, 343 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index e8f952f..458bbc4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..9b52559
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 000..08274bf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8183";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x100>;
+
Re: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd
On 2019.05.27 16:43:11 +0800, Tina Zhang wrote:
> Add VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set eventfd
> based signaling mechanism to deliver vGPU framebuffer page flip
> event to userspace.
>
Should we add probe to see if driver can support gfx flip event?
> Signed-off-by: Tina Zhang
> ---
> include/uapi/linux/vfio.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 02bb7ad6e986..27300597717f 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -696,6 +696,18 @@ struct vfio_device_ioeventfd {
>
> #define VFIO_DEVICE_IOEVENTFD_IO(VFIO_TYPE, VFIO_BASE + 16)
>
> +/**
> + * VFIO_DEVICE_SET_GFX_FLIP_EVENTFD - _IOW(VFIO_TYPE, VFIO_BASE + 17, __s32)
> + *
> + * Set eventfd based signaling mechanism to deliver vGPU framebuffer page
> + * flip event to userspace. A value of -1 is used to stop the page flip
> + * delivering.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +#define VFIO_DEVICE_SET_GFX_FLIP_EVENTFD _IO(VFIO_TYPE, VFIO_BASE + 17)
> +
> /* API for Type1 VFIO IOMMU */
>
> /**
> --
> 2.17.1
>
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
Re: [PATCH v2 4/7] dmaengine: fsl-edma-common: version check for v2 instead
On Mon, May 27, 2019 at 04:51:15PM +0800, yibin.g...@nxp.com wrote: > From: Robin Gong > > The next v3 i.mx7ulp edma is based on v1, so change version > check logic for v2 instead. > > Signed-off-by: Robin Gong > --- > drivers/dma/fsl-edma-common.c | 40 > 1 file changed, 20 insertions(+), 20 deletions(-) > > diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c > index bb24251..45d70d3 100644 > --- a/drivers/dma/fsl-edma-common.c > +++ b/drivers/dma/fsl-edma-common.c > @@ -657,26 +657,26 @@ void fsl_edma_setup_regs(struct fsl_edma_engine *edma) > edma->regs.erql = edma->membase + EDMA_ERQ; > edma->regs.eeil = edma->membase + EDMA_EEI; > > - edma->regs.serq = edma->membase + ((edma->version == v1) ? > - EDMA_SERQ : EDMA64_SERQ); > - edma->regs.cerq = edma->membase + ((edma->version == v1) ? > - EDMA_CERQ : EDMA64_CERQ); > - edma->regs.seei = edma->membase + ((edma->version == v1) ? > - EDMA_SEEI : EDMA64_SEEI); > - edma->regs.ceei = edma->membase + ((edma->version == v1) ? > - EDMA_CEEI : EDMA64_CEEI); > - edma->regs.cint = edma->membase + ((edma->version == v1) ? > - EDMA_CINT : EDMA64_CINT); > - edma->regs.cerr = edma->membase + ((edma->version == v1) ? > - EDMA_CERR : EDMA64_CERR); > - edma->regs.ssrt = edma->membase + ((edma->version == v1) ? > - EDMA_SSRT : EDMA64_SSRT); > - edma->regs.cdne = edma->membase + ((edma->version == v1) ? > - EDMA_CDNE : EDMA64_CDNE); > - edma->regs.intl = edma->membase + ((edma->version == v1) ? > - EDMA_INTR : EDMA64_INTL); > - edma->regs.errl = edma->membase + ((edma->version == v1) ? > - EDMA_ERR : EDMA64_ERRL); > + edma->regs.serq = edma->membase + ((edma->version == v2) ? > + EDMA64_SERQ : EDMA_SERQ); > + edma->regs.cerq = edma->membase + ((edma->version == v2) ? > + EDMA64_CERQ : EDMA_CERQ); > + edma->regs.seei = edma->membase + ((edma->version == v2) ? > + EDMA64_SEEI : EDMA_SEEI); > + edma->regs.ceei = edma->membase + ((edma->version == v2) ? > + EDMA64_CEEI : EDMA_CEEI); > + edma->regs.cint = edma->membase + ((edma->version == v2) ? > + EDMA64_CINT : EDMA_CINT); > + edma->regs.cerr = edma->membase + ((edma->version == v2) ? > + EDMA64_CERR : EDMA_CERR); > + edma->regs.ssrt = edma->membase + ((edma->version == v2) ? > + EDMA64_SSRT : EDMA_SSRT); > + edma->regs.cdne = edma->membase + ((edma->version == v2) ? > + EDMA64_CDNE : EDMA_CDNE); > + edma->regs.intl = edma->membase + ((edma->version == v2) ? > + EDMA64_INTL : EDMA_INTR); > + edma->regs.errl = edma->membase + ((edma->version == v2) ? > + EDMA64_ERRL : EDMA_ERR); Following to what I have said to 6/7 you can put the register offsets into that new struct aswell. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework
On Fri, May 24, 2019 at 20:42:43, Alan Mikhak wrote: Hi Alan, > On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel > wrote: > > > > Hi Alan, > > > > This patch implementation is very HW implementation dependent and > > requires the DMA to exposed through PCIe BARs, which aren't always the > > case. Besides, you are defining some control bits on > > include/linux/pci-epc.h that may not have any meaning to other types of > > DMA. > > > > I don't think this was what Kishon had in mind when he developed the > > pcitest, but let see what Kishon was to say about it. > > > > I've developed a DMA driver for DWC PCI using Linux Kernel DMAengine API > > and which I submitted some days ago. > > By having a DMA driver which implemented using DMAengine API, means the > > pcitest can use the DMAengine client API, which will be completely > > generic to any other DMA implementation. > > > > My DMA driver for DWC PCI was done thinking on my use case, which is was > > interacting from the Root Complex side with DMA IP implemented on the > > Endpoint, which was exposed through PCI BARs. However, I think it would > > be possible to reuse the same core code and instead of using the PCI-glue > > to adapt it and be used easily on the Endpoint side and to be triggered > > there. > > > > Gustavo > > Hi Gustavo, > > I saw your patches for the DMA driver for DWC PCI which added the EDDA > driver to pci_endpoint_test.c on the host side. This suggested to me > that the user would invoke pcitest on the host side to exercise your > driver on the endpoint. > > However, I didn't see any changes to pci-epf-test.c to modify the > pci_epf_test_write() and pci_epf_test_read() functions to use DMA > instead of memcpy_toio() and memcpy_fromio(), respectively. I didn't add the DMA engine client API to the pcitest yet. I was waiting for the eDMA driver to be integrated on Kernel before doing any on pcitest. > > I have four separate DMA requirements in mind as motivation for this patch. > > The following two requirements are implemented by this patch: > Local DMA write or read transfer initiated by endpoint under user > command from the host between system and endpoint memory buffers using > the endpoint DMA controller with a local interrupt. > 1) single block > 2) linked-list mode However, in most cases, you will not have the DMA block registers or linked list memory accessible or defined on PCI BARs and based on I have seen in your patch, the whole patch is based on that premise. The current implementation is not generic and highly dependent on IP and design. I strongly believe with some slight modifications it would be possible to run the DMA engine controller driver with a platform glue-logic on the Endpoint side, which could interact with pci_epf_test driver. This way the pcitest would be always generic to all products. > > This patch anticipates two more requirements yet to be implemented in > future patches: > Remote DMA write or read transfer initiated by host between system and > endpoint memory buffers using the endpoint DMA controller with a local > interrupt to the endpoint processor and a remote interrupt to the host > process. > 1) single block > 2) linked-list mode That's what the submitted patch driver does. I didn't develop the interaction with to pcitest, however, while developing DW eDMA IP driver, I've sent in some an RFC patch containing dw-edma-test driver that stimulates the DW eDMA. > > The descriptor format defined in pci-epc.h allows for pci-epf-test.c > to be expanded over time to initiate more elaborate DMA tests to > exercise other endpoint DMA scenarios. Yes, but that's not the original issue been discussed here. But let's see what Kishon as to say, In the end, he is the maintainer of this tool. Regards, Gustavo > > The following is a sample output of the pcitest usage for exercising > DMA operations on the endpoint: > > $ pcitest -r -d > READ ( 102400 bytes): OKAY > $ pcitest -w -d > WRITE ( 102400 bytes): OKAY > $ pcitest -w -d -L > WRITE ( 102400 bytes): OKAY > $ pcitest -r -d -L > READ ( 102400 bytes): OKAY > > The above are executed using DMA operations as opposed to the > following which use memcpy_toio() and memcpy_fromio(). > > $ pcitest -r > READ ( 102400 bytes): OKAY > $ pcitest -w > WRITE ( 102400 bytes): OKAY > > Regards, > Alan Mikhak > > > > > > > -Original Message- > > From: Alan Mikhak > > > > Sent: 23 de maio de 2019 23:24 > > To: linux-...@vger.kernel.org; > > linux-kernel@vger.kernel.org; kis...@ti.com; lorenzo.pieral...@arm.com; > > a...@arndb.de; gre...@linuxfoundation.org; jingooh...@gmail.com; > > gustavo.pimen...@synopsys.com; bhelg...@google.com; > > wen.yan...@zte.com.cn; k...@umn.edu; linux-ri...@lists.infradead.org; > > pal...@sifive.com; paul.walms...@sifive.com > > Cc: Alan Mikhak > > > > Subject: [PATCH] PCI: endpoint: Add DMA to Linux > > PCI EP Framework > > > > This patch depends on patch the following patches: > > [PATCH v2 1/2] tools
Re: [PATCH] dt-bindings: pinctrl: fix spelling mistakes in pinctl documentation
On Sat, May 25, 2019 at 10:42 PM Colin King wrote: > From: Colin Ian King > > The spelling of configured is incorrect in the documentation. Fix it. > > Signed-off-by: Colin Ian King Patch applied with Bjorn's review tag. Yours, Linus Walleij
Re: [PATCH 2/2] drm/i915/gvt: Support delivering page flip event to userspace
On 2019.05.27 16:43:12 +0800, Tina Zhang wrote:
> Use the eventfd based signaling mechanism provided by vfio/display
> to deliver vGPU framebuffer page flip event to userspace.
>
> Signed-off-by: Tina Zhang
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 31 +
> drivers/gpu/drm/i915/gvt/dmabuf.h | 1 +
> drivers/gpu/drm/i915/gvt/gvt.c | 1 +
> drivers/gpu/drm/i915/gvt/gvt.h | 2 ++
> drivers/gpu/drm/i915/gvt/handlers.c | 2 ++
> drivers/gpu/drm/i915/gvt/kvmgt.c| 7 +++
> 6 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 4e1e425189ba..f2ed45616d72 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -538,6 +538,35 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
> unsigned int dmabuf_id)
> return ret;
> }
>
> +static void release_flip_eventfd_ctx(struct intel_vgpu *vgpu)
> +{
> + struct eventfd_ctx **trigger = &vgpu->page_flip_trigger;
> +
> + if (*trigger) {
> + eventfd_ctx_put(*trigger);
> + *trigger = NULL;
> + }
Why so twisted?
if (vgpu->page_flip_trigger) {
eventfd_ctx_put(vgpu->page_flip_trigger);
vgpu->page_flip_trigger = NULL;
}
> +}
> +
> +int intel_vgpu_set_flip_eventfd(struct intel_vgpu *vgpu, int fd)
> +{
> + struct eventfd_ctx *trigger;
> +
> + if (fd == -1) {
> + release_flip_eventfd_ctx(vgpu);
> + } else if (fd >= 0) {
> + trigger = eventfd_ctx_fdget(fd);
> + if (IS_ERR(trigger)) {
> + gvt_vgpu_err("eventfd_ctx_fdget failed\n");
> + return PTR_ERR(trigger);
> + }
> + vgpu->page_flip_trigger = trigger;
> + } else
> + return -EINVAL;
Better put (fd < 0) check earlier in ioctl handler to simplify this.
> +
> + return 0;
> +}
> +
> void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
> {
> struct list_head *pos, *n;
> @@ -561,4 +590,6 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
>
> }
> mutex_unlock(&vgpu->dmabuf_lock);
> +
> + release_flip_eventfd_ctx(vgpu);
> }
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
> b/drivers/gpu/drm/i915/gvt/dmabuf.h
> index 5f8f03fb1d1b..4d9caa3732d2 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.h
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
> @@ -62,6 +62,7 @@ struct intel_vgpu_dmabuf_obj {
>
> int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args);
> int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned int dmabuf_id);
> +int intel_vgpu_set_flip_eventfd(struct intel_vgpu *vgpu, int fd);
> void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 43f4242062dd..7fd4afa432ef 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -184,6 +184,7 @@ static const struct intel_gvt_ops intel_gvt_ops = {
> .get_gvt_attrs = intel_get_gvt_attrs,
> .vgpu_query_plane = intel_vgpu_query_plane,
> .vgpu_get_dmabuf = intel_vgpu_get_dmabuf,
> + .vgpu_set_flip_eventfd = intel_vgpu_set_flip_eventfd,
> .write_protect_handler = intel_vgpu_page_track_handler,
> .emulate_hotplug = intel_vgpu_emulate_hotplug,
> };
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index f5a328b5290a..86ca223f9a60 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -229,6 +229,7 @@ struct intel_vgpu {
> struct completion vblank_done;
>
> u32 scan_nonprivbb;
> + struct eventfd_ctx *page_flip_trigger;
> };
>
> /* validating GM healthy status*/
> @@ -570,6 +571,7 @@ struct intel_gvt_ops {
> struct attribute_group ***intel_vgpu_type_groups);
> int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
> int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
> + int (*vgpu_set_flip_eventfd)(struct intel_vgpu *vgpu, int fd);
> int (*write_protect_handler)(struct intel_vgpu *, u64, void *,
>unsigned int);
> void (*emulate_hotplug)(struct intel_vgpu *vgpu, bool connected);
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 18f01eeb2510..1b5455888bdf 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -763,6 +763,8 @@ static int pri_surf_mmio_write(struct intel_vgpu *vgpu,
> unsigned int offset,
> else
> set_bit(event, vgpu->irq.flip_done_event[pipe]);
>
> + eventfd_signal(vgpu->page_flip_trigger, 1);
Need to check if page_flip_trigger is armed or not.
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index
Re: [PATCH v2 04/11] ARM: dts: ste: Update coresight DT bindings
On Wed, May 8, 2019 at 4:20 AM Leo Yan wrote: > CoreSight DT bindings have been updated, thus the old compatible strings > are obsolete and the drivers will report warning if DTS uses these > obsolete strings. > > This patch switches to the new bindings for CoreSight dynamic funnel and > static replicator, so can dismiss warning during initialisation. > > Cc: Linus Walleij > Cc: Lee Jones > Cc: Mathieu Poirier > Cc: Suzuki K Poulose > Signed-off-by: Leo Yan Patch applied to the Ux500 tree. Yours, Linus Walleij
Придобивки за персонала
Здравейте, Запознати ли сте с най-новата социална придобивка – ваучери за храна? А обмисляли ли сте използването на такива ваучери, с помощта на които Вашият персонал може да пазарува в различни вериги хранителни магазини и заведения? Бих могъл да Ви се обадя по телефона и да Ви представя възможностите на тези ваучери – моля посочете кога ще Ви бъде удобно да разговаряме. Приятен ден! Радослав Добрев Head of HR Benefit Team www.lunch4employee.eu
Samsung Win..Final Notification
**DO NOT DELETE THIS MESSAGE Samsung Europe Prize Office Evert van de Beekstraat 310 1118 CX Schiphol-Holland www.samsung.com/europe OFFICIAL WIN NOTIFICATION. Email Prize Ticket Number: GLX/9627835/EU/PRIZE2ND. Dear Email User: Are you the owner of this email? Congratulations! Samsung Europe wishes to congratulate you for being one of the lucky winners in the Samsung Prize Ballot. Your email have been officially selected as a winner and you are hereby awarded with your email in the 2nd category winning prize of Seven Hundred and Fifty Thousand Euros and a Samsung Galaxy S10+. With the introduction of new types of games, with the ushering in of online technology and with the permit issued under EU laws to compete for concession to run games and give away prizes on the internet, we are launching our 1st international promotion. All contestants were selected through a computer ballot system drawn from email addresses from all over the world and your email address have been selected as one of the lucky winners. Contact Notaris: Igo Jansen. Notarization Officer/Agent Tel: 0031 61 654 5088 Email: samsung.notarizat...@europe.com For claims and notarisation you must be above 18yrs to fill the below form and send to notaris contact: *** First Name: Last Name: Occupation: Address: Country: Telephone: Win Email: EPTN: GLX/9627835/EU/PRIZE2ND Claim expiry date is 29th May 2019, after this date all winning prizes will be filed as unclaimed. Keep this email confidential & away from public notice to prevent double claim or impersonation with your EPTN. Best Regards, Cristian Bensila (Prize Co-ordinator) Samsung Europe. © 2019 Samsung Europe. All rights reserved .(Privacy Statement)
Re: [RFC PATCH 3/6] smp: Run functions concurrently in smp_call_function_many()
> + /* > + * Choose the most efficient way to send an IPI. Note that the > + * number of CPUs might be zero due to concurrent changes to the > + * provided mask or cpu_online_mask. > + */ Since we have preemption disabled here, I don't think online mask can shrink, cpu-offline uses stop_machine(). > + if (nr_cpus == 1) > + arch_send_call_function_single_ipi(last_cpu); > + else if (likely(nr_cpus > 1)) > + arch_send_call_function_ipi_mask(cfd->cpumask_ipi); > + }
Re: [RFC PATCH 4/6] x86/mm/tlb: Refactor common code into flush_tlb_on_cpus()
On Sat, May 25, 2019 at 01:22:01AM -0700, Nadav Amit wrote:
> There is one functional change, which should not affect correctness:
> flush_tlb_mm_range compared loaded_mm and the mm to figure out if local
> flush is needed. Instead, the common code would look at the mm_cpumask()
> which should give the same result.
> @@ -786,18 +804,9 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned
> long start,
> info = get_flush_tlb_info(mm, start, end, stride_shift, freed_tables,
> new_tlb_gen);
>
> - if (mm == this_cpu_read(cpu_tlbstate.loaded_mm)) {
> - lockdep_assert_irqs_enabled();
> - local_irq_disable();
> - flush_tlb_func_local(info, TLB_LOCAL_MM_SHOOTDOWN);
> - local_irq_enable();
> - }
> -
> - if (cpumask_any_but(mm_cpumask(mm), cpu) < nr_cpu_ids)
> - flush_tlb_others(mm_cpumask(mm), info);
So if we want to double check that; we'd add:
WARN_ON_ONCE(cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm)) ==
(mm == this_cpu_read(cpu_tlbstate.loaded_mm)));
right?
> + flush_tlb_on_cpus(mm_cpumask(mm), info);
>
> put_flush_tlb_info();
> - put_cpu();
> }
Re: linux-next: manual merge of the vhost tree with the iommu tree
On Sun, May 12, 2019 at 01:16:26PM -0400, Michael S. Tsirkin wrote: > Joerg, what are we doing with these patches? > It was tested in next with no bad effects. > I sent an ack - do you want to pick it up? > Or have me include it in my pull? I'd prefer it in my tree, if you are fine with the spec. Regards, Joerg
Re: [PATCH v4 3/3] mtd: spinand: Add support for GigaDevice GD5F1GQ4UFxxG
Hi Schrempf, Schrempf Frieder wrote on Mon, 27 May 2019 06:35:59 +: > Hi Jeff, > > On 24.05.19 02:12, Jeff Kletsky wrote: > > (reduced direct addressees, though still on lists) > > > > On 5/22/19 11:42 PM, Schrempf Frieder wrote: > > > >> On 23.05.19 00:05, Jeff Kletsky wrote: > >>> From: Jeff Kletsky > >>> > >>> The GigaDevice GD5F1GQ4UFxxG SPI NAND is in current production devices > >>> and, while it has the same logical layout as the E-series devices, > >>> it differs in the SPI interfacing in significant ways. > >>> > >>> This support is contingent on previous commits to: > >>> > >>> * Add support for two-byte device IDs > >>> * Define macros for page-read ops with three-byte addresses > >>> > >>> http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/ > >>> > >>> Signed-off-by: Jeff Kletsky > >> Reviewed-by: Frieder Schrempf > >> > >>> Reported-by: kbuild test robot > >> I dont't think that this Reported-by tag should be used here. The bot > >> reported build errors caused by your patch and you fixed it in a new > >> version. As far as I understand this tag, it references someone who > >> reported a flaw/bug that led to this change in the first place. > >> The version history of the changes won't be visible in the git history > >> later, but the tag will be and would be rather confusing. > > > > Thank you for your patience and explanations. I've been being conservative > > as I'm not a "seasoned, Linux professional" and am still getting my > > git send-email config / command line for Linux properly straightened out. > > Being conservative in such cases is not a fault at all. I'm not an > expert either. I'm just recommending what I think might be the "correct" > way to do it. > > > Should I send another patch set with the `kbuild...` tag removed, > > or would it be removed in the process of an appropriate member > > of the Linux MTD team adding their tag for approval, if and when > > that happens? > > I don't think that's necessary. Miquèl is the one to pick up the patch, > so he could probably drop the "Reported-by: kbuild" when he applies it. I will drop it. Also, please do not add an empty line between tags, they should be a single block. I will also modify your commits for this time. Thanks, Miquèl
Re: [5.2-rc1 regression]: nvme vs. hibernation
On Sat, 25 May 2019, Dongli Zhang wrote: > Looks this has been discussed in the past. > > http://lists.infradead.org/pipermail/linux-nvme/2019-April/023234.html > > I created a fix for a case but not good enough. > > http://lists.infradead.org/pipermail/linux-nvme/2019-April/023277.html That removes the warning, but I still seem to have ~1:1 chance of reboot (triple fault?) immediately after hibernation image is read from disk. Seems like that has been going all the way down to 4.19, which seems to be rock stable. It's a bit hard to bisect, as I am not really 100% sure whether this is one issue or two intermixed ones, and it doesn't reproduce completely reliably. -- Jiri Kosina SUSE Labs
Re: Issue with Broadcom wireless in 5.2rc1 (was Re: [PATCH] mmc: sdhci: queue work after sdhci_defer_done())
On Sun, May 26, 2019 at 03:58:19PM -0400, Brian Masney wrote:
> I attached a patch that shows how I was able to determine what had
> already claimed the host.
I realized this morning that I had a flaw with my test patch that
diagnosed what was deadlocked. The mmc_ctx structure was allocated on
the stack. I attached a second version of that patch that uses
kmalloc() for that structure. It didn't change what I reported
yesterday: brcmf_sdiod_ramrw is deadlocked by
brcmf_sdio_download_firmware.
On Mon, May 27, 2019 at 10:48:24AM +0300, Adrian Hunter wrote:
> This is because SDHCI is using the IRQ thread to process the SDIO card
> interrupt (sdio_run_irqs()). When the card driver tries to use the card, it
> causes interrupts which deadlocks since c07a48c26519 ("mmc: sdhci: Remove
> finish_tasklet") has moved the tasklet processing to the IRQ thread.
>
> I would expect to be able to use the IRQ thread to complete requests, and it
> is desirable to do so because it is lower latency.
>
> Probably, SDHCI should use sdio_signal_irq() which queues a work item, and
> is what other drivers are doing.
>
> I will investigate some more and send a patch.
Thank you!
Brian
>From acc78b5e581d2c3ebc994a6ad6e7b367f2b81935 Mon Sep 17 00:00:00 2001
From: Brian Masney
Date: Sun, 26 May 2019 15:36:40 -0400
Subject: [PATCH] troubleshoot broadcom wireless lockup in 5.2rc1 (v2)
Signed-off-by: Brian Masney
---
drivers/mmc/core/core.c | 15 ++
.../broadcom/brcm80211/brcmfmac/bcmsdh.c | 46 ++---
.../broadcom/brcm80211/brcmfmac/sdio.c| 160 ++
.../broadcom/brcm80211/brcmfmac/sdio.h| 3 +
include/linux/mmc/host.h | 1 +
5 files changed, 136 insertions(+), 89 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6db36dc870b5..768acabf029b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -814,7 +814,22 @@ int __mmc_claim_host(struct mmc_host *host, struct mmc_ctx *ctx,
if (stop || !host->claimed || mmc_ctx_matches(host, ctx, task))
break;
spin_unlock_irqrestore(&host->lock, flags);
+
+ if (ctx != NULL && ctx->descr != NULL) {
+ WARN_ON(1);
+ dev_info(&host->class_dev, "%s: FIXME - before schedule() - descr=%s, claimer=%s\n",
+ __func__, ctx->descr,
+ host->claimer != NULL ? host->claimer->descr : NULL);
+ }
+
schedule();
+
+ if (ctx != NULL && ctx->descr != NULL) {
+ dev_info(&host->class_dev, "%s: FIXME - after schedule() - descr=%s, claimer=%s\n",
+ __func__, ctx->descr,
+ host->claimer != NULL ? host->claimer->descr : NULL);
+ }
+
spin_lock_irqsave(&host->lock, flags);
}
set_current_state(TASK_RUNNING);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 60aede5abb4d..fdeaeb1353af 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -47,6 +47,8 @@
#include "sdio.h"
#include "core.h"
#include "common.h"
+#include "../../../../../mmc/core/host.h"
+#include "../../../../../mmc/core/core.h"
#define SDIOH_API_ACCESS_RETRY_LIMIT 2
@@ -132,7 +134,7 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev *sdiodev)
}
sdiodev->irq_wake = true;
- sdio_claim_host(sdiodev->func1);
+ brcmf_sdio_claim_host(sdiodev->func1, __func__);
if (sdiodev->bus_if->chip == BRCM_CC_43362_CHIP_ID) {
/* assign GPIO to SDIO core */
@@ -159,13 +161,13 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev *sdiodev)
data |= SDIO_CCCR_BRCM_SEPINT_ACT_HI;
brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_BRCM_SEPINT,
data, &ret);
- sdio_release_host(sdiodev->func1);
+ brcmf_sdio_release_host(sdiodev->func1);
} else {
brcmf_dbg(SDIO, "Entering\n");
- sdio_claim_host(sdiodev->func1);
+ brcmf_sdio_claim_host(sdiodev->func1, __func__);
sdio_claim_irq(sdiodev->func1, brcmf_sdiod_ib_irqhandler);
sdio_claim_irq(sdiodev->func2, brcmf_sdiod_dummy_irqhandler);
- sdio_release_host(sdiodev->func1);
+ brcmf_sdio_release_host(sdiodev->func1);
sdiodev->sd_irq_requested = true;
}
@@ -183,10 +185,10 @@ void brcmf_sdiod_intr_unregister(struct brcmf_sdio_dev *sdiodev)
struct brcmfmac_sdio_pd *pdata;
pdata = &sdiodev->settings->bus.sdio;
- sdio_claim_host(sdiodev->func1);
+ brcmf_sdio_claim_host(sdiodev->func1, __func__);
brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_BRCM_SEPINT, 0, NULL);
brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_IENx, 0, NULL);
- sdio_release_host(sdiodev->func1);
+ brcmf_sdio_release_host(sdiodev->func1);
sdiodev->oob_irq_requested = false;
if (sdiodev->irq_wake) {
@@ -199,10 +201,10 @@ void brcmf_sdiod_intr_unregister(struct brcmf_sdio_dev *sdiodev)
}
if (sdiodev->sd_irq_requested) {
- sdio_claim_host(sdiodev->func1);
+ brcmf_sdio_claim_host(sdiodev->func1, __func__);
sdio_release_irq(sdiodev->func2);
sdio_release_irq(sdiod
