On Fri, Aug 25, 2017 at 5:36 PM, Brandon Martin <martinbv@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
