From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chee, Tien Fong <tien.fong.chee@intel.com>
Date: Mon, 19 Dec 2016 09:30:36 +0000
Subject: [U-Boot] [PATCH 06/10] arm: socfpga: arria10: Added drivers for
 Arria10 Reset Manager
In-Reply-To: <e75b715a-3df3-c4f4-4bb5-584f8d22f9a0@denx.de>
References: <1481011707-3639-1-git-send-email-tien.fong.chee@intel.com>
 <a276800c-9a06-2ac1-89f8-f29103d1043d@denx.de>
 <1481111927.2741.32.camel@intel.com>
 <01a4cb89-49ce-1bba-80e1-2a09812aeee2@denx.de>
 <1481277869.2741.49.camel@intel.com>
 <0415eee6-a108-9a08-1821-8d45ca9448da@denx.de>
 <1482130429.2382.21.camel@intel.com>
 <e75b715a-3df3-c4f4-4bb5-584f8d22f9a0@denx.de>
Message-ID: <1482139835.2382.30.camel@intel.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Isn, 2016-12-19 at 08:47 +0100, Marek Vasut wrote:
> On 12/19/2016 07:53 AM, Chee, Tien Fong wrote:
> > 
> > On Jum, 2016-12-09 at 13:51 +0100, Marek Vasut wrote:
> > > 
> > > On 12/09/2016 11:04 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Rab, 2016-12-07 at 14:58 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 12/07/2016 12:58 PM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sel, 2016-12-06 at 13:55 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 12/06/2016 09:08 AM, Chee Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > > > > 
> > > > > > > > Drivers for reset manager is restructured such that
> > > > > > > > common
> > > > > > > > functions,
> > > > > > > > gen5 drivers and Arria10 drivers are moved to
> > > > > > > > reset_manager.c,
> > > > > > > > reset_manager_gen5.c and reset_manager_arria10.c
> > > > > > > > respectively.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com
> > > > > > > > >
> > > > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > > > Cc: Dinh Nguyen <dinguyen@kernel.org>
> > > > > > > > Cc: Chin Liang See <chin.liang.see@intel.com>
> > > > > > > > Cc: Tien Fong <skywindctf@gmail.com>
> > > > > [...]
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +void reset_deassert_dedicated_peripherals(void)
> > > > > > > > +{
> > > > > > > > +	int i;
> > > > > > > > +	u32 mask0 = 0;
> > > > > > > > +	u32 mask1 = 0;
> > > > > > > > +	u32 pinmux_addr =
> > > > > > > > SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS;
> > > > > > > > +	u32 mask = 0;
> > > > > > > > +#if defined(CONFIG_MMC)
> > > > > > > > +	mask |=
> > > > > > > > ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK;
> > > > > > > > +#elif defined(CONFIG_CADENCE_QSPI)
> > > > > > > > +	mask |= ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK;
> > > > > > > > +#elif defined(CONFIG_NAND_DENALI)
> > > > > > > > +	mask |= ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK;
> > > > > > > > +#else
> > > > > > > Shouldn't this come from OF instead of being ifdef'd ?
> > > > > > > 
> > > > > > What is OF?
> > > > > Device Tree (Open Firmware).
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > what is your suggestion to make this function generic for
> > > > > > all type of flash?
> > > > > Pull it from OF ?
> > > > > 
> > > > Why you prefer device tree implementation over #define in
> > > > defconfig,
> > > > because there is performance penalty.
> > > Because we are moving away from excessive random #defines and
> > > toward
> > > having one single binary where you could exchange just the DT and
> > > run
> > > it on multiple boards, just like Linux, that is the ultimate
> > > goal.
> > > 
> > > Also, this is not performance critical code, is it.
> > > 
> > This code just to release peripherals from reset, not performance
> > critical codes. However, our defconfigs based on flash type
> > booting, so
> > this is why i din't use the DT, since we have flash type determined
> > from defconfig. Since DT is ultimate goal, i can change to DT
> > implementation.
> You should really only unreset the peripherals which you need and,
> ideally, only when you need them. So it should be the driver which
> handles the peripheral reset, not the common code (unless there is
> a reason for the common code to do it).
> 
Yeah, i agree with you too. Did our cyclone5 implement this also?
Does DM has framework to support ?user define reset mechanism?