[GIT PULL] Samsung fixes-1 for 3.16
The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-fixes-1 for you to fetch changes up to 7cbcb9d46f9194eb1f88c253a08c0292b2883acc: ARM: EXYNOS: Don't rely on firmware's secondary_cpu_start for mcpm (2014-06-21 19:30:53 +0900) Samsung fixes for 3.16 - use WFI macro in platform_do_lowpower because exynos cpuhotplug includes a hardcoded WFI instruction and it causes compile error in Thumb-2 mode. - fix GIC reg sizes for exynos4 SoCs - remove reset timer counter value during boot and resume for mct to fix a big jump in printk timestamps - fix pm code to check cortex-A9 for another exynos SoCs - don't rely on firmware's secondary_cpu_start for mcpm Abhilash Kesavan (1): ARM: EXYNOS: fix pm code to check for cortex A9 rather than the SoC Chirantan Ekbote (1): clocksource: exynos_mct: Don't reset the counter during boot and resume Doug Anderson (1): ARM: EXYNOS: Don't rely on firmware's secondary_cpu_start for mcpm Leela Krishna Amudala (1): ARM: EXYNOS: Use wfi macro in platform_do_lowpower Tomasz Figa (1): ARM: dts: fix reg sizes of GIC for exynos4 arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/mach-exynos/hotplug.c | 8 +--- arch/arm/mach-exynos/mcpm-exynos.c | 11 ++- arch/arm/mach-exynos/pm.c | 15 +-- drivers/clocksource/exynos_mct.c | 9 +++-- 5 files changed, 20 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v5] spi: s3c64xx: fix broken "cs_gpios" usage in the driver
On Sat, Jun 21, 2014 at 10:53:14PM +0530, Naveen Krishna Ch wrote: > The revisions were pretty quick Yes, this is part of what I'm concerned about - it often means that there are problems, either the review wasn't very detailed or the code is being written too hastily. In this case this is coupled with the fact that it's an area of the code that has had problems in general is setting off alarm bells. > v4 to v5 : Added Acked-by and Revewied-by from Javier and Rob Herring Don't resend for tags - you should include tags if you do resend but they're not a good reason to do so. > Kindly review and let us know your comments. I will review it when I get to it, this isn't the only thing I've got sitting for review. signature.asc Description: Digital signature
Re: [RESEND PATCH v2 1/2] ASoC: samsung: s3c24{xx,12}-i2s: port to use generic dmaengine API
On Sun, Jun 01, 2014 at 08:15:57PM +0300, Vasily Khoruzhick wrote: > Use dmaengine instead of legacy s3c24xx DMA API for s3c24xx and s3c2412 These fail to apply against current code, can you please check and resend? signature.asc Description: Digital signature
Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On Mon, Jun 16, 2014 at 4:56 PM, Tushar Behera wrote: > On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote: >> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera wrote: >>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux. >>> As per the user manual, it should be CLK_MAU_EPLL. >>> >>> The problem surfaced when the bootloader in Peach-pit board set >>> the EPLL clock as the parent of AUDSS mux. While booting the kernel, >>> we used to get a system hang during late boot if CLK_MAU_EPLL was >>> disabled. >>> >>> Signed-off-by: Tushar Behera >>> Signed-off-by: Shaik Ameer Basha >>> Reported-by: Kevin Hilman >>> --- >>> arch/arm/boot/dts/exynos5420.dtsi |2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi >>> b/arch/arm/boot/dts/exynos5420.dtsi >>> index e385322..79e9119 100644 >>> --- a/arch/arm/boot/dts/exynos5420.dtsi >>> +++ b/arch/arm/boot/dts/exynos5420.dtsi >>> @@ -167,7 +167,7 @@ >>> compatible = "samsung,exynos5420-audss-clock"; >>> reg = <0x0381 0x0C>; >>> #clock-cells = <1>; >>> - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>, >>> + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>, >>> <&clock CLK_SCLK_MAUDIO0>, <&clock >>> CLK_SCLK_MAUPCM0>; >>> clock-names = "pll_ref", "pll_in", "sclk_audio", >>> "sclk_pcm_in"; >>> }; >>> -- >>> 1.7.9.5 >>> >>> -- >> >> Tested-by: Javier Martinez Canillas >> > > Kukjin, > > Would you please take this patch as a fix for 3.16? > > -- > Tushar Behera Kukjin, Please pick this patch for 3.16. This is an essential fix required for Peach-pit/Peach-pi board. -- Tushar Behera -- To unsubscribe from 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
Boot regression on Arndale Octa
Hello, Both on kgene's for-next 053341b6993a3e838cfa35c9f594fb94ee3da9ce and on Linus' 401c58fcbbf570e7e4a8ee0e21ffd829deb4de0b my Arndale Octa board fails to boot with an "Unhandled fault: synchronous external abort (0x210)". This is a regression from v3.15, 100% reproducible. [6.251931] s3c-rtc 101e.rtc: setting system cloco to 2000-01-01 21:56:23 UTC (946763783) [6.253401] Unable to find PPMU node [6.253461] exynos5-bus-int: probe of exynos5-bus-int failed with error -2 [6.268412] clk: Not disabling unused clocks [6.310161] Unhandled fault: synchronous external abort (0x210) X���17403d 6.316467] Internal error: : 210 [#1] PREEMPT SMP ARM [6.321576] Modules linked in: [6.324613] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc1-00330-g401c58f #2 [6.332151] task: ecc12000 ti: ecc84000 task.ti: ecc84000 [6.337529] PC is at n_tty_open+0x68/0x118 [6.341598] LR is at n_tty_open+0x64/0x118 [6.3�M��pc : [c023007c>]lr : []psr: a113 [6.345670] sp : ecc85d10 ip : 0003 fp : [6.357106] r10: 0002 r9 : c0MV"� r8 : 051 [6.362305] r7 : 224c r6 : eb1fd800 r5 : r4 : f0174000 [6.368804] r3 : f0176294 r2 : c061305c r1 : c04dd17c r0 : f0176280 [6.375304] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [6.382582] Control: 30c5387d Table: 20003000 DAC: fff�C�+�r�Process swpper/0 (pid: 1, stack limit = 0xecc84240) [6.394280] Stack: (0xecc85d10 to 0xecc86000) [6.398615] 5d00: c0230014 eb1fd800 eb1fd9bc eb2f1e80 [6.406761] 5d20: c040ca0��33ef8 000 eb2f1e80 eb1fd800 c0234550 ece91800 eb1fd800 [6.414906] 5d40: 0003 c0��,V*��5e70 c006ba0 eb33e100 0001 ece91800 c022db48 [6.423051] 5d60: eb40482p c05c1428 c06134c0 c05d66b0 0001 0003 0001 c0613020 [6.431196] 5d80: eb404820 eb33e100 c040ca04 ecc85e70 c00d8880 [6.439343] 5da0: eb33e108 0003 eb33e100 eb404820 eb33e108 c00d87e4 c00d2e2c [6.447488] 5dc0: ecc85e6c ecc85f34 0002 c00d3108 [6.455633] 5de0: ecc85eb0 c00g056c ecc84000 c00de4a0 c0599ed0 ecc01d80 0001 ecc84030 [6.463779] 5e00: eb33e100 0026 eb402558 0f4756ea 0007 [6.471925] 5e20: eb311015 eb404820 eb33e100 eb33e100 ecc85eb0 ec,�2�4 ec85e70 ff9c [6.480070] 5e40: ecc84000 c00e0e70 ecc85e6c c05c5e70 ecc85e88 ecc85f2e [6.488215] 5e60: c05c5e94 8113 ecc1d3d0 eb402688 [6.496361] 5e80: ecc85f34 0001 eb311000 ff9c c0553514 0085 c057b630 [6.504506] 5ea0: c057b628 c00e22c4 0041 ecc1d3d0 eb402688 0f4756ea 0007 [6.511578] usb 1-1.4: new high-spe�d USB device number 3 using exynos-ehci [6.519584] 5ec0: eb311015 c05ab500 eb402000 eb404820 0101 0004 0018 [6.527729] 5ee0: ecc86008 c03e8db8 0002 c00edfe4 c05fd1d0 0002 [6.535875] 5f00: 0001 0002 eb311000 ff9c c05d6740 0002 eb311000 ff9c [6.544020] 5f20: c00d4088 0085 0p006fbc 0002 00�j [ 6.552166] 5f40: 0100 0001 c05d6740 c0595360 0007 c05���5d6740 0553514 [6.560312] 5f60: 0085 c0553d20 0007 0007 c0553514 c03e8�3c ebb7a700 c004fb00 [6.568456] 5f80: 2b5e3000 c05d6740 g03dff8c 00j [6.57602] 5fa0: c03dff9c c001c9b8 0�j [6.54747] 5fc0: 00j [6.92893] 5fe0: 0p00 0013 ecc85ff4 [6.601049] [] (n_tty_open) from [] (tty_ldisc_open.isra.4+0x3c/0x7c) [6.609189] [] (tty_ldisc_open.isra.4) from [] (tty_ldisc_setup+0x18/0x58) [6.617768] [] (tty_ldisc_setup) from [] (tty_init_dev+0xa0/0x198) [6.625654] [] (tty_init_dev) from [] (tty_open+0x2c8/0x5bc) [6.633019] [] (tty_open) from [] (chrdev_open+0x9c/0x178) [6.640212] [] (chrdev_open) from [] (do_dentry_open.isra.15+0xdc/0x2e8) [6.648617] [] (do_dentry_open.isra.15) from [] (finish_open+0x20/0x38) [6.656939] [] (finish_open) from [] (do_last.isra.55+0x3e8/0xc38) [6.664821] [] (do_las|.isra.55) from [] (path_openat+0xb4/0x5e0) [6.672620] [] (path_openat) from [] (do_filp_open+0x2c/0x80) [6.680072] [] (do_filp_open) from [] (do_sys_open+0x10�/0x1d0) [6.687696] [] (do_sys_open) from [] (kernel_init_freeable+0x160/0x1d8) [6.696017] [] (kernel_init_freeable) from [] (kernel_ini[6.704165] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) [6.711698] Code: e34c104d e34c2061 ebf8d227 e5864224 (e5d4303d) [6.717766] ---[ end trace 67957db0672cb23f ]--- [6.722430] Kernel panic - not sync
Re: Boot regression on Arndale Octa
Hi Andreas, On 22.06.2014 18:13, Andreas Färber wrote: > Hello, > > Both on kgene's for-next 053341b6993a3e838cfa35c9f594fb94ee3da9ce and on > Linus' 401c58fcbbf570e7e4a8ee0e21ffd829deb4de0b my Arndale Octa board > fails to boot with an "Unhandled fault: synchronous external abort > (0x210)". This is a regression from v3.15, 100% reproducible. > A couple of ideas to get more information: - What config do you use? - Does it boot with exynos devfreq disabled in kernel config? - Why the "> [6.268412] clk: Not disabling unused clocks" line is there? What's your kernel command line? - The log seems to start quite late. Could you provide full boot log as well? - Could you try bisecting the changes between 3.15 and Kukjin's for-next? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung fixes-1 for 3.16
On Sunday 22 June 2014 17:22:16 Kukjin Kim wrote: > The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: > >Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) > > are available in the git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-fixes-1 > > for you to fetch changes up to 7cbcb9d46f9194eb1f88c253a08c0292b2883acc: > >ARM: EXYNOS: Don't rely on firmware's secondary_cpu_start for mcpm > (2014-06-21 19:30:53 +0900) > > > Samsung fixes for 3.16 > > - use WFI macro in platform_do_lowpower because exynos cpuhotplug >includes a hardcoded WFI instruction and it causes compile error >in Thumb-2 mode. > - fix GIC reg sizes for exynos4 SoCs > - remove reset timer counter value during boot and resume for mct >to fix a big jump in printk timestamps > - fix pm code to check cortex-A9 for another exynos SoCs > - don't rely on firmware's secondary_cpu_start for mcpm > Pulled into fixes branch, thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: exynos5410: Fill in CPU clock-frequency
It's 1.6 GHz for the Cortex-A15.
Avoids warnings like "/cpus/cpu@0 missing clock-frequency property".
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/exynos5410.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 3839c26..9d0b8cc 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -28,24 +28,28 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
+ clock-frequency = <16>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clock-frequency = <16>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clock-frequency = <16>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clock-frequency = <16>;
};
};
--
1.9.3
--
To unsubscribe from 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: Boot regression on Arndale Octa
Am 22.06.2014 20:59, schrieb Andreas Färber: > Hi Tomasz, > > Am 22.06.2014 19:55, schrieb Tomasz Figa: >> On 22.06.2014 18:13, Andreas Färber wrote: >>> Both on kgene's for-next 053341b6993a3e838cfa35c9f594fb94ee3da9ce and on >>> Linus' 401c58fcbbf570e7e4a8ee0e21ffd829deb4de0b my Arndale Octa board >>> fails to boot with an "Unhandled fault: synchronous external abort >>> (0x210)". This is a regression from v3.15, 100% reproducible. >>> >> >> A couple of ideas to get more information: >> >> - What config do you use? > > Attached. It's basically a 3.15'ish exynos_defconfig, updated using > `make oldconfig` plus some manually enabled systemd (CONFIG_FHANDLE=y, > CONFIG_FANOTIFY=y, CONFIG_AUTOFS4=m) and Exynos options. > > Compiler is gcc 4.8.2. > >> - Does it boot with exynos devfreq disabled in kernel config? > > I do see CONFIG_ARM_EXYNOS5_BUS_DEVFREQ=y; not sure if I've already > tested without, will try. No improvement without DEVFREQ. Log attached. > I already verified that 5250 based Spring > boots with a similar config (patchset upcoming). Next I'm trying 5410 > based ODROID-XU for comparison. ODROID-XU works, too (without DEVFREQ). >> - Why the "> [6.268412] clk: Not disabling unused clocks" line is >> there? What's your kernel command line? > > console=ttySAC3,115200n8 root=/dev/mmcblk1p2 rootfstype=ext4 rw rootwait > clk_ignore_unused > > I had tried the latter because the issue occurred directly after a list > of clocks were disabled, but it did not help unfortunately. I notice that this time the trouble starts before the clocks already. Could this be related to the MMC issues reported for other chips? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg U-Boot 2012.07-g8c348a3-divty (Apr r4 2014 - 03:02:27) for ARNDALE OCTA CPU: Exynos5420 Rev2.0 [Samsung SOC on SMP Platform Base on ARM CortexA15] APLL = 800MHz, KPLL = 600MHz MPLL = 532MHz, BPLL = 800MHz Board: ARNDAL� OCTA DRAM: 2 GiB WARNING: Caches not enabled TrustZone Enabled BSP BL1 version: Checking Boot Mode ... SDMMC MMC: S5P_MSHC2: 0, S5P_MSHC0: 1 MMC Device 0: 29.9 GiB MMC Device 1: 3.6 GiB MMC Device 2: MMC Device 2 not found there are pending interrupts 0x0001 In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Loading file "boot.scr" from mmc device 0:1 (xxa1) 928 bytes read ## Executing script at r0008000 Loading file "zImage" from mmc device 0:1 (xxa1) 3073776 bytes read Loading file "�tb/exynos5420-arndale-octa.dtb" fr� j���device 01 (xxa1) 32888 bytes read ## Flattened Device Tree blob at 2100 Booting using the fdt blob at 0x2100 Loading Device Tree to 2fff4000, end 2077 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.16.0-rc1-4-ge8d1bfc (X�É�Íɽ��� (gc version 4.8.2 20140404 [gcc-4_8-brcnch revision 209122] (SUSE Linux) ) #1 SMP PREEMPT Sun Jun 22 22:13:41 CEST 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv79, cr=30c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Insignal Arnda|e Octa evaluation board based on EXYNOS5420 [0.00] Forcing write-allocate cache policy for SMP [0.00] Memory policy: Data cache writealloc [0.00] Runnin���Ésecure fimware. [0.00] PERCPU: Embedded 7 pages/cpu @ebb79000 s7808 r8192 d12672 u72768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1696w83 [0.00] Kernel command line: console=ttySAC3,115200n8 root=/dev/mmcblk1p2 rootfstype=ext4 rw rootwait clk_ignore_unused [ ��r������PID hashtable entries: 4096 (order: 2, 16384��ÑÍ¥ [ 0.00] Dentry cache�+͡�tale entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-c�che hash table entries: 65536 (order: 6, 262144 bytes) [ �r�������Memory: 672524K/6793212K available (4109K kernel code, 249K rwdata, 1292K rodata, 275K init, 283K bss, 60688K reserved, 6023164K highmem) [0.00] Virtual kernel memory layout: [0.00] vecto� : 0x - 0x1000 ( 4 kB) [0.00] �6�ᵠ� : 0xffc - 0xffe0 (2048 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfm0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [� ������ �r���Ñ:0xc0008000 0xc054e7<8 (5402 kF) [0.00] .init : 0xc054f000 - 0xc0593e80 ( 276 kB) [0.p0] .data : 0xc0594000 - 0xc05d2580 ���Z � [ 0.00].bss : 0xc05d258c - 0xc06192c0 ( 284 kB) [0.00] SLU
Re: Enabling 8 cores on 5420
Am 30.05.2014 11:25, schrieb Daniel Lezcano: > > Hi all, > > I am trying an upstream kernel + some patches to enable ethernet on > arndale octa. > > Unfortunately, only 4 cores boot up. The other ones fail to boot. > > [12.179453] CPU6: failed to come online > [13.189479] CPU7: failed to come online > [14.199479] CPU4: failed to come online > [15.209743] CPU5: failed to come online > > What should I do to enable those 8 cores ? Is there a patchset somewhere > to do so ? Ping? Confirmed still present on Arndale Octa with kgene's for-next + patch to get 2-4 up. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from 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: Enabling 8 cores on 5420
Hi PTAL https://patchwork.kernel.org/patch/4315711/ I hope your tree already includes http://www.gossamer-threads.com/lists/linux/kernel/1940123 Regards, Alim On Mon, Jun 23, 2014 at 2:32 AM, Andreas Färber wrote: > Am 30.05.2014 11:25, schrieb Daniel Lezcano: >> >> Hi all, >> >> I am trying an upstream kernel + some patches to enable ethernet on >> arndale octa. >> >> Unfortunately, only 4 cores boot up. The other ones fail to boot. >> >> [12.179453] CPU6: failed to come online >> [13.189479] CPU7: failed to come online >> [14.199479] CPU4: failed to come online >> [15.209743] CPU5: failed to come online >> >> What should I do to enable those 8 cores ? Is there a patchset somewhere >> to do so ? > > Ping? Confirmed still present on Arndale Octa with kgene's for-next + > patch to get 2-4 up. > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg > -- > To unsubscribe from 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 -- Regards, Alim -- To unsubscribe from 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] ARM: dts: exynos4: fix pwm-cells in pwm node
Sachin Kamat wrote: > > Hi Jaewon, > > On Thu, Jun 19, 2014 at 7:33 AM, Jaewon Kim wrote: > > pwm-cells should be 3. Third cell is optional PWM flags. And This flag > > supported by this binding is PWM_POLARITY_INVERTED. > > > > Signed-off-by: Jaewon Kim > > --- > > > > Changes in v2: > > - Remove unnecessary handle. > > > > arch/arm/boot/dts/exynos4.dtsi |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi > > index b8ece4b..e118356 100644 > > --- a/arch/arm/boot/dts/exynos4.dtsi > > +++ b/arch/arm/boot/dts/exynos4.dtsi > > @@ -554,7 +554,7 @@ > > interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 > > 0>; > > clocks = <&clock CLK_PWM>; > > clock-names = "timers"; > > - #pwm-cells = <2>; > > + #pwm-cells = <3>; > > status = "disabled"; > > }; > > I think I had already reviewed this patch. Anyway, > Reviewed-by: Sachin Kamat Applied, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] ARM: dts: exynos: Prepare Spring
From: Andreas Färber Hello, Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15 based attempts by Stephan and me that broke for 3.16, I've prepared a device tree for the HP Chromebook 11 aka Google Spring. The first three patches should be good to go and contain documentation fixes found while comparing exynos5250-snow.dts vs. /proc/device-tree. The main patch was tested using a chained non-verified U-Boot (simplefb) and a rootfs on USB-attached SD card. The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Audio support is likely missing as my focus was getting USB booting. Not included is touchpad support, as "atmel,atmel_mxt_tp" is not documented to be available upstream. And no /dev/mmcblk0 or Wifi yet. Also when the screen stayed on, the embedded controller's keymap seems hardcoded to US English with system settings not taking effect; but surely we don't want per-keyboard device tree files to remedy that. I'd appreciate if we can get a core .dts sorted out and consider incremental changes from there. Regards, Andreas Andreas Färber (4): Documentation: devicetree: Fix s2mps11 and s5m8767 typos Documentation: devicetree: Fix s2mps11 example syntax Documentation: devicetree: Fix tps65090 typos ARM: dts: exynos5250: Add Spring device tree Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 +- .../bindings/regulator/s5m8767-regulator.txt | 2 +- .../devicetree/bindings/regulator/tps65090.txt | 4 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/exynos5250-spring.dts| 556 + 5 files changed, 562 insertions(+), 5 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts -- 1.9.3 -- To unsubscribe from 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/4] Documentation: devicetree: Fix s2mps11 and s5m8767 typos
It's LDO2, not LD02. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +- Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index d81ba30..55ab4f4 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -81,7 +81,7 @@ as per the datasheet of s2mps11. - valid values for n are: - S2MPS11: 1 to 38 - S2MPS14: 1 to 25 - - Example: LDO1, LD02, LDO28 + - Example: LDO1, LDO2, LDO28 - BUCKn - valid values for n are: - S2MPS11: 1 to 10 diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index d290988..2019131 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -86,7 +86,7 @@ as per the datasheet of s5m8767. - LDOn - valid values for n are 1 to 28 - - Example: LDO1, LD02, LDO28 + - Example: LDO1, LDO2, LDO28 - BUCKn - valid values for n are 1 to 9. - Example: BUCK1, BUCK2, BUCK9 -- 1.9.3 -- To unsubscribe from 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 3/4] Documentation: devicetree: Fix tps65090 typos
It's vsys-l{1,2}-supply, not vsys_l{1,2}-supply.
Signed-off-by: Andreas Färber
---
Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 34098023..ca69f5e 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = <&some_reg>;
infet6-supply = <&some_reg>;
infet7-supply = <&some_reg>;
- vsys_l1-supply = <&some_reg>;
- vsys_l2-supply = <&some_reg>;
+ vsys-l1-supply = <&some_reg>;
+ vsys-l2-supply = <&some_reg>;
regulators {
dcdc1 {
--
1.9.3
--
To unsubscribe from 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/4] Documentation: devicetree: Fix s2mps11 example syntax
It's <1>, not 1.
Signed-off-by: Andreas Färber
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 55ab4f4..99a0c52 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -96,7 +96,7 @@ Example:
s2m_osc: clocks {
compatible = "samsung,s2mps11-clk";
- #clock-cells = 1;
+ #clock-cells = <1>;
clock-output-names = "xx", "yy", "zz";
};
--
1.9.3
--
To unsubscribe from 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
[RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Adds initial support for the HP Chromebook 11.
Cc: Vincent Palatin
Cc: Doug Anderson
Cc: Stephan van Schaik
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5250-spring.dts | 556
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff6..dc2c5aa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include "exynos5250.dtsi"
+#include "exynos5250-cros-common.dtsi"
+
+/ {
+ model = "Google Spring";
+ compatible = "google,spring", "samsung,exynos5250", "samsung,exynos5";
+
+ pinctrl@1140 {
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = "gpx2-3", "gpx2-4", "gpx2-5";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = "gpx3-2";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = "gpx3-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = "gpe1-0";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
+ vbat: vbat-fixed-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat-supply";
+ regulator-boot-on;
+ };
+
+ usb@1200 {
+ status = "okay";
+ };
+
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = "regulator-fixed";
+ regulator-name = "P5.0V_USB3CON";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpe1 0 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsic_reset>;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = <&usb3_vbus_reg>;
+ };
+
+ usb@1211 {
+ samsung,vbus-gpio = <&gpx1 1 0>;
+ status = "okay";
+ };
+
+ usb@1212 {
+ status = "okay";
+ };
+
+ mmc@1222 {
+ /* MMC2 pins are used as GPIO for eDP bridge control. */
+ status = "disabled";
+ };
+
+ mmc@1223 {
+ status = "disabled";
+ };
+
+ i2c@12C6 {
+ max77686@09 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ rtc {
+ reg = <0x6>;
+ };
+ };
+
+ s5m8767_pmic@66 {
+ compatible = "samsung,s5m8767-pmic";
+ reg = <0x66>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <2 0>;
+ pinctrl-nam
Re: [PATCH v6 1/6] clk: samsung: add infrastructure to register cpu clocks
On Tue, Jun 17, 2014 at 8:55 PM, Thomas Abraham wrote:
> From: Thomas Abraham
>
> The CPU clock provider supplies the clock to the CPU clock domain. The
> composition and organization of the CPU clock provider could vary among
> Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
> and gates. This patch defines a new clock type for CPU clock provider and
> adds infrastructure to register the CPU clock providers for Samsung
> platforms.
Thomas,
The overall code structuring looks very neat. Few minor and some
optimization points are suggested below,
After updating them you can add and sorry for late review.
Reviewed-by: Amit Daniel Kachhap
>
> Cc: Tomasz Figa
> Signed-off-by: Thomas Abraham
> ---
> drivers/clk/samsung/Makefile |2 +-
> drivers/clk/samsung/clk-cpu.c | 577
> +
> drivers/clk/samsung/clk.h |5 +
> 3 files changed, 583 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/samsung/clk-cpu.c
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 69e8177..f4edd31 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -2,7 +2,7 @@
> # Samsung Clock specific Makefile
> #
>
> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
> new file mode 100644
> index 000..c40f7b5
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-cpu.c
> @@ -0,0 +1,577 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Thomas Abraham
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This file contains the utility functions to register the CPU clocks
> + * for Samsung platforms.
> +*/
> +
> +#include
> +#include "clk.h"
> +
> +#define E4210_SRC_CPU 0x0
> +#define E4210_STAT_CPU 0x200
> +#define E4210_DIV_CPU0 0x300
> +#define E4210_DIV_CPU1 0x304
> +#define E4210_DIV_STAT_CPU00x400
> +#define E4210_DIV_STAT_CPU10x404
> +
> +#define MAX_DIV8
> +#define DIV_MASK 7
> +#define DIV_MASK_ALL 0x
> +#define MUX_MASK 7
> +
> +#define E4210_DIV0_RATIO0_MASK 0x7
> +#define E4210_DIV1_HPM_MASK((0x7 << 4) | (0x7 << 0))
> +#define E4210_MUX_HPM_MASK (1 << 20)
> +#define E4210_DIV0_ATB_SHIFT 16
> +#define E4210_DIV0_ATB_MASK(DIV_MASK << E4210_DIV0_ATB_SHIFT)
> +
> +#define E4210_CPU_DIV0(apll, pclk_dbg, atb, periph, corem1, corem0)\
> + (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
> + ((periph) << 12) | ((corem1) << 8) | ((corem0) << 4))
> +#define E4210_CPU_DIV1(hpm, copy) \
> + (((hpm) << 4) | ((copy) << 0))
> +
> +#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
> + (((apll << 24) | (pclk_dbg << 20) | (atb << 16) | \
> +(periph << 12) | (acp << 8) | (cpud << 4)))
> +#define E5250_CPU_DIV1(hpm, copy) \
> + (((hpm) << 4) | (copy))
> +
> +#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud) \
> + (((apll << 24) | (pclk_dbg << 20) | (atb << 16) | \
> +(cpud << 4)))
> +#define E5420_KFC_DIV(kpll, pclk, aclk)
> \
> + (((kpll << 24) | (pclk << 20) | (aclk << 4)))
> +
> +enum cpuclk_type {
> + EXYNOS4210,
> + EXYNOS5250,
> + EXYNOS5420,
> +};
> +
> +/**
> + * struct exynos4210_cpuclk_data: config data to setup cpu clocks.
> + * @prate: frequency of the primary parent clock (in KHz).
> + * @div0: value to be programmed in the div_cpu0 register.
> + * @div1: value to be programmed in the div_cpu1 register.
> + *
> + * This structure holds the divider configuration data for dividers in the
> CPU
> + * clock domain. The parent frequency at which these divider values are
> valid is
> + * specified in @prate. The @prate is the frequency of the primary parent
> clock.
> + * For CPU clock domains that do not have a DIV1 register, the @div1 member
> + * is optional.
> + */
> +struct exynos4210_cpuclk_data {
> + unsigned long prate;
> + unsigned intdiv0;
> + unsigned intdiv1;
> +};
This structure is used for infact all exynos SOCs, if possible see if
this can be renamed to exynos_cpuclk_data.
> +
> +/**
> + * struct exynos_cpuclk: information about clock supplied to a CPU core.
> + * @hw:handle between CCF and CPU clock.
> + * @alt_p
Re: [PATCH v6 3/6] clk: exynos: use cpu-clock provider type to represent arm clock
On Tue, Jun 17, 2014 at 8:55 PM, Thomas Abraham wrote:
> From: Thomas Abraham
>
> With the addition of the new Samsung specific cpu-clock type, the
> arm clock can be represented as a cpu-clock type and the independent
> clock blocks that made up the arm clock can be removed.
>
> Cc: Tomasz Figa
> Signed-off-by: Thomas Abraham
> ---
> drivers/clk/samsung/clk-exynos4.c | 25 +
> drivers/clk/samsung/clk-exynos5250.c | 16 +++-
> drivers/clk/samsung/clk-exynos5420.c | 31 ++-
> include/dt-bindings/clock/exynos5250.h |1 +
> include/dt-bindings/clock/exynos5420.h |2 ++
> 5 files changed, 53 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c
> index 4f150c9..04cbcb6 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -471,7 +471,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
> __initdata = {
> MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
> MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
> MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
> + MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1, 0,
> + CLK_MUX_READ_ONLY),
> MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
> MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
> MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4210, SRC_CAM, 4, 4),
> @@ -530,7 +531,8 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
> __initdata = {
> MUX(0, "mout_jpeg", mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
> MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_DMC, 12, 1),
> MUX(CLK_SCLK_VPLL, "sclk_vpll", mout_vpll_p, SRC_TOP0, 8, 1),
> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1),
> + MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4x12, SRC_CPU, 16, 1, 0,
> + CLK_MUX_READ_ONLY),
> MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4x12, SRC_CAM, 0, 4),
> MUX(CLK_MOUT_FIMC1, "mout_fimc1", group1_p4x12, SRC_CAM, 4, 4),
> MUX(CLK_MOUT_FIMC2, "mout_fimc2", group1_p4x12, SRC_CAM, 8, 4),
> @@ -572,8 +574,10 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
> __initdata = {
>
> /* list of divider clocks supported in all exynos4 soc's */
> static struct samsung_div_clock exynos4_div_clks[] __initdata = {
> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
> - DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
> + DIV_F(0, "div_core", "mout_core", DIV_CPU0, 0, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_core2", "div_core", DIV_CPU0, 28, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
> DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
> DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
> @@ -619,8 +623,10 @@ static struct samsung_div_clock exynos4_div_clks[]
> __initdata = {
> DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
> DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
> DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
> - DIV(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
> - DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
> + DIV_F(CLK_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
> CLK_SET_RATE_PARENT, 0),
> DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
> @@ -1005,7 +1011,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
> __initdata = {
>
> static struct samsung_clock_alias exynos4_aliases[] __initdata = {
> ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
> - ALIAS(CLK_ARM_CLK, NULL, "armclk"),
> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
> };
>
> @@ -1244,6 +1249,8 @@ static void __init exynos4_clk_init(struct device_node
> *np,
> ARRAY_SIZE(exynos4210_gate_clks));
> samsung_clk_register_alias(ctx, exynos4210_aliases,
> ARRAY_SIZE(exynos4210_aliases));
> + exynos_register_cpu_clock(ctx, 0, CLK_ARM_CLK, "armclk",
> + mout_core_p4210[0], mout_core_p4210[1], np);
> } else {
> samsung_clk_register_mux(ctx, exynos4x12_mux_clks,
> ARRAY_SIZE(exynos4x12_mux_clks));
> @@ -1253,6 +1260,8 @@ static v
Re: [PATCH 1/4] Documentation: devicetree: Fix s2mps11 and s5m8767 typos
On Mon, Jun 23, 2014 at 6:51 AM, Andreas Färber wrote: > It's LDO2, not LD02. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +- > Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt > b/Documentation/devicetree/bindings/mfd/s2mps11.txt > index d81ba30..55ab4f4 100644 > --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt > +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt > @@ -81,7 +81,7 @@ as per the datasheet of s2mps11. > - valid values for n are: > - S2MPS11: 1 to 38 > - S2MPS14: 1 to 25 > - - Example: LDO1, LD02, LDO28 > + - Example: LDO1, LDO2, LDO28 > - BUCKn > - valid values for n are: > - S2MPS11: 1 to 10 > diff --git > a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > index d290988..2019131 100644 > --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > @@ -86,7 +86,7 @@ as per the datasheet of s5m8767. > > - LDOn > - valid values for n are 1 to 28 > - - Example: LDO1, LD02, LDO28 > + - Example: LDO1, LDO2, LDO28 > - BUCKn > - valid values for n are 1 to 9. > - Example: BUCK1, BUCK2, BUCK9 > -- Very keen observation :) Reviewed-by: Sachin Kamat -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Documentation: devicetree: Fix s2mps11 example syntax
On Mon, Jun 23, 2014 at 6:51 AM, Andreas Färber wrote:
> It's <1>, not 1.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 55ab4f4..99a0c52 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -96,7 +96,7 @@ Example:
>
> s2m_osc: clocks {
> compatible = "samsung,s2mps11-clk";
> - #clock-cells = 1;
> + #clock-cells = <1>;
> clock-output-names = "xx", "yy", "zz";
> };
>
> --
> 1.9.3
>
Reviewed-by: Sachin Kamat
--
To unsubscribe from 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: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
Adding linux-samsung-soc and linux-arm-kernel ML for wider audience. On 06/19/2014 04:12 PM, Tushar Behera wrote: > On 06/19/2014 03:02 PM, Tushar Behera wrote: >> On 06/18/2014 09:22 AM, Kevin Hilman wrote: >>> On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera wrote: On 06/17/2014 10:23 PM, Kevin Hilman wrote: > Sachin, > > On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot > wrote: >> >> Tree/Branch: mainline >> Git describe: v3.16-rc1-2-gebe0618 >> Failed boot tests (console logs at the end) >> === >> exynos5420-arndale-octa: FAIL:arm-exynos_defconfig >> ste-snowball: FAIL:arm-u8500_defconfig > > FYI... these failures are getting more consistent on my octa board, > but still not failing every time. > > Kevin > Hi Kevin, Same here. Observation: If you soft-reset the board (through the jumpers) after getting this problem, the problem keeps repeating. But if you hard-reset the board (by removing the power cord), the problem doesn't occur during next iteration. >>> >>> I don't ever use the soft-reset, I only toggle the wall power. I >>> don't ever actually remove the power cord though, I'm using a >>> USB-controlled relay to toggle the wall power. >>> >>> Kevin >>> >> >> Laura, >> >> We are getting following kernel panic [1] (not always, but quite >> regularly) while booting Arndale-Octa (based on Samsung's Exynos5420) >> board with upstream kernel. I haven't observed this issue with other >> boards yet. >> >> This issue is observed when I am booting with uImage + dtb (within >> roughly ~10 iterations). >> > > Some more information: > > The boot logs are provided in pastebin, okay[2] and failed[3]. > > In case of boot failures, I am getting a higher value for vm_total_pages > (684424 in [3]). In case of successful boot on my board, it is always > 521232 [2] on my board. > > [2] http://pastebin.com/1iLaizuL > [3] http://pastebin.com/5tdDt4GL > >> There is no issue when I am booting appended zImage (zImage+dtb). I >> tried running it over 200 cycles, but without any failure. >> >> 'git bisect' points to this commit. >> commit 1c2f87c22566 "ARM: 8025/1: Get rid of meminfo" >> >> Reverting this commit on top of v3.16-rc1-17-ge99cfa2, I tested for >> around 100 iterations of booting with uImage+dtb, without any failure. >> >> [1] Kernel log >> Unhandled fault: external abort on non-linefetch (0x008) at 0xffc0 >> Internal error: : 8 [#1] PREEMPT SMP ARM >> Modules linked in: >> CPU: 0 PID: 1136 Comm: kworker/u16:0 Not tainted >> 3.15.0-rc1-00027-g1c8c3cf-dirty #5 >> task: ed0f5800 ti: eda52000 task.ti: eda52000 >> PC is at __copy_to_user_std+0x4c/0x3a8 >> LR is at copy_page_to_iter+0xb0/0x26c >> pc : []lr : []psr: 6113 >> sp : eda53de4 ip : fp : ee103040 >> r10: ed9fb700 r9 : 0080 r8 : eda53eb8 >> r7 : ffc0 r6 : r5 : 0080 r4 : eda53e78 >> r3 : r2 : r1 : ffc0 r0 : ed9fb700 >> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel >> Control: 10c5387d Table: 2000406a DAC: 0015 >> Process kworker/u16:0 (pid: 1136, stack limit = 0xeda52240) >> > > -- Tushar Behera -- To unsubscribe from 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: Boot regression on Arndale Octa
On 06/22/2014 09:43 PM, Andreas Färber wrote: > Hello, > > Both on kgene's for-next 053341b6993a3e838cfa35c9f594fb94ee3da9ce and on > Linus' 401c58fcbbf570e7e4a8ee0e21ffd829deb4de0b my Arndale Octa board > fails to boot with an "Unhandled fault: synchronous external abort > (0x210)". This is a regression from v3.15, 100% reproducible. > > [6.251931] s3c-rtc 101e.rtc: setting system cloco to 2000-01-01 > 21:56:23 UTC (946763783) > [6.253401] Unable to find PPMU node > [6.253461] exynos5-bus-int: probe of exynos5-bus-int failed with > error -2 > [6.268412] clk: Not disabling unused clocks > [6.310161] Unhandled fault: synchronous external abort (0x210) > X���17403d > 6.316467] Internal error: : 210 [#1] PREEMPT SMP ARM > [6.321576] Modules linked in: > [6.324613] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.16.0-rc1-00330-g401c58f #2 > [6.332151] task: ecc12000 ti: ecc84000 task.ti: ecc84000 > [6.337529] PC is at n_tty_open+0x68/0x118 > [6.341598] LR is at n_tty_open+0x64/0x118 > [6.3�M��pc : [c023007c>]lr : []psr: a113 > [6.345670] sp : ecc85d10 ip : 0003 fp : > [6.357106] r10: 0002 r9 : c0MV"� r8 : 051 > [6.362305] r7 : 224c r6 : eb1fd800 r5 : r4 : f0174000 > [6.368804] r3 : f0176294 r2 : c061305c r1 : c04dd17c r0 : f0176280 > [6.375304] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM > Segment kernel > [6.382582] Control: 30c5387d Table: 20003000 DAC: > fff�C�+�r�Process swpper/0 (pid: 1, stack limit = 0xecc84240) > [6.394280] Stack: (0xecc85d10 to 0xecc86000) > [6.398615] 5d00: c0230014 > eb1fd800 eb1fd9bc eb2f1e80 > [6.406761] 5d20: c040ca0��33ef8 000 eb2f1e80 eb1fd800 c0234550 > ece91800 eb1fd800 > [6.414906] 5d40: 0003 c0��,V*��5e70 c006ba0 eb33e100 0001 > ece91800 c022db48 > [6.423051] 5d60: eb40482p c05c1428 c06134c0 c05d66b0 0001 > 0003 0001 c0613020 > [6.431196] 5d80: eb404820 eb33e100 c040ca04 > ecc85e70 c00d8880 > [6.439343] 5da0: eb33e108 0003 eb33e100 eb404820 > eb33e108 c00d87e4 c00d2e2c > [6.447488] 5dc0: ecc85e6c ecc85f34 0002 > c00d3108 > [6.455633] 5de0: ecc85eb0 c00g056c ecc84000 c00de4a0 c0599ed0 > ecc01d80 0001 ecc84030 > [6.463779] 5e00: eb33e100 0026 eb402558 > 0f4756ea 0007 > [6.471925] 5e20: eb311015 eb404820 eb33e100 eb33e100 ecc85eb0 > ec,�2�4 ec85e70 ff9c > [6.480070] 5e40: ecc84000 c00e0e70 ecc85e6c > c05c5e70 ecc85e88 ecc85f2e > [6.488215] 5e60: c05c5e94 8113 ecc1d3d0 > eb402688 > [6.496361] 5e80: ecc85f34 0001 eb311000 ff9c > c0553514 0085 c057b630 > [6.504506] 5ea0: c057b628 c00e22c4 0041 ecc1d3d0 > eb402688 0f4756ea 0007 > [6.511578] usb 1-1.4: new high-spe�d USB device number 3 using > exynos-ehci > [6.519584] 5ec0: eb311015 c05ab500 eb402000 eb404820 > 0101 0004 0018 > [6.527729] 5ee0: ecc86008 c03e8db8 0002 > c00edfe4 c05fd1d0 0002 > [6.535875] 5f00: 0001 0002 eb311000 ff9c c05d6740 > 0002 eb311000 ff9c > [6.544020] 5f20: c00d4088 0085 0p006fbc > 0002 00�j > [ 6.552166] 5f40: 0100 0001 c05d6740 c0595360 > 0007 c05���5d6740 0553514 > [6.560312] 5f60: 0085 c0553d20 0007 0007 c0553514 > c03e8�3c ebb7a700 c004fb00 > [6.568456] 5f80: 2b5e3000 c05d6740 g03dff8c > 00j > [6.57602] 5fa0: c03dff9c c001c9b8 > 0�j > [6.54747] 5fc0: > 00j > [6.92893] 5fe0: 0p00 > 0013 ecc85ff4 > [6.601049] [] (n_tty_open) from [] > (tty_ldisc_open.isra.4+0x3c/0x7c) > [6.609189] [] (tty_ldisc_open.isra.4) from [] > (tty_ldisc_setup+0x18/0x58) > [6.617768] [] (tty_ldisc_setup) from [] > (tty_init_dev+0xa0/0x198) > [6.625654] [] (tty_init_dev) from [] > (tty_open+0x2c8/0x5bc) > [6.633019] [] (tty_open) from [] > (chrdev_open+0x9c/0x178) > [6.640212] [] (chrdev_open) from [] > (do_dentry_open.isra.15+0xdc/0x2e8) > [6.648617] [] (do_dentry_open.isra.15) from [] > (finish_open+0x20/0x38) > [6.656939] [] (finish_open) from [] > (do_last.isra.55+0x3e8/0xc38) > [6.664821] [] (do_las|.isra.55) from [] > (path_openat+0xb4/0x5e0) > [6.672620] [] (path_openat) from [] > (do_filp_open+0x2c/0x80) > [6.680072] [] (do_filp_open) from [] > (do_sys_open+0x10�/0x1d0) > [6.687696] [] (do_sys_open) from [] > (kernel_init_freeable+0x160/0x1d8) > [6.696017] [] (kerne
Re: MMC error on Exynos4210 board
Hi Tim, On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger wrote: > On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat wrote: >> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung >> wrote: >>> On 06/19/2014 07:40 PM, Sachin Kamat wrote: On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: > On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat >>> wrote: > On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat > wrote: >>> >> I see the below error on Exynos4210 based Origen board with >> linux-next >> (20140618). >> Reverting the below commit works fine. >> >> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>> >> >> -- [2.068992] sdhci: Secure Digital Host Controller Interface >> driver >> [2.075059] sdhci: Copyright(c) Pierre Ossman >> [2.079762] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1251[0]' >> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >> (5000 Hz) >> [2.095322] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1251[0]' >> [2.103794] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1251[0]' >> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >> [2.118117] mmc0: Hardware doesn't report any support voltages. >> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >> [2.130080] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1253[0]' >> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >> (1667 Hz) >> [2.145661] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1253[0]' >> [2.154139] of_get_named_gpiod_flags: can't parse gpios property >> of >> node '/sdhci@1253[0]' >> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >> [2.168464] mmc0: Hardware doesn't report any support voltages. >> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>> >> [2.336148] Waiting for root device /dev/mmcblk0p1... >>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. >>> >>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >>> | MMC_VDD_28_29. >>> >>> The SDHCI capabilities register only indicates support of three voltage >>> levels >>> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >>> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >>> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 >>> >>> Right. sdhci capabilities only indicated them. >>> But I think SoC can be support the specific VDD range. >>> >>> >>> Even if all capability bits of the host controller were set, there >>> still wouldn't be any overlap. Thus you see a "Hardware doesn't >>> report any support voltages" message. >>> >>> Previously, this issue was being swept under the rug by cec2e21 mmc: >>> sdhci: Use regulator min/max voltage range according to spec. That >>> change hacked up the voltage range checks such that with your 2.8v >>> fixed regulator, the driver would believe the host could support >>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The >>> driver would start down the path of commanding 3.3v-3.4v (the highest >>> voltage range believed to be supported). At the last second, the >>> driver would see the regulator was fixed and blindly skip over the set >>> voltage operation, saving it from failure. >>> >>> Since my patch eliminates the bogus voltage range checks, your board >>> is now getting caught playing too loose with the SDHCI regulator >>> voltages. >>> >>> Furthermore, the fixed regulator special-case logic that helped hide >>> your issue should also be considered for removal given that fixed >>> regulators now behave properly thanks to c00dc35 regulator: core: >>> Allow regulator_set_voltage for fixed regulators. >> >> Thanks for the detailed explanation. What do you propose to get this >> fixed > > It would be nice if the driver could be extended > to handle the peculiarities of your board in a deliberate manner but > limiting the common sdhci driver to supporting only the three voltages > from the spec also seems sensible. Until such time that the driver gets fixed to handle 2.8V fixed supply
Re: [PATCH v2 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
On Fri, May 30, 2014 at 11:49 PM, Andreas Färber wrote: > Am 28.05.2014 06:13, schrieb Sachin Kamat: >> Almost all Exynos-series of SoCs that run in secure mode don't need >> additional offset for every CPU, with Exynos4412 being the only >> exception. >> >> Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). >> >> While at it, fix the coding style (space around *). >> >> Signed-off-by: Sachin Kamat >> Signed-off-by: Tushar Behera >> --- >> arch/arm/mach-exynos/firmware.c |9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to > applying the 5410 patches... > > Tested-by: Andreas Färber > Kukjin, this patch is required to bring up 4 A15 cores on some 5410 and 5420 based boards. Can you please queue this up for the upcoming rc as fixes? -- To unsubscribe from 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] ARM: dts: Move display-timings node under fimd node
'display-timings' should be a subnode for fimd node. Moving this
node appropriately gets the display back on Origen/Origen-Quad boards.
Signed-off-by: Tushar Behera
---
Based on next-20140620.
Tested on Exynos4210-Origen board. Looks like there are still some pending
bits on Exynos4412-Origen to get display working.
arch/arm/boot/dts/exynos4210-origen.dts | 26 +-
arch/arm/boot/dts/exynos4412-origen.dts | 26 +-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index f767c42..a39323f 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -317,20 +317,20 @@
pinctrl-0 = <&lcd_en &lcd_clk &lcd_data24 &pwm0_out>;
pinctrl-names = "default";
status = "okay";
- };
- display-timings {
- native-mode = <&timing0>;
- timing0: timing {
- clock-frequency = <4750>;
- hactive = <1024>;
- vactive = <600>;
- hfront-porch = <64>;
- hback-porch = <16>;
- hsync-len = <48>;
- vback-porch = <64>;
- vfront-porch = <16>;
- vsync-len = <3>;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing {
+ clock-frequency = <4750>;
+ hactive = <1024>;
+ vactive = <600>;
+ hfront-porch = <64>;
+ hback-porch = <16>;
+ hsync-len = <48>;
+ vback-porch = <64>;
+ vfront-porch = <16>;
+ vsync-len = <3>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..0604220 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -160,20 +160,20 @@
pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
pinctrl-names = "default";
status = "okay";
- };
- display-timings {
- native-mode = <&timing0>;
- timing0: timing {
- clock-frequency = <4750>;
- hactive = <1024>;
- vactive = <600>;
- hfront-porch = <64>;
- hback-porch = <16>;
- hsync-len = <48>;
- vback-porch = <64>;
- vfront-porch = <16>;
- vsync-len = <3>;
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing {
+ clock-frequency = <4750>;
+ hactive = <1024>;
+ vactive = <600>;
+ hfront-porch = <64>;
+ hback-porch = <16>;
+ hsync-len = <48>;
+ vback-porch = <64>;
+ vfront-porch = <16>;
+ vsync-len = <3>;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5 v2] drm/exynos: soft reset mixer before reconfigure after power-on
Mixer soft reset is a recommended step before reconfiguring the mixer after power on. Mixer looses the previous state of DMAs if soft reset. This is the recommendation from the hardware team. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_mixer.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 6773b03..6f18581 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1085,6 +1085,8 @@ static void mixer_poweron(struct exynos_drm_manager *mgr) ctx->powered = true; mutex_unlock(&ctx->mixer_mutex); + mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET); + mixer_reg_write(res, MXR_INT_EN, ctx->int_en); mixer_win_reset(ctx); -- 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 5/5 v2] drm/exynos: enable vsync interrupt while waiting for vblank
mixer_wait_for_vblank function expects that the upcoming
vsync interrupt handler routine will clear the
wait_vsync_event atomic variable.
For this to happen, interrupts should be enabled and
disabled properly.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6f18581..7529946 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1019,6 +1019,8 @@ static void mixer_wait_for_vblank(struct
exynos_drm_manager *mgr)
}
mutex_unlock(&mixer_ctx->mixer_mutex);
+ drm_vblank_get(mgr->crtc->dev, mixer_ctx->pipe);
+
atomic_set(&mixer_ctx->wait_vsync_event, 1);
/*
@@ -1029,6 +1031,8 @@ static void mixer_wait_for_vblank(struct
exynos_drm_manager *mgr)
!atomic_read(&mixer_ctx->wait_vsync_event),
HZ/20))
DRM_DEBUG_KMS("vblank wait timed out.\n");
+
+ drm_vblank_put(mgr->crtc->dev, mixer_ctx->pipe);
}
static void mixer_window_suspend(struct exynos_drm_manager *mgr)
--
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 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, int
win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = &ctx->mixer_res;
- u32 val;
-
- val = mixer_reg_read(res, MXR_CFG);
- /* allow one update per vsync only */
- if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
- mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+ mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
}
static void mixer_graph_buffer(struct mixer_context *ctx, int win)
--
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 1/5 v2] drm/exynos: set power state variable after enabling clocks and power
Power state variable holds the state of the mixer device.
Power on and power off functions are toggling these variable
at wrong place.
State variable should be changed to true only after Runtime
PM and clocks are enabled. Else it may result to a situation
where mixer registers are accessed with device power enabled.
Similar logic for poweroff sequence.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c5aed7..c00abbe 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1061,7 +1061,7 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
mutex_unlock(&ctx->mixer_mutex);
return;
}
- ctx->powered = true;
+
mutex_unlock(&ctx->mixer_mutex);
pm_runtime_get_sync(ctx->dev);
@@ -1072,6 +1072,10 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
clk_prepare_enable(res->sclk_mixer);
}
+ mutex_lock(&ctx->mixer_mutex);
+ ctx->powered = true;
+ mutex_unlock(&ctx->mixer_mutex);
+
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);
@@ -1084,14 +1088,20 @@ static void mixer_poweroff(struct exynos_drm_manager
*mgr)
struct mixer_resources *res = &ctx->mixer_res;
mutex_lock(&ctx->mixer_mutex);
- if (!ctx->powered)
- goto out;
+ if (!ctx->powered) {
+ mutex_unlock(&ctx->mixer_mutex);
+ return;
+ }
mutex_unlock(&ctx->mixer_mutex);
mixer_window_suspend(mgr);
ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
+ mutex_lock(&ctx->mixer_mutex);
+ ctx->powered = false;
+ mutex_unlock(&ctx->mixer_mutex);
+
clk_disable_unprepare(res->mixer);
if (ctx->vp_enabled) {
clk_disable_unprepare(res->vp);
@@ -1099,12 +1109,6 @@ static void mixer_poweroff(struct exynos_drm_manager
*mgr)
}
pm_runtime_put_sync(ctx->dev);
-
- mutex_lock(&ctx->mixer_mutex);
- ctx->powered = false;
-
-out:
- mutex_unlock(&ctx->mixer_mutex);
}
static void mixer_dpms(struct exynos_drm_manager *mgr, int mode)
--
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 0/5 v2] drm/exynos: fix for misc issues related to exynos mixer
Fixes for various issues which are to Power On/Off sequence, Layer update, waiting for vblank in exynos mixer driver. v2: 1) Repalce mixer_enable_vblank with drm_vblank_get. This series is based on exynos-drm-fixes branch in Inki dae's tree. Rahul Sharma (5): drm/exynos: set power state variable after enabling clocks and power drm/exynos: stop mixer before gating clocks during poweroff drm/exynos: allow mulitple layer updates per vsync for mixer drm/exynos: soft reset mixer before reconfigure after power-on drm/exynos: enable vsync interrupt while waiting for vblank drivers/gpu/drm/exynos/exynos_mixer.c | 50 +++-- drivers/gpu/drm/exynos/regs-mixer.h |1 + 2 files changed, 36 insertions(+), 15 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
[PATCH 2/5 v2] drm/exynos: stop mixer before gating clocks during poweroff
Mixer should be power gated only after it is gracefully stopped.
The recommended sequence is to Stop the mixer and wait till
it enters to IDLE state before gating the clocks and power to
the mixer.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 15 +++
drivers/gpu/drm/exynos/regs-mixer.h |1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c00abbe..d359501 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -377,6 +377,20 @@ static void mixer_run(struct mixer_context *ctx)
mixer_regs_dump(ctx);
}
+static void mixer_stop(struct mixer_context *ctx)
+{
+ struct mixer_resources *res = &ctx->mixer_res;
+ int timeout = 20;
+
+ mixer_reg_writemask(res, MXR_STATUS, 0, MXR_STATUS_REG_RUN);
+
+ while (!(mixer_reg_read(res, MXR_STATUS) & MXR_STATUS_REG_IDLE) &&
+ --timeout)
+ usleep_range(1, 12000);
+
+ mixer_regs_dump(ctx);
+}
+
static void vp_video_buffer(struct mixer_context *ctx, int win)
{
struct mixer_resources *res = &ctx->mixer_res;
@@ -1094,6 +1108,7 @@ static void mixer_poweroff(struct exynos_drm_manager *mgr)
}
mutex_unlock(&ctx->mixer_mutex);
+ mixer_stop(ctx);
mixer_window_suspend(mgr);
ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index 4537026..5f32e1a 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -78,6 +78,7 @@
#define MXR_STATUS_BIG_ENDIAN (1 << 3)
#define MXR_STATUS_ENDIAN_MASK (1 << 3)
#define MXR_STATUS_SYNC_ENABLE (1 << 2)
+#define MXR_STATUS_REG_IDLE(1 << 1)
#define MXR_STATUS_REG_RUN (1 << 0)
/* bits for MXR_CFG */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] drm/exynos: defer hdmi probe when fail to get regulators
HDMI probe proceeds with dummy regulators when the regulators
are not provided in DT node or regulator provider has not get
probed or failed to register the regulators.
This patch modify hdmi driver to defer the probe in case the
regulators are not available.
Signed-off-by: Rahul Sharma
---
v2: Return Error code from devm_regulator_get_optional (as it is).
Based on exynos-drm-fixes branch in Inki dae's tree.
drivers/gpu/drm/exynos/exynos_hdmi.c | 69 --
1 file changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index c104d0c..d05da3b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -83,7 +83,7 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
- struct regulator_bulk_data *regul_bulk;
+ struct regulator**regulators;
int regul_count;
};
@@ -2022,6 +2022,36 @@ static void hdmi_commit(struct exynos_drm_display
*display)
hdmi_conf_apply(hdata);
}
+int hdmi_regulator_enable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = &hdata->res;
+ int i, ret;
+
+ for (i = 0; i < res->regul_count; ++i) {
+ ret = regulator_enable(res->regulators[i]);
+ if (ret < 0) {
+ DRM_ERROR("fail to enable regulators.\n");
+ return ret;
+ }
+ }
+ return 0;
+}
+
+int hdmi_regulator_disable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = &hdata->res;
+ int i, ret;
+
+ for (i = 0; i < res->regul_count; ++i) {
+ ret = regulator_disable(res->regulators[i]);
+ if (ret < 0) {
+ DRM_ERROR("fail to disable regulators.\n");
+ return ret;
+ }
+ }
+ return 0;
+}
+
static void hdmi_poweron(struct exynos_drm_display *display)
{
struct hdmi_context *hdata = display->ctx;
@@ -2039,8 +2069,8 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
pm_runtime_get_sync(hdata->dev);
- if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
- DRM_DEBUG_KMS("failed to enable regulator bulk\n");
+ if (hdmi_regulator_enable(hdata))
+ DRM_DEBUG_KMS("failed to enable regulators\n");
/* set pmu hdmiphy control bit to enable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
@@ -2077,7 +2107,8 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
- regulator_bulk_disable(res->regul_count, res->regul_bulk);
+ if (hdmi_regulator_disable(hdata))
+ DRM_DEBUG_KMS("failed to disable regulators\n");
pm_runtime_put_sync(hdata->dev);
@@ -2192,24 +2223,24 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
clk_set_parent(res->mout_hdmi, res->sclk_pixel);
- res->regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
- sizeof(res->regul_bulk[0]), GFP_KERNEL);
- if (!res->regul_bulk) {
- ret = -ENOMEM;
- goto fail;
- }
+ res->regul_count = ARRAY_SIZE(supply);
+
+ res->regulators = devm_kzalloc(dev, res->regul_count *
+ sizeof(res->regulators[0]), GFP_KERNEL);
+ if (!res->regulators)
+ return -ENOMEM;
+
for (i = 0; i < ARRAY_SIZE(supply); ++i) {
- res->regul_bulk[i].supply = supply[i];
- res->regul_bulk[i].consumer = NULL;
- }
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), res->regul_bulk);
- if (ret) {
- DRM_ERROR("failed to get regulators\n");
- return ret;
+ res->regulators[i] =
+ devm_regulator_get_optional(dev, supply[i]);
+ if (IS_ERR(res->regulators[i])) {
+ DRM_ERROR("fail to get regulator: %s.\n",
+ supply[i]);
+ return PTR_ERR(res->regulators[i]);
+ }
}
- res->regul_count = ARRAY_SIZE(supply);
- return ret;
+ return 0;
fail:
DRM_ERROR("HDMI resource init - failed\n");
return ret;
--
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 1/2] ASoC: max98090: Add max98091 compatible string
On 06/21/2014 02:02 AM, Doug Anderson wrote:
> Tushar,
>
> On Fri, Jun 20, 2014 at 1:03 AM, Tushar Behera wrote:
>> From: Wonjoon Lee
>>
>> The MAX98091 CODEC is the same as MAX98090 CODEC, but with an extra
>> microphone. Existing driver for MAX98090 CODEC already has support
>> for MAX98091 CODEC. Adding proper compatible string so that MAX98091
>> CODEC can be specified from device tree.
>>
>> Signed-off-by: Wonjoon Lee
>> Signed-off-by: Doug Anderson
>> Signed-off-by: Tushar Behera
>> ---
>>
>> Picked from https://chromium-review.googlesource.com/#/c/184091/
>>
>> .../devicetree/bindings/sound/max98090.txt |2 +-
>> sound/soc/codecs/max98090.c|2 ++
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/max98090.txt
>> b/Documentation/devicetree/bindings/sound/max98090.txt
>> index a5e63fa..c454e67 100644
>> --- a/Documentation/devicetree/bindings/sound/max98090.txt
>> +++ b/Documentation/devicetree/bindings/sound/max98090.txt
>> @@ -4,7 +4,7 @@ This device supports I2C only.
>>
>> Required properties:
>>
>> -- compatible : "maxim,max98090".
>> +- compatible : "maxim,max98090" or "maxim,max98091".
>>
>> - reg : The I2C address of the device.
>>
>> diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
>> index f5fccc7..4f5534d 100644
>> --- a/sound/soc/codecs/max98090.c
>> +++ b/sound/soc/codecs/max98090.c
>> @@ -2460,12 +2460,14 @@ static const struct dev_pm_ops max98090_pm = {
>>
>> static const struct i2c_device_id max98090_i2c_id[] = {
>> { "max98090", MAX98090 },
>> + { "max98091", MAX98091 },
>
> optional: This would allow you to add some extra error checking in
> max98090_probe() to make sure that the device-tree specified device
> matched the device that was detected. That could be in a future
> patch, though.
>
> Reviewed-by: Doug Anderson
>
Okay. I will add that in a follow-up patch.
Thanks for reviewing.
--
Tushar Behera
--
To unsubscribe from 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
