Re: [PATCH v3 00/11] fix swiotlb-xen for RPi4
On 11.07.20 00:34, Stefano Stabellini wrote: Hi all, This series is a collection of fixes to get Linux running on the RPi4 as dom0. Conceptually there are only two significant changes: - make sure not to call virt_to_page on vmalloc virt addresses (patch #1) - use phys_to_dma and dma_to_phys to translate phys to/from dma addresses (all other patches) I addressed all comments by Christoph to v2 of the series except from the one about merging the precursor "add struct device *" patches. I can always merge them together at any time as needed. Boris gave his Reviewed-by to the whole series v2. I added his Reviewed-by to all patches, including the ones with small cosmetic fixes, except for patch #8 #9 #10 because they are either new or changed significantly in this version of the series. I retained Roman and Corey's Tested-by. Series pushed to: xen/tip.git for-linus-5.9 Juergen
Re: [PATCH] platform/x86:dell-laptop:Add battery charging thresholds and charging mode switch.
On Tue, Aug 04, 2020 at 05:46:30AM +, Yuan, Perry wrote: > It is not patch issue, the kernel config needs to add "CONFIG_ACPI_BATTERY=y" In that case you probably want to add a dependency to ACPI_BATTERY in the DELL_LAPTOP Kconfig. -- Matthew Garrett | mj...@srcf.ucam.org
Re: KASAN: use-after-free Read in hci_send_acl
syzbot has bisected this issue to:
commit 4ffcd582301bd020b1f9d00c55473af305ec19b5
Author: Michael Chan
Date: Mon Sep 19 07:58:07 2016 +
bnxt_en: Pad TX packets below 52 bytes.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=167b0f0490
start commit: ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=157b0f0490
console output: https://syzkaller.appspot.com/x/log.txt?x=117b0f0490
kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2
dashboard link: https://syzkaller.appspot.com/bug?extid=98228e7407314d2d4ba2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=152f190490
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1482dfca90
Reported-by: syzbot+98228e7407314d2d4...@syzkaller.appspotmail.com
Fixes: 4ffcd582301b ("bnxt_en: Pad TX packets below 52 bytes.")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH v2] platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver
The performance modules in BlueField are present in several hardware blocks and each block provides access to these stats either through counters that can be programmed to monitor supported events or through memory-mapped registers that hold the relevant information. The hardware blocks that include a performance module are: * Tile (block containing 2 cores and a shared L2 cache) * TRIO (PCIe root complex) * MSS (Memory Sub-system containing the Memory Controller and L3 cache) * GIC (Interrupt controller) * SMMU (System Memory Management Unit) The mlx_pmc driver provides access to all of these performance modules through a hwmon sysfs interface. v1 --> v2 Remove unused headers. Add comma to arrays where last line is not a termination. Use kstrtoint in place of sscanf. UUID manipulation follows drivers/platform/mellanox/mlxbf-bootctl.c Signed-off-by: Shravan Kumar Ramani Reviewed-by: Vadim Pasternak Reviewed-by: Jiri Pirko --- drivers/platform/mellanox/Kconfig | 10 + drivers/platform/mellanox/Makefile|1 + drivers/platform/mellanox/mlxbf-pmc.c | 1478 + 3 files changed, 1489 insertions(+) create mode 100644 drivers/platform/mellanox/mlxbf-pmc.c diff --git a/drivers/platform/mellanox/Kconfig b/drivers/platform/mellanox/Kconfig index 916b39d..edd17e1 100644 --- a/drivers/platform/mellanox/Kconfig +++ b/drivers/platform/mellanox/Kconfig @@ -56,4 +56,14 @@ config MLXBF_BOOTCTL to the userspace tools, to be used in conjunction with the eMMC device driver to do necessary initial swap of the boot partition. +config MLXBF_PMC + tristate "Mellanox BlueField Performance Monitoring Counters driver" + depends on ARM64 + depends on HWMON + depends on ACPI + help + Say y here to enable PMC support. The PMC driver provides access + to performance monitoring counters within various blocks in the + Mellanox BlueField SoC via a sysfs interface. + endif # MELLANOX_PLATFORM diff --git a/drivers/platform/mellanox/Makefile b/drivers/platform/mellanox/Makefile index 499623c..000ddaa 100644 --- a/drivers/platform/mellanox/Makefile +++ b/drivers/platform/mellanox/Makefile @@ -4,6 +4,7 @@ # Mellanox Platform-Specific Drivers # obj-$(CONFIG_MLXBF_BOOTCTL)+= mlxbf-bootctl.o +obj-$(CONFIG_MLXBF_PMC)+= mlxbf-pmc.o obj-$(CONFIG_MLXBF_TMFIFO) += mlxbf-tmfifo.o obj-$(CONFIG_MLXREG_HOTPLUG) += mlxreg-hotplug.o obj-$(CONFIG_MLXREG_IO) += mlxreg-io.o diff --git a/drivers/platform/mellanox/mlxbf-pmc.c b/drivers/platform/mellanox/mlxbf-pmc.c new file mode 100644 index 000..24e558c --- /dev/null +++ b/drivers/platform/mellanox/mlxbf-pmc.c @@ -0,0 +1,1478 @@ +// SPDX-License-Identifier: GPL-2.0-only OR Linux-OpenIB +/* + * Mellanox BlueField Performance Monitoring Counters driver + * + * This driver provides a sysfs interface for monitoring + * performance statistics in BlueField SoC. + * + * Copyright (C) 2020 Mellanox Technologies Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define MLXBF_PMC_WRITE_REG_32 0x8209 +#define MLXBF_PMC_READ_REG_32 0x820A +#define MLXBF_PMC_WRITE_REG_64 0x820B +#define MLXBF_PMC_READ_REG_64 0x820C +#define MLXBF_PMC_SIP_SVC_UID 0x8200ff01 +#define MLXBF_PMC_SIP_SVC_VERSION 0x8200ff03 +#define MLXBF_PMC_SVC_REQ_MAJOR 0 +#define MLXBF_PMC_SVC_MIN_MINOR 3 + +#define MLXBF_PMC_SMCCC_ACCESS_VIOLATION -4 + +#define MLXBF_PMC_EVENT_SET_BF1 0 +#define MLXBF_PMC_EVENT_SET_BF2 1 +#define MLXBF_PMC_EVENT_INFO_LEN 100 + +#define MLXBF_PMC_MAX_BLOCKS 30 +#define MLXBF_PMC_MAX_ATTRS 30 +#define MLXBF_PMC_INFO_SZ 4 +#define MLXBF_PMC_REG_SIZE 8 +#define MLXBF_PMC_L3C_REG_SIZE 4 + +#define MLXBF_PMC_TYPE_COUNTER 1 +#define MLXBF_PMC_TYPE_REGISTER 0 + +#define MLXBF_PMC_PERFCTL 0 +#define MLXBF_PMC_PERFEVT 1 +#define MLXBF_PMC_PERFACC0 4 + +#define MLXBF_PMC_PERFMON_CONFIG_WR_R_B BIT(0) +#define MLXBF_PMC_PERFMON_CONFIG_STROBE BIT(1) +#define MLXBF_PMC_PERFMON_CONFIG_ADDR GENMASK_ULL(4, 2) +#define MLXBF_PMC_PERFMON_CONFIG_WDATA GENMASK_ULL(60, 5) + +#define MLXBF_PMC_PERFCTL_FM0 GENMASK_ULL(18, 16) +#define MLXBF_PMC_PERFCTL_MS0 GENMASK_ULL(21, 20) +#define MLXBF_PMC_PERFCTL_ACCM0 GENMASK_ULL(26, 24) +#define MLXBF_PMC_PERFCTL_AD0 BIT(27) +#define MLXBF_PMC_PERFCTL_ETRIG0 GENMASK_ULL(29, 28) +#define MLXBF_PMC_PERFCTL_EB0 BIT(30) +#define MLXBF_PMC_PERFCTL_EN0 BIT(31) + +#define MLXBF_PMC_PERFEVT_EVTSEL GENMASK_ULL(31, 24) + +#define MLXBF_PMC_L3C_PERF_CNT_CFG 0x0 +#define MLXBF_PMC_L3C_PERF_CNT_SEL 0x10 +#define MLXBF_PMC_L3C_PERF_CNT_SEL_1 0x14 +#define MLXBF_PMC_L3C_PERF_CNT_LOW 0x40 +#define MLXBF_PMC_L3C_PERF_CNT_HIGH 0x60 + +#define MLXBF_PMC_L3C_PERF_CNT_CFG_EN BIT(0) +#define MLXBF_PMC_L3C_PERF_CNT_CFG_RST BIT(1) +#define MLXBF_PMC_L3C_PERF_CNT_SEL_CNT_0 GENMASK(5, 0) +#define MLXBF_PMC_L3C_PERF_CNT_SEL_CNT_1 GENMASK(13, 8) +#define MLXBF_PMC_L3C_PERF_CNT_SEL_CNT_2 GENMASK(21,
drivers/mailbox/pcc.c:575:3-8: No need to set .owner here. The core will do it.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 09a0bd07764359650d41dbcb723f81321e523217 commit: 00d9990acb23c4319a1dc961d4e29a9213923b67 mailbox: pcc: make pcc_mbox_driver static date: 9 weeks ago config: x86_64-randconfig-c002-20200803 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot coccinelle warnings: (new ones prefixed by >>) >> drivers/mailbox/pcc.c:575:3-8: No need to set .owner here. The core will do >> it. Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH net-next] ip_vti: Fix unused variable warning
On Mon, Aug 03, 2020 at 03:13:49PM -0700, David Miller wrote: > From: YueHaibing > Date: Fri, 31 Jul 2020 14:49:52 +0800 > > > If CONFIG_INET_XFRM_TUNNEL is set but CONFIG_IPV6 is n, > > > > net/ipv4/ip_vti.c:493:27: warning: 'vti_ipip6_handler' defined but not used > > [-Wunused-variable] > > > > Signed-off-by: YueHaibing > > Steffen, please pick this up if you haven't already. I still have this one in my queue, it came in after I did the the ipsec-next pull request last week. Now the 5.8 release was inbetween, so it should go to the ipsec tree. I'm waiting until I can backmerge the offending patch into the ipsec tree and apply it then. Alternatively to speed things up, you can take it directly into net-next before you do the pull request to Linus. In case you prefer that: Acked-by: Steffen Klassert
Re: linux-next: build failure after merge of the vhost tree
Hi Stephen,
On Tue, Aug 04, 2020 at 03:11:17PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vhost tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/rpmsg/virtio_rpmsg_bus.c:28:10: fatal error: linux/virtio_rpmsg.h: No
> such file or directory
>28 | #include
> | ^~
>
> Caused by commit
>
> bba6f4f52c31 ("rpmsg: move common structures and defines to headers")
>
> I have used the vhost tree from next-20200803 for today.
Yes, I've seen that, that's a clang build for MIPS... I'll have a look.
Thanks
Guennadi
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH v3] Provide USF for the portable equipment.
On 03-08-20, 22:31, Dongdong Yang wrote: > From: Dongdong Yang > > This patch provides USF(User Sensitive Feedback factor) auxiliary > cpufreq governor to support high level layer sysfs inodes setting > for utils adjustment purpose from the identified scenario on portable > equipment. Because the power consumption and UI response are more cared > for by portable equipment users. And the "screen off" status stands for > no request from the user, however, the kernel is still expected to > notify the user in time on modem, network or powerkey events occur. USF > provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from > user space tasks according to high level scenario. In addition, it > usually hints more cpufreq demand that the preemptive counts of the > tasks on the cpu burst and over the user expecting completed time such > as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on > "screen on" status, which more likely with more UI. The sysfs inodes > "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust > the utils according to high level identified scenario to alloc the > cpufreq in time. > > Changes in v3 > - Move usf.c to kernel/sched. > - Remove trace_printk and debugfs. > - Add document draft. > - Update comments. > > Changes in v2 > - Add adjust_task_pred_set switch. > - Move adjust_task_pred_demand declaration into sched.h > - Update comments. Sending updated patchset for this isn't going to help you my friend. You need people (maintainers) to agree on the idea here first. The patch can be beautified later if required once the idea is agreed upon. I saw Peter already gave his NAK to it during V1. You need to discuss with people here to see why they don't like it first and as Greg said earlier, this should not go to staging at all if it ever makes it mainline. The more versions you send now (without proper discussions first), the harder it will be for this stuff to get merged upstream. -- viresh
RE: [PATCH] platform/x86:dell-laptop:Add battery charging thresholds and charging mode switch.
> From: kernel test robot > Sent: Saturday, August 1, 2020 1:08 PM > To: Yuan, Perry; s...@kernel.org; mj...@srcf.ucam.org; p...@kernel.org; > dvh...@infradead.org; a...@infradead.org; Limonciello, Mario > Cc: kbuild-...@lists.01.org; linux...@vger.kernel.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; Yuan, Perry > Subject: Re: [PATCH] platform/x86:dell-laptop:Add battery charging thresholds > and charging mode switch. > > > [EXTERNAL EMAIL] > > Hi Perry, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on power-supply/for-next] [also build test ERROR on > linux/master linus/master v5.8-rc7 next-20200731] [If your patch is applied to > the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url:https://github.com/0day-ci/linux/commits/Perry-Yuan/platform-x86- > dell-laptop-Add-battery-charging-thresholds-and-charging-mode- > switch/20200729-150347 > base: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power- > supply.git for-next > config: i386-randconfig-a005-20200731 (attached as .config) > compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 > reproduce (this is a W=1 build): > # save the attached .config to linux build tree > make W=1 ARCH=i386 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>, old ones prefixed by <<): > > >> ERROR: modpost: "battery_hook_unregister" [drivers/platform/x86/dell- > laptop.ko] undefined! > >> ERROR: modpost: "battery_hook_register" [drivers/platform/x86/dell- > laptop.ko] undefined! > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org It is not patch issue, the kernel config needs to add "CONFIG_ACPI_BATTERY=y"
[PATCH] PCI: imx6: Do not output error message when devm_clk_get() failed with -EPROBE_DEFER
When devm_clk_get() returns -EPROBE_DEFER, i.MX6 PCI driver should
NOT print error message, just return -EPROBE_DEFER is enough.
Signed-off-by: Anson Huang
---
drivers/pci/controller/dwc/pci-imx6.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 4e5c379..ee75d35 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1076,20 +1076,26 @@ static int imx6_pcie_probe(struct platform_device *pdev)
/* Fetch clocks */
imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
if (IS_ERR(imx6_pcie->pcie_phy)) {
- dev_err(dev, "pcie_phy clock source missing or invalid\n");
- return PTR_ERR(imx6_pcie->pcie_phy);
+ ret = PTR_ERR(imx6_pcie->pcie_phy);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "pcie_phy clock source missing or
invalid\n");
+ return ret;
}
imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
if (IS_ERR(imx6_pcie->pcie_bus)) {
- dev_err(dev, "pcie_bus clock source missing or invalid\n");
- return PTR_ERR(imx6_pcie->pcie_bus);
+ ret = PTR_ERR(imx6_pcie->pcie_bus);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "pcie_bus clock source missing or
invalid\n");
+ return ret;
}
imx6_pcie->pcie = devm_clk_get(dev, "pcie");
if (IS_ERR(imx6_pcie->pcie)) {
- dev_err(dev, "pcie clock source missing or invalid\n");
- return PTR_ERR(imx6_pcie->pcie);
+ ret = PTR_ERR(imx6_pcie->pcie);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "pcie clock source missing or invalid\n");
+ return ret;
}
switch (imx6_pcie->drvdata->variant) {
@@ -1097,15 +1103,19 @@ static int imx6_pcie_probe(struct platform_device *pdev)
imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
"pcie_inbound_axi");
if (IS_ERR(imx6_pcie->pcie_inbound_axi)) {
- dev_err(dev, "pcie_inbound_axi clock missing or
invalid\n");
- return PTR_ERR(imx6_pcie->pcie_inbound_axi);
+ ret = PTR_ERR(imx6_pcie->pcie_inbound_axi);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "pcie_inbound_axi clock missing or
invalid\n");
+ return ret;
}
break;
case IMX8MQ:
imx6_pcie->pcie_aux = devm_clk_get(dev, "pcie_aux");
if (IS_ERR(imx6_pcie->pcie_aux)) {
- dev_err(dev, "pcie_aux clock source missing or
invalid\n");
- return PTR_ERR(imx6_pcie->pcie_aux);
+ ret = PTR_ERR(imx6_pcie->pcie_aux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "pcie_aux clock source missing or
invalid\n");
+ return ret;
}
/* fall through */
case IMX7D:
--
2.7.4
Re: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary
On Thu, Jul 30, 2020 at 06:01:20PM +0300, Kirill Tkhai wrote: > On 30.07.2020 17:34, Eric W. Biederman wrote: > > Kirill Tkhai writes: > > > >> Currently, there is no a way to list or iterate all or subset of namespaces > >> in the system. Some namespaces are exposed in /proc/[pid]/ns/ directories, > >> but some also may be as open files, which are not attached to a process. > >> When a namespace open fd is sent over unix socket and then closed, it is > >> impossible to know whether the namespace exists or not. > >> > >> Also, even if namespace is exposed as attached to a process or as open > >> file, > >> iteration over /proc/*/ns/* or /proc/*/fd/* namespaces is not fast, because > >> this multiplies at tasks and fds number. Could you describe with more details when you need to iterate namespaces? There are three ways to hold namespaces. * processes * bind-mounts * file descriptors When CRIU dumps a container, it enumirates all processes, collects file descriptors and mounts. This means that we will be able to collect all namespaces, doesn't it?
Re: [PATCH] iio:temperature:mlx90632: Reduce number of equal calulcations
Hi Crt,
I love your patch! Yet something to improve:
[auto build test ERROR on iio/togreg]
[also build test ERROR on v5.8 next-20200803]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Crt-Mori/iio-temperature-mlx90632-Reduce-number-of-equal-calulcations/20200803-231936
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-randconfig-a001-20200803 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
4ffa6a27aca17fe88fa6bdd605b198df6632a570)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/iio/temperature/mlx90632.c:381:40: error: redefinition of 'TAdut4'
s64 calcedKsTO, calcedKsTA, ir_Alpha, TAdut4, Alpha_corr;
^
drivers/iio/temperature/mlx90632.c:377:28: note: previous definition is here
s64 TAdut, s64 TAdut4, s32
Fa, s32 Fb,
^
>> drivers/iio/temperature/mlx90632.c:412:2: error: use of undeclared
>> identifier 'TAdut4'; did you mean 'TAdut'?
TAdut4 = (div64_s64(TAdut, 1LL) + 27315) *
^~
TAdut
drivers/iio/temperature/mlx90632.c:405:17: note: 'TAdut' declared here
s64 kTA, kTA0, TAdut;
^
drivers/iio/temperature/mlx90632.c:419:67: error: use of undeclared
identifier 'TAdut4'; did you mean 'TAdut'?
temp = mlx90632_calc_temp_object_iteration(temp, object,
TAdut, TAdut4,
^~
TAdut
drivers/iio/temperature/mlx90632.c:405:17: note: 'TAdut' declared here
s64 kTA, kTA0, TAdut;
^
3 errors generated.
vim +/TAdut4 +381 drivers/iio/temperature/mlx90632.c
c87742abfc80b3 Crt Mori 2018-01-11 375
c87742abfc80b3 Crt Mori 2018-01-11 376 static s32
mlx90632_calc_temp_object_iteration(s32 prev_object_temp, s64 object,
dd5b04efd05f22 Crt Mori 2020-08-03 377
s64 TAdut, s64 TAdut4, s32 Fa, s32 Fb,
c87742abfc80b3 Crt Mori 2018-01-11 378
s32 Ga, s16 Ha, s16 Hb,
c87742abfc80b3 Crt Mori 2018-01-11 379
u16 emissivity)
c87742abfc80b3 Crt Mori 2018-01-11 380 {
c87742abfc80b3 Crt Mori 2018-01-11 @381 s64 calcedKsTO, calcedKsTA,
ir_Alpha, TAdut4, Alpha_corr;
c87742abfc80b3 Crt Mori 2018-01-11 382 s64 Ha_customer, Hb_customer;
c87742abfc80b3 Crt Mori 2018-01-11 383
dd5b04efd05f22 Crt Mori 2020-08-03 384 Ha_customer = div64_s64((s64)Ha
* 100LL, 16384);
dd5b04efd05f22 Crt Mori 2020-08-03 385 Hb_customer = div64_s64((s64)Hb
* 100, 1024);
c87742abfc80b3 Crt Mori 2018-01-11 386
dd5b04efd05f22 Crt Mori 2020-08-03 387 calcedKsTO =
div64_s64((s64)((s64)Ga * (prev_object_temp - 25 * 1000LL)
dd5b04efd05f22 Crt Mori 2020-08-03 388 *
1000LL), 68719476736);
dd5b04efd05f22 Crt Mori 2020-08-03 389 calcedKsTA = div64_s64((s64)(Fb
* (TAdut - 25 * 100LL)), 68719476736);
dd5b04efd05f22 Crt Mori 2020-08-03 390 Alpha_corr =
div64_s64(div64_s64((s64)(Fa * 100LL), 70368744177664)
dd5b04efd05f22 Crt Mori 2020-08-03 391*
Ha_customer, 1000LL);
c87742abfc80b3 Crt Mori 2018-01-11 392 Alpha_corr *= ((s64)(1 *
100LL + calcedKsTO + calcedKsTA));
c87742abfc80b3 Crt Mori 2018-01-11 393 Alpha_corr = emissivity *
div64_s64(Alpha_corr, 10LL);
c87742abfc80b3 Crt Mori 2018-01-11 394 Alpha_corr =
div64_s64(Alpha_corr, 1000LL);
c87742abfc80b3 Crt Mori 2018-01-11 395 ir_Alpha =
div64_s64((s64)object * 1000LL, Alpha_corr);
c87742abfc80b3 Crt Mori 2018-01-11 396
c87742abfc80b3 Crt Mori 2018-01-11 397 return
(int_sqrt64(int_sqrt64(ir_Alpha * 1LL + TAdut4))
c87742abfc80b3 Crt Mori 2018-01-11 398 - 27315 - Hb_customer)
* 10;
c87742abfc80b3 Crt Mori 2018-01-11 399 }
c87742abfc80b3
[PATCH] mailbox: pcc: fix platform_no_drv_owner.cocci warnings
From: kernel test robot
drivers/mailbox/pcc.c:575:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 00d9990acb23 ("mailbox: pcc: make pcc_mbox_driver static")
CC: Jason Yan
Signed-off-by: kernel test robot
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 09a0bd07764359650d41dbcb723f81321e523217
commit: 00d9990acb23c4319a1dc961d4e29a9213923b67 mailbox: pcc: make
pcc_mbox_driver static
pcc.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -572,7 +572,6 @@ static struct platform_driver pcc_mbox_d
.probe = pcc_mbox_probe,
.driver = {
.name = "PCCT",
- .owner = THIS_MODULE,
},
};
Re: [PATCH v2] fbmem: pull fbcon_update_vcs() out of fb_set_var()
On Thu, Jul 30, 2020 at 07:47:14PM +0900, Tetsuo Handa wrote:
> syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy()
> based on outdated old_{rows,row_size} values, for resize_screen() can
> recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates
> old_{rows,row_size} values which were saved before calling resize_screen().
>
> Daniel Vetter explained that resize_screen() should not recurse into
> fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
> when calling resize_screen().
>
> Instead of masking FBINFO_MISC_USEREVENT before calling fbcon_update_vcs(),
> we can remove FBINFO_MISC_USEREVENT by calling fbcon_update_vcs() only if
> fb_set_var() returned 0. This change assumes that it is harmless to call
> fbcon_update_vcs() when fb_set_var() returned 0 without reaching
> fb_notifier_call_chain().
>
> [1]
> https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
>
> Reported-and-tested-by: syzbot
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Tetsuo Handa
> Reported-by: kernel test robot for missing #include
Thanks a lot for your patch, queued up to hopefully still make it for
5.9-rc1.
Cheers, Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++--
> drivers/video/fbdev/core/fbsysfs.c | 4 ++--
> drivers/video/fbdev/ps3fb.c| 5 +++--
> include/linux/fb.h | 2 --
> 4 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 30e73ec..da7c88f 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -957,7 +957,6 @@ static int fb_check_caps(struct fb_info *info, struct
> fb_var_screeninfo *var,
> int
> fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
> {
> - int flags = info->flags;
> int ret = 0;
> u32 activate;
> struct fb_var_screeninfo old_var;
> @@ -1052,9 +1051,6 @@ static int fb_check_caps(struct fb_info *info, struct
> fb_var_screeninfo *var,
> event.data =
> fb_notifier_call_chain(FB_EVENT_MODE_CHANGE, );
>
> - if (flags & FBINFO_MISC_USEREVENT)
> - fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
> -
> return 0;
> }
> EXPORT_SYMBOL(fb_set_var);
> @@ -1105,9 +1101,9 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> return -EFAULT;
> console_lock();
> lock_fb_info(info);
> - info->flags |= FBINFO_MISC_USEREVENT;
> ret = fb_set_var(info, );
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> + if (!ret)
> + fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
> unlock_fb_info(info);
> console_unlock();
> if (!ret && copy_to_user(argp, , sizeof(var)))
> diff --git a/drivers/video/fbdev/core/fbsysfs.c
> b/drivers/video/fbdev/core/fbsysfs.c
> index d54c88f..65dae05 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -91,9 +91,9 @@ static int activate(struct fb_info *fb_info, struct
> fb_var_screeninfo *var)
>
> var->activate |= FB_ACTIVATE_FORCE;
> console_lock();
> - fb_info->flags |= FBINFO_MISC_USEREVENT;
> err = fb_set_var(fb_info, var);
> - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
> + if (!err)
> + fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
> console_unlock();
> if (err)
> return err;
> diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
> index 9df78fb..203c254 100644
> --- a/drivers/video/fbdev/ps3fb.c
> +++ b/drivers/video/fbdev/ps3fb.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -824,12 +825,12 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> var = info->var;
> fb_videomode_to_var(, vmode);
> console_lock();
> - info->flags |= FBINFO_MISC_USEREVENT;
> /* Force, in case only special bits changed */
> var.activate |= FB_ACTIVATE_FORCE;
> par->new_mode_id = val;
> retval = fb_set_var(info, );
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> + if (!retval)
> + fbcon_update_vcs(info, var.activate &
> FB_ACTIVATE_ALL);
> console_unlock();
> }
> break;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 3b4b2f0..b11eb02 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -400,8 +400,6 @@ struct fb_tile_ops {
> #define FBINFO_HWACCEL_YPAN
Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers
On 30-07-20, 10:36, Lukasz Luba wrote: > On 7/30/20 10:10 AM, Sudeep Holla wrote: > > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: > > > On 29-07-20, 16:12, Lukasz Luba wrote: > > > > The existing CPUFreq framework does not tracks the statistics when the > > > > 'fast switch' is used or when firmware changes the frequency > > > > independently > > > > due to e.g. thermal reasons. However, the firmware might track the > > > > frequency > > > > changes and expose this to the kernel. > > > > > > > > This patch set aims to introduce CPUfreq statistics gathered by firmware > > > > and retrieved by CPUFreq driver. It would require a new API functions > > > > in the CPUFreq, which allows to poke drivers to get these stats. > > > > > > > > The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends > > > > ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq > > > > driver. > > > > > > Are you doing this for the fast switch case or because your platform > > > actually runs at frequencies which may be different from what cpufreq > > > core has requested ? > > > > > > > I think so. > > For both cases, but fast switch is major and present. Thermal is not > currently implemented in SCP FW, but might be in future. Okay, lets simplify things a bit and merge things slowly upstream and merge only what is required right now. IIUC, the only concern right now is to capture stats with fast switch ? Maybe we can do something else in that case and brainstorm a bit.. > > > I am also not sure what these tables should represent, what the > > > cpufreq core has decided for the CPUs or the frequencies we actually > > > run at, as these two can be very different for example if the hardware > > > runs at frequencies which don't match exactly to what is there in the > > > freq table. I believe these are rather to show what cpufreq and its > > > governors are doing with the CPUs. > > > > > > > Exactly, I raised similar point in internal discussion and asked Lukasz > > to take up the same on the list. I assume it was always what cpufreq > > requested rather than what was delivered. So will we break the userspace > > ABI if we change that is the main question. > > Thank you for confirmation. If that is the mechanism for tracking what > cpufreq governors are doing with the CPUs, then is clashes with > presented data in FW memory, because firmware is the governor. Why is firmware the governor here ? Aren't you talking about the simple fast switch case only ? Over that, I think this cpufreq stats information isn't parsed by any tool right now and tweaking it a bit won't hurt anyone (like if we start capturing things a bit differently). So we may not want to worry about breaking userspace ABI here, if what we are looking to do is the right thing to do. > > > Over that I would like the userspace stats to work exactly as the way > > > they work right now, i.e. capture all transitions from one freq to > > > other, not just time-in-state. Also resetting of the stats from > > > userspace for example. All allocation and printing of the data must be > > > done from stats core, the only thing which the driver would do at the > > > end is updating the stats structure and nothing more. Instead of > > > reading all stats from the firmware, it will be much easier if you can > > > just get the information from the firmware whenever there is a > > > frequency switch and then we can update the stats the way it is done > > > right now. And that would be simple. > > > > > > > Good point, but notifications may not be lightweight. If that is no good, > > alternatively, I suggested to keep these firmware stats in a separate > > debugfs. Thoughts ? > > I agree that notifications might not be lightweight. I am not sure what notifications are we talking about here. > Furthermore I think > this still clashes with the assumption that cpufreq governor decisions > are tracked in these statistics, not the firmware decision. > > In this case I think we would have to create debugfs. > Sudeep do you think these debugfs should be exposed from the protocol > layer: > drivers/firmware/arm_scmi/perf.c > or maybe from the cpufreq scmi driver? I would probably be safer to have > it in the cpufreq driver because we have scmi_handle there. For the CPUs it would be better if we can keep things in cpufreq only, lets see how we go about it. -- viresh
Re: [PATCH v3 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*
On 11.07.20 00:34, Stefano Stabellini wrote: From: Stefano Stabellini xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are getting called passing dma addresses. On some platforms dma addresses could be different from physical addresses. Before doing any operations on these addresses we need to convert them back to physical addresses using dma_to_phys. Move the arch_sync_dma_for_cpu and arch_sync_dma_for_device calls from xen_dma_sync_for_cpu/device to swiotlb-xen.c, and add a call dma_to_phys to do address translations there. dma_cache_maint is fixed by the next patch. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik Acked-by: Juergen Gross Juergen
Re: [PATCH v3 08/11] swiotlb-xen: remove XEN_PFN_PHYS
On 11.07.20 00:34, Stefano Stabellini wrote: From: Stefano Stabellini XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more complex than need to be. Remove the definition of XEN_PFN_PHYS and open code the cast in the one place where it is needed. Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross Juergen
Re: [PATCH V3 vhost next 00/10] VDPA support for Mellanox ConnectX devices
On Mon, Aug 03, 2020 at 04:51:27PM -0400, Michael S. Tsirkin wrote: > On Tue, Jul 28, 2020 at 09:05:29AM +0300, Eli Cohen wrote: > > Hi Michael, > > please note that this series depends on mlx5 core device driver patches > > in mlx5-next branch in > > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git. > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git > > mlx5-next > > > > They also depend Jason Wang's patches submitted a couple of weeks ago. > > > > vdpa_sim: use the batching API > > vhost-vdpa: support batch updating > > Hmm this makes merging them messy. I can ack merging them through > the mellanox tree, but > conflicts between Jason's patches and what's in my tree also exist. > Let me see if this is something I can fix. > How big is the dependency? Can I pick it up with your ack? > > Also, mips build failures need to be dealt with. > Will look into it. > > > > > > The following series of patches provide VDPA support for Mellanox > > devices. The supported devices are ConnectX6 DX and newer. > > > > Currently, only a network driver is implemented; future patches will > > introduce a block device driver. iperf performance on a single queue is > > around 12 Gbps. Future patches will introduce multi queue support. > > > > The files are organized in such a way that code that can be used by > > different VDPA implementations will be placed in a common are resides in > > drivers/vdpa/mlx5/core. > > > > Only virtual functions are currently supported. Also, certain firmware > > capabilities must be set to enable the driver. Physical functions (PFs) > > are skipped by the driver. > > > > To make use of the VDPA net driver, one must load mlx5_vdpa. In such > > case, VFs will be operated by the VDPA driver. Although one can see a > > regular instance of a network driver on the VF, the VDPA driver takes > > precedence over the NIC driver, steering-wize. > > > > Currently, the device/interface infrastructure in mlx5_core is used to > > probe drivers. Future patches will introduce virtbus as a means to > > register devices and drivers and VDPA will be adapted to it. > > > > The mlx5 mode of operation required to support VDPA is switchdev mode. > > Once can use Linux or OVS bridge to take care of layer 2 switching. > > > > In order to provide virtio networking to a guest, an updated version of > > qemu is required. This version has been tested by the following quemu > > version: > > > > url: https://github.com/jasowang/qemu.git > > branch: vdpa > > Commit ID: 6f4e59b807db > > > > > > V2->V3 > > Fix makefile to use include path relative to the root of the kernel > > > > Eli Cohen (7): > > net/vdpa: Use struct for set/get vq state > > vhost: Fix documentation > > vdpa: Modify get_vq_state() to return error code > > vdpa/mlx5: Add hardware descriptive header file > > vdpa/mlx5: Add support library for mlx5 VDPA implementation > > vdpa/mlx5: Add shared memory registration code > > vdpa/mlx5: Add VDPA driver for supported mlx5 devices > > > > Jason Wang (2): > > vhost-vdpa: support batch updating > > vdpa_sim: use the batching API > > > > Max Gurtovoy (1): > > vdpa: remove hard coded virtq num > > > > drivers/vdpa/Kconfig | 18 + > > drivers/vdpa/Makefile |1 + > > drivers/vdpa/ifcvf/ifcvf_base.c|4 +- > > drivers/vdpa/ifcvf/ifcvf_base.h|4 +- > > drivers/vdpa/ifcvf/ifcvf_main.c| 13 +- > > drivers/vdpa/mlx5/Makefile |4 + > > drivers/vdpa/mlx5/core/mlx5_vdpa.h | 91 ++ > > drivers/vdpa/mlx5/core/mlx5_vdpa_ifc.h | 168 ++ > > drivers/vdpa/mlx5/core/mr.c| 473 ++ > > drivers/vdpa/mlx5/core/resources.c | 284 > > drivers/vdpa/mlx5/net/main.c | 76 + > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 1950 > > drivers/vdpa/mlx5/net/mlx5_vnet.h | 24 + > > drivers/vdpa/vdpa.c|3 + > > drivers/vdpa/vdpa_sim/vdpa_sim.c | 35 +- > > drivers/vhost/iotlb.c |4 +- > > drivers/vhost/vdpa.c | 46 +- > > include/linux/vdpa.h | 24 +- > > include/uapi/linux/vhost_types.h |2 + > > 19 files changed, 3165 insertions(+), 59 deletions(-) > > create mode 100644 drivers/vdpa/mlx5/Makefile > > create mode 100644 drivers/vdpa/mlx5/core/mlx5_vdpa.h > > create mode 100644 drivers/vdpa/mlx5/core/mlx5_vdpa_ifc.h > > create mode 100644 drivers/vdpa/mlx5/core/mr.c > > create mode 100644 drivers/vdpa/mlx5/core/resources.c > > create mode 100644 drivers/vdpa/mlx5/net/main.c > > create mode 100644 drivers/vdpa/mlx5/net/mlx5_vnet.c > > create mode 100644 drivers/vdpa/mlx5/net/mlx5_vnet.h > > > > -- > > 2.26.0 >
Re: [PATCH v3 09/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations
On 11.07.20 00:34, Stefano Stabellini wrote: From: Stefano Stabellini With some devices physical addresses are different than dma addresses. To be able to deal with these cases, we need to call phys_to_dma on physical addresses (including machine addresses in Xen terminology) before returning them from xen_swiotlb_alloc_coherent and xen_swiotlb_map_page. We also need to convert dma addresses back to physical addresses using dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if we want to do any operations on them. Call dma_to_phys in is_xen_swiotlb_buffer. Introduce xen_phys_to_dma and call phys_to_dma in its implementation. Introduce xen_dma_to_phys and call dma_to_phys in its implementation. Call xen_phys_to_dma/xen_dma_to_phys instead of xen_phys_to_bus/xen_bus_to_phys through swiotlb-xen.c. Everything is taken care of by these changes except for xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a few explicit phys_to_dma/dma_to_phys calls. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik Reviewed-by: Juergen Gross Juergen
Re: [PATCH V3 vhost next 00/10] VDPA support for Mellanox ConnectX devices
On Mon, Aug 03, 2020 at 04:34:50PM -0400, Michael S. Tsirkin wrote: > On Wed, Jul 29, 2020 at 08:54:52AM +0300, Eli Cohen wrote: > > On Tue, Jul 28, 2020 at 02:53:34PM +0800, Jason Wang wrote: > > > > > > Just notice Michael's vhost branch can not compile due to this commit: > > > > > > commit fee8fe6bd8ccacd27e963b71b4f943be3721779e > > > Author: Michael S. Tsirkin > > > Date:Â Â Mon Jul 27 10:51:55 2020 -0400 > > > > > > Â Â Â vdpa: make sure set_features in invoked for legacy > > > > > > Let's wait for Michael to clarify the correct branch to use then. > > > > > > > Michael, are you going to send a path to a git tree that I can rebase my > > series on top of it, or maybe you can just take my v3 and apply them on > > the right tree? If you do, you can take Jason's patches from the series > > he posted here https://lkml.org/lkml/2020/7/1/301 and take my 0003-0010 > > patches. > > > > Let me know. > > It's a bit too hard to figure out how to put these pieces together, when > I tried I run into some conflicts, and given I can't test them I'd > rather you did this. Please also note kbuild test bot reported a build > failure on mips. > > A good tree to base your work on is the linux-next branch > in https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git > ok, will do and send v4
Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections
On 2020-08-03, Andi Kleen wrote: Why is that? Both .text and .text.hot have alignment of 2^4 (default function alignment on x86) by default, so it doesn't seem like it should matter for packing density. Avoiding interspersing cold text among You may lose part of a cache line on each unit boundary. Linux has a lot of units, some of them small. All these bytes add up. It's bad for TLB locality too. Sadly with all the fine grained protection changes the 2MB coverage is eroding anyways, but this makes it even worse. Gives worse packing for the hot part if they are not aligned to 64byte boundaries, which they are usually not. I do not see how the 64-byte argument is related to this patch. If a function requires 64-byte alignment to be efficient, the compiler should communicate this fact by setting the alignment of its containing section to 64 bytes or above. If a text section has a 16-byte alignment, the linker can reorder it to an address which is a multiple of 16 but not a multiple of 64. I agree with your other statement that having a single input section description might be helpful. With more than one input section descrition, the linker has to respect the ordering requirement. With just one input section description, the linker has more freedom ordering sections if profitable. For example, LLD performs two ordering heuristics as my previous reply mentions. It'd be good if someone can measure the benefit. Personally I don't think this kind of ordering has significant benefit. (For arm/aarch64/powerpc there might be some size benefit due to fewer range extension thunks) regular/hot text seems like it should be a net win. That old commit doesn't reference efficiency -- it says there was some problem with matching when they were separated out, but there were no wildcard section names back then. It was about efficiency. -Andi -- You received this message because you are subscribed to the Google Groups "Clang Built Linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20200804044532.GC1321588%40tassilo.jf.intel.com.
Re: [PATCH V1 1/2] mmc: sdhci-pci-o2micro: Bug fix for O2 host controller Seabird1
Sorry, I have been away for a while, but I will look at it shortly.
On 3/08/20 10:23 pm, Shirley Her (SC) wrote:
> Hi, Adrian:
>
> Do you have chance to review the patched code?
>
> Thanks,
> Shirley
>
>
> *From:* Shirley Her (SC)
> *Sent:* Monday, July 20, 2020 6:18 PM
> *To:* adrian.hun...@intel.com ;
> ulf.hans...@linaro.org ; linux-...@vger.kernel.org
> ; linux-kernel@vger.kernel.org
>
> *Cc:* Shaper Liu (WH) ; Chevron Li (WH)
> ; Xiaoguang Yu (WH)
> ; Max Huang (SC) ;
> Shirley Her (SC)
> *Subject:* [PATCH V1 1/2] mmc: sdhci-pci-o2micro: Bug fix for O2 host
> controller Seabird1
>
> Add bug fix for O2 host controller Seabird1
>
> Signed-off-by: Shirley Her
> ---
> change in V1:
> 1. Add quriks2 and mmc->caps2 for Seabird1
> 2. Add get_cd support for Seabird1
> ---
> drivers/mmc/host/sdhci-pci-o2micro.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c
> b/drivers/mmc/host/sdhci-pci-o2micro.c
> index e2a846885902..ed3c605fcf0c 100644
> --- a/drivers/mmc/host/sdhci-pci-o2micro.c
> +++ b/drivers/mmc/host/sdhci-pci-o2micro.c
> @@ -561,6 +561,12 @@ static int sdhci_pci_o2_probe_slot(struct
> sdhci_pci_slot *slot)
> slot->host->mmc_host_ops.get_cd = sdhci_o2_get_cd;
> }
>
> + if (chip->pdev->device == PCI_DEVICE_ID_O2_SEABIRD1) {
> + slot->host->mmc_host_ops.get_cd = sdhci_o2_get_cd;
> + host->mmc->caps2 |= MMC_CAP2_NO_SDIO;
> + host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
> + }
> +
> host->mmc_host_ops.execute_tuning = sdhci_o2_execute_tuning;
>
> if (chip->pdev->device != PCI_DEVICE_ID_O2_FUJIN2)
> --
> 2.25.1
>
[RFC PATCH] dma-iommu: allow devices to set IOVA range dynamically
Currently, there is no other option to change the lower limit of
IOVA for any device than calling iova_init_domain(), but the
said function will re-init whole domain and also doesn't track
the previously allocated IOVA before re-initing the domain.
There are cases where the device might not support continuous
range of addresses, and can also have dependency among buffers
allocated for firmware, image manipulation, etc and all of the
address requests pass through IOMMU. In such cases, we can allocate
buffers stage by stage by setting address limit, and also keep
track the of same.
Bit of background can be found here:
IOVA allocation dependency between firmware buffer and remaining buffers
https://www.spinics.net/lists/iommu/msg43586.html
This patch allows devices to limit the IOVA space they want
during allocation at any given point of time. We shall allow
the same only if the device owns the corresponding iommu_domain,
that is the device is the only master attached to the domain.
The lower limit of IOVA space is marked by start_pfn, and the upper
limit is marked by dma_mask and this patch honors the same.
Since changing dma_mask can extend the addressable region beyond
current cached node, we do a reset of current cached nodes as well.
Signed-off-by: Ajay Kumar
---
drivers/iommu/dma-iommu.c | 73 +++
drivers/iommu/iommu.c | 16 +
include/linux/iommu.h | 6
include/linux/iova.h | 6
4 files changed, 101 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4959f5df21bd..2fe3f57ab648 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -167,6 +167,79 @@ void iommu_dma_get_resv_regions(struct device *dev, struct
list_head *list)
}
EXPORT_SYMBOL(iommu_dma_get_resv_regions);
+/**
+ * iommu_set_iova_range - Limit the IOVA region for a specific device
+ * @dev: Device to set IOVA range for
+ * @base: Base address or the lower limit of the IOVA range
+ * @size: Size of address range from lower limit to upper limit
+ *
+ * Allow a master device to dynamically control the range of IOVA addresses
+ * which are allocated iff the master device is the only device attached to
+ * the corresponding iommu_domain.
+ * This function doesn't harm IOVA addresses outside of current range,
+ * which were allocated prior to calling this function.
+ */
+int iommu_set_iova_range(struct device *dev, dma_addr_t base, u64 size)
+{
+ struct iommu_domain *domain;
+ struct iommu_dma_cookie *cookie;
+ struct iova_domain *iovad;
+ unsigned long shift, base_pfn;
+ u64 new_dma_mask;
+
+ /*
+* Check if the IOMMU master device is the sole entry in the group
+* If the group has more than one master device using the same IOMMU
+* we shouldn't be allowing that device to change the IOVA limit
+*/
+ if (iommu_group_device_count_from_dev(dev) != 1)
+ return -EINVAL;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain)
+ return -ENODEV;
+
+ if (domain->type != IOMMU_DOMAIN_DMA)
+ return -EINVAL;
+
+ cookie = domain->iova_cookie;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -ENODEV;
+
+ iovad = >iovad;
+
+ shift = iova_shift(iovad);
+ base_pfn = base >> shift;
+
+ base_pfn = max_t(unsigned long, 1, base_pfn);
+
+ /* base cannot be outside aperture */
+ if (domain->geometry.force_aperture) {
+ if (base > domain->geometry.aperture_end ||
+ base + size <= domain->geometry.aperture_start) {
+ pr_warn("specified DMA range outside IOMMU
capability\n");
+ return -EFAULT;
+ }
+ /* ...then finally give it a kicking to make sure it fits */
+ base_pfn = max_t(unsigned long, base_pfn,
+ domain->geometry.aperture_start >> shift);
+ }
+ /* Set page aligned lower limit of IOVA range to start_pfn */
+ iovad->start_pfn = base_pfn;
+
+ /* Set upper limit of IOVA range to dma_mask */
+ new_dma_mask = (u64)base + size;
+ dma_set_mask_and_coherent(dev, new_dma_mask);
+
+ /* Reset cached nodes to start IOVA search from the anchor node */
+ iovad->cached_node = >anchor.node;
+ iovad->cached32_node = >anchor.node;
+ iovad->max32_alloc_size = iovad->dma_32bit_pfn;
+
+ return 0;
+}
+EXPORT_SYMBOL(iommu_set_iova_range);
+
static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
phys_addr_t start, phys_addr_t end)
{
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 609bd25bf154..30b2d4e5487d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -919,6 +919,22 @@ static int iommu_group_device_count(struct iommu_group
*group)
return ret;
}
+int
Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency
On 31-07-20, 13:14, Jon Hunter wrote:
> I have been doing some more testing on Tegra, I noticed that when
> reading the current CPU frequency via the sysfs scaling_cur_freq entry,
> this always returns the cached value (at least for Tegra). Looking at
> the implementation of scaling_cur_freq I see ...
>
> static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
> {
> ssize_t ret;
> unsigned int freq;
>
> freq = arch_freq_get_on_cpu(policy->cpu);
> if (freq)
> ret = sprintf(buf, "%u\n", freq);
> else if (cpufreq_driver && cpufreq_driver->setpolicy &&
> cpufreq_driver->get)
> ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu));
> else
> ret = sprintf(buf, "%u\n", policy->cur);
> return ret;
> }
>
> The various Tegra CPU frequency drivers do not implement the
> set_policy callback and hence why we always get the cached value. I
> see the following commit added this and before it simply return the
> cached value ...
>
> commit c034b02e213d271b98c45c4a7b54af8f69aaac1e
> Author: Dirk Brandewie
> Date: Mon Oct 13 08:37:40 2014 -0700
>
> cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
>
> Is this intentional?
Yes, it is.
There are two sysfs files to read the current frequency.
- scaling_cur_freq: as you noticed it returns cached value unless it is for
setpolicy drivers in whose case cpufreq core doesn't control the frequency and
so doesn't cache any values.
- cpuinfo_cur_freq: This will return the value as read from hardware using
->get() callback.
--
viresh
[PATCH] RTC: Implement pretimeout watchdog for DS1307
If the hardware watchdog in the clock chip simply pulls the reset line
of the CPU, then there is no chance to write a stack trace to help
determine what may have been blocking the CPU.
This patch adds a pretimeout to the watchdog, which, if enabled, sets
a timer to go off before the hardware watchdog kicks in, and calls
the standard pretimeout function, which can (for example) call panic.
Signed-off-by: Mark Tomlinson
---
drivers/rtc/rtc-ds1307.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 49702942bb08..647f8659d0bd 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
/*
* We can't determine type by probing, but if we expect pre-Linux code
@@ -174,6 +175,10 @@ struct ds1307 {
#ifdef CONFIG_COMMON_CLK
struct clk_hw clks[2];
#endif
+#ifdef CONFIG_WATCHDOG_CORE
+ struct timer_list soft_timer;
+ struct watchdog_device *wdt;
+#endif
};
struct chip_desc {
@@ -863,12 +868,34 @@ static int m41txx_rtc_set_offset(struct device *dev, long
offset)
}
#ifdef CONFIG_WATCHDOG_CORE
+static void ds1388_soft_wdt_expire(struct timer_list *soft_timer)
+{
+ struct ds1307 *ds1307 = container_of(soft_timer, struct ds1307,
soft_timer);
+
+ watchdog_notify_pretimeout(ds1307->wdt);
+}
+
+static void ds1388_soft_timer_set(struct watchdog_device *wdt_dev)
+{
+ struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev);
+ int soft_timeout;
+
+ if (wdt_dev->pretimeout > 0) {
+ soft_timeout = wdt_dev->timeout - wdt_dev->pretimeout;
+ mod_timer(>soft_timer, jiffies + soft_timeout * HZ);
+ } else {
+ del_timer(>soft_timer);
+ }
+}
+
static int ds1388_wdt_start(struct watchdog_device *wdt_dev)
{
struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev);
u8 regs[2];
int ret;
+ ds1388_soft_timer_set(wdt_dev);
+
ret = regmap_update_bits(ds1307->regmap, DS1388_REG_FLAG,
DS1388_BIT_WF, 0);
if (ret)
@@ -900,6 +927,7 @@ static int ds1388_wdt_stop(struct watchdog_device *wdt_dev)
{
struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev);
+ del_timer(>soft_timer);
return regmap_update_bits(ds1307->regmap, DS1388_REG_CONTROL,
DS1388_BIT_WDE | DS1388_BIT_RST, 0);
}
@@ -909,6 +937,7 @@ static int ds1388_wdt_ping(struct watchdog_device *wdt_dev)
struct ds1307 *ds1307 = watchdog_get_drvdata(wdt_dev);
u8 regs[2];
+ ds1388_soft_timer_set(wdt_dev);
return regmap_bulk_read(ds1307->regmap, DS1388_REG_WDOG_HUN_SECS, regs,
sizeof(regs));
}
@@ -923,6 +952,7 @@ static int ds1388_wdt_set_timeout(struct watchdog_device
*wdt_dev,
regs[0] = 0;
regs[1] = bin2bcd(wdt_dev->timeout);
+ ds1388_soft_timer_set(wdt_dev);
return regmap_bulk_write(ds1307->regmap, DS1388_REG_WDOG_HUN_SECS, regs,
sizeof(regs));
}
@@ -1652,7 +1682,8 @@ static void ds1307_clks_register(struct ds1307 *ds1307)
#ifdef CONFIG_WATCHDOG_CORE
static const struct watchdog_info ds1388_wdt_info = {
- .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE | WDIOF_PRETIMEOUT,
.identity = "DS1388 watchdog",
};
@@ -1681,6 +1712,8 @@ static void ds1307_wdt_register(struct ds1307 *ds1307)
wdt->timeout = 99;
wdt->max_timeout = 99;
wdt->min_timeout = 1;
+ ds1307->wdt = wdt;
+ timer_setup(>soft_timer, ds1388_soft_wdt_expire, 0);
watchdog_init_timeout(wdt, 0, ds1307->dev);
watchdog_set_drvdata(wdt, ds1307);
--
2.28.0
linux-next: build failure after merge of the vhost tree
Hi all,
After merging the vhost tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/rpmsg/virtio_rpmsg_bus.c:28:10: fatal error: linux/virtio_rpmsg.h: No
such file or directory
28 | #include
| ^~
Caused by commit
bba6f4f52c31 ("rpmsg: move common structures and defines to headers")
I have used the vhost tree from next-20200803 for today.
--
Cheers,
Stephen Rothwell
pgp7ZJAeJ9Tw9.pgp
Description: OpenPGP digital signature
Re: [v2,4/6] reset-controller: ti: introduce a new reset handler
On Mon, 2020-08-03 at 14:15 +0800, Crystal Guo wrote:
> Add ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
>
> Change-Id: I9046992b115a46f3594de57fa89c6a2de9957d49
Please drop "Change-Id" tags.
> ---
> drivers/reset/reset-ti-syscon.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c
> index a2635c21db7f..1c74bcb9a6c3 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -56,6 +56,7 @@ struct ti_syscon_reset_data {
> struct regmap *regmap;
> struct ti_syscon_reset_control *controls;
> unsigned int nr_controls;
> + bool assert_deassert_together;
> };
>
> #define to_ti_syscon_reset_data(rcdev) \
> @@ -158,10 +159,24 @@ static int ti_syscon_reset_status(struct
> reset_controller_dev *rcdev,
> !(control->flags & STATUS_SET);
> }
>
> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> +
> + if (data->assert_deassert_together) {
> + ti_syscon_reset_assert(rcdev, id);
> + return ti_syscon_reset_deassert(rcdev, id);
> + } else {
> + return -ENOTSUPP;
> + }
> +}
> +
> static const struct reset_control_ops ti_syscon_reset_ops = {
> .assert = ti_syscon_reset_assert,
> .deassert = ti_syscon_reset_deassert,
> .status = ti_syscon_reset_status,
> + .reset = ti_syscon_reset,
> };
>
> static int ti_syscon_reset_probe(struct platform_device *pdev)
> @@ -204,6 +219,11 @@ static int ti_syscon_reset_probe(struct platform_device
> *pdev)
> controls[i].flags = be32_to_cpup(list++);
> }
>
> + if (of_property_read_bool(np, "assert-deassert-together"))
> + data->assert_deassert_together = true;
> + else
> + data->assert_deassert_together = false;
> +
> data->rcdev.ops = _syscon_reset_ops;
> data->rcdev.owner = THIS_MODULE;
> data->rcdev.of_node = np;
Perhaps please provide the reason why you shall add this new method? Any
existed or upcoming users?
Thanks,
Stanley Chu
linux-next: manual merge of the vhost tree with the scsi tree
Hi all,
Today's linux-next merge of the vhost tree got a conflict in:
drivers/scsi/virtio_scsi.c
between commit:
92e8d0323a51 ("scsi: virtio_scsi: Remove unnecessary condition check")
from the scsi tree and commit:
3dfd411ea7ec ("scsi: virtio_scsi: remove unnecessary condition check")
from the vhost tree.
I fixed it up (I used the former as it was a superset of the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp1oPBmIfnsM.pgp
Description: OpenPGP digital signature
[PATCH 2/3] kexec: Improve the crash_exclude_mem_range() to handle the overlapping ranges
The crash_exclude_mem_range() can only handle one memory region one time.
It will fail the case in which the passed in area covers several memory
regions. In the case, it will only exclude the first region, then return,
but leave the later regions unsolved.
E.g in a NEC system with two usable RAM regions inside the low 1M:
...
BIOS-e820: [mem 0x-0x0003efff] usable
BIOS-e820: [mem 0x0003f000-0x0003] reserved
BIOS-e820: [mem 0x0004-0x0009] usable
It will only exclude the memory region [0, 0x3efff], the memory region
[0x4, 0x9] will still be added into /proc/vmcore, which may cause
the following failure when dumping the vmcore:
ioremap on RAM at 0x0004 - 0x00040fff
WARNING: CPU: 0 PID: 665 at arch/x86/mm/ioremap.c:186
__ioremap_caller+0x2c7/0x2e0
...
RIP: 0010:__ioremap_caller+0x2c7/0x2e0
Code: 05 20 47 1c 01 48 09 c5 e9 93 fe ff ff 48 8d 54 24 28 48 8d 74 24 18 48 c7
c7 85 e7 09 82 c6 05 b4 10 36 01 01 e8 32 91 04 00 <0f> 0b 45 31 ff e9 f3
fe ff ff e8 2a 8e 04 00 66 2e 0f 1f 84 00 00
RSP: 0018:c971fd60 EFLAGS: 00010286
RAX: RBX: 0004 RCX:
RDX: 8880620268c0 RSI: 888062016a08 RDI: 888062016a08
RBP: R08: 0441 R09: 0048
R10: R11: c971fc08 R12: 7f794c343000
R13: 1000 R14: R15:
FS: 7f794c352800() GS:88806200() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f794c35 CR3: 5df9c005 CR4: 001606b0
Call Trace:
? __copy_oldmem_page.part.0+0x9c/0xb0
__copy_oldmem_page.part.0+0x9c/0xb0
read_from_oldmem.part.2+0xe2/0x140
read_vmcore+0xd8/0x2f0
proc_reg_read+0x39/0x60
vfs_read+0x91/0x140
ksys_read+0x4f/0xb0
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
cp: error reading '/proc/vmcore': Cannot allocate memory
kdump: saving vmcore failed
In order to solve this issue, let's extend the crash_exclude_mem_range()
to handle the overlapping ranges.
Signed-off-by: Lianbo Jiang
---
kernel/kexec_file.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 09cc78df53c6..41616b6a80ad 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -1157,24 +1157,26 @@ int crash_exclude_mem_range(struct crash_mem *mem,
unsigned long long mstart, unsigned long long mend)
{
int i, j;
- unsigned long long start, end;
+ unsigned long long start, end, p_start, p_end;
struct crash_mem_range temp_range = {0, 0};
for (i = 0; i < mem->nr_ranges; i++) {
start = mem->ranges[i].start;
end = mem->ranges[i].end;
+ p_start = mstart;
+ p_end = mend;
if (mstart > end || mend < start)
continue;
/* Truncate any area outside of range */
if (mstart < start)
- mstart = start;
+ p_start = start;
if (mend > end)
- mend = end;
+ p_end = end;
/* Found completely overlapping range */
- if (mstart == start && mend == end) {
+ if (p_start == start && p_end == end) {
mem->ranges[i].start = 0;
mem->ranges[i].end = 0;
if (i < mem->nr_ranges - 1) {
@@ -1185,20 +1187,29 @@ int crash_exclude_mem_range(struct crash_mem *mem,
mem->ranges[j].end =
mem->ranges[j+1].end;
}
+
+ /*
+* Continue to check if there are another
overlapping ranges
+* from the current position because of
shifting the above
+* mem ranges.
+*/
+ i--;
+ mem->nr_ranges--;
+ continue;
}
mem->nr_ranges--;
return 0;
}
- if (mstart > start && mend < end) {
+ if (p_start > start && p_end < end) {
/* Split original range */
- mem->ranges[i].end = mstart - 1;
- temp_range.start = mend + 1;
+ mem->ranges[i].end = p_start - 1;
+ temp_range.start = p_end + 1;
temp_range.end = end;
- } else if (mstart != start)
- mem->ranges[i].end = mstart - 1;
+ } else
[PATCH 3/3] kexec_file: correctly output debugging information for the PT_LOAD elf header
Currently, when we enable the debugging switch to debug kexec_file,
always get the following wrong results:
kexec_file: Crash PT_LOAD elf header. phdr=c988639b vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=51 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=3cca69a0 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=52 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=c584cb9f vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=53 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=cf85d57f vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=54 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=a4a8f847 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=55 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=272ec49f vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=56 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=ea0b65de vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=57 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=1f5e490c vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=58 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=dfe4109e vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=59 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=480ed2b6 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=60 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=80b65151 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=61 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=24e31c5e vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=62 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=332e0385 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=63 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=2754d5da vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=64 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=783320dd vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=65 p_offset=0x0
kexec_file: Crash PT_LOAD elf header. phdr=76fe5b64 vaddr=0x0,
paddr=0x0, sz=0x0 e_phnum=66 p_offset=0x0
The reason is that kernel always prints the values of the next PT_LOAD
instead of the current PT_LOAD. Change it to ensure that we can get the
correct debugging information.
Signed-off-by: Lianbo Jiang
---
kernel/kexec_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 41616b6a80ad..e2c03b4ce31b 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -1323,10 +1323,10 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,
int kernel_map,
phdr->p_filesz = phdr->p_memsz = mend - mstart + 1;
phdr->p_align = 0;
ehdr->e_phnum++;
- phdr++;
pr_debug("Crash PT_LOAD elf header. phdr=%p vaddr=0x%llx,
paddr=0x%llx, sz=0x%llx e_phnum=%d p_offset=0x%llx\n",
phdr, phdr->p_vaddr, phdr->p_paddr, phdr->p_filesz,
ehdr->e_phnum, phdr->p_offset);
+ phdr++;
}
*addr = buf;
--
2.17.1
[PATCH 0/3] x86/kexec_file: Fix some corners bugs and improve the crash_exclude_mem_range()
This series includes the following patches, it fixes some corners bugs and improves the crash_exclude_mem_range(). [1] [PATCH 1/3] x86/crash: Correct the address boundary of function parameters [2] [PATCH 2/3] kexec: Improve the crash_exclude_mem_range() to handle the overlapping ranges [3] [PATCH 3/3] kexec_file: correctly output debugging information for the PT_LOAD elf header Lianbo Jiang (3): x86/crash: Correct the address boundary of function parameters kexec: Improve the crash_exclude_mem_range() to handle the overlapping ranges kexec_file: correctly output debugging information for the PT_LOAD elf header arch/x86/kernel/crash.c | 2 +- kernel/kexec_file.c | 33 ++--- 2 files changed, 23 insertions(+), 12 deletions(-) -- 2.17.1
[PATCH 1/3] x86/crash: Correct the address boundary of function parameters
Let's carefully handle the boundary of the function parameter to make sure that the arguments passed doesn't exceed the address range. Signed-off-by: Lianbo Jiang --- arch/x86/kernel/crash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index fd87b59452a3..a8f3af257e26 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -230,7 +230,7 @@ static int elf_header_exclude_ranges(struct crash_mem *cmem) int ret = 0; /* Exclude the low 1M because it is always reserved */ - ret = crash_exclude_mem_range(cmem, 0, 1<<20); + ret = crash_exclude_mem_range(cmem, 0, (1<<20)-1); if (ret) return ret; -- 2.17.1
Re: [PATCH v3] cpufreq: CPPC: simply the code access 'highest_perf' value in cppc_perf_caps struct
Thanks 在 2020/8/4 下午12:37, Viresh Kumar 写道: On 04-08-20, 10:37, Xin Hao wrote: Hi everyone: I want to know why my patch didn't merge into upstream ? I have sent a pull request earlier today to Rafael and this will get merged in the next pull request Rafael will send to Linus.
Re: [PATCH] crypto: ccp - zero the cmd data after use it
On 8/4/20 12:22, Herbert Xu wrote: > On Tue, Aug 04, 2020 at 12:20:21PM +0800, Liwei Song wrote: >> >> Yes, the other process should do this zero work, but the case I met is >> this address will appear in the slab_alloc_node() as freelist pointer of >> slub, >> and before slub do zero wrok, even kzalloc() doesn't work with this address. > > That would be memory corruption which has nothing to do with your > patch. If it is occurring then you should fix the place that is > corrupting the memory and not work around it like this. OK, understand, thanks for your suggestion. Liwei. > > Cheers, >
Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections
> Why is that? Both .text and .text.hot have alignment of 2^4 (default > function alignment on x86) by default, so it doesn't seem like it should > matter for packing density. Avoiding interspersing cold text among You may lose part of a cache line on each unit boundary. Linux has a lot of units, some of them small. All these bytes add up. It's bad for TLB locality too. Sadly with all the fine grained protection changes the 2MB coverage is eroding anyways, but this makes it even worse. > regular/hot text seems like it should be a net win. > > That old commit doesn't reference efficiency -- it says there was some > problem with matching when they were separated out, but there were no > wildcard section names back then. It was about efficiency. -Andi
Re: [PATCH v3] cpufreq: CPPC: simply the code access 'highest_perf' value in cppc_perf_caps struct
On 04-08-20, 10:37, Xin Hao wrote: > Hi everyone: > > I want to know why my patch didn't merge into upstream ? I have sent a pull request earlier today to Rafael and this will get merged in the next pull request Rafael will send to Linus. -- viresh
wx
-- Dear friend do you receive my last message? write me back to my email let me know.
helo
-- Dear friend do you receive my last message? write me back to my email let me know.
RE: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
> > For avoid further misunderstanding: it's fine that CRAS *uses* such a short > period. It's often required for achieving a short latency. > > However, the question is whether the driver can set *only* this value for > making it working. IOW, if we don't have this constraint, what actually > happens? If the driver gives the period size alignment, wouldn't CRAS > choose 240? It won't. Without the constraint it becomes 432. Actually CRAS does not set period size specifically so the value depends on the constraint rules. [ 52.011146] sound pcmC1D0p: hw_param [ 52.011152] sound pcmC1D0p: ACCESS 0x1 [ 52.011155] sound pcmC1D0p: FORMAT 0x4 [ 52.011158] sound pcmC1D0p: SUBFORMAT 0x1 [ 52.011161] sound pcmC1D0p: SAMPLE_BITS [16:16] [ 52.011164] sound pcmC1D0p: FRAME_BITS [32:32] [ 52.011167] sound pcmC1D0p: CHANNELS [2:2] [ 52.011170] sound pcmC1D0p: RATE [48000:48000] [ 52.011173] sound pcmC1D0p: PERIOD_TIME [9000:9000] [ 52.011176] sound pcmC1D0p: PERIOD_SIZE [432:432] [ 52.011179] sound pcmC1D0p: PERIOD_BYTES [1728:1728] [ 52.011182] sound pcmC1D0p: PERIODS [474:474] [ 52.011185] sound pcmC1D0p: BUFFER_TIME [4266000:4266000] [ 52.011188] sound pcmC1D0p: BUFFER_SIZE [204768:204768] [ 52.011191] sound pcmC1D0p: BUFFER_BYTES [819072:819072] [ 52.011194] sound pcmC1D0p: TICK_TIME [0:0] Regards, Brent > > > Takashi
[PATCH v2 3/6] arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should be kept enabled by SDMMC driver.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 829f786..8cca216 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1194,8 +1194,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC1>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 14>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1222,8 +1223,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0200 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC2>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC2>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 9>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-1v8-drv";
@@ -1239,8 +1241,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0400 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC3>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 69>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1262,8 +1265,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0600 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC4>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 15>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3-drv", "sdmmc-1v8-drv";
--
2.7.4
[PATCH v2 6/6] sdhci: tegra: Add missing TMCLK for data timeout
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.
USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
SDHCI_TEGRA_VENDOR_SYS_SW_CTRL can be used to choose either TMCLK or
SDCLK for data timeout.
Default USE_TMCLK_FOR_DATA_TIMEOUT bit is set to 1 and TMCLK is used
for data timeout by Tegra SDMMC hardware and having TMCLK not enabled
is not recommended.
So, this patch fixes it.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 31ed321..c0b9405 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -140,6 +140,7 @@ struct sdhci_tegra_autocal_offsets {
struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
struct gpio_desc *power_gpio;
+ struct clk *tmclk;
bool ddr_signaling;
bool pad_calib_required;
bool pad_control_available;
@@ -1611,6 +1612,44 @@ static int sdhci_tegra_probe(struct platform_device
*pdev)
goto err_power_req;
}
+ /*
+* Tegra210 has a separate SDMMC_LEGACY_TM clock used for host
+* timeout clock and SW can choose TMCLK or SDCLK for hardware
+* data timeout through the bit USE_TMCLK_FOR_DATA_TIMEOUT of
+* the register SDHCI_TEGRA_VENDOR_SYS_SW_CTRL.
+*
+* USE_TMCLK_FOR_DATA_TIMEOUT bit default is set to 1 and SDMMC uses
+* 12Mhz TMCLK which is advertised in host capability register.
+* With TMCLK of 12Mhz provides maximum data timeout period that can
+* be achieved is 11s better than using SDCLK for data timeout.
+*
+* So, TMCLK is set to 12Mhz and kept enabled all the time on SoC's
+* supporting SDR104 mode and when not using SDCLK for data timeout.
+*/
+
+ if ((soc_data->nvquirks & NVQUIRK_ENABLE_SDR104) &&
+ !(soc_data->pdata->quirks & SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)) {
+ clk = devm_clk_get(>dev, "tmclk");
+ if (IS_ERR(clk)) {
+ rc = PTR_ERR(clk);
+ if (rc == -EPROBE_DEFER)
+ goto err_power_req;
+
+ dev_warn(>dev, "failed to get tmclk: %d\n", rc);
+ clk = NULL;
+ }
+
+ clk_set_rate(clk, 1200);
+ rc = clk_prepare_enable(clk);
+ if (rc) {
+ dev_err(>dev,
+ "failed to enable tmclk: %d\n", rc);
+ goto err_power_req;
+ }
+
+ tegra_host->tmclk = clk;
+ }
+
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
rc = PTR_ERR(clk);
@@ -1654,6 +1693,7 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
err_rst_get:
clk_disable_unprepare(pltfm_host->clk);
err_clk_get:
+ clk_disable_unprepare(tegra_host->tmclk);
err_power_req:
err_parse_dt:
sdhci_pltfm_free(pdev);
@@ -1671,6 +1711,7 @@ static int sdhci_tegra_remove(struct platform_device
*pdev)
reset_control_assert(tegra_host->rst);
usleep_range(2000, 4000);
clk_disable_unprepare(pltfm_host->clk);
+ clk_disable_unprepare(tegra_host->tmclk);
sdhci_pltfm_free(pdev);
--
2.7.4
[PATCH v2 2/6] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.
Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra186.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2be3511..31ed321 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1455,7 +1455,6 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
--
2.7.4
[PATCH v2 1/6] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra210.
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 0a3f9d0..2be3511 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1418,7 +1418,6 @@ static const struct sdhci_ops tegra210_sdhci_ops = {
static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
--
2.7.4
[PATCH v2 5/6] arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should be kept enabled by SDMMC driver.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 48160f4..ca5cb6a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -460,8 +460,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0340 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC1>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = < TEGRA194_MEMORY_CLIENT_SDMMCRA
>,
@@ -485,8 +486,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0344 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC3>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = < TEGRA194_MEMORY_CLIENT_SDMMCR
>,
@@ -511,8 +513,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0346 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC4>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
assigned-clocks = < TEGRA194_CLK_SDMMC4>,
< TEGRA194_CLK_PLLC4>;
assigned-clock-parents =
--
2.7.4
[PATCH v2 4/6] arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.
So, this clock should be kept enabled by the SDMMC driver.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 34d249d..8eb61dd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -337,8 +337,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0340 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC1>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCRA >,
@@ -366,8 +367,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0342 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC2>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC2>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC2>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCRAA >,
@@ -390,8 +392,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0344 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC3>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = < TEGRA186_MEMORY_CLIENT_SDMMCR >,
@@ -416,8 +419,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0346 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC4>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
assigned-clocks = < TEGRA186_CLK_SDMMC4>,
< TEGRA186_CLK_PLLC4_VCO>;
assigned-clock-parents = < TEGRA186_CLK_PLLC4_VCO>;
--
2.7.4
[PATCH v2 0/6] Fix timeout clock used by hardware data timeout
Tegra210/Tegra186/Tegra194 has incorrectly enabled SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support. Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK) all the time for hardware data timeout instead of SDCLK and this TMCLK need to be kept enabled by Tegra sdmmc driver. This series includes patches to fix this for Tegra210/Tegra186/Tegra194. These patches need to be manually backported for 4.9, 4.14, 4.19, 5.4 Will send patches to backport separately once these patches are ack'd. Delta between patch versions: [v2]: Includes minor fix - Patch-0006: parentheses around operand of '!' Sowjanya Komatineni (6): sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186 arm64: tegra: Add missing timeout clock to Tegra210 SDMMC arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes sdhci: tegra: Add missing TMCLK for data timeout arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 +-- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 ++- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 +-- drivers/mmc/host/sdhci-tegra.c | 43 ++-- 4 files changed, 74 insertions(+), 24 deletions(-) -- 2.7.4
[PATCH 2/6] openrisc: uaccess: Fix sparse address space warnings
The OpenRISC user access functions put_user(), get_user() and
clear_user() were missing proper sparse annotations. This generated
warnings like the below.
This patch adds the annotations to fix the warnings.
Example warnings:
net/ipv4/ip_sockglue.c:759:29: warning: incorrect type in argument 1 (different
address spaces)
net/ipv4/ip_sockglue.c:759:29:expected void const volatile [noderef] __user
*
net/ipv4/ip_sockglue.c:759:29:got int const *__gu_addr
net/ipv4/ip_sockglue.c:764:29: warning: incorrect type in initializer
(different address spaces)
net/ipv4/ip_sockglue.c:764:29:expected unsigned char const *__gu_addr
net/ipv4/ip_sockglue.c:764:29:got unsigned char [noderef] __user *
Signed-off-by: Stafford Horne
---
arch/openrisc/include/asm/uaccess.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/openrisc/include/asm/uaccess.h
b/arch/openrisc/include/asm/uaccess.h
index 46e31bb4a9ad..f2fc5c4b88c3 100644
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -100,7 +100,7 @@ extern long __put_user_bad(void);
#define __put_user_check(x, ptr, size) \
({ \
long __pu_err = -EFAULT;\
- __typeof__(*(ptr)) *__pu_addr = (ptr); \
+ __typeof__(*(ptr)) __user *__pu_addr = (ptr); \
if (access_ok(__pu_addr, size)) \
__put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
@@ -173,7 +173,7 @@ struct __large_struct {
#define __get_user_check(x, ptr, size) \
({ \
long __gu_err = -EFAULT, __gu_val = 0; \
- const __typeof__(*(ptr)) * __gu_addr = (ptr); \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
if (access_ok(__gu_addr, size)) \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
@@ -248,10 +248,10 @@ raw_copy_to_user(void __user *to, const void *from,
unsigned long size)
#define INLINE_COPY_FROM_USER
#define INLINE_COPY_TO_USER
-extern unsigned long __clear_user(void *addr, unsigned long size);
+extern unsigned long __clear_user(void __user *addr, unsigned long size);
static inline __must_check unsigned long
-clear_user(void *addr, unsigned long size)
+clear_user(void __user *addr, unsigned long size)
{
if (likely(access_ok(addr, size)))
size = __clear_user(addr, size);
--
2.26.2
[PATCH 0/6] OpenRISC header and sparse warning fixes for 5.9
Hello, This a series of fixes for OpenRISC sparse warnings. The kbuild robots report many issues related to issues with OpenRISC headers having missing or incorrect sparse annotations. Example kdbuild-all report: net/ipv4/ip_sockglue.c:1489:13: sparse: sparse: incorrect type in initializer (different address spaces) https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/MB6SE7BX425ENFTSIL6KAOB3CVS4WJLH/ Also this includes a few cleanups which I noticed while working on the warning fixups. -Stafford Stafford Horne (6): openrisc: io: Fixup defines and move include to the end openrisc: uaccess: Fix sparse address space warnings openrisc: uaccess: Use static inline function in access_ok openrisc: uaccess: Remove unused macro __addr_ok openrisc: signal: Fix sparse address space warnings openrisc: uaccess: Add user address space check to access_ok arch/openrisc/include/asm/io.h | 7 +-- arch/openrisc/include/asm/uaccess.h | 21 +++-- arch/openrisc/kernel/signal.c | 14 +++--- 3 files changed, 23 insertions(+), 19 deletions(-) -- 2.26.2
[PATCH 5/6] openrisc: signal: Fix sparse address space warnings
The __user annotations in signal.c were mostly missing. The missing
annotations caused the warnings listed below. This patch fixes them up
by adding the __user annotations.
arch/openrisc/kernel/signal.c:71:38: warning: incorrect type in initializer
(different address spaces)
arch/openrisc/kernel/signal.c:71:38:expected struct rt_sigframe *frame
arch/openrisc/kernel/signal.c:71:38:got struct rt_sigframe [noderef] __user
*
arch/openrisc/kernel/signal.c:82:14: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:82:14:expected void const volatile [noderef]
__user *
arch/openrisc/kernel/signal.c:82:14:got struct rt_sigframe *frame
arch/openrisc/kernel/signal.c:84:37: warning: incorrect type in argument 2
(different address spaces)
arch/openrisc/kernel/signal.c:84:37:expected void const [noderef] __user
*from
arch/openrisc/kernel/signal.c:84:37:got struct sigset_t *
arch/openrisc/kernel/signal.c:89:39: warning: incorrect type in argument 2
(different address spaces)
arch/openrisc/kernel/signal.c:89:39:expected struct sigcontext [noderef]
__user *sc
arch/openrisc/kernel/signal.c:89:39:got struct sigcontext *
arch/openrisc/kernel/signal.c:92:31: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:92:31:expected struct sigaltstack const
[noderef] [usertype] __user *
arch/openrisc/kernel/signal.c:92:31:got struct sigaltstack *
arch/openrisc/kernel/signal.c:158:15: warning: incorrect type in assignment
(different address spaces)
arch/openrisc/kernel/signal.c:158:15:expected struct rt_sigframe *frame
arch/openrisc/kernel/signal.c:158:15:got void [noderef] __user *
arch/openrisc/kernel/signal.c:160:14: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:160:14:expected void const volatile [noderef]
__user *
arch/openrisc/kernel/signal.c:160:14:got struct rt_sigframe *frame
arch/openrisc/kernel/signal.c:165:46: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:165:46:expected struct siginfo [noderef]
[usertype] __user *to
arch/openrisc/kernel/signal.c:165:46:got struct siginfo *
arch/openrisc/kernel/signal.c:170:33: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:170:33:expected struct sigaltstack [noderef]
[usertype] __user *
arch/openrisc/kernel/signal.c:170:33:got struct sigaltstack *
arch/openrisc/kernel/signal.c:171:40: warning: incorrect type in argument 2
(different address spaces)
arch/openrisc/kernel/signal.c:171:40:expected struct sigcontext [noderef]
__user *sc
arch/openrisc/kernel/signal.c:171:40:got struct sigcontext *
arch/openrisc/kernel/signal.c:173:32: warning: incorrect type in argument 1
(different address spaces)
arch/openrisc/kernel/signal.c:173:32:expected void [noderef] __user *to
arch/openrisc/kernel/signal.c:173:32:got struct sigset_t *
Signed-off-by: Stafford Horne
---
arch/openrisc/kernel/signal.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/openrisc/kernel/signal.c b/arch/openrisc/kernel/signal.c
index 4f0754874d78..7ce0728412f6 100644
--- a/arch/openrisc/kernel/signal.c
+++ b/arch/openrisc/kernel/signal.c
@@ -68,7 +68,7 @@ static int restore_sigcontext(struct pt_regs *regs,
asmlinkage long _sys_rt_sigreturn(struct pt_regs *regs)
{
- struct rt_sigframe *frame = (struct rt_sigframe __user *)regs->sp;
+ struct rt_sigframe __user *frame = (struct rt_sigframe __user
*)regs->sp;
sigset_t set;
/*
@@ -76,7 +76,7 @@ asmlinkage long _sys_rt_sigreturn(struct pt_regs *regs)
* then frame should be dword aligned here. If it's
* not, then the user is trying to mess with us.
*/
- if (((long)frame) & 3)
+ if (((__force unsigned long)frame) & 3)
goto badframe;
if (!access_ok(frame, sizeof(*frame)))
@@ -151,7 +151,7 @@ static inline void __user *get_sigframe(struct ksignal
*ksig,
static int setup_rt_frame(struct ksignal *ksig, sigset_t *set,
struct pt_regs *regs)
{
- struct rt_sigframe *frame;
+ struct rt_sigframe __user *frame;
unsigned long return_ip;
int err = 0;
@@ -181,10 +181,10 @@ static int setup_rt_frame(struct ksignal *ksig, sigset_t
*set,
l.ori r11,r0,__NR_sigreturn
l.sys 1
*/
- err |= __put_user(0xa960, (short *)(frame->retcode + 0));
- err |= __put_user(__NR_rt_sigreturn, (short *)(frame->retcode + 2));
- err |= __put_user(0x2001, (unsigned long *)(frame->retcode + 4));
- err |= __put_user(0x1500, (unsigned long *)(frame->retcode + 8));
+ err |= __put_user(0xa960, (short __user *)(frame->retcode +
0));
+ err |= __put_user(__NR_rt_sigreturn, (short __user
[PATCH 6/6] openrisc: uaccess: Add user address space check to access_ok
Now that __user annotations are fixed for openrisc uaccess api's we can
add checking to the access_ok macro. This patch adds the __chk_user_ptr
check, on normal builds the added check is a nop.
Signed-off-by: Stafford Horne
---
arch/openrisc/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/include/asm/uaccess.h
b/arch/openrisc/include/asm/uaccess.h
index 85a55359b244..53ddc66abb3f 100644
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -57,7 +57,8 @@ static inline int __range_ok(unsigned long addr, unsigned
long size)
#define access_ok(addr, size) \
({ \
- __range_ok((unsigned long)(addr), (size)); \
+ __chk_user_ptr(addr); \
+ __range_ok((__force unsigned long)(addr), (size)); \
})
/*
--
2.26.2
[PATCH 3/6] openrisc: uaccess: Use static inline function in access_ok
As suggested by Linus when reviewing commit 9cb2feb4d21d
("arch/openrisc: Fix issues with access_ok()") last year; making
__range_ok an inline function also fixes the used twice issue that the
commit was fixing. I agree it's a good cleanup. This patch addresses
that as I am currently working on the access_ok macro to fixup sparse
annotations in OpenRISC.
Suggested-by: Linus Torvalds
Signed-off-by: Stafford Horne
---
arch/openrisc/include/asm/uaccess.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/openrisc/include/asm/uaccess.h
b/arch/openrisc/include/asm/uaccess.h
index f2fc5c4b88c3..4b59dc9ad300 100644
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -48,16 +48,19 @@
/* Ensure that the range from addr to addr+size is all within the process'
* address space
*/
-#define __range_ok(addr, size) (size <= get_fs() && addr <= (get_fs()-size))
+static inline int __range_ok(unsigned long addr, unsigned long size)
+{
+ const mm_segment_t fs = get_fs();
+
+ return size <= fs && addr <= (fs - size);
+}
/* Ensure that addr is below task's addr_limit */
#define __addr_ok(addr) ((unsigned long) addr < get_fs())
#define access_ok(addr, size) \
({ \
- unsigned long __ao_addr = (unsigned long)(addr);\
- unsigned long __ao_size = (unsigned long)(size);\
- __range_ok(__ao_addr, __ao_size); \
+ __range_ok((unsigned long)(addr), (size)); \
})
/*
--
2.26.2
[PATCH 1/6] openrisc: io: Fixup defines and move include to the end
This didn't seem to cause any issues, but while working on fixing up sparse annotations for OpenRISC I noticed this. This patch moves the include of asm-generic/io.h to the end of the file. Also, we add defines of ioremap and iounmap, that way we don't get duplicate definitions from asm-generic/io.h. Signed-off-by: Stafford Horne --- arch/openrisc/include/asm/io.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h index db02fb2077d9..ef985540b674 100644 --- a/arch/openrisc/include/asm/io.h +++ b/arch/openrisc/include/asm/io.h @@ -25,9 +25,12 @@ #define PIO_OFFSET 0 #define PIO_MASK 0 -#include - +#define ioremap ioremap void __iomem *ioremap(phys_addr_t offset, unsigned long size); + +#define iounmap iounmap extern void iounmap(void *addr); +#include + #endif -- 2.26.2
[PATCH 4/6] openrisc: uaccess: Remove unused macro __addr_ok
Since commit b48b2c3e5043 ("openrisc: use generic strnlen_user()
function") the macro __addr_ok is no longer used. It is safe to remove
so this patch removes it.
Signed-off-by: Stafford Horne
---
arch/openrisc/include/asm/uaccess.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/openrisc/include/asm/uaccess.h
b/arch/openrisc/include/asm/uaccess.h
index 4b59dc9ad300..85a55359b244 100644
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -55,9 +55,6 @@ static inline int __range_ok(unsigned long addr, unsigned
long size)
return size <= fs && addr <= (fs - size);
}
-/* Ensure that addr is below task's addr_limit */
-#define __addr_ok(addr) ((unsigned long) addr < get_fs())
-
#define access_ok(addr, size) \
({ \
__range_ok((unsigned long)(addr), (size)); \
--
2.26.2
Re: [PATCH] coresight: etm4x: Add Support for HiSilicon ETM device
Hi Qi Liu,
On 2020-08-03 19:05, Qi Liu wrote:
Add ETMv4 periperhal ID for HiSilicon Hip08 and Hip09 platform. Hip08
contains ETMv4.2 device and Hip09 contains ETMv4.5 device.
Signed-off-by: Qi Liu
---
drivers/hwtracing/coresight/coresight-etm4x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 0c35cd5e..4a4f0bd 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -1561,6 +1561,8 @@ static struct amba_cs_uci_id uci_id_etm4[] = {
};
static const struct amba_id etm4_ids[] = {
+ CS_AMBA_ID(0x000b6d02), /* HiSilicon-Hip09 */
+ CS_AMBA_ID(0x000b6d01), /* HiSilicon-Hip08 */
CS_AMBA_ID(0x000bb95d), /* Cortex-A53 */
CS_AMBA_ID(0x000bb95e), /* Cortex-A57 */
CS_AMBA_ID(0x000bb95a), /* Cortex-A72 */
--
2.8.1
You have missed adding the maintainers/reviewers of coresight(Mathieu
and Mike),
you can use scripts/get_maintainer.pl on the drivers to get the
maintainers and
reviewers for the corresponding drivers, same on other patch as well.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] crypto: ccp - zero the cmd data after use it
On Tue, Aug 04, 2020 at 12:20:21PM +0800, Liwei Song wrote: > > Yes, the other process should do this zero work, but the case I met is > this address will appear in the slab_alloc_node() as freelist pointer of slub, > and before slub do zero wrok, even kzalloc() doesn't work with this address. That would be memory corruption which has nothing to do with your patch. If it is occurring then you should fix the place that is corrupting the memory and not work around it like this. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
On Tue, Aug 4, 2020 at 11:23 AM Shengjiu Wang wrote:
>
> On Tue, Aug 4, 2020 at 11:00 AM Nicolin Chen wrote:
> >
> > On Tue, Aug 04, 2020 at 10:35:12AM +0800, Shengjiu Wang wrote:
> > > On Tue, Aug 4, 2020 at 10:11 AM Nicolin Chen
> > > wrote:
> > > >
> > > > On Tue, Aug 04, 2020 at 09:39:44AM +0800, Shengjiu Wang wrote:
> > > > > On Tue, Aug 4, 2020 at 5:57 AM Nicolin Chen
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Aug 03, 2020 at 04:04:23PM +0800, Shengjiu Wang wrote:
> > > > > >
> > > > > > > > > clock generation. The TCSR.TE is no need to enabled when only
> > > > > > > > > RX
> > > > > > > > > is enabled.
> > > > > > > >
> > > > > > > > You are correct if there's only RX running without TX joining.
> > > > > > > > However, that's something we can't guarantee. Then we'd enable
> > > > > > > > TE after RE is enabled, which is against what RM recommends:
> > > > > > > >
> > > > > > > > # From 54.3.3.1 Synchronous mode in IMX6SXRM
> > > > > > > > # If the receiver bit clock and frame sync are to be used by
> > > > > > > > # both the transmitter and receiver, it is recommended that
> > > > > > > > # the receiver is the last enabled and the first disabled.
> > > > > > > >
> > > > > > > > I remember I did this "ugly" design by strictly following what
> > > > > > > > RM says. If hardware team has updated the RM or removed this
> > > > > > > > limitation, please quote in the commit logs.
> > > > > > >
> > > > > > > There is no change in RM and same recommandation.
> > > > > > >
> > > > > > > My change does not violate the RM. The direction which generates
> > > > > > > the clock is still last enabled.
> > > > > >
> > > > > > Using Tx syncing with Rx clock for example,
> > > > > > T1: arecord (non-stop) => set RE
> > > > > > T2: aplay => set TE then RE (but RE is already set at T1)
> > > > > >
> > > > > > Anything that I am missing?
> > > > >
> > > > > This is a good example.
> > > > > We have used this change locally for a long time, so I think it is
> > > > > safe to do this change, a little different with the recommandation.
> > > >
> > > > Any reason for we have to go against the recommendation?
> > >
> > > Previous code will enable TE and RE together even for asynchronous
> > > mode.
> > > And for recommendation, previous code just consider the RX sync with
> > > TX, but still violates the recommendation for TX sync with RX case.
> > > So at least this new change is some kind of improvement.
> >
> > Okay. Let's change it then. Please make sure to update/remove
> > those old comments in the trigger(). And it's probably better
> > to mention that what we do now is a bit different from RM:
> > /*
> > * Enable the opposite direction for synchronous mode
> > * 1. Tx sync with Rx: only set RE for Rx; set TE & RE for Tx
> > * 2. Rx sync with Tx: only set TE for Tx; set RE & TE for Rx
> > *
> > * RM recommends to enable RE after TE for case 1 and to enable
> > * TE after RE for case 2, but we here may not always guarantee
> > * that happens: "arecord 1.wav; aplay 2.wav" in case 1 enables
> > * TE after RE, which is against what RM recommends but should
> > * be safe to do, judging by years of testing results.
> > */
>
> Thank you for the agreement.
>
> >
> > Btw, do we need similar change for TRIGGER_STOP?
>
> This is a good question. It is better to do change for STOP,
> but I am afraid that there is no much test to guarantee the result.
>
> best regards
> wang shengjiu
Maybe we can do this change for STOP.
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1c0e06bb3783..6e4be398eaee 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -517,6 +517,37 @@ static int fsl_sai_hw_free(struct
snd_pcm_substream *substream,
return 0;
}
+static void fsl_sai_config_disable(struct fsl_sai *sai, bool tx)
+{
+ unsigned int ofs = sai->soc_data->reg_offset;
+ u32 xcsr, count = 100;
+
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
+ FSL_SAI_CSR_TERE, 0);
+
+ /* TERE will remain set till the end of current frame */
+ do {
+ udelay(10);
+ regmap_read(sai->regmap, FSL_SAI_xCSR(tx, ofs), );
+ } while (--count && xcsr & FSL_SAI_CSR_TERE);
+
+ regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
+ FSL_SAI_CSR_FR, FSL_SAI_CSR_FR);
+
+ /*
+* For sai master mode, after several open/close sai,
+* there will be no frame clock, and can't recover
+* anymore. Add software reset to fix this issue.
+* This is a hardware bug, and will be fix in the
+* next sai version.
+*/
+ if (!sai->is_slave_mode) {
+ /* Software Reset for both Tx and Rx */
+ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs),
FSL_SAI_CSR_SR);
+ /* Clear SR bit to finish the reset */
+
Re: [v2,5/6] reset-controller: ti: Introduce force-update method
On Mon, 2020-08-03 at 14:15 +0800, Crystal Guo wrote:
> Introduce force-update method for assert and deassert interface,
> which force the write operation in case the read already happens
> to return the correct value.
>
> Signed-off-by: Crystal Guo
> ---
> drivers/reset/reset-ti-syscon.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c
> index 1c74bcb9a6c3..f4baf78afd14 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -57,6 +57,7 @@ struct ti_syscon_reset_data {
> struct ti_syscon_reset_control *controls;
> unsigned int nr_controls;
> bool assert_deassert_together;
> + bool update_force;
> };
>
> #define to_ti_syscon_reset_data(rcdev) \
> @@ -90,7 +91,10 @@ static int ti_syscon_reset_assert(struct
> reset_controller_dev *rcdev,
> mask = BIT(control->assert_bit);
> value = (control->flags & ASSERT_SET) ? mask : 0x0;
>
> - return regmap_update_bits(data->regmap, control->assert_offset, mask,
> value);
> + if (data->update_force)
> + return regmap_write_bits(data->regmap, control->assert_offset,
> mask, value);
> + else
> + return regmap_update_bits(data->regmap, control->assert_offset,
> mask, value);
> }
>
> /**
> @@ -121,7 +125,10 @@ static int ti_syscon_reset_deassert(struct
> reset_controller_dev *rcdev,
> mask = BIT(control->deassert_bit);
> value = (control->flags & DEASSERT_SET) ? mask : 0x0;
>
> - return regmap_update_bits(data->regmap, control->deassert_offset, mask,
> value);
> + if (data->update_force)
> + return regmap_write_bits(data->regmap,
> control->deassert_offset, mask, value);
> + else
> + return regmap_update_bits(data->regmap,
> control->deassert_offset, mask, value);
> }
>
> /**
> @@ -223,6 +230,10 @@ static int ti_syscon_reset_probe(struct platform_device
> *pdev)
> data->assert_deassert_together = true;
> else
> data->assert_deassert_together = false;
> + if (of_property_read_bool(np, "update-force"))
> + data->update_force = true;
> + else
> + data->update_force = false;
>
> data->rcdev.ops = _syscon_reset_ops;
> data->rcdev.owner = THIS_MODULE;
This patch is good to help MediaTek drivers' transition to use
ti-syscon-reset-controller, also not have side effect to existed users.
Acked-by: Stanley Chu
Re: [PATCH] crypto: ccp - zero the cmd data after use it
On 8/4/20 12:04, Herbert Xu wrote: > On Tue, Aug 04, 2020 at 11:51:47AM +0800, Liwei Song wrote: >> >> On 8/3/20 20:52, Herbert Xu wrote: >>> On Mon, Aug 03, 2020 at 03:58:58PM +0800, Liwei Song wrote: exist the following assignment in ccp(ignore the force convert of the struct) by list_del in ccp_dequeue_cmd(): req->__ctx->cmd->entry->next = LIST_POISON1; after use the req, kzfree(req) can not zero the entry entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct when this address available as slub freelist pointer, this will cause the following "general protection fault" error if some process meet this LIST_POISON1 value address when request memory: >>> >>> Your description makes no sense. Please rewrite it and explain >>> the problem properly. >> >> The problem here is that the entry of struct ccp_cmd is not zeroed after we >> use it, >> If the other process got this address by kmalloc(), this illegal value >> "LIST_POISON1" >> will cause "general protection fault" error. > > If that's the case surely the other process should be zeroing > the memory? Your explanation still makes no sense. Yes, the other process should do this zero work, but the case I met is this address will appear in the slab_alloc_node() as freelist pointer of slub, and before slub do zero wrok, even kzalloc() doesn't work with this address. Thanks, Liwei. > > Thanks, >
Re: [GIT PULL] ACPI updates for v5.9-rc1
The pull request you sent on Mon, 3 Aug 2020 18:52:07 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2baa85d6927d11b8d946da2e4ad00dddca5b8da2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Power management fixes for v5.9-rc1
The pull request you sent on Mon, 3 Aug 2020 18:50:39 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.9-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/04084978003c1a1810a0b1fea581078106394a32 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 5.7 000/120] 5.7.13-rc1 review
On 8/3/20 8:12 PM, Linus Torvalds wrote: > On Mon, Aug 3, 2020 at 8:01 PM Guenter Roeck wrote: >> >> The bisect log below applies to both the sparc and the powerpc build >> failures. > > Does the attached fix it? > Yes, for the failing file with both ppc64 and sparc64. I started a full test for all architectures with the patch applied on top of v5.8. It should take about 1-2 hours to finish. I'll let you know when I have a complete set of results. Guenter
Re: [PATCH] crypto: ccp - zero the cmd data after use it
On Tue, Aug 04, 2020 at 11:51:47AM +0800, Liwei Song wrote: > > On 8/3/20 20:52, Herbert Xu wrote: > > On Mon, Aug 03, 2020 at 03:58:58PM +0800, Liwei Song wrote: > >> exist the following assignment in ccp(ignore the force > >> convert of the struct) by list_del in ccp_dequeue_cmd(): > >> req->__ctx->cmd->entry->next = LIST_POISON1; > >> > >> after use the req, kzfree(req) can not zero the entry > >> entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct > >> when this address available as slub freelist pointer, this will cause > >> the following "general protection fault" error if some process meet > >> this LIST_POISON1 value address when request memory: > > > > Your description makes no sense. Please rewrite it and explain > > the problem properly. > > The problem here is that the entry of struct ccp_cmd is not zeroed after we > use it, > If the other process got this address by kmalloc(), this illegal value > "LIST_POISON1" > will cause "general protection fault" error. If that's the case surely the other process should be zeroing the memory? Your explanation still makes no sense. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [f2fs-dev] [PATCH RFC 1/5] f2fs: introduce inmem curseg
On 08/04, Chao Yu wrote: > On 2020/8/4 10:44, Jaegeuk Kim wrote: > > On 08/04, Chao Yu wrote: > > > On 2020/7/25 16:42, Chao Yu wrote: > > > > On 2020/7/16 9:24, Chao Yu wrote: > > > > > On 2020/7/16 3:07, Jaegeuk Kim wrote: > > > > > > On 07/15, Chao Yu wrote: > > > > > > > On 2020/7/7 11:51, Jaegeuk Kim wrote: > > > > > > > > On 07/07, Chao Yu wrote: > > > > > > > > > On 2020/7/7 11:21, Jaegeuk Kim wrote: > > > > > > > > > > Hi Chao, > > > > > > > > > > > > > > > > > > > > Do you have any brief design doc to present the idea? > > > > > > > > > > > > > > > > > > Hi Jaegeuk, > > > > > > > > > > > > > > > > > > You mean this whole patchset, right? > > > > > > > > > > > > > > > > > > I can add a brief design description in patch 0/5. > > > > > > > > > > > > > > > > Yeah, it's a bit hard to understand the whole flow. > > > > > > > > > > > > > > Jaegeuk, > > > > > > > > > > > > > > Do you have time to take a look at this idea summarized in > > > > > > > [PATCH 0/5]'s cover letter? > > > > > > > > > > > > Sorry, I couldn't afford to sitting down to review the design. > > > > > > Let me give it a try soon. > > > > > > > > > > Alright, let me know if you have any question about the idea. > > > > > > > > Ping, > > > > > > > > Jaegeuk, still be too busy...? :P > > > > > > Ping again... > > > > > > Any thoughts about left patches in patchset? > > > > Ah, I was waiting for your another patch-set. > > Oops, I thought that you have not finished reviewing all patches... > > Anyway, let me send v2 w/ changes mentioned by you. > > BTW, we can discuss about how to enable such feature, options can be: > - enable when sb feature F2FS_FEATURE_ATGC was set > - enable via mount option Looks like mount option would be better. > - enable via sysfs > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > On 06/30, Chao Yu wrote: > > > > > > > > > > > Previous implementation of aligned pinfile allocation > > > > > > > > > > > will: > > > > > > > > > > > - allocate new segment on cold data log no matter whether > > > > > > > > > > > last used > > > > > > > > > > > segment is partially used or not, it makes IOs more > > > > > > > > > > > random; > > > > > > > > > > > - force concurrent cold data/GCed IO going into warm data > > > > > > > > > > > area, it > > > > > > > > > > > can make a bad effect on hot/cold data separation; > > > > > > > > > > > > > > > > > > > > > > In this patch, we introduce a new type of log named > > > > > > > > > > > 'inmem curseg', > > > > > > > > > > > the differents from normal curseg is: > > > > > > > > > > > - it reuses existed segment type (CURSEG_XXX_NODE/DATA); > > > > > > > > > > > - it only exists in memory, its segno, blkofs, summary > > > > > > > > > > > will not b > > > > > > > > > > > persisted into checkpoint area; > > > > > > > > > > > > > > > > > > > > > > With this new feature, we can enhance scalability of log, > > > > > > > > > > > special > > > > > > > > > > > allocators can be created for purposes: > > > > > > > > > > > - pure lfs allocator for aligned pinfile allocation or > > > > > > > > > > > file > > > > > > > > > > > defragmentation > > > > > > > > > > > - pure ssr allocator for later feature > > > > > > > > > > > > > > > > > > > > > > So that, let's update aligned pinfile allocation to use > > > > > > > > > > > this new > > > > > > > > > > > inmem curseg fwk. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Chao Yu > > > > > > > > > > > --- > > > > > > > > > > > fs/f2fs/checkpoint.c | 7 ++- > > > > > > > > > > > fs/f2fs/debug.c | 6 ++- > > > > > > > > > > > fs/f2fs/f2fs.h | 12 +++-- > > > > > > > > > > > fs/f2fs/file.c | 3 +- > > > > > > > > > > > fs/f2fs/gc.c | 2 +- > > > > > > > > > > > fs/f2fs/segment.c| 107 > > > > > > > > > > > ++- > > > > > > > > > > > fs/f2fs/segment.h| 17 --- > > > > > > > > > > > fs/f2fs/super.c | 9 ++-- > > > > > > > > > > > 8 files changed, 112 insertions(+), 51 deletions(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > > > > > > > > > > > index 1bb8278a1c4a..644a914af25a 100644 > > > > > > > > > > > --- a/fs/f2fs/checkpoint.c > > > > > > > > > > > +++ b/fs/f2fs/checkpoint.c > > > > > > > > > > > @@ -1623,11 +1623,16 @@ int f2fs_write_checkpoint(struct > > > > > > > > > > > f2fs_sb_info *sbi, struct cp_control *cpc) > > > > > > > > > > > f2fs_flush_sit_entries(sbi, cpc); > > > > > > > > > > > + /* save inmem log status */ > > > > > > > > > > > + f2fs_save_inmem_curseg(sbi, CURSEG_COLD_DATA_PINNED); > > > > > > > > > > > + > > > > > > > > > > > err = do_checkpoint(sbi, cpc); > > > > > > > > > > >
[PATCH v2] asm-generic/io.h: Fix sparse warnings on big-endian architectures
On big-endian architectures like OpenRISC, sparse outputs below warnings on
asm-generic/io.h. This is due to io statements like:
__raw_writel(cpu_to_le32(value), PCI_IOBASE + addr);
The __raw_writel() function expects native endianness, however
cpu_to_le32() returns __le32. On little-endian machines these match up
and there is no issue. However, on big-endian we get warnings, for IO
that is defined as little-endian the mismatch is expected.
The fix I propose is to __force to native endian.
Warnings:
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:215:22: warning: incorrect type in argument 1
(different base types)
./include/asm-generic/io.h:215:22:expected unsigned short [usertype] value
./include/asm-generic/io.h:215:22:got restricted __le16 [usertype]
./include/asm-generic/io.h:225:22: warning: incorrect type in argument 1
(different base types)
./include/asm-generic/io.h:225:22:expected unsigned int [usertype] value
./include/asm-generic/io.h:225:22:got restricted __le32 [usertype]
Signed-off-by: Stafford Horne
Acked-by: Arnd Bergmann
---
Changes since v1:
- Remove white space between casts and right hand value. That matches all of
the other casts.
include/asm-generic/io.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 30a3aab312e6..dabf8cb7203b 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -163,7 +163,7 @@ static inline u16 readw(const volatile void __iomem *addr)
u16 val;
__io_br();
- val = __le16_to_cpu(__raw_readw(addr));
+ val = __le16_to_cpu((__le16 __force)__raw_readw(addr));
__io_ar(val);
return val;
}
@@ -176,7 +176,7 @@ static inline u32 readl(const volatile void __iomem *addr)
u32 val;
__io_br();
- val = __le32_to_cpu(__raw_readl(addr));
+ val = __le32_to_cpu((__le32 __force)__raw_readl(addr));
__io_ar(val);
return val;
}
@@ -212,7 +212,7 @@ static inline void writeb(u8 value, volatile void __iomem
*addr)
static inline void writew(u16 value, volatile void __iomem *addr)
{
__io_bw();
- __raw_writew(cpu_to_le16(value), addr);
+ __raw_writew((u16 __force)cpu_to_le16(value), addr);
__io_aw();
}
#endif
@@ -222,7 +222,7 @@ static inline void writew(u16 value, volatile void __iomem
*addr)
static inline void writel(u32 value, volatile void __iomem *addr)
{
__io_bw();
- __raw_writel(__cpu_to_le32(value), addr);
+ __raw_writel((u32 __force)__cpu_to_le32(value), addr);
__io_aw();
}
#endif
@@ -474,7 +474,7 @@ static inline u16 _inw(unsigned long addr)
u16 val;
__io_pbr();
- val = __le16_to_cpu(__raw_readw(PCI_IOBASE + addr));
+ val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
__io_par(val);
return val;
}
@@ -487,7 +487,7 @@ static inline u32 _inl(unsigned long addr)
u32 val;
__io_pbr();
- val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
+ val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
__io_par(val);
return val;
}
@@ -508,7 +508,7 @@ static inline void _outb(u8 value, unsigned long addr)
static inline void _outw(u16 value, unsigned long addr)
{
__io_pbw();
- __raw_writew(cpu_to_le16(value), PCI_IOBASE + addr);
+ __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
__io_paw();
}
#endif
@@ -518,7 +518,7 @@ static inline void _outw(u16 value, unsigned long addr)
static inline void _outl(u32 value, unsigned long addr)
{
__io_pbw();
- __raw_writel(cpu_to_le32(value), PCI_IOBASE + addr);
+ __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
__io_paw();
}
#endif
--
2.26.2
Re: [f2fs-dev] [PATCH] f2fs: fix deadlock between quota writes and checkpoint
On 08/04, Chao Yu wrote: > On 2020/7/29 15:02, Jaegeuk Kim wrote: > > f2fs_write_data_pages(quota_mapping) > > __f2fs_write_data_pages f2fs_write_checkpoint > >* blk_start_plug(); > >* add bio in write_io[DATA] > >- block_operations > >- skip syncing quota by > > > > >DEFAULT_RETRY_QUOTA_FLUSH_COUNT > >- down_write(>node_write); > > f2fs_flush_merged_writes() will be called after block_operations(), why this > doesn't > help? Well, I think bio can be added after f2fs_flush_merged_writes() as well. > > >- f2fs_write_single_data_page > > - f2fs_do_write_data_page > >- f2fs_outplace_write_data > > - do_write_page > > - f2fs_allocate_data_block > > - down_write(node_write) > >- > > f2fs_wait_on_all_pages(F2FS_WB_CP_DATA); > > > > Signed-off-by: Daeho Jeong > > Signed-off-by: Jaegeuk Kim > > --- > > fs/f2fs/checkpoint.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > > index 8c782d3f324f0..99c8061da55b9 100644 > > --- a/fs/f2fs/checkpoint.c > > +++ b/fs/f2fs/checkpoint.c > > @@ -1269,6 +1269,8 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, > > int type) > > if (type == F2FS_DIRTY_META) > > f2fs_sync_meta_pages(sbi, META, LONG_MAX, > > FS_CP_META_IO); > > + else if (type == F2FS_WB_CP_DATA) > > + f2fs_submit_merged_write(sbi, DATA); > > io_schedule_timeout(DEFAULT_IO_TIMEOUT); > > } > > finish_wait(>cp_wait, ); > >
Re: [PATCH] crypto: ccp - zero the cmd data after use it
On 8/3/20 20:52, Herbert Xu wrote: > On Mon, Aug 03, 2020 at 03:58:58PM +0800, Liwei Song wrote: >> exist the following assignment in ccp(ignore the force >> convert of the struct) by list_del in ccp_dequeue_cmd(): >> req->__ctx->cmd->entry->next = LIST_POISON1; >> >> after use the req, kzfree(req) can not zero the entry >> entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct >> when this address available as slub freelist pointer, this will cause >> the following "general protection fault" error if some process meet >> this LIST_POISON1 value address when request memory: > > Your description makes no sense. Please rewrite it and explain > the problem properly. The problem here is that the entry of struct ccp_cmd is not zeroed after we use it, If the other process got this address by kmalloc(), this illegal value "LIST_POISON1" will cause "general protection fault" error. Thanks, Liwei. > > Thanks, >
[PATCH v11 12/28] media: platform: Use generic rounding helpers
Use clamp() to replace mtk_jpeg_bound_align_image() and round() to
replace mtk_jpeg_align().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 41 +--
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 8 ++--
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 5 ---
3 files changed, 15 insertions(+), 39 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 0153d57af466..980500be027b 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -151,25 +151,6 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct
mtk_jpeg_ctx *ctx,
return NULL;
}
-static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
- unsigned int wmax, unsigned int walign,
- u32 *h, unsigned int hmin,
- unsigned int hmax, unsigned int halign)
-{
- int width, height, w_step, h_step;
-
- width = *w;
- height = *h;
- w_step = 1 << walign;
- h_step = 1 << halign;
-
- v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
- if (*w < width && (*w + w_step) <= wmax)
- *w += w_step;
- if (*h < height && (*h + h_step) <= hmax)
- *h += h_step;
-}
-
static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
struct v4l2_format *f)
{
@@ -211,24 +192,24 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[0];
- mtk_jpeg_bound_align_image(_mp->width, MTK_JPEG_MIN_WIDTH,
- MTK_JPEG_MAX_WIDTH, 0,
- _mp->height, MTK_JPEG_MIN_HEIGHT,
- MTK_JPEG_MAX_HEIGHT, 0);
+ pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
+ MTK_JPEG_MAX_HEIGHT);
+ pix_mp->width = clamp(pix_mp->width, MTK_JPEG_MIN_WIDTH,
+ MTK_JPEG_MAX_WIDTH);
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
- pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
+ pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
goto end;
}
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
- mtk_jpeg_bound_align_image(_mp->width, MTK_JPEG_MIN_WIDTH,
- MTK_JPEG_MAX_WIDTH, fmt->h_align,
- _mp->height, MTK_JPEG_MIN_HEIGHT,
- MTK_JPEG_MAX_HEIGHT, fmt->v_align);
+ pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
+ MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
+ pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
+ MTK_JPEG_MIN_WIDTH, MTK_JPEG_MAX_WIDTH);
for (i = 0; i < fmt->colplanes; i++) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[i];
@@ -711,8 +692,8 @@ static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
{
bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
bs->end_addr = bs->str_addr +
-mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
- bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
+ round_up(vb2_get_plane_payload(src_buf, 0), 16);
+ bs->size = round_up(vb2_plane_size(src_buf, 0), 128);
}
static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
index ddf0dfa78e20..68abcfd7494d 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
@@ -153,10 +153,10 @@ static int mtk_jpeg_calc_dst_size(struct
mtk_jpeg_dec_param *param)
param->sampling_w[i];
/* output format is 420/422 */
param->comp_w[i] = padding_w >> brz_w[i];
- param->comp_w[i] = mtk_jpeg_align(param->comp_w[i],
- MTK_JPEG_DCTSIZE);
- param->img_stride[i] = i ? mtk_jpeg_align(param->comp_w[i], 16)
- : mtk_jpeg_align(param->comp_w[i], 32);
+ param->comp_w[i] = round_up(param->comp_w[i],
+ MTK_JPEG_DCTSIZE);
+ param->img_stride[i] = i ?
[PATCH v11 09/28] media: platform: Cancel the last frame handling flow
There is no need to queue an empty buffer for signaling a last frame,
because all frames are separate from each other in JPEG.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 46 +--
1 file changed, 2 insertions(+), 44 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 9baeeacb4452..ffb486e537b6 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -55,15 +55,9 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
-enum {
- MTK_JPEG_BUF_FLAGS_INIT = 0,
- MTK_JPEG_BUF_FLAGS_LAST_FRAME = 1,
-};
-
struct mtk_jpeg_src_buf {
struct vb2_v4l2_buffer b;
struct list_head list;
- int flags;
struct mtk_jpeg_dec_param dec_param;
};
@@ -501,31 +495,6 @@ static int mtk_jpeg_s_selection(struct file *file, void
*priv,
return 0;
}
-static int mtk_jpeg_qbuf(struct file *file, void *priv, struct v4l2_buffer
*buf)
-{
- struct v4l2_fh *fh = file->private_data;
- struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
- struct vb2_queue *vq;
- struct vb2_buffer *vb;
- struct mtk_jpeg_src_buf *jpeg_src_buf;
-
- if (buf->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
- goto end;
-
- vq = v4l2_m2m_get_vq(fh->m2m_ctx, buf->type);
- if (buf->index >= vq->num_buffers) {
- dev_err(ctx->jpeg->dev, "buffer index out of range\n");
- return -EINVAL;
- }
-
- vb = vb2_get_buffer(vq, buf->index);
- jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(vb);
- jpeg_src_buf->flags = (buf->m.planes[0].bytesused == 0) ?
- MTK_JPEG_BUF_FLAGS_LAST_FRAME : MTK_JPEG_BUF_FLAGS_INIT;
-end:
- return v4l2_m2m_qbuf(file, fh->m2m_ctx, buf);
-}
-
static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_querycap= mtk_jpeg_querycap,
.vidioc_enum_fmt_vid_cap= mtk_jpeg_enum_fmt_vid_cap,
@@ -536,7 +505,7 @@ static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_g_fmt_vid_out_mplane= mtk_jpeg_g_fmt_vid_mplane,
.vidioc_s_fmt_vid_cap_mplane= mtk_jpeg_s_fmt_vid_cap_mplane,
.vidioc_s_fmt_vid_out_mplane= mtk_jpeg_s_fmt_vid_out_mplane,
- .vidioc_qbuf= mtk_jpeg_qbuf,
+ .vidioc_qbuf= v4l2_m2m_ioctl_qbuf,
.vidioc_subscribe_event = mtk_jpeg_subscribe_event,
.vidioc_g_selection = mtk_jpeg_g_selection,
.vidioc_s_selection = mtk_jpeg_s_selection,
@@ -676,10 +645,6 @@ static void mtk_jpeg_buf_queue(struct vb2_buffer *vb)
param = _src_buf->dec_param;
memset(param, 0, sizeof(*param));
- if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
- v4l2_dbg(1, debug, >v4l2_dev, "Got eos\n");
- goto end;
- }
header_valid = mtk_jpeg_parse(param, (u8 *)vb2_plane_vaddr(vb, 0),
vb2_get_plane_payload(vb, 0));
if (!header_valid) {
@@ -792,19 +757,12 @@ static void mtk_jpeg_device_run(void *priv)
struct mtk_jpeg_src_buf *jpeg_src_buf;
struct mtk_jpeg_bs bs;
struct mtk_jpeg_fb fb;
- int i, ret;
+ int ret;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(_buf->vb2_buf);
- if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
- for (i = 0; i < dst_buf->vb2_buf.num_planes; i++)
- vb2_set_plane_payload(_buf->vb2_buf, i, 0);
- buf_state = VB2_BUF_STATE_DONE;
- goto dec_end;
- }
-
if (mtk_jpeg_check_resolution_change(ctx, _src_buf->dec_param)) {
mtk_jpeg_queue_src_chg_event(ctx);
ctx->state = MTK_JPEG_SOURCE_CHANGE;
--
2.18.0
[PATCH v11 13/28] media: platform: Change MTK_JPEG_COMP_MAX macro definition location
Move MTK_JPEG_COMP_MAX definition to mtk_jpeg_core.h file, because it is used by mtk_jpeg_core.c file. Reviewed-by: Tomasz Figa Signed-off-by: Xia Jiang --- v11: no changes --- drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 ++ drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index c9f5162d2924..4d62438963c0 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -15,6 +15,8 @@ #define MTK_JPEG_NAME "mtk-jpeg" +#define MTK_JPEG_COMP_MAX 3 + #define MTK_JPEG_FMT_FLAG_DEC_OUTPUT BIT(0) #define MTK_JPEG_FMT_FLAG_DEC_CAPTURE BIT(1) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h index 2945da842dfa..21ec8f96797f 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h @@ -8,7 +8,6 @@ #ifndef _MTK_JPEG_REG_H #define _MTK_JPEG_REG_H -#define MTK_JPEG_COMP_MAX 3 #define MTK_JPEG_BLOCK_MAX 10 #define MTK_JPEG_DCTSIZE 8 -- 2.18.0
[PATCH v11 11/28] media: platform: Stylistic changes for improving code quality
Change register offset hex numerals from uppercase to lowercase. Change data type of max/min width/height from integer to unsigned integer. Reviewed-by: Tomasz Figa Signed-off-by: Xia Jiang --- v11: no changes --- .../media/platform/mtk-jpeg/mtk_jpeg_core.h| 8 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 18 +- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index 320c4f8a014a..c9f5162d2924 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -21,10 +21,10 @@ #define MTK_JPEG_FMT_TYPE_OUTPUT 1 #define MTK_JPEG_FMT_TYPE_CAPTURE 2 -#define MTK_JPEG_MIN_WIDTH 32 -#define MTK_JPEG_MIN_HEIGHT32 -#define MTK_JPEG_MAX_WIDTH 8192 -#define MTK_JPEG_MAX_HEIGHT8192 +#define MTK_JPEG_MIN_WIDTH 32U +#define MTK_JPEG_MIN_HEIGHT32U +#define MTK_JPEG_MAX_WIDTH 8192U +#define MTK_JPEG_MAX_HEIGHT8192U #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h index 94db04e9cdb6..2945da842dfa 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h @@ -20,29 +20,29 @@ #define BIT_INQST_MASK_ALLIRQ 0x37 #define JPGDEC_REG_RESET 0x0090 -#define JPGDEC_REG_BRZ_FACTOR 0x00F8 -#define JPGDEC_REG_DU_NUM 0x00FC +#define JPGDEC_REG_BRZ_FACTOR 0x00f8 +#define JPGDEC_REG_DU_NUM 0x00fc #define JPGDEC_REG_DEST_ADDR0_Y0x0140 #define JPGDEC_REG_DEST_ADDR0_U0x0144 #define JPGDEC_REG_DEST_ADDR0_V0x0148 -#define JPGDEC_REG_DEST_ADDR1_Y0x014C +#define JPGDEC_REG_DEST_ADDR1_Y0x014c #define JPGDEC_REG_DEST_ADDR1_U0x0150 #define JPGDEC_REG_DEST_ADDR1_V0x0154 #define JPGDEC_REG_STRIDE_Y0x0158 -#define JPGDEC_REG_STRIDE_UV 0x015C +#define JPGDEC_REG_STRIDE_UV 0x015c #define JPGDEC_REG_IMG_STRIDE_Y0x0160 #define JPGDEC_REG_IMG_STRIDE_UV 0x0164 -#define JPGDEC_REG_WDMA_CTRL 0x016C +#define JPGDEC_REG_WDMA_CTRL 0x016c #define JPGDEC_REG_PAUSE_MCU_NUM 0x0170 -#define JPGDEC_REG_OPERATION_MODE 0x017C +#define JPGDEC_REG_OPERATION_MODE 0x017c #define JPGDEC_REG_FILE_ADDR 0x0200 -#define JPGDEC_REG_COMP_ID 0x020C +#define JPGDEC_REG_COMP_ID 0x020c #define JPGDEC_REG_TOTAL_MCU_NUM 0x0210 #define JPGDEC_REG_COMP0_DATA_UNIT_NUM 0x0224 -#define JPGDEC_REG_DU_CTRL 0x023C +#define JPGDEC_REG_DU_CTRL 0x023c #define JPGDEC_REG_TRIG0x0240 #define JPGDEC_REG_FILE_BRP0x0248 -#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024C +#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024c #define JPGDEC_REG_QT_ID 0x0270 #define JPGDEC_REG_INTERRUPT_STATUS0x0274 #define JPGDEC_REG_STATUS 0x0278 -- 2.18.0
[PATCH v11 00/28] Add support for mt2701 JPEG ENC support
This patchset add support for mt2701 JPEG ENC support. This is the compliance test result for jpeg dec and enc. The JPEG dec log: v4l2-compliance -d /dev/video0 v4l2-compliance SHA: c7f03287bbd64c168975e7ff3192e6fd3b507686, 32 bits, 32-bit time_t Compliance test for mtk-jpeg-dec device /dev/video0: Driver Info: Driver name : mtk-jpeg-dec Card type: mtk-jpeg-dec Bus info : platform:15004000.jpegdec Driver version : 5.8.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected JPEG Decoder Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK test invalid ioctls: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK test Requests: OK (Not Supported) Total for mtk-jpeg-dec device /dev/video0: 45, Succeeded: 45, Failed: 0, Warnings: 0 The JPEG enc log: v4l2-compliance -d /dev/video1 v4l2-compliance SHA: c7f03287bbd64c168975e7ff3192e6fd3b507686, 32 bits, 32-bit time_t Compliance test for mtk-jpeg-enc device /dev/video1: Driver Info: Driver name : mtk-jpeg-enc Card type: mtk-jpeg-enc Bus info : platform:1500a000.jpegenc Driver version : 5.8.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Detected JPEG Encoder Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video1 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK test invalid ioctls: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
[PATCH v11 06/28] media: platform: Delete the resetting hardware flow in the system PM ops
Delete the resetting hardware flow in suspend and resume function
because that resetting operation will be done in device_run().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index fb624385969e..7f74597262fc 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1191,7 +1191,6 @@ static __maybe_unused int mtk_jpeg_pm_suspend(struct
device *dev)
{
struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
- mtk_jpeg_dec_reset(jpeg->dec_reg_base);
mtk_jpeg_clk_off(jpeg);
return 0;
@@ -1202,7 +1201,6 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct
device *dev)
struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
mtk_jpeg_clk_on(jpeg);
- mtk_jpeg_dec_reset(jpeg->dec_reg_base);
return 0;
}
--
2.18.0
[PATCH v11 28/28] media: platform: Add jpeg enc feature
Add mtk jpeg encode v4l2 driver based on jpeg decode, because that jpeg
decode and encode have great similarities with function operation.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/Makefile | 5 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 351 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 17 +
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 154
.../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h | 91 +
5 files changed, 614 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index 48516dcf96e6..76c33aad0f3f 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o \
+mtk_jpeg_dec_hw.o \
+mtk_jpeg_dec_parse.o \
+mtk_jpeg_enc_hw.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 3d95c7f0a22d..1c7fff6a84df 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -3,6 +3,7 @@
* Copyright (c) 2016 MediaTek Inc.
* Author: Ming Hsiu Tsai
* Rick Chang
+ * Xia Jiang
*/
#include
@@ -23,10 +24,59 @@
#include
#include
+#include "mtk_jpeg_enc_hw.h"
#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
#include "mtk_jpeg_dec_parse.h"
+static struct mtk_jpeg_fmt mtk_jpeg_enc_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .colplanes = 1,
+ .flags = MTK_JPEG_FMT_FLAG_CAPTURE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_NV12M,
+ .hw_format = JPEG_ENC_YUV_FORMAT_NV12,
+ .h_sample = {4, 4},
+ .v_sample = {4, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_NV21M,
+ .hw_format = JEPG_ENC_YUV_FORMAT_NV21,
+ .h_sample = {4, 4},
+ .v_sample = {4, 2},
+ .colplanes = 2,
+ .h_align= 4,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .hw_format = JPEG_ENC_YUV_FORMAT_YUYV,
+ .h_sample = {8},
+ .v_sample = {4},
+ .colplanes = 1,
+ .h_align= 5,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .hw_format = JPEG_ENC_YUV_FORMAT_YVYU,
+ .h_sample = {8},
+ .v_sample = {4},
+ .colplanes = 1,
+ .h_align= 5,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_OUTPUT,
+ },
+};
+
static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
@@ -53,6 +103,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
},
};
+#define MTK_JPEG_ENC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_enc_formats)
#define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
struct mtk_jpeg_src_buf {
@@ -64,6 +115,11 @@ struct mtk_jpeg_src_buf {
static int debug;
module_param(debug, int, 0644);
+static inline struct mtk_jpeg_ctx *ctrl_to_ctx(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl->handler, struct mtk_jpeg_ctx, ctrl_hdl);
+}
+
static inline struct mtk_jpeg_ctx *mtk_jpeg_fh_to_ctx(struct v4l2_fh *fh)
{
return container_of(fh, struct mtk_jpeg_ctx, fh);
@@ -88,6 +144,53 @@ static int mtk_jpeg_querycap(struct file *file, void *priv,
return 0;
}
+static int vidioc_jpeg_enc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct mtk_jpeg_ctx *ctx = ctrl_to_ctx(ctrl);
+
+ switch (ctrl->id) {
+ case V4L2_CID_JPEG_RESTART_INTERVAL:
+ ctx->restart_interval = ctrl->val;
+ break;
+ case V4L2_CID_JPEG_COMPRESSION_QUALITY:
+ ctx->enc_quality = ctrl->val;
+ break;
+ case V4L2_CID_JPEG_ACTIVE_MARKER:
+ ctx->enable_exif = ctrl->val & V4L2_JPEG_ACTIVE_MARKER_APP1;
+
[PATCH v11 27/28] media: platform: Using the variant structure to contain the varability between dec and enc
Add varability which would be used between jpeg dec and enc to a match
data structure, it will make the code linear.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 113 +++---
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 36 +-
2 files changed, 104 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 3d1383d2eac4..3d95c7f0a22d 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -80,8 +80,8 @@ static int mtk_jpeg_querycap(struct file *file, void *priv,
{
struct mtk_jpeg_dev *jpeg = video_drvdata(file);
- strscpy(cap->driver, MTK_JPEG_NAME " decoder", sizeof(cap->driver));
- strscpy(cap->card, MTK_JPEG_NAME " decoder", sizeof(cap->card));
+ strscpy(cap->driver, jpeg->variant->dev_name, sizeof(cap->driver));
+ strscpy(cap->card, jpeg->variant->dev_name, sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
dev_name(jpeg->dev));
@@ -112,15 +112,23 @@ static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt
*mtk_jpeg_formats, int n,
static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
-f, MTK_JPEG_FMT_FLAG_CAPTURE);
+ struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
+
+ return mtk_jpeg_enum_fmt(jpeg->variant->formats,
+jpeg->variant->num_formats, f,
+MTK_JPEG_FMT_FLAG_CAPTURE);
}
static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
-f, MTK_JPEG_FMT_FLAG_OUTPUT);
+ struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
+
+ return mtk_jpeg_enum_fmt(jpeg->variant->formats,
+jpeg->variant->num_formats, f,
+MTK_JPEG_FMT_FLAG_OUTPUT);
}
static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
@@ -244,10 +252,11 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file
*file, void *priv,
struct v4l2_format *f)
{
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
- MTK_JPEG_DEC_NUM_FORMATS,
+ fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+ jpeg->variant->num_formats,
f->fmt.pix_mp.pixelformat,
MTK_JPEG_FMT_FLAG_CAPTURE);
if (!fmt)
@@ -272,10 +281,11 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file
*file, void *priv,
struct v4l2_format *f)
{
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
- MTK_JPEG_DEC_NUM_FORMATS,
+ fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+ jpeg->variant->num_formats,
f->fmt.pix_mp.pixelformat,
MTK_JPEG_FMT_FLAG_OUTPUT);
if (!fmt)
@@ -316,9 +326,8 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
return -EBUSY;
}
-
- q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
- MTK_JPEG_DEC_NUM_FORMATS,
+ q_data->fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+ jpeg->variant->num_formats,
pix_mp->pixelformat, fmt_type);
q_data->pix_mp.width = pix_mp->width;
q_data->pix_mp.height = pix_mp->height;
@@ -519,9 +528,10 @@ static bool mtk_jpeg_check_resolution_change(struct
mtk_jpeg_ctx *ctx,
}
q_data = >cap_q;
- if (q_data->fmt != mtk_jpeg_find_format(mtk_jpeg_dec_formats,
- MTK_JPEG_DEC_NUM_FORMATS, param->dst_fourcc,
- MTK_JPEG_FMT_FLAG_CAPTURE)) {
+ if (q_data->fmt !=
+ mtk_jpeg_find_format(jpeg->variant->formats,
+jpeg->variant->num_formats, param->dst_fourcc,
+
[PATCH v11 19/28] media: platform: Redefinition of mtk_jpeg_q_data structure
The standard v4l2_pix_format_mplane structure contains width/height/
sizeimage/bytesperline, so use v4l2_pix_format_mplane to replace them.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 101 ++
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 20 +---
2 files changed, 57 insertions(+), 64 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index b3e38ffd4e81..01f4656fe2b3 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -207,15 +207,15 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
q_data = mtk_jpeg_get_q_data(ctx, f->type);
- pix_mp->width = q_data->w;
- pix_mp->height = q_data->h;
+ pix_mp->width = q_data->pix_mp.width;
+ pix_mp->height = q_data->pix_mp.height;
pix_mp->field = V4L2_FIELD_NONE;
pix_mp->pixelformat = q_data->fmt->fourcc;
pix_mp->num_planes = q_data->fmt->colplanes;
- pix_mp->colorspace = ctx->colorspace;
- pix_mp->ycbcr_enc = ctx->ycbcr_enc;
- pix_mp->xfer_func = ctx->xfer_func;
- pix_mp->quantization = ctx->quantization;
+ pix_mp->colorspace = q_data->pix_mp.colorspace;
+ pix_mp->ycbcr_enc = q_data->pix_mp.ycbcr_enc;
+ pix_mp->xfer_func = q_data->pix_mp.xfer_func;
+ pix_mp->quantization = q_data->pix_mp.quantization;
v4l2_dbg(1, debug, >v4l2_dev, "(%d) g_fmt:%c%c%c%c wxh:%ux%u\n",
f->type,
@@ -228,8 +228,8 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
for (i = 0; i < pix_mp->num_planes; i++) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[i];
- pfmt->bytesperline = q_data->bytesperline[i];
- pfmt->sizeimage = q_data->sizeimage[i];
+ pfmt->bytesperline = q_data->pix_mp.plane_fmt[i].bytesperline;
+ pfmt->sizeimage = q_data->pix_mp.plane_fmt[i].sizeimage;
v4l2_dbg(1, debug, >v4l2_dev,
"plane[%d] bpl=%u, size=%u\n",
@@ -318,12 +318,12 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_formats,
MTK_JPEG_NUM_FORMATS,
pix_mp->pixelformat, fmt_type);
- q_data->w = pix_mp->width;
- q_data->h = pix_mp->height;
- ctx->colorspace = pix_mp->colorspace;
- ctx->ycbcr_enc = pix_mp->ycbcr_enc;
- ctx->xfer_func = pix_mp->xfer_func;
- ctx->quantization = pix_mp->quantization;
+ q_data->pix_mp.width = pix_mp->width;
+ q_data->pix_mp.height = pix_mp->height;
+ q_data->pix_mp.colorspace = pix_mp->colorspace;
+ q_data->pix_mp.ycbcr_enc = pix_mp->ycbcr_enc;
+ q_data->pix_mp.xfer_func = pix_mp->xfer_func;
+ q_data->pix_mp.quantization = pix_mp->quantization;
v4l2_dbg(1, debug, >v4l2_dev, "(%d) s_fmt:%c%c%c%c wxh:%ux%u\n",
f->type,
@@ -331,15 +331,18 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
(q_data->fmt->fourcc >> 8 & 0xff),
(q_data->fmt->fourcc >> 16 & 0xff),
(q_data->fmt->fourcc >> 24 & 0xff),
-q_data->w, q_data->h);
+q_data->pix_mp.width, q_data->pix_mp.height);
for (i = 0; i < q_data->fmt->colplanes; i++) {
- q_data->bytesperline[i] = pix_mp->plane_fmt[i].bytesperline;
- q_data->sizeimage[i] = pix_mp->plane_fmt[i].sizeimage;
+ q_data->pix_mp.plane_fmt[i].bytesperline =
+ pix_mp->plane_fmt[i].bytesperline;
+ q_data->pix_mp.plane_fmt[i].sizeimage =
+ pix_mp->plane_fmt[i].sizeimage;
v4l2_dbg(1, debug, >v4l2_dev,
"plane[%d] bpl=%u, size=%u\n",
-i, q_data->bytesperline[i], q_data->sizeimage[i]);
+i, q_data->pix_mp.plane_fmt[i].bytesperline,
+q_data->pix_mp.plane_fmt[i].sizeimage);
}
return 0;
@@ -404,15 +407,15 @@ static int mtk_jpeg_g_selection(struct file *file, void
*priv,
switch (s->target) {
case V4L2_SEL_TGT_COMPOSE:
case V4L2_SEL_TGT_COMPOSE_DEFAULT:
- s->r.width = ctx->out_q.w;
- s->r.height = ctx->out_q.h;
+ s->r.width = ctx->out_q.pix_mp.width;
+ s->r.height = ctx->out_q.pix_mp.height;
s->r.left = 0;
s->r.top = 0;
break;
case V4L2_SEL_TGT_COMPOSE_BOUNDS:
case V4L2_SEL_TGT_COMPOSE_PADDED:
- s->r.width = ctx->cap_q.w;
- s->r.height = ctx->cap_q.h;
+ s->r.width =
[PATCH v11 26/28] media: platform: Rename existing functions/defines/variables
Rename existing functions/defines/variables with a _dec prefix and
without dec_ prefix to prepare for the addition of the jpeg encoder
feature.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 172 +-
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 12 +-
.../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h | 5 +-
3 files changed, 97 insertions(+), 92 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 5e57aed2e90f..3d1383d2eac4 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -27,11 +27,11 @@
#include "mtk_jpeg_core.h"
#include "mtk_jpeg_dec_parse.h"
-static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
.colplanes = 1,
- .flags = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+ .flags = MTK_JPEG_FMT_FLAG_OUTPUT,
},
{
.fourcc = V4L2_PIX_FMT_YUV420M,
@@ -40,7 +40,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.colplanes = 3,
.h_align= 5,
.v_align= 4,
- .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+ .flags = MTK_JPEG_FMT_FLAG_CAPTURE,
},
{
.fourcc = V4L2_PIX_FMT_YUV422M,
@@ -49,11 +49,11 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.colplanes = 3,
.h_align= 5,
.v_align= 3,
- .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+ .flags = MTK_JPEG_FMT_FLAG_CAPTURE,
},
};
-#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
+#define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
struct mtk_jpeg_src_buf {
struct vb2_v4l2_buffer b;
@@ -112,15 +112,15 @@ static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt
*mtk_jpeg_formats, int n,
static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
-MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
+ return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
+f, MTK_JPEG_FMT_FLAG_CAPTURE);
}
static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
-MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
+ return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
+f, MTK_JPEG_FMT_FLAG_OUTPUT);
}
static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
@@ -246,9 +246,10 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+ fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+ MTK_JPEG_DEC_NUM_FORMATS,
f->fmt.pix_mp.pixelformat,
- MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
+ MTK_JPEG_FMT_FLAG_CAPTURE);
if (!fmt)
fmt = ctx->cap_q.fmt;
@@ -273,9 +274,10 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+ fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+ MTK_JPEG_DEC_NUM_FORMATS,
f->fmt.pix_mp.pixelformat,
- MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
+ MTK_JPEG_FMT_FLAG_OUTPUT);
if (!fmt)
fmt = ctx->out_q.fmt;
@@ -315,8 +317,8 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
}
- q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_formats,
- MTK_JPEG_NUM_FORMATS,
+ q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+ MTK_JPEG_DEC_NUM_FORMATS,
pix_mp->pixelformat, fmt_type);
q_data->pix_mp.width = pix_mp->width;
q_data->pix_mp.height = pix_mp->height;
@@ -358,7 +360,7 @@ static int mtk_jpeg_s_fmt_vid_out_mplane(struct file *file,
[PATCH v11 15/28] media: platform: Delete vidioc_s_selection ioctl of jpeg dec
JPEG dec does't support setting a compose rectangle, so remove
mtk_jpeg_dec_s_selection().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 22 ---
1 file changed, 22 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index db3a8b22dccd..9d1935d0782b 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -439,27 +439,6 @@ static int mtk_jpeg_g_selection(struct file *file, void
*priv,
return 0;
}
-static int mtk_jpeg_s_selection(struct file *file, void *priv,
- struct v4l2_selection *s)
-{
- struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
-
- if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
- return -EINVAL;
-
- switch (s->target) {
- case V4L2_SEL_TGT_COMPOSE:
- s->r.left = 0;
- s->r.top = 0;
- s->r.width = ctx->out_q.w;
- s->r.height = ctx->out_q.h;
- break;
- default:
- return -EINVAL;
- }
- return 0;
-}
-
static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_querycap= mtk_jpeg_querycap,
.vidioc_enum_fmt_vid_cap= mtk_jpeg_enum_fmt_vid_cap,
@@ -473,7 +452,6 @@ static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_qbuf= v4l2_m2m_ioctl_qbuf,
.vidioc_subscribe_event = mtk_jpeg_subscribe_event,
.vidioc_g_selection = mtk_jpeg_g_selection,
- .vidioc_s_selection = mtk_jpeg_s_selection,
.vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
.vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
--
2.18.0
[PATCH v11 20/28] media: platform: Change the colorspace of jpeg to the fixed value
Jpeg doesn't support colorspace conversion, so it shouldn't accept any other colorspace in S_FMT. Change the colorspace of jpeg to the fixed value. Reviewed-by: Tomasz Figa Signed-off-by: Xia Jiang --- v11: no changes --- .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 24 +-- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c index 01f4656fe2b3..0376bd3bdbbb 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c @@ -320,10 +320,10 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx, pix_mp->pixelformat, fmt_type); q_data->pix_mp.width = pix_mp->width; q_data->pix_mp.height = pix_mp->height; - q_data->pix_mp.colorspace = pix_mp->colorspace; - q_data->pix_mp.ycbcr_enc = pix_mp->ycbcr_enc; - q_data->pix_mp.xfer_func = pix_mp->xfer_func; - q_data->pix_mp.quantization = pix_mp->quantization; + q_data->pix_mp.colorspace = V4L2_COLORSPACE_SRGB; + q_data->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601; + q_data->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB; + q_data->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE; v4l2_dbg(1, debug, >v4l2_dev, "(%d) s_fmt:%c%c%c%c wxh:%ux%u\n", f->type, @@ -846,10 +846,10 @@ static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx *ctx) struct mtk_jpeg_q_data *q = >out_q; int i; - q->pix_mp.colorspace = V4L2_COLORSPACE_JPEG, - q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; - q->pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT; - q->pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT; + q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB; + q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601; + q->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE; + q->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB; q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, V4L2_PIX_FMT_JPEG, @@ -863,10 +863,10 @@ static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx *ctx) q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, V4L2_PIX_FMT_YUV420M, MTK_JPEG_FMT_FLAG_DEC_CAPTURE); - q->pix_mp.colorspace = V4L2_COLORSPACE_JPEG, - q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; - q->pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT; - q->pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT; + q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB; + q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601; + q->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE; + q->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB; q->pix_mp.width = MTK_JPEG_MIN_WIDTH; q->pix_mp.height = MTK_JPEG_MIN_HEIGHT; -- 2.18.0
[PATCH v11 21/28] media: platform: Refactor mtk_jpeg_set_default_params()
Call mtk_jpeg_try_fmt_mplane() to replace the original computation of
sizeimage and bytesperline, because that mtk_jpeg_try_fmt_mplane()
already did it.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 0376bd3bdbbb..7881e9c93df7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -844,7 +844,6 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx *ctx)
{
struct mtk_jpeg_q_data *q = >out_q;
- int i;
q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB;
q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601;
@@ -856,8 +855,7 @@ static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx
*ctx)
MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
q->pix_mp.width = MTK_JPEG_MIN_WIDTH;
q->pix_mp.height = MTK_JPEG_MIN_HEIGHT;
- q->pix_mp.plane_fmt[0].bytesperline = 0;
- q->pix_mp.plane_fmt[0].sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
+ mtk_jpeg_try_fmt_mplane(>pix_mp, q->fmt);
q = >cap_q;
q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
@@ -870,13 +868,7 @@ static void mtk_jpeg_set_default_params(struct
mtk_jpeg_ctx *ctx)
q->pix_mp.width = MTK_JPEG_MIN_WIDTH;
q->pix_mp.height = MTK_JPEG_MIN_HEIGHT;
- for (i = 0; i < q->fmt->colplanes; i++) {
- u32 stride = q->pix_mp.width * q->fmt->h_sample[i] / 4;
- u32 h = q->pix_mp.height * q->fmt->v_sample[i] / 4;
-
- q->pix_mp.plane_fmt[i].bytesperline = stride;
- q->pix_mp.plane_fmt[i].sizeimage = stride * h;
- }
+ mtk_jpeg_try_fmt_mplane(>pix_mp, q->fmt);
}
static int mtk_jpeg_open(struct file *file)
--
2.18.0
[PATCH v11 16/28] media: platform: Change the maximum width and height supported by JPEG dec
The maximum width and height supported by JPEG dec is 65535, so change them from 8192 to 65535. Reviewed-by: Tomasz Figa Signed-off-by: Xia Jiang --- v11: no changes --- drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h index 9b46b0507187..6106cfaba311 100644 --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h @@ -25,8 +25,8 @@ #define MTK_JPEG_MIN_WIDTH 32U #define MTK_JPEG_MIN_HEIGHT32U -#define MTK_JPEG_MAX_WIDTH 8192U -#define MTK_JPEG_MAX_HEIGHT8192U +#define MTK_JPEG_MAX_WIDTH 65535U +#define MTK_JPEG_MAX_HEIGHT65535U #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024) -- 2.18.0
[PATCH v11 17/28] media: platform: Refactor mtk_jpeg_try_fmt_mplane()
The function of mtk_jpeg_adjust_fmt_mplane() equals
mtk_jpeg_g_fmt_vid_mplane(), so use mtk_jpeg_g_fmt_vid_mplane() to
replace it .
Delete the unused ctx parameter.
Using fourcc to distinguish between different formats is more generic,
because that jpeg enc will also use it.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 49 ++-
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 9d1935d0782b..aba583f03ef1 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -151,44 +151,17 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct
mtk_jpeg_ctx *ctx,
return NULL;
}
-static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
- struct v4l2_format *f)
+static int mtk_jpeg_try_fmt_mplane(struct v4l2_pix_format_mplane *pix_mp,
+ struct mtk_jpeg_fmt *fmt)
{
- struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
- struct mtk_jpeg_q_data *q_data;
- int i;
-
- q_data = mtk_jpeg_get_q_data(ctx, f->type);
-
- pix_mp->width = q_data->w;
- pix_mp->height = q_data->h;
- pix_mp->pixelformat = q_data->fmt->fourcc;
- pix_mp->num_planes = q_data->fmt->colplanes;
-
- for (i = 0; i < pix_mp->num_planes; i++) {
- pix_mp->plane_fmt[i].bytesperline = q_data->bytesperline[i];
- pix_mp->plane_fmt[i].sizeimage = q_data->sizeimage[i];
- }
-}
-
-static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
- struct mtk_jpeg_fmt *fmt,
- struct mtk_jpeg_ctx *ctx, int q_type)
-{
- struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
int i;
pix_mp->field = V4L2_FIELD_NONE;
- if (ctx->state != MTK_JPEG_INIT) {
- mtk_jpeg_adjust_fmt_mplane(ctx, f);
- return 0;
- }
-
pix_mp->num_planes = fmt->colplanes;
pix_mp->pixelformat = fmt->fourcc;
- if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
+ if (fmt->fourcc == V4L2_PIX_FMT_JPEG) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[0];
pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
@@ -204,7 +177,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
return 0;
}
- /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
+ /* other fourcc */
pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
@@ -288,7 +261,12 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file
*file, void *priv,
(fmt->fourcc >> 16 & 0xff),
(fmt->fourcc >> 24 & 0xff));
- return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_CAPTURE);
+ if (ctx->state != MTK_JPEG_INIT) {
+ mtk_jpeg_g_fmt_vid_mplane(file, priv, f);
+ return 0;
+ }
+
+ return mtk_jpeg_try_fmt_mplane(>fmt.pix_mp, fmt);
}
static int mtk_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
@@ -309,7 +287,12 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file
*file, void *priv,
(fmt->fourcc >> 16 & 0xff),
(fmt->fourcc >> 24 & 0xff));
- return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_OUTPUT);
+ if (ctx->state != MTK_JPEG_INIT) {
+ mtk_jpeg_g_fmt_vid_mplane(file, priv, f);
+ return 0;
+ }
+
+ return mtk_jpeg_try_fmt_mplane(>fmt.pix_mp, fmt);
}
static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
--
2.18.0
[PATCH v11 08/28] media: platform: Add mechanism to handle jpeg hardware's locking up
There is a delayed work scheduled before starting the hardware and
canceled in the interrupt handler. If the delayed work is executed, it
resets the hardware and reports the failure to V4L2, so that the
execution can continue from next frames.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 25 +++
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 4 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index ee4aaf618551..9baeeacb4452 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -816,6 +816,9 @@ static void mtk_jpeg_device_run(void *priv)
if (ret < 0)
goto dec_end;
+ schedule_delayed_work(>job_timeout_work,
+ msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
+
mtk_jpeg_set_dec_src(ctx, _buf->vb2_buf, );
if (mtk_jpeg_set_dec_dst(ctx, _src_buf->dec_param,
_buf->vb2_buf, ))
goto dec_end;
@@ -911,6 +914,8 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
u32 dec_ret;
int i;
+ cancel_delayed_work(>job_timeout_work);
+
dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
@@ -1066,6 +1071,25 @@ static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
return PTR_ERR_OR_ZERO(jpeg->clk_jdec_smi);
}
+static void mtk_jpeg_job_timeout_work(struct work_struct *work)
+{
+ struct mtk_jpeg_dev *jpeg = container_of(work, struct mtk_jpeg_dev,
+job_timeout_work.work);
+ struct mtk_jpeg_ctx *ctx;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
+
+ ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+
+ mtk_jpeg_dec_reset(jpeg->dec_reg_base);
+
+ pm_runtime_put(jpeg->dev);
+
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
+}
static int mtk_jpeg_probe(struct platform_device *pdev)
{
struct mtk_jpeg_dev *jpeg;
@@ -1080,6 +1104,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
mutex_init(>lock);
spin_lock_init(>hw_lock);
jpeg->dev = >dev;
+ INIT_DELAYED_WORK(>job_timeout_work, mtk_jpeg_job_timeout_work);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
jpeg->dec_reg_base = devm_ioremap_resource(>dev, res);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 999bd1427809..320c4f8a014a 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -28,6 +28,8 @@
#define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
+#define MTK_JPEG_HW_TIMEOUT_MSEC 1000
+
enum mtk_jpeg_ctx_state {
MTK_JPEG_INIT = 0,
MTK_JPEG_RUNNING,
@@ -48,6 +50,7 @@ enum mtk_jpeg_ctx_state {
* @clk_jdec: JPEG hw working clock
* @clk_jdec_smi: JPEG SMI bus clock
* @larb: SMI device
+ * @job_timeout_work: IRQ timeout structure
*/
struct mtk_jpeg_dev {
struct mutexlock;
@@ -62,6 +65,7 @@ struct mtk_jpeg_dev {
struct clk *clk_jdec;
struct clk *clk_jdec_smi;
struct device *larb;
+ struct delayed_work job_timeout_work;
};
/**
--
2.18.0
[PATCH v11 24/28] arm: dts: mt2701: Add jpeg enc device tree node
Add jpeg enc device tree node.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
arch/arm/boot/dts/mt2701.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8d43a502aada..1c1c2132234f 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -568,6 +568,19 @@
< MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = < MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <>;
+ iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
+< MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
--
2.18.0
[PATCH v11 10/28] media: platform: Delete zeroing the reserved fields
Delete zeroing the reserved fields because that the core already
does it.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index ffb486e537b6..0153d57af466 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -198,7 +198,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
- memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->field = V4L2_FIELD_NONE;
if (ctx->state != MTK_JPEG_INIT) {
@@ -217,7 +216,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
_mp->height, MTK_JPEG_MIN_HEIGHT,
MTK_JPEG_MAX_HEIGHT, 0);
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
@@ -237,7 +235,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
u32 h = pix_mp->height * fmt->v_sample[i] / 4;
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
@@ -270,7 +267,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
q_data = mtk_jpeg_get_q_data(ctx, f->type);
- memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->width = q_data->w;
pix_mp->height = q_data->h;
pix_mp->field = V4L2_FIELD_NONE;
@@ -294,7 +290,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file,
void *priv,
pfmt->bytesperline = q_data->bytesperline[i];
pfmt->sizeimage = q_data->sizeimage[i];
- memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
v4l2_dbg(1, debug, >v4l2_dev,
"plane[%d] bpl=%u, size=%u\n",
--
2.18.0
[PATCH v11 14/28] media: platform: Delete redundant code and add annotation for an enum
Delete unused member variables annotation.
Delete unused variable definition.
Delete redundant log print, because V4L2 debug logs already print it.
Add annotation for enum mtk_jpeg_ctx_state.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 15 ++-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 ++--
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 980500be027b..db3a8b22dccd 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -176,14 +176,13 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
struct mtk_jpeg_ctx *ctx, int q_type)
{
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
- struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
pix_mp->field = V4L2_FIELD_NONE;
if (ctx->state != MTK_JPEG_INIT) {
mtk_jpeg_adjust_fmt_mplane(ctx, f);
- goto end;
+ return 0;
}
pix_mp->num_planes = fmt->colplanes;
@@ -202,7 +201,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
- goto end;
+ return 0;
}
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
@@ -219,16 +218,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
-end:
- v4l2_dbg(2, debug, >v4l2_dev, "wxh:%ux%u\n",
-pix_mp->width, pix_mp->height);
- for (i = 0; i < pix_mp->num_planes; i++) {
- v4l2_dbg(2, debug, >v4l2_dev,
-"plane[%d] bpl=%u, size=%u\n",
-i,
-pix_mp->plane_fmt[i].bytesperline,
-pix_mp->plane_fmt[i].sizeimage);
- }
return 0;
}
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 4d62438963c0..9b46b0507187 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -32,6 +32,12 @@
#define MTK_JPEG_HW_TIMEOUT_MSEC 1000
+/**
+ * enum mtk_jpeg_ctx_state - states of the context state machine
+ * @MTK_JPEG_INIT: current state is initialized
+ * @MTK_JPEG_RUNNING: current state is running
+ * @MTK_JPEG_SOURCE_CHANGE:current state is source resolution change
+ */
enum mtk_jpeg_ctx_state {
MTK_JPEG_INIT = 0,
MTK_JPEG_RUNNING,
@@ -113,9 +119,7 @@ struct mtk_jpeg_q_data {
* @out_q: source (output) queue information
* @cap_q: destination (capture) queue queue information
* @fh:V4L2 file handle
- * @dec_param parameters for HW decoding
* @state: state of the context
- * @header_valid: set if header has been parsed and valid
* @colorspace: enum v4l2_colorspace; supplemental to pixelformat
* @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
* @quantization: enum v4l2_quantization, colorspace quantization
--
2.18.0
[PATCH v11 25/28] media: platform: Rename jpeg dec file name
Rename the files which are for decode feature. This is preparing
path since the jpeg enc patch will be added later.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/Makefile | 2 +-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
.../platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}| 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}| 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.c => mtk_jpeg_dec_parse.c} | 2 +-
.../mtk-jpeg/{mtk_jpeg_parse.h => mtk_jpeg_dec_parse.h} | 2 +-
.../platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h} | 0
7 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}
(99%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}
(98%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.c =>
mtk_jpeg_dec_parse.c} (98%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.h =>
mtk_jpeg_dec_parse.h} (92%)
rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h}
(100%)
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
index 92a4fc046bfe..48516dcf96e6 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 47d570f32e3f..5e57aed2e90f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -23,9 +23,9 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
index 68abcfd7494d..afbbfd5d02bc 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
@@ -9,7 +9,7 @@
#include
#include
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
#define MTK_JPEG_DUNUM_MASK(val) (((val) - 1) & 0x3)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
index 7b0687f8f4b6..1cc37dbfc8e7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
@@ -11,7 +11,7 @@
#include
#include "mtk_jpeg_core.h"
-#include "mtk_jpeg_reg.h"
+#include "mtk_jpeg_dec_reg.h"
enum {
MTK_JPEG_DEC_RESULT_EOF_DONE= 0,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
index f862d38f3af7..b95c45791c29 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
@@ -8,7 +8,7 @@
#include
#include
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
#define TEM0x01
#define SOF0 0xc0
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
similarity index 92%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
index 0a48eeabaff2..2918f15811f8 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
@@ -8,7 +8,7 @@
#ifndef _MTK_JPEG_PARSE_H
#define _MTK_JPEG_PARSE_H
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
bool mtk_jpeg_parse(struct mtk_jpeg_dec_param *param, u8 *src_addr_va,
u32 src_size);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
similarity index 100%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
--
2.18.0
[PATCH v11 22/28] media: platform: Change the call functions of getting/enable/disable the jpeg's clock
Use the generic clk_bulk_* helpers to enable and disable clocks.
Signed-off-by: Xia Jiang
---
v11: specify the names of the clocks in the driver
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 28 +--
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 +++---
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 7881e9c93df7..47d570f32e3f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -783,14 +783,15 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
ret = mtk_smi_larb_get(jpeg->larb);
if (ret)
dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
- clk_prepare_enable(jpeg->clk_jdec_smi);
- clk_prepare_enable(jpeg->clk_jdec);
+
+ ret = clk_bulk_prepare_enable(jpeg->num_clks, jpeg->clks);
+ if (ret)
+ dev_err(jpeg->dev, "Failed to open jpeg clk: %d\n", ret);
}
static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
- clk_disable_unprepare(jpeg->clk_jdec);
- clk_disable_unprepare(jpeg->clk_jdec_smi);
+ clk_bulk_disable_unprepare(jpeg->num_clks, jpeg->clks);
mtk_smi_larb_put(jpeg->larb);
}
@@ -935,10 +936,16 @@ static const struct v4l2_file_operations mtk_jpeg_fops = {
.mmap = v4l2_m2m_fop_mmap,
};
+static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
+ { .id = "jpgdec-smi" },
+ { .id = "jpgdec" },
+};
+
static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
{
struct device_node *node;
struct platform_device *pdev;
+ int ret;
node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
if (!node)
@@ -952,12 +959,15 @@ static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
jpeg->larb = >dev;
- jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
- if (IS_ERR(jpeg->clk_jdec))
- return PTR_ERR(jpeg->clk_jdec);
+ jpeg->clks = mt8173_jpeg_dec_clocks;
+ jpeg->num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks);
+ ret = devm_clk_bulk_get(jpeg->dev, jpeg->num_clks, jpeg->clks);
+ if (ret) {
+ dev_err(>dev, "failed to get jpeg clock:%d\n", ret);
+ return ret;
+ }
- jpeg->clk_jdec_smi = devm_clk_get(jpeg->dev, "jpgdec-smi");
- return PTR_ERR_OR_ZERO(jpeg->clk_jdec_smi);
+ return 0;
}
static void mtk_jpeg_job_timeout_work(struct work_struct *work)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 4c76a9dcc4b7..a54e1e82e655 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -52,8 +52,8 @@ enum mtk_jpeg_ctx_state {
* @alloc_ctx: videobuf2 memory allocator's context
* @dec_vdev: video device node for decoder mem2mem mode
* @dec_reg_base: JPEG registers mapping
- * @clk_jdec: JPEG hw working clock
- * @clk_jdec_smi: JPEG SMI bus clock
+ * @clks: clock names
+ * @num_clks: numbers of clock
* @larb: SMI device
* @job_timeout_work: IRQ timeout structure
*/
@@ -67,8 +67,8 @@ struct mtk_jpeg_dev {
void*alloc_ctx;
struct video_device *dec_vdev;
void __iomem*dec_reg_base;
- struct clk *clk_jdec;
- struct clk *clk_jdec_smi;
+ struct clk_bulk_data *clks;
+ int num_clks;
struct device *larb;
struct delayed_work job_timeout_work;
};
--
2.18.0
[PATCH v11 18/28] media: platform: Refactor mtk_jpeg_find_format()
Delete the unused ctx parameter.
Using mtk_jpeg_formats and num_formats parameters is more generic,
because that jpeg enc will also use it.
Delete the macro definition of MTK_JPEG_FMT_TYPE_OUTPUT and
MTK_JPEG_FMT_TYPE_CAPTURE, because that MTK_JPEG_FMT_FLAG_DEC_OUTPUT
and MTK_JPEG_FMT_FLAG_DEC_CAPTURE are enough.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 64 ++-
.../media/platform/mtk-jpeg/mtk_jpeg_core.h | 3 -
2 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index aba583f03ef1..b3e38ffd4e81 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -131,20 +131,17 @@ static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct
mtk_jpeg_ctx *ctx,
return >cap_q;
}
-static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct mtk_jpeg_ctx *ctx,
-u32 pixelformat,
-unsigned int fmt_type)
+static struct mtk_jpeg_fmt *
+mtk_jpeg_find_format(struct mtk_jpeg_fmt *mtk_jpeg_formats, int num_formats,
+u32 pixelformat, unsigned int fmt_type)
{
- unsigned int k, fmt_flag;
-
- fmt_flag = (fmt_type == MTK_JPEG_FMT_TYPE_OUTPUT) ?
- MTK_JPEG_FMT_FLAG_DEC_OUTPUT :
- MTK_JPEG_FMT_FLAG_DEC_CAPTURE;
+ unsigned int k;
+ struct mtk_jpeg_fmt *fmt;
- for (k = 0; k < MTK_JPEG_NUM_FORMATS; k++) {
- struct mtk_jpeg_fmt *fmt = _jpeg_formats[k];
+ for (k = 0; k < num_formats; k++) {
+ fmt = _jpeg_formats[k];
- if (fmt->fourcc == pixelformat && fmt->flags & fmt_flag)
+ if (fmt->fourcc == pixelformat && fmt->flags & fmt_type)
return fmt;
}
@@ -249,8 +246,9 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(ctx, f->fmt.pix_mp.pixelformat,
- MTK_JPEG_FMT_TYPE_CAPTURE);
+ fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+ f->fmt.pix_mp.pixelformat,
+ MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
if (!fmt)
fmt = ctx->cap_q.fmt;
@@ -275,8 +273,9 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
- fmt = mtk_jpeg_find_format(ctx, f->fmt.pix_mp.pixelformat,
- MTK_JPEG_FMT_TYPE_OUTPUT);
+ fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+ f->fmt.pix_mp.pixelformat,
+ MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
if (!fmt)
fmt = ctx->out_q.fmt;
@@ -296,13 +295,12 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file
*file, void *priv,
}
static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
-struct v4l2_format *f)
+struct v4l2_format *f, unsigned int fmt_type)
{
struct vb2_queue *vq;
struct mtk_jpeg_q_data *q_data = NULL;
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
struct mtk_jpeg_dev *jpeg = ctx->jpeg;
- unsigned int f_type;
int i;
vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
@@ -316,10 +314,10 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
return -EBUSY;
}
- f_type = V4L2_TYPE_IS_OUTPUT(f->type) ?
-MTK_JPEG_FMT_TYPE_OUTPUT : MTK_JPEG_FMT_TYPE_CAPTURE;
- q_data->fmt = mtk_jpeg_find_format(ctx, pix_mp->pixelformat, f_type);
+ q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_formats,
+ MTK_JPEG_NUM_FORMATS,
+ pix_mp->pixelformat, fmt_type);
q_data->w = pix_mp->width;
q_data->h = pix_mp->height;
ctx->colorspace = pix_mp->colorspace;
@@ -356,7 +354,8 @@ static int mtk_jpeg_s_fmt_vid_out_mplane(struct file *file,
void *priv,
if (ret)
return ret;
- return mtk_jpeg_s_fmt_mplane(mtk_jpeg_fh_to_ctx(priv), f);
+ return mtk_jpeg_s_fmt_mplane(mtk_jpeg_fh_to_ctx(priv), f,
+MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
}
static int mtk_jpeg_s_fmt_vid_cap_mplane(struct file *file, void *priv,
@@ -368,7 +367,8 @@ static int mtk_jpeg_s_fmt_vid_cap_mplane(struct file *file,
void *priv,
if (ret)
return ret;
- return
[PATCH v11 23/28] media: dt-bindings: Add jpeg enc device tree node document
Add jpeg enc device tree node document.
Reviewed-by: Rob Herring
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../bindings/media/mediatek-jpeg-encoder.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
new file mode 100644
index ..736be7cad385
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -0,0 +1,35 @@
+* MediaTek JPEG Encoder
+
+MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+Required properties:
+- compatible : "mediatek,mt2701-jpgenc"
+ followed by "mediatek,mtk-jpgenc"
+- reg : physical base address of the JPEG encoder registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+ Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
+- power-domains: a phandle to the power domain, see
+ Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+ Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details.
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+
+Example:
+ jpegenc: jpegenc@1500a000 {
+ compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+ reg = <0 0x1500a000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_IMG_VENC>;
+ clock-names = "jpgenc";
+ power-domains = < MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <>;
+ iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
+< MT2701_M4U_PORT_JPGENC_BSDMA>;
+ };
--
2.18.0
[PATCH v11 07/28] media: platform: Improve the implementation of the system PM ops
Add v4l2_m2m_suspend() function call in mtk_jpeg_suspend() to make sure
that the current frame is processed completely before suspend.
Add v4l2_m2m_resume() function call in mtk_jpeg_resume() to unblock the
driver from scheduling next frame.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c| 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 7f74597262fc..ee4aaf618551 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1207,24 +1207,22 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct
device *dev)
static __maybe_unused int mtk_jpeg_suspend(struct device *dev)
{
- int ret;
-
- if (pm_runtime_suspended(dev))
- return 0;
+ struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
- ret = mtk_jpeg_pm_suspend(dev);
- return ret;
+ v4l2_m2m_suspend(jpeg->m2m_dev);
+ return pm_runtime_force_suspend(dev);
}
static __maybe_unused int mtk_jpeg_resume(struct device *dev)
{
+ struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
int ret;
- if (pm_runtime_suspended(dev))
- return 0;
-
- ret = mtk_jpeg_pm_resume(dev);
+ ret = pm_runtime_force_resume(dev);
+ if (ret < 0)
+ return ret;
+ v4l2_m2m_resume(jpeg->m2m_dev);
return ret;
}
--
2.18.0
[PATCH v11 01/28] media: platform: Improve subscribe event flow for bug fixing
Let v4l2_ctrl_subscribe_event() do the job for other types except
V4L2_EVENT_SOURCE_CHANGE.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index f82a81a3bdee..4ad4a4b30a0e 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -446,9 +446,9 @@ static int mtk_jpeg_subscribe_event(struct v4l2_fh *fh,
switch (sub->type) {
case V4L2_EVENT_SOURCE_CHANGE:
return v4l2_src_change_event_subscribe(fh, sub);
- default:
- return -EINVAL;
}
+
+ return v4l2_ctrl_subscribe_event(fh, sub);
}
static int mtk_jpeg_g_selection(struct file *file, void *priv,
--
2.18.0
[PATCH v11 03/28] media: platform: Improve getting and requesting irq flow for bug fixing
Delete platform_get_resource operation for irq.
Return actual value rather than EINVAL when fail to get and request
irq.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 67a022d04df7..2677580941b0 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1103,12 +1103,10 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
return ret;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
dec_irq = platform_get_irq(pdev, 0);
- if (!res || dec_irq < 0) {
+ if (dec_irq < 0) {
dev_err(>dev, "Failed to get dec_irq %d.\n", dec_irq);
- ret = -EINVAL;
- return ret;
+ return dec_irq;
}
ret = devm_request_irq(>dev, dec_irq, mtk_jpeg_dec_irq, 0,
@@ -1116,7 +1114,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
if (ret) {
dev_err(>dev, "Failed to request dec_irq %d (%d)\n",
dec_irq, ret);
- ret = -EINVAL;
goto err_req_irq;
}
--
2.18.0
[PATCH v11 02/28] media: platform: Improve queue set up flow for bug fixing
Add checking created buffer size follow in mtk_jpeg_queue_setup().
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 4ad4a4b30a0e..67a022d04df7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -571,6 +571,13 @@ static int mtk_jpeg_queue_setup(struct vb2_queue *q,
if (!q_data)
return -EINVAL;
+ if (*num_planes) {
+ for (i = 0; i < *num_planes; i++)
+ if (sizes[i] < q_data->sizeimage[i])
+ return -EINVAL;
+ return 0;
+ }
+
*num_planes = q_data->fmt->colplanes;
for (i = 0; i < q_data->fmt->colplanes; i++) {
sizes[i] = q_data->sizeimage[i];
--
2.18.0
[PATCH v11 04/28] media: platform: Change the fixed device node number to unfixed value
The driver can be instantiated multiple times, e.g. for a decoder and
an encoder. Moreover, other drivers could coexist on the same system.
This makes the static video node number assignment pointless, so switch
to automatic assignment instead.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 2677580941b0..12609ca46fd9 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1154,7 +1154,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
jpeg->dec_vdev->device_caps = V4L2_CAP_STREAMING |
V4L2_CAP_VIDEO_M2M_MPLANE;
- ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, 3);
+ ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, -1);
if (ret) {
v4l2_err(>v4l2_dev, "Failed to register video device\n");
goto err_dec_vdev_register;
--
2.18.0
[PATCH v11 05/28] media: platform: Improve power on and power off flow
Call pm_runtime_get_sync() before starting a frame and then
pm_runtime_put() after completing it. This can save power for the time
between processing two frames.
Reviewed-by: Tomasz Figa
Signed-off-by: Xia Jiang
---
v11: no changes
---
.../media/platform/mtk-jpeg/mtk_jpeg_core.c | 27 +--
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 12609ca46fd9..fb624385969e 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct
mtk_jpeg_ctx *ctx,
return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
}
-static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
-{
- struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
- struct vb2_v4l2_buffer *vb;
- int ret = 0;
-
- ret = pm_runtime_get_sync(ctx->jpeg->dev);
- if (ret < 0)
- goto err;
-
- return 0;
-err:
- while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
- v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
- return ret;
-}
-
static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
{
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
@@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
-
- pm_runtime_put_sync(ctx->jpeg->dev);
}
static const struct vb2_ops mtk_jpeg_qops = {
@@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
.buf_queue = mtk_jpeg_buf_queue,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish= vb2_ops_wait_finish,
- .start_streaming= mtk_jpeg_start_streaming,
.stop_streaming = mtk_jpeg_stop_streaming,
};
@@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
struct mtk_jpeg_src_buf *jpeg_src_buf;
struct mtk_jpeg_bs bs;
struct mtk_jpeg_fb fb;
- int i;
+ int i, ret;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
return;
}
+ ret = pm_runtime_get_sync(jpeg->dev);
+ if (ret < 0)
+ goto dec_end;
+
mtk_jpeg_set_dec_src(ctx, _buf->vb2_buf, );
if (mtk_jpeg_set_dec_dst(ctx, _src_buf->dec_param,
_buf->vb2_buf, ))
goto dec_end;
@@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
v4l2_m2m_buf_done(src_buf, buf_state);
v4l2_m2m_buf_done(dst_buf, buf_state);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
+ pm_runtime_put(ctx->jpeg->dev);
return IRQ_HANDLED;
}
--
2.18.0
[PATCH 2/2] powerpc/topology: Override cpu_smt_mask
On Power9 a pair of cores can be presented by the firmware as a big-core
for backward compatibility reasons, with 4 threads per (small) core and 8
threads per big-core. cpu_smt_mask() should generally point to the cpu mask
of the (small)core.
In order to maintain userspace backward compatibility (with Power8 chips in
case of Power9) in enterprise Linux systems, the topology_sibling_cpumask
has to be set to big-core. Hence override the default cpu_smt_mask() to be
powerpc specific allowing for better scheduling behaviour on Power.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Michael Neuling
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Valentin Schneider
Cc: Dietmar Eggemann
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Vaidyanathan Srinivasan
Signed-off-by: Srikar Dronamraju
---
arch/powerpc/include/asm/cputhreads.h | 1 -
arch/powerpc/include/asm/smp.h| 13 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h
b/arch/powerpc/include/asm/cputhreads.h
index deb99fd6e060..98c8bd155bf9 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -23,7 +23,6 @@
extern int threads_per_core;
extern int threads_per_subcore;
extern int threads_shift;
-extern bool has_big_cores;
extern cpumask_t threads_core_mask;
#else
#define threads_per_core 1
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 9cd0765633c5..d4bc28accb28 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -131,6 +131,19 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
+extern bool has_big_cores;
+
+#define cpu_smt_mask cpu_smt_mask
+#ifdef CONFIG_SCHED_SMT
+static inline const struct cpumask *cpu_smt_mask(int cpu)
+{
+ if (has_big_cores)
+ return per_cpu(cpu_smallcore_map, cpu);
+
+ return per_cpu(cpu_sibling_map, cpu);
+}
+#endif /* CONFIG_SCHED_SMT */
+
/* Since OpenPIC has only 4 IPIs, we use slightly different message numbers.
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
--
2.18.2
Re: linux-next: build failure after merge of the security tree
On Thu, 30 Jul 2020, Stephen Rothwell wrote: > Hi James, > > On Thu, 30 Jul 2020 12:35:03 +1000 (AEST) James Morris > wrote: > > > > On Thu, 30 Jul 2020, Stephen Rothwell wrote: > > > > > > I am still applying the above patch ... > > > > > > The merge window is coming up fast ... is anything happening about this > > > failure? > > > > A new patch is coming, but I'm not sure this code has had enough review > > from the core VFS folk. > > > > Please drop secure_uffd_v5.9 for the time being. > > You just need to remove/revert it from your security tree > (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next-testing). Done. -- James Morris
[PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
most architectures. One of the users of cpu_smt_mask(), would be to
identify idle-cores. On Power9, a pair of cores can be presented by the
firmware as a big-core for backward compatibility reasons.
In order to maintain userspace backward compatibility with previous
versions of processor, (since Power8 had SMT8 cores), Power9 onwards there
is option to the firmware to advertise a pair of SMT4 cores as a fused
cores (referred to as the big_core mode in the Linux Kernel). On Power9
this pair shares the L2 cache as well. However, from the scheduler's point
of view, a core should be determined by SMT4. The load-balancer already
does this. Hence allow PowerPc architecture to override the default
cpu_smt_mask() to point to the SMT4 cores in a big_core mode.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Michael Neuling
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Valentin Schneider
Cc: Dietmar Eggemann
Cc: Mel Gorman
Cc: Vincent Guittot
Cc: Vaidyanathan Srinivasan
Signed-off-by: Srikar Dronamraju
---
include/linux/topology.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 608fa4aadf0e..ad03df1cc266 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -198,7 +198,7 @@ static inline int cpu_to_mem(int cpu)
#define topology_die_cpumask(cpu) cpumask_of(cpu)
#endif
-#ifdef CONFIG_SCHED_SMT
+#if defined(CONFIG_SCHED_SMT) && !defined(cpu_smt_mask)
static inline const struct cpumask *cpu_smt_mask(int cpu)
{
return topology_sibling_cpumask(cpu);
--
2.18.2
Re: [PATCH] riscv: Add sfence.vma after page table changed
On Tue, Aug 4, 2020 at 8:32 AM Greentime Hu wrote:
>
> This patch addes local_flush_tlb_page(addr) to use sfence.vma after the
s/addes/adds
> page table changed. That address will be used immediately in
> memset(nextp, 0, PAGE_SIZE) to cause this issue so we should add the
> sfence.vma before we use it.
Alternate version of this commit description can be:
Invalidate local TLB after both set_pet() and clear_pte() because the
address can be used immediately after page table change.
>
> Fixes: f2c17aabc917 ("RISC-V: Implement compile-time fixed mappings")
>
> Reported-by: Syven Wang
> Signed-off-by: Syven Wang
> Signed-off-by: Greentime Hu
> ---
> arch/riscv/mm/init.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index f4adb3684f3d..29b0f7108054 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -202,12 +202,11 @@ void __set_fixmap(enum fixed_addresses idx, phys_addr_t
> phys, pgprot_t prot)
>
> ptep = _pte[pte_index(addr)];
>
> - if (pgprot_val(prot)) {
> + if (pgprot_val(prot))
> set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, prot));
> - } else {
> + else
> pte_clear(_mm, addr, ptep);
> - local_flush_tlb_page(addr);
> - }
> + local_flush_tlb_page(addr);
> }
>
> static pte_t *__init get_pte_virt(phys_addr_t pa)
> --
> 2.28.0
>
Otherwise looks good to me.
Reviewed-by: Anup Patel
Regards,
Anup
[tip:irq/core] BUILD SUCCESS 3d5128c1deb5d27993fb11ba5e517798f8021046
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core branch HEAD: 3d5128c1deb5d27993fb11ba5e517798f8021046 Merge tag 'irqchip-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core elapsed time: 724m configs tested: 112 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig ia64generic_defconfig m68k bvme6000_defconfig arm pxa168_defconfig powerpc mpc885_ads_defconfig m68k alldefconfig mips decstation_64_defconfig armneponset_defconfig arm jornada720_defconfig sh magicpanelr2_defconfig h8300 edosk2674_defconfig armshmobile_defconfig c6x defconfig armmmp2_defconfig arm lubbock_defconfig arc nsimosci_hs_defconfig mips pnx8335_stb225_defconfig sparc64 alldefconfig arm badge4_defconfig arm ixp4xx_defconfig sh lboxre2_defconfig arm aspeed_g4_defconfig arc axs101_defconfig powerpcamigaone_defconfig sh sh7770_generic_defconfig mipsbcm47xx_defconfig h8300h8300h-sim_defconfig nds32 allnoconfig powerpc alldefconfig mips bmips_stb_defconfig armmagician_defconfig arm lpc18xx_defconfig m68km5307c3_defconfig arm aspeed_g5_defconfig sh rts7751r2dplus_defconfig m68kstmark2_defconfig arm pxa_defconfig sh sh03_defconfig mips db1xxx_defconfig armtrizeps4_defconfig parisc alldefconfig mips ip32_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20200803 i386 randconfig-a005-20200803 i386 randconfig-a001-20200803 i386 randconfig-a002-20200803 i386 randconfig-a003-20200803 i386 randconfig-a006-20200803 x86_64 randconfig-a006-20200804 x86_64 randconfig-a001-20200804 x86_64 randconfig-a004-20200804 x86_64 randconfig-a005-20200804 x86_64 randconfig-a002-20200804 x86_64 randconfig-a003-20200804 x86_64 randconfig-a013-20200803 x86_64 randconfig-a011-20200803 x86_64 randconfig-a012-20200803 x86_64 randconfig-a016-20200803 x86_64 randconfig-a015-20200803 x86_64 randconfig-a014-20200803 i386 randconfig-a011-20200803 i386 randconfig-a012-20200803 i386 randconfig-a015-20200803 i386 randconfig-a014
