Re: [PATCH v3 08/10] staging: media: Make use of MEDIA_BUS_FMT_ definitions
On Fri, Nov 7, 2014 at 2:07 PM, Boris Brezillon
wrote:
> In order to have subsytem agnostic media bus format definitions we've
> moved media bus definition to include/uapi/linux/media-bus-format.h and
> prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.
>
> Reference new definitions in all media drivers residing in staging.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 18 ++--
> .../staging/media/davinci_vpfe/dm365_ipipe_hw.c| 26 +++---
> drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 100
> ++---
> drivers/staging/media/davinci_vpfe/dm365_isif.c| 90 +--
> drivers/staging/media/davinci_vpfe/dm365_resizer.c | 98 ++--
> .../staging/media/davinci_vpfe/vpfe_mc_capture.c | 18 ++--
For all the above
Acked-by: Lad, Prabhakar
Thanks,
--Prabhakar Lad
> drivers/staging/media/omap4iss/iss_csi2.c | 62 ++---
> drivers/staging/media/omap4iss/iss_ipipe.c | 16 ++--
> drivers/staging/media/omap4iss/iss_ipipeif.c | 28 +++---
> drivers/staging/media/omap4iss/iss_resizer.c | 26 +++---
> drivers/staging/media/omap4iss/iss_video.c | 78
> drivers/staging/media/omap4iss/iss_video.h | 10 +--
> 12 files changed, 285 insertions(+), 285 deletions(-)
>
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> index bdc7f00..704fa20 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> @@ -37,15 +37,15 @@
>
> /* ipipe input format's */
> static const unsigned int ipipe_input_fmts[] = {
> - V4L2_MBUS_FMT_UYVY8_2X8,
> - V4L2_MBUS_FMT_SGRBG12_1X12,
> - V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
> - V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + MEDIA_BUS_FMT_SGRBG12_1X12,
> + MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
> + MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8,
> };
>
> /* ipipe output format's */
> static const unsigned int ipipe_output_fmts[] = {
> - V4L2_MBUS_FMT_UYVY8_2X8,
> + MEDIA_BUS_FMT_UYVY8_2X8,
> };
>
> static int ipipe_validate_lutdpc_params(struct vpfe_ipipe_lutdpc *lutdpc)
> @@ -1457,7 +1457,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
>
> /* If not found, use SBGGR10 as default */
> if (i >= ARRAY_SIZE(ipipe_input_fmts))
> - fmt->code = V4L2_MBUS_FMT_SGRBG12_1X12;
> + fmt->code = MEDIA_BUS_FMT_SGRBG12_1X12;
> } else if (pad == IPIPE_PAD_SOURCE) {
> for (i = 0; i < ARRAY_SIZE(ipipe_output_fmts); i++)
> if (fmt->code == ipipe_output_fmts[i])
> @@ -1465,7 +1465,7 @@ ipipe_try_format(struct vpfe_ipipe_device *ipipe,
>
> /* If not found, use UYVY as default */
> if (i >= ARRAY_SIZE(ipipe_output_fmts))
> - fmt->code = V4L2_MBUS_FMT_UYVY8_2X8;
> + fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
> }
>
> fmt->width = clamp_t(u32, fmt->width, MIN_OUT_HEIGHT, max_out_width);
> @@ -1642,7 +1642,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct
> v4l2_subdev_fh *fh)
> memset(&format, 0, sizeof(format));
> format.pad = IPIPE_PAD_SINK;
> format.which = fh ? V4L2_SUBDEV_FORMAT_TRY :
> V4L2_SUBDEV_FORMAT_ACTIVE;
> - format.format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
> + format.format.code = MEDIA_BUS_FMT_SGRBG12_1X12;
> format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
> format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
> ipipe_set_format(sd, fh, &format);
> @@ -1650,7 +1650,7 @@ ipipe_init_formats(struct v4l2_subdev *sd, struct
> v4l2_subdev_fh *fh)
> memset(&format, 0, sizeof(format));
> format.pad = IPIPE_PAD_SOURCE;
> format.which = fh ? V4L2_SUBDEV_FORMAT_TRY :
> V4L2_SUBDEV_FORMAT_ACTIVE;
> - format.format.code = V4L2_MBUS_FMT_UYVY8_2X8;
> + format.format.code = MEDIA_BUS_FMT_UYVY8_2X8;
> format.format.width = IPIPE_MAX_OUTPUT_WIDTH_A;
> format.format.height = IPIPE_MAX_OUTPUT_HEIGHT_A;
> ipipe_set_format(sd, fh, &format);
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> index b2daf5e..6461de1 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
> @@ -196,12 +196,12 @@ ipipe_setup_resizer(void *__iom
Re: [PATCH v3 06/10] [media] platform: Make use of media_bus_format enum
Hi, Thanks for the patch, On Fri, Nov 7, 2014 at 2:07 PM, Boris Brezillon wrote: > In order to have subsytem agnostic media bus format definitions we've > moved media bus definition to include/uapi/linux/media-bus-format.h and > prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT. > > Reference new definitions in all platform drivers. > > Signed-off-by: Boris Brezillon > --- > arch/arm/mach-davinci/board-dm355-evm.c| 2 +- > arch/arm/mach-davinci/board-dm365-evm.c| 4 +- > arch/arm/mach-davinci/dm355.c | 7 +- > arch/arm/mach-davinci/dm365.c | 7 +- @Sekhar can you ack for the machine changes for davinci ? [Snip] > drivers/media/platform/davinci/vpbe.c | 2 +- > drivers/media/platform/davinci/vpfe_capture.c | 4 +- [snip] > include/media/davinci/vpbe.h | 2 +- > include/media/davinci/vpbe_venc.h | 5 +- For all the above. Acked-by: Lad, Prabhakar Thanks, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 04/10] [media] i2c: Make use of media_bus_format enum
On Fri, Nov 7, 2014 at 2:07 PM, Boris Brezillon
wrote:
> In order to have subsytem agnostic media bus format definitions we've
> moved media bus definitions to include/uapi/linux/media-bus-format.h and
> prefixed values with MEDIA_BUS_FMT instead of V4L2_MBUS_FMT.
>
> Replace all references to the old definitions in i2c drivers.
>
> Signed-off-by: Boris Brezillon
> ---
[Snip]
> drivers/media/i2c/mt9p031.c | 8 ++--
[Snip]
> drivers/media/i2c/tvp514x.c | 12 +++---
> drivers/media/i2c/tvp7002.c | 10 ++---
For all the above,
Acked-by: Lad, Prabhakar
Thanks,
--Prabhakar Lad
> drivers/media/i2c/vs6624.c| 18
> 46 files changed, 382 insertions(+), 382 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7170.c b/drivers/media/i2c/adv7170.c
> index 04bb297..40a1a95 100644
> --- a/drivers/media/i2c/adv7170.c
> +++ b/drivers/media/i2c/adv7170.c
> @@ -63,9 +63,9 @@ static inline struct adv7170 *to_adv7170(struct v4l2_subdev
> *sd)
>
> static char *inputs[] = { "pass_through", "play_back" };
>
> -static enum v4l2_mbus_pixelcode adv7170_codes[] = {
> - V4L2_MBUS_FMT_UYVY8_2X8,
> - V4L2_MBUS_FMT_UYVY8_1X16,
> +static u32 adv7170_codes[] = {
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + MEDIA_BUS_FMT_UYVY8_1X16,
> };
>
> /* --- */
> @@ -263,7 +263,7 @@ static int adv7170_s_routing(struct v4l2_subdev *sd,
> }
>
> static int adv7170_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
> - enum v4l2_mbus_pixelcode *code)
> + u32 *code)
> {
> if (index >= ARRAY_SIZE(adv7170_codes))
> return -EINVAL;
> @@ -278,9 +278,9 @@ static int adv7170_g_fmt(struct v4l2_subdev *sd,
> u8 val = adv7170_read(sd, 0x7);
>
> if ((val & 0x40) == (1 << 6))
> - mf->code = V4L2_MBUS_FMT_UYVY8_1X16;
> + mf->code = MEDIA_BUS_FMT_UYVY8_1X16;
> else
> - mf->code = V4L2_MBUS_FMT_UYVY8_2X8;
> + mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
>
> mf->colorspace = V4L2_COLORSPACE_SMPTE170M;
> mf->width = 0;
> @@ -297,11 +297,11 @@ static int adv7170_s_fmt(struct v4l2_subdev *sd,
> int ret;
>
> switch (mf->code) {
> - case V4L2_MBUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> val &= ~0x40;
> break;
>
> - case V4L2_MBUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> val |= 0x40;
> break;
>
> diff --git a/drivers/media/i2c/adv7175.c b/drivers/media/i2c/adv7175.c
> index b88f3b3..d220af5 100644
> --- a/drivers/media/i2c/adv7175.c
> +++ b/drivers/media/i2c/adv7175.c
> @@ -60,9 +60,9 @@ static inline struct adv7175 *to_adv7175(struct v4l2_subdev
> *sd)
>
> static char *inputs[] = { "pass_through", "play_back", "color_bar" };
>
> -static enum v4l2_mbus_pixelcode adv7175_codes[] = {
> - V4L2_MBUS_FMT_UYVY8_2X8,
> - V4L2_MBUS_FMT_UYVY8_1X16,
> +static u32 adv7175_codes[] = {
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + MEDIA_BUS_FMT_UYVY8_1X16,
> };
>
> /* --- */
> @@ -301,7 +301,7 @@ static int adv7175_s_routing(struct v4l2_subdev *sd,
> }
>
> static int adv7175_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
> - enum v4l2_mbus_pixelcode *code)
> + u32 *code)
> {
> if (index >= ARRAY_SIZE(adv7175_codes))
> return -EINVAL;
> @@ -316,9 +316,9 @@ static int adv7175_g_fmt(struct v4l2_subdev *sd,
> u8 val = adv7175_read(sd, 0x7);
>
> if ((val & 0x40) == (1 << 6))
> - mf->code = V4L2_MBUS_FMT_UYVY8_1X16;
> + mf->code = MEDIA_BUS_FMT_UYVY8_1X16;
> else
> - mf->code = V4L2_MBUS_FMT_UYVY8_2X8;
> + mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
>
> mf->colorspace = V4L2_COLORSPACE_SMPTE170M;
> mf->width = 0;
> @@ -335,11 +335,11 @@ static int adv7175_s_fmt(struct v4l2_subdev *sd,
> int ret;
>
> switch (mf->code) {
> - case V4L2_MBUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> val &= ~0x40;
> break;
>
> - case V4L2_MBUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> val |= 0x40;
>
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Michael, On Thu, Feb 20, 2014 at 6:47 PM, Michael Opdenacker wrote: > Hi Laurent, > > On 02/20/2014 12:36 PM, Laurent Pinchart wrote: >> Hi Michael, >> >> What's the status of this patch ? Do expect Prabhakar to pick it up, or do >> you >> plan to push all your IRQF_DISABLED removal patches in one go ? > It's true a good number of my patches haven't been picked up yet, even > after multiple resends. > > I was planning to ask the community tomorrow about what to do to finally > get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes > in one go (or removing the definition of IRQF_DISABLED) may be the final > solution. > > I hope to be able to answer your question by the end of the week. > gentle ping. should I pick it up ? Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Michael, On Mon, Feb 24, 2014 at 11:01 AM, Prabhakar Lad wrote: > Hi Michael, > > On Thu, Feb 20, 2014 at 6:47 PM, Michael Opdenacker > wrote: >> Hi Laurent, >> >> On 02/20/2014 12:36 PM, Laurent Pinchart wrote: >>> Hi Michael, >>> >>> What's the status of this patch ? Do expect Prabhakar to pick it up, or do >>> you >>> plan to push all your IRQF_DISABLED removal patches in one go ? >> It's true a good number of my patches haven't been picked up yet, even >> after multiple resends. >> >> I was planning to ask the community tomorrow about what to do to finally >> get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes >> in one go (or removing the definition of IRQF_DISABLED) may be the final >> solution. >> >> I hope to be able to answer your question by the end of the week. >> > gentle ping. should I pick it up ? > I've picked it up. Thanks, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
On Sun, Oct 6, 2013 at 11:53 AM, Michael Opdenacker wrote: > This patch proposes to remove the use of the IRQF_DISABLED flag > > It's a NOOP since 2.6.35 and it will be removed one day. > > Signed-off-by: Michael Opdenacker Acked-by: Lad, Prabhakar Regrads, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: davinci_vpfe: fix build error
Hi Hans, On Tue, Dec 17, 2013 at 8:55 PM, Lad, Prabhakar wrote: > From: "Lad, Prabhakar" > > This patch includes linux/delay.h required for msleep, > which fixes following build error. > > dm365_isif.c: In function ‘isif_enable’: > dm365_isif.c:129:2: error: implicit declaration of function ‘msleep’ > Will you pick this patch or shall I go ahead and issue a pull to Mauro ? Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: davinci_vpfe: fix build error
Hi Hans, On Fri, Dec 20, 2013 at 6:23 PM, Hans Verkuil wrote: > I just made a patch myself that I added to the pull request I just posted. > > You didn't CC me or CC the linux-media list when you posted your patch, so I > never saw it. > I dont know why this patch didnt make up in linux-media but its present DLOS [1]. I posted it the same day when you pinged me about this issue. Anyway your patch too didnt reach me and I also cannot find it in the ML. May be you directly issued the pull ? [1] https://patchwork.kernel.org/patch/3362211/ Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: davinci_vpfe: fix build error
Hi Hans, On Fri, Dec 20, 2013 at 7:00 PM, Hans Verkuil wrote: > Hi Prabhakar, > > On 12/20/2013 02:02 PM, Prabhakar Lad wrote: >> Hi Hans, >> >> On Fri, Dec 20, 2013 at 6:23 PM, Hans Verkuil wrote: >>> I just made a patch myself that I added to the pull request I just posted. >>> >>> You didn't CC me or CC the linux-media list when you posted your patch, so I >>> never saw it. >>> >> I dont know why this patch didnt make up in linux-media but its >> present DLOS [1]. > > If it's not mailed to linux-media, then it doesn't end up in linux-media > patchwork, > and then I won't see it when I process pending patches. > > While I am subscribed to DLOS I do not actually read it unless I know there is > something that I need to pay attention to. > This didnt land into linux-media becuase may be I sent it throught TI's network I usually send it via my home network. >> I posted it the same day when you pinged me about this issue. > > I was a bit surprised that I didn't see a patch for this, you are very prompt > normally :-) > :) >> Anyway your patch >> too didnt reach me and I also cannot find it in the ML. May be you >> directly issued the pull ? > > I directly issued the pull. It was such a trivial change. > No problem as long as its fixed :) Thanks, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [media] davinci-vpfe: Fix retcode check
Hi Andrey, Thanks for the patch! On Tue, Jul 8, 2014 at 3:58 PM, Andrey Utkin wrote: > 2014-07-08 17:32 GMT+03:00 Levente Kurusa : >> Hmm, while it is true that get_ipipe_mode returns an int, but >> the consequent call to regw_ip takes an u32 as its second >> argument. Did it cause a build warning for you? (Can't really >> check since I don't have ARM cross compilers close-by) >> If not, then: > > Cannot say for sure would compiler complain. > I also haven't really checked it, and unfortunately even haven't > succeeded to make a config that would build that code. But i believe > that warning is still better than misbehaviour. > It wont cause any compile warning. Applied for v3.17 Thanks, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
