Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 9, 2013 at 11:31 PM, Russell King - ARM Linux wrote: > On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: >> this is all a rather round-about way to say that for those people who >> heard and are thinking of heeding russell's call to "be silent and to >> ignore me" > > Okay, so you've just misrepresented me in the above comment. I never > said anything of the sort. The closest that I've come to a comment like > that is asking you to stop wasting people's time. close enough. > So, given your displayed inability to properly convey what people have > said to you in a discussion in your own replies, is there *any* reason > that anyone should trust you to communicate their position to any other > third party? trust is always something that has to be given, russell. respect is earned, but trust is given. many make the mistake of believing that trust is earned [people who seek to defeat others as "enemies" know this and exploit it to devastating effect]. so i can't answer your question directly, but consider this: the people that i work with have known me for a long time. they know i'm a bit of a live wire (you saw that wookey called me "crazy luke") and they often go as completely spare at some of the spanners i throw in the works just as everyone else does. it's *they* who will be doing all the talking, and i will be advising them in the background over the next week so that *technically* they're prepped. everyone has a different role to play here. /peace 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/capweedx2m800s+ptmd3vmmkv1odz0sojp-ydvjnrny5j7oc...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: > this is all a rather round-about way to say that for those people who > heard and are thinking of heeding russell's call to "be silent and to > ignore me" Okay, so you've just misrepresented me in the above comment. I never said anything of the sort. The closest that I've come to a comment like that is asking you to stop wasting people's time. So, given your displayed inability to properly convey what people have said to you in a discussion in your own replies, is there *any* reason that anyone should trust you to communicate their position to any other third party? In some ways, I'm *glad* that you've passed everything on verbatum, because it means that it's (hopefully) free from any misrepresentations such as the above. -- 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/20130609223149.go18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ok, so the deadline's almost up but the discussions of the past two or so days have basically i think everything that needs to be said, and i'm extremely grateful to everyone who's contributed, privately and publicly, especially on such short notice. i've passed it over to my associates who will turn it into executive-level-speak: they understand that the situation is sensitive and have far more sense than i, which is good. i'm not sure if i should admit this, but there's some irony here that needs to be shared. i passed the collation of input from people - most of it verbatim - over to my associate who is used to dealing with executive-level people, and he said it couldn't possibly go as-is to them, not even to their assistant. when i asked why he said it was because it sounded too much like ordering them what decisions to make. if you've been following the shit-storm criticism that's been directed at me, and you've also noticed the bit about "most of it being verbatim" you have to appreciate the irony, really. so *sigh* we have to trust my associates and their experience in dealing with executives to work out a way to get the message across: i understand the things about public communication on-list(s) being important and so on and will fight to make sure those are got across in some clear form. the good news is that they *have* asked for advice and for a report, so there *is* an opening, it's not an unwelcome cold-call that we're engaging in, here. the last thing i'd like to say is this: free (libre) software developers and advocates are in an extremely... odd position of not really being fully or adequately monetarily compensated for the true level of service that they truly provide. i mention "service" because regardless of whether it's business or whether it's spare-time work just for the heck of it, we *are* acting as servants to a great many people, and in many cases those people who directly receive the benefit of our work - millions if not hundreds of people now that the linux kernel has made its way into android - have absolutely no way of being able to identify us and pay us for that service. i've never thought about giving up, but i *have* been thinking "what the hell am i doing wrong i.e. why have i only received direct donations of about $300 in *total* for all work done for the free software community since 1995 including samba and exchange 5.5 reverse-engineering and much more", up until recently when i learned some new insights that i thought it important to share, here. the insight is this: that there is a separate tally which is inviolate that keeps a *true* account of the level of service that we *truly* provide to others, of which monetary compensation is only a partial reflection [subtracted from that inviolate account, in some cases resulting in a DEBT in the inviolate and true account - which will need to be repaid - if the monetary compensation was too high or the service provided too poor]. so, for anyone reading this who has seen the shit-storm of the past few days and felt either embarrassed, or for any other reason has felt that they should quit working with free software, please don't: remember that the work itself is not necessarily the reward (although that's important too), nor that you're providing service to others and that that itself should be the reward, but that you *will* or *are* receiving true and accurate compensation: believe it, because it's true. this is all a rather round-about way to say that for those people who heard and are thinking of heeding russell's call to "be silent and to ignore me", to do so would be a significant dis-service both to yourself and to the hundreds of millions of end-users whom you are serving, if the long-term and immediate-term projects that i have embarked on are the success that i envision them to be. even with that having been said, it is, indeed, entirely your choice, that nobody but you should make. 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/CAPweEDw0U-djVaVzWoNnvhWvwOP=LXc=ac97zztyb6akf+j...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sat, Jun 8, 2013 at 9:28 AM, Tomasz Figa wrote: > Now that the discussion went off from "you stupid kernel developers *lol*. i get that summary ["you said people were stupid!!!"] a lot. i don't quite understand where it comes from, otherwise i would stop doing it :) > adopted DeviceTree without even asking a closed company about their > proprietary solution, which does the same" to something a bit more > constructive, let me point some of the benefits. > [snip...] ahh, magic. these have gone straight into that proposal. i think the best ones - the gems - are the test-coverage and formally allowing public interaction. the test coverage because it will reduce the risk of errors in the silicon [you never know when developing both hardware and software where the bug might be] as well as reduce the development time and development costs. the public interaction (which i was going to ask thomas and maxime about, this morning) because it means a much faster feedback loop. i've been trying to think of ways to link "if you do X it will result in more sales and reduce risk" to the discussion, and i think you finally hit it tomasz, so thank you. 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/capweedwon7x-frqurvkdnxu3ncyogrezy9v5q8zxvoe6kwk...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Luke, On Friday 07 of June 2013 22:29:34 luke.leighton wrote: > On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni > > 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? Now that the discussion went off from "you stupid kernel developers adopted DeviceTree without even asking a closed company about their proprietary solution, which does the same" to something a bit more constructive, let me point some of the benefits. First let me remind you the proposals from one of my previous posts: - let Allwinner engineers join the relevant mailing lists - mostly linux- arm-kernel, but also all the topic-specific ones, like linux-mmc, linux- usb, linux-pm, devicetree-discuss, etc. - adjust their workflow to comply with rules of Linux kernel open source community (i.e. sending RFCs of things in development, getting code reviewed, addressing comments) - rework existing code to use widely-accepted, standard solutions available in upstream Linux kernel (although this is already mostly done by sunxi community) to avoid reinventing wheels - this is not only about DeviceTree, which you mentioned already in your proposal list, but also all the generic frameworks present in the kernel Now the benefits of cooperation with Linux kernel community: - access to big knowledge base of all the Linux kernel developers participating in discussions on the mailing lists; any technical (and maybe non-technical?) problems related to the kernel can be discussed on the lists at any time; also this would be a good form of communication between Allwinner engineers and sunxi community - in-depth code review by experienced kernel developers that allows early spotting of issues and finding possible improvements of design and implementation; having this would avoid things like you mentioned with their usb driver - extended testing coverage - anyone can access the patches in development (through the ML or linux-next integration tree), test them on their board with Allwinner SoC and report any issues on respective mailing lists - ability to participate in development of the whole Linux kernel, including any existing and new generic frameworks, drivers, etc., in terms of discussion, sending patches, reviewing patches of other developers; this is very important to make sure that the part being developed suits the needs of everyone (or at least most of the parties) - you can't know that without enough discussion; this is also important to avoid reinventing wheels - there might be a useful part of code available in some internal tree of some company or developer, which could be just extended (or even used as is), without the need to reinvent it, but people must know about it first That's all I can think of at the moment (+ all the proposals and benefits you have in your file already). 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/4247099.i8S79t0Pua@flatron
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) 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
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 Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard 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 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 8:30 PM, Russell King - ARM Linux 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 7, 2013 at 7:59 PM, Thomas Petazzoni 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:35 PM, Russell King - ARM Linux 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 >> 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
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))
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
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 > 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))
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:04:26PM +0100, luke.leighton wrote: > On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson 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))
+++ 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 Friday 07 of June 2013 20:02:03 luke.leighton wrote: > On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa 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))
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 > 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 Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
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 7, 2013 at 7:57 PM, Wookey 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:54 PM, Olof Johansson 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 > 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 9:57 AM, Tomasz Figa 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:26 PM, Russell King - ARM Linux 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 Thu, Jun 6, 2013 at 9:22 PM, Arnd Bergmann 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 Thu, Jun 6, 2013 at 6:28 PM, Maxime Ripard 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 5:00 PM, Olof Johansson wrote: > On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: >> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton >> 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))
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))
Luke, I want only one thing from you at this time. See below. On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton 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))
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))
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 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 7, 2013 at 9:18 AM, Alexandre Belloni wrote: > On 07/06/2013 10:06, luke.leighton wrote: >> On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic 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))
On 06/07/2013 02:02 AM, luke.leighton wrote: > On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux > wrote: > >> If companies are going to go off and invent the square wheel, and that >> makes *them* suffer the loss of being able to merge back into the >> mainline kernel, thereby making *their* job of moving forward with >> their kernel versions much harder, then yes, we *are* happy. > > russell: they have more employees than sense :) they also don't have > any idea of what they *should* be doing, so this is an opportunity to > educate them. You know, they're probably reading this thread, and if not, they certainly can in the list archives. It's probably not a good idea to slag them off like that, and like other comments in this thread... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b218bf.60...@wwwdotorg.org
Re: [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.
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))
Tomasz Figa 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
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))
2013/6/7 Olof Johansson : > On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: >> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton >> 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))
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))
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: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))
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 07/06/2013 10:06, luke.leighton wrote: > On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic 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))
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic wrote: > luke.leighton wrote: >> >> On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic >> 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 Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux 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 Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa wrote:
> On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa
> 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
>> >
>> > 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))
luke.leighton wrote: On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic 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 1:51 PM, Vladimir Pantelic 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))
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. 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. Ironically (given NVIDIA's reputation), the Tegra platform is the strongest competitor I see in that race at the moment. 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. Arnd -- 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/20130606.53780.a...@arndb.de
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 13:22 +0100 skrev luke.leighton: > idea: hook into devicetree gpio functions to allow script-fex gpio functions to gain access in a separate module? that sort of thing. No. Drop FEX from the kernel, use DT. There is no reason why the kernel shold care about the FEX format. Translate from FEX to DT where needed in the "firmware" image build process to allow Allwinner to keep the FEX as hardware description to the ODMs. 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/1370544712.31564.11.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 13:19 +0100 skrev luke.leighton: > mass-volume tablet, mass-volume IPTV box. android OS, nothing else. Which still includes a number of possible configurations with different i2c, spi, usb etc devices connected on the board. Because Allwinner is not using mainline methods for configuration their customers are stuck in only selecting between a very limited set of "Allwinner compatible" auxillary chips (g-sensors, led controls, wifi modules, gps modules etc) in their designs. By using DT their customers are free to choose any device supported mainline. 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/1370544282.31564.5.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 07:28:10PM +0200, Maxime Ripard wrote: > 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. > > 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. Well I hope they get there soon, because they sure have some very nice chip designs at amazing prices. -- 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/20130606185515.ga11...@csclub.uwaterloo.ca
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hi everyone, On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote: > On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: > > On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton > > 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. > > 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. 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. -- 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/20130606172810.GE14209@lukather
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote: > On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton 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. 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 -- 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/caoesgmgqxhg45nycfphc_0uhs+_gn-hgzm-+crvk2eef1ag...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton 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. 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. -- Jon Smirl jonsm...@gmail.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/cakon4oxpdpn3btc9gwp44exdskazgj5oecpup37vrnnvxwu...@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 7:02 AM, Theodore Ts'o wrote: > On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote: >> On Thu, Jun 6, 2013 at 1:01 AM, 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. >> >> 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. > > But that's not a true statement. You've said that Allwinner is > perfectly happy to carry code out of tree, by constantly porting their > hacks from mainline kernels. > > For some of their customers, this will be acceptable to them. In > those cases, Linux will still be in use. Great! So claiming that the > reach of Linux will be "dramatically reduced" just is not a > supportable position. > > For other (potential) customers, for whom mainline kernel support is > critically important, they will choose other hardware solutions that > are in the mainline kernel. > > I don't see the problem here. This is all just a big storm in a cup. Mainline kernel support for allwinner SoCs are already happening through hobby development by Maxime Ripard and others. Allwinner are not yet actively participating, but they're aware of it. The whole situation is a non-issue. If the vendor prefers to keep carrying their own code for a while, they're free to. It makes more sense for them to move over to the upstream code as they move forward with their kernel versions, but they can do that on their own schedule. We've seen all this before, it tends to turn out OK in the longer run. -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/caoesgmgukawvun978xqarwowbehvqqxcpkyq2eua8yavgh5...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote: > On Thu, Jun 6, 2013 at 1:01 AM, 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. > > 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. But that's not a true statement. You've said that Allwinner is perfectly happy to carry code out of tree, by constantly porting their hacks from mainline kernels. For some of their customers, this will be acceptable to them. In those cases, Linux will still be in use. Great! So claiming that the reach of Linux will be "dramatically reduced" just is not a supportable position. For other (potential) customers, for whom mainline kernel support is critically important, they will choose other hardware solutions that are in the mainline kernel. I don't see the problem here. - Ted -- 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/20130606140250.ga4...@thunk.org
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 01:22:04PM +0100, luke.leighton wrote: > On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström > wrote: > > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: > > > >> > Not really the case. Actually the opposite. DT have this as well, and > >> > integrated in device probing. Allwinner need to hack every driver used > >> > to add their gpio requests to have pinmuxing triggered. > >> > >> augh. ok. solutions. what are the solutions here? > > > > What I said before. > > idea: hook into devicetree gpio functions to allow script-fex gpio > functions to gain access in a separate module? that sort of thing. > > > Go with DT for the kernel. There is no need for two configuration > > mechanisms doing the same thing. Disguise it in fex form (and > > translator) if too hard for people with a DOS editior to configure. > > what methods for doing that. i need proposals. 4 days on the clock. No. If you want to set time scales, please put up money to find the work to come up with those proposals. Virtually no one here is a charity; the charity days of open source are long gone. Everyone needs money to put food in their mouths, and the way this works is that those who pay the most get the time. That's the nature of a open and free market. What's more is that you have been given some good proposals already: converting the fex description to DT for the kernel. Wow, that means you can use the work which has already been done in the mainline kernel for free! How cool is that! -- 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/20130606131506.go18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote: > On Thu, Jun 6, 2013 at 1:01 AM, 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. > > 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. 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. 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. 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 - you change the policy as a whole because you have a technically superior solution 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". -- 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/20130606131042.gn18...@n2100.arm.linux.org.uk
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thursday 06 of June 2013 13:49:38 luke.leighton wrote: > On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa 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 > > > > 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. There is also AMLogic, though. > > 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. (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.) Best regards, Tomasz > and many other reasons. > > > (Just > > saying, as I do not know anything about their view on this. There is a > > lot of cheap tablets built using their products as well.) > > > > 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/1622862.fXQWv0YWGV@flatron
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:19 AM, Henrik Nordström wrote: tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: > Not really the case. Actually the opposite. DT have this as well, and > integrated in device probing. Allwinner need to hack every driver used > to add their gpio requests to have pinmuxing triggered. augh. ok. solutions. what are the solutions here? What I said before. idea: hook into devicetree gpio functions to allow script-fex gpio functions to gain access in a separate module? that sort of thing. Go with DT for the kernel. There is no need for two configuration mechanisms doing the same thing. Disguise it in fex form (and translator) if too hard for people with a DOS editior to configure. what methods for doing that. i need proposals. 4 days on the clock. 4 days? WTF? since when did setting an ultimatum to the kernel community work? -- 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/51b085c6.3000...@gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa 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 > 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. > There are many other SoC vendors making low cost SoCs, like Rockchip, > Boxchip, boxchip *is* allwinner. > 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. and many other reasons. > (Just > saying, as I do not know anything about their view on this. There is a lot > of cheap tablets built using their products as well.) > > 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/CAPweEDxWW4LUeBaHLb+wHuAMq=63p88zsx4tumvb2pdp_+o...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Luke, On Thursday 06 of June 2013 13:24:57 luke.leighton wrote: > On Thu, Jun 6, 2013 at 1:01 AM, 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. > 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. There are many other SoC vendors making low cost SoCs, like Rockchip, Boxchip, Telechips. Maybe they would be better candidates for being promoted as vendors of choice for hardware running free software? (Just saying, as I do not know anything about their view on this. There is a lot of cheap tablets built using their products as well.) 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/1851164.HnXhGSdttW@flatron
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 1:01 AM, 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. 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. -- 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/CAPweEDzYLDzh_-OWU61dtVhajZ40QpQgZKHFYDsh3FgF=r9...@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 1:19 AM, Henrik Nordström wrote: > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: > >> > Not really the case. Actually the opposite. DT have this as well, and >> > integrated in device probing. Allwinner need to hack every driver used >> > to add their gpio requests to have pinmuxing triggered. >> >> augh. ok. solutions. what are the solutions here? > > What I said before. idea: hook into devicetree gpio functions to allow script-fex gpio functions to gain access in a separate module? that sort of thing. > Go with DT for the kernel. There is no need for two configuration > mechanisms doing the same thing. Disguise it in fex form (and > translator) if too hard for people with a DOS editior to configure. what methods for doing that. i need proposals. 4 days on the clock. -- 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/capweedypffcn9cnj10zht+azjhtrdu0lmfcgm_756uabf+n...@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 1:15 AM, Henrik Nordström wrote: > conditions. I don't know what you really mean here, only that it's not > "target market". mass-volume tablet, mass-volume IPTV box. android OS, nothing else. -- 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/CAPweEDzrYL5c9v1T=nTcyv9RPrJ-TEnCyyjpHQnhXXJY-32=5...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hi Thomas, On Thursday 06 of June 2013 11:27:23 Thomas Petazzoni 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? My colleague > Maxime Ripard (Cc'ed) 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. > > So isn't this entire discussion completely moot? The mainline support > for sunxi has already started since 6 months or so, and has been Device > Tree based from day one. Sure, I've been observing the development of sunxi support since it started. This is the reason why any remaining Allwinner drivers must be converted to use DT instead of this proprietary stuff as well, if they want to upstream any of them. 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/3628961.Gph977QOV0@flatron
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 06, 2013 at 02:01:14AM +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. Well, the server guys are working on ACPI - people could contribute to that effort instead if they preferred (though I can see that they might not!). signature.asc Description: Digital signature
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
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? My colleague Maxime Ripard (Cc'ed) 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. So isn't this entire discussion completely moot? The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. Best regards, Thomas -- 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/20130606112723.71ddd70c@skate
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 23:20 +0100 skrev luke.leighton: > ok: great. so we have something that i can potentially propose to > them. now: what reason can i give that they should accept this? > what's the biggest incentive for them, here, to make these changes? > what would they gain? Mainly a common infrastructure so they don't need to hack every driver to work with their scheme. But there is no way to escape from the fact that first round will be far more complicated than just adding their own stuff as-is likely is. Many of the upstreamed drivers are rewritten and far from their drivers. And further complicated by their supported designs often using devices (wifi modules, touch panels, nand chips, etc) where 3 year old barely maintained vendor code actually works better than what is currently in the upstream kernel. So no, I can not say that there is an easy road ahead, Regards Henri -- 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/1370478224.20454.69.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton: > > Not really the case. Actually the opposite. DT have this as well, and > > integrated in device probing. Allwinner need to hack every driver used > > to add their gpio requests to have pinmuxing triggered. > > augh. ok. solutions. what are the solutions here? What I said before. Go with DT for the kernel. There is no need for two configuration mechanisms doing the same thing. Disguise it in fex form (and translator) if too hard for people with a DOS editior to configure. 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/1370477958.20454.68.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:52 +0100 skrev luke.leighton: > > How is the Allwinner kernel going to load the driver for the pca9532? > > The mainline pca9532 driver does not understand fex so it can't read > > the necessary initialization data. > > jon: you're immediately outside of the target market for which > allwinner designed and deployed script.fex. You missed the point. Mainlne Kernel drivers do take advantege of DT to ease their bindings and configuration, much further than the fex can express. The exact same thing is experienced in designing a tablet. You add a pheriperal device, and it needs to be configured somehow. DT does this and it integrated in the kernel framework. fex also attemtps in doing part of this, but lacks integration and requires much more driver patching to fly. And I don't see how you can say that pca9532 is off the grid in the target market. It would fit nicely as a key backlight / edge colour controller in a tablet to give the tablet a personal touch. > > fex is only supported on the small number of peripheral chips > > Allwinner has blessed. Use any chip outside of that set and it isn't > > going to boot. > > eeexactly. i did say "target market". Yes you repeat that over an over. But what does it mean? I think what you really mean is something else more in the line of "ODMs not allowed to step outside a very narrow range of possible designs or using less than a handful approved providers", typical lockin conditions. I don't know what you really mean here, only that it's not "target market". 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/1370477756.20454.65.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thursday 06 of June 2013 00:54:02 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:40 AM, Henrik Nordström
>
> wrote:
> > tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
> >> no john - they've only added it to the multiplexed sections of the
> >>
> >> drivers which they themselves have written. such as
> >> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> >> arch/arm/mach-sun{N}i and so on.
> >
> > And a number of SPI device drivers, USB device drivers, vendor
> > provided
> > device drivers, ..
> >
> >> the script.fex system deals with the pinmux issue in a very neat way
that:
> >> a) has very little impact on the rest of the kernel tree [citation
> >>
> >> needed! i'm saying that: could someone please confirm if it's true]
> >
> > Not really the case. Actually the opposite. DT have this as well, and
> > integrated in device probing. Allwinner need to hack every driver used
> > to add their gpio requests to have pinmuxing triggered.
>
> augh. ok. solutions. what are the solutions here?
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.
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/1733666.lHUBcfUXq9@flatron
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thu, Jun 6, 2013 at 12:40 AM, jonsm...@gmail.com wrote: > I have a Cubieboard and I have a pca9532 on my desk. Now I want to > attach this pca9532 to the Cubieboard so I wire them together on I2C. > > How is the Allwinner kernel going to load the driver for the pca9532? > The mainline pca9532 driver does not understand fex so it can't read > the necessary initialization data. jon: you're immediately outside of the target market for which allwinner designed and deployed script.fex. > Luke, you of all people should see what is going on. Take an EOMA > module based on an A10. Now plug it into ten different hosts with > widely varying hardware support - like each of the ten hosts has a > different lm-sensor type chip. Where are the fex drivers for those ten > different lm-sensor chips going to come from? We already have DT > support for them. that's fantastic, because as you can see, the two systems complement each other. > fex is only supported on the small number of peripheral chips > Allwinner has blessed. Use any chip outside of that set and it isn't > going to boot. eeexactly. i did say "target market". so, we have a clear illustration that neither script.fex nor devicetree actually help solve the "chip proliferation" problem. but that's another story, and getting off-topic. what i need is a clear set of proposals, discussed and then the best one(s) that people can come up with be then summarised so that i can get them clearly and succinctly across to allwinner, along with the benefits to allwinner of each of the options. time is of the essence, speaking of which i'm pushing things to the limit including my health so i *really* have to go, i'm going to leave this up to everyone to discuss, please nominate someone to email me directly [on a different subject] so that i can read the proposals summaries should people choose to write any. thanks. 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/capweedyo+sc1aq64hbeh1oszmpnsnwmweo5kbhsan5vw_ye...@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 12:40 AM, Henrik Nordström
wrote:
> tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
>
>> no john - they've only added it to the multiplexed sections of the
>> drivers which they themselves have written. such as
>> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
>> arch/arm/mach-sun{N}i and so on.
>
> And a number of SPI device drivers, USB device drivers, vendor provided
> device drivers, ..
>
>> the script.fex system deals with the pinmux issue in a very neat way that:
>>
>> a) has very little impact on the rest of the kernel tree [citation
>> needed! i'm saying that: could someone please confirm if it's true]
>
> Not really the case. Actually the opposite. DT have this as well, and
> integrated in device probing. Allwinner need to hack every driver used
> to add their gpio requests to have pinmuxing triggered.
augh. ok. solutions. what are the solutions here?
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/CAPweEDwS3tR=wh-bZJb3vqR8fVQra=3xxditowgrdh9c7wr...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
And a number of SPI device drivers, USB device drivers, vendor provided
device drivers, ..
> the script.fex system deals with the pinmux issue in a very neat way that:
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
Not really the case. Actually the opposite. DT have this as well, and
integrated in device probing. Allwinner need to hack every driver used
to add their gpio requests to have pinmuxing triggered.
It is just layered a bit differently when using DT.
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/1370475609.20454.44.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com
> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton
>> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>>> wrote:
>>>
> and then there's the boot0 and boot1 loaders, these *do* have
>>>
no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
(not cache), but boot1 is on pair with u-boot in size and runs from
DRAM.
>>>
>>> btw, please listen to henrik: he knows what he's talking about, as
>>> you can see :) henrik, thank you for correcting my technical
>>> misunderstandings, i'll try to remember them and not propagate
>>> incorrect stuff.
>>
>> This is not about the fex syntax or uboot. The root problem is needing
>> two sets of binding for every device driver in the kernel. Pick a
>> random driver like gpio-pca953x.c and look at the source. In that file
>> there are #ifdef CONFIG_OF_ sections. Those sections are directly
>> reading the FDT binary via calls like of_get_property(node,
>> "linux,gpio-base", &size);. If fex is added to the kernel every driver
>> driver will now need both a #ifdef CONFIG_OF_ section and also a
>> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
>
> yes. which is why they haven't done it.
>
>> Is Allwinner
>> going to add fex support to every single device driver in the kernel?
>
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
>
> even the touchscreen driver that they wrote, that's got nothing to do
> with any other code in the touchscreen linux kernel source tree: it's
> more of a "meta-"driver which even has the name of the linux kernel
> module that needs to be loaded and what I2C address, GPIO options etc.
> to pass in [normally done as modprobe options in userspace].
>
> to be honest, there are better people to fully answer this question
> (alejandro and henrik are two that spring to mind) but you're
> definitely off-base, jon. the script.fex system deals with the pinmux
> issue in a very neat way that:
I have a Cubieboard and I have a pca9532 on my desk. Now I want to
attach this pca9532 to the Cubieboard so I wire them together on I2C.
How is the Allwinner kernel going to load the driver for the pca9532?
The mainline pca9532 driver does not understand fex so it can't read
the necessary initialization data.
Luke, you of all people should see what is going on. Take an EOMA
module based on an A10. Now plug it into ten different hosts with
widely varying hardware support - like each of the ten hosts has a
different lm-sensor type chip. Where are the fex drivers for those ten
different lm-sensor chips going to come from? We already have DT
support for them.
fex is only supported on the small number of peripheral chips
Allwinner has blessed. Use any chip outside of that set and it isn't
going to boot.
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
>
> b) the linux kernel developers could, instead of criticising it,
> actually learn a great deal from.
>
> l.
--
Jon Smirl
jonsm...@gmail.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/CAKON4Oz79hUE_ReAqjeynwL6ZWntX2W1uw3YOg0G2AiY7Gjs=g...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com
> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton
>> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>>> wrote:
>>>
> and then there's the boot0 and boot1 loaders, these *do* have
>>>
no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
(not cache), but boot1 is on pair with u-boot in size and runs from
DRAM.
>>>
>>> btw, please listen to henrik: he knows what he's talking about, as
>>> you can see :) henrik, thank you for correcting my technical
>>> misunderstandings, i'll try to remember them and not propagate
>>> incorrect stuff.
>>
>> This is not about the fex syntax or uboot. The root problem is needing
>> two sets of binding for every device driver in the kernel. Pick a
>> random driver like gpio-pca953x.c and look at the source. In that file
>> there are #ifdef CONFIG_OF_ sections. Those sections are directly
>> reading the FDT binary via calls like of_get_property(node,
>> "linux,gpio-base", &size);. If fex is added to the kernel every driver
>> driver will now need both a #ifdef CONFIG_OF_ section and also a
>> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
>
> yes. which is why they haven't done it.
>
>> Is Allwinner
>> going to add fex support to every single device driver in the kernel?
>
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
>
> even the touchscreen driver that they wrote, that's got nothing to do
> with any other code in the touchscreen linux kernel source tree: it's
> more of a "meta-"driver which even has the name of the linux kernel
> module that needs to be loaded and what I2C address, GPIO options etc.
> to pass in [normally done as modprobe options in userspace].
>
> to be honest, there are better people to fully answer this question
> (alejandro and henrik are two that spring to mind) but you're
> definitely off-base, jon. the script.fex system deals with the pinmux
> issue in a very neat way that:
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
>
> b) the linux kernel developers could, instead of criticising it,
> actually learn a great deal from.
>
> l.
--
Jon Smirl
jonsm...@gmail.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/CAKON4OyWaUod8m-7Fn5qdjnMs8o+ajqdOJ=XRmw_vl00...@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 12:07 AM, jonsm...@gmail.com wrote:
> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton wrote:
>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>> wrote:
>>
and then there's the boot0 and boot1 loaders, these *do* have
>>
>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>> DRAM.
>>
>> btw, please listen to henrik: he knows what he's talking about, as
>> you can see :) henrik, thank you for correcting my technical
>> misunderstandings, i'll try to remember them and not propagate
>> incorrect stuff.
>
> This is not about the fex syntax or uboot. The root problem is needing
> two sets of binding for every device driver in the kernel. Pick a
> random driver like gpio-pca953x.c and look at the source. In that file
> there are #ifdef CONFIG_OF_ sections. Those sections are directly
> reading the FDT binary via calls like of_get_property(node,
> "linux,gpio-base", &size);. If fex is added to the kernel every driver
> driver will now need both a #ifdef CONFIG_OF_ section and also a
> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
yes. which is why they haven't done it.
> Is Allwinner
> going to add fex support to every single device driver in the kernel?
no john - they've only added it to the multiplexed sections of the
drivers which they themselves have written. such as
drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
arch/arm/mach-sun{N}i and so on.
even the touchscreen driver that they wrote, that's got nothing to do
with any other code in the touchscreen linux kernel source tree: it's
more of a "meta-"driver which even has the name of the linux kernel
module that needs to be loaded and what I2C address, GPIO options etc.
to pass in [normally done as modprobe options in userspace].
to be honest, there are better people to fully answer this question
(alejandro and henrik are two that spring to mind) but you're
definitely off-base, jon. the script.fex system deals with the pinmux
issue in a very neat way that:
a) has very little impact on the rest of the kernel tree [citation
needed! i'm saying that: could someone please confirm if it's true]
b) the linux kernel developers could, instead of criticising it,
actually learn a great deal from.
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/capweedw1babe0cmt5fxz3z9p9eh508m3nzcqk2vco0oz-qy...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren: > 1) Put all the parameters in the U-Boot configuration header. This is > normal. Yes, we do so today for U-Boot SPL. But this won't fit very well with the Allwinner ODM workflow where one binary image works on a wide range of board configurations probed while flashing the image to the board, but on the other hand there is no real need for them to use u-boot as the primary boot loader, just keep using boot0 + boot1 + u-boot chain as they have always done. > 2) Read some data structure at run-time. This data structure could in > theory be some SoC-specific blob format (e.g. the packed version of > information that some tool extracts from FEX/DT), a whole FEX blob, or > device tree. This is likely to happen for the sunxi U-Boot SPL due to the sheer amount of boards involved, and is done to some extents for other boards as well. In the SPL there generally isn't room for full DT support. Main u-boot HW configuration could be done runtime via DT alone but we are not quite there yet, nothing major missing however other than getting it done. 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/1370474115.20454.26.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton wrote: > On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström > wrote: > >>> and then there's the boot0 and boot1 loaders, these *do* have > >> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM >> (not cache), but boot1 is on pair with u-boot in size and runs from >> DRAM. > > btw, please listen to henrik: he knows what he's talking about, as > you can see :) henrik, thank you for correcting my technical > misunderstandings, i'll try to remember them and not propagate > incorrect stuff. This is not about the fex syntax or uboot. The root problem is needing two sets of binding for every device driver in the kernel. Pick a random driver like gpio-pca953x.c and look at the source. In that file there are #ifdef CONFIG_OF_ sections. Those sections are directly reading the FDT binary via calls like of_get_property(node, "linux,gpio-base", &size);. If fex is added to the kernel every driver driver will now need both a #ifdef CONFIG_OF_ section and also a #ifdef CONFIG_FEX_ section. Doing that is just crazy. Is Allwinner going to add fex support to every single device driver in the kernel? Of course not, that task is far too large. What Allwinner needs to do is come onto the common API that everyone else is using. So consider what is going to happen if you try to use a pca953x chip in an Allwinner system. You're going to have to rewrite part of the device driver. You're going to have to do that for every chip you try to use. Those forks won't be accepted back into the kernel, etc. And you'll end up as yet another port and forget embedded developer. As for uboot I hope you are using the SPL support and haven't reimplemented it. If the full uboot has been modified to dynamically read a script.bin then it shouldn't be much of a stretch to teach it about FDT instead. That would be a useful feature to add to mainline uboot. As for fex2bin and bin2fex you already have the equivalent tool on your machine. It is called dtc. Check out scripts/dtc. So if you are in love with fex syntax write a script that converts it into device tree syntax. Then compile the DTS using dtc into a DTB. When the DTB is in memory it is a FDT (flattened device tree). It's that FDT format in memory that has become fixed in stone. -- Jon Smirl jonsm...@gmail.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/cakon4oxwyv2f_iteb5rnp_azc7essxpdku_ty5wlwxn7usi...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On 06/05/2013 03:59 PM, Henrik Nordström wrote: > ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: ... >> so the point is: if anyone wishes me to propose to allwinner that >> they convert over to devicetree, or any other proposal which involves >> significant low-level changes to their working practices that could >> potentially have a massive knock-on effect onto their >> multi-million-dollar clients, it had better be a damn good story. > > Calm down. It isn't really a significant difference to them outside of > the kernel. They do not need to change any of their configuraiton > methods, only a small toolchain change in how the resultig images are > built to have a corresponding device tree built. If U-Boot needs to be parametrized, there are in theory a few options open: 1) Put all the parameters in the U-Boot configuration header. This is normal. 2) Read some data structure at run-time. This data structure could in theory be some SoC-specific blob format (e.g. the packed version of information that some tool extracts from FEX/DT), a whole FEX blob, or device tree. The U-Boot maintainers have already indicated that they won't accept the first two options; run-time configuration has to be via DT, and not via some SoC-specific mechanism. (As I found out to my detriment when I attempted to make U-Boot on Tegra determine which UART to use for debug at run-time by reading the configuration header that our boot ROM uses). Now of course, boot0/boot1 could always transform whatever data structure they wish into a DTB before passing that to U-Boot... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51afc19f.9040...@wwwdotorg.org
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström wrote: >> and then there's the boot0 and boot1 loaders, these *do* have > no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM > (not cache), but boot1 is on pair with u-boot in size and runs from > DRAM. btw, please listen to henrik: he knows what he's talking about, as you can see :) henrik, thank you for correcting my technical misunderstandings, i'll try to remember them and not propagate incorrect stuff. >> so the point is: if anyone wishes me to propose to allwinner that >> they convert over to devicetree, or any other proposal which involves >> significant low-level changes to their working practices that could >> potentially have a massive knock-on effect onto their >> multi-million-dollar clients, it had better be a damn good story. > > Calm down. i am - honest! yes it's a little past my bed-time, but hey... > It isn't really a significant difference to them outside of > the kernel. They do not need to change any of their configuraiton > methods, only a small toolchain change in how the resultig images are > built to have a corresponding device tree built. henrik, jon (smirl), can i ask you both a favour? could you write something up, preferably short, that i could put forward to allwinner? describing what's needed, who would need to do what and so on. > But it is a fair bit of one-time changes kernel side. And some > scratching to figure out how to use/improve/ignore the stuff being > mainlined. i still also - really - need a good justification for this. something which helps explain clearly what the immediate or perhaps strategic benefits would be to allwinner, as to why they should accept such changes. i cannot emphasise enough how important that is. if someone can please help come up with a good justification as to why allwinner should change their working practices, that would be enormously helpful i feel, to solving this issue. otherwise we are stuck in the current situation which nobody really likes. i'm inviting you - linux kernel developers - i'm giving you an opportunity to *fix* things. you have 2 weeks to come up with a solution, which can be presented in a simple format. that's the window of opportunity. 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/CAPweEDxMpeJc-w=Yd7d2OT=uisrbp2rxf-mpmducog3eyjz...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton: > what we do not want to happen is that they see upstream patches being > submitted, they merge them into their internal tree (which to date has > had zero upstream changes: they're currently only just getting round > to doing 3.4 as we speak), and they *completely* ignore *absolutely > everything* that's being done by the community, duplicating yet > another set of device drivers (named drivers/*/sun8i_* and so on). Well, that will obviously happen one or two more rounds, a bit depending on which kernel releases Android will use. But I hope the Allwinner kernel team will rethink when they hit more current kernels. > this proposal is a start: however what you have to bear in mind is > that you now have to convince a very busy company that it is in their > best interests to disrupt their schedule, to drop their existing > working practices, to tell all their customers "please stop using the > existing tools and please use these ones instead". Why? > you also need to convince the creators of the proprietary > firmware-flashing tools "livesuite" and "phoenix" to *also* convert > their tools over to the new proposed idea. Why? > can you provide such a supporting argument which would convince > allwinner to accept the modifications to their working practices that > you propose? It does not really need to be such big modifications to their working practices. Their configuration working practices is all built around the fex file, and the new practices can be 0. Assuming kernel drivers gets ported over to using device tree. 1. Do configuration as you have always done in the .fex 2. Modify the build script to build a device tree from the fex + template, in addition to script.bin. 3. Tell u-boot to load the device tree for the kernel. That's it really. licesuit do not modify script.bin. script.bin is compiled from the .fex at image creation time. A couple more lines in the build script (and a suitable translation tool) and there is also a device tree built and installed and you get a nice and smoot transition. > > Device tree on ARM's goal is to achieve a single kernel across vendors, not > > just a single kernel for a single vendor. > > you'll be aware that i've mentioned a number of times and have > discussed at some length why this is a goal that is completely > impossible to achieve [*1]. sadly. Here I disagree. It is possible. Not across all vendors but a significant share. Regards enrik -- 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/1370468873.18839.22.camel@localhost
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström wrote: > ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton: > >> what we do not want to happen is that they see upstream patches being >> submitted, they merge them into their internal tree (which to date has >> had zero upstream changes: they're currently only just getting round >> to doing 3.4 as we speak), and they *completely* ignore *absolutely >> everything* that's being done by the community, duplicating yet >> another set of device drivers (named drivers/*/sun8i_* and so on). > > Well, that will obviously happen one or two more rounds, a bit depending > on which kernel releases Android will use. But I hope the Allwinner > kernel team will rethink when they hit more current kernels. yyyeahhh. that's the whole point, henrik: i'd like to give allwinner a heads-up *before* that happens, and to also give the linux and sunxi kernel developer teams an opportunity to hear what allwinner would like to see happen (if anything). what i *really* don't want to happen is for them to get a nasty surprise some time around 3.9 or above, along with a hell of a lot of kernel conflicts that cause them to completely abandon the entire current linux directory conventions. or worse, do "find . -name "*sunxi* | xargs git rm" on linux 3.9 [or above] prior to perging in *their* versions. >> this proposal is a start: however what you have to bear in mind is >> that you now have to convince a very busy company that it is in their >> best interests to disrupt their schedule, to drop their existing >> working practices, to tell all their customers "please stop using the >> existing tools and please use these ones instead". > > Why? taking this as a rhetorical question (kinda), what i believe jon proposed would have a knock-on effect of requiring that boot0 and boot1 be converted *away* from script.fex and onto DT. therefore, automatically, all tools must now be converted to understand DT not fex. that includes the (proprietary) equivalents of fex2bin and bin2fex [*1] but, i could be wrong. >> you also need to convince the creators of the proprietary >> firmware-flashing tools "livesuite" and "phoenix" to *also* convert >> their tools over to the new proposed idea. > > Why? > >> can you provide such a supporting argument which would convince >> allwinner to accept the modifications to their working practices that >> you propose? > > It does not really need to be such big modifications to their working > practices. Their configuration working practices is all built around the > fex file, and the new practices can be > > 0. Assuming kernel drivers gets ported over to using device tree. > > 1. Do configuration as you have always done in the .fex > > 2. Modify the build script to build a device tree from the fex + > template, in addition to script.bin. > > 3. Tell u-boot to load the device tree for the kernel. > > That's it really. > > livesuit do not modify script.bin. script.bin is compiled from the .fex > at image creation time. A couple more lines in the build script (and a > suitable translation tool) and there is also a device tree built and > installed and you get a nice and smoot transition. ok: great. so we have something that i can potentially propose to them. now: what reason can i give that they should accept this? what's the biggest incentive for them, here, to make these changes? what would they gain? >> > Device tree on ARM's goal is to achieve a single kernel across vendors, not >> > just a single kernel for a single vendor. >> >> you'll be aware that i've mentioned a number of times and have >> discussed at some length why this is a goal that is completely >> impossible to achieve [*1]. sadly. > > Here I disagree. It is possible. Not across all vendors but a > significant share. time will tell, henrik [i mean that sincerely, not in a trite way]. fortunately as you know (but many people on these various lists may not), with the eoma initiatives [*2], we bypass that possibility, and through hardware standardisation turn an N*M work problem into an N+M+2 work problem (where N is number-of-SoCs and M is number of product types). l. [*1] https://github.com/linux-sunxi/sunxi-tools [*2] http://elinux.org/Embedded_Open_Modular_Architecture -- 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/capweedwrpoycfuwjvf99yua_tbooneeh8uktzvc7dtev6fa...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton: > And Then Some, stephen. there are two versions of u-boot being used: > one is the community-assembled [GPL-compliant] one, and the other > includes a [as-of-a-few-days-ago-but-no-longer, yay!] > formerly-GPL-violating one from allwinner. > > the community-based one *doesn't* have fex integration (i don't > think, but henrik will know for sure), but the allwinner one > definitely does. Correct. > and then there's the boot0 and boot1 loaders, these *do* have > fex integration: they're absolutely tiny and they're designed to fit > into the 1st level cache. the job of these bootloaders is to set up > the DDR3 RAM timings (so that you can access DRAM!!) and to then > decide whether to load from NAND, SD/MMC etc. and many other things. no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM (not cache), but boot1 is on pair with u-boot in size and runs from DRAM. boot0 do NOT read the script.bin at all. It can't, there isn't space fore it. There is tools in the build process that reads the script.bin and adds some information to a header of boot0, but it's irrelevant to the device tree question. Exactly the same can be done from a device tree, or from a fex, it does not matter. even most of boot1 is not using script.bin. The important parameters are all recorded in a heaeder of boot1 when the image is composed using the Allwinner pack tools. Currently based on those tools reading script.bin to prepare the boot1 part of the image. > these boot0 and boot1 loaders are themselves configureable so that > you can specify, through script.fex, what GPIO is to be the "reset > key" and so on. that's a much simplified story btw. No. That info is in the boot0 and boot1 file headers, not script.bin. > so the point is: if anyone wishes me to propose to allwinner that > they convert over to devicetree, or any other proposal which involves > significant low-level changes to their working practices that could > potentially have a massive knock-on effect onto their > multi-million-dollar clients, it had better be a damn good story. Calm down. It isn't really a significant difference to them outside of the kernel. They do not need to change any of their configuraiton methods, only a small toolchain change in how the resultig images are built to have a corresponding device tree built. But it is a fair bit of one-time changes kernel side. And some scratching to figure out how to use/improve/ignore the stuff being mainlined. 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/1370469574.18839.33.camel@localhost
