From mboxrd@z Thu Jan  1 00:00:00 1970
From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia)
Date: Fri, 8 Mar 2013 15:53:52 -0300
Subject: [PATCH 04/10] bus: introduce an Marvell EBU MBus driver
In-Reply-To: <20130308183120.GG4094@obsidianresearch.com>
References: <20130306214036.62fc93b9@skate>
 <20130306215031.GB4916@obsidianresearch.com>
 <20130306222712.GP23237@titan.lakedaemon.net>
 <20130306230412.GA5870@obsidianresearch.com>
 <20130307222004.GA2450@localhost>
 <20130307230516.GA28975@obsidianresearch.com>
 <20130308091052.18612729@skate>
 <20130308172950.GC4094@obsidianresearch.com>
 <20130308175926.GC8693@localhost>
 <20130308183120.GG4094@obsidianresearch.com>
Message-ID: <20130308185350.GA2469@localhost>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Fri, Mar 08, 2013 at 11:31:20AM -0700, Jason Gunthorpe wrote:
> On Fri, Mar 08, 2013 at 02:59:27PM -0300, Ezequiel Garcia wrote:
> 
> > > I looked through Ezequiel's patch and saw a driver that provided those
> > > properties and no user of them at all. Are the patches incomplete? Is
> > > there some plan to use these values in the future?
> 
> > Leaving aside the review comments that still I haven't addressed yet,
> > the patchset is complete.
>  
> > The timings parameters were not set in device tree files,
> > not because I expected the bootloader to set them, but instead because
> > SoC default values worked fine for the NOR devices I tested.
> 
> ? Isn't that the same thing? Were the timing registers the SOC reset
> default or were they leftover from the bootloader?
> 

IMHO, SoC reset default value is not the same as leftover from bootloader,
right?

But this doesn't mean the driver is not useful to set proper parameter
values in case default/bootloader are wrong or suboptimal.

> > If this is suboptimal, I can fix the device tree files in v2
> > to set proper timings parameter values.
> 
> I have no opinion on this for your boards, it depends entirely on what
> flash chips you have to be compatible with, and how you feel about
> your bootloader.
> 
> Also, when looking at the idea from Maxime it occured to me that your
> DT binding might be better using ns or ps for the timings, instead of
> tclk cycles? That way NAND/NOR datasheet values can be included in the
> DT directly and are correct no matter what the tclk frequency is set to.
> 

Mmm... that sounds like a better aproach. I'll think about that.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com