From: Bert Vermeulen <bert@biot.com>
To: Mark Brown <broonie@kernel.org>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org,
linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org
Subject: Re: [PATCH 1/2] spi: Add SPI driver for Mikrotik RB4xx series boards
Date: Sun, 22 Mar 2015 12:25:24 +0100 [thread overview]
Message-ID: <550EA6A4.6010206@biot.com> (raw)
In-Reply-To: <20150320125139.GJ2869@sirena.org.uk>
On 03/20/2015 01:51 PM, Mark Brown wrote:
Mark,
Thanks very much for your detailed review. I'll fix things according to your
comments. However...
> On Fri, Mar 20, 2015 at 01:16:32PM +0100, Bert Vermeulen wrote:
>> +static void do_spi_byte(void __iomem *base, unsigned char byte)
>> +{
>> + do_spi_clk(base, byte >> 7);
>> + do_spi_clk(base, byte >> 6);
>> + do_spi_clk(base, byte >> 5);
>> + do_spi_clk(base, byte >> 4);
>> + do_spi_clk(base, byte >> 3);
>> + do_spi_clk(base, byte >> 2);
>> + do_spi_clk(base, byte >> 1);
>> + do_spi_clk(base, byte);
>
> This looks awfully like it's bitbanging the value out, can we not use
> spi-bitbang here?
>
[...]
>> +static inline void do_spi_clk_fast(void __iomem *base, unsigned bit1,
>> + unsigned bit2)
>
> Why would we ever want the slow version?
It is bitbanging, at least on write. The hardware has a shift register that
is uses for reads. The generic spi for this board's architecture (ath79)
indeed uses spi-bitbang.
This "fast SPI" thing is what makes this one different: the boot flash and
MMC use regular SPI on the same bus as the CPLD. This CPLD needs this fast
SPI: a mode where it shifts in two bits per clock. The second bit is
apparently sent via the CS2 pin.
So I don't think spi-bitbang will do. I need to see about reworking things
to use less custom queueing -- I'm not that familiar with this yet.
--
Bert Vermeulen bert@biot.com email/xmpp
WARNING: multiple messages have this Message-ID (diff)
From: Bert Vermeulen <bert-Nh2F35Ii2RQ@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/2] spi: Add SPI driver for Mikrotik RB4xx series boards
Date: Sun, 22 Mar 2015 12:25:24 +0100 [thread overview]
Message-ID: <550EA6A4.6010206@biot.com> (raw)
In-Reply-To: <20150320125139.GJ2869-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 03/20/2015 01:51 PM, Mark Brown wrote:
Mark,
Thanks very much for your detailed review. I'll fix things according to your
comments. However...
> On Fri, Mar 20, 2015 at 01:16:32PM +0100, Bert Vermeulen wrote:
>> +static void do_spi_byte(void __iomem *base, unsigned char byte)
>> +{
>> + do_spi_clk(base, byte >> 7);
>> + do_spi_clk(base, byte >> 6);
>> + do_spi_clk(base, byte >> 5);
>> + do_spi_clk(base, byte >> 4);
>> + do_spi_clk(base, byte >> 3);
>> + do_spi_clk(base, byte >> 2);
>> + do_spi_clk(base, byte >> 1);
>> + do_spi_clk(base, byte);
>
> This looks awfully like it's bitbanging the value out, can we not use
> spi-bitbang here?
>
[...]
>> +static inline void do_spi_clk_fast(void __iomem *base, unsigned bit1,
>> + unsigned bit2)
>
> Why would we ever want the slow version?
It is bitbanging, at least on write. The hardware has a shift register that
is uses for reads. The generic spi for this board's architecture (ath79)
indeed uses spi-bitbang.
This "fast SPI" thing is what makes this one different: the boot flash and
MMC use regular SPI on the same bus as the CPLD. This CPLD needs this fast
SPI: a mode where it shifts in two bits per clock. The second bit is
apparently sent via the CS2 pin.
So I don't think spi-bitbang will do. I need to see about reworking things
to use less custom queueing -- I'm not that familiar with this yet.
--
Bert Vermeulen bert-Nh2F35Ii2RQ@public.gmane.org email/xmpp
--
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
next prev parent reply other threads:[~2015-03-22 11:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 12:16 [PATCH 0/2] spi: Add driver for Routerboard RB4xx boards Bert Vermeulen
2015-03-20 12:16 ` [PATCH 1/2] spi: Add SPI driver for Mikrotik RB4xx series boards Bert Vermeulen
2015-03-20 12:51 ` Mark Brown
2015-03-20 12:51 ` Mark Brown
2015-03-22 11:25 ` Bert Vermeulen [this message]
2015-03-22 11:25 ` Bert Vermeulen
2015-03-22 16:17 ` Mark Brown
2015-03-22 16:17 ` Mark Brown
2015-03-20 12:56 ` Mark Brown
2015-03-25 21:40 ` Andy Shevchenko
2015-03-25 21:40 ` Andy Shevchenko
2015-03-20 12:16 ` [PATCH 2/2] spi: Add driver for the CPLD chip on Mikrotik RB4xx boards Bert Vermeulen
2015-03-20 13:28 ` Mark Brown
2015-03-20 13:28 ` Mark Brown
2015-03-25 21:45 ` Andy Shevchenko
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=550EA6A4.6010206@biot.com \
--to=bert@biot.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-spi@vger.kernel.org \
--cc=ralf@linux-mips.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 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.