On 09/29/14 22:02, Bjorn Andersson wrote:

On Mon 29 Sep 15:17 PDT 2014, Stephen Boyd wrote:

quoted

On 09/29/14 02:14, Srinivas Kandagatla wrote:

quoted

@@ -246,6 +247,24 @@
 			#reset-cells = <1>;
 		};
 
+		apcs: syscon at 2011000 {
+			compatible = "syscon";
+			reg = <0x2011000 0x1000>;
+		};

This is actually a clock controller block that hw designers decided was
good place to shove the ipc bits (because there's room!). Can we call it

                l2cc: clock-controller at 2011000 {
                        compatible = "syscon";
                        reg = <0x2011000 0x1000>;
                };

Eventually I'll add the specific krait compatible when we merge krait
clock support:

                l2cc: clock-controller at 2011000 {
                        compatible = "qcom,kpss-gcc", "syscon";
                        reg = <0x2011000 0x1000>;
                        clock-output-names = "acpu_l2_aux";
                };

As long as we can get hold of the regmap that would be fine. I pressume the
idea is to have the kpss-gcc using syscon, just like the rpm. But hopefully the
syscon patches that are floating around (merged?) will allow any driver to
expose a "syscon regmap".

Agreed. I'm not sure if kpss-gcc will use syscon. With the floating
patches I don't see a reason why we need to use it.

quoted

quoted

+
+		rpm at 108000 {
+			compatible	= "qcom,rpm-apq8064";
+			reg		= <0x108000 0x1000>;
+			qcom,ipc = <&apcs 0x8 2>;

There are actually 3 ipc bits. I guess if we ever have to use the other
two we'll extend this binding to have the other bits specified some
other way?

I haven't seen any indications of us using more than this bit. If we want to do
that, we could simply make it <&apcs 8 2 &apcs 8 3 &apcs 8 4> (or whatever
those indices are). That way this should be easy it keep compatible.

Good to hear we're not forced to use a new property. The indices have
always been 2, 1, and 0 as far as I know.

We use bit 1 to ack the RPM if it ever crashes. We know that it crashes
because we receive the error interrupt. Instead of calling panic like we
do downstream we can gracefully fail any new rpm requests. There really
isn't any way to recover from this scenario though besides rebooting.
Looking at the code I see this is all wrong and we use bit 2 to ack the
error.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation