Re: VIVID/VIMC and media fuzzing
On Fri, Dec 7, 2018 at 8:22 PM Helen Koike wrote: > >>> You also mentioned that one of the devices requires some complex setup > >>> via configfs. Is this interface described somewhere? Do you think it's > >>> more profitable to pre-setup some fixed configuration for each test > >>> process? Or just give the setup interface to fuzzer and let it do > >>> random setup? Or both? > >> > >> That's the vimc driver, but the configfs code isn't in yet. > > > > I'll try to submit it later this week (with documentation) :) > > I submitted the first version at: > https://www.spinics.net/lists/linux-media/msg144244.html > As soon as it is updated we can add it to fuzzer. I believe some > pre-setup/fixed configuration would work. > > I don't know much about fuzzer's code, if you could give me some > pointers I can help with that. Hi Helen, Great! It may be easier to think about this on 2 levels: The first is _what_ we want to do. For this, imagine you are writing a stress test for the subsystem as a C program that does some fixed setup and then executes random syscalls related to the subsystem and acting on the devices using rand() to select syscalls and arguments. What setup would you do for this? What syscalls would you issue? The second is then how to fit this into syzkaller. The setup part in syzkaller is also just custom C code. E.g. this setups network devices for test process: https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L154-L301 There is a little bit of trickery because this code is also used to generate C reproducers for crashes, and it also needs to preferably support multiple independent test processes (namely this code has procid=0..N variable and needs to setup e.g. /dev/loopN device corresponding to current procid). E.g. for vivid we use "vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2". But overall it's just C code. For the main stress/fuzzing we have these declarative descriptions, which are hopefully mostly self-explanatory: https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt If there is something missing, we need to add missing parts. And maybe even give fuzzer the configfs interface too to mess with (it can open specified files and do, say, writes with complex inputs, both binary and text based). Also, will we gain something by enabling the following ones inside of a VM: # CONFIG_V4L_PLATFORM_DRIVERS is not set # CONFIG_V4L_MEM2MEM_DRIVERS is not set ? Or, it's just physical hardware drivers? FTR, here are configs that syzbot uses: https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-selinux.cmdline https://github.com/google/syzkaller/blob/master/dashboard/config/upstream.sysctl Thanks
Re: [PATCH 2/3] media: ov2640: make VIDIOC_SUBDEV_G_FMT ioctl work with V4L2_SUBDEV_FORMAT_TRY
Hi Akinobu,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Akinobu-Mita/media-ov2640-fix-two-problems/20181208-165345
base: git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x011-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/media//i2c/ov2640.c: In function 'ov2640_get_fmt':
>> drivers/media//i2c/ov2640.c:930:8: error: implicit declaration of function
>> 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'?
>> [-Werror=implicit-function-declaration]
mf = v4l2_subdev_get_try_format(sd, cfg, 0);
^~
v4l2_subdev_notify_event
>> drivers/media//i2c/ov2640.c:930:6: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
mf = v4l2_subdev_get_try_format(sd, cfg, 0);
^
drivers/media//i2c/ov2640.c: In function 'ov2640_init_cfg':
>> drivers/media//i2c/ov2640.c:1007:3: warning: initialization makes pointer
>> from integer without a cast [-Wint-conversion]
v4l2_subdev_get_try_format(sd, cfg, 0);
^~
cc1: some warnings being treated as errors
vim +930 drivers/media//i2c/ov2640.c
917
918 static int ov2640_get_fmt(struct v4l2_subdev *sd,
919 struct v4l2_subdev_pad_config *cfg,
920 struct v4l2_subdev_format *format)
921 {
922 struct v4l2_mbus_framefmt *mf = >format;
923 struct i2c_client *client = v4l2_get_subdevdata(sd);
924 struct ov2640_priv *priv = to_ov2640(client);
925
926 if (format->pad)
927 return -EINVAL;
928
929 if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
> 930 mf = v4l2_subdev_get_try_format(sd, cfg, 0);
931 format->format = *mf;
932
933 return 0;
934 }
935
936 mf->width = priv->win->width;
937 mf->height = priv->win->height;
938 mf->code= priv->cfmt_code;
939 mf->colorspace = V4L2_COLORSPACE_SRGB;
940 mf->field = V4L2_FIELD_NONE;
941
942 return 0;
943 }
944
945 static int ov2640_set_fmt(struct v4l2_subdev *sd,
946 struct v4l2_subdev_pad_config *cfg,
947 struct v4l2_subdev_format *format)
948 {
949 struct v4l2_mbus_framefmt *mf = >format;
950 struct i2c_client *client = v4l2_get_subdevdata(sd);
951 struct ov2640_priv *priv = to_ov2640(client);
952 const struct ov2640_win_size *win;
953 int ret = 0;
954
955 if (format->pad)
956 return -EINVAL;
957
958 mutex_lock(>lock);
959
960 /* select suitable win */
961 win = ov2640_select_win(mf->width, mf->height);
962 mf->width = win->width;
963 mf->height = win->height;
964
965 mf->field = V4L2_FIELD_NONE;
966 mf->colorspace = V4L2_COLORSPACE_SRGB;
967
968 switch (mf->code) {
969 case MEDIA_BUS_FMT_RGB565_2X8_BE:
970 case MEDIA_BUS_FMT_RGB565_2X8_LE:
971 case MEDIA_BUS_FMT_YUYV8_2X8:
972 case MEDIA_BUS_FMT_UYVY8_2X8:
973 case MEDIA_BUS_FMT_YVYU8_2X8:
974 case MEDIA_BUS_FMT_VYUY8_2X8:
975 break;
976 default:
977 mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
978 break;
979 }
980
981 if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
982 struct ov2640_priv *priv = to_ov2640(client);
983
984 if (priv->streaming) {
985 ret = -EBUSY;
986 goto out;
987 }
988 /* select win */
989 priv->win = win;
990 /* select format */
991 priv->cfmt_code = mf->code;
992 } else {
993 cfg->try_fmt = *mf;
994 }
995 out:
996 mutex_unlock(>lock);
997
998 return ret;
999 }
1000
1001 static int ov2640_init_cfg(struct v4l2_subdev *sd,
1002 struct v4l2_subdev_pad_config *cfg)
1003 {
1004 struct i2c_client *client = v4l2_get_subdevdata(sd);
1005 struct ov2640_priv *priv = to_ov2640(client);
1006
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Patrick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.20-rc5 next-20181207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Patrick-LERDA/Add-ir-rcmm-driver/20181208-02 base: git://linuxtv.org/media_tree.git master reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info' kernel/rcu/tree.c:685: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf' include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array' include/linux/gpio/driver.h:375: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/iio/hw-consumer.h:1: warning: no structured comments found include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not
Re: [PATCH 1/2] media: pxa_camera: don't deferenciate a NULL pointer
Hi Mauro,
On Fri, Dec 07, 2018 at 08:07:54AM -0500, Mauro Carvalho Chehab wrote:
> As warned by smatch:
> drivers/media/platform/pxa_camera.c:2400 pxa_camera_probe() error: we
> previously assumed 'pcdev->pdata' could be null (see line 2397)
>
> It would be possible that neither DT nor platform data would be
> provided. This is a Kernel bug, so warn about that and bail.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/platform/pxa_camera.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/pxa_camera.c
> b/drivers/media/platform/pxa_camera.c
> index 5f930560eb30..f91f8fd424c4 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2396,6 +2396,9 @@ static int pxa_camera_probe(struct platform_device
> *pdev)
> pcdev->pdata = pdev->dev.platform_data;
> if (pdev->dev.of_node && !pcdev->pdata) {
> err = pxa_camera_pdata_from_dt(>dev, pcdev, >asd);
> + } else if (!pcdev->pdata) {
This fixes the issue, but the current checks remain a bit odd.
The driver seems to prefer platform data over OF. I wonder if that's
intentional or not.
In that case, I'd roughly write this as:
if (pcdev->pdata) {
...;
} else if (pdev->dev.of_node) {
...;
} else {
return -ENODEV;
}
I'm not sure WARN_ON(1) is necessary. A lot of drivers simply do it this
way without WARN_ON().
> + WARN_ON(1);
> + return -ENODEV;
> } else {
> pcdev->platform_flags = pcdev->pdata->flags;
> pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH v5 00/12] imx-media: Fixes for interlaced capture
Hi Hans, On 12/7/18 5:35 AM, Hans Verkuil wrote: Hi Steve, How to proceed with this w.r.t. the two gpu ipu patches? Are those going in first through the gpu tree? Or do they have to go in through our tree? There is only one remaining gpu ipu patch in this series that is awaiting an ack from Philipp: "gpu: ipu-csi: Swap fields according to input/output field types" I pinged him again. Philipp agreed to allow the two ipu patches in the series to be merged to media tree. Steve In that case I need Acks from whoever maintains that code. Regards, Hans On 10/17/2018 02:00 AM, Steve Longerbeam wrote: A set of patches that fixes some bugs with capturing from an interlaced source, and incompatibilites between IDMAC interlace interweaving and 4:2:0 data write reduction. History: v5: - Added a regression fix to allow empty endpoints to CSI (fix for imx6q SabreAuto). - Cleaned up some convoluted code in ipu_csi_init_interface(), suggested by Philipp Zabel. - Fixed a regression in csi_setup(), caught by Philipp. - Removed interweave_offset and replace with boolean interweave_swap, suggested by Philipp. - Make clear that it is IDMAC channel that does pixel reordering and interweave, not the CSI, in the imx.rst doc, caught by Philipp. v4: - rebased to latest media-tree master branch. - Make patch author and SoB email addresses the same. v3: - add support for/fix interweaved scan with YUV planar output. - fix bug in 4:2:0 U/V offset macros. - add patch that generalizes behavior of field swap in ipu_csi_init_interface(). - add support for interweaved scan with field order swap. Suggested by Philipp Zabel. - in v2, inteweave scan was determined using field types of CSI (and PRPENCVF) at the sink and source pads. In v3, this has been moved one hop downstream: interweave is now determined using field type at source pad, and field type selected at capture interface. Suggested by Philipp. - make sure to double CSI crop target height when input field type in alternate. - more updates to media driver doc to reflect above. v2: - update media driver doc. - enable idmac interweave only if input field is sequential/alternate, and output field is 'interlaced*'. - move field try logic out of *try_fmt and into separate function. - fix bug with resetting crop/compose rectangles. - add a patch that fixes a field order bug in VDIC indirect mode. - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro Suggested-by: Nicolas Dufresne . - add macro V4L2_FIELD_IS_INTERLACED(). Steve Longerbeam (12): media: videodev2.h: Add more field helper macros gpu: ipu-csi: Swap fields according to input/output field types gpu: ipu-v3: Add planar support to interlaced scan media: imx: Fix field negotiation media: imx-csi: Input connections to CSI should be optional media: imx-csi: Double crop height for alternate fields at sink media: imx: interweave and odd-chroma-row skip are incompatible media: imx-csi: Allow skipping odd chroma rows for YVU420 media: imx: vdic: rely on VDIC for correct field order media: imx-csi: Move crop/compose reset after filling default mbus fields media: imx: Allow interweave with top/bottom lines swapped media: imx.rst: Update doc to reflect fixes to interlaced capture Documentation/media/v4l-drivers/imx.rst | 103 +++ drivers/gpu/ipu-v3/ipu-cpmem.c| 26 ++- drivers/gpu/ipu-v3/ipu-csi.c | 119 + drivers/staging/media/imx/imx-ic-prpencvf.c | 46 +++-- drivers/staging/media/imx/imx-media-capture.c | 14 ++ drivers/staging/media/imx/imx-media-csi.c | 168 +- drivers/staging/media/imx/imx-media-vdic.c| 12 +- include/uapi/linux/videodev2.h| 7 + include/video/imx-ipu-v3.h| 6 +- 9 files changed, 354 insertions(+), 147 deletions(-)
Re: VIVID/VIMC and media fuzzing
Hi Dmitry, On 10/31/18 9:49 AM, Helen Koike wrote: > Hi Dmitry, > > On 10/31/18 7:46 AM, Hans Verkuil wrote: >> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote: >>> Hello Helen and linux-media, >>> >>> I've attended your talk "Shifting Media App Development into High >>> Gear" on OSS Summit last week and approached you with some questions >>> if/how this can be used for kernel testing. Thanks, turn out to be a >>> very useful talk! > > Great, I am glad it was useful :) > >>> >>> I am working on syzkaller/syzbot, continuous kernel fuzzing system: >>> https://github.com/google/syzkaller >>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md >>> https://syzkaller.appspot.com >>> >>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M, >>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in >>> media subsystem in just 24 hours: >>> >>> KASAN: use-after-free Read in vb2_mmap >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ >>> >>> KASAN: use-after-free Write in __vb2_cleanup_fileio >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ >>> >>> WARNING in __vb2_queue_cancel >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ >>> >>> divide error in vivid_vid_cap_s_dv_timings >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ >> >> Should be fixed by https://patchwork.linuxtv.org/patch/52641/ >> >>> >>> KASAN: use-after-free Read in wake_up_if_idle >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ >>> >>> KASAN: use-after-free Read in __vb2_perform_fileio >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ >>> >>> INFO: task hung in vivid_stop_generating_vid_cap >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ >>> >>> KASAN: null-ptr-deref Write in kthread_stop >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ >> >> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/ >> >> Haven't figured out the others yet (hope to get back to that next week). >> >>> >>> Based on this I think if we put more effort into media fuzzing, it >>> will be able to find dozens more. >> >> Yeah, this is good stuff. Thank you for setting this up. > > Agreed, Dmitry thank you for doing this. > >> >>> >>> syzkaller needs descriptions of kernel interfaces to efficiently cover >>> a subsystem. For example, see: >>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt >>> Hopefully you can read it without much explanation, it basically >>> states that there is that node in /dev and here are ioctls and other >>> syscalls that are relevant for this device and here are types of >>> arguments and layout of involved data structures. >>> >>> Turned we actually have such descriptions for /dev/video* and >>> /dev/v4l-subdev*: >>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt >>> But we don't have anything for /dev/media*, fuzzer merely knows that >>> it can open the device: >>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479 >>> and then it will just blindly execute completely random workload on >>> it, e.g. most likely it won't be able to come up with a proper complex >>> structure layout for some ioctls. And I am actually not completely >>> sure about completeness and coverage of video4linux.txt descriptions >>> too as they were contributed by somebody interested in android >>> testing. >> >> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't >> too bad. There are some differences between the 4.20 videodev2.h and the >> 4.9, but not too many. >> >>> >>> I wonder if somebody knowledgeable in /dev/media interface be willing >>> to contribute additional descriptions? >> >> We'll have to wait for 4.20-rc1 to be released since there are important >> additions to the media API. I can probably come up with something, I'm >> just not sure when I get around to it. Ping me in three weeks time if you >> haven't heard from me. >> >>> >>> We also have code coverage reports with the coverage fuzzer achieved >>> so far. Here in the Cover column: >>> https://syzkaller.appspot.com/#managers >>> e.g. this one (but note this is a ~80MB html file): >>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html >>> This can be used to assess e.g. v4l coverage. But I don't know what's >>> coverable in general from syscalls and what's coverable via the stub >>> drivers in particular. So some expertise from media developers would >>> be helpful too. >> >> The four virtual drivers should give pretty decent coverage of the core >> code. Are you able to test with a 32-bit syzkaller application on a 64-bit >> kernel as well? That way the compat32 code is tested. >> >>> >>> Do I understand it correctly that when a process opens
Re: [PATCH 2/2] media: drxk_hard: check if parameter is not NULL
On Fri, Dec 7, 2018 at 5:08 AM Mauro Carvalho Chehab
wrote:
>
> There is a smatch warning:
> drivers/media/dvb-frontends/drxk_hard.c:
> drivers/media/dvb-frontends/drxk_hard.c:1478 scu_command() error: we
> previously assumed 'parameter' could be null (see line 1467)
>
> Telling that parameter might be NULL. Well, it can't, due to the
> way the driver works, but it doesn't hurt to add a check, in order
> to shut up smatch.
eh, yeah this function is kind of odd; the early return conditions are
a little tricky, but I agree that this check doesn't hurt to add.
Reviewed-by: Nick Desaulniers
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/dvb-frontends/drxk_hard.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/drxk_hard.c
> b/drivers/media/dvb-frontends/drxk_hard.c
> index 84ac3f73f8fe..8ea1e45be710 100644
> --- a/drivers/media/dvb-frontends/drxk_hard.c
> +++ b/drivers/media/dvb-frontends/drxk_hard.c
> @@ -1474,9 +1474,11 @@ static int scu_command(struct drxk_state *state,
>
> /* assume that the command register is ready
> since it is checked afterwards */
> - for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
> - buffer[cnt++] = (parameter[ii] & 0xFF);
> - buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
> + if (parameter) {
> + for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
> + buffer[cnt++] = (parameter[ii] & 0xFF);
> + buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
> + }
> }
> buffer[cnt++] = (cmd & 0xFF);
> buffer[cnt++] = ((cmd >> 8) & 0xFF);
> --
> 2.19.2
>
--
Thanks,
~Nick Desaulniers
Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture
On 12/07/2018 03:30 PM, Mauro Carvalho Chehab wrote: > Em Thu, 6 Sep 2018 11:02:28 +0200 > Hans Verkuil escreveu: > >> Hi Philipp, >> >> It is much appreciated that this old RFC of mine is picked up again. >> I always wanted to get this in, but I never had a driver where it would >> make sense to do so. > > What's the status of this? Changes were requested, and there was some discussion. I'm basically waiting for an update. I've delegated it to me. Regards, Hans > > Hans, > As this is an old RFC from you, I'll delegate it to you at patchwork, > for you to track it. > > Regards, > Mauro > >> >> On 09/05/2018 07:09 PM, Philipp Zabel wrote: >>> For video capture it is the driver that reports the colorspace, >> >> add: "transfer function," >> >>> Y'CbCr/HSV encoding and quantization range used by the video, and there >>> is no way to request something different, even though many HDTV >>> receivers have some sort of colorspace conversion capabilities. >>> >>> For output video this feature already exists since the application >>> specifies this information for the video format it will send out, and >>> the transmitter will enable any available CSC if a format conversion has >>> to be performed in order to match the capabilities of the sink. >>> >>> For video capture we propose adding new pix_format flags: >>> V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC, >>> V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and >>> V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate >>> its conversion features. When set by the application, the driver will >>> interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func >>> fields as the requested colorspace information and will attempt to do >>> the conversion it supports. >>> >>> Drivers do not have to actually look at the flags: if the flags are not >>> set, then the colorspace, ycbcr_enc and quantization fields are set to >>> the default values by the core, i.e. just pass on the received format >>> without conversion. >> >> Thinking about this some more, I don't think this is quite the right >> approach. >> Having userspace set these flags with S_FMT if they want to do explicit >> conversions makes sense, and that part we can keep. >> >> But to signal the capabilities I think should be done via new flags for >> VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field >> of struct v4l2_fmtdesc. >> >> One thing that's not clear to me is what happens if userspace sets one or >> more flags and calls S_FMT for a driver that doesn't support this. Are the >> flags zeroed in that case upon return? I don't think so, but I think that >> is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA. >> >> I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent >> flag for v4l2_fmtdesc. >> >> Then we can just document that v4l2_format flags are only valid if they >> are also defined in v4l2_fmtdesc. >> >> Does anyone have better ideas for this? >> >> Regards, >> >> Hans >> >>> >>> Signed-off-by: Hans Verkuil >>> Signed-off-by: Philipp Zabel >>> --- >>> Changes since v1 [1] >>> - convert to rst >>> - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for >>>colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func >>> - let driver set flags to indicate supported features >>> >>> [1] https://patchwork.linuxtv.org/patch/28847/ >>> --- >>> .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++ >>> .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++-- >>> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 37 ++--- >>> drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++ >>> include/uapi/linux/videodev2.h| 5 +++ >>> 5 files changed, 94 insertions(+), 17 deletions(-) >>> >>> diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> b/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> index 38af1472a4b4..c1090027626c 100644 >>> --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list. >>> by RGBA values (128, 192, 255, 128), the same pixel described with >>> premultiplied colors would be described by RGBA values (64, 96, >>> 128, 128) >>> +* - ``V4L2_PIX_FMT_FLAG_CSC_COLORSPACE`` >>> + - 0x0002 >>> + - Set by the driver to indicate colorspace conversion support. Set >>> by the >>> + application to request conversion to the specified colorspace. It is >>> + only used for capture and is ignored for output streams. If set by the >>> + application, then request the driver to do colorspace conversion from >>> + the received colorspace to the requested colorspace by setting the >>> + ``colorspace`` field of struct :c:type:`v4l2_pix_format`. >>> +* - ``V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC`` >>> +
Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture
Em Thu, 6 Sep 2018 11:02:28 +0200 Hans Verkuil escreveu: > Hi Philipp, > > It is much appreciated that this old RFC of mine is picked up again. > I always wanted to get this in, but I never had a driver where it would > make sense to do so. What's the status of this? Hans, As this is an old RFC from you, I'll delegate it to you at patchwork, for you to track it. Regards, Mauro > > On 09/05/2018 07:09 PM, Philipp Zabel wrote: > > For video capture it is the driver that reports the colorspace, > > add: "transfer function," > > > Y'CbCr/HSV encoding and quantization range used by the video, and there > > is no way to request something different, even though many HDTV > > receivers have some sort of colorspace conversion capabilities. > > > > For output video this feature already exists since the application > > specifies this information for the video format it will send out, and > > the transmitter will enable any available CSC if a format conversion has > > to be performed in order to match the capabilities of the sink. > > > > For video capture we propose adding new pix_format flags: > > V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC, > > V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and > > V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate > > its conversion features. When set by the application, the driver will > > interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func > > fields as the requested colorspace information and will attempt to do > > the conversion it supports. > > > > Drivers do not have to actually look at the flags: if the flags are not > > set, then the colorspace, ycbcr_enc and quantization fields are set to > > the default values by the core, i.e. just pass on the received format > > without conversion. > > Thinking about this some more, I don't think this is quite the right approach. > Having userspace set these flags with S_FMT if they want to do explicit > conversions makes sense, and that part we can keep. > > But to signal the capabilities I think should be done via new flags for > VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field > of struct v4l2_fmtdesc. > > One thing that's not clear to me is what happens if userspace sets one or > more flags and calls S_FMT for a driver that doesn't support this. Are the > flags zeroed in that case upon return? I don't think so, but I think that > is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA. > > I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent > flag for v4l2_fmtdesc. > > Then we can just document that v4l2_format flags are only valid if they > are also defined in v4l2_fmtdesc. > > Does anyone have better ideas for this? > > Regards, > > Hans > > > > > Signed-off-by: Hans Verkuil > > Signed-off-by: Philipp Zabel > > --- > > Changes since v1 [1] > > - convert to rst > > - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for > >colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func > > - let driver set flags to indicate supported features > > > > [1] https://patchwork.linuxtv.org/patch/28847/ > > --- > > .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++ > > .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++-- > > Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 37 ++--- > > drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++ > > include/uapi/linux/videodev2.h| 5 +++ > > 5 files changed, 94 insertions(+), 17 deletions(-) > > > > diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > b/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > index 38af1472a4b4..c1090027626c 100644 > > --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list. > > by RGBA values (128, 192, 255, 128), the same pixel described with > > premultiplied colors would be described by RGBA values (64, 96, > > 128, 128) > > +* - ``V4L2_PIX_FMT_FLAG_CSC_COLORSPACE`` > > + - 0x0002 > > + - Set by the driver to indicate colorspace conversion support. Set > > by the > > + application to request conversion to the specified colorspace. It is > > + only used for capture and is ignored for output streams. If set by the > > + application, then request the driver to do colorspace conversion from > > + the received colorspace to the requested colorspace by setting the > > + ``colorspace`` field of struct :c:type:`v4l2_pix_format`. > > +* - ``V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC`` > > + - 0x0004 > > + - Set by the driver to indicate Y'CbCr encoding conversion support. > > Set > > + by the application to request conversion to the specified Y'CbCr > > + encoding. It is only used for capture and is ignored for
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
Hi Hans and Dan, On Fri 07 Dec 2018 at 13:38, Dan Carpenter wrote: On Fri, Dec 07, 2018 at 01:44:00PM +0100, Hans Verkuil wrote: CHECK: Alignment should match open parenthesis #936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921: + ret = v4l2_async_register_fwnode_subdev(mipi_sd, + sizeof(struct v4l2_async_subdev), _port, 1, Apparently the latest coding style is that alignment is more important than line length, although I personally do not agree. But since you need to respin in any case due to the wrong SPDX identifier you used you might as well take this into account. I added this in the cover letter: - some alignment parenthesis that were left as they are, to be more readable this ones were left as they are as they seem impossible to fit all rules. I hope you really do not mind about this checks. if you have a strong opinion about this let me know, otherwise I will leave this as it is. I'm pretty sure it complains about both equally. If you make fix one warning it will complain about the other. So you just have to pick which warning to not care about. Yeah, I agree with you, I normally like to avoid at all cost the line length issue. --- Cheers, Rui regards, dan carpenter
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 11:53:17 -0200 Mauro Carvalho Chehab escreveu: > Em Fri, 7 Dec 2018 14:27:48 +0100 > Hans Verkuil escreveu: > > > On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > > > Em Fri, 7 Dec 2018 12:47:24 +0100 > > > Hans Verkuil escreveu: > > > > > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > > >>> Em Fri, 7 Dec 2018 10:09:04 +0100 > > >>> Hans Verkuil escreveu: > > >>> > > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > > > This will allow us to simplify drivers that currently have to add > > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > > to their code, since now this will always be available. > > > > The original intent of allowing these to be configured by the > > user was (I think) to save a bit of memory. > > >>> > > >>> No. The original intent was/is to be sure that adding the media > > >>> controller support won't be breaking existing working drivers. > > >> > > >> That doesn't make sense. If enabling this option would break existing > > >> drivers, then something is really wrong, isn't it? > > > > > > It is the opposite: disabling it should not break any driver that don't > > > depend on them to work. > > > > > >> > > >>> > > But as more and more > > drivers have a media controller and all regular distros already > > enable one or more of those drivers, the memory for the MC code is > > there anyway. > > > > Complexity has always been the bane of media drivers, so reducing > > complexity at the expense of a bit more memory (which is a rounding > > error compared to the amount of video buffer memory needed) is IMHO > > a good thing. > > > > Signed-off-by: Hans Verkuil > > --- > > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > > index 8add62a18293..56eb01cc8bb4 100644 > > --- a/drivers/media/Kconfig > > +++ b/drivers/media/Kconfig > > @@ -31,6 +31,7 @@ comment "Multimedia core support" > > # > > config MEDIA_CAMERA_SUPPORT > > bool "Cameras/video grabbers support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable support for webcams and video grabbers. > > > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > > > config MEDIA_ANALOG_TV_SUPPORT > > bool "Analog TV support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable analog TV support. > > > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > > > config MEDIA_DIGITAL_TV_SUPPORT > > bool "Digital TV support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable digital TV support. > > >>> > > >>> See my comments below. > > >>> > > > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > > > config MEDIA_CONTROLLER > > bool "Media Controller API" > > - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > > MEDIA_DIGITAL_TV_SUPPORT > > ---help--- > > Enable the media controller API used to query media devices > > internal > > topology and configure it dynamically. > > >>> > > >>> I have split comments with regards to it. Yeah, nowadays media > > >>> controller > > >>> has becoming more important. Still, a lot of media drivers work fine > > >>> without them. > > >>> > > >>> Anyway, if we're willing to make it mandatory, better to just remove the > > >>> entire config option or to make it a silent one. > > >> > > >> Well, that assumes that the media controller will only be used by media > > >> drivers, and not alsa or anyone else who wants to experiment with the MC. > > >> > > >> I won't object to making it silent (since it does reflect the current > > >> situation), but since this functionality is not actually specific to > > >> media > > >> drivers I think that is a good case to be made to allow it to be selected > > >> manually. > > >> > > >>> > > @@ -119,16 +121,11 @@ config VIDEO_DEV > > tristate > > depends on MEDIA_SUPPORT > > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > > + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > > default y > > > > config VIDEO_V4L2_SUBDEV_API > > - bool "V4L2 sub-device userspace API" > > - depends on VIDEO_DEV && MEDIA_CONTROLLER > > - ---help--- > > -Enables the V4L2 sub-device pad-level userspace API used to > > configure > > -video format, size and frame rate between hardware blocks. > > - > > -This API is mostly used by
Re: [PATCH v9 05/13] media: dt-bindings: add bindings for i.MX7 media driver
Hi Hans,
On Fri 07 Dec 2018 at 12:39, Hans Verkuil wrote:
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
Add bindings documentation for i.MX7 media drivers.
The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
Signed-off-by: Rui Miguel Silva
Reviewed-by: Rob Herring
Acked-by: Sakari Ailus
Please move this patch to the beginning of the series to avoid
checkpatch warnings:
WARNING: DT compatible string "fsl,imx7-csi" appears
un-documented -- check ./Documentation/devicetree/bindings/
#1378: FILE: drivers/staging/media/imx/imx7-media-csi.c:1336:
+ { .compatible = "fsl,imx7-csi" },
Will do, thanks for catching this one.
---
Cheers,
Rui
Thanks!
Hans
---
.../devicetree/bindings/media/imx7-csi.txt| 45 ++
.../bindings/media/imx7-mipi-csi2.txt | 90
+++
2 files changed, 135 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/imx7-csi.txt
create mode 100644
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
diff --git
a/Documentation/devicetree/bindings/media/imx7-csi.txt
b/Documentation/devicetree/bindings/media/imx7-csi.txt
new file mode 100644
index ..3c07bc676bc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
@@ -0,0 +1,45 @@
+Freescale i.MX7 CMOS Sensor Interface
+=
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which
enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg : base address and length of the register set
for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list of clock specifiers, see
+
Documentation/devicetree/bindings/clock/clock-bindings.txt for
details;
+- clock-names : must contain "axi", "mclk" and "dcic"
entries, matching
+ entries in the clock property;
+
+The device node shall contain one 'port' child node with one
child 'endpoint'
+node, according to the bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+In the following example a remote endpoint is a video
multiplexer.
+
+example:
+
+csi: csi@3071 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-csi";
+reg = <0x3071 0x1>;
+interrupts = IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX7D_CLK_DUMMY>,
+<
IMX7D_CSI_MCLK_ROOT_CLK>,
+<
IMX7D_CLK_DUMMY>;
+clock-names = "axi", "mclk", "dcic";
+
+port {
+csi_from_csi_mux: endpoint {
+remote-endpoint =
<_mux_to_csi>;
+};
+};
+};
diff --git
a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
new file mode 100644
index ..71fd74ed3ec8
--- /dev/null
+++
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
@@ -0,0 +1,90 @@
+Freescale i.MX7 Mipi CSI2
+=
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in
i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg : base address and length of the register set
for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+
Documentation/devicetree/bindings/clock/clock-bindings.txt for
details;
+- clock-names : must contain "pclk", "wrap" and "phy"
entries, matching
+ entries in the clock property;
+- power-domains : a phandle to the power domain, see
+
Documentation/devicetree/bindings/power/power_domain.txt for
details.
+- reset-names : should include following entry "mrst";
+- resets: a list of phandle, should contain reset
entry of
+ reset-names;
+- phy-supply: from the generic phy bindings, a phandle to
a regulator that
+ provides power to MIPI CSIS core;
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency
in Hz, default
+ value when this property is not specified is
166 MHz;
+- fsl,csis-hs-settle : differential receiver (HS-RX) settle
time;
+
+The device node should contain two 'port' child nodes with one
child 'endpoint'
+node, according to the bindings defined in:
+ Documentation/devicetree/bindings/
media/video-interfaces.txt.
+ The following are properties specific to those nodes.
+
+port node
+-
+
+- reg : (required) can take
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 14:27:48 +0100 Hans Verkuil escreveu: > On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > > Em Fri, 7 Dec 2018 12:47:24 +0100 > > Hans Verkuil escreveu: > > > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > >>> Em Fri, 7 Dec 2018 10:09:04 +0100 > >>> Hans Verkuil escreveu: > >>> > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > This will allow us to simplify drivers that currently have to add > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > to their code, since now this will always be available. > > The original intent of allowing these to be configured by the > user was (I think) to save a bit of memory. > >>> > >>> No. The original intent was/is to be sure that adding the media > >>> controller support won't be breaking existing working drivers. > >> > >> That doesn't make sense. If enabling this option would break existing > >> drivers, then something is really wrong, isn't it? > > > > It is the opposite: disabling it should not break any driver that don't > > depend on them to work. > > > >> > >>> > But as more and more > drivers have a media controller and all regular distros already > enable one or more of those drivers, the memory for the MC code is > there anyway. > > Complexity has always been the bane of media drivers, so reducing > complexity at the expense of a bit more memory (which is a rounding > error compared to the amount of video buffer memory needed) is IMHO > a good thing. > > Signed-off-by: Hans Verkuil > --- > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > index 8add62a18293..56eb01cc8bb4 100644 > --- a/drivers/media/Kconfig > +++ b/drivers/media/Kconfig > @@ -31,6 +31,7 @@ comment "Multimedia core support" > # > config MEDIA_CAMERA_SUPPORT > bool "Cameras/video grabbers support" > +select MEDIA_CONTROLLER > ---help--- > Enable support for webcams and video grabbers. > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > config MEDIA_ANALOG_TV_SUPPORT > bool "Analog TV support" > +select MEDIA_CONTROLLER > ---help--- > Enable analog TV support. > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > config MEDIA_DIGITAL_TV_SUPPORT > bool "Digital TV support" > +select MEDIA_CONTROLLER > ---help--- > Enable digital TV support. > >>> > >>> See my comments below. > >>> > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > config MEDIA_CONTROLLER > bool "Media Controller API" > -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_DIGITAL_TV_SUPPORT > ---help--- > Enable the media controller API used to query media devices > internal > topology and configure it dynamically. > >>> > >>> I have split comments with regards to it. Yeah, nowadays media controller > >>> has becoming more important. Still, a lot of media drivers work fine > >>> without them. > >>> > >>> Anyway, if we're willing to make it mandatory, better to just remove the > >>> entire config option or to make it a silent one. > >> > >> Well, that assumes that the media controller will only be used by media > >> drivers, and not alsa or anyone else who wants to experiment with the MC. > >> > >> I won't object to making it silent (since it does reflect the current > >> situation), but since this functionality is not actually specific to media > >> drivers I think that is a good case to be made to allow it to be selected > >> manually. > >> > >>> > @@ -119,16 +121,11 @@ config VIDEO_DEV > tristate > depends on MEDIA_SUPPORT > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > +select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > default y > > config VIDEO_V4L2_SUBDEV_API > -bool "V4L2 sub-device userspace API" > -depends on VIDEO_DEV && MEDIA_CONTROLLER > ----help--- > - Enables the V4L2 sub-device pad-level userspace API used to > configure > - video format, size and frame rate between hardware blocks. > - > - This API is mostly used by camera interfaces in embedded > platforms. > +bool > >>> > >>> NACK. > >>> > >>> There is a very good reason why the subdev API is optional: there > >>> are drivers that use camera sensors but are not MC-centric. On those, > >>> the USB bridge
Re: [PATCH v9 01/13] media: staging/imx: refactor imx media device probe
Hi Hans, Thanks for the review. On Fri 07 Dec 2018 at 12:38, Hans Verkuil wrote: On 11/22/2018 04:18 PM, Rui Miguel Silva wrote: Refactor and move media device initialization code to a new common module, so it can be used by other devices, this will allow for example a near to introduce imx7 CSI driver, to use this media device. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile| 1 + .../staging/media/imx/imx-media-dev-common.c | 102 ++ drivers/staging/media/imx/imx-media-dev.c | 88 --- drivers/staging/media/imx/imx-media-of.c | 6 +- drivers/staging/media/imx/imx-media.h | 15 +++ 5 files changed, 141 insertions(+), 71 deletions(-) create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 698a4210316e..a30b3033f9a3 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o +imx-media-objs += imx-media-dev-common.o imx-media-common-objs := imx-media-utils.o imx-media-fim.o imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o diff --git a/drivers/staging/media/imx/imx-media-dev-common.c b/drivers/staging/media/imx/imx-media-dev-common.c new file mode 100644 index ..55fe94fb72f2 --- /dev/null +++ b/drivers/staging/media/imx/imx-media-dev-common.c @@ -0,0 +1,102 @@ +// SPDX-License-Identifier: GPL This is an invalid SPDX license identifier. You probably want to use GPL-2.0. hrr... you are right, I will update it here and others. --- Cheers, Rui
Re: [PATCH v2] media: cedrus: don't initialize pointers with zero
Em Fri, 07 Dec 2018 14:21:44 +0100
Paul Kocialkowski escreveu:
> Hi,
>
> On Fri, 2018-12-07 at 08:03 -0500, Mauro Carvalho Chehab wrote:
> > 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 };
>
> Thanks for sharing these details, it's definitely interesting and good
> to know :)
Yeah, that's something that was bothering for quite a while, as I've
seen patches using either one of the ways. It took me a while to
do some research, and having it documented at the patch helps, as
we should now handle it the same way for similar stuff :-)
>
> > 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.
>
> Acked-by: Paul Kocialkowski
Applied, thanks!
>
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > 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 b538eb0321d8..b7c918fa5fd1 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;
> >
Thanks,
Mauro
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
On Fri, Dec 07, 2018 at 01:44:00PM +0100, Hans Verkuil wrote: > CHECK: Alignment should match open parenthesis > #936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921: > + ret = v4l2_async_register_fwnode_subdev(mipi_sd, > + sizeof(struct v4l2_async_subdev), _port, > 1, > > Apparently the latest coding style is that alignment is more important than > line length, although I personally do not agree. But since you need to > respin in any case due to the wrong SPDX identifier you used you might as > well take this into account. I'm pretty sure it complains about both equally. If you make fix one warning it will complain about the other. So you just have to pick which warning to not care about. regards, dan carpenter
Re: [PATCH v5 00/12] imx-media: Fixes for interlaced capture
Hi Steve, How to proceed with this w.r.t. the two gpu ipu patches? Are those going in first through the gpu tree? Or do they have to go in through our tree? In that case I need Acks from whoever maintains that code. Regards, Hans On 10/17/2018 02:00 AM, Steve Longerbeam wrote: > A set of patches that fixes some bugs with capturing from an > interlaced source, and incompatibilites between IDMAC interlace > interweaving and 4:2:0 data write reduction. > > History: > v5: > - Added a regression fix to allow empty endpoints to CSI (fix for imx6q > SabreAuto). > - Cleaned up some convoluted code in ipu_csi_init_interface(), suggested > by Philipp Zabel. > - Fixed a regression in csi_setup(), caught by Philipp. > - Removed interweave_offset and replace with boolean interweave_swap, > suggested by Philipp. > - Make clear that it is IDMAC channel that does pixel reordering and > interweave, not the CSI, in the imx.rst doc, caught by Philipp. > > v4: > - rebased to latest media-tree master branch. > - Make patch author and SoB email addresses the same. > > v3: > - add support for/fix interweaved scan with YUV planar output. > - fix bug in 4:2:0 U/V offset macros. > - add patch that generalizes behavior of field swap in > ipu_csi_init_interface(). > - add support for interweaved scan with field order swap. > Suggested by Philipp Zabel. > - in v2, inteweave scan was determined using field types of > CSI (and PRPENCVF) at the sink and source pads. In v3, this > has been moved one hop downstream: interweave is now determined > using field type at source pad, and field type selected at > capture interface. Suggested by Philipp. > - make sure to double CSI crop target height when input field > type in alternate. > - more updates to media driver doc to reflect above. > > v2: > - update media driver doc. > - enable idmac interweave only if input field is sequential/alternate, > and output field is 'interlaced*'. > - move field try logic out of *try_fmt and into separate function. > - fix bug with resetting crop/compose rectangles. > - add a patch that fixes a field order bug in VDIC indirect mode. > - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro > Suggested-by: Nicolas Dufresne . > - add macro V4L2_FIELD_IS_INTERLACED(). > > > Steve Longerbeam (12): > media: videodev2.h: Add more field helper macros > gpu: ipu-csi: Swap fields according to input/output field types > gpu: ipu-v3: Add planar support to interlaced scan > media: imx: Fix field negotiation > media: imx-csi: Input connections to CSI should be optional > media: imx-csi: Double crop height for alternate fields at sink > media: imx: interweave and odd-chroma-row skip are incompatible > media: imx-csi: Allow skipping odd chroma rows for YVU420 > media: imx: vdic: rely on VDIC for correct field order > media: imx-csi: Move crop/compose reset after filling default mbus > fields > media: imx: Allow interweave with top/bottom lines swapped > media: imx.rst: Update doc to reflect fixes to interlaced capture > > Documentation/media/v4l-drivers/imx.rst | 103 +++ > drivers/gpu/ipu-v3/ipu-cpmem.c| 26 ++- > drivers/gpu/ipu-v3/ipu-csi.c | 119 + > drivers/staging/media/imx/imx-ic-prpencvf.c | 46 +++-- > drivers/staging/media/imx/imx-media-capture.c | 14 ++ > drivers/staging/media/imx/imx-media-csi.c | 168 +- > drivers/staging/media/imx/imx-media-vdic.c| 12 +- > include/uapi/linux/videodev2.h| 7 + > include/video/imx-ipu-v3.h| 6 +- > 9 files changed, 354 insertions(+), 147 deletions(-) >
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > Em Fri, 7 Dec 2018 12:47:24 +0100 > Hans Verkuil escreveu: > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: >>> Em Fri, 7 Dec 2018 10:09:04 +0100 >>> Hans Verkuil escreveu: >>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. This will allow us to simplify drivers that currently have to add #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API to their code, since now this will always be available. The original intent of allowing these to be configured by the user was (I think) to save a bit of memory. >>> >>> No. The original intent was/is to be sure that adding the media >>> controller support won't be breaking existing working drivers. >> >> That doesn't make sense. If enabling this option would break existing >> drivers, then something is really wrong, isn't it? > > It is the opposite: disabling it should not break any driver that don't > depend on them to work. > >> >>> But as more and more drivers have a media controller and all regular distros already enable one or more of those drivers, the memory for the MC code is there anyway. Complexity has always been the bane of media drivers, so reducing complexity at the expense of a bit more memory (which is a rounding error compared to the amount of video buffer memory needed) is IMHO a good thing. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8add62a18293..56eb01cc8bb4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -31,6 +31,7 @@ comment "Multimedia core support" # config MEDIA_CAMERA_SUPPORT bool "Cameras/video grabbers support" + select MEDIA_CONTROLLER ---help--- Enable support for webcams and video grabbers. @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT config MEDIA_ANALOG_TV_SUPPORT bool "Analog TV support" + select MEDIA_CONTROLLER ---help--- Enable analog TV support. @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT config MEDIA_DIGITAL_TV_SUPPORT bool "Digital TV support" + select MEDIA_CONTROLLER ---help--- Enable digital TV support. >>> >>> See my comments below. >>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" config MEDIA_CONTROLLER bool "Media Controller API" - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. >>> >>> I have split comments with regards to it. Yeah, nowadays media controller >>> has becoming more important. Still, a lot of media drivers work fine >>> without them. >>> >>> Anyway, if we're willing to make it mandatory, better to just remove the >>> entire config option or to make it a silent one. >> >> Well, that assumes that the media controller will only be used by media >> drivers, and not alsa or anyone else who wants to experiment with the MC. >> >> I won't object to making it silent (since it does reflect the current >> situation), but since this functionality is not actually specific to media >> drivers I think that is a good case to be made to allow it to be selected >> manually. >> >>> @@ -119,16 +121,11 @@ config VIDEO_DEV tristate depends on MEDIA_SUPPORT depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER default y config VIDEO_V4L2_SUBDEV_API - bool "V4L2 sub-device userspace API" - depends on VIDEO_DEV && MEDIA_CONTROLLER - ---help--- -Enables the V4L2 sub-device pad-level userspace API used to configure -video format, size and frame rate between hardware blocks. - -This API is mostly used by camera interfaces in embedded platforms. + bool >>> >>> NACK. >>> >>> There is a very good reason why the subdev API is optional: there >>> are drivers that use camera sensors but are not MC-centric. On those, >>> the USB bridge driver is responsible to setup the subdevice. >>> >>> This options helps to ensure that camera sensors used by such drivers >>> won't stop working because of the lack of the subdev-API. >> >> But they won't stop working if this is enabled. > > That's not the issue. I've seen (and nacked) several patches breaking > drivers by assuming that all init would happen via subdev API. > > By having this as an optional feature that can be disabled, developers > need to ensure that either the driver won't be built as a hole, if > no
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On Fri, Dec 07, 2018 at 09:31:06AM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil escreveu:
>
> > On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > > 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
> > >
> > > A proper way to initialize it with gcc is to use:
> > >
> > > struct foo f = { };
> > >
> > > But that seems to be a gcc extension. So, I decided to check upstream
> >
> > No, this is not a gcc extension. It's part of the latest C standard.
>
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.
>
> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support
My test says that clang works with {}.
I support this in Smatch as well.
regards,
dan carpenter
Re: [PATCH v2] media: cedrus: don't initialize pointers with zero
Hi,
On Fri, 2018-12-07 at 08:03 -0500, Mauro Carvalho Chehab wrote:
> 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 };
Thanks for sharing these details, it's definitely interesting and good
to know :)
> 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.
Acked-by: Paul Kocialkowski
> Signed-off-by: Mauro Carvalho Chehab
> ---
> 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 b538eb0321d8..b7c918fa5fd1 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;
>
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
Re: [PATCH] media: cetrus: return an error if alloc fails
Hi,
On Fri, 2018-12-07 at 06:13 -0500, Mauro Carvalho Chehab wrote:
> As warned by smatch:
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:
> drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error:
> potential null dereference 'ctx->ctrls'. (kzalloc returns null)
>
> While here, remove the memset(), as kzalloc() already zeroes the
> struct.
Good catch, thanks for the patch!
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Paul Kocialkowski
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 44c45c687503..24b89cd2b692 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -72,7 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
> cedrus_ctx *ctx)
> ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
>
> ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
> - memset(ctx->ctrls, 0, ctrl_size);
> + if (!ctx->ctrls)
> + return -ENOMEM;
>
> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> struct v4l2_ctrl_config cfg = { NULL };
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Sean,
Sorry, I just checked the first paragraph.
I will send you a new release.
Thanks,
Patrick.
On 07/12/2018 11:12, Sean Young wrote:
Hi Patrick,
On Fri, Dec 07, 2018 at 10:57:21AM +0100, Patrick LERDA wrote:
Add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
Other than the Signed-off-by this looks exactly like the v2 version;
did you see my other comments on the v2 patch?
Thanks
Sean
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 185
+
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 1 +
tools/include/uapi/linux/lirc.h| 1 +
8 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..b7e08324b874 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,16 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..fc4058013234 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..94d5b70f7a0f
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,185 @@
+/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+ *
+ * Copyright (C) 2016 by Patrick Lerda
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rc-core-priv.h"
+#include
+#include
+
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_0_NBITS 64
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3)
*/
+#define RCMM_PULSE_144 /* 16.6*(2+2/3)
*/
+#define RCMM_PULSE_261 /* 16.6*(3+2/3)
*/
+#define RCMM_PULSE_378 /* 16.6*(4+2/3)
*/
+#define RCMM_MODE_MASK 0x
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state
machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+
+ if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+ adjust to the signal */
+ if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
+ break;
+
+ data->state = STATE_LOW;
+
Re: [PATCH] media: cedrus: don't initialize pointers with zero
Em Fri, 7 Dec 2018 12:27:09 +
Ian Arkver escreveu:
> On 07/12/2018 11:37, Hans Verkuil wrote:
> > On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> >> Em Fri, 7 Dec 2018 12:14:50 +0100
> >> Hans Verkuil escreveu:
> >>
> >>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> 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
>
> A proper way to initialize it with gcc is to use:
>
> struct foo f = { };
>
> But that seems to be a gcc extension. So, I decided to check upstream
> >>>
> >>> No, this is not a gcc extension. It's part of the latest C standard.
> >>
> >> Sure? Where the C standard spec states that? I've been seeking for
> >> such info for a while, as '= {}' is also my personal preference.
> >
> > I believe it was added in C11, but I've loaned the book that stated
> > that to someone else, so I can't check.
>
> Sadly I don't see mention of empty initializer lists in section 6.7.9 of
> ISO/IEC 9899:2011, though I've only got a draft version.
Yeah, as far as I checked, this is not really part of the standard.
Depending on how you read:
"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."
One may infere that a brace-enclosed list with zero elements
would fit, and "the remainder of the aggregate shall be
initialized implicitly".
I suspect that this is how gcc people interpreted it.
> I had a play with Compiler Explorer[1] and it seems like clang is OK
> with the {} form though just out of interest msvc isn't.
Yeah, I'm aware that msvc won't support it. Good to know that clang
does the right thing cleaning the struct.
To be realistic, we only really care with gcc at the Kernel side, as
clang upstream versions still can't build upstream Kernels, and
nobody uses any other compiler for the Kernel anymore. Yet, with
regards to clang, there's a push to let it to build the Kernel.
So, it seems wise to add something that would work for both.
Anyway, I'll post a version 2 of this patch using ={} and placing
some rationale on it.
> I didn't try
> exploring other command line options.
>
> [1] https://gcc.godbolt.org/z/XIDC7W
>
> Regards,
> Ian
> >
> > In any case, it's used everywhere:
> >
> > git grep '= *{ *}' drivers/
> >
> > So it is really pointless to *not* use it.
> >
> > Regards,
> >
> > Hans
> >
> >> I tried to build the Kernel with clang, just to be sure that this
> >> won't cause issues with the clang support, but, unfortunately, the
> >> clang compiler (not even the upstream version) is able to build
> >> the upstream Kernel yet, as it lacks asm-goto support (there is an
> >> OOT patch for llvm solving it - but it sounds too much effort for
> >> my time to have to build llvm from their sources just for a simple
> >> check like this).
> >>
> >>> It's used all over in the kernel, so please use {} instead of { NULL }.
> >>>
> >>> Personally I think {} is a fantastic invention and I wish C++ had it as
> >>> well.
> >>
> >> Fully agreed on that.
> >>
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> what's the most commonly pattern. The gcc 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
>
> So, let's initialize those structs with:
> = { NULL }
>
> Signed-off-by: Mauro Carvalho Chehab
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Hi,
> This series introduces the Media driver to work with the i.MX7 SoC. it uses
> the
> already existing imx media core drivers but since the i.MX7, contrary to
> i.MX5/6, do not have an IPU and because of that some changes in the imx media
> core are made along this series to make it support that case.
>
> This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several
> configurations changes for this to work as a capture subsystem. Some bugs are
> also fixed along the line. And necessary documentation.
>
> For a more detailed view of the capture paths, pads links in the i.MX7 please
> take a look at the documentation in PATCH 10.
>
> The system used to test and develop this was the Warp7 board with an OV2680
> sensor, which output format is 10-bit bayer. So, only MIPI interface was
> tested, a scenario with an parallel input would nice to have.
I got a few checkpatch warnings about coding style:
CHECK: Alignment should match open parenthesis
#953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
+static struct v4l2_mbus_framefmt *imx7_csi_get_format(struct imx7_csi *csi,
+ struct v4l2_subdev_pad_config *cfg,
CHECK: Alignment should match open parenthesis
#1341: FILE: drivers/staging/media/imx/imx7-media-csi.c:1299:
+ ret = v4l2_async_register_fwnode_subdev(>sd,
+ sizeof(struct v4l2_async_subdev),
CHECK: Lines should not end with a '('
#684: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:669:
+static struct csis_pix_format const *mipi_csis_try_format(
CHECK: Alignment should match open parenthesis
#708: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:693:
+static struct v4l2_mbus_framefmt *mipi_csis_get_format(struct csi_state *state,
+ struct v4l2_subdev_pad_config *cfg,
CHECK: Alignment should match open parenthesis
#936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921:
+ ret = v4l2_async_register_fwnode_subdev(mipi_sd,
+ sizeof(struct v4l2_async_subdev), _port, 1,
Apparently the latest coding style is that alignment is more important than
line length, although I personally do not agree. But since you need to
respin in any case due to the wrong SPDX identifier you used you might as
well take this into account.
I was really hoping I could merge this, but the SPDX license issue killed it.
Regards,
Hans
>
>
> Bellow goes an example of the output of the pads and links and the output of
> v4l2-compliance testing.
>
> The v4l-utils version used is:
> v4l2-compliance SHA : 044d5ab7b0d02683070d01a369c73d462d7a0cee from Nov 19th
>
> The Media Driver fail some tests but this failures are coming from code out of
> scope of this series (imx-capture), and some from the sensor OV2680
> but that I think not related with the sensor driver but with the testing and
> core.
>
> The csi and mipi-csi entities pass all compliance tests.
>
> Cheers,
> Rui
>
> v8->v9:
> Hans Verkuil:
> - Fix issues detected by checkpatch strict, still some left:
> - bigger kconfig option description
> - some alignement parenthesis that were left as they are, to be more
> readable
> - added new patch (PATCH13) for Maintainers update
> - SPDX in documentation rst file
> Sakari Ailus:
> - remove pad check in csi, this is done by core already
> - destroy mutex in probe error path (add label)
> - swap order in driver release
> - initialize endpoint in stack
> - use clk_bulk
> kbuild test robot:
> - add the missing imx-media-dev-common.c in patch 1/13
> - remove OWNER of module csis
> Myself:
> - add MAINTAINERS entries - new patch
>
> v7->v8:
> Myself:
> - rebase to latest linux-next (s/V4L2_MBUS_CSI2/V4L2_MBUS_CSI2_DPHY/)
> - Rebuild and test with latest v4l2-compliance
> - add Sakari reviewed-by tag to dt-bindings
>
> v6->v7:
> Myself:
> - Clock patches removed from this version since they were already merged
> - Rebuild and test with the latest v4l2-compliance
> - Add patch to video-mux regarding bayer formats
> - remove reference to dependent patch serie (was already merged)
>
> Sakari Ailus:
> - add port and endpoint explanantions
> - fix some wording should -> shall
>
> v5->v6:
> Rob Herring:
> - rename power-domain node name from: pgc-power-domain to power-domain
> - change mux-control-cells to 0
> - remove bus-width from mipi bindings and dts
> - remove err... regarding clock names line
> - remove clk-settle from example
> - split mipi-csi2 and csi bindings per file
> - add OF graph description to CSI
>
> Philipp Zabel:
> - rework group IDs and rename them with an _IPU_ prefix, this allowed to
> remove
>the ipu_present flag need.
>
> v4->v5:
> Sakari Ailus:
> - fix remove of the capture entries in dts bindings in the right patch
>
> Stephen Boyd:
> - Send all series to clk list
>
> v3->v4:
> Philipp Zabel:
> -
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 12:47:24 +0100 Hans Verkuil escreveu: > On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > > Em Fri, 7 Dec 2018 10:09:04 +0100 > > Hans Verkuil escreveu: > > > >> This patch selects MEDIA_CONTROLLER for all camera, analog TV and > >> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > >> > >> This will allow us to simplify drivers that currently have to add > >> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > >> to their code, since now this will always be available. > >> > >> The original intent of allowing these to be configured by the > >> user was (I think) to save a bit of memory. > > > > No. The original intent was/is to be sure that adding the media > > controller support won't be breaking existing working drivers. > > That doesn't make sense. If enabling this option would break existing > drivers, then something is really wrong, isn't it? It is the opposite: disabling it should not break any driver that don't depend on them to work. > > > > >> But as more and more > >> drivers have a media controller and all regular distros already > >> enable one or more of those drivers, the memory for the MC code is > >> there anyway. > >> > >> Complexity has always been the bane of media drivers, so reducing > >> complexity at the expense of a bit more memory (which is a rounding > >> error compared to the amount of video buffer memory needed) is IMHO > >> a good thing. > >> > >> Signed-off-by: Hans Verkuil > >> --- > >> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > >> index 8add62a18293..56eb01cc8bb4 100644 > >> --- a/drivers/media/Kconfig > >> +++ b/drivers/media/Kconfig > >> @@ -31,6 +31,7 @@ comment "Multimedia core support" > >> # > >> config MEDIA_CAMERA_SUPPORT > >>bool "Cameras/video grabbers support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable support for webcams and video grabbers. > >> > >> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > >> > >> config MEDIA_ANALOG_TV_SUPPORT > >>bool "Analog TV support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable analog TV support. > >> > >> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > >> > >> config MEDIA_DIGITAL_TV_SUPPORT > >>bool "Digital TV support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable digital TV support. > > > > See my comments below. > > > >> > >> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > >> > >> config MEDIA_CONTROLLER > >>bool "Media Controller API" > >> - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > >> MEDIA_DIGITAL_TV_SUPPORT > >>---help--- > >> Enable the media controller API used to query media devices internal > >> topology and configure it dynamically. > > > > I have split comments with regards to it. Yeah, nowadays media controller > > has becoming more important. Still, a lot of media drivers work fine > > without them. > > > > Anyway, if we're willing to make it mandatory, better to just remove the > > entire config option or to make it a silent one. > > Well, that assumes that the media controller will only be used by media > drivers, and not alsa or anyone else who wants to experiment with the MC. > > I won't object to making it silent (since it does reflect the current > situation), but since this functionality is not actually specific to media > drivers I think that is a good case to be made to allow it to be selected > manually. > > > > >> @@ -119,16 +121,11 @@ config VIDEO_DEV > >>tristate > >>depends on MEDIA_SUPPORT > >>depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > >> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > >> + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > >>default y > >> > >> config VIDEO_V4L2_SUBDEV_API > >> - bool "V4L2 sub-device userspace API" > >> - depends on VIDEO_DEV && MEDIA_CONTROLLER > >> - ---help--- > >> -Enables the V4L2 sub-device pad-level userspace API used to configure > >> -video format, size and frame rate between hardware blocks. > >> - > >> -This API is mostly used by camera interfaces in embedded platforms. > >> + bool > > > > NACK. > > > > There is a very good reason why the subdev API is optional: there > > are drivers that use camera sensors but are not MC-centric. On those, > > the USB bridge driver is responsible to setup the subdevice. > > > > This options helps to ensure that camera sensors used by such drivers > > won't stop working because of the lack of the subdev-API. > > But they won't stop working if this is enabled. That's not the issue. I've seen (and nacked) several patches breaking drivers by assuming that all init would happen via subdev API. By having this as an optional feature that can be disabled, developers need to ensure that either the driver won't be built as a hole, if no subdev API suport is enabled, or need to add the needed logic inside the sub-device
Re: [PATCH v9 05/13] media: dt-bindings: add bindings for i.MX7 media driver
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
> The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
>
> Signed-off-by: Rui Miguel Silva
> Reviewed-by: Rob Herring
> Acked-by: Sakari Ailus
Please move this patch to the beginning of the series to avoid
checkpatch warnings:
WARNING: DT compatible string "fsl,imx7-csi" appears un-documented -- check
./Documentation/devicetree/bindings/
#1378: FILE: drivers/staging/media/imx/imx7-media-csi.c:1336:
+ { .compatible = "fsl,imx7-csi" },
Thanks!
Hans
> ---
> .../devicetree/bindings/media/imx7-csi.txt| 45 ++
> .../bindings/media/imx7-mipi-csi2.txt | 90 +++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
> create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt
> b/Documentation/devicetree/bindings/media/imx7-csi.txt
> new file mode 100644
> index ..3c07bc676bc3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
> @@ -0,0 +1,45 @@
> +Freescale i.MX7 CMOS Sensor Interface
> +=
> +
> +csi node
> +
> +
> +This is device node for the CMOS Sensor Interface (CSI) which enables the
> chip
> +to connect directly to external CMOS image sensors.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-csi";
> +- reg : base address and length of the register set for the device;
> +- interrupts: should contain CSI interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for
> details;
> +- clock-names : must contain "axi", "mclk" and "dcic" entries, matching
> + entries in the clock property;
> +
> +The device node shall contain one 'port' child node with one child 'endpoint'
> +node, according to the bindings defined in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +In the following example a remote endpoint is a video multiplexer.
> +
> +example:
> +
> +csi: csi@3071 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +compatible = "fsl,imx7-csi";
> +reg = <0x3071 0x1>;
> +interrupts = ;
> +clocks = < IMX7D_CLK_DUMMY>,
> +< IMX7D_CSI_MCLK_ROOT_CLK>,
> +< IMX7D_CLK_DUMMY>;
> +clock-names = "axi", "mclk", "dcic";
> +
> +port {
> +csi_from_csi_mux: endpoint {
> +remote-endpoint = <_mux_to_csi>;
> +};
> +};
> +};
> diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> new file mode 100644
> index ..71fd74ed3ec8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> @@ -0,0 +1,90 @@
> +Freescale i.MX7 Mipi CSI2
> +=
> +
> +mipi_csi2 node
> +--
> +
> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
> +compatible with previous version of Samsung D-phy.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-mipi-csi2";
> +- reg : base address and length of the register set for the device;
> +- interrupts: should contain MIPI CSIS interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for
> details;
> +- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
> + entries in the clock property;
> +- power-domains : a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for
> details.
> +- reset-names : should include following entry "mrst";
> +- resets: a list of phandle, should contain reset entry of
> + reset-names;
> +- phy-supply: from the generic phy bindings, a phandle to a regulator
> that
> + provides power to MIPI CSIS core;
> +
> +Optional properties:
> +
> +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
> + value when this property is not specified is 166 MHz;
> +- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
> +
> +The device node should contain two 'port' child nodes with one child
> 'endpoint'
> +node, according to the bindings defined in:
> + Documentation/devicetree/bindings/ media/video-interfaces.txt.
> + The following are properties specific to those nodes.
>
Re: [PATCH v9 01/13] media: staging/imx: refactor imx media device probe
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote: > Refactor and move media device initialization code to a new common > module, so it can be used by other devices, this will allow for example > a near to introduce imx7 CSI driver, to use this media device. > > Signed-off-by: Rui Miguel Silva > --- > drivers/staging/media/imx/Makefile| 1 + > .../staging/media/imx/imx-media-dev-common.c | 102 ++ > drivers/staging/media/imx/imx-media-dev.c | 88 --- > drivers/staging/media/imx/imx-media-of.c | 6 +- > drivers/staging/media/imx/imx-media.h | 15 +++ > 5 files changed, 141 insertions(+), 71 deletions(-) > create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c > > diff --git a/drivers/staging/media/imx/Makefile > b/drivers/staging/media/imx/Makefile > index 698a4210316e..a30b3033f9a3 100644 > --- a/drivers/staging/media/imx/Makefile > +++ b/drivers/staging/media/imx/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o > +imx-media-objs += imx-media-dev-common.o > imx-media-common-objs := imx-media-utils.o imx-media-fim.o > imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o > > diff --git a/drivers/staging/media/imx/imx-media-dev-common.c > b/drivers/staging/media/imx/imx-media-dev-common.c > new file mode 100644 > index ..55fe94fb72f2 > --- /dev/null > +++ b/drivers/staging/media/imx/imx-media-dev-common.c > @@ -0,0 +1,102 @@ > +// SPDX-License-Identifier: GPL This is an invalid SPDX license identifier. You probably want to use GPL-2.0. This happens in more patches, please check! Regards, Hans
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 07/12/2018 11:37, Hans Verkuil wrote:
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil escreveu:
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
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
A proper way to initialize it with gcc is to use:
struct foo f = { };
But that seems to be a gcc extension. So, I decided to check upstream
No, this is not a gcc extension. It's part of the latest C standard.
Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.
I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.
Sadly I don't see mention of empty initializer lists in section 6.7.9 of
ISO/IEC 9899:2011, though I've only got a draft version.
I had a play with Compiler Explorer[1] and it seems like clang is OK
with the {} form though just out of interest msvc isn't. I didn't try
exploring other command line options.
[1] https://gcc.godbolt.org/z/XIDC7W
Regards,
Ian
In any case, it's used everywhere:
git grep '= *{ *}' drivers/
So it is really pointless to *not* use it.
Regards,
Hans
I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).
It's used all over in the kernel, so please use {} instead of { NULL }.
Personally I think {} is a fantastic invention and I wish C++ had it as
well.
Fully agreed on that.
Regards,
Hans
what's the most commonly pattern. The gcc 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
So, let's initialize those structs with:
= { NULL }
Signed-off-by: Mauro Carvalho Chehab
---
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 b538eb0321d8..44c45c687503 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 = { NULL };
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..4099a42dba2d 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 = { NULL };
struct media_request *src_req;
unsigned long flags;
Thanks,
Mauro
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > Em Fri, 7 Dec 2018 10:09:04 +0100 > Hans Verkuil escreveu: > >> This patch selects MEDIA_CONTROLLER for all camera, analog TV and >> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. >> >> This will allow us to simplify drivers that currently have to add >> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API >> to their code, since now this will always be available. >> >> The original intent of allowing these to be configured by the >> user was (I think) to save a bit of memory. > > No. The original intent was/is to be sure that adding the media > controller support won't be breaking existing working drivers. That doesn't make sense. If enabling this option would break existing drivers, then something is really wrong, isn't it? > >> But as more and more >> drivers have a media controller and all regular distros already >> enable one or more of those drivers, the memory for the MC code is >> there anyway. >> >> Complexity has always been the bane of media drivers, so reducing >> complexity at the expense of a bit more memory (which is a rounding >> error compared to the amount of video buffer memory needed) is IMHO >> a good thing. >> >> Signed-off-by: Hans Verkuil >> --- >> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig >> index 8add62a18293..56eb01cc8bb4 100644 >> --- a/drivers/media/Kconfig >> +++ b/drivers/media/Kconfig >> @@ -31,6 +31,7 @@ comment "Multimedia core support" >> # >> config MEDIA_CAMERA_SUPPORT >> bool "Cameras/video grabbers support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable support for webcams and video grabbers. >> >> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT >> >> config MEDIA_ANALOG_TV_SUPPORT >> bool "Analog TV support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable analog TV support. >> >> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT >> >> config MEDIA_DIGITAL_TV_SUPPORT >> bool "Digital TV support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable digital TV support. > > See my comments below. > >> >> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" >> >> config MEDIA_CONTROLLER >> bool "Media Controller API" >> -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || >> MEDIA_DIGITAL_TV_SUPPORT >> ---help--- >>Enable the media controller API used to query media devices internal >>topology and configure it dynamically. > > I have split comments with regards to it. Yeah, nowadays media controller > has becoming more important. Still, a lot of media drivers work fine > without them. > > Anyway, if we're willing to make it mandatory, better to just remove the > entire config option or to make it a silent one. Well, that assumes that the media controller will only be used by media drivers, and not alsa or anyone else who wants to experiment with the MC. I won't object to making it silent (since it does reflect the current situation), but since this functionality is not actually specific to media drivers I think that is a good case to be made to allow it to be selected manually. > >> @@ -119,16 +121,11 @@ config VIDEO_DEV >> tristate >> depends on MEDIA_SUPPORT >> depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || >> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT >> +select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER >> default y >> >> config VIDEO_V4L2_SUBDEV_API >> -bool "V4L2 sub-device userspace API" >> -depends on VIDEO_DEV && MEDIA_CONTROLLER >> ----help--- >> - Enables the V4L2 sub-device pad-level userspace API used to configure >> - video format, size and frame rate between hardware blocks. >> - >> - This API is mostly used by camera interfaces in embedded platforms. >> +bool > > NACK. > > There is a very good reason why the subdev API is optional: there > are drivers that use camera sensors but are not MC-centric. On those, > the USB bridge driver is responsible to setup the subdevice. > > This options helps to ensure that camera sensors used by such drivers > won't stop working because of the lack of the subdev-API. But they won't stop working if this is enabled. This option is used as a dependency by drivers that require this functionality, but enabling it will never break other drivers that don't need this. Those drivers simply won't use it. Also note that it is the bridge driver that controls whether or not the v4l-subdevX devices are created. If the bridge driver doesn't explicitly enable it AND the subdev driver explicitly supports it, those devices will not be created. Regards, Hans > >> >> source "drivers/media/v4l2-core/Kconfig" >> > > > > Thanks, > Mauro >
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil escreveu:
>
>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
>>> 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
>>>
>>> A proper way to initialize it with gcc is to use:
>>>
>>> struct foo f = { };
>>>
>>> But that seems to be a gcc extension. So, I decided to check upstream
>>
>> No, this is not a gcc extension. It's part of the latest C standard.
>
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.
I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.
In any case, it's used everywhere:
git grep '= *{ *}' drivers/
So it is really pointless to *not* use it.
Regards,
Hans
> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support, but, unfortunately, the
> clang compiler (not even the upstream version) is able to build
> the upstream Kernel yet, as it lacks asm-goto support (there is an
> OOT patch for llvm solving it - but it sounds too much effort for
> my time to have to build llvm from their sources just for a simple
> check like this).
>
>> It's used all over in the kernel, so please use {} instead of { NULL }.
>>
>> Personally I think {} is a fantastic invention and I wish C++ had it as
>> well.
>
> Fully agreed on that.
>
>>
>> Regards,
>>
>> Hans
>>
>>> what's the most commonly pattern. The gcc 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
>>>
>>> So, let's initialize those structs with:
>>> = { NULL }
>>>
>>> Signed-off-by: Mauro Carvalho Chehab
>>> ---
>>> 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 b538eb0321d8..44c45c687503 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 = { NULL };
>>>
>>> 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..4099a42dba2d 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 = { NULL };
>>> struct media_request *src_req;
>>> unsigned long flags;
>>>
>>>
>>
>
>
>
> Thanks,
> Mauro
>
Re: [PATCH] media: cedrus: don't initialize pointers with zero
Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil escreveu:
> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > 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
> >
> > A proper way to initialize it with gcc is to use:
> >
> > struct foo f = { };
> >
> > But that seems to be a gcc extension. So, I decided to check upstream
>
> No, this is not a gcc extension. It's part of the latest C standard.
Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.
I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).
> It's used all over in the kernel, so please use {} instead of { NULL }.
>
> Personally I think {} is a fantastic invention and I wish C++ had it as
> well.
Fully agreed on that.
>
> Regards,
>
> Hans
>
> > what's the most commonly pattern. The gcc 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
> >
> > So, let's initialize those structs with:
> > = { NULL }
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > 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 b538eb0321d8..44c45c687503 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 = { NULL };
> >
> > 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..4099a42dba2d 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 = { NULL };
> > struct media_request *src_req;
> > unsigned long flags;
> >
> >
>
Thanks,
Mauro
Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support
Adding the actual author :-)
Regards,
Hans
On 12/07/2018 12:25 PM, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil wrote:
>>
>> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
>> Date: Wed, 5 Dec 2018 16:47:49 +0100
>> From: Paweł Chmiel
>> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
>> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org,
>> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
>> devicet...@vger.kernel.org, Paweł Chmiel
>>
>> If reset-gpio is defined, use it to bring device out of reset.
>> Without this, it's not possible to access si470x registers.
>>
>> Signed-off-by: Paweł Chmiel
>> ---
>> For some reason this patch was not picked up by patchwork. Resending to see
>> if
>> it is picked up now.
>> ---
>> drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
>> drivers/media/radio/si470x/radio-si470x.h | 1 +
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
>> b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> index a7ac09c55188..15eea2b2c90f 100644
>> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
>> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "radio-si470x.h"
>> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
>> radio->videodev.release = video_device_release_empty;
>> video_set_drvdata(>videodev, radio);
>> + radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(radio->gpio_reset)) {
>> + retval = PTR_ERR(radio->gpio_reset);
>> + dev_err(>dev, "Failed to request gpio: %d\n",
>> retval);
>> + goto err_all;
>> + }
>> +
>> + if (radio->gpio_reset)
>> + gpiod_set_value(radio->gpio_reset, 1);
>> +
>> /* power up : need 110ms */
>> radio->registers[POWERCFG] = POWERCFG_ENABLE;
>> if (si470x_set_register(radio, POWERCFG) < 0) {
>> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
>> video_unregister_device(>videodev);
>> + if (radio->gpio_reset)
>> + gpiod_set_value(radio->gpio_reset, 0);
>
> I have a question for you. If the gpio is the last of the bank
> acquired for this cpu, when you put to 0, then the gpio will
> be free on remove and the clock of the logic will be deactivated so I
> think that you don't have any
> garantee that the state will be 0
>
> Michael
>
>> +
>> return 0;
>> }
>> diff --git a/drivers/media/radio/si470x/radio-si470x.h
>> b/drivers/media/radio/si470x/radio-si470x.h
>> index 35fa0f3bbdd2..6fd6a399cb77 100644
>> --- a/drivers/media/radio/si470x/radio-si470x.h
>> +++ b/drivers/media/radio/si470x/radio-si470x.h
>> @@ -189,6 +189,7 @@ struct si470x_device {
>> #if IS_ENABLED(CONFIG_I2C_SI470X)
>> struct i2c_client *client;
>> + struct gpio_desc *gpio_reset;
>> #endif
>> };
>> -- 2.17.1
>>
>
>
Re: [PATCH v2 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support
On 11/22/2018 04:52 AM, Matt Ranostay wrote:
> Add initial support for MLX90640 thermal cameras which output an 32x24
> greyscale pixel image along with 2 rows of coefficent data.
>
> Because of this the data outputed is really 32x26 and needs the two rows
> removed after using the coefficent information to generate processed
> images in userspace.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Matt Ranostay
> ---
> .../bindings/media/i2c/melexis,mlx90640.txt | 20
> drivers/media/i2c/Kconfig | 1 +
> drivers/media/i2c/video-i2c.c | 110 +-
> 3 files changed, 130 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
This patch needs to be split up in two: one for the bindings, one for
the driver changes.
Once the bindings for the v3 of this patch are accepted, I can merge this.
Note that I am in the process of merging '[PATCH v3] media: video-i2c: check if
chip
struct has set_power function', so it shouldn't be necessary to repost that
patch.
Regards,
Hans
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> new file mode 100644
> index ..060d2b7a5893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> @@ -0,0 +1,20 @@
> +* Melexis MLX90640 FIR Sensor
> +
> +Melexis MLX90640 FIR sensor support which allows recording of thermal data
> +with 32x24 resolution excluding 2 lines of coefficient data that is used by
> +userspace to render processed frames.
> +
> +Required Properties:
> + - compatible : Must be "melexis,mlx90640"
> + - reg : i2c address of the device
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + mlx90640@33 {
> + compatible = "melexis,mlx90640";
> + reg = <0x33>;
> + };
> + ...
> + };
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 66bbbec487ec..24342f283f2a 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1097,6 +1097,7 @@ config VIDEO_I2C
> Enable the I2C transport video support which supports the
> following:
> * Panasonic AMG88xx Grid-Eye Sensors
> +* Melexis MLX90640 Thermal Cameras
>
> To compile this driver as a module, choose M here: the
> module will be called video-i2c
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index a64e1a725a20..d58f40334e8b 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -6,6 +6,7 @@
> *
> * Supported:
> * - Panasonic AMG88xx Grid-Eye Sensors
> + * - Melexis MLX90640 Thermal Cameras
> */
>
> #include
> @@ -18,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -66,12 +68,26 @@ static const struct v4l2_frmsize_discrete amg88xx_size = {
> .height = 8,
> };
>
> +static const struct v4l2_fmtdesc mlx90640_format = {
> + .pixelformat = V4L2_PIX_FMT_Y16_BE,
> +};
> +
> +static const struct v4l2_frmsize_discrete mlx90640_size = {
> + .width = 32,
> + .height = 26, /* 24 lines of pixel data + 2 lines of processing data */
> +};
> +
> static const struct regmap_config amg88xx_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> .max_register = 0xff
> };
>
> +static const struct regmap_config mlx90640_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 16,
> +};
> +
> struct video_i2c_chip {
> /* video dimensions */
> const struct v4l2_fmtdesc *format;
> @@ -88,6 +104,7 @@ struct video_i2c_chip {
> unsigned int bpp;
>
> const struct regmap_config *regmap_config;
> + struct nvmem_config *nvmem_config;
>
> /* setup function */
> int (*setup)(struct video_i2c_data *data);
> @@ -102,6 +119,22 @@ struct video_i2c_chip {
> int (*hwmon_init)(struct video_i2c_data *data);
> };
>
> +static int mlx90640_nvram_read(void *priv, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct video_i2c_data *data = priv;
> +
> + return regmap_bulk_read(data->regmap, 0x2400 + offset, val, bytes);
> +}
> +
> +static struct nvmem_config mlx90640_nvram_config = {
> + .name = "mlx90640_nvram",
> + .word_size = 2,
> + .stride = 1,
> + .size = 1664,
> + .reg_read = mlx90640_nvram_read,
> +};
> +
> /* Power control register */
> #define AMG88XX_REG_PCTL 0x00
> #define AMG88XX_PCTL_NORMAL 0x00
> @@ -122,12 +155,23 @@ struct video_i2c_chip {
> /* Temperature register */
> #define AMG88XX_REG_T01L 0x80
>
> +/* Control register */
> +#define MLX90640_REG_CTL10x800d
> +#define MLX90640_REG_CTL1_MASK 0x0380
> +#define MLX90640_REG_CTL1_MASK_SHIFT 7
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 10:09:04 +0100 Hans Verkuil escreveu: > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > This will allow us to simplify drivers that currently have to add > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > to their code, since now this will always be available. > > The original intent of allowing these to be configured by the > user was (I think) to save a bit of memory. No. The original intent was/is to be sure that adding the media controller support won't be breaking existing working drivers. > But as more and more > drivers have a media controller and all regular distros already > enable one or more of those drivers, the memory for the MC code is > there anyway. > > Complexity has always been the bane of media drivers, so reducing > complexity at the expense of a bit more memory (which is a rounding > error compared to the amount of video buffer memory needed) is IMHO > a good thing. > > Signed-off-by: Hans Verkuil > --- > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > index 8add62a18293..56eb01cc8bb4 100644 > --- a/drivers/media/Kconfig > +++ b/drivers/media/Kconfig > @@ -31,6 +31,7 @@ comment "Multimedia core support" > # > config MEDIA_CAMERA_SUPPORT > bool "Cameras/video grabbers support" > + select MEDIA_CONTROLLER > ---help--- > Enable support for webcams and video grabbers. > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > config MEDIA_ANALOG_TV_SUPPORT > bool "Analog TV support" > + select MEDIA_CONTROLLER > ---help--- > Enable analog TV support. > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > config MEDIA_DIGITAL_TV_SUPPORT > bool "Digital TV support" > + select MEDIA_CONTROLLER > ---help--- > Enable digital TV support. See my comments below. > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > config MEDIA_CONTROLLER > bool "Media Controller API" > - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_DIGITAL_TV_SUPPORT > ---help--- > Enable the media controller API used to query media devices internal > topology and configure it dynamically. I have split comments with regards to it. Yeah, nowadays media controller has becoming more important. Still, a lot of media drivers work fine without them. Anyway, if we're willing to make it mandatory, better to just remove the entire config option or to make it a silent one. > @@ -119,16 +121,11 @@ config VIDEO_DEV > tristate > depends on MEDIA_SUPPORT > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > default y > > config VIDEO_V4L2_SUBDEV_API > - bool "V4L2 sub-device userspace API" > - depends on VIDEO_DEV && MEDIA_CONTROLLER > - ---help--- > - Enables the V4L2 sub-device pad-level userspace API used to configure > - video format, size and frame rate between hardware blocks. > - > - This API is mostly used by camera interfaces in embedded platforms. > + bool NACK. There is a very good reason why the subdev API is optional: there are drivers that use camera sensors but are not MC-centric. On those, the USB bridge driver is responsible to setup the subdevice. This options helps to ensure that camera sensors used by such drivers won't stop working because of the lack of the subdev-API. > > source "drivers/media/v4l2-core/Kconfig" > Thanks, Mauro
Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support
Hi
On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil wrote:
>
> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
> Date: Wed, 5 Dec 2018 16:47:49 +0100
> From: Paweł Chmiel
> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org,
> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
> devicet...@vger.kernel.org, Paweł Chmiel
>
> If reset-gpio is defined, use it to bring device out of reset.
> Without this, it's not possible to access si470x registers.
>
> Signed-off-by: Paweł Chmiel
> ---
> For some reason this patch was not picked up by patchwork. Resending to see if
> it is picked up now.
> ---
> drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
> drivers/media/radio/si470x/radio-si470x.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
> b/drivers/media/radio/si470x/radio-si470x-i2c.c
> index a7ac09c55188..15eea2b2c90f 100644
> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "radio-si470x.h"
> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
> radio->videodev.release = video_device_release_empty;
> video_set_drvdata(>videodev, radio);
> + radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(radio->gpio_reset)) {
> + retval = PTR_ERR(radio->gpio_reset);
> + dev_err(>dev, "Failed to request gpio: %d\n", retval);
> + goto err_all;
> + }
> +
> + if (radio->gpio_reset)
> + gpiod_set_value(radio->gpio_reset, 1);
> +
> /* power up : need 110ms */
> radio->registers[POWERCFG] = POWERCFG_ENABLE;
> if (si470x_set_register(radio, POWERCFG) < 0) {
> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
> video_unregister_device(>videodev);
> + if (radio->gpio_reset)
> + gpiod_set_value(radio->gpio_reset, 0);
I have a question for you. If the gpio is the last of the bank
acquired for this cpu, when you put to 0, then the gpio will
be free on remove and the clock of the logic will be deactivated so I
think that you don't have any
garantee that the state will be 0
Michael
> +
> return 0;
> }
> diff --git a/drivers/media/radio/si470x/radio-si470x.h
> b/drivers/media/radio/si470x/radio-si470x.h
> index 35fa0f3bbdd2..6fd6a399cb77 100644
> --- a/drivers/media/radio/si470x/radio-si470x.h
> +++ b/drivers/media/radio/si470x/radio-si470x.h
> @@ -189,6 +189,7 @@ struct si470x_device {
> #if IS_ENABLED(CONFIG_I2C_SI470X)
> struct i2c_client *client;
> + struct gpio_desc *gpio_reset;
> #endif
> };
> -- 2.17.1
>
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> 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
>
> A proper way to initialize it with gcc is to use:
>
> struct foo f = { };
>
> But that seems to be a gcc extension. So, I decided to check upstream
No, this is not a gcc extension. It's part of the latest C standard.
It's used all over in the kernel, so please use {} instead of { NULL }.
Personally I think {} is a fantastic invention and I wish C++ had it as
well.
Regards,
Hans
> what's the most commonly pattern. The gcc 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
>
> So, let's initialize those structs with:
>= { NULL }
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> 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 b538eb0321d8..44c45c687503 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 = { NULL };
>
> 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..4099a42dba2d 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 = { NULL };
> struct media_request *src_req;
> unsigned long flags;
>
>
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Patrick,
On Fri, Dec 07, 2018 at 10:57:21AM +0100, Patrick LERDA wrote:
> Add support for RCMM infrared remote controls.
>
> Signed-off-by: Patrick Lerda
Other than the Signed-off-by this looks exactly like the v2 version;
did you see my other comments on the v2 patch?
Thanks
Sean
> ---
> drivers/media/rc/Kconfig | 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-rcmm-decoder.c | 185 +
> drivers/media/rc/rc-core-priv.h| 5 +
> drivers/media/rc/rc-main.c | 3 +
> include/media/rc-map.h | 6 +-
> include/uapi/linux/lirc.h | 1 +
> tools/include/uapi/linux/lirc.h| 1 +
> 8 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
> remote control and you would like to use it with a raw IR
> receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE
> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
> endif #RC_DECODERS
>
> menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
> obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
> obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
> obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..94d5b70f7a0f
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "rc-core-priv.h"
> +#include
> +#include
> +
> +
> +#define RCMM_UNIT17 /* nanosecs */
> +#define RCMM_0_NBITS 64
> +#define RCMM_PREFIX_PULSE41 /* 16.6*2.5 */
> +#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK 0x
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev: the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = >raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */
> + if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
> + break;
> +
> + data->state =
Re: [PATCH] media: venus: Add support for H265 controls required by gstreamer V4L2 H265 module
Hi Kelvin, Thanks for the patch! On 11/30/18 7:31 PM, Kelvin Lawson wrote: > Add support for V4L2_CID_MPEG_VIDEO_HEVC_PROFILE and > V4L2_CID_MPEG_VIDEO_HEVC_LEVEL controls required by gstreamer V4L2 H265 > encoder module. > > Signed-off-by: Kelvin Lawson > --- > drivers/media/platform/qcom/venus/venc_ctrls.c | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c > b/drivers/media/platform/qcom/venus/venc_ctrls.c > index 45910172..ad1a4d8 100644 > --- a/drivers/media/platform/qcom/venus/venc_ctrls.c > +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c > @@ -101,6 +101,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) > case V4L2_CID_MPEG_VIDEO_H264_PROFILE: > ctr->profile.h264 = ctrl->val; > break; > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: > + ctr->profile.hevc = ctrl->val; > + break; > case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: > ctr->profile.vpx = ctrl->val; > break; > @@ -110,6 +113,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) > case V4L2_CID_MPEG_VIDEO_H264_LEVEL: > ctr->level.h264 = ctrl->val; > break; > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL: > + ctr->level.hevc = ctrl->val; > + break; > case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP: > ctr->h264_i_qp = ctrl->val; > break; > @@ -217,6 +223,19 @@ int venc_ctrl_init(struct venus_inst *inst) > 0, V4L2_MPEG_VIDEO_MPEG4_LEVEL_0); > > v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, > + V4L2_CID_MPEG_VIDEO_HEVC_PROFILE, > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10, > + ~((1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) | > + (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE) | > + (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10)), > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN); > + > + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, > + V4L2_CID_MPEG_VIDEO_HEVC_LEVEL, > + V4L2_MPEG_VIDEO_HEVC_LEVEL_6_2, > + 0, V4L2_MPEG_VIDEO_HEVC_LEVEL_1); > + > + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, you are adding two new menu controls but forgot to increment the count of controls in v4l2_ctrl_handler_init(). Can you resend with that fixed? > V4L2_CID_MPEG_VIDEO_H264_PROFILE, > V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH, > ~((1 << V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) | > -- regards, Stan
Re: [PATCH v2] media: venus: Support V4L2 QP parameters in Venus encoder
Hi Kelvin, Thanks for the patch! On 11/30/18 2:07 AM, Kelvin Lawson wrote: > Support V4L2 QP parameters in Venus encoder: > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP > * V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP > * V4L2_CID_MPEG_VIDEO_H264_MIN_QP > * V4L2_CID_MPEG_VIDEO_H264_MAX_QP > > Signed-off-by: Kelvin Lawson > --- > drivers/media/platform/qcom/venus/venc.c | 19 +++ > 1 file changed, 19 insertions(+) Acked-by: Stanimir Varbanov -- regards, Stan
Re: Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support
Hi Hans, On Fri, Dec 7, 2018 at 12:08 AM Hans Verkuil wrote: > > Mauro raised a number of objections on irc regarding tags: > > https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu > > I would like to setup an irc meeting to discuss this and come to a > conclusion, since we need to decide this soon since this is critical > for stateless codec support. > > Unfortunately timezone-wise this is a bit of a nightmare. I think > that at least Mauro, myself and Tomasz Figa should be there, so UTC-2, > UTC+1 and UTC+9 (if I got that right). > > I propose 9 AM UTC which I think will work for everyone except Nicolas. > Any day next week works for me, and (for now) as well for Mauro. Let's pick > Monday to start with, and if you want to join in, then let me know. If that > day doesn't work for you, let me know what other days next week do work for > you. Monday (or any other day next week) 9AM UTC should work for me! Thanks, Alex.
RE,
-- Hello First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you.
Re: [PATCH v5] media: imx: add mem2mem device
Hi Hans,
On 12/6/18 4:32 AM, Hans Verkuil wrote:
On 12/06/18 00:13, Steve Longerbeam wrote:
On 12/5/18 10:50 AM, Hans Verkuil wrote:
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.
If it is standalone, is it reused in newer iMX versions? (7 or 8)
No, this driver makes use of the Image Converter in IPUv3, so it will
only run on iMX 5/6. The IPU has been dropped in iMX 7 and 8.
And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).
Ok, I'll leave that up to Philipp. I don't mind either way whether it is
folded into imx-media device, or whether it is made stand-alone with or
without a new media device.
Steve
Re: [PATCH v2] media: rockchip vpu: remove some unused vars
On Wed, 2018-12-05 at 19:01 -0500, Mauro Carvalho Chehab wrote:
> As complained by gcc:
>
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
> function 'rk3288_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
> function 'rk3399_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_queue_setup':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_buf_prepare':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Ezequiel Garcia
Thanks!
> ---
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 --
> 3 files changed, 16 deletions(-)
>
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index e27c10855de5..5282236d1bb1 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 5f75e4d11d76..dbc86d95fe3b 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> index 038a7136d5d1..ab0fb2053620 100644
> --- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> @@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
>struct device *alloc_devs[])
> {
> struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
> struct v4l2_pix_format_mplane *pixfmt;
> int i;
>
> switch (vq->type) {
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - vpu_fmt = ctx->vpu_dst_fmt;
> pixfmt = >dst_fmt;
> break;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - vpu_fmt = ctx->vpu_src_fmt;
> pixfmt =
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 6 Dec 2018 17:07:52 -0200
Mauro Carvalho Chehab escreveu:
> Em Thu, 6 Dec 2018 13:36:24 -0500
> Alex Deucher escreveu:
>
> > On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab
> > wrote:
> > >
> > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > Markus Dobel escreveu:
> > >
> > > > Hi everyone,
> > > >
> > > > I will try if the hack mentioned fixes the issue for me on the weekend
> > > > (but I assume, as if effectively removes the function).
> > >
> > > It should, but it keeps a few changes. Just want to be sure that what
> > > would be left won't cause issues. If this works, the logic that would
> > > solve Ryzen DMA fixes will be contained into a single point, making
> > > easier to maintain it.
> > >
> > > >
> > > > Just in case this is of interest, I neither have Ryzen nor Intel, but
> > > > an HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is
> > > > more on the slow side.
> > >
> > > Good to know. It would probably worth to check if this Ryzen
> > > bug occors with all versions of it or with just a subset.
> > > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > > affect Ryzen 2 (or vice versa).
> >
> > The original commit also mentions some Xeons are affected too. Seems
> > like this is potentially an issue on the device side rather than the
> > platform.
>
> Maybe.
>
> > >
> > > The PCI quirks logic will likely need to detect the PCI ID of
> > > the memory controllers found at the buggy CPUs, in order to enable
> > > the quirk only for the affected ones.
> > >
> > > It could be worth talking with AMD people in order to be sure about
> > > the differences at the DMA engine side.
> > >
> >
> > It's not clear to me what the pci or platform quirk would do. The
> > workaround seems to be in the driver, not on the platform.
>
> Yeah, the fix should be at the driver, but pci/quirk.c would be able
> to detect memory controllers that would require a hack inside the
> driver, in a similar way to what the media PCI drivers already do
> for DMA controllers that don't support pci2pci transfers.
>
> There, basically the PCI core (drivers/pci/pci.c and
> drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
> potential issues.
>
> Then, the driver compares such flag in order to enable the specific quirk.
>
> Ok, there would be a different way to handle it. The driver could use a
> logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
> the logic seeks for some specific PCI device IDs using pci_get_device(),
> adjusting the code accordingly, depending on the detected PCI devices.
>
> In other words, running something like this (untested), at probe time should
> produce similar results:
>
> /*
>* FIXME: It probably makes sense to also be able to identify specific
>* versions of the same PCI ID, just in case a latter stepping got a
>* fix for the issue.
>*/
> const static struct {
> int vendor, dev;
> } broken_dev_id[] = {
> PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
> PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
> },
>
> bool cx23885_does_dma_require_reset(void)
> {
> int i;
> struct pci_dev *pdev = NULL;
>
> for (i = 0; i < sizeof(broken_dev_id); i++) {
> pdev = pci_get_device(broken_dev_id[i].vendor,
> broken_dev_id[i].dev, NULL);
> if (pdev) {
> pci_put_device(pdev);
> return true;
> }
> }
> return false;
> }
>
> Should work. In any case, we need to know what memory controllers
> have problems, and what are their PCI IDs, and add them (if not there yet)
> at include/linux/pci_ids.h
>
> Thanks,
> Mauro
To be clearer, I'm thinking on something like the (untested)
code below (untested).
PS.: the PCI ID used there may be wrong. I just added one in
order to have a proof of concept.
Thanks,
Mauro
[PATCH] media: cx23885: only reset DMA on problematic CPUs
It is reported that changeset 95f408bbc4e4 ("media: cx23885:
Ryzen DMA related RiSC engine stall fixes") caused regresssions
with other CPUs.
Ensure that the quirk will be applied only for the CPUs that
are known to cause problems.
Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall
fixes")
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..48da7d194cc1 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -603,8 +604,13 @@ static void cx23885_risc_disasm(struct cx23885_tsport
*port,
static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
{
- uint32_t
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 6 Dec 2018 13:36:24 -0500
Alex Deucher escreveu:
> On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab
> wrote:
> >
> > Em Thu, 06 Dec 2018 18:18:23 +0100
> > Markus Dobel escreveu:
> >
> > > Hi everyone,
> > >
> > > I will try if the hack mentioned fixes the issue for me on the weekend
> > > (but I assume, as if effectively removes the function).
> >
> > It should, but it keeps a few changes. Just want to be sure that what
> > would be left won't cause issues. If this works, the logic that would
> > solve Ryzen DMA fixes will be contained into a single point, making
> > easier to maintain it.
> >
> > >
> > > Just in case this is of interest, I neither have Ryzen nor Intel, but an
> > > HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is more
> > > on the slow side.
> >
> > Good to know. It would probably worth to check if this Ryzen
> > bug occors with all versions of it or with just a subset.
> > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > affect Ryzen 2 (or vice versa).
>
> The original commit also mentions some Xeons are affected too. Seems
> like this is potentially an issue on the device side rather than the
> platform.
Maybe.
> >
> > The PCI quirks logic will likely need to detect the PCI ID of
> > the memory controllers found at the buggy CPUs, in order to enable
> > the quirk only for the affected ones.
> >
> > It could be worth talking with AMD people in order to be sure about
> > the differences at the DMA engine side.
> >
>
> It's not clear to me what the pci or platform quirk would do. The
> workaround seems to be in the driver, not on the platform.
Yeah, the fix should be at the driver, but pci/quirk.c would be able
to detect memory controllers that would require a hack inside the
driver, in a similar way to what the media PCI drivers already do
for DMA controllers that don't support pci2pci transfers.
There, basically the PCI core (drivers/pci/pci.c and
drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
potential issues.
Then, the driver compares such flag in order to enable the specific quirk.
Ok, there would be a different way to handle it. The driver could use a
logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
the logic seeks for some specific PCI device IDs using pci_get_device(),
adjusting the code accordingly, depending on the detected PCI devices.
In other words, running something like this (untested), at probe time should
produce similar results:
/*
* FIXME: It probably makes sense to also be able to identify specific
* versions of the same PCI ID, just in case a latter stepping got a
* fix for the issue.
*/
const static struct {
int vendor, dev;
} broken_dev_id[] = {
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
},
bool cx23885_does_dma_require_reset(void)
{
int i;
struct pci_dev *pdev = NULL;
for (i = 0; i < sizeof(broken_dev_id); i++) {
pdev = pci_get_device(broken_dev_id[i].vendor,
broken_dev_id[i].dev, NULL);
if (pdev) {
pci_put_device(pdev);
return true;
}
}
return false;
}
Should work. In any case, we need to know what memory controllers
have problems, and what are their PCI IDs, and add them (if not there yet)
at include/linux/pci_ids.h
Thanks,
Mauro
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab wrote: > > Em Thu, 06 Dec 2018 18:18:23 +0100 > Markus Dobel escreveu: > > > Hi everyone, > > > > I will try if the hack mentioned fixes the issue for me on the weekend (but > > I assume, as if effectively removes the function). > > It should, but it keeps a few changes. Just want to be sure that what > would be left won't cause issues. If this works, the logic that would > solve Ryzen DMA fixes will be contained into a single point, making > easier to maintain it. > > > > > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP > > Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on > > the slow side. > > Good to know. It would probably worth to check if this Ryzen > bug occors with all versions of it or with just a subset. > I mean: maybe it is only at the first gen or Ryzen and doesn't > affect Ryzen 2 (or vice versa). The original commit also mentions some Xeons are affected too. Seems like this is potentially an issue on the device side rather than the platform. > > The PCI quirks logic will likely need to detect the PCI ID of > the memory controllers found at the buggy CPUs, in order to enable > the quirk only for the affected ones. > > It could be worth talking with AMD people in order to be sure about > the differences at the DMA engine side. > It's not clear to me what the pci or platform quirk would do. The workaround seems to be in the driver, not on the platform. Alex
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 06 Dec 2018 18:18:23 +0100 Markus Dobel escreveu: > Hi everyone, > > I will try if the hack mentioned fixes the issue for me on the weekend (but I > assume, as if effectively removes the function). It should, but it keeps a few changes. Just want to be sure that what would be left won't cause issues. If this works, the logic that would solve Ryzen DMA fixes will be contained into a single point, making easier to maintain it. > > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP > Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on the > slow side. Good to know. It would probably worth to check if this Ryzen bug occors with all versions of it or with just a subset. I mean: maybe it is only at the first gen or Ryzen and doesn't affect Ryzen 2 (or vice versa). The PCI quirks logic will likely need to detect the PCI ID of the memory controllers found at the buggy CPUs, in order to enable the quirk only for the affected ones. It could be worth talking with AMD people in order to be sure about the differences at the DMA engine side. Thanks, Mauro
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Hi everyone, I will try if the hack mentioned fixes the issue for me on the weekend (but I assume, as if effectively removes the function). Just in case this is of interest, I neither have Ryzen nor Intel, but an HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on the slow side. Regards, Markus -- Gesendet mit zwei Streichhölzern, einem Gummiband und etwas Draht.
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Hi Mauro & Markus,
On 05/12/2018 05.07, Mauro Carvalho Chehab wrote:
> Em Sun, 21 Oct 2018 15:45:39 +0200
> Markus Dobel escreveu:
>
>> The original commit (the one reverted in this patch) introduced a
>> regression,
>> making a previously flawless adapter unresponsive after running a few
>> hours
>> to days. Since I never experienced the problems that the original commit
>> is
>> supposed to fix, I propose to revert the change until a regression-free
>> variant is found.
>>
>> Before submitting this, I've been running a system 24x7 with this revert
>> for
>> several weeks now, and it's running stable again.
>>
>> It's not a pure revert, as the original commit does not revert cleanly
>> anymore due to other changes, but content-wise it is.
>>
>> Signed-off-by: Markus Dobel
>> ---
>> drivers/media/pci/cx23885/cx23885-core.c | 60
>> drivers/media/pci/cx23885/cx23885-reg.h | 14 --
>> 2 files changed, 74 deletions(-)
>>
>> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
>> b/drivers/media/pci/cx23885/cx23885-core.c
>> index 39804d830305..606f6fc0e68b 100644
>> --- a/drivers/media/pci/cx23885/cx23885-core.c
>> +++ b/drivers/media/pci/cx23885/cx23885-core.c
>> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct
>> cx23885_tsport *port,
> Patch was mangled by your e-mailer: it broke longer lines, causing
> it to not apply.
>
> Also, before just reverting the entire thing, could you please check
> if the enclosed hack would solve it?
>
> If so, it should be easy to add a quirk at drivers/pci/quirks.c
> in order to detect the Ryzen models with a bad DMA engine that
> require periodic resets, and then make cx23885 to use it.
>
> We did similar tricks before with some broken DMA engines, at
> the time we had overlay support on drivers and AMD controllers
> didn't support PCI2PCI DMA transfers.
>
> Brad,
>
> Could you please address this issue?
I'll try to address this today or tomorrow. Since the original patch was
applied I have not received any complaints from ryzen users, but we have
accumulated a few reports from Intel users with a variety of
motherboards that do now encounter issue. Strangely system load affects
the repro; low/no load exhibits the error condition, high system load
everything is fine. I'll do my best to send in a ryzen specific patch by
the weekend.
Regards,
Brad
>
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..8b012bee6b32 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport
> *port,
>
> static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
> {
> - uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
> - uint32_t reg2_val = cx_read(TC_REQ_SET);
> + uint32_t reg1_val, reg2_val;
> +
> + /* TODO: check for Ryzen quirk */
> + if (1)
> + return;
> +
> + reg1_val = cx_read(TC_REQ); /* read-only */
> + reg2_val = cx_read(TC_REQ_SET);
>
> if (reg1_val && reg2_val) {
> cx_write(TC_REQ, reg1_val);
>
>
>
> Thanks,
> Mauro
Re: [PATCH v6 00/12] media: ov5640: Misc cleanup and improvements
On Mon, Dec 3, 2018 at 2:14 PM Maxime Ripard wrote: > > Hi, > > Here is a "small" series that mostly cleans up the ov5640 driver code, > slowly getting rid of the big data array for more understandable code > (hopefully). > > The biggest addition would be the clock rate computation at runtime, > instead of relying on those arrays to setup the clock tree > properly. As a side effect, it fixes the framerate that was off by > around 10% on the smaller resolutions, and we now support 60fps. > > This also introduces a bunch of new features. > > Let me know what you think, > Maxime > > Changes from v5: > - Squashed Jacopo patches fixing MIPI-CSI > > Changes from v4: > - Squashed Jacopo patches fixing the MIPI-CSI case > - Prefer clock rates superior to the ideal clock rate, even if it > means having a less precise one. > - Fix the JPEG case according to Hugues suggestions > - Rebased on 4.20 > > Changes from v3: > - Rebased on current Sakari tree > - Fixed an error when changing only the framerate > > Changes from v2: > - Rebased on latest Sakari PR > - Fixed the issues reported by Hugues: improper FPS returned for > formats, improper rounding of the FPS, some with his suggestions, > some by simplifying the logic. > - Expanded the clock tree comments based on the feedback from Samuel > Bobrowicz and Loic Poulain > - Merged some of the changes made by Samuel Bobrowicz to fix the > MIPI rate computation, fix the call sites of the > ov5640_set_timings function, the auto-exposure calculation call, > etc. > - Split the patches into smaller ones in order to make it more > readable (hopefully) > > Changes from v1: > - Integrated Hugues' suggestions to fix v4l2-compliance > - Fixed the bus width with JPEG > - Dropped the clock rate calculation loops for something simpler as > suggested by Sakari > - Cache the exposure value instead of using the control value > - Rebased on top of 4.17 > > Jacopo Mondi (1): > media: ov5640: Fix set format regression > > Maxime Ripard (11): > media: ov5640: Adjust the clock based on the expected rate > media: ov5640: Remove the clocks registers initialization > media: ov5640: Remove redundant defines > media: ov5640: Remove redundant register setup > media: ov5640: Compute the clock rate at runtime > media: ov5640: Remove pixel clock rates > media: ov5640: Enhance FPS handling > media: ov5640: Make the return rate type more explicit > media: ov5640: Make the FPS clamping / rounding more extendable > media: ov5640: Add 60 fps support > media: ov5640: Remove duplicate auto-exposure setup Tested 320x240@30, 640x480@30, 640x480@60, 1280x720@30 with UYVY8_2X8 and YUYV8_2X8 formats. Tested-by: Jagan Teki # a64-amarula-relic
Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support
Mauro raised a number of objections on irc regarding tags:
https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu
I would like to setup an irc meeting to discuss this and come to a
conclusion, since we need to decide this soon since this is critical
for stateless codec support.
Unfortunately timezone-wise this is a bit of a nightmare. I think
that at least Mauro, myself and Tomasz Figa should be there, so UTC-2,
UTC+1 and UTC+9 (if I got that right).
I propose 9 AM UTC which I think will work for everyone except Nicolas.
Any day next week works for me, and (for now) as well for Mauro. Let's pick
Monday to start with, and if you want to join in, then let me know. If that
day doesn't work for you, let me know what other days next week do work for
you.
Regards,
Hans
On 12/05/18 11:20, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> Add support for 'tags' to struct v4l2_buffer. These can be used
> by m2m devices so userspace can set a tag for an output buffer and
> this value will then be copied to the capture buffer(s).
>
> This tag can be used to refer to capture buffers, something that
> is needed by stateless HW codecs.
>
> The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
> or not tags are supported.
>
> Signed-off-by: Hans Verkuil
> Reviewed-by: Paul Kocialkowski
> Reviewed-by: Alexandre Courbot
> ---
> include/uapi/linux/videodev2.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2db1635de956..9095d7abe10d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> #define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> +#define V4L2_BUF_CAP_SUPPORTS_TAGS (1 << 5)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
> @@ -940,6 +941,7 @@ struct v4l2_plane {
> * @length: size in bytes of the buffer (NOT its payload) for single-plane
> * buffers (when type != *_MPLANE); number of elements in the
> * planes array for multi-plane buffers
> + * @tag: buffer tag
> * @request_fd: fd of the request that this buffer should use
> *
> * Contains data exchanged by application and driver using one of the
> Streaming
> @@ -964,7 +966,10 @@ struct v4l2_buffer {
> __s32 fd;
> } m;
> __u32 length;
> - __u32 reserved2;
> + union {
> + __u32 reserved2;
> + __u32 tag;
> + };
> union {
> __s32 request_fd;
> __u32 reserved;
> @@ -990,6 +995,8 @@ struct v4l2_buffer {
> #define V4L2_BUF_FLAG_IN_REQUEST 0x0080
> /* timecode field is valid */
> #define V4L2_BUF_FLAG_TIMECODE 0x0100
> +/* tag field is valid */
> +#define V4L2_BUF_FLAG_TAG0x0200
> /* Buffer is prepared for queuing */
> #define V4L2_BUF_FLAG_PREPARED 0x0400
> /* Cache handling flags */
>
Re: [PATCH] [PATCHv2] Add ir-rcmm-driver
On Wed, Dec 05, 2018 at 01:29:33AM +0100, patrick9...@free.fr wrote:
> From: Patrick LERDA
>
We need a Signed-off-by: here.
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> ---
> drivers/media/rc/Kconfig | 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-rcmm-decoder.c | 185 +
> drivers/media/rc/rc-core-priv.h| 5 +
> drivers/media/rc/rc-main.c | 3 +
> include/media/rc-map.h | 6 +-
> include/uapi/linux/lirc.h | 1 +
> tools/include/uapi/linux/lirc.h| 1 +
> 8 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
> remote control and you would like to use it with a raw IR
> receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE
You're not using bitreverse, so don't depend on it.
> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
> endif #RC_DECODERS
>
> menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
> obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
> obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
> obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..94d5b70f7a0f
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Replace this with the SPDX-License-Identifier.
> + */
> +
> +#include "rc-core-priv.h"
> +#include
> +#include
> +
> +
> +#define RCMM_UNIT17 /* nanosecs */
> +#define RCMM_0_NBITS 64
Not used.
> +#define RCMM_PREFIX_PULSE41 /* 16.6*2.5 */
> +#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK 0x
Not used.
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev: the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = >raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */
Use:
/*
* Note:
*/
Type multiline comments
Re: [PATCH v11 2/4] ARM: dts: rockchip: add VPU device node for RK3288
Am Freitag, 30. November 2018, 18:34:31 CET schrieb Ezequiel Garcia: > Add the Video Processing Unit node for RK3288 SoC. > > Fix the VPU IOMMU node, which was disabled and lacking > its power domain property. > > Reviewed-by: Tomasz Figa > Signed-off-by: Ezequiel Garcia applied for 4.21 after a tiny bit of reordering Thanks for seeing this through Heiko
Re: [PATCH v11 3/4] arm64: dts: rockchip: add VPU device node for RK3399
Am Freitag, 30. November 2018, 18:34:32 CET schrieb Ezequiel Garcia: > Add the Video Processing Unit node for the RK3399 SoC. > > Also, fix the VPU IOMMU node, which was disabled and lacking > its power domain property. > > Reviewed-by: Tomasz Figa > Signed-off-by: Ezequiel Garcia applied for 4.21 after a tiny bit of reordering Thanks for seeing this through Heiko
Re: [PATCH v5] media: imx: add mem2mem device
On 12/06/18 00:13, Steve Longerbeam wrote:
>
>
> On 12/5/18 10:50 AM, Hans Verkuil wrote:
>> On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
>>> Hi Hans, Philipp,
>>>
>>> One comment on my side...
>>>
>>> On 12/3/18 7:21 AM, Hans Verkuil wrote:
> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev
> *vdev)
> +{
> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
> + struct video_device *vfd = priv->vdev.vfd;
> +
> + mutex_lock(>mutex);
> +
> + if (video_is_registered(vfd)) {
> + video_unregister_device(vfd);
> + media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
>>> Yes, I agree there should be a call to
>>> v4l2_m2m_register_media_controller(). This driver does not connect with
>>> any of the imx-media entities, but calling it will at least make the
>>> mem2mem output/capture device entities (and processing entity) visible
>>> in the media graph.
>>>
>>> Philipp, can you pick/squash the following from my media-tree github fork?
>>>
>>> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
>>> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
>>> device")
>>> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>>>
>>> Steve
>>>
>> Why is this driver part of the imx driver? Since it doesn't connect with
>> any of the imx-media entities, doesn't that mean that this is really a
>> stand-alone driver?
>
> It is basically a stand-alone m2m driver, but it makes use of some
> imx-media utility functions like imx_media_enum_format(). Also making it
> a true stand-alone driver would require creating a second /dev/mediaN
> device.
If it is standalone, is it reused in newer iMX versions? (7 or 8)
And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).
Regards,
Hans
>
> Steve
>
Re: [PATCHv4 00/10] vb2/cedrus: add tag support
(fix copy and paste error in the cover letter) As was discussed here (among other places): https://lkml.org/lkml/2018/10/19/440 using capture queue buffer indices to refer to reference frames is not a good idea. A better idea is to use a 'tag' where the application can assign a u32 tag to an output buffer, which is then copied to the capture buffer(s) derived from the output buffer. It has been suggested that the timestamp can be used for this. But there are a number of reasons why this is a bad idea: 1) the struct timeval is converted to a u64 in vb2. So there can be all sorts of unexpected conversion issues. In particular, the output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily match the input. 2) it gets worse with the y2038 code where userspace either deals with a 32 bit tv_sec value or a 64 bit value. In other words, using timestamp for this is not a good idea. This implementation adds a new tag field in a union with the reserved2 field. The interpretation of that union depends on the flags field, so it still can be used for other things as well. In addition, in the previous patches the tag was in a union with the timecode field (again determined by the flags field), so if we need to cram additional information in this struct we can always put it in a union with the timecode field as well. It worked for the tag, it should work for other things. But we really need to start looking at a struct v4l2_ext_buffer. The first three patches add core tag support, the next two patches document the tag support, then a new helper function is added to v4l2-mem2mem.c to easily copy data from a source to a destination buffer that drivers can use. Next a new supports_tags vb2_queue flag is added to indicate that the driver supports tags. Ideally this should not be necessary, but that would require that all m2m drivers are converted to using the new helper function introduced in the previous patch. That takes more time then I have now. Finally the vim2m, vicodec and cedrus drivers are converted to support tags. I also removed the 'pad' fields from the mpeg2 control structs (it should never been added in the first place) and aligned the structs to a u32 boundary. Note that this might change further (Paul suggested using bitfields). Also note that the cedrus code doesn't set the sequence counter, that's something that should still be added before this driver can be moved out of staging. Note: if no buffer is found for a certain tag, then the dma address is just set to 0. That happened before as well with invalid buffer indices. This should be checked in the driver! Regards, Hans Changes since v3: - use reserved2 for the tag - split the documentation in two: one documenting the tag, one cleaning up the timecode documentation. Changes since v2: - rebased - added Reviewed-by tags - fixed a few remaining references in the documentation to the old v4l2_buffer_tag struct that was used in early versions of this series. Changes since v1: - changed to a u32 tag. Using a 64 bit tag was overly complicated due to the bad layout of the v4l2_buffer struct, and there is no real need for it by applications. Main changes since the RFC: - Added new buffer capability flag - Added m2m helper to copy data between buffers - Added documentation - Added tag logging in v4l2-ioctl.c Hans Verkuil (10): videodev2.h: add tag support vb2: add tag support v4l2-ioctl.c: log v4l2_buffer tag buffer.rst: document the new buffer tag feature. buffer.rst: clean up timecode documentation v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function vb2: add new supports_tags queue flag vim2m: add tag support vicodec: add tag support cedrus: add tag support Documentation/media/uapi/v4l/buffer.rst | 28 + .../media/uapi/v4l/vidioc-reqbufs.rst | 4 ++ .../media/common/videobuf2/videobuf2-v4l2.c | 41 --- drivers/media/platform/vicodec/vicodec-core.c | 14 ++- drivers/media/platform/vim2m.c| 14 ++- drivers/media/v4l2-core/v4l2-ctrls.c | 9 drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++-- drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++ drivers/staging/media/sunxi/cedrus/cedrus.h | 9 ++-- .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 -- .../staging/media/sunxi/cedrus/cedrus_video.c | 2 + include/media/v4l2-mem2mem.h | 21 ++ include/media/videobuf2-core.h| 2 + include/media/videobuf2-v4l2.h| 21 +- include/uapi/linux/v4l2-controls.h| 14 +++ include/uapi/linux/videodev2.h| 9 +++- 17 files changed, 168 insertions(+), 75 deletions(-) -- 2.19.1
Re: [PATCH v5] media: imx: add mem2mem device
On 12/5/18 10:50 AM, Hans Verkuil wrote:
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.
Steve
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 05 Dec 2018 17:02:46 -0300
Ezequiel Garcia escreveu:
> On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 5 Dec 2018 16:34:04 -0200
> > Mauro Carvalho Chehab escreveu:
> >
> > > Em Wed, 5 Dec 2018 17:29:38 +0100
> > > Hans Verkuil escreveu:
> > >
> > > > Note regarding the first 'Revert' patch: that is this patch:
> > > >
> > > > https://patchwork.linuxtv.org/patch/52869/
> > > >
> > > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > > upstream
> > > > yet, our master branch still has those old bindings.
> > > >
> > > > I decided to first apply the Revert patch, then add the new patch on
> > > > top.
> > > >
> > > > Regards,
> > > >
> > > > Hans
> > > >
> > > > The following changes since commit
> > > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > > >
> > > > media: v4l2: async: remove locking when initializing async notifier
> > > > (2018-12-05 06:51:28 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > > >
> > > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > > >
> > > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46
> > > > +0100)
> > > >
> > > >
> > > > Tag branch
> > > >
> > > >
> > > > Ezequiel Garcia (3):
> > > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > > media: dt-bindings: Document the Rockchip VPU bindings
> > > > media: add Rockchip VPU JPEG encoder driver
> > >
> > > Checkpatch produces a few warnings:
> > >
> > > # CHECK: Alignment should match open parenthesis
> > > # #385: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # CHECK: Alignment should match open parenthesis
> > > # #1124: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > > # + { .compatible = "rockchip,rk3399-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > > # + { .compatible = "rockchip,rk3288-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE'
> > > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > > # + if (bitstream == (formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE))
> > > #
> > > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> > >
>
> Please note that this last one is a false positive,
> the code needs those parenthesis.
Yes, I know. that "Unnecessary parentheses" warning should always be
taken with caution.
I've seen several cases where it was right, but, for the sake of a
better code readability, it was better to preserve it.
Thanks,
Mauro
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Dec 2018 16:34:04 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Em Wed, 5 Dec 2018 17:29:38 +0100
> > Hans Verkuil escreveu:
> >
> > > Note regarding the first 'Revert' patch: that is this patch:
> > >
> > > https://patchwork.linuxtv.org/patch/52869/
> > >
> > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > upstream
> > > yet, our master branch still has those old bindings.
> > >
> > > I decided to first apply the Revert patch, then add the new patch on top.
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > The following changes since commit
> > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > >
> > > media: v4l2: async: remove locking when initializing async notifier
> > > (2018-12-05 06:51:28 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > >
> > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > >
> > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> > >
> > >
> > > Tag branch
> > >
> > >
> > > Ezequiel Garcia (3):
> > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > media: dt-bindings: Document the Rockchip VPU bindings
> > > media: add Rockchip VPU JPEG encoder driver
> >
> > Checkpatch produces a few warnings:
> >
> > # CHECK: Alignment should match open parenthesis
> > # #385: FILE:
> > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # CHECK: Alignment should match open parenthesis
> > # #1124: FILE:
> > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> > #
> > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> > #
> > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > RK_VPU_MODE_NONE'
> > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> > #
> > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> >
Please note that this last one is a false positive,
the code needs those parenthesis.
Thanks!
Ezequiel
Re: [PATCH] media: rockchip/vpu: fix a few alignments
Em Wed, 5 Dec 2018 19:48:25 +0100 Hans Verkuil escreveu: > On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote: > > As reported by checkpatch.pl, some function calls have a wrong > > alignment. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > index 8919151e1631..e27c10855de5 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3288_vpu_set_src_img_ctrl(vpu, ctx); > > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3288_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > But now you get warnings because this is > 80 columns. > > I think the 'cure' is worse than the disease. > > I see this is already merged, but I don't think this patch improves > readability, > which is more important than a checkpatch warning IMHO. IMHO, it is a way more readable if things got aligned. Very very few people nowadays (if any) write patches directly at a 80 columns console. Btw, speaking about 80 cols, usually your commit messages are longer than that (the limit is actually 80 cols - 4). I keep fixing the corresponding checkpatch.pl warnings from your patches (when I have time) :-) > > Regards, > > Hans > > > > > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 > > | VEPU_REG_AXI_CTRL_INPUT_SWAP16 > > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > index 8afa2162bf9f..5f75e4d11d76 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3399_vpu_set_src_img_ctrl(vpu, ctx); > > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3399_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > > > reg = VEPU_REG_OUTPUT_SWAP32 > > | VEPU_REG_OUTPUT_SWAP16 > > > Thanks, Mauro
Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera
Em Wed, 5 Dec 2018 16:56:39 -0200 Mauro Carvalho Chehab escreveu: > Em Fri, 30 Nov 2018 15:58:07 +0100 > Andreas Pape escreveu: > > > Hi Kieran, > > > > thanks for the review. > > > > On Mon, 26 Nov 2018 12:48:08 + > > Kieran Bingham wrote: > > > > > This one worries me a little... (but hopefully not too much) > > > > > > > As mentioned, I don't have any experience concerning video drivers;-). I > > found > > this patch more or less experimentally > > > > > > > > > Signed-off-by: Andreas Pape > > > > --- > > > > drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c > > > > b/drivers/media/usb/stkwebcam/stk-webcam.c > > > > index e61427e50525..c64928e36a5a 100644 > > > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c > > > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c > > > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp, > > > > if (dev->sio_bufs == NULL) > > > > return -EINVAL; > > > > dev->sequence = 0; > > > > + stk_initialise(dev); > > > > + stk_setup_format(dev); > > > > > > Glancing through the code base - this seems to imply to me that s_fmt > > > was not set/called (presumably by cheese) as stk_setup_format() is > > > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume(). > > > > > > Is this an issue? > > > > > > I presume that this means the camera will just operate in a default > > > configuration until cheese chooses something more specific. > > > > > > > Could be. I had a video but colours, sensitivity and possibly other things > > were crap or at least very "psychedelic". Therefore the idea came up that > > some kind of initialisation was missing here. > > > > > Actually - looking further this seems to be the case, as the mode is > > > simply stored in dev->vsettings.mode, and so this last setup stage will > > > just ensure the configuration of the hardware matches the driver. > > > > > > So it seems reasonable to me - but should it be set any earlier? > > > Perhaps not. > > > > > > > > > Are there any complaints when running v4l2-compliance on this device node? > > > > > > > Here is the output of v4l2-compliance: > > > > v4l2-compliance SHA : not available > > > > Driver Info: > > Driver name : stk > > Card type : stk > > Bus info : usb-:00:1d.7-5 > > Driver version: 4.15.18 > > Capabilities : 0x8521 > > Video Capture > > Read/Write > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x0521 > > Video Capture > > Read/Write > > Streaming > > Extended Pix Format > > > > Compliance test for device /dev/video0 (not using libv4l2): > > > > Required ioctls: > > test VIDIOC_QUERYCAP: OK > > > > Allow for multiple opens: > > test second video open: OK > > test VIDIOC_QUERYCAP: OK > > test VIDIOC_G/S_PRIORITY: OK > > test for unlimited opens: OK > > > > Debug ioctls: > > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > > test VIDIOC_LOG_STATUS: OK > > > > Input ioctls: > > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > > test VIDIOC_ENUMAUDIO: OK (Not Supported) > > test VIDIOC_G/S/ENUMINPUT: OK > > test VIDIOC_G/S_AUDIO: OK (Not Supported) > > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > > > Output ioctls: > > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > > > Input/Output configuration ioctls: > > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > > test VIDIOC_G/S_EDID: OK (Not Supported) > > > > Test input 0: > > > > Control ioctls: > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > > test VIDIOC_QUERYCTRL: OK > > test VIDIOC_G/S_CTRL: OK > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > > Standard Controls: 4 Private Controls: 0 > > > > Format ioctls: > > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > > test VIDIOC_G/S_PARM: OK > > test VIDIOC_G_FBUF: OK (Not Supported) > > test VIDIOC_G_FMT: OK > > warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an > > invalid
Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera
Em Fri, 30 Nov 2018 15:58:07 +0100 Andreas Pape escreveu: > Hi Kieran, > > thanks for the review. > > On Mon, 26 Nov 2018 12:48:08 + > Kieran Bingham wrote: > > > This one worries me a little... (but hopefully not too much) > > > > As mentioned, I don't have any experience concerning video drivers;-). I found > this patch more or less experimentally > > > > > > Signed-off-by: Andreas Pape > > > --- > > > drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c > > > b/drivers/media/usb/stkwebcam/stk-webcam.c > > > index e61427e50525..c64928e36a5a 100644 > > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c > > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c > > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp, > > > if (dev->sio_bufs == NULL) > > > return -EINVAL; > > > dev->sequence = 0; > > > + stk_initialise(dev); > > > + stk_setup_format(dev); > > > > Glancing through the code base - this seems to imply to me that s_fmt > > was not set/called (presumably by cheese) as stk_setup_format() is > > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume(). > > > > Is this an issue? > > > > I presume that this means the camera will just operate in a default > > configuration until cheese chooses something more specific. > > > > Could be. I had a video but colours, sensitivity and possibly other things > were crap or at least very "psychedelic". Therefore the idea came up that > some kind of initialisation was missing here. > > > Actually - looking further this seems to be the case, as the mode is > > simply stored in dev->vsettings.mode, and so this last setup stage will > > just ensure the configuration of the hardware matches the driver. > > > > So it seems reasonable to me - but should it be set any earlier? > > Perhaps not. > > > > > > Are there any complaints when running v4l2-compliance on this device node? > > > > Here is the output of v4l2-compliance: > > v4l2-compliance SHA : not available > > Driver Info: > Driver name : stk > Card type : stk > Bus info : usb-:00:1d.7-5 > Driver version: 4.15.18 > Capabilities : 0x8521 > Video Capture > Read/Write > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0521 > Video Capture > Read/Write > Streaming > Extended Pix Format > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 4 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an > invalid pixelformat. > warn: v4l2-test-formats.cpp(733): This may or may not be a > problem. For more information see: > warn: v4l2-test-formats.cpp(734): > http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html > test
Re: [PATCH v5] media: imx: add mem2mem device
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
> Hi Hans, Philipp,
>
> One comment on my side...
>
> On 12/3/18 7:21 AM, Hans Verkuil wrote:
>>
>>> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
>>> +{
>>> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
>>> + struct video_device *vfd = priv->vdev.vfd;
>>> +
>>> + mutex_lock(>mutex);
>>> +
>>> + if (video_is_registered(vfd)) {
>>> + video_unregister_device(vfd);
>>> + media_entity_cleanup(>entity);
>> Is this needed?
>>
>> If this is to be part of the media controller, then I expect to see a call
>> to v4l2_m2m_register_media_controller() somewhere.
>>
>
> Yes, I agree there should be a call to
> v4l2_m2m_register_media_controller(). This driver does not connect with
> any of the imx-media entities, but calling it will at least make the
> mem2mem output/capture device entities (and processing entity) visible
> in the media graph.
>
> Philipp, can you pick/squash the following from my media-tree github fork?
>
> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
> device")
> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>
> Steve
>
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
Regards,
Hans
Re: [PATCH] media: rockchip/vpu: fix a few alignments
On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote: > As reported by checkpatch.pl, some function calls have a wrong > alignment. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > index 8919151e1631..e27c10855de5 100644 > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) > rk3288_vpu_set_src_img_ctrl(vpu, ctx); > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > rk3288_vpu_jpeg_enc_set_qtable(vpu, > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > +rockchip_vpu_jpeg_get_qtable(_ctx, > 0), > +rockchip_vpu_jpeg_get_qtable(_ctx, > 1)); But now you get warnings because this is > 80 columns. I think the 'cure' is worse than the disease. I see this is already merged, but I don't think this patch improves readability, which is more important than a checkpatch warning IMHO. Regards, Hans > > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 > | VEPU_REG_AXI_CTRL_INPUT_SWAP16 > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > index 8afa2162bf9f..5f75e4d11d76 100644 > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx) > rk3399_vpu_set_src_img_ctrl(vpu, ctx); > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > rk3399_vpu_jpeg_enc_set_qtable(vpu, > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > +rockchip_vpu_jpeg_get_qtable(_ctx, > 0), > +rockchip_vpu_jpeg_get_qtable(_ctx, > 1)); > > reg = VEPU_REG_OUTPUT_SWAP32 > | VEPU_REG_OUTPUT_SWAP16 >
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 5 Dec 2018 16:34:04 -0200
Mauro Carvalho Chehab escreveu:
> Em Wed, 5 Dec 2018 17:29:38 +0100
> Hans Verkuil escreveu:
>
> > Note regarding the first 'Revert' patch: that is this patch:
> >
> > https://patchwork.linuxtv.org/patch/52869/
> >
> > It is currently pending for 4.20 as a fix, but since it is not merged
> > upstream
> > yet, our master branch still has those old bindings.
> >
> > I decided to first apply the Revert patch, then add the new patch on top.
> >
> > Regards,
> >
> > Hans
> >
> > The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> >
> > media: v4l2: async: remove locking when initializing async notifier
> > (2018-12-05 06:51:28 -0500)
> >
> > are available in the Git repository at:
> >
> > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> >
> > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> >
> > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> >
> >
> > Tag branch
> >
> >
> > Ezequiel Garcia (3):
> > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > media: dt-bindings: Document the Rockchip VPU bindings
> > media: add Rockchip VPU JPEG encoder driver
>
> Checkpatch produces a few warnings:
>
> # CHECK: Alignment should match open parenthesis
> # #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> #
> # CHECK: Alignment should match open parenthesis
> # #1124: FILE:
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> #
> # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> #
> # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> #
> # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> RK_VPU_MODE_NONE'
> # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> #
> # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
>
> The more weird ones are the ones related to the DT bindings.
Hmm... those were my fault.
/me needs caffeine
>
> Regards,
> Mauro
>
> Thanks,
> Mauro
Thanks,
Mauro
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 5 Dec 2018 17:29:38 +0100
Hans Verkuil escreveu:
> Note regarding the first 'Revert' patch: that is this patch:
>
> https://patchwork.linuxtv.org/patch/52869/
>
> It is currently pending for 4.20 as a fix, but since it is not merged upstream
> yet, our master branch still has those old bindings.
>
> I decided to first apply the Revert patch, then add the new patch on top.
>
> Regards,
>
> Hans
>
> The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
>
> media: v4l2: async: remove locking when initializing async notifier
> (2018-12-05 06:51:28 -0500)
>
> are available in the Git repository at:
>
> git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
>
> for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
>
> media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
>
>
> Tag branch
>
>
> Ezequiel Garcia (3):
> Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> media: dt-bindings: Document the Rockchip VPU bindings
> media: add Rockchip VPU JPEG encoder driver
Checkpatch produces a few warnings:
# CHECK: Alignment should match open parenthesis
# #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
# + rk3288_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
#
# CHECK: Alignment should match open parenthesis
# #1124: FILE: drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
# + rk3399_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
#
# WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented --
check ./Documentation/devicetree/bindings/
# #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
# + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
#
# WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented --
check ./Documentation/devicetree/bindings/
# #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
# + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
#
# CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
RK_VPU_MODE_NONE'
# #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
# + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
#
# total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
The more weird ones are the ones related to the DT bindings.
Regards,
Mauro
Thanks,
Mauro
Re: [PATCH v2 1/1] media: Add a Kconfig option for the Request API
Em Wed, 5 Dec 2018 19:23:54 +0200
Sakari Ailus escreveu:
> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
>
> Add a Kconfig option for the API, with a scary-looking warning.
>
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
>
> Signed-off-by: Sakari Ailus
> Acked-by: Hans Verkuil
Looks good to me. I'll apply it.
> ---
> since v1:
>
> - Write out the #ifdef's in request creation
>
> - The option's functionality was reversed in request creation, fixed that
>
> drivers/media/Kconfig | 13 +
> drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
> drivers/media/media-device.c| 4
> drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
> 4 files changed, 20 insertions(+)
>
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>
> This is currently experimental.
>
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> + DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> + This option enables the Request API for the Media controller and V4L2
> + interfaces. It is currently needed by a few stateless codec drivers.
> +
> + There is currently no intention to provide API or ABI stability for
> + this new API as of yet.
> +
> #
> # Video4Linux support
> #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
> *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
> if (q->io_modes & VB2_DMABUF)
> *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (q->supports_requests)
> *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
> }
>
> int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..b8ec88612df7 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,10 +381,14 @@ static long media_device_get_topology(struct
> media_device *mdev, void *arg)
> static long media_device_request_alloc(struct media_device *mdev,
> int *alloc_fd)
> {
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> return -ENOTTY;
>
> return media_request_alloc(mdev, alloc_fd);
> +#else
> + return -ENOTTY;
> +#endif
> }
>
> static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int
> cmd)
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
> depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> depends on HAS_DMA
> depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
> select SUNXI_SRAM
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
Thanks,
Mauro
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
Hi Hans,
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote:
> On 11/30/18 18:34, Ezequiel Garcia wrote:
> > Add a mem2mem driver for the VPU available on Rockchip SoCs.
> > Currently only JPEG encoding is supported, for RK3399 and RK3288
> > platforms.
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
>
>
>
[..]
>
>
> Unless something unexpected happens, then v12 should be the final
> version and I'll make a pull request for it. Note that it will
> probably won't make 4.20, unless you manage to do it within the next
> hour :-)
>
Thanks for the review. Here are the changes that will be on v12.
Besides your feedback, I found a missing parenthesis issue,
which seems to have sneaked into v11! Apparently, v11 had
last minute changes and I failed to run v4l2-compliance.
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index f2752a0c71c0..962412c79b91 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -60,11 +60,13 @@ static void rockchip_vpu_job_finish(struct rockchip_vpu_dev
*vpu,
dst->sequence = ctx->sequence_cap++;
dst->field = src->field;
- if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
+ if (src->flags & V4L2_BUF_FLAG_TIMECODE)
dst->timecode = src->timecode;
dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
- dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ dst->flags &= ~(V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
+ dst->flags |= src->flags & (V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
avail_size = vb2_plane_size(>vb2_buf, 0) -
ctx->vpu_dst_fmt->header_size;
@@ -151,6 +153,12 @@ enc_queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *dst_vq)
src_vq->drv_priv = ctx;
src_vq->ops = _vpu_enc_queue_ops;
src_vq->mem_ops = _dma_contig_memops;
+
+ /*
+* Driver does mostly sequential access, so sacrifice TLB efficiency
+* for faster allocation. Also, no CPU access on the source queue,
+* so no kernel mapping needed.
+*/
src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
DMA_ATTR_NO_KERNEL_MAPPING;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
@@ -197,8 +205,6 @@ static int rockchip_vpu_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->jpeg_quality = ctrl->val;
break;
default:
- vpu_err("Invalid control id = %d, val = %d\n",
- ctrl->id, ctrl->val);
return -EINVAL;
}
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 6aadd194e999..3dbd15d5fabe 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -142,7 +142,7 @@ rockchip_vpu_get_default_fmt(struct rockchip_vpu_ctx *ctx,
bool bitstream)
formats = dev->variant->enc_fmts;
num_fmts = dev->variant->num_enc_fmts;
for (i = 0; i < num_fmts; i++) {
- if (bitstream == formats[i].codec_mode != RK_VPU_MODE_NONE)
+ if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
return [i];
}
return NULL;
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote: > Unless something unexpected happens, then v12 should be the final > version and I'll make a pull request for it. Note that it will > probably won't make 4.20, unless you manage to do it within the next > hour :-) Challenge accepted!
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
On 11/30/18 18:34, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
>
> Signed-off-by: Ezequiel Garcia
> ---
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> new file mode 100644
> index ..f2752a0c71c0
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> @@ -0,0 +1,531 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip VPU codec driver
> + *
> + * Copyright (C) 2018 Collabora, Ltd.
> + * Copyright 2018 Google LLC.
> + * Tomasz Figa
> + *
> + * Based on s5p-mfc driver by Samsung Electronics Co., Ltd.
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "rockchip_vpu_common.h"
> +#include "rockchip_vpu.h"
> +#include "rockchip_vpu_hw.h"
> +
> +#define DRIVER_NAME "rockchip-vpu"
> +
> +int rockchip_vpu_debug;
> +module_param_named(debug, rockchip_vpu_debug, int, 0644);
> +MODULE_PARM_DESC(debug,
> + "Debug level - higher value produces more verbose messages");
> +
> +static void rockchip_vpu_job_finish(struct rockchip_vpu_dev *vpu,
> + struct rockchip_vpu_ctx *ctx,
> + unsigned int bytesused,
> + enum vb2_buffer_state result)
> +{
> + struct vb2_v4l2_buffer *src, *dst;
> + size_t avail_size;
> +
> + pm_runtime_mark_last_busy(vpu->dev);
> + pm_runtime_put_autosuspend(vpu->dev);
> + clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
> +
> + src = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +
> + if (WARN_ON(!src))
> + return;
> + if (WARN_ON(!dst))
> + return;
> +
> + src->sequence = ctx->sequence_out++;
> + dst->sequence = ctx->sequence_cap++;
> +
> + dst->field = src->field;
> + if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
That should be src->flags
> + dst->timecode = src->timecode;
> + dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
> + dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> + dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
And this should clear and copy V4L2_BUF_FLAG_TIMECODE as well.
> +
> + avail_size = vb2_plane_size(>vb2_buf, 0) -
> + ctx->vpu_dst_fmt->header_size;
> + if (bytesused <= avail_size) {
> + if (ctx->bounce_buf) {
> + memcpy(vb2_plane_vaddr(>vb2_buf, 0) +
> +ctx->vpu_dst_fmt->header_size,
> +ctx->bounce_buf, bytesused);
> + }
> + dst->vb2_buf.planes[0].bytesused =
> + ctx->vpu_dst_fmt->header_size + bytesused;
> + } else {
> + result = VB2_BUF_STATE_ERROR;
> + }
> +
> + v4l2_m2m_buf_done(src, result);
> + v4l2_m2m_buf_done(dst, result);
> +
> + v4l2_m2m_job_finish(vpu->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +void rockchip_vpu_irq_done(struct rockchip_vpu_dev *vpu,
> +unsigned int bytesused,
> +enum vb2_buffer_state result)
> +{
> + struct rockchip_vpu_ctx *ctx =
> + v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> +
> + /*
> + * If cancel_delayed_work returns false
> + * the timeout expired. The watchdog is running,
> + * and will take care of finishing the job.
> + */
> + if (cancel_delayed_work(>watchdog_work))
> + rockchip_vpu_job_finish(vpu, ctx, bytesused, result);
> +}
> +
> +void rockchip_vpu_watchdog(struct work_struct *work)
> +{
> + struct rockchip_vpu_dev *vpu;
> + struct rockchip_vpu_ctx *ctx;
> +
> + vpu = container_of(to_delayed_work(work),
> +struct rockchip_vpu_dev, watchdog_work);
> + ctx = v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> + if (ctx) {
> + vpu_err("frame processing timed out!\n");
> + ctx->codec_ops->reset(ctx);
> + rockchip_vpu_job_finish(vpu, ctx, 0, VB2_BUF_STATE_ERROR);
> + }
> +}
> +
> +static void device_run(void *priv)
> +{
> + struct rockchip_vpu_ctx *ctx = priv;
> + int ret;
> +
> + ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks);
> + if (ret)
> + goto err_cancel_job;
> + ret = pm_runtime_get_sync(ctx->dev->dev);
> + if (ret < 0)
> + goto err_cancel_job;
> +
> + ctx->codec_ops->run(ctx);
> + return;
> +
> +err_cancel_job:
> + rockchip_vpu_job_finish(ctx->dev, ctx, 0, VB2_BUF_STATE_ERROR);
> +}
> +
> +static struct v4l2_m2m_ops vpu_m2m_ops = {
> + .device_run = device_run,
Re: [PATCH 1/1] ipu3-cio2: Allow probe to succeed if there are no sensors connected
On Wed, Dec 05, 2018 at 04:15:17PM +0200, Sakari Ailus wrote: > The device won't be powered off on systems that have no sensors connected > unless it has a driver bound to it. Allow that to happen even if there are > no sensors connected to cio2. Thanks for sending this. It helps to put the pci device to suspend which otherwise remains active after the probe for cio2 fails. I have verified it on HP Elitebook that has BIOS/DSDT more suitable for Windows. > > Signed-off-by: Sakari Ailus Reviewed-and-tested-by: Rajneesh Bhardwaj > --- > drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c > b/drivers/media/pci/intel/ipu3/ipu3-cio2.c > index 447baaebca448..e281e55cdca4a 100644 > --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c > +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c > @@ -1810,7 +1810,8 @@ static int cio2_pci_probe(struct pci_dev *pci_dev, > > /* Register notifier for subdevices we care */ > r = cio2_notifier_init(cio2); > - if (r) > + /* Proceed without sensors connected to allow the device to suspend. */ > + if (r && r != -ENODEV) > goto fail_cio2_queue_exit; > > r = devm_request_irq(_dev->dev, pci_dev->irq, cio2_irq, > -- > 2.11.0 > -- Best Regards, Rajneesh
Re: [PATCH for v4.20 0/2] cedrus: move MPEG controls out of the uAPI
Hi, On Wed, 2018-12-05 at 13:09 +0100, hverkuil-ci...@xs4all.nl wrote: > From: Hans Verkuil > > The expectation was that the MPEG-2 state controls used by the staging > cedrus driver were stable, or would only require one final change. However, > it turns out that more changes are required, and that means that it is not > such a good idea to have these controls in the public kernel API. > > This patch series moves all the MPEG-2 state control data to a new > media/mpeg2-ctrls.h header. So none of this is available from the public > API. > > However, v4l2-ctrls.h includes it for now so the kAPI still knows about it > allowing the cedrus driver to use it without changes. > > The second patch adds a note to these two controls, mentioning that they > are likely to change. > > Moving forward, this allows us to take more time in getting the MPEG-2 > (and later H264/5) state controls right. Thanks a lot for this change, I'm glad we can take time to properly stabilize these controls! For the whole series: Reviewed-by: Paul Kocialkowski Cheers, Paul > Regards, > > Hans > > Hans Verkuil (2): > mpeg2-ctrls.h: move MPEG2 state controls to non-public header > extended-controls.rst: add note to the MPEG2 state controls > > .../media/uapi/v4l/extended-controls.rst | 10 +++ > drivers/media/v4l2-core/v4l2-ctrls.c | 4 +- > include/media/mpeg2-ctrls.h | 86 +++ > include/media/v4l2-ctrls.h| 6 ++ > include/uapi/linux/v4l2-controls.h| 68 --- > include/uapi/linux/videodev2.h| 4 - > 6 files changed, 104 insertions(+), 74 deletions(-) > create mode 100644 include/media/mpeg2-ctrls.h > -- Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com
Re: [PATCH 1/1] media: Add a Kconfig option for the Request API
On 12/05/18 13:24, Sakari Ailus wrote:
> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
>
> Add a Kconfig option for the API, with a scary-looking warning.
>
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
>
> Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
> ---
> I hope this covers now everything... I was thinking how to make the option
> name itself more worrisome but I couldn't come up with a better language
> that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
> worn to be effective. :-I
>
> The patch can and should be reverted once we're entirely happy and
> confident with the API.
>
> drivers/media/Kconfig | 13 +
> drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
> drivers/media/media-device.c| 2 ++
> drivers/staging/media/sunxi/cedrus/Kconfig | 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>
> This is currently experimental.
>
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> + DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> + This option enables the Request API for the Media controller and V4L2
> + interfaces. It is currently needed by a few stateless codec drivers.
> +
> + There is currently no intention to provide API or ABI stability for
> + this new API as of yet.
> +
> #
> # Video4Linux support
> #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
> *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
> if (q->io_modes & VB2_DMABUF)
> *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (q->supports_requests)
> *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
> }
>
> int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..2ef114ce38d0 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,7 +381,9 @@ static long media_device_get_topology(struct media_device
> *mdev, void *arg)
> static long media_device_request_alloc(struct media_device *mdev,
> int *alloc_fd)
> {
> +#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
> if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> +#endif
> return -ENOTTY;
>
> return media_request_alloc(mdev, alloc_fd);
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
> depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
> depends on HAS_DMA
> depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
> select SUNXI_SRAM
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
>
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Sun, 21 Oct 2018 15:45:39 +0200
Markus Dobel escreveu:
> The original commit (the one reverted in this patch) introduced a
> regression,
> making a previously flawless adapter unresponsive after running a few
> hours
> to days. Since I never experienced the problems that the original commit
> is
> supposed to fix, I propose to revert the change until a regression-free
> variant is found.
>
> Before submitting this, I've been running a system 24x7 with this revert
> for
> several weeks now, and it's running stable again.
>
> It's not a pure revert, as the original commit does not revert cleanly
> anymore due to other changes, but content-wise it is.
>
> Signed-off-by: Markus Dobel
> ---
> drivers/media/pci/cx23885/cx23885-core.c | 60
> drivers/media/pci/cx23885/cx23885-reg.h | 14 --
> 2 files changed, 74 deletions(-)
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..606f6fc0e68b 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct
> cx23885_tsport *port,
Patch was mangled by your e-mailer: it broke longer lines, causing
it to not apply.
Also, before just reverting the entire thing, could you please check
if the enclosed hack would solve it?
If so, it should be easy to add a quirk at drivers/pci/quirks.c
in order to detect the Ryzen models with a bad DMA engine that
require periodic resets, and then make cx23885 to use it.
We did similar tricks before with some broken DMA engines, at
the time we had overlay support on drivers and AMD controllers
didn't support PCI2PCI DMA transfers.
Brad,
Could you please address this issue?
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..8b012bee6b32 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport
*port,
static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
{
- uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
- uint32_t reg2_val = cx_read(TC_REQ_SET);
+ uint32_t reg1_val, reg2_val;
+
+ /* TODO: check for Ryzen quirk */
+ if (1)
+ return;
+
+ reg1_val = cx_read(TC_REQ); /* read-only */
+ reg2_val = cx_read(TC_REQ_SET);
if (reg1_val && reg2_val) {
cx_write(TC_REQ, reg1_val);
Thanks,
Mauro
Re: [PATCH v3 0/9] TVP5150 fixes and new features
Hi Marco,
Em Fri, 9 Nov 2018 14:46:24 +0100
Marco Felsch escreveu:
> Hi Mauro,
>
> I don't want to spam you. Can you give me some feedback? I know the
> merge window is a busy time, so maybe you have some time now.
Sorry for taking so long on looking into it... has been really busy
those days :-(
I applied patch 2/9. Patch 3 doesn't apply. Would you mind
rebasing it on the top of upstream? there are some non-trivial
conflicts (perhaps I just missed some other preparation patch?).
I suspect that it would be easier if you could rebase your tree
on the top of the latest upstream one, e. g.:
git://linuxtv.org/media_tree.git
(master branch)
Regards,
Mauro
>
> Regards,
> Marco
>
> On 18-10-29 19:41, Marco Felsch wrote:
> > Hi Mauro,
> >
> > just a reminder, Rob already added his ack/rev-by tags.
> >
> > Thanks,
> > Marco
> >
> > On 18-09-18 15:14, Marco Felsch wrote:
> > > Hi,
> > >
> > > this is my v3 with the integrated reviews from my v2 [1]. This serie
> > > applies to Mauro's experimental.git [2].
> > >
> > > @Mauro:
> > > Patch ("media: tvp5150: fix irq_request error path during probe") is new
> > > in this series. Maybe you can squash them with ("media: tvp5150: Add sync
> > > lock
> > > interrupt handling"), thanks.
> > >
> > > I've tested this series on a customer dt-based board. Unfortunately I
> > > haven't a device which use the em28xx driver. So other tester a welcome :)
> > >
> > > [1] https://www.spinics.net/lists/devicetree/msg244129.html
> > > [2] https://git.linuxtv.org/mchehab/experimental.git/log/?h=tvp5150-4
> > >
> > > Javier Martinez Canillas (1):
> > > partial revert of "[media] tvp5150: add HW input connectors support"
> > >
> > > Marco Felsch (7):
> > > media: tvp5150: fix irq_request error path during probe
> > > media: tvp5150: add input source selection of_graph support
> > > media: dt-bindings: tvp5150: Add input port connectors DT bindings
> > > media: v4l2-subdev: add stubs for v4l2_subdev_get_try_*
> > > media: v4l2-subdev: fix v4l2_subdev_get_try_* dependency
> > > media: tvp5150: add FORMAT_TRY support for get/set selection handlers
> > > media: tvp5150: add s_power callback
> > >
> > > Michael Tretter (1):
> > > media: tvp5150: initialize subdev before parsing device tree
> > >
> > > .../devicetree/bindings/media/i2c/tvp5150.txt | 92 ++-
> > > drivers/media/i2c/tvp5150.c | 657 +-
> > > include/dt-bindings/media/tvp5150.h | 2 -
> > > include/media/v4l2-subdev.h | 15 +-
> > > 4 files changed, 584 insertions(+), 182 deletions(-)
> > >
> > > --
> > > 2.19.0
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions | http://www.pengutronix.de/ |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
> >
> >
>
Thanks,
Mauro
Re: [PATCH v9 04/13] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7
Hi Sakari, Thanks for the review. On Mon 03 Dec 2018 at 12:10, Sakari Ailus wrote: Hi Rui, On Thu, Nov 22, 2018 at 03:18:25PM +, Rui Miguel Silva wrote: Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2 interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile |1 + drivers/staging/media/imx/imx7-mipi-csis.c | 1135 2 files changed, 1136 insertions(+) create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 074f016d3519..d2d909a36239 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c new file mode 100644 index ..56963d0c2043 --- /dev/null +++ b/drivers/staging/media/imx/imx7-mipi-csis.c @@ -0,0 +1,1135 @@ +// SPDX-License-Identifier: GPL +/* + * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver + * + * Copyright (C) 2018 Linaro Ltd + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved. + * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "imx-media.h" + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Debug level (0-2)"); Could you rely on dynamic debug instead? Yeah, I will maybe add some debugfs entry. + +#define CSIS_DRIVER_NAME "imx7-mipi-csis" +#define CSIS_SUBDEV_NAME CSIS_DRIVER_NAME + +#define CSIS_PAD_SINK 0 +#define CSIS_PAD_SOURCE1 +#define CSIS_PADS_NUM 2 + +#define MIPI_CSIS_DEF_PIX_WIDTH640 +#define MIPI_CSIS_DEF_PIX_HEIGHT 480 + +/* Register map definition */ + +/* CSIS common control */ +#define MIPI_CSIS_CMN_CTRL 0x04 +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW BIT(16) +#define MIPI_CSIS_CMN_CTRL_INTER_MODE BIT(10) +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL BIT(2) +#define MIPI_CSIS_CMN_CTRL_RESET BIT(1) +#define MIPI_CSIS_CMN_CTRL_ENABLE BIT(0) + +#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET 8 +#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8) + +/* CSIS clock control */ +#define MIPI_CSIS_CLK_CTRL 0x08 +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x) ((x) << 28) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x) ((x) << 24) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x) ((x) << 20) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x) ((x) << 16) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK (0xf << 4) +#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0) + +/* CSIS Interrupt mask */ +#define MIPI_CSIS_INTMSK 0x10 +#define MIPI_CSIS_INTMSK_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTMSK_FRAME_START BIT(24) +#define MIPI_CSIS_INTMSK_FRAME_END BIT(20) +#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTMSK_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTMSK_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTMSK_ERR_OVER BIT(4) +#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTMSK_ERR_ECC BIT(2) +#define MIPI_CSIS_INTMSK_ERR_CRC BIT(1) +#define MIPI_CSIS_INTMSK_ERR_UNKNOWN BIT(0) + +/* CSIS Interrupt source */ +#define MIPI_CSIS_INTSRC 0x14 +#define MIPI_CSIS_INTSRC_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTSRC_EVEN BIT(30) +#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTSRC_ODD (0x3 << 28) +#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28) +#define MIPI_CSIS_INTSRC_FRAME_START BIT(24) +#define MIPI_CSIS_INTSRC_FRAME_END BIT(20) +#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTSRC_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTSRC_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTSRC_ERR_OVER BIT(4) +#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTSRC_ERR_ECC BIT(2) +#define MIPI_CSIS_INTSRC_ERR_CRC BIT(1) +#define MIPI_CSIS_INTSRC_ERR_UNKNOWN BIT(0) +#define MIPI_CSIS_INTSRC_ERRORS0xf + +/* D-PHY status control */ +#define MIPI_CSIS_DPHYSTATUS 0x20 +#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT BIT(8) +#define
Re: [PATCH 1/4] libdvbv5: do not adjust DVB time daylight saving
Em Sat, 7 Jul 2018 13:20:54 +0200
André Roth escreveu:
> This makes dvb_time available outside of EIT parsing, and
> struct tm to reflect the actual values received from DVB.
>
> Signed-off-by: André Roth
> ---
> lib/include/libdvbv5/descriptors.h | 11 +++
> lib/include/libdvbv5/eit.h | 10 --
> lib/libdvbv5/descriptors.c | 37 +
> lib/libdvbv5/tables/eit.c | 28
> 4 files changed, 48 insertions(+), 38 deletions(-)
>
> diff --git a/lib/include/libdvbv5/descriptors.h
> b/lib/include/libdvbv5/descriptors.h
> index cb21470c..31f4c73f 100644
> --- a/lib/include/libdvbv5/descriptors.h
> +++ b/lib/include/libdvbv5/descriptors.h
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * @brief Maximum size of a table session to be parsed
> @@ -159,6 +160,16 @@ uint32_t dvb_bcd(uint32_t bcd);
> void dvb_hexdump(struct dvb_v5_fe_parms *parms, const char *prefix,
>const unsigned char *buf, int len);
>
> +/**
> + * @brief Converts a DVB formatted timestamp into struct tm
> + * @ingroup dvb_table
> + *
> + * @param data event on DVB time format
> + * @param tm pointer to struct tm where the converted timestamp will
> + * be stored.
> + */
> +void dvb_time(const uint8_t data[5], struct tm *tm);
> +
> /**
> * @brief parse MPEG-TS descriptors
> * @ingroup dvb_table
> diff --git a/lib/include/libdvbv5/eit.h b/lib/include/libdvbv5/eit.h
> index 9129861e..5af266b1 100644
> --- a/lib/include/libdvbv5/eit.h
> +++ b/lib/include/libdvbv5/eit.h
> @@ -209,16 +209,6 @@ void dvb_table_eit_free(struct dvb_table_eit *table);
> void dvb_table_eit_print(struct dvb_v5_fe_parms *parms,
>struct dvb_table_eit *table);
>
> -/**
> - * @brief Converts a DVB EIT formatted timestamp into struct tm
> - * @ingroup dvb_table
> - *
> - * @param data event on DVB EIT time format
> - * @param tm pointer to struct tm where the converted timestamp will
> - * be stored.
> - */
> -void dvb_time(const uint8_t data[5], struct tm *tm);
> -
This seems to break the existing ABI.
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c
> index 0683dc1b..ccec503c 100644
> --- a/lib/libdvbv5/descriptors.c
> +++ b/lib/libdvbv5/descriptors.c
> @@ -56,6 +56,14 @@
> #include
> #include
>
> +#ifdef ENABLE_NLS
> +# include "gettext.h"
> +# include
> +# define _(string) dgettext(LIBDVBV5_DOMAIN, string)
> +#else
> +# define _(string) string
> +#endif
> +
> static void dvb_desc_init(uint8_t type, uint8_t length, struct dvb_desc
> *desc)
> {
> desc->type = type;
> @@ -1391,3 +1399,32 @@ void dvb_hexdump(struct dvb_v5_fe_parms *parms, const
> char *prefix, const unsign
> dvb_loginfo("%s%s %s %s", prefix, hex, spaces, ascii);
> }
> }
> +
> +void dvb_time(const uint8_t data[5], struct tm *tm)
> +{
> + /* ETSI EN 300 468 V1.4.1 */
> + int year, month, day, hour, min, sec;
> + int k = 0;
> + uint16_t mjd;
> +
> + mjd = *(uint16_t *) data;
> + hour = dvb_bcd(data[2]);
> + min = dvb_bcd(data[3]);
> + sec = dvb_bcd(data[4]);
> + year = ((mjd - 15078.2) / 365.25);
> + month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> + day = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> + if (month == 14 || month == 15) k = 1;
> + year += k;
> + month = month - 1 - k * 12;
> +
> + tm->tm_sec = sec;
> + tm->tm_min = min;
> + tm->tm_hour = hour;
> + tm->tm_mday = day;
> + tm->tm_mon = month - 1;
> + tm->tm_year = year;
> + tm->tm_isdst = -1; /* do not adjust */
It seems that the only real change here is that you replaced 1 by -1 here,
in order for the mktime() to not handle daylight saving time.
Why are you also moving this out of eit.c/eit.h?
> + mktime( tm );
> +}
> +
> diff --git a/lib/libdvbv5/tables/eit.c b/lib/libdvbv5/tables/eit.c
> index a6ba566a..799e4c9a 100644
> --- a/lib/libdvbv5/tables/eit.c
> +++ b/lib/libdvbv5/tables/eit.c
> @@ -154,34 +154,6 @@ void dvb_table_eit_print(struct dvb_v5_fe_parms *parms,
> struct dvb_table_eit *ei
> dvb_loginfo("|_ %d events", events);
> }
>
> -void dvb_time(const uint8_t data[5], struct tm *tm)
> -{
> - /* ETSI EN 300 468 V1.4.1 */
> - int year, month, day, hour, min, sec;
> - int k = 0;
> - uint16_t mjd;
> -
> - mjd = *(uint16_t *) data;
> - hour = dvb_bcd(data[2]);
> - min = dvb_bcd(data[3]);
> - sec = dvb_bcd(data[4]);
> - year = ((mjd - 15078.2) / 365.25);
> - month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> - day = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> - if (month == 14 || month == 15) k = 1;
> - year += k;
> - month = month - 1 - k * 12;
> -
> - tm->tm_sec = sec;
> - tm->tm_min = min;
> - tm->tm_hour = hour;
> - tm->tm_mday =
Re: [PATCH v5] media: imx: add mem2mem device
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
RE: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Laurent, > > Hi Rajmohan, > > > > On Tuesday, 4 December 2018 18:07:16 EET Mani, Rajmohan wrote: > > > >> On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > > > >>> On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > > > >> > > > >> [snip] > > > >> > > > > 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need > > > > to be enabled prior to the test. > > > > 2. Stream tests are not performed since it requires > > > > pre-configuration for each case. > > > > > > And that's a bit of an issue. I've tested the driver with a > > > small script based on media-ctl to configure links and yavta to > > > interface with the video nodes, and got the following oops: > > > > [snip] > > > > > The script can be found at > > > https://lists.libcamera.org/pipermail/libcamera-devel/2018-Nove > > > mb > > > e > > > r/40.html. > > > > > > I may be doing something wrong (and I probably am), but in any > > > case, the driver shouldn't crash. Could you please have a look ? > > > >>> > > > >>> It looks like the driver doesn't have the default state > > > >>> initialized correctly somewhere and it ends up using 0 as the > > > >>> divisor in some calculation? Something to fix indeed. > > > >> > > > >> That's probably the case. I'll trust Intel to fix that in v8 :-) > > > > > > > > Ack. > > > > > > Thanks for catching this. > > > I was able to reproduce this error and I see that error handling is > > > missing, leading to the panic. > > > > > > https://git.linuxtv.org/sailus/media_tree.git/tree/drivers/media > > > /pci/intel/ipu3/ipu3-css-params.c?h=ipu3-v7= > > > 19cee7329ca2d0156043cac6afcde535e93310af#n433 > > > > > > is where the -EINVAL is returned. > > > > > > Setting the return type as int for the following function and all > > > its callers to use the return value properly to error out, makes the > > > panic go away. > > > > I assume that I will still not be able to process frames through the > > pipe then, as I'll get an error :-) Could you tell me why the > > configuration is incorrect and how I can fix it ? > > > > :) > Let me look into this more and get back. > Thanks for your patience. I can see a couple of steps missing in the script below. (https://lists.libcamera.org/pipermail/libcamera-devel/2018-November/40.html) >From patch 02 of this v7 series "doc-rst: Add Intel IPU3 documentation", under >section "Configuring ImgU V4L2 subdev for image processing"... 1. The pipe mode needs to be configured for the V4L2 subdev. Also the pipe mode of the corresponding V4L2 subdev should be set as desired (e.g 0 for video mode or 1 for still mode) through the control id 0x009819a1 as below. e.g v4l2n -d /dev/v4l-subdev7 --ctrl=0x009819A1=1 2. ImgU pipeline needs to be configured for image processing as below. RAW bayer frames go through the following ISP pipeline HW blocks to have the processed image output to the DDR memory. RAW bayer frame -> Input Feeder -> Bayer Down Scaling (BDS) -> Geometric Distortion Correction (GDC) -> DDR The ImgU V4L2 subdev has to be configured with the supported resolutions in all the above HW blocks, for a given input resolution. For a given supported resolution for an input frame, the Input Feeder, Bayer Down Scaling and GDC blocks should be configured with the supported resolutions. This information can be obtained by looking at the following IPU3 ISP configuration table for ov5670 sensor. https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/master /baseboard-poppy/media-libs/cros-camera-hal-configs-poppy/files/gcss /graph_settings_ov5670.xml For the ov5670 example, for an input frame with a resolution of 2592x1944 (which is input to the ImgU subdev pad 0), the corresponding resolutions for input feeder, BDS and GDC are 2592x1944, 2592x1944 and 2560x1920 respectively. The following steps prepare the ImgU ISP pipeline for the image processing. 1. The ImgU V4L2 subdev data format should be set by using the VIDIOC_SUBDEV_S_FMT on pad 0, using the GDC width and height obtained above. 2. The ImgU V4L2 subdev cropping should be set by using the VIDIOC_SUBDEV_S_SELECTION on pad 0, with V4L2_SEL_TGT_CROP as the target, using the input feeder height and width. 3. The ImgU V4L2 subdev composing should be set by using the VIDIOC_SUBDEV_S_SELECTION on pad 0, with V4L2_SEL_TGT_COMPOSE as the target, using the BDS height and width. Once these 2 steps are done, the raw bayer frames can be input to the ImgU V4L2 subdev for processing. > Raj > > > > ipu3_css_osys_calc_frame_and_stripe_params() > > > > > > Will include the fix in v8. > > > > Thank you. > > > > > Thanks for catching this. > > > > You're welcome. > > > > -- > > Regards, > > > > Laurent Pinchart > > > >
Re: [PATCH] Add ir-rcmm-driver
The toggle flag is well handled with this code and at the kernel level;
This adds reliability.
Patrick.
On 04/12/2018 22:06, patrick9...@free.fr wrote:
We have so many decoders at the linux kernel level now. I'm not sure
of the best option.
Patrick.
On 04/12/2018 21:57, Sean Young wrote:
On Tue, Dec 04, 2018 at 09:20:25PM +0100, patrick9...@free.fr wrote:
From: Patrick LERDA
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 185
+
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 1 +
tools/include/uapi/linux/lirc.h| 1 +
8 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
We have a rc-mm decoder written in BPF, see:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/bpf_protocols/rc_mm.c
This is in v4l-utils 1.16 and higher.
Any reason to have it in the kernel rather than in BPF?
Sean
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..b7e08324b874 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,16 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..fc4058013234 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) +=
ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..b05063f0a552
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,185 @@
+/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+ *
+ * Copyright (C) 2016 by Patrick Lerda
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rc-core-priv.h"
+#include
+#include
+
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_0_NBITS 64
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3)
*/
+#define RCMM_PULSE_144 /* 16.6*(2+2/3)
*/
+#define RCMM_PULSE_261 /* 16.6*(3+2/3)
*/
+#define RCMM_PULSE_378 /* 16.6*(4+2/3)
*/
+#define RCMM_MODE_MASK 0x
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state
machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event
ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+
+ if (!(dev->enabled_protocols & RC_PROTO_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+
Re: [PATCH] Add ir-rcmm-driver
We have so many decoders at the linux kernel level now. I'm not sure of
the best option.
Patrick.
On 04/12/2018 21:57, Sean Young wrote:
On Tue, Dec 04, 2018 at 09:20:25PM +0100, patrick9...@free.fr wrote:
From: Patrick LERDA
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 185
+
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 1 +
tools/include/uapi/linux/lirc.h| 1 +
8 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
We have a rc-mm decoder written in BPF, see:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/bpf_protocols/rc_mm.c
This is in v4l-utils 1.16 and higher.
Any reason to have it in the kernel rather than in BPF?
Sean
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..b7e08324b874 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,16 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..fc4058013234 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..b05063f0a552
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,185 @@
+/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+ *
+ * Copyright (C) 2016 by Patrick Lerda
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rc-core-priv.h"
+#include
+#include
+
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_0_NBITS 64
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3)
*/
+#define RCMM_PULSE_144 /* 16.6*(2+2/3)
*/
+#define RCMM_PULSE_261 /* 16.6*(3+2/3)
*/
+#define RCMM_PULSE_378 /* 16.6*(4+2/3)
*/
+#define RCMM_MODE_MASK 0x
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state
machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+
+ if (!(dev->enabled_protocols & RC_PROTO_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+ adjust to the signal */
+ if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
+ break;
+
+ data->state
Re: [PATCH] Add ir-rcmm-driver
On Tue, Dec 04, 2018 at 09:20:25PM +0100, patrick9...@free.fr wrote:
> From: Patrick LERDA
>
> ---
> drivers/media/rc/Kconfig | 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-rcmm-decoder.c | 185 +
> drivers/media/rc/rc-core-priv.h| 5 +
> drivers/media/rc/rc-main.c | 3 +
> include/media/rc-map.h | 6 +-
> include/uapi/linux/lirc.h | 1 +
> tools/include/uapi/linux/lirc.h| 1 +
> 8 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
We have a rc-mm decoder written in BPF, see:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/bpf_protocols/rc_mm.c
This is in v4l-utils 1.16 and higher.
Any reason to have it in the kernel rather than in BPF?
Sean
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
> remote control and you would like to use it with a raw IR
> receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE
> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
> endif #RC_DECODERS
>
> menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
> obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
> obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
> obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..b05063f0a552
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "rc-core-priv.h"
> +#include
> +#include
> +
> +
> +#define RCMM_UNIT17 /* nanosecs */
> +#define RCMM_0_NBITS 64
> +#define RCMM_PREFIX_PULSE41 /* 16.6*2.5 */
> +#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK 0x
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev: the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = >raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */
> + if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
> + break;
>
Re: [PATCH 3/4] media: lmedm04: Move interrupt buffer to priv buffer.
On Thu, Nov 29, 2018 at 10:30:15PM +, Malcolm Priestley wrote:
> Interrupt is always present throught life time of
> there is no dma element move this buffer to private
> area of driver.
>
> Signed-off-by: Malcolm Priestley
> ---
> drivers/media/usb/dvb-usb-v2/lmedm04.c | 26 +-
> 1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
> b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> index 8fb53b83c914..7b1aaed259db 100644
> --- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
> +++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> @@ -134,7 +134,7 @@ struct lme2510_state {
> u8 stream_on;
> u8 pid_size;
> u8 pid_off;
> - void *buffer;
> + u8 int_buffer[128];
> struct urb *lme_urb;
> u8 usb_buffer[64];
> /* Frontend original calls */
> @@ -408,20 +408,14 @@ static int lme2510_int_read(struct dvb_usb_adapter
> *adap)
> if (lme_int->lme_urb == NULL)
> return -ENOMEM;
>
> - lme_int->buffer = usb_alloc_coherent(d->udev, 128, GFP_ATOMIC,
> - _int->lme_urb->transfer_dma);
> -
The buffer was allocated with usb_alloc_coherent, however now it is
allocated with kmalloc.
> - if (lme_int->buffer == NULL)
> - return -ENOMEM;
> -
> usb_fill_int_urb(lme_int->lme_urb,
> - d->udev,
> - usb_rcvintpipe(d->udev, 0xa),
> - lme_int->buffer,
> - 128,
> - lme2510_int_response,
> - adap,
> - 8);
> + d->udev,
> + usb_rcvintpipe(d->udev, 0xa),
> + lme_int->int_buffer,
> + sizeof(lme_int->int_buffer),
> + lme2510_int_response,
> + adap,
> + 8);
>
> /* Quirk of pipe reporting PIPE_BULK but behaves as interrupt */
> ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
On line 408:
lme_int->lme_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
This requires usb_alloc_coherent().
> @@ -1245,11 +1239,9 @@ static void lme2510_exit(struct dvb_usb_device *d)
> lme2510_kill_urb(>stream);
> }
>
> - if (st->lme_urb != NULL) {
> + if (st->lme_urb) {
> usb_kill_urb(st->lme_urb);
> usb_free_urb(st->lme_urb);
> - usb_free_coherent(d->udev, 128, st->buffer,
> - st->lme_urb->transfer_dma);
> info("Interrupt Service Stopped");
> }
> }
> --
> 2.19.1
Re: [PATCH 1/4] media: lmedm04: Add missing usb_free_urb to free, interrupt urb
On Thu, Nov 29, 2018 at 10:29:31PM +, Malcolm Priestley wrote:
> The interrupt urb is killed but never freed add the function
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Malcolm Priestley
> ---
> drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
> b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> index f109c04f05ae..8b405e131439 100644
> --- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
> +++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> @@ -1264,6 +1264,7 @@ static void *lme2510_exit_int(struct dvb_usb_device *d)
>
> if (st->lme_urb != NULL) {
> usb_kill_urb(st->lme_urb);
> + usb_free_urb(st->lme_urb);
Now st->lme_urb is a stale pointer.
> usb_free_coherent(d->udev, 128, st->buffer,
> st->lme_urb->transfer_dma);
And now you're following it.
> info("Interrupt Service Stopped");
> --
> 2.19.1
RE: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Tuesday, December 04, 2018 8:42 AM > To: Mani, Rajmohan > Cc: Tomasz Figa ; Zhi, Yong ; > Linux Media Mailing List ; Sakari Ailus > ; Mauro Carvalho Chehab > ; Hans Verkuil ; Zheng, Jian > Xu ; Hu, Jerry W ; > Toivonen, Tuukka ; Qiu, Tian Shu > ; Cao, Bingbu > Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset > > Hi Rajmohan, > > On Tuesday, 4 December 2018 18:07:16 EET Mani, Rajmohan wrote: > > >> On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > > >>> On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > >>>> On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > > >> > > >> [snip] > > >> > > >>>>> 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need > > >>>>> to be enabled prior to the test. > > >>>>> 2. Stream tests are not performed since it requires > > >>>>> pre-configuration for each case. > > >>>> > > >>>> And that's a bit of an issue. I've tested the driver with a small > > >>>> script based on media-ctl to configure links and yavta to > > >>>> interface with the video nodes, and got the following oops: > > [snip] > > > >>>> The script can be found at > > >>>> https://lists.libcamera.org/pipermail/libcamera-devel/2018-Novemb > > >>>> e > > >>>> r/40.html. > > >>>> > > >>>> I may be doing something wrong (and I probably am), but in any > > >>>> case, the driver shouldn't crash. Could you please have a look ? > > >>> > > >>> It looks like the driver doesn't have the default state > > >>> initialized correctly somewhere and it ends up using 0 as the > > >>> divisor in some calculation? Something to fix indeed. > > >> > > >> That's probably the case. I'll trust Intel to fix that in v8 :-) > > > > > > Ack. > > > > Thanks for catching this. > > I was able to reproduce this error and I see that error handling is > > missing, leading to the panic. > > > > https://git.linuxtv.org/sailus/media_tree.git/tree/drivers/media > > /pci/intel/ipu3/ipu3-css-params.c?h=ipu3-v7= > > 19cee7329ca2d0156043cac6afcde535e93310af#n433 > > > > is where the -EINVAL is returned. > > > > Setting the return type as int for the following function and all its > > callers to use the return value properly to error out, makes the panic > > go away. > > I assume that I will still not be able to process frames through the pipe > then, as > I'll get an error :-) Could you tell me why the configuration is incorrect > and how > I can fix it ? > :) Let me look into this more and get back. Thanks for your patience. Raj > > ipu3_css_osys_calc_frame_and_stripe_params() > > > > Will include the fix in v8. > > Thank you. > > > Thanks for catching this. > > You're welcome. > > -- > Regards, > > Laurent Pinchart > >
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Rajmohan, On Tuesday, 4 December 2018 18:07:16 EET Mani, Rajmohan wrote: > >> On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > >>> On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > >> > >> [snip] > >> > > 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to > > be enabled prior to the test. > > 2. Stream tests are not performed since it requires > > pre-configuration for each case. > > And that's a bit of an issue. I've tested the driver with a small > script based on media-ctl to configure links and yavta to > interface with the video nodes, and got the following oops: [snip] > The script can be found at > https://lists.libcamera.org/pipermail/libcamera-devel/2018-Novembe > r/40.html. > > I may be doing something wrong (and I probably am), but in any > case, the driver shouldn't crash. Could you please have a look ? > >>> > >>> It looks like the driver doesn't have the default state initialized > >>> correctly somewhere and it ends up using 0 as the divisor in some > >>> calculation? Something to fix indeed. > >> > >> That's probably the case. I'll trust Intel to fix that in v8 :-) > > > > Ack. > > Thanks for catching this. > I was able to reproduce this error and I see that error handling > is missing, leading to the panic. > > https://git.linuxtv.org/sailus/media_tree.git/tree/drivers/media > /pci/intel/ipu3/ipu3-css-params.c?h=ipu3-v7= > 19cee7329ca2d0156043cac6afcde535e93310af#n433 > > is where the -EINVAL is returned. > > Setting the return type as int for the following function and all > its callers to use the return value properly to error out, makes > the panic go away. I assume that I will still not be able to process frames through the pipe then, as I'll get an error :-) Could you tell me why the configuration is incorrect and how I can fix it ? > ipu3_css_osys_calc_frame_and_stripe_params() > > Will include the fix in v8. Thank you. > Thanks for catching this. You're welcome. -- Regards, Laurent Pinchart
RE: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Laurent, Tomasz, > > Thanks for the reviews. > > > Subject: Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset > > > > Hi Tomasz, > > > > On Thursday, 29 November 2018 21:51:32 EET Tomasz Figa wrote: > > > On Thu, Nov 29, 2018 at 6:43 AM Laurent Pinchart wrote: > > > > On Tuesday, 30 October 2018 00:22:54 EET Yong Zhi wrote: > > > > [snip] > > > > > >> 1. Link pad flag of video nodes (i.e. ipu3-imgu 0 output) need to > > > >> be enabled prior to the test. > > > >> 2. Stream tests are not performed since it requires > > > >> pre-configuration for each case. > > > > > > > > And that's a bit of an issue. I've tested the driver with a small > > > > script based on media-ctl to configure links and yavta to > > > > interface with the video nodes, and got the following oops: > > > > > > > > [ 136.927788] divide error: [#1] PREEMPT SMP PTI [ > > > > 136.927801] CPU: 2 PID: 2069 Comm: yavta Not tainted 4.20.0-rc1+ > > > > #9 [ 136.927806] Hardware name: HP Soraka/Soraka, BIOS > > > > 08/30/2018 [ 136.927820] RIP: 0010:ipu3_css_osys_calc+0xc54/0xe14 > > > > [ipu3_imgu] [ 136.927825] Code: 89 44 24 28 42 8b 44 86 6c f7 54 > > > > 24 04 81 64 24 28 > > > > 00 fd ff ff 81 64 24 04 00 03 00 00 8d 44 03 ff 81 44 24 28 80 03 > > > > 00 > > > > 00 99 fb 0f af c3 bb 20 00 00 00 99 f7 fb 8b 5c 24 40 83 fd > > > > 01 > > > > 19 d2 [ 136.927830] RSP: 0018:9af2c0b837c8 EFLAGS: 00010202 [ > > > > 136.927835] RAX: RBX: RCX: > > > > 9af2c3e353c0 > > > > [ 136.927839] RDX: RSI: 9af2c0b838e0 RDI: > > > > 9af2c3e353c0 > > > > [ 136.927843] RBP: 0001 R08: R09: > > > > 9af2c0b83880 > > > > [ 136.927846] R10: 9af2c3e353c0 R11: 9af2c3e357c0 R12: > > > > 03a0 > > > > [ 136.927849] R13: 00025a0a R14: R15: > > > > > > > > [ 136.927854] FS: 7f1eca167700() > > > > GS:8c19fab0() > > > > knlGS: > > > > > > > > [ 136.927858] CS: 0010 DS: ES: CR0: 80050033 [ > > > > 136.927862] CR2: 7f1ec776c000 CR3: 0001312a4003 CR4: > > > > 003606e0 > > > > [ 136.927865] Call Trace: > > > > [ 136.927884] ? __accumulate_pelt_segments+0x29/0x3a > > > > [ 136.927892] ? __switch_to_asm+0x40/0x70 [ 136.927899] ? > > > > alloc_vmap_area+0x78/0x2f6 [ 136.927903] ? > > > > __switch_to_asm+0x40/0x70 [ 136.927907] ? > > > > __switch_to_asm+0x34/0x70 [ 136.927911] ? > > > > __switch_to_asm+0x40/0x70 [ 136.927915] ? > > > > __switch_to_asm+0x34/0x70 [ 136.927923] ? > > > > __inc_numa_state+0x28/0x70 [ 136.927929] ? > > > > preempt_latency_start+0x1e/0x3d [ 136.927936] ? > > > > get_page_from_freelist+0x821/0xb62 > > > > [ 136.927943] ? slab_pre_alloc_hook+0x12/0x3b [ 136.927948] ? > > > > kmem_cache_alloc_node_trace+0xf6/0x108 > > > > [ 136.927954] ? alloc_vmap_area+0x78/0x2f6 > > > > > > Is it just me or the backtrace above doesn't seem to make sense? I > > > don't see any allocations inside ipu3_css_cfg_acc(). > > > > I suppose that's why it's prefixed with '?' :-) > > > > > > [ 136.927965] ipu3_css_cfg_acc+0xa0/0x1b5f [ipu3_imgu] [ > > > > 136.927981] ipu3_css_set_parameters+0x286/0x6e7 [ipu3_imgu] [ > > > > 136.927995] ipu3_css_start_streaming+0x1230/0x130a [ipu3_imgu] [ > > > > 136.928010] imgu_s_stream+0x104/0x2f7 [ipu3_imgu] [ 136.928022] > > > > ipu3_vb2_start_streaming+0x168/0x1bd [ipu3_imgu] [ 136.928034] > > > > vb2_start_streaming+0x6c/0xf2 [videobuf2_common] [ 136.928044] > > > > vb2_core_streamon+0xcf/0x109 [videobuf2_common] [ 136.928061] > > > > __video_do_ioctl+0x239/0x388 [videodev] [ 136.928081] > > > > video_usercopy+0x25d/0x47a [videodev] [ 136.928097] ? > > > > copy_overflow+0x14/0x14 [videodev] [ 136.928115] > > > > v4l2_ioctl+0x4d/0x58 [videodev] [ 136.928123] > > > > vfs_ioctl+0x1b/0x28 [ 136.928130] do_vfs_ioctl+0x4de/0x566 [ > > > > 136.928139] > > > > ksys_ioctl+0x50/0x70 [ 136.928146] __x64_sys_ioctl+0x16/0x19 [ > > > > 136.928152] do_sys
Re: [PATCH v2 1/1] media: Use common test pattern menu entries
Em Tue, 4 Dec 2018 15:40:42 +0200
Sakari Ailus escreveu:
> While the test pattern menu itself is not standardised, many devices
> support the same test patterns. Aligning the menu entries helps the user
> space to use the interface, and adding macros for the menu entry strings
> helps to keep them aligned.
>
> Signed-off-by: Sakari Ailus
> ---
> since v1:
>
> - Fix indentation of menu strings
> - Remove "8" from the macro names
>
> drivers/media/i2c/imx258.c | 10 +-
> drivers/media/i2c/imx319.c | 10 +-
> drivers/media/i2c/imx355.c | 10 +-
> drivers/media/i2c/ov2640.c | 4 ++--
> drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> include/uapi/linux/v4l2-controls.h | 5 +
> 6 files changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index f86ae18bc104..df5f016cebd9 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
> };
>
> static const char * const imx258_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* Configurations for supported link frequencies */
> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> index 17c2e4b41221..d9d4176b9d37 100644
> --- a/drivers/media/i2c/imx319.c
> +++ b/drivers/media/i2c/imx319.c
> @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] =
> {
> };
>
> static const char * const imx319_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index bed293b60e50..99138a291cb8 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> };
>
> static const char * const imx355_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 5d2d6735cc78..65058d9a5d51 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> }
>
> static const char * const ov2640_test_pattern_menu[] = {
> - "Disabled",
> - "Eight Vertical Colour Bars",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> };
>
> /*
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 58a45c353e27..5c9bcc9438ec 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
> smiapp_sensor *sensor)
> }
>
> static const char * const smiapp_test_patterns[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 998983a6e6b7..acb2a57fa5d6 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
> #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 1)
> #define V4L2_CID_PIXEL_RATE (V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 2)
> #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> +#define
Re: [PATCH 1/1] v4l uapi: Make "Vertical Colour Bars" menu item a little more generic
Em Tue, 4 Dec 2018 12:32:32 -0200
Mauro Carvalho Chehab escreveu:
> Em Tue, 4 Dec 2018 15:45:06 +0200
> Sakari Ailus escreveu:
>
> > The test pattern could contain a different number of colour bars than
> > eight, make the entry more useful by removing "Eight " from the name.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > include/uapi/linux/v4l2-controls.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index acb2a57fa5d6..88f2759c2ce4 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -1016,7 +1016,7 @@ enum v4l2_jpeg_chroma_subsampling {
> > #define V4L2_CID_TEST_PATTERN
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> > #define V4L2_TEST_PATTERN_DISABLED "Disabled"
> > #define V4L2_TEST_PATTERN_SOLID_COLOUR "Solid Colour"
> > -#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
> > +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Vertical Colour Bars"
>
> No, we can't do that. This is on an uAPI file.
>
> We should, instead, create another #define for non-eight vertical
> color bars.
>
> Before you say, yeah, I agree that we messed this one, as the defined
> name doesn't mention 8 bars...
>
> I would, instead, do something like:
>
> -#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_N_COLOUR_BARS "Vertical Colour Bars"
> +
> + /* Kept for backward-compatibility */
> +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS
> V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS
>
> And, of course, update the documentation accordingly.
Please ignore this comment. I didn't realize that those definitions
don't exist yet at the uAPI file, and that this is a follow up for
another patch:
Subject: [PATCH v2 1/1] media: Use common test pattern menu entries
Next time, please put them into a patch series, as it makes easier for
reviewers.
Thanks,
Mauro
Re: [PATCH 1/1] v4l uapi: Make "Vertical Colour Bars" menu item a little more generic
Em Tue, 4 Dec 2018 15:45:06 +0200
Sakari Ailus escreveu:
> The test pattern could contain a different number of colour bars than
> eight, make the entry more useful by removing "Eight " from the name.
>
> Signed-off-by: Sakari Ailus
> ---
> include/uapi/linux/v4l2-controls.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index acb2a57fa5d6..88f2759c2ce4 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -1016,7 +1016,7 @@ enum v4l2_jpeg_chroma_subsampling {
> #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> #define V4L2_TEST_PATTERN_DISABLED "Disabled"
> #define V4L2_TEST_PATTERN_SOLID_COLOUR "Solid Colour"
> -#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Vertical Colour Bars"
No, we can't do that. This is on an uAPI file.
We should, instead, create another #define for non-eight vertical
color bars.
Before you say, yeah, I agree that we messed this one, as the defined
name doesn't mention 8 bars...
I would, instead, do something like:
-#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
+#define V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS "Eight Vertical Colour Bars"
+#define V4L2_TEST_PATTERN_VERT_N_COLOUR_BARS "Vertical Colour Bars"
+
+ /* Kept for backward-compatibility */
+#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS
V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS
And, of course, update the documentation accordingly.
> #define V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY "Colour Bars With
> Fade to Grey"
> #define V4L2_TEST_PATTERN_PN9"Pseudorandom Sequence
> (PN9)"
> #define V4L2_CID_DEINTERLACING_MODE (V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 4)
Thanks,
Mauro
Re: [PATCH 1/1] media: Use common test pattern menu entries
On Tue, Nov 27, 2018 at 07:19:52PM +0800, Bingbu Cao wrote:
>
> On 11/27/2018 05:33 PM, Sakari Ailus wrote:
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 998983a6e6b7..a74ff6f1ac88 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
> > #define V4L2_CID_LINK_FREQ
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 1)
> > #define V4L2_CID_PIXEL_RATE
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 2)
> > #define V4L2_CID_TEST_PATTERN
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> > +#define V4L2_TEST_PATTERN_DISABLED "Disabled"
> > +#define V4L2_TEST_PATTERN_SOLID_COLOUR "Solid Colour"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS "Eight Vertical
> > Colour Bars"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY "Colour Bars
> > With Fade to Grey"
> > +#define V4L2_TEST_PATTERN_PN9 "Pseudorandom Sequence
> > (PN9)"
> More padding here for alignment?
Fixed in v2.
--
Sakari Ailus
Re: [PATCH v2] v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields
On Tue, Nov 27, 2018 at 07:07:56PM -0300, Ezequiel Garcia wrote:
> Make the core set the reserved fields to zero in
> vv4l2_pix_format_mplane.4l2_plane_pix_format,
> for _MPLANE queue types.
>
> Moving this to the core avoids having to do so in each
> and every driver.
>
> Suggested-by: Tomasz Figa
> Signed-off-by: Ezequiel Garcia
> --
> v2:
> * Drop unneeded clear in g_fmt.
> The sturct was already being cleared here.
> * Only zero plane_fmt reserved fields.
> * Use CLEAR_FIELD_MACRO.
>
> drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index e384142d2826..2506b602481f 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1512,6 +1512,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> struct v4l2_format *p = arg;
> struct video_device *vfd = video_devdata(file);
> int ret = check_fmt(file, p->type);
> + int i;
unsigned int; same below.
With that,
Acked-by: Sakari Ailus
>
> if (ret)
> return ret;
> @@ -1536,6 +1537,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + CLEAR_AFTER_FIELD(p,
> fmt.pix_mp.plane_fmt[i].bytesperline);
> return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
> case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
> @@ -1564,6 +1567,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + CLEAR_AFTER_FIELD(p,
> fmt.pix_mp.plane_fmt[i].bytesperline);
> return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
> if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
> @@ -1604,6 +1609,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
> {
> struct v4l2_format *p = arg;
> int ret = check_fmt(file, p->type);
> + int i;
>
> if (ret)
> return ret;
> @@ -1623,6 +1629,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_try_fmt_vid_cap_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + CLEAR_AFTER_FIELD(p,
> fmt.pix_mp.plane_fmt[i].bytesperline);
> return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
> case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> if (unlikely(!ops->vidioc_try_fmt_vid_overlay))
> @@ -1651,6 +1659,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
> if (unlikely(!ops->vidioc_try_fmt_vid_out_mplane))
> break;
> CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> + CLEAR_AFTER_FIELD(p,
> fmt.pix_mp.plane_fmt[i].bytesperline);
> return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
> if (unlikely(!ops->vidioc_try_fmt_vid_out_overlay))
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
Re: [PATCH v6 09/10] media: uvcvideo: Rename uvc_{un,}init_video()
Hi Kieran,
Thank you for the patch.
On Friday, 9 November 2018 19:15:42 EET Kieran Bingham wrote:
> Hi Laurent,
>
> I'm sorry - I didn't update the commit message on this one.
>
> On 09/11/2018 17:05, Kieran Bingham wrote:
> > We have both uvc_init_video() and uvc_video_init() calls which can be
> > quite confusing to determine the process for each. Now that video
> > uvc_video_enable() has been renamed to uvc_video_start_streaming(),
> > adapt these calls to suit the new flow.
> >
> > Rename uvc_init_video() to uvc_video_start() and uvc_uninit_video() to
> > uvc_video_stop().
>
> Could you s/uvc_video_start/uvc_video_start_transfer/ and
> s/uvc_video_stop/uvc_video_stop_transfer/ when applying please?
>
> (Assuming you get to apply and don't find something else :D)
Will do.
Reviewed-by: Laurent Pinchart
> > Signed-off-by: Kieran Bingham
> >
> > ---
> >
> > v6:
> > - Append _transfer to {_stop,_start}
> >
> > drivers/media/usb/uvc/uvc_video.c | 20 +++-
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > b/drivers/media/usb/uvc/uvc_video.c index cd67506dc696..a81012c65280
> > 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -1641,7 +1641,8 @@ static int uvc_alloc_urb_buffers(struct
> > uvc_streaming *stream,
> > /*
> > * Uninitialize isochronous/bulk URBs and free transfer buffers.
> > */
> > -static void uvc_uninit_video(struct uvc_streaming *stream, int
> > free_buffers)
> > +static void uvc_video_stop_transfer(struct uvc_streaming *stream,
> > + int free_buffers)
> > {
> > struct uvc_urb *uvc_urb;
> >
> > @@ -1718,7 +1719,7 @@ static int uvc_init_video_isoc(struct uvc_streaming
> > *stream,
> >
> > urb = usb_alloc_urb(npackets, gfp_flags);
> > if (urb == NULL) {
> > - uvc_uninit_video(stream, 1);
> > + uvc_video_stop_transfer(stream, 1);
> > return -ENOMEM;
> > }
> >
> > @@ -1786,7 +1787,7 @@ static int uvc_init_video_bulk(struct uvc_streaming
> > *stream,
> >
> > urb = usb_alloc_urb(0, gfp_flags);
> > if (urb == NULL) {
> > - uvc_uninit_video(stream, 1);
> > + uvc_video_stop_transfer(stream, 1);
> > return -ENOMEM;
> > }
> >
> > @@ -1806,7 +1807,8 @@ static int uvc_init_video_bulk(struct uvc_streaming
> > *stream,
> > /*
> > * Initialize isochronous/bulk URBs and allocate transfer buffers.
> > */
> > -static int uvc_init_video(struct uvc_streaming *stream, gfp_t gfp_flags)
> > +static int uvc_video_start_transfer(struct uvc_streaming *stream,
> > + gfp_t gfp_flags)
> {
> > struct usb_interface *intf = stream->intf;
> > struct usb_host_endpoint *ep;
> > @@ -1894,7 +1896,7 @@ static int uvc_init_video(struct uvc_streaming
> > *stream, gfp_t gfp_flags)
> >
> > if (ret < 0) {
> > uvc_printk(KERN_ERR, "Failed to submit URB %u "
> > "(%d).\n", i, ret);
> > - uvc_uninit_video(stream, 1);
> > + uvc_video_stop_transfer(stream, 1);
> > return ret;
> }
> > }
> > @@ -1925,7 +1927,7 @@ int uvc_video_suspend(struct uvc_streaming *stream)
> > return 0;
> >
> > stream->frozen = 1;
> > - uvc_uninit_video(stream, 0);
> > + uvc_video_stop_transfer(stream, 0);
> > usb_set_interface(stream->dev->udev, stream->intfnum, 0);
> > return 0;
> > }
> > @@ -1961,7 +1963,7 @@ int uvc_video_resume(struct uvc_streaming *stream,
> > int reset)
> >
> > if (ret < 0)
> > return ret;
> >
> > - return uvc_init_video(stream, GFP_NOIO);
> > + return uvc_video_start_transfer(stream, GFP_NOIO);
> > }
> >
> > /* --
> > @@ -2089,7 +2091,7 @@ int uvc_video_start_streaming(struct uvc_streaming
> > *stream)
> >
> > if (ret < 0)
> > goto error_commit;
> >
> > - ret = uvc_init_video(stream, GFP_KERNEL);
> > + ret = uvc_video_start_transfer(stream, GFP_KERNEL);
> > if (ret < 0)
> > goto error_video;
> >
> > @@ -2105,7 +2107,7 @@ int uvc_video_start_streaming(struct uvc_streaming
> > *stream)
> >
> > int uvc_video_stop_streaming(struct uvc_streaming *stream)
> > {
> > - uvc_uninit_video(stream, 1);
> > + uvc_video_stop_transfer(stream, 1);
> >
> > if (stream->intf->num_altsetting > 1) {
> > usb_set_interface(stream->dev->udev,
> > stream->intfnum, 0);
--
Regards,
Laurent Pinchart
Re: [PATCH v6 08/10] media: uvcvideo: Split uvc_video_enable into two
Hi Kieran,
On Sunday, 11 November 2018 00:02:39 EET Kieran Bingham wrote:
> Hi Laurent,
>
> I see that you made changes to this patch before accepting it last time.
>
> I'm afraid I haven't made those changes here, so please just cherry-pick
> your previous incarnation. There are no changes here from me between v5,
> and v6.
OK, I will do so. The two changes I made are both in
uvc_video_stop_streaming(), turning the function into a void function and
avoiding an unnecessarily line wrap.
> On 09/11/2018 17:05, Kieran Bingham wrote:
> > uvc_video_enable() is used both to start and stop the video stream
> > object, however the single function entry point shares no code between
> > the two operations.
> >
> > Split the function into two distinct calls, and rename to
> > uvc_video_start_streaming() and uvc_video_stop_streaming() as
> > appropriate.
> >
> > Signed-off-by: Kieran Bingham
> > ---
> >
> > drivers/media/usb/uvc/uvc_queue.c | 4 +-
> > drivers/media/usb/uvc/uvc_video.c | 56 +++-
> > drivers/media/usb/uvc/uvcvideo.h | 3 +-
> > 3 files changed, 31 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_queue.c
> > b/drivers/media/usb/uvc/uvc_queue.c index 2752e386f1e8..d09b0c882938
> > 100644
> > --- a/drivers/media/usb/uvc/uvc_queue.c
> > +++ b/drivers/media/usb/uvc/uvc_queue.c
> > @@ -176,7 +176,7 @@ static int uvc_start_streaming(struct vb2_queue *vq,
> > unsigned int count)>
> > queue->buf_used = 0;
> >
> > - ret = uvc_video_enable(stream, 1);
> > + ret = uvc_video_start_streaming(stream);
> >
> > if (ret == 0)
> >
> > return 0;
> >
> > @@ -194,7 +194,7 @@ static void uvc_stop_streaming(struct vb2_queue *vq)
> >
> > lockdep_assert_irqs_enabled();
> >
> > if (vq->type != V4L2_BUF_TYPE_META_CAPTURE)
> >
> > - uvc_video_enable(uvc_queue_to_stream(queue), 0);
> > + uvc_video_stop_streaming(uvc_queue_to_stream(queue));
> >
> > spin_lock_irq(>irqlock);
> > uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > b/drivers/media/usb/uvc/uvc_video.c index e19bdf089cc4..cd67506dc696
> > 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -2076,38 +2076,10 @@ int uvc_video_init(struct uvc_streaming *stream)
> >
> > return 0;
> >
> > }
> >
> > -/*
> > - * Enable or disable the video stream.
> > - */
> > -int uvc_video_enable(struct uvc_streaming *stream, int enable)
> > +int uvc_video_start_streaming(struct uvc_streaming *stream)
> >
> > {
> >
> > int ret;
> >
> > - if (!enable) {
> > - uvc_uninit_video(stream, 1);
> > - if (stream->intf->num_altsetting > 1) {
> > - usb_set_interface(stream->dev->udev,
> > - stream->intfnum, 0);
> > - } else {
> > - /* UVC doesn't specify how to inform a bulk-based device
> > -* when the video stream is stopped. Windows sends a
> > -* CLEAR_FEATURE(HALT) request to the video streaming
> > -* bulk endpoint, mimic the same behaviour.
> > -*/
> > - unsigned int epnum = stream->header.bEndpointAddress
> > - & USB_ENDPOINT_NUMBER_MASK;
> > - unsigned int dir = stream->header.bEndpointAddress
> > -& USB_ENDPOINT_DIR_MASK;
> > - unsigned int pipe;
> > -
> > - pipe = usb_sndbulkpipe(stream->dev->udev, epnum) | dir;
> > - usb_clear_halt(stream->dev->udev, pipe);
> > - }
> > -
> > - uvc_video_clock_cleanup(stream);
> > - return 0;
> > - }
> > -
> >
> > ret = uvc_video_clock_init(stream);
> > if (ret < 0)
> >
> > return ret;
> >
> > @@ -2130,3 +2102,29 @@ int uvc_video_enable(struct uvc_streaming *stream,
> > int enable)>
> > return ret;
> >
> > }
> >
> > +
> > +int uvc_video_stop_streaming(struct uvc_streaming *stream)
> > +{
> > + uvc_uninit_video(stream, 1);
> > + if (stream->intf->num_altsetting > 1) {
> > + usb_set_interface(stream->dev->udev,
> > + stream->intfnum, 0);
> > + } else {
> > + /* UVC doesn't specify how to inform a bulk-based device
> > +* when the video stream is stopped. Windows sends a
> > +* CLEAR_FEATURE(HALT) request to the video streaming
> > +* bulk endpoint, mimic the same behaviour.
> > +*/
> > + unsigned int epnum = stream->header.bEndpointAddress
> > + & USB_ENDPOINT_NUMBER_MASK;
> > + unsigned int dir = stream->header.bEndpointAddress
> > +& USB_ENDPOINT_DIR_MASK;
> > + unsigned int pipe;
> > +
> >
Re: [PATCH v6 07/10] media: uvcvideo: Move decode processing to process context
t;,
> +ret);
> +}
> +
> +static void uvc_video_decode_data(struct uvc_urb *uvc_urb,
> struct uvc_buffer *buf, const u8 *data, int len)
> {
> - unsigned int maxlen, nbytes;
> - void *mem;
> + unsigned int active_op = uvc_urb->async_operations;
> + struct uvc_copy_op *op = _urb->copy_operations[active_op];
> + unsigned int maxlen;
>
> if (len <= 0)
> return;
>
> - /* Copy the video data to the buffer. */
> maxlen = buf->length - buf->bytesused;
> - mem = buf->mem + buf->bytesused;
> - nbytes = min((unsigned int)len, maxlen);
> - memcpy(mem, data, nbytes);
> - buf->bytesused += nbytes;
> +
> + /* Take a buffer reference for async work. */
> + kref_get(>ref);
> +
> + op->buf = buf;
> + op->src = data;
> + op->dst = buf->mem + buf->bytesused;
> + op->len = min_t(unsigned int, len, maxlen);
> +
> + buf->bytesused += op->len;
>
> /* Complete the current frame if the buffer size was exceeded. */
> if (len > maxlen) {
> @@ -1116,6 +1149,8 @@ static void uvc_video_decode_data(struct uvc_streaming
> *stream, buf->error = 1;
> buf->state = UVC_BUF_STATE_READY;
> }
> +
> + uvc_urb->async_operations++;
> }
>
> static void uvc_video_decode_end(struct uvc_streaming *stream,
> @@ -1324,7 +1359,7 @@ static void uvc_video_decode_isoc(struct uvc_urb
> *uvc_urb, uvc_video_decode_meta(stream, meta_buf, mem, ret);
>
> /* Decode the payload data. */
> - uvc_video_decode_data(stream, buf, mem + ret,
> + uvc_video_decode_data(uvc_urb, buf, mem + ret,
> urb->iso_frame_desc[i].actual_length - ret);
>
> /* Process the header again. */
> @@ -1384,9 +1419,9 @@ static void uvc_video_decode_bulk(struct uvc_urb
> *uvc_urb, * sure buf is never dereferenced if NULL.
>*/
>
> - /* Process video data. */
> + /* Prepare video data for processing. */
> if (!stream->bulk.skip_payload && buf != NULL)
> - uvc_video_decode_data(stream, buf, mem, len);
> + uvc_video_decode_data(uvc_urb, buf, mem, len);
>
> /* Detect the payload end by a URB smaller than the maximum size (or
>* a payload size equal to the maximum) and process the header again.
> @@ -1472,7 +1507,7 @@ static void uvc_video_complete(struct urb *urb)
> uvc_printk(KERN_WARNING, "Non-zero status (%d) in video "
> "completion handler.\n", urb->status);
> /* fall through */
> - case -ENOENT: /* usb_kill_urb() called. */
> + case -ENOENT: /* usb_poison_urb() called. */
> if (stream->frozen)
> return;
> /* fall through */
> @@ -1494,12 +1529,26 @@ static void uvc_video_complete(struct urb *urb)
> spin_unlock_irqrestore(>irqlock, flags);
> }
>
> + /* Re-initialise the URB async work. */
> + uvc_urb->async_operations = 0;
> +
> + /*
> + * Process the URB headers, and optionally queue expensive memcpy tasks
> + * to be deferred to a work queue.
> + */
> stream->decode(uvc_urb, buf, buf_meta);
>
> - if ((ret = usb_submit_urb(urb, GFP_ATOMIC)) < 0) {
> - uvc_printk(KERN_ERR, "Failed to resubmit video URB (%d).\n",
> - ret);
> + /* If no async work is needed, resubmit the URB immediately. */
> + if (!uvc_urb->async_operations) {
> + ret = usb_submit_urb(uvc_urb->urb, GFP_ATOMIC);
> + if (ret < 0)
> + uvc_printk(KERN_ERR,
> +"Failed to resubmit video URB (%d).\n",
> +ret);
> + return;
> }
> +
> + queue_work(stream->async_wq, _urb->work);
> }
>
> /*
> @@ -1594,20 +1643,22 @@ static int uvc_alloc_urb_buffers(struct
> uvc_streaming *stream, */
> static void uvc_uninit_video(struct uvc_streaming *stream, int
> free_buffers) {
> - struct urb *urb;
> - unsigned int i;
> + struct uvc_urb *uvc_urb;
>
> uvc_video_stats_stop(stream);
>
> - for (i = 0; i < UVC_URBS; ++i) {
> - struct uvc_urb *uvc_urb = >uvc_urb[i];
> + /*
> + * We must poison the URBs rather than kill them to ensure that even
> + * after the completion handler returns, any asynchronous workqueues
> + * will be prevented from resubmitti
Re: [PATCH v6 06/10] media: uvcvideo: Abstract streaming object lifetime
Hi Kieran,
Thank you for the patch.
On Friday, 9 November 2018 19:05:29 EET Kieran Bingham wrote:
> The streaming object is a key part of handling the UVC device. Although
> not critical, we are currently missing a call to destroy the mutex on
> clean up paths, and we are due to extend the objects complexity in the
> near future.
>
> Facilitate easy management of a stream object by creating a pair of
> functions to handle creating and destroying the allocation. The new
> uvc_stream_delete() function also performs the missing mutex_destroy()
> operation.
>
> Previously a failed streaming object allocation would cause
> uvc_parse_streaming() to return -EINVAL, which is inappropriate. If the
> constructor failes, we will instead return -ENOMEM.
>
> While we're here, fix the trivial spelling error in the function banner
> of uvc_delete().
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/usb/uvc/uvc_driver.c | 54 +--
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 67bd58c6f397..afb44d1c9d04
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -396,6 +396,39 @@ static struct uvc_streaming *uvc_stream_by_id(struct
> uvc_device *dev, int id) }
>
> /*
> + * Streaming Object Management
> + */
> +
> +static void uvc_stream_delete(struct uvc_streaming *stream)
> +{
> + mutex_destroy(>mutex);
> +
> + usb_put_intf(stream->intf);
> +
> + kfree(stream->format);
> + kfree(stream->header.bmaControls);
> + kfree(stream);
> +}
> +
> +static struct uvc_streaming *uvc_stream_new(struct uvc_device *dev,
> + struct usb_interface *intf)
> +{
> + struct uvc_streaming *stream;
> +
> + stream = kzalloc(sizeof(*stream), GFP_KERNEL);
> + if (stream == NULL)
> + return NULL;
> +
> + mutex_init(>mutex);
> +
> + stream->dev = dev;
> + stream->intf = usb_get_intf(intf);
> + stream->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
> +
> + return stream;
> +}
> +
> +/*
> * Descriptors parsing
> */
>
> @@ -687,17 +720,12 @@ static int uvc_parse_streaming(struct uvc_device *dev,
> return -EINVAL;
> }
>
> - streaming = kzalloc(sizeof(*streaming), GFP_KERNEL);
> + streaming = uvc_stream_new(dev, intf);
> if (streaming == NULL) {
> usb_driver_release_interface(_driver.driver, intf);
> - return -EINVAL;
> + return -ENOMEM;
> }
>
> - mutex_init(>mutex);
> - streaming->dev = dev;
> - streaming->intf = usb_get_intf(intf);
> - streaming->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
> -
> /* The Pico iMage webcam has its class-specific interface descriptors
>* after the endpoint descriptors.
>*/
> @@ -904,10 +932,7 @@ static int uvc_parse_streaming(struct uvc_device *dev,
>
> error:
> usb_driver_release_interface(_driver.driver, intf);
> - usb_put_intf(intf);
> - kfree(streaming->format);
> - kfree(streaming->header.bmaControls);
> - kfree(streaming);
> + uvc_stream_delete(streaming);
> return ret;
> }
>
> @@ -1815,7 +1840,7 @@ static int uvc_scan_device(struct uvc_device *dev)
> * is released.
> *
> * As this function is called after or during disconnect(), all URBs have
> - * already been canceled by the USB core. There is no need to kill the
> + * already been cancelled by the USB core. There is no need to kill the
> * interrupt URB manually.
> */
> static void uvc_delete(struct kref *kref)
> @@ -1853,10 +1878,7 @@ static void uvc_delete(struct kref *kref)
> streaming = list_entry(p, struct uvc_streaming, list);
> usb_driver_release_interface(_driver.driver,
> streaming->intf);
> - usb_put_intf(streaming->intf);
> - kfree(streaming->format);
> - kfree(streaming->header.bmaControls);
> - kfree(streaming);
> + uvc_stream_delete(streaming);
> }
>
> kfree(dev);
--
Regards,
Laurent Pinchart
Re: [PATCH dvb v1 3/4] media: dvb-usb-v2: remove __func__ from dev_dbg()
Hi Sean,
Thanks for taking time to review those patches.
On Tue, Nov 27, 2018 at 10:32:44AM +, Sean Young wrote:
> On Tue, Oct 30, 2018 at 05:14:50PM +0100, Victor Toso wrote:
> > From: Victor Toso
> >
> > As dynamic debug can be instructed to add the function name to the
> > debug output using +f switch, we can remove __func__ from all
> > dev_dbg() calls. If not, a user that sets +f in dynamic debug would
> > get duplicated function name.
> >
> > Signed-off-by: Victor Toso
> > ---
> > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 105 ++--
> > drivers/media/usb/dvb-usb-v2/dvb_usb_urb.c | 7 +-
> > 2 files changed, 55 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
> > b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
> > index d55ef016d418..ad554668cc86 100644
> > --- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
> > +++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
> > @@ -37,7 +37,7 @@ static int dvb_usbv2_download_firmware(struct
> > dvb_usb_device *d,
> > {
> > int ret;
> > const struct firmware *fw;
> > - dev_dbg(>udev->dev, "%s:\n", __func__);
> > + dev_dbg(>udev->dev, "\n");
>
> How about "downloading firmware", or maybe deleting the line
> completely?
Ok
> Without dynamic debug enabled, you end up with a pretty useless
> debug message now. I think it would be better to convert these
> debug lines to useful messages, rather than "executing this
> line of code". Some of them should probably be deleted.
Yes, some of those debug lines are not useful without dynamic
debug. Some messages can be improved.
> > if (!d->props->download_firmware) {
> > ret = -EINVAL;
> > @@ -62,14 +62,14 @@ static int dvb_usbv2_download_firmware(struct
> > dvb_usb_device *d,
> >
> > return ret;
> > err:
> > - dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
> > + dev_dbg(>udev->dev, "failed=%d\n", ret);
>
> Again, just say what failed here. Ideally debug messages should
> be useful and not just "hit this line of code".
>
> Sean
I'll go over all of them again and send a new version.
Cheers,
Victor
> > return ret;
> > }
> >
> > static int dvb_usbv2_i2c_init(struct dvb_usb_device *d)
> > {
> > int ret;
> > - dev_dbg(>udev->dev, "%s:\n", __func__);
> > + dev_dbg(>udev->dev, "\n");
> >
> > if (!d->props->i2c_algo)
> > return 0;
> > @@ -87,13 +87,13 @@ static int dvb_usbv2_i2c_init(struct dvb_usb_device *d)
> >
> > return 0;
> > err:
> > - dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
> > + dev_dbg(>udev->dev, "failed=%d\n", ret);
> > return ret;
> > }
> >
> > static int dvb_usbv2_i2c_exit(struct dvb_usb_device *d)
> > {
> > - dev_dbg(>udev->dev, "%s:\n", __func__);
> > + dev_dbg(>udev->dev, "\n");
> >
> > if (d->i2c_adap.algo)
> > i2c_del_adapter(>i2c_adap);
> > @@ -133,7 +133,7 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device
> > *d)
> > {
> > int ret;
> > struct rc_dev *dev;
> > - dev_dbg(>udev->dev, "%s:\n", __func__);
> > + dev_dbg(>udev->dev, "\n");
> >
> > if (dvb_usbv2_disable_rc_polling || !d->props->get_rc_config)
> > return 0;
> > @@ -188,13 +188,13 @@ static int dvb_usbv2_remote_init(struct
> > dvb_usb_device *d)
> >
> > return 0;
> > err:
> > - dev_dbg(>udev->dev, "%s: failed=%d\n", __func__, ret);
> > + dev_dbg(>udev->dev, "failed=%d\n", ret);
> > return ret;
> > }
> >
> > static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
> > {
> > - dev_dbg(>udev->dev, "%s:\n", __func__);
> > + dev_dbg(>udev->dev, "\n");
> >
> > if (d->rc_dev) {
> > cancel_delayed_work_sync(>rc_query_work);
> > @@ -232,7 +232,7 @@ static void dvb_usb_data_complete_raw(struct
> > usb_data_stream *stream, u8 *buf,
> >
> > static int dvb_usbv2_adapter_stream_init(struct dvb_usb_adapter *adap)
> > {
> > - dev_dbg(_to_d(adap)->udev->dev, "%s: adap=%d\n", __func__,
> > + dev_dbg(_to_d(adap)->udev->dev, "adap=%d\n",
> > adap->id);
> >
> > adap->stream.udev = adap_to_d(adap)->udev;
> > @@ -244,7 +244,7 @@ static int dvb_usbv2_adapter_stream_init(struct
> > dvb_usb_adapter *adap)
> >
> > static int dvb_usbv2_adapter_stream_exit(struct dvb_usb_adapter *adap)
> > {
> > - dev_dbg(_to_d(adap)->udev->dev, "%s: adap=%d\n", __func__,
> > + dev_dbg(_to_d(adap)->udev->dev, "adap=%d\n",
> > adap->id);
> >
> > return usb_urb_exitv2(>stream);
> > @@ -257,8 +257,8 @@ static int dvb_usb_start_feed(struct dvb_demux_feed
> > *dvbdmxfeed)
> > int ret = 0;
> > struct usb_data_stream_properties stream_props;
> > dev_dbg(>udev->dev,
> > - "%s: adap=%d active_fe=%d feed_type=%d setting pid
> > [%s]: %04x (%04d) at index %d\n",
> > - __func__, adap->id, adap->active_fe, dvbdmxfeed->type,
> > + "adap=%d active_fe=%d feed_type=%d
Re: [PATCH v6 01/12] media: ov5640: Fix set format regression
On Mon, Dec 3, 2018 at 2:45 AM Maxime Ripard wrote:
>
> From: Jacopo Mondi
>
> The set_fmt operations updates the sensor format only when the image format
> is changed. When only the image sizes gets changed, the format do not get
> updated causing the sensor to always report the one that was previously in
> use.
>
> Without this patch, updating frame size only fails:
> [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...]
>
> With this patch applied:
> [fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...]
>
> Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame
> interval is unchanged")
> Signed-off-by: Jacopo Mondi
> Signed-off-by: Maxime Ripard
Tested-by: Adam Ford #imx6 w/ CSI2 interface on
4.19.6 and 4.20-RC5
> ---
> drivers/media/i2c/ov5640.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index a91d91715d00..807bd0e386a4 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2021,6 +2021,7 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
> const struct ov5640_mode_info *new_mode;
> struct v4l2_mbus_framefmt *mbus_fmt = >format;
> + struct v4l2_mbus_framefmt *fmt;
> int ret;
>
> if (format->pad != 0)
> @@ -2038,22 +2039,20 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
> if (ret)
> goto out;
>
> - if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
> - struct v4l2_mbus_framefmt *fmt =
> - v4l2_subdev_get_try_format(sd, cfg, 0);
> + if (format->which == V4L2_SUBDEV_FORMAT_TRY)
> + fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
> + else
> + fmt = >fmt;
>
> - *fmt = *mbus_fmt;
> - goto out;
> - }
> + *fmt = *mbus_fmt;
>
> if (new_mode != sensor->current_mode) {
> sensor->current_mode = new_mode;
> sensor->pending_mode_change = true;
> }
> - if (mbus_fmt->code != sensor->fmt.code) {
> - sensor->fmt = *mbus_fmt;
> + if (mbus_fmt->code != sensor->fmt.code)
> sensor->pending_fmt_change = true;
> - }
> +
> out:
> mutex_unlock(>lock);
> return ret;
> --
> git-series 0.9.1
Re: [GIT PULL FOR v4.21] dvb fixes
Em Wed, 28 Nov 2018 19:40:30 + Sean Young escreveu: > Hi Mauro, > > So I've gone through the outstanding DVB patches and picked up the easier > ones to deal with first. Please scrutinise. Thanks! Just one note. See below. > > Thanks, > > Sean > > The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0: > > media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 > -0500) > > are available in the Git repository at: > > git://linuxtv.org/syoung/media_tree.git for-v4.21b > > for you to fetch changes up to b2d148f755fc60840fbaec52388152896f8339be: > > media: sony-cxd2880: add optional vcc regulator to bindings (2018-11-27 > 16:04:16 +) > > > Colin Ian King (1): > media: dib0700: fix spelling mistake "Amplifyer" -> "Amplifier" > > Hans Verkuil (1): > media: dib0900: fix smatch warnings > > Julia Lawall (1): > media: mxl5xx: constify dvb_frontend_ops structure > > Malcolm Priestley (1): > media: dvb-usb-v2: Fix incorrect use of transfer_flags URB_FREE_BUFFER > > Neil Armstrong (3): > media: cxd2880-spi: fix probe when dvb_attach fails > media: cxd2880-spi: Add optional vcc regulator Looks fine. You only forgot to add a: Acked-by: Yasunari Takiguchi To the above patches. The Acked was written to patch 0/2. Patchwork doesn't automatically handle replies to patch 0/x, so you need to add the ack yourself ;-) I added it myself and merged. > media: sony-cxd2880: add optional vcc regulator to bindings > > Sean Young (1): > media: saa7134: rc-core maintains users count, no need to duplicate > > Victor Toso (2): > media: af9033: Remove duplicated switch statement > media: dvb: Use WARM definition from identify_state() > > zhong jiang (2): > media: usb: Use kmemdup instead of duplicating its function. > media: dvb-frontends: Use kmemdup instead of duplicating its function > > .../devicetree/bindings/media/spi/sony-cxd2880.txt | 4 ++ > drivers/media/dvb-frontends/af9033.c | 12 +--- > drivers/media/dvb-frontends/dib0090.c | 32 +- > drivers/media/dvb-frontends/lgdt3306a.c| 6 +- > drivers/media/dvb-frontends/mxl5xx.c | 2 +- > drivers/media/pci/saa7134/saa7134-core.c | 8 +-- > drivers/media/pci/saa7134/saa7134-input.c | 68 > -- > drivers/media/pci/saa7134/saa7134.h| 9 ++- > drivers/media/spi/cxd2880-spi.c| 17 ++ > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c| 6 +- > drivers/media/usb/dvb-usb-v2/gl861.c | 3 +- > drivers/media/usb/dvb-usb-v2/usb_urb.c | 5 +- > drivers/media/usb/dvb-usb/dib0700_devices.c| 2 +- > 13 files changed, 66 insertions(+), 108 deletions(-) Thanks, Mauro
Re: [PATCH 2/2] media: ov5640: make MIPI clock depend on mode
5244 seconds (14.439924 fps, 11977050.339261 > > B/s). > > capturing 720x576 @ 20FPS > > Captured 100 frames in 4.68 seconds (20.000127 fps, 16588905.060854 > > B/s). > > capturing 720x576 @ 30FPS > > Captured 100 frames in 3.487568 seconds (28.673276 fps, 23782762.085212 > > B/s). > > > > capturing 1024x768 @ 10FPS > > Captured 100 frames in 10.107128 seconds (9.894007 fps, 15561928.174298 > > B/s). > > capturing 1024x768 @ 15FPS > > Captured 100 frames in 6.810568 seconds (14.683062 fps, 23094459.169337 > > B/s). > > capturing 1024x768 @ 20FPS > > Captured 100 frames in 5.012039 seconds (19.951960 fps, 31381719.096759 > > B/s). > > capturing 1024x768 @ 30FPS > > Captured 100 frames in 3.346338 seconds (29.883407 fps, 47002534.905114 > > B/s). > > > > capturing 1280x720 @ 10FPS > > Captured 100 frames in 9.957613 seconds (10.042567 fps, 18510459.665283 > > B/s). > > capturing 1280x720 @ 15FPS > > Captured 100 frames in 6.597751 seconds (15.156679 fps, 27936790.986673 > > B/s). > > capturing 1280x720 @ 20FPS > > Captured 100 frames in 4.946115 seconds (20.217888 fps, 37265611.495083 > > B/s). > > capturing 1280x720 @ 30FPS > > Captured 100 frames in 3.301329 seconds (30.290825 fps, 55832049.080847 > > B/s). > > > > capturing 1920x1080 @ 10FPS > > Captured 100 frames in 10.024745 seconds (9.975316 fps, 41369629.470131 > > B/s). > > capturing 1920x1080 @ 15FPS > > Captured 100 frames in 6.674363 seconds (14.982702 fps, 62136260.577244 > > B/s). > > capturing 1920x1080 @ 20FPS > > Captured 100 frames in 5.102174 seconds (19.599488 fps, 81282998.172684 > > B/s). > > capturing 1920x1080 @ 30FPS > > Captured 100 frames in 3.341157 seconds (29.929746 fps, 124124642.214916 > > B/s). > > > > capturing 2592x1944 @ 10FPS > > Captured 100 frames in 13.019132 seconds (7.681004 fps, 77406819.428913 > > B/s). > > capturing 2592x1944 @ 15FPS > > Captured 100 frames in 8.819705 seconds (11.338248 fps, 114263413.559267 > > B/s). > > capturing 2592x1944 @ 20FPS > > Captured 100 frames in 6.876134 seconds (14.543055 fps, 146560487.484508 > > B/s). > > capturing 2592x1944 @ 30FPS > > Captured 100 frames in 4.359511 seconds (22.938352 fps, 231165743.130365 > > B/s). > > --- > > drivers/media/i2c/ov5640.c | 93 > > +++--- > > 1 file changed, 46 insertions(+), 47 deletions(-) > > > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c > > index c659efe918a4..13b7a0d04840 100644 > > --- a/drivers/media/i2c/ov5640.c > > +++ b/drivers/media/i2c/ov5640.c > > @@ -740,8 +740,11 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, > > u16 reg, > > * |+---> SCLK 2X > > * | +-+ > > * +->| PCLK Div| - reg 0x3108, bits 4-5 > > - *+-+---+ > > - * +---> PCLK > > + *+++ > > + * + +---+ > > + * +->| P_DIV | - reg 0x3035, bits 0-3 > > + *+-----+-+ > > + * +> PCLK > > * > > * This is deviating from the datasheet at least for the register > > * 0x3108, since it's said here that the PCLK would be clocked from > > @@ -751,7 +754,6 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, > > u16 reg, > > * - the PLL pre-divider output rate should be in the 4-27MHz range > > * - the PLL multiplier output rate should be in the 500-1000MHz range > > * - PCLK >= SCLK * 2 in YUV, >= SCLK in Raw or JPEG > > - * - MIPI SCLK = (bpp / lanes) / PCLK > > * > > * In the two latter cases, these constraints are met since our > > * factors are hardcoded. If we were to change that, we would need to > > @@ -777,10 +779,11 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, > > u16 reg, > > #define OV5640_SYSDIV_MAX 16 > > > > /* > > - * This is supposed to be ranging from 1 to 16, but the value is always > > - * set to 2 in the vendor kernels. > > + * Hardcode these values for scaler and non-scaler modes. > > + * FIXME: to be re-calcualted for 1 data lanes setups > > */ > > -#define OV5640_MIPI_DIV2 > > +#define OV5640_MIPI_D
