[linux-cirrus] 2.6 kernel status, love letters from cirrus

  • From: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>
  • To: linux-cirrus@xxxxxxxxxxxxx
  • Date: Mon, 12 Feb 2007 13:52:04 +0100

Hi,

In mainline kernels, there is now support for port F GPIO interrupts,
and support for IRQT_NOEDGE (PCMCIA wants this or it gets into an IRQ
storm when you plug in a card.)

I hacked a bit on the ep93xx PATA libata driver (can be found in my svn
tree.)  It now works again on recent kernels, supports having a slave
device, and gets the PIO0 timings right, but still downgrades all PIO
modes to PIO0 -- which is still better than losing your data. :-)

Note that the ATA stuff still needs work, as libata assumes that all
ATA hardware has the task file registers accessible via MMIO or I/O,
which doesn't hold on the ep93xx (have to generate read/write pulses
by hand), and I hacked around that in a pretty ugly way.  (Ideally,
it needs a third access option, ATA_FLAG_FITH or somesuch.)

Oh, current 2.6 head also has a libata fix that properly detects PIO
modes on old CompactFlash cards.

I also redid the I2C bus driver so that it allows sharing the EECLK
and EEDAT pins with other agents.  This is necessary for at least one
ep93xx board where the PCMCIA voltage switcher (TPS2206) hangs off
the I2C pins but does not follow the I2C protocol.  (This work can
also be found in my SVN tree.)

I also took the existing PCMCIA bits from an ep93xx tree, forward
ported that, and submitted it to the pcmcia mailing list for possible
inclusion.


Some of you will know that I've been talking to Cirrus for a while
regarding how to reconcile their tree with the upstream 2.6 tree.

I've spent a lot of time explaining the advantages of working with
the community, I've explained them why their code doesn't really have
a chance to get merged upstream in its current state, and what they
should change to make upstream merging possible.  They thanked me
on more than one occasion for my all my help, and we were discussing
some form of compensation for my efforts.

A couple of days ago this all changed, when they suddenly decided that
all the work I had already done for them would no longer require any
form of compensation, and that the best way forward would be if I give
up maintenance of the Linux ep93xx port so that they can delete all
kernel code that was not written by Cirrus employees (which would
probably mean every single line..) and shove in their ep93xx tree
verbatim, and reject all future contributions from non-Cirrus employees.

This is what they wrote:

        I think we will just maintain our own port for the 93xx.  I
        am not going to want to support code not written by Cirrus
        Logic.  So I give you kuddos for getting to the port first,
        but using GIT makes it easy to remove your work and add ours.
        So since we are current with the linux tree and have all
        periferals supported we will just keep supplying a patch for
        the lastest kernel.

        It is just a matter of splitting hairs on your coding verses
        ours, and I dont want to have to bother with it, as I'm sure
        you wont either.  Nobody here will pay you to maintain our
        code for us, or for that matter wants you to, so we will
        maintain a current git tree and allow our customers to use
        that and contribute to our official port.  You are more than
        welcome to use our code and add it to the official port, but
        we will only support our code for our customers.  And since
        I dont want to have to ask the maintainers to give us the port
        maintenece I will leave it to you.  Good luck!


cheers,
Lennert

Other related posts:

  1. Home
  2. linux-cirrus
  3. Archive
  4. 02-2007