From: Sergei Ianovich <ynvich@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>
Subject: Re: [PATCH v1] spi: master driver to enable RTC on ICPDAS LP-8841
Date: Mon, 22 Feb 2016 12:26:14 +0300 [thread overview]
Message-ID: <1456133174.2386.33.camel@gmail.com> (raw)
In-Reply-To: <20160222031027.GP18327@sirena.org.uk>
On Mon, 2016-02-22 at 12:10 +0900, Mark Brown wrote:
> On Mon, Feb 22, 2016 at 04:47:06AM +0300, Sergei Ianovich wrote:
> > ICP DAS LP-8841 contains a DS-1302 RTC. This driver provides an SPI
> > master which makes the RTC usable. The driver is not supposed to
> > work
> > with anything else.
>
> So this is something that is internal to a single chip or something?
> I'm slightly unclear from the above if this is or is not a SPI
> controller. If it isn't generic the DT should probably just describe
> the IP and let the driver create the SPI controller and device if
> that
> is an expedient way of doing things.
>
> > +spi0@901c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "icpdas,spi-lp8841-rtc";
> > + reg = <0x901c 0x1>;
> > +
> > + rtc@0 {
> > + compatible = "maxim,rtc-ds1302";
> > + reg = <0>;
> > + spi-max-frequency = <500000>;
> > + spi-3wire;
> > + spi-lsb-first;
> > + spi-cs-high;
> > + };
> > +};
>
> This example makes it seem like an actual SPI controller but just one
> that's broken/limited?
Yes. This is an actual SPI controller with minimal required
functionality. I didn't implement anything I don't need.
> > +config SPI_LP8841_RTC
> > + tristate "ICP DAS LP-8841 SPI Controller for RTC"
> > + depends on OF && (MACH_PXA27X_DT || COMPILE_TEST)
>
> Does this need a strict DT dependency or can it build without DT?
The driver can only be useful on a single industrial PC. That PC
requires DT, so I made this a strict dependency. The dependency can be
removed by using ifdefs, but I see no point why.
> > +/*
> > + * REVISIT If there is support for SPI_3WIRE and SPI_LSB_FIRST in
> > SPI
> > + * GPIO driver, this SPI driver can be replaced by a simple GPIO
> > driver
> > + * providing 3 GPIO pins.
> > + */
>
> What's the advantage of not doing that? Overall the driver looks
> fairly
> good but it does seem to just implement a straight bitbanging driver
> with less flexibility.
MicroWire (SPI_3WIRE) mode is slightly different from the modes
implemented in spi-bitbang-txrx.h. I was getting junk from device in
both Mode0 and Mode2 until I changed the implementation. The change is
documented in the patch.
There will also need to be changes in bitbang.c. SPI_LSB_FIRST will
require a new flasg in txrx_word(). To keep overhead low will require
to grow txrx_word[] from 4 to 16 or even 32. CPOL, CPHA, LSB_FIRST,
3_WIRE each requires an additional power of 2.
While this change could be benefitial to both spi-gpio and spi-bitbang,
it is very big.
> > +#ifndef DRIVER_NAME
> > +#define DRIVER_NAME "spi_lp8841_rtc"
> > +#endif
>
> If you want to use a define for this just use a define for it, don't
> do
> this ifdef stuff.
Yes, I'll fix this. This has been blindly copied from spi-gpio.c.
> > +static inline void
> > +spidelay(unsigned usec)
> > +{
> > + usleep_range(usec, usec + 1);
> > +}
>
> Just use usleep_range() directly.
Yes, I will.
> > +static void
> > +spi_lp8841_rtc_cleanup(struct spi_device *spi)
> > +{
> > +}
>
> Remove empty functions, if they can be empty the core will support
> ignoring them if they are missing.
Yes, I will.
Thanks for a lightning fast review.
> >
next prev parent reply other threads:[~2016-02-22 9:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 1:47 [PATCH v1] spi: master driver to enable RTC on ICPDAS LP-8841 Sergei Ianovich
2016-02-22 9:40 ` [PATCH v2] " Sergei Ianovich
[not found] ` <1456134057-9824-1-git-send-email-ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-22 10:39 ` Mark Brown
2016-02-22 11:57 ` [PATCH v3] " Sergei Ianovich
[not found] ` <1456142265-12925-1-git-send-email-ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-22 21:27 ` Mark Brown
[not found] ` <1456105630-28914-1-git-send-email-ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-22 3:10 ` [PATCH v1] " Mark Brown
2016-02-22 9:26 ` Sergei Ianovich [this message]
[not found] ` <1456133174.2386.33.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-22 11:08 ` Mark Brown
2016-02-22 17:55 ` Rob Herring
2016-02-23 10:44 ` [PATCH v4] " Sergei Ianovich
[not found] ` <1456224272-4391-1-git-send-email-ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-23 23:28 ` Rob Herring
2016-02-24 4:09 ` 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=1456133174.2386.33.camel@gmail.com \
--to=ynvich@gmail.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.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).