Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
2015-12-23 19:54 GMT+09:00 Tomasz Figa <tomasz.f...@gmail.com>:
> Hi,
>
> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>>> Hi Kukjin,
>>>>
>>>> Pinctrl for v4.5.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>>
>>>> The following changes since commit 
>>>> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>>
>>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>>> tags/samsung-drivers-4.5
>>>>
>>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>>
>>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>>> +0900)
>>>
>>> Hi,
>>>
>>> This should either go in through the pinctrl tree, or have an 
>>> acked/reviewed-by
>>> one of the pinctrl maintainers.
>>
>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>> https://patchwork.ozlabs.org/patch/450340/
>
> Actually, is there any reason to send this through ARM SoC? Looks like
> this pull request contains only pinctrl changes which could normally
> go through pinctrl tree. Maybe Linus W. could simply pull it?

Except that his email address was mistyped in original message... Fixed now.

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: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
Hi,

2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>> Hi Kukjin,
>>>
>>> Pinctrl for v4.5.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>
>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>> tags/samsung-drivers-4.5
>>>
>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>
>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>> +0900)
>>
>> Hi,
>>
>> This should either go in through the pinctrl tree, or have an 
>> acked/reviewed-by
>> one of the pinctrl maintainers.
>
> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
> https://patchwork.ozlabs.org/patch/450340/

Actually, is there any reason to send this through ARM SoC? Looks like
this pull request contains only pinctrl changes which could normally
go through pinctrl tree. Maybe Linus W. could simply pull 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: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
2015-12-23 19:58 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
> W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
>> Hi,
>>
>> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
>>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>>>> Hi Kukjin,
>>>>>
>>>>> Pinctrl for v4.5.
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>>
>>>>> The following changes since commit 
>>>>> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>>>
>>>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>>>> tags/samsung-drivers-4.5
>>>>>
>>>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>>>
>>>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>>>> +0900)
>>>>
>>>> Hi,
>>>>
>>>> This should either go in through the pinctrl tree, or have an 
>>>> acked/reviewed-by
>>>> one of the pinctrl maintainers.
>>>
>>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>>> https://patchwork.ozlabs.org/patch/450340/
>>
>> Actually, is there any reason to send this through ARM SoC? Looks like
>> this pull request contains only pinctrl changes which could normally
>> go through pinctrl tree. Maybe Linus W. could simply pull it?
>
> Of course, I would be happy with it.
>
> But apparently I am the only one who continuously tracks all of these
> patches for Exynos (also for subsystems different than arch/arm/mach*).
> Yeah, I could ping everyone for every patch (not mine patch I mean)...
> but it is easier just to grab it after acking and send it. I really
> don't care about the method, just apply the damned patch ;)

My intention was by no means to belittle your effort, really thanks
for doing this. :)

I was just wondering if Linus couldn't pull this just as is, without
causing further commotion and unnecessarily introducing field for
potential conflicts between trees.

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] clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs

2015-12-14 Thread Tomasz Figa
Hi Marek,

2015-12-11 23:38 GMT+09:00 Marek Szyprowski <m.szyprow...@samsung.com>:
> It is allowed to enable/disable clocks from interrupts, so common Exynos
> ARM clock management code for CPUfreq should use 'irqsave' version of
> spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
> The same spin_lock is used by gate/mux clocks during enable/disable calls.
>
> This deadlock, can be reproduced by enabling CPUfreq (ondemand or
> userspace) and decoding video with s5p-mfc driver.

Good catch.

Acked-by: Tomasz Figa <tomasz.f...@gmail.com>

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] clk: samsung: exynos542x: fix MFC clock hierarchy parent

2015-12-10 Thread Tomasz Figa
Hi,

2015-12-08 22:29 GMT+09:00 Marek Szyprowski <m.szyprow...@samsung.com>:
> Proper source for MFC block is mout_user_aclk333 (in datasheet named
> USER_MUX_ACLK_333), not the output of CLKDIV_ACLK_333 MUX.
>
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Acked-by: Tomasz Figa <tomasz.f...@gmail.com>

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/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-19 Thread Tomasz Figa
2015-11-19 13:51 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
> On 19.11.2015 13:18, Tomasz Figa wrote:
>> However, I don't think we can disable compilation of particular 64-bit
>> SoCs, so maybe there isn't much sense in splitting their clock drivers
>> into separate symbols?
>
> To me it does not really matter. Indeed as you said one cannot disable
> building of one particular Exynos SoCs.
>
> However we could still want not build some parts of such SoCs (like
> clock, pinctrl etc). I don't see much benefit for such case except when
> someone would like to drastically reduce the size of kernel image (for
> whatever reasons he has.).

Can we really build a kernel that support selected Exynos SoC without
its clock driver? Actually I don't think we even allow deselecting
clock drivers currently, because they are not visible in menuconfig.
Unless there is a clear goal to separate ARCH level Kconfig symbol for
particular ARM64-based Exynos SoCs, I don't think it makes any sense
to keep the clock-related symbols separate.

>
> On the other hand having separate symbols causes duplication and
> obfuscates a little the Kconfig/Makefile. I like keeping things simple
> so one symbol for all ARM64 Exynos clocks sounds good.
>
> Sylwester preferred current approach. You and Pankaj seem to prefer one
> symbol-way.

Hmm, I read Sylwester's post as a reply to your original message and
not Pankaj's. Sylwester, could you clarify?

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/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-18 Thread Tomasz Figa
Hi Krzysztof,

Good idea, just a couple of nits inline. Other than that:

Acked-by: Tomasz Figa <tomasz.f...@gmail.com>

2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> so it is built also on ARMv7. This does not bring any kind of benefit.
> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> multi_v7 for ARMv7).
>
> Instead build clock drivers only for respective SoC's architecture.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  drivers/clk/samsung/Kconfig  | 13 +
>  drivers/clk/samsung/Makefile |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> index 84196ecdaa12..5f138fc4d84d 100644
> --- a/drivers/clk/samsung/Kconfig
> +++ b/drivers/clk/samsung/Kconfig
> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
> bool
> select COMMON_CLK
>
> +# ARMv7 SoCs:

nit: I'm not aware of any recent upgrade of the S3C24xx line-up to
ARMv7 cores. ;) I'd suggest "32-bit ARM SoCs" or just "ARM SoCs"...

>  config S3C2410_COMMON_CLK
> bool
> select COMMON_CLK_SAMSUNG
> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
> bool
> select COMMON_CLK_SAMSUNG
>
> +# ARMv8 SoCs:

and then here "64-bit ARM SoCs" or "ARM64 SoCs", whichever you prefer.
I'd lean towards simple "ARM" and "ARM64".

> +config EXYNOS5433_COMMON_CLK
> +   bool
> +   depends on ARM64 || COMPILE_TEST
> +   default ARCH_EXYNOS

nit: bool and default can be combined into def_bool ARCH_EXYNOS

> +   select COMMON_CLK_SAMSUNG
> +
> +config EXYNOS7_COMMON_CLK
> +   bool
> +   depends on ARM64 || COMPILE_TEST
> +   default ARCH_EXYNOS

nit: See above.

However, I don't think we can disable compilation of particular 64-bit
SoCs, so maybe there isn't much sense in splitting their clock drivers
into separate symbols?

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 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

2015-11-18 Thread Tomasz Figa
Hi Krzysztof,

2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski <k.kozlow...@samsung.com>:
> The ARMv8 Exynos family SoCs in Linux kernel are currently:
>  - Exynos5433 (controlled by ARCH_EXYNOS),
>  - Exynos7 (controlled by ARCH_EXYNOS7).
>
> It duplicates Kconfig symbols unnecessarily, so consolidate them into
> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
> symbol.
>
> The commit should not bring any visible functional change.

I think this basically matches the general recommendation for ARM64,
so excluding the single nitpick inline and assuming that, after this
patch, grep ARCH_EXYNOS7 gives no results:

Reviewed-by: Tomasz Figa <tomasz.f...@gmail.com>

>
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  arch/arm64/Kconfig.platforms| 11 ++-
>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>  arch/arm64/configs/defconfig|  2 +-
>  3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35962cc..afa19baca94e 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -13,21 +13,14 @@ config ARCH_BERLIN
>   This enables support for Marvell Berlin SoC Family
>
>  config ARCH_EXYNOS
> -   bool
> -   help
> - This enables support for Samsung Exynos SoC family
> -
> -config ARCH_EXYNOS7
> -   bool "ARMv8 based Samsung Exynos7"
> -   select ARCH_EXYNOS
> +   bool "ARMv8 based Samsung Exynos SoC family"
> select COMMON_CLK_SAMSUNG
> select HAVE_S3C2410_WATCHDOG if WATCHDOG
> select HAVE_S3C_RTC if RTC_CLASS
> select PINCTRL
> select PINCTRL_EXYNOS
> -
> help
> - This enables support for Samsung Exynos7 SoC family
> + This enables support for Samsung Exynos ARMv8 SoC family

nit: Sounds a little bit strange. Maybe "This enables support for
ARMv8 based Samsung Exynos SoC family"?

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 RESEND] clk: s5pv210: add missing call to samsung_clk_of_add_provider()

2015-08-12 Thread Tomasz Figa
2015-08-12 17:58 GMT+09:00 Marek Szyprowski m.szyprow...@samsung.com:
 Commit d5e136a21b2028fb1f45143ea7112d5869bfc6c7 (clk: samsung: Register
 clk provider only after registering its all clocks, merged to v3.17-rc1)
 modified a way that driver registers registers to core framework. This
 change has not been applied to s5pv210 clocks driver, which has been
 merged in parallel to that commit. This patch adds a missing call to
 samsung_clk_of_add_provider(), so the driver is operational again.

 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 CC: sta...@vger.kernel.org  # v3.17+
 ---
  drivers/clk/samsung/clk-s5pv210.c | 2 ++
  1 file changed, 2 insertions(+)


Acked-by: Tomasz Figa tomasz.f...@gmail.com

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 10/13] pinctrl: kill off set_irq_flags usage

2015-07-12 Thread Tomasz Figa
Hi,

2015-07-12 23:26 GMT+09:00 Rob Herring r...@kernel.org:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Acked-by: Linus Walleij linus.wall...@linaro.org
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Matthias Brugger matthias@gmail.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: linux-g...@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-media...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org
 ---
  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 --
  drivers/pinctrl/pinctrl-single.c  | 5 -
  drivers/pinctrl/samsung/pinctrl-exynos.c  | 1 -
  drivers/pinctrl/samsung/pinctrl-exynos5440.c  | 1 -
  drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 2 --
  drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 2 --

For drivers/pinctrl/samsung:

Acked-by: Tomasz Figa tomasz.f...@gmail.com

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] clk: exynos4: Fix wrong clock for Exynos4x12 ADC

2015-07-05 Thread Tomasz Figa
2015-07-06 13:03 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 2015-06-12 14:46 GMT+09:00 Javier Martinez Canillas jav...@dowhile0.org:
 Hello Krzysztof,

 On Fri, Jun 12, 2015 at 3:53 AM, Krzysztof Kozlowski
 k.kozlow...@samsung.com wrote:
 The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
 However TSADC is present only on Exynos4210 so on Trats2 board (with
 Exynos4412 SoC) the exynos-adc driver could not be probed:
ERROR: could not get clock /adc@126C:adc(0)
exynos-adc 126c.adc: failed getting clock, err = -2
exynos-adc: probe of 126c.adc failed with error -2

 Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
 Converter is located in different register and it is named in datasheet
 as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
 is the same as purpose of TSADC from Exynos4210.

 The patch adds gate clock for Exynos4x12 using the proper register so
 backward compatibility is preserved. This fixes the probe of exynos-adc
 driver on Exynos4x12 boards and allows accessing sensors connected to it
 on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: sta...@vger.kernel.org
 Fixes: c63c57433003 (ARM: dts: Add ADC's dt data to read raw data for 
 exynos4x12)
 Link: https://lkml.org/lkml/2015/6/11/85

 ---

 Changes since v1:
 1. After discussion on LKML this solution was chosen because it smaller,
simpler, self-contained (one patch to fix issue) and maintains backward
compatibility. Thanks to Javier Martinez Canillas and Tomasz Figa for
valuable comments.
 2. Dropped patch 2/2 because now it is not needed. The clock id TSADC
will be used on all Exynos4 boards.
 3. Added CC-stable.
 ---
  drivers/clk/samsung/clk-exynos4.c | 2 ++
  1 file changed, 2 insertions(+)


 Patch looks good to me.

 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

 Hi Tomasz and Sylwester,

 Any comments on this version of patch?
 Tomasz, you gave me comments on previous version. Are their satisfied?

Acked-by: Tomasz Figa tomasz.f...@gmail.com

Thanks for pinging.

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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

2015-06-16 Thread Tomasz Figa
2015-06-16 0:00 GMT+09:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
 Hello Sudeep,

 On 06/15/2015 11:01 AM, Sudeep Holla wrote:


 On 15/06/15 08:46, Javier Martinez Canillas wrote:
 [...]


 Sudeep, so we may need something like $subject after all from Doug's
 explanations since the combiner chip state is lost during a S2R. I know
 that it adds more duplicated code (others irqchip drivers do the same)
 and it may not scale well if a chip has many registers but is the best
 solution I could came with.


 OK

 If you have a suggestion for a better alternative, I can give a try and
 write the patch. But I think $subject could also land to fix this issue
 since is a very non intrusive change and later can be changed once the
 irqchip core supports this use case.


 Agreed. But I would suggest also to add MASK_ON_SUSPEND and set_irq_wake
 also and then you can restore iff it's non-zero as irq core will take
 care of most of the non-wakeup sources. Because I am planning to push

 I've looking at this and a problem I found is that IIUC the set_irq_wake
 is not propagated from the the Exynos pinctrl / GPIO driver which is the
 combiner's external interrupt source so the callback is never called.
 Which means that right now only the state of the wakeup source IRQs can't
 be saved since that information is not present.

 The drivers/pinctrl/samsung/pinctrl-exynos.c driver enables and disables
 the combiner interrupts but its .irq_set_wake handler only updates the
 wakeup source mask for the external interrupts but does not call the
 combiner .set_irq_wake so that should be changed as well.


As far as I'm aware of, wake-up events from pin controllers don't go
through GIC, but rather directly to PMU, which is a dedicated unit
responsible for power management and not a standalone interrupt
controller (well actually I saw a series making it a cascaded
controller some time ago, but I'm not sure if that went in). Based on
this, I don't think we have to call set_irq_wake on GIC. Correct me if
I'm wrong, though.

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/2] clk: exynos4: Add PCLK_ADC gate clock on Exynos4x12

2015-06-11 Thread Tomasz Figa
2015-06-11 21:40 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 W dniu 11.06.2015 o 21:15, Javier Martinez Canillas pisze:
 Hello Krzysztof,

 On Thu, Jun 11, 2015 at 12:43 PM, Krzysztof Kozlowski
 k.kozlow...@samsung.com wrote:
 W dniu 11.06.2015 o 17:26, Krzysztof Kozlowski pisze:
 Add proper gate clock for the Analog to Digital Converter (ADC) on
 Exynos4x12.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos4.c   | 3 +++
  include/dt-bindings/clock/exynos4.h | 5 -
  2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/clk/samsung/clk-exynos4.c 
 b/drivers/clk/samsung/clk-exynos4.c
 index 714d6ba782c8..5f32410a01f8 100644
 --- a/drivers/clk/samsung/clk-exynos4.c
 +++ b/drivers/clk/samsung/clk-exynos4.c
 @@ -85,6 +85,7 @@
  #define DIV_PERIL4   0xc560
  #define DIV_PERIL5   0xc564
  #define E4X12_DIV_CAM1   0xc568
 +#define E4X12_GATE_BUS_FSYS1 0xc744
  #define GATE_SCLK_CAM0xc820
  #define GATE_IP_CAM  0xc920
  #define GATE_IP_TV   0xc924
 @@ -1095,6 +1096,8 @@ static struct samsung_gate_clock 
 exynos4x12_gate_clks[] __initdata = {
   0),
   GATE(CLK_PPMUIMAGE, ppmuimage, aclk200, E4X12_GATE_IP_IMAGE, 9, 
 0,
   0),
 + GATE(CLK_PCLK_ADC, pclk_adc, aclk133, E4X12_GATE_BUS_FSYS1, 16, 
 0,
 + 0),

 Now I have even simpler idea. Don't add new clock id but just define
 here the CLK_TSADC as:
 GATE(CLK_TSADC, tsadc, aclk133, E4X12_GATE_BUS_FSYS1, 16, 0, 0);

 With this change the second patch wouldn't be needed however this does
 not reflect the Exynos 4x12 datasheet.

 Any comments?


 I think it's better to reflect the datasheet so I prefer your original
 patch.

 Yeah, I also like sticking to datasheet but maybe it is not always worth
 to reproduce the datasheet in 100%. It is just thinking out loud.

 Also, wouldn't changing the CLK_TSADC gate definition cause a
 regression on an Exynos4210 board that is using the tsadc clock? or
 maybe I misunderstood the explanation of your Patch 2/2?

 No, no. The Exynos4210 would be unchanged. It has the CLK_TSADC - both
 in hardware and in kernel driver. The Exynos4x12 SoCs don't have so we can:
 1. Add new CLK_PCLK_ADC (id and clock) reflecting datasheet.
 2. Add only CLK_TSADC clock  on Exynos4x12 which will be using the
 register of PCLK_ADC. The id would stay the same as on Exynos4210.

Or we can:
3. Add new CLK_PCLK_ADC macro equal to current CLK_TSADC. Then drivers
and dtsi would be able to use the name matching the datasheet, but the
ID (and so DT ABI) would be preserved.

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: [RFT v2 06/48] pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc

2015-06-04 Thread Tomasz Figa
Hi,

2015-06-04 13:13 GMT+09:00 Jiang Liu jiang@linux.intel.com:
 Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
 already have a pointer to corresponding irq_desc.

 Signed-off-by: Jiang Liu jiang@linux.intel.com
 Acked-by: Linus Walleij linus.wall...@linaro.org
 ---
  drivers/pinctrl/intel/pinctrl-cherryview.c|2 +-
  drivers/pinctrl/intel/pinctrl-intel.c |2 +-
  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |4 ++--
  drivers/pinctrl/nomadik/pinctrl-nomadik.c |   12 +---
  drivers/pinctrl/pinctrl-amd.c |2 +-
  drivers/pinctrl/pinctrl-at91.c|2 +-
  drivers/pinctrl/pinctrl-coh901.c  |4 ++--
  drivers/pinctrl/pinctrl-rockchip.c|4 ++--
  drivers/pinctrl/pinctrl-single.c  |2 +-
  drivers/pinctrl/pinctrl-st.c  |6 +++---
  drivers/pinctrl/qcom/pinctrl-msm.c|2 +-
  drivers/pinctrl/samsung/pinctrl-exynos.c  |8 
  drivers/pinctrl/samsung/pinctrl-s3c24xx.c |   18 +-
  drivers/pinctrl/samsung/pinctrl-s3c64xx.c |   22 ++

For Samsung stuff:

Acked-by: Tomasz Figa tomasz.f...@gmail.com

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] RFT: pinctrl: samsung: separate wakeup irqdomain

2015-04-09 Thread Tomasz Figa
Hi Linus,

2015-04-09 9:40 GMT+02:00 Linus Walleij linus.wall...@linaro.org:
 The Samsung pin control driver and subdrivers sometimes use both
 an irqdomain for some IRQs and another irqdomain for wakeup irqs,
 registering the first with a call to the per-SoC callback
 .eint_gpio_init() and the second with a call to .eint_wkup_init()
 however it seems both runpaths will assign the resulting irqdomain
 to the per-bank bank.irq_domain member, making the second
 (wakeup) irqdomain overwrite the first one.

 I'm surprised this even works, and it seems that the S3C
 per-domain domain data that seems to be used in part to work
 around this bug by creating a local array with copies of the
 irqdomain (!).

 This patch mainly adds a new record to the GPIO/pin bank
 for wakeups and use this in the .eint_wkup_init() callbacks
 to pave the way for more cleanups.

 Signed-off-by: Linus Walleij linus.wall...@linaro.org
 ---
 Tomasz etc: I don't know if I'm just misunderstanding this,
 can you look at it and tell me how badly I misunderstand
 these Samsung wakeups, to me it is a complete mystery.

On all Samsung SoCs known to me, there is no GPIO bank which have both
eint_wkup and eint_gpio functions at the same time, so there is no way
that bank-irq_domain could be overwritten.

On S3C64xx, the arrays in domain data are necessary to work around
crazy layout of pin banks which do not fully correspond to EINT banks
in the controller.

So, in general, I don't think there is really any problem with this
driver at the moment. If, in future, a SoC shows up with both IRQ
types in the same pin bank, then it will have to be reworked, but I
don't see why such thing could show up in a SoC, because it wouldn't
really add any value.

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: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

2015-04-07 Thread Tomasz Figa
2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
 So I disabled the sss clock before trying a S2R:

 # devmem 0x10018800 32 0xFFFB
 (CLK_SSS in CLK_GATE_IP_G2D is gated)

 and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
 its default value on S2R so maybe that is why it works anyways?

Does the driver restore its value on resume (i.e. has it in the
save/restore array)? Remember that suspend causes all clock registers
to be reset. Then some of them will be configured by the lowest
bootloader stage after wake-up reset, but the kernel needs to restore
all of them.


 # devmem 0x10018800
 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

 Does this shed any more light? Could the problem be that the sss
 clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
 required for S2R or is just that CLK_SSS prevents the parent to
 be gated and so it is another red herring?

Does the board use secure firmware? If yes, it might require to do
some encryption on suspend, so if the firmware is broken and doesn't
control the clock itself, it might need the SSS clock to be running,
when the SLEEP SMC operation is called.

Anyway, I just realized that Exynos4 also need several clocks to be
ungated on suspend and this is handled by code [1] based on arrays
[2].

[1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
[2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276

Could this method work for your case as well? There would be no need
to call any clock API at all, just low level register writes, which is
okay, since this is a low level driver anyway.

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: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

2015-04-07 Thread Tomasz Figa
2015-04-07 16:11 GMT+02:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
 From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
 From: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Date: Tue, 7 Apr 2015 15:53:27 +0200
 Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

 Commit ae43b3289186 (ARM: 8202/1: dmaengine: pl330: Add runtime Power
 Management support v12) added pm support for the pl330 dma driver but
 it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
 during suspend and this in turn makes its parent clock aclk266_g2d to
 be gated. But the clock needs to be ungated prior suspend to allow the
 system to be suspend and resumed correctly.

 Add GATE_BUS_TOP register to the list of registers to be restored when
 the system enters into a suspend state so aclk266_g2d will be ungated.

 Thanks to Abhilash Kesavan for figuring out that this was the issue.

 Fixes: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
 support v12)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/clk/samsung/clk-exynos5420.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 07d666cc6a29..bea4a173eef5 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump 
 exynos5420_set_clksrc[] = {
 { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
 { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
 { .offset = SRC_MASK_ISP,   .value = 0x1000, },
 +   { .offset = GATE_BUS_TOP,   .value = 0x, },
 { .offset = GATE_BUS_DISP1, .value = 0x, },
 { .offset = GATE_IP_PERIC,  .value = 0x, },
  };
 --
 2.1.4

Looks good to me. You can consider this Acked-by, as long as Sylwester
is not opposed to this approach.

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: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

2015-03-30 Thread Tomasz Figa
Hi Javier,

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
 The Samsung helpers functions to register clocks, add the clock instance
 returned by the common clock framework to a lookup table that is used by
 OF to lookup the clocks.

 But this table could also be useful to clock drivers if they need to get
 a clock instance since the helper functions don't return them.

 The common clock framework __clk_lookup() function from the clk provider
 API could be used by drivers as well. But it's more efficient to use the
 Samsung specific lookup table that returns the clock instance in constant
 time, than using the __clk_lookup() function that uses the clock name as
 an index so it has a linear search time.

Is this really something we should be concerned about? If so, maybe
the generic look-up function should be rewritten to use something
faster, such as tree or hash table?

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: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

2015-03-30 Thread Tomasz Figa
Hi Javier,

Please see my comments inline.

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
[snip]
 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 07d666cc6a29..2d39b629144a 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -151,6 +151,7 @@ enum exynos5x_plls {

  static void __iomem *reg_base;
  static enum exynos5x_soc exynos5x_soc;
 +struct samsung_clk_provider *ctx;

static


  #ifdef CONFIG_PM_SLEEP
  static struct samsung_clk_reg_dump *exynos5x_save;
 @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump 
 exynos5420_set_clksrc[] = {
 { .offset = GATE_IP_PERIC,  .value = 0x, },
  };

 +/*
 + * list of clocks that have to be kept enabled during suspend/resume cycle.
 + */
 +static unsigned int exynos5x_clk_suspend[] = {

static const

 +   CLK_MDMA0,
 +};
 +
  static int exynos5420_clk_suspend(void)
  {
 +   int i;
 +   struct clk *clk;
 +
 samsung_clk_save(reg_base, exynos5x_save,
 ARRAY_SIZE(exynos5x_clk_regs));

 @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
 samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 ARRAY_SIZE(exynos5420_set_clksrc));

 +   for (i = 0; i  ARRAY_SIZE(exynos5x_clk_suspend); i++) {
 +   clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);

If look-up speed is important here, maybe all the relevant clocks
could be looked up once at initialization time and just prepared and
enabled here?

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 v4 3/5] pinctrl: exynos: add exynos5410 SoC specific data

2015-03-23 Thread Tomasz Figa
Hi Andreas, Hakjoo,

Thanks for the patch.

2015-03-16 7:00 GMT+09:00 Andreas Färber afaer...@suse.de:
 From: Hakjoo Kim ruppi@hardkernel.com

 Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
 support for all platforms based on EXYNOS5410.

 Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
 [AF: Rebased onto Exynos5260, irq_chip consolidation, const'ification]
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v2 - v3:
  * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

  v1 - v2:
  * Filled in Sob from Hakjoo Kim

  .../bindings/pinctrl/samsung-pinctrl.txt   |   1 +
  drivers/pinctrl/samsung/pinctrl-exynos.c   | 103 
 +
  drivers/pinctrl/samsung/pinctrl-samsung.c  |   2 +
  drivers/pinctrl/samsung/pinctrl-samsung.h  |   1 +
  4 files changed, 107 insertions(+)


Acked-by: Tomasz Figa tomasz.f...@gmail.com

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] pinctrl: exynos: Remove eint_gpio_init call-back for exynos7 alive pinctrl block

2015-03-09 Thread Tomasz Figa
Hi Abhilash, Linus,

2015-03-02 1:21 GMT+09:00 Abhilash Kesavan a.kesa...@samsung.com:
 The alive pin controller on exynos7 does not support external gpio
 interrupts. Hence, remove the eint_gpio_init call-back for it. This
 fixes the following error message seen during exynos7 boot-up:
 samsung-pinctrl 1058.pinctrl: irq number not available

As long as external gpio interrupts refer to non-wake-up-capable
GPIO interrupts I'm fine with this patch.

Acked-by: Tomasz Figa tomasz.f...@gmail.com

Thanks Linus for pinging and sorry for delay.

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 00/10] ARM: s3c64xx multiplatform, help needed

2015-03-02 Thread Tomasz Figa
Hi Arnd,

Thanks a lot for these patches.

2015-03-02 21:35 GMT+09:00 Arnd Bergmann a...@arndb.de:
 Hi everyone,

 I've had these patches in a private git tree for a while, and have
 finally gotten around to clean them up some more for submission.
 Hopefully we can get all of it merged into 4.1.

 I've done this to the best of my knowledge, but some parts are
 a bit tricky, so I expect that there are bugs. The trickiest
 part is the touchscreen driver. I've sent it out for review
 last year already, but I have not found anybody who could test
 it, and it's basically a blind rewrite of an existing driver,
 so it's unlikely that I got it all right.

 The other parts may actually work, but it is possible that
 I made a mistake with the ASoC driver, the sparseirq support
 or something else.

 Does anyone still have access to the hardware? I'm particularly
 interested in seeing this patch set get tested on smartq
 and on smdk6410, which have the majority of the hardware.

I still have a tiny6410, which is compatible with mini6410, so I can
test both DT and non-DT code paths. It also has a touchscreen using
the on-SoC ADC. I'll give it a try this weekend. I'll try to review
the series as well.

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] clk: samsung: Add CLKOUT driver support for Exynos3250 SoC.

2015-03-01 Thread Tomasz Figa
2015-02-25 19:13 GMT+09:00 Inha Song ideal.s...@samsung.com:
 Hi, Tomasz,

 Thanks for you comment :)

 On Wed, 25 Feb 2015 09:54:02 +0900
 Tomasz Figa tomasz.f...@gmail.com wrote:

 Hi Inha,

 Thanks for the patch. Please see my comments inline.

 2015-02-24 18:22 GMT+09:00 Inha Song ideal.s...@samsung.com:
  This patch add CLKOUT driver support for Exynos3250 SoC.

 Could you please add a little more information? I know that it might
 be pretty obvious to people familiar with this driver and/or hardware,
 but it might be a good idea to explicitly say that the CLKOUT
 controller is compatible with Exynos4, so only a new compatible string
 is added.

 On the other hand, do you really need to add a new compatible string
 if an existing one can be reused? The reason why the DT property is
 called compatible is to be able to use the same compatible strings
 on different devices, because they are compatible, even though the
 string might have its name after only one of them. If there is some
 additional reason to add a new compatible string, please write this in
 commit message.

 In in PMU document(Document/devicetree/bindgins/arm/samsung/pmu.txt),
 samsung,exynos3250-pmu compatible string had been added.

 So I add this compatible in driver.


Ah, right, the whole PMU block is not compatible with Exynos4, so a
new compatible string is needed indeed. It should be said in patch
description, though.


 
  Signed-off-by: Inha Song ideal.s...@samsung.com
  ---
   drivers/clk/samsung/clk-exynos-clkout.c | 2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
  b/drivers/clk/samsung/clk-exynos-clkout.c
  index 3a7cb25..1c02e73 100644
  --- a/drivers/clk/samsung/clk-exynos-clkout.c
  +++ b/drivers/clk/samsung/clk-exynos-clkout.c
  @@ -142,6 +142,8 @@ CLK_OF_DECLARE(exynos4212_clkout, 
  samsung,exynos4212-pmu,
  exynos4_clkout_init);
   CLK_OF_DECLARE(exynos4412_clkout, samsung,exynos4412-pmu,
  exynos4_clkout_init);
  +CLK_OF_DECLARE(exynos3250_clkout, samsung,exynos3250-pmu,
  +   exynos4_clkout_init);

 Are you sure that the PMU DEBUG register on Exynos3250 is indeed
 compatible with Exynos4 and not with newer SoCs? AFAIR, the only
 difference was the number of bits (4 on Exynos4 and 5 on Exynos5?) of
 the main mux.

 Exynos3250 PMU_DEBUG register is same with Exynos4. So I just use 
 exynos4_clkout_init function.
 But, on second thought, It looks good to add exynos3_clkout_init function for 
 Exynos3 SoC even though it's the same with exynos4_clkout_init.

 what is your opinion?

Well, if there is no need then I don't see any reason why having a
separate function doing the same things could have any benefits. If
some differences are discovered in future it can be always modified in
a separate patch.

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] clk: samsung: Add CLKOUT driver support for Exynos3250 SoC.

2015-02-24 Thread Tomasz Figa
Hi Inha,

Thanks for the patch. Please see my comments inline.

2015-02-24 18:22 GMT+09:00 Inha Song ideal.s...@samsung.com:
 This patch add CLKOUT driver support for Exynos3250 SoC.

Could you please add a little more information? I know that it might
be pretty obvious to people familiar with this driver and/or hardware,
but it might be a good idea to explicitly say that the CLKOUT
controller is compatible with Exynos4, so only a new compatible string
is added.

On the other hand, do you really need to add a new compatible string
if an existing one can be reused? The reason why the DT property is
called compatible is to be able to use the same compatible strings
on different devices, because they are compatible, even though the
string might have its name after only one of them. If there is some
additional reason to add a new compatible string, please write this in
commit message.


 Signed-off-by: Inha Song ideal.s...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos-clkout.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
 b/drivers/clk/samsung/clk-exynos-clkout.c
 index 3a7cb25..1c02e73 100644
 --- a/drivers/clk/samsung/clk-exynos-clkout.c
 +++ b/drivers/clk/samsung/clk-exynos-clkout.c
 @@ -142,6 +142,8 @@ CLK_OF_DECLARE(exynos4212_clkout, 
 samsung,exynos4212-pmu,
 exynos4_clkout_init);
  CLK_OF_DECLARE(exynos4412_clkout, samsung,exynos4412-pmu,
 exynos4_clkout_init);
 +CLK_OF_DECLARE(exynos3250_clkout, samsung,exynos3250-pmu,
 +   exynos4_clkout_init);

Are you sure that the PMU DEBUG register on Exynos3250 is indeed
compatible with Exynos4 and not with newer SoCs? AFAIR, the only
difference was the number of bits (4 on Exynos4 and 5 on Exynos5?) of
the main mux.

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 v3] pinctrl: exynos: Add support for Exynos5433

2015-02-08 Thread Tomasz Figa
Hi,

2015-01-29 18:48 GMT+09:00 Linus Walleij linus.wall...@linaro.org:
 On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote:

 This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 
 multi-
 functional input/output port pins and 135 memory port pins. There are 41 
 general
 port groups and 2 memory port groups.

 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 ---
 Changes from v2:
 - Rebase it on v3.19-rc5

 Waiting for Tomasz to review this.

Thanks Linus. Looks good to me.

Acked-by: Tomasz Figa tomasz.f...@gmail.com

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 v3 01/12] clk: samsung: exynos5433: Add clocks using common clock framework

2015-01-24 Thread Tomasz Figa
2015-01-23 1:47 GMT+09:00 Sylwester Nawrocki s.nawro...@samsung.com:
 Hi Chanwoo,

 On 21/01/15 07:26, Chanwoo Choi wrote:
 This patch adds the support for CMU (Clock Management Units) of Exynos5433
 which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
 (PLL/MMC/UART/MCT/I2C/SPI) for kernel boot and includes binding documentation
 for Exynos5433 clock controller.

 diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt 
 b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
 new file mode 100644
 index 000..72cd0ba
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
 @@ -0,0 +1,106 @@
 +* Samsung Exynos5433 CMU (Clock Management Units)
 +
 +The Exynos5433 clock controller generates and supplies clock to various
 +controllers within the Exynos5433 SoC.
 +
 +Required Properties:
 +
 +- compatible: should be one of the following.
 +  - samsung,exynos5433-cmu-top   - clock controller compatible for CMU_TOP
 +which generates clocks for 
 IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
 +domains and bus clocks.
 +  - samsung,exynos5433-cmu-cpif  - clock controller compatible for 
 CMU_CPIF
 +which generates clocks for LLI (Low Latency Interface) IP.
 +  - samsung,exynos5433-cmu-mif   - clock controller compatible for CMU_MIF
 +which generates clocks for DRAM Memory Controller domain.
 +  - samsung,exynos5433-cmu-peric - clock controller compatible for 
 CMU_PERIC
 +which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
 +  - samsung,exynos5433-cmu-peris - clock controller compatible for 
 CMU_PERIS
 +which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
 +  - samsung,exynos5433-cmu-fsys  - clock controller compatible for 
 CMU_FSYS
 +which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
 +
 +- 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/exynos5433.h header and can be used in device
 +tree sources.
 +
 +Example 1: Examples of clock controller nodes are listed below.
 +
 + cmu_top: clock-controller@0x1003 {
 + compatible = samsung,exynos5433-cmu-top;
 + reg = 0x1003 0x0c04;
 + #clock-cells = 1;
 + };
 +
 + cmu_cpif: clock-controller@0x10fc {
 + compatible = samsung,exynos5433-cmu-cpif;
 + reg = 0x10fc 0x0c04;
 + #clock-cells = 1;
 + };
 +
 + cmu_mif: clock-controller@0x105b {
 + compatible = samsung,exynos5433-cmu-mif;
 + reg = 0x105b 0x100c;
 + #clock-cells = 1;
 + };
 +
 + cmu_peric: clock-controller@0x14c8 {
 + compatible = samsung,exynos5433-cmu-peric;
 + reg = 0x14c8 0x0b08;
 + #clock-cells = 1;
 + };
 +
 + cmu_peris: clock-controller@0x1004 {
 + compatible = samsung,exynos5433-cmu-peris;
 + reg = 0x1004 0x0b20;
 + #clock-cells = 1;
 + };
 +
 + cmu_fsys: clock-controller@0x156e {
 + compatible = samsung,exynos5433-cmu-fsys;
 + reg = 0x156e 0x0b04;
 + #clock-cells = 1;
 + };

 What are the reasons to split the whole clock controller into separate
 device nodes with different compatible strings like this? I doubt drivers
 associated with each of those compatible strings could be ever reused on
 different Exynos SoCs.

Well, they are separate IP blocks, so this is how they should be
represented in DT and IMHO using different compatible strings is a bit
cleaner than relying on aliases to get instance index.

Plus we probably want to learn from mistakes done when designing
Exynos4x12 clock bindings, which prevent us from fixing the issue of
ISP power domain, in which the ISP CMU is located. AFAICS, Exynos5433
clock tree is split between several such ISP CMUs.


 There are hardware dependencies between these clock domains, which are
 not currently modelled in DT with your binding. IOW, there is currently
 no way to ensure proper registration order of the CMUs (clock domains).
 This may be important in some cases.

 To address this we could either add clocks/clock-names properties in
 respective CMU device nodes, pointing to any clocks in other CMU(s)

which I believe is the proper way of doing things, which lets us
preserve the correct representation of separate CMUs in DT.

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: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem

2015-01-17 Thread Tomasz Figa
Hi,

[CCing more people]

2015-01-16 23:39 GMT+09:00 Paul Osmialowski p.osmialo...@samsung.com:
 This enhancement of i2c API is designed to address following problem
 caused by circular lock dependency:

 - #1 (prepare_lock){+.+.+.}:
 [2.730502][c0061e50] __lock_acquire+0x3c0/0x8a4
 [2.735970][c0062868] lock_acquire+0x6c/0x8c
 [2.741090][c04a2724] mutex_lock_nested+0x68/0x464
 [2.746733][c0395e84] clk_prepare_lock+0x40/0xe8
 [2.752201][c0397698] clk_unprepare+0x18/0x28
 [2.757409][c034cbb0] s3c24xx_i2c_xfer+0xc8/0x124
 [2.762964][c03457e0] __i2c_transfer+0x74/0x8c
 [2.768259][c0347234] i2c_transfer+0x78/0xec
 [2.773380][c02a177c] regmap_i2c_read+0x48/0x64
 [2.778761][c029d5c0] _regmap_raw_read+0xa8/0xfc
 [2.784230][c029d920] _regmap_bus_read+0x28/0x48
 [2.789699][c029ce00] _regmap_read+0x74/0xdc
 [2.794819][c029d0ec] _regmap_update_bits+0x24/0x70
 [2.800549][c029e348] regmap_update_bits+0x40/0x5c
 [2.806190][c024c3c4] _regulator_do_disable+0x68/0x7c
 [2.812093][c024f4d8] _regulator_disable+0x90/0x12c
 [2.817822][c024f5a8] regulator_disable+0x34/0x60
 [2.823377][c0363070] mmc_regulator_set_ocr+0x74/0xdc
 [2.829279][c03783e8] sdhci_set_power+0x38/0x20c
 [2.834748][c0379c10] sdhci_do_set_ios+0x180/0x450
 [2.840389][c0379f00] sdhci_set_ios+0x20/0x2c
 [2.845597][c0364978] mmc_set_initial_state+0x5c/0xbc
 [2.851500][c0364f48] mmc_power_off+0x2c/0x60
 [2.856708][c0365c00] mmc_rescan+0x268/0x27c
 [2.861829][c003a128] process_one_work+0x18c/0x3f8
 [2.867471][c003a400] worker_thread+0x38/0x2f8
 [2.872766][c003f66c] kthread+0xe4/0x104
 [2.877540][c000f0a8] ret_from_fork+0x14/0x2c
 [2.882749]
 - #0 (map-mutex){+.+...}:
 [2.886828][c0061224] validate_chain.isra.25+0x3bc/0x548
 [2.892990][c0061e50] __lock_acquire+0x3c0/0x8a4
 [2.898459][c0062868] lock_acquire+0x6c/0x8c
 [2.903580][c04a2724] mutex_lock_nested+0x68/0x464
 [2.909222][c029ce9c] regmap_read+0x34/0x5c
 [2.914257][c039a994] max_gen_clk_is_prepared+0x1c/0x38
 [2.920333][c0396ec4] clk_unprepare_unused_subtree+0x64/0x98
 [2.926842][c0396f78] clk_disable_unused+0x80/0xd8
 [2.932484][c00089d0] do_one_initcall+0xac/0x1f0
 [2.937953][c068bd44] do_basic_setup+0x90/0xc8
 [2.943248][c068be00] kernel_init_freeable+0x84/0x120
 [2.949150][c0491248] kernel_init+0x8/0xec
 [2.954097][c000f0a8] ret_from_fork+0x14/0x2c
 [2.959307]
 [2.959307] other info that might help us debug this:
 [2.959307]
 [2.967293]  Possible unsafe locking scenario:
 [2.967293]
 [2.973194]CPU0CPU1
 [2.977708]
 [2.982221]   lock(prepare_lock);
 [2.985520]lock(map-mutex);
 [2.991248]lock(prepare_lock);
 [2.997063]   lock(map-mutex);
 [3.000276]
 [3.000276]  *** DEADLOCK ***

 Apparently regulator and clock try to acquire lock which is protecting the
 same regmap. Communication over i2c requires clock to be started. Both things
 require access to the same regmap in order to complete.

I stumbled upon this issue (and reported it) quite long time ago
already, but apparently nobody cared too much (including myself,
unfortunately). Please see [1] for details.

[1] https://lkml.org/lkml/2014/7/2/171

We have here a typical ABBA deadlock scenario, between I2C clock
providers and other (logical) devices on the same (physical) I2C
device, for which a regmap is used to share the registers between
drivers. Remaining factor here is I2C controller driver, which must
perform clock gating in I2C ops to trigger this deadlock.

The problem is that any operation on such I2C clock will first try to
acquire clk_prepare_mutex and then, through driver's callback, access
the regmap, acquiring its mutex (then an I2C transfer will happen, but
it irrelevant in this context). On opposite side we have drivers for
other functionality exposed by this I2C device, which will access the
regmap, acquiring its mutex and causing I2C transfers to happen.

The key here is that I2C transfers might require some clocks to be
prepared, so clk_prepare() might get called from this context and
cause a deadlock, because clk_prepare_mutex might have been already
acquired by another context, waiting for regmap mutex, which has been
already acquired by this context.

Now, for the solution, the approach proposed by Paul, as far as I
could understand it by reading the code (it's definitely lacking a
cover letter with detailed explanation), should solve the issue by
enforcing correct locking 

Re: [PATCH v11 1/9] ARM: OMAP2+: use common l2cache initialization code

2015-01-07 Thread Tomasz Figa
2015-01-06 5:25 GMT+09:00 Arnd Bergmann a...@arndb.de:
 On Monday 05 January 2015 13:19:00 Marek Szyprowski wrote:
  DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device Tree))
 +   .l2c_aux_val= OMAP_L2C_AUX_CTRL,
 +   .l2c_aux_mask   = 0xcf9f,
 +   .l2c_write_sec  = omap4_l2c310_write_sec,
 .reserve= omap_reserve,
 .smp= smp_ops(omap4_smp_ops),
 .map_io = omap4_map_io,


 Could we also get those values into the dts files? Clearly we
 can't remove them here without breaking compatibility with old
 dtbs, but it would be nice to have all new dtbs do the right thing.

Sounds like a good next step after merging this series. :)

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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

2015-01-02 Thread Tomasz Figa

On 30.12.2014 03:23, Nishanth Menon wrote:

On 12/23/2014 04:48 AM, Marek Szyprowski wrote:


-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
  {
-   void __iomem *base = l2x0_base;
+   unsigned revision;

-   if (!(readl_relaxed(base + L2X0_CTRL)  L2X0_CTRL_EN)) {
-   unsigned revision;
-
-   /* restore pl310 setup */
-   writel_relaxed(l2x0_saved_regs.tag_latency,
-  base + L310_TAG_LATENCY_CTRL);
-   writel_relaxed(l2x0_saved_regs.data_latency,
-  base + L310_DATA_LATENCY_CTRL);
-   writel_relaxed(l2x0_saved_regs.filter_end,
-  base + L310_ADDR_FILTER_END);
-   writel_relaxed(l2x0_saved_regs.filter_start,
-  base + L310_ADDR_FILTER_START);
-
-   revision = readl_relaxed(base + L2X0_CACHE_ID) 
-   L2X0_CACHE_ID_RTL_MASK;
-
-   if (revision = L310_CACHE_ID_RTL_R2P0)
-   l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
- L310_PREFETCH_CTRL);
-   if (revision = L310_CACHE_ID_RTL_R3P0)
-   l2c_write_sec(l2x0_saved_regs.pwr_ctrl, base,
- L310_POWER_CTRL);
-
-   l2c_enable(base, l2x0_saved_regs.aux_ctrl, 8);
-
-   /* Re-enable full-line-of-zeros for Cortex-A9 */
-   if (l2x0_saved_regs.aux_ctrl  L310_AUX_CTRL_FULL_LINE_ZERO)
-   set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
-   }
+   /* restore pl310 setup */
+   writel_relaxed(l2x0_saved_regs.tag_latency,
+  base + L310_TAG_LATENCY_CTRL);
+   writel_relaxed(l2x0_saved_regs.data_latency,
+  base + L310_DATA_LATENCY_CTRL);
+   writel_relaxed(l2x0_saved_regs.filter_end,
+  base + L310_ADDR_FILTER_END);
+   writel_relaxed(l2x0_saved_regs.filter_start,
+  base + L310_ADDR_FILTER_START);
+


^^ The above change broke AM437xx. Looks like the change causes the
following behavior difference on AM437x. For some reason, touching any
of the above 4 registers(even with the values read from the same
registers) causes AM437x to go beserk. Comment the 4 writes and we
reach shell. looks like l2c310_resume is not invoked prior to this
series. :(.. now that we reuse that logic to actually do programming,
we start to see the problem.


OK, I probably have answer for this. Apparently all four register above 
cannot be written in non-secure mode and they should go through 
l2c_write_sec(). More on this can be found in CoreLink Level 2 Cache 
Controller L2C-310 Technical Reference Manual, 3.2. Register summary, 
table 3.1. I have checked the TRM for r3p3, but I guess this should be 
uniform for all revisions.


Why this worked before? The registers were not written unless respective 
properties in DT were present and OMAP do not have them in DT. Current 
code always writes them, which should not really matter if the code is 
correct. (But it isn't - writel_relaxed() can't be used directly for 
those registers.)


Could you check if replacing those four writel_relaxed() with 
l2c_write_sec() does the thing?


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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

2015-01-02 Thread Tomasz Figa

On 30.12.2014 23:51, Nishanth Menon wrote:

Looks like the following also need addressing:
data-save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in __l2c_init


I'll check this.

Thanks.



Apparently the second save in __l2c_init() is not needed and it should 
have been removed. However it might be a good idea to actually do second 
save in l2c_enable() after l2c_configure() so that the values actually 
permitted by hardware and/or secure firmware are stored.


l2c310_init_fns needs to be updated indeed.

However I'm not sure about your concern about using l2x0_data before 
kmemdup(). I don't see any code potentially doing this.


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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

2014-12-30 Thread Tomasz Figa
Thanks a lot for investigating this, even before I could look into
splitting this.

2014-12-30 3:23 GMT+09:00 Nishanth Menon n...@ti.com:
 On 12/23/2014 04:48 AM, Marek Szyprowski wrote:

 -static void l2c310_resume(void)
 +static void l2c310_configure(void __iomem *base)
  {
 - void __iomem *base = l2x0_base;
 + unsigned revision;

 - if (!(readl_relaxed(base + L2X0_CTRL)  L2X0_CTRL_EN)) {
 - unsigned revision;
 -
 - /* restore pl310 setup */
 - writel_relaxed(l2x0_saved_regs.tag_latency,
 -base + L310_TAG_LATENCY_CTRL);
 - writel_relaxed(l2x0_saved_regs.data_latency,
 -base + L310_DATA_LATENCY_CTRL);
 - writel_relaxed(l2x0_saved_regs.filter_end,
 -base + L310_ADDR_FILTER_END);
 - writel_relaxed(l2x0_saved_regs.filter_start,
 -base + L310_ADDR_FILTER_START);
 -
 - revision = readl_relaxed(base + L2X0_CACHE_ID) 
 - L2X0_CACHE_ID_RTL_MASK;
 -
 - if (revision = L310_CACHE_ID_RTL_R2P0)
 - l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
 -   L310_PREFETCH_CTRL);
 - if (revision = L310_CACHE_ID_RTL_R3P0)
 - l2c_write_sec(l2x0_saved_regs.pwr_ctrl, base,
 -   L310_POWER_CTRL);
 -
 - l2c_enable(base, l2x0_saved_regs.aux_ctrl, 8);
 -
 - /* Re-enable full-line-of-zeros for Cortex-A9 */
 - if (l2x0_saved_regs.aux_ctrl  L310_AUX_CTRL_FULL_LINE_ZERO)
 - set_auxcr(get_auxcr() | BIT(3) | BIT(2) | BIT(1));
 - }
 + /* restore pl310 setup */
 + writel_relaxed(l2x0_saved_regs.tag_latency,
 +base + L310_TAG_LATENCY_CTRL);
 + writel_relaxed(l2x0_saved_regs.data_latency,
 +base + L310_DATA_LATENCY_CTRL);
 + writel_relaxed(l2x0_saved_regs.filter_end,
 +base + L310_ADDR_FILTER_END);
 + writel_relaxed(l2x0_saved_regs.filter_start,
 +base + L310_ADDR_FILTER_START);
 +

 ^^ The above change broke AM437xx. Looks like the change causes the
 following behavior difference on AM437x. For some reason, touching any
 of the above 4 registers(even with the values read from the same
 registers) causes AM437x to go beserk. Comment the 4 writes and we
 reach shell. looks like l2c310_resume is not invoked prior to this
 series. :(.. now that we reuse that logic to actually do programming,
 we start to see the problem.

Hmm, but the thing is that .configure() should not be called if the
controller is already configured, i.e. L2X0_CTRL_EN in L2X0_CTRL is
set. Maybe I missed some check somewhere. Let me reread my code I
wrote quite a long time ago and make sure.


 one option might be to write only those registers that differ from
 saved_registers (example: unmodified values dont need reprogramming).

 Looks like the following also need addressing:
 data-save is called twice (once more after l2cof_init)
 l2c310_init_fns also needs l2c310_configure
 will be nice to use l2x0_data only after we kmemdup data in __l2c_init

I'll check this.


 if you'd like to split this up in pieces, [1] might be nice - will go
 good to change the pl310, aurora etc in each chunks to enable better
 review.

Thanks a lot, the split up version will be definitely useful. Just to
make sure, the parts look quite bisectable, but have you verified that
applying the changes one by one leave the L2 cache working on OMAP?


 [1]
 https://github.com/nmenon/linux-2.6-playground/commits/temp/l2c-patch2-splitup

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 v3 3/5] pinctrl: exynos: add exynos5410 SoC specific data

2014-12-28 Thread Tomasz Figa

Hi Andreas,

On 23.11.2014 07:26, Andreas Färber wrote:

From: Hakjoo Kim ruppi@hardkernel.com

Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.

Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased onto Exynos5260 and irq_chip consolidation]
Signed-off-by: Andreas Färber afaer...@suse.de
---
  v2 - v3:
  * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

  v1 - v2:
  * Filled in Sob from Hakjoo Kim


Any news on this patch? I'd like to ACK it, but apparently it is waiting 
for a rebase.


Sorry for the delay, unfortunately things are a little bit busy on my 
side nowadays.


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 01/19] pinctrl: exynos: Add support for Exynos5433

2014-12-28 Thread Tomasz Figa

Hi Chanwoo,

On 27.11.2014 16:34, Chanwoo Choi wrote:

This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
functional input/output port pins and 135 memory port pins. There are 41 general
port groups and 2 memory port groups.

Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Geunsik Lim geunsik@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
  drivers/pinctrl/samsung/pinctrl-exynos.c  | 163 ++
  drivers/pinctrl/samsung/pinctrl-samsung.c |   2 +
  drivers/pinctrl/samsung/pinctrl-samsung.h |   1 +
  3 files changed, 166 insertions(+)


Any plans for a respin? Apparently this patch needs a rebase. Also some 
comments below.




diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 8e3e0c0..bd4c4ec 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1268,6 +1268,169 @@ struct samsung_pin_ctrl exynos5420_pin_ctrl[] = {
},
  };

+/* pin banks of exynos5433 pin-controller - ALIVE */
+static struct samsung_pin_bank exynos5433_pin_banks0[] = {


Maybe instead the structure could be named exynos5433_pin_bank_alive? 
Similarly for remaining banks.


Also please, if not done already, please remember about documenting 
alias IDs of particular controllers in DT binding documentation.



+   EXYNOS_PIN_BANK_EINTW(8, 0x000, gpa0, 0x00),
+   EXYNOS_PIN_BANK_EINTW(8, 0x020, gpa1, 0x04),
+   EXYNOS_PIN_BANK_EINTW(8, 0x040, gpa2, 0x08),
+   EXYNOS_PIN_BANK_EINTW(8, 0x060, gpa3, 0x0c),
+};
+
+/* pin banks of exynos5433 pin-controller - AUD */
+static struct samsung_pin_bank exynos5433_pin_banks1[] = {
+   EXYNOS_PIN_BANK_EINTG(7, 0x000, gpz0, 0x00),
+   EXYNOS_PIN_BANK_EINTG(4, 0x020, gpz1, 0x04),
+};
+
+/* pin banks of exynos5433 pin-controller - CPIF */
+static struct samsung_pin_bank exynos5433_pin_banks2[] = {
+   EXYNOS_PIN_BANK_EINTG(2, 0x000, gpv6, 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - eSE */
+static struct samsung_pin_bank exynos5433_pin_banks3[] = {
+   EXYNOS_PIN_BANK_EINTG(3, 0x000, gpj2, 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FINGER */
+static struct samsung_pin_bank exynos5433_pin_banks4[] = {
+   EXYNOS_PIN_BANK_EINTG(4, 0x000, gpd5, 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FSYS */
+static struct samsung_pin_bank exynos5433_pin_banks5[] = {
+   EXYNOS_PIN_BANK_EINTG(6, 0x000, gph1, 0x00),
+   EXYNOS_PIN_BANK_EINTG(7, 0x020, gpr4, 0x04),
+   EXYNOS_PIN_BANK_EINTG(5, 0x040, gpr0, 0x08),
+   EXYNOS_PIN_BANK_EINTG(8, 0x060, gpr1, 0x0c),
+   EXYNOS_PIN_BANK_EINTG(2, 0x080, gpr2, 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, gpr3, 0x14),
+};
+
+/* pin banks of exynos5433 pin-controller - IMEM */
+static struct samsung_pin_bank exynos5433_pin_banks6[] = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x000, gpf0, 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - NFC */
+static struct samsung_pin_bank exynos5433_pin_banks7[] = {
+   EXYNOS_PIN_BANK_EINTG(3, 0x000, gpj0, 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - PERIC */
+static struct samsung_pin_bank exynos5433_pin_banks8[] = {
+   EXYNOS_PIN_BANK_EINTG(6, 0x000, gpv7, 0x00),
+   EXYNOS_PIN_BANK_EINTG(5, 0x020, gpb0, 0x04),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, gpc0, 0x08),
+   EXYNOS_PIN_BANK_EINTG(2, 0x060, gpc1, 0x0c),
+   EXYNOS_PIN_BANK_EINTG(6, 0x080, gpc2, 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, gpc3, 0x14),
+   EXYNOS_PIN_BANK_EINTG(2, 0x0c0, gpg0, 0x18),
+   EXYNOS_PIN_BANK_EINTG(4, 0x0e0, gpd0, 0x1c),
+   EXYNOS_PIN_BANK_EINTG(6, 0x100, gpd1, 0x20),
+   EXYNOS_PIN_BANK_EINTG(8, 0x120, gpd2, 0x24),
+   EXYNOS_PIN_BANK_EINTG(5, 0x140, gpd4, 0x28),
+   EXYNOS_PIN_BANK_EINTG(2, 0x160, gpd8, 0x2c),
+   EXYNOS_PIN_BANK_EINTG(7, 0x180, gpd6, 0x30),
+   EXYNOS_PIN_BANK_EINTG(3, 0x1a0, gpd7, 0x34),
+   EXYNOS_PIN_BANK_EINTG(5, 0x1c0, gpg1, 0x38),
+   EXYNOS_PIN_BANK_EINTG(2, 0x1e0, gpg2, 0x3c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x200, gpg3, 0x40),
+};
+
+/* pin banks of exynos5433 pin-controller - TOUCH */
+static struct samsung_pin_bank exynos5433_pin_banks9[] = {
+   EXYNOS_PIN_BANK_EINTG(3, 0x000, gpj1, 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
+ * four gpio/pin-mux/pinconfig controllers.


Looks like four is a copy/paste error here.

Sorry for the delay. Unfortunately things are quite busy on my side 
nowadays.


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 V3 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-28 Thread Tomasz Figa

On 10.12.2014 17:39, Vivek Gautam wrote:

USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.

Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
---

Changes since V2:
  - Added documentation on alias for BUS1 pin controller block.

Changes since V1:
  - Added support for all pin banks which are part of BUS1 pin controller.

  .../devicetree/bindings/pinctrl/samsung-pinctrl.txt |1 +
  drivers/pinctrl/samsung/pinctrl-exynos.c|   19 +++
  2 files changed, 20 insertions(+)


Acked-by: Tomasz Figa tomasz.f...@gmail.com

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/2] pinctrl: exynos: Add AUDIO pin controller for exynos7

2014-12-28 Thread Tomasz Figa

On 19.12.2014 22:10, Padmavathi Venna wrote:

Audio IPs on Exynos7 require gpios available in AUDIO
pin controller block. So adding the AUDIO pinctrl support.

Signed-off-by: Padmavathi Venna padm...@samsung.com
---
  .../bindings/pinctrl/samsung-pinctrl.txt   |1 +
  drivers/pinctrl/samsung/pinctrl-exynos.c   |   10 ++
  2 files changed, 11 insertions(+), 0 deletions(-)


Acked-by: Tomasz Figa tomasz.f...@gmail.com

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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

2014-12-28 Thread Tomasz Figa

Nishanth, Tony,

On 24.12.2014 02:13, Nishanth Menon wrote:

On 12/23/2014 11:06 AM, Tony Lindgren wrote:

* Marek Szyprowski m.szyprow...@samsung.com [141223 02:51]:

From: Tomasz Figa t.f...@samsung.com

Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.

This patch is first step to make the driver not rely on availability of
writes to individual registers. This is achieved by refactoring the
driver to use a commit-like operation scheme: all register values are
prepared first and stored in an instance of l2x0_regs struct and then a
single callback is responsible to flush those values to the hardware.


The first patch of the series applied things boot with no problem.
But after applying this one I get the following on am437x:

Unhandled fault: imprecise external abort (0xc06) at 0xb6f33884

Probably the same issue Nishanth mentioned.



yep - just finished the bisect... came to the same conclusion..

c8c3a07fa6a8e9b27a1658e0d305b6f7e0fa068f is the first bad commit
commit c8c3a07fa6a8e9b27a1658e0d305b6f7e0fa068f
Author: Tomasz Figa t.f...@samsung.com
Date:   Tue Dec 23 11:48:30 2014 +0100

 ARM: l2c: Refactor the driver to use commit-like interface

 Certain implementations of secure hypervisors (namely the one found on
 Samsung Exynos-based boards) do not provide access to individual L2C
 registers. This makes the .write_sec()-based interface
insufficient and
 provoking ugly hacks.

 This patch is first step to make the driver not rely on
availability of
 writes to individual registers. This is achieved by refactoring the
 driver to use a commit-like operation scheme: all register values are
 prepared first and stored in an instance of l2x0_regs struct and
then a
 single callback is responsible to flush those values to the hardware.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

:04 04 74c6c74a0dc0612d124cd759951adf2a1e4124ee
8082aabb474f8659231de744d87cd8dbd6dd79bb M  arch


$ git bisect log
git bisect start
# good: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1
git bisect good 97bf6af1f928216fd6c5a66e8a57bfa95a659672
# bad: [9afe195db6558621bd8bac379ed65ef121930684] ARM: dts: exynos4:
Add nodes for L2 cache controller
git bisect bad 9afe195db6558621bd8bac379ed65ef121930684
# bad: [0a89ef4dd870bbf692e30fef6c8182d7b8b42e17] ARM: l2c: Get outer
cache .write_sec callback from mach_desc only if not NULL
git bisect bad 0a89ef4dd870bbf692e30fef6c8182d7b8b42e17
# bad: [c8c3a07fa6a8e9b27a1658e0d305b6f7e0fa068f] ARM: l2c: Refactor
the driver to use commit-like interface
git bisect bad c8c3a07fa6a8e9b27a1658e0d305b6f7e0fa068f
# good: [080ab387c653b8655dc1ee790658b618399db2aa] ARM: OMAP2+: use
common l2cache initialization code
git bisect good 080ab387c653b8655dc1ee790658b618399db2aa




May I ask you (or anyone else working on OMAP) to try to figure out what 
the issue is? It is stopping L2 cache support for Exynos4 being merged 
and Exynos people don't have access to any of affected boards to do 
anything about it. After all, this is generic code, so I believe 
community should cooperate with pushing it forward. (Of course I 
understand it is a holiday season at the moment, so I don't expect any 
solution right at this moment :))


Apparently patch 1/8 solved problems with some of the boards. Could you 
check how those boards differ and look for potential causes?


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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

2014-12-08 Thread Tomasz Figa
2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk:
 On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote:
 On 12/05/2014 10:10 AM, Nishanth Menon wrote:
  Case #2: Reverting the following allows boot.
 
  From next-20141204
  10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings
  revert this  - boot still fails
 
  d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from
  mach_desc only if not NULL
  revert this  - boot still fails
 
  46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C
  revert this  - boot still fails
 
  c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like
  revert this  - boot passed (first bad commit).
 
 

 + linux-samsung soc and updated Thomaz's mail ID (gmail now).

 Given where we are in the cycle (-final likely this weekend) the only
 thing we can do right now is to drop the patch set; exynos (and mvebu)
 will have to wait another cycle until this patch set (hopefully in a
 revised form) can be merged.

Or a fix could be queued on top of this. Since (I believe) this series
has been queued for 3.19, we have 6 or 7 RC releases ahead, which
could be used for the purpose of fixing things (as they are supposed
to?).


 I think we need 8208/1 split up into smaller changes so that the cause
 of this regression can be found.

I'm afraid we need more than that.

First of all, this series has been in the wild for more than 3 months
already, without any serious changes. Need not to mention that mailing
lists and maintainers of all potentially affected platforms had been
added. It had been noted in cover letter that the only platform I (and
Marek later) could test on was Exynos and that it would be good if
somebody working with other platforms could test the patches.

Looks like nobody cared back then, so why should we care that much
now, especially that we have several RC releases ahead and we can
still fix this?

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 3/5] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated

2014-12-01 Thread Tomasz Figa
2014-12-01 17:37 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:

 On nie, 2014-11-30 at 21:19 +0900, Tomasz Figa wrote:
 Hi Krzysztof,

 2014-11-28 23:08 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
  On pią, 2014-11-28 at 15:04 +0100, Linus Walleij wrote:
  On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski
  k.kozlow...@samsung.com wrote:
 
   The audio subsystem on Exynos 5420 has separate clocks and GPIO. To
   operate properly on GPIOs the main block clock 'mau_epll' must be
   enabled.
  
   This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0)
   after introducing runtime PM to pl330 DMA driver. After that commit the
   'mau_epll' was gated, because the amba clock was disabled and there
   were no more users of mau_epll.
  
   The system hang just before probing i2s0 because
   samsung_pinmux_setup() tried to access memory from audss block which was
   gated.
  
   Add a clock property to the pinctrl driver and enable the clock during
   GPIO setup. During normal GPIO operations (set, get, set_direction) the
   clock is not enabled.

 Could you make sure that possibility of gating this clock is worth the
 effort of adding gating code to all affected drivers? If there is no
 significant change in power consumption maybe it could be simply keep
 running all the time?

 I had an impression that last time you disliked such idea:
 http://www.spinics.net/lists/arm-kernel/msg338127.html
 That's why I developed these patches. Because keeping a clock always on,
 even when it is unused, is undesirable.

I was mostly concerned about the particular solution implemented by
that patch that kept the clocks enabled on all platforms, not only the
affected one. However...


 Anyway, I did some simple measurements (after booting Arndale Octa
 to /bin/sh, idle):
  - with mau_epll gated: ~523 mA
  - with mau_epll always on: ~531 mA

 Keeping it on increases energy usage by 1.5% in idle (with measurement
 uncertainty ~0.4%).


...this definitely shows that the effort isn't worthless, which means
that your patch goes in the right direction.


 Also isn't a similar problem happening due to power domains? I believe
 the whole maudio block is located in a separate power domain but
 somehow it doesn't get turned off?

 There is Maudio power domain... but I think it is not related here.

Could you somehow check what happens when the maudio power domain is
turned off and maudio pin controller is accessed? Could you also check
the difference in power consumption with this domain powered on and
off?

 Pinctrl driver does not have runtime PM and is not attached to a domain.
 I thought about other solution to this problem (with utilization of
 power domains):
  - add runtime PM to pinctrl and audss clocks,
  - attach pinctrl and audss clocks to maudio power domain,
  - enable the clock when power domain is turned on.
 However almost the same changes had to be added to pinctrl and audss
 clocks drivers (replace clock_enable() with pm_runtime_get_sync()).

Well, if the dependency is there due to hardware design, I think it
needs to be reflected in the drivers as well.

Few other issues that came to my mind:

 - Your previous patch added clock control only to pinctrl operations.
Shouldn't GPIO operations be included as well?

 - If power domain dependency is there too, what happens with GPIO
pins if the domain is powered off? If they lose their states, wouldn't
it necessary to keep the domain powered on whenever there is some GPIO
pin requested (which usually = in use)? (I'd assume that special
functions shouldn't take a reference on runtime PM, because they are
related to IP blocks in the same PM domain, which will implicitly keep
the domain powered on.)

 - Doesn't the clock controller also lose its state whenever the power
domain is powered off? I guess that would be similar to ISP clock
controller, issues of which are still not resolved in mainline.
Sylwester could tell you more about this, I guess.

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 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-01 Thread Tomasz Figa
Hi Vivek,

Please see my comments below.

2014-11-24 22:02 GMT+09:00 Vivek Gautam gautam.vi...@samsung.com:
 USB and Power regulator on Exynos7 require gpios available
 in BUS1 pin controller block.
 So adding the BUS1 pinctrl support.

 Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Linus Walleij linus.wall...@linaro.org
 ---

 This patch was part of series:
 [PATCH 00/11] Exynos7: Adding USB 3.0 support
  https://lkml.org/lkml/2014/11/21/247

 Changes since V1:
  - Added support for all pin banks which are part of BUS1 pin controller.

  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
  1 file changed, 19 insertions(+)

I have missed this with previous patch, but DT bindings documentation
should list all aliases for all supported compatible strings, because
they are required for correct operation. There is a small section
about aliases in [1] already, so please add there information about
aliases for Exynos7 pin controllers along with their names, e.g.

Aliases for controllers compatible with samsung,exynos7-pinctrl:
 - pinctrl0: pin controller of ALIVE block,
 - pinctrl1: pin controller of BUS0 block,
 [...]
 - pinctrl8: pin controller of BUS1 block.

[1] Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt

I guess you can do this in separate patch or respin this one with this added.

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 v3 3/5] pinctrl: exynos: add exynos5410 SoC specific data

2014-11-30 Thread Tomasz Figa
Hi Andreas,

2014-11-28 21:07 GMT+09:00 Andreas Färber afaer...@suse.de:
 Am 28.11.2014 um 12:59 schrieb Linus Walleij:
 On Sat, Nov 22, 2014 at 11:26 PM, Andreas Färber afaer...@suse.de wrote:

 From: Hakjoo Kim ruppi@hardkernel.com

 Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
 support for all platforms based on EXYNOS5410.

 Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
 [AF: Rebased onto Exynos5260 and irq_chip consolidation]
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  v2 - v3:
  * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)

  v1 - v2:
  * Filled in Sob from Hakjoo Kim

 Is this based on the pinctrl devel branch so I can apply it?

 It was based on the Samsung for-next tree. I can rebase if needed.

Yes, please rebase (and please make sure that all the structs are
const, which became possible after recent changes). Otherwise the
patch looks good.

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 3/5] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated

2014-11-30 Thread Tomasz Figa
Hi Krzysztof,

2014-11-28 23:08 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 On pią, 2014-11-28 at 15:04 +0100, Linus Walleij wrote:
 On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski
 k.kozlow...@samsung.com wrote:

  The audio subsystem on Exynos 5420 has separate clocks and GPIO. To
  operate properly on GPIOs the main block clock 'mau_epll' must be
  enabled.
 
  This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0)
  after introducing runtime PM to pl330 DMA driver. After that commit the
  'mau_epll' was gated, because the amba clock was disabled and there
  were no more users of mau_epll.
 
  The system hang just before probing i2s0 because
  samsung_pinmux_setup() tried to access memory from audss block which was
  gated.
 
  Add a clock property to the pinctrl driver and enable the clock during
  GPIO setup. During normal GPIO operations (set, get, set_direction) the
  clock is not enabled.

Could you make sure that possibility of gating this clock is worth the
effort of adding gating code to all affected drivers? If there is no
significant change in power consumption maybe it could be simply keep
running all the time?

Also isn't a similar problem happening due to power domains? I believe
the whole maudio block is located in a separate power domain but
somehow it doesn't get turned off?

Could you investigate the above, please?

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 01/19] pinctrl: exynos: Add support for Exynos5433

2014-11-27 Thread Tomasz Figa
2014-11-27 20:45 GMT+09:00 Arnd Bergmann a...@arndb.de:
 On Thursday 27 November 2014 16:34:58 Chanwoo Choi wrote:
 +
 +/*
 + * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
 + * four gpio/pin-mux/pinconfig controllers.
 + */
 +struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
 +   {
 +   /* pin-controller instance 0 data */
 +   .pin_banks  = exynos5433_pin_banks0,
 +   .nr_banks   = ARRAY_SIZE(exynos5433_pin_banks0),
 +   .eint_wkup_init = exynos_eint_wkup_init,
 +   .suspend= exynos_pinctrl_suspend,
 +   .resume = exynos_pinctrl_resume,
 +   .label  = exynos5433-gpio-ctrl0,
 +   }, {


 I'm counting nine controllers, not four ;-)

 These seem to all be fairly regular,

Yup, especially considering what Chanwoo mentioned about the great
idea someone came up with about putting EINT registers of one of the
controllers in different pin controller.

 my impression is that with the
 move to arm64, you should come up with a new binding that can fully
 describe each controller so you don't have to add new code and bindings
 for each future SoC that uses the same scheme.

Still, this is exactly the same thing I thought when initially refactoring this
driver 2 years ago and what was dismissed at that time due to people
supposedly not wanting that much data in DT. If this point of view has changed,
then I fully support your view, though.

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: [RFC 2/2] clk: samsung: Fix clock disable failure because domain being gated

2014-11-25 Thread Tomasz Figa
Hi Krzysztof,

Please see my comments inline.

2014-11-25 0:18 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 +static int audss_clk_gate_enable(struct clk_hw *hw)
 +{
 +   int ret;
 +
 +   if (!IS_ERR(pll_in))
 +   clk_prepare_enable(pll_in);

Calling clk_prepare_enable() from enable() callback doesn't look like
a good idea, because enabling is not supposed to sleep, while
preparing might do so.

I guess you have to pre-prepare this clock in probe and then only call
enable here.

 +   ret = clk_gate_ops.enable(hw);
 +   if (!IS_ERR(pll_in))
 +   clk_disable_unprepare(pll_in);
 +
 +   return ret;
 +}

[snip]

 +/* TODO: Also mux and div */
 +const struct clk_ops audss_clk_gate_ops = {

nit: static const probably?

 +   .enable = audss_clk_gate_enable,
 +   .disable = audss_clk_gate_disable,
 +   .is_enabled = audss_clk_gate_is_enabled,
 +};

As for the approach itself, maybe you should simply register fully
custom clocks with clk_register(), without altering
clk_register_gate() at all and simply calling gate ops whenever
necessary? I don't know, just a loose idea.

By the way, this issue could be probably solved by integrating generic
clocks with regmap API, since regmap-mmio can automatically control a
clock.

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


Samsung pinctrl patches for v3.19

2014-11-09 Thread Tomasz Figa
Hi Linus,

Please consider the following pull request containing queued changes for
pinctrl-samsung driver. I'm sorry for all the delays in handling this. Things
should get better from now on, though.

Best regards,
Tomasz

-

The following changes since commit 6e08d6bbebebcf70f982d7190c4b6dc456cedd57:

  pinctrl: Add Intel Cherryview/Braswell pin controller support (2014-11-04 
11:21:02 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-pinctrl.git 
tags/for_3.19/samsung-pinctrl

for you to fetch changes up to 2891ba2906b6d2fd453042f410a11e6fc3edc37d:

  pinctrl: exynos: Add support for Exynos4415 (2014-11-09 22:28:07 +0900)


Samsung pinctrl patches for v3.19

1) pinctrl-samsung data structure clean-up

8100cf4 pinctrl: samsung: Separate per-bank init and runtime data
1bf00d7 pinctrl: samsung: Constify samsung_pin_ctrl struct
94ce944 pinctrl: samsung: Constify samsung_pin_bank_type struct
e06deff pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct
8799327 pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()

2) pinctrl-samsung Exynos7 support

50cea0c pinctrl: exynos: Add initial driver data for Exynos7
14c255d pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts
6f5e41b pinctrl: exynos: Consolidate irq domain callbacks
0d3d30d pinctrl: exynos: Generalize the eint16_31 demux code

3) pinctrl-samsung Exynos4415 support

2891ba2 pinctrl: exynos: Add support for Exynos4415


Abhilash Kesavan (3):
  pinctrl: exynos: Generalize the eint16_31 demux code
  pinctrl: exynos: Consolidate irq domain callbacks
  pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

Naveen Krishna Ch (1):
  pinctrl: exynos: Add initial driver data for Exynos7

Tomasz Figa (6):
  pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()
  pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct
  pinctrl: samsung: Constify samsung_pin_bank_type struct
  pinctrl: samsung: Constify samsung_pin_ctrl struct
  pinctrl: samsung: Separate per-bank init and runtime data
  pinctrl: exynos: Add support for Exynos4415

 .../bindings/pinctrl/samsung-pinctrl.txt   |   3 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   | 376 +++--
 drivers/pinctrl/samsung/pinctrl-exynos.h   |   3 +
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c  |  30 +-
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c  |  31 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c  | 131 +++
 drivers/pinctrl/samsung/pinctrl-samsung.h  |  82 +++--
 7 files changed, 435 insertions(+), 221 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2] pinctrl: exynos: Add support for Exynos4415

2014-11-06 Thread Tomasz Figa
Hi Chanwoo,

2014-11-07 15:23 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com:
 Dear Linus,

 Could you please review this patch?

I'll take care of this during this weekend.

Sorry for all the delays, but I was in the middle of relocation to
another country and I just didn't have enough time yet to collect all
the patches.

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/5] ARM: EXYNOS: Add EXYNOS4415 SoC ID

2014-10-24 Thread Tomasz Figa
Hi Chanwoo,

On 20.10.2014 05:32, Chanwoo Choi wrote:
 This patch add Exynos4415's SoC ID. Exynos4415 is based on the 32-bit RISC
 processor for Smartphone. Exynos4415 uses Cortex A9 quad-cores and has a 
 target
 speed of 1.6GHz and provides 8.5GB/s memory bandwidth.
 
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig  | 5 +
  arch/arm/mach-exynos/common.h | 8 
  arch/arm/mach-exynos/exynos.c | 2 ++
  3 files changed, 15 insertions(+)
 
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index 46f3c0d..349c867 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -75,6 +75,11 @@ config SOC_EXYNOS4412
   default y
   depends on ARCH_EXYNOS4
  
 +config SOC_EXYNOS4415
 + bool SAMSUNG EXYNOS4415
 + default y
 + depends on ARCH_EXYNOS4
 +
  config SOC_EXYNOS5250
   bool SAMSUNG EXYNOS5250
   default y
 diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
 index d4d09bc..ffc0c22 100644
 --- a/arch/arm/mach-exynos/common.h
 +++ b/arch/arm/mach-exynos/common.h
 @@ -21,6 +21,7 @@
  #define EXYNOS4210_CPU_ID0x4321
  #define EXYNOS4212_CPU_ID0x4322
  #define EXYNOS4412_CPU_ID0xE4412200
 +#define EXYNOS4415_CPU_ID0xE4415000
  #define EXYNOS4_CPU_MASK 0xFFFE
  
  #define EXYNOS5250_SOC_ID0x4352
 @@ -42,6 +43,7 @@ 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)
 +IS_SAMSUNG_CPU(exynos4415, EXYNOS4415_CPU_ID, EXYNOS4_CPU_MASK)

Is there a need for this legacy helper for this SoC?

  IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
  IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
  IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
 @@ -72,6 +74,12 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, 
 EXYNOS5_SOC_MASK)
  # define soc_is_exynos4412() 0
  #endif
  
 +#if defined(CONFIG_SOC_EXYNOS4415)
 +# define soc_is_exynos4415() is_samsung_exynos4415()
 +#else
 +# define soc_is_exynos4415() 0
 +#endif

Ditto.

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: [PATCHv3 2/3] ARM: dts: Add sleep mode pin configuration for exynos3250-rinato

2014-10-24 Thread Tomasz Figa
Hi Chanwoo,

On 24.10.2014 13:39, Chanwoo Choi wrote:
 This patch add sleep mode pin configuration using pinctrl subsystem
 to reduce leakage power-consumption of gpio pin in sleep state.
 
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park Kyungmin p...@samsung.com

I suspect a typo in this email address. Kukjin, is this something you
could fix up when applying (other patches in this series have it correct)?

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 0/6] Add initial support for pinctrl on Exynos7

2014-10-24 Thread Tomasz Figa
Hi Linus,

On 24.10.2014 14:01, Linus Walleij wrote:
 On Mon, Oct 20, 2014 at 4:01 PM, Abhilash Kesavan
 kesavan.abhil...@gmail.com wrote:
 
 Can you please pick this series up.
 
 Yes, sorry for the delay. I've applied patches
 1,2,3,4. The patches to the DTS files should be taken
 through whatever tree funnels arm64 dts files.
 
 I hope Tomasz can rebase his nice
 clean-up patches on top of this now.

Unfortunately I have quite a busy week right now, preparing for
relocation, so I will not be able to take care of this probably until
next weekend when I settle in my destination place. Sorry for the delay.

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 2/5] clk: samsung: exynos4415: Add clocks using common clock framework

2014-10-24 Thread Tomasz Figa
On 24.10.2014 15:18, Daniel Drake wrote:
 On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch adds the new clock driver of Exynos4415 SoC based on Cortex-A9
 using common clock framework. The CMU (Clock Management Unit) of Exynos4415
 controls PLLs(Phase Locked Loops) and generates system clocks for CPU, buses
 and function clocks for individual IPs.
 
 There seems to be a lot in common here with other exynos4 variants in
 clk-exynos4.c. Have you considered just adding support for the 4415 in
 the existing driver?

I tried when I was still at Samsung and the outcome was far from being
nice. There are certain differences, such as separate address spaces of
few clock controllers and different bit fields in apparently similar
registers, which made resulting code quite ugly.

Also another advantage of separate driver is that it can be made without
duplicating initial fails of the driver for Exynos4, such as private
bindings for external clocks or clock controllers in different power
domains grouped together into one big logical clock controller, because
at development time they looked so (contiguous address space).

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 5/5] ARM: dts: Add dts files for Exynos4415 SoC

2014-10-24 Thread Tomasz Figa
On 24.10.2014 15:23, Daniel Drake wrote:
 On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch adds new exynos4415.dtsi to support Exynos4415 SoC
 based on Cortex-A9 quad cores and includes following dt nodes:
 
 There's a lot in common between your new exynos4415.dtsi and the
 existing exynos4.dtsi.
 Would it make more sense for the 4415 code to extend the existing
 exynos4.dtsi like the other Exynos4 variants do?

This would make sense, but then existing Exynos 4 device tree sources
would have to be refactored to use reference-based syntax for extending
nodes. (Which is desirable anyway, but adds quite a bit of effort and
could be prone to conflicts.) I'd say that they could be merged later
anyway.

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 6/7] arm64: dts: Add nodes for mmc, i2c, rtc, watchdog on Exynos7

2014-10-21 Thread Tomasz Figa
On 21.10.2014 15:52, Alim Akhtar wrote:
 +mmc_0 {
 +   status = okay;
 +   num-slots = 1;
 +   broken-cd;
 +   caps2-mmc-hs200-1_8v;
 Please use mmc_hs200-1_8v instead.

I guess you mean mmc-hs200-1_8v (with a hyphen between mmc and hs200).

 +   supports-highspeed;
 As per synopsys-dw-mshc DT binding documentation, supports-highspeed
 property is deprecated, so please use common DT binding for this,
 which is cap-mmc-highspeed.
 +   non-removable;
 +   card-detect-delay = 200;
 +   clock-frequency = 8;
 +   samsung,dw-mshc-ciu-div = 3;
 +   samsung,dw-mshc-sdr-timing = 0 4;
 +   samsung,dw-mshc-ddr-timing = 0 2;
 +   pinctrl-names = default;
 +   pinctrl-0 = sd0_clk sd0_cmd sd0_qrdy sd0_bus1 sd0_bus4 
 sd0_bus8;
 +   bus-width = 8;
 +};
 +
 +mmc_2 {
 +   status = okay;
 +   num-slots = 1;
 +   supports-highspeed;
 Here also common DT binding please cap-sd-highspeed

Above you suggest cap-mmc-highspeed to replace the same deprecated
property, but here cap-sd-highspeed. What is the rationale behind
using only one particular new property and not both for both controllers?

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 v11 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

2014-10-20 Thread Tomasz Figa
On 20.10.2014 13:41, Thomas Abraham wrote:
 Changes since v10:
 - Rebased on top of v3.18-rc1
 
 This patch series removes the use of Exynos4210 and Exynos5250 specific 
 cpufreq
 drivers and enables the use of cpufreq-dt driver for these platforms. This
 series also enables cpufreq support for Exynos5420 using arm_big_little 
 cpufreq
 driver.
 
 This patch series is based and tested on v3.18-rc1 and depends on the patch
 - clk: exynos4: remove duplicate div_core2 divider clock instantiation
   
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34859.html)
   This patch has been merged in arm-soc/samsung/dt3 branch of arm-soc tree.
 

That patch actually went through clock tree, but it doesn't matter,
because AFAIK all the dependencies for this series are already in
3.18-rc1. I'll try to apply it in next days

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 v11 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

2014-10-20 Thread Tomasz Figa


On 20.10.2014 13:48, Thomas Abraham wrote:
 Hi Tomasz,
 
 On Mon, Oct 20, 2014 at 5:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 20.10.2014 13:41, Thomas Abraham wrote:
 Changes since v10:
 - Rebased on top of v3.18-rc1

 This patch series removes the use of Exynos4210 and Exynos5250 specific 
 cpufreq
 drivers and enables the use of cpufreq-dt driver for these platforms. This
 series also enables cpufreq support for Exynos5420 using arm_big_little 
 cpufreq
 driver.

 This patch series is based and tested on v3.18-rc1 and depends on the patch
 - clk: exynos4: remove duplicate div_core2 divider clock instantiation
   
 (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34859.html)
   This patch has been merged in arm-soc/samsung/dt3 branch of arm-soc 
 tree.


 That patch actually went through clock tree, but it doesn't matter,
 because AFAIK all the dependencies for this series are already in
 3.18-rc1. I'll try to apply it in next days
 
 Thanks. The patch clk: exynos4: remove duplicate div_core2 divider
 clock instantiation is not available in 3.18-rc1. So for testing, I
 picked this patch from samsung/dt3 branch from arm-soc tree.

Hmm? I can see it there:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/clk/samsung?id=v3.18-rc1

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 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-13 Thread Tomasz Figa
Hi Anton,

On 13.10.2014 06:54, Anton Tikhomirov wrote:
 Hi Vivek,
 
 Exynos7 also has a separate special gate clock going to the IP
 apart from the usual AHB clock. So add support for the same.
 
 As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
 by the driver. Adding only sclk is not enough. 
 

I'm quite interested in this discussion. Has it happened on mailing lists?

In general, previous SoCs also gave the possibility of controlling all
the bus clocks separately, in addition to bulk gates, but there was no
real advantage in using those, while burdening the clock tree with
numerous clocks. Isn't Exynos7 similar in this aspect?

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 0/5] pinctrl: samsung: Data structure clean-up

2014-10-11 Thread Tomasz Figa
On 08.10.2014 12:23, Linus Walleij wrote:
 On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 
 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data used
 at runtime, allowing unused variant data to be dropped and selected 
 structures
 constified to improve safety.
 
 Thanks!
 
 The patches missed the v3.18 merge window, but I have queued them up as
 the first thing to go into v3.19.

OK, thanks.

 
 Now I need you to help me check the patch set from Abhilash so I know
 what to do about that, whenever you have some time...

I've already acked previous version of that series, only with some minor
nitpicks pointed, but let me take a look at last version.

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 0/6] Add initial support for pinctrl on Exynos7

2014-10-11 Thread Tomasz Figa
Abhilash, Linus,

On 09.10.2014 15:54, Abhilash Kesavan wrote:
 Changes since v4:
   - Rebased over Tomasz Figa's pinctrl clean-up patches[1]
 
 Changes since v3:
   - Changed variable name from exynos_wkup_irq_chip to irq_chip
   - Added acked-by tag from Tomasz Figa
 
 Changes since v2:
   - Added a .irq_chip field to the samsung_pin_bank struct
   - Consolidated the wakeup and gpio irqd_ops
 
 Changes since v1:
   - Marked the newly created irq_chip instances as __initdata
   - Used kmemdup to keep a copy of the irq_chip
   - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM
   - Moved the pinctrl enablement for exynos7 into a separate patch
   - Added tested-by and reviewed-by tags from Thomas Abraham
 
 This series has been tested on linux-next (20141008)
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/ with
 the following dependencies and [1].
  
 a) Samsung Serial symbol clean-up for exynos7 serial driver enablement (v2)
http://www.spinics.net/lists/arm-kernel/msg366947.html
http://www.spinics.net/lists/arm-kernel/msg366948.html
 b) dts, kbuild: Implement support for dtb vendor subdirs patchset - rebased
http://comments.gmane.org/gmane.linux.kbuild.devel/12131
 c) arch: arm64: enable support for Samsung Exynos7 SoC patchset (v5) - 
 rebased
http://www.spinics.net/lists/arm-kernel/msg364014.html
 
 [1] https://lkml.org/lkml/2014/10/2/476
 
 Abhilash Kesavan (3):
   pinctrl: exynos: Generalize the eint16_31 demux code
   pinctrl: exynos: Consolidate irq domain callbacks
   pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts
 
 Naveen Krishna Ch (3):
   pinctrl: exynos: Add initial driver data for Exynos7
   arm64: dts: Add initial pinctrl support to EXYNOS7
   arm64: exynos: Enable pinctrl support for Exynos7
 
  .../bindings/pinctrl/samsung-pinctrl.txt   |3 +
  arch/arm64/Kconfig |2 +
  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi|  560 
 
  arch/arm64/boot/dts/exynos/exynos7.dtsi|   66 +++
  drivers/pinctrl/samsung/pinctrl-exynos.c   |  188 +--
  drivers/pinctrl/samsung/pinctrl-exynos.h   |3 +
  drivers/pinctrl/samsung/pinctrl-samsung.c  |2 +
  drivers/pinctrl/samsung/pinctrl-samsung.h  |3 +
  8 files changed, 791 insertions(+), 36 deletions(-)
  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
 

No further comments from me. Thanks Abhilash for addressing all of them.

Linus, feel free to apply this series with my ACK (which seems to be
already present in all patches).

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

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

Hmm, does this change really do the intended thing?

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

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


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

2014-10-02 Thread Tomasz Figa
On 02.10.2014 12:25, Inki Dae wrote:
 On 2014년 10월 02일 08:47, Joonyoung Shim wrote:
 Hi Tomasz,

 On 10/02/2014 12:13 AM, Tomasz Figa wrote:
 Hi Inki,

 On 17.09.2014 15:48, Inki Dae wrote:
 This interface and relevant codes aren't used anymore.


 Hmm, I might be missing something, but after removing this IOCTL, how do
 we obtain an offset to pass to mmap()?

 There is DRM_IOCTL_MODE_MAP_DUMB, it can get mmap offset before mmap and
 the offset is passed via mmap.
 
 Exactly. That will lead us to more generic world.

OK. Thanks Joonyoung, Inki, for quick response. I was confused by name
of this IOCTL. I'll modify my code to use 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


[PATCH v2 2/5] pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct

2014-10-02 Thread Tomasz Figa
There is no code using it and in fact there are pin controller variants
that do not even have this field initialized in their init data. This
patch removes it completely.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
Tested by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 22 --
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  4 
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  1 -
 drivers/pinctrl/samsung/pinctrl-samsung.h |  3 ---
 4 files changed, 30 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 003bfd874a61..67658d6d4b4e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -625,7 +625,6 @@ struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = s5pv210-gpio-ctrl0,
},
 };
 
@@ -672,7 +671,6 @@ struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos3250-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos3250_pin_banks1,
@@ -681,7 +679,6 @@ struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos3250-gpio-ctrl1,
},
 };
 
@@ -746,7 +743,6 @@ struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4210-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos4210_pin_banks1,
@@ -755,12 +751,10 @@ struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4210-gpio-ctrl1,
}, {
/* pin-controller instance 2 data */
.pin_banks  = exynos4210_pin_banks2,
.nr_banks   = ARRAY_SIZE(exynos4210_pin_banks2),
-   .label  = exynos4210-gpio-ctrl2,
},
 };
 
@@ -834,7 +828,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos4x12_pin_banks1,
@@ -843,7 +836,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl1,
}, {
/* pin-controller instance 2 data */
.pin_banks  = exynos4x12_pin_banks2,
@@ -851,7 +843,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl2,
}, {
/* pin-controller instance 3 data */
.pin_banks  = exynos4x12_pin_banks3,
@@ -859,7 +850,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl3,
},
 };
 
@@ -932,7 +922,6 @@ struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos5250-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos5250_pin_banks1,
@@ -940,7 +929,6 @@ struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
.eint_gpio_init

[PATCH v2 0/5] pinctrl: samsung: Data structure clean-up

2014-10-02 Thread Tomasz Figa
This series intends to clean up data structures used by pinctrl-samsung driver.
More specifically, it separates initial compile time constants from data used
at runtime, allowing unused variant data to be dropped and selected structures
constified to improve safety.

As a side effect, size of vmlinux built from multi_v7_defconfig was reduced
from:

 text databssdec  hexfilename
 10296708 1227100 313544 11837352 b49fa8 vmlinux

to:

 text databssdec  hexfilename
 10296740 1176860 313544 11787144 b3db88 vmlinux

and quite a bit of data were moved from normal data sections to .init.data:

pre:

Idx Name  Size  VMA   LMA   File off  Algn
  3 .rodata   0026c080  c0881000  c0881000  00681000  2**6
 23 .init.data0003ff7c  c0bdb830  c0bdb830  009e3830  2**3
 24 .data..percpu 2100  c0c1c000  c0c1c000  00a24000  2**6
 25 .data 000e98e0  c0c2  c0c2  00a28000  2**6

post:

Idx Name  Size  VMA   LMA   File off  Algn
  3 .rodata   0026bf20  c0881000  c0881000  00681000  2**6
 23 .init.data00041bbc  c0bdb830  c0bdb830  009e3830  2**3
 24 .data..percpu 2100  c0c1e000  c0c1e000  00a26000  2**6
 25 .data 000db860  c0c22000  c0c22000  00a2a000  2**6

This series should not introduce any functional changes.

Tested on S3C6410-based Mini6410 board booted using device tree, with GPIO
leds and GPIO keyboard. Compile tested for s3c24xx, exynos, s5pv210.

Changes since v1:
 - rebased on current devel branch of pinctrl tree.

Tomasz Figa (5):
  pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()
  pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct
  pinctrl: samsung: Constify samsung_pin_bank_type struct
  pinctrl: samsung: Constify samsung_pin_ctrl struct
  pinctrl: samsung: Separate per-bank init and runtime data

 drivers/pinctrl/samsung/pinctrl-exynos.c  | 111 ++
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  30 +++
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  31 
 drivers/pinctrl/samsung/pinctrl-samsung.c | 126 --
 drivers/pinctrl/samsung/pinctrl-samsung.h |  78 --
 5 files changed, 192 insertions(+), 184 deletions(-)

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


[PATCH v2 5/5] pinctrl: samsung: Separate per-bank init and runtime data

2014-10-02 Thread Tomasz Figa
Currently the driver mixes constant init data with runtime data, which
is far from being elegant and can invite potential hard to track issues.
This patch intends to solve this by introducing a new
samsung_pin_bank_data structure to hold only constant data known at
compile time, which can be copied to main samsung_pin_bank struct used
at runtime.

In addition, thanks to this change, all per-bank initdata can be marked
with const and __initconst keywords and dropped after init completes.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
Tested by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 44 +++
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  8 +++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  2 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c | 18 +++--
 drivers/pinctrl/samsung/pinctrl-samsung.h | 33 ---
 5 files changed, 72 insertions(+), 33 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 4659a1abc862..19497b4261ce 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -576,7 +576,7 @@ static void exynos_pinctrl_resume(struct 
samsung_pinctrl_drv_data *drvdata)
 }
 
 /* pin banks of s5pv210 pin-controller */
-static struct samsung_pin_bank s5pv210_pin_bank[] = {
+static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(4, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -626,7 +626,7 @@ const struct samsung_pin_ctrl s5pv210_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos3250 pin-controller 0 */
-static struct samsung_pin_bank exynos3250_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb,  0x08),
@@ -637,7 +637,7 @@ static struct samsung_pin_bank exynos3250_pin_banks0[] = {
 };
 
 /* pin banks of exynos3250 pin-controller 1 */
-static struct samsung_pin_bank exynos3250_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTN(8, 0x120, gpe0),
EXYNOS_PIN_BANK_EINTN(8, 0x140, gpe1),
EXYNOS_PIN_BANK_EINTN(3, 0x180, gpe2),
@@ -680,7 +680,7 @@ const struct samsung_pin_ctrl exynos3250_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos4210 pin-controller 0 */
-static struct samsung_pin_bank exynos4210_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -700,7 +700,7 @@ static struct samsung_pin_bank exynos4210_pin_banks0[] = {
 };
 
 /* pin banks of exynos4210 pin-controller 1 */
-static struct samsung_pin_bank exynos4210_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpj0, 0x00),
EXYNOS_PIN_BANK_EINTG(5, 0x020, gpj1, 0x04),
EXYNOS_PIN_BANK_EINTG(7, 0x040, gpk0, 0x08),
@@ -724,7 +724,7 @@ static struct samsung_pin_bank exynos4210_pin_banks1[] = {
 };
 
 /* pin banks of exynos4210 pin-controller 2 */
-static struct samsung_pin_bank exynos4210_pin_banks2[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks2[] __initconst 
= {
EXYNOS_PIN_BANK_EINTN(7, 0x000, gpz),
 };
 
@@ -756,7 +756,7 @@ const struct samsung_pin_ctrl exynos4210_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos4x12 pin-controller 0 */
-static struct samsung_pin_bank exynos4x12_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -773,7 +773,7 @@ static struct samsung_pin_bank exynos4x12_pin_banks0[] = {
 };
 
 /* pin banks of exynos4x12 pin-controller 1 */
-static struct samsung_pin_bank exynos4x12_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(7, 0x040, gpk0, 0x08),
EXYNOS_PIN_BANK_EINTG(7, 0x060, gpk1, 0x0c),
EXYNOS_PIN_BANK_EINTG(7, 0x080, gpk2, 0x10),
@@ -800,12 +800,12 @@ static struct samsung_pin_bank exynos4x12_pin_banks1[] = {
 };
 
 /* pin banks of exynos4x12 pin-controller 2 */
-static struct samsung_pin_bank exynos4x12_pin_banks2[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks2[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(7, 0x000, gpz, 0x00

[PATCH v2 4/5] pinctrl: samsung: Constify samsung_pin_ctrl struct

2014-10-02 Thread Tomasz Figa
In order to separate initialization constants from runtime data, this
patch modifies the driver to store only constant data in
samsung_pin_ctrl struct and copy data required at runtime to
samsung_pinctrl_drv_data struct. This makes it possible to mark all
existing instances of samsung_pin_ctrl struct as const and __initconst.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
Tested by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 39 +++---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 12 ++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 14 ++---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 86 +++
 drivers/pinctrl/samsung/pinctrl-samsung.h | 40 +++---
 5 files changed, 96 insertions(+), 95 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0f46391df3ea..4659a1abc862 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -222,8 +222,7 @@ static const struct irq_domain_ops exynos_gpio_irqd_ops = {
 static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
 {
struct samsung_pinctrl_drv_data *d = data;
-   struct samsung_pin_ctrl *ctrl = d-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = d-pin_banks;
unsigned int svc, group, pin, virq;
 
svc = readl(d-virt_base + EXYNOS_SVC_OFFSET);
@@ -270,8 +269,8 @@ static int exynos_eint_gpio_init(struct 
samsung_pinctrl_drv_data *d)
return -ENXIO;
}
 
-   bank = d-ctrl-pin_banks;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   bank = d-pin_banks;
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_GPIO)
continue;
bank-irq_domain = irq_domain_add_linear(bank-of_node,
@@ -441,8 +440,8 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
if (!wkup_np)
return -ENODEV;
 
-   bank = d-ctrl-pin_banks;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   bank = d-pin_banks;
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_WKUP)
continue;
 
@@ -499,9 +498,9 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
irq_set_chained_handler(irq, exynos_irq_demux_eint16_31);
irq_set_handler_data(irq, muxed_data);
 
-   bank = d-ctrl-pin_banks;
+   bank = d-pin_banks;
idx = 0;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_WKUP_MUX)
continue;
 
@@ -533,11 +532,10 @@ static void exynos_pinctrl_suspend_bank(
 
 static void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
-   struct samsung_pin_ctrl *ctrl = drvdata-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = drvdata-pin_banks;
int i;
 
-   for (i = 0; i  ctrl-nr_banks; ++i, ++bank)
+   for (i = 0; i  drvdata-nr_banks; ++i, ++bank)
if (bank-eint_type == EINT_TYPE_GPIO)
exynos_pinctrl_suspend_bank(drvdata, bank);
 }
@@ -569,11 +567,10 @@ static void exynos_pinctrl_resume_bank(
 
 static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
-   struct samsung_pin_ctrl *ctrl = drvdata-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = drvdata-pin_banks;
int i;
 
-   for (i = 0; i  ctrl-nr_banks; ++i, ++bank)
+   for (i = 0; i  drvdata-nr_banks; ++i, ++bank)
if (bank-eint_type == EINT_TYPE_GPIO)
exynos_pinctrl_resume_bank(drvdata, bank);
 }
@@ -616,7 +613,7 @@ static struct samsung_pin_bank s5pv210_pin_bank[] = {
EXYNOS_PIN_BANK_EINTW(8, 0xc60, gph3, 0x0c),
 };
 
-struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
+const struct samsung_pin_ctrl s5pv210_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 data */
.pin_banks  = s5pv210_pin_bank,
@@ -663,7 +660,7 @@ static struct samsung_pin_bank exynos3250_pin_banks1[] = {
  * Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC includes
  * two gpio/pin-mux/pinconfig controllers.
  */
-struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
+const struct samsung_pin_ctrl exynos3250_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 data */
.pin_banks  = exynos3250_pin_banks0,
@@ -735,7 +732,7 @@ static struct samsung_pin_bank exynos4210_pin_banks2[] = {
  * Samsung pinctrl driver data for Exynos4210 SoC. Exynos4210 SoC includes
  * three gpio/pin

[PATCH v2 1/5] pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()

2014-10-02 Thread Tomasz Figa
Currently the function returns a valid pointer on success and NULL on
error, so exact error code is lost. This patch changes return convention
of the function to use ERR_PTR() on error instead.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
Tested by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c 
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 4a47691c32b1..0504f0b75de8 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -988,7 +988,7 @@ static struct samsung_pin_ctrl 
*samsung_pinctrl_get_soc_data(
id = of_alias_get_id(node, pinctrl);
if (id  0) {
dev_err(pdev-dev, failed to get alias id\n);
-   return NULL;
+   return ERR_PTR(-ENOENT);
}
match = of_match_node(samsung_pinctrl_dt_match, node);
ctrl = (struct samsung_pin_ctrl *)match-data + id;
@@ -1040,9 +1040,9 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
}
 
ctrl = samsung_pinctrl_get_soc_data(drvdata, pdev);
-   if (!ctrl) {
+   if (IS_ERR(ctrl)) {
dev_err(pdev-dev, driver data not available\n);
-   return -EINVAL;
+   return PTR_ERR(ctrl);
}
drvdata-ctrl = ctrl;
drvdata-dev = dev;
-- 
2.1.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


[PATCH v2 3/5] pinctrl: samsung: Constify samsung_pin_bank_type struct

2014-10-02 Thread Tomasz Figa
This structure is not intended to be modified at runtime and functions
as constant data shared between multiple pin banks. This patch makes all
instances of it constant across the driver.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
Tested by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  |  6 +++---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  6 +++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 14 +++---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 20 +---
 drivers/pinctrl/samsung/pinctrl-samsung.h |  2 +-
 5 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 67658d6d4b4e..0f46391df3ea 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -46,12 +46,12 @@ static inline struct exynos_irq_chip 
*to_exynos_irq_chip(struct irq_chip *chip)
return container_of(chip, struct exynos_irq_chip, chip);
 }
 
-static struct samsung_pin_bank_type bank_type_off = {
+static const struct samsung_pin_bank_type bank_type_off = {
.fld_width = { 4, 1, 2, 2, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
 };
 
-static struct samsung_pin_bank_type bank_type_alive = {
+static const struct samsung_pin_bank_type bank_type_alive = {
.fld_width = { 4, 1, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
 };
@@ -127,7 +127,7 @@ static int exynos_irq_set_type(struct irq_data *irqd, 
unsigned int type)
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-   struct samsung_pin_bank_type *bank_type = bank-type;
+   const struct samsung_pin_bank_type *bank_type = bank-type;
struct samsung_pinctrl_drv_data *d = bank-drvdata;
unsigned int pin = irqd-hwirq;
unsigned int shift = EXYNOS_EINT_CON_LEN * pin;
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index e38925906bd3..9db6cf5c8823 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -44,12 +44,12 @@
 #define EINT_EDGE_BOTH 6
 #define EINT_MASK  0xf
 
-static struct samsung_pin_bank_type bank_type_1bit = {
+static const struct samsung_pin_bank_type bank_type_1bit = {
.fld_width = { 1, 1, },
.reg_offset = { 0x00, 0x04, },
 };
 
-static struct samsung_pin_bank_type bank_type_2bit = {
+static const struct samsung_pin_bank_type bank_type_2bit = {
.fld_width = { 2, 1, 2, },
.reg_offset = { 0x00, 0x04, 0x08, },
 };
@@ -143,7 +143,7 @@ static void s3c24xx_eint_set_handler(unsigned int irq, 
unsigned int type)
 static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
struct samsung_pin_bank *bank, int pin)
 {
-   struct samsung_pin_bank_type *bank_type = bank-type;
+   const struct samsung_pin_bank_type *bank_type = bank-type;
unsigned long flags;
void __iomem *reg;
u8 shift;
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index fcf8c36e727e..2a14db2826d8 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -68,32 +68,32 @@
 #define EINT_CON_MASK  0xF
 #define EINT_CON_LEN   4
 
-static struct samsung_pin_bank_type bank_type_4bit_off = {
+static const struct samsung_pin_bank_type bank_type_4bit_off = {
.fld_width = { 4, 1, 2, 0, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0, 0x0c, 0x10, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit_alive = {
+static const struct samsung_pin_bank_type bank_type_4bit_alive = {
.fld_width = { 4, 1, 2, },
.reg_offset = { 0x00, 0x04, 0x08, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit2_off = {
+static const struct samsung_pin_bank_type bank_type_4bit2_off = {
.fld_width = { 4, 1, 2, 0, 2, 2, },
.reg_offset = { 0x00, 0x08, 0x0c, 0, 0x10, 0x14, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit2_alive = {
+static const struct samsung_pin_bank_type bank_type_4bit2_alive = {
.fld_width = { 4, 1, 2, },
.reg_offset = { 0x00, 0x08, 0x0c, },
 };
 
-static struct samsung_pin_bank_type bank_type_2bit_off = {
+static const struct samsung_pin_bank_type bank_type_2bit_off = {
.fld_width = { 2, 1, 2, 0, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0, 0x0c, 0x10, },
 };
 
-static struct samsung_pin_bank_type bank_type_2bit_alive = {
+static const struct samsung_pin_bank_type bank_type_2bit_alive = {
.fld_width = { 2, 1, 2, },
.reg_offset = { 0x00, 0x04, 0x08

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

2014-10-02 Thread Tomasz Figa
On 02.10.2014 21:27, Daniel Drake wrote:
 Hi,
 
 Thanks for looking into this.
 
 On Wed, Oct 1, 2014 at 4:55 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
 I think that comment is incorrect. If tcmp is written as -1UL then the
 LED totally turns off. And there is nothing in the Exynos4412 manual
 to suggest that -1UL should be set in the TCMP register for 100% duty.

 Looking at Figure 11-3 in 11.3.2 Basic Timer Operation chapter of Exynos
 4412 public datasheet [1] (page 659), the calculation above seems
 correct. The default state of timer output is high and if TCMP is set to
 a value higher than TCNT, then it will never toggle to low.

 [1]
 http://www.samsung.com/global/business/semiconductor/file/product/Exynos_4_Quad_User_Manaul_Public_REV1.00-0.pdf
 
 I read that diagram a bit differently.
 The default state of the output is high, but that is while PWM is
 inactive. It goes low at the point when the timer starts, and it
 also goes low when the timer later restarts every time. So once we
 enable PWM the output should be low.

That's right. I believe this should match what I wrote in my mail.

 It will go high once TCMP == TCNT, but because TCMP is placed at the
 maximum value which is never hit, that will never happen, so the LED
 stays off.

Right. Although all the levels above don't take into account state of
the inverter. What's shown on the diagram in the datasheet is with
inverter disabled, which corresponds to Linux's PWM_POLARITY_INVERSED.

 
 But I am confused on a few counts here...
 
 I may have identified above why a maximum TCMP value would not result
 in the output going high, but then why does the rest of the brightness
 scale work? If I set brightness 200 (tcmp=6470, tcnt=2) then the
 LED is on dimly. If I set brightness 254 (tcmp=117, tcnt=2) then
 the LED comes on much brighter. But according to my above explanation
 and looking at the diagram you referenced, such a decrease in the tcmp
 value would result in a shorter time for which the output is high,
 i.e. lower brightness, but actually the brightness increases.

This is strange. I remember verifying various edge cases with a scope on
an Exynos4210-based Origen board and I don't recall any issues.
Unfortunately I don't have appropriate hardware to recheck this specific
case anymore.

Could you specify on what board you are testing this or how the LED is
wired?

 
 If the output is high by default, why don't I see the LED turning on
 in uboot before Linux has even loaded?

Most likely because u-boot doesn't switch the pinmux from default input
to respective special function.

 
 Does the above diagram really apply to Linux? Because Linux sets the
 invert bit for all the channels in pwm_samsung_probe. So maybe that
 diagram is irrelevant until we invert the TOUT signal shown there?

The diagram illustrates how the hardware works. It shows TOUT levels
without inverter enabled. Still, the inverter simply negates the signal,
so the diagram is applicable, just with the exception that you need to
consider the output inverted.

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/2] clk: samsung: exynos5440: move restart code into clock driver

2014-10-01 Thread Tomasz Figa
Hi Pankaj,

Please see my comments inline.

On 01.10.2014 07:48, Pankaj Dubey wrote:
 Let's register reboot_notifier for Exynos5440 from it's clock driver
 for reboot functionality. So that we can cleanup restart hooks from
 machine specific file.
 
 CC: Sylwester Nawrocki s.nawro...@samsung.com
 CC: Mike Turquette mturque...@linaro.org
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
  arch/arm/mach-exynos/exynos.c|   13 
  drivers/clk/samsung/clk-exynos5440.c |   37 
 ++
  2 files changed, 37 insertions(+), 13 deletions(-)
 
 diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
 index 2f2f7b2..d56134a 100644
 --- a/arch/arm/mach-exynos/exynos.c
 +++ b/arch/arm/mach-exynos/exynos.c
 @@ -143,19 +143,6 @@ static void exynos_restart(enum reboot_mode mode, const 
 char *cmd)
   u32 val = 0x1;
   void __iomem *addr = pmu_base_addr + EXYNOS_SWRESET;

You can remove the variables above as well...

  
 - if (of_machine_is_compatible(samsung,exynos5440)) {
 - u32 status;
 - np = of_find_compatible_node(NULL, NULL, 
 samsung,exynos5440-clock);
 -
 - addr = of_iomap(np, 0) + 0xbc;
 - status = __raw_readl(addr);
 -
 - addr = of_iomap(np, 0) + 0xcc;
 - val = __raw_readl(addr);
 -
 - val = (val  0x) | (status  0x);
 - }
 -
   __raw_writel(val, addr);

and make this use the constants instead.

  }
  
 diff --git a/drivers/clk/samsung/clk-exynos5440.c 
 b/drivers/clk/samsung/clk-exynos5440.c
 index 00d1d00..171d3af 100644
 --- a/drivers/clk/samsung/clk-exynos5440.c
 +++ b/drivers/clk/samsung/clk-exynos5440.c
 @@ -15,6 +15,8 @@
  #include linux/clk-provider.h
  #include linux/of.h
  #include linux/of_address.h
 +#include linux/notifier.h
 +#include linux/reboot.h
  
  #include clk.h
  #include clk-pll.h
 @@ -89,6 +91,38 @@ static const struct of_device_id ext_clk_match[] 
 __initconst = {
   {},
  };
  
 +static int exynos5440_clk_reboot_notify_handler(struct notifier_block *this,
 + unsigned long code, void *unused)
 +{
 + if (code == SYS_RESTART) {
 + struct device_node *np;
 + void __iomem *addr;
 + u32 val, status;
 +
 + np = of_find_compatible_node(NULL, NULL,
 + samsung,exynos5440-clock);
 +
 + addr = of_iomap(np, 0) + 0xbc;

You can just save the address in exynos5440_clk_init() and use it here
without the whole dance with DT and ioremap.

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 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver

2014-10-01 Thread Tomasz Figa
Hi Pankaj,

Please see my comments inline.

On 01.10.2014 07:49, Pankaj Dubey wrote:
 Let's register reboot_notifier from PMU driver for reboot
 functionality. So that we can remove restart hooks from
 machine specific file, and thus moving ahead when PMU moved
 to driver folder, this functionality can be reused for ARM64
 based Exynos SoC's.

[snip]

 +static int pmu_reboot_notify_handler(struct notifier_block *this,
 + unsigned long code, void *unused)
 +{
 + if (code == SYS_RESTART) {
 + u32 val = 0x1;
 +
 + pmu_raw_writel(val, EXYNOS_SWRESET);

As already mentioned for patch 1, no need for the variable, because this
is just a constant 1.

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: pwm-samsung: incorrect register values for 100% duty cycle

2014-10-01 Thread Tomasz Figa
Hi Daniel,

On 18.09.2014 01:42, Daniel Drake wrote:
 Hi,
 
 I'm using pwm-samsung on Exynos4412 for a variable-brightness LED.
 
 When the LED is set to maximum brightness via the pwm-leds driver, we
 arrive at pwm_samsung_config with duty_ns = period_ns, i.e. 100% duty
 cycle.
 
 This function does:
 
 /* -1UL will give 100% duty. */
 --tcmp;
 writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
 
 I think that comment is incorrect. If tcmp is written as -1UL then the
 LED totally turns off. And there is nothing in the Exynos4412 manual
 to suggest that -1UL should be set in the TCMP register for 100% duty.

Looking at Figure 11-3 in 11.3.2 Basic Timer Operation chapter of Exynos
4412 public datasheet [1] (page 659), the calculation above seems
correct. The default state of timer output is high and if TCMP is set to
a value higher than TCNT, then it will never toggle to low.

[1]
http://www.samsung.com/global/business/semiconductor/file/product/Exynos_4_Quad_User_Manaul_Public_REV1.00-0.pdf

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

According to my computations, with tcmp=0 you should get exactly the
minimum supported duty cycle (1 / N, where N is the number of ticks of
period), not full brightness. Are you sure that you have the right
output polarity configured?

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

Comparing few datasheets, the timers seem identical in this aspect.

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 2/4] ARM: exynos: Ensure PM domains are powered at initialization

2014-10-01 Thread Tomasz Figa
On 30.09.2014 20:33, Kevin Hilman wrote:
 Ulf Hansson ulf.hans...@linaro.org writes:
 
 At -probe() it's common practice for drivers/subsystems to bring their
 devices to full power and without depending on CONFIG_PM_RUNTIME.

 We could also expect that drivers/subsystems requires their device's
 corresponding PM domains to be powered, to successfully complete a
 -probe() sequence.

 Align to the behavior above, by ensuring all PM domains are powered
 prior initialization of a generic PM domain.

 Do note, since the generic PM domain will try to power off unused PM
 domains at late_init, there are no increased power consumption over
 time.
 
 IMO no increased power consumption is a bit misleading because
 boot-time power consumption may have a major increase when all power
 domains are powered on.  Sure, they will eventually (hopefully) be
 turned off in after late_initcall, but there will still be an impact.
 
 I guess the Samsung folks should comment here on whether that is
 significant.

Unfortunately this series has not been posted to linux-samsung-soc
mailing list and I'm a formerly-Samsung folk now, so it hasn't really
reached there.

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 2/2] drm/exynos: use drm generic mmap interface

2014-10-01 Thread Tomasz Figa
Hi Inki,

On 17.09.2014 15:48, Inki Dae wrote:
 This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
 to Exynos drm and instead uses drm generic mmap.

It looks like libdrm_exynos is still using DRM_EXYNOS_GEM_MMAP, but this
patch just removes it. This basically means that any application using
it is now broken. Do you have any plans to fix this?

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/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

2014-10-01 Thread Tomasz Figa
Hi Inki,

On 17.09.2014 15:48, Inki Dae wrote:
 This interface and relevant codes aren't used anymore.
 

Hmm, I might be missing something, but after removing this IOCTL, how do
we obtain an offset to pass to mmap()?

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 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC

2014-09-30 Thread Tomasz Figa
On 30.09.2014 17:12, Abhilash Kesavan wrote:
 Hi Tomasz,
 
 On Mon, Sep 22, 2014 at 2:22 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Abhilash,

 On 22.09.2014 06:47, Abhilash Kesavan wrote:
 Changes since v4:
 - Fixed comments from Tomasz Figa:
   - Changed the namespace prefix from exynos to samsung
   - Defined bindings to take all input clocks
   - Sorted the Kconfig entries alphabetically in clock Makefile
   - Used consistent 1 tab line breaks across the clock file
   - Statically initialized the samsung_cmu_info struct
 - Enabled exynos7 in the arm64 defconfig as per Catalin Marinas' comment.
 - Added Kukjin Kim's ack along with Thomas Abraham's tested and reviewed 
 tags.


 The clock patches look good to me, but since they are doing quite a lot
 of code moving I'd prefer to take them through clk tree. Based on the
 fact that there are no code dependencies between clock patches and
 remaining ones and Exynos7 is a new material for 3.18, I'm inclined to
 apply them to my tree if nobody minds.
 
 Will you be picking up the clock changes soon ?

I'd like to do so. Kukjin, since clock changes are a part of this
series, might I have your Ack for them to be applied separately?

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 2/2] arch: arm: samsung: Clean-up usage of CONFIG_SERIAL_SAMSUNG_UARTS symbol

2014-09-30 Thread Tomasz Figa
On 30.09.2014 17:13, Arnd Bergmann wrote:
 On Tuesday 30 September 2014 20:04:55 Abhilash Kesavan wrote:
 --- a/arch/arm/mach-s3c64xx/irq-pm.c
 +++ b/arch/arm/mach-s3c64xx/irq-pm.c
 @@ -55,10 +55,10 @@ static struct irq_grp_save {
 u32 mask;
  } eint_grp_save[5];
  
 -#ifndef CONFIG_SERIAL_SAMSUNG_UARTS
 -#define SERIAL_SAMSUNG_UARTS 0
 +#ifndef CONFIG_SERIAL_SAMSUNG
 +#define SERIAL_SAMSUNG_UARTS   0
  #else
 -#defineSERIAL_SAMSUNG_UARTS CONFIG_SERIAL_SAMSUNG_UARTS
 +#define SERIAL_SAMSUNG_UARTS   4
  #endif
  
  static u32 irq_uart_mask[SERIAL_SAMSUNG_UARTS];
 
 I think this won't work because now you access invalid registers
 on machines that have only three uarts.

Both S3C6400 and S3C6410 SoCs have 4 UART blocks. AFAICT
CONFIG_SERIAL_SAMSUNG_UARTS was always set to 4 on ARCH_S3C64XX.

 
 diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
 index 11fbbc2..03cafe9 100644
 --- a/arch/arm/plat-samsung/init.c
 +++ b/arch/arm/plat-samsung/init.c
 @@ -93,8 +93,8 @@ void __init s3c24xx_init_clocks(int xtal)
  #if IS_ENABLED(CONFIG_SAMSUNG_ATAGS)
  static int nr_uarts __initdata = 0;
  
 -#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
 -static struct s3c2410_uartcfg uart_cfgs[CONFIG_SERIAL_SAMSUNG_UARTS];
 +#ifdef CONFIG_SERIAL_SAMSUNG
 +static struct s3c2410_uartcfg uart_cfgs[4];

Abhilash: Instead of using 4 directly, you could define a constant for it.

  #endif
  
  /* s3c24xx_init_uartdevs
 @@ -110,7 +110,7 @@ void __init s3c24xx_init_uartdevs(char *name,
   struct s3c24xx_uart_resources *res,
   struct s3c2410_uartcfg *cfg, int no)
  {
 -#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
 +#ifdef CONFIG_SERIAL_SAMSUNG
 struct platform_device *platdev;
 struct s3c2410_uartcfg *cfgptr = uart_cfgs;
 struct s3c24xx_uart_resources *resp;
 
 Since you hardcode the number here now, you can actually drop this #ifdef.

I believe what Abhilash did is correct, because this code is not needed
when there is no serial support enabled.

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 2/2] arch: arm: samsung: Clean-up usage of CONFIG_SERIAL_SAMSUNG_UARTS symbol

2014-09-30 Thread Tomasz Figa


On 30.09.2014 20:36, Arnd Bergmann wrote:
 On Tuesday 30 September 2014 18:10:14 Tomasz Figa wrote:
 @@ -110,7 +110,7 @@ void __init s3c24xx_init_uartdevs(char *name,
   struct s3c24xx_uart_resources *res,
   struct s3c2410_uartcfg *cfg, int no)
  {
 -#ifdef CONFIG_SERIAL_SAMSUNG_UARTS
 +#ifdef CONFIG_SERIAL_SAMSUNG
 struct platform_device *platdev;
 struct s3c2410_uartcfg *cfgptr = uart_cfgs;
 struct s3c24xx_uart_resources *resp;

 Since you hardcode the number here now, you can actually drop this #ifdef.

 I believe what Abhilash did is correct, because this code is not needed
 when there is no serial support enabled.

 
 I only added the #ifdef here because it was broken when
 CONFIG_SERIAL_SAMSUNG_UARTS was undefined.

Fair enough. This isn't really that much code to really care and most
(if not all) use cases have UART enabled anyway.

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/2] tty: serial: samsung: Clean-up selection of number of available UARTs

2014-09-30 Thread Tomasz Figa
Abhilash,

On 30.09.2014 16:34, Abhilash Kesavan wrote:
 Remove symbols SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS which
 select the number of UART ports available on the SoC. Use the maximum
 number of UART ports possible across the serial driver in place of
 SERIAL_SAMSUNG_UARTS. Removal of these symbols also helps in Exynos7
 serial enablement.
 

AFAICT this patch should be second in the series, because it removes
symbols which are used by code that is yet to be updated in current patch 2.

Otherwise:

Reviewed-by: Tomasz Figa tomasz.f...@gmail.com

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


[GIT PULL] Samsung clock changes for v3.18

2014-09-29 Thread Tomasz Figa
The following changes since commit a52ae5a755d980e9ff812c6f45a415ba27bfd33b:

  Merge branch 'clk-fixes' into clk-next (2014-09-17 11:47:56 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git 
tags/for_3.18/samsung-clk

for you to fetch changes up to fa0111be4ff30150720db3c3e5ee8d7823921639:

  clk: samsung: exynos4: remove duplicate div_core2 divider clock instantiation 
(2014-09-24 12:41:33 +0200)


Samsung clock patches for v3.18

1) non-critical fixes (without the need to push to stable)

fa0111be4ff3 clk: samsung: exynos4: remove duplicate div_core2 divider clock 
instantiation
b511593d7165 clk: samsung: exynos4: fix g3d clocks
c14254300131 clk: samsung: exynos4: add missing smmu_g2d clock and update 
comments
22842d244af3 clk: samsung: exynos5260: fix typo in clock name
e82ba578ccde clk: samsung: exynos3250: fix width field of mout_mmc0/1
59037b92f440 clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock
5ce37f266650 clk: samsung: exynos3250: fix mout_cam_blk parent list

2) Clock driver extensions

07ccf02ba5c3 dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 
CMU
d0e73eaf1925 ARM: dts: exynos3250: Add CMU node for DMC domain clocks
e3c3f19bc618 clk: samsung: exynos3250: Register DMC clk provider
4676f0aab9dc clk: samsung: exynos4: add support for MOUT_HDMI and MOUT_MIXER 
clocks


Chander Kashyap (1):
  clk: samsung: exynos5260: fix typo in clock name

Krzysztof Kozlowski (3):
  clk: samsung: exynos3250: Register DMC clk provider
  ARM: dts: exynos3250: Add CMU node for DMC domain clocks
  dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU

Marek Szyprowski (3):
  clk: samsung: exynos4: add missing smmu_g2d clock and update comments
  clk: samsung: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
  clk: samsung: exynos4: fix g3d clocks

Pankaj Dubey (3):
  clk: samsung: exynos3250: fix mout_cam_blk parent list
  clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock
  clk: samsung: exynos3250: fix width field of mout_mmc0/1

Thomas Abraham (1):
  clk: samsung: exynos4: remove duplicate div_core2 divider clock 
instantiation

 .../devicetree/bindings/clock/exynos3250-clock.txt |  10 +-
 arch/arm/boot/dts/exynos3250.dtsi  |   6 +
 drivers/clk/samsung/clk-exynos3250.c   | 202 -
 drivers/clk/samsung/clk-exynos4.c  |  18 +-
 drivers/clk/samsung/clk-exynos5260.c   |   2 +-
 include/dt-bindings/clock/exynos3250.h |  27 +++
 include/dt-bindings/clock/exynos4.h|  12 +-
 7 files changed, 257 insertions(+), 20 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] serial: samsung: Fix serial config dependencies for exynos7

2014-09-29 Thread Tomasz Figa
Hi Abhilash,

The patch itself seems fine, but I wonder if those config options aren't
really just leftovers from the past and couldn't be completely removed.

On 29.09.2014 07:16, Abhilash Kesavan wrote:
 From: Pankaj Dubey pankaj.du...@samsung.com
 
 Exynos7 has a similar serial controller to that present in older Samsung
 SoCs. To re-use the existing serial driver on Exynos7 we need to have
 SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not
 possible because these symbols are dependent on PLAT_SAMSUNG which is
 not present for the ARMv8 based exynos7.
 
 Change the dependency of these symbols from PLAT_SAMSUNG to the serial
 driver thus making it available on exynos7. As the existing platform
 specific code making use of these symbols is related to uart driver this
 change in dependency should not cause any issues.
 
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
 Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig
 with and without the serial driver enabled.
 
  drivers/tty/serial/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
 index 81f6ee7..e6c0bcb 100644
 --- a/drivers/tty/serial/Kconfig
 +++ b/drivers/tty/serial/Kconfig
 @@ -249,14 +249,14 @@ config SERIAL_SAMSUNG
  
  config SERIAL_SAMSUNG_UARTS_4
   bool
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442)
   help
 Internal node for the common case of 4 Samsung compatible UARTs

The only place where this symbol is used is below.

  
  config SERIAL_SAMSUNG_UARTS
   int
 - depends on PLAT_SAMSUNG
 + depends on SERIAL_SAMSUNG
   default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
   default 3
   help
 

With this symbol the situation isn't that easy, but still should be
manageable.

Looking at the serial-samsung driver, all occurrences of
CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally
defined number equal to the maximum value - in this case 4.

There are also two places in arch/arm where this symbol is used:

1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial
ports which need suspend/resume handling. Since on s3c64xx the number is
always 4, it can be simply defined locally as a constant.

2) In arch/arm/plat-samsung/init.c it is used to determine size of a
static array of UART ports and to check whether the UART driver is
enabled. In former case I believe it should be safe to hardcode it to 4
as well, in latter CONFIG_SERIAL_SAMSUNG can 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 v3 3/6] pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

2014-09-29 Thread Tomasz Figa
Hi Abhilash,

Just two minor issues inline. I leave them up to Linus to decide.

Linus, if you don't mind them, feel free to apply this patch with my Ack.

On 29.09.2014 07:15, Abhilash Kesavan wrote:
 Exynos7 uses different offsets for wakeup interrupt configuration registers.
 So a new irq_chip instance for Exynos7 wakeup interrupts is added. The 
 irq_chip
 selection is now based on the wakeup interrupt controller compatible string.

[snip]

 @@ -469,12 +488,18 @@ static int exynos_eint_wkup_init(struct 
 samsung_pinctrl_drv_data *d)
   struct samsung_pin_bank *bank;
   struct exynos_weint_data *weint_data;
   struct exynos_muxed_weint_data *muxed_data;
 + struct exynos_irq_chip *exynos_wkup_irq_chip;

Quite an awful name for a local variable. irq_chip alone would be enough.

   unsigned int muxed_banks = 0;
   unsigned int i;
   int idx, irq;
  
   for_each_child_of_node(dev-of_node, np) {
 - if (of_match_node(exynos_wkup_irq_ids, np)) {
 + const struct of_device_id *match;
 +
 + match = of_match_node(exynos_wkup_irq_ids, np);
 + if (match) {
 + exynos_wkup_irq_chip = kmemdup(match-data,
 + sizeof(struct exynos_irq_chip), GFP_KERNEL);

sizeof(*exynos_wkup_irq_chip) (or irq_chip considering my comment above)
could be used instead.

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 v3 0/6] Add initial support for pinctrl on Exynos7

2014-09-29 Thread Tomasz Figa
On 29.09.2014 07:15, Abhilash Kesavan wrote:
 Changes since v1:
   - Marked the newly created irq_chip instances as __initdata
   - Used kmemdup to keep a copy of the irq_chip
   - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM
   - Moved the pinctrl enablement for exynos7 into a separate patch
   - Added tested-by and reviewed-by tags from Thomas Abraham
 
 Following patches have been tested on linux-next (20140926).
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
  
 Following patches are required for this series:
 1) tty/serial: fix config dependencies for samsung serial

 https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html
 2) dts, kbuild: Implement support for dtb vendor subdirs patchset 
http://comments.gmane.org/gmane.linux.kbuild.devel/12131
 3) arch: arm64: enable support for Samsung Exynos7 SoC patchset (v5)
http://www.spinics.net/lists/arm-kernel/msg364014.html
 
 Abhilash Kesavan (3):
   pinctrl: exynos: Generalize the eint16_31 demux code
   pinctrl: exynos: Consolidate irq domain callbacks
   pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts
 
 Naveen Krishna Ch (3):
   pinctrl: exynos: Add initial driver data for Exynos7
   arm64: dts: Add initial pinctrl support to EXYNOS7
   arm64: exynos: Enable pinctrl support for Exynos7
 
  .../bindings/pinctrl/samsung-pinctrl.txt   |3 +
  arch/arm64/Kconfig |2 +
  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi|  560 
 
  arch/arm64/boot/dts/exynos/exynos7.dtsi|   66 +++
  drivers/pinctrl/samsung/pinctrl-exynos.c   |  196 +--
  drivers/pinctrl/samsung/pinctrl-exynos.h   |3 +
  drivers/pinctrl/samsung/pinctrl-samsung.c  |2 +
  drivers/pinctrl/samsung/pinctrl-samsung.h  |3 +
  8 files changed, 799 insertions(+), 36 deletions(-)
  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
 

For patches 1-2, 4-6:

Acked-by: Tomasz Figa tomasz.f...@gmail.com

Linus, I have replied for patch 3 with 2 minor issues with coding style.
If you don't mind them, feel free to take the whole series with my Ack.

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/5] pinctrl: samsung: Data structure clean-up

2014-09-27 Thread Tomasz Figa
Hi Linus,

On 25.09.2014 09:49, Tomasz Figa wrote:
 On 25.09.2014 09:47, Linus Walleij wrote:
 On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote:

 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data 
 used
 at runtime, allowing unused variant data to be dropped and selected 
 structures
 constified to improve safety.

 I like the patch set, tried to apply it but patch 3/5 failed to apply to the
 devel branch for pinctrl.

 Can you rebase this on my devel branch, include Marek's Tested-by
 tag and resend, and I'll take it for v3.18.
 
 Sure. Will do that today evening. Probably clashed with some other
 changes queued in the meantime.

Uhm. I went back home and forgot about this series until now. Sorry.

I have rebased it on your devel branch, although it seems like this
branch is missing [1], which in turn seems to be already present in your
for-next branch and is going to cause a merge conflict with this
series. Should I still proceed with posting the series based on devel?

[1] f6a8249f9e55d pinctrl: exynos: Lock GPIOs as interrupts when used as
EINTs

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/3] clk: samsung: Spelling s/bwtween/between/

2014-09-27 Thread Tomasz Figa
Hi Pankaj,

On 27.09.2014 07:41, Pankaj Dubey wrote:
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com

Even though the patch is obvious, it should have at least one line of
description.

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 2/3] clk: samsung: remove unnecessary CONFIG_OF from clk.c

2014-09-27 Thread Tomasz Figa
Hi Pankaj,

On 27.09.2014 07:41, Pankaj Dubey wrote:
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com

Missing patch description.

 ---
  drivers/clk/samsung/clk.c |2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
 index deab84d..31bf391 100644
 --- a/drivers/clk/samsung/clk.c
 +++ b/drivers/clk/samsung/clk.c
 @@ -281,7 +281,6 @@ void __init samsung_clk_register_gate(struct 
 samsung_clk_provider *ctx,
   * obtain the clock speed of all external fixed clock sources from device
   * tree and register it
   */
 -#ifdef CONFIG_OF

We still have non-DT platforms which use this code, i.e. s3c24xx and
s3c64xx. Have you checked if this compiles fine on them with CONFIG_OF
disabled?

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: Specify default clocks for Exynos4 FIMC devices

2014-09-26 Thread Tomasz Figa
On 26.09.2014 13:01, Sylwester Nawrocki wrote:
 Hi Tomasz,
 
 On 25/09/14 23:58, Tomasz Figa wrote:
 On 10.09.2014 18:37, Sylwester Nawrocki wrote:
 The default mux and divider clocks are specified in device tree
 so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are
 clocked from recommended clock source and with maximum supported
 frequency. If needed these settings could be overrode in board
 specific dts files, however they are in practice optimal in most
 cases.

 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos4210.dtsi |   16 
  arch/arm/boot/dts/exynos4x12.dtsi |   16 
  2 files changed, 32 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index 807bb5b..0969d2e 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -154,18 +154,30 @@
samsung,pix-limits = 4224 8192 1920 4224;
samsung,mainscaler-ext;
samsung,cam-if;
 +  assigned-clocks = clock CLK_MOUT_FIMC0,
 +  clock CLK_SCLK_FIMC0;
 +  assigned-clock-parents = clock CLK_SCLK_MPLL;
 +  assigned-clock-rates = 0, 16000;

 I wonder whether such settings shouldn't really be set up on a per-board
 basis.

 As Daniel already pointed, we have cases when MPLL frequency differs
 across boards, but we might also have boards that differ in power budget
 and so having different desired operating frequencies for various IP blocks.

 What do you think?
 
 This patch provides sane default values for Exynos4210, MPLL is recommended
 clock source for FIMC devices. If any other clock frequency is needed for 
 selected boards the clocks setup could be simply overwritten in board dts 
 file. Otherwise similar changes would have to be done in each board dts.

I'm not concerned specifically with Exynos4210, but with placing such
kind of data in common dtsi files.

Notice that even on boards which have correct initialization done by
firmware, this will cause the settings to be overwritten, even if the
firmware sets correct, but different values, regardless of them being
clock parents or rates.

To me, even if this would mean duplicating some data, making this per
board and present only in dts files of boards that actually need this
(i.e. are known to have broken firmware) sounds more reasonable.

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/5] pinctrl: samsung: Data structure clean-up

2014-09-25 Thread Tomasz Figa
On 25.09.2014 09:47, Linus Walleij wrote:
 On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 
 This series intends to clean up data structures used by pinctrl-samsung 
 driver.
 More specifically, it separates initial compile time constants from data used
 at runtime, allowing unused variant data to be dropped and selected 
 structures
 constified to improve safety.
 
 I like the patch set, tried to apply it but patch 3/5 failed to apply to the
 devel branch for pinctrl.
 
 Can you rebase this on my devel branch, include Marek's Tested-by
 tag and resend, and I'll take it for v3.18.

Sure. Will do that today evening. Probably clashed with some other
changes queued in the meantime.

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 v3] ARM: dts: add CPU nodes for Exynos4 SoCs

2014-09-25 Thread Tomasz Figa
Hi Kukjin,

On 25.09.2014 10:26, Kukjin Kim wrote:
 On 09/25/14 17:17, Lorenzo Pieralisi wrote:
 [CC'ed Daniel to make him aware this patch goes through your tree]

 Thanks and just note the branch  which is including this change actually
 v4 is just rebased not v3 will be sent out to arm-soc last tonight or
 tomorrow.

Could you keep this patch in a separate stable branch, so I could pull
it as a dependency for Thomas Abraham's cpufreq series?

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 v3] ARM: dts: add CPU nodes for Exynos4 SoCs

2014-09-25 Thread Tomasz Figa


On 25.09.2014 10:44, Kukjin Kim wrote:
 On 09/25/14 17:28, Tomasz Figa wrote:
 Hi Kukjin,

 On 25.09.2014 10:26, Kukjin Kim wrote:
 On 09/25/14 17:17, Lorenzo Pieralisi wrote:
 [CC'ed Daniel to make him aware this patch goes through your tree]

 Thanks and just note the branch  which is including this change actually
 v4 is just rebased not v3 will be sent out to arm-soc last tonight or
 tomorrow.
 
 v3 is correct :) sorry, I confused the version...
 

 Could you keep this patch in a separate stable branch, so I could pull
 it as a dependency for Thomas Abraham's cpufreq series?

 It's possible, but would be better that DT changes are sent to upstream
 through samsung/arm-soc tree?...we suffered ugly conflicts between
 arm-soc and driver before and then we decided DT changes should be
 handled in arm-soc...Hmm...

The only other option I can see is splitting the series and sending
mach/dts patches through arm-soc and clock/cpufreq patches through clock
tree. This would break cpufreq support in both trees, until they both
hit Linus's tree. If this is not a problem, then I can proceed this way.

Please correct me if I'm missing something.

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: Specify default clocks for Exynos4 FIMC devices

2014-09-25 Thread Tomasz Figa
Hi Sylwester,

On 10.09.2014 18:37, Sylwester Nawrocki wrote:
 The default mux and divider clocks are specified in device tree
 so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are
 clocked from recommended clock source and with maximum supported
 frequency. If needed these settings could be overrode in board
 specific dts files, however they are in practice optimal in most
 cases.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 ---
  arch/arm/boot/dts/exynos4210.dtsi |   16 
  arch/arm/boot/dts/exynos4x12.dtsi |   16 
  2 files changed, 32 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
 b/arch/arm/boot/dts/exynos4210.dtsi
 index 807bb5b..0969d2e 100644
 --- a/arch/arm/boot/dts/exynos4210.dtsi
 +++ b/arch/arm/boot/dts/exynos4210.dtsi
 @@ -154,18 +154,30 @@
   samsung,pix-limits = 4224 8192 1920 4224;
   samsung,mainscaler-ext;
   samsung,cam-if;
 + assigned-clocks = clock CLK_MOUT_FIMC0,
 + clock CLK_SCLK_FIMC0;
 + assigned-clock-parents = clock CLK_SCLK_MPLL;
 + assigned-clock-rates = 0, 16000;

I wonder whether such settings shouldn't really be set up on a per-board
basis.

As Daniel already pointed, we have cases when MPLL frequency differs
across boards, but we might also have boards that differ in power budget
and so having different desired operating frequencies for various IP blocks.

What do you think?

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 v10 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

2014-09-24 Thread Tomasz Figa
On 24.09.2014 09:34, Kukjin Kim wrote:
 Thomas Abraham wrote:

 This patch series removes the use of Exynos4210 and Exynos5250 specific 
 cpufreq
 drivers and enables the use of cpufreq-cpu0 driver for these platforms. This
 series also enables cpufreq support for Exynos5420 using arm_big_little 
 cpufreq
 driver.

 This patch series is dependent on two other patches
 1. ARM: dts: add CPU nodes for Exynos4 SoCs
- https://lkml.org/lkml/2014/7/21/315
 2. clk: exynos4: remove duplicate div_core2 divider clock instantiation
- 
 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34859.html

I have applied 2) to Samsung clock tree.


 Thomas Abraham (6):
   clk: samsung: add infrastructure to register cpu clocks
   clk: samsung: add cpu clock configuration data and instantiate cpu clock
   ARM: dts: Exynos: add CPU OPP and regulator supply property
   ARM: Exynos: switch to using generic cpufreq driver for 
 Exynos4210/5250/5420
   cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
   clk: samsung: remove unused clock aliases and update clock flags

  arch/arm/boot/dts/exynos4210-origen.dts |4 +
  arch/arm/boot/dts/exynos4210-trats.dts  |4 +
  arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +
  arch/arm/boot/dts/exynos4210.dtsi   |   14 +-
  arch/arm/boot/dts/exynos5250-arndale.dts|4 +
  arch/arm/boot/dts/exynos5250-smdk5250.dts   |4 +
  arch/arm/boot/dts/exynos5250-snow.dts   |4 +
  arch/arm/boot/dts/exynos5250.dtsi   |   25 ++-
  arch/arm/boot/dts/exynos5420.dtsi   |   38 +++
  arch/arm/mach-exynos/exynos.c   |   24 ++-
  drivers/clk/samsung/Makefile|2 +-
  drivers/clk/samsung/clk-cpu.c   |  335 
 +++
  drivers/clk/samsung/clk-cpu.h   |   91 ++
  drivers/clk/samsung/clk-exynos4.c   |   63 +++--
  drivers/clk/samsung/clk-exynos5250.c|   44 +++-
  drivers/clk/samsung/clk-exynos5420.c|   72 +-
  drivers/cpufreq/Kconfig.arm |   22 --
  drivers/cpufreq/Makefile|2 -
  include/dt-bindings/clock/exynos5250.h  |1 +
  include/dt-bindings/clock/exynos5420.h  |2 +
 
 Looks good to me,
 Acked-by: Kukjin Kim kgene@samsung.com
 
 BTW, who will handle this series? I think this is already ready for v3.18.

I believe Viresh already acked this series too and since it does quite a
lot of shuffling in clock code, I'd prefer to take this through clock
tree, but apparently there is a dependency on patch 1), which already
went through another tree?

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 4/7] ARM: l2c: Add support for overriding prefetch settings

2014-09-24 Thread Tomasz Figa
On 24.09.2014 13:14, Mark Rutland wrote:
 On Wed, Sep 24, 2014 at 12:05:38PM +0100, Marek Szyprowski wrote:
 From: Tomasz Figa t.f...@samsung.com

 Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
 settings configured in registers leading to crashes if L2C is enabled
 without overriding them. This patch introduces bindings to enable
 prefetch settings to be specified from DT and necessary support in the
 driver.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  Documentation/devicetree/bindings/arm/l2cc.txt | 10 +++
  arch/arm/mm/cache-l2x0.c   | 39 
 ++
  2 files changed, 49 insertions(+)

 diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
 b/Documentation/devicetree/bindings/arm/l2cc.txt
 index af527ee111c2..3443d2d76788 100644
 --- a/Documentation/devicetree/bindings/arm/l2cc.txt
 +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
 @@ -47,6 +47,16 @@ Optional properties:
  - cache-id-part: cache id part number to be used if it is not present
on hardware
  - wt-override: If present then L2 is forced to Write through mode
 +- arm,double-linefill : Override double linefill enable setting. Enable if
 +  non-zero, disable if zero.
 +- arm,double-linefill-incr : Override double linefill on INCR read. Enable
 +  if non-zero, disable if zero.
 +- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
 +  if non-zero, disable if zero.
 +- arm,prefetch-drop : Override prefetch drop enable setting. Enable if 
 non-zero,
 +  disable if zero.
 
 I'm not too keen on tristate properties. Is this level of flexibility
 really required?
 
 What exact overrides do you need for boards you know of? Why do these
 cause crashes if not overridden?

Well, this is all thanks to broken firmware, which doesn't initialize
those values properly on certain systems and they must be overridden. On
the other side, there are systems with firmware that does it correctly
and for those the boot defaults should be preferred. I don't see any
other reasonable option of handling this.

As for why they cause crashes, I'm not an expert if it is about L2C
internals, so I can't really tell, but apparently the cache can work
correctly only on certain settings.

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


Re: [PATCH/RFC 0/2] serial: samsung: add support for early console

2014-09-23 Thread Tomasz Figa
On 23.09.2014 14:53, Alim Akhtar wrote:
 Hi Marek,
 
 On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
 m.szyprow...@samsung.com wrote:
 Hello,

 This patchset adds support for early console defined in device tree. As
 an example, DTS files for all Exynos4 based machines are updated with
 the correct value for common chosen/sdtout property.

 To get it fully functional additional improvements (support for
 early_ioremap) are needed in early console code.

 Is these really tested?
 So that mean we need to wait till __ioremap__ support available for ARM.

This was originally tested by creating a fixed mapping for all UART
ports on respective platforms in .map_io() callback of machine
descriptor. This might be the way to support this on 32-bit ARM
platforms until early ioremap is available.

However if no mapping is available, the earlycon will simply not
register and won't break anything, so it should be safe to keep.

 How to take this forward then? Here is a platform (exynos7) which
 needs earlycon support for debugging some of the early core things and
 ARM64 has ioremap support as well. There is no reason why we should
 hold earlycon support for exyons7.
 I see two solution here:
 1 How about re-spin patch-1 which will just add ealrycon support for
 __exynos4210__ serial type only? And rest of the types can be added as
 incremental patches, as and when ioremap for ARM available.
 Atleast this approch will solve exynos7 problem of not having earlycon 
 support.
 And This patch can be tested on exynos7 (I can do that).

I don't really think there is a need to remove support for other
variants. As I mentioned, they can be supported without early_ioremap()
by static IO mapping.

 2 Take  my patch which is working and tested for exynos7 and can be
 easily extended and generalized when ioremap for ARM is available.
 
 My preference would be the the first one.
 Let me know your thoughts please.
 In case you are ok with 1st approach, can you please re-spin patch1
 with needed changes?

I'd say this patch could be merged as is. For 32-bit platforms
additional patches might be posted separately to add early static
mapping or just wait until early ioremap becomes availabl.e

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 2/5] pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

2014-09-23 Thread Tomasz Figa
On 23.09.2014 10:16, Abhilash Kesavan wrote:
[snip]
 @@ -383,9 +377,11 @@ static int exynos_wkup_irq_set_wake(struct irq_data 
 *irqd, unsigned int on)
  /*
   * irq_chip for wakeup interrupts
   */
 -static struct exynos_irq_chip exynos_wkup_irq_chip = {
 +static struct exynos_irq_chip *exynos_wkup_irq_chip;
 +
[snip]
 @@ -459,7 +480,7 @@ static void exynos_irq_demux_eint16_31(unsigned int irq, 
 struct irq_desc *desc)
  static int exynos_wkup_irq_map(struct irq_domain *h, unsigned int virq,
   irq_hw_number_t hw)
  {
 - irq_set_chip_and_handler(virq, exynos_wkup_irq_chip.chip,
 + irq_set_chip_and_handler(virq, exynos_wkup_irq_chip-chip,
   handle_level_irq);
   irq_set_chip_data(virq, h-host_data);
   set_irq_flags(virq, IRQF_VALID);
 @@ -491,7 +512,12 @@ static int exynos_eint_wkup_init(struct 
 samsung_pinctrl_drv_data *d)
   int idx, irq;
  
   for_each_child_of_node(dev-of_node, np) {
 - if (of_match_node(exynos_wkup_irq_ids, np)) {
 + const struct of_device_id *match;
 +
 + match = of_match_node(exynos_wkup_irq_ids, np);
 + if (match) {
 + exynos_wkup_irq_chip = kmemdup(match-data,
 + sizeof(struct exynos_irq_chip), GFP_KERNEL);

That's not exactly what I had in my mind.

You just changed the code to write to another global variable. This is
not the best practice and might cause hard to track issues in future,
when extending the driver.

From what I can see, the best solution would be to add .irq_chip field
to samsung_pin_bank struct. Then exynos_wkup_irq_map() could access it
through h-host_data pointer and exynos_irq_demux_eint16_31() could also
retrieve the irq chip through bank struct without the need too add chip
field to exynos_muxed_weint_data struct.

As a side effect, it would be possible to consolidate
exynos_wkup_irqd_ops with exynos_gpio_irqd_ops, which currently only
differ in irq chip passed as argument to irq_set_chip_and_handler() in
.map() callback.

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 2/5] pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct

2014-09-23 Thread Tomasz Figa
There is no code using it and in fact there are pin controller variants
that do not even have this field initialized in their init data. This
patch removes it completely.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 22 --
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  4 
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  1 -
 drivers/pinctrl/samsung/pinctrl-samsung.h |  3 ---
 4 files changed, 30 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d7154ed0b0eb..7e6463f970ff 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -682,7 +682,6 @@ struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = s5pv210-gpio-ctrl0,
},
 };
 
@@ -729,7 +728,6 @@ struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos3250-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos3250_pin_banks1,
@@ -738,7 +736,6 @@ struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos3250-gpio-ctrl1,
},
 };
 
@@ -803,7 +800,6 @@ struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4210-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos4210_pin_banks1,
@@ -812,12 +808,10 @@ struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4210-gpio-ctrl1,
}, {
/* pin-controller instance 2 data */
.pin_banks  = exynos4210_pin_banks2,
.nr_banks   = ARRAY_SIZE(exynos4210_pin_banks2),
-   .label  = exynos4210-gpio-ctrl2,
},
 };
 
@@ -891,7 +885,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos4x12_pin_banks1,
@@ -900,7 +893,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl1,
}, {
/* pin-controller instance 2 data */
.pin_banks  = exynos4x12_pin_banks2,
@@ -908,7 +900,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl2,
}, {
/* pin-controller instance 3 data */
.pin_banks  = exynos4x12_pin_banks3,
@@ -916,7 +907,6 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos4x12-gpio-ctrl3,
},
 };
 
@@ -989,7 +979,6 @@ struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
-   .label  = exynos5250-gpio-ctrl0,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos5250_pin_banks1,
@@ -997,7 +986,6 @@ struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
.eint_gpio_init = exynos_eint_gpio_init,
.suspend= exynos_pinctrl_suspend,
.resume

[PATCH 3/5] pinctrl: samsung: Constify samsung_pin_bank_type struct

2014-09-23 Thread Tomasz Figa
This structure is not intended to be modified at runtime and functions
as constant data shared between multiple pin banks. This patch makes all
instances of it constant across the driver.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  |  8 
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  6 +++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 14 +++---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 20 +---
 drivers/pinctrl/samsung/pinctrl-samsung.h |  2 +-
 5 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 7e6463f970ff..0202e0016233 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -46,12 +46,12 @@ static inline struct exynos_irq_chip 
*to_exynos_irq_chip(struct irq_chip *chip)
return container_of(chip, struct exynos_irq_chip, chip);
 }
 
-static struct samsung_pin_bank_type bank_type_off = {
+static const struct samsung_pin_bank_type bank_type_off = {
.fld_width = { 4, 1, 2, 2, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
 };
 
-static struct samsung_pin_bank_type bank_type_alive = {
+static const struct samsung_pin_bank_type bank_type_alive = {
.fld_width = { 4, 1, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
 };
@@ -171,7 +171,7 @@ static int exynos_irq_request_resources(struct irq_data 
*irqd)
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-   struct samsung_pin_bank_type *bank_type = bank-type;
+   const struct samsung_pin_bank_type *bank_type = bank-type;
struct samsung_pinctrl_drv_data *d = bank-drvdata;
unsigned int shift = EXYNOS_EINT_CON_LEN * irqd-hwirq;
unsigned long reg_con = our_chip-eint_con + bank-eint_offset;
@@ -210,7 +210,7 @@ static void exynos_irq_release_resources(struct irq_data 
*irqd)
struct irq_chip *chip = irq_data_get_irq_chip(irqd);
struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
-   struct samsung_pin_bank_type *bank_type = bank-type;
+   const struct samsung_pin_bank_type *bank_type = bank-type;
struct samsung_pinctrl_drv_data *d = bank-drvdata;
unsigned int shift = EXYNOS_EINT_CON_LEN * irqd-hwirq;
unsigned long reg_con = our_chip-eint_con + bank-eint_offset;
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index e38925906bd3..9db6cf5c8823 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -44,12 +44,12 @@
 #define EINT_EDGE_BOTH 6
 #define EINT_MASK  0xf
 
-static struct samsung_pin_bank_type bank_type_1bit = {
+static const struct samsung_pin_bank_type bank_type_1bit = {
.fld_width = { 1, 1, },
.reg_offset = { 0x00, 0x04, },
 };
 
-static struct samsung_pin_bank_type bank_type_2bit = {
+static const struct samsung_pin_bank_type bank_type_2bit = {
.fld_width = { 2, 1, 2, },
.reg_offset = { 0x00, 0x04, 0x08, },
 };
@@ -143,7 +143,7 @@ static void s3c24xx_eint_set_handler(unsigned int irq, 
unsigned int type)
 static void s3c24xx_eint_set_function(struct samsung_pinctrl_drv_data *d,
struct samsung_pin_bank *bank, int pin)
 {
-   struct samsung_pin_bank_type *bank_type = bank-type;
+   const struct samsung_pin_bank_type *bank_type = bank-type;
unsigned long flags;
void __iomem *reg;
u8 shift;
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index fcf8c36e727e..2a14db2826d8 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -68,32 +68,32 @@
 #define EINT_CON_MASK  0xF
 #define EINT_CON_LEN   4
 
-static struct samsung_pin_bank_type bank_type_4bit_off = {
+static const struct samsung_pin_bank_type bank_type_4bit_off = {
.fld_width = { 4, 1, 2, 0, 2, 2, },
.reg_offset = { 0x00, 0x04, 0x08, 0, 0x0c, 0x10, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit_alive = {
+static const struct samsung_pin_bank_type bank_type_4bit_alive = {
.fld_width = { 4, 1, 2, },
.reg_offset = { 0x00, 0x04, 0x08, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit2_off = {
+static const struct samsung_pin_bank_type bank_type_4bit2_off = {
.fld_width = { 4, 1, 2, 0, 2, 2, },
.reg_offset = { 0x00, 0x08, 0x0c, 0, 0x10, 0x14, },
 };
 
-static struct samsung_pin_bank_type bank_type_4bit2_alive = {
+static const struct samsung_pin_bank_type bank_type_4bit2_alive

[PATCH 0/5] pinctrl: samsung: Data structure clean-up

2014-09-23 Thread Tomasz Figa
This series intends to clean up data structures used by pinctrl-samsung driver.
More specifically, it separates initial compile time constants from data used
at runtime, allowing unused variant data to be dropped and selected structures
constified to improve safety.

As a side effect, size of vmlinux built from multi_v7_defconfig was reduced
from:

 text databssdec  hexfilename
 10296708 1227100 313544 11837352 b49fa8 vmlinux

to:

 text databssdec  hexfilename
 10296740 1176860 313544 11787144 b3db88 vmlinux

and quite a bit of data were moved from normal data sections to .init.data:

pre:

Idx Name  Size  VMA   LMA   File off  Algn
  3 .rodata   0026c080  c0881000  c0881000  00681000  2**6
 23 .init.data0003ff7c  c0bdb830  c0bdb830  009e3830  2**3
 24 .data..percpu 2100  c0c1c000  c0c1c000  00a24000  2**6
 25 .data 000e98e0  c0c2  c0c2  00a28000  2**6

post:

Idx Name  Size  VMA   LMA   File off  Algn
  3 .rodata   0026bf20  c0881000  c0881000  00681000  2**6
 23 .init.data00041bbc  c0bdb830  c0bdb830  009e3830  2**3
 24 .data..percpu 2100  c0c1e000  c0c1e000  00a26000  2**6
 25 .data 000db860  c0c22000  c0c22000  00a2a000  2**6

This series should not introduce any functional changes.

Tested on S3C6410-based Mini6410 board, booting with device tree.

Marek, Bart, could you do some testing on Exynos-based boards,
just to make sure?

Tomasz Figa (5):
  pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()
  pinctrl: samsung: Drop unused label field in samsung_pin_ctrl struct
  pinctrl: samsung: Constify samsung_pin_bank_type struct
  pinctrl: samsung: Constify samsung_pin_ctrl struct
  pinctrl: samsung: Separate per-bank init and runtime data

 drivers/pinctrl/samsung/pinctrl-exynos.c  | 113 +++
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  30 +++
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  31 
 drivers/pinctrl/samsung/pinctrl-samsung.c | 126 --
 drivers/pinctrl/samsung/pinctrl-samsung.h |  78 --
 5 files changed, 193 insertions(+), 185 deletions(-)

-- 
2.1.0

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


[PATCH 1/5] pinctrl: samsung: Make samsung_pinctrl_get_soc_data use ERR_PTR()

2014-09-23 Thread Tomasz Figa
Currently the function returns a valid pointer on success and NULL on
error, so exact error code is lost. This patch changes return convention
of the function to use ERR_PTR() on error instead.

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

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c 
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 4a47691c32b1..0504f0b75de8 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -988,7 +988,7 @@ static struct samsung_pin_ctrl 
*samsung_pinctrl_get_soc_data(
id = of_alias_get_id(node, pinctrl);
if (id  0) {
dev_err(pdev-dev, failed to get alias id\n);
-   return NULL;
+   return ERR_PTR(-ENOENT);
}
match = of_match_node(samsung_pinctrl_dt_match, node);
ctrl = (struct samsung_pin_ctrl *)match-data + id;
@@ -1040,9 +1040,9 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
}
 
ctrl = samsung_pinctrl_get_soc_data(drvdata, pdev);
-   if (!ctrl) {
+   if (IS_ERR(ctrl)) {
dev_err(pdev-dev, driver data not available\n);
-   return -EINVAL;
+   return PTR_ERR(ctrl);
}
drvdata-ctrl = ctrl;
drvdata-dev = dev;
-- 
2.1.0

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


[PATCH 4/5] pinctrl: samsung: Constify samsung_pin_ctrl struct

2014-09-23 Thread Tomasz Figa
In order to separate initialization constants from runtime data, this
patch modifies the driver to store only constant data in
samsung_pin_ctrl struct and copy data required at runtime to
samsung_pinctrl_drv_data struct. This makes it possible to mark all
existing instances of samsung_pin_ctrl struct as const and __initconst.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 39 +++---
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 12 ++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 14 ++---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 86 +++
 drivers/pinctrl/samsung/pinctrl-samsung.h | 40 +++---
 5 files changed, 96 insertions(+), 95 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0202e0016233..552f7c75243d 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -277,8 +277,7 @@ static const struct irq_domain_ops exynos_gpio_irqd_ops = {
 static irqreturn_t exynos_eint_gpio_irq(int irq, void *data)
 {
struct samsung_pinctrl_drv_data *d = data;
-   struct samsung_pin_ctrl *ctrl = d-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = d-pin_banks;
unsigned int svc, group, pin, virq;
 
svc = readl(d-virt_base + EXYNOS_SVC_OFFSET);
@@ -325,8 +324,8 @@ static int exynos_eint_gpio_init(struct 
samsung_pinctrl_drv_data *d)
return -ENXIO;
}
 
-   bank = d-ctrl-pin_banks;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   bank = d-pin_banks;
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_GPIO)
continue;
bank-irq_domain = irq_domain_add_linear(bank-of_node,
@@ -498,8 +497,8 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
if (!wkup_np)
return -ENODEV;
 
-   bank = d-ctrl-pin_banks;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   bank = d-pin_banks;
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_WKUP)
continue;
 
@@ -556,9 +555,9 @@ static int exynos_eint_wkup_init(struct 
samsung_pinctrl_drv_data *d)
irq_set_chained_handler(irq, exynos_irq_demux_eint16_31);
irq_set_handler_data(irq, muxed_data);
 
-   bank = d-ctrl-pin_banks;
+   bank = d-pin_banks;
idx = 0;
-   for (i = 0; i  d-ctrl-nr_banks; ++i, ++bank) {
+   for (i = 0; i  d-nr_banks; ++i, ++bank) {
if (bank-eint_type != EINT_TYPE_WKUP_MUX)
continue;
 
@@ -590,11 +589,10 @@ static void exynos_pinctrl_suspend_bank(
 
 static void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
-   struct samsung_pin_ctrl *ctrl = drvdata-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = drvdata-pin_banks;
int i;
 
-   for (i = 0; i  ctrl-nr_banks; ++i, ++bank)
+   for (i = 0; i  drvdata-nr_banks; ++i, ++bank)
if (bank-eint_type == EINT_TYPE_GPIO)
exynos_pinctrl_suspend_bank(drvdata, bank);
 }
@@ -626,11 +624,10 @@ static void exynos_pinctrl_resume_bank(
 
 static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
-   struct samsung_pin_ctrl *ctrl = drvdata-ctrl;
-   struct samsung_pin_bank *bank = ctrl-pin_banks;
+   struct samsung_pin_bank *bank = drvdata-pin_banks;
int i;
 
-   for (i = 0; i  ctrl-nr_banks; ++i, ++bank)
+   for (i = 0; i  drvdata-nr_banks; ++i, ++bank)
if (bank-eint_type == EINT_TYPE_GPIO)
exynos_pinctrl_resume_bank(drvdata, bank);
 }
@@ -673,7 +670,7 @@ static struct samsung_pin_bank s5pv210_pin_bank[] = {
EXYNOS_PIN_BANK_EINTW(8, 0xc60, gph3, 0x0c),
 };
 
-struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
+const struct samsung_pin_ctrl s5pv210_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 data */
.pin_banks  = s5pv210_pin_bank,
@@ -720,7 +717,7 @@ static struct samsung_pin_bank exynos3250_pin_banks1[] = {
  * Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC includes
  * two gpio/pin-mux/pinconfig controllers.
  */
-struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
+const struct samsung_pin_ctrl exynos3250_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 data */
.pin_banks  = exynos3250_pin_banks0,
@@ -792,7 +789,7 @@ static struct samsung_pin_bank exynos4210_pin_banks2[] = {
  * Samsung pinctrl driver data for Exynos4210 SoC. Exynos4210 SoC includes
  * three gpio/pin-mux/pinconfig controllers.
  */
-struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
+const struct samsung_pin_ctrl

[PATCH 5/5] pinctrl: samsung: Separate per-bank init and runtime data

2014-09-23 Thread Tomasz Figa
Currently the driver mixes constant init data with runtime data, which
is far from being elegant and can invite potential hard to track issues.
This patch intends to solve this by introducing a new
samsung_pin_bank_data structure to hold only constant data known at
compile time, which can be copied to main samsung_pin_bank struct used
at runtime.

In addition, thanks to this change, all per-bank initdata can be marked
with const and __initconst keywords and dropped after init completes.

Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 44 +++
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c |  8 +++---
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c |  2 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c | 18 +++--
 drivers/pinctrl/samsung/pinctrl-samsung.h | 33 ---
 5 files changed, 72 insertions(+), 33 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 552f7c75243d..b4490cb2a439 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -633,7 +633,7 @@ static void exynos_pinctrl_resume(struct 
samsung_pinctrl_drv_data *drvdata)
 }
 
 /* pin banks of s5pv210 pin-controller */
-static struct samsung_pin_bank s5pv210_pin_bank[] = {
+static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(4, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -683,7 +683,7 @@ const struct samsung_pin_ctrl s5pv210_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos3250 pin-controller 0 */
-static struct samsung_pin_bank exynos3250_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb,  0x08),
@@ -694,7 +694,7 @@ static struct samsung_pin_bank exynos3250_pin_banks0[] = {
 };
 
 /* pin banks of exynos3250 pin-controller 1 */
-static struct samsung_pin_bank exynos3250_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTN(8, 0x120, gpe0),
EXYNOS_PIN_BANK_EINTN(8, 0x140, gpe1),
EXYNOS_PIN_BANK_EINTN(3, 0x180, gpe2),
@@ -737,7 +737,7 @@ const struct samsung_pin_ctrl exynos3250_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos4210 pin-controller 0 */
-static struct samsung_pin_bank exynos4210_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -757,7 +757,7 @@ static struct samsung_pin_bank exynos4210_pin_banks0[] = {
 };
 
 /* pin banks of exynos4210 pin-controller 1 */
-static struct samsung_pin_bank exynos4210_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpj0, 0x00),
EXYNOS_PIN_BANK_EINTG(5, 0x020, gpj1, 0x04),
EXYNOS_PIN_BANK_EINTG(7, 0x040, gpk0, 0x08),
@@ -781,7 +781,7 @@ static struct samsung_pin_bank exynos4210_pin_banks1[] = {
 };
 
 /* pin banks of exynos4210 pin-controller 2 */
-static struct samsung_pin_bank exynos4210_pin_banks2[] = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks2[] __initconst 
= {
EXYNOS_PIN_BANK_EINTN(7, 0x000, gpz),
 };
 
@@ -813,7 +813,7 @@ const struct samsung_pin_ctrl exynos4210_pin_ctrl[] 
__initconst = {
 };
 
 /* pin banks of exynos4x12 pin-controller 0 */
-static struct samsung_pin_bank exynos4x12_pin_banks0[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
@@ -830,7 +830,7 @@ static struct samsung_pin_bank exynos4x12_pin_banks0[] = {
 };
 
 /* pin banks of exynos4x12 pin-controller 1 */
-static struct samsung_pin_bank exynos4x12_pin_banks1[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(7, 0x040, gpk0, 0x08),
EXYNOS_PIN_BANK_EINTG(7, 0x060, gpk1, 0x0c),
EXYNOS_PIN_BANK_EINTG(7, 0x080, gpk2, 0x10),
@@ -857,12 +857,12 @@ static struct samsung_pin_bank exynos4x12_pin_banks1[] = {
 };
 
 /* pin banks of exynos4x12 pin-controller 2 */
-static struct samsung_pin_bank exynos4x12_pin_banks2[] = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks2[] __initconst 
= {
EXYNOS_PIN_BANK_EINTG(7, 0x000, gpz, 0x00),
 };
 
 /* pin banks of exynos4x12 pin-controller 3 */
-static struct samsung_pin_bank exynos4x12_pin_banks3[] = {
+static const

Re: [PATCH 2/4] pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts

2014-09-22 Thread Tomasz Figa
On 22.09.2014 08:17, Abhilash Kesavan wrote:
 Hi Tomasz,
 
 On Sat, Sep 13, 2014 at 4:57 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Abhilash,

 Please see my comments inline.

 On 13.09.2014 10:50, Abhilash Kesavan wrote:
 Exynos7 uses different offsets for wakeup interrupt configuration registers.
 So a new irq_chip instance for Exynos7 wakeup interrupts is added. The 
 irq_chip
 selection is now based on the wakeup interrupt controller compatible string.

 [snip]

 @@ -328,9 +322,11 @@ static int exynos_wkup_irq_set_wake(struct irq_data 
 *irqd, unsigned int on)
  /*
   * irq_chip for wakeup interrupts
   */
 -static struct exynos_irq_chip exynos_wkup_irq_chip = {
 +static struct exynos_irq_chip exynos_wkup_irq_chip;
 +

 Why do you still need this, if you have both variants below?
 
 After adding __initdata to the two variants, I will require to have a
 copy of one of them.
 

 +static struct exynos_irq_chip exynos4210_wkup_irq_chip = {
   .chip = {
 - .name = exynos_wkup_irq_chip,
 + .name = exynos4210_wkup_irq_chip,
   .irq_unmask = exynos_irq_unmask,
   .irq_mask = exynos_irq_mask,
   .irq_ack = exynos_irq_ack,
 @@ -342,6 +338,29 @@ static struct exynos_irq_chip exynos_wkup_irq_chip = {
   .eint_pend = EXYNOS_WKUP_EPEND_OFFSET,
  };

 +static struct exynos_irq_chip exynos7_wkup_irq_chip = {
 + .chip = {
 + .name = exynos7_wkup_irq_chip,
 + .irq_unmask = exynos_irq_unmask,
 + .irq_mask = exynos_irq_mask,
 + .irq_ack = exynos_irq_ack,
 + .irq_set_type = exynos_irq_set_type,
 + .irq_set_wake = exynos_wkup_irq_set_wake,
 + },
 + .eint_con = EXYNOS7_WKUP_ECON_OFFSET,
 + .eint_mask = EXYNOS7_WKUP_EMASK_OFFSET,
 + .eint_pend = EXYNOS7_WKUP_EPEND_OFFSET,
 +};
 +
 +/* list of external wakeup controllers supported */
 +static const struct of_device_id exynos_wkup_irq_ids[] = {
 + { .compatible = samsung,exynos4210-wakeup-eint,
 + .data = exynos4210_wkup_irq_chip },
 + { .compatible = samsung,exynos7-wakeup-eint,
 + .data = exynos7_wkup_irq_chip },
 + { }
 +};
 +
  /* interrupt handler for wakeup interrupts 0..15 */
  static void exynos_irq_eint0_15(unsigned int irq, struct irq_desc *desc)
  {
 @@ -434,7 +453,12 @@ static int exynos_eint_wkup_init(struct 
 samsung_pinctrl_drv_data *d)
   int idx, irq;

   for_each_child_of_node(dev-of_node, np) {
 - if (of_match_node(exynos_wkup_irq_ids, np)) {
 + const struct of_device_id *match;
 +
 + match = of_match_node(exynos_wkup_irq_ids, np);
 + if (match) {
 + memcpy(exynos_wkup_irq_chip, match-data,
 + sizeof(struct exynos_irq_chip));

 Hmm, this doesn't look correct to me. You are modifying a static struct
 here. Why couldn't you simply use the exynos irq chip pointed by
 match-data in further registration code?
 
 That will not be available later once I use __initdata.
 

Then either __initdata shouldn't be necessary or kmemdup() should be
used to allocate a copy.


   wkup_np = np;
   break;
   }
 diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h 
 b/drivers/pinctrl/samsung/pinctrl-exynos.h
 index e060722..0db1e52 100644
 --- a/drivers/pinctrl/samsung/pinctrl-exynos.h
 +++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
 @@ -25,6 +25,9 @@
  #define EXYNOS_WKUP_ECON_OFFSET  0xE00
  #define EXYNOS_WKUP_EMASK_OFFSET 0xF00
  #define EXYNOS_WKUP_EPEND_OFFSET 0xF40
 +#define EXYNOS7_WKUP_ECON_OFFSET 0x700
 +#define EXYNOS7_WKUP_EMASK_OFFSET0x900
 +#define EXYNOS7_WKUP_EPEND_OFFSET0xA00

 Interestingly enough, the offsets look just like the normal GPIO
 interrupt controller of previous Exynos SoCs. Are you sure those are
 correct? Also if somehow the controller now resembles the normal one,
 doesn't it have the SVC register making it possible to reuse the non
 wake-up code instead?
 
 The wakeup interrupt register offsets are the same as the GPIO
 interrupt offsets in earlier Exynos SoCs. There is no SVC register for
 the wakeup interrupt block.

OK, your code is fine then.

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 1/3] clk: samsung: exynos3250: Register DMC clk provider

2014-09-22 Thread Tomasz Figa
On 02.09.2014 15:21, Krzysztof Kozlowski wrote:
 Add clock provider for clocks in DMC domain including EPLL and BPLL. The
 DMC clocks are necessary for Exynos3 devfreq driver.
 
 The DMC clock domain uses different address space (0x105C) than
 standard clock domain (0x1003 - 0x1005). The difference is huge
 enough to add new DT node for the clock provider, rather than extending
 existing address space.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 
 ---
 
 Changes since v1:
 =
 1. Fix overwritteing main clock provider reg_base with DMC clock domain
reg_basr. This leads to OOPS in suspend.

Applied the whole series for next.

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] clk: samsung: exynos3250: fix width field of mout_mmc0/1

2014-09-22 Thread Tomasz Figa
On 09.09.2014 14:14, Krzysztof Kozlowski wrote:
 On 05.09.2014 13:54, Pankaj Dubey wrote:
 As per Exynos3250 user manual mmc0/1 mux selection has 4 bit wide.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
   drivers/clk/samsung/clk-exynos3250.c |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Applied for next.

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


  1   2   3   4   5   6   7   8   9   10   >