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

On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com wrote:

 4 days? WTF? since when did setting an ultimatum to the kernel
 community work?

 i was only informed of the opportunity 2 days ago, vladimir.  this is
an important meeting.  of course the linux kernel community is
entirely free to:

* completely ignore this opportunity
* continue to complain that soc vendors do not follow their
unilaterally-decided rules
* to continue to its chosen course of making unilateral decisions and
setting unilaterally-decided rules and to experience the consequences.

 i'm extremely busy, vladimir, and i'm acting as the messenger here.

 3 days remaining on the clock.

l.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capweedwr_nwusi-j53m8muoav1rxm4wnnxtrioa2cjndyqe...@mail.gmail.com

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

2013-06-07 Thread Vladimir Pantelic


luke.leighton wrote:

On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com wrote:


4 days? WTF? since when did setting an ultimatum to the kernel
community work?


  i was only informed of the opportunity 2 days ago, vladimir.  this is
an important meeting.  of course the linux kernel community is
entirely free to:

* completely ignore this opportunity
* continue to complain that soc vendors do not follow their
unilaterally-decided rules


SoC vendors are free to join the discussion, and many SoC vendors are 
part of the kernel community, so calling this unilateral is plain wrong.



  3 days remaining on the clock.


what catastrophic thing will happen when the time runs out?



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b19046.5040...@gmail.com

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

On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa tomasz.f...@gmail.com
wrote:
Luke,

On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com

wrote:
I don't see any other solution here than moving all the Allwinner
code
to DT (as it has been suggested in this thread several times
already), as this is the only hardware description method supported
by ARM Linux.

i repeat again: please state, explicitly and unequivocably that you
-

linux kernel developers - are happy that the reach of linux and
gnu/linux OSes is dramatically reduced due to this intransigent
position.

or, tomasz, please state that you, tomasz, represent each and every

one of the linux kernel developers so that i do not need to keep
asking.

I do not represent all linux kernel developers by any means. I am just
stating current policy of SoC/board support maintained by ARM Linux,
which is common for all Linux kernel devlopers, or at least ARM Linux
kernel developers.

Personally I am happy with numerous companies backing this policy and
not making problems like this with Allwinner and I am really
surprised that you are supporting a troublesome company like this.

you've not read what i've written tomasz.

I have.

There are many other SoC vendors making low cost SoCs, like Rockchip,
Boxchip,

boxchip *is* allwinner.

Right, sorry. I am not really into this low cost hardware.

i've been tracking it for several years.

There is also AMLogic, though.

they're *definitely* GPL-violators.

Telechips. Maybe they would be better candidates for being
promoted as vendors of choice for hardware running free software?

no, because they're not selling at a low-enough price with
high-enough integration. telechips and rockchip don't have the market
penetration.

I do not have access to any numbers, so I am left to believe in what you
say.

well... none of us do :) that report (was it from IDC? it was in
earlier messages) is a good analysis.

(Although here in Poland the cheap tablet market is almost evenly
divided between all those companies, you can find almost same amount of
tablets based on SoCs from each vendor.)

most likely.

allwinner is the one that's actually expressed an interest, at
Director (Board) Level, of being GPL-compliant. the software
engineers understand that; their immediate Manager does not [and is
causing considerable disruption].

AMLogic stone-walled and cost us money and a large client due to
their GPL violations. which they till have not resolved [in over 2
years]. i will not work with them, ever again.

Telechips are korean-based: they haven't responded to communications.

Nufront got themselves in a muddle [late on silicon] so we ruled them
out - we'll come back to them later.

there's a number of others, but allwinner's the only one that is
actively communicating.

so.

coming back to what you said earlier: i'm formulating what to say to
allwinner [and need to pre-send something by monday so that they can
consider it before the meeting]. so far, it consists of:

* device-tree is what the linux kernel community has come up with, it
is equivalent to FEX.

* the linux kernel community would like to apologise for not
consulting with you (allwinner) on the decision to only accept device
tree

[bear in mind that if this kind of thing isn't said, they risk just
continuing to make the sunxi community's life absolute hell by
continuing to work in isolation and continuing to duplicate drivers
etc. etc. ]

* work is being done by the free software community, they are
beginning to integrate allwinner's work into the upstream kernel, and
you (allwinner) will begin to see this when you get round to doing
linux kernel 3.9

* allwinner and the linux and sunxi community therefore need to work
closer together, we propose:

* {insert proposals here}

3 days left on the clock.

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDx_1fvAv9sROtPreoyyj_yDAuYb040fM2zPc+tf22d=y...@mail.gmail.com

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

On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:

If companies are going to go off and invent the square wheel, and that
makes *them* suffer the loss of being able to merge back into the
mainline kernel, thereby making *their* job of moving forward with
their kernel versions much harder, then yes, we *are* happy.

russell: they have more employees than sense :) they also don't have
any idea of what they *should* be doing, so this is an opportunity to
educate them.

they're not feeling any pain: they just employ more chinese
developers and substitute bodies for time and common-sense.

also, in this particular case, thanks to their script.fex system when
i said they only need to develop one kernel and one u-boot i really
wasn't kidding around: they really have got to the point which
everyone else dreams of with device-tree [admittedly by limiting the
product range that their clients can play with, but that product range
has huge returns, so they're still happy].

Companies will always do idiotic things; it's *them* and their users
who have to live with the results of that bad decision making process.

russell: the decision process they've made is actually an extremely
effective one.

Eventually, the pain of being outside the mainline kernel will become
too great, especially if their users demand things like kernel upgrades
from them. Eventually, they will change.

And no, this isn't an intransigent position. This is reality given
that ARM already has way too much code in the Linux kernel and we're
trying to reduce that through the use of technologies like DT. The
last thing we need right now is for another DT like implementation
to come along which is only used on a minority of platforms - even if
the platform it is used on is successful.

The way this works is this:
- you either go with the policies which are set, or

which they weren't consulted on, it has to be pointed out.

- you change the policy as a whole because you have a technically
superior solution

i believe they have a technically more *successful* solution. whether
it's more appropriate in a wider context is another matter.

here we have a key to the crux of the problem: the linux kernel
maintainers have to cater for _everyone_. with no funding or
incentive from the major contributors to work with them. hmmm

What that means in this case is either you adopt DT, or you convince
everyone that DT isn't the solution, but your solution is, and we adopt
your solution for *everything* instead.

If neither of those are possible, then that's really not our problem,
and it's not _us_ who are being intransigent.

indeed.

ok. so. we come back to the question again: what shall i propose to
them that they consider doing, and what benefit would it be to them to
do so?

i cannot go to them and say you have to do this [insert proposal
here] - it has to be more subtle than that.

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDyYt+pN+UaFuqWL5RrHpyuq_4So-tArmx3dr=0wls+...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic vlado...@gmail.com wrote:
luke.leighton wrote:

On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic vlado...@gmail.com
wrote:

4 days? WTF? since when did setting an ultimatum to the kernel
community work?

i was only informed of the opportunity 2 days ago, vladimir. this is
an important meeting. of course the linux kernel community is
entirely free to:

* completely ignore this opportunity
* continue to complain that soc vendors do not follow their
unilaterally-decided rules

SoC vendors are free to join the discussion, and many SoC vendors are part
of the kernel community, so calling this unilateral is plain wrong.

you're free to believe that, vladimir. i've explained why that
hasn't happened, in prior messages. can we move forward, please?

3 days remaining on the clock.

what catastrophic thing will happen when the time runs out?

no catastrophe, vladimir: all that happens is that an opportunity is
lost, and the result of that is that the situation remains as it is,
with a major soc vendor being divorced from and isolated from the free
software community, who will continue to have to shoulder the
frustrating and isolated burden of responsibility of reworking
over-the-fence kernel patches as best they can with the limited
resources that they have.

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/capweedxfwcv7hsduo6uc751iipg9ngdqc5ub7mbxwbespwf...@mail.gmail.com

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

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 vlado...@gmail.com wrote:
 luke.leighton wrote:
   3 days remaining on the clock.

 what catastrophic thing will happen when the time runs out?
  no catastrophe, vladimir: all that happens is that an opportunity is
 lost, and the result of that is that the situation remains as it is,
 with a major soc vendor being divorced from and isolated from the free
 software community, who will continue to have to shoulder the
 frustrating and isolated burden of responsibility of reworking
 over-the-fence kernel patches as best they can with the limited
 resources that they have.

I think the question was: what will be done in 3 days that cannot be
undone ? and you didn't answer that. I don't understand why your are
still stating that Allwinner will never be able to get code in the
mainline after Olof and Maxime told you that they are already working,
at least discussing with them.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b19769.4060...@free-electrons.com

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

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

On Fri, Jun 07, 2013 at 09:02:43AM +0100, luke.leighton wrote:
  ok.  so.  we come back to the question again: what shall i propose to
 them that they consider doing, and what benefit would it be to them to
 do so?
 
  i cannot go to them and say you have to do this [insert proposal
 here] - it has to be more subtle than that.

It seems that you don't have to do anything at all.  From what Arnd and
others have said, they are _already_ talking to, and working with people
in the kernel community to move their code base forward, move to DT, and
they are already starting to send their own patches for the mainline
kernel themselves.


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

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

On Fri, Jun 07, 2013 at 10:40:37AM +0200, Vladimir Pantelic wrote:
 luke.leighton wrote:   so.
 
coming back to what you said earlier: i'm formulating what to say to
  allwinner [and need to pre-send something by monday so that they can
  consider it before the meeting].  so far, it consists of:
 
  * device-tree is what the linux kernel community has come up with, it
  is equivalent to FEX.
 
  * the linux kernel community would like to apologise for not
  consulting with you (allwinner) on the decision to only accept device
  tree

 apologize? WTF?

(I don't seem to have the original mail).

Definitely not.

The way this generally works is that discussions happen in public on
mailing lists, and people who have an interest get involved in the
discussion.  If someone decides to avoid the mailing lists because they
want to be secret about XYZ then they won't be part of the decision
making process - but that's not _our_ problem.  That is _their_ problem.

In the case of DT, there was quite a lengthy discussion about it and
its adoption.

So, either the discussion took place _before_ there was any interest in
the ARM kernel developments from Allwinner, or they themselves _chose_
not to be represented in the discussion by not being on the mailing list
or participating in the discussion.

There is nothing for us to apologise for here.

(Occasionally, the kernel community *is* a dictatorship - for example,
when Linus threatens to delete all the ARM defconfigs, or when Linus
decides that we're running out of control when adding more than 10k
lines of new code per kernel release, or - in the same way - when I see
something I really don't like, but thankfully those are fairly rare.)


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

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

On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote:
 luke.leighton wrote:
   3 days remaining on the clock.

 what catastrophic thing will happen when the time runs out?

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

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


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

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

2013-06-07 Thread Barry Song

2013/6/7 Olof Johansson o...@lixom.net:
On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com jonsm...@gmail.com wrote:
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com
wrote:
augh. ok. solutions. what are the solutions here?

Luke if you really want to fix this a good solution is to have
Allwinner join Linaro and provide an engineer to the Linaro effort.
That engineer will get educated on the right way to do kernel
development and he can pass that knowledge back to Allwinner each day
as he learns it.

There's no need for anybody to join Linaro to contribute upstream.
That's a crazy notion.

i do agree. i don't think there is any direct relationship between
linaro and upstream.
otherwise, we will be in pain as we are not linaro member too.

Listen, Allwinner isn't working in a vacuum, believe it or not. I've
talked to them, so has Arnd and other people working on ARM, including
Maxime Ripard, who's been reimplementing upstream support for their
platform. Everybody is interested in the right things happening, it's
just a matter of figuring out how to do it. The right people are
already talking.

Allwinner has expressed interest in the past in joining Linaro but the
price was too high. I believe there are cheaper options now for
joining. The benefits Allwinner receives from joining will far exceed
the cost of joining. The net result will likely be a reduction in the
amount they need to spend on in-house development since they will
learn how to better leverage other developer's work.

Uh, you're listing the benefits of doing upstream work, not of joining Linaro.

-Olof

thanks
barry

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAGsJ_4wKgJTwZnJm7UEUVcNYLrWfWu1Gi0=09jqq1uxchj5...@mail.gmail.com

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

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 Bjørn Mork

Tomasz Figa tomasz.f...@gmail.com
writes:

 Seeing from your posts you don't have any knowledge on how Linux kernel 
 development works and even on how Allwinner's cooperation with our 
 community looks (and seem to be completely closed to our effort of showing 
 you the reality), so I'm not sure if you are the right person to take any 
 of those roles...

Try googling for Luke Leighton troll.  The pattern is some lengthy
semi-technical post, followed by very long threads with no substance
whatsoever.  It seems like some sick joke trying to waste as much time
for as many people as possible.

He's even become an -ENOPATCH example:
http://linuxmafia.com/~rick/lexicon.html#enopatch


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li6mxlcr@nemi.mork.no

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 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 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
 li...@arm.linux.org.uk wrote:
 
 If companies are going to go off and invent the square wheel, and that
 makes *them* suffer the loss of being able to merge back into the
 mainline kernel, thereby making *their* job of moving forward with
 their kernel versions much harder, then yes, we *are* happy.
 
  russell: they have more employees than sense :)  they also don't have
 any idea of what they *should* be doing, so this is an opportunity to
 educate them.

You know, they're probably reading this thread, and if not, they
certainly can in the list archives. It's probably not a good idea to
slag them off like that, and like other comments in this thread...


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b218bf.60...@wwwdotorg.org

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

On Fri, Jun 7, 2013 at 9:18 AM, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
On 07/06/2013 10:06, luke.leighton wrote:
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic vlado...@gmail.com wrote:
luke.leighton wrote:
3 days remaining on the clock.

what catastrophic thing will happen when the time runs out?
no catastrophe, vladimir: all that happens is that an opportunity is
lost, and the result of that is that the situation remains as it is,
with a major soc vendor being divorced from and isolated from the free
software community, who will continue to have to shoulder the
frustrating and isolated burden of responsibility of reworking
over-the-fence kernel patches as best they can with the limited
resources that they have.

I think the question was: what will be done in 3 days that cannot be
undone ? and you didn't answer that.

apologies for not being clear. there is nothing that cannot be
undone. i trust that that answers the specific question you've
asked.

let me try to put it into undo words.

this is about me (a messenger) offering you plural (the linux kernel
community) an opportunity to undo the
mess-that-is-perceived-to-be-the-case wrt one specific SoC vendor,
named Allwinner.

let me try to put it another way. i cannot specifically state
EXACTLY what will be done, because i do not have authorisation to
make that publicly known. i am trying hard to hint at what can be
done, and the deadline is monday 10th june 2013 to get a clear
proposal in which will make its way to allwinner, by means that i
cannot specifically tell you about because i do not have the specific
authorisation or permission to tell you.

does that point you in the right direction?

can we please get on with taking advantage of this opportunity and
discuss options that can be presented, instead of asking these kinds
of questions?

I don't understand why your are
still stating that Allwinner will never be able to get code in the
mainline

i didn't say that. apologies if that wasn't clear.

after Olof and Maxime told you that they are already working,
at least discussing with them.

apologies, i missed that. there's a lot i need to get up-to-speed,
in very little time. i have some keywords to search for now i'll go
find those messages.

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDy3hCvusHvWMBki0ak=se51rtu-1wyid3hawoqut8w...@mail.gmail.com

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

thomas i _very_ briefly spotted this when i was extremely busy
yesterday, and i'm grateful to the 2 or 3 people who've given me the
keywords and/or links to catch up.

On Thu, Jun 6, 2013 at 10:27 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Dear Tomasz Figa,

On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote:

I don't see any other solution here than moving all the Allwinner
code to DT (as it has been suggested in this thread several times
already), as this is the only hardware description method supported
by ARM Linux.

Have you noticed that it is already the case in mainline?

i knew there was a little bit, but not the extent of the commits.

My colleague Maxime Ripard (Cc'ed)

maxime: we need to talk :)

please tell me in 4 or 5 sentences what you've managed to do so far,
expanding a little on what thomas says below, more specifically what
it achieves and/or allows rather than technically what it does
(suitable for managers and directors in other words), and what plans
you'd like to see happen.

is the maintainer of the mainline Allwinner sunxi
effort. It already supports a number of boards, has a pinctrl driver, a
GPIO driver, serial port is working, network is working, I2C is
working.

All in mainline, completely Device Tree based.

great. which version did it first hit, i.e. what will the first
signs of this be when allwinner begin doing git pulls?

and which boards. bear in mind that one of those boards should
really be the total range of products available across hundreds of
chinese tablet clone manufacturers.

specific question: is one of the boards the one that tom cubie
submitted, which covers virtually every android tablet product
manufactured in the millions by chinese tablet clone manufacturers?

So isn't this entire discussion completely moot?

no because it's totally in isolation from allwinner. i need to give
them a heads-up, and get them involved, giving them specific
incentives [which nobody's yet given!!] for following a particular
path [or paths] yet to be recommended.

The mainline support
for sunxi has already started since 6 months or so, and has been Device
Tree based from day one.

to clarify: the *community-driven* mainline support for sunxi. ok -
which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
(Dual-Core Cortex A7)? which ones are in?

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDzW60poOYahm31aW3_A=nvzmybpppgm9pzdvupjnju...@mail.gmail.com

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

On Fri, Jun 07, 2013 at 02:49:28PM +, joem wrote:
   SoC vendors are free to join the discussion, and many SoC vendors are part
   of the kernel community, so calling this unilateral is plain wrong.
  
   you're free to believe that, vladimir.  i've explained why that
  hasn't happened, in prior messages.  can we move forward, please?
 
 I prefer it if the vladimir troll (and fellow trolls)
 make requests for one of us to make or do something instead of
 constantly whining and wasting time.
 
 After all we are attached to funds and resources ready to
 deploy if something sounds a good idea and gets a vote.
 
 To vladimir - please put your thoughts in a blog where it belongs.
 If its important, I'm sure others would offer comment
 and take you up on your thoughts.

I think your position is confused.  Everything that Vladimir (in his
three posts) in this thread so far have been correct.  Vladimir is not
the one doing any trolling in this thread.

Vladimir has not requested anything.  He hasn't whined.  He hasn't
wasted time.  He has stated the following in _three_ short succinct
emails:
(a) no one gets to impose stipulate timescales unless they're willing
to financially sponsor the work.
(b) the adopted position of the Linux kernel developers.

Luke Leighton on the other hand is demanding that we (Linux kernel
developers) come up with proposals within three days so that Luke can
act as a middle man between us and Allwinner, and is blaming the Linux
kernel community for the situation with Allwinner.

As you seem to have your facts wrong, I can only conclude that you
are also trolling... I hope I'm wrong about that and you've just made
an innocent mistake.


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

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

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 luke.leigh...@gmail.com wrote:
   but the Directors of Allwinner aren't been kept in the loop,
 here: that's my job, to get them up-to-speed.

The one job I would love for you to do instead of all this trolling
and time-wasting that's being done by _everybody_ involved, is to just
extract yourself from the situation and let us go on with our work.
You're causing nothing but confusion and extra work. Literally. You
represent nobody that matters in this discussion.

By demanding us to spend time and effort bringing you personally up to
speed on a subject that both we (ARM kernel community) and them
(Allwinner) are already having discussions about, it's nothing but a
distraction and waste of energy.

And yes, Allwinner knows about this public email thread.


Thanks.

-Olof


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoesgmg+xk5yy2w3n__qyekrxb5fp6eruowvzpnhkovhf2+...@mail.gmail.com

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

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

On Thu, Jun 6, 2013 at 5:00 PM, Olof Johansson o...@lixom.net wrote:
On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com jonsm...@gmail.com wrote:
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com
wrote:
augh. ok. solutions. what are the solutions here?

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

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]

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/capweedwu+rztcgb20uh7jxazjbrx_yhva4sy_atr7mwpbb4...@mail.gmail.com

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

On Thu, Jun 6, 2013 at 6:28 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:

 I should also add that Allwinner not only talked to us already,

 oo!  great!  can you please [privately, not publicly] let me know who
that is, so i can let the Directors know, so that they can follow up?

 but also
 expressed interest in doing actual modern kernel development (like using
 recently introduced kernel frameworks, like the clk framework).

 awesome.

 I've received patches from them already for private reviews, they began
 to show up on the kernel mailing lists, they asked to be CCed on the
 patches I send upstream, they're even the one that reached out to me
 when the early support for their chips was released. So, like Olof said,
 they aren't in a vacuum, they are very aware of the mainline kernel and
 speak a decent english.

 good!  next thing you know they'll be writing comments in english too [*1]

 So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
 inferior (because not generic enough) to the device tree, but they show
 interest on going down the mainline road.

 yes.  i'm coming at this from the other end, via the top management,
so that this is properly coordinated.

 so.  reminder.  and question.  what needs to be done, and what are
the benefits?

 l.


[*1] 
http://git.rhombus-tech.net/?p=linux.git;a=blob;f=drivers/usb/sun7i_usb/manager/usb_manager.c;h=3775c83134efee9694789b68e85010ebc0d9938b;hb=refs/heads/lkcl-3.3-a20#l274


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAPweEDyg11k++gunqVQkbwi_-MvhexAX6Z_kjM=3rfbi7qn...@mail.gmail.com

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

On Thu, Jun 6, 2013 at 9:22 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 06 June 2013, Maxime Ripard wrote:
So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
inferior (because not generic enough) to the device tree, but they show
interest on going down the mainline road.

Right, and of course there is nothing special about that, everybody starts
out with they own even vendor tree (c), and as hardware support gets merged
upstream, the diff gets smaller, even though the code in the mainline
kernel is normally very different from what they started out with.

*sigh* except if that idiot manager [whom we're keenly aware of]
orders them to delete absolutely everything (find . -name '*sunxi*' |
xargs git rm) and overwrite it with their internally-managed tree,
causing absolute mayhem in the process...

Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may
end up being the first modern one that is fully supported upstream including
a GPU driver, since it is one of the obvious targets for the
reverse-engineering efforts.

yes. http://libv.livejournal.com/24735.html

Ironically (given NVIDIA's reputation), the
Tegra platform is the strongest competitor I see in that race at the moment.

at $7.50 for a dual-core processor, and i am *not* going to tell you
the quad-core price, i don't believe it can be considered to be a
race, or even a competition. they're *OUT*, man. really.

oh wait - did you mean for 1st to have fully supported upstream GPU
driver? that would be veery nice.

For all I can tell, things are progressing nicely, given that it's currently
a volunteer effort. If anyone needs things to move faster, I'd recommend
them to send money to free-electrons.com.

i'll put that on the list of recommendations, but - again - i need a
list of clear benefits and returns as to why that should happen.

--
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 Kenneth Casson Leighton

On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 Luke Leighton on the other hand is demanding that we

 no demands have been made, russell: i've informed you of an immovable
deadline which will pass beyond which the opportunity being presented
is lost.

 (Linux kernel
 developers) come up with proposals within three days so that Luke can
 act

  is *going* to act, regardless of how well people deal with the
time limitations and my own communication limitations

 as a middle man between us and Allwinner, and is

  not ...

  blaming the Linux
 kernel community for the situation with Allwinner.

 As you seem to have your facts wrong, I can only conclude that you
 are also trolling... I hope I'm wrong about that and you've just made
 an innocent mistake.

 please continue to assume that i am making mistakes [under time
pressure]: you'd be right.  i never understand this word troll and i
haven't got time to discuss its meaning.

 greatly appreciated efforts to correct my misunderstandings and
mistakes so that i'm properly prepared - ready or not - for the
meeting ahead.

l.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capweedxxnrwyk4ghskn-pzm1hlozpid1mune1q-4ft6pjrj...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa tomasz.f...@gmail.com wrote:

Seeing from your posts you don't have any knowledge on how Linux kernel
 development works

 check back to 2004.

 and even on how Allwinner's cooperation with our
 community looks (and seem to be completely closed to our effort of showing
 you the reality),

 no - just f*g busy, tomasz

 so I'm not sure if you are the right person to take any
 of those roles...

 well, tough.  get me up to speed, *fast*.  please stop wasting time
like this: get me up to speed.  i may not be the best person but i am
in the right place at the right time, and nobody else is going to be
able to step into this role in time.

 so i may not be the best person that you *think* i am, but i'm the
person you've got.  time's ticking.  can we get on please?

 I'd suggest Maxime Ripard or someone else from Free Electrons to be
 responsible for communication with Allwinner instead.

 you're welcome to suggest, however they do not have the contacts that
i have (many of which are indirect anyway), and i am not going to
introduce him to them either, in case they jeapordise the critical
business relationships that took my associates 4 years to establish.

 l.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAPweEDwmgr2JbH+txDDjR_gDA2R2C1v=auvcuvts7rrimhz...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson o...@lixom.net wrote:
 Luke,

 I want only one thing from you at this time. See below.


 On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton luke.leigh...@gmail.com 
 wrote:
   but the Directors of Allwinner aren't been kept in the loop,
 here: that's my job, to get them up-to-speed.

 The one job I would love for you to do instead of all this trolling
 and time-wasting that's being done by _everybody_ involved, is to just
 extract yourself from the situation and let us go on with our work.
 You're causing nothing but confusion and extra work. Literally. You
 represent nobody that matters in this discussion.

 absolutely correct.  i am nobody, who is in the right place at the
right time.  i'm just a messenger.  so - what message do you wish to
take to the Directors of Allwinner (if any).

 By demanding

 a-a-ah, no demands made.

 us to spend time and effort bringing you personally up to
 speed on a subject that both we (ARM kernel community) and them
 (Allwinner) are already having discussions about, it's nothing but a
 distraction and waste of energy.

 And yes, Allwinner knows about this public email thread

 that's good!


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAPweEDzeyJh+DKX=8tzrt9ang9nqlp8nwkwfmb2wy+jnbkq...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 7:57 PM, Wookey woo...@wookware.org wrote:
OK, this sounds good. Could you say who the allwinner engineers are?

[cross-over: i asked him if he'd be happy to let me know privately,
so i have at least some context when speaking to the Directors]

I
guess it's quite a large organisation, so if Crazy Luke can say 'the
work of mainline integration using device-tree is already being done
by $these $people, please talk to them to help move it along', that
might help get everyone on the same page.

*mull*, *mull*... yes exactly!

If it's like many large organisations, some bits of it will 'get it'
and see why, in the long term, mainline integration is worthwhile, but
other bits will look at what they have now and their android focus,
and decide it's easier to keep doing what they are doing.

There is a lot of hardware using these socs, and I'd love to be able
to use that with mainstream stuff, rather than random vendor piles,
and specific android kernels, so anything we can do to help make that
happen is good.

So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
inferior (because not generic enough) to the device tree, but they show
interest on going down the mainline road.

So, luke: mainline is not going to support fex directly, whatever you
or allwinner do. The advantages to allwinner of working with mainline
are:
1) Ability to use whatever (kernel supported) hardware they like with
new designs, with no driver work
2) Ability to use latest kernels and thus whatever shiny goodies those
include
3) No need to do fex-ready drivers for new hardware
4) No need to keep backporting new kernels to add fex integration
forevermore

hooray - thank you wookey, this is exactly what i need.
cut/paste, straight into the report.

If they want to keep existing tools and fex workflow then a fex-DT
translation tool will be needed.

in-kernel or external tool?

(It's not clear to me to what degree
DT can simply be used instead directly)

TBD. input here, anyone?

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAPweEDw3_M_5e_B2HueCNcfXjO9_4_oiCJuEfTERetyoOx=+v...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Hello,

On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:

Have you noticed that it is already the case in mainline?

i knew there was a little bit, but not the extent of the commits.

Then you could probably use a bit of your time to read the kernel
commit logs rather than writing hundreds of e-mails, no?

not now, thomas. i need summaries. bear in mind i type faster than
i can read/find. very very grateful for your summaries, it's exactly
what i need.

My colleague Maxime Ripard (Cc'ed)

maxime: we need to talk :)

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?

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.

--
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 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
 li...@arm.linux.org.uk wrote:
  Luke Leighton on the other hand is demanding that we
 
  no demands have been made, russell: i've informed you of an immovable
 deadline which will pass beyond which the opportunity being presented
 is lost.
[...]

Would that be the opportunity for you to pose as an intermediary
between the Linux community and Allwinner, which you failed to realise
was a completely redundant position?

If not, please explain what you are actually hoping to do, and why
anyone should care.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607193104.ge4...@decadent.org.uk

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

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 tomasz.f...@gmail.com 
wrote:
 Seeing from your posts you don't have any knowledge on how Linux kernel
 
  development works
 
  check back to 2004.

$ git log --oneline --author=Luke Kenneth Casson Leighton | wc -l
0
$ git log --oneline --author=l...@lkcl.net | wc -l
0
$ git log --oneline --author=Luke Leighton | wc -l
0

That's an -ENOPATCH for me.

  and even on how Allwinner's cooperation with our
  community looks (and seem to be completely closed to our effort of
  showing you the reality),
 
  no - just f*g busy, tomasz

Just like many of us, I guess.

  so I'm not sure if you are the right person to take any
  of those roles...
 
  well, tough.  get me up to speed, *fast*.  please stop wasting time
 like this: get me up to speed.  i may not be the best person but i am
 in the right place at the right time, and nobody else is going to be
 able to step into this role in time.
 
  so i may not be the best person that you *think* i am, but i'm the
 person you've got.  time's ticking.  can we get on please?
 
  I'd suggest Maxime Ripard or someone else from Free Electrons to be
  responsible for communication with Allwinner instead.
 
  you're welcome to suggest, however they do not have the contacts that
 i have (many of which are indirect anyway), and i am not going to
 introduce him to them either, in case they jeapordise the critical
 business relationships that took my associates 4 years to establish.

Well, I'm quitting this discussion right now, as it doesn't seem to be of 
any use or might be even counter-productive. I have already showed my view 
on this matter (and even given you some proposals for them), got it 
confirmed by several other people and got nothing from you that could make 
me reconsider anything.

Thank you for your time.

Best regards,
Tomasz


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1506423.MBs7Fu8QWI@flatron

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

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

On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
 On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson o...@lixom.net wrote:
  By demanding
 
  a-a-ah, no demands made.

 well, tough.  get me up to speed, *fast*.  please stop wasting time
like this: get me up to speed.

That is a demand.  Stop trolling.


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

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

On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
  well, tough.  get me up to speed, *fast*.

No, not unless you're willing to *pay* someone to spend time teaching you,
because you are asking to be *taught* about the current situation, so
you're asking someone to do some _work_ _for_ _you_.  If you're not
willing to do that, then all the information is out there in the public
domain for you to learn from yourself.

 please stop wasting time like this:

Pot. Black.


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

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

On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
 On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  Luke Leighton on the other hand is demanding that we
 
  no demands have been made, russell: i've informed you of an immovable
 deadline which will pass beyond which the opportunity being presented
 is lost.

 well, tough.  get me up to speed, *fast*.  please stop wasting time
like this: get me up to speed.

That is a demand.  On the other hand this would not be:

Can someone please get me up to speed on this?  That is a request.

Sorry, you've just lost some more credibility.

Please let those who are already working with Allwinner continue to
work with them rather than spending time needlessly with someone who
clearly doesn't have any idea about what they say even from one moment
to the next.


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

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

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

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 Luke Kenneth Casson Leighton

On Fri, Jun 7, 2013 at 8:35 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Luke Leighton on the other hand is demanding that we

no demands have been made, russell: i've informed you of an immovable
deadline which will pass beyond which the opportunity being presented
is lost.

well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed.

That is a demand. On the other hand this would not be:

Can someone please get me up to speed on this? That is a request.

thank you for the correction.

can someone please get me up to speed on this? i've collated peoples
very gratefully received responses so far, here:
http://hands.com/~lkcl/allwinner_linux_proposal.txt

Please let those who are already working with Allwinner continue to
work with them rather than spending time needlessly with someone who
clearly doesn't have any idea about what they say even from one moment
to the next.

1) correct: i don't. i've been caught off-guard by this: it's very
short notice, and i have limited time available. i'm doing the best i
can to correct mistakes as i go along, but i *don't have time* to
observe the niceties, dot all the i's or cross all the t's.

2) that appears to be a request to a large audience. i have to point
out to that audience: end result of complying with the request above
will be that the free software community suffers as a result of losing
the opportunity to speak to - and therefore influence - the Directors
of one of the world's most successful, fastest growing [and also very
young and inexperienced] SoC fabless semiconductor company.

please make your own choice.

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

On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:

 Maxime will reply to this in more details, but I believe the status is:

  * Interrupt controller is working.
  * Clock drivers are working.
  * Pinctrl is working.
  * GPIO is working.
  * Timer is working.
  * UART is working
  * Watchdog is on its way (patches posted)
  * Ethernet is on its way (patches posted)
  * I2C is on its way (patches posted)

 ok so i've got this now in
http://hands.com/~lkcl/allwinner_linux_proposal.txt - that leaves...
well there's quite a bit: usb, sd/mmc (both variants: they changed the
data structures around sun5i), nand (probably both - the allwinner one
and the mtd one being done, reminds me: we need full documentation on
the NAND chip), scsi, g2d - cedarx and more.

 what else should be raised, and to what benefit?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capweedxtc+oamcpveq3bulbn88hsjzkoi0fknlbadzd04lq...@mail.gmail.com

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

On Fri, Jun 7, 2013 at 8:30 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
  well, tough.  get me up to speed, *fast*.

 No, not unless you're willing to *pay* someone to spend time teaching you,

 there's not enough time.  2 days left.

 because you are asking to be *taught* about the current situation, so
 you're asking someone to do some _work_ _for_

 . for the benefit of free software, russell.

 for the benefit of free software.

 for the BENEFIT of free software.

  _you_.

 NO.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capweedxmtnpfbapiacpig0g3zhvmwljpopdz6tbd-fn5hkd...@mail.gmail.com

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

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

On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
maxime: we need to talk :)

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?

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

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

On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan)
dennis.y...@gmail.com wrote:

On Saturday, June 8, 2013, luke.leighton wrote:

right - too many people contributed to this, input from jon smirl,
wookie, maxime, tomasz, henrik, i've made a start here and will
continue editing: this is notes for me to put forward an agenda for
discussion:

http://hands.com/~lkcl/allwinner_linux_proposal.txt

i'm setting a rule that each section *has* to have a list of clear
benefits, otherwise it'll have to be removed before it goes on to
their Directors.

so - even if there are any allwinner engineers reading this who would
like something put forward please also speak up! :)

___
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.

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

On Thu, Jun 6, 2013 at 1:15 AM, Henrik Nordström
hen...@henriknordstrom.net 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))

On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
hen...@henriknordstrom.net wrote:
 tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:

  Not really the case. Actually the opposite. DT have this as well, and
  integrated in device probing. Allwinner need to hack every driver used
  to add their gpio requests to have pinmuxing triggered.

  augh.  ok.  solutions.  what are the solutions here?

 What I said before.

 idea: hook into devicetree gpio functions to allow script-fex gpio
functions to gain access in a separate module?  that sort of thing.

 Go with DT for the kernel. There is no need for two configuration
 mechanisms doing the same thing. Disguise it in fex form (and
 translator) if too hard for people with a DOS editior to configure.

 what methods for doing that.  i need proposals.  4 days on the clock.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capweedypffcn9cnj10zht+azjhtrdu0lmfcgm_756uabf+n...@mail.gmail.com

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

On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com wrote:

 I don't see any other solution here than moving all the Allwinner code to
 DT (as it has been suggested in this thread several times already), as
 this is the only hardware description method supported by ARM Linux.

 i repeat again: please state, explicitly and unequivocably that you -
linux kernel developers - are happy that the reach of linux and
gnu/linux OSes is dramatically reduced due to this intransigent
position.

 or, tomasz, please state that you, tomasz, represent each and every
one of the linux kernel developers so that i do not need to keep
asking.


-- 
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 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 tomasz.f...@gmail.com 
wrote:
  I don't see any other solution here than moving all the Allwinner code
  to DT (as it has been suggested in this thread several times
  already), as this is the only hardware description method supported
  by ARM Linux.
  i repeat again: please state, explicitly and unequivocably that you -
 linux kernel developers - are happy that the reach of linux and
 gnu/linux OSes is dramatically reduced due to this intransigent
 position.
 
  or, tomasz, please state that you, tomasz, represent each and every
 one of the linux kernel developers so that i do not need to keep
 asking.

I do not represent all linux kernel developers by any means. I am just 
stating current policy of SoC/board support maintained by ARM Linux, which 
is common for all Linux kernel devlopers, or at least ARM Linux kernel 
developers.

Personally I am happy with numerous companies backing this policy and not 
making problems like this with Allwinner and I am really surprised that 
you are supporting a troublesome company like this.

There are many other SoC vendors making low cost SoCs, like Rockchip, 
Boxchip, Telechips. Maybe they would be better candidates for being 
promoted as vendors of choice for hardware running free software? (Just 
saying, as I do not know anything about their view on this. There is a lot 
of cheap tablets built using their products as well.)

Best regards,
Tomasz


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1851164.HnXhGSdttW@flatron

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

On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Luke,

On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com
wrote:
I don't see any other solution here than moving all the Allwinner code
to DT (as it has been suggested in this thread several times
already), as this is the only hardware description method supported
by ARM Linux.
i repeat again: please state, explicitly and unequivocably that you -
linux kernel developers - are happy that the reach of linux and
gnu/linux OSes is dramatically reduced due to this intransigent
position.

or, tomasz, please state that you, tomasz, represent each and every
one of the linux kernel developers so that i do not need to keep
asking.

I do not represent all linux kernel developers by any means. I am just
stating current policy of SoC/board support maintained by ARM Linux, which
is common for all Linux kernel devlopers, or at least ARM Linux kernel
developers.

Personally I am happy with numerous companies backing this policy and not
making problems like this with Allwinner and I am really surprised that
you are supporting a troublesome company like this.

you've not read what i've written tomasz.

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 Vladimir Pantelic


luke.leighton wrote:

On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
hen...@henriknordstrom.net 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 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 tomasz.f...@gmail.com 
wrote:
  Luke,
  
  On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
  On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com
  
  wrote:
   I don't see any other solution here than moving all the Allwinner
   code
   to DT (as it has been suggested in this thread several times
   already), as this is the only hardware description method supported
   by ARM Linux.
   
   i repeat again: please state, explicitly and unequivocably that you
   -
  
  linux kernel developers - are happy that the reach of linux and
  gnu/linux OSes is dramatically reduced due to this intransigent
  position.
  
   or, tomasz, please state that you, tomasz, represent each and every
  
  one of the linux kernel developers so that i do not need to keep
  asking.
  
  I do not represent all linux kernel developers by any means. I am just
  stating current policy of SoC/board support maintained by ARM Linux,
  which is common for all Linux kernel devlopers, or at least ARM Linux
  kernel developers.
  
  Personally I am happy with numerous companies backing this policy and
  not making problems like this with Allwinner and I am really
  surprised that you are supporting a troublesome company like this.
 
  you've not read what i've written tomasz.

I have.

  There are many other SoC vendors making low cost SoCs, like Rockchip,
  Boxchip,
 
  boxchip *is* allwinner.

Right, sorry. I am not really into this low cost hardware.

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 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 tomasz.f...@gmail.com wrote:
 
  I don't see any other solution here than moving all the Allwinner code to
  DT (as it has been suggested in this thread several times already), as
  this is the only hardware description method supported by ARM Linux.
 
  i repeat again: please state, explicitly and unequivocably that you -
 linux kernel developers - are happy that the reach of linux and
 gnu/linux OSes is dramatically reduced due to this intransigent
 position.

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 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
 hen...@henriknordstrom.net 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 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 tomasz.f...@gmail.com wrote:
 
  I don't see any other solution here than moving all the Allwinner code to
  DT (as it has been suggested in this thread several times already), as
  this is the only hardware description method supported by ARM Linux.
 
  i repeat again: please state, explicitly and unequivocably that you -
 linux kernel developers - are happy that the reach of linux and
 gnu/linux OSes is dramatically reduced due to this intransigent
 position.

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 Olof Johansson

On Thu, Jun 6, 2013 at 7:02 AM, Theodore Ts'o ty...@mit.edu 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 tomasz.f...@gmail.com wrote:

I don't see any other solution here than moving all the Allwinner code to
DT (as it has been suggested in this thread several times already), as
this is the only hardware description method supported by ARM Linux.

i repeat again: please state, explicitly and unequivocably that you -
linux kernel developers - are happy that the reach of linux and
gnu/linux OSes is dramatically reduced due to this intransigent
position.

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 jonsm...@gmail.com

On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com wrote:
  augh.  ok.  solutions.  what are the solutions here?

Luke if you really want to fix this a good solution is to have
Allwinner join Linaro and provide an engineer to the Linaro effort.
That engineer will get educated on the right way to do kernel
development and he can pass that knowledge back to Allwinner each day
as he learns it.

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 8:13 AM, jonsm...@gmail.com jonsm...@gmail.com wrote:
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com wrote:
augh. ok. solutions. what are the solutions here?

There's no need for anybody to join Linaro to contribute upstream.
That's a crazy notion.

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 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 jonsm...@gmail.com wrote:
  On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton luke.leigh...@gmail.com 
  wrote:
   augh.  ok.  solutions.  what are the solutions here?
 
  Luke if you really want to fix this a good solution is to have
  Allwinner join Linaro and provide an engineer to the Linaro effort.
  That engineer will get educated on the right way to do kernel
  development and he can pass that knowledge back to Allwinner each day
  as he learns it.
 
 There's no need for anybody to join Linaro to contribute upstream.
 That's a crazy notion.
 
 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 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 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 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 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))

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

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

On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström
hen...@henriknordstrom.net 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).

[*1] https://github.com/linux-sunxi/sunxi-tools
[*2] http://elinux.org/Embedded_Open_Modular_Architecture

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/capweedwrpoycfuwjvf99yua_tbooneeh8uktzvc7dtev6fa...@mail.gmail.com

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

ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton:

 what we do not want to happen is that they see upstream patches being
 submitted, they merge them into their internal tree (which to date has
 had zero upstream changes: they're currently only just getting round
 to doing 3.4 as we speak), and they *completely* ignore *absolutely
 everything* that's being done by the community, duplicating yet
 another set of device drivers (named drivers/*/sun8i_* and so on).

Well, that will obviously happen one or two more rounds, a bit depending
on which kernel releases Android will use. But I hope the Allwinner
kernel team will rethink when they hit more current kernels.

  this proposal is a start: however what you have to bear in mind is
 that you now have to convince a very busy company that it is in their
 best interests to disrupt their schedule, to drop their existing
 working practices, to tell all their customers please stop using the
 existing tools and please use these ones instead.

Why?

  you also need to convince the creators of the proprietary
 firmware-flashing tools livesuite and phoenix to *also* convert
 their tools over to the new proposed idea.

Why?

  can you provide such a supporting argument which would convince
 allwinner to accept the modifications to their working practices that
 you propose?

It does not really need to be such big modifications to their working
practices. Their configuration working practices is all built around the
fex file, and the new practices can be

0. Assuming kernel drivers gets ported over to using device tree.

1. Do configuration as you have always done in the .fex

2. Modify the build script to build a device tree from the fex +
template, in addition to script.bin.

3. Tell u-boot to load the device tree for the kernel.

That's it really.

licesuit do not modify script.bin. script.bin is compiled from the .fex
at image creation time. A couple more lines in the build script (and a
suitable translation tool) and there is also a device tree built and
installed and you get a nice and smoot transition.

  Device tree on ARM's goal is to achieve a single kernel across vendors, not
  just a single kernel for a single vendor.
 
  you'll be aware that i've mentioned a number of times and have
 discussed at some length why this is a goal that is completely
 impossible to achieve [*1].  sadly.

Here I disagree. It is possible. Not across all vendors but a
significant share.

Regards
enrik


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370468873.18839.22.camel@localhost

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

On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@henriknordstrom.net 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.

--
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 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 jonsm...@gmail.com

On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton luke.leigh...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@henriknordstrom.net 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.

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

ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren:

 1) Put all the parameters in the U-Boot configuration header. This is
 normal.

Yes, we do so today for U-Boot SPL. But this won't fit very well with
the Allwinner ODM workflow where one binary image works on a wide range
of board configurations probed while flashing the image to the board,
but on the other hand there is no real need for them to use u-boot as
the primary boot loader, just keep using boot0 + boot1 + u-boot chain as
they have always done.

 2) Read some data structure at run-time. This data structure could in
 theory be some SoC-specific blob format (e.g. the packed version of
 information that some tool extracts from FEX/DT), a whole FEX blob, or
 device tree.

This is likely to happen for the sunxi U-Boot SPL due to the sheer
amount of boards involved, and is done to some extents for other boards
as well. In the SPL there generally isn't room for full DT support. Main
u-boot HW configuration could be done runtime via DT alone but we are
not quite there yet, nothing major missing however other than getting it
done.

Regards
Henrik


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370474115.20454.26.camel@localhost

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

On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com jonsm...@gmail.com wrote:
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton luke.leigh...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@henriknordstrom.net 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.

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.

--
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 jonsm...@gmail.com

On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton luke.leigh...@gmail.com wrote:
On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com jonsm...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton luke.leigh...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@henriknordstrom.net 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.

yes. which is why they haven't done it.

Is Allwinner
going to add fex support to every single device driver in the kernel?

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.

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

tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:

  no john - they've only added it to the multiplexed sections of the
 drivers which they themselves have written.  such as
 drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
 arch/arm/mach-sun{N}i and so on.

And a number of SPI device drivers, USB device drivers, vendor provided
device drivers, ..

 the script.fex system deals with the pinmux issue in a very neat way that:
 
   a) has very little impact on the rest of the kernel tree [citation
 needed!  i'm saying that: could someone please confirm if it's true]

Not really the case. Actually the opposite. DT have this as well, and
integrated in device probing. Allwinner need to hack every driver used
to add their gpio requests to have pinmuxing triggered.

It is just layered a bit differently when using DT.

Regards
Henrik


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370475609.20454.44.camel@localhost

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

On Thu, Jun 6, 2013 at 12:40 AM, Henrik Nordström
hen...@henriknordstrom.net 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))

On Thu, Jun 6, 2013 at 12:40 AM, jonsm...@gmail.com 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.

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.

--
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 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
 
 hen...@henriknordstrom.net 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))

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

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