RFD: OMAP PRCM register access holding up PM branch submissions

RFD: OMAP PRCM register access holding up PM branch submissions

[Kevin Hilman]

Russell, Paul,

As we discussed a bit in the OMAP clocks thread, there is not yet a
decision on the best way to access the PRCM registers.  I'd like to
get some discussion going so I can begin submissions of the rest of
the OMAP PM core code.

We currently have two methods for PRCM register access

1) direct access using __raw_[read|write] and OMAP_PRM_REGADDR() #defines

2) "MOD + offset" access using prm_[read|write|rmw]_*

The current code (in Russell's omap-clks3) branch is kind of a hybrid
with lots of usages of both methods, and Paul's patch (A 09) which
converted everything to (2) has been rejected.  However, I'm still not
entirely clear whether the objection was because you're opposed to the
'MOD + offset' approach in general, or just the way it was done in
this patch.

So, what is the path forward?  If you are not opposed to moving to the
'MOD + offset' approach in principle, I propose we just make a new
attempt at converting to it.  If you're opposed to it all together, we
need to start some discussion.  Russell, you seem to have suggested
you had some ideas[1].  Would you mind posting your ideas for
discussion, not necessarily patches, but just rough ideas to start
discussions.

Until we get some decision on this, it is impossible to move forward
with submissions of the rest of the OMAP PM code.

Thanks,

Kevin

[1] http://marc.info/?l=linux-omap&m=123609877205834&w=2

Re: RFD: OMAP PRCM register access holding up PM branch submissions

[Russell King - ARM Linux]

On Thu, Mar 12, 2009 at 08:25:55AM -0700, Kevin Hilman wrote:
> So, what is the path forward?  If you are not opposed to moving to the
> 'MOD + offset' approach in principle, I propose we just make a new
> attempt at converting to it.

The path forward is that I'm not going to do anything further on this
until after the next merge window[*].  I only officially spend one day
a week on TI stuff, and I've spent rather more than that over the course
of the last cycle at the expense of other work.

So it's now time that these other people who had been squeezed out get
my attention up until the next merge window.  I'm thinking of things
like highmem, MXC, and so forth.


* - I was hoping to get the entire queued contents of my omap-clks3
branch out on to linux-omap, but having encountered problems with the
shere amount of email causing the load to sky rocket resulting in the
OOM killer going crazy on my firewall, I'm not going to be able to do
that.  So, the omap-clks3 branch is currently in limbo and as such might
*not* get merged during the next window.

Re: RFD: OMAP PRCM register access holding up PM branch submissions

[Kevin Hilman]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Thu, Mar 12, 2009 at 08:25:55AM -0700, Kevin Hilman wrote:
>> So, what is the path forward?  If you are not opposed to moving to the
>> 'MOD + offset' approach in principle, I propose we just make a new
>> attempt at converting to it.
>
> The path forward is that I'm not going to do anything further on this
> until after the next merge window[*].  I only officially spend one day
> a week on TI stuff, and I've spent rather more than that over the course
> of the last cycle at the expense of other work.
>

Russell,

Nobody expects you to be doing all the work yourself, I would just
like to hear your opinions on the direction.  Even working full-time,
there is way too much OMAP clock and PM code in progress for any one
person to work on alone.  Between Paul, myself and others in the
linux-omap community, we are happy to work on evolving this code in
the right direction.

If you can share your opinions on the two register access approaches I
described, I will work on coordinating development in that direction.

Until then, any efforts to get OMAP PM code into shape for upstream
submission are completely stalled since it is still unclear what your
opinions are on the PRCM access methods going forward.

Kevin

Re: RFD: OMAP PRCM register access holding up PM branch submissions

[Russell King - ARM Linux]

On Thu, Mar 12, 2009 at 09:54:41AM -0700, Kevin Hilman wrote:
> If you can share your opinions on the two register access approaches I
> described, I will work on coordinating development in that direction.

If I had a path forwards, then I would say so.  At the moment, I have
a vague idea about what I'd like to see, but it isn't in a workable
state at the present time.

I need to put further thought and time into coming up with a solution.
For the time being, I am not going to apply the outstanding patches to
put in place a solution which is totally confused about iomem and u32
types with lots of casts to make it work.  Even one which passes u32
types to the IO accessors (which don't produce a warning but shouldn't
be allowed in any case.)

I'm sorry, but I have no further time that I can spend on this, not even
proposing solutions, not even commenting back on the patches.  That's
the way it is.  I'm _WAY_ over time on OMAP stuff this cycle and that's
just going to have to be accepted by the community.

Sorry.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: RFD: OMAP PRCM register access holding up PM branch submissions

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090312 10:03]:
> On Thu, Mar 12, 2009 at 09:54:41AM -0700, Kevin Hilman wrote:
> > If you can share your opinions on the two register access approaches I
> > described, I will work on coordinating development in that direction.
> 
> If I had a path forwards, then I would say so.  At the moment, I have
> a vague idea about what I'd like to see, but it isn't in a workable
> state at the present time.
> 
> I need to put further thought and time into coming up with a solution.
> For the time being, I am not going to apply the outstanding patches to
> put in place a solution which is totally confused about iomem and u32
> types with lots of casts to make it work.  Even one which passes u32
> types to the IO accessors (which don't produce a warning but shouldn't
> be allowed in any case.)

Well let's get the current omap clock patches in omap-clks3 merged.
It is already way closer to what we need than the current mainline code.

Paul, maybe you can post that series to linux-omap for final review
and testing because of the mail/OOM issues Russell is having?

Then we'll come up with a proper solution for the remaining patches
after this merge window.
 
> I'm sorry, but I have no further time that I can spend on this, not even
> proposing solutions, not even commenting back on the patches.  That's
> the way it is.  I'm _WAY_ over time on OMAP stuff this cycle and that's
> just going to have to be accepted by the community.
> 
> Sorry.

Sure you have tons of other things to take care of, and the remaining
omap clock patches can be sorted out over time.

Regards,

Tony

Re: RFD: OMAP PRCM register access holding up PM branch submissions

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090312 10:03]:
>> On Thu, Mar 12, 2009 at 09:54:41AM -0700, Kevin Hilman wrote:
>> > If you can share your opinions on the two register access approaches I
>> > described, I will work on coordinating development in that direction.
>> 
>> If I had a path forwards, then I would say so.  At the moment, I have
>> a vague idea about what I'd like to see, but it isn't in a workable
>> state at the present time.
>> 
>> I need to put further thought and time into coming up with a solution.
>> For the time being, I am not going to apply the outstanding patches to
>> put in place a solution which is totally confused about iomem and u32
>> types with lots of casts to make it work.  Even one which passes u32
>> types to the IO accessors (which don't produce a warning but shouldn't
>> be allowed in any case.)
>
> Well let's get the current omap clock patches in omap-clks3 merged.
> It is already way closer to what we need than the current mainline code.
>
> Paul, maybe you can post that series to linux-omap for final review
> and testing because of the mail/OOM issues Russell is having?

I will post this series to linux-omap for final review.

I don't think there are any major objections that should prevent this
from going into this merge window.  

> Then we'll come up with a proper solution for the remaining patches
> after this merge window.

Agreed, this PRCM issue does not need to be resolved for this merge window.

Kevin