mvebu: Device bus driver resurrection

mvebu: Device bus driver resurrection

[Ezequiel Garcia]

Hello everyone,

Now that we've all agreed on a mvebu mbus driver (or a first version of it)
I'd like to resurrect the Device Bus driver.

As far as I can remember, the last things said about this driver were:

  * The timing parameters should be in {nano,pico,etc} seconds,
    instead of ticks.

  * Although not everyone agreed, this driver was a good thing to have
    so we no longer depend on the bootloader setting these parameters.
    
  * The address decoding windows should *not* be setup by this driver,
    but rather be described in the device tree itself.

If anyone has aditional comments, please speak your mind.

My plan is to address all of the above comments, and send a v2 soon.

However, since we do not yet describe the address windows at the device tree,
the plan is to do window allocation/release in this devbus driver
**only as a temporal solution**.

Once the address decoding windows are properly described in the DTS,
we can remove that handling from the driver for good.

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

mvebu: Device bus driver resurrection

[Thomas Petazzoni]

Hello,

On Tue, 26 Mar 2013 09:43:38 -0300, Ezequiel Garcia wrote:

> Now that we've all agreed on a mvebu mbus driver (or a first version of it)
> I'd like to resurrect the Device Bus driver.
> 
> As far as I can remember, the last things said about this driver were:
> 
>   * The timing parameters should be in {nano,pico,etc} seconds,
>     instead of ticks.
> 
>   * Although not everyone agreed, this driver was a good thing to have
>     so we no longer depend on the bootloader setting these parameters.
>     
>   * The address decoding windows should *not* be setup by this driver,
>     but rather be described in the device tree itself.
> 
> If anyone has aditional comments, please speak your mind.
> 
> My plan is to address all of the above comments, and send a v2 soon.
> 
> However, since we do not yet describe the address windows at the device tree,
> the plan is to do window allocation/release in this devbus driver
> **only as a temporal solution**.
> 
> Once the address decoding windows are properly described in the DTS,
> we can remove that handling from the driver for good.
> 
> Does this sound sane enough?

Of course I do agree with your proposal, and I'd like to say that I'm
committed to work on a proper DT binding for the mvebu-mbus driver so
that the static windows can ultimately be defined in the Device Tree.
So what Ezequiel presents here as a temporary solution really is.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

mvebu: Device bus driver resurrection

[Jason Gunthorpe]

On Tue, Mar 26, 2013 at 09:43:38AM -0300, Ezequiel Garcia wrote:
> Hello everyone,
> 
> Now that we've all agreed on a mvebu mbus driver (or a first version of it)
> I'd like to resurrect the Device Bus driver.
> 
> As far as I can remember, the last things said about this driver were:
> 
>   * The timing parameters should be in {nano,pico,etc} seconds,
>     instead of ticks.

Yes, and I saw Rob Herring note that the DT parameters in cases like
that should end in -ps
 
>   * Although not everyone agreed, this driver was a good thing to have
>     so we no longer depend on the bootloader setting these parameters.

Please make the timing parameters mandatory, not optional. If boot
loader set timing is going to be used then this driver should not be
involved. Otherwise the timing should be fully specified and no values
from the bootloader should be retained.

>   * The address decoding windows should *not* be setup by this driver,
>     but rather be described in the device tree itself.

I'm going to suggest you send out a quick DT sample for what you are
thinking, that might save lots of effort?

Jason

mvebu: Device bus driver resurrection

[Thomas Petazzoni]

Dear Jason Gunthorpe,

On Tue, 26 Mar 2013 10:45:05 -0600, Jason Gunthorpe wrote:

> >   * The address decoding windows should *not* be setup by this driver,
> >     but rather be described in the device tree itself.
> 
> I'm going to suggest you send out a quick DT sample for what you are
> thinking, that might save lots of effort?

As far as the mvebu-mbus DT binding is concerned, yes, my plan is to
start a new thread to discuss the DT binding, and get the DT
representation sorted out before doing the necessary changes at the
driver level and therefore save lots of effort, as you suggest.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

mvebu: Device bus driver resurrection

[Ezequiel Garcia]

Hi Jason,

On Tue, Mar 26, 2013 at 10:45:05AM -0600, Jason Gunthorpe wrote:
> On Tue, Mar 26, 2013 at 09:43:38AM -0300, Ezequiel Garcia wrote:
> > Hello everyone,
> > 
> > Now that we've all agreed on a mvebu mbus driver (or a first version of it)
> > I'd like to resurrect the Device Bus driver.
> > 
> > As far as I can remember, the last things said about this driver were:
> > 
> >   * The timing parameters should be in {nano,pico,etc} seconds,
> >     instead of ticks.
> 
> Yes, and I saw Rob Herring note that the DT parameters in cases like
> that should end in -ps
>  
> >   * Although not everyone agreed, this driver was a good thing to have
> >     so we no longer depend on the bootloader setting these parameters.
> 
> Please make the timing parameters mandatory, not optional. If boot
> loader set timing is going to be used then this driver should not be
> involved. Otherwise the timing should be fully specified and no values
> from the bootloader should be retained.
> 
> >   * The address decoding windows should *not* be setup by this driver,
> >     but rather be described in the device tree itself.
> 
> I'm going to suggest you send out a quick DT sample for what you are
> thinking, that might save lots of effort?
> 

I've just sent a v2 for the Device Bus work, which takes care of all
your comments, except for the quick DT sample.
I hope it looks better now!

I'm not sure how close we are to an agreed mbus DTS binding, but I hope
the Device Bus can still get merged as it is, so we can have NOR support
as early as possible. Since the proposed DTS is really minimal, I expect
it to be innocuous.

If at all possible, could you take a look at it and tell me what do you think?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com