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-arm-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 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-arm-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 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-arm-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, 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-arm-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))
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-arm-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 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-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1733666.lHUBcfUXq9@flatron
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wednesday 05 of June 2013 23:38:52 Luke Kenneth Casson Leighton wrote: > On Wed, Jun 5, 2013 at 10:52 PM, Tomasz Figa wrote: > > Hi Luke, > > allo tomasz :) > > ok - much of what you say is duplicated by what russell said, so in > effect the same reply is relevant, but there's been some cross-over. > > i'll summarise below and cut all but the key question below: > > I tend to disagree with your view. Is it really our task to convince > > such companies to work with open source community? > > their sheer overwhelming success provides us with mass-volume > ultra-low cost hardware. to not make an effort to accommodate them > would in this specific instance be a huge missed opportunity, > responsibility for which currently falls on the shoulders of the sunxi > community, where that small community is in no way considered > "authoritative" as an upstream source and thus every single GNU/Linux > Distro is left in a position of forcing people to follow insane > non-standard build procedures that are *way* outside of the capability > of the average person. > > so by the linux kernel developers intransigent position, the reach of > free software as a whole is greatly reduced. simple logical > unavoidable conclusion. > > please feel free - linux kernel developers - to maintain this > intransigent position for as long as you find it useful to you to do > so. btw, that is a sincere statement, devoid and completely free of > all and any implicit or explicit additional statements and > implications. OK, this is a large volume of hardware that can be used to run free software, point taken. Still, I wouldn't really bind having this platform fully upstreamed with possibility to run Linux on it. You can take Debian or whatever and just boot it with Allwinner's kernel. Sure, probably distribution people would shout here about upstream kernel being the only supported, but maybe this is the problem, not the lack of support for the platform in upstream kernel? I don't say that having mainline support for this platform wouldn't be nice. Sure, it would. But if the company doesn't want to cooperate and comply to existing rules, I don't think it can be helped. > >> > 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. > > > > I tend to disagree on this as well, but it's another story. Have read > > one of the discussions on this topic and it seemed to look more like > > lobbying for one of the standards being promoted by some company, > > yeahh, that's rather unfortunate. i went to some lengths to avoid > mentioning eoma [*1] until there was a natural point at which it > became difficult *not* to bring it up, not least because i didn't hear > anyone else presenting any actual real workable solutions. > > but, you have to bear in mind a couple of things: > > a) i'm a free software developer and advocate. "business", "lobbying" > etc. do not come naturally to me. my associates scream at me > regularly. > > b) i've been thinking about this incredibly hard problem for at least > 4 years and almost *all* of my background in computing of the past 30 > years leads me naturally towards actually coming up with a solution > > c) i'm actually really, really really and truly going about *actively* > implementing that solution rather than just complaining about it *and* > i'm inviting free software developers to participate, why, because see > first sentence of a) above. Basically there are two possible solutions for this problem. You can either change the hardware to be standardized or make the software handle many different kinds of hardware. Using EOMA would be an example of the former, while our approach with Device Tree represents the latter. Now the key is that Linux is not just about supporting new platforms that are going to show up in near future, but also existing ones, that can't be magically made standardized. This makes it already too late for ARM for such hardware solution, since there is a lot of platforms already not using it. ARM64 would be more appropriate to go this way, but you would have to make sure that all hardware designers adopt the standard (and I'm pretty sure that at some point some low cost hardware design company would do things in their own way anyway, breaking the whole idea, just as Allwinner did to DT wi
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wednesday 05 of June 2013 22:16:37 Russell King - ARM Linux wrote: > On Wed, Jun 05, 2013 at 03:00:13PM -0600, Stephen Warren wrote: > > 2) Having U-Boot itself read a DT and configure itself, just like the > > kernel does. This is relatively new, and only supported by a few > > boards > > (all Tegra to some extent, and a couple each Samsung Exynos and Xilinx > > boards). I suspect/guess this is the kind of thing that Luke was > > referring to re: U-Boot fex integration. > > Reading what I have of this thread, this is just another case of > $company runs of and does their own unique way of doing something, > which is in a totally different direction from that path chosen by > Linux kernel developers, and Linux kernel developers are _expected_ > to roll over and accept $company's unique way of doing it. > > $company could have assisted with the DT effort, helping to sort out > the common arch issues (which haven't been all that much), converting > drivers to DT and such like. But no, instead they've gone off and > created their own thing. > > I wonder how many more of these cases there needs to be before people > get the message that Linux kernel developers *do* *not* like this > behaviour, and if you do this, then chances are you're going to be > stuck with having code which isn't able to be merged into mainline. > > And I don't buy the argument that we were still sorting out DT. DT has > been well defined for many many years before we started using it on ARM. > It has been used for years on both PowerPC and Sparc architectures to > describe their hardware, and all of the DT infrastructure was already > present in the kernel. What was left for us were: > > * converting our platform-data based drivers to use data from DT. > * come up with ways of dealing with SoC issues such as clock > representation, pin muxing and such like in DT. > > But no... all that had to be created in this custom fex stuff which now > presents a barrier with getting support for something merged. > > And somehow people make out that this is _our_ problem... Well said. And the problem is that this is not the first and probably not the last such case. Best regards, Tomasz -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1494529.ijR1yO8EGg@flatron
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wednesday 05 of June 2013 16:48:27 jonsm...@gmail.com wrote: > On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton > > wrote: > > On Fri, May 31, 2013 at 3:52 AM, Ben Hutchings wrote: > > > The 3.8.y branch is over, so I think we have to move to 3.9, ready > > > or > > > not. I merged the work in progress from trunk to sid and am going > > > through the config changes at the moment. > > > > > > I'm rather disappointed that nothing at all has been committed by > > > ARM > > > porters to either branch in the last month. > > > > *sigh* i didn't want to leave this as it stood, ben, purely for the > > > > reason that i don't want to see you discouraged! but, i also had to > > think a bit about what potentially to say. > > > > the one SoC family that's going to become increasingly important to > > > > have both upstream and in debian is support for allwinner's > > processors. with 40% world-wide tablet market share [*0], they must > > be doing something right, and it's basically getting a staggering > > price-performance value as well as having a set of interfaces and > > level of integration that is really second to none. > > > > to begin to describe the problem in getting allwinner soc source code > > > > upstream is this: not only do we have the usual "let's get it out the > > door as fast as possible" learning curve of a very young, very new and > > bewilderingly-successful fabless SoC company, but we also have a > > completely new type of very successful and comprehensive > > device-tree-like dynamic configuration system to deal with, which > > allwinner have called "fex" [*1]. > > > > basically at the time when device-tree was being thought of, > > > > allwinner needed something that they could *right then* - not waiting > > for developers to finish device-tree - they needed to be able to > > reconfigure their customer's kernels *without* needing a recompile. > > so they invented the script.fex system, which is a simple config.ini > > file-format, compile it to binary, and get the bootloader to upload it > > to memory and read it. > > Why don't you try converting the sunxi code over to device tree? I > don't think it will be as hard as you may think it is. Start off by > mapping the existing fex syntax into a DTS file. Send your DTS file to > devicetree-discuss to get help with the correct syntax. Once this DTS > template is constructed you can write a program to convert any fex > file into it. > > Now boot with this DTB; that will get all of the existing info into > the kernel's internal FDT. Then start converting your drivers over to > use the of_ support for accessing the FDT. You've already done all of > the hard work in making the drivers configurable at boot. As a > transition tool allow the kernel to boot with both fex and DT untill > you get all of the drivers converted. > > BTW, device tree has been in the kernel since 2007 (or earlier). > About two years ago the ARM community decided to switch all new > development onto it in order to stop the proliferation of > platform/machine files. I believe the rule about no new non-DT ARM > platforms has been in place for over eighteen months. Well, it not only has been in the kernel, but has been extensively used for PowerPC. Not even saying that the idea started even earlier, originating from OpenFirmware. Allwinner has just reinvented a wheel, without even considering the fact that it has been already invented. This is actually not so uncommon plot, because for such companies it is often easier to develop (or hack up) a completely new solution without any supervision, than to extend an existing solution that would need cooperation with community and (whoaa) being compliant with open source policy. IMHO this is completely wrong and can't be justified. Not even saying about adopting such solution now that we already have a standard and widely accepted one, which they could have used as well. Best regards, Tomasz -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3619282.JgdgeGHudI@flatron
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hi Luke, On Wednesday 05 of June 2013 22:15:08 Luke Kenneth Casson Leighton wrote: > [i've just received word, please remove debian-release from > discussions!] > On Wed, Jun 5, 2013 at 9:46 PM, jonsm...@gmail.com wrote: > > Why don't you try converting the sunxi code over to device tree? > > ok. perhaps i wasn't clear. whatever is proposed has to be be > acceptable to allwinner, and i'm looking for proposals that i can put > to them, i.e. i am going to act as the communications channel to them. Well, device tree is the only method of hardware description supported by Linux kernel on ARM at the moment (except for board files, but this is deprecated). I don't see why it should change, considering the fact that device tree is generic, extensible and described by standards. There is no place for any proprietary solutions here. > 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). This is mostly their problem. If they don't care about work duplication on their side then why bother? > > I don't > > think it will be as hard as you may think it is. Start off by mapping > > the existing fex syntax into a DTS file. Send your DTS file to > > devicetree-discuss to get help with the correct syntax. Once this DTS > > template is constructed you can write a program to convert any fex > > file into it. > > 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". I'm not sure if I followed all the discussion (read http://thread.gmane.org/gmane.linux.debian.devel.kernel/91136/focus=92096 which didn't seem to contain anything relevant), so I might not have the full picture, but I'm going to put my two cents in. I tend to disagree with your view. Is it really our task to convince such companies to work with open source community? If they don't see the benefit of doing so, then IMHO it's their loss and loss of their customers and end users. There are so many vendors backing open source at the moment and they somehow don't have problems like this. > 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. > > so if that is to truly be accepted, it has to be framed in such a way > that it will be clearly of financial benefit to the SoC vendor. > > can you provide such a supporting argument which would convince > allwinner to accept the modifications to their working practices that > you propose? There is one, very simple. If they don't, there is no community cooperation for them, that's how it works. There is a set of unwritten (or maybe even written) rules of open source communities that you must obey if you want to work with them and you can't just get over that, because some company don't want to change their practices. Just see how many companies are backing open source at the moment, without making problems like this. They have understood the benefits and taken the effort to change their practices, because it was worth it. (I'm working for such company at the moment and I can assure you that this is the case.) > > 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. I tend to disagree on this as well, but it's another story. Have read one of the discussions on this topic and it seemed to look more like lobbying for one of the standards being promoted by some company, not anything really close to the reality (where we can already successfully run multiplatform kernels on platforms of different vendors...). Best regards, Tomasz -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19865137.ey1FePPnmD@flatron
