All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <oss@buserror.net>
To: Boris Brezillon <boris.brezillon@free-electrons.com>,
	Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Richard Weinberger <richard@nod.at>,
	u-boot@lists.denx.de,
	"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Alexander Kaplan <alex@nextthing.co>,
	Brian Norris <computersforpeace@gmail.com>
Subject: Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
Date: Tue, 03 May 2016 00:06:45 -0500	[thread overview]
Message-ID: <1462252005.16584.34.camel@buserror.net> (raw)
In-Reply-To: <20160425225357.7bb6338d@bbrezillon>

On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote:
> On Mon, 25 Apr 2016 13:36:46 -0400
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> > 
> > > Hi Scott,
> > > 
> > > I've recently contributed a lot of MTD/NAND related patches (and intend
> > > to continue doing so). Some of them are transversal changes touching the
> > > MTD and NAND framework internals, which implies patching all NAND
> > > drivers along with the core changes.
> > > 
> > > All those changes are required to properly handle modern NANDs (MLC/TLC
> > > NANDs), and I need them to add proper NAND support to the sunxi
> > > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > > 
> > > So my question is, how should I port those changes to U-Boot? I see
> > > that your doing "synchronization commits", but in my case this mean
> > > including a bunch of driver specific changes into this "sync commit".
> > > 
> > > I think it's also worth mentioning that I plan to heavily rework the
> > > Linux NAND framework to improve NAND performances on modern NAND
> > > controllers and clarify the NAND chip / NAND controller concepts, and
> > > other people are also working on merging the BBT code of the NAND and
> > > OneNAND framework. Which unfortunately means that we're not done porting
> > > invasive changes to U-Boot :-/.
> > > 
> > > Any advice is welcome.  
> > 
> > I suppose my first suggestion would be to sync the kernel back into
> > U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> > be too hard to pick a window to grab the current kernel release and
> > bring it over.  I think the more stuff we let build up prior to syncing
> > the harder it will be.
> > 
> 
> Okay, so this means I should be the one back-porting Linux changes into
> U-Boot? I was planning on porting my current work on the sunxi NAND
> driver (including all the core dependencies) and submitting it to
> U-Boot, but honestly, I don't see how I can keep things in sync in the
> long run. From my experience, porting things to U-Boot is never as
> easy at it seems, and I don't think I'll have the time to maintain that
> by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
> Can I expect some help from your side?

I usually do syncs when someone complains about needing a sync.  Every release
seems a bit much.  I'll try to do one soon.

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <oss@buserror.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
Date: Tue, 03 May 2016 00:06:45 -0500	[thread overview]
Message-ID: <1462252005.16584.34.camel@buserror.net> (raw)
In-Reply-To: <20160425225357.7bb6338d@bbrezillon>

On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote:
> On Mon, 25 Apr 2016 13:36:46 -0400
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> > 
> > > Hi Scott,
> > > 
> > > I've recently contributed a lot of MTD/NAND related patches (and intend
> > > to continue doing so). Some of them are transversal changes touching the
> > > MTD and NAND framework internals, which implies patching all NAND
> > > drivers along with the core changes.
> > > 
> > > All those changes are required to properly handle modern NANDs (MLC/TLC
> > > NANDs), and I need them to add proper NAND support to the sunxi
> > > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > > 
> > > So my question is, how should I port those changes to U-Boot? I see
> > > that your doing "synchronization commits", but in my case this mean
> > > including a bunch of driver specific changes into this "sync commit".
> > > 
> > > I think it's also worth mentioning that I plan to heavily rework the
> > > Linux NAND framework to improve NAND performances on modern NAND
> > > controllers and clarify the NAND chip / NAND controller concepts, and
> > > other people are also working on merging the BBT code of the NAND and
> > > OneNAND framework. Which unfortunately means that we're not done porting
> > > invasive changes to U-Boot :-/.
> > > 
> > > Any advice is welcome.  
> > 
> > I suppose my first suggestion would be to sync the kernel back into
> > U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> > be too hard to pick a window to grab the current kernel release and
> > bring it over.  I think the more stuff we let build up prior to syncing
> > the harder it will be.
> > 
> 
> Okay, so this means I should be the one back-porting Linux changes into
> U-Boot? I was planning on porting my current work on the sunxi NAND
> driver (including all the core dependencies) and submitting it to
> U-Boot, but honestly, I don't see how I can keep things in sync in the
> long run. From my experience, porting things to U-Boot is never as
> easy at it seems, and I don't think I'll have the time to maintain that
> by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
> Can I expect some help from your side?

I usually do syncs when someone complains about needing a sync.  Every release
seems a bit much.  I'll try to do one soon.

-Scott

  reply	other threads:[~2016-05-03  5:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 14:43 Porting Linux's MTD/NAND changes into U-Boot Boris Brezillon
2016-04-25 14:43 ` [U-Boot] " Boris Brezillon
2016-04-25 17:36 ` Tom Rini
2016-04-25 17:36   ` Tom Rini
2016-04-25 20:53   ` Boris Brezillon
2016-04-25 20:53     ` Boris Brezillon
2016-05-03  5:06     ` Scott Wood [this message]
2016-05-03  5:06       ` Scott Wood
2016-05-03  7:36       ` Boris Brezillon
2016-05-03  7:36         ` Boris Brezillon
2016-05-16 12:02       ` Boris Brezillon
2016-05-16 12:02         ` Boris Brezillon
2016-05-18  4:38         ` Scott Wood
2016-05-18  4:38           ` Scott Wood
2016-04-26  5:17   ` Heiko Schocher
2016-04-26  5:17     ` Heiko Schocher
2016-04-26  7:20     ` Richard Weinberger
2016-04-26  7:20       ` Richard Weinberger
2016-04-26  8:13       ` Heiko Schocher
2016-04-26  8:13         ` Heiko Schocher

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=1462252005.16584.34.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=alex@nextthing.co \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=marex@denx.de \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=trini@konsulko.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.