[PATCH v2] irqchip: exynos-combiner: Fix compilation error on ARM64
The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including linux/interrupt.h. Signed-off-by: Naveen Krishna Chatradhi Cc: Thomas Gleixner Cc: Jason Cooper Cc: Sudeep Holla --- Changes since v1: Used linux/interrupt.h instead of asm/hardirq.h drivers/irqchip/exynos-combiner.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index f8636a6..5945223 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include -- 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman wrote: > HI Thomas, > > Thomas Abraham writes: > >> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman wrote: >>> Hi Thomas, >>> >>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: > On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: >> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap >> wrote: > > [...] > Can you clarify how you're setting the voltages to ensure stability? >>> >>> below is the diff : wip/exynos/integ >> >> Thanks. >> >> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at >> 1500mV, but still when booting with cpuidle enabled (bL switcher >> disabled), I'm seeing lockups with no kernel output. With CPUidle >> disabled, things are pretty stable. >> >> What tree are you using to test this out on 5420? I'm using mainline >> v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my >> wip/exynos/integ branch at >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. > > I mis-stated this. Actually my tree is based on the v3.17-rc1 branch > of the exynos-reference tree[1] + the above mentioned patches for > cpuidle and cpufreq. > > Also, I've narrowed down the instability a bit, and it's not related > to CPUidle. I can now trigger a boot hang even without CPUidle > enabled. Here's a quick way to cause a boot lockup. With the switcher > disabled, I enable CPUfreq and set the default governor to > performance. As soon as cpufreq driver loads, it tries to use the top > frequences for both clusters, and it hangs. > > Selectively disabling frequencies, I narrowed it down to the 1.3GHz > and 1.2GHz frequencies of the little cluster. With these commented > out in the DT, it will fully boot with the performance governor > enabled. > > So that leads to the question. Are all of the operating points in > exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. >>> >>> Can you share your branch and temp hack(s) as well as your defconfig? >>> >>> I'm using the v3.17-rc1 branch from the exynos tree (which includes >>> the max77802 series) but also has a bunch of other stuff which may be >>> causing the issue. >>> >>> It would be good if I can reproduce your exact tree/branch and see if >>> I still have the same problem. >> >> The branch with the patches that have been used to test cpufreq on >> Exynos5800 is available at >> >> https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq >> >> Please let me know if this works or if there are any issues. > > Yes, your branch works fine, but it's because of the last (unposted) > patch on your branch[1]: > ARM: dts: remove all supplies sourced from tps65090 PMIC I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary. > > That patch had not been posted, so I hadn't seen it before, but based on > the changelog, it's pretty clear you had the same problems that I had > without it, so I'm not sure why it wasn't mentioned earlier in this > thread. At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier. > > I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch > is not actually using the max voltage, which appears to be 1.5V from the > DT, but actually using 1.35 V, however the changelog has no explanation > for this. This also is a temporary patch and by "max voltage" I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply. > > One other thing, your temp-cpufreq branch has conflicts with max77802 > stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm > using for CPUidle dependencies, on the PMU series IIRC.) I haven't checked but probab
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi wrote: > On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: >> On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: >> > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: >> > >> >> This USB 3.0 PHY controller is also present on Exynos7 >> >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. >> > >> >> +++ b/drivers/phy/Kconfig >> >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 >> >> >> >> config PHY_EXYNOS5_USBDRD >> >> tristate "Exynos5 SoC series USB DRD PHY driver" >> >> - depends on ARCH_EXYNOS5 && OF >> >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF >> > >> > shouldn't that prompt and its help text be updated to mention also Exynos7? >> >> Right, even that has to be updated accordingly. Will update the same in next >> version of the patch. Thanks for pointing this. > > I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like > that idea. The thing is that this will likely need to be patches for > exynos8, 9, 10, 11... Yes, after we have the 2nd version of Exynos7 support patches, it makes more sense to keep dependency on ARCH_EXYNOS. -- Best Regards Vivek Gautam Samsung R&D 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 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
On Fri, Aug 29, 2014 at 12:58 AM, Felipe Balbi wrote: > On Thu, Aug 28, 2014 at 01:31:59PM +0530, Vivek Gautam wrote: >> The Exynos-DWC3 USB 3.0 DRD controller is also present on >> Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 >> for this driver. >> >> Signed-off-by: Vivek Gautam >> --- >> drivers/usb/dwc3/Kconfig |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >> index 785510a..e235894 100644 >> --- a/drivers/usb/dwc3/Kconfig >> +++ b/drivers/usb/dwc3/Kconfig >> @@ -55,7 +55,7 @@ config USB_DWC3_OMAP >> >> config USB_DWC3_EXYNOS >> tristate "Samsung Exynos Platform" >> - depends on ARCH_EXYNOS || COMPILE_TEST >> + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST > > wait when building for ARCH_EXYNOS7 you don't get ARCH_EXYNOS ? Right, we do get it now in V2 patch series for Exynos7 [1], but it wasn't available in the first series [2]. Will drop this patch now. [1] http://www.spinics.net/lists/linux-samsung-soc/msg36378.html [2] http://www.spinics.net/lists/arm-kernel/msg357382.html -- Best Regards Vivek Gautam Samsung R&D 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 v2] mfd: syscon: Decouple syscon interface from platform devices
On Tue, Sep 2, 2014 at 8:12 PM, Pankaj Dubey wrote: > Currently a syscon entity can only be registered directly through a > platform device that binds to a dedicated syscon driver. However in > certain cases it is required to bind a device with it's dedicated > driver rather than binding with syscon driver. > > For example, certain SoCs (e.g. Exynos) contain system controller > blocks which perform various functions such as power domain control, > CPU power management, low power mode control, but in addition contain > certain IP integration glue, such as various signal masks, > coprocessor power control, etc. In such case, there is a need to have > a dedicated driver for such system controller but also share registers > with other drivers. The latter is where the syscon interface is helpful. > > This patch decouples syscon object from syscon platform driver, and > allows to create syscon objects first time when it is required by > calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon > objects along with syscon provider device_nodes and regmap handles. > > Signed-off-by: Pankaj Dubey > Signed-off-by: Tomasz Figa > --- > V1 of this patchset [1] and related discussion can be found here [1]. > > Changes since v1: > - Removed of_syscon_unregister function. > - Modified of_syscon_register function and it will be used by syscon.c >to create syscon objects whenever required. > - Removed platform device support from syscon. > - Removed syscon_regmap_lookup_by_pdevname API support. > - As there are significant changes w.r.t patchset v1, I am taking over >author for this patchset from Tomasz Figa. > > Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname and > will be broken after this patch. As per discussion over here [1], patches > for making these drivers DT based are ready and once that is done they can use > syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible. > > [1]: https://lkml.org/lkml/2014/8/22/81 [snip] Tested on smdk5250 board with 3.17-rc3 for USB 2.0 and USB 3.0, since USB takes syscon phandle for handling some of the pmu registers. Things work fine with all the dt side changes in this patch. Tested-by: Vivek Gautam -- Best Regards Vivek Gautam Samsung R&D 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
[PATCHv6 1/2] thermal: exynos: Add support for many TRIMINFO_CTRL registers
This patch support many TRIMINFO_CTRL registers if specific Exynos SoC has one more TRIMINFO_CTRL registers. Also this patch uses proper 'RELOAD' shift/mask bit operation to set RELOAD feature instead of static value. Signed-off-by: Chanwoo Choi Acked-by: Kyungmin Park Cc: Zhang Rui Cc: Eduardo Valentin Cc: Amit Daniel Kachhap Reviewed-by: Amit Daniel Kachhap --- drivers/thermal/samsung/exynos_thermal_common.h | 1 + drivers/thermal/samsung/exynos_tmu.c| 15 --- drivers/thermal/samsung/exynos_tmu.h| 7 +-- drivers/thermal/samsung/exynos_tmu_data.c | 4 +++- drivers/thermal/samsung/exynos_tmu_data.h | 1 + 5 files changed, 22 insertions(+), 6 deletions(-) diff --git a/drivers/thermal/samsung/exynos_thermal_common.h b/drivers/thermal/samsung/exynos_thermal_common.h index cd44719..158f5aa 100644 --- a/drivers/thermal/samsung/exynos_thermal_common.h +++ b/drivers/thermal/samsung/exynos_thermal_common.h @@ -27,6 +27,7 @@ #define SENSOR_NAME_LEN16 #define MAX_TRIP_COUNT 8 #define MAX_COOLING_DEVICE 4 +#define MAX_TRIMINFO_CTRL_REG 2 #define ACTIVE_INTERVAL 500 #define IDLE_INTERVAL 1 diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c index 35437df..092ab69 100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++ b/drivers/thermal/samsung/exynos_tmu.c @@ -127,7 +127,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) struct exynos_tmu_data *data = platform_get_drvdata(pdev); struct exynos_tmu_platform_data *pdata = data->pdata; const struct exynos_tmu_registers *reg = pdata->registers; - unsigned int status, trim_info = 0, con; + unsigned int status, trim_info = 0, con, ctrl; unsigned int rising_threshold = 0, falling_threshold = 0; int ret = 0, threshold_code, i; @@ -144,8 +144,17 @@ static int exynos_tmu_initialize(struct platform_device *pdev) } } - if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) - __raw_writel(1, data->base + reg->triminfo_ctrl); + if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) { + for (i = 0; i < reg->triminfo_ctrl_count; i++) { + if (pdata->triminfo_reload[i]) { + ctrl = readl(data->base + + reg->triminfo_ctrl[i]); + ctrl |= pdata->triminfo_reload[i]; + writel(ctrl, data->base + + reg->triminfo_ctrl[i]); + } + } + } /* Save trimming info in order to perform calibration */ if (data->soc == SOC_ARCH_EXYNOS5440) { diff --git a/drivers/thermal/samsung/exynos_tmu.h b/drivers/thermal/samsung/exynos_tmu.h index d503f35..f67203b 100644 --- a/drivers/thermal/samsung/exynos_tmu.h +++ b/drivers/thermal/samsung/exynos_tmu.h @@ -78,6 +78,7 @@ enum soc_type { * slightly across different exynos SOC's. * @triminfo_data: register containing 2 pont trimming data * @triminfo_ctrl: trim info controller register. + * @triminfo_ctrl_count: the number of trim info controller register. * @tmu_ctrl: TMU main controller register. * @test_mux_addr_shift: shift bits of test mux address. * @therm_trip_mode_shift: shift bits of tripping mode in tmu_ctrl register. @@ -112,8 +113,8 @@ enum soc_type { struct exynos_tmu_registers { u32 triminfo_data; - u32 triminfo_ctrl; - u32 triminfo_ctrl1; + u32 triminfo_ctrl[MAX_TRIMINFO_CTRL_REG]; + u32 triminfo_ctrl_count; u32 tmu_ctrl; u32 test_mux_addr_shift; @@ -200,6 +201,7 @@ struct exynos_tmu_registers { * @second_point_trim: temp value of the second point trimming * @default_temp_offset: default temperature offset in case of no trimming * @test_mux; information if SoC supports test MUX + * @triminfo_reload: reload value to read TRIMINFO register * @cal_type: calibration type for temperature * @freq_clip_table: Table representing frequency reduction percentage. * @freq_tab_count: Count of the above table as frequency reduction may @@ -230,6 +232,7 @@ struct exynos_tmu_platform_data { u8 second_point_trim; u8 default_temp_offset; u8 test_mux; + u8 triminfo_reload[MAX_TRIMINFO_CTRL_REG]; enum calibration_type cal_type; enum soc_type type; diff --git a/drivers/thermal/samsung/exynos_tmu_data.c b/drivers/thermal/samsung/exynos_tmu_data.c index 177ada5..362a1e1 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c +++ b/drivers/thermal/samsung/exynos_tmu_data.c @@ -169,7 +169,8 @@ struct exynos_tmu_init_data const exynos3250_default_tmu_data = { #if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250) static const struct exynos_tmu_registers exynos4412_tmu_registers = { .triminfo_data = EXYNOS_TMU_REG_TRIMINFO, -
[PATCHv6 0/2] thermal: exynos: Add support for TRIMINFO feature of Exynos3250
This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250. But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only one TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which has more than one TRIMINF_CTRL. Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove duplicate code when reading triminfo register of Exynos5440. Changes from v5: - Rebase this patchset on next branch of linux-soc-thermal.git Changes from v4: - Remove un-necessary triminfo_ctrl_{shift, mask} field - Includes Bartlomiej's patch[1] that Exynos5260 / Exynos5420 should not use TRIM_RELOAD flag [2] https://lkml.org/lkml/2014/8/20/481 Changes from v3: - Add reviewed message of Amit Daniel Kachhap - Split RELOAD patch as two patch - Fix 'TRIMINFO_RELOAD_SHIFT' value - This series includes separate patch[1] [1] https://lkml.org/lkml/2014/8/20/5 - Drop ACTIME bit setting because TRM includes not enough information of ACTIME bit. Changes from v2: - Fix build break because of missing 'or' operation. Changes from v1: - Add missing 'TMU_SUPPORT_TRIM_RELOAD' features Chanwoo Choi (2): thermal: exynos: Add support for many TRIMINFO_CTRL registers thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250 drivers/thermal/samsung/exynos_thermal_common.h | 1 + drivers/thermal/samsung/exynos_tmu.c| 15 --- drivers/thermal/samsung/exynos_tmu.h| 7 +-- drivers/thermal/samsung/exynos_tmu_data.c | 11 +-- drivers/thermal/samsung/exynos_tmu_data.h | 8 ++-- 5 files changed, 33 insertions(+), 9 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6 2/2] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
This patch add support for TRIM_RELOAD feature at Exynos3250. The TMu of Exynos3250 has two TRIMINFO_CON register and must need to set RELOAD bit before reading TRIMINFO register. Signed-off-by: Chanwoo Choi Acked-by: Kyungmin Park Cc: Zhang Rui Cc: Eduardo Valentin Cc: Amit Daniel Kachhap Reviewed-by: Amit Daniel Kachhap --- drivers/thermal/samsung/exynos_tmu_data.c | 9 +++-- drivers/thermal/samsung/exynos_tmu_data.h | 7 +-- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/samsung/exynos_tmu_data.c b/drivers/thermal/samsung/exynos_tmu_data.c index 362a1e1..8bae170 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c +++ b/drivers/thermal/samsung/exynos_tmu_data.c @@ -87,6 +87,9 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data = { #if defined(CONFIG_SOC_EXYNOS3250) static const struct exynos_tmu_registers exynos3250_tmu_registers = { .triminfo_data = EXYNOS_TMU_REG_TRIMINFO, + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1, + .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2, + .triminfo_ctrl_count = 2, .tmu_ctrl = EXYNOS_TMU_REG_CONTROL, .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT, .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT, @@ -147,8 +150,10 @@ static const struct exynos_tmu_registers exynos3250_tmu_registers = { .temp_level = 95, \ }, \ .freq_tab_count = 2, \ + .triminfo_reload[0] = EXYNOS_TRIMINFO_RELOAD_ENABLE, \ + .triminfo_reload[1] = EXYNOS_TRIMINFO_RELOAD_ENABLE, \ .registers = &exynos3250_tmu_registers, \ - .features = (TMU_SUPPORT_EMULATION | \ + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \ TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \ TMU_SUPPORT_EMUL_TIME) #endif @@ -169,7 +174,7 @@ struct exynos_tmu_init_data const exynos3250_default_tmu_data = { #if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250) static const struct exynos_tmu_registers exynos4412_tmu_registers = { .triminfo_data = EXYNOS_TMU_REG_TRIMINFO, - .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON, + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2, .triminfo_ctrl_count = 1, .tmu_ctrl = EXYNOS_TMU_REG_CONTROL, .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT, diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h index 6b47a17..4b8f33c 100644 --- a/drivers/thermal/samsung/exynos_tmu_data.h +++ b/drivers/thermal/samsung/exynos_tmu_data.h @@ -39,14 +39,17 @@ #define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT 8 #define EXYNOS_TMU_CORE_EN_SHIFT 0 +/* Exynos3250 specific registers */ +#define EXYNOS_TMU_TRIMINFO_CON1 0x10 + /* Exynos4210 specific registers */ #define EXYNOS4210_TMU_REG_THRESHOLD_TEMP 0x44 #define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50 #define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x -/* Exynos5250 and Exynos4412 specific registers */ -#define EXYNOS_TMU_TRIMINFO_CON0x14 +/* Exynos5250, Exynos4412, Exynos3250 specific registers */ +#define EXYNOS_TMU_TRIMINFO_CON2 0x14 #define EXYNOS_THD_TEMP_RISE 0x50 #define EXYNOS_THD_TEMP_FALL 0x54 #define EXYNOS_EMUL_CON0x80 -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
Dear Eduardo, On 08/30/2014 04:28 AM, Eduardo Valentin wrote: > Chanwoo, > > On Fri, Aug 29, 2014 at 08:50:41AM +0900, Chanwoo Choi wrote: >> Dear Eduardo, >> >> On 08/28/2014 11:53 PM, Eduardo Valentin wrote: >>> On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote: Dear Eduardo, This patch is wrong. It is my mistake. Please ignore only this patch because the offset calculation of 'case 0' is different from 'case 2'. >>> >>> >>> Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be >>> a common agreement. > >> >> Yes, patches 1 - 3 are correct. >> > > OK. I pulled patch 01 into my next branch. > > Can you please update patches 02 and 03 based on my next brach? They are > conflicting with the massive cleanups done by Bartlomiej (Thanks > Bartlomiej). So, please, resend patches 02 and 03 only, refreshed onto > my next branch. OK, I'll send new patchset after rebase it. Best Regards, Chanwoo Choi > > Cheers. > >> Best Regards, >> Chanwoo Choi >> >>> Best Regards, Chanwoo Choi On 08/26/2014 10:31 AM, Chanwoo Choi wrote: > This patch remove simply duplicate code when reading triminfo register of > Exynos5440. > > Signed-off-by: Chanwoo Choi > Acked-by: Kyungmin Park > Cc: Zhang Rui > Cc: Eduardo Valentin > Cc: Amit Daniel Kachhap > Reviewed-by: Amit Daniel Kachhap > --- > drivers/thermal/samsung/exynos_tmu.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/thermal/samsung/exynos_tmu.c > b/drivers/thermal/samsung/exynos_tmu.c > index 64c702a..5888467 100644 > --- a/drivers/thermal/samsung/exynos_tmu.c > +++ b/drivers/thermal/samsung/exynos_tmu.c > @@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct > platform_device *pdev) >*/ > switch (data->id) { > case 0: > + case 2: > trim_info = readl(data->base + > EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data); > break; > case 1: > trim_info = readl(data->base + reg->triminfo_data); > break; > - case 2: > - trim_info = readl(data->base - > - EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data); > } > } else { > /* On exynos5420 the triminfo register is in the shared space */ > >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/17] drm/exynos/ipp: remove file argument from node related functions
On 09/02/2014 09:55 PM, Andrzej Hajda wrote: > Since file pointer is preserved in c_node passing it > as argument in node functions is redundant. > > Signed-off-by: Andrzej Hajda > --- > v3: > - file check moved to next patch > --- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > About both patch 16 and 17 Reviewed-by: Joonyoung Shim Thanks. > diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c > b/drivers/gpu/drm/exynos/exynos_drm_ipp.c > index 05f0f4e..9e9714a 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c > @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev, > > static struct drm_exynos_ipp_mem_node > *ipp_get_mem_node(struct drm_device *drm_dev, > - struct drm_file *file, > struct drm_exynos_ipp_cmd_node *c_node, > struct drm_exynos_ipp_queue_buf *qbuf) > { > @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node > dma_addr_t *addr; > > addr = exynos_drm_gem_get_dma_addr(drm_dev, > - qbuf->handle[i], file); > + qbuf->handle[i], c_node->filp); > if (IS_ERR(addr)) { > DRM_ERROR("failed to get addr.\n"); > ipp_put_mem_node(drm_dev, c_node, m_node); > @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event > *event) > } > > static int ipp_get_event(struct drm_device *drm_dev, > - struct drm_file *file, > struct drm_exynos_ipp_cmd_node *c_node, > struct drm_exynos_ipp_queue_buf *qbuf) > { > @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev, > e = kzalloc(sizeof(*e), GFP_KERNEL); > if (!e) { > spin_lock_irqsave(&drm_dev->event_lock, flags); > - file->event_space += sizeof(e->event); > + c_node->filp->event_space += sizeof(e->event); > spin_unlock_irqrestore(&drm_dev->event_lock, flags); > return -ENOMEM; > } > @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev, > e->event.prop_id = qbuf->prop_id; > e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id; > e->base.event = &e->event.base; > - e->base.file_priv = file; > + e->base.file_priv = c_node->filp; > e->base.destroy = ipp_free_event; > mutex_lock(&c_node->event_lock); > list_add_tail(&e->base.link, &c_node->event_list); > @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, > void *data, > switch (qbuf->buf_type) { > case IPP_BUF_ENQUEUE: > /* get memory node */ > - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf); > + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf); > if (IS_ERR(m_node)) { > DRM_ERROR("failed to get m_node.\n"); > return PTR_ERR(m_node); > @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, > void *data, >*/ > if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) { > /* get event for destination buffer */ > - ret = ipp_get_event(drm_dev, file, c_node, qbuf); > + ret = ipp_get_event(drm_dev, c_node, qbuf); > if (ret) { > DRM_ERROR("failed to get event.\n"); > goto err_clean_node; > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 11/19] irqchip: vic: Add support for FIQ management
On Tue, Sep 02, 2014 at 02:00:45PM +0100, Daniel Thompson wrote: > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index bda5a91..8821160 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data > *gic, > /* > * Fully acknowledge (both ack and eoi) a FIQ-based IPI > */ > -static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs, > -void *data) > +void gic_handle_fiq_ipi(void) > { > struct gic_chip_data *gic = &gic_data[0]; > - void __iomem *cpu_base = gic_data_cpu_base(gic); > + void __iomem *cpu_base; > unsigned long irqstat, irqnr; > > + if (!gic || !gic->fiq_enable) > + return; > + > + cpu_base = gic_data_cpu_base(gic); > + > if (WARN_ON(!in_nmi())) > return NOTIFY_BAD; > > @@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb, > unsigned long regs, > > return NOTIFY_OK; > } > - > -/* > - * Notifier to ensure IPI FIQ is acknowledged correctly. > - */ > -static struct notifier_block gic_fiq_ipi_notifier = { > - .notifier_call = gic_handle_fiq_ipi, > -}; > #else /* CONFIG_FIQ */ > static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq, >int group) {} > @@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int > irq_start, > #ifdef CONFIG_SMP > set_smp_cross_call(gic_raise_softirq); > register_cpu_notifier(&gic_cpu_notifier); > -#ifdef CONFIG_FIQ > - if (gic_data_fiq_enable(gic)) > - register_fiq_nmi_notifier(&gic_fiq_ipi_notifier); > -#endif > #endif > set_handle_irq(gic_handle_irq); > } Shouldn't this be merged into some other patch? -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
HI Thomas, Thomas Abraham writes: > On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman wrote: >> Hi Thomas, >> >> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham wrote: >>> Hi Kevin, >>> >>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: > On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap > wrote: [...] >>> >>> Can you clarify how you're setting the voltages to ensure stability? >> >> below is the diff : wip/exynos/integ > > Thanks. > > I've applied your patch, and bootup shows vdd_arm and vdd_kfc at > 1500mV, but still when booting with cpuidle enabled (bL switcher > disabled), I'm seeing lockups with no kernel output. With CPUidle > disabled, things are pretty stable. > > What tree are you using to test this out on 5420? I'm using mainline > v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my > wip/exynos/integ branch at > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? >>> >>> I tried to recreate the boot lockup issue using the same steps you >>> listed above for the Exynos5800 peach-pi platform (Chromebook2), but I >>> do not see any issues. I can see both clusters with max clock speed >>> after boot (1.8GHz and 1.3GHz). >>> >>> I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support >>> patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 >>> voltage to 1.3V. >> >> Can you share your branch and temp hack(s) as well as your defconfig? >> >> I'm using the v3.17-rc1 branch from the exynos tree (which includes >> the max77802 series) but also has a bunch of other stuff which may be >> causing the issue. >> >> It would be good if I can reproduce your exact tree/branch and see if >> I still have the same problem. > > The branch with the patches that have been used to test cpufreq on > Exynos5800 is available at > > https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq > > Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) Are there any plans to update the main referece branch and include cpufreq? Kevin [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a -- To unsubscribe from this list: send the line "unsubscribe linux-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] irqchip: exynos-combiner: Fix compilation error on ARM64
Naveen, On Tue, Sep 02, 2014 at 08:54:52PM +0530, Naveen Krishna Chatradhi wrote: > The following compilation error occurs on 64-bit Exynos7 SoC: > > drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: > drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of > function ‘set_irq_flags’ [-Werror=implicit-function-declaration] > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > ^ > drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared > (first use in this function) > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > ^ > drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is > reported only once for each function it appears in > drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared > (first use in this function) > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > > Fix the build error by including asm/hardirq.h. > > Signed-off-by: Naveen Krishna Chatradhi > Cc: Thomas Gleixner > --- > drivers/irqchip/exynos-combiner.c |2 ++ > 1 file changed, 2 insertions(+) Please include me in the Cc on future irqchip fixes, I almost missed this one. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-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] mfd: syscon: Decouple syscon interface from platform devices
On Tuesday 02 September 2014 19:42:52 Alexander Shiyan wrote: > > > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) > > > -{ > > > - struct device *dev; > > > - struct syscon *syscon; > > > - > > > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s, > > > -syscon_match_pdevname); > > > - if (!dev) > > > - return ERR_PTR(-EPROBE_DEFER); > > > - > > > - syscon = dev_get_drvdata(dev); > > > - > > > - return syscon->regmap; > > > -} > > > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname); > > > > I think this can actually be left intact if that helps with clps71xx. > > It could be done in a hacky way using bus_find_device_by_name() > > to keep it simple, or in a somewhat nicer way by keeping the > > syscon platform_driver around for the non-DT case. > > It will not work anyway because the patch involves the use of > of_device_is_compatible(), of_iomap() etc... What I meant was to have the pdevname stuff keep working the way it does today. At that point, you essentially have two completely independent drivers, one that registers a platform driver and provides syscon_regmap_lookup_by_pdevname, and one that provides the other interfaces using DT lookup. 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 v2 0/7] arch: arm64: enable support for Samsung Exynos7 SoC
Hi Naveen, On 02.09.2014 17:35, Naveen Krishna Chatradhi wrote: > Changes since v1: > - Reduced the number of features targetted for the initial platform support. > Are you going to reply to my comments to previous version? Btw. My @samsung.com e-mail is no longer valid. Please use my private one for patches related to Samsung clocks and pin control drivers. Respective patch for MAINTAINERS file has been applied already. 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] irqchip: exynos-combiner: Fix compilation error on ARM64
On 02/09/14 16:24, Naveen Krishna Chatradhi wrote: The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including asm/hardirq.h. You should avoid using asm headers whenever possible esp. in driver code. linux/hardirq.h or much better linux/interrupt.h should fix this error. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-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] mfd: syscon: Decouple syscon interface from platform devices
Tue, 02 Sep 2014 17:20:03 +0200 от Arnd Bergmann : > On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote: > > Currently a syscon entity can only be registered directly through a > > platform device that binds to a dedicated syscon driver. However in > > certain cases it is required to bind a device with it's dedicated > > driver rather than binding with syscon driver. > > > > For example, certain SoCs (e.g. Exynos) contain system controller > > blocks which perform various functions such as power domain control, > > CPU power management, low power mode control, but in addition contain > > certain IP integration glue, such as various signal masks, > > coprocessor power control, etc. In such case, there is a need to have > > a dedicated driver for such system controller but also share registers > > with other drivers. The latter is where the syscon interface is helpful. > > > > This patch decouples syscon object from syscon platform driver, and > > allows to create syscon objects first time when it is required by > > calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon > > objects along with syscon provider device_nodes and regmap handles. > > > > Signed-off-by: Pankaj Dubey > > Signed-off-by: Tomasz Figa > > --- > > V1 of this patchset [1] and related discussion can be found here [1]. > > > > Changes since v1: > > - Removed of_syscon_unregister function. > > - Modified of_syscon_register function and it will be used by syscon.c > >to create syscon objects whenever required. > > - Removed platform device support from syscon. > > - Removed syscon_regmap_lookup_by_pdevname API support. > > - As there are significant changes w.r.t patchset v1, I am taking over > >author for this patchset from Tomasz Figa. > > Note that you got the Signed-off-by: list wrong, you should never have > any people listed as Signed-off-by after your own name, and they should > be listed before your name only when you are forwarding their patches. > > > Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname > > and > > will be broken after this patch. As per discussion over here [1], patches > > for making these drivers DT based are ready and once that is done they can > > use > > syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible. > > > > [1]: https://lkml.org/lkml/2014/8/22/81 ... > > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) > > -{ > > - struct device *dev; > > - struct syscon *syscon; > > - > > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s, > > -syscon_match_pdevname); > > - if (!dev) > > - return ERR_PTR(-EPROBE_DEFER); > > - > > - syscon = dev_get_drvdata(dev); > > - > > - return syscon->regmap; > > -} > > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname); > > I think this can actually be left intact if that helps with clps71xx. > It could be done in a hacky way using bus_find_device_by_name() > to keep it simple, or in a somewhat nicer way by keeping the > syscon platform_driver around for the non-DT case. It will not work anyway because the patch involves the use of of_device_is_compatible(), of_iomap() etc... --- N�r��yb�X��ǧv�^�){.n�+{�x,�ȧ���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf
[PATCH v2 4/7] clk: samsung: add initial clock support for Exynos7 SoC
Add initial clock support for Exynos7 SoC which is required to bring up platforms based on Exynos7. Signed-off-by: Naveen Krishna Chatradhi Cc: Tomasz Figa Cc: Mike Turquette --- .../devicetree/bindings/clock/exynos7-clock.txt| 37 ++ drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos7.c | 438 include/dt-bindings/clock/exynos7-clk.h| 55 +++ 4 files changed, 531 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt b/Documentation/devicetree/bindings/clock/exynos7-clock.txt new file mode 100644 index 000..798eb10 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt @@ -0,0 +1,37 @@ +* Samsung Exynos7 Clock Controller + +Exynos7 clock controller has various blocks which are instantiated +independently from the device-tree. These clock controllers +generate and supply clocks to various hardware blocks within +the SoC. + +Each clock is assigned an identifier and client nodes can use +this identifier to specify the clock which they consume. All +available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos7-clk.h header and can be used in +device tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It +is expected that they are defined using standard clock bindings +with following clock-output-names: + + - "fin_pll" - PLL input clock from XXTI + +Required Properties for Clock Controller: + + - compatible: clock controllers will use one of the following + compatible strings to indicate the clock controller + functionality. + + - "samsung,exynos7-clock-topc" + - "samsung,exynos7-clock-top0" + - "samsung,exynos7-clock-peric0" + - "samsung,exynos7-clock-peric1" + - "samsung,exynos7-clock-peris" + + - reg: physical base address of the controller and the length of + memory mapped region. + + - #clock-cells: should be 1. diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 6fb4bc6..5da0ba9 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -18,3 +18,4 @@ obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o obj-$(CONFIG_ARCH_S5PV210) += clk-s5pv210.o clk-s5pv210-audss.o +obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o diff --git a/drivers/clk/samsung/clk-exynos7.c b/drivers/clk/samsung/clk-exynos7.c new file mode 100644 index 000..25e12b3 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos7.c @@ -0,0 +1,438 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Naveen Krishna Chatradhi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * +*/ + +#include +#include +#include +#include + +#include "clk.h" +#include + +/* Register Offset definitions for CMU_TOPC (0x1057) */ +#define CC_PLL_LOCK0x +#define BUS0_PLL_LOCK 0x0004 +#define BUS1_DPLL_LOCK 0x0008 +#define MFC_PLL_LOCK 0x000C +#define AUD_PLL_LOCK 0x0010 +#define CC_PLL_CON00x0100 +#define BUS0_PLL_CON0 0x0110 +#define BUS1_DPLL_CON0 0x0120 +#define MFC_PLL_CON0 0x0130 +#define AUD_PLL_CON0 0x0140 +#define AUD_PLL_CON1 0x0144 +#define AUD_PLL_CON2 0x0148 +#define MIF_PLL_CON0 0x0150 +#define MIF_PLL_CON1 0x0154 +#define MIF_PLL_CON2 0x0158 +#define MUX_SEL_TOPC0 0x0200 +#define MUX_SEL_TOPC1 0x0204 +#define MUX_SEL_TOPC3 0x020C +#define DIV_TOPC1 0x0604 +#define DIV_TOPC3 0x060C +#define ENABLE_ACLK_TOPC1 0x0804 +#define ENABLE_SCLK_TOPC1 0x0A04 + +static struct samsung_fixed_factor_clock topc_fixed_factor_clks[] __initdata = { + FFACTOR(0, "ffac_topc_bus0_pll_div2", "mout_bus0_pll_ctrl", 1, 2, 0), + FFACTOR(0, "ffac_topc_bus0_pll_div4", + "ffac_topc_bus0_pll_div2", 1, 2, 0), + FFACTOR(0, "ffac_topc_bus1_pll_div2", "mout_bus1_pll_ctrl", 1, 2, 0), + FFACTOR(0, "ffac_topc_cc_pll_div2", "mout_cc_pll_ctrl", 1, 2, 0), + FFACTOR(0, "ffac_topc_mfc_pll_div2", "mout_mfc_pll_ctrl", 1, 2, 0), +}; + +/* List of parent clocks for Muxes in CMU_TOPC */ +PNAME(mout_bus0_pll_ctrl_p)= { "fin_pll", "fout_bus0_pll" }; +PNAME(mout_bus1_pll_ctrl_p)= { "fin_pll", "fout_bus1_pll" }; +PNAME(mout_cc_pll_ctrl_p) = { "fin_pll", "fout_cc_pll" }; +PNAME(mout_mfc_pll_ctrl_p) = { "fin_pll", "fout_mfc_pll" }; + +PNAME(mo
Re: [PATCH] tty/serial: fix config dependencies for samsung serial
On Tuesday 02 September 2014 20:52:00 Naveen Krishna Chatradhi wrote: > Make the config symbols SERIAL_SAMSUNG_UARTS_4 and > SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than > PLAT_SAMSUNG. Please always describe why you are doing a change. This patch seems really pointless. > config SERIAL_SAMSUNG_UARTS_4 > bool > - depends on PLAT_SAMSUNG > + depends on SERIAL_SAMSUNG > default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || > CPU_S3C2442) > help > Internal node for the common case of 4 Samsung compatible UARTs > > config SERIAL_SAMSUNG_UARTS > int > - depends on PLAT_SAMSUNG > + depends on SERIAL_SAMSUNG > default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 > default 3 > help > Have you checked that it still builds on all samsung platforms when SERIAL_SAMSUNG is disabled? We have had build errors in this area in the past. 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
[PATCH v2 7/7] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
From: Alim Akhtar This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. Signed-off-by: Alim Akhtar Signed-off-by: Naveen Krishna Chatradhi Cc: Rob Herring Cc: Catalin Marinas --- arch/arm64/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fd4e81a..b4d1dc2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,18 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_EXYNOS + bool + help + This enables support for Samsung Exynos SoC family + +config ARCH_EXYNOS7 + bool "ARMv8 based Samsung Exynos7" + select ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + help + This enables support for Samsung Exynos7 SoC family + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB -- 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 v2 6/7] tty/serial: samsung: enable usage for 64-bit Exynos platforms
Allow Samsung serial driver to be usable on Exynos 64-bit SoC based platforms. Signed-off-by: Pankaj Dubey Signed-off-by: Naveen Krishna Chatradhi Cc: Greg Kroah-Hartman --- drivers/tty/serial/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 26cec64..3383744 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -220,7 +220,7 @@ config SERIAL_CLPS711X_CONSOLE config SERIAL_SAMSUNG tristate "Samsung SoC serial support" - depends on PLAT_SAMSUNG + depends on PLAT_SAMSUNG || ARCH_EXYNOS select SERIAL_CORE help Support for the on-chip UARTs on the Samsung S3C24XX series CPUs, -- 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 v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
Add initial device tree nodes for EXYNOS7 SoC and board dts file to support Espresso board based on Exynos7 SoC. Signed-off-by: Naveen Krishna Chatradhi Cc: Rob Herring Cc: Catalin Marinas --- arch/arm64/boot/dts/Makefile|1 + arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 31 + arch/arm64/boot/dts/exynos/exynos7.dtsi | 168 +++ 3 files changed, 200 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..a3bc18a 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,3 +1,4 @@ +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos/exynos7-espresso.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts new file mode 100644 index 000..f6a8879 --- /dev/null +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts @@ -0,0 +1,31 @@ +/* + * SAMSUNG Exynos7 Espresso board device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.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. +*/ + +/dts-v1/; +#include "exynos7.dtsi" + +/ { + model = "Samsung Exynos7 Espresso board based on EXYNOS7"; + compatible = "samsung,exynos7-espresso", "samsung,exynos7"; + + chosen { + linux,stdout-path = &serial_2; + }; + + memory@4000 { + device_type = "memory"; + reg = <0x0 0x4000 0x0 0xC000>; + }; +}; + +&serial_2 { + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi new file mode 100644 index 000..e593af55 --- /dev/null +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi @@ -0,0 +1,168 @@ +/* + * SAMSUNG EXYNOS7 SoC device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.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. + */ + +#include + +/ { + compatible = "samsung,exynos7"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &serial_0; + serial1 = &serial_1; + serial2 = &serial_2; + serial3 = &serial_3; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + enable-method = "psci"; + reg = <0x0>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + enable-method = "psci"; + reg = <0x1>; + }; + + cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + enable-method = "psci"; + reg = <0x2>; + }; + + cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + enable-method = "psci"; + reg = <0x3>; + }; + }; + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + + soc: soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0 0x1800>; + + chipid@1000 { + compatible = "samsung,exynos4210-chipid"; + reg = <0x1000 0x100>; + }; + + fin_pll: xxti { + compatible = "fixed-clock"; + clock-frequency = <2400>; + clock-output-names = "fin_pll"; + #clock-cells = <0>; + }; + + gic: interrupt-controller@11001000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x11001000 0x1000>, + <0x11002000 0x1000>, +
[PATCH v2 2/7] clk: samsung: Factor out the common code to clk.c
While adding clock support for Exynos5260, the infrastructure to register multiple clock controllers was introduced. Factor out the support for registering multiple clock controller from Exynos5260 clock code to common samsung clock code so that it can be used by other Exynos SoC which have multiple clock controllers. Signed-off-by: Naveen Krishna Chatradhi Cc: Tomasz Figa Cc: Mike Turquette --- drivers/clk/samsung/clk-exynos5260.c | 183 +- drivers/clk/samsung/clk.c| 95 ++ drivers/clk/samsung/clk.h| 34 +++ 3 files changed, 155 insertions(+), 157 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos5260.c b/drivers/clk/samsung/clk-exynos5260.c index ce3de97..d72c982 100644 --- a/drivers/clk/samsung/clk-exynos5260.c +++ b/drivers/clk/samsung/clk-exynos5260.c @@ -11,10 +11,8 @@ #include #include -#include #include #include -#include #include "clk-exynos5260.h" #include "clk.h" @@ -22,39 +20,6 @@ #include -static LIST_HEAD(clock_reg_cache_list); - -struct exynos5260_clock_reg_cache { - struct list_head node; - void __iomem *reg_base; - struct samsung_clk_reg_dump *rdump; - unsigned int rd_num; -}; - -struct exynos5260_cmu_info { - /* list of pll clocks and respective count */ - struct samsung_pll_clock *pll_clks; - unsigned int nr_pll_clks; - /* list of mux clocks and respective count */ - struct samsung_mux_clock *mux_clks; - unsigned int nr_mux_clks; - /* list of div clocks and respective count */ - struct samsung_div_clock *div_clks; - unsigned int nr_div_clks; - /* list of gate clocks and respective count */ - struct samsung_gate_clock *gate_clks; - unsigned int nr_gate_clks; - /* list of fixed clocks and respective count */ - struct samsung_fixed_rate_clock *fixed_clks; - unsigned int nr_fixed_clks; - /* total number of clocks with IDs assigned*/ - unsigned int nr_clk_ids; - - /* list and number of clocks registers */ - unsigned long *clk_regs; - unsigned int nr_clk_regs; -}; - /* * Applicable for all 2550 Type PLLS for Exynos5260, listed below * DISP_PLL, EGL_PLL, KFC_PLL, MEM_PLL, BUS_PLL, MEDIA_PLL, G3D_PLL. @@ -115,102 +80,6 @@ static struct samsung_pll_rate_table pll2650_24mhz_tbl[] __initdata = { #ifdef CONFIG_PM_SLEEP -static int exynos5260_clk_suspend(void) -{ - struct exynos5260_clock_reg_cache *cache; - - list_for_each_entry(cache, &clock_reg_cache_list, node) - samsung_clk_save(cache->reg_base, cache->rdump, - cache->rd_num); - - return 0; -} - -static void exynos5260_clk_resume(void) -{ - struct exynos5260_clock_reg_cache *cache; - - list_for_each_entry(cache, &clock_reg_cache_list, node) - samsung_clk_restore(cache->reg_base, cache->rdump, - cache->rd_num); -} - -static struct syscore_ops exynos5260_clk_syscore_ops = { - .suspend = exynos5260_clk_suspend, - .resume = exynos5260_clk_resume, -}; - -static void exynos5260_clk_sleep_init(void __iomem *reg_base, - unsigned long *rdump, - unsigned long nr_rdump) -{ - struct exynos5260_clock_reg_cache *reg_cache; - - reg_cache = kzalloc(sizeof(struct exynos5260_clock_reg_cache), - GFP_KERNEL); - if (!reg_cache) - panic("could not allocate register cache.\n"); - - reg_cache->rdump = samsung_clk_alloc_reg_dump(rdump, nr_rdump); - - if (!reg_cache->rdump) - panic("could not allocate register dump storage.\n"); - - if (list_empty(&clock_reg_cache_list)) - register_syscore_ops(&exynos5260_clk_syscore_ops); - - reg_cache->rd_num = nr_rdump; - reg_cache->reg_base = reg_base; - list_add_tail(®_cache->node, &clock_reg_cache_list); -} - -#else -static void exynos5260_clk_sleep_init(void __iomem *reg_base, - unsigned long *rdump, - unsigned long nr_rdump){} -#endif - -/* - * Common function which registers plls, muxes, dividers and gates - * for each CMU. It also add CMU register list to register cache. - */ - -void __init exynos5260_cmu_register_one(struct device_node *np, - struct exynos5260_cmu_info *cmu) -{ - void __iomem *reg_base; - struct samsung_clk_provider *ctx; - - reg_base = of_iomap(np, 0); - if (!reg_base) - panic("%s: failed to map registers\n", __func__); - - ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids); - if (!ctx) - panic("%s: unable to alllocate ctx\n", __func__); - - if (cmu->pll_clks) - samsung_clk_register_pll(ctx, cmu->pll_clks, cmu->nr_pll_clks, - reg_base); - if (cmu->mux_clks) - samsun
[PATCH v2 3/7] clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info
Add the fields "fixed_factor_clks" and "nr_fixed_factor_clks" to "struct exynos_cmu_info" to allow registering of fixed factor clocks as well with exynos_cmu_register_one(). Signed-off-by: Naveen Krishna Chatradhi Cc: Tomasz Figa Cc: Mike Turquette --- drivers/clk/samsung/clk.c |3 +++ drivers/clk/samsung/clk.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c index a043654..4b31267 100644 --- a/drivers/clk/samsung/clk.c +++ b/drivers/clk/samsung/clk.c @@ -402,6 +402,9 @@ void __init exynos_cmu_register_one(struct device_node *np, if (cmu->fixed_clks) samsung_clk_register_fixed_rate(ctx, cmu->fixed_clks, cmu->nr_fixed_clks); + if (cmu->fixed_factor_clks) + samsung_clk_register_fixed_factor(ctx, cmu->fixed_factor_clks, + cmu->nr_fixed_factor_clks); if (cmu->clk_regs) exynos_clk_sleep_init(reg_base, cmu->clk_regs, cmu->nr_clk_regs); diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h index 552d155..993b51c 100644 --- a/drivers/clk/samsung/clk.h +++ b/drivers/clk/samsung/clk.h @@ -347,6 +347,9 @@ struct exynos_cmu_info { /* list of fixed clocks and respective count */ struct samsung_fixed_rate_clock *fixed_clks; unsigned int nr_fixed_clks; + /* list of fixed factor clocks and respective count */ + struct samsung_fixed_factor_clock *fixed_factor_clks; + unsigned int nr_fixed_factor_clks; /* total number of clocks with IDs assigned*/ unsigned int nr_clk_ids; -- 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 v2 1/7] clk: samsung: add support for 145xx and 1460x PLLs
PLL145xx is similar to PLL35xx and PLL1460x is almost similar to PLL46xx with minor differences in bit positions. Hence, reuse the functions defined for pll_35xx and pll_46xx to support 145xx and 1460x PLLs respectively. Signed-off-by: Naveen Krishna Chatradhi Cc: Tomasz Figa Cc: Mike Turquette --- drivers/clk/samsung/clk-pll.c | 25 - drivers/clk/samsung/clk-pll.h |4 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c index b07fad2..9d70e5c 100644 --- a/drivers/clk/samsung/clk-pll.c +++ b/drivers/clk/samsung/clk-pll.c @@ -482,6 +482,8 @@ static const struct clk_ops samsung_pll45xx_clk_min_ops = { #define PLL46XX_VSEL_MASK (1) #define PLL46XX_MDIV_MASK (0x1FF) +#define PLL1460X_MDIV_MASK (0x3FF) + #define PLL46XX_PDIV_MASK (0x3F) #define PLL46XX_SDIV_MASK (0x7) #define PLL46XX_VSEL_SHIFT (27) @@ -511,13 +513,15 @@ static unsigned long samsung_pll46xx_recalc_rate(struct clk_hw *hw, pll_con0 = __raw_readl(pll->con_reg); pll_con1 = __raw_readl(pll->con_reg + 4); - mdiv = (pll_con0 >> PLL46XX_MDIV_SHIFT) & PLL46XX_MDIV_MASK; + mdiv = (pll_con0 >> PLL46XX_MDIV_SHIFT) & ((pll->type == pll_1460x) ? + PLL1460X_MDIV_MASK : PLL46XX_MDIV_MASK); pdiv = (pll_con0 >> PLL46XX_PDIV_SHIFT) & PLL46XX_PDIV_MASK; sdiv = (pll_con0 >> PLL46XX_SDIV_SHIFT) & PLL46XX_SDIV_MASK; kdiv = pll->type == pll_4650c ? pll_con1 & PLL4650C_KDIV_MASK : pll_con1 & PLL46XX_KDIV_MASK; - shift = pll->type == pll_4600 ? 16 : 10; + shift = ((pll->type == pll_4600) || (pll->type == pll_1460x)) ? 16 : 10; + fvco *= (mdiv << shift) + kdiv; do_div(fvco, (pdiv << sdiv)); fvco >>= shift; @@ -573,14 +577,21 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw, unsigned long drate, lock = 0x; /* Set PLL PMS and VSEL values. */ - con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) | + if (pll->type == pll_1460x) { + con0 &= ~((PLL1460X_MDIV_MASK << PLL46XX_MDIV_SHIFT) | + (PLL46XX_PDIV_MASK << PLL46XX_PDIV_SHIFT) | + (PLL46XX_SDIV_MASK << PLL46XX_SDIV_SHIFT)); + } else { + con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) | (PLL46XX_PDIV_MASK << PLL46XX_PDIV_SHIFT) | (PLL46XX_SDIV_MASK << PLL46XX_SDIV_SHIFT) | (PLL46XX_VSEL_MASK << PLL46XX_VSEL_SHIFT)); + con0 |= rate->vsel << PLL46XX_VSEL_SHIFT; + } + con0 |= (rate->mdiv << PLL46XX_MDIV_SHIFT) | (rate->pdiv << PLL46XX_PDIV_SHIFT) | - (rate->sdiv << PLL46XX_SDIV_SHIFT) | - (rate->vsel << PLL46XX_VSEL_SHIFT); + (rate->sdiv << PLL46XX_SDIV_SHIFT); /* Set PLL K, MFR and MRR values. */ con1 = __raw_readl(pll->con_reg + 0x4); @@ -1190,6 +1201,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx, /* clk_ops for 35xx and 2550 are similar */ case pll_35xx: case pll_2550: + case pll_1450x: + case pll_1451x: + case pll_1452x: if (!pll->rate_table) init.ops = &samsung_pll35xx_clk_min_ops; else @@ -1223,6 +1237,7 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx, case pll_4600: case pll_4650: case pll_4650c: + case pll_1460x: if (!pll->rate_table) init.ops = &samsung_pll46xx_clk_min_ops; else diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h index c0ed4d4..213de9a 100644 --- a/drivers/clk/samsung/clk-pll.h +++ b/drivers/clk/samsung/clk-pll.h @@ -33,6 +33,10 @@ enum samsung_pll_type { pll_s3c2440_mpll, pll_2550xx, pll_2650xx, + pll_1450x, + pll_1451x, + pll_1452x, + pll_1460x, }; #define PLL_35XX_RATE(_rate, _m, _p, _s) \ -- 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 v2 0/7] arch: arm64: enable support for Samsung Exynos7 SoC
Changes since v1: - Reduced the number of features targetted for the initial platform support. This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC processor. NOTE: We tested these patches with the "arm64: dts: add symlink" change posted @ https://lkml.org/lkml/2014/9/1/688 The following patches are tested based on Kgene's for-next tree. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next The following patches are required for this series. 1- "irqchip: exynos-combiner: Fix compilation error on ARM64" https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36209.html 2- "tty/serial: fix config dependencies for samsung serial" https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html Alim Akhtar (1): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support Naveen Krishna Chatradhi (6): clk: samsung: add support for 145xx and 1460x PLLs clk: samsung: Factor out the common code to clk.c clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info clk: samsung: add initial clock support for Exynos7 SoC tty/serial: samsung: enable usage for 64-bit Exynos platforms arm64: dts: Add initial device tree support for EXYNOS7 .../devicetree/bindings/clock/exynos7-clock.txt| 37 ++ arch/arm64/Kconfig | 12 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/exynos/exynos7-espresso.dts| 31 ++ arch/arm64/boot/dts/exynos/exynos7.dtsi| 168 drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5260.c | 183 ++-- drivers/clk/samsung/clk-exynos7.c | 438 drivers/clk/samsung/clk-pll.c | 25 +- drivers/clk/samsung/clk-pll.h |4 + drivers/clk/samsung/clk.c | 98 + drivers/clk/samsung/clk.h | 37 ++ drivers/tty/serial/Kconfig |2 +- include/dt-bindings/clock/exynos7-clk.h| 55 +++ 14 files changed, 929 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] irqchip: exynos-combiner: Fix compilation error on ARM64
The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including asm/hardirq.h. Signed-off-by: Naveen Krishna Chatradhi Cc: Thomas Gleixner --- drivers/irqchip/exynos-combiner.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index f8636a6..7fbedcc 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -18,6 +18,8 @@ #include #include +#include + #include "irqchip.h" #define COMBINER_ENABLE_SET0x0 -- 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] tty/serial: fix config dependencies for samsung serial
From: Pankaj Dubey Make the config symbols SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than PLAT_SAMSUNG. Signed-off-by: Pankaj Dubey Signed-off-by: Naveen Krishna Chatradhi Cc: Greg Kroah-Hartman --- drivers/tty/serial/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 26cec64..4f27f0c 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -230,14 +230,14 @@ config SERIAL_SAMSUNG config SERIAL_SAMSUNG_UARTS_4 bool - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442) help Internal node for the common case of 4 Samsung compatible UARTs config SERIAL_SAMSUNG_UARTS int - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 default 3 help -- 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 v2] mfd: syscon: Decouple syscon interface from platform devices
On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote: > Currently a syscon entity can only be registered directly through a > platform device that binds to a dedicated syscon driver. However in > certain cases it is required to bind a device with it's dedicated > driver rather than binding with syscon driver. > > For example, certain SoCs (e.g. Exynos) contain system controller > blocks which perform various functions such as power domain control, > CPU power management, low power mode control, but in addition contain > certain IP integration glue, such as various signal masks, > coprocessor power control, etc. In such case, there is a need to have > a dedicated driver for such system controller but also share registers > with other drivers. The latter is where the syscon interface is helpful. > > This patch decouples syscon object from syscon platform driver, and > allows to create syscon objects first time when it is required by > calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon > objects along with syscon provider device_nodes and regmap handles. > > Signed-off-by: Pankaj Dubey > Signed-off-by: Tomasz Figa > --- > V1 of this patchset [1] and related discussion can be found here [1]. > > Changes since v1: > - Removed of_syscon_unregister function. > - Modified of_syscon_register function and it will be used by syscon.c >to create syscon objects whenever required. > - Removed platform device support from syscon. > - Removed syscon_regmap_lookup_by_pdevname API support. > - As there are significant changes w.r.t patchset v1, I am taking over >author for this patchset from Tomasz Figa. Note that you got the Signed-off-by: list wrong, you should never have any people listed as Signed-off-by after your own name, and they should be listed before your name only when you are forwarding their patches. > Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname > and > will be broken after this patch. As per discussion over here [1], patches > for making these drivers DT based are ready and once that is done they can use > syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible. > > [1]: https://lkml.org/lkml/2014/8/22/81 Adding Alexander Shiyan to Cc here, so we can make sure this is well coordinated. I'm also adding Michal Simek, since here was involved in earlier discussions about doing this. > drivers/mfd/syscon.c | 143 > +--- > include/linux/mfd/syscon.h |1 + > 2 files changed, 44 insertions(+), 100 deletions(-) I certainly like the diffstat ;-) > struct syscon { > + struct device_node *np; > struct regmap *regmap; > + struct list_head list; > }; Right > @@ -68,27 +72,6 @@ struct regmap *syscon_regmap_lookup_by_compatible(const > char *s) > } > EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible); > > -static int syscon_match_pdevname(struct device *dev, void *data) > -{ > - return !strcmp(dev_name(dev), (const char *)data); > -} > - > -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) > -{ > - struct device *dev; > - struct syscon *syscon; > - > - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s, > - syscon_match_pdevname); > - if (!dev) > - return ERR_PTR(-EPROBE_DEFER); > - > - syscon = dev_get_drvdata(dev); > - > - return syscon->regmap; > -} > -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname); I think this can actually be left intact if that helps with clps71xx. It could be done in a hacky way using bus_find_device_by_name() to keep it simple, or in a somewhat nicer way by keeping the syscon platform_driver around for the non-DT case. > + regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config); > + if (IS_ERR(regmap)) { > + pr_err("regmap init failed\n"); > + return ERR_CAST(regmap); > + } The last time I looked over this code, I think it was not safe to call regmap_init_mmio() with a NULL device pointer, and we decided that should be fixed. Have you checked whether it is ok now? 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 v2] mfd: syscon: Decouple syscon interface from platform devices
On 02.09.2014 16:42, Pankaj Dubey wrote: > Currently a syscon entity can only be registered directly through a > platform device that binds to a dedicated syscon driver. However in > certain cases it is required to bind a device with it's dedicated > driver rather than binding with syscon driver. > > For example, certain SoCs (e.g. Exynos) contain system controller > blocks which perform various functions such as power domain control, > CPU power management, low power mode control, but in addition contain > certain IP integration glue, such as various signal masks, > coprocessor power control, etc. In such case, there is a need to have > a dedicated driver for such system controller but also share registers > with other drivers. The latter is where the syscon interface is helpful. > > This patch decouples syscon object from syscon platform driver, and > allows to create syscon objects first time when it is required by > calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon > objects along with syscon provider device_nodes and regmap handles. > > Signed-off-by: Pankaj Dubey > Signed-off-by: Tomasz Figa > --- > V1 of this patchset [1] and related discussion can be found here [1]. > > Changes since v1: > - Removed of_syscon_unregister function. > - Modified of_syscon_register function and it will be used by syscon.c >to create syscon objects whenever required. > - Removed platform device support from syscon. > - Removed syscon_regmap_lookup_by_pdevname API support. > - As there are significant changes w.r.t patchset v1, I am taking over >author for this patchset from Tomasz Figa. I guess you should also drop my Signed-off-by too. I think the best thing would replacing it with my Suggested-by and adding Arnd's Suggested-by too. 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: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
Chanwoo, On Fri, Aug 29, 2014 at 08:50:41AM +0900, Chanwoo Choi wrote: > Dear Eduardo, > > On 08/28/2014 11:53 PM, Eduardo Valentin wrote: > > On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote: > >> Dear Eduardo, > >> > >> This patch is wrong. It is my mistake. > >> > >> Please ignore only this patch because > >> the offset calculation of 'case 0' is different from 'case 2'. > > > > > > Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be > > a common agreement. > > Yes, patches 1 - 3 are correct. > OK. I pulled patch 01 into my next branch. Can you please update patches 02 and 03 based on my next brach? They are conflicting with the massive cleanups done by Bartlomiej (Thanks Bartlomiej). So, please, resend patches 02 and 03 only, refreshed onto my next branch. Cheers. > Best Regards, > Chanwoo Choi > > > > >> > >> Best Regards, > >> Chanwoo Choi > >> > >> On 08/26/2014 10:31 AM, Chanwoo Choi wrote: > >>> This patch remove simply duplicate code when reading triminfo register of > >>> Exynos5440. > >>> > >>> Signed-off-by: Chanwoo Choi > >>> Acked-by: Kyungmin Park > >>> Cc: Zhang Rui > >>> Cc: Eduardo Valentin > >>> Cc: Amit Daniel Kachhap > >>> Reviewed-by: Amit Daniel Kachhap > >>> --- > >>> drivers/thermal/samsung/exynos_tmu.c | 4 +--- > >>> 1 file changed, 1 insertion(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/thermal/samsung/exynos_tmu.c > >>> b/drivers/thermal/samsung/exynos_tmu.c > >>> index 64c702a..5888467 100644 > >>> --- a/drivers/thermal/samsung/exynos_tmu.c > >>> +++ b/drivers/thermal/samsung/exynos_tmu.c > >>> @@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct > >>> platform_device *pdev) > >>>*/ > >>> switch (data->id) { > >>> case 0: > >>> + case 2: > >>> trim_info = readl(data->base + > >>> EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data); > >>> break; > >>> case 1: > >>> trim_info = readl(data->base + reg->triminfo_data); > >>> break; > >>> - case 2: > >>> - trim_info = readl(data->base - > >>> - EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data); > >>> } > >>> } else { > >>> /* On exynos5420 the triminfo register is in the shared space */ > >>> > >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can only be registered directly through a platform device that binds to a dedicated syscon driver. However in certain cases it is required to bind a device with it's dedicated driver rather than binding with syscon driver. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon platform driver, and allows to create syscon objects first time when it is required by calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon objects along with syscon provider device_nodes and regmap handles. Signed-off-by: Pankaj Dubey Signed-off-by: Tomasz Figa --- V1 of this patchset [1] and related discussion can be found here [1]. Changes since v1: - Removed of_syscon_unregister function. - Modified of_syscon_register function and it will be used by syscon.c to create syscon objects whenever required. - Removed platform device support from syscon. - Removed syscon_regmap_lookup_by_pdevname API support. - As there are significant changes w.r.t patchset v1, I am taking over author for this patchset from Tomasz Figa. Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname and will be broken after this patch. As per discussion over here [1], patches for making these drivers DT based are ready and once that is done they can use syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible. [1]: https://lkml.org/lkml/2014/8/22/81 drivers/mfd/syscon.c | 143 +--- include/linux/mfd/syscon.h |1 + 2 files changed, 44 insertions(+), 100 deletions(-) diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index ca15878..8247e93 100644 --- a/drivers/mfd/syscon.c +++ b/drivers/mfd/syscon.c @@ -14,41 +14,45 @@ #include #include -#include +#include #include #include -#include -#include -#include #include #include +#include -static struct platform_driver syscon_driver; +static DEFINE_SPINLOCK(syscon_list_slock); +static LIST_HEAD(syscon_list); struct syscon { + struct device_node *np; struct regmap *regmap; + struct list_head list; }; -static int syscon_match_node(struct device *dev, void *data) -{ - struct device_node *dn = data; - - return (dev->of_node == dn) ? 1 : 0; -} +static struct syscon *of_syscon_register(struct device_node *np); struct regmap *syscon_node_to_regmap(struct device_node *np) { - struct syscon *syscon; - struct device *dev; + struct syscon *entry, *syscon = NULL; + + spin_lock(&syscon_list_slock); - dev = driver_find_device(&syscon_driver.driver, NULL, np, -syscon_match_node); - if (!dev) - return ERR_PTR(-EPROBE_DEFER); + list_for_each_entry(entry, &syscon_list, list) + if (entry->np == np) { + syscon = entry; + break; + } - syscon = dev_get_drvdata(dev); + spin_unlock(&syscon_list_slock); - return syscon->regmap; + if (!syscon) + syscon = of_syscon_register(np); + + if (!IS_ERR(syscon)) + return syscon->regmap; + else + return ERR_CAST(syscon); } EXPORT_SYMBOL_GPL(syscon_node_to_regmap); @@ -68,27 +72,6 @@ struct regmap *syscon_regmap_lookup_by_compatible(const char *s) } EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible); -static int syscon_match_pdevname(struct device *dev, void *data) -{ - return !strcmp(dev_name(dev), (const char *)data); -} - -struct regmap *syscon_regmap_lookup_by_pdevname(const char *s) -{ - struct device *dev; - struct syscon *syscon; - - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s, -syscon_match_pdevname); - if (!dev) - return ERR_PTR(-EPROBE_DEFER); - - syscon = dev_get_drvdata(dev); - - return syscon->regmap; -} -EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname); - struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np, const char *property) { @@ -110,81 +93,41 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np, } EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle); -static const struct of_device_id of_syscon_match[] = { - { .compatible = "syscon", }, - { }, -}; - static struct regmap_config syscon_regmap_config = { .reg_bits = 32, .val_bits = 32,
Re: [PATCH v3 0/8] thermal: exynos: various cleanups
On Mon, Sep 01, 2014 at 07:05:27AM -0400, edubez...@gmail.com wrote: > Amit > > On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap > wrote: > > On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin > > wrote: > >> Amit, > >> > >> On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: > >>> Hi, > >>> > >>> This patch series contains various cleanups for EXYNOS thermal > >>> driver. Overall it decreases driver's LOC by 9%. It is based > >>> on next-20140731 kernel. It should not cause any functionality > >>> changes. > >>> > >> > >> Did you have the time to test this series? > > > > Hi Eduardo/Bartlomiej, > > > > For the whole series tested on exynos5250 based arndale board. > > Tested-by: Amit Daniel Kachhap > > > > Thanks! I will pull the series on my tree. Pulled into my next branch. Thanks. > > > > Sorry for the delay as I was busy in some internal work. > > > > Thanks, > > Amit D > >> > >>> Changes since v2 (https://lkml.org/lkml/2014/6/17/436): > >>> - synced patches against next-20140731 > >>> - dropped patch "thermal: exynos: remove dead code for > >>> TYPE_TWO_POINT_TRIMMING calibration" (newly added Exynos3250 > >>> SoC support uses TYPE_TWO_POINT_TRIMMING calibration) > >>> - updated patch description for patch #2 > >>> - dropped Reviewed-by from Amit from patch #8 (due to changed > >>> scope of the patch) > >>> > >>> Changes since v1 (https://lkml.org/lkml/2014/5/5/194): > >>> - synced patches against next-20140617 > >>> - merged patch "thermal: exynos: remove unused defines" into > >>> "thermal: exynos: remove unused struct exynos_tmu_registers > >>> entries" one (per request from Eduardo) > >>> - improved patch descriptions for patches #1-5 > >>> - fixed documentation for pdata->gain and pdata->reference_voltage > >>> - added Reviewed-by from Amit to patches #6, #7 and #10 > >>> - added missing Acked-by from Kyungmin Park > >>> > >>> Best regards, > >>> -- > >>> Bartlomiej Zolnierkiewicz > >>> Samsung R&D Institute Poland > >>> Samsung Electronics > >>> > >>> > >>> Bartlomiej Zolnierkiewicz (8): > >>> thermal: exynos: remove unused struct exynos_tmu_registers entries > >>> thermal: exynos: remove dead code for HW_MODE calibration > >>> thermal: exynos: remove redundant pdata checks from > >>> exynos_tmu_initialize() > >>> thermal: exynos: remove redundant threshold_code checks from > >>> exynos_tmu_initialize() > >>> thermal: exynos: simplify temp_to_code() and code_to_temp() > >>> thermal: exynos: cache non_hw_trigger_levels in pdata > >>> thermal: exynos: remove redundant pdata checks from > >>> exynos_tmu_control() > >>> thermal: exynos: remove identical values from exynos*_tmu_registers > >>> structures > >>> > >>> drivers/thermal/samsung/exynos_thermal_common.h | 1 - > >>> drivers/thermal/samsung/exynos_tmu.c| 126 > >>> +--- > >>> drivers/thermal/samsung/exynos_tmu.h| 74 +- > >>> drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- > >>> drivers/thermal/samsung/exynos_tmu_data.h | 31 +- > >>> 5 files changed, 35 insertions(+), 253 deletions(-) > >>> > >>> -- > >>> 1.8.2.3 > >>> > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in > >>> the body of a message to majord...@vger.kernel.org > >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > >> linux-samsung-soc" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: > On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: > > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: > > > >> This USB 3.0 PHY controller is also present on Exynos7 > >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > > > >> +++ b/drivers/phy/Kconfig > >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 > >> > >> config PHY_EXYNOS5_USBDRD > >> tristate "Exynos5 SoC series USB DRD PHY driver" > >> - depends on ARCH_EXYNOS5 && OF > >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > > > > shouldn't that prompt and its help text be updated to mention also Exynos7? > > Right, even that has to be updated accordingly. Will update the same in next > version of the patch. Thanks for pointing this. I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like that idea. The thing is that this will likely need to be patches for exynos8, 9, 10, 11... cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 04:09:08PM +0530, Vivek Gautam wrote: > Hi, > > > On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland wrote: > > On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote: > >> Exynos7 also has a separate special gate clock going to the IP > >> apart from the usual AHB clock. So add support for the same. > >> > >> Signed-off-by: Vivek Gautam > >> --- > >> drivers/usb/dwc3/dwc3-exynos.c | 16 > >> 1 file changed, 16 insertions(+) > >> > >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c > >> b/drivers/usb/dwc3/dwc3-exynos.c > >> index f9fb8ad..bab6395 100644 > >> --- a/drivers/usb/dwc3/dwc3-exynos.c > >> +++ b/drivers/usb/dwc3/dwc3-exynos.c > >> @@ -35,6 +35,7 @@ struct dwc3_exynos { > >> struct device *dev; > >> > >> struct clk *clk; > >> + struct clk *sclk; > >> struct regulator*vdd33; > >> struct regulator*vdd10; > >> }; > >> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device > >> *pdev) > >> return -EINVAL; > >> } > >> > >> + /* Exynos7 has a special gate clock going to this IP */ > >> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk"); > >> + if (IS_ERR(exynos->sclk)) > >> + dev_warn(dev, "couldn't get sclk\n"); > > > > Doesn't this introduce a pointless warning for Exynos SoCs other than > > Exynos7? > > True, it will introduce an unnecessary warning for non-Exynos7 systems. > I initially thought of introducing a compatible check for Exynos7-dwc3, but > that > way we may end up adding such checks for future SoCs which have similar > controller but have some clock difference or some other small change, no ? maybe dev_dbg() is what you want ? :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: > Adding phy calibrate callback, which facilitates setting certain > PHY settings post initialization of the PHY controller. > Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which > the Loss-of-Signal (LOS) Detector Threshold Level as well as > Tx-Vboost-Level should be controlled for Super-Speed operations. > > Additionally set proper time to wait for RxDetect measurement, > for desired PHY reference clock, so as to solve issue with enumeration > of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive > on the controller. > We are using CR_port for this purpose to send required data > to override the LOS values. > > On testing with USB 3.0 devices on USB 3.0 port present on > SMDK5420, and peach-pit boards should see following message: > usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd > > and without this patch, should see below shown message: > usb 1-1: new high-speed USB device number 2 using xhci-hcd > > [Also removed unnecessary extra lines in the register macro definitions] > > Signed-off-by: Vivek Gautam > --- > drivers/phy/phy-exynos5-usbdrd.c | 185 > ++ > 1 file changed, 170 insertions(+), 15 deletions(-) > > diff --git a/drivers/phy/phy-exynos5-usbdrd.c > b/drivers/phy/phy-exynos5-usbdrd.c > index 47f47fe..85742b0 100644 > --- a/drivers/phy/phy-exynos5-usbdrd.c > +++ b/drivers/phy/phy-exynos5-usbdrd.c > @@ -37,13 +37,11 @@ > > /* EXYNOS5: USB 3.0 DRD PHY registers */ > #define EXYNOS5_DRD_LINKSYSTEM 0x04 > - > #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) > #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) > #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) > > #define EXYNOS5_DRD_PHYUTMI 0x08 > - > #define PHYUTMI_OTGDISABLE BIT(6) > #define PHYUTMI_FORCESUSPEND BIT(1) > #define PHYUTMI_FORCESLEEP BIT(0) > @@ -51,26 +49,20 @@ > #define EXYNOS5_DRD_PHYPIPE 0x0c > > #define EXYNOS5_DRD_PHYCLKRST0x10 > - > #define PHYCLKRST_EN_UTMISUSPEND BIT(31) > - > #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) > #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) > - > #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) > #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) > - > #define PHYCLKRST_SSC_EN BIT(20) > #define PHYCLKRST_REF_SSP_EN BIT(19) > #define PHYCLKRST_REF_CLKDIV2BIT(18) > - > #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) > - > #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) > #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) > #define PHYCLKRST_FSEL(_x) ((_x) << 5) > @@ -78,46 +70,68 @@ > #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) > #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) > #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) > - > #define PHYCLKRST_RETENABLEN BIT(4) > - > #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) > #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) > #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) > - > #define PHYCLKRST_PORTRESET BIT(1) > #define PHYCLKRST_COMMONONN BIT(0) > > #define EXYNOS5_DRD_PHYREG0 0x14 > +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) > +#define PHYREG0_SSC_RANGEBIT(20) > +#define PHYREG0_CR_WRITE BIT(19) > +#define PHYREG0_CR_READ BIT(18) > +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) > +#define PHYREG0_CR_CAP_DATA BIT(1) > +#define PHYREG0_CR_CAP_ADDR BIT(0) > + > #define EXYNOS5_DRD_PHYREG1 0x18 > +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) > +#define PHYREG1_CR_ACK BIT(0) > > #define EXYNOS5_DRD_PHYPARAM00x1c > - > #define PHYPARAM0_REF_USE_PADBIT(31) > #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26) > #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) > > #define EXYNOS5_DRD_PHYPARAM10x20 > - > #define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0) > #define PHYPARAM1_PCS_TXDEEMPH (0x1c) > > #define EXYNOS5_DRD_PHYTERM 0x24 > > #define EX
Re: [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
On Tue, Sep 2, 2014 at 3:59 AM, Mike Turquette wrote: > Quoting Thomas Abraham (2014-07-30 01:07:38) >> The CPU clock provider supplies the clock to the CPU clock domain. The >> composition and organization of the CPU clock provider could vary among >> Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers >> and gates. This patch defines a new clock type for CPU clock provider and >> adds infrastructure to register the CPU clock providers for Samsung >> platforms. >> >> Signed-off-by: Thomas Abraham >> Reviewed-by: Tomasz Figa > > Acked-by: Mike Turquette Thank you Mike. Regards, Thomas. > >> --- >> drivers/clk/samsung/Makefile |2 +- >> drivers/clk/samsung/clk-cpu.c | 335 >> + >> drivers/clk/samsung/clk-cpu.h | 91 +++ >> 3 files changed, 427 insertions(+), 1 deletion(-) >> create mode 100644 drivers/clk/samsung/clk-cpu.c >> create mode 100644 drivers/clk/samsung/clk-cpu.h >> >> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile >> index 6fb4bc6..8909c93 100644 >> --- a/drivers/clk/samsung/Makefile >> +++ b/drivers/clk/samsung/Makefile >> @@ -2,7 +2,7 @@ >> # Samsung Clock specific Makefile >> # >> >> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o >> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o >> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o >> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o >> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o >> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c >> new file mode 100644 >> index 000..009a21b >> --- /dev/null >> +++ b/drivers/clk/samsung/clk-cpu.c >> @@ -0,0 +1,335 @@ >> +/* >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * Author: Thomas Abraham >> + * >> + * 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. >> + * >> + * This file contains the utility function to register CPU clock for Samsung >> + * Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or >> a >> + * group of CPUs. The CPU clock is typically derived from a hierarchy of >> clock >> + * blocks which includes mux and divider blocks. There are a number of other >> + * auxiliary clocks supplied to the CPU domain such as the debug blocks and >> AXI >> + * clock for CPU domain. The rates of these auxiliary clocks are related to >> the >> + * CPU clock rate and this relation is usually specified in the hardware >> manual >> + * of the SoC or supplied after the SoC characterization. >> + * >> + * The below implementation of the CPU clock allows the rate changes of the >> CPU >> + * clock and the corresponding rate changes of the auxillary clocks of the >> CPU >> + * domain. The platform clock driver provides a clock register configuration >> + * for each configurable rate which is then used to program the clock >> hardware >> + * registers to acheive a fast co-oridinated rate change for all the CPU >> domain >> + * clocks. >> + * >> + * On a rate change request for the CPU clock, the rate change is propagated >> + * upto the PLL supplying the clock to the CPU domain clock blocks. While >> the >> + * CPU domain PLL is reconfigured, the CPU domain clocks are driven using an >> + * alternate clock source. If required, the alternate clock source is >> divided >> + * down in order to keep the output clock rate within the previous OPP >> limits. >> +*/ >> + >> +#include >> +#include "clk-cpu.h" >> + >> +#define E4210_SRC_CPU 0x0 >> +#define E4210_STAT_CPU 0x200 >> +#define E4210_DIV_CPU0 0x300 >> +#define E4210_DIV_CPU1 0x304 >> +#define E4210_DIV_STAT_CPU00x400 >> +#define E4210_DIV_STAT_CPU10x404 >> + >> +#define E4210_DIV0_RATIO0_MASK 0x7 >> +#define E4210_DIV1_HPM_MASK(0x7 << 4) >> +#define E4210_DIV1_COPY_MASK (0x7 << 0) >> +#define E4210_MUX_HPM_MASK (1 << 20) >> +#define E4210_DIV0_ATB_SHIFT 16 >> +#define E4210_DIV0_ATB_MASK(DIV_MASK << E4210_DIV0_ATB_SHIFT) >> + >> +#define MAX_DIV8 >> +#define DIV_MASK 7 >> +#define DIV_MASK_ALL 0x >> +#define MUX_MASK 7 >> + >> +/* >> + * Helper function to wait until divider(s) have stabilized after the >> divider >> + * value has changed. >> + */ >> +static void wait_until_divider_stable(void __iomem *div_reg, unsigned long >> mask) >> +{ >> + unsigned long timeout = jiffies + msecs_to_jiffies(10); >> + >> + do { >> + if (!(readl(div_reg) & mask)) >> + return; >> + } while (time_before(jiffies, timeout)); >> + >> + pr_err("%s: timeout in divider stablization\n", __func__); >> +} >> + >> +/* >> + * Helper function to wait until mux has stabilized after the mux selection >> + * value was changed. >> + */ >> +static void wait
Re: [PATCH v2 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad
On 27/08/14 15:22, Javier Martinez Canillas wrote: >>> If there was a BTN_NONE or KEY_UNUSED it would had been better but I think >>> that making a distinction between these two cases (reserved pin vs GPIO >>> available but not used) is useful. >> >> Maybe Nick can comment here. Yes, this is probably useful to document. However, I fear that it's not going to be obvious what the distinction is to someone who doesn't have the Atmel docs. Perhaps it would be clearer to just do something like: linux,gpio-keymap = ; /* GPIO3 */ If you omit any trailing KEY_RESERVED values it doesn't affect anything. I was also going to suggest that you put something like "/* Atmel mXT224SL */" in your .dts file so it's clear what version of the maXTouch device you are configuring. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: dts: exynos3250: Add CMU node for DMC domain clocks
Add CMU (Clock Management Unit) node for DMC (Dynamic Memory Controller) domain clocks on Exynos3250. Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos3250.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi index 429a6c6cfcf9..8c3a9cc0a4d1 100644 --- a/arch/arm/boot/dts/exynos3250.dtsi +++ b/arch/arm/boot/dts/exynos3250.dtsi @@ -163,6 +163,12 @@ #clock-cells = <1>; }; + cmu_dmc: clock-controller@105C { + compatible = "samsung,exynos3250-cmu-dmc"; + reg = <0x105C 0x2000>; + #clock-cells = <1>; + }; + rtc: rtc@1007 { compatible = "samsung,exynos3250-rtc"; reg = <0x1007 0x100>; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU
Document the new compatible for clock in DMC (Dynamic Memory Controller) domain of Exynos3250 Clock Management Unit (CMU). Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/clock/exynos3250-clock.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt index aadc9c59e2d1..f57d9dd9ea85 100644 --- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt @@ -7,6 +7,8 @@ Required Properties: - compatible: should be one of the following. - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC. + - "samsung,exynos3250-cmu-dmc" - controller compatible with +Exynos3250 SoC for Dynamic Memory Controller domain. - reg: physical base address of the controller and length of memory mapped region. @@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in dt-bindings/clock/exynos3250.h header and can be used in device tree sources. -Example 1: An example of a clock controller node is listed below. +Example 1: Examples of clock controller nodes are listed below. cmu: clock-controller@1003 { compatible = "samsung,exynos3250-cmu"; @@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed below. #clock-cells = <1>; }; + cmu_dmc: clock-controller@105C { + compatible = "samsung,exynos3250-cmu-dmc"; + reg = <0x105C 0x2000>; + #clock-cells = <1>; + }; + Example 2: UART controller node that consumes the clock generated by the clock controller. Refer to the standard clock bindings for information about 'clocks' and 'clock-names' property. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] clk: samsung: exynos3250: Register DMC clk provider
Add clock provider for clocks in DMC domain including EPLL and BPLL. The DMC clocks are necessary for Exynos3 devfreq driver. The DMC clock domain uses different address space (0x105C) than standard clock domain (0x1003 - 0x1005). The difference is huge enough to add new DT node for the clock provider, rather than extending existing address space. Signed-off-by: Krzysztof Kozlowski --- Changes since v1: = 1. Fix overwritteing main clock provider reg_base with DMC clock domain reg_basr. This leads to OOPS in suspend. --- drivers/clk/samsung/clk-exynos3250.c | 195 + include/dt-bindings/clock/exynos3250.h | 27 + 2 files changed, 222 insertions(+) diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c index dc85f8e7a2d7..6840dc71c72b 100644 --- a/drivers/clk/samsung/clk-exynos3250.c +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -110,7 +110,14 @@ enum exynos3250_plls { nr_plls }; +/* list of PLLs in DMC block to be registered */ +enum exynos3250_dmc_plls { + bpll, epll, + nr_dmc_plls +}; + static void __iomem *reg_base; +static void __iomem *dmc_reg_base; /* * Support for CMU save/restore across system suspends @@ -724,6 +731,25 @@ static struct samsung_pll_rate_table exynos3250_pll_rates[] = { { /* sentinel */ } }; +/* EPLL */ +static struct samsung_pll_rate_table exynos3250_epll_rates[] = { + PLL_36XX_RATE(8, 200, 3, 1, 0), + PLL_36XX_RATE(28800, 96, 2, 2, 0), + PLL_36XX_RATE(19200, 128, 2, 3, 0), + PLL_36XX_RATE(14400, 96, 2, 3, 0), + PLL_36XX_RATE( 9600, 128, 2, 4, 0), + PLL_36XX_RATE( 8400, 112, 2, 4, 0), + PLL_36XX_RATE( 8004, 106, 2, 4, 43691), + PLL_36XX_RATE( 73728000, 98, 2, 4, 19923), + PLL_36XX_RATE( 67737598, 270, 3, 5, 62285), + PLL_36XX_RATE( 65535999, 174, 2, 5, 49982), + PLL_36XX_RATE( 5000, 200, 3, 5, 0), + PLL_36XX_RATE( 49152002, 131, 2, 5, 4719), + PLL_36XX_RATE( 4800, 128, 2, 5, 0), + PLL_36XX_RATE( 45158401, 180, 3, 5, 41524), + { /* sentinel */ } +}; + /* VPLL */ static struct samsung_pll_rate_table exynos3250_vpll_rates[] = { PLL_36XX_RATE(6, 100, 2, 1, 0), @@ -821,3 +847,172 @@ static void __init exynos3250_cmu_init(struct device_node *np) samsung_clk_of_add_provider(np, ctx); } CLK_OF_DECLARE(exynos3250_cmu, "samsung,exynos3250-cmu", exynos3250_cmu_init); + +/* + * CMU DMC + */ + +#define BPLL_LOCK 0x0118 +#define BPLL_CON0 0x0218 +#define BPLL_CON1 0x021c +#define BPLL_CON2 0x0220 +#define SRC_DMC0x0300 +#define DIV_DMC1 0x0504 +#define GATE_BUS_DMC0 0x0700 +#define GATE_BUS_DMC1 0x0704 +#define GATE_BUS_DMC2 0x0708 +#define GATE_BUS_DMC3 0x070c +#define GATE_SCLK_DMC 0x0800 +#define GATE_IP_DMC0 0x0900 +#define GATE_IP_DMC1 0x0904 +#define EPLL_LOCK 0x1110 +#define EPLL_CON0 0x1114 +#define EPLL_CON1 0x1118 +#define EPLL_CON2 0x111c +#define SRC_EPLL 0x1120 + +/* + * Support for CMU save/restore across system suspends + */ +#ifdef CONFIG_PM_SLEEP +static struct samsung_clk_reg_dump *exynos3250_dmc_clk_regs; + +static unsigned long exynos3250_cmu_dmc_clk_regs[] __initdata = { + BPLL_LOCK, + BPLL_CON0, + BPLL_CON1, + BPLL_CON2, + SRC_DMC, + DIV_DMC1, + GATE_BUS_DMC0, + GATE_BUS_DMC1, + GATE_BUS_DMC2, + GATE_BUS_DMC3, + GATE_SCLK_DMC, + GATE_IP_DMC0, + GATE_IP_DMC1, + EPLL_LOCK, + EPLL_CON0, + EPLL_CON1, + EPLL_CON2, + SRC_EPLL, +}; + +static int exynos3250_dmc_clk_suspend(void) +{ + samsung_clk_save(dmc_reg_base, exynos3250_dmc_clk_regs, + ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs)); + return 0; +} + +static void exynos3250_dmc_clk_resume(void) +{ + samsung_clk_restore(dmc_reg_base, exynos3250_dmc_clk_regs, + ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs)); +} + +static struct syscore_ops exynos3250_dmc_clk_syscore_ops = { + .suspend = exynos3250_dmc_clk_suspend, + .resume = exynos3250_dmc_clk_resume, +}; + +static void exynos3250_dmc_clk_sleep_init(void) +{ + exynos3250_dmc_clk_regs = + samsung_clk_alloc_reg_dump(exynos3250_cmu_dmc_clk_regs, + ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs)); + if (!exynos3250_dmc_clk_regs) { + pr_warn("%s: Failed to allocate sleep save data\n", __func__); + goto err; + } + + register_syscore_ops(&exynos3250_dmc_clk_syscore_ops); + return; +err: + kfree(exynos3250_dmc_clk_regs); +} +#else +static inli
[PATCH v11 11/19] irqchip: vic: Add support for FIQ management
This patch introduces callbacks to route interrupts to or away from the FIQ signal. It also causes these callbacks to be registered with the FIQ infrastructure. This patch enable FIQ support for mach-versatile whilst mach-ep93xx, mach-netx, mach-s3c64xx and plat-samsung are unmodified (and can therefore continue to use init_FIQ() as before). Signed-off-by: Daniel Thompson Cc: Hartley Sweeten Cc: Ryan Mallon Cc: Russell King Cc: Ben Dooks Cc: Kukjin Kim Cc: Thomas Gleixner Cc: Jason Cooper Cc: linux-samsung-soc@vger.kernel.org --- arch/arm/mach-versatile/core.c | 2 +- drivers/irqchip/irq-gic.c | 21 -- drivers/irqchip/irq-vic.c | 92 - include/linux/irqchip/arm-gic.h | 3 ++ include/linux/irqchip/arm-vic.h | 6 ++- 5 files changed, 88 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c index 08fb8c8..bad1d30 100644 --- a/arch/arm/mach-versatile/core.c +++ b/arch/arm/mach-versatile/core.c @@ -108,7 +108,7 @@ void __init versatile_init_irq(void) np = of_find_matching_node_by_address(NULL, vic_of_match, VERSATILE_VIC_BASE); - __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np); + __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np ? false : true, np); writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR); diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index bda5a91..8821160 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data *gic, /* * Fully acknowledge (both ack and eoi) a FIQ-based IPI */ -static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs, - void *data) +void gic_handle_fiq_ipi(void) { struct gic_chip_data *gic = &gic_data[0]; - void __iomem *cpu_base = gic_data_cpu_base(gic); + void __iomem *cpu_base; unsigned long irqstat, irqnr; + if (!gic || !gic->fiq_enable) + return; + + cpu_base = gic_data_cpu_base(gic); + if (WARN_ON(!in_nmi())) return NOTIFY_BAD; @@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs, return NOTIFY_OK; } - -/* - * Notifier to ensure IPI FIQ is acknowledged correctly. - */ -static struct notifier_block gic_fiq_ipi_notifier = { - .notifier_call = gic_handle_fiq_ipi, -}; #else /* CONFIG_FIQ */ static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq, int group) {} @@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, #ifdef CONFIG_SMP set_smp_cross_call(gic_raise_softirq); register_cpu_notifier(&gic_cpu_notifier); -#ifdef CONFIG_FIQ - if (gic_data_fiq_enable(gic)) - register_fiq_nmi_notifier(&gic_fiq_ipi_notifier); -#endif #endif set_handle_irq(gic_handle_irq); } diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c index 7d35287..22aa126 100644 --- a/drivers/irqchip/irq-vic.c +++ b/drivers/irqchip/irq-vic.c @@ -36,6 +36,9 @@ #include #include +#ifdef CONFIG_FIQ +#include +#endif #include "irqchip.h" @@ -261,11 +264,53 @@ static struct irq_domain_ops vic_irqdomain_ops = { .xlate = irq_domain_xlate_onetwocell, }; +#ifdef CONFIG_FIQ +static DEFINE_RAW_SPINLOCK(irq_controller_lock); + +static void vic_set_fiq(struct irq_data *d, bool enable) +{ + void __iomem *base = irq_data_get_irq_chip_data(d); + unsigned int irq = d->hwirq; + u32 val; + + raw_spin_lock(&irq_controller_lock); + val = readl(base + VIC_INT_SELECT); + if (enable) + val |= 1 << irq; + else + val &= ~(1 << irq); + writel(val, base + VIC_INT_SELECT); + raw_spin_unlock(&irq_controller_lock); +} + +static void vic_enable_fiq(struct irq_data *d) +{ + vic_set_fiq(d, true); +} + +static void vic_disable_fiq(struct irq_data *d) +{ + vic_set_fiq(d, false); +} + +struct fiq_chip vic_fiq = { + .fiq_enable = vic_enable_fiq, + .fiq_disable = vic_disable_fiq, +}; + +static void vic_register_fiq(int irq) +{ + fiq_register_mapping(irq, &vic_fiq); +} +#else /* CONFIG_FIQ */ +static inline void vic_register_fiq(int irq) {} +#endif /* CONFIG_FIQ */ + /** * vic_register() - Register a VIC. * @base: The base address of the VIC. * @parent_irq: The parent IRQ if cascaded, else 0. - * @irq: The base IRQ for the VIC. + * @irq_start: The base IRQ for the VIC. * @valid_sources: bitmask of valid interrupts * @resume_sources: bitmask of interrupts allowed for resume sources. * @node: The device tree node associated with the VIC. @@ -277,12 +322,13 @@ static struct irq_domain_ops vic_irqdomain_ops = {
[PATCH v3 16/17] drm/exynos/ipp: remove file argument from node related functions
Since file pointer is preserved in c_node passing it as argument in node functions is redundant. Signed-off-by: Andrzej Hajda --- v3: - file check moved to next patch --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index 05f0f4e..9e9714a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev, static struct drm_exynos_ipp_mem_node *ipp_get_mem_node(struct drm_device *drm_dev, - struct drm_file *file, struct drm_exynos_ipp_cmd_node *c_node, struct drm_exynos_ipp_queue_buf *qbuf) { @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node dma_addr_t *addr; addr = exynos_drm_gem_get_dma_addr(drm_dev, - qbuf->handle[i], file); + qbuf->handle[i], c_node->filp); if (IS_ERR(addr)) { DRM_ERROR("failed to get addr.\n"); ipp_put_mem_node(drm_dev, c_node, m_node); @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event *event) } static int ipp_get_event(struct drm_device *drm_dev, - struct drm_file *file, struct drm_exynos_ipp_cmd_node *c_node, struct drm_exynos_ipp_queue_buf *qbuf) { @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev, e = kzalloc(sizeof(*e), GFP_KERNEL); if (!e) { spin_lock_irqsave(&drm_dev->event_lock, flags); - file->event_space += sizeof(e->event); + c_node->filp->event_space += sizeof(e->event); spin_unlock_irqrestore(&drm_dev->event_lock, flags); return -ENOMEM; } @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev, e->event.prop_id = qbuf->prop_id; e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id; e->base.event = &e->event.base; - e->base.file_priv = file; + e->base.file_priv = c_node->filp; e->base.destroy = ipp_free_event; mutex_lock(&c_node->event_lock); list_add_tail(&e->base.link, &c_node->event_list); @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data, switch (qbuf->buf_type) { case IPP_BUF_ENQUEUE: /* get memory node */ - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf); + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf); if (IS_ERR(m_node)) { DRM_ERROR("failed to get m_node.\n"); return PTR_ERR(m_node); @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data, */ if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) { /* get event for destination buffer */ - ret = ipp_get_event(drm_dev, file, c_node, qbuf); + ret = ipp_get_event(drm_dev, c_node, qbuf); if (ret) { DRM_ERROR("failed to get event.\n"); goto err_clean_node; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 17/17] drm/exynos/ipp: add file checks for ioctls
Process should not have access to ipp nodes created by another process. The patch adds necessary checks. It also simplifies lookup for command node. Signed-off-by: Andrzej Hajda --- v3: - added file check from previous commit - simplified c_node lookup --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 69 +++-- 1 file changed, 22 insertions(+), 47 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index 9e9714a..4f36a9d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -318,44 +318,6 @@ static void ipp_print_property(struct drm_exynos_ipp_property *property, sz->hsize, sz->vsize, config->flip, config->degree); } -static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property) -{ - struct exynos_drm_ippdrv *ippdrv; - struct drm_exynos_ipp_cmd_node *c_node; - u32 prop_id = property->prop_id; - - DRM_DEBUG_KMS("prop_id[%d]\n", prop_id); - - ippdrv = ipp_find_drv_by_handle(prop_id); - if (IS_ERR(ippdrv)) { - DRM_ERROR("failed to get ipp driver.\n"); - return -EINVAL; - } - - /* -* Find command node using command list in ippdrv. -* when we find this command no using prop_id. -* return property information set in this command node. -*/ - mutex_lock(&ippdrv->cmd_lock); - list_for_each_entry(c_node, &ippdrv->cmd_list, list) { - if ((c_node->property.prop_id == prop_id) && - (c_node->state == IPP_STATE_STOP)) { - mutex_unlock(&ippdrv->cmd_lock); - DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n", - property->cmd, (int)ippdrv); - - c_node->property = *property; - return 0; - } - } - mutex_unlock(&ippdrv->cmd_lock); - - DRM_ERROR("failed to search property.\n"); - - return -EINVAL; -} - static struct drm_exynos_ipp_cmd_work *ipp_create_cmd_work(void) { struct drm_exynos_ipp_cmd_work *cmd_work; @@ -391,6 +353,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, void *data, struct drm_exynos_ipp_property *property = data; struct exynos_drm_ippdrv *ippdrv; struct drm_exynos_ipp_cmd_node *c_node; + u32 prop_id; int ret, i; if (!ctx) { @@ -403,6 +366,8 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, void *data, return -EINVAL; } + prop_id = property->prop_id; + /* * This is log print for user application property. * user application set various property. @@ -411,14 +376,24 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, void *data, ipp_print_property(property, i); /* -* set property ioctl generated new prop_id. -* but in this case already asigned prop_id using old set property. -* e.g PAUSE state. this case supports find current prop_id and use it -* instead of allocation. +* In case prop_id is not zero try to set existing property. */ - if (property->prop_id) { - DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id); - return ipp_find_and_set_property(property); + if (prop_id) { + c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock, prop_id); + + if (!c_node || c_node->filp != file) { + DRM_DEBUG_KMS("prop_id[%d] not found\n", prop_id); + return -EINVAL; + } + + if (c_node->state != IPP_STATE_STOP) { + DRM_DEBUG_KMS("prop_id[%d] not stopped\n", prop_id); + return -EINVAL; + } + + c_node->property = *property; + + return 0; } /* find ipp driver using ipp id */ @@ -897,7 +872,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data, /* find command node */ c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock, qbuf->prop_id); - if (!c_node) { + if (!c_node || c_node->filp != file) { DRM_ERROR("failed to get command node.\n"); return -ENODEV; } @@ -1032,7 +1007,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, void *data, c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock, cmd_ctrl->prop_id); - if (!c_node) { + if (!c_node || c_node->filp != file) { DRM_ERROR("invalid command node list.\n"); return -ENODEV; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/
Re: [PATCH 05/14] pinctrl: exynos: Add driver data for Exynos7
Hi Linus, On 02.09.2014 14:38, Linus Walleij wrote: > On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi > wrote: > >> This patch adds driver data for Exynos7 >> to pinctrl-exynos driver. Exynos7 includes 229 multi-functional >> input/output ports. There are 40 general port groups. >> >> Signed-off-by: Naveen Krishna Chatradhi >> Cc: Tomasz Figa >> Cc: linus.wall...@linaro.org >> Cc: Thomas Abraham > > Tomasz can you have a look at this (from your private mail...)? Sure. In fact I already took a look last week, and this patch in particular looks good. However I'm waiting for replies to my other comments in this thread, as some of them affect also this patch. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] pinctrl: exynos: Add driver data for Exynos7
On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi wrote: > This patch adds driver data for Exynos7 > to pinctrl-exynos driver. Exynos7 includes 229 multi-functional > input/output ports. There are 40 general port groups. > > Signed-off-by: Naveen Krishna Chatradhi > Cc: Tomasz Figa > Cc: linus.wall...@linaro.org > Cc: Thomas Abraham Tomasz can you have a look at this (from your private mail...)? 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
[PATCH v6 0/4] Fine tune USB 3.0 PHY on exynos5420
This series is based on Heikki's patches for simpliefied phy lookup table: [PATCHv3 0/6] phy: simplified phy lookup [1], applied against 'usb-next' branch alongwith Sergei's patch for adding generic phy support to usb hcd [2]. NOTE: We need to get above dependencies merged first in order to merge this series. As of now patches @ [1] are posted with all the comments addressed and we are waiting for an ACK on them, but patch @ [2] needs to be re-spined as Sergie says in [3]: "Yes, I'm planning this since Greg has lost v4." Changes since v5: - Assigned NULL to hcd->gen_phy in error path in xhci-plat.c, so that we don't need to check for IS_ERR() while calibrating the PHYs in core/hcd.c - Removed extra empty lines in register definitions in exynos5-usbdrd phy driver. - Added write access for EXYNOS5_DRD_PHYREG0 register before any crport_handshake() call as suggested by Jingoo Han. - Renamed member 'calibrate' to 'phy_exynos_calibrate' of struct exynos5_usbdrd_phy_drvdata. Changes since v4: - Rebased on latest patches by Heikki. - Took care of handling -EPROBE_DEFER error number while getting PHY in xhci plat. Changes from v3: - Modified error message as per review comments from Julius. Changes since v2: - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy, in order to make it more generic. - Moved the phy_calibration calls to core/hcd.c to enable a more generic solution for issues of calibrating the PHYs. Changes since v1: - Using 'gen_phy' member of 'hcd' instead of declaring more variables to hold phys. - Added a check for compatible match for 'Synopsys-dwc3' controller, since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that, instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs (main hcd and shared hcd). - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()' to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3 controller while trying to calibrate the PHY. Explanation for the need of this patch-series: "The DWC3-exynos eXtensible host controller present on Exynos5420/5800 SoCs is quirky. The PHY serving this controller operates at High-Speed by default, so it detects even Super-speed devices as high-speed ones. Certain PHY parameters like Tx LOS levels and Boost levels need to be calibrated further post initialization of xHCI controller, to get SuperSpeed operations working." [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html [2] http://comments.gmane.org/gmane.linux.ports.sh.devel/35932 [3] http://www.spinics.net/lists/linux-usb/msg112300.html Vivek Gautam (4): phy: Add provision for calibrating phy. usb: host: xhci-plat: Get PHYs for xhci's hcds usb: hcd: Calibrate PHY post hcd reset phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 drivers/phy/phy-core.c | 36 drivers/phy/phy-exynos5-usbdrd.c | 185 ++ drivers/usb/core/hcd.c | 18 drivers/usb/host/xhci-plat.c | 27 ++ include/linux/phy/phy.h |8 ++ 5 files changed, 259 insertions(+), 15 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK (0x3f << 1) #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) #define EXYNOS5_DRD_PHYUTMI0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE0x0c #define EXYNOS5_DRD_PHYCLKRST 0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2 BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) #define PHYCLKRST_FSEL(_x) ((_x) << 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) - #define PHYCLKRST_PORTRESETBIT(1) #define PHYCLKRST_COMMONONNBIT(0) #define EXYNOS5_DRD_PHYREG00x14 +#define PHYREG0_SSC_REF_CLK_SELBIT(21) +#define PHYREG0_SSC_RANGE BIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READBIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) +#define PHYREG0_CR_CAP_DATABIT(1) +#define PHYREG0_CR_CAP_ADDRBIT(0) + #define EXYNOS5_DRD_PHYREG10x18 +#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM0 0x1c - #define PHYPARAM0_REF_USE_PAD BIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) #define EXYNOS5_DRD_PHYPARAM1 0x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM0x24 #define EXYNOS5_DRD_PHYTEST0x28 - #define PHYTEST_POWERDOWN_SSP BIT(3) #define PHYTEST_POWERDOWN_HSP BIT(2) #define EXYNOS5_DRD_PHYADP 0x2c #define EXYNOS5_DRD_PHYUTMICLKSEL 0x30 - #define PHYUTMICLKSEL_UTMI_CLKSEL
[PATCH v6 3/4] usb: hcd: Calibrate PHY post hcd reset
Some quirky PHYs may require to be calibrated post the hcd initialization. The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along with Synopsys's DWC3 controller, is one such PHY which needs to be calibrated post xhci's reset at initialization time and at resume time, to get the controller work at SuperSpeed. So facilitating the HCDs to calibrate the PHY. Signed-off-by: Vivek Gautam --- drivers/usb/core/hcd.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index c4ed66c..6e01d09 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2202,6 +2202,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg) struct usb_hcd *hcd = container_of(rhdev->bus, struct usb_hcd, self); int status; int old_state = hcd->state; + int ret; dev_dbg(&rhdev->dev, "usb %sresume\n", (PMSG_IS_AUTO(msg) ? "auto-" : "")); @@ -2216,6 +2217,15 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg) hcd->state = HC_STATE_RESUMING; status = hcd->driver->bus_resume(hcd); + + /* calibrate the phy here */ + ret = phy_calibrate(hcd->gen_phy); + if (ret < 0 && ret != -ENOTSUPP) { + dev_err(hcd->self.controller, + "failed to calibrate USB PHY\n"); + return ret; + } + clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); if (status == 0) { struct usb_device *udev; @@ -2738,6 +2748,14 @@ int usb_add_hcd(struct usb_hcd *hcd, } hcd->rh_pollable = 1; + /* calibrate the phy here */ + retval = phy_calibrate(hcd->gen_phy); + if (retval < 0 && retval != -ENOTSUPP) { + dev_err(hcd->self.controller, + "failed to calibrate USB PHY\n"); + return retval; + } + /* NOTE: root hub and controller capabilities may not be the same */ if (device_can_wakeup(hcd->self.controller) && device_can_wakeup(&hcd->self.root_hub->dev)) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY and/or calibrate some of the PHY settings to get full support out of the PHY controller. The PHY core provides a calibration funtionality now to do so. Therefore, facilitate getting the two possible PHYs, viz. USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3). Signed-off-by: Vivek Gautam --- drivers/usb/host/xhci-plat.c | 27 +++ 1 file changed, 27 insertions(+) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 1a0cf9f..6afd508 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -180,6 +181,19 @@ static int xhci_plat_probe(struct platform_device *pdev) goto put_hcd; } + /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */ + hcd->gen_phy = devm_phy_get(&pdev->dev, "usb2-phy"); + if (IS_ERR(hcd->gen_phy)) { + ret = PTR_ERR(hcd->gen_phy); + if (ret == -EPROBE_DEFER) { + return ret; + } else if (ret != -ENOSYS && ret != -ENODEV) { + hcd->gen_phy = NULL; + dev_warn(&pdev->dev, +"Error retrieving usb2 phy: %d\n", ret); + } + } + ret = usb_add_hcd(hcd, irq, IRQF_SHARED); if (ret) goto disable_clk; @@ -209,6 +223,19 @@ static int xhci_plat_probe(struct platform_device *pdev) if (HCC_MAX_PSA(xhci->hcc_params) >= 4) xhci->shared_hcd->can_do_streams = 1; + /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */ + xhci->shared_hcd->gen_phy = devm_phy_get(&pdev->dev, "usb3-phy"); + if (IS_ERR(xhci->shared_hcd->gen_phy)) { + ret = PTR_ERR(xhci->shared_hcd->gen_phy); + if (ret == -EPROBE_DEFER) { + return ret; + } else if (ret != -ENOSYS && ret != -ENODEV) { + xhci->shared_hcd->gen_phy = NULL; + dev_warn(&pdev->dev, +"Error retrieving usb3 phy: %d\n", ret); + } + } + ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); if (ret) goto put_usb3_hcd; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/4] phy: Add provision for calibrating phy.
Some PHY controllers may need to calibrate certain PHY settings after initialization of the controller and sometimes even after initializing the PHY-consumer too. Add support for the same in order to let consumers do so in need. Signed-off-by: vivek Gautam --- drivers/phy/phy-core.c | 36 include/linux/phy/phy.h |8 2 files changed, 44 insertions(+) diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c index 834b337..c8cb3de 100644 --- a/drivers/phy/phy-core.c +++ b/drivers/phy/phy-core.c @@ -393,6 +393,42 @@ int phy_power_off(struct phy *phy) EXPORT_SYMBOL_GPL(phy_power_off); /** + * phy_calibrate - calibrate a phy post initialization + * @phy: Pointer to 'phy' from consumer + * + * For certain PHYs, it may be needed to calibrate few phy parameters + * post initialization. The need to calibrate may arise after the + * initialization of consumer itself, in order to prevent further any + * loss of phy settings post consumer-initialization. + * example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such + * phy which needs calibration after the host controller reset + * has happened. + */ +int phy_calibrate(struct phy *phy) +{ + int ret = -ENOTSUPP; + + if (!phy) + return 0; + + mutex_lock(&phy->mutex); + if (phy->ops->calibrate) { + ret = phy->ops->calibrate(phy); + if (ret < 0) { + dev_err(&phy->dev, + "phy calibration failed --> %d\n", ret); + goto out; + } + } + +out: + mutex_unlock(&phy->mutex); + + return ret; +} +EXPORT_SYMBOL_GPL(phy_calibrate); + +/** * _of_phy_get() - lookup and obtain a reference to a phy by phandle * @np: device_node for which to get the phy * @index: the index of the phy diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index d983051..c70a311 100644 --- a/include/linux/phy/phy.h +++ b/include/linux/phy/phy.h @@ -28,6 +28,7 @@ struct phy; * @exit: operation to be performed while exiting * @power_on: powering on the phy * @power_off: powering off the phy + * @calibrate: calibrate the phy post init * @owner: the module owner containing the ops */ struct phy_ops { @@ -35,6 +36,7 @@ struct phy_ops { int (*exit)(struct phy *phy); int (*power_on)(struct phy *phy); int (*power_off)(struct phy *phy); + int (*calibrate)(struct phy *phy); struct module *owner; }; @@ -126,6 +128,7 @@ int phy_init(struct phy *phy); int phy_exit(struct phy *phy); int phy_power_on(struct phy *phy); int phy_power_off(struct phy *phy); +int phy_calibrate(struct phy *phy); static inline int phy_get_bus_width(struct phy *phy) { return phy->attrs.bus_width; @@ -231,6 +234,11 @@ static inline int phy_power_off(struct phy *phy) return -ENOSYS; } +static inline int phy_calibrate(struct phy *phy) +{ + return -ENOSYS; +} + static inline int phy_get_bus_width(struct phy *phy) { return -ENOSYS; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 11:39:08AM +0100, Vivek Gautam wrote: > Hi, > > > On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland wrote: > > On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote: > >> Exynos7 also has a separate special gate clock going to the IP > >> apart from the usual AHB clock. So add support for the same. > >> > >> Signed-off-by: Vivek Gautam > >> --- > >> drivers/usb/dwc3/dwc3-exynos.c | 16 > >> 1 file changed, 16 insertions(+) > >> > >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c > >> b/drivers/usb/dwc3/dwc3-exynos.c > >> index f9fb8ad..bab6395 100644 > >> --- a/drivers/usb/dwc3/dwc3-exynos.c > >> +++ b/drivers/usb/dwc3/dwc3-exynos.c > >> @@ -35,6 +35,7 @@ struct dwc3_exynos { > >> struct device *dev; > >> > >> struct clk *clk; > >> + struct clk *sclk; > >> struct regulator*vdd33; > >> struct regulator*vdd10; > >> }; > >> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device > >> *pdev) > >> return -EINVAL; > >> } > >> > >> + /* Exynos7 has a special gate clock going to this IP */ > >> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk"); > >> + if (IS_ERR(exynos->sclk)) > >> + dev_warn(dev, "couldn't get sclk\n"); > > > > Doesn't this introduce a pointless warning for Exynos SoCs other than > > Exynos7? > > True, it will introduce an unnecessary warning for non-Exynos7 systems. > I initially thought of introducing a compatible check for Exynos7-dwc3, but > that > way we may end up adding such checks for future SoCs which have similar > controller but have some clock difference or some other small change, no ? Perhaps. I don't know what your future hardware will look like. Is the usbdrd30_sclk input unique to Exynos7, or was it previously there but just without an input? If the latter you could just reduce this to: dev_info(dev, "no sclk specified"); Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Hi, On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland wrote: > On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote: >> Exynos7 also has a separate special gate clock going to the IP >> apart from the usual AHB clock. So add support for the same. >> >> Signed-off-by: Vivek Gautam >> --- >> drivers/usb/dwc3/dwc3-exynos.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c >> index f9fb8ad..bab6395 100644 >> --- a/drivers/usb/dwc3/dwc3-exynos.c >> +++ b/drivers/usb/dwc3/dwc3-exynos.c >> @@ -35,6 +35,7 @@ struct dwc3_exynos { >> struct device *dev; >> >> struct clk *clk; >> + struct clk *sclk; >> struct regulator*vdd33; >> struct regulator*vdd10; >> }; >> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device >> *pdev) >> return -EINVAL; >> } >> >> + /* Exynos7 has a special gate clock going to this IP */ >> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk"); >> + if (IS_ERR(exynos->sclk)) >> + dev_warn(dev, "couldn't get sclk\n"); > > Doesn't this introduce a pointless warning for Exynos SoCs other than > Exynos7? True, it will introduce an unnecessary warning for non-Exynos7 systems. I initially thought of introducing a compatible check for Exynos7-dwc3, but that way we may end up adding such checks for future SoCs which have similar controller but have some clock difference or some other small change, no ? > >> + >> exynos->dev = dev; >> exynos->clk = clk; >> >> clk_prepare_enable(exynos->clk); >> + if (!IS_ERR(exynos->sclk)) >> + clk_prepare_enable(exynos->sclk); > > If you replaced the returned err value with NULL you could avoid these > IS_ERR cases. Right, point taken. [snip] -- Best Regards Vivek Gautam Samsung R&D 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] mfd: syscon: Decouple syscon interface from syscon devices
On Tue, 02 Sep 2014, Arnd Bergmann wrote: > On Tuesday 02 September 2014 09:05:16 Lee Jones wrote: > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > > > On Monday 01 September 2014 17:04:26 Lee Jones wrote: > > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > > > Maybe I'm misreading the patch, but I don't see how it creates a > > > > > migration path. What I want to end up with is infrastructure that > > > > > lets anybody call syscon_regmap_lookup_by_pdevname or > > > > > syscon_regmap_lookup_by_compatible (if they really need to) > > > > > without needing the platform_driver for syscon. That should not > > > > > require any form of compatibility layer because to the driver > > > > > using it there is no API change. > > > > > > > > Somehow I think the likelyhood is that I am misreading the patch. > > > > > > > > I thought that before this patch drivers we had to register a syscon > > > > device to bind to this driver, which was fine for the first use-cases > > > > of syscon as it wasn't required too early during boot. However, now > > > > there are use-cases where systems require access to syscon registers > > > > eariler in boot we require a means to obtain access prior to device > > > > probing. I thought this patch not only provides that possibilty, but > > > > also leaves in the ability to register direct from DT. > > > > > > Right, it does provide the ability to have syscon before devices > > > are registered, I missed that part. > > > > > > > > In contrast, this patch introduces a new of_syscon_{un,}register() > > > > > interface that would get removed after the the above has > > > > > been implemented, causing extra churn for any driver that also > > > > > wants to provide a regmap-like interface. > > > > > > > > When will we ever not have to register syscon? > > > > > > The idea is that we implicitly register the syscon block when someone > > > calls syscon_regmap_lookup_by_compatible or > > > syscon_regmap_lookup_by_phandle > > > and then return a reference to that new syscon. When another driver > > > looks up the same device node, we just pass a reference to the existing > > > syscon. > > > > Doesn't sound too unreasonable. So how about instead of exporting > > these new of_syscon_{un,}register() calls, we make them static and > > call them from syscon_regmap_lookup_by_{phandle,compatible}? > > Yes, that would be a good start. We should think about whether we want > to remove the existing DT probing at the same time, since it becomes > unused, and we might want to move the code to drivers/base/regmap_*.c > at some point I'd support that move - and can even draft the patch if required. -- 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] mfd: syscon: Decouple syscon interface from syscon devices
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Tuesday, September 02, 2014 1:45 PM > To: linux-arm-ker...@lists.infradead.org > Cc: Lee Jones; kgene@samsung.com; li...@arm.linux.org.uk; > naus...@samsung.com; Pankaj Dubey; Tomasz Figa; linux-ker...@vger.kernel.org; > jo...@samsung.com; vikas.saj...@samsung.com; linux-samsung- > s...@vger.kernel.org; broo...@kernel.org; thomas...@samsung.com; > chow@samsung.com > Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices > > On Tuesday 02 September 2014 09:05:16 Lee Jones wrote: > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > > > On Monday 01 September 2014 17:04:26 Lee Jones wrote: > > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > > > Maybe I'm misreading the patch, but I don't see how it creates a > > > > > migration path. What I want to end up with is infrastructure > > > > > that lets anybody call syscon_regmap_lookup_by_pdevname or > > > > > syscon_regmap_lookup_by_compatible (if they really need to) > > > > > without needing the platform_driver for syscon. That should not > > > > > require any form of compatibility layer because to the driver > > > > > using it there is no API change. > > > > > > > > Somehow I think the likelyhood is that I am misreading the patch. > > > > > > > > I thought that before this patch drivers we had to register a > > > > syscon device to bind to this driver, which was fine for the first > > > > use-cases of syscon as it wasn't required too early during boot. > > > > However, now there are use-cases where systems require access to > > > > syscon registers eariler in boot we require a means to obtain > > > > access prior to device probing. I thought this patch not only > > > > provides that possibilty, but also leaves in the ability to register direct from > DT. > > > > > > Right, it does provide the ability to have syscon before devices are > > > registered, I missed that part. > > > > > > > > In contrast, this patch introduces a new > > > > > of_syscon_{un,}register() interface that would get removed after > > > > > the the above has been implemented, causing extra churn for any > > > > > driver that also wants to provide a regmap-like interface. > > > > > > > > When will we ever not have to register syscon? > > > > > > The idea is that we implicitly register the syscon block when > > > someone calls syscon_regmap_lookup_by_compatible or > > > syscon_regmap_lookup_by_phandle and then return a reference to that > > > new syscon. When another driver looks up the same device node, we > > > just pass a reference to the existing syscon. > > > > Doesn't sound too unreasonable. So how about instead of exporting > > these new of_syscon_{un,}register() calls, we make them static and > > call them from syscon_regmap_lookup_by_{phandle,compatible}? > > Yes, that would be a good start. We should think about whether we want to remove > the existing DT probing at the same time, since it becomes unused, and we might > want to move the code to drivers/base/regmap_*.c at some point. > OK, I am working on these two parts. Once code is in proper form and tested on our setup I will post here. Thanks, Pankaj > 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] mfd: syscon: Decouple syscon interface from syscon devices
On Tuesday 02 September 2014 09:05:16 Lee Jones wrote: > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > On Monday 01 September 2014 17:04:26 Lee Jones wrote: > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > > Maybe I'm misreading the patch, but I don't see how it creates a > > > > migration path. What I want to end up with is infrastructure that > > > > lets anybody call syscon_regmap_lookup_by_pdevname or > > > > syscon_regmap_lookup_by_compatible (if they really need to) > > > > without needing the platform_driver for syscon. That should not > > > > require any form of compatibility layer because to the driver > > > > using it there is no API change. > > > > > > Somehow I think the likelyhood is that I am misreading the patch. > > > > > > I thought that before this patch drivers we had to register a syscon > > > device to bind to this driver, which was fine for the first use-cases > > > of syscon as it wasn't required too early during boot. However, now > > > there are use-cases where systems require access to syscon registers > > > eariler in boot we require a means to obtain access prior to device > > > probing. I thought this patch not only provides that possibilty, but > > > also leaves in the ability to register direct from DT. > > > > Right, it does provide the ability to have syscon before devices > > are registered, I missed that part. > > > > > > In contrast, this patch introduces a new of_syscon_{un,}register() > > > > interface that would get removed after the the above has > > > > been implemented, causing extra churn for any driver that also > > > > wants to provide a regmap-like interface. > > > > > > When will we ever not have to register syscon? > > > > The idea is that we implicitly register the syscon block when someone > > calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle > > and then return a reference to that new syscon. When another driver > > looks up the same device node, we just pass a reference to the existing > > syscon. > > Doesn't sound too unreasonable. So how about instead of exporting > these new of_syscon_{un,}register() calls, we make them static and > call them from syscon_regmap_lookup_by_{phandle,compatible}? Yes, that would be a good start. We should think about whether we want to remove the existing DT probing at the same time, since it becomes unused, and we might want to move the code to drivers/base/regmap_*.c at some point. 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] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote: > On Monday 01 September 2014 17:04:26 Lee Jones wrote: > > On Mon, 01 Sep 2014, Arnd Bergmann wrote: > > > Maybe I'm misreading the patch, but I don't see how it creates a > > > migration path. What I want to end up with is infrastructure that > > > lets anybody call syscon_regmap_lookup_by_pdevname or > > > syscon_regmap_lookup_by_compatible (if they really need to) > > > without needing the platform_driver for syscon. That should not > > > require any form of compatibility layer because to the driver > > > using it there is no API change. > > > > Somehow I think the likelyhood is that I am misreading the patch. > > > > I thought that before this patch drivers we had to register a syscon > > device to bind to this driver, which was fine for the first use-cases > > of syscon as it wasn't required too early during boot. However, now > > there are use-cases where systems require access to syscon registers > > eariler in boot we require a means to obtain access prior to device > > probing. I thought this patch not only provides that possibilty, but > > also leaves in the ability to register direct from DT. > > Right, it does provide the ability to have syscon before devices > are registered, I missed that part. > > > > In contrast, this patch introduces a new of_syscon_{un,}register() > > > interface that would get removed after the the above has > > > been implemented, causing extra churn for any driver that also > > > wants to provide a regmap-like interface. > > > > When will we ever not have to register syscon? > > The idea is that we implicitly register the syscon block when someone > calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle > and then return a reference to that new syscon. When another driver > looks up the same device node, we just pass a reference to the existing > syscon. Doesn't sound too unreasonable. So how about instead of exporting these new of_syscon_{un,}register() calls, we make them static and call them from syscon_regmap_lookup_by_{phandle,compatible}? -- 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