All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: x0148406-l0cyMroinI0@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	nsekhar-l0cyMroinI0@public.gmane.org,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Date: Wed, 5 Dec 2012 16:03:03 -0800	[thread overview]
Message-ID: <20121206000302.GM21682@atomide.com> (raw)
In-Reply-To: <20121205232426.BAD573E0E22@localhost>

* Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> [121205 15:26]:
> On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org> wrote:
> > On 12/05/2012 04:22 PM, Grant Likely wrote:
> > > 
> > > Please, be specific. Use something like "ti,am3340-gpmc" or
> > > "ti,omap3430-gpmc". The compatible property is a list so that new
> > > devices can claim compatibility with old. Compatible strings that are
> > > overly generic are a pet-peave of mine.
> > 
> > We aim to use the binding for omap2,3,4,5 as well as the am33xx devices
> > (which are omap based). Would it be sufficient to have "ti,omap2-gpmc"
> > implying all omap2+ based devices or should we have a compatible string
> > for each device supported?
> 
> Are they each register-level compatible with one another?
> 
> The general recommended approach here is to make subsequent silicon
> claim compatibility with the first compatible implementation.
> 
> So, for an am3358 board:
> 	compatible = "ti,am3358-gpmc", "ti,omap2420-gpmc";
> 
> Essentially, what this means is that "ti,omap2420-gpmc" is the generic
> value instead of "omap2-gpmc". The reason for this is so that the value
> is anchored against a specific implementation, and not against something
> completely imaginary or idealized. If a newer version isn't quite
> compatible with the omap2420-gpmc, then it can drop the compatible claim
> and the driver really should be told about the new device.

The compatible property can also be used to figure out which ones
need the workarounds in patch #4 of this series for the DT case.
So we should be specific with the compatible.

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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Date: Wed, 5 Dec 2012 16:03:03 -0800	[thread overview]
Message-ID: <20121206000302.GM21682@atomide.com> (raw)
In-Reply-To: <20121205232426.BAD573E0E22@localhost>

* Grant Likely <grant.likely@secretlab.ca> [121205 15:26]:
> On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter <jon-hunter@ti.com> wrote:
> > On 12/05/2012 04:22 PM, Grant Likely wrote:
> > > 
> > > Please, be specific. Use something like "ti,am3340-gpmc" or
> > > "ti,omap3430-gpmc". The compatible property is a list so that new
> > > devices can claim compatibility with old. Compatible strings that are
> > > overly generic are a pet-peave of mine.
> > 
> > We aim to use the binding for omap2,3,4,5 as well as the am33xx devices
> > (which are omap based). Would it be sufficient to have "ti,omap2-gpmc"
> > implying all omap2+ based devices or should we have a compatible string
> > for each device supported?
> 
> Are they each register-level compatible with one another?
> 
> The general recommended approach here is to make subsequent silicon
> claim compatibility with the first compatible implementation.
> 
> So, for an am3358 board:
> 	compatible = "ti,am3358-gpmc", "ti,omap2420-gpmc";
> 
> Essentially, what this means is that "ti,omap2420-gpmc" is the generic
> value instead of "omap2-gpmc". The reason for this is so that the value
> is anchored against a specific implementation, and not against something
> completely imaginary or idealized. If a newer version isn't quite
> compatible with the omap2420-gpmc, then it can drop the compatible claim
> and the driver really should be told about the new device.

The compatible property can also be used to figure out which ones
need the workarounds in patch #4 of this series for the DT case.
So we should be specific with the compatible.

Regards,

Tony

  reply	other threads:[~2012-12-06  0:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05 19:09 [PATCH v7 0/5] OMAP GPMC DT bindings Daniel Mack
2012-12-05 19:09 ` Daniel Mack
2012-12-05 19:09 ` [PATCH v7 1/5] ARM: OMAP: gpmc: don't create devices from initcall on DT Daniel Mack
2012-12-05 19:09   ` Daniel Mack
2012-12-05 19:09 ` [PATCH v7 2/5] mtd: omap-nand: pass device_node in platform data Daniel Mack
2012-12-05 19:09   ` Daniel Mack
2012-12-05 19:09 ` [PATCH v7 3/5] ARM: OMAP: gpmc-nand: drop __init annotation Daniel Mack
2012-12-05 19:09   ` Daniel Mack
2012-12-05 19:09 ` [PATCH v7 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Daniel Mack
2012-12-05 19:09   ` Daniel Mack
2012-12-05 19:09 ` [PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND Daniel Mack
2012-12-05 19:09   ` Daniel Mack
2012-12-05 22:22   ` Grant Likely
2012-12-05 22:22     ` Grant Likely
2012-12-05 22:33     ` Jon Hunter
2012-12-05 22:33       ` Jon Hunter
2012-12-05 23:24       ` Grant Likely
2012-12-05 23:24         ` Grant Likely
2012-12-06  0:03         ` Tony Lindgren [this message]
2012-12-06  0:03           ` Tony Lindgren
     [not found]           ` <20121206000302.GM21682-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2012-12-06 16:22             ` Jon Hunter
2012-12-06 16:22               ` Jon Hunter
     [not found]               ` <50C0C646.9000802-l0cyMroinI0@public.gmane.org>
2012-12-06 16:54                 ` Daniel Mack
2012-12-06 16:54                   ` Daniel Mack
     [not found]                   ` <50C0CDB0.5050008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06 18:11                     ` Jon Hunter
2012-12-06 18:11                       ` Jon Hunter
2012-12-06 16:19         ` Jon Hunter
2012-12-06 16:19           ` Jon Hunter
     [not found]           ` <50C0C5AB.3030201-l0cyMroinI0@public.gmane.org>
2012-12-06 16:59             ` Daniel Mack
2012-12-06 16:59               ` Daniel Mack
2012-12-12  9:13           ` Daniel Mack
2012-12-12  9:13             ` Daniel Mack
     [not found]             ` <50C84AC6.5030307-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-12 23:02               ` Jon Hunter
2012-12-12 23:02                 ` Jon Hunter
2012-12-15  0:37                 ` Grant Likely
2012-12-15  0:37                   ` Grant Likely
     [not found] ` <1354734571-10774-1-git-send-email-zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-05 19:22   ` [PATCH v7 0/5] OMAP GPMC DT bindings Jon Hunter
2012-12-05 19:22     ` Jon Hunter
2012-12-05 19:24     ` Daniel Mack
2012-12-05 19:24       ` Daniel Mack

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=20121206000302.GM21682@atomide.com \
    --to=tony-4v6ys6ai5vpbdgjk7y7tuq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nsekhar-l0cyMroinI0@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=x0148406-l0cyMroinI0@public.gmane.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 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.