All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	Milton Miller <miltonm@bga.com>,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Date: Mon, 04 Jun 2007 16:41:54 +0400	[thread overview]
Message-ID: <46640892.2030408@ru.mvista.com> (raw)
In-Reply-To: <1180905120.31677.22.camel@localhost.localdomain>

Hello.

Benjamin Herrenschmidt wrote:

>>    No, it doesn't -- since that info is almost *absolutely* useless
>>(the only 
>>exception is "cfi") in the context of Linux MTD subsys.
>>    Please, try to understand that knowing that chip is CFI compatible in 
>>itself doesn't yet guarantee that you can access the chip -- it all depends on 
>>its mapping to the real physical address range, therefore this group IMO 
>>cannot even constitute a valid "compatible" property.

> You make no sense to me. It's like saying that knowing that a 8250 chip
> on ISA cannot be accessed if you don't know it's IO ports so it
> shouldn't say "8250" in compatible property ?!?!?!?

    No, it's a completely different case.  Base address and even flash size 
are not the only things that matter.  There's bus width and interleave factors 
that influence the access (and possibly, byte-swapping too, although this is 
unlikely to happen in PPC world).

> Also, whatever shortcomings of the linux MTD drivers are totally
> irrelevant to what is correct to have in a device-tree. While we do
> tailor our device-tree specification around linux needs in most cases,
> there are cases like this one where common sense should be enough to
> understand that it's not because the linux MTD subsystem, as of today,
> cannot be told what programming interface to use, that we shouldn't
> provide that information in the tree.

    We did provide it, in the form of probing hints ("probe-type" prop).

> Regarding physical address ranges for the flash mapping, I suppose the
> best is to define a property for flash chips for it. 

    Flash chips in themselves have little to do with how they are mapped to 
the physical address space (considers the interleave factor), so that doesn't 
seem a practical idea.

WBR, Sergei

WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	Milton Miller <miltonm@bga.com>
Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Date: Mon, 04 Jun 2007 16:41:54 +0400	[thread overview]
Message-ID: <46640892.2030408@ru.mvista.com> (raw)
In-Reply-To: <1180905120.31677.22.camel@localhost.localdomain>

Hello.

Benjamin Herrenschmidt wrote:

>>    No, it doesn't -- since that info is almost *absolutely* useless
>>(the only 
>>exception is "cfi") in the context of Linux MTD subsys.
>>    Please, try to understand that knowing that chip is CFI compatible in 
>>itself doesn't yet guarantee that you can access the chip -- it all depends on 
>>its mapping to the real physical address range, therefore this group IMO 
>>cannot even constitute a valid "compatible" property.

> You make no sense to me. It's like saying that knowing that a 8250 chip
> on ISA cannot be accessed if you don't know it's IO ports so it
> shouldn't say "8250" in compatible property ?!?!?!?

    No, it's a completely different case.  Base address and even flash size 
are not the only things that matter.  There's bus width and interleave factors 
that influence the access (and possibly, byte-swapping too, although this is 
unlikely to happen in PPC world).

> Also, whatever shortcomings of the linux MTD drivers are totally
> irrelevant to what is correct to have in a device-tree. While we do
> tailor our device-tree specification around linux needs in most cases,
> there are cases like this one where common sense should be enough to
> understand that it's not because the linux MTD subsystem, as of today,
> cannot be told what programming interface to use, that we shouldn't
> provide that information in the tree.

    We did provide it, in the form of probing hints ("probe-type" prop).

> Regarding physical address ranges for the flash mapping, I suppose the
> best is to define a property for flash chips for it. 

    Flash chips in themselves have little to do with how they are mapped to 
the physical address space (considers the interleave factor), so that doesn't 
seem a practical idea.

WBR, Sergei

  parent reply	other threads:[~2007-06-04 12:40 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-02  4:30 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Milton Miller
2007-06-02  7:39 ` Benjamin Herrenschmidt
2007-06-03 16:10   ` Sergei Shtylyov
2007-06-03 17:36     ` Segher Boessenkool
2007-06-03 18:03       ` Sergei Shtylyov
2007-06-03 18:03         ` Sergei Shtylyov
2007-06-03 18:25         ` Segher Boessenkool
2007-06-03 18:25           ` Segher Boessenkool
2007-06-03 18:36           ` Sergei Shtylyov
2007-06-03 18:36             ` Sergei Shtylyov
2007-06-03 18:46             ` Segher Boessenkool
2007-06-03 18:46               ` Segher Boessenkool
2007-06-03 19:16               ` Sergei Shtylyov
2007-06-03 19:16                 ` Sergei Shtylyov
2007-06-03 21:04         ` Benjamin Herrenschmidt
2007-06-03 21:04           ` Benjamin Herrenschmidt
2007-06-04 12:34           ` Sergei Shtylyov
2007-06-04 12:34             ` Sergei Shtylyov
2007-06-04 14:37             ` Segher Boessenkool
2007-06-04 14:37               ` Segher Boessenkool
2007-06-04 14:49               ` Sergei Shtylyov
2007-06-04 14:49                 ` Sergei Shtylyov
2007-06-07 14:53           ` David Woodhouse
2007-06-07 14:53             ` David Woodhouse
2007-06-07 15:49             ` Segher Boessenkool
2007-06-07 15:49               ` Segher Boessenkool
2007-06-07 14:47         ` David Woodhouse
2007-06-07 14:47           ` David Woodhouse
2007-06-07 15:32           ` Segher Boessenkool
2007-06-07 15:32             ` Segher Boessenkool
2007-06-02  8:53 ` Segher Boessenkool
2007-06-03 16:22   ` Sergei Shtylyov
2007-06-03 17:40     ` Segher Boessenkool
2007-06-03 18:31       ` Sergei Shtylyov
2007-06-03 18:44         ` Segher Boessenkool
2007-06-03 19:13           ` Sergei Shtylyov
2007-06-03 19:56             ` Segher Boessenkool
2007-06-03 20:26               ` Sergei Shtylyov
2007-06-04  8:07                 ` Segher Boessenkool
2007-06-04 13:34                   ` Sergei Shtylyov
2007-06-07 15:00                 ` David Woodhouse
2007-06-07 15:00                   ` David Woodhouse
2007-06-07 15:55                   ` Segher Boessenkool
2007-06-07 15:55                     ` Segher Boessenkool
2007-06-07 16:05                     ` David Woodhouse
2007-06-07 16:05                       ` David Woodhouse
2007-06-07 16:46                       ` Segher Boessenkool
2007-06-07 16:46                         ` Segher Boessenkool
2007-06-12  4:44                     ` David Gibson
2007-06-12 10:53                       ` Segher Boessenkool
2007-06-13  3:16                         ` David Gibson
2007-06-13  5:05                           ` Segher Boessenkool
2007-06-13  6:11                             ` David Gibson
2007-06-13  9:10                               ` Segher Boessenkool
2007-06-15  4:12                                 ` David Gibson
2007-06-15 11:22                                   ` Segher Boessenkool
2007-06-15  4:14                     ` David Gibson
2007-06-15  8:42                       ` Segher Boessenkool
2007-06-15  8:47                         ` David Woodhouse
2007-06-15  8:59                           ` Segher Boessenkool
2007-06-03 21:12     ` Benjamin Herrenschmidt
2007-06-03 21:12       ` Benjamin Herrenschmidt
2007-06-04  8:11       ` Segher Boessenkool
2007-06-04  8:11         ` Segher Boessenkool
2007-06-04 13:16         ` Sergei Shtylyov
2007-06-04 13:16           ` Sergei Shtylyov
2007-06-04 12:41       ` Sergei Shtylyov [this message]
2007-06-04 12:41         ` Sergei Shtylyov
2007-06-04 14:49         ` Segher Boessenkool
2007-06-04 14:49           ` Segher Boessenkool
2007-06-04 15:54           ` Sergei Shtylyov
2007-06-04 15:54             ` Sergei Shtylyov
2007-06-03 17:29 ` Sergei Shtylyov
2007-06-03 17:45   ` Segher Boessenkool
2007-06-03 18:18     ` Sergei Shtylyov
2007-06-03 18:43       ` Segher Boessenkool
2007-06-03 18:59         ` Sergei Shtylyov
2007-06-03 19:48           ` Segher Boessenkool
2007-06-03 20:10             ` Sergei Shtylyov
2007-06-04  8:02               ` Segher Boessenkool
2007-06-04 19:40 ` Mark A. Greer
  -- strict thread matches above, loose matches on Subject: below --
2007-06-01 23:20 Mark A. Greer
2007-06-02  8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35   ` Sergei Shtylyov
2007-06-05 21:11     ` Mark A. Greer
2007-06-06 12:41       ` Sergei Shtylyov
2007-06-06 12:41         ` Sergei Shtylyov
2007-06-07 15:08         ` David Woodhouse
2007-06-07 15:08           ` David Woodhouse
2007-06-06  2:39   ` David Gibson
2007-06-07 13:30     ` Segher Boessenkool
2007-06-12  4:42       ` David Gibson
2007-06-12 10:50         ` Segher Boessenkool
2007-06-13  6:12           ` David Gibson
2007-06-13  9:13             ` Segher Boessenkool
2007-06-13  9:19               ` David Gibson
2007-06-13  9:37                 ` Segher Boessenkool
2007-06-14  4:29                   ` David Gibson
2007-06-14  8:00                     ` Segher Boessenkool
2007-06-14 12:39                     ` Sergei Shtylyov
2007-06-14 13:20                       ` Segher Boessenkool
2007-06-14 12:48           ` Sergei Shtylyov
2007-06-14 13:18             ` Segher Boessenkool
2007-06-14 12:50         ` Sergei Shtylyov
2007-06-14 13:43           ` Segher Boessenkool

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=46640892.2030408@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=segher@kernel.crashing.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.