Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On 06/07/2013 02:02 AM, luke.leighton wrote: On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: If companies are going to go off and invent the square wheel, and that makes *them* suffer the loss of being able to merge back into the mainline kernel, thereby making *their* job of moving forward with their kernel versions much harder, then yes, we *are* happy. russell: they have more employees than sense :) they also don't have any idea of what they *should* be doing, so this is an opportunity to educate them. You know, they're probably reading this thread, and if not, they certainly can in the list archives. It's probably not a good idea to slag them off like that, and like other comments in this thread... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b218bf.60...@wwwdotorg.org
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On 06/05/2013 02:46 PM, jonsm...@gmail.com wrote: On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton l...@lkcl.net mailto:l...@lkcl.net wrote: ... the detect line, which is the write-protect line, to setting the DRAM clock timings, saying which kernel driver must be loaded to support the touchscreen, enabling debugging, JTAG, naming the GPIOs for easy and convenient use in the kernel code: basically there isn't a single piece of hardware on the allwinner SoC family which *isn't* reconfigureable through script.fex... and they've even integrated it into u-boot *and* their low-level (early) bootloader as well [which Device tree support has been integrated into uboot for about five years now. There are two aspects to DT support in U-Boot: 1) Having U-Boot pass a DT to the kernel, possibly manipulating a few properties on the way, e.g. RAM size. As you say, this has been around a while. 2) Having U-Boot itself read a DT and configure itself, just like the kernel does. This is relatively new, and only supported by a few boards (all Tegra to some extent, and a couple each Samsung Exynos and Xilinx boards). I suspect/guess this is the kind of thing that Luke was referring to re: U-Boot fex integration. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51afa6dd.3000...@wwwdotorg.org
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On 06/05/2013 03:59 PM, Henrik Nordström wrote: ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: ... so the point is: if anyone wishes me to propose to allwinner that they convert over to devicetree, or any other proposal which involves significant low-level changes to their working practices that could potentially have a massive knock-on effect onto their multi-million-dollar clients, it had better be a damn good story. Calm down. It isn't really a significant difference to them outside of the kernel. They do not need to change any of their configuraiton methods, only a small toolchain change in how the resultig images are built to have a corresponding device tree built. If U-Boot needs to be parametrized, there are in theory a few options open: 1) Put all the parameters in the U-Boot configuration header. This is normal. 2) Read some data structure at run-time. This data structure could in theory be some SoC-specific blob format (e.g. the packed version of information that some tool extracts from FEX/DT), a whole FEX blob, or device tree. The U-Boot maintainers have already indicated that they won't accept the first two options; run-time configuration has to be via DT, and not via some SoC-specific mechanism. (As I found out to my detriment when I attempted to make U-Boot on Tegra determine which UART to use for debug at run-time by reading the configuration header that our boot ROM uses). Now of course, boot0/boot1 could always transform whatever data structure they wish into a DTB before passing that to U-Boot... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51afc19f.9040...@wwwdotorg.org
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
David Henningsson wrote at Thursday, February 23, 2012 1:31 AM: On 02/23/2012 01:01 AM, Andres Cimmarusti wrote: If the new two pins can be never used, i.e. physically unreachable, we may disable these pins by giving the proper default pin-config values. Usually it's a job of BIOS. But if BIOS doesn't do it, user need to do it manually. Build your kernel with CONFIG_SND_HDA_HWDEP=y, CONFIG_SND_HDA_RECONFIG=y, CONFIG_SND_HDA_PATCH_LOADER=y. I guess most of distro kernels are built with them. Then create a file containing below in /lib/firmware, such as, /lib/firmware/ibx-hdmi: [codec] 0x80862804 0x80860101 3 [pincfg] 0x04 0x41f0 0x06 0x41f0 Now pass this file to patch module option for snd-hda-intel. For example, create a file in /etc/modprobe.d/, e.g. /etc/modprobe.d/50-hdmi.conf, containing the line options snd-hda-intel patch=ibx-hdmi Then reload the driver or reboot. This will disable pins 0x04 and 0x06 so that only the pin 0x05 will be used. I've tested this workaround and it works well. I don't suppose this could be added as a quirk to the kernel for this particular device? (when and only if there's only one physically accessible HDMI connector). Stephen, could you comment on this? Are we guaranteed a certain board configuration (i e which pins are physically connected or not) given a PCI SSID, or anything else that can be used as a key to a quirk table? I think I've asked you before and that the answer was no, but my memory could be failing me. Any quirks would definitely have to include the PCI subsystem vendor ID and subsystem device ID to stand any chance of working; the main dev and vendor IDs certainly aren't enough. For NVIDIA GPUs, my expectation is that matching on all 4 IDs would often provide a unique key that determines which quirks to apply. However, the subsystem IDs are assigned by OEMs, and I have no idea whether they re- use the same IDs for different boards sometimes (I believe they shouldn't, but that doesn't necessarily mean anything). I assume the situation is identical for Intel graphics chips, but I can't really comment there at all! In summary: Our GPUs have a bunch of output port pins, and it's up to the individual board design which of those to use for which ports. There should be a 1:1 mapping between the 4-part PCI ID and the set of ports used and what for, but there's no way to guarantee that's true across all boards. Finally, if we did start quirking this, a complete table would end up being potentially enormous; an entry for every graphics board or mother- board with integrated graphics ever made... -- nvpublic
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
Andres Cimmarusti wrote at Tuesday, February 21, 2012 11:44 PM: ... Unfortunately with kernel 3.2.x and 3.1.x I get no sound out choosing the same configuration in pulseaudio. Device is advertised correctly but there's a bizarre multiplicity advertised: $ aplay -l List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 Using aplay with device 3 says device is busy. pulseaudio probably has that device open, hence aplay can't open it again. To validate this, run the following: pasuspender bash Then, run your aplay within that bash. At least aplay should run now, even if you still can't hear audio; it's possible you don't (or can't) have anything hooked up to that audio output Device 7 works correctly (but is not available in pulseaudio unless forced by default, which then renders internal speakers disabled) There are ways to configure pulseaudio to allow the user to select which PCM device to use on a given sound card. David Henningsson made this work for NVIDIA GPUs at least in Ubuntu, and I imagine the same technique could be applied to Intel devices too. In the meantime, the WAR that Takashi mentioned in his response sounds like it'd work very well, albeit it's a bit manual to set up. and device 8 produces no sound out. It's plausible that isn't connected, or is connected to a graphics port you simply don't have hooked up to a monitor or audio-capable monitor. As Takashi mentions, from a kernel perspective, this isn't really a regression at all, but simply exposing all the features of the HW that were previously hidden. Without that change, others can't use some HW usefully at all. Unfortunately, pulseaudio makes some rather simplistic assumptions about how HW works by default, and can be confused by the additional features that are exposed. Sorry this caused problems for you. -- nvpublic
Bug#660111: multiple, non-physically accesible, HDMI devices listed for Intel IbexPeak ALC269VB
Andres Cimmarusti wrote at Wednesday, February 22, 2012 5:02 PM: First of all, thank you for your feedback. It's been quite helpful / insightful ... There are ways to configure pulseaudio to allow the user to select which PCM device to use on a given sound card. David Henningsson made this work for NVIDIA GPUs at least in Ubuntu, and I imagine the same technique could be applied to Intel devices too. Mmm.. just in Ubuntu? was this work submitted upstream? It appears there are some related fixes shown in the Ubuntu pulseaudio changelog: I think the following Ubuntu bug covers the patch: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/716371 See the patch in comment #2. Hopefully David will chime in on upstreaming status etc. The following might be interesting; at least some of it will apply to non-NVIDIA graphics cards: ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html -- nvpublic
