From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] Adds driver for Xilinx' xps_spi SPI controller.
Date: Mon, 2 Apr 2012 18:34:41 +0200 [thread overview]
Message-ID: <201204021834.41538.marek.vasut@gmail.com> (raw)
In-Reply-To: <4F79CC28.6080605@threespeedlogic.com>
Dear Graeme Smecher,
> Hi Marek,
>
> On 31/03/12 12:42 PM, Marek Vasut wrote:
> > Dear Graeme Smecher,
> >
> >> Hi Wolfgang,
> >>
> >> On 18/09/10 01:02 PM, Wolfgang Denk wrote:
> >>> Dear Graeme Smecher,
> >>>
> >>> In
> >>> message<1280955847-2999-1-git-send-email-graeme.smecher@mail.mcgill.ca
> >>> >
> >
> > you wrote:
> >>>> This code differs in only trivial ways from the altera_spi driver. It
> >>>> plays nice with Thomas Chou's mmc_spi driver, as well as with SPI
> >>>> flash.
> >>>
> >>> Hm... if the core really differs in only trivial ways from the
> >>> altera_spi driver, then why do we need a duplication of that code?
> >>>
> >>> Can we plase have a single driver source that supports both instead?
> >>
> >> Hm... It's possible to combine xilinx_spi.c and altera_spi.c. However, I
> >> suspect joining them will make maintenance more complicated rather than
> >> simpler. I can't, for example, test a combined driver on Altera hardware
> >> (and the Altera maintainer will likely have the same problem with Xilinx
> >> hardware.)
> >>
> >> My guess is that most SPI interfaces are nearly identical at a register
> >> level, especially for drivers that don't support interrupts and other
> >> complications. (See mxc_spi.c for another example.) Xilinx and Altera's
> >> SPI interfaces are just two examples that happen to both be FPGA-based
> >> -- I could probably have adapted any of the other SPI drivers instead.
> >>
> >> Are you sure combining drivers is the most logical approach? Let me
> >> know, and I'll have a crack at it.
> >>
> >> thanks,
> >> Graeme
> >
> > What was the conclusion here? Shall I drop the patch or will you submit a
> > rebased version?
>
> Please drop the patch for now, since I'm not in a position to maintain
> it. The trail of bread-crumbs on the mailing list is a good compromise
> until someone (me, later on?) steps up.
Sorry to hear that, though thanks for updating me on the situation :)
> thanks,
> Graeme
Best regards,
Marek Vasut
prev parent reply other threads:[~2012-04-02 16:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 15:47 [U-Boot] [PATCH] Adds driver for Xilinx' xps_spi SPI controller Graeme Smecher
2010-08-03 17:59 ` Mike Frysinger
2010-08-04 21:01 ` Graeme Smecher
2010-08-04 21:04 ` [U-Boot] [PATCH V2] " Graeme Smecher
2010-08-17 16:27 ` Graeme Smecher
2010-08-17 17:25 ` Anatolij Gustschin
2010-08-17 17:34 ` Graeme Smecher
2010-09-18 20:02 ` Wolfgang Denk
2010-09-20 14:43 ` Graeme Smecher
2012-03-31 19:42 ` Marek Vasut
2012-04-02 15:56 ` Graeme Smecher
2012-04-02 16:34 ` Marek Vasut [this message]
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=201204021834.41538.marek.vasut@gmail.com \
--to=marek.vasut@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.