Re: [PATCH v2] staging: erofs: Add identifier for function definition arguments
On 2019/1/8 21:24, Sidong Yang wrote: > Add identifier for function definition arguments in xattr_iter_handlers, > this change clears the checkpatch.pl issue and make code more explicit. > > Signed-off-by: Sidong Yang Reviewed-by: Chao Yu Thanks, ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] gpu: ipu-csi: Swap fields according to input/output field types
Please disregard. This patch can't be submitted stand-alone, I will
re-submit as part of a v6 of "imx-media: Fixes for interlaced capture"
patchset.
Steve
On 12/14/18 3:46 PM, Steve Longerbeam wrote:
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
csi_setup(), suggested by Philipp.
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 126 +++---
drivers/staging/media/imx/imx-media-csi.c | 7 +-
include/video/imx-ipu-v3.h| 5 +-
3 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+ const struct v4l2_mbus_config *mbus_cfg,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
{
int ret;
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
return 0;
}
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ const struct v4l2_mbus_framefmt *infmt,
+ const struct v4l2_mbus_framefmt *outfmt,
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CC
[PATCH v6 03/12] gpu: ipu-v3: Add planar support to interlaced scan
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be doubled, since a single chroma line
is shared by two luma lines.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
Acked-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 26 +++--
drivers/staging/media/imx/imx-ic-prpencvf.c | 3 ++-
drivers/staging/media/imx/imx-media-csi.c | 3 ++-
include/video/imx-ipu-v3.h | 3 ++-
4 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 163fadb8a33a..d047a6867c59 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -277,9 +277,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32
u_off, u32 v_off)
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+ u32 pixelformat)
{
- u32 ilo, sly;
+ u32 ilo, sly, sluv;
if (stride < 0) {
stride = -stride;
@@ -290,9 +291,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch,
int stride)
sly = (stride * 2) - 1;
+ switch (pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ sluv = stride / 2 - 1;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ sluv = stride - 1;
+ break;
+ case V4L2_PIX_FMT_YUV422P:
+ sluv = stride - 1;
+ break;
+ case V4L2_PIX_FMT_NV16:
+ sluv = stride * 2 - 1;
+ break;
+ default:
+ sluv = 0;
+ break;
+ }
+
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
+ if (sluv)
+ ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
};
EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 28f41caba05d..af7224846bd5 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -412,7 +412,8 @@ static int prp_setup_channel(struct prp_priv *priv,
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field) &&
channel == priv->out_ch)
- ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline);
+ ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
+ image.pix.pixelformat);
ret = ipu_ic_task_idma_init(priv->ic, channel,
image.pix.width, image.pix.height,
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index c2a8d9cd31b7..da4808348845 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -512,7 +512,8 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field))
ipu_cpmem_interlaced_scan(priv->idmac_ch,
- image.pix.bytesperline);
+ image.pix.bytesperline,
+ image.pix.pixelformat);
ipu_idmac_set_double_buffer(priv->idmac_ch, true);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index bbc8481f567d..c887f4bee5f8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -258,7 +258,8 @@ void ipu_cpmem_set_stride(struct ipuv3_channel *ch, int
stride);
void ipu_cpmem_set_high_priority(struct ipuv3_channel *ch);
void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int bufnum, dma_addr_t
buf);
void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+ u32 pixelformat);
void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch);
void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 06/12] media: imx-csi: Double crop height for alternate fields at sink
If the incoming sink field type is alternate, the reset crop height
and crop height bounds must be set to twice the incoming height,
because in alternate field mode, upstream will report only the
lines for a single field, and the CSI captures the whole frame.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
drivers/staging/media/imx/imx-media-csi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index b276672cae1d..c40c3262038e 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1142,6 +1142,8 @@ static void csi_try_crop(struct csi_priv *priv,
struct v4l2_mbus_framefmt *infmt,
struct v4l2_fwnode_endpoint *upstream_ep)
{
+ u32 in_height;
+
crop->width = min_t(__u32, infmt->width, crop->width);
if (crop->left + crop->width > infmt->width)
crop->left = infmt->width - crop->width;
@@ -1149,6 +1151,10 @@ static void csi_try_crop(struct csi_priv *priv,
crop->left &= ~0x3;
crop->width &= ~0x7;
+ in_height = infmt->height;
+ if (infmt->field == V4L2_FIELD_ALTERNATE)
+ in_height *= 2;
+
/*
* FIXME: not sure why yet, but on interlaced bt.656,
* changing the vertical cropping causes loss of vertical
@@ -1158,12 +1164,12 @@ static void csi_try_crop(struct csi_priv *priv,
if (upstream_ep->bus_type == V4L2_MBUS_BT656 &&
(V4L2_FIELD_HAS_BOTH(infmt->field) ||
infmt->field == V4L2_FIELD_ALTERNATE)) {
- crop->height = infmt->height;
- crop->top = (infmt->height == 480) ? 2 : 0;
+ crop->height = in_height;
+ crop->top = (in_height == 480) ? 2 : 0;
} else {
- crop->height = min_t(__u32, infmt->height, crop->height);
- if (crop->top + crop->height > infmt->height)
- crop->top = infmt->height - crop->height;
+ crop->height = min_t(__u32, in_height, crop->height);
+ if (crop->top + crop->height > in_height)
+ crop->top = in_height - crop->height;
}
}
@@ -1403,6 +1409,8 @@ static void csi_try_fmt(struct csi_priv *priv,
crop->top = 0;
crop->width = sdformat->format.width;
crop->height = sdformat->format.height;
+ if (sdformat->format.field == V4L2_FIELD_ALTERNATE)
+ crop->height *= 2;
csi_try_crop(priv, crop, cfg, &sdformat->format, upstream_ep);
compose->left = 0;
compose->top = 0;
@@ -1530,6 +1538,8 @@ static int csi_get_selection(struct v4l2_subdev *sd,
sel->r.top = 0;
sel->r.width = infmt->width;
sel->r.height = infmt->height;
+ if (infmt->field == V4L2_FIELD_ALTERNATE)
+ sel->r.height *= 2;
break;
case V4L2_SEL_TGT_CROP:
sel->r = *crop;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 07/12] media: imx: interweave and odd-chroma-row skip are incompatible
If IDMAC interweaving is enabled in a write channel, the channel must
write the odd chroma rows for 4:2:0 formats. Skipping writing the odd
chroma rows produces corrupted captured 4:2:0 images when interweave
is enabled.
Reported-by: Krzysztof Hałasa
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 9 +++--
drivers/staging/media/imx/imx-media-csi.c | 8 ++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 1a03d4c9d7b8..cf76b0432371 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -391,12 +391,17 @@ static int prp_setup_channel(struct prp_priv *priv,
image.phys0 = addr0;
image.phys1 = addr1;
- if (channel == priv->out_ch || channel == priv->rot_out_ch) {
+ /*
+* Skip writing U and V components to odd rows in the output
+* channels for planar 4:2:0 (but not when enabling IDMAC
+* interweaving, they are incompatible).
+*/
+ if (!interweave && (channel == priv->out_ch ||
+ channel == priv->rot_out_ch)) {
switch (image.pix.pixelformat) {
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
- /* Skip writing U and V components to odd rows */
ipu_cpmem_skip_odd_chroma_rows(channel);
break;
}
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index c40c3262038e..dbc5a92ec073 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -457,8 +457,12 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
((image.pix.width & 0x1f) ?
((image.pix.width & 0xf) ? 8 : 16) : 32) : 64;
passthrough_bits = 16;
- /* Skip writing U and V components to odd rows */
- ipu_cpmem_skip_odd_chroma_rows(priv->idmac_ch);
+ /*
+* Skip writing U and V components to odd rows (but not
+* when enabling IDMAC interweaving, they are incompatible).
+*/
+ if (!interweave)
+ ipu_cpmem_skip_odd_chroma_rows(priv->idmac_ch);
break;
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 09/12] media: imx: vdic: rely on VDIC for correct field order
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
So fix prepare_vdi_in_buffers() to give the VDIC the fields in whatever
order they were received by the video source, and rely on the VDIC to
sort out which is top and which is bottom.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-vdic.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-vdic.c
b/drivers/staging/media/imx/imx-media-vdic.c
index 482250d47e7c..4a890714193e 100644
--- a/drivers/staging/media/imx/imx-media-vdic.c
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -219,26 +219,18 @@ static void __maybe_unused prepare_vdi_in_buffers(struct
vdic_priv *priv,
switch (priv->fieldtype) {
case V4L2_FIELD_SEQ_TB:
- prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0);
- curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + fs;
- next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
- break;
case V4L2_FIELD_SEQ_BT:
prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0) + fs;
curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + fs;
break;
+ case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
+ case V4L2_FIELD_INTERLACED:
prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0) + is;
curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + is;
break;
- default:
- /* assume V4L2_FIELD_INTERLACED_TB */
- prev_phys = vb2_dma_contig_plane_dma_addr(prev_vb, 0);
- curr_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0) + is;
- next_phys = vb2_dma_contig_plane_dma_addr(curr_vb, 0);
- break;
}
ipu_cpmem_set_buffer(priv->vdi_in_ch_p, 0, prev_phys);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 11/12] media: imx: Allow interweave with top/bottom lines swapped
Allow sequential->interlaced interweaving but with top/bottom
lines swapped to the output buffer.
This can be accomplished by adding one line length to IDMAC output
channel address, with a negative line length for the interlace offset.
This is to allow the seq-bt -> interlaced-bt transformation, where
bottom lines are still dominant (older in time) but with top lines
first in the interweaved output buffer.
With this support, the CSI can now allow seq-bt at its source pads,
e.g. the following transformations are allowed in CSI from sink to
source:
seq-tb -> seq-bt
seq-bt -> seq-bt
alternate -> seq-bt
Suggested-by: Philipp Zabel
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v4:
- Removed interweave_offset and replace with boolean interweave_swap,
suggested by Philipp Zabel.
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 25 +
drivers/staging/media/imx/imx-media-csi.c | 40 ++---
2 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index cf76b0432371..33ada6612fee 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -106,6 +106,7 @@ struct prp_priv {
u32 frame_sequence; /* frame sequence counter */
bool last_eof; /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
+ bool interweave_swap; /* swap top/bottom lines when interweaving */
struct completion last_eof_comp;
};
@@ -235,6 +236,9 @@ static void prp_vb2_buf_done(struct prp_priv *priv, struct
ipuv3_channel *ch)
if (ipu_idmac_buffer_is_ready(ch, priv->ipu_buf_num))
ipu_idmac_clear_buffer(ch, priv->ipu_buf_num);
+ if (priv->interweave_swap && ch == priv->out_ch)
+ phys += vdev->fmt.fmt.pix.bytesperline;
+
ipu_cpmem_set_buffer(ch, priv->ipu_buf_num, phys);
}
@@ -376,8 +380,9 @@ static int prp_setup_channel(struct prp_priv *priv,
* the IDMAC output channel.
*/
interweave = V4L2_FIELD_IS_INTERLACED(image.pix.field) &&
- V4L2_FIELD_IS_SEQUENTIAL(outfmt->field) &&
- channel == priv->out_ch;
+ V4L2_FIELD_IS_SEQUENTIAL(outfmt->field);
+ priv->interweave_swap = interweave &&
+ image.pix.field == V4L2_FIELD_INTERLACED_BT;
if (rot_swap_width_height) {
swap(image.pix.width, image.pix.height);
@@ -388,6 +393,11 @@ static int prp_setup_channel(struct prp_priv *priv,
(image.pix.width * outcc->bpp) >> 3;
}
+ if (priv->interweave_swap && channel == priv->out_ch) {
+ /* start interweave scan at 1st top line (2nd line) */
+ image.rect.top = 1;
+ }
+
image.phys0 = addr0;
image.phys1 = addr1;
@@ -396,8 +406,8 @@ static int prp_setup_channel(struct prp_priv *priv,
* channels for planar 4:2:0 (but not when enabling IDMAC
* interweaving, they are incompatible).
*/
- if (!interweave && (channel == priv->out_ch ||
- channel == priv->rot_out_ch)) {
+ if ((channel == priv->out_ch && !interweave) ||
+ channel == priv->rot_out_ch) {
switch (image.pix.pixelformat) {
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
@@ -424,8 +434,11 @@ static int prp_setup_channel(struct prp_priv *priv,
if (rot_mode)
ipu_cpmem_set_rotation(channel, rot_mode);
- if (interweave)
- ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
+ if (interweave && channel == priv->out_ch)
+ ipu_cpmem_interlaced_scan(channel,
+ priv->interweave_swap ?
+ -image.pix.bytesperline :
+ image.pix.bytesperline,
image.pix.pixelformat);
ret = ipu_ic_task_idma_init(priv->ic, channel,
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 7afb7e367d76..e18f58f56dfb 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -114,6 +114,7 @@ struct csi_priv {
u32 frame_sequence; /* frame sequence counter */
bool last_eof; /* waiting for last EOF at stream off */
bool nfb4eof;/* NFB4EOF encountered during streaming */
+ bool interweave_swap; /* swap top/bottom lines when interweaving */
struct completion last_eof_comp;
};
@@ -286,6 +287,9 @@ static void csi_vb2_buf_done(struct csi_priv *priv)
if (ipu_idmac_buffer_is_ready(priv->idmac_ch, priv->ipu_buf_num))
ipu_idmac_clear_buffer(priv->idmac_ch, priv->ipu_buf_num);
+ i
[PATCH v6 05/12] media: imx-csi: Input connections to CSI should be optional
Some imx platforms do not have fwnode connections to all CSI input
ports, and should not be treated as an error. This includes the
imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
endpoint parsing will not treat an unconnected endpoint as an error.
Fixes: c893500a16baf ("media: imx: csi: Register a subdev notifier")
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-csi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index e3a4f39dbf73..b276672cae1d 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1815,7 +1815,7 @@ static int imx_csi_parse_endpoint(struct device *dev,
struct v4l2_fwnode_endpoint *vep,
struct v4l2_async_subdev *asd)
{
- return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
+ return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
}
static int imx_csi_async_register(struct csi_priv *priv)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 08/12] media: imx-csi: Allow skipping odd chroma rows for YVU420
Skip writing U/V components to odd rows for YVU420 in addition to YUV420 and NV12. Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel --- drivers/staging/media/imx/imx-media-csi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c index dbc5a92ec073..47568ec43f4a 100644 --- a/drivers/staging/media/imx/imx-media-csi.c +++ b/drivers/staging/media/imx/imx-media-csi.c @@ -452,6 +452,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv) passthrough_bits = 16; break; case V4L2_PIX_FMT_YUV420: + case V4L2_PIX_FMT_YVU420: case V4L2_PIX_FMT_NV12: burst_size = (image.pix.width & 0x3f) ? ((image.pix.width & 0x1f) ? -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v6 02/12] gpu: ipu-csi: Swap fields according to input/output field types
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
csi_setup(), suggested by Philipp.
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 126 +++---
drivers/staging/media/imx/imx-media-csi.c | 7 +-
include/video/imx-ipu-v3.h| 5 +-
3 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+ const struct v4l2_mbus_config *mbus_cfg,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
{
int ret;
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config
*csicfg,
return 0;
}
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ const struct v4l2_mbus_framefmt *infmt,
+ const struct v4l2_mbus_framefmt *outfmt,
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+ return 0;
+}
+
+
int ipu_csi_init_interface(struct ipu_csi *csi,
- struct v4l2_mbus_config *mbus_cfg,
- struct v4l2_mbus_framefmt *mbus_fmt)
+
[PATCH v6 04/12] media: imx: Fix field negotiation
IDMAC interlaced scan, a.k.a. interweave, should be enabled in the
IDMAC output channels only if the IDMAC output pad field type is
'seq-bt' or 'seq-tb', and field type at the capture interface is
'interlaced*'.
V4L2_FIELD_HAS_BOTH() macro should not be used on the input to determine
enabling interlaced/interweave scan. That macro includes the 'interlaced'
field types, and in those cases the data is already interweaved with
top/bottom field lines.
The CSI will capture whole frames when the source specifies alternate
field mode. So the CSI also enables interweave for alternate input
field type and the field type at capture interface is interlaced.
Fix the logic for setting field type in try_fmt in CSI entity.
The behavior should be:
- No restrictions on field type at sink pad.
- At the output pads, allow sequential fields in TB order, if the sink pad
field type is sequential or alternate. Otherwise passthrough the field
type from sink to source pad.
Move this logic to new function csi_try_field().
These changes result in the following allowed field transformations
from CSI sink -> source pads (all other field types at sink are passed
through to source):
seq-tb -> seq-tb
seq-bt -> seq-tb
alternate -> seq-tb
In a future patch, the CSI sink -> source will allow:
seq-tb -> seq-bt
seq-bt -> seq-bt
alternate -> seq-bt
This will require supporting interweave with top/bottom line swapping.
Until then seq-bt is not allowed at the CSI source pad because there is
no way to swap top/bottom lines when interweaving to INTERLACED_BT --
note that despite the name, INTERLACED_BT is top-bottom order in memory.
The BT in this case refers to field dominance: the bottom lines are
older in time than the top lines.
The capture interface device allows selecting IDMAC interweave by
choosing INTERLACED_TB if the CSI/PRPENCVF source pad is seq-tb and
INTERLACED_BT if the source pad is seq-bt (for future support of seq-bt).
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 21 --
drivers/staging/media/imx/imx-media-capture.c | 14
drivers/staging/media/imx/imx-media-csi.c | 64 ++-
3 files changed, 76 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index af7224846bd5..1a03d4c9d7b8 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -354,12 +354,13 @@ static int prp_setup_channel(struct prp_priv *priv,
{
struct imx_media_video_dev *vdev = priv->vdev;
const struct imx_media_pixfmt *outcc;
- struct v4l2_mbus_framefmt *infmt;
+ struct v4l2_mbus_framefmt *outfmt;
unsigned int burst_size;
struct ipu_image image;
+ bool interweave;
int ret;
- infmt = &priv->format_mbus[PRPENCVF_SINK_PAD];
+ outfmt = &priv->format_mbus[PRPENCVF_SRC_PAD];
outcc = vdev->cc;
ipu_cpmem_zero(channel);
@@ -369,6 +370,15 @@ static int prp_setup_channel(struct prp_priv *priv,
image.rect.width = image.pix.width;
image.rect.height = image.pix.height;
+ /*
+* If the field type at capture interface is interlaced, and
+* the output IDMAC pad is sequential, enable interweave at
+* the IDMAC output channel.
+*/
+ interweave = V4L2_FIELD_IS_INTERLACED(image.pix.field) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfmt->field) &&
+ channel == priv->out_ch;
+
if (rot_swap_width_height) {
swap(image.pix.width, image.pix.height);
swap(image.rect.width, image.rect.height);
@@ -409,9 +419,7 @@ static int prp_setup_channel(struct prp_priv *priv,
if (rot_mode)
ipu_cpmem_set_rotation(channel, rot_mode);
- if (image.pix.field == V4L2_FIELD_NONE &&
- V4L2_FIELD_HAS_BOTH(infmt->field) &&
- channel == priv->out_ch)
+ if (interweave)
ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
image.pix.pixelformat);
@@ -839,8 +847,7 @@ static void prp_try_fmt(struct prp_priv *priv,
infmt = __prp_get_fmt(priv, cfg, PRPENCVF_SINK_PAD, sdformat->which);
if (sdformat->pad == PRPENCVF_SRC_PAD) {
- if (sdformat->format.field != V4L2_FIELD_NONE)
- sdformat->format.field = infmt->field;
+ sdformat->format.field = infmt->field;
prp_bound_align_output(&sdformat->format, infmt,
priv->rot_mode);
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index b37e1186eb2f..01ec9443de55 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -239,6 +239,20 @@ static int capture_try_fmt_vid_cap(struct file
[PATCH v6 10/12] media: imx-csi: Move crop/compose reset after filling default mbus fields
If caller passes un-initialized field type V4L2_FIELD_ANY to CSI
sink pad, the reset CSI crop window would not be correct, because
the crop window depends on a valid input field type. To fix move
the reset of crop and compose windows to after the call to
imx_media_fill_default_mbus_fields().
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
drivers/staging/media/imx/imx-media-csi.c | 27 ---
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 47568ec43f4a..7afb7e367d76 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1409,19 +1409,6 @@ static void csi_try_fmt(struct csi_priv *priv,
W_ALIGN, &sdformat->format.height,
MIN_H, MAX_H, H_ALIGN, S_ALIGN);
- /* Reset crop and compose rectangles */
- crop->left = 0;
- crop->top = 0;
- crop->width = sdformat->format.width;
- crop->height = sdformat->format.height;
- if (sdformat->format.field == V4L2_FIELD_ALTERNATE)
- crop->height *= 2;
- csi_try_crop(priv, crop, cfg, &sdformat->format, upstream_ep);
- compose->left = 0;
- compose->top = 0;
- compose->width = crop->width;
- compose->height = crop->height;
-
*cc = imx_media_find_mbus_format(sdformat->format.code,
CS_SEL_ANY, true);
if (!*cc) {
@@ -1437,6 +1424,20 @@ static void csi_try_fmt(struct csi_priv *priv,
imx_media_fill_default_mbus_fields(
&sdformat->format, infmt,
priv->active_output_pad == CSI_SRC_PAD_DIRECT);
+
+ /* Reset crop and compose rectangles */
+ crop->left = 0;
+ crop->top = 0;
+ crop->width = sdformat->format.width;
+ crop->height = sdformat->format.height;
+ if (sdformat->format.field == V4L2_FIELD_ALTERNATE)
+ crop->height *= 2;
+ csi_try_crop(priv, crop, cfg, &sdformat->format, upstream_ep);
+ compose->left = 0;
+ compose->top = 0;
+ compose->width = crop->width;
+ compose->height = crop->height;
+
break;
}
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: Sasha Levin writes: On Mon, Jan 07, 2019 at 02:44:30PM +0100, Vitaly Kuznetsov wrote: P.S. I still think about bringing mem_hotplug_begin()/done() to hv_balloon but that's going to be a separate discussion, here I want to have a small fix backportable to stable. This should probably be marked for stable then :) Yes, please :-) Queued up for hyperv-fixes with a -stable tag, thank you! -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 44/97] staging: erofs: fix use-after-free of on-stack `z_erofs_vle_unzip_io'
From: Gao Xiang
[ Upstream commit 848bd9acdcd00c164b42b14aacec242949ecd471 ]
The root cause is the race as follows:
Thread #0 Thread #1
z_erofs_vle_unzip_kickoff z_erofs_submit_and_unzip
struct z_erofs_vle_unzip_io io[]
atomic_add_return()
wait_event()
[end of function]
wake_up()
Fix it by taking the waitqueue lock between atomic_add_return and
wake_up to close such the race.
kernel message:
Unable to handle kernel paging request at virtual address 97f7052caa1303dc
...
Workqueue: kverityd verity_work
task: ffe32bcb8000 task.stack: ffe3298a
PC is at __wake_up_common+0x48/0xa8
LR is at __wake_up+0x3c/0x58
...
Call trace:
...
[] __wake_up_common+0x48/0xa8
[] __wake_up+0x3c/0x58
[] z_erofs_vle_unzip_kickoff+0x40/0x64
[] z_erofs_vle_read_endio+0x94/0x134
[] bio_endio+0xe4/0xf8
[] dec_pending+0x134/0x32c
[] clone_endio+0x90/0xf4
[] bio_endio+0xe4/0xf8
[] verity_work+0x210/0x368
[] process_one_work+0x188/0x4b4
[] worker_thread+0x140/0x458
[] kthread+0xec/0x108
[] ret_from_fork+0x10/0x1c
Code: d1006273 54000260 f9400804 b9400019 (b85fc081)
---[ end trace be9dde154f677cd1 ]---
Reviewed-by: Chao Yu
Signed-off-by: Gao Xiang
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/erofs/unzip_vle.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/erofs/unzip_vle.c
b/drivers/staging/erofs/unzip_vle.c
index 14da8cc2246a..0346630b67c8 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -724,13 +724,18 @@ static void z_erofs_vle_unzip_kickoff(void *ptr, int bios)
struct z_erofs_vle_unzip_io *io = tagptr_unfold_ptr(t);
bool background = tagptr_unfold_tags(t);
- if (atomic_add_return(bios, &io->pending_bios))
+ if (!background) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&io->u.wait.lock, flags);
+ if (!atomic_add_return(bios, &io->pending_bios))
+ wake_up_locked(&io->u.wait);
+ spin_unlock_irqrestore(&io->u.wait.lock, flags);
return;
+ }
- if (background)
+ if (!atomic_add_return(bios, &io->pending_bios))
queue_work(z_erofs_workqueue, &io->u.work);
- else
- wake_up(&io->u.wait);
}
static inline void z_erofs_vle_read_endio(struct bio *bio)
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.20 055/117] staging: erofs: fix use-after-free of on-stack `z_erofs_vle_unzip_io'
From: Gao Xiang
[ Upstream commit 848bd9acdcd00c164b42b14aacec242949ecd471 ]
The root cause is the race as follows:
Thread #0 Thread #1
z_erofs_vle_unzip_kickoff z_erofs_submit_and_unzip
struct z_erofs_vle_unzip_io io[]
atomic_add_return()
wait_event()
[end of function]
wake_up()
Fix it by taking the waitqueue lock between atomic_add_return and
wake_up to close such the race.
kernel message:
Unable to handle kernel paging request at virtual address 97f7052caa1303dc
...
Workqueue: kverityd verity_work
task: ffe32bcb8000 task.stack: ffe3298a
PC is at __wake_up_common+0x48/0xa8
LR is at __wake_up+0x3c/0x58
...
Call trace:
...
[] __wake_up_common+0x48/0xa8
[] __wake_up+0x3c/0x58
[] z_erofs_vle_unzip_kickoff+0x40/0x64
[] z_erofs_vle_read_endio+0x94/0x134
[] bio_endio+0xe4/0xf8
[] dec_pending+0x134/0x32c
[] clone_endio+0x90/0xf4
[] bio_endio+0xe4/0xf8
[] verity_work+0x210/0x368
[] process_one_work+0x188/0x4b4
[] worker_thread+0x140/0x458
[] kthread+0xec/0x108
[] ret_from_fork+0x10/0x1c
Code: d1006273 54000260 f9400804 b9400019 (b85fc081)
---[ end trace be9dde154f677cd1 ]---
Reviewed-by: Chao Yu
Signed-off-by: Gao Xiang
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/erofs/unzip_vle.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/erofs/unzip_vle.c
b/drivers/staging/erofs/unzip_vle.c
index 79d3ba62b298..45e88bada907 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -717,13 +717,18 @@ static void z_erofs_vle_unzip_kickoff(void *ptr, int bios)
struct z_erofs_vle_unzip_io *io = tagptr_unfold_ptr(t);
bool background = tagptr_unfold_tags(t);
- if (atomic_add_return(bios, &io->pending_bios))
+ if (!background) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&io->u.wait.lock, flags);
+ if (!atomic_add_return(bios, &io->pending_bios))
+ wake_up_locked(&io->u.wait);
+ spin_unlock_irqrestore(&io->u.wait.lock, flags);
return;
+ }
- if (background)
+ if (!atomic_add_return(bios, &io->pending_bios))
queue_work(z_erofs_workqueue, &io->u.work);
- else
- wake_up(&io->u.wait);
}
static inline void z_erofs_vle_read_endio(struct bio *bio)
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.20 056/117] media: cedrus: don't initialize pointers with zero
From: Mauro Carvalho Chehab
[ Upstream commit e4d7b113fdccde1acf8638c5879f2a450d492303 ]
A common mistake is to assume that initializing a var with:
struct foo f = { 0 };
Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.
According to C99 Standard 6.7.8.21:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:
drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
warning: Using plain integer as NULL pointer
drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
warning: Using plain integer as NULL pointer
As the right initialization would be, instead:
struct foo f = { NULL };
Another way to initialize it with gcc is to use:
struct foo f = {};
That seems to be a gcc extension, but clang also does the right thing,
and that's a clean way for doing it.
Anyway, I decided to check upstream what's the most commonly pattern.
The "= {}" pattern has about 2000 entries:
$ git grep -E "=\s*\{\s*\}"|wc -l
1951
The standard-C compliant pattern has about 2500 entries:
$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323
Meaning that developers have split options on that.
So, let's opt to the simpler form.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Paul Kocialkowski
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index c912c70b3ef7..f18077e8810a 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
- struct v4l2_ctrl_config cfg = { 0 };
+ struct v4l2_ctrl_config cfg = {};
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..f10c25f5460e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
- struct cedrus_run run = { 0 };
+ struct cedrus_run run = {};
struct media_request *src_req;
unsigned long flags;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: imx: queue subdev events to reachable video devices
Hi Hans,
On 1/8/19 5:26 AM, Hans Verkuil wrote:
On 12/09/18 20:57, Steve Longerbeam wrote:
From: Steve Longerbeam
Forward events from a sub-device to its list of reachable video
devices.
Note this will queue the event to a video device even if there is
no actual _enabled_ media path from the sub-device to the video device.
So a future improvement is to skip the video device if there is no enabled
path to it from the sub-device. The entity->pipe pointer can't be
used for this check because in imx-media a sub-device can be a
member to more than one streaming pipeline at a time.
You explain what you are doing, but I am missing an explanation of *why*
this is needed.
Ok, I'll add more explanation.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-capture.c | 18 ++
drivers/staging/media/imx/imx-media-dev.c | 24 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index b37e1186eb2f..4dfbe05d203e 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -335,6 +335,21 @@ static int capture_s_parm(struct file *file, void *fh,
return 0;
}
+static int capture_subscribe_event(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub)
+{
+ switch (sub->type) {
+ case V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR:
+ return v4l2_event_subscribe(fh, sub, 0, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
+ case V4L2_EVENT_CTRL:
+ return v4l2_ctrl_subscribe_event(fh, sub);
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_querycap= vidioc_querycap,
@@ -362,6 +377,9 @@ static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
+
+ .vidioc_subscribe_event = capture_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
This part of the patch adds event support to the capture device, can't this be
split up into a separate patch? It seems to be useful in its own right.
Ok, I will split this up. The first patch will add the
(un)subscribe_event callbacks to the capture device, and the second
patch will forward subdev events.
/*
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 4b344a4a3706..25e916562c66 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -442,6 +442,29 @@ static const struct media_device_ops imx_media_md_ops = {
.link_notify = imx_media_link_notify,
};
+static void imx_media_notify(struct v4l2_subdev *sd,
+unsigned int notification,
+void *arg)
+{
+ struct media_entity *entity = &sd->entity;
+ int i;
+
+ if (notification != V4L2_DEVICE_NOTIFY_EVENT)
+ return;
+
+ for (i = 0; i < entity->num_pads; i++) {
+ struct media_pad *pad = &entity->pads[i];
+ struct imx_media_pad_vdev *pad_vdev;
+ struct list_head *pad_vdev_list;
+
+ pad_vdev_list = to_pad_vdev_list(sd, pad->index);
+ if (!pad_vdev_list)
+ continue;
+ list_for_each_entry(pad_vdev, pad_vdev_list, list)
+ v4l2_event_queue(pad_vdev->vdev->vfd, arg);
Which events do you want to forward?
Shouldn't any/all subdev events be forwarded?
I would also prefer to allow userland to subscribe to any events that a
subdevice might generate. In other words, imx-media will allow the user
to subscribe to, and receive any events that might be generated by
subdevices.
E.g. forwarding control events
doesn't seem right, but other events may be useful.
The imx capture devices inherit controls from the subdevices. If an
inherited control is changed via the capture device, will _two_ control
events be generated (one from the subdevice and one from the capture
device)? Or will only one event get generated to the capture device?
Same question goes when changing an inherited control from the subdevice
nodes.
Are those events
also appearing on the v4l-subdevX device? And if so, should they?
How do we know what subdevices a future imx-based system might attach to
the media graph? That's why I think it makes sense to forward any/all
events from subdevices.
Steve
+ }
+}
+
static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -462,6 +485,7 @@ static int imx_media_probe(struct platform_d
Re: [PATCH v2] staging: erofs: Add identifier for function definition arguments
On 2019/1/8 21:24, Sidong Yang wrote: > Add identifier for function definition arguments in xattr_iter_handlers, > this change clears the checkpatch.pl issue and make code more explicit. > > Signed-off-by: Sidong Yang personally looks good to me. Reviewed-by: Gao Xiang Thanks, Gao Xiang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Hi Peter
On Tue, 8 Jan 2019 at 07:21, Peter Robinson wrote:
>
> Hi Stefan,
>
> > This patch series improves the load/unload of bcm2835 camera and audio
> > drivers. It has been tested with Raspberry Pi 3 B and a camera module V1.
> >
> > This series based on current linux-next and Phil Elwell's series ("Improve
> > VCHIQ
> > cache line size handling"). After Nicolas' series ("staging: vc04_services:
> > Some dead code removal") has been applied, i will rebase my series.
>
> I tried testing this series applied to 4.20 with the camera module. I
> tried with qv4l2 (from v4l-utils) and using cheese, which in turn uses
> gstreamer. I basically get the same crash for both options. Desktop is
> LXDE on 32 bit Fedora 29.
>
> I've not yet tried with 5.0-rc1 but it looks like it has this patch
> series and some other bits for the vchiq drivers in staging.
I'm trying to sort the patches I have on our kernel tree and get them
in a shape to get merged to staging.
I've built for 5.0.0-rc1 and also see the same error using:
v4l2-ctl -v width=640,height=480,pixelformat=YU12
v4l2-ctl --stream-mmap=3 --stream-to=/dev/null --stream-count=300
It's three independent things:
- The firmware has failed the failed to enable the camera for reasons unknown.
- The error path then hasn't returned all the buffers to videobuf2,
hence the warning from videobuf2-core.c:1468
- The driver has then tried to pass some buffers to MMAL / VCHI which
tries adding them to an invalid list.
I'm investigating why the firmware is failing to enable the camera
initially, and then look at cleaning up the error handling.
Dave
> Peter
>
> [ 231.121704] bcm2835-v4l2: Failed enabling camera, ret -2
> [ 231.127168] bcm2835-v4l2: Failed to enable camera
> [ 231.132030] [ cut here ]
> [ 231.136852] WARNING: CPU: 2 PID: 1473 at
> drivers/media/common/videobuf2/videobuf2-core.c:1468
> vb2_start_streaming+0xb4/0x12c [videobuf2_common]
> [ 231.149967] Modules linked in: fuse ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6
> ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4
> nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack
> nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink
> ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc
> vfat fat brcmfmac brcmutil vc4 cfg80211 snd_soc_core bcm2835_v4l2(C)
> ac97_bus snd_bcm2835(C) videobuf2_vmalloc snd_pcm_dmaengine
> videobuf2_memops snd_seq videobuf2_v4l2 videobuf2_common
> snd_seq_device v4l2_common snd_pcm videodev media snd_timer snd
> soundcore drm_kms_helper drm hci_uart btqca joydev btbcm btintel
> fb_sys_fops syscopyarea bluetooth sysfillrect gpio_raspberrypi_exp
> sysimgblt raspberrypi_hwmon bcm2835_thermal ecdh_generic vchiq(C)
> rfkill bcm2835_wdt bcm2835_rng leds_gpio cpufreq_dt lz4 lz4_compress
> zram hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii mmc_block
> dwc2 sdhci_iproc crc32_arm_ce
> [ 231.150208] sdhci_pltfm udc_core sdhci bcm2835 pwm_bcm2835
> i2c_bcm2835 bcm2835_dma phy_generic
> [ 231.248013] CPU: 2 PID: 1473 Comm: qv4l2 Tainted: G C
> 4.20.0-1.fc30.armv7hl #1
> [ 231.256663] Hardware name: BCM2835
> [ 231.260144] [] (unwind_backtrace) from []
> (show_stack+0x18/0x1c)
> [ 231.268013] [] (show_stack) from []
> (dump_stack+0x80/0xa0)
> [ 231.275357] [] (dump_stack) from [] (__warn+0xdc/0xf8)
> [ 231.282349] [] (__warn) from []
> (warn_slowpath_null+0x40/0x4c)
> [ 231.290067] [] (warn_slowpath_null) from []
> (vb2_start_streaming+0xb4/0x12c [videobuf2_common])
> [ 231.300747] [] (vb2_start_streaming [videobuf2_common])
> from [] (vb2_core_streamon+0x110/0x138 [videobuf2_common])
> [ 231.313166] [] (vb2_core_streamon [videobuf2_common])
> from [] (__video_do_ioctl+0x35c/0x494 [videodev])
> [ 231.324681] [] (__video_do_ioctl [videodev]) from
> [] (video_usercopy+0x508/0x5d4 [videodev])
> [ 231.335120] [] (video_usercopy [videodev]) from
> [] (vfs_ioctl+0x28/0x3c)
> [ 231.343697] [] (vfs_ioctl) from []
> (do_vfs_ioctl+0x8c/0x838)
> [ 231.351212] [] (do_vfs_ioctl) from []
> (ksys_ioctl+0x58/0x74)
> [ 231.358726] [] (ksys_ioctl) from []
> (ret_fast_syscall+0x0/0x54)
> [ 231.366493] Exception stack(0xd7d53fa8 to 0xd7d53ff0)
> [ 231.371623] 3fa0: 4a1bf700 b5edd000 000c
> 40045612 be905378 0001
> [ 231.379930] 3fc0: 4a1bf700 b5edd000 40045612 0036 b5e40e40
> 000c b6f00508
> [ 231.388230] 3fe0: be905378 be905368 b5ec6804 b5b9a1f0
> [ 231.393434] ---[ end trace c5943cec7bb25669 ]---
> [ 237.695591] list_add corruption. prev->next should be next
> (ea4493e0), but was efeb6638. (prev=e126fa78).
> [ 237.705362] [ cut here ]
> [ 237.710056] kernel BUG at lib/list_debug.c:28!
> [ 237.714569] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 237.719785] Modules linked in: fuse ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6
> ip
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
Dan Carpenter writes: > On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: >> (I remember Greg disliked when people were tagging patches for stable@ >> themselves, he prefered maintainers deciding if the particular commit >> deserves stable@ or not - but as you have a tree now we may as well have >> different rules :-) > > You're thinking of Dave Miller. So far as I know he's the only > maintainer who handles stable that way. This may actually be the case, you think "one of the the mighty Linux overlords" but your fingers type "Greg" instread. Sorry for the confusion :-) -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: general protection fault in spk_ttyio_ldisc_close
Greg KH, le mar. 08 janv. 2019 15:25:07 +0100, a ecrit: > On Tue, Jan 08, 2019 at 09:15:02AM -0500, Kyungtae Kim wrote: > > On Tue, Jan 8, 2019 at 8:50 AM Greg KH wrote: > > > > > > On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote: > > > > We report a bug in linux-4.20: "general protection fault in > > > > spk_ttyio_ldisc_close" > > > > > > > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable > > > > repro: https://kt0755.github.io/etc/repro.a670e.c > > > > > > > > This occurs when the function kfree is about to execute > > > > (driver/staging/speakup/spk_ttyio.c:68). > > > > Particularly, kfree takes the argument like speakup_tty->disc_data. > > > > But speakup_tty is invalid, so the pointer dereference causes GPF. > > > > At a glance, it seems that speakup_tty was deallocated somewhere ahead > > > > of kfree. > > > > > > How did you trigger this? Did you shut down and close the device > > > already somehow? Do you have a real tty device that is driven by the > > > device? > > > > > > thanks, > > > > > > greg k-h > > > > For this crash, we did without real speakup tty device. > > How did you bind a non-real speakup tty device to the driver? One can tell any device name to the driver and it will attempt to communicate with it. Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: general protection fault in spk_ttyio_ldisc_close
On Tue, Jan 08, 2019 at 09:15:02AM -0500, Kyungtae Kim wrote: > On Tue, Jan 8, 2019 at 8:50 AM Greg KH wrote: > > > > On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote: > > > We report a bug in linux-4.20: "general protection fault in > > > spk_ttyio_ldisc_close" > > > > > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable > > > repro: https://kt0755.github.io/etc/repro.a670e.c > > > > > > This occurs when the function kfree is about to execute > > > (driver/staging/speakup/spk_ttyio.c:68). > > > Particularly, kfree takes the argument like speakup_tty->disc_data. > > > But speakup_tty is invalid, so the pointer dereference causes GPF. > > > At a glance, it seems that speakup_tty was deallocated somewhere ahead of > > > kfree. > > > > How did you trigger this? Did you shut down and close the device > > already somehow? Do you have a real tty device that is driven by the > > device? > > > > thanks, > > > > greg k-h > > For this crash, we did without real speakup tty device. How did you bind a non-real speakup tty device to the driver? > I'm currently trying to figure out how this actually happens. That would be great to figure out :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: general protection fault in spk_ttyio_ldisc_close
On Tue, Jan 8, 2019 at 8:50 AM Greg KH wrote: > > On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote: > > We report a bug in linux-4.20: "general protection fault in > > spk_ttyio_ldisc_close" > > > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable > > repro: https://kt0755.github.io/etc/repro.a670e.c > > > > This occurs when the function kfree is about to execute > > (driver/staging/speakup/spk_ttyio.c:68). > > Particularly, kfree takes the argument like speakup_tty->disc_data. > > But speakup_tty is invalid, so the pointer dereference causes GPF. > > At a glance, it seems that speakup_tty was deallocated somewhere ahead of > > kfree. > > How did you trigger this? Did you shut down and close the device > already somehow? Do you have a real tty device that is driven by the > device? > > thanks, > > greg k-h For this crash, we did without real speakup tty device. I'm currently trying to figure out how this actually happens. Thanks, Kyungtae Kim ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: general protection fault in spk_ttyio_ldisc_close
On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote: > We report a bug in linux-4.20: "general protection fault in > spk_ttyio_ldisc_close" > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable > repro: https://kt0755.github.io/etc/repro.a670e.c > > This occurs when the function kfree is about to execute > (driver/staging/speakup/spk_ttyio.c:68). > Particularly, kfree takes the argument like speakup_tty->disc_data. > But speakup_tty is invalid, so the pointer dereference causes GPF. > At a glance, it seems that speakup_tty was deallocated somewhere ahead of > kfree. How did you trigger this? Did you shut down and close the device already somehow? Do you have a real tty device that is driven by the device? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
general protection fault in spk_ttyio_ldisc_close
We report a bug in linux-4.20: "general protection fault in spk_ttyio_ldisc_close" kernel config: https://kt0755.github.io/etc/config_v4.20_stable repro: https://kt0755.github.io/etc/repro.a670e.c This occurs when the function kfree is about to execute (driver/staging/speakup/spk_ttyio.c:68). Particularly, kfree takes the argument like speakup_tty->disc_data. But speakup_tty is invalid, so the pointer dereference causes GPF. At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree. = general protection fault: [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 13246 Comm: syz-executor7 Not tainted 4.20.0-rc2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 RIP: 0010:spk_ttyio_ldisc_close+0x3f/0x80 drivers/staging/speakup/spk_ttyio.c:68 Code: 35 95 8c e8 43 03 60 01 48 8b 1d dc 2e 3f 07 48 ba 00 00 00 00 00 fc ff df 48 8d bb 70 05 00 00 48 89 f8 48 c1 e8 03 48 01 d0 <80> 38 00 75 26 48 8b bb 70 05 00 00 e8 a0 68 4f fa 48 c7 c7 c0 35 RSP: 0018:88810e6f7960 EFLAGS: 00010282 RAX: dcae RBX: RCX: 111021cdef00 RDX: dc00 RSI: 0008 RDI: 0570 RBP: 88810e6f7968 R08: fbfff192a6b9 R09: fbfff192a6b9 R10: 88810e6f7950 R11: fbfff192a6b8 R12: 8881063ee6b0 R13: 87471020 R14: 8881063eeea8 R15: 888116ec7b80 FS: 7f607f746700() GS:88811a00() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 006fb2e0 CR3: 00010f186000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: tty_ldisc_close drivers/tty/tty_ldisc.c:477 [inline] tty_ldisc_kill+0xef/0x1a0 drivers/tty/tty_ldisc.c:623 tty_ldisc_release+0x111/0x230 drivers/tty/tty_ldisc.c:790 tty_release_struct+0x1f/0x60 drivers/tty/tty_io.c:1595 tty_release+0xb80/0x11c0 drivers/tty/tty_io.c:1768 __fput+0x2b8/0x7a0 fs/file_table.c:278 fput+0x1a/0x20 fs/file_table.c:309 task_work_run+0x15b/0x1e0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x8d6/0x30d0 kernel/exit.c:867 do_group_exit+0x13d/0x370 kernel/exit.c:970 get_signal+0x6bb/0x1890 kernel/signal.c:2517 do_signal+0x8c/0x1a10 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x186/0x1d0 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x445/0x4f0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4497b9 Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f607f745ce8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: fe00 RBX: 0071bf80 RCX: 004497b9 RDX: RSI: RDI: 0071bf80 RBP: 0071bf80 R08: R09: 0071bf58 R10: R11: 0246 R12: R13: R14: 7f607f7469c0 R15: 7f607f746700 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) = Thanks, Kyungtae Kim ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: imx: queue subdev events to reachable video devices
On 12/09/18 20:57, Steve Longerbeam wrote:
> From: Steve Longerbeam
>
> Forward events from a sub-device to its list of reachable video
> devices.
>
> Note this will queue the event to a video device even if there is
> no actual _enabled_ media path from the sub-device to the video device.
> So a future improvement is to skip the video device if there is no enabled
> path to it from the sub-device. The entity->pipe pointer can't be
> used for this check because in imx-media a sub-device can be a
> member to more than one streaming pipeline at a time.
You explain what you are doing, but I am missing an explanation of *why*
this is needed.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/imx-media-capture.c | 18 ++
> drivers/staging/media/imx/imx-media-dev.c | 24 +++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/staging/media/imx/imx-media-capture.c
> b/drivers/staging/media/imx/imx-media-capture.c
> index b37e1186eb2f..4dfbe05d203e 100644
> --- a/drivers/staging/media/imx/imx-media-capture.c
> +++ b/drivers/staging/media/imx/imx-media-capture.c
> @@ -335,6 +335,21 @@ static int capture_s_parm(struct file *file, void *fh,
> return 0;
> }
>
> +static int capture_subscribe_event(struct v4l2_fh *fh,
> +const struct v4l2_event_subscription *sub)
> +{
> + switch (sub->type) {
> + case V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR:
> + return v4l2_event_subscribe(fh, sub, 0, NULL);
> + case V4L2_EVENT_SOURCE_CHANGE:
> + return v4l2_src_change_event_subscribe(fh, sub);
> + case V4L2_EVENT_CTRL:
> + return v4l2_ctrl_subscribe_event(fh, sub);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static const struct v4l2_ioctl_ops capture_ioctl_ops = {
> .vidioc_querycap= vidioc_querycap,
>
> @@ -362,6 +377,9 @@ static const struct v4l2_ioctl_ops capture_ioctl_ops = {
> .vidioc_expbuf = vb2_ioctl_expbuf,
> .vidioc_streamon= vb2_ioctl_streamon,
> .vidioc_streamoff = vb2_ioctl_streamoff,
> +
> + .vidioc_subscribe_event = capture_subscribe_event,
> + .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
> };
This part of the patch adds event support to the capture device, can't this be
split up into a separate patch? It seems to be useful in its own right.
>
> /*
> diff --git a/drivers/staging/media/imx/imx-media-dev.c
> b/drivers/staging/media/imx/imx-media-dev.c
> index 4b344a4a3706..25e916562c66 100644
> --- a/drivers/staging/media/imx/imx-media-dev.c
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -442,6 +442,29 @@ static const struct media_device_ops imx_media_md_ops = {
> .link_notify = imx_media_link_notify,
> };
>
> +static void imx_media_notify(struct v4l2_subdev *sd,
> + unsigned int notification,
> + void *arg)
> +{
> + struct media_entity *entity = &sd->entity;
> + int i;
> +
> + if (notification != V4L2_DEVICE_NOTIFY_EVENT)
> + return;
> +
> + for (i = 0; i < entity->num_pads; i++) {
> + struct media_pad *pad = &entity->pads[i];
> + struct imx_media_pad_vdev *pad_vdev;
> + struct list_head *pad_vdev_list;
> +
> + pad_vdev_list = to_pad_vdev_list(sd, pad->index);
> + if (!pad_vdev_list)
> + continue;
> + list_for_each_entry(pad_vdev, pad_vdev_list, list)
> + v4l2_event_queue(pad_vdev->vdev->vfd, arg);
Which events do you want to forward? E.g. forwarding control events
doesn't seem right, but other events may be useful. Are those events
also appearing on the v4l-subdevX device? And if so, should they?
> + }
> +}
> +
> static int imx_media_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -462,6 +485,7 @@ static int imx_media_probe(struct platform_device *pdev)
> mutex_init(&imxmd->mutex);
>
> imxmd->v4l2_dev.mdev = &imxmd->md;
> + imxmd->v4l2_dev.notify = imx_media_notify;
> strscpy(imxmd->v4l2_dev.name, "imx-media",
> sizeof(imxmd->v4l2_dev.name));
>
>
Regards,
Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: erofs: Add identifier for function definition arguments
Add identifier for function definition arguments in xattr_iter_handlers,
this change clears the checkpatch.pl issue and make code more explicit.
Signed-off-by: Sidong Yang
---
drivers/staging/erofs/xattr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/erofs/xattr.c b/drivers/staging/erofs/xattr.c
index 80dca6a4adbe..59bc5641c4e7 100644
--- a/drivers/staging/erofs/xattr.c
+++ b/drivers/staging/erofs/xattr.c
@@ -117,10 +117,12 @@ static int init_inode_xattrs(struct inode *inode)
*and need to be handled
*/
struct xattr_iter_handlers {
- int (*entry)(struct xattr_iter *, struct erofs_xattr_entry *);
- int (*name)(struct xattr_iter *, unsigned int, char *, unsigned int);
- int (*alloc_buffer)(struct xattr_iter *, unsigned int);
- void (*value)(struct xattr_iter *, unsigned int, char *, unsigned int);
+ int (*entry)(struct xattr_iter *_it, struct erofs_xattr_entry *entry);
+ int (*name)(struct xattr_iter *_it, unsigned int processed, char *buf,
+ unsigned int len);
+ int (*alloc_buffer)(struct xattr_iter *_it, unsigned int value_sz);
+ void (*value)(struct xattr_iter *_it, unsigned int processed, char *buf,
+ unsigned int len);
};
static inline int xattr_iter_fixup(struct xattr_iter *it)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: erofs: fixed -Wmissing-prototype warnings by making functions static.
Define three functions which are not used outside their own
translation-units as static in order to fix the following warnings:
drivers/staging/erofs/utils.c:134:6: warning: no previous prototype for
‘erofs_try_to_release_workgroup’ [-Wmissing-prototypes]
bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
^~
drivers/staging/erofs/unzip_vle.c:592:6: warning: no previous prototype for
‘z_erofs_vle_work_release’ [-Wmissing-prototypes]
void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
^~~~
drivers/staging/erofs/unzip_vle_lz4.c:16:5: warning: no previous prototype
for ‘z_erofs_unzip_lz4’ [-Wmissing-prototypes]
int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
^
Signed-off-by: Jeremy Sowden
---
drivers/staging/erofs/unzip_vle.c | 2 +-
drivers/staging/erofs/unzip_vle_lz4.c | 2 +-
drivers/staging/erofs/utils.c | 12 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/erofs/unzip_vle.c
b/drivers/staging/erofs/unzip_vle.c
index 4ac1099a39c6..584612b47369 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -589,7 +589,7 @@ static void __z_erofs_vle_work_release(struct
z_erofs_vle_workgroup *grp,
erofs_workgroup_put(&grp->obj);
}
-void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
+static void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
{
struct z_erofs_vle_workgroup *grp =
z_erofs_vle_work_workgroup(work, true);
diff --git a/drivers/staging/erofs/unzip_vle_lz4.c
b/drivers/staging/erofs/unzip_vle_lz4.c
index 52797bd89da1..8e8d705a6861 100644
--- a/drivers/staging/erofs/unzip_vle_lz4.c
+++ b/drivers/staging/erofs/unzip_vle_lz4.c
@@ -13,7 +13,7 @@
#include "unzip_vle.h"
#include
-int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
+static int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
{
int ret = LZ4_decompress_safe_partial(in, out, inlen, outlen, outlen);
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index b535898ca753..fc30025ef101 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -131,9 +131,9 @@ static void erofs_workgroup_unfreeze_final(struct
erofs_workgroup *grp)
__erofs_workgroup_free(grp);
}
-bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
- struct erofs_workgroup *grp,
- bool cleanup)
+static bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
+ struct erofs_workgroup *grp,
+ bool cleanup)
{
/*
* for managed cache enabled, the refcount of workgroups
@@ -172,9 +172,9 @@ bool erofs_try_to_release_workgroup(struct erofs_sb_info
*sbi,
#else
/* for nocache case, no customized reclaim path at all */
-bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
- struct erofs_workgroup *grp,
- bool cleanup)
+static bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
+ struct erofs_workgroup *grp,
+ bool cleanup)
{
int cnt = atomic_read(&grp->refcount);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] staging: erofs: fixed -Wmissing-prototype warnings.
Fixes for -Wmissing-prototype warnings in the erofs driver. One group of functions have been made static; for the second, prototypes have been moved to a header file. Changes since v1: * amended commit messages to ensure distinct e-mail subjects. Jeremy Sowden (2): staging: erofs: fixed -Wmissing-prototype warnings by making functions static. staging: erofs: fixed -Wmissing-prototype warnings by moving prototypes to header file. drivers/staging/erofs/data.c | 6 -- drivers/staging/erofs/internal.h | 7 +++ drivers/staging/erofs/unzip_vle.c | 2 +- drivers/staging/erofs/unzip_vle_lz4.c | 2 +- drivers/staging/erofs/utils.c | 14 ++ 5 files changed, 15 insertions(+), 16 deletions(-) base-commit: c8c2702409430a6a2fd928e857f15773aaafcc99 -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: erofs: fixed -Wmissing-prototype warnings by moving prototypes to header file.
Moved prototypes for two functions to a header file in order to fix the
following warnings:
drivers/staging/erofs/unzip_vle.c:577:6: warning: no previous prototype for
‘erofs_workgroup_free_rcu’ [-Wmissing-prototypes]
void erofs_workgroup_free_rcu(struct erofs_workgroup *grp)
^~~~
drivers/staging/erofs/unzip_vle.c:1702:5: warning: no previous prototype for
‘z_erofs_map_blocks_iter’ [-Wmissing-prototypes]
int z_erofs_map_blocks_iter(struct inode *inode,
^~~
Signed-off-by: Jeremy Sowden
---
drivers/staging/erofs/data.c | 6 --
drivers/staging/erofs/internal.h | 7 +++
drivers/staging/erofs/utils.c| 2 --
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/erofs/data.c b/drivers/staging/erofs/data.c
index 5a55f0bfdfbb..329fa4fa3e9c 100644
--- a/drivers/staging/erofs/data.c
+++ b/drivers/staging/erofs/data.c
@@ -165,12 +165,6 @@ static int erofs_map_blocks_flatmode(struct inode *inode,
return err;
}
-#ifdef CONFIG_EROFS_FS_ZIP
-extern int z_erofs_map_blocks_iter(struct inode *,
- struct erofs_map_blocks *,
- struct page **, int);
-#endif
-
int erofs_map_blocks_iter(struct inode *inode,
struct erofs_map_blocks *map,
struct page **mpage_ret, int flags)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 49c587383315..192f4028d85d 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -288,6 +288,8 @@ static inline void erofs_workstation_cleanup_all(struct
super_block *sb)
erofs_shrink_workstation(EROFS_SB(sb), ~0UL, true);
}
+extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp);
+
#ifdef EROFS_FS_HAS_MANAGED_CACHE
extern int erofs_try_to_free_all_cached_pages(struct erofs_sb_info *sbi,
struct erofs_workgroup *egrp);
@@ -530,6 +532,11 @@ struct erofs_map_blocks_iter {
struct page *mpage;
};
+#ifdef CONFIG_EROFS_FS_ZIP
+extern int z_erofs_map_blocks_iter(struct inode *,
+ struct erofs_map_blocks *,
+ struct page **, int);
+#endif
static inline struct page *
erofs_get_inline_page(struct inode *inode,
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index fc30025ef101..aed211cd5875 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -104,8 +104,6 @@ int erofs_register_workgroup(struct super_block *sb,
return err;
}
-extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp);
-
static void __erofs_workgroup_free(struct erofs_workgroup *grp)
{
atomic_long_dec(&erofs_global_shrink_cnt);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Hi Peter,
> Peter Robinson hat am 8. Januar 2019 um 09:56
> geschrieben:
>
>
> Hi Stefan,
>
> > > > This patch series improves the load/unload of bcm2835 camera and audio
> > > > drivers. It has been tested with Raspberry Pi 3 B and a camera module
> > > > V1.
> > > >
> > > > This series based on current linux-next and Phil Elwell's series
> > > > ("Improve VCHIQ
> > > > cache line size handling"). After Nicolas' series ("staging:
> > > > vc04_services:
> > > > Some dead code removal") has been applied, i will rebase my series.
> > >
> > > I tried testing this series applied to 4.20 with the camera module.
> >
> > first of all this crash should never happend.
>
> What do you mean by that?
looks like you spotted an issue in the bail out code which is very likely not
fixed yet.
But i assume this wasn't your intention. You want to use the RPi camera with
Linux 4.20.
>
> > But why didn't you applied the series which was actually applied to
> > mainline?
> > Did you apply the rest of Phil's DT series as mentioned in the cover letter?
>
> I'm fairly certain I have Phil's "Improve VCHIQ cache line size
> handling" patch series applied if that's the one you mean, I will
> check (I'm currently dealing with 4 different kernels for maintenance
> so I'm sorry if my memory isn't exact).
That's correct. Btw you will need a recent raspberrypi-firmware (iirc since
10/2018), too.
>
> > > I
> > > tried with qv4l2 (from v4l-utils) and using cheese, which in turn uses
> > > gstreamer.
> >
> > Please provide the exact commandline and version.
>
> That was the command line, it pops up a GUI and then just taking a
> still. The version is the latest upstream which is 1.16.3.
Thanks, i will try to reproduce it.
>
> > > I basically get the same crash for both options. Desktop is
> > > LXDE on 32 bit Fedora 29.
> > >
> > > I've not yet tried with 5.0-rc1 but it looks like it has this patch
> > > series and some other bits for the vchiq drivers in staging.
> >
> > Please try 5.0-rc1 which would be more helpful.
>
> Yes, it's on my list.
>
> > Maybe this sounds like a lame excuse but the intension of this series
> > wasn't to get the driver fully operational. I think this is more Dave's
> > expertise.
>
> Well like so much stuff on the Raspberry Pi there's users that are
> testing it and want to use it so when people bother me I test it and
> provide feedback to the patches, if you don't want feedback I'll stop
> testing and just disable it and send people upstream for details so
> they don't bother me!
Please don't get me wrong. I'm very thankful to all this feedback. I know this
isn't a very thankful job to offer a very close to mainline distribution and
users expect the same behavior like on Raspbian. Without yours and others
feedback we wont get much further.
All i wanted to say was: please don't expect too much. It took nearly a year to
fix this VCHIQ corruption. I think for the audio and camera stuff, we are just
at the beginning ...
So please keep up this good work.
Stefan
>
> Peter
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
Sent from my iPad
> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>>
>> Sent from my iPad
>>
>>> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski
>>> wrote:
>>>
>>> Hi,
>>>
> On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
> On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
> Hi,
>
> On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
>
>>> +
>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE0x01
>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
>>> +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
>>> +
>>> +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
>>> +
>>> +struct v4l2_hevc_dpb_entry {
>>> +__u32buffer_tag;
>>> +__u8rps;
>>> +__u8field_pic;
>>> +__u16pic_order_cnt[2];
>>> +};
Please add a property for reference index, if that rps is not used for
this, some device would request that(not the rockchip one). And
Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
>>>
>>> What exactly is that reference index? Is it a bitstream element or
>>> something deduced from the bitstream?
>>>
>> picture order count(POC) for HEVC and frame_num in AVC. I think it is
>> the number used in list0(P slice and B slice) and list1(B slice).
>
> The picture order count is already the last field of the DPB entry
> structure. There is one for each field picture.
As we are not sure whether there is a field coded slice or CTU, I would hold
this part and else about the field.
>
Adding another buffer_tag for referring the memory of the motion vectors
for each frames. Or a better method is add a meta data to echo picture
buffer, since the picture output is just the same as the original,
display won't care whether the motion vectors are written the button of
picture or somewhere else.
>>>
>>> The motion vectors are passed as part of the raw bitstream data, in the
>>> slices. Is there a case where the motion vectors are coded differently?
>> No, it is an additional cache for decoder, even FFmpeg having such
>> data, I think allwinner must output it into somewhere.
>
> Ah yes I see what you mean! This is handled internally by our driver
> and not exposed to userspace. I don't think it would be a good idea to
> expose this cache or request that userspace allocates it like a video
> buffer.
>
No, usually the driver should allocate, as the user space have no idea on size
of each devices.
But for advantage user, application can fix a broken picture with a proper data
or analysis a object motion from that.
So I would suggest attaching this information to a picture buffer as a meta
data.
>>> +
>>> +struct v4l2_hevc_pred_weight_table {
>>> +__u8luma_log2_weight_denom;
>>> +__s8delta_chroma_log2_weight_denom;
>>> +
>>> +__s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
>>> +__s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
>>> +__s8delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
>>> +__s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
>>> +
>>> +__s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
>>> +__s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
>>> +__s8delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
>>> +__s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
>>> +};
>>> +
Those properties I think are not necessary are applying for the
Rockchip's device, may not work for the others.
>>>
>>> Yes, it's possible that some of the elements are not necessary for some
>>> decoders. What we want is to cover all the elements that might be
>>> required for a decoder.
>> I wonder whether allwinner need that, those sao flag usually ignored
>> by decoder in design. But more is better than less, it is hard to
>> extend a v4l2 structure in the future, maybe a new HEVC profile
>> would bring a new property, it is still too early for HEVC.
>
> Yes this is used by our decoder. The idea is to have all the basic
> bitstream elements in the structures (even if some decoders don't use
> them all) and add others for extension as separate controls later.
>
>>> +struct v4l2_ctrl_hevc_slice_params {
>>> +__u32bit_size;
>>> +__u32data_bit_offset;
>>> +
>>> +/* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
>>> +__u8nal_unit_type;
>>> +__u8nuh_temporal_id_plus1;
>>> +
>>> +/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header
>>> */
>>> +__u8slice_type;
>>> +__u8colour_plane_id;
>>> +__u16slice_pic_order_cnt;
>>> +__u8slice_sao_luma_flag;
>>> +
Re: [PATCH] [v3] staging: rtl8723bs: Clean up dead code
Your subject does work for `git am` but the more normal way to format it is: [PATCH v4] staging: rtl8723bs: Clean up dead code On Mon, Jan 07, 2019 at 05:20:52PM -0600, Aditya Pakki wrote: > rtw_wps_start() is part of dead code due to CONFIG_INTEL_WIDI. > The fix removes the deadcode and replaces the function with NULL > in rtw_private_handler. Identified as part of copy_from_user bug. > > Changes from v1 & 2: > The return value of copy_from_user() is not checked appropriately. > However, maintainers identified the patch fixing the issue is not > required as function rts_wps_start() is dead code and can be removed. > > Signed-off-by: Aditya Pakki > --- The "Changed from" comments need to go here under the --- cut off line. It gets removed from the final kernel git log. That information is just for maintainers to remember what was discussed earlier. It's not needed for the permanent record. > .../staging/rtl8723bs/os_dep/ioctl_linux.c| 34 +-- > 1 file changed, 1 insertion(+), 33 deletions(-) regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: > (I remember Greg disliked when people were tagging patches for stable@ > themselves, he prefered maintainers deciding if the particular commit > deserves stable@ or not - but as you have a tree now we may as well have > different rules :-) You're thinking of Dave Miller. So far as I know he's the only maintainer who handles stable that way. It's a lot of work to do the things Dave does. #understatement regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
David Hildenbrand writes: > On 07.01.19 14:44, Vitaly Kuznetsov wrote: >> David Hildenbrand writes: >> ... >>> On 04.01.19 15:19, Vitaly Kuznetsov wrote: if (start_pfn > has->start_pfn && - !PageReserved(pfn_to_page(start_pfn - 1))) + online_section_nr(pfn_to_section_nr(start_pfn))) hv_bring_pgs_online(has, start_pfn, pgs_ol); } >>> >>> I wonder if you should use pfn_to_online_page() and check for PageOffline(). >>> >>> (I guess online_section_nr() should also do the trick) >> >> I'm worried a bit about racing with mm code here as we're not doing >> mem_hotplug_begin()/done() so I'd slightly prefer keeping >> online_section_nr() (pfn_to_online_page() also uses it but then it gets >> to the particular struct page). Moreover, with pfn_to_online_page() we >> will be looking at some other pfn - because the start_pfn is definitelly >> offline (pre-patch we were looking at start_pfn-1). Just looking at the >> whole section seems cleaner. > > Fine with me. I guess the section can never be offlined as it still > contains reserved pages if not fully "fake-onlined" by HV code already. > > But we could still consider mem_hotplug_begin()/done() as we could have > a online section although online_pages() has not completed yet. So we > could actually touch some "semi onlined section". Yes, exactly, if we race with section onlining here we may never online the tail so it will remain 'semi onlined'. I'm going to propose exporting mem_hotplug_begin()/done() to modules to fix this (in a separate patch because I anticipate some pushback :-) > > Acked-by: David Hildenbrand > Thanks! -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: erofs: fixed -Wmissing-prototype warnings.
On 2019/1/8 17:08, Jeremy Sowden wrote: > On 2019-01-08, at 09:46:18 +0800, Gao Xiang wrote: >> On 2019/1/8 2:25, Jeremy Sowden wrote: >>> Fixes for -Wmissing-prototype warnings in the erofs driver. One >>> group of functions have been made static; for the second, prototypes >>> have been moved to a head >> Is -Wmissing-prototypes required for the current linux kernel? >> I cannot see this warning in my personal kernel compilation... >> >> Functions your fix have already been added proper erofs prefix, >> therefore it wouldn't pollute the global namespace: >> z_erofs_vle_work_release >> z_erofs_unzip_lz4 >> erofs_try_to_release_workgroup >> >> erofs_workgroup_free_rcu >> z_erofs_map_blocks_iter > There was a request for help to fix these warnings on the > driverdev-devel mailing list last Novemeber (I've also attached the > message): > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-November/128432.html > > Currently, the flag is only enabled by passing W=1 to make, but since it > is useful, the idea is to fix all the current warnings and enable it in > the main build. OK, it is fine with me personally too since it has no logic change. I will also take care of W=1 from now on, and thanks for your explanation ;) Thanks, Gao Xiang > > J. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On 07.01.19 14:44, Vitaly Kuznetsov wrote: > David Hildenbrand writes: > >> On 04.01.19 15:19, Vitaly Kuznetsov wrote: >>> Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use >>> 128M. To deal with it we implement partial section onlining by registering >>> custom page onlining callback (hv_online_page()). Later, when more memory >>> arrives we try to online the 'tail' (see hv_bring_pgs_online()). >>> >>> It was found that in some cases this 'tail' onlining causes issues: >>> >>> BUG: Bad page state in process kworker/0:2 pfn:109e3a >>> page:e08344278e80 count:0 mapcount:1 mapping: index:0x0 >>> flags: 0xf8000() >>> raw: 000f8000 dead0100 dead0200 >>> raw: >>> page dumped because: nonzero mapcount >>> ... >>> Workqueue: events hot_add_req [hv_balloon] >>> Call Trace: >>> dump_stack+0x5c/0x80 >>> bad_page.cold.112+0x7f/0xb2 >>> free_pcppages_bulk+0x4b8/0x690 >>> free_unref_page+0x54/0x70 >>> hv_page_online_one+0x5c/0x80 [hv_balloon] >>> hot_add_req.cold.24+0x182/0x835 [hv_balloon] >>> ... >>> >>> Turns out that we now have deferred struct page initialization for memory >>> hotplug so e.g. memory_block_action() in drivers/base/memory.c does >>> pages_correctly_probed() check and in that check it avoids inspecting >>> struct pages and checks sections instead. But in Hyper-V balloon driver we >>> do PageReserved(pfn_to_page()) check and this is now wrong. >>> >>> Switch to checking online_section_nr() instead. >>> >>> Signed-off-by: Vitaly Kuznetsov >>> --- >>> drivers/hv/hv_balloon.c | 10 ++ >>> 1 file changed, 6 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c >>> index 5301fef16c31..7c6349a50ef1 100644 >>> --- a/drivers/hv/hv_balloon.c >>> +++ b/drivers/hv/hv_balloon.c >>> @@ -888,12 +888,14 @@ static unsigned long handle_pg_range(unsigned long >>> pg_start, >>> pfn_cnt -= pgs_ol; >>> /* >>> * Check if the corresponding memory block is already >>> -* online by checking its last previously backed page. >>> -* In case it is we need to bring rest (which was not >>> -* backed previously) online too. >>> +* online. It is possible to observe struct pages still >>> +* being uninitialized here so check section instead. >>> +* In case the section is online we need to bring the >>> +* rest of pfns (which were not backed previously) >>> +* online too. >>> */ >>> if (start_pfn > has->start_pfn && >>> - !PageReserved(pfn_to_page(start_pfn - 1))) >>> + online_section_nr(pfn_to_section_nr(start_pfn))) >>> hv_bring_pgs_online(has, start_pfn, pgs_ol); >>> >>> } >>> >> >> I wonder if you should use pfn_to_online_page() and check for PageOffline(). >> >> (I guess online_section_nr() should also do the trick) > > I'm worried a bit about racing with mm code here as we're not doing > mem_hotplug_begin()/done() so I'd slightly prefer keeping > online_section_nr() (pfn_to_online_page() also uses it but then it gets > to the particular struct page). Moreover, with pfn_to_online_page() we > will be looking at some other pfn - because the start_pfn is definitelly > offline (pre-patch we were looking at start_pfn-1). Just looking at the > whole section seems cleaner. Fine with me. I guess the section can never be offlined as it still contains reserved pages if not fully "fake-onlined" by HV code already. But we could still consider mem_hotplug_begin()/done() as we could have a online section although online_pages() has not completed yet. So we could actually touch some "semi onlined section". Acked-by: David Hildenbrand > > P.S. I still think about bringing mem_hotplug_begin()/done() to > hv_balloon but that's going to be a separate discussion, here I want to > have a small fix backportable to stable. > > Thanks, > -- Thanks, David / dhildenb ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Hi Stefan,
> > > This patch series improves the load/unload of bcm2835 camera and audio
> > > drivers. It has been tested with Raspberry Pi 3 B and a camera module V1.
> > >
> > > This series based on current linux-next and Phil Elwell's series
> > > ("Improve VCHIQ
> > > cache line size handling"). After Nicolas' series ("staging:
> > > vc04_services:
> > > Some dead code removal") has been applied, i will rebase my series.
> >
> > I tried testing this series applied to 4.20 with the camera module.
>
> first of all this crash should never happend.
What do you mean by that?
> But why didn't you applied the series which was actually applied to mainline?
> Did you apply the rest of Phil's DT series as mentioned in the cover letter?
I'm fairly certain I have Phil's "Improve VCHIQ cache line size
handling" patch series applied if that's the one you mean, I will
check (I'm currently dealing with 4 different kernels for maintenance
so I'm sorry if my memory isn't exact).
> > I
> > tried with qv4l2 (from v4l-utils) and using cheese, which in turn uses
> > gstreamer.
>
> Please provide the exact commandline and version.
That was the command line, it pops up a GUI and then just taking a
still. The version is the latest upstream which is 1.16.3.
> > I basically get the same crash for both options. Desktop is
> > LXDE on 32 bit Fedora 29.
> >
> > I've not yet tried with 5.0-rc1 but it looks like it has this patch
> > series and some other bits for the vchiq drivers in staging.
>
> Please try 5.0-rc1 which would be more helpful.
Yes, it's on my list.
> Maybe this sounds like a lame excuse but the intension of this series wasn't
> to get the driver fully operational. I think this is more Dave's expertise.
Well like so much stuff on the Raspberry Pi there's users that are
testing it and want to use it so when people bother me I test it and
provide feedback to the patches, if you don't want feedback I'll stop
testing and just disable it and send people upstream for details so
they don't bother me!
Peter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Hi Peter,
> Peter Robinson hat am 8. Januar 2019 um 08:21
> geschrieben:
>
>
> Hi Stefan,
>
> > This patch series improves the load/unload of bcm2835 camera and audio
> > drivers. It has been tested with Raspberry Pi 3 B and a camera module V1.
> >
> > This series based on current linux-next and Phil Elwell's series ("Improve
> > VCHIQ
> > cache line size handling"). After Nicolas' series ("staging: vc04_services:
> > Some dead code removal") has been applied, i will rebase my series.
>
> I tried testing this series applied to 4.20 with the camera module.
first of all this crash should never happend.
But why didn't you applied the series which was actually applied to mainline?
Did you apply the rest of Phil's DT series as mentioned in the cover letter?
> I
> tried with qv4l2 (from v4l-utils) and using cheese, which in turn uses
> gstreamer.
Please provide the exact commandline and version.
> I basically get the same crash for both options. Desktop is
> LXDE on 32 bit Fedora 29.
>
> I've not yet tried with 5.0-rc1 but it looks like it has this patch
> series and some other bits for the vchiq drivers in staging.
Please try 5.0-rc1 which would be more helpful.
Maybe this sounds like a lame excuse but the intension of this series wasn't to
get the driver fully operational. I think this is more Dave's expertise.
Stefan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
Hi,
On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>
> Sent from my iPad
>
> > On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski
> > wrote:
> >
> > Hi,
> >
> > > On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
> > > > On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
> > > >
> > > > > > +
> > > > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE0x01
> > > > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
> > > > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
> > > > > > +
> > > > > > +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
> > > > > > +
> > > > > > +struct v4l2_hevc_dpb_entry {
> > > > > > +__u32buffer_tag;
> > > > > > +__u8rps;
> > > > > > +__u8field_pic;
> > > > > > +__u16pic_order_cnt[2];
> > > > > > +};
> > >
> > > Please add a property for reference index, if that rps is not used for
> > > this, some device would request that(not the rockchip one). And
> > > Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
> >
> > What exactly is that reference index? Is it a bitstream element or
> > something deduced from the bitstream?
> >
> picture order count(POC) for HEVC and frame_num in AVC. I think it is
> the number used in list0(P slice and B slice) and list1(B slice).
The picture order count is already the last field of the DPB entry
structure. There is one for each field picture.
> > > Adding another buffer_tag for referring the memory of the motion vectors
> > > for each frames. Or a better method is add a meta data to echo picture
> > > buffer, since the picture output is just the same as the original,
> > > display won't care whether the motion vectors are written the button of
> > > picture or somewhere else.
> >
> > The motion vectors are passed as part of the raw bitstream data, in the
> > slices. Is there a case where the motion vectors are coded differently?
> No, it is an additional cache for decoder, even FFmpeg having such
> data, I think allwinner must output it into somewhere.
Ah yes I see what you mean! This is handled internally by our driver
and not exposed to userspace. I don't think it would be a good idea to
expose this cache or request that userspace allocates it like a video
buffer.
> > > > > > +
> > > > > > +struct v4l2_hevc_pred_weight_table {
> > > > > > +__u8luma_log2_weight_denom;
> > > > > > +__s8delta_chroma_log2_weight_denom;
> > > > > > +
> > > > > > +__s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > > > +__s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > > > +__s8
> > > > > > delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > > > +__s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > > > +
> > > > > > +__s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > > > +__s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > > > +__s8
> > > > > > delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > > > +__s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > > > +};
> > > > > > +
> > > Those properties I think are not necessary are applying for the
> > > Rockchip's device, may not work for the others.
> >
> > Yes, it's possible that some of the elements are not necessary for some
> > decoders. What we want is to cover all the elements that might be
> > required for a decoder.
> I wonder whether allwinner need that, those sao flag usually ignored
> by decoder in design. But more is better than less, it is hard to
> extend a v4l2 structure in the future, maybe a new HEVC profile
> would bring a new property, it is still too early for HEVC.
Yes this is used by our decoder. The idea is to have all the basic
bitstream elements in the structures (even if some decoders don't use
them all) and add others for extension as separate controls later.
> > > > > > +struct v4l2_ctrl_hevc_slice_params {
> > > > > > +__u32bit_size;
> > > > > > +__u32data_bit_offset;
> > > > > > +
> > > > > > +/* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
> > > > > > +__u8nal_unit_type;
> > > > > > +__u8nuh_temporal_id_plus1;
> > > > > > +
> > > > > > +/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment
> > > > > > header */
> > > > > > +__u8slice_type;
> > > > > > +__u8colour_plane_id;
> > >
> > > > > > +__u16slice_pic_order_cnt;
> > > > > > +__u8slice_sao_luma_flag;
> > > > > > +__u8slice_sao_chroma_flag;
> > > > > > +__u8slice_temporal_mvp_enabled_flag;
> > > > > > +__u8num_ref_idx_l0_active_minus1;
> > > > > > +__u8num_ref_idx_l1_active_minus1;
> > > Rockchip's decoder doesn't use this part.
> > > > > > +__u8mvd_l1_zero_flag;
> > > > > > +__u8cabac_i
