On 02/12/2024 05:00, Mukesh Kumar Savaliya wrote: > Hi Krzysztof, > > On 11/29/2024 8:44 PM, Krzysztof Kozlowski wrote: >> On 29/11/2024 15:43, Mukesh Kumar Savaliya wrote: >>> Adds qcom,shared-se flag usage. Use this flag when I2C serial controller >>> needs to be shared in multiprocessor system(APPS,Modem,ADSP) environment. >>> >>> SE(Serial Engine HW controller acting as protocol master controller) is an >>> I2C controller. Basically a programmable SERDES(serializer/deserializer) >>> coupled with data DMA entity, capable in handling a bus protocol, and data >>> moves to/from system memory. >>> >>> Two clients from different processors can share an I2C controller for same >>> slave device OR their owned slave devices. Assume I2C Slave EEPROM device >>> connected with I2C controller. Each client from ADSP SS and APPS Linux SS >>> can perform i2c transactions. >>> >>> Transfer gets serialized by Lock TRE + DMA xfer + Unlock TRE at HW level. >>> >>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@xxxxxxxxxxx> >>> --- >>> .../devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml >>> index 9f66a3bb1f80..88682a333399 100644 >>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml >>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml >>> @@ -60,6 +60,14 @@ properties: >>> power-domains: >>> maxItems: 1 >>> >>> + qcom,shared-se: >>> + description: True if I2C controller is shared between two or more system processors. >>> + SE(Serial Engine HW controller working as protocol master controller) is an >>> + I2C controller. Basically, a programmable SERDES(serializer/deserializer) >>> + coupled with data DMA entity, capable in handling a bus protocol, and data >>> + moves to/from system memory. >> I replied why I NAK it. You did not really address my concerns, but >> replied with some generic statement. After that generic statement you >> gave me exactly 0 seconds to react and you sent v5. >> > Sorry for 0 seconds, i thought of addressing comment and uploading it > new patch as i wanted to explain SE. whatever i have added for SE > explanation is in qualcomm hardware programming guide document. >> Really 0 seconds to respond to your comment, while you give yourself >> days to respond to my comments. >> >> This is not how it works. >> > Sure, let me first conclude here what exactly should be done. >> NAK >> >> Implement previous feedback. Don't send any new versions before you >> understand what you have to do and get some agreement with reviewers. >> > Sure, this is definitely a good way. what did i do for previous comment ? > I have opened SE and expanded, explained. > > which statement or explanation should i rephrase ? Is it description > statement from this yaml file ? Could you please suggested better word > instead of shared-se if this flag name is not suitable ? > > I could not get this ask - > "There are few of such flags already and there are some patches adding > it in different flavors." Come with one flag or enum, if needed, covering all your cases like this. Best regards, Krzysztof
