All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haavard Skinnemoen <hskinnemoen@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
Date: Sun, 11 Feb 2007 19:04:06 +0100	[thread overview]
Message-ID: <1defaf580702111004m6759e7f8yd03392a9ab7464c4@mail.gmail.com> (raw)
In-Reply-To: <007601c74dfc$13ee7340$01c4af0a@Glamdring>

On 2/11/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> Any duplication causes by this is against code which is not
> yet present in the current source tree, but only against code
> Haavard wants to write.

Ok, I think there's some misunderstanding going on here. I didn't mean
to say that the spi driver _must_ be made common for all chips _now_.
Please disregard my suggestions about a common spi driver for now.
Let's get this stuff moving.

> I do not understand who will be responsible for maintaining
> the spi support for at91 chips if it is rewritten.

I'm responsible for the atmel_spi driver in the Linux kernel which is
on its way into mainstream hopefully any day now (it's been accepted
by the SPI maintainer.) This driver supports AT91RM9200, AT91SAM926x
and AT32AP7000, so I don't see why I can't be responsible for the
u-boot driver as well if nobody else are going to step up.

But let's do it your way for now and move the SPI parts of the
dataflash driver to the CPU directory. We can always change it later,
when support for all boards are in place and it becomes clearer which
parts are shareable and which parts are not.

> Please realize that, while I am providing the patches, I am just taking what
> the Atmel AT91 groups is delivering to the end customers.
> The AT91 group is fed up with zero response
> and has basically given up on trying to get patches approved.

Hmm...that sounds somehow familiar :-P

Hopefully, the new custodian model will improve this.

> I am in no way able to support fully testing significant modifications of
> these
> patches and I belive that if this is done, there will be noone
> accepting responsibility for that these patches actually
> generate U-Boot binaries's which will actually work.

U-boot is a community effort. We depend on an active community to test
non-trivial changes. Michel has already volunteered, that's exactly
what we need.

We can't depend _only_ on the AT91 group to make sure that dataflash
will work on all boards using it, nor can we depend _only_ on the
AVR32 group. As far as I know, none of us are testing any of this on
Blackfin, for example.

Of course, Atmel needs to do testing as well, and it will probably
make sense to offer special "Atmel blessed" versions of u-boot which
have been tested thoroughly on all supported configurations for the
customers that need this. But we can't say that nobody is allowed to
make any changes to the official driver because it has been tested and
we don't want to do it again.

Any changes Atmel does based on such testing should of course be
submitted for inclusion upstream. But for this to work, we do need a
timely response from the upstream maintainers.

> >From what I have seen, the patches from the AT91 group fit closely into the
> current
> way U-Boot is designed, and they should be reviewed by people that
> actually study the patches so that an unbiased opinion is given.

I don't know what you're getting at here, but yes, in order to review
a patch, you _do_ need to study it and give an unbiased opinion. But
it works the other way around too -- if you want review, you _have_ to
be willing to make changes based on that review.

Haavard

  reply	other threads:[~2007-02-11 18:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.12584.1171099992.16820.u-boot-users@lists.sourceforge.net>
2007-02-10 20:31 ` [U-Boot-Users] AT91 NAND om AT91SAM9260EK Ivan Kuten
2007-02-11 16:43   ` Ulf Samuelsson
2007-02-11 18:04     ` Haavard Skinnemoen [this message]
2007-02-11 19:42       ` Ulf Samuelsson
2007-02-11 20:23         ` Haavard Skinnemoen
2007-02-11 20:29           ` Ulf Samuelsson
2007-02-11 20:54             ` Haavard Skinnemoen
2007-02-11 21:10           ` Wolfgang Denk
2007-02-11 21:39             ` Ulf Samuelsson
2007-02-11 23:45               ` Wolfgang Denk
2007-02-12  0:26                 ` Ulf Samuelsson
2007-02-12 15:18                   ` Haavard Skinnemoen
2007-02-12 18:40                     ` Ulf Samuelsson
2007-02-12 19:36                       ` Stefan Roese
2007-02-12 19:37                       ` Haavard Skinnemoen
2007-02-12 20:05                         ` Ulf Samuelsson
2007-02-11 21:54       ` Ulf Samuelsson
2007-02-11 11:49 Michel Benoit
2007-02-11 16:20 ` Ulf Samuelsson
     [not found] <mailman.5069.1170973304.16820.u-boot-users@lists.sourceforge.net>
2007-02-08 22:57 ` Ivan Kuten
     [not found] <c88e466f0702050752t16c18251gcddf40a7ec95469@mail.gmail.com>
2007-02-07 23:17 ` Ulf Samuelsson
2007-02-08  6:06   ` Stefan Roese
2007-02-08  8:34     ` Michel Benoit
2007-02-08 19:25       ` Ulf Samuelsson
2007-02-08 20:58         ` Haavard Skinnemoen
2007-02-08 22:20           ` Ulf Samuelsson
2007-02-09 15:45             ` Haavard Skinnemoen
2007-02-09 19:11               ` Ulf Samuelsson
2007-02-09 19:54                 ` Haavard Skinnemoen
2007-02-09 19:39               ` Wolfgang Denk
2007-02-09 22:18                 ` Ulf Samuelsson
2007-02-09 22:58                   ` Haavard Skinnemoen
2007-02-09 23:20                     ` Ulf Samuelsson
2007-02-09 23:42                       ` Haavard Skinnemoen
2007-02-10  0:10                         ` Ulf Samuelsson
2007-02-10  1:18                       ` Wolfgang Denk
2007-02-10  9:05                         ` Ulf Samuelsson
2007-02-10  7:23                     ` Stefan Roese
2007-02-10  1:15                   ` Wolfgang Denk
2007-02-10  7:32                     ` Stefan Roese
2007-02-10  9:29                     ` Ulf Samuelsson
2007-02-10  1:53       ` Ken Watson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1defaf580702111004m6759e7f8yd03392a9ab7464c4@mail.gmail.com \
    --to=hskinnemoen@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.