All of lore.kernel.org
 help / color / mirror / Atom feed
From: Detlef Vollmann <dv@vollmann.ch>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-arm-kernel@lists.infradead.org,
	spi-devel-general@lists.sourceforge.net
Subject: Re: [PATCH 4/7] at91: remove non used at91_spi.h
Date: Sat, 16 Jul 2011 16:00:58 +0200	[thread overview]
Message-ID: <4E21999A.6060105@vollmann.ch> (raw)
In-Reply-To: <20110716115655.GA1992@pengutronix.de>

On 07/16/11 13:56, Wolfram Sang wrote:
>
>>> About the SPI driver:
>>>  From Documentation/spi/spi-summary:
>>> "At this writing, Linux has no slave side programming interface."
>>> So there's no SPI framwork that covers the slave side.
>> This what I mean use the SPI framework and add the SPI Slave support there
>
> [CCing spi-devel]
>
> If you talk about SPI slaves, be sure to have read Grant's comments in
>
> http://thread.gmane.org/gmane.linux.kernel.spi.devel/7401
>
> to see what would be needed for slave support.
I completely agree with Gran't comments here.

> Short note: Would be
> seperate subsystem, master subsystem is of limited use. I think a few
> slave-drivers would be nice to evaluate, so one can get a feeling if a
> subsystem makes sense and if so, how it could look like.
>
> Detlef, have you posted your slave driver so far?
No, and I didn't plan to do so.
Not because I don't want to publish it, if you want to look at it,
I'm happy to send the driver.
But I don't think it makes much sense to put my driver into mainline
Linux.
The reason for this is very simple: the protocol is specific for this
hardware, and the driver needs this specific protocol.
The Atmel hardware is not able to maintain information about frame
ends when running in DMA mode, so we need to put the length of the
frame to the beginning of the frame, and also need to put in some
extra information to be able to re-sync in case of transmission errors.

So this driver is very specific for this hardware, and I wrote SPI
slave drivers in the past for other hardware that were also very
specific.  I really doubt that an SPI slave framework really makes
sense.

And that's the reason why I'm keen that the hardware description
headers are available to out-of-tree drivers.

   Detlef

WARNING: multiple messages have this Message-ID (diff)
From: dv@vollmann.ch (Detlef Vollmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/7] at91: remove non used at91_spi.h
Date: Sat, 16 Jul 2011 16:00:58 +0200	[thread overview]
Message-ID: <4E21999A.6060105@vollmann.ch> (raw)
In-Reply-To: <20110716115655.GA1992@pengutronix.de>

On 07/16/11 13:56, Wolfram Sang wrote:
>
>>> About the SPI driver:
>>>  From Documentation/spi/spi-summary:
>>> "At this writing, Linux has no slave side programming interface."
>>> So there's no SPI framwork that covers the slave side.
>> This what I mean use the SPI framework and add the SPI Slave support there
>
> [CCing spi-devel]
>
> If you talk about SPI slaves, be sure to have read Grant's comments in
>
> http://thread.gmane.org/gmane.linux.kernel.spi.devel/7401
>
> to see what would be needed for slave support.
I completely agree with Gran't comments here.

> Short note: Would be
> seperate subsystem, master subsystem is of limited use. I think a few
> slave-drivers would be nice to evaluate, so one can get a feeling if a
> subsystem makes sense and if so, how it could look like.
>
> Detlef, have you posted your slave driver so far?
No, and I didn't plan to do so.
Not because I don't want to publish it, if you want to look at it,
I'm happy to send the driver.
But I don't think it makes much sense to put my driver into mainline
Linux.
The reason for this is very simple: the protocol is specific for this
hardware, and the driver needs this specific protocol.
The Atmel hardware is not able to maintain information about frame
ends when running in DMA mode, so we need to put the length of the
frame to the beginning of the frame, and also need to put in some
extra information to be able to re-sync in case of transmission errors.

So this driver is very specific for this hardware, and I wrote SPI
slave drivers in the past for other hardware that were also very
specific.  I really doubt that an SPI slave framework really makes
sense.

And that's the reason why I'm keen that the hardware description
headers are available to out-of-tree drivers.

   Detlef

  reply	other threads:[~2011-07-16 14:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14 23:51 [PATCH 1/7] at91rm9200: emac move register header to drivers Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:51 ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52 ` [PATCH 2/7] at91/i2c: " Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52   ` Jean-Christophe PLAGNIOL-VILLARD
     [not found]   ` <1310687525-22486-2-git-send-email-plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
2011-07-15  7:23     ` Jean Delvare
2011-07-15  7:23       ` Jean Delvare
     [not found]       ` <20110715092314.215043d5-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2011-07-15 15:49         ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-15 15:49           ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52 ` [PATCH 3/7] at91_mci: " Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52   ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52 ` [PATCH 4/7] at91: remove non used at91_spi.h Jean-Christophe PLAGNIOL-VILLARD
2011-07-15 11:47   ` Detlef Vollmann
2011-07-15 15:46     ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-15 16:44       ` Detlef Vollmann
2011-07-16 10:57         ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-16 11:56           ` Wolfram Sang
2011-07-16 11:56             ` Wolfram Sang
2011-07-16 14:00             ` Detlef Vollmann [this message]
2011-07-16 14:00               ` Detlef Vollmann
2011-07-17  2:33               ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-17  2:33                 ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-16 13:41           ` Detlef Vollmann
2011-07-17  2:36             ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-18  7:35               ` Andrew Victor
2011-07-14 23:52 ` [PATCH 5/7] at91: remove non used at91_ssc.h Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52 ` [PATCH 6/7] at91rm9200/rtc: move register header to drivers Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52 ` [PATCH 7/7] at91sam9/wdt: " Jean-Christophe PLAGNIOL-VILLARD
2011-07-14 23:52   ` Jean-Christophe PLAGNIOL-VILLARD
2011-07-15 11:04   ` Wim Van Sebroeck
2011-07-15 11:04     ` Wim Van Sebroeck
2011-07-22 18:28   ` Wim Van Sebroeck
2011-07-22 18:28     ` Wim Van Sebroeck

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=4E21999A.6060105@vollmann.ch \
    --to=dv@vollmann.ch \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=w.sang@pengutronix.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.