Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the
Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.
Signed-off-by: Ezequiel Garcia
Tested-by: Jonas Karlman
---
drivers/staging/media/hantro/hantro_drv.c | 5 -
drivers/staging/media/hantro/hantro_h264.c | 5 -
Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX
if a non-flat scaling matrix applies to the picture. This is the case if
SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag
are set, and should be handled by applications.
On one hand, the PPS bitstream
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the
Currently, the drivers makes no distinction between per_request
and mandatory, as both are used in the same request validate check.
The driver only cares to know if a given control is
required to be part of a request, so only one flag is needed.
Signed-off-by: Ezequiel Garcia
Tested-by: Jonas
From: Jernej Skrabec
Current frame list construction algorithm assumes that decoded image
will be output into its own buffer. That is true for progressive content
but not for interlaced where each field is decoded separately into same
buffer.
Fix that by checking if capture buffer is listed in
The prediction weight parameters are only required under
certain conditions, which depend on slice header parameters.
As specified in section 7.3.3 Slice header syntax, the prediction
weight table is present if:
((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \
The H.264 specification requires in section 7.4.3 "Slice header semantics",
that the following values shall be the same in all slice headers:
pic_parameter_set_id
frame_num
field_pic_flag
bottom_field_flag
idr_pic_id
pic_order_cnt_lsb
delta_pic_order_cnt_bottom
Currently, the SLICE_BASED and FRAME_BASED modes documentation
is misleading and not matching the intended use-cases.
Drop non-required fields SLICE_PARAMS 'start_byte_offset' and
DECODE_PARAMS 'num_slices' and clarify the decoding modes in the
documentation.
On SLICE_BASED mode, a single slice
The SLICE_PARAMS control is intended for slice-based
devices. In this mode, the OUTPUT buffer contains
a single slice, and so the buffer's plane payload size
can be used to query the slice size.
To reduce the API surface drop the size from the
SLICE_PARAMS control.
A follow-up change will remove
As discussed recently, the current interface for the
Decoded Picture Buffer is not enough to properly
support field coding.
This commit introduces enough semantics to support
frame and field coding, and to signal how DPB entries
are "used for reference".
Reserved fields will be added by a
From: Philipp Zabel
Since pic_order_cnt_bit_size is not a syntax element itself, explicitly
state that it is the total size in bits of the pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] syntax elements contained in the slice.
Signed-off-by:
DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced
content (field_pic_flag=1).
As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4)
and log2_max_frame_num_minus4 is in the range of 0 to 12,
which means pic_num should be a 32-bit field.
The v4l2_h264_dpb_entry struct needs
From: Jernej Skrabec
When dealing with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Change reference lists to hold a structure, which specifies
an index into
Slice header syntax element 'first_mb_in_slice' can point
to the last macroblock, currently the field can only reference
65536 macroblocks which is insufficient for 8K videos.
Although unlikely, a 8192x4320 video (where macroblocks are 16x16),
would contain 138240 macroblocks on a frame.
As per
New round for the H.264 uAPI cleanup, which as discussed
aims at being stabilized and promoted as a first-class public uAPI soon.
Changelog:
v3->v4:
* Convert enum v4l2_h264_field_reference to a __u8,
as suggested by Hans. This reduces v4l2_ctrl_h264_slice_params
from 536 bytes down to 152
Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
Signed-off-by: Ezequiel Garcia
On Fri, Aug 21, 2020 at 11:56:43AM -0700, Lokesh Gidra wrote:
> From: Daniel Colascione
>
> This change adds a new function, anon_inode_getfd_secure, that creates
> anonymous-node file with individual non-S_PRIVATE inode to which security
> modules can apply policy. Existing callers continue
On 23 August 2020 4:54:05 AM IST, Cristian Ciocaltea
wrote:
>Hi Mani,
>
>On Sat, Aug 22, 2020 at 06:43:43PM +0530, Manivannan Sadhasivam wrote:
>> Hi Cristi,
>>
>> Thanks for the series! I'll take a look soon but there is a quick
>comment
>> below.
>>
>> On Sat, Aug 22, 2020 at 01:26:53AM
On Aug 24, 2020, at 9:26 PM, Matthew Wilcox wrote:
>
> On Tue, Aug 25, 2020 at 10:27:35AM +1000, Dave Chinner wrote:
>>> do {
>>> - unsigned offset, bytes;
>>> -
>>> - offset = offset_in_page(pos);
>>> - bytes = min_t(loff_t, PAGE_SIZE - offset, count);
>>> +
On 8/24/20 4:07 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-08-24-16-06 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
在 2020/8/25 上午9:56, Daniel Jordan 写道:
> On Mon, Aug 24, 2020 at 01:24:20PM -0700, Hugh Dickins wrote:
>> On Mon, 24 Aug 2020, Andrew Morton wrote:
>>> On Mon, 24 Aug 2020 20:54:33 +0800 Alex Shi
>>> wrote:
>> Andrew demurred on version 17 for lack of review. Alexander Duyck has
>> been doing
On Mon, Aug 24, 2020 at 8:04 PM Stephen Rothwell wrote:
>
> Hi Alexei,
>
> On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov
> wrote:
> >
> > On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> > > wrote:
> > > >
On Tue, Aug 25, 2020 at 10:27:35AM +1000, Dave Chinner wrote:
> > do {
> > - unsigned offset, bytes;
> > -
> > - offset = offset_in_page(pos);
> > - bytes = min_t(loff_t, PAGE_SIZE - offset, count);
> > + loff_t bytes;
> >
> > if
The need for padding 64bit is implicitly checked by nla_align_64bit(), so
remove this explicit one.
Signed-off-by: Miaohe Lin
---
lib/nlattr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index bc5b5cf608c4..98f596bfbfd8 100644
---
On Wed, Jul 29, 2020 at 10:50 AM Matthias Kaehlcke wrote:
>
> For disabled paths the 'interconnect_summary' in debugfs currently shows
> the orginally requested bandwidths. This is confusing, since the bandwidth
> requests aren't active. Instead show the bandwidths for disabled
> paths/requests
adjust the code and add support non-rixi
This patch adds support for non-rixi, based on [1].
MIPS page fault path take 3 exception (1 tlb miss + 2 tlb invalid), but
the second tlb invalid exception is just caused by __update_tlb from
do_page_fault writing tlb without _PAGE_VALID set. With this patch, it
only take 1 tlb miss + 1 tlb
Hi,
On 7/13/20 10:19 PM, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain
When mtu is locked, we should not obtain ipv4 mtu as we return immediately
in this case and leave acquired ipv4 mtu unused.
Signed-off-by: Miaohe Lin
---
net/ipv4/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index
Hello Jan,
The flash on our board is Winbond W25Q128JV.
Best Regards,
Le Jin
-Original Message-
From: Kiszka, Jan (CT RDA IOT SES-DE)
Sent: Monday, August 24, 2020 8:49 PM
To: Vignesh Raghavendra ; Tudor Ambarus
; Mark Brown ; Jin, Le (RC-CN
DI FA R SW)
Cc: Boris Brezillon ;
Hi Chris,
On 8/24/20 4:35 PM, Chris Wilson wrote:
Quoting Lu Baolu (2020-08-24 07:31:23)
Hi Chris,
On 2020/8/22 2:33, Chris Wilson wrote:
Quoting Lu Baolu (2019-05-25 06:41:28)
This allows the iommu generic layer to allocate a dma domain and
attach it to a device through the iommu api's.
Hi Sidong,
Thanks a lot for your patch and effort to improve VKMS.
On 08/18, Sidong Yang wrote:
> I wrote this patch for TODO list in vkms documentation.
>
> Use alpha value to blend source value and destination value Instead of
> just overwrite with source value.
>
> Cc: Rodrigo Siqueira
>
From: Qianli Zhao
Flushing own workqueue or work self in work context will lead to
a deadlock.
Catch this incorrect usage and issue a warning when issue happened
crash> ps 10856
PIDPPID CPU TASK ST COMM
108562 2 ffc873428080 UN [kworker/u16:15]
crash> bt 10856
Hi Vinod,
Thank you for the review comments...
On 24/8/2020 12:06 am, Vinod Koul wrote:
On 17-08-20, 15:05, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add support for USB PHY on Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
Reviewed-by: Philipp Zabel
Hi Melissa,
First of all, thanks a lot for your patch!
Follows my inline comments.
On 08/19, Melissa Wen wrote:
> The current VKMS blend function ignores alpha channel and just overwrites
> vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
> running the
Hi Alexei,
On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov
wrote:
>
> On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell
> wrote:
> >
> > On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (x86_64
> > >
From: Chris Healy
Add syscon compatibility with Vybrid OCOTP driver binding. This is
required to access the UID.
Fixes: 623069946952 ("nvmem: Add DT binding documentation for Vybrid
OCOTP driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Healy
---
Changes in v4:
- Point to the
On Tue, Aug 25, 2020 at 5:21 AM Mike Kravetz wrote:
>
> On 8/24/20 1:59 PM, Andrew Morton wrote:
> > On Sat, 22 Aug 2020 17:53:28 +0800 Muchun Song
> > wrote:
> >
> >> There is a race between the assignment of `table->data` and write value
> >> to the pointer of `table->data` in the
* xunlei [2020-08-25 10:11:24]:
> On 2020/8/24 PM9:38, Srikar Dronamraju wrote:
> > * Xunlei Pang [2020-08-24 20:30:19]:
> >
> >> We've met problems that occasionally tasks with full cpumask
> >> (e.g. by putting it into a cpuset or setting to full affinity)
> >> were migrated to our isolated
From: Shuo Liu
A User VM can access its virtual PCI configuration spaces via port IO
approach, which has two following steps:
1) writes address into port 0xCF8
2) put/get data in/from port 0xCFC
To distribute a complete PCI configuration space access one time, HSM
need to combine such two
From: Shuo Liu
ACRN supports partition mode to achieve real-time requirements. In
partition mode, a CPU core can be dedicated to a vCPU of User VM. The
local APIC of the dedicated CPU core can be passthrough to the User VM.
The Service VM controls the assignment of the CPU cores.
Introduce an
From: Shuo Liu
A virtual CPU of User VM has different context due to the different
registers state. ACRN userspace needs to set the virtual CPU
registers state (e.g. giving a initial registers state to a virtual
BSP of a User VM).
HSM provides an ioctl ACRN_IOCTL_SET_VCPU_REGS to do the virtual
From: Shuo Liu
ioeventfd is a mechanism to register PIO/MMIO regions to trigger an
eventfd signal when written to by a User VM. ACRN userspace can register
any arbitrary I/O address with a corresponding eventfd and then pass the
eventfd to a specific end-point of interest for handling.
Vhost is
From: Shuo Liu
The C-states and P-states data are used to support CPU power management.
The hypervisor controls C-states and P-states for a User VM.
ACRN userspace need to query the data from the hypervisor to build ACPI
tables for a User VM.
HSM provides ioctls for ACRN userspace to query
From: Shuo Liu
PCI device passthrough enables an OS in a virtual machine to directly
access a PCI device in the host. It promises almost the native
performance, which is required in performance-critical scenarios of
ACRN.
HSM provides the following ioctls:
- Assign - ACRN_IOCTL_ASSIGN_PCIDEV
From: Shuo Liu
An I/O request of a User VM, which is constructed by hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
I/O client maintains a list of address ranges. Introduce
acrn_ioreq_range_{add,del}() to
From: Shuo Liu
irqfd is a mechanism to inject a specific interrupt to a User VM using a
decoupled eventfd mechanism.
Vhost is a kernel-level virtio server which uses eventfd for interrupt
injection. To support vhost on ACRN, irqfd is introduced in HSM.
HSM provides ioctls to associate a
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM, there is a shared 4-KByte memory region used for I/O
requests
From: Shuo Liu
ACRN userspace need to inject virtual interrupts into a User VM in
devices emulation.
HSM needs provide interfaces to do so.
Introduce following interrupt injection interfaces:
ioctl ACRN_IOCTL_SET_IRQLINE:
Pass data from userspace to the hypervisor, and inform the hypervisor
From: Shuo Liu
The HSM provides hypervisor services to the ACRN userspace. While
launching a User VM, ACRN userspace needs to allocate memory and request
the ACRN Hypervisor to set up the EPT mapping for the VM.
A mapping cache is introduced for accelerating the translation between
the Service
From: Shuo Liu
The Service VM communicates with the hypervisor via conventional
hypercalls. VMCALL instruction is used to make the hypercalls.
ACRN hypercall ABI:
* Hypercall number is in R8 register.
* Up to 2 parameters are in RDI and RSI registers.
* Return value is in RAX register.
From: Yin Fengwei
ACRN Hypervisor reports hypervisor features via CPUID leaf 0x4001
which is similar to KVM. A VM can check if it's the privileged VM using
the feature bits. The Service VM is the only privileged VM by design.
Signed-off-by: Yin Fengwei
Signed-off-by: Shuo Liu
Reviewed-by:
From: Shuo Liu
Add documentation on the following aspects of ACRN:
1) A brief introduction on the architecture of ACRN.
2) I/O request handling in ACRN.
To learn more about ACRN, please go to ACRN project website
https://projectacrn.org, or the documentation page
From: Shuo Liu
ACRN Hypervisor Service Module (HSM) is a kernel module in Service VM
which communicates with ACRN userspace through ioctls and talks to ACRN
Hypervisor through hypercalls.
Add a basic HSM driver which allows Service VM userspace to communicate
with ACRN. The following patches
From: Shuo Liu
The VM management interfaces expose several VM operations to ACRN
userspace via ioctls. For example, creating VM, starting VM, destroying
VM and so on.
The ACRN Hypervisor needs to exchange data with the ACRN userspace
during the VM operations. HSM provides VM operation ioctls to
From: Shuo Liu
ACRN is a Type 1 reference hypervisor stack, running directly on the bare-metal
hardware, and is suitable for a variety of IoT and embedded device solutions.
ACRN implements a hybrid VMM architecture, using a privileged Service VM. The
Service VM manages the system resources
From: Shuo Liu
The ACRN Hypervisor builds an I/O request when a trapped I/O access
happens in User VM. Then, ACRN Hypervisor issues an upcall by sending
a notification interrupt to the Service VM. HSM in the Service VM needs
to hook the notification interrupt to handle I/O requests.
Currently, rcu_do_batch() depends on the unsegmented callback list's len field
to know how many CBs are executed. This fields counts down from 0 as CBs are
dequeued. It is possible that all CBs could not be run because of reaching
limits in which case the remaining unexecuted callbacks are
Add counting of segment lengths of segmented callback list.
This will be useful for a number of things such as knowing how big the
ready-to-execute segment have gotten. The immediate benefit is ability
to trace how the callbacks in the segmented callback list change.
Tested by profusely reading
Track how the segcb list changes before/after acceleration, during
queuing and during dequeuing.
This has proved useful to discover an optimization to avoid unwanted GP
requests when there are no callbacks accelerated. The overhead is minimal as
each segment's length is now stored in the
This is required for several usecases identified. One of them being tracing how
the segmented callback list changes. Tracing this has identified issues in RCU
code in the past. The trace patch is the last one in this series.
Passes 30 minutes of TREE01, TREE03, TREE07. Testing of other TREE
The donecbs's ->len field is used to store the total count of the segmented
callback list's length. This ->len field is then added to the destination segcb
list.
However, this presents a problem for per-segment length counting which is added
in a future patch. This future patch sets the rcl->len
Hi Andrew and Mike,
On Sat, Aug 22, 2020 at 5:53 PM Muchun Song wrote:
>
> There is a race between the assignment of `table->data` and write value
> to the pointer of `table->data` in the __do_proc_doulongvec_minmax().
> Fix this by duplicating the `table`, and only update the duplicate of
> it.
On Mon, Aug 24, 2020 at 06:26:50PM +0200, Krzysztof Kozlowski wrote:
> The i.MX 8QXP DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
> compatible: ['fsl,imx8qxp-lpuart',
On Mon, Aug 24, 2020 at 08:33:06PM -0600, Rob Herring wrote:
> On Mon, Aug 24, 2020 at 06:26:36PM +0200, Krzysztof Kozlowski wrote:
> > Allow parsing GPIO controller children nodes with GPIO hogs to fix
> > warning:
> >
> > arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpio@3024:
> >
On Mon, 24 Aug 2020 18:26:48 +0200, Krzysztof Kozlowski wrote:
> Document the binding for Zodiac Inflight Innovations Ultra Boards.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 8
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Rob
On Mon, 24 Aug 2020 18:26:49 +0200, Krzysztof Kozlowski wrote:
> The i.MX 8M DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mq-thor96.dt.yaml:
> interrupt-controller@32e2d000:
> compatible: ['fsl,imx8m-irqsteer',
On Mon, 24 Aug 2020 18:26:47 +0200, Krzysztof Kozlowski wrote:
> The Toradex Colibri i.MX 8 Evaluation board has two Toradex compatibles
> so it needs separate entry. This fixes dtbs_check warning:
>
> arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dt.yaml: /:
> compatible:
On Mon, Aug 24, 2020 at 06:26:46PM +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs use two compatibles so update the binding to
> fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
> compatible:1: 'syscon' was expected
> From
On Mon, Aug 24, 2020 at 06:26:45PM +0200, Krzysztof Kozlowski wrote:
> The i.MX 8 DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b4:
> compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is
On Mon, 24 Aug 2020 18:26:44 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: tmu@3026:
> compatible:0: 'fsl,imx8mn-tmu' is not one of
>-Original Message-
>From: Johan Hovold
>Sent: 2020年8月24日 17:54
>To: kernel test robot
>Cc: Greg Kroah-Hartman ; kbuild-...@lists.01.org;
>linux-kernel@vger.kernel.org
>Subject: [kbuild-all] Re: drivers/greybus/es2.c:439 message_send() error:
>double
>unlocked
On Mon, 24 Aug 2020 18:26:43 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: reset-controller@3039:
> compatible:0: 'fsl,imx8mm-src' is
On Mon, 24 Aug 2020 18:26:42 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: nand-controller@33002000:
> compatible:0: 'fsl,imx8mm-gpmi-nand'
On Mon, 24 Aug 2020 18:26:41 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dt.yaml:
> watchdog@3028:
> compatible:0:
On Mon, 24 Aug 2020 18:26:40 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
> compatible:0: 'fsl,imx8mm-pwm' is not one of
On Mon, 24 Aug 2020 18:26:39 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
> compatible:0: 'fsl,imx8mm-pwm' is not one of
On Mon, 24 Aug 2020 18:26:37 +0200, Krzysztof Kozlowski wrote:
> Parse also optional power-domains property to fix dtbs_check warnings
> like:
>
> arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: gpio@5d08:
> 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+'
>
On Mon, 24 Aug 2020 18:26:38 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: ddr-pmu@3d80:
> compatible:0: 'fsl,imx8mm-ddr-pmu' is not one
On Mon, Aug 24, 2020 at 06:26:36PM +0200, Krzysztof Kozlowski wrote:
> Allow parsing GPIO controller children nodes with GPIO hogs to fix
> warning:
>
> arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpio@3024:
> 'wl-reg-on' does not match any of the regexes: 'pinctrl-[0-9]+'
> From
The compute_crc() function is responsible for calculating the
framebuffer CRC value; due to the XRGB format, this function has to
ignore the alpha channel during the CRC computation. Therefore,
compute_crc() set zero to the alpha channel directly in the input
framebuffer, which is not a problem
This patch implements the necessary functions to add writeback support
for vkms. This feature is useful for testing compositors if you don't
have hardware with writeback support.
Change in V4 (Emil and Melissa):
- Move signal completion above drm_crtc_add_crc_entry()
- Make writeback always
On Mon, 24 Aug 2020 18:26:35 +0200, Krzysztof Kozlowski wrote:
> The GPIO controller node can have gpio-ranges property. This fixes
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
> 'gpio-ranges' does not match any of the regexes:
In the vkms_composer.c, some of the functions related to CRC and compose
have interdependence between each other. This patch reworks some
functions inside vkms_composer to make crc and composer computation
decoupled.
This patch is preparation work for making vkms able to support new
features.
This is the V5 version of a series that introduces the writeback support
to VKMS. The first two patches of this series are a pre-work for the
latest patch that adds the writeback connector, this patchset can be seen
in two parts:
* A pre-work that aims to make vkms composer operations a little
Hi, James,
> On 09/07/2020 09:22, Alison Wang wrote:
> > Add error detection for A53 and A72 cores. Hardware error injection is
> > supported on A53. Software error injection is supported on both.
>
>
> As we can't safely write to these registers from linux, so I think this means
> all
> the
On Mon, 24 Aug 2020 18:26:34 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8 SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
> compatible:0: 'fsl,imx8mm-gpio' is not one of
: 11 months ago
config: microblaze-randconfig-r035-20200824 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
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
On 8/24/20 7:22 PM, Al Viro wrote:
On Mon, Aug 24, 2020 at 07:07:02PM -0700, John Hubbard wrote:
On 8/24/20 6:54 PM, Al Viro wrote:
On Fri, Aug 21, 2020 at 09:20:54PM -0700, John Hubbard wrote:
Direct IO behavior:
ITER_IOVEC:
pin_user_pages_fast();
break;
On Mon, 17 Aug 2020 08:17:01 +0800, Zhiyong Tao wrote:
> The commit adds mt8192 compatible node in binding document.
>
> Signed-off-by: Zhiyong Tao
> ---
> .../bindings/pinctrl/pinctrl-mt8192.yaml | 155 ++
> 1 file changed, 155 insertions(+)
> create mode 100644
>
On Mon, Aug 24, 2020 at 07:07:02PM -0700, John Hubbard wrote:
> On 8/24/20 6:54 PM, Al Viro wrote:
> > On Fri, Aug 21, 2020 at 09:20:54PM -0700, John Hubbard wrote:
> >
> > > Direct IO behavior:
> > >
> > > ITER_IOVEC:
> > > pin_user_pages_fast();
> > > break;
> > >
> > >
On Sun, 16 Aug 2020 20:07:31 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (r8a7742) SoC specific bindings. The R8A7742 CAN module
> is identical to R-Car Gen2 family.
>
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-can".
>
> Signed-off-by: Lad Prabhakar
Hillf,
With the latest version (attached what I have changed on my tree), the
system failed to start up with cpu stalled.
Hillf Danton 于2020年8月22日周六 上午11:30写道：
>
>
> On Thu, 20 Aug 2020 20:43:17 +0800 Hillf Danton wrote:
> > Hi Jike,
> >
> > On Thu, 20 Aug 2020 15:43:17 +0800 Jike Song wrote:
On Sat, Aug 15, 2020 at 09:43:04PM +0200, Pavel Pisa wrote:
> The device-tree bindings for open-source/open-hardware CAN FD IP core
> designed at the Czech Technical University in Prague.
>
> CTU CAN FD IP core and other CTU CAN bus related projects
> listing and documentation page
>
>
On Sat, 15 Aug 2020 21:43:03 +0200, Pavel Pisa wrote:
> The Czech Technical University in Prague (CTU) is one of
> the biggest and oldest (founded 1707) technical universities
> in Europe. The abbreviation in Czech language is ČVUT according
> to official name in Czech language
>
> České vysoké
On Fri, 14 Aug 2020 18:30:33 +0100, Lad Prabhakar wrote:
> Document the support for R-Car PCIe EP on R8A774A1 and R8A774B1 SoC
> devices.
>
> Also constify "renesas,rcar-gen3-pcie-ep" so that it can be used as
> fallback compatible string for R-Car Gen3 and RZ/G2 devices as the
> PCIe module is
On Sat, 15 Aug 2020 21:33:35 +0200, Andreas Kemnade wrote:
> This adds a compatible string for the Tolino Shine 2 HD eBook reader.
>
> Signed-off-by: Andreas Kemnade
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Mon, 2020-08-24 at 13:50 +0200, Marco Elver wrote:
> On Mon, 24 Aug 2020 at 10:07, Walter Wu wrote:
> >
> > Syzbot reports many UAF issues for workqueue or timer, see [1] and [2].
> > In some of these access/allocation happened in process_one_work(),
> > we see the free stack is useless in
On Fri, Aug 14, 2020 at 03:09:19PM +0300, Abel Vesa wrote:
> Document the i.MX BLK_CTRL with its devicetree properties.
>
> Signed-off-by: Abel Vesa
> ---
> .../bindings/clock/fsl,imx-blk-ctrl.yaml | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode
101 - 200 of 2231 matches
Mail list logo
