25 Jan, 2014
2 commits
-
Add Video Processing Front End (VPFE) driver for AM43XX family of devices
Driver supports the following:
- Single and Dual instance (i.e am43x-epos and AM437x-GP-EVM)
- V4L2 API using MMAP buffer access based on videobuf2 api
- Asynchronous sensor/decoder sub device registrationSigned-off-by: Benoit Parrot
Signed-off-by: Darren Etheridge -
Add basic OmniVision ov2659 sensor driver
Currently only support 800x600 YUV422: YUYV ordering
Supports media-controller api and asynchonous registrationSigned-off-by: Benoit Parrot
Signed-off-by: Darren Etheridge
21 Jan, 2014
1 commit
-
…ux-kernel/audio-display-linux-feature-tree into ti-linux-3.12.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.12.y* 'audio-display-ti-linux-3.12.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
ARM: dts: am437x-gp-evm remove duplicate tscadc node
v4l: ti-vpe: Add crop support in VPE driver
v4l: ti-vpe: Fix some params in VPE data descriptors
v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufsSigned-off-by: Dan Murphy <dmurphy@ti.com>
20 Jan, 2014
3 commits
-
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for thist purpose.Some standard crop parameter checks are done in __vpe_try_crop().
Signed-off-by: Archit Taneja
-
Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect->width
shouldn't be used to calculate the line stride, the original image width
should be used for that. We add a 'width' argument which gives the buffer
width in memory.- frame_width and frame_height describe the complete width and height of the
client to which the channel is connected. If there are multiple channels
fetching data and providing to the same client, the above 2 arguments should
be the width and height of the region covered by all the channels. In the case
where there is only one channel providing pixel data to the client
(like in VPE), frame_width and frame_height should be the cropped width and
cropped height respectively. The calculation of these params is done in the
vpe driver now.- start_h and start_v is also used in the case of multiple channels to decribe
where each channel should start filling pixel data. We don't use this in VPE,
and pass 0s to the vpdma_add_in_dtd() helper.- Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect
param is removed since cropping isn't possible for outbound data, and 'width'
is added to calculate the line stride.Signed-off-by: Archit Taneja
-
VPE has a ctrl parameter which decides how many mem to mem transactions the
active job from the job queue can perform.The driver's job_ready() made sure that the number of ready source buffers are
sufficient for the job to execute successfully. But it didn't make sure if
there are sufficient ready destination buffers in the capture queue for the
VPE output.If the time taken by VPE to process a single frame is really slow, then it's
possible that we don't need to imply such a restriction on the dst queue, but
really fast transactions(small resolution, no de-interlacing) may cause us to
hit the condition where we don't have any free buffers for the VPE to write on.Add the extra check in job_ready() to make sure we have the sufficient amount
of destination buffers.Signed-off-by: Archit Taneja
18 Jan, 2014
1 commit
-
…x-stable into ti-linux-3.12.y
This is the 3.12.6 stable release
* tag 'v3.12.6' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (120 commits)
Linux 3.12.6
ARM: OMAP2+: hwmod: Fix SOFTRESET logic
drm/i915/vlv: fix up broken precision in vlv_crtc_clock_get
drm/i915/vlv: add VLV specific clock_get function v3
i915/vlv: untangle integrated clock source handling v4
Btrfs: fix lockdep error in async commit
Btrfs: fix a crash when running balance and defrag concurrently
Btrfs: do not run snapshot-aware defragment on error
Btrfs: take ordered root lock when removing ordered operations inode
Btrfs: stop using vfs_read in send
Btrfs: fix incorrect inode acl reset
Btrfs: fix hole check in log_one_extent
Btrfs: fix memory leak of chunks' extent map
Btrfs: reset intwrite on transaction abort
Btrfs: do a full search everytime in btrfs_search_old_slot
Revert "net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST"
Input: elantech - add support for newer (August 2013) devices
NFSv4 wait on recovery for async session errors
sc1200_wdt: Fix oops
staging: comedi: ssv_dnp: use comedi_dio_update_state()
...Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
drivers/usb/musb/musb_cppi41.cSigned-off-by: Dan Murphy <dmurphy@ti.com>
20 Dec, 2013
9 commits
-
commit 0db3fa2741ad8371c21b3a6785416a4afc0cc1d4 upstream.
drivers/media/dvb-frontends/cxd2820r_core.c:34:32: error: cannot size expression
drivers/media/dvb-frontends/cxd2820r_core.c:68:32: error: cannot size expressionSigned-off-by: Hans Verkuil
Acked-by: Antti Palosaari
Reviewed-by: Antti Palosaari
Reviewed-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
Cc: Frederik Himpe
Signed-off-by: Greg Kroah-Hartman -
commit 3189ef0290dcc9f44782672fade35847cb30da00 upstream.
We introduced a couple new error paths which are missing unlocks.
Fixes: 7760e148350b ('[media] af9035: Don't use dynamic static allocation')Signed-off-by: Dan Carpenter
Acked-by: Antti Palosaari
Signed-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 0c413d10515feae02cee967b31bb8afea8aa0d29 upstream.
It is IT9135 dual design.
Thanks to Michael Piko for reporting that!Reported-by: Michael Piko
Signed-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 3af41a337a5b270de3e65466a07f106ad97ad0c6 upstream.
Commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 inverted the mute control
state test in s_routing which caused the audio routing to fail. This broke
ivtv support for the Hauppauge video/audio input bracket (which adds additional
video and audio inputs) all the way back in kernel 2.6.36.
This fix fixes the condition and it also removes a nonsense check on the
balance control.
Bisected-by: Rajil SaraswatSigned-off-by: Andy Walls
Reported-by: Rajil Saraswat
Tested-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit d18a88b1f535d627412b2a265d71b2f7d464860e upstream.
Driver did not work anymore since I2C has gone broken due
to recent commit:
commit 37ebaf6891ee81687bb558e8375c0712d8264ed8
[media] dvb-frontends: Don't use dynamic static allocationSigned-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit f8e1b699a5504a2da05834c7cfdddb125a8ce088 upstream.
The no_video flag was checked in all other cases except one. Calling
v4l2_ctrl_handler_setup() if no_video is 1 will crash.
This wasn't noticed before since there are only two card types that
set no_video to 1, so this type of hardware is quite rare.Signed-off-by: Hans Verkuil
Reported-by: Lorenz Röhrl
Tested-by: Lorenz Röhrl
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 9ba6a91f19b8c118d11c549495fa4f7a20505d80 upstream.
When adding frequency clamping to the tef6862 and radio-tea5764 drivers
I forgot to actually *assign* the clamp result to the frequency.Signed-off-by: Hans Verkuil
Reported-by: Hans Petter Selasky
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 89f4d45b2752df5d222b5f63919ce59e2d8afaf4 upstream.
In case of error, the function kthread_run() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().Signed-off-by: Wei Yongjun
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 9323297dc0ea9141f8099e474657391bb3ad98f8 upstream.
There was three small buffer len calculation bugs which caused
driver non-working. These are coming from recent commit:
commit 7760e148350bf6df95662bc0db3734e9d991cb03
[media] af9035: Don't use dynamic static allocationSigned-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
10 Dec, 2013
1 commit
-
…ux-kernel/audio-display-linux-feature-tree into ti-linux-3.12.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.12.y* 'audio-display-ti-linux-3.12.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
arm/dts: boneblack - make 1280x720@60 default for HDMI
v4l: ti-vpe: Add a type specifier to describe vpdma data format type
v4l: ti-vpe: enable CSC support for VPE
v4l: ti-vpe: enable YUV to RGB color conversion support
v4l: ti-vpe: create a color space converter library
v4l: ti-vpe: enable basic scaler support
v4l: ti-vpe: load scaler coefficients
v4l: ti-vpe: Create a scaler library
v4l: ti-vpe: make sure VPDMA line stride constraints are met
v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format
v4l: ti-vpe: use module_platform_driver to simplify the code
v4l: ti-vpe: fix error return code in vpe_probe()
v4l: ti-vpe: fix return value check in vpe_probe()Signed-off-by: Dan Murphy <dmurphy@ti.com>
09 Dec, 2013
9 commits
-
…ux-stable into ti-linux-3.12.y
This is the 3.12.4 stable release
* tag 'v3.12.4' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (295 commits)
Linux 3.12.4
drm/radeon/audio: correct ACR table
drm/radeon/audio: improve ACR calculation
aio: clean up aio ring in the fail path
aio: nullify aio->ring_pages after freeing it
aio: prevent double free in ioctx_alloc
aio: checking for NULL instead of IS_ERR
rework aio migrate pages to use aio fs
take anon inode allocation to libfs.c
aio: Fix a trinity splat
ntp: Make periodic RTC update more reliable
elevator: acquire q->sysfs_lock in elevator_change()
elevator: Fix a race in elevator switching and md device initialization
rt2800: add support for radio chip RF3070
iommu: Remove stack trace from broken irq remapping warning
iommu/vt-d: Fixed interaction of VFIO_IOMMU_MAP_DMA with IOMMU address limits
HID: hid-elo: some systems cannot stomach work around
HID: lg: fix Report Descriptor for Logitech MOMO Force (Black)
video: kyro: fix incorrect sizes when copying to userspace
usb: wusbcore: change WA_SEGS_MAX to a legal value
...Conflicts:
arch/arm/mach-omap2/omap_device.c
drivers/mtd/devices/m25p80.c
drivers/usb/musb/davinci.cSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
The struct vpdma_data_format holds the color format depth and the data_type
value needed to be programmed in the data descriptors. However, it doesn't
tell what type of color format is it, i.e, whether it is RGB, YUV or Misc.This information is needed when by vpdma library when forming descriptors. We
modify the depth parameter for the chroma portion of the NV12 format. For this,
we check if the data_type value is C420. This isn't sufficient as there are
many YUV and RGB vpdma formats which have the same data_type value. Hence, we
need to hold the type of the color format for the above case, and possibly more
cases in the future.Signed-off-by: Archit Taneja
-
Use the csc library functions to configure the CSC block in VPE.
Some changes are required in try_fmt to handle the pix->colorspace parameter
more correctly. Add basic RGB color formats to the list of supported vpe
formats.If the destination format is RGB colorspace, we also need to use the RGB output
port instead of the Luma and Chroma output ports. This requires configuring the
output data descriptors differently.Also, make the default colorspace V4L2_COLORSPACE_SMPTE170M as that resembles
the Standard Definition colorspace more closely.Signed-off-by: Archit Taneja
-
The CSC block can be used for color space conversion between YUV and RGB
formats.It is configurable via a programmable set of coefficients. Add functionality to
choose the appropriate CSC coefficients and program them in the CSC registers.
We take the source and destination colorspace formats as the arguments, and
choose the coefficient table accordingly.Only YUV to RGB coefficients are provided for standard and high definition
colorspaces. The coefficients can also be limited or full range, only full range
coefficients are chosen by default. We would need some sort of control ioctl for
the user to specify the range needed.Signed-off-by: Archit Taneja
-
Create the csc block related configurations and register definitions as a
library. This is done as the same csc block is used in both VIP and VPE.The vpe_dev device holds a csc_data handle, which it can reference to access
the registers, or call csc related helper functions.Signed-off-by: Archit Taneja
-
Add the required scaler register configurations which lets us perform linear
scaling for the supported range of horizontal and vertical scaling ratios.The horizontal scaler performs polyphase scaling using it's 8 tap 32 phase
filter, decimation is performed when downscaling passes beyond 2x or 4x.The vertical scaler performs polyphase scaling using it's 5 tap 32 phase
filter, it switches to a simpler form of scaling using the running average
filter when the downscale ratio is more than 4x.Many of the scaler features like peaking, trimming and non-linear scaling aren't
implemented for now. Only those register fields are configured which are
required for basic scaling operation.The function to configure scaler registers takes the sc_data handle, the source
and destination directions, and the scaler address data block offsets for the
current context so that they can be configured.Signed-off-by: Archit Taneja
-
The scaler IP requires to be loaded with coefficients from memory through
VPDMA.The horizontal and vertical scaler each require a set of scaler coefficients.
The horizontal polyphase scaler requires luma and chroma coefficients for a 32
phase and 8 tap filter. Similarly, the vertical scaler requires coefficients for
a 5 tap filter.In order to load the scaler coefficients via VPDMA, a configuration descriptor
is used in block mode. The payload for the descriptor is the scaler coefficients
copied to memory. The coefficients need to be placed in memory in a particular
order, this is taken care by the functions sc_set_hs and sc_set_vs_coefficients.The choice of the scaler coefficients depends on the downscale ratio. In the
case of horizontal downscaling, we need to consider the change in ratio cause by
decimation. In the case of vertical scaling, the VPE driver should provide the
source height based on whether the de-interlacer is used or not.Signed-off-by: Archit Taneja
-
Create the scaler block related configurations and register definitions as a
library. This is done as the same scaler block is used in both VIP and VPE.The vpe_dev device holds a sc_data handle, which it can reference to access
the registers, or call scaler related helper functions.Signed-off-by: Archit Taneja
-
When VPDMA fetches or writes to an image buffer, the line stride must be a
multiple of 16 bytes. If it isn't, VPDMA HW will write/fetch until the next
16 byte boundry. This causes VPE to work incorrectly for source or destination
widths which don't satisfy the above alignment requirement.In order to prevent this, we now make sure that when we set pix format for the
input and output buffers, the VPE source and destination image line strides are
16 byte aligned. Also, the motion vector buffers for the de-interlacer are
allocated in such a way that it ensures the same alignment.Signed-off-by: Archit Taneja
06 Dec, 2013
4 commits
-
The data_type value to be programmed in the data descriptors to fetch/write a
UYVY buffer was not mentioned correctly in the older DRA7x documentation. This
caused VPE to fail with UYVY color formats.Update the data_type value to fix functionality when UYVY format is used.
Signed-off-by: Archit Taneja
-
module_platform_driver() makes the code simpler by eliminating
boilerplate code.Signed-off-by: Wei Yongjun
-
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.Signed-off-by: Wei Yongjun
-
In case of error, the function devm_kzalloc() and devm_ioremap()
returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return
value check should be replaced with NULL test.Signed-off-by: Wei Yongjun
05 Dec, 2013
10 commits
-
commit 9736a89dafe07359d9c86bf9c3b815a250b354bc upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this frontend, only ttpci uses it. The maximum
number of messages there is two, on I2C read operations. As the logic
can add an extra operation, change the size to 3.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 8393796dfa4cf5dffcceec464c7789bec3a2f471 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 37ebaf6891ee81687bb558e8375c0712d8264ed8 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Reviewed-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit ba4746423488aafa435739c32bfe0758f3dd5d77 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 9aca4fb0571ce9cfef680ceb08d19dd008015307 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit f7a35df15b1f7de7823946aebc9164854e66ea07 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit f1baab870f6e93b668af7b34d6f6ba49f1b0e982 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Reviewed-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 56ac033725ec93a45170caf3979eb2b1211a59a8 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum limit is 80, used only
on tm6000 driver. This limit is due to the size of the USB control URBs.
Ok, it would be theoretically possible to use a bigger size on PCI
devices, but the firmware load time is already good enough. Anyway,
if some usage requires more, it is just a matter of also increasing
the buffer size at load_firmware().Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 24e9a47e14f0a97ee97abc3dd86b2ef254448a17 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
with is currently 128. That means that the buffer size can be up to
128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
Worse than that, someone could increase it and cause real troubles.
So, let's use dynamically allocated data, instead.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 1d212cf0c2d89adf3d0a6d62d729076f49f087dc upstream.
drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom':
drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
That happens because the routine allocates 256 bytes for an eeprom buffer, plus
the size of struct i2c_client, with is big.
Change the logic to dynamically allocate/deallocate space for struct i2c_client,
instead of using the stack.Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
