[PATCH] MAINTAINERS: pinctrl: Move Thomas Abraham to CREDITS
Thomas Abraham's Linaro email address bounces for several months. Also there were no replies for several emails sent on LKML to his Samsung address. Move his name to CREDITS. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org Link: http://lkml.org/lkml/2015/6/15/15 --- CREDITS | 4 MAINTAINERS | 1 - 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/CREDITS b/CREDITS index 4fcf9cd8544c..bcb8efaa9459 100644 --- a/CREDITS +++ b/CREDITS @@ -20,6 +20,10 @@ D: One of assisting postmasters for vger.kernel.org's lists S: (ask for current address) S: Finland +N: Thomas Abraham +E: thomas...@samsung.com +D: Samsung pin controller driver + N: Dragos Acostachioaie E: dra...@iname.com W: http://www.arbornet.org/~dragos diff --git a/MAINTAINERS b/MAINTAINERS index 4bed1920eb2a..f0a63f06ca33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8008,7 +8008,6 @@ F:drivers/pinctrl/sh-pfc/ PIN CONTROLLER - SAMSUNG M: Tomasz Figa tomasz.f...@gmail.com -M: Thomas Abraham thomas.abra...@linaro.org L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] pinctrl: kill off set_irq_flags usage
On Mon, Jul 27, 2015 at 10:55 PM, Rob Herring r...@kernel.org wrote: 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 modify 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 --- Thomas asked that this be merged thru subsystem trees instead of arm-soc, so please apply this to your tree. Patch applied, and thanks for driving this. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: pinctrl: Move Thomas Abraham to CREDITS
On Tue, Jul 28, 2015 at 10:21 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Thomas Abraham's Linaro email address bounces for several months. Also there were no replies for several emails sent on LKML to his Samsung address. Move his name to CREDITS. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org Link: http://lkml.org/lkml/2015/6/15/15 Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] irqchip: kill off set_irq_flags usage
Hi Rob, Thomas, Jason,
On 27/07/2015 22:55, Rob Herring wrote:
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 modify 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
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Alexander Shiyan shc_w...@mail.ru
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
for irq-armada-370-xp
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Thanks,
Gregory
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.
Rob
drivers/irqchip/exynos-combiner.c | 2 +-
drivers/irqchip/irq-armada-370-xp.c | 3 +--
drivers/irqchip/irq-bcm2835.c | 2 +-
drivers/irqchip/irq-clps711x.c| 6 +++---
drivers/irqchip/irq-gic-v3.c | 5 ++---
drivers/irqchip/irq-gic.c | 4 ++--
drivers/irqchip/irq-hip04.c | 4 ++--
drivers/irqchip/irq-keystone.c| 2 +-
drivers/irqchip/irq-mmp.c | 3 ---
drivers/irqchip/irq-mxs.c | 1 -
drivers/irqchip/irq-renesas-intc-irqpin.c | 1 -
drivers/irqchip/irq-renesas-irqc.c| 1 -
drivers/irqchip/irq-s3c24xx.c | 14 ++
drivers/irqchip/irq-sun4i.c | 2 +-
drivers/irqchip/irq-versatile-fpga.c | 2 +-
drivers/irqchip/irq-vic.c | 2 +-
drivers/irqchip/irq-vt8500.c | 1 -
drivers/irqchip/spear-shirq.c | 1 -
18 files changed, 18 insertions(+), 38 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5c82e3b..a62cfd3 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -165,7 +165,7 @@ static int combiner_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_set_chip_and_handler(irq, combiner_chip, handle_level_irq);
irq_set_chip_data(irq, combiner_data[hw 3]);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+ irq_set_probe(irq);
return 0;
}
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 0d3b0fe..017f881 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain
*domain, unsigned int virq,
{
irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
handle_simple_irq);
- set_irq_flags(virq, IRQF_VALID);
return 0;
}
@@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain
*h,
irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
handle_level_irq);
}
- set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+ irq_set_probe(virq);
return 0;
}
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index e68c3b6..9c4ba16 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -165,7 +165,7 @@ static int __init armctrl_of_init(struct device_node
*node,
BUG_ON(irq = 0);
irq_set_chip_and_handler(irq, armctrl_chip,
handle_level_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+ irq_set_probe(irq);
}
}
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33127f1..2e74e81 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct
irq_domain *h, unsigned int virq,
irq_hw_number_t hw)
{
irq_flow_handler_t handler = handle_level_irq;
- unsigned int flags = IRQF_VALID | IRQF_PROBE;
+ unsigned int flags = 0;
if (!clps711x_irqs[hw].flags)
return 0;
if (clps711x_irqs[hw].flags
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Hi, On Tue, Jul 28, 2015 at 9:20 AM, Alexey Klimov klimov.li...@gmail.com wrote: Hi Doug, On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson diand...@chromium.org wrote: Alexey, On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov klimov.li...@gmail.com wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? I hate to burst your bubble here, but... ...I think it would be a bad idea to use the cp15 counter on exynos 5422. According to Samsung, there are issues where using cp15 could sometimes return the wrong value, especially if you happen to read it while on an A7 instead of an A15. It will tend to work pretty well, but Samsung claimed that it might not work right on some CPUs or at some temperatures. I think this is right time when I can say If only I had known about it before!. Yeah, we spent a whole lot of time on this too before giving up after we found out it was not possible to use. That's quite interesting especially about temperature issues. Maybe it's worth to insert comments in driver/docs about this. Maybe not a bad idea. Depends if you think someone else will try to do this... ...and if they do, will they check mailing list traffic. Generally I'd say that if the arch timer works for you: use the arch timer. If the arch timer doesn't work for you, use the MCT. -Doug I possess no knowledge if there're any different hw revisions of odroid-xu3 on the field but looks like arch timer works fine for me on odroid-xu3 Exynos5422 SoC with upstream kernel. Well, it looked like it worked for us too. In fact, I never saw a failure. All I know is that Samsung said: don't do this, it's not a good idea. The performance gain wasn't enough to go against that... That's when I started trying to optimize the MCT a little bit. ;) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] ARM: dts: Add SPI CS on exynos5250-snow
Michal Suchanek wrote:
Although there is only one choice of chipselect it is necessary to
specify it. The driver cannot claim the gpio otherwise.
Signed-off-by: Michal Suchanek hramr...@gmail.com
Acked-by: Javier Martinez Canillas jav...@osg.samsung.com
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com
From here ---88---
--
- don't move unrelated line
- use symbolic GPIO_ACTIVE_HIGH
to here ---88---
should be added under the following '---'.
Please add some additional comments like above 'changes since previous version'
under the following '---' not '--', because all comments will be logged before
the '---' and I don't want to keep the changes basically.
Anyway, applied with removing above comments.
Thanks,
Kukjin
---
arch/arm/boot/dts/exynos5250-snow.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index b7f4122..2d6a976 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -688,6 +688,7 @@
status = okay;
samsung,spi-src-clk = 0;
num-cs = 1;
+ cs-gpios = gpa2 5 GPIO_ACTIVE_HIGH;
};
usbdrd_dwc3 {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv6] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
Chanho Park wrote: Hi, On Tue, Jul 14, 2015 at 5:23 PM, Kukjin Kim kg...@kernel.org wrote: Chanho Park wrote: Hi Kukjin, On Tue, Jul 14, 2015 at 2:04 PM, Kukjin Kim kg...@kernel.org wrote: Krzysztof Kozlowski wrote: On 14.07.2015 09:24, Chanho Park wrote: The odroid-xu3 board which is based on exynos5422 not exynos5800 is booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are cortex-a15 cores. To correct this mis-odering, I added exynos5422-cpus.dtsi and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and cpu4-7 are cortex-a15. Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Chanho Park parkc...@gmail.com --- [...] Secondary cpu booting problem[1] is not resolved yet. Need more investigations to work booting 8 cores correctly. [1]: http://www.spinics.net/lists/linux-samsung-soc/msg45525.html arch/arm/boot/dts/exynos5422-cpus.dtsi | 81 ++ arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 + 2 files changed, 82 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi Thanks, applied to my tree. I'll send it to Kukjin for v4.3 unless he picks it also. Well, let me see. I'm thinking we need to sort out the cpu ordering and dtsi inclusions for exynos5420, 5422 and 5800 related to DT files. See, 1) exynos5420 DT (cpu0~3: a15, cpu 4~7: a7) 2) exynos5800 DT is including exynos5420 DT 3) exynos5422 and exynos5800 based boards are including exynos5800 DT. Then making exynos5422-cpus DT for exynos5422 based boards? (cpu0~3: a7, cpu4~7: a15) I think, it could cause confusion when new board based on them are added because it's not clear and the boot cpu could be selected by bootloader part. The iROM will check the GPIO pin to select which core is run as cpu0. I think no one will change the GPIO pin if a new board which is based on exynos5422 :) Yes, I know the boot sequence and it means it depends on board configuration not SoC. That’s why I'm saying it should be handled in board DT file. I think, most of current exynos big.LITTLE model should do if it could be changed according to board configuration. I also agreed it's not a SoC configuration since second patch(exynos5422.dtsi - exynos5422-cpu.dtsi). So how about creating exynos5422-cpus and exynos5420-cpus then including the cpus DT file in each board accordingly? Or more clear way to avoid confusion? In this situation, all exynos5422 boards(odroid xu3 series and mobile phone) have same cpu configurations. If we move the exynos5420 cpu configuration from exynos5420.dtsi, we should change all dts which including exynos5420.dtsi. Maybe same board configuration. Just adding inclusion should be fine at this moment. I think we'd better to defer the change until a new exynos5422 board which has different cpu configurations is added. I mean, according to current inclusion of exynos5422 based boards' DT file, it is including exynos5420 DT via exynos5800 DT and then override different cpu ordering (5422-cpu DT) because of different board configuration (just GPIO value) and it is not a good way in this case. Actually, I don't want to disturb current dts hierarchy even though it looks strange. The common features of exynos5800 and exynos5422 should be in the exynos5800.dtsi because they shared many things except the cpu order. Please consider the exynos5422-cpu.dtsi is just board configurations to represent cpu order. Yeah, strange and it can cause some confusing...but OK, we don't have much choice at the moment, so applied to support it even we need some re-work 'current dts hierarchy' next time. Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/12] ARM: SAMSUNG: local regs-srom header in mach-exynos
Krzysztof Kozlowski wrote: On 27.07.2015 23:57, Kukjin Kim wrote: This patch moves regs-srom header file into mach-exynos. Hi, Hi, Minor nits: 1. Could you trim it and remove unnecessary empty line before description? Yeah, actually I couldn't use git send-email when I submitted but just used e-mail. It should be fine in my local branch. 2. Could you answer in commit message: Why? Why are you moving the headers? OK, basically we don't need to keep headers in mach/xxx and plat/xxx if it is not required. For example, actually common.h files in mach-/ have been made/moved because of the reason before. Someday we did because it was required to support multi_v7 as well. Anyway it is still required and note that I have some more patches to move headers which are used only for under drivers/ not arch side into drivers/. And next step is removing some definitions which are not used more. c: Krzysztof Kozlowski k.kozlow...@samsung.com Malformed Cc: tag. Oh, OK. Thanks. One more thing, please ignore patch [09/12] ARM: SAMSUNG: local keypad header in mach-s3c64xx in this series because the header is used in plat-samsung as well. Anyway, thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
On Tue, Jul 28, 2015 at 4:02 PM, Mark Rutland mark.rutl...@arm.com wrote: On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. Are they actually interfaces to the same timer, or are they just fed by the same system counter? Good question goes to Samsung maintainers. I can find unanswered mail thread: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/258576.html Let me quote Kukjin: Basically the two blocks are connected and the arch timer uses the count value from MCT for reference I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? If they're the same device, then you can simply use the architected timer, and gain all the benefits without additional code. That could give you additional benefits (e.g. VDSO support). Right. I like the idea to use arch_timer. Odroid-xu3 works fine with it. Looks like Samsung have some games with power management stuff that can't be opened/told and they use MCT that works well for their needs. This draft patchset is only about little speedup of MCT operations that still here and used. To start arch timer we may need to initialize G_TCON register in MCT like it's done in Xen: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/platforms/exynos5.c;h=79e3a5faf9fa6f37d99040f85c6dccbd9312c856;hb=HEAD in exynos5_init_time(). I guess not all bootloaders properly initialize MCT on Exynos5 boards. If addition of similar platform callback and enable of arch_timer are steps in right direction I can take a look on it. Or as suggested in one mail thread: if MCT is present in DT then MCT driver lookup arch_timer in dt, find it, initialize G_TCON reg and gives up to allow arch_timer to do it job (in that case we need to init MCT before arch timer). Previous numbers for 100 gettimeofday() calls from userspace are about 1 ms. With this patches we have 0.5 ms or even better. So twice as fast. Just as matter of interest i tried to perform 200 sched_yield() calls from userspace. I see around 20% speedup with patches applied. I tried to use hackbench but it's hard to feel the difference, maybe speedup is 0.5% but with bad fluctuation. Everything is tested on odroid-xu3. Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't have arch timer. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014 -May/256943.html [2] https://lkml.org/lkml/2014/6/20/431 Current code created with such assumptions: -- don't want to insert huge refactoring in MCT code; -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit mode so i don't want to build described functionality on ARM64. For arm64 the generic timer is mandatory, and I can't imagine a case where we wouldn't use it in preference. Yep. That's why probably MCT isn't used on arm64. Currently i'm trying to patch odroid-xu3 DT only. -- firmware on odroid-xu3 is broken and secondary cores start in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode; -- in addition instead of DT property I may parse PFR regs and find Generic Timer Extension there. ID_PFR1.GenTimer only tells you whether or not the generic timer is implemented in the CPU, not how it's wired up (e.g. whether it shares the system counter with the MCT), so I don't think it tells you anything useful. Thanks, Mark. Yep, just only one of the initial points to understand is it any use trying. Thanks. Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] spi: s3c64xx: add more debug prints.
On Tue, Jul 28, 2015 at 09:37:03AM -, Michal Suchanek wrote: The SPI transfers can mysteriously fail so add more debug prints about SPI parameters set by the driver. The hardware specific SPI driver is the only place where the programmed SPI parameters are known so there is no other reasonable place for these prints. For timing things there should already be enough information in the trace points with better resolution. signature.asc Description: Digital signature
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Alexey, On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov klimov.li...@gmail.com wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? I hate to burst your bubble here, but... ...I think it would be a bad idea to use the cp15 counter on exynos 5422. According to Samsung, there are issues where using cp15 could sometimes return the wrong value, especially if you happen to read it while on an A7 instead of an A15. It will tend to work pretty well, but Samsung claimed that it might not work right on some CPUs or at some temperatures. I've added Alim who provided this information to me (in the private http://crosbug.com/p/29556). He may be able to elaborate more. Generally I'd say that if the arch timer works for you: use the arch timer. If the arch timer doesn't work for you, use the MCT. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
Hi Doug, On Tue, Jul 28, 2015 at 6:24 PM, Doug Anderson diand...@chromium.org wrote: Alexey, On Mon, Jul 27, 2015 at 2:28 PM, Alexey Klimov klimov.li...@gmail.com wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? I hate to burst your bubble here, but... ...I think it would be a bad idea to use the cp15 counter on exynos 5422. According to Samsung, there are issues where using cp15 could sometimes return the wrong value, especially if you happen to read it while on an A7 instead of an A15. It will tend to work pretty well, but Samsung claimed that it might not work right on some CPUs or at some temperatures. I think this is right time when I can say If only I had known about it before!. That's quite interesting especially about temperature issues. Maybe it's worth to insert comments in driver/docs about this. I've added Alim who provided this information to me (in the private http://crosbug.com/p/29556). He may be able to elaborate more. Alim, could you please add details if any? Generally I'd say that if the arch timer works for you: use the arch timer. If the arch timer doesn't work for you, use the MCT. -Doug I possess no knowledge if there're any different hw revisions of odroid-xu3 on the field but looks like arch timer works fine for me on odroid-xu3 Exynos5422 SoC with upstream kernel. Is it right direction to switch xu3 to arch timer? Do you have any info or ideas about enabling MCT G_TCON register to start arch timer and what's the best way to do it? Thanks. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] clocksource: exynos_mct: allow mct to read counter from coprocessor
On Tue, Jul 28, 2015 at 9:11 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On 28.07.2015 06:28, Alexey Klimov wrote:
It was discovered that 64-bit mmio MCT counter holds
the same value as ARM arch timer 64-bit physical counter.
Even more: arch timer and MCT are same underlying hardware
timer.
Patch adds code to MCT to allow it to read 64-bit counter
from coprocessor cp15 registers since it's way more
faster than reading the same counter from MCT mmio region.
That functionality triggers only if special property
use-cp15-phys-counter is present in device tree,
only on 32-bit ARMv7 systems and only if HYP mode is
available.
Hi,
It would be nice to put here also the measurements from cover letter.
This would be the justification for the commit.
Ok, I will add them. I will try to find time to perform more precise
measurements.
I guess same optimization could be done for ARMv8 Exynos SoCs?
I honestly don't know, don't have access to ARMv8 Exynos SoCs.
If i remember correctly there are no public-available 64-bit Exynos
boards yet. Exynos7420 is on the way to be released.
The main concern is that MCT probably not enabled for arm64 and
some cleanup/re-factoring is required for cycles_t variable. See
message in exynos4_read_current_timer() in MCT.
Also ARMv8 requires arm generic timer to be available and fully
operational. So for me it looks like current upstream kernel will work
on top of arm arch timer.
Idea of rewriting accessors is taken from arm_arch_timer.c.
By default MCT will read counter from mmio since it's
guaranteed to work.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
drivers/clocksource/exynos_mct.c | 77
++--
1 file changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 9064ff7..039b41c 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,6 +26,9 @@
#include linux/clocksource.h
#include linux/sched_clock.h
+#include asm/arch_timer.h /* for cp15 physical arch timer counter */
+#include asm/virt.h/* for checking HYP mode */
+
#define EXYNOS4_MCTREG(x)(x)
#define EXYNOS4_MCT_G_CNT_L EXYNOS4_MCTREG(0x100)
#define EXYNOS4_MCT_G_CNT_U EXYNOS4_MCTREG(0x104)
@@ -82,6 +85,17 @@ static unsigned long clk_rate;
static unsigned int mct_int_type;
static int mct_irqs[MCT_NR_IRQS];
+static u32 notrace __exynos4_read_count_32(void);
+static u64 __exynos4_read_count_64(void);
+
+/*
+ * Default to __exynos4_read_count_{32,64} functions that reads counter from
+ * MCT mmio region and this method is guaranteed
+ * to exist (if MCT was successfully initialized).
+ */
+u32 (*exynos4_read_count_32)(void) = __exynos4_read_count_32;
+u64 (*exynos4_read_count_64)(void) = __exynos4_read_count_64;
I think these could be static.
Yeah. Will fix it right away.
+
struct mct_clock_event_device {
struct clock_event_device evt;
unsigned long base;
@@ -163,16 +177,16 @@ static void exynos4_mct_frc_start(void)
}
/**
- * exynos4_read_count_64 - Read all 64-bits of the global counter
+ * __exynos4_read_count_64 - Read all 64-bits of the global counter
*
- * This will read all 64-bits of the global counter taking care to make sure
- * that the upper and lower half match. Note that reading the MCT can be
quite
- * slow (hundreds of nanoseconds) so you should use the 32-bit (lower half
- * only) version when possible.
+ * This will read all 64-bits of the global counter from MCT mmio region
+ * taking care to make sure that the upper and lower half match.
+ * Note that reading the MCT can be quite slow (hundreds of nanoseconds)
+ * so you should use the 32-bit (lower half only) version when possible.
*
* Returns the number of cycles in the global counter.
*/
-static u64 exynos4_read_count_64(void)
+static u64 __exynos4_read_count_64(void)
{
unsigned int lo, hi;
u32 hi2 = readl_relaxed(reg_base + EXYNOS4_MCT_G_CNT_U);
@@ -187,18 +201,45 @@ static u64 exynos4_read_count_64(void)
}
/**
- * exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ * __exynos4_read_cp15_count_64 - Read all 64-bits of the global counter
+ * from coprocessor regisers.
*
- * This will read just the lower 32-bits of the global counter. This is
marked
- * as notrace so it can be used by the scheduler clock.
+ * Note that reading here is faster than reading from MCT mmio region.
+ *
+ * Returns the number of cycles in the global counter.
+ */
+static u64 __exynos4_read_cp15_count_64(void)
+{
+ return arch_counter_get_cntpct();
+}
+
+/**
+ * __exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ *
+ * This will read just the lower 32-bits of the global counter from
+ * MCT mmio region.
+ * This is marked as notrace so it can be used by the scheduler
Re: [RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor
On Mon, Jul 27, 2015 at 10:28:27PM +0100, Alexey Klimov wrote: Hi all, year(s) ago it was discovered that MCT timer and ARM architectured timer are the same hardware with different interface. Here [1]. Are they actually interfaces to the same timer, or are they just fed by the same system counter? I followed mail-list discussions about removing MCT and using arch timer for Exynos5-based SoCs but things aren't moving at least latest upstream kernel on odroid-xu3 will use MCT as default timers. Maybe the reason are some power-management related things that very specific to Samsung. I don't know. Idea of this draft patchset comes from Doug patches when he tried to optimize read of 64-bit counter located in mmio. [2] Why not using cp15 counter instead if possible? If they're the same device, then you can simply use the architected timer, and gain all the benefits without additional code. That could give you additional benefits (e.g. VDSO support). Previous numbers for 100 gettimeofday() calls from userspace are about 1 ms. With this patches we have 0.5 ms or even better. So twice as fast. Just as matter of interest i tried to perform 200 sched_yield() calls from userspace. I see around 20% speedup with patches applied. I tried to use hackbench but it's hard to feel the difference, maybe speedup is 0.5% but with bad fluctuation. Everything is tested on odroid-xu3. Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't have arch timer. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014 -May/256943.html [2] https://lkml.org/lkml/2014/6/20/431 Current code created with such assumptions: -- don't want to insert huge refactoring in MCT code; -- target platform only ARMv7 Exynos5-based SoC that works in 32-bit mode so i don't want to build described functionality on ARM64. For arm64 the generic timer is mandatory, and I can't imagine a case where we wouldn't use it in preference. Currently i'm trying to patch odroid-xu3 DT only. -- firmware on odroid-xu3 is broken and secondary cores start in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode; -- in addition instead of DT property I may parse PFR regs and find Generic Timer Extension there. ID_PFR1.GenTimer only tells you whether or not the generic timer is implemented in the CPU, not how it's wired up (e.g. whether it shares the system counter with the MCT), so I don't think it tells you anything useful. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-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 3/3] ARM: dts: add MCT property use-cp15-phys-counter for exynos5422-odroidxu3
Hi Krzysztof,
On Tue, Jul 28, 2015 at 8:53 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On 28.07.2015 06:28, Alexey Klimov wrote:
Speedup MCT operation on odroid-xu3 dev board by using
coprocessor 64-bit counter instead of reading same counter
located in mmio region.
Tested on Odroid-xu3.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4
Please do this in Odroid XU3 common DTSI:
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 78e6a50..b7f6c8f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -18,6 +18,10 @@
compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
};
+mct {
+ use-cp15-phys-counter;
+};
+
Put the node in alphabetical position.
Best regards,
Krzysztof
Thanks. Will do it.
--
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line unsubscribe linux-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: kill off set_irq_flags usage
On Mon, Jul 27, 2015 at 03:55:13PM -0500, Rob Herring wrote: 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 modify 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 Cc: Russell King li...@arm.linux.org.uk Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Cc: Gregory Clement gregory.clem...@free-electrons.com Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com Acked-by: Shawn Guo shawn...@kernel.org Cc: Sascha Hauer ker...@pengutronix.de Cc: Imre Kaloz ka...@openwrt.org Acked-by: Krzysztof Halasa khal...@piap.pl Cc: Greg Ungerer g...@uclinux.org Cc: Roland Stigge sti...@antcom.de Cc: Tony Lindgren t...@atomide.com Cc: Daniel Mack dan...@zonque.org Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: Robert Jarzmik robert.jarz...@free.fr Cc: Simtec Linux Team li...@simtec.co.uk Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Acked-by: Wan ZongShun mcuos@gmail.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Tested-by: Kevin Hilman khil...@linaro.org --- Thomas asked that this be merged thru subsystem trees instead of arm-soc, so please apply just this patch to your tree. this be merged through subsystem trees + please apply just this patch. I'm going to assume that the first this means a patch series. So I've applied this to next/cleanup, let me know if this was in error and should be removed, it's easy to drop at this time. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] clocksource: exynos_mct: allow mct to read counter from coprocessor
On 28.07.2015 06:28, Alexey Klimov wrote:
It was discovered that 64-bit mmio MCT counter holds
the same value as ARM arch timer 64-bit physical counter.
Even more: arch timer and MCT are same underlying hardware
timer.
Patch adds code to MCT to allow it to read 64-bit counter
from coprocessor cp15 registers since it's way more
faster than reading the same counter from MCT mmio region.
That functionality triggers only if special property
use-cp15-phys-counter is present in device tree,
only on 32-bit ARMv7 systems and only if HYP mode is
available.
Hi,
It would be nice to put here also the measurements from cover letter.
This would be the justification for the commit.
I guess same optimization could be done for ARMv8 Exynos SoCs?
Idea of rewriting accessors is taken from arm_arch_timer.c.
By default MCT will read counter from mmio since it's
guaranteed to work.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
drivers/clocksource/exynos_mct.c | 77
++--
1 file changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 9064ff7..039b41c 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,6 +26,9 @@
#include linux/clocksource.h
#include linux/sched_clock.h
+#include asm/arch_timer.h /* for cp15 physical arch timer counter */
+#include asm/virt.h/* for checking HYP mode */
+
#define EXYNOS4_MCTREG(x)(x)
#define EXYNOS4_MCT_G_CNT_L EXYNOS4_MCTREG(0x100)
#define EXYNOS4_MCT_G_CNT_U EXYNOS4_MCTREG(0x104)
@@ -82,6 +85,17 @@ static unsigned long clk_rate;
static unsigned int mct_int_type;
static int mct_irqs[MCT_NR_IRQS];
+static u32 notrace __exynos4_read_count_32(void);
+static u64 __exynos4_read_count_64(void);
+
+/*
+ * Default to __exynos4_read_count_{32,64} functions that reads counter from
+ * MCT mmio region and this method is guaranteed
+ * to exist (if MCT was successfully initialized).
+ */
+u32 (*exynos4_read_count_32)(void) = __exynos4_read_count_32;
+u64 (*exynos4_read_count_64)(void) = __exynos4_read_count_64;
I think these could be static.
+
struct mct_clock_event_device {
struct clock_event_device evt;
unsigned long base;
@@ -163,16 +177,16 @@ static void exynos4_mct_frc_start(void)
}
/**
- * exynos4_read_count_64 - Read all 64-bits of the global counter
+ * __exynos4_read_count_64 - Read all 64-bits of the global counter
*
- * This will read all 64-bits of the global counter taking care to make sure
- * that the upper and lower half match. Note that reading the MCT can be
quite
- * slow (hundreds of nanoseconds) so you should use the 32-bit (lower half
- * only) version when possible.
+ * This will read all 64-bits of the global counter from MCT mmio region
+ * taking care to make sure that the upper and lower half match.
+ * Note that reading the MCT can be quite slow (hundreds of nanoseconds)
+ * so you should use the 32-bit (lower half only) version when possible.
*
* Returns the number of cycles in the global counter.
*/
-static u64 exynos4_read_count_64(void)
+static u64 __exynos4_read_count_64(void)
{
unsigned int lo, hi;
u32 hi2 = readl_relaxed(reg_base + EXYNOS4_MCT_G_CNT_U);
@@ -187,18 +201,45 @@ static u64 exynos4_read_count_64(void)
}
/**
- * exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ * __exynos4_read_cp15_count_64 - Read all 64-bits of the global counter
+ * from coprocessor regisers.
*
- * This will read just the lower 32-bits of the global counter. This is
marked
- * as notrace so it can be used by the scheduler clock.
+ * Note that reading here is faster than reading from MCT mmio region.
+ *
+ * Returns the number of cycles in the global counter.
+ */
+static u64 __exynos4_read_cp15_count_64(void)
+{
+ return arch_counter_get_cntpct();
+}
+
+/**
+ * __exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ *
+ * This will read just the lower 32-bits of the global counter from
+ * MCT mmio region.
+ * This is marked as notrace so it can be used by the scheduler clock.
*
* Returns the number of cycles in the global counter (lower 32 bits).
*/
-static u32 notrace exynos4_read_count_32(void)
+static u32 notrace __exynos4_read_count_32(void)
{
return readl_relaxed(reg_base + EXYNOS4_MCT_G_CNT_L);
}
+/**
+ * __exynos4_read_cp15_count_32 - Read the lower 32-bits of the global
counter
+ *
+ * This will read global counter from coprocessor regisers.
s/regisers/registers/
+ * This is marked as notrace so it can be used by the scheduler clock.
+ *
+ * Returns the number of cycles in the global counter (lower 32 bits).
+ */
+static u32 notrace __exynos4_read_cp15_count_32(void)
+{
+ return arch_counter_get_cntpct();
+}
+
Re: [PATCH v2] clk: exynos4: Fix wrong clock for Exynos4x12 ADC
On 07/26, Sylwester Nawrocki wrote: On 07/22/2015 08:41 AM, Krzysztof Kozlowski wrote: On 22.07.2015 07:42, Stephen Boyd wrote: On 06/12, Krzysztof Kozlowski wrote: [...] Signed-off-by: Krzysztof Kozlowskik.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 Did you want clk maintainers to apply this? The To: list is not helping so I'm not sure what's going on and it seems to have slipped through the cracks. Thank you for being proactive! I appreciate this. Some time ago Sylwester replied that he took care about this patch so I think this will go through Samsung clock tree. Sylwester, are you planning to send this as fix for 4.2-rc? I think it qualifies for 4.3, it's not a new regression and will be backported to -stable anyway. I would prefer clk maintainers have applied this, otherwise I would need to make a (questionable) pull request with only one patch, since all patches except this one after the last merge window were part of bigger series touching multiple subsystems and applied through the samsung soc tree. Ok. Applied to clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
