Re: [PATCH] media: staging: davinci: remove vpfe driver
On Tue, Jul 23, 2019 at 11:46 AM Arnd Bergmann wrote: > > The davinci_vpfe driver was merged into staging back in 2012 by Manjunath > Hadli from TI, with a long TODO list. > > For all I can tell, since then it has only seen fixes for compile-time > issues and global cleanups, but nobody has actually worked on the items > on the TODO list. > > To make things worse, the driver in its current form is incompatible with > the platform code in arch/arm/mach-davinci, i.e. the driver expects to > get its platform_data passed to the device as a 'struct vpfe_config', > but uses a differnet definition for that structure compared to what the s/differnet/different > platform uses. > > Finally, there is another driver for the same device in > drivers/media/platform/davinci/vpfe_capture.c. From all I can tell, the > staging version was originally a copy of a more featureful driver in TI's > downstream kernels. However, that kernel no longer supports dm365 after > linux-2.6.37, and the mainline version moved in a different direction. > > Signed-off-by: Arnd Bergmann > --- > drivers/staging/media/Kconfig |2 - > drivers/staging/media/Makefile|1 - > drivers/staging/media/davinci_vpfe/Kconfig| 13 - > drivers/staging/media/davinci_vpfe/Makefile | 11 - > drivers/staging/media/davinci_vpfe/TODO | 38 - > .../media/davinci_vpfe/davinci-vpfe-mc.txt| 154 -- > .../media/davinci_vpfe/davinci_vpfe_user.h| 1287 -- > .../staging/media/davinci_vpfe/dm365_ipipe.c | 1852 --- > .../staging/media/davinci_vpfe/dm365_ipipe.h | 174 -- > .../media/davinci_vpfe/dm365_ipipe_hw.c | 1038 > .../media/davinci_vpfe/dm365_ipipe_hw.h | 556 - > .../media/davinci_vpfe/dm365_ipipeif.c| 1070 - > .../media/davinci_vpfe/dm365_ipipeif.h| 228 -- > .../media/davinci_vpfe/dm365_ipipeif_user.h | 90 - > .../staging/media/davinci_vpfe/dm365_isif.c | 2097 - > .../staging/media/davinci_vpfe/dm365_isif.h | 200 -- > .../media/davinci_vpfe/dm365_isif_regs.h | 291 --- > .../media/davinci_vpfe/dm365_resizer.c| 1995 > .../media/davinci_vpfe/dm365_resizer.h| 241 -- > drivers/staging/media/davinci_vpfe/vpfe.h | 83 - > .../media/davinci_vpfe/vpfe_mc_capture.c | 716 -- > .../media/davinci_vpfe/vpfe_mc_capture.h | 90 - > .../staging/media/davinci_vpfe/vpfe_video.c | 1646 - > .../staging/media/davinci_vpfe/vpfe_video.h | 150 -- > 24 files changed, 14023 deletions(-) > delete mode 100644 drivers/staging/media/davinci_vpfe/Kconfig > delete mode 100644 drivers/staging/media/davinci_vpfe/Makefile > delete mode 100644 drivers/staging/media/davinci_vpfe/TODO > delete mode 100644 drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt > delete mode 100644 drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif_user.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif_regs.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.c > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.h > Acked-by: Lad, Prabhakar Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/8] media: v4l2-async: simplify v4l2_async_subdev structure
Hi Mauro, Thanks for the patch. On Tue, Dec 19, 2017 at 11:18 AM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one > struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME > match criteria requires just a device name. > > So, it doesn't make sense to enclose those into structs, > as the criteria can go directly into the union. > > That makes easier to document it, as we don't need to document > weird senseless structs. > > At drivers, this makes even clearer about the match criteria. > > Acked-by: Sylwester Nawrocki <s.nawro...@samsung.com> > Acked-by: Benoit Parrot <bpar...@ti.com> > Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> > Acked-by: Sakari Ailus <sakari.ai...@linux.intel.com> > Acked-by: Philipp Zabel <p.za...@pengutronix.de> > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com> > --- > drivers/media/platform/am437x/am437x-vpfe.c| 6 +++--- For above: Acked-by: Lad, Prabhakar <prabhakar.cse...@gmail.com> Cheers, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: use unsigned for pad index
On Fri, Dec 11, 2015 at 2:26 PM, Mauro Carvalho Chehab <mche...@osg.samsung.com> wrote: > The pad index is unsigned. Replace the occurences of it where > pertinent. > > Suggested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com> > --- > drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 2 +- > drivers/staging/media/davinci_vpfe/dm365_isif.c| 2 +- > drivers/staging/media/davinci_vpfe/dm365_resizer.c | 2 +- For the above: Acked-by: Lad, Prabhakar <prabhakar.cse...@gmail.com> Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Clarify expression which uses both multiplication and pointer dereference
On Mon, May 18, 2015 at 7:51 AM, Michal Kubecek mkube...@suse.cz wrote:
On Sun, May 17, 2015 at 07:18:42PM +0200, Alex Dowad wrote:
This fixes a checkpatch style error in vpfe_buffer_queue_setup.
Signed-off-by: Alex Dowad alexinbeij...@gmail.com
---
drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 06d48d5..04a687c 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -1095,7 +1095,7 @@ vpfe_buffer_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *fmt,
size = video-fmt.fmt.pix.sizeimage;
if (vpfe_dev-video_limit) {
- while (size * *nbuffers vpfe_dev-video_limit)
+ while (size * (*nbuffers) vpfe_dev-video_limit)
(*nbuffers)--;
}
if (pipe-state == VPFE_PIPELINE_STREAM_CONTINUOUS) {
Style issue aside, is there a reason not to use
if (size * *nbuffers vpfe_dev-video_limit)
*nbuffers = vpfe_dev-video_limit / size;
instead?
I would prefer this.
Cheers,
--Prabhakar Lad
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/4] staging: sm750fb: wrong type for print
On Mon, Mar 9, 2015 at 7:35 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: mention correct format specifier while printing. fixes all the build warnings about incorrect argument type while printing. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- V2: Giedrius commented resource_size_t can be either u64 or u32 depending on if CONFIG_PHYS_ADDR_T_64BIT. based on his comments i should have kept the datatype as resource_size_t and used %pa as the format specifier. But since this is a framebuffer device and it should follow what the framebuffer layer is suggesting in struct fb_fix_screeninfo at smem_start and mmio_start. adding Tomi for his comments. this patch will give checkpatch warnings about use of printk. this patch was mainly to fix the build warnings. printk will be converted to pr_* and dev_* in a later patch. drivers/staging/sm750fb/sm750.c| 24 drivers/staging/sm750fb/sm750.h| 8 drivers/staging/sm750fb/sm750_hw.c | 4 ++-- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c index 520c69e..753869e 100644 --- a/drivers/staging/sm750fb/sm750.c +++ b/drivers/staging/sm750fb/sm750.c @@ -530,20 +530,20 @@ static int lynxfb_ops_mmap(struct fb_info * info, struct vm_area_struct * vma) if (vma-vm_pgoff (~0UL PAGE_SHIFT)) return -EINVAL; off = vma-vm_pgoff PAGE_SHIFT; - printk(lynxfb mmap pgoff: %x\n, vma-vm_pgoff); - printk(lynxfb mmap off 1: %x\n, off); + printk(lynxfb mmap pgoff: %lx\n, vma-vm_pgoff); + printk(lynxfb mmap off 1: %lx\n, off); wouldn't it makes sense to change printk to some pr_*() ? Cheers, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/4] staging: sm750fb: correctly define SM750LE_REVISION_ID
On Mon, Mar 9, 2015 at 7:35 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: check if it is already defined before defining SM750LE_REVISION_ID again and at the same time mention correct data type. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- v2: removed the redundant cast in sm750_hw.c drivers/staging/sm750fb/ddk750_chip.h | 4 +++- drivers/staging/sm750fb/sm750_hw.c| 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h index 1c78875..d761b72 100644 --- a/drivers/staging/sm750fb/ddk750_chip.h +++ b/drivers/staging/sm750fb/ddk750_chip.h @@ -1,7 +1,9 @@ #ifndef DDK750_CHIP_H__ #define DDK750_CHIP_H__ #define DEFAULT_INPUT_CLOCK 14318181 /* Default reference clock */ -#define SM750LE_REVISION_ID (char)0xfe +#ifndef SM750LE_REVISION_ID +#define SM750LE_REVISION_ID ((unsigned char)0xfe) BTW who is defining this somewhere else ? Cheers, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hyperv: fix sparse warnings
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch fixes following sparse warnings:
netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared.
Should it be static?
rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not
declared. Should it be static?
rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not
declared. Should it be static?
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Found this issue on linux-next (gcc version 4.9.2,
sparse version 0.4.5-rc1) and applies on top linux-next.
drivers/net/hyperv/netvsc.c | 6 +++---
drivers/net/hyperv/rndis_filter.c | 5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 58bb410..208eb05 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -685,9 +685,9 @@ static u32 netvsc_get_next_send_section(struct
netvsc_device *net_device)
return ret_val;
}
-u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device,
- unsigned int section_index,
- struct hv_netvsc_packet *packet)
+static u32 netvsc_copy_to_send_buf(struct netvsc_device *net_device,
+ unsigned int section_index,
+ struct hv_netvsc_packet *packet)
{
char *start = net_device-send_buf;
char *dest = (start + (section_index * net_device-send_section_size));
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 7bd8387..7816d98 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -624,7 +624,8 @@ cleanup:
return ret;
}
-int rndis_filter_set_offload_params(struct hv_device *hdev,
+static int
+rndis_filter_set_offload_params(struct hv_device *hdev,
struct ndis_offload_params *req_offloads)
{
struct netvsc_device *nvdev = hv_get_drvdata(hdev);
@@ -699,7 +700,7 @@ u8 netvsc_hash_key[HASH_KEYLEN] = {
0x6a, 0x42, 0xb7, 0x3b, 0xbe, 0xac, 0x01, 0xfa
};
-int rndis_filter_set_rss_param(struct rndis_device *rdev, int num_queue)
+static int rndis_filter_set_rss_param(struct rndis_device *rdev, int num_queue)
{
struct net_device *ndev = rdev-net_dev-ndev;
struct rndis_request *request;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: use of opaque subject lines
On Thu, Feb 5, 2015 at 5:57 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Thu, Feb 05, 2015 at 04:57:09PM +, Lad, Prabhakar wrote:
On Thu, Feb 5, 2015 at 4:30 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote:
On a serious note: I do understand what you're getting at, I don't take
that personally (and I will send a v2 addressing the things above), but
honestly, this kind of answer might just be a real turn-off for other
people trying to get into kernel development...
I don't want to start a whole new 'attitude in the kernel community'
discussion, but I can't just let this go like that, sorry.
Just during the last 12 hours or so, I've seen the following l-k traffic:
Subject: [PATCH] usb: host/sl811-hcd: fix sparse warning
Subject: [PATCH] usb: gadget: function/f_sourcesink: fix sparse warning
Subject: [PATCH] tty: vt/vt: fix sparse warning
Subject: [PATCH] scsi: fix sparse warnings
Subject: [PATCH] bfa: bfa_core: fix sparse warning
Subject: [PATCH] scsi: fix sparse warning
Subject: [PATCH] xen/acpi-processor: fix sparse warning
Subject: [PATCH] scsi: initio: fix sparse warnings
Subject: [PATCH] scsi: dc395x: fix sparse warning
Subject: [PATCH] scsi: eata: fix sparse warning
Subject: [PATCH] scsi: qla1280: fix sparse warnings
Subject: [PATCH] scsi: ips: fix sparse warnings
Subject: [PATCH] fbdev: via/via_clock: fix sparse warning
Subject: [PATCH] usb: gadget: fix sparse warnings
Subject: [PATCH] usb: gadget: fix sparse warnings
Subject: [PATCH] usb: gadget: function/uvc_v4l2.c: fix sparse warnings
Subject: [PATCH] xen-netback: fix sparse warning
Subject: [PATCH] thermal: int340x: fix sparse warning
Subject: [PATCH] vxge: fix sparse warning
Subject: Re: [PATCH] xen-netback: fix sparse warning
Subject: [PATCH] ixgbe: fix sparse warnings
Subject: [PATCH] samsung-laptop: fix sparse warning
Subject: [PATCH] x86: thinkpad_acpi.c: fix sparse warning
Subject: [PATCH] Sony-laptop: fix sparse warning
all right I have stopped the script to send any more patches fixing
sparse warnings !
That's not the point at all {sigh}
The point is, if you are going to do fixes, also provide a valid subject
line too. Think of the people on the receiving end of your patch, they
are the most valuable and limited resource our community has right now.
You want to make it as _easy_ as possible for them to accept your
contribution. If you don't provide enough information, or drown them in
redundancy, or crappy patches, they will just get frustrated and drop
them all on the floor.
And _NEVER_ have automated scripts create patches and send them out. I
only know of ONE person/bot that gets away with this, and you are not
that person, sorry. It it not a script on the receiving end of your
output, so don't use a script to create a mess for them to dig through.
I want these types of fixes, but make it easy for us to accept them, not
hard, like Al is pointing out in very vivid detail. To respond to his
heartfelt plea and detailed instructions with a fine, I'll just go
away! is disrespectful.
Sorry for that.
I agree a proper a description is needed ideally, but all these days prior to my
patches, the subject line was 'fix sparse warnings' for such patches,
that’s the
reason I picked it for my script. I understand people get annoyed seeing so many
continuous patches with same subject line, ill make my script a bit smarter
to have detailed explanation now on.
Just a side note I verify the patch created by the script and if its
OK then only I post it to ML.
Regards,
--Prabhakar Lad
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] staging: media: davinci_vpfe: drop condition with no effect
On Mon, Jan 26, 2015 at 7:27 AM, Nicholas Mc Guire der.h...@hofr.at wrote:
As the if and else branch body are identical the condition has no effect and
can be dropped.
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Regards,
--Prabhakar Lad
---
As the if and the else branch of the inner conditional paths are the same
the condition is without effect. Given the comments indicate that
the else branch *should* be handling a specific case this may indicate
a bug, in which case the below patch is *wrong*. This needs a review by
someone that knows the specifics of this driver.
If the inner if/else is a placeholder for planed updates then it should
be commented so this is clear.
Patch was only compile tested with davinci_all_defconfig + CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y, CONFIG_MEDIA_SUPPORT=m,
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y, CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y, CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_VIDEO_DM365_VPFE=m
Patch is against 3.0.19-rc5 -next-20150123
drivers/staging/media/davinci_vpfe/dm365_resizer.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
index 75e70e1..bf2cb7a 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
@@ -63,16 +63,11 @@ resizer_calculate_line_length(u32 pix, int width, int
height,
if (pix == MEDIA_BUS_FMT_UYVY8_2X8 ||
pix == MEDIA_BUS_FMT_SGRBG12_1X12) {
*line_len = width 1;
- } else if (pix == MEDIA_BUS_FMT_Y8_1X8 ||
- pix == MEDIA_BUS_FMT_UV8_1X8) {
- *line_len = width;
- *line_len_c = width;
- } else {
- /* YUV 420 */
- /* round width to upper 32 byte boundary */
+ } else {
*line_len = width;
*line_len_c = width;
}
+
/* adjust the line len to be a multiple of 32 */
*line_len += 31;
*line_len = ~0x1f;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fix davinci_vpfe: fix space prohibted before that ','
Hi, On Wed, Jan 21, 2015 at 4:52 AM, Ahmad Hassan ahmad.hassan...@gmail.com wrote: This patch fixes the following checkpatch.pl error: fix space prohibited before that ',' at line 904 Thanks for the patch, but there already exists a patch [1] fixing this. [1] https://patchwork.linuxtv.org/patch/27912/ Thanks, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: davinci_vpfe: fix space prohibited before semicolon warning
Hi,
Thanks for the patch.
On Wed, Jan 14, 2015 at 9:46 PM, Aya Mahfouz
mahfouz.saif.elya...@gmail.com wrote:
This patch fixes the following checkpatch.pl warning:
space prohibited before semicolon
Signed-off-by: Aya Mahfouz mahfouz.saif.elya...@gmail.com
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Regards,
--Prabhakar Lad
---
v1: This patch applies to Greg's tree.
drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 704fa20..a425f71 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -901,7 +901,7 @@ static int ipipe_set_gbce_params(struct vpfe_ipipe_device
*ipipe, void *param)
struct device *dev = ipipe-subdev.v4l2_dev-dev;
if (!gbce_param) {
- memset(gbce, 0 , sizeof(struct vpfe_ipipe_gbce));
+ memset(gbce, 0, sizeof(struct vpfe_ipipe_gbce));
} else {
memcpy(gbce, gbce_param, sizeof(struct vpfe_ipipe_gbce));
if (ipipe_validate_gbce_params(gbce) 0) {
@@ -1086,7 +1086,7 @@ static int ipipe_set_car_params(struct
vpfe_ipipe_device *ipipe, void *param)
struct vpfe_ipipe_car *car = ipipe-config.car;
if (!car_param) {
- memset(car , 0, sizeof(struct vpfe_ipipe_car));
+ memset(car, 0, sizeof(struct vpfe_ipipe_car));
} else {
memcpy(car, car_param, sizeof(struct vpfe_ipipe_car));
if (ipipe_validate_car_params(car) 0) {
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: davinci_vpfe: dm365_resizer: fix sparse warning
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch fixes following sparse warning,
dm365_resizer.c:223:1: warning: symbol 'resizer_calculate_resize_ratios' was
not declared. Should it be static?
dm365_resizer.c:313:5: warning: symbol 'resizer_configure_output_win' was not
declared. Should it be static?
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/staging/media/davinci_vpfe/dm365_resizer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
index 8e13bd4..8828d6c 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
@@ -219,7 +219,7 @@ configure_resizer_out_params(struct vpfe_resizer_device
*resizer, int index,
* @resizer: Pointer to VPFE resizer subdevice.
* @index: index RSZ_A-resizer-A RSZ_B-resizer-B.
*/
-void
+static void
resizer_calculate_resize_ratios(struct vpfe_resizer_device *resizer, int index)
{
struct resizer_params *param = resizer-config;
@@ -310,7 +310,7 @@ resizer_calculate_sdram_offsets(struct vpfe_resizer_device
*resizer, int index)
return 0;
}
-int resizer_configure_output_win(struct vpfe_resizer_device *resizer)
+static int resizer_configure_output_win(struct vpfe_resizer_device *resizer)
{
struct resizer_params *param = resizer-config;
struct vpfe_rsz_output_spec output_specs;
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
