All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Bean Huo <beanhuo@outlook.com>
Cc: "dwmw2@infradead.org" <dwmw2@infradead.org>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	"richard@nod.at" <richard@nod.at>,
	"cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	beanhuo <beanhuo@micron.com>,
	"boris.brezillon@free-electrons.com"
	<boris.brezillon@free-electrons.com>
Subject: Re: [PATCH v1 1/3] mtd: physmap: add dual die entry in devicetree binding
Date: Fri, 23 Feb 2018 16:53:40 +0100	[thread overview]
Message-ID: <20180223165340.24bb2c6c@bbrezillon> (raw)
In-Reply-To: <DM2PR12MB0014BEF2B19FED0392EB0366A6CC0@DM2PR12MB0014.namprd12.prod.outlook.com>

On Fri, 23 Feb 2018 11:07:17 +0000
Bean Huo <beanhuo@outlook.com> wrote:

> Boris,
> thanks for the review.
> 
> >> + - dual-die-stack: boolean to enable support for the devices with the
> >> +   two dies in stack.  
> 
> >How about making that more future proof and adding a property that
> >directly contains the number of dies (num-dies)?  
> 
> Exactly, I also thought here should add a property, through which it can be compatible
> with all kinds of PNOR for the future more dies stacked device.
> But currently, it doesn't exist  PNOR device with more than two dies, and we
> have no idea about 4/6 dies stacked device operation sequence. so I simply add a boolean
> entry and try to only enable dual-die stacked PNOR firstly.

Actually, I think it's better to think about future evolutions now than
adding a new property every time a vendor decides to add more dies (I
guess the number of dies will always be a power-of-2).

> 
> Maybe I can try to do that in next version patch. the software implementation is so flexible.
> 
> >>
> >>  For JEDEC compatible devices, the following additional properties
> >>  are defined:  
> 



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Bean Huo <beanhuo@outlook.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"boris.brezillon@free-electrons.com"
	<boris.brezillon@free-electrons.com>,
	"richard@nod.at" <richard@nod.at>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	beanhuo <beanhuo@micron.com>
Subject: Re: [PATCH v1 1/3] mtd: physmap: add dual die entry in devicetree binding
Date: Fri, 23 Feb 2018 16:53:40 +0100	[thread overview]
Message-ID: <20180223165340.24bb2c6c@bbrezillon> (raw)
In-Reply-To: <DM2PR12MB0014BEF2B19FED0392EB0366A6CC0@DM2PR12MB0014.namprd12.prod.outlook.com>

On Fri, 23 Feb 2018 11:07:17 +0000
Bean Huo <beanhuo@outlook.com> wrote:

> Boris,
> thanks for the review.
> 
> >> + - dual-die-stack: boolean to enable support for the devices with the
> >> +   two dies in stack.  
> 
> >How about making that more future proof and adding a property that
> >directly contains the number of dies (num-dies)?  
> 
> Exactly, I also thought here should add a property, through which it can be compatible
> with all kinds of PNOR for the future more dies stacked device.
> But currently, it doesn't exist  PNOR device with more than two dies, and we
> have no idea about 4/6 dies stacked device operation sequence. so I simply add a boolean
> entry and try to only enable dual-die stacked PNOR firstly.

Actually, I think it's better to think about future evolutions now than
adding a new property every time a vendor decides to add more dies (I
guess the number of dies will always be a power-of-2).

> 
> Maybe I can try to do that in next version patch. the software implementation is so flexible.
> 
> >>
> >>  For JEDEC compatible devices, the following additional properties
> >>  are defined:  
> 



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2018-02-23 15:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1519241514-6466-1-git-send-email-beanhuo@outlook.com>
2018-02-21 19:32 ` [PATCH v1 1/3] mtd: physmap: add dual die entry in devicetree binding Bean Huo
2018-02-21 19:32   ` Bean Huo
2018-02-22 13:05   ` Boris Brezillon
2018-02-22 13:05     ` Boris Brezillon
2018-02-23 11:07     ` Bean Huo
2018-02-23 11:07       ` Bean Huo
2018-02-23 15:53       ` Boris Brezillon [this message]
2018-02-23 15:53         ` Boris Brezillon
2018-02-21 19:32 ` [PATCH v1 2/3] mtd: probe: probe dual die entry from " Bean Huo
2018-02-21 19:32   ` Bean Huo
2018-02-22 13:02   ` Boris Brezillon
2018-02-22 13:02     ` Boris Brezillon
2018-02-23 11:14     ` Bean Huo
2018-02-23 11:14       ` Bean Huo
2018-02-21 19:32 ` [PATCH v1 3/3] drivers: mtd: chips: add support for the dual die stacked PNOR Bean Huo
2018-02-21 19:32   ` Bean Huo
2018-02-22 13:33   ` Boris Brezillon
2018-02-22 13:33     ` Boris Brezillon
2018-02-23 11:43     ` Bean Huo
2018-02-23 15:49       ` Boris Brezillon

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=20180223165340.24bb2c6c@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=beanhuo@micron.com \
    --cc=beanhuo@outlook.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.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.