[PATCH] bus: mhi: host: Change the trace string for the userspace tools mapping

2024-02-18 Thread Krishna chaitanya chundru
User space tools can't map strings if we use directly, as the string
address is internal to kernel.

So add trace point strings for the user space tools to map strings
properly.

Signed-off-by: Krishna chaitanya chundru 
---
 drivers/bus/mhi/host/main.c  | 4 ++--
 drivers/bus/mhi/host/trace.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index 2d38f6005da6..15d657af9b5b 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -1340,7 +1340,7 @@ static int mhi_update_channel_state(struct mhi_controller 
*mhi_cntrl,
enum mhi_cmd_type cmd = MHI_CMD_NOP;
int ret;
 
-   trace_mhi_channel_command_start(mhi_cntrl, mhi_chan, to_state, 
"Updating");
+   trace_mhi_channel_command_start(mhi_cntrl, mhi_chan, to_state, 
TPS("Updating"));
switch (to_state) {
case MHI_CH_STATE_TYPE_RESET:
write_lock_irq(_chan->lock);
@@ -1407,7 +1407,7 @@ static int mhi_update_channel_state(struct mhi_controller 
*mhi_cntrl,
write_unlock_irq(_chan->lock);
}
 
-   trace_mhi_channel_command_end(mhi_cntrl, mhi_chan, to_state, "Updated");
+   trace_mhi_channel_command_end(mhi_cntrl, mhi_chan, to_state, 
TPS("Updated"));
 exit_channel_update:
mhi_cntrl->runtime_put(mhi_cntrl);
mhi_device_put(mhi_cntrl->mhi_dev);
diff --git a/drivers/bus/mhi/host/trace.h b/drivers/bus/mhi/host/trace.h
index d12a98d44272..368515dcb22d 100644
--- a/drivers/bus/mhi/host/trace.h
+++ b/drivers/bus/mhi/host/trace.h
@@ -84,6 +84,8 @@ DEV_ST_TRANSITION_LIST
 #define dev_st_trans(a, b) { DEV_ST_TRANSITION_##a, b },
 #define dev_st_trans_end(a, b) { DEV_ST_TRANSITION_##a, b }
 
+#define TPS(x) tracepoint_string(x)
+
 TRACE_EVENT(mhi_gen_tre,
 
TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,

---
base-commit: ceeb64f41fe6a1eb9fc56d583983a81f8f3dd058
change-id: 20240218-ftrace_string-7677762aa63c

Best regards,
-- 
Krishna chaitanya chundru 




Re: [PATCH v11] bus: mhi: host: Add tracing support

2024-02-05 Thread Krishna Chaitanya Chundru




On 2/6/2024 11:56 AM, Manivannan Sadhasivam wrote:

On Tue, Feb 06, 2024 at 10:02:05AM +0530, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 


There are a lot of checkpatch errors. Please fix them and resubmit.

- Mani


Hi Mani,

The errors which is pointing in the checkpatch are false positive, those
errors are being shown from v2 onwards and kernel test boot is also not
throwing any errors for it.

I checked with internal team they said these errors are false positive.

Thanks & Regards,
Krishna Chaitanya.


Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v11:
- Rebased with mhi next.
- Link to v10: 
https://lore.kernel.org/r/20240131-ftrace_support-v10-1-4349306b8...@quicinc.com

Changes in v10:
- Modified command_start and command_end traces to take string as input to 
mention correct
- string as suggested by mani
- As sugggested by mani modified the print format from lower format to upper 
case format.
- Link to v9: 
https://lore.kernel.org/r/20240105-ftrace_support-v9-1-a2dca64cc...@quicinc.com

Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
  drivers/bus/mhi/common.h|  38 +++---
  drivers/bus/mhi/host/init.c |  64 +
  drivers/bus/mhi/host/internal.h |  41 ++
  drivers/bus/mhi/host/main.c |  19 ++-
  drivers/bus/mhi/host/pm.c   |   7 +-
  drivers/bus/mhi/host/trace.h| 280 
  6 files changed, 384 insertions(+), 65 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
__le32 dword[2];
  };
  
+#define MHI_STATE_LIST\

+   mhi_state(RESET,"RESET")  \
+   mhi_state(READY,"READY")  \
+   mhi_state(M0,   "M0") \
+   mhi_state(M1,   "M1") \
+   mhi_state(M2,   "M2") \
+   mhi_state(M3,   "M3") \
+   mhi_state(M3_FAST,  "M3_FAST")\
+   mhi_state(BHI,  

[PATCH v11] bus: mhi: host: Add tracing support

2024-02-05 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v11:
- Rebased with mhi next.
- Link to v10: 
https://lore.kernel.org/r/20240131-ftrace_support-v10-1-4349306b8...@quicinc.com

Changes in v10:
- Modified command_start and command_end traces to take string as input to 
mention correct
- string as suggested by mani
- As sugggested by mani modified the print format from lower format to upper 
case format.
- Link to v9: 
https://lore.kernel.org/r/20240105-ftrace_support-v9-1-a2dca64cc...@quicinc.com

Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/common.h|  38 +++---
 drivers/bus/mhi/host/init.c |  64 +
 drivers/bus/mhi/host/internal.h |  41 ++
 drivers/bus/mhi/host/main.c |  19 ++-
 drivers/bus/mhi/host/pm.c   |   7 +-
 drivers/bus/mhi/host/trace.h| 280 
 6 files changed, 384 insertions(+), 65 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
__le32 dword[2];
 };
 
+#define MHI_STATE_LIST \
+   mhi_state(RESET,"RESET")\
+   mhi_state(READY,"READY")\
+   mhi_state(M0,   "M0")   \
+   mhi_state(M1,   "M1")   \
+   mhi_state(M2,   "M2")   \
+   mhi_state(M3,   "M3")   \
+   mhi_state(M3_FAST,  "M3_FAST")  \
+   mhi_state(BHI,  "BHI")  \
+   mhi_state_end(SYS_ERR,  "SYS ERROR")
+
+#undef mhi_state
+#undef mhi_state_end
+
+#define mhi_state(a, b)case MHI_STATE_##a: return b;
+#define mhi_state_end(a, b)case MHI_STATE_##a: return b;
+
 static inline const char *mhi_state_str(enum mhi_state state)
 {
switch (state) {
-   case MHI_STATE_RESET:
-   return "RESET";
-   case MHI_STATE_READY:
-   return &quo

[PATCH v10] bus: mhi: host: Add tracing support

2024-01-30 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v10:
- Modified command_start and command_end traces to take string as input to 
mention correct
- string as suggested by mani
- As sugggested by mani modified the print format from lower format to upper 
case format.
- Link to v9: 
https://lore.kernel.org/r/20240105-ftrace_support-v9-1-a2dca64cc...@quicinc.com

Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/common.h|  38 +++---
 drivers/bus/mhi/host/init.c |  63 +
 drivers/bus/mhi/host/internal.h |  40 ++
 drivers/bus/mhi/host/main.c |  19 ++-
 drivers/bus/mhi/host/pm.c   |   7 +-
 drivers/bus/mhi/host/trace.h| 280 
 6 files changed, 383 insertions(+), 64 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
__le32 dword[2];
 };
 
+#define MHI_STATE_LIST \
+   mhi_state(RESET,"RESET")\
+   mhi_state(READY,"READY")\
+   mhi_state(M0,   "M0")   \
+   mhi_state(M1,   "M1")   \
+   mhi_state(M2,   "M2")   \
+   mhi_state(M3,   "M3")   \
+   mhi_state(M3_FAST,  "M3_FAST")  \
+   mhi_state(BHI,  "BHI")  \
+   mhi_state_end(SYS_ERR,  "SYS ERROR")
+
+#undef mhi_state
+#undef mhi_state_end
+
+#define mhi_state(a, b)case MHI_STATE_##a: return b;
+#define mhi_state_end(a, b)case MHI_STATE_##a: return b;
+
 static inline const char *mhi_state_str(enum mhi_state state)
 {
switch (state) {
-   case MHI_STATE_RESET:
-   return "RESET";
-   case MHI_STATE_READY:
-   return "READY";
-   case MHI_STATE_M0:
-   return "M0";
-   case MHI_STATE_M1:
-   return "M1";
-   case MHI_STATE_M2:
-   

Re: [PATCH v9] bus: mhi: host: Add tracing support

2024-01-30 Thread Krishna Chaitanya Chundru




On 1/30/2024 11:56 PM, Manivannan Sadhasivam wrote:

On Tue, Jan 30, 2024 at 09:22:52AM -0500, Steven Rostedt wrote:

On Tue, 30 Jan 2024 13:41:52 +0530
Manivannan Sadhasivam  wrote:


So same trace will get printed for both mhi_channel_command_start() and
mhi_channel_command_end()?


The trace output will also include the tracepoint name. That is, it will
have the same content but will be preceded with:

   mhi_channel_command_start: ...
   mhi_channel_command_end: ...



Yes, but the message will be the same:

mhi_channel_command_start: chan%d: Updating state to:
mhi_channel_command_end: chan%d: Updating state to:

Either only one of the trace should be present or the second one should print,
"mhi_channel_command_end: chan%d: Updated state to:"

- Mani


I will try to pass a string to updated for mhi_channel_command_end &
updating for mhi_channel_command_start in my next patch.

- Krishna Chaitanya.




Re: [PATCH v9] bus: mhi: host: Add tracing support

2024-01-30 Thread Krishna Chaitanya Chundru




On 1/30/2024 1:41 PM, Manivannan Sadhasivam wrote:

On Fri, Jan 05, 2024 at 05:53:03PM +0530, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 


Few nitpicks below.


I will make suggested changes in next patch.

- Krishna Chaitanya.

Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
  drivers/bus/mhi/common.h|  38 +++---
  drivers/bus/mhi/host/init.c |  63 +
  drivers/bus/mhi/host/internal.h |  40 ++
  drivers/bus/mhi/host/main.c |  19 ++-
  drivers/bus/mhi/host/pm.c   |   7 +-
  drivers/bus/mhi/host/trace.h| 275 
  6 files changed, 378 insertions(+), 64 deletions(-)



[...]


+TRACE_EVENT(mhi_gen_tre,
+
+   TP_PROTO(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
+struct mhi_ring_element *mhi_tre),
+
+   TP_ARGS(mhi_cntrl, mhi_chan, mhi_tre),
+
+   TP_STRUCT__entry(
+   __string(name, mhi_cntrl->mhi_dev->name)
+   __field(int, ch_num)
+   __field(void *, wp)
+   __field(__le64, tre_ptr)
+   __field(__le32, dword0)
+   __field(__le32, dword1)
+   ),
+
+   TP_fast_assign(
+   __assign_str(name, mhi_cntrl->mhi_dev->name);
+   __entry->ch_num = mhi_chan->chan;
+   __entry->wp = mhi_tre;
+   __entry->tre_ptr = mhi_tre->ptr;
+   __entry->dword0 = mhi_tre->dword[0];
+   __entry->dword1 = mhi_tre->dword[1];
+   ),
+
+   TP_printk("%s: Chan: %d Tre: 0x%p Tre buf: 0x%llx dword0: 0x%08x dword1: 
0x%08x\n",


Use caps for printing the acronyms everywhere. Like TRE, DWORD etc...


+ __get_str(name), __entry->ch_num, __entry->wp, 
__entry->tre_ptr,
+ __entry->dword0, __entry->dword1)
+);
+
+TRACE_EVENT(mhi_intvec_states,
+
+   TP_PROTO(struct mhi_controller *mhi_cntrl, int dev_ee, int dev_state),
+
+   TP_ARGS(mhi_cntrl, dev_ee, dev_state),
+
+   TP_STRUCT__entry(
+   __string(name, mhi_cntrl->mhi_dev->name)
+   __field(in

Re: [PATCH v9] bus: mhi: host: Add tracing support

2024-01-24 Thread Krishna Chaitanya Chundru




On 1/8/2024 6:52 PM, Krishna Chaitanya Chundru wrote:

Hi Steven,

Even though I added your reviewed-by tag, I incorporated changes 
mentioned in the previous patch.


Can you please review it once.

Thanks & Regards,

Krishna Chaitanya.


Hi Steven,

Can you please review it once.

Thanks & Regards,
Krishna Chaitanya.


On 1/5/2024 5:53 PM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v9:
- Change the implementations of some array so that the strings to enum 
mapping

- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com 



Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com 



Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com 



Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com 



Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the 
address to avoid

- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com 



Changes in v4:
- Fix compilation issues in previous patch which happended due to 
rebasing.
- In the defconfig FTRACE config is not enabled due to that the 
compilation issue is not

- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com 



Changes in v3:
- move trace header file from include/trace/events to 
drivers/bus/mhi/host/ so that

- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid 
holes in the buffer.

- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver 
headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com 



Changes in v2:
- Passing the raw state into the trace event and using  
__print_symbolic() as suggested by bjorn.

- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com 


---
  drivers/bus/mhi/common.h    |  38 +++---
  drivers/bus/mhi/host/init.c |  63 +
  drivers/bus/mhi/host/internal.h |  40 ++
  drivers/bus/mhi/host/main.c |  19 ++-
  drivers/bus/mhi/host/pm.c   |   7 +-
  drivers/bus/mhi/host/trace.h    | 275 


  6 files changed, 378 insertions(+), 64 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
  __le32 dword[2];
  };
+#define MHI_STATE_LIST    \
+    mhi_state(RESET,    "RESET")    \
+    mhi_state(READY,    "READY")    \
+    mhi_state(M0,    "M0")    \
+    mhi_state(M1,    "M1")    \
+    mhi_state(M2,    "M2")    \
+    mhi_state(M3,    "M3")    \
+    mhi_state(M3_FAST,    "M3_FAST")    \
+    mhi_state(BHI,    "BHI")    \
+    mhi_state_end(SYS_ERR,    "SYS ERROR")
+
+#undef mhi_state
+#undef mhi_state_end
+
+#define mhi_state(a, b)    case MHI_STATE_##a: return b;
+#define mhi_state_end(a, b)    case MHI_STATE_##a: return b;
+
  static inline const char *mhi_state_str(enum mhi_state state)
  {
  switch (state) {
-    case MHI_STATE_RESET:
-    return "RESET";
-    case MHI_STATE_READY:
-    return "READY";
-    case MHI_STATE_M0:
-    return "M0";
-    case MHI_STATE_M1:
-    return "M1";
-    case MHI_STATE_M2:
-    return "M2"

Re: [PATCH v9] bus: mhi: host: Add tracing support

2024-01-08 Thread Krishna Chaitanya Chundru

Hi Steven,

Even though I added your reviewed-by tag, I incorporated changes 
mentioned in the previous patch.


Can you please review it once.

Thanks & Regards,

Krishna Chaitanya.

On 1/5/2024 5:53 PM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
  drivers/bus/mhi/common.h|  38 +++---
  drivers/bus/mhi/host/init.c |  63 +
  drivers/bus/mhi/host/internal.h |  40 ++
  drivers/bus/mhi/host/main.c |  19 ++-
  drivers/bus/mhi/host/pm.c   |   7 +-
  drivers/bus/mhi/host/trace.h| 275 
  6 files changed, 378 insertions(+), 64 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
__le32 dword[2];
  };
  
+#define MHI_STATE_LIST\

+   mhi_state(RESET,"RESET")  \
+   mhi_state(READY,"READY")  \
+   mhi_state(M0,   "M0") \
+   mhi_state(M1,   "M1") \
+   mhi_state(M2,   "M2") \
+   mhi_state(M3,   "M3") \
+   mhi_state(M3_FAST,  "M3_FAST")\
+   mhi_state(BHI,  "BHI")\
+   mhi_state_end(SYS_ERR,  "SYS ERROR")
+
+#undef mhi_state
+#undef mhi_state_end
+
+#define mhi_state(a, b)case MHI_STATE_##a: return b;
+#define mhi_state_end(a, b)case MHI_STATE_##a: return b;
+
  static inline const char *mhi_state_str(enum mhi_state state)
  {
switch (state) {
-   case MHI_STATE_RESET:
-   return "RESET";
-   case MHI_STATE_READY:
-   return "READY";
-   case MHI_STATE_M0:
-   return "M0";
-   case MHI_STATE_M1:
-   return "M1";
-   case MHI_STATE_M2:
-   return "M2";
-   case MHI_STATE_M3:
-   return &q

[PATCH v9] bus: mhi: host: Add tracing support

2024-01-05 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Change the implementation of the arrays which has enum to strings mapping
to make it consistent in both trace header file and other files.

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
Reviewed-by: "Steven Rostedt (Google)" 
---
Changes in v9:
- Change the implementations of some array so that the strings to enum mapping
- is same in both trace header and other files as suggested by steve.
- Link to v8: 
https://lore.kernel.org/r/20231207-ftrace_support-v8-1-7f62d4558...@quicinc.com

Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/common.h|  38 +++---
 drivers/bus/mhi/host/init.c |  63 +
 drivers/bus/mhi/host/internal.h |  40 ++
 drivers/bus/mhi/host/main.c |  19 ++-
 drivers/bus/mhi/host/pm.c   |   7 +-
 drivers/bus/mhi/host/trace.h| 275 
 6 files changed, 378 insertions(+), 64 deletions(-)

diff --git a/drivers/bus/mhi/common.h b/drivers/bus/mhi/common.h
index f794b9c8049e..dda340aaed95 100644
--- a/drivers/bus/mhi/common.h
+++ b/drivers/bus/mhi/common.h
@@ -297,30 +297,30 @@ struct mhi_ring_element {
__le32 dword[2];
 };
 
+#define MHI_STATE_LIST \
+   mhi_state(RESET,"RESET")\
+   mhi_state(READY,"READY")\
+   mhi_state(M0,   "M0")   \
+   mhi_state(M1,   "M1")   \
+   mhi_state(M2,   "M2")   \
+   mhi_state(M3,   "M3")   \
+   mhi_state(M3_FAST,  "M3_FAST")  \
+   mhi_state(BHI,  "BHI")  \
+   mhi_state_end(SYS_ERR,  "SYS ERROR")
+
+#undef mhi_state
+#undef mhi_state_end
+
+#define mhi_state(a, b)case MHI_STATE_##a: return b;
+#define mhi_state_end(a, b)case MHI_STATE_##a: return b;
+
 static inline const char *mhi_state_str(enum mhi_state state)
 {
switch (state) {
-   case MHI_STATE_RESET:
-   return "RESET";
-   case MHI_STATE_READY:
-   return "READY";
-   case MHI_STATE_M0:
-   return "M0";
-   case MHI_STATE_M1:
-   return "M1";
-   case MHI_STATE_M2:
-   return "M2";
-   case MHI_STATE_M3:
-   return "M3";
-   case MHI_STATE_M3_FAST:
-   return "M3 FAST";
-   case MHI_STATE_BHI:
-   return "BHI";
-   case MHI_STATE_SYS_ERR:
-   return "SYS ERROR";
+  

Re: [PATCH v8] bus: mhi: host: Add tracing support

2024-01-05 Thread Krishna Chaitanya Chundru



On 1/5/2024 10:47 AM, Baochen Qiang wrote:



On 1/4/2024 12:47 PM, Krishna Chaitanya Chundru wrote:

Hi Steven,

Can you please review this.

Thanks & Regards,

Krishna Chaitanya.

On 12/7/2023 10:00 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.
Is there a reason why debug messages have to be removed? From the view 
of MHI controller, we often need MHI logs to debug, so is it possbile 
to preserve those logs?


The trace is being replaced by the debug message and it would be 
preferred to have one mechanism or the other, not both.


you will still see these logs in traces.

- Krishna Chaitanya.



Signed-off-by: Krishna chaitanya chundru 
---
Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign 
as suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com


Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com


Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com


Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print 
the address to avoid

- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com


Changes in v4:
- Fix compilation issues in previous patch which happended due to 
rebasing.
- In the defconfig FTRACE config is not enabled due to that the 
compilation issue is not

- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com


Changes in v3:
- move trace header file from include/trace/events to 
drivers/bus/mhi/host/ so that

- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid 
holes in the buffer.
- removed the mhi_to_physical function as this can give security 
issues.
- removed macros to define strings as we can get those from driver 
headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com


Changes in v2:
- Passing the raw state into the trace event and using 
__print_symbolic() as suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by 
bjorn.

- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com

---
  drivers/bus/mhi/host/init.c  |   3 +
  drivers/bus/mhi/host/main.c  |  19 ++--
  drivers/bus/mhi/host/pm.c    |   7 +-
  drivers/bus/mhi/host/trace.h | 205 
+++

  4 files changed, 221 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
  static DEFINE_IDA(mhi_controller_ida);
  const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..189f4786403e 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include "internal.h"
+#include "trace.h"
  int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,
    void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,8 @@ irqreturn_t mhi_intvec_threaded_handler(int 
irq_number, void *priv)

  state = mhi_get_mhi_state(mhi_cntrl);
  ee = mhi_get_exec_env(mhi_cntrl);
-    dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-    TO_MHI_EXEC_STR(mhi_cntrl->ee),
-    mhi_state_str(mhi_cntrl->dev_state),
-    TO_MHI_EXEC_STR(ee), mhi_state_str(state));
+    trace_mhi_intvec_states(mhi_cntrl, ee, state);
  if (state == MHI_STATE_SYS_ERR) {
  dev_dbg(dev, "System error detected\n");
  pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,8 @@ int mhi_process_ctrl_ev_ring(struct 
mhi_controller *mhi_cntrl,

  while (dev_rp != local_rp) {
  enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
+    trace_mhi_ctrl_event(mhi_cntrl, local_rp);
+
  switc

Re: [PATCH v8] bus: mhi: host: Add tracing support

2024-01-04 Thread Krishna Chaitanya Chundru



On 1/4/2024 9:31 PM, Steven Rostedt wrote:

On Thu, 7 Dec 2023 10:00:47 +0530
Krishna chaitanya chundru  wrote:


This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

So this looks good from a tracing POV.

Reviewed-by: Steven Rostedt (Google) 

But I do have some more comments that could be done by new patches.




+TRACE_EVENT(mhi_intvec_states,
+
+   TP_PROTO(struct mhi_controller *mhi_cntrl, int dev_ee, int dev_state),
+
+   TP_ARGS(mhi_cntrl, dev_ee, dev_state),
+
+   TP_STRUCT__entry(
+   __string(name, mhi_cntrl->mhi_dev->name)
+   __field(int, local_ee)
+   __field(int, state)
+   __field(int, dev_ee)
+   __field(int, dev_state)
+   ),
+
+   TP_fast_assign(
+   __assign_str(name, mhi_cntrl->mhi_dev->name);
+   __entry->local_ee = mhi_cntrl->ee;
+   __entry->state = mhi_cntrl->dev_state;
+   __entry->dev_ee = dev_ee;
+   __entry->dev_state = dev_state;
+   ),
+
+   TP_printk("%s: local ee: %s state: %s device ee: %s state: %s\n",
+ __get_str(name),
+ TO_MHI_EXEC_STR(__entry->local_ee),
+ mhi_state_str(__entry->state),
+ TO_MHI_EXEC_STR(__entry->dev_ee),
+ mhi_state_str(__entry->dev_state))

So the above may have issues with user space parsing.

For one, that mhi_state_str() is:

static inline const char *mhi_state_str(enum mhi_state state)
{
 switch (state) {
 case MHI_STATE_RESET:
 return "RESET";
 case MHI_STATE_READY:
 return "READY";
 case MHI_STATE_M0:
 return "M0";
 case MHI_STATE_M1:
 return "M1";
 case MHI_STATE_M2:
 return "M2";
 case MHI_STATE_M3:
 return "M3";
 case MHI_STATE_M3_FAST:
 return "M3 FAST";
 case MHI_STATE_BHI:
 return "BHI";
 case MHI_STATE_SYS_ERR:
 return "SYS ERROR";
 default:
 return "Unknown state";
 }
};
  
Which if this could be changed into:


#define MHI_STATE_LIST  \
EM(RESET,"RESET") \
EM(READY,"READY") \
EM(M0,   "M0")\
EM(M1,   "M1")\
EM(M2,   "M2")\
EM(M3,   "M3")\
EM(M3_FAST,  "M3_FAST")   \
EM(BHI,  "BHI")   \
EMe(SYS_ERR, "SYS ERROR")

#undef EM
#undef EMe

#define EM(a, b)  case MHI_STATE_##a: return b;
#define EMe(a, b) case MHI_STATE_##a: return b;

static inline const char *mhi_state_str(enum mhi_state state)
{
 switch (state) {
MHI_STATE_LIST
default:
return "Unknown state";
}

Then you could use that macro in the trace header:

#undef EM
#undef EMe

#define EM(a, b)TRACE_DEFINE_ENUM(MHI_STATE_##a);
#define EMe(a, b)   TRACE_DEFINE_ENUM(MHI_STATE_##a);

MHI_STATE_LIST

And in the print fmts:

#undef EM
#undef EMe

#define EM(a, b)   { MHI_STATE_##a, b },
#define EMe(a, b)  { MHI_STATE_##a, b }


TP_printk("%s: local ee: %s state: %s device ee: %s state: %s\n",
  __get_str(name),
  TO_MHI_EXEC_STR(__entry->local_ee),

  __print_symbolic(__entry->state), MHI_STATE_LIST),

  TO_MHI_EXEC_STR(__entry->dev_ee),

  __print_symbolic(__entry->dev_state, MHI_STATE_LIST))


And that will be exported to user space in the
/sys/kernel/tracing/events/*/*/format file, as:

__print_symbolic(REC->state, {
{ MHI_STATE_RESET, "RESET"},
{ MHI_STATE_READY, "READY"},
{ MHI_STATE_M0, "M0"},
{ MHI_STATE_M1, "M1"},
{ MHI_STATE_M2, "M2"},
{ MHI_STATE_M3, "M3"},
{ MHI_STATE_M3_FAST, "M3 FAST&qu

Re: [PATCH v8] bus: mhi: host: Add tracing support

2024-01-03 Thread Krishna Chaitanya Chundru

Hi Steven,

Can you please review this.

Thanks & Regards,

Krishna Chaitanya.

On 12/7/2023 10:00 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
  drivers/bus/mhi/host/init.c  |   3 +
  drivers/bus/mhi/host/main.c  |  19 ++--
  drivers/bus/mhi/host/pm.c|   7 +-
  drivers/bus/mhi/host/trace.h | 205 +++
  4 files changed, 221 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  
+#define CREATE_TRACE_POINTS

+#include "trace.h"
+
  static DEFINE_IDA(mhi_controller_ida);
  
  const char * const mhi_ee_str[MHI_EE_MAX] = {

diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..189f4786403e 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include "internal.h"
+#include "trace.h"
  
  int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,

  void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,8 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
  
  	state = mhi_get_mhi_state(mhi_cntrl);

ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  
+	trace_mhi_intvec_states(mhi_cntrl, ee, state);

if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,8 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_ctrl_event(mhi_cntrl, local_rp);

+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +997,8 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_data_event(mhi_cntrl, local_rp);

+
chan = MHI_TRE_GET_EV_CH

Re: [PATCH v8] bus: mhi: host: Add tracing support

2023-12-11 Thread Krishna Chaitanya Chundru

Hi Steven,

Can you review it once.

Thanks & Regards,

Krishna Chaitanya.

On 12/7/2023 10:00 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
  drivers/bus/mhi/host/init.c  |   3 +
  drivers/bus/mhi/host/main.c  |  19 ++--
  drivers/bus/mhi/host/pm.c|   7 +-
  drivers/bus/mhi/host/trace.h | 205 +++
  4 files changed, 221 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  
+#define CREATE_TRACE_POINTS

+#include "trace.h"
+
  static DEFINE_IDA(mhi_controller_ida);
  
  const char * const mhi_ee_str[MHI_EE_MAX] = {

diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..189f4786403e 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include "internal.h"
+#include "trace.h"
  
  int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,

  void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,8 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
  
  	state = mhi_get_mhi_state(mhi_cntrl);

ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  
+	trace_mhi_intvec_states(mhi_cntrl, ee, state);

if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,8 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_ctrl_event(mhi_cntrl, local_rp);

+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +997,8 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_data_event(mhi_cntrl, local_rp);

+
chan = MHI_TRE_GET_EV_CHID(local_rp)

[PATCH v8] bus: mhi: host: Add tracing support

2023-12-06 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v8:
- Pass the structure and derefernce the variables in TP_fast_assign as 
suggested by steve
- Link to v7: 
https://lore.kernel.org/r/20231206-ftrace_support-v7-1-aca49a042...@quicinc.com

Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c  |   3 +
 drivers/bus/mhi/host/main.c  |  19 ++--
 drivers/bus/mhi/host/pm.c|   7 +-
 drivers/bus/mhi/host/trace.h | 205 +++
 4 files changed, 221 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..189f4786403e 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include "internal.h"
+#include "trace.h"
 
 int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,
  void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,8 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,8 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_ctrl_event(mhi_cntrl, local_rp);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +997,8 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_data_event(mhi_cntrl, local_rp);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1237,7 @@ int mhi_gen_tre(struct mhi_controller *mhi_

Re: [PATCH v7] bus: mhi: host: Add tracing support

2023-12-06 Thread Krishna Chaitanya Chundru



On 12/6/2023 9:25 PM, Steven Rostedt wrote:

On Wed, 6 Dec 2023 21:12:57 +0530
Krishna chaitanya chundru  wrote:


diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  
+#define CREATE_TRACE_POINTS

+#include "trace.h"
+
  static DEFINE_IDA(mhi_controller_ida);
  
  const char * const mhi_ee_str[MHI_EE_MAX] = {

diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..507cf3351a97 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include "internal.h"
+#include "trace.h"
  
  int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,

  void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
  
  	state = mhi_get_mhi_state(mhi_cntrl);

ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  
+	trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,

+   mhi_cntrl->dev_state, ee, state);

I'm not sure if this was discussed before, but why not just pass in the
mhi_cntrl pointer and do the assigning in the TRACE_EVENT()
TP_fast_assign() portion?

It will save on setting up the parameters.


if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +831,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_ctrl_event(mhi_cntrl->mhi_dev->name, local_rp,

+local_rp->ptr, local_rp->dword[0],
+local_rp->dword[1]);

And here..


+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +1000,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  
+		trace_mhi_data_event(mhi_cntrl->mhi_dev->name, local_rp, local_rp->ptr,

+local_rp->dword[0], local_rp->dword[1]);

and here..

for the local_rp. Especially since you are just repeating what you send
into the two events. You can consolidate it down to just adding that in the
TP_fast_assign() of the shared DECLARE_EVENT_CLASS().


+
chan = MHI_TRE_GET_EV_CHID(local_rp);
  
  		WARN_ON(chan >= mhi_cntrl->max_chan);

@@ -1235,6 +1241,8 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct 
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob, chain);
  
+	trace_mhi_gen_tre(mhi_cntrl->mhi_dev->name, mhi_chan->chan, mhi_tre,

+ mhi_tre->ptr, mhi_tre->dword[0], mhi_tre->dword[1]);

Same here. You can pass in the mhi_tre pointer.


/* increment WP */
mhi_add_ring_element(mhi_cntrl, tre_ring);
mhi_add_ring_element(mhi_cntrl, buf_ring);
@@ -1327,9 +1335,7 @@ static int mhi_update_channel_state(struct mhi_controller 
*mhi_cntrl,
enum mhi_cmd_type cmd = MHI_CMD_NOP;
int ret;
  
-	dev_dbg(dev, "%d: Updating channel state to: %s\n", mhi_chan->chan,

-   TO_CH_STATE_TYPE_STR(to_state));
-
+   trace_mhi_channel_command_start(mhi_cntrl->mhi_dev->name, 
mhi_chan->chan, to_state);

And here..


switch (to_state) {
case MHI_CH_STATE_TYPE_RESET:
write_lock_irq(_chan->lock);
@@ -1396,9 +1402,7 @@ static int mhi_update_channel_state(struct mhi_controller 
*mhi_cntrl,
write_unlock_irq(_chan->lock);
}
  
-	dev_dbg(dev, "%d: Channel state change to %s successful\n",

-   mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
-
+   trace_mhi_channel_command_end(mhi_cntrl->mhi_dev->name, mhi_chan->chan, 
to_state);

and here..

Where you can also update the DECLARE_EVENT_CLASS() to directly access the
mhi_cntrl and mhi_chan pointers. Sometimes it's better to do the
dereference from inside the TP_fast_assign. That way, things like eprobes
and bpf tracing can also have access to the full structure if needed.

-- Steve


Hi Steve,

I will make changes as suggested in the next patch series.

- Krishna Chaitanya.




[PATCH v7] bus: mhi: host: Add tracing support

2023-12-06 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v7:
- change log format as pointed by mani.
- Link to v6: 
https://lore.kernel.org/r/20231204-ftrace_support-v6-1-9b206546d...@quicinc.com

Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c  |   3 +
 drivers/bus/mhi/host/main.c  |  24 ++---
 drivers/bus/mhi/host/pm.c|   7 +-
 drivers/bus/mhi/host/trace.h | 208 +++
 4 files changed, 229 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..507cf3351a97 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include "internal.h"
+#include "trace.h"
 
 int __must_check mhi_read_reg(struct mhi_controller *mhi_cntrl,
  void __iomem *base, u32 offset, u32 *out)
@@ -491,11 +492,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+   mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +831,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_ctrl_event(mhi_cntrl->mhi_dev->name, local_rp,
+local_rp->ptr, local_rp->dword[0],
+local_rp->dword[1]);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +1000,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_data_event(mhi_cntrl->mhi_dev->name, local_rp, 
local_rp->ptr,
+local_rp->dword[0], local_rp->dword[1]);

[PATCH v6] bus: mhi: host: Add tracing support

2023-12-04 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v6:
- use 'rp' directly as suggested by jeffrey.
- Link to v5: 
https://lore.kernel.org/r/20231127-ftrace_support-v5-1-eb67daead...@quicinc.com

Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  23 +++--
 drivers/bus/mhi/host/pm.c   |   6 +-
 drivers/bus/mhi/host/trace.h| 208 
 5 files changed, 228 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a02a71605907 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include "trace.h"
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..0d7e068e713a 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+   mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_ctrl_event(mhi_cntrl->mhi_dev->name, local_rp,
+local_rp->ptr, local_rp->dword[0],
+local_rp->dword[1]);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +999,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_data_event(mhi_cntrl->mhi_dev->name, local_rp, 
local_rp->ptr,
+local_rp->dword[0], local_rp-&

Re: [PATCH v5] bus: mhi: host: Add tracing support

2023-12-04 Thread Krishna Chaitanya Chundru



On 12/1/2023 10:31 PM, Jeffrey Hugo wrote:

On 11/27/2023 4:09 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the 
address to avoid

- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com


Changes in v4:
- Fix compilation issues in previous patch which happended due to 
rebasing.
- In the defconfig FTRACE config is not enabled due to that the 
compilation issue is not

- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com


Changes in v3:
- move trace header file from include/trace/events to 
drivers/bus/mhi/host/ so that

- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid 
holes in the buffer.

- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver 
headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com


Changes in v2:
- Passing the raw state into the trace event and using 
__print_symbolic() as suggested by bjorn.

- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com

---
  drivers/bus/mhi/host/init.c |   3 +
  drivers/bus/mhi/host/internal.h |   1 +
  drivers/bus/mhi/host/main.c |  23 +++--
  drivers/bus/mhi/host/pm.c   |   6 +-
  drivers/bus/mhi/host/trace.h    | 208 


  5 files changed, 228 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  +#define CREATE_TRACE_POINTS
+#include "trace.h"
+
  static DEFINE_IDA(mhi_controller_ida);
    const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h 
b/drivers/bus/mhi/host/internal.h

index 2e139e76de4c..a02a71605907 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
  #ifndef _MHI_INT_H
  #define _MHI_INT_H
  +#include "trace.h"
  #include "../common.h"
    extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..0d7e068e713a 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,9 @@ irqreturn_t mhi_intvec_threaded_handler(int 
irq_number, void *priv)

    state = mhi_get_mhi_state(mhi_cntrl);
  ee = mhi_get_exec_env(mhi_cntrl);
-    dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-    TO_MHI_EXEC_STR(mhi_cntrl->ee),
-    mhi_state_str(mhi_cntrl->dev_state),
-    TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  +    trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+    mhi_cntrl->dev_state, ee, state);
  if (state == MHI_STATE_SYS_ERR) {
  dev_dbg(dev, "System error detected\n");
  pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,10 @@ int mhi_process_ctrl_ev_ring(struct 
mhi_controller *mhi_cntrl,

  while (dev_rp != local_rp) {
  enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  +    trace_mhi_ctrl_event(mhi_cntrl->mhi_dev->name, local_rp,
+ local_rp->ptr, local_rp->dword[0],
+ local_rp->dword[1]);
+
  switch (type) {
  case MHI_PKT_TYPE_BW_REQ_EVENT:
  {
@@ -997,6 +999,9 @@ int mhi_process_data_event_ring(struct 
mhi_controller *mhi_cntrl,

  while (dev_rp != local_rp && event_quota > 0) {
  enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
  +    trace_mhi_data_event(mhi_cntrl->mhi_dev->name, local_rp, 
local_rp->ptr,

+ local_rp->dword[0], local_rp->dword[1]);
+
  chan = MHI_TRE_GET_EV_CHID(local_rp);
    WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1240,8 @@ int mhi_gen_tre(struct mhi_con

[PATCH v5] bus: mhi: host: Add tracing support

2023-11-27 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever the trace events are added, debug messages are removed.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v5:
- Use DECLARE_EVENT_CLASS for multiple events as suggested by steve.
- Instead of converting to u64 to print address, use %px to print the address 
to avoid
- warnings in some platforms.
- Link to v4: 
https://lore.kernel.org/r/2023-ftrace_support-v4-1-c83602399...@quicinc.com

Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  23 +++--
 drivers/bus/mhi/host/pm.c   |   6 +-
 drivers/bus/mhi/host/trace.h| 208 
 5 files changed, 228 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a02a71605907 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include "trace.h"
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..0d7e068e713a 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+   mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_ctrl_event(mhi_cntrl->mhi_dev->name, local_rp,
+local_rp->ptr, local_rp->dword[0],
+local_rp->dword[1]);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +999,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_data_event(mhi_cntrl->mhi_dev->name, local_rp, 
local_rp->ptr,
+local_rp->dword[0], local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1240,8 @@ int mh

Re: [PATCH v4] bus: mhi: host: Add tracing support

2023-11-13 Thread Krishna Chaitanya Chundru



On 11/12/2023 1:07 AM, Steven Rostedt wrote:

On Sat, 11 Nov 2023 11:25:22 +0530
Krishna chaitanya chundru  wrote:

diff --git a/drivers/bus/mhi/host/trace.h b/drivers/bus/mhi/host/trace.h
new file mode 100644
index ..0e99318f5d08
--- /dev/null
+++ b/drivers/bus/mhi/host/trace.h
+
+TRACE_EVENT(mhi_update_channel_state_start,
+
+   TP_PROTO(const char *name, int ch_num, int state),
+
+   TP_ARGS(name, ch_num, state),
+
+   TP_STRUCT__entry(
+   __string(name, name)
+   __field(int, ch_num)
+   __field(int, state)
+   ),
+
+   TP_fast_assign(
+   __assign_str(name, name);
+   __entry->ch_num = ch_num;
+   __entry->state = state;
+   ),
+
+   TP_printk("%s: ch%d: Updating state to: %s\n",
+ __get_str(name), __entry->ch_num,
+ TO_CH_STATE_TYPE_STR(__entry->state))
+);
+
+TRACE_EVENT(mhi_update_channel_state_end,
+
+   TP_PROTO(const char *name, int ch_num, int state),
+
+   TP_ARGS(name, ch_num, state),
+
+   TP_STRUCT__entry(
+   __string(name, name)
+   __field(int, ch_num)
+   __field(int, state)
+   ),
+
+   TP_fast_assign(
+   __assign_str(name, name);
+   __entry->ch_num = ch_num;
+   __entry->state = state;
+   ),
+
+   TP_printk("%s: ch%d: Updated state to: %s\n",
+ __get_str(name), __entry->ch_num,
+ TO_CH_STATE_TYPE_STR(__entry->state))
+);
+

The above three events have the same format. You can save kilobytes of
memory by converting them into a DECLARE_EVENT_CLASS() and use
DEFINE_EVENT() for each event.

A TRACE_EVENT() macro is really just a wrapper around
DECLARE_EVENT_CLASS() and DEFINE_EVENT(). The DECLARE_EVENT_CLASS()
does the bulk of the work and adds the most memory footprint. By
breaking it apart for several events, it does save memory.

Whenever you can use a single DECLARE_EVENT_CLASS() for multiple
events, I strongly suggest doing so.

Thanks,

-- Steve


Sure steve I will change as suggested in my next patch.

- Krishna Chaitanya.




+#endif
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE trace
+
+#include 

---
base-commit: 3006adf3be79cde4d14b1800b963b82b6e5572e0
change-id: 20231005-ftrace_support-6869d4156139

Best regards,




[PATCH v4] bus: mhi: host: Add tracing support

2023-11-10 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever we added trace events removing debug messages.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v4:
- Fix compilation issues in previous patch which happended due to rebasing.
- In the defconfig FTRACE config is not enabled due to that the compilation 
issue is not
- seen in my workspace.
- Link to v3: 
https://lore.kernel.org/r/2023-ftrace_support-v3-1-f358d2911...@quicinc.com

Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  24 +++--
 drivers/bus/mhi/host/pm.c   |   6 +-
 drivers/bus/mhi/host/trace.h| 225 
 5 files changed, 246 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a02a71605907 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include "trace.h"
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..923d51904f35 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+   mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_ctrl_ev_ring(mhi_cntrl->mhi_dev->name, 
local_rp,
+  local_rp->ptr, 
local_rp->dword[0],
+  local_rp->dword[1]);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +999,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_data_event_ring(mhi_cntrl->mhi_dev->name, 
local_rp->ptr,
+ local_rp->dword[0], 
local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1240,8 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct 
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob, chain);
 
+   trace_mhi_gen_tre(mhi_cntrl->mhi_

[PATCH v3] bus: mhi: host: Add tracing support

2023-11-10 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Where ever we added trace events removing debug messages.

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v3:
- move trace header file from include/trace/events to drivers/bus/mhi/host/ so 
that
- we can include driver header files.
- Use macros directly in the trace events as suggested Jeffrey Hugo.
- Reorder the structure in the events as suggested by steve to avoid holes in 
the buffer.
- removed the mhi_to_physical function as this can give security issues.
- removed macros to define strings as we can get those from driver headers.
- Link to v2: 
https://lore.kernel.org/r/20231013-ftrace_support-v2-1-6e893ce01...@quicinc.com

Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  24 +++--
 drivers/bus/mhi/host/pm.c   |   6 +-
 drivers/bus/mhi/host/trace.h| 224 
 5 files changed, 245 insertions(+), 13 deletions(-)

diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..6acb85f4c5f8 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a02a71605907 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include "trace.h"
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..7fe8b2dd9e24 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_states(mhi_cntrl->mhi_dev->name, mhi_cntrl->ee,
+   mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +830,10 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_ctrl_ev_ring(mhi_cntrl->mhi_dev->name, 
(u64)local_rp,
+  local_rp->ptr, 
local_rp->dword[0],
+  local_rp->dword[1]);
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +999,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_data_event_ring(mhi_cntrl->mhi_dev->name, 
local_rp->ptr,
+ local_rp->dword[0], 
local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1240,8 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct 
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob, chain);
 
+   trace_mhi_gen_tre(mhi_cntrl->mhi_dev->name, mhi_chan->chan, 
(u64)mhi_tre,
+ mhi_tre->ptr, mhi_tre->dword[0], mhi_tre->dword[1]);
/* increment WP */
mhi_add_ring_element(mhi_cntrl, tre_ring);
mhi_add_ring_element(mhi_cntrl, buf_ring);
@@ -1327,9 +1334,8 @@ sta

Re: [PATCH v2] bus: mhi: host: Add tracing support

2023-10-30 Thread Krishna Chaitanya Chundru



On 10/27/2023 8:59 PM, Jeffrey Hugo wrote:

On 10/23/2023 1:11 AM, Krishna Chaitanya Chundru wrote:


On 10/20/2023 8:33 PM, Jeffrey Hugo wrote:

On 10/13/2023 3:52 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v2:
- Passing the raw state into the trace event and using 
__print_symbolic() as suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by 
bjorn.

- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com 


---
  MAINTAINERS |   1 +
  drivers/bus/mhi/host/init.c |   3 +
  drivers/bus/mhi/host/internal.h |   1 +
  drivers/bus/mhi/host/main.c |  32 +++--
  drivers/bus/mhi/host/pm.c   |   6 +-
  include/trace/events/mhi_host.h | 287 


  6 files changed, 317 insertions(+), 13 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 35977b269d5e..4339c668a6ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13862,6 +13862,7 @@ F:    Documentation/mhi/
  F:    drivers/bus/mhi/
  F:    drivers/pci/endpoint/functions/pci-epf-mhi.c
  F:    include/linux/mhi.h
+F:    include/trace/events/mhi_host.h
    MICROBLAZE ARCHITECTURE
  M:    Michal Simek 
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..3afa90a204fd 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  +#define CREATE_TRACE_POINTS
+#include 


This feels redundant to me.  A few lines ago we included internal.h, 
and internal.h includes trace/events/mhi_host.h


As Steve mentioned, this is mandatory step for creating trace points 
& trace events.


I understand this creates the trace points, and that needs to be done 
in C code.  It dtill seems redundant because we are including the 
header twice (and I am aware trace has the special multi-header read 
functionality for this).


The duplicate include still feels weird, but I have not come up with a 
better way to structure this.
We will use this way for now then, we will check in parallel if there 
is  a way to avoid this and change it in the future.







+
  static DEFINE_IDA(mhi_controller_ida);
    const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h 
b/drivers/bus/mhi/host/internal.h

index 2e139e76de4c..a80a317a59a9 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
  #ifndef _MHI_INT_H
  #define _MHI_INT_H
  +#include 
  #include "../common.h"
    extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..fcdb728ba49f 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -246,6 +246,11 @@ static void *mhi_to_virtual(struct mhi_ring 
*ring, dma_addr_t addr)

  return (addr - ring->iommu_base) + ring->base;
  }
  +dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
+{
+    return (addr - ring->base) + ring->iommu_base;
+}


This seems to be poorly named since we are using the iommu_base 
which suggests we are converting to an IOVA.


Why do we need this though?  This seems like it might be a security 
issue, or at the very least, not preferred, and I'm struggling to 
figure out what value this provides to you are I when looking at the 
log.



I will rename the function to reflect it is converting to IOVA.

We MHI TRE we write the IOVA address, to correlate between TRE events 
in the MHI ring and event we are processing  we want to log the IOVA 
address.


As we are logging only IOVA address which is provided in the 
devicetree and not the original physical address we are not expecting 
any security issues here.


Correct me if I was wrong.


The IOVA is not provided by DT, it is a runtime allocated value 
provided by the IOMMU, if present.  If not present, then it is a 
physical address.


Remember, x86 does not use devicetree.

While the IOVA (with an iommu) is not technically a physical address, 
but is treated as such by the device.  I can imagine an attacker doing 
bad things if they get a hold of the value.

Sure we will remove it.


Still, you haven't indicated why this is useful.


The TRE ring elements has address in the IOVA format when we want to 
correlate the address with the TRE elements in the dumps it will easier 
with this way.


Anyway we will not expose this as you suggested as it might expose 
physical address in some platforms.







+
 

Re: [PATCH v2] bus: mhi: host: Add tracing support

2023-10-23 Thread Krishna Chaitanya Chundru



On 10/20/2023 8:33 PM, Jeffrey Hugo wrote:

On 10/13/2023 3:52 AM, Krishna chaitanya chundru wrote:

This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v2:
- Passing the raw state into the trace event and using 
__print_symbolic() as suggested by bjorn.

- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com

---
  MAINTAINERS |   1 +
  drivers/bus/mhi/host/init.c |   3 +
  drivers/bus/mhi/host/internal.h |   1 +
  drivers/bus/mhi/host/main.c |  32 +++--
  drivers/bus/mhi/host/pm.c   |   6 +-
  include/trace/events/mhi_host.h | 287 


  6 files changed, 317 insertions(+), 13 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 35977b269d5e..4339c668a6ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13862,6 +13862,7 @@ F:    Documentation/mhi/
  F:    drivers/bus/mhi/
  F:    drivers/pci/endpoint/functions/pci-epf-mhi.c
  F:    include/linux/mhi.h
+F:    include/trace/events/mhi_host.h
    MICROBLAZE ARCHITECTURE
  M:    Michal Simek 
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..3afa90a204fd 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
  #include 
  #include "internal.h"
  +#define CREATE_TRACE_POINTS
+#include 


This feels redundant to me.  A few lines ago we included internal.h, 
and internal.h includes trace/events/mhi_host.h


As Steve mentioned, this is mandatory step for creating trace points & 
trace events.





+
  static DEFINE_IDA(mhi_controller_ida);
    const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h 
b/drivers/bus/mhi/host/internal.h

index 2e139e76de4c..a80a317a59a9 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
  #ifndef _MHI_INT_H
  #define _MHI_INT_H
  +#include 
  #include "../common.h"
    extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..fcdb728ba49f 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -246,6 +246,11 @@ static void *mhi_to_virtual(struct mhi_ring 
*ring, dma_addr_t addr)

  return (addr - ring->iommu_base) + ring->base;
  }
  +dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
+{
+    return (addr - ring->base) + ring->iommu_base;
+}


This seems to be poorly named since we are using the iommu_base which 
suggests we are converting to an IOVA.


Why do we need this though?  This seems like it might be a security 
issue, or at the very least, not preferred, and I'm struggling to 
figure out what value this provides to you are I when looking at the log.



I will rename the function to reflect it is converting to IOVA.

We MHI TRE we write the IOVA address, to correlate between TRE events in 
the MHI ring and event we are processing  we want to log the IOVA address.


As we are logging only IOVA address which is provided in the devicetree 
and not the original physical address we are not expecting any security 
issues here.


Correct me if I was wrong.


+
  static void mhi_add_ring_element(struct mhi_controller *mhi_cntrl,
   struct mhi_ring *ring)
  {
@@ -491,11 +496,9 @@ irqreturn_t mhi_intvec_threaded_handler(int 
irq_number, void *priv)

    state = mhi_get_mhi_state(mhi_cntrl);
  ee = mhi_get_exec_env(mhi_cntrl);
-    dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-    TO_MHI_EXEC_STR(mhi_cntrl->ee),
-    mhi_state_str(mhi_cntrl->dev_state),
-    TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  + trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name, 
mhi_cntrl->ee,

+  mhi_cntrl->dev_state, ee, state);


Why are we removing the debug message when adding this trace?  The 
commit text doesn't say.  (Looks like you do this several times, 
assume this comment applies to all isntances)


I will add this in the commit text in my next patch.

Just a query is recommended to keep both debug message and trace events. 
If yes we will not remove the debug messages.





  if (state == MHI_STATE_SYS_ERR) {
  dev_dbg(dev, "System error detected\n");
  pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +835,12 @@ int mhi_process_ctrl_ev_ring(struct 
mhi_controller *mhi_cntrl,

  while (dev_rp 

Re: [PATCH v2] bus: mhi: host: Add tracing support

2023-10-17 Thread Krishna Chaitanya Chundru



On 10/16/2023 8:43 PM, Steven Rostedt wrote:

On Fri, 13 Oct 2023 15:22:19 +0530
Krishna chaitanya chundru  wrote:


+++ b/include/trace/events/mhi_host.h
@@ -0,0 +1,287 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM mhi_host
+
+#if !defined(_TRACE_EVENT_MHI_HOST_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_EVENT_MHI_HOST_H
+
+#include 
+#define MHI_STATE  \
+   EM(MHI_STATE_RESET, "RESET")  \
+   EM(MHI_STATE_READY, "READY")  \
+   EM(MHI_STATE_M0,"M0") \
+   EM(MHI_STATE_M1,"M1") \
+   EM(MHI_STATE_M2,"M2") \
+   EM(MHI_STATE_M3,"M3") \
+   EM(MHI_STATE_M3_FAST,   "M3 FAST")\
+   EM(MHI_STATE_BHI,   "BHI")\
+   EMe(MHI_STATE_SYS_ERR,  "SYS ERROR")
+
+#define MHI_EE \
+   EM(MHI_EE_PBL,  "PRIMARY BOOTLOADER") \
+   EM(MHI_EE_SBL,  "SECONDARY BOOTLOADER")   \
+   EM(MHI_EE_AMSS, "MISSION MODE")   \
+   EM(MHI_EE_RDDM, "RAMDUMP DOWNLOAD MODE")  \
+   EM(MHI_EE_WFW,  "WLAN FIRMWARE")  \
+   EM(MHI_EE_PTHRU,"PASS THROUGH")   \
+   EM(MHI_EE_EDL,  "EMERGENCY DOWNLOAD") \
+   EM(MHI_EE_FP,   "FLASH PROGRAMMER")   \
+   EM(MHI_EE_DISABLE_TRANSITION,   "DISABLE")\
+   EMe(MHI_EE_NOT_SUPPORTED,   "NOT SUPPORTED")
+
+#define MHI_PM_STATE   \
+   EM(MHI_PM_STATE_DISABLE,"DISABLE")\
+   EM(MHI_PM_STATE_POR,"POWER ON RESET") \
+   EM(MHI_PM_STATE_M0, "M0") \
+   EM(MHI_PM_STATE_M2, "M2") \
+   EM(MHI_PM_STATE_M3_ENTER,   "M?->M3")  \
+   EM(MHI_PM_STATE_M3, "M3") \
+   EM(MHI_PM_STATE_M3_EXIT,"M3->M0")  \
+   EM(MHI_PM_STATE_FW_DL_ERR,  "Firmware Download Error")\
+   EM(MHI_PM_STATE_SYS_ERR_DETECT, "SYS ERROR Detect")   \
+   EM(MHI_PM_STATE_SYS_ERR_PROCESS,"SYS ERROR Process")  \
+   EM(MHI_PM_STATE_SHUTDOWN_PROCESS,   "SHUTDOWN Process")   \
+   EMe(MHI_PM_STATE_LD_ERR_FATAL_DETECT,   "Linkdown or Error Fatal 
Detect")
+
+#define MHI_CH_STATE   \
+   EM(MHI_CH_STATE_TYPE_RESET, "RESET")  \
+   EM(MHI_CH_STATE_TYPE_STOP, "STOP")\
+   EMe(MHI_CH_STATE_TYPE_START, "START")
+
+#define MHI_DEV_ST_TRANSITION  \
+   EM(DEV_ST_TRANSITION_PBL,   "PBL")\
+   EM(DEV_ST_TRANSITION_READY, "READY")  \
+   EM(DEV_ST_TRANSITION_SBL,   "SBL")\
+   EM(DEV_ST_TRANSITION_MISSION_MODE,  "MISSION MODE")   \
+   EM(DEV_ST_TRANSITION_FP,"FLASH PROGRAMMER")   \
+   EM(DEV_ST_TRANSITION_SYS_ERR,   "SYS ERROR")  \
+   EMe(DEV_ST_TRANSITION_DISABLE,  "DISABLE")
+
+/* Enums require being exported to userspace, for user tool parsing */
+#undef EM
+#undef EMe
+#defineEM(a, b)TRACE_DEFINE_ENUM(a);
+#defineEMe(a, b)   TRACE_DEFINE_ENUM(a);
+
+MHI_STATE
+MHI_EE
+MHI_PM_STATE
+MHI_CH_STATE
+MHI_DEV_ST_TRANSITION
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b)   {a, b},
+#define EMe(a, b)  {a, b}
+
+TRACE_EVENT(mhi_gen_tre,
+
+   TP_PROTO(const char *name, int ch_num, u64 wp, __le64 tre_ptr,
+__le32 dword0, __le32 dword1),
+
+   TP_ARGS(name, ch_num, wp, tre_ptr, dword0, dword1),
+
+   TP_STRUCT__entry(
+   __string(name, name)
+   __field(int, ch_num)

This is fine as __string() is four bytes in the event (2 bytes for offset
where the string exists, and 2 bytes for its length).


+   __field(u64, 

Re: [PATCH] bus: mhi: host: Add tracing support

2023-10-13 Thread Krishna Chaitanya Chundru



On 10/6/2023 4:10 AM, Bjorn Andersson wrote:

On Thu, Oct 05, 2023 at 03:55:20PM +0530, Krishna chaitanya chundru wrote:

This change adds ftrace support for following:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

This is not the best "problem description".


Usage:
echo 1 > /sys/kernel/debug/tracing/events/mhi_host/enable
cat /sys/kernel/debug/tracing/trace

This does not need to be included in the commit message, how to use the
tracing framework is documented elsewhere.

Removed this now.

[..]

diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..499590437e9b 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,10 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
  
  	state = mhi_get_mhi_state(mhi_cntrl);

ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
  
+	trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name, TO_MHI_EXEC_STR(mhi_cntrl->ee),

+ mhi_state_str(mhi_cntrl->dev_state),
+ TO_MHI_EXEC_STR(ee), 
mhi_state_str(state));

All these helper functions that translates a state to a string, pass the
raw state into the trace event and use __print_symbolic() in your
TP_printk() instead.

This will allow you to read the state, but you can have tools act of the
numerical value.


(This comment applies to all the trace events)

changed the events as you suggested.

if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,

[..]

diff --git a/include/trace/events/mhi_host.h b/include/trace/events/mhi_host.h

[..]

+
+TRACE_EVENT(mhi_pm_st_worker,

Why is this trace event called "worker", isn't the event a
"mhi_pm_state_transition"?

Don't just name your trace event based on the function that triggers
them, but what they represent and make sure they carry useful
information to understand the system.

If you want to trace the flow through your functions, you can use e.g.
ftrace.

Regards,
Bjorn


Changed as you suggested.

- KC




[PATCH v2] bus: mhi: host: Add tracing support

2023-10-13 Thread Krishna chaitanya chundru
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Signed-off-by: Krishna chaitanya chundru 
---
Changes in v2:
- Passing the raw state into the trace event and using  __print_symbolic() as 
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1: 
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
 MAINTAINERS |   1 +
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  32 +++--
 drivers/bus/mhi/host/pm.c   |   6 +-
 include/trace/events/mhi_host.h | 287 
 6 files changed, 317 insertions(+), 13 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 35977b269d5e..4339c668a6ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13862,6 +13862,7 @@ F:  Documentation/mhi/
 F: drivers/bus/mhi/
 F: drivers/pci/endpoint/functions/pci-epf-mhi.c
 F: include/linux/mhi.h
+F: include/trace/events/mhi_host.h
 
 MICROBLAZE ARCHITECTURE
 M: Michal Simek 
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..3afa90a204fd 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include 
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a80a317a59a9 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include 
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..fcdb728ba49f 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -246,6 +246,11 @@ static void *mhi_to_virtual(struct mhi_ring *ring, 
dma_addr_t addr)
return (addr - ring->iommu_base) + ring->base;
 }
 
+dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
+{
+   return (addr - ring->base) + ring->iommu_base;
+}
+
 static void mhi_add_ring_element(struct mhi_controller *mhi_cntrl,
 struct mhi_ring *ring)
 {
@@ -491,11 +496,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name, 
mhi_cntrl->ee,
+ mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +835,12 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_ctrl_ev_ring(mhi_cntrl->mhi_dev->name,
+  mhi_to_physical(ev_ring, 
local_rp),
+  local_rp->ptr, 
local_rp->dword[0],
+  local_rp->dword[1],
+  MHI_TRE_GET_EV_STATE(local_rp));
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +1006,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_data_event_ring(mhi_cntrl->mhi_dev->name, 
local_rp->ptr,
+ local_rp->dword[0], 
local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1247,9 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct 
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob

[PATCH] bus: mhi: host: Add tracing support

2023-10-05 Thread Krishna chaitanya chundru
This change adds ftrace support for following:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker

Usage:
echo 1 > /sys/kernel/debug/tracing/events/mhi_host/enable
cat /sys/kernel/debug/tracing/trace

Signed-off-by: Krishna chaitanya chundru 
---
 MAINTAINERS |   1 +
 drivers/bus/mhi/host/init.c |   3 +
 drivers/bus/mhi/host/internal.h |   1 +
 drivers/bus/mhi/host/main.c |  27 --
 drivers/bus/mhi/host/pm.c   |   7 +-
 include/trace/events/mhi_host.h | 207 
 6 files changed, 234 insertions(+), 12 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 35977b269d5e..4339c668a6ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13862,6 +13862,7 @@ F:  Documentation/mhi/
 F: drivers/bus/mhi/
 F: drivers/pci/endpoint/functions/pci-epf-mhi.c
 F: include/linux/mhi.h
+F: include/trace/events/mhi_host.h
 
 MICROBLAZE ARCHITECTURE
 M: Michal Simek 
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..3afa90a204fd 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
 #include 
 #include "internal.h"
 
+#define CREATE_TRACE_POINTS
+#include 
+
 static DEFINE_IDA(mhi_controller_ida);
 
 const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a80a317a59a9 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
 #ifndef _MHI_INT_H
 #define _MHI_INT_H
 
+#include 
 #include "../common.h"
 
 extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..499590437e9b 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,10 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
void *priv)
 
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
-   dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee),
-   mhi_state_str(mhi_cntrl->dev_state),
-   TO_MHI_EXEC_STR(ee), mhi_state_str(state));
 
+   trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name, 
TO_MHI_EXEC_STR(mhi_cntrl->ee),
+ mhi_state_str(mhi_cntrl->dev_state),
+ TO_MHI_EXEC_STR(ee), 
mhi_state_str(state));
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +831,11 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_ctrl_ev_ring(mhi_cntrl->mhi_dev->name, 
(u64)(local_rp),
+  local_rp->ptr, 
local_rp->dword[0],
+  local_rp->dword[1],
+  
mhi_state_str(MHI_TRE_GET_EV_STATE(local_rp)));
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +1001,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
+   trace_mhi_process_data_event_ring(mhi_cntrl->mhi_dev->name, 
local_rp->ptr,
+ local_rp->dword[0], 
local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
 
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1242,8 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct 
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob, chain);
 
+   trace_mhi_gen_tre(mhi_cntrl->mhi_dev->name, mhi_chan->chan, 
(u64)(mhi_tre),
+ mhi_tre->ptr, mhi_tre->dword[0], mhi_tre->dword[1]);
/* increment WP */
mhi_add_ring_element(mhi_cntrl, tre_ring);
mhi_add_ring_element(mhi_cntrl, buf_ring);
@@ -1327,9 +1336,8 @@ static int mhi_update_channel_state(struct mhi_controller 
*mhi_cntrl,
enum mhi_cmd_type cmd = MHI_CMD_NOP;
int ret;
 
-   dev_dbg(dev, "%d: Updating channel state to: %s\n", mhi_chan->chan,
-   TO_CH_STATE_TYPE_STR(to_state));
-
+   trace_mhi_update_channel_state_start(mhi_cntrl->mhi_dev->name, 
mhi_

Module versioning + Missing CRC in symvers + export tracepoints

2021-04-20 Thread Krishna Chaitanya
Hi,

I am seeing an issue of no CRC being generated in the Module.symvers for a
driver module even when CONFIG_MODVERSIONS Is enabled, this causes
modpost warnings about missing versioning.

The module in questions only exports tracepoint related symbols (as
struct tracepoint is
part of the module CRC), I have seen this with other modules also e.g.
iwlwifi with CONFIG_MODVERSIONS.

Though I am trying on 5.12.-rc2, also, seeing this issue with older kernels with
CONFIG_MODVERSIONS enabled e.g. 4.15.0, Below are a couple of snippets
to demonstrate the issue.

modpost warnings
===

WARNING: modpost: EXPORT symbol "__tracepoint_iwlwifi_dev_ucode_event"
[drivers/net/wireless/intel/iwlwifi//iwlwifi.ko] version generation
failed, symbol will not be versioned.
WARNING: modpost: EXPORT symbol "iwl_remove_notification"
[drivers/net/wireless/intel/iwlwifi//iwlwifi.ko] version generation
failed, symbol will not be versioned.


Module.symvers (after modpost)
==
0x  iwl_remove_notification
drivers/net/wireless/intel/iwlwifi//iwlwifi EXPORT_SYMBOL_GPL
0x  __tracepoint_iwlwifi_dev_ucode_event
drivers/net/wireless/intel/iwlwifi//iwlwifi EXPORT_SYMBOL

Any ideas?


[PATCH v5 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-04-15 Thread Sai Krishna Potthuri
Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/pinctrl/Kconfig  |  14 +
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 906 +++
 3 files changed, 921 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..736f5230590b 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,20 @@ config PINCTRL_ZYNQ
help
  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+   tristate "Pinctrl driver for Xilinx ZynqMP"
+   depends on ZYNQMP_FIRMWARE
+   select PINMUX
+   select GENERIC_PINCONF
+   default ZYNQMP_FIRMWARE
+   help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..cd28423fd8d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)   += pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..e5f3f5794c66
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,906 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri 
+ * Rajan Vaja 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX  "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN  16
+#define MAX_GROUP_PIN  50
+#define MAX_PIN_GROUPS 50
+#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP   0x
+#define RESERVED_GROUP 0xFFFE
+
+#define DRIVE_STRENGTH_2MA 2
+#define DRIVE_STRENGTH_4MA 4
+#define DRIVE_STRENGTH_8MA 8
+#define DRIVE_STRENGTH_12MA12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:  Name of the pin mux function
+ * @groups:List of pin groups for this function
+ * @ngroups:   Number of entries in @groups
+ * @node:  Firmware node matching with the function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+   char name[MAX_FUNC_NAME_LEN];
+   const char * const *groups;
+   unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pin control device
+ * @groups:Pin groups
+ * @ngroups:   Number of @groups
+ * @funcs: Pin mux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+   struct pinctrl_dev *pctrl;
+   const struct zynqmp_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynqmp_pmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:  Group name
+ * @pins:  Group pin numbers
+ * @npins: Number of pins in the group
+ */
+struct zynqmp_pctrl_group {
+   const char *name;
+   unsigned int pins[MAX_GROUP_PIN];
+   unsigned int npins;
+};
+
+static struct pinctrl_desc zynqmp_desc;
+
+static int zynqmp_pctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+   struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+   return pctrl->ngroups;
+}
+
+static const char *zynqmp_pctrl_get_group_name(struct pinctrl_dev *p

[PATCH v5 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver

2021-04-15 Thread Sai Krishna Potthuri
Adding documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri 
Reviewed-by: Rob Herring 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 2 files changed, 355 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index ..8ef0d07d35fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,336 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri 
+  - Rajan Vaja 
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number 
of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin 
configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux 
and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+type: object
+patternProperties:
+  '^mux':
+type: object
+description:
+  Pinctrl node's client devices use subnodes for pin muxes,
+  which in turn use below standard properties.
+$ref: pinmux-node.yaml#
+
+properties:
+  groups:
+description:
+  List of groups to select (either this or "pins" must be
+  specified), available groups for this subnode.
+items:
+  enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+ sdio1_3_grp, sdio

[PATCH v5 0/3] Add ZynqMP pinctrl driver

2021-04-15 Thread Sai Krishna Potthuri
Add support for Xilinx ZynqMP pinctrl driver and also update
the Xilinx firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and
allow configuring the pins as per the request.

changes in v5:
- Used generic property 'power-source' instead of driver specific for
configuring the IO voltages, updated the same in dt-binding.
- Added support to build driver as a module.
- Used error codes returned by the Xilinx firmware instead of shadowing the
error codes in the driver.
- Fixed comments from Andy related to spell checks, NULL checks, explicit
typecast, header inclusion ordering, removing kernel docs for the
obvious ones.

changes in v4:
- Added comment for ignoring the return value for GET_FUNCTION_NAME qid.
- Updated the zynqmp_pinctrl_get_function_name() API prototype to void as
it always returns zero.

changes in v3:
- Fixed binding doc comments from Rob.
- Used 'maxItems' for groups and pins properties.
- Updated commit subject and description to have present tense statements.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

Sai Krishna Potthuri (3):
  firmware: xilinx: Add pinctrl support
  dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver
  pinctrl: Add Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 +++
 drivers/firmware/xilinx/zynqmp.c  | 114 +++
 drivers/pinctrl/Kconfig   |  14 +
 drivers/pinctrl/Makefile  |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c  | 906 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 include/linux/firmware/xlnx-zynqmp.h  |  90 ++
 7 files changed, 1480 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



[PATCH v5 1/3] firmware: xilinx: Add pinctrl support

2021-04-15 Thread Sai Krishna Potthuri
Adding pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri 
Acked-by: Michal Simek 
---
 drivers/firmware/xilinx/zynqmp.c | 114 +++
 include/linux/firmware/xlnx-zynqmp.h |  90 +
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!id)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+   *id = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+  0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+  param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES

[PATCH v1 2/3] drm/msm/disp/dpu1: add vsync and underrun irqs for INTF_5

2021-04-06 Thread Krishna Manikandan
INTF_5 is used by EDP panel in SC7280 target. Add vsync
and underrun irqs needed by INTF_5 to dpu irq map.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 72cdaf8..a37928b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -69,10 +69,12 @@
 #define DPU_INTR_INTF_1_UNDERRUN BIT(26)
 #define DPU_INTR_INTF_2_UNDERRUN BIT(28)
 #define DPU_INTR_INTF_3_UNDERRUN BIT(30)
+#define DPU_INTR_INTF_5_UNDERRUN BIT(22)
 #define DPU_INTR_INTF_0_VSYNC BIT(25)
 #define DPU_INTR_INTF_1_VSYNC BIT(27)
 #define DPU_INTR_INTF_2_VSYNC BIT(29)
 #define DPU_INTR_INTF_3_VSYNC BIT(31)
+#define DPU_INTR_INTF_5_VSYNC BIT(23)
 
 /**
  * Pingpong Secondary interrupt status bit definitions
@@ -308,7 +310,10 @@ static const struct dpu_irq_type dpu_irq_map[] = {
{ DPU_IRQ_TYPE_INTF_VSYNC, INTF_2, DPU_INTR_INTF_2_VSYNC, 0},
{ DPU_IRQ_TYPE_INTF_UNDER_RUN, INTF_3, DPU_INTR_INTF_3_UNDERRUN, 0},
{ DPU_IRQ_TYPE_INTF_VSYNC, INTF_3, DPU_INTR_INTF_3_VSYNC, 0},
-   /* irq_idx:32-63 */
+   /* irq_idx:32-33 */
+   { DPU_IRQ_TYPE_INTF_UNDER_RUN, INTF_5, DPU_INTR_INTF_5_UNDERRUN, 0},
+   { DPU_IRQ_TYPE_INTF_VSYNC, INTF_5, DPU_INTR_INTF_5_VSYNC, 0},
+   /* irq_idx:34-63 */
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
-- 
2.7.4



[PATCH v1 1/3] drm/msm/disp/dpu1: increase the range of interrupts in dpu_irq_map

2021-04-06 Thread Krishna Manikandan
Currently, each register in the dpu interrupt set is allowed
to have a maximum of 32 interrupts. With the introduction
of INTF_5_VSYNC and INTF_5_UNDERRUN irqs for EDP panel,
the total number of interrupts under INTR_STATUS register
in dpu_irq_map will exceed 32. Increase the range of each
interrupt register to 64 to handle this.

This patch has dependency on the below series:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=461193

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 755 +++---
 1 file changed, 661 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 5c521de..72cdaf8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -308,24 +308,56 @@ static const struct dpu_irq_type dpu_irq_map[] = {
{ DPU_IRQ_TYPE_INTF_VSYNC, INTF_2, DPU_INTR_INTF_2_VSYNC, 0},
{ DPU_IRQ_TYPE_INTF_UNDER_RUN, INTF_3, DPU_INTR_INTF_3_UNDERRUN, 0},
{ DPU_IRQ_TYPE_INTF_VSYNC, INTF_3, DPU_INTR_INTF_3_VSYNC, 0},
-
-   /* BEGIN MAP_RANGE: 32-64, INTR2 */
-   /* irq_idx: 32-35 */
+   /* irq_idx:32-63 */
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   { DPU_IRQ_TYPE_RESERVED, 0, 0, 0},
+   /* BEGIN MAP_RANGE: 64-95, INTR2 */
+   /* irq_idx: 64-67 */
{ DPU_IRQ_TYPE_PING_PONG_AUTO_REF, PINGPONG_S0,
DPU_INTR_PING_PONG_S0_AUTOREFRESH_DONE, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
-   /* irq_idx: 36-39 */
+   /* irq_idx: 68-71 */
{ DPU_IRQ_TYPE_PING_PONG_WR_PTR, PINGPONG_S0,
DPU_INTR_PING_PONG_S0_WR_PTR, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
-   /* irq_idx: 40 */
+   /* irq_idx: 72 */
{ DPU_IRQ_TYPE_PING_PONG_RD_PTR, PINGPONG_S0,
DPU_INTR_PING_PONG_S0_RD_PTR, 1},
-   /* irq_idx: 41-45 */
+   /* irq_idx: 73-77 */
{ DPU_IRQ_TYPE_CTL_START, CTL_0,
DPU_INTR_CTL_0_START, 1},
{ DPU_IRQ_TYPE_CTL_START, CTL_1,
@@ -336,10 +368,10 @@ static const struct dpu_irq_type dpu_irq_map[] = {
DPU_INTR_CTL_3_START, 1},
{ DPU_IRQ_TYPE_CTL_START, CTL_4,
DPU_INTR_CTL_4_START, 1},
-   /* irq_idx: 46-47 */
+   /* irq_idx: 78-79 */
{ DPU_IRQ_TYPE_CWB_OVERFLOW, CWB_2, DPU_INTR_CWB_2_OVERFLOW, 1},
{ DPU_IRQ_TYPE_CWB_OVERFLOW, CWB_3, DPU_INTR_CWB_3_OVERFLOW, 1},
-   /* irq_idx: 48-51 */
+   /* irq_idx: 80-83 */
{ DPU_IRQ_TYPE_PING_PONG_TEAR_CHECK, PINGPONG_0,
DPU_INTR_PING_PONG_0_TEAR_DETECTED, 1},
{ DPU_IRQ_TYPE_PING_PONG_TEAR_CHECK, PINGPONG_1,
@@ -348,13 +380,13 @@ static const struct dpu_irq_type dpu_irq_map[] = {
DPU_INTR_PING_PONG_2_TEAR_DETECTED, 1},
{ DPU_IRQ_TYPE_PING_PONG_TEAR_CHECK, PINGPONG_3,
DPU_INTR_PING_PONG_3_TEAR_DETECTED, 1},
-   /* irq_idx: 52-55 */
+   /* irq_idx: 84-87 */
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
{ DPU_IRQ_TYPE_PING_PONG_TEAR_CHECK, PINGPONG_S0,
DPU_INTR_PING_PONG_S0_TEAR_DETECTED, 1},
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 1},
-   /* irq_idx: 56-59 */
+   /* irq_idx: 88-91 */
{ DPU_IRQ_TYPE_PING_PONG_TE_CHECK, PINGPONG_0,
DPU_INTR_PING_PONG_0_TE_DETECTED, 1},
{ DPU_IRQ_TYPE_PING_PONG_TE_CHECK, PINGPONG_1

[PATCH v1 0/3] Add irq support to accommodate SC7280 target

2021-04-06 Thread Krishna Manikandan
The changes in this series adds all the irq related changes which are needed to
support EDP interface coming on sc7280 target.

Changes in this series:
- Currently each interrupt register has a range of 32 indexes only.
  But with the introduction of VSYNC and UNDERRUN irq for INTF_5,
  the number of irqs under INTR_STATUS will exceed this value.
  Increase the range of each interrupt register to 64 indexes
  to handle this.

- Changes are added to enable the vsync and underrun irqs for INTF_5 
which
  is required for edp panel.

- Some irqs which are applicable for sdm845 target are obsolete for 
sc7180
  and sc7280 targets. Support is added to skip all the obsolete irqs 
based on
  the target.

Krishna Manikandan (3):
  drm/msm/disp/dpu1: increase the range of interrupts in dpu_irq_map
  drm/msm/disp/dpu1: add vsync and underrun irqs for INTF_5
  drm/msm/disp/dpu1: add flags to indicate obsolete irqs

 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 773 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |   5 +-
 5 files changed, 692 insertions(+), 101 deletions(-)

-- 
2.7.4



[PATCH v1 3/3] drm/msm/disp/dpu1: add flags to indicate obsolete irqs

2021-04-06 Thread Krishna Manikandan
Some irqs which are applicable for sdm845 target are no
longer applicable for sc7180 and sc7280 targets. Add a
flag to indicate the irqs which are obsolete for a
particular target so that these irqs are skipped while
checking for matching irq lookup index.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|  9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 13 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  5 -
 5 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 84ea09d..cdec3fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -58,8 +58,8 @@ int dpu_core_irq_idx_lookup(struct dpu_kms *dpu_kms,
if (!dpu_kms->hw_intr || !dpu_kms->hw_intr->ops.irq_idx_lookup)
return -EINVAL;
 
-   return dpu_kms->hw_intr->ops.irq_idx_lookup(intr_type,
-   instance_idx);
+   return dpu_kms->hw_intr->ops.irq_idx_lookup(dpu_kms->hw_intr,
+   intr_type, instance_idx);
 }
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ec27e6a..d4c381f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -56,6 +56,13 @@
 
 #define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
 
+#define INTR_SC7180_MASK \
+   (BIT(DPU_IRQ_TYPE_PING_PONG_RD_PTR) |\
+   BIT(DPU_IRQ_TYPE_PING_PONG_WR_PTR) |\
+   BIT(DPU_IRQ_TYPE_PING_PONG_AUTO_REF) |\
+   BIT(DPU_IRQ_TYPE_PING_PONG_TEAR_CHECK) |\
+   BIT(DPU_IRQ_TYPE_PING_PONG_TE_CHECK))
+
 #define DEFAULT_PIXEL_RAM_SIZE (50 * 1024)
 #define DEFAULT_DPU_LINE_WIDTH 2048
 #define DEFAULT_DPU_OUTPUT_LINE_WIDTH  2560
@@ -1077,6 +1084,7 @@ static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.dma_cfg = sdm845_regdma,
.perf = sc7180_perf_data,
.mdss_irqs = 0x3f,
+   .obsolete_irq = INTR_SC7180_MASK,
};
 }
 
@@ -1166,6 +1174,7 @@ static void sc7280_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif = sdm845_vbif,
.perf = sc7280_perf_data,
.mdss_irqs = 0x1c07,
+   .obsolete_irq = INTR_SC7180_MASK,
};
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 0cf7210..4dfd8a2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -723,6 +723,7 @@ struct dpu_perf_cfg {
  * @cursor_formats Supported formats for cursor pipe
  * @vig_formatsSupported formats for vig pipe
  * @mdss_irqs: Bitmap with the irqs supported by the target
+ * @obsolete_irq:   Irq types that are obsolete for a particular target
  */
 struct dpu_mdss_cfg {
u32 hwversion;
@@ -769,6 +770,7 @@ struct dpu_mdss_cfg {
const struct dpu_format_extended *vig_formats;
 
unsigned long mdss_irqs;
+   unsigned long obsolete_irq;
 };
 
 struct dpu_mdss_hw_cfg_handler {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index a37928b..9c4d6b0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -1327,14 +1327,15 @@ static const struct dpu_irq_type dpu_irq_map[] = {
{ DPU_IRQ_TYPE_RESERVED, 0, 0, 12},
 };
 
-static int dpu_hw_intr_irqidx_lookup(enum dpu_intr_type intr_type,
-   u32 instance_idx)
+static int dpu_hw_intr_irqidx_lookup(struct dpu_hw_intr *intr,
+   enum dpu_intr_type intr_type, u32 instance_idx)
 {
int i;
 
for (i = 0; i < ARRAY_SIZE(dpu_irq_map); i++) {
if (intr_type == dpu_irq_map[i].intr_type &&
-   instance_idx == dpu_irq_map[i].instance_idx)
+   instance_idx == dpu_irq_map[i].instance_idx &&
+   !(intr->obsolete_irq & BIT(dpu_irq_map[i].intr_type)))
return i;
}
 
@@ -1386,7 +1387,9 @@ static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr 
*intr,
(irq_idx < end_idx) && irq_status;
irq_idx++)
if ((irq_status & dpu_irq_map[irq_idx].irq_mask) &&
-   (dpu_irq_map[irq_idx].reg_idx == reg_idx)) {
+   (dpu_irq_map[irq_idx].reg_idx == reg_idx) &&
+   !(intr-&

[PATCH v1 3/4] drm/msm/disp/dpu1: add support to program fetch active in ctl path

2021-04-05 Thread Krishna Manikandan
A new register called CTL_FETCH_ACTIVE is introduced in
SC7280 family which is used to inform the HW about
the pipes which are active in the current ctl path.
This change adds support to program this register
based on the active pipes in the current composition.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  7 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 27 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  3 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 9607a76..4d2f7d7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -130,7 +130,9 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
uint32_t stage_idx, lm_idx;
int zpos_cnt[DPU_STAGE_MAX + 1] = { 0 };
bool bg_alpha_enable = false;
+   DECLARE_BITMAP(fetch_active, SSPP_MAX);
 
+   memset(fetch_active, 0, sizeof(fetch_active));
drm_atomic_crtc_for_each_plane(plane, crtc) {
state = plane->state;
if (!state)
@@ -140,7 +142,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
fb = state->fb;
 
dpu_plane_get_ctl_flush(plane, ctl, _mask);
-
+   set_bit(dpu_plane_pipe(plane), fetch_active);
DPU_DEBUG("crtc %d stage:%d - plane %d sspp %d fb %d\n",
crtc->base.id,
pstate->stage,
@@ -180,6 +182,9 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
}
}
 
+   if (ctl->ops.set_active_pipes)
+   ctl->ops.set_active_pipes(ctl, fetch_active);
+
 _dpu_crtc_program_lm_output_roi(crtc);
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 8981cfa..3cf489b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -27,6 +27,7 @@
 #define   CTL_MERGE_3D_FLUSH0x100
 #define   CTL_INTF_FLUSH0x110
 #define   CTL_INTF_MASTER   0x134
+#define   CTL_FETCH_PIPE_ACTIVE 0x0FC
 
 #define CTL_MIXER_BORDER_OUTBIT(24)
 #define CTL_FLUSH_MASK_CTL  BIT(17)
@@ -34,6 +35,11 @@
 #define DPU_REG_RESET_TIMEOUT_US2000
 #define  MERGE_3D_IDX   23
 #define  INTF_IDX   31
+#define CTL_INVALID_BIT 0x
+
+static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 17, 18, 19,
+   CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
+   1, 2, 3, CTL_INVALID_BIT, CTL_INVALID_BIT};
 
 static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
const struct dpu_mdss_cfg *m,
@@ -344,6 +350,8 @@ static void dpu_hw_ctl_clear_all_blendstages(struct 
dpu_hw_ctl *ctx)
DPU_REG_WRITE(c, CTL_LAYER_EXT2(LM_0 + i), 0);
DPU_REG_WRITE(c, CTL_LAYER_EXT3(LM_0 + i), 0);
}
+
+   DPU_REG_WRITE(c, CTL_FETCH_PIPE_ACTIVE, 0);
 }
 
 static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl *ctx,
@@ -529,6 +537,23 @@ static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
DPU_REG_WRITE(c, CTL_TOP, intf_cfg);
 }
 
+static void dpu_hw_ctl_set_fetch_pipe_active(struct dpu_hw_ctl *ctx,
+   unsigned long *fetch_active)
+{
+   int i;
+   u32 val = 0;
+
+   if (fetch_active) {
+   for (i = 0; i < SSPP_MAX; i++) {
+   if (test_bit(i, fetch_active) &&
+   fetch_tbl[i] != CTL_INVALID_BIT)
+   val |= BIT(fetch_tbl[i]);
+   }
+   }
+
+   DPU_REG_WRITE(>hw, CTL_FETCH_PIPE_ACTIVE, val);
+}
+
 static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
unsigned long cap)
 {
@@ -558,6 +583,8 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->get_bitmask_sspp = dpu_hw_ctl_get_bitmask_sspp;
ops->get_bitmask_mixer = dpu_hw_ctl_get_bitmask_mixer;
ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp;
+   if (cap & BIT(DPU_CTL_FETCH_ACTIVE))
+   ops->set_active_pipes = dpu_hw_ctl_set_fetch_pipe_active;
 };
 
 static struct dpu_hw_blk_ops dpu_hw_ops;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index e93a42a..806c171 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -167,6 +167,9 @@ struct dpu_hw_ctl_ops {
 */
void (*setup_blendstage)(struct dpu_hw_ctl *ctx,
enum dpu_lm lm, struct dpu_hw_stage_cfg *cfg);
+
+   void (*set_active_pipes)(struct dpu_hw_ctl *ctx,
+   unsigned long *fetch_active);
 };
 
 /**
-- 
2.7.4



[PATCH v1 1/4] drm/msm/disp/dpu1: add support for display for SC7280 target

2021-04-05 Thread Krishna Manikandan
Add required display hw catalog changes for SC7280 target.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 176 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c   |   6 +-
 drivers/gpu/drm/msm/msm_drv.c  |   4 +-
 5 files changed, 177 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 189f353..ec27e6a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -43,6 +43,9 @@
 #define PINGPONG_SDM845_SPLIT_MASK \
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
 
+#define CTL_SC7280_MASK \
+   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE))
+
 #define MERGE_3D_SM8150_MASK (0)
 
 #define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
@@ -51,6 +54,8 @@
 
 #define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
 
+#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+
 #define DEFAULT_PIXEL_RAM_SIZE (50 * 1024)
 #define DEFAULT_DPU_LINE_WIDTH 2048
 #define DEFAULT_DPU_OUTPUT_LINE_WIDTH  2560
@@ -199,6 +204,18 @@ static const struct dpu_caps sm8250_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
 };
 
+static const struct dpu_caps sc7280_dpu_caps = {
+   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+   .max_mixer_blendstages = 0x7,
+   .qseed_type = DPU_SSPP_SCALER_QSEED4,
+   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2,
+   .ubwc_version = DPU_HW_UBWC_VER_30,
+   .has_dim_layer = true,
+   .has_idle_pc = true,
+   .max_linewidth = 2400,
+   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
 static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -268,6 +285,22 @@ static const struct dpu_mdp_cfg sm8250_mdp[] = {
},
 };
 
+static const struct dpu_mdp_cfg sc7280_mdp[] = {
+   {
+   .name = "top_0", .id = MDP_TOP,
+   .base = 0x0, .len = 0x2014,
+   .highest_bank_bit = 0x1,
+   .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+   .reg_off = 0x2AC, .bit_off = 0},
+   .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+   .reg_off = 0x2AC, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+   .reg_off = 0x2B4, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+   .reg_off = 0x2C4, .bit_off = 8},
+   },
+};
+
 /*
  * CTL sub blocks config
  */
@@ -350,6 +383,29 @@ static const struct dpu_ctl_cfg sm8150_ctl[] = {
},
 };
 
+static const struct dpu_ctl_cfg sc7280_ctl[] = {
+   {
+   .name = "ctl_0", .id = CTL_0,
+   .base = 0x15000, .len = 0x1E8,
+   .features = CTL_SC7280_MASK
+   },
+   {
+   .name = "ctl_1", .id = CTL_1,
+   .base = 0x16000, .len = 0x1E8,
+   .features = CTL_SC7280_MASK
+   },
+   {
+   .name = "ctl_2", .id = CTL_2,
+   .base = 0x17000, .len = 0x1E8,
+   .features = CTL_SC7280_MASK
+   },
+   {
+   .name = "ctl_3", .id = CTL_3,
+   .base = 0x18000, .len = 0x1E8,
+   .features = CTL_SC7280_MASK
+   },
+};
+
 /*
  * SSPP sub blocks config
  */
@@ -475,6 +531,17 @@ static const struct dpu_sspp_cfg sm8250_sspp[] = {
sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
 };
 
+static const struct dpu_sspp_cfg sc7280_sspp[] = {
+   SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SC7180_MASK,
+   sc7180_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+   SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000,  DMA_SDM845_MASK,
+   sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
+   SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  DMA_CURSOR_SDM845_MASK,
+   sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
+   SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000,  DMA_CURSOR_SDM845_MASK,
+   sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
+};
+
 /*
  * MIXER sub blocks config
  */
@@ -550,6 +617,15 @@ static const struct dpu_lm_cfg sm8150_lm[] = {
_lm_sblk, PINGPONG_5, LM_4, 0),
 };
 
+static const struct dpu_lm_cfg sc7280_lm[] = {
+   LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
+   _lm_sblk, PINGPONG_0, 0, 0),
+   LM_BLK("lm_2", LM_2, 0x46000, MIXER_SC7180_MASK,
+   _lm_s

[PATCH v1 2/4] drm/msm/disp/dpu1: add intf offsets for SC7280 target

2021-04-05 Thread Krishna Manikandan
Interface block offsets are different for SC7280 family
when compared to existing targets. These offset values
are used to access the interface irq registers. This
change adds proper interface offsets for SC7280 target.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 5c521de..c289b7e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -25,6 +25,9 @@
 #define MDP_AD4_INTR_EN_OFF0x41c
 #define MDP_AD4_INTR_CLEAR_OFF 0x424
 #define MDP_AD4_INTR_STATUS_OFF0x420
+#define MDP_INTF_0_OFF_REV_7xxx 0x34000
+#define MDP_INTF_1_OFF_REV_7xxx 0x35000
+#define MDP_INTF_5_OFF_REV_7xxx 0x39000
 
 /**
  * WB interrupt status bit definitions
@@ -242,7 +245,22 @@ static const struct dpu_intr_reg dpu_intr_set[] = {
MDP_AD4_1_OFF + MDP_AD4_INTR_CLEAR_OFF,
MDP_AD4_1_OFF + MDP_AD4_INTR_EN_OFF,
MDP_AD4_1_OFF + MDP_AD4_INTR_STATUS_OFF,
-   }
+   },
+   {
+   MDP_INTF_0_OFF_REV_7xxx+INTF_INTR_CLEAR,
+   MDP_INTF_0_OFF_REV_7xxx+INTF_INTR_EN,
+   MDP_INTF_0_OFF_REV_7xxx+INTF_INTR_STATUS
+   },
+   {
+   MDP_INTF_1_OFF_REV_7xxx+INTF_INTR_CLEAR,
+   MDP_INTF_1_OFF_REV_7xxx+INTF_INTR_EN,
+   MDP_INTF_1_OFF_REV_7xxx+INTF_INTR_STATUS
+   },
+   {
+   MDP_INTF_5_OFF_REV_7xxx+INTF_INTR_CLEAR,
+   MDP_INTF_5_OFF_REV_7xxx+INTF_INTR_EN,
+   MDP_INTF_5_OFF_REV_7xxx+INTF_INTR_STATUS
+   },
 };
 
 /*
-- 
2.7.4



[PATCH v1 4/4] drm/msm/disp/dpu1: enable DATA_HCTL_EN for sc7280 target

2021-04-05 Thread Krishna Manikandan
The reset value of INTF_CONFIG2 register is changed
for SC7280 family. Changes are added to program
this register correctly based on the target.

DATA_HCTL_EN in INTF_CONFIG2 register allows data
to be transferred at a different rate than video
timing. When this is set, the number of data per
line follows DISPLAY_DATA_HCTL register value.
This change adds support to program these
registers for sc7280 target.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 6f0f545..899f28d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -31,6 +31,8 @@
 #define INTF_TEST_CTL   0x054
 #define INTF_TP_COLOR0  0x058
 #define INTF_TP_COLOR1  0x05C
+#define INTF_CONFIG20x060
+#define INTF_DISPLAY_DATA_HCTL  0x064
 #define INTF_FRAME_LINE_COUNT_EN0x0A8
 #define INTF_FRAME_COUNT0x0AC
 #define   INTF_LINE_COUNT   0x0B0
@@ -93,7 +95,7 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
u32 active_hctl, display_hctl, hsync_ctl;
u32 polarity_ctl, den_polarity, hsync_polarity, vsync_polarity;
u32 panel_format;
-   u32 intf_cfg;
+   u32 intf_cfg, intf_cfg2 = 0, display_data_hctl = 0;
 
/* read interface_cfg */
intf_cfg = DPU_REG_READ(c, INTF_CONFIG);
@@ -178,6 +180,13 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
(COLOR_8BIT << 4) |
(0x21 << 8));
 
+   if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
+   intf_cfg2 |= BIT(4);
+   display_data_hctl = display_hctl;
+   DPU_REG_WRITE(c, INTF_CONFIG2, intf_cfg2);
+   DPU_REG_WRITE(c, INTF_DISPLAY_DATA_HCTL, display_data_hctl);
+   }
+
DPU_REG_WRITE(c, INTF_HSYNC_CTL, hsync_ctl);
DPU_REG_WRITE(c, INTF_VSYNC_PERIOD_F0, vsync_period * hsync_period);
DPU_REG_WRITE(c, INTF_VSYNC_PULSE_WIDTH_F0,
-- 
2.7.4



[PATCH v1 0/4] Add display support for SC7280 target

2021-04-05 Thread Krishna Manikandan
The changes in this series adds all the required support for display driver for
SC7280 target. In addition to the basic catalog changes, changes are added to
accommodate new registers for SC7280 target.

SC7280 target comes under next generation targets. The register differences in
SC7280 when compared to SC7180 are mentioned below:

- SC7280 uses UBWC3.0 and changes are added to program the ubwc static
  registers properly

- Pingpong dither block offset value has changed for SC7280 family. 
Separate
  sub block is defined for sc7280 pingpong block and changes are added 
to
  handle this.

- Interface offsets are different for SC7280 family. These offset 
values are
  used to access the interface irq registers. Changes are added to 
handle
  this based on the target.

- A new register called CTL_FETCH_PIPE_ACTIVE is introduced in SC7280 
family,
  which tells the HW about the active pipes in the CTL path. Changes are
  added to program this register based on the active pipes in the
  current composition.

- Changes are added to program INTF_CONFIG2 properly since the reset 
value
  of this register has changed in SC7280 family and we need to 
explicitly program
  it with correct values to avoid wrong interface configuration.

- INTF_5 is added to intf configuration to support EDP.

Krishna Manikandan (4):
  drm/msm/disp/dpu1: add support for display for SC7280 target
  drm/msm/disp/dpu1: add intf offsets for SC7280 target
  drm/msm/disp/dpu1: add support to program fetch active in ctl path
  drm/msm/disp/dpu1: enable DATA_HCTL_EN for sc7280 target

 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 176 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c|  27 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h|   3 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  20 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c   |  11 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  |   6 +-
 drivers/gpu/drm/msm/msm_drv.c |   4 +-
 10 files changed, 242 insertions(+), 24 deletions(-)

-- 
2.7.4



[PATCH v15 1/4] dt-bindings: msm: disp: add yaml schemas for DPU bindings

2021-04-05 Thread Krishna Manikandan
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for DPU device tree bindings.

Signed-off-by: Krishna Manikandan 

Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
- Added empty line between different properties (Sam Ravnborg)
- Replaced reference txt files with  their corresponding
  yaml files (Sam Ravnborg)
- Modified the file to use "|" only when it is
  necessary (Sam Ravnborg)

Changes in v3:
- Corrected the license used (Rob Herring)
- Added maxItems for properties (Rob Herring)
- Dropped generic descriptions (Rob Herring)
- Added ranges property (Rob Herring)
- Corrected the indendation (Rob Herring)
- Added additionalProperties (Rob Herring)
- Split dsi file into two, one for dsi controller
  and another one for dsi phy per target (Rob Herring)
- Corrected description for pinctrl-names (Rob Herring)
- Corrected the examples used in yaml file (Rob Herring)
- Delete dsi.txt and dpu.txt (Rob Herring)

Changes in v4:
- Move schema up by one level (Rob Herring)
- Add patternProperties for mdp node (Rob Herring)
- Corrected description of some properties (Rob Herring)

Changes in v5:
- Correct the indentation (Rob Herring)
- Remove unnecessary description from properties (Rob Herring)
- Correct the number of interconnect entries (Rob Herring)
- Add interconnect names for sc7180 (Rob Herring)
- Add description for ports (Rob Herring)
- Remove common properties (Rob Herring)
- Add unevalutatedProperties (Rob Herring)
- Reference existing dsi controller yaml in the common
  dsi controller file (Rob Herring)
- Correct the description of clock names to include only the
  clocks that are required (Rob Herring)
- Remove properties which are already covered under the common
  binding (Rob Herring)
- Add dsi phy supply nodes which are required for sc7180 and
  sdm845 targets (Rob Herring)
- Add type ref for syscon-sfpb (Rob Herring)

Changes in v6:
- Fixed errors during dt_binding_check (Rob Herring)
- Add maxItems for phys and phys-names (Rob Herring)
- Use unevaluatedProperties wherever required (Rob Herring)
- Removed interrupt controller from required properties for
  dsi controller (Rob Herring)
- Add constraints for dsi-phy reg-names based on the compatible
  phy version (Rob Herring)
- Add constraints for dsi-phy supply nodes based on the
  compatible phy version (Rob Herring)

Changes in v7:
- Add default value for qcom,mdss-mdp-transfer-time-us (Rob Herring)
- Modify the schema for data-lanes (Rob Herring)
- Split the phy schema into separate schemas based on
  the phy version (Rob Herring)

Changes in v8:
- Resolve merge conflicts with latest dsi.txt file
- Include dp yaml change also in the same series

Changes in v9:
- Combine target specific dsi controller yaml files
  to a single yaml file (Rob Herring)
- Combine target specific dsi phy yaml files into a
  single yaml file (Rob Herring)
- Use unevaluatedProperties and additionalProperties
  wherever required
- Remove duplicate properties from common yaml files

Changes in v10:
- Split the patch into separate patches for DPU, DSI and
  PHY (Stephen Boyd)
- Drop unnecessary fullstop (Stephen Boyd)
- Add newline whereever required (Stephen Boyd)
- Add description for clock used (Stephen Boyd)
- Modify the description for interconnect entries  (Stephen Boyd)
- Drop assigned clock entries as it a generic property (Stephen Boyd)
- Correct the definition for interrupts (Stephen Boyd)
- Drop clock names from required properties (Stephen Boyd)
- Drop labels for display nodes from example (Stephen Boyd)
- Drop flags from interrupts entries (Stephen Boyd)

Changes in v11:
- Drop maxItems for clocks (Stephen Boyd)

Changes in v12:
- Add description for register property (Stephen Boyd)
- Add maxItems for interrupts (Stephen Boyd)
- Add description for iommus property (Stephen Boyd)
- Add description for interconnects (Stephen Boyd)
- Change display node name to display_controller (Stephen Boyd)

Changes in v13:
- Add maxItems for reg property (Stephen Boyd)
- Add ranges property in example (Stephen Boyd)
- Modify description for iommus property (Stephen Boyd)
- Add Dp bindings for ports in the same patch (Stephen Boyd)
- Remove soc from examples and change address and size cells
  accordingly (Stephen Boyd)
- Add reference for ports

Changes in v14:
- Modify title for SC7180 and SDM845 yaml files (Stephen Boyd)
- Add required list for display-controller node (Stephen Boyd)
- Rename mdss node name to display-subsytem (Stephen Boyd)
---
 .../bindings/display/msm/dpu-sc7180.yaml  

[PATCH v15 3/4] dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings

2021-04-05 Thread Krishna Manikandan
Add YAML schema for the device tree bindings for DSI PHY.

Signed-off-by: Krishna Manikandan 

Changes in v1:
   - Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd)
   - Remove qcom,dsi-phy-regulator-ldo-mode (Stephen Boyd)
   - Add clock cells properly (Stephen Boyd)
   - Remove unnecessary decription from clock names (Stephen Boyd)
   - Add pin names for the supply entries for 10nm phy which is
 used in sc7180 and sdm845 (Stephen Boyd)
   - Remove unused header files from examples (Stephen Boyd)
   - Drop labels for display nodes and correct node name (Stephen Boyd)

Changes in v2:
   - Drop maxItems for clock (Stephen Boyd)
   - Add vdds supply pin information for sdm845 (Stephen Boyd)
   - Add examples for 14nm, 20nm and 28nm phy yaml files (Stephen Boyd)
   - Keep child nodes directly under soc node (Stephen Boyd)

Changes in v3:
   - Use a separate yaml file to describe the common properties
 for all the dsi phy versions (Stephen Boyd)
   - Remove soc from examples (Stephen Boyd)
   - Add description for register property

Changes in v4:
   - Modify the title for all the phy versions (Stephen Boyd)
   - Drop description for all the phy versions (Stephen Boyd)
   - Modify the description for register property (Stephen Boyd)

Changes in v5:
   - Remove unused properties from common dsi phy file
   - Add clock-cells and phy-cells to required property
 list (Stephen Boyd)
---
 .../bindings/display/msm/dsi-phy-10nm.yaml | 68 +
 .../bindings/display/msm/dsi-phy-14nm.yaml | 66 
 .../bindings/display/msm/dsi-phy-20nm.yaml | 71 ++
 .../bindings/display/msm/dsi-phy-28nm.yaml | 68 +
 .../bindings/display/msm/dsi-phy-common.yaml   | 40 
 5 files changed, 313 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
new file mode 100644
index 000..4a26bef
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DSI 10nm PHY
+
+maintainers:
+  - Krishna Manikandan 
+
+allOf:
+  - $ref: dsi-phy-common.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - const: qcom,dsi-phy-10nm
+  - const: qcom,dsi-phy-10nm-8998
+
+  reg:
+items:
+  - description: dsi phy register set
+  - description: dsi phy lane register set
+  - description: dsi pll register set
+
+  reg-names:
+items:
+  - const: dsi_phy
+  - const: dsi_phy_lane
+  - const: dsi_pll
+
+  vdds-supply:
+description: |
+  Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and
+  connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - vdds-supply
+
+unevaluatedProperties: false
+
+examples:
+  - |
+ #include 
+ #include 
+
+ dsi-phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+   <0x0ae94600 0x280>,
+   <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ vdds-supply = <_mipi_dsi0_pll>;
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+  < RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
new file mode 100644
index 000..72a00cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DSI 14nm PHY
+
+maintainers:
+  - Krishna Manikandan 
+
+allOf:
+  - $ref: dsi-phy-common.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - const: qcom,dsi-phy-14nm
+  - const: qcom,dsi-phy-14nm-660
+
+  reg:
+items:
+  - description: dsi phy register s

[PATCH v15 2/4] dt-bindings: msm: dsi: add yaml schemas for DSI bindings

2021-04-05 Thread Krishna Manikandan
Add YAML schema for the device tree bindings for DSI

Signed-off-by: Krishna Manikandan 

Changes in v1:
- Separate dsi controller bindings to a separate patch (Stephen Boyd)
- Merge dsi-common-controller.yaml and dsi-controller-main.yaml to
  a single file (Stephen Boyd)
- Drop supply entries and definitions from properties (Stephen Boyd)
- Modify phy-names property for dsi controller (Stephen Boyd)
- Remove boolean from description (Stephen Boyd)
- Drop pinctrl properties as they are standard entries (Stephen Boyd)
- Modify the description for ports property and keep the reference
  to the generic binding where this is defined (Stephen Boyd)
- Add description to clock names (Stephen Boyd)
- Correct the indendation (Stephen Boyd)
- Drop the label for display dt nodes and correct the node
  name (Stephen Boyd)

Changes in v2:
- Drop maxItems for clock (Stephen Boyd)
- Drop qcom,mdss-mdp-transfer-time-us as it is not used in upstream
  dt file (Stephen Boyd)
- Keep child node directly under soc node (Stephen Boyd)
- Drop qcom,sync-dual-dsi as it is not used in upstream dt

Changes in v3:
- Add description for register property (Stephen Boyd)

Changes in v4:
- Add maxItems for phys property (Stephen Boyd)
- Add maxItems for reg property (Stephen Boyd)
- Add reference for data-lanes property (Stephen Boyd)
- Remove soc from example (Stephen Boyd)

Changes in v5:
- Modify title and description (Stephen Boyd)
- Add required properties for ports node (Stephen Boyd)
- Add data-lanes in the example (Stephen Boyd)
- Drop qcom,master-dsi property (Stephen Boyd)

Changes in v6:
- Add required properties for port@0, port@1 and corresponding
  endpoints (Stephen Boyd)
- Add address-cells and size-cells for ports (Stephen Boyd)
- Use additionalProperties instead of unevaluatedProperties (Stephen Boyd)
---
 .../bindings/display/msm/dsi-controller-main.yaml  | 213 ++
 .../devicetree/bindings/display/msm/dsi.txt| 249 -
 2 files changed, 213 insertions(+), 249 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt

diff --git 
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
new file mode 100644
index 000..7858524
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DSI controller
+
+maintainers:
+  - Krishna Manikandan 
+
+allOf:
+  - $ref: "../dsi-controller.yaml#"
+
+properties:
+  compatible:
+items:
+  - const: qcom,mdss-dsi-ctrl
+
+  reg:
+maxItems: 1
+
+  reg-names:
+const: dsi_ctrl
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Display byte clock
+  - description: Display byte interface clock
+  - description: Display pixel clock
+  - description: Display escape clock
+  - description: Display AHB clock
+  - description: Display AXI clock
+
+  clock-names:
+items:
+  - const: byte
+  - const: byte_intf
+  - const: pixel
+  - const: core
+  - const: iface
+  - const: bus
+
+  phys:
+maxItems: 1
+
+  phy-names:
+const: dsi
+
+  "#address-cells": true
+
+  "#size-cells": true
+
+  syscon-sfpb:
+description: A phandle to mmss_sfpb syscon node (only for DSIv2).
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+  qcom,dual-dsi-mode:
+type: boolean
+description: |
+  Indicates if the DSI controller is driving a panel which needs
+  2 DSI links.
+
+  ports:
+$ref: "/schemas/graph.yaml#/properties/port"
+type: object
+description: |
+  Contains DSI controller input and output ports as children, each
+  containing one endpoint subnode.
+
+properties:
+  port@0:
+type: object
+description: |
+  Input endpoints of the controller.
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+properties:
+  remote-endpoint:
+description: |
+  For port@1, set to phandle of the connected panel/bridge's
+  input endpoint. For port@0, set to the MDP interface output.
+
+  data-lanes:
+$ref: "/schemas/media/video-interfaces.yaml#"
+description: |
+  This describes how the physical DSI data lanes are mapped
+  to t

[PATCH v15 4/4] dt-bindings: msm/dp: Add bindings of MSM DisplayPort controller

2021-04-05 Thread Krishna Manikandan
Add bindings for Snapdragon DisplayPort controller driver.

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
Signed-off-by: Tanmay Shah 
Signed-off-by: Kuogee Hsieh 
Signed-off-by: Krishna Manikandan 

Changes in V2:
-Provide details about sel-gpio

Changes in V4:
-Provide details about max dp lanes
-Change the commit text

Changes in V5:
-moved dp.txt to yaml file

Changes in v6:
- Squash all AUX LUT properties into one pattern Property
- Make aux-cfg[0-9]-settings properties optional
- Remove PLL/PHY bindings from DP controller dts
- Add DP clocks description
- Remove _clk suffix from clock names
- Rename pixel clock to stream_pixel
- Remove redundant bindings (GPIO, PHY, HDCP clock, etc..)
- Fix indentation
- Add Display Port as interface of DPU in DPU bindings
  and add port mapping accordingly.

Chages in v7:
- Add dp-controller.yaml file common between multiple SOC
- Rename dp-sc7180.yaml to dp-controller-sc7180.yaml
- change compatible string and add SOC name to it.
- Remove Root clock generator for pixel clock
- Add assigned-clocks and assigned-clock-parents bindings
- Remove redundant properties, descriptions and blank lines
- Add DP port in DPU bindings
- Update depends-on tag in commit message and rebase change accordingly

Changes in v8:
- Add MDSS AHB clock in bindings

Changes in v9:
- Remove redundant reg-name property
- Change assigned-clocks and assigned-clocks-parents counts to 2
- Use IRQ flags in example dts

Changes in v10:
- Change title of this patch as it does not contain PLL bindings anymore
- Remove redundant properties
- Remove use of IRQ flag
- Fix ports property

Changes in v11:
- add ports required of both #address-cells and  #size-cells
- add required operating-points-v2
- add required #sound-dai-cells
- add required power-domains
- update maintainer list

Changes in v12:
- remove soc node from examples (Stephen Boyd)
- split dpu-sc7180.yaml changes to separate patch (Stephen Boyd)

Changes in v13:
- add assigned-clocks
- add assigned-clock-parents
---
 .../bindings/display/msm/dp-controller.yaml| 162 +
 1 file changed, 162 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dp-controller.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
new file mode 100644
index 000..3a02c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dp-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MSM Display Port Controller
+
+maintainers:
+  - Kuogee Hsieh 
+
+description: |
+  Device tree bindings for DisplayPort host controller for MSM targets
+  that are compatible with VESA DisplayPort interface specification.
+
+properties:
+  compatible:
+enum:
+  - qcom,sc7180-dp
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: AHB clock to enable register access
+  - description: Display Port AUX clock
+  - description: Display Port Link clock
+  - description: Link interface clock between DP and PHY
+  - description: Display Port Pixel clock
+
+  clock-names:
+items:
+  - const: core_iface
+  - const: core_aux
+  - const: ctrl_link
+  - const: ctrl_link_iface
+  - const: stream_pixel
+
+  assigned-clocks:
+items:
+  - description: link clock source
+  - description: pixel clock source
+
+  assigned-clock-parents:
+items:
+  - description: phy 0 parent
+  - description: phy 1 parent
+
+  phys:
+maxItems: 1
+
+  phy-names:
+items:
+  - const: dp
+
+  operating-points-v2:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+  "#sound-dai-cells":
+const: 0
+
+  ports:
+type: object
+description: |
+  A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description: Input endpoint of the controller
+
+  port@1:
+type: object
+description: Output endpoint of the controller
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
+
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - phys
+  - phy-names
+  - "#sound-dai-cells"
+  - power-domains
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+
+displayport-controller@ae9 {
+compatible = "qcom,sc7180-dp";
+reg = <0xae9 0x1400>;

RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-25 Thread Sai Krishna Potthuri
Hi Linus,

> -Original Message-
> From: Linus Walleij 
> Sent: Thursday, March 25, 2021 2:27 PM
> To: Sai Krishna Potthuri 
> Cc: Andy Shevchenko ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux-arm Mailing List  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; devicetree ; open
> list:GPIO SUBSYSTEM ; git ;
> saikrishna12...@gmail.com
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Mon, Mar 22, 2021 at 4:25 PM Sai Krishna Potthuri
>  wrote:
> > [Andy]
> 
> > > > > > +   PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1, };
> > > > >
> > > > > I'm lost here. What is IO standard exactly? Why it can't be in
> > > > > generic headers?
> > > > It represents LVCMOS 3.3 volts/ LVCMOS 1.8 volts.
> > > > Since this is specific to Xilinx ZynqMP platform, considered to be
> > > > added in the driver file.
> > >
> > > So, why can't we create a couple of bits to represent this voltages
> > > in the generic header and gain usability for others as well?
> >
> > I see some drivers are maintaining the configuration list in the
> > driver file, if the configuration is specific to the driver.
> >
> > We can move this to generic header if it is used by others as well.
> > Ok, will wait for Linus to comment.
> > >
> > > Linus?
> 
> While it is fine to add custom pin config options to pin controllers for
> hopelessly idiomatic stuff, this does look like it should be using
> PIN_CONFIG_POWER_SOURCE with the voltage rail as parameter, see
> include/linux/pinctrl/pinconf-generic.h
Thanks.
I will update the driver to use 'power-source' option.

Regards
Sai Krishna
> 
> If you're not using that then tell us why.
> 
> Yours,
> Linus Walleij


RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-23 Thread Sai Krishna Potthuri
Hi Andy Shevchenko,

> -Original Message-
> From: Andy Shevchenko 
> Sent: Monday, March 22, 2021 10:47 PM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux-arm Mailing List  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; devicetree ; open
> list:GPIO SUBSYSTEM ; git ;
> saikrishna12...@gmail.com
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Mon, Mar 22, 2021 at 5:25 PM Sai Krishna Potthuri
>  wrote:
> > > From: Andy Shevchenko 
> > > Sent: Friday, March 19, 2021 3:53 PM On Thu, Mar 18, 2021 at 4:42 PM
> > > Sai Krishna Potthuri 
> > > wrote:
> > > > > From: Andy Shevchenko 
> > > > > Sent: Wednesday, March 17, 2021 6:26 PM On Wed, Mar 17, 2021 at
> > > > > 10:27 AM Sai Krishna Potthuri
> > > > >  wrote:
> 
> ...
> 
> > > > #include 
> > >
> > > Looking into other drivers with similar includes, shouldn't it go
> > > first in the file before any other linux/* asm/* etc?
> > I see some drivers are including this header before linux/* and some
> > are using after linux/*.
> 
> The rule of thumb is that: more generic headers are going first.
> 
> I consider dt/* ones are more generic than linux/* ones because they are
> covering more than just the Linux kernel.
Ok, I will reorder accordingly.
> 
> ...
> 
> > > > > I'm lost here. What is IO standard exactly? Why it can't be in
> > > > > generic headers?
> > > > It represents LVCMOS 3.3 volts/ LVCMOS 1.8 volts.
> > > > Since this is specific to Xilinx ZynqMP platform, considered to be
> > > > added in the driver file.
> > >
> > > So, why can't we create a couple of bits to represent this voltages
> > > in the generic header and gain usability for others as well?
> > I see some drivers are maintaining the configuration list in the
> > driver file, if the configuration is specific to the driver.
> 
> Yes, my point is that this case doesn't sound too specific to the driver. Many
> pin control buffers (in hardware way of speaking) have properties to be
> different voltage tolerant / produce.
Ok, you want me to proceed with this change or shall we wait for
Linus to comment?
> 
> > We can move this to generic header if it is used by others as well.
> > Ok, will wait for Linus to comment.
> > >
> > > Linus?
> 
> ...
> 
> > > > > > +   ret = zynqmp_pm_pinctrl_request(pin);
> > > > > > +   if (ret) {
> > > > > > +   dev_err(pctldev->dev, "request failed for pin
> > > > > > + %u\n", pin);
> > > > >
> > > > > > +   return -EIO;
> > > > >
> > > > > Why shadowing error code?
> > >
> > > So, any comments on the initial Q?
> > Xilinx low level secure firmware error codes are different from Linux error
> codes.
> > Secure firmware maintains list of error codes (positive values other than
> zero).
> > Hence we return -EIO, if the return value from firmware is non-zero.
> 
> Why the zynqmp_pm_pinctrl_request() can't return codes in Linux error
> code space?
I cross checked with the Xilinx firmware team, firmware driver is now returning
Linux error codes in the latest kernel but while developing the driver it was a
different approach. I will update the driver to simply return the values from
firmware calls.
> 
> > > >>  Since it's the only possible error, why is it not
> > > > > reflected in the kernel doc?
> > > > I will update the kernel doc with the error value for such cases.
> > > > >
> > > > > > +   }
> 
> --
> With Best Regards,
> Andy Shevchenko


RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-22 Thread Sai Krishna Potthuri
Hi Andy Shevchenko,

> -Original Message-
> From: Andy Shevchenko 
> Sent: Friday, March 19, 2021 3:53 PM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux-arm Mailing List  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; devicetree ; open
> list:GPIO SUBSYSTEM ; git ;
> saikrishna12...@gmail.com
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Thu, Mar 18, 2021 at 4:42 PM Sai Krishna Potthuri 
> wrote:
> > > From: Andy Shevchenko 
> > > Sent: Wednesday, March 17, 2021 6:26 PM On Wed, Mar 17, 2021 at
> > > 10:27 AM Sai Krishna Potthuri
> > >  wrote:
> 
> ...
> 
> > > > +config PINCTRL_ZYNQMP
> > > > +   bool "Pinctrl driver for Xilinx ZynqMP"
> > >
> > > Why not module?
> > As most of the Xilinx drivers depending on the pin controller driver
> > for configuring the MIO pins, we are not supporting to build this
> > driver as a module.
> 
> OK.
> 
> > > > +   depends on ARCH_ZYNQMP
> > > > +   select PINMUX
> > > > +   select GENERIC_PINCONF
> 
> ...
> 
> > > > +#include 
> > > > +#include 
> > >
> > > > +#include  #include
> > > > +
> > >
> > > Can you move this group of headers after linux/* ?
> > >
> > > > +#include 
> > >
> > > Can it be moved outside of these headers
> > >
> > > > +#include  #include
> > > > +
> > >
> > > Ordering (for all groups of headers)?
> > Ok, I will order the headers in the below order #include 
> > #include 
> 
> + blank line
> 
> > #include 
> 
> + blank line
Ok, I will add above two blank lines.
> 
> > #include 
> 
> Looking into other drivers with similar includes, shouldn't it go first in 
> the file
> before any other linux/* asm/* etc?
I see some drivers are including this header before linux/* and some are using
after linux/*.
> 
> > > > +#include "core.h"
> > > > +#include "pinctrl-utils.h"
> 
> ...
> 
> > > > +   PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1, };
> > >
> > > I'm lost here. What is IO standard exactly? Why it can't be in
> > > generic headers?
> > It represents LVCMOS 3.3 volts/ LVCMOS 1.8 volts.
> > Since this is specific to Xilinx ZynqMP platform, considered to be
> > added in the driver file.
> 
> So, why can't we create a couple of bits to represent this voltages in the
> generic header and gain usability for others as well?
I see some drivers are maintaining the configuration list in the driver file, if
the configuration is specific to the driver.
We can move this to generic header if it is used by others as well.
Ok, will wait for Linus to comment.
> 
> Linus?
> 
> ...
> 
> > > > +   ret = zynqmp_pm_pinctrl_request(pin);
> > > > +   if (ret) {
> > > > +   dev_err(pctldev->dev, "request failed for pin
> > > > + %u\n", pin);
> > >
> > > > +   return -EIO;
> > >
> > > Why shadowing error code?
> 
> So, any comments on the initial Q?
Xilinx low level secure firmware error codes are different from Linux error 
codes.
Secure firmware maintains list of error codes (positive values other than zero).
Hence we return -EIO, if the return value from firmware is non-zero. 
> 
> >>  Since it's the only possible error, why is it not
> > > reflected in the kernel doc?
> > I will update the kernel doc with the error value for such cases.
> > >
> > > > +   }
> 
> ...
> 
> > > > +   default:
> > > > +   /* Invalid drive strength */
> > > > +   dev_warn(pctldev->dev,
> > > > +"Invalid drive strength for pin %d\n",
> > > > +pin);
> > > > +   return -EINVAL;
> > > > +   }
> > > > +   break;
> > > > +   default:
> > > > +   ret = -EOPNOTSUPP;
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   param = pinconf_to_config_param(*config);
> > > > +   *config = pinconf_to_config_packed(param, arg);
> > > > +
> > > > +   return ret;
>

RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-18 Thread Sai Krishna Potthuri
Hi Andy Shevchenko,

Thanks for the review.

> -Original Message-
> From: Andy Shevchenko 
> Sent: Wednesday, March 17, 2021 6:26 PM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux-arm Mailing List  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; devicetree ; open
> list:GPIO SUBSYSTEM ; git ;
> saikrishna12...@gmail.com
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Wed, Mar 17, 2021 at 10:27 AM Sai Krishna Potthuri
>  wrote:
> >
> > Adding pinctrl driver for Xilinx ZynqMP platform.
> > This driver queries pin information from firmware and registers pin
> > control accordingly.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  drivers/pinctrl/Kconfig  |   13 +
> >  drivers/pinctrl/Makefile |1 +
> >  drivers/pinctrl/pinctrl-zynqmp.c | 1030
> > ++
> >  3 files changed, 1044 insertions(+)
> >  create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
> >
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index
> > 815095326e2d..25d3c7208975 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
> > help
> >   This selects the pinctrl driver for Xilinx Zynq.
> >
> > +config PINCTRL_ZYNQMP
> > +   bool "Pinctrl driver for Xilinx ZynqMP"
> 
> Why not module?
As most of the Xilinx drivers depending on the pin controller driver for
configuring the MIO pins, we are not supporting to build this driver as
a module. 
> 
> > +   depends on ARCH_ZYNQMP
> > +   select PINMUX
> > +   select GENERIC_PINCONF
> > +   help
> > + This selects the pinctrl driver for Xilinx ZynqMP platform.
> > + This driver will query the pin information from the firmware
> > + and allow configuring the pins.
> > + Configuration can include the mux function to select on those
> > + pin(s)/group(s), and various pin configuration parameters
> > + such as pull-up, slew rate, etc.
> > +
> >  config PINCTRL_INGENIC
> > bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
> > default MACH_INGENIC
> > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index
> > f53933b2ff02..7e058739f0d5 100644
> > --- a/drivers/pinctrl/Makefile
> > +++ b/drivers/pinctrl/Makefile
> > @@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
> >  obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
> >  obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
> >  obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
> > +obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
> >  obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
> >  obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
> >  obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
> > diff --git a/drivers/pinctrl/pinctrl-zynqmp.c
> > b/drivers/pinctrl/pinctrl-zynqmp.c
> > new file mode 100644
> > index ..63edde400e85
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-zynqmp.c
> > @@ -0,0 +1,1030 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * ZynqMP pin controller
> > + *
> > + *  Copyright (C) 2020 Xilinx, Inc.
> > + *
> > + *  Sai Krishna Potthuri 
> > + *  Rajan Vaja 
> > + */
> > +
> > +#include 
> > +#include 
> 
> > +#include 
> > +#include 
> 
> Can you move this group of headers after linux/* ?
> 
> > +#include 
> 
> Can it be moved outside of these headers
> 
> > +#include 
> > +#include 
> 
> Ordering (for all groups of headers)?
Ok, I will order the headers in the below order
#include 
#include 
#include 
#include 
> 
> > +#include "core.h"
> > +#include "pinctrl-utils.h"
> > +
> > +#define ZYNQMP_PIN_PREFIX  "MIO"
> > +#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
> > +#define MAX_FUNC_NAME_LEN  16
> > +#define MAX_GROUP_PIN  50
> > +#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
> > +#define NUM_GROUPS_PER_RESP6
> > +
> > +#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
> > +#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
> > +#define NA_GROUP   -1
> > +#define RESERVED_GROUP  

RE: [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)

2021-03-17 Thread Krishna Reddy
Tested-by: Krishna Reddy 

Validated nested translations with NVMe PCI device assigned to Guest VM. 
Tested with both v12 and v13 of Jean-Philippe's patches as base.

> This is based on Jean-Philippe's
> [PATCH v12 00/10] iommu: I/O page faults for SMMUv3
> https://lore.kernel.org/linux-arm-kernel/YBfij71tyYvh8LhB@myrica/T/

With Jean-Philippe's V13, Patch 12 of this series has a conflict that had to be 
resolved manually.

-KR




RE: [PATCH v12 00/13] SMMUv3 Nested Stage Setup (VFIO part)

2021-03-17 Thread Krishna Reddy
Tested-by: Krishna Reddy 

Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM and is 
functional.

This patch series resolved the mismatch(seen with v11 patches) for 
VFIO_IOMMU_SET_PASID_TABLE and VFIO_IOMMU_CACHE_INVALIDATE Ioctls between linux 
and QEMU patch series "vSMMUv3/pSMMUv3 2 stage VFIO integration" 
(v5.2.0-2stage-rfcv8). 

-KR



[PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-17 Thread Sai Krishna Potthuri
Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/pinctrl/Kconfig  |   13 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 1030 ++
 3 files changed, 1044 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+   bool "Pinctrl driver for Xilinx ZynqMP"
+   depends on ARCH_ZYNQMP
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..63edde400e85
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1030 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ *  Copyright (C) 2020 Xilinx, Inc.
+ *
+ *  Sai Krishna Potthuri 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX  "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN  16
+#define MAX_GROUP_PIN  50
+#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP   -1
+#define RESERVED_GROUP -2
+
+#define DRIVE_STRENGTH_2MA 2
+#define DRIVE_STRENGTH_4MA 4
+#define DRIVE_STRENGTH_8MA 8
+#define DRIVE_STRENGTH_12MA12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:  Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups:   Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+   char name[MAX_FUNC_NAME_LEN];
+   const char * const *groups;
+   unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups:   Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+   struct pinctrl_dev *pctrl;
+   const struct zynqmp_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynqmp_pmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:  Group name
+ * @pins:  Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+   const char *name;
+   unsigned int pins[MAX_GROUP_PIN];
+   unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ */
+enum zynqmp_pin_config_param {
+   PIN_CONFIG

[PATCH v4 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver

2021-03-17 Thread Sai Krishna Potthuri
Adding documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri 
Reviewed-by: Rob Herring 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 339 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 2 files changed, 358 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index ..0c1149706f8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,339 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri 
+  - Rajan Vaja 
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number 
of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin 
configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux 
and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+type: object
+patternProperties:
+  '^mux':
+type: object
+description:
+  Pinctrl node's client devices use subnodes for pin muxes,
+  which in turn use below standard properties.
+$ref: pinmux-node.yaml#
+
+properties:
+  groups:
+description:
+  List of groups to select (either this or "pins" must be
+  specified), available groups for this subnode.
+items:
+  enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+ sdio1_3_grp, sdio

[PATCH v4 1/3] firmware: xilinx: Add pinctrl support

2021-03-17 Thread Sai Krishna Potthuri
Adding pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri 
Acked-by: Michal Simek 
---
 drivers/firmware/xilinx/zynqmp.c | 114 +++
 include/linux/firmware/xlnx-zynqmp.h |  90 +
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!id)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+   *id = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+  0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+  param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES

[PATCH v4 0/3] Add ZynqMP pinctrl driver

2021-03-17 Thread Sai Krishna Potthuri
Add support for Xilinx ZynqMP pinctrl driver and also update the Xilinx
firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and allow
configuring the pins as per the request.

changes in v4:
- Added comment for ignoring the return value for GET_FUNCTION_NAME qid.
- Updated the zynqmp_pinctrl_get_function_name() API prototype to void
as it always returns zero.

changes in v3:
- Fixed binding doc comments from Rob.
- Used 'maxItems' for groups and pins properties.
- Updated commit subject and description to have present tense statements.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

Sai Krishna Potthuri (3):
  firmware: xilinx: Add pinctrl support
  dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver
  pinctrl: Add Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml |  339 ++
 drivers/firmware/xilinx/zynqmp.c  |  114 ++
 drivers/pinctrl/Kconfig   |   13 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-zynqmp.c  | 1030 +
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |   19 +
 include/linux/firmware/xlnx-zynqmp.h  |   90 ++
 7 files changed, 1606 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



RE: [PATCH v13 00/15] SMMUv3 Nested Stage Setup (IOMMU part)

2021-03-16 Thread Krishna Reddy
> Hi Krishna,
> On 3/15/21 7:04 PM, Krishna Reddy wrote:
> > Tested-by: Krishna Reddy 
> >
> >> 1) pass the guest stage 1 configuration
> >
> > Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM
> along with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and
> QEMU patch series "vSMMUv3/pSMMUv3 2 stage VFIO integration" from
> v5.2.0-2stage-rfcv8.
> > NVMe PCIe device is functional with 2-stage translations and no issues
> observed.
> Thank you very much for your testing efforts. For your info, there are more
> recent kernel series:
> [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part) (Feb 23) [PATCH
> v12 00/13] SMMUv3 Nested Stage Setup (VFIO part) (Feb 23)
> 
> working along with QEMU RFC
> [RFC v8 00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration (Feb 25)
> 
> If you have cycles to test with those, this would be higly appreciated.
 
Thanks Eric for the latest patches. Will validate and update. 
Feel free to reach out me for validating future patch sets as necessary.

-KR


RE: [PATCH v11 00/13] SMMUv3 Nested Stage Setup (VFIO part)

2021-03-15 Thread Krishna Reddy
Tested-by: Krishna Reddy 

> 1) pass the guest stage 1 configuration
> 3) invalidate stage 1 related caches

Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along 
with patch series "v13 SMMUv3 Nested Stage Setup (IOMMU part)" and QEMU patch 
series "vSMMUv3/pSMMUv3 2 stage VFIO integration" from v5.2.0-2stage-rfcv8. 
NVMe PCIe device is functional with 2-stage translations and no issues observed.

-KR



RE: [PATCH v13 00/15] SMMUv3 Nested Stage Setup (IOMMU part)

2021-03-15 Thread Krishna Reddy
Tested-by: Krishna Reddy 

> 1) pass the guest stage 1 configuration

Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along 
with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch 
series "vSMMUv3/pSMMUv3 2 stage VFIO integration" from v5.2.0-2stage-rfcv8. 
NVMe PCIe device is functional with 2-stage translations and no issues observed.

-KR



RE: [PATCH v3 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-03-01 Thread Sai Krishna Potthuri
Hi Nobuhiro,

> -Original Message-
> From: Nobuhiro Iwamatsu 
> Sent: Sunday, February 28, 2021 6:19 AM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux ARM  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; devicet...@vger.kernel.org; linux-
> g...@vger.kernel.org; git ; saikrishna12...@gmail.com
> Subject: Re: [PATCH v3 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> Hi,
> 
> 2021年2月12日(金) 21:10 Sai Krishna Potthuri
> :
> >
> > Adding pinctrl driver for Xilinx ZynqMP platform.
> > This driver queries pin information from firmware and registers pin
> > control accordingly.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  drivers/pinctrl/Kconfig  |   13 +
> >  drivers/pinctrl/Makefile |1 +
> >  drivers/pinctrl/pinctrl-zynqmp.c | 1031
> > ++
> >  3 files changed, 1045 insertions(+)
> >  create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
> >
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index
> > 815095326e2d..25d3c7208975 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
> > help
> >   This selects the pinctrl driver for Xilinx Zynq.
> >
> > +config PINCTRL_ZYNQMP
> > +   bool "Pinctrl driver for Xilinx ZynqMP"
> > +   depends on ARCH_ZYNQMP
> > +   select PINMUX
> > +   select GENERIC_PINCONF
> > +   help
> > + This selects the pinctrl driver for Xilinx ZynqMP platform.
> > + This driver will query the pin information from the firmware
> > + and allow configuring the pins.
> > + Configuration can include the mux function to select on those
> > + pin(s)/group(s), and various pin configuration parameters
> > + such as pull-up, slew rate, etc.
> > +
> >  config PINCTRL_INGENIC
> > bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
> > default MACH_INGENIC
> > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index
> > f53933b2ff02..7e058739f0d5 100644
> > --- a/drivers/pinctrl/Makefile
> > +++ b/drivers/pinctrl/Makefile
> > @@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
> >  obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
> >  obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
> >  obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
> > +obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
> >  obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
> >  obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
> >  obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
> > diff --git a/drivers/pinctrl/pinctrl-zynqmp.c
> > b/drivers/pinctrl/pinctrl-zynqmp.c
> > new file mode 100644
> > index ..ec0a5d0e22d5
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-zynqmp.c
> > @@ -0,0 +1,1031 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * ZynqMP pin controller
> > + *
> > + *  Copyright (C) 2020 Xilinx, Inc.
> > + *
> > + *  Sai Krishna Potthuri 
> > + *  Rajan Vaja 
> > + */
> 
> 
> 
> > +/**
> > + * zynqmp_pinctrl_get_function_name() - get function name
> > + * @fid:   Function ID.
> > + * @name:  Function name
> > + *
> > + * Call firmware API to get name of given function.
> > + *
> > + * Return: 0 on success else error code.
> > + */
> > +static int zynqmp_pinctrl_get_function_name(u32 fid, char *name) {
> > +   struct zynqmp_pm_query_data qdata = {0};
> > +   u32 ret_payload[PAYLOAD_ARG_CNT];
> > +
> > +   qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_NAME;
> > +   qdata.arg1 = fid;
> > +
> > +   zynqmp_pm_query_data(qdata, ret_payload);
> 
> Please check the return value here as well as other functions.
> 
> I know that when we used zynqmp_pm_query_data with
> PM_QID_PINCTRL_GET_FUNCTION_NAME, it returns -22 error code.
> How about adding processing with zynqmp_pm_query_data like
> PM_QID_CLOCK_GET_NAME or writing a comment here?
I will add comment for this kind of intentional cases.

Regards
Sai Krishna 
> 
> Best regards,
>   Nobuhiro
> 
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6


[PATCH v3 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver

2021-02-12 Thread Sai Krishna Potthuri
Adding documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 339 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 2 files changed, 358 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index ..0c1149706f8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,339 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri 
+  - Rajan Vaja 
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number 
of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin 
configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux 
and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+type: object
+patternProperties:
+  '^mux':
+type: object
+description:
+  Pinctrl node's client devices use subnodes for pin muxes,
+  which in turn use below standard properties.
+$ref: pinmux-node.yaml#
+
+properties:
+  groups:
+description:
+  List of groups to select (either this or "pins" must be
+  specified), available groups for this subnode.
+items:
+  enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+ sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+

[PATCH v3 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

2021-02-12 Thread Sai Krishna Potthuri
Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/pinctrl/Kconfig  |   13 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
 3 files changed, 1045 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+   bool "Pinctrl driver for Xilinx ZynqMP"
+   depends on ARCH_ZYNQMP
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..ec0a5d0e22d5
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ *  Copyright (C) 2020 Xilinx, Inc.
+ *
+ *  Sai Krishna Potthuri 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX  "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN  16
+#define MAX_GROUP_PIN  50
+#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP   -1
+#define RESERVED_GROUP -2
+
+#define DRIVE_STRENGTH_2MA 2
+#define DRIVE_STRENGTH_4MA 4
+#define DRIVE_STRENGTH_8MA 8
+#define DRIVE_STRENGTH_12MA12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:  Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups:   Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+   char name[MAX_FUNC_NAME_LEN];
+   const char * const *groups;
+   unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups:   Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+   struct pinctrl_dev *pctrl;
+   const struct zynqmp_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynqmp_pmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:  Group name
+ * @pins:  Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+   const char *name;
+   unsigned int pins[MAX_GROUP_PIN];
+   unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ */
+enum zynqmp_pin_config_param {
+   PIN_CONFIG

[PATCH v3 1/3] firmware: xilinx: Add pinctrl support

2021-02-12 Thread Sai Krishna Potthuri
Adding pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri 
Acked-by: Michal Simek 
---
 drivers/firmware/xilinx/zynqmp.c | 114 +++
 include/linux/firmware/xlnx-zynqmp.h |  90 +
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!id)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+   *id = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+  0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+  param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES

[PATCH v3 0/3] Add ZynqMP pinctrl driver

2021-02-12 Thread Sai Krishna Potthuri
Add support for Xilinx ZynqMP pinctrl driver and also update the
Xilinx firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and
allow configuring the pins as per the request.

changes in v3:
- Fixed binding doc comments from Rob.
- Used 'maxItems' for groups and pins properties.
- Updated commit subject and description to have
present tense statements.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

Sai Krishna Potthuri (3):
  firmware: xilinx: Add pinctrl support
  dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver
  pinctrl: Add Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml |  339 ++
 drivers/firmware/xilinx/zynqmp.c  |  114 ++
 drivers/pinctrl/Kconfig   |   13 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-zynqmp.c  | 1031 +
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |   19 +
 include/linux/firmware/xlnx-zynqmp.h  |   90 ++
 7 files changed, 1607 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



RE: [PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver

2021-02-09 Thread Sai Krishna Potthuri
Hi Rob,

> -Original Message-
> From: Rob Herring 
> Sent: Tuesday, February 9, 2021 7:27 PM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Michal Simek
> ; Greg Kroah-Hartman ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-g...@vger.kernel.org; git
> ; saikrishna12...@gmail.com
> Subject: Re: [PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP
> pinctrl driver
> 
> On Tue, Feb 9, 2021 at 2:17 AM Sai Krishna Potthuri 
> wrote:
> >
> > Hi Rob,
> >
> > Thanks for the review.
> >
> > > -Original Message-
> > > From: Rob Herring 
> > > Sent: Tuesday, February 9, 2021 7:51 AM
> > > To: Sai Krishna Potthuri 
> > > Cc: Linus Walleij ; Michal Simek
> > > ; Greg Kroah-Hartman
> > > ; linux-arm-ker...@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> > > linux-g...@vger.kernel.org; git ;
> > > saikrishna12...@gmail.com
> > > Subject: Re: [PATCH v2 2/3] dt-bindings: pinctrl: Added binding for
> > > ZynqMP pinctrl driver
> > >
> > > On Tue, Jan 19, 2021 at 10:57:33AM +0530, Sai Krishna Potthuri wrote:
> > > > Added documentation and dt-bindings file which contains MIO pin
> > > > configuration defines for Xilinx ZynqMP pinctrl driver.
> > > >
> > > > Signed-off-by: Sai Krishna Potthuri
> > > > 
> > > > ---
> > > >  .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 337
> > > > ++  include/dt-bindings/pinctrl/pinctrl-zynqmp.h
> > > > ++ |
> > > > 23 ++
> > > >  2 files changed, 360 insertions(+)  create mode 100644
> > > > Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> > > >  create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.ya
> > > > ml
> > > > b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.ya
> > > > ml
> > > > new file mode 100644
> > > > index ..9f2efbafcaa4
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctr
> > > > +++ l.ya
> > > > +++ ml
> > > > @@ -0,0 +1,337 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
> > > > +---
> > > > +$id:
> > > > +http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Xilinx ZynqMP Pinctrl
> > > > +
> > > > +maintainers:
> > > > +  - Sai Krishna Potthuri
> > > > +
> > > > +  - Rajan Vaja 
> > > > +
> > > > +description: |
> > > > +  Please refer to pinctrl-bindings.txt in this directory for
> > > > +details of the
> > > > +  common pinctrl bindings used by client devices, including the
> > > > +meaning of the
> > > > +  phrase "pin configuration node".
> > > > +
> > > > +  ZynqMP's pin configuration nodes act as a container for an
> > > > + arbitrary number of  subnodes. Each of these subnodes represents
> > > > + some desired configuration for a  pin, a group, or a list of
> > > > + pins or groups. This configuration can include the  mux function
> > > > + to select on those pin(s)/group(s), and various pin
> > > > + configuration  parameters, such
> > > as pull-up, slew rate, etc.
> > > > +
> > > > +  Each configuration node can consist of multiple nodes
> > > > + describing the pinmux and  pinconf options. Those nodes can be
> > > > + pinmux nodes or
> > > pinconf nodes.
> > > > +
> > > > +  The name of each subnode is not important; all subnodes should
> > > > + be enumerated  and processed purely based on their content.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +const: xlnx,zynqmp-pinctrl
> > > > +
> > > > +patternProperties:
> > > > +  '^(.*-)?(default|gpio)$':
> > > > +type: object
> > > > +patternProperties:
> > > > +  '^mux(.*)$':
> > >
> > > '^mux' is equivalent.
> > I will fix in v3.
> &g

RE: [PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver

2021-02-09 Thread Sai Krishna Potthuri
Hi Rob,

Thanks for the review.

> -Original Message-
> From: Rob Herring 
> Sent: Tuesday, February 9, 2021 7:51 AM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Michal Simek
> ; Greg Kroah-Hartman ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-g...@vger.kernel.org; git
> ; saikrishna12...@gmail.com
> Subject: Re: [PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP
> pinctrl driver
> 
> On Tue, Jan 19, 2021 at 10:57:33AM +0530, Sai Krishna Potthuri wrote:
> > Added documentation and dt-bindings file which contains MIO pin
> > configuration defines for Xilinx ZynqMP pinctrl driver.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 337
> > ++  include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |
> > 23 ++
> >  2 files changed, 360 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> >  create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> > b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> > new file mode 100644
> > index ..9f2efbafcaa4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.ya
> > +++ ml
> > @@ -0,0 +1,337 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Xilinx ZynqMP Pinctrl
> > +
> > +maintainers:
> > +  - Sai Krishna Potthuri 
> > +  - Rajan Vaja 
> > +
> > +description: |
> > +  Please refer to pinctrl-bindings.txt in this directory for details
> > +of the
> > +  common pinctrl bindings used by client devices, including the
> > +meaning of the
> > +  phrase "pin configuration node".
> > +
> > +  ZynqMP's pin configuration nodes act as a container for an
> > + arbitrary number of  subnodes. Each of these subnodes represents
> > + some desired configuration for a  pin, a group, or a list of pins or
> > + groups. This configuration can include the  mux function to select
> > + on those pin(s)/group(s), and various pin configuration  parameters, such
> as pull-up, slew rate, etc.
> > +
> > +  Each configuration node can consist of multiple nodes describing
> > + the pinmux and  pinconf options. Those nodes can be pinmux nodes or
> pinconf nodes.
> > +
> > +  The name of each subnode is not important; all subnodes should be
> > + enumerated  and processed purely based on their content.
> > +
> > +properties:
> > +  compatible:
> > +const: xlnx,zynqmp-pinctrl
> > +
> > +patternProperties:
> > +  '^(.*-)?(default|gpio)$':
> > +type: object
> > +patternProperties:
> > +  '^mux(.*)$':
> 
> '^mux' is equivalent.
I will fix in v3.

> 
> > +type: object
> > +description:
> > +  Pinctrl node's client devices use subnodes for pin muxes,
> > +  which in turn use below standard properties.
> > +$ref: pinmux-node.yaml#
> > +
> > +properties:
> > +  groups:
> > +description:
> > +  List of groups to select (either this or "pins" must be
> > +  specified), available groups for this subnode.
> > +items:
> > +  oneOf:
> > +- enum: [ethernet0_0_grp, ethernet1_0_grp,
> > + ethernet2_0_grp,
> 
> Don't need 'oneOf' for a single item.
Here we have a possibility to have more than one group item as below,
hence used 'oneOf'.
groups = "uart0_4_grp", "uart0_5_grp";
Please suggest me if there is a better/another way to represent this.

> 
> > + ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
> > + gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
> > + mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
> > + qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
> > + spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
> > + spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
> > + spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
> > + spi0_ss_6_grp, spi0_

[PATCH v2 0/3] Added ZynqMP pinctrl driver

2021-01-18 Thread Sai Krishna Potthuri
Added support for Xilinx ZynqMP pinctrl driver support and also
updated the Xilinx firmware driver to support pinctrl functionality.
This driver will query the pin information from the firmware and
allow configuring the pins as per the request.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

This might be resend for some people, as i had some trouble with my
email server earlier.

Sai Krishna Potthuri (3):
  firmware: xilinx: Added pinctrl support
  dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver
  pinctrl: Added Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml |  337 ++
 drivers/firmware/xilinx/zynqmp.c  |  114 ++
 drivers/pinctrl/Kconfig   |   13 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-zynqmp.c  | 1031 +
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |   23 +
 include/linux/firmware/xlnx-zynqmp.h  |   90 ++
 7 files changed, 1609 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



[PATCH v2 1/3] firmware: xilinx: Added pinctrl support

2021-01-18 Thread Sai Krishna Potthuri
Add pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/firmware/xilinx/zynqmp.c | 114 +++
 include/linux/firmware/xlnx-zynqmp.h |  90 +
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!id)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+   *id = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+  0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+  param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES,
+   PM_QID_PINCTRL_GET_NUM_PINS = 6

[PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver

2021-01-18 Thread Sai Krishna Potthuri
Added documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 337 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  23 ++
 2 files changed, 360 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index ..9f2efbafcaa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,337 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri 
+  - Rajan Vaja 
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number 
of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin 
configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux 
and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+type: object
+patternProperties:
+  '^mux(.*)$':
+type: object
+description:
+  Pinctrl node's client devices use subnodes for pin muxes,
+  which in turn use below standard properties.
+$ref: pinmux-node.yaml#
+
+properties:
+  groups:
+description:
+  List of groups to select (either this or "pins" must be
+  specified), available groups for this subnode.
+items:
+  oneOf:
+- enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2

[PATCH v2 3/3] pinctrl: Added Xilinx ZynqMP pinctrl driver support

2021-01-18 Thread Sai Krishna Potthuri
Added pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/pinctrl/Kconfig  |   13 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
 3 files changed, 1045 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+   bool "Pinctrl driver for Xilinx ZynqMP"
+   depends on ARCH_ZYNQMP
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..ec0a5d0e22d5
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ *  Copyright (C) 2020 Xilinx, Inc.
+ *
+ *  Sai Krishna Potthuri 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX  "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN  16
+#define MAX_GROUP_PIN  50
+#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP   -1
+#define RESERVED_GROUP -2
+
+#define DRIVE_STRENGTH_2MA 2
+#define DRIVE_STRENGTH_4MA 4
+#define DRIVE_STRENGTH_8MA 8
+#define DRIVE_STRENGTH_12MA12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:  Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups:   Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+   char name[MAX_FUNC_NAME_LEN];
+   const char * const *groups;
+   unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups:   Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+   struct pinctrl_dev *pctrl;
+   const struct zynqmp_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynqmp_pmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:  Group name
+ * @pins:  Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+   const char *name;
+   unsigned int pins[MAX_GROUP_PIN];
+   unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ */
+enum zynqmp_pin_config_param {
+   PIN_CONFIG

RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

2021-01-07 Thread Chatradhi, Naveen Krishna
[AMD Official Use Only - Approved for External Use]

Hi Guenter,

>> No, because you are not in the approval path (you did not send the patch to 
>> me). Reviewed-by: or Acked-by: would be more appropriate.

Got it, my mistake, please use 
Acked-by: Naveen Krishna Chatradhi 

Regards,
Naveenk

-Original Message-
From: Guenter Roeck  On Behalf Of Guenter Roeck
Sent: Friday, January 8, 2021 11:47 AM
To: Chatradhi, Naveen Krishna ; David Arcari 
; linux-hw...@vger.kernel.org
Cc: Jean Delvare ; linux-kernel@vger.kernel.org; 
sta...@vger.kernel.org
Subject: Re: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info 
config

[CAUTION: External Email]

On 1/7/21 9:49 PM, Chatradhi, Naveen Krishna wrote:
> [AMD Official Use Only - Approved for External Use]
>
> Hi David,
>
> Thank you for noticing and submitting a fix. You may use
> Signed-off-by: Naveen Krishna Chatradhi 
>

No, because you are not in the approval path (you did not send the patch to 
me). Reviewed-by: or Acked-by: would be more appropriate.

Genter

> Regards,
> Naveenk
>
> -Original Message-
> From: David Arcari 
> Sent: Thursday, January 7, 2021 8:17 PM
> To: linux-hw...@vger.kernel.org
> Cc: David Arcari ; Chatradhi, Naveen Krishna 
> ; Jean Delvare ; 
> Guenter Roeck ; linux-kernel@vger.kernel.org; 
> sta...@vger.kernel.org
> Subject: [PATCH] hwmon: (amd_energy) fix allocation of 
> hwmon_channel_info config
>
> [CAUTION: External Email]
>
> hwmon, specifically hwmon_num_channel_attrs, expects the config array in the 
> hwmon_channel_info structure to be terminated by a zero entry.  amd_energy 
> does not honor this convention.  As result, a KASAN warning is possible.  Fix 
> this by adding an additional entry and setting it to zero.
>
> Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy 
> counters")
>
> Signed-off-by: David Arcari 
> Cc: Naveen Krishna Chatradhi  [naveenk:] 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Jean Delvare 
> Cc: Guenter Roeck 
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hwmon/amd_energy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c 
> index 9b306448b7a0..822c2e74b98d 100644
> --- a/drivers/hwmon/amd_energy.c
> +++ b/drivers/hwmon/amd_energy.c
> @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev,
>  */
> cpus = num_present_cpus() / num_siblings;
>
> -   s_config = devm_kcalloc(dev, cpus + sockets,
> +   s_config = devm_kcalloc(dev, cpus + sockets + 1,
> sizeof(u32), GFP_KERNEL);
> if (!s_config)
> return -ENOMEM;
> @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev,
> scnprintf(label_l[i], 10, "Esocket%u", (i - cpus));
> }
>
> +   s_config[i] = 0;
> return 0;
>  }
>
> --
> 2.18.1
>


RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

2021-01-07 Thread Chatradhi, Naveen Krishna
[AMD Official Use Only - Approved for External Use]

Hi David,

Thank you for noticing and submitting a fix. You may use
Signed-off-by: Naveen Krishna Chatradhi 

Regards,
Naveenk

-Original Message-
From: David Arcari  
Sent: Thursday, January 7, 2021 8:17 PM
To: linux-hw...@vger.kernel.org
Cc: David Arcari ; Chatradhi, Naveen Krishna 
; Jean Delvare ; Guenter 
Roeck ; linux-kernel@vger.kernel.org; sta...@vger.kernel.org
Subject: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

[CAUTION: External Email]

hwmon, specifically hwmon_num_channel_attrs, expects the config array in the 
hwmon_channel_info structure to be terminated by a zero entry.  amd_energy does 
not honor this convention.  As result, a KASAN warning is possible.  Fix this 
by adding an additional entry and setting it to zero.

Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")

Signed-off-by: David Arcari 
Cc: Naveen Krishna Chatradhi 
[naveenk:] Signed-off-by: Naveen Krishna Chatradhi 
Cc: Jean Delvare 
Cc: Guenter Roeck 
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 drivers/hwmon/amd_energy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c index 
9b306448b7a0..822c2e74b98d 100644
--- a/drivers/hwmon/amd_energy.c
+++ b/drivers/hwmon/amd_energy.c
@@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev,
 */
cpus = num_present_cpus() / num_siblings;

-   s_config = devm_kcalloc(dev, cpus + sockets,
+   s_config = devm_kcalloc(dev, cpus + sockets + 1,
sizeof(u32), GFP_KERNEL);
if (!s_config)
return -ENOMEM;
@@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev,
scnprintf(label_l[i], 10, "Esocket%u", (i - cpus));
}

+   s_config[i] = 0;
return 0;
 }

--
2.18.1


RE: [PATCH 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver

2020-12-10 Thread Sai Krishna Potthuri
Hi Rob,

Thanks for the review

> -Original Message-
> From: Rob Herring 
> Sent: Wednesday, December 9, 2020 10:33 PM
> To: Sai Krishna Potthuri 
> Cc: Linus Walleij ; Michal Simek
> ; Greg Kroah-Hartman ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-g...@vger.kernel.org; git
> ; saikrishna12...@gmail.com
> Subject: Re: [PATCH 2/3] dt-bindings: pinctrl: Added binding for ZynqMP
> pinctrl driver
> 
> On Wed, Dec 09, 2020 at 02:14:13PM +0530, Sai Krishna Potthuri wrote:
> > Added documentation and dt-bindings file which contains MIO pin
> > configuration defines for Xilinx ZynqMP pinctrl driver.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 329
> > ++  include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |
> > 29 ++
> >  2 files changed, 358 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> >  create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> > b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
> > new file mode 100644
> > index ..dd0c8c12714f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.ya
> > +++ ml
> > @@ -0,0 +1,329 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Xilinx ZynqMP Pinctrl
> > +
> > +maintainers:
> > +  - Sai Krishna Potthuri 
> > +  - Rajan Vaja 
> > +
> > +description: |
> > +  Please refer to pinctrl-bindings.txt in this directory for details
> > +of the
> > +  common pinctrl bindings used by client devices, including the
> > +meaning of the
> > +  phrase "pin configuration node".
> > +
> > +  ZynqMP's pin configuration nodes act as a container for an
> > + arbitrary number of  subnodes. Each of these subnodes represents
> > + some desired configuration for a  pin, a group, or a list of pins or
> > + groups. This configuration can include the  mux function to select
> > + on those pin(s)/group(s), and various pin configuration  parameters, such
> as pull-up, slew rate, etc.
> > +
> > +  Each configuration node can consist of multiple nodes describing
> > + the pinmux and  pinconf options. Those nodes can be pinmux nodes or
> pinconf nodes.
> > +
> > +  The name of each subnode is not important; all subnodes should be
> > + enumerated  and processed purely based on their content.
> > +
> > +properties:
> > +  compatible:
> > +const: xlnx,zynqmp-pinctrl
> > +
> > +patternProperties:
> > +  '^(.*-)?(default|gpio)$':
> > +type: object
> > +patternProperties:
> > +  '^(.*-)?mux$':
> > +type: object
> > +description:
> > +  Pinctrl node's client devices use subnodes for pin muxes,
> > +  which in turn use below standard properties.
> > +$ref: pinmux-node.yaml#
> > +
> > +properties:
> > +  groups:
> > +description:
> > +  List of groups to select (either this or "pins" must be
> > +  specified), available groups for this subnode.
> > +enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
> > +   ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
> > +   gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
> > +   mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
> > +   qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
> > +   spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
> > +   spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
> > +   spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
> > +   spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
> > +   spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
> > +   spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
> > +   spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
> > +   spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
> > +   spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
> > +   spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
>

[PATCH 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver

2020-12-09 Thread Sai Krishna Potthuri
Added documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 329 ++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  29 ++
 2 files changed, 358 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index ..dd0c8c12714f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,329 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri 
+  - Rajan Vaja 
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number 
of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin 
configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux 
and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+type: object
+patternProperties:
+  '^(.*-)?mux$':
+type: object
+description:
+  Pinctrl node's client devices use subnodes for pin muxes,
+  which in turn use below standard properties.
+$ref: pinmux-node.yaml#
+
+properties:
+  groups:
+description:
+  List of groups to select (either this or "pins" must be
+  specified), available groups for this subnode.
+enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+   ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+   gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+   mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+   qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+   spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+   spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+   spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+   spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+   spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+   spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+   spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+   spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+   spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+   spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+   spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+   spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+   spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+   spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+   spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+   spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+   sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+   sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+   sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+   sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+   sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+   sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+   sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+   sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+   sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+   sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+   sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+   sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+   sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+   sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+   sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+   sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+   sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
+   sdio1_9_grp, sdio1_

[PATCH 3/3] pinctrl: Added Xilinx ZynqMP pinctrl driver support

2020-12-09 Thread Sai Krishna Potthuri
Added pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/pinctrl/Kconfig  |   13 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
 3 files changed, 1045 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+   bool "Pinctrl driver for Xilinx ZynqMP"
+   depends on ARCH_ZYNQMP
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)  += pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)   += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..0694cd6fc753
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ *  Copyright (C) 2020 Xilinx, Inc.
+ *
+ *  Sai Krishna Potthuri 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX  "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN  16
+#define MAX_GROUP_PIN  50
+#define END_OF_FUNCTIONS   "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN   12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP   -1
+#define RESERVED_GROUP -2
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:  Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups:   Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+   char name[MAX_FUNC_NAME_LEN];
+   const char * const *groups;
+   unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups:   Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+   struct pinctrl_dev *pctrl;
+   const struct zynqmp_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynqmp_pmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:  Group name
+ * @pins:  Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+   const char *name;
+   unsigned int pins[MAX_GROUP_PIN];
+   unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ * @PIN_CONFIG_SCHMITTCMOS:this parameter (on a custom format) allows
+ * to select schmitt or cmos input for MIO pins
+ */
+enum zynqmp_pin_config_param {
+   PIN_CONFIG_IOS

[PATCH 0/3] pinctrl: Added ZynqMP pinctrl driver

2020-12-09 Thread Sai Krishna Potthuri
Added support for Xilinx ZynqMP pinctrl driver support and
also updated the Xilinx firmware driver to support pinctrl
functionality.
This driver will query the pin information from the firmware
and allow configuring the pins as per the request.

Sai Krishna Potthuri (3):
  firmware: xilinx: Added pinctrl support
  dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver
  pinctrl: Added Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml |  329 ++
 drivers/firmware/xilinx/zynqmp.c  |  114 ++
 drivers/pinctrl/Kconfig   |   13 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-zynqmp.c  | 1031 +
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |   29 +
 include/linux/firmware/xlnx-zynqmp.h  |   90 ++
 7 files changed, 1607 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



[PATCH 1/3] firmware: xilinx: Added pinctrl support

2020-12-09 Thread Sai Krishna Potthuri
Add pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/firmware/xilinx/zynqmp.c | 114 +++
 include/linux/firmware/xlnx-zynqmp.h |  90 +
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!id)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+   *id = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+  0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   if (!value)
+   return -EINVAL;
+
+   ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+   *value = ret_payload[1];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+   return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+  param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES,
+   PM_QID_PINCTRL_GET_NUM_PINS = 6

RE: [PATCH linux hwmon-next v4 1/3] hwmon: (sbtsi) Add basic support for SB-TSI sensors

2020-12-03 Thread Chatradhi, Naveen Krishna
[AMD Official Use Only - Approved for External Use]

Hi Kun Yi,

> Test status: tested reading temp1_input, and reading/writing 
> temp1_max/min.

Tested the above at our end from an arm based BMC connected to the 2P Rome 
machine, it works fine. 

Regards,
Naveenk

-Original Message-
From: Guenter Roeck  
Sent: Thursday, December 3, 2020 7:08 AM
To: Kun Yi 
Cc: jdelv...@suse.com; robh...@kernel.org; mark.rutl...@arm.com; Venkatesh, 
Supreeth ; open...@lists.ozlabs.org; 
linux-hw...@vger.kernel.org; devicet...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH linux hwmon-next v4 1/3] hwmon: (sbtsi) Add basic support 
for SB-TSI sensors

[CAUTION: External Email]

On Wed, Dec 02, 2020 at 08:55:59AM -0800, Kun Yi wrote:
> SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible 
> interface that reports AMD SoC's Ttcl (normalized temperature), and 
> resembles a typical 8-pin remote temperature sensor's I2C interface to 
> BMC.
>
> This commit adds basic support using this interface to read CPU 
> temperature, and read/write high/low CPU temp thresholds.
>
> To instantiate this driver on an AMD CPU with SB-TSI support, the i2c 
> bus number would be the bus connected from the board management 
> controller (BMC) to the CPU. The i2c address is specified in Section 
> 6.3.1 of the spec [1]: The SB-TSI address is normally 98h for socket 0 
> and 90h for socket 1, but it could vary based on hardware address 
> select pins.
>
> [1]: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> amd.com%2Fsystem%2Ffiles%2FTechDocs%2F56255_OSRR.pdfdata=04%7C01%
> 7CNaveenKrishna.Chatradhi%40amd.com%7C1a8cb0ebe4bb43bc759808d8972c562f
> %7C3dd8961fe4884e608e11a82d994e183d%7C0%7C1%7C637425563976853035%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C1000sdata=oH5YmE000EUVGVxruzI%2FBRnWOKptlG%2Bpf
> yKferIwYME%3Dreserved=0
>
> Test status: tested reading temp1_input, and reading/writing 
> temp1_max/min.
>
> Signed-off-by: Kun Yi 
> ---
>  drivers/hwmon/Kconfig  |  10 ++
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/sbtsi_temp.c | 265 
> +
>  3 files changed, 276 insertions(+)
>  create mode 100644 drivers/hwmon/sbtsi_temp.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
> 3c059fc23cd6..3d6a809700ae 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1522,6 +1522,16 @@ config SENSORS_SL28CPLD
> This driver can also be built as a module.  If so, the module
> will be called sl28cpld-hwmon.
>
> +config SENSORS_SBTSI
> + tristate "Emulated SB-TSI temperature sensor"
> + depends on I2C
> + help
> +   If you say yes here you get support for emulated temperature
> +   sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
> +
> +   This driver can also be built as a module. If so, the module will
> +   be called sbtsi_temp.
> +
>  config SENSORS_SHT15
>   tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>   depends on GPIOLIB || COMPILE_TEST diff --git 
> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 
> 01ca5d3fbad4..ee8c037919da 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -160,6 +160,7 @@ obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
>  obj-$(CONFIG_SENSORS_PWM_FAN)+= pwm-fan.o
>  obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)  += raspberrypi-hwmon.o
>  obj-$(CONFIG_SENSORS_S3C)+= s3c-hwmon.o
> +obj-$(CONFIG_SENSORS_SBTSI)  += sbtsi_temp.o
>  obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>  obj-$(CONFIG_SENSORS_SCH5627)+= sch5627.o
>  obj-$(CONFIG_SENSORS_SCH5636)+= sch5636.o
> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c 
> new file mode 100644 index ..6b0a7b9df1f3
> --- /dev/null
> +++ b/drivers/hwmon/sbtsi_temp.c
> @@ -0,0 +1,265 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbtsi_temp.c - hwmon driver for a SBI Temperature Sensor Interface 
> (SB-TSI)
> + *compliant AMD SoC temperature device.
> + *
> + * Copyright (c) 2020, Google Inc.
> + * Copyright (c) 2020, Kun Yi   */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SB-TSI registers only support SMBus byte data access. "_INT" 
> +registers are
> + * the integer part of a temperature value or limit, and "_DEC" 
> +registers are
> + * corresponding decimal parts.
> + */
> +#define SBTSI_REG_TEMP_INT   0x01 /* RO */
> +#define SBTSI_REG_STATUS 0x02 /* RO */
> +#define SBTSI_REG_CONFIG 0x03 /* RO */
> +#define SBTSI_REG_TEMP_HIGH_INT  0x07 /* RW */
> +#define SBTSI_REG_TEMP_LOW_INT   0x08 /* RW */
> +#define SBTSI_REG_TEMP_DEC   0x10 /* RW */
> +#define SBTSI_REG_TEMP_HIGH_DEC  0x13 /* RW */
> +#define 

Spinlock debugging in the kernel

2020-11-30 Thread Krishna M
Please excuse me if this is a wrong group.
Please find the log of a system that I am trying to debug.

It is a "soft lockup" issue and the root cause seems to be coming from
the mm unit of the kernel.
I am relatively new to kernel and arm64 platforms.


How do you typically decipher a locking issue like this? Any ideas/
pointers that I can run with will greatly help.

[  512.522056] Rehashing will be triggered for ipset fqdn:pol_5_to of
elements 362 ahash_max 4 nsize 4
[  907.867755] BUG: soft lockup - CPU#0 stuck for 22s! [kswapd0:395]
[  919.861747] BUG: soft lockup - CPU#0 stuck for 33s! [kswapd0:395]
[  919.861752] Modules linked in: nfsv3 nfs lockd grace sunrpc
ath9k(O) ath9k_common(O) ath9k_hw(O) ath(O) mac80211(O) cfg80211(O)
compat(O) gproxy(O) bwdriver(O)rndis_host cdc_ether usbnet
mii GobiSerial(O) cdc_acm option usb_wwan clstrio(O) clb(PO) kxp(PO)
ip6t_rpfilter ip6t_REJECTnf_log_ipv6 nf_reject_ipv6 ip6t_frag
ip6table_mangle ip6table_filter ip6table_raw ip6t_ipv6header
nf_conntrack_ipv6 nf_defrag_ipv6 ifb act_mirred em_meta cls_basic
cls_flow cls_u32 sch_htb sch_prio sch_sfq arpt_ARPPROXY arpt_REPLY
arpt_mangle arptable_filter arp_tables xt_REDIRECT xt_nat ipt_REJECT
xt_recent xt_NETMAP ipt_MASQUERADEnf_log_ipv4
nf_log_common xt_LOG xt_iprange ipt_ah xt_addrtype xt_TRACE xt_TCPMSS
xt_tcpmss xt_state xt_rateest xt_RATEEST xt_pkttype xt_physdev
[  919.862293]  xt_multiport xt_mark xt_mac xt_limit(O) xt_length
xt_ipv4options(O) xt_helper xt_hashlimit xt_esp xt_DSCP xt_dscp xt_CT
xt_conntrack xt_connmark xt_connbytes xt_comment
xt_CLASSIFY nf_conntrack_netlink iptable_raw nf_nat_snmp_basic
nf_conntrack_snmp nf_conntrack_broadcast nf_nat_tftp nf_conntrack_tftp
nf_nat_pptpnf_nat_proto_gre nf_conntrack_pptp
nf_conntrack_proto_gre nf_nat_irc nf_conntrack_irc nf_nat_ftp
nf_conntrack_ftp iptable_filter iptable_nat iptable_mangle
nf_reject_ipv4   nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat_ipv4
nf_nat ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
compat_xtables(O) ip_set_hash_netportnet(O)
ip_set_hash_netnet(O) ip_set_hash_netiface(O) ip_set_hash_mac(O)
ip_set_hash_ipmark(O) ip_set_list_set(O) ip_set_hash_netport(O)
ip_set_hash_net(O) ip_set_hash_ipportip(O)
[  919.862508]  ip_set_hash_ipportnet(O) ip_set_hash_ipport(O)
ip_set_hash_ip(O) ip_set_bitmap_port(O) ip_set_bitmap_ipmac(O)
ip_set_bitmap_ip(O) xt_set(O) ip_set(O)nfnetlink
sha512_generic dummy bonding ip6_vti ip6_tunnel tunnel6 ebt_ip6
ebt_arpreply 8021q garp ip_vti ip_gre ip_tunnel gre ebt_mark_m
ebt_mark ebt_redirect ebt_dnat  ebt_ip ebt_arp ebt_snat ebt_vlan
ebt_log ebt_fpath(O) ebtable_broute ebtable_filter ebtable_nat
ebtables br_netfilter bridge stp llc alarm_panic(PO) alarm(PO)
l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel tun pppoe
pppox ppp_deflate ppp_mppe ppp_async ppp_generic crc_ccitt slhc
usb_storage caam_pkc caamalg caamhash caamalg_desc caamhash_desc
caamrng caam_jr error(P) caam [last unloaded: nf_synproxy_core]
[  919.862794] CPU: 0 PID: 395 Comm: kswapd0 Tainted: P   O
4.14.83 #1
[  919.862802] task: 5a1b task.stack: 5a0ba000
[  919.862808] NIP:  406f7f04 LR: 40163650 CTR: 40163d8c
[  919.862815] REGS: 5a0bbad0 TRAP: 0901   Tainted: P   O (4.14.83)
[  919.862818] MSR:  00029000   CR: 44002444  XER: 
[  919.862843]  GPR00: 40163e08 5a0bbb80 5a1b 5aa16698 55f80540
1000f000    GPR08: 0001 0001 0001 0409
24004442
[  919.862915] NIP [406f7f04] _raw_spin_lock+0x30/0x5c
[  919.862934] LR [40163650] page_vma_mapped_walk+0x144/0x1e8

Thanks,
Krishna M


Re: [PATCH] [v6] wireless: Initial driver submission for pureLiFi STA devices

2020-10-19 Thread Krishna Chaitanya
On Mon, Oct 19, 2020 at 4:01 PM Srinivasan Raju  wrote:
>
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices.
>
> This driver implementation has been based on the zd1211rw driver.
>
> Driver is based on 802.11 softMAC Architecture and uses
> native 802.11 for configuration and management.
>
> The driver is compiled and tested in ARM, x86 architectures and
> compiled in powerpc architecture.
>
> Reported-by: kernel test robot 
> Signed-off-by: Srinivasan Raju 
> ---
>  MAINTAINERS|5 +
>  drivers/net/wireless/Kconfig   |1 +
>  drivers/net/wireless/Makefile  |1 +
>  drivers/net/wireless/purelifi/Kconfig  |   27 +
>  drivers/net/wireless/purelifi/Makefile |3 +
>  drivers/net/wireless/purelifi/chip.c   |   94 ++
>  drivers/net/wireless/purelifi/chip.h   |   82 ++
>  drivers/net/wireless/purelifi/intf.h   |   38 +
>  drivers/net/wireless/purelifi/mac.c|  860 +
>  drivers/net/wireless/purelifi/mac.h|  180 +++
>  drivers/net/wireless/purelifi/usb.c| 1627 
>  drivers/net/wireless/purelifi/usb.h|  148 +++
>  12 files changed, 3066 insertions(+)
>  create mode 100644 drivers/net/wireless/purelifi/Kconfig
>  create mode 100644 drivers/net/wireless/purelifi/Makefile
>  create mode 100644 drivers/net/wireless/purelifi/chip.c
>  create mode 100644 drivers/net/wireless/purelifi/chip.h
>  create mode 100644 drivers/net/wireless/purelifi/intf.h
>  create mode 100644 drivers/net/wireless/purelifi/mac.c
>  create mode 100644 drivers/net/wireless/purelifi/mac.h
>  create mode 100644 drivers/net/wireless/purelifi/usb.c
>  create mode 100644 drivers/net/wireless/purelifi/usb.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c80f87d7258c..150f592fb6e4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14108,6 +14108,11 @@ T: git git://linuxtv.org/media_tree.git
>  F: Documentation/admin-guide/media/pulse8-cec.rst
>  F: drivers/media/cec/usb/pulse8/
>
> +PUREILIFI USB DRIVER
> +M: Srinivasan Raju 
> +S: Maintained
> +F: drivers/net/wireless/purelifi
> +
>  PVRUSB2 VIDEO4LINUX DRIVER
>  M: Mike Isely 
>  L: pvru...@isely.net   (subscribers-only)
> diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
> index 170a64e67709..b87da3139f94 100644
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
> @@ -48,6 +48,7 @@ source "drivers/net/wireless/st/Kconfig"
>  source "drivers/net/wireless/ti/Kconfig"
>  source "drivers/net/wireless/zydas/Kconfig"
>  source "drivers/net/wireless/quantenna/Kconfig"
> +source "drivers/net/wireless/purelifi/Kconfig"
>
>  config PCMCIA_RAYCS
> tristate "Aviator/Raytheon 2.4GHz wireless support"
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 80b324499786..e9fc770026f0 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/
>  obj-$(CONFIG_WLAN_VENDOR_TI) += ti/
>  obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/
>  obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/
> +obj-$(CONFIG_WLAN_VENDOR_PURELIFI) += purelifi/
>
>  # 16-bit wireless PCMCIA client drivers
>  obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o
> diff --git a/drivers/net/wireless/purelifi/Kconfig 
> b/drivers/net/wireless/purelifi/Kconfig
> new file mode 100644
> index ..f6630791df9d
> --- /dev/null
> +++ b/drivers/net/wireless/purelifi/Kconfig
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config WLAN_VENDOR_PURELIFI
> +   bool "pureLiFi devices"
> +   default y
> +   help
> + If you have a pureLiFi device, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all the
> + questions about these cards. If you say Y, you will be asked for
> + your specific card in the following questions.
> +
> +if WLAN_VENDOR_PURELIFI
> +
> +config PURELIFI
> +
> +   tristate "pureLiFi device support"
> +   depends on CFG80211 && MAC80211 && USB
> +   help
> +  This driver makes the adapter appear as a normal WLAN interface.
> +
> +  The pureLiFi device requires external STA firmware to be loaded.
> +
> +  To compile this driver as a module, choose M here: the module will
> +  be called purelifi.
> +
> +endif # WLAN_VENDOR_PURELIFI
> diff --git a/drivers/net/wireless/purelifi/Makefile 
> b/drivers/net/wireless/purelifi/Makefile
> new file mode 100644
> index ..1f20055e741f
> --- /dev/null
> +++ b/drivers/net/wireless/purelifi/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_PURELIFI) := purelifi.o
> +purelifi-objs  += chip.o usb.o mac.o
> diff --git a/drivers/net/wireless/purelifi/chip.c 
> b/drivers/net/wireless/purelifi/chip.c
> new file mode 100644
> 

[v3] drm/msm: Fix race condition in msm driver with async layer updates

2020-10-16 Thread Krishna Manikandan
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.

Synchronize the compositions such that second commit waits
until first commit flushes the composition.

This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.

Changes in v2:
- Use an array of mutexes in kms to handle commit
  lock per crtc. (Rob Clark)

Changes in v3:
- Add wrapper functions to handle lock and unlock of
  commit_lock for each crtc. (Rob Clark)

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/msm_atomic.c | 37 -
 drivers/gpu/drm/msm/msm_kms.h|  6 --
 2 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..575e9af 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned 
crtc_mask)
}
 }
 
+static void lock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   struct drm_crtc *crtc;
+
+   for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+   mutex_lock(>commit_lock[drm_crtc_index(crtc)]);
+}
+
+static void unlock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   struct drm_crtc *crtc;
+
+   for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+   mutex_unlock(>commit_lock[drm_crtc_index(crtc)]);
+}
+
 static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
 {
unsigned crtc_mask = BIT(crtc_idx);
 
trace_msm_atomic_async_commit_start(crtc_mask);
 
-   mutex_lock(>commit_lock);
+   lock_crtcs(kms, crtc_mask);
 
if (!(kms->pending_crtc_mask & crtc_mask)) {
-   mutex_unlock(>commit_lock);
+   unlock_crtcs(kms, crtc_mask);
goto out;
}
 
@@ -79,7 +95,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int 
crtc_idx)
 */
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
 
/*
 * Wait for flush to complete:
@@ -90,9 +105,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int 
crtc_idx)
 
vblank_put(kms, crtc_mask);
 
-   mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
+   unlock_crtcs(kms, crtc_mask);
kms->funcs->disable_commit(kms);
 
 out:
@@ -189,12 +203,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state 
*state)
 * Ensure any previous (potentially async) commit has
 * completed:
 */
+   lock_crtcs(kms, crtc_mask);
trace_msm_atomic_wait_flush_start(crtc_mask);
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
 
-   mutex_lock(>commit_lock);
-
/*
 * Now that there is no in-progress flush, prepare the
 * current update:
@@ -232,8 +245,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
}
 
kms->funcs->disable_commit(kms);
-   mutex_unlock(>commit_lock);
-
+   unlock_crtcs(kms, crtc_mask);
/*
 * At this point, from drm core's perspective, we
 * are done with the atomic update, so we can just
@@ -260,8 +272,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
 */
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
-
+   unlock_crtcs(kms, crtc_mask);
/*
 * Wait for flush to complete:
 */
@@ -271,9 +282,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
 
vblank_put(kms, crtc_mask);
 
-   mutex_lock(>commit_lock);
+   lock_crtcs(kms, crtc_mask);
kms->funcs->complete_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
+   unlock_crtcs(kms, crtc_mask);
kms->funcs->disable_commit(kms);
 
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 1cbef6b..2049847 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -155,7 +155,7 @@ struct msm_kms {
 * For async commit, where ->flush_commit() and later happens
 * from the crtc's pending_timer close to end of the frame:
 */
-   struct mutex commit_lock;
+   struct mutex commit_lock[MAX_CRTCS];
unsigned pending_crtc_mask;
struct msm_pending_timer pending_timers[MAX_CRTCS];
 };
@@ -165,7 +165,9 @@ static in

[v2] drm/msm: Fix race condition in msm driver with async layer updates

2020-10-15 Thread Krishna Manikandan
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.

Synchronize the compositions such that second commit waits
until first commit flushes the composition.

This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.

Changes in v2:
- Use an array of mutexes in kms to handle commit
  lock per crtc. (Rob Clark)

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/msm_atomic.c | 32 +++-
 drivers/gpu/drm/msm/msm_kms.h|  6 --
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..f9bd472 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -61,10 +61,10 @@ static void msm_atomic_async_commit(struct msm_kms *kms, 
int crtc_idx)
 
trace_msm_atomic_async_commit_start(crtc_mask);
 
-   mutex_lock(>commit_lock);
+   mutex_lock(>commit_lock[crtc_idx]);
 
if (!(kms->pending_crtc_mask & crtc_mask)) {
-   mutex_unlock(>commit_lock);
+   mutex_unlock(>commit_lock[crtc_idx]);
goto out;
}
 
@@ -79,7 +79,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int 
crtc_idx)
 */
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
 
/*
 * Wait for flush to complete:
@@ -90,9 +89,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int 
crtc_idx)
 
vblank_put(kms, crtc_mask);
 
-   mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
+   mutex_unlock(>commit_lock[crtc_idx]);
kms->funcs->disable_commit(kms);
 
 out:
@@ -171,6 +169,16 @@ static unsigned get_crtc_mask(struct drm_atomic_state 
*state)
return mask;
 }
 
+static int get_crtc_id(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   struct drm_crtc *crtc;
+
+   for_each_crtc_mask(kms->dev, crtc, crtc_mask)
+   return drm_crtc_index(crtc);
+
+   return 0;
+}
+
 void msm_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
@@ -180,6 +188,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
unsigned crtc_mask = get_crtc_mask(state);
bool async = kms->funcs->vsync_time &&
can_do_async(state, _crtc);
+   int crtc_idx = get_crtc_id(kms, crtc_mask);
 
trace_msm_atomic_commit_tail_start(async, crtc_mask);
 
@@ -189,12 +198,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state 
*state)
 * Ensure any previous (potentially async) commit has
 * completed:
 */
+   mutex_lock(>commit_lock[crtc_idx]);
trace_msm_atomic_wait_flush_start(crtc_mask);
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
 
-   mutex_lock(>commit_lock);
-
/*
 * Now that there is no in-progress flush, prepare the
 * current update:
@@ -232,8 +240,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
}
 
kms->funcs->disable_commit(kms);
-   mutex_unlock(>commit_lock);
-
+   mutex_unlock(>commit_lock[crtc_idx]);
/*
 * At this point, from drm core's perspective, we
 * are done with the atomic update, so we can just
@@ -260,8 +267,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
 */
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
-
+   mutex_unlock(>commit_lock[crtc_idx]);
/*
 * Wait for flush to complete:
 */
@@ -271,9 +277,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
 
vblank_put(kms, crtc_mask);
 
-   mutex_lock(>commit_lock);
+   mutex_lock(>commit_lock[crtc_idx]);
kms->funcs->complete_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
+   mutex_unlock(>commit_lock[crtc_idx]);
kms->funcs->disable_commit(kms);
 
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 1cbef6b..2049847 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -155,7 +155,7 @@ struct msm_kms {
 * For async commit, where ->flush_commit() and later happens
 * from the crtc's pending_timer close to end of the frame:
 */
-   struct mutex commit_lock;
+ 

[v1] drm/msm: Fix race condition in msm driver with async layer updates

2020-10-14 Thread Krishna Manikandan
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.

Synchronize the compositions such that second commit waits
until first commit flushes the composition.

This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.

Signed-off-by: Krishna Manikandan 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 26 
 drivers/gpu/drm/msm/msm_atomic.c | 35 ++--
 drivers/gpu/drm/msm/msm_kms.h|  5 +
 5 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index c2729f7..9024719 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1383,6 +1383,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, 
struct drm_plane *plane,
 
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+   mutex_init(_crtc->commit_lock);
 
DPU_DEBUG("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index cec3474..1eeb73d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -169,6 +169,7 @@ struct dpu_crtc {
 
/* for handling internal event thread */
spinlock_t event_lock;
+   struct mutex commit_lock;
 
struct dpu_core_perf_params cur_perf;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e..f99ae7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -445,6 +445,30 @@ static void dpu_kms_wait_flush(struct msm_kms *kms, 
unsigned crtc_mask)
dpu_kms_wait_for_commit_done(kms, crtc);
 }
 
+static void dpu_kms_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+   struct drm_crtc *crtc;
+   struct dpu_crtc *dpu_crtc;
+
+   for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+   dpu_crtc = to_dpu_crtc(crtc);
+   mutex_lock(_crtc->commit_lock);
+   }
+}
+
+static void dpu_kms_commit_unlock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+   struct drm_crtc *crtc;
+   struct dpu_crtc *dpu_crtc;
+
+   for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+   dpu_crtc = to_dpu_crtc(crtc);
+   mutex_unlock(_crtc->commit_lock);
+   }
+}
+
 static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
@@ -738,6 +762,8 @@ static const struct msm_kms_funcs kms_funcs = {
 #ifdef CONFIG_DEBUG_FS
.debugfs_init= dpu_kms_debugfs_init,
 #endif
+   .commit_lock = dpu_kms_commit_lock,
+   .commit_unlock   = dpu_kms_commit_unlock,
 };
 
 static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..d33253f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned 
crtc_mask)
}
 }
 
+static void msm_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   if (kms->funcs->commit_lock)
+   kms->funcs->commit_lock(kms, crtc_mask);
+   else
+   mutex_lock(>commit_lock);
+}
+
+static void msm_commit_unlock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+   if (kms->funcs->commit_unlock)
+   kms->funcs->commit_unlock(kms, crtc_mask);
+   else
+   mutex_unlock(>commit_lock);
+}
+
 static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
 {
unsigned crtc_mask = BIT(crtc_idx);
 
trace_msm_atomic_async_commit_start(crtc_mask);
 
-   mutex_lock(>commit_lock);
+   msm_commit_lock(kms, crtc_mask);
 
if (!(kms->pending_crtc_mask & crtc_mask)) {
-   mutex_unlock(>commit_lock);
+   msm_commit_unlock(kms, crtc_mask);
goto out;
}
 
@@ -79,7 +95,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int 
crtc_idx)
 */
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
-   mutex_unlock(>commit_lock);
 
/*
 * Wait for flush to complete:
@@ -90,9 +105,8 @@ static void m

[PATCH 2/2] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon

2020-08-10 Thread Krishna Manikandan
From: Chandan Uddaraju 

Add bindings for Snapdragon DisplayPort controller driver.

Changes in V2:
Provide details about sel-gpio

Changes in V4:
Provide details about max dp lanes
Change the commit text

Changes in V5:
moved dp.txt to yaml file

Changes in v6:
- Squash all AUX LUT properties into one pattern Property
- Make aux-cfg[0-9]-settings properties optional
- Remove PLL/PHY bindings from DP controller dts
- Add DP clocks description
- Remove _clk suffix from clock names
- Rename pixel clock to stream_pixel
- Remove redundant bindings (GPIO, PHY, HDCP clock, etc..)
- Fix indentation
- Add Display Port as interface of DPU in DPU bindings
  and add port mapping accordingly.

Chages in v7:
- Add dp-controller.yaml file common between multiple SOC
- Rename dp-sc7180.yaml to dp-controller-sc7180.yaml
- change compatible string and add SOC name to it.
- Remove Root clock generator for pixel clock
- Add assigned-clocks and assigned-clock-parents bindings
- Remove redundant properties, descriptions and blank lines
- Add DP port in DPU bindings
- Update depends-on tag in commit message and rebase change accordingly

Changes in v8:
- Add MDSS AHB clock in bindings

Changes in v9:
- Remove redundant reg-name property
- Change assigned-clocks and assigned-clocks-parents counts to 2
- Use IRQ flags in example dts

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
Signed-off-by: Tanmay Shah 
---
 .../bindings/display/msm/dp-controller-sc7180.yaml | 141 +
 .../bindings/display/msm/dp-controller.yaml|  59 +
 .../bindings/display/msm/dpu-sc7180.yaml   |  10 ++
 3 files changed, 210 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dp-controller-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dp-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/display/msm/dp-controller-sc7180.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller-sc7180.yaml
new file mode 100644
index 000..83a9e39
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller-sc7180.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only  OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dp-controller-sc7180.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MSM SC7180 Display Port Controller.
+
+maintainers:
+  - Chandan Uddaraju 
+  - Vara Reddy 
+  - Tanmay Shah 
+
+description: |
+  Device tree bindings for DP host controller for MSM SC7180 target
+  that are compatible with VESA Display Port interface specification.
+
+allOf:
+  - $ref: dp-controller.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  - qcom,sc7180-dp
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 5
+
+  clock-names:
+items:
+  - const: core_iface
+  - const: core_aux
+  - const: ctrl_link
+  - const: ctrl_link_iface
+  - const: stream_pixel
+
+  "#clock-cells":
+const: 1
+
+  assigned-clocks:
+maxItems: 2
+  assigned-clock-parents:
+maxItems: 2
+
+  data-lanes:
+$ref: "/schemas/types.yaml#/definitions/uint32-array"
+minItems: 1
+maxItems: 4
+
+  vdda-1p2-supply:
+description: phandle to vdda 1.2V regulator node.
+
+  vdda-0p9-supply:
+description: phandle to vdda 0.9V regulator node.
+
+  ports:
+type: object
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+  port@1:
+type: object
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - assigned-clocks
+  - assigned-clock-parents
+  - vdda-1p2-supply
+  - vdda-0p9-supply
+  - data-lanes
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+msm_dp: displayport-controller@ae9{
+compatible = "qcom,sc7180-dp";
+reg = <0 0xae9 0 0x1400>;
+
+interrupt-parent = <>;
+interrupts = <12 IRQ_TYPE_NONE>;
+
+clocks = < DISP_CC_MDSS_AHB_CLK>,
+ < DISP_CC_MDSS_DP_AUX_CLK>,
+ < DISP_CC_MDSS_DP_LINK_CLK>,
+ < DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+ < DISP_CC_MDSS_DP_PIXEL_CLK>;
+clock-names = "core_iface", "core_aux",
+  "ctrl_link",
+  "ctrl_link_iface", "stream_pixel";
+#clock-cells = <1>;
+
+assigned-clocks = < DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+  < DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+assigned-clock-parents = <_phy 0>, <_phy 1>;
+
+vdda-1p2-supply = <_l3c_1p2>;
+vdda-0p9-supply = <_l4a_0p8>;
+
+data-lanes = <0 1>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dp_in: endpoint {
+ 

[PATCH 1/2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

2020-08-10 Thread Krishna Manikandan
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.

Signed-off-by: Krishna Manikandan 

Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
- Added empty line between different properties (Sam Ravnborg)
- Replaced reference txt files with  their corresponding
  yaml files (Sam Ravnborg)
- Modified the file to use "|" only when it is
  necessary (Sam Ravnborg)

Changes in v3:
- Corrected the license used (Rob Herring)
- Added maxItems for properties (Rob Herring)
- Dropped generic descriptions (Rob Herring)
- Added ranges property (Rob Herring)
- Corrected the indendation (Rob Herring)
- Added additionalProperties (Rob Herring)
- Split dsi file into two, one for dsi controller
  and another one for dsi phy per target (Rob Herring)
- Corrected description for pinctrl-names (Rob Herring)
- Corrected the examples used in yaml file (Rob Herring)
- Delete dsi.txt and dpu.txt (Rob Herring)

Changes in v4:
- Move schema up by one level (Rob Herring)
- Add patternProperties for mdp node (Rob Herring)
- Corrected description of some properties (Rob Herring)

Changes in v5:
- Correct the indentation (Rob Herring)
- Remove unnecessary description from properties (Rob Herring)
- Correct the number of interconnect entries (Rob Herring)
- Add interconnect names for sc7180 (Rob Herring)
- Add description for ports (Rob Herring)
- Remove common properties (Rob Herring)
- Add unevalutatedProperties (Rob Herring)
- Reference existing dsi controller yaml in the common
  dsi controller file (Rob Herring)
- Correct the description of clock names to include only the
  clocks that are required (Rob Herring)
- Remove properties which are already covered under the common
  binding (Rob Herring)
- Add dsi phy supply nodes which are required for sc7180 and
  sdm845 targets (Rob Herring)
- Add type ref for syscon-sfpb (Rob Herring)

Changes in v6:
- Fixed errors during dt_binding_check (Rob Herring)
- Add maxItems for phys and phys-names (Rob Herring)
- Use unevaluatedProperties wherever required (Rob Herring)
- Removed interrupt controller from required properties for
  dsi controller (Rob Herring)
- Add constraints for dsi-phy reg-names based on the compatible
  phy version (Rob Herring)
- Add constraints for dsi-phy supply nodes based on the
  compatible phy version (Rob Herring)

Changes in v7:
- Add default value for qcom,mdss-mdp-transfer-time-us (Rob Herring)
- Modify the schema for data-lanes (Rob Herring)
- Split the phy schema into separate schemas based on
  the phy version (Rob Herring)

Changes in v8:
- Resolve merge conflicts with latest dsi.txt file
- Include dp yaml change also in the same series
---
 .../bindings/display/msm/dpu-sc7180.yaml   | 236 +++
 .../bindings/display/msm/dpu-sdm845.yaml   | 216 ++
 .../devicetree/bindings/display/msm/dpu.txt| 141 
 .../display/msm/dsi-common-controller.yaml | 249 +
 .../display/msm/dsi-controller-sc7180.yaml | 120 ++
 .../display/msm/dsi-controller-sdm845.yaml | 120 ++
 .../bindings/display/msm/dsi-phy-10nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-14nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-20nm.yaml |  66 ++
 .../bindings/display/msm/dsi-phy-28nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
 .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
 .../devicetree/bindings/display/msm/dsi.txt| 247 
 13 files changed, 1355 insertions(+), 388 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-common-controller.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-s

[v7] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

2020-08-02 Thread Krishna Manikandan
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.

Signed-off-by: Krishna Manikandan 

Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
- Added empty line between different properties (Sam Ravnborg)
- Replaced reference txt files with  their corresponding
  yaml files (Sam Ravnborg)
- Modified the file to use "|" only when it is
  necessary (Sam Ravnborg)

Changes in v3:
- Corrected the license used (Rob Herring)
- Added maxItems for properties (Rob Herring)
- Dropped generic descriptions (Rob Herring)
- Added ranges property (Rob Herring)
- Corrected the indendation (Rob Herring)
- Added additionalProperties (Rob Herring)
- Split dsi file into two, one for dsi controller
  and another one for dsi phy per target (Rob Herring)
- Corrected description for pinctrl-names (Rob Herring)
- Corrected the examples used in yaml file (Rob Herring)
- Delete dsi.txt and dpu.txt (Rob Herring)

Changes in v4:
- Move schema up by one level (Rob Herring)
- Add patternProperties for mdp node (Rob Herring)
- Corrected description of some properties (Rob Herring)

Changes in v5:
- Correct the indentation (Rob Herring)
- Remove unnecessary description from properties (Rob Herring)
- Correct the number of interconnect entries (Rob Herring)
- Add interconnect names for sc7180 (Rob Herring)
- Add description for ports (Rob Herring)
- Remove common properties (Rob Herring)
- Add unevalutatedProperties (Rob Herring)
- Reference existing dsi controller yaml in the common
  dsi controller file (Rob Herring)
- Correct the description of clock names to include only the
  clocks that are required (Rob Herring)
- Remove properties which are already covered under the common
  binding (Rob Herring)
- Add dsi phy supply nodes which are required for sc7180 and
  sdm845 targets (Rob Herring)
- Add type ref for syscon-sfpb (Rob Herring)

Changes in v6:
- Fixed errors during dt_binding_check (Rob Herring)
- Add maxItems for phys and phys-names (Rob Herring)
- Use unevaluatedProperties wherever required (Rob Herring)
- Removed interrupt controller from required properties for
  dsi controller (Rob Herring)
- Add constraints for dsi-phy reg-names based on the compatible
  phy version (Rob Herring)
- Add constraints for dsi-phy supply nodes based on the
  compatible phy version (Rob Herring)

Changes in v7:
- Add default value for qcom,mdss-mdp-transfer-time-us (Rob Herring)
- Modify the schema for data-lanes (Rob Herring)
- Split the phy schema into separate schemas based on
  the phy version (Rob Herring)
---
 .../bindings/display/msm/dpu-sc7180.yaml   | 236 +++
 .../bindings/display/msm/dpu-sdm845.yaml   | 216 ++
 .../devicetree/bindings/display/msm/dpu.txt| 141 
 .../display/msm/dsi-common-controller.yaml | 249 +
 .../display/msm/dsi-controller-sc7180.yaml | 120 ++
 .../display/msm/dsi-controller-sdm845.yaml | 120 ++
 .../bindings/display/msm/dsi-phy-10nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-14nm.yaml |  61 +
 .../bindings/display/msm/dsi-phy-20nm.yaml |  66 ++
 .../bindings/display/msm/dsi-phy-28nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
 .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
 .../devicetree/bindings/display/msm/dsi.txt| 246 
 13 files changed, 1354 insertions(+), 387 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-common-controller.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt

diff --git a/Documentation/devicetree/bindin

[PATCH 3/7] i2c: tegra: add flag for register write buffering

2020-07-23 Thread Krishna Yarlagadda
In chips earlier to Tegra186, register write gets buffered. So to make
sure register writes are completed, there is need to readback the
register. Adding flag to disable this readback for Tegra186 and later
chips.

Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index a841d6c..bdbbca0 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -220,6 +220,7 @@ struct tegra_i2c_hw_feature {
bool has_mst_fifo;
const struct i2c_adapter_quirks *quirks;
bool supports_bus_clear;
+   bool has_reg_write_buffering;
bool has_apb_dma;
u8 tlow_std_mode;
u8 thigh_std_mode;
@@ -325,8 +326,11 @@ static void i2c_writel(struct tegra_i2c_dev *i2c_dev, u32 
val,
writel_relaxed(val, i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg));
 
/* Read back register to make sure that register writes completed */
-   if (reg != I2C_TX_FIFO)
-   readl_relaxed(i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg));
+   if (i2c_dev->hw->has_reg_write_buffering) {
+   if (reg != I2C_TX_FIFO)
+   readl_relaxed(i2c_dev->base +
+ tegra_i2c_reg_addr(i2c_dev, reg));
+   }
 }
 
 static u32 i2c_readl(struct tegra_i2c_dev *i2c_dev, unsigned long reg)
@@ -1450,6 +1454,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = 
{
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = false,
+   .has_reg_write_buffering = true,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1475,6 +1480,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = 
{
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = false,
+   .has_reg_write_buffering = true,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1500,6 +1506,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw 
= {
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = true,
+   .has_reg_write_buffering = true,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1525,6 +1532,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw 
= {
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = true,
+   .has_reg_write_buffering = true,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1550,6 +1558,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw 
= {
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = true,
+   .has_reg_write_buffering = true,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1575,6 +1584,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw 
= {
.has_mst_fifo = false,
.quirks = _i2c_quirks,
.supports_bus_clear = true,
+   .has_reg_write_buffering = false,
.has_apb_dma = false,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x3,
@@ -1600,6 +1610,7 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw 
= {
.has_mst_fifo = true,
.quirks = _i2c_quirks,
.supports_bus_clear = true,
+   .has_reg_write_buffering = false,
.has_apb_dma = false,
.tlow_std_mode = 0x8,
.thigh_std_mode = 0x7,
-- 
2.7.4



[PATCH 6/7] i2c: tegra: DMA support for t186 and t194

2020-07-23 Thread Krishna Yarlagadda
Enable GPC DMA support for Tegra186 and Tegra194

Signed-off-by: Rajesh Gumasta 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 8ab968e..77198fc 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -236,6 +236,7 @@ struct tegra_i2c_hw_feature {
u32 setup_hold_time_hs_mode;
bool has_interface_timing_reg;
bool has_slcg_support;
+   bool has_gpc_dma;
 };
 
 /**
@@ -432,11 +433,18 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev 
*i2c_dev)
dma_addr_t dma_phys;
int err;
 
-   if (!i2c_dev->hw->has_apb_dma)
-   return 0;
-
-   if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
-   dev_dbg(i2c_dev->dev, "Support for APB DMA not enabled!\n");
+   if (i2c_dev->hw->has_gpc_dma) {
+   if (!IS_ENABLED(CONFIG_TEGRA_GPC_DMA)) {
+   dev_dbg(i2c_dev->dev, "Support for GPC DMA not 
enabled!\n");
+   return 0;
+   }
+   } else if (i2c_dev->hw->has_apb_dma) {
+   if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
+   dev_dbg(i2c_dev->dev, "Support for APB DMA not 
enabled!\n");
+   return 0;
+   }
+   } else {
+   dev_dbg(i2c_dev->dev, "DMA is not enabled!\n");
return 0;
}
 
@@ -1490,6 +1498,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = 
{
.setup_hold_time_fast_fast_plus_mode = 0x0,
.setup_hold_time_hs_mode = 0x0,
.has_interface_timing_reg = false,
+   .has_gpc_dma = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
@@ -1519,6 +1528,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = 
{
.setup_hold_time_fast_fast_plus_mode = 0x0,
.setup_hold_time_hs_mode = 0x0,
.has_interface_timing_reg = false,
+   .has_gpc_dma = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
@@ -1548,6 +1558,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw 
= {
.setup_hold_time_fast_fast_plus_mode = 0x0,
.setup_hold_time_hs_mode = 0x0,
.has_interface_timing_reg = false,
+   .has_gpc_dma = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
@@ -1577,6 +1588,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw 
= {
.setup_hold_time_fast_fast_plus_mode = 0x0,
.setup_hold_time_hs_mode = 0x0,
.has_interface_timing_reg = true,
+   .has_gpc_dma = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
@@ -1606,6 +1618,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw 
= {
.setup_hold_time_fast_fast_plus_mode = 0,
.setup_hold_time_hs_mode = 0,
.has_interface_timing_reg = true,
+   .has_gpc_dma = true,
 };
 
 static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
@@ -1635,6 +1648,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw 
= {
.setup_hold_time_fast_fast_plus_mode = 0,
.setup_hold_time_hs_mode = 0,
.has_interface_timing_reg = true,
+   .has_gpc_dma = true,
 };
 
 static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
@@ -1664,6 +1678,7 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw 
= {
.setup_hold_time_fast_fast_plus_mode = 0x02020202,
.setup_hold_time_hs_mode = 0x090909,
.has_interface_timing_reg = true,
+   .has_gpc_dma = true,
 };
 
 /* Match table for of_platform binding */
-- 
2.7.4



[PATCH 2/7] i2c: tegra: Fix setting of controller ID

2020-07-23 Thread Krishna Yarlagadda
From: Shardar Shariff Md 

Assign controller id with adapter number as it (cont_id) is passed
through DT(through alias). Mask with controller id mask to avoid
overflow other fields when single device is present and id is -1.

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index c6c870c..a841d6c 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -83,6 +83,7 @@
 #define PACKET_HEADER0_CONT_ID GENMASK(15, 12)
 #define PACKET_HEADER0_PROTOCOLGENMASK(7, 4)
 #define PACKET_HEADER0_PROTOCOL_I2C1
+#define PACKET_HEADER0_CONT_ID_MASK0xF
 
 #define I2C_HEADER_CONT_ON_NAK BIT(21)
 #define I2C_HEADER_READBIT(19)
@@ -1669,7 +1670,6 @@ static int tegra_i2c_probe(struct platform_device *pdev)
i2c_dev->adapter.retries = 1;
i2c_dev->adapter.timeout = 6 * HZ;
i2c_dev->irq = irq;
-   i2c_dev->cont_id = pdev->id;
i2c_dev->dev = >dev;
 
i2c_dev->rst = devm_reset_control_get_exclusive(>dev, "i2c");
@@ -1807,6 +1807,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
if (ret)
goto release_dma;
 
+   i2c_dev->cont_id = i2c_dev->adapter.nr & PACKET_HEADER0_CONT_ID_MASK;
pm_runtime_put(>dev);
 
return 0;
-- 
2.7.4



[PATCH 7/7] i2c: tegra: dump I2C registers on timeout

2020-07-23 Thread Krishna Yarlagadda
From: Rajesh Gumasta 

Dump I2C regsiters for debug when transfer timeout occurs.

Signed-off-by: Rajesh Gumasta 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 77198fc..cdc8664 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -126,6 +126,8 @@
 #define  I2C_HS_INTERFACE_TIMING_THD_STA   GENMASK(13, 8)
 #define  I2C_HS_INTERFACE_TIMING_TSU_STA   GENMASK(5, 0)
 
+#define I2C_MST_PACKET_TRANSFER_CNT_STATUS 0x0b0
+
 #define I2C_MST_FIFO_CONTROL   0x0b4
 #define I2C_MST_FIFO_CONTROL_RX_FLUSH  BIT(0)
 #define I2C_MST_FIFO_CONTROL_TX_FLUSH  BIT(1)
@@ -1178,6 +1180,33 @@ static int tegra_i2c_issue_bus_clear(struct i2c_adapter 
*adap)
return -EAGAIN;
 }
 
+static void tegra_i2c_reg_dump(struct tegra_i2c_dev *i2c_dev)
+{
+   dev_dbg(i2c_dev->dev, "--- register dump for debugging \n");
+   dev_dbg(i2c_dev->dev, "I2C_CNFG - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_CNFG));
+   dev_dbg(i2c_dev->dev, "I2C_PACKET_TRANSFER_STATUS - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_PACKET_TRANSFER_STATUS));
+   dev_dbg(i2c_dev->dev, "I2C_FIFO_CONTROL - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_FIFO_CONTROL));
+   dev_dbg(i2c_dev->dev, "I2C_FIFO_STATUS - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_FIFO_STATUS));
+
+   if (i2c_dev->hw->has_mst_fifo) {
+   dev_dbg(i2c_dev->dev, "I2C_MST_FIFO_CONTROL - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_MST_FIFO_CONTROL));
+   dev_dbg(i2c_dev->dev, "I2C_MST_FIFO_STATUS - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_MST_FIFO_STATUS));
+   dev_dbg(i2c_dev->dev, "I2C_MST_PACKET_TRANSFER_CNT - 0x%x\n",
+   i2c_readl(i2c_dev,
+ I2C_MST_PACKET_TRANSFER_CNT_STATUS));
+   }
+   dev_dbg(i2c_dev->dev, "I2C_INT_MASK - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_INT_MASK));
+   dev_dbg(i2c_dev->dev, "I2C_INT_STATUS - 0x%x\n",
+   i2c_readl(i2c_dev, I2C_INT_STATUS));
+}
+
 static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
  struct i2c_msg *msg,
  enum msg_end_type end_state)
@@ -1331,6 +1360,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev 
*i2c_dev,
 
if (!time_left && !completion_done(_dev->dma_complete)) {
dev_err(i2c_dev->dev, "DMA transfer timeout\n");
+   tegra_i2c_reg_dump(i2c_dev);
tegra_i2c_init(i2c_dev, true);
return -ETIMEDOUT;
}
@@ -1352,6 +1382,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev 
*i2c_dev,
 
if (time_left == 0) {
dev_err(i2c_dev->dev, "i2c transfer timed out\n");
+   tegra_i2c_reg_dump(i2c_dev);
tegra_i2c_init(i2c_dev, true);
return -ETIMEDOUT;
}
-- 
2.7.4



[PATCH 5/7] i2c: tegra: enable second level clock gating

2020-07-23 Thread Krishna Yarlagadda
Enable Second Level Clock Gating feature for supported chips.
With SLCG enabled, software need not control clocks anymore
and leave clocks enabled always on.

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Laxman Dewangan 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 2f654ed..8ab968e 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -235,6 +235,7 @@ struct tegra_i2c_hw_feature {
u32 setup_hold_time_fast_fast_plus_mode;
u32 setup_hold_time_hs_mode;
bool has_interface_timing_reg;
+   bool has_slcg_support;
 };
 
 /**
@@ -299,6 +300,7 @@ struct tegra_i2c_dev {
struct completion dma_complete;
bool is_curr_atomic_xfer;
int clk_divisor_hs_mode;
+   bool is_clkon_always;
 };
 
 static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
@@ -1478,6 +1480,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = 
{
.supports_bus_clear = false,
.has_reg_write_buffering = true,
.has_hs_mode_support = false,
+   .has_slcg_support = false,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1506,6 +1509,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = 
{
.supports_bus_clear = false,
.has_reg_write_buffering = true,
.has_hs_mode_support = false,
+   .has_slcg_support = false,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1534,6 +1538,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw 
= {
.supports_bus_clear = true,
.has_reg_write_buffering = true,
.has_hs_mode_support = false,
+   .has_slcg_support = false,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1562,6 +1567,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw 
= {
.supports_bus_clear = true,
.has_reg_write_buffering = true,
.has_hs_mode_support = false,
+   .has_slcg_support = false,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1590,6 +1596,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw 
= {
.supports_bus_clear = true,
.has_reg_write_buffering = true,
.has_hs_mode_support = false,
+   .has_slcg_support = false,
.has_apb_dma = true,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x2,
@@ -1618,6 +1625,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw 
= {
.supports_bus_clear = true,
.has_reg_write_buffering = false,
.has_hs_mode_support = false,
+   .has_slcg_support = true,
.has_apb_dma = false,
.tlow_std_mode = 0x4,
.thigh_std_mode = 0x3,
@@ -1646,6 +1654,7 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw 
= {
.supports_bus_clear = true,
.has_reg_write_buffering = false,
.has_hs_mode_support = true,
+   .has_slcg_support = true,
.has_apb_dma = false,
.tlow_std_mode = 0x8,
.thigh_std_mode = 0x7,
@@ -1822,7 +1831,12 @@ static int tegra_i2c_probe(struct platform_device *pdev)
}
}
 
-   if (i2c_dev->is_multimaster_mode) {
+   if (i2c_dev->is_multimaster_mode || i2c_dev->hw->has_slcg_support)
+   i2c_dev->is_clkon_always = true;
+   else
+   i2c_dev->is_clkon_always = false;
+
+   if (i2c_dev->is_clkon_always) {
ret = clk_enable(i2c_dev->div_clk);
if (ret < 0) {
dev_err(i2c_dev->dev, "div_clk enable failed %d\n",
@@ -1875,7 +1889,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
tegra_i2c_release_dma(i2c_dev);
 
 disable_div_clk:
-   if (i2c_dev->is_multimaster_mode)
+   if (i2c_dev->is_clkon_always)
clk_disable(i2c_dev->div_clk);
 
 put_rpm:
@@ -1908,7 +1922,7 @@ static int tegra_i2c_remove(struct platform_device *pdev)
 
i2c_del_adapter(_dev->adapter);
 
-   if (i2c_dev->is_multimaster_mode)
+   if (i2c_dev->is_clkon_always)
clk_disable(i2c_dev->div_clk);
 
pm_runtime_disable(>dev);
@@ -1932,7 +1946,8 @@ static int __maybe_unused tegra_i2c_suspend(struct device 
*dev)
struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
int err = 0;
 
-   i2c_mark_adapter_suspended(_dev->adapter);
+   if (i2c_dev->is_clkon_always)
+   clk_disable(i2c_dev->div_clk);
 
if (!pm_runtime_status_suspended(dev))
err = tegra_i2c_runtime_suspend(dev);
@@ -1968,6 +1983,15 @@ static int __maybe_unused tegra_i2c_resume(struct device 
*dev)
   

[PATCH 4/7] i2c: tegra: add high speed mode support

2020-07-23 Thread Krishna Yarlagadda
From: Shardar Shariff Md 

Add high speed mode support

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Laxman Dewangan 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 64 --
 1 file changed, 56 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index bdbbca0..2f654ed 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -85,12 +85,14 @@
 #define PACKET_HEADER0_PROTOCOL_I2C1
 #define PACKET_HEADER0_CONT_ID_MASK0xF
 
+#define I2C_HEADER_HIGHSPEED_MODE  BIT(22)
 #define I2C_HEADER_CONT_ON_NAK BIT(21)
 #define I2C_HEADER_READBIT(19)
 #define I2C_HEADER_10BIT_ADDR  BIT(18)
 #define I2C_HEADER_IE_ENABLE   BIT(17)
 #define I2C_HEADER_REPEAT_STARTBIT(16)
 #define I2C_HEADER_CONTINUE_XFER   BIT(15)
+#define I2C_HEADER_MASTER_ADDR_SHIFT   12
 #define I2C_HEADER_SLAVE_ADDR_SHIFT1
 
 #define I2C_BUS_CLEAR_CNFG 0x084
@@ -136,6 +138,7 @@
 
 /* configuration load timeout in microseconds */
 #define I2C_CONFIG_LOAD_TIMEOUT100
+#define I2C_HS_MODE350
 
 /* Packet header size in bytes */
 #define I2C_PACKET_HEADER_SIZE 12
@@ -215,12 +218,14 @@ struct tegra_i2c_hw_feature {
int clk_divisor_std_mode;
int clk_divisor_fast_mode;
u16 clk_divisor_fast_plus_mode;
+   int clk_multiplier_hs_mode;
bool has_multi_master_mode;
bool has_slcg_override_reg;
bool has_mst_fifo;
const struct i2c_adapter_quirks *quirks;
bool supports_bus_clear;
bool has_reg_write_buffering;
+   bool has_hs_mode_support;
bool has_apb_dma;
u8 tlow_std_mode;
u8 thigh_std_mode;
@@ -293,6 +298,7 @@ struct tegra_i2c_dev {
bool is_curr_dma_xfer;
struct completion dma_complete;
bool is_curr_atomic_xfer;
+   int clk_divisor_hs_mode;
 };
 
 static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
@@ -778,8 +784,9 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, 
bool clk_reinit)
if (i2c_dev->is_dvc)
tegra_dvc_init(i2c_dev);
 
-   val = I2C_CNFG_NEW_MASTER_FSM | I2C_CNFG_PACKET_MODE_EN |
- FIELD_PREP(I2C_CNFG_DEBOUNCE_CNT, 2);
+   val = I2C_CNFG_NEW_MASTER_FSM | I2C_CNFG_PACKET_MODE_EN;
+   if (i2c_dev->bus_clk_rate != I2C_HS_MODE)
+   val |= FIELD_PREP(I2C_CNFG_DEBOUNCE_CNT, 0x2);
 
if (i2c_dev->hw->has_multi_master_mode)
val |= I2C_CNFG_MULTI_MASTER_MODE;
@@ -791,6 +798,13 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, 
bool clk_reinit)
tegra_i2c_vi_init(i2c_dev);
 
/* Make sure clock divisor programmed correctly */
+   if (i2c_dev->bus_clk_rate == I2C_HS_MODE) {
+   i2c_dev->clk_divisor_hs_mode = i2c_dev->hw->clk_divisor_hs_mode;
+   } else {
+   val = i2c_readl(i2c_dev, I2C_CLK_DIVISOR);
+   i2c_dev->clk_divisor_hs_mode = 
FIELD_PREP(I2C_CLK_DIVISOR_HSMODE, val);
+   }
+
clk_divisor = FIELD_PREP(I2C_CLK_DIVISOR_HSMODE,
 i2c_dev->hw->clk_divisor_hs_mode) |
  FIELD_PREP(I2C_CLK_DIVISOR_STD_FAST_MODE,
@@ -822,8 +836,13 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev, 
bool clk_reinit)
i2c_writel(i2c_dev, tsu_thd, I2C_INTERFACE_TIMING_1);
 
if (!clk_reinit) {
-   clk_multiplier = (tlow + thigh + 2);
-   clk_multiplier *= (i2c_dev->clk_divisor_non_hs_mode + 1);
+   if (i2c_dev->bus_clk_rate == I2C_HS_MODE) {
+   clk_multiplier = i2c_dev->hw->clk_multiplier_hs_mode;
+   clk_multiplier *= (i2c_dev->clk_divisor_hs_mode + 1);
+   } else {
+   clk_multiplier = (tlow + thigh + 2);
+   clk_multiplier *= (i2c_dev->clk_divisor_non_hs_mode + 
1);
+   }
err = clk_set_rate(i2c_dev->div_clk,
   i2c_dev->bus_clk_rate * clk_multiplier);
if (err) {
@@ -1244,6 +1263,8 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev 
*i2c_dev,
packet_header |= I2C_HEADER_CONT_ON_NAK;
if (msg->flags & I2C_M_RD)
packet_header |= I2C_HEADER_READ;
+   if (i2c_dev->bus_clk_rate == I2C_HS_MODE)
+   packet_header |= I2C_HEADER_HIGHSPEED_MODE;
if (dma && !i2c_dev->msg_read)
*buffer++ = packet_header;
else
@@ -1448,6 +1469,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = 
{
.clk_divisor_std_mode = 

[PATCH 1/7] i2c: tegra: remove dead code

2020-07-23 Thread Krishna Yarlagadda
From: Shardar Shariff Md 

When I2C_HEADER_CONT_ON_NAK bit in IO header is set then “No ACK
from slave” error is not reported (NACK is considered as ACK
and transfer is continued). So if I2C_ERR_NO_ACK is set, it would
imply I2C_M_IGNORE_NAK is not set and hence this code will never
execute. When I2C_HEADER_CONT_ON_NAK bit in IO header is set then
“No ACK from slave” error is not reported.
Condition (msg->flags & I2C_M_IGNORE_NAK) will never be hit

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/i2c/busses/i2c-tegra.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 1577296..c6c870c 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1336,11 +1336,8 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev 
*i2c_dev,
return -EAGAIN;
}
 
-   if (i2c_dev->msg_err == I2C_ERR_NO_ACK) {
-   if (msg->flags & I2C_M_IGNORE_NAK)
-   return 0;
+   if (i2c_dev->msg_err == I2C_ERR_NO_ACK)
return -EREMOTEIO;
-   }
 
return -EIO;
 }
-- 
2.7.4



[PATCH v2 2/2] reset: reset-zynqmp: Added support for Versal platform

2020-07-22 Thread Sai Krishna Potthuri
Updated the reset driver to support Versal platform.
As part of adding Versal support
- Added Versal specific compatible string.
- Reset Id and number of resets are different for Versal and ZynqMP,
hence taken care of these two based on compatible string.

Signed-off-by: Sai Krishna Potthuri 
---
 drivers/reset/reset-zynqmp.c | 50 +++-
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
index 373ea8d4f7a1..ebd433fa09dd 100644
--- a/drivers/reset/reset-zynqmp.c
+++ b/drivers/reset/reset-zynqmp.c
@@ -9,12 +9,20 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ZYNQMP_NR_RESETS (ZYNQMP_PM_RESET_END - ZYNQMP_PM_RESET_START)
 #define ZYNQMP_RESET_ID ZYNQMP_PM_RESET_START
+#define VERSAL_NR_RESETS   95
+
+struct zynqmp_reset_soc_data {
+   u32 reset_id;
+   u32 num_resets;
+};
 
 struct zynqmp_reset_data {
struct reset_controller_dev rcdev;
+   const struct zynqmp_reset_soc_data *data;
 };
 
 static inline struct zynqmp_reset_data *
@@ -26,23 +34,28 @@ to_zynqmp_reset_data(struct reset_controller_dev *rcdev)
 static int zynqmp_reset_assert(struct reset_controller_dev *rcdev,
   unsigned long id)
 {
-   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
+   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+   return zynqmp_pm_reset_assert(priv->data->reset_id + id,
  PM_RESET_ACTION_ASSERT);
 }
 
 static int zynqmp_reset_deassert(struct reset_controller_dev *rcdev,
 unsigned long id)
 {
-   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
+   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+   return zynqmp_pm_reset_assert(priv->data->reset_id + id,
  PM_RESET_ACTION_RELEASE);
 }
 
 static int zynqmp_reset_status(struct reset_controller_dev *rcdev,
   unsigned long id)
 {
+   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
int val, err;
 
-   err = zynqmp_pm_reset_get_status(ZYNQMP_RESET_ID + id, );
+   err = zynqmp_pm_reset_get_status(priv->data->reset_id + id, );
if (err)
return err;
 
@@ -52,10 +65,28 @@ static int zynqmp_reset_status(struct reset_controller_dev 
*rcdev,
 static int zynqmp_reset_reset(struct reset_controller_dev *rcdev,
  unsigned long id)
 {
-   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
+   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+   return zynqmp_pm_reset_assert(priv->data->reset_id + id,
  PM_RESET_ACTION_PULSE);
 }
 
+static int zynqmp_reset_of_xlate(struct reset_controller_dev *rcdev,
+const struct of_phandle_args *reset_spec)
+{
+   return reset_spec->args[0];
+}
+
+static const struct zynqmp_reset_soc_data zynqmp_reset_data = {
+   .reset_id = ZYNQMP_RESET_ID,
+   .num_resets = ZYNQMP_NR_RESETS,
+};
+
+static const struct zynqmp_reset_soc_data versal_reset_data = {
+.reset_id = 0,
+.num_resets = VERSAL_NR_RESETS,
+};
+
 static const struct reset_control_ops zynqmp_reset_ops = {
.reset = zynqmp_reset_reset,
.assert = zynqmp_reset_assert,
@@ -71,18 +102,25 @@ static int zynqmp_reset_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   priv->data = of_device_get_match_data(>dev);
+   if (!priv->data)
+   return -EINVAL;
+
platform_set_drvdata(pdev, priv);
 
priv->rcdev.ops = _reset_ops;
priv->rcdev.owner = THIS_MODULE;
priv->rcdev.of_node = pdev->dev.of_node;
-   priv->rcdev.nr_resets = ZYNQMP_NR_RESETS;
+   priv->rcdev.nr_resets = priv->data->num_resets;
+   priv->rcdev.of_reset_n_cells = 1;
+   priv->rcdev.of_xlate = zynqmp_reset_of_xlate;
 
return devm_reset_controller_register(>dev, >rcdev);
 }
 
 static const struct of_device_id zynqmp_reset_dt_ids[] = {
-   { .compatible = "xlnx,zynqmp-reset", },
+   { .compatible = "xlnx,zynqmp-reset", .data = _reset_data, },
+   { .compatible = "xlnx,versal-reset", .data = _reset_data, },
{ /* sentinel */ },
 };
 
-- 
2.17.1



[PATCH v2 0/2] reset: reset-zynqmp: Added Versal platform support

2020-07-22 Thread Sai Krishna Potthuri
Extended the ZynqMP reset driver to support Versal platform, accordingly
updated the dt-binding with the Versal platform specific information
like compatible string and reset indices.

Changes in v2:
 - Updated 1/2 patch commit description with some explanation about
reset indices.
 - 2/2 patch, Created SOC specific data structure and initialize the
const data based on of_device_get_match_data.
 - Defined driver specific of_xlate callback.

Sai Krishna Potthuri (2):
  dt-bindings: reset: Updated binding for Versal reset driver
  reset: reset-zynqmp: Added support for Versal platform

 .../bindings/reset/xlnx,zynqmp-reset.txt  |  11 +-
 drivers/reset/reset-zynqmp.c  |  50 -
 .../dt-bindings/reset/xlnx-versal-resets.h| 105 ++
 3 files changed, 156 insertions(+), 10 deletions(-)
 create mode 100644 include/dt-bindings/reset/xlnx-versal-resets.h

-- 
2.17.1



[PATCH v2 1/2] dt-bindings: reset: Updated binding for Versal reset driver

2020-07-22 Thread Sai Krishna Potthuri
Added documentation and Versal reset indices to describe
about Versal reset driver bindings.
In Versal all reset indices includes Class, SubClass, Type, Index
information whereas class refers to clock, reset, power etc.,
Underlying firmware in Versal have such classification and expects
the ID to be this way.
[13:0] - Index bits
[19:14] - Type bits
[25:20] - SubClass bits
[31:26] - Class bits.

Signed-off-by: Sai Krishna Potthuri 
---
 .../bindings/reset/xlnx,zynqmp-reset.txt  |  11 +-
 .../dt-bindings/reset/xlnx-versal-resets.h| 105 ++
 2 files changed, 112 insertions(+), 4 deletions(-)
 create mode 100644 include/dt-bindings/reset/xlnx-versal-resets.h

diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt 
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
index 27a45fe5ecf1..ed836868dbf1 100644
--- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -1,7 +1,7 @@
 --
- =  Zynq UltraScale+ MPSoC reset driver binding =
+ =  Zynq UltraScale+ MPSoC and Versal reset driver binding =
 --
-The Zynq UltraScale+ MPSoC has several different resets.
+The Zynq UltraScale+ MPSoC and Versal has several different resets.
 
 See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
 about zynqmp resets.
@@ -10,7 +10,8 @@ Please also refer to reset.txt in this directory for common 
reset
 controller binding usage.
 
 Required Properties:
-- compatible:  "xlnx,zynqmp-reset"
+- compatible:  "xlnx,zynqmp-reset" for Zynq UltraScale+ MPSoC platform
+   "xlnx,versal-reset" for Versal platform
 - #reset-cells:Specifies the number of cells needed to encode reset
line, should be 1
 
@@ -37,8 +38,10 @@ Device nodes that need access to reset lines should
 specify them as a reset phandle in their corresponding node as
 specified in reset.txt.
 
-For list of all valid reset indicies see
+For list of all valid reset indices for Zynq UltraScale+ MPSoC see
 
+For list of all valid reset indices for Versal see
+
 
 Example:
 
diff --git a/include/dt-bindings/reset/xlnx-versal-resets.h 
b/include/dt-bindings/reset/xlnx-versal-resets.h
new file mode 100644
index ..895424e9b0e5
--- /dev/null
+++ b/include/dt-bindings/reset/xlnx-versal-resets.h
@@ -0,0 +1,105 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_VERSAL_RESETS_H
+#define _DT_BINDINGS_VERSAL_RESETS_H
+
+#define VERSAL_RST_PMC_POR (0xc30c001U)
+#define VERSAL_RST_PMC (0xc410002U)
+#define VERSAL_RST_PS_POR  (0xc30c003U)
+#define VERSAL_RST_PL_POR  (0xc30c004U)
+#define VERSAL_RST_NOC_POR (0xc30c005U)
+#define VERSAL_RST_FPD_POR (0xc30c006U)
+#define VERSAL_RST_ACPU_0_POR  (0xc30c007U)
+#define VERSAL_RST_ACPU_1_POR  (0xc30c008U)
+#define VERSAL_RST_OCM2_POR(0xc30c009U)
+#define VERSAL_RST_PS_SRST (0xc41000aU)
+#define VERSAL_RST_PL_SRST (0xc41000bU)
+#define VERSAL_RST_NOC (0xc41000cU)
+#define VERSAL_RST_NPI (0xc41000dU)
+#define VERSAL_RST_SYS_RST_1   (0xc41000eU)
+#define VERSAL_RST_SYS_RST_2   (0xc41000fU)
+#define VERSAL_RST_SYS_RST_3   (0xc410010U)
+#define VERSAL_RST_FPD (0xc410011U)
+#define VERSAL_RST_PL0 (0xc410012U)
+#define VERSAL_RST_PL1 (0xc410013U)
+#define VERSAL_RST_PL2 (0xc410014U)
+#define VERSAL_RST_PL3 (0xc410015U)
+#define VERSAL_RST_APU (0xc410016U)
+#define VERSAL_RST_ACPU_0  (0xc410017U)
+#define VERSAL_RST_ACPU_1  (0xc410018U)
+#define VERSAL_RST_ACPU_L2 (0xc410019U)
+#define VERSAL_RST_ACPU_GIC(0xc41001aU)
+#define VERSAL_RST_RPU_ISLAND  (0xc41001bU)
+#define VERSAL_RST_RPU_AMBA(0xc41001cU)
+#define VERSAL_RST_R5_0(0xc41001dU)
+#define VERSAL_RST_R5_1(0xc41001eU)
+#define VERSAL_RST_SYSMON_PMC_SEQ_RST  (0xc41001fU)
+#define VERSAL_RST_SYSMON_PMC_CFG_RST  (0xc410020U)
+#define VERSAL_RST_SYSMON_FPD_CFG_RST  (0xc410021U)
+#define VERSAL_RST_SYSMON_FPD_SEQ_RST  (0xc410022U)
+#define VERSAL_RST_SYSMON_LPD  (0xc410023U)
+#define VERSAL_RST_PDMA_RST1   (0xc410024U)
+#define VERSAL_RST_PDMA_RST0   (0xc410

RE: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal reset driver

2020-07-21 Thread Sai Krishna Potthuri
Hi Rob,

Thanks for the review

> -Original Message-
> From: Rob Herring 
> Sent: Tuesday, July 21, 2020 7:38 AM
> To: Sai Krishna Potthuri 
> Cc: Philipp Zabel ; Michal Simek
> ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; git
> ; saikrishna12...@gmail.com
> Subject: Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal reset
> driver
> 
> On Tue, Jul 14, 2020 at 11:59:08AM +0530, Sai Krishna Potthuri wrote:
> > Added documentation and Versal reset indices to describe about Versal
> > reset driver bindings.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  .../bindings/reset/xlnx,zynqmp-reset.txt  |  11 +-
> >  .../dt-bindings/reset/xlnx-versal-resets.h| 105 ++
> >  2 files changed, 112 insertions(+), 4 deletions(-)  create mode
> > 100644 include/dt-bindings/reset/xlnx-versal-resets.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
> > b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
> > index 27a45fe5ecf1..ed836868dbf1 100644
> > --- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
> > +++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
> > @@ -1,7 +1,7 @@
> >
> > --
> > 
> > - =  Zynq UltraScale+ MPSoC reset driver binding =
> > + =  Zynq UltraScale+ MPSoC and Versal reset driver binding =
> >
> > --
> >  -The Zynq UltraScale+ MPSoC has several different resets.
> > +The Zynq UltraScale+ MPSoC and Versal has several different resets.
> >
> >  See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more
> > information  about zynqmp resets.
> > @@ -10,7 +10,8 @@ Please also refer to reset.txt in this directory for
> > common reset  controller binding usage.
> >
> >  Required Properties:
> > -- compatible:  "xlnx,zynqmp-reset"
> > +- compatible:  "xlnx,zynqmp-reset" for Zynq UltraScale+ MPSoC
> platform
> > +   "xlnx,versal-reset" for Versal platform
> >  - #reset-cells:Specifies the number of cells needed to encode reset
> > line, should be 1
> >
> > @@ -37,8 +38,10 @@ Device nodes that need access to reset lines should
> > specify them as a reset phandle in their corresponding node as
> > specified in reset.txt.
> >
> > -For list of all valid reset indicies see
> > +For list of all valid reset indices for Zynq UltraScale+ MPSoC see
> >  
> > +For list of all valid reset indices for Versal see
> > +
> >
> >  Example:
> >
> > diff --git a/include/dt-bindings/reset/xlnx-versal-resets.h
> > b/include/dt-bindings/reset/xlnx-versal-resets.h
> > new file mode 100644
> > index ..895424e9b0e5
> > --- /dev/null
> > +++ b/include/dt-bindings/reset/xlnx-versal-resets.h
> > @@ -0,0 +1,105 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + *  Copyright (C) 2020 Xilinx, Inc.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_VERSAL_RESETS_H
> > +#define _DT_BINDINGS_VERSAL_RESETS_H
> > +
> > +#define VERSAL_RST_PMC_POR     (0xc30c001U)
> 
> Perhaps some explanation on the numbering as ZynqMP seems to be just an
> index.
In versal, all ID's includes Class, SubClass, Type, Index information whereas 
class
refers to clock, reset, power etc., Underlying firmware in Versal have such
classification and expects the ID to be this way.
[13:0] - Index bits
[19:14] - Type bits
[25:20] - SubClass bits
[31:26] - Class bits
I will add this information in this file in v2.

Regards
Sai Krishna
> 
> > +#define VERSAL_RST_PMC (0xc410002U)
> > +#define VERSAL_RST_PS_POR  (0xc30c003U)
> > +#define VERSAL_RST_PL_POR  (0xc30c004U)
> > +#define VERSAL_RST_NOC_POR (0xc30c005U)
> > +#define VERSAL_RST_FPD_POR (0xc30c006U)
> > +#define VERSAL_RST_ACPU_0_POR  (0xc30c007U)
> > +#define VERSAL_RST_ACPU_1_POR  (0xc30c008U)
> > +#define VERSAL_RST_OCM2_POR(0xc30c009U)
> > +#define VERSAL_RST_PS_SRST (0xc41000aU)
> > +#define VERSAL_RST_PL_SRST (0xc41000bU)
> > +#define VERSAL_RST_NOC (0xc41000cU)
> > +#define VERSAL_RST_NPI (0xc41000dU)
> > +#define

RE: [PATCH 2/2] reset: reset-zynqmp: Added support for Versal platform

2020-07-20 Thread Sai Krishna Potthuri
Hi Philipp,

Thanks for the review.

> -Original Message-
> From: Philipp Zabel 
> Sent: Monday, July 20, 2020 3:18 PM
> To: Sai Krishna Potthuri ; Rob Herring
> ; Michal Simek 
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; git ; saikrishna12...@gmail.com
> Subject: Re: [PATCH 2/2] reset: reset-zynqmp: Added support for Versal
> platform
> 
> On Tue, 2020-07-14 at 11:59 +0530, Sai Krishna Potthuri wrote:
> > Updated the reset driver to support Versal platform.
> > As part of adding Versal support
> > - Added Versal specific compatible string.
> > - Reset Id and number of resets are different for Versal and ZynqMP,
> > hence taken care of these two based on compatible string.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > 
> > ---
> >  drivers/reset/reset-zynqmp.c | 24 
> >  1 file changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/reset/reset-zynqmp.c
> > b/drivers/reset/reset-zynqmp.c index 373ea8d4f7a1..17aa4532ec5e
> 100644
> > --- a/drivers/reset/reset-zynqmp.c
> > +++ b/drivers/reset/reset-zynqmp.c
> > @@ -12,9 +12,11 @@
> >
> >  #define ZYNQMP_NR_RESETS (ZYNQMP_PM_RESET_END -
> > ZYNQMP_PM_RESET_START)  #define ZYNQMP_RESET_ID
> ZYNQMP_PM_RESET_START
> > +#define VERSAL_NR_RESETS   95
> >
> >  struct zynqmp_reset_data {
> > struct reset_controller_dev rcdev;
> > +   u32 reset_id;
> >  };
> >
> >  static inline struct zynqmp_reset_data * @@ -26,23 +28,28 @@
> > to_zynqmp_reset_data(struct reset_controller_dev *rcdev)  static int
> > zynqmp_reset_assert(struct reset_controller_dev *rcdev,
> >unsigned long id)
> >  {
> > -   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
> > +   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> > +
> > +   return zynqmp_pm_reset_assert(priv->reset_id + id,
> >   PM_RESET_ACTION_ASSERT);
> >  }
> >
> >  static int zynqmp_reset_deassert(struct reset_controller_dev *rcdev,
> >  unsigned long id)
> >  {
> > -   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
> > +   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> > +
> > +   return zynqmp_pm_reset_assert(priv->reset_id + id,
> >   PM_RESET_ACTION_RELEASE);
> >  }
> >
> >  static int zynqmp_reset_status(struct reset_controller_dev *rcdev,
> >unsigned long id)
> >  {
> > +   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> > int val, err;
> >
> > -   err = zynqmp_pm_reset_get_status(ZYNQMP_RESET_ID + id, );
> > +   err = zynqmp_pm_reset_get_status(priv->reset_id + id, );
> > if (err)
> > return err;
> >
> > @@ -52,7 +59,9 @@ static int zynqmp_reset_status(struct
> > reset_controller_dev *rcdev,  static int zynqmp_reset_reset(struct
> reset_controller_dev *rcdev,
> >   unsigned long id)
> >  {
> > -   return zynqmp_pm_reset_assert(ZYNQMP_RESET_ID + id,
> > +   struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> > +
> > +   return zynqmp_pm_reset_assert(priv->reset_id + id,
> >   PM_RESET_ACTION_PULSE);
> >  }
> >
> > @@ -76,13 +85,20 @@ static int zynqmp_reset_probe(struct
> platform_device *pdev)
> > priv->rcdev.ops = _reset_ops;
> > priv->rcdev.owner = THIS_MODULE;
> > priv->rcdev.of_node = pdev->dev.of_node;
> > +   priv->reset_id = ZYNQMP_RESET_ID;
> > priv->rcdev.nr_resets = ZYNQMP_NR_RESETS;
> > +   if (of_device_is_compatible(pdev->dev.of_node,
> > +   "xlnx,versal-reset")) {
> 
> It would be better to use of_match_device and static const initalization data
> for this.
Will create soc specific initialization data structure and assign based on
of_device_get_match_data().

> 
> > +   priv->reset_id = 0;
> > +   priv->rcdev.nr_resets = VERSAL_NR_RESETS;
> 
> This won't work. All your reset ids are greater than 95, and this driver is 
> using
> the default of_xlate callback, so of_reset_simple_xlate will fail all reset
> control requests with -EINVAL.
Will create of_xlate callback that will simply return the reset line number
without any checks. We have underlying secure library which will validate
the reset line number.

Regards
Sai Krishna
> 
> regards
> Philipp


[PATCH v11 1/5] iommu/arm-smmu: move TLB timeout and spin count macros

2020-07-18 Thread Krishna Reddy
Move TLB timeout and spin count macros to header file to
allow using the same from vendor specific implementations.

Reviewed-by: Jon Hunter 
Reviewed-by: Nicolin Chen 
Reviewed-by: Pritesh Raithatha 
Reviewed-by: Robin Murphy 
Reviewed-by: Thierry Reding 
Signed-off-by: Krishna Reddy 
---
 drivers/iommu/arm-smmu.c | 3 ---
 drivers/iommu/arm-smmu.h | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 19f906de6420..cdd15ead9bc4 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,9 +52,6 @@
  */
 #define QCOM_DUMMY_VAL -1
 
-#define TLB_LOOP_TIMEOUT   100 /* 1s! */
-#define TLB_SPIN_COUNT 10
-
 #define MSI_IOVA_BASE  0x800
 #define MSI_IOVA_LENGTH0x10
 
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index d172c024be61..c7d0122a7c6c 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -236,6 +236,8 @@ enum arm_smmu_cbar_type {
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS   128
 
+#define TLB_LOOP_TIMEOUT   100 /* 1s! */
+#define TLB_SPIN_COUNT 10
 
 /* Shared driver definitions */
 enum arm_smmu_arch_version {
-- 
2.26.2



[PATCH v11 5/5] iommu/arm-smmu: Add global/context fault implementation hooks

2020-07-18 Thread Krishna Reddy
Add global/context fault hooks to allow vendor specific implementations
override default fault interrupt handlers.

Update NVIDIA implementation to override the default global/context fault
interrupt handlers and handle interrupts across the two ARM MMU-500s that
are programmed identically.

Reviewed-by: Jon Hunter 
Reviewed-by: Nicolin Chen 
Reviewed-by: Pritesh Raithatha 
Reviewed-by: Robin Murphy 
Reviewed-by: Thierry Reding 
Signed-off-by: Krishna Reddy 
---
 drivers/iommu/arm-smmu-nvidia.c | 99 +
 drivers/iommu/arm-smmu.c| 17 +-
 drivers/iommu/arm-smmu.h|  3 +
 3 files changed, 117 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index 2f55e5793d34..31368057e9be 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -127,6 +127,103 @@ static int nvidia_smmu_reset(struct arm_smmu_device *smmu)
return 0;
 }
 
+static irqreturn_t nvidia_smmu_global_fault_inst(int irq,
+struct arm_smmu_device *smmu,
+int inst)
+{
+   u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+   void __iomem *gr0_base = nvidia_smmu_page(smmu, inst, 0);
+
+   gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR);
+   if (!gfsr)
+   return IRQ_NONE;
+
+   gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0);
+   gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1);
+   gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
+
+   dev_err_ratelimited(smmu->dev,
+   "Unexpected global fault, this could be serious\n");
+   dev_err_ratelimited(smmu->dev,
+   "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, 
GFSYNR2 0x%08x\n",
+   gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+   writel_relaxed(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t nvidia_smmu_global_fault(int irq, void *dev)
+{
+   unsigned int inst;
+   irqreturn_t ret = IRQ_NONE;
+   struct arm_smmu_device *smmu = dev;
+
+   for (inst = 0; inst < NUM_SMMU_INSTANCES; inst++) {
+   irqreturn_t irq_ret;
+
+   irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
+   if (irq_ret == IRQ_HANDLED)
+   ret = IRQ_HANDLED;
+   }
+
+   return ret;
+}
+
+static irqreturn_t nvidia_smmu_context_fault_bank(int irq,
+ struct arm_smmu_device *smmu,
+ int idx, int inst)
+{
+   u32 fsr, fsynr, cbfrsynra;
+   unsigned long iova;
+   void __iomem *gr1_base = nvidia_smmu_page(smmu, inst, 1);
+   void __iomem *cb_base = nvidia_smmu_page(smmu, inst, smmu->numpage + 
idx);
+
+   fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
+   if (!(fsr & ARM_SMMU_FSR_FAULT))
+   return IRQ_NONE;
+
+   fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
+   iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
+   cbfrsynra = readl_relaxed(gr1_base + ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+   dev_err_ratelimited(smmu->dev,
+   "Unhandled context fault: fsr=0x%x, iova=0x%08lx, 
fsynr=0x%x, cbfrsynra=0x%x, cb=%d\n",
+   fsr, iova, fsynr, cbfrsynra, idx);
+
+   writel_relaxed(fsr, cb_base + ARM_SMMU_CB_FSR);
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t nvidia_smmu_context_fault(int irq, void *dev)
+{
+   int idx;
+   unsigned int inst;
+   irqreturn_t ret = IRQ_NONE;
+   struct arm_smmu_device *smmu;
+   struct iommu_domain *domain = dev;
+   struct arm_smmu_domain *smmu_domain;
+
+   smmu_domain = container_of(domain, struct arm_smmu_domain, domain);
+   smmu = smmu_domain->smmu;
+
+   for (inst = 0; inst < NUM_SMMU_INSTANCES; inst++) {
+   irqreturn_t irq_ret;
+
+   /*
+* Interrupt line is shared between all contexts.
+* Check for faults across all contexts.
+*/
+   for (idx = 0; idx < smmu->num_context_banks; idx++) {
+   irq_ret = nvidia_smmu_context_fault_bank(irq, smmu,
+idx, inst);
+   if (irq_ret == IRQ_HANDLED)
+   ret = IRQ_HANDLED;
+   }
+   }
+
+   return ret;
+}
+
 static const struct arm_smmu_impl nvidia_smmu_impl = {
.read_reg = nvidia_smmu_read_reg,
.write_reg = nvidia_smmu_write_reg,
@@ -134,6 +231,8 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
.write_reg64 = nvidia_smmu_write_reg64,
.reset = nvidia_smmu_reset,
.tlb_sync = nvidia_sm

  1   2   3   4   5   6   7   8   9   10   >