Bug#711474: linux-image-3.9-1-amd64: backlight brightness on Dell XPS13 is no longer changeable
Package: src:linux Version: 3.9.4-1 Severity: normal Dear Maintainer, After upgrading to 3.9, I can't reliably set the backlight on my Dell XPS13 anymore. using i915.backlight=vendor doesn't work either. Using the patch listed at https://bugzilla.kernel.org/attachment.cgi?id=97751, bug https://bugzilla.kernel.org/show_bug.cgi?id=47941 comment 83, turns things back into a workable state. Please consider applying. I've rolled my own kernel with this patch for now. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Dell System XPS L322X product_version: chassis_vendor: Dell Inc. chassis_version: 0.1 bios_vendor: Dell Inc. bios_version: A08 board_vendor: Dell Inc. board_name: 0WW7PG board_version: A00 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) Subsystem: Dell Device [1028:058b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:058b] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 43 Region 0: Memory at d000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at c000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 2000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell Device [1028:058b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 40 Region 0: Memory at d050 (64-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: xhci_hcd 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Dell Device [1028:058b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 44 Region 0: Memory at d0515000 (64-bit, non-prefetchable) [size=16] Capabilities: access denied Kernel driver in use: mei_me 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Dell Device [1028:058b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at d051a000 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: Dell Device [1028:058b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 45 Region 0: Memory at d051 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: d040-d04f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1
Re: Updating Linux in wheezy
Adam D. Barratt a...@adam-barratt.org.uk (07/06/2013): It's tight, but Saturday would be within the window we announced so should okay from that perspective; it could be interesting if any regressions appear. As wheezy's linux package also produces the kernel udebs, we should really have the kernel included in the point release be the same as the kernel that the installer's built with. CCing Cyril and -boot for any comments on that side. I'm not sure how the pu-NEW freeze is implemented, but I'm not sure I'll be able to have everything ready on saturday; in any cases, I'll have to wait until the kernel is built everywhere before uploading src:debian-installer (unless we play with a few dep-waits). So if it's OK to have a late debian-installer upload, linux's being uploaded on saturday is fine with me. (Apologies for being late myself, etc.; but you already know about that part.) Mraw, KiBi. signature.asc Description: Digital signature
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com wrote: 4 days? WTF? since when did setting an ultimatum to the kernel community work? i was only informed of the opportunity 2 days ago, vladimir. this is an important meeting. of course the linux kernel community is entirely free to: * completely ignore this opportunity * continue to complain that soc vendors do not follow their unilaterally-decided rules * to continue to its chosen course of making unilateral decisions and setting unilaterally-decided rules and to experience the consequences. i'm extremely busy, vladimir, and i'm acting as the messenger here. 3 days remaining on the clock. l. -- 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/capweedwr_nwusi-j53m8muoav1rxm4wnnxtrioa2cjndyqe...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
luke.leighton wrote: On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com wrote: 4 days? WTF? since when did setting an ultimatum to the kernel community work? i was only informed of the opportunity 2 days ago, vladimir. this is an important meeting. of course the linux kernel community is entirely free to: * completely ignore this opportunity * continue to complain that soc vendors do not follow their unilaterally-decided rules SoC vendors are free to join the discussion, and many SoC vendors are part of the kernel community, so calling this unilateral is plain wrong. 3 days remaining on the clock. what catastrophic thing will happen when the time runs out? -- 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/51b19046.5040...@gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa tomasz.f...@gmail.com wrote: On Thursday 06 of June 2013 13:49:38 luke.leighton wrote: On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Luke, On Thursday 06 of June 2013 13:24:57 luke.leighton wrote: On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com wrote: I don't see any other solution here than moving all the Allwinner code to DT (as it has been suggested in this thread several times already), as this is the only hardware description method supported by ARM Linux. i repeat again: please state, explicitly and unequivocably that you - linux kernel developers - are happy that the reach of linux and gnu/linux OSes is dramatically reduced due to this intransigent position. or, tomasz, please state that you, tomasz, represent each and every one of the linux kernel developers so that i do not need to keep asking. I do not represent all linux kernel developers by any means. I am just stating current policy of SoC/board support maintained by ARM Linux, which is common for all Linux kernel devlopers, or at least ARM Linux kernel developers. Personally I am happy with numerous companies backing this policy and not making problems like this with Allwinner and I am really surprised that you are supporting a troublesome company like this. you've not read what i've written tomasz. I have. There are many other SoC vendors making low cost SoCs, like Rockchip, Boxchip, boxchip *is* allwinner. Right, sorry. I am not really into this low cost hardware. i've been tracking it for several years. There is also AMLogic, though. they're *definitely* GPL-violators. Telechips. Maybe they would be better candidates for being promoted as vendors of choice for hardware running free software? no, because they're not selling at a low-enough price with high-enough integration. telechips and rockchip don't have the market penetration. I do not have access to any numbers, so I am left to believe in what you say. well... none of us do :) that report (was it from IDC? it was in earlier messages) is a good analysis. (Although here in Poland the cheap tablet market is almost evenly divided between all those companies, you can find almost same amount of tablets based on SoCs from each vendor.) most likely. allwinner is the one that's actually expressed an interest, at Director (Board) Level, of being GPL-compliant. the software engineers understand that; their immediate Manager does not [and is causing considerable disruption]. AMLogic stone-walled and cost us money and a large client due to their GPL violations. which they till have not resolved [in over 2 years]. i will not work with them, ever again. Telechips are korean-based: they haven't responded to communications. Nufront got themselves in a muddle [late on silicon] so we ruled them out - we'll come back to them later. there's a number of others, but allwinner's the only one that is actively communicating. so. coming back to what you said earlier: i'm formulating what to say to allwinner [and need to pre-send something by monday so that they can consider it before the meeting]. so far, it consists of: * device-tree is what the linux kernel community has come up with, it is equivalent to FEX. * the linux kernel community would like to apologise for not consulting with you (allwinner) on the decision to only accept device tree [bear in mind that if this kind of thing isn't said, they risk just continuing to make the sunxi community's life absolute hell by continuing to work in isolation and continuing to duplicate drivers etc. etc. ] * work is being done by the free software community, they are beginning to integrate allwinner's work into the upstream kernel, and you (allwinner) will begin to see this when you get round to doing linux kernel 3.9 * allwinner and the linux and sunxi community therefore need to work closer together, we propose: * {insert proposals here} 3 days left on the clock. l. -- 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/CAPweEDx_1fvAv9sROtPreoyyj_yDAuYb040fM2zPc+tf22d=y...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
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. they're not feeling any pain: they just employ more chinese developers and substitute bodies for time and common-sense. also, in this particular case, thanks to their script.fex system when i said they only need to develop one kernel and one u-boot i really wasn't kidding around: they really have got to the point which everyone else dreams of with device-tree [admittedly by limiting the product range that their clients can play with, but that product range has huge returns, so they're still happy]. Companies will always do idiotic things; it's *them* and their users who have to live with the results of that bad decision making process. russell: the decision process they've made is actually an extremely effective one. Eventually, the pain of being outside the mainline kernel will become too great, especially if their users demand things like kernel upgrades from them. Eventually, they will change. And no, this isn't an intransigent position. This is reality given that ARM already has way too much code in the Linux kernel and we're trying to reduce that through the use of technologies like DT. The last thing we need right now is for another DT like implementation to come along which is only used on a minority of platforms - even if the platform it is used on is successful. The way this works is this: - you either go with the policies which are set, or which they weren't consulted on, it has to be pointed out. - you change the policy as a whole because you have a technically superior solution i believe they have a technically more *successful* solution. whether it's more appropriate in a wider context is another matter. here we have a key to the crux of the problem: the linux kernel maintainers have to cater for _everyone_. with no funding or incentive from the major contributors to work with them. hmmm What that means in this case is either you adopt DT, or you convince everyone that DT isn't the solution, but your solution is, and we adopt your solution for *everything* instead. If neither of those are possible, then that's really not our problem, and it's not _us_ who are being intransigent. indeed. ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? i cannot go to them and say you have to do this [insert proposal here] - it has to be more subtle than that. l. -- 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/CAPweEDyYt+pN+UaFuqWL5RrHpyuq_4So-tArmx3dr=0wls+...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic vlado...@gmail.com wrote: luke.leighton wrote: On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com wrote: 4 days? WTF? since when did setting an ultimatum to the kernel community work? i was only informed of the opportunity 2 days ago, vladimir. this is an important meeting. of course the linux kernel community is entirely free to: * completely ignore this opportunity * continue to complain that soc vendors do not follow their unilaterally-decided rules SoC vendors are free to join the discussion, and many SoC vendors are part of the kernel community, so calling this unilateral is plain wrong. you're free to believe that, vladimir. i've explained why that hasn't happened, in prior messages. can we move forward, please? 3 days remaining on the clock. what catastrophic thing will happen when the time runs out? no catastrophe, vladimir: all that happens is that an opportunity is lost, and the result of that is that the situation remains as it is, with a major soc vendor being divorced from and isolated from the free software community, who will continue to have to shoulder the frustrating and isolated burden of responsibility of reworking over-the-fence kernel patches as best they can with the limited resources that they have. -- 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/capweedxfwcv7hsduo6uc751iipg9ngdqc5ub7mbxwbespwf...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On 07/06/2013 10:06, luke.leighton wrote: On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic vlado...@gmail.com wrote: luke.leighton wrote: 3 days remaining on the clock. what catastrophic thing will happen when the time runs out? no catastrophe, vladimir: all that happens is that an opportunity is lost, and the result of that is that the situation remains as it is, with a major soc vendor being divorced from and isolated from the free software community, who will continue to have to shoulder the frustrating and isolated burden of responsibility of reworking over-the-fence kernel patches as best they can with the limited resources that they have. I think the question was: what will be done in 3 days that cannot be undone ? and you didn't answer that. I don't understand why your are still stating that Allwinner will never be able to get code in the mainline after Olof and Maxime told you that they are already working, at least discussing with them. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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/51b19769.4060...@free-electrons.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
luke.leighton wrote: so. coming back to what you said earlier: i'm formulating what to say to allwinner [and need to pre-send something by monday so that they can consider it before the meeting]. so far, it consists of: * device-tree is what the linux kernel community has come up with, it is equivalent to FEX. * the linux kernel community would like to apologise for not consulting with you (allwinner) on the decision to only accept device tree apologize? WTF? * allwinner and the linux and sunxi community therefore need to work closer together, we propose: * {insert proposals here} 1) switch to DT 2) there is no 2) 3 days left on the clock. tick tock -- 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/51b19c85.9090...@gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 09:02:43AM +0100, luke.leighton wrote: ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? i cannot go to them and say you have to do this [insert proposal here] - it has to be more subtle than that. It seems that you don't have to do anything at all. From what Arnd and others have said, they are _already_ talking to, and working with people in the kernel community to move their code base forward, move to DT, and they are already starting to send their own patches for the mainline kernel themselves. -- 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/20130607084913.gr18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 10:40:37AM +0200, Vladimir Pantelic wrote: luke.leighton wrote: so. coming back to what you said earlier: i'm formulating what to say to allwinner [and need to pre-send something by monday so that they can consider it before the meeting]. so far, it consists of: * device-tree is what the linux kernel community has come up with, it is equivalent to FEX. * the linux kernel community would like to apologise for not consulting with you (allwinner) on the decision to only accept device tree apologize? WTF? (I don't seem to have the original mail). Definitely not. The way this generally works is that discussions happen in public on mailing lists, and people who have an interest get involved in the discussion. If someone decides to avoid the mailing lists because they want to be secret about XYZ then they won't be part of the decision making process - but that's not _our_ problem. That is _their_ problem. In the case of DT, there was quite a lengthy discussion about it and its adoption. So, either the discussion took place _before_ there was any interest in the ARM kernel developments from Allwinner, or they themselves _chose_ not to be represented in the discussion by not being on the mailing list or participating in the discussion. There is nothing for us to apologise for here. (Occasionally, the kernel community *is* a dictatorship - for example, when Linus threatens to delete all the ARM defconfigs, or when Linus decides that we're running out of control when adding more than 10k lines of new code per kernel release, or - in the same way - when I see something I really don't like, but thankfully those are fairly rare.) -- 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/20130607090822.gs18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote: luke.leighton wrote: 3 days remaining on the clock. what catastrophic thing will happen when the time runs out? Maybe the world will explode into tiny small bits? Probably not. I suspect nothing of any relevance to us. As has already been pointed out, Allwinner is already working with people in the kernel community to move things forward, so the right things are already happening. -- 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/20130607091424.gt18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
2013/6/7 Olof Johansson o...@lixom.net: On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com wrote: augh. ok. solutions. what are the solutions here? Luke if you really want to fix this a good solution is to have Allwinner join Linaro and provide an engineer to the Linaro effort. That engineer will get educated on the right way to do kernel development and he can pass that knowledge back to Allwinner each day as he learns it. There's no need for anybody to join Linaro to contribute upstream. That's a crazy notion. i do agree. i don't think there is any direct relationship between linaro and upstream. otherwise, we will be in pain as we are not linaro member too. Listen, Allwinner isn't working in a vacuum, believe it or not. I've talked to them, so has Arnd and other people working on ARM, including Maxime Ripard, who's been reimplementing upstream support for their platform. Everybody is interested in the right things happening, it's just a matter of figuring out how to do it. The right people are already talking. Allwinner has expressed interest in the past in joining Linaro but the price was too high. I believe there are cheaper options now for joining. The benefits Allwinner receives from joining will far exceed the cost of joining. The net result will likely be a reduction in the amount they need to spend on in-house development since they will learn how to better leverage other developer's work. Uh, you're listing the benefits of doing upstream work, not of joining Linaro. -Olof thanks barry -- 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/CAGsJ_4wKgJTwZnJm7UEUVcNYLrWfWu1Gi0=09jqq1uxchj5...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
fre 2013-06-07 klockan 09:02 +0100 skrev luke.leighton: ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? Just tell them that the kernel is moving to a different configuration syntax called Device Tree, but apart from updating kernel drivers to the new way of configuring things it only have minor impact on their envionment. It is still possible to use the fex file for all board configuration details, only requires a small tool for translating fex to device tree. The change only impacts kernel, and a small change to their SDK build scripts to also build the device tree from the fex. It is no big deal really in structural terms. There is far bigger structural changes in the kernel which coincides with this and will require some developer time to adjust for. Had they upstreamed their changes earlier then... Regards Henrik -- 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/1370600817.9983.7.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Tomasz Figa tomasz.f...@gmail.com writes: Seeing from your posts you don't have any knowledge on how Linux kernel development works and even on how Allwinner's cooperation with our community looks (and seem to be completely closed to our effort of showing you the reality), so I'm not sure if you are the right person to take any of those roles... Try googling for Luke Leighton troll. The pattern is some lengthy semi-technical post, followed by very long threads with no substance whatsoever. It seems like some sick joke trying to waste as much time for as many people as possible. He's even become an -ENOPATCH example: http://linuxmafia.com/~rick/lexicon.html#enopatch Bjørn -- 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/87li6mxlcr@nemi.mork.no
Alquiler vacacional de apartamentos en Vera (Almería)
Buenos días: Tenemos disponibles para alquilar 14 casas adosadas y varios apartamentos Vera (Almería) en el entorno de Puerto Rey. Los alquila directamente la propiedad, sin intermediarios, y desde 250 euros la semana. Si quiere que le mandemos todos los detalles puede contactar con nosotros en vera_alqui...@hhxx.es Un saludo GSX Servicios SL
Processed: your mail
Processing commands for cont...@bugs.debian.org: reassign #711526 linux-image-3.2.0-4-amd64 3.2.41-2+deb7u2 Bug #711526 [3.2.41-2+deb7u2] mmc0: Timeout waiting for hardware interrupt. Warning: Unknown package '3.2.41-2+deb7u2' Bug reassigned from package '3.2.41-2+deb7u2' to 'linux-image-3.2.0-4-amd64'. No longer marked as found in versions linux-image-3.2.0-4-amd64. Ignoring request to alter fixed versions of bug #711526 to the same values previously set Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware interrupt. Marked as found in versions linux/3.2.41-2+deb7u2. End of message, stopping processing here. Please contact me if you need assistance. -- 711526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711526 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13706125431136.transcr...@bugs.debian.org
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:52:43AM +0100, luke.leighton wrote: coming back to what you said earlier: i'm formulating what to say to allwinner [and need to pre-send something by monday so that they can consider it before the meeting]. so far, it consists of: * device-tree is what the linux kernel community has come up with, it is equivalent to FEX. From what I have seem looking at FEX, devicetree is vastly more powerful and scalable than FEX. It is also a standard (IEEE1275) that has been around for many years (given devicetree is using part of openfirmware). * the linux kernel community would like to apologise for not consulting with you (allwinner) on the decision to only accept device tree I would consider that an enourmous lie. Devicetree was around long before their company had ever started doing the allwinner. It might not have been used in ARM yet, but it was used in a number of other architectures, making it the obvious choice for doing the same thing on more architectures. [bear in mind that if this kind of thing isn't said, they risk just continuing to make the sunxi community's life absolute hell by continuing to work in isolation and continuing to duplicate drivers etc. etc. ] That is their problem (and their customers). * work is being done by the free software community, they are beginning to integrate allwinner's work into the upstream kernel, and you (allwinner) will begin to see this when you get round to doing linux kernel 3.9 If something is popular enough, people will work on getting it supported, where supported means done properly. * allwinner and the linux and sunxi community therefore need to work closer together, we propose: * {insert proposals here} How about allwinner simply tries to help with the activity already taking place for getting everything working with devicetree. That probably means doing work to their tools to generate devicetree files from their FEX files, if they really like FEX (and think their customers like FEX). 3 days left on the clock. Who cares what your deadline is. That's not how good choices are made. -- Len Sorensen -- 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/20130607143014.gb11...@csclub.uwaterloo.ca
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
SoC vendors are free to join the discussion, and many SoC vendors are part of the kernel community, so calling this unilateral is plain wrong. you're free to believe that, vladimir. i've explained why that hasn't happened, in prior messages. can we move forward, please? I prefer it if the vladimir troll (and fellow trolls) make requests for one of us to make or do something instead of constantly whining and wasting time. After all we are attached to funds and resources ready to deploy if something sounds a good idea and gets a vote. To vladimir - please put your thoughts in a blog where it belongs. If its important, I'm sure others would offer comment and take you up on your thoughts.
Processed: Re: Bug#711526: mmc0: Timeout waiting for hardware interrupt.
Processing control commands: reassign -1 linux-image-3.2.0-4-amd64 Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware interrupt. Ignoring request to reassign bug #711526 to the same package found -1 3.2.41-2+deb7u2 Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware interrupt. Ignoring request to alter found versions of bug #711526 to the same values previously set -- 711526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711526 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b711526.137062387621380.transcr...@bugs.debian.org
Bug#711526: mmc0: Timeout waiting for hardware interrupt.
Control: reassign -1 linux-image-3.2.0-4-amd64 Control: found -1 3.2.41-2+deb7u2 On Vi, 07 iun 13, 14:57:49, pepelopez wrote: Package: 3.2.41-2+deb7u2 Version: linux-image-3.2.0-4-amd64 Dear pepelopez, You mixed up the package name with the version, which is why: 1. your report was filled against 'unknown-package' 2. it misses information that may be very useful for the Maintainers I'm taking care of 1., but kindly run reportbug linux-image-3.2.0-4-amd64 and send the generated information as a follow-up for this bug (number 711526). Kind regards, Andrei -- Looking after bugs filled against unknown packages signature.asc Description: Digital signature
Bug#711539: [src:linux] No sound on headphones with snd_hda_intel (working on 3.8)
Package: src:linux Version: linux-image-3.9-1-amd64 Severity: normal --- Please enter the report below this line. --- When booting with 3.9 I get no sound on headphones (it works through speakers). It also doesn't work with 3.10-rc4 from experimental. It works with 3.2 and 3.8. Please let me know if you need more information, I'll be glad to provide it. --- System information. --- Architecture: amd64 Kernel: Linux 3.9-1-amd64 Debian Release: jessie/sid 700 testing security.debian.org 700 testing cdn.debian.net 600 unstablecdn.debian.net 500 stable repository.spotify.com 500 stable dl.google.com 500 raring ppa.launchpad.net 500 oneiric ppa.launchpad.net 1 testing www.deb-multimedia.org 1 experimentalcdn.debian.net --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
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
Bug#711526: mmc0: Timeout waiting for hardware interrupt.
Package: src:linux Version: 3.2.41-2+deb7u2 Followup-For: Bug #711526 Card reader not work. 0b:06.0 CardBus bridge: O2 Micro, Inc. OZ711SP1 Memory CardBus Controller (rev 01) 0b:06.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 02) 0b:06.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01) [ 1346.564443] mmc0: new SDHC card at address cc87 [ 1346.628822] mmcblk0: mmc0:cc87 SU04G 3.79 GiB (ro) [ 1346.630721] mmcblk0: p1 p2 [ 1356.672118] mmc0: Timeout waiting for hardware interrupt. [ 1356.672176] [ cut here ] [ 1356.672235] WARNING: at /build/buildd- linux_3.2.41-2+deb7u2-amd64-NHQI9B/linux-3.2.41/drivers/mmc/host/sdhci.c:959 sdhci_send_command+0x2f/0x7db [sdhci]() [ 1356.672247] Hardware name: TravelMate 5520 [ 1356.672253] Modules linked in: mmc_block act_police sch_ingress cls_u32 sch_sfq sch_cbq sha256_generic cryptd aes_x86_64 aes_generic cbc tun ndiswrapper(O) pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep parport_pc ppdev rfcomm bluetooth lp parport cpufreq_stats cpufreq_conservative cpufreq_userspace cpufreq_powersave binfmt_misc uinput fuse iptable_nat nf_nat iptable_mangle ipt_LOG xt_limit xt_tcpudp ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_multiport iptable_filter ip_tables x_tables ext2 dm_crypt snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi snd_hda_codec_realtek fglrx(P) joydev snd_hda_intel snd_hda_codec acer_wmi snd_hwdep snd_pcm sparse_keymap snd_page_alloc pcmcia snd_seq rfkill snd_seq_device snd_timer snd sp5100_tco yenta_socket pcmcia_rsrc pcmcia_core edac_mce_amd i2c_piix4 powernow_k8 soundcore edac_core psmouse i2c_core battery mperf ac power_supply serio_raw evdev pcspkr k8temp video processor button wmi ext4 crc16 jbd2 mbcache dm_mod microcode sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hid sdhci_pci sdhci mmc_core pata_atiixp ahci libahci libata ohci_hcd thermal thermal_sys ehci_hcd scsi_mod sky2 usbcore usb_common [last unloaded: scsi_wait_scan] [ 1356.672521] Pid: 10, comm: ksoftirqd/1 Tainted: P O 3.2.0-4-amd64 #1 Debian 3.2.41-2+deb7u2 [ 1356.672530] Call Trace: [ 1356.672548] [81046a55] ? warn_slowpath_common+0x78/0x8c [ 1356.672570] [a0012d48] ? sdhci_send_command+0x2f/0x7db [sdhci] [ 1356.672592] [a00136ce] ? sdhci_finish_data+0x1da/0x1f7 [sdhci] [ 1356.672612] [a0013750] ? sdhci_timeout_timer+0x65/0xa0 [sdhci] [ 1356.672624] [81052208] ? run_timer_softirq+0x19a/0x261 [ 1356.672643] [a00136eb] ? sdhci_finish_data+0x1f7/0x1f7 [sdhci] [ 1356.672656] [8104c094] ? __do_softirq+0xb9/0x177 [ 1356.672666] [8104c1cc] ? run_ksoftirqd+0x7a/0x118 [ 1356.672675] [8104c152] ? __do_softirq+0x177/0x177 [ 1356.672688] [8105f329] ? kthread+0x76/0x7e [ 1356.672701] [81354b34] ? kernel_thread_helper+0x4/0x10 [ 1356.672712] [8105f2b3] ? kthread_worker_fn+0x139/0x139 [ 1356.672722] [81354b30] ? gs_change+0x13/0x13 [ 1356.672729] ---[ end trace 782d14030959d823 ]--- -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.41-2+deb7u2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/internal-system ro quiet ** Tainted: PWO (4609) * Proprietary module has been loaded. * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: [11861.677107] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7773 PROTO=UDP SPT=137 DPT=137 LEN=58 [11862.727799] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7804 PROTO=UDP SPT=137 DPT=137 LEN=58 [11863.479142] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7819 PROTO=UDP SPT=137 DPT=137 LEN=58 [11864.229150] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7828 PROTO=UDP SPT=137 DPT=137 LEN=58 [11876.537856] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8316 PROTO=UDP SPT=137 DPT=137 LEN=58 [11877.287347] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8317 PROTO=UDP SPT=137 DPT=137 LEN=58 [11878.040721] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8318 PROTO=UDP SPT=137 DPT=137 LEN=58 [11888.827193] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8344 PROTO=UDP
Bug#649748: linux-2.6: fixes upstream packaging when cross-compiling
reassign 649748 src:linux thanks On Wed, Nov 23, 2011 at 08:18:16PM -0600, Jonathan Nieder wrote: found 649748 linux-2.6/2.6.39-3 tags 649748 + upstream quit Hi Hector, Hector Oron wrote: Do you think is sane to send this patch to upstream? Yep, sounds like the sane thing to do. Based on MAINTAINERS (ok, I already knew, but let's pretend for a moment), the mailing list to write to is linux-kbu...@vger.kernel.org (no subscription needed, and the convention is to always reply-to-all there). From git log scripts/package/builddeb, I see that the people to cc are maximilian attems m...@stro.at and Asbjoern Sloth Toennesen asbj...@asbjorn.biz to get comments on the first version of a patch and Michal Marek mma...@suse.cz once the final version is ready. Administrivia: kernel hackers tend to prefer to review diffs produced with the -p / --show-c-function option. Patches should include a sign-off --- see the Developer's Certificate of Origin 1.1 in Documentation/SubmittingPatches for details on that. Hector, this hasn't landed in current kernel.org git, did you submit it upstream? Cheers, Moritz -- 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/20130607174908.ga21...@inutil.org
Processed: Re: linux-2.6: fixes upstream packaging when cross-compiling
Processing commands for cont...@bugs.debian.org: reassign 649748 src:linux Bug #649748 [linux-2.6] linux-2.6: fixes upstream packaging when cross-compiling Bug reassigned from package 'linux-2.6' to 'src:linux'. No longer marked as found in versions linux-2.6/2.6.39-3. Ignoring request to alter fixed versions of bug #649748 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 649748: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649748 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.137062744313093.transcr...@bugs.debian.org
Bug#600031: marked as done (updating kernel causes slow write speed to raid)
Your message dated Fri, 7 Jun 2013 19:49:13 +0200 with message-id 20130607174913.gb21...@inutil.org and subject line Re: updating kernel causes slow write speed to raid has caused the Debian Bug report #600031, regarding updating kernel causes slow write speed to raid to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 600031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600031 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image Version: 2.6.32-5-686 After dist-upgrade from Lenny to Squeeze write speed is halved. Shown with bonnie++. Before upgrade write speed was 21MB/s, after upgrade 10MB/s. Hardware: Dell Powervault 745n with hardware raid Adaptec 2610SA. Celeron(R) CPU 2.40GHz, 512MiB RAM. Confirmed link to kernel with: otherserver$ scp 4gbfile raid_server: 100% 4000MB 6.6MB/s 10:06 reboot server with kernel 2.6.26-2-686 leftover from Lenny. otherserver$ scp 4gbfile raid_server: 100% 4000MB 11.3MB/s 05:55 Also of note that when copying a large file the system becomes heavily loaded. iowait: 80.1%wa load average: 3.58, 1.48, 0.66 Mem:514428k total, 508276k used, 6152k free,10084k buffers ---End Message--- ---BeginMessage--- Version: 2.6.36-1 On Thu, Oct 14, 2010 at 03:16:36PM +0100, Dave Clarke wrote: Ben That has solved it. Now getting around 27MB/s write on ext4 and 97MB/s read with the experimental kernel. I'm happy with these speeds on this hardware. It is still a little slower then with windows but I can live with that. Marking 2.6.36 as fixed. Cheers, Moritz---End Message---
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 9:18 AM, Alexandre Belloni alexandre.bell...@free-electrons.com wrote: On 07/06/2013 10:06, luke.leighton wrote: On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic vlado...@gmail.com wrote: luke.leighton wrote: 3 days remaining on the clock. what catastrophic thing will happen when the time runs out? no catastrophe, vladimir: all that happens is that an opportunity is lost, and the result of that is that the situation remains as it is, with a major soc vendor being divorced from and isolated from the free software community, who will continue to have to shoulder the frustrating and isolated burden of responsibility of reworking over-the-fence kernel patches as best they can with the limited resources that they have. I think the question was: what will be done in 3 days that cannot be undone ? and you didn't answer that. apologies for not being clear. there is nothing that cannot be undone. i trust that that answers the specific question you've asked. let me try to put it into undo words. this is about me (a messenger) offering you plural (the linux kernel community) an opportunity to undo the mess-that-is-perceived-to-be-the-case wrt one specific SoC vendor, named Allwinner. let me try to put it another way. i cannot specifically state EXACTLY what will be done, because i do not have authorisation to make that publicly known. i am trying hard to hint at what can be done, and the deadline is monday 10th june 2013 to get a clear proposal in which will make its way to allwinner, by means that i cannot specifically tell you about because i do not have the specific authorisation or permission to tell you. does that point you in the right direction? can we please get on with taking advantage of this opportunity and discuss options that can be presented, instead of asking these kinds of questions? I don't understand why your are still stating that Allwinner will never be able to get code in the mainline i didn't say that. apologies if that wasn't clear. after Olof and Maxime told you that they are already working, at least discussing with them. apologies, i missed that. there's a lot i need to get up-to-speed, in very little time. i have some keywords to search for now i'll go find those messages. l. -- 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/CAPweEDy3hCvusHvWMBki0ak=se51rtu-1wyid3hawoqut8w...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
thomas i _very_ briefly spotted this when i was extremely busy yesterday, and i'm grateful to the 2 or 3 people who've given me the keywords and/or links to catch up. On Thu, Jun 6, 2013 at 10:27 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Dear Tomasz Figa, On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote: I don't see any other solution here than moving all the Allwinner code to DT (as it has been suggested in this thread several times already), as this is the only hardware description method supported by ARM Linux. Have you noticed that it is already the case in mainline? i knew there was a little bit, but not the extent of the commits. My colleague Maxime Ripard (Cc'ed) maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. is the maintainer of the mainline Allwinner sunxi effort. It already supports a number of boards, has a pinctrl driver, a GPIO driver, serial port is working, network is working, I2C is working. All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing git pulls? and which boards. bear in mind that one of those boards should really be the total range of products available across hundreds of chinese tablet clone manufacturers. specific question: is one of the boards the one that tom cubie submitted, which covers virtually every android tablet product manufactured in the millions by chinese tablet clone manufacturers? So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? l. -- 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/CAPweEDzW60poOYahm31aW3_A=nvzmybpppgm9pzdvupjnju...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 02:49:28PM +, joem wrote: SoC vendors are free to join the discussion, and many SoC vendors are part of the kernel community, so calling this unilateral is plain wrong. you're free to believe that, vladimir. i've explained why that hasn't happened, in prior messages. can we move forward, please? I prefer it if the vladimir troll (and fellow trolls) make requests for one of us to make or do something instead of constantly whining and wasting time. After all we are attached to funds and resources ready to deploy if something sounds a good idea and gets a vote. To vladimir - please put your thoughts in a blog where it belongs. If its important, I'm sure others would offer comment and take you up on your thoughts. I think your position is confused. Everything that Vladimir (in his three posts) in this thread so far have been correct. Vladimir is not the one doing any trolling in this thread. Vladimir has not requested anything. He hasn't whined. He hasn't wasted time. He has stated the following in _three_ short succinct emails: (a) no one gets to impose stipulate timescales unless they're willing to financially sponsor the work. (b) the adopted position of the Linux kernel developers. Luke Leighton on the other hand is demanding that we (Linux kernel developers) come up with proposals within three days so that Luke can act as a middle man between us and Allwinner, and is blaming the Linux kernel community for the situation with Allwinner. As you seem to have your facts wrong, I can only conclude that you are also trolling... I hope I'm wrong about that and you've just made an innocent mistake. -- 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/20130607182608.gv18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Luke, I want only one thing from you at this time. See below. On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton luke.leigh...@gmail.com wrote: but the Directors of Allwinner aren't been kept in the loop, here: that's my job, to get them up-to-speed. The one job I would love for you to do instead of all this trolling and time-wasting that's being done by _everybody_ involved, is to just extract yourself from the situation and let us go on with our work. You're causing nothing but confusion and extra work. Literally. You represent nobody that matters in this discussion. By demanding us to spend time and effort bringing you personally up to speed on a subject that both we (ARM kernel community) and them (Allwinner) are already having discussions about, it's nothing but a distraction and waste of energy. And yes, Allwinner knows about this public email thread. Thanks. -Olof -- 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/caoesgmg+xk5yy2w3n__qyekrxb5fp6eruowvzpnhkovhf2+...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hello, On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote: Have you noticed that it is already the case in mainline? i knew there was a little bit, but not the extent of the commits. Then you could probably use a bit of your time to read the kernel commit logs rather than writing hundreds of e-mails, no? My colleague Maxime Ripard (Cc'ed) maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. Maxime will reply to this in more details, but I believe the status is: * Interrupt controller is working. * Clock drivers are working. * Pinctrl is working. * GPIO is working. * Timer is working. * UART is working * Watchdog is on its way (patches posted) * Ethernet is on its way (patches posted) * I2C is on its way (patches posted) Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13) are supported. See arch/arm/boot/dts/sun{4,5}i* for a good overview. All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing git pulls? The very first support landed in 3.8. So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. You really believe you're more important than you really are, I'd say. My colleague Maxime is in contact with Allwinner, he has regular discussion with them, started reviewing some of the kernel code they're writing, has received datasheets from them, and evaluation boards. So this work is definitely not done in isolation from Allwinner, and they have received much more than an heads-up from Maxime. The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? So far, A10 and A13. Maxime has received a A31 evaluation board from Allwinner very recently, and also A10S and A20 boards. I suppose he will be working on those fairly and posting the corresponding patches fairly soon. In other words, it looks like you've started an entire discussion about the mainline support for Allwinner SoCs without having a look at what git log tells you... Which by itself is a very good indicator that you're probably not the best interlocutor for Allwinner as far as mainline development is concerned. Best regards, Thomas Petazzoni -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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/20130607205940.4816fed5@skate
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 5:00 PM, Olof Johansson o...@lixom.net wrote: On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com wrote: augh. ok. solutions. what are the solutions here? Luke if you really want to fix this a good solution is to have Allwinner join Linaro and provide an engineer to the Linaro effort. That engineer will get educated on the right way to do kernel development and he can pass that knowledge back to Allwinner each day as he learns it. There's no need for anybody to join Linaro to contribute upstream. That's a crazy notion. indeed. this is a company that produced a 70-page datasheet when freescale produced 4,500 for the iMX6. i passed on that link and i believe it'll be an eye-opener to their engineers: education is what's key here, and you don't need to pay vast sums to do it. although the quantities they're selling are just ennorrrmous, allowing them to undercut absolutely everybody because they can pay absolute best rates to the Fab Houses (TSMC etc.) their profit margins are going to be exceptionally slim. so we cannot count on them having a spare $1m per year to give to linaro, so yes, i tend to agree with what you're implying, olof, that allwinner should be encouraged to participate more in upstream contribution. so. could someone please describe to me what they should do, here? whom should they best contact, what lists, what's the procedures, where's the best-working-practices, where are the foundations with which they can participate that have the formal procedures for proposals [similar to python's PEP and debian's DEP]. that last was a not-very-subtle hint, btw. and... please... i've yet to receive *any* answers to the question and what are the benefits that they would get by doing so!! Listen, Allwinner isn't working in a vacuum, believe it or not. I've talked to them, so has Arnd and other people working on ARM, including Maxime Ripard, who's been reimplementing upstream support for their platform. great. Everybody is interested in the right things happening, it's just a matter of figuring out how to do it. The right people are already talking. but the Directors of Allwinner aren't been kept in the loop, here: that's my job, to get them up-to-speed. the cost of joining. The net result will likely be a reduction in the amount they need to spend on in-house development since they will learn how to better leverage other developer's work. but you forget one thing: they only need *ever* produce *one* board/kernel. they have a registered board type, it covers *all* products and i mean *all* products. i don't mean that in the usual way where most companies re-use a single machine type for multiple devices and irritate the crap out of linux kernel developers when the GPL source finally leaks, i mean thanks to script.fex they LITERALLY only ever compile one binary and then customise script.fex on a per-customer basis. so the usual lessons really do not apply, here. the only one i spotted was that they rather foolishly made duplicates of sun5i_usb and renamed all the files (s/SUN5I/SUN7I/g) to make sun7i_usb, then started editing. one of the developers created a buffer overflow, which corrupted internal memory, and there are signs that he then started experimenting switching off DMA trying to fix various problems. if he'd done a proper job #ifdef CONFIG_SUN7I_USB #ifdef CONFIG_SUN5I_USB in the same source code etc etc. and tested on known-good [older] hardware he would have noticed that the modifications failed on previously-known-good hardware and would have spotted the buffer overflow error much sooner. that _is_ something i will be bringing to the Director's attention, that the strategy of cut-paste-itis has detrimental effects. ok. so. apologies, bit of a digression there. question for you olof [and others of course]: you've clearly listed some benefits, which i'm very very grateful for. in light of what i describe above [the we only need ever write one kernel strategy which is serving Allwinner really really well apart from the code-duplication mistake], do the benefits you list *still* apply, and if so, could you please elaborate for me, assume i'm thick or something [or at least not a programmer, which i am unfortunately so might miss something] l. -- 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/capweedwu+rztcgb20uh7jxazjbrx_yhva4sy_atr7mwpbb4...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 6:28 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: I should also add that Allwinner not only talked to us already, oo! great! can you please [privately, not publicly] let me know who that is, so i can let the Directors know, so that they can follow up? but also expressed interest in doing actual modern kernel development (like using recently introduced kernel frameworks, like the clk framework). awesome. I've received patches from them already for private reviews, they began to show up on the kernel mailing lists, they asked to be CCed on the patches I send upstream, they're even the one that reached out to me when the early support for their chips was released. So, like Olof said, they aren't in a vacuum, they are very aware of the mainline kernel and speak a decent english. good! next thing you know they'll be writing comments in english too [*1] So yes, Allwinner has an evil vendor tree (c), with a solution similar yet inferior (because not generic enough) to the device tree, but they show interest on going down the mainline road. yes. i'm coming at this from the other end, via the top management, so that this is properly coordinated. so. reminder. and question. what needs to be done, and what are the benefits? l. [*1] http://git.rhombus-tech.net/?p=linux.git;a=blob;f=drivers/usb/sun7i_usb/manager/usb_manager.c;h=3775c83134efee9694789b68e85010ebc0d9938b;hb=refs/heads/lkcl-3.3-a20#l274 -- 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/CAPweEDyg11k++gunqVQkbwi_-MvhexAX6Z_kjM=3rfbi7qn...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 9:22 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 06 June 2013, Maxime Ripard wrote: So yes, Allwinner has an evil vendor tree (c), with a solution similar yet inferior (because not generic enough) to the device tree, but they show interest on going down the mainline road. Right, and of course there is nothing special about that, everybody starts out with they own even vendor tree (c), and as hardware support gets merged upstream, the diff gets smaller, even though the code in the mainline kernel is normally very different from what they started out with. *sigh* except if that idiot manager [whom we're keenly aware of] orders them to delete absolutely everything (find . -name '*sunxi*' | xargs git rm) and overwrite it with their internally-managed tree, causing absolute mayhem in the process... Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may end up being the first modern one that is fully supported upstream including a GPU driver, since it is one of the obvious targets for the reverse-engineering efforts. yes. http://libv.livejournal.com/24735.html Ironically (given NVIDIA's reputation), the Tegra platform is the strongest competitor I see in that race at the moment. at $7.50 for a dual-core processor, and i am *not* going to tell you the quad-core price, i don't believe it can be considered to be a race, or even a competition. they're *OUT*, man. really. oh wait - did you mean for 1st to have fully supported upstream GPU driver? that would be veery nice. For all I can tell, things are progressing nicely, given that it's currently a volunteer effort. If anyone needs things to move faster, I'd recommend them to send money to free-electrons.com. i'll put that on the list of recommendations, but - again - i need a list of clear benefits and returns as to why that should happen. l. -- 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/CAPweEDyfrA9z55Yqt8jC8j=e=g_gah_fa0xrolxexajwqxn...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Luke Leighton on the other hand is demanding that we no demands have been made, russell: i've informed you of an immovable deadline which will pass beyond which the opportunity being presented is lost. (Linux kernel developers) come up with proposals within three days so that Luke can act is *going* to act, regardless of how well people deal with the time limitations and my own communication limitations as a middle man between us and Allwinner, and is not ... blaming the Linux kernel community for the situation with Allwinner. As you seem to have your facts wrong, I can only conclude that you are also trolling... I hope I'm wrong about that and you've just made an innocent mistake. please continue to assume that i am making mistakes [under time pressure]: you'd be right. i never understand this word troll and i haven't got time to discuss its meaning. greatly appreciated efforts to correct my misunderstandings and mistakes so that i'm properly prepared - ready or not - for the meeting ahead. l. -- 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/capweedxxnrwyk4ghskn-pzm1hlozpid1mune1q-4ft6pjrj...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Seeing from your posts you don't have any knowledge on how Linux kernel development works check back to 2004. and even on how Allwinner's cooperation with our community looks (and seem to be completely closed to our effort of showing you the reality), no - just f*g busy, tomasz so I'm not sure if you are the right person to take any of those roles... well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. i may not be the best person but i am in the right place at the right time, and nobody else is going to be able to step into this role in time. so i may not be the best person that you *think* i am, but i'm the person you've got. time's ticking. can we get on please? I'd suggest Maxime Ripard or someone else from Free Electrons to be responsible for communication with Allwinner instead. you're welcome to suggest, however they do not have the contacts that i have (many of which are indirect anyway), and i am not going to introduce him to them either, in case they jeapordise the critical business relationships that took my associates 4 years to establish. l. -- 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/CAPweEDwmgr2JbH+txDDjR_gDA2R2C1v=auvcuvts7rrimhz...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson o...@lixom.net wrote: Luke, I want only one thing from you at this time. See below. On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton luke.leigh...@gmail.com wrote: but the Directors of Allwinner aren't been kept in the loop, here: that's my job, to get them up-to-speed. The one job I would love for you to do instead of all this trolling and time-wasting that's being done by _everybody_ involved, is to just extract yourself from the situation and let us go on with our work. You're causing nothing but confusion and extra work. Literally. You represent nobody that matters in this discussion. absolutely correct. i am nobody, who is in the right place at the right time. i'm just a messenger. so - what message do you wish to take to the Directors of Allwinner (if any). By demanding a-a-ah, no demands made. us to spend time and effort bringing you personally up to speed on a subject that both we (ARM kernel community) and them (Allwinner) are already having discussions about, it's nothing but a distraction and waste of energy. And yes, Allwinner knows about this public email thread that's good! -- 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/CAPweEDzeyJh+DKX=8tzrt9ang9nqlp8nwkwfmb2wy+jnbkq...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:57 PM, Wookey woo...@wookware.org wrote: OK, this sounds good. Could you say who the allwinner engineers are? [cross-over: i asked him if he'd be happy to let me know privately, so i have at least some context when speaking to the Directors] I guess it's quite a large organisation, so if Crazy Luke can say 'the work of mainline integration using device-tree is already being done by $these $people, please talk to them to help move it along', that might help get everyone on the same page. *mull*, *mull*... yes exactly! If it's like many large organisations, some bits of it will 'get it' and see why, in the long term, mainline integration is worthwhile, but other bits will look at what they have now and their android focus, and decide it's easier to keep doing what they are doing. There is a lot of hardware using these socs, and I'd love to be able to use that with mainstream stuff, rather than random vendor piles, and specific android kernels, so anything we can do to help make that happen is good. So yes, Allwinner has an evil vendor tree (c), with a solution similar yet inferior (because not generic enough) to the device tree, but they show interest on going down the mainline road. So, luke: mainline is not going to support fex directly, whatever you or allwinner do. The advantages to allwinner of working with mainline are: 1) Ability to use whatever (kernel supported) hardware they like with new designs, with no driver work 2) Ability to use latest kernels and thus whatever shiny goodies those include 3) No need to do fex-ready drivers for new hardware 4) No need to keep backporting new kernels to add fex integration forevermore hooray - thank you wookey, this is exactly what i need. cut/paste, straight into the report. If they want to keep existing tools and fex workflow then a fex-DT translation tool will be needed. in-kernel or external tool? (It's not clear to me to what degree DT can simply be used instead directly) TBD. input here, anyone? -- 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/CAPweEDw3_M_5e_B2HueCNcfXjO9_4_oiCJuEfTERetyoOx=+v...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Hello, On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote: Have you noticed that it is already the case in mainline? i knew there was a little bit, but not the extent of the commits. Then you could probably use a bit of your time to read the kernel commit logs rather than writing hundreds of e-mails, no? not now, thomas. i need summaries. bear in mind i type faster than i can read/find. very very grateful for your summaries, it's exactly what i need. My colleague Maxime Ripard (Cc'ed) maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. Maxime will reply to this in more details, but I believe the status is: * Interrupt controller is working. * Clock drivers are working. * Pinctrl is working. * GPIO is working. * Timer is working. * UART is working * Watchdog is on its way (patches posted) * Ethernet is on its way (patches posted) * I2C is on its way (patches posted) Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13) are supported. See arch/arm/boot/dts/sun{4,5}i* for a good overview. All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing git pulls? The very first support landed in 3.8. So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. You really believe you're more important than you really are, I'd say. no, i don't. i'm just a messenger. under-informed one, at the moment. please bear that in mind rather than saying you seem dreadfully underinformed - i got caught off-guard by this opportunity and need to get up-to-speed rather fast. My colleague Maxime is in contact with Allwinner, he has regular discussion with them, started reviewing some of the kernel code they're writing, has received datasheets from them, and evaluation boards. _great_. that's brilliant to hear. So this work is definitely not done in isolation from Allwinner, and they have received much more than an heads-up from Maxime. The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? So far, A10 and A13. Maxime has received a A31 evaluation board from Allwinner very recently, and also A10S and A20 boards. I suppose he will be working on those fairly and posting the corresponding patches fairly soon. great. you've got the A20 3.3 kernel source drop? http://git.rhombus-tech.net/?p=linux.git;a=tree;h=refs/heads/lkcl-3.3-a20;hb=refs/heads/lkcl-3.3-a20 In other words, it looks like you've started an entire discussion about the mainline support for Allwinner SoCs without having a look at what git log tells you... absolutely correct. dived into this the moment i got word of a potential meeting on extremely short notice, having had zero time to review the logs prior even to then. Which by itself is a very good indicator that you're probably not the best interlocutor for Allwinner as far as mainline development is concerned. the meeting's going ahead, regardless of your concerns. please help get me up to speed, for the benefit of the linux community. take advantage of the opportunity, please: take it at face value without judgement. l. -- 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/CAPweEDzaWBYEOpDNCkxGyHzewTAVgD6v=jjm-t46uw_jypb...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote: On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Luke Leighton on the other hand is demanding that we no demands have been made, russell: i've informed you of an immovable deadline which will pass beyond which the opportunity being presented is lost. [...] Would that be the opportunity for you to pose as an intermediary between the Linux community and Allwinner, which you failed to realise was a completely redundant position? If not, please explain what you are actually hoping to do, and why anyone should care. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20130607193104.ge4...@decadent.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Friday 07 of June 2013 20:02:03 luke.leighton wrote: On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Seeing from your posts you don't have any knowledge on how Linux kernel development works check back to 2004. $ git log --oneline --author=Luke Kenneth Casson Leighton | wc -l 0 $ git log --oneline --author=l...@lkcl.net | wc -l 0 $ git log --oneline --author=Luke Leighton | wc -l 0 That's an -ENOPATCH for me. and even on how Allwinner's cooperation with our community looks (and seem to be completely closed to our effort of showing you the reality), no - just f*g busy, tomasz Just like many of us, I guess. so I'm not sure if you are the right person to take any of those roles... well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. i may not be the best person but i am in the right place at the right time, and nobody else is going to be able to step into this role in time. so i may not be the best person that you *think* i am, but i'm the person you've got. time's ticking. can we get on please? I'd suggest Maxime Ripard or someone else from Free Electrons to be responsible for communication with Allwinner instead. you're welcome to suggest, however they do not have the contacts that i have (many of which are indirect anyway), and i am not going to introduce him to them either, in case they jeapordise the critical business relationships that took my associates 4 years to establish. Well, I'm quitting this discussion right now, as it doesn't seem to be of any use or might be even counter-productive. I have already showed my view on this matter (and even given you some proposals for them), got it confirmed by several other people and got nothing from you that could make me reconsider anything. Thank you for your time. Best regards, Tomasz -- 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/1506423.MBs7Fu8QWI@flatron
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
+++ Maxime Ripard [2013-06-06 19:28 +0200]: Hi everyone, On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote: Listen, Allwinner isn't working in a vacuum, believe it or not. I've talked to them, so has Arnd and other people working on ARM, including Maxime Ripard, who's been reimplementing upstream support for their platform. Everybody is interested in the right things happening, it's just a matter of figuring out how to do it. The right people are already talking. I should also add that Allwinner not only talked to us already, but also expressed interest in doing actual modern kernel development (like using recently introduced kernel frameworks, like the clk framework). I've received patches from them already for private reviews, they began to show up on the kernel mailing lists, they asked to be CCed on the patches I send upstream, they're even the one that reached out to me when the early support for their chips was released. So, like Olof said, they aren't in a vacuum, they are very aware of the mainline kernel and speak a decent english. OK, this sounds good. Could you say who the allwinner engineers are? I guess it's quite a large organisation, so if Crazy Luke can say 'the work of mainline integration using device-tree is already being done by $these $people, please talk to them to help move it along', that might help get everyone on the same page. If it's like many large organisations, some bits of it will 'get it' and see why, in the long term, mainline integration is worthwhile, but other bits will look at what they have now and their android focus, and decide it's easier to keep doing what they are doing. There is a lot of hardware using these socs, and I'd love to be able to use that with mainstream stuff, rather than random vendor piles, and specific android kernels, so anything we can do to help make that happen is good. So yes, Allwinner has an evil vendor tree (c), with a solution similar yet inferior (because not generic enough) to the device tree, but they show interest on going down the mainline road. So, luke: mainline is not going to support fex directly, whatever you or allwinner do. The advantages to allwinner of working with mainline are: 1) Ability to use whatever (kernel supported) hardware they like with new designs, with no driver work 2) Ability to use latest kernels and thus whatever shiny goodies those include 3) No need to do fex-ready drivers for new hardware 4) No need to keep backporting new kernels to add fex integration forevermore If they want to keep existing tools and fex workflow then a fex-DT translation tool will be needed. (It's not clear to me to what degree DT can simply be used instead directly) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20130607185724.gz14...@stoneboat.aleph1.co.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote: On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson o...@lixom.net wrote: By demanding a-a-ah, no demands made. well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. That is a demand. Stop trolling. -- 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/20130607193120.gx18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote: well, tough. get me up to speed, *fast*. No, not unless you're willing to *pay* someone to spend time teaching you, because you are asking to be *taught* about the current situation, so you're asking someone to do some _work_ _for_ _you_. If you're not willing to do that, then all the information is out there in the public domain for you to learn from yourself. please stop wasting time like this: Pot. Black. -- 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/20130607193014.gw18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote: On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Luke Leighton on the other hand is demanding that we no demands have been made, russell: i've informed you of an immovable deadline which will pass beyond which the opportunity being presented is lost. well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. That is a demand. On the other hand this would not be: Can someone please get me up to speed on this? That is a request. Sorry, you've just lost some more credibility. Please let those who are already working with Allwinner continue to work with them rather than spending time needlessly with someone who clearly doesn't have any idea about what they say even from one moment to the next. -- 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/20130607193532.gy18...@n2100.arm.linux.org.uk
RE: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Confused yes - innocent mistake - 50% yes. I see now the posts are cc'd from arm-netbook mailing lists to many other mailing lists with different standards for noise. Apologies for not seeing that. arm-netbook list 'belongs' to luke, but generally the noise level is very low here and its aim is to make EOMA 68 and other similar gadgets. So it is not fair on anybody here to be flooded like this with blog quality post. If anyone got open source things that need building, or things that need doing, by all means send a one or two line request. So stop squabbling, become more productive by sticking to one or two line responses. I'm sure everyone can do that. And if you have time, here are projects to take inspiration from when it comes making gadgets: http://rhombus-tech.net/ Projects that have sprung up around Luke's project: http://www.iuac.res.in/~elab/phoenix/SBC/ https://github.com/slapin/a13board http://www.gplsquared.com/SoM2/SoM2.html http://www.gplsquared.com/mk802/mk802.html As you seem to have your facts wrong, I can only conclude that you are also trolling... I hope I'm wrong about that and you've just made an innocent mistake. -- 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/6DBBEE2DB8B23047A3F38C3520340CDFCCC116@fh-ex1
Bug#649748: linux-2.6: fixes upstream packaging when cross-compiling
Hello, 2013/6/7 Moritz Muehlenhoff j...@inutil.org: Hector, this hasn't landed in current kernel.org git, did you submit it upstream? No, I did not submit it upstream, also it seems to be incomplete, and it misses armhf architecture. Please, allow me few days to work on it and re-submit updated patch to Debian and upstream. Thanks for the heads-up Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- 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/CAODfWeEXHzxCx-6W8GE-QaCo=UGjgpuw54wrm6hbhr_h...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
right - too many people contributed to this, input from jon smirl, wookie, maxime, tomasz, henrik, i've made a start here and will continue editing: this is notes for me to put forward an agenda for discussion: http://hands.com/~lkcl/allwinner_linux_proposal.txt i'm setting a rule that each section *has* to have a list of clear benefits, otherwise it'll have to be removed before it goes on to their Directors. so - even if there are any allwinner engineers reading this who would like something put forward please also speak up! :) l. -- 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/capweedxg4zpidvhten+pegbsfmzpkqj-iy3x0vbgj7ib7pt...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 8:35 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote: On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Luke Leighton on the other hand is demanding that we no demands have been made, russell: i've informed you of an immovable deadline which will pass beyond which the opportunity being presented is lost. well, tough. get me up to speed, *fast*. please stop wasting time like this: get me up to speed. That is a demand. On the other hand this would not be: Can someone please get me up to speed on this? That is a request. thank you for the correction. can someone please get me up to speed on this? i've collated peoples very gratefully received responses so far, here: http://hands.com/~lkcl/allwinner_linux_proposal.txt Please let those who are already working with Allwinner continue to work with them rather than spending time needlessly with someone who clearly doesn't have any idea about what they say even from one moment to the next. 1) correct: i don't. i've been caught off-guard by this: it's very short notice, and i have limited time available. i'm doing the best i can to correct mistakes as i go along, but i *don't have time* to observe the niceties, dot all the i's or cross all the t's. 2) that appears to be a request to a large audience. i have to point out to that audience: end result of complying with the request above will be that the free software community suffers as a result of losing the opportunity to speak to - and therefore influence - the Directors of one of the world's most successful, fastest growing [and also very young and inexperienced] SoC fabless semiconductor company. please make your own choice. l. -- 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/capweedyosjxep9wx0vat3xdhgot7ky-kuq7c8-cxpuoce+n...@mail.gmail.com
IPQ Module
Hello all; I tested 3.2.0-4 kernel on Debian 7.0 Wheezy operating system. Debian Wheezy being used 3.2.0-4 kernel. # uname -ar Linux snort.test.lan 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux kernel version I understand; the new kernel version no used ip_queue module, right? I run Snort IPQ mode and error: -- ipq DAQ configured to inline. ERROR: Can't initialize DAQ ipq (-1) - ipq_daq_initialize: ipq_create_handle error Unable to create netlink socket Fatal Error, Quitting.. -- I tested NFQ mode Snort his way to work and worked. I think; new kernel not use IPQ module. # modprobe ip_queue ERROR: could not insert 'ip_queue': Device or resource busy # insmod ip_queue Error: could not load module ip_queue: No such file or directory # insmod /lib/modules/3.2.0-4-amd64/kernel/net/ipv4/netfilter/ip_queue.ko Error: could not insert module /lib/modules/3.2.0-4-amd64/kernel/net/ipv4/netfilter/ip_queue.ko: Device or resource busy and syslog message: Jun 8 02:21:54 snort kernel: [ 3382.028421] ip_queue: failed to register queue handler Jun 8 02:27:35 snort kernel: [ 3722.151772] ip_queue: failed to register queue handler Jun 8 02:27:52 snort kernel: [ 3739.115550] ip_queue: failed to register queue handler I want to share this information with you. Best Regards Ozgur Karatas
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Maxime will reply to this in more details, but I believe the status is: * Interrupt controller is working. * Clock drivers are working. * Pinctrl is working. * GPIO is working. * Timer is working. * UART is working * Watchdog is on its way (patches posted) * Ethernet is on its way (patches posted) * I2C is on its way (patches posted) ok so i've got this now in http://hands.com/~lkcl/allwinner_linux_proposal.txt - that leaves... well there's quite a bit: usb, sd/mmc (both variants: they changed the data structures around sun5i), nand (probably both - the allwinner one and the mtd one being done, reminds me: we need full documentation on the NAND chip), scsi, g2d - cedarx and more. what else should be raised, and to what benefit? -- 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/capweedxtc+oamcpveq3bulbn88hsjzkoi0fknlbadzd04lq...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 8:30 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote: well, tough. get me up to speed, *fast*. No, not unless you're willing to *pay* someone to spend time teaching you, there's not enough time. 2 days left. because you are asking to be *taught* about the current situation, so you're asking someone to do some _work_ _for_ . for the benefit of free software, russell. for the benefit of free software. for the BENEFIT of free software. _you_. NO. -- 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/capweedxmtnpfbapiacpig0g3zhvmwljpopdz6tbd-fn5hkd...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote: maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. You mean something like http://linux-sunxi.org/Linux_mainlining_effort ? You should really do a bit of research before starting a thread like this one. This webpage has been around for like 9 monthes now on the wiki of a community you pretend to represent (even though I fail to get how you can pretend such thing, but that's another topic). is the maintainer of the mainline Allwinner sunxi effort. It already supports a number of boards, has a pinctrl driver, a GPIO driver, serial port is working, network is working, I2C is working. All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing git pulls? 3.8, as shown in the wiki page and which boards. bear in mind that one of those boards should really be the total range of products available across hundreds of chinese tablet clone manufacturers. specific question: is one of the boards the one that tom cubie submitted, which covers virtually every android tablet product manufactured in the millions by chinese tablet clone manufacturers? Again, wiki. So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? A10, A13 for the moment. I just received hardware with A10s, A20 and A31 that I need to work on, but support should come quite soon. I already have some patches pending to be tested on an A31 board, but didn't have as much time as I wanted lately to actually set a proper environment to test them. Maxime -- 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/20130607220853.GR14209@lukather
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote: maxime: we need to talk :) please tell me in 4 or 5 sentences what you've managed to do so far, expanding a little on what thomas says below, more specifically what it achieves and/or allows rather than technically what it does (suitable for managers and directors in other words), and what plans you'd like to see happen. You mean something like http://linux-sunxi.org/Linux_mainlining_effort ? ahh, fantastic. with references too. magic. exactly what i need. thank you. listed now at http://hands.com/~lkcl/allwinner_linux_proposal.txt You should really do a bit of research before starting a thread like this one. then that gives you some idea of how busy i've been and still am, to not be aware even of things like this, to have kicked a project off some 18-24 months ago and not be able to keep up with one of the many branches and initiatives that it's spawned. when i said i've been caught off-guard by this opportunity i meant exactly what i said. This webpage has been around for like 9 monthes now on the wiki of a community you pretend to represent i pretend no such thing and apologise for giving any impression of such. (even though I fail to get how you can pretend such thing, but that's another topic). i have a different focus: a meta-project of sorts, where allwinner happened to be the first. look up rhombus-tech and EOMA68 and it'll become a bit clearer. is the maintainer of the mainline Allwinner sunxi effort. It already supports a number of boards, has a pinctrl driver, a GPIO driver, serial port is working, network is working, I2C is working. All in mainline, completely Device Tree based. great. which version did it first hit, i.e. what will the first signs of this be when allwinner begin doing git pulls? 3.8, as shown in the wiki page got that. and which boards. bear in mind that one of those boards should really be the total range of products available across hundreds of chinese tablet clone manufacturers. specific question: is one of the boards the one that tom cubie submitted, which covers virtually every android tablet product manufactured in the millions by chinese tablet clone manufacturers? Again, wiki. yep, am there now. So isn't this entire discussion completely moot? no because it's totally in isolation from allwinner. i need to give them a heads-up, and get them involved, giving them specific incentives [which nobody's yet given!!] for following a particular path [or paths] yet to be recommended. The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. to clarify: the *community-driven* mainline support for sunxi. ok - which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i (Dual-Core Cortex A7)? which ones are in? A10, A13 for the moment. I just received hardware with A10s, A20 and A31 that I need to work on, but support should come quite soon. superb. question: what help or other resources could you do with? what additional information? I already have some patches pending to be tested on an A31 board, but didn't have as much time as I wanted lately to actually set a proper environment to test them. ok - good to know. btw when you get to it please note a bug found in the vanilla [allwinner-released] A20 3.3 tree where they reduced a 128 byte buffer to 78 bytes for spurious reasons; the critical fix is at line 989, of the following patch: http://git.rhombus-tech.net/?p=linux.git;a=commitdiff;h=refs/heads/lkcl-3.3-a20;hp=6c5753e5dc1fafff288d522c94b40a7dd2a81adc i found this by running a diff -u of sun4i_usb from the 3.4 sunxi community tree against the sun7i_usb tree from the allwinner 3.3 release. amongst the desperate attempts to disable DMA (probably due to stack corruption of the above bug) and various renaming attempts of *SUN4I* to *SUN7I*, that one stuck out like a sore thumb. the other bits - which may or may not be relevant - are the spinlock protection and the call to sw_udc_enable which is present in the sun4i_usb 3.4 code but not the A20 3.3 code. mileage may vary, and the buffer overrun only happens if you enable the OTG interface as dual (auto-detect) because that's enough features in the bitfield to cause there to be enough strcpy's... oops :) l. -- 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/capweedwfhy_abbxjspm7bvfdfhsxl5h594cfn4zvc6qfpu4...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Saturday, June 8, 2013, luke.leighton wrote: right - too many people contributed to this, input from jon smirl, wookie, maxime, tomasz, henrik, i've made a start here and will continue editing: this is notes for me to put forward an agenda for discussion: http://hands.com/~lkcl/allwinner_linux_proposal.txt i'm setting a rule that each section *has* to have a list of clear benefits, otherwise it'll have to be removed before it goes on to their Directors. so - even if there are any allwinner engineers reading this who would like something put forward please also speak up! :) l. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Hi luke I'm not a allwinner employer :-)$. but pretty much in the same position as they are. I'd like to add a few comments about the risk of adopting the device tree(from allwinner side) 1) current using fdt in bootloader(uboot) is not mature, I'm not saying about passing the fdt data to kernel. But the bootloader itself need information from device tree, say boot0/1 phase (boot device type, DDR initialization...) since fdt is not ready, and SRAM space is very limited ... I'm afraid 'fex' may co-exist with device tree. still, they receive benefits if they can adopt device tree, at least minimal the kernel side migration effort Generally this info already been pointed out by steppen warren in previous email... 2) device tree may not been understood by third vendors (who previus produce shoes or ? :-$), they are real old 'Fex' scheme user, they like edit the data in windows with dos format So, how to fill this gaps, make them happy? Creat another tool to handle device tree modification? Then it's another price they have to pay... Dennis Lan
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan) dennis.y...@gmail.com wrote: On Saturday, June 8, 2013, luke.leighton wrote: right - too many people contributed to this, input from jon smirl, wookie, maxime, tomasz, henrik, i've made a start here and will continue editing: this is notes for me to put forward an agenda for discussion: http://hands.com/~lkcl/allwinner_linux_proposal.txt i'm setting a rule that each section *has* to have a list of clear benefits, otherwise it'll have to be removed before it goes on to their Directors. so - even if there are any allwinner engineers reading this who would like something put forward please also speak up! :) l. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Hi luke I'm not a allwinner employer :-)$. but pretty much in the same position as they are. thanks for chipping in. I'd like to add a few comments about the risk of adopting the device tree(from allwinner side) 1) current using fdt in bootloader(uboot) is not mature, I'm not saying about passing the fdt data to kernel. fdt. could you provide some context here? what is it? (apart from being a TLA) But the bootloader itself need information from device tree, say boot0/1 phase (boot device type, DDR initialization...) since fdt is not ready, and SRAM space is very limited ... I'm afraid 'fex' may co-exist with device tree. still, they receive benefits if they can adopt device tree, at least minimal the kernel side migration effort Generally this info already been pointed out by steppen warren in previous email... ... which i have to admit i may have missed the significance of or possibly just missed it entirely. what's the main concern you have, here; what's the potential solution, and what's the benefit of that potential solution, to allwinner [direct or indirect]? 2) device tree may not been understood by third vendors (who previus produce shoes or ? :-$), :) they are real old 'Fex' scheme user, they like edit the data in windows with dos format So, how to fill this gaps, make them happy? Creat another tool to handle device tree modification? Then it's another price they have to pay... yehh... that kinda looks unavoidable, although it would ultimately only inconvenience the developers of the proprietary firmware-flashing tools [livesuite, phoenix] and so would be transparent to the factories and so on. i've mentioned the idea of having an in-kernel translation tool rather than an external (pre-runtime) one, i've yet to get some feedback on that. l. -- 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/CAPweEDyv=uN8_Ts4miXCGsCrNwYkovLpF_PYF7D1=n2_azh...@mail.gmail.com
Bug#711585: [linux-image-3.9-1-loongson-2f] linux 3.9.4-1 for loongson-2f doesn't halt/reboot/suspend-disk.
Package: linux-image-3.9-1-loongson-2f Version: 3.9.4-1 Severity: Important When rebooting, halting or suspending to disk on a mini-pc with loongson-2f, it just hangs, printing a weird trace. Fortunately dmessage kept such trace: Jun 7 23:34:30 mini-1 kernel: [2.18] EXT4-fs (sda6): write access will be enabled during recovery Jun 7 23:34:30 mini-1 kernel: [2.908000] EXT4-fs (sda6): orphan cleanup on readonly fs Jun 7 23:34:30 mini-1 kernel: [2.908000] EXT4-fs (sda6): ext4_orphan_cleanup: deleting unreferenced inode 888392 Jun 7 23:34:30 mini-1 kernel: [2.924000] EXT4-fs (sda6): ext4_orphan_cleanup: deleting unreferenced inode 889643 Jun 7 23:34:30 mini-1 kernel: [2.924000] EXT4-fs (sda6): ext4_orphan_cleanup: deleting unreferenced inode 904421 Jun 7 23:34:30 mini-1 kernel: [2.936000] EXT4-fs (sda6): 3 orphan inodes deleted Jun 7 23:34:30 mini-1 kernel: [2.94] EXT4-fs (sda6): recovery complete Jun 7 23:34:30 mini-1 kernel: [3.072000] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Jun 7 23:34:30 mini-1 kernel: [3.076000] VFS: Mounted root (ext4 filesystem) readonly on device 8:6. Jun 7 23:34:30 mini-1 kernel: [3.076000] Freeing unused kernel memory: 320k freed Jun 7 23:34:30 mini-1 kernel: [6.764000] cpufreq: Loongson-2F CPU frequency driver. Jun 7 23:34:30 mini-1 kernel: [6.812000] CPU 0 Unable to handle kernel paging request at virtual address c00106c8, epc == 8051f1c4, ra == 8051d36c Jun 7 23:34:30 mini-1 kernel: [6.816000] Oops[#1]: Jun 7 23:34:30 mini-1 kernel: [6.816000] Cpu 0 Jun 7 23:34:30 mini-1 kernel: [6.816000] $ 0 : cfff c00106c8 Jun 7 23:34:30 mini-1 kernel: [6.816000] $ 4 : 9800be421000 807b Jun 7 23:34:30 mini-1 kernel: [6.816000] $ 8 : 98000136e798 Jun 7 23:34:30 mini-1 kernel: [6.816000] $12 : 8047d688 803192e8 Jun 7 23:34:30 mini-1 kernel: [6.816000] $16 : 9800be421000 8081cc40 8081cc30 806f90b8 Jun 7 23:34:30 mini-1 kernel: [6.816000] $20 : 9800be764000 9800be6afe70 771b8000 4000 Jun 7 23:34:30 mini-1 kernel: [6.816000] $24 : 770c7ce4 Jun 7 23:34:30 mini-1 kernel: [6.816000] $28 : 9800be6ac000 9800be6afd50 00afc978 8051d36c Jun 7 23:34:30 mini-1 kernel: [6.816000] Hi: e147d0b6 Jun 7 23:34:30 mini-1 kernel: [6.816000] Lo: 748f7125 Jun 7 23:34:30 mini-1 kernel: [6.816000] epc : 8051f1c4 dev_uevent+0xe0/0x1a0 Jun 7 23:34:30 mini-1 kernel: [6.816000] Not tainted Jun 7 23:34:30 mini-1 kernel: [6.816000] ra: 8051d36c show_uevent+0xdc/0x178 Jun 7 23:34:30 mini-1 kernel: [6.816000] Status: 100044e3 KX SX UX KERNEL EXL IE Jun 7 23:34:30 mini-1 kernel: [6.816000] Cause : 10008008 Jun 7 23:34:30 mini-1 kernel: [6.816000] BadVA : c00106c8 Jun 7 23:34:30 mini-1 kernel: [6.816000] PrId : 6303 (ICT Loongson-2) Jun 7 23:34:30 mini-1 kernel: [6.816000] Modules linked in: usb_common Jun 7 23:34:30 mini-1 kernel: [6.816000] Process udevd (pid: 246, threadinfo=9800be6ac000, task=9800be67a6b8, tls=771fc2c0) Jun 7 23:34:30 mini-1 kernel: [6.816000] Stack : 8081cc40 806f90b8 9800be421000 Jun 7 23:34:30 mini-1 kernel: [6.816000] 8081cc40 8051d36c 9800be342980 80867818 Jun 7 23:34:30 mini-1 kernel: [6.816000] 9800be0f5550 8081cc40 806f90b8 9800be3429a0 Jun 7 23:34:30 mini-1 kernel: [6.816000] 9800be6afe70 8051dac0 00afc978 802c6778 Jun 7 23:34:30 mini-1 kernel: [6.816000] 9800be342980 80387a04 9800be6afe70 Jun 7 23:34:30 mini-1 kernel: [6.816000] 770785e0 4000 9800be75cec0 771b8000 Jun 7 23:34:30 mini-1 kernel: [6.816000] 9800be6afe70 770785e0 Jun 7 23:34:30 mini-1 kernel: [6.816000] 7f8e97d8 803190c0 0003 9800be75cec0 Jun 7 23:34:30 mini-1 kernel: [6.816000] 771b8000 000a 80319338 Jun 7 23:34:30 mini-1 kernel: [6.816000] 4000 000a Jun 7 23:34:30 mini-1 kernel: [6.816000] ... Jun 7 23:34:30 mini-1 kernel: [6.816000] Call Trace: Jun 7 23:34:30 mini-1 kernel: [6.816000] [8051f1c4] dev_uevent+0xe0/0x1a0 Jun 7 23:34:30 mini-1 kernel: [6.816000] [8051d36c] show_uevent+0xdc/0x178 Jun 7 23:34:30 mini-1 kernel: [