Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 7月, 2016 3 次提交
    • H
      [media] adv7604/adv7842: fix quantization range handling · fd74246d
      由 Hans Verkuil 提交于 
      Fix a number of bugs that appeared when support for mediabus formats was
added:

- Support for V4L2_DV_RGB_RANGE_FULL/LIMITED should only be enabled
  for HDMI RGB formats, not for YCbCr formats. Since, as the name
  says, this setting is for RGB only. So read the InfoFrame to check
  the format.

- the quantization range for the pixelport depends on whether the
  mediabus code is RGB or not: if it is RGB, then produce full range
  RGB values, otherwise produce limited range YCbCr values.

  This means that the op_656_range and alt_data_sat fields of the
  platform data are no longer used and these will be removed in a
  following patch.

- when setting up a new format the RGB quantization range settings
  were never updated. Do so, since this depends on the format.

- fix the log_status output which was confusing and incorrect.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      fd74246d
    • H
      [media] adv7511: fix quantization range handling · 0a25a012
      由 Hans Verkuil 提交于 
      Commit 1fb69bfd (adv7511: improve
colorspace handling) introduced a number of bugs, specifically with
regards to YCbCr output and quantization range handling:

- if the output is not RGB, then disable the full-to-limited range
  CSC matrix since that is meant for RGB formats. YCbCr formats are
  always limited range, so there is nothing to convert. (OK, full
  range YCbCr is possible, but we don't support that right now).

- the mediabus code that was passed to adv7511_set_fmt was always cleared
  by the memset in adv7511_fill_format. This made it effectively impossible
  to select YCbCr output.

- adv7511_set_fmt never updated the rgb quantization range.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      0a25a012
    • H
      [media] adv7511: drop adv7511_set_IT_content_AVI_InfoFrame · afd620f8
      由 Hans Verkuil 提交于 
      The IT Content bit has nothing to do with CE vs IT timings.
Delete this code. This will also fix a bug where this could
override the 'content type' control, which is actually the
correct place to set/clear the ITC bit.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      afd620f8
  3. 12 7月, 2016 1 次提交
  5. 09 7月, 2016 4 次提交
  7. 28 6月, 2016 11 次提交
  9. 24 6月, 2016 1 次提交
  11. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      由 Arnd Bergmann 提交于 
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  13. 10 5月, 2016 2 次提交
  15. 07 5月, 2016 4 次提交
  17. 06 5月, 2016 1 次提交
  19. 25 4月, 2016 3 次提交
  21. 21 4月, 2016 4 次提交
  23. 14 4月, 2016 1 次提交
  25. 03 3月, 2016 1 次提交
  27. 27 2月, 2016 1 次提交
  29. 23 2月, 2016 1 次提交
  31. 19 2月, 2016 1 次提交