Re: [PATCH 0/4] Add support for Exynos clock output configuration
Hi Tomasz, On Tue, May 20, 2014 at 5:43 PM, Tomasz Figa t.f...@samsung.com wrote: Since the block responsible for handling the pin is PMU, not CMU, a separate driver, that binds to PMU node is required and acquires all input clocks by standard DT clock look-up. This way we don't need any cross-IP block drivers and cross-driver register sharing or nodes for fake devices. To represent the PMU mux/gate clock, generic composite clock is registered. Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. Depends on: [PATCHv5 0/4] Enable usbphy and hsotg for exynos4 (No link, sorry, I could not find it in any archive yet...) for Exynos4210/4x12 PMU binding and DT nodes. This isn't working for me. Testing linus master e99cfa2d0634881b8a41d56c48b5956b9a3ba162 plus: ARM: dts: exynos4: add port sub-nodes to exynos usb host modules ARM: dts: exynos4412-odroidx: enable common hardware blocks ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device) ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3 Testing on ODROID-U2. I apply the first patch here (clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy) and things continue to work. Now when I add the second patch clk: samsung: exynos4: Add CLKOUT clock hierarchy boot hangs at: [4.753740] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 02:43:30 UTC (946694610) [4.753809] ### dt-test ### No testcase data in device tree; not running tests [4.791155] gps-power-domain: Power-off latency e Any ideas? Thanks Daniel -- 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/4] ARM: dts: exynos4: add port sub-nodes to exynos usb host modules
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: This patch adds port sub-nodes to exynos4 ehci and ohci modules, which are required by recently merged new exynos4 usb2 phy support. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com I checked this against the DT binding documentation for the samsung,exynos4210-ohci and samsung,exynos4210-ehci nodes, and also the usb2 phy binding docs. Looks fine. Also tested on ODROID-U2, seems to be working: ehci-exynos: EHCI EXYNOS driver exynos-ehci 1258.ehci: EHCI Host Controller exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1 exynos-ehci 1258.ehci: irq 102, io mem 0x1258 exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-exynos: OHCI EXYNOS driver ...and the onboard USB (EHCI) ethernet adapter works. Nice. The only thing I don't quite understand is the relationship between EHCI and OHCI controllers, one being at 1258 and the other at 1259000; the SoC docs (which I have not studied in detail) don't make this very clear to me - no registers listed at base address 1259? Anyway, Reviewed-by: Daniel Drake dr...@endlessm.com -- 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] ARM: dts: exynos4412-odroidx: enable common hardware blocks
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: This patch adds support for common hardware modules available on all Exynos4412-based Odroid boards, which already have complete support in mainline kernel. This includes secure firmware calls, watchdog, g2d and fimc (mem2mem) multimedia accelerators. For the secure firmware, this is indeed required for U2/U3, otherwise the system crashes in weird ways during early boot. If this entry also makes sense for ODROID-X, I'm surprised it was not there already, does it boot without it? As for the watchdog, g2d and fimc, is there really any Exynos4412 configuration where such components are not available? Sorry if that is a silly question - just wondering why we wouldn't enable these in exynos4412.dtsi. Thanks Daniel -- 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] ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device)
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: From: Kamil Debski k.deb...@samsung.com This patch adds basic support for USB modules (host and device) on OdroidX board. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Checked that this conforms to the documented DT bindings. Reviewed-by: Daniel Drake dr...@endlessm.com -- 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] ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3
On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: This patch moves some parts of exynos4412-odroidx.dts to common exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz instead of 1.4GHz), while U2/U3 differs from X2 by different way of routing signals to host USB hub. It also lacks some hw modules not yet supported by those dts files (i.e. LCD touch panel). Thanks for this! It is working on ODROID-U2: at least eMMC/SD, LED, serial. Just 2 minor questions from reviewing: Odroid-X DTS used to have serial ports at 1382 and 1383, this patch removes them, but leaves 2. I can understand the idea of removing entries for ports that are not available on the board, but I've never seen an ODROID with 2 serial ports - should we bring this down to just the 1 enabled serial port that is accessible? Odroid-X DTS used to enable EHCI port 2, but with this refactoring, no longer does. Intentional? Thanks Daniel -- 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/2] Sound support for Exynos4412 Odroid X2, U3 board
On Wed, Jun 18, 2014 at 5:22 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: This series adds basic sound support for the Odroid X2/U3 boards. It relies on specific Exynos Audio Subsystem clock parent and frequencies being pre-configured. My full testing git branch has been pushed to: git://linuxtv.org/snawrocki/samsung.git v3.16-rc1-odroid-sound-clk Thanks for this! I tested these patches plus the ones in your branch to integrate with the ODROID. I tested ODROID-U2's 3.5mm analog headphone jack output with: # speaker-test -c 2 -t wav -l 2 On my x86 laptop this command takes ~6 seconds and produces audible output: Front left, front right, front left, front right When those words are reproduced over the speakers, there is a corresponding message printed to stdout which synchronizes nicely. On ODROID-U2 the same command doesn't work quite right - execution takes only 3.5 seconds and the audible output is truncated: Front left, front right, front and the stdout messages do not really coincide with the audio being reproduced at that time. No pulseaudio or anything like that. Can you reproduce this? Thanks Daniel -- 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/2] Sound support for Exynos4412 Odroid X2, U3 board
On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: I could reproduce such behaviour on the U3 board, but only with u-boot which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather than 800 MHz, which was the case in my original environment. All fout_mpll child clocks have then different frequency values in both cases. It's a bit strange though, because frequencies of all the audio subsystem clocks seem to be same anyway: I'm using the standard uboot from hardkernel. # cat /sys/kernel/debug/clk/clk_summary This command makes the kernel totally hang, weird. # speaker-test -c 2 -t wav -l 2 -p 1024 This plays back fine. Could it be a problem with the samsung-i2s driver, not correctly flushing at the right times? Or do you think the problem is more likely to be clock-related? Thanks Daniel -- 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
sdhci_s3c_consider_clock scheduling while atomic - clk_round_rate
sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts disabled, and this calls into sdhci_s3c_consider_clock(). The patch mmc: sdhci-s3c: Cache bus clock rates addressed some scheduling while atomic in this function, but there are more issues here, seen while testing 3.16-rc2 on exynos4412: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:103 in_atomic(): 1, irqs_disabled(): 128, pid: 75, name: mmcqd/0 Preemption disabled at:[ (null)] (null) CPU: 0 PID: 75 Comm: mmcqd/0 Not tainted 3.16.0-rc2-00028-ge9fe7eb-dirty #77 [c0016140] (unwind_backtrace) from [c0011e14] (show_stack+0x10/0x14) [c0011e14] (show_stack) from [c05ce8a8] (dump_stack+0x84/0xc4) [c05ce8a8] (dump_stack) from [c05d2de0] (mutex_lock+0x1c/0x3c) [c05d2de0] (mutex_lock) from [c046214c] (clk_prepare_lock+0x6c/0xf4) [c046214c] (clk_prepare_lock) from [c04625ac] (clk_round_rate+0x10/0x2c) [c04625ac] (clk_round_rate) from [c0447628] (sdhci_s3c_set_clock+0x4c/0x1e8) [c0447628] (sdhci_s3c_set_clock) from [c0447818] (sdhci_cmu_set_clock+0x54/0x140) [c0447818] (sdhci_cmu_set_clock) from [c0443a38] (sdhci_do_set_ios+0x138/0x58c) [c0443a38] (sdhci_do_set_ios) from [c0443864] (sdhci_set_ios+0x28/0x34) clk_round_rate cannot be called here because it takes a mutex. sdhci_s3c_set_clock() also calls into clk_prepare_enable() which looks like it could trigger this problem too. Daniel -- 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] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote: The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are powered on and off. I guess this replaces the patch titled drivers: phy: exynos4x12-phy: fix HSIC1 power on/off sequence Tested on ODROID-U2. Seems to be working as well as the previous patch: - Internal SMSC hub works on boot and after reboot, tested with USB mouse - Internal SMSC ethernet device works on boot, but disappears upon reboot. (same as previous patch, also reproduced by Marek) Thanks, Daniel -- 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] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Tue, Jun 24, 2014 at 4:35 PM, Kamil Debski k.deb...@samsung.com wrote: By reboot I guess that you mean typing reboot or by using SysRq magic and not power cycling? If so, I had experienced the same symptoms. I guess that the Ethernet chip is not reset properly and fails to enumerate without power cycling (it's nRESET pin is connected to P3V3). I found that removing regulator-always-on from buck8_reg: BUCK8 in the dts file fixes this problem. Yes, that fixes the problem. Thanks! Tested-by: Daniel Drake dr...@endlessm.com -- 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 support for Exynos clock output configuration
Hi, On Tue, Jun 24, 2014 at 5:08 PM, Tomasz Figa t.f...@samsung.com wrote: Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. for all the patches: Tested-by: Daniel Drake dr...@endlessm.com Tested on ODROID-U2 alongside phy: phy-samsung-usb2: Change phy power on/power off sequence now USB is working fine. Thanks! Daniel -- 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/6] clk: samsung: exynos4: Remove SRC_MASK_ISP gates
Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote: ISP special clocks have dedicated gating registers and so MUX SRC_MASK register should not be used. This patch fixes the problem of Exynos4x12-based boards freezing on system suspend, because those mux outputs need not to be masked while suspending. Not sure if you will be interested in this, as your plate must be pretty full already, and I am probably the first person to try suspend/resume on ODROID, but: ODROID-U2 fails to suspend/resume. I am testing with rtcwake, trying to raise a wakeup alarm on the internal Exynos4412 RTC. For this, CONFIG_COMMON_CLK_MAX77686 must be disabled (otherwise it disables the upstream 32KHz clock source for the RTC), I also have CONFIG_RTC_DRV_MAX77686 disabled so that there is only one RTC to worry about. Then: rtcwake --utc -m mem -s 10 -v Before this patch, it would totally hang after calling cpu_suspend() (checked with S3C_PMDBG) - not sure if it hangs before sleeping, or if it sleeps but simply fails to wake up. With this patch, now it seems like the RTC alarm does wake up the system after the desired time, however it immediately goes back into uboot rather than resuming into Linux. So this patch does make some progress at least. The power light is on at all times during these tests (not sure if that means anything, but I was wondering if it should go out when the system suspends). Thanks Daniel -- 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/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Testing against 3.16-rc2, this doesn't quite work for me. SAMSUNG_PM_DEBUG still doesn't appear in menuconfig. HAVE_SAMSUNG_PM_DEBUG is 'n'. Looks like the select from DEBUG_S3C_UART is not working, but I'm not sure why. Daniel -- 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/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
On Wed, Jun 25, 2014 at 12:43 PM, Tomasz Figa t.f...@samsung.com wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. I replaced the original patch with this updated version and can confirm that the option now appears in the menu again, and compile succeeds when set to yes. Thanks Daniel -- 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/2] ARM: EXYNOS: Add support for firmware-assisted suspend/resume
Hi Tomasz, On Wed, Jun 25, 2014 at 5:18 PM, Tomasz Figa t.f...@samsung.com wrote: On a numer of Exynos-based boards Linux kernel is running in non-secure mode under a secure firmware. This means that certain operations need to be handled in special way, with firmware assistance. System-wide suspend/resume is an example of such operations. Thanks for working on this. Tested on ODROID-U2, it almost works! Now instead of resetting upon resume, the system does go back into Linux. However things go wrong at that point - maybe some memory corruption? A memory allocation error from the USB stack, and then an unhandled abort about 5 seconds which usually kills my bash process. I'll try to find some time to investigate a bit more. In the mean time, the crash log is below. I'm testing with rtcwake -m mem -s 10. That's using the internal RTC with the max77686 RTC driver not built to avoid confusion. Also the max77686 clk driver must be disabled otherwise it disables the upstream clock source of the exynos's RTC. Enabling non-boot CPUs ... CPU1: Booted secondary processor CPU1 is up CPU2: Booted secondary processor CPU2 is up CPU3: Booted secondary processor CPU3 is up PM: noirq resume of devices complete after 1.460 msecs PM: early resume of devices complete after 1.603 msecs s3c-rtc 1007.rtc: rtc disabled, re-enabling usb usb1: root hub lost power or was reset s3c-i2c 1386.i2c: slave address 0x00 s3c-i2c 1386.i2c: bus frequency set to 214 KHz s3c-i2c 1387.i2c: slave address 0x00 s3c-i2c 1387.i2c: bus frequency set to 71 KHz usb 1-2: reset high-speed USB device number 2 using exynos-ehci swapper/0: page allocation failure: order:0, mode:0x284000 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc2-00034-g8f86926 #118 [c0016140] (unwind_backtrace) from [c0011e14] (show_stack+0x10/0x14) [c0011e14] (show_stack) from [c05b27f4] (dump_stack+0x84/0xc4) [c05b27f4] (dump_stack) from [c00b5398] (warn_alloc_failed+0x108/0x128) [c00b5398] (warn_alloc_failed) from [c00b8858] (__alloc_pages_nodemask+0x924/0xa3c) [c00b8858] (__alloc_pages_nodemask) from [c00ea824] (new_slab+0xd8/0x340) [c00ea824] (new_slab) from [c05b0abc] (__slab_alloc.isra.53.constprop.58+0x280/0x3b0) [c05b0abc] (__slab_alloc.isra.53.constprop.58) from [c00ec7dc] (kmem_cache_alloc+0x118/0x204) [c00ec7dc] (kmem_cache_alloc) from [c02ba680] (radix_tree_node_alloc+0x8c/0x98) [c02ba680] (radix_tree_node_alloc) from [c02baed4] (__radix_tree_create+0x128/0x1c4) [c02baed4] (__radix_tree_create) from [c02baf9c] (radix_tree_insert+0x2c/0xd4) [c02baf9c] (radix_tree_insert) from [c02db86c] (add_dma_entry+0x84/0x144) [c02db86c] (add_dma_entry) from [c03ccd08] (usb_hcd_map_urb_for_dma+0x450/0x540) [c03ccd08] (usb_hcd_map_urb_for_dma) from [c03cd660] (usb_hcd_submit_urb+0x6cc/0x7f8) [c03cd660] (usb_hcd_submit_urb) from [c03c1300] (rx_submit+0xe4/0x210) [c03c1300] (rx_submit) from [c03c1630] (rx_complete+0x19c/0x20c) [c03c1630] (rx_complete) from [c03cbd48] (__usb_hcd_giveback_urb+0x6c/0xd0) [c03cbd48] (__usb_hcd_giveback_urb) from [c03cc88c] (usb_giveback_urb_bh+0xa0/0xcc) [c03cc88c] (usb_giveback_urb_bh) from [c00289e8] (tasklet_action+0xcc/0x14c) [c00289e8] (tasklet_action) from [c0028b70] (__do_softirq+0x108/0x24c) [c0028b70] (__do_softirq) from [c0028f20] (irq_exit+0x98/0xe4) [c0028f20] (irq_exit) from [c000f31c] (handle_IRQ+0xa0/0xc4) [c000f31c] (handle_IRQ) from [c0008628] (gic_handle_irq+0x4c/0x68) [c0008628] (gic_handle_irq) from [c00129c0] (__irq_svc+0x40/0x70) Exception stack(0xc07f9f58 to 0xc07f9fa0) 9f40: ffed 9f60: ffed c080048c c05bba78 c07f4f10 c08401aa 9f80: c07f8000 0001 c07f9fa0 c000f5c4 c000f5c8 6153 [c00129c0] (__irq_svc) from [c000f5c8] (arch_cpu_idle+0x28/0x2c) [c000f5c8] (arch_cpu_idle) from [c005db24] (cpu_startup_entry+0x138/0x238) [c005db24] (cpu_startup_entry) from [c07abbd4] (start_kernel+0x3ac/0x3b8) Mem-info: Normal per-cpu: CPU0: hi: 186, btch: 31 usd: 94 CPU1: hi: 186, btch: 31 usd: 30 CPU2: hi: 186, btch: 31 usd: 0 CPU3: hi: 186, btch: 31 usd: 0 HighMem per-cpu: CPU0: hi: 186, btch: 31 usd: 98 CPU1: hi: 186, btch: 31 usd: 0 CPU2: hi: 186, btch: 31 usd: 0 CPU3: hi: 186, btch: 31 usd: 0 active_anon:4564 inactive_anon:267 isolated_anon:0 active_file:9994 inactive_file:5258 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:347626 slab_reclaimable:4068 slab_unreclaimable:5438 mapped:4418 shmem:913 pagetables:174 bounce:0 free_cma:32441 Normal free:131792kB min:3444kB low:4304kB high:5164kB active_anon:4372kB inactive_anon:272kB active_file:33896kB inactive_file:4512kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:778240kB managed:743296kB mlocked:0kB dirty:0kB writeback:0kB mapped:5208kB shmem:908kB slab_reclaimable:16272kB slab_unreclaimable:21752kB kernel_stack:928kB pagetables:696kB unstable:0kB
exynos-drm 1024x768 HDMI output
Hi, Thanks a lot for this exynos-drm commit: commit 62747fe0ad5169a767987d9009e3398466555cde Author: Sean Paul seanp...@chromium.org Date: Tue Jan 15 08:11:08 2013 -0500 drm/exynos: hdmi: support extra resolutions using drm_display_mode timings As you probably know, many people had written off the Exynos4's capability to output to non-TV resolutions over HDMI. Now, with your patch, 640x480 works perfectly, and other resolutions are hopefully within reach. I would like to get 1024x768 working on Exynos4412. I'm using a Sony TV which has an EDID that offers 1024x768 in its established timing bitmap - i.e. it supports 1024x768 via the standard/ancient VESA timings. I have tested the TV with other devices, it seems to work fine at this res. However, on Exynos4412 with exynos-drm, running at this resolution is not quite right. The very first row of pixels is rendered perfectly, but all off the others are offset and wrapped. I'll try to explain with some ASCII art: A X B Imagine that is the complete first 3 rows of pixels shown on my display. The first row, with pixels A, is complete, and starts and finishes where it should do on the physical display. However, the second row on the display starts with a series of always-black pixels, this is the region marked X, which occupies 257 pixels. Immediately after, the second row of pixels of the output image starts (B), then when it hits the end of the screen, it wraps around onto the next row of pixels on the screen. Then the third row of the image pixels starts (C) and so on. Sounds like a hsync issue, right? I have been playing with the register writes in hdmi_v14_mode_set() but I can't quite get a perfect output. Is there any documentation available for these registers? Why do we have to program the numbers twice (once in HDMI regs, once in timing generator regs)? Specifically, I have not yet found an explanation for why the first row gets rendered right, and I haven't found a way to reduce the size of region X, although I have figured out how to move it around: The standard timings for 1024x768 are: hdisplay=1024 hsync_start=1048 hsync_end=1185 htotal=1344 Using these numbers, exynos-drm writes: tg-hact_st = 320 tg-hact_sz = 1024 If I subtract and add 257 (the size of the black region X) respectively, i.e. tg-hact_st = 63 tg-hact_sz = 1288 Then I get the following: X B C i.e. all rows of displayed output are now fine, except for the first. On the first row, the leftmost 257 pixels of output are no longer visible anywhere, the rest of them start in the wrong place (top left, rather than 257 pixels in), and the black region X is now positioned at the right hand side of the first row. That is the closest I have found so far. Any thoughts or tips much appreciated. Thanks Daniel -- 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: exynos-drm 1024x768 HDMI output
On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake dr...@endlessm.com wrote: What I feel we are missing here is an explanation for why the first row of pixels is treated differently from the rest. Every value that I tweak seems to have an effect on the first line (which was rendered OK) as well as all the others (which were bad). If it were just a matter of tweaking e.g. h_fsz then I would expect *all* rows of pixels to have been rendered badly in the first place. Nevertheless, I'm happy to continue throwing values at the variables if that is our best option... We need to find a way of making a change that effects the only first line, or all the lines except the first. I have an idea, but my understanding of CRT timings isn't quite strong enough to tell me exactly how to implement it. Maybe you can help suggest what variables to tweak in order to try this experiment: Lets just accept the fact that the first line of the output image is rendered badly. Specifically, it has 257 black pixels added onto the end of it. The following rows do not exhibit that problem. To accept and ignore this oddity, I want to make the device start outputting the image exactly 1024+257 pixels too early. i.e. I want 1281 junk pixels before the image starts. Then, I want to adjust the timing parameters appropriately so that those junk pixels do not appear on the display. I want those 1281 junk pixels to be sent to the display during the horizontal scans that happen before the top left visible pixel is clocked. I think I'm saying: I want to adjust the field of view so that those 1281 junk pixels are rendered inside the vertical back porch. Does that make any sense? Daniel -- 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: exynos-drm 1024x768 HDMI output
On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake dr...@endlessm.com wrote: Lets just accept the fact that the first line of the output image is rendered badly. Specifically, it has 257 black pixels added onto the end of it. The following rows do not exhibit that problem. To accept and ignore this oddity, I want to make the device start outputting the image exactly 1024+257 pixels too early. i.e. I want 1281 junk pixels before the image starts. Then, I want to adjust the timing parameters appropriately so that those junk pixels do not appear on the display. I want those 1281 junk pixels to be sent to the display during the horizontal scans that happen before the top left visible pixel is clocked. I think I'm saying: I want to adjust the field of view so that those 1281 junk pixels are rendered inside the vertical back porch. Nearly got something working along these lines: tg-vact_st -= 1 tg-vact_sz += 1 Now the 257 bad pixels start at the top left of my display (rather than on the second row of visible pixels), and that causes the annoying horizontal wrap that I wrote about in my first mail. So add from earlier: tg-hact_st -= 257 tg-hact_sz + 257 Now the displayed image looks good. But looking closer, I am missing the first horizontal row of pixels, and the rightmost vertical column of pixels. Daniel -- 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: drm_do_probe_ddc_edid ENXIO check too aggressive?
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter dan...@ffwll.ch wrote: Have a bit of logic in the exynos -detect function to re-try a 2nd round of edid probing after each hdp interrupt if the first one returns an -ENXIO. Only tricky part is to be careful with edge detection so that userspace gets all the hotplug events still. Presuming you don't have any funkiness with reprobing causing yet another hpd interrupt and stuff like that (seen it all), as long as you're using the helpers in drm_crtc_helper.c it should all be working correctly. So you want a work item which just grabs all modeset locks and then calls drm_helper_probe_single_connector_modes or something on the right connector. Thanks for the tips. Having trouble sticking to those details though. exynos_drm_connector_detect() is actually a long way away from EDID probing so it is hard to detect the ENXIO case there. What happens here is: exynos hdmi_irq_thread() calls drm_helper_hpd_irq_event() That then calls exynos_drm_connector_detect(), which returns a simple yes, hpd detection says we are connected Then it calls drm_kms_helper_hotplug_event() for which the call chain is: drm_kms_helper_hotplug_event exynos_drm_output_poll_changed drm_fb_helper_hotplug_event drm_fb_helper_probe_connector_mode exynos_drm_connector_fill_modes drm_helper_probe_single_connector_modes exynos_drm_connector_get_modes drm_get_edid drm_do_get_edid drm_do_probe_ddc_edid -- ENXIO in here drm_do_probe_ddc_edid actually swallows the ENXIO code and just returns -1, so that particular error is indistinguishable from others. Trying to follow your suggestions, the closest would seem to be something like: 1. Modify exynos_drm_connector_detect to read and cache the EDID right away. If EDID read fails for any reason, report no connection and schedule a work item to retry the EDID read. If the later EDID read succeeds, call drm_kms_helper_hotplug_event() 2. Modify exynos_drm_connector_get_modes to return cached EDID Does that sound sensible? Thanks Daniel -- 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: drm_do_probe_ddc_edid ENXIO check too aggressive?
On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter dan...@ffwll.ch wrote: I think we can do it simpler. When you get a hpd interrupt you eventually call drm_helper_hpd_irq_event which will update all the state and poke connectors. I'd just create a delay_work which you launch from hdmi_irq_thread with a 1 second delay which again calls drm_helper_hpd_irq_event. That way you won't miss the EDID (presuming the user isn't _really_ careful with pluggin in the cable slowly). OK, I like this more simplistic option. However, one more pesky detail, if I am understanding your suggestion correctly. You are hoping for: 1. I connect the display, causing HPD interrupt 2. hpd irq handler calls drm_helper_hpd_irq_event() directly. Fails to read EDID, no big deal. 3. hpd irq handles schedules a work item to call drm_helper_hpd_irq_event() a second time, 1 second later. Reads EDID sucessfully, image gets output to display. That doesn't quite work. drm_helper_hpd_irq_event() in step 2 notices and records the state change (disconnected -- connected). And after drm_helper_probe_single_connector_modes() fails to read the EDID, it starts outputting an image at 1024x768. When we come to step 3, we call drm_helper_hpd_irq_event again, but that just returns without doing anything as it does not detect any new state change. If we skip step 2, i.e. always delay the call to drm_helper_hpd_irq_event by 1 second, the problem is solved. As a user, the 1 second delay is not noticable. What do you think about just doing this? Daniel -- 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: drm_do_probe_ddc_edid ENXIO check too aggressive?
On Wed, Dec 18, 2013 at 1:58 PM, Daniel Kurtz djku...@chromium.org wrote: +seanpaul I think the problem is that the hdmi irq is really just an undebounced gpio interrupt, and thus, it is firing way too soon. The chromium kernel adds an excplicit 1.1 second timer to debounce hpd between the hdmi hpd-gpio irq and taking any action (ie reading the edid). I believe this will eventually make its way upstream, but is still pending some other patches: http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=blob;f=drivers/gpu/drm/exynos/exynos_hdmi.c;h=1258c67e87f360c846c64bb3f04436a68018b4fe;hb=refs/heads/chromeos-3.8#l2647 Yes, this looks very similar to the approach I tried earlier. I guess the patch was written for the same reasons as well. Sean, any objections to me taking your patch and sending it upstream? http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=77aed71acf4b84e722ead24c820d8ad059121e5b Thanks Daniel -- 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: drm_do_probe_ddc_edid ENXIO check too aggressive?
On Wed, Dec 18, 2013 at 2:18 PM, Daniel Drake dr...@endlessm.com wrote: Yes, this looks very similar to the approach I tried earlier. I guess the patch was written for the same reasons as well. Sean, any objections to me taking your patch and sending it upstream? http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=77aed71acf4b84e722ead24c820d8ad059121e5b Seems easier said than done. The patch looks innocent but it touches on other stuff that has changed a lot. For example, it adds cancel_delayed_work_sync() in the hdmi_poweroff() path. With my naive backport to vanilla-3.8, hdmi_poweroff() gets called within the context of that work item, and a work item trying to cancel_delayed_work_sync() on itself hangs. Reproduced just by unplugging the display once. I see that things have changed substantially in the ChromiumOS tree, for example this patch probably has some effect: commit 29ae0c6096395a96a597453271946fc7d8442b6e Author: Sean Paul seanp...@chromium.org Date: Thu Jun 20 17:24:12 2013 -0400 drm/exynos: Consolidate suspend/resume in drm_drv As this job seems bigger than anticipated and I don't have any Exynos hardware that can boot mainline, I think I might have to stop here, and hope that ChromiumOS guys upstream all this soon? Daniel -- 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
s5p-mfc firmware load path
Hi, linux-firmware git layout suggests that s5p-mfc firmware should be installed to /lib/firmware/s5p-mfc and this is where distros seem to be installing it. However, the request_firmware calls in the s5p-mfc driver cause the kernel to look for the firmware at /lib/firmware directly, and fail to find it under such configurations. Which is the correct fix for this inconsistency? Thanks, Daniel -- 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
exynos-drm HDMI PHY configuration values
Hi Sean, In your commit drm/exynos: hdmi: support extra resolutions using drm_display_mode timings you added several more HDMI PHY configs to exynos-drm. Thanks for that. Can you explain where these magic numbers came from? I'm interested in adding 85.5MHz for 1366x768 support. Thanks, Daniel -- 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] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Tue, Jul 1, 2014 at 4:15 PM, Kamil Debski k.deb...@samsung.com wrote: The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are powered on and off. Signed-off-by: Kamil Debski k.deb...@samsung.com Tested on ODROID-U2 with the internal LAN (which is a USB device), and an external USB mouse connected via the internal USB hub. Tested-by: Daniel Drake dr...@endlessm.com -- 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 0/3] Deterministic UART numbering on Samsung SoCs
Hi,
How can we move forward here?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa t.f...@samsung.com wrote:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
disabled in DT),
Yes, the kernel help text documents this quite well:
config SERIAL_SAMSUNG
tristate Samsung SoC serial support
depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
provide all of these ports, depending on how the serial port
pins are configured.
- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
naming change OK? You could argue that userspace that relies on fixed
device paths is a bit broken, but that argument would be a bit cloudy
given the kernel documentation for the ttySAC devices above.
- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.
That's right, that problem is left to the user, but at least we'd be
consistent with other SoCs (and open to generic solutions to that
inconvenience).
Daniel
--
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 2/2] ASoC: samsung: Add machine driver for Odroid X2/U3
Hi Sylwester, On Fri, Jul 4, 2014 at 2:13 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: This patch adds the sound subsystem driver for Odroid-X2 and Odroid-U3 boards. The codec works in I2S master mode; there are two separate audio routing paths defined, as there are differences in the signal routing between the X2 and U3 boards, i.e. U3 uses single jack for headphones and microphone. Signed-off-by: Chen Zhen zhen1.c...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Testing on ODROID-U2, v3 is not quite working for me, but v2 of the patch was fine. I boot up, run: # speaker-test -c 2 -t wav As soon as I hear the word front I press ctrl+c and then run the command again. Now the command hangs with no audible output. Any ideas? Let me know if you have trouble reproducing. Thanks Daniel -- 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
mixer_check_mode drops Exynos5 display modes
Hi Sean, While looking at the following commit I noticed something: commit f041b257a8997c8472a1013e9f252c3e2a1d879e Author: Sean Paul seanp...@chromium.org Date: Thu Jan 30 16:19:15 2014 -0500 drm/exynos: Remove exynos_drm_hdmi shim This commit changes how mixer_check_mode() is used. It used to just exclude certain modes on old mixer versions, but now it seems to be called unconditionally, for all mixer versions. I guess the effect here is that some modes on exynos5 setups are dropped whereas they weren't before. Is that intentional? Thanks Daniel -- 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: [alsa-devel] [PATCH V3 2/2] ASoC: samsung: Add machine driver for Odroid X2/U3
On Thu, Jul 10, 2014 at 5:15 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 08/07/14 11:15, Daniel Drake wrote: Testing on ODROID-U2, v3 is not quite working for me, but v2 of the patch was fine. I boot up, run: # speaker-test -c 2 -t wav As soon as I hear the word front I press ctrl+c and then run the command again. Now the command hangs with no audible output. Any ideas? Let me know if you have trouble reproducing. I just posted a patch addressing this, please let me know if there are any further issues. Sorry for not testing sooner. Your patch solves the issue. Thanks Daniel -- 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 0/4] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled
Hi Bartlomiej, On Wed, Jul 9, 2014 at 6:17 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: This patch series adds support for AFTR idle mode on boards with secure firmware enabled and allows EXYNOS cpuidle driver usage on Exynos4x12 SoCs. It has been tested on Trats2 board (using Exynos4412 SoC with secure firmware enabled) on which AFTR mode reduces power consumption by ~12% when EXYNOS cpuidle driver is enabled (in both cases the default exynos_defconfig config is used and CPU1-3 are offlined). Thanks for this, I have tested it on ODROID-U2. I don't have any equipment to measure the power usage, but after offlining CPUs 1,2,3 via sysfs online file, a printk I added confirms that the system is going to enter aftr mode, and system stability seems as good as ever. Is there any automatic way that the cpus should be offlined, or is the intention that it must be done by hand like this? Thanks, Daniel -- 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/2] ARM: dts: ODROID i2c improvements
Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available when the board is wired up the right way. In this case,
the vendor kernel has run at this speed for a long time.
sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cb6f55f..adadaf9 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -134,6 +134,8 @@
i2c@1386 {
pinctrl-0 = i2c0_bus;
pinctrl-names = default;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 40;
status = okay;
usb3503: usb3503@08 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: Enable PMIC interrupts on ODROID
The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.
This is needed for the max77686-irq driver to create the PMIC IRQ
domain, which is needed by max77686-rtc.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 6d6d23c..cb6f55f 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -148,6 +148,10 @@
max77686: pmic@09 {
compatible = maxim,max77686;
+ interrupt-parent = gpx3;
+ interrupts = 2 0;
+ pinctrl-names = default;
+ pinctrl-0 = max77686_irq;
reg = 0x09;
#clock-cells = 1;
@@ -368,4 +372,11 @@
samsung,pins = gpx1-3;
samsung,pin-pud = 0;
};
+
+ max77686_irq: max77686-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add Exynos4412 based Odroid X2 and U2/U3/U3+ support
Hi Olof, Thanks for joining the party here :) On Fri, Jul 18, 2014 at 6:56 AM, Olof Johansson o...@lixom.net wrote: Anyone got a simple writeup on the steps needed to boot, bl1/2 needed, expected offset into eMMC for where it goes, etc? https://github.com/hardkernel/u-boot/blob/odroid-v2010.12/sd_fuse/sd_fusing.sh is probably the best writeup :) https://github.com/hardkernel/u-boot/tree/odroid-v2010.12/sd_fuse has the blobs needed (they have not changed at all in the U3's history, so the ones you have already will work fine). Samsung guys are also upstreaming support into uboot, including a README.odroid in the last commit with this info: http://patchwork.ozlabs.org/project/uboot/list/?submitter=23519 I gave the kernel (next-0717) a go here on my U3, and it boots (as you mention, no USB comes up). Nice. USB works with the later patches floating around. I do see a few KERN_ERR printks though: [ERR] [0.00] L2C: failed to init: -19 This one is fixed with the patch series Enable L2 cache support on Exynos4210/4x12 SoCs [ERR] [0.001302] missing device node for CPU 0 [ERR] [0.001344] missing device node for CPU 1 [ERR] [0.001366] missing device node for CPU 2 [ERR] [0.001386] missing device node for CPU 3 Not sure about these - I still get them with all the patches applied. [ERR] [0.156490] max77686 0-0009: irq is not specified I submitted a patch for this, ARM: dts: Enable PMIC interrupts on ODROID [ERR] [1.339498] /i2c@1386/usb3503@08: could not get #clock-cells for /system-controller@1002 [ERR] [1.348050] ERROR: could not get clock /i2c@1386/usb3503@08:refclk(0) I think these go away with the USB patches floating around. [ERR] [1.383055] max77686-rtc max77686-rtc: max77686_rtc_init_reg: fail to write controlm reg(-6) [ERR] [1.391108] max77686-rtc max77686-rtc: Failed to initialize RTC reg:-6 Fixed with ARM: dts: ODROID i2c improvements Daniel -- 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: add CPU nodes for Exynos4 SoCs
On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation when topology is read from DT) fixed GIC driver to filter cluster ID from values returned by cpu_logical_map() for SoCs having registers mapped without per-CPU banking making it is possible to add CPU nodes for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also required by future changes adding initialization of cpuidle states in Exynos cpuidle driver through DT. This conflicts with work in the thread cpufreq: use generic cpufreq drivers for exynos platforms which is already in its 7th iteration. Perhaps best to work directly with Thomas to help him finish that series? Daniel -- 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/2] clk: samsung: exynos4: Enable ARMCLK down feature
On Fri, Jul 18, 2014 at 3:36 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of ARMCLK will be reduced upon entering idle mode (WFI or WFE). The feature behaves like very fast cpufreq ondemand governor. In idle mode this reduces energy consumption on full frequency chosen by cpufreq governor by approximately: - Trats2: 6.5% (153 mA - 143 mA) - Trats: 33.0% (180 mA - 120 mA) - Gear1: 27.0% (180 mA - 130 mA) The patch uses simillar settings as Exynos5250 (clk-exynos5250.c), except it disables clock up feature and on Exynos4412 ARMCLK down is enabled for all 4 cores. Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and Samsung Gear 1 (Exynos4212). Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Tested on ODROID-U2, seems to be working. I don't have a way of measuring the power usage, but the system seems as stable as before. Tested-by: Daniel Drake dr...@endlessm.com -- 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 0/3] Deterministic UART numbering on Samsung SoCs
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: I like the sound of going to the standard ttyS notation and only providing ports for ones that exist, but is this userspace-visible ttyS is 8250 compatible UARTS. If the Samsung is not an 8250 compatible UART then it doesn't belong as ttyS from the kernel perspective. OK, thanks for pointing that out. So we stick with the ttySAC namespace. And by doing that, and sticking to the existing and documented behaviour, it seems like we have already addressed Russells's concern: The problem you're raising is very much the same problem you have when there are multiple USB serial devices connected to the machine - you just get a bunch of /dev/ttyUSB* devices which are unordered (they can change on each boot, or change order if you disconnect and reconnect them.) In this case, we have a dedicated namespace and the path information is already fully encoded in the device name. The order and number of ports are fixed, they can't be disconnected and reconnected. There is no real risk of an additional serial controller driver coming to play in the ttySAC namespace. So I think Tomasz's approach is good - although I haven't looked at the code in detail. Thanks Daniel -- 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 Exynos4412 based Odroid X2 and U2/U3/U3+ support
On Tue, Aug 19, 2014 at 8:40 PM, Olof Johansson o...@lixom.net wrote: ODROID-U3 has been broken in mainline for quite a while. Have patches been posted for this already? http://arm-soc.lixom.net/bootlogs/mainline/v3.17-rc1/odroidu3-arm-exynos_defconfig.html for one of the latest boots that failed. Yes, discussed in the thread titled [PATCH 1/2] ARM: dts: Enable PMIC interrupts on ODROID Those patches weren't important for boot at the time of submission, but it looks like something else changed (the max77686 driver?) that makes them now required. Daniel -- 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 Exynos4412 based Odroid X2 and U2/U3/U3+ support
On Wed, Aug 20, 2014 at 8:18 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: More importantly I wonder if a design where a IRQ line is not connected to the max77686 PMIC makes even sense. If such a design is possible then the interrupt property should be optional but if not then I think that the driver should fail to probe in that case. Yes, it is a regression but also the Odroid DTS was not following the DT binding and was just lucky that the driver was not checking the required DT properties. I think it would not be totally unreasonable to have such a design with no IRQ line hookup - after all we just did a load of ODROID work on 3.16 without this interrupt being available, and we didn't notice. At the same time, I think its unlikely that someone wouldn't just hook this up, it is sensible to put this kind of thing on the board even if you don't have an immediate need for it, and all the reference designs will have it. No strong preference but I would vote for the slightly simpler option of having the max77686 driver require the interrupt specified (like now), until someone comes along with a board that physically lacks it. Daniel -- 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] drm/exynos: fix plane-framebuffer linkage
Pageflipping currently causes some inconsistencies that lead to crashes. Just run an app that causes a CRTC pageflip in a raw X session and check that it exits cleanly and can be restarted - you'll see crashes like: Unable to handle kernel NULL pointer dereference at virtual address 0334 PC is at exynos_drm_crtc_plane_commit+0x20/0x40 LR is at exynos_drm_crtc_plane_commit+0x20/0x40 [c03749b4] (exynos_drm_crtc_plane_commit) from [c03741bc] (exynos_drm_crtc_commit+0x44/0x70) [c03741bc] (exynos_drm_crtc_commit) from [c03743a0] (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4) [c03743a0] (exynos_drm_crtc_mode_set_commit.isra.2) from [c03744f4] (exynos_drm_crtc_page_flip+0x140/0x1a8) [c03744f4] (exynos_drm_crtc_page_flip) from [c036b20c] (drm_mode_page_flip_ioctl+0x224/0x2dc) [c036b20c] (drm_mode_page_flip_ioctl) from [c035c324] (drm_ioctl+0x338/0x4fc) These crashes happen because drm_plane_force_disable has previously set plane-crtc to NULL. When drm_mode_page_flip_ioctl() is used to flip another framebuffer onto the primary plane, crtc-primary-fb is correctly updated (this is a virtual plane created by plane_helper), but plane-fb is not (this plane is the real one, created by exynos_drm_crtc_create). We then come to handle rmfb of the backbuffer, which the real primary plane is incorrectly pointing at. So drm_framebuffer_remove() decides that the buffer is actually active on a plane and force-disables the plane. Ensuring that plane-fb is kept up-to-date solves that issue, but exposes a reference counting problem. Now we see crashes when rmfb is called on the front-buffer, because the rmfb code expects to drop 3 references here, and there are only 2. That can be fixed by adopting the reference management found in omapdrm: Framebuffer references are not taken directly in crtc mode_set context, but rather in the context of updating the plane, which also covers flips. Like omapdrm we also unreference the old framebuffer here. Signed-off-by: Daniel Drake dr...@endlessm.com --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b68e58f..7aa9dee 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, if (manager-ops-mode_set) manager-ops-mode_set(manager, crtc-mode); - ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, crtc_w, crtc_h, - x, y, crtc_w, crtc_h); - if (ret) - return ret; - - plane-crtc = crtc; - plane-fb = crtc-primary-fb; - drm_framebuffer_reference(plane-fb); - - return 0; + return exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, +crtc_w, crtc_h, x, y, crtc_w, crtc_h); } static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y, diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 8371cbd..df27e35 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc, overlay-crtc_x, overlay-crtc_y, overlay-crtc_width, overlay-crtc_height); + if (plane-fb) + drm_framebuffer_unreference(plane-fb); + + drm_framebuffer_reference(fb); + + plane-fb = fb; + plane-crtc = crtc; + exynos_drm_crtc_plane_mode_set(crtc, overlay); return 0; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Clock list for s3c-rtc device: - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC. - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC. Is this RTC source clock needed for all Exynos SoCs? It is at least needed on Exynos4412, which has the XrtcXTI thing exactly as you describe. However the very standard setup there is to hook it up to the CP clock output of the MAX76686 PMIC. This CP clock is on by default, so you can potentially live without that detail being present in the DT. However... one small issue with this setup is that when you enable CONFIG_COMMON_CLK_MAX77686, the CP clock gets exposed in Linux's common clock framework, and Linux then turns it off because it believes it is unused. Then the RTC stops ticking. So the rtc_src idea would also be good for Exynos4412. Maybe it would make sense to drop the needs_src_clk flag, and simply require/enable the src clock whenever it is present in the DT. Also, are you sure about the way you are treating this clock, all those enable/disable calls? You only seem to enable it when doing some particular driver operations e.g. reading the time, leaving it disabled at all other times. However I believe on Exynos4412 that if you disable this clock then the RTC will not tick. Daniel -- 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] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim jy0922.s...@samsung.com wrote: It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c. My patch moves that drm_framebuffer_reference() call to the plane function which is called from crtc_mode_set context (and also called in crtc pageflip path), so there should be no problem here. Chip specific drm driver internally doesn't have to care fb reference count if there is no special case. We should have switched to universal plane at that time. To me it seems like the chip-specific DRM drivers do need to add a reference in the crtc_mode_set and crtc page flip paths otherwise framebuffer removal crashes (expecting to remove 3 references), as noted by my testing and also in commit 25c8b5c304. However, I'll be happy if universal planes means the driver does not have to care about this any more. Andrej, please go ahead if you are interested, I'll be happy to test your results. Thanks Daniel -- 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] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter dan...@ffwll.ch wrote: I think fb refcounting in exynos is just plain busted. If you look at other drivers the only place the refcount framebuffers or backing storage objects is for pageflips to make sure the memory doesn't go away while the hw is still scanning out the old framebuffer. If you refcount anywhere else you either do something really crazy or your driver is broken. With my patch actually the behaviour is much more similar to omapdrm, which also doesn't quite match your description of other drivers. See omap_plane.c. There is a fb reference taken for pinning in update_pin() which presumably is what you describe - avoid destroying the fb while it is being scanned out. (Maybe exynos should have something equivalent too, but thats a separate issue) However there is *another* fb reference taken in omap_plane_mode_set(). And my patch is modelled to do the same in exynos-drm. I believe this is necessary under the current model. At least, when drm_mode_rmfb() is running for the last user of the active framebuffer, it expects to drop 3 references from the framebuffer before dropping the 4th causes the object to be destroyed, as follows: 1. drm_mode_rmfb explicitly drops a reference - it calls __drm_framebuffer_unregister which then calls __drm_framebuffer_unreference /* Mark fb as reaped, we still have a ref from fpriv-fbs. */ __drm_framebuffer_unregister(dev, fb); 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls drm_mode_set_config_internal() in order to turn off the CRTC, dropping another reference in the process. if (tmp-old_fb) drm_framebuffer_unreference(tmp-old_fb); 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops another reference: /* disconnect the plane from the fb and crtc: */ __drm_framebuffer_unreference(old_fb); 4. drm_framebuffer drops the final reference itself, to cause freeing of the object: drm_framebuffer_unreference(fb); So ordinarily, after a fb is created by drm core (with refcnt at 1), there would have to be 3 references added to it by the time it is the primary fb so that when we do rmfb, it has a refcnt of 4, and gets freed correctly. (The second bug I was seeing with pageflips was that refcnt was 3, which means that the final reference was dropped in (3) above, but __drm_framebuffer_unreference doesn't like that at all - it calls drm_framebuffer_free_bug) Not being overly familiar with DRM internals I tried to go backwards to find out where these 3 references would be created during normal operation. 2 are clear: 1. drm_framebuffer_init() explicitly grabs one: /* Grab the idr reference. */ drm_framebuffer_reference(fb) 2. drm_mode_set_config_internal() takes one: if (tmp-primary-fb) drm_framebuffer_reference(tmp-primary-fb); Where should the 3rd one be created? I don't know, but looking at previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm driver should take one, both on crtc mode set and crtc page flip. However, I'll be happy if universal planes means the driver does not have to care about this any more. Andrej, please go ahead if you are interested, I'll be happy to test your results. universal planes will fix up the mess with 2 drm plane objects (primary plane + exonys internal primary). So should help to untangle this not, but it will not magically fix the refcounting bugs itself. So even when we move to universal planes (fixing 1 of the issues), its good that we're having this refcount discussion (which we need to understand to confidently solve the 2nd issue). Thanks for your input! Daniel -- 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
pwm-samsung: incorrect register values for 100% duty cycle
Hi, I'm using pwm-samsung on Exynos4412 for a variable-brightness LED. When the LED is set to maximum brightness via the pwm-leds driver, we arrive at pwm_samsung_config with duty_ns = period_ns, i.e. 100% duty cycle. This function does: /* -1UL will give 100% duty. */ --tcmp; writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm)); I think that comment is incorrect. If tcmp is written as -1UL then the LED totally turns off. And there is nothing in the Exynos4412 manual to suggest that -1UL should be set in the TCMP register for 100% duty. If I remove that --tcmp line, so that 100% duty cycle is handled as tcmp=0, the problem is solved: the LED turns on at max brightness when the leds subsystem requests so. Any ideas? Is this -1UL thing a quirk from older chip versions not applicable to Exynos4? Thanks Daniel -- 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] drm/exynos: fix plane-framebuffer linkage
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake dr...@endlessm.com wrote: 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls drm_mode_set_config_internal() in order to turn off the CRTC, dropping another reference in the process. if (tmp-old_fb) drm_framebuffer_unreference(tmp-old_fb); 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops another reference: /* disconnect the plane from the fb and crtc: */ __drm_framebuffer_unreference(old_fb); If 3. here is about the primary plane then this won't happen, since the primary plane pointerreference has already been cleared in step 2. I just checked - as Joonyoung suspects, the plane being force disabled in step 3 is the private exynos-drm plane. So thats an issue - but at least now I have a complete understanding of the problem. Sounds like that will also be fixed by moving to universal planes. I'll wait for Andrzej's patch. Thanks! Daniel -- 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: Specify default clocks for Exynos4 FIMC devices
Hi Sylwester, On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki s.nawro...@samsung.com wrote: The default mux and divider clocks are specified in device tree so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are clocked from recommended clock source and with maximum supported frequency. If needed these settings could be overrode in board specific dts files, however they are in practice optimal in most cases. Just curious about the Exynos4x12 situation here. You set the FIMC clocks as 176MHz, child of MPLL, which works for ODROID with a divider: 880MHz MPLL / 5 = 176MHz However, talking of recommended frequencies... Is 880MHz really the standard there? Isn't 800MHz the more common one? Also, if you happen to know, I would be curious about the equivalent and recommended situation for the sclk_mfc clock. On the vendor kernel it is clocked at 880/4 = 220MHz. When booting mainline on an odroid it is 880/16 = 55MHz :/ Thanks Daniel -- 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: Specify default clocks for Exynos4 FIMC devices
On Wed, Sep 10, 2014 at 10:37 AM, Sylwester Nawrocki s.nawro...@samsung.com wrote: The default mux and divider clocks are specified in device tree so that the FIMC devices in Exynos4210 and Exynos4x12 SoCs are clocked from recommended clock source and with maximum supported frequency. If needed these settings could be overrode in board specific dts files, however they are in practice optimal in most cases. Another consideration for this patch. fimc-core.c already has probe-time code that tries to set the clock frequency, using a clock-frequency property in the DT, and falling back to a hardcoded value in the driver. Maybe it is best to just set the clock rate from one place. Daniel -- 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] drm/exynos: switch to universal plane API
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda a.ha...@samsung.com wrote: The patch replaces legacy functions drm_plane_init() / drm_crtc_init() with drm_universal_plane_init() and drm_crtc_init_with_planes(). It allows to replace fake primary plane with the real one. Additionally the patch leaves cleanup of crtcs to core, this way planes and crtcs are cleaned in correct order. Signed-off-by: Andrzej Hajda a.ha...@samsung.com Thanks Andrzej! With your patch the crashes I was seeing are gone. Daniel -- 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-i2s: Maintain CDCLK settings across i2s_{shutdown/startup}
Hi Sylwester, On Thu, Jul 10, 2014 at 10:11 AM, Sylwester Nawrocki s.nawro...@samsung.com wrote: Currently configuration of the CDCLK pad is being overwritten in the i2s_shutdown() callback in order to gate the SoC output clock. However if an ASoC machine driver doesn't restore that clock settings each time after opening the sound device this results in the CDCLK pin being permanently configured into input mode. I.e. the output clock will always stay disabled. Fix that by saving the CDCLKCON bit state in i2s_shutdown() and and restoring it in the i2s_startup() callback. I'm still having trouble in this area on ODROID. Basically, if you start pulseaudio, all audio breaks. Even after you kill pulseaudio, audio is still broken. This happens because CDCLK gets disabled by i2s.c and never enabled again. pulseaudio does: 1. i2s_startup for playback channel 2. i2s_startup for capture channel 3. i2s_shutdown for capture channel 4. i2s_shutdown for playback channel In step 3 we disable CDCLK even though playback should still be active, oops. In step 4 we do this: u32 mod = readl(i2s-addr + I2SMOD); i2s-cdclk_out = !(mod MOD_CDCLKCON); and now cdclk_out is always going to be 0, so we'll never turn it back on again. Regardless of what we do now, I think there is a bug in i2s_shutdown in that it should not do any real shutdown stuff if the other stream (playback/capture) is open. However I'm wondering if we should more thoroughly clean up CDCLK handling. Right now CDCLK is enabled during boot in odroidx2_late_probe() (even if you never play any audio), and then sometimes disabled by i2s.c after the sound device has been opened and then closed, with a half-broken attempt to sometimes enable it again next time it is opened. We're in this situation because that setup is pretty fragile and confusing... Is CDCLK something ODROID-specific? Perhaps we could have startup/shutdown hooks in odroidx2_max98090.c that start and stop the clock (with proper refcounting), and remove CDCLK interaction from i2s.c. Is CDCLK something more generic for Samsung i2s devices? In that case we could enable it in i2s_startup, disable it in i2s_shutdown, and avoid interacting with it at all from odroidx2_max98090.c. (again with proper refcounting) Thanks Daniel -- 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: Specify default clocks for Exynos4 FIMC devices
On Thu, Sep 25, 2014 at 12:05 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: Just curious about the Exynos4x12 situation here. You set the FIMC clocks as 176MHz, child of MPLL, which works for ODROID with a divider: 880MHz MPLL / 5 = 176MHz However, talking of recommended frequencies... Is 880MHz really the standard there? Isn't 800MHz the more common one? AFAIK 880 MHz is recommended MPLL frequency for Exynos4412 EVT2.0, which is revision of the Exynos4412 SoC the Odroid U3 boards are populated with. You can read the main/sub revision information from the chip ID register (at 0x1000). Thanks for the information. Might be worth a quick comment in exynos4x12.dtsi then, saying that the defaults here are for Exynos4412 EVT2.0 and might want to be overridden for other versions of the SoC. Thanks Daniel -- 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: Specify default clocks for Exynos4 FIMC devices
On Thu, Sep 25, 2014 at 1:44 PM, Daniel Drake dr...@endlessm.com wrote: AFAIK 880 MHz is recommended MPLL frequency for Exynos4412 EVT2.0, which is revision of the Exynos4412 SoC the Odroid U3 boards are populated with. You can read the main/sub revision information from the chip ID register (at 0x1000). Thanks for the information. Might be worth a quick comment in exynos4x12.dtsi then, saying that the defaults here are for Exynos4412 EVT2.0 and might want to be overridden for other versions of the SoC. Also can you double check this? The old ODROID-X is Exynos4412 EVT1.0 and runs 880MHz MPLL. Daniel -- 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
3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1
Hi, Booting 3.17-rc6 on ODROID-U2, I see this message: ERROR: Bad of_node_put() on /ehci@1258/port@1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00376-g85cd8fd #1031 [c0016418] (unwind_backtrace) from [c0011f00] (show_stack+0x10/0x14) [c0011f00] (show_stack) from [c08213fc] (dump_stack+0x84/0xc4) [c08213fc] (dump_stack) from [c02dacc0] (kobject_cleanup+0x58/0x6c) [c02dacc0] (kobject_cleanup) from [c0608718] (of_get_next_available_child+0x78/0x98) [c0608718] (of_get_next_available_child) from [c05673c8] (exynos_ehci_probe+0x254/0x424) [c05673c8] (exynos_ehci_probe) from [c03ce700] (platform_drv_probe+0x2c/0x5c) [c03ce700] (platform_drv_probe) from [c03ccd00] (driver_probe_device+0xe8/0x234) [c03ccd00] (driver_probe_device) from [c03ccef8] (__driver_attach+0x68/0x8c) This repeats for all of the ehci and ohci ports. Haven't had time to dig deeper. Is this a known issue? Thanks Daniel -- 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: Enable temperature sensor on exynos4412 ODROID
The Exynos4412 has a Thermal Management Unit (TMU) which provides
a temperature sensor and related functionality.
This must be enabled on a per-board basis, as it requires a 100k
resistance to ground on the XtsRES_EXT pin, as well as a 1.8V input on
VDD18_TS pin. If that voltage is not supplied, the machine immediately
reports a maximum temperature of 255C and triggers the thermal subsystem
to shut down the system.
This patch also enables the TMU on the ODROID boards via the appropriate
power supply.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
arch/arm/boot/dts/exynos4412.dtsi | 10 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3d8c623..9994a44 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -400,3 +400,8 @@
samsung,pin-drv = 0;
};
};
+
+tmu {
+ status = okay;
+ vtmu-supply = ldo10_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 0f6ec93..ee58e7f 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -66,4 +66,14 @@
pmu_system_controller: system-controller@1002 {
compatible = samsung,exynos4412-pmu, syscon;
};
+
+ tmu: tmu@100C {
+ compatible = samsung,exynos4412-tmu;
+ interrupt-parent = combiner;
+ reg = 0x100C 0x100;
+ interrupts = 2 4;
+ clocks = clock CLK_TMU_APBIF;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: samsung: fix CDCLK handling
ODROID is the only platform that uses CDCLK, and right now,
CDCLK handling is buggy. If you start pulseaudio on ODROID,
audio is broken until reboot (even after killing pulse).
This happens because CDCLK gets disabled by i2s.c and never enabled again.
pulseaudio does:
1. i2s_startup for playback channel
2. i2s_startup for capture channel
3. i2s_shutdown for capture channel
4. i2s_shutdown for playback channel
In step 3 we disable CDCLK even though playback should still be active.
In step 4 we do this:
u32 mod = readl(i2s-addr + I2SMOD);
i2s-cdclk_out = !(mod MOD_CDCLKCON);
and now cdclk_out is always going to be 0, so we'll never turn it back
on again.
Both this bug and the one that b97c60abf9a tries to fix happened
because of the way that CDCLK handling is painfully split between
platform and i2s drivers.
Simplify the situation and solve the bug with the following approach:
- as before, samsung_i2s_dai_probe() gates CDCLK by default
(no need for smartq_wm8987 to do this as well)
- platform drivers can gate/ungate CDCLK as necessary
(currently only odroidx2 needs to do this)
- i2s code has no other interaction with CDCLK
Signed-off-by: Daniel Drake dr...@endlessm.com
---
sound/soc/samsung/i2s.c | 19 ++
sound/soc/samsung/odroidx2_max98090.c | 36 ++-
sound/soc/samsung/smartq_wm8987.c | 6 --
3 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 9d51347..6654ce6 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -68,8 +68,6 @@ struct i2s_dai {
#define DAI_OPENED (1 0) /* Dai is opened */
#define DAI_MANAGER(1 1) /* Dai is the manager */
unsigned mode;
- /* CDCLK pin direction: 0 - input, 1 - output */
- unsigned int cdclk_out:1;
/* Driver for this DAI */
struct snd_soc_dai_driver i2s_dai_drv;
/* DMA parameters */
@@ -739,9 +737,6 @@ static int i2s_startup(struct snd_pcm_substream *substream,
spin_unlock_irqrestore(lock, flags);
- if (!is_opened(other) i2s-cdclk_out)
- i2s_set_sysclk(dai, SAMSUNG_I2S_CDCLK,
- 0, SND_SOC_CLOCK_OUT);
return 0;
}
@@ -757,24 +752,14 @@ static void i2s_shutdown(struct snd_pcm_substream
*substream,
i2s-mode = ~DAI_OPENED;
i2s-mode = ~DAI_MANAGER;
- if (is_opened(other)) {
+ if (is_opened(other))
other-mode |= DAI_MANAGER;
- } else {
- u32 mod = readl(i2s-addr + I2SMOD);
- i2s-cdclk_out = !(mod MOD_CDCLKCON);
- if (other)
- other-cdclk_out = i2s-cdclk_out;
- }
+
/* Reset any constraint on RFS and BFS */
i2s-rfs = 0;
i2s-bfs = 0;
spin_unlock_irqrestore(lock, flags);
-
- /* Gate CDCLK by default */
- if (!is_opened(other))
- i2s_set_sysclk(dai, SAMSUNG_I2S_CDCLK,
- 0, SND_SOC_CLOCK_IN);
}
static int config_setup(struct i2s_dai *i2s)
diff --git a/sound/soc/samsung/odroidx2_max98090.c
b/sound/soc/samsung/odroidx2_max98090.c
index 278edf9..b700284 100644
--- a/sound/soc/samsung/odroidx2_max98090.c
+++ b/sound/soc/samsung/odroidx2_max98090.c
@@ -21,20 +21,37 @@ struct odroidx2_drv_data {
/* The I2S CDCLK output clock frequency for the MAX98090 codec */
#define MAX98090_MCLK 1920
+static int odroidx2_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+
+ if (rtd-cpu_dai-active)
+ return 0;
+
+ return snd_soc_dai_set_sysclk(rtd-cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_OUT);
+}
+
+static void odroidx2_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+
+ if (!rtd-cpu_dai-active)
+ snd_soc_dai_set_sysclk(rtd-cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_IN);
+}
+
+static const struct snd_soc_ops odroidx2_ops = {
+ .startup = odroidx2_startup,
+ .shutdown = odroidx2_shutdown,
+};
+
static int odroidx2_late_probe(struct snd_soc_card *card)
{
struct snd_soc_dai *codec_dai = card-rtd[0].codec_dai;
- struct snd_soc_dai *cpu_dai = card-rtd[0].cpu_dai;
- int ret;
- ret = snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
+ return snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
SND_SOC_CLOCK_IN);
- if (ret 0)
- return ret;
-
- /* Set the cpu DAI configuration in order to use CDCLK */
- return snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
- 0, SND_SOC_CLOCK_OUT);
}
static const struct snd_soc_dapm_widget odroidx2_dapm_widgets
Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1
On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.
When we are getting the child node using for_each_available_child_of_node(),
which calls for of_get_next_available_child(). So
of_get_next_available_child()
does a of_node_put() on the prev node, in case we have siblings to the
child.
Can you see if the below change helps ?
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci-phy[phy_number] = phy;
- of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
This is on top of usb-next.
If you are testing on rc6 only, then probably you will have to cherrypick two
patches each for ehci-exynos and ohci-exynos:
usb: host: ehci-exynos: Remove unnecessary usb-phy support
usb: host: ohci-exynos: Remove unnecessary usb-phy support
I made the equivalent change to 3.17-rc7 (right now 3.17 is my main
interest), i.e. removed all of_node_put calls from
exynos_ehci_get_phy(). Same change is needed in exynos_ohci_get_phy().
Now the warnings are gone.
BTW, I think the warning only appeared when CONFIG_OF_SELFTEST=y
I didn't check the implementation details like you did, but I looked
at a few other users of for_each_available_child_of_node and it looks
like indeed you do not need to call of_node_put() on the children in
the normal case, or at least, nobody else does.
Thanks,
Daniel
--
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: pwm-samsung: incorrect register values for 100% duty cycle
Hi, Thanks for looking into this. On Wed, Oct 1, 2014 at 4:55 AM, Tomasz Figa tomasz.f...@gmail.com wrote: I think that comment is incorrect. If tcmp is written as -1UL then the LED totally turns off. And there is nothing in the Exynos4412 manual to suggest that -1UL should be set in the TCMP register for 100% duty. Looking at Figure 11-3 in 11.3.2 Basic Timer Operation chapter of Exynos 4412 public datasheet [1] (page 659), the calculation above seems correct. The default state of timer output is high and if TCMP is set to a value higher than TCNT, then it will never toggle to low. [1] http://www.samsung.com/global/business/semiconductor/file/product/Exynos_4_Quad_User_Manaul_Public_REV1.00-0.pdf I read that diagram a bit differently. The default state of the output is high, but that is while PWM is inactive. It goes low at the point when the timer starts, and it also goes low when the timer later restarts every time. So once we enable PWM the output should be low. It will go high once TCMP == TCNT, but because TCMP is placed at the maximum value which is never hit, that will never happen, so the LED stays off. But I am confused on a few counts here... I may have identified above why a maximum TCMP value would not result in the output going high, but then why does the rest of the brightness scale work? If I set brightness 200 (tcmp=6470, tcnt=2) then the LED is on dimly. If I set brightness 254 (tcmp=117, tcnt=2) then the LED comes on much brighter. But according to my above explanation and looking at the diagram you referenced, such a decrease in the tcmp value would result in a shorter time for which the output is high, i.e. lower brightness, but actually the brightness increases. If the output is high by default, why don't I see the LED turning on in uboot before Linux has even loaded? Does the above diagram really apply to Linux? Because Linux sets the invert bit for all the channels in pwm_samsung_probe. So maybe that diagram is irrelevant until we invert the TOUT signal shown there? Daniel -- 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: pwm-samsung: incorrect register values for 100% duty cycle
On Thu, Oct 2, 2014 at 1:49 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This is strange. I remember verifying various edge cases with a scope on an Exynos4210-based Origen board and I don't recall any issues. Unfortunately I don't have appropriate hardware to recheck this specific case anymore. Could you specify on what board you are testing this or how the LED is wired? Its a new board prototype with Exynos4412. The PWM output connects to a APL5606AKI-TRG chip which does AC-to-DC conversion and multiplies the voltage, and outputs to a simple LED. Not the easiest unknown setup to work with, I know. I'll get hold of a multimeter and try to get a better understanding of what is happening. You've given me a few ideas. Thanks Daniel -- 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/5] clk: samsung: exynos4415: Add clocks using common clock framework
On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds the new clock driver of Exynos4415 SoC based on Cortex-A9 using common clock framework. The CMU (Clock Management Unit) of Exynos4415 controls PLLs(Phase Locked Loops) and generates system clocks for CPU, buses and function clocks for individual IPs. There seems to be a lot in common here with other exynos4 variants in clk-exynos4.c. Have you considered just adding support for the 4415 in the existing driver? Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC
On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds new exynos4415.dtsi to support Exynos4415 SoC based on Cortex-A9 quad cores and includes following dt nodes: There's a lot in common between your new exynos4415.dtsi and the existing exynos4.dtsi. Would it make more sense for the 4415 code to extend the existing exynos4.dtsi like the other Exynos4 variants do? Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC
On Fri, Oct 24, 2014 at 7:34 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Well, I also thought about such approach, but there are some fundamental differences: interrupt and clock controllers are completely different. Using a common exynos4.dtsi and overriding them in every node will result in a code, which is a bit hard to follow. IMHO with such differences justifies using separate base dtsi file. For the things that aren't in common, they are already split out into soc-specific files for the existing Exynos4 variants. Taking your example of the CMU, it already differs in different exynos4 versions therefore is not listed in exynos4.dtsi at all. So this argument only seems valid if the differences are really huge, or if you are also saying the existing exynos4 dts files are bad? Personally I have come to like the current layout, although would definitely appreciate the reference-based syntax mentioned by Tomasz, and this seems like a good opportunity to at least fix up exynos4.dtsi for that. Daniel -- 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
