Re: [PATCH v2 2/2] regulator: s5m8767: Document new bindings for Buck9 GPIO control

[Krzysztof Kozlowski]

On Wed, 2014-01-22 at 19:49 +, Mark Brown wrote:
> On Wed, Jan 22, 2014 at 05:07:28PM +0100, Krzysztof Kozlowski wrote:
> > Add documentation for new bindings for controlling (enable/disable) the
> > Buck9 Converter by GPIO (BUCK9EN).
> 
> Your CC list for this is *very* large...
Hmmm... The get_maintainers produces such long list for any change in
Documentation/devicetree/bindings... I'll stop using it for this.

> 
> > +   - s5m8767,pmic-ext-control-enable: regulator can be enabled/disabled
> > +   by GPIO (valid only for buck9).
> > +   - s5m8767,pmic-ext-control-gpio: GPIO specifier for one GPIO
> > +   controlling this regulator (valid only for buck9).
> > +   This property is required when 
> > 's5m8767,pmic-ext-control-enable' is specified.
> 
> In what situation might the GPIO be present but not usable - can't we
> just use the presence of the GPIO property?  Also GPIO properties are
> supposed to be always "-gpios".
Remove the "s5m8767,pmic-ext-control-enable" and use only
"s5m8767,pmic-ext-control-gpios"? Sure, that makes sense. Thanks for
idea.


Best regards,
Krzysztof

--
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: Arndale Timer Interrupt Question

[Mj Embd]

On 1/10/14, Tomasz Figa  wrote:
> Hi,
>
> On 09.01.2014 13:52, Bartlomiej Zolnierkiewicz wrote:
>>
>> added linux-samsung-soc to cc:,
>> it is a better suited list for this question
>>
>> On Thursday, January 09, 2014 10:30:56 AM Mj Embd wrote:
>>> I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can
>>> you please help here.
>>>
>>> As per the exynos5 public manual
>>> What is the difference between  CPU_nCNTHPIRQ[0] and CNTHPIRQ.
>
> I'm not sure if this is really what I think it is, but looking at the
> manual, CPU_nCNTHPIRQ[0] and [1] SPI ports and CNTHPIRQ PPI port seem to
> be the same signals, with the difference that the first two are shared
> interrupts connected through the combiner, while the last one is a
> per-processor interrupt, directly connected to GIC PPI port, allowing
> each CPU to get its own CNTHPIRQ signal ([0] for CPU 0 and [1] for CPU 1).

So while registering the IRQ which one has to be used Core0:26/33 Core1:26/54 ?

> Best regards,
> Tomasz
>
>>>
>>> While the later has an interrupt ID 26, the former is part of a group
>>> with combined interrupt id as 33 for core 0 and 54 for core 1.
>>>
>>> For a timer interrupt which goes to PL2, which id should be used 26 or
>>> 33 for core 0 ?
>>>
>>> Please clear this confusion.
>>>
>>> Many Thanks
>>
>> --
>> 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
>>
>


-- 
-mj
--
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] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks

[Prabhakar Lad]

Hi Swaminathan,

On Thu, Jan 23, 2014 at 10:49 AM, swaminathan  wrote:
> Hi All,
> Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add
> Horizontal and Vertical search range for Video Macro Blocks"
> posted on 30-Dec-2013 ?
>
>
Just a side note, please don’t top post and always reply as plain text.

[Snip]

> Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range
> for Video Macro Blocks
>
>
>> This patch adds Controls to set Horizontal and Vertical search range
>> for Motion Estimation block for Samsung MFC video Encoders.
>>
>> Signed-off-by: Swami Nathan 
>> Signed-off-by: Amit Grover 
>> ---
>> Documentation/DocBook/media/v4l/controls.xml|   14 +
>> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
>> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|   24
>> +++
>> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
>> drivers/media/v4l2-core/v4l2-ctrls.c|   14 +
>> include/uapi/linux/v4l2-controls.h  |2 ++
>> 6 files changed, 58 insertions(+), 6 deletions(-)
>>
This patch from the outset looks OK,  but you need to split up
into two, first adding a v4l control and second one using it up in the driver.

Regards,
--Prabhakar Lad
--
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] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks

[swaminathan]

Hi All,
Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add 
Horizontal and Vertical search range for Video Macro Blocks"

posted on 30-Dec-2013 ?


Regards,
Swaminathan




--
From: "Amit Grover" 
Sent: Monday, December 30, 2013 4:13 PM
To: ; ; 
; ; 
; ; 
; ; ; 

Cc: ; ; 
; ; ; 
; ; "Swami Nathan" 

Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range 
for Video Macro Blocks



This patch adds Controls to set Horizontal and Vertical search range
for Motion Estimation block for Samsung MFC video Encoders.

Signed-off-by: Swami Nathan 
Signed-off-by: Amit Grover 
---
Documentation/DocBook/media/v4l/controls.xml|   14 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|   24 
+++

drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
drivers/media/v4l2-core/v4l2-ctrls.c|   14 +
include/uapi/linux/v4l2-controls.h  |2 ++
6 files changed, 58 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml

index 7a3b49b..70a0f6f 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,20 @@ Applicable to the MPEG1, MPEG2, MPEG4 
encoders.

VBV buffer control.
   

+   
+   
+ spanname="id">V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE 

+ integer
+   Sets the Horizontal search 
range for Video Macro blocks.

+   
+
+ 
+   
+ spanname="id">V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE 

+ integer
+   Sets the Vertical search range 
for Video Macro blocks.

+   
+
   
   
 spanname="id">V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h

index 6920b54..f2c13c3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
struct s5p_mfc_enc_params {
 u16 width;
 u16 height;
+ u32 horz_range;
+ u32 vert_range;

 u16 gop_size;
 enum v4l2_mpeg_video_multi_slice_mode slice_mode;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c

index 4ff3b6c..a02e7b8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
 .default_value = 0,
 },
 {
+ .id = V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "horizontal search range of video macro block",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "vertical search range of video macro block",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
 .id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
 .type = V4L2_CTRL_TYPE_INTEGER,
 .minimum = 0,
@@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl 
*ctrl)

 case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
 p->vbv_size = ctrl->val;
 break;
+ case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE:
+ p->horz_range = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE:
+ p->vert_range = ctrl->val;
+ break;
 case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
 p->codec.h264.cpb_size = ctrl->val;
 break;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c

index 461358c..47e1807 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx 
*ctx)

 WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);

 /* setting for MV range [16, 256] */
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->horz_range & 0x3fff); /* conditional check in app */
 WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);

- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->vert_range & 0x3fff); /* conditional check in app */
 WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);

 WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c

index fb46790..7cf23d5 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
 case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
 case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
 case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV 
Control";
+ case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE: return "hor search range of 
video MB";
+ case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE: return "vert search range of 
video MB";
 case V4L2_CID_MPEG_VIDEO_REPEAT

Re: [RFC PATCH 1/9] drm/exynos: correct timing porch conversion

[Daniel Kurtz]

On Wed, Jan 22, 2014 at 11:09 PM, Andrzej Hajda  wrote:
> Hi,
>
> It seems I have not added description to this patch.
> In this patch porch is calculated in compatible way to
> drm_display_mode_from_videomode core function.
> The way it was seems to me incorrect and it did not work on my hw.
>
> Anyway this patch could be merged with Sean's patches, if he agrees.
>
> Regards
> Andrzej
>
> On 01/22/2014 03:35 PM, Andrzej Hajda wrote:
>> Signed-off-by: Andrzej Hajda 

Yes, it does make more sense than just arbitrarily assigning half of
the non-sync blank period to the back porch, and the remainder to the
front porch.
With your follow-on commit message added, this is:

Reviewed-by: Daniel Kurtz 

>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ---
>>  1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 8caaac2..b611f33 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -538,21 +538,18 @@ static void fimd_mode_set(struct exynos_drm_manager 
>> *mgr,
>>  {
>>   struct fimd_context *ctx = mgr->ctx;
>>   struct fimd_mode_data *mode = &ctx->mode;
>> - int hblank, vblank;
>>
>> - vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
>>   mode->vtotal = in_mode->crtc_vtotal;
>>   mode->vdisplay = in_mode->crtc_vdisplay;
>>   mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
>> - mode->vbpd = (vblank - mode->vsync_len) / 2;
>> - mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
>> + mode->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
>> + mode->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;
>>
>> - hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
>>   mode->htotal = in_mode->crtc_htotal;
>>   mode->hdisplay = in_mode->crtc_hdisplay;
>>   mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
>> - mode->hbpd = (hblank - mode->hsync_len) / 2;
>> - mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
>> + mode->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
>> + mode->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
>>
>>   mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
>>
>>
>
> ___
> 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 1/1] ARM: S3C24XX: Move rtc-core.h from plat to mach

[kgene]

Heiko Stübner wrote:
> 
> Am Montag, 30. Dezember 2013, 16:10:08 schrieb Sachin Kamat:
> > plat/rtc-core.h is only referenced from mach-s3c24xx. Hence
> > move it there to de-populate the plat directory. While at it
> > also do some cleanup of the header file.
> >
> > Signed-off-by: Sachin Kamat 
> > Cc: Heiko Stuebner 
> 
> late, but as the patch is not merged yet:
> 
> Acked-by: Heiko Stuebner 
> 
Applied into cleanup, thanks.

- Kukjin

> > ---
> >  .../plat => mach-s3c24xx/include/mach}/rtc-core.h  |   13 ++---
> >  arch/arm/mach-s3c24xx/s3c2416.c|2 +-
> >  arch/arm/mach-s3c24xx/s3c2443.c|2 +-
> >  3 files changed, 8 insertions(+), 9 deletions(-)
> >  rename arch/arm/{plat-samsung/include/plat =>
> > mach-s3c24xx/include/mach}/rtc-core.h (69%)

--
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] ARM: exynos_defconfig: Update EHCI config entry

[kgene]

Jingoo Han wrote:
> 
> On Thursday, January 16, 2014 5:34 PM, Tushar Behera wrote:
> >
> > Commit 29824c167bea ("USB: host: Rename ehci-s5p to ehci-exynos")
> > renamed the config entry of EHCI host driver. Similar change needs
> > to be done in exynos_defconfig as well.
> >
> > Signed-off-by: Tushar Behera 
> 
> (+cc Vivek Gautam, Yulgon Kim, Julius Werner)
> 
> Reviewed-by: Jingoo Han 
> 
> Yes, right.
> I overlooked 'exynos_defconfig', when I changed the name of
> Exynos EHCI driver. Thank you for sending the patch. :-)
> 
> Best regards,
> Jingoo Han
> 
> > ---
> >  arch/arm/configs/exynos_defconfig |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> > index dbe1f1c..4ce7b70 100644
> > --- a/arch/arm/configs/exynos_defconfig
> > +++ b/arch/arm/configs/exynos_defconfig
> > @@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
> >  CONFIG_LOGO=y
> >  CONFIG_USB=y
> >  CONFIG_USB_EHCI_HCD=y
> > -CONFIG_USB_EHCI_S5P=y
> > +CONFIG_USB_EHCI_EXYNOS=y
> >  CONFIG_USB_STORAGE=y
> >  CONFIG_USB_DWC3=y
> >  CONFIG_USB_PHY=y
> > --
> > 1.7.9.5

OK, applied into -fixes.

Thanks,
Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up

[Stephen Boyd]

On 01/20, Tomasz Figa wrote:
> Hi Kevin,
> 
> On 14.01.2014 16:42, Kevin Hilman wrote:
> >Tomasz Figa  writes:
> >
> >>This patch introduces generic code to perform power domain look-up using
> >>device tree and automatically bind devices to their power domains.
> >>Generic device tree binding is introduced to specify power domains of
> >>devices in their device tree nodes.
> >>
> >>Backwards compatibility with legacy Samsung-specific power domain
> >>bindings is provided, but for now the new code is not compiled when
> >>CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> >>will change as soon as Exynos power domain code gets converted to use
> >>the generic framework in further patch.
> >>
> >>Signed-off-by: Tomasz Figa 
> >
> >I haven't read through this in detail yet, but wanted to make sure that
> >the DT representation can handle nested power domains.  At least
> >SH-mobile has a hierarchy of power domains and the genpd code can handle
> >that, so wanted to make sure that the DT representation can handle it as
> >well.
> 
> The representation of power domains themselves as implied by this
> patch is fully platform-specific. The only generic part is the
> #power-domain-cells property, which defines the number of cells
> needed to identify the power domain of given provider. You are free
> to have any platform-specific properties (or even generic ones,
> added on top of this patch) to let you specify the hierarchy in DT.
> 

(Semi-related to this thread, but not really the patchset)

I'd like to have a way to say that this power domain is a
subdomain of another domain provided by a different power domain
provider driver. From what I can tell, the only way to reparent
domains as of today is by name or reference and you have to make
a function call to do it (pm_genpd_add_subdomain_names() or
pm_genpd_add_subdomain()). This is annoying in the case where all
the power domains are not regsitered within the same driver
because we don't know which driver comes first.

It would be great if there was a way to specify this relationship
explicitly when initializing a power domain so that the
reparenting is done automatically without requiring any explicit
function call. Perhaps DT could specify this? Or we could add
another field to the generic_power_domain struct like parent_name?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 RFC 04/10] base: power: Add generic OF-based power domain look-up

[Tomasz Figa]

Hi Stephen,

On 23.01.2014 01:18, Stephen Boyd wrote:

On 01/11, Tomasz Figa wrote:

+
+/**
+ * of_genpd_lock() - Lock access to of_genpd_providers list
+ */
+static void of_genpd_lock(void)
+{
+   mutex_lock(&of_genpd_mutex);
+}
+
+/**
+ * of_genpd_unlock() - Unlock access to of_genpd_providers list
+ */
+static void of_genpd_unlock(void)
+{
+   mutex_unlock(&of_genpd_mutex);
+}


Why do we need these functions? Can't we just call
mutex_lock/unlock directly?


That would be fine as well, I guess. Just duplicated the pattern used in 
CCF, but can remove them in next version if it's found to be better.





+
+/**
+ * of_genpd_add_provider() - Register a domain provider for a node
+ * @np: Device node pointer associated with domain provider
+ * @genpd_src_get: callback for decoding domain
+ * @data: context pointer for @genpd_src_get callback.


These look a little outdated.


Oops, missed this.




+ */
+int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
+ void *data)
+{
+   struct of_genpd_provider *cp;
+
+   cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);


Please use sizeof(*cp) instead.


Right.




+   if (!cp)
+   return -ENOMEM;
+
+   cp->node = of_node_get(np);
+   cp->data = data;
+   cp->xlate = xlate;
+
+   of_genpd_lock();
+   list_add(&cp->link, &of_genpd_providers);
+   of_genpd_unlock();
+   pr_debug("Added domain provider from %s\n", np->full_name);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_add_provider);
+

[...]

+
+/* See of_genpd_get_from_provider(). */
+static struct generic_pm_domain *__of_genpd_get_from_provider(
+   struct of_phandle_args *genpdspec)
+{
+   struct of_genpd_provider *provider;
+   struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);


Can this be -EPROBE_DEFER so that we can defer probe until a
later time if the power domain provider hasn't registered yet?


Yes, this could be useful. Makes me wonder why clock code (on which I 
based this code) doesn't have it done this way.





+
+   /* Check if we have such a provider in our array */
+   list_for_each_entry(provider, &of_genpd_providers, link) {
+   if (provider->node == genpdspec->np)
+   genpd = provider->xlate(genpdspec, provider->data);
+   if (!IS_ERR(genpd))
+   break;
+   }
+
+   return genpd;
+}
+

[...]

+static int of_genpd_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+   struct device *dev = data;
+   int ret;
+
+   if (!dev->of_node)
+   return NOTIFY_DONE;
+
+   switch (event) {
+   case BUS_NOTIFY_BIND_DRIVER:
+   ret = of_genpd_add_to_domain(dev);
+   break;
+
+   case BUS_NOTIFY_UNBOUND_DRIVER:
+   ret = of_genpd_del_from_domain(dev);
+   break;
+
+   default:
+   return NOTIFY_DONE;
+   }
+
+   return notifier_from_errno(ret);
+}
+
+static struct notifier_block of_genpd_notifier_block = {
+   .notifier_call = of_genpd_notifier_call,
+};
+
+static int of_genpd_init(void)
+{
+   return bus_register_notifier(&platform_bus_type,
+   &of_genpd_notifier_block);
+}
+core_initcall(of_genpd_init);


Would it be possible to call the of_genpd_add_to_domain() and
of_genpd_del_from_domain() functions directly in the driver core,
similar to how the pinctrl framework has a hook in there? That
way we're not relying on any initcall ordering for this.


Hmm, the initcall here just registers a notifier, which needs to be done 
just before any driver registers. So, IMHO, current variant is safe, 
given an early enough initcall level is used.


However, doing it the pinctrl way might still have an advantage of not 
relying on specific bus type, so this is worth consideration indeed. I'd 
like to hear Rafael's and Kevin's opinions on this (and other comments 
above too).


Best regards,
Tomasz
--
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 RFC 04/10] base: power: Add generic OF-based power domain look-up

[Stephen Boyd]

On 01/11, Tomasz Figa wrote:
> +
> +/**
> + * of_genpd_lock() - Lock access to of_genpd_providers list
> + */
> +static void of_genpd_lock(void)
> +{
> + mutex_lock(&of_genpd_mutex);
> +}
> +
> +/**
> + * of_genpd_unlock() - Unlock access to of_genpd_providers list
> + */
> +static void of_genpd_unlock(void)
> +{
> + mutex_unlock(&of_genpd_mutex);
> +}

Why do we need these functions? Can't we just call
mutex_lock/unlock directly?

> +
> +/**
> + * of_genpd_add_provider() - Register a domain provider for a node
> + * @np: Device node pointer associated with domain provider
> + * @genpd_src_get: callback for decoding domain
> + * @data: context pointer for @genpd_src_get callback.

These look a little outdated.

> + */
> +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
> +   void *data)
> +{
> + struct of_genpd_provider *cp;
> +
> + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);

Please use sizeof(*cp) instead.

> + if (!cp)
> + return -ENOMEM;
> +
> + cp->node = of_node_get(np);
> + cp->data = data;
> + cp->xlate = xlate;
> +
> + of_genpd_lock();
> + list_add(&cp->link, &of_genpd_providers);
> + of_genpd_unlock();
> + pr_debug("Added domain provider from %s\n", np->full_name);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
> +
[...]
> +
> +/* See of_genpd_get_from_provider(). */
> +static struct generic_pm_domain *__of_genpd_get_from_provider(
> + struct of_phandle_args *genpdspec)
> +{
> + struct of_genpd_provider *provider;
> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);

Can this be -EPROBE_DEFER so that we can defer probe until a
later time if the power domain provider hasn't registered yet?

> +
> + /* Check if we have such a provider in our array */
> + list_for_each_entry(provider, &of_genpd_providers, link) {
> + if (provider->node == genpdspec->np)
> + genpd = provider->xlate(genpdspec, provider->data);
> + if (!IS_ERR(genpd))
> + break;
> + }
> +
> + return genpd;
> +}
> +
[...]
> +static int of_genpd_notifier_call(struct notifier_block *nb,
> +   unsigned long event, void *data)
> +{
> + struct device *dev = data;
> + int ret;
> +
> + if (!dev->of_node)
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case BUS_NOTIFY_BIND_DRIVER:
> + ret = of_genpd_add_to_domain(dev);
> + break;
> +
> + case BUS_NOTIFY_UNBOUND_DRIVER:
> + ret = of_genpd_del_from_domain(dev);
> + break;
> +
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static struct notifier_block of_genpd_notifier_block = {
> + .notifier_call = of_genpd_notifier_call,
> +};
> +
> +static int of_genpd_init(void)
> +{
> + return bus_register_notifier(&platform_bus_type,
> + &of_genpd_notifier_block);
> +}
> +core_initcall(of_genpd_init);

Would it be possible to call the of_genpd_add_to_domain() and
of_genpd_del_from_domain() functions directly in the driver core,
similar to how the pinctrl framework has a hook in there? That
way we're not relying on any initcall ordering for this.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/2] regulator: s5m8767: Document new bindings for Buck9 GPIO control

[Mark Brown]

On Wed, Jan 22, 2014 at 05:07:28PM +0100, Krzysztof Kozlowski wrote:
> Add documentation for new bindings for controlling (enable/disable) the
> Buck9 Converter by GPIO (BUCK9EN).

Your CC list for this is *very* large...

> + - s5m8767,pmic-ext-control-enable: regulator can be enabled/disabled
> + by GPIO (valid only for buck9).
> + - s5m8767,pmic-ext-control-gpio: GPIO specifier for one GPIO
> + controlling this regulator (valid only for buck9).
> + This property is required when 
> 's5m8767,pmic-ext-control-enable' is specified.

In what situation might the GPIO be present but not usable - can't we
just use the presence of the GPIO property?  Also GPIO properties are
supposed to be always "-gpios".


signature.asc
Description: Digital signature

Re: [PATCH RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Krzysztof Kozlowski]

On Wed, 2014-01-22 at 10:46 -0500, Paul Gortmaker wrote:
> On 14-01-22 10:37 AM, Krzysztof Kozlowski wrote:
> > 
> >>
> >> Hi,
> >>
> >> A little more explanation from my side: the build error actually happens
> >> only on next/master, not Linus' tree.
> >>
> >> Mentioned commit which changes the driver to platform driver is in
> >> mainline since 3.12-rc2 so it seems this is not the cause of the build
> >> error. I think I need to find first the real cause of this build error.
> >>
> >> Best regards,
> >> Krzysztof
> > 
> > After bisecting, the real commit for build error is:
> > caa7dcde7c424cdc81698a6e4e48072eb67ec67e
> > module: relocate module_init from init.h to module.h
> 
> Yep, even though I fixed a crap-tonne of implicit includes, and
> built all the arm configs, some were bound to sneak through.
> 
> I'll push a fix shortly to the init cleanup queue:
> 
>http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git/
> 
> so it will be fine for the next linux-next tree.

Thanks, the same issue applies to drivers/cpufreq/exynos-cpufreq.c.

Best regards,
Krzysztof

--
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 v2 0/2] regulator: s5m8767: Use GPIO for controlling Buck9/eMMC

[Krzysztof Kozlowski]

Hi,

This is second version of patch adding GPIO control over Buck9 regulator
in s5m8767 regulator driver.

Previously the patch was part of larger patchset from which all other patches
were applied. Changes since previous revision:
1. Use ena_gpio of regulator core, as suggested by Mark Brown.

This patchset is based on next tree: next-20140122.

Best regards,
Krzysztof

Krzysztof Kozlowski (2):
  regulator: s5m8767: Use GPIO for controlling Buck9/eMMC
  regulator: s5m8767: Document new bindings for Buck9 GPIO control

 .../bindings/regulator/s5m8767-regulator.txt   |   16 +++-
 drivers/regulator/s5m8767.c|   97 +++-
 include/linux/mfd/samsung/core.h   |4 +-
 include/linux/mfd/samsung/s5m8767.h|7 ++
 4 files changed, 119 insertions(+), 5 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] regulator: s5m8767: Document new bindings for Buck9 GPIO control

[Krzysztof Kozlowski]

Add documentation for new bindings for controlling (enable/disable) the
Buck9 Converter by GPIO (BUCK9EN).

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
---
 .../bindings/regulator/s5m8767-regulator.txt   |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index fc6b38f035bd..b52ee77dc4c0 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -69,13 +69,18 @@ sub-node should be of the format as listed below.
};
};
 The above regulator entries are defined in regulator bindings documentation
-except op_mode description.
+except these properties:
- op_mode: describes the different operating modes of the LDO's with
power mode change in SOC. The different possible values are,
0 - always off mode
1 - on in normal mode
2 - low power mode
3 - suspend mode
+   - s5m8767,pmic-ext-control-enable: regulator can be enabled/disabled
+   by GPIO (valid only for buck9).
+   - s5m8767,pmic-ext-control-gpio: GPIO specifier for one GPIO
+   controlling this regulator (valid only for buck9).
+   This property is required when 
's5m8767,pmic-ext-control-enable' is specified.
 
 The following are the names of the regulators that the s5m8767 pmic block
 supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
@@ -148,5 +153,14 @@ Example:
regulator-always-on;
regulator-boot-on;
};
+
+   vemmc_reg: BUCK9 {
+   regulator-name = "VMEM_VDD_2.8V";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   op_mode = <3>; /* Standby Mode */
+   s5m8767,pmic-ext-control-enable;
+   s5m8767,pmic-ext-control-gpio = <&gpk0 2 0>;
+   };
};
};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] regulator: s5m8767: Use GPIO for controlling Buck9/eMMC

[Krzysztof Kozlowski]

Add support for GPIO control (enable/disable) over Buck9. The Buck9
Converter is used as a supply for eMMC Host Controller.

BUCK9EN GPIO of S5M8767 chip may be used by application processor to
enable or disable the Buck9. This has two benefits:
 - It is faster than toggling it over I2C bus.
 - It allows disabling the regulator during suspend to RAM; The AP will
   enable it during resume; Without the patch the regulator supplying
   eMMC must be defined as fixed-regulator.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
---
 drivers/regulator/s5m8767.c |  101 +--
 include/linux/mfd/samsung/core.h|4 +-
 include/linux/mfd/samsung/s5m8767.h |7 +++
 3 files changed, 108 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index d7164bb75d3e..95c28b04dcc9 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -11,11 +11,8 @@
  *
  */
 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -483,6 +480,65 @@ static struct regulator_desc regulators[] = {
s5m8767_regulator_desc(BUCK9),
 };
 
+/*
+ * Enable GPIO control over BUCK9 in regulator_config for that regulator.
+ */
+static void s5m8767_regulator_config_ext_control(struct s5m8767_info *s5m8767,
+   struct sec_regulator_data *rdata,
+   struct regulator_config *config)
+{
+   int i, mode = 0;
+
+   if (rdata->id != S5M8767_BUCK9)
+   return;
+
+   /* Check if opmode for regulator matches S5M8767_ENCTRL_USE_GPIO */
+   for (i = 0; i < s5m8767->num_regulators; i++) {
+   const struct sec_opmode_data *opmode = &s5m8767->opmode[i];
+   if (opmode->id == rdata->id) {
+   mode = s5m8767_opmode_reg[rdata->id][opmode->mode];
+   break;
+   }
+   }
+   if (mode != S5M8767_ENCTRL_USE_GPIO) {
+   dev_warn(s5m8767->dev,
+   "ext-control for %s: mismatched op_mode (%x), 
ignoring\n",
+   rdata->reg_node->name, mode);
+   return;
+   }
+
+   if (!gpio_is_valid(rdata->ext_control_gpio)) {
+   dev_warn(s5m8767->dev,
+   "ext-control for %s: GPIO not valid, 
ignoring\n",
+   rdata->reg_node->name);
+   return;
+   }
+
+   config->ena_gpio = rdata->ext_control_gpio;
+   config->ena_gpio_flags = GPIOF_OUT_INIT_HIGH;
+}
+
+/*
+ * Turn on GPIO control over BUCK9.
+ */
+static int s5m8767_enable_ext_control(struct s5m8767_info *s5m8767,
+   struct regulator_dev *rdev)
+{
+   int ret, reg, enable_ctrl;
+
+   if (rdev_get_id(rdev) != S5M8767_BUCK9)
+   return -EINVAL;
+
+   ret = s5m8767_get_register(rdev, ®, &enable_ctrl);
+   if (ret)
+   return ret;
+
+   return regmap_update_bits(s5m8767->iodev->regmap_pmic,
+   reg, S5M8767_ENCTRL_MASK,
+   S5M8767_ENCTRL_USE_GPIO << S5M8767_ENCTRL_SHIFT);
+}
+
+
 #ifdef CONFIG_OF
 static int s5m8767_pmic_dt_parse_dvs_gpio(struct sec_pmic_dev *iodev,
struct sec_platform_data *pdata,
@@ -520,6 +576,24 @@ static int s5m8767_pmic_dt_parse_ds_gpio(struct 
sec_pmic_dev *iodev,
return 0;
 }
 
+static int s5m8767_pmic_dt_parse_ext_control_gpio(struct sec_pmic_dev *iodev,
+   struct sec_regulator_data *rdata,
+   struct device_node *reg_np)
+{
+   if (of_get_property(reg_np, "s5m8767,pmic-ext-control-enable", NULL)) {
+   int gpio = of_get_named_gpio(reg_np,
+   "s5m8767,pmic-ext-control-gpio", 0);
+   if (!gpio_is_valid(gpio)) {
+   dev_err(iodev->dev, "invalid %s gpio: %d\n",
+   reg_np->name, gpio);
+   return -EINVAL;
+   }
+   rdata->ext_control_enable = true;
+   rdata->ext_control_gpio = gpio;
+   }
+   return 0;
+}
+
 static int s5m8767_pmic_dt_parse_pdata(struct platform_device *pdev,
struct sec_platform_data *pdata)
 {
@@ -574,6 +648,14 @@ static int s5m8767_pmic_dt_parse_pdata(struct 
platform_device *pdev,
continue;
}
 
+   if (s5m8767_pmic_dt_parse_ext_control_gpio(iodev, rdata,
+   reg_np)) {
+   dev_warn(iodev->dev,
+   "wrong configuration for regulator %s, 
skipping\n",
+   reg_np->name);
+   continue;
+   }
+
rdata->id = i;
rdata->initdata = of_get_regulator_init_data(

Re: [PATCH RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Paul Gortmaker]

On 14-01-22 10:37 AM, Krzysztof Kozlowski wrote:
> 
>>
>> On Wed, 2014-01-22 at 20:12 +0530, Viresh Kumar wrote:
>>> On 22 January 2014 19:51, Krzysztof Kozlowski  
>>> wrote:
 Add missing include to fix build error:
 drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
 type or storage class [enabled by default]
 drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
 declaration of ‘module_init’ [-Werror=implicit-int]
 drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
 types) in function declaration [enabled by default]
 drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
 type or storage class [enabled by default]
 drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
 declaration of ‘module_exit’ [-Werror=implicit-int]
 drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
 types) in function declaration [enabled by default]
 drivers/cpufreq/exynos-cpufreq.c:292:1: warning: 
 ‘exynos_cpufreq_platdrv_init’ defined but not used [-Wunused-function]
 cc1: some warnings being treated as errors
 make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
 make[1]: *** [drivers/cpufreq] Error 2

 Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
 and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
 exynos-cpufreq to platform driver).

 Signed-off-by: Krzysztof Kozlowski 
 Cc: Lukasz Majewski 
 Cc: Tomasz Figa 
 Cc: Kyungmin Park 
 ---
  drivers/cpufreq/exynos-cpufreq.c |1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/cpufreq/exynos-cpufreq.c 
 b/drivers/cpufreq/exynos-cpufreq.c
 index fcd2914d081a..fa54c2b88dd7 100644
 --- a/drivers/cpufreq/exynos-cpufreq.c
 +++ b/drivers/cpufreq/exynos-cpufreq.c
 @@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
>>>
>>> I am surprised how that patch went through then? And nothing was
>>> reported by kbuild for it..
>>
>> Hi,
>>
>> A little more explanation from my side: the build error actually happens
>> only on next/master, not Linus' tree.
>>
>> Mentioned commit which changes the driver to platform driver is in
>> mainline since 3.12-rc2 so it seems this is not the cause of the build
>> error. I think I need to find first the real cause of this build error.
>>
>> Best regards,
>> Krzysztof
> 
> After bisecting, the real commit for build error is:
> caa7dcde7c424cdc81698a6e4e48072eb67ec67e
> module: relocate module_init from init.h to module.h

Yep, even though I fixed a crap-tonne of implicit includes, and
built all the arm configs, some were bound to sneak through.

I'll push a fix shortly to the init cleanup queue:

   http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git/

so it will be fine for the next linux-next tree.

Thanks,
Paul.
--

> 
> My patch seems valid although the reason in commit msg should be updated:
> 
> Add missing include to fix build error:
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type 
> or storage class [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> declaration of ‘module_init’ [-Werror=implicit-int]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> types) in function declaration [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type 
> or storage class [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> declaration of ‘module_exit’ [-Werror=implicit-int]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> types) in function declaration [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: 
> ‘exynos_cpufreq_platdrv_init’ defined but not used [-Wunused-function]
> cc1: some warnings being treated as errors
> make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
> make[1]: *** [drivers/cpufreq] Error 2
> 
> Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> and was introduced in next tree by commit caa7dcde7c42 (module: relocate
> module_init from init.h to module.h).
> 
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Krzysztof Kozlowski]

> 
> On Wed, 2014-01-22 at 20:12 +0530, Viresh Kumar wrote:
> > On 22 January 2014 19:51, Krzysztof Kozlowski  
> > wrote:
> > > Add missing include to fix build error:
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
> > > type or storage class [enabled by default]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> > > declaration of ‘module_init’ [-Werror=implicit-int]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> > > types) in function declaration [enabled by default]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
> > > type or storage class [enabled by default]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> > > declaration of ‘module_exit’ [-Werror=implicit-int]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> > > types) in function declaration [enabled by default]
> > > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: 
> > > ‘exynos_cpufreq_platdrv_init’ defined but not used [-Wunused-function]
> > > cc1: some warnings being treated as errors
> > > make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
> > > make[1]: *** [drivers/cpufreq] Error 2
> > >
> > > Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> > > and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
> > > exynos-cpufreq to platform driver).
> > >
> > > Signed-off-by: Krzysztof Kozlowski 
> > > Cc: Lukasz Majewski 
> > > Cc: Tomasz Figa 
> > > Cc: Kyungmin Park 
> > > ---
> > >  drivers/cpufreq/exynos-cpufreq.c |1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/cpufreq/exynos-cpufreq.c 
> > > b/drivers/cpufreq/exynos-cpufreq.c
> > > index fcd2914d081a..fa54c2b88dd7 100644
> > > --- a/drivers/cpufreq/exynos-cpufreq.c
> > > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > > @@ -17,6 +17,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > 
> > I am surprised how that patch went through then? And nothing was
> > reported by kbuild for it..
> 
> Hi,
> 
> A little more explanation from my side: the build error actually happens
> only on next/master, not Linus' tree.
> 
> Mentioned commit which changes the driver to platform driver is in
> mainline since 3.12-rc2 so it seems this is not the cause of the build
> error. I think I need to find first the real cause of this build error.
> 
> Best regards,
> Krzysztof

After bisecting, the real commit for build error is:
caa7dcde7c424cdc81698a6e4e48072eb67ec67e
module: relocate module_init from init.h to module.h

My patch seems valid although the reason in commit msg should be updated:

Add missing include to fix build error:
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_init’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_exit’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: ‘exynos_cpufreq_platdrv_init’ 
defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2

Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
and was introduced in next tree by commit caa7dcde7c42 (module: relocate
module_init from init.h to module.h).




--
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: [RFC PATCH 1/9] drm/exynos: correct timing porch conversion

[Andrzej Hajda]

Hi,

It seems I have not added description to this patch.
In this patch porch is calculated in compatible way to
drm_display_mode_from_videomode core function.
The way it was seems to me incorrect and it did not work on my hw.

Anyway this patch could be merged with Sean's patches, if he agrees.

Regards
Andrzej

On 01/22/2014 03:35 PM, Andrzej Hajda wrote:
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8caaac2..b611f33 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -538,21 +538,18 @@ static void fimd_mode_set(struct exynos_drm_manager 
> *mgr,
>  {
>   struct fimd_context *ctx = mgr->ctx;
>   struct fimd_mode_data *mode = &ctx->mode;
> - int hblank, vblank;
>  
> - vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
>   mode->vtotal = in_mode->crtc_vtotal;
>   mode->vdisplay = in_mode->crtc_vdisplay;
>   mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
> - mode->vbpd = (vblank - mode->vsync_len) / 2;
> - mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
> + mode->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
> + mode->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;
>  
> - hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
>   mode->htotal = in_mode->crtc_htotal;
>   mode->hdisplay = in_mode->crtc_hdisplay;
>   mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
> - mode->hbpd = (hblank - mode->hsync_len) / 2;
> - mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
> + mode->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
> + mode->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
>  
>   mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Krzysztof Kozlowski]

On Wed, 2014-01-22 at 20:12 +0530, Viresh Kumar wrote:
> On 22 January 2014 19:51, Krzysztof Kozlowski  wrote:
> > Add missing include to fix build error:
> > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
> > type or storage class [enabled by default]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> > declaration of ‘module_init’ [-Werror=implicit-int]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> > types) in function declaration [enabled by default]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no 
> > type or storage class [enabled by default]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> > declaration of ‘module_exit’ [-Werror=implicit-int]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> > types) in function declaration [enabled by default]
> > drivers/cpufreq/exynos-cpufreq.c:292:1: warning: 
> > ‘exynos_cpufreq_platdrv_init’ defined but not used [-Wunused-function]
> > cc1: some warnings being treated as errors
> > make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
> > make[1]: *** [drivers/cpufreq] Error 2
> >
> > Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> > and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
> > exynos-cpufreq to platform driver).
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > Cc: Lukasz Majewski 
> > Cc: Tomasz Figa 
> > Cc: Kyungmin Park 
> > ---
> >  drivers/cpufreq/exynos-cpufreq.c |1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/cpufreq/exynos-cpufreq.c 
> > b/drivers/cpufreq/exynos-cpufreq.c
> > index fcd2914d081a..fa54c2b88dd7 100644
> > --- a/drivers/cpufreq/exynos-cpufreq.c
> > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> 
> I am surprised how that patch went through then? And nothing was
> reported by kbuild for it..

Hi,

A little more explanation from my side: the build error actually happens
only on next/master, not Linus' tree.

Mentioned commit which changes the driver to platform driver is in
mainline since 3.12-rc2 so it seems this is not the cause of the build
error. I think I need to find first the real cause of this build error.

Best regards,
Krzysztof



--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Viresh Kumar]

On 22 January 2014 19:51, Krzysztof Kozlowski  wrote:
> Add missing include to fix build error:
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type 
> or storage class [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> declaration of ‘module_init’ [-Werror=implicit-int]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> types) in function declaration [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type 
> or storage class [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
> declaration of ‘module_exit’ [-Werror=implicit-int]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
> types) in function declaration [enabled by default]
> drivers/cpufreq/exynos-cpufreq.c:292:1: warning: 
> ‘exynos_cpufreq_platdrv_init’ defined but not used [-Wunused-function]
> cc1: some warnings being treated as errors
> make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
> make[1]: *** [drivers/cpufreq] Error 2
>
> Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
> exynos-cpufreq to platform driver).
>
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Lukasz Majewski 
> Cc: Tomasz Figa 
> Cc: Kyungmin Park 
> ---
>  drivers/cpufreq/exynos-cpufreq.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c 
> b/drivers/cpufreq/exynos-cpufreq.c
> index fcd2914d081a..fa54c2b88dd7 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 

I am surprised how that patch went through then? And nothing was
reported by kbuild for it..
--
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

[RFC PATCH 6/9] drm/panel: add s6e8aa0 driver

[Andrzej Hajda]

The patch adds MIPI-DSI based s6e8aa0 AMOLED LCD 5.3 inch panel driver.
Driver uses mipi_dsi bus to communicate with panel and exposes drm_panel
interface.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c | 1046 +
 3 files changed, 1054 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4f40d19..63b33ef 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -17,4 +17,11 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_S6E8AA0
+   tristate "S6E8AA0 DSI video mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af9dfa2..181265b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
new file mode 100644
index 000..e9b9ec1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -0,0 +1,1046 @@
+/*
+ * MIPI-DSI based s6e8aa0 AMOLED LCD 5.3 inch panel driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ * Donghwa Lee, 
+ * Joongmock Shin 
+ * Eunchul Kim 
+ * Tomasz Figa 
+ *
+ * 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 
+#include 
+#include 
+
+#define LDI_MTP_LENGTH 24
+#define GAMMA_LEVEL_NUM25
+#define GAMMA_TABLE_LEN26
+
+#define PANELCTL_SS_MASK   (1 << 5)
+#define PANELCTL_SS_1_800  (0 << 5)
+#define PANELCTL_SS_800_1  (1 << 5)
+#define PANELCTL_GTCON_MASK(7 << 2)
+#define PANELCTL_GTCON_110 (6 << 2)
+#define PANELCTL_GTCON_111 (7 << 2)
+
+#define PANELCTL_CLK1_CON_MASK (7 << 3)
+#define PANELCTL_CLK1_000  (0 << 3)
+#define PANELCTL_CLK1_001  (1 << 3)
+#define PANELCTL_CLK2_CON_MASK (7 << 0)
+#define PANELCTL_CLK2_000  (0 << 0)
+#define PANELCTL_CLK2_001  (1 << 0)
+
+#define PANELCTL_INT1_CON_MASK (7 << 3)
+#define PANELCTL_INT1_000  (0 << 3)
+#define PANELCTL_INT1_001  (1 << 3)
+#define PANELCTL_INT2_CON_MASK (7 << 0)
+#define PANELCTL_INT2_000  (0 << 0)
+#define PANELCTL_INT2_001  (1 << 0)
+
+#define PANELCTL_BICTL_CON_MASK(7 << 3)
+#define PANELCTL_BICTL_000 (0 << 3)
+#define PANELCTL_BICTL_001 (1 << 3)
+#define PANELCTL_BICTLB_CON_MASK   (7 << 0)
+#define PANELCTL_BICTLB_000(0 << 0)
+#define PANELCTL_BICTLB_001(1 << 0)
+
+#define PANELCTL_EM_CLK1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK1_110   (6 << 3)
+#define PANELCTL_EM_CLK1_111   (7 << 3)
+#define PANELCTL_EM_CLK1B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK1B_110  (6 << 0)
+#define PANELCTL_EM_CLK1B_111  (7 << 0)
+
+#define PANELCTL_EM_CLK2_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK2_110   (6 << 3)
+#define PANELCTL_EM_CLK2_111   (7 << 3)
+#define PANELCTL_EM_CLK2B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK2B_110  (6 << 0)
+#define PANELCTL_EM_CLK2B_111  (7 << 0)
+
+#define PANELCTL_EM_INT1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_INT1_000   (0 << 3)
+#define PANELCTL_EM_INT1_001   (1 << 3)
+#define PANELCTL_EM_INT2_CON_MASK  (7 << 0)
+#define PANELCTL_EM_INT2_000   (0 << 0)
+#define PANELCTL_EM_INT2_001   (1 << 0)
+
+#define AID_DISABLE(0x4)
+#define AID_1  (0x5)
+#define AID_2  (0x6)
+#define AID_3  (0x7)
+
+#define s6e8aa0_dcs_write(lcd, seq...) \
+({\
+   const u8 d[] = { seq };\
+   struct mipi_dsi_device *dsi = to_mipi_dsi_device(lcd->dev); \
+   BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "DCS sequence too big for stack");\
+   mipi_dsi_dcs_write(dsi, dsi->channel, d, ARRAY_SIZE(d));\
+})
+
+#define s6e8aa0_dcs_write_static(lcd, seq...) \
+({\
+   static const u8 d[] = { seq };\
+   struct mipi_dsi_device *dsi = to_mipi_dsi_device(lcd->dev); \
+   mipi_dsi_dcs_write(dsi, dsi->channel, d, ARRAY_SIZE(d));\
+})
+
+typedef u8 s6e8aa0_gamma_t

[RFC PATCH 7/9] ARM: dts: exynos4: add MIPI DSI Master node

[Andrzej Hajda]

This is a common part of DSI node for all Exynos4 boards.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index a73eeb5..7102f29 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -104,6 +104,20 @@
reg = <0x1001 0x400>;
};
 
+   dsi_0: dsi@11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   samsung,power-domain = <&pd_lcd0>;
+   phys = <&mipi_phy 1>;
+   phy-names = "dsim";
+   clocks = <&clock 286>, <&clock 143>;
+   clock-names = "bus_clk", "pll_clk";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
camera {
compatible = "samsung,fimc", "simple-bus";
status = "disabled";
-- 
1.8.3.2

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

[RFC PATCH 5/9] panel/s6e8aa0: add DT bindings

[Andrzej Hajda]

The patch adds bindings for s6e8aa0 panel.
Bindings describes panel resources, boot delays,
display timings, orientation and physical size.

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/panel/samsung-s6e8aa0.txt  | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt 
b/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
new file mode 100644
index 000..675e66e
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
@@ -0,0 +1,53 @@
+Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e8aa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+  - power-on-delay: delay after turning regulators on [ms]
+  - reset-delay: delay after reset sequence [ms]
+  - init-delay: delay after initialization sequence [ms]
+  - samsung,panel-width-mm: physical panel width [mm]
+  - samsung,panel-height-mm: physical panel height [mm]
+  - flip-horizontal: boolean to flip image horizontally
+  - flip-vertical: boolean to flip image vertically
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+   panel {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <&vcclcd_reg>;
+   vci-supply = <&vlcd_reg>;
+   reset-gpio = <&gpy4 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+   flip-horizontal;
+   flip-vertical;
+
+   display-timings {
+   native-mode = <&timing0>;
+
+   timing0: timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
-- 
1.8.3.2

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

[RFC PATCH 8/9] ARM: dts: exynos4210-trats: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats.
It adds also trats specific properties for DSI.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 36 ++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index e4c4913..105f212 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -379,6 +379,42 @@
};
};
 
+   dsi_0: dsi@11C8 {
+   vddcore-supply = <&vusb_reg>;
+   vddio-supply = <&vmipi_reg>;
+   samsung,pll-clk-freq = <2400>;
+   status = "okay";
+
+   panel@0 {
+   reg = <0>;
+   compatible = "samsung,s6e8aa0";
+   vdd3-supply = <&vcclcd_reg>;
+   vci-supply = <&vlcd_reg>;
+   reset-gpio = <&gpy4 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
+   };
+
fimd@11c0 {
samsung,fimd-vidout-rgb;
samsung,fimd-inv-vclk;
-- 
1.8.3.2

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

[RFC PATCH 9/9] ARM: dts: exynos4412-trats2: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats2.
It adds also trats2 specific properties for DSI
and regulator required by panel.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 2867c4e..3243b76 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -442,6 +442,15 @@
};
};
 
+   lcd_vdd3_reg: voltage-regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "LCD_VDD_2.2V";
+   regulator-min-microvolt = <220>;
+   regulator-max-microvolt = <220>;
+   gpio = <&gpc0 1 0>;
+   enable-active-high;
+   };
+
sdhci@1251 {
bus-width = <8>;
non-removable;
@@ -498,6 +507,42 @@
};
};
 
+   dsi_0: dsi@11C8 {
+   vddcore-supply = <&ldo8_reg>;
+   vddio-supply = <&ldo10_reg>;
+   samsung,pll-clk-freq = <2400>;
+   status = "okay";
+
+   panel@0 {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <&lcd_vdd3_reg>;
+   vci-supply = <&ldo25_reg>;
+   reset-gpio = <&gpy4 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
+   };
+
fimd@11c0 {
samsung,fimd-vidout-rgb;
samsung,fimd-inv-vclk;
-- 
1.8.3.2

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

[RFC PATCH 0/9] Exynos DSI master and S6E8AA0 panel drivers

[Andrzej Hajda]

Hi,

This patch set adds bindings and drivers to Exynos MIPI-DSI host and S6E8AA0 
panel.
Both devices are present in Trats and Trats2 targets which are present
in mainline kernel and currently have no display support.
Patchset contains also patches adding corresponding DTS nodes to both devices.

Both drivers are based on patches posted by Tomasz [2].

Drivers have been successfully tested on both devices.

Exynos DSI driver supports only video mode, command mode will be added later.

Patchset contains two additional patches:
- 1st patch corrects porch calculation in function introduced by refactoring
  patches [1],
- 2nd patch delays fbdev initialization to allow fbdev work with devices

Patches are based on branch next-20131211 plus exynos refactoring patches
by Sean Paul [1] plus resolving many merge conflicts.
I have also cherry-picked patches adding drm_panel and drm_mipi_dsi support 
which
were not merged at this time. I hope Sean's patches will be merged soon,
so I could rebase this patchset in saner way.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/94358
[2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15684

Regards
Andrzej

Andrzej Hajda (9):
  drm/exynos: correct timing porch conversion
  drm/exynos: delay fbdev initialization until an output is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  drm/panel: add s6e8aa0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node

 .../devicetree/bindings/panel/samsung-s6e8aa0.txt  |   53 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   48 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   36 +
 arch/arm/boot/dts/exynos4412-trats2.dts|   45 +
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   26 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1393 
 drivers/gpu/drm/exynos/exynos_drm_fb.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   11 +-
 drivers/gpu/drm/panel/Kconfig  |7 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1046 +++
 16 files changed, 2678 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

-- 
1.8.3.2

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

[RFC PATCH 4/9] drm/exynos: add DSIM driver

[Andrzej Hajda]

The patch adds driver for Exynos DSI master (DSIM). It is a platform driver
which is registered as exynos_drm_display sub-driver of exynos_drm framework
and implements DRM encoder/connector pair.
It is also MIPI-DSI host driver and provides DSI bus for panels.
It interacts with its panel(s) using drm_panel framework.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Kconfig  |9 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1393 +++
 5 files changed, 1418 insertions(+)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7441c4a..3681a06 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -31,6 +31,15 @@ config DRM_EXYNOS_FIMD
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
+config DRM_EXYNOS_DSI
+   bool "EXYNOS DRM MIPI-DSI driver support"
+   depends on DRM_EXYNOS
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   default n
+   help
+ This enables support for Exynos MIPI-DSI device.
+
 config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on ARCH_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index b1839e8..02dde22 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -11,6 +11,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp_core.o exynos_dp_reg.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4dc9f0d..57ee22a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -419,6 +419,12 @@ static int __init exynos_drm_init(void)
goto out_dp;
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_DSI
+   ret = platform_driver_register(&dsi_driver);
+   if (ret < 0)
+   goto out_dsi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(&fimd_driver);
if (ret < 0)
@@ -534,6 +540,10 @@ out_hdmi:
platform_driver_unregister(&fimd_driver);
 out_fimd:
 #endif
+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(&dsi_driver);
+out_dsi:
+#endif
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(&dp_driver);
 out_dp:
@@ -581,6 +591,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(&fimd_driver);
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(&dsi_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(&dp_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 26bf10a..03c1f4d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -361,6 +361,7 @@ int exynos_platform_device_ipp_register(void);
 void exynos_platform_device_ipp_unregister(void);
 
 extern struct platform_driver dp_driver;
+extern struct platform_driver dsi_driver;
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
new file mode 100644
index 000..794bca0
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -0,0 +1,1393 @@
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa 
+ *
+ * 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 
+#include 
+
+#include 
+#include 
+
+#include "exynos_drm_drv.h"
+
+#define DSIM_STATUS_REG0x0 /* Status register */
+#define DSIM_SWRST_REG 0x4 /* Software reset register */
+#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
+#define DSIM_TIMEOUT_REG   0xc /* Time out register */
+#define DSIM_CONFIG_REG0x10/* Configuration register */
+#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
+
+/* Main display image resolution register */
+#define DSIM_MDRESOL_REG   0x18
+#d

[RFC PATCH 3/9] exynos/dsim: add DT bindings

[Andrzej Hajda]

The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
for DSI bus host bindings [1].
Other properties describes its resources: memory, interrupt, clocks,
phy, regulators.
There is only one configuration property: pll-clock-frequency.

[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/video/exynos_dsim.txt  | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
new file mode 100644
index 000..0246e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -0,0 +1,48 @@
+Exynos MIPI DSI Master
+
+Required properties:
+  - compatible: "samsung,exynos4210-mipi-dsi"
+  - reg: physical base address and length of the registers set for the device
+  - interrupts: should contain DSI interrupt
+  - clocks: list of clock specifiers, must contain an entry for each required
+entry in clock-names
+  - clock-names: should include "bus_clk"and "pll_clk" entries
+  - phys: list of phy specifiers, must contain an entry for each required
+entry in phy-names
+  - phy-names: should include "dsim" entry
+  - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
+  - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
+  - pll-clock-frequency: specifies frequency of "pll_clk" clock
+  - #address-cells, #size-cells: should be set respectively to <1> and <0>
+according to DSI host bindings (see MIPI DSI bindings [1])
+
+Optional properties:
+  - samsung,power-domain: a phandle to DSIM power domain node
+
+Child nodes:
+  Should contain DSI peripheral nodes (see DSI bindings [1])
+
+[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+Example:
+
+   dsi@11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   clocks = <&clock 286>, <&clock 143>;
+   clock-names = "bus_clk", "pll_clk";
+   phys = <&mipi_phy 1>;
+   phy-names = "dsim";
+   vddcore-supply = <&vusb_reg>;
+   vddio-supply = <&vmipi_reg>;
+   samsung,power-domain = <&pd_lcd0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pll-clock-frequency = <2400>;
+
+   panel@0 {
+   reg = <0>;
+   ...
+   };
+   };
-- 
1.8.3.2

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

[RFC PATCH 2/9] drm/exynos: delay fbdev initialization until an output is connected

[Andrzej Hajda]

In case fbdev is initialized before any output is connected,
fb resolution defaults to 1024x768. After that any output with
bigger resolution is ignored and fbdev is not displayed.
The patch postpones fbdev initialization to avoid such situation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  3 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  4 +++-
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cbb53a3..4dc9f0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -107,22 +107,10 @@ static int exynos_drm_load(struct drm_device *dev, 
unsigned long flags)
/* setup possible_clones. */
exynos_drm_encoder_setup(dev);
 
-   /*
-* create and configure fb helper and also exynos specific
-* fbdev object.
-*/
-   ret = exynos_drm_fbdev_init(dev);
-   if (ret) {
-   DRM_ERROR("failed to initialize drm fbdev\n");
-   goto err_drm_device;
-   }
-
drm_vblank_offdelay = VBLANK_OFF_DELAY;
 
return 0;
 
-err_drm_device:
-   exynos_drm_device_unregister(dev);
 err_vblank:
drm_vblank_cleanup(dev);
 err_display_cleanup:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c7c08d0..65a22ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -20,6 +20,7 @@
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
+#include "exynos_drm_fbdev.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"
 #include "exynos_drm_crtc.h"
@@ -300,6 +301,8 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
 
if (fb_helper)
drm_fb_helper_hotplug_event(fb_helper);
+   else
+   exynos_drm_fbdev_init(dev);
 }
 
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e7c2f2d..9a5ec83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -249,8 +249,10 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
return 0;
 
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
-   if (!fbdev)
+   if (!fbdev) {
+   DRM_ERROR("failed to allocate fbdev.\n");
return -ENOMEM;
+   }
 
private->fb_helper = helper = &fbdev->drm_fb_helper;
helper->funcs = &exynos_drm_fb_helper_funcs;
-- 
1.8.3.2

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

[RFC PATCH 1/9] drm/exynos: correct timing porch conversion

[Andrzej Hajda]

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8caaac2..b611f33 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -538,21 +538,18 @@ static void fimd_mode_set(struct exynos_drm_manager *mgr,
 {
struct fimd_context *ctx = mgr->ctx;
struct fimd_mode_data *mode = &ctx->mode;
-   int hblank, vblank;
 
-   vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
mode->vtotal = in_mode->crtc_vtotal;
mode->vdisplay = in_mode->crtc_vdisplay;
mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
-   mode->vbpd = (vblank - mode->vsync_len) / 2;
-   mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
+   mode->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
+   mode->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;
 
-   hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
mode->htotal = in_mode->crtc_htotal;
mode->hdisplay = in_mode->crtc_hdisplay;
mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
-   mode->hbpd = (hblank - mode->hsync_len) / 2;
-   mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
+   mode->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
+   mode->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
 
mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
 
-- 
1.8.3.2

--
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 RESEND] cpufreq: exynos: Fix build error of no type of module_init

[Krzysztof Kozlowski]

Add missing include to fix build error:
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_init’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_exit’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: ‘exynos_cpufreq_platdrv_init’ 
defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2

Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
exynos-cpufreq to platform driver).

Signed-off-by: Krzysztof Kozlowski 
Cc: Lukasz Majewski 
Cc: Tomasz Figa 
Cc: Kyungmin Park 
---
 drivers/cpufreq/exynos-cpufreq.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index fcd2914d081a..fa54c2b88dd7 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cpufreq: exynos: Fix build error of no type of module_init

[y]

From: Krzysztof Kozlowski 

Add missing include to fix build error:
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_init’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: data definition has no type or 
storage class [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: error: type defaults to ‘int’ in 
declaration of ‘module_exit’ [-Werror=implicit-int]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: parameter names (without 
types) in function declaration [enabled by default]
drivers/cpufreq/exynos-cpufreq.c:292:1: warning: ‘exynos_cpufreq_platdrv_init’ 
defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2

Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
and was introduced by commit d568b6f71df1 (cpufreq: exynos: Convert
exynos-cpufreq to platform driver).

Signed-off-by: Krzysztof Kozlowski 
Cc: Lukasz Majewski 
Cc: Tomasz Figa 
Cc: Kyungmin Park 
---
 drivers/cpufreq/exynos-cpufreq.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index fcd2914d081a..fa54c2b88dd7 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: EXYNOS: cpuidle: Fix build error of no type of module_init

[Krzysztof Kozlowski]

Add missing include to fix build error:
arch/arm/mach-exynos/cpuidle.c:256:1: warning: data definition has no type or 
storage class [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: error: type defaults to ‘int’ in 
declaration of ‘module_init’ [-Werror=implicit-int]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: parameter names (without types) 
in function declaration [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: data definition has no type or 
storage class [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: error: type defaults to ‘int’ in 
declaration of ‘module_exit’ [-Werror=implicit-int]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: parameter names (without types) 
in function declaration [enabled by default]
arch/arm/mach-exynos/cpuidle.c:256:1: warning: ‘exynos_cpuidle_driver_init’ 
defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-exynos/cpuidle.o] Error 1

Build error happens on gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
and was introduced by commit 35baa3369d1c (ARM: EXYNOS: convert cpuidle
driver to be a platform driver).

Signed-off-by: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Kyungmin Park 
---
 arch/arm/mach-exynos/cpuidle.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index f57cb91f02aa..53dc1e705b2f 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] ARM: EXYNOS: Consolidate CPU init code

[Sachin Kamat]

cpu_table was used to distinguish between different Exynos4 and 5 SoCs
and assign the the initialization and io mapping pointers based on type.
exynos_init is dummy and no longer needed as we do a DT based booting.
By having a common io mapping function we can get rid of the whole
table and avoid populating it for every SoC.

Tested on Exynos4210, 5250 and 5420 based boards.

Signed-off-by: Sachin Kamat 
---
 arch/arm/mach-exynos/common.c |   93 -
 1 file changed, 17 insertions(+), 76 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index f18be40e5b21..02d0aaa7af59 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -48,55 +48,7 @@
 #define L2_AUX_VAL 0x7C470001
 #define L2_AUX_MASK 0xC200
 
-static const char name_exynos4210[] = "EXYNOS4210";
-static const char name_exynos4212[] = "EXYNOS4212";
-static const char name_exynos4412[] = "EXYNOS4412";
-static const char name_exynos5250[] = "EXYNOS5250";
-static const char name_exynos5420[] = "EXYNOS5420";
-static const char name_exynos5440[] = "EXYNOS5440";
-
-static void exynos4_map_io(void);
-static void exynos5_map_io(void);
-static int exynos_init(void);
-
-static struct cpu_table cpu_ids[] __initdata = {
-   {
-   .idcode = EXYNOS4210_CPU_ID,
-   .idmask = EXYNOS4_CPU_MASK,
-   .map_io = exynos4_map_io,
-   .init   = exynos_init,
-   .name   = name_exynos4210,
-   }, {
-   .idcode = EXYNOS4212_CPU_ID,
-   .idmask = EXYNOS4_CPU_MASK,
-   .map_io = exynos4_map_io,
-   .init   = exynos_init,
-   .name   = name_exynos4212,
-   }, {
-   .idcode = EXYNOS4412_CPU_ID,
-   .idmask = EXYNOS4_CPU_MASK,
-   .map_io = exynos4_map_io,
-   .init   = exynos_init,
-   .name   = name_exynos4412,
-   }, {
-   .idcode = EXYNOS5250_SOC_ID,
-   .idmask = EXYNOS5_SOC_MASK,
-   .map_io = exynos5_map_io,
-   .init   = exynos_init,
-   .name   = name_exynos5250,
-   }, {
-   .idcode = EXYNOS5420_SOC_ID,
-   .idmask = EXYNOS5_SOC_MASK,
-   .map_io = exynos5_map_io,
-   .init   = exynos_init,
-   .name   = name_exynos5420,
-   }, {
-   .idcode = EXYNOS5440_SOC_ID,
-   .idmask = EXYNOS5_SOC_MASK,
-   .init   = exynos_init,
-   .name   = name_exynos5440,
-   },
-};
+static void exynos_map_io(void);
 
 /* Initial IO mappings */
 
@@ -355,28 +307,28 @@ void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
 
-   s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+   exynos_map_io();
 }
 
-static void __init exynos4_map_io(void)
+static void __init exynos_map_io(void)
 {
-   iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
-   if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0)
-   iotable_init(exynos4_iodesc0, ARRAY_SIZE(exynos4_iodesc0));
-   else
-   iotable_init(exynos4_iodesc1, ARRAY_SIZE(exynos4_iodesc1));
-
-   if (soc_is_exynos4210())
+   if (soc_is_exynos4210() || soc_is_exynos4212() || soc_is_exynos4412())
+   iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+
+   if (soc_is_exynos5250() || soc_is_exynos5420())
+   iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
+
+   if (soc_is_exynos4210()) {
+   if (samsung_rev() == EXYNOS4210_REV_0)
+   iotable_init(exynos4_iodesc0,
+   ARRAY_SIZE(exynos4_iodesc0));
+   else
+   iotable_init(exynos4_iodesc1,
+   ARRAY_SIZE(exynos4_iodesc1));
iotable_init(exynos4210_iodesc, ARRAY_SIZE(exynos4210_iodesc));
+   }
if (soc_is_exynos4212() || soc_is_exynos4412())
iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
-}
-
-static void __init exynos5_map_io(void)
-{
-   iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
-
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
 }
@@ -386,10 +338,6 @@ struct bus_type exynos_subsys = {
.dev_name   = "exynos-core",
 };
 
-static struct device exynos4_dev = {
-   .bus= &exynos_subsys,
-};
-
 static int __init exynos_core_init(void)
 {
return subsys_system_register(&exynos_subsys, NULL);
@@ -409,10 +357,3 @@ static in

Re: [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up

[Lorenzo Pieralisi]

On Mon, Jan 20, 2014 at 05:32:53PM +, Tomasz Figa wrote:
> Hi Lorenzo,
> 
> On 16.01.2014 17:34, Lorenzo Pieralisi wrote:
> > Hi Tomasz,
> >
> > thank you for posting this series. I would like to use the DT bindings
> > for power domains in the bindings for C-states on ARM:
> >
> > http://comments.gmane.org/gmane.linux.power-management.general/41012
> >
> > and in particular link a given C-state to a given power domain so that the
> > kernel will have a way to actually check what devices are lost upon C-state
> > entry (and for devices I also mean CPU peripheral like PMUs, GIC CPU IF,
> > caches and possibly cpus, all of them already represented with DT nodes).
> >
> > I have a remark:
> >
> > -  Can we group device nodes under a single power-domain-parent so that
> > all devices defined under that parent won't have to re-define a
> > power-domain property (a property like interrupt-parent, so to speak)
> >
> > What do you think ?
> 
> Hmm, I can see potential benefits of such construct on platforms with 
> clear hierarchy of devices, but to make sure I'm getting it correctly, 
> is the following what you have in mind?
> 
> soc-domain-x@1234 {
>   compatible = "...";
>   reg = <...>;
>   power-domain-parent = <&power_domains DOMAIN_X>;
> 
>   device@1000 {
>   compatible = "...";
>   // inherits power-domain = <&power_domains DOMAIN_X>
>   };
> 
>   device@2000 {
>   compatible = "...";
>   // inherits power-domain = <&power_domains DOMAIN_X>
>   };
> };

Yes, exactly, it could avoid duplicated data. I still have an issue
with nodes that are per-cpu but define just one node (eg PMU), since
a CPU might belong in a power-domain on its own (ie one power domain
per-CPU) and basically this means that arch-timers, PMU & company should
link to multiple power domains, ie one per CPU or we find a way to define
a power domain as "banked".

I need to think about this a bit more, thanks for your feedback.

Lorenzo

--
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] Documentation: devicetree: mct: Fix counter bit of CPU local timers

[Daniel Lezcano]

On 01/22/2014 09:08 AM, Jingoo Han wrote:

On Tuesday, January 21, 2014 6:03 PM, Jingoo Han wrote:


According to the datasheet of Exynos SoCs, the counter bit
of CPU local timers is 31-bit, not 32-bit; thus, it should
be fixed.


Please, ignore this patch.
There is a 31-bit counter in CPU local timers; however,
FRC (free running down-counters) of CPU local timers is
32-bit. Thus, there is no need to fix it.
Thank you.


Ok.



Signed-off-by: Jingoo Han 
---
  Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index 167d5da..8c77791 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
  global timer and CPU local timers. The global timer is a 64-bit free running
  up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
+four preset counter values. The CPU local timers are 31-bit free running
  down-counters and generate an interrupt when the counter expires. There is
  one CPU local timer instantiated in MCT for every CPU in the system.

--
1.7.10.4






--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: devicetree: mct: Fix counter bit of CPU local timers

[Jingoo Han]

On Tuesday, January 21, 2014 6:03 PM, Jingoo Han wrote:
> 
> According to the datasheet of Exynos SoCs, the counter bit
> of CPU local timers is 31-bit, not 32-bit; thus, it should
> be fixed.

Please, ignore this patch.
There is a 31-bit counter in CPU local timers; however,
FRC (free running down-counters) of CPU local timers is
32-bit. Thus, there is no need to fix it.
Thank you.

Best regards,
Jingoo Han

> 
> Signed-off-by: Jingoo Han 
> ---
>  Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> index 167d5da..8c77791 100644
> --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> @@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
>  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
>  global timer and CPU local timers. The global timer is a 64-bit free running
>  up-counter and can generate 4 interrupts when the counter reaches one of the
> -four preset counter values. The CPU local timers are 32-bit free running
> +four preset counter values. The CPU local timers are 31-bit free running
>  down-counters and generate an interrupt when the counter expires. There is
>  one CPU local timer instantiated in MCT for every CPU in the system.
> 
> --
> 1.7.10.4


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html