date:20140917

On 2014년 09월 17일 15:35, Andrzej Hajda wrote:
 Hi,
 
 On 09/16/2014 08:35 AM, Daniel Vetter wrote:
 On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote:
 Pageflipping currently causes some inconsistencies that lead to
 crashes. Just run an app that causes a CRTC pageflip in a raw X session
 and check that it exits cleanly and can be restarted - you'll see
 crashes like:
  Unable to handle kernel NULL pointer dereference at virtual address 
 0334
  PC is at exynos_drm_crtc_plane_commit+0x20/0x40
  LR is at exynos_drm_crtc_plane_commit+0x20/0x40
  [c03749b4] (exynos_drm_crtc_plane_commit) from [c03741bc] 
 (exynos_drm_crtc_commit+0x44/0x70)
  [c03741bc] (exynos_drm_crtc_commit) from [c03743a0] 
 (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
  [c03743a0] (exynos_drm_crtc_mode_set_commit.isra.2) from [c03744f4] 
 (exynos_drm_crtc_page_flip+0x140/0x1a8)
  [c03744f4] (exynos_drm_crtc_page_flip) from [c036b20c] 
 (drm_mode_page_flip_ioctl+0x224/0x2dc)
  [c036b20c] (drm_mode_page_flip_ioctl) from [c035c324] 
 (drm_ioctl+0x338/0x4fc)

 These crashes happen because drm_plane_force_disable has previously set
 plane-crtc to NULL.

 When drm_mode_page_flip_ioctl() is used to flip another framebuffer
 onto the primary plane, crtc-primary-fb is correctly updated (this is
 a virtual plane created by plane_helper), but plane-fb is not (this
 plane is the real one, created by exynos_drm_crtc_create).

 We then come to handle rmfb of the backbuffer, which the real primary
 plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
 the buffer is actually active on a plane and force-disables the plane.

 Ensuring that plane-fb is kept up-to-date solves that issue, but
 exposes a reference counting problem. Now we see crashes when rmfb is
 called on the front-buffer, because the rmfb code expects to drop 3
 references here, and there are only 2.

 That can be fixed by adopting the reference management found in omapdrm:
 Framebuffer references are not taken directly in crtc mode_set context,
 but rather in the context of updating the plane, which also covers
 flips. Like omapdrm we also unreference the old framebuffer here.

 Signed-off-by: Daniel Drake dr...@endlessm.com
 This sounds very much like exynos should switch to universal planes so
 that the fake primary plane created by the helpers doesn't get in the way.
 And for chips which already use planes for everything internally this
 shouldn't be a lot more than a few lines.
 -Daniel
 
 The patch proposed here of course supersedes my patch fixing fb refcounting.
 But the best solution is to get rid of virtual plane as Daniel Vetter
 stated.
 Daniel (Drake of course :) ) do you want to prepare patch switching to
 universal planes?
 Maybe other volunteers? If not I can try to do it, as it seems quite
 straightforward.

I think you can do it and you would be a right person to do it.

Thanks,
Inki Dae

 
 Regards
 Andrzej
 
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
  drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
  2 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..7aa9dee 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
 if (manager-ops-mode_set)
 manager-ops-mode_set(manager, crtc-mode);
  
 -   ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -   x, y, crtc_w, crtc_h);
 -   if (ret)
 -   return ret;
 -
 -   plane-crtc = crtc;
 -   plane-fb = crtc-primary-fb;
 -   drm_framebuffer_reference(plane-fb);
 -
 -   return 0;
 +   return exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0,
 +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
 b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 index 8371cbd..df27e35 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, 
 struct drm_crtc *crtc,
 overlay-crtc_x, overlay-crtc_y,
 overlay-crtc_width, overlay-crtc_height);
  
 +   if (plane-fb)
 +   drm_framebuffer_unreference(plane-fb);
 +
 +   drm_framebuffer_reference(fb);
 +
 +   plane-fb = fb;
 +   plane-crtc = crtc;
 +
 exynos_drm_crtc_plane_mode_set(crtc, overlay);
  
 return 0;
 -- 
 1.9.1

 ___
 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

Re: [PATCH] drm/exynos: fix plane-framebuffer linkage

2014-09-17 Thread Joonyoung Shim

Hi,

On 09/17/2014 03:49 PM, Inki Dae wrote:
 On 2014년 09월 17일 15:35, Andrzej Hajda wrote:
 Hi,

 On 09/16/2014 08:35 AM, Daniel Vetter wrote:
 On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote:
 Pageflipping currently causes some inconsistencies that lead to
 crashes. Just run an app that causes a CRTC pageflip in a raw X session
 and check that it exits cleanly and can be restarted - you'll see
 crashes like:
  Unable to handle kernel NULL pointer dereference at virtual address 
 0334
  PC is at exynos_drm_crtc_plane_commit+0x20/0x40
  LR is at exynos_drm_crtc_plane_commit+0x20/0x40
  [c03749b4] (exynos_drm_crtc_plane_commit) from [c03741bc] 
 (exynos_drm_crtc_commit+0x44/0x70)
  [c03741bc] (exynos_drm_crtc_commit) from [c03743a0] 
 (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
  [c03743a0] (exynos_drm_crtc_mode_set_commit.isra.2) from [c03744f4] 
 (exynos_drm_crtc_page_flip+0x140/0x1a8)
  [c03744f4] (exynos_drm_crtc_page_flip) from [c036b20c] 
 (drm_mode_page_flip_ioctl+0x224/0x2dc)
  [c036b20c] (drm_mode_page_flip_ioctl) from [c035c324] 
 (drm_ioctl+0x338/0x4fc)

 These crashes happen because drm_plane_force_disable has previously set
 plane-crtc to NULL.

 When drm_mode_page_flip_ioctl() is used to flip another framebuffer
 onto the primary plane, crtc-primary-fb is correctly updated (this is
 a virtual plane created by plane_helper), but plane-fb is not (this
 plane is the real one, created by exynos_drm_crtc_create).

 We then come to handle rmfb of the backbuffer, which the real primary
 plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
 the buffer is actually active on a plane and force-disables the plane.

 Ensuring that plane-fb is kept up-to-date solves that issue, but
 exposes a reference counting problem. Now we see crashes when rmfb is
 called on the front-buffer, because the rmfb code expects to drop 3
 references here, and there are only 2.

 That can be fixed by adopting the reference management found in omapdrm:
 Framebuffer references are not taken directly in crtc mode_set context,
 but rather in the context of updating the plane, which also covers
 flips. Like omapdrm we also unreference the old framebuffer here.

 Signed-off-by: Daniel Drake dr...@endlessm.com
 This sounds very much like exynos should switch to universal planes so
 that the fake primary plane created by the helpers doesn't get in the way.
 And for chips which already use planes for everything internally this
 shouldn't be a lot more than a few lines.
 -Daniel

 The patch proposed here of course supersedes my patch fixing fb refcounting.
 But the best solution is to get rid of virtual plane as Daniel Vetter
 stated.
 Daniel (Drake of course :) ) do you want to prepare patch switching to
 universal planes?
 Maybe other volunteers? If not I can try to do it, as it seems quite
 straightforward.
 
 I think you can do it and you would be a right person to do it.
 
 Thanks,
 Inki Dae
 

 Regards
 Andrzej

 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
  drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
  2 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..7aa9dee 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
if (manager-ops-mode_set)
manager-ops-mode_set(manager, crtc-mode);
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 -  if (ret)
 -  return ret;
 -
 -  plane-crtc = crtc;
 -  plane-fb = crtc-primary-fb;
 -  drm_framebuffer_reference(plane-fb);

It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.
Chip specific drm driver internally doesn't have to care fb reference count if
there is no special case. We should have switched to universal plane at that
time.

Thanks.

 -
 -  return 0;
 +  return exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
 b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 index 8371cbd..df27e35 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, 
 struct drm_crtc *crtc,
overlay-crtc_x, overlay-crtc_y,
overlay-crtc_width, overlay-crtc_height);
  
 +  if (plane-fb)
 +  drm_framebuffer_unreference(plane-fb);
 +
 +  drm_framebuffer_reference(fb);
 +
 +  plane-fb = fb;
 +  plane-crtc = crtc;
 +

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

Hello Doug,

On Wed, Sep 17, 2014 at 12:15 AM, Doug Anderson diand...@chromium.org wrote:

 I think you can turn off CONFIG_COMMON_CLK_MAX77686 and then this
 clock will be left at whatever the bootloader set it to, right?  Then
 there will be no auto-disabling by the CCF and the RTC will work.

Yes, that's how Daniel was working around the issue.

 That's one argument for making the clock optional.


Indeed.

 NOTE: I don't think that the builtin RTC is terribly important for any
 exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
 part of the Maxim PMIC itself and pretty much ignore the one built-in
 to the exynos.  I think there are some cases it was used (as a
 fallback wakeup source in certain test scripts), but nothing very
 important.


Ok, I'll post the patch I shared before that makes the rtc to claim
the max77802 32kHz clock as rtc_src anyways since that is the right
thing to do even if the rtc_src ends being optional due DT backward
compat.

 -Doug

Best regards,
Javier
--
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

Re: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.

2014-09-17 Thread Vikas Sajjan

Hi,

On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee jonghwa3@samsung.com wrote:
 Add rtc alarm and tick irq to wakeup sources in exynos3250.

 Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
 Acked-by : Chanwoo choi cw00.c...@samsung.com
 ---
  arch/arm/mach-exynos/pm.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
 index fa7218a..d78dcf9 100644
 --- a/arch/arm/mach-exynos/pm.c
 +++ b/arch/arm/mach-exynos/pm.c
 @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {

  static u32 exynos_irqwake_intmask = 0x;

 +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
 +   { 105, BIT(1) }, /* RTC alarm */
 +   { 106, BIT(2) }, /* RTC tick */
 +   { /* sentinel */ },
 +};
 +
  static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
 { 76, BIT(1) }, /* RTC alarm */
 { 77, BIT(2) }, /* RTC tick */
 @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] 
 = {
  static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
  {
 const struct exynos_wkup_irq *wkup_irq;
 -
 if (soc_is_exynos5250())
 wkup_irq = exynos5250_wkup_irq;
 +   else if (soc_is_exynos3250())
 +   wkup_irq = exynos3250_wkup_irq;


Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
which refactors the pm.c to use DT based lookup.

[1] http://www.spinics.net/lists/arm-kernel/msg355266.html



 else
 wkup_irq = exynos4_wkup_irq;

 --
 1.7.9.5

 --
 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-samsung-soc 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 6/8] drm/bridge: Modify drm_bridge core to support driver model

Hi Laurent,

On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Ajay,

 Thank you for the patch.

 I think we're moving in the right direction, but we're not there yet.

 On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
 This patch tries to seperate drm_bridge implementation
 into 2 parts, a drm part and a non_drm part.

 A set of helper functions are defined in this patch to make
 bridge driver probe independent of the drm flow.

 The bridge devices register themselves on a lookup table
 when they get probed by calling drm_bridge_add_for_lookup.

 The parent encoder driver waits till the bridge is available in the
 lookup table(by calling of_drm_find_bridge) and then continues with
 its initialization.

 Before the introduction of the component framework I would have said this is
 the way to go. Now, I think bridges should register themselves as components,
 and the DRM master driver should use the component framework to get a
 reference to the bridges it needs.
Well, I have modified the bridge framework exactly the way Thierry wanted it
to be, I mean the same way the current panel framework is.
And, I don't think there is a problem with that.
What problem are you facing with current bridge implementation?
What is the advantage of using the component framework to register bridges?

 The encoder driver should call drm_bridge_attach_encoder to pass on
 the drm_device and the encoder pointers to the bridge object.

 Now that the drm_device pointer is available, the encoder then calls
 bridge-funcs-post_encoder_init to allow the bridge to continue
 registering itself with the drm core.

 This is what really bothers me with DRM bridge.

 The framework assumes that a bridge will always bridge an encoder and a
 connector. Beside lacking support for chained bridges, this creates an
 artificial split between bridges and encoders by modeling the same components
 using drm_encoder or drm_bridge depending on their position in the video
 output pipeline.

 I would like to see drm_bridge becoming more self-centric, removing the
 awareness of the upstream encoder and downstream connector. I'll give this a
 try, but it will conflict with this patch, so I'd like to share opinions and
 coordinate efforts sooner than later if possible.
I am not really able to understand how you want drm_bridge to be.
As of now, there are many platforms using drm_bridge and they don't
have a problem with current implementation.
Regarding chained bridges: Can't you add this once my patchset is merged?
As an additional feature?

To be honest, I have spent quite sometime for working on this patchset.
All I started with was to add drm_panel support to drm_bridge.
When I sent the first patchset for that, Daniel, Rob and Thierry raised a
concern that current bridge framework itself is not proper and hence
they asked me to fix that first. And we have reached till here based on
their comments only.

Without this patchset, you cannot bring an X server
based display on snow and peach_pit. Also, day by day the number of
platforms using drm_bridge is increasing. And, I don't really see a problem
with the current approach(which is exactly the same way panel framework is).
And, I am no decision maker here. I would expect the top guys to comment!

Ajay

 Also, non driver model based ptn3460 driver is removed in this patch.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 --
  drivers/gpu/drm/Makefile   |1 +
  drivers/gpu/drm/bridge/Kconfig |   12 +-
  drivers/gpu/drm/bridge/Makefile|2 -
  drivers/gpu/drm/bridge/ptn3460.c   |  343 -
  drivers/gpu/drm/drm_bridge.c   |   89 +
  drivers/gpu/drm/drm_crtc.c |9 +-
  drivers/gpu/drm/exynos/Kconfig |3 +-
  drivers/gpu/drm/exynos/exynos_dp_core.c|   57 ++--
  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +-
  include/drm/bridge/ptn3460.h   |   37 ---
  include/drm/drm_crtc.h |   16 +-
  13 files changed, 147 insertions(+), 453 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
  delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
  create mode 100644 drivers/gpu/drm/drm_bridge.c
  delete mode 100644 include/drm/bridge/ptn3460.h

 --
 Regards,

 Laurent Pinchart

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

Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

2014-09-17 Thread Dave Airlie


 Before the introduction of the component framework I would have said this is
 the way to go. Now, I think bridges should register themselves as components,
 and the DRM master driver should use the component framework to get a
 reference to the bridges it needs.
 Well, I have modified the bridge framework exactly the way Thierry wanted it
 to be, I mean the same way the current panel framework is.
 And, I don't think there is a problem with that.
 What problem are you facing with current bridge implementation?
 What is the advantage of using the component framework to register bridges?

At this point I'd rather merge something that keep iterating out of
tree, if this enables current hw to work and is better than what we
have we should merge it, and if we can get interest in using the
component framework then we should look at that as a separate problem.

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

Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

2014-09-17 Thread Laurent Pinchart

Hi Ajay,

On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
 On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
  Hi Ajay,
  
  Thank you for the patch.
  
  I think we're moving in the right direction, but we're not there yet.
  
  On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
  This patch tries to seperate drm_bridge implementation
  into 2 parts, a drm part and a non_drm part.
  
  A set of helper functions are defined in this patch to make
  bridge driver probe independent of the drm flow.
  
  The bridge devices register themselves on a lookup table
  when they get probed by calling drm_bridge_add_for_lookup.
  
  The parent encoder driver waits till the bridge is available in the
  lookup table(by calling of_drm_find_bridge) and then continues with
  its initialization.
  
  Before the introduction of the component framework I would have said this
  is the way to go. Now, I think bridges should register themselves as
  components, and the DRM master driver should use the component framework
  to get a reference to the bridges it needs.
 
 Well, I have modified the bridge framework exactly the way Thierry wanted it
 to be, I mean the same way the current panel framework is.
 And, I don't think there is a problem with that.
 What problem are you facing with current bridge implementation?
 What is the advantage of using the component framework to register bridges?

There are several advantages.

- The component framework has been designed with this exact problem in mind, 
piecing multiple components into a display device. This patch set introduces 
yet another framework, without any compelling reason as far as I can see. 
Today DRM drivers already need to use three different frameworks (component, 
I2C slave encoder and panel), and we're adding a fourth one to make the mess 
even messier. This is really a headlong rush, we need to stop and fix the 
design mistakes.

- The component framework solves the probe ordering problem. Bridges can use 
deferred probing, but when a bridge requires a resources (such as a clock for 
instance) provided by the display controller, this will break.

  The encoder driver should call drm_bridge_attach_encoder to pass on
  the drm_device and the encoder pointers to the bridge object.
  
  Now that the drm_device pointer is available, the encoder then calls
  bridge-funcs-post_encoder_init to allow the bridge to continue
  registering itself with the drm core.
  
  This is what really bothers me with DRM bridge.
  
  The framework assumes that a bridge will always bridge an encoder and a
  connector. Beside lacking support for chained bridges, this creates an
  artificial split between bridges and encoders by modeling the same
  components using drm_encoder or drm_bridge depending on their position in
  the video output pipeline.
  
  I would like to see drm_bridge becoming more self-centric, removing the
  awareness of the upstream encoder and downstream connector. I'll give this
  a try, but it will conflict with this patch, so I'd like to share
  opinions and coordinate efforts sooner than later if possible.
 
 I am not really able to understand how you want drm_bridge to be.
 As of now, there are many platforms using drm_bridge and they don't
 have a problem with current implementation.
 Regarding chained bridges: Can't you add this once my patchset is merged?
 As an additional feature?

Yes, as I mentioned in another e-mail this can be fixed later. I want to start 
discussing it though.

 To be honest, I have spent quite sometime for working on this patchset.
 All I started with was to add drm_panel support to drm_bridge.
 When I sent the first patchset for that, Daniel, Rob and Thierry raised a
 concern that current bridge framework itself is not proper and hence
 they asked me to fix that first. And we have reached till here based on
 their comments only.
 
 Without this patchset, you cannot bring an X server
 based display on snow and peach_pit. Also, day by day the number of
 platforms using drm_bridge is increasing.

That's exactly why I'd like to use the component framework now, as the 
conversion will become more complex as time goes by.

 And, I don't really see a problem with the current approach(which is exactly
 the same way panel framework is). And, I am no decision maker here. I would
 expect the top guys to comment!

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support

On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 [adding Laurent Pinchart to cc who had concerns with a previous
 version of this patch-set]

 Hello Ajay,

 On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
 This series is based on master branch of Linus tree at:
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

 I have tested this after adding few DT changes for exynos5250-snow and
 exynos5420-peach-pit boards.

 The V4 series of this particular patchset was also tested by:
 Rahul Sharma rahul.sha...@samsung.com
 Javier Martinez Canillas jav...@dowhile0.org

 Changes since V2:
 -- Address comments from Jingoo Han for ps8622 driver
 -- Address comments from Daniel, Rob and Thierry regarding
bridge chaining
 -- Address comments from Thierry regarding the names for
new drm_panel functions

 Changes since V3:
 -- Remove hotplug based initialization of exynos_dp
 -- Make exynos_dp work directly with drm_panel, remove
dependency on panel_binder
 -- Minor cleanups in panel_binder and panel_lvds driver

 Changes since V4:
 -- Use gpiod interface for panel-lvds and ps8622 drivers.
 -- Address comments from Javier.
 -- Fix compilation issues when PANEL_BINDER is selected as module.
 -- Split Documentation patches from driver patches.
 -- Rebase on top of the tree.

 Changes since V5:
 -- Modify bridge drivers to support driver model.
 -- Drop the concept of bridge chain(sincle there are no 2 real 
 bridges)
Hence drop bridge-panel_binder layer.
 -- Drop panel-lvds driver and accomodate the required changes in
panel-simple driver.
 -- Use gpiod interface in ptn3460 driver.
 -- Address all comments by Thierry Reding for V5 series.
 -- Address comments from Sean Paul for exynos_dp_commit issue.

 Changes since V6:
 -- Panel patches were seperated and they are merged already.
 -- Fix few issues with ptn3460, before modifying the bridge core.
 -- Modify drm_bridge as per Thierry's comments for V6 series.
 -- Add drm_bridge changes minimally without breaking existing code.
 -- Add new features for ptn3460, step-by-step.
 -- Address comments from Thierry and Andreas for ptn3460 and ps8622.
 -- Split documentation patches from driver patches.


 I've tested your series on an Exynos5420 Peach Pit and an Exynos5250
 Snow Chromebooks and display worked for me on both machines.
Great!

 I also needed [PATCH] drm/panel: simple: Add AUO B116XW03 panel
 support [0] which does not apply cleanly on linux-next so you may
 want to do a re-spin for that patch.
Ok. I will take care of this in next version.

 For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw
 a blink on boot and only the backlight remained turned on (no display
 output). I don't know if that is expected since IIUC it should be
 possible to do a transition from simplefb to a DRM/KMS driver. I don't
 have a serial console hooked on this machine so I couldn't debug it
 further, sorry.
I am just wondering how SIMPLE FB can affect DRM based display.
I am not even sure if both can co-exist or not. Is there anything
we can do with bootargs instead of CONFIG?

Ajay

 Also, I saw that Laurent mentioned some concerns today about the
 previous version (v6) of your series [1]. I guess he missed this v7
 although AFAIU there was no fundamental change on this one so his
 concerns remains? I was really hoping that this could make it to 3.18
 since display support is one of the last major functionalities that is
 missing on these machines.

 Best regards,
 Javier

 [0]: http://patchwork.ozlabs.org/patch/384744/
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html
--
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

Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

2014-09-17 Thread Laurent Pinchart

Hi Thierry,

On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
 On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
  On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
   On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
   Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree
at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
git

I have tested this after adding few DT changes for
exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.

I'm trying to test this with a modified exynos5250-spring DT
   
   [...]
   
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.

Do I need to specify a specific panel model for Spring?
   
   [...]
   
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---

 arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts index
687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
   vdd_pll-supply = s5m_ldo8_reg;
   };

+  panel: panel {
+  compatible = simple-panel;
+  };

You can't do this. simple-panel isn't a valid panel model. It
should probably be removed from the platform_of_match table in the
driver.
   
   Okay, that means the Snow DT is wrong, too:
   https://patchwork.kernel.org/patch/4625441/
   
   And the others specify it as fallback:
   https://patchwork.kernel.org/patch/4625461/
   https://patchwork.kernel.org/patch/4625451/
   
   A quick grep shows that many (all?) devices that use DRM panels provide
   simple-panel as fallback. That's probably fine as long as they also do
   provide the specific model. But given that simple-panel does not have a
   mode or physical size, I don't think even that makes sense.
  
  On snow, the bridge chip provides the display mode instead of the panel.
  That is why display was working for me.
 
 Okay, I suppose under some circumstances that might make sense. Although
 it's still always the panel that dictates the display timings, so the
 panel node needs to have a panel model specific compatible value with a
 matching entry in the panel-simple driver so that it can even be used in
 setups without a bridge.
 
 One other thing: how does the bridge know which mode to drive? I suspect
 that it can drive more than one mode? Can it freely be configured or
 does it have a predefined set of modes? If the latter, then according to
 what you said above there needs to be a way to configure the bridge (via
 DT?) so that it reports the mode matching the panel. I wonder if that
 should be handled completely in code, so that for example a bridge has a
 panel attached it can use the panel's .get_modes() and select a matching
 mode among the set that it supports.

Yes, pretty please :-) I don't think it would be a good idea to duplicate mode 
information in the bridge DT node, as that's not a property of the bridge. 
Querying the mode at runtime is in my opinion a much better option, and would 
also allow switching between different modes at runtime when that makes sense.

Now, I'm not sure whether it should be the bridge driver querying the panel 
driver directly, or the display controller driver doing it and then 
configuring the bridge accordingly. The latter seems more generic to me and 
doesn't rely on the assumption that the bridge output will always be directly 
connected to a panel.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Dong Aisheng

On Wed, Sep 17, 2014 at 12:01:50PM +0530, Pankaj Dubey wrote:
 Currently a syscon entity can be only registered directly through a
 platform device that binds to a dedicated syscon driver. However in
 certain use cases it is desirable to make a device used with another
 driver a syscon interface provider.
 
 For example, certain SoCs (e.g. Exynos) contain system controller
 blocks which perform various functions such as power domain control,
 CPU power management, low power mode control, but in addition contain
 certain IP integration glue, such as various signal masks,
 coprocessor power control, etc. In such case, there is a need to have
 a dedicated driver for such system controller but also share registers
 with other drivers. The latter is where the syscon interface is helpful.
 
 In case of DT based platforms, this patch decouples syscon object from
 syscon platform driver, and allows to create syscon objects first time
 when it is required by calling of syscon_regmap_lookup_by APIs and keep
 a list of such syscon objects along with syscon provider device_nodes
 and regmap handles.
 
 For non-DT based platforms, this patch keeps syscon platform driver
 structure where is can be probed and such non-DT based drivers can use
 syscon_regmap_lookup_by_pdev API and get access to regmap handles.
 Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
 we can completly remove platform driver of syscon, and keep only helper
 functions to get regmap handles.
 
 Suggested-by: Arnd Bergmann a...@arndb.de
 Suggested-by: Tomasz Figa tomasz.f...@gmail.com
 Tested-by: Vivek Gautam gautam.vi...@samsung.com
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
 V2 of this patchset and related discussion can be found here [1].
 
 Changes since v2:
  - Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
  - Removed unwanted change in syscon.h.
  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
 
 Changes since v1:
  - Removed of_syscon_unregister function.
  - Modified of_syscon_register function and it will be used by syscon.c 
to create syscon objects whenever required. 
  - Removed platform device support from syscon.
  - Removed syscon_regmap_lookup_by_pdevname API support.
  - As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
 
 [1]: https://lkml.org/lkml/2014/9/2/299
 
  drivers/mfd/syscon.c |   78 
 --
  1 file changed, 57 insertions(+), 21 deletions(-)
 
 diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
 index ca15878..4a4bad9 100644
 --- a/drivers/mfd/syscon.c
 +++ b/drivers/mfd/syscon.c
 @@ -15,40 +15,49 @@
  #include linux/err.h
  #include linux/io.h
  #include linux/module.h
 +#include linux/list.h
  #include linux/of.h
  #include linux/of_address.h
 -#include linux/of_platform.h
  #include linux/platform_data/syscon.h
  #include linux/platform_device.h
  #include linux/regmap.h
  #include linux/mfd/syscon.h
 +#include linux/slab.h
  
  static struct platform_driver syscon_driver;
  
 +static DEFINE_SPINLOCK(syscon_list_slock);
 +static LIST_HEAD(syscon_list);
 +
  struct syscon {
 + struct device_node *np;
   struct regmap *regmap;
 + struct list_head list;
  };
  
 -static int syscon_match_node(struct device *dev, void *data)
 -{
 - struct device_node *dn = data;
 -
 - return (dev-of_node == dn) ? 1 : 0;
 -}
 +static struct syscon *of_syscon_register(struct device_node *np);
  
  struct regmap *syscon_node_to_regmap(struct device_node *np)
  {
 - struct syscon *syscon;
 - struct device *dev;
 + struct syscon *entry, *syscon = NULL;
  
 - dev = driver_find_device(syscon_driver.driver, NULL, np,
 -  syscon_match_node);
 - if (!dev)
 - return ERR_PTR(-EPROBE_DEFER);
 + spin_lock(syscon_list_slock);
  
 - syscon = dev_get_drvdata(dev);
 + list_for_each_entry(entry, syscon_list, list)
 + if (entry-np == np) {
 + syscon = entry;
 + break;
 + }
  
 - return syscon-regmap;
 + spin_unlock(syscon_list_slock);
 +
 + if (!syscon)
 + syscon = of_syscon_register(np);
 +
 + if (!IS_ERR(syscon))
 + return syscon-regmap;
 +
 + return ERR_CAST(syscon);
  }
  EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
  
 @@ -110,17 +119,45 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct 
 device_node *np,
  }
  EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
  
 -static const struct of_device_id of_syscon_match[] = {
 - { .compatible = syscon, },
 - { },
 -};
 -
  static struct regmap_config

Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Laurent,

Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html

On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Thierry,

 On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
 On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
  On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
   On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
   Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree
at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
git
   
I have tested this after adding few DT changes for
exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
   
I'm trying to test this with a modified exynos5250-spring DT
  
   [...]
  
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
   
Do I need to specify a specific panel model for Spring?
  
   [...]
  
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
   
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
   
 arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
 1 file changed, 31 insertions(+), 1 deletion(-)
   
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts index
687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
   vdd_pll-supply = s5m_ldo8_reg;
   };
   
+  panel: panel {
+  compatible = simple-panel;
+  };
   
You can't do this. simple-panel isn't a valid panel model. It
should probably be removed from the platform_of_match table in the
driver.
  
   Okay, that means the Snow DT is wrong, too:
   https://patchwork.kernel.org/patch/4625441/
  
   And the others specify it as fallback:
   https://patchwork.kernel.org/patch/4625461/
   https://patchwork.kernel.org/patch/4625451/
  
   A quick grep shows that many (all?) devices that use DRM panels provide
   simple-panel as fallback. That's probably fine as long as they also do
   provide the specific model. But given that simple-panel does not have a
   mode or physical size, I don't think even that makes sense.
 
  On snow, the bridge chip provides the display mode instead of the panel.
  That is why display was working for me.

 Okay, I suppose under some circumstances that might make sense. Although
 it's still always the panel that dictates the display timings, so the
 panel node needs to have a panel model specific compatible value with a
 matching entry in the panel-simple driver so that it can even be used in
 setups without a bridge.

 One other thing: how does the bridge know which mode to drive? I suspect
 that it can drive more than one mode? Can it freely be configured or
 does it have a predefined set of modes? If the latter, then according to
 what you said above there needs to be a way to configure the bridge (via
 DT?) so that it reports the mode matching the panel. I wonder if that
 should be handled completely in code, so that for example a bridge has a
 panel attached it can use the panel's .get_modes() and select a matching
 mode among the set that it supports.

 Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
 information in the bridge DT node, as that's not a property of the bridge.
 Querying the mode at runtime is in my opinion a much better option, and would
 also allow switching between different modes at runtime when that makes sense.

 Now, I'm not sure whether it should be the bridge driver querying the panel
 driver directly, or the display controller driver doing it and then
 configuring the bridge accordingly. The latter seems more generic to me and
 doesn't rely on the assumption that the bridge output will always be directly
 connected to a panel.

 --
 Regards,

 Laurent Pinchart

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

[PATCH v3 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/host/ohci-exynos.c |   89 +++-
 1 file changed, 24 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..992b28d 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include linux/of.h
 #include linux/platform_device.h
 #include linux/phy/phy.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-#include linux/usb/otg.h
 
 #include ohci.h
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -48,56 +43,40 @@ static int exynos_ohci_get_phy(struct device *dev,
 {
struct device_node *child;
struct phy *phy;
-   int phy_number;
-   int ret = 0;
+   int phy_num;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get the generic phys */
for_each_available_child_of_node(dev-of_node, child) {
-   ret = of_property_read_u32(child, reg, phy_number);
+   ret = of_property_read_u32(child, reg, phy_num);
if (ret) {
dev_err(dev, Failed to parse device tree\n);
of_node_put(child);
return ret;
}
 
-   if (phy_number = PHY_NUMBER) {
+   if (phy_num = PHY_NUMBER) {
dev_err(dev, Invalid number of PHYs\n);
of_node_put(child);
return -EINVAL;
}
 
-   phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci-phy[phy_num] = devm_of_phy_get(dev, child, NULL);
+   phy = exynos_ohci-phy[phy_num];
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci-phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci-phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci-phy)) {
-   ret = PTR_ERR(exynos_ohci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS  ret != -ENODEV) {
+   dev_err(dev,
+   Error retrieving usb2 phy: %d\n, ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ohci-otg = exynos_ohci-phy-otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci-phy))
-   return usb_phy_init(exynos_ohci-phy);
-
for (i = 0; ret == 0  i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci-phy_g[i]))
-   ret = phy_power_on(exynos_ohci-phy_g[i]);
+   if (!IS_ERR(exynos_ohci-phy[i]))
+   ret = phy_power_on(exynos_ohci-phy[i]);
if (ret)
for (i--; i = 0; i--)
-   if (!IS_ERR(exynos_ohci-phy_g[i]))
-   phy_power_off(exynos_ohci-phy_g[i]);
+   if (!IS_ERR(exynos_ohci-phy[i]))
+   phy_power_off(exynos_ohci-phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci-phy)) {
-

[PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/host/ehci-exynos.c |   81 
 1 file changed, 23 insertions(+), 58 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..99c5f5f 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include linux/of_gpio.h
 #include linux/phy/phy.h
 #include linux/platform_device.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-#include linux/usb/otg.h
 
 #include ehci.h
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
 {
struct device_node *child;
struct phy *phy;
-   int phy_number;
-   int ret = 0;
+   int phy_num;
+   int ret;
 
for_each_available_child_of_node(dev-of_node, child) {
-   ret = of_property_read_u32(child, reg, phy_number);
+   ret = of_property_read_u32(child, reg, phy_num);
if (ret) {
dev_err(dev, Failed to parse device tree\n);
of_node_put(child);
return ret;
}
 
-   if (phy_number = PHY_NUMBER) {
+   if (phy_num = PHY_NUMBER) {
dev_err(dev, Invalid number of PHYs\n);
of_node_put(child);
return -EINVAL;
}
 
-   phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci-phy[phy_num] = devm_of_phy_get(dev, child, NULL);
+   phy = exynos_ehci-phy[phy_num];
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci-phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci-phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci-phy)) {
-   ret = PTR_ERR(exynos_ehci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS  ret != -ENODEV) {
+   dev_err(dev,
+   Error retrieving usb2 phy: %d\n, ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ehci-otg = exynos_ehci-phy-otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +96,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci-phy))
-   return usb_phy_init(exynos_ehci-phy);
-
for (i = 0; ret == 0  i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   ret = phy_power_on(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+   ret = phy_power_on(exynos_ehci-phy[i]);
if (ret)
for (i--; i = 0; i--)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   phy_power_off(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+   phy_power_off(exynos_ehci-phy[i]);
 
return ret;
 }
@@ -131,14 +113,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci-phy)) {
-   usb_phy_shutdown(exynos_ehci-phy);
-   return;
-   }
-
for (i = 0; i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   phy_power_off(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+

RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Pankaj Dubey

Hi,

On Wednesday, September 17, 2014, Dong Aisheng Wrote,
 
  +static struct syscon *of_syscon_register(struct device_node *np) {
  +   struct syscon *syscon;
  +   struct regmap *regmap;
  +   void __iomem *base;
  +
  +   if (!of_device_is_compatible(np, syscon))
  +   return ERR_PTR(-EINVAL);
  +
  +   syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
  +   if (!syscon)
  +   return ERR_PTR(-ENOMEM);
  +
  +   base = of_iomap(np, 0);
  +   if (!base)
  +   return ERR_PTR(-ENOMEM);
  +
  +   regmap = regmap_init_mmio(NULL, base, syscon_regmap_config);
 
 Does a NULL device pointer work?

Yes, it is safe, at least we are able to test on Exynos based SoC. 
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
kernel
by Vivek Gautam. 

Patch V2 also has been tested by Borris Brezillon on AT91 platform.


 I just tested on MX6SX SDB board and it seemed crashed at here in
regmap_init
 function.
 

Can you please provide crash log which can give more information about the
crash?


Thanks,
Pankaj Dubey

 Regards
 Dong Aisheng
 
  +   if (IS_ERR(regmap)) {
  +   pr_err(regmap init failed\n);
  +   return ERR_CAST(regmap);
  +   }
  +
  +   syscon-regmap = regmap;
  +   syscon-np = np;
  +
  +   spin_lock(syscon_list_slock);
  +   list_add_tail(syscon-list, syscon_list);
  +   spin_unlock(syscon_list_slock);
  +
  +   return syscon;
  +}
  +
   static int syscon_probe(struct platform_device *pdev)  {
  struct device *dev = pdev-dev;
  @@ -167,7 +204,6 @@ static struct platform_driver syscon_driver = {
  .driver = {
  .name = syscon,
  .owner = THIS_MODULE,
  -   .of_match_table = of_syscon_match,
  },
  .probe  = syscon_probe,
  .id_table   = syscon_ids,
  --
  1.7.9.5
 
 
  ___
  linux-arm-kernel mailing list
  linux-arm-ker...@lists.infradead.org
  http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[PATCH v3 0/2] usb: host: ehci/ohci-exynos: phy cleanup

Cleaning up the phy getting sequence in ehci-exynos and ohci-exynos
drivers.

Hi Alan, Jingoo,

I have not imported the Acked-by and Reviewed-by from you guys, from V2 version
of this patch series, since this version is now rebased on the already available
commit in usb-next - usb: ehci/ohci-exynos: Fix PHY getting sequence.

Please feel free to comment on it and add your Acked-by's and Reviewed-by's.

Changes since v2:
 - Rebased on top of usb-next branch, which now has
   'usb: ehci/ohci-exynos: Fix PHY getting sequence' patch.

Changes since v1:
 - This patch was part of the series [PATCH 0/7] usb-phy: samsung: Cleanup the 
unused drivers
   https://lkml.org/lkml/2014/8/14/235. I have dropped the phy cleanup patches 
from that series-
   Patches 1-5.
 - Rebased this patch on top of 3.17-rc1.

Vivek Gautam (2):
  usb: host: ehci-exynos: Remove unnecessary usb-phy support
  usb: host: ohci-exynos: Remove unnecessary usb-phy support

 drivers/usb/host/ehci-exynos.c |   81 +++-
 drivers/usb/host/ohci-exynos.c |   89 +++-
 2 files changed, 47 insertions(+), 123 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH 0/9] drm/exynos: initialization/deinitialization fixes

On 2014년 09월 09일 22:16, Andrzej Hajda wrote:
 This set of patches contains fixes of initialization and deinitialization
 code of exynos_drm core and components.
 It is based on exynos-drm-next branch.
 
 Patchset has been tested on trats and universal_c210 platforms.

Applied all patches except patch #5. As of now, it seems good to merge
also patch #5 if you couldn't post next version of that patch until the
end of this week. In this case, I will have a pull request including
that patch so that we can fix it up correctly later. Give me your
opinion if there is other plan.

Thanks,
Inki Dae

 
 Regards
 Andrzej
 
 
 Andrzej Hajda (9):
   drm/exynos/ipp: traverse ipp drivers list safely
   drm/exynos: fix drm driver de-initialization order
   drm/exynos/fbdev: fix fbdev gem object cleanup
   drm/exynos/fb: free exynos framebuffer on error
   drm/exynos/crtc: fix framebuffer reference sequence
   drm/exynos/dsi: unregister connector on removal
   drm/exynos/dpi: unregister connector and panel on removal
   drm/exynos/dp: unregister connector on removal
   drm/exynos/hdmi: unregister connector on removal
 
  drivers/gpu/drm/exynos/exynos_dp_core.c   | 4 +++-
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 6 ++
  drivers/gpu/drm/exynos/exynos_drm_dpi.c   | 6 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 8 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 9 ++---
  drivers/gpu/drm/exynos/exynos_drm_fb.c| 1 +
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 4 ++--
  drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 +++-
  9 files changed, 30 insertions(+), 15 deletions(-)
 

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

[PATCH 0/2] s3c RTC fix for Exynos Chromebooks

Hello Kukjin,

commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
added an rtc_src DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as
its source clock but this breaks the s3c RTC on Exynos Chromebooks
because the rtc device node does not define the rtc_src clock.

It was working before only because the source clock was not disabled
by the kernel since the CCF didn't know about it. But once the clock
is known, the CCF disables the clock and does not work so define the
rtc_src clock to make the s3c-rtc driver obtain it and kept enabled.

This series makes the s3c RTC to claim its source clock on the Snow
and Peach boards but other Samsung boards will have the same issue.

The following patches are meant to be for the 3.18 rc cycle once
3.18-rc1 is released.

Javier Martinez Canillas (2):
  ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
  ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

 arch/arm/boot/dts/exynos5250-snow.dts  | 5 -
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 5 -
 3 files changed, 12 insertions(+), 3 deletions(-)

Best regards,
Javier
--
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

[PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
added an rtc_src DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as its
source clock. In the case of the Exynos5250 based Snow board, the Maxim
77686 32kHz AP clock is used as the source clock.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/exynos5250-snow.dts | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index e51fcef..56eec56 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 #include dt-bindings/gpio/gpio.h
+#include dt-bindings/clock/maxim,max77686.h
 #include exynos5250.dtsi
 
 / {
@@ -29,6 +30,8 @@
 
rtc@101E {
status = okay;
+   clocks = clock CLK_RTC, max77686 MAX77686_CLK_AP;
+   clock-names = rtc, rtc_src;
};
 
pinctrl@1140 {
@@ -350,7 +353,7 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
 
-   max77686@09 {
+   max77686: max77686@09 {
compatible = maxim,max77686;
interrupt-parent = gpx3;
interrupts = 2 0;
-- 
2.1.0

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

[PATCH 1/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards

commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
added an rtc_src DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as its
source clock. In the case of the Peach Pit and Pi machines, the Maxim
77802 32kHz AP clock is used as the source clock.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a23382..bfd189e 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -12,6 +12,7 @@
 #include dt-bindings/input/input.h
 #include dt-bindings/gpio/gpio.h
 #include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/clock/maxim,max77802.h
 #include exynos5420.dtsi
 
 / {
@@ -151,7 +152,7 @@
status = okay;
clock-frequency = 40;
 
-   max77802-pmic@9 {
+   max77802: max77802-pmic@9 {
compatible = maxim,max77802;
interrupt-parent = gpx3;
interrupts = 1 IRQ_TYPE_NONE;
@@ -727,6 +728,8 @@
 
 rtc {
status = okay;
+   clocks = clock CLK_RTC, max77802 MAX77802_CLK_32K_AP;
+   clock-names = rtc, rtc_src;
 };
 
 spi_2 {
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 1d31c81..84ec1ce 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -12,6 +12,7 @@
 #include dt-bindings/input/input.h
 #include dt-bindings/gpio/gpio.h
 #include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/clock/maxim,max77802.h
 #include exynos5800.dtsi
 
 / {
@@ -150,7 +151,7 @@
status = okay;
clock-frequency = 40;
 
-   max77802-pmic@9 {
+   max77802: max77802-pmic@9 {
compatible = maxim,max77802;
interrupt-parent = gpx3;
interrupts = 1 IRQ_TYPE_NONE;
@@ -715,6 +716,8 @@
 
 rtc {
status = okay;
+   clocks = clock CLK_RTC, max77802 MAX77802_CLK_32K_AP;
+   clock-names = rtc, rtc_src;
 };
 
 spi_2 {
-- 
2.1.0

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

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-09-17 Thread Tomi Valkeinen

On 27/08/14 17:39, Ajay Kumar wrote:
 Add documentation for DT properties supported by ps8622/ps8625
 eDP-LVDS converter.
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
 
  1 file changed, 20 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
 
 diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
 b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 new file mode 100644
 index 000..0ec8172
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 @@ -0,0 +1,20 @@
 +ps8622-bridge bindings
 +
 +Required properties:
 + - compatible: parade,ps8622 or parade,ps8625
 + - reg: first i2c address of the bridge
 + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
 + - reset-gpios: OF device-tree gpio specification for RST_ pin.
 +
 +Optional properties:
 + - lane-count: number of DP lanes to use
 + - use-external-pwm: backlight will be controlled by an external PWM

What does this mean? That the backlight support from ps8625 is not used?
If so, maybe disable-pwm or something?

 +
 +Example:
 + lvds-bridge@48 {
 + compatible = parade,ps8622;
 + reg = 0x48;
 + sleep-gpios = gpc3 6 1 0 0;
 + reset-gpios = gpc3 1 1 0 0;
 + lane-count = 1;
 + };
 

I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Jingoo Han

On Wednesday, September 17, 2014 8:18 PM, Vivek Gautam wrote:
 
 Now that we have completely moved from older USB-PHY drivers
 to newer GENERIC-PHY drivers for PHYs available with USB controllers
 on Exynos series of SoCs, we can remove the support for the same
 in our host drivers too.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/usb/host/ehci-exynos.c |   81 
 
  1 file changed, 23 insertions(+), 58 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index 2eed9a4..99c5f5f 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -21,11 +21,8 @@
  #include linux/of_gpio.h
  #include linux/phy/phy.h
  #include linux/platform_device.h
 -#include linux/usb/phy.h
 -#include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
  #include linux/usb/hcd.h
 -#include linux/usb/otg.h
 
  #include ehci.h
 
 @@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
  struct exynos_ehci_hcd {
   struct clk *clk;
 - struct usb_phy *phy;
 - struct usb_otg *otg;
 - struct phy *phy_g[PHY_NUMBER];
 + struct phy *phy[PHY_NUMBER];
  };
 
  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
 *)(hcd_to_ehci(hcd)-priv)
 @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
  {
   struct device_node *child;
   struct phy *phy;
 - int phy_number;
 - int ret = 0;
 + int phy_num;
 + int ret;
 
   for_each_available_child_of_node(dev-of_node, child) {
 - ret = of_property_read_u32(child, reg, phy_number);
 + ret = of_property_read_u32(child, reg, phy_num);
   if (ret) {
   dev_err(dev, Failed to parse device tree\n);
   of_node_put(child);
   return ret;
   }
 
 - if (phy_number = PHY_NUMBER) {
 + if (phy_num = PHY_NUMBER) {
   dev_err(dev, Invalid number of PHYs\n);
   of_node_put(child);
   return -EINVAL;
   }
 
 - phy = devm_of_phy_get(dev, child, NULL);
 + exynos_ehci-phy[phy_num] = devm_of_phy_get(dev, child, NULL);
 + phy = exynos_ehci-phy[phy_num];
   of_node_put(child);
 - if (IS_ERR(phy))
 - /* Lets fallback to older USB-PHYs */
 - goto usb_phy_old;
 - exynos_ehci-phy_g[phy_number] = phy;
 - /* Make the older PHYs unavailable */
 - exynos_ehci-phy = ERR_PTR(-ENXIO);
 - }
 -
 - return 0;
 -
 -usb_phy_old:
 - exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
 - if (IS_ERR(exynos_ehci-phy)) {
 - ret = PTR_ERR(exynos_ehci-phy);
 - if (ret != -ENXIO  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 + if (IS_ERR(phy)) {
 + ret = PTR_ERR(phy);
 + if (ret == -EPROBE_DEFER) {
 + return ret;
 + } else if (ret != -ENOSYS  ret != -ENODEV) {
 + dev_err(dev,
 + Error retrieving usb2 phy: %d\n, ret);
 + return PTR_ERR(phy);
 + }
   }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ehci-otg = exynos_ehci-phy-otg;
   }
 
 - return ret;
 + return 0;
  }
 
  static int exynos_ehci_phy_enable(struct device *dev)
 @@ -111,16 +96,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
   int i;
   int ret = 0;
 
 - if (!IS_ERR(exynos_ehci-phy))
 - return usb_phy_init(exynos_ehci-phy);
 -
   for (i = 0; ret == 0  i  PHY_NUMBER; i++)
 - if (!IS_ERR(exynos_ehci-phy_g[i]))
 - ret = phy_power_on(exynos_ehci-phy_g[i]);
 + if (!IS_ERR(exynos_ehci-phy[i]))
 + ret = phy_power_on(exynos_ehci-phy[i]);
   if (ret)
   for (i--; i = 0; i--)
 - if (!IS_ERR(exynos_ehci-phy_g[i]))
 - phy_power_off(exynos_ehci-phy_g[i]);
 + if (!IS_ERR(exynos_ehci-phy[i]))
 + phy_power_off(exynos_ehci-phy[i]);
 
   return ret;
  }
 @@ -131,14 +113,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
   struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
   int i;
 
 - if (!IS_ERR(exynos_ehci-phy)) {
 - usb_phy_shutdown(exynos_ehci-phy);
 - return;
 - }
 -
   for (i = 0; i  PHY_NUMBER; i++)
 - if (!IS_ERR(exynos_ehci-phy_g[i]))
 - phy_power_off(exynos_ehci-phy_g[i]);

RE: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0

2014-09-17 Thread Kukjin Kim

Doug Anderson wrote:
 
 Vivek,
 
Hi,

 On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
  From: Naveen Krishna Chatradhi ch.nav...@samsung.com
 
  MMC capability for HS200 is parsed in mmc/core/host.c as
  dts string mmc-hs200-1_8v.
 
  This patch corrects the dts string for Exynos5420 based peach-pit
  and Exynos5800 based peach-pi boards.
 
  Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

In this case, Vivek's sign is required here.

  ---
 
  Hi Kukjin,
 
  As commented by Doug earlier for this patch, the two patches required
-- mmc: dw_mmc: Make sure we don't get stuck when we get an error
-- mmc: dw_mmc: change to use recommended reset procedure
  are now merged in upstream.
  So you can go ahead and pick this change.
 
   arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
   arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)
 
 Reviewed-by: Doug Anderson diand...@chromium.org

Thanks, I will take this patch once Vivek replies his sign on this patch.

- Kukjin

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

Re: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0

Hi Kukjin,


On Wed, Sep 17, 2014 at 5:39 PM, Kukjin Kim kg...@kernel.org wrote:
 Doug Anderson wrote:

 Vivek,

 Hi,

 On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
  From: Naveen Krishna Chatradhi ch.nav...@samsung.com
 
  MMC capability for HS200 is parsed in mmc/core/host.c as
  dts string mmc-hs200-1_8v.
 
  This patch corrects the dts string for Exynos5420 based peach-pit
  and Exynos5800 based peach-pi boards.
 
  Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

 In this case, Vivek's sign is required here.

Ok, i will resend it with my Signed-off


  ---
 
  Hi Kukjin,
 
  As commented by Doug earlier for this patch, the two patches required
-- mmc: dw_mmc: Make sure we don't get stuck when we get an error
-- mmc: dw_mmc: change to use recommended reset procedure
  are now merged in upstream.
  So you can go ahead and pick this change.
 
   arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
   arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)

 Reviewed-by: Doug Anderson diand...@chromium.org

 Thanks, I will take this patch once Vivek replies his sign on this patch.

 - Kukjin

 --
 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
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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

Re: [PATCH] drm/exynos: fix plane-framebuffer linkage

2014-09-17 Thread Daniel Drake

On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim jy0922.s...@samsung.com wrote:
 It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.

My patch moves that drm_framebuffer_reference() call to the plane
function which is called from crtc_mode_set context (and also called
in crtc pageflip path), so there should be no problem here.

 Chip specific drm driver internally doesn't have to care fb reference count if
 there is no special case. We should have switched to universal plane at that
 time.

To me it seems like the chip-specific DRM drivers do need to add a
reference in the crtc_mode_set and crtc page flip paths otherwise
framebuffer removal crashes (expecting to remove 3 references), as
noted by my testing and also in commit 25c8b5c304.

However, I'll be happy if universal planes means the driver does not
have to care about this any more. Andrej, please go ahead if you are
interested, I'll be happy to test your results.

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

Re: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0

On Wed, Sep 17, 2014 at 5:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Hi Kukjin,


 On Wed, Sep 17, 2014 at 5:39 PM, Kukjin Kim kg...@kernel.org wrote:
 Doug Anderson wrote:

 Vivek,

 Hi,

 On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
  From: Naveen Krishna Chatradhi ch.nav...@samsung.com
 
  MMC capability for HS200 is parsed in mmc/core/host.c as
  dts string mmc-hs200-1_8v.
 
  This patch corrects the dts string for Exynos5420 based peach-pit
  and Exynos5800 based peach-pi boards.
 
  Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com

 In this case, Vivek's sign is required here.

 Ok, i will resend it with my Signed-off.


  ---
 
  Hi Kukjin,
 
  As commented by Doug earlier for this patch, the two patches required
-- mmc: dw_mmc: Make sure we don't get stuck when we get an error
-- mmc: dw_mmc: change to use recommended reset procedure
  are now merged in upstream.
  So you can go ahead and pick this change.
 
   arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
   arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)

 Reviewed-by: Doug Anderson diand...@chromium.org

 Thanks, I will take this patch once Vivek replies his sign on this patch.

As suggested, giving  my signed-off here:
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com




-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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

Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Ajay,

 On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
 On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
  Hi Ajay,
 
  Thank you for the patch.
 
  I think we're moving in the right direction, but we're not there yet.
 
  On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
  This patch tries to seperate drm_bridge implementation
  into 2 parts, a drm part and a non_drm part.
 
  A set of helper functions are defined in this patch to make
  bridge driver probe independent of the drm flow.
 
  The bridge devices register themselves on a lookup table
  when they get probed by calling drm_bridge_add_for_lookup.
 
  The parent encoder driver waits till the bridge is available in the
  lookup table(by calling of_drm_find_bridge) and then continues with
  its initialization.
 
  Before the introduction of the component framework I would have said this
  is the way to go. Now, I think bridges should register themselves as
  components, and the DRM master driver should use the component framework
  to get a reference to the bridges it needs.

 Well, I have modified the bridge framework exactly the way Thierry wanted it
 to be, I mean the same way the current panel framework is.
 And, I don't think there is a problem with that.
 What problem are you facing with current bridge implementation?
 What is the advantage of using the component framework to register bridges?

 There are several advantages.

 - The component framework has been designed with this exact problem in mind,
 piecing multiple components into a display device. This patch set introduces
 yet another framework, without any compelling reason as far as I can see.
Without this bridge registration framework, there is no way you can pass on a
drm_device pointer to the bridge driver. That is why we added a lookup
framework.

 Today DRM drivers already need to use three different frameworks (component,
 I2C slave encoder and panel), and we're adding a fourth one to make the mess
 even messier. This is really a headlong rush, we need to stop and fix the
 design mistakes.

 - The component framework solves the probe ordering problem. Bridges can use
 deferred probing, but when a bridge requires a resources (such as a clock for
 instance) provided by the display controller, this will break.
This is exactly the way sti drm uses bridge I think. It uses component framework
to wait till the master device initializes and then passes on a
drm_device pointer
to the component devices. But please know that it is feasible in case of sti,
because the bridge they use must be a embedded chip on the SOC, but not a
third party device.
And, the case which you mentioned(clock instance need to be passed to
bridge driver)
happens only in the case of bridges embedded on the SOC, but not a
third party device.
So, you are always allowed to use component framework for that.

But, assume the bridge chip is a third party device(ex: ptn3460 or ps8622) which
sits on an i2c bus. In that case, your approach poses the foll problems:
The way master and components are binded varies from platform to platform.
i.e the way exynos consolidates and adds the components is very much
different the way msm/sti/armada does the same!
So, when one needs to use a third party device as a bridge, they will end up
hacking up their drm layer to support this third party device.

With my approach, only the corresponding encoder driver needs to
know about the bridge, that too just the phandle to bridge node.
The platform specific drm layer can still be unaware of the bridge and stuff.

With your approach, the way we would specify the bridge node will change
from platform to platform resulting in non-uniformity. Also, the platform
specific drm layer needs to be aware of the bridge.

And, I assume these are the reasons why drm_panel doesn't use component
framework. Because all the panels are often third party and hence can be reused
across platforms, and so are ptn3460/ps8622.

  The encoder driver should call drm_bridge_attach_encoder to pass on
  the drm_device and the encoder pointers to the bridge object.
 
  Now that the drm_device pointer is available, the encoder then calls
  bridge-funcs-post_encoder_init to allow the bridge to continue
  registering itself with the drm core.
 
  This is what really bothers me with DRM bridge.
 
  The framework assumes that a bridge will always bridge an encoder and a
  connector. Beside lacking support for chained bridges, this creates an
  artificial split between bridges and encoders by modeling the same
  components using drm_encoder or drm_bridge depending on their position in
  the video output pipeline.
 
  I would like to see drm_bridge becoming more self-centric, removing the
  awareness of the upstream encoder and downstream connector. I'll give this
  a try, but it will conflict with this patch, so I'd like to share
  opinions and coordinate

Re: [PATCH] drm/exynos: fix plane-framebuffer linkage

2014-09-17 Thread Daniel Vetter

On Wed, Sep 17, 2014 at 2:19 PM, Daniel Drake dr...@endlessm.com wrote:
 Chip specific drm driver internally doesn't have to care fb reference count 
 if
 there is no special case. We should have switched to universal plane at that
 time.

 To me it seems like the chip-specific DRM drivers do need to add a
 reference in the crtc_mode_set and crtc page flip paths otherwise
 framebuffer removal crashes (expecting to remove 3 references), as
 noted by my testing and also in commit 25c8b5c304.

I think fb refcounting in exynos is just plain busted. If you look at
other drivers the only place the refcount framebuffers or backing
storage objects is for pageflips to make sure the memory doesn't go
away while the hw is still scanning out the old framebuffer. If you
refcount anywhere else you either do something really crazy or your
driver is broken.

 However, I'll be happy if universal planes means the driver does not
 have to care about this any more. Andrej, please go ahead if you are
 interested, I'll be happy to test your results.

universal planes will fix up the mess with 2 drm plane objects
(primary plane + exonys internal primary). So should help to untangle
this not, but it will not magically fix the refcounting bugs itself.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

This interface and relevant codes aren't used anymore.

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   17 -
 drivers/gpu/drm/exynos/exynos_drm_gem.h |4 
 include/uapi/drm/exynos_drm.h   |   18 --
 4 files changed, 42 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9b00e4e..10ad3d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -282,9 +282,6 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
-   exynos_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
-   DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 15db801..2f3665d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }
 
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
-   struct drm_file *file_priv)
-{
-   struct drm_exynos_gem_map_off *args = data;
-
-   DRM_DEBUG_KMS(handle = 0x%x, offset = 0x%lx\n,
-   args-handle, (unsigned long)args-offset);
-
-   if (!(dev-driver-driver_features  DRIVER_GEM)) {
-   DRM_ERROR(does not support GEM.\n);
-   return -ENODEV;
-   }
-
-   return exynos_drm_gem_dumb_map_offset(file_priv, dev, args-handle,
-   args-offset);
-}
-
 int exynos_drm_gem_mmap_buffer(struct file *filp,
  struct vm_area_struct *vma)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 1592c0b..8e46094 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -111,10 +111,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp);
 
-/* get buffer offset to map to user space. */
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
-   struct drm_file *file_priv);
-
 /*
  * mmap the physically continuous memory that a gem object contains
  * to user space.
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index d584412..67a751c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -33,20 +33,6 @@ struct drm_exynos_gem_create {
 };
 
 /**
- * A structure for getting buffer offset.
- *
- * @handle: a pointer to gem object created.
- * @pad: just padding to be 64-bit aligned.
- * @offset: relatived offset value of the memory region allocated.
- * - this value should be set by user.
- */
-struct drm_exynos_gem_map_off {
-   unsigned int handle;
-   unsigned int pad;
-   uint64_t offset;
-};
-
-/**
  * A structure for mapping buffer.
  *
  * @handle: a handle to gem object created.
@@ -316,7 +302,6 @@ struct drm_exynos_ipp_cmd_ctrl {
 };
 
 #define DRM_EXYNOS_GEM_CREATE  0x00
-#define DRM_EXYNOS_GEM_MAP_OFFSET  0x01
 #define DRM_EXYNOS_GEM_MMAP0x02
 /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
 #define DRM_EXYNOS_GEM_GET 0x04
@@ -336,9 +321,6 @@ struct drm_exynos_ipp_cmd_ctrl {
 #define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
 
-#define DRM_IOCTL_EXYNOS_GEM_MAP_OFFSETDRM_IOWR(DRM_COMMAND_BASE + \
-   DRM_EXYNOS_GEM_MAP_OFFSET, struct drm_exynos_gem_map_off)
-
 #define DRM_IOCTL_EXYNOS_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_MMAP, struct drm_exynos_gem_mmap)
 
-- 
1.7.9.5

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

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

Hi Tomi,

Thanks for your comments.

On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 27/08/14 17:39, Ajay Kumar wrote:
 Add documentation for DT properties supported by ps8622/ps8625
 eDP-LVDS converter.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
 
  1 file changed, 20 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt

 diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
 b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 new file mode 100644
 index 000..0ec8172
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 @@ -0,0 +1,20 @@
 +ps8622-bridge bindings
 +
 +Required properties:
 + - compatible: parade,ps8622 or parade,ps8625
 + - reg: first i2c address of the bridge
 + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
 + - reset-gpios: OF device-tree gpio specification for RST_ pin.
 +
 +Optional properties:
 + - lane-count: number of DP lanes to use
 + - use-external-pwm: backlight will be controlled by an external PWM

 What does this mean? That the backlight support from ps8625 is not used?
 If so, maybe disable-pwm or something?
use-external-pwm or disable-bridge-pwm would be better.

 +
 +Example:
 + lvds-bridge@48 {
 + compatible = parade,ps8622;
 + reg = 0x48;
 + sleep-gpios = gpc3 6 1 0 0;
 + reset-gpios = gpc3 1 1 0 0;
 + lane-count = 1;
 + };


 I wish all new display component bindings would use the video
 ports/endpoints to describe the connections. It will be very difficult
 to improve the display driver model later if we're missing such critical
 pieces from the DT bindings.
Why do we need a complex graph when it can be handled using a simple phandle?

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

Re: [PATCH 0/2] drm/exynos: use drm generic mmap interface

2014-09-17 Thread Daniel Vetter

On Wed, Sep 17, 2014 at 10:48:44PM +0900, Inki Dae wrote:
 This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface
 which isn't used anymore and also uses drm generic mmap interface
 instead of a mmap interface specific to Exynos drm. So this patch set
 removes a existing mmap interface and relevant codes specific to Exynos
 drm.
 
 Inki Dae (2):
   drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
   drm/exynos: use drm generic mmap interface

Thanks for doing this. Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
-Daniel

 
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   28 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
  drivers/gpu/drm/exynos/exynos_drm_gem.c |  101 
 +--
  drivers/gpu/drm/exynos/exynos_drm_gem.h |   14 -
  include/uapi/drm/exynos_drm.h   |   40 
  5 files changed, 14 insertions(+), 170 deletions(-)
 
 -- 
 1.7.9.5
 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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

Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Arnd Bergmann

On Wednesday 17 September 2014, Pankaj Dubey wrote:
 ---
 V2 of this patchset and related discussion can be found here [1].
 
 Changes since v2:
  - Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
  - Removed unwanted change in syscon.h.
  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
  - Added Tested-by of Vivek Gautam for testing on Exynos platform.

Looks fine. Provided you can figure out the problem that Dong Aisheng
reported, please add my

Acked-by: Arnd Bergmann a...@arndb.de

 -}
 +static struct syscon *of_syscon_register(struct device_node *np);


One  minor comment: please avoid doing forward declarations of
local functions. It took me a while to understand what is going on
because I expect all functions to be ordered such that they only get
called by functions below, and don't need this.

Just move of_syscon_register() here directly.

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

Re: [PATCH 1/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards

2014-09-17 Thread Doug Anderson

Javier,

On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
 added an rtc_src DT property for the Samsung's S3C Real Time Clock
 controller that specifies the 32.768 kHz clock that uses the RTC as its
 source clock. In the case of the Peach Pit and Pi machines, the Maxim
 77802 32kHz AP clock is used as the source clock.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 5 -
  2 files changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
--
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

Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

2014-09-17 Thread Doug Anderson

Hi,

On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
 added an rtc_src DT property for the Samsung's S3C Real Time Clock
 controller that specifies the 32.768 kHz clock that uses the RTC as its
 source clock. In the case of the Exynos5250 based Snow board, the Maxim
 77686 32kHz AP clock is used as the source clock.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5250-snow.dts | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index e51fcef..56eec56 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -10,6 +10,7 @@

  /dts-v1/;
  #include dt-bindings/gpio/gpio.h
 +#include dt-bindings/clock/maxim,max77686.h
  #include exynos5250.dtsi

  / {
 @@ -29,6 +30,8 @@

 rtc@101E {
 status = okay;
 +   clocks = clock CLK_RTC, max77686 MAX77686_CLK_AP;
 +   clock-names = rtc, rtc_src;

Wait, seriously?  Snow is still using the rtc@101E syntax?
Whatever happened to the series that Andreas worked so hard on,
including https://patchwork.kernel.org/patch/4664801/?

Kukjin: Andreas's patch series was Reviewed long ago I think and by
now I'd imagine it's got some conflicts due to it not having been
applied in a timely fashion.  Perhaps you could fix it up for Andreas
(since he's already rebased it several times) and land it?

If I had to guess, outstanding from Andreas's series (patchwork IDs listed):

4751131 New  [v7] ARM: dts: Prepare node labels for exynos5250
4664801 New  [v6,04/10] ARM: dts: Clean up exynos5250-snow
4664771 New  [v6,05/10] ARM: dts: Fill in bootargs for exynos5250-snow
4664731 New  [v6,06/10] ARM: dts: Clean up exynos5250-smdk5250
4664751 New  [v6,07/10] ARM: dts: Clean up exynos5250-arndale
4664711 New  [v6,08/10] ARM: dts: Fix apparent GPIO typo in
exynos5250-arndale
4664681 New  [v6,09/10] ARM: dts: Simplify USB3503 on exynos5250-arndale
4664691 New  [v6,10/10] ARM: dts: Add exynos5250-spring device tree


 };

 pinctrl@1140 {
 @@ -350,7 +353,7 @@
 samsung,i2c-sda-delay = 100;
 samsung,i2c-max-bus-freq = 378000;

 -   max77686@09 {
 +   max77686: max77686@09 {
 compatible = maxim,max77686;
 interrupt-parent = gpx3;
 interrupts = 2 0;

In any case, there's nothing wrong with Javier's patch other than the
fact that it will eventually need to get merged with Andreas's, so:

Reviewed-by: Doug Anderson diand...@chromium.org
--
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

Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

2014-09-17 Thread Andreas Färber

Am 17.09.2014 um 17:47 schrieb Doug Anderson:
 Hi,
 
 On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 commit 546b117fdf17 (rtc: s3c: add support for RTC of Exynos3250 SoC)
 added an rtc_src DT property for the Samsung's S3C Real Time Clock
 controller that specifies the 32.768 kHz clock that uses the RTC as its
 source clock. In the case of the Exynos5250 based Snow board, the Maxim
 77686 32kHz AP clock is used as the source clock.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5250-snow.dts | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index e51fcef..56eec56 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -10,6 +10,7 @@

  /dts-v1/;
  #include dt-bindings/gpio/gpio.h
 +#include dt-bindings/clock/maxim,max77686.h
  #include exynos5250.dtsi

  / {
 @@ -29,6 +30,8 @@

 rtc@101E {
 status = okay;
 +   clocks = clock CLK_RTC, max77686 MAX77686_CLK_AP;
 +   clock-names = rtc, rtc_src;
 
 Wait, seriously?  Snow is still using the rtc@101E syntax?
 Whatever happened to the series that Andreas worked so hard on,
 including https://patchwork.kernel.org/patch/4664801/?
 
 Kukjin: Andreas's patch series was Reviewed long ago I think and by
 now I'd imagine it's got some conflicts due to it not having been
 applied in a timely fashion.  Perhaps you could fix it up for Andreas
 (since he's already rebased it several times) and land it?
 
 If I had to guess, outstanding from Andreas's series (patchwork IDs listed):
 
 4751131 New  [v7] ARM: dts: Prepare node labels for exynos5250
 4664801 New  [v6,04/10] ARM: dts: Clean up exynos5250-snow
 4664771 New  [v6,05/10] ARM: dts: Fill in bootargs for exynos5250-snow
 4664731 New  [v6,06/10] ARM: dts: Clean up exynos5250-smdk5250
 4664751 New  [v6,07/10] ARM: dts: Clean up exynos5250-arndale
 4664711 New  [v6,08/10] ARM: dts: Fix apparent GPIO typo in
 exynos5250-arndale
 4664681 New  [v6,09/10] ARM: dts: Simplify USB3503 on 
 exynos5250-arndale
 4664691 New  [v6,10/10] ARM: dts: Add exynos5250-spring device tree

Yes, Kukjin told me not to resend anything, and I haven't heard back
from him since his Kernel Summit trip.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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

Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver

Hi,

On Friday 15 August 2014 06:10 PM, Peter Griffin wrote:
 This patch removes the superflous .owner field for drivers which
 use the module_platform_driver or platform_driver_register api,
 as this is overriden in __platform_driver_register.
 
 Signed-off-by: Peter Griffin peter.grif...@linaro.org
 ---
  drivers/phy/phy-bcm-kona-usb2.c | 1 -
  drivers/phy/phy-berlin-sata.c   | 1 -
  drivers/phy/phy-exynos-dp-video.c   | 1 -
  drivers/phy/phy-exynos-mipi-video.c | 1 -
  drivers/phy/phy-exynos5-usbdrd.c| 1 -
  drivers/phy/phy-exynos5250-sata.c   | 1 -
  drivers/phy/phy-hix5hd2-sata.c  | 1 -
  drivers/phy/phy-miphy365x.c | 1 -
  drivers/phy/phy-mvebu-sata.c| 1 -
  drivers/phy/phy-omap-control.c  | 1 -
  drivers/phy/phy-omap-usb2.c | 1 -
  drivers/phy/phy-qcom-apq8064-sata.c | 1 -
  drivers/phy/phy-qcom-ipq806x-sata.c | 1 -
  drivers/phy/phy-samsung-usb2.c  | 1 -
  drivers/phy/phy-sun4i-usb.c | 1 -
  drivers/phy/phy-ti-pipe3.c  | 1 -
  drivers/phy/phy-twl4030-usb.c   | 1 -

twl4030-usb doesn't use module_platform_driver. Care to resend this patch
along? I've merged all other patches in this series.

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

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

2014-09-17 Thread Tomi Valkeinen

On 17/09/14 17:29, Ajay kumar wrote:
 Hi Tomi,
 
 Thanks for your comments.
 
 On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 27/08/14 17:39, Ajay Kumar wrote:
 Add documentation for DT properties supported by ps8622/ps8625
 eDP-LVDS converter.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
 
  1 file changed, 20 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/video/bridge/ps8622.txt

 diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
 b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 new file mode 100644
 index 000..0ec8172
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 @@ -0,0 +1,20 @@
 +ps8622-bridge bindings
 +
 +Required properties:
 + - compatible: parade,ps8622 or parade,ps8625
 + - reg: first i2c address of the bridge
 + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
 + - reset-gpios: OF device-tree gpio specification for RST_ pin.
 +
 +Optional properties:
 + - lane-count: number of DP lanes to use
 + - use-external-pwm: backlight will be controlled by an external PWM

 What does this mean? That the backlight support from ps8625 is not used?
 If so, maybe disable-pwm or something?
 use-external-pwm or disable-bridge-pwm would be better.

Well, the properties are about the bridge. use-external-pwm means that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.

disable-bridge-pwm is ok, but the bridge there is extra. The
properties are about the bridge, so it's implicit.

 +
 +Example:
 + lvds-bridge@48 {
 + compatible = parade,ps8622;
 + reg = 0x48;
 + sleep-gpios = gpc3 6 1 0 0;
 + reset-gpios = gpc3 1 1 0 0;
 + lane-count = 1;
 + };


 I wish all new display component bindings would use the video
 ports/endpoints to describe the connections. It will be very difficult
 to improve the display driver model later if we're missing such critical
 pieces from the DT bindings.
 Why do we need a complex graph when it can be handled using a simple phandle?

Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?

The point of the ports/endpoint graph is to also support more
complicated scenarios. If you now create ps8622 bindings that do not
support those graphs, the no one else using ps8622 can use
ports/endpoint graphs either.

Btw, is there an example how the bridge with these bindings is used in a
board's .dts file? I couldn't find any example with a quick search. So
it's unclear to me what the simple phandle actually is.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 5/6] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS

2014-09-17 Thread Lee Jones

On Thu, 11 Sep 2014, Javier Martinez Canillas wrote:

 From: Andrew Bresticker abres...@chromium.org
 
 When an EC command returns EC_RES_IN_PROGRESS, we need to query
 the state of the EC until it indicates that it is no longer busy.
 Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
 commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
 it is working on the in-progress command.
 
 The delay in milliseconds and the number of retries are the values
 that were used by the flashrom tool when retrying commands.
 
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Reviewed-by: Simon Glass s...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
 
 Changes since v2:
  - Explain in the commit message from where the delay and retry values come 
 from.
Commented by Andrew Bresticker.
  - Move the needed definitions inside the if block. Suggested by Lee Jones.
  - Only check if result is EC_RES_IN_PROGRESS instead of checking also if ret 
 is
-EAGAIN since the former implies the later. Suggested by Lee Jones.
  - Use usleep_range() instead of msleep() since doesn't handle values between 
 1~20.
Suggested by Lee Jones.
 
 Changes since v1:
  - The *xfer() calls don't modify the passed cros_ec_command so there is
no need to populate it inside the for loop. Suggested by Lee Jones.
 
  drivers/mfd/cros_ec.c | 34 ++
  1 file changed, 34 insertions(+)
 
 diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
 index c53804a..af2fadf 100644
 --- a/drivers/mfd/cros_ec.c
 +++ b/drivers/mfd/cros_ec.c
 @@ -23,6 +23,10 @@
  #include linux/mfd/core.h
  #include linux/mfd/cros_ec.h
  #include linux/mfd/cros_ec_commands.h
 +#include linux/delay.h
 +
 +#define EC_COMMAND_RETRIES   50
 +#define EC_RETRY_DELAY_MS10
  
  int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
  struct cros_ec_command *msg)
 @@ -69,6 +73,36 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
  
   mutex_lock(ec_dev-lock);
   ret = ec_dev-cmd_xfer(ec_dev, msg);
 + if (msg-result == EC_RES_IN_PROGRESS) {
 + int i;
 + struct cros_ec_command status_msg;
 + struct ec_response_get_comms_status status;
 +
 + status_msg.version = 0;
 + status_msg.command = EC_CMD_GET_COMMS_STATUS;
 + status_msg.outdata = NULL;
 + status_msg.outsize = 0;
 + status_msg.indata = (uint8_t *)status;
 + status_msg.insize = sizeof(status);
 +
 + /*
 +  * Query the EC's status until it's no longer busy or
 +  * we encounter an error.
 +  */
 + for (i = 0; i  EC_COMMAND_RETRIES; i++) {
 + usleep_range(EC_RETRY_DELAY_MS, EC_RETRY_DELAY_MS + 1);

Remove the EC_RETRY_DELAY_MS define and place the values in raw.

You're now sleeping for 10us.  Did you test the changes?

 + ret = ec_dev-cmd_xfer(ec_dev, status_msg);
 + if (ret  0)
 + break;
 +
 + msg-result = status_msg.result;
 + if (status_msg.result != EC_RES_SUCCESS)
 + break;
 + if (!(status.flags  EC_COMMS_STATUS_PROCESSING))
 + break;
 + }
 + }
   mutex_unlock(ec_dev-lock);
  
   return ret;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH v3 6/6] mfd: cros_ec: Instantiate sub-devices from device tree

2014-09-17 Thread Lee Jones

On Thu, 11 Sep 2014, Javier Martinez Canillas wrote:

 From: Todd Broch tbr...@chromium.org
 
 If the EC device tree node has sub-nodes, try to instantiate them as
 MFD sub-devices.  We can configure the EC features provided by the board.
 
 Signed-off-by: Todd Broch tbr...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
 
 Changes since v2:
  - Drop if guards since of_node is unconditionally built. Suggested by Lee 
 Jones
  - Drop unneeded comment about of_platform_populate(). Suggested by Lee Jones.
  - Fix error message if of_platform_populate() fails. Suggested by Lee Jones.
 
 Changes since v1:
  - Don't leave an empty struct mfd_cell array. Suggested by Lee Jones.
  - Just use of_platform_populate() instead of manually iterating through
sub-devices and calling mfd_add_devices. Suggested by Lee Jones.
 ---
  drivers/mfd/cros_ec.c | 27 ---
  1 file changed, 8 insertions(+), 19 deletions(-)
 
 diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
 index 751af0b..7c533d2 100644
 --- a/drivers/mfd/cros_ec.c
 +++ b/drivers/mfd/cros_ec.c
 @@ -21,6 +21,7 @@
  #include linux/slab.h
  #include linux/module.h
  #include linux/mfd/core.h
 +#include linux/of_platform.h
  #include linux/mfd/cros_ec.h
  #include linux/mfd/cros_ec_commands.h
  #include linux/delay.h
 @@ -109,22 +110,10 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
  }
  EXPORT_SYMBOL(cros_ec_cmd_xfer);
  
 -static const struct mfd_cell cros_devs[] = {
 - {
 - .name = cros-ec-keyb,
 - .id = 1,
 - .of_compatible = google,cros-ec-keyb,
 - },
 - {
 - .name = cros-ec-i2c-tunnel,
 - .id = 2,
 - .of_compatible = google,cros-ec-i2c-tunnel,
 - },
 -};
 -
  int cros_ec_register(struct cros_ec_device *ec_dev)
  {
   struct device *dev = ec_dev-dev;
 + struct device_node *node = dev-of_node;
   int err = 0;
  
   if (ec_dev-din_size) {
 @@ -140,12 +129,12 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
  
   mutex_init(ec_dev-lock);
  
 - err = mfd_add_devices(dev, 0, cros_devs,
 -   ARRAY_SIZE(cros_devs),
 -   NULL, ec_dev-irq, NULL);
 - if (err) {
 - dev_err(dev, failed to add mfd devices\n);
 - return err;

So these devices will only ever probe with DT now ...

 + if (node) {

So it would be wrong for dev-of_node not to be populated.

 + err = of_platform_populate(node, NULL, NULL, dev);
 + if (err) {
 + dev_err(dev, Failed to register subordinate devices);
 + return err;
 + }
   }
  
   dev_info(dev, Chrome EC device registered\n);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH] drm/exynos: fix plane-framebuffer linkage

2014-09-17 Thread Daniel Drake

On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter dan...@ffwll.ch wrote:
 I think fb refcounting in exynos is just plain busted. If you look at
 other drivers the only place the refcount framebuffers or backing
 storage objects is for pageflips to make sure the memory doesn't go
 away while the hw is still scanning out the old framebuffer. If you
 refcount anywhere else you either do something really crazy or your
 driver is broken.

With my patch actually the behaviour is much more similar to omapdrm,
which also doesn't quite match your description of other drivers.
See omap_plane.c.

There is a fb reference taken for pinning in update_pin() which
presumably is what you describe - avoid destroying the fb while it is
being scanned out. (Maybe exynos should have something equivalent too,
but thats a separate issue)

However there is *another* fb reference taken in
omap_plane_mode_set(). And my patch is modelled to do the same in
exynos-drm.

I believe this is necessary under the current model. At least, when
drm_mode_rmfb() is running for the last user of the active
framebuffer, it expects to drop 3 references from the framebuffer
before dropping the 4th causes the object to be destroyed, as follows:

1. drm_mode_rmfb explicitly drops a reference - it calls
__drm_framebuffer_unregister which then calls
__drm_framebuffer_unreference
/* Mark fb as reaped, we still have a ref from fpriv-fbs. */
__drm_framebuffer_unregister(dev, fb);

2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
drm_mode_set_config_internal() in order to turn off the CRTC, dropping
another reference in the process.
if (tmp-old_fb)
drm_framebuffer_unreference(tmp-old_fb);

3. drm_framebuffer_remove calls drm_plane_force_disable() which drops
another reference:
/* disconnect the plane from the fb and crtc: */
__drm_framebuffer_unreference(old_fb);

4. drm_framebuffer drops the final reference itself, to cause freeing
of the object:
drm_framebuffer_unreference(fb);


So ordinarily, after a fb is created by drm core (with refcnt at 1),
there would have to be 3 references added to it by the time it is the
primary fb so that when we do rmfb, it has a refcnt of 4, and gets
freed correctly.
(The second bug I was seeing with pageflips was that refcnt was 3,
which means that the final reference was dropped in (3) above, but
__drm_framebuffer_unreference doesn't like that at all - it calls
drm_framebuffer_free_bug)

Not being overly familiar with DRM internals I tried to go backwards
to find out where these 3 references would be created during normal
operation. 2 are clear:

1. drm_framebuffer_init() explicitly grabs one:
/* Grab the idr reference. */
drm_framebuffer_reference(fb)

2. drm_mode_set_config_internal() takes one:
if (tmp-primary-fb)
drm_framebuffer_reference(tmp-primary-fb);

Where should the 3rd one be created? I don't know, but looking at
previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm
driver should take one, both on crtc mode set and crtc page flip.

 However, I'll be happy if universal planes means the driver does not
 have to care about this any more. Andrej, please go ahead if you are
 interested, I'll be happy to test your results.

 universal planes will fix up the mess with 2 drm plane objects
 (primary plane + exonys internal primary). So should help to untangle
 this not, but it will not magically fix the refcounting bugs itself.

So even when we move to universal planes (fixing 1 of the issues), its
good that we're having this refcount discussion (which we need to
understand to confidently solve the 2nd issue). Thanks for your input!

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

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

2014-09-17 Thread Doug Anderson

Daniel,

On Wed, Sep 17, 2014 at 9:49 AM, Daniel Drake dr...@endlessm.com wrote:
 On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson diand...@chromium.org wrote:
 NOTE: I don't think that the builtin RTC is terribly important for any
 exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
 part of the Maxim PMIC itself and pretty much ignore the one built-in
 to the exynos.  I think there are some cases it was used (as a
 fallback wakeup source in certain test scripts), but nothing very
 important.

 That's not true for all hardware though, at least the board I'm
 working on now has the SoC RTC as battery-backed and the PMIC one with
 no battery. So in this case at least, the interesting RTC is the SoC
 one.

Yup, I can totally believe that.  My statement was meant only to apply
to the boards I knew about firsthand...

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

Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register



On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
 Currently the DP_PHY_ENABLE register is mapped in the driver,
 and accessed to control power to the PHY.
 With mfd-syscon and regmap interface available at our disposal,
 it's wise to use that instead of using a 'reg' property for the
 controller and allocating a memory resource for that.
 
 To facilitate this, we have added another compatible string
 for Exynso5420 SoC to acquire driver data which contains
 different DP-PHY-CONTROL register offset.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 Cc: Kishon Vijay Abraham I kis...@ti.com

Taking this in linux-phy tree. If someone has already taken this patch, please
let me know.

Thanks
Kishon

 ---
 
 Changes since v2:
  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
since that's available with us in linux/mfd/syscon/exynos5-pmu.h file.
 
 Changes since v1:
  - state-regs should have been struct regmap * instead of
void __iomem *. So corrected the same.
 
  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
  drivers/phy/phy-exynos-dp-video.c  |   79 
 +---
  2 files changed, 59 insertions(+), 27 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 7a6feea..15e0f2c 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
  -
  
  Required properties:
 -- compatible : should be samsung,exynos5250-dp-video-phy;
 -- reg : offset and length of the Display Port PHY register set;
 +- compatible : should be one of the following supported values:
 +  - samsung,exynos5250-dp-video-phy
 +  - samsung,exynos5420-dp-video-phy
 +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
 +   control pmu registers for power isolation.
  - #phy-cells : from the generic PHY bindings, must be 0;
  
  Samsung S5P/EXYNOS SoC series USB PHY
 diff --git a/drivers/phy/phy-exynos-dp-video.c 
 b/drivers/phy/phy-exynos-dp-video.c
 index 8b3026e..53f44a0 100644
 --- a/drivers/phy/phy-exynos-dp-video.c
 +++ b/drivers/phy/phy-exynos-dp-video.c
 @@ -13,44 +13,55 @@
  #include linux/io.h
  #include linux/kernel.h
  #include linux/module.h
 +#include linux/mfd/syscon.h
 +#include linux/mfd/syscon/exynos5-pmu.h
  #include linux/of.h
  #include linux/of_address.h
  #include linux/phy/phy.h
  #include linux/platform_device.h
 +#include linux/regmap.h
  
 -/* DPTX_PHY_CONTROL register */
 -#define EXYNOS_DPTX_PHY_ENABLE   (1  0)
 +struct exynos_dp_video_phy_drvdata {
 + u32 phy_ctrl_offset;
 +};
  
  struct exynos_dp_video_phy {
 - void __iomem *regs;
 + struct regmap *regs;
 + const struct exynos_dp_video_phy_drvdata *drvdata;
  };
  
 -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
 on)
 +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
 + unsigned int on)
  {
 - u32 reg;
 + unsigned int val;
 +
 + if (IS_ERR(state-regs))
 + return;
  
 - reg = readl(state-regs);
 - if (on)
 - reg |= EXYNOS_DPTX_PHY_ENABLE;
 - else
 - reg = ~EXYNOS_DPTX_PHY_ENABLE;
 - writel(reg, state-regs);
 + val = on ? 0 : EXYNOS5_PHY_ENABLE;
  
 - return 0;
 + regmap_update_bits(state-regs, state-drvdata-phy_ctrl_offset,
 +EXYNOS5_PHY_ENABLE, val);
  }
  
  static int exynos_dp_video_phy_power_on(struct phy *phy)
  {
   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
  
 - return __set_phy_state(state, 1);
 + /* Disable power isolation on DP-PHY */
 + exynos_dp_video_phy_pwr_isol(state, 0);
 +
 + return 0;
  }
  
  static int exynos_dp_video_phy_power_off(struct phy *phy)
  {
   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
  
 - return __set_phy_state(state, 0);
 + /* Enable power isolation on DP-PHY */
 + exynos_dp_video_phy_pwr_isol(state, 1);
 +
 + return 0;
  }
  
  static struct phy_ops exynos_dp_video_phy_ops = {
 @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
   .owner  = THIS_MODULE,
  };
  
 +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
 + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
 +};
 +
 +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
 + .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
 +};
 +
 +static const struct of_device_id exynos_dp_video_phy_of_match[] = {
 + {
 + .compatible = samsung,exynos5250-dp-video-phy,
 + .data = exynos5250_dp_video_phy,
 + }, {
 +

Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver

2014-09-17 Thread Peter Griffin

Hi Kishon,

On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote:

 Hi,
 
 On Friday 15 August 2014 06:10 PM, Peter Griffin wrote:
  This patch removes the superflous .owner field for drivers which
  use the module_platform_driver or platform_driver_register api,
  as this is overriden in __platform_driver_register.
  
  Signed-off-by: Peter Griffin peter.grif...@linaro.org

snip
   drivers/phy/phy-twl4030-usb.c   | 1 -
 
 twl4030-usb doesn't use module_platform_driver. Care to resend this patch
 along? I've merged all other patches in this series.

That is true, but it does use platform_driver_register  whih overrides .owner.
So the patch is stil good I think (fyi see include/linux/platform_device.h).

regards,

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

pwm-samsung: incorrect register values for 100% duty cycle

2014-09-17 Thread Daniel Drake

Hi,

I'm using pwm-samsung on Exynos4412 for a variable-brightness LED.

When the LED is set to maximum brightness via the pwm-leds driver, we
arrive at pwm_samsung_config with duty_ns = period_ns, i.e. 100% duty
cycle.

This function does:

/* -1UL will give 100% duty. */
--tcmp;
writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));

I think that comment is incorrect. If tcmp is written as -1UL then the
LED totally turns off. And there is nothing in the Exynos4412 manual
to suggest that -1UL should be set in the TCMP register for 100% duty.

If I remove that --tcmp line, so that 100% duty cycle is handled as
tcmp=0, the problem is solved: the LED turns on at max brightness when
the leds subsystem requests so.

Any ideas? Is this -1UL thing a quirk from older chip versions not
applicable to Exynos4?

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

Re: exynos5420/arndale-octa: imprecise external aborts on exynos_defconfig

2014-09-17 Thread Kevin Hilman

Thomas Abraham ta.oma...@gmail.com writes:

On Thu, Sep 11, 2014 at 12:16 AM, Kevin Hilman khil...@kernel.org wrote:
Tyler Baker tyler.ba...@linaro.org writes:

Exynos5420-based Arndale octa boards have recently started failing boot
tests due to imprecise external aborts. This only appears to happen
when using exynos_defconfig and boots fine with multi_v7_defconfig. The
issue seems to be intermittent, so is not reliably reproducable and
difficult to bisect. Here are a few boot logs from recent
mainline/linux-next kernels that are failing:

FYI, I'm seeing the same periodic aborts. For example, here's my boot
of next-20140910:
http://images.armcloud.us/kernel-ci/next/next-20140910/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html

However, my userspace is much simpler and doesn't seem to cause a panic,
so my boot tests report passing. (I should fixup my scripts so these
imprecise aborts are reported as a FAIL.)

I'm glad you pointed out that it happens only with exynos_defconfig and
not multi_v7_defconfig because I noticed that too. I haven't had the
time to track it any further than that, so maybe the exynos folks can
help track it down from here.

Thanks for reporting this,

Kevin

Hi Tyler, Kevin,

From the bootlog you have shared,

[1.060016] CPU4: failed to come online
[2.070031] CPU5: failed to come online
[3.080049] CPU6: failed to come online
[4.090066] CPU7: failed to come online
[4.090099] Brought up 4 CPUs
[4.090109] SMP: Total of 4 processors activated.
[4.090119] CPU: WARNING: CPU(s) started in wrong/inconsistent
modes (primary CPU mode 0x13)
[4.090128] CPU: This may indicate a broken bootloader or firmware.

Would it be possible to set max cpus to 1, disable switcher and try
again. I don't have a arndale octa board but I have tested mainline
kernel with smdk5420 board. It boots all eight CPUs, switcher works
fine and there are no imprecise aborts seen.

Sorry for the delay, I'm travelling this week.

FWIW, the same CPU boot failures you hilight above are happening on
multi_v7_defconfig[1] which is not getting the imprecise abort. This is
only happening on exynos_defconfig[2], so I'm curious why you think the
switcher or NR_CPUS might be the issues.

Anyways, I narrowed this down a bit and discovered it's
CONFIG_EXYNOS5420_MCPM=y that's the root cause. If I use
exynos_defconfig and then disable that option, I don't get any more
imprecise aborts.

Kevin

[1]
http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-multi_v7_defconfig/boot-exynos5420-arndale-octa.html
[2]
http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html
--
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

Re: [PATCH] drm/exynos: fix plane-framebuffer linkage

2014-09-17 Thread Joonyoung Shim

Hi,

On 09/18/2014 01:41 AM, Daniel Drake wrote:
 On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter dan...@ffwll.ch wrote:
 I think fb refcounting in exynos is just plain busted. If you look at
 other drivers the only place the refcount framebuffers or backing
 storage objects is for pageflips to make sure the memory doesn't go
 away while the hw is still scanning out the old framebuffer. If you
 refcount anywhere else you either do something really crazy or your
 driver is broken.
 
 With my patch actually the behaviour is much more similar to omapdrm,

Your patch will occur fb reference count problem when setplane.

 which also doesn't quite match your description of other drivers.
 See omap_plane.c.
 
 There is a fb reference taken for pinning in update_pin() which
 presumably is what you describe - avoid destroying the fb while it is
 being scanned out. (Maybe exynos should have something equivalent too,
 but thats a separate issue)
 
 However there is *another* fb reference taken in
 omap_plane_mode_set(). And my patch is modelled to do the same in
 exynos-drm.
 
 I believe this is necessary under the current model. At least, when
 drm_mode_rmfb() is running for the last user of the active
 framebuffer, it expects to drop 3 references from the framebuffer
 before dropping the 4th causes the object to be destroyed, as follows:
 
 1. drm_mode_rmfb explicitly drops a reference - it calls
 __drm_framebuffer_unregister which then calls
 __drm_framebuffer_unreference
 /* Mark fb as reaped, we still have a ref from fpriv-fbs. */
 __drm_framebuffer_unregister(dev, fb);
 
 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
 drm_mode_set_config_internal() in order to turn off the CRTC, dropping
 another reference in the process.
 if (tmp-old_fb)
 drm_framebuffer_unreference(tmp-old_fb);
 
 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops
 another reference:
 /* disconnect the plane from the fb and crtc: */
 __drm_framebuffer_unreference(old_fb);

This call is new path, before universal planes merged, private plane of
exynos crtc wasn't included in dev-mode_config.plane_list because
private plane wasn't exposed to userspace so this path wasn't called.

 
 4. drm_framebuffer drops the final reference itself, to cause freeing
 of the object:
 drm_framebuffer_unreference(fb);
 
 
 So ordinarily, after a fb is created by drm core (with refcnt at 1),
 there would have to be 3 references added to it by the time it is the
 primary fb so that when we do rmfb, it has a refcnt of 4, and gets
 freed correctly.
 (The second bug I was seeing with pageflips was that refcnt was 3,
 which means that the final reference was dropped in (3) above, but
 __drm_framebuffer_unreference doesn't like that at all - it calls
 drm_framebuffer_free_bug)
 
 Not being overly familiar with DRM internals I tried to go backwards
 to find out where these 3 references would be created during normal
 operation. 2 are clear:
 
 1. drm_framebuffer_init() explicitly grabs one:
 /* Grab the idr reference. */
 drm_framebuffer_reference(fb)
 
 2. drm_mode_set_config_internal() takes one:
 if (tmp-primary-fb)
 drm_framebuffer_reference(tmp-primary-fb);
 
 Where should the 3rd one be created? I don't know, but looking at
 previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm
 driver should take one, both on crtc mode set and crtc page flip.

So Andrzej added fb reference count increasing in crtc modeset path, but
i think we can take away this workaround if remove private plane for
exynos crtc.

Thanks.

 
 However, I'll be happy if universal planes means the driver does not
 have to care about this any more. Andrej, please go ahead if you are
 interested, I'll be happy to test your results.

 universal planes will fix up the mess with 2 drm plane objects
 (primary plane + exonys internal primary). So should help to untangle
 this not, but it will not magically fix the refcounting bugs itself.
 
 So even when we move to universal planes (fixing 1 of the issues), its
 good that we're having this refcount discussion (which we need to
 understand to confidently solve the 2nd issue). Thanks for your input!
 
 Daniel
 

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

Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

Hi Kishon,


On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
 Currently the DP_PHY_ENABLE register is mapped in the driver,
 and accessed to control power to the PHY.
 With mfd-syscon and regmap interface available at our disposal,
 it's wise to use that instead of using a 'reg' property for the
 controller and allocating a memory resource for that.

 To facilitate this, we have added another compatible string
 for Exynso5420 SoC to acquire driver data which contains
 different DP-PHY-CONTROL register offset.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 Cc: Kishon Vijay Abraham I kis...@ti.com

 Taking this in linux-phy tree. If someone has already taken this patch, please
 let me know.

Thanks for taking this. But just one check, i think i need to separate
out the Documentation
to a separate patch even before this driver patch. Isn't it ?


 Thanks
 Kishon

 ---

 Changes since v2:
  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
since that's available with us in linux/mfd/syscon/exynos5-pmu.h file.

 Changes since v1:
  - state-regs should have been struct regmap * instead of
void __iomem *. So corrected the same.

  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
  drivers/phy/phy-exynos-dp-video.c  |   79 
 +---
  2 files changed, 59 insertions(+), 27 deletions(-)

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 7a6feea..15e0f2c 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
  -

  Required properties:
 -- compatible : should be samsung,exynos5250-dp-video-phy;
 -- reg : offset and length of the Display Port PHY register set;
 +- compatible : should be one of the following supported values:
 +  - samsung,exynos5250-dp-video-phy
 +  - samsung,exynos5420-dp-video-phy
 +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
 +   control pmu registers for power isolation.
  - #phy-cells : from the generic PHY bindings, must be 0;

  Samsung S5P/EXYNOS SoC series USB PHY
 diff --git a/drivers/phy/phy-exynos-dp-video.c 
 b/drivers/phy/phy-exynos-dp-video.c
 index 8b3026e..53f44a0 100644
 --- a/drivers/phy/phy-exynos-dp-video.c
 +++ b/drivers/phy/phy-exynos-dp-video.c
 @@ -13,44 +13,55 @@
  #include linux/io.h
  #include linux/kernel.h
  #include linux/module.h
 +#include linux/mfd/syscon.h
 +#include linux/mfd/syscon/exynos5-pmu.h
  #include linux/of.h
  #include linux/of_address.h
  #include linux/phy/phy.h
  #include linux/platform_device.h
 +#include linux/regmap.h

 -/* DPTX_PHY_CONTROL register */
 -#define EXYNOS_DPTX_PHY_ENABLE   (1  0)
 +struct exynos_dp_video_phy_drvdata {
 + u32 phy_ctrl_offset;
 +};

  struct exynos_dp_video_phy {
 - void __iomem *regs;
 + struct regmap *regs;
 + const struct exynos_dp_video_phy_drvdata *drvdata;
  };

 -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
 on)
 +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
 + unsigned int on)
  {
 - u32 reg;
 + unsigned int val;
 +
 + if (IS_ERR(state-regs))
 + return;

 - reg = readl(state-regs);
 - if (on)
 - reg |= EXYNOS_DPTX_PHY_ENABLE;
 - else
 - reg = ~EXYNOS_DPTX_PHY_ENABLE;
 - writel(reg, state-regs);
 + val = on ? 0 : EXYNOS5_PHY_ENABLE;

 - return 0;
 + regmap_update_bits(state-regs, state-drvdata-phy_ctrl_offset,
 +EXYNOS5_PHY_ENABLE, val);
  }

  static int exynos_dp_video_phy_power_on(struct phy *phy)
  {
   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);

 - return __set_phy_state(state, 1);
 + /* Disable power isolation on DP-PHY */
 + exynos_dp_video_phy_pwr_isol(state, 0);
 +
 + return 0;
  }

  static int exynos_dp_video_phy_power_off(struct phy *phy)
  {
   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);

 - return __set_phy_state(state, 0);
 + /* Enable power isolation on DP-PHY */
 + exynos_dp_video_phy_pwr_isol(state, 1);
 +
 + return 0;
  }

  static struct phy_ops exynos_dp_video_phy_ops = {
 @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
   .owner  = THIS_MODULE,
  };

 +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
 + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
 +};
 +
 +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
 + .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
 +};

RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Pankaj Dubey

+CC: Dong Aisheng 

Hi Arnd,

On Wednesday, September 17, 2014, Arnd Bergmann wrote,
  V2 of this patchset and related discussion can be found here [1].
 
  Changes since v2:
   - Added back platform device support from syscon, with one change that
 syscon will not be probed for DT based platform.
   - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
 users of syscon will not be broken.
   - Removed unwanted change in syscon.h.
   - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
 Arnd Bergmann.
   - Added Tested-by of Vivek Gautam for testing on Exynos platform.
 
 Looks fine. Provided you can figure out the problem that Dong Aisheng
reported,
 please add my
 
 Acked-by: Arnd Bergmann a...@arndb.de


Thanks. 
After he reported I have again done code walk-through of regmap_init_mmio
and 
could not see any such fatal error.  At the same time I have replied to Dong
Aisheng,
asking for more details and waiting for his reply. 
 
  -}
  +static struct syscon *of_syscon_register(struct device_node *np);
 
 
 One  minor comment: please avoid doing forward declarations of local
functions. It
 took me a while to understand what is going on because I expect all
functions to be
 ordered such that they only get called by functions below, and don't need
this.
 
 Just move of_syscon_register() here directly.
 

OK, I will remove forward declaration of of_syscon_register and respin
patch once again.

   Arnd

Thanks,
Pankaj Dubey

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

Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Dong Aisheng

On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
 Hi,
 
 On Wednesday, September 17, 2014, Dong Aisheng Wrote,
  
   +static struct syscon *of_syscon_register(struct device_node *np) {
   + struct syscon *syscon;
   + struct regmap *regmap;
   + void __iomem *base;
   +
   + if (!of_device_is_compatible(np, syscon))
   + return ERR_PTR(-EINVAL);
   +
   + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
   + if (!syscon)
   + return ERR_PTR(-ENOMEM);
   +
   + base = of_iomap(np, 0);
   + if (!base)
   + return ERR_PTR(-ENOMEM);
   +
   + regmap = regmap_init_mmio(NULL, base, syscon_regmap_config);
  
  Does a NULL device pointer work?
 
 Yes, it is safe, at least we are able to test on Exynos based SoC. 
 I have tested it with kgene/for-next kernel on Exynos3250.
 Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
 kernel
 by Vivek Gautam. 
 
 Patch V2 also has been tested by Borris Brezillon on AT91 platform.
 
 

The kernel i tested was next-20140915 of linux-next.

please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
struct device_node *np = dev-of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev-of_node if dev is NULL.

Can you check if you're using the same code as mine?

  I just tested on MX6SX SDB board and it seemed crashed at here in
 regmap_init
  function.
  
 
 Can you please provide crash log which can give more information about the
 crash?
 

My crash log is:

[0.225148] Unable to handle kernel NULL pointer dereference at virtual 
address 01d4
[0.233383] pgd = 80004000
[0.236185] [01d4] *pgd=
[0.239873] Internal error: Oops: 5 [#1] SMP ARM
[0.244588] Modules linked in:
[0.247753] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.17.0-rc4-next-20140915-6-g8ba2dd0-dirty #421
[0.257342] task: bd878000 ti: bd88 task.ti: bd88
[0.262848] PC is at regmap_init+0x21c/0xab4
[0.267221] LR is at vprintk_emit+0x254/0x5e0
[0.271677] pc : [80389420]lr : [8006a4f8]psr: 6153
[0.271677] sp : bd881ae0  ip : bd881a48  fp : bd881b1c
[0.283354] r10:   r9 : bd8e1850  r8 : 0003
[0.288678] r7 :   r6 : 8098fccc  r5 : 8098ee0c  r4 : bd8f4e00
[0.295307] r3 : bd878000  r2 : 01e5  r1 : 806ee8f0  r0 : 808762c0
[0.301938] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.309438] Control: 10c5387d  Table: 8000404a  DAC: 0015
[0.315284] Process swapper/0 (pid: 1, stack limit = 0xbd880240)
[0.321391] Stack: (0xbd881ae0 to 0xbd882000)
[0.325851] 1ae0: bd8e1850  bd881b1c bd881af8 8038f580 8098fccc 
 be7d49b8
[0.334136] 1b00: 8098fca4 bd917000 bd8e1850  bd881b34 bd881b20 
8038f68c 80389210
[0.342422] 1b20: bd91b480 8098fcc4 bd881b5c bd881b38 80398b24 8038f664 
 bd91ac10
[0.350708] 1b40: be7d4bc0 bd917010 bd917000 bd8e1850 bd881bac bd881b60 
803185a4 80398a54
[0.358993] 1b60: bd881b94 bd881b70     
 
[0.367277] 1b80:   bd917010 80983a64  bd916c10 
80983a64 
[0.375563] 1ba0: bd881bc4 bd881bb0 8037bb44 80318510 811c65f0 bd917010 
bd881bec bd881bc8
[0.383848] 1bc0: 8037a104 8037bb1c 80983a64 bd917010 8037a23c bd916c10 
 
[0.392134] 1be0: bd881c04 bd881bf0 8037a284 8037a004  bd917010 
bd881c2c bd881c08
[0.400419] 1c00: 80378614 8037a248 bd8038d8 bd8af7d4 bd916c10 bd917010 
bd917044 8098e308
[0.408704] 1c20: bd881c4c bd881c30 80379fb8 803785c0 bd803800 bd917018 
bd917010 8098e308
[0.416990] 1c40: bd881c6c bd881c50 8037961c 80379f48  bd917018 
 bd917010
[0.425275] 1c60: bd881ca4 bd881c70 80377904 80379598 bd881cc8 bd881cc0 
bd881cb8 bd881c88
[0.433560] 1c80: be7d4bc0 bd916c10  0001 bd917000 be7d4c10 
bd881cb4 bd881ca8
[0.441845] 1ca0: 804f1708 803774e8 bd881cfc bd881cb8 804f1f2c 804f16dc 
bd881cdc bd881cc8
[0.450130] 1cc0: 806b6d7c 80060478 809b0220 6153 bd881cfc  
be7d4bc0 
[0.458415] 1ce0: 0001 8070bb80 bd916c10  bd881d5c bd881d00 
804f2068 804f1e5c
[0.466700] 1d00: bd878000 a153 809b0220  bd881d2c bd881d20 
80060480 80060284
[0.474985] 1d20: bd881d44 bd881d30 806b6d7c 80060478  be7d4bc0 
be7d49b8 
[0.483270] 1d40: 0001 8070bb80 bd916c10  bd881dbc bd881d60 
804f20c4 804f1f8c
[0.491556] 1d60: 0001 6153 809b0220  bd881d8c bd881d80 
80060480 80060284
[0.499841] 1d80: bd881da4 bd881d90 806b6d7c 80060478 be7d46f8 be7d49b8 
be7cf764 
[0.508126] 1da0: 0001 8070bb80 bd910810  bd881e1c bd881dc0

Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

2014-09-17 Thread Dong Aisheng

On Thu, Sep 18, 2014 at 08:59:32AM +0530, Pankaj Dubey wrote:
 +CC: Dong Aisheng 
 
 Hi Arnd,
 
 On Wednesday, September 17, 2014, Arnd Bergmann wrote,
   V2 of this patchset and related discussion can be found here [1].
  
   Changes since v2:
- Added back platform device support from syscon, with one change that
  syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
  users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
  Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
  
  Looks fine. Provided you can figure out the problem that Dong Aisheng
 reported,
  please add my
  
  Acked-by: Arnd Bergmann a...@arndb.de
 
 
 Thanks. 
 After he reported I have again done code walk-through of regmap_init_mmio
 and 
 could not see any such fatal error.  At the same time I have replied to Dong
 Aisheng,
 asking for more details and waiting for his reply. 
  

I just replied and gave the log.

Regards
Dong Aisheng

   -}
   +static struct syscon *of_syscon_register(struct device_node *np);
  
  
  One  minor comment: please avoid doing forward declarations of local
 functions. It
  took me a while to understand what is going on because I expect all
 functions to be
  ordered such that they only get called by functions below, and don't need
 this.
  
  Just move of_syscon_register() here directly.
  
 
 OK, I will remove forward declaration of of_syscon_register and respin
 patch once again.
 
  Arnd
 
 Thanks,
 Pankaj Dubey
 
--
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

Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

Hi Alan,


On Wed, Sep 17, 2014 at 8:27 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 17 Sep 2014, Vivek Gautam wrote:

 Now that we have completely moved from older USB-PHY drivers
 to newer GENERIC-PHY drivers for PHYs available with USB controllers
 on Exynos series of SoCs, we can remove the support for the same
 in our host drivers too.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com

 I don't see why you made your changes in this awkward way.  For
 instance...

 @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
  {
   struct device_node *child;
   struct phy *phy;
 - int phy_number;
 - int ret = 0;
 + int phy_num;

 Why rename this variable?  Wasn't the original name good enough?

fair enough, don't need to rename the variable.


 + int ret;

   for_each_available_child_of_node(dev-of_node, child) {
 - ret = of_property_read_u32(child, reg, phy_number);
 + ret = of_property_read_u32(child, reg, phy_num);
   if (ret) {
   dev_err(dev, Failed to parse device tree\n);
   of_node_put(child);
   return ret;
   }

 - if (phy_number = PHY_NUMBER) {
 + if (phy_num = PHY_NUMBER) {
   dev_err(dev, Invalid number of PHYs\n);
   of_node_put(child);
   return -EINVAL;
   }

 - phy = devm_of_phy_get(dev, child, NULL);
 + exynos_ehci-phy[phy_num] = devm_of_phy_get(dev, child, NULL);
 + phy = exynos_ehci-phy[phy_num];

 Why make two changes, resulting in more code, when you could have made
 just one change?

 phy = devm_of_phy_get(dev, child, NULL);
 +   exynos_ehci-phy[phy_num] = phy;

Right. i don't know what state of mind i was in while making these changes.
i should have kept the changes to minimal.


 Also, the patch description should mention that you are adding support
 for EPROBE_DEFER.

Sure, will add that description.




-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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

[PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..f293453 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include linux/of_gpio.h
 #include linux/phy/phy.h
 #include linux/platform_device.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-#include linux/usb/otg.h
 
 #include ehci.h
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci-phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci-phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci-phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci-phy)) {
-   ret = PTR_ERR(exynos_ehci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS  ret != -ENODEV) {
+   dev_err(dev,
+   Error retrieving usb2 phy: %d\n, ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ehci-otg = exynos_ehci-phy-otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci-phy))
-   return usb_phy_init(exynos_ehci-phy);
-
for (i = 0; ret == 0  i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   ret = phy_power_on(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+   ret = phy_power_on(exynos_ehci-phy[i]);
if (ret)
for (i--; i = 0; i--)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   phy_power_off(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+   phy_power_off(exynos_ehci-phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci-phy)) {
-   usb_phy_shutdown(exynos_ehci-phy);
-   return;
-   }
-
for (i = 0; i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci-phy_g[i]))
-   phy_power_off(exynos_ehci-phy_g[i]);
+   if (!IS_ERR(exynos_ehci-phy[i]))
+   phy_power_off(exynos_ehci-phy[i]);
 }
 
 static void

[PATCH v4 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ohci-exynos.c |   81 ++--
 1 file changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..e8bf4bb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include linux/of.h
 #include linux/platform_device.h
 #include linux/phy/phy.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-#include linux/usb/otg.h
 
 #include ohci.h
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci-phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci-phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci-phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci-phy)) {
-   ret = PTR_ERR(exynos_ohci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS  ret != -ENODEV) {
+   dev_err(dev,
+   Error retrieving usb2 phy: %d\n, ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ohci-otg = exynos_ohci-phy-otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci-phy))
-   return usb_phy_init(exynos_ohci-phy);
-
for (i = 0; ret == 0  i  PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci-phy_g[i]))
-   ret = phy_power_on(exynos_ohci-phy_g[i]);
+   if (!IS_ERR(exynos_ohci-phy[i]))
+   ret = phy_power_on(exynos_ohci-phy[i]);
if (ret)
for (i--; i = 0; i--)
-   if (!IS_ERR(exynos_ohci-phy_g[i]))
-   phy_power_off(exynos_ohci-phy_g[i]);
+   if (!IS_ERR(exynos_ohci-phy[i]))
+   phy_power_off(exynos_ohci-phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci-phy)) {
-   usb_phy_shutdown(exynos_ohci-phy);
-   return;
-   }
-

Re: [PATCH 2/2] drm/exynos: use drm generic mmap interface

2014-09-17 Thread Joonyoung Shim

Hi,

On 09/17/2014 10:48 PM, Inki Dae wrote:
 This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
 to Exynos drm and instead uses drm generic mmap.
 
 We had used the interface specific to Exynos drm to do mmap directly,
 not to use demand paging which maps each page with physical memory
 at page fault handler. We don't need the specific mmap interface
 because the drm generic mmap which uses vm offset manager stuff can
 also do mmap directly.
 
 This patch makes a userspace region to be mapped with whole physical
 memory region allocated by userspace request when mmap system call is
 requested.
 
 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   25 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
  drivers/gpu/drm/exynos/exynos_drm_gem.c |   84 
 ++-
  drivers/gpu/drm/exynos/exynos_drm_gem.h |   10 
  include/uapi/drm/exynos_drm.h   |   22 
  5 files changed, 14 insertions(+), 128 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 10ad3d4..a7819eb 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c

Because anymore anon file doesn't use, you can remove to include
linux/anon_inodes.h.

 @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
   return 0;
  }
  
 -static const struct file_operations exynos_drm_gem_fops = {
 - .mmap = exynos_drm_gem_mmap_buffer,
 -};
 -
  static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
  {
   struct drm_connector *connector;
 @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
  static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
  {
   struct drm_exynos_file_private *file_priv;
 - struct file *anon_filp;
   int ret;
  
   file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
 @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev, 
 struct drm_file *file)
   if (ret)
   goto err_file_priv_free;
  
 - anon_filp = anon_inode_getfile(exynos_gem, exynos_drm_gem_fops,
 - NULL, 0);
 - if (IS_ERR(anon_filp)) {
 - ret = PTR_ERR(anon_filp);
 - goto err_subdrv_close;
 - }
 -
 - anon_filp-f_mode = FMODE_READ | FMODE_WRITE;
 - file_priv-anon_filp = anon_filp;
 -
   return ret;
  
 -err_subdrv_close:
 - exynos_drm_subdrv_close(dev, file);
 -
  err_file_priv_free:
   kfree(file_priv);
   file-driver_priv = NULL;
 @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file 
 *file)
  {
   struct exynos_drm_private *private = dev-dev_private;
 - struct drm_exynos_file_private *file_priv;
   struct drm_pending_vblank_event *v, *vt;
   struct drm_pending_event *e, *et;
   unsigned long flags;
 @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
 struct drm_file *file)
   }
   spin_unlock_irqrestore(dev-event_lock, flags);
  
 - file_priv = file-driver_priv;
 - if (file_priv-anon_filp)
 - fput(file_priv-anon_filp);
 -
   kfree(file-driver_priv);
   file-driver_priv = NULL;
  }
 @@ -282,8 +259,6 @@ static const struct vm_operations_struct 
 exynos_drm_gem_vm_ops = {
  static const struct drm_ioctl_desc exynos_ioctls[] = {
   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
   DRM_UNLOCKED | DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
 - exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
   exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 69a6fa3..d22e640 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
  struct drm_exynos_file_private {
   struct exynos_drm_g2d_private   *g2d_priv;
   struct device   *ipp_dev;
 - struct file *anon_filp;
  };
  
  /*
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index 2f3665d..3cf6494 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
   drm_gem_object_unreference_unlocked(obj);
  }
  
 -int exynos_drm_gem_mmap_buffer(struct file *filp,
 +int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
 struct vm_area_struct *vma)
  {
 - struct drm_gem_object *obj =

Re: [PATCH 2/2] drm/exynos: use drm generic mmap interface


Thanks for review.

Below trivial things you pointed out will be fixed soon.

On 2014년 09월 18일 13:56, Joonyoung Shim wrote:
 Hi,
 
 On 09/17/2014 10:48 PM, Inki Dae wrote:
 This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
 to Exynos drm and instead uses drm generic mmap.

 We had used the interface specific to Exynos drm to do mmap directly,
 not to use demand paging which maps each page with physical memory
 at page fault handler. We don't need the specific mmap interface
 because the drm generic mmap which uses vm offset manager stuff can
 also do mmap directly.

 This patch makes a userspace region to be mapped with whole physical
 memory region allocated by userspace request when mmap system call is
 requested.

 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   25 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
  drivers/gpu/drm/exynos/exynos_drm_gem.c |   84 
 ++-
  drivers/gpu/drm/exynos/exynos_drm_gem.h |   10 
  include/uapi/drm/exynos_drm.h   |   22 
  5 files changed, 14 insertions(+), 128 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 10ad3d4..a7819eb 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 
 Because anymore anon file doesn't use, you can remove to include
 linux/anon_inodes.h.

Right, I missed it while taking away the direct mmap stuff specific to
Exynos drm.

 
 @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
  return 0;
  }
  
 -static const struct file_operations exynos_drm_gem_fops = {
 -.mmap = exynos_drm_gem_mmap_buffer,
 -};
 -
  static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
  {
  struct drm_connector *connector;
 @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
  static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
  {
  struct drm_exynos_file_private *file_priv;
 -struct file *anon_filp;
  int ret;
  
  file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
 @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev, 
 struct drm_file *file)
  if (ret)
  goto err_file_priv_free;
  
 -anon_filp = anon_inode_getfile(exynos_gem, exynos_drm_gem_fops,
 -NULL, 0);
 -if (IS_ERR(anon_filp)) {
 -ret = PTR_ERR(anon_filp);
 -goto err_subdrv_close;
 -}
 -
 -anon_filp-f_mode = FMODE_READ | FMODE_WRITE;
 -file_priv-anon_filp = anon_filp;
 -
  return ret;
  
 -err_subdrv_close:
 -exynos_drm_subdrv_close(dev, file);
 -
  err_file_priv_free:
  kfree(file_priv);
  file-driver_priv = NULL;
 @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file 
 *file)
  {
  struct exynos_drm_private *private = dev-dev_private;
 -struct drm_exynos_file_private *file_priv;
  struct drm_pending_vblank_event *v, *vt;
  struct drm_pending_event *e, *et;
  unsigned long flags;
 @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device 
 *dev, struct drm_file *file)
  }
  spin_unlock_irqrestore(dev-event_lock, flags);
  
 -file_priv = file-driver_priv;
 -if (file_priv-anon_filp)
 -fput(file_priv-anon_filp);
 -
  kfree(file-driver_priv);
  file-driver_priv = NULL;
  }
 @@ -282,8 +259,6 @@ static const struct vm_operations_struct 
 exynos_drm_gem_vm_ops = {
  static const struct drm_ioctl_desc exynos_ioctls[] = {
  DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
  DRM_UNLOCKED | DRM_AUTH),
 -DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
 -exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
  DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
  exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
  DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 69a6fa3..d22e640 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
  struct drm_exynos_file_private {
  struct exynos_drm_g2d_private   *g2d_priv;
  struct device   *ipp_dev;
 -struct file *anon_filp;
  };
  
  /*
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index 2f3665d..3cf6494 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device 
 *dev,
  drm_gem_object_unreference_unlocked(obj);
  }
  
 -int exynos_drm_gem_mmap_buffer(struct file *filp,
 +int

[PATCH v2] drm/exynos: use drm generic mmap interface

This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.

We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.

This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.

Changelog v2:
- do not set VM_IO, VM_DONTEXPEND and VM_DONTDUMP. These flags were already
  set by drm_gem_mmap
- do not include linux/anon_inodes.h, which isn't needed anymore.

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   26 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   89 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   10 
 include/uapi/drm/exynos_drm.h   |   22 
 5 files changed, 16 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..928c514 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -15,7 +15,6 @@
 #include drm/drmP.h
 #include drm/drm_crtc_helper.h
 
-#include linux/anon_inodes.h
 #include linux/component.h
 
 #include drm/exynos_drm.h
@@ -149,10 +148,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }
 
-static const struct file_operations exynos_drm_gem_fops = {
-   .mmap = exynos_drm_gem_mmap_buffer,
-};
-
 static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
 {
struct drm_connector *connector;
@@ -191,7 +186,6 @@ static int exynos_drm_resume(struct drm_device *dev)
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv;
-   struct file *anon_filp;
int ret;
 
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +198,8 @@ static int exynos_drm_open(struct drm_device *dev, struct 
drm_file *file)
if (ret)
goto err_file_priv_free;
 
-   anon_filp = anon_inode_getfile(exynos_gem, exynos_drm_gem_fops,
-   NULL, 0);
-   if (IS_ERR(anon_filp)) {
-   ret = PTR_ERR(anon_filp);
-   goto err_subdrv_close;
-   }
-
-   anon_filp-f_mode = FMODE_READ | FMODE_WRITE;
-   file_priv-anon_filp = anon_filp;
-
return ret;
 
-err_subdrv_close:
-   exynos_drm_subdrv_close(dev, file);
-
 err_file_priv_free:
kfree(file_priv);
file-driver_priv = NULL;
@@ -234,7 +215,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
 {
struct exynos_drm_private *private = dev-dev_private;
-   struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +240,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
}
spin_unlock_irqrestore(dev-event_lock, flags);
 
-   file_priv = file-driver_priv;
-   if (file_priv-anon_filp)
-   fput(file_priv-anon_filp);
-
kfree(file-driver_priv);
file-driver_priv = NULL;
 }
@@ -282,8 +258,6 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
-   exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
struct device   *ipp_dev;
-   struct file *anon_filp;
 };
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..0d5b969 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,16 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }
 
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int

Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver



On Thursday 18 September 2014 12:34 AM, Peter Griffin wrote:
 Hi Kishon,
 
 On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote:
 
 Hi,

 On Friday 15 August 2014 06:10 PM, Peter Griffin wrote:
 This patch removes the superflous .owner field for drivers which
 use the module_platform_driver or platform_driver_register api,
 as this is overriden in __platform_driver_register.

 Signed-off-by: Peter Griffin peter.grif...@linaro.org
 
 snip
  drivers/phy/phy-twl4030-usb.c   | 1 -

 twl4030-usb doesn't use module_platform_driver. Care to resend this patch
 along? I've merged all other patches in this series.
 
 That is true, but it does use platform_driver_register  whih overrides .owner.
 So the patch is stil good I think (fyi see include/linux/platform_device.h).

Indeed. Will merge this one.

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

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

Hi Tomi,

On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 17/09/14 17:29, Ajay kumar wrote:
 Hi Tomi,

 Thanks for your comments.

 On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
 On 27/08/14 17:39, Ajay Kumar wrote:
 Add documentation for DT properties supported by ps8622/ps8625
 eDP-LVDS converter.

 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
 
  1 file changed, 20 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/video/bridge/ps8622.txt

 diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
 b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 new file mode 100644
 index 000..0ec8172
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
 @@ -0,0 +1,20 @@
 +ps8622-bridge bindings
 +
 +Required properties:
 + - compatible: parade,ps8622 or parade,ps8625
 + - reg: first i2c address of the bridge
 + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
 + - reset-gpios: OF device-tree gpio specification for RST_ pin.
 +
 +Optional properties:
 + - lane-count: number of DP lanes to use
 + - use-external-pwm: backlight will be controlled by an external PWM

 What does this mean? That the backlight support from ps8625 is not used?
 If so, maybe disable-pwm or something?
 use-external-pwm or disable-bridge-pwm would be better.

 Well, the properties are about the bridge. use-external-pwm means that
 the bridge uses an external PWM, which, if I understood correctly, is
 not what the property is about.

 disable-bridge-pwm is ok, but the bridge there is extra. The
 properties are about the bridge, so it's implicit.
Ok. I will use disable-pwm.

 +
 +Example:
 + lvds-bridge@48 {
 + compatible = parade,ps8622;
 + reg = 0x48;
 + sleep-gpios = gpc3 6 1 0 0;
 + reset-gpios = gpc3 1 1 0 0;
 + lane-count = 1;
 + };


 I wish all new display component bindings would use the video
 ports/endpoints to describe the connections. It will be very difficult
 to improve the display driver model later if we're missing such critical
 pieces from the DT bindings.
 Why do we need a complex graph when it can be handled using a simple phandle?

 Maybe in your case you can handle it with simple phandle. Can you
 guarantee that it's enough for everyone, on all platforms?
Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
this. In case of both, the phandle to bridge node is passed to the
exynos_dp node.

 The point of the ports/endpoint graph is to also support more
 complicated scenarios. If you now create ps8622 bindings that do not
 support those graphs, the no one else using ps8622 can use
 ports/endpoint graphs either.

 Btw, is there an example how the bridge with these bindings is used in a
 board's .dts file? I couldn't find any example with a quick search. So
 it's unclear to me what the simple phandle actually is.
Please refer to the following link:
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
Let me know if you still think we would need to describe it as a complex graph!

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

Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register