Hi Dan,
On 04.04.2019 17:42, Dan Carpenter wrote:
> Hello Andrzej Hajda,
>
> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
> identify last buffers in decoder capture queue" from Oct 7, 2015,
> leads to the following static checker warning:
>
>
On 25.01.2018 13:25, Dan Carpenter wrote:
> On Thu, Jan 25, 2018 at 10:58:45AM +0100, Andrzej Hajda wrote:
>> On 23.01.2018 09:32, Dan Carpenter wrote:
>>> Hello Andrzej Hajda,
>>>
>>> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
>
On 23.01.2018 09:32, Dan Carpenter wrote:
> Hello Andrzej Hajda,
>
> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
> identify last buffers in decoder capture queue" from Oct 7, 2015,
> leads to the following static checker warning:
>
>
On 06.10.2017 23:30, Shuah Khan wrote:
> Driver calls request_firmware() whenever the device is opened for the
> first time. As the device gets opened and closed, dev->num_inst == 1
> is true several times. This is not necessary since the firmware is saved
> in the fw_buf. s5p_mfc_load_firmware() c
Hi Shuah,
On 06.10.2017 23:30, Shuah Khan wrote:
> Check if firmware is allocated before requesting firmware instead of
> requesting firmware only to release it if firmware is not allocated.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
> 1
On 01.11.2017 22:05, Mauro Carvalho Chehab wrote:
> As warned by smatch:
> drivers/media/i2c/s5c73m3/s5c73m3-core.c:268 s5c73m3_check_status()
> error: uninitialized symbol 'status'.
>
> if s5c73m3_check_status() is called too late, time_is_after_jiffies(end)
> will return 0, causing the whi
On 09.10.2017 10:44, Sean Young wrote:
> Hi,
>
> On Thu, Sep 21, 2017 at 12:46:04PM +0100, Sean Young wrote:
>> On Mon, Sep 18, 2017 at 04:37:52PM +0200, Hans Verkuil wrote:
>>> On 09/18/2017 04:15 PM, Maciej Purski wrote:
Hi Hans,
some time ago in reply to your email I described what mes
On 03.08.2017 10:28, Hans Verkuil wrote:
> Hi Maciej,
>
> Unfortunately I do not have the MHL spec, but I was wondering what the
> relationship between RCP and CEC is. CEC has remote control support as
> well, so is RCP that subset of the CEC specification or is it completely
> separate?
We also d
and after the code change:
>
> before:
>textdata bss dec hex filename
> 277655656 320 3374183cd drivers/media/i2c/s5k5baf.o
>
> after:
>textdata bss dec hex filename
> 277335600 256 335898335 drivers/media/i
On 30.05.2017 08:53, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
>
> https://hverkuil.home.xs4all.nl/cec-status.txt
>
> My goal is to get CEC supported for any mainlined HDMI driver where the
> hardware
r
> Acked-by: Krzysztof Kozlowski
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/
On 31.03.2017 11:06, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 28 +-
> drivers/media/platform/s5p-mfc/s5p_mfc.c| 1 +
>
On 31.03.2017 11:06, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
d definitions
> * Update computation of min scratch buffer size requirement for V8 onwards
>
> Changes since v2:
> - Addressed review comments by Andrzej Hajda.
> - Rebased on latest krzk/for-next tree.
> - This patches are tested on top of Marek's patch v2 [1]
> - Applied ack
Hi Smitha,
Sorry for late reply, it seems I have missed this email.
On 14.03.2017 12:41, Smitha T Murthy wrote:
> On Tue, 2017-03-07 at 12:33 +0100, Andrzej Hajda wrote:
>> On 03.03.2017 10:07, Smitha T Murthy wrote:
>>> Add HEVC encoder support and necessary registers, V4L2
Hi Marian,
On 15.03.2017 12:36, Marian Mihailescu wrote:
> Hi,
>
> After testing these patches, encoding using MFC fails when requesting
> buffers for capture (it works for output) with ENOMEM (it complains it
> cannot allocate memory on bank1).
> Did anyone else test encoding?
I have tested enc
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Added V4l2 controls for HEVC encoder
It should be rather "Document controls for HEVC encoder" or sth similar.
In general most of comments are in previous patch.
Few additional comments:
- please be careful about control names - they are exported to u
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 28 +-
> drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
> ---
> Documentation/media/uapi/v4l/pixfmt-013.rst |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
ID_MPEG_VIDEO_HEVC_WITHOUT_STARTCODE_ENABLE: return "HEVC
> ENC without startcode enable";
> + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_PERIOD: return "HEVC
> Number of reference picture";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_BETA_OFFSET_DIV2: re
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 19 +
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 99
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> include/uapi/linux/videodev2.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-
.
>
> Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
On 03.03.2017 10:07, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
Few nitpicks below.
> CC: Rob Herring
On 01.03.2017 16:21, Nicolas Dufresne wrote:
> Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
>> - on output side you have encoded bytestream - you cannot say about
>> interlacing in such case, so the only valid value is NONE,
>> - on capture side you have d
On 01.03.2017 12:51, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver, default to NONE in case any is provided, but we can basically
> accept any value provided by the userspace as we will anyway not
> be able to do any deinterlacing.
>
> In this
On 21.02.2017 20:20, Thibault Saunier wrote:
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
> didn't set the colorimetry when userspace provided
> V4L2_COLORSPACE_DEFAULT.
>
> Use 576p display
On 22.02.2017 14:10, Thibault Saunier wrote:
> Hello,
>
> On 02/22/2017 06:29 AM, Andrzej Hajda wrote:
>> On 21.02.2017 20:20, Thibault Saunier wrote:
>>> It is required by the standard that the field order is set by the
>>> driver.
>&g
On 21.02.2017 20:20, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier
>
> ---
>
> Changes in v5:
> - Just adapt the field and never error out.
>
> Changes in v4: None
> Changes in v3:
> - Do not check values i
e patchset:
Acked-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc.c| 21 -
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 13 -
> drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h | 1 -
> 3 files
On 13.02.2017 20:08, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous
> review
On 13.02.2017 20:08, Thibault Saunier wrote:
> User userspace provided by the user as we are only doing scaling and
> color encoding conversion, we won't be able to transform the colorspace
> itself and the colorspace won't mater in that operation.
>
> Also always use output colorspace on the captu
, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas
> Signed-off-by: Thibault Saunier
> Reviewed-by: An
On 09.02.2017 23:10, Shuah Khan wrote:
> Fix s5p_mfc_set_dec_frame_buffer_v6() to print buffer size in hex to be
> consistent with the rest of the messages in the routine.
>
> Signed-off-by: Shuah Khan
As Nicolas said please fix the subject.
After this you can add my:
Acked-by: A
On 09.02.2017 23:11, Shuah Khan wrote:
> Remove unneeded io_modes initialzation in s5p_mfc_open(). It gets done
> right below in vdev == dev->vfd_dec conditional.
>
> Signed-off-by: Shuah Khan
Acked-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/media/platform/s5p-mfc
On 09.02.2017 21:04, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
>
On 09.02.2017 21:04, Thibault Saunier wrote:
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
> didn't set the colorimetry, also respect usespace setting.
>
> Use 576p display resolution as a th
On 09.02.2017 21:04, Thibault Saunier wrote:
> If the colorspace is specified by userspace we should respect
> it and not reset it ourself if we can support it.
>
> Signed-off-by: Thibault Saunier
> ---
> drivers/media/platform/exynos-gsc/gsc-core.c | 25 +
> 1 file change
), so change the driver logic to be aligned with this.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/me
ccess device or context queue in error handling path, which
> might not be initialized yet, what causes kernel panic. Fix this by moving
> initialization of all static members as early as possible.
>
> Signed-off-by: Marek Szyprowski
Acked-by: Andrzej Hajda
--
To unsubscribe from
Hi Smitha,
I have no big experience with HEVC, so it is hard to review it
appropriately but I will try do my best.
As these control names goes to user space you should be very careful
about it.
I guess it could be good to compare these controls with other HEVC
encoders including software ones (ffm
gt; Signed-off-by: Hans Verkuil
> Tested-by: Marek Szyprowski
For patches 1-6:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
--
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
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 28 +-
> drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
c
> index b6cb280..da4202f 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -227,6 +227,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx-&
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy
Beside small nitpick.
Reviewed-by: Andrzej Hajda
> ---
> include/uapi/linux/videodev2.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-
Hi Smitha,
Ups, I have missed this patch, I hope it wont influence the review :)
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs
On 02.02.2017 08:58, Andrzej Hajda wrote:
> On 18.01.2017 11:02, Smitha T Murthy wrote:
>> Add support for codec definition and corresponding buffer
>> requirements for HEVC decoder.
>>
>> Signed-off-by: Smitha T Murthy
>> ---
>> drivers/media/p
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for HEVC decoder.
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h |3 +++
> drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3
On 18.01.2017 11:02, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.
Subject says
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> CC: Rob Herring
> CC: devicet...@vger.kernel.org
> Signed-off-by: Smitha T Murthy
> ---
> .../devicetree/bindings/medi
On 18.01.2017 11:01, Smitha T Murthy wrote:
> This patch renames macro IS_MFCV8 to IS_MFCV8_PLUS so that the MFCv8
> code can be resued for MFCv10.10 support. Since the MFCv8 specific code
> holds good for MFC v10.10 also.
>
> Signed-off-by: Smitha T Murthy
Acked-by: Andrzej Ha
Hi Smitha,
On 18.01.2017 10:37, Smitha T Murthy wrote:
> >From MFCv6 onwards encoder stream buffer and decoder CPB buffer
Unexpected char at the beginning.
> need to be aligned with 512.
Patch below adds checks only if buffer size is multiple of 512, am I right?
If yes, please precise the subje
Bool values should be negated using logical operators. Using bitwise operators
results in unexpected and possibly incorrect results.
Reported-by: David Binderman
Signed-off-by: Andrzej Hajda
---
drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 03.01.2017 09:11, Hans Verkuil wrote:
> On 01/03/2017 09:00 AM, Andrzej Hajda wrote:
>> Is there a reason to split registration into two steps?
>> Wouldn't be better to integrate hpd_notifier_get into
>> cec_register_hpd_notifier.
> One problem is that hpd_n
On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil
>
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
>
> Update
On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Implement the HPD notifier support to allow CEC drivers to
> be informed when there is a new EDID and when a connect or
> disconnect happens.
>
> Signed-off-by: Hans Verkuil
> Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/e
Hi Hans,
On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patc
Hi,
On 08/27/2016 11:55 AM, Randy Li wrote:
> Hi:
>
>I have been reported that the setting the profile, level and bitrate
> through the v4l2 extra controls would not make the encoded result
> different. I tried it recently, it is true. Although the h264 parser
> would tell me the result hav
Code for queue cleanup has nothing specific to hardware version.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc.c| 26 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 1 +
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 6
Andrzej
Andrzej Hajda (6):
s5p-mfc: use one implementation of s5p_mfc_get_new_ctx
s5p-mfc: make queue cleanup code common
s5p-mfc: remove unnecessary callbacks
s5p-mfc: use spinlock to protect MFC context
s5p-mfc: merge together s5p_mfc_hw_call and s5p_mfc_hw_call_void
s5p-mfc: remove
Both version of MFC driver uses functions with the same body and name.
The patch moves them to common location. It also simplifies it.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc.c| 20
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 1
Both macros can be merged into one.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc.c| 38 -
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 8 +-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 16 +--
drivers/media
MFC register addresses are used only by writel/readl macros which already
takes care of proper register accessing.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 488 +--
1 file changed, 244 insertions(+), 244 deletions(-)
diff --git a
Many version specific functions are not called by common code, so there
is no need to use callbacks. Additionally some of them are not used at all,
so they can be safely removed.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 17 -
drivers/media
MFC driver uses dev->irqlock spinlock to protect queues only, but many context
fields requires protection also - they can be accessed concurrently
from IOCTLs and IRQ handler. The patch increases protection range of irqlock
to those fields also.
Signed-off-by: Andrzej Hajda
---
drivers/me
On 11/10/2015 09:53 AM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Tuesday 10 November 2015 07:48:54 Andrzej Hajda wrote:
>> On 11/09/2015 09:16 PM, Laurent Pinchart wrote:
>>> On Thursday 24 September 2015 16:00:12 Andrzej Hajda wrote:
>>>> The function can
On 11/09/2015 09:16 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday 24 September 2015 16:00:12 Andrzej Hajda wrote:
>> The function can return negative value.
>>
>> The problem has been detected using proposed semantic
MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.
Signed-off-by: Andrzej Hajda
---
Hi Kamil,
Incorrect format fixed.
Regards
Andrzej
---
drivers/media/platform/s5p-mfc/s5p_mfc.c
MFC driver never delivered EOS event to apps feeding constantly its capture
buffer with fresh buffers. The patch fixes it by marking last buffers
returned by MFC with MFC_BUF_FLAG_EOS flag and firing EOS event on
de-queuing such buffers.
Signed-off-by: Andrzej Hajda
---
Hi Kamil,
Commit message
MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.
Signed-off-by: Andrzej Hajda
---
Hi,
This version is rebased on latest media_tree branch.
Regards
Andrzej
---
drivers/media
MFC driver never delivered EOS event to apps feeding constantly its capture
buffer with fresh buffers. The patch fixes it by marking last buffers returned
by MFC with MFC_BUF_FLAG_EOS flag and firing EOS event on de-queuing such
buffers.
Signed-off-by: Andrzej Hajda
---
Hi,
This version is
MFC driver never delivered EOS event to apps feeding constantly its capture
buffer with fresh buffers. The patch fixes it by marking last buffers returned
by MFC with MFC_BUF_FLAG_EOS flag and firing EOS event on de-queuing such
buffers.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform
MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.
Signed-off-by: Andrzej Hajda
---
drivers/media/platform/s5p-mfc/s5p_mfc.c| 25
drivers/media/platform/s5p
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
---
Hi,
To avoid problems with too many
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
---
Hi,
To avoid problems with too many
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
---
Hi,
To avoid problems with too many
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
---
Hi,
To avoid problems with too many
On 09/21/2015 03:42 PM, David Howells wrote:
> Andrzej Hajda wrote:
>
>> Semantic patch finds comparisons of types:
>> unsigned < 0
>> unsigned >= 0
>> The former is always false, the latter is always true.
>> Such comparisons are useless, so the
The variable can take negative values.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda
---
drivers/staging/media/davinci_vpfe
On 09/11/2015 03:19 AM, Javier Martinez Canillas wrote:
> Hello,
>
> On 08/20/2015 09:07 AM, Javier Martinez Canillas wrote:
>> The SPI core always reports the MODALIAS uevent as "spi:"
>> regardless of the mechanism that was used to register the device
>> (i.e: OF or board code) and the table that
gt; @@ -31,6 +31,7 @@ static const struct of_device_id s5c73m3_spi_ids[] = {
>> { .compatible = "samsung,s5c73m3" },
>> { }
>> };
>> +MODULE_DEVICE_TABLE(of, s5c73m3_spi_ids;);
>>
>> enum spi_direction {
>> SPI_DIR_RX,
>>
>
Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match
compatible ioctls on ARM64 kernels without breaking AMD64 some fields
should be aligned using compat_s64 type and in one case struct should be
unpacked.
Signed-off-by: Andrzej Hajda
---
Hi Hans,
I have tested following
retain 4 bytes
alignment on x86 architecture.
Signed-off-by: Andrzej Hajda
---
Hi Hans,
Tested successfully on arm32 app / arm64 kernel.
Thanks for help.
Regards
Andrzej
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core
Union v4l2_event::u is aligned to 8 bytes on arm32. On arm64 v4l2_event32::u
is aligned to 4 bytes. As a result structures v4l2_event and v4l2_event32 have
different sizes and VIDOC_DQEVENT ioctl does not work from arm32 apps running
on arm64 kernel. The patch fixes it.
Signed-off-by: Andrzej
o encoder to check
> MFCINST_GOT_INST state only for capture buffer from queue_setup.
>
> Signed-off-by: Seung-Woo Kim
Looks OK.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |9 +
> 1 files changed, 5 insertion
eo
> To: Mauro Carvalho Chehab
> To: Kyungmin Park
> To: Andrzej Hajda
> To: linux-media@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
Reviewed-by: Andrzej Hajda
Regards
Andrzej
> ---
> drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 1 -
> 1 file changed, 1 deletion(-)
>
Signed-off-by: Vaishali Thakkar
Reviewed-by: Andrzej Hajda
> ---
> drivers/media/i2c/s5k5baf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> index 297ef04..7a43b55 100644
> --- a/drivers/m
Hi Mauro,
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> This sensor driver is abusing MEDIA_ENT_T_V4L2_SUBDEV, creating
> some subdevs with a non-existing type.
>
> As this is a sensor driver, the proper type is likely
> MEDIA_ENT_T_CAM_SENSOR.
This driver exposes two media entities:
- p
baf_fw_parse(struct device *dev, struct
> s5k5baf_fw **fw,
> count -= S5K5BAG_FW_TAG_LEN;
>
> d = devm_kzalloc(dev, count * sizeof(u16), GFP_KERNEL);
> + if (!d)
> + return -ENOMEM;
>
> for (i = 0; i < count; ++i)
> d[i] =
Hi Philipp,
On 12/22/2014 04:11 PM, Philipp Zabel wrote:
> This patch adds a function to get a port device tree node by port id,
> or reg property value.
>
> Signed-off-by: Philipp Zabel
> Acked-by: Laurent Pinchart
> ---
> drivers/of/base.c| 26 ++
> include/li
On 06/09/2014 01:29 PM, Lars-Peter Clausen wrote:
> On 06/09/2014 01:18 AM, Ben Dooks wrote:
>> On Fri, May 30, 2014 at 08:16:59PM +0200, Lars-Peter Clausen wrote:
>>> On 05/30/2014 07:33 PM, David Daney wrote:
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
> On Fri, May 30, 2014 at 1:3
On 05/01/2014 11:11 AM, Russell King - ARM Linux wrote:
> On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
>> 2. You replace calls of component_add and component_del with calls
>> to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,
>> &speci
Russell King - ARM Linux wrote, On 01.05.2014 00:28:
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
The main problem with component framework is that componentization
significantly changes every driver and changes it in a way which is not
compatible with traditional drivers, so
Hi Greg,
Thanks for comments. I CC Laurent, I hope it could be interesting for
him also.
Greg Kroah-Hartman wrote, On 30.04.2014 17:49:
On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
Generic framework for tracking internal interfaces
exynos_dpi uses connector polling for tracking panel presence,
this solution introduces unnecessary 10s delay before panel activation.
Moreover it is unsafe, module unloading or driver unbinding can
cause system crash. interface_tracker support solves both problems.
Signed-off-by: Andrzej Hajda
Panel is powered off already by connector during drm_panel_remove call.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-ld9040.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-ld9040.c
index 1f1f837..1def4b0
drm_panel framework allows only query for presence of given panel.
It also does not protect panel module from unloading and does not
provide solution for driver unbinding. interface_tracker
should solve both issues.
Signed-off-by: Andrzej Hajda
---
---
drivers/gpu/drm/drm_panel.c | 5
d at least with drm_panel.
Regards
Andrzej
Andrzej Hajda (4):
drivers/base: add interface tracker framework
drm/panel: add interface tracker support
drm/exynos/dpi: add interface tracker support
drm/panel/ld9040: do not power off panel on removal
drivers/base/Makefile
type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound
to.
Signed-off-by: Andrzej Hajda
---
drivers
Hi Tomasz,
On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
> The HDMIPHY (physical interface) is controlled by a single
> bit in a power controller's regiter. It was implemented
> as clock. It was a simple but effective hack.
This power controller register has also bits to control HDMI clock
d
1 - 100 of 226 matches
Mail list logo
