Re: [linux-sunxi] Booting devel device tree kernel on Cubietruck
sorry I did not realize that your are booting from NFS, I had my own mmc driver. I guess you could use initramfs. I've not tried to boot from NFS before. On Thu, May 22, 2014 at 3:56 PM, Yassin Jaffer yassinjaf...@gmail.comwrote: setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait On Thu, May 22, 2014 at 2:26 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: I can't get anywhere trying to boot a devel device tree kernel on Cubietruck. This is with https://github.com/jwrdegoede/linux-sunxi.git and the linux-devel branch. I don't get any boot output. I can boot a 3.4 kernel without problem. I followed these steps. http://linux-sunxi.org/Mainline_Kernel_Howto I also tried turning on low level printk but still no output U-Boot SPL 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Board: Cubietruck DRAM: 2048 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 sun7i# tftp 0x4900 /var/lib/tftpboot/ct.dtb dwmac.1c5 Waiting for PHY auto negotiation to complete done Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/ct.dtb'. Load address: 0x4900 Loading: ## 7.6 MiB/s done Bytes transferred = 24030 (5dde hex) sun7i# tftp 0x4600 /var/lib/tftpboot/uImage Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/uImage'. Load address: 0x4600 Loading: # # 12.3 MiB/s done Bytes transferred = 1837040 (1c07f0 hex) sun7i# env set fdt_high sun7i# sun7i# bootm 0x4600 - 0x4900 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1836976 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4900 Booting using the fdt blob at 0x4900 Loading Kernel Image ... OK Using Device Tree in place at 4900, end 49008ddd Starting kernel ... -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Nand issue in A20 custom board.
Hi all, We are using A20 custom board , in that we have sk hynix nand of 4 gb. once i booted ubuntu from sdcard with nand used=1 in script. i am getting otp copy 0 is ok! in contineous loop. but once i disable nand in script , ubuntu is working fine. and i also tried flashing android to nand from Phonix suite but getting fallowing error. nand driver init failed. Your help will be greatly appreciable. Regards Punith -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. 6Booting Linux on physical CPU 0 6Initializing cgroup subsys cpuset 6Initializing cgroup subsys cpu 5Linux version 3.4.61+ (embdes@embdes-desktop) (gcc version 4.6.3 20120201 (prerelease) (crosstool-NG linaro-1.13.1-2012.02-20120222 - Linaro4 CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: sun7i 6Memory cut off: 6 MALI : 0x5c00 - 0x5fff ( 64 MB) 4Ignoring unrecognised tag 0x 6Memory Reserved: 6 SYS : 0x4300 - 0x4300 ( 64 kB) 6 VE : 0x4400 - 0x48ff ( 80 MB) 6 G2D : 0x4900 - 0x49ff ( 16 MB) 6 LCD : 0x5a00 - 0x5bff ( 32 MB) Memory policy: ECC disabled, Data cache writealloc 6sunxi: Allwinner A20 (AW1651/sun7i) detected. 7On node 0 totalpages: 245760 7free_area_init_node: node 0, pgdat c0a2d840, node_mem_map d000 7 DMA zone: 512 pages used for memmap 7 DMA zone: 0 pages reserved 7 DMA zone: 65024 pages, LIFO batch:15 7 Normal zone: 1008 pages used for memmap 7 Normal zone: 111632 pages, LIFO batch:31 7 HighMem zone: 528 pages used for memmap 7 HighMem zone: 67056 pages, LIFO batch:15 6PERCPU: Embedded 7 pages/cpu @d0808000 s7360 r8192 d13120 u32768 7pcpu-alloc: s7360 r8192 d13120 u32768 alloc=8*4096c 7pcpu-alloc: c[0] c0 c[0] c1 c Built 1 zonelists in Zone order, mobility grouping on. Total pages: 243712 5Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 loglevel=8 panic=10 rootfstype=ext4 rootwait 6PID hash table entries: 4096 (order: 2, 16384 bytes) 6Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) 6Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) 6allocated 2097152 bytes of page_cgroup 6please try 'cgroup_disable=memory' option if you don't want memory cgroups 6Memory: 448MB 512MB = 960MB total 5Memory: 828952k/828952k available, 154088k reserved, 270336K highmem 5Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xf000 - 0xff00 ( 240 MB) lowmem : 0xc000 - 0xef80 ( 760 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc0981970 (9703 kB) .init : 0xc0982000 - 0xc09bbcc0 ( 232 kB) .data : 0xc09bc000 - 0xc0a39720 ( 502 kB) .bss : 0xc0a39744 - 0xc0c05f90 (1843 kB) 6SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 6Preemptible hierarchical RCU implementation. 6 RCU dyntick-idle grace-period acceleration is enabled. 6 Additional per-CPU info printed with stalls. 6NR_IRQS:192 6Architected local timer running at 24.00MHz. 6sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms 2start_kernel(): bug: interrupts were enabled early 6Console: colour dummy device 80x30 6Calibrating delay loop... c761.03 BogoMIPS (lpj=3805184) 6pid_max: default: 32768 minimum: 301 6Mount-cache hash table entries: 512 6Initializing cgroup subsys cpuacct 6Initializing cgroup subsys memory 6Initializing cgroup subsys devices 6Initializing cgroup subsys freezer 6Initializing cgroup subsys blkio 6Initializing cgroup subsys perf_event 6CPU: Testing write buffer coherency: ok 6CPU0: thread -1, cpu 0, socket 0, mpidr 8000 6hw perfevents: enabled with ARMv7 Cortex-A7 PMU driver, 5 counters available 6Setting up static identity map for 0x406a93c8 - 0x406a9420 CPU1: Booted secondary processor 6CPU1: thread -1, cpu 1, socket 0, mpidr 8001 6Brought up 2 CPUs 6SMP: Total of 2 processors activated (1527.80 BogoMIPS). 6devtmpfs: initialized 6dummy: 6NET: Registered protocol family 16 6hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. 6hw-breakpoint: maximum watchpoint size is 8 bytes. 6[ccu-inf] aw clock manager init 6[ccu-inf] aw_ccu_init 6[ccu-inf] script config pll4 to 300MHz 6[ccu-inf] script config pll6 to 600MHz 6[ccu-inf] script config pll7 to 297MHz 6[ccu-inf] script config pll8 to 336MHz 6Init eGon pin module V2.0 6bio: create slab bio-0 at 0 6sunxi_gpio driver init ver 1.3 6gpiochip_add: registered GPIOs 1 to 2 on device: A1X_GPIO 5SCSI subsystem initialized 7libata version 3.00 loaded. 6usbcore:
Re: [linux-sunxi] [PATCH] Add qt840a
Hi, On 05/21/2014 10:23 PM, Amit Kucheria wrote: Hi Hans, (Do you explicitly change headers so that a reply-all doesn't include your email id? If so, I won't manually try to add you back again) No googlegroups does that automatically (a bit of a mis feature). Still there is no need to add me back again, I will see the mail regardless. On Sun, May 18, 2014 at 4:00 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 05/16/2014 10:38 AM, Amit Kucheria wrote: On Fri, May 16, 2014 at 1:17 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 05/15/2014 08:56 PM, Amit Kucheria wrote: On Thu, May 15, 2014 at 11:41 PM, Hans de Goede hdego...@redhat.com wrote: Hi, Thanks for the patch. Looking at the outside of the qt840a box, I believe it is the same as the q5 (and the brandless box I have). With a PCB labelled i12 and I've already added a fex file for that ... Can you confirm that you've the same pcb as this one: http://www.aliexpress.com/item/Q5-Allwinner-A20-Android-4-2-Dual-Core-1-2GHz-OTA-Miracasr-DLNA-Support-1G-RAM/1834930044.html Yes, it looks identical and does say I12 on the PCB. Good, since I'm having trouble with my I12 tv box with the ethernet I've ordered a qt840a for myself. This seems to also use a different Shall we keep the wiki page I created[1]? Yes that seems like a good idea, not some highres pictures of the entire pcb (both front and back) would make a good addition. Will do. Also can you please: 1) Create a link named I12-tvbox from the frontpage to this page. 2) Add some notes that the same pcb is also used in a tvbox called the q5 and in some brandless boxes (with the same port layout / enclosure) 3) Add a note that the qt840a uses an ap6330 wifi/bt module where as the q5 and nonames uses an ap6210 wifi.bt module. Done. Thanks! snip And also does your ethernet port work ? Mine is flaky, and it seems that the fex file is incorrect wrt the ethernet (on my pcb it needs PH21 as emac power gpio to work at all. Have you tried to disabling screen1_output_type in your fex file? Disabling it kills my ethernet for some very strange reason I cannot figure out yet. Keeping it enabled gives me lots of kernel warnings and dire messages of LCD in danger Have you tried setting disp_mode to 0 ? After that the screen1_output_* should no longer matter. Note that LCD1 also uses PH21, so that may be part of the problem. Same thing with the ctp_int_port - I was confused why it needed to be enabled for ethernet to work until you mentioned PH21 as the emac/gmac power gpio. Having added that line to [gmac_para] I can now disable the [ctp_para] but still unable to disable screen1_output_type. I switched to gmac and disabled RGMII-by-default in the gmac driver to get it to work. I'll send out the patch now that I know my earlier patches actually hit the list. Is your ethernet phy also the ic ip101a-lp ? Yes. Hmm, and it works reliable ? Can you try to ping -f something-on-your-lan and see if you experience any packet drop. I get 10% packet drop or more. Yes, I've done ping testing, nothing more yet. Regular ping, or ping -f ? ping -f floods the line with as much packets as possible so it is a bit more of a stress test. My ip101a-lp also gets quite hot, can you touch yours (for a while) while it is in operation to see if it too gets hot ? I've a feeling mine is just broken ... I'll try it out. Great, let me know how it goes :) The ethernet is indeed flaky with a kernel oops showing up after a bit. Does your phy chip also get hot (mine gets almost too hot to touch for a long period of time, but only if an ethernet cable is actually plugged in) ? Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Add qt840a
On Thu, May 22, 2014 at 2:27 PM, Hans de Goede hdego...@redhat.com wrote: And also does your ethernet port work ? Mine is flaky, and it seems that the fex file is incorrect wrt the ethernet (on my pcb it needs PH21 as emac power gpio to work at all. Have you tried to disabling screen1_output_type in your fex file? Disabling it kills my ethernet for some very strange reason I cannot figure out yet. Keeping it enabled gives me lots of kernel warnings and dire messages of LCD in danger Have you tried setting disp_mode to 0 ? After that the screen1_output_* should no longer matter. Note that LCD1 also uses PH21, so that may be part of the problem. Yes, tried that as well. The gmac driver does not attach to the PHY. Log here[1]. Renabling screen1_output gets rid of the PHY error and ethernet works. Same thing with the ctp_int_port - I was confused why it needed to be enabled for ethernet to work until you mentioned PH21 as the emac/gmac power gpio. Having added that line to [gmac_para] I can now disable the [ctp_para] but still unable to disable screen1_output_type. snip Does your phy chip also get hot (mine gets almost too hot to touch for a long period of time, but only if an ethernet cable is actually plugged in) ? My phy chip doesn't seem to be heating as much, it seems. Regards, Amit [1] http://pastebin.com/09Re5vwf -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun7i: cubietruck: set mmc3 bus-width property
On Wed, May 21, 2014 at 07:43:30PM +0200, Hans de Goede wrote: bus-width defaults to 1, and all 4 lines are hooked up at the cubietruck, properly set bus-width to 4. Signed-off-by: Hans de Goede hdego...@redhat.com Merged the two patches, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH] Add qt840a
Hi, On 05/22/2014 11:20 AM, Amit Kucheria wrote: On Thu, May 22, 2014 at 2:27 PM, Hans de Goede hdego...@redhat.com wrote: And also does your ethernet port work ? Mine is flaky, and it seems that the fex file is incorrect wrt the ethernet (on my pcb it needs PH21 as emac power gpio to work at all. Have you tried to disabling screen1_output_type in your fex file? Disabling it kills my ethernet for some very strange reason I cannot figure out yet. Keeping it enabled gives me lots of kernel warnings and dire messages of LCD in danger Have you tried setting disp_mode to 0 ? After that the screen1_output_* should no longer matter. Note that LCD1 also uses PH21, so that may be part of the problem. Yes, tried that as well. The gmac driver does not attach to the PHY. Log here[1]. Renabling screen1_output gets rid of the PHY error and ethernet works. That log definitely looks like something is messing with PH21, no idea how to fix this (I've been doing all my testing with the upstream kernel, using dts files rather then fex files). Same thing with the ctp_int_port - I was confused why it needed to be enabled for ethernet to work until you mentioned PH21 as the emac/gmac power gpio. Having added that line to [gmac_para] I can now disable the [ctp_para] but still unable to disable screen1_output_type. snip Does your phy chip also get hot (mine gets almost too hot to touch for a long period of time, but only if an ethernet cable is actually plugged in) ? My phy chip doesn't seem to be heating as much, it seems. Ok, that confirms that my phy chip likely is bust then. I'll retest when I receive my own QT840a. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Nand issue in A20 custom board.
While flashing through phonix suite i got fallowing error in continuous loop in serial port. FES:INFO : ..1 FES:INFO : ..2 FES:INFO : ..3 FES:INFO : ..5 FES:INFO : ..6 FES:INFO : ..7 FES:INFO : ..8 FES:INFO : ..9 FES:CONFIG_USB_GADGET_DUALSPEED FES:fes connect to host FES:USB_MOV_DATA_BY_DMA! FES:INFO : ..10... FES:jump to fes_main FES:INFO: fes_protocol_process start FES:[info]: set address 3 FES:write special pipe FES:INFO: fed reg_addr = 0x4011f6f4 FES:fed para[0] = 0x40a0 FES:fed para[1] = 0x40a01000 FES:fed para[2] = 0x FES:fed para[3] = 0x [Fed]:- [Fed]:Hello, Nand Register [Fed]:- NHW : start nand scan [NAND] nand driver(A20) version: 0x2, 0x12, data: 20130826 2119 NFC Randomizer start. [SCAN_DBG] Nand flash chip id is:0xad 0xd7 0x94 0x91 0x60 0x44 NFC Read Retry Init. chip 0, block 8, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 9, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 10, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 11, page 0, oob: 0xff, 0xff, 0xff, 0xff [PHY_DBG] can't get right otp value from nand otp blocks, then use otp command _vender_get_param_otp_hynix time 0! otp copy 0 is ok! set retry default value: 0 0 0 0 0 0 0 0 NFC_LSBExit [PHY_DBG] repair otp value end chip 0, block 8, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 9, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 10, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 11, page 0, oob: 0xff, 0xff, 0xff, 0xff [PHY_DBG] can't get right otp value from nand otp blocks, then use otp command _vender_get_param_otp_hynix time 0! otp copy 0 is ok! set retry default value: 0 0 0 0 0 0 0 0 NFC_LSBExit [PHY_DBG] repair otp value end chip 0, block 8, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 9, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 10, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 11, page 0, oob: 0xff, 0xff, 0xff, 0xff [PHY_DBG] can't get right otp value from nand otp blocks, then use otp command _vender_get_param_otp_hynix time 0! otp copy 0 is ok! set retry default value: 0 0 0 0 0 0 0 0 NFC_LSBExit [PHY_DBG] repair otp value end chip 0, block 8, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 9, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 10, page 0, oob: 0xff, 0xff, 0xff, 0xff chip 0, block 11, page 0, oob: 0xff, 0xff, 0xff, 0xff [PHY_DBG] can't get right otp value from nand otp blocks, then use otp command Kindly tell me what will be the issue. Regards Punith -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Booting devel device tree kernel on Cubietruck
Op 22 mei 2014, om 14:13 heeft jonsm...@gmail.com het volgende geschreven: On Thu, May 22, 2014 at 2:14 AM, Yassin Jaffer yassinjaf...@gmail.com wrote: sorry I did not realize that your are booting from NFS, I had my own mmc driver. I guess you could use initramfs. I've not tried to boot from NFS before. On Thu, May 22, 2014 at 3:56 PM, Yassin Jaffer yassinjaf...@gmail.com wrote: setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait So part of the problem is boot args. I can fix the rootfs once the kernel starts booting. I got a little further... sun7i# setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait sun7i# bootm 0x4600 - 0x6000 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1846144 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 6000 Booting using the fdt blob at 0x6000 Loading Kernel Image ... OK Loading Device Tree to 4fff7000, end 4ddd ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. |�p ��x~ �x��~� That looks like the baud rate of early printk is not 115200. earlyprinktk runs before clocks get changed, so it will use whatever the bootloader configured. Since you do get u-boot output I think the problem lies somewhere else. Since earlyprintk is arch specific, does the kernel support sunxi earlyprintk? regards, Koen Once I can see what is going on, this feels to me like the kernel is not finding a machine name in the device tree that it likes. But I am using the cubietruck DT from that same kernel tree. On Thu, May 22, 2014 at 2:26 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: I can't get anywhere trying to boot a devel device tree kernel on Cubietruck. This is with https://github.com/jwrdegoede/linux-sunxi.git and the linux-devel branch. I don't get any boot output. I can boot a 3.4 kernel without problem. I followed these steps. http://linux-sunxi.org/Mainline_Kernel_Howto I also tried turning on low level printk but still no output U-Boot SPL 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Board: Cubietruck DRAM: 2048 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 sun7i# tftp 0x4900 /var/lib/tftpboot/ct.dtb dwmac.1c5 Waiting for PHY auto negotiation to complete done Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/ct.dtb'. Load address: 0x4900 Loading: ## 7.6 MiB/s done Bytes transferred = 24030 (5dde hex) sun7i# tftp 0x4600 /var/lib/tftpboot/uImage Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/uImage'. Load address: 0x4600 Loading: # # 12.3 MiB/s done Bytes transferred = 1837040 (1c07f0 hex) sun7i# env set fdt_high sun7i# sun7i# bootm 0x4600 - 0x4900 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1836976 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4900 Booting using the fdt blob at 0x4900 Loading Kernel Image ... OK Using Device Tree in place at 4900, end 49008ddd Starting kernel ... -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google
Re: [linux-sunxi] Booting devel device tree kernel on Cubietruck
On Thu, May 22, 2014 at 8:16 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 22 mei 2014, om 14:13 heeft jonsm...@gmail.com het volgende geschreven: On Thu, May 22, 2014 at 2:14 AM, Yassin Jaffer yassinjaf...@gmail.com wrote: sorry I did not realize that your are booting from NFS, I had my own mmc driver. I guess you could use initramfs. I've not tried to boot from NFS before. On Thu, May 22, 2014 at 3:56 PM, Yassin Jaffer yassinjaf...@gmail.com wrote: setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait So part of the problem is boot args. I can fix the rootfs once the kernel starts booting. I got a little further... sun7i# setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait sun7i# bootm 0x4600 - 0x6000 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1846144 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 6000 Booting using the fdt blob at 0x6000 Loading Kernel Image ... OK Loading Device Tree to 4fff7000, end 4ddd ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. |�p ��x~ �x��~� That looks like the baud rate of early printk is not 115200. earlyprinktk runs before clocks get changed, so it will use whatever the bootloader configured. Since you do get u-boot output I think the problem lies somewhere else. Since earlyprintk is arch specific, does the kernel support sunxi earlyprintk? It has option for Kernel low-level debugging messages via sunXi UART0. I am using that on an A20. regards, Koen Once I can see what is going on, this feels to me like the kernel is not finding a machine name in the device tree that it likes. But I am using the cubietruck DT from that same kernel tree. On Thu, May 22, 2014 at 2:26 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: I can't get anywhere trying to boot a devel device tree kernel on Cubietruck. This is with https://github.com/jwrdegoede/linux-sunxi.git and the linux-devel branch. I don't get any boot output. I can boot a 3.4 kernel without problem. I followed these steps. http://linux-sunxi.org/Mainline_Kernel_Howto I also tried turning on low level printk but still no output U-Boot SPL 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Board: Cubietruck DRAM: 2048 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 sun7i# tftp 0x4900 /var/lib/tftpboot/ct.dtb dwmac.1c5 Waiting for PHY auto negotiation to complete done Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/ct.dtb'. Load address: 0x4900 Loading: ## 7.6 MiB/s done Bytes transferred = 24030 (5dde hex) sun7i# tftp 0x4600 /var/lib/tftpboot/uImage Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/uImage'. Load address: 0x4600 Loading: # # 12.3 MiB/s done Bytes transferred = 1837040 (1c07f0 hex) sun7i# env set fdt_high sun7i# sun7i# bootm 0x4600 - 0x4900 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1836976 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4900 Booting using the fdt blob at 0x4900 Loading Kernel Image ... OK Using Device Tree in place at 4900, end 49008ddd Starting kernel ... -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit
Re: [linux-sunxi] Booting devel device tree kernel on Cubietruck
On Thu, May 22, 2014 at 8:19 AM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Thu, May 22, 2014 at 8:16 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 22 mei 2014, om 14:13 heeft jonsm...@gmail.com het volgende geschreven: On Thu, May 22, 2014 at 2:14 AM, Yassin Jaffer yassinjaf...@gmail.com wrote: sorry I did not realize that your are booting from NFS, I had my own mmc driver. I guess you could use initramfs. I've not tried to boot from NFS before. On Thu, May 22, 2014 at 3:56 PM, Yassin Jaffer yassinjaf...@gmail.com wrote: setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait So part of the problem is boot args. I can fix the rootfs once the kernel starts booting. I got a little further... sun7i# setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait sun7i# bootm 0x4600 - 0x6000 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1846144 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 6000 Booting using the fdt blob at 0x6000 Loading Kernel Image ... OK Loading Device Tree to 4fff7000, end 4ddd ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. |�p ��x~ �x��~� That looks like the baud rate of early printk is not 115200. earlyprinktk runs before clocks get changed, so it will use whatever the bootloader configured. Since you do get u-boot output I think the problem lies somewhere else. Since earlyprintk is arch specific, does the kernel support sunxi earlyprintk? It has option for Kernel low-level debugging messages via sunXi UART0. I am using that on an A20. I see that I also need to turn on early printk in the kernel. Now I am getting some output... So as soon as the real serial driver starts I am losing output. sun7i# bootm 0x4600 - 0x6000 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1846168 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 6000 Booting using the fdt blob at 0x6000 Loading Kernel Image ... OK Loading Device Tree to 4fff7000, end 4ddd ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.15.0-rc5-80186-gb9505da (jonsmirl@terra) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-11ubuntu1) ) #3 SMP Thu May 22 08:28:43 EDT 2014 [0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Cubietech Cubietruck [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 524288 [0.00] free_area_init_node: node 0, pgdat c0370940, node_mem_map ee7f9000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 2576 pages used for memmap [0.00] HighMem zone: 329728 pages, LIFO batch:31 [0.00] PERCPU: Embedded 5 pages/cpu @ee7cc000 s6592 r0 d13888 u32768 [0.00] pcpu-alloc: s6592 r0 d13888 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768 [0.00] Kernel command line: console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2076052K/2097152K available (2636K kernel code, 157K rwdata, 500K rodata, 190K init, 221K bss, 21100K reserved, 1318912K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] .text : 0xc0008000 - 0xc0318560 (3138 kB) [0.00] .init : 0xc0319000 - 0xc03489c0 ( 191 kB) [0.00] .data : 0xc034a000 - 0xc03714e0 ( 158
[linux-sunxi] [PATCH v9 0/2] Add support for the Allwinner A31 DMA Controller
Hi, This patchset adds support for the DMA controller found in the Allwinner A31 and A23 SoCs. This has been tested using the newly introduced SPI driver on an A31 EVK. Support for DMA-driven SPI transfers will be the subject of another patch serie. Thanks, Maxime Changes from v8: - Drop the select on DMA_OF - Depend on COMPILE_TEST to get more build tests coverage Changes from v7: - select DMA_OF, since we're only relying on DT - Properly kill the tasklet as suggested in https://lwn.net/Articles/588457/ - Split up the dt bindings documentation into a separate patch Changes from v6: - Dropped the merged patches and the clock patches that are pretty orthogonal to this driver Changes from v5: - Rebased on top of 3.15-rc1 Changes from v4: - Removed the packed attribute on the LLI - Switched to using a NULL device pointer in clk_get on PLL6 and AHB1 mux to make explicit that we are getting global clocks - Switched from spin_lock_irqsave to spin_lock in the interrupt handler - Various nitpicks from Andy Shevchenko: + Switched to using %p printk formats for pointers + Inverted some tests to lose a level of indentation + Dropped ifdef DEBUG protecting calls to dev_dbg Changes from v3: - A few other comments made by Andy Shevchenko were fixed: + Used references in %pa* printk formats + Used is_slave_direction in prep_slave_sg to make sure we were actually called for something, and to avoid making assumptions that we were actually called with the expected directions + A few others minor fixes: s/pr_err/dev_err/, etc. Changes from v2: - Removed the clk_put calls in the clock protection functions - Splitted out the sunxi machines into several files - Moved the clock protection code into these new machine files - Moved the PLL6 reparenting to the DMA driver - Addressed various comments from Andy Shevchenko: switched to using devm_kcalloc, used correct printk formats for physical and DMA addresses, etc. Changes from v1: - Removed the clk_put call in the clocks protecting patches - Minor fixes here and there as suggested by Andy Shevchenko: switch to dmam_pool_create, switch to dev_dbg instead of pr_debug, etc. Maxime Ripard (2): Documentation: dt: Add Allwinner A31 DMA controller bindings dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller .../devicetree/bindings/dma/sun6i-dma.txt | 45 + drivers/dma/Kconfig|8 + drivers/dma/Makefile |1 + drivers/dma/sun6i-dma.c| 1058 4 files changed, 1112 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/sun6i-dma.txt create mode 100644 drivers/dma/sun6i-dma.c -- 1.9.3 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Allwinner A31 max output resolution via HDMI
Hi, I wondered if anyone knows what's ther maximal output resolution the hdmi port of the allwinner A31? It has HDMI1.4 which is supposed to support 4k, but while I've seen some posts that talk about 2160p@30Hz (at the A31 wiki page for example) - most places talk about 1080p@60Hz. Thanks! -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] pinctrl: sunxi: fix pin numbers passed to register offset helpers
The pin numbers passed to sunxi_*_reg helpers to get the correct registers should be the pin offset for the PIO block, not the absolute number we use that is based on the alphanumeric labels Allwinner uses. This patch subtracts .pin_base from the pin number passed to these functions, so the driver accesses the correct registers. Signed-off-by: Chen-Yu Tsai w...@csie.org --- Hi, This patch fixes the pinctrl driver failing to set pinmuxes for the R_PIO block found on the A31 and A23. The problem was found while working on bringing up the A23 SoC. The R_UART pins weren't properly muxed when the bootloader didn't use them. A thank you to Boris who also verified the issue. Cheers, ChenYu --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index f6522b5..59962fa 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -280,6 +280,7 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev); struct sunxi_pinctrl_group *g = pctl-groups[group]; unsigned long flags; + unsigned pin = g-pin - pctl-desc-pin_base; u32 val, mask; u16 strength; u8 dlevel; @@ -303,23 +304,23 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, * 3: 40mA */ dlevel = strength / 10 - 1; - val = readl(pctl-membase + sunxi_dlevel_reg(g-pin)); - mask = DLEVEL_PINS_MASK sunxi_dlevel_offset(g-pin); + val = readl(pctl-membase + sunxi_dlevel_reg(pin)); + mask = DLEVEL_PINS_MASK sunxi_dlevel_offset(pin); writel((val ~mask) - | dlevel sunxi_dlevel_offset(g-pin), - pctl-membase + sunxi_dlevel_reg(g-pin)); + | dlevel sunxi_dlevel_offset(pin), + pctl-membase + sunxi_dlevel_reg(pin)); break; case PIN_CONFIG_BIAS_PULL_UP: - val = readl(pctl-membase + sunxi_pull_reg(g-pin)); - mask = PULL_PINS_MASK sunxi_pull_offset(g-pin); - writel((val ~mask) | 1 sunxi_pull_offset(g-pin), - pctl-membase + sunxi_pull_reg(g-pin)); + val = readl(pctl-membase + sunxi_pull_reg(pin)); + mask = PULL_PINS_MASK sunxi_pull_offset(pin); + writel((val ~mask) | 1 sunxi_pull_offset(pin), + pctl-membase + sunxi_pull_reg(pin)); break; case PIN_CONFIG_BIAS_PULL_DOWN: - val = readl(pctl-membase + sunxi_pull_reg(g-pin)); - mask = PULL_PINS_MASK sunxi_pull_offset(g-pin); - writel((val ~mask) | 2 sunxi_pull_offset(g-pin), - pctl-membase + sunxi_pull_reg(g-pin)); + val = readl(pctl-membase + sunxi_pull_reg(pin)); + mask = PULL_PINS_MASK sunxi_pull_offset(pin); + writel((val ~mask) | 2 sunxi_pull_offset(pin), + pctl-membase + sunxi_pull_reg(pin)); break; default: break; @@ -376,6 +377,7 @@ static void sunxi_pmx_set(struct pinctrl_dev *pctldev, spin_lock_irqsave(pctl-lock, flags); + pin -= pctl-desc-pin_base; val = readl(pctl-membase + sunxi_mux_reg(pin)); mask = MUX_PINS_MASK sunxi_mux_offset(pin); writel((val ~mask) | config sunxi_mux_offset(pin), -- 2.0.0.rc2 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: fix pin numbers passed to register offset helpers
Hello Chen-Yu, On 22/05/2014 17:20, Chen-Yu Tsai wrote: The pin numbers passed to sunxi_*_reg helpers to get the correct registers should be the pin offset for the PIO block, not the absolute number we use that is based on the alphanumeric labels Allwinner uses. This patch subtracts .pin_base from the pin number passed to these functions, so the driver accesses the correct registers. Thanks for fixing this bug. Signed-off-by: Chen-Yu Tsai w...@csie.org Reviewed-by: Boris Brezillon boris.brezil...@free-electrons.com --- Hi, This patch fixes the pinctrl driver failing to set pinmuxes for the R_PIO block found on the A31 and A23. The problem was found while working on bringing up the A23 SoC. The R_UART pins weren't properly muxed when the bootloader didn't use them. A thank you to Boris who also verified the issue. Cheers, ChenYu --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index f6522b5..59962fa 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -280,6 +280,7 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev); struct sunxi_pinctrl_group *g = pctl-groups[group]; unsigned long flags; + unsigned pin = g-pin - pctl-desc-pin_base; u32 val, mask; u16 strength; u8 dlevel; @@ -303,23 +304,23 @@ static int sunxi_pconf_group_set(struct pinctrl_dev *pctldev, * 3: 40mA */ dlevel = strength / 10 - 1; - val = readl(pctl-membase + sunxi_dlevel_reg(g-pin)); - mask = DLEVEL_PINS_MASK sunxi_dlevel_offset(g-pin); + val = readl(pctl-membase + sunxi_dlevel_reg(pin)); + mask = DLEVEL_PINS_MASK sunxi_dlevel_offset(pin); writel((val ~mask) - | dlevel sunxi_dlevel_offset(g-pin), - pctl-membase + sunxi_dlevel_reg(g-pin)); + | dlevel sunxi_dlevel_offset(pin), + pctl-membase + sunxi_dlevel_reg(pin)); break; case PIN_CONFIG_BIAS_PULL_UP: - val = readl(pctl-membase + sunxi_pull_reg(g-pin)); - mask = PULL_PINS_MASK sunxi_pull_offset(g-pin); - writel((val ~mask) | 1 sunxi_pull_offset(g-pin), - pctl-membase + sunxi_pull_reg(g-pin)); + val = readl(pctl-membase + sunxi_pull_reg(pin)); + mask = PULL_PINS_MASK sunxi_pull_offset(pin); + writel((val ~mask) | 1 sunxi_pull_offset(pin), + pctl-membase + sunxi_pull_reg(pin)); break; case PIN_CONFIG_BIAS_PULL_DOWN: - val = readl(pctl-membase + sunxi_pull_reg(g-pin)); - mask = PULL_PINS_MASK sunxi_pull_offset(g-pin); - writel((val ~mask) | 2 sunxi_pull_offset(g-pin), - pctl-membase + sunxi_pull_reg(g-pin)); + val = readl(pctl-membase + sunxi_pull_reg(pin)); + mask = PULL_PINS_MASK sunxi_pull_offset(pin); + writel((val ~mask) | 2 sunxi_pull_offset(pin), + pctl-membase + sunxi_pull_reg(pin)); break; default: break; @@ -376,6 +377,7 @@ static void sunxi_pmx_set(struct pinctrl_dev *pctldev, spin_lock_irqsave(pctl-lock, flags); + pin -= pctl-desc-pin_base; val = readl(pctl-membase + sunxi_mux_reg(pin)); mask = MUX_PINS_MASK sunxi_mux_offset(pin); writel((val ~mask) | config sunxi_mux_offset(pin), -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
On Wed, May 21, 2014 at 11:14 AM, Lee Jones lee.jo...@linaro.org wrote: This set of patches introduces the core driver and support for two different subsystems: - Regulators .../ABI/testing/sysfs-driver-input-axp-pek | 11 + Documentation/devicetree/bindings/mfd/axp20x.txt | 93 +++ .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/configs/multi_v7_defconfig| 3 + arch/arm/configs/sunxi_defconfig | 4 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile| 1 + drivers/input/misc/axp20x-pek.c| 281 + drivers/mfd/Kconfig| 12 + drivers/mfd/Makefile | 1 + drivers/mfd/axp20x.c | 258 +++ include/linux/mfd/axp20x.h | 180 + 12 files changed, 856 insertions(+) The regulator changes don't appear to be showing up in the diffstat or obviously in the series? Right. Cut-and-paste error. You have already applied the regulator patches so I didn't include them here (in theory I posted this series to be picked up by Lee). That's fine. Just tell me which patches need to stay together and which are able to be applied through their respective subsystem trees separately. Then, once I have all the Acks I can apply no problem. Hi Lee, I'd say #1 for the MFD tree, #4 for the input subsystem, #2 #3 and #5 are documentations, #6 and #7 defconfigs add-on. Thanks, -- Carlo Caione -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/6] wdt: sunxi: Move restart code to the watchdog driver
On Mon, May 19, 2014 at 05:04:22PM +0200, Maxime Ripard wrote: On Thu, May 15, 2014 at 11:11:23AM +0200, Maxime Ripard wrote: On Wed, May 07, 2014 at 02:33:18PM -0700, Guenter Roeck wrote: On Tue, May 06, 2014 at 09:44:19PM -0500, Maxime Ripard wrote: Most of the watchdog code is duplicated between the machine restart code and the watchdog driver. Add the restart hook to the watchdog driver, to be able to remove it from the machine code eventually. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Acked-by: Arnd Bergmann a...@arndb.de Reviewed-by: Guenter Roeck li...@roeck-us.net Wim, do you have any comment on this one? Ping? It would be really great to see this in 3.16, and we get quite close to the end of ARM's merge window. Ping? Guenter, since you seem to be the only responsive, may I suggest that you start merging patches and do a pull request to either Wim or Linus directly during the merge window? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 1/6] wdt: sunxi: Move restart code to the watchdog driver
On Thu, 22 May 2014 22:34:44 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, May 19, 2014 at 05:04:22PM +0200, Maxime Ripard wrote: On Thu, May 15, 2014 at 11:11:23AM +0200, Maxime Ripard wrote: On Wed, May 07, 2014 at 02:33:18PM -0700, Guenter Roeck wrote: On Tue, May 06, 2014 at 09:44:19PM -0500, Maxime Ripard wrote: Most of the watchdog code is duplicated between the machine restart code and the watchdog driver. Add the restart hook to the watchdog driver, to be able to remove it from the machine code eventually. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Acked-by: Arnd Bergmann a...@arndb.de Reviewed-by: Guenter Roeck li...@roeck-us.net Wim, do you have any comment on this one? Ping? It would be really great to see this in 3.16, and we get quite close to the end of ARM's merge window. Ping? Guenter, since you seem to be the only responsive, may I suggest that you start merging patches and do a pull request to either Wim or Linus directly during the merge window? I've yet to see anyone explain why this is an improvement over the current situation ? -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/6] wdt: sunxi: Move restart code to the watchdog driver
On Thu, May 22, 2014 at 09:39:43PM +0100, One Thousand Gnomes wrote: On Thu, 22 May 2014 22:34:44 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, May 19, 2014 at 05:04:22PM +0200, Maxime Ripard wrote: On Thu, May 15, 2014 at 11:11:23AM +0200, Maxime Ripard wrote: On Wed, May 07, 2014 at 02:33:18PM -0700, Guenter Roeck wrote: On Tue, May 06, 2014 at 09:44:19PM -0500, Maxime Ripard wrote: Most of the watchdog code is duplicated between the machine restart code and the watchdog driver. Add the restart hook to the watchdog driver, to be able to remove it from the machine code eventually. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Acked-by: Arnd Bergmann a...@arndb.de Reviewed-by: Guenter Roeck li...@roeck-us.net Wim, do you have any comment on this one? Ping? It would be really great to see this in 3.16, and we get quite close to the end of ARM's merge window. Ping? Guenter, since you seem to be the only responsive, may I suggest that you start merging patches and do a pull request to either Wim or Linus directly during the merge window? I've yet to see anyone explain why this is an improvement over the current situation ? This being ... ? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 1/6] wdt: sunxi: Move restart code to the watchdog driver
On Thu, May 22, 2014 at 10:34:44PM +0200, Maxime Ripard wrote: On Mon, May 19, 2014 at 05:04:22PM +0200, Maxime Ripard wrote: On Thu, May 15, 2014 at 11:11:23AM +0200, Maxime Ripard wrote: On Wed, May 07, 2014 at 02:33:18PM -0700, Guenter Roeck wrote: On Tue, May 06, 2014 at 09:44:19PM -0500, Maxime Ripard wrote: Most of the watchdog code is duplicated between the machine restart code and the watchdog driver. Add the restart hook to the watchdog driver, to be able to remove it from the machine code eventually. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Acked-by: Arnd Bergmann a...@arndb.de Reviewed-by: Guenter Roeck li...@roeck-us.net Wim, do you have any comment on this one? Ping? It would be really great to see this in 3.16, and we get quite close to the end of ARM's merge window. Ping? Guenter, since you seem to be the only responsive, may I suggest that you start merging patches and do a pull request to either Wim or Linus directly during the merge window? I had prepared a pull request for Wim last weekend or so, but then there were more patches piling in and I got distracted, so I didn't have time to actually send it. I'll try again this weekend ... the kids should be busy learning for their finals, and I'll have Friday and Monday off from work, so I should be able to find the time. As for sending patches to Linus directly, well, Wim is the watchdog maintainer. I manage to upset enough people, and would not want to add Wim to the list. The patches _are_ in my watchdog-next branch and get some coverage from both my auto-builders and from Fenguang's build robots, so while they are not in linux-next, they are not completely in the dark either. Guenter -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: fix pin numbers passed to register offset helpers
On Thu, May 22, 2014 at 5:20 PM, Chen-Yu Tsai w...@csie.org wrote: The pin numbers passed to sunxi_*_reg helpers to get the correct registers should be the pin offset for the PIO block, not the absolute number we use that is based on the alphanumeric labels Allwinner uses. This patch subtracts .pin_base from the pin number passed to these functions, so the driver accesses the correct registers. Signed-off-by: Chen-Yu Tsai w...@csie.org Maxime, can I have your ACK on this patch, too? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: gslx680 driver ported to sunxi
I have compiled the gslx680 driver, but there is a problem finding the firmware file (Error -2). Is there an standard location where the module will search for it? I'm using a 3.4 kernel, and the F20 image. Many thanks! Module loading dmesg excerpt following: [ 342.700742] ===gslx680_ts_init= [ 342.704643] _fetch_sysconfig_para. [ 342.708780] gslx680 firmware /lib/firmware/tablet.fw. [ 342.718037] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe [ 342.722046] _fetch_sysconfig_para: ctp_twi_id is 2. [ 342.726244] _fetch_sysconfig_para: screen_max_x = 800. [ 342.730476] _fetch_sysconfig_para: screen_max_y = 480. [ 342.734587] _fetch_sysconfig_para: revert_x_flag = 1. [ 342.738699] _fetch_sysconfig_para: revert_y_flag = 1. [ 342.743223] _fetch_sysconfig_para: exchange_x_y_flag = 1. [ 342.748665] _init_platform_resource: tp_io request gpio fail! [ 342.760743] i2c-core: driver [gslx680] using legacy suspend method [ 342.772884] i2c-core: driver [gslx680] using legacy resume method [ 342.781601] incomplete xfer (0x20) [ 342.786900] incomplete xfer (0x20) [ 342.793411] ctp_detect: Detected chip gslx680 at adapter 2, address 0x40 [ 342.797667] gslx680_ts_probe begin=. [ 342.801305] ==kzalloc success= [ 342.804136] [GSLX680] Enter gsl_ts_init_ts [ 342.808394] ctp_set_irq_mode: config gpio to int mode. [ 342.815161] ctp_set_irq_mode, 854: gpio_int_info, port = 8, port_num = 21. [ 342.817574] INTERRUPT CONFIG [ 342.825989] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c-2/2-0040/input/input1 [ 342.920231] =gsl_load_fw start== [ 404.034587] gslx680 2-0040: Unable to open firmware /lib/firmware/tablet.fw [ 404.045146] init_chip: gsl_load_fw fail: -2 [ 404.048717] gslx680 2-0040: init_chip failed [ 404.057737] gslx680: probe of 2-0040 failed with error -2 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
