Re: [PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Tue, Jan 7, 2014 at 8:52 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 07 January 2014, Linus Walleij wrote: It appears that these problems appear if you explicitly enable the DT board support, can't we just put that into the defconfig then, so we don't miss such things? I don't understand. I didn't enable it manually and I still get it on linux-next-20130107. Maybe you were still on the older linux-next that had not been updated for some time? No that's not the problem, I used the latest... but: (...) I just tried building with make allmodconfig KCONFIG_ALLCONFIG=allconfig, with the allconfig file containing a CONFIG_MACH_S3C2410=y statement. This caught a number of additionl problems, some related and some not. This was the problem, so making new build rules now to see if I can catch this. What is actually the bigger worry here is that the contents of the new file, while correctly moved out of mach/gpio.h also don't belong into include/linux/platform_data, because they don't define a pdata structure but rather the contents that are supposed to be passed from the platform code. I would much prefer if you could move the file back into mach-s3c24xx/ under a new name and keep it out of platform_data. Unfortunately it cannot live right under mach-s3c24xx because there are drivers here and there referring directly to the contents of this file. The only quick-fix option would be to move it back to mach/gpio-samsung-s3c24xx.h but the real solution is of course to augment all drivers to use gpio descriptors and add descriptor tables to the boardfiles. I'm a bit reluctant to do that as I'd prefer to be able to test such modifications on HW ... plus time may be better invested in DT migration (as I think is the conclusion of this thread eventually). I suspect that the only thing actually needed by the gpio driver is the number of GPIO lines per platform, and we can find another way to communicate that. A bit more: if you look in drivers/gpio/gpio-samsung.c you see bank base GPIO offset for each bank into the global scope *and* the number of GPIOs for each bank propagated from machine headers instead of using platform data. Again the proper solution (if the boardfiles are kept) is to switch to using a GPIO descriptor table. Or using DT. Most of the contents should be private to the mach-s3c code and not be visible to either the gpio driver or any drivers using the plat/gpio-cfg.h interface. Samsungs plat/gpio-cfg.h is basically a custom legacy pin control implementation. The real solution to getting rid of that file is to switch over to using pinctrl-[samsung|s3c24xx] which as Heiko describes mandates also using DT, and thus blocks attempts at using this path for fixing the legacy boardfiles. It's one of these situations where we end up with an all-or-nothing conversion path: either you change everything over to device tree or everything stays in two copies ... I'm trying to refactor the existing board files here maybe that is in vain :-/ as GPIO maintainer I want to get rid of mach/gpio.h. Note that on Exynos, the solution for the gpio driver dependencies was to scrap the driver and use pinctrl-exynos instead. I think the S3C driver is a different piece of hardware unfortunately. But exynos was using this driver before it moved to the new pinctrl driver. I was wrong about this, too much in my head. As Tomasz says, pinctrl-samsung can be used, but mandates that everything is moved over to device tree. Probably the best thing now that I have one problem less is to leave it to the S3C maintainers to complete their DT migration? 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 V12 0/3] Add watchdog DT nodes and use syscon regmap interface to configure pmu registers
Hello Wim Van Sebroeck, I believe that I addressed all the comments given by reviewers. So can you look into this series and take necessary action..? Best Wishes, Leela Krishna. On Wed, Dec 18, 2013 at 9:01 PM, Leela Krishna Amudala l.kris...@samsung.com wrote: Hello Wim Van Sebroeck, Can you kindly look into this series and take necessary action..? Best Wishes, Leela Krishna. On Fri, Dec 6, 2013 at 2:47 PM, Leela Krishna Amudala l.kris...@samsung.com wrote: This patchset does the following things - Adds pmusysreg device node to exynos5.dtsi file - Adds watchdog DT nodes to Exynos5250 and 5420 - Uses syscon regmap interface to configure pmu registers to mask/unmask enable/disable of watchdog. This patch set is rebased on Kgene's for-next branch and tested on SMDK5420 changes since V11: - Added EXYNOS5 prefix to REG_OFFSET defines (suggested by Tomasz) - NEEDS_PMU_CONFIG = HAS_PMU_CONFIG (suggested by Olof, Guenter) - Move QUIRK_HAS_PMU_CONFIG check to s3c2410wdt_mask_and_disable_reset (suggested by Guenter) changes since V10: - followed coding style rules - removed duplicate error message suggested by Guenter Roeck li...@roeck-us.net changes since V9: - added descriptions to s3c2410_wdt_variant structure fields - moved calling s3c2410wdt_mask_and_disable_reset() function above s3c2410wdt_start() call in probe - put dev_err message back to s3c2410wdt_mask_and_disable_reset() function (suggested by Doug Anderson diand...@chromium.org) changes since V8: - modified the patch description for the below patch watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register - removed MODULE_ALIAS in watchdog driver - changed dev_warn to dev_err in one failure case handling (suggested by Guenter Roeck li...@roeck-us.net) - renamed variable name from pmu_config to drv_data - changed the compatible field description in documentation file (suggested by Tomasz Figa t.f...@samsung.com) changes since V7: - re-ordered the patches in the series - moved pmu_config_s3c2410 structure out of ifdef CONFIG_OF and limited only this structure to platform match table - renamed structure name from s3c_wdt_driver_ids to s3c2410_wdt_ids - removed exynos variants from platform match table (suggested by Tomasz Figa t.f...@samsung.com) changes since V6: - added SoC-specific compatible value to syscon node and documented it - given more patch description for below patch ARM: dts: update watchdog device nodes for Exynos5250 and Exynos5420 - added platform_device_id array for watchdog devices - selected MFD_SYSCON in Kconfig entry for watchdog Changes since V5: - removed status property in DT nodes - changed the return type for the function s3c2410wdt_mask_and_disable_reset() and handled error cases - Handled to get driver data in non-DT cases - Addressed comments given by Tomasz Figa t.f...@samsung.com Changes since V4: - changed the node name from pmusysreg to syscon and node label from pmu_sys_reg to pmu_syscon - changed the property name from samsung,pmusysreg to samsung,syscon-phandle - used regmap_update_bits instead of remap_read/regmap_write - Addressed other comments given by Tomasz Figa t.f...@samsung.com Changes since V3: - changed the compatible strings for watchdog node - splitted up adding pmusysreg node and made it separate patch - Addressed comments given by Sachin Kamat sachin.ka...@linaro.org Changes since V2: - used syscon regmap interface to configure pmu registers in WDT driver (suggested by Tomasz Figa t.f...@samsung.com) Changes since V1: - Added new compatible string for Exynos5 SoCs - Introduced quirk mechanism to program PMU registers - Addressed comments given by Tomasz Figa t.f...@samsung.com Leela Krishna Amudala (3): ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register ARM: dts: update watchdog device nodes for Exynos5250 and Exynos5420 .../devicetree/bindings/arm/samsung/pmu.txt| 15 ++ .../devicetree/bindings/watchdog/samsung-wdt.txt | 21 ++- arch/arm/boot/dts/exynos5.dtsi |7 - arch/arm/boot/dts/exynos5250.dtsi | 11 +- arch/arm/boot/dts/exynos5420.dtsi | 14 ++ drivers/watchdog/Kconfig |1 + drivers/watchdog/s3c2410_wdt.c | 154 ++-- 7 files changed, 205 insertions(+), 18 deletions(-) create mode 100644
Re: [PATCH 2/2] drm/exynos: Fix build after removal of DRM_WAKUP
On Wed, Jan 08, 2014 at 10:15:25AM +0900, Inki Dae wrote: 2014/1/8 Daniel Vetter dan...@ffwll.ch: Oops, looks like something slipped past between me making the patches and them getting merged. Thanks for taking care of this. Both patches are These patches already were posted by Seung-Woo link below, and I merged already them to exynos-drm-next. http://www.spinics.net/lists/dri-devel/msg50921.html Are you sure? I still need those patches in -next as of today. signature.asc Description: Digital signature
Re: [PATCH 2/2] drm/exynos: Fix build after removal of DRM_WAKUP
Hello, On 2014년 01월 08일 21:03, Mark Brown wrote: On Wed, Jan 08, 2014 at 10:15:25AM +0900, Inki Dae wrote: 2014/1/8 Daniel Vetter dan...@ffwll.ch: Oops, looks like something slipped past between me making the patches and them getting merged. Thanks for taking care of this. Both patches are These patches already were posted by Seung-Woo link below, and I merged already them to exynos-drm-next. http://www.spinics.net/lists/dri-devel/msg50921.html Are you sure? I still need those patches in -next as of today. Yes, at least for exynos-drm-next tree of Inki. Inki sent pull request including my patch yesterday. Best Regards, - Seung-Woo Kim -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] spi: s3c24xx: Remove reference to plat/fiq.h
On Tue, Dec 31, 2013 at 02:00:39PM +0530, Sachin Kamat wrote: fiq.h contains only a function declaration and is not used by anyone else. Move the declaration to the driver header file and remove the unnecessary platform dependency from the driver. Applied, thanks. signature.asc Description: Digital signature
[PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.
The erratum-773769 occurs on Arm Coretex-A15 (rev r2p0), when L2 Data Ram latency is set to 4 cycles or more; or when ACP is in use, or with L2 Data RAM slice configured. Therefore, the effective latency as calculated in Table 7-2 of Cotex-A15 (rev r2p0) trm should be 3 cycles or less. On Exynos5250 based systems the effective data ram latency is 4 cycles, since we have DATA_RAM_SETUP bit enabled (L2CTRL[5]=1b'1) and DATA_RAM_LATENCY bits set to 0x2 (L2CTLR[2:0]=3b'010) therefore, the effective L2 data RAM latency becomes 4 cycles. So erratum '773769' occurs causing a corrupted L2 Cache. This patch gives a workaround to the mentioned erratum, using below mentioned algo: if data RAM setup = 1 then check if effective latency i.e (latency + setup + 1) 3 if 'true' then clear data RAM setup goto branch 'a' if data RAM setup = 0 a: then check if data RAM latency 0x10 if true then force data RAM latency = 0x10 so that the effective data RAM latency reduces to 3 cycles or less and hence prevent hitting the erratum. NOTE: The Exynos5250 based products have already been shipped, which makes it impossible to add the change in bootloader, so we are adding the required change in kernel. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Doug Anderson diand...@chromium.org Cc: Olof Johansson ol...@chromium.org Cc: David Garbett david.garb...@arm.com --- arch/arm/Kconfig | 15 arch/arm/mach-exynos/Kconfig |1 + arch/arm/mm/proc-v7.S| 79 ++ 3 files changed, 95 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c59fa19..2e6f36c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1250,6 +1250,21 @@ config ARM_ERRATA_751472 operation is received by a CPU before the ICIALLUIS has completed, potentially leading to corrupted entries in the cache or TLB. +config ARM_ERRATA_773769 + bool ARM errata: Large data RAM latencies can lead to rare data corruption + depends on CPU_V7 + help + This option enables the workaround for the erratum 773769, which affects + Cortex-A15 (rev r2p0). + In systems with L2 Data RAM latency programmed to 4 or more cycles, + or with ACP in use, or with a L2 Data RAM slice configured, it is + possible that a rare collision between non-cacheable stores and + L1 data cache evictions which can lead to data corruption in L2 cache + or memory. + This workaround is to configure an effective Data RAM latency of 3 or + less. Also note that, if a Data RAM slice is configured in A15 then + there is no workaround. + config PL310_ERRATA_753970 bool PL310 errata: cache sync operation may be faulty depends on CACHE_PL310 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 4c414af..29f505f 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -82,6 +82,7 @@ config SOC_EXYNOS5250 default y depends on ARCH_EXYNOS5 select ARCH_HAS_BANDGAP + select ARM_ERRATA_773769 select PINCTRL_EXYNOS select PM_GENERIC_DOMAINS if PM select S5P_PM if PM diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index bd17819..0674c4c 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -141,6 +141,49 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r4, c10, c2, 0 @ write PRRR mcr p15, 0, r5, c10, c2, 1 @ write NMRR #endif /* CONFIG_MMU */ + +#ifdef CONFIG_ARM_ERRATA_773769 + /* get the arm rev id */ + mrc p15, 0, r3, c0, c0, 0 @ read main ID register + and r4, r3, #0xff00 @ ARM? + teq r4, #0x4100 + bne 8f + and r5, r3, #0x00f0 @ variant + and r7, r3, #0x000f @ revision + orr r7, r7, r5, lsr #20-4 @ combine variant and revision + ubfxr3, r3, #4, #12 @ primary part number + + ldr r4, =0x0c0f @ Cortex-A15 primary part number + teq r3, r4 + bne 8f + + ALT_SMP(cmp r7, #0x21) @ present prior to r2p1 + ALT_UP_B(8f) + mrclt p15, 0, r3, c1, c0, 0 @ read system control register + andlt r3, r3, #0x4@ mask for C bit + cmplt r3, #0x0@ check if cache is on/off + bne 8f @ Do nothing when cache is on + + mrceq p15, 1, r5, c9, c0, 2 @ read L2 control register + andeq r3, r5, #(1 5) @ mask for data RAM setup + lsreq r3, r3, #0x5 + cmpeq r3, #0x1@ check if data RAM setup
Re: USB broken on Exynos 5250 with 3.13-rc6 kernel
Hi John, On Sat, Jan 4, 2014 at 3:30 AM, John Dulaney jdula...@redhat.com wrote: I build 3.13-rc6 for exynso-5250. After installing the kernel and rebooting my machine, everything worked (lpae out of the box, even) except for usb; I rebuilt the kernel a couple of times, poking at USB config options, but was completely unable to get USB to work. Which exynos5250 machine are you trying the kernel ? I tested linux-next kernel 3.13-rc7 on smdk5250, and on that i could get USB working (i checked XHCI ports actually, but i am sure EHCI ports will also work straight away). Please make sure you are building with exynos_defconfig. And on top of that i enabled following configs: CONFIG_USB_ANNOUNCE_NEW_DEVICES CONFIG_USB_XHCI_HCD CONFIG_USB_EHCI_EXYNOS CONFIG_USB_OHCI_HCD (these OHCI configs will serve the purpose to use HID) CONFIG_USB_OHCI_EXYNOS [...] -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
On Wed, Jan 08, 2014 at 01:33:11PM +, Vivek Gautam wrote: The erratum-773769 occurs on Arm Coretex-A15 (rev r2p0), when L2 Data Ram latency is set to 4 cycles or more; or when ACP is in use, or with L2 Data RAM slice configured. Therefore, the effective latency as calculated in Table 7-2 of Cotex-A15 (rev r2p0) trm should be 3 cycles or less. On Exynos5250 based systems the effective data ram latency is 4 cycles, since we have DATA_RAM_SETUP bit enabled (L2CTRL[5]=1b'1) and DATA_RAM_LATENCY bits set to 0x2 (L2CTLR[2:0]=3b'010) therefore, the effective L2 data RAM latency becomes 4 cycles. So erratum '773769' occurs causing a corrupted L2 Cache. This patch gives a workaround to the mentioned erratum, using below mentioned algo: if data RAM setup = 1 then check if effective latency i.e (latency + setup + 1) 3 if 'true' then clear data RAM setup goto branch 'a' if data RAM setup = 0 a: then check if data RAM latency 0x10 if true then force data RAM latency = 0x10 so that the effective data RAM latency reduces to 3 cycles or less and hence prevent hitting the erratum. NOTE: The Exynos5250 based products have already been shipped, which makes it impossible to add the change in bootloader, so we are adding the required change in kernel. NAK. Whilst I appreciate that you may not be able to fix your bootloader, this isn't the right change to make in the kernel. Blindly changing memory latencies is likely to do more harm than good for a multi-platform kernel, even if it works for exynos 5250. The only alternative I can think of (if you have to make a mainline kernel change) is to restrict the clock frequencies at which the CPU is allowed to run, although that obviously requires some investigation in order to determine how viable it is for your SoC. Will -- To unsubscribe from this list: send the line unsubscribe linux-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 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Wednesday 08 January 2014, Arnd Bergmann wrote: On Wednesday 08 January 2014, Linus Walleij wrote: On Tue, Jan 7, 2014 at 8:52 PM, Arnd Bergmann a...@arndb.de wrote: b I was wrong about this, too much in my head. As Tomasz says, pinctrl-samsung can be used, but mandates that everything is moved over to device tree. Probably the best thing now that I have one problem less is to leave it to the S3C maintainers to complete their DT migration? Let me have another look first, maybe I can find an intermediate step that helps you on your conquest to kill mach/gpio.h. I've asked the mighty grep and it said that these are the files using the contents you moved around: drivers/gpio/gpio-samsung.c drivers/leds/leds-s3c24xx.c drivers/mmc/host/s3cmci.c sound/soc/samsung/h1940_uda1380.c sound/soc/samsung/neo1973_wm8753.c sound/soc/samsung/rx1950_uda1380.c sound/soc/samsung/s3c2412-i2s.c sound/soc/samsung/s3c24xx-i2s.c sound/soc/samsung/smartq_wm8987.c The symbols used in these drivers are: S3CGP.() S3C_GPIO_END S3C_GPIO_PULL_.* S3C_GPIO_SFN() s3c_gpio_cfgall_range() s3c_gpio_setpull() which is basically all of the mach/gpio.h file, plus a few small parts of the plat/gpio-cfg.h file. The rest of plat/gpio-cfg.h however is used in board files to call into the gpio-samsung.c driver, so we still need the header file for those, until the board files get replaced with DT descriptions using the pinctrl interface. I think it would be worthwhile to go ahead and make all inclusions of the plat/gpio-cfg.h file explicit, and remove it from mach/gpio.h, that part should be simple enough and helpful at the same time. Besides the leds-s3c24xx.c and gpio-samsung.c files we already talked about, I think it's only s3cmci.c, s3c2412-i2s.c and s3c24xx-i2s.c that still need this outside of mach-s3c*. The correct way to get rid of S3C_GP. and S3C_GPIO_END would be to pass the GPIO numbers from platform code in platform_data pointers. It's not hard to do, but tedious to get right for the seven drivers that need them. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
WIll, Thanks for your comments! On Wed, Jan 8, 2014 at 6:35 AM, Will Deacon will.dea...@arm.com wrote: On Wed, Jan 08, 2014 at 01:33:11PM +, Vivek Gautam wrote: The erratum-773769 occurs on Arm Coretex-A15 (rev r2p0), when L2 Data Ram latency is set to 4 cycles or more; or when ACP is in use, or with L2 Data RAM slice configured. Therefore, the effective latency as calculated in Table 7-2 of Cotex-A15 (rev r2p0) trm should be 3 cycles or less. On Exynos5250 based systems the effective data ram latency is 4 cycles, since we have DATA_RAM_SETUP bit enabled (L2CTRL[5]=1b'1) and DATA_RAM_LATENCY bits set to 0x2 (L2CTLR[2:0]=3b'010) therefore, the effective L2 data RAM latency becomes 4 cycles. So erratum '773769' occurs causing a corrupted L2 Cache. This patch gives a workaround to the mentioned erratum, using below mentioned algo: if data RAM setup = 1 then check if effective latency i.e (latency + setup + 1) 3 if 'true' then clear data RAM setup goto branch 'a' if data RAM setup = 0 a: then check if data RAM latency 0x10 if true then force data RAM latency = 0x10 so that the effective data RAM latency reduces to 3 cycles or less and hence prevent hitting the erratum. NOTE: The Exynos5250 based products have already been shipped, which makes it impossible to add the change in bootloader, so we are adding the required change in kernel. NAK. Whilst I appreciate that you may not be able to fix your bootloader, this isn't the right change to make in the kernel. Blindly changing memory latencies is likely to do more harm than good for a multi-platform kernel, even if it works for exynos 5250. The only alternative I can think of (if you have to make a mainline kernel change) is to restrict the clock frequencies at which the CPU is allowed to run, although that obviously requires some investigation in order to determine how viable it is for your SoC. OK, so humor me a little here... I'll start off by saying that I'm totally OK if mainline doesn't want this fixed. If mainline is not interested in running reliably on exynos5250-based products then there's nothing I can do about it. It seems unfortunate, but I'm not going to get into a shouting match about it. You're saying that this patch is blindly changing memory latencies. I don't think it is (please correct me if I'm wrong!). This patch: * Is guarded by a CONFIG option so the code isn't even compiled in if you don't want EXYNOS5250 support. I know this doesn't help multiplatform, but it means that if you really hate the code it's easy to disable. * Is guarded by a runtime check of the revision number so that it doesn't run on unaffected A15 revisions. * Is guarded by a runtime check so it does nothing at all if the total latency is = 3 (AKA if boot code already picked a sane value) ...with the above guards it's pretty safe... I will agree that there is a _potential_ that this could make things work worse on an already broken product our there, but I would say there's a reasonable chance that such a product doesn't exist (but please correct me if I'm wrong). Specifically, this patch will cause problems in two examples that I can think of: -- Example A: existing A15 =r2p0 product with 773769-ignorant boot code that could be fixed, but that needs setup = 1 In this case we've got boot code that's like the exynos5250 boot code that accidentally sets the total latency to = 4 when it would work just fine to use a value of 3. ...except that unlike the exynos5250 this hypthetical SoC needs to leave setup = 1. ...if such a machine were found in the wild (seems unlikely?) then we'll need to figure out what to do. If its boot code cannot be updated and we want to support this product with a similar patch then we'll need to be more dynamic. -- Example B: existing A15 =r2p0 product that just has to live with crashes In this case we've got a product where we're going to just accept that it crashes sometimes (since this is a fairly hard crash to trigger) because it crashes even more when the total latency 4. In this case we don't want to fix the errata because that makes things worse. ...if such a machine were find in the wild (it's possible, I guess?) then that's a really good reason not to take this patch or to find some way to dynamically enable / disable it. -- Let me know what you think of the above, or if I'm misunderstanding something... -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 v2 0/8] clk: max77686: Clock provider implementation fixes
On Wednesday 08 of January 2014 08:31:38 Mike Turquette wrote: Quoting Tomasz Figa (2014-01-02 07:22:12) On Tuesday 31 of December 2013 11:42:15 Mike Turquette wrote: Quoting Tomasz Figa (2013-12-12 08:07:13) This series intends to improve clock provider impementation of max77686 PMIC driver. First two patches are simple fixes of current implementation to allow correct control of provided clocks. Further patches refactor the driver to make the code cleaner and prepare for further patches. Then last two patches add registration of OF clock provider and adjust device tree nodes of boards containing max77686 chip to contain properties required by clock provider. Acked-by: Mike Turquette mturque...@linaro.org Hmm... Shouldn't this series go through the clk tree directly? If not, who should be taking it? Yes it should, but I guessed it would come in a pull request. Maybe Ack is the wrong thing? I can just say looks good to me me or something else. Nah, I think Ack is completely right, but still this series is quite standalone, e.g. it does not really belong to samsung-clk nor any other clock subtree, so I thought you would be applying them directly. I believe Lee has already applied this one, but in future, to avoid such confusion, if it's more convenient for you, I can send you any clock series as pull requests. 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 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Tue, Jan 07, 2014 at 07:27:49PM +0100, Linus Walleij wrote: I think the S3C driver is a different piece of hardware unfortunately. It's not, the IP is basically the same - the difference between s3c, s5p and Exynos is a marketing one, Samsung have generally just reused IP where that is reasonable. There's a great deal of continuity in the platforms. signature.asc Description: Digital signature
Re: [PATCH] MAINTAINERS: Add entry for Samsung SoC clock drivers
Quoting Tomasz Figa (2013-12-05 02:09:10) Hi, On Saturday 09 of November 2013 03:17:34 Tomasz Figa wrote: From: Tomasz Figa t.f...@samsung.com This patch adds an entry for Samsung SoC clock drivers located under drivers/clk/samsung/ directory, with me taking the maintainer role. Signed-off-by: Tomasz Figa t.f...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Mike Turquette mturque...@linaro.org Acked-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Kukjin Kim kgene@samsung.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 61b8757..df7e1bf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7319,6 +7319,12 @@ L: linux-me...@vger.kernel.org S: Supported F: drivers/media/i2c/s5c73m3/* +SAMSUNG SOC CLOCK DRIVERS +M: Tomasz Figa t.f...@samsung.com +S: Supported +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) +F: drivers/clk/samsung/ + SERIAL DRIVERS M: Greg Kroah-Hartman gre...@linuxfoundation.org L: linux-ser...@vger.kernel.org I don't see this patch applied anywhere. Mike, should it go through your tree? Taken into clk-next. Regards, Mike 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/8] clk: max77686: Clock provider implementation fixes
I believe Lee has already applied this one, but in future, to avoid such confusion, if it's more convenient for you, I can send you any clock series as pull requests. Me? I haven't applied any clk patches. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC alternative ver 1] phy: Exynos 421x USB 2.0 PHY support
Hi Kishon, Thank you for your review. From: Kishon Vijay Abraham I [mailto:kis...@ti.com] Sent: Monday, January 06, 2014 11:24 AM Hi, On Friday 20 December 2013 06:54 PM, Kamil Debski wrote: This the alternative version of the support for Exynos 421x USB 2.0 PHY in the Generic PHY framework. In this version the support for Exynos 4210 and 4212 was joined into one file. Signed-off-by: Kamil Debski k.deb...@samsung.com --- Hi, Me and Kishon were discussing for quite a long time the way how Exynos 4 should be handled. I have decided to post the original patches and try to make an alternative version with support for Exynos 4210 and 4212 joined in one file. I have prepared two versions. The first one has 506 lines (vs 563 when two files are used). When doing the second version I was a little more aggresive in removing code. This was done at a cost of adding if's deciding which SoC version the driver is dealing with in some internal functions. This resulted in a better number of removed lines - the second version has only 452 lines (vs 563 original and 506 version 1). Alright.. If the alternate approach doesn't give too much of advantage, lets stick with the original one. I would recommend creating a documentation (Documentation/phy/?) for the samsung PHY since that actually creates a layer on top of generic PHY framework. That would help while adding new samsung PHY drivers. Ok, I will prepare an updated set of patches with the documentation added. Also I will fix other issues you pointed out in reply to other patches from this series. Btw thank you for preparing alternate versions for your original patches. No problem :) Best wishes, -- Kamil Debski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-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 4/5] arm: omap3: twl: use the new lookup method with usb phy
* Heikki Krogerus heikki.kroge...@linux.intel.com [131209 07:10]:
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
This seems safe to queue via the USB list:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = musb-hdrc.0,
+ .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
};
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
};
static int omap3_batt_table[] = {
@@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_add_lookup_table(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
1.8.5.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 v5 3/9] phy: Add new Exynos USB 2.0 PHY driver
Hi,
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Monday, January 06, 2014 11:12 AM
Hi,
On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 55
drivers/phy/Kconfig| 29 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos4210-usb2.c | 257
drivers/phy/phy-exynos4212-usb2.c | 306
drivers/phy/phy-samsung-usb2.c | 226
+++
drivers/phy/phy-samsung-usb2.h | 67 +
7 files changed, 943 insertions(+)
create mode 100644 drivers/phy/phy-exynos4210-usb2.c
create mode 100644 drivers/phy/phy-exynos4212-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.h
.
.
snip
.
.
diff --git a/drivers/phy/phy-samsung-usb2.h
b/drivers/phy/phy-samsung-usb2.h new file mode 100644 index
000..ab89f91
--- /dev/null
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -0,0 +1,67 @@
+/*
+ * Samsung SoC USB 1.1/2.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _PHY_EXYNOS_USB2_H
+#define _PHY_EXYNOS_USB2_H
+
+#include linux/clk.h
+#include linux/phy/phy.h
+#include linux/device.h
+#include linux/regmap.h
+#include linux/spinlock.h
+
+#define KHZ 1000
+#define MHZ (KHZ * KHZ)
+
+struct samsung_usb2_phy_driver;
+struct samsung_usb2_phy_instance;
+struct samsung_usb2_phy_config;
+
+struct samsung_usb2_phy_instance {
+ const struct samsung_usb2_common_phy *cfg;
+ struct clk *clk;
+ struct phy *phy;
+ struct samsung_usb2_phy_driver *drv;
+ unsigned long rate;
+ u32 clk_reg_val;
+ bool enabled;
+};
+
+struct samsung_usb2_phy_driver {
+ const struct samsung_usb2_phy_config *cfg;
+ struct clk *clk;
+ struct device *dev;
+ void __iomem *reg_phy;
+ struct regmap *reg_pmu;
+ struct regmap *reg_sys;
+ spinlock_t lock;
+ struct samsung_usb2_phy_instance instances[0];
I think having instances as array here would allocate more space while
allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.
I am not sure if I understand you correctly here. Maybe I will explain
what I intended to write. An array with size 0 at the end of a structure
takes no space in the structure. The benefit of using it is that after
the structure one can allocate a number of the array elements and
address them easily. Another option would be placing pointer in the
samsung_usb2_phy_instance and allocate memory separately, but this would
involve two allocations and a pointer would be always present in the
structure.
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-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/8] clk: max77686: Clock provider implementation fixes
Quoting Lee Jones (2014-01-08 09:15:44) I believe Lee has already applied this one, but in future, to avoid such confusion, if it's more convenient for you, I can send you any clock series as pull requests. Me? I haven't applied any clk patches. I have taken patches 1-7 into clk-next just now. I can take patch #8 as well but it would probably be better to send it through arm-soc? Regards, Mike -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] clk: max77686: Clock provider implementation fixes
On Wednesday 08 of January 2014 09:59:39 Mike Turquette wrote: Quoting Lee Jones (2014-01-08 09:15:44) I believe Lee has already applied this one, but in future, to avoid such confusion, if it's more convenient for you, I can send you any clock series as pull requests. Me? I haven't applied any clk patches. I have taken patches 1-7 into clk-next just now. Thanks. I can take patch #8 as well but it would probably be better to send it through arm-soc? Hmm, patch 8 is trivial enough to not cause any merge conflicts, but since it's unlikely that any users depending on introduced changes will show up for 3.14 it shouldn't really matter which tree it goes through... 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.14
Hi Mike, Please consider pulling following Samsung Clock changes for v3.14. The following changes since commit 2bb00c68e094271b79deac993893461cc051b721: Merge branch 'samsung-fixes' into samsung-next-base (2013-12-30 18:15:23 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.14/samsung-clk for you to fetch changes up to 59d711e9ddd2f68822a2a99fc939e11a9288b73e: ARM: dts: exynos5420: add input clocks to audss clock controller (2014-01-08 18:02:43 +0100) (A bit late) first round of Samsung clock patches for v3.14. Andrew Bresticker (7): clk: exynos5250: register APLL rate table clk: exynos-audss: convert to platform device clk: exynos-audss: allow input clocks to be specified in device tree clk: exynos5250: add clock ID for div_pcm0 ARM: dts: exynos5250: add input clocks to audss clock controller clk: exynos-audss: add support for Exynos 5420 ARM: dts: exynos5420: add input clocks to audss clock controller Andrzej Hajda (8): ARM: exynos4: create a DT header defining CLK IDs clk: exynos4: replace clock ID private enums with IDs from DT header ARM: exynos5250: create a DT header defining CLK IDs clk: exynos5250: replace clock ID private enums with IDs from DT header ARM: exynos5420: create a DT header defining CLK IDs clk: exynos5420: replace clock ID private enums with IDs from DT header ARM: exynos5440: create a DT header defining CLK IDs clk: exynos5440: replace clock ID private enums with IDs from DT header Sachin Kamat (1): clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll Tomasz Figa (7): clk: samsung: exynos5250: Sort definitions by registers and bitfield clk: samsung: exynos5250: Make names of mux and div clocks consistent clk: samsung: exynos5250: Fix parents of gate clocks from GSCL domain clk: samsung: exynos5250: Fix parent of gate clocks from DISP1 domain clk: samsung: exynos5250: Add missing unpopulated mux parents clk: samsung: exynos5250: Correct parent list of audio muxes clk: samsung: exynos5250: Fix parents of gate clocks from MFC domain .../devicetree/bindings/clock/clk-exynos-audss.txt | 39 +- .../devicetree/bindings/clock/exynos5250-clock.txt | 1 + arch/arm/boot/dts/exynos5250.dtsi | 2 + arch/arm/boot/dts/exynos5420.dtsi | 4 +- drivers/clk/samsung/clk-exynos-audss.c | 159 +++- drivers/clk/samsung/clk-exynos4.c | 857 ++--- drivers/clk/samsung/clk-exynos5250.c | 699 ++--- drivers/clk/samsung/clk-exynos5420.c | 648 drivers/clk/samsung/clk-exynos5440.c | 81 +- include/dt-bindings/clk/exynos-audss-clk.h | 3 +- include/dt-bindings/clock/exynos4.h| 244 ++ include/dt-bindings/clock/exynos5250.h | 160 include/dt-bindings/clock/exynos5420.h | 188 + include/dt-bindings/clock/exynos5440.h | 42 + 14 files changed, 1957 insertions(+), 1170 deletions(-) create mode 100644 include/dt-bindings/clock/exynos4.h create mode 100644 include/dt-bindings/clock/exynos5250.h create mode 100644 include/dt-bindings/clock/exynos5420.h create mode 100644 include/dt-bindings/clock/exynos5440.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.
On Wed, Jan 08, 2014 at 08:21:21AM -0800, Doug Anderson wrote: WIll, Thanks for your comments! On Wed, Jan 8, 2014 at 6:35 AM, Will Deacon will.dea...@arm.com wrote: NAK. Whilst I appreciate that you may not be able to fix your bootloader, this isn't the right change to make in the kernel. Blindly changing memory latencies is likely to do more harm than good for a multi-platform kernel, even if it works for exynos 5250. The only alternative I can think of (if you have to make a mainline kernel change) is to restrict the clock frequencies at which the CPU is allowed to run, although that obviously requires some investigation in order to determine how viable it is for your SoC. +1 I'll start off by saying that I'm totally OK if mainline doesn't want this fixed. If mainline is not interested in running reliably on exynos5250-based products then there's nothing I can do about it. It seems unfortunate, but I'm not going to get into a shouting match about it. No, we're saying to put the work-around in the boot loader, not the kernel. You're saying that this patch is blindly changing memory latencies. I don't think it is (please correct me if I'm wrong!). This patch: * Is guarded by a CONFIG option so the code isn't even compiled in if you don't want EXYNOS5250 support. I know this doesn't help multiplatform, but it means that if you really hate the code it's easy to disable. As you identify, this is completely useless in the multiplatform kernel case, so you can completely remove this from the argument _for_ this change - it carries no weight what so ever. * Is guarded by a runtime check of the revision number so that it doesn't run on unaffected A15 revisions. So what if the A15 reports an affected revision, but the SoC integrator has fixed the problem - why should they have to put up with the work- around being applied on their silicon? * Is guarded by a runtime check so it does nothing at all if the total latency is = 3 (AKA if boot code already picked a sane value) Right, so the effect of the above is that with a multiplatform kernel including Exynos 5 support, all platforms with an A15 r2p0 or earlier have this work-around applied even if it was actually fixed in the silicon - which there's no way to know from the software perspective. We've been through these arguments many times, you're not the first to raise it, and we've decided upon the policy. We want as _few_ work- arounds in the kernel as possible, because applying the work-arounds is very problematical with the mixture of secure and non-secure booting. Maybe Will can check, but I believe that the L2 cache control register is one of those which is not writable from non-secure mode, and thus will crash the kernel at boot if a write is attempted. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
Hi, On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jan 08, 2014 at 08:21:21AM -0800, Doug Anderson wrote: WIll, Thanks for your comments! On Wed, Jan 8, 2014 at 6:35 AM, Will Deacon will.dea...@arm.com wrote: NAK. Whilst I appreciate that you may not be able to fix your bootloader, this isn't the right change to make in the kernel. Blindly changing memory latencies is likely to do more harm than good for a multi-platform kernel, even if it works for exynos 5250. The only alternative I can think of (if you have to make a mainline kernel change) is to restrict the clock frequencies at which the CPU is allowed to run, although that obviously requires some investigation in order to determine how viable it is for your SoC. +1 I'll start off by saying that I'm totally OK if mainline doesn't want this fixed. If mainline is not interested in running reliably on exynos5250-based products then there's nothing I can do about it. It seems unfortunate, but I'm not going to get into a shouting match about it. No, we're saying to put the work-around in the boot loader, not the kernel. Unfortunately the resume path of the firmware runs from Read Only firmware code (yes, it sucks), so it's not totally trivial to fix. It would be possible for someone to unscrew their write protect switch and update their RO firmware, but that doesn't help the average user. Olof came up with the idea that you could update the RW firmware (affects initial boot) and then cache away the value and restore it in the kernel after resume. That would still require a kernel patch but perhaps a less objectionable one. ...of course if writing this register is a problem in secure mode then maybe that patch would be NAKed anyway. * Is guarded by a runtime check of the revision number so that it doesn't run on unaffected A15 revisions. So what if the A15 reports an affected revision, but the SoC integrator has fixed the problem - why should they have to put up with the work- around being applied on their silicon? That's one I didn't think about, you're right. ...but we're really getting into hypothetical situations here. Are there any r2p0 products that have such a fix (and thus require a latency of = 4)? We've been through these arguments many times, you're not the first to raise it, and we've decided upon the policy. We want as _few_ work- arounds in the kernel as possible, because applying the work-arounds is very problematical with the mixture of secure and non-secure booting. OK, fair enough. If we want no workaround here then we can drop this patch. I'd guess that the way forward is: * Land kernel workaround locally in Chromium tree * I'll try to land FW change locally in at least one Chromium branch. If we were to get a new RO build ever (seems unlikely at this point) it would be fixed for upstream kernels. If we were to get a new RW build (seems unlikely, but at least less unlikely) it would be fixed if someone landed a kernel patch to save/restore this register across suspend/resume. * If Joe Upstream wants to run an upstream kernel on some type of exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 are the ones I know of) then he will deal with the small number of crashes or figure out a solution. -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 v2] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
Hi Doug, The existing watchdog timeout worked OK but didn't deal with rounding in an ideal way when dividing out all of its clocks. Specifically if you had a timeout of 32 seconds and an input clock of , you'd end up setting a timeout of 31.9998 seconds and reporting a timeout of 31 seconds. Specifically DBG printouts showed: s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833 s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656 (ff4f) and the final timeout reported to the user was: ((count / divisor) * divisor) / freq (0xff4f * 255) / 520833 = 31 (truncated from 31.9998) the technically correct value is: (0xff4f * 255) / (.0 / 128) = 31.9998 By using DIV_ROUND_UP we can be a little more correct. s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834 s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688 (ff50) and the final timeout reported to the user: (0xff50 * 255) / 520834 = 32 the technically correct value is: (0xff50 * 255) / (.0 / 128) = 32.0003 We'll use a DIV_ROUND_UP to solve this, generally erroring on the side of reporting shorter values to the user and setting the watchdog to slightly longer than requested: * Round input frequency up to assume watchdog is counting faster. * Round divisions by divisor up to give us extra time. At the same time we can avoid a for loop by just doing the right math. Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v2: - Avoid a for loop as per Guenter. Patch added to linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-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] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ
Hi Doug, On modern SoCs the watchdog timer is parented on a clock that doesn't change every time we have a cpufreq change. That means we don't need to constantly adjust the watchdog timer, so avoid registering for and dealing with cpufreq transitions unless we've actually got CONFIG_ARM_S3C24XX_CPUFREQ defined. Note that this is more than just an optimization. The s3c2410 watchdog driver actually pats the watchdog on every CPU frequency change. On modern systems these happen many times per second (even in a system where nothing is happening). That effectively makes any userspace watchdog program useless (the watchdog is constantly patted by the kernel). If we need ARM_S3C24XX_CPUFREQ defined on a multiplatform kernel we'll need to make sure that kernel supports common clock and change this to user common clock framework. Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v2: - Use the updated config name. Patch added to linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line unsubscribe linux-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: Looking for example to use samsung jpeg v4l2 mem2mem driver
Hi, On 01/01/2014 12:39 AM, m silverstri wrote: Hi, I am looking for an example which uses samsung jpeg v4l2 mem2mem driver. For example the 'Exynos4 JPEG codec v4l2 driver' described here http://lwn.net/Articles/468547 I am new to linux v4l2 driver. I am looking for example to pass an input image to hardware accelerated encoder/decoder. I have pushed some test application to a git repository at [1]. It can be used for JPEG files encoding/decoding with the mainline s5p-jpeg driver. A v4l2-jpeg-codec-test directory should appear there within few hours. [1] http://git.infradead.org/users/kmpark/public-apps/tree/refs/heads/master Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
On Wed, Jan 08, 2014 at 11:43:29AM -0800, Doug Anderson wrote: Olof came up with the idea that you could update the RW firmware (affects initial boot) and then cache away the value and restore it in the kernel after resume. That would still require a kernel patch but perhaps a less objectionable one. ...of course if writing this register is a problem in secure mode then maybe that patch would be NAKed anyway. It's not a problem in secure mode, since secure mode will have access to the register. It's the non-secure mode where various registers either ignore writes, or they trigger an exception that are the problem. Consider what would happen if an exception were to be triggered when no exception handlers were installed (eg, because the MMU is not enabled.) That's one I didn't think about, you're right. ...but we're really getting into hypothetical situations here. Are there any r2p0 products that have such a fix (and thus require a latency of = 4)? Really, we can't know, because this kind of information is dependent on the SoC, and probably such customisations are only knowable via NDAs. However, I do know of some A9 CPUs where exactly this kind of thing has happened - where various selected silicon bugs have been fixed but the revision still reports the same as one with all those bugs. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
On Wed, 8 Jan 2014, Doug Anderson wrote: Hi, On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux No, we're saying to put the work-around in the boot loader, not the kernel. Unfortunately the resume path of the firmware runs from Read Only firmware code (yes, it sucks), so it's not totally trivial to fix. It would be possible for someone to unscrew their write protect switch and update their RO firmware, but that doesn't help the average user. [...] I'd guess that the way forward is: * Land kernel workaround locally in Chromium tree * I'll try to land FW change locally in at least one Chromium branch. If we were to get a new RO build ever (seems unlikely at this point) it would be fixed for upstream kernels. If we were to get a new RW build (seems unlikely, but at least less unlikely) it would be fixed if someone landed a kernel patch to save/restore this register across suspend/resume. * If Joe Upstream wants to run an upstream kernel on some type of exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 are the ones I know of) then he will deal with the small number of crashes or figure out a solution. If Joe Upstream wants to run an upstream kernel, doesn't he have to unscrew his write protect switch first, at which point the RO firmware can be updated as well? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
On Wed, 8 Jan 2014, Doug Anderson wrote: On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: We've been through these arguments many times, you're not the first to raise it, and we've decided upon the policy. We want as _few_ work- arounds in the kernel as possible, because applying the work-arounds is very problematical with the mixture of secure and non-secure booting. OK, fair enough. If we want no workaround here then we can drop this patch. I'd guess that the way forward is: * Land kernel workaround locally in Chromium tree * I'll try to land FW change locally in at least one Chromium branch. If we were to get a new RO build ever (seems unlikely at this point) it would be fixed for upstream kernels. If we were to get a new RW build (seems unlikely, but at least less unlikely) it would be fixed if someone landed a kernel patch to save/restore this register across suspend/resume. * If Joe Upstream wants to run an upstream kernel on some type of exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 are the ones I know of) then he will deal with the small number of crashes or figure out a solution. At some point you have to realize that what you're proposing is not viable when taking into account the bigger picture. And your FW architecture is to blame. If you were running Windows instead of Linux I bet you'd have found a way to fix things differently than asking Microsoft to add a special quirk in their code. In the PC world you are required to perform a BIOS update instead. So you really need to provision the ability to update at least a portion of the firmware that is not read-only. That may be a third-stage bootloader or the like which purpose is only to install workarounds such as this before executing the kernel and which doesn't need to be updated with the kernel. And in theory you should be able to do that on top of your current RO firmware. Errata workarounds are often machine specific and they can be applied only in special conditions the kernel might not safely know about until it is too late. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-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: Add Arm Erratum 773769 for Large data RAM latency.
Nicolas, On Wed, Jan 8, 2014 at 12:58 PM, Nicolas Pitre n...@fluxnic.net wrote: On Wed, 8 Jan 2014, Doug Anderson wrote: On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: We've been through these arguments many times, you're not the first to raise it, and we've decided upon the policy. We want as _few_ work- arounds in the kernel as possible, because applying the work-arounds is very problematical with the mixture of secure and non-secure booting. OK, fair enough. If we want no workaround here then we can drop this patch. I'd guess that the way forward is: * Land kernel workaround locally in Chromium tree * I'll try to land FW change locally in at least one Chromium branch. If we were to get a new RO build ever (seems unlikely at this point) it would be fixed for upstream kernels. If we were to get a new RW build (seems unlikely, but at least less unlikely) it would be fixed if someone landed a kernel patch to save/restore this register across suspend/resume. * If Joe Upstream wants to run an upstream kernel on some type of exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 are the ones I know of) then he will deal with the small number of crashes or figure out a solution. At some point you have to realize that what you're proposing is not viable when taking into account the bigger picture. And your FW architecture is to blame. If you were running Windows instead of Linux I bet you'd have found a way to fix things differently than asking Microsoft to add a special quirk in their code. In the PC world you are required to perform a BIOS update instead. Yup, I can believe that. ...I'm merely trying to report reality. Firmware updates (even RW ones) require an extra level of scrutiny / testing and a chunk of in-house resources. Those resources get allocated if there is no other choice, but I can't force a lot of people to spend a lot of time to approve a RW firmware update (actually approving = 3 RW firmware updates since there are at least three different 5250 variants) when there is a simple and low risk kernel fix for it. I could try, but I'll get slapped down / laughed at. If this were the Windows/x86 world and we had no choice the decision would go a different way. ...but we're not in the Windows/x86 world. So you really need to provision the ability to update at least a portion of the firmware that is not read-only. That may be a third-stage bootloader or the like which purpose is only to install workarounds such as this before executing the kernel and which doesn't need to be updated with the kernel. And in theory you should be able to do that on top of your current RO firmware. The fact that we have too much code in RO is a known issue and people are definitely working on that. It has already bitten us. It's unlikely that someone will try retrofit something to work on existing devices, though. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.
Russell, On Wed, Jan 8, 2014 at 1:02 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jan 08, 2014 at 11:43:29AM -0800, Doug Anderson wrote: Olof came up with the idea that you could update the RW firmware (affects initial boot) and then cache away the value and restore it in the kernel after resume. That would still require a kernel patch but perhaps a less objectionable one. ...of course if writing this register is a problem in secure mode then maybe that patch would be NAKed anyway. It's not a problem in secure mode, since secure mode will have access to the register. It's the non-secure mode where various registers either ignore writes, or they trigger an exception that are the problem. Consider what would happen if an exception were to be triggered when no exception handlers were installed (eg, because the MMU is not enabled.) OK, good to know. ...so if someone wanted to code up this patch and send upstream they would be able to. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.
Nicolas, On Wed, Jan 8, 2014 at 1:08 PM, Nicolas Pitre n...@fluxnic.net wrote: On Wed, 8 Jan 2014, Doug Anderson wrote: Hi, On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux No, we're saying to put the work-around in the boot loader, not the kernel. Unfortunately the resume path of the firmware runs from Read Only firmware code (yes, it sucks), so it's not totally trivial to fix. It would be possible for someone to unscrew their write protect switch and update their RO firmware, but that doesn't help the average user. [...] I'd guess that the way forward is: * Land kernel workaround locally in Chromium tree * I'll try to land FW change locally in at least one Chromium branch. If we were to get a new RO build ever (seems unlikely at this point) it would be fixed for upstream kernels. If we were to get a new RW build (seems unlikely, but at least less unlikely) it would be fixed if someone landed a kernel patch to save/restore this register across suspend/resume. * If Joe Upstream wants to run an upstream kernel on some type of exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10 are the ones I know of) then he will deal with the small number of crashes or figure out a solution. If Joe Upstream wants to run an upstream kernel, doesn't he have to unscrew his write protect switch first, at which point the RO firmware can be updated as well? Actually, no. You can move your device into dev mode and run any kernel you want. You'll get an annoying you're in dev mode screen at every bootup, but otherwise it works just fine. Going into dev mode requires some special keystrokes at bootup and a wipe of your hard disk but no screwdrivers. -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 v2 0/8] clk: max77686: Clock provider implementation fixes
On Wednesday 08 of January 2014 13:54:32 Mike Turquette wrote: Quoting Tomasz Figa (2014-01-08 10:04:57) On Wednesday 08 of January 2014 09:59:39 Mike Turquette wrote: Quoting Lee Jones (2014-01-08 09:15:44) I believe Lee has already applied this one, but in future, to avoid such confusion, if it's more convenient for you, I can send you any clock series as pull requests. Me? I haven't applied any clk patches. I have taken patches 1-7 into clk-next just now. Thanks. I can take patch #8 as well but it would probably be better to send it through arm-soc? Hmm, patch 8 is trivial enough to not cause any merge conflicts, but since it's unlikely that any users depending on introduced changes will show up for 3.14 it shouldn't really matter which tree it goes through... In the absence of any strong opinion on the topic I have taken patch #8 into clk-next for 3.14. Great, thanks. 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
Question about samsung exynos driver
Hi, I am looking at the source code for samsung exynos driver in here: https://android.googlesource.com/kernel/exynos/+/android-exynos-3.4/drivers/media/video/exynos/jpeg/jpeg_enc.c# What I don't understand it while it advertise it can support multiple plane format (set V4L2_CAP_VIDEO_OUTPUT_MPLANE in querycap(): cap-capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_VIDEO_CAPTURE_MPLANE | V4L2_CAP_VIDEO_OUTPUT_MPLANE; but all the formats in struct jpeg_fmt formats[] has memplanes equals 1. My question when will be the multiple plane functionality being utilized? Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-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] Samsung Clock changes for v3.14
On Wednesday 08 of January 2014 14:07:49 Mike Turquette wrote: Quoting Tomasz Figa (2014-01-08 11:13:38) Hi Mike, Please consider pulling following Samsung Clock changes for v3.14. The following changes since commit 2bb00c68e094271b79deac993893461cc051b721: Hi Tomasz, Commit 2bb00c68 is the tip of the Samsung clk fixes that I'm about to send out. Can you rebase this request onto the tip of clk-next? I guess I can do it, but wouldn't this introduce merge conflicts, since some of the fixes are changing the same parts of the code? I based my samsung-next branch on top of your clk-next with my fixes branch merged, since that's what will end up in Linus' tree anyway. Was it not the right thing to do? Best regards, Tomasz Thanks! Mike Merge branch 'samsung-fixes' into samsung-next-base (2013-12-30 18:15:23 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.14/samsung-clk for you to fetch changes up to 59d711e9ddd2f68822a2a99fc939e11a9288b73e: ARM: dts: exynos5420: add input clocks to audss clock controller (2014-01-08 18:02:43 +0100) (A bit late) first round of Samsung clock patches for v3.14. Andrew Bresticker (7): clk: exynos5250: register APLL rate table clk: exynos-audss: convert to platform device clk: exynos-audss: allow input clocks to be specified in device tree clk: exynos5250: add clock ID for div_pcm0 ARM: dts: exynos5250: add input clocks to audss clock controller clk: exynos-audss: add support for Exynos 5420 ARM: dts: exynos5420: add input clocks to audss clock controller Andrzej Hajda (8): ARM: exynos4: create a DT header defining CLK IDs clk: exynos4: replace clock ID private enums with IDs from DT header ARM: exynos5250: create a DT header defining CLK IDs clk: exynos5250: replace clock ID private enums with IDs from DT header ARM: exynos5420: create a DT header defining CLK IDs clk: exynos5420: replace clock ID private enums with IDs from DT header ARM: exynos5440: create a DT header defining CLK IDs clk: exynos5440: replace clock ID private enums with IDs from DT header Sachin Kamat (1): clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll Tomasz Figa (7): clk: samsung: exynos5250: Sort definitions by registers and bitfield clk: samsung: exynos5250: Make names of mux and div clocks consistent clk: samsung: exynos5250: Fix parents of gate clocks from GSCL domain clk: samsung: exynos5250: Fix parent of gate clocks from DISP1 domain clk: samsung: exynos5250: Add missing unpopulated mux parents clk: samsung: exynos5250: Correct parent list of audio muxes clk: samsung: exynos5250: Fix parents of gate clocks from MFC domain .../devicetree/bindings/clock/clk-exynos-audss.txt | 39 +- .../devicetree/bindings/clock/exynos5250-clock.txt | 1 + arch/arm/boot/dts/exynos5250.dtsi | 2 + arch/arm/boot/dts/exynos5420.dtsi | 4 +- drivers/clk/samsung/clk-exynos-audss.c | 159 +++- drivers/clk/samsung/clk-exynos4.c | 857 ++--- drivers/clk/samsung/clk-exynos5250.c | 699 ++--- drivers/clk/samsung/clk-exynos5420.c | 648 drivers/clk/samsung/clk-exynos5440.c | 81 +- include/dt-bindings/clk/exynos-audss-clk.h | 3 +- include/dt-bindings/clock/exynos4.h| 244 ++ include/dt-bindings/clock/exynos5250.h | 160 include/dt-bindings/clock/exynos5420.h | 188 + include/dt-bindings/clock/exynos5440.h | 42 + 14 files changed, 1957 insertions(+), 1170 deletions(-) create mode 100644 include/dt-bindings/clock/exynos4.h create mode 100644 include/dt-bindings/clock/exynos5250.h create mode 100644 include/dt-bindings/clock/exynos5420.h create mode 100644 include/dt-bindings/clock/exynos5440.h ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung Clock changes for v3.14
Quoting Tomasz Figa (2014-01-08 14:43:24) On Wednesday 08 of January 2014 14:07:49 Mike Turquette wrote: Quoting Tomasz Figa (2014-01-08 11:13:38) Hi Mike, Please consider pulling following Samsung Clock changes for v3.14. The following changes since commit 2bb00c68e094271b79deac993893461cc051b721: Hi Tomasz, Commit 2bb00c68 is the tip of the Samsung clk fixes that I'm about to send out. Can you rebase this request onto the tip of clk-next? I guess I can do it, but wouldn't this introduce merge conflicts, since some of the fixes are changing the same parts of the code? Yes it will cause conflicts, but that is sometimes OK. I based my samsung-next branch on top of your clk-next with my fixes branch merged, since that's what will end up in Linus' tree anyway. Was it not the right thing to do? Well maybe I am missing something, but I think it is not the best thing. The problem is that those patches will sort of be merged twice. Again maybe I am missing something. The same commit IDs will be used so perhaps it is OK... Part of this trouble is caused by the simple way that I fork clk-next from v3.xx-rc1. Since I never rebase that branch to a more recent -rc then there is a delta between the fixes that go in the queue of patches for the next merge window. I guess one way that other subsystems handle this is by having something like clk-next-late which is a new branch based on a later -rc. How awful is the merge conflict resolution? Regards, Mike Best regards, Tomasz Thanks! Mike Merge branch 'samsung-fixes' into samsung-next-base (2013-12-30 18:15:23 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.14/samsung-clk for you to fetch changes up to 59d711e9ddd2f68822a2a99fc939e11a9288b73e: ARM: dts: exynos5420: add input clocks to audss clock controller (2014-01-08 18:02:43 +0100) (A bit late) first round of Samsung clock patches for v3.14. Andrew Bresticker (7): clk: exynos5250: register APLL rate table clk: exynos-audss: convert to platform device clk: exynos-audss: allow input clocks to be specified in device tree clk: exynos5250: add clock ID for div_pcm0 ARM: dts: exynos5250: add input clocks to audss clock controller clk: exynos-audss: add support for Exynos 5420 ARM: dts: exynos5420: add input clocks to audss clock controller Andrzej Hajda (8): ARM: exynos4: create a DT header defining CLK IDs clk: exynos4: replace clock ID private enums with IDs from DT header ARM: exynos5250: create a DT header defining CLK IDs clk: exynos5250: replace clock ID private enums with IDs from DT header ARM: exynos5420: create a DT header defining CLK IDs clk: exynos5420: replace clock ID private enums with IDs from DT header ARM: exynos5440: create a DT header defining CLK IDs clk: exynos5440: replace clock ID private enums with IDs from DT header Sachin Kamat (1): clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll Tomasz Figa (7): clk: samsung: exynos5250: Sort definitions by registers and bitfield clk: samsung: exynos5250: Make names of mux and div clocks consistent clk: samsung: exynos5250: Fix parents of gate clocks from GSCL domain clk: samsung: exynos5250: Fix parent of gate clocks from DISP1 domain clk: samsung: exynos5250: Add missing unpopulated mux parents clk: samsung: exynos5250: Correct parent list of audio muxes clk: samsung: exynos5250: Fix parents of gate clocks from MFC domain .../devicetree/bindings/clock/clk-exynos-audss.txt | 39 +- .../devicetree/bindings/clock/exynos5250-clock.txt | 1 + arch/arm/boot/dts/exynos5250.dtsi | 2 + arch/arm/boot/dts/exynos5420.dtsi | 4 +- drivers/clk/samsung/clk-exynos-audss.c | 159 +++- drivers/clk/samsung/clk-exynos4.c | 857 ++--- drivers/clk/samsung/clk-exynos5250.c | 699 ++--- drivers/clk/samsung/clk-exynos5420.c | 648 drivers/clk/samsung/clk-exynos5440.c | 81 +- include/dt-bindings/clk/exynos-audss-clk.h | 3 +- include/dt-bindings/clock/exynos4.h| 244 ++ include/dt-bindings/clock/exynos5250.h | 160 include/dt-bindings/clock/exynos5420.h | 188 + include/dt-bindings/clock/exynos5440.h | 42 + 14 files changed, 1957 insertions(+), 1170 deletions(-) create mode 100644
Re: [GIT PULL] Samsung Clock changes for v3.14
Quoting Mike Turquette (2014-01-08 14:59:43) Quoting Tomasz Figa (2014-01-08 14:43:24) On Wednesday 08 of January 2014 14:07:49 Mike Turquette wrote: Quoting Tomasz Figa (2014-01-08 11:13:38) Hi Mike, Please consider pulling following Samsung Clock changes for v3.14. The following changes since commit 2bb00c68e094271b79deac993893461cc051b721: Hi Tomasz, Commit 2bb00c68 is the tip of the Samsung clk fixes that I'm about to send out. Can you rebase this request onto the tip of clk-next? I guess I can do it, but wouldn't this introduce merge conflicts, since some of the fixes are changing the same parts of the code? Yes it will cause conflicts, but that is sometimes OK. I based my samsung-next branch on top of your clk-next with my fixes branch merged, since that's what will end up in Linus' tree anyway. Was it not the right thing to do? Well maybe I am missing something, but I think it is not the best thing. The problem is that those patches will sort of be merged twice. Again maybe I am missing something. The same commit IDs will be used so perhaps it is OK... Part of this trouble is caused by the simple way that I fork clk-next from v3.xx-rc1. Since I never rebase that branch to a more recent -rc then there is a delta between the fixes that go in the queue of patches for the next merge window. I guess one way that other subsystems handle this is by having something like clk-next-late which is a new branch based on a later -rc. How awful is the merge conflict resolution? Thanks for working this out on IRC. I've taken this pull request into clk-next for 3.14. Regards, Mike Regards, Mike Best regards, Tomasz Thanks! Mike Merge branch 'samsung-fixes' into samsung-next-base (2013-12-30 18:15:23 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.14/samsung-clk for you to fetch changes up to 59d711e9ddd2f68822a2a99fc939e11a9288b73e: ARM: dts: exynos5420: add input clocks to audss clock controller (2014-01-08 18:02:43 +0100) (A bit late) first round of Samsung clock patches for v3.14. Andrew Bresticker (7): clk: exynos5250: register APLL rate table clk: exynos-audss: convert to platform device clk: exynos-audss: allow input clocks to be specified in device tree clk: exynos5250: add clock ID for div_pcm0 ARM: dts: exynos5250: add input clocks to audss clock controller clk: exynos-audss: add support for Exynos 5420 ARM: dts: exynos5420: add input clocks to audss clock controller Andrzej Hajda (8): ARM: exynos4: create a DT header defining CLK IDs clk: exynos4: replace clock ID private enums with IDs from DT header ARM: exynos5250: create a DT header defining CLK IDs clk: exynos5250: replace clock ID private enums with IDs from DT header ARM: exynos5420: create a DT header defining CLK IDs clk: exynos5420: replace clock ID private enums with IDs from DT header ARM: exynos5440: create a DT header defining CLK IDs clk: exynos5440: replace clock ID private enums with IDs from DT header Sachin Kamat (1): clk: exynos5250: Add CLK_SET_RATE_PARENT flag to mout_apll Tomasz Figa (7): clk: samsung: exynos5250: Sort definitions by registers and bitfield clk: samsung: exynos5250: Make names of mux and div clocks consistent clk: samsung: exynos5250: Fix parents of gate clocks from GSCL domain clk: samsung: exynos5250: Fix parent of gate clocks from DISP1 domain clk: samsung: exynos5250: Add missing unpopulated mux parents clk: samsung: exynos5250: Correct parent list of audio muxes clk: samsung: exynos5250: Fix parents of gate clocks from MFC domain .../devicetree/bindings/clock/clk-exynos-audss.txt | 39 +- .../devicetree/bindings/clock/exynos5250-clock.txt | 1 + arch/arm/boot/dts/exynos5250.dtsi | 2 + arch/arm/boot/dts/exynos5420.dtsi | 4 +- drivers/clk/samsung/clk-exynos-audss.c | 159 +++- drivers/clk/samsung/clk-exynos4.c | 857 ++--- drivers/clk/samsung/clk-exynos5250.c | 699 ++--- drivers/clk/samsung/clk-exynos5420.c | 648 drivers/clk/samsung/clk-exynos5440.c | 81 +- include/dt-bindings/clk/exynos-audss-clk.h | 3 +- include/dt-bindings/clock/exynos4.h|
[PATCH v5 1/4] [media] exynos-scaler: Add new driver for Exynos5 SCALER
This patch adds support for SCALER device which is a new device
for scaling, blending, color fill and color space conversion
on EXYNOS5410 and EXYNOS5420 SoCs.
This device supports the followings as key feature.
input image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB, L8A8 and L8
output image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB
input rotation
- 0/90/180/270 degree, X/Y/XY Flip
scale ratio
- 1/4 scale down to 16 scale up
color space conversion
- RGB to YUV / YUV to RGB
Size - Exynos5420
- Input : 16x16 to 8192x8192
- Output: 4x4 to 8192x8192
Size - Exynos5410
- Input/Output: 4x4 to 4096x4096
alpha blending, color fill
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos-scaler/scaler-regs.c | 337
drivers/media/platform/exynos-scaler/scaler-regs.h | 331 +++
2 files changed, 668 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c
create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h
diff --git a/drivers/media/platform/exynos-scaler/scaler-regs.c
b/drivers/media/platform/exynos-scaler/scaler-regs.c
new file mode 100644
index 000..8f5076a
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-regs.c
@@ -0,0 +1,337 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/platform_device.h
+
+#include scaler-regs.h
+
+/* Scaler reset timeout in milliseconds */
+#define SCALER_RESET_TIMEOUT 5
+
+void scaler_hw_set_sw_reset(struct scaler_dev *dev)
+{
+ u32 cfg;
+
+ cfg = scaler_read(dev, SCALER_CFG);
+ cfg |= SCALER_CFG_SOFT_RESET;
+
+ scaler_write(dev, SCALER_CFG, cfg);
+}
+
+int scaler_wait_reset(struct scaler_dev *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
+ u32 cfg, reset_done = 0;
+
+ while (time_is_after_jiffies(end)) {
+ cfg = scaler_read(dev, SCALER_CFG);
+ if (!(cfg SCALER_CFG_SOFT_RESET)) {
+ reset_done = 1;
+ break;
+ }
+ usleep_range(100, 200);
+ }
+
+ if (!reset_done)
+ return -EBUSY;
+
+ /*
+* Write any value to read/write register and read it back.
+* If the write and read value matches, then the reset process is
+* succeeded.
+*/
+ end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
+ while (time_is_after_jiffies(end)) {
+ scaler_write(dev, SCALER_CFG_SOFT_RESET_CHECK_REG,
+ SCALER_CFG_SOFT_RESET_CHECK_VAL);
+ if (SCALER_CFG_SOFT_RESET_CHECK_VAL ==
+ scaler_read(dev, SCALER_CFG_SOFT_RESET_CHECK_REG))
+ return 0;
+ usleep_range(9000, 1);
+ }
+
+ return -EBUSY;
+}
+
+void scaler_hw_set_irq(struct scaler_dev *dev, int irq_num, bool enable)
+{
+ u32 cfg;
+
+ if ((irq_num SCALER_INT_FRAME_END) ||
+ (irq_num SCALER_INT_TIMEOUT))
+ return;
+
+ cfg = scaler_read(dev, SCALER_INT_EN);
+ if (enable)
+ cfg |= 1 irq_num;
+ else
+ cfg = ~(1 irq_num);
+ scaler_write(dev, SCALER_INT_EN, cfg);
+}
+
+void scaler_hw_set_input_addr(struct scaler_dev *dev, struct scaler_addr *addr)
+{
+ scaler_dbg(dev, src_buf: 0x%x, cb: 0x%x, cr: 0x%x,
+ addr-y, addr-cb, addr-cr);
+ scaler_write(dev, SCALER_SRC_Y_BASE, addr-y);
+ scaler_write(dev, SCALER_SRC_CB_BASE, addr-cb);
+ scaler_write(dev, SCALER_SRC_CR_BASE, addr-cr);
+}
+
+void scaler_hw_set_output_addr(struct scaler_dev *dev,
+struct scaler_addr *addr)
+{
+ scaler_dbg(dev, dst_buf: 0x%x, cb: 0x%x, cr: 0x%x,
+ addr-y, addr-cb, addr-cr);
+ scaler_write(dev, SCALER_DST_Y_BASE, addr-y);
+ scaler_write(dev, SCALER_DST_CB_BASE, addr-cb);
+ scaler_write(dev, SCALER_DST_CR_BASE, addr-cr);
+}
+
+void scaler_hw_set_in_size(struct scaler_ctx *ctx)
+{
+ struct scaler_dev *dev = ctx-scaler_dev;
+ struct scaler_frame
[PATCH v5 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver
This patch adds the DT binding documentation for the
Exynos5420/5410 based SCALER device driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/media/exynos5-scaler.txt | 22
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt
b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
new file mode 100644
index 000..9328e7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
@@ -0,0 +1,22 @@
+* Samsung Exynos5 SCALER device
+
+SCALER is used for scaling, blending, color fill and color space
+conversion on EXYNOS[5420/5410] SoCs.
+
+Required properties:
+- compatible: should be samsung,exynos5420-scaler or
+ samsung,exynos5410-scaler
+- reg: should contain SCALER physical address location and length
+- interrupts: should contain SCALER interrupt number
+- clocks: should contain the SCALER clock specifier, from the
+ common clock bindings
+- clock-names: should be scaler
+
+Example:
+ scaler_0: scaler@1280 {
+ compatible = samsung,exynos5420-scaler;
+ reg = 0x1280 0x1000;
+ interrupts = 0 220 0;
+ clocks = clock 381;
+ clock-names = scaler;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver
This patch adds the core functionality for the SCALER driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos-scaler/scaler.c | 1231 +
drivers/media/platform/exynos-scaler/scaler.h | 376
2 files changed, 1607 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
create mode 100644 drivers/media/platform/exynos-scaler/scaler.h
diff --git a/drivers/media/platform/exynos-scaler/scaler.c
b/drivers/media/platform/exynos-scaler/scaler.c
new file mode 100644
index 000..db2cad1
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler.c
@@ -0,0 +1,1231 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+
+#include scaler-regs.h
+
+#define SCALER_CLOCK_GATE_NAME scaler
+
+static const struct scaler_fmt scaler_formats[] = {
+ {
+ .name = YUV 4:2:0 non-contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12M,
+ .depth = { 8, 4 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+
+ }, {
+ .name = YUV 4:2:0 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12,
+ .depth = { 12 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = YUV 4:2:0 n.c. 2p, Y/CbCr tiled,
+ .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+ .depth = { 8, 4 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_TILED,
+ }, {
+ .name = YUV 4:2:2 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV16,
+ .depth = { 16 },
+ .color = SCALER_YUV422,
+ .color_order= SCALER_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV422_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = YUV 4:4:4 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV24,
+ .depth = { 24 },
+ .color = SCALER_YUV444,
+ .color_order= SCALER_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV444_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565X,
+ .depth = { 16 },
+ .color = SCALER_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .scaler_color = SCALER_RGB565,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = XRGB-1555, 16 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB555,
+ .depth = { 16 },
+ .color = SCALER_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .scaler_color = SCALER_ARGB1555,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = XRGB-, 32 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+ .depth = { 32 },
+ .color = SCALER_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .scaler_color = SCALER_ARGB,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .pixelformat= V4L2_PIX_FMT_YVYU,
[PATCH v5 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver
This patch adds the Makefile and memory to memory (m2m) interface
functionality for the SCALER driver.
[arun...@samsung.com: fix compilation issues]
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/Kconfig|8 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/exynos-scaler/Makefile |3 +
drivers/media/platform/exynos-scaler/scaler-m2m.c | 788 +
4 files changed, 800 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/Makefile
create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index b2a4403..aec5b80 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -196,6 +196,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
+config VIDEO_SAMSUNG_EXYNOS_SCALER
+ tristate Samsung Exynos SCALER driver
+ depends on OF VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
+
config VIDEO_SH_VEU
tristate SuperH VEU mem2mem video processing driver
depends on VIDEO_DEV VIDEO_V4L2 HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index e5269da..0f774ba 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler/
obj-$(CONFIG_BLACKFIN) += blackfin/
diff --git a/drivers/media/platform/exynos-scaler/Makefile
b/drivers/media/platform/exynos-scaler/Makefile
new file mode 100644
index 000..6c8a25b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/Makefile
@@ -0,0 +1,3 @@
+exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler.o
diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
b/drivers/media/platform/exynos-scaler/scaler-m2m.c
new file mode 100644
index 000..892b93b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
@@ -0,0 +1,788 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include scaler-regs.h
+
+#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
+#define SCALER_DEF_WIDTH 1280
+#define SCALER_DEF_HEIGHT 720
+
+static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
+{
+ struct scaler_ctx *curr_ctx;
+ struct scaler_dev *scaler = ctx-scaler_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(scaler-m2m.m2m_dev);
+ if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
+ return 0;
+
+ scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(scaler-irq_queue,
+ !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
+ SCALER_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct scaler_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-scaler_dev-pdev-dev);
+
+ return ret 0 ? 0 : ret;
+}
+
+static int scaler_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct scaler_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = scaler_m2m_ctx_stop_req(ctx);
+ if (ret 0)
+ scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-scaler_dev-pdev-dev);
+
+ return 0;
+}
+
+void scaler_m2m_job_finish(struct scaler_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-scaler_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+static void scaler_m2m_job_abort(void
Re: [PATCH 5/5] ARM: exynos5420: add dt node for sss module
Hello Tomasz,
On 8 January 2014 06:02, Tomasz Figa tomasz.f...@gmail.com wrote:
On Tuesday 07 of January 2014 17:21:49 Naveen Krishna Ch wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
this patch adds the device tree nodes for SSS module found on Exynos5420
nit: Sentences in English start with a capital letter. Also this patch
adds one node, not few of them as the description suggests.
Also patch subject should start with ARM: dts: prefix.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
TO: linux-samsung-soc@vger.kernel.org
CC: Kukjin Kim kgene@samsung.com
CC: linux-cry...@vger.kernel.org
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..97045f9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = clock 319, clock 318;
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+
+ sss: sss {
Node name should be sss@1083 as per ePAPR node naming recommendation.
Thanks for the correction, Will correct it and submit. Thanks
Best regards,
Tomasz
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-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 4/5] crypto:s5p-sss: Exynos5 SoCs too can select SSS driver
Hello Tomasz, On 8 January 2014 06:00, Tomasz Figa tomasz.f...@gmail.com wrote: On Tuesday 07 of January 2014 17:21:48 Naveen Krishna Ch wrote: This patch modifies Kconfig such that ARCH_EXYNOS5 SoCs can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com CC: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC: Vladimir Zapolskiy vzapols...@gmail.com TO: linux-cry...@vger.kernel.org CC: linux-samsung-soc@vger.kernel.org --- drivers/crypto/Kconfig |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index f4fd837..137dcd8 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP capabilities of the DCP co-processor config CRYPTO_DEV_S5P - tristate Support for Samsung S5PV210 crypto accelerator - depends on ARCH_S5PV210 + tristate Support for Samsung crypto accelerator + depends on ARCH_S5PV210 || ARCH_EXYNOS5 select CRYPTO_AES select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. - Select this to offload Samsung S5PV210 or S5PC110 from AES - algorithms execution. + Select this to offload Samsung S5PV210 or S5PC110, Exynos5250 + and Exynos5420 from AES algorithms execution. What about Exynos4 SoCs? The SSS module as such looks alike on Exynos5250, Exynso5420 and Exynos4210. I couldn't test it right now. I should also verify on other Exynos4 SoCs. Best regards, Tomasz -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line unsubscribe linux-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/6 v2] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource 0 and hash interrupt as 1.
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v1:
A typo fixed, from err pdata-irq_hash; to pdata-irq_fc;
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..93cddeb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata-ioaddr = devm_ioremap(dev, res-start,
resource_size(res));
- pdata-irq_hash = platform_get_irq_byname(pdev, hash);
- if (pdata-irq_hash 0) {
- err = pdata-irq_hash;
- dev_warn(dev, hash interrupt is not available.\n);
+ pdata-irq_fc = platform_get_irq(pdev, 0);
+ if (pdata-irq_fc 0) {
+ err = pdata-irq_fc;
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, hash interrupt is not available.\n);
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- pdata-irq_fc = platform_get_irq_byname(pdev, feed control);
- if (pdata-irq_fc 0) {
- err = pdata-irq_fc;
- dev_warn(dev, feed control interrupt is not available.\n);
+ pdata-irq_hash = platform_get_irq(pdev, 1);
+ if (pdata-irq_hash 0) {
+ err = pdata-irq_hash;
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, feed control interrupt is not available.\n);
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6 v2] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
From: Naveen Krishna Ch ch.nav...@samsung.com This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com CC: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC: Vladimir Zapolskiy vzapols...@gmail.com TO: linux-cry...@vger.kernel.org CC: linux-samsung-soc@vger.kernel.org --- Changes since v1: SSS module on Exynos4210 and Exynos5250, Exynso5420 are alike hence, modifying the Kconfig to select the s5p-sss.c driver for all SoCs supporting ARCH_EXYNOS drivers/crypto/Kconfig |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index f4fd837..193e8b1 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP capabilities of the DCP co-processor config CRYPTO_DEV_S5P - tristate Support for Samsung S5PV210 crypto accelerator - depends on ARCH_S5PV210 + tristate Support for Samsung crypto accelerator + depends on ARCH_S5PV210 || ARCH_EXYNOS select CRYPTO_AES select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. - Select this to offload Samsung S5PV210 or S5PC110 from AES - algorithms execution. + Select this to offload Samsung S5PV210 or S5PC110, Exynos4210, + Exynos5250 and Exynos5420 from AES algorithms execution. config CRYPTO_DEV_TEGRA_AES tristate Support for TEGRA AES hw engine -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6 v2] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Implements a varient struct to address the changes in SSS hardware
on various SoCs from Samsung.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v1:
1. Added description of the SSS module in Documentation
2. Corrected the interrupts description
3. Added varient struct instead of the version variable
.../devicetree/bindings/crypto/samsung-sss.txt | 20 +
drivers/crypto/s5p-sss.c | 81 ++--
2 files changed, 95 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..0e45b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - samsung,s5p-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts feed control and hash in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..78e0c37 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -145,6 +146,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_varient - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_varient {
+ boolhas_hash_irq;
+ unsigned intaes_offset;
+};
+
struct s5p_aes_reqctx {
unsigned long mode;
};
@@ -173,10 +188,56 @@ struct s5p_aes_dev {
struct crypto_queue queue;
boolbusy;
spinlock_t lock;
+
+ struct samsung_aes_varient *varient;
};
static struct s5p_aes_dev *s5p_dev;
+static struct samsung_aes_varient s5p_aes_data = {
+ .has_hash_irq = true,
+ .aes_offset = 0x4000,
+};
+
+static const struct platform_device_id s5p_sss_ids[] = {
+ {
+ .name = s5p-secss,
+ .driver_data= (kernel_ulong_t)s5p_aes_data,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
+
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_sss_dt_match[] = {
+ {
+ .compatible = samsung,s5p-secss,
+ .data = (void *)s5p_aes_data,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+#else
+static struct of_device_id s5p_sss_dt_match[] = {
+ { },
+};
+#endif
+
+static inline struct samsung_aes_varient *find_s5p_sss_version
+ (struct platform_device *pdev)
+{
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(s5p_sss_dt_match,
+ pdev-dev.of_node);
+ return (struct samsung_aes_varient *)match-data;
+ }
+ }
+ return (struct samsung_aes_varient *)
+ platform_get_device_id(pdev)-driver_data;
+}
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -564,6 +625,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
struct s5p_aes_dev *pdata;
struct device *dev = pdev-dev;
struct resource*res;
+ struct samsung_aes_varient *varient;
if (s5p_dev)
return
[PATCH 5/6 v2] ARM: dts: exynos5420: add dt node for sss module
This patch adds the device tree node for SSS module
found on Exynos5420
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
TO: linux-samsung-soc@vger.kernel.org
CC: Kukjin Kim kgene@samsung.com
CC: linux-cry...@vger.kernel.org
---
Changes since v1:
Modified dt node name from sss to sss@1083
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..0b27902 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = clock 319, clock 318;
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+
+ sss@1083 {
+ compatible = samsung,exynos-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 471;
+ clock-names = secss;
+ samsung,power-domain = g2d_pd;
+ };
+
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6 v2] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate iv buffer before trying to memcpy the contents Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- Changes since v1: None drivers/crypto/s5p-sss.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 7c31a5f..220f123 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -398,8 +398,9 @@ static void s5p_set_aes(struct s5p_aes_dev *dev, struct samsung_aes_varient *var = dev-varient; void __iomem *keystart; - memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA - (var-aes_offset, 0), iv, 0x10); + if (iv) + memcpy(dev-ioaddr + SSS_REG_AES_IV_DATA + (var-aes_offset, 0), iv, 0x10); if (keylen == AES_KEYSIZE_256) keystart = dev-ioaddr + -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/9] phy: Add new Exynos USB 2.0 PHY driver
Hi,
On Wednesday 08 January 2014 11:26 PM, Kamil Debski wrote:
Hi,
From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
Sent: Monday, January 06, 2014 11:12 AM
Hi,
On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the
generic PHY framework. The driver includes support for the Exynos
4x10
and 4x12 SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 55
drivers/phy/Kconfig| 29 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos4210-usb2.c | 257
drivers/phy/phy-exynos4212-usb2.c | 306
drivers/phy/phy-samsung-usb2.c | 226
+++
drivers/phy/phy-samsung-usb2.h | 67 +
7 files changed, 943 insertions(+)
create mode 100644 drivers/phy/phy-exynos4210-usb2.c
create mode 100644 drivers/phy/phy-exynos4212-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.h
.
.
snip
.
.
diff --git a/drivers/phy/phy-samsung-usb2.h
b/drivers/phy/phy-samsung-usb2.h new file mode 100644 index
000..ab89f91
--- /dev/null
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -0,0 +1,67 @@
+/*
+ * Samsung SoC USB 1.1/2.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _PHY_EXYNOS_USB2_H
+#define _PHY_EXYNOS_USB2_H
+
+#include linux/clk.h
+#include linux/phy/phy.h
+#include linux/device.h
+#include linux/regmap.h
+#include linux/spinlock.h
+
+#define KHZ 1000
+#define MHZ (KHZ * KHZ)
+
+struct samsung_usb2_phy_driver;
+struct samsung_usb2_phy_instance;
+struct samsung_usb2_phy_config;
+
+struct samsung_usb2_phy_instance {
+ const struct samsung_usb2_common_phy *cfg;
+ struct clk *clk;
+ struct phy *phy;
+ struct samsung_usb2_phy_driver *drv;
+ unsigned long rate;
+ u32 clk_reg_val;
+ bool enabled;
+};
+
+struct samsung_usb2_phy_driver {
+ const struct samsung_usb2_phy_config *cfg;
+ struct clk *clk;
+ struct device *dev;
+ void __iomem *reg_phy;
+ struct regmap *reg_pmu;
+ struct regmap *reg_sys;
+ spinlock_t lock;
+ struct samsung_usb2_phy_instance instances[0];
I think having instances as array here would allocate more space while
allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.
I am not sure if I understand you correctly here. Maybe I will explain
what I intended to write. An array with size 0 at the end of a structure
takes no space in the structure. The benefit of using it is that after
the structure one can allocate a number of the array elements and
address them easily. Another option would be placing pointer in the
samsung_usb2_phy_instance and allocate memory separately, but this would
involve two allocations and a pointer would be always present in the
structure.
Al-right.. makes sense.
Thanks
Kishon
Best wishes,
--
To unsubscribe from this list: send the line unsubscribe linux-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 v12 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, Zhang, On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: Hi Rafael, Hi, This patch series introduces support for CPU overclocking technique called Boost. It is a follow up of a LAB governor proposal. Boost is a LAB component: http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq Boost unifies hardware based solution (e.g. Intel Nehalem) with software oriented one (like the one done at Exynos). For this reason cpufreq/freq_table code has been reorganized to include common code. Important design decisions: - Boost related code is compiled-in unconditionally to cpufreq core and disabled by default. The cpufreq_driver is responsibile for setting boost_supported flag and providing set_boost callback(if HW support is needed). For software managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only when a target platform has thermal framework properly configured. - struct cpufreq_driver has been extended with boost related fields: -- boost_supported - when driver supports boosting -- boost_enabled - boost state -- set_boost - callback to function, which is necessary to enable/disable boost - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is visible _only_ when cpufreq driver supports Boost. - No special spin_lock for Boost was created. The one from cpufreq core was reused. - The Boost code doesn't rely on any policy. When boost state is changed, then the policy list is iterated and proper adjustements are done. - To improve safety level, the thermal framework is also extended to disable software boosting, when thermal trip point is reached. After cooling down the boost can be enabled again. This emulates behaviour similar to HW managed boost (like x86) Tested at HW: Exynos 4412 3.13-rc4 Linux Intel Core i7-3770 3.13-rc4 Linux Above patches were posted on top of kernel_pm/bleeding-edge (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) Lukasz Majewski (7): cpufreq: Add boost frequency support in core cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution cpufreq:boost:Kconfig: Provide support for software managed BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support boost framework Documentation:cpufreq:boost: Update BOOST documentation cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412) Documentation/cpu-freq/boost.txt | 26 +++ drivers/cpufreq/Kconfig |4 + drivers/cpufreq/Kconfig.arm | 15 drivers/cpufreq/acpi-cpufreq.c| 86 +++-- drivers/cpufreq/cpufreq.c | 118 - drivers/cpufreq/exynos-cpufreq.c |3 + drivers/cpufreq/exynos4x12-cpufreq.c |2 +- drivers/cpufreq/freq_table.c | 56 -- drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- include/linux/cpufreq.h | 24 ++ 10 files changed, 261 insertions(+), 85 deletions(-) A gentle ping about BOOST patches. Its been already acked by Viresh and Eduardo. It applies on kernel_pm/bleeding_edge SHA1: 4836deb72c5e2a9af0cb2129c1149783a26d99ab It looks like Rui is still looking into this. Rui, are you fine with this series? I'd really appreciate Ack from Rui on this patch series. However, after Rui's comments on v9, I've completely removed the BOOST code from thermal core. Since the v10, I've only adjusted default data for Exynos SoC. This approach has been finally accepted by Eduardo (who is responsible for this part of the thermal subsystem) on the v12. Rafael -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
