Exynos SoC media drivers updates
Hi Mauro,
Please pull the following for 3.9, it includes Exynos SoC drivers cleanups and fixes. DMABUF exporting support for Exynos5 GScaler driver, device tree support for Exynos MFC driver (platform bits for it got merged already for v3.8).
There is also included a patch removing deprecated image centering controls.
The following changes since commit 8cd7085ff460ead3aba6174052a408f4ad52ac36:
[media] get_dvb_firmware: Fix the location of firmware for Terratec HTC
(2013-01-01 11:18:26 -0200)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsung media_for_v3.9
for you to fetch changes up to 36073ee2f7b3b5ae91900cb992b292404614243b:
V4L: Remove deprecated image centering controls (2013-01-04 11:35:43 +0100)
----------------------------------------------------------------
Arun Kumar K (2):
s5p-mfc: Add device tree support
s5p-mfc: Flush DPB buffers during stream off
Kamil Debski (4):
s5p-mfc: Move firmware allocation point to avoid allocation problems
s5p-mfc: Correct check of vb2_dma_contig_init_ctx return value
s5p-mfc: Change internal buffer allocation from vb2 ops to dma_alloc_coherent
s5p-mfc: Context handling in open() bugfix
Sachin Kamat (9):
s5p-tv: Add missing braces around sizeof in sdo_drv.c
s5p-tv: Add missing braces around sizeof in mixer_video.c
s5p-tv: Add missing braces around sizeof in mixer_reg.c
s5p-tv: Add missing braces around sizeof in mixer_drv.c
s5p-tv: Add missing braces around sizeof in hdmiphy_drv.c
s5p-tv: Add missing braces around sizeof in hdmi_drv.c
s5p-mfc: Remove redundant 'break'
s5p-mfc: Fix a typo in error message in s5p_mfc_pm.c
s5p-mfc: Fix an error check
Shaik Ameer Basha (1):
exynos-gsc: Support dmabuf export buffer
Sylwester Nawrocki (5):
s5p-fimc: Avoid possible NULL pointer dereference in set_fmt op
s5p-fimc: Prevent potential buffer overflow
s5p-fimc: Prevent AB-BA deadlock during links reconfiguration
s5p-tv: Fix return value in sdo_probe() on error paths
V4L: Remove deprecated image centering controls
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling of VIDIOC_S_FMT
Tony Prisk (3):
s5p-fimc: Fix incorrect usage of IS_ERR_OR_NULL
s5p-tv: Fix incorrect usage of IS_ERR_OR_NULL
s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Wei Yongjun (1):
s5p-mfc: remove unused variable
Documentation/DocBook/media/v4l/controls.xml | 23 --- drivers/media/platform/exynos-gsc/gsc-m2m.c | 12 +- drivers/media/platform/s5p-fimc/fimc-capture.c | 58 +++++-- drivers/media/platform/s5p-fimc/fimc-lite.c | 6 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 100 +++++------- drivers/media/platform/s5p-g2d/g2d.c | 4 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 148 ++++++++++++----- drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 31 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 149 ++++++++--------- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h | 3 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 15 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 30 ++++ drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 5 + drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 197 ++++++++--------------- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 148 ++++++----------- drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 2 +- drivers/media/platform/s5p-tv/hdmi_drv.c | 18 +-- drivers/media/platform/s5p-tv/hdmiphy_drv.c | 2 +- drivers/media/platform/s5p-tv/mixer_drv.c | 14 +- drivers/media/platform/s5p-tv/mixer_reg.c | 6 +- drivers/media/platform/s5p-tv/mixer_video.c | 22 +-- drivers/media/platform/s5p-tv/sdo_drv.c | 29 ++-- drivers/media/v4l2-core/v4l2-ctrls.c | 2 - include/uapi/linux/v4l2-controls.h | 4 - 24 files changed, 503 insertions(+), 525 deletions(-)
Regards,
Signature · 2 lines
Sylwester Nawrocki Samsung Poland R&D Center
Quoted 56 lines · Sylwester Nawrocki
Hi Mauro,
Please pull the following for 3.9, it includes Exynos SoC drivers cleanups and fixes. DMABUF exporting support for Exynos5 GScaler driver, device tree support for Exynos MFC driver (platform bits for it got merged already for v3.8).
There is also included a patch removing deprecated image centering controls.
The following changes since commit
8cd7085ff460ead3aba6174052a408f4ad52ac36:[media]
get_dvb_firmware: Fix the location of firmware for Terratec HTC
(2013-01-01 11:18:26 -0200)are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsungmedia_for_v3.9for you to fetch changes up to
36073ee2f7b3b5ae91900cb992b292404614243b:V4L: Remove deprecated image centering controls (2013-01-04 11:35:43 +0100)----------------------------------------------------------------
Arun Kumar K (2):
s5p-mfc: Add device tree support
s5p-mfc: Flush DPB buffers during stream offKamil Debski (4):
s5p-mfc: Move firmware allocation point to avoid allocation problems
s5p-mfc: Correct check ofvb2_dma_contig_init_ctxreturn value
s5p-mfc: Change internal buffer allocation from vb2 ops todma_alloc_coherent
s5p-mfc: Context handling inopen()bugfixSachin Kamat (9):
s5p-tv: Add missing braces around sizeof insdo_drv.c
s5p-tv: Add missing braces around sizeof inmixer_video.c
s5p-tv: Add missing braces around sizeof inmixer_reg.c
s5p-tv: Add missing braces around sizeof inmixer_drv.c
s5p-tv: Add missing braces around sizeof inhdmiphy_drv.c
s5p-tv: Add missing braces around sizeof inhdmi_drv.c
s5p-mfc: Remove redundant 'break'
s5p-mfc: Fix a typo in error message ins5p_mfc_pm.c
s5p-mfc: Fix an error checkShaik Ameer Basha (1):
exynos-gsc: Support dmabuf export bufferSylwester Nawrocki (5):
s5p-fimc: Avoid possible NULL pointer dereference inset_fmtop
s5p-fimc: Prevent potential buffer overflow
s5p-fimc: Prevent AB-BA deadlock during links reconfiguration
s5p-tv: Fix return value insdo_probe()on error paths
V4L: Remove deprecated image centering controlsTomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMT
Quoted 7 lines
Tony Prisk (3):
s5p-fimc: Fix incorrect usage ofIS_ERR_OR_NULL
s5p-tv: Fix incorrect usage ofIS_ERR_OR_NULL
s5p-g2d: Fix incorrect usage ofIS_ERR_OR_NULLWei Yongjun (1):
s5p-mfc: remove unused variable
Related patchwork commands:
pwclient update -s 'accepted' 15333 pwclient update -s 'accepted' 15565 pwclient update -s 'accepted' 16071 pwclient update -s 'accepted' 16072 pwclient update -s 'accepted' 16073 pwclient update -s 'accepted' 15657 pwclient update -s 'accepted' 15656 pwclient update -s 'accepted' 15658 pwclient update -s 'accepted' 15659 pwclient update -s 'accepted' 15660 pwclient update -s 'accepted' 15661 pwclient update -s 'accepted' 16013 pwclient update -s 'superseded' 16059 pwclient update -s 'accepted' 16060 pwclient update -s 'accepted' 16080 pwclient update -s 'accepted' 16081 pwclient update -s 'accepted' 16084 pwclient update -s 'accepted' 15647 pwclient update -s 'superseded' 16083 pwclient update -s 'accepted' 15765
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki <[email protected]> escreveu:
Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMT
I'll drop this one for now. Devin raised a point: such changes would break existing applications.
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMT
So, its status update may be wrong after flushing your pwclient commands.
Regards,
Mauro
Quoted 10 lines · Mauro Carvalho Chehab
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki<[email protected]> escreveu:Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request. I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in VIDIOC_S_FMT indicating that format has been modified and is valid, when -EINVAL was returned. This sounds ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc, or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.
Regards,
Sylwester
Em Sun, 06 Jan 2013 13:34:53 +0100
Sylwester Nawrocki <[email protected]> escreveu:
Quoted 25 lines · Mauro Carvalho Chehab
Quoted 10 lines
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki<[email protected]> escreveu:Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request.
I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143
Quoted 12 lines
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in
VIDIOC_S_FMTindicating that format has been modified and is valid, when-EINVALwas returned. This sounds
ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc,
or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.
The patch makes the driver compliant to v4l-compilance, as its behavior asks for such change, after some discussions we had this year in San Diego. At that time, we all believed that such change were safe.
However, we can't do it like proposed there (and on other patches from Hans).
The fact is that tvtime and mythtv applications (maybe more) will fail if the returned format is different than the requested ones, as they don't check for the returned value.
As no regressions on userspace are allowed, we need to re-discuss this issue.
While this doesn't happen, I'll postpone such patches.
Comments/suggestions are welcome.
Regards,
Mauro
Quoted 47 lines · On Sun January 6 2013 13:41:57 Mauro Carvalho Chehab wrote:
Em Sun, 06 Jan 2013 13:34:53 +0100
Sylwester Nawrocki <[email protected]> escreveu:Quoted 25 lines · Mauro Carvalho Chehab
Quoted 10 lines
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki<[email protected]> escreveu:Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request.
I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143Quoted 12 lines
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in
VIDIOC_S_FMTindicating that format has been modified and is valid, when-EINVALwas returned. This sounds
ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc,
or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.The patch makes the driver compliant to v4l-compilance, as its behavior asks for such change, after some discussions we had this year in San Diego. At that time, we all believed that such change were safe.
However, we can't do it like proposed there (and on other patches from Hans).
Quoted 7 lines
The fact is that tvtime and mythtv applications (maybe more) will fail if the returned format is different than the requested ones, as they don't check for the returned value.
As no regressions on userspace are allowed, we need to re-discuss this issue.
While this doesn't happen, I'll postpone such patches.
This is a video output device. So this patch will never affect tvtime/mythtv/etc. I have no problem with this change being merged.
Regards,
Hans
Em Sun, 6 Jan 2013 13:53:52 +0100
Hans Verkuil <[email protected]> escreveu:
Quoted 52 lines · On Sun January 6 2013 13:41:57 Mauro Carvalho Chehab wrote:
Quoted 51 lines
Em Sun, 06 Jan 2013 13:34:53 +0100
Sylwester Nawrocki <[email protected]> escreveu:Quoted 25 lines · Mauro Carvalho Chehab
Quoted 10 lines
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki<[email protected]> escreveu:Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request.
I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143Quoted 12 lines
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in
VIDIOC_S_FMTindicating that format has been modified and is valid, when-EINVALwas returned. This sounds
ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc,
or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.The patch makes the driver compliant to v4l-compilance, as its behavior asks for such change, after some discussions we had this year in San Diego. At that time, we all believed that such change were safe.
However, we can't do it like proposed there (and on other patches from Hans).
The fact is that tvtime and mythtv applications (maybe more) will fail if the returned format is different than the requested ones, as they don't check for the returned value.
Quoted 6 lines
Quoted 3 lines
As no regressions on userspace are allowed, we need to re-discuss this issue.
While this doesn't happen, I'll postpone such patches.
This is a video output device. So this patch will never affect tvtime/mythtv/etc. I have no problem with this change being merged.
Ok. still, we need to double-check what happens on video output apps. I'll keep it on hold for a while, tagged as "under review" at Sylwester's umbrella.
Regards,
Mauro
Quoted 43 lines · Hans Verkuil
Quoted 43 lines
Quoted 20 lines
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request.
I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143Quoted 12 lines
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in
VIDIOC_S_FMTindicating that format has been modified and is valid, when-EINVALwas returned. This sounds
ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc,
or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.The patch makes the driver compliant to v4l-compilance, as its behavior asks for such change, after some discussions we had this year in San Diego. At that time, we all believed that such change were safe.
However, we can't do it like proposed there (and on other patches from Hans).
The fact is that tvtime and mythtv applications (maybe more) will fail if the returned format is different than the requested ones, as they don't check for the returned value.
Quoted 6 lines
Quoted 3 lines
As no regressions on userspace are allowed, we need to re-discuss this issue.
While this doesn't happen, I'll postpone such patches.
This is a video output device. So this patch will never affect tvtime/mythtv/etc. I have no problem with this change being merged.
TBH, I very much doubt anyone would complain in case of this driver. I'm not certain if there is complete support for even one board in the mainline kernel, likely only Origen A. AFAIK most applications use either Exynos DRM driver, that has support for all features available in s5p-tv driver, or framebuffer emulation on top of v4l2 output interface (there were in the past RFC patches posted for vb2 adding FB emulation) is used. Although I agree with Mauro in principle, I think chances of above patch causing any trouble to anyone are close to zero.
--
Regards,
Sylwester
Em Sun, 06 Jan 2013 14:15:44 +0100
Sylwester Nawrocki <[email protected]> escreveu:
Quoted 51 lines · Hans Verkuil
Quoted 43 lines
Quoted 43 lines
Quoted 20 lines
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Tomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTI'll drop this one for now. Devin raised a point: such changes would break existing applications.
Quoted 6 lines
So, we'll need to revisit this topic before changing the drivers.
Btw, I failed to find the corresponding patch at patchwork:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=VIDIOC_S_FMTSo, its status update may be wrong after flushing your pwclient commands.
Hmm, I got this patch from Tomasz by e-mail and added it to the pull request.
I think it wasn't sent to the mailing list, but I noticed it only after sending you the pull requests, when was preparing the pwclient commands. I've just posted it now, sorry. The link is here:
http://patchwork.linuxtv.org/patch/16143Quoted 12 lines
Tomasz created this patch specifically for the purpose of format negotiation in video pipeline in the application we used to test various scenarios with DMABUF. I agree this patch has a potential of breaking buggy user space applications. I can't see other solution for it right now, there seems even to be no possibility to return some flag in
VIDIOC_S_FMTindicating that format has been modified and is valid, when-EINVALwas returned. This sounds
ugly anyway, but could ensure backward compatibility for applications that exppect EINVAL when format has been changed. BTW, I wonder if it is only fourcc,
or other format parameters as well - like width, height, some applications expect to get EINVAL when those have changed.The patch makes the driver compliant to v4l-compilance, as its behavior asks for such change, after some discussions we had this year in San Diego. At that time, we all believed that such change were safe.
However, we can't do it like proposed there (and on other patches from Hans).
The fact is that tvtime and mythtv applications (maybe more) will fail if the returned format is different than the requested ones, as they don't check for the returned value.
Quoted 6 lines
Quoted 3 lines
As no regressions on userspace are allowed, we need to re-discuss this issue.
While this doesn't happen, I'll postpone such patches.
This is a video output device. So this patch will never affect tvtime/mythtv/etc. I have no problem with this change being merged.
Quoted 11 lines
TBH, I very much doubt anyone would complain in case of this driver. I'm not certain if there is complete support for even one board in the mainline kernel,
likely only Origen A. AFAIK most applications use either Exynos DRM driver, that has support for all features available in s5p-tv driver, or framebuffer
emulation on top of v4l2 output interface (there were in the past RFC patches
posted for vb2 adding FB emulation) is used. Although I agree with Mauro in principle, I think chances of above patch causing any trouble to anyone are close to zero.
Yes, I see your point. Yet, it doesn't hurt to keep it on hold for a couple weeks while we discuss it at the ML.
Regards,
Mauro
Em Fri, 04 Jan 2013 23:39:12 +0100
Sylwester Nawrocki <[email protected]> escreveu:
Quoted 79 lines · Sylwester Nawrocki
Quoted 56 lines
Hi Mauro,
Please pull the following for 3.9, it includes Exynos SoC drivers cleanups and fixes. DMABUF exporting support for Exynos5 GScaler driver, device tree support for Exynos MFC driver (platform bits for it got merged already for v3.8).
There is also included a patch removing deprecated image centering controls.
The following changes since commit
8cd7085ff460ead3aba6174052a408f4ad52ac36:[media]
get_dvb_firmware: Fix the location of firmware for Terratec HTC
(2013-01-01 11:18:26 -0200)are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsungmedia_for_v3.9for you to fetch changes up to
36073ee2f7b3b5ae91900cb992b292404614243b:V4L: Remove deprecated image centering controls (2013-01-04 11:35:43 +0100)----------------------------------------------------------------
Arun Kumar K (2):
s5p-mfc: Add device tree support
s5p-mfc: Flush DPB buffers during stream offKamil Debski (4):
s5p-mfc: Move firmware allocation point to avoid allocation problems
s5p-mfc: Correct check ofvb2_dma_contig_init_ctxreturn value
s5p-mfc: Change internal buffer allocation from vb2 ops todma_alloc_coherent
s5p-mfc: Context handling inopen()bugfixSachin Kamat (9):
s5p-tv: Add missing braces around sizeof insdo_drv.c
s5p-tv: Add missing braces around sizeof inmixer_video.c
s5p-tv: Add missing braces around sizeof inmixer_reg.c
s5p-tv: Add missing braces around sizeof inmixer_drv.c
s5p-tv: Add missing braces around sizeof inhdmiphy_drv.c
s5p-tv: Add missing braces around sizeof inhdmi_drv.c
s5p-mfc: Remove redundant 'break'
s5p-mfc: Fix a typo in error message ins5p_mfc_pm.c
s5p-mfc: Fix an error checkShaik Ameer Basha (1):
exynos-gsc: Support dmabuf export bufferSylwester Nawrocki (5):
s5p-fimc: Avoid possible NULL pointer dereference inset_fmtop
s5p-fimc: Prevent potential buffer overflow
s5p-fimc: Prevent AB-BA deadlock during links reconfiguration
s5p-tv: Fix return value insdo_probe()on error paths
V4L: Remove deprecated image centering controlsTomasz Stanislawski (1):
s5p-tv: mixer: fix handling ofVIDIOC_S_FMTQuoted 7 lines
Tony Prisk (3):
s5p-fimc: Fix incorrect usage ofIS_ERR_OR_NULL
s5p-tv: Fix incorrect usage ofIS_ERR_OR_NULL
s5p-g2d: Fix incorrect usage ofIS_ERR_OR_NULLWei Yongjun (1):
s5p-mfc: remove unused variableRelated patchwork commands:
pwclient update -s 'accepted' 15333 pwclient update -s 'accepted' 15565 pwclient update -s 'accepted' 16071 pwclient update -s 'accepted' 16072 pwclient update -s 'accepted' 16073 pwclient update -s 'accepted' 15657 pwclient update -s 'accepted' 15656 pwclient update -s 'accepted' 15658 pwclient update -s 'accepted' 15659 pwclient update -s 'accepted' 15660 pwclient update -s 'accepted' 15661 pwclient update -s 'accepted' 16013
Quoted 8 lines
pwclient update -s 'superseded' 16059 pwclient update -s 'accepted' 16060 pwclient update -s 'accepted' 16080 pwclient update -s 'accepted' 16081 pwclient update -s 'accepted' 16084 pwclient update -s 'accepted' 15647 pwclient update -s 'superseded' 16083 pwclient update -s 'accepted' 15765
Those status updates were missing:
pwclient update -s 'superseded' 14608 pwclient update -s 'superseded' 15188 pwclient update -s 'accepted' 16058 pwclient update -s 'accepted' 16108
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Cheers, Mauro
Quoted 23 lines · Mauro Carvalho Chehab
Quoted 14 lines
Related patchwork commands:
pwclient update -s 'accepted' 15333 pwclient update -s 'accepted' 15565 pwclient update -s 'accepted' 16071 pwclient update -s 'accepted' 16072 pwclient update -s 'accepted' 16073 pwclient update -s 'accepted' 15657 pwclient update -s 'accepted' 15656 pwclient update -s 'accepted' 15658 pwclient update -s 'accepted' 15659 pwclient update -s 'accepted' 15660 pwclient update -s 'accepted' 15661 pwclient update -s 'accepted' 16013
Quoted 8 lines
pwclient update -s 'superseded' 16059 pwclient update -s 'accepted' 16060 pwclient update -s 'accepted' 16080 pwclient update -s 'accepted' 16081 pwclient update -s 'accepted' 16084 pwclient update -s 'accepted' 15647 pwclient update -s 'superseded' 16083 pwclient update -s 'accepted' 15765
Quoted 5 lines
Those status updates were missing:
pwclient update -s 'superseded' 14608
pwclient update -s 'superseded' 15188
pwclient update -s 'accepted' 16058
OK, sorry. Just learning to use the tools, will try to do better next time. :)
Quoted 1 line
pwclient update -s 'accepted' 16108
And that's the pull request itself, I've obviously missed it.
--
Thanks,
Sylwester
Em Sun, 06 Jan 2013 13:58:59 +0100
Sylwester Nawrocki <[email protected]> escreveu:
Quoted 24 lines · Mauro Carvalho Chehab
Quoted 23 lines
Quoted 22 lines
Related patchwork commands:
pwclient update -s 'accepted' 15333 pwclient update -s 'accepted' 15565 pwclient update -s 'accepted' 16071 pwclient update -s 'accepted' 16072 pwclient update -s 'accepted' 16073 pwclient update -s 'accepted' 15657 pwclient update -s 'accepted' 15656 pwclient update -s 'accepted' 15658 pwclient update -s 'accepted' 15659 pwclient update -s 'accepted' 15660 pwclient update -s 'accepted' 15661 pwclient update -s 'accepted' 16013 pwclient update -s 'superseded' 16059 pwclient update -s 'accepted' 16060 pwclient update -s 'accepted' 16080 pwclient update -s 'accepted' 16081 pwclient update -s 'accepted' 16084 pwclient update -s 'accepted' 15647 pwclient update -s 'superseded' 16083 pwclient update -s 'accepted' 15765
Quoted 8 lines
Quoted 5 lines
Those status updates were missing:
pwclient update -s 'superseded' 14608
pwclient update -s 'superseded' 15188
pwclient update -s 'accepted' 16058OK, sorry. Just learning to use the tools, will try to do better next time. :)
No problem.
Quoted 3 lines
Quoted 1 line
pwclient update -s 'accepted' 16108
And that's the pull request itself, I've obviously missed it.
Yeah ;) Well, you shouldn't include it. Sorry to add it at the list.
Regards,
Mauro