All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Brian Hutchinson <b.hutchman@gmail.com>
Subject: Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
Date: Sat, 17 Jan 2015 10:14:04 -0800	[thread overview]
Message-ID: <20150117181404.GW18552@atomide.com> (raw)
In-Reply-To: <CAALWOA-v=-KZ5W+Giwq9Z7rdA8JM2Q+zgqZPz-5sDrHD_b-_7A@mail.gmail.com>

* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 09:54]:
> On 17 January 2015 at 17:47, Tony Lindgren <tony@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 ).

Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
 
> 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.

Maybe that's why some bits got shifted :) 
 
> > +#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.

Got any generic naming in mind for the helper macro we could use?
 
> A similar thing is true for the overall device memory map actually:
> https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view

Cool, that certainly helps. To me it looks dm814x needs it's own
clock driver for the source clocks, but after that the dividers
are similar to dm816x and am33xx. Have not looked at the am814x
beyond that though.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
Date: Sat, 17 Jan 2015 10:14:04 -0800	[thread overview]
Message-ID: <20150117181404.GW18552@atomide.com> (raw)
In-Reply-To: <CAALWOA-v=-KZ5W+Giwq9Z7rdA8JM2Q+zgqZPz-5sDrHD_b-_7A@mail.gmail.com>

* Matthijs van Duin <matthijsvanduin@gmail.com> [150117 09:54]:
> On 17 January 2015 at 17:47, Tony Lindgren <tony@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 ).

Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0]
bits for MUXMODE instead of just bits [2:0]?
 
> 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.

Maybe that's why some bits got shifted :) 
 
> > +#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.

Got any generic naming in mind for the helper macro we could use?
 
> A similar thing is true for the overall device memory map actually:
> https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view

Cool, that certainly helps. To me it looks dm814x needs it's own
clock driver for the source clocks, but after that the dividers
are similar to dm816x and am33xx. Have not looked at the am814x
beyond that though.

Regards,

Tony

  reply	other threads:[~2015-01-17 18:17 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 23:37 [PATCH 0/4] Device tree related changes to boot dm816x Tony Lindgren
2015-01-13 23:37 ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 1/4] ARM: OMAP2+: Add board-generic.c entry for ti81xx Tony Lindgren
2015-01-13 23:37   ` Tony Lindgren
2015-01-14 13:51   ` Sergei Shtylyov
2015-01-14 13:51     ` Sergei Shtylyov
2015-01-15  0:07     ` Tony Lindgren
2015-01-15  0:07       ` Tony Lindgren
2015-01-19 19:18       ` Tony Lindgren
2015-01-19 19:18         ` Tony Lindgren
2015-01-19 20:42         ` Felipe Balbi
2015-01-19 20:42           ` Felipe Balbi
2015-01-19 21:05           ` Tony Lindgren
2015-01-19 21:05             ` Tony Lindgren
2015-01-19 21:10             ` Felipe Balbi
2015-01-19 21:10               ` Felipe Balbi
2015-01-13 23:37 ` [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration Tony Lindgren
2015-01-13 23:37   ` Tony Lindgren
2015-01-15 21:23   ` Suman Anna
2015-01-15 21:23     ` Suman Anna
2015-01-15 22:59     ` Tony Lindgren
2015-01-15 22:59       ` Tony Lindgren
2015-01-17 16:41       ` Tony Lindgren
2015-01-17 16:41         ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 3/4] ARM: dts: Add basic clocks for dm816x Tony Lindgren
2015-01-13 23:37   ` Tony Lindgren
2015-01-13 23:37 ` [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm Tony Lindgren
2015-01-13 23:37   ` Tony Lindgren
2015-01-17 16:47   ` Tony Lindgren
2015-01-17 16:47     ` Tony Lindgren
2015-01-17 17:51     ` Matthijs van Duin
2015-01-17 17:51       ` Matthijs van Duin
2015-01-17 18:14       ` Tony Lindgren [this message]
2015-01-17 18:14         ` Tony Lindgren
2015-01-17 22:37         ` Matthijs van Duin
2015-01-17 22:37           ` Matthijs van Duin
2015-01-19 17:29           ` Tony Lindgren
2015-01-19 17:29             ` Tony Lindgren
2015-01-22  3:17             ` Matthijs van Duin
2015-01-22  3:17               ` Matthijs van Duin
2015-01-23 16:47               ` Tony Lindgren
2015-01-23 16:47                 ` Tony Lindgren
2015-01-25  8:34                 ` Matthijs van Duin
2015-01-25  8:34                   ` Matthijs van Duin
2015-01-26 15:58                   ` Tony Lindgren
2015-01-26 15:58                     ` Tony Lindgren
2015-01-28 21:43                     ` Matthijs van Duin
2015-01-28 21:43                       ` Matthijs van Duin
2015-02-02 17:44                       ` Tony Lindgren
2015-02-02 17:44                         ` Tony Lindgren
2015-02-03  5:51                         ` Matthijs van Duin
2015-02-03  5:51                           ` Matthijs van Duin
2015-01-28 17:04                 ` Tony Lindgren
2015-01-28 17:04                   ` Tony Lindgren
2015-02-01  1:51     ` Matthijs van Duin
2015-02-01  1:51       ` Matthijs van Duin
2015-02-02 16:09       ` Tony Lindgren
2015-02-02 16:09         ` Tony Lindgren
2015-03-18  0:06         ` Tony Lindgren
2015-03-18  0:06           ` Tony Lindgren
2015-03-18  8:32           ` Matthijs van Duin
2015-03-18  8:32             ` Matthijs van Duin
2015-03-18 16:54             ` Tony Lindgren
2015-03-18 16:54               ` Tony Lindgren
2015-03-19  5:13               ` Matthijs van Duin
2015-03-19  5:13                 ` Matthijs van Duin

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=20150117181404.GW18552@atomide.com \
    --to=tony@atomide.com \
    --cc=b.hutchman@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=matthijsvanduin@gmail.com \
    /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.