mvebu: Device bus driver resurrection
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?
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
Hello,
Quoted 18 lines · Ezequiel Garcia
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.
Quoted 8 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 9 lines · 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.
Yes, and I saw Rob Herring note that the DT parameters in cases like that should end in -ps
Quoted 2 lines
* 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.
Quoted 2 lines
* 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
Dear Jason Gunthorpe,
Quoted 5 lines · Jason Gunthorpe
Quoted 2 lines
* 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Hi Jason,
Quoted 22 lines · Jason Gunthorpe
Quoted 9 lines · 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.
Yes, and I saw Rob Herring note that the DT parameters in cases like that should end in -ps
Quoted 2 lines
* 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.
Quoted 6 lines
Quoted 2 lines
* 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?
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com