Re: [PATCH v5 3/9] dt: exynos5250: Enable support for generic USB DRD phy

2014-04-24 Thread Tushar Behera
On 04/23/2014 08:00 PM, Vivek Gautam wrote:
> Add device tree node for new usbdrd-phy driver, which
> is based on generic phy framework.
> 
> Signed-off-by: Vivek Gautam 
> Reviewed-by: Tomasz Figa 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 3742331..d4254c0 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -551,6 +551,16 @@
>   };
>   };
>  
> + usbdrd_phy: phy@1210 {
> + compatible = "samsung,exynos5250-usbdrd-phy";
> + reg = <0x1210 0x100>;
> + clocks = <&clock CLK_USB3>, <&clock CLK_FIN_PLL>;
> + clock-names = "phy", "ref";
> + samsung,pmu-syscon = <&pmu_system_controller>;

Replace samsung,pmu-syscon by samsung,syscon-phandle ?

> + samsung,pmu-offset = <0x704>;
> + #phy-cells = <1>;
> + };
> +
>   usb@1211 {
>   compatible = "samsung,exynos4210-ehci";
>   reg = <0x1211 0x100>;
> 


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


Re: [PATCH v5 1/9] dt: exynos5420: Enable support for USB 3.0 PHY controller

2014-04-24 Thread Tushar Behera
On 04/23/2014 08:00 PM, Vivek Gautam wrote:
> Add device tree nodes for USB 3.0 PHY present alongwith
> USB 3.0 controller Exynos 5420 SoC. This phy driver is
> based on generic phy framework.
> 
> Signed-off-by: Vivek Gautam 
> Reviewed-by: Tomasz Figa 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |   20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index c3a9a66..f69745f 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -732,4 +732,24 @@
>   clock-names = "secss";
>   samsung,power-domain = <&g2d_pd>;
>   };
> +
> + usbdrd_phy0: phy@1210 {
> + compatible = "samsung,exynos5420-usbdrd-phy";
> + reg = <0x1210 0x100>;
> + clocks = <&clock CLK_USBD300>, <&clock CLK_SCLK_USBPHY300>;
> + clock-names = "phy", "ref";
> + samsung,pmu-syscon = <&pmu_system_controller>;

Should the property name be samsung,syscon-phandle as used elsewhere?

samsung,syscon-phandle = <&pmu_system_controller>;

> + samsung,pmu-offset = <0x704>;
> + #phy-cells = <1>;
> + };
> +
> + usbdrd_phy1: phy@1250 {
> + compatible = "samsung,exynos5420-usbdrd-phy";
> + reg = <0x1250 0x100>;
> + clocks = <&clock CLK_USBD301>, <&clock CLK_SCLK_USBPHY301>;
> + clock-names = "phy", "ref";
> + samsung,pmu-syscon = <&pmu_system_controller>;

ditto

> + samsung,pmu-offset = <0x708>;
> + #phy-cells = <1>;
> + };
>  };
> 


-- 
Tushar Behera
--
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 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
Sorry for the previous reply. Here goes the full explaination.

On Fri, Apr 25, 2014 at 11:40 AM, Ajay kumar  wrote:
> On Thu, Apr 24, 2014 at 11:08 PM, Ajay kumar  wrote:
>> On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark  wrote:
>>> On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar  wrote:
 Rob,

 On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark  wrote:
> On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
>> Sorry for the previous reply,
>>
>> Here goes the full explaination:
>>
>>> Rob,
>>>
>>> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb->bridge)
   pb->bridge->funcs->enable(pb->bridge);
 pb->panel->funcs->enable(pb->panel);
   }

>> We cannot call them like this from crtc helpers in the order you 
>> mentioned,
>> since each individual bridge chip expects the panel controls at
>> different places.
>> I mean,
>> -- sometimes panel controls needs to be done before bridge
>> controls(ptn3460: before RST_N and PD_N)
>
> well, this is why bridge has pre-enable/enable/disable/post-disable
> hooks, so you can choose before or after..
 These calls are for a bridge to sync with the encoder calls.
 We might end up defining pre-enable/enable/disable/post-disable for a
 panel to sync
 with the bridge calls! I have explained below.

>> -- sometimes in between the bridge controls (ps8622: one panel control
>> before SLP_N and one after SLP_N)
>> -- sometimes panel controls needs to be done after bridge controls.
>
> I am not convinced that a generic panel/bridge adapter is not
> possible.  Maybe we need more fine grained fxn ptr callbacks, although
> seems like pre+post should give you enough.  It would certainly be
> easier than having to add panel support in each individual bridge
> driver (which seems like it will certainly result that only certain
> combinations of panel+bridge actually work as intended)
 Ok. Consider this case:
 Currently, we have the sequence as "bridge->pre_enable,
 encoder_enable, bridge->enable"
 And, the bridge should obviously be enabled in bridge->pre_enable.
 Now, where do you choose to call panel->pre_enable?
 -- as the first step of bridge->pre_enable, before we pull up/down bridge 
 GPIOs.
 -- at the last step of bridge->pre_enable, after we pull up/down the
 bridge GPIOs.

 Ideally, PTN3460 expects it to be the second case, and PS8625 expects
 it to be the first case.
 So, we will end up adding pre_pre_enable, post_pre_enable to
 accomodate such scenarios.
>>>
>>> ok, well I think we can deal with this with a slight modification of
>>> my original proposal.  Split drm_panel_bridge into
>>> drm_composite_bridge and drm_panel_bridge:
>>>
>>>   struct drm_composite_bridge {
>>> struct drm_bridge base;
>>> struct drm_bridge *b1, *b2;
>>>   }
>>>
>>>   static void drm_composite_bridge_enable(struct drm_bridge *bridge)
>>>   {
>>> struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
>>> cbridge->b1->funcs->enable(cbridge->b1);
>>> cbridge->b2->funcs->enable(cbridge->b2);
>>>   }
>>>
>>>   .. and so on ..
>>>
>>>   struct drm_panel_bridge {
>>> struct drm_bridge base;
>>> struct drm_panel *panel;
>>>   }
>>>
>>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>>   {
>>> struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
>>> pbridge->panel->funcs->enable(pbridge->panel);
>>>   }
>>>
>>>   .. and so on..
>>>
>>>
>>> then in initialization, order can be managed like:
>>>
>>>   if (panel_first)
>>> bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
>>>   else
>>> bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);
>>>
>>>   possibly parametrize drm_panel_bridge if we need to map
>>> panel->enable() to bridge->pre_enable() vs bridge->enable(), etc..
>>
>> Well, this really does seems complex to me.
>> Don't you think just having a drm_panel inside drm_bridge structure is
>> sufficient?!
>> And, make a call for pre_panel_enable and post_panel_enable around
>> bridge->pre_enable..and so on.?
Adding more comments:
The beauty of drm_panel is in the flexibility which it provides.
We can call panel_enable/disable at the right point. Even the bridge chips
expect the same. So, I am not ok with combining the bridge and panel and

Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
On Thu, Apr 24, 2014 at 11:08 PM, Ajay kumar  wrote:
> On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark  wrote:
>> On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar  wrote:
>>> Rob,
>>>
>>> On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark  wrote:
 On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
> Sorry for the previous reply,
>
> Here goes the full explaination:
>
>> Rob,
>>
>> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
>>> So what about, rather than adding drm_panel support to each bridge
>>> individually, we introduce a drm_panel_bridge (with a form of
>>> chaining).. ie:
>>>
>>>   struct drm_panel_bridge {
>>> struct drm_bridge base;
>>> struct drm_panel *panel;
>>> struct drm_bridge *bridge; /* optional */
>>>   };
>>>
>>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>>   {
>>> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
>>> if (pb->bridge)
>>>   pb->bridge->funcs->enable(pb->bridge);
>>> pb->panel->funcs->enable(pb->panel);
>>>   }
>>>
> We cannot call them like this from crtc helpers in the order you 
> mentioned,
> since each individual bridge chip expects the panel controls at
> different places.
> I mean,
> -- sometimes panel controls needs to be done before bridge
> controls(ptn3460: before RST_N and PD_N)

 well, this is why bridge has pre-enable/enable/disable/post-disable
 hooks, so you can choose before or after..
>>> These calls are for a bridge to sync with the encoder calls.
>>> We might end up defining pre-enable/enable/disable/post-disable for a
>>> panel to sync
>>> with the bridge calls! I have explained below.
>>>
> -- sometimes in between the bridge controls (ps8622: one panel control
> before SLP_N and one after SLP_N)
> -- sometimes panel controls needs to be done after bridge controls.

 I am not convinced that a generic panel/bridge adapter is not
 possible.  Maybe we need more fine grained fxn ptr callbacks, although
 seems like pre+post should give you enough.  It would certainly be
 easier than having to add panel support in each individual bridge
 driver (which seems like it will certainly result that only certain
 combinations of panel+bridge actually work as intended)
>>> Ok. Consider this case:
>>> Currently, we have the sequence as "bridge->pre_enable,
>>> encoder_enable, bridge->enable"
>>> And, the bridge should obviously be enabled in bridge->pre_enable.
>>> Now, where do you choose to call panel->pre_enable?
>>> -- as the first step of bridge->pre_enable, before we pull up/down bridge 
>>> GPIOs.
>>> -- at the last step of bridge->pre_enable, after we pull up/down the
>>> bridge GPIOs.
>>>
>>> Ideally, PTN3460 expects it to be the second case, and PS8625 expects
>>> it to be the first case.
>>> So, we will end up adding pre_pre_enable, post_pre_enable to
>>> accomodate such scenarios.
>>
>> ok, well I think we can deal with this with a slight modification of
>> my original proposal.  Split drm_panel_bridge into
>> drm_composite_bridge and drm_panel_bridge:
>>
>>   struct drm_composite_bridge {
>> struct drm_bridge base;
>> struct drm_bridge *b1, *b2;
>>   }
>>
>>   static void drm_composite_bridge_enable(struct drm_bridge *bridge)
>>   {
>> struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
>> cbridge->b1->funcs->enable(cbridge->b1);
>> cbridge->b2->funcs->enable(cbridge->b2);
>>   }
>>
>>   .. and so on ..
>>
>>   struct drm_panel_bridge {
>> struct drm_bridge base;
>> struct drm_panel *panel;
>>   }
>>
>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>   {
>> struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
>> pbridge->panel->funcs->enable(pbridge->panel);
>>   }
>>
>>   .. and so on..
>>
>>
>> then in initialization, order can be managed like:
>>
>>   if (panel_first)
>> bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
>>   else
>> bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);
>>
>>   possibly parametrize drm_panel_bridge if we need to map
>> panel->enable() to bridge->pre_enable() vs bridge->enable(), etc..
>
> Well, this really does seems complex to me.
> Don't you think just having a drm_panel inside drm_bridge structure is
> sufficient?!
> And, make a call for pre_panel_enable and post_panel_enable around
> bridge->pre_enable..and so on.?
Adding more comments:
The beauty of drm_panel is in the flexibility which it provides.
We can call panel_enable/disable at the right point. Even the
--
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/9] drm/panel: add pre_enable and post_disable routines

2014-04-24 Thread Ajay kumar
On Friday, April 25, 2014, Thierry Reding  wrote:
>
> On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote:
> > Thierry,
> >
> > On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding
> >  wrote:
> > > On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote:
> [...]
> > >> Imo this makes sense, especially if we go through with the idea talked
> > >> about yesterday of creating a drm_bridge to wrap-up a drm_panel with
> > >> sufficient isolation between all components.
> > >
> > > I'm not at all comfortable with these. The names are totally confusing.
> > > Next somebody will need to do something after the panel has been enabled
> > > and we'll have to introduce .post_enable() and .pre_disable() functions.
> > > And worse, what if somebody needs something to be done between
> > > .pre_enable() and .enable()? .post_pre_enable()? Where does it end?
> > >
> > > According to the above description the only reason why we need this is
> > > to avoid visible glitches when the panel is already on, but the video
> > > stream hasn't started yet. If that's the only reason why we need this,
> > > then perhaps adding a way for a panel to expose the associated backlight
> > > would be better?
> > Actually, we need not expose the entire backlight device.
> > AFAIK, the glitch is caused when you enable BL_EN before
> > there is valid video data. So, one way to mask off the glitch is to
> > follow this sequence:
> > -- power up the panel.
> > -- start video data, (start PWM here or)
> > -- (start PWM here), enable backlight
>
> That's very difficult to get right, isn't it? Even if you have fine-
> grained control over what to enable you still need a way to determine
> _when_ it's safe to enable the backlight. Typically I guess that would
> be the duration of one frame (or perhaps 2, depending on when the panel
> syncs to the video signal).
We need not "determine", its already present in LVDS datasheet.
The LVDS datasheet says at least 200ms delay is needed from "Valid
data" to "BL on".

> Perhaps it could even by sync'ed to the VBLANK?
No. vblanks are related to crtc. And the bridge/panel driver should be
independent of vblank.

> > The problem is that the above scenario cannot be mapped to panel-simple 
> > driver.
> > IMO, panel_simple should provide enable/disable controls both for LCD
> > and backlight.
> > something like panel_simple_lcd_enable/panel_simple_led_enable, and
> > panel_simple_lcd_disable/panel_simple_led_disable.
>
> That's not what the simple panel driver can do. If we want this it needs
> to be solved in a generic way for all panels since they all need to use
> the drm_panel_*() functions to abstract away the details from drivers
> that use the panels.
Right. So only I have added pre_enable and post_disable callbacks.
Using that name won't harm existing panel drivers and still addresses
our requirement.


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


Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
Hi,

On 04/25/2014 02:54 PM, Tushar Behera wrote:
> On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 04/25/2014 01:30 PM, Tushar Behera wrote:
>>> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
 This patch fix the offset of CPU boot address and don't need to send smc 
 call
 of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 
 removes
 WFE in secure mode.

 Signed-off-by: Chanwoo Choi 
 Acked-by: Kyungmin Park 
 ---
  arch/arm/mach-exynos/firmware.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-exynos/firmware.c 
 b/arch/arm/mach-exynos/firmware.c
 index aa01c42..386d01d 100644
 --- a/arch/arm/mach-exynos/firmware.c
 +++ b/arch/arm/mach-exynos/firmware.c
 @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
  static int exynos_cpu_boot(int cpu)
  {
/*
 +   * Exynos3250 doesn't need to send smc command for secondary CPU boot
 +   * because Exynos3250 removes WFE in secure mode.
 +   */
 +  if (soc_is_exynos3250())
 +  return 0;
 +  /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
 -  if (soc_is_exynos4212())
 +  else if (soc_is_exynos4212())
>>>
>>> This changes is not required.
>>
>> Do you mean it as following?
>>
>>  if (soc_is_exynos3250())
>>  return 0
>>
>>  if (soc_is_exynos4212())
>>  cpu = 0;
>>
> 
> Yes, logically the flow would be same and code would be more readable.

OK, I'll fix it.

Thanks,
Chanwoo Choi

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


Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 11:13 AM, Chanwoo Choi wrote:
> Hi,
> 
> On 04/25/2014 01:30 PM, Tushar Behera wrote:
>> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
>>> This patch fix the offset of CPU boot address and don't need to send smc 
>>> call
>>> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 
>>> removes
>>> WFE in secure mode.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>> Acked-by: Kyungmin Park 
>>> ---
>>>  arch/arm/mach-exynos/firmware.c | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/firmware.c 
>>> b/arch/arm/mach-exynos/firmware.c
>>> index aa01c42..386d01d 100644
>>> --- a/arch/arm/mach-exynos/firmware.c
>>> +++ b/arch/arm/mach-exynos/firmware.c
>>> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
>>>  static int exynos_cpu_boot(int cpu)
>>>  {
>>> /*
>>> +* Exynos3250 doesn't need to send smc command for secondary CPU boot
>>> +* because Exynos3250 removes WFE in secure mode.
>>> +*/
>>> +   if (soc_is_exynos3250())
>>> +   return 0;
>>> +   /*
>>>  * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>>>  * But, Exynos4212 has only one secondary CPU so second parameter
>>>  * isn't used for informing secure firmware about CPU id.
>>>  */
>>> -   if (soc_is_exynos4212())
>>> +   else if (soc_is_exynos4212())
>>
>> This changes is not required.
> 
> Do you mean it as following?
> 
>   if (soc_is_exynos3250())
>   return 0
> 
>   if (soc_is_exynos4212())
>   cpu = 0;
> 

Yes, logically the flow would be same and code would be more readable.

>>
>>> cpu = 0;
>>>  
>>> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>>> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned 
>>> long boot_addr)
>>>  {
>>> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>>>  
>>> -   if (!soc_is_exynos4212())
>>> +   if (!soc_is_exynos4212() && !soc_is_exynos3250())
>>> boot_reg += 4*cpu;
>>>  
>>> __raw_writel(boot_addr, boot_reg);
>>>
>>
>>
> 


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


Re: [PATCH v3 00/16] exynos5420: clock file cleanup

2014-04-24 Thread Shaik Ameer Basha
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
 wrote:
> Many changes/fixes have been identified for clock file for exynos5420.
> These include correct parents, bit fields, new clocks etc. Existing
> files needs some correction in terms of names of the clock and
> indentation. These issues are addressed in this patch series. It also
> replaces the usage of enums with macro as clock ids.
>
> This patch series is rebased on,
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master
>
> This patch is also dependent on the following patch.
> ARM: dts: add dt node for sss module for exynos5250/5420

Sorry, it depends on SSS clock patch. Not the dts one.
clk: samsung exynos5250/5420: Add gate clock for SSS module

>
> Changes since v2:
> -
> 1] Addressed review comments from Gerhard Sittig and Tomasz Figa.
>
> Changes since v1:
> -
> 1] Addressed review comments from Tomasz Figa.
> http://www.spinics.net/lists/devicetree/msg16759.html
> http://www.spinics.net/lists/devicetree/msg16760.html
>
> Shaik Ameer Basha (16):
>   clk: exynos5420: rename parent clocks
>   clk: exynos5420: add clocks for ISP block
>   clk: exynos5420: update clocks for GSCL and MSCL blocks
>   clk: exynos5420: correct clock parents for mscl sysmmu
>   clk: exynos5420: update clocks for G2D block
>   clk: exynos5420: update clocks for DISP1 block
>   clk: exynos5420: update clocks for PERIC block
>   clk: exynos5420: update clocks for PERIS and GEN blocks
>   clk: exynos5420: update clocks for WCORE block
>   clk: exynos5420: update clocks for FSYS and FSYS2 blocks
>   clk: exynos5420: correct sysmmu-mfc parent clocks
>   clk: exynos5420: fix register offset for sclk_bpll
>   clk: exynos5420: cleanup core and misc clocks
>   clk: exynos5420: correct g3d parent clock
>   clk: exynos5420: create clock ID for mout_sclk_vpll
>   clk: exynos5420: add more registers to restore list
>
>  arch/arm/boot/dts/exynos5420.dtsi  |   14 +-
>  drivers/clk/samsung/clk-exynos5420.c   |  808 
> 
>  include/dt-bindings/clock/exynos5420.h |   33 +-
>  3 files changed, 550 insertions(+), 305 deletions(-)
>  mode change 100644 => 100755 drivers/clk/samsung/clk-exynos5420.c
>  mode change 100644 => 100755 include/dt-bindings/clock/exynos5420.h
>
> --
> 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: add generic function to calculate cpu number

2014-04-24 Thread Chander Kashyap
The address of cpu power registers in pmu is based on cpu number
offsets. This function calculate the same. This is essentially
required in case of multicluster SoC's e.g Exynos5420.

Signed-off-by: Chander Kashyap 
Signed-off-by: Chander Kashyap 
---
 arch/arm/mach-exynos/regs-pmu.h |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..217da2e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -313,4 +313,13 @@
 
 #define EXYNOS5_OPTION_USE_RETENTION   (1 << 4)
 
+#include 
+#define MAX_CPUS_IN_CLUSTER4
+
+static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
+{
+   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
+}
+
 #endif /* __ASM_ARCH_REGS_PMU_H */
-- 
1.7.9.5

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


Re: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
Hi,

On 04/25/2014 01:30 PM, Tushar Behera wrote:
> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
>> This patch fix the offset of CPU boot address and don't need to send smc call
>> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
>> WFE in secure mode.
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>>  arch/arm/mach-exynos/firmware.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/firmware.c 
>> b/arch/arm/mach-exynos/firmware.c
>> index aa01c42..386d01d 100644
>> --- a/arch/arm/mach-exynos/firmware.c
>> +++ b/arch/arm/mach-exynos/firmware.c
>> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
>>  static int exynos_cpu_boot(int cpu)
>>  {
>>  /*
>> + * Exynos3250 doesn't need to send smc command for secondary CPU boot
>> + * because Exynos3250 removes WFE in secure mode.
>> + */
>> +if (soc_is_exynos3250())
>> +return 0;
>> +/*
>>   * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>>   * But, Exynos4212 has only one secondary CPU so second parameter
>>   * isn't used for informing secure firmware about CPU id.
>>   */
>> -if (soc_is_exynos4212())
>> +else if (soc_is_exynos4212())
> 
> This changes is not required.

Do you mean it as following?

if (soc_is_exynos3250())
return 0

if (soc_is_exynos4212())
cpu = 0;

> 
>>  cpu = 0;
>>  
>>  exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
>> boot_addr)
>>  {
>>  void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>>  
>> -if (!soc_is_exynos4212())
>> +if (!soc_is_exynos4212() && !soc_is_exynos3250())
>>  boot_reg += 4*cpu;
>>  
>>  __raw_writel(boot_addr, boot_reg);
>>
> 
> 

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


Re: [PATCH v5] arm: exynos: generalize power register address calculation

2014-04-24 Thread Chander Kashyap
On 24 April 2014 13:18, Chander Kashyap  wrote:
> On 22 April 2014 17:55, Chander Kashyap  wrote:
>> Currently status/configuration power register values are hard-coded for cpu1.
>>
>> Make it generic so that it is useful for SoC's with more than two cpus.
>>
>> Signed-off-by: Chander Kashyap 
>> Signed-off-by: Chander Kashyap 
>> ---
>> changes in v5:
>> 1. Fix typo: enynos_pmu_cpunr -> exynos_pmu_cpunr
>> changes in v4:
>> 1: Dropped changes in platsmp.c and hotplug.c as those are taken 
>> care by
>>Tomasz Patches.
>> 2. Converted ENYNOS_PMU_CPUNR macro to static inline function
>> changes in v3:
>> 1. Move cpunr calculation to a macro
>> 2. Changed printk format specifier from unsigned hex to unsigned 
>> decimal
>> Changes in v2:
>> 1. Used existing macros for clusterid and cpuid calculation
>>
>>  arch/arm/mach-exynos/regs-pmu.h |   18 --
>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/regs-pmu.h 
>> b/arch/arm/mach-exynos/regs-pmu.h
>> index 4f6a256..f39e78c 100644
>> --- a/arch/arm/mach-exynos/regs-pmu.h
>> +++ b/arch/arm/mach-exynos/regs-pmu.h
>> @@ -105,8 +105,13 @@
>>  #define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
>>  #define S5P_GPS_ALIVE_LOWPWR   S5P_PMUREG(0x13A0)
>>
>> -#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
>> -#define S5P_ARM_CORE1_STATUS   S5P_PMUREG(0x2084)
>> +#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
>> +#define S5P_ARM_CORE0_STATUS   S5P_PMUREG(0x2004)
>> +
>> +#define S5P_ARM_CORE_CONFIGURATION(_cpunr) \
>> +   (S5P_ARM_CORE0_CONFIGURATION + 0x80 * (_cpunr))
>> +#define S5P_ARM_CORE_STATUS(_cpunr) \
>> +   (S5P_ARM_CORE0_STATUS + 0x80 * (_cpunr))
>>
>>  #define S5P_PAD_RET_MAUDIO_OPTION  S5P_PMUREG(0x3028)
>>  #define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
>> @@ -313,4 +318,13 @@
>>
>>  #define EXYNOS5_OPTION_USE_RETENTION   (1 << 4)
>>
>> +#include 
>> +#define MAX_CPUS_IN_CLUSTER4
>> +
>> +static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
>> +{
>> +   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
>> ++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
>> +}
>> +
>>  #endif /* __ASM_ARCH_REGS_PMU_H */
>> --
>> 1.7.9.5
>>
>
> Any other comment on this. If not can this be merged?

Please reject this patch as some of changes also done by Tomasz in his patches.
>
>
> --
> with warm regards,
> Chander Kashyap



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


Re: [PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables

2014-04-24 Thread Jungseok Lee
On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote:
> On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
> > This patch implements 4 levels of translation tables since 3 levels of
> > page tables with 4KB pages cannot support 40-bit physical address
> > space described in [1] due to the following issue.
> >
> > It is a restriction that kernel logical memory map with 4KB + 3 levels
> > (0xffc0-0x) cannot cover RAM region from
> > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
> > mapping for this region in map_mem function since __phys_to_virt for
> > this region reaches to address overflow.
> >
> > If SoC design follows the document, [1], over 32GB RAM would be placed
> > from 544GB. Even 64GB system is supposed to use the region from 544GB
> > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
> > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
> >
> > However, it is recommended 4 levels of page table should be only
> > enabled if memory map is too sparse or there is about 512GB RAM.
> 
> Hello Jungseok,
> A few comments can be found inline...

Hi Steve, The comments are very helpful. Thanks.

[ ... ]

> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index
> > 0fd5650..f313a7a 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -37,8 +37,8 @@
> >
> >  /*
> >   * swapper_pg_dir is the virtual address of the initial page table.
> > We place
> > - * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The
> > idmap_pg_dir has
> > - * 2 pages and is placed below swapper_pg_dir.
> > + * the page tables 4 * PAGE_SIZE below KERNEL_RAM_VADDR. The
> > + idmap_pg_dir has
> > + * 3 pages and is placed below swapper_pg_dir.
> >   */
> >  #define KERNEL_RAM_VADDR   (PAGE_OFFSET + TEXT_OFFSET)
> >
> > @@ -46,8 +46,8 @@
> >  #error KERNEL_RAM_VADDR must start at 0xXXX8  #endif
> >
> > -#define SWAPPER_DIR_SIZE   (3 * PAGE_SIZE)
> > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE)
> > +#define SWAPPER_DIR_SIZE   (4 * PAGE_SIZE)
> > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
> >
> > .globl  swapper_pg_dir
> > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE
> > @@ -371,16 +371,29 @@ ENDPROC(__calc_phys_offset)
> >
> >  /*
> >   * Macro to populate the PGD for the corresponding block entry in the
> > next
> > - * level (tbl) for the given virtual address.
> > + * levels (tbl1 and tbl2) for the given virtual address.
> >   *
> > - * Preserves:  pgd, tbl, virt
> > + * Preserves:  pgd, tbl1, tbl2, virt
> 
> tbl1 and tbl2 are *not* preserved for 4 level. tbl1 is bumped up one page to 
> make space for the pud,
> then fed into create_block_mapping later.

Your logic can be extended to 3 levels.
In an original code, tbl is fed into create_block_mapping.
That is why I've written them down as "preserves".

I will fix it in the next version.

> >   * Corrupts:   tmp1, tmp2
> >   */
> > -   .macro  create_pgd_entry, pgd, tbl, virt, tmp1, tmp2
> > +   .macro  create_pgd_entry, pgd, tbl1, tbl2, virt, tmp1, tmp2
> > lsr \tmp1, \virt, #PGDIR_SHIFT
> > and \tmp1, \tmp1, #PTRS_PER_PGD - 1 // PGD index
> > -   orr \tmp2, \tbl, #3 // PGD entry table type
> > +   orr \tmp2, \tbl1, #3// PGD entry table type
> > str \tmp2, [\pgd, \tmp1, lsl #3]
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > +   ldr \tbl2, =FIXADDR_TOP
> > +   cmp \tbl2, \virt
> 
> Do we need this extra logic? See my other comment below where the fixed 
> mapping is placed down.
> 
> > +   add \tbl2, \tbl1, #PAGE_SIZE
> > +   b.ne1f
> > +   add \tbl2, \tbl2, #PAGE_SIZE
> > +1:
> > +   lsr \tmp1, \virt, #PUD_SHIFT
> > +   and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index
> > +   orr \tmp2, \tbl2, #3// PUD entry table type
> > +   str \tmp2, [\tbl1, \tmp1, lsl #3]
> > +   mov \tbl1, \tbl2
> > +#endif
> 
> It may be easier to read to have a create_pud_entry macro too?

Okay. I will write a create_pud_entry macro.

> > .endm
> >
> >  /*
> > @@ -444,7 +457,7 @@ __create_page_tables:
> > add x0, x25, #PAGE_SIZE // section table address
> > ldr x3, =KERNEL_START
> > add x3, x3, x28 // __pa(KERNEL_START)
> > -   create_pgd_entry x25, x0, x3, x5, x6
> > +   create_pgd_entry x25, x0, x1, x3, x5, x6
> > ldr x6, =KERNEL_END
> > mov x5, x3  // __pa(KERNEL_START)
> > add x6, x6, x28 // __pa(KERNEL_END)
> > @@ -455,7 +468,7 @@ __create_page_tables:
> >  */
> > add x0, x26, #PAGE_SIZE // section table address
> > mov x5, #PAGE_OFFSET
> > -   create_pgd_entry x26, x0, x5, x3, x6
> > +   create_pgd_entry x26, x0, x1, x5, x3, x6
> > ldr x6, =KERNEL_END
> > mov x3, x24 // phys offset
> > 

Re: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Chanwoo Choi
On 04/25/2014 01:38 PM, Tushar Behera wrote:
> On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
>> From: Tomasz Figa 
>>
>> This patch add new exynos3250.dtsi to support Exynos3250 SoC based on 
>> Cortex-A7
>> dual core and includes following dt nodes:
>>
> 
> [ ... ]
> 
>> ---
>>  arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
>>  arch/arm/boot/dts/exynos3250.dtsi | 405 +
>>  arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 
>> ++
> 
> exynos4412-tizenw.dts related changes are unrelated.


Right, It is may mistake.
I'll resend this patch.

Thanks,
Chanwoo Choi

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


Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

2014-04-24 Thread Tushar Behera
On 04/24/2014 09:55 PM, Mark Brown wrote:
> On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote:
>> This patch moves initialization code to subsys_initcall() to ensure
>> that the i2c bus is available early so the regulators can be quickly
>> probed and available for other devices on their probe() call.
> 
>> Such solution has been proposed by Mark Brown to fix the problem of
>> the regulators not beeing available on the peripheral device probe():
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
> 
> What specifically is this needed for?  We *should* be able to use
> deferred probe for most things, but I know that not all subsystems are
> able to yet.
> 

DRM-Exynos is one such sub-system right now that doesn't handle deferred
probe well. That is one of the reasons for this patch.

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


Re: [PATCH v3 02/16] clk: exynos5420: add clocks for ISP block

2014-04-24 Thread Alim Akhtar
Hi Shaik,

On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
 wrote:
> This patch adds missing clocks for ISP block
>
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Shaik Ameer Basha 
> ---
>  drivers/clk/samsung/clk-exynos5420.c |   80 
> ++
>  1 file changed, 80 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 389d4b1..972da5d 100755
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -57,6 +57,7 @@
>  #define SRC_FSYS   0x10244
>  #define SRC_PERIC0 0x10250
>  #define SRC_PERIC1 0x10254
> +#define SRC_ISP0x10270
>  #define SRC_TOP10  0x10280
>  #define SRC_TOP11  0x10284
>  #define SRC_TOP12  0x10288
> @@ -77,12 +78,15 @@
>  #define DIV_PERIC2 0x10560
>  #define DIV_PERIC3 0x10564
>  #define DIV_PERIC4 0x10568
> +#define SCLK_DIV_ISP0  0x10580
> +#define SCLK_DIV_ISP1  0x10584
>  #define GATE_BUS_TOP   0x10700
>  #define GATE_BUS_FSYS0 0x10740
>  #define GATE_BUS_PERIC 0x10750
>  #define GATE_BUS_PERIC10x10754
>  #define GATE_BUS_PERIS00x10760
>  #define GATE_BUS_PERIS10x10764
> +#define GATE_TOP_SCLK_ISP  0x10870
>  #define GATE_IP_GSCL0  0x10910
>  #define GATE_IP_GSCL1  0x10920
>  #define GATE_IP_MFC0x1092c
> @@ -145,6 +149,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
> SRC_MASK_FSYS,
> SRC_MASK_PERIC0,
> SRC_MASK_PERIC1,
> +   SRC_ISP,
> DIV_TOP0,
> DIV_TOP1,
> DIV_TOP2,
> @@ -158,12 +163,15 @@ static unsigned long exynos5420_clk_regs[] __initdata = 
> {
> DIV_PERIC2,
> DIV_PERIC3,
> DIV_PERIC4,
> +   SCLK_DIV_ISP0,
> +   SCLK_DIV_ISP1,
> GATE_BUS_TOP,
> GATE_BUS_FSYS0,
> GATE_BUS_PERIC,
> GATE_BUS_PERIC1,
> GATE_BUS_PERIS0,
> GATE_BUS_PERIS1,
> +   GATE_TOP_SCLK_ISP,
> GATE_IP_GSCL0,
> GATE_IP_GSCL1,
> GATE_IP_MFC,
> @@ -250,6 +258,15 @@ PNAME(mout_user_aclk200_fsys_p)= {"fin_pll", 
> "mout_sw_aclk200_fsys"};
>
>  PNAME(mout_sw_aclk200_fsys2_p) = {"dout_aclk200_fsys2", "mout_sclk_spll"};
>  PNAME(mout_user_aclk200_fsys2_p) = {"fin_pll", "mout_sw_aclk200_fsys2"};
> +PNAME(mout_sw_aclk400_isp_p) = {"dout_aclk400_isp", "mout_sclk_spll"};
> +PNAME(mout_user_aclk400_isp_p) = {"fin_pll", "mout_sw_aclk400_isp"};
> +
> +PNAME(mout_sw_aclk333_432_isp0_p) = {"dout_aclk333_432_isp0",
> +   "mout_sclk_spll"};
> +PNAME(mout_user_aclk333_432_isp0_p) = {"fin_pll", 
> "mout_sw_aclk333_432_isp0"};
> +
> +PNAME(mout_sw_aclk333_432_isp_p) = {"dout_aclk333_432_isp", 
> "mout_sclk_spll"};
> +PNAME(mout_user_aclk333_432_isp_p) = {"fin_pll", "mout_sw_aclk333_432_isp"};
>
>  PNAME(mout_sw_aclk200_p) = {"dout_aclk200", "mout_sclk_spll"};
>  PNAME(mout_aclk200_disp1_p) = {"fin_pll", "mout_sw_aclk200"};
> @@ -265,6 +282,7 @@ PNAME(mout_user_aclk166_p) = {"fin_pll", 
> "mout_sw_aclk166"};
>
>  PNAME(mout_sw_aclk266_p) = {"dout_aclk266", "mout_sclk_spll"};
>  PNAME(mout_user_aclk266_p) = {"fin_pll", "mout_sw_aclk266"};
> +PNAME(mout_user_aclk266_isp_p) = {"fin_pll", "mout_sw_aclk266"};
>
>  PNAME(mout_sw_aclk333_432_gscl_p) = {"dout_aclk333_432_gscl", 
> "mout_sclk_spll"};
>  PNAME(mout_user_aclk333_432_gscl_p) = {"fin_pll", 
> "mout_sw_aclk333_432_gscl"};
> @@ -448,6 +466,31 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
> __initdata = {
> MUX(0, "mout_spi0", mout_group2_p, SRC_PERIC1, 20, 3),
> MUX(0, "mout_spi1", mout_group2_p, SRC_PERIC1, 24, 3),
> MUX(0, "mout_spi2", mout_group2_p, SRC_PERIC1, 28, 3),
> +   MUX(0, "mout_aclk400_isp", mout_group1_p, SRC_TOP0, 0, 2),
> +   MUX(0, "mout_sw_aclk400_isp", mout_sw_aclk400_isp_p,
> +   SRC_TOP10, 0, 1),
> +   MUX(0, "mout_user_aclk400_isp", mout_user_aclk400_isp_p,
> +   SRC_TOP3, 0, 1),
> +   MUX(0, "mout_aclk333_432_isp0", mout_group4_p, SRC_TOP1, 12, 2),
> +   MUX(0, "mout_sw_aclk333_432_isp0", mout_sw_aclk333_432_isp0_p,
> +   SRC_TOP11, 12, 1),
> +   MUX(0, "mout_user_aclk333_432_isp0", mout_user_aclk333_432_isp0_p,
> +   SRC_TOP4, 12, 1),
> +   MUX(0, "mout_aclk333_432_isp", mout_group4_p,
> +   SRC_TOP1, 4, 2),
> +   MUX(0, "mout_sw_aclk333_432_isp", mout_sw_aclk333_432_isp_p,
> +   SRC_TOP11, 4, 1),
> +   MUX(0, "mout_user_aclk333_432_isp", mout_user_aclk333_432_isp_p,
> +   SRC_TOP4, 4, 1),
> +   MUX(0, "mout_user_aclk266_isp", mout_user_aclk266_isp_p,
> +   SRC_TOP4, 16, 1),
> +
It is nice to sort then based on the same order as mentioned in there
register discription. Thats really halps in fast r

Re: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
> From: Tomasz Figa 
> 
> This patch add new exynos3250.dtsi to support Exynos3250 SoC based on 
> Cortex-A7
> dual core and includes following dt nodes:
> 

[ ... ]

> ---
>  arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
>  arch/arm/boot/dts/exynos3250.dtsi | 405 +
>  arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 
> ++

exynos4412-tizenw.dts related changes are unrelated.

-- 
Tushar Behera
--
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: [PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Tushar Behera
On 04/25/2014 06:46 AM, Chanwoo Choi wrote:
> This patch fix the offset of CPU boot address and don't need to send smc call
> of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
> WFE in secure mode.
> 
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 
> ---
>  arch/arm/mach-exynos/firmware.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index aa01c42..386d01d 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -31,11 +31,17 @@ static int exynos_do_idle(void)
>  static int exynos_cpu_boot(int cpu)
>  {
>   /*
> +  * Exynos3250 doesn't need to send smc command for secondary CPU boot
> +  * because Exynos3250 removes WFE in secure mode.
> +  */
> + if (soc_is_exynos3250())
> + return 0;
> + /*
>* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
>* But, Exynos4212 has only one secondary CPU so second parameter
>* isn't used for informing secure firmware about CPU id.
>*/
> - if (soc_is_exynos4212())
> + else if (soc_is_exynos4212())

This changes is not required.

>   cpu = 0;
>  
>   exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> @@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
> boot_addr)
>  {
>   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>  
> - if (!soc_is_exynos4212())
> + if (!soc_is_exynos4212() && !soc_is_exynos3250())
>   boot_reg += 4*cpu;
>  
>   __raw_writel(boot_addr, boot_reg);
> 


-- 
Tushar Behera
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board

2014-04-24 Thread Tushar Behera
On 04/24/2014 07:09 PM, Mark Brown wrote:
> On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:
> 
>> +Required properties:
>> +- compatible : Can be one of the following,
>> +"google,snow-audio-max98090" or
>> +"google,snow-audio-max98095"
>> +- samsung,i2s-controller: The phandle of the Samsung I2S0 controller
> 
> This should be any I2S controller, not just I2S0?
> 

Yes, right. It can be any I2S controller. Just that, right now it is
wired to I2S0.

>> +- samsung,audio-codec: The phandle of the audio codec
> 
> This binding only has one I2S controller and CODEC.  However...
> 
>> +static struct snd_soc_dai_link snow_dai[] = {
>> +{ /* Playback DAI i/f */
>> +.name = "Playback",
>> +.stream_name = "Playback",
>> +.codec_dai_name = "HiFi",
>> +.dai_fmt = SND_SOC_DAIFMT_I2S |
>> +SND_SOC_DAIFMT_NB_NF |
>> +SND_SOC_DAIFMT_CBS_CFS,
>> +}, { /* Capture DAI i/f */
>> +.name = "Capture",
>> +.stream_name = "Capture",
>> +.codec_dai_name = "HiFi",
>> +.dai_fmt = SND_SOC_DAIFMT_I2S |
>> +SND_SOC_DAIFMT_NB_NF |
>> +SND_SOC_DAIFMT_CBS_CFS,
>> +},
>> +};
> 
> ...for some reason we have separate capture and playback DAI links

That was lack of understanding from my side. I was of the impression
that the back-end uses different DAI interfaces for aplay and arecord,
which certainly is not the case. I will remove the 'Capture' dai and
make 'Playback' dai as the primary DAI.

> defined.  Why is that?  Also, why is the secondary I2S playback stream
> not supported (this may be a reason to restrict to only the one I2S
> interface)?

AFAICS, I2S driver doesn't support secondary DAI with DT (dai type is
always TYPE_PRI in case of DT). Hence I could not find a setup to test
secondary dai with this board.

> 
> Please also use subject lines consistent with the subsystem - NO NEED TO
> SHOUT.
> 

Noted, will take care.

Thanks.
-- 
Tushar Behera
--
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] ARM: dts: Add peach-pit board support

2014-04-24 Thread Arun Kumar K
Thanks Doug & Tushar for the Reviewed-by.

On Fri, Apr 25, 2014 at 12:27 AM, Doug Anderson  wrote:
> Arun,
>
> On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K  wrote:
>> Adds the google peach-pit board dts file which uses
>> exynos5420 SoC.
>>
>> Signed-off-by: Arun Kumar K 
>> Signed-off-by: Doug Anderson 
>> ---
>> Changes from v1
>> ---
>> - Addressed review comments from Doug, Sachin & Tushar
>> - Removed adc and lid-switch nodes
>> ---
>>  arch/arm/boot/dts/Makefile |1 +
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
>> 
>>  2 files changed, 183 insertions(+)
>> +   spi@12d3 {
>> +   status = "okay";
>> +   samsung,spi-src-clk = <0>;
>> +   num-cs = <1>;
>> +
>> +   spidev@0 {
>> +   compatible = "spidev";
>> +   reg = <0>;
>> +   spi-max-frequency = <5000>;
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <&spi_flash_cs>;
>> +
>> +   controller-data {
>> +   cs-gpio = <&gpa2 5 0>;
>
> Technically this could be
>
> cs-gpio = <&gpa2 5 GPIO_ACTIVE_HIGH>;
>
> ...but I don't think that's a huge deal...
>

Kukjin, please let me know if I need to re-send this or can you take
care while applying?

Regards
Arun

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


[RESEND PATCH 3/3] ARM: dts: fixed gpio key node for exynos4412

2014-04-24 Thread Beomho Seo
This patch fixed gpio key device node.
First, fix incorrect gpio property.
And then, add ok-key node where locate bottom center.
I have tested on exynos4412-trats2 board.

Signed-off-by: Beomho Seo 
Signed-off-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index c9f3c6e..cc96bee 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -87,18 +87,18 @@
compatible = "gpio-keys";

key-down {
-   interrupt-parent = <&gpj1>;
-   interrupts = <2 0>;
-   gpios = <&gpj1 2 1>;
+   interrupt-parent = <&gpx3>;
+   interrupts = <3 0>;
+   gpios = <&gpx3 3 1>;
linux,code = <114>;
label = "volume down";
debounce-interval = <10>;
};

key-up {
-   interrupt-parent = <&gpj1>;
-   interrupts = <1 0>;
-   gpios = <&gpj1 1 1>;
+   interrupt-parent = <&gpx2>;
+   interrupts = <2 0>;
+   gpios = <&gpx2 2 1>;
linux,code = <115>;
label = "volume up";
debounce-interval = <10>;
@@ -113,6 +113,16 @@
debounce-interval = <10>;
gpio-key,wakeup;
};
+
+   key-ok {
+   interrupt-parent = <&gpx0>;
+   interrupts = <1 0>;
+   gpios = <&gpx0 1 1>;
+   linux,code = <139>;
+   label = "ok";
+   debounce-inteval = <10>;
+   gpio-key,wakeup;
+   };
};

adc: adc@126C {
-- 
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


[RESEND PATCH 2/3] ARM: dts: add cm36651 light/proximity sensor node

2014-04-24 Thread Beomho Seo
Exynos4412-trats2 board have light/proximity sensor.
This patch add cm36651 light/ proximity sensor node for exynos4412.
cm36651 is required properties as below.
- Use i2c-gpio for cm36651 sensor.
- Use fixed regulator for the IR LED.
  It is a part of the cm36651 for proximity detection.
- cm36651 is i2c device driver so need to use i2c-gpio driver.

Signed-off-by: Beomho Seo 
Signed-off-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 42418e2..c9f3c6e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -21,6 +21,7 @@

aliases {
i2c8 = &i2c_ak8975;
+   i2c9 = &i2c_cm36651;
};

memory {
@@ -71,6 +72,14 @@
enable-active-high;
};

+   ps_als_reg: voltage-regulator-2 {
+   compatible = "regulator-fixed";
+   regulator-name = "LED_A_3.0V";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   gpio = <&gpj0 5 0>;
+   enable-active-high;
+   };
/* More to come */
};

@@ -500,6 +509,23 @@
};
};

+   i2c_cm36651: i2c-gpio-2 {
+   compatible = "i2c-gpio";
+   gpios = <&gpf0 0 0>, <&gpf0 1 0>;
+   i2c-gpio,delay-us = <2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   cm36651@18 {
+   compatible = "cm36651";
+   reg = <0x18>;
+   interrupt-parent = <&gpx0>;
+   interrupts = <2 0>;
+   vled-supply = <&ps_als_reg>;
+   };
+   };
+
spi_1: spi@1393 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_bus>;
-- 
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


[PATCHv2] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Chanho Park
This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.

Cc: Chanwoo Choi 
Cc: Tomasz Figa 
Signed-off-by: Chanho Park 
---
Changes from v1:
 - Remove duplicated properties in exynos4412.dtsi(Comment from Tomasz Figa)

 arch/arm/boot/dts/exynos4.dtsi| 6 ++
 arch/arm/boot/dts/exynos4210.dtsi | 6 --
 arch/arm/boot/dts/exynos4412.dtsi | 4 
 arch/arm/boot/dts/exynos4x12.dtsi | 6 --
 4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0401f4d..b43dc24 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = <0x1044 0x1000>;
};
 
+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupt-parent = <&combiner>;
+   interrupts = <2 2>, <3 2>;
+   };
+
sys_reg: syscon@1001 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x1001 0x400>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cb0e768d..e19c154 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = <1>;
};
 
-   pmu {
-   compatible = "arm,cortex-a9-pmu";
-   interrupt-parent = <&combiner>;
-   interrupts = <2 2>, <3 2>;
-   };
-
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4210-pinctrl";
reg = <0x1140 0x1000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index a40b6e2..7b75762 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,10 @@
samsung,combiner-nr = <20>;
};
 
+   pmu {
+   interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
+   };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x4000>;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306..b730a74 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,12 +31,6 @@
mshc0 = &mshc_0;
};
 
-   pmu {
-   compatible = "arm,cortex-a9-pmu";
-   interrupt-parent = <&combiner>;
-   interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
-   };
-
pd_isp: isp-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
-- 
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


[RESEND PATCH 1/3] ARM: dts: fix incorrect compatible for exynos4412

2014-04-24 Thread Beomho Seo
This patch fixed incorrect compatible for ak8975 magnetic sensor.
ak8975 magnetic sensor use compatible "ak8975" or "asahi-kasei,ak8975".

Signed-off-by: Beomho Seo 
Signed-off-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 3228506..42418e2 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -494,7 +494,7 @@
status = "okay";

ak8975@0c {
-   compatible = "ak,ak8975";
+   compatible = "ak8975";
reg = <0x0c>;
gpios = <&gpj0 7 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


[RESEND PATCH 0/3] ARM: dts: add device data for exynos4412-trats2

2014-04-24 Thread Beomho Seo
This patchset add some device node for exynos4412-trats2.
It is based on v3.15-next/dt-samsung-2 branch.

exynos4412-trats2.dts
- Fix incorrect compatible. Compatible of AK8975 are "ak8975" or 
"asahi-kasei,ak8975".
- Add cm36651 light/proximity sensor device node.
- Change gpio-key device node. fix incorrect gpio property, and then add 
"ok-key" node.

Beomho Seo (3):
  ARM: dts: fix incorrect compatible for exynos4412
  ARM: dts: add cm36651 light/proximity sensor node
  ARM: dts: fixed gpio key node for exynos4412

 arch/arm/boot/dts/exynos4412-trats2.dts |   50 ++-
 1 file changed, 43 insertions(+), 7 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


RE: [PATCH] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Chanho Park
Hi Tomasz,

> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Tomasz Figa
> Sent: Friday, April 25, 2014 2:04 AM
> To: Chanho Park; kgene@samsung.com; linux-samsung-
> s...@vger.kernel.org
> Cc: Chanwoo Choi; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] ARM: dts: exynos4: clean up arm-pmu node
> 
> Hi Chanho,
> 
> On 14.04.2014 15:03, Chanho Park wrote:
> > This patch cleans a arm-pmu node up for exynos4. Only exynos4412
> series
> > boards have four pmu interrupts. Rest of exynos4 boards, except 4412,
> have only
> > two pmu interrupts. Thus, we can define two interrupts in the
> > exynos4.dtsi and extends the interrupts only exynos4412.dtsi.
> >
> > Cc: Chanwoo Choi 
> > Signed-off-by: Chanho Park 
> > ---
> >   arch/arm/boot/dts/exynos4.dtsi| 6 ++
> >   arch/arm/boot/dts/exynos4210.dtsi | 6 --
> >   arch/arm/boot/dts/exynos4412.dtsi | 6 ++
> >   arch/arm/boot/dts/exynos4x12.dtsi | 6 --
> >   4 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos4.dtsi
> b/arch/arm/boot/dts/exynos4.dtsi
> > index e541ecb..6de978c 100644
> > --- a/arch/arm/boot/dts/exynos4.dtsi
> > +++ b/arch/arm/boot/dts/exynos4.dtsi
> > @@ -105,6 +105,12 @@
> > reg = <0x1044 0x1000>;
> > };
> >
> > +   pmu {
> > +   compatible = "arm,cortex-a9-pmu";
> > +   interrupt-parent = <&combiner>;
> > +   interrupts = <2 2>, <3 2>;
> > +   };
> > +
> > sys_reg: syscon@1001 {
> > compatible = "samsung,exynos4-sysreg", "syscon";
> > reg = <0x1001 0x400>;
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi
> > index cacf614..4e7610f 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -75,12 +75,6 @@
> > #clock-cells = <1>;
> > };
> >
> > -   pmu {
> > -   compatible = "arm,cortex-a9-pmu";
> > -   interrupt-parent = <&combiner>;
> > -   interrupts = <2 2>, <3 2>;
> > -   };
> > -
> > pinctrl_0: pinctrl@1140 {
> > compatible = "samsung,exynos4210-pinctrl";
> > reg = <0x1140 0x1000>;
> > diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> > index 15d3c0a..e6af870 100644
> > --- a/arch/arm/boot/dts/exynos4412.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412.dtsi
> > @@ -26,6 +26,12 @@
> > samsung,combiner-nr = <20>;
> > };
> >
> > +   pmu {
> > +   compatible = "arm,cortex-a9-pmu";
> > +   interrupt-parent = <&combiner>;
> 
> I guess you could omit the two properties above and let them be
> inherited from exynos4.dtsi.

Yes. It can be omitted in the exynos4412.dtsi. Thank you for your review.
I'll send V2 Patch.

Best Regards,
Chanho Park

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


[PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

2014-04-24 Thread Chanwoo Choi
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.

Cc: Arnd Bergmann 
Cc: Marc Zynigier 
Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/hotplug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
 
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
 */
-   asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
-   if ((primary_part & 0xfff0) == 0xc0f0)
+   primary_part = read_cpuid_part_number();
+
+   switch (primary_part) {
+   case ARM_CPU_PART_CORTEX_A7:
+   case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-   else
+   break;
+   default:
cpu_enter_lowpower_a9();
+   break;
+   }
 
platform_do_lowpower(cpu, &spurious);
 
-- 
1.8.0

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


[PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework

2014-04-24 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7
using common clock framework. The CMU (Clock Management Unit) of Exynos3250
control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses,
and function clocks for individual IPs.

The CMU of Exynos3250 includes following clock doamins:
- CPU block for Cortex-A7 MPCore processor
- LEFTBUS/RIGHTBUS block
- TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Inki Dae 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Karol Wrona 
Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d120797 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
+obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
new file mode 100644
index 000..0574a76
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos3250 SoC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+#include "clk-pll.h"
+
+#define SRC_LEFTBUS0x4200
+#define DIV_LEFTBUS0x4500
+#define GATE_IP_LEFTBUS0x4800
+#define SRC_RIGHTBUS   0x8200
+#define DIV_RIGHTBUS   0x8500
+#define GATE_IP_RIGHTBUS   0x8800
+#define GATE_IP_PERIR  0x8960
+#define MPLL_LOCK  0xc010
+#define MPLL_CON0  0xc110
+#define VPLL_LOCK  0xc020
+#define VPLL_CON0  0xc120
+#define UPLL_LOCK  0xc030
+#define UPLL_CON0  0xc130
+#define SRC_TOP0   0xc210
+#define SRC_TOP1   0xc214
+#define SRC_CAM0xc220
+#define SRC_MFC0xc228
+#define SRC_G3D0xc22c
+#define SRC_LCD0xc234
+#define SRC_ISP0xc238
+#define SRC_FSYS   0xc240
+#define SRC_PERIL0 0xc250
+#define SRC_PERIL1 0xc254
+#define SRC_MASK_TOP   0xc310
+#define SRC_MASK_CAM   0xc320
+#define SRC_MASK_LCD   0xc334
+#define SRC_MASK_ISP   0xc338
+#define SRC_MASK_FSYS  0xc340
+#define SRC_MASK_PERIL00xc350
+#define SRC_MASK_PERIL10xc354
+#define DIV_TOP0xc510
+#define DIV_CAM0xc520
+#define DIV_MFC0xc528
+#define DIV_G3D0xc52c
+#define DIV_LCD0xc534
+#define DIV_ISP0xc538
+#define DIV_FSYS0  0xc540
+#define DIV_FSYS1  0xc544
+#define DIV_FSYS2  0xc548
+#define DIV_PERIL0 0xc550
+#define DIV_PERIL1 0xc554
+#define DIV_PERIL3 0xc55c
+#define DIV_PERIL4 0xc560
+#define DIV_PERIL5 0xc564
+#define DIV_CAM1   0xc568
+#define CLKDIV2_RATIO  0xc580
+#define GATE_SCLK_CAM  0xc820
+#define GATE_SCLK_MFC  0xc828
+#define GATE_SCLK_G3D  0xc82c
+#define GATE_SCLK_LCD  0xc834
+#define GATE_SCLK_ISP_TOP  0xc838
+#define GATE_SCLK_FSYS 0xc840
+#define GATE_SCLK_PERIL0xc850
+#define GATE_IP_CAM0xc920
+#define GATE_IP_MFC0xc928
+#define GATE_IP_G3D0xc92c
+#define GATE_IP_LCD0xc934
+#define GATE_IP_ISP0xc938
+#define GATE_IP_FSYS   0xc940
+#define GATE_IP_PERIL  0xc950
+#define GATE_BLOCK 0xc970
+#define APLL_LOCK  0x14000
+#define APLL_CON0  0x14100
+#define SRC_CPU0x14200
+#define DIV_CPU0   0x14

[PATCHv4 6/7] dt-bindings: add documentation for Exynos3250 clock controller

2014-04-24 Thread Chanwoo Choi
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.

Cc: Mike Turquette 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Randy Dunlap 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Tomasz Figa 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+   cmu: clock-controller@1003 {
+   compatible = "samsung,exynos3250-cmu";
+   reg = <0x1003 0x2>;
+   #clock-cells = <1>;
+   };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@1380 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x1380 0x100>;
+   interrupts = <0 109 0>;
+   clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>;
+   clock-names = "uart", "clk_uart_baud0";
+   };
-- 
1.8.0

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


[PATCHv4 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID

2014-04-24 Thread Chanwoo Choi
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/Kconfig | 22 ++
 arch/arm/mach-exynos/exynos.c|  2 ++
 arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
 
 menu "SAMSUNG EXYNOS SoCs Support"
 
+config ARCH_EXYNOS3
+   bool "SAMSUNG EXYNOS3"
+   select ARM_AMBA
+   select CLKSRC_OF
+   select HAVE_ARM_SCU if SMP
+   select HAVE_SMP
+   select PINCTRL
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Samsung EXYNOS3 SoCs based systems
+
 config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
 
 comment "EXYNOS SoCs"
 
+config SOC_EXYNOS3250
+   bool "SAMSUNG EXYNOS3250"
+   default y
+   depends on ARCH_EXYNOS3
+   select ARCH_HAS_BANDGAP
+   select ARM_CPU_SUSPEND if PM
+   select PINCTRL_EXYNOS
+   select SAMSUNG_DMADEV
+   help
+ Enable EXYNOS3250 CPU support
+
 config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a5fe18..e7dc6fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -346,6 +346,8 @@ static void __init exynos_dt_machine_init(void)
 }
 
 static char const *exynos_dt_compat[] __initconst = {
+   "samsung,exynos3",
+   "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h 
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
 #define S5PV210_CPU_ID 0x4311
 #define S5PV210_CPU_MASK   0xF000
 
+#define EXYNOS3250_SOC_ID   0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
 #define EXYNOS4210_CPU_ID  0x4321
 #define EXYNOS4212_CPU_ID  0x4322
 #define EXYNOS4412_CPU_ID  0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
 IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
 IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
 IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
 IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, 
EXYNOS5_SOC_MASK)
 # define soc_is_s5pv210()  0
 #endif
 
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
 #if defined(CONFIG_CPU_EXYNOS4210)
 # define soc_is_exynos4210()   is_samsung_exynos4210()
 #else
-- 
1.8.0

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


[PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250

2014-04-24 Thread Chanwoo Choi
From: Tomasz Figa 

This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:

- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus

Signed-off-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Kyungmin Park 
Signed-off-by: Inki Dae 
Signed-off-by: Hyunhee Kim 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
 arch/arm/boot/dts/exynos3250.dtsi | 405 +
 arch/arm/boot/dts/exynos4212-tizenw.dts   | 926 ++
 3 files changed, 1808 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as 
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+   pinctrl@1140 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpb: gpb {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   uart0_data: uart0-data {
+   samsung,pins = "gpa0-0", "gpa0-1";
+   samsung,pin-function = <0x2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart0_fctl: uart0-fctl {
+   samsung,pins = "gpa0-2", "gpa0-3";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_data: uart1-data {
+   samsung,pins = "gpa0-4", "gpa0-5";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   uart1_fctl: uart1-fctl {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   i2c2_bus: i2c2-bus {
+   samsung,pins = "gpa0-6", "gpa0-7";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+
+  

[PATCHv4 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212

2014-04-24 Thread Chanwoo Choi
From: Kyungmin Park 

This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.

Signed-off-by: Kyungmin Park 
Signed-off-by: Chanwoo Choi 
---
 arch/arm/mach-exynos/firmware.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
 
 #include 
 
+#include 
+
 #include "smc.h"
 
 static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+   if (soc_is_exynos4212())
+   cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
 }
 
 static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+   if (!soc_is_exynos4212())
+   boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
return 0;
-- 
1.8.0

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


[PATCHv4 3/7] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-24 Thread Chanwoo Choi
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/mach-exynos/firmware.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..386d01d 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -31,11 +31,17 @@ static int exynos_do_idle(void)
 static int exynos_cpu_boot(int cpu)
 {
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+   if (soc_is_exynos3250())
+   return 0;
+   /*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
-   if (soc_is_exynos4212())
+   else if (soc_is_exynos4212())
cpu = 0;
 
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -46,7 +52,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
 {
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
 
-   if (!soc_is_exynos4212())
+   if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
-- 
1.8.0

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


[PATCHv4 0/7] Support new Exynos3250 SoC based on Cortex-A7 dual core

2014-04-24 Thread Chanwoo Choi
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core.
Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor
for Smartphone. It is desigend with the 28nm low-power high-K metal gate process
and provides the best performance features.

This patchset include some patches such as:
- Support booting of Exynos3250
- Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba
- Support the clock control for Exynos3250 using common clk framework

[Pinctrl patch for Exynos3250]
The pinctrl patch for Exynos3250 has been merged in pinctrl.git of Linus Walleij
- [1] https://lkml.org/lkml/2014/4/23/72

This patchset is based on following git repo/branch.
- git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
- branch   : for-next (Linux 3.15-rc1)

Changes from v3:
- Remove all dependency about following patchset to remove static memory
  mapping for SYSRAM[1] / PMU ([2] or [3]). If following patchset merged,
  I'll send a further patches to support SYSRAM/PMU for secondary CPU.
 [1] http://www.spinics.net/lists/arm-kernel/msg323011.html
 [2] https://lkml.org/lkml/2014/4/2/48
 [3] http://www.spinics.net/lists/arm-kernel/msg316013.html

Changes from v2:
- Remove static memory mapping about SYSRAM/PMU such as following patches:
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
- Add description for secondary CPU boot of Exynos4212/Exynos3250
- Fix description in exynos_cpu_die() to remove particular SoC series
- Fix minor coding style
- Add documentation for Exynos3250 clock controller

Changes from v1:
- Add new "samsung,exynos3" compatible name
- Add comment about exynos_cpu_boot in Exynos4212
- Remove unnecessary 'goto' statement in firmware.c
- Use read_cpuid_part_number() function instead of assembler directly
- Post separated pinctrl patch from this patchset
  : https://lkml.org/lkml/2014/4/13/156
- Remove unused pmu interrupts due to Exynos3250 dual-core
- Cosolidate all the patches related to exynos3250.dtsi into one patch
- Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same
- Add sign-off of sender to all this patches
- Fix minor typo

Chanwoo Choi (4):
  ARM: EXYNOS: Add Exynos3250 SoC ID
  ARM: EXYNOS: Support secondary CPU boot of Exynos3250
  ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
  dt-bindings: add documentation for Exynos3250 clock controller

Kyungmin Park (1):
  ARM: EXYNOS: Support secondary CPU boot of Exynos4212

Tomasz Figa (2):
  clk: samsung: exynos3250: Add clocks using common clock framework
  ARM: dts: Add device tree sources for Exynos3250

 .../devicetree/bindings/clock/exynos3250-clock.txt |  41 +
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi  | 477 +++
 arch/arm/boot/dts/exynos3250.dtsi  | 405 +
 arch/arm/boot/dts/exynos4212-tizenw.dts| 926 +
 arch/arm/mach-exynos/Kconfig   |  22 +
 arch/arm/mach-exynos/exynos.c  |   2 +
 arch/arm/mach-exynos/firmware.c|  21 +-
 arch/arm/mach-exynos/hotplug.c |  19 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |  10 +
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 ++
 12 files changed, 2957 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

-- 
1.8.0

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


Re: [PATCH v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC

2014-04-24 Thread Rahul Sharma
Hi Kukjin,

Need this macro to enable build for clock driver.

Regards,
Rahul Sharma.


On 22 April 2014 15:36, Kukjin Kim  wrote:
> Tomasz Figa wrote:
>>
>> On 16.04.2014 10:08, Sachin Kamat wrote:
>> > Hi Tomasz,
>> >
>> > On 16 April 2014 13:27, Tomasz Figa  wrote:
>> >> Hi Rahul,
>> >>
>> >>
>> >> On 16.04.2014 05:58, Rahul Sharma wrote:
>> >>>
>> >>> From: Pankaj Dubey 
>> >>>
>> >>> This patch add basic arch side support for exynos5260 SoC.
>> >>>
>> >>> Signed-off-by: Pankaj Dubey 
>> >>> Signed-off-by: Rahul Sharma 
>> >>> Reviewed-by: Tomasz Figa 
>> >>> ---
>> >>>arch/arm/mach-exynos/Kconfig |5 +
>> >>>1 file changed, 5 insertions(+)
>> >>>
>> >>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
>> exynos/Kconfig
>> >>> index fc8bf18..bf4ed87 100644
>> >>> --- a/arch/arm/mach-exynos/Kconfig
>> >>> +++ b/arch/arm/mach-exynos/Kconfig
>> >>> @@ -84,6 +84,11 @@ config SOC_EXYNOS5250
>> >>>  help
>> >>>Enable EXYNOS5250 SoC support
>> >>>
>> >>> +config SOC_EXYNOS5260
>> >>> +   bool "SAMSUNG EXYNOS5260"
>> >>> +   default y
>> >>> +   depends on ARCH_EXYNOS5
>> >>> +
>> >>>config SOC_EXYNOS5420
>> >>>  bool "SAMSUNG EXYNOS5420"
>> >>>  default y
>> >>>
>> >>
>> >> Is this patch necessary now? After Sachin's consolidation series there
>> are
>> >> no per SoC entries anymore.
>> >
>> > Kukjin still wanted individual SoCs to be selectable. Please refer [1].
>> >
>> > [1] http://www.spinics.net/lists/devicetree/msg27040.html
>>
>> I don't think any valid reason was presented there. Features in code
>> should not be selected using #ifdef CONFIG_ anymore, so I don't really
>> see any reason to not proceed with this consolidation. Olof, Arnd?
>>
> Hi,
>
> Yeah, in this case, nothing happened with adding SOC_EXYNOS5260. So I don't 
> have any idea why this is required.
>
> - 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 v2] ARM: dts: Add peach-pit board support

2014-04-24 Thread Doug Anderson
Arun,

On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K  wrote:
> Adds the google peach-pit board dts file which uses
> exynos5420 SoC.
>
> Signed-off-by: Arun Kumar K 
> Signed-off-by: Doug Anderson 
> ---
> Changes from v1
> ---
> - Addressed review comments from Doug, Sachin & Tushar
> - Removed adc and lid-switch nodes
> ---
>  arch/arm/boot/dts/Makefile |1 +
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |  182 
> 
>  2 files changed, 183 insertions(+)
> +   spi@12d3 {
> +   status = "okay";
> +   samsung,spi-src-clk = <0>;
> +   num-cs = <1>;
> +
> +   spidev@0 {
> +   compatible = "spidev";
> +   reg = <0>;
> +   spi-max-frequency = <5000>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&spi_flash_cs>;
> +
> +   controller-data {
> +   cs-gpio = <&gpa2 5 0>;

Technically this could be

cs-gpio = <&gpa2 5 GPIO_ACTIVE_HIGH>;

...but I don't think that's a huge deal...

Reviewed-by: Doug Anderson 
--
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/9] drm/panel: add pre_enable and post_disable routines

2014-04-24 Thread Thierry Reding
On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote:
> Thierry,
> 
> On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding
>  wrote:
> > On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote:
[...]
> >> Imo this makes sense, especially if we go through with the idea talked
> >> about yesterday of creating a drm_bridge to wrap-up a drm_panel with
> >> sufficient isolation between all components.
> >
> > I'm not at all comfortable with these. The names are totally confusing.
> > Next somebody will need to do something after the panel has been enabled
> > and we'll have to introduce .post_enable() and .pre_disable() functions.
> > And worse, what if somebody needs something to be done between
> > .pre_enable() and .enable()? .post_pre_enable()? Where does it end?
> >
> > According to the above description the only reason why we need this is
> > to avoid visible glitches when the panel is already on, but the video
> > stream hasn't started yet. If that's the only reason why we need this,
> > then perhaps adding a way for a panel to expose the associated backlight
> > would be better?
> Actually, we need not expose the entire backlight device.
> AFAIK, the glitch is caused when you enable BL_EN before
> there is valid video data. So, one way to mask off the glitch is to
> follow this sequence:
> -- power up the panel.
> -- start video data, (start PWM here or)
> -- (start PWM here), enable backlight

That's very difficult to get right, isn't it? Even if you have fine-
grained control over what to enable you still need a way to determine
_when_ it's safe to enable the backlight. Typically I guess that would
be the duration of one frame (or perhaps 2, depending on when the panel
syncs to the video signal).

Perhaps it could even by sync'ed to the VBLANK?

> The problem is that the above scenario cannot be mapped to panel-simple 
> driver.
> IMO, panel_simple should provide enable/disable controls both for LCD
> and backlight.
> something like panel_simple_lcd_enable/panel_simple_led_enable, and
> panel_simple_lcd_disable/panel_simple_led_disable.

That's not what the simple panel driver can do. If we want this it needs
to be solved in a generic way for all panels since they all need to use
the drm_panel_*() functions to abstract away the details from drivers
that use the panels.

Thierry


pgpCcImfBpebT.pgp
Description: PGP signature


Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support

2014-04-24 Thread Bjorn Helgaas
On Fri, Mar 28, 2014 at 05:52:51PM +0100, Lucas Stach wrote:
> While working on MSI support for the i.MX6 PCIe host driver
> it has been discovered that the binding for this host controller
> is broken in many ways (refer to the patch descriptions for more
> info) and was introduced without proper discussion about what
> should/should not be in the binding.
> 
> This series fixes this and minimizes the difference of the
> i.MX6 binding to the common designware PCIe binding. I'm aware
> that this is a quite radical change, but I think it's justified
> to do this as long as there aren't many user of the old binding
> (most of the optional properties in the binding aren't even
> implemented).
> 
> Looking forward to your feedback.
> 
> Lucas Stach (8):
>   ARM: imx6q-clk: parent lvds_gate from lvds_sel
>   PCI: designware: split Exynos and i.MX bindings
>   ARM: dts: imx6: update pcie to bring in line with new binding
>   PCI: imx6: use new clock names
>   PCI: imx6: drop old irq mapping
>   PCI: imx6: rip out optional (and unused) irqs
>   PCI: designware: make MSI isr shared irq aware
>   PCI: imx6: add support for MSI

What's the status of all these?  I would normally apply patches 4-8 of this
series through my tree, given the appropriate acks, but I haven't seen
those yet.  And I'm not sure what dependencies there are between the
non-PCI patches and the PCI ones.

Bjorn
--
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] Exynos4: cpuidle: support dual CPUs with AFTR state

2014-04-24 Thread Tomasz Figa

Hi Daniel,

Please see my comments inline.

Btw. Please fix your e-mail composer to properly wrap your messages 
around 7xth column, as otherwise they're hard to read.


On 04.04.2014 11:48, Daniel Lezcano wrote:

The following driver is for exynos4210. I did not yet finished the other 
boards, so
I created a specific driver for 4210 which could be merged later.

The driver is based on Colin Cross's driver found at:

https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/

This one was based on a 3.4 kernel and an old API.

It has been refreshed, simplified and based on the recent code cleanup I sent
today.

The AFTR could be entered when all the cpus (except cpu0) are down. In order to
reach this situation, the couple idle states are used.

There is a sync barrier at the entry and the exit of the low power function. So
all cpus will enter and exit the function at the same time.

At this point, CPU0 knows the other cpu will power down itself. CPU0 waits for
the CPU1 to be powered down and then initiate the AFTR power down sequence.

No interrupts are handled by CPU1, this is why we switch to the timer broadcast
even if the local timer is not impacted by the idle state.

When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then they both
exit the idle function.

This driver allows the exynos4210 to have the same power consumption at idle
time than the one when we have to unplug CPU1 in order to let CPU0 to reach
the AFTR state.

This patch is a RFC because, we have to find a way to remove the macros
definitions and cpu powerdown function without pulling the arch dependent
headers.

Signed-off-by: Daniel Lezcano 
---
  arch/arm/mach-exynos/common.c|   11 +-
  drivers/cpuidle/Kconfig.arm  |8 ++
  drivers/cpuidle/Makefile |1 +
  drivers/cpuidle/cpuidle-exynos4210.c |  226 ++
  4 files changed, 245 insertions(+), 1 deletion(-)
  create mode 100644 drivers/cpuidle/cpuidle-exynos4210.c

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
  };

+static struct platform_device exynos4210_cpuidle = {
+   .name  = "exynos4210-cpuidle",
+   .dev.platform_data = exynos_sys_powerdown_aftr,
+   .id= -1,
+};
+
  void __init exynos_cpuidle_init(void)
  {
-   platform_device_register(&exynos_cpuidle);
+   if (soc_is_exynos4210())
+   platform_device_register(&exynos4210_cpuidle);
+   else
+   platform_device_register(&exynos_cpuidle);
  }

  void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
  Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+   bool "Cpu Idle Driver for the Exynos 4210 processor"
+   default y
+   depends on ARCH_EXYNOS
+   select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+   help
+ Select this to enable cpuidle for the Exynos 4210 processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+= 
cpuidle-zynq.o
  obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
  obj-$(CONFIG_ARM_AT91_CPUIDLE)  += cpuidle-at91.o
  obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUIDLE)+= cpuidle-exynos4210.o

  
###
  # POWERPC drivers
diff --git a/drivers/cpuidle/cpuidle-exynos4210.c 
b/drivers/cpuidle/cpuidle-exynos4210.c
new file mode 100644
index 000..56f6d51
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-exynos4210.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Copyright (c) 2014 Linaro : Daniel Lezcano 
+ * http://www.linaro.org
+ *
+ * Based on the work of Colin Cross 
+ *
+ * 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 


This won't work with multiplatform.


+
+static atomic_t exynos_idle_barrier;
+static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
+
+#define BOOT_VECTOR S5P_VA_SYSRAM
+#define S5P_VA_PMU  S3C_ADDR(0x021800

Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
On Thu, Apr 24, 2014 at 10:55 PM, Rob Clark  wrote:
> On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar  wrote:
>> Rob,
>>
>> On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark  wrote:
>>> On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
 Sorry for the previous reply,

 Here goes the full explaination:

> Rob,
>
> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
>> So what about, rather than adding drm_panel support to each bridge
>> individually, we introduce a drm_panel_bridge (with a form of
>> chaining).. ie:
>>
>>   struct drm_panel_bridge {
>> struct drm_bridge base;
>> struct drm_panel *panel;
>> struct drm_bridge *bridge; /* optional */
>>   };
>>
>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>   {
>> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
>> if (pb->bridge)
>>   pb->bridge->funcs->enable(pb->bridge);
>> pb->panel->funcs->enable(pb->panel);
>>   }
>>
 We cannot call them like this from crtc helpers in the order you mentioned,
 since each individual bridge chip expects the panel controls at
 different places.
 I mean,
 -- sometimes panel controls needs to be done before bridge
 controls(ptn3460: before RST_N and PD_N)
>>>
>>> well, this is why bridge has pre-enable/enable/disable/post-disable
>>> hooks, so you can choose before or after..
>> These calls are for a bridge to sync with the encoder calls.
>> We might end up defining pre-enable/enable/disable/post-disable for a
>> panel to sync
>> with the bridge calls! I have explained below.
>>
 -- sometimes in between the bridge controls (ps8622: one panel control
 before SLP_N and one after SLP_N)
 -- sometimes panel controls needs to be done after bridge controls.
>>>
>>> I am not convinced that a generic panel/bridge adapter is not
>>> possible.  Maybe we need more fine grained fxn ptr callbacks, although
>>> seems like pre+post should give you enough.  It would certainly be
>>> easier than having to add panel support in each individual bridge
>>> driver (which seems like it will certainly result that only certain
>>> combinations of panel+bridge actually work as intended)
>> Ok. Consider this case:
>> Currently, we have the sequence as "bridge->pre_enable,
>> encoder_enable, bridge->enable"
>> And, the bridge should obviously be enabled in bridge->pre_enable.
>> Now, where do you choose to call panel->pre_enable?
>> -- as the first step of bridge->pre_enable, before we pull up/down bridge 
>> GPIOs.
>> -- at the last step of bridge->pre_enable, after we pull up/down the
>> bridge GPIOs.
>>
>> Ideally, PTN3460 expects it to be the second case, and PS8625 expects
>> it to be the first case.
>> So, we will end up adding pre_pre_enable, post_pre_enable to
>> accomodate such scenarios.
>
> ok, well I think we can deal with this with a slight modification of
> my original proposal.  Split drm_panel_bridge into
> drm_composite_bridge and drm_panel_bridge:
>
>   struct drm_composite_bridge {
> struct drm_bridge base;
> struct drm_bridge *b1, *b2;
>   }
>
>   static void drm_composite_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
> cbridge->b1->funcs->enable(cbridge->b1);
> cbridge->b2->funcs->enable(cbridge->b2);
>   }
>
>   .. and so on ..
>
>   struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel *panel;
>   }
>
>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
> pbridge->panel->funcs->enable(pbridge->panel);
>   }
>
>   .. and so on..
>
>
> then in initialization, order can be managed like:
>
>   if (panel_first)
> bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
>   else
> bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);
>
>   possibly parametrize drm_panel_bridge if we need to map
> panel->enable() to bridge->pre_enable() vs bridge->enable(), etc..

Well, this really does seems complex to me.
Don't you think just having a drm_panel inside drm_bridge structure is
sufficient?!
And, make a call for pre_panel_enable and post_panel_enable around
bridge->pre_enable..and so on.?
--
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 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Rob Clark
On Thu, Apr 24, 2014 at 12:55 PM, Ajay kumar  wrote:
> Rob,
>
> On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark  wrote:
>> On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
>>> Sorry for the previous reply,
>>>
>>> Here goes the full explaination:
>>>
 Rob,

 On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
> So what about, rather than adding drm_panel support to each bridge
> individually, we introduce a drm_panel_bridge (with a form of
> chaining).. ie:
>
>   struct drm_panel_bridge {
> struct drm_bridge base;
> struct drm_panel *panel;
> struct drm_bridge *bridge; /* optional */
>   };
>
>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>   {
> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
> if (pb->bridge)
>   pb->bridge->funcs->enable(pb->bridge);
> pb->panel->funcs->enable(pb->panel);
>   }
>
>>> We cannot call them like this from crtc helpers in the order you mentioned,
>>> since each individual bridge chip expects the panel controls at
>>> different places.
>>> I mean,
>>> -- sometimes panel controls needs to be done before bridge
>>> controls(ptn3460: before RST_N and PD_N)
>>
>> well, this is why bridge has pre-enable/enable/disable/post-disable
>> hooks, so you can choose before or after..
> These calls are for a bridge to sync with the encoder calls.
> We might end up defining pre-enable/enable/disable/post-disable for a
> panel to sync
> with the bridge calls! I have explained below.
>
>>> -- sometimes in between the bridge controls (ps8622: one panel control
>>> before SLP_N and one after SLP_N)
>>> -- sometimes panel controls needs to be done after bridge controls.
>>
>> I am not convinced that a generic panel/bridge adapter is not
>> possible.  Maybe we need more fine grained fxn ptr callbacks, although
>> seems like pre+post should give you enough.  It would certainly be
>> easier than having to add panel support in each individual bridge
>> driver (which seems like it will certainly result that only certain
>> combinations of panel+bridge actually work as intended)
> Ok. Consider this case:
> Currently, we have the sequence as "bridge->pre_enable,
> encoder_enable, bridge->enable"
> And, the bridge should obviously be enabled in bridge->pre_enable.
> Now, where do you choose to call panel->pre_enable?
> -- as the first step of bridge->pre_enable, before we pull up/down bridge 
> GPIOs.
> -- at the last step of bridge->pre_enable, after we pull up/down the
> bridge GPIOs.
>
> Ideally, PTN3460 expects it to be the second case, and PS8625 expects
> it to be the first case.
> So, we will end up adding pre_pre_enable, post_pre_enable to
> accomodate such scenarios.

ok, well I think we can deal with this with a slight modification of
my original proposal.  Split drm_panel_bridge into
drm_composite_bridge and drm_panel_bridge:

  struct drm_composite_bridge {
struct drm_bridge base;
struct drm_bridge *b1, *b2;
  }

  static void drm_composite_bridge_enable(struct drm_bridge *bridge)
  {
struct drm_composite_bridge *cbridge = to_composite_bridge(bridge);
cbridge->b1->funcs->enable(cbridge->b1);
cbridge->b2->funcs->enable(cbridge->b2);
  }

  .. and so on ..

  struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
  }

  static void drm_panel_bridge_enable(struct drm_bridge *bridge)
  {
struct drm_panel_bridge *pbridge = to_panel_bridge(bridge);
pbridge->panel->funcs->enable(pbridge->panel);
  }

  .. and so on..


then in initialization, order can be managed like:

  if (panel_first)
bridge = drm_composite_bridge_init(panel_bridge, actual_bridge)
  else
bridge = drm_composite_bridge_init(actual_bridge, panel_bridge);

  possibly parametrize drm_panel_bridge if we need to map
panel->enable() to bridge->pre_enable() vs bridge->enable(), etc..

BR,
-R

> So, we leave the choice for the individual bridge chip drivers to
> implement panel
> power up/down controls in the place where they wish to.
>
>
> Thanks and regards,
>  Ajay Kumar
--
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: dts: exynos4412-trats2: rename alias for i2c_ak8975 label

2014-04-24 Thread Tomasz Figa

Hi Tomasz,

On 15.04.2014 16:25, Tomasz Stanislawski wrote:

The i2c_ak8975 controler uses label i2c8.
This alias is already used for I2C controller 8 defined
in file arch/arm/boot/dts/exynos4.dtsi.

This patch renames a label for i2c_ak8975 to i2c9.

Signed-off-by: Tomasz Stanislawski 
---
  arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index c16b315..5add765 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -20,7 +20,7 @@
compatible = "samsung,trats2", "samsung,exynos4412", "samsung,exynos4";

aliases {
-   i2c8 = &i2c_ak8975;
+   i2c9 = &i2c_ak8975;
};

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



Seems reasonable.

Reviewed-by: Tomasz Figa 

--
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] ARM: dts: exynos4: clean up arm-pmu node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 15:03, Chanho Park wrote:

This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.

Cc: Chanwoo Choi 
Signed-off-by: Chanho Park 
---
  arch/arm/boot/dts/exynos4.dtsi| 6 ++
  arch/arm/boot/dts/exynos4210.dtsi | 6 --
  arch/arm/boot/dts/exynos4412.dtsi | 6 ++
  arch/arm/boot/dts/exynos4x12.dtsi | 6 --
  4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e541ecb..6de978c 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = <0x1044 0x1000>;
};

+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupt-parent = <&combiner>;
+   interrupts = <2 2>, <3 2>;
+   };
+
sys_reg: syscon@1001 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x1001 0x400>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..4e7610f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = <1>;
};

-   pmu {
-   compatible = "arm,cortex-a9-pmu";
-   interrupt-parent = <&combiner>;
-   interrupts = <2 2>, <3 2>;
-   };
-
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4210-pinctrl";
reg = <0x1140 0x1000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 15d3c0a..e6af870 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,12 @@
samsung,combiner-nr = <20>;
};

+   pmu {
+   compatible = "arm,cortex-a9-pmu";
+   interrupt-parent = <&combiner>;


I guess you could omit the two properties above and let them be 
inherited from exynos4.dtsi.


Otherwise looks fine.

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 V5 00/20] ARM: exynos: cpuidle: Move the driver to drivers/cpuidle

2014-04-24 Thread Tomasz Figa

On 14.04.2014 11:01, Daniel Lezcano wrote:


Hi Kukjin,

I believe I addressed all the comments. Is it possible to take this
patchset for next ?


+1.

Also when applying you might add

Reviewed-by: Tomasz Figa 

to any patches that don't have it yet.

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] ARM: dts: Add atmel trackpad node to 5250 cros

2014-04-24 Thread Tomasz Figa

Hi Arun,

On 14.04.2014 08:35, Arun Kumar K wrote:

The newer versions of exynos5250 based Snow boards have
atmel trackpad. Updating relevant nodes for the same.

Signed-off-by: Arun Kumar K 
---
  arch/arm/boot/dts/exynos5250-cros-common.dtsi |   24 
  1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..658f086 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -28,6 +28,13 @@
samsung,pin-pud = <0>;
};

+   trackpad_irq: trackpad-irq {
+   samsung,pins = "gpx1-2";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
max77686_irq: max77686-irq {
samsung,pins = "gpx3-2";
samsung,pin-function = <0>;
@@ -191,6 +198,9 @@
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;

+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_bus &trackpad_irq>;


Please add &trackpad_irq to trackpad node instead. Pinctrl properties of 
i2c node should contain only i2c-related pins.



+
trackpad {
reg = <0x67>;
compatible = "cypress,cyapa";
@@ -198,6 +208,20 @@
interrupt-parent = <&gpx1>;
wakeup-source;
};
+   trackpad-alt {


Style: Please keep one blank line between two nodes.


+   reg = <0x4b>;
+   compatible = "atmel,atmel_mxt_tp";
+   interrupts = <2 0>;
+   interrupt-parent = <&gpx1>;
+   wakeup-source;
+   };
+   trackpad-bootloader {


Ditto.


+   reg = <0x25>;
+   compatible = "atmel,atmel_mxt_tp";
+   interrupts = <2 0>;
+   interrupt-parent = <&gpx1>;
+   wakeup-source;
+   };


Hmm, why are there 3 different nodes here? Could you explain what one by 
one for what hardware they are?


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 V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Ajay kumar
Rob,

On Thu, Apr 24, 2014 at 9:41 PM, Rob Clark  wrote:
> On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
>> Sorry for the previous reply,
>>
>> Here goes the full explaination:
>>
>>> Rob,
>>>
>>> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
 So what about, rather than adding drm_panel support to each bridge
 individually, we introduce a drm_panel_bridge (with a form of
 chaining).. ie:

   struct drm_panel_bridge {
 struct drm_bridge base;
 struct drm_panel *panel;
 struct drm_bridge *bridge; /* optional */
   };

   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
   {
 struct drm_panel_bridge *pb = to_panel_bridge(bridge);
 if (pb->bridge)
   pb->bridge->funcs->enable(pb->bridge);
 pb->panel->funcs->enable(pb->panel);
   }

>> We cannot call them like this from crtc helpers in the order you mentioned,
>> since each individual bridge chip expects the panel controls at
>> different places.
>> I mean,
>> -- sometimes panel controls needs to be done before bridge
>> controls(ptn3460: before RST_N and PD_N)
>
> well, this is why bridge has pre-enable/enable/disable/post-disable
> hooks, so you can choose before or after..
These calls are for a bridge to sync with the encoder calls.
We might end up defining pre-enable/enable/disable/post-disable for a
panel to sync
with the bridge calls! I have explained below.

>> -- sometimes in between the bridge controls (ps8622: one panel control
>> before SLP_N and one after SLP_N)
>> -- sometimes panel controls needs to be done after bridge controls.
>
> I am not convinced that a generic panel/bridge adapter is not
> possible.  Maybe we need more fine grained fxn ptr callbacks, although
> seems like pre+post should give you enough.  It would certainly be
> easier than having to add panel support in each individual bridge
> driver (which seems like it will certainly result that only certain
> combinations of panel+bridge actually work as intended)
Ok. Consider this case:
Currently, we have the sequence as "bridge->pre_enable,
encoder_enable, bridge->enable"
And, the bridge should obviously be enabled in bridge->pre_enable.
Now, where do you choose to call panel->pre_enable?
-- as the first step of bridge->pre_enable, before we pull up/down bridge GPIOs.
-- at the last step of bridge->pre_enable, after we pull up/down the
bridge GPIOs.

Ideally, PTN3460 expects it to be the second case, and PS8625 expects
it to be the first case.
So, we will end up adding pre_pre_enable, post_pre_enable to
accomodate such scenarios.

So, we leave the choice for the individual bridge chip drivers to
implement panel
power up/down controls in the place where they wish to.


Thanks and regards,
 Ajay Kumar
--
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] i2c: exynos5: Initialise Samsung High Speed I2C controller early

2014-04-24 Thread Mark Brown
On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote:
> This patch moves initialization code to subsys_initcall() to ensure
> that the i2c bus is available early so the regulators can be quickly
> probed and available for other devices on their probe() call.

> Such solution has been proposed by Mark Brown to fix the problem of
> the regulators not beeing available on the peripheral device probe():
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html

What specifically is this needed for?  We *should* be able to use
deferred probe for most things, but I know that not all subsystems are
able to yet.


signature.asc
Description: Digital signature


Re: [PATCH 3/4] ARM: dts: exynos4: add hsotg device node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch adds a hsotg node for exynos4 USB2.0 device controller.

Cc: Tomasz Figa 
Cc: Kamil Debski 
Cc: Marek Szyprowski 
Signed-off-by: Chanho Park 
---
  arch/arm/boot/dts/exynos4.dtsi | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0e32d7f..e541ecb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -288,6 +288,17 @@
#phy-cells = <1>;
};

+   hsotg@1248 {
+   compatible = "samsung,s3c6400-hsotg";
+   reg = <0x1248 0x2>;
+   interrupts = <0 71 0>;
+   clocks = <&clock 305>;


Please use clock macros.


+   clock-names = "otg";
+   phys = <&exynos_usbphy 0>;
+   phy-names = "device";


This is not the correct phy name for this binding. According to what the 
driver uses and the example in ...bindings/usb/dwc2.txt "usb2-phy" 
should be used.


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 v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

2014-04-24 Thread Tomasz Figa

Hi Tarek,

On 14.04.2014 13:59, Tarek Dakhran wrote:

On 04/14/2014 03:03 PM, Arnd Bergmann wrote:

On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:

--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[]
__initdata = {
 },
  };
+static struct map_desc exynos5410_iodesc[] __initdata = {
+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn=
__phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
  static struct map_desc exynos5_iodesc[] __initdata = {

NAK

Why does this keep coming up?

Arnd


We need this memory region because boot address for exynos5410 located
here, same as for 5250.



Is there really no way to map this region dynamically in the entity 
(driver, source file, whatever) that actually uses it? The goal is to 
get rid of all the static mappings entirely, so adding new one makes us 
further from it.


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 V2 7/9] drm/bridge: ptn3460: add drm_panel controls

2014-04-24 Thread Rob Clark
On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar  wrote:
> Sorry for the previous reply,
>
> Here goes the full explaination:
>
>> Rob,
>>
>> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark  wrote:
>>> So what about, rather than adding drm_panel support to each bridge
>>> individually, we introduce a drm_panel_bridge (with a form of
>>> chaining).. ie:
>>>
>>>   struct drm_panel_bridge {
>>> struct drm_bridge base;
>>> struct drm_panel *panel;
>>> struct drm_bridge *bridge; /* optional */
>>>   };
>>>
>>>   static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>>   {
>>> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
>>> if (pb->bridge)
>>>   pb->bridge->funcs->enable(pb->bridge);
>>> pb->panel->funcs->enable(pb->panel);
>>>   }
>>>
> We cannot call them like this from crtc helpers in the order you mentioned,
> since each individual bridge chip expects the panel controls at
> different places.
> I mean,
> -- sometimes panel controls needs to be done before bridge
> controls(ptn3460: before RST_N and PD_N)

well, this is why bridge has pre-enable/enable/disable/post-disable
hooks, so you can choose before or after..

> -- sometimes in between the bridge controls (ps8622: one panel control
> before SLP_N and one after SLP_N)
> -- sometimes panel controls needs to be done after bridge controls.

I am not convinced that a generic panel/bridge adapter is not
possible.  Maybe we need more fine grained fxn ptr callbacks, although
seems like pre+post should give you enough.  It would certainly be
easier than having to add panel support in each individual bridge
driver (which seems like it will certainly result that only certain
combinations of panel+bridge actually work as intended)

> So, putting these drm_panel controls inside individual bridge drivers will 
> work,
> but keeping them in crtc_helpers might break stuff.

I'm not talking about crtc changing helpers.

BR,
-R

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


Re: [PATCH 2/4] ARM: dts: exynos4: add exynos_usbphy node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.

Cc: Tomasz Figa 
Cc: Kamil Debski 
Signed-off-by: Chanho Park 
---
  arch/arm/boot/dts/exynos4.dtsi| 10 ++
  arch/arm/boot/dts/exynos4x12.dtsi |  5 +
  2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e565b86..0e32d7f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = "disabled";
};

+   exynos_usbphy: exynos-usbphy@125B {
+   compatible = "samsung,exynos4210-usb2-phy";
+   reg = <0x125B 0x100>;
+   samsung,pmureg-phandle = <&pmu_reg>;
+   clocks = <&clock 305>, <&clock 2>;


Please use clock macros from include/dt-bindings instead of numbers 
directly.


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 1/4] ARM: dts: exynos4: add PMU syscon node

2014-04-24 Thread Tomasz Figa

Hi Chanho,

On 14.04.2014 14:48, Chanho Park wrote:

This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.

Cc: Tomasz Figa 
Cc: Kamil Debski 
Signed-off-by: Chanho Park 
---
  arch/arm/boot/dts/exynos4.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = <0x1001 0x400>;
};

+   pmu_reg: syscon@1002 {
+   compatible = "samsung,exynos4-pmureg", "syscon";


This compatible string doesn't seem to be defined in [1], please add it 
there,


[1] Documentation/devicetree/bindings/arm/samsung/pmu.txt

Otherwise looks good, so after fixing that you may add my

Reviewed-by: Tomasz Figa 

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


[PATCH] i2c: mux: Use subsys_initcall for the i2c-arb-gpio-challenge

2014-04-24 Thread Naveen Krishna Chatradhi
From: Doug Anderson 

Since many drivers rely on FETs that live behind this arbitrator, they
can't successfully probe until after the arbitrator comes up.  They
ought to handle things properly with EPROBE_DEFER and still work, but
that has some downsides:

1. Those drivers don't come up till later in the boot process.  That
   really not so nice for the LCD--we want that to init early.
2. Some drivers have bugs and don't handle EPROBE_DEFER.  Those
   drivers should be fixed but not all of them have been fixed yet.
   HDMI is one example since DRM doesn't really have good support for
   deferring probes.

With this change We end up using the same init level as the main i2c bus.

Signed-off-by: Doug Anderson 
Reviewed-on: https://gerrit.chromium.org/gerrit/57007
Reviewed-by: Simon Glass 
Signed-off-by: Naveen Krishna Chatradhi 
---
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c 
b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
index 69afffa..6cf52bb 100644
--- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -241,7 +241,17 @@ static struct platform_driver i2c_arbitrator_driver = {
},
 };
 
-module_platform_driver(i2c_arbitrator_driver);
+static int __init i2c_arbitrator_init(void)
+{
+   return platform_driver_register(&i2c_arbitrator_driver);
+}
+subsys_initcall(i2c_arbitrator_init);
+
+static void __exit i2c_arbitrator_exit(void)
+{
+   platform_driver_unregister(&i2c_arbitrator_driver);
+}
+module_exit(i2c_arbitrator_exit);
 
 MODULE_DESCRIPTION("GPIO-based I2C Arbitration");
 MODULE_AUTHOR("Doug Anderson ");
-- 
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] i2c: exynos5: Initialise Samsung High Speed I2C controller early

2014-04-24 Thread Naveen Krishna Chatradhi
This patch moves initialization code to subsys_initcall() to ensure
that the i2c bus is available early so the regulators can be quickly
probed and available for other devices on their probe() call.

Such solution has been proposed by Mark Brown to fix the problem of
the regulators not beeing available on the peripheral device probe():
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html

Signed-off-by: Naveen Krishna Chatradhi 
---
 drivers/i2c/busses/i2c-exynos5.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 00af0a0..20e3077 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -762,8 +762,18 @@ static struct platform_driver exynos5_i2c_driver = {
},
 };
 
-module_platform_driver(exynos5_i2c_driver);
+static int __init i2c_adap_exynos5_init(void)
+{
+   return platform_driver_register(&exynos5_i2c_driver);
+}
+subsys_initcall(i2c_adap_exynos5_init);
+
+static void __exit i2c_adap_exynos5_exit(void)
+{
+   platform_driver_unregister(&exynos5_i2c_driver);
+}
 
+module_exit(i2c_adap_exynos5_exit);
 MODULE_DESCRIPTION("Exynos5 HS-I2C Bus driver");
 MODULE_AUTHOR("Naveen Krishna Chatradhi, ");
 MODULE_AUTHOR("Taekgyun Ko, ");
-- 
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 v5] clk: Exynos5250: Add clocks for G3D

2014-04-24 Thread Arun Kumar K
This patch adds the required clocks for ARM Mali IP
in Exynos5250.

Signed-off-by: Arun Kumar K 
---
This patch somehow got missed getting merged long time
back after Acks by Mike and Kukjin and review done by
Tomasz and Doug.
http://www.spinics.net/lists/linux-samsung-soc/msg21608.html
Resending it now after rebasing and testing on the latest kernel.

Changes from v4
- Rebased on latest kernel
- Added macros
Changes from v3
- Renamed some clocks as per Tomasz Figa's comments
Changes from v2
- Rebased on clk-next
Changes from v1
- Removed exporting of parent DIV clock for g3d
  as per Tomsz Figa's comment.
---
 drivers/clk/samsung/clk-exynos5250.c   |   14 ++
 include/dt-bindings/clock/exynos5250.h |2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee442..14a1d49 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -37,6 +37,7 @@
 #define VPLL_CON0  0x10140
 #define GPLL_CON0  0x10150
 #define SRC_TOP0   0x10210
+#define SRC_TOP1   0x10214
 #define SRC_TOP2   0x10218
 #define SRC_TOP3   0x1021c
 #define SRC_GSCL   0x10220
@@ -71,6 +72,7 @@
 #define GATE_IP_GSCL   0x10920
 #define GATE_IP_DISP1  0x10928
 #define GATE_IP_MFC0x1092c
+#define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
 #define GATE_IP_FSYS   0x10944
 #define GATE_IP_PERIC  0x10950
@@ -100,6 +102,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_CPU0,
SRC_CORE1,
SRC_TOP0,
+   SRC_TOP1,
SRC_TOP2,
SRC_TOP3,
SRC_GSCL,
@@ -189,10 +192,12 @@ PNAME(mout_vpllsrc_p) = { "fin_pll", "sclk_hdmi27m" };
 PNAME(mout_vpll_p) = { "mout_vpllsrc", "fout_vpll" };
 PNAME(mout_cpll_p) = { "fin_pll", "fout_cpll" };
 PNAME(mout_epll_p) = { "fin_pll", "fout_epll" };
+PNAME(mout_gpll_p) = { "fin_pll", "fout_gpll" };
 PNAME(mout_mpll_user_p)= { "fin_pll", "mout_mpll" };
 PNAME(mout_bpll_user_p)= { "fin_pll", "mout_bpll" };
 PNAME(mout_aclk166_p)  = { "mout_cpll", "mout_mpll_user" };
 PNAME(mout_aclk200_p)  = { "mout_mpll_user", "mout_bpll_user" };
+PNAME(mout_aclk400_p)  = { "mout_aclk400_g3d_mid", "mout_gpll" };
 PNAME(mout_aclk200_sub_p) = { "fin_pll", "div_aclk200" };
 PNAME(mout_aclk266_sub_p) = { "fin_pll", "div_aclk266" };
 PNAME(mout_aclk333_sub_p) = { "fin_pll", "div_aclk333" };
@@ -273,12 +278,16 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
MUX(0, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
MUX(0, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
+   MUX(0, "mout_aclk400_g3d_mid", mout_aclk200_p, SRC_TOP0, 20, 1),
+
+   MUX(0, "mout_aclk400_g3d", mout_aclk400_p, SRC_TOP1, 28, 1),
 
MUX(0, "mout_cpll", mout_cpll_p, SRC_TOP2, 8, 1),
MUX(0, "mout_epll", mout_epll_p, SRC_TOP2, 12, 1),
MUX(0, "mout_vpll", mout_vpll_p, SRC_TOP2, 16, 1),
MUX(0, "mout_mpll_user", mout_mpll_user_p, SRC_TOP2, 20, 1),
MUX(0, "mout_bpll_user", mout_bpll_user_p, SRC_TOP2, 24, 1),
+   MUX(CLK_MOUT_GPLL, "mout_gpll", mout_gpll_p, SRC_TOP2, 28, 1),
 
MUX(0, "mout_aclk200_disp1_sub", mout_aclk200_sub_p, SRC_TOP3, 4, 1),
MUX(0, "mout_aclk266_gscl_sub", mout_aclk266_sub_p, SRC_TOP3, 8, 1),
@@ -326,6 +335,7 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
 
MUX(0, "mout_mpll_fout", mout_mpll_fout_p, PLL_DIV2_SEL, 4, 1),
MUX(0, "mout_bpll_fout", mout_bpll_fout_p, PLL_DIV2_SEL, 0, 1),
+
 };
 
 static struct samsung_div_clock exynos5250_div_clks[] __initdata = {
@@ -351,6 +361,8 @@ static struct samsung_div_clock exynos5250_div_clks[] 
__initdata = {
DIV(0, "div_aclk200", "mout_aclk200", DIV_TOP0, 12, 3),
DIV(0, "div_aclk266", "mout_mpll_user", DIV_TOP0, 16, 3),
DIV(0, "div_aclk333", "mout_aclk333", DIV_TOP0, 20, 3),
+   DIV(0, "div_aclk400_g3d", "mout_aclk400_g3d", DIV_TOP0,
+   24, 3),
 
DIV(0, "div_aclk66_pre", "mout_mpll_user", DIV_TOP1, 24, 3),
 
@@ -615,6 +627,8 @@ static struct samsung_gate_clock exynos5250_gate_clks[] 
__initdata = {
GATE(CLK_WDT, "wdt", "div_aclk66", GATE_IP_PERIS, 19, 0, 0),
GATE(CLK_RTC, "rtc", "div_aclk66", GATE_IP_PERIS, 20, 0, 0),
GATE(CLK_TMU, "tmu", "div_aclk66", GATE_IP_PERIS, 21, 0, 0),
+   GATE(CLK_G3D, "g3d", "div_aclk400_g3d", GATE_IP_G3D, 0,
+   CLK_SET_RATE_PARENT, 0),
 };
 
 static struct samsung_pll_rate_table vpll_24mhz_tbl[] __initdata = {
diff --git a/include/dt-bindings/clock/exynos5250.h 
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..751915e 100644
--- a/include/dt-bindings/cl

Re: [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board

2014-04-24 Thread Mark Brown
On Wed, Apr 23, 2014 at 02:31:45PM +0530, Tushar Behera wrote:

> +Required properties:
> +- compatible : Can be one of the following,
> + "google,snow-audio-max98090" or
> + "google,snow-audio-max98095"
> +- samsung,i2s-controller: The phandle of the Samsung I2S0 controller

This should be any I2S controller, not just I2S0?

> +- samsung,audio-codec: The phandle of the audio codec

This binding only has one I2S controller and CODEC.  However...

> +static struct snd_soc_dai_link snow_dai[] = {
> + { /* Playback DAI i/f */
> + .name = "Playback",
> + .stream_name = "Playback",
> + .codec_dai_name = "HiFi",
> + .dai_fmt = SND_SOC_DAIFMT_I2S |
> + SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_CBS_CFS,
> + }, { /* Capture DAI i/f */
> + .name = "Capture",
> + .stream_name = "Capture",
> + .codec_dai_name = "HiFi",
> + .dai_fmt = SND_SOC_DAIFMT_I2S |
> + SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_CBS_CFS,
> + },
> +};

...for some reason we have separate capture and playback DAI links
defined.  Why is that?  Also, why is the secondary I2S playback stream
not supported (this may be a reason to restrict to only the one I2S
interface)?

Please also use subject lines consistent with the subsystem - NO NEED TO
SHOUT.


signature.asc
Description: Digital signature


Re: [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210

2014-04-24 Thread Vikas Sajjan
Hi Pankaj,

On Thu, Apr 24, 2014 at 6:27 PM, Pankaj Dubey  wrote:
> Hi Vikas,
>
>
> On 04/24/2014 08:59 PM, Vikas Sajjan wrote:
>>
>> +Tomasz
>>
>>
>> On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey 
>> wrote:
>>>
>>> This patch adds pmu regnode to exynos4210 dtsi to handle
>>> PMU register access via DT.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>> ---
>>>   arch/arm/boot/dts/exynos4210.dtsi |5 +
>>>   1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
>>> b/arch/arm/boot/dts/exynos4210.dtsi
>>> index cacf614..0a2c0fe 100644
>>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>>> @@ -81,6 +81,11 @@
>>>  interrupts = <2 2>, <3 2>;
>>>  };
>>>
>>> +   pmu_system_controller: system-controller@1002 {
>>> +   compatible = "samsung,exynos4210-pmu", "syscon";
>>> +   reg = <0x1002 0x5000>;
>>
>> Can we have 2 strings as "compatible" and these 2 strings are used by
>> 2 different driver?
>>
>> Because once syscon driver gets probed, exynos-pmu.c [1] driver will
>> never be probed.
>>
>> The new PMU driver [1] completely relies on this. With just
>> exynos_defconfig, you will not notice this issue, since syscon is NOT
>> enabled by exynos_defconfig. When I enabled "System Controller
>> Register R/W Based on Regmap" in menuconfig, I could see PMU driver
>> [1] is NEVER probed.
>>
>> Let me know, if I am missing something.
>>
>>   [1] http://www.spinics.net/lists/arm-kernel/msg319750.html
>
>
> You are correct. We also missed this because "SYSCON" option was
> not enabled in exynos_defconfig.
> I noticed this during preparation of V2 when I planned to use
> "early_syscon_init" [1] as suggested by Sylwester here [2].
>
OK.

> In V2 I will take care of this. I hope soon I will be able to post second

So in your V2, will you be adding new DT node altogether for PMU?
Because with existing DT node "pmu_system_controller"  (which is
already present in mailine for exynos 5250) and SYSCON driver enable,
exynos PMU driver will NEVER probed.

> version of this series, just waiting for testing and internal code review.
>
> [1] https://lkml.org/lkml/2014/4/8/239
> [2] https://lkml.org/lkml/2014/4/2/171
>
>>
>>
>>> +   };
>>> +
>>>  pinctrl_0: pinctrl@1140 {
>>>  compatible = "samsung,exynos4210-pinctrl";
>>>  reg = <0x1140 0x1000>;
>>> --
>>> 1.7.10.4
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Best Regards,
> Pankaj Dubey
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 4/4] ARM: S3C24XX: move debug-macro.S into the common space

2014-04-24 Thread Heiko Stübner
Move debug-macro.S from mach/include to include/debug where all other common
debug macros are.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 1 +
 .../{mach-s3c24xx/include/mach/debug-macro.S => include/debug/s3c24xx.S} | 0
 2 files changed, 1 insertion(+)
 rename arch/arm/{mach-s3c24xx/include/mach/debug-macro.S => 
include/debug/s3c24xx.S} (100%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9755e63..2e1bd76 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1010,6 +1010,7 @@ config DEBUG_LL_INCLUDE
 DEBUG_IMX6SL_UART
default "debug/msm.S" if DEBUG_MSM_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
+   default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || 
DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
default "debug/tegra.S" if DEBUG_TEGRA_UART
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/include/debug/s3c24xx.S
similarity index 100%
rename from arch/arm/mach-s3c24xx/include/mach/debug-macro.S
rename to arch/arm/include/debug/s3c24xx.S
-- 
1.9.0


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


[PATCH v2 3/4] ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro

2014-04-24 Thread Heiko Stübner
This removes the need for mach/-headers in the debug macro.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 23 +--
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |  9 ++---
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index cb5751f..9755e63 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -625,6 +625,7 @@ choice
config DEBUG_S3C_UART0
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 0 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -637,6 +638,7 @@ choice
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 1 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -649,6 +651,7 @@ choice
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 2 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -950,6 +953,10 @@ config DEBUG_EXYNOS_UART
 
 config DEBUG_S3C2410_UART
bool
+   select DEBUG_S3C24XX_UART
+
+config DEBUG_S3C24XX_UART
+   bool
 
 config DEBUG_OMAP2PLUS_UART
bool
@@ -1059,6 +1066,12 @@ config DEBUG_UART_PHYS
default 0x4009 if ARCH_LPC32XX
default 0x4010 if DEBUG_PXA_UART1
default 0x4200 if ARCH_GEMINI
+   default 0x5000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART0 || \
+   DEBUG_S3C2410_UART0)
+   default 0x50004000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART1 || \
+   DEBUG_S3C2410_UART1)
+   default 0x50008000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART2 || \
+   DEBUG_S3C2410_UART2)
default 0x7c0003f8 if FOOTBRIDGE
default 0x8023 if DEBUG_PICOXCELL_UART
default 0x8007 if DEBUG_IMX23_UART
@@ -1088,7 +1101,7 @@ config DEBUG_UART_PHYS
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_LL_UART_EFM32 || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
@@ -1105,6 +1118,12 @@ config DEBUG_UART_VIRT
default 0xf210 if DEBUG_PXA_UART1
default 0xf409 if ARCH_LPC32XX
default 0xf420 if ARCH_GEMINI
+   default 0xf700 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART0 || \
+   DEBUG_S3C2410_UART0)
+   default 0xf7004000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART1 || \
+   DEBUG_S3C2410_UART1)
+   default 0xf7008000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART2 || \
+   DEBUG_S3C2410_UART2)
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
default 0xf809 if DEBUG_VEXPRESS_UART0_RS1
@@ -1146,7 +1165,7 @@ config DEBUG_UART_VIRT
default 0xff003000 if DEBUG_U300_UART
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_8250_SHIFT
int "Register offset shift for the 8250 debug UART"
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index fbe3e71..b1f54dc 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -12,18 +12,13 @@
  * published by the Free Software Foundation.
 */
 
-#include 
 #include 
 
 #define S3C2410_UART1_OFF (0x4000)
 
.macro addruart, rp, rv, tmp
-   ldr \rp, = S3C24XX_PA_UART
-   ldr \rv, = S3C24XX_VA_UART
-#if CONFIG_DEBUG_S3C_UART != 0
-   add \rp, \rp, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-   add \rv, \rv, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-#endif
+   ldr \rp, = CONFIG_DEBUG_UART_PHYS
+   ldr \rv, = CONFIG_DEBUG_UART_VIRT
.endm
 
.macro  fifo_full_s3c2410 rd, rx
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.o

[PATCH v2 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Using the lowlevel debug uart is a corner case - even more so in a
multiplatform environment. So it seems reasonable to simply let the
developer set the appropriate uart type for the debugged SoC.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 30 ++
 arch/arm/mach-s3c24xx/Kconfig| 28 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 52 +---
 3 files changed, 31 insertions(+), 79 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4a2fc0b..cb5751f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -670,6 +670,33 @@ choice
  The uncompressor code port configuration is now handled
  by CONFIG_S3C_LOWLEVEL_UART_PORT.
 
+   config DEBUG_S3C2410_UART0
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool "Use S3C2410/S3C2412 UART 0 for low-level debug"
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 0. The port must have been initialised
+ by the boot-loader before use.
+
+   config DEBUG_S3C2410_UART1
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool "Use S3C2410/S3C2412 UART 1 for low-level debug"
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 1. The port must have been initialised
+ by the boot-loader before use.
+
+   config DEBUG_S3C2410_UART2
+   depends on ARCH_S3C24XX
+   select DEBUG_S3C2410_UART
+   bool "Use S3C2410/S3C2412 UART 2 for low-level debug"
+   help
+ Say Y here if you want the debug print routines to direct
+ their output to UART 2. The port must have been initialised
+ by the boot-loader before use.
+
config DEBUG_SOCFPGA_UART
depends on ARCH_SOCFPGA
bool "Use SOCFPGA UART for low-level debug"
@@ -921,6 +948,9 @@ endchoice
 config DEBUG_EXYNOS_UART
bool
 
+config DEBUG_S3C2410_UART
+   bool
+
 config DEBUG_OMAP2PLUS_UART
bool
depends on ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 40cf50b..98d17af 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -26,7 +26,6 @@ config CPU_S3C2410
bool "SAMSUNG S3C2410"
default y
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
@@ -39,7 +38,6 @@ config CPU_S3C2410
 config CPU_S3C2412
bool "SAMSUNG S3C2412"
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2412_DMA if S3C24XX_DMA
select S3C2412_PM if PM
help
@@ -48,7 +46,6 @@ config CPU_S3C2412
 config CPU_S3C2416
bool "SAMSUNG S3C2416/S3C2450"
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2416_PM if PM
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
@@ -59,7 +56,6 @@ config CPU_S3C2416
 config CPU_S3C2440
bool "SAMSUNG S3C2440"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
@@ -69,7 +65,6 @@ config CPU_S3C2440
 config CPU_S3C2442
bool "SAMSUNG S3C2442"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
@@ -84,7 +79,6 @@ config CPU_S3C244X
 config CPU_S3C2443
bool "SAMSUNG S3C2443"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
select SAMSUNG_CLKSRC
@@ -158,28 +152,6 @@ config S3C2410_PM
help
  Power Management code common to S3C2410 and better
 
-# low-level serial option nodes
-
-config CPU_LLSERIAL_S3C2410_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2410 && !CPU_LLSERIAL_S3C2440
-
-config CPU_LLSERIAL_S3C2440_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2440 && !CPU_LLSERIAL_S3C2410
-
-config CPU_LLSERIAL_S3C2410
-   bool
-   help
- Selected if there is an S3C2410 (or register compatible) serial
- low-level implementation needed
-
-config CPU_LLSERIAL_S3C2440
-   bool
-   help
- Selected if there is an S3C2440 (or register compatible) serial
- low-level implementation needed
-
 config S3C24XX_PLL
bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
depends on ARM_S3C24XX_CPUFREQ
diff --git a/arch/arm/mach-s3c24xx/include/mach/deb

[PATCH v2 1/4] ARM: compressed/head.S: remove s3c24xx special case

2014-04-24 Thread Heiko Stübner
addruart from the generic debug macro is doing exactly the same using
the common lowlevel uart definition, so there is no cause for this
special casing for s3c24xx.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/compressed/head.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 066b034..3a8b32d 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -60,11 +60,6 @@
add \rb, \rb, #0x0001   @ Ser1
 #endif
.endm
-#elif defined(CONFIG_ARCH_S3C24XX)
-   .macro loadsp, rb, tmp
-   mov \rb, #0x5000
-   add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
-   .endm
 #else
.macro  loadsp, rb, tmp
addruart \rb, \tmp
-- 
1.9.0


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


[PATCH v2 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

2014-04-24 Thread Heiko Stübner
This series tries to simplify the s3c24xx debug macro, removing dependencies
on mach/ includes, static mappings and finally moving it into include/debug.

The one slightly invasive change is the need for the developer to select
the uart type by himself, which gets rid of the debug macro trying to
determine the uart type itself.

But as usage of the debug-uart is not the common case - especially in a
multiplatform scenario - I didn't worry to much.

Based on 3.15-rc1 and tested on a S3C2442 Openmoko Freerunner (GTA02)

changes since v1:
- do not introduce a secondary choice option, instead implement the
  s3c2410 debug uarts as separate options

Heiko Stuebner (4):
  ARM: compressed/head.S: remove s3c24xx special case
  ARM: S3C24XX: trim down debug uart handling
  ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
  ARM: S3C24XX: move debug-macro.S into the common space

 arch/arm/Kconfig.debug   |  54 +++-
 arch/arm/boot/compressed/head.S  |   5 --
 arch/arm/include/debug/s3c24xx.S |  46 +++
 arch/arm/mach-s3c24xx/Kconfig|  28 ---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 ---
 5 files changed, 98 insertions(+), 136 deletions(-)
 create mode 100644 arch/arm/include/debug/s3c24xx.S
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S

-- 
1.9.0


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


[PATCH v3 16/16] clk: exynos5420: add more registers to restore list

2014-04-24 Thread Shaik Ameer Basha
This patch adds more register offsets to the restore list.

Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 33a48d2..6dfd3fd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -27,6 +27,7 @@
 #define DIV_CPU1   0x504
 #define GATE_BUS_CPU   0x700
 #define GATE_SCLK_CPU  0x800
+#define CLKOUT_CMU_CPU 0xa00
 #define GATE_IP_G2D0x8800
 #define CPLL_LOCK  0x10020
 #define DPLL_LOCK  0x10030
@@ -39,7 +40,11 @@
 #define CPLL_CON0  0x10120
 #define DPLL_CON0  0x10128
 #define EPLL_CON0  0x10130
+#define EPLL_CON1  0x10134
+#define EPLL_CON2  0x10138
 #define RPLL_CON0  0x10140
+#define RPLL_CON1  0x10144
+#define RPLL_CON2  0x10148
 #define IPLL_CON0  0x10150
 #define SPLL_CON0  0x10160
 #define VPLL_CON0  0x10170
@@ -139,6 +144,13 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_CPU1,
GATE_BUS_CPU,
GATE_SCLK_CPU,
+   CLKOUT_CMU_CPU,
+   EPLL_CON0,
+   EPLL_CON1,
+   EPLL_CON2,
+   RPLL_CON0,
+   RPLL_CON1,
+   RPLL_CON2,
SRC_TOP0,
SRC_TOP1,
SRC_TOP2,
-- 
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 v3 15/16] clk: exynos5420: create clock ID for mout_sclk_vpll

2014-04-24 Thread Shaik Ameer Basha
This patch adds clock ID for mout_sclk_vpll clock

Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |2 +-
 include/dt-bindings/clock/exynos5420.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 944ff20..33a48d2 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -437,7 +437,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
SRC_TOP5, 28, 1),
 
MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
-   MUX(0, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
+   MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
index b2410bc..7c80443 100755
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -190,6 +190,7 @@
 #define CLK_MOUT_HDMI  640
 #define CLK_MOUT_MAUDIO0   642
 #define CLK_MOUT_G3D   643
+#define CLK_MOUT_VPLL  644
 
 /* divider clocks */
 #define CLK_DOUT_PIXEL 768
-- 
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 v3 14/16] clk: exynos5420: correct g3d parent clock

2014-04-24 Thread Shaik Ameer Basha
This patch fixes the g3d parent clock.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |7 +++
 include/dt-bindings/clock/exynos5420.h |2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 0323b34..944ff20 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -427,8 +427,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
8, 1),
MUX(0, "mout_user_aclk266_g2d", mout_user_aclk266_g2d_p, SRC_TOP5,
12, 1),
-   MUX_A(0, "mout_user_aclk_g3d", mout_user_aclk_g3d_p,
-   SRC_TOP5, 16, 1, "aclkg3d"),
+   MUX(CLK_MOUT_G3D, "mout_user_aclk_g3d", mout_user_aclk_g3d_p,
+   SRC_TOP5, 16, 1),
MUX(0, "mout_user_aclk300_jpeg", mout_user_aclk300_jpeg_p,
SRC_TOP5, 20, 1),
MUX(0, "mout_user_aclk300_disp1", mout_user_aclk300_disp1_p,
@@ -889,8 +889,7 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_MFC, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
GATE(CLK_SMMU_MFCL, "smmu_mfcl", "dout_mfc_blk", GATE_IP_MFC, 1, 0, 0),
GATE(CLK_SMMU_MFCR, "smmu_mfcr", "dout_mfc_blk", GATE_IP_MFC, 2, 0, 0),
-
-   GATE(CLK_G3D, "g3d", "aclkg3d", GATE_IP_G3D, 9, 0, 0),
+   GATE(CLK_G3D, "g3d", "mout_user_aclk_g3d", GATE_IP_G3D, 9, 0, 0),
 
GATE(CLK_ROTATOR, "rotator", "mout_user_aclk266", GATE_IP_GEN, 1, 0, 0),
GATE(CLK_JPEG, "jpeg", "aclk300_jpeg", GATE_IP_GEN, 2, 0, 0),
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
index c36c7c6..b2410bc 100755
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -176,7 +176,6 @@
 #define CLK_SMMU_FIMCL1493
 #define CLK_SMMU_FIMCL3494
 #define CLK_FIMC_LITE3 495
-#define CLK_ACLK_G3D   500
 #define CLK_G3D501
 #define CLK_SMMU_MIXER 502
 #define CLK_SMMU_G2D   503
@@ -190,6 +189,7 @@
 /* mux clocks */
 #define CLK_MOUT_HDMI  640
 #define CLK_MOUT_MAUDIO0   642
+#define CLK_MOUT_G3D   643
 
 /* divider clocks */
 #define CLK_DOUT_PIXEL 768
-- 
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 v3 13/16] clk: exynos5420: cleanup core and misc clocks

2014-04-24 Thread Shaik Ameer Basha
This patch renames some of the clocks according to the
datasheet. It also adds and updates some core and misc
clocks.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |   29 +++--
 include/dt-bindings/clock/exynos5420.h |3 +++
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 3afc112..0323b34 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -62,7 +62,8 @@
 #define SRC_TOP11  0x10284
 #define SRC_TOP12  0x10288
 #define SRC_MASK_TOP2  0x10308
-#defineSRC_MASK_DISP10 0x1032c
+#define SRC_MASK_DISP100x1032c
+#define SRC_MASK_MAU   0x10334
 #define SRC_MASK_FSYS  0x10340
 #define SRC_MASK_PERIC00x10350
 #define SRC_MASK_PERIC10x10354
@@ -271,6 +272,7 @@ PNAME(mout_group5_p) = {"mout_sclk_vpll", "mout_sclk_dpll"};
 PNAME(mout_fimd1_final_p) = {"mout_fimd1", "mout_fimd1_opt"};
 PNAME(mout_sw_aclk66_p)= {"dout_aclk66", "mout_sclk_spll"};
 PNAME(mout_user_aclk66_peric_p) = {"fin_pll", "mout_sw_aclk66"};
+PNAME(mout_user_aclk66_gpio_p) = {"mout_sw_aclk66", "ffactor_sw_aclk66"};
 
 PNAME(mout_sw_aclk200_fsys_p) = {"dout_aclk200_fsys", "mout_sclk_spll"};
 PNAME(mout_sw_pclk200_fsys_p) = {"dout_pclk200_fsys", "mout_sclk_spll"};
@@ -351,6 +353,8 @@ PNAME(mout_hdmi_p) = {"dout_hdmi_pixel", "sclk_hdmiphy"};
 PNAME(mout_maudio0_p) = {"fin_pll", "maudio_clk", "mout_sclk_dpll",
 "mout_sclk_mpll", "mout_sclk_spll", "mout_sclk_ipll",
 "mout_sclk_epll", "mout_sclk_rpll"};
+PNAME(mout_mau_epll_clk_p) = {"mout_sclk_epll", "mout_sclk_dpll",
+   "mout_sclk_mpll", "mout_sclk_spll"};
 
 /* fixed rate clocks generated outside the soc */
 static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] 
__initdata = {
@@ -367,7 +371,8 @@ static struct samsung_fixed_rate_clock 
exynos5420_fixed_rate_clks[] __initdata =
 };
 
 static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] 
__initdata = {
-   FFACTOR(0, "sclk_hsic_12m", "fin_pll", 1, 2, 0),
+   FFACTOR(0, "ffactor_hsic_12m", "fin_pll", 1, 2, 0),
+   FFACTOR(0, "ffactor_sw_aclk66", "mout_sw_aclk66", 1, 2, 0),
 };
 
 static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
@@ -478,7 +483,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
TOP_SPARE2, 8, 1, CLK_SET_RATE_PARENT, 0),
 
/* MAU Block */
-   MUX(0, "mout_maudio0", mout_maudio0_p, SRC_MAU, 28, 3),
+   MUX_F(CLK_MOUT_MAUDIO0, "mout_maudio0", mout_maudio0_p, SRC_MAU, 28, 3,
+   CLK_SET_RATE_PARENT, 0),
 
/* FSYS Block */
MUX(0, "mout_usbd301", mout_group2_p, SRC_FSYS, 4, 3),
@@ -502,6 +508,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_spi0", mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, "mout_spi1", mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, "mout_spi2", mout_group2_p, SRC_PERIC1, 28, 3),
+
+   MUX(0, "mout_user_aclk66_gpio", mout_user_aclk66_gpio_p,
+   SRC_TOP7, 4, 1),
+   MUX_F(0, "mout_mau_epll_clk", mout_mau_epll_clk_p, SRC_TOP7, 20, 2,
+   CLK_SET_RATE_PARENT, 0),
MUX(0, "mout_pclk200_fsys", mout_group1_p, SRC_TOP0, 24, 2),
MUX(0, "mout_sw_pclk200_fsys", mout_sw_pclk200_fsys_p,
SRC_TOP10, 24, 1),
@@ -552,10 +563,10 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
 };
 
 static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
-   DIV(0, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
+   DIV(0, "dout_armclk1", "mout_cpu", DIV_CPU0, 0, 3),
DIV(0, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
-   DIV(0, "armclk2", "div_arm", DIV_CPU0, 28, 3),
-   DIV(0, "div_kfc", "mout_cpu_kfc", DIV_KFC0, 0, 3),
+   DIV(0, "dout_armclk2", "dout_armclk1", DIV_CPU0, 28, 3),
+   DIV(0, "dout_kfc", "mout_kfc", DIV_KFC0, 0, 3),
DIV(0, "sclk_kpll", "mout_kpll", DIV_KFC0, 24, 3),
 
DIV(0, "dout_aclk400_mscl", "mout_aclk400_mscl", DIV_TOP0, 4, 3),
@@ -908,6 +919,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1",
GATE_IP_DISP1, 9, 0, 0),
+
+   /* aclk333 gates internal MFC busses and should not be gated. */
/* aclk266 also gates other IPs in psgen. It should not be gated. */
GATE(0, "aclk266", "mout_user_aclk266",
GATE_BUS_NOC, 22, CLK_IGNORE_UNUSED, 0),
@@ -928,6 +941,10 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
   

[PATCH v3 11/16] clk: exynos5420: correct sysmmu-mfc parent clocks

2014-04-24 Thread Shaik Ameer Basha
This patch corrects the wrong parent-child relationship
between sysmmu-mfc clocks.

Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index d8fe6d8..6daf739 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -82,6 +82,7 @@
 #define SCLK_DIV_ISP0  0x10580
 #define SCLK_DIV_ISP1  0x10584
 #define DIV2_RATIO00x10590
+#define DIV4_RATIO 0x105a0
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
@@ -176,6 +177,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP0,
SCLK_DIV_ISP1,
DIV2_RATIO0,
+   DIV4_RATIO,
GATE_BUS_TOP,
GATE_BUS_GEN,
GATE_BUS_FSYS0,
@@ -636,6 +638,9 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, "dout_spi1_pre", "dout_spi1", DIV_PERIC4, 16, 8),
DIV(0, "dout_spi2_pre", "dout_spi2", DIV_PERIC4, 24, 8),
 
+   /* Mfc Blk */
+   DIV(0, "dout_mfc_blk", "mout_user_aclk333", DIV4_RATIO, 0, 2),
+
/* GSCL Block */
DIV(0, "dout_gscl_blk_300", "mout_user_aclk300_gscl",
DIV2_RATIO0, 4, 2),
@@ -873,8 +878,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_DISP1, 8, 0, 0),
 
GATE(CLK_MFC, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
-   GATE(CLK_SMMU_MFCL, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
-   GATE(CLK_SMMU_MFCR, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
+   GATE(CLK_SMMU_MFCL, "smmu_mfcl", "dout_mfc_blk", GATE_IP_MFC, 1, 0, 0),
+   GATE(CLK_SMMU_MFCR, "smmu_mfcr", "dout_mfc_blk", GATE_IP_MFC, 2, 0, 0),
 
GATE(CLK_G3D, "g3d", "aclkg3d", GATE_IP_G3D, 9, 0, 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 v3 12/16] clk: exynos5420: fix register offset for sclk_bpll

2014-04-24 Thread Shaik Ameer Basha
This patch fixes the wrong register offset for sclk_bpll clock.

Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 6daf739..3afc112 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,7 +111,6 @@
 #define TOP_SPARE2 0x10b08
 #define BPLL_LOCK  0x20010
 #define BPLL_CON0  0x20110
-#define SRC_CDREX  0x20200
 #define KPLL_LOCK  0x28000
 #define KPLL_CON0  0x28100
 #define SRC_KFC0x28200
@@ -204,7 +203,6 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
TOP_SPARE2,
-   SRC_CDREX,
SRC_KFC,
DIV_KFC0,
 };
@@ -380,7 +378,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1),
MUX(0, "mout_kfc", mout_kfc_p, SRC_KFC, 16, 1),
 
-   MUX(0, "sclk_bpll", mout_bpll_p, SRC_CDREX, 0, 1),
+   MUX(0, "sclk_bpll", mout_bpll_p, TOP_SPARE2, 0, 1),
 
MUX_A(0, "mout_aclk400_mscl", mout_group1_p,
SRC_TOP0, 4, 2, "aclk400_mscl"),
-- 
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 v3 10/16] clk: exynos5420: update clocks for FSYS and FSYS2 blocks

2014-04-24 Thread Shaik Ameer Basha
This patch adds more clocks from FSYS and FSYS2 blocks
and uses GATE_IP_* registers for gating IPs.

Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |   37 +++---
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index d9996dd..d8fe6d8 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -85,6 +85,7 @@
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
+#define GATE_BUS_FSYS2 0x10748
 #define GATE_BUS_PERIC 0x10750
 #define GATE_BUS_PERIC10x10754
 #define GATE_BUS_PERIS00x10760
@@ -97,6 +98,7 @@
 #define GATE_IP_DISP1  0x10928
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
+#define GATE_IP_FSYS   0x10944
 #define GATE_IP_PERIC  0x10950
 #define GATE_IP_PERIS  0x10960
 #define GATE_IP_MSCL   0x10970
@@ -177,6 +179,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_BUS_TOP,
GATE_BUS_GEN,
GATE_BUS_FSYS0,
+   GATE_BUS_FSYS2,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
@@ -189,6 +192,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_DISP1,
GATE_IP_G3D,
GATE_IP_GEN,
+   GATE_IP_FSYS,
GATE_IP_PERIC,
GATE_IP_PERIS,
GATE_IP_MSCL,
@@ -269,6 +273,8 @@ PNAME(mout_sw_aclk66_p) = {"dout_aclk66", 
"mout_sclk_spll"};
 PNAME(mout_user_aclk66_peric_p) = {"fin_pll", "mout_sw_aclk66"};
 
 PNAME(mout_sw_aclk200_fsys_p) = {"dout_aclk200_fsys", "mout_sclk_spll"};
+PNAME(mout_sw_pclk200_fsys_p) = {"dout_pclk200_fsys", "mout_sclk_spll"};
+PNAME(mout_user_pclk200_fsys_p)= {"fin_pll", "mout_sw_pclk200_fsys"};
 PNAME(mout_user_aclk200_fsys_p)= {"fin_pll", "mout_sw_aclk200_fsys"};
 
 PNAME(mout_sw_aclk200_fsys2_p) = {"dout_aclk200_fsys2", "mout_sclk_spll"};
@@ -481,6 +487,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_mmc2", mout_group2_p, SRC_FSYS, 16, 3),
MUX(0, "mout_usbd300", mout_group2_p, SRC_FSYS, 20, 3),
MUX(0, "mout_unipro", mout_group2_p, SRC_FSYS, 24, 3),
+   MUX(0, "mout_mphy_refclk", mout_group2_p, SRC_FSYS, 28, 3),
 
/* PERIC Block */
MUX(0, "mout_uart0", mout_group2_p, SRC_PERIC0, 4, 3),
@@ -495,6 +502,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_spi0", mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, "mout_spi1", mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, "mout_spi2", mout_group2_p, SRC_PERIC1, 28, 3),
+   MUX(0, "mout_pclk200_fsys", mout_group1_p, SRC_TOP0, 24, 2),
+   MUX(0, "mout_sw_pclk200_fsys", mout_sw_pclk200_fsys_p,
+   SRC_TOP10, 24, 1),
+   MUX(0, "mout_user_pclk200_fsys", mout_user_pclk200_fsys_p,
+   SRC_TOP3, 24, 1),
MUX(0, "mout_aclk100_noc", mout_group1_p, SRC_TOP0, 20, 2),
MUX(0, "mout_sw_aclk100_noc", mout_sw_aclk100_noc_p,
SRC_TOP10, 20, 1),
@@ -594,6 +606,7 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, "dout_mmc2", "mout_mmc2", DIV_FSYS1, 20, 10),
 
DIV(0, "dout_unipro", "mout_unipro", DIV_FSYS2, 24, 8),
+   DIV(0, "dout_mphy_refclk", "mout_mphy_refclk", DIV_FSYS2, 16, 8),
 
/* UART and PWM */
DIV(0, "dout_uart0", "mout_uart0", DIV_PERIC0, 8, 4),
@@ -720,12 +733,12 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_SCLK_USBPHY300, "sclk_usbphy300", "dout_usbphy300",
GATE_TOP_SCLK_FSYS, 8, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_USBD300, "sclk_usbd300", "dout_usbd300",
-   GATE_TOP_SCLK_FSYS, 9, CLK_SET_RATE_PARENT, 0),
+   GATE_TOP_SCLK_FSYS, 9, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_USBD301, "sclk_usbd301", "dout_usbd301",
-   GATE_TOP_SCLK_FSYS, 10, CLK_SET_RATE_PARENT, 0),
+   GATE_TOP_SCLK_FSYS, 10, CLK_IGNORE_UNUSED, 0),
 
-   GATE(CLK_SCLK_USBD301, "sclk_unipro", "dout_unipro",
-   SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
+   GATE(CLK_SCLK_UNIPRO, "sclk_unipro", "dout_unipro",
+   GATE_IP_FSYS, 23, CLK_SET_RATE_PARENT, 0),
 
GATE(CLK_SCLK_GSCL_WA, "sclk_gscl_wa", "mout_user_aclk333_432_gscl",
GATE_TOP_SCLK_GSCL, 6, CLK_SET_RATE_PARENT, 0),
@@ -754,15 +767,15 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_PDMA0, "pdma0", "aclk200_fsys", GATE_BUS_FSYS0, 1, 0, 0),
GATE(CLK_PDMA1, "pdma1", "aclk200_fsys", GATE_BUS_FSYS0, 2, 0, 0),
GATE(CLK_UFS, "ufs", "aclk200_fsys2", GATE_BUS_FSYS0, 3, 0, 0),
-   GATE(CLK_RTIC, "rtic", "aclk200_fsys", GATE_BUS_

[PATCH v3 09/16] clk: exynos5420: update clocks for WCORE block

2014-04-24 Thread Shaik Ameer Basha
This patch adds missing clocks from WCORE block.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 6ad87d1..d9996dd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -89,6 +89,7 @@
 #define GATE_BUS_PERIC10x10754
 #define GATE_BUS_PERIS00x10760
 #define GATE_BUS_PERIS10x10764
+#define GATE_BUS_NOC   0x10770
 #define GATE_TOP_SCLK_ISP  0x10870
 #define GATE_IP_GSCL0  0x10910
 #define GATE_IP_GSCL1  0x10920
@@ -180,6 +181,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
GATE_BUS_PERIS1,
+   GATE_BUS_NOC,
GATE_TOP_SCLK_ISP,
GATE_IP_GSCL0,
GATE_IP_GSCL1,
@@ -271,6 +273,13 @@ PNAME(mout_user_aclk200_fsys_p)= {"fin_pll", 
"mout_sw_aclk200_fsys"};
 
 PNAME(mout_sw_aclk200_fsys2_p) = {"dout_aclk200_fsys2", "mout_sclk_spll"};
 PNAME(mout_user_aclk200_fsys2_p) = {"fin_pll", "mout_sw_aclk200_fsys2"};
+PNAME(mout_sw_aclk100_noc_p) = {"dout_aclk100_noc", "mout_sclk_spll"};
+PNAME(mout_user_aclk100_noc_p) = {"fin_pll", "mout_sw_aclk100_noc"};
+
+PNAME(mout_sw_aclk400_wcore_p) = {"dout_aclk400_wcore", "mout_sclk_spll"};
+PNAME(mout_aclk400_wcore_bpll_p) = {"mout_aclk400_wcore", "sclk_bpll"};
+PNAME(mout_user_aclk400_wcore_p) = {"fin_pll", "mout_sw_aclk400_wcore"};
+
 PNAME(mout_sw_aclk400_isp_p) = {"dout_aclk400_isp", "mout_sclk_spll"};
 PNAME(mout_user_aclk400_isp_p) = {"fin_pll", "mout_sw_aclk400_isp"};
 
@@ -486,6 +495,18 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_spi0", mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, "mout_spi1", mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, "mout_spi2", mout_group2_p, SRC_PERIC1, 28, 3),
+   MUX(0, "mout_aclk100_noc", mout_group1_p, SRC_TOP0, 20, 2),
+   MUX(0, "mout_sw_aclk100_noc", mout_sw_aclk100_noc_p,
+   SRC_TOP10, 20, 1),
+   MUX(0, "mout_user_aclk100_noc", mout_user_aclk100_noc_p,
+   SRC_TOP3, 20, 1),
+   MUX(0, "mout_aclk400_wcore", mout_group1_p, SRC_TOP0, 16, 2),
+   MUX(0, "mout_aclk400_wcore_bpll", mout_aclk400_wcore_bpll_p,
+   TOP_SPARE2, 4, 1),
+   MUX(0, "mout_sw_aclk400_wcore", mout_sw_aclk400_wcore_p,
+   SRC_TOP10, 16, 1),
+   MUX(0, "mout_user_aclk400_wcore", mout_user_aclk400_wcore_p,
+   SRC_TOP3, 16, 1),
MUX(0, "mout_aclk400_isp", mout_group1_p, SRC_TOP0, 0, 2),
MUX(0, "mout_sw_aclk400_isp", mout_sw_aclk400_isp_p,
SRC_TOP10, 0, 1),
@@ -553,6 +574,10 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, "dout_disp1_blk", "aclk200_disp1", DIV2_RATIO0, 16, 2),
DIV(0, "dout_aclk400_disp1", "mout_aclk400_disp1", DIV_TOP2, 4, 3),
 
+   DIV(0, "dout_aclk100_noc", "mout_aclk100_noc", DIV_TOP0, 20, 3),
+   DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore_bpll",
+   DIV_TOP0, 16, 3),
+
/* Audio Block */
DIV(0, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
DIV(0, "dout_maupcm0", "dout_maudio0", DIV_MAU, 24, 8),
@@ -867,6 +892,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1",
GATE_IP_DISP1, 9, 0, 0),
+   /* aclk266 also gates other IPs in psgen. It should not be gated. */
+   GATE(0, "aclk266", "mout_user_aclk266",
+   GATE_BUS_NOC, 22, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk200_disp1", "mout_user_aclk200_disp1",
GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk300_disp1", "mout_user_aclk300_disp1",
-- 
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 v3 08/16] clk: exynos5420: update clocks for PERIS and GEN blocks

2014-04-24 Thread Shaik Ameer Basha
This patch fixes some parent-child relationships according
to the latest datasheet and adds more clocks related to
PERIS and GEN blocks.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |   70 
 include/dt-bindings/clock/exynos5420.h |5 +++
 2 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index b4cf4c1..6ad87d1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -83,6 +83,7 @@
 #define SCLK_DIV_ISP1  0x10584
 #define DIV2_RATIO00x10590
 #define GATE_BUS_TOP   0x10700
+#define GATE_BUS_GEN   0x1073c
 #define GATE_BUS_FSYS0 0x10740
 #define GATE_BUS_PERIC 0x10750
 #define GATE_BUS_PERIC10x10754
@@ -96,6 +97,7 @@
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
 #define GATE_IP_PERIC  0x10950
+#define GATE_IP_PERIS  0x10960
 #define GATE_IP_MSCL   0x10970
 #define GATE_TOP_SCLK_GSCL 0x10820
 #define GATE_TOP_SCLK_DISP10x10828
@@ -172,6 +174,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP1,
DIV2_RATIO0,
GATE_BUS_TOP,
+   GATE_BUS_GEN,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
@@ -185,6 +188,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_PERIC,
+   GATE_IP_PERIS,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -602,6 +606,10 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
/* MSCL Blk */
DIV(0, "dout_mscl_blk", "aclk400_mscl", DIV2_RATIO0, 28, 2),
 
+   /* PSGEN */
+   DIV(0, "dout_gen_blk", "mout_user_aclk266", DIV2_RATIO0, 8, 1),
+   DIV(0, "dout_jpg_blk", "aclk166", DIV2_RATIO0, 20, 1),
+
/* ISP Block */
DIV(0, "dout_aclk400_isp", "mout_aclk400_isp", DIV_TOP0, 0, 3),
DIV(0, "dout_aclk333_432_isp0", "mout_aclk333_432_isp0",
@@ -620,9 +628,7 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
 };
 
 static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
-   /* TODO: Re-verify the CG bits for all the gate clocks */
-   GATE_A(CLK_MCT, "pclk_st", "aclk66_psgen", GATE_BUS_PERIS1, 2, 0, 0,
-   "mct"),
+   GATE(CLK_MCT, "mct", "aclk66_psgen", GATE_IP_PERIS, 18, 0, 0),
 
GATE(0, "aclk200_fsys", "mout_user_aclk200_fsys",
GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
@@ -769,27 +775,30 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_SPDIF, "spdif", "aclk66_peric", GATE_IP_PERIC, 26, 0, 0),
 
GATE(CLK_CHIPID, "chipid", "aclk66_psgen",
-   GATE_BUS_PERIS0, 12, CLK_IGNORE_UNUSED, 0),
+   GATE_IP_PERIS, 0, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SYSREG, "sysreg", "aclk66_psgen",
-   GATE_BUS_PERIS0, 13, CLK_IGNORE_UNUSED, 0),
-   GATE(CLK_TZPC0, "tzpc0", "aclk66_psgen", GATE_BUS_PERIS0, 18, 0, 0),
-   GATE(CLK_TZPC1, "tzpc1", "aclk66_psgen", GATE_BUS_PERIS0, 19, 0, 0),
-   GATE(CLK_TZPC2, "tzpc2", "aclk66_psgen", GATE_BUS_PERIS0, 20, 0, 0),
-   GATE(CLK_TZPC3, "tzpc3", "aclk66_psgen", GATE_BUS_PERIS0, 21, 0, 0),
-   GATE(CLK_TZPC4, "tzpc4", "aclk66_psgen", GATE_BUS_PERIS0, 22, 0, 0),
-   GATE(CLK_TZPC5, "tzpc5", "aclk66_psgen", GATE_BUS_PERIS0, 23, 0, 0),
-   GATE(CLK_TZPC6, "tzpc6", "aclk66_psgen", GATE_BUS_PERIS0, 24, 0, 0),
-   GATE(CLK_TZPC7, "tzpc7", "aclk66_psgen", GATE_BUS_PERIS0, 25, 0, 0),
-   GATE(CLK_TZPC8, "tzpc8", "aclk66_psgen", GATE_BUS_PERIS0, 26, 0, 0),
-   GATE(CLK_TZPC9, "tzpc9", "aclk66_psgen", GATE_BUS_PERIS0, 27, 0, 0),
-
-   GATE(CLK_HDMI_CEC, "hdmi_cec", "aclk66_psgen", GATE_BUS_PERIS1, 0, 0,
-   0),
+   GATE_IP_PERIS, 1, CLK_IGNORE_UNUSED, 0),
+   GATE(CLK_TZPC0, "tzpc0", "aclk66_psgen", GATE_IP_PERIS, 6, 0, 0),
+   GATE(CLK_TZPC1, "tzpc1", "aclk66_psgen", GATE_IP_PERIS, 7, 0, 0),
+   GATE(CLK_TZPC2, "tzpc2", "aclk66_psgen", GATE_IP_PERIS, 8, 0, 0),
+   GATE(CLK_TZPC3, "tzpc3", "aclk66_psgen", GATE_IP_PERIS, 9, 0, 0),
+   GATE(CLK_TZPC4, "tzpc4", "aclk66_psgen", GATE_IP_PERIS, 10, 0, 0),
+   GATE(CLK_TZPC5, "tzpc5", "aclk66_psgen", GATE_IP_PERIS, 11, 0, 0),
+   GATE(CLK_TZPC6, "tzpc6", "aclk66_psgen", GATE_IP_PERIS, 12, 0, 0),
+   GATE(CLK_TZPC7, "tzpc7", "aclk66_psgen", GATE_IP_PERIS, 13, 0, 0),
+   GATE(CLK_TZPC8, "tzpc8", "aclk66_psgen", GATE_IP_PERIS, 14, 0, 0),
+   GATE(CLK_TZPC9, "tzpc9", "aclk66_psgen", GATE_IP_PERIS, 15, 0, 0),
+
+   /* GATE_IP_PERIS doesn't list TZPC10,11 */
+   GATE(CLK_TZPC10, "tzpc10", "aclk66_psgen", GATE_BUS_GEN, 30, 0, 0

[PATCH v3 07/16] clk: exynos5420: update clocks for PERIC block

2014-04-24 Thread Shaik Ameer Basha
This patch includes,
1] renaming of the HSI2C clocks
2] renaming of spi clocks according to the datasheet
3] fixes for child-parent relationships
4] adding of more clocks related to PERIC block

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 arch/arm/boot/dts/exynos5420.dtsi  |   14 +++---
 drivers/clk/samsung/clk-exynos5420.c   |   73 
 include/dt-bindings/clock/exynos5420.h |   14 +++---
 3 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..67ba2c5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -549,7 +549,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c4_hs_bus>;
-   clocks = <&clock CLK_I2C4>;
+   clocks = <&clock CLK_USI0>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -562,7 +562,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c5_hs_bus>;
-   clocks = <&clock CLK_I2C5>;
+   clocks = <&clock CLK_USI1>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -575,7 +575,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c6_hs_bus>;
-   clocks = <&clock CLK_I2C6>;
+   clocks = <&clock CLK_USI2>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -588,7 +588,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c7_hs_bus>;
-   clocks = <&clock CLK_I2C7>;
+   clocks = <&clock CLK_USI3>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -601,7 +601,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c8_hs_bus>;
-   clocks = <&clock CLK_I2C8>;
+   clocks = <&clock CLK_USI4>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -614,7 +614,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c9_hs_bus>;
-   clocks = <&clock CLK_I2C9>;
+   clocks = <&clock CLK_USI5>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -627,7 +627,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c10_hs_bus>;
-   clocks = <&clock CLK_I2C10>;
+   clocks = <&clock CLK_USI6>;
clock-names = "hsi2c";
status = "disabled";
};
diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index cd75661..b4cf4c1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -95,6 +95,7 @@
 #define GATE_IP_DISP1  0x10928
 #define GATE_IP_G3D0x10930
 #define GATE_IP_GEN0x10934
+#define GATE_IP_PERIC  0x10950
 #define GATE_IP_MSCL   0x10970
 #define GATE_TOP_SCLK_GSCL 0x10820
 #define GATE_TOP_SCLK_DISP10x10828
@@ -183,6 +184,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_DISP1,
GATE_IP_G3D,
GATE_IP_GEN,
+   GATE_IP_PERIC,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -588,9 +590,9 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, "dout_audio2", "mout_audio2", DIV_PERIC3, 28, 4),
 
/* SPI Pre-Ratio */
-   DIV(0, "dout_pre_spi0", "dout_spi0", DIV_PERIC4, 8, 8),
-   DIV(0, "dout_pre_spi1", "dout_spi1", DIV_PERIC4, 16, 8),
-   DIV(0, "dout_pre_spi2", "dout_spi2", DIV_PERIC4, 24, 8),
+   DIV(0, "dout_spi0_pre", "dout_spi0", DIV_PERIC4, 8, 8),
+   DIV(0, "dout_spi1_pre", "dout_spi1", DIV_PERIC4, 16, 8),
+   DIV(0, "dout_spi2_pre", "dout_spi2", DIV_PERIC4, 24, 8),
 
/* GSCL Block */
DIV(0, "dout_gscl_blk_300", "mout_user_aclk300_gscl",
@@ -641,8 +643,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk66_psgen", "mout_aclk66_psgen",
GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
-   GATE(0, "aclk66_peric", "mout_aclk66_peric",
-   GATE_BUS_TOP, 11, 0, 0),
+   GATE(0, "aclk66_peric", "mout_user_aclk66_peric",
+   GATE_BUS_TOP, 11, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk166", "mout_user_aclk166",
GATE_BUS_TOP, 14, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk333", "mout_aclk333",
@@ -657

[PATCH v3 06/16] clk: exynos5420: update clocks for DISP1 block

2014-04-24 Thread Shaik Ameer Basha
This patch corrects some child-parent clock relationships,
and updates the clocks according to the latest datasheet.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |   44 
 include/dt-bindings/clock/exynos5420.h |3 ++-
 2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index ab07299..cd75661 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -61,6 +61,7 @@
 #define SRC_TOP10  0x10280
 #define SRC_TOP11  0x10284
 #define SRC_TOP12  0x10288
+#define SRC_MASK_TOP2  0x10308
 #defineSRC_MASK_DISP10 0x1032c
 #define SRC_MASK_FSYS  0x10340
 #define SRC_MASK_PERIC00x10350
@@ -100,6 +101,7 @@
 #define GATE_TOP_SCLK_MAU  0x1083c
 #define GATE_TOP_SCLK_FSYS 0x10840
 #define GATE_TOP_SCLK_PERIC0x10850
+#define TOP_SPARE2 0x10b08
 #define BPLL_LOCK  0x20010
 #define BPLL_CON0  0x20110
 #define SRC_CDREX  0x20200
@@ -146,6 +148,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SRC_TOP10,
SRC_TOP11,
SRC_TOP12,
+   SRC_MASK_TOP2,
SRC_MASK_DISP10,
SRC_MASK_FSYS,
SRC_MASK_PERIC0,
@@ -186,6 +189,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_MAU,
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
+   TOP_SPARE2,
SRC_CDREX,
SRC_KFC,
DIV_KFC0,
@@ -252,6 +256,7 @@ PNAME(mout_group3_p) = {"mout_sclk_rpll", "mout_sclk_spll"};
 PNAME(mout_group4_p) = {"mout_sclk_ipll", "mout_sclk_dpll", "mout_sclk_mpll"};
 PNAME(mout_group5_p) = {"mout_sclk_vpll", "mout_sclk_dpll"};
 
+PNAME(mout_fimd1_final_p) = {"mout_fimd1", "mout_fimd1_opt"};
 PNAME(mout_sw_aclk66_p)= {"dout_aclk66", "mout_sclk_spll"};
 PNAME(mout_user_aclk66_peric_p) = {"fin_pll", "mout_sw_aclk66"};
 
@@ -271,7 +276,7 @@ PNAME(mout_sw_aclk333_432_isp_p) = {"dout_aclk333_432_isp", 
"mout_sclk_spll"};
 PNAME(mout_user_aclk333_432_isp_p) = {"fin_pll", "mout_sw_aclk333_432_isp"};
 
 PNAME(mout_sw_aclk200_p) = {"dout_aclk200", "mout_sclk_spll"};
-PNAME(mout_aclk200_disp1_p) = {"fin_pll", "mout_sw_aclk200"};
+PNAME(mout_user_aclk200_disp1_p) = {"fin_pll", "mout_sw_aclk200"};
 
 PNAME(mout_sw_aclk400_mscl_p) = {"dout_aclk400_mscl", "mout_sclk_spll"};
 PNAME(mout_user_aclk400_mscl_p)= {"fin_pll", "mout_sw_aclk400_mscl"};
@@ -293,7 +298,9 @@ PNAME(mout_sw_aclk300_gscl_p) = {"dout_aclk300_gscl", 
"mout_sclk_spll"};
 PNAME(mout_user_aclk300_gscl_p)= {"fin_pll", "mout_sw_aclk300_gscl"};
 
 PNAME(mout_sw_aclk300_disp1_p) = {"dout_aclk300_disp1", "mout_sclk_spll"};
+PNAME(mout_sw_aclk400_disp1_p) = {"dout_aclk400_disp1", "mout_sclk_spll"};
 PNAME(mout_user_aclk300_disp1_p) = {"fin_pll", "mout_sw_aclk300_disp1"};
+PNAME(mout_user_aclk400_disp1_p) = {"fin_pll", "mout_sw_aclk400_disp1"};
 
 PNAME(mout_sw_aclk300_jpeg_p) = {"dout_aclk300_jpeg", "mout_sclk_spll"};
 PNAME(mout_user_aclk300_jpeg_p) = {"fin_pll", "mout_sw_aclk300_jpeg"};
@@ -373,7 +380,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
 
MUX(0, "mout_user_aclk400_mscl", mout_user_aclk400_mscl_p,
SRC_TOP3, 4, 1),
-   MUX(0, "mout_aclk200_disp1", mout_aclk200_disp1_p, SRC_TOP3, 8, 1),
+   MUX(0, "mout_user_aclk200_disp1", mout_user_aclk200_disp1_p,
+   SRC_TOP3, 8, 1),
MUX(0, "mout_user_aclk200_fsys2", mout_user_aclk200_fsys2_p,
SRC_TOP3, 12, 1),
MUX(0, "mout_user_aclk200_fsys", mout_user_aclk200_fsys_p,
@@ -443,6 +451,10 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_dp1", mout_group2_p, SRC_DISP10, 20, 3),
MUX(0, "mout_pixel", mout_group2_p, SRC_DISP10, 24, 3),
MUX(CLK_MOUT_HDMI, "mout_hdmi", mout_hdmi_p, SRC_DISP10, 28, 1),
+   MUX_F(0, "mout_fimd1_opt", mout_group2_p,
+   SRC_DISP10, 8, 3, CLK_SET_RATE_PARENT, 0),
+   MUX_F(0, "mout_fimd1_final", mout_fimd1_final_p,
+   TOP_SPARE2, 8, 1, CLK_SET_RATE_PARENT, 0),
 
/* MAU Block */
MUX(0, "mout_maudio0", mout_maudio0_p, SRC_MAU, 28, 3),
@@ -486,6 +498,11 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
SRC_TOP4, 4, 1),
MUX(0, "mout_user_aclk266_isp", mout_user_aclk266_isp_p,
SRC_TOP4, 16, 1),
+   MUX(0, "mout_aclk400_disp1", mout_group1_p, SRC_TOP2, 4, 2),
+   MUX(0, "mout_sw_aclk400_disp1", mout_sw_aclk400_disp1_p,
+   SRC_TOP12, 4, 1),
+   MUX(0, "mout_user_aclk400_disp1", mout_user_aclk400_disp1_p,
+   SRC_TOP5, 0, 1),
 
/* ISP Block */
MUX(0, "mout_pwm_isp", mout_group2_p, SRC_ISP, 24, 3)

[PATCH v3 05/16] clk: exynos5420: update clocks for G2D block

2014-04-24 Thread Shaik Ameer Basha
Addign more G2D block clocks.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |   10 ++
 include/dt-bindings/clock/exynos5420.h |3 +++
 2 files changed, 13 insertions(+)
 mode change 100644 => 100755 include/dt-bindings/clock/exynos5420.h

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 9da85ac..ab07299 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -815,6 +815,10 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_ROTATOR, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
GATE(CLK_JPEG, "jpeg", "aclk300_jpeg", GATE_IP_GEN, 2, 0, 0),
GATE(CLK_JPEG2, "jpeg2", "aclk300_jpeg", GATE_IP_GEN, 3, 0, 0),
+   GATE(CLK_MDMA0, "mdma0", "aclk266_g2d",
+   GATE_IP_G2D, 1, CLK_IGNORE_UNUSED, 0),
+   GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "aclk266_g2d",
+   GATE_IP_G2D, 5, CLK_IGNORE_UNUSED, 0),
GATE(CLK_MDMA1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
GATE(CLK_SMMU_ROTATOR, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
GATE(CLK_SMMU_JPEG, "smmu_jpeg", "aclk300_jpeg", GATE_IP_GEN, 7, 0, 0),
@@ -842,6 +846,11 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
"mout_user_aclk333_432_isp0", GATE_BUS_TOP, 5, 0, 0),
GATE(0, "aclk333_432_isp",
"mout_user_aclk333_432_isp", GATE_BUS_TOP, 8, 0, 0),
+   /* G2D */
+   GATE(CLK_G2D, "g2d", "aclk333_g2d",
+   GATE_IP_G2D, 3, CLK_IGNORE_UNUSED, 0),
+   GATE(CLK_SMMU_G2D, "smmu_g2d", "aclk333_g2d",
+   GATE_IP_G2D, 7, CLK_IGNORE_UNUSED, 0),
/* ISP */
GATE(0, "sclk_pwm_isp", "dout_pwm_isp", GATE_TOP_SCLK_ISP, 3, 0, 0),
GATE(0, "sclk_uart_isp", "dout_uart_isp", GATE_TOP_SCLK_ISP, 0, 0, 0),
@@ -858,6 +867,7 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
 
/* SSS */
GATE(CLK_SSS, "sss", "aclk266_g2d", GATE_IP_G2D, 2, 0, 0),
+   GATE(CLK_SMMU_SSS, "smmu_sss", "aclk266_g2d", GATE_IP_G2D, 6, 0, 0),
 };
 
 static struct samsung_pll_clock exynos5420_plls[nr_plls] __initdata = {
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
old mode 100644
new mode 100755
index 223925f..6631dc1
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -175,6 +175,9 @@
 #define CLK_ACLK_G3D   500
 #define CLK_G3D501
 #define CLK_SMMU_MIXER 502
+#define CLK_SMMU_G2D   503
+#define CLK_SMMU_MDMA0 504
+#define CLK_SMMU_SSS   505
 
 /* mux clocks */
 #define CLK_MOUT_HDMI  640
-- 
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 v3 04/16] clk: exynos5420: correct clock parents for mscl sysmmu

2014-04-24 Thread Shaik Ameer Basha
Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index c3c8ceb..9da85ac 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -579,6 +579,9 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV2_RATIO0, 4, 2),
DIV(0, "dout_gscl_blk_333", "aclk333_432_gscl", DIV2_RATIO0, 6, 2),
 
+   /* MSCL Blk */
+   DIV(0, "dout_mscl_blk", "aclk400_mscl", DIV2_RATIO0, 28, 2),
+
/* ISP Block */
DIV(0, "dout_aclk400_isp", "mout_aclk400_isp", DIV_TOP0, 0, 3),
DIV(0, "dout_aclk333_432_isp0", "mout_aclk333_432_isp0",
@@ -820,12 +823,12 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_MSCL0, "mscl0", "aclk400_mscl", GATE_IP_MSCL, 0, 0, 0),
GATE(CLK_MSCL1, "mscl1", "aclk400_mscl", GATE_IP_MSCL, 1, 0, 0),
GATE(CLK_MSCL2, "mscl2", "aclk400_mscl", GATE_IP_MSCL, 2, 0, 0),
-   GATE(CLK_SMMU_MSCL0, "smmu_mscl0", "aclk400_mscl", GATE_IP_MSCL, 8, 0,
-   0),
-   GATE(CLK_SMMU_MSCL1, "smmu_mscl1", "aclk400_mscl", GATE_IP_MSCL, 9, 0,
-   0),
-   GATE(CLK_SMMU_MSCL2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0,
-   0),
+   GATE(CLK_SMMU_MSCL0, "smmu_mscl0", "dout_mscl_blk",
+   GATE_IP_MSCL, 8, 0, 0),
+   GATE(CLK_SMMU_MSCL1, "smmu_mscl1", "dout_mscl_blk",
+   GATE_IP_MSCL, 9, 0, 0),
+   GATE(CLK_SMMU_MSCL2, "smmu_mscl2", "dout_mscl_blk",
+   GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1", GATE_IP_DISP1, 9, 0,
0),
/* gating of aclk300_gscl causes system hang. It should not be gated. */
-- 
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 v3 03/16] clk: exynos5420: update clocks for GSCL and MSCL blocks

2014-04-24 Thread Shaik Ameer Basha
This patch adds the missing GSCL and MSCL block clocks
and corrects some wrong parent-child relationships.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c   |   41 +---
 include/dt-bindings/clock/exynos5420.h |2 +-
 2 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 972da5d..c3c8ceb 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -80,6 +80,7 @@
 #define DIV_PERIC4 0x10568
 #define SCLK_DIV_ISP0  0x10580
 #define SCLK_DIV_ISP1  0x10584
+#define DIV2_RATIO00x10590
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_FSYS0 0x10740
 #define GATE_BUS_PERIC 0x10750
@@ -165,6 +166,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_PERIC4,
SCLK_DIV_ISP0,
SCLK_DIV_ISP1,
+   DIV2_RATIO0,
GATE_BUS_TOP,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
@@ -572,6 +574,11 @@ static struct samsung_div_clock exynos5420_div_clks[] 
__initdata = {
DIV(0, "dout_pre_spi1", "dout_spi1", DIV_PERIC4, 16, 8),
DIV(0, "dout_pre_spi2", "dout_spi2", DIV_PERIC4, 24, 8),
 
+   /* GSCL Block */
+   DIV(0, "dout_gscl_blk_300", "mout_user_aclk300_gscl",
+   DIV2_RATIO0, 4, 2),
+   DIV(0, "dout_gscl_blk_333", "aclk333_432_gscl", DIV2_RATIO0, 6, 2),
+
/* ISP Block */
DIV(0, "dout_aclk400_isp", "mout_aclk400_isp", DIV_TOP0, 0, 3),
DIV(0, "dout_aclk333_432_isp0", "mout_aclk333_432_isp0",
@@ -666,9 +673,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
GATE(CLK_SCLK_USBD301, "sclk_unipro", "dout_unipro",
SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
 
-   GATE(CLK_SCLK_GSCL_WA, "sclk_gscl_wa", "aclK333_432_gscl",
+   GATE(CLK_SCLK_GSCL_WA, "sclk_gscl_wa", "mout_user_aclk333_432_gscl",
GATE_TOP_SCLK_GSCL, 6, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_SCLK_GSCL_WB, "sclk_gscl_wb", "aclk333_432_gscl",
+   GATE(CLK_SCLK_GSCL_WB, "sclk_gscl_wb", "mout_user_aclk333_432_gscl",
GATE_TOP_SCLK_GSCL, 7, CLK_SET_RATE_PARENT, 0),
 
/* Display */
@@ -766,22 +773,25 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
 
GATE(CLK_GSCL0, "gscl0", "aclk300_gscl", GATE_IP_GSCL0, 0, 0, 0),
GATE(CLK_GSCL1, "gscl1", "aclk300_gscl", GATE_IP_GSCL0, 1, 0, 0),
-   GATE(CLK_CLK_3AA, "clk_3aa", "aclk300_gscl", GATE_IP_GSCL0, 4, 0, 0),
+   GATE(CLK_FIMC_3AA, "fimc_3aa", "aclk333_432_gscl",
+   GATE_IP_GSCL0, 4, 0, 0),
 
-   GATE(CLK_SMMU_3AA, "smmu_3aa", "aclk333_432_gscl", GATE_IP_GSCL1, 2, 0,
-   0),
-   GATE(CLK_SMMU_FIMCL0, "smmu_fimcl0", "aclk333_432_gscl",
+   GATE(CLK_SMMU_3AA, "smmu_3aa", "dout_gscl_blk_333",
+   GATE_IP_GSCL1, 2, 0, 0),
+   GATE(CLK_SMMU_FIMCL0, "smmu_fimcl0", "dout_gscl_blk_333",
GATE_IP_GSCL1, 3, 0, 0),
-   GATE(CLK_SMMU_FIMCL1, "smmu_fimcl1", "aclk333_432_gscl",
+   GATE(CLK_SMMU_FIMCL1, "smmu_fimcl1", "dout_gscl_blk_333",
GATE_IP_GSCL1, 4, 0, 0),
-   GATE(CLK_SMMU_GSCL0, "smmu_gscl0", "aclk300_gscl", GATE_IP_GSCL1, 6, 0,
-   0),
-   GATE(CLK_SMMU_GSCL1, "smmu_gscl1", "aclk300_gscl", GATE_IP_GSCL1, 7, 0,
-   0),
-   GATE(CLK_GSCL_WA, "gscl_wa", "aclk300_gscl", GATE_IP_GSCL1, 12, 0, 0),
-   GATE(CLK_GSCL_WB, "gscl_wb", "aclk300_gscl", GATE_IP_GSCL1, 13, 0, 0),
-   GATE(CLK_SMMU_FIMCL3, "smmu_fimcl3,", "aclk333_432_gscl",
+   GATE(CLK_SMMU_GSCL0, "smmu_gscl0", "dout_gscl_blk_300",
+   GATE_IP_GSCL1, 6, 0, 0),
+   GATE(CLK_SMMU_GSCL1, "smmu_gscl1", "dout_gscl_blk_300",
+   GATE_IP_GSCL1, 7, 0, 0),
+   GATE(CLK_GSCL_WA, "gscl_wa", "sclk_gscl_wa", GATE_IP_GSCL1, 12, 0, 0),
+   GATE(CLK_GSCL_WB, "gscl_wb", "sclk_gscl_wb", GATE_IP_GSCL1, 13, 0, 0),
+   GATE(CLK_SMMU_FIMCL3, "smmu_fimcl3,", "dout_gscl_blk_333",
GATE_IP_GSCL1, 16, 0, 0),
+   GATE(0, "fimc_lite0", "aclk333_432_gscl", GATE_IP_GSCL0, 5, 0, 0),
+   GATE(0, "fimc_lite1", "aclk333_432_gscl", GATE_IP_GSCL0, 6, 0, 0),
GATE(CLK_FIMC_LITE3, "fimc_lite3", "aclk333_432_gscl",
GATE_IP_GSCL1, 17, 0, 0),
 
@@ -818,6 +828,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
__initdata = {
0),
GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1", GATE_IP_DISP1, 9, 0,
0),
+   /* gating of aclk300_gscl causes system hang. It should not be gated. */
+   GATE(CLK_ACLK400_MSCL, "aclk400_mscl", "mout_user_aclk400_mscl",
+   GATE_BUS_TOP, 17, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk266_isp", "mout_us

[PATCH v3 02/16] clk: exynos5420: add clocks for ISP block

2014-04-24 Thread Shaik Ameer Basha
This patch adds missing clocks for ISP block

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |   80 ++
 1 file changed, 80 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 389d4b1..972da5d 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -57,6 +57,7 @@
 #define SRC_FSYS   0x10244
 #define SRC_PERIC0 0x10250
 #define SRC_PERIC1 0x10254
+#define SRC_ISP0x10270
 #define SRC_TOP10  0x10280
 #define SRC_TOP11  0x10284
 #define SRC_TOP12  0x10288
@@ -77,12 +78,15 @@
 #define DIV_PERIC2 0x10560
 #define DIV_PERIC3 0x10564
 #define DIV_PERIC4 0x10568
+#define SCLK_DIV_ISP0  0x10580
+#define SCLK_DIV_ISP1  0x10584
 #define GATE_BUS_TOP   0x10700
 #define GATE_BUS_FSYS0 0x10740
 #define GATE_BUS_PERIC 0x10750
 #define GATE_BUS_PERIC10x10754
 #define GATE_BUS_PERIS00x10760
 #define GATE_BUS_PERIS10x10764
+#define GATE_TOP_SCLK_ISP  0x10870
 #define GATE_IP_GSCL0  0x10910
 #define GATE_IP_GSCL1  0x10920
 #define GATE_IP_MFC0x1092c
@@ -145,6 +149,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SRC_MASK_FSYS,
SRC_MASK_PERIC0,
SRC_MASK_PERIC1,
+   SRC_ISP,
DIV_TOP0,
DIV_TOP1,
DIV_TOP2,
@@ -158,12 +163,15 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_PERIC2,
DIV_PERIC3,
DIV_PERIC4,
+   SCLK_DIV_ISP0,
+   SCLK_DIV_ISP1,
GATE_BUS_TOP,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
GATE_BUS_PERIS1,
+   GATE_TOP_SCLK_ISP,
GATE_IP_GSCL0,
GATE_IP_GSCL1,
GATE_IP_MFC,
@@ -250,6 +258,15 @@ PNAME(mout_user_aclk200_fsys_p)= {"fin_pll", 
"mout_sw_aclk200_fsys"};
 
 PNAME(mout_sw_aclk200_fsys2_p) = {"dout_aclk200_fsys2", "mout_sclk_spll"};
 PNAME(mout_user_aclk200_fsys2_p) = {"fin_pll", "mout_sw_aclk200_fsys2"};
+PNAME(mout_sw_aclk400_isp_p) = {"dout_aclk400_isp", "mout_sclk_spll"};
+PNAME(mout_user_aclk400_isp_p) = {"fin_pll", "mout_sw_aclk400_isp"};
+
+PNAME(mout_sw_aclk333_432_isp0_p) = {"dout_aclk333_432_isp0",
+   "mout_sclk_spll"};
+PNAME(mout_user_aclk333_432_isp0_p) = {"fin_pll", "mout_sw_aclk333_432_isp0"};
+
+PNAME(mout_sw_aclk333_432_isp_p) = {"dout_aclk333_432_isp", "mout_sclk_spll"};
+PNAME(mout_user_aclk333_432_isp_p) = {"fin_pll", "mout_sw_aclk333_432_isp"};
 
 PNAME(mout_sw_aclk200_p) = {"dout_aclk200", "mout_sclk_spll"};
 PNAME(mout_aclk200_disp1_p) = {"fin_pll", "mout_sw_aclk200"};
@@ -265,6 +282,7 @@ PNAME(mout_user_aclk166_p) = {"fin_pll", "mout_sw_aclk166"};
 
 PNAME(mout_sw_aclk266_p) = {"dout_aclk266", "mout_sclk_spll"};
 PNAME(mout_user_aclk266_p) = {"fin_pll", "mout_sw_aclk266"};
+PNAME(mout_user_aclk266_isp_p) = {"fin_pll", "mout_sw_aclk266"};
 
 PNAME(mout_sw_aclk333_432_gscl_p) = {"dout_aclk333_432_gscl", 
"mout_sclk_spll"};
 PNAME(mout_user_aclk333_432_gscl_p) = {"fin_pll", "mout_sw_aclk333_432_gscl"};
@@ -448,6 +466,31 @@ static struct samsung_mux_clock exynos5420_mux_clks[] 
__initdata = {
MUX(0, "mout_spi0", mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, "mout_spi1", mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, "mout_spi2", mout_group2_p, SRC_PERIC1, 28, 3),
+   MUX(0, "mout_aclk400_isp", mout_group1_p, SRC_TOP0, 0, 2),
+   MUX(0, "mout_sw_aclk400_isp", mout_sw_aclk400_isp_p,
+   SRC_TOP10, 0, 1),
+   MUX(0, "mout_user_aclk400_isp", mout_user_aclk400_isp_p,
+   SRC_TOP3, 0, 1),
+   MUX(0, "mout_aclk333_432_isp0", mout_group4_p, SRC_TOP1, 12, 2),
+   MUX(0, "mout_sw_aclk333_432_isp0", mout_sw_aclk333_432_isp0_p,
+   SRC_TOP11, 12, 1),
+   MUX(0, "mout_user_aclk333_432_isp0", mout_user_aclk333_432_isp0_p,
+   SRC_TOP4, 12, 1),
+   MUX(0, "mout_aclk333_432_isp", mout_group4_p,
+   SRC_TOP1, 4, 2),
+   MUX(0, "mout_sw_aclk333_432_isp", mout_sw_aclk333_432_isp_p,
+   SRC_TOP11, 4, 1),
+   MUX(0, "mout_user_aclk333_432_isp", mout_user_aclk333_432_isp_p,
+   SRC_TOP4, 4, 1),
+   MUX(0, "mout_user_aclk266_isp", mout_user_aclk266_isp_p,
+   SRC_TOP4, 16, 1),
+
+   /* ISP Block */
+   MUX(0, "mout_pwm_isp", mout_group2_p, SRC_ISP, 24, 3),
+   MUX(0, "mout_uart_isp", mout_group2_p, SRC_ISP, 20, 3),
+   MUX(0, "mout_spi0_isp", mout_group2_p, SRC_ISP, 12, 3),
+   MUX(0, "mout_spi1_isp", mout_group2_p, SRC_ISP, 16, 3),
+   MUX(0, "mout_isp_sensor", mout_group2_p, SRC_ISP, 28, 3),
 };
 
 static struct samsung_div_clock exynos5420_div_clks[] __initdata = {

[PATCH v3 01/16] clk: exynos5420: rename parent clocks

2014-04-24 Thread Shaik Ameer Basha
This patch modifies the defined parent clock names as per the
exynos5420 datasheet.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5420.c |  359 ++
 1 file changed, 187 insertions(+), 172 deletions(-)
 mode change 100644 => 100755 drivers/clk/samsung/clk-exynos5420.c

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
old mode 100644
new mode 100755
index 35311e1..389d4b1
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -217,85 +217,92 @@ static void exynos5420_clk_sleep_init(void) {}
 #endif
 
 /* list of all parent clocks */
-PNAME(mspll_cpu_p) = { "sclk_cpll", "sclk_dpll",
-   "sclk_mpll", "sclk_spll" };
-PNAME(cpu_p)   = { "mout_apll" , "mout_mspll_cpu" };
-PNAME(kfc_p)   = { "mout_kpll" , "mout_mspll_kfc" };
-PNAME(apll_p)  = { "fin_pll", "fout_apll", };
-PNAME(bpll_p)  = { "fin_pll", "fout_bpll", };
-PNAME(cpll_p)  = { "fin_pll", "fout_cpll", };
-PNAME(dpll_p)  = { "fin_pll", "fout_dpll", };
-PNAME(epll_p)  = { "fin_pll", "fout_epll", };
-PNAME(ipll_p)  = { "fin_pll", "fout_ipll", };
-PNAME(kpll_p)  = { "fin_pll", "fout_kpll", };
-PNAME(mpll_p)  = { "fin_pll", "fout_mpll", };
-PNAME(rpll_p)  = { "fin_pll", "fout_rpll", };
-PNAME(spll_p)  = { "fin_pll", "fout_spll", };
-PNAME(vpll_p)  = { "fin_pll", "fout_vpll", };
-
-PNAME(group1_p)= { "sclk_cpll", "sclk_dpll", "sclk_mpll" };
-PNAME(group2_p)= { "fin_pll", "sclk_cpll", "sclk_dpll", 
"sclk_mpll",
- "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(group3_p)= { "sclk_rpll", "sclk_spll" };
-PNAME(group4_p)= { "sclk_ipll", "sclk_dpll", "sclk_mpll" };
-PNAME(group5_p)= { "sclk_vpll", "sclk_dpll" };
-
-PNAME(sw_aclk66_p) = { "dout_aclk66", "sclk_spll" };
-PNAME(aclk66_peric_p)  = { "fin_pll", "mout_sw_aclk66" };
-
-PNAME(sw_aclk200_fsys_p) = { "dout_aclk200_fsys", "sclk_spll"};
-PNAME(user_aclk200_fsys_p) = { "fin_pll", "mout_sw_aclk200_fsys" };
-
-PNAME(sw_aclk200_fsys2_p) = { "dout_aclk200_fsys2", "sclk_spll"};
-PNAME(user_aclk200_fsys2_p)= { "fin_pll", "mout_sw_aclk200_fsys2" };
-
-PNAME(sw_aclk200_p) = { "dout_aclk200", "sclk_spll"};
-PNAME(aclk200_disp1_p) = { "fin_pll", "mout_sw_aclk200" };
-
-PNAME(sw_aclk400_mscl_p) = { "dout_aclk400_mscl", "sclk_spll"};
-PNAME(user_aclk400_mscl_p) = { "fin_pll", "mout_sw_aclk400_mscl" };
-
-PNAME(sw_aclk333_p) = { "dout_aclk333", "sclk_spll"};
-PNAME(user_aclk333_p)  = { "fin_pll", "mout_sw_aclk333" };
-
-PNAME(sw_aclk166_p) = { "dout_aclk166", "sclk_spll"};
-PNAME(user_aclk166_p)  = { "fin_pll", "mout_sw_aclk166" };
-
-PNAME(sw_aclk266_p) = { "dout_aclk266", "sclk_spll"};
-PNAME(user_aclk266_p)  = { "fin_pll", "mout_sw_aclk266" };
-
-PNAME(sw_aclk333_432_gscl_p) = { "dout_aclk333_432_gscl", "sclk_spll"};
-PNAME(user_aclk333_432_gscl_p) = { "fin_pll", "mout_sw_aclk333_432_gscl" };
-
-PNAME(sw_aclk300_gscl_p) = { "dout_aclk300_gscl", "sclk_spll"};
-PNAME(user_aclk300_gscl_p) = { "fin_pll", "mout_sw_aclk300_gscl" };
-
-PNAME(sw_aclk300_disp1_p) = { "dout_aclk300_disp1", "sclk_spll"};
-PNAME(user_aclk300_disp1_p)= { "fin_pll", "mout_sw_aclk300_disp1" };
-
-PNAME(sw_aclk300_jpeg_p) = { "dout_aclk300_jpeg", "sclk_spll"};
-PNAME(user_aclk300_jpeg_p) = { "fin_pll", "mout_sw_aclk300_jpeg" };
-
-PNAME(sw_aclk_g3d_p) = { "dout_aclk_g3d", "sclk_spll"};
-PNAME(user_aclk_g3d_p) = { "fin_pll", "mout_sw_aclk_g3d" };
-
-PNAME(sw_aclk266_g2d_p) = { "dout_aclk266_g2d", "sclk_spll"};
-PNAME(user_aclk266_g2d_p)  = { "fin_pll", "mout_sw_aclk266_g2d" };
-
-PNAME(sw_aclk333_g2d_p) = { "dout_aclk333_g2d", "sclk_spll"};
-PNAME(user_aclk333_g2d_p)  = { "fin_pll", "mout_sw_aclk333_g2d" };
-
-PNAME(audio0_p)= { "fin_pll", "cdclk0", "sclk_dpll", "sclk_mpll",
- "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(audio1_p)= { "fin_pll", "cdclk1", "sclk_dpll", "sclk_mpll",
- "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(audio2_p)= { "fin_pll", "cdclk2", "sclk_dpll", "sclk_mpll",
- "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(spdif_p) = { "fin_pll", "dout_audio0", "dout_audio1", "dout_audio2",
- "spdif_extclk", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(hdmi_p)  = { "dout_hdmi_pixel", "sclk_hdmiphy" };
-PNAME(maudio0_p)   = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
- "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
+PNAME(mout_mspll_cpu_p) = {"mout_sclk_cpll", "mout_sclk_dpll",
+   "mout_sclk_mpll", "mout_sclk_spll"};
+PNAME(mout_cpu_p) = {"mout_apll" , "mout_mspll_cpu"};
+PNAME(mout_kfc_p) = {"mout_kpll

[PATCH v3 00/16] exynos5420: clock file cleanup

2014-04-24 Thread Shaik Ameer Basha
Many changes/fixes have been identified for clock file for exynos5420.
These include correct parents, bit fields, new clocks etc. Existing
files needs some correction in terms of names of the clock and
indentation. These issues are addressed in this patch series. It also
replaces the usage of enums with macro as clock ids.

This patch series is rebased on,
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master

This patch is also dependent on the following patch.
ARM: dts: add dt node for sss module for exynos5250/5420

Changes since v2:
-
1] Addressed review comments from Gerhard Sittig and Tomasz Figa.

Changes since v1:
-
1] Addressed review comments from Tomasz Figa.
http://www.spinics.net/lists/devicetree/msg16759.html
http://www.spinics.net/lists/devicetree/msg16760.html

Shaik Ameer Basha (16):
  clk: exynos5420: rename parent clocks
  clk: exynos5420: add clocks for ISP block
  clk: exynos5420: update clocks for GSCL and MSCL blocks
  clk: exynos5420: correct clock parents for mscl sysmmu
  clk: exynos5420: update clocks for G2D block
  clk: exynos5420: update clocks for DISP1 block
  clk: exynos5420: update clocks for PERIC block
  clk: exynos5420: update clocks for PERIS and GEN blocks
  clk: exynos5420: update clocks for WCORE block
  clk: exynos5420: update clocks for FSYS and FSYS2 blocks
  clk: exynos5420: correct sysmmu-mfc parent clocks
  clk: exynos5420: fix register offset for sclk_bpll
  clk: exynos5420: cleanup core and misc clocks
  clk: exynos5420: correct g3d parent clock
  clk: exynos5420: create clock ID for mout_sclk_vpll
  clk: exynos5420: add more registers to restore list

 arch/arm/boot/dts/exynos5420.dtsi  |   14 +-
 drivers/clk/samsung/clk-exynos5420.c   |  808 
 include/dt-bindings/clock/exynos5420.h |   33 +-
 3 files changed, 550 insertions(+), 305 deletions(-)
 mode change 100644 => 100755 drivers/clk/samsung/clk-exynos5420.c
 mode change 100644 => 100755 include/dt-bindings/clock/exynos5420.h

-- 
1.7.9.5

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


Re: [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210

2014-04-24 Thread Pankaj Dubey

Hi Vikas,

On 04/24/2014 08:59 PM, Vikas Sajjan wrote:

+Tomasz


On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey  wrote:

This patch adds pmu regnode to exynos4210 dtsi to handle
PMU register access via DT.

Signed-off-by: Pankaj Dubey 
---
  arch/arm/boot/dts/exynos4210.dtsi |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..0a2c0fe 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,11 @@
 interrupts = <2 2>, <3 2>;
 };

+   pmu_system_controller: system-controller@1002 {
+   compatible = "samsung,exynos4210-pmu", "syscon";
+   reg = <0x1002 0x5000>;

Can we have 2 strings as "compatible" and these 2 strings are used by
2 different driver?

Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.

The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled "System Controller
Register R/W Based on Regmap" in menuconfig, I could see PMU driver
[1] is NEVER probed.

Let me know, if I am missing something.

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


You are correct. We also missed this because "SYSCON" option was
not enabled in exynos_defconfig.
I noticed this during preparation of V2 when I planned to use
"early_syscon_init" [1] as suggested by Sylwester here [2].

In V2 I will take care of this. I hope soon I will be able to post second
version of this series, just waiting for testing and internal code review.

[1] https://lkml.org/lkml/2014/4/8/239
[2] https://lkml.org/lkml/2014/4/2/171




+   };
+
 pinctrl_0: pinctrl@1140 {
 compatible = "samsung,exynos4210-pinctrl";
 reg = <0x1140 0x1000>;
--
1.7.10.4


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Best Regards,
Pankaj Dubey

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


Re: [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210

2014-04-24 Thread Vikas Sajjan
+Tomasz


On Wed, Apr 2, 2014 at 1:32 PM, Pankaj Dubey  wrote:
> This patch adds pmu regnode to exynos4210 dtsi to handle
> PMU register access via DT.
>
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/boot/dts/exynos4210.dtsi |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index cacf614..0a2c0fe 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -81,6 +81,11 @@
> interrupts = <2 2>, <3 2>;
> };
>
> +   pmu_system_controller: system-controller@1002 {
> +   compatible = "samsung,exynos4210-pmu", "syscon";
> +   reg = <0x1002 0x5000>;

Can we have 2 strings as "compatible" and these 2 strings are used by
2 different driver?

Because once syscon driver gets probed, exynos-pmu.c [1] driver will
never be probed.

The new PMU driver [1] completely relies on this. With just
exynos_defconfig, you will not notice this issue, since syscon is NOT
enabled by exynos_defconfig. When I enabled "System Controller
Register R/W Based on Regmap" in menuconfig, I could see PMU driver
[1] is NEVER probed.

Let me know, if I am missing something.

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


> +   };
> +
> pinctrl_0: pinctrl@1140 {
> compatible = "samsung,exynos4210-pinctrl";
> reg = <0x1140 0x1000>;
> --
> 1.7.10.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] thermal: samsung: Only update available threshold limits

2014-04-24 Thread Tushar Behera
On 04/24/2014 04:18 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Monday, April 14, 2014 11:08:15 AM Tushar Behera wrote:
>> Currently the threshold limits are updated in 2 stages, once for all
>> software trigger levels and again for hardware trip point.
>>
>> While updating the software trigger levels, it overwrites the threshold
>> limit for hardware trip point thereby forcing the Exynos core to issue
>> an emergency shutdown.
> 
> On what SoC type have you encountered this problem?  It doesn't seem to
> happen on older SoCs (at least Exynos4210 and Exynos4x12 ones).
> 

I found this issue while testing on Exynos5420 with these patches [1].

[1] https://lkml.org/lkml/2013/8/1/38

>> Updating only the required fields in threshold register fixes this issue.
> 
> With the current code there is indeed a time window during which threshold
> limit for hardware trip point is set to zero so the fix is correct.
> 


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


Re: [PATCH 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Am Donnerstag, 24. April 2014, 11:34:55 schrieb Russell King - ARM Linux:
> On Thu, Apr 24, 2014 at 12:24:31PM +0200, Heiko Stübner wrote:
> > +choice
> > +   prompt "S3C24XX low-level debugging port type"
> > +   depends on DEBUG_LL && ARCH_S3C24XX
> > +
> > +   config DEBUG_S3C24XX_UART_S3C2440
> > +   bool "S3C2440 uart type"
> > +   help
> > + Select this if you're debugging S3C2416, S3C2440, S3C2442,
> > + S3C2443 or S3C2450 SoCs.
> > +
> > +   config DEBUG_S3C24XX_UART_S3C2410
> > +   bool "S3C2410 uart type"
> > +   help
> > + Select this if you're debugging S3C2410 or S3C2412 SoCs.
> > +endchoice
> 
> Why does this need to be a separate choice statement?  What's special
> about S3C24XX?  Is there something wrong with the main choice statement
> just above this where everyone else lists their debugging UART?

The special case is that s3c24xx as architecture has two different uart types. 
Everything else is the same so I didn't want to duplicate the s3c_debug_uartX 
entries.

The other option would have been to duplicate these, like having

- s3c_debug_uart[0-3] for the more common s3c2440 type and
- s3c2410_debug_uart[0-3] for the named type

I guess, judging from your comment this would be better?
[or I'm just overlooking the obvious third way :-) ]


Heiko
--
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: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tushar Behera
On 04/24/2014 03:36 PM, Tomasz Figa wrote:
> On 24.04.2014 11:07, Tushar Behera wrote:
>> On 04/23/2014 03:43 PM, Kukjin Kim wrote:
>>> Tushar Behera wrote:

 On 22 April 2014 13:08, Alim Akhtar  wrote:
> Hi Tushar
>
> On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
>  wrote:
>> MAU powerdomain provides clocks for Audio sub-system block. This
>> block
>> comprises of the I2S audio controller, audio DMA blocks and Audio
>> sub-system clock registers.
>>
>> Right now, there is no way to hook up power-domains with clock
 providers.
>> During late boot when this power-domain gets disabled, we get
>> following
>> external abort.
>>>
>>> + Jonghwan Choi
>>>
>>> Well, this is not a perfect solution to support MAU power domain,
>>> it's true it is a problem right now though.
>>>
>>> In other words, this is just temporal fix for the problem.
>>>
>>> How about accessing clock stuff for audio sub-system with handling
>>> MAU power domain via generic IO power domain?
>>>
>>
>> + Tomasz Figa
>>
>> Existing power domain driver exynos4_pm_init_power_domain is registered
>> with an arch_initcall whereas the clk-exynos-audss driver is registered
>> with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
>> node, the binding with power-domain doesn't happen.
> 
> I'd say core_initcall is way too early for clk-exynos-audss driver. It
> should be at most subsys_initcall. As far as I can see, all users of
> clocks provided by this driver (i.e. i2s) are probed at device_initcall
> level anyway.
> 

It is also used by ADMA node, which gets probed.

>>
>> Alternately, if Tomasz's patches are applied [1], power-domain binding
>> is successful. But because of the init order, clk-exynos-audss defers
>> probe resulting in a kernel crash. Forcing clk-exynos-audss to register
>> through arch_initcall() fixes this issue, but I am not sure if that is
>> okay.
> 
> If the driver crashes on deferred probe, then it's a bug and it should
> be fixed.
> 

By the time clk-exynos-audss is getting called, mau_pd is already
disabled by power-domain driver. That is not getting enabled during
clk-exynos-audss probe. Am I missing something?


> Best regards,
> Tomasz


-- 
Tushar Behera
--
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] thermal: samsung: Only update available threshold limits

2014-04-24 Thread Bartlomiej Zolnierkiewicz

Hi,

On Monday, April 14, 2014 11:08:15 AM Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
> 
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.

On what SoC type have you encountered this problem?  It doesn't seem to
happen on older SoCs (at least Exynos4210 and Exynos4x12 ones).

> Updating only the required fields in threshold register fixes this issue.

With the current code there is indeed a time window during which threshold
limit for hardware trip point is set to zero so the fix is correct.

> Signed-off-by: Tushar Behera 
> ---
> Based on v3.15-rc1.
> 
>  drivers/thermal/samsung/exynos_tmu.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
>   trigger_levs++;
>   }
>  
> + rising_threshold = readl(data->base + reg->threshold_th0);

You may move this inside "} else {" block as rising_threshold
is not used for data->soc == SOC_ARCH_EXYNOS4210 case.

Also rising_threshold initialization to zero at the beginning of
exynos_tmu_initialize() is not needed anylonger.

> +
>   if (data->soc == SOC_ARCH_EXYNOS4210) {
>   /* Write temperature code for threshold */
>   threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
>   ret = threshold_code;
>   goto out;
>   }
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   if (pdata->threshold_falling) {
>   threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
>   }
>   if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
>   /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
>   rising_threshold |= threshold_code << 8 * i;
>   writel(rising_threshold,
>   data->base + reg->threshold_th0);

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

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


Re: [PATCH 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Russell King - ARM Linux
On Thu, Apr 24, 2014 at 12:24:31PM +0200, Heiko Stübner wrote:
> +choice
> + prompt "S3C24XX low-level debugging port type"
> + depends on DEBUG_LL && ARCH_S3C24XX
> +
> + config DEBUG_S3C24XX_UART_S3C2440
> + bool "S3C2440 uart type"
> + help
> +   Select this if you're debugging S3C2416, S3C2440, S3C2442,
> +   S3C2443 or S3C2450 SoCs.
> +
> + config DEBUG_S3C24XX_UART_S3C2410
> + bool "S3C2410 uart type"
> + help
> +   Select this if you're debugging S3C2410 or S3C2412 SoCs.
> +endchoice

Why does this need to be a separate choice statement?  What's special
about S3C24XX?  Is there something wrong with the main choice statement
just above this where everyone else lists their debugging UART?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from 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


Re: [PATCH 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Leela Krishna Amudala
Hi Abhilash,

If you are okay with this patchset you can rebase/merge it with your
mcpm patches.

Best Wishes,
Leela Krishna.

On Thu, Apr 24, 2014 at 3:24 PM, Daniel Lezcano
 wrote:
>
> Hi Abhilash and Leela,
>
> FYI I think you are working on similar patches.
>
>
> On 04/24/2014 11:31 AM, Leela Krishna Amudala wrote:
>> This patchset adds the generic cpu power control functions for
>>
>> exynos based SoCs to power up/down and to know the status of the cpu.
>>
>> Note: This series has been rebased on 3.15-rc1 and tested on
>> Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.
>>
>> Leela Krishna Amudala (2):
>>ARM: EXYNOS: Add generic cpu power control functions for all exynos
>>  based SoCs
>>ARM: EXYNOS: use generic exynos cpu power control functions
>>
>>   arch/arm/mach-exynos/common.h   |3 +++
>>   arch/arm/mach-exynos/platsmp.c  |9 +++--
>>   arch/arm/mach-exynos/pm.c   |   36
>> 
>>   arch/arm/mach-exynos/regs-pmu.h |6 ++
>>   4 files changed, 48 insertions(+), 6 deletions(-)
>>
>
>
> --
>   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


[PATCH 3/4] ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro

2014-04-24 Thread Heiko Stübner
This removes the need for mach/-headers in the debug macro.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 19 +--
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S |  9 ++---
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 43b94a9..2476f84 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -625,6 +625,7 @@ choice
config DEBUG_S3C_UART0
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 0 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -637,6 +638,7 @@ choice
config DEBUG_S3C_UART1
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 1 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -649,6 +651,7 @@ choice
config DEBUG_S3C_UART2
depends on PLAT_SAMSUNG
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 2 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -661,6 +664,7 @@ choice
config DEBUG_S3C_UART3
depends on PLAT_SAMSUNG && ARCH_EXYNOS
select DEBUG_EXYNOS_UART
+   select DEBUG_S3C24XX_UART if ARCH_S3C24XX
bool "Use S3C UART 3 for low-level debug"
help
  Say Y here if you want the debug print routines to direct
@@ -937,6 +941,9 @@ endchoice
 config DEBUG_EXYNOS_UART
bool
 
+config DEBUG_S3C24XX_UART
+   bool
+
 config DEBUG_OMAP2PLUS_UART
bool
depends on ARCH_OMAP2PLUS
@@ -1045,6 +1052,10 @@ config DEBUG_UART_PHYS
default 0x4009 if ARCH_LPC32XX
default 0x4010 if DEBUG_PXA_UART1
default 0x4200 if ARCH_GEMINI
+   default 0x5000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART0
+   default 0x50004000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART1
+   default 0x50008000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART2
+   default 0x5000C000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART3
default 0x7c0003f8 if FOOTBRIDGE
default 0x8023 if DEBUG_PICOXCELL_UART
default 0x8007 if DEBUG_IMX23_UART
@@ -1074,7 +1085,7 @@ config DEBUG_UART_PHYS
default 0xf700 if ARCH_IOP33X
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_LL_UART_EFM32 || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
@@ -1091,6 +1102,10 @@ config DEBUG_UART_VIRT
default 0xf210 if DEBUG_PXA_UART1
default 0xf409 if ARCH_LPC32XX
default 0xf420 if ARCH_GEMINI
+   default 0xf700 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART0
+   default 0xf7004000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART1
+   default 0xf7008000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART2
+   default 0xf700c000 if DEBUG_S3C24XX_UART && DEBUG_S3C_UART3
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
default 0xf809 if DEBUG_VEXPRESS_UART0_RS1
@@ -1132,7 +1147,7 @@ config DEBUG_UART_VIRT
default 0xff003000 if DEBUG_U300_UART
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
-   DEBUG_UART_8250 || DEBUG_UART_PL01X
+   DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_S3C24XX_UART
 
 config DEBUG_UART_8250_SHIFT
int "Register offset shift for the 8250 debug UART"
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 3077a5f..5b165d8 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -12,18 +12,13 @@
  * published by the Free Software Foundation.
 */
 
-#include 
 #include 
 
 #define S3C2410_UART1_OFF (0x4000)
 
.macro addruart, rp, rv, tmp
-   ldr \rp, = S3C24XX_PA_UART
-   ldr \rv, = S3C24XX_VA_UART
-#if CONFIG_DEBUG_S3C_UART != 0
-   add \rp, \rp, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-   add \rv, \rv, #(S3C2410_UART1_OFF * CONFIG_DEBUG_S3C_UART)
-#endif
+   ldr \rp, = CONFIG_DEBUG_UART_PHYS
+   ldr \rv, = CONFIG_DEBUG_UART_VIRT
.endm
 
.macro  fifo_full_s3c2410 rd, rx
-- 
1.9.0


--
To

[PATCH 4/4] ARM: S3C24XX: move debug-macro.S into the common space

2014-04-24 Thread Heiko Stübner
Move debug-macro.S from mach/include to include/debug where all other common
debug macros are.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 1 +
 .../{mach-s3c24xx/include/mach/debug-macro.S => include/debug/s3c24xx.S} | 0
 2 files changed, 1 insertion(+)
 rename arch/arm/{mach-s3c24xx/include/mach/debug-macro.S => 
include/debug/s3c24xx.S} (100%)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 2476f84..00d3ee6 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -996,6 +996,7 @@ config DEBUG_LL_INCLUDE
 DEBUG_IMX6SL_UART
default "debug/msm.S" if DEBUG_MSM_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
+   default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || 
DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
default "debug/tegra.S" if DEBUG_TEGRA_UART
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/include/debug/s3c24xx.S
similarity index 100%
rename from arch/arm/mach-s3c24xx/include/mach/debug-macro.S
rename to arch/arm/include/debug/s3c24xx.S
-- 
1.9.0


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


[PATCH 2/4] ARM: S3C24XX: trim down debug uart handling

2014-04-24 Thread Heiko Stübner
Using the lowlevel debug uart is a corner case - even more so in a
multiplatform environment. So it seems reasonable to simply let the
developer set the appropriate uart type for the debugged SoC.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/Kconfig.debug   | 16 
 arch/arm/mach-s3c24xx/Kconfig| 28 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 52 +---
 3 files changed, 17 insertions(+), 79 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4a2fc0b..43b94a9 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -918,6 +918,22 @@ choice
 
 endchoice
 
+choice
+   prompt "S3C24XX low-level debugging port type"
+   depends on DEBUG_LL && ARCH_S3C24XX
+
+   config DEBUG_S3C24XX_UART_S3C2440
+   bool "S3C2440 uart type"
+   help
+ Select this if you're debugging S3C2416, S3C2440, S3C2442,
+ S3C2443 or S3C2450 SoCs.
+
+   config DEBUG_S3C24XX_UART_S3C2410
+   bool "S3C2410 uart type"
+   help
+ Select this if you're debugging S3C2410 or S3C2412 SoCs.
+endchoice
+
 config DEBUG_EXYNOS_UART
bool
 
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 40cf50b..98d17af 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -26,7 +26,6 @@ config CPU_S3C2410
bool "SAMSUNG S3C2410"
default y
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
@@ -39,7 +38,6 @@ config CPU_S3C2410
 config CPU_S3C2412
bool "SAMSUNG S3C2412"
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2412_DMA if S3C24XX_DMA
select S3C2412_PM if PM
help
@@ -48,7 +46,6 @@ config CPU_S3C2412
 config CPU_S3C2416
bool "SAMSUNG S3C2416/S3C2450"
select CPU_ARM926T
-   select CPU_LLSERIAL_S3C2440
select S3C2416_PM if PM
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
@@ -59,7 +56,6 @@ config CPU_S3C2416
 config CPU_S3C2440
bool "SAMSUNG S3C2440"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
@@ -69,7 +65,6 @@ config CPU_S3C2440
 config CPU_S3C2442
bool "SAMSUNG S3C2442"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2410_CLOCK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
@@ -84,7 +79,6 @@ config CPU_S3C244X
 config CPU_S3C2443
bool "SAMSUNG S3C2443"
select CPU_ARM920T
-   select CPU_LLSERIAL_S3C2440
select S3C2443_COMMON
select S3C2443_DMA if S3C24XX_DMA
select SAMSUNG_CLKSRC
@@ -158,28 +152,6 @@ config S3C2410_PM
help
  Power Management code common to S3C2410 and better
 
-# low-level serial option nodes
-
-config CPU_LLSERIAL_S3C2410_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2410 && !CPU_LLSERIAL_S3C2440
-
-config CPU_LLSERIAL_S3C2440_ONLY
-   bool
-   default y if CPU_LLSERIAL_S3C2440 && !CPU_LLSERIAL_S3C2410
-
-config CPU_LLSERIAL_S3C2410
-   bool
-   help
- Selected if there is an S3C2410 (or register compatible) serial
- low-level implementation needed
-
-config CPU_LLSERIAL_S3C2440
-   bool
-   help
- Selected if there is an S3C2440 (or register compatible) serial
- low-level implementation needed
-
 config S3C24XX_PLL
bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
depends on ARM_S3C24XX_CPUFREQ
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S 
b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 2f39737..3077a5f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -13,11 +13,9 @@
 */
 
 #include 
-#include 
 #include 
 
 #define S3C2410_UART1_OFF (0x4000)
-#define SHIFT_2440TXF (14-9)
 
.macro addruart, rp, rv, tmp
ldr \rp, = S3C24XX_PA_UART
@@ -28,56 +26,11 @@
 #endif
.endm
 
-   .macro fifo_full_s3c24xx rd, rx
-   @ check for arm920 vs arm926. currently assume all arm926
-   @ devices have an 64 byte FIFO identical to the s3c2440
-   mrc p15, 0, \rd, c0, c0
-   and \rd, \rd, #0xff0
-   teq \rd, #0x260
-   beq 1004f
-   mrc p15, 0, \rd, c1, c0
-   tst \rd, #1
-   addeq   \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
-   addne   \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
-   bic \rd, \rd, #0xff000
-   ldr \rd, [\rd, # S3C2410_GSTATUS1 - 

[PATCH 1/4] ARM: compressed/head.S: remove s3c24xx special case

2014-04-24 Thread Heiko Stübner
addruart from the generic debug macro is doing exactly the same using
the common lowlevel uart definition, so there is no cause for this
special casing for s3c24xx.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/compressed/head.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 066b034..3a8b32d 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -60,11 +60,6 @@
add \rb, \rb, #0x0001   @ Ser1
 #endif
.endm
-#elif defined(CONFIG_ARCH_S3C24XX)
-   .macro loadsp, rb, tmp
-   mov \rb, #0x5000
-   add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
-   .endm
 #else
.macro  loadsp, rb, tmp
addruart \rb, \tmp
-- 
1.9.0


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


[PATCH 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

2014-04-24 Thread Heiko Stübner
This series tries to simplify the s3c24xx debug macro, removing dependencies
on mach/ includes, static mappings and finally moving it into include/debug.

The one slightly invasive change is the need for the developer to select
the uart type by himself, which gets rid of the debug macro trying to
determine the uart type itself.

But as usage of the debug-uart is not the common case - especially in a
multiplatform scenario - I didn't worry to much.

Based on 3.15-rc1 and tested on a S3C2442 Openmoko Freerunner (GTA02)


Heiko Stuebner (4):
  ARM: compressed/head.S: remove s3c24xx special case
  ARM: S3C24XX: trim down debug uart handling
  ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
  ARM: S3C24XX: move debug-macro.S into the common space

 arch/arm/Kconfig.debug   |  36 +++-
 arch/arm/boot/compressed/head.S  |   5 --
 arch/arm/include/debug/s3c24xx.S |  46 +++
 arch/arm/mach-s3c24xx/Kconfig|  28 ---
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 ---
 5 files changed, 80 insertions(+), 136 deletions(-)
 create mode 100644 arch/arm/include/debug/s3c24xx.S
 delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S

-- 
1.9.0


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


Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tomasz Figa

On 24.04.2014 11:07, Tushar Behera wrote:

On 04/23/2014 03:43 PM, Kukjin Kim wrote:

Tushar Behera wrote:


On 22 April 2014 13:08, Alim Akhtar  wrote:

Hi Tushar

On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
 wrote:

MAU powerdomain provides clocks for Audio sub-system block. This block
comprises of the I2S audio controller, audio DMA blocks and Audio
sub-system clock registers.

Right now, there is no way to hook up power-domains with clock

providers.

During late boot when this power-domain gets disabled, we get following
external abort.


+ Jonghwan Choi

Well, this is not a perfect solution to support MAU power domain, it's true it 
is a problem right now though.

In other words, this is just temporal fix for the problem.

How about accessing clock stuff for audio sub-system with handling MAU power 
domain via generic IO power domain?



+ Tomasz Figa

Existing power domain driver exynos4_pm_init_power_domain is registered
with an arch_initcall whereas the clk-exynos-audss driver is registered
with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
node, the binding with power-domain doesn't happen.


I'd say core_initcall is way too early for clk-exynos-audss driver. It 
should be at most subsys_initcall. As far as I can see, all users of 
clocks provided by this driver (i.e. i2s) are probed at device_initcall 
level anyway.




Alternately, if Tomasz's patches are applied [1], power-domain binding
is successful. But because of the init order, clk-exynos-audss defers
probe resulting in a kernel crash. Forcing clk-exynos-audss to register
through arch_initcall() fixes this issue, but I am not sure if that is okay.


If the driver crashes on deferred probe, then it's a bug and it should 
be fixed.


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 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Daniel Lezcano


Hi Abhilash and Leela,

FYI I think you are working on similar patches.

On 04/24/2014 11:31 AM, Leela Krishna Amudala wrote:
> This patchset adds the generic cpu power control functions for

exynos based SoCs to power up/down and to know the status of the cpu.

Note: This series has been rebased on 3.15-rc1 and tested on
Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.

Leela Krishna Amudala (2):
   ARM: EXYNOS: Add generic cpu power control functions for all exynos
 based SoCs
   ARM: EXYNOS: use generic exynos cpu power control functions

  arch/arm/mach-exynos/common.h   |3 +++
  arch/arm/mach-exynos/platsmp.c  |9 +++--
  arch/arm/mach-exynos/pm.c   |   36 
  arch/arm/mach-exynos/regs-pmu.h |6 ++
  4 files changed, 48 insertions(+), 6 deletions(-)




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


[PATCH 1/2] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs

2014-04-24 Thread Leela Krishna Amudala
Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.

Signed-off-by: Leela Krishna Amudala 
---
 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/pm.c   |   36 
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 3 files changed, 45 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83..566f222 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -62,5 +62,8 @@ struct exynos_pmu_conf {
 };
 
 extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_cpu_powerdown(int cpu);
+extern void exynos_cpu_powerup(int cpu);
+extern int  exynos_cpu_power_state(int cpu);
 
 #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..6651028 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -100,6 +100,42 @@ static int exynos_irq_set_wake(struct irq_data *data, 
unsigned int state)
return -ENOENT;
 }
 
+/**
+ * exynos_cpu_powerdown : power down the specified cpu
+ * @cpu : the cpu to power down
+ *
+ * Power downs the specified cpu. The sequence must be finished by a
+ * call to cpu_do_idle()
+ *
+ */
+void exynos_cpu_powerdown(int cpu)
+{
+   __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_powerup : power up the specified cpu
+ * @cpu : the cpu to power up
+ *
+ * Power up the specified cpu
+ */
+void exynos_cpu_powerup(int cpu)
+{
+   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_state : returns the power state of the cpu
+ * @cpu : the cpu to retrieve the power state from
+ *
+ */
+int exynos_cpu_power_state(int cpu)
+{
+   return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu)) &
+   S5P_CORE_LOCAL_PWR_EN);
+}
+
 /* For Cortex-A9 Diagnostic and Power control register */
 static unsigned int save_arm_register[2];
 
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..0bdfcbc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -121,6 +121,12 @@
 
 #define S5P_CHECK_SLEEP0x0BAD
 
+#define EXYNOS_ARM_CORE0_CONFIGURATION S5P_PMUREG(0x2000)
+#define EXYNOS_ARM_CORE_CONFIGURATION(_nr) \
+   (EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_ARM_CORE_STATUS(_nr)\
+   (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+
 /* Only for EXYNOS4210 */
 #define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
 #define S5P_CMU_RESET_LCD1_LOWPWR  S5P_PMUREG(0x1174)
-- 
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 0/2] Add generic cpu power control functions for exynos

2014-04-24 Thread Leela Krishna Amudala
This patchset adds the generic cpu power control functions for
exynos based SoCs to power up/down and to know the status of the cpu.

Note: This series has been rebased on 3.15-rc1 and tested on 
Exynos based Origen(Cortex-A9) and Arndale-octa(Cortex A7,A15) boards.

Leela Krishna Amudala (2):
  ARM: EXYNOS: Add generic cpu power control functions for all exynos
based SoCs
  ARM: EXYNOS: use generic exynos cpu power control functions

 arch/arm/mach-exynos/common.h   |3 +++
 arch/arm/mach-exynos/platsmp.c  |9 +++--
 arch/arm/mach-exynos/pm.c   |   36 
 arch/arm/mach-exynos/regs-pmu.h |6 ++
 4 files changed, 48 insertions(+), 6 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 2/2] ARM: EXYNOS: use generic exynos cpu power control functions

2014-04-24 Thread Leela Krishna Amudala
Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu.

Signed-off-by: Leela Krishna Amudala 
---
 arch/arm/mach-exynos/platsmp.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f..e3d005b 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -107,15 +107,12 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);
 
-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
-   __raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
-
+   if (!exynos_cpu_power_state(cpu)) {
+   exynos_cpu_powerup(cpu);
timeout = 10;
 
/* wait max 10 ms until cpu1 is on */
-   while ((__raw_readl(S5P_ARM_CORE1_STATUS)
-   & S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
+   while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
 
-- 
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: register sched_clock callback

2014-04-24 Thread Vincent Guittot
Use the clocksource mct-frc for sched_clock

Signed-off-by: Vincent Guittot 
---
 drivers/clocksource/exynos_mct.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index a6ee6d7..61b0577 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define EXYNOS4_MCTREG(x)  (x)
 #define EXYNOS4_MCT_G_CNT_LEXYNOS4_MCTREG(0x100)
@@ -192,12 +193,19 @@ struct clocksource mct_frc = {
.resume = exynos4_frc_resume,
 };
 
+static u64 notrace exynos4_read_sched_clock(void)
+{
+   return exynos4_frc_read(&mct_frc);
+}
+
 static void __init exynos4_clocksource_init(void)
 {
exynos4_mct_frc_start(0, 0);
 
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
+
+   sched_clock_register(exynos4_read_sched_clock, 64, clk_rate);
 }
 
 static void exynos4_mct_comp0_stop(void)
-- 
1.9.1

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


Re: [PATCH] mmc: dw_mmc: Don't print data errors

2014-04-24 Thread Ulf Hansson
>> The "status" here could be useful information about the status
>> register, which is not considered while printing errors by the "higher
>> levels". An option could be to print the error, but not when you
>> perform tuning.
>>
>> No big deal though, just a thought.
>
> Right, I could potentially put the driver into "tuning" mode and then
> suppress the errors during that time.  If you request it I will do
> that.
>
> I will also note that there are many other error conditions in the
> driver that don't have such printouts.  I think the general philosophy
> of this driver is not to print them...

So, then let's stick to that philosophy and keep this as is.

Kind regards
Ulf Hansson

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


Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420

2014-04-24 Thread Tushar Behera
On 04/23/2014 03:43 PM, Kukjin Kim wrote:
> Tushar Behera wrote:
>>
>> On 22 April 2014 13:08, Alim Akhtar  wrote:
>>> Hi Tushar
>>>
>>> On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
>>>  wrote:
 MAU powerdomain provides clocks for Audio sub-system block. This block
 comprises of the I2S audio controller, audio DMA blocks and Audio
 sub-system clock registers.

 Right now, there is no way to hook up power-domains with clock
>> providers.
 During late boot when this power-domain gets disabled, we get following
 external abort.
> 
> + Jonghwan Choi
> 
> Well, this is not a perfect solution to support MAU power domain, it's true 
> it is a problem right now though.
> 
> In other words, this is just temporal fix for the problem.
> 
> How about accessing clock stuff for audio sub-system with handling MAU power 
> domain via generic IO power domain?
> 

+ Tomasz Figa

Existing power domain driver exynos4_pm_init_power_domain is registered
with an arch_initcall whereas the clk-exynos-audss driver is registered
with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
node, the binding with power-domain doesn't happen.

Alternately, if Tomasz's patches are applied [1], power-domain binding
is successful. But because of the init order, clk-exynos-audss defers
probe resulting in a kernel crash. Forcing clk-exynos-audss to register
through arch_initcall() fixes this issue, but I am not sure if that is okay.

[1] http://www.spinics.net/lists/kernel/msg1728566.html

>>> ?? which abort?? Can you please mention it here?

>>
>> Thanks Alim for spotting this ... I somehow missed adding this.
>>
>> 
>> Unhandled fault: imprecise external abort (0x1406) at 0x
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007
>>
>>
>> Kukjin,
>>
>> Let me know if I need to resend the patch.
> 
> - Kukjin
> 


-- 
Tushar Behera
--
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: exynos_defconfig: Enable HS-I2C

2014-04-24 Thread Tushar Behera
On 03/04/2014 05:52 PM, Sachin Kamat wrote:
> High speed I2C is used on Exynos5 based SoCs. Enable it.
> 
> Signed-off-by: Sachin Kamat 
> ---
>  arch/arm/configs/exynos_defconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index 4ce7b70ea901..e07a227ec0db 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -65,6 +65,7 @@ CONFIG_TCG_TIS_I2C_INFINEON=y
>  CONFIG_I2C=y
>  CONFIG_I2C_MUX=y
>  CONFIG_I2C_ARB_GPIO_CHALLENGE=y
> +CONFIG_I2C_EXYNOS5=y
>  CONFIG_I2C_S3C2410=y
>  CONFIG_DEBUG_GPIO=y
>  # CONFIG_HWMON is not set
> 
Kukjin,

Please consider picking this patch when you plan to update
exynos_defconfig. With this change on upstream kernel, we are able to
get Arndale_Octa board to boot and mount an MMC partition successfully.

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


  1   2   >