* Arvind Sankar wrote:
> With the barrier in there, is there any reason to *not* inline the
> function? barrier_data() is an asm statement that tells the compiler
> that the asm uses the memory that was set to zero, thus preventing it
> from removing the memset even if nothing else uses that
Add devicetree binding for Analog Devices ADUX1020 Photometric
sensor.
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/iio/light/adux1020.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/adux1020.yaml
Add initial support for Analog Devices ADUX1020 Photometric sensor.
Only proximity mode has been enabled for now.
Signed-off-by: Manivannan Sadhasivam
---
drivers/iio/light/Kconfig| 11 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/adux1020.c | 783
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct.
This means that ptdump_walk_pgd_level_core() is now always passed a
valid pgd, so drop the support for pgd==NULL.
Signed-off-by: Steven Price
---
An mm_struct is needed to enable x86 to use of the generic
walk_page_range() function.
In the case of walking the user page tables (when
CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a
fake_mm structure because there isn't an mm_struct with a pointer
to the pgd of the user
Add a generic version of page table dumping that architectures can
opt-in to
Signed-off-by: Steven Price
---
include/linux/ptdump.h | 21 ++
mm/Kconfig.debug | 21 ++
mm/Makefile| 1 +
mm/ptdump.c| 150 +
4 files
Previously the /sys/kernel/debug/kernel_page_tables file would only show
lines for entries present in the page tables. However it is useful to
also show non-present entries as this makes the size and level of the
holes more visible. This aligns the behaviour with x86 which also shows
holes.
Now walk_page_range() can walk kernel page tables, we can switch the
arm64 ptdump code over to using it, simplifying the code.
Signed-off-by: Steven Price
---
arch/arm64/Kconfig | 1 +
arch/arm64/Kconfig.debug | 19 +
arch/arm64/include/asm/ptdump.h| 8 +-
Hello,
This patchset adds initial IIO driver support for ADUX1020 Photometric
sensor from Analog Devices. This sensor is usable for multiple optical
measurement applications, including gesture control and proximity sensing.
This initial driver includes support for only proximity mode with event
Make use of the new functionality in walk_page_range to remove the
arch page walking code and use the generic code to walk the page tables.
The effective permissions are passed down the chain using new fields
in struct pg_state.
The KASAN optimisation is implemented by including test_p?d
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For x86 we already have p?d_large() functions, so simply
It is useful to be able to skip parts of the page table tree even when
walking without VMAs. Add test_p?d callbacks similar to test_walk but
which are called just before a table at that level is walked. If the
callback returns non-zero then the entire table is skipped.
Signed-off-by: Steven Price
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level() need to pass an mm_struct rather
than the raw pgd_t pointer. Luckily since commit 7e904a91bf60
("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct
for EFI on x86.
Signed-off-by:
Since 48684a65b4e3: "mm: pagewalk: fix misbehavior of walk_page_range
for vma(VM_PFNMAP)", page_table_walk() will report any kernel area as
a hole, because it lacks a vma.
This means each arch has re-implemented page table walking when needed,
for example in the per-arch ptdump walker.
Remove
pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
no users. We're about to add users so reintroduce them, along with
p4d_entry() as we now have 5 levels of tables.
Note that commit a00cc7d9dd93d66a ("mm, x86:
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For sparc 64 bit, pmd_large() and pud_large() are already
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For riscv a page is a leaf page when it has a read, write
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For s390, pud_large() and pmd_large() are already
Exposing the pud/pgd levels of the page tables to walk_page_range() means
we may come across the exotic large mappings that come with large areas
of contiguous memory (such as the kernel's linear map).
For architectures that don't provide all p?d_leaf() macros, provide
generic do nothing default
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For powerpc pmd_large() already exists and does what we
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For arm pmd_large() already exists and does what we want.
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arm64, we already have p?d_sect() macros which we
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
If _PAGE_HUGE is defined we can simply look for it. When
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arc, we only have two levels, so only pmd_leaf()
Resurrecting this patch set after rebasing onto v5.4-rc1 which includes
the change to separate function pointers from iterator data in the
mm_walk structure.
Many architectures current have a debugfs file for dumping the kernel
page tables. Currently each architecture has to implement custom
On Mon, Oct 07, 2019 at 06:06:35PM +0800, Yunfeng Ye wrote:
> There are no return value checking when using kzalloc() and kcalloc() for
> memory allocation. so add it.
>
> Signed-off-by: Yunfeng Ye
> ---
> v1 -> v2:
> - return error code when memory allocation failure
>
>
On Mon, Oct 07, 2019 at 07:07:38AM +0100, Chris Clayton wrote:
> Just built and installed -rc2 and get the following when depmod is run.
>
> depmod: WARNING: /lib/modules/5.4.0-rc2/kernel/drivers/usb/storage/uas.ko
> needs unknown symbol usb_stor_sense_invalidCDB
> depmod: WARNING:
Quoting Cheng-yi Chiang (2019-10-07 06:58:41)
>
> Hi Guenter,
> Thanks for the quick review.
> I'll update accordingly in v2.
I'd prefer this use the nvmem framework which already handles many of
the requirements discussed here. Implement an nvmem provider and figure
out how to wire that up to
Ignore all upper-case variants before and after SI units like
mA, mV and uV so uses like RANGE_mA do not emit a CAMELCASE message.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl
On Mon, 2019-10-07 at 17:12 +0200, Michal Hocko wrote:
> On Mon 07-10-19 10:59:10, Qian Cai wrote:
> [...]
> > It is almost impossible to eliminate all the indirect call chains from
> > console_sem/console_owner_lock to zone->lock because it is too normal that
> > something later needs to allocate
On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>
> [...]
> > > > My suggestion would be to look at reworking the patch set and
> > > > post numbers for my patch set versus the bitmap approach and we can
> > > > look at them then.
> > >
Hi stmmac users,
Since 091810dbded9 ("net: stmmac: Introduce selftests support"), the
stmmac driver supports ethtool selftests that can help diagnose HW
mis-configurations and SW programming issues.
I would like to request all stmmac users to try running these tests and
send the output to
Quoting Hans de Goede (2019-10-05 14:04:49)
> Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to
> platform_get_irq*()"), platform_get_irq() will call dev_err() itself on
> failure, so there is no need for the driver to also do this.
>
> Signed-off-by: Hans de Goede
> ---
Quoting Hans de Goede (2019-10-05 14:04:48)
> The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries
> platform_get_irq_byname() and then falls back to the IRQ at index 0 if
> the platform_get_irq_byname().
>
> In this case we do not want platform_get_irq_byname() to print an
On 10/7/19 8:16 AM, Joerg Roedel wrote:
> @@ -318,7 +328,7 @@ static void dump_pagetable(unsigned long address)
>
> #else /* CONFIG_X86_64: */
>
> -void vmalloc_sync_all(void)
> +void vmalloc_sync_mappings(void)
> {
> sync_global_pgds(VMALLOC_START & PGDIR_MASK, VMALLOC_END);
> }
Hi Neil,
On Mon, 7 Oct 2019 at 19:50, Neil Armstrong wrote:
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing VDDCPUA_PWM and VDDCPUB_PWM
> > gpio signal use to enable/disable the pwm regulator for DVFS.
> >
> > Fixes: d14734a04a8a (arm64: dts: meson-g12b-odroid-n2:
Quoting Hans de Goede (2019-10-05 14:04:47)
> Some drivers (e.g dwc3) first try to get an IRQ byname and then fall
> back to the one at index 0. In this case we do not want the error(s)
> printed by platform_get_irq_byname(). This commit adds a new
> platform_get_irq_byname_optional(), which does
Hi,
On Mon, Oct 07, 2019 at 11:19:06PM +0800, Chen-Yu Tsai wrote:
> On Sun, Aug 25, 2019 at 1:50 AM Samuel Holland wrote:
> > The RSB controller has two registers for controlling interrupt inputs:
> > RSB_INTE, which has bits for each possible interrupt, and the global
> > interrupt enable bit
Hi Neil,
On Mon, 7 Oct 2019 at 19:49, Neil Armstrong wrote:
>
> Hi Anand,
>
> On 07/10/2019 15:16, Anand Moon wrote:
> > As per schematics add missing 5V_EN gpio signal to enable
> > VCC5V regulator node.
> >
> > Fixes: c35f6dc5c377 (arm64: dts: meson: Add minimal support for Odroid-N2)
> > Cc:
On Thu, Sep 19, 2019 at 04:06:18PM +0200, Rasmus Villemoes wrote:
> The scheduler uses a (currently private) fixed_power_int() in its load
> average computation for computing powers of numbers 0 < x < 1
> expressed as fixed-point numbers, which is also what we want here. But
> that requires the
Hi,
On Thu, Aug 08, 2019 at 08:53:01PM +0100, Matt Fleming wrote:
> SD_BALANCE_{FORK,EXEC} and SD_WAKE_AFFINE are stripped in sd_init()
> for any sched domains with a NUMA distance greater than 2 hops
> (RECLAIM_DISTANCE). The idea being that it's expensive to balance
> across domains that far
On Mon, 7 Oct 2019 at 17:14, Rik van Riel wrote:
>
> On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote:
> > runnable load has been introduced to take into account the case where
> > blocked load biases the wake up path which may end to select an
> > overloaded
> > CPU with a large number
Make of_find_next_cache_node() available for modules.
Signed-off-by: Hanna Hawa
---
drivers/of/base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 20e0e7ee4edf..fe22c7428958 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2172,6
On Mon, Oct 7, 2019 at 6:10 AM Masahiro Yamada
wrote:
>
> Currently, linux/videodev.h is excluded from the UAPI header test since
> it is not self-contained. Building it for user-space would fail.
>
>
> Replacing with solves it, and allow more
> headers to join the UAPI header test.
>
>
On Sun, Oct 06, 2019 at 05:46:07PM +0200, Christoph Hellwig wrote:
> Use the new iomap writeback code that was copied from XFS to perform
> writeback.
>
> Signed-off-by: Christoph Hellwig
> [darrick: reduce this patch only to convert the xfs writeback code]
> Signed-off-by: Darrick J. Wong
On Mon, Oct 07, 2019 at 08:17:05AM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 07:48:38AM +0200, Christoph Hellwig wrote:
> > On Sun, Oct 06, 2019 at 03:43:24PM -0700, Darrick J. Wong wrote:
> > > > +iomap-y+= trace.o \
> > >
> > > I think this patch
From: David Miller
Date: Oct/07/2019, 15:14:26 (UTC+00:00)
> From: Jose Abreu
> Date: Mon, 7 Oct 2019 15:16:08 +0200
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > index 8b76745a7ec4..40b0756f3a14 100644
> >
Hi Helen,
On 10/5/19 10:36 PM, Helen Koike wrote:
> Hi Carlos,
>
> On 10/5/19 9:28 PM, kbuild test robot wrote:
>> Fixes: 4d124d159dff ("media: vimc: get pixformat info from v4l2_format_info
>> to avoid code repetition")
> Usually, the Fixes flag is used for something that is already accepted in
On Sun, Aug 25, 2019 at 1:50 AM Samuel Holland wrote:
>
> The RSB controller has two registers for controlling interrupt inputs:
> RSB_INTE, which has bits for each possible interrupt, and the global
> interrupt enable bit in RSB_CTRL.
>
> Currently, we enable the bits in RSB_INTE before each
HI Icenowy,
On Sun, Oct 06, 2019 at 11:12:43PM +0800, Icenowy Zheng wrote:
> 在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道：
> > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道：
> > > Hi Wens,
> > >
> > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng
> > > wrote:
> > > > This reverts commit
Adds support for Amazon's Annapurna Labs L1 EDAC driver to detect and
report L1 errors.
Signed-off-by: Hanna Hawa
---
MAINTAINERS | 5 +
drivers/edac/Kconfig | 8 ++
drivers/edac/Makefile | 1 +
drivers/edac/al_l1_edac.c | 190 ++
On Mon, Oct 07, 2019 at 11:21:56AM +0300, Andy Shevchenko wrote:
> On Sun, Oct 06, 2019 at 11:10:58AM -0400, William Breathitt Gray wrote:
> > This macro iterates for each 8-bit group of bits (clump) with set bits,
> > within a bitmap memory region. For each iteration, "start" is set to the
> >
Adds support for Amazon's Annapurna Labs L2 EDAC driver to detect and
report L2 errors.
Signed-off-by: Hanna Hawa
---
MAINTAINERS | 5 +
drivers/edac/Kconfig | 8 ++
drivers/edac/Makefile | 1 +
drivers/edac/al_l2_edac.c | 251 ++
This series adds L1 cache and L2 cache error detection and correction support
for Amazon's Annapurna Labs SoCs.
Alpine SoCs supports L1 and L2 single bit correction and two bits detection
capability based on ARM implementation.
The CPU cores in the SoC are the same and all of them support ECC.
On Mon, 7 Oct 2019 13:26:06 +0200
Ingo Molnar wrote:
> [ Sorry, fixed the Cc:lkml line. ]
/me joining the fun.
>
> * Peter Zijlstra wrote:
>
> > These here patches are something I've been poking at for a while,
> > enabling jump_label to use 2 byte jumps/nops.
> >
> > It _almost_ works
From: Joerg Roedel
Git commit 3f8fd02b1bf1 ("mm/vmalloc: Sync unmappings in
__purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in
the vunmap() code-path. While this change was necessary to maintain
correctness on x86-32-pae kernels, it also adds additional cycles for
Am 07.10.19 um 11:32 schrieb Mika Westerberg:
> On Sat, Oct 05, 2019 at 09:34:41AM +0200, Matthias Andree wrote:
>> Am 04.10.19 um 15:06 schrieb Mika Westerberg:
>>> On Fri, Oct 04, 2019 at 02:57:21PM +0200, Matthias Andree wrote:
Am 04.10.19 um 14:39 schrieb Mika Westerberg:
> @Matthias,
From: John Ogness
The syslog and kmsg_dump readers are provided buffers to fill.
Both try to maximize the provided buffer usage by calculating the
maximum number of messages that can fit. However, if after the
calculation, messages are dropped and new messages added, the
calculation will no
On Thu, Oct 03, 2019 at 05:12:43PM -0700 Xuewei Zhang wrote:
> quota/period ratio is used to ensure a child task group won't get more
> bandwidth than the parent task group, and is calculated as:
> normalized_cfs_quota() = [(quota_us << 20) / period_us]
>
> If the quota/period ratio was changed
Sakari Ailus wrote on Mon [2019-Oct-07 11:03:20
+0300]:
> On Fri, Oct 04, 2019 at 12:24:16PM -0500, Benoit Parrot wrote:
> > @@ -2657,6 +2669,12 @@ static int ov5640_init_controls(struct ov5640_dev
> > *sensor)
> > /* we can use our own mutex for the ctrl lock */
> > hdl->lock = >lock;
On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote:
> runnable load has been introduced to take into account the case where
> blocked load biases the wake up path which may end to select an
> overloaded
> CPU with a large number of runnable tasks instead of an underutilized
> CPU with a huge
On Thu, Sep 19, 2019 at 04:06:17PM +0200, Rasmus Villemoes wrote:
> lightness*1000 is nowhere near overflowing 32 bits, so we can just use
> an ordinary 32/32 division, which is much cheaper than the 64/32 done
> via do_div().
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Daniel Thompson
>
> Setting the shutdown to true is
> usually just to get the queues flushed, but the nvme_kill_queues() that
> we call accomplishes the same thing.
The intention of this patch was to clean up another location where
nvme_dev_disable()
is called with shutdown == false, but the device is being
On Mon, Oct 07, 2019 at 04:44:23PM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > > All the other reasons would require a fairly egregious kernel bug, hence
> > > the speculation that the #GP is due to a non-canonical address. Something
> > > like the following would be more precise,
On 10/7/19 4:59 PM, Maxime Jourdan wrote:
> Hello,
>
> This patch series aims to bring H.264 support as well as compliance update
> to the amlogic stateful video decoder driver.
>
> There is 1 issue that remains currently:
>
> - The following codepath had to be commented out from
On Mon 07-10-19 10:59:10, Qian Cai wrote:
[...]
> It is almost impossible to eliminate all the indirect call chains from
> console_sem/console_owner_lock to zone->lock because it is too normal that
> something later needs to allocate some memory dynamically, so as long as it
> directly call
On Sat, Sep 14, 2019 at 11:12 AM Adam Ford wrote:
>
> On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 14.09.2019 um 15:42 schrieb Adam Ford :
> > >
> > > On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> > > wrote:
> > >>
> > >>
> > >>> Am 13.09.2019 um
Fix warnings on __u64 and pointer translation on arm and
other 32bit architectures. Since the pointer is 32bits on
those archs, we should not directly cast those types.
Signed-off-by: Masami Hiramatsu
Cc: Emilio López
---
tools/testing/selftests/sync/sync.c |6 +++---
1 file changed, 3
Use size_t and ssize_t correctly for counting send file size
instead of unsigned long and long, because long is 32bit on
32bit arch, which is not enough for counting long file size (>4GB).
Signed-off-by: Masami Hiramatsu
Cc: Eric Dumazet
Cc: David S. Miller
---
Fix printf format warnings on arm (and other 32bit arch).
- udpgso.c and udpgso_bench_tx use %lu for size_t but it
should be unsigned long long on 32bit arch.
- so_txtime.c uses %ld for int64_t, but it should be
unsigned long long on 32bit arch.
Signed-off-by: Masami Hiramatsu
Cc:
Hi,
Here are some patches to fix some warnings/issues on 32bit arch
(e.g. arm).
When I built the ksefltest on arm, I hit some 32bit related warnings.
Here are the patches to fix those issues.
- [1/5] va_max was set 2^32 even on 32bit arch. This can make
va_max == 0 and always fail.
Some virtual address range tests requires 64bit address space,
and we can not build and run those tests on the 32bit machine.
Filter the 64bit architectures in Makefile and run_vmtests,
so that those tests are built/run only on 64bit archs.
Signed-off-by: Masami Hiramatsu
Cc: Anshuman Khandual
Currently proc-self-map-files-002.c sets va_max (max test address
of user virtual address) to 4GB, but it is too big for 32bit
arch and 1UL << 32 is overflow on 32bit long.
Make va_max 3GB on 32bit arch like i386 and arm.
Signed-off-by: Masami Hiramatsu
Cc: Alexey Dobriyan
---
When TI CAL was introduce as another driver under platform/ti-vpe
adding a second entry into the ti-vpe directory in the platform
Makefile caused issues during parallel build.
Signed-off-by: Benoit Parrot
Signed-off-by: Jyri Sarha
---
drivers/media/platform/Makefile | 4 +---
1 file changed, 1
Instead of saving a pointer to the 'fh' member of struct vpe_ctx to
later have to use container_of to retrieve the actual pointer to the
context structure, which seems to confuse static code analysis tool
anyways, just save the pointer to the actual structure and then retrieve
it directly.
From: Nikhil Devshatwar
SEQ_BT indicates the buffer for bottom field needs to be processed
before the top field.
Simplify the field selection logic to support SEQ_BT as well.
Modify the interlace flags to include any of alternate, SEQ_TB, SEQ_BT.
Update other format error checking to consider
Hello,
syzbot found the following crash on:
HEAD commit:1e76a3e5 kmsan: replace __GFP_NO_KMSAN_SHADOW with kmsan_i..
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=149bdd4760
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:58d5f26a usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=129c746360
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:58d5f26a usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=11e5b20d60
kernel config:
This a collection of backlog patches I have been carrying for the VPE
driver.
It adds supports for SEQ_BT as well as NV21.
And fixes a number of issues both through v4l2-compliance and normal
usage.
Changes since v2:
- Fix a type causing a compile error
- Address Hans' comment on the v4l2_common
v4l2-compliance fails with this message:
fail: v4l2-test-formats.cpp(672): \
Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT
fail: v4l2-test-formats.cpp(672): \
Video Output Multiplanar: TRY_FMT(G_FMT) != G_FMT
...
test VIDIOC_TRY_FMT: FAIL
Fixes: 94ed726e8e01
On Thu, Sep 19, 2019 at 04:06:16PM +0200, Rasmus Villemoes wrote:
> The "break-even" point for the two formulas is L==8, which is also
> what the code actually implements. [Incidentally, at that point one
> has Y=0.008856, not 0.08856].
>
> Moreover, all the sources I can find say the linear
v4l2-compliance warns with this message:
warn: v4l2-test-formats.cpp(717): \
TRY_FMT cannot handle an invalid pixelformat.
warn: v4l2-test-formats.cpp(718): \
This may or may not be a problem. For more information see:
warn: v4l2-test-formats.cpp(719): \
All 4 of the "colorspace" components were not originally handled.
Causing issue related to xfer_func not being initialized properly.
This was found with v4l2-compliance test.
Signed-off-by: Benoit Parrot
---
drivers/media/platform/ti-vpe/vpe.c | 5 -
1 file changed, 4 insertions(+), 1
For each queue we need to maintain resolutions, pixel format,
bytesperline, sizeimage, colorspace, etc.
Instead of manually adding more entries in the vpe_q_data struct, it is
better to just add a "struct v4l2_format" member and use that to store
all needed information.
Signed-off-by: Benoit
Up to now VPE was relying on the colorspace value of struct v4l2_format
as an indication to perform color space conversion from YUV to RGB or
not.
Instead we should used the source/destination fourcc codes as a more
reliable indication to perform color space conversion or not.
To do so, we
It is often useful to figure out if a pixel_format is either YUV or RGB
especially for driver who can perform the pixel encoding conversion.
Instead of having each driver implement its own "is_this_yuv/rgb"
function based on a restricted set of pixel value, it is better to do
this in centralized
The RGB to YUV HD full range coefficients did not match the TRM values
and appeared to be a cut-n-paste from the YUV to RGB section.
Replace the entries with the values from the TRM.
Signed-off-by: Benoit Parrot
---
drivers/media/platform/ti-vpe/csc.c | 4 ++--
1 file changed, 2 insertions(+),
v4l2-compliance fails with this message:
fail: v4l2-test-buffers.cpp(691): ret == 0
fail: v4l2-test-buffers.cpp(974): captureBufs(node, q, m2m_q,
frame_count, true)
test MMAP: FAIL
This caused the following Kernel Warning:
WARNING: CPU: 0 PID: 961 at
On Mon, 7 Oct 2019 14:55:19 +0200
Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2
> > at build time.
> >
> > I dug this here link out of my IRC logs:
> >
> >
> >
Add RGB565 and RGB555 to the v4l2_format_info table.
Signed-off-by: Benoit Parrot
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 09a3915b98a3..d0e5ebc736f9
VPE uses VPDMA (built-in dma engine) to transfer data to and from the IP
and memory. VPDMA expect 32 bits addresses. To make sure that is always
the case set the DMA mask and coherent mask for the device.
Signed-off-by: Benoit Parrot
---
drivers/media/platform/ti-vpe/vpe.c | 7 +++
1 file
commit 52831a418fa6 ("[media] media: ti-vpe: vpe: allow use of user
specified stride") and commit 8c1e4fa17e92 ("[media] media: ti-vpe: vpdma:
add support for user specified stride") resulted in the Motion Vector
stride to be the same as the image stride.
This caused memory corruption in the
v4l2-compliance fails with this message:
fail: v4l2-test-buffers.cpp(294): \
(int)g_sequence() < seq.last_seq + 1
fail: v4l2-test-buffers.cpp(740): \
buf.check(m2m_q, last_m2m_seq)
fail: v4l2-test-buffers.cpp(974): \
captureBufs(node, q, m2m_q, frame_count, true)
From: Ram Prasad
VPE's max height supported MAX_H is set to 1184 which is the
padded height from VC1 decoder output.
In case of 90, 270 degree rotated video processing, input to
VPE will be 1080x1920, 720x1280 etc and MAX_H needs to be set
correct value. Setting MAX_H to 2048 as worst case
Using dma_addr_t as the type to hold address inside of a fix sized
descriptor used by the vpdma firmware is prone to fail when the expected
width is 32 bits and suddenly when CONFIG_LPAE is enabled the data size
is now 64 bits shifted the remaining members of the descriptor in memory
which
A few NULL pointer checks were missing.
Add check with appropriate return code.
Signed-off-by: Benoit Parrot
---
drivers/media/platform/ti-vpe/vpe.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
v4l2-compliance fails with this message:
warn: v4l2-test-formats.cpp(717): \
TRY_FMT cannot handle an invalid pixelformat.
test VIDIOC_TRY_FMT: FAIL
This causes the following kernel panic:
Unable to handle kernel paging request at virtual address 56595561
pgd = ecd80e00
v4l2-compliance fails with this message:
fail: v4l2-test-formats.cpp(463): !pfmt.sizeimage
fail: v4l2-test-formats.cpp(736): \
Video Capture Multiplanar is valid, \
but TRY_FMT failed to return a format
test VIDIOC_TRY_FMT: FAIL
This failure is causd by the driver
From: Nikhil Devshatwar
In NV21 format, the chroma plane is written to memory such that the U
and V components are swapped for NV12.
Create a new entry in the VPDMA formats to describe the correct data
types used in the data descriptors.
Update all checks for NV12 and add NV21 there as well.
501 - 600 of 1218 matches
Mail list logo
