Bug#711474: linux-image-3.9-1-amd64: backlight brightness on Dell XPS13 is no longer changeable

2013-06-07 Thread Jan De Luyck
Package: src:linux
Version: 3.9.4-1
Severity: normal

Dear Maintainer,

After upgrading to 3.9, I can't reliably set the backlight on my Dell XPS13
anymore. using i915.backlight=vendor doesn't work either.

Using the patch listed at
https://bugzilla.kernel.org/attachment.cgi?id=97751, bug
https://bugzilla.kernel.org/show_bug.cgi?id=47941 comment 83, turns things
back into a workable state.

Please consider applying. I've rolled my own kernel with this patch for now.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Dell System XPS L322X
product_version:
chassis_vendor: Dell Inc.
chassis_version: 0.1
bios_vendor: Dell Inc.
bios_version: A08
board_vendor: Dell Inc.
board_name: 0WW7PG
board_version: A00

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM
Controller [8086:0154] (rev 09)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Dell Device [1028:058b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 43
Region 0: Memory at d000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 2000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30
[XHCI])
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 40
Region 0: Memory at d050 (64-bit, non-prefetchable) [size=64K]
Capabilities: access denied
Kernel driver in use: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at d0515000 (64-bit, non-prefetchable) [size=16]
Capabilities: access denied
Kernel driver in use: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
(prog-if 20 [EHCI])
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d051a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: access denied
Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at d051 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: d040-d04f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: access denied
Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #1 

Re: Updating Linux in wheezy

2013-06-07 Thread Cyril Brulebois
Adam D. Barratt a...@adam-barratt.org.uk (07/06/2013):
 It's tight, but Saturday would be within the window we announced so
 should okay from that perspective; it could be interesting if any
 regressions appear.
 
 As wheezy's linux package also produces the kernel udebs, we should
 really have the kernel included in the point release be the same as
 the kernel that the installer's built with. CCing Cyril and -boot
 for any comments on that side.

I'm not sure how the pu-NEW freeze is implemented, but I'm not sure
I'll be able to have everything ready on saturday; in any cases, I'll
have to wait until the kernel is built everywhere before uploading
src:debian-installer (unless we play with a few dep-waits). So if it's
OK to have a late debian-installer upload, linux's being uploaded on
saturday is fine with me.

(Apologies for being late myself, etc.; but you already know about
that part.)

Mraw,
KiBi.


signature.asc
Description: Digital signature


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

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

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

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

 I have.

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

  boxchip *is* allwinner.

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

 i've been tracking it for several years.

 There is also AMLogic, though.

 they're *definitely* GPL-violators.

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

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

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

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

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

 most likely.

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

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

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

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

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

 so.

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

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

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

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

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

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

* {insert proposals here}

3 days left on the clock.

l.


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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 indeed.

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

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

 l.


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



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

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

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

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


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



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

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

 apologize? WTF?

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

Definitely not.

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

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

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

There is nothing for us to apologise for here.

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


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



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

2013-06-07 Thread Russell King - ARM Linux
On Fri, Jun 07, 2013 at 09: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



Alquiler vacacional de apartamentos en Vera (Almería)

2013-06-07 Thread Alquiler en Vera
Buenos días:
Tenemos disponibles para alquilar 14 casas adosadas y varios apartamentos Vera 
(Almería) en el entorno de Puerto Rey.
Los alquila directamente la propiedad, sin intermediarios, y desde 250 euros la 
semana.
Si quiere que le mandemos todos los detalles puede contactar con nosotros en 
vera_alqui...@hhxx.es
Un saludo
GSX Servicios SL



Processed: your mail

2013-06-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reassign #711526 linux-image-3.2.0-4-amd64 3.2.41-2+deb7u2
Bug #711526 [3.2.41-2+deb7u2] mmc0: Timeout waiting for hardware interrupt.
Warning: Unknown package '3.2.41-2+deb7u2'
Bug reassigned from package '3.2.41-2+deb7u2' to 'linux-image-3.2.0-4-amd64'.
No longer marked as found in versions linux-image-3.2.0-4-amd64.
Ignoring request to alter fixed versions of bug #711526 to the same values 
previously set
Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware 
interrupt.
Marked as found in versions linux/3.2.41-2+deb7u2.

End of message, stopping processing here.

Please contact me if you need assistance.
-- 
711526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711526
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13706125431136.transcr...@bugs.debian.org



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

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.



Processed: Re: Bug#711526: mmc0: Timeout waiting for hardware interrupt.

2013-06-07 Thread Debian Bug Tracking System
Processing control commands:

 reassign -1 linux-image-3.2.0-4-amd64
Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware 
interrupt.
Ignoring request to reassign bug #711526 to the same package
 found -1 3.2.41-2+deb7u2
Bug #711526 [linux-image-3.2.0-4-amd64] mmc0: Timeout waiting for hardware 
interrupt.
Ignoring request to alter found versions of bug #711526 to the same values 
previously set

-- 
711526: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711526
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b711526.137062387621380.transcr...@bugs.debian.org



Bug#711526: mmc0: Timeout waiting for hardware interrupt.

2013-06-07 Thread Andrei POPESCU
Control: reassign -1 linux-image-3.2.0-4-amd64
Control: found -1 3.2.41-2+deb7u2

On Vi, 07 iun 13, 14:57:49, pepelopez wrote:
 Package: 3.2.41-2+deb7u2
 Version: linux-image-3.2.0-4-amd64

Dear pepelopez,

You mixed up the package name with the version, which is why:

1. your report was filled against 'unknown-package'
2. it misses information that may be very useful for the Maintainers

I'm taking care of 1., but kindly run

reportbug linux-image-3.2.0-4-amd64

and send the generated information as a follow-up for this bug (number 
711526).

Kind regards,
Andrei
-- 
Looking after bugs filled against unknown packages


signature.asc
Description: Digital signature


Bug#711539: [src:linux] No sound on headphones with snd_hda_intel (working on 3.8)

2013-06-07 Thread Sebastián Cruz
Package: src:linux
Version: linux-image-3.9-1-amd64
Severity: normal

--- Please enter the report below this line. ---

When booting with 3.9 I get no sound on headphones (it works through
speakers). It also doesn't work with 3.10-rc4 from experimental.

It works with 3.2 and 3.8.

Please let me know if you need more information, I'll be glad to provide it.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.9-1-amd64

Debian Release: jessie/sid
  700 testing security.debian.org
  700 testing cdn.debian.net
  600 unstablecdn.debian.net
  500 stable  repository.spotify.com
  500 stable  dl.google.com
  500 raring  ppa.launchpad.net
  500 oneiric ppa.launchpad.net
1 testing www.deb-multimedia.org
1 experimentalcdn.debian.net

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

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



Bug#711526: mmc0: Timeout waiting for hardware interrupt.

2013-06-07 Thread pepelopez
Package: src:linux
Version: 3.2.41-2+deb7u2
Followup-For: Bug #711526

Card reader not work.

0b:06.0 CardBus bridge: O2 Micro, Inc. OZ711SP1 Memory CardBus Controller (rev
01)
0b:06.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev
02)
0b:06.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller
(rev 01)

[ 1346.564443] mmc0: new SDHC card at address cc87
[ 1346.628822] mmcblk0: mmc0:cc87 SU04G 3.79 GiB (ro)
[ 1346.630721]  mmcblk0: p1 p2
[ 1356.672118] mmc0: Timeout waiting for hardware interrupt.
[ 1356.672176] [ cut here ]
[ 1356.672235] WARNING: at /build/buildd-
linux_3.2.41-2+deb7u2-amd64-NHQI9B/linux-3.2.41/drivers/mmc/host/sdhci.c:959
sdhci_send_command+0x2f/0x7db [sdhci]()
[ 1356.672247] Hardware name: TravelMate 5520
[ 1356.672253] Modules linked in: mmc_block act_police sch_ingress cls_u32
sch_sfq sch_cbq sha256_generic cryptd aes_x86_64 aes_generic cbc tun
ndiswrapper(O) pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep
parport_pc ppdev rfcomm bluetooth lp parport cpufreq_stats cpufreq_conservative
cpufreq_userspace cpufreq_powersave binfmt_misc uinput fuse iptable_nat nf_nat
iptable_mangle ipt_LOG xt_limit xt_tcpudp ipt_REJECT nf_conntrack_ipv4
nf_defrag_ipv4 xt_state nf_conntrack xt_multiport iptable_filter ip_tables
x_tables ext2 dm_crypt snd_usb_audio snd_usbmidi_lib snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_hda_codec_realtek fglrx(P) joydev
snd_hda_intel snd_hda_codec acer_wmi snd_hwdep snd_pcm sparse_keymap
snd_page_alloc pcmcia snd_seq rfkill snd_seq_device snd_timer snd sp5100_tco
yenta_socket pcmcia_rsrc pcmcia_core edac_mce_amd i2c_piix4 powernow_k8
soundcore edac_core psmouse i2c_core battery mperf ac power_supply serio_raw
evdev pcspkr k8temp video processor button wmi ext4 crc16 jbd2 mbcache dm_mod
microcode sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hid sdhci_pci
sdhci mmc_core pata_atiixp ahci libahci libata ohci_hcd thermal thermal_sys
ehci_hcd scsi_mod sky2 usbcore usb_common [last unloaded: scsi_wait_scan]
[ 1356.672521] Pid: 10, comm: ksoftirqd/1 Tainted: P   O 3.2.0-4-amd64
#1 Debian 3.2.41-2+deb7u2
[ 1356.672530] Call Trace:
[ 1356.672548]  [81046a55] ? warn_slowpath_common+0x78/0x8c
[ 1356.672570]  [a0012d48] ? sdhci_send_command+0x2f/0x7db [sdhci]
[ 1356.672592]  [a00136ce] ? sdhci_finish_data+0x1da/0x1f7 [sdhci]
[ 1356.672612]  [a0013750] ? sdhci_timeout_timer+0x65/0xa0 [sdhci]
[ 1356.672624]  [81052208] ? run_timer_softirq+0x19a/0x261
[ 1356.672643]  [a00136eb] ? sdhci_finish_data+0x1f7/0x1f7 [sdhci]
[ 1356.672656]  [8104c094] ? __do_softirq+0xb9/0x177
[ 1356.672666]  [8104c1cc] ? run_ksoftirqd+0x7a/0x118
[ 1356.672675]  [8104c152] ? __do_softirq+0x177/0x177
[ 1356.672688]  [8105f329] ? kthread+0x76/0x7e
[ 1356.672701]  [81354b34] ? kernel_thread_helper+0x4/0x10
[ 1356.672712]  [8105f2b3] ? kthread_worker_fn+0x139/0x139
[ 1356.672722]  [81354b30] ? gs_change+0x13/0x13
[ 1356.672729] ---[ end trace 782d14030959d823 ]---



-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.41-2+deb7u2

** Command line:
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/internal-system ro quiet

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[11861.677107] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7773 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11862.727799] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7804 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11863.479142] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7819 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11864.229150] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7828 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11876.537856] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8316 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11877.287347] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8317 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11878.040721] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8318 
PROTO=UDP SPT=137 DPT=137 LEN=58 
[11888.827193] IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:22:ca:42:66:08:00 
SRC=192.168.1.10 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8344 
PROTO=UDP 

Bug#649748: linux-2.6: fixes upstream packaging when cross-compiling

2013-06-07 Thread Moritz Muehlenhoff
reassign 649748 src:linux
thanks

On Wed, Nov 23, 2011 at 08:18:16PM -0600, Jonathan Nieder wrote:
 found 649748 linux-2.6/2.6.39-3
 tags 649748 + upstream
 quit
 
 Hi Hector,
 
 Hector Oron wrote:
 
Do you think is sane to send this patch to upstream?
 
 Yep, sounds like the sane thing to do.  Based on MAINTAINERS (ok, I
 already knew, but let's pretend for a moment), the mailing list to
 write to is linux-kbu...@vger.kernel.org (no subscription needed, and
 the convention is to always reply-to-all there).
 
 From git log scripts/package/builddeb, I see that the people to cc
 are maximilian attems m...@stro.at and Asbjoern Sloth Toennesen
 asbj...@asbjorn.biz to get comments on the first version of a patch
 and Michal Marek mma...@suse.cz once the final version is ready.
 
 Administrivia: kernel hackers tend to prefer to review diffs produced
 with the -p / --show-c-function option.  Patches should include a
 sign-off --- see the Developer's Certificate of Origin 1.1 in
 Documentation/SubmittingPatches for details on that.

Hector,
this hasn't landed in current kernel.org git, did you submit it upstream?

Cheers,
Moritz


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



Processed: Re: linux-2.6: fixes upstream packaging when cross-compiling

2013-06-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reassign 649748 src:linux
Bug #649748 [linux-2.6] linux-2.6: fixes upstream packaging when cross-compiling
Bug reassigned from package 'linux-2.6' to 'src:linux'.
No longer marked as found in versions linux-2.6/2.6.39-3.
Ignoring request to alter fixed versions of bug #649748 to the same values 
previously set
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
649748: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649748
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.137062744313093.transcr...@bugs.debian.org



Bug#600031: marked as done (updating kernel causes slow write speed to raid)

2013-06-07 Thread Debian Bug Tracking System
Your message dated Fri, 7 Jun 2013 19:49:13 +0200
with message-id 20130607174913.gb21...@inutil.org
and subject line Re: updating kernel causes slow write speed to raid
has caused the Debian Bug report #600031,
regarding updating kernel causes slow write speed to raid
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
600031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-image
Version: 2.6.32-5-686

After dist-upgrade from Lenny to Squeeze write speed is halved. Shown
with bonnie++. Before upgrade write speed was 21MB/s, after upgrade
10MB/s.

Hardware: Dell Powervault 745n with hardware raid Adaptec 2610SA.
Celeron(R) CPU 2.40GHz, 512MiB RAM.

Confirmed link to kernel with:

otherserver$ scp 4gbfile raid_server:
   100% 4000MB   6.6MB/s   10:06

reboot server with kernel 2.6.26-2-686 leftover from Lenny.
otherserver$ scp 4gbfile raid_server:
   100% 4000MB  11.3MB/s   05:55

Also of note that when copying a large file the system becomes heavily loaded.
   iowait: 80.1%wa
   load average: 3.58, 1.48, 0.66
   Mem:514428k total,   508276k used, 6152k free,10084k buffers


---End Message---
---BeginMessage---
Version: 2.6.36-1

On Thu, Oct 14, 2010 at 03:16:36PM +0100, Dave Clarke wrote:
 Ben
 That has solved it. Now getting around 27MB/s write on ext4 and 97MB/s
 read with the experimental kernel. I'm happy with these speeds on this
 hardware. It is still a little slower then with windows but I can live
 with that.

Marking 2.6.36 as fixed.

Cheers,
Moritz---End Message---


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

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

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

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

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

 let me try to put it into undo words.

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

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

 does that point you in the right direction?

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

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

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

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


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

l.


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



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

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

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

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

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

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

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

 My colleague Maxime Ripard (Cc'ed)

 maxime: we need to talk :)

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

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

 All in mainline, completely Device Tree based.

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

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

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


 So isn't this entire discussion completely moot?

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

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

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

l.


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



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

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

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

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

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

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


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



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

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

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

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

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

 indeed.  this is a company that produced a 70-page datasheet when
freescale produced 4,500 for the iMX6.  i passed on that link and i
believe it'll be an eye-opener to their engineers: education is what's
key here, and you don't need to pay vast sums to do it.

 although the quantities they're selling are just ennorrrmous,
allowing them to undercut absolutely everybody because they can pay
absolute best rates to the Fab Houses (TSMC etc.) their profit margins
are going to be exceptionally slim.

 so we cannot count on them having a spare $1m per year to give to
linaro, so yes, i tend to agree with what you're implying, olof, that
allwinner should be encouraged to participate more in upstream
contribution.

 so.

 could someone please describe to me what they should do, here?  whom
should they best contact, what lists, what's the procedures, where's
the best-working-practices, where are the foundations with which they
can participate that have the formal procedures for proposals [similar
to python's PEP and debian's DEP].  that last was a not-very-subtle
hint, btw.

 and... please... i've yet to receive *any* answers to the question
and what are the benefits that they would get by doing so!!

 Listen, Allwinner isn't working in a vacuum, believe it or not. I've
 talked to them, so has Arnd and other people working on ARM, including
 Maxime Ripard, who's been reimplementing upstream support for their
 platform.

 great.

 Everybody is interested in the right things happening, it's
 just a matter of figuring out how to do it. The right people are
 already talking.

  but the Directors of Allwinner aren't been kept in the loop,
here: that's my job, to get them up-to-speed.

 the cost of joining. The net result will likely be a reduction in the
 amount they need to spend on in-house development since they will
 learn how to better leverage other developer's work.

 but you forget one thing: they only need *ever* produce *one*
board/kernel.  they have a registered board type, it covers *all*
products and i mean *all* products.  i don't mean that in the usual
way where most companies re-use a single machine type for multiple
devices and irritate the crap out of linux kernel developers when the
GPL source finally leaks, i mean thanks to script.fex they
LITERALLY only ever compile one binary and then customise script.fex
on a per-customer basis.

 so the usual lessons really do not apply, here.

 the only one i spotted was that they rather foolishly made duplicates
of sun5i_usb and renamed all the files (s/SUN5I/SUN7I/g) to make
sun7i_usb, then started editing.  one of the developers created a
buffer overflow, which corrupted internal memory, and there are signs
that he then started experimenting switching off DMA trying to fix
various problems.

 if he'd done a proper job #ifdef CONFIG_SUN7I_USB #ifdef
CONFIG_SUN5I_USB in the same source code etc etc. and tested on
known-good [older] hardware he would have noticed that the
modifications failed on previously-known-good hardware and would have
spotted the buffer overflow error much sooner.

 that _is_ something i will be bringing to the Director's attention,
that the strategy of cut-paste-itis has detrimental effects.

ok.  so.  apologies, bit of a digression there.

 question for you olof [and others of course]: you've clearly listed
some benefits, which i'm very very grateful for.  in light of what i
describe above [the we only need ever write one kernel strategy
which is serving Allwinner really really well apart from the
code-duplication mistake], do the benefits you list *still* apply, and
if so, could you please elaborate for me, assume i'm thick or
something [or at least not a programmer, which i am unfortunately so
might miss something]

l.


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



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

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

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

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

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


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

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

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

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

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

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

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

l.


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



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

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

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

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

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

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

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

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

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

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

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

  My colleague Maxime Ripard (Cc'ed)

  maxime: we need to talk :)

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

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

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

 Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13)
 are supported.

 See arch/arm/boot/dts/sun{4,5}i* for a good overview.

  All in mainline, completely Device Tree based.

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

 The very first support landed in 3.8.

  So isn't this entire discussion completely moot?

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

 You really believe you're more important than you really are, I'd say.

 no, i don't.  i'm just a messenger.  under-informed one, at the
moment.  please bear that in mind rather than saying you seem
dreadfully underinformed - i got caught off-guard by this opportunity
and need to get up-to-speed rather fast.

 My colleague Maxime is in contact with Allwinner, he has regular
 discussion with them, started reviewing some of the kernel code they're
 writing, has received datasheets from them, and evaluation boards.

 _great_.  that's brilliant to hear.

 So this work is definitely not done in isolation from Allwinner, and
 they have received much more than an heads-up from Maxime.

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

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

 So far, A10 and A13. Maxime has received a A31 evaluation board from
 Allwinner very recently, and also A10S and A20 boards. I suppose he
 will be working on those fairly and posting the corresponding patches
 fairly soon.

 great.   you've got the A20 3.3 kernel source drop?
 
http://git.rhombus-tech.net/?p=linux.git;a=tree;h=refs/heads/lkcl-3.3-a20;hb=refs/heads/lkcl-3.3-a20


 In other words, it looks like you've started an entire discussion about
 the mainline support for Allwinner SoCs without having a look at what
 git log tells you...

 absolutely correct.  dived into this the moment i got word of a
potential meeting on extremely short notice, having had zero time to
review the logs prior even to then.

 Which by itself is a very good indicator that
 you're probably not the best interlocutor for Allwinner as far as
 mainline development is concerned.

 the meeting's going ahead, regardless of your concerns.  please help
get me up to speed, for the benefit of the linux community.  take
advantage of the opportunity, please: take it at face value without
judgement.

l.


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



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

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

2013-06-07 Thread Russell King - ARM Linux
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
 On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson 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))

2013-06-07 Thread Russell King - ARM Linux
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
  well, tough.  get me up to speed, *fast*.

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

 please stop wasting time like this:

Pot. Black.


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



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

2013-06-07 Thread Russell King - ARM Linux
On Fri, Jun 07, 2013 at 08: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



Bug#649748: linux-2.6: fixes upstream packaging when cross-compiling

2013-06-07 Thread Hector Oron
Hello,

2013/6/7 Moritz Muehlenhoff j...@inutil.org:

 Hector,
 this hasn't landed in current kernel.org git, did you submit it upstream?

No, I did not submit it upstream, also it seems to be incomplete, and
it misses armhf architecture. Please, allow me few days to work on it
and re-submit updated patch to Debian and upstream.

Thanks for the heads-up

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


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



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

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

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

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

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

l.


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



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

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

 l.


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



IPQ Module

2013-06-07 Thread Ozgur
Hello all;

I tested 3.2.0-4 kernel on Debian 7.0 Wheezy operating system. Debian
Wheezy being used 3.2.0-4 kernel.

# uname -ar
Linux snort.test.lan 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64
GNU/Linux kernel version

I understand; the new kernel version no used ip_queue module, right? I
run Snort IPQ mode and error:

--
ipq DAQ configured to inline.
ERROR: Can't initialize DAQ ipq (-1) - ipq_daq_initialize:
ipq_create_handle error Unable to create netlink socket

Fatal Error, Quitting..
--

I tested NFQ mode Snort his way to work and worked. I think; new kernel
not use IPQ module.

# modprobe ip_queue
ERROR: could not insert 'ip_queue': Device or resource busy

# insmod ip_queue
Error: could not load module ip_queue: No such file or directory

# insmod /lib/modules/3.2.0-4-amd64/kernel/net/ipv4/netfilter/ip_queue.ko
Error: could not insert module
/lib/modules/3.2.0-4-amd64/kernel/net/ipv4/netfilter/ip_queue.ko: Device or
resource busy

and syslog message:

Jun  8 02:21:54 snort kernel: [ 3382.028421] ip_queue: failed to register
queue handler
Jun  8 02:27:35 snort kernel: [ 3722.151772] ip_queue: failed to register
queue handler
Jun  8 02:27:52 snort kernel: [ 3739.115550] ip_queue: failed to register
queue handler

I want to share this information with you.

Best Regards

Ozgur Karatas


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

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

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

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

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

 You mean something like http://linux-sunxi.org/Linux_mainlining_effort ?

 ahh, fantastic.  with references too.  magic.  exactly what i need.
thank you.  listed now at
http://hands.com/~lkcl/allwinner_linux_proposal.txt

 You should really do a bit of research before starting a thread like
 this one.

 then that gives you some idea of how busy i've been and still am, to
not be aware even of things like this, to have kicked a project off
some 18-24 months ago and not be able to keep up with one of the many
branches and initiatives that it's spawned.

 when i said i've been caught off-guard by this opportunity i meant
exactly what i said.

 This webpage has been around for like 9 monthes now on the wiki
 of a community you pretend to represent

 i pretend no such thing and apologise for giving any impression of such.

 (even though I fail to get how
 you can pretend such thing, but that's another topic).

 i have a different focus: a meta-project of sorts, where allwinner
happened to be the first.  look up rhombus-tech and EOMA68 and it'll
become a bit clearer.

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

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

 3.8, as shown in the wiki page

 got that.

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

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

 Again, wiki.

 yep, am there now.

  So isn't this entire discussion completely moot?

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

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

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

 A10, A13 for the moment. I just received hardware with A10s, A20 and A31
 that I need to work on, but support should come quite soon.

 superb.  question: what help or other resources could you do with?
what additional information?


 I already
 have some patches pending to be tested on an A31 board, but didn't have
 as much time as I wanted lately to actually set a proper environment to
 test them.

 ok - good to know.  btw when you get to it please note a bug found in
the vanilla [allwinner-released] A20 3.3 tree where they reduced a
128 byte buffer to 78 bytes for spurious reasons; the critical fix is
at line 989, of the following patch:

 
http://git.rhombus-tech.net/?p=linux.git;a=commitdiff;h=refs/heads/lkcl-3.3-a20;hp=6c5753e5dc1fafff288d522c94b40a7dd2a81adc

 i found this by running a diff -u of sun4i_usb from the 3.4 sunxi
community tree against the sun7i_usb tree from the allwinner 3.3
release.  amongst the desperate attempts to disable DMA (probably due
to stack corruption of the above bug) and various renaming attempts of
*SUN4I* to *SUN7I*, that one stuck out like a sore thumb.  the other
bits - which may or may not be relevant - are the spinlock protection
and the call to sw_udc_enable which is present in the sun4i_usb 3.4
code but not the A20 3.3 code.

mileage may vary, and the buffer overrun only happens if you enable
the OTG interface as dual (auto-detect) because that's enough
features in the bitfield to cause there to be enough strcpy's... oops
:)

l.


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



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

2013-06-07 Thread Dennis Lan (dlan)
On Saturday, June 8, 2013, luke.leighton wrote:

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

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

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

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

 l.

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



Hi luke
 I'm not a allwinner employer :-)$. but pretty much in the same
position as they are.

 I'd like to add a few comments about the risk of adopting the device
tree(from allwinner side)
1) current using fdt in bootloader(uboot) is not mature, I'm not saying
about passing the fdt data to kernel.
  But the bootloader itself need information from device tree, say boot0/1
phase (boot device type, DDR initialization...)
  since fdt is not ready, and SRAM space is very limited ... I'm afraid
'fex' may co-exist with device tree.
  still, they receive benefits if they can adopt device tree, at
least minimal the kernel side migration effort
  Generally this info already been pointed out by steppen warren in
previous email...

2) device tree may not been understood by third vendors (who previus
produce shoes or ? :-$),
  they are real old 'Fex' scheme user, they like edit the data in windows
with dos format
  So, how to fill this gaps, make them happy? Creat another tool to handle
device tree modification?
  Then it's another price they have to pay...


Dennis Lan


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

2013-06-07 Thread luke.leighton
On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan)
dennis.y...@gmail.com wrote:


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

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

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

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

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

 l.

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



 Hi luke
  I'm not a allwinner employer :-)$. but pretty much in the same position
 as they are.

 thanks for chipping in.

  I'd like to add a few comments about the risk of adopting the device
 tree(from allwinner side)
 1) current using fdt in bootloader(uboot) is not mature, I'm not saying
 about passing the fdt data to kernel.

  fdt.  could you provide some context here?  what is it?
(apart from being a TLA)

   But the bootloader itself need information from device tree, say boot0/1
 phase (boot device type, DDR initialization...)
   since fdt is not ready, and SRAM space is very limited ... I'm afraid
 'fex' may co-exist with device tree.
   still, they receive benefits if they can adopt device tree, at least
 minimal the kernel side migration effort
   Generally this info already been pointed out by steppen warren in previous
 email...

 ... which i have to admit i may have missed the significance of or
possibly just missed it entirely.

 what's the main concern you have, here; what's the potential
solution, and what's the benefit of that potential solution, to
allwinner [direct or indirect]?

 2) device tree may not been understood by third vendors (who previus produce
 shoes or ? :-$),

 :)

   they are real old 'Fex' scheme user, they like edit the data in windows
 with dos format
   So, how to fill this gaps, make them happy? Creat another tool to handle
 device tree modification?
   Then it's another price they have to pay...

 yehh... that kinda looks unavoidable, although it would ultimately
only inconvenience the developers of the proprietary firmware-flashing
tools [livesuite, phoenix] and so would be transparent to the
factories and so on.  i've mentioned the idea of having an in-kernel
translation tool rather than an external (pre-runtime) one, i've yet
to get some feedback on that.

 l.


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



Bug#711585: [linux-image-3.9-1-loongson-2f] linux 3.9.4-1 for loongson-2f doesn't halt/reboot/suspend-disk.

2013-06-07 Thread Javier Vasquez
Package:  linux-image-3.9-1-loongson-2f
Version:  3.9.4-1
Severity: Important

When rebooting, halting or suspending to disk on a mini-pc with
loongson-2f, it just hangs, printing a weird trace.

Fortunately dmessage kept such trace:

Jun  7 23:34:30 mini-1 kernel: [2.18] EXT4-fs (sda6): write
access will be enabled during recovery
Jun  7 23:34:30 mini-1 kernel: [2.908000] EXT4-fs (sda6): orphan
cleanup on readonly fs
Jun  7 23:34:30 mini-1 kernel: [2.908000] EXT4-fs (sda6):
ext4_orphan_cleanup: deleting unreferenced inode 888392
Jun  7 23:34:30 mini-1 kernel: [2.924000] EXT4-fs (sda6):
ext4_orphan_cleanup: deleting unreferenced inode 889643
Jun  7 23:34:30 mini-1 kernel: [2.924000] EXT4-fs (sda6):
ext4_orphan_cleanup: deleting unreferenced inode 904421
Jun  7 23:34:30 mini-1 kernel: [2.936000] EXT4-fs (sda6): 3 orphan
inodes deleted
Jun  7 23:34:30 mini-1 kernel: [2.94] EXT4-fs (sda6): recovery complete
Jun  7 23:34:30 mini-1 kernel: [3.072000] EXT4-fs (sda6): mounted
filesystem with ordered data mode. Opts: (null)
Jun  7 23:34:30 mini-1 kernel: [3.076000] VFS: Mounted root (ext4
filesystem) readonly on device 8:6.
Jun  7 23:34:30 mini-1 kernel: [3.076000] Freeing unused kernel
memory: 320k freed
Jun  7 23:34:30 mini-1 kernel: [6.764000] cpufreq: Loongson-2F CPU
frequency driver.
Jun  7 23:34:30 mini-1 kernel: [6.812000] CPU 0 Unable to handle
kernel paging request at virtual address c00106c8, epc ==
8051f1c4, ra == 8051d36c
Jun  7 23:34:30 mini-1 kernel: [6.816000] Oops[#1]:
Jun  7 23:34:30 mini-1 kernel: [6.816000] Cpu 0
Jun  7 23:34:30 mini-1 kernel: [6.816000] $ 0   : 
cfff c00106c8 
Jun  7 23:34:30 mini-1 kernel: [6.816000] $ 4   : 9800be421000
807b  
Jun  7 23:34:30 mini-1 kernel: [6.816000] $ 8   : 
 98000136e798 
Jun  7 23:34:30 mini-1 kernel: [6.816000] $12   : 
8047d688 803192e8 
Jun  7 23:34:30 mini-1 kernel: [6.816000] $16   : 9800be421000
8081cc40 8081cc30 806f90b8
Jun  7 23:34:30 mini-1 kernel: [6.816000] $20   : 9800be764000
9800be6afe70 771b8000 4000
Jun  7 23:34:30 mini-1 kernel: [6.816000] $24   : 
770c7ce4
Jun  7 23:34:30 mini-1 kernel: [6.816000] $28   : 9800be6ac000
9800be6afd50 00afc978 8051d36c
Jun  7 23:34:30 mini-1 kernel: [6.816000] Hi: e147d0b6
Jun  7 23:34:30 mini-1 kernel: [6.816000] Lo: 748f7125
Jun  7 23:34:30 mini-1 kernel: [6.816000] epc   : 8051f1c4
dev_uevent+0xe0/0x1a0
Jun  7 23:34:30 mini-1 kernel: [6.816000] Not tainted
Jun  7 23:34:30 mini-1 kernel: [6.816000] ra: 8051d36c
show_uevent+0xdc/0x178
Jun  7 23:34:30 mini-1 kernel: [6.816000] Status: 100044e3  KX SX
UX KERNEL EXL IE
Jun  7 23:34:30 mini-1 kernel: [6.816000] Cause : 10008008
Jun  7 23:34:30 mini-1 kernel: [6.816000] BadVA : c00106c8
Jun  7 23:34:30 mini-1 kernel: [6.816000] PrId  : 6303 (ICT Loongson-2)
Jun  7 23:34:30 mini-1 kernel: [6.816000] Modules linked in: usb_common
Jun  7 23:34:30 mini-1 kernel: [6.816000] Process udevd (pid: 246,
threadinfo=9800be6ac000, task=9800be67a6b8,
tls=771fc2c0)
Jun  7 23:34:30 mini-1 kernel: [6.816000] Stack : 8081cc40
806f90b8 9800be421000 
Jun  7 23:34:30 mini-1 kernel: [6.816000] 8081cc40
8051d36c 9800be342980 80867818
Jun  7 23:34:30 mini-1 kernel: [6.816000] 9800be0f5550
8081cc40 806f90b8 9800be3429a0
Jun  7 23:34:30 mini-1 kernel: [6.816000] 9800be6afe70
8051dac0 00afc978 802c6778
Jun  7 23:34:30 mini-1 kernel: [6.816000] 9800be342980
80387a04  9800be6afe70
Jun  7 23:34:30 mini-1 kernel: [6.816000] 770785e0
4000 9800be75cec0 771b8000
Jun  7 23:34:30 mini-1 kernel: [6.816000] 9800be6afe70
770785e0  
Jun  7 23:34:30 mini-1 kernel: [6.816000] 7f8e97d8
803190c0 0003 9800be75cec0
Jun  7 23:34:30 mini-1 kernel: [6.816000] 
771b8000 000a 80319338
Jun  7 23:34:30 mini-1 kernel: [6.816000] 
 4000 000a
Jun  7 23:34:30 mini-1 kernel: [6.816000] ...
Jun  7 23:34:30 mini-1 kernel: [6.816000] Call Trace:
Jun  7 23:34:30 mini-1 kernel: [6.816000] [8051f1c4]
dev_uevent+0xe0/0x1a0
Jun  7 23:34:30 mini-1 kernel: [6.816000] [8051d36c]
show_uevent+0xdc/0x178
Jun  7 23:34:30 mini-1 kernel: [