| Message ID | 660fa006-4f91-2fb5-ef98-ba0482e1ecff@mothictech.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Tue, Aug 22, 2017 at 05:05:47PM -0400, Brandon Martin wrote: > Document the DT bindings for the rtc-v3020 driver. MMIO and GPIO > attachment modes are both supported via DT. > > Signed-off-by: Brandon Martin <martinbv@mothictech.com> > --- > .../devicetree/bindings/rtc/rtc-v3020.txt | 38 ++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rtc/rtc-v3020.txt > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-v3020.txt b/Documentation/devicetree/bindings/rtc/rtc-v3020.txt > new file mode 100644 > index 000000000000..8b32e6a79960 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rtc/rtc-v3020.txt > @@ -0,0 +1,38 @@ > + EM Micro v3020 RTC > +~~~~~~~~~~~~~~~~~~~~ > + > +Required properties: > + - compatible : "emmicro,v3020" > + > +Required for MMIO connection: > + - reg : should contain registers location and length. Looking at the datasheet, there's really no such thing. You'd have to have some specialized h/w to generate the serial waveform. > + > +Required for GPIO connection: > +- emmicro,use-gpio > +- cs-gpios, wr-gpios, rd-gpios, io-gpios : specify gpios connected to > + corresponding pins of the RTC > + > +Optional properties: > +- emmicro,mmio-left-shift : data bit to which IO line is connected for MMIO > + connection (defaults to 0) This has come up several times on RTCs (LP8841, DS1302). This really looks like SPI and could probably use the spi-gpio bitbang driver. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/25/2017 05:54 PM, Rob Herring wrote: >> + >> +Required for MMIO connection: >> + - reg : should contain registers location and length. > > Looking at the datasheet, there's really no such thing. You'd have to > have some specialized h/w to generate the serial waveform. If it's MMIO attached i.e. hooked up to a single data bit on an otherwise multi-drop, flat addressed external bus, you do have to specify the memory address at which one would access the device. Length is irrelevant, yes, as it has but one externally-accessible "register" in its memory map. Is there a better way to handle this sort of thing than the typical "reg" binding? It certainly seems to map nicely to ioremap(). > >> + >> +Required for GPIO connection: >> +- emmicro,use-gpio >> +- cs-gpios, wr-gpios, rd-gpios, io-gpios : specify gpios connected to >> + corresponding pins of the RTC >> + >> +Optional properties: >> +- emmicro,mmio-left-shift : data bit to which IO line is connected for MMIO >> + connection (defaults to 0) > > This has come up several times on RTCs (LP8841, DS1302). This really > looks like SPI and could probably use the spi-gpio bitbang driver. Indeed it is perhaps like that. This was a comparatively blind pass at DT-izing the existing driver without other changes. It does work and has immediate application on a mainline'd DT board: Compulab CM-T3517 which is in fact what I'm porting to. I don't think you could use spi-gpio bitbang if you had it memory-mapped, and there are actual platforms that do this. Some of Compulab's older PXA based boards appear to do it, and they are in fact the boards still using pdata rather than DT that caused me to keep that around when doing this.
On Fri, Aug 25, 2017 at 5:36 PM, Brandon Martin <martinbv@mothictech.com> wrote: > On 08/25/2017 05:54 PM, Rob Herring wrote: >>> >>> + >>> +Required for MMIO connection: >>> + - reg : should contain registers location and length. >> >> >> Looking at the datasheet, there's really no such thing. You'd have to >> have some specialized h/w to generate the serial waveform. > > > If it's MMIO attached i.e. hooked up to a single data bit on an otherwise > multi-drop, flat addressed external bus, you do have to specify the memory > address at which one would access the device. Length is irrelevant, yes, as > it has but one externally-accessible "register" in its memory map. > > Is there a better way to handle this sort of thing than the typical "reg" > binding? It certainly seems to map nicely to ioremap(). Okay, I guess you should keep that. >>> + >>> +Required for GPIO connection: >>> +- emmicro,use-gpio >>> +- cs-gpios, wr-gpios, rd-gpios, io-gpios : specify gpios connected to >>> + corresponding pins of the RTC >>> + >>> +Optional properties: >>> +- emmicro,mmio-left-shift : data bit to which IO line is connected for >>> MMIO >>> + connection (defaults to 0) >> >> >> This has come up several times on RTCs (LP8841, DS1302). This really >> looks like SPI and could probably use the spi-gpio bitbang driver. > > > Indeed it is perhaps like that. > > This was a comparatively blind pass at DT-izing the existing driver without > other changes. It does work and has immediate application on a mainline'd > DT board: Compulab CM-T3517 which is in fact what I'm porting to. > > I don't think you could use spi-gpio bitbang if you had it memory-mapped, > and there are actual platforms that do this. Some of Compulab's older PXA > based boards appear to do it, and they are in fact the boards still using > pdata rather than DT that caused me to keep that around when doing this. I only meant for the GPIO based connection, that it looks like SPI bitbanging. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/28/2017 02:36 PM, Rob Herring wrote:
> I only meant for the GPIO based connection, that it looks like SPI bitbanging.
I guess the question then becomes if that's an appropriate thing to do
as part of a change set intended only to add DT bindings to an existing
driver. It wouldn't remove much code since much of the bit-banging type
code still needs to remain to support the MMIO mode.
The chip does explicitly support a SPI type connection, but I'm unaware
of any boards using it with a real SPI controller.
diff --git a/Documentation/devicetree/bindings/rtc/rtc-v3020.txt b/Documentation/devicetree/bindings/rtc/rtc-v3020.txt new file mode 100644 index 000000000000..8b32e6a79960 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-v3020.txt @@ -0,0 +1,38 @@ + EM Micro v3020 RTC +~~~~~~~~~~~~~~~~~~~~ + +Required properties: + - compatible : "emmicro,v3020" + +Required for MMIO connection: + - reg : should contain registers location and length. + +Required for GPIO connection: +- emmicro,use-gpio +- cs-gpios, wr-gpios, rd-gpios, io-gpios : specify gpios connected to + corresponding pins of the RTC + +Optional properties: +- emmicro,mmio-left-shift : data bit to which IO line is connected for MMIO + connection (defaults to 0) + +MMIO Example: + + rtc@70 { + ompatible = "emmicro,v3020"; + reg = <1 0x70 1>; + emmicro,mmio-left-shift = <16>; /* IO connected to D16 */ + }; + + +GPIO Example: + + rtc { + compatible = "emmicro,v3020"; + + emmicro,use-gpio; + cs-gpios = <&gpio2 3 0>; + wr-gpios = <&gpio2 4 0>; + rd-gpios = <&gpio2 5 0>; + io-gpios = <&gpio2 6 0>; + };
Document the DT bindings for the rtc-v3020 driver. MMIO and GPIO attachment modes are both supported via DT. Signed-off-by: Brandon Martin <martinbv@mothictech.com> --- .../devicetree/bindings/rtc/rtc-v3020.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-v3020.txt