| Message ID | CA+bK7J6rXtF54Tp1+mkDbv8Hok88MVZeC+mLvjjGjzZ4KtTHEw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird <tbird20d@gmail.com> wrote: > On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >> Sorry, I can't take this without a DT ack. > > Hmmm. > > The policy seems to be: > "For driver (not subsystem) bindings: If you are comfortable with the > binding, and it hasn't received an Acked-by from the devicetree > maintainers after a few weeks, go ahead and take it." > > The syscon property is only relative to the qcom hwspinlock driver, > (unless I'm missing something) and both Qualcomm and Sony devs are > OK with it. So while an ACK from the DT side would be nice, I don't > think it's required. This is exactly the type of delay that is really > holding up a lot of out-of-tree code. Sorry, I do prefer to make sure Mark is OK with this devicetree patch, especially since it wasn't clear whether Mark is entirely comfortable with it in his last response. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote: > On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird <tbird20d@gmail.com> wrote: >> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >>> Sorry, I can't take this without a DT ack. >> >> Hmmm. >> >> The policy seems to be: >> "For driver (not subsystem) bindings: If you are comfortable with the >> binding, and it hasn't received an Acked-by from the devicetree >> maintainers after a few weeks, go ahead and take it." >> >> The syscon property is only relative to the qcom hwspinlock driver, >> (unless I'm missing something) and both Qualcomm and Sony devs are >> OK with it. So while an ACK from the DT side would be nice, I don't >> think it's required. This is exactly the type of delay that is really >> holding up a lot of out-of-tree code. > > Sorry, I do prefer to make sure Mark is OK with this devicetree patch, > especially since it wasn't clear whether Mark is entirely comfortable > with it in his last response. Just to be clear - do you personally have any objections to the patch? Are we now stuck in limbo until such time as the device tree maintainers get around to us? I'm worried about this status because my understanding is that the DT maintainers are hugely backlogged and let a lot of stuff drop on the floor. In particular, see slide 21 of the following presentation: http://www.elinux.org/images/0/0a/The_Device_Tree_as_a_Stable_ABI-_A_Fairy_Tale%3F.pdf That graph shows that the DT maintainers are falling way behind in their reviews and ACKs. The policy of not waiting for an ACK from device tree maintainers was specifically created to help the situation we are now in, and yet you seem to be unwilling to follow it. This is extremely frustrating. One idea we discussed at a recent meeting on mainlining was to submit SoC-blocking items to drivers/staging. Then, stuff is at least in the tree and can be tested by others pending some approval. Do you have any opinion on that? Is there any way to move ahead? Or are we doomed to just sit around and wait indefinitely? For the record, after what amount of time without a DT ACK would you consider accepting this (if ever)? Another idea I'm considering is to write our own hwspinlock layer and become the maintainer of that, so we're not blocked by you. At this point, the value of using your hwspinlock framework is vastly outweighed by the negative effect is has on our mainlining effort. Regards, -- Tim Bird Senior Software Engineer, Sony Mobile Architecture Group Chair, CE Workgroup, Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird <tbird20d@gmail.com> wrote: > On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird <tbird20d@gmail.com> wrote: >>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >>>> Sorry, I can't take this without a DT ack. >>> >>> Hmmm. >>> >>> The policy seems to be: >>> "For driver (not subsystem) bindings: If you are comfortable with the >>> binding, and it hasn't received an Acked-by from the devicetree >>> maintainers after a few weeks, go ahead and take it." >>> >>> The syscon property is only relative to the qcom hwspinlock driver, >>> (unless I'm missing something) and both Qualcomm and Sony devs are >>> OK with it. So while an ACK from the DT side would be nice, I don't >>> think it's required. This is exactly the type of delay that is really >>> holding up a lot of out-of-tree code. >> >> Sorry, I do prefer to make sure Mark is OK with this devicetree patch, >> especially since it wasn't clear whether Mark is entirely comfortable >> with it in his last response. > > Just to be clear - do you personally have any objections to the patch? No, but this patch is for a folder I don't maintain so I prefer someone who does to take a look. Mark did take a look, and said he's confused by this patch (see this thread). Do you want me to ignore him and just send it to Linus anyway? -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 6, 2015 at 9:31 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote: > On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird <tbird20d@gmail.com> wrote: >> On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >>> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird <tbird20d@gmail.com> wrote: >>>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >>>>> Sorry, I can't take this without a DT ack. >>>> >>>> Hmmm. >>>> >>>> The policy seems to be: >>>> "For driver (not subsystem) bindings: If you are comfortable with the >>>> binding, and it hasn't received an Acked-by from the devicetree >>>> maintainers after a few weeks, go ahead and take it." >>>> >>>> The syscon property is only relative to the qcom hwspinlock driver, >>>> (unless I'm missing something) and both Qualcomm and Sony devs are >>>> OK with it. So while an ACK from the DT side would be nice, I don't >>>> think it's required. This is exactly the type of delay that is really >>>> holding up a lot of out-of-tree code. >>> >>> Sorry, I do prefer to make sure Mark is OK with this devicetree patch, >>> especially since it wasn't clear whether Mark is entirely comfortable >>> with it in his last response. >> >> Just to be clear - do you personally have any objections to the patch? > > No, but this patch is for a folder I don't maintain so I prefer > someone who does to take a look. > > Mark did take a look, and said he's confused by this patch (see this thread). > > Do you want me to ignore him and just send it to Linus anyway? Ohad, Tim, For this patch to be useful to us we also need Suman's DT patch, so we should try to get them both in asap. Based on the long discussion we had on one of the previous iterations of Suman's DT binding, with the DT maintainers I believe that it would be fine to move along and sent Suman's patches to Linus - without an explicit Ack from the DT guys (or did I just miss one?). Regarding this patch I agree with Ohad that it would be good if we verify that Mark's question is answered before moving on. So I will reach out to him to see if he has any remaining concerns. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 6, 2015 at 7:48 PM, Bjorn Andersson <bjorn@kryo.se> wrote: > Based on the long discussion we had on one of the previous iterations > of Suman's DT binding, with the DT maintainers I believe that it would > be fine to move along and sent Suman's patches to Linus - without an > explicit Ack from the DT guys (or did I just miss one?). Thanks Bjorn. Mark, are you OK with the latest iteration from Suman? it would be nice to get your +1 just to make sure we don't merge stuff you're uncomfortable with. Thanks! Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: > Mark, are you OK with the latest iteration from Suman? it would be > nice to get your +1 just to make sure we don't merge stuff you're > uncomfortable with. Quick update: As Tim pointed out, we can move forward with the driver binding patch according to the process described under II.2 of [1]. Both Bjorn and myself would still prefer to make sure Mark is satisfied with the response Bjorn sent to Mark's question, but we understand if Mark is swamped and we eventually would proceed according to the DT's submitting-patches guidance below. Tim, thanks for pointing that out as I wasn't aware of this. What we probably do need a DT ack on is the hwspinlock subsystem binding submitted by Suman, again according to the process described under II.2 of [1]: "Subsystem bindings (anything affecting more than a single device): then getting a devicetree maintainer to review it is required". Mark and Rob: thanks so much for all your help so far as you have substantially helped shaping the hwspinlock binding. Please let us know if you are satisfied with Suman's latest iteration, still prefer to take another look at it, or are too swamped. If the latter, then maybe we can ask Kumar to take a look, as this seems to be blocking Qualcomm's upstream roadmap. Thanks, Ohad. [1] Documentation/devicetree/bindings/submitting-patches.txt -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 13, 2015 at 5:23 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote: > On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote: >> Mark, are you OK with the latest iteration from Suman? it would be >> nice to get your +1 just to make sure we don't merge stuff you're >> uncomfortable with. > > Quick update: > > As Tim pointed out, we can move forward with the driver binding patch > according to the process described under II.2 of [1]. Both Bjorn and > myself would still prefer to make sure Mark is satisfied with the > response Bjorn sent to Mark's question, but we understand if Mark is > swamped and we eventually would proceed according to the DT's > submitting-patches guidance below. Tim, thanks for pointing that out > as I wasn't aware of this. > > What we probably do need a DT ack on is the hwspinlock subsystem > binding submitted by Suman, again according to the process described > under II.2 of [1]: "Subsystem bindings (anything affecting more than a > single device): then getting a devicetree maintainer to review it is > required". Right, you can't really merge this driver binding until the binding is done and acked. Your binding would be referring to a binding doc that doesn't exist in the tree if you merge this. > Mark and Rob: thanks so much for all your help so far as you have > substantially helped shaping the hwspinlock binding. Please let us > know if you are satisfied with Suman's latest iteration, still prefer > to take another look at it, or are too swamped. If the latter, then > maybe we can ask Kumar to take a look, as this seems to be blocking > Qualcomm's upstream roadmap. While I think the binding looks fine, I'm not going to go around Mark either. He's invested the most thought in this (of DT maintainers) and should be the one to ack it. The part I'm not clear what the purpose of "pool-hwlock" was. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> The part I'm not clear what the purpose of "pool-hwlock" was.
One use-case was a set of hwlocks having no fixed purpose, and being
available for dynamic allocation between the OS and other entities (e.g.
some RTOS on another core).
The set of locks forming a reusable pool, and any information associated
with them (e.g. the logical IDs used by the other entity) are a property
of that interface rather than the hwlock provider.
So you'd describe those pools of locks in some interface-specific
manner, consuming hwlocks from a set of hwlock providers.
Hopefully that doesn't maek things less clear...
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt new file mode 100644 index 0000000..28ade7d --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt @@ -0,0 +1,39 @@ +Qualcomm Hardware Mutex Block: + +The hardware block provides mutexes utilized between different processors on +the SoC as part of the communication protocol used by these processors. + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,sfpb-mutex", + "qcom,tcsr-mutex" + +- syscon: + Usage: required + Value type: <prop-encoded-array> + Definition: one cell containing: + syscon phandle + offset of the hwmutex block within the syscon + stride of the hwmutex registers + +- #hwlock-cells: + Usage: required + Value type: <u32> + Definition: must be 1, the specified cell represent the lock id + (hwlock standard property, see hwlock.txt) + +Example: + + tcsr: syscon@1a400000 { + compatible = "qcom,tcsr-msm8974", "syscon"; + reg = <0xfd484000 0x2000>; + }; + + hwlock@fd484000 { + compatible = "qcom,tcsr-mutex"; + syscon = <&tcsr 0 0x80>; + + #hwlock-cells = <1>; + };