date:20151211

Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Marek Szyprowski


Hi Inki,

On 2015-12-11 10:57, Inki Dae wrote:

Hi Marek,

2015년 12월 11일 18:26에 Marek Szyprowski 이(가) 쓴 글:

Hi Inki,

On 2015-12-11 10:02, Inki Dae wrote:

Hi Marek,

I found out why NULL point access happened. That was incurred by below your 
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the new 
crtc driver
so the driver should get the drm framebuffer object from the plane's state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.

After that, I think the drm framebuffer should be set to drm plane as a current 
fb
which would be scanned out.

Anyway, I can fix it like below if you are ok.

Thanks,
Inki Dae

--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
  if (ctx->suspended)
  return;
   -   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+   addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
  DRM_DEBUG_KMS("dma_addr = %pad\n", );

+plane->base.fb = plane->pending_fb;

plane->base.fb should not be modified. I think that the following fix is more

Could you explain why plane->base.fb shouldn't be modified?


All 'base' classes are modified by DRM core and there should be no need
to modify them from the drivers.

I've checked this issue and the proper fix for is the following code:

--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct 
exynos_drm_crtc *crtc)

 static void vidi_update_plane(struct exynos_drm_crtc *crtc,
  struct exynos_drm_plane *plane)
 {
+   struct drm_plane_state *state = plane->base.state;
struct vidi_context *ctx = crtc->ctx;
dma_addr_t addr;

if (ctx->suspended)
return;

-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+   addr = exynos_drm_fb_dma_addr(state->fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", );

if (ctx->vblank_on)


plane->base.fb is updated from the core once all crtc/plane atomic update
calls finishes. The drivers should use the fb stored in plane->base.state.
I've missed that VIDI driver doesn't get the fb and incorrectly used
plane->base.fb instad of state->fb while updating the code.



In case that userspace requests setplane, plane->base.fb would be updated after 
update_plane callback.
However, in other cases, I don't see how plane->base.fb could be updated.
In this case, I think vendor specific drivers would need to update it as a 
current fb to be scanned out like other some drivers did.
Of course, it may be possible for drm core part to take care of it 
appropriately later.

Thanks,
Inki Dae


appropriate:
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -132,12 +132,13 @@ static void vidi_update_plane(struct exynos_drm_crtc 
*crtc,
   struct exynos_drm_plane *plane)
  {
 struct vidi_context *ctx = crtc->ctx;
-   dma_addr_t addr;
+   dma_addr_t addr = 0;

 if (ctx->suspended)
 return;

-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+   if (plane->base.fb)
+   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
 DRM_DEBUG_KMS("dma_addr = %pad\n", );

 if (ctx->vblank_on)

I will investigate the case of NULL plane->state.fb, because it might be 
relevant
to other crtc drivers as well.



if (ctx->vblank_on)


2015년 12월 10일 22:05에 Inki Dae 이(가) 쓴 글:

2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:

DMA address is a framebuffer attribute and the right place for it is
exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
helper function for getting dma address of the given framebuffer.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Gustavo Padovan 
---
   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
   drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
   drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 ---
   drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
   drivers/gpu/drm/exynos/exynos_drm_fb.h|  3 +--
   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 10 ++
   drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
   drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  5 -
   drivers/gpu/drm/exynos/exynos_mixer.c |  7 ---
   9 files changed, 38 insertions(+), 53 deletions(-)


<--snip-->


diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 669362c53f49..3ce141236fad 100644
---

Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae

Hi Marek,

2015년 12월 11일 18:26에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
> 
> On 2015-12-11 10:02, Inki Dae wrote:
>> Hi Marek,
>>
>> I found out why NULL point access happened. That was incurred by below your 
>> patch,
>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>>
>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>> the drm frambuffer object of fb_helper is set to the plane state of the new 
>> crtc driver
>> so the driver should get the drm framebuffer object from the plane's state or
>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
>>
>> After that, I think the drm framebuffer should be set to drm plane as a 
>> current fb
>> which would be scanned out.
>>
>> Anyway, I can fix it like below if you are ok.
>>
>> Thanks,
>> Inki Dae
>>
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc 
>> *crtc,
>>  if (ctx->suspended)
>>  return;
>>   -   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> +   addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>>  DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>
>> +plane->base.fb = plane->pending_fb;
> 
> plane->base.fb should not be modified. I think that the following fix is more

Could you explain why plane->base.fb shouldn't be modified?

In case that userspace requests setplane, plane->base.fb would be updated after 
update_plane callback.
However, in other cases, I don't see how plane->base.fb could be updated.
In this case, I think vendor specific drivers would need to update it as a 
current fb to be scanned out like other some drivers did.
Of course, it may be possible for drm core part to take care of it 
appropriately later.

Thanks,
Inki Dae

> appropriate:
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct exynos_drm_crtc 
> *crtc,
>   struct exynos_drm_plane *plane)
>  {
> struct vidi_context *ctx = crtc->ctx;
> -   dma_addr_t addr;
> +   dma_addr_t addr = 0;
> 
> if (ctx->suspended)
> return;
> 
> -   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> +   if (plane->base.fb)
> +   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", );
> 
> if (ctx->vblank_on)
> 
> I will investigate the case of NULL plane->state.fb, because it might be 
> relevant
> to other crtc drivers as well.
> 
> 
>>if (ctx->vblank_on)
>>
>>
>> 2015년 12월 10일 22:05에 Inki Dae 이(가) 쓴 글:
>>>
>>> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
 DMA address is a framebuffer attribute and the right place for it is
 exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
 helper function for getting dma address of the given framebuffer.

 Signed-off-by: Marek Szyprowski 
 Reviewed-by: Gustavo Padovan 
 ---
   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
   drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
   drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 ---
   drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
   drivers/gpu/drm/exynos/exynos_drm_fb.h|  3 +--
   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 10 ++
   drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
   drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  5 -
   drivers/gpu/drm/exynos/exynos_mixer.c |  7 ---
   9 files changed, 38 insertions(+), 53 deletions(-)

>>> <--snip-->
>>>
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 index 669362c53f49..3ce141236fad 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 @@ -24,6 +24,7 @@
 #include "exynos_drm_drv.h"
   #include "exynos_drm_crtc.h"
 +#include "exynos_drm_fb.h"
   #include "exynos_drm_plane.h"
   #include "exynos_drm_vidi.h"
   @@ -126,11 +127,13 @@ static void vidi_update_plane(struct 
 exynos_drm_crtc *crtc,
 struct exynos_drm_plane *plane)
   {
   struct vidi_context *ctx = crtc->ctx;
 +dma_addr_t addr;
 if (ctx->suspended)
   return;
   -DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
 +addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> At this point, plane->base.fb is NULL so null pointer access happens like 
>>> below,
>>>
>>> [5.969422] Unable to handle kernel NULL pointer dereference at virtual 
>>> address 0090
>>> [5.977481] pgd = ee59
>>>

Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Marek Szyprowski


Hi Inki,

On 2015-12-11 10:02, Inki Dae wrote:

Hi Marek,

I found out why NULL point access happened. That was incurred by below your 
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the new 
crtc driver
so the driver should get the drm framebuffer object from the plane's state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.

After that, I think the drm framebuffer should be set to drm plane as a current 
fb
which would be scanned out.

Anyway, I can fix it like below if you are ok.

Thanks,
Inki Dae

--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
 if (ctx->suspended)
 return;
  
-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);

+   addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
 DRM_DEBUG_KMS("dma_addr = %pad\n", );

+   plane->base.fb = plane->pending_fb;


plane->base.fb should not be modified. I think that the following fix is 
more

appropriate:
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -132,12 +132,13 @@ static void vidi_update_plane(struct 
exynos_drm_crtc *crtc,

  struct exynos_drm_plane *plane)
 {
struct vidi_context *ctx = crtc->ctx;
-   dma_addr_t addr;
+   dma_addr_t addr = 0;

if (ctx->suspended)
return;

-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+   if (plane->base.fb)
+   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", );

if (ctx->vblank_on)

I will investigate the case of NULL plane->state.fb, because it might be 
relevant

to other crtc drivers as well.


  
 if (ctx->vblank_on)



2015년 12월 10일 22:05에 Inki Dae 이(가) 쓴 글:


2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:

DMA address is a framebuffer attribute and the right place for it is
exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
helper function for getting dma address of the given framebuffer.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Gustavo Padovan 
---
  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 ---
  drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
  drivers/gpu/drm/exynos/exynos_drm_fb.h|  3 +--
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 10 ++
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  5 -
  drivers/gpu/drm/exynos/exynos_mixer.c |  7 ---
  9 files changed, 38 insertions(+), 53 deletions(-)


<--snip-->


diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 669362c53f49..3ce141236fad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -24,6 +24,7 @@
  
  #include "exynos_drm_drv.h"

  #include "exynos_drm_crtc.h"
+#include "exynos_drm_fb.h"
  #include "exynos_drm_plane.h"
  #include "exynos_drm_vidi.h"
  
@@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,

  struct exynos_drm_plane *plane)
  {
struct vidi_context *ctx = crtc->ctx;
+   dma_addr_t addr;
  
  	if (ctx->suspended)

return;
  
-	DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);

+   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);

At this point, plane->base.fb is NULL so null pointer access happens like below,

[5.969422] Unable to handle kernel NULL pointer dereference at virtual 
address 0090
[5.977481] pgd = ee59
[5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
[5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[5.991712] Modules linked in:
[5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted 
4.4.0-rc3-00052-gc60d7e2-dirty #199
[6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
[6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
[6.018990] LR is at vidi_update_plane+0x4c/0xc4
[6.023581] pc : []lr : []psr: 8013
[6.023581] sp : ee4d5d90  ip : 0001  fp : 
[6.035029] r10:   r9 : c05b965c  r8 : ee813e00
[6.040241] r7 :   r6 : ee8e3330  r5 :   r4 : ee8e3010
[6.046749] r3 :   r2 :   r1 : 0024  r0 : 
[6.053264] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

2015-12-11 Thread Linus Walleij

On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
 wrote:

> This patch adds documentation for the gpio-switch binding. This binding
> provides a mechanism to bind named links to gpio, with the primary
> purpose of enabling standardised access to switches that might be standard
> across a group of devices but implemented differently on each device.
>
> Signed-off-by: Martyn Welch 

As mentioned in the comment to the second patch, this solves the
following generic problem:

Expose a GPIO line to userspace using a specific name

That means basically naming GPIO lines and marking them as
"not used by the operating system".

This is something that has been proposed before, and postponed
because the kernel lacks the right infrastructure.

Markus Pargmann also did a series that add initial values to
hogs, which is the inverse usecase of this, where you want to
*output* something by default, then maybe also make it available
to userspace.

So what we need to see here is a patch series that does all of these
things:

- Name lines

- Sets them to initial values

- Mark them as read-only

- Mark them as "not used by the operating system" so that they
  can be default-exported to userspace.

Making *USE* of this naming etc inside the Linux kernel

> +gpio-switch {
> +compatible = "gpio-switch";
> +
> +write-protect {
> +label = "write-protect";
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +read-only;
> +};

This should not need new structures and nodes like this. It should
be part of Documentation/devicetree/bindings/gpio/gpio.txt
and put directly in the gpiochip node.

Maybe as an extension of the existing hogs, but that has already
been tried.

While we can agree on a device tree binding, the kernel still needs
major refactoring to actually expose named GPIOs to userspace,
and that should be done using the new chardev, not with sysfs
links.

Yours,
Linus Walleij
--
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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Dan Carpenter

On Fri, Dec 11, 2015 at 02:53:20PM +0100, Boris Brezillon wrote:
> Hi Brian,
> 
> On Thu, 10 Dec 2015 16:40:08 -0800
> Brian Norris  wrote:
> 
> > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > Unregister the NAND device from the NAND subsystem when removing a denali
> > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > exposed by the MTD layer, and accesses to this device will likely crash
> > > the system.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Cc:  #3.8+
> > 
> > Does this follow these rules, from
> > Documentation/stable_kernel_rules.txt?
> > 
> >  - It must be obviously correct and tested.
> > 
> >  - It must fix a real bug that bothers people (not a, "This could be a
> >problem..." type thing).
> 
> As you wish, I'll remove those Cc and Fixes tags, or just drop the
> patch if you think it's useless...

The fixes tag is a separate thing from CCing stable.  It's useful on by
itself.  I always put the person who wrote the original patch in the To:
header so they can review and comment if I have made a mistake.

regards,
dan carpenter

--
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 v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae

Hi Marek,

2015-12-11 20:27 GMT+09:00 Marek Szyprowski :
> Hi Inki,
>
>
> On 2015-12-11 10:57, Inki Dae wrote:
>>
>> Hi Marek,
>>
>> 2015년 12월 11일 18:26에 Marek Szyprowski 이(가) 쓴 글:
>>>
>>> Hi Inki,
>>>
>>> On 2015-12-11 10:02, Inki Dae wrote:

 Hi Marek,

 I found out why NULL point access happened. That was incurred by below
 your patch,
 [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos
 fb

 When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
 the drm frambuffer object of fb_helper is set to the plane state of the
 new crtc driver
 so the driver should get the drm framebuffer object from the plane's
 state or
 exynos_plane->pending_fb which is set by exynos_plane_atomic_update
 function.

 After that, I think the drm framebuffer should be set to drm plane as a
 current fb
 which would be scanned out.

 Anyway, I can fix it like below if you are ok.

 Thanks,
 Inki Dae

 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
 *crtc,
   if (ctx->suspended)
   return;
-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
 +   addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
   DRM_DEBUG_KMS("dma_addr = %pad\n", );

 +plane->base.fb = plane->pending_fb;
>>>
>>> plane->base.fb should not be modified. I think that the following fix is
>>> more
>>
>> Could you explain why plane->base.fb shouldn't be modified?
>
>
> All 'base' classes are modified by DRM core and there should be no need
> to modify them from the drivers.

Ok, If so - drm core updates plane->fb - then it's reasonable. But I
couldn't find the exact location where plane->fb is set to a fb to be
scanned out.
So could you let me know the exact location? it's not clear to me yet.

>
> I've checked this issue and the proper fix for is the following code:
>
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct exynos_drm_crtc
> *crtc)
>  static void vidi_update_plane(struct exynos_drm_crtc *crtc,
>   struct exynos_drm_plane *plane)
>  {
> +   struct drm_plane_state *state = plane->base.state;
> struct vidi_context *ctx = crtc->ctx;
> dma_addr_t addr;
>
> if (ctx->suspended)
> return;
>
> -   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> +   addr = exynos_drm_fb_dma_addr(state->fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>
> if (ctx->vblank_on)
>
>
> plane->base.fb is updated from the core once all crtc/plane atomic update
> calls finishes. The drivers should use the fb stored in plane->base.state.
> I've missed that VIDI driver doesn't get the fb and incorrectly used
> plane->base.fb instad of state->fb while updating the code.
>

Actually, I used state->fb instead of plane->pending_fb but in
exynos_plane_atomic_update function, plane->pending_fb is set to
state->fb.
That is why I commented like below,
" so the driver should get the drm framebuffer object from the plane's
state or exynos_plane->pending_fb which is set by
exynos_plane_atomic_update function."

Anyway, using state->fb looks like more consistent with other drivers,
fimd, decon and mixer.

Thanks,
Inki Dae

>
>
>> In case that userspace requests setplane, plane->base.fb would be updated
>> after update_plane callback.
>> However, in other cases, I don't see how plane->base.fb could be updated.
>> In this case, I think vendor specific drivers would need to update it as a
>> current fb to be scanned out like other some drivers did.
>> Of course, it may be possible for drm core part to take care of it
>> appropriately later.
>>
>> Thanks,
>> Inki Dae
>>
>>> appropriate:
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct
>>> exynos_drm_crtc *crtc,
>>>struct exynos_drm_plane *plane)
>>>   {
>>>  struct vidi_context *ctx = crtc->ctx;
>>> -   dma_addr_t addr;
>>> +   dma_addr_t addr = 0;
>>>
>>>  if (ctx->suspended)
>>>  return;
>>>
>>> -   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> +   if (plane->base.fb)
>>> +   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>>  DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>>
>>>  if (ctx->vblank_on)
>>>
>>> I will investigate the case of NULL plane->state.fb, because it might be
>>> relevant
>>> to other crtc drivers as well.
>>>
>>>
 if (ctx->vblank_on)


 2015년 12월 10일 22:05에 Inki Dae 이(가) 쓴 글:
>
> 2015년 11월 30일

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

2015-12-11 Thread Rob Herring

On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij  wrote:
> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>  wrote:
>
>> This patch adds documentation for the gpio-switch binding. This binding
>> provides a mechanism to bind named links to gpio, with the primary
>> purpose of enabling standardised access to switches that might be standard
>> across a group of devices but implemented differently on each device.
>>
>> Signed-off-by: Martyn Welch 
>
> As mentioned in the comment to the second patch, this solves the
> following generic problem:
>
> Expose a GPIO line to userspace using a specific name
>
> That means basically naming GPIO lines and marking them as
> "not used by the operating system".
>
> This is something that has been proposed before, and postponed
> because the kernel lacks the right infrastructure.

That doesn't necessarily mean we can't define a binding.

> Markus Pargmann also did a series that add initial values to
> hogs, which is the inverse usecase of this, where you want to
> *output* something by default, then maybe also make it available
> to userspace.
>
> So what we need to see here is a patch series that does all of these
> things:
>
> - Name lines
>
> - Sets them to initial values
>
> - Mark them as read-only
>
> - Mark them as "not used by the operating system" so that they
>   can be default-exported to userspace.

No! This should not be a DT property.

Whether I want to control a GPIO in the kernel or userspace is not
known and can change over time. It could simply depend on kernel
config. There is also the case that a GPIO has no connection or kernel
driver until some time later when a DT overlay for an expansion board
is applied.

Rob
--
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 v5 41/58] mtd: nand: socrates: use the mtd instance embedded in struct nand_chip

2015-12-11 Thread Boris Brezillon

struct nand_chip now embeds an mtd device. Make use of this mtd instance.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- fix build error

---
Changes generated with the following coccinelle script

--->8---
virtual patch

@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
-   struct mtd_info __mtdfield;
...
};
|
__type {
...
-   struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)

@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
-   __priv->__mtdfield.__subfield
+   nand_to_mtd(&__priv->__chipfield)->__subfield
|
-   &(__priv->__mtdfield)
+   nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
 drivers/mtd/nand/socrates_nand.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/socrates_nand.c b/drivers/mtd/nand/socrates_nand.c
index 2dfb1e0..925761c 100644
--- a/drivers/mtd/nand/socrates_nand.c
+++ b/drivers/mtd/nand/socrates_nand.c
@@ -30,7 +30,6 @@
 
 struct socrates_nand_host {
struct nand_chipnand_chip;
-   struct mtd_info mtd;
void __iomem*io_base;
struct device   *dev;
 };
@@ -159,8 +158,8 @@ static int socrates_nand_probe(struct platform_device 
*ofdev)
return -EIO;
}
 
-   mtd = >mtd;
nand_chip = >nand_chip;
+   mtd = nand_to_mtd(nand_chip);
host->dev = >dev;
 
nand_chip->priv = host; /* link the private data structures */
@@ -216,7 +215,7 @@ out:
 static int socrates_nand_remove(struct platform_device *ofdev)
 {
struct socrates_nand_host *host = dev_get_drvdata(>dev);
-   struct mtd_info *mtd = >mtd;
+   struct mtd_info *mtd = nand_to_mtd(>nand_chip);
 
nand_release(mtd);
 
-- 
2.1.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

[PATCH] clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs

2015-12-11 Thread Marek Szyprowski

It is allowed to enable/disable clocks from interrupts, so common Exynos
ARM clock management code for CPUfreq should use 'irqsave' version of
spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
The same spin_lock is used by gate/mux clocks during enable/disable calls.

This deadlock, can be reproduced by enabling CPUfreq (ondemand or
userspace) and decoding video with s5p-mfc driver.

Relevant stack trace:
[ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252
[ 5928.061609]  lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, 
.owner_cpu: 0
[ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: GW   
4.4.0-rc4-1-g447a7fd #678
[ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5928.083359] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 5928.091072] [] (show_stack) from [] 
(dump_stack+0x68/0xb8)
[ 5928.098275] [] (dump_stack) from [] 
(do_raw_spin_lock+0x184/0x1ac)
[ 5928.106177] [] (do_raw_spin_lock) from [] 
(_raw_spin_lock_irqsave+0x20/0x28)
[ 5928.114943] [] (_raw_spin_lock_irqsave) from [] 
(clk_gate_endisable+0x24/0x98)
[ 5928.123882] [] (clk_gate_endisable) from [] 
(clk_core_disable+0x60/0x84)
[ 5928.132299] [] (clk_core_disable) from [] 
(clk_disable+0x24/0x30)
[ 5928.140117] [] (clk_disable) from [] 
(s5p_mfc_handle_frame+0x254/0x860)
[ 5928.148445] [] (s5p_mfc_handle_frame) from [] 
(s5p_mfc_irq+0x890/0xa24)
[ 5928.156778] [] (s5p_mfc_irq) from [] 
(handle_irq_event_percpu+0x50/0x14c)
[ 5928.165283] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[ 5928.174143] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xdc/0x1a4)
[ 5928.182645] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x18/0x28)
[ 5928.191236] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x6c/0xdc)
[ 5928.199917] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x4c/0x98)
[ 5928.208249] [] (gic_handle_irq) from [] 
(__irq_svc+0x54/0x90)
[ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00)
[ 5928.220745] 5ca0:   
ee80454c faddfadc
[ 5928.228906] 5cc0:  0101 ee831ce0 f8114200 ee807c00 01130520 
0403 eddb5d84
[ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 
2053 
[ 5928.245225] [] (__irq_svc) from [] 
(exynos_cpuclk_notifier_cb+0x170/0x270)
[ 5928.253823] [] (exynos_cpuclk_notifier_cb) from [] 
(notifier_call_chain+0x44/0x84)
[ 5928.263106] [] (notifier_call_chain) from [] 
(__srcu_notifier_call_chain+0x6c/0x9c)
[ 5928.272480] [] (__srcu_notifier_call_chain) from [] 
(srcu_notifier_call_chain+0x18/0x20)
[ 5928.282288] [] (srcu_notifier_call_chain) from [] 
(__clk_notify+0x6c/0x74)
[ 5928.290881] [] (__clk_notify) from [] 
(clk_propagate_rate_change+0xa0/0xac)
[ 5928.299561] [] (clk_propagate_rate_change) from [] 
(clk_propagate_rate_change+0x90/0xac)
[ 5928.309370] [] (clk_propagate_rate_change) from [] 
(clk_core_set_rate_nolock+0x64/0xa8)
[ 5928.319091] [] (clk_core_set_rate_nolock) from [] 
(clk_set_rate+0x20/0x30)
[ 5928.327686] [] (clk_set_rate) from [] 
(set_target+0xe8/0x23c)
[ 5928.335152] [] (set_target) from [] 
(__cpufreq_driver_target+0x184/0x29c)
[ 5928.343655] [] (__cpufreq_driver_target) from [] 
(cpufreq_set+0x44/0x64)
[ 5928.352074] [] (cpufreq_set) from [] 
(store_scaling_setspeed+0x5c/0x74)
[ 5928.360407] [] (store_scaling_setspeed) from [] 
(store+0x7c/0x98)
[ 5928.368221] [] (store) from [] (sysfs_kf_write+0x44/0x48)
[ 5928.375338] [] (sysfs_kf_write) from [] 
(kernfs_fop_write+0xb8/0x1bc)
[ 5928.383496] [] (kernfs_fop_write) from [] 
(__vfs_write+0x2c/0xd4)
[ 5928.391308] [] (__vfs_write) from [] 
(vfs_write+0xa0/0x144)
[ 5928.398598] [] (vfs_write) from [] (SyS_write+0x44/0x84)
[ 5928.405631] [] (SyS_write) from [] 
(ret_fast_syscall+0x0/0x3c)

Signed-off-by: Marek Szyprowski 
CC: sta...@vger.kernel.org  # v4.2+
---
 drivers/clk/samsung/clk-cpu.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index 2fe37f708dc7..813003d6ce09 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -148,6 +148,7 @@ static int exynos_cpuclk_pre_rate_change(struct 
clk_notifier_data *ndata,
unsigned long alt_prate = clk_get_rate(cpuclk->alt_parent);
unsigned long alt_div = 0, alt_div_mask = DIV_MASK;
unsigned long div0, div1 = 0, mux_reg;
+   unsigned long flags;
 
/* find out the divider values to use for clock data */
while ((cfg_data->prate * 1000) != ndata->new_rate) {
@@ -156,7 +157,7 @@ static int exynos_cpuclk_pre_rate_change(struct 
clk_notifier_data *ndata,
cfg_data++;
}
 
-   spin_lock(cpuclk->lock);
+   spin_lock_irqsave(cpuclk->lock, flags);
 
/*
 * For the selected PLL clock frequency, get the pre-defined divider
@@ -212,7 +213,7 @@ static int

Re: [PATCH 03/10] media framework: rename pads init function to media_entity_pads_init()

2015-12-11 Thread Jacek Anaszewski


On 12/11/2015 02:34 PM, Mauro Carvalho Chehab wrote:

With the MC next gen rework, what's left for media_entity_init()
is to just initialize the PADs. However, certain devices, like
a FLASH led/light doesn't have any input or output PAD.

So, there's no reason why calling media_entity_init() would be
mandatory. Also, despite its name, what this function actually
does is to initialize the PADs data. So, rename it to
media_entity_pads_init() in order to reflect that.

The media entity actual init happens during entity register,
at media_device_register_entity(). We should move init of
num_links and num_backlinks to it.

Signed-off-by: Mauro Carvalho Chehab 

[...]

diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c 
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5c686a24712b..13d5a36bc5d8 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -651,7 +651,7 @@ struct v4l2_flash *v4l2_flash_init(
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
strlcpy(sd->name, config->dev_name, sizeof(sd->name));

-   ret = media_entity_init(>entity, 0, NULL);
+   ret = media_entity_pads_init(>entity, 0, NULL);
if (ret < 0)
return ERR_PTR(ret);



For this part:

Acked-by: Jacek Anaszewski 

--
Best Regards,
Jacek Anaszewski
--
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 03/10] media framework: rename pads init function to media_entity_pads_init()

2015-12-11 Thread Mauro Carvalho Chehab

With the MC next gen rework, what's left for media_entity_init()
is to just initialize the PADs. However, certain devices, like
a FLASH led/light doesn't have any input or output PAD.

So, there's no reason why calling media_entity_init() would be
mandatory. Also, despite its name, what this function actually
does is to initialize the PADs data. So, rename it to
media_entity_pads_init() in order to reflect that.

The media entity actual init happens during entity register,
at media_device_register_entity(). We should move init of
num_links and num_backlinks to it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media-framework.txt  | 18 +++---
 Documentation/video4linux/v4l2-framework.txt   |  8 
 Documentation/zh_CN/video4linux/v4l2-framework.txt |  8 
 drivers/media/dvb-core/dvbdev.c|  4 ++--
 drivers/media/dvb-frontends/au8522_decoder.c   |  2 +-
 drivers/media/i2c/ad9389b.c|  2 +-
 drivers/media/i2c/adp1653.c|  2 +-
 drivers/media/i2c/adv7180.c|  2 +-
 drivers/media/i2c/adv7511.c|  2 +-
 drivers/media/i2c/adv7604.c|  2 +-
 drivers/media/i2c/adv7842.c|  2 +-
 drivers/media/i2c/as3645a.c|  2 +-
 drivers/media/i2c/cx25840/cx25840-core.c   |  2 +-
 drivers/media/i2c/lm3560.c |  2 +-
 drivers/media/i2c/lm3646.c |  2 +-
 drivers/media/i2c/m5mols/m5mols_core.c |  2 +-
 drivers/media/i2c/mt9m032.c|  2 +-
 drivers/media/i2c/mt9p031.c|  2 +-
 drivers/media/i2c/mt9t001.c|  2 +-
 drivers/media/i2c/mt9v032.c|  2 +-
 drivers/media/i2c/noon010pc30.c|  2 +-
 drivers/media/i2c/ov2659.c |  2 +-
 drivers/media/i2c/ov9650.c |  2 +-
 drivers/media/i2c/s5c73m3/s5c73m3-core.c   |  4 ++--
 drivers/media/i2c/s5k4ecgx.c   |  2 +-
 drivers/media/i2c/s5k5baf.c|  4 ++--
 drivers/media/i2c/s5k6a3.c |  2 +-
 drivers/media/i2c/s5k6aa.c |  2 +-
 drivers/media/i2c/smiapp/smiapp-core.c |  6 +++---
 drivers/media/i2c/tc358743.c   |  2 +-
 drivers/media/i2c/tvp514x.c|  2 +-
 drivers/media/i2c/tvp7002.c|  2 +-
 drivers/media/media-device.c   |  2 ++
 drivers/media/media-entity.c   | 11 ---
 drivers/media/platform/exynos4-is/fimc-capture.c   |  4 ++--
 drivers/media/platform/exynos4-is/fimc-isp-video.c |  2 +-
 drivers/media/platform/exynos4-is/fimc-isp.c   |  2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |  4 ++--
 drivers/media/platform/exynos4-is/fimc-m2m.c   |  2 +-
 drivers/media/platform/exynos4-is/mipi-csis.c  |  2 +-
 drivers/media/platform/omap3isp/ispccdc.c  |  2 +-
 drivers/media/platform/omap3isp/ispccp2.c  |  2 +-
 drivers/media/platform/omap3isp/ispcsi2.c  |  2 +-
 drivers/media/platform/omap3isp/isppreview.c   |  2 +-
 drivers/media/platform/omap3isp/ispresizer.c   |  2 +-
 drivers/media/platform/omap3isp/ispstat.c  |  2 +-
 drivers/media/platform/omap3isp/ispvideo.c |  2 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |  4 ++--
 drivers/media/platform/vsp1/vsp1_entity.c  |  2 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  2 +-
 drivers/media/platform/xilinx/xilinx-dma.c |  2 +-
 drivers/media/platform/xilinx/xilinx-tpg.c |  2 +-
 drivers/media/usb/au0828/au0828-video.c|  6 +++---
 drivers/media/usb/cx231xx/cx231xx-video.c  |  4 ++--
 drivers/media/usb/uvc/uvc_entity.c |  4 ++--
 drivers/media/v4l2-core/tuner-core.c   |  2 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c   |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |  2 +-
 drivers/staging/media/davinci_vpfe/dm365_isif.c|  2 +-
 drivers/staging/media/davinci_vpfe/dm365_resizer.c |  6 +++---
 drivers/staging/media/davinci_vpfe/vpfe_video.c|  2 +-
 drivers/staging/media/omap4iss/iss_csi2.c  |  2 +-
 drivers/staging/media/omap4iss/iss_ipipe.c |  2 +-
 drivers/staging/media/omap4iss/iss_ipipeif.c   |  2 +-
 drivers/staging/media/omap4iss/iss_resizer.c   |  2 +-
 drivers/staging/media/omap4iss/iss_video.c |  2 +-
 include/media/media-entity.h   |  2 +-
 68 files changed, 102 insertions(+), 99 deletions(-)

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index b424de6c3bb3..7fbfe4bd1f47 100644
---

[PATCH v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

Unregister the NAND device from the NAND subsystem when removing a denali
NAND controller, otherwise the MTD attached to the NAND device is still
exposed by the MTD layer, and accesses to this device will likely crash
the system.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- remove Cc stable and fixes tags
- calculate the dma buffer size before calling nand_release()

 drivers/mtd/nand/denali.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 67eb2be..fdfea05 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
 /* driver exit point */
 void denali_remove(struct denali_nand_info *denali)
 {
+   int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
+
+   nand_release(>mtd);
denali_irq_cleanup(denali->irq, denali);
-   dma_unmap_single(denali->dev, denali->buf.dma_buf,
-denali->mtd.writesize + denali->mtd.oobsize,
+   dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
 DMA_BIDIRECTIONAL);
 }
 EXPORT_SYMBOL(denali_remove);
-- 
2.1.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

[PATCH v5 15/58] mtd: nand: denali: use the mtd instance embedded in struct nand_chip

2015-12-11 Thread Boris Brezillon

struct nand_chip now embeds an mtd device. Make use of this mtd instance.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- fix conflict after changes brought in v5 of patch 1

---
Changes generated with the following coccinelle script

--->8---
virtual patch

@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
-   struct mtd_info __mtdfield;
...
};
|
__type {
...
-   struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)

@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
-   __priv->__mtdfield.__subfield
+   nand_to_mtd(&__priv->__chipfield)->__subfield
|
-   &(__priv->__mtdfield)
+   nand_to_mtd(&__priv->__chipfield)
)
--->8---

Conflicts:
drivers/mtd/nand/denali.c
---
 drivers/mtd/nand/denali.c | 69 ++-
 drivers/mtd/nand/denali.h |  1 -
 2 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index fdfea05..ccab8bc 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -75,7 +75,10 @@ MODULE_PARM_DESC(onfi_timing_mode,
  * this macro allows us to convert from an MTD structure to our own
  * device context (denali) structure.
  */
-#define mtd_to_denali(m) container_of(m, struct denali_nand_info, mtd)
+static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
+{
+   return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
+}
 
 /*
  * These constants are defined by the driver to enable common driver
@@ -986,6 +989,8 @@ static bool handle_ecc(struct denali_nand_info *denali, 
uint8_t *buf,
 * than one NAND connected.
 */
if (err_byte < ECC_SECTOR_SIZE) {
+   struct mtd_info *mtd =
+   nand_to_mtd(>nand);
int offset;
 
offset = (err_sector *
@@ -995,7 +1000,7 @@ static bool handle_ecc(struct denali_nand_info *denali, 
uint8_t *buf,
err_device;
/* correct the ECC error */
buf[offset] ^= err_correction_value;
-   denali->mtd.ecc_stats.corrected++;
+   mtd->ecc_stats.corrected++;
bitflips++;
}
} else {
@@ -1062,7 +1067,7 @@ static int write_page(struct mtd_info *mtd, struct 
nand_chip *chip,
 {
struct denali_nand_info *denali = mtd_to_denali(mtd);
dma_addr_t addr = denali->buf.dma_buf;
-   size_t size = denali->mtd.writesize + denali->mtd.oobsize;
+   size_t size = mtd->writesize + mtd->oobsize;
uint32_t irq_status;
uint32_t irq_mask = INTR_STATUS__DMA_CMD_COMP |
INTR_STATUS__PROGRAM_FAIL;
@@ -1160,7 +1165,7 @@ static int denali_read_page(struct mtd_info *mtd, struct 
nand_chip *chip,
struct denali_nand_info *denali = mtd_to_denali(mtd);
 
dma_addr_t addr = denali->buf.dma_buf;
-   size_t size = denali->mtd.writesize + denali->mtd.oobsize;
+   size_t size = mtd->writesize + mtd->oobsize;
 
uint32_t irq_status;
uint32_t irq_mask = INTR_STATUS__ECC_TRANSACTION_DONE |
@@ -1193,14 +1198,14 @@ static int denali_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
denali_enable_dma(denali, false);
 
if (check_erased_page) {
-   read_oob_data(>mtd, chip->oob_poi, denali->page);
+   read_oob_data(mtd, chip->oob_poi, denali->page);
 
/* check ECC failures that may have occurred on erased pages */
if (check_erased_page) {
-   if (!is_erased(buf, denali->mtd.writesize))
-   denali->mtd.ecc_stats.failed++;
-   if (!is_erased(buf, denali->mtd.oobsize))
-   denali->mtd.ecc_stats.failed++;
+   if (!is_erased(buf, mtd->writesize))
+   mtd->ecc_stats.failed++;
+   if (!is_erased(buf, mtd->oobsize))
+   mtd->ecc_stats.failed++;
}
}
return max_bitflips;
@@ -1211,7 +1216,7 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
struct nand_chip *chip,
 {
struct denali_nand_info *denali =

Re: [PATCH v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Dinh Nguyen

Hi Boris,

On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
 wrote:
> + Dinh (who made commit 2a0a288ec258)
>
> Also added back the Fixes tag.
>
> On Fri, 11 Dec 2015 15:02:34 +0100
> Boris Brezillon  wrote:
>
>> Unregister the NAND device from the NAND subsystem when removing a denali
>> NAND controller, otherwise the MTD attached to the NAND device is still
>> exposed by the MTD layer, and accesses to this device will likely crash
>> the system.
>>
>> Signed-off-by: Boris Brezillon 
>
> Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
>
>> ---
>> Changes since v4:
>> - remove Cc stable and fixes tags
>> - calculate the dma buffer size before calling nand_release()
>>
>>  drivers/mtd/nand/denali.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> index 67eb2be..fdfea05 100644
>> --- a/drivers/mtd/nand/denali.c
>> +++ b/drivers/mtd/nand/denali.c
>> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>>  /* driver exit point */
>>  void denali_remove(struct denali_nand_info *denali)
>>  {
>> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
>> +
>> + nand_release(>mtd);
>>   denali_irq_cleanup(denali->irq, denali);
>> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
>> -  denali->mtd.writesize + denali->mtd.oobsize,
>> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>>DMA_BIDIRECTIONAL);

Not sure what is the need to add bufsize here, but the commit message
doesn't reflect the change.

Dinh
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

Hi Dinh,

On Fri, 11 Dec 2015 10:50:21 -0600
Dinh Nguyen  wrote:

> Hi Boris,
> 
> On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
>  wrote:
> > + Dinh (who made commit 2a0a288ec258)
> >
> > Also added back the Fixes tag.
> >
> > On Fri, 11 Dec 2015 15:02:34 +0100
> > Boris Brezillon  wrote:
> >
> >> Unregister the NAND device from the NAND subsystem when removing a denali
> >> NAND controller, otherwise the MTD attached to the NAND device is still
> >> exposed by the MTD layer, and accesses to this device will likely crash
> >> the system.
> >>
> >> Signed-off-by: Boris Brezillon 
> >
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> >
> >> ---
> >> Changes since v4:
> >> - remove Cc stable and fixes tags
> >> - calculate the dma buffer size before calling nand_release()
> >>
> >>  drivers/mtd/nand/denali.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> >> index 67eb2be..fdfea05 100644
> >> --- a/drivers/mtd/nand/denali.c
> >> +++ b/drivers/mtd/nand/denali.c
> >> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
> >>  /* driver exit point */
> >>  void denali_remove(struct denali_nand_info *denali)
> >>  {
> >> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
> >> +
> >> + nand_release(>mtd);
> >>   denali_irq_cleanup(denali->irq, denali);
> >> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >> -  denali->mtd.writesize + denali->mtd.oobsize,
> >> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
> >>DMA_BIDIRECTIONAL);
> 
> Not sure what is the need to add bufsize here, but the commit message
> doesn't reflect the change.

You were not in Cc of the first version (my fault), but Brian pointed
that the mtd fields could be in an unknown state after the
nand_release() call (this is currently not the case, but it change in
the future). The idea is to pre-compute the DMA buffer size before
releasing the mtd/nand device to prevent any future issues.

I don't think it is worth mentioning this in the commit message,
because these are just implementation details, but I can add the
following comment before the bufsize declaration:

/*
 * Pre-compute DMA buffer size to avoid any problems in case
 * nand_release() ever changes in a way that mtd->writesize and
 * mtd->oobsize are not reliable after this call.
 */

What do you think?

Best Regards,

Boris

> 
> Dinh



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

+ Dinh (who made commit 2a0a288ec258)

Also added back the Fixes tag.

On Fri, 11 Dec 2015 15:02:34 +0100
Boris Brezillon  wrote:

> Unregister the NAND device from the NAND subsystem when removing a denali
> NAND controller, otherwise the MTD attached to the NAND device is still
> exposed by the MTD layer, and accesses to this device will likely crash
> the system.
> 
> Signed-off-by: Boris Brezillon 

Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")

> ---
> Changes since v4:
> - remove Cc stable and fixes tags
> - calculate the dma buffer size before calling nand_release()
> 
>  drivers/mtd/nand/denali.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 67eb2be..fdfea05 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>  /* driver exit point */
>  void denali_remove(struct denali_nand_info *denali)
>  {
> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
> +
> + nand_release(>mtd);
>   denali_irq_cleanup(denali->irq, denali);
> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
> -  denali->mtd.writesize + denali->mtd.oobsize,
> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>DMA_BIDIRECTIONAL);
>  }
>  EXPORT_SYMBOL(denali_remove);



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

Hi Dan,

On Fri, 11 Dec 2015 17:39:47 +0300
Dan Carpenter  wrote:

> On Fri, Dec 11, 2015 at 02:53:20PM +0100, Boris Brezillon wrote:
> > Hi Brian,
> > 
> > On Thu, 10 Dec 2015 16:40:08 -0800
> > Brian Norris  wrote:
> > 
> > > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > > Unregister the NAND device from the NAND subsystem when removing a 
> > > > denali
> > > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > > exposed by the MTD layer, and accesses to this device will likely crash
> > > > the system.
> > > > 
> > > > Signed-off-by: Boris Brezillon 
> > > > Cc:  #3.8+
> > > 
> > > Does this follow these rules, from
> > > Documentation/stable_kernel_rules.txt?
> > > 
> > >  - It must be obviously correct and tested.
> > > 
> > >  - It must fix a real bug that bothers people (not a, "This could be a
> > >problem..." type thing).
> > 
> > As you wish, I'll remove those Cc and Fixes tags, or just drop the
> > patch if you think it's useless...
> 
> The fixes tag is a separate thing from CCing stable.  It's useful on by
> itself.  I always put the person who wrote the original patch in the To:
> header so they can review and comment if I have made a mistake.

Noted. I added back the Fixes tag and added Dinh Nguyen (the commit
author) in the loop.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: atomic check only enabled crtc states

2015-12-11 Thread Inki Dae

Hi Javier,

2015-12-09 19:51 GMT+09:00 Javier Martinez Canillas :
> Hello Inki,
>
> On 11/27/2015 10:00 AM, Javier Martinez Canillas wrote:
>> Hello Andrzej,
>>
>> On 11/27/2015 03:57 AM, Andrzej Hajda wrote:
>>> Since atomic check is called also for disabled crtcs it should skip
>>> mode checking as it can be uninitialized. The patch fixes it.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> Suggested-by: Daniel Vetter 
>>> ---
>>> Hi Javier,
>>>
>>> Could you check with this patch.
>>>
>>
>> The patch fixes the issue I reported. The display mode is correctly set
>> with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi:
>>
>> Tested-by: Javier Martinez Canillas 
>>
>
> This patch was never picked but fixes and important
> bug introduced in the v4.4 merge window so it should
> be sent during the v4.4-rc cycle.

Don't worry about that.

Thanks,
Inki Dae

>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

Hi Brian,

On Thu, 10 Dec 2015 16:40:08 -0800
Brian Norris  wrote:

> On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > Unregister the NAND device from the NAND subsystem when removing a denali
> > NAND controller, otherwise the MTD attached to the NAND device is still
> > exposed by the MTD layer, and accesses to this device will likely crash
> > the system.
> > 
> > Signed-off-by: Boris Brezillon 
> > Cc:  #3.8+
> 
> Does this follow these rules, from
> Documentation/stable_kernel_rules.txt?
> 
>  - It must be obviously correct and tested.
> 
>  - It must fix a real bug that bothers people (not a, "This could be a
>problem..." type thing).

Sorry to bring the "stable or not stable (that is the question :-))"
debate back, but after thinking a bit more about the implications of
this missing nand_release() call, I think it is worth backporting the
fix to all stable kernels.
The reason is, it can potentially introduce a security hole, because if
the mtd device is not unregister but the underlying mtd object is freed
and the kernel reuses the same memory region for a different object,
the MTD layer will possibly call one of the mtd->_method() function,
and this field might point to another completely different function.

You'll say that denali devices are probably never removed and this is
the reason why people have never seen this problem before, which would
be a good reason to not bother backporting the patch.
But, given that the driver can be compiled as a module (the user can
possibly load/unload it, which will in turn create/destroy the
NAND/MTD device), and that the denali controller can be exposed through
a PCI bus (which, AFAIK is hotpluggable), I really think this fix
should be sent to stable.

Best Regards,

Boris

> 
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> > ---
> >  drivers/mtd/nand/denali.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> > index 67eb2be..8feece3 100644
> > --- a/drivers/mtd/nand/denali.c
> > +++ b/drivers/mtd/nand/denali.c
> > @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
> >  /* driver exit point */
> >  void denali_remove(struct denali_nand_info *denali)
> >  {
> > +   nand_release(>mtd);
> > denali_irq_cleanup(denali->irq, denali);
> > dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >  denali->mtd.writesize + denali->mtd.oobsize,
> 
> It feels a bit odd to allow usage of MTD fields after it has been
> unregistered. Maybe precompute this before the nand_release()?
> 
> Brian

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Brian Norris

Hi Boris,

On Fri, Dec 11, 2015 at 11:03:05PM +0100, Boris Brezillon wrote:
> On Thu, 10 Dec 2015 16:40:08 -0800
> Brian Norris  wrote:
> > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > Unregister the NAND device from the NAND subsystem when removing a denali
> > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > exposed by the MTD layer, and accesses to this device will likely crash
> > > the system.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Cc:  #3.8+
> > 
> > Does this follow these rules, from
> > Documentation/stable_kernel_rules.txt?
> > 
> >  - It must be obviously correct and tested.
> > 
> >  - It must fix a real bug that bothers people (not a, "This could be a
> >problem..." type thing).
> 
> Sorry to bring the "stable or not stable (that is the question :-))"
> debate back, but after thinking a bit more about the implications of
> this missing nand_release() call, I think it is worth backporting the
> fix to all stable kernels.
> The reason is, it can potentially introduce a security hole, because if
> the mtd device is not unregister but the underlying mtd object is freed
> and the kernel reuses the same memory region for a different object,
> the MTD layer will possibly call one of the mtd->_method() function,
> and this field might point to another completely different function.
> 
> You'll say that denali devices are probably never removed and this is
> the reason why people have never seen this problem before, which would
> be a good reason to not bother backporting the patch.
> But, given that the driver can be compiled as a module (the user can
> possibly load/unload it, which will in turn create/destroy the
> NAND/MTD device), and that the denali controller can be exposed through
> a PCI bus (which, AFAIK is hotpluggable), I really think this fix
> should be sent to stable.

That's all well and good, but still nobody has told me they've tested
this.

I've pushed your v5 (+ comments, + ack) to l2-mtd.git. If it gets
testing and this request is made again at that point, we can easily send
it to stable after it hits Linus' tree. See option 2 in
Documentation/stable_kernel_rules.txt. You can even send the email
yourself, just CC me and anyone else relevant. I'll ack it if it's been
tested.

Regards,
Brian
--
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

Odroid U3 mutex deadlock.

2015-12-11 Thread Anand Moon

Hi Krzysztof,

I am just observing this deadlock om my Odroid U3.
--

[2.937531] =
[2.938733] [ INFO: possible recursive locking detected ]
[2.944117] 4.4.0-rc4-xu3s #32 Not tainted
[2.948195] -
[2.953577] swapper/0/1 is trying to acquire lock:
[2.958351]  (>lock){+.+...}, at: []
__genpd_poweron+0x64/0x108
[2.965727]
[2.965727] but task is already holding lock:
[2.971543]  (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[2.979355]
[2.979355] other info that might help us debug this:
[2.985865]  Possible unsafe locking scenario:
[2.985865]
[2.991768]CPU0
[2.994198]
[2.996628]   lock(>lock);
[2.26]   lock(>lock);
[3.003225]
[3.003225]  *** DEADLOCK ***
[3.003225]
[3.009128]  May be due to missing lock nesting notation
[3.009128]
[3.015900] 3 locks held by swapper/0/1:
[3.019804]  #0:  (>mutex){..}, at: []
__driver_attach+0x48/0x98
[3.027442]  #1:  (>mutex){..}, at: []
__driver_attach+0x58/0x98
[3.035081]  #2:  (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[3.043326]
[3.043326] stack backtrace:
[3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
[3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.060444] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.068163] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[3.075367] [] (dump_stack) from []
(__lock_acquire+0x1f88/0x215c)
[3.083262] [] (__lock_acquire) from []
(lock_acquire+0xa4/0xd0)
[3.090990] [] (lock_acquire) from []
(mutex_lock_nested+0x70/0x4d4)
[3.099061] [] (mutex_lock_nested) from []
(__genpd_poweron+0x64/0x108)
[3.107393] [] (__genpd_poweron) from []
(genpd_dev_pm_attach+0x170/0x1b8)
[3.115986] [] (genpd_dev_pm_attach) from []
(platform_drv_probe+0x2c/0xac)
[3.124667] [] (platform_drv_probe) from []
(driver_probe_device+0x208/0x2fc)
[3.133519] [] (driver_probe_device) from []
(__driver_attach+0x94/0x98)
[3.141939] [] (__driver_attach) from []
(bus_for_each_dev+0x68/0x9c)
[3.150097] [] (bus_for_each_dev) from []
(bus_add_driver+0x1a0/0x218)
[3.158344] [] (bus_add_driver) from []
(driver_register+0x78/0xf8)
[3.166330] [] (driver_register) from []
(exynos_drm_register_drivers+0x28/0x74)
[3.175441] [] (exynos_drm_register_drivers) from
[] (exynos_drm_init+0x6c/0xc4)
[3.184556] [] (exynos_drm_init) from []
(do_one_initcall+0x90/0x1dc)
[3.192718] [] (do_one_initcall) from []
(kernel_init_freeable+0x158/0x1f8)
[3.201396] [] (kernel_init_freeable) from []
(kernel_init+0x8/0xe8)
[3.209469] [] (kernel_init) from []
(ret_from_fork+0x14/0x24)
[3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
[3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO lookup
[3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
property of node '/hdmi@12D0[0]'
[3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
node '/hdmi@12D0[0]' - status (0)
[3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
mixer_component_ops)
[3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
hdmi_component_ops)
[3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.269812] [drm] No driver support for vblank timestamp query.
[3.323251] exynos-drm exynos-drm: fb0:  frame buffer device
[3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0

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

[RESEND PATCH v5 3/8] dt-bindings: add exynos-srom device tree binding

2015-12-11 Thread Pankaj Dubey

This patch adds exynos-srom binding information for SROM Controller
driver on Exynos SoCs.

CC: Rob Herring 
CC: Mark Rutland 
CC: Ian Campbell 
Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 .../devicetree/bindings/arm/samsung/exynos-srom.txt  | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
new file mode 100644
index 000..33886d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -0,0 +1,12 @@
+SAMSUNG Exynos SoCs SROM Controller driver.
+
+Required properties:
+- compatible : Should contain "samsung,exynos-srom".
+
+- reg: offset and length of the register set
+
+Example:
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x10>;
+   };
-- 
1.9.1

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

[RESEND PATCH v5 7/8] MAINTAINERS: add maintainers entry for drivers/soc/samsung

2015-12-11 Thread Pankaj Dubey

This patch adds maintainers entry for new driver folder
drivers/soc/samsung

Signed-off-by: Pankaj Dubey 
Acked-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..2c4b21f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1465,6 +1465,7 @@ F:arch/arm/mach-s5p*/
 F: arch/arm/mach-exynos*/
 F: drivers/*/*s3c2410*
 F: drivers/*/*/*s3c2410*
+F: drivers/soc/samsung/*
 F: drivers/spi/spi-s3c*
 F: sound/soc/samsung/*
 F: Documentation/arm/Samsung/
-- 
1.9.1

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

[RESEND PATCH v5 5/8] ARM: dts: add SROM device node for exynos5

2015-12-11 Thread Pankaj Dubey

Add SROM controller device node for exynos5.

CC: Rob Herring 
CC: Mark Rutland 
CC: Ian Campbell 
Signed-off-by: Pankaj Dubey 
[k.kozlowski: fixed size of mapped SROMC memory region]
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 arch/arm/boot/dts/exynos5.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 110dbd4..fb52d16 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -30,6 +30,11 @@
reg = <0x1000 0x100>;
};
 
+   sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   };
+
combiner: interrupt-controller@1044 {
compatible = "samsung,exynos4210-combiner";
#interrupt-cells = <2>;
-- 
1.9.1

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

[RESEND PATCH v5 6/8] drivers: soc: add support for exynos SROM driver

2015-12-11 Thread Pankaj Dubey

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
[p.fe...@samsung.com: tested on SMDK5410]
Tested-by: Pavel Fedin 
Signed-off-by: Kukjin Kim 
---
 drivers/soc/Kconfig   |   1 +
 drivers/soc/Makefile  |   1 +
 drivers/soc/samsung/Kconfig   |  13 +++
 drivers/soc/samsung/Makefile  |   1 +
 drivers/soc/samsung/exynos-srom.c | 175 ++
 drivers/soc/samsung/exynos-srom.h |  51 +++
 6 files changed, 242 insertions(+)
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 4e853ed..332c19f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -4,6 +4,7 @@ source "drivers/soc/brcmstb/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
+source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/sunxi/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index f2ba2e9..3b8bb23 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MACH_DOVE) += dove/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
+obj-$(CONFIG_SOC_SAMSUNG)  += samsung/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_SOC_TI)   += ti/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..2833b5b
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,13 @@
+#
+# SAMSUNG SoC drivers
+#
+menu "Samsung SOC driver support"
+
+config SOC_SAMSUNG
+   bool
+
+config EXYNOS_SROM
+   bool
+   depends on ARM && ARCH_EXYNOS && PM
+
+endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 000..9c554d5
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_SROM)  += exynos-srom.o
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
new file mode 100644
index 000..57a232d
--- /dev/null
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *   http://www.samsung.com/
+ *
+ * EXYNOS - SROM Controller support
+ * Author: Pankaj Dubey 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "exynos-srom.h"
+
+static const unsigned long exynos_srom_offsets[] = {
+   /* SROM side */
+   EXYNOS_SROM_BW,
+   EXYNOS_SROM_BC0,
+   EXYNOS_SROM_BC1,
+   EXYNOS_SROM_BC2,
+   EXYNOS_SROM_BC3,
+};
+
+/**
+ * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
+ * @offset: srom register offset from the controller base address.
+ * @value: the value of register under the offset.
+ */
+struct exynos_srom_reg_dump {
+   u32 offset;
+   u32 value;
+};
+
+/**
+ * struct exynos_srom: platform data for exynos srom controller driver.
+ * @dev: platform device pointer
+ * @reg_base: srom base address
+ * @reg_offset: exynos_srom_reg_dump pointer to hold offset and its value.
+ */
+struct exynos_srom {
+   struct device *dev;
+   void __iomem *reg_base;
+   struct exynos_srom_reg_dump *reg_offset;
+};
+
+static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
+   const unsigned long *rdump,
+   unsigned long nr_rdump)
+{
+   struct exynos_srom_reg_dump *rd;
+   unsigned int i;
+
+   rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
+   if (!rd)
+   return NULL;
+
+   for (i = 0; i < nr_rdump; ++i)
+   rd[i].offset = rdump[i];
+
+   return rd;
+}
+
+static int exynos_srom_probe(struct platform_device *pdev)
+{
+   struct device_node *np;
+   struct exynos_srom *srom;
+   struct device *dev = >dev;
+
+   np = dev->of_node;
+   if (!np) {
+   dev_err(>dev, "could not find device info\n");
+   return -EINVAL;
+   }
+
+   srom = devm_kzalloc(>dev,
+   sizeof(struct exynos_srom), GFP_KERNEL);
+   if (!srom)
+   return -ENOMEM;
+
+   srom->dev = dev;
+   srom->reg_base = of_iomap(np, 0);
+   if

[RESEND PATCH v5 1/8] ARM: EXYNOS: remove unused static mapping of CMU for exynos5

2015-12-11 Thread Pankaj Dubey

Remove unused static mapping of exynos5 CMU and related code.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 arch/arm/mach-exynos/exynos.c   | 5 -
 arch/arm/mach-exynos/include/mach/map.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1c47aee..524aa6f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -70,11 +70,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
.length = SZ_4K,
.type   = MT_DEVICE,
-   }, {
-   .virtual= (unsigned long)S5P_VA_CMU,
-   .pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
-   .length = 144 * SZ_1K,
-   .type   = MT_DEVICE,
},
 };
 
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index de3ae59..a2acba3 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,7 +25,6 @@
 #define EXYNOS_PA_CHIPID   0x1000
 
 #define EXYNOS4_PA_CMU 0x1003
-#define EXYNOS5_PA_CMU 0x1001
 
 #define EXYNOS4_PA_DMC00x1040
 #define EXYNOS4_PA_DMC10x1041
-- 
1.9.1

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

[RESEND PATCH v5 8/8] ARM: EXYNOS: Remove SROM related register settings from mach-exynos

2015-12-11 Thread Pankaj Dubey

As now we have dedicated driver for SROM controller, it will take care
of saving register banks during S2R so we can safely remove these
settings from mach-exynos.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 arch/arm/mach-exynos/Kconfig |  2 ++
 arch/arm/mach-exynos/exynos.c| 17 -
 arch/arm/mach-exynos/include/mach/map.h  |  3 --
 arch/arm/mach-exynos/regs-srom.h | 53 
 arch/arm/mach-exynos/suspend.c   | 20 ++-
 arch/arm/plat-samsung/include/plat/map-s5p.h |  1 -
 6 files changed, 4 insertions(+), 92 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..83c85f5 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
+   select EXYNOS_SROM if PM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
@@ -24,6 +25,7 @@ menuconfig ARCH_EXYNOS
select PINCTRL_EXYNOS
select PM_GENERIC_DOMAINS if PM
select S5P_DEV_MFC
+   select SOC_SAMSUNG
select SRAM
select THERMAL
select MFD_SYSCON
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 524aa6f..4ffb90e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -37,11 +37,6 @@ void __iomem *pmu_base_addr;
 
 static struct map_desc exynos4_iodesc[] __initdata = {
{
-   .virtual= (unsigned long)S5P_VA_SROMC,
-   .pfn= __phys_to_pfn(EXYNOS4_PA_SROMC),
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-   }, {
.virtual= (unsigned long)S5P_VA_CMU,
.pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
.length = SZ_128K,
@@ -64,15 +59,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
},
 };
 
-static struct map_desc exynos5_iodesc[] __initdata = {
-   {
-   .virtual= (unsigned long)S5P_VA_SROMC,
-   .pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
-   .length = SZ_4K,
-   .type   = MT_DEVICE,
-   },
-};
-
 static struct platform_device exynos_cpuidle = {
.name  = "exynos_cpuidle",
 #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -144,9 +130,6 @@ static void __init exynos_map_io(void)
 {
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
-   if (soc_is_exynos5())
-   iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
 }
 
 static void __init exynos_init_io(void)
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 86d8085..351e839 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -32,7 +32,4 @@
 #define EXYNOS4_PA_COREPERI0x1050
 #define EXYNOS4_PA_L2CC0x10502000
 
-#define EXYNOS4_PA_SROMC   0x1257
-#define EXYNOS5_PA_SROMC   0x1225
-
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/regs-srom.h b/arch/arm/mach-exynos/regs-srom.h
deleted file mode 100644
index 5c4d442..000
--- a/arch/arm/mach-exynos/regs-srom.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 2010 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * S5P SROMC register definitions
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#ifndef __PLAT_SAMSUNG_REGS_SROM_H
-#define __PLAT_SAMSUNG_REGS_SROM_H __FILE__
-
-#include 
-
-#define S5P_SROMREG(x) (S5P_VA_SROMC + (x))
-
-#define S5P_SROM_BWS5P_SROMREG(0x0)
-#define S5P_SROM_BC0   S5P_SROMREG(0x4)
-#define S5P_SROM_BC1   S5P_SROMREG(0x8)
-#define S5P_SROM_BC2   S5P_SROMREG(0xc)
-#define S5P_SROM_BC3   S5P_SROMREG(0x10)
-#define S5P_SROM_BC4   S5P_SROMREG(0x14)
-#define S5P_SROM_BC5   S5P_SROMREG(0x18)
-
-/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */
-
-#define S5P_SROM_BW__DATAWIDTH__SHIFT  0
-#define S5P_SROM_BW__ADDRMODE__SHIFT   1
-#define S5P_SROM_BW__WAITENABLE__SHIFT 2
-#define S5P_SROM_BW__BYTEENABLE__SHIFT 3
-
-#define S5P_SROM_BW__CS_MASK   0xf
-
-#define S5P_SROM_BW__NCS0__SHIFT   0
-#define S5P_SROM_BW__NCS1__SHIFT   4
-#define S5P_SROM_BW__NCS2__SHIFT

[RESEND PATCH v5 4/8] ARM: dts: add SROM device node for exynos4

2015-12-11 Thread Pankaj Dubey

Add device node of SROM controller for exynos4.

CC: Rob Herring 
CC: Mark Rutland 
CC: Ian Campbell 
Signed-off-by: Pankaj Dubey 
[k.kozlowski: fixed size of mapped SROMC memory region]
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 arch/arm/boot/dts/exynos4.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3184e10..ffda7f5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -76,6 +76,11 @@
reg = <0x1000 0x100>;
};
 
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x14>;
+   };
+
mipi_phy: video-phy@10020710 {
compatible = "samsung,s5pv210-mipi-video-phy";
#phy-cells = <1>;
-- 
1.9.1

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

[RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver

2015-12-11 Thread Pankaj Dubey

THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES

Series v5 got merged in kgene/for-next but due to last moment change before pull
these patches were not accepted during 4.3 merge window.After that 
kgene/for-next
got rebased over 4.4-rc1 these patches got dropped into another branch and till
date not included to for-next.

Since then due to minor change in "drivers/soc/", patches are not getting 
applied
cleanly so rebasing on current for-next and resending all these with fix in 
memory
mapping included.


This patch set adds support for Exynos SROM controller DT based driver.
Currently SROM register sets are used only during S2R, so driver
basically added for taking care of S2R. It will help us in removing
static mapping from exynos.c and other extra code handline during S2R.

This patch set also updated exynos4 and exynos5 dtsi files for with device
node for srom, and added binding documentation for the same.

First two patches are some minor cleanup in mach-exynos.

Patchset v1 was posted here[1]
[1]: https://lkml.org/lkml/2015/4/29/98
Patchset v2 was posted here[2]
[2]: https://lkml.org/lkml/2015/8/24/125
Patchset v3 was posted here[3]
[3]: https://lkml.org/lkml/2015/10/13/392
Patchset v3 was posted here[4]
[4]: https://lkml.org/lkml/2015/10/19/278

This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for boot
and S2R functionality.


Changes since v5:
 - Rebased and resolved conflicts on lastest for-next.
 - Included fix in memory mapping size in exynos4/exynos5 dtsi files.

Change since v4:
 - Removed unnedded NULL assignments from exynos_srom_remove function.
 - Added PM depency for selecting CONFIG_EXYNOS_SROM.
Changes since v3:
 - Rebased to lastet kgene tree.
 - Added platform data support, instead of using global variables for srom base
 - Addressed review comments from LABBE Corentin

Changes since v2:
 - Rebased to latest kgene tree.
 - Addressed review comments from Krzysztof Kozlowski.
 - Add new patch for MAINTAINER list update.
 - Reordered patch sequence for avoiding git bisect issues.

Changes since v1:
 - Rebased to latest kgene tree.
 - Addressed review comments from Krzysztof Kozlowski.
 - Add two new patches for minor cleanup in exynos.c and map.h

Pankaj Dubey (8):
  ARM: EXYNOS: remove unused static mapping of CMU for exynos5
  ARM: EXYNOS: code cleanup in map.h
  dt-bindings: add exynos-srom device tree binding
  ARM: dts: add SROM device node for exynos4
  ARM: dts: add SROM device node for exynos5
  drivers: soc: add support for exynos SROM driver
  MAINTAINERS: add maintainers entry for drivers/soc/samsung
  ARM: EXYNOS: Remove SROM related register settings from mach-exynos

 .../bindings/arm/samsung/exynos-srom.txt   |  12 ++
 MAINTAINERS|   1 +
 arch/arm/boot/dts/exynos4.dtsi |   5 +
 arch/arm/boot/dts/exynos5.dtsi |   5 +
 arch/arm/mach-exynos/Kconfig   |   2 +
 arch/arm/mach-exynos/exynos.c  |  22 ---
 arch/arm/mach-exynos/include/mach/map.h|   8 -
 arch/arm/mach-exynos/regs-srom.h   |  53 ---
 arch/arm/mach-exynos/suspend.c |  20 +--
 arch/arm/plat-samsung/include/plat/map-s5p.h   |   1 -
 drivers/soc/Kconfig|   1 +
 drivers/soc/Makefile   |   1 +
 drivers/soc/samsung/Kconfig|  13 ++
 drivers/soc/samsung/Makefile   |   1 +
 drivers/soc/samsung/exynos-srom.c  | 175 +
 drivers/soc/samsung/exynos-srom.h  |  51 ++
 16 files changed, 269 insertions(+), 102 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h

-- 
1.9.1

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

[RESEND PATCH v5 2/8] ARM: EXYNOS: code cleanup in map.h

2015-12-11 Thread Pankaj Dubey

Remove unused exynos5440 uart offset macro.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
---
 arch/arm/mach-exynos/include/mach/map.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index a2acba3..86d8085 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -35,8 +35,4 @@
 #define EXYNOS4_PA_SROMC   0x1257
 #define EXYNOS5_PA_SROMC   0x1225
 
-/* Compatibility UART */
-
-#define EXYNOS5440_PA_UART00x000B
-
 #endif /* __ASM_ARCH_MAP_H */
-- 
1.9.1

--
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 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

2015-12-11 Thread Chanwoo Choi

On 2015년 12월 11일 16:20, Krzysztof Kozlowski wrote:
> On 11.12.2015 14:07, Chanwoo Choi wrote:
>> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
>> (Internal) block to enable the bus frequency.
>>
>> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
>> bus is parent device in INT block using VDD_INT.
>>
>> Signed-off-by: Chanwoo Choi 
>> [linux.amoon: Tested on Odroid U3]
>> Tested-by: Anand Moon 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
>> 
>>  arch/arm/boot/dts/exynos4412-trats2.dts | 48 
>> +
>>  2 files changed, 95 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index 7bd65026761e..b6818aec7cf9 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -501,3 +501,50 @@
>>   {
>>  status = "okay";
>>  };
>> +
>> +_acp {
>> +devfreq = <_dmc>;
>> +status = "okay";
>> +};
> 
> I meant put them in proper place, respecting alphabetical order. The 'b'
> comes before 'w'.
> 
> As for the new nodes (bus_XXX) your previous sorting (first parent, then
> passive) was also okay - it had sense. This is up to you. Just put
> everything not at the end of file.

OK. I'll reorder them. Thanks for review.

[snip]

Best Regards,
Chanwoo Choi
--
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 v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size

2015-12-11 Thread Inki Dae



2015년 12월 10일 21:59에 Marek Szyprowski 이(가) 쓴 글:
> Hello,
> 
> On 2015-12-10 12:35, Inki Dae wrote:
>> Hi Marek,
>>
>> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
>>> This patch fixes trashed display of buffers cropped to very small width.
>>> Even if DMA is unstable and causes tearing when changing the burst size,
>>> it is still better than displaying a garbage.
>> It seems that this patch is different from above description. I think below 
>> patch is just cleanup,
>> which passes each member necessary instead of passing a drm_framebuffer 
>> object.
> 
> Please note the last chunk of this patch. After applying it width is
> taken from state->src.w instead of fb->width. If you want, I can split
> this patch into 2 parts - one cleanup without functional change, and
> second, replacement of fb->width with state->src.w.

Will just merge it.

Thanks,
Inki Dae

> 
> 
>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
>>>   1 file changed, 11 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 70cd2681e343..2e2247126581 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>>>   static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned 
>>> int win,
>>> -struct drm_framebuffer *fb)
>>> +uint32_t pixel_format, int width)
>>>   {
>>>   unsigned long val;
>>>   @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context 
>>> *ctx, unsigned int win,
>>>* So the request format is ARGB then change it to XRGB.
>>>*/
>>>   if (ctx->driver_data->has_limited_fmt && !win) {
>>> -if (fb->pixel_format == DRM_FORMAT_ARGB)
>>> -fb->pixel_format = DRM_FORMAT_XRGB;
>>> +if (pixel_format == DRM_FORMAT_ARGB)
>>> +pixel_format = DRM_FORMAT_XRGB;
>>>   }
>>>   -switch (fb->pixel_format) {
>>> +switch (pixel_format) {
>>>   case DRM_FORMAT_C8:
>>>   val |= WINCON0_BPPMODE_8BPP_PALETTE;
>>>   val |= WINCONx_BURSTLEN_8WORD;
>>> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context 
>>> *ctx, unsigned int win,
>>>   break;
>>>   }
>>>   -DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
>>> -
>>>   /*
>>> - * In case of exynos, setting dma-burst to 16Word causes permanent
>>> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
>>> - * switching which is based on plane size is not recommended as
>>> - * plane size varies alot towards the end of the screen and rapid
>>> - * movement causes unstable DMA which results into iommu crash/tear.
>>> + * Setting dma-burst to 16Word causes permanent tearing for very small
>>> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
>>> + * plane size is not recommended as plane size varies alot towards the
>>> + * end of the screen and rapid movement causes unstable DMA, but it is
>>> + * still better to change dma-burst than displaying garbage.
>>>*/
>>>   -if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>> +if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>>   val &= ~WINCONx_BURSTLEN_MASK;
>>>   val |= WINCONx_BURSTLEN_4WORD;
>>>   }
>>> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc 
>>> *crtc,
>>>   DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
>>>   }
>>>   -fimd_win_set_pixfmt(ctx, win, fb);
>>> +fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>>> /* hardware window 0 doesn't support color key. */
>>>   if (win != 0)
>>>
> 
> Best regards
--
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/3] Add support for monitoring gpio switches

2015-12-11 Thread Linus Walleij

On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
 wrote:

> Select Chromebooks have gpio attached to switches used to cause the
> firmware to enter alternative modes of operation and/or control other
> device characteristics (such as write protection on flash devices). This
> patch adds a driver that exposes a read-only interface to allow these
> signals to be read from user space.
>
> This functionality has been generalised to provide support for any device
> with device tree support which needs to identify a gpio as being used for a
> specific task.
>
> Signed-off-by: Martyn Welch 

If you want to do this thing, also propose a device tree binding document
for "gpio-switch".

But first (from Documentation/gpio/drivers-on-gpio.txt):

- gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line
  can generate interrupts in response to a key press. Also supports debounce.

- gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your
  GPIO line cannot generate interrupts, so it needs to be periodically polled
  by a timer.

- extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an
  external connector status, such as a headset line for an audio driver or an
  HDMI connector. It will provide a better userspace sysfs interface than GPIO.

So you mean none of these apply for this case?

Second: what you want to do is export a number of GPIOs with certain names
to userspace. This is something very generic and should be implemented
as such, not as something Chromebook-specific.

Patches like that has however already been suggested, and I have NACKed
them because the GPIO sysfs ABI is insane, and that is why I am refactoring
the world to create a proper chardev ABI for GPIO instead. See:
http://marc.info/?l=linux-gpio=144550276512673=2

So for the moment, NACK on this, please participate in creating the
*right* ABI for GPIO instead of trying to shoehorn stuff into the dying
sysfs ABI.

Yours,
Linus Walleij
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Dinh Nguyen

On Fri, Dec 11, 2015 at 11:08 AM, Boris Brezillon
 wrote:
> Hi Dinh,
>
> On Fri, 11 Dec 2015 10:50:21 -0600
> Dinh Nguyen  wrote:
>
>> Hi Boris,
>>
>> On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
>>  wrote:
>> > + Dinh (who made commit 2a0a288ec258)
>> >
>> > Also added back the Fixes tag.
>> >
>> > On Fri, 11 Dec 2015 15:02:34 +0100
>> > Boris Brezillon  wrote:
>> >
>> >> Unregister the NAND device from the NAND subsystem when removing a denali
>> >> NAND controller, otherwise the MTD attached to the NAND device is still
>> >> exposed by the MTD layer, and accesses to this device will likely crash
>> >> the system.
>> >>
>> >> Signed-off-by: Boris Brezillon 
>> >
>> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
>> >
>> >> ---
>> >> Changes since v4:
>> >> - remove Cc stable and fixes tags
>> >> - calculate the dma buffer size before calling nand_release()
>> >>
>> >>  drivers/mtd/nand/denali.c | 6 --
>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> >> index 67eb2be..fdfea05 100644
>> >> --- a/drivers/mtd/nand/denali.c
>> >> +++ b/drivers/mtd/nand/denali.c
>> >> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>> >>  /* driver exit point */
>> >>  void denali_remove(struct denali_nand_info *denali)
>> >>  {
>> >> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
>> >> +
>> >> + nand_release(>mtd);
>> >>   denali_irq_cleanup(denali->irq, denali);
>> >> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
>> >> -  denali->mtd.writesize + denali->mtd.oobsize,
>> >> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>> >>DMA_BIDIRECTIONAL);
>>
>> Not sure what is the need to add bufsize here, but the commit message
>> doesn't reflect the change.
>
> You were not in Cc of the first version (my fault), but Brian pointed
> that the mtd fields could be in an unknown state after the
> nand_release() call (this is currently not the case, but it change in
> the future). The idea is to pre-compute the DMA buffer size before
> releasing the mtd/nand device to prevent any future issues.
>
> I don't think it is worth mentioning this in the commit message,
> because these are just implementation details, but I can add the
> following comment before the bufsize declaration:
>
> /*
>  * Pre-compute DMA buffer size to avoid any problems in case
>  * nand_release() ever changes in a way that mtd->writesize and
>  * mtd->oobsize are not reliable after this call.
>  */
>
> What do you think?
>

Ah, perfect! With the updated comment,

Acked-by: Dinh Nguyen 

Thanks,
Dinh
--
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 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

2015-12-11 Thread Krzysztof Kozlowski

On 11.12.2015 16:52, Chanwoo Choi wrote:
> Dear MyungJoo,
> 
> Almost device tree patches in this series are reviewed by Exynos maintainer.
> Could you please review this series?

Are there any objections to merging DT patches through Samsung-soc?

Looking at the code, there are no dependencies between DT and drivers,
right?

Best regards,
Krzysztof

> 
> Best Regards,
> Chanwoo Choi
> 
> On 2015년 12월 11일 14:07, Chanwoo Choi wrote:
>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
>> have the common architecture for bus between DRAM and sub-blocks in SoC.
>> This driver can support the generic bus frequency driver for Exynos SoCs.
>>
>> In devicetree, Each bus block has a bus clock, regulator, operation-point
>> and devfreq-event devices which measure the utilization of each bus block.
>>
>> Signed-off-by: Chanwoo Choi 
>> [linux.amoon: Tested on Odroid U3]
>> Tested-by: Anand Moon 
>> ---
>>  drivers/devfreq/Kconfig |  15 ++
>>  drivers/devfreq/Makefile|   1 +
>>  drivers/devfreq/exynos/Makefile |   1 +
>>  drivers/devfreq/exynos/exynos-bus.c | 449 
>> 
>>  4 files changed, 466 insertions(+)
>>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c

--
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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

2015-12-11 Thread Boris Brezillon

Hi Brian,

On Thu, 10 Dec 2015 16:40:08 -0800
Brian Norris  wrote:

> On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > Unregister the NAND device from the NAND subsystem when removing a denali
> > NAND controller, otherwise the MTD attached to the NAND device is still
> > exposed by the MTD layer, and accesses to this device will likely crash
> > the system.
> > 
> > Signed-off-by: Boris Brezillon 
> > Cc:  #3.8+
> 
> Does this follow these rules, from
> Documentation/stable_kernel_rules.txt?
> 
>  - It must be obviously correct and tested.
> 
>  - It must fix a real bug that bothers people (not a, "This could be a
>problem..." type thing).

As you wish, I'll remove those Cc and Fixes tags, or just drop the
patch if you think it's useless...
I just noticed the bug while reworking this series, and thought it
would be useful to fix it, but I honestly don't care if it's applied
or not (I don't use this platform).

> 
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> > ---
> >  drivers/mtd/nand/denali.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> > index 67eb2be..8feece3 100644
> > --- a/drivers/mtd/nand/denali.c
> > +++ b/drivers/mtd/nand/denali.c
> > @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
> >  /* driver exit point */
> >  void denali_remove(struct denali_nand_info *denali)
> >  {
> > +   nand_release(>mtd);
> > denali_irq_cleanup(denali->irq, denali);
> > dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >  denali->mtd.writesize + denali->mtd.oobsize,
> 
> It feels a bit odd to allow usage of MTD fields after it has been
> unregistered. Maybe precompute this before the nand_release()?

nand_realease() is not releasing the mtd instance or re-initialazing
its field, so it should be safe, but I agree that pre-computing the DMA
buffer size is more future-proof.

I'll fix that, send a v5 and let you decide whether it's needed or not.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae

Hi Marek,

I found out why NULL point access happened. That was incurred by below your 
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the new 
crtc driver
so the driver should get the drm framebuffer object from the plane's state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.

After that, I think the drm framebuffer should be set to drm plane as a current 
fb
which would be scanned out.

Anyway, I can fix it like below if you are ok.

Thanks,
Inki Dae

--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;
 
-   addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+   addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", );

+   plane->base.fb = plane->pending_fb;
 
if (ctx->vblank_on)


2015년 12월 10일 22:05에 Inki Dae 이(가) 쓴 글:
> 
> 
> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
>> DMA address is a framebuffer attribute and the right place for it is
>> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
>> helper function for getting dma address of the given framebuffer.
>>
>> Signed-off-by: Marek Szyprowski 
>> Reviewed-by: Gustavo Padovan 
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 ---
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_fb.h|  3 +--
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 10 ++
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  5 -
>>  drivers/gpu/drm/exynos/exynos_mixer.c |  7 ---
>>  9 files changed, 38 insertions(+), 53 deletions(-)
>>
> 
> <--snip-->
> 
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> index 669362c53f49..3ce141236fad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -24,6 +24,7 @@
>>  
>>  #include "exynos_drm_drv.h"
>>  #include "exynos_drm_crtc.h"
>> +#include "exynos_drm_fb.h"
>>  #include "exynos_drm_plane.h"
>>  #include "exynos_drm_vidi.h"
>>  
>> @@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc 
>> *crtc,
>>struct exynos_drm_plane *plane)
>>  {
>>  struct vidi_context *ctx = crtc->ctx;
>> +dma_addr_t addr;
>>  
>>  if (ctx->suspended)
>>  return;
>>  
>> -DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
>> +addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> 
> At this point, plane->base.fb is NULL so null pointer access happens like 
> below,
> 
> [5.969422] Unable to handle kernel NULL pointer dereference at virtual 
> address 0090
> [5.977481] pgd = ee59
> [5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
> [5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [5.991712] Modules linked in:
> [5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted 
> 4.4.0-rc3-00052-gc60d7e2-dirty #199
> [6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
> [6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
> [6.018990] LR is at vidi_update_plane+0x4c/0xc4
> [6.023581] pc : []lr : []psr: 8013
> [6.023581] sp : ee4d5d90  ip : 0001  fp : 
> [6.035029] r10:   r9 : c05b965c  r8 : ee813e00
> [6.040241] r7 :   r6 : ee8e3330  r5 :   r4 : ee8e3010
> [6.046749] r3 :   r2 :   r1 : 0024  r0 : 
> [6.053264] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [6.060379] Control: 10c5387d  Table: 6e59004a  DAC: 0051
> [6.066107] Process sh (pid: 1598, stack limit = 0xee4d4210)
> [6.071748] Stack: (0xee4d5d90 to 0xee4d6000)
> [6.076100] 5d80:  ee813300 
> ee476e40 0005
> [6.084236] 5da0: ee8e3330 c028ac14 0008 ee476e40 ee476fc0 ef3b3800 
> ee476fc0 eeb3e380
> [6.092395] 5dc0: 0002 c02b08e4  eeb3e3a4 ee476fc0 ee476e40 
> ef3b3800 eeb3e380
> [6.100554] 5de0: 0002 c02b12b8 ee854400  0001 ee8501a8 
>  ee476e40
> [6.108714] 5e00: ef3b3800 0001 ee476e40 0050 ee850c80 0001 
> ee476e40 ef3b3aac
> [6.116873] 5e20: 0002 00ff  c028e0ec 000a82b4

37 matches

Mail list logo