On 17 January 2015 at 17:47, Tony Lindgren <t...@atomide.com> wrote: > Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx
Yes, ditto on dm814x but there things get even more interesting: It has the same four config bits as am335x but moved them to bits 16-19, while bits 0-7 contains 1 << mode. The benefit is that you can also select no mode at all (high-Z or just the pull if enabled) and this is in fact the default, though I'm curious what would happen if multiple bits are set (though not curious enough to risk my hardware :P ). It also means you can change mode with a byte-write to avoid touching the upper bits, which is nice especially since slew is preconfigured per pin to match I/O timings and you're supposed to never change it (after fixing the ones ROM messed up due to bugs). Also on rev 2.x silicon you're not allowed to disable the receiver if using 3.3V I/O. > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) The overall control module layout is actually compatible across the whole happy family; basically any register they have in common is at the same offset (with notable exception of ADC and eCAP event muxes on am335x versus c6a811x/dra62x, but the latter is a semi-mythical device anyway, not even a product brief in circulation). They often even have the same semantics, though padconf shows this isn't always true unfortunately. A similar thing is true for the overall device memory map actually: https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
