Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

2013-06-09 Thread luke.leighton
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))

2013-06-09 Thread Russell King - ARM Linux
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))

2013-06-09 Thread luke.leighton
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))

2013-06-08 Thread luke.leighton
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))

2013-06-08 Thread Tomasz Figa
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Dennis Lan (dlan)
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Maxime Ripard
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Luke Kenneth Casson Leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread joem
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))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread Wookey
+++ 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))

2013-06-07 Thread Tomasz Figa
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))

2013-06-07 Thread Ben Hutchings
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Luke Kenneth Casson Leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Thomas Petazzoni
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))

2013-06-07 Thread Olof Johansson
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))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Stephen Warren
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))

2013-06-07 Thread joem

> > 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))

2013-06-07 Thread Lennart Sorensen
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))

2013-06-07 Thread Bjørn Mork
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))

2013-06-07 Thread Henrik Nordström
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-06-07 Thread Barry Song
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))

2013-06-07 Thread Russell King - ARM Linux
On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:
>>   3 days remaining on the clock.
>
> what catastrophic thing will happen when the time runs out?

Maybe the world will explode into tiny small bits?  Probably not.  I
suspect nothing of any relevance to us.

As has already been pointed out, Allwinner is already working with
people in the kernel community to move things forward, so the right
things are already happening.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607091424.gt18...@n2100.arm.linux.org.uk



Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread Russell King - ARM Linux
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))

2013-06-07 Thread Vladimir Pantelic

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))

2013-06-07 Thread Alexandre Belloni
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread luke.leighton
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))

2013-06-07 Thread Vladimir Pantelic

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))

2013-06-07 Thread luke.leighton
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))

2013-06-06 Thread Arnd Bergmann
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))

2013-06-06 Thread Henrik Nordström
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))

2013-06-06 Thread Henrik Nordström
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))

2013-06-06 Thread Lennart Sorensen
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))

2013-06-06 Thread Maxime Ripard
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))

2013-06-06 Thread 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.

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))

2013-06-06 Thread jonsm...@gmail.com
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))

2013-06-06 Thread Olof Johansson
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))

2013-06-06 Thread Theodore Ts'o
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))

2013-06-06 Thread Russell King - ARM Linux
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))

2013-06-06 Thread Russell King - ARM Linux
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))

2013-06-06 Thread Tomasz Figa
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))

2013-06-06 Thread Vladimir Pantelic

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))

2013-06-06 Thread luke.leighton
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))

2013-06-06 Thread Tomasz Figa
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))

2013-06-06 Thread luke.leighton
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))

2013-06-06 Thread luke.leighton
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))

2013-06-06 Thread luke.leighton
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))

2013-06-06 Thread Tomasz Figa
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))

2013-06-06 Thread Mark Brown
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))

2013-06-06 Thread Thomas Petazzoni
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread Tomasz Figa
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))

2013-06-05 Thread luke.leighton
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))

2013-06-05 Thread luke.leighton
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread jonsm...@gmail.com
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))

2013-06-05 Thread jonsm...@gmail.com
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_v“l00...@mail.gmail.com



Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

2013-06-05 Thread luke.leighton
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread jonsm...@gmail.com
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))

2013-06-05 Thread Stephen Warren
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))

2013-06-05 Thread luke.leighton
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))

2013-06-05 Thread Henrik Nordström
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))

2013-06-05 Thread luke.leighton
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))

2013-06-05 Thread Henrik Nordström
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