linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Additional SPI-master parameters per SPI-Device in device-tree
Date: Tue, 04 Aug 2015 08:39:20 +0200	[thread overview]
Message-ID: <55C05E18.600@martin.sperl.org> (raw)

Hi!

How could we implement additional per spi-device parameters that
are interesting to the spi-master.

Examples for the spi-bcm2835 master for example could be:
* set minimum transfer size for dma to something else but the default
    (of 96 bytes - setting for something high would disable it)
* change polling transfer limits (i.e disable it)

Implementing these on a spi-master level is easy during probe.

So I wonder if the following approach would be acceptable
to implement device-tree parsing on the device for master
specific parameters:

int bcm2835_spi_setup(struct spi_device *spi)
{
   struct bcm2835_spi_dev *cs = spi->controller_state;
   if (!cs) {
     cs = devm_kzalloc(&spi->dev, sizeof(struct bcm2835_spi_dev), 0);
     if (!cs)
         return -ENOMEM;
     spi->controller_state = cs;

     /* parse device-tree and assign to controller_state */
     cs->polling_limit = master_bs->polling_limit;
     of_property_read_u32(nc, "spi-bcm2835-polling-limit", 
&cs->polling_limit);
     cs->dma_limit = master_bs->dma_limit;
     of_property_read_u32(nc, "spi-bcm2835-dma-limit", &cs->polling_limit);
   }
   ...
   return 0;
}

Or would it be better if we included an additional master method
that would get called from spi_add_device to do this kind of setup?
say:
   int add_device(struct spi_master *master, struct spi_device *spi);
(possibly also one called when removing the device)

Thanks,
                 Martin

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2015-08-04  6:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04  6:39 Martin Sperl [this message]
     [not found] ` <55C05E18.600-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2015-08-04  9:54   ` Additional SPI-master parameters per SPI-Device in device-tree Mark Brown
     [not found]     ` <20150804095443.GH20873-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-04 10:09       ` Martin Sperl
     [not found]         ` <55C08F70.5070303-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2015-08-04 11:15           ` Mark Brown
     [not found]             ` <20150804111528.GL20873-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-04 11:37               ` Martin Sperl
     [not found]                 ` <55C0A40C.5070806-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2015-08-04 15:00                   ` Mark Brown

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=55C05E18.600@martin.sperl.org \
    --to=kernel-tqfnsx0mhmxhksadf0wuew@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).