On Wednesday 21 March 2012, Viresh Kumar wrote:
quoted
What's wrong with one vic_dt_init_irq() function and an array with two entries?
Hey Arnd,
Actually i was doing 3xx DT porting and again came to this thing. I believe what
you suggested should be fine too as the actual vic model/name is going to be
passed from .dts file.
If this is acceptable to you, i will add patch for both vic & gic in my
patchset.
Ok, sounds good.
Let's make sure we're on the same page with the process though. I hope
you're aware that I took Stefan's spear6xx v5 patch. I just now saw that
you were not on Cc on the submission of the patch nor on my reply, but you
had given your Ack on the patch. Just let me know how you want to handle
these things in the future -- the normal way would be to always let you
forward the patches to me, rather than having them applied to arm-soc
directly.
Regarding the spear3xx patches, I'm looking forward to your patches.
I think spear is simple and clean enough that it can serve as an example
for others doing DT conversion. Do you also plan to unify 3xx and 6xx?
I think there is hardly anything left in mach-spear6xx that justifies
having a separate platform, especially since with the DT conversion done,
we can actually remove most of the header file contents as well.
Arnd
On Wed, Mar 21, 2012 at 6:06 PM, Arnd Bergmann [off-list ref] wrote:
Let's make sure we're on the same page with the process though. I hope
you're aware that I took Stefan's spear6xx v5 patch.
Ya. I already know that. :)
Just let me know how you want to handle
these things in the future -- the normal way would be to always let you
forward the patches to me, rather than having them applied to arm-soc
directly.
Hmmm. I don't know how exactly it works, but maybe you can add me as
an custodian for SPEAr, with a git repo somewhere in kernel.org (?).
So that i can apply patches directly to my branch, you pull it.
What do you say?
I think spear is simple and clean enough that it can serve as an example
for others doing DT conversion. Do you also plan to unify 3xx and 6xx?
I think there is hardly anything left in mach-spear6xx that justifies
having a separate platform, especially since with the DT conversion done,
we can actually remove most of the header file contents as well.
I issue with us was that we were not able to push stuff mainline in time and
were too busy supporting customers.
We have lot of patches locally, that we would like to upstream. But it
can't happen
without updating it with new expectations of list. I actually wanted
to ask you few
things:
- DT: Obviously we would have this in our patches
- Pinmux: I would remove our padmux and use pinmux, but what about its
DT support.
I know stephen had few patches for it, but don't know there
progress. I don't want to
do stuff twice. First add support for it in board and the *.dts files.
- Clock Framework: Is common clock framework ready for use or can we update our
local clock framework?
I will see if merging 3xx & 6xx is feasible. If yes, then i will
surely move in that direction.
I always like cleaning stuff. :)
I would be adding 13xx (cortex-A9) patches again later, once done with 3xx.
--
viresh
On Wednesday 21 March 2012, viresh kumar wrote:
On Wed, Mar 21, 2012 at 6:06 PM, Arnd Bergmann [off-list ref] wrote:
quoted
Just let me know how you want to handle
these things in the future -- the normal way would be to always let you
forward the patches to me, rather than having them applied to arm-soc
directly.
Hmmm. I don't know how exactly it works, but maybe you can add me as
an custodian for SPEAr, with a git repo somewhere in kernel.org (?).
So that i can apply patches directly to my branch, you pull it.
What do you say?
Yes, that would be the ideal way. You are already listed in the MAINTAINERS
file, so nothing would change in theory. If you don't have an account on
kernel.org yet, see http://www.kernel.org/faq/#account for how to get
one. This will require that you have your gpg keys signed by at least
one person in the kernel web of trust, so you may have to find people
locally who can sign yours and are already signed.
quoted
I think spear is simple and clean enough that it can serve as an example
for others doing DT conversion. Do you also plan to unify 3xx and 6xx?
I think there is hardly anything left in mach-spear6xx that justifies
having a separate platform, especially since with the DT conversion done,
we can actually remove most of the header file contents as well.
I issue with us was that we were not able to push stuff mainline in time and
were too busy supporting customers.
We have lot of patches locally, that we would like to upstream. But it
can't happen
without updating it with new expectations of list. I actually wanted
to ask you few
things:
- DT: Obviously we would have this in our patches
- Pinmux: I would remove our padmux and use pinmux, but what about its
DT support.
I know stephen had few patches for it, but don't know there
progress. I don't want to
do stuff twice. First add support for it in board and the *.dts files.
AFAICT, the pinmux DT binding should be ready for v3.5, I don't think it
made it into v3.4.
- Clock Framework: Is common clock framework ready for use or can we update our
local clock framework?
I'm sending it to Linus now and you can start using it, but it may still
change in a number of ways based on the requirements of new platforms that
start migrate to it.
I will see if merging 3xx & 6xx is feasible. If yes, then i will
surely move in that direction.
I always like cleaning stuff. :)
I've looked at this earlier today out of curiosity and found:
debug_macro.h, gpio.h, hardware.h, timex.h, uncompress.h:
identical already
clock.c: almost identical, can be easily merged, or both copies
kept around during transition.
misc_regs.h: can be merged into clock.c
spear.h: can merged into spear6xx.c but mostly go away
generic.h, irqs.h: not needed any more for spear6xx
Once you have taken care of these, files, you can enable building 3xx
and 6xx together, and move the contents of mach-spear3xx, mach-spear6xx
and plat-spear into one directory.
I would be adding 13xx (cortex-A9) patches again later, once done with 3xx.
Ok, excellent. Note that there is no requirement to do it all in the order
you line out above. You can always get support for new stuff into the
existing platform without cleaning up all of it right away, as long as you
have a good balance between cleanups and new functionality.
In particular, you don't have to start using pinctrl and the common clk
immediately for spear3xx, although you might find that it helps you.
For spear13xx, the platform being completely new, I would however ask
you to use those from the start.
Arnd
On Wed, Mar 21, 2012 at 7:34 PM, Arnd Bergmann [off-list ref] wrote:
On Wednesday 21 March 2012, viresh kumar wrote:
quoted
- Pinmux: I would remove our padmux and use pinmux, but what about its
DT support.
? I know stephen had few patches for it, but don't know there
progress. I don't want to
? do stuff twice. First add support for it in board and the *.dts files.
AFAICT, the pinmux DT binding should be ready for v3.5, I don't think it
made it into v3.4.
So, i can add stuff in board file for pinmux for now?
I've looked at this earlier today out of curiosity and found:
clock.c: almost identical, can be easily merged, or both copies
? ? ? ? kept around during transition.
Would make it very confusing if we merge these two. Some clock
structures are same, but others are not. Mostly differences are in the
macros (or bit positions in registers), rather than hierarchy. So, i would
like to keep them separate. But still have a look again to see if they can
really be merged.
misc_regs.h: can be merged into clock.c
it has more than clock stuff. it is used in pinmux and some other places too,
that may not be in mainline for now.
Once you have taken care of these, files, you can enable building 3xx
and 6xx together, and move the contents of mach-spear3xx, mach-spear6xx
and plat-spear into one directory.
plat-spear would be required for 13xx too. So, merging 3xx and 6xx only would
be possible.
Ok, excellent. Note that there is no requirement to do it all in the order
you line out above. You can always get support for new stuff into the
existing platform without cleaning up all of it right away, as long as you
have a good balance between cleanups and new functionality.
Ya. I just wanted to get some hands on experience with this new stuff, before
touching 13xx.
In particular, you don't have to start using pinctrl and the common clk
immediately for spear3xx, although you might find that it helps you.
But, can i update padmux and clock framework of SPEAr platform? Because
without the latest code for both padmux and clock, other code for SPEAr
might not be that effective or usable.
For spear13xx, the platform being completely new, I would however ask
you to use those from the start.
Sure.
--
viresh