-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need help with Device Tree #381
Comments
Read: |
I have tested three scenarios: Firmware boot without disable_commandline_tags Firmware boot with disable_commandline_tags=1 U-boot Am I doing something wrong in the Firmware boot case? I also tried setting config.txt: device_tree= to a nonextisting file, but no error message. Additional kernel config changes
Kernel source changes I got this error (using U-boot) before changing arch/arm/mach-bcm2708/bcm2708.c:
arch/arm/mach-bcm2708/bcm2708.c
arch/arm/boot/dts/bcm2708.dts
Fimware boot without disable_commandline_tags /boot/config.txt
Kernel messages
/proc/device-tree
Fimware boot with disable_commandline_tags=1 /boot/config.txt
Kernel messages
U-boot Built from git.denx.de/u-boot-arm.git
/proc/device-tree
|
You want these settings:
Do you have a uart attached? |
I'm going to interject a bit here: If you have a multi-platform enabled kernel, it will always panic because the machine ID passed in r1 is the 2708 machine ID. Multi-platform relies on the correct device tree being passed in r2 by the bootloader, thus the kernel expects the machine ID to be 0xFFFFFFFF if a specific arch hasn't been compiled in. For reference: http://lwn.net/Articles/496400/ (I think the 2835 mainline port has actually been converted to multi-platform, therefore won't boot unless you use U-boot) |
So would a config.txt option (e.g. linux_machine_id=0xffffffff) be useful (it will find it's way into r2 on kernel boot). |
I haven't been able to replicate what you did. Which kernel is the 'stock kernel' ? I have tested raspberrypi/linux:3.10.y and torvalds/linux. Image: 2013-09-10-wheezy-raspbian config.txt
Added to arch/arm/boot/dts/bcm2835-rpi-b.dts
Build
Copy: raspberrypi/linux 3.10.y
https://gist.github.com/notro/6687398 torvalds/linux
|
It would be useful in the long term for "generic" multiarch kernels to boot on the Pi. Basically a kernel compiled for an ARM1176 / ARMv6 processor (and had necessary device drivers built-in) would run on anything that provided it with a device tree with enough compatible devices. r1 needs to be 0xfffffff in these cases, indicating that the bootloader has passed through a devicetree describing the machine, rather than r1 being one of the set-in-stone machine IDs. In the short term, it would allow for building multiarch kernels with a pi-specific DTB appended to the kernel zImage. This is useful for getting the dtb correct in the first place before pushing it across to videocore which (in theory) can then magically determine if we are running on a model A / B / rev1 / rev2 and pass the necessary stuff across (ram size in particular). r2 still ends up as a pointer to ATAGS, but the kernel basically ignores ATAGS if a device tree tag is present. |
My kernel is from "sudo BRANCH=next rpi-update". I was just suggesting that the there is enough life in the kernel boot with the device tree config.txt options to get some debug infomation out (e.g. with printk through uart). If you can perhaps dump the raw binary device tree data when booting from uboot and when booting direct, we might see where the problem is. |
With a Device Tree enabled kernel and disable_commandline_tags=1 (and the other lines), I get nothing on the console after reset. Since not even config.txt
Relevant source code snippets
Sidenote: setup_machine_fdt()
setup_machine_tags()
|
If you have early_printk, then the first set of console messages will be printed to the serial console ONLY. Are you connected to the gpio uart? |
Yes, I have a serial console and CONFIG_EARLY_PRINTK=y. |
I used zImage instead of Image and that gave me
|
I was wrong in my assumption that start_kernel() wasn't called. I can see that the firmware alters the memory node from 256 to 512MB:
This is what the kernel receives and does:
Anything in particular I should look into ?
|
I have found a way to make zImage boot. U-boot sets the memory size to 0x1C000000 and the firmware sets it to 0x20000000. Here is a kernel output diff without forcing the size: |
By the way, this is zImage memory without DT
compared to U-boot with DT
|
Is the difference in 0x20000000 and 0x1c000000 due to the gpu_mem? Currenly I have: (with 512M part and 64M gpu_mem) "/memory/reg" to totalmemsize (e.g. 512M) Would you prefer I set this to: |
The only parameters I have in config.txt, is the DT related ones. So since the default gpu_mem is 64, I assume it is 64M. This is how U-boot determines ramsize: With regards to memreserve, it doesn't look like it is used (scripts/dtc/ is excluded):
This is the kernel function that reads the memory node: http://lxr.free-electrons.com/source/drivers/of/fdt.c?v=3.10;a=arm#L613 U-boot seem to honour it: http://lists.linaro.org/pipermail/linaro-kernel/2011-March/000161.html Does the firmware set memreserve today? I can't find it in /proc/device-tree/
Yes
Skip this one? |
#24 requested: so I am doing as requested by @lp0 I'll agree to change to your requested way at the weekend if no one shouts out that that is incorrect. |
I have another request. Some of these settings is needed to boot the 3.10.y kernel (I haven't tried to find out which). And this would make a FDT work correct on all boards with regards to bcm2708.boardrev for instance, and macaddr can't be hardcoded either. I don't know if any of the other parameters differ between boards. usual stuff
|
The mac address does come through device tree (as does serial/revision) But, yes, in theory I can send the "extended" command line through (just would be nice to know what is actually needed). |
/memory/reg is always the total memory Just because omitting the reserved memory from /memory/reg works too does not mean it is correct. |
I couldn't find any of those in /proc/device-tree
I extract the kernel config from the image in the rpi-firmware next branch and add DT support to that. |
bcm2835_defconfig will actually use device tree for the hardware, and will purely use upstream kernel code. |
Power.org™ Standard for Embedded Power Architecture™ Platform Requirements 3.4 Memory node 8.3 Memory Reservation Block
ePAPR states that multiple memory nodes/ranges can be used to describe the physical memory layout. driver/of/fdt.c seem to support that.
Yes, but I haven't found anything in the 3.10.y tree that uses memreserve. And if that is the case, all memory can't be put in the memory node. Please prove me wrong.
I agree with that, but I haven't found anything that proves it wrong. |
I want to deviate as little as possible from rpi-firmware. This way I benefit from the tesing of a lot of users. The upstream kernel code doesn't have that yet I believe. And I don't think the users of my kernel want to be part of that testing. So while in rpi patched kernel land, I would like all extra ATAGS arguments to be added. When 3.10.y becomes the standard, will the next branch start using Device Tree for the drivers that is already upstream? |
We will move the main firmware branch to 3.10 in a few weeks. |
The code that handles memserve on arm is arm_dt_memblock_reserve() in arch/arm/kernel/devtree.c called from arm_memblock_init() in arch/arm/mm/init.c I know this works, because when you don't reserve it, the framebuffer memory overlaps with some kernel memory early in the boot process and bad things happen. |
I don't see a real benefit to combining the original command line based parameters and device tree support. If you have device tree support enabled then it won't boot without it. All the configuration data should be there in device tree so you can trivially modify the existing drivers to use it. |
Thanks, I stand corrected. I added this to bcm2835-rpi-b.dts
And got this output
|
The point is, I don't want to spend a lot of time making all the drivers work with Device Tree. For the moment I only care about some framebuffer drivers and ads7846 (touch controller). Except that this doesn't look right
Not sure what you mean here.
For me it wouldn't be trivial, since I first looked into Device Tree a week ago, and all the kernel development I have done is writing some framebuffer drivers :-) It looks like I would have to patch 6 files/drivers to achieve that:
OK, it's not as bad as I thought. I'll give it a go.
|
One option is to get the dcw_otg driver working with bcm835 and the dwc2 can be considered in the future if it improves. |
You are correct. Namely that the missing resource is manpower - a port to the bcm2835 arch is possible (and desirable for a number of reasons) but there is plenty of work required to take the established 2708 port and move it "closer" to mainline. A good example is the dwc2 driver - Synopsys driver upstreamed by the vendor; it would make sense to publish further updates to that one rather than our current out-of-tree branch if it were in a state where the feature sets of both were comparable. |
I now have have a working BCM2835 with USB (dwc2) and networking (no DHCP) based on vanilla 3.12. Here's the patches I used: https://github.com/notro/rpi-build/tree/master/patches/bcm2835 This is the U-Boot script I used: https://github.com/notro/rpi-build/blob/master/bcm2835.py#L74 |
@notro sounds interesting. You say no DHCP - is that just something not enabled/tested, or is it not working with dwc2? |
Yes, of course. I failed in my attempt to do so: #393 Does dwc_oth depend on DMA or some other stuff that is not supported by BCM2835? |
Not enabled I would say. I tried to find the correct kernel config options, but gave up in the middle of NETFILTER and friends.
I have only tested that I can ping the outside world, and that it doesn't just die on me. I had it running over night.
It's easier to list what is present: There are some other patches floating around (mailbox and i2s at least), but I haven't looked into them. What is vchiq? |
There is mailbox code here: nomis/linux@917bdfc It needs to be updated for the new kernel interface. |
Hurray! It really works! And of course: I2S audio is working ;-) Are these patches already in the swarren repo or have you changed anything in the patches? |
Yes, I have just copied them. |
I have also added most of the patches from: https://github.com/hackerspace/rpi-linux/commits/lr-usb https://github.com/notro/rpi-build/tree/master/patches/bcm2835 Here's the boot log from that build: https://gist.github.com/notro/7475528
I will continue tomorrow going through the mailing list to see what's there. At least I2S I understand. Hopefully an updated mailbox driver as well. |
My version of the mailbox driver doesn't have this obscure idea of an "overflow" when reading from a mailbox. |
No DMA. I can't think of a reason for dwc_otg not to work on 2835.
Fast interrupt. A single interrupt can be designated as the FIQ, and a much faster/cheaper interrupt service routine is used. On Pi we designate the USB interrupt as the FIQ as it generates >8000 interrupts/second. You are probably better off disabling the FIQ initially (dwc_otg.fiq_fix_enable=0) in case that is causing a problem. |
i'm trying to get a kernel from the rpi-3.10.y branch to boot using device tree, and it appears to be locking up at either the semaphores, irq, or mailbox https://github.com/raspberrypi/linux/blob/rpi-3.10.y/arch/arm/mach-bcm2708/power.c#L101 the only other difference i can see, is that down() with atags leads to cpu_idle_loop and the irq am i right to assume that the semaphore isnt releasing the cpu and allowing the irq? |
Unpatched, or with my patches? From your references I assume you use ARCH_BCM2708 (bcmrpi_defconfig)? |
i only have the .dt_compat patch, i'll go over your other posts and look for more after supper if i don't have a reply by then using a slightly modified default config, which can boot when atags are enabled, and it has early_printk |
I have a solution to my original problem: How to load devices from Device Tree for some video drivers. The solution is a builtin module that can load a Device Tree from /lib/firmware. I went this route because of all the problems I faced getting full DT support. fdt_loader has to be builtin to get DT alias support, since of_alias_scan() is not exported. |
that sounds like it may be one way to solve the MPR121 issues i had the driver expects the element->keyboard mapping to be under platform_data, which currently must be compiled into a shim driver that simply says 'this hardware is present on the platform, here is the key mapping' basically, exactly what DT is meant to replace |
You can use i2c-bcm2835.c instead, which has DT support. This patch is probably relevant for your use case: http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-November/000744.html Or as I did with spi-bcm2708, add DT support to i2c-bcm2708 and use the fdt_loader argument: remove-pdevs=bcm2708_i2c.0 to remove the device added in arch/arm/mach-bcm2708/bcm2708.c |
In crc32c_vpmsum() we call enable_kernel_altivec() without first disabling preemption, which is not allowed: WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120 Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ... CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 #381 ... NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120 LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] Call Trace: 0xc138fd09 (unreliable) crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum] crypto_shash_update+0x88/0x1c0 crc32c+0x64/0x90 [libcrc32c] dm_bm_checksum+0x48/0x80 [dm_persistent_data] sb_check+0x84/0x120 [dm_thin_pool] dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data] dm_bm_read_lock+0x80/0xf0 [dm_persistent_data] __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool] dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool] pool_ctr+0x4cc/0xb60 [dm_thin_pool] dm_table_add_target+0x16c/0x3c0 table_load+0x184/0x400 ctl_ioctl+0x2f0/0x560 dm_ctl_ioctl+0x38/0x50 do_vfs_ioctl+0xd8/0x920 SyS_ioctl+0x68/0xc0 system_call+0x38/0xfc It used to be sufficient just to call pagefault_disable(), because that also disabled preemption. But the two were decoupled in commit 8222dbe ("sched/preempt, mm/fault: Decouple preemption from the page fault logic") in mid 2015. So add the missing preempt_disable/enable(). We should also call disable_kernel_fp(), although it does nothing by default, there is a debug switch to make it active and all enables should be paired with disables. Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c") Cc: [email protected] # v4.8+ Signed-off-by: Michael Ellerman <[email protected]>
commit 4749228 upstream. In crc32c_vpmsum() we call enable_kernel_altivec() without first disabling preemption, which is not allowed: WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120 Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ... CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 raspberrypi#381 ... NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120 LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] Call Trace: 0xc138fd09 (unreliable) crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum] crypto_shash_update+0x88/0x1c0 crc32c+0x64/0x90 [libcrc32c] dm_bm_checksum+0x48/0x80 [dm_persistent_data] sb_check+0x84/0x120 [dm_thin_pool] dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data] dm_bm_read_lock+0x80/0xf0 [dm_persistent_data] __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool] dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool] pool_ctr+0x4cc/0xb60 [dm_thin_pool] dm_table_add_target+0x16c/0x3c0 table_load+0x184/0x400 ctl_ioctl+0x2f0/0x560 dm_ctl_ioctl+0x38/0x50 do_vfs_ioctl+0xd8/0x920 SyS_ioctl+0x68/0xc0 system_call+0x38/0xfc It used to be sufficient just to call pagefault_disable(), because that also disabled preemption. But the two were decoupled in commit 8222dbe ("sched/preempt, mm/fault: Decouple preemption from the page fault logic") in mid 2015. So add the missing preempt_disable/enable(). We should also call disable_kernel_fp(), although it does nothing by default, there is a debug switch to make it active and all enables should be paired with disables. Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c") Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4749228 upstream. In crc32c_vpmsum() we call enable_kernel_altivec() without first disabling preemption, which is not allowed: WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120 Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ... CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 #381 ... NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120 LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] Call Trace: 0xc138fd09 (unreliable) crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum] crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum] crypto_shash_update+0x88/0x1c0 crc32c+0x64/0x90 [libcrc32c] dm_bm_checksum+0x48/0x80 [dm_persistent_data] sb_check+0x84/0x120 [dm_thin_pool] dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data] dm_bm_read_lock+0x80/0xf0 [dm_persistent_data] __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool] dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool] pool_ctr+0x4cc/0xb60 [dm_thin_pool] dm_table_add_target+0x16c/0x3c0 table_load+0x184/0x400 ctl_ioctl+0x2f0/0x560 dm_ctl_ioctl+0x38/0x50 do_vfs_ioctl+0xd8/0x920 SyS_ioctl+0x68/0xc0 system_call+0x38/0xfc It used to be sufficient just to call pagefault_disable(), because that also disabled preemption. But the two were decoupled in commit 8222dbe ("sched/preempt, mm/fault: Decouple preemption from the page fault logic") in mid 2015. So add the missing preempt_disable/enable(). We should also call disable_kernel_fp(), although it does nothing by default, there is a debug switch to make it active and all enables should be paired with disables. Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c") Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e18035c upstream. Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink implementation. The code is fine, but generates a lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.7.1mq+ #381 Tainted: G O -------------------------------------------- pulseaudio/4180 is trying to acquire lock: ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm] but task is already holding lock: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&group->lock); lock(&group->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by pulseaudio/4180: #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm] #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] [...] Cc: [email protected] Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking") Signed-off-by: Michał Mirosław <[email protected]> Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
commit e18035c upstream. Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink implementation. The code is fine, but generates a lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.7.1mq+ #381 Tainted: G O -------------------------------------------- pulseaudio/4180 is trying to acquire lock: ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm] but task is already holding lock: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&group->lock); lock(&group->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by pulseaudio/4180: #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm] #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] [...] Cc: [email protected] Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking") Signed-off-by: Michał Mirosław <[email protected]> Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
commit e18035c upstream. Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink implementation. The code is fine, but generates a lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.7.1mq+ #381 Tainted: G O -------------------------------------------- pulseaudio/4180 is trying to acquire lock: ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm] but task is already holding lock: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&group->lock); lock(&group->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by pulseaudio/4180: #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm] #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] [...] Cc: [email protected] Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking") Signed-off-by: Michał Mirosław <[email protected]> Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink implementation. The code is fine, but generates a lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.7.1mq+ raspberrypi#381 Tainted: G O -------------------------------------------- pulseaudio/4180 is trying to acquire lock: ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm] but task is already holding lock: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&group->lock); lock(&group->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by pulseaudio/4180: #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm] raspberrypi#1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm] [...] Cc: [email protected] Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking") Signed-off-by: Michał Mirosław <[email protected]> Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl Signed-off-by: Takashi Iwai <[email protected]>
…nslate the same key [ Upstream commit 5476fcf ] The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[raspberrypi#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[raspberrypi#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[raspberrypi#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…nslate the same key [ Upstream commit 5476fcf ] The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…isconnected See http://forum.stmlabs.com/showthread.php?tid=11053 firmware: gencmd: Add option to enable force_audio at runtime firmware: audioplus: Need to close/open a forced hdmi output when channels change bootcode: Updates to speed up bootocode sdcard accesses from gsh firmware: devtree: populate /axi/vc_mem/reg See: raspberrypi/linux#381 firmware: audio: Updates to support multichannel hdmi audio more accurately linux: bump to 3.10.17
I'm trying to get Device Tree working, but has failed in my attempts so far.
I have seen that it's reported working with U-boot, but I'm distributing my kernel with rpi-update, so I would like this to work without U-boot. Is it even possible?
I tried adding all config.txt parameters from https://github.com/raspberrypi/linux/wiki/How-to-boot-using-device-tree, but then it wouldn't boot. So I only use the device_tree* parameters.
I'm using the next firmware with the rpi-3.10.y branch from raspberrypi/linux and use the device tree test data.
Added to kernel config
bcm2708.dts
Compile device tree
Added to /boot/config.txt
Kernel boot messages
Nothing in proc
Why?
I want to use Device Tree to configure some framebuffer drivers I'm working on, not the base drivers.
Framebuffer drivers: https://github.com/notro/fbtft
rpi-update distributed kernel: https://github.com/notro/rpi-firmware
The text was updated successfully, but these errors were encountered: