Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Tue, Dec 2, 2014 at 7:32 AM, Hans Verkuil wrote: > On 12/01/2014 11:27 PM, Prabhakar Lad wrote: >> Hi Hans, >> >> On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil wrote: >>> On 12/01/2014 11:11 AM, Hans Verkuil wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: > From: Benoit Parrot > > This patch adds Video Processing Front End (VPFE) driver for > AM437X family of devices > Driver supports the following: > - V4L2 API using MMAP buffer access based on videobuf2 api > - Asynchronous sensor/decoder sub device registration > - DT support > > Signed-off-by: Benoit Parrot > Signed-off-by: Darren Etheridge > Signed-off-by: Lad, Prabhakar > --- > .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + > MAINTAINERS|9 + > drivers/media/platform/Kconfig |1 + > drivers/media/platform/Makefile|2 + > drivers/media/platform/am437x/Kconfig | 10 + > drivers/media/platform/am437x/Makefile |2 + > drivers/media/platform/am437x/vpfe.c | 2764 > > drivers/media/platform/am437x/vpfe.h | 286 ++ > drivers/media/platform/am437x/vpfe_regs.h | 140 + > include/uapi/linux/Kbuild |1 + > include/uapi/linux/am437x_vpfe.h | 122 + > 11 files changed, 3398 insertions(+) >>> >>> Can the source names be improved? There are too many 'vpfe' sources. >>> Perhaps prefix all with 'am437x-'? >>> >> I did think of it but, dropped it as anyway the source's are present >> in am437x folder, again naming the files am437x-xxx.x didn't make >> me feel good. If you still insists I'll do it. > > Yes, please do. If you look at most other drivers they all have a prefix. > > Another reason is that the media_build system expects unique names. > OK makes sense I'll prefix it with 'am437x-'. probably fixing all the review comments i'll post a v2 end of the day. Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Tue, Dec 2, 2014 at 7:26 AM, Hans Verkuil wrote: > On 12/01/2014 11:17 PM, Prabhakar Lad wrote: >> Hi Hans, >> >> Thanks for the review. >> >> On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil wrote: >>> Hi all, >>> >>> Thanks for the patch, review comments are below. >>> >>> For the next version I would appreciate if someone can test this driver with >>> the latest v4l2-compliance from the v4l-utils git repo. If possible test >>> streaming >>> as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver >>> input. >>> But that depends on the available hardware of course. >>> >>> I'd like to see the v4l2-compliance output. It's always good to have that on >>> record. >>> >> Following is the compliance output, missed it post it along with patch: >> >> root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v >> Driver Info: >> Driver name : vpfe >> Card type :[ 70.363908] vpfe 48326000.vpfe: >> = START STATUS = >> TI AM437x VPFE >> Bus info : platform:vpfe [ 70.375576] vpfe >> 48326000.vpfe: == END STATUS == >> 48326000.vpfe >> Driver version: 3.18.0 >> Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 >> ities : 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 >> >> 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 >> 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 (Not Supported) >> test VIDIOC_QUERYCTRL: OK (Not Supported) >> test VIDIOC_G/S_CTRL: OK (Not Supported) >> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) >> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) >> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) >> Standard Controls: 0 Private Controls: 0 >> >> Format ioctls: >> info: found 7 framesizes for pixel format 56595559 >> info: found 7 framesizes for pixel format 59565955 >> info: found 7 framesizes for pixel format 52424752 >> info: found 7 framesizes for pixel format 31384142 >> info: found 4 formats for buftype 1 >> 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 >> test VIDIOC_TRY_FMT: OK >> info: Global format check succeeded for type 1 >> test VIDIOC_S_FMT: OK >> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) >> >> Codec ioctls: >> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) >> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) >> >> Buffer ioctls: >> info: test buftype Video Capture >> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK >> test VIDIOC_EXPBUF: OK >> >> Streaming ioctls: >> test read/write: OK >> Video Capture: >> Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s >> Buffer: 1 Sequence: 0 Field: None Timestamp:
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:27 PM, Prabhakar Lad wrote: > Hi Hans, > > On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil wrote: >> On 12/01/2014 11:11 AM, Hans Verkuil wrote: >>> Hi all, >>> >>> Thanks for the patch, review comments are below. >>> >>> For the next version I would appreciate if someone can test this driver with >>> the latest v4l2-compliance from the v4l-utils git repo. If possible test >>> streaming >>> as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver >>> input. >>> But that depends on the available hardware of course. >>> >>> I'd like to see the v4l2-compliance output. It's always good to have that on >>> record. >>> >>> >>> On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: From: Benoit Parrot This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot Signed-off-by: Darren Etheridge Signed-off-by: Lad, Prabhakar --- .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + MAINTAINERS|9 + drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|2 + drivers/media/platform/am437x/Kconfig | 10 + drivers/media/platform/am437x/Makefile |2 + drivers/media/platform/am437x/vpfe.c | 2764 drivers/media/platform/am437x/vpfe.h | 286 ++ drivers/media/platform/am437x/vpfe_regs.h | 140 + include/uapi/linux/Kbuild |1 + include/uapi/linux/am437x_vpfe.h | 122 + 11 files changed, 3398 insertions(+) >> >> Can the source names be improved? There are too many 'vpfe' sources. >> Perhaps prefix all with 'am437x-'? >> > I did think of it but, dropped it as anyway the source's are present > in am437x folder, again naming the files am437x-xxx.x didn't make > me feel good. If you still insists I'll do it. Yes, please do. If you look at most other drivers they all have a prefix. Another reason is that the media_build system expects unique names. Regards, Hans >> In general I prefer '-' over '_' in a source name: it's looks better >> IMHO. >> > I am almost done with all the review comments, if we take a decision > on this quickly I can post a v2 soon. > >> One question, unrelated to this patch series: >> >> Prabhakar, would it make sense to look at the various existing TI sources >> as well and rename them to make it more explicit for which SoCs they are >> meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but >> no reference to the actual SoC they are for. >> > vpe - definitely needs to be changed. > vpif - under davinci is common for (Davinci series > dm6467/dm6467t/omapl138/am1808) > vpfe - under davinci is common for (Davinci series dm36x/dm6446/dm355) > > I am falling short of names for renaming this common drivers :) > > Thanks, > --Prabhakar Lad > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:17 PM, Prabhakar Lad wrote: > Hi Hans, > > Thanks for the review. > > On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil wrote: >> Hi all, >> >> Thanks for the patch, review comments are below. >> >> For the next version I would appreciate if someone can test this driver with >> the latest v4l2-compliance from the v4l-utils git repo. If possible test >> streaming >> as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver >> input. >> But that depends on the available hardware of course. >> >> I'd like to see the v4l2-compliance output. It's always good to have that on >> record. >> > Following is the compliance output, missed it post it along with patch: > > root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v > Driver Info: > Driver name : vpfe > Card type :[ 70.363908] vpfe 48326000.vpfe: > = START STATUS = > TI AM437x VPFE > Bus info : platform:vpfe [ 70.375576] vpfe > 48326000.vpfe: == END STATUS == > 48326000.vpfe > Driver version: 3.18.0 > Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 > ities : 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 > > 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 > 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 (Not Supported) > test VIDIOC_QUERYCTRL: OK (Not Supported) > test VIDIOC_G/S_CTRL: OK (Not Supported) > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 0 Private Controls: 0 > > Format ioctls: > info: found 7 framesizes for pixel format 56595559 > info: found 7 framesizes for pixel format 59565955 > info: found 7 framesizes for pixel format 52424752 > info: found 7 framesizes for pixel format 31384142 > info: found 4 formats for buftype 1 > 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 > test VIDIOC_TRY_FMT: OK > info: Global format check succeeded for type 1 > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > info: test buftype Video Capture > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > > Streaming ioctls: > test read/write: OK > Video Capture: > Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s > Buffer: 1 Sequence: 0 Field: None Timestamp: 74.979310s > Buffer: 2 Sequence: 0 Field: None Timestamp: 75.002191s > Buffer: 3 Sequence: 0 Field: None Timestamp: 75.208114s >
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil wrote: > On 12/01/2014 11:11 AM, Hans Verkuil wrote: >> Hi all, >> >> Thanks for the patch, review comments are below. >> >> For the next version I would appreciate if someone can test this driver with >> the latest v4l2-compliance from the v4l-utils git repo. If possible test >> streaming >> as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver >> input. >> But that depends on the available hardware of course. >> >> I'd like to see the v4l2-compliance output. It's always good to have that on >> record. >> >> >> On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: >>> From: Benoit Parrot >>> >>> This patch adds Video Processing Front End (VPFE) driver for >>> AM437X family of devices >>> Driver supports the following: >>> - V4L2 API using MMAP buffer access based on videobuf2 api >>> - Asynchronous sensor/decoder sub device registration >>> - DT support >>> >>> Signed-off-by: Benoit Parrot >>> Signed-off-by: Darren Etheridge >>> Signed-off-by: Lad, Prabhakar >>> --- >>> .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + >>> MAINTAINERS|9 + >>> drivers/media/platform/Kconfig |1 + >>> drivers/media/platform/Makefile|2 + >>> drivers/media/platform/am437x/Kconfig | 10 + >>> drivers/media/platform/am437x/Makefile |2 + >>> drivers/media/platform/am437x/vpfe.c | 2764 >>> >>> drivers/media/platform/am437x/vpfe.h | 286 ++ >>> drivers/media/platform/am437x/vpfe_regs.h | 140 + >>> include/uapi/linux/Kbuild |1 + >>> include/uapi/linux/am437x_vpfe.h | 122 + >>> 11 files changed, 3398 insertions(+) > > Can the source names be improved? There are too many 'vpfe' sources. > Perhaps prefix all with 'am437x-'? > I did think of it but, dropped it as anyway the source's are present in am437x folder, again naming the files am437x-xxx.x didn't make me feel good. If you still insists I'll do it. > In general I prefer '-' over '_' in a source name: it's looks better > IMHO. > I am almost done with all the review comments, if we take a decision on this quickly I can post a v2 soon. > One question, unrelated to this patch series: > > Prabhakar, would it make sense to look at the various existing TI sources > as well and rename them to make it more explicit for which SoCs they are > meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but > no reference to the actual SoC they are for. > vpe - definitely needs to be changed. vpif - under davinci is common for (Davinci series dm6467/dm6467t/omapl138/am1808) vpfe - under davinci is common for (Davinci series dm36x/dm6446/dm355) I am falling short of names for renaming this common drivers :) Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, Thanks for the review. On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil wrote: > Hi all, > > Thanks for the patch, review comments are below. > > For the next version I would appreciate if someone can test this driver with > the latest v4l2-compliance from the v4l-utils git repo. If possible test > streaming > as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver > input. > But that depends on the available hardware of course. > > I'd like to see the v4l2-compliance output. It's always good to have that on > record. > Following is the compliance output, missed it post it along with patch: root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v Driver Info: Driver name : vpfe Card type :[ 70.363908] vpfe 48326000.vpfe: = START STATUS = TI AM437x VPFE Bus info : platform:vpfe [ 70.375576] vpfe 48326000.vpfe: == END STATUS == 48326000.vpfe Driver version: 3.18.0 Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 ities : 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 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 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 (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: info: found 7 framesizes for pixel format 56595559 info: found 7 framesizes for pixel format 59565955 info: found 7 framesizes for pixel format 52424752 info: found 7 framesizes for pixel format 31384142 info: found 4 formats for buftype 1 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 test VIDIOC_TRY_FMT: OK info: Global format check succeeded for type 1 test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Streaming ioctls: test read/write: OK Video Capture: Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s Buffer: 1 Sequence: 0 Field: None Timestamp: 74.979310s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.002191s Buffer: 3 Sequence: 0 Field: None Timestamp: 75.208114s Buffer: 0 Sequence: 0 Field: None Timestamp: 75.230998s Buffer: 1 Sequence: 0 Field: None Timestamp: 75.253877s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.276756s Buffer: 3 Sequence: 0 Field: None Timestamp: 75.299637s
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:11 AM, Hans Verkuil wrote: > Hi all, > > Thanks for the patch, review comments are below. > > For the next version I would appreciate if someone can test this driver with > the latest v4l2-compliance from the v4l-utils git repo. If possible test > streaming > as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver > input. > But that depends on the available hardware of course. > > I'd like to see the v4l2-compliance output. It's always good to have that on > record. > > > On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: >> From: Benoit Parrot >> >> This patch adds Video Processing Front End (VPFE) driver for >> AM437X family of devices >> Driver supports the following: >> - V4L2 API using MMAP buffer access based on videobuf2 api >> - Asynchronous sensor/decoder sub device registration >> - DT support >> >> Signed-off-by: Benoit Parrot >> Signed-off-by: Darren Etheridge >> Signed-off-by: Lad, Prabhakar >> --- >> .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + >> MAINTAINERS|9 + >> drivers/media/platform/Kconfig |1 + >> drivers/media/platform/Makefile|2 + >> drivers/media/platform/am437x/Kconfig | 10 + >> drivers/media/platform/am437x/Makefile |2 + >> drivers/media/platform/am437x/vpfe.c | 2764 >> >> drivers/media/platform/am437x/vpfe.h | 286 ++ >> drivers/media/platform/am437x/vpfe_regs.h | 140 + >> include/uapi/linux/Kbuild |1 + >> include/uapi/linux/am437x_vpfe.h | 122 + >> 11 files changed, 3398 insertions(+) Can the source names be improved? There are too many 'vpfe' sources. Perhaps prefix all with 'am437x-'? In general I prefer '-' over '_' in a source name: it's looks better IMHO. One question, unrelated to this patch series: Prabhakar, would it make sense to look at the various existing TI sources as well and rename them to make it more explicit for which SoCs they are meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but no reference to the actual SoC they are for. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi all,
Thanks for the patch, review comments are below.
For the next version I would appreciate if someone can test this driver with
the latest v4l2-compliance from the v4l-utils git repo. If possible test
streaming
as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver
input.
But that depends on the available hardware of course.
I'd like to see the v4l2-compliance output. It's always good to have that on
record.
On 11/24/2014 02:10 AM, Lad, Prabhakar wrote:
> From: Benoit Parrot
>
> This patch adds Video Processing Front End (VPFE) driver for
> AM437X family of devices
> Driver supports the following:
> - V4L2 API using MMAP buffer access based on videobuf2 api
> - Asynchronous sensor/decoder sub device registration
> - DT support
>
> Signed-off-by: Benoit Parrot
> Signed-off-by: Darren Etheridge
> Signed-off-by: Lad, Prabhakar
> ---
> .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 +
> MAINTAINERS|9 +
> drivers/media/platform/Kconfig |1 +
> drivers/media/platform/Makefile|2 +
> drivers/media/platform/am437x/Kconfig | 10 +
> drivers/media/platform/am437x/Makefile |2 +
> drivers/media/platform/am437x/vpfe.c | 2764
>
> drivers/media/platform/am437x/vpfe.h | 286 ++
> drivers/media/platform/am437x/vpfe_regs.h | 140 +
> include/uapi/linux/Kbuild |1 +
> include/uapi/linux/am437x_vpfe.h | 122 +
> 11 files changed, 3398 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
> create mode 100644 drivers/media/platform/am437x/Kconfig
> create mode 100644 drivers/media/platform/am437x/Makefile
> create mode 100644 drivers/media/platform/am437x/vpfe.c
> create mode 100644 drivers/media/platform/am437x/vpfe.h
> create mode 100644 drivers/media/platform/am437x/vpfe_regs.h
> create mode 100644 include/uapi/linux/am437x_vpfe.h
>
> diff --git a/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
> b/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
> new file mode 100644
> index 000..3932e76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
> @@ -0,0 +1,61 @@
> +Texas Instruments AM437x CAMERA (VPFE)
> +--
> +
> +The Video Processing Front End (VPFE) is a key component for image capture
> +applications. The capture module provides the system interface and the
> +processing capability to connect RAW image-sensor modules and video decoders
> +to the AM437x device.
> +
> +Required properties:
> +- compatible: must be "ti,am437x-vpfe"
> +- reg: physical base address and length of the registers set for the device;
> +- interrupts: should contain IRQ line for the VPFE;
> +- ti,am437x-vpfe-interface: can be one of the following,
> + 0 - Raw Bayer Interface.
> + 1 - 8 Bit BT656 Interface.
> + 2 - 10 Bit BT656 Interface.
> + 3 - YCbCr 8 Bit Interface.
> + 4 - YCbCr 16 Bit Interface.
> +
> +VPFE supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + vpfe: vpfe@f0034000 {
> + compatible = "ti,am437x-vpfe";
> + reg = <0x48328000 0x2000>;
> + interrupts = ;
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_pins_default>;
> + pinctrl-1 = <_pins_sleep>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vpfe0_ep: endpoint {
> + remote-endpoint = <_1>;
> + ti,am437x-vpfe-interface = <0>;
> + bus-width = <8>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +
> + i2c1: i2c@4802a000 {
> +
> + ov2659@30 {
> + compatible = "ti,ov2659";
> + reg = <0x30>;
> +
> + port {
> + ov2659_1: endpoint {
> + remote-endpoint = <_ep>;
> + bus-width = <8>;
> + mclk-frequency = <1200>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a6288ca..a42d367 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8537,6 +8537,15 @@ S: Maintained
> F: drivers/media/platform/davinci/
> F: include/media/davinci/
>
> +TI AM437X VPFE DRIVER
> +M: Lad, Prabhakar
> +L:
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, Thanks for the review. On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. Following is the compliance output, missed it post it along with patch: root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v Driver Info: Driver name : vpfe Card type :[ 70.363908] vpfe 48326000.vpfe: = START STATUS = TI AM437x VPFE Bus info : platform:vpfe [ 70.375576] vpfe 48326000.vpfe: == END STATUS == 48326000.vpfe Driver version: 3.18.0 Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 ities : 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 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 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 (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: info: found 7 framesizes for pixel format 56595559 info: found 7 framesizes for pixel format 59565955 info: found 7 framesizes for pixel format 52424752 info: found 7 framesizes for pixel format 31384142 info: found 4 formats for buftype 1 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 test VIDIOC_TRY_FMT: OK info: Global format check succeeded for type 1 test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Streaming ioctls: test read/write: OK Video Capture: Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s Buffer: 1 Sequence: 0 Field: None Timestamp: 74.979310s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.002191s Buffer: 3 Sequence: 0 Field: None Timestamp: 75.208114s Buffer: 0 Sequence: 0 Field: None Timestamp: 75.230998s Buffer: 1 Sequence: 0 Field: None Timestamp: 75.253877s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.276756s Buffer: 3 Sequence: 0 Field: None Timestamp:
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 12/01/2014 11:11 AM, Hans Verkuil wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: From: Benoit Parrot bpar...@ti.com This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot bpar...@ti.com Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + MAINTAINERS|9 + drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|2 + drivers/media/platform/am437x/Kconfig | 10 + drivers/media/platform/am437x/Makefile |2 + drivers/media/platform/am437x/vpfe.c | 2764 drivers/media/platform/am437x/vpfe.h | 286 ++ drivers/media/platform/am437x/vpfe_regs.h | 140 + include/uapi/linux/Kbuild |1 + include/uapi/linux/am437x_vpfe.h | 122 + 11 files changed, 3398 insertions(+) Can the source names be improved? There are too many 'vpfe' sources. Perhaps prefix all with 'am437x-'? I did think of it but, dropped it as anyway the source's are present in am437x folder, again naming the files am437x-xxx.x didn't make me feel good. If you still insists I'll do it. In general I prefer '-' over '_' in a source name: it's looks better IMHO. I am almost done with all the review comments, if we take a decision on this quickly I can post a v2 soon. One question, unrelated to this patch series: Prabhakar, would it make sense to look at the various existing TI sources as well and rename them to make it more explicit for which SoCs they are meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but no reference to the actual SoC they are for. vpe - definitely needs to be changed. vpif - under davinci is common for (Davinci series dm6467/dm6467t/omapl138/am1808) vpfe - under davinci is common for (Davinci series dm36x/dm6446/dm355) I am falling short of names for renaming this common drivers :) Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:17 PM, Prabhakar Lad wrote: Hi Hans, Thanks for the review. On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. Following is the compliance output, missed it post it along with patch: root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v Driver Info: Driver name : vpfe Card type :[ 70.363908] vpfe 48326000.vpfe: = START STATUS = TI AM437x VPFE Bus info : platform:vpfe [ 70.375576] vpfe 48326000.vpfe: == END STATUS == 48326000.vpfe Driver version: 3.18.0 Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 ities : 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 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 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 (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: info: found 7 framesizes for pixel format 56595559 info: found 7 framesizes for pixel format 59565955 info: found 7 framesizes for pixel format 52424752 info: found 7 framesizes for pixel format 31384142 info: found 4 formats for buftype 1 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 test VIDIOC_TRY_FMT: OK info: Global format check succeeded for type 1 test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Streaming ioctls: test read/write: OK Video Capture: Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s Buffer: 1 Sequence: 0 Field: None Timestamp: 74.979310s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.002191s Buffer: 3 Sequence: 0 Field: None Timestamp: 75.208114s Buffer: 0 Sequence: 0 Field: None Timestamp: 75.230998s Hmm, sequence is always 0. Is the sequence field set? And
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:27 PM, Prabhakar Lad wrote: Hi Hans, On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 12/01/2014 11:11 AM, Hans Verkuil wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: From: Benoit Parrot bpar...@ti.com This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot bpar...@ti.com Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + MAINTAINERS|9 + drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|2 + drivers/media/platform/am437x/Kconfig | 10 + drivers/media/platform/am437x/Makefile |2 + drivers/media/platform/am437x/vpfe.c | 2764 drivers/media/platform/am437x/vpfe.h | 286 ++ drivers/media/platform/am437x/vpfe_regs.h | 140 + include/uapi/linux/Kbuild |1 + include/uapi/linux/am437x_vpfe.h | 122 + 11 files changed, 3398 insertions(+) Can the source names be improved? There are too many 'vpfe' sources. Perhaps prefix all with 'am437x-'? I did think of it but, dropped it as anyway the source's are present in am437x folder, again naming the files am437x-xxx.x didn't make me feel good. If you still insists I'll do it. Yes, please do. If you look at most other drivers they all have a prefix. Another reason is that the media_build system expects unique names. Regards, Hans In general I prefer '-' over '_' in a source name: it's looks better IMHO. I am almost done with all the review comments, if we take a decision on this quickly I can post a v2 soon. One question, unrelated to this patch series: Prabhakar, would it make sense to look at the various existing TI sources as well and rename them to make it more explicit for which SoCs they are meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but no reference to the actual SoC they are for. vpe - definitely needs to be changed. vpif - under davinci is common for (Davinci series dm6467/dm6467t/omapl138/am1808) vpfe - under davinci is common for (Davinci series dm36x/dm6446/dm355) I am falling short of names for renaming this common drivers :) Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Tue, Dec 2, 2014 at 7:26 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 12/01/2014 11:17 PM, Prabhakar Lad wrote: Hi Hans, Thanks for the review. On Mon, Dec 1, 2014 at 10:11 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. Following is the compliance output, missed it post it along with patch: root@am437x-evm:~# ./v4l2-compliance -s -i 0 -v Driver Info: Driver name : vpfe Card type :[ 70.363908] vpfe 48326000.vpfe: = START STATUS = TI AM437x VPFE Bus info : platform:vpfe [ 70.375576] vpfe 48326000.vpfe: == END STATUS == 48326000.vpfe Driver version: 3.18.0 Capabil[ 70.388485] vpfe 48326000.vpfe: invalid input index: 1 ities : 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 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 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 (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: info: found 7 framesizes for pixel format 56595559 info: found 7 framesizes for pixel format 59565955 info: found 7 framesizes for pixel format 52424752 info: found 7 framesizes for pixel format 31384142 info: found 4 formats for buftype 1 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 test VIDIOC_TRY_FMT: OK info: Global format check succeeded for type 1 test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Streaming ioctls: test read/write: OK Video Capture: Buffer: 0 Sequence: 0 Field: None Timestamp: 74.956437s Buffer: 1 Sequence: 0 Field: None Timestamp: 74.979310s Buffer: 2 Sequence: 0 Field: None Timestamp: 75.002191s Buffer: 3 Sequence: 0 Field: None Timestamp: 75.208114s Buffer: 0 Sequence: 0 Field: None Timestamp:
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi Hans, On Tue, Dec 2, 2014 at 7:32 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 12/01/2014 11:27 PM, Prabhakar Lad wrote: Hi Hans, On Mon, Dec 1, 2014 at 11:00 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 12/01/2014 11:11 AM, Hans Verkuil wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: From: Benoit Parrot bpar...@ti.com This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot bpar...@ti.com Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + MAINTAINERS|9 + drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|2 + drivers/media/platform/am437x/Kconfig | 10 + drivers/media/platform/am437x/Makefile |2 + drivers/media/platform/am437x/vpfe.c | 2764 drivers/media/platform/am437x/vpfe.h | 286 ++ drivers/media/platform/am437x/vpfe_regs.h | 140 + include/uapi/linux/Kbuild |1 + include/uapi/linux/am437x_vpfe.h | 122 + 11 files changed, 3398 insertions(+) Can the source names be improved? There are too many 'vpfe' sources. Perhaps prefix all with 'am437x-'? I did think of it but, dropped it as anyway the source's are present in am437x folder, again naming the files am437x-xxx.x didn't make me feel good. If you still insists I'll do it. Yes, please do. If you look at most other drivers they all have a prefix. Another reason is that the media_build system expects unique names. OK makes sense I'll prefix it with 'am437x-'. probably fixing all the review comments i'll post a v2 end of the day. Thanks, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
Hi all,
Thanks for the patch, review comments are below.
For the next version I would appreciate if someone can test this driver with
the latest v4l2-compliance from the v4l-utils git repo. If possible test
streaming
as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver
input.
But that depends on the available hardware of course.
I'd like to see the v4l2-compliance output. It's always good to have that on
record.
On 11/24/2014 02:10 AM, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
This patch adds Video Processing Front End (VPFE) driver for
AM437X family of devices
Driver supports the following:
- V4L2 API using MMAP buffer access based on videobuf2 api
- Asynchronous sensor/decoder sub device registration
- DT support
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
.../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 +
MAINTAINERS|9 +
drivers/media/platform/Kconfig |1 +
drivers/media/platform/Makefile|2 +
drivers/media/platform/am437x/Kconfig | 10 +
drivers/media/platform/am437x/Makefile |2 +
drivers/media/platform/am437x/vpfe.c | 2764
drivers/media/platform/am437x/vpfe.h | 286 ++
drivers/media/platform/am437x/vpfe_regs.h | 140 +
include/uapi/linux/Kbuild |1 +
include/uapi/linux/am437x_vpfe.h | 122 +
11 files changed, 3398 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
create mode 100644 drivers/media/platform/am437x/Kconfig
create mode 100644 drivers/media/platform/am437x/Makefile
create mode 100644 drivers/media/platform/am437x/vpfe.c
create mode 100644 drivers/media/platform/am437x/vpfe.h
create mode 100644 drivers/media/platform/am437x/vpfe_regs.h
create mode 100644 include/uapi/linux/am437x_vpfe.h
diff --git a/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
b/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
new file mode 100644
index 000..3932e76
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-am437xx-vpfe.txt
@@ -0,0 +1,61 @@
+Texas Instruments AM437x CAMERA (VPFE)
+--
+
+The Video Processing Front End (VPFE) is a key component for image capture
+applications. The capture module provides the system interface and the
+processing capability to connect RAW image-sensor modules and video decoders
+to the AM437x device.
+
+Required properties:
+- compatible: must be ti,am437x-vpfe
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPFE;
+- ti,am437x-vpfe-interface: can be one of the following,
+ 0 - Raw Bayer Interface.
+ 1 - 8 Bit BT656 Interface.
+ 2 - 10 Bit BT656 Interface.
+ 3 - YCbCr 8 Bit Interface.
+ 4 - YCbCr 16 Bit Interface.
+
+VPFE supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+ vpfe: vpfe@f0034000 {
+ compatible = ti,am437x-vpfe;
+ reg = 0x48328000 0x2000;
+ interrupts = GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH;
+
+ pinctrl-names = default, sleep;
+ pinctrl-0 = vpfe_pins_default;
+ pinctrl-1 = vpfe_pins_sleep;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ vpfe0_ep: endpoint {
+ remote-endpoint = ov2659_1;
+ ti,am437x-vpfe-interface = 0;
+ bus-width = 8;
+ hsync-active = 0;
+ vsync-active = 0;
+ };
+ };
+ };
+
+ i2c1: i2c@4802a000 {
+
+ ov2659@30 {
+ compatible = ti,ov2659;
+ reg = 0x30;
+
+ port {
+ ov2659_1: endpoint {
+ remote-endpoint = vpfe0_ep;
+ bus-width = 8;
+ mclk-frequency = 1200;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a6288ca..a42d367 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8537,6 +8537,15 @@ S: Maintained
F: drivers/media/platform/davinci/
F: include/media/davinci/
+TI AM437X VPFE DRIVER
+M: Lad, Prabhakar prabhakar.cse...@gmail.com
+L:
Re: [PATCH] media: platform: add VPFE capture driver support for AM437X
On 12/01/2014 11:11 AM, Hans Verkuil wrote: Hi all, Thanks for the patch, review comments are below. For the next version I would appreciate if someone can test this driver with the latest v4l2-compliance from the v4l-utils git repo. If possible test streaming as well (v4l2-compliance -s), ideally with both a sensor and a STD receiver input. But that depends on the available hardware of course. I'd like to see the v4l2-compliance output. It's always good to have that on record. On 11/24/2014 02:10 AM, Lad, Prabhakar wrote: From: Benoit Parrot bpar...@ti.com This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot bpar...@ti.com Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/media/ti-am437xx-vpfe.txt | 61 + MAINTAINERS|9 + drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|2 + drivers/media/platform/am437x/Kconfig | 10 + drivers/media/platform/am437x/Makefile |2 + drivers/media/platform/am437x/vpfe.c | 2764 drivers/media/platform/am437x/vpfe.h | 286 ++ drivers/media/platform/am437x/vpfe_regs.h | 140 + include/uapi/linux/Kbuild |1 + include/uapi/linux/am437x_vpfe.h | 122 + 11 files changed, 3398 insertions(+) Can the source names be improved? There are too many 'vpfe' sources. Perhaps prefix all with 'am437x-'? In general I prefer '-' over '_' in a source name: it's looks better IMHO. One question, unrelated to this patch series: Prabhakar, would it make sense to look at the various existing TI sources as well and rename them to make it more explicit for which SoCs they are meant? Most are pretty vague with variations on vpe, vpif, vpfe, etc. but no reference to the actual SoC they are for. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
