Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(>tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Dec 3 05:00:11 CET 2018 media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0 media_build git hash: 47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8 v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH] media: unify some sony camera sensors pattern naming
On 12/01/2018 02:08 AM, Tomasz Figa wrote:
Hi Bingbu,
On Mon, Nov 26, 2018 at 7:56 PM wrote:
From: Bingbu Cao
Some Sony camera sensors have same test pattern
definitions, this patch unify the pattern naming
to make it more clear to the userspace.
Suggested-by: Sakari Ailus
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx258.c | 8
drivers/media/i2c/imx319.c | 8
drivers/media/i2c/imx355.c | 8
3 files changed, 12 insertions(+), 12 deletions(-)
Thanks for the patch! One comment inline.
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e2294843..a8a2880c6b4e 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -504,10 +504,10 @@ struct imx258_mode {
static const char * const imx258_test_pattern_menu[] = {
"Disabled",
- "Color Bars",
- "Solid Color",
- "Grey Color Bars",
- "PN9"
+ "Solid Colour",
+ "Eight Vertical Colour Bars",
Is it just me or "solid color" and "color bars" are being swapped
here? Did the driver had the names mixed up before or the order of
modes is different between these sensors?
The test pattern value order of the 3 camera sensors should be same.
All are:
0 - Disabled
1 - Solid Colour
2 - Eight Vertical Colour Bars
...
This patch swapped the first 2 item for imx258 (wrong order before) and use
unified
name for all 3 sensors.
Best regards,
Tomasz
Re: [PATCH] pulse8-cec: return 0 when invalidating the logical address
On 12/02/2018 04:25 PM, Torbjorn Jansson wrote: > On 2018-11-14 14:25, Hans Verkuil wrote: >> Return 0 when invalidating the logical address. The cec core produces >> a warning for drivers that do this. >> >> Signed-off-by: Hans Verkuil >> Reported-by: Torbjorn Jansson >> --- >> diff --git a/drivers/media/usb/pulse8-cec/pulse8-cec.c >> b/drivers/media/usb/pulse8-cec/pulse8-cec.c >> index 365c78b748dd..b085b14f3f87 100644 >> --- a/drivers/media/usb/pulse8-cec/pulse8-cec.c >> +++ b/drivers/media/usb/pulse8-cec/pulse8-cec.c >> @@ -586,7 +586,7 @@ static int pulse8_cec_adap_log_addr(struct cec_adapter >> *adap, u8 log_addr) >> else >> pulse8->config_pending = true; >> mutex_unlock(>config_lock); >> -return err; >> +return log_addr == CEC_LOG_ADDR_INVALID ? 0 : err; >> } >> >> static int pulse8_cec_adap_transmit(struct cec_adapter *adap, u8 attempts, >> > > > question, is below warning also fixed by this patch? or is it a different > problem? > note that this warning showed up without me unplugging the usb device. > and cec-ctl have stopped working (again...) Yes, same problem. Nothing to do with cec-ctl having stopped working. The real problem is this (quoted from https://hverkuil.home.xs4all.nl/cec-status.txt, end of the section "USB CEC Dongles"): "I'm no systemd hero and sometimes it won't pick up the device, esp. at boot time. I would be very happy if someone can take a good look at this and come up with better ideas. As far as I can tell the CEC device is picked up the first time it is connected to a USB port. But unplugging it, then replugging it into the same USB port will not pick it up again. You need to run inputattach manually in that case. It's something in udev/systemd, but I have no idea how to fix it." I have no time to chase this issue down. It probably requires contacting some systemd mailinglist and talk to people who actually understand systemd. If you want, you can give that a go. Regards, Hans
Re: [PATCH] pulse8-cec: return 0 when invalidating the logical address
On 2018-11-14 14:25, Hans Verkuil wrote: Return 0 when invalidating the logical address. The cec core produces a warning for drivers that do this. Signed-off-by: Hans Verkuil Reported-by: Torbjorn Jansson --- diff --git a/drivers/media/usb/pulse8-cec/pulse8-cec.c b/drivers/media/usb/pulse8-cec/pulse8-cec.c index 365c78b748dd..b085b14f3f87 100644 --- a/drivers/media/usb/pulse8-cec/pulse8-cec.c +++ b/drivers/media/usb/pulse8-cec/pulse8-cec.c @@ -586,7 +586,7 @@ static int pulse8_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr) else pulse8->config_pending = true; mutex_unlock(>config_lock); - return err; + return log_addr == CEC_LOG_ADDR_INVALID ? 0 : err; } static int pulse8_cec_adap_transmit(struct cec_adapter *adap, u8 attempts, question, is below warning also fixed by this patch? or is it a different problem? note that this warning showed up without me unplugging the usb device. and cec-ctl have stopped working (again...) [75420.604557] WARNING: CPU: 5 PID: 23114 at drivers/media/cec/cec-adap.c:1217 cec_adap_unconfigure+0x9c/0xa0 [cec] [75420.604562] Modules linked in: fuse 8021q garp mrp xt_nat macvlan xt_CHECKSUM iptable_mangle ip6t_REJECT nf_reject_ipv6 tun xfs devlink ebtable_filter ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache target_core_user uio target_core_pscsi bonding target_core_file target_core_iblock iscsi_target_mod target_core_mod rc_cec pulse8_cec cec ip6table_filter ip6_tables nct6775 hwmon_vid vfat fat dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) cx25840 cx23885 rc_tt_1500 altera_ci tda18271 altera_stapl tveeprom cx2341x sp2 si2157 si2168 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp [75420.604634] snd_hda_codec_hdmi ir_rc6_decoder videobuf2_dma_sg videobuf2_memops kvm_intel dvb_usb_dvbsky dvb_usb_v2 videobuf2_dvb m88ds3103 videobuf2_v4l2 videobuf2_common rc_rc6_mce v4l2_common videodev kvm dvb_core iTCO_wdt mceusb rc_core iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic joydev crct10dif_pclmul cdc_acm cp210x snd_hda_intel crc32_pclmul ghash_clmulni_intel snd_hda_codec intel_cstate intel_uncore ipmi_ssif snd_hda_core intel_rapl_perf media snd_hwdep drm_kms_helper i2c_mux snd_seq snd_seq_device snd_pcm drm snd_timer snd soundcore i2c_i801 mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler pcc_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc dm_thin_pool dm_cache_smq dm_cache dm_persistent_data libcrc32c dm_bio_prison mxm_wmi uas crc32c_intel igb [75420.604705] usb_storage megaraid_sas dca i2c_algo_bit wmi vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio i2c_dev [75420.604722] CPU: 5 PID: 23114 Comm: cec-ctl Tainted: P OE 4.19.5-200.local.fc28.x86_64 #1 [75420.604725] Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018 [75420.604732] RIP: 0010:cec_adap_unconfigure+0x9c/0xa0 [cec] [75420.604736] Code: 3c 05 00 00 e8 b5 fa ff ff 48 8d bb 30 04 00 00 31 c9 ba 01 00 00 00 be 01 00 00 00 e8 8d a8 80 e0 48 89 df 5b e9 a4 fe ff ff <0f> 0b eb 98 0f 1f 44 00 00 41 57 41 56 4c 8d b7 d0 03 00 00 41 55 [75420.604739] RSP: 0018:aa7423197d78 EFLAGS: 00010282 [75420.604743] RAX: ff92 RBX: 99d61cdbd800 RCX: [75420.604746] RDX: RSI: 0246 RDI: 99d62e903700 [75420.604749] RBP: 99d19d4aaa00 R08: 000e R09: [75420.604752] R10: 18fa R11: R12: aa7423197de8 [75420.604755] R13: 7ffe4fb9bd40 R14: 7ffe4fb9bd01 R15: 99d61cdbd800 [75420.604759] FS: 7f1e0310d740() GS:99d63f94() knlGS: [75420.604762] CS: 0010 DS: ES: CR0: 80050033 [75420.604765] CR2: 7f0d225fe680 CR3: 000ac544a005 CR4: 003626e0 [75420.604768] DR0: DR1: DR2: [75420.604771] DR3: DR6: fffe0ff0 DR7: 0400 [75420.604773] Call Trace: [75420.604784] __cec_s_log_addrs+0x25c/0x4c0 [cec] [75420.604790] cec_ioctl+0x1e2/0xda0 [cec] [75420.604800] ? do_filp_open+0xa7/0x100 [75420.604806] do_vfs_ioctl+0xa4/0x630 [75420.604812] ksys_ioctl+0x60/0x90 [75420.604818] __x64_sys_ioctl+0x16/0x20 [75420.604826] do_syscall_64+0x5b/0x160 [75420.604833] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [75420.604838] RIP: 0033:0x7f1e0210bc57 [75420.604842] Code: 00 00 90 48 8b 05 49 82 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 19 82 2c 00 f7 d8 64 89 01 48 [75420.604845] RSP: 002b:7ffe4fb9b908 EFLAGS: 0246 ORIG_RAX: 0010 [75420.604849] RAX:
