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