Re: [PATCH v4] drm/exynos: prepare FIMD clocks

2013-04-21 Thread Tomasz Figa
Hi,

On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
 On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
  While migrating to common clock framework (CCF), I found that the FIMD
  clocks were pulled down by the CCF.
  If CCF finds any clock(s) which has NOT been claimed by any of the
  drivers, then such clock(s) are PULLed low by CCF.
  
  Calling clk_prepare() for FIMD clocks fixes the issue.
  
  This patch also replaces clk_disable() with clk_unprepare() during
  exit, since clk_prepare() is called in fimd_probe().
 
 I asked you about fixing your commit log too.. It still looks incorrect
 to me.
 
 This patch doesn't have anything to do with CCF pulling clocks down, but
 calling clk_prepare() before clk_enable() is must now.. that's it..
 nothing more.
 

I fully agree.

The message should be something like:

Common Clock Framework introduced the need to prepare clocks before 
enabling them, otherwise clk_enable() fails. This patch adds clk_prepare 
calls to the driver.

and that's all.

What you are observing as CCF pulling clocks down is the fact that 
clk_enable() fails if the clock is not prepared and so the clock is not 
enabled in result.

Another thing is that CCF is not pulling anything down. GPIO pins can be 
pulled down (or up or not pulled), but clocks can be masked, gated or 
simply disabled - this does not imply their signal level.

  Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
  ---
  
  Changes since v3:
  - added clk_prepare() in fimd_probe() and clk_unprepare() in
  fimd_remove() 
   as suggested by Viresh Kumar viresh.ku...@linaro.org
  
  Changes since v2:
  - moved clk_prepare_enable() and clk_disable_unprepare() from
  fimd_probe() to fimd_clock() as suggested by Inki Dae
  inki@samsung.com 
  Changes since v1:
  - added error checking for clk_prepare_enable() and also
  replaced
  clk_disable() with clk_disable_unprepare() during exit.
  
  ---
  
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |   14 --
   1 file changed, 12 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
  100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
  *pdev) 
  return ret;
  
  }
  
  +   ret = clk_prepare(ctx-bus_clk);
  +   if (ret  0)
  +   return ret;
  +
  +   ret = clk_prepare(ctx-lcd_clk);
  +   if  (ret  0) {
  +   clk_unprepare(ctx-bus_clk);
  +   return ret;
  +   }
  +

Why not just simply use clk_prepare_enable() instead of all calls to 
clk_enable() in the driver?

Same goes for s/clk_disable/clk_disable_unprepare/ .

  
  ctx-vidcon0 = pdata-vidcon0;
  ctx-vidcon1 = pdata-vidcon1;
  ctx-default_win = pdata-default_win;
  
  @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
  *pdev) 
  if (ctx-suspended)
  
  goto out;
  
  -   clk_disable(ctx-lcd_clk);
  -   clk_disable(ctx-bus_clk);
  +   clk_unprepare(ctx-lcd_clk);
  +   clk_unprepare(ctx-bus_clk);
 
 This looks wrong again.. You still need to call clk_disable() to make
 clk enabled
 count zero...

Viresh is right again here.

Best regards,
Tomasz

--
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 v4] drm/exynos: prepare FIMD clocks

2013-04-21 Thread Tomasz Figa
Hi Inki,

On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
 2013/4/21 Tomasz Figa tomasz.f...@gmail.com
 
  Hi,
  
  On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
   On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
While migrating to common clock framework (CCF), I found that the
FIMD
clocks were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.

Calling clk_prepare() for FIMD clocks fixes the issue.

This patch also replaces clk_disable() with clk_unprepare() during
exit, since clk_prepare() is called in fimd_probe().
   
   I asked you about fixing your commit log too.. It still looks
   incorrect
   to me.
   
   This patch doesn't have anything to do with CCF pulling clocks down,
   but calling clk_prepare() before clk_enable() is must now.. that's
   it.. nothing more.
  
  I fully agree.
  
  The message should be something like:
  
  Common Clock Framework introduced the need to prepare clocks before
  enabling them, otherwise clk_enable() fails. This patch adds
  clk_prepare calls to the driver.
  
  and that's all.
  
  What you are observing as CCF pulling clocks down is the fact that
  clk_enable() fails if the clock is not prepared and so the clock is
  not
  enabled in result.
  
  Another thing is that CCF is not pulling anything down. GPIO pins can
  be pulled down (or up or not pulled), but clocks can be masked, gated
  or simply disabled - this does not imply their signal level.
  
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---

Changes since v3:
- added clk_prepare() in fimd_probe() and clk_unprepare()
in
fimd_remove()

 as suggested by Viresh Kumar viresh.ku...@linaro.org

Changes since v2:
- moved clk_prepare_enable() and clk_disable_unprepare()
from
fimd_probe() to fimd_clock() as suggested by Inki Dae
inki@samsung.com

Changes since v1:
- added error checking for clk_prepare_enable() and also
replaced
clk_disable() with clk_disable_unprepare() during exit.

---

 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
*pdev)

return ret;

}

+   ret = clk_prepare(ctx-bus_clk);
+   if (ret  0)
+   return ret;
+
+   ret = clk_prepare(ctx-lcd_clk);
+   if  (ret  0) {
+   clk_unprepare(ctx-bus_clk);
+   return ret;
+   }
+
  
  Why not just simply use clk_prepare_enable() instead of all calls to
  clk_enable() in the driver?
  
  Same goes for s/clk_disable/clk_disable_unprepare/ .
 
 I agree with you. Using clk_prepare_enable() is more clear. Actually I
 had already commented on this. Please see the patch v2. But this way
 also looks good to me.

Well, both versions are technically correct and will have the same effect 
for Exynos SoC clocks, since only enable/disable ops change hardware 
state.

However if we look at general meaning of those generic ops, the clock will 
remain prepared for all the time the driver is loaded, even if the device 
is runtime suspended. Again on Exynos SoCs this won't have any effect, but 
I think we should respect general Common Clock Framework semantics anyway.

ctx-vidcon0 = pdata-vidcon0;
ctx-vidcon1 = pdata-vidcon1;
ctx-default_win = pdata-default_win;

@@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
*pdev)

if (ctx-suspended)

goto out;

-   clk_disable(ctx-lcd_clk);
-   clk_disable(ctx-bus_clk);
+   clk_unprepare(ctx-lcd_clk);
+   clk_unprepare(ctx-bus_clk);
   
   This looks wrong again.. You still need to call clk_disable() to
   make
   clk enabled
   count zero...
  
  Viresh is right again here.
 
 Ok, you two guys say together this looks wrong so I'd like to take more
 checking. I thought that clk-clk_enable is 1 at here and it would be 0
 by pm_runtimg_put_sync(). Is there any my missing point?

You're reasoning is correct, but only assuming that runtime PM is enabled. 
When it is disabled, pm_runtime_put_sync() is a no-op.

Well, after digging into the exynos_drm_fimd driver a bit more, it seems 
like its power management code needs a serious rework, because I was able 
to find more problems:

1) fimd_activate

[PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries

2013-04-21 Thread Tomasz Figa
Several entries in MAINTAINERS file related to Samsung SoCs do not point
to linux-samsung-soc mailing list, which is supposed to collect all
Samsung SoC-related threads, to ease following of Samsung SoC-related
work. This leads to a problem with people skipping this mailing list in
their posts, even though they are related to Samsung SoCs.

This patch adds pointers to linux-samsung-soc mailing list to affected
entries of MAINTAINERS file.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c0d68b..07cb8da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1139,6 +1139,7 @@ F:arch/arm/mach-exynos*/
 ARM/SAMSUNG MOBILE MACHINE SUPPORT
 M: Kyungmin Park kyungmin.p...@samsung.com
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-s5pv210/mach-aquila.c
 F: arch/arm/mach-s5pv210/mach-goni.c
@@ -1150,6 +1151,7 @@ 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
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/media/platform/s5p-g2d/
 
@@ -1158,6 +1160,7 @@ M:Kyungmin Park kyungmin.p...@samsung.com
 M: Sylwester Nawrocki s.nawro...@samsung.com
 L: linux-arm-ker...@lists.infradead.org
 L: linux-media@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/plat-samsung/include/plat/*fimc*
 F: drivers/media/platform/s5p-fimc/
@@ -1168,6 +1171,7 @@ 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
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/plat-samsung/s5p-dev-mfc.c
 F: drivers/media/platform/s5p-mfc/
@@ -1177,6 +1181,7 @@ M:Kyungmin Park kyungmin.p...@samsung.com
 M: Tomasz Stanislawski t.stanisl...@samsung.com
 L: linux-arm-ker...@lists.infradead.org
 L: linux-media@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/media/platform/s5p-tv/
 
@@ -2679,6 +2684,7 @@ M:Joonyoung Shim jy0922.s...@samsung.com
 M: Seung-Woo Kim sw0312@samsung.com
 M: Kyungmin Park kyungmin.p...@samsung.com
 L: dri-de...@lists.freedesktop.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
 S: Supported
 F: drivers/gpu/drm/exynos
@@ -3142,6 +3148,7 @@ F:Documentation/extcon/
 EXYNOS DP DRIVER
 M: Jingoo Han jg1@samsung.com
 L: linux-fb...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/video/exynos/exynos_dp*
 F: include/video/exynos_dp*
@@ -3151,6 +3158,7 @@ M:Inki Dae inki@samsung.com
 M: Donghwa Lee dh09@samsung.com
 M: Kyungmin Park kyungmin.p...@samsung.com
 L: linux-fb...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/video/exynos/exynos_mipi*
 F: include/video/exynos_mipi*
@@ -6892,12 +6900,14 @@ F:  drivers/platform/x86/samsung-laptop.c
 SAMSUNG AUDIO (ASoC) DRIVERS
 M: Sangbeom Kim sbki...@samsung.com
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Supported
 F: sound/soc/samsung
 
 SAMSUNG FRAMEBUFFER DRIVER
 M: Jingoo Han jg1@samsung.com
 L: linux-fb...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/video/s3c-fb.c
 
@@ -7087,6 +7097,7 @@ F:drivers/mmc/host/sdhci-pltfm.[ch]
 SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER
 M: Ben Dooks ben-li...@fluff.org
 L: linux-...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
 F: drivers/mmc/host/sdhci-s3c.c
 
-- 
1.8.2.1

--
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 v4] drm/exynos: prepare FIMD clocks

2013-04-22 Thread Tomasz Figa
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
   2013/4/21 Tomasz Figa tomasz.f...@gmail.com
  
Hi,
   
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
 On 8 April 2013 16:37, Vikas Sajjan vikas.saj...@linaro.org wrote:
  While migrating to common clock framework (CCF), I found that the
  FIMD
  clocks were pulled down by the CCF.
  If CCF finds any clock(s) which has NOT been claimed by any of the
  drivers, then such clock(s) are PULLed low by CCF.
 
  Calling clk_prepare() for FIMD clocks fixes the issue.
 
  This patch also replaces clk_disable() with clk_unprepare() during
  exit, since clk_prepare() is called in fimd_probe().

 I asked you about fixing your commit log too.. It still looks
 incorrect
 to me.

 This patch doesn't have anything to do with CCF pulling clocks down,
 but calling clk_prepare() before clk_enable() is must now.. that's
 it.. nothing more.
   
I fully agree.
   
The message should be something like:
   
Common Clock Framework introduced the need to prepare clocks before
enabling them, otherwise clk_enable() fails. This patch adds
clk_prepare calls to the driver.
   
and that's all.
   
What you are observing as CCF pulling clocks down is the fact that
clk_enable() fails if the clock is not prepared and so the clock is
not
enabled in result.
   
Another thing is that CCF is not pulling anything down. GPIO pins can
be pulled down (or up or not pulled), but clocks can be masked, gated
or simply disabled - this does not imply their signal level.
   
  Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
  ---
 
  Changes since v3:
  - added clk_prepare() in fimd_probe() and clk_unprepare()
  in
  fimd_remove()
 
   as suggested by Viresh Kumar viresh.ku...@linaro.org
 
  Changes since v2:
  - moved clk_prepare_enable() and clk_disable_unprepare()
  from
  fimd_probe() to fimd_clock() as suggested by Inki Dae
  inki@samsung.com
 
  Changes since v1:
  - added error checking for clk_prepare_enable() and also
  replaced
  clk_disable() with clk_disable_unprepare() during exit.
 
  ---
 
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |   14 --
   1 file changed, 12 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
  100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
  *pdev)
 
  return ret;
 
  }
 
  +   ret = clk_prepare(ctx-bus_clk);
  +   if (ret  0)
  +   return ret;
  +
  +   ret = clk_prepare(ctx-lcd_clk);
  +   if  (ret  0) {
  +   clk_unprepare(ctx-bus_clk);
  +   return ret;
  +   }
  +
   
Why not just simply use clk_prepare_enable() instead of all calls to
clk_enable() in the driver?
   
Same goes for s/clk_disable/clk_disable_unprepare/ .
  
   I agree with you. Using clk_prepare_enable() is more clear. Actually I
   had already commented on this. Please see the patch v2. But this way
   also looks good to me.
  
  
  Well, both versions are technically correct and will have the same effect
  for Exynos SoC clocks, since only enable/disable ops change hardware
  state.
  
  However if we look at general meaning of those generic ops, the clock will
  remain prepared for all the time the driver is loaded, even if the device
  
  
  
  Right, so I said previous one is more clear. I gonna revert current one 
and then merge previous one(v3)
  
  
   
  is runtime suspended. Again on Exynos SoCs this won't have any effect, but
  I think we should respect general Common Clock Framework semantics anyway.
  
  
  ctx-vidcon0 = pdata-vidcon0;
  ctx-vidcon1 = pdata-vidcon1;
  ctx-default_win = pdata-default_win;
 
  @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
  *pdev)
 
  if (ctx-suspended)
 
  goto out;
 
  -   clk_disable(ctx-lcd_clk);
  -   clk_disable(ctx-bus_clk);
  +   clk_unprepare(ctx-lcd_clk);
  +   clk_unprepare(ctx-bus_clk);

 This looks wrong again.. You still need to call clk_disable() to
 make
 clk enabled
 count zero...
   
Viresh is right again here.
  
   Ok, you two guys say together this looks wrong so I'd like to take more
   checking. I thought that clk-clk_enable is 1 at here and it would be 0
   by pm_runtimg_put_sync(). Is there any my missing

Re: [PATCH v4] drm/exynos: prepare FIMD clocks

2013-04-22 Thread Tomasz Figa
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
 On 21 April 2013 20:13, Tomasz Figa tomasz.f...@gmail.com wrote:
  3) after those two changes, all that remains is to fix compliance with
  Common Clock Framework, in other words:
  
  s/clk_enable/clk_prepare_enable/
  
  and
  
  s/clk_disable/clk_disable_unprepare/
 
 We don't have to call  clk_{un}prepare() everytime for your platform as
 you aren't doing anything in it. So just call them once at probe/remove and
 call clk_enable/disable everywhere else.

Can you assure that in future SoCs, on which this driver will be used, this 
assumption will still hold true or even that in current Exynos driver this 
behavior won't be changed?

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Kernel and System Framework

--
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 v4] drm/exynos: prepare FIMD clocks

2013-04-22 Thread Tomasz Figa
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote:
 On 04/22/2013 12:03 PM, Inki Dae wrote:
   Also looks good to me. But what if power domain was disabled without
   pm
   runtime? In this case, you must enable the power domain at machine
   code or
   bootloader somewhere. This way would not only need some hard codes
   to turn
   the power domain on but also not manage power management fully. This
   is same as only the use of pm runtime interface(needing some hard
   codes without pm runtime) so I don't prefer to add
   clk_enable/disable to fimd probe(). I quite tend to force only the
   use of pm runtime as possible. So please add the hard codes to
   machine code or bootloader like you did for power domain if you
   want to use drm fimd without pm runtime.
  
  That's not how the runtime PM, clock subsystems work:
  
  1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be
  kept
  powered on all the time.
  
  2) Common Clock Framework will always gate all clocks that have zero
  enable_count. Note that CCF support for Exynos is already merged for
  3.10 and it will be the only available clock support method for
  Exynos.
  
  AFAIK, drivers must work correctly in both cases, with
  CONFIG_PM_RUNTIME
  enabled and disabled.
  
  Then is the driver worked correctly if the power domain to this device was
  disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()?  I
  think, in this case, the device wouldn't be worked correctly because the
  power of the device remains off. So you must enable the power domain
  somewhere. What is the difference between these two cases?
 
 How about making the driver dependant on PM_RUNTIME and making it always
 use pm_runtime_* API, regardless if the platform actually implements runtime
 PM or not ? Is there any issue in using the Runtime PM core always, rather
 than coding any workarounds in drivers when PM_RUNTIME is disabled ?

I don't think this is a good idea. This would mean that any user that from 
some reasons don't want to use PM_RUNTIME, would not be able to use the driver 
anymore.

Rafael, Kevin, do you have any opinion on this?

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Kernel and System Framework

--
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 v4] drm/exynos: prepare FIMD clocks

2013-04-22 Thread Tomasz Figa
On Monday 22 of April 2013 12:05:49 Sylwester Nawrocki wrote:
 On 04/22/2013 11:56 AM, Tomasz Figa wrote:
  On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
  On 21 April 2013 20:13, Tomasz Figa tomasz.f...@gmail.com wrote:
  3) after those two changes, all that remains is to fix compliance with
  Common Clock Framework, in other words:
  
  s/clk_enable/clk_prepare_enable/
  
  and
  
  s/clk_disable/clk_disable_unprepare/
  
  We don't have to call  clk_{un}prepare() everytime for your platform as
  you aren't doing anything in it. So just call them once at probe/remove
  and
  call clk_enable/disable everywhere else.
 
 Yes, I agree with that. Additionally clk_(un)prepare must not be called in
 atomic context, so some drivers will have to work like this anyway.
 Or the clocks could be prepared/unprepared in the device open/close file op
 for instance.

Well, I don't think drivers should make any assumptions how particular clk ops 
are implemented on particular platform.

Instead, generic semantics of Common Clock Framework should be obeyed, which 
AFAIK are:
1) Each clock must be prepared before enabling.
2) clk_prepare() can not be called from atomic contexts.
3) clk_prepare_enable() can be used instead of clk_prepare() + clk_enable() 
when the driver does not need to enable the clock from atomic context.

Since the Exynos DRM FIMD driver does not need to do call any clock operations 
in atomic contexts, the approach keeping the clock handling as simple as 
possible would be to just replace all clk_{enable,disable} with 
clk_{prepare_enable,disable_unprepare}, as I suggested.

CCing Mike, the maintainer of Common Clock Framework, since he's the right 
person to pass any judgements when it is about clocks.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Kernel and System Framework

--
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: Introduce a new helper framework for buffer synchronization

2013-05-13 Thread Tomasz Figa
Hi,

On Monday 13 of May 2013 20:24:01 Inki Dae wrote:
  -Original Message-
  From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
  Sent: Monday, May 13, 2013 6:52 PM
  To: Inki Dae
  Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
  ker...@lists.infradead.org; linux-media@vger.kernel.org;
  'linux-fbdev';
  'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'
  Subject: Re: Introduce a new helper framework for buffer
  synchronization 
  Op 13-05-13 11:21, Inki Dae schreef:
   -Original Message-
   From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
   Sent: Monday, May 13, 2013 5:01 PM
   To: Inki Dae
   Cc: Rob Clark; Daniel Vetter; DRI mailing list; linux-arm-
   ker...@lists.infradead.org; linux-media@vger.kernel.org;
   linux-fbdev;
   Kyungmin Park; myungjoo.ham; YoungJun Cho
   Subject: Re: Introduce a new helper framework for buffer
  
  synchronization
  
   Op 09-05-13 09:33, Inki Dae schreef:
   Hi all,
   
   This post introduces a new helper framework based on dma fence.
   And
  
  the
  
   purpose of this post is to collect other opinions and advices
   before
  
  RFC
  
   posting.
   
   First of all, this helper framework, called fence helper, is in
  
  progress
  
   yet so might not have enough comments in codes and also might need
   to
  
  be
  
   more cleaned up. Moreover, we might be missing some parts of the
   dma
   
   fence.
   
   However, I'd like to say that all things mentioned below has been
  
  tested
  
   with Linux platform and worked well.
   
   
   And tutorial for user process.
   
   just before cpu access
   
   struct dma_buf_fence *df;
   
   df-type = DMA_BUF_ACCESS_READ or
 
 DMA_BUF_ACCESS_WRITE;
 
   ioctl(fd, DMA_BUF_GET_FENCE, df);
   
   after memset or memcpy
   
   ioctl(fd, DMA_BUF_PUT_FENCE, df);
   
   NAK.
   
   Userspace doesn't need to trigger fences. It can do a buffer idle
   wait,
   and postpone submitting new commands until after it's done using
   the
   buffer.
   
   Hi Maarten,
   
   It seems that you say user should wait for a buffer like KDS does:
   KDS
  
  uses
  
   select() to postpone submitting new commands. But I think this way
  
  assumes
  
   that every data flows a DMA device to a CPU. For example, a CPU
   should
  
  keep
  
   polling for the completion of a buffer access by a DMA device. This
  
  means
  
   that the this way isn't considered for data flow to opposite case;
   CPU
  
  to
  
   DMA device.
  
  Not really. You do both things the same way. You first wait for the bo
  to be idle, this could be implemented by adding poll support to the
  dma-buf fd.
  Then you either do your read or write. Since userspace is supposed to
  be the one controlling the bo it should stay idle at that point. If
  you have another thread queueing
  the buffer againbefore your thread is done that's a bug in the
 
 application,
 
  and can be solved with userspace locking primitives. No need for the
  kernel to get involved.
 
 Yes, that is how we have synchronized buffer between CPU and DMA device
 until now without buffer synchronization mechanism. I thought that it's
 best to make user not considering anything: user can access a buffer
 regardless of any DMA device controlling and the buffer synchronization
 is performed in kernel level. Moreover, I think we could optimize
 graphics and multimedia hardware performance because hardware can do
 more works: one thread accesses a shared buffer and the other controls
 DMA device with the shared buffer in parallel.

Could you explain this point? I thought that if there is a shared buffer 
accessible for user and DMA device, only one of them can use it at the 
moment, i.e. the buffer is useless for the reading user (or read DMA) 
until (write) DMA (or writing user) finishes writing for it. Is it 
incorrect? Or this is not the point here?

I'm not an expert here and I'm just trying to understand the idea, so 
correct me if I'm wrong. Thanks in advance.

Best regards,
Tomasz

 Thus, we could avoid
 sequential processing and that is my intention. Aren't you think about
 that we could improve hardware utilization with such way or other? of
 course, there could be better way.
 
   Kernel space doesn't need the root hole you created by giving a
   dereferencing a pointer passed from userspace.
   Your next exercise should be to write a security exploit from the
   api
  
  you
  
   created here. It's the only way to learn how to write safe code.
   Hint:
   df.ctx = mmap(..);
   
   Also I'm not clear to use our way yet and that is why I posted. As
   you
   mentioned, it seems like that using mmap() is more safe. But there
   is
  
  one
  
   issue it makes me confusing. For your hint, df.ctx = mmap(..), the
   issue 
  is
  
   that dmabuf mmap can be used to map a dmabuf with user space. And
   the
  

[PATCH 27/28] ARM: EXYNOS: Remove CONFIG_SOC_EXYNOS4412

2013-06-14 Thread Tomasz Figa
Exynos4212 and Exynos4412 SoCs differ only in number of ARM cores and
there is no need to have separate Kconfig options for them, since they
use the same code.

This patch removes CONFIG_SOC_EXYNOS4412, leaving CONFIG_SOC_EXYNOS4212
as the one supporting both SoCs from this series.

Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/Kconfig  | 11 +--
 arch/arm/plat-samsung/include/plat/cpu.h  |  6 +-
 drivers/cpufreq/Kconfig.arm   |  2 +-
 drivers/media/platform/exynos4-is/Kconfig |  2 +-
 drivers/thermal/exynos_thermal.c  |  2 +-
 drivers/tty/serial/samsung.c  |  3 +--
 6 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 47d8d9e..fe75a65 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -46,7 +46,7 @@ config CPU_EXYNOS4210
  Enable EXYNOS4210 CPU support
 
 config SOC_EXYNOS4212
-   bool SAMSUNG EXYNOS4212
+   bool SAMSUNG EXYNOS4212/4412
default y
depends on ARCH_EXYNOS4
select PINCTRL_EXYNOS
@@ -56,15 +56,6 @@ config SOC_EXYNOS4212
help
  Enable EXYNOS4212 SoC support
 
-config SOC_EXYNOS4412
-   bool SAMSUNG EXYNOS4412
-   default y
-   depends on ARCH_EXYNOS4
-   select PINCTRL_EXYNOS
-   select SAMSUNG_DMADEV
-   help
- Enable EXYNOS4412 SoC support
-
 config SOC_EXYNOS5250
bool SAMSUNG EXYNOS5250
default y
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
b/arch/arm/plat-samsung/include/plat/cpu.h
index 989fefe..87b03bb 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -122,13 +122,9 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, 
EXYNOS5_SOC_MASK)
 
 #if defined(CONFIG_SOC_EXYNOS4212)
 # define soc_is_exynos4212()   is_samsung_exynos4212()
-#else
-# define soc_is_exynos4212()   0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS4412)
 # define soc_is_exynos4412()   is_samsung_exynos4412()
 #else
+# define soc_is_exynos4212()   0
 # define soc_is_exynos4412()   0
 #endif
 
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index a924408..b214ad6 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -32,7 +32,7 @@ config ARM_EXYNOS4210_CPUFREQ
  SoC (S5PV310 or S5PC210).
 
 config ARM_EXYNOS4X12_CPUFREQ
-   def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
+   def_bool SOC_EXYNOS4212
help
  This adds the CPUFreq driver for Samsung EXYNOS4X12
  SoC (EXYNOS4212 or EXYNOS4412).
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 6ff99b5..f483e11 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -32,7 +32,7 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
+if SOC_EXYNOS4212 || SOC_EXYNOS5250
 
 config VIDEO_EXYNOS_FIMC_LITE
tristate EXYNOS FIMC-LITE camera interface driver
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 788b1dd..f88a2ad 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -817,7 +817,7 @@ static struct exynos_tmu_platform_data const 
exynos4210_default_tmu_data = {
 #define EXYNOS4210_TMU_DRV_DATA (NULL)
 #endif
 
-#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
+#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4212)
 static struct exynos_tmu_platform_data const exynos_default_tmu_data = {
.threshold_falling = 10,
.trigger_levels[0] = 85,
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 0c8a9fa..eeb8ecb 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1714,8 +1714,7 @@ static struct s3c24xx_serial_drv_data 
s5pv210_serial_drv_data = {
 #endif
 
 #if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
-   defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250) || \
-   defined(CONFIG_SOC_EXYNOS5440)
+   defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS5440)
 static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
.info = (struct s3c24xx_uart_info) {
.name   = Samsung Exynos4 UART,
-- 
1.8.2.1

--
To unsubscribe from

Re: [PATCH 27/28] ARM: EXYNOS: Remove CONFIG_SOC_EXYNOS4412

2013-06-15 Thread Tomasz Figa
On Saturday 15 of June 2013 10:06:25 Eduardo Valentin wrote:
 Tomasz,
 
 On 14-06-2013 15:33, Tomasz Figa wrote:
  Exynos4212 and Exynos4412 SoCs differ only in number of ARM cores and
  there is no need to have separate Kconfig options for them, since they
  use the same code.
  
  This patch removes CONFIG_SOC_EXYNOS4412, leaving
  CONFIG_SOC_EXYNOS4212
  as the one supporting both SoCs from this series.
  
  Cc: Rafael J. Wysocki r...@sisk.pl
  Cc: Viresh Kumar viresh.ku...@linaro.org
  Cc: Mauro Carvalho Chehab mche...@redhat.com
  Cc: Zhang Rui rui.zh...@intel.com
  Cc: Eduardo Valentin eduardo.valen...@ti.com
  Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
  Cc: cpuf...@vger.kernel.org
  Cc: linux...@vger.kernel.org
  Cc: linux-media@vger.kernel.org
  Cc: linux-ser...@vger.kernel.org
  Signed-off-by: Tomasz Figa t.f...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
  
   arch/arm/mach-exynos/Kconfig  | 11 +--
   arch/arm/plat-samsung/include/plat/cpu.h  |  6 +-
   drivers/cpufreq/Kconfig.arm   |  2 +-
   drivers/media/platform/exynos4-is/Kconfig |  2 +-
   drivers/thermal/exynos_thermal.c  |  2 +-
   drivers/tty/serial/samsung.c  |  3 +--
   6 files changed, 6 insertions(+), 20 deletions(-)
 
 Not for the matter of the change itself, but just for simplicity while
 merging when the change is agreed to be good, it is recommended that you
 split your changes in different smaller patches, specially because you
 are touching several parts of the kernel that belong to different
 trees. If one merges your change the way it is, it is likely to create
 merge conflicts.

Right. Let me split this patch.

Best regards,
Tomasz

  diff --git a/arch/arm/mach-exynos/Kconfig
  b/arch/arm/mach-exynos/Kconfig index 47d8d9e..fe75a65 100644
  --- a/arch/arm/mach-exynos/Kconfig
  +++ b/arch/arm/mach-exynos/Kconfig
  @@ -46,7 +46,7 @@ config CPU_EXYNOS4210
  
Enable EXYNOS4210 CPU support
   
   config SOC_EXYNOS4212
  
  -   bool SAMSUNG EXYNOS4212
  +   bool SAMSUNG EXYNOS4212/4412
  
  default y
  depends on ARCH_EXYNOS4
  select PINCTRL_EXYNOS
  
  @@ -56,15 +56,6 @@ config SOC_EXYNOS4212
  
  help
  
Enable EXYNOS4212 SoC support
  
  -config SOC_EXYNOS4412
  -   bool SAMSUNG EXYNOS4412
  -   default y
  -   depends on ARCH_EXYNOS4
  -   select PINCTRL_EXYNOS
  -   select SAMSUNG_DMADEV
  -   help
  - Enable EXYNOS4412 SoC support
  -
  
   config SOC_EXYNOS5250
   
  bool SAMSUNG EXYNOS5250
  default y
  
  diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
  b/arch/arm/plat-samsung/include/plat/cpu.h index 989fefe..87b03bb
  100644
  --- a/arch/arm/plat-samsung/include/plat/cpu.h
  +++ b/arch/arm/plat-samsung/include/plat/cpu.h
  @@ -122,13 +122,9 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
  EXYNOS5_SOC_MASK) 
   #if defined(CONFIG_SOC_EXYNOS4212)
   # define soc_is_exynos4212()   is_samsung_exynos4212()
  
  -#else
  -# define soc_is_exynos4212()   0
  -#endif
  -
  -#if defined(CONFIG_SOC_EXYNOS4412)
  
   # define soc_is_exynos4412()   is_samsung_exynos4412()
   #else
  
  +# define soc_is_exynos4212()   0
  
   # define soc_is_exynos4412()   0
   #endif
  
  diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
  index a924408..b214ad6 100644
  --- a/drivers/cpufreq/Kconfig.arm
  +++ b/drivers/cpufreq/Kconfig.arm
  @@ -32,7 +32,7 @@ config ARM_EXYNOS4210_CPUFREQ
  
SoC (S5PV310 or S5PC210).
   
   config ARM_EXYNOS4X12_CPUFREQ
  
  -   def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
  +   def_bool SOC_EXYNOS4212
  
  help
  
This adds the CPUFreq driver for Samsung EXYNOS4X12
SoC (EXYNOS4212 or EXYNOS4412).
  
  diff --git a/drivers/media/platform/exynos4-is/Kconfig
  b/drivers/media/platform/exynos4-is/Kconfig index 6ff99b5..f483e11
  100644
  --- a/drivers/media/platform/exynos4-is/Kconfig
  +++ b/drivers/media/platform/exynos4-is/Kconfig
  @@ -32,7 +32,7 @@ config VIDEO_S5P_MIPI_CSIS
  
To compile this driver as a module, choose M here: the
module will be called s5p-csis.
  
  -if SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
  +if SOC_EXYNOS4212 || SOC_EXYNOS5250
  
   config VIDEO_EXYNOS_FIMC_LITE
   
  tristate EXYNOS FIMC-LITE camera interface driver
  
  diff --git a/drivers/thermal/exynos_thermal.c
  b/drivers/thermal/exynos_thermal.c index 788b1dd..f88a2ad 100644
  --- a/drivers/thermal/exynos_thermal.c
  +++ b/drivers/thermal/exynos_thermal.c
  @@ -817,7 +817,7 @@ static struct exynos_tmu_platform_data const
  exynos4210_default_tmu_data = { 
   #define EXYNOS4210_TMU_DRV_DATA (NULL)
   #endif
  
  -#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4412)
  +#if defined(CONFIG_SOC_EXYNOS5250) || defined(CONFIG_SOC_EXYNOS4212)
  
   static struct exynos_tmu_platform_data const exynos_default_tmu_data
   = {  
  .threshold_falling = 10

Re: [RFC PATCH 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs

2013-06-16 Thread Tomasz Figa
Hi Sylwester,

Looks good, but I added some nitpicks inline.

On Friday 14 of June 2013 19:45:47 Sylwester Nawrocki wrote:
 Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
 receiver and MIPI DSI transmitter DPHYs.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  .../bindings/phy/exynos-video-mipi-phy.txt |   16 ++
  drivers/phy/Kconfig|   10 ++
  drivers/phy/Makefile   |3 +-
  drivers/phy/exynos_video_mipi_phy.c|  166
  4 files changed, 194 insertions(+), 1 deletion(-)
  create mode 100644
 Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt create
 mode 100644 drivers/phy/exynos_video_mipi_phy.c
 
 diff --git
 a/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
 b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt new
 file mode 100644
 index 000..32311c89
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/phy/exynos-video-mipi-phy.txt
 @@ -0,0 +1,16 @@
 +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
 +-
 +
 +Required properties:
 +- compatible : samsung,soc_name-video-phy, currently most SoCs can

I don't like this soc_name here. It sounds like any SoC name can be put 
here. IMHO just listing all supported compatible values should be enough.

 claim +  compatibility with the S5PV210 MIPI CSIS/DSIM PHY and thus
 should use +  samsung,s5pv210-video-phy;
 +- reg : offset and length of the MIPI DPHY register set;
 +- #phy-cells : from the generic phy bindings, must be 1;
 +
 +For samsung,s5pv210-video-phy compatible DPHYs the second cell in the
 PHY +specifier identifies the DPHY and its meaning is as follows:
 +  0 - MIPI CSIS 0,
 +  1 - MIPI DSIM 0,
 +  2 - MIPI CSIS 1,
 +  3 - MIPI DSIM 1.
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 0764a54..d234e99 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -11,3 +11,13 @@ menuconfig GENERIC_PHY
 devices present in the kernel. This layer will have the generic
 API by which phy drivers can create PHY using the phy framework 
and
 phy users can obtain reference to the PHY.
 +
 +if GENERIC_PHY
 +
 +config EXYNOS_VIDEO_MIPI_PHY
 + bool S5P/EXYNOS MIPI CSI-2/DSI PHY driver
 + depends on OF

Hmm. Is this driver designed only for OF-enabled boards?

 + help
 +   Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 +   S5P and EXYNOS SoCs.
 +endif
 diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
 index 9e9560f..b16f2c1 100644
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -2,4 +2,5 @@
  # Makefile for the phy drivers.
  #
 
 -obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
 +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
 +obj-$(CONFIG_EXYNOS_VIDEO_MIPI_PHY)  += exynos_video_mipi_phy.o
 diff --git a/drivers/phy/exynos_video_mipi_phy.c
 b/drivers/phy/exynos_video_mipi_phy.c new file mode 100644
 index 000..8d4976f
 --- /dev/null
 +++ b/drivers/phy/exynos_video_mipi_phy.c
 @@ -0,0 +1,166 @@
 +/*
 + * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
 + *
 + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
 + * Author: Sylwester Nawrocki s.nawro...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as +
 * published by the Free Software Foundation.
 + */
 +
 +#include linux/delay.h
 +#include linux/io.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/of_address.h
 +#include linux/phy/phy.h
 +#include linux/platform_device.h
 +#include linux/spinlock.h
 +
 +/* MIPI_PHYn_CONTROL register bit definitions */
 +#define EXYNOS_MIPI_PHY_ENABLE   (1  0)
 +#define EXYNOS_MIPI_PHY_SRESETN  (1  1)
 +#define EXYNOS_MIPI_PHY_MRESETN  (1  2)
 +#define EXYNOS_MIPI_PHY_RESET_MASK   (3  1)
 +
 +#define EXYNOS_MAX_VIDEO_PHYS4
 +
 +struct exynos_video_phy {
 + spinlock_t slock;
 + struct phy *phys[EXYNOS_MAX_VIDEO_PHYS];
 + void __iomem *regs;
 +};
 +
 +/*
 + * The @id argument specifies MIPI CSIS or DSIM PHY as follows:
 + *  0 - MIPI CSIS 0
 + *  1 - MIPI DSIM 0
 + *  2 - MIPI CSIS 1
 + *  3 - MIPI DSIM 1
 + */
 +static int set_phy_state(struct exynos_video_phy *state,
 + unsigned int id, int on)
 +{
 + void __iomem *addr = id  2 ? state-regs : state-regs + 4;

I don't find this statement too readable. What about:

void __iomem *addr = state-regs;

and below:

/* CSIS 1 and DSIM 1 PHYs have separate register */
if (id = 2)
addr += 4;

 + unsigned long flags;
 + u32 reg, reset;
 +
 + pr_debug(%s(): id: %d, on: %d, addr: %#x, base: %#x\n,
 +  __func__, id, on, 

Re: [RFC PATCH 2/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi

2013-06-16 Thread Tomasz Figa
On Friday 14 of June 2013 19:45:48 Sylwester Nawrocki wrote:
 Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/boot/dts/exynos4.dtsi |   12 
  1 file changed, 12 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos4.dtsi
 b/arch/arm/boot/dts/exynos4.dtsi index d505ece..4b7ce52 100644
 --- a/arch/arm/boot/dts/exynos4.dtsi
 +++ b/arch/arm/boot/dts/exynos4.dtsi
 @@ -120,12 +120,20 @@
   reg = 0x1001 0x400;
   };
 
 + mipi_phy: video-phy {

nit: video-phy@10020710

Best regards,
Tomasz

 + compatible = samsung,s5pv210-video-phy;
 + reg = 0x10020710 8;
 + #phy-cells = 1;
 + };
 +
   dsi_0: dsi@11C8 {
   compatible = samsung,exynos4210-mipi-dsi;
   reg = 0x11C8 0x1;
   interrupts = 0 79 0;
   samsung,phy-type = 0;
   samsung,power-domain = pd_lcd0;
 + phys = mipi_phy 1;
 + phy-names = dsim;
   clocks = clock 286, clock 143;
   clock-names = bus_clk, pll_clk;
   status = disabled;
 @@ -181,6 +189,8 @@
   interrupts = 0 78 0;
   bus-width = 4;
   samsung,power-domain = pd_cam;
 + phys = mipi_phy 0;
 + phy-names = csis;
   status = disabled;
   };
 
 @@ -190,6 +200,8 @@
   interrupts = 0 80 0;
   bus-width = 2;
   samsung,power-domain = pd_cam;
 + phys = mipi_phy 2;
 + phy-names = csis;
   status = disabled;
   };
   };
--
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: [RFC PATCH 3/5] video: exynos_dsi: Use generic PHY driver

2013-06-16 Thread Tomasz Figa
On Friday 14 of June 2013 19:45:49 Sylwester Nawrocki wrote:
 Use the generic PHY API instead of the platform callback to control
 the MIPI DSIM DPHY.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/video/display/source-exynos_dsi.c |   36
 + include/video/exynos_dsi.h   
 |5 
  2 files changed, 11 insertions(+), 30 deletions(-)

Yes, this is what I was really missing a lot while developing this driver.

Definitely looks good! It's a shame we don't have this driver in mainline 
yet ;) ,

Best regards,
Tomasz

 diff --git a/drivers/video/display/source-exynos_dsi.c
 b/drivers/video/display/source-exynos_dsi.c index 145d57b..dfab790
 100644
 --- a/drivers/video/display/source-exynos_dsi.c
 +++ b/drivers/video/display/source-exynos_dsi.c
 @@ -24,6 +24,7 @@
  #include linux/mm.h
  #include linux/module.h
  #include linux/of.h
 +#include linux/phy/phy.h
  #include linux/platform_device.h
  #include linux/pm_runtime.h
  #include linux/regulator/consumer.h
 @@ -219,6 +220,7 @@ struct exynos_dsi {
   bool enabled;
 
   struct platform_device *pdev;
 + struct phy *phy;
   struct device *dev;
   struct resource *res;
   struct clk *pll_clk;
 @@ -816,6 +818,7 @@ again:
 
  static bool exynos_dsi_transfer_finish(struct exynos_dsi *dsi)
  {
 + static unsigned long j;
   struct exynos_dsi_transfer *xfer;
   unsigned long flags;
   bool start = true;
 @@ -824,7 +827,8 @@ static bool exynos_dsi_transfer_finish(struct
 exynos_dsi *dsi)
 
   if (list_empty(dsi-transfer_list)) {
   spin_unlock_irqrestore(dsi-transfer_lock, flags);
 - dev_warn(dsi-dev, unexpected TX/RX interrupt\n);
 + if (printk_timed_ratelimit(j, 500))
 + dev_warn(dsi-dev, unexpected TX/RX 
interrupt\n);
   return false;
   }
 
 @@ -994,8 +998,7 @@ static int exynos_dsi_enable(struct video_source
 *src) clk_prepare_enable(dsi-bus_clk);
   clk_prepare_enable(dsi-pll_clk);
 
 - if (dsi-pd-phy_enable)
 - dsi-pd-phy_enable(dsi-pdev, true);
 + phy_power_on(dsi-phy);
 
   exynos_dsi_reset(dsi);
   exynos_dsi_init_link(dsi);
 @@ -1019,8 +1022,7 @@ static int exynos_dsi_disable(struct video_source
 *src)
 
   exynos_dsi_disable_clock(dsi);
 
 - if (dsi-pd-phy_enable)
 - dsi-pd-phy_enable(dsi-pdev, false);
 + phy_power_off(dsi-phy);
 
   clk_disable_unprepare(dsi-pll_clk);
   clk_disable_unprepare(dsi-bus_clk);
 @@ -1099,12 +1101,6 @@ static const struct dsi_video_source_ops
 exynos_dsi_ops = { * Device Tree
   */
 
 -static int (* const of_phy_enables[])(struct platform_device *, bool) =
 { -#ifdef CONFIG_S5P_SETUP_MIPIPHY
 - [0] = s5p_dsim_phy_enable,
 -#endif
 -};
 -
  static struct exynos_dsi_platform_data *exynos_dsi_parse_dt(
   struct platform_device 
*pdev)
  {
 @@ -1112,7 +1108,6 @@ static struct exynos_dsi_platform_data
 *exynos_dsi_parse_dt( struct exynos_dsi_platform_data *dsi_pd;
   struct device *dev = pdev-dev;
   const __be32 *prop_data;
 - u32 val;
 
   dsi_pd = kzalloc(sizeof(*dsi_pd), GFP_KERNEL);
   if (!dsi_pd) {
 @@ -1120,19 +1115,6 @@ static struct exynos_dsi_platform_data
 *exynos_dsi_parse_dt( return NULL;
   }
 
 - prop_data = of_get_property(node, samsung,phy-type, NULL);
 - if (!prop_data) {
 - dev_err(dev, failed to get phy-type property\n);
 - goto err_free_pd;
 - }
 -
 - val = be32_to_cpu(*prop_data);
 - if (val = ARRAY_SIZE(of_phy_enables) || !of_phy_enables[val]) {
 - dev_err(dev, Invalid phy-type %u\n, val);
 - goto err_free_pd;
 - }
 - dsi_pd-phy_enable = of_phy_enables[val];
 -
   prop_data = of_get_property(node, samsung,pll-stable-time, 
NULL);
   if (!prop_data) {
   dev_err(dev, failed to get pll-stable-time property\n);
 @@ -1254,6 +1236,10 @@ static int exynos_dsi_probe(struct
 platform_device *pdev) return -ENOMEM;
   }
 
 + dsi-phy = devm_phy_get(pdev-dev, dsim);
 + if (IS_ERR(dsi-phy))
 + return PTR_ERR(dsi-phy);
 +
   platform_set_drvdata(pdev, dsi);
 
   dsi-irq = platform_get_irq(pdev, 0);
 diff --git a/include/video/exynos_dsi.h b/include/video/exynos_dsi.h
 index 95e1568..5c062c7 100644
 --- a/include/video/exynos_dsi.h
 +++ b/include/video/exynos_dsi.h
 @@ -25,9 +25,6 @@
   */
  struct exynos_dsi_platform_data {
   unsigned int enabled;
 -
 - int (*phy_enable)(struct platform_device *pdev, bool on);
 -
   unsigned int pll_stable_time;
   unsigned long pll_clk_rate;
   unsigned long esc_clk_rate;
 @@ -36,6 +33,4 @@ struct exynos_dsi_platform_data {
   unsigned short rx_timeout;
  };
 
 -int s5p_dsim_phy_enable(struct platform_device *pdev, bool on);
 -
  #endif /* _EXYNOS_MIPI_DSIM_H */
--

[PATCH v2 17/38] [media] platform: Check for ARCH_EXYNOS separately

2013-06-17 Thread Tomasz Figa
ARCH_EXYNOS is going to be excluded from PLAT_S5P, so it must be checked
separately in Exynos-related Kconfig entries.

Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Tomasz Stanislawski t.stanisl...@samsung.com
Cc: Jeongtae Park jtp.p...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/Kconfig| 6 +++---
 drivers/media/platform/exynos4-is/Kconfig | 3 ++-
 drivers/media/platform/s5p-tv/Kconfig | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0494d27..bce695d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -159,7 +159,7 @@ config VIDEO_MEM2MEM_DEINTERLACE
 
 config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
-   depends on VIDEO_DEV  VIDEO_V4L2  PLAT_S5P
+   depends on VIDEO_DEV  VIDEO_V4L2  (PLAT_S5P || ARCH_EXYNOS)
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
default n
@@ -169,7 +169,7 @@ config VIDEO_SAMSUNG_S5P_G2D
 
 config VIDEO_SAMSUNG_S5P_JPEG
tristate Samsung S5P/Exynos4 JPEG codec driver
-   depends on VIDEO_DEV  VIDEO_V4L2  PLAT_S5P
+   depends on VIDEO_DEV  VIDEO_V4L2  (PLAT_S5P || ARCH_EXYNOS)
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
@@ -177,7 +177,7 @@ config VIDEO_SAMSUNG_S5P_JPEG
 
 config VIDEO_SAMSUNG_S5P_MFC
tristate Samsung S5P MFC Video Codec
-   depends on VIDEO_DEV  VIDEO_V4L2  PLAT_S5P
+   depends on VIDEO_DEV  VIDEO_V4L2  (PLAT_S5P || ARCH_EXYNOS)
select VIDEOBUF2_DMA_CONTIG
default n
help
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 6ff99b5..004fd0b 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -1,7 +1,8 @@
 
 config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
-   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API  PLAT_S5P  PM_RUNTIME
+   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API  PM_RUNTIME
+   depends on (PLAT_S5P || ARCH_EXYNOS)
help
  Say Y here to enable camera host interface devices for
  Samsung S5P and EXYNOS SoC series.
diff --git a/drivers/media/platform/s5p-tv/Kconfig 
b/drivers/media/platform/s5p-tv/Kconfig
index 7b659bd..369a4c1 100644
--- a/drivers/media/platform/s5p-tv/Kconfig
+++ b/drivers/media/platform/s5p-tv/Kconfig
@@ -8,7 +8,7 @@
 
 config VIDEO_SAMSUNG_S5P_TV
bool Samsung TV driver for S5P platform
-   depends on PLAT_S5P  PM_RUNTIME
+   depends on (PLAT_S5P || ARCH_EXYNOS)  PM_RUNTIME
default n
---help---
  Say Y here to enable selecting the TV output devices for
-- 
1.8.2.1

--
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 v2 32/38] [media] exynos4-is: Remove check for SOC_EXYNOS4412

2013-06-17 Thread Tomasz Figa
Since SOC_EXYNOS4412 Kconfig symbol has been removed, it is enough to
check for SOC_EXYNOS4212 for both SoCs from Exynos4x12 series.

Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 004fd0b..0d4fd5c 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -33,7 +33,7 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
+if SOC_EXYNOS4212 || SOC_EXYNOS5250
 
 config VIDEO_EXYNOS_FIMC_LITE
tristate EXYNOS FIMC-LITE camera interface driver
-- 
1.8.2.1

--
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: [RFC PATCH 3/5] video: exynos_dsi: Use generic PHY driver

2013-06-19 Thread Tomasz Figa
On Wednesday 19 of June 2013 19:10:52 Sylwester Nawrocki wrote:
 On 06/16/2013 11:15 PM, Tomasz Figa wrote:
  On Friday 14 of June 2013 19:45:49 Sylwester Nawrocki wrote:
   Use the generic PHY API instead of the platform callback to control
   the MIPI DSIM DPHY.
   
   Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
   Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
   ---
   
drivers/video/display/source-exynos_dsi.c |   36
   
   + include/video/exynos_dsi.h
   
   |5 

2 files changed, 11 insertions(+), 30 deletions(-)
  
  Yes, this is what I was really missing a lot while developing this
  driver.
  
  Definitely looks good! It's a shame we don't have this driver in
  mainline yet ;)
 
 Yes, I should have mentioned in the cover letter this patch depends
 on modified version of this [1] patch set of yours. I'll drop this
 patch and will update the driver staying in mainline now, but I won't
 be able to test it, on a non-dt platform.
 
 I guess even some pre-eliminary display (panel) API would be helpful.
 The CDF development seems to have been stalled for some time. I wonder
 if we could first have something that works for limited set of devices
 and be extending it gradually, rather than living with zero support
 for displays on DT based ARM platforms.

Well, the problem is that once we define a binding for displays, we will 
have to keep support for this binding even if we decide to change 
something.

But as I discussed with Laurent and Alexandre at LinuxCon Japan, we should 
be able to reuse V4L2 bindings for our purposes, so someone just needs to 
code a proof of concept implementation that doesn't necessarily provide 
full functionality yet, but allows to make something work. Probably based 
on already posted RFC versions of CDF.

CCed Laurent and Alexandre, as they might be able to shed even more light 
on this.

Best regards,
Tomasz

 
 [1] http://www.spinics.net/lists/linux-fbdev/msg09689.html
 
 Regards,
 Sylwester
--
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 0/1] S3C244X/S3C64XX SoC camera host interface driver

2012-08-11 Thread Tomasz Figa
Hi,

On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote:
 Hi all,
 
 This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera
 host interface. My intention was to create a V4L2 driver that would work
 with standard applications like Gstreamer or mplayer, and yet exposing
 possibly all features available in the hardware.
 
 It took me several weeks to do this work in my (limited) spare time.
 Finally I've got something that is functional and I think might be useful
 for others, so I'm publishing this initial version. It hopefully doesn't
 need much tweaking or corrections, at least as far as S3C244X is
 concerned. It has not been tested on S3C64XX SoCs, as I don't have the
 hardware. However, the driver has been designed with covering S3C64XX as
 well in mind, and I've already taken care of some differences between
 S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but
 these are quite separate issue and could be easily added as a next step.

I will try to test it on S3C6410 in some reasonably near future and report 
any needed corrections.

Currently I am using a modified s5p-fimc driver in my project, but it 
supports only the codec path of S3C64xx and any needed stream duplication 
and rescaling is done in later processing, so it might be wise to migrate 
to yours.

Best regards,
Tomasz Figa
 
 The patch to follow only adds the CAMIF driver, the other two required
 for the camera on Mini2440 board to work (OV9650 sensor driver and the
 board file patch) can be found in branch s3c-camif-v3.5 in git
 repository:
 
 git://github.com/snawrocki/linux.git
 
 Gitweb: https://github.com/snawrocki/linux/commits/s3c-camif-v3.5
 
 These patches are based off of stable v3.5 kernel.
 
 The S3C-CAMIF driver exposes one v4l2 subdev and two capture video nodes
 - for the codec and preview data paths. For minimum functionality
 there is no need to touch the subdev device node in user space. However
 it is recommended for best results.
 
 For my tests I used nice Mini2440 BSP from Pengutronix, which already
 contains various applications, like Gstreamer, v4l2-ctl or even
 media-ctl. It's available at
 http://www.pengutronix.de/oselas/bsp/pengutronix/index_en.html.
 
 I've tested the driver with mplayer and Gstreamer, also simultaneous
 capture from the preview and codec video nodes. The codec path
 camera preview at framebuffer can be started, for example, with
 following command:
 
 # gst-launch v4l2src device=/dev/video0 !
 video/x-raw-yuv,width=320,height= 240 ! ffmpegcolorspace ! fbdevsink
 
 In order to select the preview video node (which supports only RGB pixel
 formats) /dev/video0 need to be replaced with /dev/video1, e.g.
 
 # gst-launch v4l2src device=/dev/video1 !
 video/x-raw-rgb,bpp=32,endianness= 4321,depth=32,width=320,height=240 !
 ffmpegcolorspace ! fbdevsink
 
 In this case I'm getting slightly incorrect color representation, still
 need to figure out why this happens.
 
 The supported pixel formats are listed in the attached
 supported_pixel_formats.txt file.
 
 The camera test pattern is exposed through a private control at the
 subdev node, all supported controls are listed in attached
 supported_controls.txt file. The test pattern can be enabled e.g. with
 command:
 
 # v4l2-ctl -d /dev/v4l-subdev1 --set-ctrl=test_pattern=1
 
 
 A note about the driver's internals
 
 The S3C-CAMIF driver sets at the camera input (catchcam) (default)
 pixel format as retrieved from the sensor subdev. This happens during
 driver's initialization, so there is no need to touch the subdev in user
  space to capture video from the camera. If pixel resolution selected at
 /dev/video? differs from the one set at camera input (S3C-CAMIF subdev
 pad 0), the image frames will be resized accordingly, taking into
 account the resizer's capabilities.
 
 To change pixel format at the sensor subdev and the camif input, so those
 better match our target capture resolution, following commands can be
 used:
 
 media-ctl --set-v4l2 'OV9650:0 [fmt: YUYV2X8/640x640]'
 media-ctl --set-v4l2 'S3C-CAMIF:0 [fmt: YUYV2X8/640x640]'
 
 The only requirement is that these formats are same, otherwise it won't
 be possible to start streaming and VIDIOC_STREAMON will fail wit -EPIPE
 errno.
 
 The video node numbering might be different, if there are other V4L2
 drivers in the system. It can be easily checked with media-ctl utility
 (media-ctl -p), my configuration was as in attached camif_media_info.txt
 log.
 
 I've run v4l2-compliance on both video nodes, the results can be found in
 file v4l2_compliance_log.txt.
 
 A graph depicting device topology can be generated from attached
 camif_graph.dot file (which was created with 'media-ctl --print-dot'),
 with following command:
 
 # cat camif_graph.dot | dot -Tpdf  camif_graph.pdf
 # evince camif_graph.pdf
 
 There is still some more work needed to make the OV9650 sensor driver
 ready for the mainline, I'm planning to take care of it in near future

Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver

2012-08-11 Thread Tomasz Figa
On Saturday 11 of August 2012 21:32:15 Sylwester Nawrocki wrote:
 On 08/11/2012 08:39 PM, Tomasz Figa wrote:
  Hi,
  
  On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote:
  Hi all,
  
  This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera
  host interface. My intention was to create a V4L2 driver that would
  work
  with standard applications like Gstreamer or mplayer, and yet exposing
  possibly all features available in the hardware.
  
  It took me several weeks to do this work in my (limited) spare time.
  Finally I've got something that is functional and I think might be
  useful for others, so I'm publishing this initial version. It
  hopefully doesn't need much tweaking or corrections, at least as far
  as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I
  don't have the hardware. However, the driver has been designed with
  covering S3C64XX as well in mind, and I've already taken care of some
  differences between S3C2444X and S3C64XX. Mem-to-mem features are not
  yet supported, but these are quite separate issue and could be easily
  added as a next step. 
  I will try to test it on S3C6410 in some reasonably near future and
  report any needed corrections.
 
 Sounds great, thanks.

I have not tested the driver yet, but I am looking through the code and it 
seems like S3C6410 (at least according to the documentation) supports far 
more pixel formats than defined in the driver.

Both preview and scaler paths are supposed to support 420/422 planar, 422 
interleaved and 565/666/888 formats.

Also two distinct planar 420 formats exist that simply differ by plane 
order YUV420 (currently supported in your driver) and YVU420 (with Cb and 
Cr planes swapped). It should be pretty straightforward to add support for 
the latter.

Best regards,
Tomasz Figa

 
  Currently I am using a modified s5p-fimc driver in my project, but it
  supports only the codec path of S3C64xx and any needed stream
  duplication and rescaling is done in later processing, so it might be
  wise to migrate to yours.
 
 Yeah, the s3c camif is quite different from the s5p one. Thus the
 s3c-camif driver might be a much better starting point for S3C6410. I
 could test any changes for s3c6410 back on s3c2440 and incorporate the
 verified ones into some common stable git branch.
 
 --
 
 Regards,
 Sylwester
--
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: s5p-fimc VIDIOC_STREAMOFF bug

2012-04-21 Thread Tomasz Figa
Hi Sylwester,

Thanks for your response.

On Friday 20 of April 2012 20:24:38 Sylwester Nawrocki wrote:
 Hi Tomasz,
 
 On 04/19/2012 11:45 PM, Tomasz Figa wrote:
  Hi,
  
  I have been working on adapting s5p-fimc driver for s3c6410 and
  everything seems to be working just fine after some minor changes
  (except minor loss of functionality - only codec path is supported,
  but for most use cases it does not matter).
  
  However I think that I have spotted a bug in capture stop / capture
  suspend handling. In fimc_capture_state_cleanup() the
  ST_CAPT_SUSPENDED status bit of fimc-state field is being set
  regardless of suspend parameter, which confuses the driver that FIMC
  is suspended and might not accept buffers into active queue and so
  the driver will never start the capture process unless the device
  gets closed and reopened (because of the condition checking the
  count of active buffers).
  
  In my fork for s3c6410 I have moved the set_bit call into
  fimc_capture_suspend(), so the bit gets set only when the device gets
  suspended. This seems to solve the problem and I do not see any
  issues that this could introduce, so it might be a good solution.
  
  Let me know if I am wrong in anything I have written.
 
 Your conclusions are correct, there was indeed a bug like that.
 There is already a patch fixing this [1], but it is going to be available
 just from v3.4. I'm considering sending it to Greg for inclusion in the
 stable releases, after it gets upstream.

OK, I must have missed the patch. Good that it has been already noticed and 
fixed.

 Once I did some preliminary work for the s3c-fimc driver, but dropped
 this due to lack of time. If you ever decide you want to mainline your
 work, just send the patches to linux-media@vger.kernel.org (and perhaps
 also to samsung-soc and ARM Linux) for review.

I am not sure sure if there is any interest for more advanced support of 
S3C6410 going into mainline, but if such shows up I am ready to cooperate.

 
  Best regards,
  Tomasz Figa
 
 [1] http://patchwork.linuxtv.org/patch/10417
 
 
 Thanks,
--
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 0/4] media: s5p-tv: clean-up and fixes

2013-09-23 Thread Tomasz Figa
Hi Mateusz,

On Saturday 21 of September 2013 17:00:45 Mateusz Krawczuk wrote:
 This patch series add restoring previous vpll rate after driver offs
 stream or recives error.
 It also replace mxr_info, mxr_dbg, mxr_warn and mxr_err macro
 by generic solution.
 
 Mateusz Krawczuk (4):
   media: s5p-tv: Replace mxr_ macro by default dev_
   media: s5p-tv: Restore vpll clock rate
   media: s5p-tv: Fix sdo driver to work with CCF
   media: s5p-tv: Fix mixer driver to work with CCF
 
  drivers/media/platform/s5p-tv/mixer.h   |  12 ---
  drivers/media/platform/s5p-tv/mixer_drv.c   |  81
 --- 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 +-
  drivers/media/platform/s5p-tv/sdo_drv.c |  39 +++--
  7 files changed, 137 insertions(+), 105 deletions(-)

For the whole series:

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 4/5] ASoC: samsung: Use CONFIG_ARCH_S3C64XX to check for S3C64xx support

2013-09-28 Thread Tomasz Figa
Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies
the s3c-i2s-v2 driver to use the proper way of checking for S3C64xx
support - CONFIG_ARCH_S3C64XX.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 sound/soc/samsung/s3c-i2s-v2.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index e5e81b1..fefc561 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -31,11 +31,7 @@
 #undef S3C_IIS_V2_SUPPORTED
 
 #if defined(CONFIG_CPU_S3C2412) || defined(CONFIG_CPU_S3C2413) \
-   || defined(CONFIG_CPU_S5PV210)
-#define S3C_IIS_V2_SUPPORTED
-#endif
-
-#ifdef CONFIG_PLAT_S3C64XX
+   || defined(CONFIG_ARCH_S3C64XX) || defined(CONFIG_CPU_S5PV210)
 #define S3C_IIS_V2_SUPPORTED
 #endif
 
-- 
1.8.3.2

--
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 3/5] [media] s3c-camif: Use CONFIG_ARCH_S3C64XX to check for S3C64xx support

2013-09-28 Thread Tomasz Figa
Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies
the Kconfig entry of s3c-camif driver to use the proper way of checking
for S3C64xx support - CONFIG_ARCH_S3C64XX.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7caf94..eb70dda 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -112,7 +112,7 @@ config VIDEO_OMAP3_DEBUG
 config VIDEO_S3C_CAMIF
tristate Samsung S3C24XX/S3C64XX SoC Camera Interface driver
depends on VIDEO_V4L2  I2C  VIDEO_V4L2_SUBDEV_API
-   depends on (PLAT_S3C64XX || PLAT_S3C24XX)  PM_RUNTIME
+   depends on (ARCH_S3C64XX || PLAT_S3C24XX)  PM_RUNTIME
select VIDEOBUF2_DMA_CONTIG
---help---
  This is a v4l2 driver for s3c24xx and s3c64xx SoC series camera
-- 
1.8.3.2

--
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 5/5] ARM: s3c64xx: Kill CONFIG_PLAT_S3C64XX

2013-09-28 Thread Tomasz Figa
CONFIG_PLAT_S3C64XX has been kept in place way too long since it was
marked as temporary in commit

110d85a ARM: S3C64XX: Eliminate plat-s3c64xx

After fixing all users of it in previous patches, this patch finally
kills this temporary Kconfig entry.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 arch/arm/Kconfig  |  2 ++
 arch/arm/mach-s3c64xx/Kconfig | 11 ---
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dc51f8a..40d5178 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -738,10 +738,12 @@ config ARCH_S3C64XX
select NEED_MACH_GPIO_H
select NO_IOPORT
select PLAT_SAMSUNG
+   select PM_GENERIC_DOMAINS
select S3C_DEV_NAND
select S3C_GPIO_TRACK
select SAMSUNG_ATAGS
select SAMSUNG_GPIOLIB_4BIT
+   select SAMSUNG_WAKEMASK
select SAMSUNG_WDT_RESET
select USB_ARCH_HAS_OHCI
help
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 0e23910..2cb8dc5 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -5,17 +5,6 @@
 
 if ARCH_S3C64XX
 
-# temporary until we can eliminate all drivers using it.
-config PLAT_S3C64XX
-   bool
-   depends on ARCH_S3C64XX
-   default y
-   select PM_GENERIC_DOMAINS
-   select SAMSUNG_WAKEMASK
-   help
- Base platform code for any Samsung S3C64XX device
-
-
 # Configuration options for the S3C6410 CPU
 
 config CPU_S3C6400
-- 
1.8.3.2

--
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 1/5] ARM: Kconfig: Move if ARCH_S3C64XX statement to mach-s3c64xx/Kconfig

2013-09-28 Thread Tomasz Figa
All other platforms have this condition checked inside their own Kconfig
files, so for consistency this patch makes it this way for mach-s3c64xx
as well.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 arch/arm/Kconfig  | 2 --
 arch/arm/mach-s3c64xx/Kconfig | 4 
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b766dad..dc51f8a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -995,9 +995,7 @@ source arch/arm/mach-sti/Kconfig
 
 source arch/arm/mach-s3c24xx/Kconfig
 
-if ARCH_S3C64XX
 source arch/arm/mach-s3c64xx/Kconfig
-endif
 
 source arch/arm/mach-s5p64x0/Kconfig
 
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index bd14e3a..0e23910 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -3,6 +3,8 @@
 #
 # Licensed under GPLv2
 
+if ARCH_S3C64XX
+
 # temporary until we can eliminate all drivers using it.
 config PLAT_S3C64XX
bool
@@ -322,3 +324,5 @@ config MACH_S3C64XX_DT
  board.
  Note: This is under development and not all peripherals can be
  supported with this machine file.
+
+endif
-- 
1.8.3.2

--
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 2/5] gpio: samsung: Use CONFIG_ARCH_S3C64XX to check for S3C64xx support

2013-09-28 Thread Tomasz Figa
Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies
the gpio-samsung driver to use the proper way of checking for S3C64xx
support - CONFIG_ARCH_S3C64XX.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/gpio/gpio-samsung.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 29b5d67..76e02b9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -1033,7 +1033,7 @@ static int s3c24xx_gpiolib_fbank_to_irq(struct gpio_chip 
*chip, unsigned offset)
 }
 #endif
 
-#ifdef CONFIG_PLAT_S3C64XX
+#ifdef CONFIG_ARCH_S3C64XX
 static int s3c64xx_gpiolib_mbank_to_irq(struct gpio_chip *chip, unsigned pin)
 {
return pin  5 ? IRQ_EINT(23) + pin : -ENXIO;
@@ -1174,7 +1174,7 @@ struct samsung_gpio_chip s3c24xx_gpios[] = {
  */
 
 static struct samsung_gpio_chip s3c64xx_gpios_4bit[] = {
-#ifdef CONFIG_PLAT_S3C64XX
+#ifdef CONFIG_ARCH_S3C64XX
{
.chip   = {
.base   = S3C64XX_GPA(0),
@@ -1227,7 +1227,7 @@ static struct samsung_gpio_chip s3c64xx_gpios_4bit[] = {
 };
 
 static struct samsung_gpio_chip s3c64xx_gpios_4bit2[] = {
-#ifdef CONFIG_PLAT_S3C64XX
+#ifdef CONFIG_ARCH_S3C64XX
{
.base   = S3C64XX_GPH_BASE + 0x4,
.chip   = {
@@ -1257,7 +1257,7 @@ static struct samsung_gpio_chip s3c64xx_gpios_4bit2[] = {
 };
 
 static struct samsung_gpio_chip s3c64xx_gpios_2bit[] = {
-#ifdef CONFIG_PLAT_S3C64XX
+#ifdef CONFIG_ARCH_S3C64XX
{
.base   = S3C64XX_GPF_BASE,
.config = samsung_gpio_cfgs[6],
-- 
1.8.3.2

--
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 2/5] gpio: samsung: Use CONFIG_ARCH_S3C64XX to check for S3C64xx support

2013-10-02 Thread Tomasz Figa
Hi Linus,

On Wednesday 02 of October 2013 12:46:51 Linus Walleij wrote:
 On Sat, Sep 28, 2013 at 8:21 PM, Tomasz Figa tomasz.f...@gmail.com 
wrote:
  Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies
  the gpio-samsung driver to use the proper way of checking for S3C64xx
  support - CONFIG_ARCH_S3C64XX.
  
  Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 
 Acked-by: Linus Walleij linus.wall...@linaro.org

Thanks.

 I assume that this will go through ARM SoC?

I think so.

Best regards,
Tomasz

--
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: S3C244X/S3C64XX SoC camera host interface driver questions

2012-11-04 Thread Tomasz Figa
Hi Andrey,

On Sunday 04 of November 2012 23:14:47 Sylwester Nawrocki wrote:
  Are you using this version of patches:
  http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-cam
  if ? 
  I'm using patches from
  https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 wich was in
  your mail to samsung maillist.
 
 I suggest you to update to the s3c-camif branch as above, it includes
 some bug fixes. Sorry, I don't have exact patch for your issue handy
 right now.

Yes, you should definitely try the branch pointed by Sylwester, because the 
one you originally tested does not contain my fixes for S3C6410.

Best regards,
Tomasz Figa

--
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: [RFC v2 0/5] Common Display Framework

2012-12-21 Thread Tomasz Figa
Hi Vikas,

On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
  Hi Laurent,
 
 Thanks for the reply.
 
 On 17 December 2012 20:55, Laurent Pinchart 
 
 laurent.pinch...@ideasonboard.com wrote:
  Hi Vikas,
  
  Sorry for the late reply. I now have more time to work on CDF, so
  delays should be much shorter.
  
  On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
   Hi Laurent,
   
   I was thinking of porting CDF to samsung EXYNOS 5250 platform, what
   I
  
  found
  
   is that, the exynos display controller is MIPI DSI based controller.
   
   But if I look at CDF patches, it has only support for MIPI DBI based
  
  Display
  
   controller.
   
   So my question is, do we have any generic framework for MIPI DSI
   based
   display controller? basically I wanted to know, how to go about
   porting
  
  CDF
  
   for such kind of display controller.
  
  MIPI DSI support is not available yet. The only reason for that is
  that I don't have any MIPI DSI hardware to write and test the code
  with :-)
  
  The common display framework should definitely support MIPI DSI. I
  think the
  existing MIPI DBI code could be used as a base, so the implementation
  shouldn't be too high.
  
  Yeah, i was also thinking in similar lines, below is my though for
  MIPI
 
 DSI support in CDF.
 
 o   MIPI DSI support as part of CDF framework will expose
 
 §  mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
 file )
 
 §  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
 platform specific init driver call )
 
 ·bus ops will be
 
 o   read data
 
 o   write data
 
 o   write command
 
 §  MIPI DSI will be registered as bus_register()
 
 When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
 initialize the MIPI DSI HW IP.
 
  This probe will also parse the DT file for MIPI DSI based panel, add
 the panel device (device_add() ) to kernel and register the display
 entity with its control and  video ops with CDF.
 
 I can give this a try.

I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 
LCD driver to use the v2 RFC of Common Display Framework. I have most of 
the work done, I have just to solve several remaining problems.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform

--
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: [RFC v2 0/5] Common Display Framework

2012-12-27 Thread Tomasz Figa
Hi Laurent,

On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
 Hi Tomasz,
 
 On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
  On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
   On 17 December 2012 20:55, Laurent Pinchart wrote:
Hi Vikas,

Sorry for the late reply. I now have more time to work on CDF, so
delays should be much shorter.

On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
 Hi Laurent,
 
 I was thinking of porting CDF to samsung EXYNOS 5250 platform,
 what
 I found is that, the exynos display controller is MIPI DSI based
 controller.
 
 But if I look at CDF patches, it has only support for MIPI DBI
 based
 Display controller.
 
 So my question is, do we have any generic framework for MIPI DSI
 based display controller? basically I wanted to know, how to go
 about
 porting CDF for such kind of display controller.

MIPI DSI support is not available yet. The only reason for that is
that I don't have any MIPI DSI hardware to write and test the code
with :-)

The common display framework should definitely support MIPI DSI. I
think the existing MIPI DBI code could be used as a base, so the
implementation shouldn't be too high.

Yeah, i was also thinking in similar lines, below is my though for
MIPI DSI support in CDF.
   
   o   MIPI DSI support as part of CDF framework will expose
   §  mipi_dsi_register_device(mpi_device) (will be called
   mach-xxx-dt.c
   file )
   §  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
   from
   platform specific init driver call )
   ·bus ops will be
   o   read data
   o   write data
   o   write command
   §  MIPI DSI will be registered as bus_register()
   
   When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI)
   will
   initialize the MIPI DSI HW IP.
   
   This probe will also parse the DT file for MIPI DSI based panel, add
   the panel device (device_add() ) to kernel and register the display
   entity with its control and  video ops with CDF.
   
   I can give this a try.
  
  I am currently in progress of reworking Exynos MIPI DSIM code and
  s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I
  have most of the work done, I have just to solve several remaining
  problems.
 Do you already have code that you can publish ? I'm particularly
 interested (and I think Tomi Valkeinen would be as well) in looking at
 the DSI operations you expose to DSI sinks (panels, transceivers, ...).

Well, I'm afraid this might be little below your expectations, but here's 
an initial RFC of the part defining just the DSI bus. I need a bit more 
time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.

The implementation is very simple and heavily based on your MIPI DBI 
support and existing Exynos MIPI DSIM framework. Provided operation set is 
based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately 
this is my only source of information about MIPI DSI.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform

From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001
From: Tomasz Figa t.f...@samsung.com
Date: Thu, 27 Dec 2012 12:36:15 +0100
Subject: [RFC] video: display: Add generic MIPI DSI bus

Signed-off-by: Tomasz Figa t.f...@samsung.com
---
 drivers/video/display/Kconfig|   4 +
 drivers/video/display/Makefile   |   1 +
 drivers/video/display/mipi-dsi-bus.c | 214 
+++
 include/video/display.h  |   1 +
 include/video/mipi-dsi-bus.h |  98 
 5 files changed, 318 insertions(+)
 create mode 100644 drivers/video/display/mipi-dsi-bus.c
 create mode 100644 include/video/mipi-dsi-bus.h

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 13b6aaf..dbaff9d 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI
tristate
default n
 
+config DISPLAY_MIPI_DSI
+   tristate
+   default n
+
 config DISPLAY_PANEL_DPI
tristate DPI (Parallel) Display Panels
---help---
diff --git a/drivers/video/display/Makefile 
b/drivers/video/display/Makefile
index 482bec7..429b3ac8 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_DISPLAY_CORE) += display-core.o
 obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
+obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o
 obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
 obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/mipi-dsi-bus.c 
b/drivers/video/display/mipi-dsi-bus.c
new file mode 100644
index 000..2998522
--- /dev/null
+++ b/drivers/video/display/mipi-dsi-bus.c
@@ -0,0 +1,214 @@
+/*
+ * MIPI DSI Bus

Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

2013-01-03 Thread Tomasz Figa
Hi Vikas,

On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
 From: Vikas Sajjan vikas.saj...@linaro.org
 
 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
  include/video/display.h |6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/include/video/display.h b/include/video/display.h
 index b639fd0..fb2f437 100644
 --- a/include/video/display.h
 +++ b/include/video/display.h
 @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
 
   void (*enable_hs)(struct video_source *src, bool enable);
 
 + /* frame related */
 + int (*get_frame_done)(struct video_source *src);
 + int (*clear_frame_done)(struct video_source *src);
 + int (*set_early_blank_mode)(struct video_source *src, int power);
 + int (*set_blank_mode)(struct video_source *src, int power);
 +

I'm not sure if all those extra ops are needed in any way.

Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only 
FB_BLANK_UNBLANK status, which basically equals to the already existing 
enable operation, while set_early_blank mode handles only 
FB_BLANK_POWERDOWN, being equal to disable callback.

Both get_frame_done and clear_frame_done do not look at anything used at 
the moment and if frame done status monitoring will be ever needed, I 
think a better way should be implemented.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform

--
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: [RFC v2 0/5] Common Display Framework

2013-01-08 Thread Tomasz Figa
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
 On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
  On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
  On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan 
wrote:
  On 17 December 2012 20:55, Laurent Pinchart wrote:
Hi Vikas,

Sorry for the late reply. I now have more time to
work on CDF, so
delays should be much shorter.

On Thursday 06 December 2012 10:51:15 Vikas Sajjan 
wrote:
  Hi Laurent,
  
  I was thinking of porting CDF to samsung
  EXYNOS 5250 platform,
  what I found is that, the exynos display
  controller is MIPI DSI
  based controller.
  
  But if I look at CDF patches, it has only
  support for MIPI DBI
  based Display controller.
  
  So my question is, do we have any generic
  framework for MIPI DSI
  based display controller? basically I wanted
  to know, how to go
  about porting CDF for such kind of display
  controller.

MIPI DSI support is not available yet. The only
reason for that is
that I don't have any MIPI DSI hardware to write
and test the code
with:-)

The common display framework should definitely
support MIPI DSI. I
think the existing MIPI DBI code could be used as
a base, so the
implementation shouldn't be too high.

Yeah, i was also thinking in similar lines, below
is my though for
MIPI DSI support in CDF.
  
  o   MIPI DSI support as part of CDF framework will
  expose
  §  mipi_dsi_register_device(mpi_device) (will be
  called mach-xxx-dt.c
  file )
  §  mipi_dsi_register_driver(mipi_driver, bus ops)
  (will be called
  from platform specific init driver call )
  ·bus ops will be
  o   read data
  o   write data
  o   write command
  §  MIPI DSI will be registered as bus_register()
  
  When MIPI DSI probe is called, it (e.g., Exynos or
  OMAP MIPI DSI)
  will initialize the MIPI DSI HW IP.
  
  This probe will also parse the DT file for MIPI DSI
  based panel, add
  the panel device (device_add() ) to kernel and
  register the display
  entity with its control and  video ops with CDF.
  
  I can give this a try.

I am currently in progress of reworking Exynos MIPI DSIM
code and
s6e8ax0 LCD driver to use the v2 RFC of Common Display
Framework. I
have most of the work done, I have just to solve several
remaining
problems.
  
  Do you already have code that you can publish ? I'm
  particularly
  interested (and I think Tomi Valkeinen would be as well) in
  looking at
  the DSI operations you expose to DSI sinks (panels,
  transceivers, ...).

Well, I'm afraid this might be little below your expectations, but
here's an initial RFC of the part defining just the DSI bus. I
need a bit more time for patches for Exynos MIPI DSI master and
s6e8ax0 LCD.
  
  No worries. I was particularly interested in the DSI operations you
  needed to export, they seem pretty simple. Thank you for sharing the
  code.
 FYI,
 here is STE DSI API:
 http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f
 =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD
 #l361
 
 But it is not perfect. After a couple of products we realized that most
 panel drivers want an easy way to send a bunch of init commands in one
 go. So I think it should be an op for sending an array of commands at
 once. Something like
 
 struct dsi_cmd {
  enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */
  u8 cmd;
  int dataLen;
  u8 *data;
 }
 struct dsi_ops {
  int dsi_write(source, int num_cmds, struct dsi_cmd *cmds);
  ...
 }

Yes, this should be flexible enough to cover most of (or even whole) DSI 
specification.

However I'm not sure whether the dsi_write name would be appropriate, 
since DSI packet types include also read and special transactions. So, 
according to DSI terminology, maybe dsi_transaction would be better?

 
 The rest of DSI write API could be made helpers on top of this one op.
 This grouping also allows driver to describe intent to send a bunch of
 commands together which might be of interest with mode set (if you need

Re: [oselas] Audio support on Mini6410 board

2013-02-09 Thread Tomasz Figa
Hi,

On Saturday 09 of February 2013 19:21:32 Sylwester Nawrocki wrote:
 Hi,
 
 On 01/20/2013 09:46 PM, Alexander Nestorov wrote:
  I have been playing for a week with the board. Both audio and video
  work correctly, but I haven't
  been able to set the mic settings in alsamixer (so I can't test the
  mic). The touchscreen isn't working, so I'll try to make it working
  and send you some patches.
  
  Anyways, now there's another question/problem that I have. Video
  playback is really slow because
  I'm not using the device's cpu-decoder but rather doing everything in
  software mode.
  
  Is there support for hardware acceleration in the kernel for this
  device? Also, after talking with
 
 No, there is still no video codec (MFC) driver for s3c6410 upstream.
 Now, when there is support for the hardware video codec available in
 newer SoC (Exynos4/5) and some V4L2 infrastructure added together with
 the s5p-mfc driver, it should be much easier to write a driver for the
 s3c64xx MFC. Still it is relatively huge task and I didn't see any
 volunteers willing to add support upstream for the s3c64xx MFC, except
 Andrey who replied in this thread. I could provide some help, but
 I will likely won't find time to do any development work or testing.
 
 Also please note there is no support for the mem-to-mem features (color
 space conversion, scaling, rotation/flip) in the s3c-camif driver.
 It should be relatively simple to add it though. I'm not really sure
 if it is needed to run the codec on s3c64xx, but the plugin [1] uses
 FIMC (CAMIF) as a video post-processor. This plugin sets up processing
 pipeline like:
 
 memory (compressed data) - MFC - (YCbCr tiled) memory - FIMC -
 memory (display)

AFAIK the MFC (like rest of the media processing peripherals) on S3C6410 
does not support tiled buffers. It uses the standard planar Y + Cb + Cr 
format.

In addition, the MFC of S3C6410 supports built-in rotation and mirroring 
of decoded video.

For scaling, there is a video post-processor block. There is no upstreamed 
driver for it, but the hardware is reasonably simple, so it wouldn't be 
too hard to write a driver for it. (I might be able to do it, although 
don't count on me, as I have also much other work to do, part of which is 
also related to S3C64xx).

Best regards,
Tomasz

  some people from #gstreamer they pointed me to a component[1] in
  gstreamer, but I'm not really
  sure how to I use it. Any ideas/experience with that?
 
 This component uses multi-planar V4L2 API [2], which also use the
 s5p-mfc and s5p-fimc driver. The s3c-camif driver uses the
 single-planar API at the camera capture video node. So if this existing
 plugin was to be used with the s3c64xx hardware, the drivers for it
 would have to support the multi-planar API, which I believe is not
 needed on s3c64xx hardware.
 The best is probably to make the drivers only single-plane API aware
 and adapt the plugin. The required changes at the plugin wouldn't be
 significant.
 
 Anyway, a real problem here is lack of the s3c64xx MFC driver. So
 first we need the codec driver, which could be tested with modified
 test application [3], or directly with modified plugin [1].
 
  Regards!
  
  [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc
 
 [2] http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
 [3]
 http://git.infradead.org/users/kmpark/public-apps/tree/9c057b001e8873861
 a70f7025214003837a0860b
 
 --
 
 Regards,
 Sylwester
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-samsung-soc in the body of a message to
 majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v2 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs

2013-06-25 Thread Tomasz Figa
Hi Sylwester, Felipe,

On Tuesday 25 of June 2013 19:44:52 Sylwester Nawrocki wrote:
 Hi Felipe,
 
 Thanks for the review.
 
 On 06/25/2013 05:06 PM, Felipe Balbi wrote:
  On Tue, Jun 25, 2013 at 04:21:46PM +0200, Sylwester Nawrocki wrote:
  +enum phy_id {
  +  PHY_CSIS0,
  +  PHY_DSIM0,
  +  PHY_CSIS1,
  +  PHY_DSIM1,
  +  NUM_PHYS
  
  please prepend these with EXYNOS_PHY_ or EXYNOS_MIPI_PHY_
 
 OK, will fix that.
 
  +struct exynos_video_phy {
  +  spinlock_t slock;
  +  struct phy *phys[NUM_PHYS];
  
  more than one phy ? This means you should instantiate driver multiple
  drivers. Each phy id should call probe again.
 
 Why ? This single PHY _provider_ can well handle multiple PHYs.
 I don't see a good reason to further complicate this driver like
 this. Please note that MIPI-CSIS 0 and MIPI DSIM 0 share MMIO
 register, so does MIPI CSIS 1 and MIPI DSIM 1. There are only 2
 registers for those 4 PHYs. I could have the involved object
 multiplied, but it would have been just a waste of resources
 with no difference to the PHY consumers.

IMHO one driver instance should represent one instance of IP block. Since 
this is a single IP block containing multiple PHYs with shared control 
interface, I think Sylwester did the right thing.

[snip]
  +static struct phy *exynos_video_phy_xlate(struct device *dev,
  +  struct of_phandle_args *args)
  +{
  +  struct exynos_video_phy *state = dev_get_drvdata(dev);
  +
  +  if (WARN_ON(args-args[0]  NUM_PHYS))
  +  return NULL;
  
  please remove this check.
 
 args-args[0] comes from DT as the PHY id and there is nothing
 preventing it from being greater or equal to the state-phys[]
 array length, unless I'm missing something. Actually it should
 have been 'if (args-args[0] = NUM_PHYS)'.

The xlate() callback gets directly whatever parsed from device tree, so it 
is possible for an out of range value to get here and so this check is 
valid. However I think it should rather return an ERR_PTR, not NULL. See 
of_phy_get().

  +  return state-phys[args-args[0]];
  
  and your xlate is 'wrong'.
 
 What exactly is wrong here ?

Felipe, could you elaborate a bit more on this? I can't find any serious 
problems with this code.

[snip]
  +  phy_provider = devm_of_phy_provider_register(dev,
  +  exynos_video_phy_xlate);
  +  if (IS_ERR(phy_provider))
  +  return PTR_ERR(phy_provider);
  +
  +  for (i = 0; i  NUM_PHYS; i++) {
  +  char label[8];
  +
  +  snprintf(label, sizeof(label), %s.%d,
  +  i == PHY_DSIM0 || i == PHY_DSIM1 ?
  +  dsim : csis, i / 2);
  +
  +  state-phys[i] = devm_phy_create(dev, i, 
exynos_video_phy_ops,
  +  label, 
state);
  +  if (IS_ERR(state-phys[i])) {
  +  dev_err(dev, failed to create PHY %s\n, label);
  +  return PTR_ERR(state-phys[i]);
  +  }
  +  }
  
  this really doesn't look correct to me. It looks like you have
  multiple
  PHYs, one for each ID. So your probe should be called for each PHY ID
  and you have several phy_providers too.
 
 Yes, multiple PHY objects, but a single provider. There is no need
 whatsoever for multiple PHY providers.

The whole concept of whatever-provider is to allow managing multiple 
objects by one parent object, like one clock provider for the whole clock 
controller, one interrupt controller object for all interrupts of an 
interrupt controller block, etc.

This is why a phandle has args, to allow addressing subobjects inside a 
provider.

Best regards,
Tomasz

--
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 V4 4/4] video: exynos_dp: Use the generic PHY driver

2013-07-05 Thread Tomasz Figa
Hi Jingoo,

On Tuesday 02 of July 2013 17:42:49 Jingoo Han wrote:
 Use the generic PHY API instead of the platform callback to control
 the DP PHY.
 
 Signed-off-by: Jingoo Han jg1@samsung.com
 ---
  .../devicetree/bindings/video/exynos_dp.txt|   23
 +--- drivers/video/exynos/exynos_dp_core.c 
 |   16 ++ drivers/video/exynos/exynos_dp_core.h
  |2 ++
  3 files changed, 20 insertions(+), 21 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
 b/Documentation/devicetree/bindings/video/exynos_dp.txt index
 84f10c1..022f4b6 100644
 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
 @@ -1,17 +1,6 @@
  The Exynos display port interface should be configured based on
  the type of panel connected to it.
 
 -We use two nodes:
 - -dp-controller node
 - -dptx-phy node(defined inside dp-controller node)
 -
 -For the DP-PHY initialization, we use the dptx-phy node.
 -Required properties for dptx-phy:
 - -reg:
 - Base address of DP PHY register.
 - -samsung,enable-mask:
 - The bit-mask used to enable/disable DP PHY.
 -

I wonder if this part shouldn't stay here, just marked as deprecated, 
because compatibility with old dtbs must be preserved (and rest of the 
patch looks like it is).

  For the Panel initialization, we read data from dp-controller node.
  Required properties for dp-controller:
   -compatible:
 @@ -25,6 +14,10 @@ Required properties for dp-controller:
   from common clock binding: handle to dp clock.
   -clock-names:
   from common clock binding: Shall be dp.
 + -phys:
 + from general PHY binding: the phandle for the PHY device.
 + -phy-names:
 + from general PHY binding: Should be dp.
   -interrupt-parent:
   phandle to Interrupt combiner node.
   -samsung,color-space:
 @@ -67,12 +60,8 @@ SOC specific portion:
   interrupt-parent = combiner;
   clocks = clock 342;
   clock-names = dp;
 -
 - dptx-phy {
 - reg = 0x10040720;
 - samsung,enable-mask = 1;
 - };
 -
 + phys = dp_phy;
 + phy-names = dp;
   };
 
  Board Specific portion:
 diff --git a/drivers/video/exynos/exynos_dp_core.c
 b/drivers/video/exynos/exynos_dp_core.c index 05fed7d..5e1a715 100644
 --- a/drivers/video/exynos/exynos_dp_core.c
 +++ b/drivers/video/exynos/exynos_dp_core.c
 @@ -19,6 +19,7 @@
  #include linux/interrupt.h
  #include linux/delay.h
  #include linux/of.h
 +#include linux/phy/phy.h
 
  #include exynos_dp_core.h
 
 @@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct
 exynos_dp_device *dp)
 
   dp_phy_node = of_find_node_by_name(dp_phy_node, dptx-phy);
   if (!dp_phy_node) {
 - dev_err(dp-dev, could not find dptx-phy node\n);
 - return -ENODEV;
 + dp-phy = devm_phy_get(dp-dev, dp);
 + if (IS_ERR(dp-phy))
 + return PTR_ERR(dp-phy);
 + else
 + return 0;
   }
 
   if (of_property_read_u32(dp_phy_node, reg, phy_base)) {
 @@ -992,7 +996,9 @@ err:
 
  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
 - if (dp-phy_addr) {
 + if (dp-phy) {
 + phy_power_on(dp-phy);
 + } else if (dp-phy_addr) {
   u32 reg;
 
   reg = __raw_readl(dp-phy_addr);
 @@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct
 exynos_dp_device *dp)
 
  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
  {
 - if (dp-phy_addr) {
 + if (dp-phy) {
 + phy_power_off(dp-phy);
 + } else if (dp-phy_addr) {
   u32 reg;
 
   reg = __raw_readl(dp-phy_addr);
 diff --git a/drivers/video/exynos/exynos_dp_core.h
 b/drivers/video/exynos/exynos_dp_core.h index 56cfec8..87804b6 100644
 --- a/drivers/video/exynos/exynos_dp_core.h
 +++ b/drivers/video/exynos/exynos_dp_core.h
 @@ -151,6 +151,8 @@ struct exynos_dp_device {
   struct video_info   *video_info;
   struct link_train   link_train;
   struct work_struct  hotplug_work;
 +

nit: unnecessary blank line

 + struct phy  *phy;
  };
 
  /* exynos_dp_reg.c */

Otherwise looks good.

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 V4 3/4] video: exynos_dp: remove non-DT support for Exynos Display Port

2013-07-05 Thread Tomasz Figa
Hi Jingoo,

On Tuesday 02 of July 2013 17:41:52 Jingoo Han wrote:
 Exynos Display Port can be used only for Exynos SoCs. In addition,
 non-DT for EXYNOS SoCs is be supported from v3.11; thus, there is
 no need to support non-DT for Exynos Display Port.
 
 The 'include/video/exynos_dp.h' file has been used for non-DT
 support and the content of file include/video/exynos_dp.h is moved
 to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
 file is removed. Also, 'struct exynos_dp_platdata' is removed,
 because it is not used any more.
 
 Signed-off-by: Jingoo Han jg1@samsung.com
 ---
  drivers/video/exynos/Kconfig  |2 +-
  drivers/video/exynos/exynos_dp_core.c |  116
 +++-- drivers/video/exynos/exynos_dp_core.h | 
 109 +++ drivers/video/exynos/exynos_dp_reg.c  |
2 -
  include/video/exynos_dp.h |  131
 - 5 files changed, 135 insertions(+),
 225 deletions(-)
  delete mode 100644 include/video/exynos_dp.h

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 V4 2/4] phy: Add driver for Exynos DP PHY

2013-07-05 Thread Tomasz Figa
On Tuesday 02 of July 2013 17:40:31 Jingoo Han wrote:
 Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
 
 Signed-off-by: Jingoo Han jg1@samsung.com
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Acked-by: Felipe Balbi ba...@ti.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|8 ++
  drivers/phy/Kconfig|6 ++
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos-dp-video.c  |  111
  4 files changed, 126 insertions(+)
  create mode 100644 drivers/phy/phy-exynos-dp-video.c

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 V4 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi

2013-07-05 Thread Tomasz Figa
On Tuesday 02 of July 2013 17:39:11 Jingoo Han wrote:
 Add PHY provider node for the DP PHY.
 
 Signed-off-by: Jingoo Han jg1@samsung.com
 Acked-by: Felipe Balbi ba...@ti.com
 ---
  arch/arm/boot/dts/exynos5250.dtsi |   13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-21 Thread Tomasz Figa
Hi,

On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
 On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
  On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.

Ick, don't pass strings around, pass pointers.  If you have
platform
data you can get to, then put the pointer there, don't use a
name.

I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
   
   Why will you not have that pointer?  You can't rely on the name as
   the device id will not match up, so you should be able to rely on
   the pointer being in the structure that the board sets up, right?
   
   Don't use names, especially as ids can, and will, change, that is
   going
   to cause big problems.  Use pointers, this is C, we are supposed to
   be
   doing that :)
  
  Kishon, I think what Greg means is this:  The name you are using must
  be stored somewhere in a data structure constructed by the board file,
  right?  Or at least, associated with some data structure somehow.
  Otherwise the platform code wouldn't know which PHY hardware
  corresponded to a particular name.
  
  Greg's suggestion is that you store the address of that data structure
  in the platform data instead of storing the name string.  Have the
  consumer pass the data structure's address when it calls phy_create,
  instead of passing the name.  Then you don't have to worry about two
  PHYs accidentally ending up with the same name or any other similar
  problems.
 
 Close, but the issue is that whatever returns from phy_create() should
 then be used, no need to call any find functions, as you can just use
 the pointer that phy_create() returns.  Much like all other class api
 functions in the kernel work.

I think there is a confusion here about who registers the PHYs.

All platform code does is registering a platform/i2c/whatever device, 
which causes a driver (located in drivers/phy/) to be instantiated. Such 
drivers call phy_create(), usually in their probe() callbacks, so 
platform_code has no way (and should have no way, for the sake of 
layering) to get what phy_create() returns.

IMHO we need a lookup method for PHYs, just like for clocks, regulators, 
PWMs or even i2c busses because there are complex cases when passing just 
a name using platform data will not work. I would second what Stephen said 
[1] and define a structure doing things in a DT-like way.

Example;

[platform code]

static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
/* etc... */
};

static void my_machine_init(void)
{
/* ... */
phy_register_lookup(my_phy_lookup, ARRAY_SIZE(my_phy_lookup));
/* ... */
}

/* Notice nothing stuffed in platform data. */

[provider code - samsung-usbphy driver]

static int samsung_usbphy_probe(...)
{
/* ... */
for (i = 0; i  PHY_COUNT; ++i) {
usbphy-phy[i].name = phy;
usbphy-phy[i].id = i;
/* ... */
ret = phy_create(usbphy-phy);
/* err handling */
}
/* ... */
}

[consumer code - s3c-hsotg driver]

static int s3c_hsotg_probe(...)
{
/* ... */
phy = phy_get(pdev-dev, otg);
/* ... */
}

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-21 Thread Tomasz Figa
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
 Hi,
 
 On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
  Hi,
  
  On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
  On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
  On Sat, 20 Jul 2013, Greg KH wrote:
  That should be passed using platform data.
  
  Ick, don't pass strings around, pass pointers.  If you have
  platform
  data you can get to, then put the pointer there, don't use a
  name.
  
  I don't think I understood you here :-s We wont have phy pointer
  when we create the device for the controller no?(it'll be done in
  board file). Probably I'm missing something.
  
  Why will you not have that pointer?  You can't rely on the name
  as
  the device id will not match up, so you should be able to rely on
  the pointer being in the structure that the board sets up, right?
  
  Don't use names, especially as ids can, and will, change, that is
  going
  to cause big problems.  Use pointers, this is C, we are supposed to
  be
  doing that :)
  
  Kishon, I think what Greg means is this:  The name you are using
  must
  be stored somewhere in a data structure constructed by the board
  file,
  right?  Or at least, associated with some data structure somehow.
  Otherwise the platform code wouldn't know which PHY hardware
  corresponded to a particular name.
  
  Greg's suggestion is that you store the address of that data
  structure
  in the platform data instead of storing the name string.  Have the
  consumer pass the data structure's address when it calls phy_create,
  instead of passing the name.  Then you don't have to worry about two
  PHYs accidentally ending up with the same name or any other similar
  problems.
  
  Close, but the issue is that whatever returns from phy_create()
  should
  then be used, no need to call any find functions, as you can just
  use
  the pointer that phy_create() returns.  Much like all other class api
  functions in the kernel work.
  
  I think there is a confusion here about who registers the PHYs.
  
  All platform code does is registering a platform/i2c/whatever device,
  which causes a driver (located in drivers/phy/) to be instantiated.
  Such drivers call phy_create(), usually in their probe() callbacks,
  so platform_code has no way (and should have no way, for the sake of
  layering) to get what phy_create() returns.
 
 right.
 
  IMHO we need a lookup method for PHYs, just like for clocks,
  regulators, PWMs or even i2c busses because there are complex cases
  when passing just a name using platform data will not work. I would
  second what Stephen said [1] and define a structure doing things in a
  DT-like way.
  
  Example;
  
  [platform code]
  
  static const struct phy_lookup my_phy_lookup[] = {
  
  PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
 
 The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
 creating the device, the ids in the device name would change and
 PHY_LOOKUP wont be useful.

I don't think this is a problem. All the existing lookup methods already 
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
can simply add a requirement that the ID must be assigned manually, 
without using PLATFORM_DEVID_AUTO to use PHY lookup.

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
Hi Alan,

On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
 On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
 The PHY and the controller it is attached to are both physical
 devices.
 
 The connection between them is hardwired by the system
 manufacturer and cannot be changed by software.
 
 PHYs are generally described by fixed system-specific board
 files or by Device Tree information.  Are they ever discovered
 dynamically?
  
  No. They are created just like any other platform devices are created.
 
 Okay.  Are PHYs _always_ platform devices?

They can be i2c, spi or any other device types as well.

 Is the same true for the controllers attached to the PHYs?
 If not -- if both a PHY and a controller are discovered
 dynamically -- how does the kernel know whether they are
 connected to each other?
  
  No differences here. Both PHY and controller will have dt information
  or hwmod data using which platform devices will be created.
  
 The kernel needs to know which controller is attached to which
 PHY.  Currently this information is represented by name or ID
 strings embedded in platform data.
  
  right. It's embedded in the platform data of the controller.
 
 It must also be embedded in the PHY's platform data somehow.
 Otherwise, how would the kernel know which PHY to use?

By using a PHY lookup as Stephen and I suggested in our previous replies. 
Without any extra data in platform data. (I have even posted a code 
example.)

 The PHY's driver (the supplier) uses the platform data to
 construct a platform_device structure that represents the PHY.
  
  Currently the driver assigns static labels (corresponding to the label
  used in the platform data of the controller).
  
 Until this is done, the controller's driver (the client) cannot
 use the PHY.
  
  right.
  
 Since there is no parent-child relation between the PHY and the
 controller, there is no guarantee that the PHY's driver will be
 ready when the controller's driver wants to use it.  A deferred
 probe may be needed.
  
  right.
  
 The issue (or one of the issues) in this discussion is that
 Greg does not like the idea of using names or IDs to associate
 PHYs with controllers, because they are too prone to
 duplications or other errors.  Pointers are more reliable.
 
 But pointers to what?  Since the only data known to be
 available to both the PHY driver and controller driver is the
 platform data, the obvious answer is a pointer to platform data
 (either for the PHY or for the controller, or maybe both).
  
  hmm.. it's not going to be simple though as the platform device for
  the PHY and controller can be created in entirely different places.
  e.g., in some cases the PHY device is a child of some mfd core device
  (the device will be created in drivers/mfd) and the controller driver
  (usually) is created in board file. I guess then we have to come up
  with something to share a pointer in two different files.
 
 The ability for two different source files to share a pointer to a data
 item defined in a third source file has been around since long before
 the C language was invented.  :-)
 
 In this case, it doesn't matter where the platform_device structures
 are created or where the driver source code is.  Let's take a simple
 example.  Suppose the system design includes a PHY named foo.  Then
 the board file could contain:
 
 struct phy_info { ... } phy_foo;
 EXPORT_SYMBOL_GPL(phy_foo);
 
 and a header file would contain:
 
 extern struct phy_info phy_foo;
 
 The PHY supplier could then call phy_create(phy_foo), and the PHY
 client could call phy_find(phy_foo).  Or something like that; make up
 your own structure tags and function names.
 
 It's still possible to have conflicts, but now two PHYs with the same
 name (or a misspelled name somewhere) will cause an error at link time.

This is incorrect, sorry. First of all it's a layering violation - you 
export random driver-specific symbols from one driver to another. Then 
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and 
there are two types of consumer drivers (e.g. USB host controllers). Now 
consider following mapping:

SoC PHY consumer
A   PHY1HOST1
B   PHY1HOST2
C   PHY2HOST1
D   PHY2HOST2

So we have to be able to use any of the PHYs with any of the host drivers. 
This means you would have to export symbol with the same name from both 
PHY drivers, which obviously would not work in this case, because having 
both drivers enabled (in a multiplatform aware configuration) would lead 
to linking conflict.

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
[Fixed address of devicetree mailing list and added more people on CC.]

For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813

Best regards,
Tomasz

On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
 Hi Alan,
 
 On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
  On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
The PHY and the controller it is attached to are both 
physical
devices.

The connection between them is hardwired by the system
manufacturer and cannot be changed by software.

PHYs are generally described by fixed system-specific 
board
files or by Device Tree information.  Are they ever 
discovered
dynamically?
   
   No. They are created just like any other platform devices are
   created.
  
  Okay.  Are PHYs _always_ platform devices?
 
 They can be i2c, spi or any other device types as well.
 
Is the same true for the controllers attached to the PHYs?
If not -- if both a PHY and a controller are discovered
dynamically -- how does the kernel know whether they are
connected to each other?
   
   No differences here. Both PHY and controller will have dt
   information
   or hwmod data using which platform devices will be created.
   
The kernel needs to know which controller is attached to 
which
PHY.  Currently this information is represented by name or 
ID
strings embedded in platform data.
   
   right. It's embedded in the platform data of the controller.
  
  It must also be embedded in the PHY's platform data somehow.
  Otherwise, how would the kernel know which PHY to use?
 
 By using a PHY lookup as Stephen and I suggested in our previous
 replies. Without any extra data in platform data. (I have even posted a
 code example.)
 
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the 
PHY.
   
   Currently the driver assigns static labels (corresponding to the
   label
   used in the platform data of the controller).
   
Until this is done, the controller's driver (the client) 
cannot
use the PHY.
   
   right.
   
Since there is no parent-child relation between the PHY 
and the
controller, there is no guarantee that the PHY's driver 
will be
ready when the controller's driver wants to use it.  A 
deferred
probe may be needed.
   
   right.
   
The issue (or one of the issues) in this discussion is 
that
Greg does not like the idea of using names or IDs to 
associate
PHYs with controllers, because they are too prone to
duplications or other errors.  Pointers are more reliable.

But pointers to what?  Since the only data known to be
available to both the PHY driver and controller driver is 
the
platform data, the obvious answer is a pointer to platform 
data
(either for the PHY or for the controller, or maybe both).
   
   hmm.. it's not going to be simple though as the platform device for
   the PHY and controller can be created in entirely different places.
   e.g., in some cases the PHY device is a child of some mfd core
   device
   (the device will be created in drivers/mfd) and the controller
   driver
   (usually) is created in board file. I guess then we have to come up
   with something to share a pointer in two different files.
  
  The ability for two different source files to share a pointer to a
  data
  item defined in a third source file has been around since long before
  the C language was invented.  :-)
  
  In this case, it doesn't matter where the platform_device structures
  are created or where the driver source code is.  Let's take a simple
  example.  Suppose the system design includes a PHY named foo.  Then
  the board file could contain:
  
  struct phy_info { ... } phy_foo;
  EXPORT_SYMBOL_GPL(phy_foo);
  
  and a header file would contain:
  
  extern struct phy_info phy_foo;
  
  The PHY supplier could then call phy_create(phy_foo), and the PHY
  client could call phy_find(phy_foo).  Or something like that; make up
  your own structure tags and function names.
  
  It's still possible to have conflicts, but now two PHYs with the same
  name (or a misspelled name somewhere) will cause an error at link
  time.
 
 This is incorrect, sorry. First of all it's a layering violation - you
 export random driver-specific symbols from one driver to another. Then
 imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
 there are two types of consumer drivers (e.g. USB host controllers). Now
 consider following mapping:
 
 SoC   PHY consumer
 A PHY1HOST1
 B PHY1HOST2
 C PHY2HOST1
 D PHY2HOST2

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
 On Tue, 23 Jul 2013, Tomasz Figa wrote:
  On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
   Hi Alan,
 
 Thanks for helping to clarify the issues here.
 
Okay.  Are PHYs _always_ platform devices?
   
   They can be i2c, spi or any other device types as well.
 
 In those other cases, presumably there is no platform data associated
 with the PHY since it isn't a platform device.  Then how does the
 kernel know which controller is attached to the PHY?  Is this spelled
 out in platform data associated with the PHY's i2c/spi/whatever parent?
 
  PHY.  Currently this information is represented by name or
  
  ID
  
  strings embedded in platform data.
 
 right. It's embedded in the platform data of the controller.

It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
   
   By using a PHY lookup as Stephen and I suggested in our previous
   replies. Without any extra data in platform data. (I have even posted
   a
   code example.)
 
 I don't understand, because I don't know what a PHY lookup does.

I have provided a code example in [1]. Feel free to ask questions about 
those code snippets.

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889

In this case, it doesn't matter where the platform_device
structures
are created or where the driver source code is.  Let's take a
simple
example.  Suppose the system design includes a PHY named foo. 
Then
the board file could contain:

struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);

and a header file would contain:

extern struct phy_info phy_foo;

The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo).  Or something like that; make
up
your own structure tags and function names.

It's still possible to have conflicts, but now two PHYs with the
same
name (or a misspelled name somewhere) will cause an error at link
time.
   
   This is incorrect, sorry. First of all it's a layering violation -
   you
   export random driver-specific symbols from one driver to another.
   Then
 
 No, that's not what I said.  Neither the PHY driver nor the controller
 driver exports anything to the other.  Instead, both drivers use data
 exported by the board file.

It's still a random, driver-specific global symbol exported from board file 
to drivers.

   imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
   and
   there are two types of consumer drivers (e.g. USB host controllers).
   Now
   consider following mapping:
   
   SoC   PHY consumer
   A PHY1HOST1
   B PHY1HOST2
   C PHY2HOST1
   D PHY2HOST2
   
   So we have to be able to use any of the PHYs with any of the host
   drivers. This means you would have to export symbol with the same
   name
   from both PHY drivers, which obviously would not work in this case,
   because having both drivers enabled (in a multiplatform aware
   configuration) would lead to linking conflict.
 
 You're right; the scheme was too simple.  Instead, the board file must
 export two types of data structures, one for PHYs and one for
 controllers.  Like this:
 
 struct phy_info {
   /* Info for the controller attached to this PHY */
   struct controller_info  *hinfo;
 };
 
 struct controller_info {
   /* Info for the PHY which this controller is attached to */
   struct phy_info *pinfo;
 };
 
 The board file for SoC A would contain:
 
 struct phy_info phy1 = {host1);
 EXPORT_SYMBOL(phy1);
 struct controller_info host1 = {phy1};
 EXPORT_SYMBOL(host1);
 
 The board file for SoC B would contain:
 
 struct phy_info phy1 = {host2);
 EXPORT_SYMBOL(phy1);
 struct controller_info host2 = {phy1};
 EXPORT_SYMBOL(host2);
 
 And so on.  This explicitly gives the connection between PHYs and
 controllers.  The PHY providers would use phy1 or phy2, and the PHY
 consumers would use host1 or host2.

This could work assuming that only one SoC and one board is supported in 
single kernel image. However it's not the case.

We've used to support multiple boards since a long time already and now for 
selected platforms we even support multiplatform, i.e. multiple SoCs in 
single zImage. Such solution will not work.

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
 On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
  Hi,
  
  On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
   On Tue, 23 Jul 2013, Tomasz Figa wrote:
   On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
   Hi Alan,
   
   Thanks for helping to clarify the issues here.
   
   Okay.  Are PHYs _always_ platform devices?
   
   They can be i2c, spi or any other device types as well.
   
   In those other cases, presumably there is no platform data associated
   with the PHY since it isn't a platform device.  Then how does the
   kernel know which controller is attached to the PHY?  Is this spelled
   out in platform data associated with the PHY's i2c/spi/whatever
   parent?
  
  Yes. I think we could use i2c_board_info for passing platform data.
  
PHY.  Currently this information is represented by name or
   
   ID
   
strings embedded in platform data.
   
   right. It's embedded in the platform data of the controller.
   
   It must also be embedded in the PHY's platform data somehow.
   Otherwise, how would the kernel know which PHY to use?
   
   By using a PHY lookup as Stephen and I suggested in our previous
   replies. Without any extra data in platform data. (I have even
   posted a
   code example.)
   
   I don't understand, because I don't know what a PHY lookup does.
  
  It is how the PHY framework finds a PHY, when the controller (say
  USB)requests a PHY from the PHY framework.
  
   In this case, it doesn't matter where the platform_device
   structures
   are created or where the driver source code is.  Let's take a
   simple
   example.  Suppose the system design includes a PHY named foo. 
   Then
   the board file could contain:
   
   struct phy_info { ... } phy_foo;
   EXPORT_SYMBOL_GPL(phy_foo);
   
   and a header file would contain:
   
   extern struct phy_info phy_foo;
   
   The PHY supplier could then call phy_create(phy_foo), and the PHY
   client could call phy_find(phy_foo).  Or something like that;
   make up
   your own structure tags and function names.
   
   It's still possible to have conflicts, but now two PHYs with the
   same
   name (or a misspelled name somewhere) will cause an error at link
   time.
   
   This is incorrect, sorry. First of all it's a layering violation -
   you
   export random driver-specific symbols from one driver to another.
   Then
   
   No, that's not what I said.  Neither the PHY driver nor the
   controller
   driver exports anything to the other.  Instead, both drivers use data
   exported by the board file.
  
  I think instead we can use the same data while creating the platform
  data of the controller and the PHY.
  The PHY driver while creating the PHY (using PHY framework) will also
  pass the *data* it actually got from the platform data to the
  framework. The PHY user driver (USB), while requesting for the PHY
  (from the PHY framework) will pass the *data* it got from its platform
  data.
  The PHY framework can do a comparison of the *data* pointers it has and
  return the appropriate PHY to the controller.
  
   imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
   and
   there are two types of consumer drivers (e.g. USB host
   controllers). Now
   consider following mapping:
   
   SoC PHY consumer
   A   PHY1HOST1
   B   PHY1HOST2
   C   PHY2HOST1
   D   PHY2HOST2
   
   So we have to be able to use any of the PHYs with any of the host
   drivers. This means you would have to export symbol with the same
   name
   from both PHY drivers, which obviously would not work in this case,
   because having both drivers enabled (in a multiplatform aware
   configuration) would lead to linking conflict.
   
   You're right; the scheme was too simple.  Instead, the board file
   must
   export two types of data structures, one for PHYs and one for
   controllers.  Like this:
   
   struct phy_info {
   
 /* Info for the controller attached to this PHY */
 struct controller_info  *hinfo;
   
   };
   
   struct controller_info {
   
 /* Info for the PHY which this controller is attached to */
 struct phy_info *pinfo;
   
   };
   
   The board file for SoC A would contain:
   
   struct phy_info phy1 = {host1);
   EXPORT_SYMBOL(phy1);
   struct controller_info host1 = {phy1};
   EXPORT_SYMBOL(host1);
   
   The board file for SoC B would contain:
   
   struct phy_info phy1 = {host2);
   EXPORT_SYMBOL(phy1);
   struct controller_info host2 = {phy1};
   EXPORT_SYMBOL(host2);
  
  I meant something like this
  struct phy_info {
  
  const char *name;
  
  };
  
  struct phy_platform_data {
  
  .
  .
  struct phy_info *info;
  
  };
  
  struct usb_controller_platform_data {
  
  .
  .
  struct phy_info *info;
  
  };
  
  struct phy_info phy_info;
  
  While creating the phy device
  
  struct phy_platform_data phy_data

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
 On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
   Ick, no.  Why can't you just pass the pointer to the phy itself?  If
   you
   had a priv pointer to search from, then you could have just passed
   the
   original phy pointer in the first place, right?
  
  IMHO it would be better if you provided some code example, but let's
  try to check if I understood you correctly.
 
 It's not my code that I want to have added, so I don't have to write
 examples, I just get to complain about the existing stuff :)

Still, I think that some small code snippets illustrating the idea are 
really helpful.

  8
  
  
  [Board file]
  
  static struct phy my_phy;
  
  static struct platform_device phy_pdev = {
  
  /* ... */
  .platform_data = my_phy;
  /* ... */
  
  };
  
  static struct platform_device phy_pdev = {
  
  /* ... */
  .platform_data = my_phy;
  /* ... */
  
  };
  
  [Provider driver]
  
  struct phy *phy = pdev-dev.platform_data;
  
  ret = phy_create(phy);
  
  [Consumer driver]
  
  struct phy *phy = pdev-dev.platform_data;
  
  ret = phy_get(pdev-dev, phy);
  
  ---
  -8
  
  Is this what you mean?
 
 No.  Well, kind of.  What's wrong with using the platform data structure
 unique to the board to have the pointer?
 
 For example (just randomly picking one), the ata-pxa driver would change
 include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
 
 struct phy;
 
 struct  pata_pxa_pdata {
   /* PXA DMA DREQ0:2 pin */
   uint32_tdma_dreq;
   /* Register shift */
   uint32_treg_shift;
   /* IRQ flags */
   uint32_tirq_flags;
   /* PHY */
   struct phy  *phy;
 };
 
 Then, when you create the platform, set the phy* pointer with a call to
 phy_create().  Then you can use that pointer wherever that plaform data
 is available (i.e. whereever platform_data is at).

Hmm? So, do you suggest to call phy_create() from board file? What phy_ops 
struct and other hardware parameters would it take?

   The issue is that a string name is not going to scale at all, as it
   requires hard-coded information that will change over time (as the
   existing clock interface is already showing.)
  
  I fully agree that a simple, single string will not scale even in some,
  not so uncommon cases, but there is already a lot of existing lookup
  solutions over the kernel and so there is no point in introducing
  another one.
 I'm trying to get _rid_ of lookup solutions and just use a real
 pointer, as you should.  I'll go tackle those other ones after this one
 is taken care of, to show how the others should be handled as well.

There was a reason for introducing lookup solutions. The reason was that in 
board file there is no way to get a pointer to something that is going to be 
created much later in time. We don't do time travel ;-).

   Please just pass the real phy pointer around, that's what it is
   there
   for.  Your board binding logic/code should be able to handle this,
   as
   it somehow was going to do the same thing with a name.
  
  It's technically correct, but quality of this solution isn't really
  nice, because it's a layering violation (at least if I understood what
  you mean). This is because you need to have full definition of struct
  phy in board file and a structure that is used as private data in PHY
  core comes from platform code.
 
 No, just a pointer, you don't need the full structure until you get to
 some .c code that actually manipulates the phy itself, for all other
 places, you are just dealing with a pointer and a structure you never
 reference.
 
 Does that make more sense?

Well, to the point that I think I now understood your suggestion. 
Unfortunately the suggestion alone isn't really something that can be done, 
considering how driver core and generic frameworks work.

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
 On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
   You don't know the id of the device you are looking up, due to
   multiple devices being in the system (dynamic ids, look back earlier
   in
   this thread for details about that.)
  
  I got copied in very late so don't have most of the thread I'm afraid,
  I did try looking at web archives but didn't see a clear problem
  statement.  In any case this is why the APIs doing lookups do the
  lookups in the context of the requesting device - devices ask for
  whatever name they use locally.
 
 What do you mean by locally?
 
 The problem with the api was that the phy core wanted a id and a name to
 create a phy, and then later other code was doing a lookup based on
 the name and id (mushed together), because it knew that this device
 was the one it wanted.
 
 Just like the clock api, which, for multiple devices, has proven to
 cause problems.  I don't want to see us accept an api that we know has
 issues in it now, I'd rather us fix it up properly.
 
 Subsystems should be able to create ids how ever they want to, and not
 rely on the code calling them to specify the names of the devices that
 way, otherwise the api is just too fragile.
 
 I think, that if you create a device, then just carry around the pointer
 to that device (in this case a phy) and pass it to whatever other code
 needs it.  No need to do lookups on known names or anything else,
 just normal pointers, with no problems for multiple devices, busses, or
 naming issues.

PHY object is not a device, it is something that a device driver creates 
(one or more instances of) when it is being probed. You don't have a clean 
way to export this PHY object to other driver, other than keeping this PHY 
on a list inside PHY core with some well-known ID (e.g. device name + 
consumer port name/index, like in regulator core) and then to use this 
well-known ID inside consumer driver as a lookup key passed to phy_get();

Actually I think for PHY case, exactly the same way as used for regulators 
might be completely fine:

1. Each PHY would have some kind of platform, non-unique name, that is 
just used to print some messages (like the platform/board name of a 
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would 
consist of consumer device name and consumer port name - just like in 
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its 
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't 
receive any information about PHYs from platform code.

Code example:

[Board file]

static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};

static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};

static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};

static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};

[PHY driver]

static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}

[EHCI driver]

static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}

[OTG driver]

static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}

Having to write platform data for everything gets old fast and the
code
duplication is pretty tedious...
   
   Adding a single pointer is tedious?  Where is the name that you
   are
   going to lookup going to come from?  That code doesn't write
   itself...
  
  It's adding platform data in the first place that gets tedious - and
  of
  course there's also DT and ACPI to worry about, it's not just a case
  of
  platform data and then you're done.  Pushing the lookup into library
  code means that drivers don't have to worry about any of this stuff.
 
 I agree, so just pass around the pointer to the phy and all is good.  No
 need to worry about DT or ACPI or anything else.

With Device Tree we don't have board files anymore. How would 

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
 On Tue, 23 Jul 2013, Tomasz Figa wrote:
  IMHO it would be better if you provided some code example, but let's
  try to check if I understood you correctly.
  
  8---
  -
  
  [Board file]
  
  static struct phy my_phy;
  
  static struct platform_device phy_pdev = {
  
  /* ... */
  .platform_data = my_phy;
  /* ... */
  
  };
  
  static struct platform_device phy_pdev = {
 
 This should be controller_pdev, not phy_pdev, yes?

Right. A copy-pasto.

 
  /* ... */
  .platform_data = my_phy;
  /* ... */
  
  };
  
  [Provider driver]
  
  struct phy *phy = pdev-dev.platform_data;
  
  ret = phy_create(phy);
  
  [Consumer driver]
  
  struct phy *phy = pdev-dev.platform_data;
  
  ret = phy_get(pdev-dev, phy);
 
 Or even just phy_get(pdev-dev), because phy_get() could be smart
 enough to to set phy = dev-platform_data.

Unless you need more than one PHY in this driver...

 
  --
  --8
  
  Is this what you mean?
 
 That's what I was going to suggest too.  The struct phy is defined in
 the board file, which already knows about all the PHYs that exist in
 the system.  (Or perhaps it is allocated dynamically, so that when many
 board files are present in the same kernel, only the entries listed in
 the board file for the current system get created.) 

Well, such dynamic allocation is a must. We don't accept non-multiplatform 
aware code anymore, not even saying about multiboard.

 Then the
 structure's address is stored in the platform data and made available
 to both the provider and the consumer.

Yes, technically this can work. You would still have to perform some kind 
of synchronization to make sure that the PHY bound to this structure is 
actually present. This is again technically doable (e.g. a list of 
registered struct phys inside PHY core).

 Even though the struct phy is defined (or allocated) in the board file,
 its contents don't get filled in until the PHY driver provides the
 details.

You can't assure this. Board file is free to do whatever it wants with 
this struct. A clean solution would prevent this.

  It's technically correct, but quality of this solution isn't really
  nice, because it's a layering violation (at least if I understood
  what you mean). This is because you need to have full definition of
  struct phy in board file and a structure that is used as private data
  in PHY core comes from platform code.
 
 You don't have to have a full definition in the board file.  Just a
 partial definition -- most of the contents can be filled in later, when
 the PHY driver is ready to store the private data.
 
 It's not a layering violation for one region of the kernel to store
 private data in a structure defined by another part of the kernel.
 This happens all the time (e.g., dev_set_drvdata).

Not really. The phy struct is something that _is_ private data of PHY 
subsystem, not something that can store private data of PHY subsystem 
(sure it can store private data of particular PHY driver, but that's 
another story) and only PHY subsystem should have access to its contents.

By the way, we need to consider other cases here as well, for example it 
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's 
being probed from DT or not.

I'd suggest simply reusing the lookup method of regulator framework, just 
as I suggested here:

http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
 On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
  On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
   On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
 Ick, no.  Why can't you just pass the pointer to the phy itself?
  If
 you
 had a priv pointer to search from, then you could have just
 passed
 the
 original phy pointer in the first place, right?

IMHO it would be better if you provided some code example, but
let's
try to check if I understood you correctly.
   
   It's not my code that I want to have added, so I don't have to write
   examples, I just get to complain about the existing stuff :)
  
  Still, I think that some small code snippets illustrating the idea are
  really helpful.
  
8---
-


[Board file]

static struct phy my_phy;

static struct platform_device phy_pdev = {

/* ... */
.platform_data = my_phy;
/* ... */

};

static struct platform_device phy_pdev = {

/* ... */
.platform_data = my_phy;
/* ... */

};

[Provider driver]

struct phy *phy = pdev-dev.platform_data;

ret = phy_create(phy);

[Consumer driver]

struct phy *phy = pdev-dev.platform_data;

ret = phy_get(pdev-dev, phy);

--
-
-8

Is this what you mean?
   
   No.  Well, kind of.  What's wrong with using the platform data
   structure unique to the board to have the pointer?
   
   For example (just randomly picking one), the ata-pxa driver would
   change include/linux/platform_data/ata-pxa.h to have a phy pointer
   in it:
   
   struct phy;
   
   struct  pata_pxa_pdata {
   
 /* PXA DMA DREQ0:2 pin */
 uint32_tdma_dreq;
 /* Register shift */
 uint32_treg_shift;
 /* IRQ flags */
 uint32_tirq_flags;
 /* PHY */
 struct phy  *phy;
   
   };
   
   Then, when you create the platform, set the phy* pointer with a call
   to
   phy_create().  Then you can use that pointer wherever that plaform
   data
   is available (i.e. whereever platform_data is at).
  
  Hmm? So, do you suggest to call phy_create() from board file? What
  phy_ops struct and other hardware parameters would it take?
  
 The issue is that a string name is not going to scale at all,
 as it
 requires hard-coded information that will change over time (as
 the
 existing clock interface is already showing.)

I fully agree that a simple, single string will not scale even in
some,
not so uncommon cases, but there is already a lot of existing
lookup
solutions over the kernel and so there is no point in introducing
another one.
   
   I'm trying to get _rid_ of lookup solutions and just use a real
   pointer, as you should.  I'll go tackle those other ones after this
   one
   is taken care of, to show how the others should be handled as well.
  
  There was a reason for introducing lookup solutions. The reason was
  that in board file there is no way to get a pointer to something that
  is going to be created much later in time. We don't do time travel
  ;-).
  
 Please just pass the real phy pointer around, that's what it
 is
 there
 for.  Your board binding logic/code should be able to handle
 this,
 as
 it somehow was going to do the same thing with a name.

It's technically correct, but quality of this solution isn't
really
nice, because it's a layering violation (at least if I understood
what
you mean). This is because you need to have full definition of
struct
phy in board file and a structure that is used as private data in
PHY
core comes from platform code.
   
   No, just a pointer, you don't need the full structure until you
   get to some .c code that actually manipulates the phy itself, for
   all other places, you are just dealing with a pointer and a
   structure you never reference.
   
   Does that make more sense?
  
  Well, to the point that I think I now understood your suggestion.
  Unfortunately the suggestion alone isn't really something that can be
  done, considering how driver core and generic frameworks work.
 
 Ok, given that I seem to be totally confused as to exactly how the
 board-specific frameworks work, I'll take your word for it.

Well, they are working in a way that keeps separation of layers, making 
things clean. Platform code should not (well, there might exist some in 
tree hacks, but this should not be propagated) used to exchange data 
between drivers, but rather to specify board specific parameters for 
generic drivers. If drivers need to cooperate, there must be a dedicated 
interface

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote:
 On Tue, 23 Jul 2013, Tomasz Figa wrote:
   That's what I was going to suggest too.  The struct phy is defined
   in
   the board file, which already knows about all the PHYs that exist in
   the system.  (Or perhaps it is allocated dynamically, so that when
   many
   board files are present in the same kernel, only the entries listed
   in
   the board file for the current system get created.)
  
  Well, such dynamic allocation is a must. We don't accept
  non-multiplatform aware code anymore, not even saying about
  multiboard.
  
   Then the
   structure's address is stored in the platform data and made
   available
   to both the provider and the consumer.
  
  Yes, technically this can work. You would still have to perform some
  kind of synchronization to make sure that the PHY bound to this
  structure is actually present. This is again technically doable (e.g.
  a list of registered struct phys inside PHY core).
 
 The synchronization takes place inside phy_get.  If phy_create hasn't
 been called for this structure by the time phy_get runs, phy_get will
 return an error.

Yes, this is the solution that I had in mind when saying that this is 
doable.

   Even though the struct phy is defined (or allocated) in the board
   file,
   its contents don't get filled in until the PHY driver provides the
   details.
  
  You can't assure this. Board file is free to do whatever it wants with
  this struct. A clean solution would prevent this.
 
 I'm not sure what you mean here.  Of course I can't prevent a board
 file from messing up a data structure.  I can't prevent it from causing
 memory access violations either; in fact, I can't prevent any bugs in
 other people's code.
 
 Besides, why do you say the board file is free to do whatever it wants
 with the struct phy?  Currently the struct phy is created by the PHY
 provider and the PHY core, right?  It's not even mentioned in the board
 file.

I mean, if you have a struct type of which full declaration is available 
for some code, this code can access any memeber of it without any hacks, 
which is not something that we want to have in board files. The phy struct 
should be opaque for them.

It's technically correct, but quality of this solution isn't
really
nice, because it's a layering violation (at least if I understood
what you mean). This is because you need to have full definition
of
struct phy in board file and a structure that is used as private
data
in PHY core comes from platform code.
   
   You don't have to have a full definition in the board file.  Just a
   partial definition -- most of the contents can be filled in later,
   when
   the PHY driver is ready to store the private data.
   
   It's not a layering violation for one region of the kernel to store
   private data in a structure defined by another part of the kernel.
   This happens all the time (e.g., dev_set_drvdata).
  
  Not really. The phy struct is something that _is_ private data of PHY
  subsystem, not something that can store private data of PHY subsystem
  (sure it can store private data of particular PHY driver, but that's
  another story) and only PHY subsystem should have access to its
  contents.
 If you want to keep the phy struct completely separate from the board
 file, there's an easy way to do it.  Let's say the board file knows
 about N different PHYs in the system.  Then you define an array of N
 pointers to phys:
 
 struct phy *(phy_address[N]);
 
 In the platform data for both PHY j and its controller, store
 phy_address[j].  The PHY provider passes this cookie to phy_create:
 
   cookie = pdev-dev.platform_data;
   ret = phy_create(phy, cookie);
 
 and phy_create simply stores: *cookie = phy.  The PHY consumer does
 much the same the same thing:
 
   cookie = pdev-dev.platform_data;
   phy = phy_get(cookie);
 
 phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.

OK, this can work. Again, just technically, because it's rather ugly.

  By the way, we need to consider other cases here as well, for example
  it would be nice to have a single phy_get() function that works for
  both non- DT and DT cases to make the consumer driver not have to
  worry whether it's being probed from DT or not.
 
 You ought to be able to adapt this scheme to work with DT.  Maybe by
 having multiple phy_address arrays.

Where would you want to have those phy_address arrays stored? There are no 
board files when booting with DT. Not even saying that you don't need to 
use any hacky schemes like this when you have DT that nicely specifies 
relations between devices.

Anyway, board file should not be considered as a method to exchange data 
between drivers. It should be used only to pass data from it to drivers, 
not the other way. Ideally all data in a board file should be marked as 
const and __init and dropped after system initialization.

Best regards,
Tomasz

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
 On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
  On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
   On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
 You don't know the id of the device you are looking up, due to
 multiple devices being in the system (dynamic ids, look back
 earlier
 in
 this thread for details about that.)

I got copied in very late so don't have most of the thread I'm
afraid,
I did try looking at web archives but didn't see a clear problem
statement.  In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
   
   What do you mean by locally?
   
   The problem with the api was that the phy core wanted a id and a
   name to create a phy, and then later other code was doing a
   lookup based on the name and id (mushed together), because it
   knew that this device was the one it wanted.
   
   Just like the clock api, which, for multiple devices, has proven to
   cause problems.  I don't want to see us accept an api that we know
   has
   issues in it now, I'd rather us fix it up properly.
   
   Subsystems should be able to create ids how ever they want to, and
   not
   rely on the code calling them to specify the names of the devices
   that
   way, otherwise the api is just too fragile.
   
   I think, that if you create a device, then just carry around the
   pointer to that device (in this case a phy) and pass it to whatever
   other code needs it.  No need to do lookups on known names or
   anything else, just normal pointers, with no problems for multiple
   devices, busses, or naming issues.
  
  PHY object is not a device, it is something that a device driver
  creates (one or more instances of) when it is being probed.
 
 But you created a 'struct device' for it, so I think of it as a device
 be it virtual or real :)

Keep in mind that those virtual devices are created by PHY driver bound to 
a real device and one real device can have multiple virtual devices behind 
it.

  You don't have a clean way to export this PHY object to other driver,
  other than keeping this PHY on a list inside PHY core with some
  well-known ID (e.g. device name + consumer port name/index, like in
  regulator core) and then to use this well-known ID inside consumer
  driver as a lookup key passed to phy_get();
  
  Actually I think for PHY case, exactly the same way as used for
  regulators might be completely fine:
  
  1. Each PHY would have some kind of platform, non-unique name, that is
  just used to print some messages (like the platform/board name of a
  regulator).
  2. Each PHY would have an array of consumers. Consumer specifier would
  consist of consumer device name and consumer port name - just like in
  regulator subsystem.
  3. PHY driver receives an array of, let's say, phy_init_data inside
  its
  platform data that it would use to register its PHYs.
  4. Consumer drivers would have constant consumer port names and
  wouldn't receive any information about PHYs from platform code.
  
  Code example:
  
  [Board file]
  
  static const struct phy_consumer_data usb_20_phy0_consumers[] = {
  
  {
  
  .devname = foo-ehci,
  .port = usbphy,
  
  },
  
  };
  
  static const struct phy_consumer_data usb_20_phy1_consumers[] = {
  
  {
  
  .devname = foo-otg,
  .port = otgphy,
  
  },
  
  };
  
  static const struct phy_init_data my_phys[] = {
  
  {
  
  .name = USB 2.0 PHY 0,
  .consumers = usb_20_phy0_consumers,
  .num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
  
  },
  {
  
  .name = USB 2.0 PHY 1,
  .consumers = usb_20_phy1_consumers,
  .num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
  
  },
  { }
  
  };
  
  static const struct platform_device usb_phy_pdev = {
  
  .name = foo-usbphy,
  .id = -1,
  .dev = {
  
  .platform_data = my_phys,
  
  },
  
  };
  
  [PHY driver]
  
  static int foo_usbphy_probe(pdev)
  {
  
  struct foo_usbphy *foo;
  struct phy_init_data *init_data = pdev-dev.platform_data;
  /* ... */
  // for each PHY in init_data {
  
  phy_register(foo-phy[i], init_data[i]);
  
  // }
  /* ... */
  
  }
  
  [EHCI driver]
  
  static int foo_ehci_probe(pdev)
  {
  
  struct phy *phy;
  /* ... */
  phy = phy_get(pdev-dev, usbphy);
  /* ... */
  
  }
  
  [OTG driver]
  
  static int foo_otg_probe(pdev)
  {
  
  struct phy *phy;
  /* ... */
  phy = phy_get(pdev-dev, otgphy);
  /* ... */
  
  }
 
 That's not so bad, as long as you let the phy core use whatever name it
 wants for the device when it registers it with sysfs.

Yes, in regulator core

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-07-23 Thread Tomasz Figa
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
 On Tue, 23 Jul 2013, Tomasz Figa wrote:
   If you want to keep the phy struct completely separate from the
   board
   file, there's an easy way to do it.  Let's say the board file knows
   about N different PHYs in the system.  Then you define an array of N
   pointers to phys:
   
   struct phy *(phy_address[N]);
   
   In the platform data for both PHY j and its controller, store
   
   phy_address[j].  The PHY provider passes this cookie to phy_create:
 cookie = pdev-dev.platform_data;
 ret = phy_create(phy, cookie);
   
   and phy_create simply stores: *cookie = phy.  The PHY consumer does
   
   much the same the same thing:
 cookie = pdev-dev.platform_data;
 phy = phy_get(cookie);
   
   phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.
  
  OK, this can work. Again, just technically, because it's rather ugly.
 
 There's no reason the phy_address things have to be arrays.  A separate
 individual pointer for each PHY would work just as well.
 
  Where would you want to have those phy_address arrays stored? There
  are no board files when booting with DT. Not even saying that you
  don't need to use any hacky schemes like this when you have DT that
  nicely specifies relations between devices.
 
 If everybody agrees DT has a nice scheme for specifying relations
 between devices, why not use that same scheme in the PHY core?

It is already used, for cases when consumer device has a DT node attached. 
In non-DT case this kind lookup translates loosely to something that is 
being done in regulator framework - you can't bind devices by pointers, 
because you don't have those pointers, so you need to use device names.

  Anyway, board file should not be considered as a method to exchange
  data between drivers. It should be used only to pass data from it to
  drivers, not the other way. Ideally all data in a board file should
  be marked as const and __init and dropped after system
  initialization.
 
 The phy_address things don't have to be defined or allocated in the
 board file; they could be set up along with the platform data.

There is no platform data when booting with DT.

 In any case, this was simply meant to be a suggestion to show that it
 is relatively easy to do what you need without using name or ID
 strings.

Sure. It's good to have different options discussed as well.

Best regards,
Tomasz

--
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] drm/exynos: Add check for IOMMU while passing physically continous memory flag

2013-08-01 Thread Tomasz Figa
Hi Vikas,

On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
 While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
 connected with resolution 2560x1600, following error occured even with
 IOMMU enabled:
 [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
 buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
 
 This patch fixes the issue by adding a check for IOMMU.
 
 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 Signed-off-by: Arun Kumar arun...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 @@ -16,6 +16,7 @@
  #include drm/drm_crtc.h
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h
 +#include drm/exynos_drm.h
 
  #include exynos_drm_drv.h
  #include exynos_drm_fb.h
 @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
 drm_fb_helper *helper, struct platform_device *pdev = dev-platformdev;
   unsigned long size;
   int ret;
 + unsigned int flag;
 
   DRM_DEBUG_KMS(surface width(%d), height(%d) and bpp(%d\n,
   sizes-surface_width, sizes-surface_height,
 @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
 drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
 
   /* 0 means to allocate physically continuous memory */
 - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
 + if (!is_drm_iommu_supported(dev))
 + flag = 0;
 + else
 + flag = EXYNOS_BO_NONCONTIG;

While noncontig memory might be used for devices that support IOMMU, there 
should be no problem with using contig memory for them, so this seems more 
like masking the original problem rather than tracking it down.

Could you check why the allocation fails when requesting contiguous 
memory?

Best regards,
Tomasz

--
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] drm/exynos: Add check for IOMMU while passing physically continous memory flag

2013-08-02 Thread Tomasz Figa
Hi Vikas,

On Friday 02 of August 2013 12:08:52 Vikas Sajjan wrote:
 Hi Rob,
 
 On 2 August 2013 06:03, Rob Clark robdcl...@gmail.com wrote:
  On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com 
wrote:
  Hi Vikas,
  
  On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
  While trying to get boot-logo up on exynos5420 SMDK which has eDP
  panel
  connected with resolution 2560x1600, following error occured even
  with
  IOMMU enabled:
  [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
  buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor
  0
  
  This patch fixes the issue by adding a check for IOMMU.
  
  Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
  
   drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
   1 file changed, 8 insertions(+), 1 deletion(-)
[snip]
  @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
  drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
  
/* 0 means to allocate physically continuous memory */
  
  - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
  + if (!is_drm_iommu_supported(dev))
  + flag = 0;
  + else
  + flag = EXYNOS_BO_NONCONTIG;
  
  While noncontig memory might be used for devices that support IOMMU,
  there should be no problem with using contig memory for them, so
  this seems more like masking the original problem rather than
  tracking it down. 
  it is probably a good idea to not require contig memory when it is not
  needed for performance or functionality (and if it is only
  performance, then fallback gracefully to non-contig).. but yeah, would
  be good to know if this is masking another issue all the same
 
 Whats happening with CONTIG flag and with IOMMU,  is
 
  __iommu_alloc_buffer() --- dma_alloc_from_contiguous() and in this
 function it fails at
 this condition check  if (pageno = cma-count)
 
 So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
 succeeds and it works well without my patch.
 
 But what about the case where CONFIG_CMA is disabled , yet i want
 bigger memory for a device.
  I think using IOMMU we can achieve this.

  correct me, if i am wrong.

This is probably fine. I'm not sure about performance aspects of using 
noncontig memory as framebuffer, though. This needs to be checked and if 
there is some performance penalty, I would make noncontig allocation a 
fallback case, if contig fails, as Rob has suggested.

Also I think you should adjust the commit message to say that non-
contiguous memory can be used when IOMMU is supported, so there is no need 
to force contiguous allocations, since this is not a bug fix, but rather a 
feature this patch is adding.

Best regards,
Tomasz
 
  BR,
  -R
  
  Could you check why the allocation fails when requesting contiguous
  memory?
  
  Best regards,
  Tomasz
  
  --
  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
--
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 V2] drm/exynos: Add fallback option to get non physically continous memory for fb

2013-08-05 Thread Tomasz Figa
On Monday 05 of August 2013 15:14:42 Vikas Sajjan wrote:
 While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
 connected with resolution 2560x1600, following error occured even with
 IOMMU enabled:
 [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
 buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
 
 To address the case where physically continous memory MAY NOT be a
 mandatory requirement for fb, the patch adds a feature to get non
 physically continous memory for fb if IOMMU is supported and if CONTIG
 memory allocation fails.
 
 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 Signed-off-by: Arun Kumar arun...@samsung.com
 ---
 changes since v1:
- Modified to add the fallback patch if CONTIG alloc fails as suggested
 by Rob Clark robdcl...@gmail.com and Tomasz Figa
 tomasz.f...@gmail.com.
 
- changed the commit message.
 ---
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   19 +++
  1 file changed, 15 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..9a4b886
 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 @@ -16,6 +16,7 @@
  #include drm/drm_crtc.h
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h
 +#include drm/exynos_drm.h
 
  #include exynos_drm_drv.h
  #include exynos_drm_fb.h
 @@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct
 drm_fb_helper *helper,
 
   size = mode_cmd.pitches[0] * mode_cmd.height;
 
 - /* 0 means to allocate physically continuous memory */
 - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
 + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);

You can put the fallback here like this:
if (IS_ERR(exynos_gem_obj)  is_drm_iommu_supported(dev)) {
/*
 * If IOMMU is supported then try to get buffer from
 * non-continous memory area
 */
dev_warn(pdev-dev, contiguous FB allocation failed, falling 
back to non-contiguous\n);
exynos_gem_obj = exynos_drm_gem_create(dev,

EXYNOS_BO_NONCONTIG, size);
}

   if (IS_ERR(exynos_gem_obj)) {
 - ret = PTR_ERR(exynos_gem_obj);
 - goto err_release_framebuffer;

And then you can leave this original check untouched, reducing the
diffstat and unnecessary code indentation.

 + /*
 +  * If IOMMU is supported then try to get buffer from
 +  * non-continous memory area
 +  */
 + if (is_drm_iommu_supported(dev))
 + exynos_gem_obj = exynos_drm_gem_create(dev,
 + EXYNOS_BO_NONCONTIG, size);
 + if (IS_ERR(exynos_gem_obj)) {
 + ret = PTR_ERR(exynos_gem_obj);
 + goto err_release_framebuffer;
 + }
 + dev_warn(pdev-dev, exynos_gem_obj for FB is allocated with\n
 + non physically continuous memory\n);

Please don't split messages into multiple lines, because this makes
grepping for them harder (and checkpatch complains).

Best regards,
Tomasz

--
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 2/2] media: s5p-mfc: remove DT hacks and simplify initialization code

2013-08-06 Thread Tomasz Figa
Hi Kukjin,

On Wednesday 07 of August 2013 07:13:09 Kukjin Kim wrote:
 On 08/06/13 19:22, Kamil Debski wrote:
  Hi Kukjin,
  
  This patch looks good.
  
  Best wishes,
  Kamil Debski
  
  From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
  Sent: Monday, August 05, 2013 2:27 PM
  
  This patch removes custom initialization of reserved memory regions
  from s5p-mfc driver. Memory initialization can be now handled by
  generic code.
  
  Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
  
  Acked-by: Kamil Debskik.deb...@samsung.com
 
 Kamil, thanks for your ack.
 
 Applied.

This is a nice cleanup, but I don't think it should be applied yet, 
because it depends on patch 1/2, which needs an Ack from DT maintainers.

Best regards,
Tomasz

--
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 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

2013-08-08 Thread Tomasz Figa
Hi Stephen,

On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
 On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
  MFC driver use custom bindings for managing reserved memory. Those
  bindings are not really specific to MFC device and no even well
  discussed. They can be easily replaced with generic, platform
  independent code for handling reserved and contiguous memory.
  
  Two additional child devices for each memory port (AXI master) are
  introduced to let one assign some properties to each of them. Later
  one
  can also use them to assign properties related to SYSMMU controllers,
  which can be used to manage the limited dma window provided by those
  memory ports.
  
  diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
  b/Documentation/devicetree/bindings/media/s5p-mfc.txt
  
  +The MFC device is connected to system bus with two memory ports (AXI
  +masters) for better performance. Those memory ports are modelled as
  +separate child devices, so one can assign some properties to them
  (like +memory region for dma buffer allocation or sysmmu controller).
  +
  
   Required properties:
 - compatible : value should be either one among the following
  
  (a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs
  (b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs
  
  +   and additionally simple-bus to correctly initialize child
  +   devices for memory ports (AXI masters)
 
 simple-bus is wrong here; the child nodes aren't independent entities
 that can be instantiated separately from their parent and without
 depending on their parent.

I fully agree, but I can't think of anything better. Could you suggest a 
solution that would cover our use case:

The MFC IP has two separate bus masters (called here and there memports). 
On some SoCs, each master must use different memory bank to meet memory 
bandwidth requirements for higher bitrate video streams. This can be seen 
as MFC having two DMA subdevices, which have different DMA windows.

On Linux, this is handled by binding two appropriate CMA memory regions to 
the memports, so the driver can do DMA allocations on behalf of particular 
memport and get appropriate memory for it.

  -  - samsung,mfc-r : Base address of the first memory bank used by MFC
  -   for DMA contiguous memory allocation and its size.
  -
  -  - samsung,mfc-l : Base address of the second memory bank used by
  MFC
  -   for DMA contiguous memory allocation and its size.
 
 These properties shouldn't be removed, but simply marked deprecated. The
 driver will need to continue to support them so that old DTs work with
 new kernels. The binding must therefore continue to document them so
 that the old DT content still makes sense.

I tend to disagree on this. For Samsung platforms we've been trying to 
avoid DT bindings changes as much as possible, but I'd rather say that 
device tree was coupled with kernel version it came from, so Samsung-
specific bindings haven't been fully stabilized yet, especially since we 
are still at discussion stage when it's about defining processes for 
binding staging and stabilization.

I would rather see this patch as part of work on Samsung DT binding 
janitoring or maybe even sanitizing in some cases, like this one, when the 
old (and IMHO bad) MFC binding was introduced without proper review. I 
don't think we want to support this kind of brokenness anymore, especially 
considering the hacks which would be required by such support (see 
original implementation of this binding and code required in board file).

  +Two child nodes must be defined for MFC device. Their names must be
  +following: memport-r and memport-l (right and left). Required
 
 Node names shouldn't have semantic meaning.

What about bus-master-0 and bus-master-1?

  +properties:
  +  - compatible : value should be samsung,memport
 
 There's no need to define compatible properties for things which aren't
 separate devices.

I agree.

  +  - dma-memory-region : optional property with a phandle to
  respective memory + region (see 
devicetree/bindings/memory.txt), if
  no region
  +   is defined, sysmmu controller must be used for 
managing
  +   limited dma window of each memory port.
 
 What's the benefit of putting this property in a sub-node; surely you
 can put the property in the main MFC node yet follow the same conceptual
 schema for its content as a dma-memory-region node?

See my use case description above.

Best regards,
Tomasz

--
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 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code

2013-08-08 Thread Tomasz Figa
On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote:
 On 08/08/2013 03:19 PM, Tomasz Figa wrote:
  Hi Stephen,
  
  On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
  On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
  MFC driver use custom bindings for managing reserved memory. Those
  bindings are not really specific to MFC device and no even well
  discussed. They can be easily replaced with generic, platform
  independent code for handling reserved and contiguous memory.
  
  Two additional child devices for each memory port (AXI master) are
  introduced to let one assign some properties to each of them. Later
  one
  can also use them to assign properties related to SYSMMU
  controllers,
  which can be used to manage the limited dma window provided by those
  memory ports.
  
  diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
  b/Documentation/devicetree/bindings/media/s5p-mfc.txt
  
  +The MFC device is connected to system bus with two memory ports
  (AXI
  +masters) for better performance. Those memory ports are modelled as
  +separate child devices, so one can assign some properties to them
  (like +memory region for dma buffer allocation or sysmmu
  controller).
  +
  
   Required properties:
 - compatible : value should be either one among the following

(a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs
(b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs
  
  + and additionally simple-bus to correctly initialize child
  + devices for memory ports (AXI masters)
  
  simple-bus is wrong here; the child nodes aren't independent entities
  that can be instantiated separately from their parent and without
  depending on their parent.
  
  I fully agree, but I can't think of anything better. Could you suggest
  a solution that would cover our use case:
  
  The MFC IP has two separate bus masters (called here and there
  memports). On some SoCs, each master must use different memory bank
  to meet memory bandwidth requirements for higher bitrate video
  streams. This can be seen as MFC having two DMA subdevices, which
  have different DMA windows.
  
  On Linux, this is handled by binding two appropriate CMA memory
  regions to the memports, so the driver can do DMA allocations on
  behalf of particular memport and get appropriate memory for it.
 
 I don't see what that has to do with simple-bus.

Well, this is not the first binding doing things this way, unless I don't 
understand something. See the recently posted mvebu bindings. Using 
simple-bus for this has the nice property of allowing both non-DT and DT 
cases to be handled in exactly the same way in MFC driver.

 Whatever parses the
 node of the MFC can directly read from any contained property or child
 node; there's no need to try and get the core DT tree parser to
 enumerate the children.
 
 If you actually need a struct platform_device for each of these child
 nodes (which sounds wrong, but I'm not familiar with the code)

We need struct device for each memport and CMA region bound to both of 
them. This is a requirement of the Linux DMA mapping API, and well, it 
represents real hardware structure anyway.

 , then
 simply have the driver call of_platform_populate() itself at the
 appropriate time.

This sounds fine to me. 

 But that's not going to work well unless the child
 nodes have compatible values, which doesn't seem right given their
 purpose.
  -  - samsung,mfc-r : Base address of the first memory bank used by
  MFC
  - for DMA contiguous memory allocation and its size.
  -
  -  - samsung,mfc-l : Base address of the second memory bank used by
  MFC
  - for DMA contiguous memory allocation and its size.
  
  These properties shouldn't be removed, but simply marked deprecated.
  The driver will need to continue to support them so that old DTs
  work with new kernels. The binding must therefore continue to
  document them so that the old DT content still makes sense.
  
  I tend to disagree on this. For Samsung platforms we've been trying to
  avoid DT bindings changes as much as possible, but I'd rather say that
  device tree was coupled with kernel version it came from, so Samsung-
  specific bindings haven't been fully stabilized yet, especially since
  we are still at discussion stage when it's about defining processes
  for binding staging and stabilization.
 
 Well, that's why everyone is shouting at ARM for abusing DT...

IMHO this is not fully fair. We have a lot of development happenning on 
ARM. Things usually can't be done perfectly on first iteration, while we 
often want things working reasonably ASAP.

This is why I'm really all for staging/stable separation. I believe things 
need to be tested in practice before we say that they are good already and 
can't be redone, which is what this kind of process would allow.

  I would rather see this patch as part of work on Samsung DT binding
  janitoring or maybe even sanitizing in some cases

Re: [PATCH 01/15] drivers: phy: add generic PHY framework

2013-08-13 Thread Tomasz Figa
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
 Hi,
 
 On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
  Hi,
  
  On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
  IMHO we need a lookup method for PHYs, just like for clocks,
  regulators, PWMs or even i2c busses because there are complex
  cases
  when passing just a name using platform data will not work. I
  would
  second what Stephen said [1] and define a structure doing things
  in a
  DT-like way.
  
  Example;
  
  [platform code]
  
  static const struct phy_lookup my_phy_lookup[] = {
  
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
  
  The only problem here is that if *PLATFORM_DEVID_AUTO* is used
  while
  creating the device, the ids in the device name would change and
  PHY_LOOKUP wont be useful.
  
  I don't think this is a problem. All the existing lookup methods
  already
  use ID to identify devices (see regulators, clkdev, PWMs, i2c,
  ...). You
  can simply add a requirement that the ID must be assigned manually,
  without using PLATFORM_DEVID_AUTO to use PHY lookup.
  
  And I'm saying that this idea, of using a specific name and id, is
  frought with fragility and will break in the future in various ways
  when
  devices get added to systems, making these strings constantly have
  to be
  kept up to date with different board configurations.
  
  People, NEVER, hardcode something like an id.  The fact that this
  happens today with the clock code, doesn't make it right, it makes
  the
  clock code wrong.  Others have already said that this is wrong there
  as
  well, as systems change and dynamic ids get used more and more.
  
  Let's not repeat the same mistakes of the past just because we
  refuse to
  learn from them...
  
  So again, the find a phy by a string functions should be removed,
  the
  device id should be automatically created by the phy core just to
  make
  things unique in sysfs, and no driver code should _ever_ be reliant
  on
  the number that is being created, and the pointer to the phy
  structure
  should be used everywhere instead.
  
  With those types of changes, I will consider merging this subsystem,
  but
  without them, sorry, I will not.
  
  I'll agree with Greg here, the very fact that we see people trying to
  add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
  to a
  big problem in the framework.
  
  The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
  adding similar infrastructure to the driver themselves to make sure
  we
  don't end up with duplicate names in sysfs in case we have multiple
  instances of the same IP in the SoC (or several of the same PCIe
  card).
  I really don't want to go back to that.
  
  If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
  give the correct binding information to the PHY framework. I think we
  can drop having this non-dt support in PHY framework? I see only one
  platform (OMAP3) going to be needing this non-dt support and we can
  use the USB PHY library for it. 
  you shouldn't drop support for non-DT platform, in any case we lived
  without DT (and still do) for years. Gotta find a better way ;-)
 
 hmm..
 
 how about passing the device names of PHY in platform data of the
 controller? It should be deterministic as the PHY framework assigns its
 own id and we *don't* want to add any requirement that the ID must be
 assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
 *phy_init_data* in the v10 patch series.

What about slightly altering the concept of v9 to pass a pointer to struct 
device instead of device name inside phy_init_data?

Best regards,
Tomasz

--
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 01/15] drivers: phy: add generic PHY framework

2013-08-13 Thread Tomasz Figa
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
 W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
  On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
  On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
  On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
  On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I 
wrote:
  IMHO we need a lookup method for PHYs, just like for clocks,
  regulators, PWMs or even i2c busses because there are complex
  cases
  when passing just a name using platform data will not work. I
  would
  second what Stephen said [1] and define a structure doing
  things
  in a
  DT-like way.
  
  Example;
  
  [platform code]
  
  static const struct phy_lookup my_phy_lookup[] = {
  
 PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
 phy.2),
  
  The only problem here is that if *PLATFORM_DEVID_AUTO* is used
  while
  creating the device, the ids in the device name would change
  and
  PHY_LOOKUP wont be useful.
  
  I don't think this is a problem. All the existing lookup
  methods
  already
  use ID to identify devices (see regulators, clkdev, PWMs, i2c,
  ...). You
  can simply add a requirement that the ID must be assigned
  manually,
  without using PLATFORM_DEVID_AUTO to use PHY lookup.
  
  And I'm saying that this idea, of using a specific name and id,
  is
  frought with fragility and will break in the future in various
  ways
  when
  devices get added to systems, making these strings constantly
  have
  to be
  kept up to date with different board configurations.
  
  People, NEVER, hardcode something like an id.  The fact that
  this
  happens today with the clock code, doesn't make it right, it
  makes
  the
  clock code wrong.  Others have already said that this is wrong
  there
  as
  well, as systems change and dynamic ids get used more and more.
  
  Let's not repeat the same mistakes of the past just because we
  refuse to
  learn from them...
  
  So again, the find a phy by a string functions should be
  removed,
  the
  device id should be automatically created by the phy core just
  to
  make
  things unique in sysfs, and no driver code should _ever_ be
  reliant
  on
  the number that is being created, and the pointer to the phy
  structure
  should be used everywhere instead.
  
  With those types of changes, I will consider merging this
  subsystem,
  but
  without them, sorry, I will not.
  
  I'll agree with Greg here, the very fact that we see people
  trying to
  add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
  points
  to a big problem in the framework.
  
  The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
  end up
  adding similar infrastructure to the driver themselves to make
  sure
  we
  don't end up with duplicate names in sysfs in case we have
  multiple
  instances of the same IP in the SoC (or several of the same PCIe
  card).
  I really don't want to go back to that.
  
  If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
  can
  give the correct binding information to the PHY framework. I think
  we
  can drop having this non-dt support in PHY framework? I see only
  one
  platform (OMAP3) going to be needing this non-dt support and we
  can
  use the USB PHY library for it.
  
  you shouldn't drop support for non-DT platform, in any case we
  lived
  without DT (and still do) for years. Gotta find a better way ;-)
  
  hmm..
  
  how about passing the device names of PHY in platform data of the
  controller? It should be deterministic as the PHY framework assigns
  its
  own id and we *don't* want to add any requirement that the ID must
  be
  assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
  of
  *phy_init_data* in the v10 patch series.
 
 OK, so the PHY device name would have a fixed part, passed as
 platform data of the controller and a variable part appended
 by the PHY core, depending on the number of registered PHYs ?
 
 Then same PHY names would be passed as the PHY provider driver's
 platform data ?
 
 Then if there are 2 instances of the above (same names in platform
 data) how would be determined which PHY controller is linked to
 which PHY supplier ?
 
 I guess you want each device instance to have different PHY device
 names already in platform data ? That might work. We probably will
 be focused mostly on DT anyway. It seem without DT we are trying
 to find some layer that would allow us to couple relevant devices
 and overcome driver core inconvenience that it provides to means
 to identify specific devices in advance. :) Your proposal sounds
 reasonable, however I might be missing some details or corner cases.
 
  What about slightly altering the concept of v9 to pass a pointer to
  struct device instead of device name inside phy_init_data?
 
 As Felipe said, we don't want to pass pointers in platform_data
 to/from random subsystems. We pass data, passing pointers would
 be a total mess IMHO.

Well

Re: [PATCH RFC v5] s5k5baf: add camera sensor driver

2013-08-19 Thread Tomasz Figa
On Monday 19 of August 2013 16:30:45 Stephen Warren wrote:
 On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote:
  On 08/19/2013 03:25 PM, Pawel Moll wrote:
  On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote:
  +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
  @@ -0,0 +1,51 @@
  +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC
  ISP
  +-
  +
  +Required properties:
  +
  +- compatible : samsung,s5k5baf;
  +- reg: I2C slave address of the sensor;
  +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V);
  +- vddreg-supply  : regulator input power supply 1.8V (1.7V
  to 1.9V) +or 2.8V (2.6V to 3.0);
  +- vddio-supply   : I/O power supply 1.8V (1.65V to 1.95V)
  +or 2.8V (2.5V to 3.1V);
  +- gpios  : GPIOs connected to STDBYN and RSTN pins,
  +in order: STBYN, RSTN;
  
  You probably want to use the [name-]gpios convention here (see
  Documentation/devicetree/bindings/gpio/gpio.txt), so something like
  stbyn-gpios and rstn-gpios.
  
  Unless using multiple named properties is really preferred over a
  single gpios property I would like to keep the single property
  containing a list of GPIOs. ...
 
 Yes, a separate property for each type of GPIO is typical. Multiple
 entries in the same property are allowed if they're used for the same
 purpose/type, whereas here they're clearly different things.
 Inconsistent with (some) other properties, admittedly...

I'm not really convinced about the superiority of named gpio properties 
over a single gpios property with multiple entries in this case. I'd say 
it's more just a matter of preference.

See the clock or interrupt bindings. They all specify all the clocks and 
interrupts in single property, without any differentiation based on their 
purposes. Also keep in mind that original GPIO bindings used only a single 
gpios property and was only extended to allow named ones.

Best regards,
Tomasz

--
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 v7 13/13] V4L: Add driver for s5k4e5 image sensor

2013-08-21 Thread Tomasz Figa
Hi Hans,

On Wednesday 21 of August 2013 08:53:55 Hans Verkuil wrote:
 On 08/21/2013 08:34 AM, Arun Kumar K wrote:
  This patch adds subdev driver for Samsung S5K4E5 raw image sensor.
  Like s5k6a3, it is also another fimc-is firmware controlled
  sensor. This minimal sensor driver doesn't do any I2C communications
  as its done by ISP firmware. It can be updated if needed to a
  regular sensor driver by adding the I2C communication.
  
  Signed-off-by: Arun Kumar K arun...@samsung.com
  Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
  ---
  
   .../devicetree/bindings/media/i2c/s5k4e5.txt   |   43 +++
   drivers/media/i2c/Kconfig  |8 +
   drivers/media/i2c/Makefile |1 +
   drivers/media/i2c/s5k4e5.c |  361
    4 files changed, 413 insertions(+)
   create mode 100644
   Documentation/devicetree/bindings/media/i2c/s5k4e5.txt create mode
   100644 drivers/media/i2c/s5k4e5.c
 
 ...
 
  diff --git a/drivers/media/i2c/s5k4e5.c b/drivers/media/i2c/s5k4e5.c
  new file mode 100644
  index 000..0a6ece6
  --- /dev/null
  +++ b/drivers/media/i2c/s5k4e5.c
  @@ -0,0 +1,361 @@
  +/*
  + * Samsung S5K4E5 image sensor driver
  + *
  + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
  + * Author: Arun Kumar K arun...@samsung.com
  + *
  + * This program is free software; you can redistribute it and/or
  modify + * it under the terms of the GNU General Public License
  version 2 as + * published by the Free Software Foundation.
  + */
  +
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/device.h
  +#include linux/errno.h
  +#include linux/gpio.h
  +#include linux/i2c.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/of_gpio.h
  +#include linux/pm_runtime.h
  +#include linux/regulator/consumer.h
  +#include linux/slab.h
  +#include linux/videodev2.h
  +#include media/v4l2-async.h
  +#include media/v4l2-subdev.h
  +
  +#define S5K4E5_SENSOR_MAX_WIDTH2576
  +#define S5K4E5_SENSOR_MAX_HEIGHT   1930
  +
  +#define S5K4E5_SENSOR_ACTIVE_WIDTH 2560
  +#define S5K4E5_SENSOR_ACTIVE_HEIGHT1920
  +
  +#define S5K4E5_SENSOR_MIN_WIDTH(32 + 16)
  +#define S5K4E5_SENSOR_MIN_HEIGHT   (32 + 10)
  +
  +#define S5K4E5_DEF_WIDTH   1296
  +#define S5K4E5_DEF_HEIGHT  732
  +
  +#define S5K4E5_DRV_NAMES5K4E5
  +#define S5K4E5_CLK_NAMEmclk
  +
  +#define S5K4E5_NUM_SUPPLIES2
  +
  +#define S5K4E5_DEF_CLK_FREQ2400
  +
  +/**
  + * struct s5k4e5 - s5k4e5 sensor data structure
  + * @dev: pointer to this I2C client device structure
  + * @subdev: the image sensor's v4l2 subdev
  + * @pad: subdev media source pad
  + * @supplies: image sensor's voltage regulator supplies
  + * @gpio_reset: GPIO connected to the sensor's reset pin
  + * @lock: mutex protecting the structure's members below
  + * @format: media bus format at the sensor's source pad
  + */
  +struct s5k4e5 {
  +   struct device *dev;
  +   struct v4l2_subdev subdev;
  +   struct media_pad pad;
  +   struct regulator_bulk_data supplies[S5K4E5_NUM_SUPPLIES];
  +   int gpio_reset;
  +   struct mutex lock;
  +   struct v4l2_mbus_framefmt format;
  +   struct clk *clock;
  +   u32 clock_frequency;
  +};
  +
  +static const char * const s5k4e5_supply_names[] = {
  +   svdda,
  +   svddio
  +};
 
 I'm no regulator expert, but shouldn't this list come from the DT or
 platform_data? Or are these names specific to this sensor?

This is a list of regulator input (aka supply) names. In other words those 
are usually names of pins of the consumer device (s5k4e5 chip in this 
case) to which the regulators are connected. They are used as lookup keys 
when looking up regulators, either from device tree or lookup tables.

Best regards,
Tomasz

--
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 v7] s5k5baf: add camera sensor driver

2013-08-22 Thread Tomasz Figa
Hi Andrzej,

Please see some minor comments inline.

On Wednesday 21 of August 2013 16:41:31 Andrzej Hajda wrote:
 Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor
 with embedded SoC ISP.
 The driver exposes the sensor as two V4L2 subdevices:
 - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
   no controls.
 - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
   pre/post ISP cropping, downscaling via selection API, controls.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 Hi,
 
 This patch incorporates Stephen's suggestions, thanks.
 
 Regards
 Andrzej
 
 v7
 - changed description of 'clock-frequency' DT property
 
 v6
 - endpoint node presence is now optional,
 - added asynchronous subdev registration support and clock
   handling,
 - use named gpios in DT bindings
 
 v5
 - removed hflip/vflip device tree properties
 
 v4
 - GPL changed to GPLv2,
 - bitfields replaced by u8,
 - cosmetic changes,
 - corrected s_stream flow,
 - gpio pins are no longer exported,
 - added I2C addresses to subdev names,
 - CIS subdev registration postponed after
   succesfull HW initialization,
 - added enums for pads,
 - selections are initialized only during probe,
 - default resolution changed to 1600x1200,
 - state-error pattern removed from few other functions,
 - entity link creation moved to registered callback.
 
 v3:
 - narrowed state-error usage to i2c and power errors,
 - private gain controls replaced by red/blue balance user controls,
 - added checks to devicetree gpio node parsing
 
 v2:
 - lower-cased driver name,
 - removed underscore from regulator names,
 - removed platform data code,
 - v4l controls grouped in anonymous structs,
 - added s5k5baf_clear_error function,
 - private controls definitions moved to uapi header file,
 - added v4l2-controls.h reservation for private controls,
 - corrected subdev registered/unregistered code,
 - .log_status sudbev op set to v4l2 helper,
 - moved entity link creation to probe routines,
 - added cleanup on error to probe function.
 ---
  .../devicetree/bindings/media/samsung-s5k5baf.txt  |   59 +
  MAINTAINERS|7 +
  drivers/media/i2c/Kconfig  |7 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/s5k5baf.c| 2045
  5 files changed, 2119 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/media/samsung-s5k5baf.txt create mode
 100644 drivers/media/i2c/s5k5baf.c
 
 diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
 b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt new file
 mode 100644
 index 000..d680d99
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
 @@ -0,0 +1,59 @@
 +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP
 +
 +
 +Required properties:
 +
 +- compatible   : samsung,s5k5baf;
 +- reg  : I2C slave address of the sensor;

Can this sensor have an aribitrary slave address or only a set of well 
known possible addresses (e.g. listed in documentation)?

 +- vdda-supply  : analog power supply 2.8V (2.6V to 3.0V);
 +- vddreg-supply: regulator input power supply 1.8V (1.7V to 
1.9V)
 + or 2.8V (2.6V to 3.0);
 +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V)
 + or 2.8V (2.5V to 3.1V);
 +- stbyn-gpios  : GPIO connected to STDBYN pin;
 +- rstn-gpios   : GPIO connected to RSTN pin;

Both GPIOs above have names suggesting that they are active low. I wonder 
how the GPIO flags cell is interpreted here, namely the polarity bit.

Otherwise the binding looks good.

Best regards,
Tomasz

--
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 v3 1/6] media: s5p-tv: Replace mxr_ macro by default dev_

2013-08-29 Thread Tomasz Figa
Hi Mateusz,

On Wednesday 28 of August 2013 18:12:59 Mateusz Krawczuk wrote:
 Replace mxr_dbg, mxr_info and mxr_warn by generic solution.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.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(-)

Although, this is a valid patch, I don't think it is related by any way to 
migration of S5PV210 to common clock framework. So, IMHO, this patch should 
be send separately, not as a part of this series.

Best regards,
Tomasz

--
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 v3 2/6] media: s5p-tv: Restore vpll clock rate

2013-08-29 Thread Tomasz Figa
Hi Mateusz,

Generally this patch looks good, but I have some minor nitpicks, that I 
would like to be fixed.

On Wednesday 28 of August 2013 18:13:00 Mateusz Krawczuk wrote:
 Restore vpll clock rate if start stream fail or stream is off.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 ---
  drivers/media/platform/s5p-tv/sdo_drv.c | 24 ++--
  1 file changed, 22 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
 b/drivers/media/platform/s5p-tv/sdo_drv.c index 0afa90f..9dbdfe6 100644
 --- a/drivers/media/platform/s5p-tv/sdo_drv.c
 +++ b/drivers/media/platform/s5p-tv/sdo_drv.c
 @@ -55,6 +55,8 @@ struct sdo_device {
   struct clk *dacphy;
   /** clock for control of VPLL */
   struct clk *fout_vpll;
 + /** vpll rate before sdo stream was on */
 + int vpll_rate;

Clock frequency should be stored in an unsigned long. (See the return type 
of clk_get_rate().)

   /** regulator for SDO IP power */
   struct regulator *vdac;
   /** regulator for SDO plug detection */
 @@ -193,17 +195,34 @@ static int sdo_s_power(struct v4l2_subdev *sd, int
 on)
 
  static int sdo_streamon(struct sdo_device *sdev)
  {
 + int ret;
 +
   /* set proper clock for Timing Generator */
 - clk_set_rate(sdev-fout_vpll, 5400);
 + sdev-vpll_rate = clk_get_rate(sdev-fout_vpll);
 + ret = clk_set_rate(sdev-fout_vpll, 5400);
 + if (ret  0) {
 + dev_err(sdev-dev,
 + Failed to set vpll rate!\n);
 + return ret;
 + }
   dev_info(sdev-dev, fout_vpll.rate = %lu\n,
   clk_get_rate(sdev-fout_vpll));
   /* enable clock in SDO */
   sdo_write_mask(sdev, SDO_CLKCON, ~0, SDO_TVOUT_CLOCK_ON);
 - clk_enable(sdev-dacphy);
 + ret = clk_enable(sdev-dacphy);
 + if (ret  0) {
 + dev_err(sdev-dev,
 + clk_enable(dacphy) failed !\n);
 + goto fail;
 + }
   /* enable DAC */
   sdo_write_mask(sdev, SDO_DAC, ~0, SDO_POWER_ON_DAC);
   sdo_reg_debug(sdev);
   return 0;

nit: Please insert a blank line here.

Best regards,
Tomasz

 +fail:
 + sdo_write_mask(sdev, SDO_CLKCON, 0, SDO_TVOUT_CLOCK_ON);
 + clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
 + return ret;
  }
 
  static int sdo_streamoff(struct sdo_device *sdev)
 @@ -220,6 +239,7 @@ static int sdo_streamoff(struct sdo_device *sdev)
   }
   if (tries == 0)
   dev_err(sdev-dev, failed to stop streaming\n);
 + clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
   return tries ? 0 : -EIO;
  }

--
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 v3 3/6] media: s5p-tv: Fix sdo driver to work with CCF

2013-08-29 Thread Tomasz Figa
Hi Mateusz,

On Wednesday 28 of August 2013 18:13:01 Mateusz Krawczuk wrote:
 Replace clk_enable by clock_enable_prepare and clk_disable with
 clk_disable_unprepare. Clock prepare is required by Clock Common
 Framework, and old clock driver didn`t support it. Without it Common
 Clock Framework prints a warning.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 ---
  drivers/media/platform/s5p-tv/sdo_drv.c | 25 +++--
  1 file changed, 15 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
 b/drivers/media/platform/s5p-tv/sdo_drv.c index 9dbdfe6..a79e620 100644
 --- a/drivers/media/platform/s5p-tv/sdo_drv.c
 +++ b/drivers/media/platform/s5p-tv/sdo_drv.c
 @@ -209,10 +209,10 @@ static int sdo_streamon(struct sdo_device *sdev)
   clk_get_rate(sdev-fout_vpll));
   /* enable clock in SDO */
   sdo_write_mask(sdev, SDO_CLKCON, ~0, SDO_TVOUT_CLOCK_ON);
 - ret = clk_enable(sdev-dacphy);
 + ret = clk_prepare_enable(sdev-dacphy);
   if (ret  0) {
   dev_err(sdev-dev,
 - clk_enable(dacphy) failed !\n);
 + clk_prepare_enable(dacphy) failed !\n);

nit: I haven't noticed this when reviewing previous patch, but please tone 
down those errors messages a bit, by removing the exclamation mark (and the 
space before it). We shouldn't be shouting at users. ;)

   goto fail;
   }
   /* enable DAC */
 @@ -230,7 +230,7 @@ static int sdo_streamoff(struct sdo_device *sdev)
   int tries;
 
   sdo_write_mask(sdev, SDO_DAC, 0, SDO_POWER_ON_DAC);
 - clk_disable(sdev-dacphy);
 + clk_disable_unprepare(sdev-dacphy);
   sdo_write_mask(sdev, SDO_CLKCON, 0, SDO_TVOUT_CLOCK_ON);
   for (tries = 100; tries; --tries) {
   if (sdo_read(sdev, SDO_CLKCON)  SDO_TVOUT_CLOCK_READY)
 @@ -274,7 +274,7 @@ static int sdo_runtime_suspend(struct device *dev)
   dev_info(dev, suspend\n);
   regulator_disable(sdev-vdet);
   regulator_disable(sdev-vdac);
 - clk_disable(sdev-sclk_dac);
 + clk_disable_unprepare(sdev-sclk_dac);
   return 0;
  }
 
 @@ -286,7 +286,7 @@ static int sdo_runtime_resume(struct device *dev)
 
   dev_info(dev, resume\n);
 
 - ret = clk_enable(sdev-sclk_dac);
 + ret = clk_prepare_enable(sdev-sclk_dac);
   if (ret  0)
   return ret;
 
 @@ -319,7 +319,7 @@ static int sdo_runtime_resume(struct device *dev)
  vdac_r_dis:
   regulator_disable(sdev-vdac);
  dac_clk_dis:
 - clk_disable(sdev-sclk_dac);
 + clk_disable_unprepare(sdev-sclk_dac);
   return ret;
  }
 
 @@ -333,7 +333,7 @@ static int sdo_probe(struct platform_device *pdev)
   struct device *dev = pdev-dev;
   struct sdo_device *sdev;
   struct resource *res;
 - int ret = 0;
 + int ret;

Hmm, this change doesn't look like belonging to this patch.

   struct clk *sclk_vpll;
 
   dev_info(dev, probe start\n);
 @@ -425,8 +425,13 @@ static int sdo_probe(struct platform_device *pdev)
   }
 
   /* enable gate for dac clock, because mixer uses it */
 - clk_enable(sdev-dac);
 -
 + ret = clk_prepare_enable(sdev-dac);
 + if (ret  0) {
 + dev_err(dev,
 + clk_prepare_enable_enable(dac) failed !\n);
 + ret = PTR_ERR(sdev-dac);

Hmm, ret already contains the error value returned by clk_prepare_enable() 
here, so this looks like a copy paste error.

Best regards,
Tomasz

 + goto fail_fout_vpll;
 + }
   /* configure power management */
   pm_runtime_enable(dev);
 
 @@ -464,7 +469,7 @@ static int sdo_remove(struct platform_device *pdev)
   struct sdo_device *sdev = sd_to_sdev(sd);
 
   pm_runtime_disable(pdev-dev);
 - clk_disable(sdev-dac);
 + clk_disable_unprepare(sdev-dac);
   clk_put(sdev-fout_vpll);
   clk_put(sdev-dacphy);
   clk_put(sdev-dac);

--
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 v3 4/6] media: s5p-tv: Fix mixer driver to work with CCF

2013-08-29 Thread Tomasz Figa
On Wednesday 28 of August 2013 18:13:02 Mateusz Krawczuk wrote:
 Replace clk_enable by clock_enable_prepare and clk_disable with
 clk_disable_unprepare. Clock prepare is required by Clock Common
 Framework, and old clock driver didn`t support it. Without it Common
 Clock Framework prints a warning.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 ---
  drivers/media/platform/s5p-tv/mixer_drv.c | 35
 --- 1 file changed, 28 insertions(+), 7
 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c
 b/drivers/media/platform/s5p-tv/mixer_drv.c index 8ce7c3e..3b2b305
 100644
 --- a/drivers/media/platform/s5p-tv/mixer_drv.c
 +++ b/drivers/media/platform/s5p-tv/mixer_drv.c
 @@ -347,19 +347,40 @@ static int mxr_runtime_resume(struct device *dev)
  {
   struct mxr_device *mdev = to_mdev(dev);
   struct mxr_resources *res = mdev-res;
 + int ret;
 
   dev_dbg(mdev-dev, resume - start\n);
   mutex_lock(mdev-mutex);
   /* turn clocks on */
 - clk_enable(res-mixer);
 - clk_enable(res-vp);
 - clk_enable(res-sclk_mixer);
 + ret = clk_prepare_enable(res-mixer);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(mixer) failed\n);
 + goto fail;
 + }
 + ret = clk_prepare_enable(res-vp);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(vp) failed\n);
 + goto fail_mixer;
 + }
 + ret = clk_prepare_enable(res-sclk_mixer);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(sclk_mixer) failed\n);
 + goto fail_vp;
 + }
   /* apply default configuration */
   mxr_reg_reset(mdev);
 - dev_dbg(mdev-dev, resume - finished\n);
 
   mutex_unlock(mdev-mutex);
 + dev_dbg(mdev-dev, resume - finished\n);

Why is this line moved in this patch?

   return 0;

nit: A blank line would look good here.

 +fail_vp:
 + clk_disable_unprepare(res-vp);
 +fail_mixer:
 + clk_disable_unprepare(res-mixer);
 +fail:
 + mutex_unlock(mdev-mutex);
 + dev_info(mdev-dev, resume failed\n);

dev_err?

Best regards,
Tomasz

 + return ret;
  }
 
  static int mxr_runtime_suspend(struct device *dev)
 @@ -369,9 +390,9 @@ static int mxr_runtime_suspend(struct device *dev)
   dev_dbg(mdev-dev, suspend - start\n);
   mutex_lock(mdev-mutex);
   /* turn clocks off */
 - clk_disable(res-sclk_mixer);
 - clk_disable(res-vp);
 - clk_disable(res-mixer);
 + clk_disable_unprepare(res-sclk_mixer);
 + clk_disable_unprepare(res-vp);
 + clk_disable_unprepare(res-mixer);
   mutex_unlock(mdev-mutex);
   dev_dbg(mdev-dev, suspend - finished\n);
   return 0;

--
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 v3 5/6] clk: samsung: Add clock driver for s5pc110/s5pv210

2013-08-29 Thread Tomasz Figa
Hi Mateusz,

On Wednesday 28 of August 2013 18:13:03 Mateusz Krawczuk wrote:
 This patch adds new, Common Clock Framework-based clock driver for
 Samsung S5PV210 SoCs. The driver is just added, without enabling it yet.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 ---
  .../bindings/clock/samsung,s5pv210-clock.txt   |  72 ++
  drivers/clk/samsung/Makefile   |   3 +
  drivers/clk/samsung/clk-s5pv210.c  | 732
 + include/dt-bindings/clock/samsung,s5pv210-clock.h 
 | 221 +++ 4 files changed, 1028 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt create
 mode 100644 drivers/clk/samsung/clk-s5pv210.c
  create mode 100644 include/dt-bindings/clock/samsung,s5pv210-clock.h
 
 diff --git
 a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt
 b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt new
 file mode 100644
 index 000..753c8f9
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt
 @@ -0,0 +1,72 @@
 +* Samsung S5PC110/S5PV210 Clock Controller
 +
 +The S5PV210 clock controller generates and supplies clock to various
 controllers +within the SoC. The clock binding described here is
 applicable to all SoCs in +the S5PC110/S5PV210 family.
 +
 +Required Properties:
 +
 +- compatible: should be one of the following.
 +  - samsung,s5pv210-clock - controller compatible with S5PC110/S5PV210
 SoC. +
 +- reg: physical base address of the controller and length of memory
 mapped +  region.
 +
 +- #clock-cells: should be 1.
 +
 +Each clock is assigned an identifier and client nodes can use this
 identifier +to specify the clock which they consume. Some of the clocks
 are available only +on a particular S5PC110/S5PV210 SoC and this is
 specified where applicable. +
 +All available clocks are defined as preprocessor macros in
 +dt-bindings/clock/samsung,s5pv210-clock.h header and can be used in
 device +tree sources.
 +
 +External clocks:
 +
 +There are several clocks that are generated outside the SoC. It is
 expected +that they are defined using standard clock bindings with
 following +clock-output-names:
 + - xxti- xtal - required
 + - xusbxti - USB xtal - required,

Hmm, I'm not sure if all the boards must always provide both of them. 
Actually it looks like the correct statement here would be At least one of 
the above clocks should be specified..

 +
 +
 +Example: Clock controller node:
 +
 + clock: clock-controller@7e00f000 {
 + compatible = samsung,s5pv210-clock;
 + reg = 0x7e00f000 0x1000;
 + #clock-cells = 1;
 + };
 +
 +Example: Required external clocks:
 +
 + fin_pll: clock-xxti {
 + compatible = fixed-clock;
 + clock-output-names = xxti;
 + clock-frequency = 1200;
 + #clock-cells = 0;
 + };
 +
 + xusbxti: clock-xusbxti {
 + compatible = fixed-clock;
 + clock-output-names = xusbxti;
 + clock-frequency = 4800;
 + #clock-cells = 0;
 + };
 +
 +Example: UART controller node that consumes the clock generated by the
 clock +  controller (refer to the standard clock bindings for
 information about +  clocks and clock-names properties):
 +
 + uart0: serial@7f005000 {
 + compatible = samsung,s5pv210-uart;
 + reg = 0x7f005000 0x100;
 + interrupt-parent = vic1;
 + interrupts = 5;
 + clock-names = uart, clk_uart_baud2,
 + clk_uart_baud3;
 + clocks = clock PCLK_UART0, clocks PCLK_UART0,
 + clock SCLK_UART;
 + status = disabled;
 + };
 \ No newline at end of file
 diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
 index 8eb4799..e08c45e 100644
 --- a/drivers/clk/samsung/Makefile
 +++ b/drivers/clk/samsung/Makefile
 @@ -9,3 +9,6 @@ obj-$(CONFIG_SOC_EXYNOS5420)  += clk-exynos5420.o
  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
  obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
  obj-$(CONFIG_ARCH_S3C64XX)   += clk-s3c64xx.o
 +ifeq ($(CONFIG_COMMON_CLK), y)
 +obj-$(CONFIG_ARCH_S5PV210)   += clk-s5pv210.o
 +endif
 \ No newline at end of file
 diff --git a/drivers/clk/samsung/clk-s5pv210.c
 b/drivers/clk/samsung/clk-s5pv210.c new file mode 100644
 index 000..1c5ea5c
 --- /dev/null
 +++ b/drivers/clk/samsung/clk-s5pv210.c
 @@ -0,0 +1,732 @@
 +/*
 + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
 + * Author: Mateusz Krawczuk m.krawc...@partner.samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * Common Clock Framework support for all 

Re: [PATCH v3 6/6] ARM: s5pv210: Migrate clock handling to Common Clock Framework

2013-08-29 Thread Tomasz Figa
Hi Mateusz,

On Wednesday 28 of August 2013 18:13:04 Mateusz Krawczuk wrote:
 This patch migrates the s5pv210 platform to use new clock driver
 using Common Clock Framework.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 ---
  arch/arm/mach-s5pv210/Kconfig |  9 +
  arch/arm/mach-s5pv210/Makefile|  4 ++--
  arch/arm/mach-s5pv210/common.c| 17 +
  arch/arm/mach-s5pv210/common.h| 13 +
  arch/arm/mach-s5pv210/mach-aquila.c   |  1 +
  arch/arm/mach-s5pv210/mach-goni.c |  3 ++-
  arch/arm/mach-s5pv210/mach-smdkc110.c |  1 +
  arch/arm/mach-s5pv210/mach-smdkv210.c |  1 +
  arch/arm/mach-s5pv210/mach-torbreck.c |  1 +
  arch/arm/plat-samsung/Kconfig |  2 +-
  arch/arm/plat-samsung/init.c  |  2 --
  11 files changed, 48 insertions(+), 6 deletions(-)
 
 diff --git a/arch/arm/mach-s5pv210/Kconfig
 b/arch/arm/mach-s5pv210/Kconfig index caaedaf..ad4546e 100644
 --- a/arch/arm/mach-s5pv210/Kconfig
 +++ b/arch/arm/mach-s5pv210/Kconfig
 @@ -15,6 +15,7 @@ config CPU_S5PV210
   select S5P_PM if PM
   select S5P_SLEEP if PM
   select SAMSUNG_DMADEV
 + select S5P_CLOCK if !COMMON_CLK
   help
 Enable S5PV210 CPU support
 
 @@ -69,6 +70,14 @@ config S5PV210_SETUP_USB_PHY
   help
 Common setup code for USB PHY controller
 
 +config COMMON_CLK_S5PV210
 + bool Common Clock Framework support
 + default y
 + select COMMON_CLK
 + help
 +   Enable this option to use new clock driver
 +   based on Common Clock Framework.
 +
  menu S5PC110 Machines
 
  config MACH_AQUILA
 diff --git a/arch/arm/mach-s5pv210/Makefile
 b/arch/arm/mach-s5pv210/Makefile index 1c4e419..0c67fe2 100644
 --- a/arch/arm/mach-s5pv210/Makefile
 +++ b/arch/arm/mach-s5pv210/Makefile
 @@ -12,8 +12,8 @@ obj-:=
 
  # Core
 
 -obj-y+= common.o clock.o
 -
 +obj-y+= common.o
 +obj-$(CONFIG_S5P_CLOCK)  += clock.o
  obj-$(CONFIG_PM) += pm.o
 
  obj-y+= dma.o
 diff --git a/arch/arm/mach-s5pv210/common.c
 b/arch/arm/mach-s5pv210/common.c index 26027a2..a1d86a1 100644
 --- a/arch/arm/mach-s5pv210/common.c
 +++ b/arch/arm/mach-s5pv210/common.c
 @@ -34,7 +34,13 @@
  #include mach/regs-clock.h
 
  #include plat/cpu.h
 +
 +#ifdef CONFIG_S5P_CLOCK
  #include plat/clock.h
 +#else
 +#include linux/clk-provider.h
 +#endif
 +
  #include plat/devs.h
  #include plat/sdhci.h
  #include plat/adc-core.h
 @@ -50,6 +56,14 @@
 
  #include common.h
 
 +/* External clock frequency */
 +static unsigned long xusbxti_f, xxti_f;

If the xxti_f variable is not being changed anywhere, it might be a good 
idea to drop it completely and pass a constant zero to s5pv210_clk_init().

 +
 +void __init s5pv210_set_xusbxti_freq(unsigned long freq)
 +{
 + xusbxti_f = freq;
 +}
 +
  static const char name_s5pv210[] = S5PV210/S5PC110;
 
  static struct cpu_table cpu_ids[] __initdata = {
 @@ -229,12 +243,14 @@ void __init s5pv210_map_io(void)
 
  void __init s5pv210_init_clocks(int xtal)
  {
 +#ifdef CONFIG_S5P_CLOCK
   printk(KERN_DEBUG %s: initializing clocks\n, __func__);
 
   s3c24xx_register_baseclocks(xtal);
   s5p_register_clocks(xtal);
   s5pv210_register_clocks();
   s5pv210_setup_clocks();
 +#endif
  }
 
  void __init s5pv210_init_irq(void)
 @@ -248,6 +264,7 @@ void __init s5pv210_init_irq(void)
   vic[3] = ~0;
 
   s5p_init_irq(vic, ARRAY_SIZE(vic));
 + s5pv210_clk_init(NULL, xxti_f, xusbxti_f, S3C_VA_SYS);
  }
 
  struct bus_type s5pv210_subsys = {
 diff --git a/arch/arm/mach-s5pv210/common.h
 b/arch/arm/mach-s5pv210/common.h index fe1beb5..2db2a15 100644
 --- a/arch/arm/mach-s5pv210/common.h
 +++ b/arch/arm/mach-s5pv210/common.h
 @@ -14,6 +14,19 @@
 
  #include linux/reboot.h
 
 +void s5pv210_set_xxti_freq(unsigned long freq);

This function is no longer present in common.c, so should be removed here 
as well.

 +void s5pv210_set_xusbxti_freq(unsigned long freq);
 +
 +#ifdef CONFIG_COMMON_CLK_S5PV210
 +void s5pv210_clk_init(struct device_node *np,
 + unsigned long xxti_f, unsigned long xusbxti_f,
 + void __iomem *reg_base);
 +#else
 +static inline void s5pv210_clk_init(struct device_node *np,
 + unsigned long xxti_f, unsigned long xusbxti_f,
 + void __iomem *reg_base) {}
 +#endif
 +
  void s5pv210_init_io(struct map_desc *mach_desc, int size);
  void s5pv210_init_irq(void);
 
 diff --git a/arch/arm/mach-s5pv210/mach-aquila.c
 b/arch/arm/mach-s5pv210/mach-aquila.c index ad40ab0..e37a311 100644
 --- a/arch/arm/mach-s5pv210/mach-aquila.c
 +++ b/arch/arm/mach-s5pv210/mach-aquila.c
 @@ -646,6 +646,7 @@ static void __init aquila_map_io(void)
  {
   s5pv210_init_io(NULL, 0);
   s3c24xx_init_clocks(2400);
 + 

Re: [PATCH 01/11] dt: binding: add binding for ImgTec IR block

2013-12-22 Thread Tomasz Figa
Hi James,

On Friday 13 of December 2013 15:12:49 James Hogan wrote:
 Add device tree binding for ImgTec Consumer Infrared block.
 
 Signed-off-by: James Hogan james.ho...@imgtec.com
 Cc: Mauro Carvalho Chehab m.che...@samsung.com
 Cc: linux-media@vger.kernel.org
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: devicet...@vger.kernel.org
 Cc: Rob Landley r...@landley.net
 Cc: linux-...@vger.kernel.org
 ---
  Documentation/devicetree/bindings/media/img-ir.txt | 20 
  1 file changed, 20 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/img-ir.txt
 
 diff --git a/Documentation/devicetree/bindings/media/img-ir.txt 
 b/Documentation/devicetree/bindings/media/img-ir.txt
 new file mode 100644
 index ..6f623b094ea6
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/img-ir.txt
 @@ -0,0 +1,20 @@
 +* ImgTec Infrared (IR) decoder
 +
 +Required properties:
 +- compatible:Should be img,ir

This compatible string isn't really very specific. Is there some IP
revision string that could be added, to account for possible design
changes that may require binding change?

 +- reg:   Physical base address of the controller and 
 length of
 + memory mapped region.
 +- interrupts:The interrupt specifier to the cpu.
 +
 +Optional properties:
 +- clocks:Clock specifier for base clock.
 + Defaults to 32.768KHz if not specified.

To make the binding less fragile and allow interoperability with non-DT
platforms it may be better to provide also clock-names property (so you
can use clk_get(); that's a Linux implementation detail, though, but to
make our lives easier IMHO they should be sometimes considered too).

Best regards,
Tomasz

--
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-24 Thread Tomasz Figa

Hi Shaik,

On 09.01.2014 04:28, 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


s/number/specifier/


+- clocks: should contain the SCALER clock specifier, from the
+   common clock bindings


s/specifier/phandle and specifier pair for each clock listed in 
clock-names property/


s/from/according to/


+- clock-names: should be scaler


should contain exactly one entry:
 - scaler - IP bus clock.

Also this patch should be first in the series to let the driver added in 
further patches use already present bindings.


Best regards,
Tomasz
--
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 v4 03/10] Documentation: devicetree: Update Samsung FIMC DT binding

2014-02-22 Thread Tomasz Figa

[Ccing Mike]

On 22.02.2014 23:02, Sylwester Nawrocki wrote:

On 02/21/2014 04:50 PM, Mark Rutland wrote:

On Thu, Feb 20, 2014 at 07:40:30PM +, Sylwester Nawrocki wrote:

+- #clock-cells: from the common clock bindings
(../clock/clock-bindings.txt),
+  must be 1. A clock provider is associated with the 'camera' node
and it should
+  be referenced by external sensors that use clocks provided by the
SoC on
+  CAM_*_CLKOUT pins. The clock specifier cell stores an index of a
clock.
+  The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks
respectively.
+
+- clock-output-names: from the common clock bindings, should contain
names of
+  clocks registered by the camera subsystem corresponding to
CAM_A_CLKOUT,
+  CAM_B_CLKOUT output clocks, in this order. Parent clock of these
clocks are
+  specified be first two entries of the clock-names property.


Do you need this?


All right, that might have been a bad idea, it mixes names of clocks
registered
by the main clock controller with names of clock input lines at the device.
It's a mistake I have been usually sensitive to and now made it myself. :/

My intention was to maintain the clock tree, since the camera block doesn't
generate the clock itself, it merely passes through the clocks from the
SoC main
clock controller (CMU). So clk parents need to be properly set and since
there
is no clock-output-names property at the CMU DT node,
of_clk_get_parent_name()
cannot be used.

So presumably the DT binding would be only specifying that the sclk_cam0,
sclk_cam1 clock input entries are associated with output clocks named as
in clock-output-names property.

And the driver could either:
  1) hard code those (well defined) CMU clock (clk parent) names,


I don't think this would be a good idea, as those CMU clock names may 
vary between SoCs.



  2) clk_get() its input clock, retrieve name with __clk_get_name() and
pass
it as parent name to clk_register() - it sounds a bit hacky though.


This looks fine, at least until proper interface is added to CCF. Exynos 
audio subsystem clock driver does exactly the same.


However, the right thing would be to make it possible to use pointers to 
struct clk instead of strings to list parent(s). This could be done by 
adding .parents field (struct clk **) to clk_init_data struct and make 
clk_register() use it if available.




The output clock names could be also well defined by the binding per the
IP's
compatible. Nevertheless using clock-output-names seems cleaner to me than
defining character strings in the driver.

What do you think ?


RANT

Personally, I don't like clock-output-names at all. The idea of having a 
global namespace for all clock providers looks flawed to me. This 
property only tries to work around the not-quite-right design by giving 
device tree the right to force CCF to use particular internal clock 
identifiers and avoid collisions if two providers happen to have the 
same internal clock names.


I believe there should be completely no need for clock-output-names, 
(other than a textual label for debugging purposes, analogically to 
regulator-name). If one clock provider needs a clock from another, then 
you should list it using clock bindings in node of the former, not rely 
on some static name assignments.


Then, after eliminating the need to use static names anymore, the 
namespace could be split into per-provider namespaces and we would have 
no collision issue anymore.


Of course it's probably to late already for such changes, as there are 
already systems relying on clock-output-names (i.e. without inter-IP 
clock dependencies listed using clock bindings) and we would have to 
keep backwards compatibility anyway...


/RANT

Best regards,
Tomasz
--
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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver

2014-03-19 Thread Tomasz Figa

Hi Laurent,

On 19.03.2014 12:31, Laurent Pinchart wrote:

Hi Shaik,

Thank you for the patch.

On Wednesday 19 March 2014 12:43:13 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   |   24 +
  1 file changed, 24 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..e1dd465
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
@@ -0,0 +1,24 @@
+* 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 specifier
+- clocks: should contain the SCALER clock phandle and specifier pair for
+   each clock listed in clock-names property, according to
+   the common clock bindings
+- clock-names: should contain exactly one entry
+   - scaler - IP bus clock


I'm not too familiar with the Exynos platform, but wouldn't it make sense to
use a common name across IP cores for interface and function clocks ?


Yes, it would definitely make sense, provided we are starting from 
scratch, but due to the lack of listed IP clock inputs in documentation, 
we ended with a custom of naming the inputs after SoC clocks of first 
SoC used with such driver. This showed up long before adoption of DT and 
common clocks on Samsung platform and I'd say it would be hard to get 
rid of it now.


Anyway, as long as clock names are well specified in binding 
documentation, it should be fine. So, from me it's a


Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz
--
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver

2014-05-07 Thread Tomasz Figa
[CCing more DT-folks :)]

On 07.05.2014 16:19, Rahul Sharma wrote:
 On 7 May 2014 19:06, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
 On 05/07/2014 12:38 PM, Rahul Sharma wrote:
 On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
 Hi,

 On 09/04/14 11:12, Rahul Sharma wrote:
 Idea looks good. How about keeping compatible which is independent
 of SoC, something like samsung,exynos-simple-phy and provide Reg
 and Bit through phy provider node. This way we can avoid SoC specific
 hardcoding in phy driver and don't need to look into dt bindings for
 each new SoC.

 I believe it is a not recommended approach.

 Why not? We should try to avoid hard coding in the driver code. Moreover by
 avoiding hardcoding we can make it a generic driver for single bit PHYs.


 +1.

 @Tomasz, any plans to consider this approach for simple phy driver?

 Regards,
 Rahul Sharma.


 Hi Rahul,
 Initially, I wanted to make a very generic driver and to add bit and
 register (or its offset) attribute to the PHY node.
 However, there was a very strong opposition from DT maintainers
 to adding any bit related configuration to DT.
 The current solution was designed to be a trade-off between
 being generic and being accepted :).

 
 Thanks Tomasz,
 Ok got it. lets discuss it again and conclude it.
 
 @Kishon, DT-folks,
 
 The original RFC patch from Tomasz (at https://lkml.org/lkml/2013/10/21/313)
 added simple phy driver as Generic-simple-phy with these properties:
 
 + of_property_read_u32(dev-of_node, mask, sphy-mask);
 + of_property_read_u32(dev-of_node, on-value, sphy-on_value);
 + of_property_read_u32(dev-of_node, off-value, sphy-off_value);
 
 Shall we consider the same solution again for generic simple phy
 driver which just expose on/off control through register bit.
 
 Regards,
 Rahul Sharma
 
 Regards,
 Tomasz Stanislawski



 Cheers
 Kishon


 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

Best regards,
Tomasz
--
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 1/3] [media] s5p-mfc: Add variants to access mfc registers

2014-05-08 Thread Tomasz Figa

Hi Arun, Paweł,

On 09.05.2014 06:49, Arun Kumar K wrote:

Hi Kamil,

On 05/09/14 06:30, Pawel Osciak wrote:

Hi Kamil,

On Fri, May 9, 2014 at 1:31 AM, Kamil Debski k.deb...@samsung.com wrote:


Hi Arun,

I think that this driver is getting too complicated now.

First there are separate files for MFC versions, but in addition there are
many
IF_MFCVx in there.


The intention of this patch is to actually get rid of IF_MFCVx
conditionals wherever possible.



I am curious how many additional lines it would take to
add s5p_mfc_cmd_v8.* and s5p_mfc_opr_v8.*.

I get the point that this approach may result in less lines added, but
having a callback specific for version use register pointers specific for
another version makes the code look unreadable and difficult to maintain.


Could you please give an example of how this reduces readability?
I personally feel this patch makes things much more readable (see below).

On the other hand, if we continued without the current method, we
would have to sprinkle
IF_MFCVx macros all around actual functions/operations, instead of
just containing this
to the regs structure, and the only difference in each path would be
register name defines.
I don't feel this would be a better direction to be honest.

Compare, new, after this patch:


+ WRITEL(y_addr, mfc_regs-e_source_first_plane_addr);
+ WRITEL(c_addr, mfc_regs-e_source_second_plane_addr);


vs previously, before this patch:


- if (IS_MFCV7(dev)) {
- WRITEL(y_addr, S5P_FIMV_E_SOURCE_FIRST_ADDR_V7);
- WRITEL(c_addr, S5P_FIMV_E_SOURCE_SECOND_ADDR_V7);
- } else {
- WRITEL(y_addr, S5P_FIMV_E_SOURCE_LUMA_ADDR_V6);
- WRITEL(c_addr, S5P_FIMV_E_SOURCE_CHROMA_ADDR_V6);
- }


And of course adding V8 more would make it even worse with yet another
else if case.



Please give your opinion on another way to add support for v8.
s5p_mfc_cmd_v8.* and s5p_mfc_opr_v8.* ?


If we add v7 and v8 files, a majority of their code will look like this:

s5p_mfc_opr_v6.c:
(...)
void foo_v6(args)
{
foofun(REGISTER_A_V6);
barfun(REGISTER_B_V6);
}
(...)

s5p_mfc_opr_v7.c:
(...)
void foo_v7(args)
{
foofun(REGISTER_A_V7);
barfun(REGISTER_B_V7);
}
(...)

s5p_mfc_opr_v8.c:
(...)
void foo_v8(args)
{
foofun(REGISTER_A_V8);
barfun(REGISTER_B_V8);
}
(...)

I'm not sure this is less error prone and less code...



Adding on to this, I had a discussion with the firmware team and what I
got to know is future firmwares are also going to keep the operation
sequence same as v6, but there can be more changes in register offsets
as they accomodate more features. So if we go with opr_v8.c, we _might_
need opr_v9.c also with hardly any change in the code except register
offset modifications.


If register offsets make for most of the differences between particular 
MFC versions, then probably having the register pointers used instead of 
base + OFFSET could be useful. Unfortunately we don't have much 
information about the newer variants, so it's hard to say.


Btw. I wonder why the firmware team couldn't simply add new registers at 
the end of the address space, without breaking software compatibility 
with every new version, even though rest of programming model mostly 
stays intact, which is a pure nonsense. Couldn't you complain to the for 
this if you have contact with them? Otherwise this madness will never stop.


Best regards,
Tomasz
--
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 0/3] Support for multiple MFC FW sub-versions

2014-05-20 Thread Tomasz Figa
Hi Arun,

On 20.05.2014 12:17, Arun Kumar K wrote:
 This patchset is for supporting multple firmware sub-versions
 for MFC. Newer firmwares come with changed interfaces and fixes
 without any change in the fw version number.
 So this implementation is as per Tomasz Figa's suggestion [1].
 [1] http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/31735
 
 Arun Kumar K (3):
   [media] s5p-mfc: Remove duplicate function s5p_mfc_reload_firmware
   [media] s5p-mfc: Support multiple firmware sub-versions
   [media] s5p-mfc: Add init buffer cmd to MFCV6
 
  drivers/media/platform/s5p-mfc/s5p_mfc.c|   11 +++---
  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   11 +-
  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |   44 
 ++-
  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++--
  4 files changed, 30 insertions(+), 42 deletions(-)
 

The whole series looks good.

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz
--
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] [media] Remove references to non-existent PLAT_S5P symbol

2014-10-06 Thread Tomasz Figa
On 06.10.2014 17:39, Sylwester Nawrocki wrote:
 diff --git a/drivers/media/platform/exynos4-is/Kconfig 
 b/drivers/media/platform/exynos4-is/Kconfig
 index 77c9512..b3b270a 100644
 --- a/drivers/media/platform/exynos4-is/Kconfig
 +++ b/drivers/media/platform/exynos4-is/Kconfig
 @@ -2,7 +2,7 @@
  config VIDEO_SAMSUNG_EXYNOS4_IS
   bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
 - depends on (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
 + depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
   depends on OF  COMMON_CLK
   help
 Say Y here to enable camera host interface devices for
 @@ -57,7 +57,7 @@ endif
  
  config VIDEO_EXYNOS4_FIMC_IS
   tristate EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
 - depends on HAS_DMA
 + depends on HAS_DMA  !ARCH_S5PV210

Hmm, does this change really do the intended thing?

Since both S5PV210 and Exynos are multiplatform-aware, now whenever
ARCH_S5PV210 is enabled, it isn't possible to enable
VIDEO_EXYNOS4_FIMC_IS, even though ARCH_EXYNOS can be enabled as well at
the same time.

Best regards,
Tomasz
--
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 v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

2015-11-02 Thread Tomasz Figa
On Mon, Nov 2, 2015 at 10:11 PM, Daniel Kurtz  wrote:
>
> +Tomasz, so he can reply to the thread
> +Marek and Russell as recommended by Tomasz
>
> On Oct 30, 2015 22:27, "Robin Murphy"  wrote:
> >
> > Hi Dan,
> >
> > On 30/10/15 01:17, Daniel Kurtz wrote:
> >>
> >> +linux-media & VIDEOBUF2 FRAMEWORK maintainers since this is about the
> >> v4l2-contig's usage of the DMA API.
> >>
> >> Hi Robin,
> >>
> >> On Tue, Oct 27, 2015 at 12:55 AM, Robin Murphy  
> >> wrote:
> >>>
> >>> On 26/10/15 13:44, Yong Wu wrote:
> 
> 
>  On Thu, 2015-10-01 at 20:13 +0100, Robin Murphy wrote:
>  [...]
> >
> >
> > +/*
> > + * The DMA API client is passing in a scatterlist which could describe
> > + * any old buffer layout, but the IOMMU API requires everything to be
> > + * aligned to IOMMU pages. Hence the need for this complicated bit of
> > + * impedance-matching, to be able to hand off a suitably-aligned list,
> > + * but still preserve the original offsets and sizes for the caller.
> > + */
> > +int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> > +   int nents, int prot)
> > +{
> > +   struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> > +   struct iova_domain *iovad = domain->iova_cookie;
> > +   struct iova *iova;
> > +   struct scatterlist *s, *prev = NULL;
> > +   dma_addr_t dma_addr;
> > +   size_t iova_len = 0;
> > +   int i;
> > +
> > +   /*
> > +* Work out how much IOVA space we need, and align the segments
> > to
> > +* IOVA granules for the IOMMU driver to handle. With some 
> > clever
> > +* trickery we can modify the list in-place, but reversibly, by
> > +* hiding the original data in the as-yet-unused DMA fields.
> > +*/
> > +   for_each_sg(sg, s, nents, i) {
> > +   size_t s_offset = iova_offset(iovad, s->offset);
> > +   size_t s_length = s->length;
> > +
> > +   sg_dma_address(s) = s->offset;
> > +   sg_dma_len(s) = s_length;
> > +   s->offset -= s_offset;
> > +   s_length = iova_align(iovad, s_length + s_offset);
> > +   s->length = s_length;
> > +
> > +   /*
> > +* The simple way to avoid the rare case of a segment
> > +* crossing the boundary mask is to pad the previous one
> > +* to end at a naturally-aligned IOVA for this one's
> > size,
> > +* at the cost of potentially over-allocating a little.

I'd like to know what is the boundary mask and what hardware imposes
requirements like this. The cost here is not only over-allocating a
little, but making many, many buffers contiguously mappable on the
CPU, unmappable contiguously in IOMMU, which just defeats the purpose
of having an IOMMU, which I believe should be there for simple IP
blocks taking one DMA address to be able to view the buffer the same
way as the CPU.

> > +*/
> > +   if (prev) {
> > +   size_t pad_len = roundup_pow_of_two(s_length);
> > +
> > +   pad_len = (pad_len - iova_len) & (pad_len - 1);
> > +   prev->length += pad_len;
> 
> 
> 
>  Hi Robin,
>  While our v4l2 testing, It seems that we met a problem here.
>  Here we update prev->length again, Do we need update
>  sg_dma_len(prev) again too?
> 
>  Some function like vb2_dc_get_contiguous_size[1] always get
>  sg_dma_len(s) to compare instead of s->length. so it may break
>  unexpectedly while sg_dma_len(s) is not same with s->length.
> >>>
> >>>
> >>>
> >>> This is just tweaking the faked-up length that we hand off to 
> >>> iommu_map_sg()
> >>> (see also the iova_align() above), to trick it into bumping this segment 
> >>> up
> >>> to a suitable starting IOVA. The real length at this point is stashed in
> >>> sg_dma_len(s), and will be copied back into s->length in __finalise_sg(), 
> >>> so
> >>> both will hold the same true length once we return to the caller.
> >>>
> >>> Yes, it does mean that if you have a list where the segment lengths are 
> >>> page
> >>> aligned but not monotonically decreasing, e.g. {64k, 16k, 64k}, then 
> >>> you'll
> >>> still end up with a gap between the second and third segments, but that's
> >>> fine because the DMA API offers no guarantees about what the resulting DMA
> >>> addresses will be (consider the no-IOMMU case where they would each just 
> >>> be
> >>> "mapped" to their physical address). If that breaks v4l, then it's 
> >>> probably
> >>> v4l's DMA API use that needs looking at (again).
> >>
> >>
> >> Hmm, I thought the DMA API maps a 

Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

2015-11-03 Thread Tomasz Figa
On Wed, Nov 4, 2015 at 2:41 AM, Robin Murphy <robin.mur...@arm.com> wrote:
> Hi Tomasz,
>
> On 02/11/15 13:43, Tomasz Figa wrote:
>>
>> I'd like to know what is the boundary mask and what hardware imposes
>> requirements like this. The cost here is not only over-allocating a
>> little, but making many, many buffers contiguously mappable on the
>> CPU, unmappable contiguously in IOMMU, which just defeats the purpose
>> of having an IOMMU, which I believe should be there for simple IP
>> blocks taking one DMA address to be able to view the buffer the same
>> way as the CPU.
>
>
> The expectation with dma_map_sg() is that you're either going to be
> iterating over the buffer segments, handing off each address to the device
> to process one by one;

My understanding of a scatterlist was that it represents a buffer as a
whole, by joining together its physically discontinuous segments.

I don't see how single segments (layout of which is completely up to
the allocator; often just single pages) would be usable for hardware
that needs to do some work more serious than just writing a byte
stream continuously to subsequent buffers. In case of such simple
devices you don't even need an IOMMU (for means other than protection
and/or getting over address space limitations).

However, IMHO the most important use case of an IOMMU is to make
buffers, which are contiguous in CPU virtual address space (VA),
contiguous in device's address space (IOVA). Your implementation of
dma_map_sg() effectively breaks this ability, so I'm not really
following why it's located under drivers/iommu and supposed to be used
with IOMMU-enabled platforms...

> or you have a scatter-gather-capable device, in which
> case you hand off the whole list at once.

No need for mapping ability of the IOMMU here as well (except for
working around address space issues, as I mentioned above).

> It's in the latter case where you
> have to make sure the list doesn't exceed the hardware limitations of that
> device. I believe the original concern was disk controllers (the
> introduction of dma_parms seems to originate from the linux-scsi list), but
> most scatter-gather engines are going to have some limit on how much they
> can handle per entry (IMO the dmaengine drivers are the easiest example to
> look at).
>
> Segment boundaries are a little more arcane, but my assumption is that they
> relate to the kind of devices whose addressing is not flat but relative to
> some separate segment register (The "64-bit" mode of USB EHCI is one
> concrete example I can think of) - since you cannot realistically change the
> segment register while the device is in the middle of accessing a single
> buffer entry, that entry must not fall across a segment boundary or at some
> point the device's accesses are going to overflow the offset address bits
> and wrap around to bogus addresses at the bottom of the segment.

The two requirements above sound like something really specific to
scatter-gather-capable hardware, which as I pointed above, barely need
an IOMMU (at least its mapping capabilities). We are talking here
about very IOMMU-specific code, though...

Now, while I see that on some systems there might be IOMMU used for
improving protection and working around addressing issues with
SG-capable hardware, the code shouldn't be breaking the majority of
systems with IOMMU used as the only possible way to make physically
discontinuous appear (IO-virtually) continuous to devices incapable of
scatter-gather.

>
> Now yes, it will be possible under _most_ circumstances to use an IOMMU to
> lay out a list of segments with page-aligned lengths within a single IOVA
> allocation whilst still meeting all the necessary constraints. It just needs
> some unavoidably complicated calculations - quite likely significantly more
> complex than my v5 version of map_sg() that tried to do that and merge
> segments but failed to take the initial alignment into account properly -
> since there are much simpler ways to enforce just the _necessary_ behaviour
> for the DMA API, I put the complicated stuff to one side for now to prevent
> it holding up getting the basic functional support in place.

Somehow just whatever currently done in arch/arm/mm/dma-mapping.c was
sufficient and not overly complicated.

See http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1547 .

I can see that the code there at least tries to comply with maximum
segment size constraint. Segment boundary seems to be ignored, though.
However, I'm convinced that in most (if not all) cases where IOMMU
IOVA-contiguous mapping is needed, those two requirements don't exist.
Do we really have to break the good hardware only because the
bad^Wlimited one is broken?

Couldn't we preserve the ARM-like behavior whenever
dma_parms->segment

Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

2015-11-03 Thread Tomasz Figa
On Wed, Nov 4, 2015 at 3:40 AM, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Tue, Nov 03, 2015 at 05:41:24PM +, Robin Murphy wrote:
>> Hi Tomasz,
>>
>> On 02/11/15 13:43, Tomasz Figa wrote:
>> >Agreed. The dma_map_*() API is not guaranteed to return a single
>> >contiguous part of virtual address space for any given SG list.
>> >However it was understood to be able to map buffers contiguously
>> >mappable by the CPU into a single segment and users,
>> >videobuf2-dma-contig in particular, relied on this.
>>
>> I don't follow that - _any_ buffer made of page-sized chunks is going to be
>> mappable contiguously by the CPU; it's clearly impossible for the streaming
>> DMA API itself to offer such a guarantee, because it's entirely orthogonal
>> to the presence or otherwise of an IOMMU.
>
> Tomasz's use of "virtual address space" above in combination with the
> DMA API is really confusing.

I suppose I must have mistakenly use "virtual address space" somewhere
instead of "IO virtual address space". I'm sorry for causing
confusion.

The thing being discussed here is mapping of buffers described by
scatterlists into IO virtual address space, i.e. the operation
happening when dma_map_sg() is called for an IOMMU-enabled device.

Best regards,
Tomasz
--
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 v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

2015-11-04 Thread Tomasz Figa
On Wed, Nov 4, 2015 at 6:27 PM, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Wed, Nov 04, 2015 at 02:12:03PM +0900, Tomasz Figa wrote:
>> My understanding of a scatterlist was that it represents a buffer as a
>> whole, by joining together its physically discontinuous segments.
>
> Correct, and it may also be scattered in CPU virtual space as well.
>
>> I don't see how single segments (layout of which is completely up to
>> the allocator; often just single pages) would be usable for hardware
>> that needs to do some work more serious than just writing a byte
>> stream continuously to subsequent buffers. In case of such simple
>> devices you don't even need an IOMMU (for means other than protection
>> and/or getting over address space limitations).
>
> All that's required is that the addresses described in the scatterlist
> are accessed as an apparently contiguous series of bytes.  They don't
> have to be contiguous in any address view, provided the device access
> appears to be contiguous.  How that is done is really neither here nor
> there.
>
> IOMMUs are normally there as an address translator - for example, the
> underlying device may not have the capability to address a scatterlist
> (eg, because it makes effectively random access) and in order to be
> accessible to the device, it needs to be made contiguous in device
> address space.
>
> Another scenario is that you have more bits of physical address than
> a device can generate itself for DMA purposes, and you need an IOMMU
> to create a (possibly scattered) mapping in device address space
> within the ability of the device to address.
>
> The requirements here depend on the device behind the IOMMU.

I fully agree with you.

The problem is that the code being discussed here breaks the case of
devices that don't have the capability of addressing a scatterlist,
supposedly for the sake of devices that have such capability (but as I
suggested, they both could be happily supported, by distinguishing
special values of DMA max segment size and boundary mask).

>> However, IMHO the most important use case of an IOMMU is to make
>> buffers, which are contiguous in CPU virtual address space (VA),
>> contiguous in device's address space (IOVA).
>
> No - there is no requirement for CPU virtual contiguous buffers to also
> be contiguous in the device address space.

There is no requirement, but shouldn't it be desired for the mapping
code to map them as such? Otherwise, how could the IOMMU use case you
described above (address translator for devices which don't have the
capability to address a scatterlist) be handled properly?

Is the general conclusion now that dma_map_sg() should not be used to
create IOMMU mappings and we should make a step backwards making all
drivers (or frameworks, such as videobuf2) do that manually? That
would be really backwards, because code not aware of IOMMU existence
at all would have to become aware of it.

Best regards,
Tomasz
--
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] media: vb2: Allow reqbufs(0) with "in use" MMAP buffers

2015-10-15 Thread Tomasz Figa
From: John Sheu <s...@chromium.org>

Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are
considered "in use".  This is different behavior than for other memory
types and prevents us from deallocating buffers in following two cases:

1) There are outstanding mmap()ed views on the buffer. However even if
   we put the buffer in reqbufs(0), there will be remaining references,
   due to vma .open/close() adjusting vb2 buffer refcount appropriately.
   This means that the buffer will be in fact freed only when the last
   mmap()ed view is unmapped.

2) Buffer has been exported as a DMABUF. Refcount of the vb2 buffer
   is managed properly by VB2 DMABUF ops, i.e. incremented on DMABUF
   get and decremented on DMABUF release. This means that the buffer
   will be alive until all importers release it.

Considering both cases above, there does not seem to be any need to
prevent reqbufs(0) operation, because buffer lifetime is already
properly managed by both mmap() and DMABUF code paths. Let's remove it
and allow userspace freeing the queue (and potentially allocating a new
one) even though old buffers might be still in processing.

Signed-off-by: John Sheu <s...@chromium.org>
Reviewed-by: Pawel Osciak <posc...@chromium.org>
Reviewed-by: Tomasz Figa <tf...@chromium.org>
Signed-off-by: Tomasz Figa <tf...@chromium.org>
---
 drivers/media/v4l2-core/videobuf2-core.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 4f59b7e..931c5de 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -636,19 +636,6 @@ static bool __buffer_in_use(struct vb2_queue *q, struct 
vb2_buffer *vb)
return false;
 }
 
-/**
- * __buffers_in_use() - return true if any buffers on the queue are in use and
- * the queue cannot be freed (by the means of REQBUFS(0)) call
- */
-static bool __buffers_in_use(struct vb2_queue *q)
-{
-   unsigned int buffer;
-   for (buffer = 0; buffer < q->num_buffers; ++buffer) {
-   if (__buffer_in_use(q, q->bufs[buffer]))
-   return true;
-   }
-   return false;
-}
 
 /**
  * __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to be
@@ -884,16 +871,7 @@ static int __reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
}
 
if (req->count == 0 || q->num_buffers != 0 || q->memory != req->memory) 
{
-   /*
-* We already have buffers allocated, so first check if they
-* are not in use and can be freed.
-*/
mutex_lock(>mmap_lock);
-   if (q->memory == V4L2_MEMORY_MMAP && __buffers_in_use(q)) {
-   mutex_unlock(>mmap_lock);
-   dprintk(1, "memory in use, cannot free\n");
-   return -EBUSY;
-   }
 
/*
 * Call queue_cancel to clean up any buffers in the PREPARED or
-- 
2.6.0.rc2.230.g3dd15c0

--
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: Questions about userspace, request and frame API in your Rockchip VPU driver

2016-07-26 Thread Tomasz Figa
Hi Florent,

Let's keep more people in the loop. CCing Pawel, Hans, Laurent and
linux-media ML, as there might be more people interested in the status
and/or helping.

On Tue, Jul 26, 2016 at 4:50 PM, Florent Revest
 wrote:
> Hi Tomasz,
>
> I'm currently an intern at Free Electrons working with Thomas and Maxime
> who told me that they know you.

Yeah, say hi to them from me. ;)

> I work on a v4l2 m2m VPU driver for
> Allwinner SoCs. This VPU has very similar problematics as the ones you
> meet on the Rockchip's RK3229. For instance, it is not able to work on
> raw bitstream and needs prior frames parsing, which can't be done in
> kernel space.
>
> Some time ago, I asked on the #v4l IRC channel what I should do to
> implement this behavior correctly and Hans Verkuil told me to get in
> touch with Pawel Osciak, but he is probably busy with other things and
> couldn't answer yet.

Yeah, I'm pretty much sure he is.

>
> So basically, I'm curious about the state of the "Frame API" he talked
> about at the linux kernel summit media workshop.
> https://blogs.s-osg.org/planning-future-media-linux-linux-kernel-summit-media-workshop-seoul-south-korea/
> Do you know what is the status of this API ?

I think the H264 API is more or less in a good shape. I don't remember
exactly, but VP8 API might need a bit more work. There is also VP9 API
in the works, but it's a quite early stage. Both are more or less
blocked currently on the request API, which needs to be extended to
support controls and merged upstream. I believe all the APIs could
benefit from adding more platforms to the discussion.

>
> Is this the place where it is implemented ?
> http://lists.infradead.org/pipermail/linux-rockchip/2016-February/007557.html
> If I get it right, this is just a new extended control that is attached
> to a frame with the media request API from Laurent, am I right ? I still
> have troubles understanding the overall concept of the request API and
> I'd like to know more about your usage of it.

You're correct. Basically for this kind of dumb decoding there is a
need to attach additional data to each frame. In theory that could be
done by a series of qbuf, s_ctrl, qbuf, s_ctrl, but it would require a
contract with the driver, so that it latches the controls at qbuf time
and would make the driver do basically the same as the request API,
but on its own. That would overly complicate the driver, considering
that you might want to queue multiple frames for better parallelism
and each needs its own set of data.

>
> Also, the text says "The user space code should be implemented as
> libv4l2 plugins". And Hans told me the opposite on IRC.
> kido | is developing a libv4l2 plugin interface which uses
> libavformat to pre-process buffers the "right" way to do it ?
> hverkuil | kido: no, there isn't. [...]
> hverkuil | Chances are he has code floating around for chromium that
> you can use.

Personally I think that a plugin would be a good way to deal with
legacy apps. Still, if I remember correctly, the preferred way is to
have a shared bitstream parser library and then use the slice/frame
API directly in the app, feeding the kernel with data from the parser.

>
> How is the userspace part of your rockchip driver implemented in Chrome
> OS and most importantly, do you have any userspace code available to share ?

I believe all the related code should be over there:

https://cs.chromium.org/chromium/src/media/gpu/

There are variants for VA-API, regular "smart" V4L2 codec API and
frame/slice API, which you are interested in. The class responsible
for talking the V4L2 frame/slice API is
v4l2_slice_video_decode_accelerator.cc and there should be also some
modules responsible for parsing the bitstream, but I don't have enough
knowledge on this code to point exactly.

Best regards,
Tomasz
--
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: [RFC 0/2] Add V4L2_BUF_TYPE_META_OUTPUT buffer type

2017-08-03 Thread Tomasz Figa
Hi Sakari,

On Sat, Jun 17, 2017 at 12:14 AM, Sakari Ailus
 wrote:
> The V4L2_BUF_TYPE_META_OUTPUT buffer type complements the metadata buffer
> types support for OUTPUT buffers, capture being already supported. This is
> intended for similar cases than V4L2_BUF_TYPE_META_CAPTURE but for output
> buffers, e.g. device parameters that may be complex and highly
> hierarchical data structure. Statistics are a current use case for
> metadata capture buffers.
>
> There's a warning related to references from make htmldocs; I'll fix that
> in v2 / non-RFC version.
>
> Sakari Ailus (2):
>   v4l: Add support for V4L2_BUF_TYPE_META_OUTPUT
>   docs-rst: v4l: Document V4L2_BUF_TYPE_META_OUTPUT interface
>
>  Documentation/media/uapi/v4l/buffer.rst  |  3 +++
>  Documentation/media/uapi/v4l/dev-meta.rst| 32 
> ++--
>  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +++
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c|  2 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  1 +
>  include/media/v4l2-ioctl.h   | 17 +
>  include/uapi/linux/videodev2.h   |  2 ++
>  8 files changed, 72 insertions(+), 13 deletions(-)

Is there by any chance an update on this series?

Best regards,
Tomasz


Re: [GIT PULL] linux-firmware: intel: Add Kabylake IPU3 firmware

2017-08-15 Thread Tomasz Figa
Hi everyone,

On Sat, Aug 5, 2017 at 9:04 AM, Mani, Rajmohan  wrote:
> Hi,
>
> Please review this PULL request to add Kabylake IPU3 firmware to the 
> linux-firmware repository.
>
>
> The following changes since commit 7d2c913dcd1be083350d97a8cb1eba24cfacbc8a:
>
>   ath10k: update year in license (2017-06-22 12:06:02 -0700)
>
> are available in the git repository at:
>
>   https://github.com/RajmohanMani/linux-firmware.git tags/v1
>
> for you to fetch changes up to 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f:
>
>   linux-firmware: intel: Add Kabylake IPU3 firmware (2017-08-04 15:53:13 
> -0700)
>
> 
> IPU3 firmware version irci_irci_ecr-master_20161208_0213_20170112_1500
>
> 
> Rajmohan Mani (1):
>   linux-firmware: intel: Add Kabylake IPU3 firmware
>
>  LICENSE.ipu3_firmware  |  36 
> 
>  WHENCE |  11 +++
>  intel/ipu3-fw.bin  |   1 +
>  intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin | Bin 0 -> 
> 1212984 bytes
>  4 files changed, 48 insertions(+)
>  create mode 100644 LICENSE.ipu3_firmware
>  create mode 12 intel/ipu3-fw.bin
>  create mode 100644 intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin

A gentle ping. Perhaps any issue with this pull request?

Best regards,
Tomasz


Re: [PATCH v2] media: ov5670: Fix incorrect frame timing reported to user

2017-08-10 Thread Tomasz Figa
Hi Chiranjeevi,

On Thu, Aug 10, 2017 at 6:59 AM, Chiranjeevi Rapolu
<chiranjeevi.rap...@intel.com> wrote:
> Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
> yielding incorrect frame timing for the user.
>
> OV sensor is using internal timing and this requires
> conversion (internal timing -> PPL) for correct HBLANK calculation.
>
> Now, change pixels-per-line domain from internal sensor clock to
> pixels domain. Set HBLANK read-only because fixed PPL is used for all
> resolutions. And, use more accurate link-frequency 422.4MHz instead of
> rounding down to 420MHz.
>
> Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rap...@intel.com>
> ---
> Changes in v2:
> - Change subject to reflect frame timing info.
> - Change OV5670_DEF_PPL so that it doesn't convey a register default
>   value. And, add more comments to it.
>  drivers/media/i2c/ov5670.c | 45 +++--
>  1 file changed, 23 insertions(+), 22 deletions(-)

Okay, the numbers in this version finally make sense. Thanks for
figuring this out.

Reviewed-by: Tomasz Figa <tf...@chromium.org>

Best regards,
Tomasz


Re: [PATCH v4 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver

2017-07-12 Thread Tomasz Figa
Hi Yong,

On Thu, Jul 13, 2017 at 8:20 AM, Zhi, Yong  wrote:
> Hi, Sakari,
>
> Thanks for the time spent on code review, acks to all the comments, except 
> two places:
>
>> +/* .complete() is called after all subdevices have been located */
>> +static int cio2_notifier_complete(struct v4l2_async_notifier *notifier)
>> +{
>> + struct cio2_device *cio2 = container_of(notifier, struct cio2_device,
>> + notifier);
>> + struct sensor_async_subdev *s_asd;
>> + struct fwnode_handle *fwn_remote, *fwn_endpt, *fwn_remote_endpt;
>> + struct cio2_queue *q;
>> + struct fwnode_endpoint remote_endpt;
>> + unsigned int i, pad;
>> + int ret;
>> +
>> + for (i = 0; i < notifier->num_subdevs; i++) {
>> + s_asd = container_of(cio2->notifier.subdevs[i],
>> + struct sensor_async_subdev,
>> + asd);
>> +
>> + fwn_remote = s_asd->asd.match.fwnode.fwnode;
>> + fwn_endpt = (struct fwnode_handle *)
>> + s_asd->vfwn_endpt.base.local_fwnode;
>
> Why do you need a cast?
>
> [YZ] With a cast results in compilation warning:

(I think you mean "without".)

>
> drivers/media/pci/ipu3/ipu3-cio2.c:1298:13: warning: assignment discards 
> ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
>fwn_endpt = /*(struct fwnode_handle *)*/

This is a sign that the code is doing something wrong (in this case
probably trying to write to a const pointer), so casting just silences
the unfixed error.

>
>> + ret = v4l2_async_notifier_register(>v4l2_dev, >notifier);
>> + if (ret) {
>> + cio2->notifier.num_subdevs = 0;
>
> No need to assign num_subdevs as 0.
>
> [YZ] _notifier_exit() will call _unregister() if this is not 0.

You shouldn't call _exit() if _init() failed. I noticed that many
error paths in your code does this. Please fix it.

Best regards,
Tomasz


Re: [PATCH v4 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver

2017-07-13 Thread Tomasz Figa
On Thu, Jul 13, 2017 at 5:21 PM, Sakari Ailus  wrote:
>> >> + ret = v4l2_async_notifier_register(>v4l2_dev, 
>> >> >notifier);
>> >> + if (ret) {
>> >> + cio2->notifier.num_subdevs = 0;
>> >
>> > No need to assign num_subdevs as 0.
>> >
>> > [YZ] _notifier_exit() will call _unregister() if this is not 0.
>>
>> You shouldn't call _exit() if _init() failed. I noticed that many
>> error paths in your code does this. Please fix it.
>
> In general most functions that initialise and clean up something are
> implemented so that the cleanup function can be called without calling the
> corresponding init function. This eases driver implementation by reducing
> complexity in error paths that are difficult to implement and test to begin
> with, so I don't see anything wrong with that, quite the contrary.
>
> I.e. in this case you should call v4l2_async_notifier_unregister() without
> checking the number of async sub-devices.
>
> There are exceptions to that though; not all the framework functions behave
> this way. Of kernel APIs, e.g. kmalloc() and kfree() do this --- you can
> pass a NULL pointer to kfree() and it does nothing.

I'd argue that most of the cleanup paths I've seen in the kernel are
the opposite. If you properly check for errors in your code, it's
actually very unlikely that you need to call a cleanup function
without the init function called... That said, I've seen the pattern
you describe too, so probably either there is no strict rule or it's
not strictly enforced. (Still, judging by
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#centralized-exiting-of-functions,
which mentions "one err bugs" and suggests "to split it up into two
error labels", the pattern I'm arguing for might be the recommended
default.)

Best regards,
Tomasz


Re: [PATCH v3 02/12] intel-ipu3: mmu: implement driver

2017-07-26 Thread Tomasz Figa
Hi Robin,

On Wed, Jul 19, 2017 at 10:37 PM, Robin Murphy <robin.mur...@arm.com> wrote:
> On 19/07/17 04:12, Yong Zhi wrote:
>> From: Tomasz Figa <tf...@chromium.org>
>>
>> This driver translates Intel IPU3 internal virtual
>> address to physical address.
>>
>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> Signed-off-by: Yong Zhi <yong@intel.com>
>> ---
>>  drivers/media/pci/intel/ipu3/Kconfig|   9 +
>>  drivers/media/pci/intel/ipu3/Makefile   |  15 +
>>  drivers/media/pci/intel/ipu3/ipu3-mmu.c | 639 
>> 
>>  drivers/media/pci/intel/ipu3/ipu3-mmu.h |  27 ++
>>  4 files changed, 690 insertions(+)
>>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c
>>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h
>>
>> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
>> b/drivers/media/pci/intel/ipu3/Kconfig
>> index 2a895d6..7bcdfa5 100644
>> --- a/drivers/media/pci/intel/ipu3/Kconfig
>> +++ b/drivers/media/pci/intel/ipu3/Kconfig
>> @@ -15,3 +15,12 @@ config VIDEO_IPU3_CIO2
>>   Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
>>   connected camera.
>>   The module will be called ipu3-cio2.
>> +
>> +config INTEL_IPU3_MMU
>> + tristate
>
> Shouldn't this be bool now?

Well, depends on what we expect it to be. I still didn't see any good
reason not to make it a loadable module.

>
>> + default n
>> + select IOMMU_API
>> + select IOMMU_IOVA
>> + ---help---
>> +   For IPU3, this option enables its MMU driver to translate its 
>> internal
>> +   virtual address to 39 bits wide physical address for 64GBytes space 
>> access.
>> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
>> b/drivers/media/pci/intel/ipu3/Makefile
>> index 20186e3..91cac9c 100644
>> --- a/drivers/media/pci/intel/ipu3/Makefile
>> +++ b/drivers/media/pci/intel/ipu3/Makefile
>> @@ -1 +1,16 @@
>> +#
>> +#  Copyright (c) 2017, Intel Corporation.
>> +#
>> +#  This program is free software; you can redistribute it and/or modify it
>> +#  under the terms and conditions of the GNU General Public License,
>> +#  version 2, as published by the Free Software Foundation.
>> +#
>> +#  This program is distributed in the hope it will be useful, but WITHOUT
>> +#  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> +#  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> +#  more details.
>> +#
>> +
>>  obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>> +obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
>> +
>> diff --git a/drivers/media/pci/intel/ipu3/ipu3-mmu.c 
>> b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
>> new file mode 100644
>> index 000..093b821
>> --- /dev/null
>> +++ b/drivers/media/pci/intel/ipu3/ipu3-mmu.c
>> @@ -0,0 +1,639 @@
>> +/*
>> + * Copyright (c) 2017 Intel Corporation.
>> + * Copyright (C) 2017 Google, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License version
>> + * 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include "ipu3-mmu.h"
>> +
>> +#define IPU3_PAGE_SHIFT  12
>> +#define IPU3_PAGE_SIZE   (1UL << IPU3_PAGE_SHIFT)
>> +
>> +#define IPU3_PT_BITS 10
>> +#define IPU3_PT_PTES (1UL << IPU3_PT_BITS)
>> +
>> +#define IPU3_ADDR2PTE(addr)  ((addr) >> IPU3_PAGE_SHIFT)
>> +#define IPU3_PTE2ADDR(pte)   ((phys_addr_t)(pte) << IPU3_PAGE_SHIFT)
>> +
>> +#define IPU3_L2PT_SHIFT  IPU3_PT_BITS
>> +#define IPU3_L2PT_MASK   ((1UL << IPU3_L2PT_SHIFT) - 1)
>> +
>> +#define IPU3_L1PT_SHIFT  IPU3_PT_BITS
>> +#define IPU3_L1PT_MASK   ((1UL << IPU3_L1PT_SHIFT) - 1)
>> +
>> +#define IPU3_MMU_ADDRESS_BITS(IPU3_PAGE_SHIFT + \
>> +

Re: [PATCH v3 03/12] intel-ipu3: Add DMA API implementation

2017-07-26 Thread Tomasz Figa
On Fri, Jul 21, 2017 at 7:09 AM, Sakari Ailus <sakari.ai...@iki.fi> wrote:
> Hi Arnd,
>
> On Wed, Jul 19, 2017 at 09:24:41AM +0200, Arnd Bergmann wrote:
>> On Wed, Jul 19, 2017 at 5:12 AM, Yong Zhi <yong@intel.com> wrote:
>> > From: Tomasz Figa <tf...@chromium.org>
>> >
>> > This patch adds support for the IPU3 DMA mapping API.
>> >
>> > Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> > Signed-off-by: Yong Zhi <yong@intel.com>
>>
>> This needs some explanation on why you decided to go down the
>> route of adding your own dma_map_ops. It's not obvious at all,
>> and and I'm still concerned that this complicates things more than
>> it helps.
>
> There are a few considerations here --- they could be documented in the
> patch commit message
>
> - The device has its own MMU. The default x86 DMA ops assume there isn't.
>
> - As this is an image signal processor device, the buffers are typically
>   large (often in the range of tens of MB) and they do not need to be
>   physically contiguous. The current implementation of e.g.
>   drivers/iommu/intel-iommu.c allocate memory using alloc_pages() which is
>   unfeasible for such single allocations. Neither CMA is needed.
>
>   Also other IOMMU implementations have their own DMA ops currently.
>
> I agree it'd be nice to unify these in the long run but I don't think this
> stands apart from the rest currently --- except that the MMU is only used
> by a single PCI device, the same which it is contained in.

On top of what Sakari said, it just perfectly matches what V4L2
videobuf2 framework expects. It does all the buffer mapping and
synchronization using DMA mapping and given the x86 DMA ops being
useless for this device, it makes everything that videobuf2 does using
them useless too.

Best regards,
Tomasz


Re: [PATCH 01/12] [media] vb2: add explicit fence user API

2017-07-03 Thread Tomasz Figa
Hi Gustavo,

On Tue, Jun 27, 2017 at 12:39 AM, Gustavo Padovan  wrote:
> 2017-06-18 kbuild test robot :
>
>> Hi Gustavo,
>>
>> [auto build test ERROR on linuxtv-media/master]
>> [also build test ERROR on v4.12-rc5 next-20170616]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Gustavo-Padovan/vb2-add-explicit-fence-user-API/20170618-210740
>> base:   git://linuxtv.org/media_tree.git master
>> config: x86_64-allmodconfig (attached as .config)
>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All error/warnings (new ones prefixed by >>):
>>
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>> 'atomisp_qbuf':
>> >> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1297:10: 
>> >> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> >> 'reserved'?
>>  (buf->reserved2 & ATOMISP_BUFFER_HAS_PER_FRAME_SETTING)) {
>>  ^~
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1299:50: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>   pipe->frame_request_config_id[buf->index] = buf->reserved2 &
>>  ^~
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
>> 'atomisp_dqbuf':
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1483:5: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>  buf->reserved2 = pipe->frame_config_id[buf->index];
>> ^~
>>In file included from include/linux/printk.h:329:0,
>> from include/linux/kernel.h:13,
>> from include/linux/delay.h:21,
>> from 
>> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:24:
>>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1488:6: 
>> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
>> 'reserved'?
>>   buf->reserved2);
>>  ^
>
> Ouch! Seems the reserved2 was burned down by 2 drivers accessing it
> without any care for the uAPI. I'll change my patches to use the
> 'reserved' field instead.

Given that a reserved field has a clear meaning of being reserved and
the driver in question is in staging. I'd rather vote for fixing the
driver.

Best regards,
Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig <h...@lst.de> wrote:
>>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>
>>> In general I think moving dma
>>> ops and iommu implementations into modules is a bad idea
>>
>> Could you elaborate on this? I'd be interested in seeing the reasoning
>> behind this.
>>
>>> but I
>>> don't want to reject the idea before seeing the code.  Or maybe
>>> by looking at the user we can come up with an even better idea
>>> to solve the original issue you're trying to solve, so please also
>>> explain your rationale.
>
> I had pretty much the same thoughts here.
>
>> Basically we have an x86 platform with a camera subsystem that is a
>> PCI device, has its own MMU and needs cache maintenance. Moreover, the
>> V4L2 subsystem, which is the right place for camera drivers, heavily
>> relies on DMA mapping as a way to abstract memory allocation, mapping
>> and cache maintenance. So it feels natural to me to hide the hardware
>> details (additional cache maintenance, mapping into the built-in
>> IOMMU) in the DMA mapping ops for this camera subsystem and simply
>> make V4L2 just work without knowing those details.
>
> I can understand your reasoning here, but I'm also not convinced
> that this is the best approach. There may be a middle ground somewhere
> though.
>
> Generally speaking I don't want to have to deal with the horrors of
> deciding whether an IOMMU is going to be there eventually or not
> at probe() time. At some point, we had decided that IOMMUs need to
> be initialized (almost) as early as irqchips and clocksources so we can
> rely on them to be there at device discovery time. That got pushed
> back already, and now we may have to deal with -EPROBE_DEFER
> when an IOMMU has not been fully initialized at device probe time,
> but at least we can reliably see if one is there or not. Making IOMMUs
> modular will add further uncertainty here. Obviously we cannot attach
> an IOMMU to a device once we have started using DMA mapping
> calls on it.

The hardware can only work with IOMMU and so the main module is highly
tied with the IOMMU module and it initialized it directly. There is no
separate struct driver or device associated with the IOMMU, as it's a
part of the one and only one PCI device (as visible from the system
PCI bus point of view) and technically handled by one pci_driver.

>
> For your particular use case, I would instead leave the knowledge
> about the IOMMU in the driver itself, like we do for the IOMMUs
> that are integrated in desktop GPUs, and have the code use the
> DMA mapping API with the system-provided dma_map_ops to
> get dma_addr_t tokens which you then program into the device
> IOMMU.
>
> An open question however would be whether to use the IOMMU
> API without the DMA mapping API here, or whether to completely
> leave the knowledge of the IOMMU inside of the driver itself.
> I don't have a strong opinion on that part, and I guess this mostly
> depends on what the hardware looks like.

+ linux-media and some media folks

I'd say that this is something that has been consistently tried to be
avoided by V4L2 and that's why it's so tightly integrated with DMA
mapping. IMHO re-implementing the code that's already there in
videobuf2 again in the driver, only because, for no good reason
mentioned as for now, having a loadable module providing DMA ops was
disliked.

Similarly with IOMMU API. It provides a lot of help in managing the
mappings and re-implementing this would be IMHO backwards.

Best regards,
Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tf...@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <a...@arndb.de> wrote:
>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig <h...@lst.de> wrote:
>>>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
>>
>>>> In general I think moving dma
>>>> ops and iommu implementations into modules is a bad idea
>>>
>>> Could you elaborate on this? I'd be interested in seeing the reasoning
>>> behind this.
>>>
>>>> but I
>>>> don't want to reject the idea before seeing the code.  Or maybe
>>>> by looking at the user we can come up with an even better idea
>>>> to solve the original issue you're trying to solve, so please also
>>>> explain your rationale.
>>
>> I had pretty much the same thoughts here.
>>
>>> Basically we have an x86 platform with a camera subsystem that is a
>>> PCI device, has its own MMU and needs cache maintenance. Moreover, the
>>> V4L2 subsystem, which is the right place for camera drivers, heavily
>>> relies on DMA mapping as a way to abstract memory allocation, mapping
>>> and cache maintenance. So it feels natural to me to hide the hardware
>>> details (additional cache maintenance, mapping into the built-in
>>> IOMMU) in the DMA mapping ops for this camera subsystem and simply
>>> make V4L2 just work without knowing those details.
>>
>> I can understand your reasoning here, but I'm also not convinced
>> that this is the best approach. There may be a middle ground somewhere
>> though.
>>
>> Generally speaking I don't want to have to deal with the horrors of
>> deciding whether an IOMMU is going to be there eventually or not
>> at probe() time. At some point, we had decided that IOMMUs need to
>> be initialized (almost) as early as irqchips and clocksources so we can
>> rely on them to be there at device discovery time. That got pushed
>> back already, and now we may have to deal with -EPROBE_DEFER
>> when an IOMMU has not been fully initialized at device probe time,
>> but at least we can reliably see if one is there or not. Making IOMMUs
>> modular will add further uncertainty here. Obviously we cannot attach
>> an IOMMU to a device once we have started using DMA mapping
>> calls on it.
>
> The hardware can only work with IOMMU and so the main module is highly
> tied with the IOMMU module and it initialized it directly. There is no
> separate struct driver or device associated with the IOMMU, as it's a
> part of the one and only one PCI device (as visible from the system
> PCI bus point of view) and technically handled by one pci_driver.
>
>>
>> For your particular use case, I would instead leave the knowledge
>> about the IOMMU in the driver itself, like we do for the IOMMUs
>> that are integrated in desktop GPUs, and have the code use the
>> DMA mapping API with the system-provided dma_map_ops to
>> get dma_addr_t tokens which you then program into the device
>> IOMMU.
>>
>> An open question however would be whether to use the IOMMU
>> API without the DMA mapping API here, or whether to completely
>> leave the knowledge of the IOMMU inside of the driver itself.
>> I don't have a strong opinion on that part, and I guess this mostly
>> depends on what the hardware looks like.
>
> + linux-media and some media folks
>
> I'd say that this is something that has been consistently tried to be
> avoided by V4L2 and that's why it's so tightly integrated with DMA
> mapping. IMHO re-implementing the code that's already there in
> videobuf2 again in the driver, only because, for no good reason
> mentioned as for now, having a loadable module providing DMA ops was
> disliked.

Sorry, I intended to mean:

IMHO re-implementing the code that's already there in videobuf2 again
in the driver, only because, for no good reason mentioned as for now,
having a loadable module providing DMA ops was disliked, would make no
sense.

>
> Similarly with IOMMU API. It provides a lot of help in managing the
> mappings and re-implementing this would be IMHO backwards.
>
> Best regards,
> Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa <tf...@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann <a...@arndb.de> wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <a...@arndb.de> wrote:
>>>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>
>>>>
>>>> I'd say that this is something that has been consistently tried to be
>>>> avoided by V4L2 and that's why it's so tightly integrated with DMA
>>>> mapping. IMHO re-implementing the code that's already there in
>>>> videobuf2 again in the driver, only because, for no good reason
>>>> mentioned as for now, having a loadable module providing DMA ops was
>>>> disliked.
>>>
>>> Sorry, I intended to mean:
>>>
>>> IMHO re-implementing the code that's already there in videobuf2 again
>>> in the driver, only because, for no good reason mentioned as for now,
>>> having a loadable module providing DMA ops was disliked, would make no
>>> sense.
>>
>> Why would we need to duplicate that code? I would expect that the videobuf2
>> core can simply call the regular dma_mapping interfaces, and you handle the
>> IOPTE generation at the point when the buffer is handed off from the core
>> code to the device driver. Am I missing something?
>
> Well, for example, the iommu-dma helpers already implement all the
> IOVA management, SG iterations, IOMMU API calls, sanity checks and so
> on. There is a significant amount of common code.
>
> On the other hand, if it's strictly about base/dma-mapping, we might
> not need it indeed. The driver could call iommu-dma helpers directly,
> without the need to provide its own DMA ops. One caveat, though, we
> are not able to obtain coherent (i.e. uncached) memory with this
> approach, which might have some performance effects and complicates
> the code, that would now need to flush caches even for some small
> internal buffers.

I think I should add a bit of explanation here:
 1) the device is non-coherent with CPU caches, even on x86,
 2) it looks like x86 does not have non-coherent DMA ops, (but it
might be something that could be fixed)
 3) one technically could still use __get_vm_area() and map_vm_area(),
which _are_ exported, to create an uncached mapping. I'll leave it to
you to judge if it would be better than using the already available
generic helpers.

Best regards,
Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa <tf...@chromium.org> wrote:
>
>>> On the other hand, if it's strictly about base/dma-mapping, we might
>>> not need it indeed. The driver could call iommu-dma helpers directly,
>>> without the need to provide its own DMA ops. One caveat, though, we
>>> are not able to obtain coherent (i.e. uncached) memory with this
>>> approach, which might have some performance effects and complicates
>>> the code, that would now need to flush caches even for some small
>>> internal buffers.
>>
>> I think I should add a bit of explanation here:
>>  1) the device is non-coherent with CPU caches, even on x86,
>>  2) it looks like x86 does not have non-coherent DMA ops, (but it
>> might be something that could be fixed)
>
> I don't understand what this means here. The PCI on x86 is always
> cache-coherent, so why is the device not?
>
> Do you mean that the device has its own caches that may need
> flushing to make the device cache coherent with the CPU cache,
> rather than flushing the CPU caches?

Sakari might be able to explain this with more technical details, but
generally the device is not a standard PCI device one might find on
existing x86 systems.

It is some kind of embedded subsystem that behaves mostly like a PCI
device, with certain exceptions, one being the lack of coherency with
CPU caches, at least for certain parts of the subsystem. The reference
vendor code disables the coherency completely, for reasons not known
to me, but AFAICT this is the preferred operating mode, possibly due
to performance effects (this is a memory-heavy image processing
subsystem).

Best regards,
Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann <a...@arndb.de> wrote:
>>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>
>>>
>>> I'd say that this is something that has been consistently tried to be
>>> avoided by V4L2 and that's why it's so tightly integrated with DMA
>>> mapping. IMHO re-implementing the code that's already there in
>>> videobuf2 again in the driver, only because, for no good reason
>>> mentioned as for now, having a loadable module providing DMA ops was
>>> disliked.
>>
>> Sorry, I intended to mean:
>>
>> IMHO re-implementing the code that's already there in videobuf2 again
>> in the driver, only because, for no good reason mentioned as for now,
>> having a loadable module providing DMA ops was disliked, would make no
>> sense.
>
> Why would we need to duplicate that code? I would expect that the videobuf2
> core can simply call the regular dma_mapping interfaces, and you handle the
> IOPTE generation at the point when the buffer is handed off from the core
> code to the device driver. Am I missing something?

Well, for example, the iommu-dma helpers already implement all the
IOVA management, SG iterations, IOMMU API calls, sanity checks and so
on. There is a significant amount of common code.

On the other hand, if it's strictly about base/dma-mapping, we might
not need it indeed. The driver could call iommu-dma helpers directly,
without the need to provide its own DMA ops. One caveat, though, we
are not able to obtain coherent (i.e. uncached) memory with this
approach, which might have some performance effects and complicates
the code, that would now need to flush caches even for some small
internal buffers.

Best regards,
Tomasz


Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

2017-07-06 Thread Tomasz Figa
On Thu, Jul 6, 2017 at 11:27 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann <a...@arndb.de> wrote:
>>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>
>>>>> On the other hand, if it's strictly about base/dma-mapping, we might
>>>>> not need it indeed. The driver could call iommu-dma helpers directly,
>>>>> without the need to provide its own DMA ops. One caveat, though, we
>>>>> are not able to obtain coherent (i.e. uncached) memory with this
>>>>> approach, which might have some performance effects and complicates
>>>>> the code, that would now need to flush caches even for some small
>>>>> internal buffers.
>>>>
>>>> I think I should add a bit of explanation here:
>>>>  1) the device is non-coherent with CPU caches, even on x86,
>>>>  2) it looks like x86 does not have non-coherent DMA ops, (but it
>>>> might be something that could be fixed)
>>>
>>> I don't understand what this means here. The PCI on x86 is always
>>> cache-coherent, so why is the device not?
>>>
>>> Do you mean that the device has its own caches that may need
>>> flushing to make the device cache coherent with the CPU cache,
>>> rather than flushing the CPU caches?
>>
>> Sakari might be able to explain this with more technical details, but
>> generally the device is not a standard PCI device one might find on
>> existing x86 systems.
>>
>> It is some kind of embedded subsystem that behaves mostly like a PCI
>> device, with certain exceptions, one being the lack of coherency with
>> CPU caches, at least for certain parts of the subsystem. The reference
>> vendor code disables the coherency completely, for reasons not known
>> to me, but AFAICT this is the preferred operating mode, possibly due
>> to performance effects (this is a memory-heavy image processing
>
> Ok, got it. I think something similar happens on integrated GPUs for
> a certain CPU family. The DRM code has its own ways of dealing with
> this kind of device. If you find that the hardware to be closely
> related (either the implementation, or the location on the internal
> buses) to the GPU on this machine, I'd recommend having a look
> in drivers/gpu/drm to see how it's handled there, and if that code could
> be shared.

I think it's not closely related, but might be a very similar case.

Still, DRM is very liberal in terms of not using common code for doing
things, while V4L2 tries to makes things generic as much as possible.
There is already the vb2_dma_contig backend, which allocates coherent
memory (in case of V4L2-allocated buffers), manages caches (in case of
userptr or DMA-buf buffers) and so on for you. If we can't have the
DMA ops do the right thing, the code there is essentially useless and
you are left with vb2_dma_sg that uses a page allocator and gives the
driver sg tables (it actually can also do cache management for you,
but since dma_sync_sg_*() is essentially a no-op on x86, the driver
would have to do it on its own).

Best regards,
Tomasz


Re: [PATCH v2 3/3] [media] intel-ipu3: cio2: Add new MIPI-CSI2 driver

2017-06-28 Thread Tomasz Figa
On Wed, Jun 28, 2017 at 10:31 PM, Sakari Ailus <sakari.ai...@iki.fi> wrote:
> On Tue, Jun 27, 2017 at 06:33:13PM +0900, Tomasz Figa wrote:
>> On Mon, Jun 26, 2017 at 11:51 PM, Sakari Ailus <sakari.ai...@iki.fi> wrote:
>> > On Mon, Jun 12, 2017 at 06:59:18PM +0900, Tomasz Figa wrote:
>> >
>> >>
>> >> > +   if (WARN_ON(freq <= 0))
>> >> > +   return -EINVAL;
>> >>
>> >> It generally doesn't make sense for the frequency to be negative, so
>> >> maybe the argument should have been unsigned to start with? (And
>> >> 32-bit if we don't expect frequencies higher than 4 GHz anyway.)
>> >
>> > The value comes from a 64-bit integer V4L2 control so that implies the 
>> > value
>> > range of s64 as well.
>>
>> Okay, if there is no way to enforce this at control level, then I
>> guess we have to keep this here.
>>
>> >
>> >>
>> >> > +
>> >> > +   /* b could be 0, -2 or -8, so r < 5 */
>> >>
>> >> Definitely. Anything <= 0 is also less than 5. Let's take a
>> >> look at the computation below again:
>> >>
>> >> 1) accinv is multiplied by b,
>> >> 2) 5 is divided by 256 (=== shift right by 8 bits) = 1953125,
>> >> 3) accinv*b is multiplied by 1953125 to form the value of r.
>> >>
>> >> Now let's see at possible maximum absolute values for particular steps:
>> >> 1) 16 * -8 = -128 (signed 8 bits),
>> >> 2) 1953125 (unsigned 21 bits),
>> >> 3) -128 * 1953125 = -24872 (signed 29 bits).
>> >>
>> >> So I think the important thing to note in the comment is:
>> >>
>> >> /* b could be 0, -2 or -8, so |accinv * b| is always less than (1 <<
>> >> ds) and thus |r| < 5. */
>> >>
>> >> > +   r = accinv * b * (5 >> ds);
>> >>
>> >> On the other hand, you lose some precision here. If you used s64
>> >> instead and did the divide shift at the end ((accinv * b * 5)
>> >> >> ds), for the example above you would get -250007629. (Depending on
>> >> how big freq is, it might not matter, though.)
>> >>
>> >
>> > The frequency is typically hundreds of mega-Hertz.
>>
>> I think it still would make sense to have the calculation a bit more precise.
>
> Then the solution is to divide by the 64-bit number, i.e. do_div(). IMO
> this shouldn't be a big deal either way: the result needs to be in a value
> range and this is only done once when streaming is started.
>
>>
>> >
>> >> Also nit: What is 5? We have local constants defined above, I
>> >> think it could also make sense to do the same for this one. The
>> >> compiler should do constant propagation and simplify respective
>> >> calculations anyway.
>> >
>> > COUNT_ACC in the formula in the comment a few decalines above is in
>> > nanoseconds. Performing the calculations in integer arithmetics results in
>> > having 5 in the resulting formula.
>> >
>> > So this is actually a constant related to the hardware but it does not have
>> > a pre-determined name because it is derived from COUNT_ACC.
>>
>> Which, I believe, doesn't stop us from naming it.
>
> No, but the value is derived from another value and used once. There's not
> much value in adding a macro for IMO.
>
> The formula can be perhaps easier written as:
>
> accinv * a + (accinv * b * (5 >> ds)
>   / (int32_t)(link_freq >> ds));
>
> If you insist, how about COUNT_ACC_FACTOR, for it's derived from COUNT_ACC?
>
>>
>> >> > +static int cio2_v4l2_querycap(struct file *file, void *fh,
>> >> > + struct v4l2_capability *cap)
>> >> > +{
>> >> > +   struct cio2_device *cio2 = video_drvdata(file);
>> >> > +
>> >> > +   strlcpy(cap->driver, CIO2_NAME, sizeof(cap->driver));
>> >> > +   strlcpy(cap->card, CIO2_DEVICE_NAME, sizeof(cap->card));
>> >> > +   snprintf(cap->bus_info, sizeof(cap->bus_info),
>> >> > +"PCI:%s", pci_name(cio2->pci_dev));
>> >> > +   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
>> >>
>> >> Hmm, I thought single plane queu

Re: [PATCH v3 02/12] intel-ipu3: mmu: implement driver

2017-07-28 Thread Tomasz Figa
On Fri, Jul 28, 2017 at 11:10 PM, Robin Murphy <robin.mur...@arm.com> wrote:
> On 26/07/17 11:38, Tomasz Figa wrote:
>> Hi Robin,
>>
>> On Wed, Jul 19, 2017 at 10:37 PM, Robin Murphy <robin.mur...@arm.com> wrote:
>>> On 19/07/17 04:12, Yong Zhi wrote:
>>>> From: Tomasz Figa <tf...@chromium.org>
>>>>
>>>> This driver translates Intel IPU3 internal virtual
>>>> address to physical address.
>>>>
>>>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>>>> Signed-off-by: Yong Zhi <yong@intel.com>
>>>> ---
>>>>  drivers/media/pci/intel/ipu3/Kconfig|   9 +
>>>>  drivers/media/pci/intel/ipu3/Makefile   |  15 +
>>>>  drivers/media/pci/intel/ipu3/ipu3-mmu.c | 639 
>>>> 
>>>>  drivers/media/pci/intel/ipu3/ipu3-mmu.h |  27 ++
>>>>  4 files changed, 690 insertions(+)
>>>>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.c
>>>>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-mmu.h
>>>>
>>>> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
>>>> b/drivers/media/pci/intel/ipu3/Kconfig
>>>> index 2a895d6..7bcdfa5 100644
>>>> --- a/drivers/media/pci/intel/ipu3/Kconfig
>>>> +++ b/drivers/media/pci/intel/ipu3/Kconfig
>>>> @@ -15,3 +15,12 @@ config VIDEO_IPU3_CIO2
>>>>   Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
>>>>   connected camera.
>>>>   The module will be called ipu3-cio2.
>>>> +
>>>> +config INTEL_IPU3_MMU
>>>> + tristate
>>>
>>> Shouldn't this be bool now?
>>
>> Well, depends on what we expect it to be. I still didn't see any good
>> reason not to make it a loadable module.
>
> Sure, conceptually there's no real reason it shouldn't be *allowed* to
> be built as a module, but without all the necessary symbols exported, a
> tristate here is only going to make allmodconfig builds fail.

Have we already completely dismissed the idea of exporting the IOMMU
symbols needed to make this driver a loadable module? I think the most
problematic ones were around the DMA mapping stuff, but IOMMU could be
still a module. Anyway, I think we might be removing the DMA mapping
implementation from the driver as the opinion of few other reviewers
seemed to be that this is reserved only to arch code.

>>>> +static struct iommu_domain *ipu3_mmu_domain_alloc(unsigned int type)
>>>> +{
>>>> + struct ipu3_mmu_domain *mmu_dom;
>>>> + u32 pteval;
>>>> +
>>>> + if (WARN(type != IOMMU_DOMAIN_DMA,
>>>> +  "IPU3 MMU only supports DMA domains\n"))
>>>> + return NULL;
>>>> +
>>>> + mmu_dom = kzalloc(sizeof(*mmu_dom), GFP_KERNEL);
>>>> + if (!mmu_dom)
>>>> + return NULL;
>>>> +
>>>> + if (iommu_get_dma_cookie(_dom->domain))
>>>> + goto fail_domain;
>>>> +
>>>> + mmu_dom->domain.geometry.aperture_start = 0;
>>>> + mmu_dom->domain.geometry.aperture_end =
>>>> + DMA_BIT_MASK(IPU3_MMU_ADDRESS_BITS);
>>>> + mmu_dom->domain.geometry.force_aperture = true;
>>>> +
>>>> + /*
>>>> +  * The MMU does not have a "valid" bit, so we have to use a dummy
>>>> +  * page for invalid entries.
>>>> +  */
>>>> + mmu_dom->dummy_page = kzalloc(IPU3_PAGE_SIZE, GFP_KERNEL);
>>>> + if (!mmu_dom->dummy_page)
>>>> + goto fail_cookie;
>>>> + pteval = IPU3_ADDR2PTE(virt_to_phys(mmu_dom->dummy_page));
>>>> + mmu_dom->dummy_page_pteval = pteval;
>>>
>>> Conceptually, would it make sense for the dummy page to be per-mmu,
>>> rather than per-domain? I realise it doesn't make much practical
>>> difference if you only expect to ever use a single DMA ops domain, but
>>> it would neatly mirror existing drivers which do a similar thing (e.g.
>>> the Mediatek IOMMUs).
>>
>> It makes it a bit complicated to achieve correctness against the IOMMU
>> API, because it would leave the page tables invalid if the domain is
>> detached from the MMU.
>
> In general, I'm not convinced it's sane for anyone to be calling
> iommu_map/unmap on a domain that isn't live. However, since this driver
> only supports DMA ops domains anyway, I don't s

Re: [PATCH v1] media: ov13858: Correct link-frequency and pixel-rate

2017-07-28 Thread Tomasz Figa
Hi Chiranjeevi,

On Sat, Jul 29, 2017 at 3:48 AM, Chiranjeevi Rapolu
 wrote:
> Previously both link-frequency and pixel-rate reported by
> the sensor was incorrect, resulting in incorrect FPS.
> Report link-frequency in Hz rather than link data rate in bps.
> Calculate pixel-rate from link-frequency.
>
> Signed-off-by: Chiranjeevi Rapolu 
> ---
>  drivers/media/i2c/ov13858.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
> index 86550d8..2a5bb43 100644
> --- a/drivers/media/i2c/ov13858.c
> +++ b/drivers/media/i2c/ov13858.c
> @@ -60,8 +60,8 @@
>  #define OV13858_VBLANK_MIN 56
>
>  /* HBLANK control - read only */
> -#define OV13858_PPL_540MHZ 2244
> -#define OV13858_PPL_1080MHZ4488
> +#define OV13858_PPL_270MHZ 2244
> +#define OV13858_PLL_540MHZ 4488

typo? "PPL" seems correct, because it's supposed to be pixels per line.

>
>  /* Exposure control */
>  #define OV13858_REG_EXPOSURE   0x3500
> @@ -944,31 +944,33 @@ struct ov13858_mode {
>
>  /* Configurations for supported link frequencies */
>  #define OV13858_NUM_OF_LINK_FREQS  2
> -#define OV13858_LINK_FREQ_1080MBPS 108000
> -#define OV13858_LINK_FREQ_540MBPS  54000
> +#define OV13858_LINK_FREQ_540MHZ   54000
> +#define OV13858_LINK_FREQ_270MHZ   27000
>  #define OV13858_LINK_FREQ_INDEX_0  0
>  #define OV13858_LINK_FREQ_INDEX_1  1
>
>  /* Menu items for LINK_FREQ V4L2 control */
>  static const s64 link_freq_menu_items[OV13858_NUM_OF_LINK_FREQS] = {
> -   OV13858_LINK_FREQ_1080MBPS,
> -   OV13858_LINK_FREQ_540MBPS
> +   OV13858_LINK_FREQ_540MHZ,
> +   OV13858_LINK_FREQ_270MHZ
>  };
>
>  /* Link frequency configs */
>  static const struct ov13858_link_freq_config
> link_freq_configs[OV13858_NUM_OF_LINK_FREQS] = {
> {
> -   .pixel_rate = 86400,
> -   .pixels_per_line = OV13858_PPL_1080MHZ,
> +   /* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample 
> */
> +   .pixel_rate = ((uint64_t)OV13858_LINK_FREQ_540MHZ * 2 * 4) / 
> 10,

Instead of this cast, you can just define OV13858_LINK_FREQ_540MHZ to
be 54000ULL.

> +   .pixels_per_line = OV13858_PLL_540MHZ,

s/PLL/PPL/?

> .reg_list = {
> .num_of_regs = ARRAY_SIZE(mipi_data_rate_1080mbps),
> .regs = mipi_data_rate_1080mbps,
> }
> },
> {
> -   .pixel_rate = 43200,
> -   .pixels_per_line = OV13858_PPL_540MHZ,
> +   /* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample 
> */
> +   .pixel_rate = ((uint64_t)OV13858_LINK_FREQ_270MHZ * 2 * 4) / 
> 10,

Ditto.

> +   .pixels_per_line = OV13858_PPL_270MHZ,
> .reg_list = {
> .num_of_regs = ARRAY_SIZE(mipi_data_rate_540mbps),
> .regs = mipi_data_rate_540mbps,
> @@ -1634,10 +1636,10 @@ static int ov13858_init_controls(struct ov13858 
> *ov13858)
>
> ov13858->hblank = v4l2_ctrl_new_std(
> ctrl_hdlr, _ctrl_ops, V4L2_CID_HBLANK,
> -   OV13858_PPL_1080MHZ - 
> ov13858->cur_mode->width,
> -   OV13858_PPL_1080MHZ - 
> ov13858->cur_mode->width,
> +   OV13858_PLL_540MHZ - ov13858->cur_mode->width,
> +   OV13858_PLL_540MHZ - ov13858->cur_mode->width,
> 1,
> -   OV13858_PPL_1080MHZ - 
> ov13858->cur_mode->width);
> +   OV13858_PLL_540MHZ - 
> ov13858->cur_mode->width);

Ditto.

Best regards,
Tomasz


Re: [PATCH 0/2] Add V4L2_BUF_TYPE_META_OUTPUT buffer type

2017-08-21 Thread Tomasz Figa
Hi Sakari,

On Sat, Aug 19, 2017 at 6:30 AM, Sakari Ailus
<sakari.ai...@linux.intel.com> wrote:
> Hi folks,
>
> Here's a non-RFC version of the META_OUTPUT buffer type patches.
>
> The V4L2_BUF_TYPE_META_OUTPUT buffer type complements the metadata buffer
> types support for OUTPUT buffers, capture being already supported. This is
> intended for similar cases than V4L2_BUF_TYPE_META_CAPTURE but for output
> buffers, e.g. device parameters that may be complex and highly
> hierarchical data structure. Statistics are a current use case for
> metadata capture buffers.
>
> Yong: could you take these to your IPU3 ImgU patchset, please? As that
> would be the first user, the patches would be merged with the driver
> itself.
>
> since RFC:
>
> - Fix make htmldocs build.
>
> - Fix CAPTURE -> OUTPUT in buffer.rst.
>
> - Added " for specifying how the device processes images" in the
>   documentation.
>
> Sakari Ailus (2):
>   v4l: Add support for V4L2_BUF_TYPE_META_OUTPUT
>   docs-rst: v4l: Document V4L2_BUF_TYPE_META_OUTPUT interface
>
>  Documentation/media/uapi/v4l/buffer.rst  |  3 +++
>  Documentation/media/uapi/v4l/dev-meta.rst| 33 
> ++--
>  Documentation/media/uapi/v4l/vidioc-querycap.rst |  3 +++
>  Documentation/media/videodev2.h.rst.exceptions   |  2 ++
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c|  2 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 ++
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  1 +
>  include/media/v4l2-ioctl.h   | 17 
>  include/uapi/linux/videodev2.h   |  2 ++
>  9 files changed, 75 insertions(+), 13 deletions(-)

For the whole series:
Reviewed-by: Tomasz Figa <tf...@chromium.org>

Best regards,
Tomasz


Re: [RFC v4 10/18] vb2: dma-contig: Fix DMA attribute and cache management

2017-05-10 Thread Tomasz Figa
Hi Sakari,

Some comments inline.

On Mon, May 8, 2017 at 11:03 PM, Sakari Ailus
 wrote:
> Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
> attrs") added support for driver specific DMA attributes to
> videobuf2-dma-contig but it had several issues in it.
>
> In particular,
>
> - cache operations were only performed on USERPTR buffers,
>
> - DMA attributes were set only for MMAP buffers and
>
> - it did not provide begin_cpu_access() and end_cpu_access() dma_buf_ops
>   callbacks for cache syncronisation on exported MMAP buffers.
>
> This patch corrects these issues.

I think the above are not really issues for the use cases the original
commit added the support for, i.e. disabling kernel mapping. There was
no intention of allowing cached MMAP buffers. Although I guess the
code added by it was not strict enough and didn't check the flags for
allowed ones.

>
> Also arrange the header files alphabetically.
>
> Fixes: ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA attrs")
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 94 
> --
>  1 file changed, 72 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 0afc3da..8b0298a 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -11,12 +11,12 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>
>  #include 
>  #include 
> @@ -97,12 +97,13 @@ static void vb2_dc_prepare(void *buf_priv)
> struct vb2_dc_buf *buf = buf_priv;
> struct sg_table *sgt = buf->dma_sgt;
>
> -   /* DMABUF exporter will flush the cache for us */

Ah, this annoying comment goes away here! Thanks and sorry for the
noise in previous patch.

> -   if (!buf->vec)
> -   return;
> -
> -   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
> -  buf->dma_dir);
> +   /*
> +* DMABUF exporter will flush the cache for us; only USERPTR
> +* and MMAP buffers with non-coherent memory will be flushed.
> +*/

Sounds much better.

> +   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)

Hmm, we change it for USERPTR to rely on presence of
DMA_ATTR_NON_CONSISTENT in buf->attrs, but I don't see it being set
for such anywhere by previous patches.

> +   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
> +  buf->dma_dir);
>  }
>
>  static void vb2_dc_finish(void *buf_priv)
> @@ -110,11 +111,13 @@ static void vb2_dc_finish(void *buf_priv)
> struct vb2_dc_buf *buf = buf_priv;
> struct sg_table *sgt = buf->dma_sgt;
>
> -   /* DMABUF exporter will flush the cache for us */
> -   if (!buf->vec)
> -   return;
> -
> -   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, 
> buf->dma_dir);
> +   /*
> +* DMABUF exporter will flush the cache for us; only USERPTR
> +* and MMAP buffers with non-coherent memory will be flushed.
> +*/
> +   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)

Ditto.

> +   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
> +   buf->dma_dir);
>  }
>
>  /*/
> @@ -142,6 +145,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
> long attrs,
>   gfp_t gfp_flags)
>  {
> struct vb2_dc_buf *buf;
> +   int ret;
>
> if (WARN_ON(!dev))
> return ERR_PTR(-EINVAL);
> @@ -152,9 +156,9 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
> long attrs,
>
> buf->attrs = attrs;
> buf->cookie = dma_alloc_attrs(dev, size, >dma_addr,
> -   GFP_KERNEL | gfp_flags, buf->attrs);
> + GFP_KERNEL | gfp_flags, buf->attrs);

White space change, not sure if intended.

> if (!buf->cookie) {
> -   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> +   dev_err(dev, "dma_alloc_attrs of size %ld failed\n", size);
> kfree(buf);
> return ERR_PTR(-ENOMEM);
> }
> @@ -167,6 +171,16 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
> long attrs,
> buf->size = size;
> buf->dma_dir = dma_dir;
>
> +   ret = dma_get_sgtable_attrs(buf->dev, >__dma_sgt, buf->cookie,
> +   buf->dma_addr, buf->size, buf->attrs);
> +   if (ret < 0) {
> +   dma_free_attrs(dev, size, buf->cookie, buf->dma_addr,
> +  buf->attrs);
> +   put_device(dev);
> +   return ERR_PTR(-ENOMEM);
> +   

  1   2   3   4   >