Re: [PATCH 1/4] cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver
Hi Daniel, On 22 April 2014 16:12, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 04/21/2014 01:49 PM, Chander Kashyap wrote: Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores. In order to use generic cpuidle-big-little driver, this patch adds Exynos5420 specific check to initialize generic cpuidle driver. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com --- drivers/cpuidle/Kconfig.arm |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm index 97ccc31..5244d87 100644 --- a/drivers/cpuidle/Kconfig.arm +++ b/drivers/cpuidle/Kconfig.arm @@ -4,7 +4,7 @@ config ARM_BIG_LITTLE_CPUIDLE bool Support for ARM big.LITTLE processors - depends on ARCH_VEXPRESS_TC2_PM + depends on ARCH_VEXPRESS_TC2_PM || SOC_EXYNOS5420 For the sake of consistency, I would prefer: depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS Yes i will change it. Thanks and let the current code (and future platform driver) to handle the loading of the driver. select ARM_CPU_SUSPEND select CPU_IDLE_MULTIPLE_DRIVERS help -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line unsubscribe linux-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] mmc: dw_mmc: exynos: Turn SDIO interrupts on
On Wed, Apr 23, 2014 at 9:42 AM, Alim Akhtar alim.akh...@gmail.com wrote: Hi Yuvaraj, On Mon, Mar 24, 2014 at 10:12 AM, Yuvaraj Kumar yuvaraj...@gmail.com wrote: On Mon, Mar 24, 2014 at 9:59 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Yuvaraj. NACK. we can use mmc_of_parese(). Thanks Jaehoon for the pointer.I will use mmc_of_parse(). Are you planning to re-spin this patch? Now Jaehoon's changes for using mmc_of_parse() is landed in mmc-next. As its already added mmc_of_parse(),no respin of this. Just we need to use it in DT. Thanks!! I have sent the patch that use mmc_of_parse(). https://patchwork.kernel.org/patch/3750681/ Best Regards, Jaehoon Chung On 03/24/2014 01:23 PM, Yuvaraj Kumar C D wrote: The mmc part in exynos supports SDIO interrupts and they work fine, so turn the capability on. With this I see download speeds increase about 10x. This V1 of this patch is posted to LKML at https://patchwork.kernel.org/patch/2429661/) by Doug Anderson. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/mmc/host/dw_mmc.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 0c56faa..240949d 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -2417,6 +2417,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host) if (of_get_property(np, cd-inverted, NULL)) pdata-caps2 |= MMC_CAP2_CD_ACTIVE_HIGH; + if (of_find_property(np, cap-sdio-irq, NULL)) + pdata-caps |= MMC_CAP_SDIO_IRQ; + return pdata; } -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pinctrl: exynos: Add driver data for Exynos3250
On Mon, Apr 14, 2014 at 3:45 AM, Chanwoo Choi cw00.c...@samsung.com wrote: From: Tomasz Figa t.f...@samsung.com This patch adds driver data (bank list and EINT layout) for Exynos3250 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional input/output ports. There are 23 general port groups. Changes from v1: - Add signed-off of sender - Post only separated patch for pinctrl from following patchset(v1) : https://lkml.org/lkml/2014/4/10/286 Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com This v2 patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] drm: Introduce drm_fb_helper_prepare()
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote: On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote: [...] diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c [...] @@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper *helper) } /** + * drm_fb_helper_prepare - setup a drm_fb_helper structure + * @dev: DRM device + * @helper: driver-allocated fbdev helper structure to set up + * @funcs: pointer to structure of functions associate with this helper + * + * Sets up the bare minimum to make the framebuffer helper usable. This is + * useful to implement race-free initialization of the polling helpers. In + * that case a typical sequence would be: + * + * - call drm_fb_helper_prepare() + * - set dev-mode_config.funcs This step is done in drm_fb_helper_prepare already. drm_fb_helper_prepare() sets fb_helper-funcs. dev-mode_config.funcs needs to be set because it gets called by drm_kms_helper_hotplug_event() which in turn is called by output_poll_execute(), which can be called at any point after drm_kms_helper_poll_init(). It could be scheduled immediately by drm_kms_helper_poll_enable(). I wonder if perhaps we should be wrapping that into a function as well. Currently this is only documented in code by the drivers that call this. But since it's only a single step it doesn't seem worth it. Perhaps if we rolled the min/max_width/height into that function as well it would be more worth it? That could be difficult to do since a couple of drivers need to set those depending on the chipset generation. + * - perform driver-specific setup + * - call drm_kms_helper_poll_init() Maybe mention that after this you can start to handle hpd events using the probe helpers? Isn't that somewhat implied already? The poll helpers call directly the dev-mode_config.funcs-output_poll_changed() function, which has already been set up earlier. + * - call drm_fb_helper_init() + * - call drm_fb_helper_single_add_all_connectors() + * - call drm_fb_helper_initial_config() Does this list look sane in the generated DocBook? Afaik kerneldoc unfortunately lacks any form of markup, at least afaik :( I must admit I didn't check. I'll make sure I do that before sending out the next version. Thierry pgpG3P6CXV81y.pgp Description: PGP signature
Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines
On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BL_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- pre_enable callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- post_disable callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = pre_enable callback poweron LED unit/BL_EN = enable callback poweroff LED unit/BL_EN = disable callback poweroff LCD unit/LCD_EN = post_disable callback I don't like this. What happens when the next panel comes around that has a yet slightly different requirement? Will we introduce a new pre_pre_enable() and post_post_disable() function then? As I have already explained, these 2 callbacks are sufficient enough to take care the power up/down sequence for LVDS and eDP panels. And, definitely having just 2 callbacks enable and disable is not at all sufficient. I initially thought of using panel_simple_enable from panel-simple driver. But it doesn't go well with case wherein there are 2 regulators(one for LCD and one for LED) a BL_EN signal etc. And, often(Believe me, I have referred to both eDP panel datasheets and LVDS panel datasheets) proper powerup sequence for such panels is as mentioned below: powerup: -- power up the supply (LCD_VCC). -- start video data. -- enable backlight. powerdown -- disable backlight. -- stop video data. -- power off the supply (LCD VCC) For the above cases, if I have to somehow fit in all the required settings, it breaks the sequence and I end up getting glitches during bootup/DPMS. Also, when the drm_bridge can support pre_enable and post_disable, why not drm_panel provide that both should work in tandem? Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pinctrl: exynos: Add driver data for Exynos3250
On 04/23/2014 04:01 PM, Linus Walleij wrote: On Mon, Apr 14, 2014 at 3:45 AM, Chanwoo Choi cw00.c...@samsung.com wrote: From: Tomasz Figa t.f...@samsung.com This patch adds driver data (bank list and EINT layout) for Exynos3250 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional input/output ports. There are 23 general port groups. Changes from v1: - Add signed-off of sender - Post only separated patch for pinctrl from following patchset(v1) : https://lkml.org/lkml/2014/4/10/286 Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com This v2 patch applied. Thanks for your apply. Best regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
On Wed, Apr 23, 2014 at 10:26:20AM +0900, YoungJun Cho wrote: Hi Andrzej Thank you for comment. On 04/22/2014 11:02 PM, Andrzej Hajda wrote: On 04/21/2014 02:28 PM, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu timings. Changelog v2: - Adds unit address (commented by Sachin Kamat) Changelog v3: - Removes optional delay, size properties (commented by Laurent Pinchart) - Adds OLED detection, TE gpio properties Changelog v4: - Moves CPU timings relevant properties from FIMD DT (commeted by Laurent Pinchart, Andrzej Hajda) Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file mode 100644 index 000..9eeb38b --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt @@ -0,0 +1,63 @@ +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel + +Required properties: + - compatible: samsung,s6e3fa0 + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpio: a GPIO spec for the reset pin + - det-gpio: a GPIO spec for the OLED detection pin + - te-gpio: a GPIO spec for the TE pin Just FYI, according to DT documentation [1] gpio spec should be in form [name]-gpios, however there is plenty bindings with -gpio suffix, so I am not sure if it is really enforced. On the other side it is enforced by descriptor based gpio framework[2]. Integer-based gpio framework used in your driver is obsolete according to [2]. Yes, you're right. That is my mistake. They should be attached 's'. At first I used integer-based gpio framework and replaced to descriptor based one, but did not updated DT bindings. I've been working on a patch to support both *-gpios and *-gpio variants with the GPIO descriptor framework. *-gpios makes sense if there can indeed be several, but for something like hotplug detection I don't think there's a reason to require the plural. Furthermore some bindings already use the singular *-gpio anyway, so if we ever want to convert drivers using those bindings to the GPIO descriptor API we have to support that form too. Thierry pgp0WyvpxcSxF.pgp Description: PGP signature
Re: [PATCH] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Hi, On Tue, Apr 22, 2014 at 11:29 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 22 Apr 2014, Vivek Gautam wrote: On Thu, Apr 10, 2014 at 6:54 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Add support to consume phy provided by Generic phy framework. Keeping the support for older usb-phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ohci-exynos. Once we move to new phy in the device nodes for ohci, we can remove the support for older phys. Any comments on this please. I think whatever the approach we follow, that can be common to both ehci-exynos[1], and ohci-exynos, since both are needed to move to the new generic phy framework, keeping support for older usb-phy so as to have smooth transition, in order to avoid any regression. I lost my copies of the ehci-exynos patch, but probably the same comments apply as for the ohci-exynos patch. Ok, i will be reworking on the ehci-exynos patch also (which was earlier posted by Kamil [1]), after addressing the review comments on that, and will post the same. [1] [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework https://lkml.org/lkml/2014/1/29/298 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines
On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote: On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BL_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- pre_enable callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- post_disable callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = pre_enable callback poweron LED unit/BL_EN = enable callback poweroff LED unit/BL_EN = disable callback poweroff LCD unit/LCD_EN = post_disable callback I don't like this. What happens when the next panel comes around that has a yet slightly different requirement? Will we introduce a new pre_pre_enable() and post_post_disable() function then? As I have already explained, these 2 callbacks are sufficient enough to take care the power up/down sequence for LVDS and eDP panels. And, definitely having just 2 callbacks enable and disable is not at all sufficient. I initially thought of using panel_simple_enable from panel-simple driver. But it doesn't go well with case wherein there are 2 regulators(one for LCD and one for LED) a BL_EN signal etc. And, often(Believe me, I have referred to both eDP panel datasheets and LVDS panel datasheets) proper powerup sequence for such panels is as mentioned below: powerup: -- power up the supply (LCD_VCC). -- start video data. -- enable backlight. powerdown -- disable backlight. -- stop video data. -- power off the supply (LCD VCC) For the above cases, if I have to somehow fit in all the required settings, it breaks the sequence and I end up getting glitches during bootup/DPMS. Also, when the drm_bridge can support pre_enable and post_disable, why not drm_panel provide that both should work in tandem? Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. I'm not at all comfortable with these. The names are totally confusing. Next somebody will need to do something after the panel has been enabled and we'll have to introduce .post_enable() and .pre_disable() functions. And worse, what if somebody needs something to be done between .pre_enable() and .enable()? .post_pre_enable()? Where does it end? According to the above description the only reason why we need this is to avoid visible glitches when the panel is already on, but the video stream hasn't started yet. If that's the only reason why we need this, then perhaps adding a way for a panel to expose the associated backlight would be better? Thierry pgpnxv94ZOMpr.pgp Description: PGP signature
[PATCH] ASoC: SAMSUNG: Don't clear clock setting during i2s_startup
In exiting kernel, if DAIFMT flags are set in dai_link and I2S is
set to run in master mode, the I2S clocks are not getting configured
resulting in no output.
Existing code clears the current I2S clock settings during i2s_startup
and requires that the clocks are reconfigured. It then assumes that
sound-card driver would call snd_soc_dai_{set_sysclk/set_fmt} to
configure the root clock.
1. Since I2S clock settings remain fixed for a board, it would be better
to set the clocks once during sound-card probe.
2. Also if the DAIFMT flags are set in dai_link, snd_soc_dai_set_fmt is
called during DAI probe.
If both these conditions are true, then I2S clock remains unconfigured
during audio playback. Fix this by removing the code to clear
rclk_srcrate in i2s_startup. Instead, reset this during DAI probe.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
The patch is based on v3.15-rc2.
sound/soc/samsung/i2s.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 048ead9..6e61db7 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -724,9 +724,6 @@ static int i2s_startup(struct snd_pcm_substream *substream,
else
i2s-mode |= DAI_MANAGER;
- /* Enforce set_sysclk in Master mode */
- i2s-rclk_srcrate = 0;
-
if (!any_active(i2s) (i2s-quirks QUIRK_NEED_RSTCLR))
writel(CON_RSTCLR, i2s-addr + I2SCON);
@@ -984,6 +981,7 @@ probe_exit:
/* Reset any constraint on RFS and BFS */
i2s-rfs = 0;
i2s-bfs = 0;
+ i2s-rclk_srcrate = 0;
i2s_txctrl(i2s, 0);
i2s_rxctrl(i2s, 0);
i2s_fifo(i2s, FIC_TXFLUSH);
--
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] mmc: dw_mmc: Don't print data errors
On 23 April 2014 01:51, Doug Anderson diand...@chromium.org wrote: Data errors are completely expected during tuning. Printing them out is confusing people looking at the kernel logs. They see things like: [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088 ...and they think something is wrong with their hardware. Remove the printouts. We'll leave it up to a higher level to report about errors. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mmc/host/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index cced599..4c8d423 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, struct mmc_data *data) data-error = -EIO; } - dev_err(host-dev, data error, status 0x%08x\n, status); + dev_dbg(host-dev, data error, status 0x%08x\n, status); The status here could be useful information about the status register, which is not considered while printing errors by the higher levels. An option could be to print the error, but not when you perform tuning. No big deal though, just a thought. /* * After an error, there may be data lingering -- 1.9.1.423.g4596e3a Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-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/4] mcpm: exynos: populate suspend and powered_up callbacks
On 22 April 2014 16:21, Daniel Lezcano daniel.lezc...@linaro.org wrote:
On 04/21/2014 01:49 PM, Chander Kashyap wrote:
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
arch/arm/mach-exynos/mcpm-exynos.c | 53
1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 46d4968..16af0bd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -318,10 +318,63 @@ static int exynos_power_down_finish(unsigned int
cpu, unsigned int cluster)
return 0; /* success: the CPU is halted */
}
+static void enable_coherency(void)
+{
+ unsigned long v, u;
+
+ asm volatile(
+ mrcp15, 0, %0, c1, c0, 1\n
+ orr%0, %0, %2\n
+ ldr%1, [%3]\n
+ and%1, %1, #0\n
+ orr%0, %0, %1\n
+ mcrp15, 0, %0, c1, c0, 1\n
+ : =r (v), =r (u)
+ : Ir (0x40), Ir (S5P_INFORM0)
+ : cc);
+}
Shouldn't this function to be used from hotplug.c also ?
Hotplug.c already taking care for this. And anyhow that will go away
for mcpm dependent SoCs
+
+void exynos_powered_up(void)
+{
+ unsigned int mpidr, cpu, cluster;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ arch_spin_lock(bl_lock);
+ if (cpu_use_count[cpu][cluster] == 0)
+ cpu_use_count[cpu][cluster] = 1;
+ arch_spin_unlock(bl_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = enynos_pmu_cpunr(mpidr);
*enynos*_pmu_cpunr ?
oops, I will fix typo
+
+ __raw_writel(virt_to_phys(mcpm_entry_point), REG_ENTRY_ADDR);
+
+ exynos_power_down();
+
+ /*
+* Execution reaches here only if cpu did not power down.
+* Hence roll back the changes done in exynos_power_down function.
+ */
+ __raw_writel(EXYNOS_CORE_LOCAL_PWR_EN,
+ EXYNOS_ARM_CORE_CONFIGURATION(cpunr));
Why don't you use the functions defined in the
patch 5/5 arm: exynos: Add MCPM call-back functions
In exynos_core_power_control it powerup the alreay powered down core.
But here i need to simply set this value as core never powered down.
exynos_core_power_control() ?
+ set_cr(get_cr() | CR_C);
+ enable_coherency();
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
with warm regards,
Chander Kashyap
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 101
---
1 file changed, 80 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG 0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG 0x68
+#define DSIM_PHYTIMING2_REG 0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) 0xf) 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZED BIT(1)
#define DSIM_STATE_CMD_LPM BIT(2)
+struct exynos_dsi_driver_data {
+ unsigned int plltmr_reg;
+
+ unsigned int has_freqband:1;
+};
+
struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {
spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+ struct exynos_dsi_driver_data *driver_data;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+ .plltmr_reg = 0x50,
+ .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+ .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+ { .compatible = samsung,exynos4210-mipi-dsi,
+ .data = exynos4_dsi_driver_data },
+ { .compatible = samsung,exynos5420-mipi-dsi,
+ .data = exynos5_dsi_driver_data },
+ { }
+};
I wonder if it wouldn't be better to use samsung,exynos5410-mipi-dsi
compatible and distinguish 5410 and 5420 by DSIM_VERSION register.
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+ struct platform_device *pdev)
+{
+ const struct of_device_id *of_id =
+ of_match_device(exynos_dsi_of_match, pdev-dev);
+
+ return (struct exynos_dsi_driver_data *)of_id-data;
+}
+
static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
{
if (wait_for_completion_timeout(dsi-completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct
exynos_dsi *dsi,
static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
{
- static const unsigned long freq_bands[] = {
- 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
- 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
- 510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
- 770 * MHZ, 870 * MHZ, 950 * MHZ,
- };
+ struct exynos_dsi_driver_data *driver_data = dsi-driver_data;
unsigned long fin, fout;
- int timeout, band;
+ int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct
exynos_dsi *dsi,
failed to find PLL PMS for requested frequency\n);
return -EFAULT;
}
+ dev_dbg(dsi-dev, PLL freq %lu, (p %d, m %d, s %d)\n, fout, p, m, s);
- for (band = 0; band ARRAY_SIZE(freq_bands); ++band)
- if (fout freq_bands[band])
- break;
+ writel(500, dsi-reg_base + driver_data-plltmr_reg);
+
+ reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+ if (driver_data-has_freqband) {
+ static const unsigned long freq_bands[] = {
+ 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+ 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+ 510 * MHZ, 560 * MHZ, 640 * MHZ, 690
Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - det-gpio: a GPIO spec for the OLED detection pin
+ - te-gpio: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?
+ - cpu-timings: CPU interface timings for the connected panel, and it
contains
+following optional properties.
+ - cs-setup: clock cycles for the active period of address signal
+enable until chip select is enable in CPU interface
+ - wr-setup: clock cycles for the active period of CS signal enable
+until write signal is enable in CPU interface
+ - wr-act: clock cycles for the active period of CS enable in CPU
+interface
+ - wr-hold: clock cycles for the active period of CS disable until
+write signal is disable in CPU interface
cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.
If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.
Regards
Andrzej
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpio = gpy7 4 0;
+ det-gpio = gpg0 6 0;
+ te-gpio = gpd1 7 0;
+
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = 0;
+ hactive = 1080;
+ vactive = 1920;
+ hfront-porch = 2;
+ hback-porch = 2;
+ hsync-len = 1;
+ vfront-porch = 1;
+ vback-porch = 4;
+ vsync-len = 1;
+ };
+ };
+
+ cpu-timings {
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-act = 1;
+ wr-hold = 0;
+ };
+ };
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2 0/4] add cpuidle support for Exynos5420
Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg321666.html 2. [PATCH v4] arm: exynos: generalize power register address calculation http://www.spinics.net/lists/arm-kernel/msg324024.html Changelog is in respective patches. Chander Kashyap (4): cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 ++ arch/arm/mach-exynos/mcpm-exynos.c | 53 ++ drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c |3 +- 4 files changed, 59 insertions(+), 2 deletions(-) -- 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] i2c: s3c2410: resume race fix
Doug Anderson wrote: From: Olof Johansson o...@lixom.net Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson o...@lixom.net Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Kukjin Kim kgene@samsung.com Thanks, Kukjin --- drivers/i2c/busses/i2c-s3c2410.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c- s3c2410.c index ae44910..bb3a996 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1276,10 +1276,10 @@ static int s3c24xx_i2c_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); - i2c-suspended = 0; clk_prepare_enable(i2c-clk); s3c24xx_i2c_init(i2c); clk_disable_unprepare(i2c-clk); + i2c-suspended = 0; return 0; } -- 1.9.1.423.g4596e3a -- To unsubscribe from this list: send the line unsubscribe linux-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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com; Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-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/4] add cpuidle support for Exynos5420
On Wednesday, April 23, 2014 02:55:50 PM Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg321666.html 2. [PATCH v4] arm: exynos: generalize power register address calculation http://www.spinics.net/lists/arm-kernel/msg324024.html Changelog is in respective patches. Chander Kashyap (4): cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 ++ arch/arm/mach-exynos/mcpm-exynos.c | 53 ++ drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c |3 +- 4 files changed, 59 insertions(+), 2 deletions(-) I'm assuming that the Exynos maintainers will take care of this, correct? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
Tushar Behera wrote: On 22 April 2014 13:08, Alim Akhtar alim.akh...@gmail.com wrote: Hi Tushar On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera tushar.beh...@linaro.org wrote: MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. + Jonghwan Choi Well, this is not a perfect solution to support MAU power domain, it's true it is a problem right now though. In other words, this is just temporal fix for the problem. How about accessing clock stuff for audio sub-system with handling MAU power domain via generic IO power domain? ?? which abort?? Can you please mention it here? Thanks Alim for spotting this ... I somehow missed adding this. Unhandled fault: imprecise external abort (0x1406) at 0x Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 Kukjin, Let me know if I need to resend the patch. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569
+
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E3FA0
+ tristate S6E3FA0 DSI command mode panel
+ depends on DRM DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho yj44@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 drm/drmP.h
+#include drm/drm_mipi_dsi.h
+#include drm/drm_panel.h
+
+#include linux/gpio.h
+#include linux/of_gpio.h
#include linux/gpio/consumer.h should be enough.
+#include linux/regulator/consumer.h
+
+#include video/mipi_display.h
+#include video/of_videomode.h
+#include video/videomode.h
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM 30
+
+struct s6e3fa0 {
+ struct device *dev;
+ struct drm_panelpanel;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc*reset_gpio;
+ struct gpio_desc*det_gpio;
+ struct gpio_desc*te_gpio;
+ struct videomodevm;
+ struct drm_panel_cpu_timingscpu_timings;
+
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ unsigned intwidth_mm;
+ unsigned intheight_mm;
+
+ unsigned char id;
+ unsigned char vddm;
+ unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+ {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+ {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+ {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+ {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+ {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+ {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+ {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+ {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+ {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+ {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+ {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+ {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+ {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+ {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+ {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+ {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+ {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+ {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+
Re: [RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. Lee, I don't mind if I apply this and send a pull request to you or I pull a tag from you with this in - what's easiest for you? I'm happy to do it. Doug, Can you send the patch-set again with all of the *-bys and ensure I'm on TO or CC please? -- 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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi,
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com;
Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
--
To unsubscribe from this list: send the line unsubscribe linux-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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
Hi,
On Wed, Apr 23, 2014 at 4:27 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hi,
Hi Anton,
On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
av.tikhomi...@samsung.com wrote:
Hello,
-Original Message-
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
To: linux-...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; linux-
arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com;
Vivek
Gautam; Anton Tikhomirov
Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
regulators
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
Yea, actually after the patch (which got merged in 3.15 rc1)
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the USB stops working, and that's because the regulators related to
usb are not turned on by default (ldo12 and ldo15 to be specific).
So we need to enable those regulators, which ofcourse the driver
should be doing, if i am not wrong.
Similar is the reason for EHCI, and OHCI exynos patches in this series.
I shall be sending the dt patch for this soon.
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] mfd: tps65090: Stop caching most registers
Anton,
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent names).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- Leave cache on for the registers that can be cached.
- Move register offsets to mfd header file.
drivers/mfd/tps65090.c | 27 ++-
drivers/power/tps65090-charger.c | 11 ---
This patch still requires your Ack.
include/linux/mfd/tps65090.h | 14 ++
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..1c3e6e2 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -32,14 +32,6 @@
#define NUM_INT_REG 2
#define TOTAL_NUM_REG 0x18
-/* interrupt status registers */
-#define TPS65090_INT_STS 0x0
-#define TPS65090_INT_STS20x1
-
-/* interrupt mask registers */
-#define TPS65090_INT_MSK 0x2
-#define TPS65090_INT_MSK20x3
-
#define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
#define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE2
#define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
@@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.irqs = tps65090_irqs,
.num_irqs = ARRAY_SIZE(tps65090_irqs),
.num_regs = NUM_INT_REG,
- .status_base = TPS65090_INT_STS,
- .mask_base = TPS65090_INT_MSK,
+ .status_base = TPS65090_REG_INTR_STS,
+ .mask_base = TPS65090_REG_INTR_MASK,
.mask_invert = true,
};
static bool is_volatile_reg(struct device *dev, unsigned int reg)
{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
+ /* Nearly all registers have status bits mixed in, except a few */
+ switch (reg) {
+ case TPS65090_REG_INTR_MASK:
+ case TPS65090_REG_INTR_MASK2:
+ case TPS65090_REG_CG_CTRL0:
+ case TPS65090_REG_CG_CTRL1:
+ case TPS65090_REG_CG_CTRL2:
+ case TPS65090_REG_CG_CTRL3:
+ case TPS65090_REG_CG_CTRL4:
+ case TPS65090_REG_CG_CTRL5:
return false;
+ }
+ return true;
}
static const struct regmap_config tps65090_regmap_config = {
diff --git a/drivers/power/tps65090-charger.c
b/drivers/power/tps65090-charger.c
index cc26c12..31a3ba4 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -30,17 +30,6 @@
#include linux/mfd/tps65090.h
-#define TPS65090_REG_INTR_STS0x00
-#define TPS65090_REG_INTR_MASK 0x02
-#define TPS65090_REG_CG_CTRL00x04
-#define TPS65090_REG_CG_CTRL10x05
-#define TPS65090_REG_CG_CTRL20x06
-#define TPS65090_REG_CG_CTRL30x07
-#define TPS65090_REG_CG_CTRL40x08
-#define TPS65090_REG_CG_CTRL50x09
-#define TPS65090_REG_CG_STATUS1 0x0a
-#define TPS65090_REG_CG_STATUS2 0x0b
-
#define TPS65090_CHARGER_ENABLE BIT(0)
#define TPS65090_VACGBIT(1)
#define TPS65090_NOITERM BIT(5)
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index 3f43069..45f0f9d 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -64,6 +64,20 @@ enum {
TPS65090_REGULATOR_MAX,
};
+/* Register addresses */
+#define TPS65090_REG_INTR_STS0x00
+#define TPS65090_REG_INTR_STS2 0x01
+#define TPS65090_REG_INTR_MASK 0x02
+#define TPS65090_REG_INTR_MASK2 0x03
+#define TPS65090_REG_CG_CTRL00x04
+#define TPS65090_REG_CG_CTRL10x05
+#define TPS65090_REG_CG_CTRL20x06
+#define TPS65090_REG_CG_CTRL30x07
+#define TPS65090_REG_CG_CTRL40x08
+#define TPS65090_REG_CG_CTRL50x09
+#define TPS65090_REG_CG_STATUS1 0x0a
+#define TPS65090_REG_CG_STATUS2 0x0b
+
struct tps65090 {
struct device *dev;
struct regmap *rmap;
--
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] ASoC: SAMSUNG: Don't clear clock setting during i2s_startup
On Wed, Apr 23, 2014 at 01:34:24PM +0530, Tushar Behera wrote: In exiting kernel, if DAIFMT flags are set in dai_link and I2S is set to run in master mode, the I2S clocks are not getting configured resulting in no output. Applied, thanks. signature.asc Description: Digital signature
Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
Hi Andrzej,
On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - det-gpio: a GPIO spec for the OLED detection pin
+ - te-gpio: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?
+ - cpu-timings: CPU interface timings for the connected panel, and it
contains
+following optional properties.
+ - cs-setup: clock cycles for the active period of address
signal
+enable until chip select is enable in CPU interface
+ - wr-setup: clock cycles for the active period of CS signal
enable
+until write signal is enable in CPU interface
+ - wr-act: clock cycles for the active period of CS enable in
CPU
+interface
What about calling this property wr-active ? I had called this wr-cycle in a
previous implementation, that could be an option as well.
+ - wr-hold: clock cycles for the active period of CS disable
until
+write signal is disable in CPU interface
cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.
The panel has a memory-like interface with chip select, read/write and access
strobe, address (1 bit) and data signals. The interface is defined in the MIPI
DBI specification (a quick search turned up
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be
direct PDF downloads available), even if some panels implement a similar
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably
due to the similarities with the 8051 external bus).
The cpu-timings properties describe the read and write access timings for
those signals, unrelated to the display video timings. I thus believe that
they should be separate from the display timings. We will probably need to add
properties for the read signal as well, but that can be done later.
If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.
The timings description should be pretty generic I believe, especially given
that the interface is standardized by the MIPI alliance. Could you have a
quick look at the spec and share your opinion ?
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpio = gpy7 4 0;
+ det-gpio = gpg0 6 0;
+ te-gpio = gpd1 7 0;
+
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = 0;
+ hactive = 1080;
+ vactive = 1920;
+
Re: [PATCH v3 1/5] mfd: tps65090: Don't tell child devices we have an IRQ if we don't
If we weren't given an interrupt we shouldn't tell child devices (like the tps65090 charger) that they have an interrupt. This is needed so that we can support polling mode in the tps65090 charger driver. See also (charger: tps65090: Allow charger module to be used when no irq). Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Lee Jones lee.jo...@linaro.org --- Changes in v3: None Changes in v2: - Split noirq (polling mode) changes into MFD and charger drivers/mfd/tps65090.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) Applied, thanks. -- 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 v3 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. In order to avoid adding more duplicate #defines, we also move some register offset definitions to the mfd driver (and resolve inconsistent names). Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v3: None Changes in v2: - Leave cache on for the registers that can be cached. - Move register offsets to mfd header file. drivers/mfd/tps65090.c | 27 ++- drivers/power/tps65090-charger.c | 11 --- include/linux/mfd/tps65090.h | 14 ++ 3 files changed, 28 insertions(+), 24 deletions(-) Applied now, thanks. -- 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 v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
The tps65090 regulator allows you to specify how long you want it to wait before detecting an overcurrent condition. Allow specifying that through the device tree (or through platform data). Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Michael Spang sp...@chromium.org Signed-off-by: Sean Paul seanp...@chromium.org --- Changes in v3: - Fixed kernel-doc notation for return Changes in v2: - Separated the overcurrent and retries changes into two patches. - Now set overcurrent at probe time since it doesn't change. .../devicetree/bindings/regulator/tps65090.txt | 4 ++ drivers/regulator/tps65090-regulator.c | 56 ++ include/linux/mfd/tps65090.h | 5 ++ 3 files changed, 65 insertions(+) Applied, thanks. -- 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 v3 resend] clk: s2mps11: Add support for S2MPS14 clocks
Hi,
Mike, can you apply this patch? Actually you acked it already [1] but I
forgot to put it in the commit message.
The patch wasn't applied in that time because of multiple concurrent
changes in sec-core drivers.
[1]http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28039/focus=310279
Best regards,
Krzysztof
On pon, 2014-04-14 at 09:55 +0200, Krzysztof Kozlowski wrote:
This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
s2mps11 clock driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Yadwinder Singh Brar yadi.b...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/clk/Kconfig | 8 +++
drivers/clk/clk-s2mps11.c | 61
+++
2 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..8f9ce8ba036d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -65,12 +65,12 @@ config COMMON_CLK_SI570
clock generators.
config COMMON_CLK_S2MPS11
- tristate Clock driver for S2MPS11/S5M8767 MFD
+ tristate Clock driver for S2MPS1X/S5M8767 MFD
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
- multi-function devices have 3 fixed-rate oscillators, clocked at
- 32KHz each.
+ This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ clock. These multi-function devices have two (S2MPS14) or three
+ (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
config CLK_TWL6040
tristate External McPDM functional clock from twl6040
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index f2f62a1bf61a..b78eafeab038 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -1,7 +1,7 @@
/*
* clk-s2mps11.c - Clock driver for S2MPS11.
*
- * Copyright (C) 2013 Samsung Electornics
+ * Copyright (C) 2013,2014 Samsung Electornics
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -13,10 +13,6 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
*/
#include linux/module.h
@@ -27,6 +23,7 @@
#include linux/clk-provider.h
#include linux/platform_device.h
#include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s2mps14.h
#include linux/mfd/samsung/s5m8767.h
#include linux/mfd/samsung/core.h
@@ -125,7 +122,21 @@ static struct clk_init_data
s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
},
};
-static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
+static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = s2mps14_ap,
+ .ops = s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = s2mps14_bt,
+ .ops = s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
+static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
+ struct clk_init_data *clks_init)
{
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
struct device_node *clk_np;
@@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct
platform_device *pdev)
if (!clk_table)
return ERR_PTR(-ENOMEM);
- for (i = 0; i S2MPS11_CLKS_NUM; i++)
+ for (i = 0; i S2MPS11_CLKS_NUM; i++) {
+ if (!clks_init[i].name)
+ continue; /* Skip clocks not present in some devices */
of_property_read_string_index(clk_np, clock-output-names, i,
- s2mps11_clks_init[i].name);
+ clks_init[i].name);
+ }
return clk_np;
}
@@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
struct device_node *clk_np = NULL;
unsigned int s2mps11_reg;
+ struct clk_init_data *clks_init;
int i, ret = 0;
u32 val;
@@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device
*pdev)
s2mps11_clk = s2mps11_clks;
- clk_np = s2mps11_clk_parse_dt(pdev);
- if (IS_ERR(clk_np))
- return PTR_ERR(clk_np);
-
switch(platform_get_device_id(pdev)-driver_data) {
case S2MPS11X:
s2mps11_reg = S2MPS11_REG_RTC_CTRL;
+ clks_init =
Re: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators
On Wednesday, April 23, 2014 8:06 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 7:58 PM, Anton Tikhomirov wrote:
On Wednesday, April 23, 2014 6:52 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 6:27 PM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
Yea, actually after the patch (which got merged in 3.15 rc1)
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the USB stops working, and that's because the regulators related to
usb are not turned on by default (ldo12 and ldo15 to be specific).
So we need to enable those regulators, which ofcourse the driver
should be doing, if i am not wrong.
Similar is the reason for EHCI, and OHCI exynos patches in this series.
Oh, I see. Thank you for your explanation.
I shall be sending the dt patch for this soon.
OK, I will wait for your patch.
Best regards,
Jingoo Han
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Add cros_ec changes for newer boards
On Tue, 22 Apr 2014, Doug Anderson wrote: This series adds the most critical cros_ec changes for newer boards using cros_ec. Specifically: * Fixes timing/locking issues with the previously upstreamed (but never used upstream) cros_ec_spi driver. * Updates the cros_ec header file to the latest version which allows us to use newer EC features like i2c tunneling. * Adds an i2c tunnel driver to allow communication to the EC's i2c devices. This _doesn't_ get the EC driver fully up to speed with what's in the current Chromium OS trees. There are a whole slew of cleanup patches there, an addition of an LPC transport mode, and exports of functions to userspace. Once these patches land and we have functionality we can continue to pick more cleanup patches. Changes in v2: - Update tunnel binding as per swarren - Removed i2c20 alias for i2c tunnel Bill Richardson (1): mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources David Hendricks (1): mfd: cros_ec: spi: calculate delay between transfers correctly Doug Anderson (5): mfd: cros_ec: spi: Add mutex to cros_ec_spi mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms i2c: ChromeOS EC tunnel driver ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 + arch/arm/boot/dts/tegra124-venice2.dts | 26 + drivers/i2c/busses/Kconfig |9 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 ++ drivers/mfd/cros_ec.c |7 +- drivers/mfd/cros_ec_spi.c | 67 +- include/linux/mfd/cros_ec.h|4 +- include/linux/mfd/cros_ec_commands.h | 1128 ++-- 9 files changed, 1493 insertions(+), 92 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c Need to wait for the ARM, DT and I2C guys to review, at which point I'll be happy to take in and supply a branch for them to pull from if required. If there are no _true_ dependencies and the MFD changes can be added independently without fear of build breakages, let me know and I'll apply them separately. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly
From: David Hendricks dhend...@chromium.org To avoid spamming the EC we calculate the time between the previous transfer and the current transfer and force a delay if the time delta is too small. However, a small miscalculation causes the delay period to be far too short. Most noticably this impacts commands with a long turnaround time such as EC firmware reads and writes. Signed-off-by: David Hendricks dhend...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Waiting for other subsystems to Ack, so for now: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
On Tue, 22 Apr 2014, Doug Anderson wrote: We're adding i2c tunneling to the list of things that goes over cros_ec. i2c tunneling can be slooow, so increase our deadline to 100ms to account for that. Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec_spi.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) Waiting for other subsystems to Ack, so for now: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] i2c: ChromeOS EC tunnel driver
On Tue, 22 Apr 2014, Doug Anderson wrote: On ARM Chromebooks we have a few devices that are accessed by both the AP (the main Application Processor) and the EC (the Embedded Controller). These are: * The battery (sbs-battery). * The power management unit tps65090. On the original Samsung ARM Chromebook these devices were on an I2C bus that was shared between the AP and the EC and arbitrated using some extranal GPIOs (see i2c-arb-gpio-challenge). The original arbitration scheme worked well enough but had some downsides: * It was nonstandard (not using standard I2C multimaster) * It only worked if the EC-AP communication was I2C * It was relatively hard to debug problems (hard to tell if i2c issues were caused by the EC, the AP, or some device on the bus). On the HP Chromebook 11 the design was changed to: * The AP/EC comms were still i2c, but the battery/tps65090 were no longer on the bus used for AP/EC communication. The battery was exposed to the AP through a limited i2c tunnel and tps65090 was exposed to the AP through a custom Linux driver. On the Samsung ARM Chromebook 2 the scheme is changed yet again, now: * The AP/EC comms are now using SPI for faster speeds. * The EC's i2c bus is exposed to the AP through a full i2c tunnel. The upstream tegra124-venice2 uses the same scheme as the Samsung ARM Chromebook 2, though it has a different set of components on the other side of the bus. This driver supports the scheme used by the Samsung ARM Chromebook 2. Future patches to this driver could add support for the battery tunnel on the HP Chromebook 11 (and perhaps could even be used to access tps65090 on the HP Chromebook 11 instead of using a special driver, but I haven't researched that enough). Signed-off-by: Vincent Palatin vpala...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: - Update tunnel binding as per swarren .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 +++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-cros-ec-tunnel.c| 304 + drivers/mfd/cros_ec.c | 5 + For the MFD changes: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
On Tue, 22 Apr 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org This just updates include/linux/mfd/cros_ec_commands.h to match the latest EC version (which is the One True Source for such things). See https://chromium.googlesource.com/chromiumos/platform/ec [dianders: took today's ToT version from the Chromium OS EC; deleted references to cros_ec_dev and cros_ec_lpc since those aren't upstream yet] Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec.c|2 +- include/linux/mfd/cros_ec.h |4 +- include/linux/mfd/cros_ec_commands.h | 1128 +++--- 3 files changed, 1059 insertions(+), 75 deletions(-) Waiting for other subsystems to Ack, so for now: Acked-by: Lee Jones lee.jo...@linaro.org -- 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 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
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 v2 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
On Tue, 22 Apr 2014, Doug Anderson wrote: The cros_ec_spi transfer had two problems with its timeout code: 1. It looked at the timeout even in the case that it found valid data. 2. If the cros_ec_spi code got switched out for a while, it's possible it could get a timeout after a single loop. Let's be paranoid and make sure we do one last transfer after the timeout expires. Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec_spi.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) Waiting for other subsystems to Ack, so for now: Acked-by: Lee Jones lee.jo...@linaro.org -- 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 2/3] usb: ehci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ehci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1d8c47..a3ca8cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -20,6 +20,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)-priv)
@@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
exynos_ehci-otg = phy-otg;
}
+ exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ehci-vdd33)) {
+ err = PTR_ERR(exynos_ehci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ehci-vdd10)) {
+ err = PTR_ERR(exynos_ehci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ehci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -178,6 +203,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
return rc;
}
@@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
+ int ret;
+
+ ret = regulator_enable(exynos_ehci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ehci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ehci-clk);
--
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 v2 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi
On Tue, 22 Apr 2014, Doug Anderson wrote: The main transfer function for cros_ec_spi can be called by more than one client at a time. Make sure that those clients don't stomp on each other by locking the bus for the duration of the transfer function. Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v2: None drivers/mfd/cros_ec_spi.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) Waiting for other subsystems to Ack, so for now: Acked-by: Lee Jones lee.jo...@linaro.org -- 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: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
Hi Andrzej,
On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
mode 100644
index 000..9eeb38b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,63 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - det-gpio: a GPIO spec for the OLED detection pin
+ - te-gpio: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
Which properties of display-timings are relevant for CPU mode?
I guess width and height. Anything more?
+ - cpu-timings: CPU interface timings for the connected panel, and it
contains
+following optional properties.
+ - cs-setup: clock cycles for the active period of address
signal
+enable until chip select is enable in CPU interface
+ - wr-setup: clock cycles for the active period of CS signal
enable
+until write signal is enable in CPU interface
+ - wr-act: clock cycles for the active period of CS enable in
CPU
+interface
What about calling this property wr-active ? I had called this wr-cycle in a
previous implementation, that could be an option as well.
+ - wr-hold: clock cycles for the active period of CS disable
until
+write signal is disable in CPU interface
cpu-timings name does not sound to be related to display.
I wonder if it would not be better to merge cpu-timings into
display-timings but this will require more discussion I guess.
The panel has a memory-like interface with chip select, read/write and access
strobe, address (1 bit) and data signals. The interface is defined in the
MIPI
DBI specification (a quick search turned up
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be
direct PDF downloads available), even if some panels implement a similar
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably
due to the similarities with the 8051 external bus).
The cpu-timings properties describe the read and write access timings for
those signals, unrelated to the display video timings. I thus believe that
they should be separate from the display timings. We will probably need to
add
properties for the read signal as well, but that can be done later.
cpu-timings suggests these timings are for CPU, but they are for display
panel in CPU mode.
I though rather about something like display-cpu-timings or i80-timings,
just to avoid confusion.
Regards
Andrzej
If you want to stay with separate node please consider to make it
optional as whole node or make some properties required. Making node
required with all sub-properties optional is weird.
By the way I hope all timings properties are generic for CPU mode,
if not they should be prefixed by vendor or model.
The timings description should be pretty generic I believe, especially given
that the interface is standardized by the MIPI alliance. Could you have a
quick look at the spec and share your opinion ?
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpio = gpy7 4 0;
+ det-gpio = gpg0 6 0;
+ te-gpio = gpd1 7 0;
+
+ display-timings {
+
[PATCH 0/3] Add MFCv8 support
This patchset adds MFCv8 support to the s5p-mfc driver. MFCv8 has the same operation sequence as that of v6+, but there is some shuffling of the registers happened. So to re-use the exisiting code, register access uses context variables instead of macros. The patchset modifies opr_v6 file to use register variables and is tested on mfc v6, v7 and v8 based boards. The patchset is based on the following set of patches posted for MFC which are currently under review: [media] s5p-mfc: Add support for resolution change event v4l: Add resolution change event. [media] s5p-mfc: Don't allocate codec buffers on STREAMON. [media] s5p-mfc: Extract open/close MFC instance commands. [media] s5p-mfc: Fixes for decode REQBUFS. [media] s5p-mfc: Copy timestamps only when a frame is produced. [media] s5p-mfc: add init buffer cmd to MFCV6 [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode. [media] s5p-mfc: Add a control for IVF format for VP8 encoder Arun Kumar K (1): [media] s5p-mfc: Rename IS_MFCV7 macro Kiran AVND (2): [media] s5p-mfc: Add variants to access mfc registers [media] s5p-mfc: Core support to add v8 decoder .../devicetree/bindings/media/s5p-mfc.txt |3 +- drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 93 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 31 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h|7 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |4 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c |6 + drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 254 +++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 792 +--- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|7 +- 10 files changed, 926 insertions(+), 273 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.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 2/3] [media] s5p-mfc: Core support to add v8 decoder
From: Kiran AVND avnd.ki...@samsung.com This patch adds variant data and core support for V8 decoder. This patch also adds the register definition file for new firmware version v8 for MFC. Signed-off-by: Kiran AVND avnd.ki...@samsung.com Signed-off-by: Pawel Osciak posc...@chromium.org Signed-off-by: Arun Kumar K arun...@samsung.com --- .../devicetree/bindings/media/s5p-mfc.txt |3 +- drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 93 drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 +++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |4 + drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 85 -- 6 files changed, 209 insertions(+), 10 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.h diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index f418168..3e3c5f3 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,7 +10,8 @@ Required properties: - compatible : value should be either one among the following (a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs (b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs - (b) samsung,mfc-v7 for MFC v7 present in Exynos5420 SoC + (c) samsung,mfc-v7 for MFC v7 present in Exynos5420 SoC + (d) samsung,mfc-v8 for MFC v8 present in Exynos5800 SoC - reg : Physical base address of the IP registers and length of memory mapped region. diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h new file mode 100644 index 000..747907c --- /dev/null +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h @@ -0,0 +1,93 @@ +/* + * Register definition file for Samsung MFC V8.x Interface (FIMV) driver + * + * 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. + */ + +#ifndef _REGS_MFC_V8_H +#define _REGS_MFC_V8_H + +#include regs-mfc-v7.h + +/* Additional registers for v8 */ +#define S5P_FIMV_D_MVC_NUM_VIEWS_V80xf104 +#define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8 0xf144 +#define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V80xf148 +#define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150 + +#define S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8 0xf138 +#define S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8 0xf13c + +#define S5P_FIMV_D_FIRST_PLANE_DPB_V8 0xf160 +#define S5P_FIMV_D_SECOND_PLANE_DPB_V8 0xf260 +#define S5P_FIMV_D_MV_BUFFER_V80xf460 + +#define S5P_FIMV_D_NUM_MV_V8 0xf134 +#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V8 0xf154 + +#define S5P_FIMV_D_SCRATCH_BUFFER_ADDR_V8 0xf560 +#define S5P_FIMV_D_SCRATCH_BUFFER_SIZE_V8 0xf564 + +#define S5P_FIMV_D_CPB_BUFFER_ADDR_V8 0xf5b0 +#define S5P_FIMV_D_CPB_BUFFER_SIZE_V8 0xf5b4 +#define S5P_FIMV_D_AVAILABLE_DPB_FLAG_LOWER_V8 0xf5bc +#define S5P_FIMV_D_CPB_BUFFER_OFFSET_V80xf5c0 +#define S5P_FIMV_D_SLICE_IF_ENABLE_V8 0xf5c4 +#define S5P_FIMV_D_STREAM_DATA_SIZE_V8 0xf5d0 + +/* Display information register */ +#define S5P_FIMV_D_DISPLAY_FRAME_WIDTH_V8 0xf600 +#define S5P_FIMV_D_DISPLAY_FRAME_HEIGHT_V8 0xf604 + +/* Display status */ +#define S5P_FIMV_D_DISPLAY_STATUS_V8 0xf608 + +#define S5P_FIMV_D_DISPLAY_FIRST_PLANE_ADDR_V8 0xf60c +#define S5P_FIMV_D_DISPLAY_SECOND_PLANE_ADDR_V80xf610 + +#define S5P_FIMV_D_DISPLAY_FRAME_TYPE_V8 0xf618 +#define S5P_FIMV_D_DISPLAY_CROP_INFO1_V8 0xf61c +#define S5P_FIMV_D_DISPLAY_CROP_INFO2_V8 0xf620 +#define S5P_FIMV_D_DISPLAY_PICTURE_PROFILE_V8 0xf624 + +/* Decoded picture information register */ +#define S5P_FIMV_D_DECODED_STATUS_V8 0xf644 +#define S5P_FIMV_D_DECODED_FIRST_PLANE_ADDR_V8 0xf648 +#define S5P_FIMV_D_DECODED_SECOND_PLANE_ADDR_V80xf64c +#define S5P_FIMV_D_DECODED_THIRD_PLANE_ADDR_V8 0xf650 +#define S5P_FIMV_D_DECODED_FRAME_TYPE_V8 0xf654 +#define S5P_FIMV_D_DECODED_NAL_SIZE_V8 0xf664 + +/* Returned value register for specific setting */ +#define S5P_FIMV_D_RET_PICTURE_TAG_TOP_V8 0xf674 +#define S5P_FIMV_D_RET_PICTURE_TAG_BOT_V8 0xf678 +#define S5P_FIMV_D_MVC_VIEW_ID_V8 0xf6d8 + +/* SEI related information */ +#define S5P_FIMV_D_FRAME_PACK_SEI_AVAIL_V8 0xf6dc + +/* MFCv8 Context buffer sizes */ +#define MFC_CTX_BUF_SIZE_V8(30 * SZ_1K)/* 30KB */ +#define MFC_H264_DEC_CTX_BUF_SIZE_V8 (2 * SZ_1M) /* 2MB */ +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V8 (20 * SZ_1K)/* 20KB */ + +/* Buffer size defines */
Re: [PATCH 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT
Hi,
On Wed, Apr 2, 2014 at 1:20 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Exynos Power Management Unit (PMU) base address
from device tree. Code will use existing samsung pmu binding information.
This patch also adds get_exynos_pmubase a helper function to return mapped
base
address to various other files under mach-exynos.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h |2 ++
arch/arm/mach-exynos/exynos.c | 44
+
2 files changed, 46 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ff28334..9a55cf6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -61,4 +61,6 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void __iomem *get_exynos_pmubase(void);
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a5e1349..a5127fb 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,8 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static void __iomem *exynos_pmu_base __initdata;
Are you sure you want to keep exynos_pmu_base in .init section.
I am seeing a crash in platform_do_lowpower()
I think you should remove __initdata.
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -245,6 +247,47 @@ void __init exynos_init_late(void)
exynos_pm_init();
}
+static char const *exynos_dt_pmu_match[] __initconst = {
+ samsung,exynos4210-pmu,
+ samsung,exynos4212-pmu,
+ samsung,exynos4412-pmu,
+ samsung,exynos5250-pmu,
+ NULL
+};
+
+static int __init exynos_fdt_map_pmu(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+
+ if (of_flat_dt_match(node, exynos_dt_pmu_match)) {
+ phys_addr_t phys_addr;
+ reg = of_get_flat_dt_prop(node, reg, len);
+ if (reg == NULL || len != (sizeof(unsigned long) * 2))
+ return 0;
+
+ phys_addr = be32_to_cpu(reg[0]);
+ iodesc.pfn = __phys_to_pfn(phys_addr);
+ iodesc.length = be32_to_cpu(reg[1]) - 1;
+ iodesc.virtual = (unsigned long)S5P_VA_PMU;
+ iodesc.type = MT_DEVICE;
+ iotable_init(iodesc, 1);
+
+ exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
+ if (WARN_ON(!exynos_pmu_base))
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+inline void __iomem *get_exynos_pmubase()
+{
+ return exynos_pmu_base;
+}
+
static int __init exynos_fdt_map_chipid(unsigned long node, const char
*uname,
int depth, void *data)
{
@@ -301,6 +344,7 @@ void __init exynos_init_io(void)
debug_ll_io_init();
of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+ of_scan_flat_dt(exynos_fdt_map_pmu, NULL);
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings
On 04/23/2014 02:55 PM, Laurent Pinchart wrote: Hi Andrzej, On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote: On 04/23/2014 01:34 PM, Laurent Pinchart wrote: On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote: On 04/21/2014 02:28 PM, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu timings. Changelog v2: - Adds unit address (commented by Sachin Kamat) Changelog v3: - Removes optional delay, size properties (commented by Laurent Pinchart) - Adds OLED detection, TE gpio properties Changelog v4: - Moves CPU timings relevant properties from FIMD DT (commeted by Laurent Pinchart, Andrzej Hajda) Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 63 +++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file mode 100644 index 000..9eeb38b --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt @@ -0,0 +1,63 @@ +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel + +Required properties: + - compatible: samsung,s6e3fa0 + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpio: a GPIO spec for the reset pin + - det-gpio: a GPIO spec for the OLED detection pin + - te-gpio: a GPIO spec for the TE pin + - display-timings: timings for the connected panel as described by [1] Which properties of display-timings are relevant for CPU mode? I guess width and height. Anything more? + - cpu-timings: CPU interface timings for the connected panel, and it contains +following optional properties. + - cs-setup: clock cycles for the active period of address signal +enable until chip select is enable in CPU interface + - wr-setup: clock cycles for the active period of CS signal enable +until write signal is enable in CPU interface + - wr-act: clock cycles for the active period of CS enable in CPU +interface What about calling this property wr-active ? I had called this wr-cycle in a previous implementation, that could be an option as well. + - wr-hold: clock cycles for the active period of CS disable until +write signal is disable in CPU interface cpu-timings name does not sound to be related to display. I wonder if it would not be better to merge cpu-timings into display-timings but this will require more discussion I guess. The panel has a memory-like interface with chip select, read/write and access strobe, address (1 bit) and data signals. The interface is defined in the MIPI DBI specification (a quick search turned up http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be direct PDF downloads available), even if some panels implement a similar interface that predates MIPI DBI (with names such as i80 or SYS-80 probably due to the similarities with the 8051 external bus). The cpu-timings properties describe the read and write access timings for those signals, unrelated to the display video timings. I thus believe that they should be separate from the display timings. We will probably need to add properties for the read signal as well, but that can be done later. cpu-timings suggests these timings are for CPU, but they are for display panel in CPU mode. I though rather about something like display-cpu-timings or i80-timings, just to avoid confusion. mipi-dbi-timings maybe ? It looks OK. I guess only hactive, and vactive props of display-timings are used, maybe some flags? I wonder if it would not be better to drop display-timings node and place all props into mipi-dbi-timings or mipi-dbi-settings node. Or rather all timings props should be put into port/endpoint node with or without any container node. Regards Andrzej If you want to stay with separate node please consider to make it optional as whole node or make some properties required. Making node required with all sub-properties optional is weird. By the way I hope all timings properties are generic for CPU mode, if not they should be prefixed by vendor or model. The timings description should be pretty generic I believe, especially given that the interface is standardized by the MIPI alliance. Could you have a quick look at the spec and share your opinion ? + +Optional properties: + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]:
Re: [PATCH 3/4] drm: Introduce drm_fb_helper_prepare()
On Wed, Apr 23, 2014 at 09:35:48AM +0200, Daniel Vetter wrote: On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote: On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote: On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote: [...] diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c [...] @@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct drm_fb_helper *helper) } /** + * drm_fb_helper_prepare - setup a drm_fb_helper structure + * @dev: DRM device + * @helper: driver-allocated fbdev helper structure to set up + * @funcs: pointer to structure of functions associate with this helper + * + * Sets up the bare minimum to make the framebuffer helper usable. This is + * useful to implement race-free initialization of the polling helpers. In + * that case a typical sequence would be: + * + * - call drm_fb_helper_prepare() + * - set dev-mode_config.funcs This step is done in drm_fb_helper_prepare already. drm_fb_helper_prepare() sets fb_helper-funcs. dev-mode_config.funcs needs to be set because it gets called by drm_kms_helper_hotplug_event() which in turn is called by output_poll_execute(), which can be called at any point after drm_kms_helper_poll_init(). It could be scheduled immediately by drm_kms_helper_poll_enable(). I wonder if perhaps we should be wrapping that into a function as well. Currently this is only documented in code by the drivers that call this. But since it's only a single step it doesn't seem worth it. Perhaps if we rolled the min/max_width/height into that function as well it would be more worth it? That could be difficult to do since a couple of drivers need to set those depending on the chipset generation. Oh I've misread this step for the fb_helper-funcs assignment. Makes sense and I don't think we need to augment your kerneldoc more to explain this. + * - perform driver-specific setup Hm, maybe clarify this as initialize modeset objects like crtcs, encoders and connectors? Since that's the important part we need to get done here. + * - call drm_kms_helper_poll_init() Maybe mention that after this you can start to handle hpd events using the probe helpers? Isn't that somewhat implied already? The poll helpers call directly the dev-mode_config.funcs-output_poll_changed() function, which has already been set up earlier. I've more meant that after this it's save for drivers to enable hpd interrupts and start to process them. I.e. - enable interrupts and start processing hpd events as an additional step to make it really cleear how it all fits together. Otherwise driver authors are left wondering wtf this isn't just one function call to do it all for them ;-) + * - call drm_fb_helper_init() + * - call drm_fb_helper_single_add_all_connectors() + * - call drm_fb_helper_initial_config() Does this list look sane in the generated DocBook? Afaik kerneldoc unfortunately lacks any form of markup, at least afaik :( I must admit I didn't check. I'll make sure I do that before sending out the next version. If it looks ugly I'm ok as-is, just wondered. Kerneldoc is a bit simplistic ime. In the second version I just sent out I ended up moving the description of this sequence into the fbdev helper section rather than keeping it in the description of the drm_fb_helper_prepare() function, since the new function is really just a part of the whole sequence, so it seemed to fit more nicely. And I've dropped the list formatting and turned it into prose instead. Thierry pgpeZGgpUcAm7.pgp Description: PGP signature
Re: [PATCH resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets
The rtc-s5m driver does not support all of S2M and S5M chipsets supported by main MFD sec-core driver. For such chipsets unsupported by rtc-s5m, the MFD sec-core driver initialized regmap with default config. This config in such cases wouldn't work at all. The main MFD sec-core driver shouldn't initialize regmap for child drivers which is not used by them and even not valid. Move the allocation of RTC I2C dummy device and initialization of RTC regmap from main MFD sec-core driver to the rtc-s5m driver. The rtc-s5m driver will use proper regmap config for supported devices. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/mfd/sec-core.c | 53 +--- drivers/rtc/rtc-s5m.c| 75 +--- include/linux/mfd/samsung/core.h | 3 -- 3 files changed, 71 insertions(+), 60 deletions(-) Applied, thanks. -- 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
[PATCH 0/9] Enable USB 3.0 support on Exynos5 systems
Based on 'for-next' branch of Kgene's linux-samsung tree. Tested with phy-driver[1] patches and peach-pit dts[2]. This is the DT split part of the patch-series[3]. Patches: usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config are removing the older phy-samsung-usb3 driver. Have included this driver patch in this series since we are moving the device tree of DWC3 controller to new phy driver, so we wouldn't be needing this older driver anymore. [1]: [PATCH v6 1/2] phy: Add new Exynos5 USB 3.0 PHY driver http://www.spinics.net/lists/linux-usb/msg106185.html [PATCH v6 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply http://www.spinics.net/lists/linux-usb/msg106184.html [2]: [PATCH] ARM: dts: Add peach-pit board support http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28846.html [3]: [PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY framework https://lkml.org/lkml/2014/4/8/247 Vivek Gautam (9): dt: exynos5420: Enable support for USB 3.0 PHY controller dt: exynos5420: Enable support for DWC3 controller dt: exynos5250: Enable support for generic USB DRD phy dts: exynos5250: Update DWC3 usb controller to use new phy driver dts: exynos5250-snow: Add Vbus regulator for USB 3.0 dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0 dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0 usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config arch/arm/boot/dts/exynos5250-snow.dts | 22 ++ arch/arm/boot/dts/exynos5250.dtsi | 21 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 44 arch/arm/boot/dts/exynos5420-smdk5420.dts | 46 arch/arm/boot/dts/exynos5420.dtsi | 54 + arch/arm/configs/exynos_defconfig |1 - drivers/usb/phy/Kconfig|8 - drivers/usb/phy/Makefile |1 - drivers/usb/phy/phy-samsung-usb.h | 80 --- drivers/usb/phy/phy-samsung-usb3.c | 350 10 files changed, 175 insertions(+), 452 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c -- 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 v5 8/9] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Removing this older USB 3.0 DRD controller PHY driver, since a new driver based on generic phy framework is now available. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- This is reworked version for the patch : [PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver https://lkml.org/lkml/2014/4/8/231 Changes from V4: - Removed phy-samsung-usb3.c references in the Makefile and Kconfig. drivers/usb/phy/Kconfig|8 - drivers/usb/phy/Makefile |1 - drivers/usb/phy/phy-samsung-usb.h | 80 - drivers/usb/phy/phy-samsung-usb3.c | 350 4 files changed, 439 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 416e0c8..45c10f2 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -103,14 +103,6 @@ config SAMSUNG_USB2PHY Enable this to support Samsung USB 2.0 (High Speed) PHY controller driver for Samsung SoCs. -config SAMSUNG_USB3PHY - tristate Samsung USB 3.0 PHY controller Driver - select SAMSUNG_USBPHY - select USB_PHY - help - Enable this to support Samsung USB 3.0 (Super Speed) phy controller - for samsung SoCs. - config TWL6030_USB tristate TWL6030 USB Transceiver Driver depends on TWL4030_CORE OMAP_USB2 USB_MUSB_OMAP2PLUS diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index f8fa719..d836ef0 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -18,7 +18,6 @@ obj-$(CONFIG_AM335X_PHY_USB) += phy-am335x.o obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o obj-$(CONFIG_SAMSUNG_USB2PHY) += phy-samsung-usb2.o -obj-$(CONFIG_SAMSUNG_USB3PHY) += phy-samsung-usb3.o obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o diff --git a/drivers/usb/phy/phy-samsung-usb.h b/drivers/usb/phy/phy-samsung-usb.h index 68771bf..dd2a0b5 100644 --- a/drivers/usb/phy/phy-samsung-usb.h +++ b/drivers/usb/phy/phy-samsung-usb.h @@ -155,86 +155,6 @@ #define EXYNOS5_PHY_OTG_TUNE (0x40) -/* EXYNOS5: USB 3.0 DRD */ -#define EXYNOS5_DRD_LINKSYSTEM (0x04) - -#define LINKSYSTEM_FLADJ_MASK (0x3f 1) -#define LINKSYSTEM_FLADJ(_x) ((_x) 1) -#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 27) - -#define EXYNOS5_DRD_PHYUTMI(0x08) - -#define PHYUTMI_OTGDISABLE (0x1 6) -#define PHYUTMI_FORCESUSPEND (0x1 1) -#define PHYUTMI_FORCESLEEP (0x1 0) - -#define EXYNOS5_DRD_PHYPIPE(0x0c) - -#define EXYNOS5_DRD_PHYCLKRST (0x10) - -#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 (0x1 20) -#define PHYCLKRST_REF_SSP_EN (0x1 19) -#define PHYCLKRST_REF_CLKDIV2 (0x1 18) - -#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) -#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) -#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 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_MASK(0x3f 5) -#define PHYCLKRST_FSEL(_x) ((_x) 5) -#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 5) -#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 (0x1 4) - -#define PHYCLKRST_REFCLKSEL_MASK (0x03 2) -#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) -#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - -#define PHYCLKRST_PORTRESET(0x1 1) -#define PHYCLKRST_COMMONONN(0x1 0) - -#define EXYNOS5_DRD_PHYREG0(0x14) -#define EXYNOS5_DRD_PHYREG1(0x18) - -#define EXYNOS5_DRD_PHYPARAM0 (0x1c) - -#define PHYPARAM0_REF_USE_PAD (0x1 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
[PATCH v5 9/9] ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config
After removing the phy-samsung-usb3 driver, this config should be removed. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- arch/arm/configs/exynos_defconfig |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 4ce7b70..22cfc75 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -99,7 +99,6 @@ CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y CONFIG_USB_PHY=y CONFIG_SAMSUNG_USB2PHY=y -CONFIG_SAMSUNG_USB3PHY=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_S3C=y -- 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 v5 7/9] dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
This is first version of the patch for VBUS support for USB3DRD phy.
v5 is just and indicative of the patch-series.
arch/arm/boot/dts/exynos5420-smdk5420.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..96d99e1 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -147,6 +147,52 @@
pinctrl-0 = hdmi_hpd_irq;
};
+ pinctrl@1400 {
+ usb300_vbus_en: usb300-vbus-en {
+ samsung,pins = gpg0-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb301_vbus_en: usb301-vbus-en {
+ samsung,pins = gpg1-4;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ usb300_vbus_reg: regulator-usb300 {
+ compatible = regulator-fixed;
+ regulator-name = VBUS0;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpg0 5 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb300_vbus_en;
+ enable-active-high;
+ };
+
+ usb301_vbus_reg: regulator-usb301 {
+ compatible = regulator-fixed;
+ regulator-name = VBUS1;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpg1 4 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb301_vbus_en;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb300_vbus_reg;
+ };
+
+ phy@1250 {
+ vbus-supply = usb301_vbus_reg;
+ };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
--
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 v5 6/9] dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
This is first version of the patch for VBUS support for USB3DRD phy.
v5 is just and indicative of the patch-series.
arch/arm/boot/dts/exynos5420-peach-pit.dts | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 4d61a5e..45c0fef 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -70,6 +70,20 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ usb300_vbus_en: usb300-vbus-en {
+ samsung,pins = gph0-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb301_vbus_en: usb301-vbus-en {
+ samsung,pins = gph0-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
gpio-keys {
@@ -103,6 +117,36 @@
status = okay;
};
+ usb300_vbus_reg: regulator-usb300 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON0;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 0 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb300_vbus_en;
+ enable-active-high;
+ };
+
+ usb301_vbus_reg: regulator-usb301 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON1;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb301_vbus_en;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb300_vbus_reg;
+ };
+
+ phy@1250 {
+ vbus-supply = usb301_vbus_reg;
+ };
+
mmc@1220 {
status = okay;
num-slots = 1;
--
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 v5 4/9] dts: exynos5250: Update DWC3 usb controller to use new phy driver
Removing the dt node for older usb3 phy driver from Exynos5250
device tree and updating the dt node for DWC3 controller to
use new phy driver based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index d4254c0..d7c65e6 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -533,21 +533,8 @@
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
- usb-phy = usb2_phy usb3_phy;
- };
- };
-
- usb3_phy: usbphy@1210 {
- compatible = samsung,exynos5250-usb3phy;
- reg = 0x1210 0x100;
- clocks = clock CLK_FIN_PLL, clock CLK_USB3;
- clock-names = ext_xtal, usbdrd30;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- usbphy-sys {
- reg = 0x10040704 0x8;
+ phys = usbdrd_phy 0, usbdrd_phy 1;
+ phy-names = usb2-phy, usb3-phy;
};
};
--
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 v5 2/9] dt: exynos5420: Enable support for DWC3 controller
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f69745f..e808d1b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -733,6 +733,23 @@
samsung,power-domain = g2d_pd;
};
+ usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock CLK_USBD300;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ phys = usbdrd_phy0 0, usbdrd_phy0 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy0: phy@1210 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1210 0x100;
@@ -743,6 +760,23 @@
#phy-cells = 1;
};
+ usb@1240 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock CLK_USBD301;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1240 0x1;
+ interrupts = 0 73 0;
+ phys = usbdrd_phy1 0, usbdrd_phy1 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy1: phy@1250 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1250 0x100;
--
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 v5 3/9] dt: exynos5250: Enable support for generic USB DRD phy
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..d4254c0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -551,6 +551,16 @@
};
};
+ usbdrd_phy: phy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USB3, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
--
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 v5 1/9] dt: exynos5420: Enable support for USB 3.0 PHY controller
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..f69745f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -732,4 +732,24 @@
clock-names = secss;
samsung,power-domain = g2d_pd;
};
+
+ usbdrd_phy0: phy@1210 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USBD300, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
+
+ usbdrd_phy1: phy@1250 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1250 0x100;
+ clocks = clock CLK_USBD301, clock CLK_SCLK_USBPHY301;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x708;
+ #phy-cells = 1;
+ };
};
--
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 RFC 3/3] drm/exynos: use pending_components for components tracking
On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote: On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote: On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: Separation of the interfaces exposed by the device from the device itself seems to me a good thing. I would even consider it as a biggest advantage of this solution :) The problem of re-initialization does not seems to be relevant here, it is classic problem of coding correctness nothing more, it can appear here and in many different places. It may be a problem of coding correctless, but it's also a maintainability problem too - it makes it _much_ more difficult to ensure that everything is correct. But forcibly re-initializing all component devices instead of fixing bugs in specific drivers seems to be 'absolutely absurd' as classic says. They're *unnecessary* bugs that wouldn't even exist if it weren't for the forced-splitup of the initialisation into two separate parts that your approach mandates. Yes, I know that you're desperate to play that down, but you can't get Not true. I only try to find the best solution and the approach with multiple re-probing just to avoid potential bugs in drivers does not look to me correct. away from this fact: your approach _forces_ a split up of the initialisation into dependent two stages and that fact _alone_ adds additional complexity, and along with that additional complexity comes more opportunity for bugs. This sound so funny, just look at componentize patches - every patch adds two stage initialization for every component and the master, with forced unwinding and two levels of devres management. 'My approach' adds only one call to probe and one call to remove of components, and very simple and straightforward interface to the master. 'My approach' is very standard - during probe driver probes hardware, and registers interfaces which can be used by other drivers, for example by drm master. The only addition is reporting its readiness. Comparing to 'your approach' it is bloody simple. Also with that additional complexity comes the need to perform more tests to find those bugs, and given that most people just say okay, it boots and seems to work, that's good enough for me there is a high possibility that these kinds of bugs will take a long time to find. Volume of changes for each component and drm device management dispersed on all components makes your argument very valid for component subsystem. Btw have you observed component framework when one of the components during bind returns -EPROBE_DEFER ? In my tests it resulted in deferred probing of master and unbind/bind of other components. So lets say you have N components and the last component will be deferred K times, it results in: - K times deferring of the last component and the master, - (N - 1) * K - unbinds and binds of other components. As I wrote already, this framework was proposed for drivers which are tied together anyway, and this is case of many drivers, not only exynos. Please name them. Standalone drivers were not at my sight but I have also described in other mail how the framework can be 'improved' to support standalone drivers also. At the moment, I don't see a justification for your simplified and restrictive solution, which if used will lock drivers into that simplisitic method, and which can't ever be extended without lots of ifdeffery to having other components (such as TDA998x) attached. My objections are entirely based on where imx-drm and armada DRM are going, neither of which could ever use your implementation. Before you say that it isn't meant to deal with stuff like the TDA998x, take a moment to think about this - the Dove video subsystem was designed to support OLPC. It was primerly designed to drive a LCD screen plus an on-board VGA DAC. Everything for that is on-SoC. With that, the hardware is well known, and your solution could be used. However, then SolidRun came along and dropped a TDA998x on the LCD output pins. Suddenly, things aren't that simple, and your solution falls apart, because it can't cope with a generic component that has no knowledge of the rest of its master. This kind of scenario can happen /any/ time, and any time it does happen, your simple solution falls apart. I think I have answered you two or three times that it is not a problem to remove 'glued drivers' restriction. I desperately try to avoid accusing you for 'desperately playing down' on this subject, so I will not comment this anymore. On the other hand you have not answered quite important question - how do you plan to componentize drivers shared by different drms when one of drms is not componentized??? Regards Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH 3/3] dts: exynos5420-smdk5420: Add required VDD regulator supplies for usb
Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 96d99e1..323ce00 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -185,10 +185,30 @@
enable-active-high;
};
+ usb@1200 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+ };
+
phy@1210 {
vbus-supply = usb300_vbus_reg;
};
+ usb@1211 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+ };
+
+ usb@1212 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+ };
+
+ usb@1240 {
+ vdd33-supply = ldo9_reg;
+ vdd10-supply = ldo11_reg;
+ };
+
phy@1250 {
vbus-supply = usb301_vbus_reg;
};
--
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 1/3] dts: exynos5250: Add required VDD regulator supplies for usb
Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a794a70..2f183b8 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -363,8 +363,20 @@
samsung,audio-codec = wm8994;
};
+ usb@1200 {
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
+ };
+
usb@1211 {
samsung,vbus-gpio = gpx2 6 0;
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
+ };
+
+ usb@1212 {
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
};
dp-controller@145B {
--
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 2/3] dts: exynos5250-snow: Add required VDD regulator supplies for usb
Add required VDD 3.3V and VDD 1.0V regulator supplies to usb nodes.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd9b3b3..21d1f31 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -214,12 +214,24 @@
enable-active-high;
};
+ usb@1200 {
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
+ };
+
phy@1210 {
vbus-supply = usb3_vbus_reg;
};
usb@1211 {
samsung,vbus-gpio = gpx1 1 0;
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
+ };
+
+ usb@1212 {
+ vdd33-supply = ldo12_reg;
+ vdd10-supply = ldo15_reg;
};
fixed-rate-clocks {
--
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 0/3] dts: exynos5: Add required VDD supplies for USB
Based on for-next branch of Kgene's linux-samsung tree, with following patch series: [PATCH 0/9] Enable USB 3.0 support on Exynos5 systems https://lkml.org/lkml/2014/4/23/389 These are device tree patches corresponding to the usb driver patch-series: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators [PATCH 2/3] usb: ehci-exynos: Make provision for vdd regulators [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators Vivek Gautam (3): dts: exynos5250: Add required VDD regulator supplies for usb dts: exynos5250-snow: Add required VDD regulator supplies for usb dts: exynos5420-smdk5420: Add required VDD regulator supplies for usb arch/arm/boot/dts/exynos5250-smdk5250.dts | 12 arch/arm/boot/dts/exynos5250-snow.dts | 12 arch/arm/boot/dts/exynos5420-smdk5420.dts | 20 3 files changed, 44 insertions(+) -- 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 v2 0/4] add cpuidle support for Exynos5420
On 04/23/14 19:18, Rafael J. Wysocki wrote: On Wednesday, April 23, 2014 02:55:50 PM Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg321666.html 2. [PATCH v4] arm: exynos: generalize power register address calculation http://www.spinics.net/lists/arm-kernel/msg324024.html Changelog is in respective patches. Chander Kashyap (4): cpuidle: config: Add SOC_EXYNOS5420 entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 ++ arch/arm/mach-exynos/mcpm-exynos.c | 53 ++ drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c |3 +- 4 files changed, 59 insertions(+), 2 deletions(-) I'm assuming that the Exynos maintainers will take care of this, correct? Yeah, I will if you have any objection :-) BTW, I need to look at the dependent patches. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
Lee, On Wed, Apr 23, 2014 at 4:51 AM, Lee Jones lee.jo...@linaro.org wrote: The tps65090 regulator allows you to specify how long you want it to wait before detecting an overcurrent condition. Allow specifying that through the device tree (or through platform data). Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Michael Spang sp...@chromium.org Signed-off-by: Sean Paul seanp...@chromium.org --- Changes in v3: - Fixed kernel-doc notation for return Changes in v2: - Separated the overcurrent and retries changes into two patches. - Now set overcurrent at probe time since it doesn't change. .../devicetree/bindings/regulator/tps65090.txt | 4 ++ drivers/regulator/tps65090-regulator.c | 56 ++ include/linux/mfd/tps65090.h | 5 ++ 3 files changed, 65 insertions(+) Applied, thanks. U, Mark said that he had already applied this patch to his tree (I mentioned it in my recent summary and you can see it in this thread too). I don't see it on git.kernel.org though https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=for-next I'm worried this will cause a merge conflict if you both apply it. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).
Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Fixed kernel-doc notation for return
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- No longer open code fet_is_enabled().
- Fixed tps6090 typo.
- For loop = while true.
- Removed a set of braces.
drivers/regulator/tps65090-regulator.c | 155 +
1 file changed, 140 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca04e9f..2057e2e 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
*/
#include linux/module.h
+#include linux/delay.h
#include linux/init.h
#include linux/gpio.h
#include linux/of_gpio.h
@@ -28,7 +29,13 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
@@ -80,40 +87,158 @@ static int tps65090_reg_set_overcurrent_wait(struct
tps65090_regulator *ri,
return ret;
}
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev: Regulator device
+ *
+ * Return: 0 if ok, -ENOTRECOVERABLE if the FET power good bit did not get
+ * set, or some other -ve value if another error occurred (e.g. i2c error)
+ */
+static int tps65090_try_enable_fet(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ int ret, i;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask,
+rdev-desc-enable_mask);
+ if (ret 0) {
+ dev_err(rdev-dev, Error in updating reg %#x\n,
+ rdev-desc-enable_reg);
+ return ret;
+ }
+
+ for (i = 0; i MAX_CTRL_READ_TRIES; i++) {
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg,
+ control);
+ if (ret 0)
+ return ret;
+
+ if (!(control BIT(CTRL_TO_BIT)))
+ break;
+
+ usleep_range(1000, 1500);
+ }
+ if (!(control BIT(CTRL_PG_BIT)))
+ return -ENOTRECOVERABLE;
+
+ return 0;
+}
+
+/**
+ * tps65090_fet_enable - Enable a FET, trying a few times if it fails
+ *
+ * Some versions of the tps65090 have issues when turning on the FETs.
+ * This function goes through several steps to ensure the best chance of the
+ * FET going on. Specifically:
+ * - We'll make sure that we bump the overcurrent wait to the maximum, which
+ * increases the chances that we'll turn on properly.
+ * - We'll retry turning the FET on multiple times (turning off in between).
+ *
+ * @rdev: Regulator device
+ *
+ * Return: 0 if ok, non-zero if it fails.
+ */
+static int tps65090_fet_enable(struct regulator_dev *rdev)
+{
+ int ret, tries;
+
+ /*
+* Try enabling multiple times until we succeed since sometimes the
+* first try times out.
+*/
+ tries = 0;
+ while (true) {
+ ret = tps65090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
+
+ /* Try turning the FET off (and then on again) */
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask, 0);
+ if (ret)
+ goto err;
+
+ tries++;
+ }
+
+ if (tries)
+ dev_warn(rdev-dev, reg %#x enable ok after %d tries\n,
+rdev-desc-enable_reg, tries);
+
+ return 0;
+err:
+ dev_warn(rdev-dev, reg %#x enable failed\n, rdev-desc-enable_reg);
+ WARN_ON(1);
+
+
[RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a headache. Having two people adjusting masks and
acking interrupts is a recipe for disaster.
In the shipping kernel we had a hack to have the AP pay attention to
the IRQ but not to ack it. It also wasn't supposed to configure the
IRQ in any way. That hack allowed us to detect when the device was
charging without messing with the EC's state.
The current tps65090 infrastructure makes the above difficult, and it
was a bit of a hack to begin with. Rather than uglify the driver to
support it, just extend the driver's existing notion of no irq to
the charger. This makes the charger code poll every 2 seconds for AC
detect, which is sufficient.
For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't). If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger
drivers/power/tps65090-charger.c | 76 +++-
1 file changed, 59 insertions(+), 17 deletions(-)
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index 8fc9d6d..cc26c12 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -17,9 +17,11 @@
*/
#include linux/delay.h
#include linux/err.h
+#include linux/freezer.h
#include linux/init.h
#include linux/interrupt.h
#include linux/kernel.h
+#include linux/kthread.h
#include linux/module.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -43,11 +45,15 @@
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
+#define POLL_INTERVAL (HZ * 2)/* Used when no irq */
+
struct tps65090_charger {
struct device *dev;
int ac_online;
int prev_ac_online;
int irq;
+ struct task_struct *poll_task;
+ boolpassive_mode;
struct power_supply ac;
struct tps65090_platform_data *pdata;
};
@@ -60,6 +66,9 @@ static int tps65090_low_chrg_current(struct tps65090_charger
*charger)
{
int ret;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_write(charger-dev-parent, TPS65090_REG_CG_CTRL5,
TPS65090_NOITERM);
if (ret 0) {
@@ -75,6 +84,9 @@ static int tps65090_enable_charging(struct tps65090_charger
*charger)
int ret;
uint8_t ctrl0 = 0;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_read(charger-dev-parent, TPS65090_REG_CG_CTRL0,
ctrl0);
if (ret 0) {
@@ -98,6 +110,9 @@ static int tps65090_config_charger(struct tps65090_charger
*charger)
uint8_t intrmask = 0;
int ret;
+ if (charger-passive_mode)
+ return 0;
+
if (charger-pdata-enable_low_current_chrg) {
ret = tps65090_low_chrg_current(charger);
if (ret 0) {
@@ -175,10 +190,14 @@ static irqreturn_t tps65090_charger_isr(int irq, void
*dev_id)
}
/* Clear interrupts. */
- ret = tps65090_write(charger-dev-parent, TPS65090_REG_INTR_STS, 0x00);
- if (ret 0) {
- dev_err(charger-dev, %s(): Error in writing reg 0x%x\n,
+ if (!charger-passive_mode) {
+ ret = tps65090_write(charger-dev-parent,
+TPS65090_REG_INTR_STS, 0x00);
+ if (ret 0) {
+ dev_err(charger-dev,
+ %s(): Error in writing reg 0x%x\n,
__func__, TPS65090_REG_INTR_STS);
+ }
}
if (charger-prev_ac_online != charger-ac_online)
@@ -209,6 +228,18 @@ static struct tps65090_platform_data *
}
+static int tps65090_charger_poll_task(void *data)
+{
+ set_freezable();
+
+ while (!kthread_should_stop()) {
+ schedule_timeout_interruptible(POLL_INTERVAL);
+ try_to_freeze();
+ tps65090_charger_isr(-1, data);
+ }
+ return 0;
+}
+
static int tps65090_charger_probe(struct platform_device *pdev)
{
struct tps65090_charger *cdata;
@@ -255,22 +286,10 @@ static int tps65090_charger_probe(struct platform_device
*pdev)
}
irq = platform_get_irq(pdev, 0);
- if (irq = 0) {
- dev_warn(pdev-dev, Unable to get charger irq = %d\n, irq);
- ret = irq;
- goto fail_unregister_supply;
- }
-
+ if (irq 0)
+ irq =
Re: [RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers
Lee, On Wed, Apr 23, 2014 at 3:55 AM, Lee Jones lee.jo...@linaro.org wrote: Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. Lee, I don't mind if I apply this and send a pull request to you or I pull a tag from you with this in - what's easiest for you? I'm happy to do it. Doug, Can you send the patch-set again with all of the *-bys and ensure I'm on TO or CC please? It looks as if you've already applied 1, 3, and 4. I've sent up 2 and 5 again with collected tags. https://patchwork.kernel.org/patch/4042761/ https://patchwork.kernel.org/patch/4042751/ -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 4/4] mcpm: exynos: populate suspend and powered_up callbacks
[added Nico in CC]
On Wed, Apr 23, 2014 at 10:25:54AM +0100, Chander Kashyap wrote:
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
changes in v2:
1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
arch/arm/mach-exynos/mcpm-exynos.c | 53
1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 6c74c82..d53f597 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -272,10 +272,63 @@ static int exynos_power_down_finish(unsigned int cpu,
unsigned int cluster)
return 0; /* success: the CPU is halted */
}
+static void enable_coherency(void)
+{
+ unsigned long v, u;
+
+ asm volatile(
+ mrcp15, 0, %0, c1, c0, 1\n
+ orr%0, %0, %2\n
+ ldr%1, [%3]\n
+ and%1, %1, #0\n
+ orr%0, %0, %1\n
+ mcrp15, 0, %0, c1, c0, 1\n
+ : =r (v), =r (u)
+ : Ir (0x40), Ir (S5P_INFORM0)
+ : cc);
+}
+
+void exynos_powered_up(void)
+{
+ unsigned int mpidr, cpu, cluster;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ arch_spin_lock(exynos_mcpm_lock);
+ if (cpu_use_count[cpu][cluster] == 0)
+ cpu_use_count[cpu][cluster] = 1;
+ arch_spin_unlock(exynos_mcpm_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = exynos_pmu_cpunr(mpidr);
+
+ __raw_writel(virt_to_phys(mcpm_entry_point), REG_ENTRY_ADDR);
+
+ exynos_power_down();
+
+ /*
+ * Execution reaches here only if cpu did not power down.
+ * Hence roll back the changes done in exynos_power_down function.
+ */
+ __raw_writel(EXYNOS_CORE_LOCAL_PWR_EN,
+ EXYNOS_ARM_CORE_CONFIGURATION(cpunr));
+ set_cr(get_cr() | CR_C);
+ enable_coherency();
This is wrong:
1) MCPM would eventually reboot the CPU in question if the suspend call
returns (and restore SCTLR and ACTLR in cpu_resume), so there is 0 point
in doing that here.
2) The core would have executed out of coherency for a while so the
tlbs could be stale and you do not invalidate them. But given (1), (2)
becomes just informational. The register write must be executed
though (I guess...). Now, on restoring the SMP bit in cpu_resume
(errata 799270) I need to verify this is safe and get back to you.
Cheers,
Lorenzo
--
To unsubscribe from this list: send the line unsubscribe linux-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 6/7] arm64: mm: Implement 4 levels of translation tables
On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.
It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.
If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.
Hello Jungseok,
A few comments can be found inline...
References
--
[1]: Principles of ARM Memory Maps, White Paper, Issue C
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig |7 +
arch/arm64/include/asm/memblock.h |6 +
arch/arm64/include/asm/page.h |4 ++-
arch/arm64/include/asm/pgalloc.h | 20 +++
arch/arm64/include/asm/pgtable-hwdef.h |6 +++--
arch/arm64/include/asm/pgtable.h | 44
++--
arch/arm64/include/asm/tlb.h |8 ++
arch/arm64/kernel/head.S | 40 -
arch/arm64/kernel/traps.c |5
arch/arm64/mm/fault.c |1 +
arch/arm64/mm/mmu.c| 16 +---
11 files changed, 136 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 431acbc..7f5270b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -184,12 +184,19 @@ config ARM64_3_LEVELS
help
This feature enables 3 levels of translation tables.
+config ARM64_4_LEVELS
+ bool 4 level
+ depends on ARM64_4K_PAGES
+ help
+ This feature enables 4 levels of translation tables.
+
endchoice
config ARM64_VA_BITS
int Virtual address space size
range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS
range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS
+ range 48 48 if ARM64_4K_PAGES ARM64_4_LEVELS
help
This feature is determined by a combination of page size and
level of translation tables.
diff --git a/arch/arm64/include/asm/memblock.h
b/arch/arm64/include/asm/memblock.h
index 6afeed2..e4ac8bf 100644
--- a/arch/arm64/include/asm/memblock.h
+++ b/arch/arm64/include/asm/memblock.h
@@ -16,6 +16,12 @@
#ifndef __ASM_MEMBLOCK_H
#define __ASM_MEMBLOCK_H
+#ifndef CONFIG_ARM64_4_LEVELS
+#define MEMBLOCK_INITIAL_LIMIT PGDIR_SIZE
+#else
+#define MEMBLOCK_INITIAL_LIMIT PUD_SIZE
+#endif
+
extern void arm64_memblock_init(void);
#endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-types.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include asm/pgtable-3level-types.h
+#else
+#include asm/pgtable-4level-types.h
#endif
extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h
b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
#define check_pgt_cache()do { } while (0)
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+ return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+ BUG_ON((unsigned long)pud (PAGE_SIZE-1));
+ free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+ set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif /* CONFIG_ARM64_4_LEVELS */
+
#ifndef CONFIG_ARM64_2_LEVELS
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index 9cd86c6..ba30053 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-hwdef.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include
Re: [PATCH v2 0/7] Add cros_ec changes for newer boards
On 04/23/2014 06:32 AM, Lee Jones wrote: On Tue, 22 Apr 2014, Doug Anderson wrote: This series adds the most critical cros_ec changes for newer boards using cros_ec. Specifically: * Fixes timing/locking issues with the previously upstreamed (but never used upstream) cros_ec_spi driver. * Updates the cros_ec header file to the latest version which allows us to use newer EC features like i2c tunneling. * Adds an i2c tunnel driver to allow communication to the EC's i2c devices. This _doesn't_ get the EC driver fully up to speed with what's in the current Chromium OS trees. There are a whole slew of cleanup patches there, an addition of an LPC transport mode, and exports of functions to userspace. Once these patches land and we have functionality we can continue to pick more cleanup patches. ... Need to wait for the ARM, DT and I2C guys to review, at which point I'll be happy to take in and supply a branch for them to pull from if required. If there are no _true_ dependencies and the MFD changes can be added independently without fear of build breakages, let me know and I'll apply them separately. I believe there aren't direct dependencies between the patches. So, the MFD patches can be applied to the MFD tree and the DT patch applied to the Tegra tree. I'm simply waiting for the MFD patches to be applied before applying the DT patch so that I know the DT binding definition is fully accepted before applying a patch that uses it. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2 2/4] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
On Wed, Apr 23, 2014 at 10:25:52AM +0100, Chander Kashyap wrote: Add samsung,exynos5420 compatible string to initialize generic big-little cpuidle driver for Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com Acked-by: Daniel Lezcano daniel.lezc...@linaro.org --- drivers/cpuidle/cpuidle-big_little.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c index b45fc62..d0fac53 100644 --- a/drivers/cpuidle/cpuidle-big_little.c +++ b/drivers/cpuidle/cpuidle-big_little.c @@ -170,7 +170,8 @@ static int __init bl_idle_init(void) /* * Initialize the driver just for a compliant set of machines */ - if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7)) + if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7) + (!of_machine_is_compatible(samsung,exynos5420))) return -ENODEV; We should handle the string matching differently, we can't keep adding comparisons. Daniel raised the point already: what about the idle tables (data and number of states ?). TC2 has just a cluster state, and specific latencies, which are highly unlikely to be correct for this platform. Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-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] mmc: dw_mmc: Don't print data errors
Seungwon / Ulf, On Wed, Apr 23, 2014 at 1:17 AM, Ulf Hansson ulf.hans...@linaro.org wrote: On 23 April 2014 01:51, Doug Anderson diand...@chromium.org wrote: Data errors are completely expected during tuning. Printing them out is confusing people looking at the kernel logs. They see things like: [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088 ...and they think something is wrong with their hardware. Remove the printouts. We'll leave it up to a higher level to report about errors. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mmc/host/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index cced599..4c8d423 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, struct mmc_data *data) data-error = -EIO; } - dev_err(host-dev, data error, status 0x%08x\n, status); + dev_dbg(host-dev, data error, status 0x%08x\n, status); The status here could be useful information about the status register, which is not considered while printing errors by the higher levels. An option could be to print the error, but not when you perform tuning. No big deal though, just a thought. Right, I could potentially put the driver into tuning mode and then suppress the errors during that time. If you request it I will do that. I will also note that there are many other error conditions in the driver that don't have such printouts. I think the general philosophy of this driver is not to print them... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking
On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote: On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote: Yes, I know that you're desperate to play that down, but you can't get Not true. I only try to find the best solution and the approach with multiple re-probing just to avoid potential bugs in drivers does not look to me correct. away from this fact: your approach _forces_ a split up of the initialisation into dependent two stages and that fact _alone_ adds additional complexity, and along with that additional complexity comes more opportunity for bugs. This sound so funny, just look at componentize patches - every patch adds two stage initialization for every component and the master, with forced unwinding and two levels of devres management. *Sigh*. Why am I bothering discussing this with you. *NO* it does not, for the VERY SIMPLE reason that NOTHING is done before the BIND. NO structures are allocated. NOTHING is setup. The *only* thing that is done is the driver registers with the component helper. That's not two stage initialisation. That's *single* stage. 'My approach' adds only one call to probe and one call to remove of components, and very simple and straightforward interface to the master. You're talking utter garbage there. 'My approach' is very standard - during probe driver probes hardware, and registers interfaces which can be used by other drivers, for example by drm master. The only addition is reporting its readiness. Comparing to 'your approach' it is bloody simple. More unbelievable crap. Also with that additional complexity comes the need to perform more tests to find those bugs, and given that most people just say okay, it boots and seems to work, that's good enough for me there is a high possibility that these kinds of bugs will take a long time to find. Volume of changes for each component and drm device management dispersed on all components makes your argument very valid for component subsystem. Btw have you observed component framework when one of the components during bind returns -EPROBE_DEFER ? In my tests it resulted in deferred probing of master and unbind/bind of other components. So lets say you have N components and the last component will be deferred K times, it results in: - K times deferring of the last component and the master, - (N - 1) * K - unbinds and binds of other components. True, and you can't get away from that with proper behaviour. As I wrote already, this framework was proposed for drivers which are tied together anyway, and this is case of many drivers, not only exynos. Please name them. You ignored this. Therefore, I assume that you *can't* name them because there *aren't* any. I called your bluff, I win. At the moment, I don't see a justification for your simplified and restrictive solution, which if used will lock drivers into that simplisitic method, and which can't ever be extended without lots of ifdeffery to having other components (such as TDA998x) attached. My objections are entirely based on where imx-drm and armada DRM are going, neither of which could ever use your implementation. Before you say that it isn't meant to deal with stuff like the TDA998x, take a moment to think about this - the Dove video subsystem was designed to support OLPC. It was primerly designed to drive a LCD screen plus an on-board VGA DAC. Everything for that is on-SoC. With that, the hardware is well known, and your solution could be used. However, then SolidRun came along and dropped a TDA998x on the LCD output pins. Suddenly, things aren't that simple, and your solution falls apart, because it can't cope with a generic component that has no knowledge of the rest of its master. This kind of scenario can happen /any/ time, and any time it does happen, your simple solution falls apart. I think I have answered you two or three times that it is not a problem to remove 'glued drivers' restriction. I desperately try to avoid accusing you for 'desperately playing down' on this subject, so I will not comment this anymore. Right, so what I draw from this is that *you* again refuse to answer this point because despite your assertions that your solution can do it, you have no clue as to *how* it can be done. I've looked at your solution with respect to this, and I *can't* see how it can be done either. That's why I've been asking *you* the question, so that *you* can provide some technical input to it. On the other hand you have not answered quite important question - how do you plan to componentize drivers shared by different drms when one of drms is not componentized??? Read this, from a message I sent at the beginning of February: | Here's my changes to the TDA998x driver to add support for the component | helper. The TDA998x driver retains support for the old way so that | drivers can be transitioned. For any one DRM
[PATCH v3 0/3] Generic Device Tree based power domain look-up
Up till now there was no single generic method to bind devices to their power domains using Device Tree. Each platform has been doing this using its own way, example of which are Exynos power domain bindings [1] and look-up code [2]. This series is intended to change this and provide generic DT bindings for power domain specification and generic code performing look-up of power domains and binding them to devices. First two patches are the most important part of this series, as they introduce $subject. Patch 3 converts mach-exynos to use the new generic method. Further patches are adding one more user of the new code, mach-s3c64xx, with first 3 patches (4-6) required to clean-up its power domain driver a bit and last 3 patches (9-11) adding display support for Mini6410 board, including a node for display controller (FIMD) which is a power domain consumer. The design of DT bindings and provider code is heavily inspired by implementation of clock providers in Common Clock Framework, while the code binding devices to power domains by my Exynos power domain implementation (now removed by this series ;)). Successfully tested on Exynos4210-based Trats and Exynos4412-based Trats2 boards using MFC, [1] Documentation/devicetree/bindings/arm/exynos/power_domain.txt [2] arch/arm/mach-exynos/pm_domains.c Changes since v2: (http://thread.gmane.org/gmane.linux.kernel/1658926) - rebased onto current Rafael's linux-pm bleeding-edge branch, - dropped patches for s3c64xx for now. I will send them in separate series, - do not call pm_genpd_dev_need_restore(true) in genpd_bind_domain(), - fixed various stylistic issues reported in review comments. Changes since v1 (RFC): [https://lkml.org/lkml/2014/1/11/141] - rebased onto current Rafael's linux-pm bleeding-edge branch, - reordered the patches a bit (to have the generic ones first), - dropped renaming of S3C64xx power domains (as suggested by Mark Brown), - added support for deferred probing (as suggested by Stephen Boyd), - fixed several minor issues pointed by Stephen Boyd, - replaced notifiers with direct hooks in driver core to make power domain support independent from specific bus type and allow error handling. Tomasz Figa (3): base: power: Add generic OF-based power domain look-up drivercore: Bind/unbind power domain on probe/remove ARM: exynos: Move to generic power domain bindings .../bindings/arm/exynos/power_domain.txt | 12 +- .../devicetree/bindings/power/power_domain.txt | 51 arch/arm/mach-exynos/pm_domains.c | 81 +- drivers/base/dd.c | 9 +- drivers/base/power/domain.c| 283 + include/linux/pm_domain.h | 46 kernel/power/Kconfig | 4 + 7 files changed, 398 insertions(+), 88 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-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 2/3] drivercore: Bind/unbind power domain on probe/remove
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state. Since this is not limited to particular busses and specific archs/platforms, it is more convenient to do the above directly in driver core, just as done with pinctrl default configuration. This patch adds necessary code to really_probe() and __device_release_driver() to achieve this and maintain consistent stack-like ordering of operations happening when binding and unbinding a driver. Signed-off-by: Tomasz Figa t.f...@samsung.com Reviewed-by: Stephen Boyd sb...@codeaurora.org Reviewed-by: Philipp Zabel philipp.za...@gmail.com [on i.MX6 GK802] Tested-by: Philipp Zabel philipp.za...@gmail.com Reviewed-by: Mark Brown broo...@linaro.org Reviewed-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/dd.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 8986b9f..7501c42 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -23,6 +23,7 @@ #include linux/kthread.h #include linux/wait.h #include linux/async.h +#include linux/pm_domain.h #include linux/pm_runtime.h #include linux/pinctrl/devinfo.h @@ -273,6 +274,11 @@ static int really_probe(struct device *dev, struct device_driver *drv) dev-driver = drv; + /* If using genpd, bind power domain now before probing */ + ret = genpd_bind_domain(dev); + if (ret) + goto probe_failed; + /* If using pinctrl, bind pins now before probing */ ret = pinctrl_bind_pins(dev); if (ret) @@ -303,6 +309,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) probe_failed: devres_release_all(dev); driver_sysfs_remove(dev); + genpd_unbind_domain(dev); dev-driver = NULL; dev_set_drvdata(dev, NULL); @@ -513,7 +520,7 @@ static void __device_release_driver(struct device *dev) blocking_notifier_call_chain(dev-bus-p-bus_notifier, BUS_NOTIFY_UNBOUND_DRIVER, dev); - + genpd_unbind_domain(dev); } } -- 1.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-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 1/3] base: power: Add generic OF-based power domain look-up
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Reviewed-by: Mark Brown broo...@linaro.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Reviewed-by: Philipp Zabel philipp.za...@gmail.com
[on i.MX6 GK802]
Tested-by: Philipp Zabel philipp.za...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 283 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 384 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label power.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index ae098a2..7677744 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -8,6 +8,7 @@
#include linux/kernel.h
#include linux/io.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
@@ -2189,3 +2190,285 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * Device Tree based power domain providers.
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support binding
+ * of devices to these domains is supposed to register a power domain provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ * - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
+/**
+ * struct of_genpd_provider - Power domain provider registration structure
+ * @link: Entry in global list of domain providers
+ * @node: Pointer to device tree node of domain provider
+ * @xlate: Provider-specific xlate callback mapping a set of specifier cells
+ * into a power domain.
+ * @data: context pointer to be
[PATCH v3 3/3] ARM: exynos: Move to generic power domain bindings
This patch moves Exynos power domain code to use the new generic power
domain look-up framework introduced by previous patch, allowing the new
code to be compiled with CONFIG_ARCH_EXYNOS selected as well.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt | 12 ++--
arch/arm/mach-exynos/pm_domains.c | 81 +-
kernel/power/Kconfig | 2 +-
3 files changed, 7 insertions(+), 88 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b41..60f26a8 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
+- #power-domain-cells: number of cells in power domain specifier;
+must be 0.
Node of a device using power domains must have a samsung,power-domain property
defined with a phandle to respective power domain.
@@ -17,12 +19,8 @@ Example:
lcd0: power-domain-lcd0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C00 0x10;
+ #power-domain-cells = 0;
};
-Example of the node using power domain:
-
- node {
- /* ... */
- samsung,power-domain = lcd0;
- /* ... */
- };
+See Documentation/devicetree/bindings/power/power_domain.txt for description
+of consumer-side bindings.
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index fe6570e..9cad3c6 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -73,89 +73,14 @@ static int exynos_pd_power_off(struct generic_pm_domain
*domain)
return exynos_pd_power(domain, false);
}
-static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
-struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, adding to power domain %s\n, pd-pd.name);
-
- while (1) {
- ret = pm_genpd_add_device(pd-pd, dev);
- if (ret != -EAGAIN)
- break;
- cond_resched();
- }
-
- pm_genpd_dev_need_restore(dev, true);
-}
-
-static void exynos_remove_device_from_domain(struct device *dev)
-{
- struct generic_pm_domain *genpd = dev_to_genpd(dev);
- int ret;
-
- dev_dbg(dev, removing from power domain %s\n, genpd-name);
-
- while (1) {
- ret = pm_genpd_remove_device(genpd, dev);
- if (ret != -EAGAIN)
- break;
- cond_resched();
- }
-}
-
-static void exynos_read_domain_from_dt(struct device *dev)
-{
- struct platform_device *pd_pdev;
- struct exynos_pm_domain *pd;
- struct device_node *node;
-
- node = of_parse_phandle(dev-of_node, samsung,power-domain, 0);
- if (!node)
- return;
- pd_pdev = of_find_device_by_node(node);
- if (!pd_pdev)
- return;
- pd = platform_get_drvdata(pd_pdev);
- exynos_add_device_to_domain(pd, dev);
-}
-
-static int exynos_pm_notifier_call(struct notifier_block *nb,
- unsigned long event, void *data)
-{
- struct device *dev = data;
-
- switch (event) {
- case BUS_NOTIFY_BIND_DRIVER:
- if (dev-of_node)
- exynos_read_domain_from_dt(dev);
-
- break;
-
- case BUS_NOTIFY_UNBOUND_DRIVER:
- exynos_remove_device_from_domain(dev);
-
- break;
- }
- return NOTIFY_DONE;
-}
-
-static struct notifier_block platform_nb = {
- .notifier_call = exynos_pm_notifier_call,
-};
-
static __init int exynos4_pm_init_power_domain(void)
{
- struct platform_device *pdev;
struct device_node *np;
for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
struct exynos_pm_domain *pd;
int on;
- pdev = of_find_device_by_node(np);
-
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
pr_err(%s: failed to allocate memory for domain\n,
@@ -168,17 +93,13 @@ static __init int exynos4_pm_init_power_domain(void)
pd-base = of_iomap(np, 0);
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
- pd-pd.of_node = np;
-
- platform_set_drvdata(pdev, pd);
on = __raw_readl(pd-base + 0x4) S5P_INT_LOCAL_PWR_EN;
pm_genpd_init(pd-pd, NULL, !on);
+ of_genpd_add_provider(np, of_genpd_xlate_simple, pd-pd);
}
-
Re: [PATCH RFC 3/3] drm/exynos: use pending_components for components tracking
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote: So, maybe you would like to finally address *my* point about TDA998x and your solution in a way that provides a satisfactory answer. *Show* how it can be done, or *outline* how it can be done. Let me be absolutely clear *why* I'm very interested in this - and that is because I'm presently converting TDA998x and Armada DRM to use the component helpers. If your solution is better, then I'd want to convert to that instead, and let's retire the component helpers. At the moment, my belief is that your solution is *very* substandard and suboptimal precisely for the reasons I've outlined, especially when it comes to sharing a component between several drivers. So, if you *really* care, you'll stop fobbing me off on this point and provide some real technical input how you'd see your solution being used in exactly the scenario that I've been outlining several times in this thread. For example, you could show what kind of modifications you expect would be required to the _existing_ TDA998x driver to allow it to participate as a device declared in DT as an entirely separate entity, probed via the standard I2C probing methods, and then hook itself into the appropriate DRM driver. Remembering, of course, that the TDA998x device is used by more than _just_ Armada DRM. I don't care if you show it via pseudo-code or by real patch. I just want to know _how_ your solution could be used. And I won't want some silly remark like trivially or I've already answered that. I want _you_ to _show_ _how_ it can be done. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-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 7/9] drm/bridge: ptn3460: add drm_panel controls
Rob,
On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
We cannot call them like this from crtc helpers in the order you mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
sometimes panel controls needs to be done before bridge controls,
... and so on.
If you don't need a real bridge, just create one of these w/
pb-bridge==NULL, otherwise create it as a wrapper for your real
bridge.
BR,
-R
On Mon, Apr 21, 2014 at 6:39 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
Address few coding style comments from Jingoo Han
drivers/gpu/drm/bridge/Kconfig |1 +
drivers/gpu/drm/bridge/ptn3460.c| 20 +++-
drivers/gpu/drm/exynos/exynos_dp_core.c | 16
include/drm/bridge/ptn3460.h|6 --
4 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..3bc6845 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -2,4 +2,5 @@ config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index f1d2afc..3920202 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -19,6 +19,7 @@
#include linux/i2c.h
#include linux/gpio.h
#include linux/delay.h
+#include drm/drm_panel.h
#include drmP.h
#include drm_edid.h
@@ -38,6 +39,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
+ struct drm_panel *panel;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ drm_panel_pre_enable(ptn_bridge-panel);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug
before
* it is fully functional. We're forced to wait for the maximum
start up
@@ -142,6 +146,10 @@ static void ptn3460_pre_enable(struct drm_bridge
*bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ if (ptn_bridge-enabled)
+ drm_panel_enable(ptn_bridge-panel);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +161,9 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ drm_panel_disable(ptn_bridge-panel);
+ drm_panel_post_disable(ptn_bridge-panel);
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -198,6 +209,7 @@ int ptn3460_get_modes(struct drm_connector *connector)
power_off = !ptn_bridge-enabled;
ptn3460_pre_enable(ptn_bridge-bridge);
+ ptn3460_enable(ptn_bridge-bridge);
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
@@ -265,7 +277,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
};
int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+ struct i2c_client *client, struct device_node *node,
+ struct drm_panel *panel)
{
int ret;
struct drm_bridge *bridge;
@@ -324,6 +337,11 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
goto err;
}
+ if (panel) {
+ ptn_bridge-panel = panel;
+ drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+ }
+
bridge-driver_private = ptn_bridge;
encoder-bridge = bridge;
ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index dbc5ccc..4853f31 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++
Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls
Sorry for the previous reply,
Here goes the full explaination:
Rob,
On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark robdcl...@gmail.com wrote:
So what about, rather than adding drm_panel support to each bridge
individually, we introduce a drm_panel_bridge (with a form of
chaining).. ie:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
We cannot call them like this from crtc helpers in the order you mentioned,
since each individual bridge chip expects the panel controls at
different places.
I mean,
-- sometimes panel controls needs to be done before bridge
controls(ptn3460: before RST_N and PD_N)
-- sometimes in between the bridge controls (ps8622: one panel control
before SLP_N and one after SLP_N)
-- sometimes panel controls needs to be done after bridge controls.
So, putting these drm_panel controls inside individual bridge drivers will work,
but keeping them in crtc_helpers might break stuff.
Thanks and regards,
Ajay Kumar
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines
Daniel, On Wed, Apr 23, 2014 at 12:59 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BL_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- pre_enable callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- post_disable callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = pre_enable callback poweron LED unit/BL_EN = enable callback poweroff LED unit/BL_EN = disable callback poweroff LCD unit/LCD_EN = post_disable callback I don't like this. What happens when the next panel comes around that has a yet slightly different requirement? Will we introduce a new pre_pre_enable() and post_post_disable() function then? As I have already explained, these 2 callbacks are sufficient enough to take care the power up/down sequence for LVDS and eDP panels. And, definitely having just 2 callbacks enable and disable is not at all sufficient. I initially thought of using panel_simple_enable from panel-simple driver. But it doesn't go well with case wherein there are 2 regulators(one for LCD and one for LED) a BL_EN signal etc. And, often(Believe me, I have referred to both eDP panel datasheets and LVDS panel datasheets) proper powerup sequence for such panels is as mentioned below: powerup: -- power up the supply (LCD_VCC). -- start video data. -- enable backlight. powerdown -- disable backlight. -- stop video data. -- power off the supply (LCD VCC) For the above cases, if I have to somehow fit in all the required settings, it breaks the sequence and I end up getting glitches during bootup/DPMS. Also, when the drm_bridge can support pre_enable and post_disable, why not drm_panel provide that both should work in tandem? Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. -Daniel Actually, I tried implementing this for ptn3460. But, it breaks the working. As explained in the other patch(reply for Rob), we cannot truly ISOLATE the panel controls from bridge controls and keep them as seperate. They should be kept together, in the individual bridge chip drivers, so that the bridge chip driver can decide which panel control to call at what point. So, I think combining bridge chip and panel controls was really a bad idea. I will implement the basic panel controls required by the bridge as optional bridge properties via DT. By that way, at least the driver remains robust. Thanks and regards, Ajay Kumar -- To unsubscribe from this list: send the line unsubscribe linux-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/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled
Add platform device and select the correct implementation automatically
depending on wether the old samsung_clock or the common clock framework
is enabled.
This is only done for machines already using the old dclk implementation,
as everybody else should move to use dt anyway.
The machine-specific settings for the external clocks will have to be set
by somebody with knowledge about the specific hardware.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-s3c24xx/Kconfig | 22 +-
arch/arm/mach-s3c24xx/common.c | 14 ++
arch/arm/mach-s3c24xx/common.h | 2 ++
arch/arm/mach-s3c24xx/mach-anubis.c | 5 +
arch/arm/mach-s3c24xx/mach-bast.c | 5 +
arch/arm/mach-s3c24xx/mach-osiris.c | 5 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 5 +
arch/arm/mach-s3c24xx/mach-vr1000.c | 5 +
arch/arm/mach-s3c24xx/s3c244x.c | 2 ++
9 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d067f76..6036e77 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,13 @@ config PLAT_S3C24XX
help
Base platform code for any Samsung S3C24XX device
+config S3C2410_COMMON_DCLK
+ bool
+ select REGMAP_MMIO
+ help
+ Temporary symbol to build the dclk driver based on the common clock
+ framework.
+
menu SAMSUNG S3C24XX SoCs Support
comment S3C24XX SoCs
@@ -264,7 +271,8 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -345,7 +353,8 @@ config MACH_TCT_HAMMER
config MACH_VR1000
bool Thorcom VR1000
select MACH_BAST_IDE
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -530,7 +539,8 @@ config MACH_ANUBIS
bool Simtec Electronics ANUBIS
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_GPIO_EXTRA64
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
@@ -571,7 +581,8 @@ config MACH_OSIRIS
bool Simtec IM2440D20 (OSIRIS) module
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_GPIO_EXTRA128
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
@@ -643,7 +654,8 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
help
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 92a1e3a..8e930e0 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -554,3 +554,17 @@ void __init s3c2443_init_clocks(int xtal)
s3c2443_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
}
#endif
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2440) || \
+ defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dclk_resource[] = {
+ [0] = DEFINE_RES_MEM(0x5684, 0x4),
+};
+
+struct platform_device s3c2410_device_dclk = {
+ .name = s3c2410-dclk,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c2410_dclk_resource),
+ .resource = s3c2410_dclk_resource,
+};
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 3fade6d..50504c7 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -114,6 +114,8 @@ extern struct platform_device s3c2412_device_dma;
extern struct platform_device s3c2440_device_dma;
extern struct platform_device s3c2443_device_dma;
+extern struct platform_device s3c2410_device_dclk;
+
#ifdef CONFIG_S3C2412_COMMON_CLK
void __init s3c2412_common_clk_init(struct device_node *np, unsigned long
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 2a16f8f..6a1a781 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -352,6 +352,7 @@ static
[PATCH v2 4/9] dt-bindings: add documentation for s3c2410 clock controller
Describe the clock controller of s3c2410, s3c2440 and s3c2442.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Tomasz Figa t.f...@samsung.com
---
.../bindings/clock/samsung,s3c2410-clock.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
new file mode 100644
index 000..0b64ad8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
@@ -0,0 +1,50 @@
+* Samsung S3C2410 Clock Controller
+
+The S3C2410 clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to the s3c2410,
+s3c2440 and s3c2442 SoCs in the s3c24x family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - samsung,s3c2410-clock - controller compatible with S3C2410 SoC.
+ - samsung,s3c2440-clock - controller compatible with S3C2440 SoC.
+ - samsung,s3c2442-clock - controller compatible with S3C2442 SoC.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c2410-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+The xti clock used as input for the plls is generated outside the SoC. It is
+expected that is are defined using standard clock bindings with a
+clock-output-names value of xti.
+
+Example: Clock controller node:
+
+ clocks: clock-controller@4c00 {
+ compatible = samsung,s3c2410-clock;
+ reg = 0x4c00 0x20;
+ #clock-cells = 1;
+ };
+
+Example: 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 properties):
+
+ serial@50004000 {
+ compatible = samsung,s3c2440-uart;
+ reg = 0x50004000 0x4000;
+ interrupts = 1 23 3 4, 1 23 4 4;
+ clock-names = uart, clk_uart_baud2;
+ clocks = clocks PCLK_UART0, clocks PCLK_UART0;
+ status = disabled;
+ };
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/9] clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442
This driver can handle the clock controllers of the socs mentioned above,
as they share a common clock tree with only small differences.
The clock structure is built according to the manuals of the included
SoCs and might include changes in comparison to the previous clock
structure.
As pll-rate-tables only the 12mhz variants are currently included.
The original code was wrongly checking for 169mhz xti values [a 0 to much
at the end], so the original 16mhz pll table would have never been
included and its values are so obscure that I have no possibility to
at least check their sane-ness. When using the formula from the manual
the resulting frequency is near the table value but still slightly off.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/Makefile| 1 +
drivers/clk/samsung/clk-s3c2410.c | 477
include/dt-bindings/clock/s3c2410.h | 62 +
3 files changed, 540 insertions(+)
create mode 100644 drivers/clk/samsung/clk-s3c2410.c
create mode 100644 include/dt-bindings/clock/s3c2410.h
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 9892de4..2cb62f8 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
+obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o
diff --git a/drivers/clk/samsung/clk-s3c2410.c
b/drivers/clk/samsung/clk-s3c2410.c
new file mode 100644
index 000..7b41821
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c2410.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (c) 2013 Heiko Stuebner he...@sntech.de
+ *
+ * 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.
+ *
+ * Common Clock Framework support for S3C2410 and following SoCs.
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/syscore_ops.h
+
+#include dt-bindings/clock/s3c2410.h
+
+#include clk.h
+#include clk-pll.h
+
+#define LOCKTIME 0x00
+#define MPLLCON0x04
+#define UPLLCON0x08
+#define CLKCON 0x0c
+#define CLKSLOW0x10
+#define CLKDIVN0x14
+#define CAMDIVN0x18
+
+/* the soc types */
+enum supported_socs {
+ S3C2410,
+ S3C2440,
+ S3C2442,
+};
+
+/* list of PLLs to be registered */
+enum s3c2410_plls {
+ mpll, upll,
+};
+
+static void __iomem *reg_base;
+
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *s3c2410_save;
+
+/*
+ * list of controller registers to be saved and restored during a
+ * suspend/resume cycle.
+ */
+static unsigned long s3c2410_clk_regs[] __initdata = {
+ LOCKTIME,
+ MPLLCON,
+ UPLLCON,
+ CLKCON,
+ CLKSLOW,
+ CLKDIVN,
+ CAMDIVN,
+};
+
+static int s3c2410_clk_suspend(void)
+{
+ samsung_clk_save(reg_base, s3c2410_save,
+ ARRAY_SIZE(s3c2410_clk_regs));
+
+ return 0;
+}
+
+static void s3c2410_clk_resume(void)
+{
+ samsung_clk_restore(reg_base, s3c2410_save,
+ ARRAY_SIZE(s3c2410_clk_regs));
+}
+
+static struct syscore_ops s3c2410_clk_syscore_ops = {
+ .suspend = s3c2410_clk_suspend,
+ .resume = s3c2410_clk_resume,
+};
+
+static void s3c2410_clk_sleep_init(void)
+{
+ s3c2410_save = samsung_clk_alloc_reg_dump(s3c2410_clk_regs,
+ ARRAY_SIZE(s3c2410_clk_regs));
+ if (!s3c2410_save) {
+ pr_warn(%s: failed to allocate sleep save data, no sleep
support!\n,
+ __func__);
+ return;
+ }
+
+ register_syscore_ops(s3c2410_clk_syscore_ops);
+ return;
+}
+#else
+static void s3c2410_clk_sleep_init(void) {}
+#endif
+
+PNAME(fclk_p) = { mpll, div_slow };
+
+struct samsung_mux_clock s3c2410_common_muxes[] __initdata = {
+ MUX(FCLK, fclk, fclk_p, CLKSLOW, 4, 1),
+};
+
+static struct clk_div_table divslow_d[] = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 2 },
+ { .val = 2, .div = 4 },
+ { .val = 3, .div = 6 },
+ { .val = 4, .div = 8 },
+ { .val = 5, .div = 10 },
+ { .val = 6, .div = 12 },
+ { .val = 7, .div = 14 },
+ { /* sentinel */ },
+};
+
+struct samsung_div_clock s3c2410_common_dividers[] __initdata = {
+ DIV_T(0, div_slow, xti, CLKSLOW, 0, 3, divslow_d),
+ DIV(PCLK, pclk, hclk, CLKDIVN, 0, 1),
+};
+
+struct
[PATCH v2 6/9] ARM: S3C24XX: add platform code for conversion to the common clock framework
This adds the necessary init functions to init the clocks from the common
clock framework and necessary CONFIG_SAMSUNG_CLOCK ifdefs around the legacy
clock code.
This also includes empty stubs for the *_setup_clocks functions that are
called from the cpufreq driver on resume.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-s3c24xx/Kconfig | 5 +
arch/arm/mach-s3c24xx/common.c | 25 +
arch/arm/mach-s3c24xx/common.h | 7 +++
arch/arm/mach-s3c24xx/s3c2410.c | 6 ++
arch/arm/mach-s3c24xx/s3c2442.c | 3 ++-
arch/arm/mach-s3c24xx/s3c244x.c | 6 ++
6 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 6036e77..daab788 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,11 @@ config PLAT_S3C24XX
help
Base platform code for any Samsung S3C24XX device
+config S3C2410_COMMON_CLK
+ bool
+ help
+ Build the s3c2410 clock driver based on the common clock framework.
+
config S3C2410_COMMON_DCLK
bool
select REGMAP_MMIO
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 8e930e0..5307bb7 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -53,6 +53,7 @@
#include plat/cpu-freq.h
#include plat/pll.h
#include plat/pwm-core.h
+#include plat/watchdog-reset.h
#include common.h
@@ -534,6 +535,14 @@ struct platform_device s3c2443_device_dma = {
};
#endif
+#if defined(CONFIG_COMMON_CLK) defined(CONFIG_CPU_S3C2410)
+void __init s3c2410_init_clocks(int xtal)
+{
+ s3c2410_common_clk_init(NULL, xtal, 0, S3C24XX_VA_CLKPWR);
+ samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
#ifdef CONFIG_CPU_S3C2412
void __init s3c2412_init_clocks(int xtal)
{
@@ -548,6 +557,22 @@ void __init s3c2416_init_clocks(int xtal)
}
#endif
+#if defined(CONFIG_COMMON_CLK) defined(CONFIG_CPU_S3C2440)
+void __init s3c2440_init_clocks(int xtal)
+{
+ s3c2410_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
+ samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
+#if defined(CONFIG_COMMON_CLK) defined(CONFIG_CPU_S3C2442)
+void __init s3c2442_init_clocks(int xtal)
+{
+ s3c2410_common_clk_init(NULL, xtal, 2, S3C24XX_VA_CLKPWR);
+ samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
+}
+#endif
+
#ifdef CONFIG_CPU_S3C2443
void __init s3c2443_init_clocks(int xtal)
{
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 50504c7..2d65541 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -77,6 +77,7 @@ extern void s3c244x_restart(enum reboot_mode mode, const char
*cmd);
#ifdef CONFIG_CPU_S3C2440
extern int s3c2440_init(void);
extern void s3c2440_map_io(void);
+extern void s3c2440_init_clocks(int xtal);
extern void s3c2440_init_irq(void);
#else
#define s3c2440_init NULL
@@ -86,6 +87,7 @@ extern void s3c2440_init_irq(void);
#ifdef CONFIG_CPU_S3C2442
extern int s3c2442_init(void);
extern void s3c2442_map_io(void);
+extern void s3c2442_init_clocks(int xtal);
extern void s3c2442_init_irq(void);
#else
#define s3c2442_init NULL
@@ -116,6 +118,11 @@ extern struct platform_device s3c2443_device_dma;
extern struct platform_device s3c2410_device_dclk;
+#ifdef CONFIG_S3C2410_COMMON_CLK
+void __init s3c2410_common_clk_init(struct device_node *np, unsigned long
xti_f,
+ int current_soc,
+ void __iomem *reg_base);
+#endif
#ifdef CONFIG_S3C2412_COMMON_CLK
void __init s3c2412_common_clk_init(struct device_node *np, unsigned long
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/s3c2410.c b/arch/arm/mach-s3c24xx/s3c2410.c
index ffb92cbc..a1ce4b0 100644
--- a/arch/arm/mach-s3c24xx/s3c2410.c
+++ b/arch/arm/mach-s3c24xx/s3c2410.c
@@ -83,6 +83,7 @@ void __init s3c2410_map_io(void)
iotable_init(s3c2410_iodesc, ARRAY_SIZE(s3c2410_iodesc));
}
+#ifdef CONFIG_SAMSUNG_CLOCK
void __init_or_cpufreq s3c2410_setup_clocks(void)
{
struct clk *xtal_clk;
@@ -142,6 +143,11 @@ void __init s3c2410_init_clocks(int xtal)
clkdev_add_table(s3c2410_clk_lookup, ARRAY_SIZE(s3c2410_clk_lookup));
samsung_wdt_reset_init(S3C24XX_VA_WATCHDOG);
}
+#else
+void __init_or_cpufreq s3c2410_setup_clocks(void)
+{
+}
+#endif
struct bus_type s3c2410_subsys = {
.name = s3c2410-core,
diff --git a/arch/arm/mach-s3c24xx/s3c2442.c b/arch/arm/mach-s3c24xx/s3c2442.c
index 2c8adc0..564c6503 100644
--- a/arch/arm/mach-s3c24xx/s3c2442.c
+++ b/arch/arm/mach-s3c24xx/s3c2442.c
@@ -53,6 +53,7 @@
#include common.h
+#ifdef CONFIG_SAMSUNG_CLOCK
/* S3C2442 extended clock support */
static unsigned long s3c2442_camif_upll_round(struct clk *clk,
@@ -162,7 +163,7 @@
[PATCH v2 7/9] ARM: S3C24XX: convert s3c2440 and s3c2442 to common clock framework
Convert all machines using these cpus to use the ccf clock driver
instead of the legacy Samsung clock implementation.
Some of the more esotheric machines will probably need a fixup, as they
do strange things to the clkout outputs, that I did not really understand
nor have the hardware to check.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-s3c24xx/Kconfig | 8
arch/arm/mach-s3c24xx/Makefile | 4 ++--
arch/arm/mach-s3c24xx/common.c | 4
arch/arm/mach-s3c24xx/mach-anubis.c| 10 +++---
arch/arm/mach-s3c24xx/mach-at2440evb.c | 10 +++---
arch/arm/mach-s3c24xx/mach-gta02.c | 8 ++--
arch/arm/mach-s3c24xx/mach-mini2440.c | 10 +++---
arch/arm/mach-s3c24xx/mach-nexcoder.c | 15 ---
arch/arm/mach-s3c24xx/mach-osiris.c| 10 +++---
arch/arm/mach-s3c24xx/mach-rx1950.c| 10 +++---
arch/arm/mach-s3c24xx/mach-rx3715.c| 10 +++---
arch/arm/mach-s3c24xx/mach-smdk2440.c | 10 +++---
12 files changed, 73 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index daab788..96d1e54 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -73,10 +73,10 @@ config CPU_S3C2416
config CPU_S3C2440
bool SAMSUNG S3C2440
- depends on SAMSUNG_CLOCK
+ select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2440
- select S3C2410_CLOCK
+ select S3C2410_COMMON_CLK
select S3C2410_PM if PM
select S3C2440_DMA if S3C24XX_DMA
help
@@ -84,10 +84,10 @@ config CPU_S3C2440
config CPU_S3C2442
bool SAMSUNG S3C2442
- depends on SAMSUNG_CLOCK
+ select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2440
- select S3C2410_CLOCK
+ select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select S3C2410_PM if PM
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index f254797..9010eba 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -29,9 +29,9 @@ obj-$(CONFIG_S3C2412_PM_SLEEP)+= sleep-s3c2412.o
obj-$(CONFIG_CPU_S3C2416) += s3c2416.o
obj-$(CONFIG_S3C2416_PM) += pm-s3c2416.o
-obj-$(CONFIG_CPU_S3C2440) += s3c2440.o clock-s3c2440.o
+obj-$(CONFIG_CPU_S3C2440) += s3c2440.o
obj-$(CONFIG_CPU_S3C2442) += s3c2442.o
-obj-$(CONFIG_CPU_S3C244X) += s3c244x.o clock-s3c244x.o
+obj-$(CONFIG_CPU_S3C244X) += s3c244x.o
obj-$(CONFIG_S3C2440_DMA) += dma-s3c2440.o
obj-$(CONFIG_S3C2440_PLL_1200) += pll-s3c2440-1200.o
obj-$(CONFIG_S3C2440_PLL_16934400) += pll-s3c2440-16934400.o
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 5307bb7..def8627 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -92,7 +92,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3244,
.idmask = 0x,
.map_io = s3c2440_map_io,
- .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init = s3c2440_init,
.name = name_s3c2440
@@ -101,7 +100,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440001,
.idmask = 0x,
.map_io = s3c2440_map_io,
- .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init = s3c2440_init,
.name = name_s3c2440a
@@ -110,7 +108,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440aaa,
.idmask = 0x,
.map_io = s3c2442_map_io,
- .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init = s3c2442_init,
.name = name_s3c2442
@@ -119,7 +116,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32440aab,
.idmask = 0x,
.map_io = s3c2442_map_io,
- .init_clocks= s3c244x_init_clocks,
.init_uarts = s3c244x_init_uarts,
.init = s3c2442_init,
.name = name_s3c2442b
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 6a1a781..6b4f188 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -46,7 +46,6 @@
#include net/ax88796.h
-#include plat/clock.h
#include plat/devs.h
#include plat/cpu.h
#include linux/platform_data/asoc-s3c24xx_simtec.h
@@
[PATCH v2 8/9] ARM: S3C24XX: convert s3c2410 to common clock framework
Convert the machines using the s3c2410 to use the new driver based
on the common clock framework instead of the legacy Samsung clock driver.
As with the s3c244x, machines using the clkout output will need a fixup
from someone with the hardware.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-s3c24xx/Kconfig | 4 ++--
arch/arm/mach-s3c24xx/common.c | 2 --
arch/arm/mach-s3c24xx/mach-amlm5900.c | 9 +++--
arch/arm/mach-s3c24xx/mach-bast.c | 10 +++---
arch/arm/mach-s3c24xx/mach-h1940.c | 10 +++---
arch/arm/mach-s3c24xx/mach-n30.c| 12
arch/arm/mach-s3c24xx/mach-nexcoder.c | 7 +--
arch/arm/mach-s3c24xx/mach-otom.c | 10 +++---
arch/arm/mach-s3c24xx/mach-qt2410.c | 9 +++--
arch/arm/mach-s3c24xx/mach-smdk2410.c | 9 +++--
arch/arm/mach-s3c24xx/mach-tct_hammer.c | 9 +++--
arch/arm/mach-s3c24xx/mach-vr1000.c | 10 +++---
12 files changed, 67 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 96d1e54..57ebb13 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -37,10 +37,10 @@ comment S3C24XX SoCs
config CPU_S3C2410
bool SAMSUNG S3C2410
default y
- depends on SAMSUNG_CLOCK
+ select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
- select S3C2410_CLOCK
+ select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index def8627..a7b1269 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -74,7 +74,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3241,
.idmask = 0x,
.map_io = s3c2410_map_io,
- .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init = s3c2410_init,
.name = name_s3c2410
@@ -83,7 +82,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32410002,
.idmask = 0x,
.map_io = s3c2410_map_io,
- .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init = s3c2410a_init,
.name = name_s3c2410a
diff --git a/arch/arm/mach-s3c24xx/mach-amlm5900.c
b/arch/arm/mach-s3c24xx/mach-amlm5900.c
index 284ea1f..0e175e0 100644
--- a/arch/arm/mach-s3c24xx/mach-amlm5900.c
+++ b/arch/arm/mach-s3c24xx/mach-amlm5900.c
@@ -161,11 +161,16 @@ static struct platform_device *amlm5900_devices[]
__initdata = {
static void __init amlm5900_map_io(void)
{
s3c24xx_init_io(amlm5900_iodesc, ARRAY_SIZE(amlm5900_iodesc));
- s3c24xx_init_clocks(0);
s3c24xx_init_uarts(amlm5900_uartcfgs, ARRAY_SIZE(amlm5900_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
}
+static void __init amlm5900_init_time(void)
+{
+ s3c2410_init_clocks(1200);
+ samsung_timer_init();
+}
+
#ifdef CONFIG_FB_S3C2410
static struct s3c2410fb_display __initdata amlm5900_lcd_info = {
.width = 160,
@@ -241,6 +246,6 @@ MACHINE_START(AML_M5900, AML_M5900)
.map_io = amlm5900_map_io,
.init_irq = s3c2410_init_irq,
.init_machine = amlm5900_init,
- .init_time = samsung_timer_init,
+ .init_time = amlm5900_init_time,
.restart= s3c2410_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c
b/arch/arm/mach-s3c24xx/mach-bast.c
index 13e078c..ab075a6 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -50,7 +50,6 @@
#include mach/regs-lcd.h
#include mach/gpio-samsung.h
-#include plat/clock.h
#include plat/cpu.h
#include plat/cpu-freq.h
#include plat/devs.h
@@ -581,11 +580,16 @@ static void __init bast_map_io(void)
s3c_hwmon_set_platdata(bast_hwmon_info);
s3c24xx_init_io(bast_iodesc, ARRAY_SIZE(bast_iodesc));
- s3c24xx_init_clocks(0);
s3c24xx_init_uarts(bast_uartcfgs, ARRAY_SIZE(bast_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
}
+static void __init bast_init_time(void)
+{
+ s3c2410_init_clocks(1200);
+ samsung_timer_init();
+}
+
static void __init bast_init(void)
{
register_syscore_ops(bast_pm_syscore_ops);
@@ -613,6 +617,6 @@ MACHINE_START(BAST, Simtec-BAST)
.map_io = bast_map_io,
.init_irq = s3c2410_init_irq,
.init_machine = bast_init,
- .init_time = samsung_timer_init,
+ .init_time =
[PATCH v2 9/9] ARM: S3C24XX: remove legacy clock code
With the move to the common clock framework completed for s3c2410, s3c2440
and s3c2442, the legacy clock code for these machines can go away too.
This also includes the legacy dclk code, as all legacy users are converted.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-s3c24xx/Kconfig | 11 -
arch/arm/mach-s3c24xx/Makefile | 2 -
arch/arm/mach-s3c24xx/clock-dclk.c | 195
arch/arm/mach-s3c24xx/clock-s3c2410.c | 285
arch/arm/mach-s3c24xx/clock-s3c2440.c | 217 --
arch/arm/mach-s3c24xx/clock-s3c244x.c | 141
arch/arm/mach-s3c24xx/common.h | 2 -
arch/arm/mach-s3c24xx/include/mach/regs-clock.h | 18 --
arch/arm/mach-s3c24xx/include/mach/regs-gpio.h | 3 -
arch/arm/mach-s3c24xx/pm.c | 12 -
arch/arm/mach-s3c24xx/s3c2410.c | 62 --
arch/arm/mach-s3c24xx/s3c2442.c | 112 --
arch/arm/mach-s3c24xx/s3c244x.c | 63 --
13 files changed, 1123 deletions(-)
delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 57ebb13..02b1adf 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -110,17 +110,6 @@ config CPU_S3C2443
# common code
-config S3C2410_CLOCK
- bool
- help
- Clock code for the S3C2410, and similar processors which
- is currently includes the S3C2410, S3C2440, S3C2442.
-
-config S3C24XX_DCLK
- bool
- help
- Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
-
config S3C24XX_SMDK
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 9010eba..2235d0d 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -44,10 +44,8 @@ obj-$(CONFIG_PM) += pm.o irq-pm.o sleep.o
# common code
-obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
obj-$(CONFIG_S3C24XX_DMA) += dma.o
-obj-$(CONFIG_S3C2410_CLOCK)+= clock-s3c2410.o
obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
obj-$(CONFIG_S3C2410_IOTIMING) += iotiming-s3c2410.o
diff --git a/arch/arm/mach-s3c24xx/clock-dclk.c
b/arch/arm/mach-s3c24xx/clock-dclk.c
deleted file mode 100644
index 1edd9b2..000
--- a/arch/arm/mach-s3c24xx/clock-dclk.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * Copyright (c) 2004-2008 Simtec Electronics
- * Ben Dooks b...@simtec.co.uk
- * http://armlinux.simtec.co.uk/
- *
- * 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.
- *
- * S3C24XX - definitions for DCLK and CLKOUT registers
- */
-
-#include linux/kernel.h
-#include linux/errno.h
-#include linux/clk.h
-#include linux/io.h
-
-#include mach/regs-clock.h
-#include mach/regs-gpio.h
-
-#include plat/clock.h
-#include plat/cpu.h
-
-/* clocks that could be registered by external code */
-
-static int s3c24xx_dclk_enable(struct clk *clk, int enable)
-{
- unsigned long dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
- if (enable)
- dclkcon |= clk-ctrlbit;
- else
- dclkcon = ~clk-ctrlbit;
-
- __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
- return 0;
-}
-
-static int s3c24xx_dclk_setparent(struct clk *clk, struct clk *parent)
-{
- unsigned long dclkcon;
- unsigned int uclk;
-
- if (parent == clk_upll)
- uclk = 1;
- else if (parent == clk_p)
- uclk = 0;
- else
- return -EINVAL;
-
- clk-parent = parent;
-
- dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
- if (clk-ctrlbit == S3C2410_DCLKCON_DCLK0EN) {
- if (uclk)
- dclkcon |= S3C2410_DCLKCON_DCLK0_UCLK;
- else
- dclkcon = ~S3C2410_DCLKCON_DCLK0_UCLK;
- } else {
- if (uclk)
- dclkcon |= S3C2410_DCLKCON_DCLK1_UCLK;
- else
- dclkcon = ~S3C2410_DCLKCON_DCLK1_UCLK;
- }
-
- __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
- return 0;
-}
-static unsigned long s3c24xx_calc_div(struct clk *clk, unsigned long rate)
-{
- unsigned long div;
-
- if ((rate == 0) || !clk-parent)
- return 0;
-
- div = clk_get_rate(clk-parent) / rate;
- if (div 2)
- div = 2;
- else if (div 16)
- div = 16;
-
- return div;
-}
-
-static unsigned long s3c24xx_round_dclk_rate(struct clk *clk,
- unsigned
[PATCH v2.1 3/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled
Add platform device and select the correct implementation automatically
depending on wether the old samsung_clock or the common clock framework
is enabled.
This is only done for machines already using the old dclk implementation,
as everybody else should move to use dt anyway.
The machine-specific settings for the external clocks will have to be set
by somebody with knowledge about the specific hardware.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
adapted to apply against v3.16-next/clk-s3c24xx
arch/arm/mach-s3c24xx/Kconfig | 22 +-
arch/arm/mach-s3c24xx/common.c | 14 ++
arch/arm/mach-s3c24xx/common.h | 2 ++
arch/arm/mach-s3c24xx/mach-anubis.c | 5 +
arch/arm/mach-s3c24xx/mach-bast.c | 5 +
arch/arm/mach-s3c24xx/mach-osiris.c | 5 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 5 +
arch/arm/mach-s3c24xx/mach-vr1000.c | 5 +
arch/arm/mach-s3c24xx/s3c244x.c | 2 ++
9 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d067f76..6036e77 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -18,6 +18,13 @@ config PLAT_S3C24XX
help
Base platform code for any Samsung S3C24XX device
+config S3C2410_COMMON_DCLK
+ bool
+ select REGMAP_MMIO
+ help
+ Temporary symbol to build the dclk driver based on the common clock
+ framework.
+
menu SAMSUNG S3C24XX SoCs Support
comment S3C24XX SoCs
@@ -264,7 +271,8 @@ config ARCH_BAST
select ISA
select MACH_BAST_IDE
select S3C2410_IOTIMING if ARM_S3C2410_CPUFREQ
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -345,7 +353,8 @@ config MACH_TCT_HAMMER
config MACH_VR1000
bool Thorcom VR1000
select MACH_BAST_IDE
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_NOR
select S3C24XX_SIMTEC_PM if PM
select S3C24XX_SIMTEC_USB
@@ -530,7 +539,8 @@ config MACH_ANUBIS
bool Simtec Electronics ANUBIS
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_1200
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
help
@@ -571,7 +581,8 @@ config MACH_OSIRIS
bool Simtec IM2440D20 (OSIRIS) module
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_1200
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C2410_COMMON_DCLK if COMMON_CLK
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
select S3C_DEV_USB_HOST
@@ -643,7 +654,8 @@ config MACH_RX1950
select PM_H1940 if PM
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_16934400
- select S3C24XX_DCLK
+ select S3C24XX_DCLK if SAMSUNG_CLOCK
+ select S3C24XX_COMMON_DCLK if COMMON_CLK
select S3C24XX_PWM
select S3C_DEV_NAND
help
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 92a1e3a..8e930e0 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -554,3 +554,17 @@ void __init s3c2443_init_clocks(int xtal)
s3c2443_common_clk_init(NULL, xtal, 1, S3C24XX_VA_CLKPWR);
}
#endif
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2440) || \
+ defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dclk_resource[] = {
+ [0] = DEFINE_RES_MEM(0x5684, 0x4),
+};
+
+struct platform_device s3c2410_device_dclk = {
+ .name = s3c2410-dclk,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c2410_dclk_resource),
+ .resource = s3c2410_dclk_resource,
+};
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 3fade6d..50504c7 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -114,6 +114,8 @@ extern struct platform_device s3c2412_device_dma;
extern struct platform_device s3c2440_device_dma;
extern struct platform_device s3c2443_device_dma;
+extern struct platform_device s3c2410_device_dclk;
+
#ifdef CONFIG_S3C2412_COMMON_CLK
void __init s3c2412_common_clk_init(struct device_node *np, unsigned long
xti_f,
unsigned long ext_f, void __iomem *reg_base);
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c
b/arch/arm/mach-s3c24xx/mach-anubis.c
index 2a16f8f..6a1a781 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@
[PATCH v2.1 8/9] ARM: S3C24XX: convert s3c2410 to common clock framework
Convert the machines using the s3c2410 to use the new driver based
on the common clock framework instead of the legacy Samsung clock driver.
As with the s3c244x, machines using the clkout output will need a fixup
from someone with the hardware.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
adapted to apply against v3.16-next/clk-s3c24xx
arch/arm/mach-s3c24xx/Kconfig | 4 ++--
arch/arm/mach-s3c24xx/common.c | 2 --
arch/arm/mach-s3c24xx/mach-amlm5900.c | 9 +++--
arch/arm/mach-s3c24xx/mach-bast.c | 10 +++---
arch/arm/mach-s3c24xx/mach-h1940.c | 10 +++---
arch/arm/mach-s3c24xx/mach-n30.c| 12
arch/arm/mach-s3c24xx/mach-nexcoder.c | 7 +--
arch/arm/mach-s3c24xx/mach-otom.c | 10 +++---
arch/arm/mach-s3c24xx/mach-qt2410.c | 9 +++--
arch/arm/mach-s3c24xx/mach-smdk2410.c | 9 +++--
arch/arm/mach-s3c24xx/mach-tct_hammer.c | 9 +++--
arch/arm/mach-s3c24xx/mach-vr1000.c | 10 +++---
12 files changed, 67 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 96d1e54..57ebb13 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -37,10 +37,10 @@ comment S3C24XX SoCs
config CPU_S3C2410
bool SAMSUNG S3C2410
default y
- depends on SAMSUNG_CLOCK
+ select COMMON_CLK
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
- select S3C2410_CLOCK
+ select S3C2410_COMMON_CLK
select S3C2410_DMA if S3C24XX_DMA
select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index def8627..a7b1269 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -74,7 +74,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x3241,
.idmask = 0x,
.map_io = s3c2410_map_io,
- .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init = s3c2410_init,
.name = name_s3c2410
@@ -83,7 +82,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = 0x32410002,
.idmask = 0x,
.map_io = s3c2410_map_io,
- .init_clocks= s3c2410_init_clocks,
.init_uarts = s3c2410_init_uarts,
.init = s3c2410a_init,
.name = name_s3c2410a
diff --git a/arch/arm/mach-s3c24xx/mach-amlm5900.c
b/arch/arm/mach-s3c24xx/mach-amlm5900.c
index 284ea1f..0e175e0 100644
--- a/arch/arm/mach-s3c24xx/mach-amlm5900.c
+++ b/arch/arm/mach-s3c24xx/mach-amlm5900.c
@@ -161,11 +161,16 @@ static struct platform_device *amlm5900_devices[]
__initdata = {
static void __init amlm5900_map_io(void)
{
s3c24xx_init_io(amlm5900_iodesc, ARRAY_SIZE(amlm5900_iodesc));
- s3c24xx_init_clocks(0);
s3c24xx_init_uarts(amlm5900_uartcfgs, ARRAY_SIZE(amlm5900_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
}
+static void __init amlm5900_init_time(void)
+{
+ s3c2410_init_clocks(1200);
+ samsung_timer_init();
+}
+
#ifdef CONFIG_FB_S3C2410
static struct s3c2410fb_display __initdata amlm5900_lcd_info = {
.width = 160,
@@ -241,6 +246,6 @@ MACHINE_START(AML_M5900, AML_M5900)
.map_io = amlm5900_map_io,
.init_irq = s3c2410_init_irq,
.init_machine = amlm5900_init,
- .init_time = samsung_timer_init,
+ .init_time = amlm5900_init_time,
.restart= s3c2410_restart,
MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c
b/arch/arm/mach-s3c24xx/mach-bast.c
index 13e078c..ab075a6 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -50,7 +50,6 @@
#include mach/regs-lcd.h
#include mach/gpio-samsung.h
-#include plat/clock.h
#include plat/cpu.h
#include plat/cpu-freq.h
#include plat/devs.h
@@ -581,11 +580,16 @@ static void __init bast_map_io(void)
s3c_hwmon_set_platdata(bast_hwmon_info);
s3c24xx_init_io(bast_iodesc, ARRAY_SIZE(bast_iodesc));
- s3c24xx_init_clocks(0);
s3c24xx_init_uarts(bast_uartcfgs, ARRAY_SIZE(bast_uartcfgs));
samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
}
+static void __init bast_init_time(void)
+{
+ s3c2410_init_clocks(1200);
+ samsung_timer_init();
+}
+
static void __init bast_init(void)
{
register_syscore_ops(bast_pm_syscore_ops);
@@ -613,6 +617,6 @@ MACHINE_START(BAST, Simtec-BAST)
.map_io = bast_map_io,
.init_irq = s3c2410_init_irq,
.init_machine = bast_init,
- .init_time =
[PATCH v2.1 9/9] ARM: S3C24XX: remove legacy clock code
With the move to the common clock framework completed for s3c2410, s3c2440
and s3c2442, the legacy clock code for these machines can go away too.
This also includes the legacy dclk code, as all legacy users are converted.
Signed-off-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
adapted to apply against v3.16-next/clk-s3c24xx
arch/arm/mach-s3c24xx/Kconfig | 11 -
arch/arm/mach-s3c24xx/Makefile | 2 -
arch/arm/mach-s3c24xx/clock-dclk.c | 195
arch/arm/mach-s3c24xx/clock-s3c2410.c | 284
arch/arm/mach-s3c24xx/clock-s3c2440.c | 217 --
arch/arm/mach-s3c24xx/clock-s3c244x.c | 141
arch/arm/mach-s3c24xx/common.h | 2 -
arch/arm/mach-s3c24xx/include/mach/regs-clock.h | 18 --
arch/arm/mach-s3c24xx/include/mach/regs-gpio.h | 3 -
arch/arm/mach-s3c24xx/pm.c | 12 -
arch/arm/mach-s3c24xx/s3c2410.c | 62 --
arch/arm/mach-s3c24xx/s3c2442.c | 112 --
arch/arm/mach-s3c24xx/s3c244x.c | 63 --
13 files changed, 1122 deletions(-)
delete mode 100644 arch/arm/mach-s3c24xx/clock-dclk.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2410.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2440.c
delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c244x.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 7b99740..77b0fb5 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -110,17 +110,6 @@ config CPU_S3C2443
# common code
-config S3C2410_CLOCK
- bool
- help
- Clock code for the S3C2410, and similar processors which
- is currently includes the S3C2410, S3C2440, S3C2442.
-
-config S3C24XX_DCLK
- bool
- help
- Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
-
config S3C24XX_SMDK
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 9010eba..2235d0d 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -44,10 +44,8 @@ obj-$(CONFIG_PM) += pm.o irq-pm.o sleep.o
# common code
-obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
obj-$(CONFIG_S3C24XX_DMA) += dma.o
-obj-$(CONFIG_S3C2410_CLOCK)+= clock-s3c2410.o
obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
obj-$(CONFIG_S3C2410_IOTIMING) += iotiming-s3c2410.o
diff --git a/arch/arm/mach-s3c24xx/clock-dclk.c
b/arch/arm/mach-s3c24xx/clock-dclk.c
deleted file mode 100644
index 1edd9b2..000
--- a/arch/arm/mach-s3c24xx/clock-dclk.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * Copyright (c) 2004-2008 Simtec Electronics
- * Ben Dooks b...@simtec.co.uk
- * http://armlinux.simtec.co.uk/
- *
- * 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.
- *
- * S3C24XX - definitions for DCLK and CLKOUT registers
- */
-
-#include linux/kernel.h
-#include linux/errno.h
-#include linux/clk.h
-#include linux/io.h
-
-#include mach/regs-clock.h
-#include mach/regs-gpio.h
-
-#include plat/clock.h
-#include plat/cpu.h
-
-/* clocks that could be registered by external code */
-
-static int s3c24xx_dclk_enable(struct clk *clk, int enable)
-{
- unsigned long dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
- if (enable)
- dclkcon |= clk-ctrlbit;
- else
- dclkcon = ~clk-ctrlbit;
-
- __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
- return 0;
-}
-
-static int s3c24xx_dclk_setparent(struct clk *clk, struct clk *parent)
-{
- unsigned long dclkcon;
- unsigned int uclk;
-
- if (parent == clk_upll)
- uclk = 1;
- else if (parent == clk_p)
- uclk = 0;
- else
- return -EINVAL;
-
- clk-parent = parent;
-
- dclkcon = __raw_readl(S3C24XX_DCLKCON);
-
- if (clk-ctrlbit == S3C2410_DCLKCON_DCLK0EN) {
- if (uclk)
- dclkcon |= S3C2410_DCLKCON_DCLK0_UCLK;
- else
- dclkcon = ~S3C2410_DCLKCON_DCLK0_UCLK;
- } else {
- if (uclk)
- dclkcon |= S3C2410_DCLKCON_DCLK1_UCLK;
- else
- dclkcon = ~S3C2410_DCLKCON_DCLK1_UCLK;
- }
-
- __raw_writel(dclkcon, S3C24XX_DCLKCON);
-
- return 0;
-}
-static unsigned long s3c24xx_calc_div(struct clk *clk, unsigned long rate)
-{
- unsigned long div;
-
- if ((rate == 0) || !clk-parent)
- return 0;
-
- div = clk_get_rate(clk-parent) / rate;
- if (div 2)
- div = 2;
- else if (div 16)
- div = 16;
-
- return div;
-}
-
-static unsigned long
Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
Hello.
On 04/23/2014 11:34 PM, Heiko Stübner wrote:
The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.
Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.
To not needing to create additional infrastructure for this, the mpll clock
is requested at the first call to s3c2410_set_fvco().
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
[...]
@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config
*cfg)
*/
void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
{
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+ static struct clk *mpll;
+
+ if (!mpll)
You are testing uninitialized variable. This check wouldn't make much
sense even if the variable was initialized.
+ mpll = clk_get(NULL, mpll)
+ if (IS_ERR(mpll))
+ return;
+
+ clk_set_rate(mpll, cfg-pll.frequency);
+#endif
}
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
Hi,
On 23.04.2014 22:42, Sergei Shtylyov wrote:
Hello.
On 04/23/2014 11:34 PM, Heiko Stübner wrote:
The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.
Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.
To not needing to create additional infrastructure for this, the mpll
clock
is requested at the first call to s3c2410_set_fvco().
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
[...]
@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct
s3c_cpufreq_config *cfg)
*/
void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
{
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+static struct clk *mpll;
+
+if (!mpll)
You are testing uninitialized variable. This check wouldn't make
much sense even if the variable was initialized.
I should probably add that NULL is considered a valid clock handle by
Common Clock Framework.
If there is really no way to pass the clock to this function then
probably a global variable initialized by some code running earlier than
this function could be called would be a better choice.
Anyway, Heiko, thanks for working on this. I'll try to review rest of
the series soon. (I'm attending the ELC next week, though, so I'm not
sure if I find some time then, though.)
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
On 04/24/2014 12:42 AM, Sergei Shtylyov wrote:
The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.
Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.
To not needing to create additional infrastructure for this, the mpll clock
is requested at the first call to s3c2410_set_fvco().
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
[...]
@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config
*cfg)
*/
void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
{
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+static struct clk *mpll;
+
+if (!mpll)
You are testing uninitialized variable. This check wouldn't make much
sense even if the variable was initialized.
Oops, I didn't notice *static*... :- The code makes more sense now.
+mpll = clk_get(NULL, mpll)
+if (IS_ERR(mpll))
+return;
+
+clk_set_rate(mpll, cfg-pll.frequency);
+#endif
}
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
Am Mittwoch, 23. April 2014, 22:55:51 schrieb Tomasz Figa:
Hi,
On 23.04.2014 22:42, Sergei Shtylyov wrote:
Hello.
On 04/23/2014 11:34 PM, Heiko Stübner wrote:
The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.
Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.
To not needing to create additional infrastructure for this, the mpll
clock
is requested at the first call to s3c2410_set_fvco().
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/cpufreq-utils.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..d5e797b 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
[...]
@@ -60,5 +61,18 @@ void s3c2410_cpufreq_setrefresh(struct
s3c_cpufreq_config *cfg)
*/
void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
{
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+static struct clk *mpll;
+
+if (!mpll)
You are testing uninitialized variable. This check wouldn't make
much sense even if the variable was initialized.
I should probably add that NULL is considered a valid clock handle by
Common Clock Framework.
If there is really no way to pass the clock to this function then
probably a global variable initialized by some code running earlier than
this function could be called would be a better choice.
*grrr* :-) ... ok I'll try to find another way (again) to do this
Anyway, Heiko, thanks for working on this. I'll try to review rest of
the series soon. (I'm attending the ELC next week, though, so I'm not
sure if I find some time then, though.)
Just as a reminder, there isn't this much to still review, as you
Acked/Reviewed most of the series in v1 and only this patch as well as 2 and 5
still need a review/ack - and the only changes are fixes for your comments ;-)
Heiko
--
To unsubscribe from this list: send the line unsubscribe linux-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 1/9] ARM: S3C24XX: cpufreq-utils: don't write raw values to MPLLCON when using ccf
The s3c24xx cpufreq driver needs to change the mpll speed and was doing
this by writing raw values from a translation table into the MPLLCON
register.
Change this to use a regular clk_set_rate call when using the common
clock framework and only write the raw value in the samsung_clock case.
The s3c cpufreq driver does already aquire the mpll, so simply add a reference
to struct s3c_cpufreq_config to let set_fvco access it.
While struct clk is opaque the differenciation between samsung clock and
common clock is kept, as the samsung-clock mpll clk does not implement a
real set_rate.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/cpufreq-utils.c | 8
arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 1 +
drivers/cpufreq/s3c24xx-cpufreq.c | 1 +
3 files changed, 10 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/cpufreq-utils.c
b/arch/arm/mach-s3c24xx/cpufreq-utils.c
index 2a0aa56..c1b7508 100644
--- a/arch/arm/mach-s3c24xx/cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -14,6 +14,7 @@
#include linux/errno.h
#include linux/cpufreq.h
#include linux/io.h
+#include linux/clk.h
#include mach/map.h
#include mach/regs-clock.h
@@ -60,5 +61,12 @@ void s3c2410_cpufreq_setrefresh(struct s3c_cpufreq_config
*cfg)
*/
void s3c2410_set_fvco(struct s3c_cpufreq_config *cfg)
{
+#ifdef CONFIG_SAMSUNG_CLOCK
__raw_writel(cfg-pll.driver_data, S3C2410_MPLLCON);
+#endif
+
+#ifdef CONFIG_COMMON_CLK
+ if (!IS_ERR(cfg-mpll))
+ clk_set_rate(cfg-mpll, cfg-pll.frequency);
+#endif
}
diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
index 7231c8e..72d4178 100644
--- a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
+++ b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
@@ -119,6 +119,7 @@ struct s3c_plltab {
struct s3c_cpufreq_config {
struct s3c_freq freq;
struct s3c_freq max;
+ struct clk *mpll;
struct cpufreq_frequency_table pll;
struct s3c_clkdivs divs;
struct s3c_cpufreq_info *info; /* for core, not drivers */
diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c
b/drivers/cpufreq/s3c24xx-cpufreq.c
index be1b2b5..227ebf7 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -141,6 +141,7 @@ static int s3c_cpufreq_calcdivs(struct s3c_cpufreq_config
*cfg)
static void s3c_cpufreq_setfvco(struct s3c_cpufreq_config *cfg)
{
+ cfg-mpll = _clk_mpll;
(cfg-info-set_fvco)(cfg);
}
--
1.9.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: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Best regards,
Jingoo Han
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Vivek Gautam
Sent: Monday, April 21, 2014 9:17 PM
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
Thanks
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Hi Andrzej,
Thank you for the comments.
On 04/23/2014 04:37 PM, Andrzej Hajda wrote:
On 04/23/2014 05:45 AM, YoungJun Cho wrote:
Hi again Andrzej,
On 04/23/2014 10:01 AM, YoungJun Cho wrote:
Hi Andrzej
Thank you for comments.
On 04/22/2014 09:15 PM, Andrzej Hajda wrote:
Hi YoungJun,
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
*dev_id)
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
-exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi-irq);
exynos_dsi_wait_for_reset(dsi);
+exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);
return 0;
I have commented it in the previous version of the patchset. I repeat it
again.
This is a regression, on exynos4210-trats I have 'timeout waiting for
reset' message after dpms off, on.
I'm really sorry for that. I misunderstood last time.
I think the original codes were correct, because the reset timeout would
be occurred without clock activation.
This is not true.
I'll check and fix again.
(By the way, why am I ok?)
I have not verified with exynos4210-trats board yet(I have to get it),
but reset timeout is occured in exynos_dsi_wait_for_reset()
with dsi-completed and that is completed by exynos_dsi_irq().
And the regulators and clocks are enabled by exynos_dsi_poweron(),
NOT by exynos_dsi_enable_clock().
So I think the reset timeout is not related with this patch.
As far as I remember there were at least two issues with init sequence:
- spurious irq storm after power on and before reset,
- irq reset timeouts after reset and without enabled clock.
The current sequence is a result of tests on live hw (documentation were
not helpful in this case). I think it could be improved little bit more
by moving exynos_dsi_enable_clock just after enable_irq this will
eliminate possible timeout when RST_RELEASE irq is signaled but irq is
still disabled. The sequence should look like below:
exynos_dsi_reset(dsi);
enable_irq(dsi-irq);
exynos_dsi_enable_clock(dsi);
exynos_dsi_wait_for_reset(dsi);
exynos_dsi_init_link(dsi);
And PHY related configuration could be put somewhere after
exynos_dsi_wait_for_reset.
I have tested this sequence on trats, it seems to be OK.
It also works well in Exynos5420 target.
I think it would be better to remove this patch and implement new PHY
control functions with this modification.
Thank you.
Best regards YJ
Regards
Andrzej
Anyway I need more investigation.
Thank you.
Best regards YJ
I will comment your previous answer here to make the discussion easier:
As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
So this patch is required for Exynos5 SoCs.
In the moment this patch is applied exynos_dsi_set_pll do not touch phy
registers you have mentioned.
Your change would be more clear if it will be merged together with the
patch adding PHYCTRL settings.
Anyway, solution is simple - please set PHY registers after reset and
configure clocks before reset to avoid
reset timeouts, is there any reason to not do it this way?
The only reason is that the PHY control is related with PLL control and
that was in exynos_dsi_enable_clock() call path.
So I just wanted to keep current sequence.
If there is no way to use previous one, I'll consider your approach.
Thank you.
Best regards YJ
Regards
Andrzej
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420
Hi Andrzej,
Thank you for comments.
On 04/23/2014 05:29 PM, Andrzej Hajda wrote:
On 04/21/2014 02:28 PM, YoungJun Cho wrote:
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 101 ---
1 file changed, 80 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x)(((x) 0xf) 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZEDBIT(1)
#define DSIM_STATE_CMD_LPMBIT(2)
+struct exynos_dsi_driver_data {
+ unsigned int plltmr_reg;
+
+ unsigned int has_freqband:1;
+};
+
struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {
spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+ struct exynos_dsi_driver_data *driver_data;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+ .plltmr_reg = 0x50,
+ .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+ .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+ { .compatible = samsung,exynos4210-mipi-dsi,
+ .data = exynos4_dsi_driver_data },
+ { .compatible = samsung,exynos5420-mipi-dsi,
+ .data = exynos5_dsi_driver_data },
+ { }
+};
I wonder if it wouldn't be better to use samsung,exynos5410-mipi-dsi
compatible and distinguish 5410 and 5420 by DSIM_VERSION register.
That's because I have only Exynos5420 SoC based target,
so made DT for that and tested it only.
But it seems to be no problem to use exynos5410 compatible at least
for the dsi device :).
I'll try.
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+ struct platform_device *pdev)
+{
+ const struct of_device_id *of_id =
+ of_match_device(exynos_dsi_of_match, pdev-dev);
+
+ return (struct exynos_dsi_driver_data *)of_id-data;
+}
+
static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
{
if (wait_for_completion_timeout(dsi-completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct
exynos_dsi *dsi,
static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
{
- static const unsigned long freq_bands[] = {
- 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
- 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
- 510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
- 770 * MHZ, 870 * MHZ, 950 * MHZ,
- };
+ struct exynos_dsi_driver_data *driver_data = dsi-driver_data;
unsigned long fin, fout;
- int timeout, band;
+ int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
*dsi,
failed to find PLL PMS for requested frequency\n);
return -EFAULT;
}
+ dev_dbg(dsi-dev, PLL freq %lu, (p %d, m %d, s %d)\n, fout, p, m, s);
- for (band = 0; band ARRAY_SIZE(freq_bands); ++band)
- if (fout freq_bands[band])
- break;
+ writel(500, dsi-reg_base + driver_data-plltmr_reg);
+
+ reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+ if
