public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] S5P: new spi gpio bitbang driver
Date: Wed, 15 Sep 2010 14:06:32 -0400	[thread overview]
Message-ID: <201009151406.33814.vapier@gentoo.org> (raw)
In-Reply-To: <4C90565C.3000404@samsung.com>

On Wednesday, September 15, 2010 01:15:08 Donghwa Lee wrote:
>  On Tuesday, September 14, 2010 20:48:11 Mike Frysinger wrote:
> > On Tuesday, September 14, 2010 03:38:11 Donghwa Lee wrote:
> >> This patch adds basic support for spi mode 0~3 by control gpio bitbang
> >> in S5P. Original name of this patch was "support spi gpio driver by
> >> control gpio bitbang". But, it had arch-specific features, S5P, so
> >> changed to this name.
> > 
> > so why arent you implementing this with the common spi API ?  then any of
> > the code in the tree would be able to use this spi driver without having
> > to change to your arch-specific API.
> 
> I think common spi API is not appropriate for S5P arch. For example,
> arch-S5P gpio framework consists of many gpio bank structure, and gpio
> number. From here, gpio bank structures are groups of many gpio pin and
> gpio number indicates specific gpio pin of gpio bank group. To control any
> gpio pin in arch S5P, must know about gpio bank and its specific number.
> But, existing spi API is different from avobe.
> For example, spi_setup_slave() function, consists of 4 function parameter,
> bus, cs, max_hz and mode. bus and cs is specific gpio number that not gpio
> bank group. so I think it is hard to control gpio without modifying API
> format.

i dont see how this matters.  implement the common gpio api and handle the 
binding of a unique number to specific bank/pin there.  then the spi/gpio 
layer need not care about how gpios are implement on any arch.

the Blackfin port already does this.  each variant has a different number of 
gpio ports with a different number of pins in each bank.  you can see in 
arch/blackfin/include/asm/mach-*/gpio.h how we then normalize the banks/pins 
into numbers from 0 to <gpio max for that arch>.  then spi layer simply says 
"give me gpio 12" and the gpio layer takes care of the port/pin layer.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100915/d0cb6e27/attachment.pgp 

  reply	other threads:[~2010-09-15 18:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14  7:38 [U-Boot] [PATCH] S5P: new spi gpio bitbang driver Donghwa Lee
2010-09-14 11:48 ` Mike Frysinger
2010-09-15  5:15   ` Donghwa Lee
2010-09-15 18:06     ` Mike Frysinger [this message]
2010-09-16  2:38       ` Donghwa Lee
2010-09-16  6:17         ` Mike Frysinger

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=201009151406.33814.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox