Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

2018-05-15 Thread Bartlomiej Zolnierkiewicz 
On Friday, May 04, 2018 04:24:15 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:19:31 +0200
> > Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> escreveu:
> > 
> > 
> > > How's about just allowing COMPILE_TEST for FB_VIA instead of adding
> > > all these stubs?
> > 
> > Works for me.
> > 
> > Do you want to apply it via your tree or via the media one?
> > 
> > If you prefer to apply on yours:
> > 
> > Reviewed-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
> 
> Thanks, I'll apply it to my tree later.

I've queued the patch for v4.18 now.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

2018-05-04 Thread Bartlomiej Zolnierkiewicz 
On Friday, May 04, 2018 11:07:01 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:19:31 +0200
> Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> escreveu:
> 
> 
> > How's about just allowing COMPILE_TEST for FB_VIA instead of adding
> > all these stubs?
> 
> Works for me.
> 
> Do you want to apply it via your tree or via the media one?
> 
> If you prefer to apply on yours:
> 
> Reviewed-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Thanks, I'll apply it to my tree later.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

2018-04-25 Thread Bartlomiej Zolnierkiewicz 

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote:
> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
> 
> > Ideally we should be able to build both drivers in the same kernel
> > (especially as modules).
> > 
> > I was hoping that it could be fixed easily but then I discovered
> > the root source of the problem:
> > 
> > drivers/gpu/drm/omapdrm/dss/display.o: In function 
> > `omapdss_unregister_display':
> > display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
> > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): 
> > first defined here
> 
> The main problem is that omapdrm and omapfb are two different drivers
> for the same HW. You need to pick one, even if we would change those
> functions and fix the link issue.

With proper resource allocation in both drivers this shouldn't be
a problem - the one which allocates resources first will be used
(+ we can initialize omapdrm first in case it is built-in). This is
how similar situations are handled in other kernel subsystems.

It seems that the real root problem is commit f76ee892a99e ("omapfb:
copy omapdss & displays for omapfb") from Dec 2015 which resulted in
duplication of ~30 KLOC of code. The code in question seems to be
both fbdev & drm independent:

"
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for 
the
  display subsystem IPs used on OMAP (and related) SoCs. It offers only a
  kernel internal API, and does not implement anything for fbdev or drm.

* omapdss panels and encoders, located in
  drivers/video/fbdev/omap2/displays-new/. These are panel and external 
encoder
  drivers, which use APIs offered by omapdss driver. These also don't 
implement
  anything for fbdev or drm.
"

While I understand some motives behind this change I'm not overall
happy with it..

> At some point in time we could compile both as modules (but not
> built-in), but the only use for that was development/testing and in the
> end made our life more difficult. So, now you must fully disable one of
> them to enable the other. And, actually, we even have boot-time code,
> not included in the module itself, which gets enabled when omapdrm is
> enabled.

Do you mean some code in arch/arm/mach-omap2/ or something else?

> While it's of course good to support COMPILE_TEST, if using COMPILE_TEST
> with omapfb is problematic, I'm not sure if it's worth to spend time on
> that. We should be moving away from omapfb to omapdrm.

Is there some approximate schedule for omapfb removal available?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

2018-04-25 Thread Bartlomiej Zolnierkiewicz 
On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 14:47:28 +0200
> Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> escreveu:
> 
> > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > Add stubs for omapfb_dss.h, in the case it is included by
> > > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > > happen on ARM when DRM_OMAP is not 'n'.
> > > 
> > > That allows building such driver(s) with COMPILE_TEST.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>  
> > 
> > This patch should be dropped (together with patch #6/7) as it was
> > superseded by a better solution suggested by Laurent:
> > 
> > https://patchwork.kernel.org/patch/10325193/
> > 
> > ACK-ed by Tomi:
> > 
> > https://www.spinics.net/lists/dri-devel/msg171918.html
> > 
> > and already merged by you (commit 7378f1149884 "media: omap2:
> > omapfb: allow building it with COMPILE_TEST")..
> 
> I "ressurected" this patch due to patch 6/7.
> 
> The problem with the solution already acked/merged is that
> it works *only* if you don't try to build for ARM.
> 
> At the moment you want to build a FB_OMAP2-dependent driver
> on ARM with allyesc onfig, DRM_OMAP will be true, and FB_OMAP2
> will be disabled:
> 
>   menuconfig FB_OMAP2
>   tristate "OMAP2+ frame buffer support"
>   depends on FB
>   depends on DRM_OMAP = n
> 
> One solution might be to change the depends on to:
>   depends on (DRM_OMAP = n || COMPILE_TEST)
> 
> But someone pointed me that the above check was added to avoid building
> duplicated symbols. So, the above would cause build failures.
> 
> So, in order to build for ARM with DRM_OMAP selected (allyesconfig,
> allmodconfig), we have the following alternatives:
> 
>   1) apply patch 5/7;
>   2) make sure that FB_OMAP2 and DRM_OMAP won't declare the
>      same non-static symbols;
>   3) redesign FB_OMAP2 to work with DRM_OMAP built.
> 
> I suspect that (1) is easier.

I agree.

You can merge this patch through your tree with:

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

2018-04-23 Thread Bartlomiej Zolnierkiewicz 
On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > Add stubs for omapfb_dss.h, in the case it is included by
> > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > happen on ARM when DRM_OMAP is not 'n'.
> > 
> > That allows building such driver(s) with COMPILE_TEST.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> 
> This patch should be dropped (together with patch #6/7) as it was
> superseded by a better solution suggested by Laurent:
> 
> https://patchwork.kernel.org/patch/10325193/
> 
> ACK-ed by Tomi:
> 
> https://www.spinics.net/lists/dri-devel/msg171918.html
> 
> and already merged by you (commit 7378f1149884 "media: omap2:
> omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel
(especially as modules).

I was hoping that it could be fixed easily but then I discovered
the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first 
defined here
...

I need some more time to think about this..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

2018-04-23 Thread Bartlomiej Zolnierkiewicz 
On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> Add stubs for omapfb_dss.h, in the case it is included by
> some driver when CONFIG_FB_OMAP2 is not defined, with can
> happen on ARM when DRM_OMAP is not 'n'.
> 
> That allows building such driver(s) with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

This patch should be dropped (together with patch #6/7) as it was
superseded by a better solution suggested by Laurent:

https://patchwork.kernel.org/patch/10325193/

ACK-ed by Tomi:

https://www.spinics.net/lists/dri-devel/msg171918.html

and already merged by you (commit 7378f1149884 "media: omap2:
omapfb: allow building it with COMPILE_TEST")..

> ---
>  include/video/omapfb_dss.h | 54 
> --
>  1 file changed, 52 insertions(+), 2 deletions(-)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH v2 7/7] media: via-camera: allow build on non-x86 archs with COMPILE_TEST

2018-04-23 Thread Bartlomiej Zolnierkiewicz 
 + return false;
> +#endif
> +
>   if (!pbus)
>   return false;
>   pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN,
> @@ -1343,7 +1351,7 @@ static int viacam_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   }
>  
> - if (machine_is_olpc() && viacam_serial_is_enabled())
> + if (viacam_serial_is_enabled())
>   return -EBUSY;
>  
>   /*
> diff --git a/include/linux/via-core.h b/include/linux/via-core.h
> index 9c21cdf3e3b3..ced4419baef8 100644
> --- a/include/linux/via-core.h
> +++ b/include/linux/via-core.h
> @@ -70,8 +70,12 @@ struct viafb_pm_hooks {
>   void *private;
>  };
>  
> +#ifdef CONFIG_FB_VIA
>  void viafb_pm_register(struct viafb_pm_hooks *hooks);
>  void viafb_pm_unregister(struct viafb_pm_hooks *hooks);
> +#else
> +static inline void viafb_pm_register(struct viafb_pm_hooks *hooks) {}
> +#endif /* CONFIG_FB_VIA */
>  #endif /* CONFIG_PM */
>  
>  /*
> @@ -113,8 +117,13 @@ struct viafb_dev {
>   * Interrupt management.
>   */
>  
> +#ifdef CONFIG_FB_VIA
>  void viafb_irq_enable(u32 mask);
>  void viafb_irq_disable(u32 mask);
> +#else
> +static inline void viafb_irq_enable(u32 mask) {}
> +static inline void viafb_irq_disable(u32 mask) {}
> +#endif
>  
>  /*
>   * The global interrupt control register and its bits.
> @@ -157,10 +166,18 @@ void viafb_irq_disable(u32 mask);
>  /*
>   * DMA management.
>   */
> +#ifdef CONFIG_FB_VIA
>  int viafb_request_dma(void);
>  void viafb_release_dma(void);
>  /* void viafb_dma_copy_out(unsigned int offset, dma_addr_t paddr, int len); 
> */
>  int viafb_dma_copy_out_sg(unsigned int offset, struct scatterlist *sg, int 
> nsg);
> +#else
> +static inline int viafb_request_dma(void) { return 0; }
> +static inline void viafb_release_dma(void) {}
> +static inline int viafb_dma_copy_out_sg(unsigned int offset,
> + struct scatterlist *sg, int nsg)
> +{ return 0; }
> +#endif
>  
>  /*
>   * DMA Controller registers.
> diff --git a/include/linux/via-gpio.h b/include/linux/via-gpio.h
> index 8281aea3dd6d..b5a96cf7a874 100644
> --- a/include/linux/via-gpio.h
> +++ b/include/linux/via-gpio.h
> @@ -8,7 +8,11 @@
>  #ifndef __VIA_GPIO_H__
>  #define __VIA_GPIO_H__
>  
> +#ifdef CONFIG_FB_VIA
>  extern int viafb_gpio_lookup(const char *name);
>  extern int viafb_gpio_init(void);
>  extern void viafb_gpio_exit(void);
> +#else
> +static inline int viafb_gpio_lookup(const char *name) { return 0; }
> +#endif
>  #endif
> diff --git a/include/linux/via_i2c.h b/include/linux/via_i2c.h
> index 44532e468c05..209bff950e22 100644
> --- a/include/linux/via_i2c.h
> +++ b/include/linux/via_i2c.h
> @@ -32,6 +32,7 @@ struct via_i2c_stuff {
>  };
>  
>  
> +#ifdef CONFIG_FB_VIA
>  int viafb_i2c_readbyte(u8 adap, u8 slave_addr, u8 index, u8 *pdata);
>  int viafb_i2c_writebyte(u8 adap, u8 slave_addr, u8 index, u8 data);
>  int viafb_i2c_readbytes(u8 adap, u8 slave_addr, u8 index, u8 *buff, int 
> buff_len);
> @@ -39,4 +40,9 @@ struct i2c_adapter *viafb_find_i2c_adapter(enum 
> viafb_i2c_adap which);
>  
>  extern int viafb_i2c_init(void);
>  extern void viafb_i2c_exit(void);
> +#else
> +static inline
> +struct i2c_adapter *viafb_find_i2c_adapter(enum viafb_i2c_adap which)
> +{ return NULL; }
> +#endif
>  #endif /* __VIA_I2C_H__ */

How's about just allowing COMPILE_TEST for FB_VIA instead of adding
all these stubs?


From: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
Subject: [PATCH] video: fbdev: via: allow COMPILE_TEST build

This patch allows viafb driver to be build on !X86 archs
using COMPILE_TEST config option.

Since via-camera driver (VIDEO_VIA_CAMERA) depends on viafb
it also needs a little fixup.

Cc: Florian Tobias Schandinat <florianschandi...@gmx.de>
Cc: Mauro Carvalho Chehab <mche...@s-opensource.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
---
 drivers/media/platform/via-camera.c |5 +
 drivers/video/fbdev/Kconfig |2 +-
 drivers/video/fbdev/via/global.h|6 ++
 drivers/video/fbdev/via/hw.c|1 -
 drivers/video/fbdev/via/via-core.c  |1 -
 drivers/video/fbdev/via/via_clock.c |2 +-
 drivers/video/fbdev/via/viafbdev.c  |1 -
 7 files changed, 13 insertions(+), 5 deletions(-)

Index: b/drivers/media/platform/via-camera.c
===
--- a/drivers/media/platform/via-camera.c   2018-04-23 13:46:37.0 
+0200
+++ b/drivers/media/platform/via-camera.c   2018-04-23 14:01:07.873322815 
+0200
@@ -27,7 +27,12 @@
 #include 
 #include 
 #include 
+
+#ifdef CONFIG_X86
 #include 
+

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

2018-04-20 Thread Bartlomiej Zolnierkiewicz 
On Thursday, April 05, 2018 04:29:42 PM Mauro Carvalho Chehab wrote:
> This driver builds cleanly with COMPILE_TEST, and it is
> needed in order to allow building drivers/media omap2
> driver.
> 
> So, change the logic there to allow building it.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

This change has broken build on OF=n && COMPILE_TEST=y configs:

https://patchwork.kernel.org/patch/10352465/

[ This is not a problem when compiling for OMAP2 because it depends
  on ARM Multiplatform support which (indirectly) selects OF. ]

Also I would really prefer that people won't merge fbdev related
patches without my ACK and I see this patch in -next coming from
one of your trees..

> ---
>  drivers/video/fbdev/omap2/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/omap2/Kconfig 
> b/drivers/video/fbdev/omap2/Kconfig
> index 0921c4de8407..82008699d253 100644
> --- a/drivers/video/fbdev/omap2/Kconfig
> +++ b/drivers/video/fbdev/omap2/Kconfig
> @@ -1,4 +1,4 @@
> -if ARCH_OMAP2PLUS
> +if ARCH_OMAP2PLUS || COMPILE_TEST
>  
>  source "drivers/video/fbdev/omap2/omapfb/Kconfig"

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 1/4] exynos4-is: Clear isp-i2c adapter power.ignore_children flag

2016-09-01 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, September 01, 2016 01:39:16 PM Sylwester Nawrocki wrote:
> Since commit 04f59143b571161d25315dd52d7a2ecc022cb71a
> ("i2c: let I2C masters ignore their children for PM")
> the power.ignore_children flag is set when registering an I2C
> adapter. Since I2C transfers are not managed by the fimc-isp-i2c
> driver its clients use pm_runtime_* calls directly to communicate
> required power state of the bus controller.
> However when the power.ignore_children flag is set that doesn't
> work, so clear that flag back after registering the adapter.
> While at it drop pm_runtime_enable() call on the i2c_adapter
> as it is already done by the I2C subsystem when registering
> I2C adapter.
> 
> Cc: <sta...@vger.kernel.org> # 4.7+

You may also use "Fixes:" tag to mark the original commit that
this one corrects.

> Reported-by: Marek Szyprowski <m.szyprow...@samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawro...@samsung.com>
> ---
>  drivers/media/platform/exynos4-is/fimc-is-i2c.c | 25 
> ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c 
> b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
> index 7521aa5..03b4246 100644
> --- a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
> +++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
> @@ -55,26 +55,37 @@ static int fimc_is_i2c_probe(struct platform_device *pdev)
>   i2c_adap->algo = _is_i2c_algorithm;
>   i2c_adap->class = I2C_CLASS_SPD;
>  
> + platform_set_drvdata(pdev, isp_i2c);
> + pm_runtime_enable(>dev);
> +
>   ret = i2c_add_adapter(i2c_adap);
>   if (ret < 0) {
>   dev_err(>dev, "failed to add I2C bus %s\n",
>   node->full_name);
> - return ret;
> + goto err_pm_dis;
>   }
>  
> - platform_set_drvdata(pdev, isp_i2c);
> -
> - pm_runtime_enable(>dev);
> - pm_runtime_enable(_adap->dev);
> -
> + /*
> +  * Client drivers of this adapter don't do any I2C transfers as that
> +  * is handled by the ISP firmware.  But we rely on the runtime PM
> +  * state propagation from the clients up to the adapter driver so
> +  * clear the ignore_children flags here.  PM rutnime calls are not

Minor nit:

"rutnime" typo

Otherwise it looks all fine to me.

Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

--
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

Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node

2015-09-28 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
> > Hi Hans,
> > 
> > W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> >> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> >>> From: Marek Szyprowski <m.szyprow...@samsung.com>
> >>>
> >>> Add Exynos 5433 jpeg h/w codec node.
> >>>
> >>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> >>> Signed-off-by: Andrzej Pietrasiewicz <andrze...@samsung.com>
> >>> ---
> >>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +
> >>>   1 file changed, 21 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >>
> >> This dtsi file doesn't exist in the media-git tree. What is the story
> >> here?
> >>
> >> Should this go through a different subsystem?
> >>
> >> I think the media subsystem can take patches 1-3 and whoever does DT
> >> patches can
> >> take this patch, right?
> >>
> > 
> > The cover letter explains that the series is rebased onto Mauro's
> > master with Kukjin's branch merged. The latter does contain
> > the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> > media subsystem and leaving DT patch to someone else is the
> > way to go.
> 
> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
> accepted upstream by arm-soc. He rolled it for few releases but:
> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
> wants to drop it?
> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
> can be probably easily adjusted for ARM64.
> 
> All of this means that Device Tree support for this driver can't be
> merged now and effort for mainlining 5433 may be unfortunately wasted...

Exynos5433 support is being incrementally merged (clocks, drm, phy,
pinctrl, thermal and tty support is already in upstream or -next).

I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
could you please explain?) but I think that this shouldn't not stop
us from continuing Exynos5433 upstreaming effort.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

--
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

Re: MAINTAINERS/s5p: Kamil Debski no longer with Samsung?

2015-08-03 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Sunday, August 02, 2015 01:40:40 PM Joe Perches wrote:
 On Sun, 2015-08-02 at 20:31 +, Mail Delivery System wrote:
  k.deb...@samsung.com: host mailin.samsung.com[203.254.224.12] 
  said: 550 5.1.1
  Recipient address rejected: User unknown (in reply to RCPT TO 
  command)
 
 His email address bounces.
 
 Should MAINTAINERS be updated?

Please wait with these changes, the situation should be clarified soon
(I've added Kamil to Cc).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

 ---
  MAINTAINERS | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 826affa..b5197c7 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -1442,7 +1442,6 @@ F:arch/arm/mach-s5pv210/
  
  ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
  M: Kyungmin Park kyungmin.p...@samsung.com
 -M: Kamil Debski k.deb...@samsung.com
  L: linux-arm-ker...@lists.infradead.org
  L: linux-media@vger.kernel.org
  S: Maintained
 @@ -1450,7 +1449,6 @@ F:drivers/media/platform/s5p-g2d/
  
  ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
  M: Kyungmin Park kyungmin.p...@samsung.com
 -M: Kamil Debski k.deb...@samsung.com
  M: Jeongtae Park jtp.p...@samsung.com
  L: linux-arm-ker...@lists.infradead.org
  L: linux-media@vger.kernel.org
 @@ -8248,9 +8246,8 @@ S:Maintained
  F: drivers/media/usb/pwc/*
  
  PWM FAN DRIVER
 -M: Kamil Debski k.deb...@samsung.com
  L: lm-sens...@lm-sensors.org
 -S: Supported
 +S: Orphan
  F: Documentation/devicetree/bindings/hwmon/pwm-fan.txt
  F: Documentation/hwmon/pwm-fan
  F: drivers/hwmon/pwm-fan.c
 @@ -8906,9 +8903,8 @@ T:
 https://github.com/lmajewski/linux-samsung-thermal.git
  F: drivers/thermal/samsung/
  
  SAMSUNG USB2 PHY DRIVER
 -M: Kamil Debski k.deb...@samsung.com
  L: linux-ker...@vger.kernel.org
 -S: Supported
 +S: Orphan
  F: Documentation/devicetree/bindings/phy/samsung-phy.txt
  F: Documentation/phy/samsung-usb2.txt
  F: drivers/phy/phy-exynos4210-usb2.c

--
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

Re: [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST

2014-09-10 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Tuesday, September 09, 2014 03:54:04 PM Mauro Carvalho Chehab wrote:
 This driver depends on a legacy OMAP DMA API. So, it won't
 compile-test on other archs.
 
 While we might add stubs to the functions, this is not a
 good idea, as the hole API should be replaced.

This is also not a good idea becaouse it would break the driver
for OMAP1 once somebody enables COMPILE_TEST option while also
having ARCH_OMAP1 enabled (which is perfectly fine and shouldn't
cause the driver breakage).  In general COMPILE_TEST option is
completely independent from the arch specific ones and it should
not change behaviour of the existing code.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

 So, for now, let's just remove COMPILE_TEST and wait for
 some time for people to fix. If not fixed, then we'll end
 by removing this driver as a hole.
 
 Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
 
 diff --git a/drivers/media/platform/soc_camera/Kconfig 
 b/drivers/media/platform/soc_camera/Kconfig
 index 6af6c6dccda8..f2776cd415ca 100644
 --- a/drivers/media/platform/soc_camera/Kconfig
 +++ b/drivers/media/platform/soc_camera/Kconfig
 @@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
  config VIDEO_OMAP1
   tristate OMAP1 Camera Interface driver
   depends on VIDEO_DEV  SOC_CAMERA
 - depends on ARCH_OMAP1 || COMPILE_TEST
 + depends on ARCH_OMAP1
   depends on HAS_DMA
   select VIDEOBUF_DMA_CONTIG
   select VIDEOBUF_DMA_SG

--
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

[PATCH] v4l: vsp1: fix driver dependencies

2014-09-01 Thread Bartlomiej Zolnierkiewicz 
Renesas VSP1 Video Processing Engine support should be available
only on Renesas ARM SoCs.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm magnus.d...@gmail.com
---
 drivers/media/platform/Kconfig |1 +
 1 file changed, 1 insertion(+)

Index: b/drivers/media/platform/Kconfig
===
--- a/drivers/media/platform/Kconfig2014-09-01 14:51:37.024553544 +0200
+++ b/drivers/media/platform/Kconfig2014-09-01 15:17:34.284594657 +0200
@@ -213,6 +213,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_VSP1
tristate Renesas VSP1 Video Processing Engine
depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API  HAS_DMA
+   depends on ARCH_SHMOBILE || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.

--
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

[PATCH] v4l: ti-vpe: fix devm_ioremap_resource() return value checking

2014-03-18 Thread Bartlomiej Zolnierkiewicz 
devm_ioremap_resource() returns a pointer to the remapped memory or
an ERR_PTR() encoded error code on failure.  Fix the checks inside
csc_create() and sc_create() accordingly.

Cc: Archit Taneja arc...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
Compile tested only.

 drivers/media/platform/ti-vpe/csc.c |4 ++--
 drivers/media/platform/ti-vpe/sc.c  |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Index: b/drivers/media/platform/ti-vpe/csc.c
===
--- a/drivers/media/platform/ti-vpe/csc.c   2014-03-14 16:45:25.848724010 
+0100
+++ b/drivers/media/platform/ti-vpe/csc.c   2014-03-18 11:01:36.595182833 
+0100
@@ -187,9 +187,9 @@ struct csc_data *csc_create(struct platf
}
 
csc-base = devm_ioremap_resource(pdev-dev, csc-res);
-   if (!csc-base) {
+   if (IS_ERR(csc-base)) {
dev_err(pdev-dev, failed to ioremap\n);
-   return ERR_PTR(-ENOMEM);
+   return csc-base;
}
 
return csc;
Index: b/drivers/media/platform/ti-vpe/sc.c
===
--- a/drivers/media/platform/ti-vpe/sc.c2014-03-14 16:45:25.848724010 
+0100
+++ b/drivers/media/platform/ti-vpe/sc.c2014-03-18 11:02:09.555182273 
+0100
@@ -302,9 +302,9 @@ struct sc_data *sc_create(struct platfor
}
 
sc-base = devm_ioremap_resource(pdev-dev, sc-res);
-   if (!sc-base) {
+   if (IS_ERR(sc-base)) {
dev_err(pdev-dev, failed to ioremap\n);
-   return ERR_PTR(-ENOMEM);
+   return sc-base;
}
 
return sc;

--
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

Re: [PATCH v5 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:13 AM Shaik Ameer Basha wrote:
 This patch adds the Makefile and memory to memory (m2m) interface
 functionality for the SCALER driver.
 
 [arun...@samsung.com: fix compilation issues]
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Signed-off-by: Arun Kumar K arun...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  drivers/media/platform/Kconfig|8 +
  drivers/media/platform/Makefile   |1 +
  drivers/media/platform/exynos-scaler/Makefile |3 +
  drivers/media/platform/exynos-scaler/scaler-m2m.c |  788 
 +

It would be cleaner to add Kconfig + Makefiles in the same patch
that adds core functionality (patch #2) and then switch the order of
patch #2 and patch #3.

  4 files changed, 800 insertions(+)
  create mode 100644 drivers/media/platform/exynos-scaler/Makefile
  create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
 
 diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
 index b2a4403..aec5b80 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -196,6 +196,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
   help
 This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
  
 +config VIDEO_SAMSUNG_EXYNOS_SCALER
 + tristate Samsung Exynos SCALER driver
 + depends on OF  VIDEO_DEV  VIDEO_V4L2  ARCH_EXYNOS5

Please check for EXYNOS5410 and EXYNOS5420 explicitly instead
of checking just for ARCH_EXYNOS5.

Also this config option doesn't need to depend on OF since
the whole EXYNOS support is OF only now.

 + select VIDEOBUF2_DMA_CONTIG
 + select V4L2_MEM2MEM_DEV
 + help
 +   This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
 +
  config VIDEO_SH_VEU
   tristate SuperH VEU mem2mem video processing driver
   depends on VIDEO_DEV  VIDEO_V4L2  HAS_DMA

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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

Re: [PATCH v5 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:12 AM Shaik Ameer Basha wrote:
 This patch adds the core functionality for the SCALER driver.
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  drivers/media/platform/exynos-scaler/scaler.c | 1231 
 +
  drivers/media/platform/exynos-scaler/scaler.h |  376 
  2 files changed, 1607 insertions(+)
  create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
  create mode 100644 drivers/media/platform/exynos-scaler/scaler.h

[...]

 +static int scaler_probe(struct platform_device *pdev)
 +{
 + struct scaler_dev *scaler;
 + struct resource *res;
 + struct device *dev = pdev-dev;
 + int ret;
 +
 + if (!dev-of_node)
 + return -ENODEV;
 +
 + scaler = devm_kzalloc(dev, sizeof(*scaler), GFP_KERNEL);
 + if (!scaler)
 + return -ENOMEM;
 +
 + scaler-pdev = pdev;
 + scaler-variant = scaler_get_variant_data(pdev);
 +
 + init_waitqueue_head(scaler-irq_queue);
 + spin_lock_init(scaler-slock);
 + mutex_init(scaler-lock);
 + scaler-clock = ERR_PTR(-EINVAL);
 +
 + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 + scaler-regs = devm_request_and_ioremap(dev, res);
 + if (!scaler-regs)
 + return -ENODEV;
 +
 + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 + if (!res) {
 + dev_err(dev, failed to get IRQ resource\n);
 + return -ENXIO;
 + }
 +
 + ret = scaler_clk_get(scaler);
 + if (ret  0)
 + return ret;
 +
 + ret = devm_request_irq(dev, res-start, scaler_irq_handler,
 + 0, pdev-name, scaler);
 + if (ret  0) {
 + dev_err(dev, failed to install irq (%d)\n, ret);
 + goto err_clk;
 + }
 +
 + platform_set_drvdata(pdev, scaler);
 + pm_runtime_enable(dev);
 +
 + /* Initialize the continious memory allocator */
 + scaler-alloc_ctx = vb2_dma_contig_init_ctx(dev);
 + if (IS_ERR(scaler-alloc_ctx)) {
 + ret = PTR_ERR(scaler-alloc_ctx);
 + goto err_clk;
 + }
 +
 + ret = v4l2_device_register(dev, scaler-v4l2_dev);
 + if (ret  0)
 + goto err_clk;
 +
 + ret = scaler_register_m2m_device(scaler);
 + if (ret  0)
 + goto err_v4l2;
 +
 + dev_info(dev, registered successfully\n);
 + return 0;
 +
 +err_v4l2:
 + v4l2_device_unregister(scaler-v4l2_dev);
 +err_clk:
 + scaler_clk_put(scaler);

vb2_dma_contig_cleanup_ctx() and pm_runtime_disable() calls on
failure are missing

 + return ret;
 +}
 +
 +static int scaler_remove(struct platform_device *pdev)
 +{
 + struct scaler_dev *scaler = platform_get_drvdata(pdev);
 +
 + scaler_unregister_m2m_device(scaler);
 + v4l2_device_unregister(scaler-v4l2_dev);
 +
 + vb2_dma_contig_cleanup_ctx(scaler-alloc_ctx);
 + pm_runtime_disable(pdev-dev);
 + scaler_clk_put(scaler);
 +
 + scaler_dbg(scaler, %s driver unloaded\n, pdev-name);
 + return 0;
 +}

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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

Re: [PATCH v5 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver

2014-01-09 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Thursday, January 09, 2014 08:58:14 AM Shaik Ameer Basha wrote:
 This patch adds the DT binding documentation for the
 Exynos5420/5410 based SCALER device driver.
 
 Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  .../devicetree/bindings/media/exynos5-scaler.txt   |   22 
 
  1 file changed, 22 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
 
 diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt 
 b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
 new file mode 100644
 index 000..9328e7d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
 @@ -0,0 +1,22 @@
 +* Samsung Exynos5 SCALER device
 +
 +SCALER is used for scaling, blending, color fill and color space
 +conversion on EXYNOS[5420/5410] SoCs.
 +
 +Required properties:
 +- compatible: should be samsung,exynos5420-scaler or
 + samsung,exynos5410-scaler
 +- reg: should contain SCALER physical address location and length
 +- interrupts: should contain SCALER interrupt number
 +- clocks: should contain the SCALER clock specifier, from the
 + common clock bindings
 +- clock-names: should be scaler
 +
 +Example:
 + scaler_0: scaler@1280 {
 + compatible = samsung,exynos5420-scaler;
 + reg = 0x1280 0x1000;
 + interrupts = 0 220 0;
 + clocks = clock 381;
 + clock-names = scaler;
 + };

Your patchset adds support for EXYNOS5 SCALER but doesn't add any real
users of it yet.  Could you please explain why?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

--
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

Re: [PATCH v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-24 Thread Bartlomiej Zolnierkiewicz 

Hi Tomasz,

On Tuesday, September 24, 2013 11:43:53 AM Tomasz Stanislawski wrote:
 Hi,
 
 On 09/23/2013 05:48 PM, Bartlomiej Zolnierkiewicz wrote:
  
  Hi Tomasz,
  
  On Monday, September 23, 2013 04:50:01 PM Tomasz Stanislawski wrote:
  Hello,
  May I ask what is the rationale for this patch?
  To reduce a few lines of code?
  
  This patch makes source code more generic-like and easier to follow (mxd_r*
 
 more generic(-like?) - NOT. Using mxr_ macros is a more generic way to 
 produce logs

Using mxr_* macros is not more generic, don't be silly. :)

 because one can change only one line to change error format for the whole 
 module.
 For example, in case of mxr_ family, a patch adding function name to debug 
 message
 would require just a few lines patch. Using in case of dev_ family, one has to
 produce 200-lines of highly conflicting patch.

* For over two and half year since the s5p-tv driver introduction there was no 
such
  need and it is very _unlikely_ that it will be one in the future.

* Optimizing for the completely _theorethical_ future patches size is just
  over-enginneering IMHO.

 'easier to follow' - MAYBE. I agree that some people may prefer to
 see more directly what is happening, but tell me if you really consider line:
 
 mxr_dbg(mdev, this is debug\n);
 
 as a very confusing and obfuscated piece of code.
 
 COME ON!

It is confusing becuase you have to lookup what mxr_dbg() actually does,
extra time needs to be spent on seeing that the mxr_* macros are just
a needless wrappers. You also have to recall it from the memory or look it
up again if you come back to the code some time later. Just stop arguing
about this trivial change and Ack Mateusz's patch already. :)

PS Please try to not top post, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

 Regards,
 TS
 
  macros currently only obfuscate the code and make them harder to read for
  everybody, maybe besides the original driver author ;). Removal of few
  superfluous lines of code is just a bonus.
  
  Or to give up possibility of changing message format in just one place?
  
  For over two and half year (since s5p-tv driver introduction in Feb 2011)
  such change was not needed and it doesn't seem that keeping the code to
  allow such possibility is worth an added code obfuscation.
  
  Besides you can easily script a change to message format so in practice
  I don't see a real advantage of keeping non-standard messaging macros
  just for easing a potential message format conversion.
  
  I could see migrating from mxr_* to pr_* could seen as the fix, but not 
  this.
  
  Such migration seems to be pointless as you would have to add an extra
  argument to pr_* to not lose the device information.
 
 There is something called pr_fmt. It may help with mentioned issue.
 
  
 
 
 
  Best regards,
  --
  Bartlomiej Zolnierkiewicz
  Samsung RD Institute Poland
  Samsung Electronics
  
  Waiting for reply,
  Tomasz Stanislawski
 
 
  On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
  Replace mxr_dbg, mxr_info and mxr_warn by generic solution.
 
  Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/media/platform/s5p-tv/mixer.h   |  12 ---
   drivers/media/platform/s5p-tv/mixer_drv.c   |  47 ++-
   drivers/media/platform/s5p-tv/mixer_grp_layer.c |   2 +-
   drivers/media/platform/s5p-tv/mixer_reg.c   |   6 +-
   drivers/media/platform/s5p-tv/mixer_video.c | 100 
  
   drivers/media/platform/s5p-tv/mixer_vp_layer.c  |   2 +-
   6 files changed, 78 insertions(+), 91 deletions(-)
 

--
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

Re: [PATCH v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-24 Thread Bartlomiej Zolnierkiewicz 

Hi Tomasz,

On Tuesday, September 24, 2013 02:52:44 PM Tomasz Stanislawski wrote:
 On 09/23/2013 07:44 PM, Joe Perches wrote:
  On Mon, 2013-09-23 at 17:48 +0200, Bartlomiej Zolnierkiewicz wrote:
  On Monday, September 23, 2013 04:50:01 PM Tomasz Stanislawski wrote:
  May I ask what is the rationale for this patch?
  To reduce a few lines of code?
  This patch makes source code more generic-like and easier to follow (mxd_r*
  macros currently only obfuscate the code and make them harder to read for
  everybody, maybe besides the original driver author ;). Removal of few
  superfluous lines of code is just a bonus.
  I don't see any significant issue with this change.
  Using generic mechanisms is good.
 
 
 Hi Joe,
 Sorry for flaming but please let me explain reasons of my opposition to this 
 patch.
 
 1. It is true that there was no change in mixer messages for 2.5 year in 
 MAINLINE.
 But sometimes I used modification of mxr_ macros while testing the driver.
 Therefore those macros are useful for me.

For debug you can also trivially do this with dev_*, just #undef them in
your driver and define your versions.

 2. The other problem with this patch is its high 'conflictness' during 
 merging.
 Unfortunately, sometimes I have to use s5p-tv on platform and configuration
 that is only supported in older versions of the kernel + some integration 
 patches.
 The s5p-tv differs from mainline version in those kernels. Therefore
 I would need to keep two versions of patches, one for old and another one for 
 new kernel.

You would need to do it or not, depending on the actual change.

Anyway in the reality there is practically no development happening on
this driver. During two and half year you only did two small fixes to
the mixer driver (BTW your other drivers from s5p-tv directory are not
using any custom macros):

3c44efd [media] v4l: s5p-tv: mixer: support for dmabuf exporting
fa77521 [media] v4l: s5p-tv: mixer: support for dmabuf importing

 Or backport the 'cleanup patch' and all experimental patches above it.

The cost to backport it if/when needed should be pretty small, it is not
a big change:

 6 files changed, 78 insertions(+), 91 deletions(-)

 3. As I understand the coding guidelines asked to use dev_* to ensure that all
 error messages have information about the device. There is no change in 
 format of
 errors after this patch. So they do not change anything from userland point 
 of view.

Which is actually a good thing (same functionality, less code).

 4. I looked for other files where macro for dev_err is used.
 I tried following shell command on v3.12-rc2.
 
 git grep -A1 _err( | grep -A1 '#define' | grep -B1 dev_err
 
 then processing results using
 grep -v ^-- | cut -d: -f 1 | sort -u | wc
 
 produced 55 files. Among them, the files below makes use of a macro that is
 directly expanded to dev_err(dev_ptr, fmt, ...) without any changes in format.
 
 drivers/firewire/ohci.c
 drivers/gpu/drm/i2c/ch7006_priv.h
 drivers/gpu/drm/i2c/sil164_drv.c
 drivers/infiniband/hw/mthca/mthca_dev.h
 drivers/infiniband/hw/qib/qib.h
 drivers/media/platform/marvell-ccic/cafe-driver.c
 drivers/media/platform/marvell-ccic/mcam-core.c
 drivers/media/platform/s5p-tv/mixer.h
 drivers/media/platform/via-camera.c
 drivers/mtd/devices/docg3.h
 drivers/net/ethernet/broadcom/bgmac.h
 drivers/net/ethernet/chelsio/cxgb3/common.h
 drivers/net/ethernet/intel/e1000/e1000.h
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
 drivers/net/ethernet/mellanox/mlx4/mlx4.h
 drivers/net/wireless/iwlegacy/common.h
 drivers/pci/hotplug/pciehp.h
 drivers/pci/hotplug/shpchp.h
 drivers/remoteproc/ste_modem_rproc.c
 drivers/scsi/csiostor/csio_hw.h
 drivers/staging/fwserial/fwserial.c
 drivers/usb/atm/usbatm.h
 drivers/usb/host/ehci.h
 drivers/usb/host/fhci.h
 drivers/usb/host/fotg210-hcd.c
 drivers/usb/host/fusbh200-hcd.c
 drivers/usb/host/ohci.h
 drivers/usb/host/oxu210hp-hcd.c
 drivers/usb/host/xhci.h
 include/linux/hid.h
 include/net/cfg80211.h
 
 Other files makes only cosmetic changes to format, so they might still be 
 worth to
 be 'demacronized'. So I think we can consider that macros wrapping dev_* is 
 still
 a widely used technique so I ask for a good reason before changing the driver.
 
 If one still would like to continue a 'dev_* cleanup crusade' then I kindly
 ask to create a big patchset that fixes all over mentioned files.
 If most of their maintainers accepts the patches I promise to accept it in
 s5p-tv.

OK.

 Currently, due to mentioned reason the patch is not a cleanup-up for me.
 And since I am still a maintainer of this god-forgotten driver I am
 going NACK this patch because it makes my work more difficult and because
 this patch provides only (if any) relative aesthetic gain.

I won't argue about this anymore because I find the whole discussion a bit
silly. The change itself is obvious, trivial and cost to either port new
patches over it or backport it to older private trees should be very small
(as I sit next

Re: [PATCH v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-23 Thread Bartlomiej Zolnierkiewicz 

Hi Tomasz,

On Monday, September 23, 2013 04:50:01 PM Tomasz Stanislawski wrote:
 Hello,
 May I ask what is the rationale for this patch?
 To reduce a few lines of code?

This patch makes source code more generic-like and easier to follow (mxd_r*
macros currently only obfuscate the code and make them harder to read for
everybody, maybe besides the original driver author ;). Removal of few
superfluous lines of code is just a bonus.

 Or to give up possibility of changing message format in just one place?

For over two and half year (since s5p-tv driver introduction in Feb 2011)
such change was not needed and it doesn't seem that keeping the code to
allow such possibility is worth an added code obfuscation.

Besides you can easily script a change to message format so in practice
I don't see a real advantage of keeping non-standard messaging macros
just for easing a potential message format conversion.

 I could see migrating from mxr_* to pr_* could seen as the fix, but not this.

Such migration seems to be pointless as you would have to add an extra
argument to pr_* to not lose the device information.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

 Waiting for reply,
 Tomasz Stanislawski
 
 
 On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
  Replace mxr_dbg, mxr_info and mxr_warn by generic solution.
  
  Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/media/platform/s5p-tv/mixer.h   |  12 ---
   drivers/media/platform/s5p-tv/mixer_drv.c   |  47 ++-
   drivers/media/platform/s5p-tv/mixer_grp_layer.c |   2 +-
   drivers/media/platform/s5p-tv/mixer_reg.c   |   6 +-
   drivers/media/platform/s5p-tv/mixer_video.c | 100 
  
   drivers/media/platform/s5p-tv/mixer_vp_layer.c  |   2 +-
   6 files changed, 78 insertions(+), 91 deletions(-)
  
  diff --git a/drivers/media/platform/s5p-tv/mixer.h 
  b/drivers/media/platform/s5p-tv/mixer.h
  index 04e6490..c054106 100644
  --- a/drivers/media/platform/s5p-tv/mixer.h
  +++ b/drivers/media/platform/s5p-tv/mixer.h
  @@ -327,18 +327,6 @@ void mxr_streamer_put(struct mxr_device *mdev);
   void mxr_get_mbus_fmt(struct mxr_device *mdev,
  struct v4l2_mbus_framefmt *mbus_fmt);
   
  -/* Debug */
  -
  -#define mxr_err(mdev, fmt, ...)  dev_err(mdev-dev, fmt, ##__VA_ARGS__)
  -#define mxr_warn(mdev, fmt, ...) dev_warn(mdev-dev, fmt, ##__VA_ARGS__)
  -#define mxr_info(mdev, fmt, ...) dev_info(mdev-dev, fmt, ##__VA_ARGS__)
  -
  -#ifdef CONFIG_VIDEO_SAMSUNG_S5P_MIXER_DEBUG
  -   #define mxr_dbg(mdev, fmt, ...)  dev_dbg(mdev-dev, fmt, ##__VA_ARGS__)
  -#else
  -   #define mxr_dbg(mdev, fmt, ...)  do { (void) mdev; } while (0)
  -#endif
  -
   /* accessing Mixer's and Video Processor's registers */
   
   void mxr_vsync_set_update(struct mxr_device *mdev, int en);
  diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c 
  b/drivers/media/platform/s5p-tv/mixer_drv.c
  index 51805a5..8ce7c3e 100644
  --- a/drivers/media/platform/s5p-tv/mixer_drv.c
  +++ b/drivers/media/platform/s5p-tv/mixer_drv.c
  @@ -59,7 +59,7 @@ void mxr_streamer_get(struct mxr_device *mdev)
   {
  mutex_lock(mdev-mutex);
  ++mdev-n_streamer;
  -   mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
  +   dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
  if (mdev-n_streamer == 1) {
  struct v4l2_subdev *sd = to_outsd(mdev);
  struct v4l2_mbus_framefmt mbus_fmt;
  @@ -91,7 +91,7 @@ void mxr_streamer_put(struct mxr_device *mdev)
   {
  mutex_lock(mdev-mutex);
  --mdev-n_streamer;
  -   mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
  +   dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
  if (mdev-n_streamer == 0) {
  int ret;
  struct v4l2_subdev *sd = to_outsd(mdev);
  @@ -113,7 +113,7 @@ void mxr_output_get(struct mxr_device *mdev)
   {
  mutex_lock(mdev-mutex);
  ++mdev-n_output;
  -   mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
  +   dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
  /* turn on auxiliary driver */
  if (mdev-n_output == 1)
  v4l2_subdev_call(to_outsd(mdev), core, s_power, 1);
  @@ -124,7 +124,7 @@ void mxr_output_put(struct mxr_device *mdev)
   {
  mutex_lock(mdev-mutex);
  --mdev-n_output;
  -   mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
  +   dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
  /* turn on auxiliary driver */
  if (mdev-n_output == 0)
  v4l2_subdev_call(to_outsd(mdev), core, s_power, 0);
  @@ -159,42 +159,42 @@ static int mxr_acquire_plat_resources(struct 
  mxr_device *mdev,
   
  res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mxr);
  if (res == NULL) {
  -   mxr_err(mdev, get memory resource failed.\n);
  +   dev_err(mdev-dev, get memory resource failed.\n);
  ret = -ENXIO