All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ramuthevar, Vadivel MuruganX"  <vadivel.muruganx.ramuthevar@linux.intel.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	devicetree@vger.kernel.org, miquel.raynal@bootlin.com,
	richard@nod.at, vigneshr@ti.com, arnd@arndb.de,
	brendanhiggins@google.com, tglx@linutronix.de,
	anders.roxell@linaro.org, masonccyang@mxic.com.tw,
	robh+dt@kernel.org, linux-mips@vger.kernel.org,
	hauke.mehrtens@intel.com, andriy.shevchenko@intel.com,
	qi-ming.wu@intel.com, cheol.yong.kim@intel.com
Subject: Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Date: Thu, 7 May 2020 14:38:52 +0800	[thread overview]
Message-ID: <69a06362-1f9d-bf65-4a9b-98fc6b63a391@linux.intel.com> (raw)
In-Reply-To: <20200507082730.6425cd96@collabora.com>

Hi Boris,

   Thank you very much for the review comments and your time...

On 7/5/2020 2:27 pm, Boris Brezillon wrote:
> On Thu, 7 May 2020 14:13:42 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> 
>> Hi Boris,
>>
>>      Thank you very much for the review comments and your time...
>>
>> On 7/5/2020 1:28 pm, Boris Brezillon wrote:
>>> On Thu,  7 May 2020 08:15:37 +0800
>>> "Ramuthevar,Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>    
>>>> +	reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
>>>> +	writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN,
>>>> +	       ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
>>>
>>> Seriously, did you really think I would not notice what you're doing
>>> here?
>> Yes , I know that you have very good understanding about this.
>>    You're reading the previous value which either contains a default
>>> mapping or has the mapping set by the bootloader, and write it back to
>>> the register along with a new mask and the REGEN bit set (which
>>> BTW is wrong since you don't mask out other fields before updating
>>> them).
>> There is no other field get overwritten
>>    This confirms that this Core -> FPI address translation exists
>>> and has to be set properly, so please stop lying about that.
>>
>> Sorry, there is no SW translation, as I have mentioned that it's
>> optional only, for safer side , reading and writing the default values.
> 
> Then write EBU_ADDR_SEL_REGEN and we'll if see that works. I suspect it
> won't.

You mean, without reading just writing EBU_ADDR_SEL_REGEN bit alone in 
EBU_ADDR_SELx , as you said it won't work because it overwrites 0x174 
with 0x0 values so BASE is lost.
either we can leave it or read & write with ORed | EBU_ADDR_SEL_REGEN

Please correct me if anything is wrong, Thanks!
> 
>> The memory region to enabled that's my concern so written the same
>> register values.
> 
> I don't buy that, sorry.
> 
>>
>> This will not be impact other fields, so please see below for reference
>>
>> The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish
>> and control memory regions for external accesses.
>>
>> Reset Value: 17400001H
> 
> See, as suspected the reset value is exactly what you expect.

Yes , that's the reason said being optional.

Regards
Vadivel
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Ramuthevar, Vadivel MuruganX" <vadivel.muruganx.ramuthevar@linux.intel.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: cheol.yong.kim@intel.com, devicetree@vger.kernel.org,
	qi-ming.wu@intel.com, anders.roxell@linaro.org, vigneshr@ti.com,
	arnd@arndb.de, hauke.mehrtens@intel.com, richard@nod.at,
	brendanhiggins@google.com, linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org, robh+dt@kernel.org,
	linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
	tglx@linutronix.de, masonccyang@mxic.com.tw,
	andriy.shevchenko@intel.com
Subject: Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Date: Thu, 7 May 2020 14:38:52 +0800	[thread overview]
Message-ID: <69a06362-1f9d-bf65-4a9b-98fc6b63a391@linux.intel.com> (raw)
In-Reply-To: <20200507082730.6425cd96@collabora.com>

Hi Boris,

   Thank you very much for the review comments and your time...

On 7/5/2020 2:27 pm, Boris Brezillon wrote:
> On Thu, 7 May 2020 14:13:42 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> 
>> Hi Boris,
>>
>>      Thank you very much for the review comments and your time...
>>
>> On 7/5/2020 1:28 pm, Boris Brezillon wrote:
>>> On Thu,  7 May 2020 08:15:37 +0800
>>> "Ramuthevar,Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>    
>>>> +	reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
>>>> +	writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN,
>>>> +	       ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
>>>
>>> Seriously, did you really think I would not notice what you're doing
>>> here?
>> Yes , I know that you have very good understanding about this.
>>    You're reading the previous value which either contains a default
>>> mapping or has the mapping set by the bootloader, and write it back to
>>> the register along with a new mask and the REGEN bit set (which
>>> BTW is wrong since you don't mask out other fields before updating
>>> them).
>> There is no other field get overwritten
>>    This confirms that this Core -> FPI address translation exists
>>> and has to be set properly, so please stop lying about that.
>>
>> Sorry, there is no SW translation, as I have mentioned that it's
>> optional only, for safer side , reading and writing the default values.
> 
> Then write EBU_ADDR_SEL_REGEN and we'll if see that works. I suspect it
> won't.

You mean, without reading just writing EBU_ADDR_SEL_REGEN bit alone in 
EBU_ADDR_SELx , as you said it won't work because it overwrites 0x174 
with 0x0 values so BASE is lost.
either we can leave it or read & write with ORed | EBU_ADDR_SEL_REGEN

Please correct me if anything is wrong, Thanks!
> 
>> The memory region to enabled that's my concern so written the same
>> register values.
> 
> I don't buy that, sorry.
> 
>>
>> This will not be impact other fields, so please see below for reference
>>
>> The EBU Address Select Registers EBU_ADDR_SEL_0 to EBU_ADDSEL3 establish
>> and control memory regions for external accesses.
>>
>> Reset Value: 17400001H
> 
> See, as suspected the reset value is exactly what you expect.

Yes , that's the reason said being optional.

Regards
Vadivel
> 

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

  reply	other threads:[~2020-05-07  6:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07  0:15 [PATCH v5 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Ramuthevar,Vadivel MuruganX
2020-05-07  0:15 ` Ramuthevar, Vadivel MuruganX
2020-05-07  0:15 ` [PATCH v5 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support Ramuthevar,Vadivel MuruganX
2020-05-07  0:15   ` Ramuthevar, Vadivel MuruganX
2020-05-11 15:37   ` Rob Herring
2020-05-11 15:37     ` Rob Herring
2020-05-12  3:02     ` Ramuthevar, Vadivel MuruganX
2020-05-12  3:02       ` Ramuthevar, Vadivel MuruganX
2020-05-07  0:15 ` [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC Ramuthevar,Vadivel MuruganX
2020-05-07  0:15   ` Ramuthevar, Vadivel MuruganX
2020-05-07  0:22   ` Randy Dunlap
2020-05-07  0:22     ` Randy Dunlap
2020-05-07  5:57     ` Ramuthevar, Vadivel MuruganX
2020-05-07  5:57       ` Ramuthevar, Vadivel MuruganX
2020-05-07  5:28   ` Boris Brezillon
2020-05-07  5:28     ` Boris Brezillon
2020-05-07  6:13     ` Ramuthevar, Vadivel MuruganX
2020-05-07  6:13       ` Ramuthevar, Vadivel MuruganX
2020-05-07  6:27       ` Boris Brezillon
2020-05-07  6:27         ` Boris Brezillon
2020-05-07  6:38         ` Ramuthevar, Vadivel MuruganX [this message]
2020-05-07  6:38           ` Ramuthevar, Vadivel MuruganX
2020-05-07  6:48           ` Boris Brezillon
2020-05-07  6:48             ` Boris Brezillon
2020-05-08  2:31             ` Ramuthevar, Vadivel MuruganX
2020-05-08  2:31               ` Ramuthevar, Vadivel MuruganX

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=69a06362-1f9d-bf65-4a9b-98fc6b63a391@linux.intel.com \
    --to=vadivel.muruganx.ramuthevar@linux.intel.com \
    --cc=anders.roxell@linaro.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=arnd@arndb.de \
    --cc=boris.brezillon@collabora.com \
    --cc=brendanhiggins@google.com \
    --cc=cheol.yong.kim@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hauke.mehrtens@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=masonccyang@mxic.com.tw \
    --cc=miquel.raynal@bootlin.com \
    --cc=qi-ming.wu@intel.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vigneshr@ti.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.