Re: [PATCH v2] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-04-01 Thread Jolly Shah
Hi Luojiaxing,


On Mon, Mar 22, 2021 at 1:41 AM luojiaxing  wrote:
>
>
> On 2021/3/20 20:14, John Garry wrote:
> > On 19/03/2021 01:43, Jason Yan wrote:
> >>
> >>
> >> 在 2021/3/19 6:56, Jolly Shah 写道:
> >>> When the cache_type for the scsi device is changed, the scsi layer
> >>> issues a MODE_SELECT command. The caching mode details are communicated
> >>> via a request buffer associated with the scsi command with data
> >>> direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
> >>> reaches the libata layer, as a part of generic initial setup, libata
> >>> layer sets up the scatterlist for the command using the scsi command
> >>> (ata_scsi_qc_new). This command is then translated by the libata layer
> >>> into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
> >>> treats this as a non data command (ata_mselect_caching), since it only
> >>> needs an ata taskfile to pass the caching on/off information to the
> >>> device. It does not need the scatterlist that has been setup, so it
> >>> does
> >>> not perform dma_map_sg on the scatterlist (ata_qc_issue).
> >>> Unfortunately,
> >>> when this command reaches the libsas layer(sas_ata_qc_issue), libsas
> >>> layer sees it as a non data command with a scatterlist. It cannot
> >>> extract the correct dma length, since the scatterlist has not been
> >>> mapped with dma_map_sg for a DMA operation. When this partially
> >>> constructed SAS task reaches pm80xx LLDD, it results in below warning.
> >>>
> >>> "pm80xx_chip_sata_req 6058: The sg list address
> >>> start_addr=0x data_len=0x0end_addr_high=0x
> >>> end_addr_low=0x has crossed 4G boundary"
> >>>
> >>> This patch updates code to handle ata non data commands separately so
> >>> num_scatter and total_xfer_len remain 0.
> >>>
> >>> Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if
> >>> libata marks qc as NODATA")
> >>> Signed-off-by: Jolly Shah 
> >
> > Reviewed-by: John Garry 
> >
> > @luojiaxing, can you please test this?
>
>
> Sure, let me take a look, and reply the test result here later
>

Wanted to follow up on test results. Any updates?

Thanks,
Jolly

>
> Thanks
>
> Jiaxing
>
>
> >
> >>> ---
> >>> v2:
> >>> - reorganized code to avoid setting num_scatter twice
> >>>
> >>>   drivers/scsi/libsas/sas_ata.c | 9 -
> >>>   1 file changed, 4 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/scsi/libsas/sas_ata.c
> >>> b/drivers/scsi/libsas/sas_ata.c
> >>> index 024e5a550759..8b9a39077dba 100644
> >>> --- a/drivers/scsi/libsas/sas_ata.c
> >>> +++ b/drivers/scsi/libsas/sas_ata.c
> >>> @@ -201,18 +201,17 @@ static unsigned int sas_ata_qc_issue(struct
> >>> ata_queued_cmd *qc)
> >>>   memcpy(task->ata_task.atapi_packet, qc->cdb,
> >>> qc->dev->cdb_len);
> >>>   task->total_xfer_len = qc->nbytes;
> >>>   task->num_scatter = qc->n_elem;
> >>> +task->data_dir = qc->dma_dir;
> >>> +} else if (qc->tf.protocol == ATA_PROT_NODATA) {
> >>> +task->data_dir = DMA_NONE;
> >>
> >> Hi Jolly & John,
> >>
> >> We only set DMA_NONE for ATA_PROT_NODATA, I'm curious about why
> >> ATA_PROT_NCQ_NODATA and ATAPI_PROT_NODATA do not need to set DMA_NONE?
> >
> > So we can see something like atapi_eh_tur() -> ata_exec_internal(),
> > which is a ATAPI NONDATA and has DMA_NONE, so should be ok.
> >
> > Other cases, like those using the xlate function on the qc for
> > ATA_PROT_NCQ_NODATA, could be checked further.
> >
> > For now, we're just trying to fix the fix.
> >
> >>
> >> Thanks,
> >> Jason
> >>
> >>
> >>>   } else {
> >>>   for_each_sg(qc->sg, sg, qc->n_elem, si)
> >>>   xfer += sg_dma_len(sg);
> >>>   task->total_xfer_len = xfer;
> >>>   task->num_scatter = si;
> >>> -}
> >>> -
> >>> -if (qc->tf.protocol == ATA_PROT_NODATA)
> >>> -task->data_dir = DMA_NONE;
> >>> -else
> >>>   task->data_dir = qc->dma_dir;
> >>> +}
> >>>   task->scatter = qc->sg;
> >>>   task->ata_task.retry_count = 1;
> >>>   task->task_state_flags = SAS_TASK_STATE_PENDING;
> >>>
> >> .
> >
> >
> > .
> >
>


Re: [PATCH] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-03-18 Thread Jolly Shah
Hi John,


On Thu, Mar 18, 2021 at 9:19 AM John Garry  wrote:
>
> On 18/03/2021 00:24, Jolly Shah wrote:
> > Hi John,
> >
> > Thanks for the review.
> >
> >
> > On Wed, Mar 17, 2021 at 4:44 AM John Garry  wrote:
> >>
> >> On 16/03/2021 19:39, Jolly Shah wrote:
> >>> When the cache_type for the scsi device is changed, the scsi layer
> >>> issues a MODE_SELECT command. The caching mode details are communicated
> >>> via a request buffer associated with the scsi command with data
> >>> direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
> >>> reaches the libata layer, as a part of generic initial setup, libata
> >>> layer sets up the scatterlist for the command using the scsi command
> >>> (ata_scsi_qc_new). This command is then translated by the libata layer
> >>> into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
> >>> treats this as a non data command (ata_mselect_caching), since it only
> >>> needs an ata taskfile to pass the caching on/off information to the
> >>> device. It does not need the scatterlist that has been setup, so it does
> >>> not perform dma_map_sg on the scatterlist (ata_qc_issue).
> >>
> >> So if we don't perform the dma_map_sg() on the sgl at this point, then
> >> it seems to me that we should not perform for_each_sg() on it either,
> >> right? That is still what happens in sas_ata_qc_issue() in this case.
> >>
>
> Hi Jolly Shah,
>
> >
> > Yes that's right. To avoid that, I can add elseif block for
> > ATA_PROT_NODATA before for_each_sg() is performed. Currently there's
> > existing code block for ATA_PROT_NODATA after for_each_sg()  is
> > performed,
> > reused that to reset num_scatter. Please suggest.
> >
>
> How about just combine the 2x if-else statements into 1x if-elif-else
> statement, like:
>
>
> if (ata_is_atapi(qc->tf.protocol)) {
> memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);
> task->total_xfer_len = qc->nbytes;
> task->num_scatter = qc->n_elem;
> task->data_dir = qc->dma_dir;
> } else if (qc->tf.protocol == ATA_PROT_NODATA) {
> task->data_dir = DMA_NONE;
> } else {
> for_each_sg(qc->sg, sg, qc->n_elem, si)
> xfer += sg_dma_len(sg);
>
> task->total_xfer_len = xfer;
> task->num_scatter = si;
> task->data_dir = qc->dma_dir;
> }
>
Updated in v2.

> >>> Unfortunately,
> >>> when this command reaches the libsas layer(sas_ata_qc_issue), libsas
> >>> layer sees it as a non data command with a scatterlist. It cannot
> >>> extract the correct dma length, since the scatterlist has not been
> >>> mapped with dma_map_sg for a DMA operation. When this partially
> >>> constructed SAS task reaches pm80xx LLDD, it results in below warning.
> >>>
> >>> "pm80xx_chip_sata_req 6058: The sg list address
> >>> start_addr=0x data_len=0x0end_addr_high=0x
> >>> end_addr_low=0x has crossed 4G boundary"
> >>>
> >>> This patch assigns appropriate value to  num_sectors for ata non data
> >>> commands.
> >>>
> >>> Signed-off-by: Jolly Shah 
> >>> ---
> >>>drivers/scsi/libsas/sas_ata.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
> >>> index 024e5a550759..94ec08cebbaa 100644
> >>> --- a/drivers/scsi/libsas/sas_ata.c
> >>> +++ b/drivers/scsi/libsas/sas_ata.c
> >>> @@ -209,10 +209,12 @@ static unsigned int sas_ata_qc_issue(struct 
> >>> ata_queued_cmd *qc)
> >>>task->num_scatter = si;
> >>>}
> >>>
> >>> - if (qc->tf.protocol == ATA_PROT_NODATA)
> >>> + if (qc->tf.protocol == ATA_PROT_NODATA) {
> >>>task->data_dir = DMA_NONE;
> >>> - else
> >>> + task->num_scatter = 0;
> >>
> >> task->num_scatter has already been set in this function. Best not set it
> >> twice.
> >>
> >
> > Sure. Please suggest if I should update patch to above suggested
> > approach. That will avoid setting num_scatter twice.
> >
>
> Thanks,
> John
>
> BTW, could we add a fixes tag?

Added in v2.

Thanks,
Jolly


[PATCH v2] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-03-18 Thread Jolly Shah
When the cache_type for the scsi device is changed, the scsi layer
issues a MODE_SELECT command. The caching mode details are communicated
via a request buffer associated with the scsi command with data
direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
reaches the libata layer, as a part of generic initial setup, libata
layer sets up the scatterlist for the command using the scsi command
(ata_scsi_qc_new). This command is then translated by the libata layer
into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
treats this as a non data command (ata_mselect_caching), since it only
needs an ata taskfile to pass the caching on/off information to the
device. It does not need the scatterlist that has been setup, so it does
not perform dma_map_sg on the scatterlist (ata_qc_issue). Unfortunately,
when this command reaches the libsas layer(sas_ata_qc_issue), libsas
layer sees it as a non data command with a scatterlist. It cannot
extract the correct dma length, since the scatterlist has not been
mapped with dma_map_sg for a DMA operation. When this partially
constructed SAS task reaches pm80xx LLDD, it results in below warning.

"pm80xx_chip_sata_req 6058: The sg list address
start_addr=0x data_len=0x0end_addr_high=0x
end_addr_low=0x has crossed 4G boundary"

This patch updates code to handle ata non data commands separately so
num_scatter and total_xfer_len remain 0.

Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if libata marks qc 
as NODATA")
Signed-off-by: Jolly Shah 
---
v2:
- reorganized code to avoid setting num_scatter twice

 drivers/scsi/libsas/sas_ata.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 024e5a550759..8b9a39077dba 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -201,18 +201,17 @@ static unsigned int sas_ata_qc_issue(struct 
ata_queued_cmd *qc)
memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);
task->total_xfer_len = qc->nbytes;
task->num_scatter = qc->n_elem;
+   task->data_dir = qc->dma_dir;
+   } else if (qc->tf.protocol == ATA_PROT_NODATA) {
+   task->data_dir = DMA_NONE;
} else {
for_each_sg(qc->sg, sg, qc->n_elem, si)
xfer += sg_dma_len(sg);
 
task->total_xfer_len = xfer;
task->num_scatter = si;
-   }
-
-   if (qc->tf.protocol == ATA_PROT_NODATA)
-   task->data_dir = DMA_NONE;
-   else
task->data_dir = qc->dma_dir;
+   }
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;
-- 
2.31.0.rc2.261.g7f71774620-goog



Re: [PATCH] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-03-17 Thread Jolly Shah
Hi John,

Thanks for the review.


On Wed, Mar 17, 2021 at 4:44 AM John Garry  wrote:
>
> On 16/03/2021 19:39, Jolly Shah wrote:
> > When the cache_type for the scsi device is changed, the scsi layer
> > issues a MODE_SELECT command. The caching mode details are communicated
> > via a request buffer associated with the scsi command with data
> > direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
> > reaches the libata layer, as a part of generic initial setup, libata
> > layer sets up the scatterlist for the command using the scsi command
> > (ata_scsi_qc_new). This command is then translated by the libata layer
> > into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
> > treats this as a non data command (ata_mselect_caching), since it only
> > needs an ata taskfile to pass the caching on/off information to the
> > device. It does not need the scatterlist that has been setup, so it does
> > not perform dma_map_sg on the scatterlist (ata_qc_issue).
>
> So if we don't perform the dma_map_sg() on the sgl at this point, then
> it seems to me that we should not perform for_each_sg() on it either,
> right? That is still what happens in sas_ata_qc_issue() in this case.
>

Yes that's right. To avoid that, I can add elseif block for
ATA_PROT_NODATA before for_each_sg() is performed. Currently there's
existing code block for ATA_PROT_NODATA after for_each_sg()  is
performed,
reused that to reset num_scatter. Please suggest.

> > Unfortunately,
> > when this command reaches the libsas layer(sas_ata_qc_issue), libsas
> > layer sees it as a non data command with a scatterlist. It cannot
> > extract the correct dma length, since the scatterlist has not been
> > mapped with dma_map_sg for a DMA operation. When this partially
> > constructed SAS task reaches pm80xx LLDD, it results in below warning.
> >
> > "pm80xx_chip_sata_req 6058: The sg list address
> > start_addr=0x data_len=0x0end_addr_high=0x
> > end_addr_low=0xffff has crossed 4G boundary"
> >
> > This patch assigns appropriate value to  num_sectors for ata non data
> > commands.
> >
> > Signed-off-by: Jolly Shah 
> > ---
> >   drivers/scsi/libsas/sas_ata.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
> > index 024e5a550759..94ec08cebbaa 100644
> > --- a/drivers/scsi/libsas/sas_ata.c
> > +++ b/drivers/scsi/libsas/sas_ata.c
> > @@ -209,10 +209,12 @@ static unsigned int sas_ata_qc_issue(struct 
> > ata_queued_cmd *qc)
> >   task->num_scatter = si;
> >   }
> >
> > - if (qc->tf.protocol == ATA_PROT_NODATA)
> > + if (qc->tf.protocol == ATA_PROT_NODATA) {
> >   task->data_dir = DMA_NONE;
> > - else
> > + task->num_scatter = 0;
>
> task->num_scatter has already been set in this function. Best not set it
> twice.
>

Sure. Please suggest if I should update patch to above suggested
approach. That will avoid setting num_scatter twice.

Thanks,
Jolly Shah

> Thanks,
> John
>
> > + } else {
> >   task->data_dir = qc->dma_dir;
> > + }
> >   task->scatter = qc->sg;
> >   task->ata_task.retry_count = 1;
> >   task->task_state_flags = SAS_TASK_STATE_PENDING;
> >
>


Re: [PATCH] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-03-17 Thread Jolly Shah
Hi Jason,

Thanks for the review.


On Tue, Mar 16, 2021 at 6:50 PM Jason Yan  wrote:
>
>
> 在 2021/3/17 3:39, Jolly Shah 写道:
> > When the cache_type for the scsi device is changed, the scsi layer
> > issues a MODE_SELECT command. The caching mode details are communicated
> > via a request buffer associated with the scsi command with data
> > direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
> > reaches the libata layer, as a part of generic initial setup, libata
> > layer sets up the scatterlist for the command using the scsi command
> > (ata_scsi_qc_new). This command is then translated by the libata layer
> > into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
> > treats this as a non data command (ata_mselect_caching), since it only
> > needs an ata taskfile to pass the caching on/off information to the
> > device. It does not need the scatterlist that has been setup, so it does
> > not perform dma_map_sg on the scatterlist (ata_qc_issue). Unfortunately,
> > when this command reaches the libsas layer(sas_ata_qc_issue), libsas
> > layer sees it as a non data command with a scatterlist. It cannot
> > extract the correct dma length, since the scatterlist has not been
> > mapped with dma_map_sg for a DMA operation. When this partially
> > constructed SAS task reaches pm80xx LLDD, it results in below warning.
> >
> > "pm80xx_chip_sata_req 6058: The sg list address
> > start_addr=0x data_len=0x0end_addr_high=0x
> > end_addr_low=0x has crossed 4G boundary"
> >
> > This patch assigns appropriate value to  num_sectors for ata non data
> > commands.
> >
> > Signed-off-by: Jolly Shah 
> > ---
> >   drivers/scsi/libsas/sas_ata.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
> > index 024e5a550759..94ec08cebbaa 100644
> > --- a/drivers/scsi/libsas/sas_ata.c
> > +++ b/drivers/scsi/libsas/sas_ata.c
> > @@ -209,10 +209,12 @@ static unsigned int sas_ata_qc_issue(struct 
> > ata_queued_cmd *qc)
> >   task->num_scatter = si;
> >   }
> >
> > - if (qc->tf.protocol == ATA_PROT_NODATA)
> > + if (qc->tf.protocol == ATA_PROT_NODATA) {
> >   task->data_dir = DMA_NONE;
> > - else
> > + task->num_scatter = 0;
> > + } else {
> >       task->data_dir = qc->dma_dir;
> > + }
> >   task->scatter = qc->sg;
> >   task->ata_task.retry_count = 1;
> >   task->task_state_flags = SAS_TASK_STATE_PENDING;
> >
>
> Thanks for the patch. Except the warning, any functional errors?
>

No functional errors observed.

Thanks,
Jolly Shah

> The code looks good to me,
>
> Reviewed-by: Jason Yan 


[PATCH] scsi: libsas: Reset num_scatter if libata mark qc as NODATA

2021-03-16 Thread Jolly Shah
When the cache_type for the scsi device is changed, the scsi layer
issues a MODE_SELECT command. The caching mode details are communicated
via a request buffer associated with the scsi command with data
direction set as DMA_TO_DEVICE (scsi_mode_select). When this command
reaches the libata layer, as a part of generic initial setup, libata
layer sets up the scatterlist for the command using the scsi command
(ata_scsi_qc_new). This command is then translated by the libata layer
into ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat). The libata layer
treats this as a non data command (ata_mselect_caching), since it only
needs an ata taskfile to pass the caching on/off information to the
device. It does not need the scatterlist that has been setup, so it does
not perform dma_map_sg on the scatterlist (ata_qc_issue). Unfortunately,
when this command reaches the libsas layer(sas_ata_qc_issue), libsas
layer sees it as a non data command with a scatterlist. It cannot
extract the correct dma length, since the scatterlist has not been
mapped with dma_map_sg for a DMA operation. When this partially
constructed SAS task reaches pm80xx LLDD, it results in below warning.

"pm80xx_chip_sata_req 6058: The sg list address
start_addr=0x data_len=0x0end_addr_high=0x
end_addr_low=0x has crossed 4G boundary"

This patch assigns appropriate value to  num_sectors for ata non data 
commands.

Signed-off-by: Jolly Shah 
---
 drivers/scsi/libsas/sas_ata.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 024e5a550759..94ec08cebbaa 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -209,10 +209,12 @@ static unsigned int sas_ata_qc_issue(struct 
ata_queued_cmd *qc)
task->num_scatter = si;
}
 
-   if (qc->tf.protocol == ATA_PROT_NODATA)
+   if (qc->tf.protocol == ATA_PROT_NODATA) {
task->data_dir = DMA_NONE;
-   else
+   task->num_scatter = 0;
+   } else {
task->data_dir = qc->dma_dir;
+   }
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;
-- 
2.31.0.rc2.261.g7f71774620-goog



Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags

2020-05-29 Thread Jolly Shah

Hi Stephan,

> --Original Message--
> From: Stephen Boyd 
> Sent:  Thursday, May 28, 2020 4:12PM
> To: Jolly Shah , Arm , 
Linux-clk , Michal Simek 
, Mturquette , Olof 

> Cc: Rajan Vaja , 
linux-arm-ker...@lists.infradead.org 
, Linux-kernel@vger.kernel.org 
, Tejas Patel , 
Rajan Vaja 
> Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction 
clock check from custom type flags

>

Quoting Jolly Shah (2020-05-28 10:44:01)

Hi Stephan,

Thanks for the review.

  > --Original Message--
  > From: Stephen Boyd 
  > Sent:  Tuesday, May 26, 2020 6:08PM
  > To: Jolly Shah , Arm ,
Linux-clk , Michal Simek
, Mturquette , Olof

  > Cc: Rajan Vaja ,
linux-arm-ker...@lists.infradead.org
, Linux-kernel@vger.kernel.org
, Tejas Patel ,
Rajan Vaja , Jolly Shah 
  > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
clock check from custom type flags
  >

Quoting Jolly Shah (2020-03-12 14:31:39)

From: Tejas Patel 

Older firmware version sets BIT(13) in clkflag to mark a
divider as fractional divider. Updated firmware version sets BIT(4)
in type flags to mark a divider as fractional divider since
BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
framework flags.

To support both old and new firmware version, consider BIT(13) from
clkflag and BIT(4) from type_flag to check if divider is fractional
or not.

To maintain compatibility BIT(13) of clkflag in firmware will not be
used in future for any purpose and will be marked as unused.


Why are we mixing the firmware flags with the ccf flags? They shouldn't
be the same. The firmware should have its own 'flag numberspace' that is
distinct from the common clk framework's 'flag numberspace'. Please fix
the code.



Yes firmware flags are using separate numberspace now. Firmware
maintains CCF and firmware specific flags separately but earlier
CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here
for backward compatibility. Driver takes care of not registering same
with CCF. Let me know if I misunderstood.


Why is the firmware maintaining CCF specific flags? The firmware
shouldn't know about the CCF flag numbering at all. We can change the
numbers that the CCF flags are assigned to randomly and that shouldn't
mean that the firmware needs to change. Maybe I should apply this patch?


Got it. Will fix it.

Thanks,
Jolly Shah




---8<
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index bd1ee9039558..c1f36bca85b0 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -16,22 +16,22 @@
   *
   * Please update clk_flags[] in drivers/clk/clk.c when making changes here!
   */
-#define CLK_SET_RATE_GATE  BIT(0) /* must be gated across rate change */
-#define CLK_SET_PARENT_GATEBIT(1) /* must be gated across re-parent */
-#define CLK_SET_RATE_PARENTBIT(2) /* propagate rate change up one level */
-#define CLK_IGNORE_UNUSED  BIT(3) /* do not gate even if unused */
+#define CLK_SET_RATE_GATE  BIT(13) /* must be gated across rate change */
+#define CLK_SET_PARENT_GATEBIT(2) /* must be gated across re-parent */
+#define CLK_SET_RATE_PARENTBIT(3) /* propagate rate change up one level */
+#define CLK_IGNORE_UNUSED  BIT(4) /* do not gate even if unused */
/* unused */
/* unused */
-#define CLK_GET_RATE_NOCACHE   BIT(6) /* do not use the cached clk rate */
-#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
-#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy 
*/
-#define CLK_RECALC_NEW_RATES   BIT(9) /* recalc rates after notifications */
-#define CLK_SET_RATE_UNGATEBIT(10) /* clock needs to run to set rate */
-#define CLK_IS_CRITICALBIT(11) /* do not gate, ever */
+#define CLK_GET_RATE_NOCACHE   BIT(5) /* do not use the cached clk rate */
+#define CLK_SET_RATE_NO_REPARENT BIT(6) /* don't re-parent on rate change */
+#define CLK_GET_ACCURACY_NOCACHE BIT(7) /* do not use the cached clk accuracy 
*/
+#define CLK_RECALC_NEW_RATES   BIT(8) /* recalc rates after notifications */
+#define CLK_SET_RATE_UNGATEBIT(9) /* clock needs to run to set rate */
+#define CLK_IS_CRITICALBIT(10) /* do not gate, ever */
  /* parents need enable during gate/ungate, set rate and re-parent */
-#define CLK_OPS_PARENT_ENABLE  BIT(12)
+#define CLK_OPS_PARENT_ENABLE  BIT(11)
  /* duty cycle call may be forwarded to the parent clock */
-#define CLK_DUTY_CYCLE_PARENT  BIT(13)
+#define CLK_DUTY_CYCLE_PARENT  BIT(12)
  
  struct clk;

  struct clk_hw;



Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags

2020-05-28 Thread Jolly Shah

Hi Stephan,

Thanks for the review.

> --Original Message--
> From: Stephen Boyd 
> Sent:  Tuesday, May 26, 2020 6:08PM
> To: Jolly Shah , Arm , 
Linux-clk , Michal Simek 
, Mturquette , Olof 

> Cc: Rajan Vaja , 
linux-arm-ker...@lists.infradead.org 
, Linux-kernel@vger.kernel.org 
, Tejas Patel , 
Rajan Vaja , Jolly Shah 
> Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction 
clock check from custom type flags

>

Quoting Jolly Shah (2020-03-12 14:31:39)

From: Tejas Patel 

Older firmware version sets BIT(13) in clkflag to mark a
divider as fractional divider. Updated firmware version sets BIT(4)
in type flags to mark a divider as fractional divider since
BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
framework flags.

To support both old and new firmware version, consider BIT(13) from
clkflag and BIT(4) from type_flag to check if divider is fractional
or not.

To maintain compatibility BIT(13) of clkflag in firmware will not be
used in future for any purpose and will be marked as unused.


Why are we mixing the firmware flags with the ccf flags? They shouldn't
be the same. The firmware should have its own 'flag numberspace' that is
distinct from the common clk framework's 'flag numberspace'. Please fix
the code.



Yes firmware flags are using separate numberspace now. Firmware 
maintains CCF and firmware specific flags separately but earlier 
CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here 
for backward compatibility. Driver takes care of not registering same 
with CCF. Let me know if I misunderstood.


Thanks,
Jolly Shah




Re: [PATCH] firmware: xilinx: Fix an error handling path in 'zynqmp_firmware_probe()'

2020-05-13 Thread Jolly Shah

Reviewed-by: Jolly Shah 

> --Original Message--
> From: Christophe Jaillet 
> Sent:  Sunday, May 10, 2020 6:03AM
> To: Michal Simek , Rajan Vaja 
, Jolly Shah , 'Greg Kh' 
, Tejas Patel , 
Manish Narani , Ravi Patel 
> Cc: linux-arm-ker...@lists.infradead.org 
, Linux-kernel@vger.kernel.org 
, Kernel-janitors 
, Christophe Jaillet 

> Subject: [PATCH] firmware: xilinx: Fix an error handling path in 
'zynqmp_firmware_probe()'

>

If 'mfd_add_devices()' fails, we must undo 'zynqmp_pm_api_debugfs_init()'
otherwise some debugfs directory and files will be left.

Just move the call to 'zynqmp_pm_api_debugfs_init()' a few lines below to
fix the issue.

Fixes: e23d9c6d0d49 ("drivers: soc: xilinx: Add ZynqMP power domain driver")
Signed-off-by: Christophe JAILLET 
---
Not related to this fix, but I think that:
- a call to 'of_platform_depopulate()' is missing in the remove function
- we shouldn't return of_platform_populate(); directly because we
  don't have the opportunity to call 'mfd_remove_devices()' as done in
  the remove function, and 'of_platform_depopulate()' for what have
  been populated yet

I'm not familiar with this API, so I just point it out to get feedback.


Agree. This needs to be fixed.

Thanks,
Jolly Shah



---
  drivers/firmware/xilinx/zynqmp.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8095fa84d5d7..8d1ff2454e2e 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1235,8 +1235,6 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
pr_info("%s Trustzone version v%d.%d\n", __func__,
pm_tz_version >> 16, pm_tz_version & 0x);
  
-	zynqmp_pm_api_debugfs_init();

-
ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, firmware_devs,
  ARRAY_SIZE(firmware_devs), NULL, 0, NULL);
if (ret) {
@@ -1244,6 +1242,8 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
return ret;
}
  
+	zynqmp_pm_api_debugfs_init();

+
return of_platform_populate(dev->of_node, NULL, NULL, dev);
  }
  



RE: [PATCH 1/2] dt-bindings: firmware: Add bindings for Versal firmware

2019-10-07 Thread Jolly Shah
Hi Michal and Greg,

> -Original Message-
> From: Michal Simek 
> Sent: Sunday, October 06, 2019 11:14 PM
> To: Greg KH ; Jolly Shah 
> Cc: ard.biesheu...@linaro.org; mi...@kernel.org; m...@codeblueprint.co.uk;
> sudeep.ho...@arm.com; hkallwe...@gmail.com; keesc...@chromium.org;
> dmitry.torok...@gmail.com; Michal Simek ; Rajan Vaja
> ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH 1/2] dt-bindings: firmware: Add bindings for Versal 
> firmware
> 
> On 04. 10. 19 18:18, Greg KH wrote:
> > On Fri, Sep 27, 2019 at 12:40:05PM -0700, Jolly Shah wrote:
> >> ZynqMP firmware driver can be used for versal also.
> >> Add versal compatible string to zynqmp firmware driver
> >> doc.
> >>
> >> Signed-off-by: Jolly Shah 
> >> ---
> >>  .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16
> +++-
> >>  1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-
> firmware.txt
> b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-
> firmware.txt
> >> index a4fe136..18c3aea 100644
> >> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-
> firmware.txt
> >> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-
> firmware.txt
> >> @@ -11,7 +11,9 @@ power management service, FPGA service and other
> platform management
> >>  services.
> >>
> >>  Required properties:
> >> - - compatible:Must contain:   "xlnx,zynqmp-firmware"
> >> + - compatible:Must contain any of below:
> >> +  "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC
> >> +  "xlnx,versal-firmware" for Versal
> >>   - method:The method of calling the PM-API firmware layer.
> >>Permitted values are:
> >>  - "smc" : SMC #0, following the SMCCC
> >> @@ -21,6 +23,8 @@ Required properties:
> >>  Example
> >>  ---
> >>
> >> +Zynq Ultrascale+ MPSoC
> >> +--
> >>  firmware {
> >>zynqmp_firmware: zynqmp-firmware {
> >>compatible = "xlnx,zynqmp-firmware";
> >> @@ -28,3 +32,13 @@ firmware {
> >>...
> >>};
> >>  };
> >> +
> >> +Versal
> >> +--
> >> +firmware {
> >> +  versal_firmware: versal-firmware {
> >> +  compatible = "xlnx,versal-firmware";
> >> +  method = "smc";
> >> +  ...
> >> +  };
> >> +};
> >> --
> >> 2.7.4
> >>
> >
> >
> > For new dt bindings, don't you have to cc: the dt maintainers and
> > mailing list?  I can't take the patch until I get an ack from them.
> 
> Yes dt guys should be in CC and normally I am taking this via ARM soc tree.
> 
> Jolly: Please resend
> 

Sorry missed it earlier. Sent v2 including DT maintainers.

Thanks,
Jolly Shah

> Thanks,
> Michal


[PATCH v2 0/2] drivers: firmware: xilinx: Add support for versal soc

2019-10-07 Thread Jolly Shah
Versal is xilinx's next generation soc. This patch adds
driver support required to be compatible with versal device

v2:
  No changes. Resending to include DT maintaners

Jolly Shah (2):
  dt-bindings: firmware: Add bindings for Versal firmware
  drivers: firmware: xilinx: Add support for versal soc

 .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16 +++-
 drivers/firmware/xilinx/zynqmp.c |  8 ++--
 2 files changed, 21 insertions(+), 3 deletions(-)

-- 
2.7.4



[PATCH v2 1/2] dt-bindings: firmware: Add bindings for Versal firmware

2019-10-07 Thread Jolly Shah
ZynqMP firmware driver can be used for versal also.
Add versal compatible string to zynqmp firmware driver
doc.

Signed-off-by: Jolly Shah 
---
 .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index a4fe136..18c3aea 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -11,7 +11,9 @@ power management service, FPGA service and other platform 
management
 services.
 
 Required properties:
- - compatible: Must contain:   "xlnx,zynqmp-firmware"
+ - compatible: Must contain any of below:
+   "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC
+   "xlnx,versal-firmware" for Versal
  - method: The method of calling the PM-API firmware layer.
Permitted values are:
  - "smc" : SMC #0, following the SMCCC
@@ -21,6 +23,8 @@ Required properties:
 Example
 ---
 
+Zynq Ultrascale+ MPSoC
+--
 firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
@@ -28,3 +32,13 @@ firmware {
...
};
 };
+
+Versal
+--
+firmware {
+   versal_firmware: versal-firmware {
+   compatible = "xlnx,versal-firmware";
+   method = "smc";
+   ...
+   };
+};
-- 
2.7.4



[PATCH v2 2/2] drivers: firmware: xilinx: Add support for versal soc

2019-10-07 Thread Jolly Shah
Versal is xilinx's next generation soc. This patch adds
driver support required to be compatible with versal device.

Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fd3d837..75bdfaa 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -711,8 +711,11 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
int ret;
 
np = of_find_compatible_node(NULL, NULL, "xlnx,zynqmp");
-   if (!np)
-   return 0;
+   if (!np) {
+   np = of_find_compatible_node(NULL, NULL, "xlnx,versal");
+   if (!np)
+   return 0;
+   }
of_node_put(np);
 
ret = get_set_conduit_method(dev->of_node);
@@ -770,6 +773,7 @@ static int zynqmp_firmware_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id zynqmp_firmware_of_match[] = {
{.compatible = "xlnx,zynqmp-firmware"},
+   {.compatible = "xlnx,versal-firmware"},
{},
 };
 MODULE_DEVICE_TABLE(of, zynqmp_firmware_of_match);
-- 
2.7.4



[PATCH 0/2] drivers: firmware: xilinx: Add support for versal soc

2019-09-27 Thread Jolly Shah
Versal is xilinx's next generation soc. This patch adds
driver support required to be compatible with versal device.

Jolly Shah (2):
  dt-bindings: firmware: Add bindings for Versal firmware
  drivers: firmware: xilinx: Add support for versal soc

 .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16 +++-
 drivers/firmware/xilinx/zynqmp.c |  8 ++--
 2 files changed, 21 insertions(+), 3 deletions(-)

-- 
2.7.4



[PATCH 2/2] drivers: firmware: xilinx: Add support for versal soc

2019-09-27 Thread Jolly Shah
Versal is xilinx's next generation soc. This patch adds
driver support required to be compatible with versal device.

Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fd3d837..75bdfaa 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -711,8 +711,11 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
int ret;
 
np = of_find_compatible_node(NULL, NULL, "xlnx,zynqmp");
-   if (!np)
-   return 0;
+   if (!np) {
+   np = of_find_compatible_node(NULL, NULL, "xlnx,versal");
+   if (!np)
+   return 0;
+   }
of_node_put(np);
 
ret = get_set_conduit_method(dev->of_node);
@@ -770,6 +773,7 @@ static int zynqmp_firmware_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id zynqmp_firmware_of_match[] = {
{.compatible = "xlnx,zynqmp-firmware"},
+   {.compatible = "xlnx,versal-firmware"},
{},
 };
 MODULE_DEVICE_TABLE(of, zynqmp_firmware_of_match);
-- 
2.7.4



[PATCH 1/2] dt-bindings: firmware: Add bindings for Versal firmware

2019-09-27 Thread Jolly Shah
ZynqMP firmware driver can be used for versal also.
Add versal compatible string to zynqmp firmware driver
doc.

Signed-off-by: Jolly Shah 
---
 .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index a4fe136..18c3aea 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -11,7 +11,9 @@ power management service, FPGA service and other platform 
management
 services.
 
 Required properties:
- - compatible: Must contain:   "xlnx,zynqmp-firmware"
+ - compatible: Must contain any of below:
+   "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC
+   "xlnx,versal-firmware" for Versal
  - method: The method of calling the PM-API firmware layer.
Permitted values are:
  - "smc" : SMC #0, following the SMCCC
@@ -21,6 +23,8 @@ Required properties:
 Example
 ---
 
+Zynq Ultrascale+ MPSoC
+--
 firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
@@ -28,3 +32,13 @@ firmware {
...
};
 };
+
+Versal
+--
+firmware {
+   versal_firmware: versal-firmware {
+   compatible = "xlnx,versal-firmware";
+   method = "smc";
+   ...
+   };
+};
-- 
2.7.4



[PATCH v2] soc: xilinx: Set CAP_UNUSABLE requirement for versal while powering down domain

2019-08-26 Thread Jolly Shah
From: Tejas Patel 

For "0" requirement which is used to inform firmware that device is
not required currently by master, Versal PLM (Platform Loader and
Manager) which runs on Platform Management Controller and is responsible
platform management of devices that disables clock, power it down
and reset the device. genpd_power_off() is being called during runtime
suspend also. So, if any device goes to runtime suspend state during
resumes it needs to be re-initialized again. It is possible that
drivers do not reinitialize device upon resume from runtime suspend
every time ans so dont want it to be powered down or get reset
during runtime suspend.

In Versal PLM new PM_CAP_UNUSABLE capability is added, which disables
clock only and avoids power down and reset during runtime suspend. Power
and reset will be gated with core suspend.So, this patch sets 
CAPABILITY_UNUSABLE requirement during gpd_power_off()
if platform is other than zynqmp.

Signed-off-by: Tejas Patel 
Signed-off-by: Jolly Shah 
---
 drivers/soc/xilinx/zynqmp_pm_domains.c | 10 --
 include/linux/firmware/xlnx-zynqmp.h   |  3 ++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/xilinx/zynqmp_pm_domains.c 
b/drivers/soc/xilinx/zynqmp_pm_domains.c
index 600f57c..23d90cb 100644
--- a/drivers/soc/xilinx/zynqmp_pm_domains.c
+++ b/drivers/soc/xilinx/zynqmp_pm_domains.c
@@ -2,7 +2,7 @@
 /*
  * ZynqMP Generic PM domain support
  *
- *  Copyright (C) 2015-2018 Xilinx, Inc.
+ *  Copyright (C) 2015-2019 Xilinx, Inc.
  *
  *  Davorin Mista 
  *  Jolly Shah 
@@ -25,6 +25,8 @@
 
 static const struct zynqmp_eemi_ops *eemi_ops;
 
+static int min_capability;
+
 /**
  * struct zynqmp_pm_domain - Wrapper around struct generic_pm_domain
  * @gpd:   Generic power domain
@@ -106,7 +108,7 @@ static int zynqmp_gpd_power_off(struct generic_pm_domain 
*domain)
int ret;
struct pm_domain_data *pdd, *tmp;
struct zynqmp_pm_domain *pd;
-   u32 capabilities = 0;
+   u32 capabilities = min_capability;
bool may_wakeup;
 
if (!eemi_ops->set_requirement)
@@ -283,6 +285,10 @@ static int zynqmp_gpd_probe(struct platform_device *pdev)
if (!domains)
return -ENOMEM;
 
+   if (!of_device_is_compatible(dev->parent->of_node,
+"xlnx,zynqmp-firmware"))
+   min_capability = ZYNQMP_PM_CAPABILITY_UNUSABLE;
+
for (i = 0; i < ZYNQMP_NUM_DOMAINS; i++, pd++) {
pd->node_id = 0;
pd->gpd.name = kasprintf(GFP_KERNEL, "domain%d", i);
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 778abbb..b8a7c22 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -2,7 +2,7 @@
 /*
  * Xilinx Zynq MPSoC Firmware layer
  *
- *  Copyright (C) 2014-2018 Xilinx
+ *  Copyright (C) 2014-2019 Xilinx
  *
  *  Michal Simek 
  *  Davorin Mista 
@@ -46,6 +46,7 @@
 #defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
 #defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+#defineZYNQMP_PM_CAPABILITY_UNUSABLE   0x8U
 
 /*
  * Firmware FPGA Manager flags
-- 
2.7.4



[PATCH] soc: xilinx: Set CAP_UNUSABLE requirement for versal while powering down domain

2019-08-08 Thread Jolly Shah
From: Tejas Patel 

For "0" requirement which is used to inform firmware that
device is not required currently by master, Versal LibPM disables
clock, power it down and reset the device. genpd_power_off()
is being called during runtime suspend also. So, if any device
goes to runtime suspend state during resumes it needs to be
re-initialized again. It is possible that drivers do not
reinitialize device upon resume from runtime suspend every time.

In LibPM new PM_CAP_UNUSABLE capability is added, which disables
clock only and avoids power down and reset.
So, set CAPABILITY_UNUSABLE requirement during zynqmp_gpd_power_off()
if platform is other than zynqmp.

Signed-off-by: Tejas Patel 
Signed-off-by: Jolly Shah 
---
 drivers/soc/xilinx/zynqmp_pm_domains.c | 10 --
 include/linux/firmware/xlnx-zynqmp.h   |  3 ++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/xilinx/zynqmp_pm_domains.c 
b/drivers/soc/xilinx/zynqmp_pm_domains.c
index 600f57c..23d90cb 100644
--- a/drivers/soc/xilinx/zynqmp_pm_domains.c
+++ b/drivers/soc/xilinx/zynqmp_pm_domains.c
@@ -2,7 +2,7 @@
 /*
  * ZynqMP Generic PM domain support
  *
- *  Copyright (C) 2015-2018 Xilinx, Inc.
+ *  Copyright (C) 2015-2019 Xilinx, Inc.
  *
  *  Davorin Mista 
  *  Jolly Shah 
@@ -25,6 +25,8 @@
 
 static const struct zynqmp_eemi_ops *eemi_ops;
 
+static int min_capability;
+
 /**
  * struct zynqmp_pm_domain - Wrapper around struct generic_pm_domain
  * @gpd:   Generic power domain
@@ -106,7 +108,7 @@ static int zynqmp_gpd_power_off(struct generic_pm_domain 
*domain)
int ret;
struct pm_domain_data *pdd, *tmp;
struct zynqmp_pm_domain *pd;
-   u32 capabilities = 0;
+   u32 capabilities = min_capability;
bool may_wakeup;
 
if (!eemi_ops->set_requirement)
@@ -283,6 +285,10 @@ static int zynqmp_gpd_probe(struct platform_device *pdev)
if (!domains)
return -ENOMEM;
 
+   if (!of_device_is_compatible(dev->parent->of_node,
+"xlnx,zynqmp-firmware"))
+   min_capability = ZYNQMP_PM_CAPABILITY_UNUSABLE;
+
for (i = 0; i < ZYNQMP_NUM_DOMAINS; i++, pd++) {
pd->node_id = 0;
pd->gpd.name = kasprintf(GFP_KERNEL, "domain%d", i);
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 778abbb..b8a7c22 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -2,7 +2,7 @@
 /*
  * Xilinx Zynq MPSoC Firmware layer
  *
- *  Copyright (C) 2014-2018 Xilinx
+ *  Copyright (C) 2014-2019 Xilinx
  *
  *  Michal Simek 
  *  Davorin Mista 
@@ -46,6 +46,7 @@
 #defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
 #defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+#define ZYNQMP_PM_CAPABILITY_UNUSABLE  0x8U
 
 /*
  * Firmware FPGA Manager flags
-- 
2.7.4



RE: [PATCH v2 09/11] firmware: xilinx: Add SDIO Tap Delay APIs

2019-07-01 Thread Jolly Shah
Hi Manish,

> -Original Message-
> From: Manish Narani 
> Sent: Sunday, June 30, 2019 10:30 PM
> To: ulf.hans...@linaro.org; robh...@kernel.org; mark.rutl...@arm.com;
> he...@sntech.de; Michal Simek ;
> adrian.hun...@intel.com; christoph.muell...@theobroma-systems.com;
> philipp.toms...@theobroma-systems.com; viresh.ku...@linaro.org;
> scott.bran...@broadcom.com; ay...@soulik.info; ker...@esmil.dk;
> tony@rock-chips.com; Rajan Vaja ; Jolly Shah
> ; Nava kishore Manne ;
> m...@kernel.org; Manish Narani ; o...@lixom.net
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> rockc...@lists.infradead.org
> Subject: [PATCH v2 09/11] firmware: xilinx: Add SDIO Tap Delay APIs
> 
> Add APIs for setting SDIO Tap Delays on ZynqMP platform.
> 
> Signed-off-by: Manish Narani 
> ---
>  drivers/firmware/xilinx/zynqmp.c | 48
> 
>  include/linux/firmware/xlnx-zynqmp.h | 15 ++-
>  2 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/xilinx/zynqmp.c 
> b/drivers/firmware/xilinx/zynqmp.c
> index fd3d837..b81f1be 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -664,6 +664,52 @@ static int zynqmp_pm_set_requirement(const u32
> node, const u32 capabilities,
>  qos, ack, NULL);
>  }
> 
> +/**
> + * zynqmp_pm_sdio_out_setphase() - PM call to set clock output delays for SD
> + * @device_id:   Device ID of the SD controller
> + * @tap_delay:   Tap Delay value for output clock
> + *
> + * This API function is to be used for setting the clock output delays for SD
> + * clock.
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +static int zynqmp_pm_sdio_out_setphase(u32 device_id, u8 tap_delay)
> +{
> + u32 node_id = (!device_id) ? NODE_SD_0 : NODE_SD_1;
> + int ret;
> +
> + ret = zynqmp_pm_ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> +   PM_TAPDELAY_OUTPUT, tap_delay, NULL);
> + if (ret)
> + pr_err("Error setting Output Tap Delay\n");
> +
> + return ret;
> +}
> +
> +/**
> + * zynqmp_pm_sdio_in_setphase() - PM call to set clock input delays for SD
> + * @device_id:   Device ID of the SD controller
> + * @tap_delay:   Tap Delay value for input clock
> + *
> + * This API function is to be used for setting the clock input delays for SD
> + * clock.
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +static int zynqmp_pm_sdio_in_setphase(u32 device_id, u8 tap_delay)
> +{
> + u32 node_id = (!device_id) ? NODE_SD_0 : NODE_SD_1;
> + int ret;
> +
> + ret = zynqmp_pm_ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> +   PM_TAPDELAY_INPUT, tap_delay, NULL);
> + if (ret)
> + pr_err("Error setting Input Tap Delay\n");
> +
> + return ret;
> +}
> +
>  static const struct zynqmp_eemi_ops eemi_ops = {
>   .get_api_version = zynqmp_pm_get_api_version,
>   .get_chipid = zynqmp_pm_get_chipid,
> @@ -687,6 +733,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
>   .set_requirement = zynqmp_pm_set_requirement,
>   .fpga_load = zynqmp_pm_fpga_load,
>   .fpga_get_status = zynqmp_pm_fpga_get_status,
> + .sdio_out_setphase = zynqmp_pm_sdio_out_setphase,
> + .sdio_in_setphase = zynqmp_pm_sdio_in_setphase,

Are these eemi APIs? You are using ioctl eemi api to set the delay.

Thanks,
Jolly Shah

>  };
> 
>  /**
> diff --git a/include/linux/firmware/xlnx-zynqmp.h 
> b/include/linux/firmware/xlnx-
> zynqmp.h
> index 1262ea6..d9b53e5 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -92,7 +92,8 @@ enum pm_ret_status {
>  };
> 
>  enum pm_ioctl_id {
> - IOCTL_SET_PLL_FRAC_MODE = 8,
> + IOCTL_SET_SD_TAPDELAY = 7,
> + IOCTL_SET_PLL_FRAC_MODE,
>   IOCTL_GET_PLL_FRAC_MODE,
>   IOCTL_SET_PLL_FRAC_DATA,
>   IOCTL_GET_PLL_FRAC_DATA,
> @@ -251,6 +252,16 @@ enum zynqmp_pm_request_ack {
>   ZYNQMP_PM_REQUEST_ACK_NON_BLOCKING,
>  };
> 
> +enum pm_node_id {
> + NODE_SD_0 = 39,
> + NODE_SD_1,
> +};
> +
> +enum tap_delay_type {
> + PM_TAPDELAY_INPUT = 0,
> + PM_TAPDELAY_OUTPUT,
> +};
> +
>  /**
>   * struct zynqmp_pm_query_data - PM query data
>   * @qid: query ID
> @@ -295,6 +306,8 @@ struct zynqmp_eemi_ops {
>  const u32 capabilities,
>  const u32 qos,
>  const enum zynqmp_pm_request_ack ack);
> + int (*sdio_out_setphase)(u32 device_id, u8 tap_delay);
> + int (*sdio_in_setphase)(u32 device_id, u8 tap_delay);
>  };
> 
>  int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
> --
> 2.1.1



[PATCH] firmware: xilinx: zynqmp: Remove unused macro

2019-06-19 Thread Jolly Shah
ZYNQMP_PM_CAPABILITY_POWER capability is not supported by firmware
and hence needs to be removed

Signed-off-by: Tejas Patel 
Signed-off-by: Michal Simek 
Signed-off-by: Jolly Shah 
---
 include/linux/firmware/xlnx-zynqmp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 1262ea6..778abbb 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -46,7 +46,6 @@
 #defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
 #defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
-#defineZYNQMP_PM_CAPABILITY_POWER  0x8U
 
 /*
  * Firmware FPGA Manager flags
-- 
2.7.4



RE: [PATCH] drivers: clk: Update clock driver to handle clock attribute

2019-04-12 Thread Jolly Shah
Hi Michael,

> -Original Message-
> From: Michael Tretter 
> Sent: Friday, April 12, 2019 2:01 AM
> To: Jolly Shah 
> Cc: mturque...@baylibre.com; sb...@codeaurora.org; Michal Simek
> ; linux-...@vger.kernel.org; Tejas Patel
> ; Rajan Vaja ; linux-
> ker...@vger.kernel.org; Jolly Shah ; Rajan Vaja
> ; linux-arm-ker...@lists.infradead.org;
> ker...@pengutronix.de
> Subject: Re: [PATCH] drivers: clk: Update clock driver to handle clock 
> attribute
> 
> On Mon, 04 Mar 2019 15:19:10 -0800, Jolly Shah wrote:
> > From: Rajan Vaja 
> >
> > Versal EEMI APIs uses clock device ID which is combination of class,
> > subclass, type and clock index (e.g. 0x8104006 in which 0-13 bits are
> > for index(6 in given example), 14-19 bits are for clock type (i.e pll,
> > out or ref, 1 in given example), 20-25 bits are for subclass which is
> > nothing but clock type only), 26-32 bits are for device class, which
> > is clock(0x2) for all clocks) while zynqmp firmware uses clock ID
> > which is index only (e.g 0, 1, to n, where n is max_clock id).
> >
> > To use zynqmp clock driver for versal platform also, extend use
> > of QueryAttribute API to fetch device class, subclass and clock type
> > to create clock device ID. In case of zynqmp this attributes would be
> > 0 only, so there won't be any effect on clock id as it would use
> > clock index only.
> >
> > Signed-off-by: Tejas Patel 
> > Signed-off-by: Rajan Vaja 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Jolly Shah 
> > ---
> >  drivers/clk/zynqmp/clkc.c | 42 +-
> >  1 file changed, 29 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
> > index f65cc0f..c13b014 100644
> > --- a/drivers/clk/zynqmp/clkc.c
> > +++ b/drivers/clk/zynqmp/clkc.c
> > @@ -53,6 +53,10 @@
> >  #define RESERVED_CLK_NAME  ""
> >
> >  #define CLK_VALID_MASK 0x1
> > +#define NODE_CLASS_SHIFT   26U
> > +#define NODE_SUBCLASS_SHIFT20U
> > +#define NODE_TYPE_SHIFT14U
> > +#define NODE_INDEX_SHIFT   0U
> >
> >  enum clk_type {
> > CLK_TYPE_OUTPUT,
> > @@ -80,6 +84,7 @@ struct clock_parent {
> >   * @num_nodes: Number of nodes present in topology
> >   * @parent:Parent of clock
> >   * @num_parents:   Number of parents of clock
> > + * @clk_id:Clock id
> >   */
> >  struct zynqmp_clock {
> > char clk_name[MAX_NAME_LEN];
> > @@ -89,6 +94,7 @@ struct zynqmp_clock {
> > u32 num_nodes;
> > struct clock_parent parent[MAX_PARENT];
> > u32 num_parents;
> > +   u32 clk_id;
> >  };
> >
> >  static const char clk_type_postfix[][10] = {
> > @@ -396,7 +402,8 @@ static int zynqmp_clock_get_topology(u32 clk_id,
> >
> > *num_nodes = 0;
> > for (j = 0; j <= MAX_NODES; j += 3) {
> > -   ret = zynqmp_pm_clock_get_topology(clk_id, j, pm_resp);
> > +   ret = zynqmp_pm_clock_get_topology(clock[clk_id].clk_id, j,
> > +  pm_resp);
> 
> I think, having clk_id as the index in the array of clock descriptors
> and each descriptor having a clk_id, which might be equal to the clk_id
> (on zynqmp), but might be different from the index (versal) is really
> confusing. It would be better if there would be a clear separation
> between the driver internal id and the id that is used at the interface
> with the firmware.

If we use different ids, we will need to hard code some mappings to convert 
them to one being used by firmware. For user, both are clock ids but id values 
are different compared to zynqmp where it was sequential starting from 0. 

> 
> > if (ret)
> > return ret;
> > ret = __zynqmp_clock_get_topology(topology, pm_resp,
> num_nodes);
> > @@ -459,7 +466,8 @@ static int zynqmp_clock_get_parents(u32 clk_id, struct
> clock_parent *parents,
> > *num_parents = 0;
> > do {
> > /* Get parents from firmware */
> > -   ret = zynqmp_pm_clock_get_parents(clk_id, j, pm_resp);
> > +   ret = zynqmp_pm_clock_get_parents(clock[clk_id].clk_id, j,
> > + pm_resp);
> > if (ret)
> > return ret;
> >
> > @@ -528,13 +536,14 @@ static struct clk_hw
> *zynqmp_register_clk_topology(int clk_id, char *clk_name,
> > 

RE: [PATCH] firmware: xilinx: fix debugfs write handler

2019-03-05 Thread Jolly Shah
Acked-by: Jolly Shah 


> -Original Message-
> From: Jann Horn 
> Sent: Monday, February 18, 2019 1:43 PM
> To: Michal Simek ; ja...@google.com
> Cc: Rajan Vaja ; Jolly Shah ; linux-
> arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] firmware: xilinx: fix debugfs write handler
> 
>  - Userspace wants to write a string with `len` bytes, not counting the
>terminating NULL, so we should allocate `len+1` bytes. It looks like the
>current code relied on having a nullbyte directly behind `kern_buff`,
>which happens to work reliably as long as `len` isn't one of the kmalloc
>size classes.
>  - strncpy_from_user() is completely wrong here; userspace is giving us a
>(not necessarily null-terminated) buffer and its length.
>strncpy_from_user() is for cases in which we don't know the length.
>  - Don't let broken userspace allocate arbitrarily big kmalloc allocations.
> 
> Just use memdup_user_nul(), which is designed precisely for things like
> this.
> 
> Signed-off-by: Jann Horn 
> ---
> WARNING: completely untested patch
> 
> drivers/firmware/xilinx/zynqmp-debug.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/firmware/xilinx/zynqmp-debug.c
> b/drivers/firmware/xilinx/zynqmp-debug.c
> index 2771df6df379..90b66cdbfd58 100644
> --- a/drivers/firmware/xilinx/zynqmp-debug.c
> +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> @@ -163,21 +163,14 @@ static ssize_t zynqmp_pm_debugfs_api_write(struct
> file *file,
> 
>   strcpy(debugfs_buf, "");
> 
> - if (*off != 0 || len == 0)
> + if (*off != 0 || len <= 1 || len > PAGE_SIZE - 1)
>   return -EINVAL;
> 
> - kern_buff = kzalloc(len, GFP_KERNEL);
> - if (!kern_buff)
> - return -ENOMEM;
> -
> + kern_buff = memdup_user_nul(ptr, len);
> + if (IS_ERR(kern_buff))
> + return PTR_ERR(kern_buff);
>   tmp_buff = kern_buff;
> 
> - ret = strncpy_from_user(kern_buff, ptr, len);
> - if (ret < 0) {
> - ret = -EFAULT;
> - goto err;
> - }
> -
>   /* Read the API name from a user request */
>   pm_api_req = strsep(_buff, " ");
> 
> --
> 2.21.0.rc0.258.g878e2cd30e-goog



[PATCH] drivers: clk: zynqmp: Allow zero divisor value

2019-03-04 Thread Jolly Shah
From: Rajan Vaja 

Zero divider is valid and default for some of ZynqMP
clocks. Allow zero divisor when CLK_DIVIDER_ALLOW_ZERO
for the clock is set.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/clk/zynqmp/divider.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/zynqmp/divider.c b/drivers/clk/zynqmp/divider.c
index a371c66..e146b6f 100644
--- a/drivers/clk/zynqmp/divider.c
+++ b/drivers/clk/zynqmp/divider.c
@@ -76,6 +76,13 @@ static unsigned long zynqmp_clk_divider_recalc_rate(struct 
clk_hw *hw,
else
value = div >> 16;
 
+   if (!value) {
+   WARN(!(divider->flags & CLK_DIVIDER_ALLOW_ZERO),
+"%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n",
+clk_name);
+   return parent_rate;
+   }
+
return DIV_ROUND_UP_ULL(parent_rate, value);
 }
 
-- 
2.7.4



[PATCH] drivers: clk: Update clock driver to handle clock attribute

2019-03-04 Thread Jolly Shah
From: Rajan Vaja 

Versal EEMI APIs uses clock device ID which is combination of class,
subclass, type and clock index (e.g. 0x8104006 in which 0-13 bits are
for index(6 in given example), 14-19 bits are for clock type (i.e pll,
out or ref, 1 in given example), 20-25 bits are for subclass which is
nothing but clock type only), 26-32 bits are for device class, which
is clock(0x2) for all clocks) while zynqmp firmware uses clock ID
which is index only (e.g 0, 1, to n, where n is max_clock id).

To use zynqmp clock driver for versal platform also, extend use
of QueryAttribute API to fetch device class, subclass and clock type
to create clock device ID. In case of zynqmp this attributes would be
0 only, so there won't be any effect on clock id as it would use
clock index only.

Signed-off-by: Tejas Patel 
Signed-off-by: Rajan Vaja 
Signed-off-by: Michal Simek 
Signed-off-by: Jolly Shah 
---
 drivers/clk/zynqmp/clkc.c | 42 +-
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
index f65cc0f..c13b014 100644
--- a/drivers/clk/zynqmp/clkc.c
+++ b/drivers/clk/zynqmp/clkc.c
@@ -53,6 +53,10 @@
 #define RESERVED_CLK_NAME  ""
 
 #define CLK_VALID_MASK 0x1
+#define NODE_CLASS_SHIFT   26U
+#define NODE_SUBCLASS_SHIFT20U
+#define NODE_TYPE_SHIFT14U
+#define NODE_INDEX_SHIFT   0U
 
 enum clk_type {
CLK_TYPE_OUTPUT,
@@ -80,6 +84,7 @@ struct clock_parent {
  * @num_nodes: Number of nodes present in topology
  * @parent:Parent of clock
  * @num_parents:   Number of parents of clock
+ * @clk_id:Clock id
  */
 struct zynqmp_clock {
char clk_name[MAX_NAME_LEN];
@@ -89,6 +94,7 @@ struct zynqmp_clock {
u32 num_nodes;
struct clock_parent parent[MAX_PARENT];
u32 num_parents;
+   u32 clk_id;
 };
 
 static const char clk_type_postfix[][10] = {
@@ -396,7 +402,8 @@ static int zynqmp_clock_get_topology(u32 clk_id,
 
*num_nodes = 0;
for (j = 0; j <= MAX_NODES; j += 3) {
-   ret = zynqmp_pm_clock_get_topology(clk_id, j, pm_resp);
+   ret = zynqmp_pm_clock_get_topology(clock[clk_id].clk_id, j,
+  pm_resp);
if (ret)
return ret;
ret = __zynqmp_clock_get_topology(topology, pm_resp, num_nodes);
@@ -459,7 +466,8 @@ static int zynqmp_clock_get_parents(u32 clk_id, struct 
clock_parent *parents,
*num_parents = 0;
do {
/* Get parents from firmware */
-   ret = zynqmp_pm_clock_get_parents(clk_id, j, pm_resp);
+   ret = zynqmp_pm_clock_get_parents(clock[clk_id].clk_id, j,
+ pm_resp);
if (ret)
return ret;
 
@@ -528,13 +536,14 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
   const char **parent_names)
 {
int j;
-   u32 num_nodes;
+   u32 num_nodes, clk_dev_id;
char *clk_out = NULL;
struct clock_topology *nodes;
struct clk_hw *hw = NULL;
 
nodes = clock[clk_id].node;
num_nodes = clock[clk_id].num_nodes;
+   clk_dev_id = clock[clk_id].clk_id;
 
for (j = 0; j < num_nodes; j++) {
/*
@@ -551,13 +560,14 @@ static struct clk_hw *zynqmp_register_clk_topology(int 
clk_id, char *clk_name,
if (!clk_topology[nodes[j].type])
continue;
 
-   hw = (*clk_topology[nodes[j].type])(clk_out, clk_id,
+   hw = (*clk_topology[nodes[j].type])(clk_out, clk_dev_id,
parent_names,
num_parents,
[j]);
if (IS_ERR(hw))
-   pr_warn_once("%s() %s register fail with %ld\n",
-__func__, clk_name, PTR_ERR(hw));
+   pr_warn_once("%s() 0x%x: %s register fail with %ld\n",
+__func__,  clk_dev_id, clk_name,
+PTR_ERR(hw));
 
parent_names[0] = clk_out;
}
@@ -621,20 +631,26 @@ static int zynqmp_register_clocks(struct device_node *np)
 static void zynqmp_get_clock_info(void)
 {
int i, ret;
-   u32 attr, type = 0;
+   u32 attr, type = 0, nodetype, subclass, class;
 
for (i = 0; i < clock_max_idx; i++) {
-   zynqmp_pm_clock_get_name(i, clock[i].clk_name);
-   if (!strcmp(clock[i].clk_name, RESERVED_CLK_NAME))
-   continue;
-
ret = zynqmp_pm_clock_get_a

[PATCH] drivers: Defer probe if firmware is not ready

2019-03-04 Thread Jolly Shah
From: Rajan Vaja 

Driver needs ZynqMP firmware interface to call EEMI
APIs. In case firmware is not ready, dependent drivers
should wait until the firmware is ready.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 Documentation/xilinx/eemi.txt  |  4 ++--
 drivers/clk/zynqmp/clkc.c  |  4 ++--
 drivers/firmware/xilinx/zynqmp-debug.c |  3 ---
 drivers/firmware/xilinx/zynqmp.c   | 11 ++-
 drivers/nvmem/zynqmp_nvmem.c   | 10 +++---
 drivers/reset/reset-zynqmp.c   |  8 
 drivers/soc/xilinx/zynqmp_pm_domains.c | 18 ++
 drivers/soc/xilinx/zynqmp_power.c  | 10 ++
 drivers/spi/spi-zynqmp-gqspi.c |  5 +
 include/linux/firmware/xlnx-zynqmp.h   |  2 +-
 10 files changed, 47 insertions(+), 28 deletions(-)

diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt
index 0ab686c..5f39b4f 100644
--- a/Documentation/xilinx/eemi.txt
+++ b/Documentation/xilinx/eemi.txt
@@ -41,8 +41,8 @@ Example of EEMI ops usage:
int ret;
 
eemi_ops = zynqmp_pm_get_eemi_ops();
-   if (!eemi_ops)
-   return -ENXIO;
+   if (IS_ERR(eemi_ops))
+   return PTR_ERR(eemi_ops);
 
ret = eemi_ops->query_data(qdata, ret_payload);
 
diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
index c13b014..1e34e3e 100644
--- a/drivers/clk/zynqmp/clkc.c
+++ b/drivers/clk/zynqmp/clkc.c
@@ -711,8 +711,8 @@ static int zynqmp_clock_probe(struct platform_device *pdev)
struct device *dev = >dev;
 
eemi_ops = zynqmp_pm_get_eemi_ops();
-   if (!eemi_ops)
-   return -ENXIO;
+   if (IS_ERR(eemi_ops))
+   return PTR_ERR(eemi_ops);
 
ret = zynqmp_clk_setup(dev->of_node);
 
diff --git a/drivers/firmware/xilinx/zynqmp-debug.c 
b/drivers/firmware/xilinx/zynqmp-debug.c
index 2771df6..a3aa76c 100644
--- a/drivers/firmware/xilinx/zynqmp-debug.c
+++ b/drivers/firmware/xilinx/zynqmp-debug.c
@@ -90,9 +90,6 @@ static int process_api_request(u32 pm_id, u64 *pm_api_arg, 
u32 *pm_api_ret)
int ret;
struct zynqmp_pm_query_data qdata = {0};
 
-   if (!eemi_ops)
-   return -ENXIO;
-
switch (pm_id) {
case PM_GET_API_VERSION:
ret = eemi_ops->get_api_version(_api_version);
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 98f9361..87a1d63 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -24,6 +24,8 @@
 #include 
 #include "zynqmp-debug.h"
 
+static const struct zynqmp_eemi_ops *eemi_ops_tbl;
+
 static const struct mfd_cell firmware_devs[] = {
{
.name = "zynqmp_power_controller",
@@ -649,7 +651,11 @@ static const struct zynqmp_eemi_ops eemi_ops = {
  */
 const struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
-   return _ops;
+   if (eemi_ops_tbl)
+   return eemi_ops_tbl;
+   else
+   return ERR_PTR(-EPROBE_DEFER);
+
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_get_eemi_ops);
 
@@ -694,6 +700,9 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
pr_info("%s Trustzone version v%d.%d\n", __func__,
pm_tz_version >> 16, pm_tz_version & 0x);
 
+   /* Assign eemi_ops_table */
+   eemi_ops_tbl = _ops;
+
zynqmp_pm_api_debugfs_init();
 
ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, firmware_devs,
diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c
index 490c8fc..5893543 100644
--- a/drivers/nvmem/zynqmp_nvmem.c
+++ b/drivers/nvmem/zynqmp_nvmem.c
@@ -16,6 +16,8 @@ struct zynqmp_nvmem_data {
struct nvmem_device *nvmem;
 };
 
+static const struct zynqmp_eemi_ops *eemi_ops;
+
 static int zynqmp_nvmem_read(void *context, unsigned int offset,
 void *val, size_t bytes)
 {
@@ -23,9 +25,7 @@ static int zynqmp_nvmem_read(void *context, unsigned int 
offset,
int idcode, version;
struct zynqmp_nvmem_data *priv = context;
 
-   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
-
-   if (!eemi_ops || !eemi_ops->get_chipid)
+   if (!eemi_ops->get_chipid)
return -ENXIO;
 
ret = eemi_ops->get_chipid(, );
@@ -61,6 +61,10 @@ static int zynqmp_nvmem_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   eemi_ops = zynqmp_pm_get_eemi_ops();
+   if (IS_ERR(eemi_ops))
+   return PTR_ERR(eemi_ops);
+
priv->dev = dev;
econfig.dev = dev;
econfig.reg_read = zynqmp_nvmem_read;
diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
index 2ef1f13..99e75d9 100644
--- a/drivers/reset/reset-zynqmp.c
+++ b/drivers/reset/reset-zynqmp.c
@@ -79,11 +79,11 @@ static int zynqmp_reset_probe(struct platform_device *pdev)
if (!priv)
  

[PATCH 2/2] dt-bindings: xilinx: Separate clock binding from firmware doc

2019-02-27 Thread Jolly Shah
From: Rajan Vaja 

Clock description is part of firmware doc. Move clock description
in separate doc.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/clock/xlnx,zynqmp-clk.txt  | 63 ++
 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   | 54 +--
 2 files changed, 64 insertions(+), 53 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt

diff --git a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt 
b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
new file mode 100644
index 000..391ee1a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
@@ -0,0 +1,63 @@
+--
+Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
+Zynq MPSoC firmware interface
+--
+The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
+tree. It reads required input clock frequencies from the devicetree and acts
+as clock provider for all clock consumers of PS clocks.
+
+See clock_bindings.txt for more information on the generic clock bindings.
+
+Required properties:
+ - #clock-cells:   Must be 1
+ - compatible: Must contain:   "xlnx,zynqmp-clk"
+ - clocks: List of clock specifiers which are external input
+   clocks to the given clock controller. Please refer
+   the next section to find the input clocks for a
+   given controller.
+ - clock-names:List of clock names which are exteral input 
clocks
+   to the given clock controller. Please refer to the
+   clock bindings for more details.
+
+Input clocks for zynqmp Ultrascale+ clock controller:
+
+The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
+inputs. These required clock inputs are:
+ - pss_ref_clk (PS reference clock)
+ - video_clk (reference clock for video system )
+ - pss_alt_ref_clk (alternative PS reference clock)
+ - aux_ref_clk
+ - gt_crx_ref_clk (transceiver reference clock)
+
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source:
+ - swdt0_ext_clk
+ - swdt1_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - gem2_emio_clk
+ - gem3_emio_clk
+ - mio_clk_XX  # with XX = 00..77
+ - mio_clk_50_or_51#for the mux clock to gem tsu from 50 or 51
+
+
+Output clocks are registered based on clock information received
+from firmware. Output clocks indexes are mentioned in
+include/dt-bindings/clock/xlnx-zynqmp-clk.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   zynqmp_clk: clock-controller {
+   #clock-cells = <1>;
+   compatible = "xlnx,zynqmp-clk";
+   clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
+   clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
+   };
+   };
+};
diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 45d259c..a4fe136 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -17,53 +17,6 @@ Required properties:
  - "smc" : SMC #0, following the SMCCC
  - "hvc" : HVC #0, following the SMCCC
 
---
-Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
-Zynq MPSoC firmware interface
---
-The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
-tree. It reads required input clock frequencies from the devicetree and acts
-as clock provider for all clock consumers of PS clocks.
-
-See clock_bindings.txt for more information on the generic clock bindings.
-
-Required properties:
- - #clock-cells:   Must be 1
- - compatible: Must contain:   "xlnx,zynqmp-clk"
- - clocks: List of clock specifiers which are external input
-   clocks to the given clock controller. Please refer
-   the next section to find the input clocks for a
-   given controller.
- - clock-names:List of clock names which 

[PATCH 1/2] include: dt-binding: clock: Rename zynqmp header file

2019-02-27 Thread Jolly Shah
Rename file name of ZynqMP clk dt-bindings to align with
file name of reset and power dt-bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |   2 +-
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 ---
 include/dt-bindings/clock/xlnx-zynqmp-clk.h| 126 +
 3 files changed, 127 insertions(+), 117 deletions(-)
 delete mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h
 create mode 100644 include/dt-bindings/clock/xlnx-zynqmp-clk.h

diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 614bac5..45d259c 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -62,7 +62,7 @@ order to provide an optional (E)MIO clock source:
 
 Output clocks are registered based on clock information received
 from firmware. Output clocks indexes are mentioned in
-include/dt-bindings/clock/xlnx,zynqmp-clk.h.
+include/dt-bindings/clock/xlnx-zynqmp-clk.h.
 
 ---
 Example
diff --git a/include/dt-bindings/clock/xlnx,zynqmp-clk.h 
b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
deleted file mode 100644
index 4aebe6e..000
--- a/include/dt-bindings/clock/xlnx,zynqmp-clk.h
+++ /dev/null
@@ -1,116 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Xilinx Zynq MPSoC Firmware layer
- *
- *  Copyright (C) 2014-2018 Xilinx, Inc.
- *
- */
-
-#ifndef _DT_BINDINGS_CLK_ZYNQMP_H
-#define _DT_BINDINGS_CLK_ZYNQMP_H
-
-#define IOPLL  0
-#define RPLL   1
-#define APLL   2
-#define DPLL   3
-#define VPLL   4
-#define IOPLL_TO_FPD   5
-#define RPLL_TO_FPD6
-#define APLL_TO_LPD7
-#define DPLL_TO_LPD8
-#define VPLL_TO_LPD9
-#define ACPU   10
-#define ACPU_HALF  11
-#define DBF_FPD12
-#define DBF_LPD13
-#define DBG_TRACE  14
-#define DBG_TSTMP  15
-#define DP_VIDEO_REF   16
-#define DP_AUDIO_REF   17
-#define DP_STC_REF 18
-#define GDMA_REF   19
-#define DPDMA_REF  20
-#define DDR_REF21
-#define SATA_REF   22
-#define PCIE_REF   23
-#define GPU_REF24
-#define GPU_PP0_REF25
-#define GPU_PP1_REF26
-#define TOPSW_MAIN 27
-#define TOPSW_LSBUS28
-#define GTGREF0_REF29
-#define LPD_SWITCH 30
-#define LPD_LSBUS  31
-#define USB0_BUS_REF   32
-#define USB1_BUS_REF   33
-#define USB3_DUAL_REF  34
-#define USB0   35
-#define USB1   36
-#define CPU_R5 37
-#define CPU_R5_CORE38
-#define CSU_SPB39
-#define CSU_PLL40
-#define PCAP   41
-#define IOU_SWITCH 42
-#define GEM_TSU_REF43
-#define GEM_TSU44
-#define GEM0_REF   45
-#define GEM1_REF   46
-#define GEM2_REF   47
-#define GEM3_REF   48
-#define GEM0_TX49
-#define GEM1_TX50
-#define GEM2_TX51
-#define GEM3_TX52
-#define QSPI_REF   53
-#define SDIO0_REF  54
-#define SDIO1_REF  55
-#define UART0_REF  56
-#define UART1_REF  57
-#define SPI0_REF   58
-#define SPI1_REF   59
-#define NAND_REF   60
-#define I2C0_REF   61
-#define I2C1_REF   62
-#define CAN0_REF   63
-#define CAN1_REF   64
-#define CAN0   65
-#define CAN1   66
-#define DLL_REF67
-#define ADMA_REF   68
-#define TIMESTAMP_REF  69
-#define AMS_REF70
-#define PL0_REF71
-#define PL1_REF72
-#define PL2_REF73
-#define PL3_REF74
-#define WDT75
-#define IOPLL_INT  76
-#define IOPLL_PRE_SRC  77
-#define IOPLL_HALF 78
-#define IOPLL_INT_MUX  79
-#define IOPLL_POST_SRC 80
-#define RPLL_INT   81
-#define RPLL_PRE_SRC   82
-#define RPLL_HALF  83
-#define RPLL_INT_MUX   84
-#define RPLL_POST_SRC  85
-#define APLL_INT   86
-#define APLL_PRE_SRC   87
-#define APLL_HALF  88
-#define APLL_INT_MUX   89
-#define APLL_POST_SRC  90
-#define DPLL_INT

[PATCH 0/2] Rename dt header and move clock binding

2019-02-27 Thread Jolly Shah
This patchset renames clock dt include file to align with other incldues.
Other patch moves clock binding to a separate file under clock directory to
align with other firmware child binding documenetation.

Jolly Shah (1):
  include: dt-binding: clock: Rename zynqmp header file

Rajan Vaja (1):
  dt-bindings: xilinx: Separate clock binding from firmware doc

 .../devicetree/bindings/clock/xlnx,zynqmp-clk.txt  |  63 +++
 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  54 +
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 ---
 include/dt-bindings/clock/xlnx-zynqmp-clk.h| 126 +
 4 files changed, 190 insertions(+), 169 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
 delete mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h
 create mode 100644 include/dt-bindings/clock/xlnx-zynqmp-clk.h

-- 
2.7.4



[PATCH v4 2/3] firmware: xilinx: Add APIs to control node status/power

2019-02-01 Thread Jolly Shah
From: Rajan Vaja 

Add Xilinx ZynqMP firmware APIs to control node status
and power. These APIs allows turning on/off power domain
and setting capabilities of devices present in power domain.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 58 
 include/linux/firmware/xlnx-zynqmp.h | 26 
 2 files changed, 84 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8065e33..6660b8c 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -534,6 +534,61 @@ static int zynqmp_pm_set_suspend_mode(u32 mode)
return zynqmp_pm_invoke_fn(PM_SET_SUSPEND_MODE, mode, 0, 0, 0, NULL);
 }
 
+/**
+ * zynqmp_pm_request_node() - Request a node with specific capabilities
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This function is used by master to request particular node from firmware.
+ * Every master must request node before using it.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_request_node(const u32 node, const u32 capabilities,
+ const u32 qos,
+ const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_REQUEST_NODE, node, capabilities,
+  qos, ack, NULL);
+}
+
+/**
+ * zynqmp_pm_release_node() - Release a node
+ * @node:  Node ID of the slave
+ *
+ * This function is used by master to inform firmware that master
+ * has released node. Once released, master must not use that node
+ * without re-request.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_release_node(const u32 node)
+{
+   return zynqmp_pm_invoke_fn(PM_RELEASE_NODE, node, 0, 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This API function is to be used for slaves a PU already has requested
+ * to change its capabilities.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_set_requirement(const u32 node, const u32 capabilities,
+const u32 qos,
+const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_SET_REQUIREMENT, node, capabilities,
+  qos, ack, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -551,6 +606,9 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.reset_get_status = zynqmp_pm_reset_get_status,
.init_finalize = zynqmp_pm_init_finalize,
.set_suspend_mode = zynqmp_pm_set_suspend_mode,
+   .request_node = zynqmp_pm_request_node,
+   .release_node = zynqmp_pm_release_node,
+   .set_requirement = zynqmp_pm_set_requirement,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index f84d700..c7a7748 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -40,8 +40,19 @@
 /* Payload size (consists of callback API ID + arguments) */
 #define CB_PAYLOAD_SIZE (CB_ARG_CNT + 1)
 
+#define ZYNQMP_PM_MAX_QOS  100U
+
+/* Node capabilities */
+#defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
+#defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
+#defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+#defineZYNQMP_PM_CAPABILITY_POWER  0x8U
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_REQUEST_NODE = 13,
+   PM_RELEASE_NODE,
+   PM_SET_REQUIREMENT,
PM_RESET_ASSERT = 17,
PM_RESET_GET_STATUS,
PM_PM_INIT_FINALIZE = 21,
@@ -223,6 +234,12 @@ enum zynqmp_pm_suspend_reason {
SUSPEND_SYSTEM_SHUTDOWN,
 };
 
+enum zynqmp_pm_request_ack {
+   ZYNQMP_PM_REQUEST_ACK_NO = 1,
+   ZYNQMP_PM_REQUEST_ACK_BLOCKING,
+   ZYNQMP_PM_REQUEST_ACK_NON_BLOCKING,
+};
+
 /**
  * struct zynqmp_pm_query_data - PM query data
  * @qid:   query ID
@@ -255,6 +272,15 @@ struct zynqmp_eemi_ops {
int (*reset_get_status)(const enum zynqmp_pm_reset reset, u32 *status);
int (*init_finalize)(void);
int (*set_suspend_mode)(u32 mode);
+   int (*request_node)(const u32 node,
+   const u32 capabilities,
+   const u32 qos,
+   const enum

[PATCH v4 0/3] drivers: soc: xilinx: Add support for ZynqMP power domain driver

2019-02-01 Thread Jolly Shah
The zynqmp power domain driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

v4:
 - Added reviewed tag for dt bindings
 - Remove local device list for each domain and use list maintained in core 
genpd structure
 - Remove hardcoded pd-id to node ID mapping. Instead use argument passed in 
peripheral node as node ID. 
   Firmware would validate node ID when APIs requested from genpd ops.

v3:
 - Changed binding to have FW node as a power controller as suggested by Rob
 - Updated FW driver to register it as mfd child devices from firmware probe
 - Move bindings location as suggested

v2:
 - Rebased on top of latest firmware driver patch series
 - Updated driver name from zynqmp-genpd to zynqmp-power-controller
 - Updated device tree bindings to move power controller node under firmware 
node

Jolly Shah (1):
  drivers: soc: xilinx: Add ZynqMP power domain driver

Rajan Vaja (2):
  dt-bindings: power: Add ZynqMP power domain bindings
  firmware: xilinx: Add APIs to control node status/power

 .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 +++
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  73 +
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   1 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 321 +
 include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 +++
 include/linux/firmware/xlnx-zynqmp.h   |  26 ++
 8 files changed, 504 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

-- 
2.7.4



[PATCH v4 1/3] dt-bindings: power: Add ZynqMP power domain bindings

2019-02-01 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe ZynqMP power domain bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Reviewed-by: Rob Herring 
---
 .../bindings/power/xlnx,zynqmp-genpd.txt   | 34 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  | 39 ++
 2 files changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt 
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index 000..3c7f237
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must 
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   ...
+   #power-domain-cells = <1>;
+   ...
+   };
+};
+
+sata {
+   ...
+   power-domains = <_firmware 28>;
+   ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h 
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index 000..0d9a412
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_022
+#definePD_USB_123
+#definePD_TTC_024
+#definePD_TTC_125
+#definePD_TTC_226
+#definePD_TTC_327
+#definePD_SATA 28
+#definePD_ETH_029
+#definePD_ETH_130
+#definePD_ETH_231
+#definePD_ETH_332
+#definePD_UART_0   33
+#definePD_UART_1   34
+#definePD_SPI_035
+#definePD_SPI_136
+#definePD_I2C_037
+#definePD_I2C_138
+#definePD_SD_0 39
+#definePD_SD_1 40
+#definePD_DP   41
+#definePD_GDMA 42
+#definePD_ADMA 43
+#definePD_NAND 44
+#definePD_QSPI 45
+#definePD_GPIO 46
+#definePD_CAN_047
+#definePD_CAN_148
+#definePD_GPU  58
+#definePD_PCIE 59
+
+#endif
-- 
2.7.4



[PATCH v4 3/3] drivers: soc: xilinx: Add ZynqMP power domain driver

2019-02-01 Thread Jolly Shah
The zynqmp-genpd driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  15 ++
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   1 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 321 +
 5 files changed, 347 insertions(+)
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c

diff --git a/drivers/firmware/xilinx/Kconfig b/drivers/firmware/xilinx/Kconfig
index 8f44b9c..bd33bbf 100644
--- a/drivers/firmware/xilinx/Kconfig
+++ b/drivers/firmware/xilinx/Kconfig
@@ -6,6 +6,7 @@ menu "Zynq MPSoC Firmware Drivers"
 
 config ZYNQMP_FIRMWARE
bool "Enable Xilinx Zynq MPSoC firmware interface"
+   select MFD_CORE
help
  Firmware interface driver is used by different
  drivers to communicate with the firmware for
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 6660b8c..dab1350 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,12 @@
 #include 
 #include "zynqmp-debug.h"
 
+static const struct mfd_cell firmware_devs[] = {
+   {
+   .name = "zynqmp_power_controller",
+   },
+};
+
 /**
  * zynqmp_pm_ret_code() - Convert PMU-FW error codes to Linux error codes
  * @ret_status:PMUFW return code
@@ -665,11 +672,19 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
 
zynqmp_pm_api_debugfs_init();
 
+   ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, firmware_devs,
+ ARRAY_SIZE(firmware_devs), NULL, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "failed to add MFD devices %d\n", ret);
+   return ret;
+   }
+
return of_platform_populate(dev->of_node, NULL, NULL, dev);
 }
 
 static int zynqmp_firmware_remove(struct platform_device *pdev)
 {
+   mfd_remove_devices(>dev);
zynqmp_pm_api_debugfs_exit();
 
return 0;
diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index 5025e0e..01e76b5 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -28,4 +28,13 @@ config ZYNQMP_POWER
  power management callbacks from firmware.
  If in doubt, say N.
 
+config ZYNQMP_PM_DOMAINS
+   bool "Enable Zynq MPSoC generic PM domains"
+   default y
+   depends on PM && ARCH_ZYNQMP && ZYNQMP_FIRMWARE
+   select PM_GENERIC_DOMAINS
+   help
+ Say yes to enable device power management through PM domains
+ If in doubt, say N.
+
 endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index 428b9db..f66bfea 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
 obj-$(CONFIG_ZYNQMP_POWER) += zynqmp_power.o
+obj-$(CONFIG_ZYNQMP_PM_DOMAINS) += zynqmp_pm_domains.o
diff --git a/drivers/soc/xilinx/zynqmp_pm_domains.c 
b/drivers/soc/xilinx/zynqmp_pm_domains.c
new file mode 100644
index 000..354d256
--- /dev/null
+++ b/drivers/soc/xilinx/zynqmp_pm_domains.c
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Generic PM domain support
+ *
+ *  Copyright (C) 2015-2018 Xilinx, Inc.
+ *
+ *  Davorin Mista 
+ *  Jolly Shah 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define ZYNQMP_NUM_DOMAINS (100)
+/* Flag stating if PM nodes mapped to the PM domain has been requested */
+#define ZYNQMP_PM_DOMAIN_REQUESTED BIT(0)
+
+/**
+ * struct zynqmp_pm_domain - Wrapper around struct generic_pm_domain
+ * @gpd:   Generic power domain
+ * @node_id:   PM node ID corresponding to device inside PM domain
+ * @flags: ZynqMP PM domain flags
+ */
+struct zynqmp_pm_domain {
+   struct generic_pm_domain gpd;
+   u32 node_id;
+   u8 flags;
+};
+
+/**
+ * zynqmp_gpd_is_active_wakeup_path() - Check if device is in wakeup source
+ * path
+ * @dev:   Device to check for wakeup source path
+ * @not_used:  Data member (not required)
+ *
+ * This function is checks device's child hierarchy and checks if any device is
+ * set as wakeup source.
+ *
+ * Return: 1 if device is in wakeup source path else 0
+ */
+static int zynqmp_gpd_is_active_wakeup_path(struct device *dev, void *not_used)
+{
+   int may_wakeup;
+
+   may_wakeup = device_may_

RE: [PATCH v6 3/3] drivers: soc: xilinx: Add ZynqMP PM driver

2019-02-01 Thread Jolly Shah
Hi Sudeep,

> -Original Message-
> From: Sudeep Holla 
> Sent: Friday, February 01, 2019 4:15 AM
> To: Jolly Shah 
> Cc: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com; Rajan
> Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v6 3/3] drivers: soc: xilinx: Add ZynqMP PM driver
> 
> On Thu, Jan 31, 2019 at 07:01:05PM +, Jolly Shah wrote:
> > >
> > > NACK, if this is for system suspend/reset ? You can just use exiting
> > > sysfs, no need to create Xilinx specific new ones. Moreover you need to
> > > use PSCI to make sure higher ELs can do orderly suspend/shutdown.
> > >
> >
> > We have power off suspend mode which is not supported by existing sysfs and
> > hence new one is needed. Suspend is handled through PSCI interface only.
> >
> 
> I see only 2 cases supported SUSPEND_SYSTEM_SHUTDOWN and
> SUSPEND_POWER_REQUEST. Both are already support so my NACK still stands.

The 2 cases(SUSPEND_SYSTEM_SHUTDOWN and  SUSPEND_POWER_REQUEST )in isr is for 
remote suspend.  Sysfs is for self suspend and it supports PM_SUSPEND_MODE_STD 
and PM_SUSPEND_MODE_POWER_OFF(power off suspend).

Thanks,
Jolly Shah

> 
> --
> Regards,
> Sudeep


RE: [PATCH v6 3/3] drivers: soc: xilinx: Add ZynqMP PM driver

2019-01-31 Thread Jolly Shah
Hi Sudeep,

> -Original Message-
> From: Sudeep Holla 
> Sent: Wednesday, January 30, 2019 2:13 AM
> To: Jolly Shah 
> Cc: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com; Rajan
> Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Sudeep Holla
> ; Rajan Vaja ; Jolly Shah
> 
> Subject: Re: [PATCH v6 3/3] drivers: soc: xilinx: Add ZynqMP PM driver
> 
> On Tue, Jan 29, 2019 at 12:38:21PM -0800, Jolly Shah wrote:
> > From: Rajan Vaja 
> >
> > Add ZynqMP PM driver. PM driver provides power management
> > support for ZynqMP.
> >
> > Signed-off-by: Rajan Vaja 
> > Signed-off-by: Jolly Shah 
> > ---
> >  drivers/soc/xilinx/Kconfig|  11 +++
> >  drivers/soc/xilinx/Makefile   |   1 +
> >  drivers/soc/xilinx/zynqmp_power.c | 178
> ++
> >  3 files changed, 190 insertions(+)
> >  create mode 100644 drivers/soc/xilinx/zynqmp_power.c
> >
> > diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
> > index 687c8f3..5025e0e 100644
> > --- a/drivers/soc/xilinx/Kconfig
> > +++ b/drivers/soc/xilinx/Kconfig
> > @@ -17,4 +17,15 @@ config XILINX_VCU
> >   To compile this driver as a module, choose M here: the
> >   module will be called xlnx_vcu.
> >
> > +config ZYNQMP_POWER
> > +   bool "Enable Xilinx Zynq MPSoC Power Management driver"
> > +   depends on PM && ARCH_ZYNQMP
> > +   default y
> > +   help
> > + Say yes to enable power management support for ZyqnMP SoC.
> > + This driver uses firmware driver as an interface for power
> > + management request to firmware. It registers isr to handle
> > + power management callbacks from firmware.
> > + If in doubt, say N.
> > +
> >  endmenu
> > diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
> > index dee8fd5..428b9db 100644
> > --- a/drivers/soc/xilinx/Makefile
> > +++ b/drivers/soc/xilinx/Makefile
> > @@ -1,2 +1,3 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
> > +obj-$(CONFIG_ZYNQMP_POWER) += zynqmp_power.o
> > diff --git a/drivers/soc/xilinx/zynqmp_power.c
> b/drivers/soc/xilinx/zynqmp_power.c
> > new file mode 100644
> > index 000..771cb59
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp_power.c
> > @@ -0,0 +1,178 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx Zynq MPSoC Power Management
> > + *
> > + *  Copyright (C) 2014-2018 Xilinx, Inc.
> > + *
> > + *  Davorin Mista 
> > + *  Jolly Shah 
> > + *  Rajan Vaja 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +enum pm_suspend_mode {
> > +   PM_SUSPEND_MODE_FIRST = 0,
> > +   PM_SUSPEND_MODE_STD = PM_SUSPEND_MODE_FIRST,
> > +   PM_SUSPEND_MODE_POWER_OFF,
> > +};
> > +
> > +#define PM_SUSPEND_MODE_FIRST  PM_SUSPEND_MODE_STD
> > +
> > +static const char *const suspend_modes[] = {
> > +   [PM_SUSPEND_MODE_STD] = "standard",
> > +   [PM_SUSPEND_MODE_POWER_OFF] = "power-off",
> > +};
> > +
> > +static enum pm_suspend_mode suspend_mode = PM_SUSPEND_MODE_STD;
> > +
> > +enum pm_api_cb_id {
> > +   PM_INIT_SUSPEND_CB = 30,
> > +   PM_ACKNOWLEDGE_CB,
> > +   PM_NOTIFY_CB,
> > +};
> > +
> > +static void zynqmp_pm_get_callback_data(u32 *buf)
> > +{
> > +   zynqmp_pm_invoke_fn(GET_CALLBACK_DATA, 0, 0, 0, 0, buf);
> > +}
> > +
> > +static irqreturn_t zynqmp_pm_isr(int irq, void *data)
> > +{
> > +   u32 payload[CB_PAYLOAD_SIZE];
> > +
> > +   zynqmp_pm_get_callback_data(payload);
> > +
> > +   /* First element is callback API ID, others are callback arguments */
> > +   if (payload[0] == PM_INIT_SUSPEND_CB) {
> > +   switch (payload[1]) {
> > +   case SUSPEND_SYSTEM_SHUTDOWN:
> > +   orderly_poweroff(true);
> > +   break;
> > +   case SUSPEND_POWER_REQUEST:
> > +   pm_suspend(PM_SUSPEND_MEM);
> > +   break;
> > +   default:
> > +   pr_err("%s Unsupported InitSuspendCb reason "
> >

[PATCH v6 1/3] dt-bindings: soc: Add ZynqMP PM bindings

2019-01-29 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Reviewed-by: Rob Herring 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



RE: [PATCH v5 2/3] firmware: xilinx: Implement ZynqMP power management APIs

2019-01-29 Thread Jolly Shah
Hi Michal,

> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Tuesday, January 29, 2019 5:11 AM
> To: Jolly Shah ; matthias@gmail.com;
> andy.gr...@linaro.org; shawn...@kernel.org; geert+rene...@glider.be;
> bjorn.anders...@linaro.org; sean.w...@mediatek.com;
> m.szyprow...@samsung.com; Michal Simek ;
> robh...@kernel.org; mark.rutl...@arm.com
> Cc: Rajan Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Rajan Vaja
> ; Jolly Shah 
> Subject: Re: [PATCH v5 2/3] firmware: xilinx: Implement ZynqMP power
> management APIs
> 
> On 14. 01. 19 20:22, Jolly Shah wrote:
> > From: Rajan Vaja 
> >
> > Add Xilinx ZynqMP firmware APIs to set suspend mode
> > and inform firmware that master has initialized its
> > own power management.
> >
> > Signed-off-by: Rajan Vaja 
> > Signed-off-by: Jolly Shah 
> > ---
> >  drivers/firmware/xilinx/zynqmp.c | 29 +
> >  include/linux/firmware/xlnx-zynqmp.h | 20 
> >  2 files changed, 49 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> b/drivers/firmware/xilinx/zynqmp.c
> > index 84b3fd2..c7a3b6c 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -428,6 +428,33 @@ static int zynqmp_pm_clock_getparent(u32 clock_id,
> u32 *parent_id)
> > return ret;
> >  }
> >
> > +/**
> > + * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
> > + *master has initialized its own power management
> > + *
> > + * This API function is to be used for notify the power management 
> > controller
> > + * about the completed power management initialization.
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int zynqmp_pm_init_finalize(void)
> > +{
> > +   return zynqmp_pm_invoke_fn(PM_PM_INIT_FINALIZE, 0, 0, 0, 0, NULL);
> > +}
> > +
> > +/**
> > + * zynqmp_pm_set_suspend_mode()- Set system suspend mode
> > + * @mode:  Mode to set for system suspend
> > + *
> > + * This API function is used to set mode of system suspend.
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int zynqmp_pm_set_suspend_mode(u32 mode)
> > +{
> > +   return zynqmp_pm_invoke_fn(PM_SET_SUSPEND_MODE, mode, 0, 0, 0,
> NULL);
> > +}
> > +
> >  static const struct zynqmp_eemi_ops eemi_ops = {
> > .get_api_version = zynqmp_pm_get_api_version,
> > .query_data = zynqmp_pm_query_data,
> > @@ -440,6 +467,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
> > .clock_getrate = zynqmp_pm_clock_getrate,
> > .clock_setparent = zynqmp_pm_clock_setparent,
> > .clock_getparent = zynqmp_pm_clock_getparent,
> > +   .init_finalize = zynqmp_pm_init_finalize,
> > +   .set_suspend_mode = zynqmp_pm_set_suspend_mode,
> 
> This has been created long time ago and there was one more patch in the
> middle of this.
> I have applied reset driver just now which didn't have any issue that's
> why please rebase your patches on the top of this branch
> https://github.com/Xilinx/linux-xlnx/commits/zynqmp/soc and resend.
> 

Rebased and sent v6.

Thanks,
Jolly Shah

> Thanks,
> Michal


[PATCH v6 3/3] drivers: soc: xilinx: Add ZynqMP PM driver

2019-01-29 Thread Jolly Shah
From: Rajan Vaja 

Add ZynqMP PM driver. PM driver provides power management
support for ZynqMP.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/soc/xilinx/Kconfig|  11 +++
 drivers/soc/xilinx/Makefile   |   1 +
 drivers/soc/xilinx/zynqmp_power.c | 178 ++
 3 files changed, 190 insertions(+)
 create mode 100644 drivers/soc/xilinx/zynqmp_power.c

diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index 687c8f3..5025e0e 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -17,4 +17,15 @@ config XILINX_VCU
  To compile this driver as a module, choose M here: the
  module will be called xlnx_vcu.
 
+config ZYNQMP_POWER
+   bool "Enable Xilinx Zynq MPSoC Power Management driver"
+   depends on PM && ARCH_ZYNQMP
+   default y
+   help
+ Say yes to enable power management support for ZyqnMP SoC.
+ This driver uses firmware driver as an interface for power
+ management request to firmware. It registers isr to handle
+ power management callbacks from firmware.
+ If in doubt, say N.
+
 endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index dee8fd5..428b9db 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
+obj-$(CONFIG_ZYNQMP_POWER) += zynqmp_power.o
diff --git a/drivers/soc/xilinx/zynqmp_power.c 
b/drivers/soc/xilinx/zynqmp_power.c
new file mode 100644
index 000..771cb59
--- /dev/null
+++ b/drivers/soc/xilinx/zynqmp_power.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Zynq MPSoC Power Management
+ *
+ *  Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ *  Davorin Mista 
+ *  Jolly Shah 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum pm_suspend_mode {
+   PM_SUSPEND_MODE_FIRST = 0,
+   PM_SUSPEND_MODE_STD = PM_SUSPEND_MODE_FIRST,
+   PM_SUSPEND_MODE_POWER_OFF,
+};
+
+#define PM_SUSPEND_MODE_FIRST  PM_SUSPEND_MODE_STD
+
+static const char *const suspend_modes[] = {
+   [PM_SUSPEND_MODE_STD] = "standard",
+   [PM_SUSPEND_MODE_POWER_OFF] = "power-off",
+};
+
+static enum pm_suspend_mode suspend_mode = PM_SUSPEND_MODE_STD;
+
+enum pm_api_cb_id {
+   PM_INIT_SUSPEND_CB = 30,
+   PM_ACKNOWLEDGE_CB,
+   PM_NOTIFY_CB,
+};
+
+static void zynqmp_pm_get_callback_data(u32 *buf)
+{
+   zynqmp_pm_invoke_fn(GET_CALLBACK_DATA, 0, 0, 0, 0, buf);
+}
+
+static irqreturn_t zynqmp_pm_isr(int irq, void *data)
+{
+   u32 payload[CB_PAYLOAD_SIZE];
+
+   zynqmp_pm_get_callback_data(payload);
+
+   /* First element is callback API ID, others are callback arguments */
+   if (payload[0] == PM_INIT_SUSPEND_CB) {
+   switch (payload[1]) {
+   case SUSPEND_SYSTEM_SHUTDOWN:
+   orderly_poweroff(true);
+   break;
+   case SUSPEND_POWER_REQUEST:
+   pm_suspend(PM_SUSPEND_MEM);
+   break;
+   default:
+   pr_err("%s Unsupported InitSuspendCb reason "
+   "code %d\n", __func__, payload[1]);
+   }
+   }
+
+   return IRQ_HANDLED;
+}
+
+static ssize_t suspend_mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   char *s = buf;
+   int md;
+
+   for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
+   if (suspend_modes[md]) {
+   if (md == suspend_mode)
+   s += sprintf(s, "[%s] ", suspend_modes[md]);
+   else
+   s += sprintf(s, "%s ", suspend_modes[md]);
+   }
+
+   /* Convert last space to newline */
+   if (s != buf)
+   *(s - 1) = '\n';
+   return (s - buf);
+}
+
+static ssize_t suspend_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   int md, ret = -EINVAL;
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+   if (!eemi_ops || !eemi_ops->set_suspend_mode)
+   return ret;
+
+   for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
+   if (suspend_modes[md] &&
+   sysfs_streq(suspend_modes[md], buf)) {
+   ret = 0;
+   break;
+   }
+
+   if (!ret && md != suspend_mode) {
+   ret = eemi_ops->set_suspend_mode(md);
+   if (likely(!ret))
+   suspend_mode = 

[PATCH v6 2/3] firmware: xilinx: Implement ZynqMP power management APIs

2019-01-29 Thread Jolly Shah
Add Xilinx ZynqMP firmware APIs to set suspend mode
and inform firmware that master has initialized its
own power management.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 29 +
 include/linux/firmware/xlnx-zynqmp.h | 20 
 2 files changed, 49 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 70b5037..8065e33 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -507,6 +507,33 @@ static int zynqmp_pm_reset_get_status(const enum 
zynqmp_pm_reset reset,
return ret;
 }
 
+/**
+ * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
+ *master has initialized its own power management
+ *
+ * This API function is to be used for notify the power management controller
+ * about the completed power management initialization.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_init_finalize(void)
+{
+   return zynqmp_pm_invoke_fn(PM_PM_INIT_FINALIZE, 0, 0, 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_set_suspend_mode()- Set system suspend mode
+ * @mode:  Mode to set for system suspend
+ *
+ * This API function is used to set mode of system suspend.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_set_suspend_mode(u32 mode)
+{
+   return zynqmp_pm_invoke_fn(PM_SET_SUSPEND_MODE, mode, 0, 0, 0, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -522,6 +549,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.ioctl = zynqmp_pm_ioctl,
.reset_assert = zynqmp_pm_reset_assert,
.reset_get_status = zynqmp_pm_reset_get_status,
+   .init_finalize = zynqmp_pm_init_finalize,
+   .set_suspend_mode = zynqmp_pm_set_suspend_mode,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 07c587a..f84d700 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -28,14 +28,23 @@
 /* SMC SIP service Call Function Identifier Prefix */
 #define PM_SIP_SVC 0xC200
 #define PM_GET_TRUSTZONE_VERSION   0xa03
+#define PM_SET_SUSPEND_MODE0xa02
+#define GET_CALLBACK_DATA  0xa01
 
 /* Number of 32bits values in payload */
 #define PAYLOAD_ARG_CNT4U
 
+/* Number of arguments for a callback */
+#define CB_ARG_CNT 4
+
+/* Payload size (consists of callback API ID + arguments) */
+#define CB_PAYLOAD_SIZE (CB_ARG_CNT + 1)
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
PM_RESET_ASSERT = 17,
PM_RESET_GET_STATUS,
+   PM_PM_INIT_FINALIZE = 21,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -208,6 +217,12 @@ enum zynqmp_pm_reset {
ZYNQMP_PM_RESET_END = ZYNQMP_PM_RESET_PS_PL3
 };
 
+enum zynqmp_pm_suspend_reason {
+   SUSPEND_POWER_REQUEST = 201,
+   SUSPEND_ALERT,
+   SUSPEND_SYSTEM_SHUTDOWN,
+};
+
 /**
  * struct zynqmp_pm_query_data - PM query data
  * @qid:   query ID
@@ -238,8 +253,13 @@ struct zynqmp_eemi_ops {
int (*reset_assert)(const enum zynqmp_pm_reset reset,
const enum zynqmp_pm_reset_action assert_flag);
int (*reset_get_status)(const enum zynqmp_pm_reset reset, u32 *status);
+   int (*init_finalize)(void);
+   int (*set_suspend_mode)(u32 mode);
 };
 
+int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
+   u32 arg2, u32 arg3, u32 *ret_payload);
+
 #if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
 const struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void);
 #else
-- 
2.7.4



[PATCH v6 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver

2019-01-29 Thread Jolly Shah
Add ZynqMP PM driver. PM driver provides power management
support for ZynqMP.

v6:
 - Rebased on top of 
https://github.com/Xilinx/linux-xlnx/commits/zynqmp/soc
v5:
 - Added Reviewed tag for dt bindings

v4:
 - Minor fixes to address v3 review comments
 
v3:
 - Updated DT bindings as per v2 review comments
 
v2:
 - Rebased on top of latest firmware driver patch series
 - Updated driver to use shared interrupt instead of mailbox

Jolly Shah (1):
  firmware: xilinx: Implement ZynqMP power management APIs

Rajan Vaja (2):
  dt-bindings: soc: Add ZynqMP PM bindings
  drivers: soc: xilinx: Add ZynqMP PM driver

 .../bindings/power/reset/xlnx,zynqmp-power.txt |  25 +++
 drivers/firmware/xilinx/zynqmp.c   |  29 
 drivers/soc/xilinx/Kconfig |  11 ++
 drivers/soc/xilinx/Makefile|   1 +
 drivers/soc/xilinx/zynqmp_power.c  | 178 +
 include/linux/firmware/xlnx-zynqmp.h   |  20 +++
 6 files changed, 264 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
 create mode 100644 drivers/soc/xilinx/zynqmp_power.c

-- 
2.7.4



[PATCH v5 1/3] dt-bindings: soc: Add ZynqMP PM bindings

2019-01-14 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Reviewed-by: Rob Herring 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



[PATCH v5 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver

2019-01-14 Thread Jolly Shah
Add ZynqMP PM driver. PM driver provides power management
support for ZynqMP.

v5:
 - Added Reviewed tag for dt bindings

v4:
 - Minor fixes to address v3 review comments
 
v3:
 - Updated DT bindings as per v2 review comments
 
v2:
 - Rebased on top of latest firmware driver patch series
 - Updated driver to use shared interrupt instead of mailbox

Rajan Vaja (3):
  dt-bindings: soc: Add ZynqMP PM bindings
  firmware: xilinx: Implement ZynqMP power management APIs
  drivers: soc: xilinx: Add ZynqMP PM driver

 .../bindings/power/reset/xlnx,zynqmp-power.txt |  25 +++
 drivers/firmware/xilinx/zynqmp.c   |  29 
 drivers/soc/xilinx/Kconfig |  11 ++
 drivers/soc/xilinx/Makefile|   1 +
 drivers/soc/xilinx/zynqmp_power.c  | 178 +
 include/linux/firmware/xlnx-zynqmp.h   |  20 +++
 6 files changed, 264 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
 create mode 100644 drivers/soc/xilinx/zynqmp_power.c

-- 
2.7.4



[PATCH v5 3/3] drivers: soc: xilinx: Add ZynqMP PM driver

2019-01-14 Thread Jolly Shah
From: Rajan Vaja 

Add ZynqMP PM driver. PM driver provides power management
support for ZynqMP.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/soc/xilinx/Kconfig|  11 +++
 drivers/soc/xilinx/Makefile   |   1 +
 drivers/soc/xilinx/zynqmp_power.c | 178 ++
 3 files changed, 190 insertions(+)
 create mode 100644 drivers/soc/xilinx/zynqmp_power.c

diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index 687c8f3..5025e0e 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -17,4 +17,15 @@ config XILINX_VCU
  To compile this driver as a module, choose M here: the
  module will be called xlnx_vcu.
 
+config ZYNQMP_POWER
+   bool "Enable Xilinx Zynq MPSoC Power Management driver"
+   depends on PM && ARCH_ZYNQMP
+   default y
+   help
+ Say yes to enable power management support for ZyqnMP SoC.
+ This driver uses firmware driver as an interface for power
+ management request to firmware. It registers isr to handle
+ power management callbacks from firmware.
+ If in doubt, say N.
+
 endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index dee8fd5..428b9db 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
+obj-$(CONFIG_ZYNQMP_POWER) += zynqmp_power.o
diff --git a/drivers/soc/xilinx/zynqmp_power.c 
b/drivers/soc/xilinx/zynqmp_power.c
new file mode 100644
index 000..771cb59
--- /dev/null
+++ b/drivers/soc/xilinx/zynqmp_power.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Zynq MPSoC Power Management
+ *
+ *  Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ *  Davorin Mista 
+ *  Jolly Shah 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum pm_suspend_mode {
+   PM_SUSPEND_MODE_FIRST = 0,
+   PM_SUSPEND_MODE_STD = PM_SUSPEND_MODE_FIRST,
+   PM_SUSPEND_MODE_POWER_OFF,
+};
+
+#define PM_SUSPEND_MODE_FIRST  PM_SUSPEND_MODE_STD
+
+static const char *const suspend_modes[] = {
+   [PM_SUSPEND_MODE_STD] = "standard",
+   [PM_SUSPEND_MODE_POWER_OFF] = "power-off",
+};
+
+static enum pm_suspend_mode suspend_mode = PM_SUSPEND_MODE_STD;
+
+enum pm_api_cb_id {
+   PM_INIT_SUSPEND_CB = 30,
+   PM_ACKNOWLEDGE_CB,
+   PM_NOTIFY_CB,
+};
+
+static void zynqmp_pm_get_callback_data(u32 *buf)
+{
+   zynqmp_pm_invoke_fn(GET_CALLBACK_DATA, 0, 0, 0, 0, buf);
+}
+
+static irqreturn_t zynqmp_pm_isr(int irq, void *data)
+{
+   u32 payload[CB_PAYLOAD_SIZE];
+
+   zynqmp_pm_get_callback_data(payload);
+
+   /* First element is callback API ID, others are callback arguments */
+   if (payload[0] == PM_INIT_SUSPEND_CB) {
+   switch (payload[1]) {
+   case SUSPEND_SYSTEM_SHUTDOWN:
+   orderly_poweroff(true);
+   break;
+   case SUSPEND_POWER_REQUEST:
+   pm_suspend(PM_SUSPEND_MEM);
+   break;
+   default:
+   pr_err("%s Unsupported InitSuspendCb reason "
+   "code %d\n", __func__, payload[1]);
+   }
+   }
+
+   return IRQ_HANDLED;
+}
+
+static ssize_t suspend_mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   char *s = buf;
+   int md;
+
+   for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
+   if (suspend_modes[md]) {
+   if (md == suspend_mode)
+   s += sprintf(s, "[%s] ", suspend_modes[md]);
+   else
+   s += sprintf(s, "%s ", suspend_modes[md]);
+   }
+
+   /* Convert last space to newline */
+   if (s != buf)
+   *(s - 1) = '\n';
+   return (s - buf);
+}
+
+static ssize_t suspend_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   int md, ret = -EINVAL;
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+   if (!eemi_ops || !eemi_ops->set_suspend_mode)
+   return ret;
+
+   for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
+   if (suspend_modes[md] &&
+   sysfs_streq(suspend_modes[md], buf)) {
+   ret = 0;
+   break;
+   }
+
+   if (!ret && md != suspend_mode) {
+   ret = eemi_ops->set_suspend_mode(md);
+   if (likely(!ret))
+   suspend_mode = 

[PATCH v5 2/3] firmware: xilinx: Implement ZynqMP power management APIs

2019-01-14 Thread Jolly Shah
From: Rajan Vaja 

Add Xilinx ZynqMP firmware APIs to set suspend mode
and inform firmware that master has initialized its
own power management.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 29 +
 include/linux/firmware/xlnx-zynqmp.h | 20 
 2 files changed, 49 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..c7a3b6c 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,33 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32 
*parent_id)
return ret;
 }
 
+/**
+ * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
+ *master has initialized its own power management
+ *
+ * This API function is to be used for notify the power management controller
+ * about the completed power management initialization.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_init_finalize(void)
+{
+   return zynqmp_pm_invoke_fn(PM_PM_INIT_FINALIZE, 0, 0, 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_set_suspend_mode()- Set system suspend mode
+ * @mode:  Mode to set for system suspend
+ *
+ * This API function is used to set mode of system suspend.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_set_suspend_mode(u32 mode)
+{
+   return zynqmp_pm_invoke_fn(PM_SET_SUSPEND_MODE, mode, 0, 0, 0, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +467,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+   .init_finalize = zynqmp_pm_init_finalize,
+   .set_suspend_mode = zynqmp_pm_set_suspend_mode,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..1424170 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -28,12 +28,21 @@
 /* SMC SIP service Call Function Identifier Prefix */
 #define PM_SIP_SVC 0xC200
 #define PM_GET_TRUSTZONE_VERSION   0xa03
+#define PM_SET_SUSPEND_MODE0xa02
+#define GET_CALLBACK_DATA  0xa01
 
 /* Number of 32bits values in payload */
 #define PAYLOAD_ARG_CNT4U
 
+/* Number of arguments for a callback */
+#define CB_ARG_CNT 4
+
+/* Payload size (consists of callback API ID + arguments) */
+#define CB_PAYLOAD_SIZE (CB_ARG_CNT + 1)
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_PM_INIT_FINALIZE = 21,
PM_QUERY_DATA = 35,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
@@ -73,6 +82,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_ATTRIBUTES,
 };
 
+enum zynqmp_pm_suspend_reason {
+   SUSPEND_POWER_REQUEST = 201,
+   SUSPEND_ALERT,
+   SUSPEND_SYSTEM_SHUTDOWN,
+};
+
 /**
  * struct zynqmp_pm_query_data - PM query data
  * @qid:   query ID
@@ -99,8 +114,13 @@ struct zynqmp_eemi_ops {
int (*clock_getrate)(u32 clock_id, u64 *rate);
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
+   int (*init_finalize)(void);
+   int (*set_suspend_mode)(u32 mode);
 };
 
+int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
+   u32 arg2, u32 arg3, u32 *ret_payload);
+
 #if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
 const struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void);
 #else
-- 
2.7.4



[PATCH v2 4/4] dt-bindings: pinctrl: Add ZynqMP pin controller bindings

2019-01-04 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP pin controller
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt   | 275 +
 1 file changed, 275 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
new file mode 100644
index 000..acf44a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
@@ -0,0 +1,275 @@
+   Binding for Xilinx ZynqMP Pinctrl
+
+Required properties:
+- compatible: "xlnx,zynqmp-pinctrl"
+
+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.
+
+Required properties for pinmux nodes are:
+ - groups: A list of pinmux groups.
+ - function: The name of a pinmux function to activate for the specified set
+   of groups.
+
+Required properties for configuration nodes:
+One of:
+ - pins: A list of pin names
+ - groups: A list of pinmux groups.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+ groups, function
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+ groups, pins, bias-disable, bias-pull-up, bias-pull-down, slew-rate
+
+ Valid arguments for 'slew-rate' are 'SLEW_RATE_SLOW' and 'SLEW_RATE_FAST' to
+ select between slow and fast respectively.
+
+ Valid values for groups are:
+ 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_10_grp, sdio1_11_grp,
+ sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+ sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+ sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+ sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+ nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+ nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+ can0_1_grp, can0_2_grp, can0_3_grp,
+ can0_4_grp, can0_5_grp, can0_6_grp,
+ can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can0_11_grp, can0_12_grp,
+ can0_13_grp, can0_14_grp, can0_15_grp,
+ can0_16_grp, can0_17_grp, can0_18_grp,
+ can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp,
+ can1_6_grp, can1_7_grp, can1_8_grp,
+ can1_9_grp, can1_10_grp, can1_11_grp,
+ can1_12_grp, can1_13_grp, can1_14_grp,
+ can1_15_grp, can1_16_grp, can1_17_grp,
+ can1_18_grp, can1_19_grp, uart0_0_grp,
+ uart0_1_grp, uart0_2_grp, uart0_3_grp,
+ uart0_4_grp, uart

[PATCH v2 3/4] dt-bindings: reset: Add bindings for ZynqMP reset driver

2019-01-04 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP reset driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/reset/xlnx,zynqmp-reset.txt   | 148 +
 1 file changed, 148 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt 
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
new file mode 100644
index 000..e9c1af8
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -0,0 +1,148 @@
+--
+ =  Zynq UltraScale+ MPSoC reset driver binding =
+--
+The Zynq UltraScale+ MPSoC has several different resets.
+
+See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
+about zynqmp resets.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required Properties:
+- #reset-cells:Specifies the number of cells needed to encode reset
+   line, should be 1
+
+Reset outputs:
+   0   :PCIE config reset.
+   1   :PCIE bridge block level reset (AXI interface).
+   2   :PCIE control block level,reset.
+   3   :Display Port block level reset (includes DPDMA).
+   4   :FPD WDT reset.
+   5   :AF_FM5 block level reset.
+   6   :AF_FM4 block level reset.
+   7   :AF_FM3 block level reset.
+   8   :AF_FM2 block level reset.
+   9   :AF_FM1 block level reset.
+   10  :AF_FM0 block level reset.
+   11  :GDMA block level reset.
+   12  :Pixel Processor (GPU_PP1) block level reset.
+   13  :Pixel Processor (GPU_PP0) block level reset.
+   14  :GPU block level reset.
+   15  :GT block level reset.
+   16  :Sata block level reset.
+   17  :ACPU3 power on reset.
+   18  :ACPU2 power on reset.
+   19  :ACPU1 power on reset.
+   20  :ACPU0 power on reset.
+   21  :APU L2 reset.
+   22  :ACPU3 reset.
+   23  :ACPU2 reset.
+   24  :ACPU1 reset.
+   25  :ACPU0 reset.
+   26  :DDR block level reset inside of the DDR Sub System.
+   27  :APM block level reset inside of the DDR Sub System.
+   28  :soft reset.
+   29  :GEM 0 reset.
+   30  :GEM 1 reset.
+   31  :GEM 2 reset.
+   32  :GEM 3 reset.
+   33  :qspi reset.
+   34  :uart0 reset.
+   35  :uart1 reset.
+   36  :spi0 reset.
+   37  :spi1 reset.
+   38  :sdio0 reset.
+   39  :sdio1 reset.
+   40  :can0 reset.
+   41  :can1 reset.
+   42  :i2c0 reset.
+   43  :i2c1 reset.
+   44  :ttc0 reset.
+   45  :ttc1 reset.
+   46  :ttc2 reset.
+   47  :ttc3 reset.
+   48  :swdt reset.
+   49  :nand reset.
+   50  :adma reset.
+   51  :gpio reset.
+   52  :iou_cc reset.
+   53  :timestamp reset.
+   54  :rpu_r50 reset.
+   55  :rpu r51 reset.
+   56  :rpu_amba reset.
+   57  :ocm reset.
+   58  :rpu_pge reset.
+   59  :usb0_core reset.
+   60  :usb1_core reset.
+   61  :usb0_hiber reset.
+   62  :usb1_hiber reset.
+   63  :usb0_apb reset.
+   64  :usb1_apb reset.
+   65  :ipi reset.
+   66  :apm reset.
+   67  :rtc reset.
+   68  :sysmon reset.
+   69  :afi_fm6 reset.
+   70  :lpd_swdt reset.
+   71  :fpd_reset.
+   72  :rpu_dbg1 reset.
+   73  :rpu_dbg0 reset.
+   74  :dbg_lpd reset.
+   75  :dbg_fpd reset.
+   76  :apll reset.
+   77  :dpll reset.
+   78  :vpll reset.
+   79  :iopll reset.
+   80  :rpll reset.
+   81  :gpio_pl_0 reset.
+   82  :gpio_pl_1 reset.
+   83  :gpio_pl_2 reset.
+   84  :gpio_pl_3 reset.
+   85  :gpio_pl_4 reset.
+   86  :gpio_pl_5 reset.
+   87  :gpio_pl_6 reset.
+   88  :gpio_pl_7 reset.
+   89  :gpio_pl_8 reset.
+   90  :gpio_pl_9 reset.
+   91  :gpio_pl_10 reset.
+   92  :gpio_pl_11 reset.
+   93  :gpio_pl_12 reset.
+   94  :gpio_pl_13 reset.
+   95  :gpio_pl_14 reset.
+   96  :gpio_pl_15 reset.
+   97  :gpio_pl_16 reset.
+   98  :gpio_pl_17 reset.
+   99  :gpio_pl_18 reset.
+   100 :gpio_pl_19 reset.
+   101 :gpio_pl_20 reset.
+   102 :gpio_pl_21 reset.
+   103 :gpio_pl_22 reset.
+   104 :gpio_pl_23 reset.
+   105 :gpio_pl_24 reset.
+   106 :gpio_pl_25 reset.
+   107 :gpio_pl_26 reset.
+   108 :gpio_pl_27 reset.
+   109 :gpio_pl_28 reset.
+   110 :gpio_pl_29 reset.
+   111 :gpio_pl_30 reset.
+   112 :gpio_pl_31 reset.
+   113 :rpu_ls reset.
+   114 :ps_only reset.
+   115 :pl reset.
+   116 :ps_pl0 reset
+   117 :ps_pl1 reset
+   118 :ps_pl2 reset
+   119 :ps_pl3 reset
+
+---
+Example
+---
+
+firmware

[PATCH v2 1/4] dt-bindings: power: Add ZynqMP power domain bindings

2019-01-04 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe ZynqMP power domain bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/xlnx,zynqmp-genpd.txt   | 34 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  | 39 ++
 2 files changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt 
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index 000..3c7f237
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must 
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   ...
+   #power-domain-cells = <1>;
+   ...
+   };
+};
+
+sata {
+   ...
+   power-domains = <_firmware 2>;
+   ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h 
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index 000..1bc9636
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_00
+#definePD_USB_11
+#definePD_SATA 2
+#definePD_SPI_03
+#definePD_SPI_14
+#definePD_UART_0   5
+#definePD_UART_1   6
+#definePD_ETH_07
+#definePD_ETH_18
+#definePD_ETH_29
+#definePD_ETH_310
+#definePD_I2C_011
+#definePD_I2C_112
+#definePD_DP   13
+#definePD_GDMA 14
+#definePD_ADMA 15
+#definePD_TTC_016
+#definePD_TTC_117
+#definePD_TTC_218
+#definePD_TTC_319
+#definePD_SD_0 20
+#definePD_SD_1 21
+#definePD_NAND 22
+#definePD_QSPI 23
+#definePD_GPIO 24
+#definePD_CAN_025
+#definePD_CAN_126
+#definePD_PCIE 27
+#definePD_GPU  28
+
+#endif
-- 
2.7.4



[PATCH v2 0/4] dt-bindings: Firmware node binding for ZynqMP core

2019-01-04 Thread Jolly Shah
Base firmware node and clock child node binding are part of mainline kernel. 
This patchset adds documentation to describe rest of the firmware child node 
bindings. 
Complete firmware DT node example is shown below for ease of understanding:

firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
#power-domain-cells = <1>;
#reset-cells = <1>;

zynqmp_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,zynqmp-clk";
clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
};

zynqmp_power: zynqmp-power {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};

pinctrl0: pinctrl@ff18 {
compatible = "xlnx,zynqmp-pinctrl";

pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};

conf {
groups = "uart0_4_grp";
slew-rate = ;
io-standard = ;
};

conf-rx {
pins = "MIO18";
bias-high-impedance;
};

conf-tx {
pins = "MIO19";
bias-disable;
schmitt-cmos = ;
};
};
};
};
};
Nava kishore Manne (1):
  dt-bindings: reset: Add bindings for ZynqMP reset driver

Rajan Vaja (3):
  dt-bindings: power: Add ZynqMP power domain bindings
  dt-bindings: soc: Add ZynqMP PM bindings
  dt-bindings: pinctrl: Add ZynqMP pin controller bindings

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt   | 275 +
 .../bindings/power/reset/xlnx,zynqmp-power.txt |  25 ++
 .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 +++
 .../bindings/reset/xlnx,zynqmp-reset.txt   | 148 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 +++
 5 files changed, 521 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

-- 
2.7.4



[PATCH v2 2/4] dt-bindings: soc: Add ZynqMP PM bindings

2019-01-04 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-12-06 Thread Jolly Shah
Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Wednesday, December 05, 2018 2:21 PM
> To: Jolly Shah 
> Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; Nava kishore Manne
> ; linux-kernel@vger.kernel.org; Rajan Vaja
> ; Michal Simek ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> On Wed, Dec 05, 2018 at 08:29:36PM +, Jolly Shah wrote:
> > Hi Rob,
> >
> > Thanks for the review. Please find my responses inline.
> 
> You need to fix your mail client to wrap lines.

Thanks I will.

> 
> > Thanks,
> > Jolly Shah
> >
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: Tuesday, December 04, 2018 2:06 PM
> > > To: Jolly Shah 
> > > Cc: mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> > > ; Nava kishore Manne ; linux-
> arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > devicet...@vger.kernel.org; Jolly Shah 
> > > Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP
> core
> > >
> > > On Fri, Nov 16, 2018 at 03:56:50PM -0800, Jolly Shah wrote:
> > > > Base firmware node and clock child node binding are part of mainline
> kernel.
> > > This patchset adds documentation to describe rest of the firmware child
> node
> > > bindings.
> > > > Complete firmware DT node example is shown below for ease of
> > > understanding:
> > >
> > > Shouldn't there be a fpga mgr node too? Called pcap IIRC.
> > >
> > [Jolly] As you suggested, we only added child nodes if the
> > sub-functions have their own resources (clks, irqs, etc.). FPGA doesn't
> > have any resources so not added . Firmware driver would still register
> > it as mfd device to instantiate the driver.
> 
> Okay, but won't their need to be child devices for

There are no fpga child devices. Should it be moved out?

> 
> 
> >
> > > >
> > > > firmware {
> > > > zynqmp_firmware: zynqmp-firmware {
> > > > compatible = "xlnx,zynqmp-firmware";
> > > > method = "smc";
> > > > #power-domain-cells = <1>;
> > > > #reset-cells = <1>;
> > > >
> > > > zynqmp_clk: clock-controller {
> > > > #clock-cells = <1>;
> > > > compatible = "xlnx,zynqmp-clk";
> > > > clocks = <_ref_clk>, <_clk>,
> > > <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
> > > > clock-names = "pss_ref_clk", "video_clk",
> > > "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
> > > > };
> > > >
> > > > zynqmp_power: zynqmp-power {
> > > > compatible = "xlnx,zynqmp-power";
> > > > interrupts = <0 35 4>;
> > > > };
> > > >
> > > > nvmem_firmware {
> > > > compatible = "xlnx,zynqmp-nvmem-fw";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > /* Data cells */
> > > > soc_revision: soc_revision {
> > > > reg = <0x0 0x4>;
> > > > };
> > > > };
> > > >
> > > > afi0: afi0 {
> > > > compatible = "xlnx,afi-fpga";
> > > > config-afi = <0 2>, <1 1>, <2 1>;
> > > > };
> > > >
> > > > qspi: spi@ff0f {
> > >
> > > Why is this under firmware node?
> > [Jolly] Qspi is a user of eemi API provided by firmware node to
> > perform privileged register writes. Alternatively, we can keep such
> > user nodes outside of firmware node and keep nodes which firmware is
> > provider for like clock, reset, pins and power.
> > Please suggest.
> 
> Child nodes of the firmware should be providers, not consumers (of the
&

RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-12-06 Thread Jolly Shah
Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Wednesday, December 05, 2018 2:21 PM
> To: Jolly Shah 
> Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; Nava kishore Manne
> ; linux-kernel@vger.kernel.org; Rajan Vaja
> ; Michal Simek ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> On Wed, Dec 05, 2018 at 08:29:36PM +, Jolly Shah wrote:
> > Hi Rob,
> >
> > Thanks for the review. Please find my responses inline.
> 
> You need to fix your mail client to wrap lines.

Thanks I will.

> 
> > Thanks,
> > Jolly Shah
> >
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: Tuesday, December 04, 2018 2:06 PM
> > > To: Jolly Shah 
> > > Cc: mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> > > ; Nava kishore Manne ; linux-
> arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > devicet...@vger.kernel.org; Jolly Shah 
> > > Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP
> core
> > >
> > > On Fri, Nov 16, 2018 at 03:56:50PM -0800, Jolly Shah wrote:
> > > > Base firmware node and clock child node binding are part of mainline
> kernel.
> > > This patchset adds documentation to describe rest of the firmware child
> node
> > > bindings.
> > > > Complete firmware DT node example is shown below for ease of
> > > understanding:
> > >
> > > Shouldn't there be a fpga mgr node too? Called pcap IIRC.
> > >
> > [Jolly] As you suggested, we only added child nodes if the
> > sub-functions have their own resources (clks, irqs, etc.). FPGA doesn't
> > have any resources so not added . Firmware driver would still register
> > it as mfd device to instantiate the driver.
> 
> Okay, but won't their need to be child devices for

There are no fpga child devices. Should it be moved out?

> 
> 
> >
> > > >
> > > > firmware {
> > > > zynqmp_firmware: zynqmp-firmware {
> > > > compatible = "xlnx,zynqmp-firmware";
> > > > method = "smc";
> > > > #power-domain-cells = <1>;
> > > > #reset-cells = <1>;
> > > >
> > > > zynqmp_clk: clock-controller {
> > > > #clock-cells = <1>;
> > > > compatible = "xlnx,zynqmp-clk";
> > > > clocks = <_ref_clk>, <_clk>,
> > > <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
> > > > clock-names = "pss_ref_clk", "video_clk",
> > > "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
> > > > };
> > > >
> > > > zynqmp_power: zynqmp-power {
> > > > compatible = "xlnx,zynqmp-power";
> > > > interrupts = <0 35 4>;
> > > > };
> > > >
> > > > nvmem_firmware {
> > > > compatible = "xlnx,zynqmp-nvmem-fw";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > /* Data cells */
> > > > soc_revision: soc_revision {
> > > > reg = <0x0 0x4>;
> > > > };
> > > > };
> > > >
> > > > afi0: afi0 {
> > > > compatible = "xlnx,afi-fpga";
> > > > config-afi = <0 2>, <1 1>, <2 1>;
> > > > };
> > > >
> > > > qspi: spi@ff0f {
> > >
> > > Why is this under firmware node?
> > [Jolly] Qspi is a user of eemi API provided by firmware node to
> > perform privileged register writes. Alternatively, we can keep such
> > user nodes outside of firmware node and keep nodes which firmware is
> > provider for like clock, reset, pins and power.
> > Please suggest.
> 
> Child nodes of the firmware should be providers, not consumers (of the
&

RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-12-05 Thread Jolly Shah
Hi Rob,

Thanks for the review. Please find my responses inline.

Thanks,
Jolly Shah

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, December 04, 2018 2:06 PM
> To: Jolly Shah 
> Cc: mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Nava kishore Manne ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Jolly Shah 
> Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> On Fri, Nov 16, 2018 at 03:56:50PM -0800, Jolly Shah wrote:
> > Base firmware node and clock child node binding are part of mainline kernel.
> This patchset adds documentation to describe rest of the firmware child node
> bindings.
> > Complete firmware DT node example is shown below for ease of
> understanding:
> 
> Shouldn't there be a fpga mgr node too? Called pcap IIRC.
> 
[Jolly] As you suggested, we only added child nodes if the sub-functions have 
their own resources (clks, irqs, etc.). FPGA doesn't have any resources so not 
added . Firmware driver would still register it as mfd device to instantiate 
the driver.

> >
> > firmware {
> > zynqmp_firmware: zynqmp-firmware {
> > compatible = "xlnx,zynqmp-firmware";
> > method = "smc";
> > #power-domain-cells = <1>;
> > #reset-cells = <1>;
> >
> > zynqmp_clk: clock-controller {
> > #clock-cells = <1>;
> > compatible = "xlnx,zynqmp-clk";
> > clocks = <_ref_clk>, <_clk>,
> <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
> > clock-names = "pss_ref_clk", "video_clk",
> "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
> > };
> >
> > zynqmp_power: zynqmp-power {
> > compatible = "xlnx,zynqmp-power";
> > interrupts = <0 35 4>;
> > };
> >
> > nvmem_firmware {
> > compatible = "xlnx,zynqmp-nvmem-fw";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > /* Data cells */
> > soc_revision: soc_revision {
> > reg = <0x0 0x4>;
> > };
> > };
> >
> > afi0: afi0 {
> > compatible = "xlnx,afi-fpga";
> > config-afi = <0 2>, <1 1>, <2 1>;
> > };
> >
> > qspi: spi@ff0f {
> 
> Why is this under firmware node?
[Jolly] Qspi is a user of eemi API provided by firmware node to perform 
privileged register writes. Alternatively, we can keep such user nodes outside 
of firmware node and keep nodes which firmware is provider for like clock, 
reset, pins and power.
Please suggest.

> 
> > compatible = "xlnx,zynqmp-qspi-1.0";
> > clock-names = "ref_clk", "pclk";
> > clocks = <_clk _clk>;
> > interrupts = <0 15 4>;
> > interrupt-parent = <>;
> > num-cs = <1>;
> > reg = <0x0 0xff0f 0x1000>,<0x0 0xc000
> 0x800>;
> > };
> >
> > serdes: zynqmp_phy@fd40 {
> 
> And this?

[Jolly] Same as above.

> 
> > compatible = "xlnx,zynqmp-psgtr";
> > status = "okay";
> > reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d
> 0x0 0x1000>,
> > <0x0 0xff5e 0x0 0x1000>;
> > reg-names = "serdes", "siou", "lpd";
> >
> > lane0: lane@0 {
> > #phy-cells = <4>;
> > };
> > lane1: lane@1 {
> > #phy-cells = <4>;
> > };
> > lane2: lane@2 {
> > #phy-cells = <4>;
> > };
> > lane3: lane@3 {
> > #phy-cells = <4>;
> > };
> > };
> >
> > pinctrl_ua

RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-12-05 Thread Jolly Shah
Hi Rob,

Thanks for the review. Please find my responses inline.

Thanks,
Jolly Shah

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, December 04, 2018 2:06 PM
> To: Jolly Shah 
> Cc: mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Nava kishore Manne ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Jolly Shah 
> Subject: Re: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> On Fri, Nov 16, 2018 at 03:56:50PM -0800, Jolly Shah wrote:
> > Base firmware node and clock child node binding are part of mainline kernel.
> This patchset adds documentation to describe rest of the firmware child node
> bindings.
> > Complete firmware DT node example is shown below for ease of
> understanding:
> 
> Shouldn't there be a fpga mgr node too? Called pcap IIRC.
> 
[Jolly] As you suggested, we only added child nodes if the sub-functions have 
their own resources (clks, irqs, etc.). FPGA doesn't have any resources so not 
added . Firmware driver would still register it as mfd device to instantiate 
the driver.

> >
> > firmware {
> > zynqmp_firmware: zynqmp-firmware {
> > compatible = "xlnx,zynqmp-firmware";
> > method = "smc";
> > #power-domain-cells = <1>;
> > #reset-cells = <1>;
> >
> > zynqmp_clk: clock-controller {
> > #clock-cells = <1>;
> > compatible = "xlnx,zynqmp-clk";
> > clocks = <_ref_clk>, <_clk>,
> <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
> > clock-names = "pss_ref_clk", "video_clk",
> "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
> > };
> >
> > zynqmp_power: zynqmp-power {
> > compatible = "xlnx,zynqmp-power";
> > interrupts = <0 35 4>;
> > };
> >
> > nvmem_firmware {
> > compatible = "xlnx,zynqmp-nvmem-fw";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > /* Data cells */
> > soc_revision: soc_revision {
> > reg = <0x0 0x4>;
> > };
> > };
> >
> > afi0: afi0 {
> > compatible = "xlnx,afi-fpga";
> > config-afi = <0 2>, <1 1>, <2 1>;
> > };
> >
> > qspi: spi@ff0f {
> 
> Why is this under firmware node?
[Jolly] Qspi is a user of eemi API provided by firmware node to perform 
privileged register writes. Alternatively, we can keep such user nodes outside 
of firmware node and keep nodes which firmware is provider for like clock, 
reset, pins and power.
Please suggest.

> 
> > compatible = "xlnx,zynqmp-qspi-1.0";
> > clock-names = "ref_clk", "pclk";
> > clocks = <_clk _clk>;
> > interrupts = <0 15 4>;
> > interrupt-parent = <>;
> > num-cs = <1>;
> > reg = <0x0 0xff0f 0x1000>,<0x0 0xc000
> 0x800>;
> > };
> >
> > serdes: zynqmp_phy@fd40 {
> 
> And this?

[Jolly] Same as above.

> 
> > compatible = "xlnx,zynqmp-psgtr";
> > status = "okay";
> > reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d
> 0x0 0x1000>,
> > <0x0 0xff5e 0x0 0x1000>;
> > reg-names = "serdes", "siou", "lpd";
> >
> > lane0: lane@0 {
> > #phy-cells = <4>;
> > };
> > lane1: lane@1 {
> > #phy-cells = <4>;
> > };
> > lane2: lane@2 {
> > #phy-cells = <4>;
> > };
> > lane3: lane@3 {
> > #phy-cells = <4>;
> > };
> > };
> >
> > pinctrl_ua

RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-11-26 Thread Jolly Shah
Ping for comments

> -Original Message-
> From: Jolly Shah [mailto:jolly.s...@xilinx.com]
> Sent: Friday, November 16, 2018 3:57 PM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: Michal Simek ; Rajan Vaja ;
> Nava kishore Manne ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Jolly Shah 
> Subject: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> Base firmware node and clock child node binding are part of mainline kernel.
> This patchset adds documentation to describe rest of the firmware child node
> bindings.
> Complete firmware DT node example is shown below for ease of understanding:
> 
> firmware {
>   zynqmp_firmware: zynqmp-firmware {
>   compatible = "xlnx,zynqmp-firmware";
>   method = "smc";
>   #power-domain-cells = <1>;
>   #reset-cells = <1>;
> 
>   zynqmp_clk: clock-controller {
>   #clock-cells = <1>;
>   compatible = "xlnx,zynqmp-clk";
>   clocks = <_ref_clk>, <_clk>,
> <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
>   clock-names = "pss_ref_clk", "video_clk",
> "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
>   };
> 
>   zynqmp_power: zynqmp-power {
>   compatible = "xlnx,zynqmp-power";
>   interrupts = <0 35 4>;
>   };
> 
>   nvmem_firmware {
>   compatible = "xlnx,zynqmp-nvmem-fw";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   /* Data cells */
>   soc_revision: soc_revision {
>   reg = <0x0 0x4>;
>   };
>   };
> 
>   afi0: afi0 {
>   compatible = "xlnx,afi-fpga";
>   config-afi = <0 2>, <1 1>, <2 1>;
>   };
> 
>   qspi: spi@ff0f {
>   compatible = "xlnx,zynqmp-qspi-1.0";
>   clock-names = "ref_clk", "pclk";
>   clocks = <_clk _clk>;
>   interrupts = <0 15 4>;
>   interrupt-parent = <>;
>   num-cs = <1>;
>   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000
> 0x800>;
>   };
> 
>   serdes: zynqmp_phy@fd40 {
>   compatible = "xlnx,zynqmp-psgtr";
>   status = "okay";
>   reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d
> 0x0 0x1000>,
>   <0x0 0xff5e 0x0 0x1000>;
>   reg-names = "serdes", "siou", "lpd";
> 
>   lane0: lane@0 {
>   #phy-cells = <4>;
>   };
>   lane1: lane@1 {
>   #phy-cells = <4>;
>   };
>   lane2: lane@2 {
>   #phy-cells = <4>;
>   };
>   lane3: lane@3 {
>   #phy-cells = <4>;
>   };
>   };
> 
>   pinctrl_uart1_default: uart1-default {
>   mux {
>   groups = "uart0_4_grp";
>   function = "uart0";
>   };
> 
>   conf {
>   groups = "uart0_4_grp";
>   slew-rate = ;
>   io-standard = ;
>   };
> 
>   conf-rx {
>   pins = "MIO18";
>   bias-high-impedance;
>   };
> 
>   conf-tx {
>   pins = "MIO19";
>   bias-disable;
>   schmitt-cmos = ;
>   };
>   };
>   zynqmp-r5-remoteproc@0 {
>       compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
>  

RE: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-11-26 Thread Jolly Shah
Ping for comments

> -Original Message-
> From: Jolly Shah [mailto:jolly.s...@xilinx.com]
> Sent: Friday, November 16, 2018 3:57 PM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: Michal Simek ; Rajan Vaja ;
> Nava kishore Manne ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Jolly Shah 
> Subject: [PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core
> 
> Base firmware node and clock child node binding are part of mainline kernel.
> This patchset adds documentation to describe rest of the firmware child node
> bindings.
> Complete firmware DT node example is shown below for ease of understanding:
> 
> firmware {
>   zynqmp_firmware: zynqmp-firmware {
>   compatible = "xlnx,zynqmp-firmware";
>   method = "smc";
>   #power-domain-cells = <1>;
>   #reset-cells = <1>;
> 
>   zynqmp_clk: clock-controller {
>   #clock-cells = <1>;
>   compatible = "xlnx,zynqmp-clk";
>   clocks = <_ref_clk>, <_clk>,
> <_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
>   clock-names = "pss_ref_clk", "video_clk",
> "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
>   };
> 
>   zynqmp_power: zynqmp-power {
>   compatible = "xlnx,zynqmp-power";
>   interrupts = <0 35 4>;
>   };
> 
>   nvmem_firmware {
>   compatible = "xlnx,zynqmp-nvmem-fw";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   /* Data cells */
>   soc_revision: soc_revision {
>   reg = <0x0 0x4>;
>   };
>   };
> 
>   afi0: afi0 {
>   compatible = "xlnx,afi-fpga";
>   config-afi = <0 2>, <1 1>, <2 1>;
>   };
> 
>   qspi: spi@ff0f {
>   compatible = "xlnx,zynqmp-qspi-1.0";
>   clock-names = "ref_clk", "pclk";
>   clocks = <_clk _clk>;
>   interrupts = <0 15 4>;
>   interrupt-parent = <>;
>   num-cs = <1>;
>   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000
> 0x800>;
>   };
> 
>   serdes: zynqmp_phy@fd40 {
>   compatible = "xlnx,zynqmp-psgtr";
>   status = "okay";
>   reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d
> 0x0 0x1000>,
>   <0x0 0xff5e 0x0 0x1000>;
>   reg-names = "serdes", "siou", "lpd";
> 
>   lane0: lane@0 {
>   #phy-cells = <4>;
>   };
>   lane1: lane@1 {
>   #phy-cells = <4>;
>   };
>   lane2: lane@2 {
>   #phy-cells = <4>;
>   };
>   lane3: lane@3 {
>   #phy-cells = <4>;
>   };
>   };
> 
>   pinctrl_uart1_default: uart1-default {
>   mux {
>   groups = "uart0_4_grp";
>   function = "uart0";
>   };
> 
>   conf {
>   groups = "uart0_4_grp";
>   slew-rate = ;
>   io-standard = ;
>   };
> 
>   conf-rx {
>   pins = "MIO18";
>   bias-high-impedance;
>   };
> 
>   conf-tx {
>   pins = "MIO19";
>   bias-disable;
>   schmitt-cmos = ;
>   };
>   };
>   zynqmp-r5-remoteproc@0 {
>       compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
>  

[PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-11-16 Thread Jolly Shah
Base firmware node and clock child node binding are part of mainline kernel. 
This patchset adds documentation to describe rest of the firmware child node 
bindings. 
Complete firmware DT node example is shown below for ease of understanding:

firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
#power-domain-cells = <1>;
#reset-cells = <1>;

zynqmp_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,zynqmp-clk";
clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
};

zynqmp_power: zynqmp-power {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};

nvmem_firmware {
compatible = "xlnx,zynqmp-nvmem-fw";
#address-cells = <1>;
#size-cells = <1>;

/* Data cells */
soc_revision: soc_revision {
reg = <0x0 0x4>;
};
};

afi0: afi0 {
compatible = "xlnx,afi-fpga";
config-afi = <0 2>, <1 1>, <2 1>;
};

qspi: spi@ff0f {
compatible = "xlnx,zynqmp-qspi-1.0";
clock-names = "ref_clk", "pclk";
clocks = <_clk _clk>;
interrupts = <0 15 4>;
interrupt-parent = <>;
num-cs = <1>;
reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
};

serdes: zynqmp_phy@fd40 {
compatible = "xlnx,zynqmp-psgtr";
status = "okay";
reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
<0x0 0xff5e 0x0 0x1000>;
reg-names = "serdes", "siou", "lpd";

lane0: lane@0 {
#phy-cells = <4>;
};
lane1: lane@1 {
#phy-cells = <4>;
};
lane2: lane@2 {
#phy-cells = <4>;
};
lane3: lane@3 {
#phy-cells = <4>;
};
};

pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};

conf {
groups = "uart0_4_grp";
slew-rate = ;
io-standard = ;
};

conf-rx {
pins = "MIO18";
bias-high-impedance;
};

conf-tx {
pins = "MIO19";
bias-disable;
schmitt-cmos = ;
};
};
zynqmp-r5-remoteproc@0 {
compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
reg = <0x0 0xFFE0 0x0 0x1>,
<0x0 0xFFE2 0x0 0x1>,
<0x0 0xff34 0x0 0x100>;
reg-names = "tcm_a", "tcm_b", "ipi";
dma-ranges;
core_conf = "split0";
memory-region = <_0_fw_reserved>,
<_0_dma_reserved>;
tcm-pnode-id = <0xf>, <0x10>;
rpu-pnode-id = <0x7>;
interrupt-parent = <>;
interrupts = <0 29 4>;
};
};
};

Jolly Shah (2):
  dt-bindings: phy: Add dt bindi

[PATCH 7/9] dt-bindings: phy: Add dt bindings for ZynqMP PHY

2018-11-16 Thread Jolly Shah
This patch adds the document describing dt bindings for ZynqMP
PHY. ZynqMP SOC has a High Speed Processing System Gigabit
Transceiver which provides PHY capabilties to USB, SATA,
PCIE, Display Port and Ehernet SGMII controllers.

Signed-off-by: Anurag Kumar Vulisha 
Signed-off-by: Jolly Shah 
Signed-off-by: Michal Simek 
---
 .../devicetree/bindings/phy/phy-zynqmp.txt | 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-zynqmp.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-zynqmp.txt 
b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
new file mode 100644
index 000..21cb722
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
@@ -0,0 +1,126 @@
+Xilinx ZynqMP PHY binding
+
+This binding describes a ZynqMP PHY device that is used to control ZynqMP
+High Speed Gigabit Transceiver(GT). ZynqMP PS GTR provides four lanes
+and are used by USB, SATA, PCIE, Display port and Ethernet SGMMI controllers.
+
+Required properties (controller (parent) node):
+- compatible   : Can be "xlnx,zynqmp-psgtr-v1.1" or "xlnx,zynqmp-psgtr"
+ "xlnx,zynqmp-psgtr-v1.1" has the lpd address mapping removed
+
+- reg   : Address and length of register sets for each device in
+  "reg-names"
+- reg-names : The names of the register addresses corresponding to the
+ registers filled in "reg":
+   - serdes: SERDES block register set
+   - siou: SIOU block register set
+   - lpd: Low power domain peripherals reset control
+
+Required nodes :  A sub-node is required for each lane the controller
+  provides.
+
+Required properties (port (child) nodes):
+lane0:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane1:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane2:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane3:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+
+Note:  LANE_NUM : This determines which lane's reference clock is shared by 
controller.
+   FREQUENCY: This the clock frequency at which controller wants to 
operate.
+
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   serdes: zynqmp_phy@fd40 {
+   compatible = "xlnx,zynqmp-psgtr";
+   status = "okay";
+   reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
+   <0x0 0xff5e 0x0 0x1000>;
+   reg-names = "serdes", "siou", "lpd";
+
+   lane0: lane@0 {
+   #phy-cells = <4>;
+   };
+   lane1: lane@1 {
+   #phy-cells = <4>;
+   };
+   lane2: lane@2 {
+   #phy-cells = <4>;
+   };
+   lane3: lane@3 {
+   #phy-cells = <4>;
+   };
+   };
+   };
+};
+
+Specifying phy control of devices
+=
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type.
+
+phys = ;
+
+PHANDLE =  or  or  or 
+CONTROLLER_TYPE = PHY_TYPE_PCIE or PHY_TYPE_SATA or PHY_TYPE_USB
+ or PHY_TYPE_DP or PHY_TYPE_SGMII
+CONTROLLER_INSTANCE = Depends on controller type used, can be any of
+   PHY_TYPE_PCIE : 0 or 1 or 2 or 3
+   PHY_TYPE_SATA : 0 or 1
+   PHY_TYPE_USB  : 0 or 1
+   PHY_TYPE_DP   : 0 or 1
+   PHY_TYPE_SGMII: 0 or 1 or 2 or 3
+LANE_NUM= Depends on which lane clock is used as ref clk, can 
be
+ 0 

[PATCH 8/9] dt-bindings: remoteproc: Add Xilinx R5 rproc binding

2018-11-16 Thread Jolly Shah
From: Wendy Liang 

Add device tree binding for Xilinx Cortex-r5 remoteproc.

Signed-off-by: Wendy Liang 
Signed-off-by: Jolly Shah 
---
 .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt   | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
new file mode 100644
index 000..4831350
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
@@ -0,0 +1,81 @@
+Xilinx ARM Cortex A53-R5 remoteproc driver
+==
+
+ZynqMP family of devices use two Cortex R5 processors to help with various
+low power / real time tasks.
+
+This driver requires specific ZynqMP hardware design.
+
+ZynqMP R5 RemoteProc Device Node:
+=
+A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
+within ZynqMP SoC.
+
+Required properties:
+
+ - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
+ - reg : Address and length of the register set for the device. It
+contains in the same order as described reg-names
+ - reg-names: Contain the register set names.
+  "tcm_a" and "tcm_b" for TCM memories.
+  If the user uses the remoteproc driver with the RPMsg kernel
+  driver,"ipi" for the IPI register used to communicate with RPU
+  is also required.
+  Otherwise, if user only uses the remoteproc driver to boot RPU
+  firmware, "ipi" is not required.
+ - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
+ resources for the remoteproc driver to access.
+ - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
+  to start RPU or shut it down.
+
+Optional properties:
+
+ - core_conf : R5 core configuration (valid string - split0 or split1 or
+   lock-step), default is lock-step.
+ - memory-region: memories regions for RPU executable and DMA memory.
+ - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
+user uses the remoteproc driver with the RPMsg kernel driver.
+ - interrupt-parent : Phandle for the interrupt controller. It is required if
+  the user uses the remoteproc driver with the RPMsg kernel
+  kernel driver.
+
+Example:
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   rproc_0_fw_reserved: rproc@3ed00 {
+   compatible = "rproc-prog-memory";
+   no-map;
+   reg = <0x0 0x3ed0 0x0 0x4>;
+   };
+   rproc_0_dma_reserved: rproc@3ed40 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x0 0x3ed4 0x0 0x8>;
+   };
+   };
+
+   firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp-r5-remoteproc@0 {
+   compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
+   reg = <0x0 0xFFE0 0x0 0x1>,
+   <0x0 0xFFE2 0x0 0x1>,
+   <0x0 0xff34 0x0 0x100>;
+   reg-names = "tcm_a", "tcm_b", "ipi";
+   dma-ranges;
+   core_conf = "split0";
+   memory-region = <_0_fw_reserved>,
+   <_0_dma_reserved>;
+   tcm-pnode-id = <0xf>, <0x10>;
+   rpu-pnode-id = <0x7>;
+   interrupt-parent = <>;
+   interrupts = <0 29 4>;
+   } ;
+   };
+   };
-- 
2.7.4



[PATCH 0/9] dt-bindings: Firmware node binding for ZynqMP core

2018-11-16 Thread Jolly Shah
Base firmware node and clock child node binding are part of mainline kernel. 
This patchset adds documentation to describe rest of the firmware child node 
bindings. 
Complete firmware DT node example is shown below for ease of understanding:

firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
#power-domain-cells = <1>;
#reset-cells = <1>;

zynqmp_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,zynqmp-clk";
clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
};

zynqmp_power: zynqmp-power {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};

nvmem_firmware {
compatible = "xlnx,zynqmp-nvmem-fw";
#address-cells = <1>;
#size-cells = <1>;

/* Data cells */
soc_revision: soc_revision {
reg = <0x0 0x4>;
};
};

afi0: afi0 {
compatible = "xlnx,afi-fpga";
config-afi = <0 2>, <1 1>, <2 1>;
};

qspi: spi@ff0f {
compatible = "xlnx,zynqmp-qspi-1.0";
clock-names = "ref_clk", "pclk";
clocks = <_clk _clk>;
interrupts = <0 15 4>;
interrupt-parent = <>;
num-cs = <1>;
reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
};

serdes: zynqmp_phy@fd40 {
compatible = "xlnx,zynqmp-psgtr";
status = "okay";
reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
<0x0 0xff5e 0x0 0x1000>;
reg-names = "serdes", "siou", "lpd";

lane0: lane@0 {
#phy-cells = <4>;
};
lane1: lane@1 {
#phy-cells = <4>;
};
lane2: lane@2 {
#phy-cells = <4>;
};
lane3: lane@3 {
#phy-cells = <4>;
};
};

pinctrl_uart1_default: uart1-default {
mux {
groups = "uart0_4_grp";
function = "uart0";
};

conf {
groups = "uart0_4_grp";
slew-rate = ;
io-standard = ;
};

conf-rx {
pins = "MIO18";
bias-high-impedance;
};

conf-tx {
pins = "MIO19";
bias-disable;
schmitt-cmos = ;
};
};
zynqmp-r5-remoteproc@0 {
compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
reg = <0x0 0xFFE0 0x0 0x1>,
<0x0 0xFFE2 0x0 0x1>,
<0x0 0xff34 0x0 0x100>;
reg-names = "tcm_a", "tcm_b", "ipi";
dma-ranges;
core_conf = "split0";
memory-region = <_0_fw_reserved>,
<_0_dma_reserved>;
tcm-pnode-id = <0xf>, <0x10>;
rpu-pnode-id = <0x7>;
interrupt-parent = <>;
interrupts = <0 29 4>;
};
};
};

Jolly Shah (2):
  dt-bindings: phy: Add dt bindi

[PATCH 7/9] dt-bindings: phy: Add dt bindings for ZynqMP PHY

2018-11-16 Thread Jolly Shah
This patch adds the document describing dt bindings for ZynqMP
PHY. ZynqMP SOC has a High Speed Processing System Gigabit
Transceiver which provides PHY capabilties to USB, SATA,
PCIE, Display Port and Ehernet SGMII controllers.

Signed-off-by: Anurag Kumar Vulisha 
Signed-off-by: Jolly Shah 
Signed-off-by: Michal Simek 
---
 .../devicetree/bindings/phy/phy-zynqmp.txt | 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-zynqmp.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-zynqmp.txt 
b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
new file mode 100644
index 000..21cb722
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-zynqmp.txt
@@ -0,0 +1,126 @@
+Xilinx ZynqMP PHY binding
+
+This binding describes a ZynqMP PHY device that is used to control ZynqMP
+High Speed Gigabit Transceiver(GT). ZynqMP PS GTR provides four lanes
+and are used by USB, SATA, PCIE, Display port and Ethernet SGMMI controllers.
+
+Required properties (controller (parent) node):
+- compatible   : Can be "xlnx,zynqmp-psgtr-v1.1" or "xlnx,zynqmp-psgtr"
+ "xlnx,zynqmp-psgtr-v1.1" has the lpd address mapping removed
+
+- reg   : Address and length of register sets for each device in
+  "reg-names"
+- reg-names : The names of the register addresses corresponding to the
+ registers filled in "reg":
+   - serdes: SERDES block register set
+   - siou: SIOU block register set
+   - lpd: Low power domain peripherals reset control
+
+Required nodes :  A sub-node is required for each lane the controller
+  provides.
+
+Required properties (port (child) nodes):
+lane0:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane1:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane2:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+lane3:
+- #phy-cells   : Should be 4
+ Cell after port phandle is device type from:
+   - 
+   - 
+   - 
+   - 
+   - 
+
+Note:  LANE_NUM : This determines which lane's reference clock is shared by 
controller.
+   FREQUENCY: This the clock frequency at which controller wants to 
operate.
+
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   serdes: zynqmp_phy@fd40 {
+   compatible = "xlnx,zynqmp-psgtr";
+   status = "okay";
+   reg = <0x0 0xfd40 0x0 0x4>, <0x0 0xfd3d 0x0 
0x1000>,
+   <0x0 0xff5e 0x0 0x1000>;
+   reg-names = "serdes", "siou", "lpd";
+
+   lane0: lane@0 {
+   #phy-cells = <4>;
+   };
+   lane1: lane@1 {
+   #phy-cells = <4>;
+   };
+   lane2: lane@2 {
+   #phy-cells = <4>;
+   };
+   lane3: lane@3 {
+   #phy-cells = <4>;
+   };
+   };
+   };
+};
+
+Specifying phy control of devices
+=
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type.
+
+phys = ;
+
+PHANDLE =  or  or  or 
+CONTROLLER_TYPE = PHY_TYPE_PCIE or PHY_TYPE_SATA or PHY_TYPE_USB
+ or PHY_TYPE_DP or PHY_TYPE_SGMII
+CONTROLLER_INSTANCE = Depends on controller type used, can be any of
+   PHY_TYPE_PCIE : 0 or 1 or 2 or 3
+   PHY_TYPE_SATA : 0 or 1
+   PHY_TYPE_USB  : 0 or 1
+   PHY_TYPE_DP   : 0 or 1
+   PHY_TYPE_SGMII: 0 or 1 or 2 or 3
+LANE_NUM= Depends on which lane clock is used as ref clk, can 
be
+ 0 

[PATCH 8/9] dt-bindings: remoteproc: Add Xilinx R5 rproc binding

2018-11-16 Thread Jolly Shah
From: Wendy Liang 

Add device tree binding for Xilinx Cortex-r5 remoteproc.

Signed-off-by: Wendy Liang 
Signed-off-by: Jolly Shah 
---
 .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt   | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt 
b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
new file mode 100644
index 000..4831350
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
@@ -0,0 +1,81 @@
+Xilinx ARM Cortex A53-R5 remoteproc driver
+==
+
+ZynqMP family of devices use two Cortex R5 processors to help with various
+low power / real time tasks.
+
+This driver requires specific ZynqMP hardware design.
+
+ZynqMP R5 RemoteProc Device Node:
+=
+A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
+within ZynqMP SoC.
+
+Required properties:
+
+ - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
+ - reg : Address and length of the register set for the device. It
+contains in the same order as described reg-names
+ - reg-names: Contain the register set names.
+  "tcm_a" and "tcm_b" for TCM memories.
+  If the user uses the remoteproc driver with the RPMsg kernel
+  driver,"ipi" for the IPI register used to communicate with RPU
+  is also required.
+  Otherwise, if user only uses the remoteproc driver to boot RPU
+  firmware, "ipi" is not required.
+ - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
+ resources for the remoteproc driver to access.
+ - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
+  to start RPU or shut it down.
+
+Optional properties:
+
+ - core_conf : R5 core configuration (valid string - split0 or split1 or
+   lock-step), default is lock-step.
+ - memory-region: memories regions for RPU executable and DMA memory.
+ - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
+user uses the remoteproc driver with the RPMsg kernel driver.
+ - interrupt-parent : Phandle for the interrupt controller. It is required if
+  the user uses the remoteproc driver with the RPMsg kernel
+  kernel driver.
+
+Example:
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   rproc_0_fw_reserved: rproc@3ed00 {
+   compatible = "rproc-prog-memory";
+   no-map;
+   reg = <0x0 0x3ed0 0x0 0x4>;
+   };
+   rproc_0_dma_reserved: rproc@3ed40 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x0 0x3ed4 0x0 0x8>;
+   };
+   };
+
+   firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp-r5-remoteproc@0 {
+   compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
+   reg = <0x0 0xFFE0 0x0 0x1>,
+   <0x0 0xFFE2 0x0 0x1>,
+   <0x0 0xff34 0x0 0x100>;
+   reg-names = "tcm_a", "tcm_b", "ipi";
+   dma-ranges;
+   core_conf = "split0";
+   memory-region = <_0_fw_reserved>,
+   <_0_dma_reserved>;
+   tcm-pnode-id = <0xf>, <0x10>;
+   rpu-pnode-id = <0x7>;
+   interrupt-parent = <>;
+   interrupts = <0 29 4>;
+   } ;
+   };
+   };
-- 
2.7.4



[PATCH 4/9] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/nvmem/xlnx,zynqmp-nvmem.txt   | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index 000..090ba08
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,44 @@
+--
+=  Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   nvmem_firmware {
+   compatible = "xlnx,zynqmp-nvmem-fw";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   soc_revision: soc_revision {
+   reg = <0x0 0x4>;
+   };
+   };
+   };
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+   pcap {
+   ...
+   nvmem-cells = <_revision>;
+   nvmem-cell-names = "soc_revision";
+   };
+
-- 
2.7.4



[PATCH 1/9] dt-bindings: power: Add ZynqMP power domain bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe ZynqMP power domain bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/xlnx,zynqmp-genpd.txt   | 34 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  | 39 ++
 2 files changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt 
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index 000..3c7f237
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must 
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   ...
+   #power-domain-cells = <1>;
+   ...
+   };
+};
+
+sata {
+   ...
+   power-domains = <_firmware 2>;
+   ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h 
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index 000..1bc9636
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_00
+#definePD_USB_11
+#definePD_SATA 2
+#definePD_SPI_03
+#definePD_SPI_14
+#definePD_UART_0   5
+#definePD_UART_1   6
+#definePD_ETH_07
+#definePD_ETH_18
+#definePD_ETH_29
+#definePD_ETH_310
+#definePD_I2C_011
+#definePD_I2C_112
+#definePD_DP   13
+#definePD_GDMA 14
+#definePD_ADMA 15
+#definePD_TTC_016
+#definePD_TTC_117
+#definePD_TTC_218
+#definePD_TTC_319
+#definePD_SD_0 20
+#definePD_SD_1 21
+#definePD_NAND 22
+#definePD_QSPI 23
+#definePD_GPIO 24
+#definePD_CAN_025
+#definePD_CAN_126
+#definePD_PCIE 27
+#definePD_GPU  28
+
+#endif
-- 
2.7.4



[PATCH 6/9] dt-bindings: spi: zynqmp: Move SPI node under zynqmp firmware

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

SPI driver uses ZynqMP firmware interface and so it should be
populated by firmware driver.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/spi/spi-zynqmp-qspi.txt| 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt 
b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
index 0f6d37f..767bb8e 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
@@ -14,12 +14,18 @@ Optional properties:
 - num-cs   : Number of chip selects used.
 
 Example:
-   qspi: spi@ff0f {
-   compatible = "xlnx,zynqmp-qspi-1.0";
-   clock-names = "ref_clk", "pclk";
-   clocks = <_clk _clk>;
-   interrupts = <0 15 4>;
-   interrupt-parent = <>;
-   num-cs = <1>;
-   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 0x800>;
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   qspi: spi@ff0f {
+   compatible = "xlnx,zynqmp-qspi-1.0";
+   clock-names = "ref_clk", "pclk";
+   clocks = <_clk _clk>;
+   interrupts = <0 15 4>;
+   interrupt-parent = <>;
+   num-cs = <1>;
+   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
+   };
};
+};
-- 
2.7.4



[PATCH 9/9] dt-bindings: fpga: Add binding doc for the afi config driver

2018-11-16 Thread Jolly Shah
Add the binding document for the afi config driver.

Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Michal Simek 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/fpga/xlnx,afi-fpga.txt | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt 
b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
new file mode 100644
index 000..9006e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
@@ -0,0 +1,67 @@
+Xilinx ZynqMp AFI interface Manager
+
+The Zynq UltraScale+ MPSoC Processing System core provides access from PL
+masters to PS internal peripherals, and memory through AXI FIFO interface
+(AFI) interfaces.
+
+Required properties:
+-compatible:   Should contain "xlnx,afi-fpga"
+-config-afi:   Pairs of  
+
+The possible values of regid and values are
+ regid:Regids of the register to be written possible values
+   0- AFIFM0_RDCTRL
+   1- AFIFM0_WRCTRL
+   2- AFIFM1_RDCTRL
+   3- AFIFM1_WRCTRL
+   4- AFIFM2_RDCTRL
+   5- AFIFM2_WRCTRL
+   6- AFIFM3_RDCTRL
+   7- AFIFM3_WRCTRL
+   8- AFIFM4_RDCTRL
+   9- AFIFM4_WRCTRL
+   10- AFIFM5_RDCTRL
+   11- AFIFM5_WRCTRL
+   12- AFIFM6_RDCTRL
+   13- AFIFM6_WRCTRL
+   14- AFIFS
+   15- AFIFS_SS2
+- value:   Array of values to be written.
+   for FM0_RDCTRL(0) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM0_WRCTRL(1) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_RDCTRL(2) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_WRCTRL(3) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_RDCTRL(4) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_WRCTRL(5) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_RDCTRL(6) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_WRCTRL(7) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_RDCTRL(8) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_WRCTRL(9) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM5_RDCTRL(10) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM5_WRCTRL(11) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_RDCTRL(12) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_WRCTRL(13) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for AFI_FA(14)
+   dw_ss1_sel  bits (11:10)
+   dw_ss0_sel  bits (9:8)
+   0x0: 32-bit AXI data width),
+   0x1: 64-bit AXI data width,
+   0x2: 128-bit AXI data
+   All other bits are 0 write ignored.
+
+   for AFI_FA(15)  selects for ss2AXI data width valid values
+   0x000: 32-bit AXI data width),
+   0x100: 64-bit AXI data width,
+   0x200: 128-bit AXI data
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   afi0: afi0 {
+   compatible = "xlnx,afi-fpga";
+   config-afi = <0 2>, <1 1>, <2 1>;
+   };
+   };
+};
-- 
2.7.4



[PATCH 4/9] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/nvmem/xlnx,zynqmp-nvmem.txt   | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt 
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index 000..090ba08
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,44 @@
+--
+=  Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   nvmem_firmware {
+   compatible = "xlnx,zynqmp-nvmem-fw";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells */
+   soc_revision: soc_revision {
+   reg = <0x0 0x4>;
+   };
+   };
+   };
+};
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+   pcap {
+   ...
+   nvmem-cells = <_revision>;
+   nvmem-cell-names = "soc_revision";
+   };
+
-- 
2.7.4



[PATCH 1/9] dt-bindings: power: Add ZynqMP power domain bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe ZynqMP power domain bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/xlnx,zynqmp-genpd.txt   | 34 +++
 include/dt-bindings/power/xlnx-zynqmp-power.h  | 39 ++
 2 files changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt 
b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
new file mode 100644
index 000..3c7f237
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
@@ -0,0 +1,34 @@
+---
+Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
+---
+The binding for zynqmp-power-controller follow the common
+generic PM domain binding[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+== Zynq MPSoC Generic PM Domain Node ==
+
+Required property:
+ - Below property should be in zynqmp-firmware node.
+ - #power-domain-cells:Number of cells in a PM domain specifier. Must 
be 1.
+
+Power domain ID indexes are mentioned in
+include/dt-bindings/power/xlnx-zynqmp-power.h.
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   ...
+   #power-domain-cells = <1>;
+   ...
+   };
+};
+
+sata {
+   ...
+   power-domains = <_firmware 2>;
+   ...
+};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h 
b/include/dt-bindings/power/xlnx-zynqmp-power.h
new file mode 100644
index 000..1bc9636
--- /dev/null
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
+#define _DT_BINDINGS_ZYNQMP_POWER_H
+
+#definePD_USB_00
+#definePD_USB_11
+#definePD_SATA 2
+#definePD_SPI_03
+#definePD_SPI_14
+#definePD_UART_0   5
+#definePD_UART_1   6
+#definePD_ETH_07
+#definePD_ETH_18
+#definePD_ETH_29
+#definePD_ETH_310
+#definePD_I2C_011
+#definePD_I2C_112
+#definePD_DP   13
+#definePD_GDMA 14
+#definePD_ADMA 15
+#definePD_TTC_016
+#definePD_TTC_117
+#definePD_TTC_218
+#definePD_TTC_319
+#definePD_SD_0 20
+#definePD_SD_1 21
+#definePD_NAND 22
+#definePD_QSPI 23
+#definePD_GPIO 24
+#definePD_CAN_025
+#definePD_CAN_126
+#definePD_PCIE 27
+#definePD_GPU  28
+
+#endif
-- 
2.7.4



[PATCH 6/9] dt-bindings: spi: zynqmp: Move SPI node under zynqmp firmware

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

SPI driver uses ZynqMP firmware interface and so it should be
populated by firmware driver.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/spi/spi-zynqmp-qspi.txt| 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt 
b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
index 0f6d37f..767bb8e 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
@@ -14,12 +14,18 @@ Optional properties:
 - num-cs   : Number of chip selects used.
 
 Example:
-   qspi: spi@ff0f {
-   compatible = "xlnx,zynqmp-qspi-1.0";
-   clock-names = "ref_clk", "pclk";
-   clocks = <_clk _clk>;
-   interrupts = <0 15 4>;
-   interrupt-parent = <>;
-   num-cs = <1>;
-   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 0x800>;
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   qspi: spi@ff0f {
+   compatible = "xlnx,zynqmp-qspi-1.0";
+   clock-names = "ref_clk", "pclk";
+   clocks = <_clk _clk>;
+   interrupts = <0 15 4>;
+   interrupt-parent = <>;
+   num-cs = <1>;
+   reg = <0x0 0xff0f 0x1000>,<0x0 0xc000 
0x800>;
+   };
};
+};
-- 
2.7.4



[PATCH 9/9] dt-bindings: fpga: Add binding doc for the afi config driver

2018-11-16 Thread Jolly Shah
Add the binding document for the afi config driver.

Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Michal Simek 
Signed-off-by: Jolly Shah 
---
 .../devicetree/bindings/fpga/xlnx,afi-fpga.txt | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt 
b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
new file mode 100644
index 000..9006e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,afi-fpga.txt
@@ -0,0 +1,67 @@
+Xilinx ZynqMp AFI interface Manager
+
+The Zynq UltraScale+ MPSoC Processing System core provides access from PL
+masters to PS internal peripherals, and memory through AXI FIFO interface
+(AFI) interfaces.
+
+Required properties:
+-compatible:   Should contain "xlnx,afi-fpga"
+-config-afi:   Pairs of  
+
+The possible values of regid and values are
+ regid:Regids of the register to be written possible values
+   0- AFIFM0_RDCTRL
+   1- AFIFM0_WRCTRL
+   2- AFIFM1_RDCTRL
+   3- AFIFM1_WRCTRL
+   4- AFIFM2_RDCTRL
+   5- AFIFM2_WRCTRL
+   6- AFIFM3_RDCTRL
+   7- AFIFM3_WRCTRL
+   8- AFIFM4_RDCTRL
+   9- AFIFM4_WRCTRL
+   10- AFIFM5_RDCTRL
+   11- AFIFM5_WRCTRL
+   12- AFIFM6_RDCTRL
+   13- AFIFM6_WRCTRL
+   14- AFIFS
+   15- AFIFS_SS2
+- value:   Array of values to be written.
+   for FM0_RDCTRL(0) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM0_WRCTRL(1) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_RDCTRL(2) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM1_WRCTRL(3) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_RDCTRL(4) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM2_WRCTRL(5) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_RDCTRL(6) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM3_WRCTRL(7) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_RDCTRL(8) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM4_WRCTRL(9) the valid values-fabric width   2: 32-bit,1 : 
64-bit ,0: 128-bit enabled
+   for FM5_RDCTRL(10) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM5_WRCTRL(11) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_RDCTRL(12) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for FM6_WRCTRL(13) the valid values-fabric width   2: 32-bit,1 
: 64-bit ,0: 128-bit enabled
+   for AFI_FA(14)
+   dw_ss1_sel  bits (11:10)
+   dw_ss0_sel  bits (9:8)
+   0x0: 32-bit AXI data width),
+   0x1: 64-bit AXI data width,
+   0x2: 128-bit AXI data
+   All other bits are 0 write ignored.
+
+   for AFI_FA(15)  selects for ss2AXI data width valid values
+   0x000: 32-bit AXI data width),
+   0x100: 64-bit AXI data width,
+   0x200: 128-bit AXI data
+
+Example:
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+   afi0: afi0 {
+   compatible = "xlnx,afi-fpga";
+   config-afi = <0 2>, <1 1>, <2 1>;
+   };
+   };
+};
-- 
2.7.4



[PATCH 3/9] dt-bindings: reset: Add bindings for ZynqMP reset driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP reset driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/reset/xlnx,zynqmp-reset.txt   | 148 +
 1 file changed, 148 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt 
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
new file mode 100644
index 000..e9c1af8
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -0,0 +1,148 @@
+--
+ =  Zynq UltraScale+ MPSoC reset driver binding =
+--
+The Zynq UltraScale+ MPSoC has several different resets.
+
+See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
+about zynqmp resets.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required Properties:
+- #reset-cells:Specifies the number of cells needed to encode reset
+   line, should be 1
+
+Reset outputs:
+   0   :PCIE config reset.
+   1   :PCIE bridge block level reset (AXI interface).
+   2   :PCIE control block level,reset.
+   3   :Display Port block level reset (includes DPDMA).
+   4   :FPD WDT reset.
+   5   :AF_FM5 block level reset.
+   6   :AF_FM4 block level reset.
+   7   :AF_FM3 block level reset.
+   8   :AF_FM2 block level reset.
+   9   :AF_FM1 block level reset.
+   10  :AF_FM0 block level reset.
+   11  :GDMA block level reset.
+   12  :Pixel Processor (GPU_PP1) block level reset.
+   13  :Pixel Processor (GPU_PP0) block level reset.
+   14  :GPU block level reset.
+   15  :GT block level reset.
+   16  :Sata block level reset.
+   17  :ACPU3 power on reset.
+   18  :ACPU2 power on reset.
+   19  :ACPU1 power on reset.
+   20  :ACPU0 power on reset.
+   21  :APU L2 reset.
+   22  :ACPU3 reset.
+   23  :ACPU2 reset.
+   24  :ACPU1 reset.
+   25  :ACPU0 reset.
+   26  :DDR block level reset inside of the DDR Sub System.
+   27  :APM block level reset inside of the DDR Sub System.
+   28  :soft reset.
+   29  :GEM 0 reset.
+   30  :GEM 1 reset.
+   31  :GEM 2 reset.
+   32  :GEM 3 reset.
+   33  :qspi reset.
+   34  :uart0 reset.
+   35  :uart1 reset.
+   36  :spi0 reset.
+   37  :spi1 reset.
+   38  :sdio0 reset.
+   39  :sdio1 reset.
+   40  :can0 reset.
+   41  :can1 reset.
+   42  :i2c0 reset.
+   43  :i2c1 reset.
+   44  :ttc0 reset.
+   45  :ttc1 reset.
+   46  :ttc2 reset.
+   47  :ttc3 reset.
+   48  :swdt reset.
+   49  :nand reset.
+   50  :adma reset.
+   51  :gpio reset.
+   52  :iou_cc reset.
+   53  :timestamp reset.
+   54  :rpu_r50 reset.
+   55  :rpu r51 reset.
+   56  :rpu_amba reset.
+   57  :ocm reset.
+   58  :rpu_pge reset.
+   59  :usb0_core reset.
+   60  :usb1_core reset.
+   61  :usb0_hiber reset.
+   62  :usb1_hiber reset.
+   63  :usb0_apb reset.
+   64  :usb1_apb reset.
+   65  :ipi reset.
+   66  :apm reset.
+   67  :rtc reset.
+   68  :sysmon reset.
+   69  :afi_fm6 reset.
+   70  :lpd_swdt reset.
+   71  :fpd_reset.
+   72  :rpu_dbg1 reset.
+   73  :rpu_dbg0 reset.
+   74  :dbg_lpd reset.
+   75  :dbg_fpd reset.
+   76  :apll reset.
+   77  :dpll reset.
+   78  :vpll reset.
+   79  :iopll reset.
+   80  :rpll reset.
+   81  :gpio_pl_0 reset.
+   82  :gpio_pl_1 reset.
+   83  :gpio_pl_2 reset.
+   84  :gpio_pl_3 reset.
+   85  :gpio_pl_4 reset.
+   86  :gpio_pl_5 reset.
+   87  :gpio_pl_6 reset.
+   88  :gpio_pl_7 reset.
+   89  :gpio_pl_8 reset.
+   90  :gpio_pl_9 reset.
+   91  :gpio_pl_10 reset.
+   92  :gpio_pl_11 reset.
+   93  :gpio_pl_12 reset.
+   94  :gpio_pl_13 reset.
+   95  :gpio_pl_14 reset.
+   96  :gpio_pl_15 reset.
+   97  :gpio_pl_16 reset.
+   98  :gpio_pl_17 reset.
+   99  :gpio_pl_18 reset.
+   100 :gpio_pl_19 reset.
+   101 :gpio_pl_20 reset.
+   102 :gpio_pl_21 reset.
+   103 :gpio_pl_22 reset.
+   104 :gpio_pl_23 reset.
+   105 :gpio_pl_24 reset.
+   106 :gpio_pl_25 reset.
+   107 :gpio_pl_26 reset.
+   108 :gpio_pl_27 reset.
+   109 :gpio_pl_28 reset.
+   110 :gpio_pl_29 reset.
+   111 :gpio_pl_30 reset.
+   112 :gpio_pl_31 reset.
+   113 :rpu_ls reset.
+   114 :ps_only reset.
+   115 :pl reset.
+   116 :ps_pl0 reset
+   117 :ps_pl1 reset
+   118 :ps_pl2 reset
+   119 :ps_pl3 reset
+
+---
+Example
+---
+
+firmware

[PATCH 3/9] dt-bindings: reset: Add bindings for ZynqMP reset driver

2018-11-16 Thread Jolly Shah
From: Nava kishore Manne 

Add documentation to describe Xilinx ZynqMP reset driver
bindings.

Signed-off-by: Nava kishore Manne 
Signed-off-by: Jolly Shah 
---
 .../bindings/reset/xlnx,zynqmp-reset.txt   | 148 +
 1 file changed, 148 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt 
b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
new file mode 100644
index 000..e9c1af8
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
@@ -0,0 +1,148 @@
+--
+ =  Zynq UltraScale+ MPSoC reset driver binding =
+--
+The Zynq UltraScale+ MPSoC has several different resets.
+
+See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
+about zynqmp resets.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required Properties:
+- #reset-cells:Specifies the number of cells needed to encode reset
+   line, should be 1
+
+Reset outputs:
+   0   :PCIE config reset.
+   1   :PCIE bridge block level reset (AXI interface).
+   2   :PCIE control block level,reset.
+   3   :Display Port block level reset (includes DPDMA).
+   4   :FPD WDT reset.
+   5   :AF_FM5 block level reset.
+   6   :AF_FM4 block level reset.
+   7   :AF_FM3 block level reset.
+   8   :AF_FM2 block level reset.
+   9   :AF_FM1 block level reset.
+   10  :AF_FM0 block level reset.
+   11  :GDMA block level reset.
+   12  :Pixel Processor (GPU_PP1) block level reset.
+   13  :Pixel Processor (GPU_PP0) block level reset.
+   14  :GPU block level reset.
+   15  :GT block level reset.
+   16  :Sata block level reset.
+   17  :ACPU3 power on reset.
+   18  :ACPU2 power on reset.
+   19  :ACPU1 power on reset.
+   20  :ACPU0 power on reset.
+   21  :APU L2 reset.
+   22  :ACPU3 reset.
+   23  :ACPU2 reset.
+   24  :ACPU1 reset.
+   25  :ACPU0 reset.
+   26  :DDR block level reset inside of the DDR Sub System.
+   27  :APM block level reset inside of the DDR Sub System.
+   28  :soft reset.
+   29  :GEM 0 reset.
+   30  :GEM 1 reset.
+   31  :GEM 2 reset.
+   32  :GEM 3 reset.
+   33  :qspi reset.
+   34  :uart0 reset.
+   35  :uart1 reset.
+   36  :spi0 reset.
+   37  :spi1 reset.
+   38  :sdio0 reset.
+   39  :sdio1 reset.
+   40  :can0 reset.
+   41  :can1 reset.
+   42  :i2c0 reset.
+   43  :i2c1 reset.
+   44  :ttc0 reset.
+   45  :ttc1 reset.
+   46  :ttc2 reset.
+   47  :ttc3 reset.
+   48  :swdt reset.
+   49  :nand reset.
+   50  :adma reset.
+   51  :gpio reset.
+   52  :iou_cc reset.
+   53  :timestamp reset.
+   54  :rpu_r50 reset.
+   55  :rpu r51 reset.
+   56  :rpu_amba reset.
+   57  :ocm reset.
+   58  :rpu_pge reset.
+   59  :usb0_core reset.
+   60  :usb1_core reset.
+   61  :usb0_hiber reset.
+   62  :usb1_hiber reset.
+   63  :usb0_apb reset.
+   64  :usb1_apb reset.
+   65  :ipi reset.
+   66  :apm reset.
+   67  :rtc reset.
+   68  :sysmon reset.
+   69  :afi_fm6 reset.
+   70  :lpd_swdt reset.
+   71  :fpd_reset.
+   72  :rpu_dbg1 reset.
+   73  :rpu_dbg0 reset.
+   74  :dbg_lpd reset.
+   75  :dbg_fpd reset.
+   76  :apll reset.
+   77  :dpll reset.
+   78  :vpll reset.
+   79  :iopll reset.
+   80  :rpll reset.
+   81  :gpio_pl_0 reset.
+   82  :gpio_pl_1 reset.
+   83  :gpio_pl_2 reset.
+   84  :gpio_pl_3 reset.
+   85  :gpio_pl_4 reset.
+   86  :gpio_pl_5 reset.
+   87  :gpio_pl_6 reset.
+   88  :gpio_pl_7 reset.
+   89  :gpio_pl_8 reset.
+   90  :gpio_pl_9 reset.
+   91  :gpio_pl_10 reset.
+   92  :gpio_pl_11 reset.
+   93  :gpio_pl_12 reset.
+   94  :gpio_pl_13 reset.
+   95  :gpio_pl_14 reset.
+   96  :gpio_pl_15 reset.
+   97  :gpio_pl_16 reset.
+   98  :gpio_pl_17 reset.
+   99  :gpio_pl_18 reset.
+   100 :gpio_pl_19 reset.
+   101 :gpio_pl_20 reset.
+   102 :gpio_pl_21 reset.
+   103 :gpio_pl_22 reset.
+   104 :gpio_pl_23 reset.
+   105 :gpio_pl_24 reset.
+   106 :gpio_pl_25 reset.
+   107 :gpio_pl_26 reset.
+   108 :gpio_pl_27 reset.
+   109 :gpio_pl_28 reset.
+   110 :gpio_pl_29 reset.
+   111 :gpio_pl_30 reset.
+   112 :gpio_pl_31 reset.
+   113 :rpu_ls reset.
+   114 :ps_only reset.
+   115 :pl reset.
+   116 :ps_pl0 reset
+   117 :ps_pl1 reset
+   118 :ps_pl2 reset
+   119 :ps_pl3 reset
+
+---
+Example
+---
+
+firmware

[PATCH 5/9] dt-bindings: pinctrl: Add ZynqMP pin controller bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP pin controller
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt   | 272 +
 1 file changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
new file mode 100644
index 000..0d54b40
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
@@ -0,0 +1,272 @@
+   Binding for Xilinx ZynqMP Pinctrl
+
+Required properties:
+ZynqMP pin control driver is populated by ZynqMP firmware and doesn't need
+any separate property.
+
+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.
+
+Required properties for pinmux nodes are:
+ - groups: A list of pinmux groups.
+ - function: The name of a pinmux function to activate for the specified set
+   of groups.
+
+Required properties for configuration nodes:
+One of:
+ - pins: A list of pin names
+ - groups: A list of pinmux groups.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+ groups, function
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+ groups, pins, bias-disable, bias-pull-up, bias-pull-down, slew-rate
+
+ Valid arguments for 'slew-rate' are 'SLEW_RATE_SLOW' and 'SLEW_RATE_FAST' to
+ select between slow and fast respectively.
+
+ Valid values for groups are:
+ 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_10_grp, sdio1_11_grp,
+ sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+ sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+ sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+ sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+ nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+ nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+ can0_1_grp, can0_2_grp, can0_3_grp,
+ can0_4_grp, can0_5_grp, can0_6_grp,
+ can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can0_11_grp, can0_12_grp,
+ can0_13_grp, can0_14_grp, can0_15_grp,
+ can0_16_grp, can0_17_grp, can0_18_grp,
+ can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp,
+ can1_6_grp, can1_7_grp, can1_8_grp,
+ can1_9_grp, can1_10_grp, can1_11_grp,
+ can1_12_grp, can1_13_grp, can1_14_grp,
+ can1_15_grp, can1_16_grp, can1_17_grp,
+ can1_18_grp, can1_19_grp, uart0_0_grp,
+ u

[PATCH 5/9] dt-bindings: pinctrl: Add ZynqMP pin controller bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP pin controller
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.txt   | 272 +
 1 file changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
new file mode 100644
index 000..0d54b40
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.txt
@@ -0,0 +1,272 @@
+   Binding for Xilinx ZynqMP Pinctrl
+
+Required properties:
+ZynqMP pin control driver is populated by ZynqMP firmware and doesn't need
+any separate property.
+
+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.
+
+Required properties for pinmux nodes are:
+ - groups: A list of pinmux groups.
+ - function: The name of a pinmux function to activate for the specified set
+   of groups.
+
+Required properties for configuration nodes:
+One of:
+ - pins: A list of pin names
+ - groups: A list of pinmux groups.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+ groups, function
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+ groups, pins, bias-disable, bias-pull-up, bias-pull-down, slew-rate
+
+ Valid arguments for 'slew-rate' are 'SLEW_RATE_SLOW' and 'SLEW_RATE_FAST' to
+ select between slow and fast respectively.
+
+ Valid values for groups are:
+ 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_10_grp, sdio1_11_grp,
+ sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+ sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+ sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+ sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+ nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+ nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+ can0_1_grp, can0_2_grp, can0_3_grp,
+ can0_4_grp, can0_5_grp, can0_6_grp,
+ can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can0_11_grp, can0_12_grp,
+ can0_13_grp, can0_14_grp, can0_15_grp,
+ can0_16_grp, can0_17_grp, can0_18_grp,
+ can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp,
+ can1_6_grp, can1_7_grp, can1_8_grp,
+ can1_9_grp, can1_10_grp, can1_11_grp,
+ can1_12_grp, can1_13_grp, can1_14_grp,
+ can1_15_grp, can1_16_grp, can1_17_grp,
+ can1_18_grp, can1_19_grp, uart0_0_grp,
+ u

[PATCH 2/9] dt-bindings: soc: Add ZynqMP PM bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



[PATCH 2/9] dt-bindings: soc: Add ZynqMP PM bindings

2018-11-16 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP power management
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 .../bindings/power/reset/xlnx,zynqmp-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt

diff --git 
a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt 
b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
new file mode 100644
index 000..d366f1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
@@ -0,0 +1,25 @@
+
+Device Tree Bindings for the Xilinx Zynq MPSoC Power Management
+
+The zynqmp-power node describes the power management configurations.
+It will control remote suspend/shutdown interfaces.
+
+Required properties:
+ - compatible: Must contain:   "xlnx,zynqmp-power"
+ - interrupts: Interrupt specifier
+
+---
+Example
+---
+
+firmware {
+   zynqmp_firmware: zynqmp-firmware {
+   compatible = "xlnx,zynqmp-firmware";
+   method = "smc";
+
+   zynqmp_power: zynqmp-power {
+   compatible = "xlnx,zynqmp-power";
+   interrupts = <0 35 4>;
+   };
+   };
+};
-- 
2.7.4



RE: [PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power domain driver

2018-10-10 Thread Jolly Shah
Ping for comments

Thanks,
Jolly Shah

> -Original Message-
> From: Jolly Shah [mailto:jolly.s...@xilinx.com]
> Sent: Thursday, October 04, 2018 2:24 PM
> To: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com
> Cc: Rajan Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jolly Shah
> 
> Subject: [PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power
> domain driver
> 
> The zynqmp power domain driver communicates the usage requirements for
> logical power domains / devices to the platform FW.
> FW is responsible for choosing appropriate power states, taking Linux' usage
> information into account.
> 
> This patch series is based on top of Xilinx firmware patch set:
> https://patchwork.kernel.org/cover/10555405/
> 
> v3:
>  - Changed binding to have FW node as a power controller as suggested by Rob
>  - Updated FW driver to register it as mfd child devices from firmware probe
>  - Move bindings location as suggested
> 
> v2:
>  - Rebased on top of latest firmware driver patch series
>  - Updated driver name from zynqmp-genpd to zynqmp-power-controller
>  - Updated device tree bindings to move power controller node under firmware
> node
> 
> Jolly Shah (1):
>   drivers: soc: xilinx: Add ZynqMP power domain driver
> 
> Rajan Vaja (3):
>   dt-bindings: power: Add ZynqMP power domain bindings
>   firmware: xilinx: Add APIs to control node status/power
>   firmware: xilinx: Add node IDs for zynqmp firmware
> 
>  .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 ++
>  drivers/firmware/xilinx/Kconfig|   1 +
>  drivers/firmware/xilinx/zynqmp.c   |  73 
>  drivers/soc/xilinx/Kconfig |   9 +
>  drivers/soc/xilinx/Makefile|   2 +
>  drivers/soc/xilinx/zynqmp_pm_domains.c | 403
> +
>  include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 ++
>  include/linux/firmware/xlnx-zynqmp.h   |  98 +
>  8 files changed, 659 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/xlnx,zynqmp-
> genpd.txt
>  create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c
>  create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h
> 
> --
> 2.7.4



RE: [PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power domain driver

2018-10-10 Thread Jolly Shah
Ping for comments

Thanks,
Jolly Shah

> -Original Message-
> From: Jolly Shah [mailto:jolly.s...@xilinx.com]
> Sent: Thursday, October 04, 2018 2:24 PM
> To: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com
> Cc: Rajan Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jolly Shah
> 
> Subject: [PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power
> domain driver
> 
> The zynqmp power domain driver communicates the usage requirements for
> logical power domains / devices to the platform FW.
> FW is responsible for choosing appropriate power states, taking Linux' usage
> information into account.
> 
> This patch series is based on top of Xilinx firmware patch set:
> https://patchwork.kernel.org/cover/10555405/
> 
> v3:
>  - Changed binding to have FW node as a power controller as suggested by Rob
>  - Updated FW driver to register it as mfd child devices from firmware probe
>  - Move bindings location as suggested
> 
> v2:
>  - Rebased on top of latest firmware driver patch series
>  - Updated driver name from zynqmp-genpd to zynqmp-power-controller
>  - Updated device tree bindings to move power controller node under firmware
> node
> 
> Jolly Shah (1):
>   drivers: soc: xilinx: Add ZynqMP power domain driver
> 
> Rajan Vaja (3):
>   dt-bindings: power: Add ZynqMP power domain bindings
>   firmware: xilinx: Add APIs to control node status/power
>   firmware: xilinx: Add node IDs for zynqmp firmware
> 
>  .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 ++
>  drivers/firmware/xilinx/Kconfig|   1 +
>  drivers/firmware/xilinx/zynqmp.c   |  73 
>  drivers/soc/xilinx/Kconfig |   9 +
>  drivers/soc/xilinx/Makefile|   2 +
>  drivers/soc/xilinx/zynqmp_pm_domains.c | 403
> +
>  include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 ++
>  include/linux/firmware/xlnx-zynqmp.h   |  98 +
>  8 files changed, 659 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/xlnx,zynqmp-
> genpd.txt
>  create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c
>  create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h
> 
> --
> 2.7.4



RE: [PATCH v4 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver

2018-10-10 Thread Jolly Shah
Ping for comments


> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Jolly Shah
> Sent: Friday, September 14, 2018 12:40 PM
> To: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com
> Cc: Rajan Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jolly Shah
> 
> Subject: [PATCH v4 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver
> 
> Add ZynqMP PM driver. PM driver provides power management support for
> ZynqMP.
> 
> This patch series is based on top of Xilinx firmware patch set:
> https://patchwork.kernel.org/cover/10598195/
> 
> v4:
>  - Minor fixes to address v3 review comments
> 
> v3:
>  - Updated DT bindings as per v2 review comments
> 
> v2:
>  - Rebased on top of latest firmware driver patch series
>  - Updated driver to use shared interrupt instead of mailbox
> 
> Rajan Vaja (3):
>   dt-bindings: soc: Add ZynqMP PM bindings
>   firmware: xilinx: Implement ZynqMP power management APIs
>   drivers: soc: xilinx: Add ZynqMP PM driver
> 
>  .../bindings/power/reset/xlnx,zynqmp-power.txt |  22 +++
>  drivers/firmware/xilinx/zynqmp.c   |  29 
>  drivers/soc/xilinx/Kconfig |  11 ++
>  drivers/soc/xilinx/Makefile|   1 +
>  drivers/soc/xilinx/zynqmp_power.c  | 178 
> +
>  include/linux/firmware/xlnx-zynqmp.h   |  20 +++
>  6 files changed, 261 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
>  create mode 100644 drivers/soc/xilinx/zynqmp_power.c
> 
> --
> 2.7.4



RE: [PATCH v4 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver

2018-10-10 Thread Jolly Shah
Ping for comments


> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Jolly Shah
> Sent: Friday, September 14, 2018 12:40 PM
> To: matthias@gmail.com; andy.gr...@linaro.org; shawn...@kernel.org;
> geert+rene...@glider.be; bjorn.anders...@linaro.org;
> sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> ; robh...@kernel.org; mark.rutl...@arm.com
> Cc: Rajan Vaja ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Jolly Shah
> 
> Subject: [PATCH v4 0/3] drivers: soc: xilinx: Add support for ZynqMP PM driver
> 
> Add ZynqMP PM driver. PM driver provides power management support for
> ZynqMP.
> 
> This patch series is based on top of Xilinx firmware patch set:
> https://patchwork.kernel.org/cover/10598195/
> 
> v4:
>  - Minor fixes to address v3 review comments
> 
> v3:
>  - Updated DT bindings as per v2 review comments
> 
> v2:
>  - Rebased on top of latest firmware driver patch series
>  - Updated driver to use shared interrupt instead of mailbox
> 
> Rajan Vaja (3):
>   dt-bindings: soc: Add ZynqMP PM bindings
>   firmware: xilinx: Implement ZynqMP power management APIs
>   drivers: soc: xilinx: Add ZynqMP PM driver
> 
>  .../bindings/power/reset/xlnx,zynqmp-power.txt |  22 +++
>  drivers/firmware/xilinx/zynqmp.c   |  29 
>  drivers/soc/xilinx/Kconfig |  11 ++
>  drivers/soc/xilinx/Makefile|   1 +
>  drivers/soc/xilinx/zynqmp_power.c  | 178 
> +
>  include/linux/firmware/xlnx-zynqmp.h   |  20 +++
>  6 files changed, 261 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
>  create mode 100644 drivers/soc/xilinx/zynqmp_power.c
> 
> --
> 2.7.4



[PATCH v6 2/4] firmware: xilinx: Add zynqmp IOCTL API for device control

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add ZynqMP firmware IOCTL API to control and configure
devices like PLLs, SD, Gem, etc.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
---
 drivers/firmware/xilinx/zynqmp.c | 42 
 include/linux/firmware/xlnx-zynqmp.h |  4 +++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..9a1c72a 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,47 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32 
*parent_id)
return ret;
 }
 
+/**
+ * zynqmp_is_valid_ioctl() - Check whether IOCTL ID is valid or not
+ * @ioctl_id:  IOCTL ID
+ *
+ * Return: 1 if IOCTL is valid else 0
+ */
+static inline int zynqmp_is_valid_ioctl(u32 ioctl_id)
+{
+   switch (ioctl_id) {
+   case IOCTL_SET_PLL_FRAC_MODE:
+   case IOCTL_GET_PLL_FRAC_MODE:
+   case IOCTL_SET_PLL_FRAC_DATA:
+   case IOCTL_GET_PLL_FRAC_DATA:
+   return 1;
+   default:
+   return 0;
+   }
+}
+
+/**
+ * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
+ * @node_id:   Node ID of the device
+ * @ioctl_id:  ID of the requested IOCTL
+ * @arg1:  Argument 1 to requested IOCTL call
+ * @arg2:  Argument 2 to requested IOCTL call
+ * @out:   Returned output value
+ *
+ * This function calls IOCTL to firmware for device control and configuration.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
+  u32 *out)
+{
+   if (!zynqmp_is_valid_ioctl(ioctl_id))
+   return -EINVAL;
+
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
+  arg1, arg2, out);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +481,7 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+   .ioctl = zynqmp_pm_ioctl,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..7a9db08 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,7 +34,8 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
-   PM_QUERY_DATA = 35,
+   PM_IOCTL = 34,
+   PM_QUERY_DATA,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
PM_CLOCK_GETSTATE,
@@ -99,6 +100,7 @@ struct zynqmp_eemi_ops {
int (*clock_getrate)(u32 clock_id, u64 *rate);
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
+   int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
 };
 
 #if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
-- 
2.7.4



[PATCH v6 2/4] firmware: xilinx: Add zynqmp IOCTL API for device control

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add ZynqMP firmware IOCTL API to control and configure
devices like PLLs, SD, Gem, etc.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
---
 drivers/firmware/xilinx/zynqmp.c | 42 
 include/linux/firmware/xlnx-zynqmp.h |  4 +++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..9a1c72a 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,47 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32 
*parent_id)
return ret;
 }
 
+/**
+ * zynqmp_is_valid_ioctl() - Check whether IOCTL ID is valid or not
+ * @ioctl_id:  IOCTL ID
+ *
+ * Return: 1 if IOCTL is valid else 0
+ */
+static inline int zynqmp_is_valid_ioctl(u32 ioctl_id)
+{
+   switch (ioctl_id) {
+   case IOCTL_SET_PLL_FRAC_MODE:
+   case IOCTL_GET_PLL_FRAC_MODE:
+   case IOCTL_SET_PLL_FRAC_DATA:
+   case IOCTL_GET_PLL_FRAC_DATA:
+   return 1;
+   default:
+   return 0;
+   }
+}
+
+/**
+ * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
+ * @node_id:   Node ID of the device
+ * @ioctl_id:  ID of the requested IOCTL
+ * @arg1:  Argument 1 to requested IOCTL call
+ * @arg2:  Argument 2 to requested IOCTL call
+ * @out:   Returned output value
+ *
+ * This function calls IOCTL to firmware for device control and configuration.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
+  u32 *out)
+{
+   if (!zynqmp_is_valid_ioctl(ioctl_id))
+   return -EINVAL;
+
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
+  arg1, arg2, out);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +481,7 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+   .ioctl = zynqmp_pm_ioctl,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..7a9db08 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,7 +34,8 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
-   PM_QUERY_DATA = 35,
+   PM_IOCTL = 34,
+   PM_QUERY_DATA,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
PM_CLOCK_GETSTATE,
@@ -99,6 +100,7 @@ struct zynqmp_eemi_ops {
int (*clock_getrate)(u32 clock_id, u64 *rate);
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
+   int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
 };
 
 #if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
-- 
2.7.4



RE: [PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver

2018-10-08 Thread Jolly Shah
Hi Stephen,

> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: Sunday, October 07, 2018 7:28 PM
> To: Jolly Shah ; a...@kernel.org; linux-
> c...@vger.kernel.org; Michal Simek ;
> mturque...@baylibre.com; o...@lixom.net; sb...@codeaurora.org
> Cc: Rajan Vaja ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Jolly Shah ; Rajan Vaja
> ; Tejas Patel ; Shubhrajyoti Datta
> ; Jolly Shah 
> Subject: Re: [PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver
> 
> Quoting Jolly Shah (2018-09-28 15:18:00)
> > diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c new
> > file mode 100644 index 000..1b07d77
> > --- /dev/null
> > +++ b/drivers/clk/zynqmp/clkc.c
> > @@ -0,0 +1,716 @@
> [...]
> > + * @type:  Clock type: CLK_TYPE_OUTPUT or CLK_TYPE_EXTERNAL
> > + *
> > + * Return: 0 on success else error code  */ static int
> > +zynqmp_get_clock_type(u32 clk_id, u32 *type) {
> > +   int ret;
> > +
> > +   ret = zynqmp_is_valid_clock(clk_id);
> > +   if (ret == 1) {
> > +   *type = clock[clk_id].type;
> > +   return 0;
> > +   }
> > +
> > +   return ret == 0 ? -EINVAL : ret; }
> > +
> > +/**
> > + * zynqmp_pm_clock_get_num_clocks() - Get number of clocks in system
> > + * @nclocks:   Number of clocks in system/board.
> > + *
> > + * Call firmware API to get number of clocks.
> > + *
> > + * Return: 0 on success else error code.
> > + */
> > +static int zynqmp_pm_clock_get_num_clocks(u32 *nclocks) {
> > +   struct zynqmp_pm_query_data qdata = {0};
> > +   __le32 ret_payload[PAYLOAD_ARG_CNT];
> 
> I asked about endianess but this isn't the right fix. Just marking something 
> as
> __le32 but then not using that type and just passing it to some function that
> takes a u32 pointer doesn't work. So is the firmware side always little 
> endian? If
> so, maybe the ioctls can do the byte swap and then the kernel API can be 
> native
> CPU endian while the firmware layer can be aware that things may need
> swapping. I'm suggesting that this type is just u32 and then the eemi_ops
> functions accept u32 and do the swapping themselves.
> 
> If you put back u32 here and elsewhere in this patch you can have my
> 
> Reviewed-by: Stephen Boyd 
> 
> The fix to the underlying ops for endian correctness can come later, so don't 
> feel
> like it needs to be fixed right now.

Thanks for clarification. It makes perfect sense. I pushed v6 with suggested 
change and your review tag. 
I will send an incremental patch for endianness correction.

Thanks,
Jolly Shah



RE: [PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver

2018-10-08 Thread Jolly Shah
Hi Stephen,

> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: Sunday, October 07, 2018 7:28 PM
> To: Jolly Shah ; a...@kernel.org; linux-
> c...@vger.kernel.org; Michal Simek ;
> mturque...@baylibre.com; o...@lixom.net; sb...@codeaurora.org
> Cc: Rajan Vaja ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Jolly Shah ; Rajan Vaja
> ; Tejas Patel ; Shubhrajyoti Datta
> ; Jolly Shah 
> Subject: Re: [PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver
> 
> Quoting Jolly Shah (2018-09-28 15:18:00)
> > diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c new
> > file mode 100644 index 000..1b07d77
> > --- /dev/null
> > +++ b/drivers/clk/zynqmp/clkc.c
> > @@ -0,0 +1,716 @@
> [...]
> > + * @type:  Clock type: CLK_TYPE_OUTPUT or CLK_TYPE_EXTERNAL
> > + *
> > + * Return: 0 on success else error code  */ static int
> > +zynqmp_get_clock_type(u32 clk_id, u32 *type) {
> > +   int ret;
> > +
> > +   ret = zynqmp_is_valid_clock(clk_id);
> > +   if (ret == 1) {
> > +   *type = clock[clk_id].type;
> > +   return 0;
> > +   }
> > +
> > +   return ret == 0 ? -EINVAL : ret; }
> > +
> > +/**
> > + * zynqmp_pm_clock_get_num_clocks() - Get number of clocks in system
> > + * @nclocks:   Number of clocks in system/board.
> > + *
> > + * Call firmware API to get number of clocks.
> > + *
> > + * Return: 0 on success else error code.
> > + */
> > +static int zynqmp_pm_clock_get_num_clocks(u32 *nclocks) {
> > +   struct zynqmp_pm_query_data qdata = {0};
> > +   __le32 ret_payload[PAYLOAD_ARG_CNT];
> 
> I asked about endianess but this isn't the right fix. Just marking something 
> as
> __le32 but then not using that type and just passing it to some function that
> takes a u32 pointer doesn't work. So is the firmware side always little 
> endian? If
> so, maybe the ioctls can do the byte swap and then the kernel API can be 
> native
> CPU endian while the firmware layer can be aware that things may need
> swapping. I'm suggesting that this type is just u32 and then the eemi_ops
> functions accept u32 and do the swapping themselves.
> 
> If you put back u32 here and elsewhere in this patch you can have my
> 
> Reviewed-by: Stephen Boyd 
> 
> The fix to the underlying ops for endian correctness can come later, so don't 
> feel
> like it needs to be fixed right now.

Thanks for clarification. It makes perfect sense. I pushed v6 with suggested 
change and your review tag. 
I will send an incremental patch for endianness correction.

Thanks,
Jolly Shah



[PATCH v6 1/4] Documentation: xilinx: Add documentation for eemi APIs

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add documentation for embedded energy management interface (EEMI)
APIs. It includes information about eemi ops and how to use them.
It also includes API information and supported IOCTL IDs which can
be used for device and control configuration.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
---
 Documentation/xilinx/eemi.txt | 67 +++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/xilinx/eemi.txt

diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt
new file mode 100644
index 000..0ab686c
--- /dev/null
+++ b/Documentation/xilinx/eemi.txt
@@ -0,0 +1,67 @@
+-
+Xilinx Zynq MPSoC EEMI Documentation
+-
+
+Xilinx Zynq MPSoC Firmware Interface
+-
+The zynqmp-firmware node describes the interface to platform firmware.
+ZynqMP has an interface to communicate with secure firmware. Firmware
+driver provides an interface to firmware APIs. Interface APIs can be
+used by any driver to communicate with PMC(Platform Management Controller).
+
+Embedded Energy Management Interface (EEMI)
+--
+The embedded energy management interface is used to allow software
+components running across different processing clusters on a chip or
+device to communicate with a power management controller (PMC) on a
+device to issue or respond to power management requests.
+
+EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
+The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
+structure. Any driver who want to communicate with PMC using EEMI APIs
+can call zynqmp_pm_get_eemi_ops().
+
+Example of EEMI ops:
+
+   /* zynqmp-firmware driver maintain all EEMI APIs */
+   struct zynqmp_eemi_ops {
+   int (*get_api_version)(u32 *version);
+   int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
+   };
+
+   static const struct zynqmp_eemi_ops eemi_ops = {
+   .get_api_version = zynqmp_pm_get_api_version,
+   .query_data = zynqmp_pm_query_data,
+   };
+
+Example of EEMI ops usage:
+
+   static const struct zynqmp_eemi_ops *eemi_ops;
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   eemi_ops = zynqmp_pm_get_eemi_ops();
+   if (!eemi_ops)
+   return -ENXIO;
+
+   ret = eemi_ops->query_data(qdata, ret_payload);
+
+IOCTL
+--
+IOCTL API is for device control and configuration. It is not a system
+IOCTL but it is an EEMI API. This API can be used by master to control
+any device specific configuration. IOCTL definitions can be platform
+specific. This API also manage shared device configuration.
+
+The following IOCTL IDs are valid for device control:
+- IOCTL_SET_PLL_FRAC_MODE  8
+- IOCTL_GET_PLL_FRAC_MODE  9
+- IOCTL_SET_PLL_FRAC_DATA  10
+- IOCTL_GET_PLL_FRAC_DATA  11
+
+Refer EEMI API guide [0] for IOCTL specific parameters and other EEMI APIs.
+
+References
+--
+[0] Embedded Energy Management Interface (EEMI) API guide:
+
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
-- 
2.7.4



[PATCH v6 1/4] Documentation: xilinx: Add documentation for eemi APIs

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add documentation for embedded energy management interface (EEMI)
APIs. It includes information about eemi ops and how to use them.
It also includes API information and supported IOCTL IDs which can
be used for device and control configuration.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
---
 Documentation/xilinx/eemi.txt | 67 +++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/xilinx/eemi.txt

diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt
new file mode 100644
index 000..0ab686c
--- /dev/null
+++ b/Documentation/xilinx/eemi.txt
@@ -0,0 +1,67 @@
+-
+Xilinx Zynq MPSoC EEMI Documentation
+-
+
+Xilinx Zynq MPSoC Firmware Interface
+-
+The zynqmp-firmware node describes the interface to platform firmware.
+ZynqMP has an interface to communicate with secure firmware. Firmware
+driver provides an interface to firmware APIs. Interface APIs can be
+used by any driver to communicate with PMC(Platform Management Controller).
+
+Embedded Energy Management Interface (EEMI)
+--
+The embedded energy management interface is used to allow software
+components running across different processing clusters on a chip or
+device to communicate with a power management controller (PMC) on a
+device to issue or respond to power management requests.
+
+EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
+The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
+structure. Any driver who want to communicate with PMC using EEMI APIs
+can call zynqmp_pm_get_eemi_ops().
+
+Example of EEMI ops:
+
+   /* zynqmp-firmware driver maintain all EEMI APIs */
+   struct zynqmp_eemi_ops {
+   int (*get_api_version)(u32 *version);
+   int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
+   };
+
+   static const struct zynqmp_eemi_ops eemi_ops = {
+   .get_api_version = zynqmp_pm_get_api_version,
+   .query_data = zynqmp_pm_query_data,
+   };
+
+Example of EEMI ops usage:
+
+   static const struct zynqmp_eemi_ops *eemi_ops;
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   eemi_ops = zynqmp_pm_get_eemi_ops();
+   if (!eemi_ops)
+   return -ENXIO;
+
+   ret = eemi_ops->query_data(qdata, ret_payload);
+
+IOCTL
+--
+IOCTL API is for device control and configuration. It is not a system
+IOCTL but it is an EEMI API. This API can be used by master to control
+any device specific configuration. IOCTL definitions can be platform
+specific. This API also manage shared device configuration.
+
+The following IOCTL IDs are valid for device control:
+- IOCTL_SET_PLL_FRAC_MODE  8
+- IOCTL_GET_PLL_FRAC_MODE  9
+- IOCTL_SET_PLL_FRAC_DATA  10
+- IOCTL_GET_PLL_FRAC_DATA  11
+
+Refer EEMI API guide [0] for IOCTL specific parameters and other EEMI APIs.
+
+References
+--
+[0] Embedded Energy Management Interface (EEMI) API guide:
+
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
-- 
2.7.4



[PATCH v6 4/4] drivers: clk: Add ZynqMP clock driver

2018-10-08 Thread Jolly Shah
From: Jolly Shah 

This patch adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from
firmware and regiters pll and output clocks with CCF.

Signed-off-by: Rajan Vaja 
Signed-off-by: Tejas Patel 
Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
Reviewed-by: Stephen Boyd 
---
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/zynqmp/Kconfig   |  10 +
 drivers/clk/zynqmp/Makefile  |   4 +
 drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 +++
 drivers/clk/zynqmp/clk-mux-zynqmp.c  | 141 +++
 drivers/clk/zynqmp/clk-zynqmp.h  |  68 
 drivers/clk/zynqmp/clkc.c| 716 +++
 drivers/clk/zynqmp/divider.c | 217 +++
 drivers/clk/zynqmp/pll.c | 335 
 include/linux/firmware/xlnx-zynqmp.h |   1 +
 11 files changed, 1638 insertions(+)
 create mode 100644 drivers/clk/zynqmp/Kconfig
 create mode 100644 drivers/clk/zynqmp/Makefile
 create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
 create mode 100644 drivers/clk/zynqmp/clkc.c
 create mode 100644 drivers/clk/zynqmp/divider.c
 create mode 100644 drivers/clk/zynqmp/pll.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 98ce9fc..ab2ea76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -253,5 +253,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/zynqmp/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71ec41e..b6ac0d2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -100,3 +100,4 @@ obj-$(CONFIG_X86)   += x86/
 endif
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
diff --git a/drivers/clk/zynqmp/Kconfig b/drivers/clk/zynqmp/Kconfig
new file mode 100644
index 000..1708605
--- /dev/null
+++ b/drivers/clk/zynqmp/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config COMMON_CLK_ZYNQMP
+   bool "Support for Xilinx ZynqMP Ultrascale+ clock controllers"
+   depends on ARCH_ZYNQMP || COMPILE_TEST
+   depends on ZYNQMP_FIRMWARE
+   help
+ Support for the Zynqmp Ultrascale clock controller.
+ It has a dependency on the PMU firmware.
+ Say Y if you want to include clock support.
diff --git a/drivers/clk/zynqmp/Makefile b/drivers/clk/zynqmp/Makefile
new file mode 100644
index 000..0ec24bf
--- /dev/null
+++ b/drivers/clk/zynqmp/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Zynq Ultrascale+ MPSoC clock specific Makefile
+
+obj-$(CONFIG_ARCH_ZYNQMP)  += pll.o clk-gate-zynqmp.o divider.o 
clk-mux-zynqmp.o clkc.o
diff --git a/drivers/clk/zynqmp/clk-gate-zynqmp.c 
b/drivers/clk/zynqmp/clk-gate-zynqmp.c
new file mode 100644
index 000..83b236f
--- /dev/null
+++ b/drivers/clk/zynqmp/clk-gate-zynqmp.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq UltraScale+ MPSoC clock controller
+ *
+ *  Copyright (C) 2016-2018 Xilinx
+ *
+ * Gated clock implementation
+ */
+
+#include 
+#include 
+#include "clk-zynqmp.h"
+
+/**
+ * struct clk_gate - gating clock
+ * @hw:handle between common and hardware-specific interfaces
+ * @flags: hardware-specific flags
+ * @clk_id:Id of clock
+ */
+struct zynqmp_clk_gate {
+   struct clk_hw hw;
+   u8 flags;
+   u32 clk_id;
+};
+
+#define to_zynqmp_clk_gate(_hw) container_of(_hw, struct zynqmp_clk_gate, hw)
+
+/**
+ * zynqmp_clk_gate_enable() - Enable clock
+ * @hw:handle between common and hardware-specific interfaces
+ *
+ * Return: 0 on success else error code
+ */
+static int zynqmp_clk_gate_enable(struct clk_hw *hw)
+{
+   struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+   const char *clk_name = clk_hw_get_name(hw);
+   u32 clk_id = gate->clk_id;
+   int ret;
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+   ret = eemi_ops->clock_enable(clk_id);
+
+   if (ret)
+   pr_warn_once("%s() clock enabled failed for %s, ret = %d\n",
+__func__, clk_name, ret);
+
+   return ret;
+}
+
+/*
+ * zynqmp_clk_gate_disable() - Disable clock
+ * @hw:handle between common and hardware-specific interfaces
+ */
+static void zynqmp_clk_gate_disable(struct clk_hw *hw)
+{
+   struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+   const char *clk_name = clk_hw_get_name(hw);
+   u32 clk_id = gate->clk_id;
+   int ret;
+   co

[PATCH v6 4/4] drivers: clk: Add ZynqMP clock driver

2018-10-08 Thread Jolly Shah
From: Jolly Shah 

This patch adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from
firmware and regiters pll and output clocks with CCF.

Signed-off-by: Rajan Vaja 
Signed-off-by: Tejas Patel 
Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Jolly Shah 
Acked-by: Olof Johansson 
Reviewed-by: Stephen Boyd 
---
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/zynqmp/Kconfig   |  10 +
 drivers/clk/zynqmp/Makefile  |   4 +
 drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 +++
 drivers/clk/zynqmp/clk-mux-zynqmp.c  | 141 +++
 drivers/clk/zynqmp/clk-zynqmp.h  |  68 
 drivers/clk/zynqmp/clkc.c| 716 +++
 drivers/clk/zynqmp/divider.c | 217 +++
 drivers/clk/zynqmp/pll.c | 335 
 include/linux/firmware/xlnx-zynqmp.h |   1 +
 11 files changed, 1638 insertions(+)
 create mode 100644 drivers/clk/zynqmp/Kconfig
 create mode 100644 drivers/clk/zynqmp/Makefile
 create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
 create mode 100644 drivers/clk/zynqmp/clkc.c
 create mode 100644 drivers/clk/zynqmp/divider.c
 create mode 100644 drivers/clk/zynqmp/pll.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 98ce9fc..ab2ea76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -253,5 +253,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/zynqmp/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71ec41e..b6ac0d2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -100,3 +100,4 @@ obj-$(CONFIG_X86)   += x86/
 endif
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
diff --git a/drivers/clk/zynqmp/Kconfig b/drivers/clk/zynqmp/Kconfig
new file mode 100644
index 000..1708605
--- /dev/null
+++ b/drivers/clk/zynqmp/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config COMMON_CLK_ZYNQMP
+   bool "Support for Xilinx ZynqMP Ultrascale+ clock controllers"
+   depends on ARCH_ZYNQMP || COMPILE_TEST
+   depends on ZYNQMP_FIRMWARE
+   help
+ Support for the Zynqmp Ultrascale clock controller.
+ It has a dependency on the PMU firmware.
+ Say Y if you want to include clock support.
diff --git a/drivers/clk/zynqmp/Makefile b/drivers/clk/zynqmp/Makefile
new file mode 100644
index 000..0ec24bf
--- /dev/null
+++ b/drivers/clk/zynqmp/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Zynq Ultrascale+ MPSoC clock specific Makefile
+
+obj-$(CONFIG_ARCH_ZYNQMP)  += pll.o clk-gate-zynqmp.o divider.o 
clk-mux-zynqmp.o clkc.o
diff --git a/drivers/clk/zynqmp/clk-gate-zynqmp.c 
b/drivers/clk/zynqmp/clk-gate-zynqmp.c
new file mode 100644
index 000..83b236f
--- /dev/null
+++ b/drivers/clk/zynqmp/clk-gate-zynqmp.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq UltraScale+ MPSoC clock controller
+ *
+ *  Copyright (C) 2016-2018 Xilinx
+ *
+ * Gated clock implementation
+ */
+
+#include 
+#include 
+#include "clk-zynqmp.h"
+
+/**
+ * struct clk_gate - gating clock
+ * @hw:handle between common and hardware-specific interfaces
+ * @flags: hardware-specific flags
+ * @clk_id:Id of clock
+ */
+struct zynqmp_clk_gate {
+   struct clk_hw hw;
+   u8 flags;
+   u32 clk_id;
+};
+
+#define to_zynqmp_clk_gate(_hw) container_of(_hw, struct zynqmp_clk_gate, hw)
+
+/**
+ * zynqmp_clk_gate_enable() - Enable clock
+ * @hw:handle between common and hardware-specific interfaces
+ *
+ * Return: 0 on success else error code
+ */
+static int zynqmp_clk_gate_enable(struct clk_hw *hw)
+{
+   struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+   const char *clk_name = clk_hw_get_name(hw);
+   u32 clk_id = gate->clk_id;
+   int ret;
+   const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+   ret = eemi_ops->clock_enable(clk_id);
+
+   if (ret)
+   pr_warn_once("%s() clock enabled failed for %s, ret = %d\n",
+__func__, clk_name, ret);
+
+   return ret;
+}
+
+/*
+ * zynqmp_clk_gate_disable() - Disable clock
+ * @hw:handle between common and hardware-specific interfaces
+ */
+static void zynqmp_clk_gate_disable(struct clk_hw *hw)
+{
+   struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+   const char *clk_name = clk_hw_get_name(hw);
+   u32 clk_id = gate->clk_id;
+   int ret;
+   co

[PATCH v6 3/4] dt-bindings: clock: Add bindings for ZynqMP clock driver

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP clock driver
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  53 ++
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 +
 2 files changed, 169 insertions(+)
 create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h

diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 1b431d9..614bac5 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -17,6 +17,53 @@ Required properties:
  - "smc" : SMC #0, following the SMCCC
  - "hvc" : HVC #0, following the SMCCC
 
+--
+Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
+Zynq MPSoC firmware interface
+--
+The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
+tree. It reads required input clock frequencies from the devicetree and acts
+as clock provider for all clock consumers of PS clocks.
+
+See clock_bindings.txt for more information on the generic clock bindings.
+
+Required properties:
+ - #clock-cells:   Must be 1
+ - compatible: Must contain:   "xlnx,zynqmp-clk"
+ - clocks: List of clock specifiers which are external input
+   clocks to the given clock controller. Please refer
+   the next section to find the input clocks for a
+   given controller.
+ - clock-names:List of clock names which are exteral input 
clocks
+   to the given clock controller. Please refer to the
+   clock bindings for more details.
+
+Input clocks for zynqmp Ultrascale+ clock controller:
+
+The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
+inputs. These required clock inputs are:
+ - pss_ref_clk (PS reference clock)
+ - video_clk (reference clock for video system )
+ - pss_alt_ref_clk (alternative PS reference clock)
+ - aux_ref_clk
+ - gt_crx_ref_clk (transceiver reference clock)
+
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source:
+ - swdt0_ext_clk
+ - swdt1_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - gem2_emio_clk
+ - gem3_emio_clk
+ - mio_clk_XX  # with XX = 00..77
+ - mio_clk_50_or_51#for the mux clock to gem tsu from 50 or 51
+
+
+Output clocks are registered based on clock information received
+from firmware. Output clocks indexes are mentioned in
+include/dt-bindings/clock/xlnx,zynqmp-clk.h.
+
 ---
 Example
 ---
@@ -25,5 +72,11 @@ firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
+   zynqmp_clk: clock-controller {
+   #clock-cells = <1>;
+   compatible = "xlnx,zynqmp-clk";
+   clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
+   clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
+   };
};
 };
diff --git a/include/dt-bindings/clock/xlnx,zynqmp-clk.h 
b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
new file mode 100644
index 000..4aebe6e
--- /dev/null
+++ b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ *  Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ */
+
+#ifndef _DT_BINDINGS_CLK_ZYNQMP_H
+#define _DT_BINDINGS_CLK_ZYNQMP_H
+
+#define IOPLL  0
+#define RPLL   1
+#define APLL   2
+#define DPLL   3
+#define VPLL   4
+#define IOPLL_TO_FPD   5
+#define RPLL_TO_FPD6
+#define APLL_TO_LPD7
+#define DPLL_TO_LPD8
+#define VPLL_TO_LPD9
+#define ACPU   10
+#define ACPU_HALF  11
+#define DBF_FPD12
+#define DBF_LPD13
+#define DBG_TRACE  14
+#define DBG_TSTMP  15
+#define DP_VIDEO_REF   16
+#define DP_AUDIO_REF   17
+#define DP_STC_REF 18
+#define GDMA_REF   19
+#define DPDMA_REF  20
+#define DDR_REF21
+#define SATA_REF   22
+

[PATCH v6 0/4] drivers: clk: Add ZynqMP clock driver support

2018-10-08 Thread Jolly Shah
This patchset adds CCF compliant clock driver for ZynqMP.Clock driver queries 
supported clock information from firmware and regiters pll and output clocks 
with CCF.

This patch series is earlier reveiwed as part of FW patchset 
(https://patchwork.kernel.org/cover/10555405/). 
FW driver from that patchset is merged. This patchset contains only clock 
driver and is based on top of 
xilinx firmware patch set available in below tree:
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=next/drivers

v6:
 - Updated eemi return payload type to be u32 instead of le32 and Eemi ops in 
FW driver will be updated to take care of endianess
 - Added Stephen's review tag
 
v5:
 - Added "Acked-by: Olof Johansson " for patches
 
v4:
 - Fixed minor review comments received for v3 patchset
 
v3:
 - Added check to pass only valid ioctls for ioctl eemi api
 - Added eemi documentation including ioctl details

Jolly Shah (1):
  drivers: clk: Add ZynqMP clock driver

Rajan Vaja (3):
  Documentation: xilinx: Add documentation for eemi APIs
  firmware: xilinx: Add zynqmp IOCTL API for device control
  dt-bindings: clock: Add bindings for ZynqMP clock driver

 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  53 ++
 Documentation/xilinx/eemi.txt  |  67 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/zynqmp/Kconfig |  10 +
 drivers/clk/zynqmp/Makefile|   4 +
 drivers/clk/zynqmp/clk-gate-zynqmp.c   | 144 +
 drivers/clk/zynqmp/clk-mux-zynqmp.c| 141 
 drivers/clk/zynqmp/clk-zynqmp.h|  68 ++
 drivers/clk/zynqmp/clkc.c  | 716 +
 drivers/clk/zynqmp/divider.c   | 217 +++
 drivers/clk/zynqmp/pll.c   | 335 ++
 drivers/firmware/xilinx/zynqmp.c   |  42 ++
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 
 include/linux/firmware/xlnx-zynqmp.h   |   5 +-
 15 files changed, 1919 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/xilinx/eemi.txt
 create mode 100644 drivers/clk/zynqmp/Kconfig
 create mode 100644 drivers/clk/zynqmp/Makefile
 create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
 create mode 100644 drivers/clk/zynqmp/clkc.c
 create mode 100644 drivers/clk/zynqmp/divider.c
 create mode 100644 drivers/clk/zynqmp/pll.c
 create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h

-- 
2.7.4



[PATCH v6 3/4] dt-bindings: clock: Add bindings for ZynqMP clock driver

2018-10-08 Thread Jolly Shah
From: Rajan Vaja 

Add documentation to describe Xilinx ZynqMP clock driver
bindings.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  53 ++
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 +
 2 files changed, 169 insertions(+)
 create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h

diff --git 
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt 
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 1b431d9..614bac5 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -17,6 +17,53 @@ Required properties:
  - "smc" : SMC #0, following the SMCCC
  - "hvc" : HVC #0, following the SMCCC
 
+--
+Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
+Zynq MPSoC firmware interface
+--
+The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
+tree. It reads required input clock frequencies from the devicetree and acts
+as clock provider for all clock consumers of PS clocks.
+
+See clock_bindings.txt for more information on the generic clock bindings.
+
+Required properties:
+ - #clock-cells:   Must be 1
+ - compatible: Must contain:   "xlnx,zynqmp-clk"
+ - clocks: List of clock specifiers which are external input
+   clocks to the given clock controller. Please refer
+   the next section to find the input clocks for a
+   given controller.
+ - clock-names:List of clock names which are exteral input 
clocks
+   to the given clock controller. Please refer to the
+   clock bindings for more details.
+
+Input clocks for zynqmp Ultrascale+ clock controller:
+
+The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
+inputs. These required clock inputs are:
+ - pss_ref_clk (PS reference clock)
+ - video_clk (reference clock for video system )
+ - pss_alt_ref_clk (alternative PS reference clock)
+ - aux_ref_clk
+ - gt_crx_ref_clk (transceiver reference clock)
+
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source:
+ - swdt0_ext_clk
+ - swdt1_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - gem2_emio_clk
+ - gem3_emio_clk
+ - mio_clk_XX  # with XX = 00..77
+ - mio_clk_50_or_51#for the mux clock to gem tsu from 50 or 51
+
+
+Output clocks are registered based on clock information received
+from firmware. Output clocks indexes are mentioned in
+include/dt-bindings/clock/xlnx,zynqmp-clk.h.
+
 ---
 Example
 ---
@@ -25,5 +72,11 @@ firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
+   zynqmp_clk: clock-controller {
+   #clock-cells = <1>;
+   compatible = "xlnx,zynqmp-clk";
+   clocks = <_ref_clk>, <_clk>, 
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
+   clock-names = "pss_ref_clk", "video_clk", 
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
+   };
};
 };
diff --git a/include/dt-bindings/clock/xlnx,zynqmp-clk.h 
b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
new file mode 100644
index 000..4aebe6e
--- /dev/null
+++ b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ *  Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ */
+
+#ifndef _DT_BINDINGS_CLK_ZYNQMP_H
+#define _DT_BINDINGS_CLK_ZYNQMP_H
+
+#define IOPLL  0
+#define RPLL   1
+#define APLL   2
+#define DPLL   3
+#define VPLL   4
+#define IOPLL_TO_FPD   5
+#define RPLL_TO_FPD6
+#define APLL_TO_LPD7
+#define DPLL_TO_LPD8
+#define VPLL_TO_LPD9
+#define ACPU   10
+#define ACPU_HALF  11
+#define DBF_FPD12
+#define DBF_LPD13
+#define DBG_TRACE  14
+#define DBG_TSTMP  15
+#define DP_VIDEO_REF   16
+#define DP_AUDIO_REF   17
+#define DP_STC_REF 18
+#define GDMA_REF   19
+#define DPDMA_REF  20
+#define DDR_REF21
+#define SATA_REF   22
+

[PATCH v6 0/4] drivers: clk: Add ZynqMP clock driver support

2018-10-08 Thread Jolly Shah
This patchset adds CCF compliant clock driver for ZynqMP.Clock driver queries 
supported clock information from firmware and regiters pll and output clocks 
with CCF.

This patch series is earlier reveiwed as part of FW patchset 
(https://patchwork.kernel.org/cover/10555405/). 
FW driver from that patchset is merged. This patchset contains only clock 
driver and is based on top of 
xilinx firmware patch set available in below tree:
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=next/drivers

v6:
 - Updated eemi return payload type to be u32 instead of le32 and Eemi ops in 
FW driver will be updated to take care of endianess
 - Added Stephen's review tag
 
v5:
 - Added "Acked-by: Olof Johansson " for patches
 
v4:
 - Fixed minor review comments received for v3 patchset
 
v3:
 - Added check to pass only valid ioctls for ioctl eemi api
 - Added eemi documentation including ioctl details

Jolly Shah (1):
  drivers: clk: Add ZynqMP clock driver

Rajan Vaja (3):
  Documentation: xilinx: Add documentation for eemi APIs
  firmware: xilinx: Add zynqmp IOCTL API for device control
  dt-bindings: clock: Add bindings for ZynqMP clock driver

 .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  53 ++
 Documentation/xilinx/eemi.txt  |  67 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/zynqmp/Kconfig |  10 +
 drivers/clk/zynqmp/Makefile|   4 +
 drivers/clk/zynqmp/clk-gate-zynqmp.c   | 144 +
 drivers/clk/zynqmp/clk-mux-zynqmp.c| 141 
 drivers/clk/zynqmp/clk-zynqmp.h|  68 ++
 drivers/clk/zynqmp/clkc.c  | 716 +
 drivers/clk/zynqmp/divider.c   | 217 +++
 drivers/clk/zynqmp/pll.c   | 335 ++
 drivers/firmware/xilinx/zynqmp.c   |  42 ++
 include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 
 include/linux/firmware/xlnx-zynqmp.h   |   5 +-
 15 files changed, 1919 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/xilinx/eemi.txt
 create mode 100644 drivers/clk/zynqmp/Kconfig
 create mode 100644 drivers/clk/zynqmp/Makefile
 create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
 create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
 create mode 100644 drivers/clk/zynqmp/clkc.c
 create mode 100644 drivers/clk/zynqmp/divider.c
 create mode 100644 drivers/clk/zynqmp/pll.c
 create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h

-- 
2.7.4



RE: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power domain bindings

2018-10-04 Thread Jolly Shah
Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, September 25, 2018 9:15 AM
> To: Jolly Shah 
> Cc: Matthias Brugger ; Andy Gross
> ; Shawn Guo ; Geert
> Uytterhoeven ; Bjorn Andersson
> ; Sean Wang ;
> Marek Szyprowski ; Michal Simek
> ; Mark Rutland ; Rajan Vaja
> ; devicet...@vger.kernel.org; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE  ker...@lists.infradead.org>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power domain
> bindings
> 
> On Thu, Sep 13, 2018 at 12:51 PM Jolly Shah  wrote:
> >
> > Hi Rob,
> >
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: Monday, August 20, 2018 12:46 PM
> > > To: Jolly Shah 
> > > Cc: matthias@gmail.com; andy.gr...@linaro.org;
> > > shawn...@kernel.org;
> > > geert+rene...@glider.be; bjorn.anders...@linaro.org;
> > > sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> > > ; mark.rutl...@arm.com; Rajan Vaja
> > > ; devicet...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Rajan Vaja
> > > ; Jolly Shah 
> > > Subject: Re: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power
> > > domain bindings
> > >
> > > On Thu, Aug 16, 2018 at 12:21:42PM -0700, Jolly Shah wrote:
> > > > From: Rajan Vaja 
> > > >
> > > > Add documentation to describe ZynqMP power domain bindings.
> > > >
> > > > Signed-off-by: Rajan Vaja 
> > > > Signed-off-by: Jolly Shah 
> > > > ---
> > > >  .../firmware/xilinx/xlnx,zynqmp-firmware.txt   | 47
> > > ++
> > >
> > > This should be with all the other power domain bindings.
> > >
> > > >  1 file changed, 47 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > index d215d15..5fa10a0 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqm
> > > > +++ p-fi
> > > > +++ rmware.txt
> > > > @@ -64,6 +64,29 @@ Output clocks are registered based on clock
> > > > information received  from firmware. Output clocks indexes are
> > > > mentioned in  include/dt-bindings/clock/xlnx,zynqmp-clk.h.
> > > >
> > > > +---
> > > > +Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
> > > > +---
> > > > +The binding for zynqmp-power-controller follow the common generic
> > > > +PM domain binding[1].
> > > > +
> > > > +[1] Documentation/devicetree/bindings/power/power_domain.txt
> > > > +
> > > > +== Zynq MPSoC Generic PM Domain Node ==
> > > > +
> > > > +Required properties:
> > > > + - compatible: Must be: "xlnx,zynqmp-power-controller"
> > > > +
> > > > +This node contains a number of subnodes, each representing a
> > > > +single PM domain that PM domain consumer devices reference.
> > > > +
> > > > +== PM Domain Nodes ==
> > > > +
> > > > +Required properties:
> > > > + - #power-domain-cells:Number of cells in a PM domain specifier. 
> > > > Must
> > > be 0.
> > > > + - pd-id:  Domain identifier as defined by platform firmware.
> > > > +   This identifier is passed to the PM firmware.
> > >
> > > Make this a cell for the power domain consumer.
> > [Jolly] We have more than one Ids for GPU device. Also they don't have
> > parent child relationship and hence are defined as flat hierarchy.
> > (shown in example below)
> 
> Then the gpu node should have:
> 
> power-domains = < 58  20  21>;
> 
> Also, for this and the firmware reset binding, there is no reason that I see 
> to
> make these all subnodes. A single firmware node can be a provider of multiple
> functions. You only need child nodes if the sub-functions have their own
> resources (clks, irqs, etc.). IOW, don't create nodes just because you want to
> instantiate drivers that way. DT is not the only way to instantiate devices 
> for
> drivers.
> 

Got it. Pushed v3 with suggested changes. Please review.

> Rob


RE: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power domain bindings

2018-10-04 Thread Jolly Shah
Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, September 25, 2018 9:15 AM
> To: Jolly Shah 
> Cc: Matthias Brugger ; Andy Gross
> ; Shawn Guo ; Geert
> Uytterhoeven ; Bjorn Andersson
> ; Sean Wang ;
> Marek Szyprowski ; Michal Simek
> ; Mark Rutland ; Rajan Vaja
> ; devicet...@vger.kernel.org; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE  ker...@lists.infradead.org>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power domain
> bindings
> 
> On Thu, Sep 13, 2018 at 12:51 PM Jolly Shah  wrote:
> >
> > Hi Rob,
> >
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: Monday, August 20, 2018 12:46 PM
> > > To: Jolly Shah 
> > > Cc: matthias@gmail.com; andy.gr...@linaro.org;
> > > shawn...@kernel.org;
> > > geert+rene...@glider.be; bjorn.anders...@linaro.org;
> > > sean.w...@mediatek.com; m.szyprow...@samsung.com; Michal Simek
> > > ; mark.rutl...@arm.com; Rajan Vaja
> > > ; devicet...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Rajan Vaja
> > > ; Jolly Shah 
> > > Subject: Re: [PATCH v2 1/3] dt-bindings: power: Add ZynqMP power
> > > domain bindings
> > >
> > > On Thu, Aug 16, 2018 at 12:21:42PM -0700, Jolly Shah wrote:
> > > > From: Rajan Vaja 
> > > >
> > > > Add documentation to describe ZynqMP power domain bindings.
> > > >
> > > > Signed-off-by: Rajan Vaja 
> > > > Signed-off-by: Jolly Shah 
> > > > ---
> > > >  .../firmware/xilinx/xlnx,zynqmp-firmware.txt   | 47
> > > ++
> > >
> > > This should be with all the other power domain bindings.
> > >
> > > >  1 file changed, 47 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > index d215d15..5fa10a0 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > > > rmwa
> > > > re.txt
> > > > +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqm
> > > > +++ p-fi
> > > > +++ rmware.txt
> > > > @@ -64,6 +64,29 @@ Output clocks are registered based on clock
> > > > information received  from firmware. Output clocks indexes are
> > > > mentioned in  include/dt-bindings/clock/xlnx,zynqmp-clk.h.
> > > >
> > > > +---
> > > > +Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
> > > > +---
> > > > +The binding for zynqmp-power-controller follow the common generic
> > > > +PM domain binding[1].
> > > > +
> > > > +[1] Documentation/devicetree/bindings/power/power_domain.txt
> > > > +
> > > > +== Zynq MPSoC Generic PM Domain Node ==
> > > > +
> > > > +Required properties:
> > > > + - compatible: Must be: "xlnx,zynqmp-power-controller"
> > > > +
> > > > +This node contains a number of subnodes, each representing a
> > > > +single PM domain that PM domain consumer devices reference.
> > > > +
> > > > +== PM Domain Nodes ==
> > > > +
> > > > +Required properties:
> > > > + - #power-domain-cells:Number of cells in a PM domain specifier. 
> > > > Must
> > > be 0.
> > > > + - pd-id:  Domain identifier as defined by platform firmware.
> > > > +   This identifier is passed to the PM firmware.
> > >
> > > Make this a cell for the power domain consumer.
> > [Jolly] We have more than one Ids for GPU device. Also they don't have
> > parent child relationship and hence are defined as flat hierarchy.
> > (shown in example below)
> 
> Then the gpu node should have:
> 
> power-domains = < 58  20  21>;
> 
> Also, for this and the firmware reset binding, there is no reason that I see 
> to
> make these all subnodes. A single firmware node can be a provider of multiple
> functions. You only need child nodes if the sub-functions have their own
> resources (clks, irqs, etc.). IOW, don't create nodes just because you want to
> instantiate drivers that way. DT is not the only way to instantiate devices 
> for
> drivers.
> 

Got it. Pushed v3 with suggested changes. Please review.

> Rob


[PATCH v3 2/4] firmware: xilinx: Add APIs to control node status/power

2018-10-04 Thread Jolly Shah
From: Rajan Vaja 

Add Xilinx ZynqMP firmware APIs to control node status
and power. These APIs allows turning on/off power domain
and setting capabilities of devices present in power domain.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 58 
 include/linux/firmware/xlnx-zynqmp.h | 26 
 2 files changed, 84 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 9a1c72a..faf6a52 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -469,6 +469,61 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 
arg1, u32 arg2,
   arg1, arg2, out);
 }
 
+/**
+ * zynqmp_pm_request_node() - Request a node with specific capabilities
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This function is used by master to request particular node from firmware.
+ * Every master must request node before using it.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_request_node(const u32 node, const u32 capabilities,
+ const u32 qos,
+ const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_REQUEST_NODE, node, capabilities,
+  qos, ack, NULL);
+}
+
+/**
+ * zynqmp_pm_release_node() - Release a node
+ * @node:  Node ID of the slave
+ *
+ * This function is used by master to inform firmware that master
+ * has released node. Once released, master must not use that node
+ * without re-request.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_release_node(const u32 node)
+{
+   return zynqmp_pm_invoke_fn(PM_RELEASE_NODE, node, 0, 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This API function is to be used for slaves a PU already has requested
+ * to change its capabilities.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_set_requirement(const u32 node, const u32 capabilities,
+const u32 qos,
+const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_SET_REQUIREMENT, node, capabilities,
+  qos, ack, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -482,6 +537,9 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
.ioctl = zynqmp_pm_ioctl,
+   .request_node = zynqmp_pm_request_node,
+   .release_node = zynqmp_pm_release_node,
+   .set_requirement = zynqmp_pm_set_requirement,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 3c3c28e..6998f7d 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -32,8 +32,19 @@
 /* Number of 32bits values in payload */
 #define PAYLOAD_ARG_CNT4U
 
+#define ZYNQMP_PM_MAX_QOS  100U
+
+/* Node capabilities */
+#defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
+#defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
+#defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+#defineZYNQMP_PM_CAPABILITY_POWER  0x8U
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_REQUEST_NODE = 13,
+   PM_RELEASE_NODE,
+   PM_SET_REQUIREMENT,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -75,6 +86,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
 };
 
+enum zynqmp_pm_request_ack {
+   ZYNQMP_PM_REQUEST_ACK_NO = 1,
+   ZYNQMP_PM_REQUEST_ACK_BLOCKING,
+   ZYNQMP_PM_REQUEST_ACK_NON_BLOCKING,
+};
+
 /**
  * struct zynqmp_pm_query_data - PM query data
  * @qid:   query ID
@@ -102,6 +119,15 @@ struct zynqmp_eemi_ops {
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
+   int (*request_node)(const u32 node,
+   const u32 capabilities,
+   const u32 qos,
+   const enum zynqmp_pm_request_ack ack);
+   int

[PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power domain driver

2018-10-04 Thread Jolly Shah
The zynqmp power domain driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

This patch series is based on top of Xilinx firmware patch set:
https://patchwork.kernel.org/cover/10555405/

v3:
 - Changed binding to have FW node as a power controller as suggested by Rob
 - Updated FW driver to register it as mfd child devices from firmware probe
 - Move bindings location as suggested

v2:
 - Rebased on top of latest firmware driver patch series
 - Updated driver name from zynqmp-genpd to zynqmp-power-controller
 - Updated device tree bindings to move power controller node under firmware 
node

Jolly Shah (1):
  drivers: soc: xilinx: Add ZynqMP power domain driver

Rajan Vaja (3):
  dt-bindings: power: Add ZynqMP power domain bindings
  firmware: xilinx: Add APIs to control node status/power
  firmware: xilinx: Add node IDs for zynqmp firmware

 .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 ++
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  73 
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   2 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 403 +
 include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 ++
 include/linux/firmware/xlnx-zynqmp.h   |  98 +
 8 files changed, 659 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

-- 
2.7.4



[PATCH v3 2/4] firmware: xilinx: Add APIs to control node status/power

2018-10-04 Thread Jolly Shah
From: Rajan Vaja 

Add Xilinx ZynqMP firmware APIs to control node status
and power. These APIs allows turning on/off power domain
and setting capabilities of devices present in power domain.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/zynqmp.c | 58 
 include/linux/firmware/xlnx-zynqmp.h | 26 
 2 files changed, 84 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 9a1c72a..faf6a52 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -469,6 +469,61 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 
arg1, u32 arg2,
   arg1, arg2, out);
 }
 
+/**
+ * zynqmp_pm_request_node() - Request a node with specific capabilities
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This function is used by master to request particular node from firmware.
+ * Every master must request node before using it.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_request_node(const u32 node, const u32 capabilities,
+ const u32 qos,
+ const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_REQUEST_NODE, node, capabilities,
+  qos, ack, NULL);
+}
+
+/**
+ * zynqmp_pm_release_node() - Release a node
+ * @node:  Node ID of the slave
+ *
+ * This function is used by master to inform firmware that master
+ * has released node. Once released, master must not use that node
+ * without re-request.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_release_node(const u32 node)
+{
+   return zynqmp_pm_invoke_fn(PM_RELEASE_NODE, node, 0, 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
+ * @node:  Node ID of the slave
+ * @capabilities:  Requested capabilities of the slave
+ * @qos:   Quality of service (not supported)
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * This API function is to be used for slaves a PU already has requested
+ * to change its capabilities.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_set_requirement(const u32 node, const u32 capabilities,
+const u32 qos,
+const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_SET_REQUIREMENT, node, capabilities,
+  qos, ack, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -482,6 +537,9 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
.ioctl = zynqmp_pm_ioctl,
+   .request_node = zynqmp_pm_request_node,
+   .release_node = zynqmp_pm_release_node,
+   .set_requirement = zynqmp_pm_set_requirement,
 };
 
 /**
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 3c3c28e..6998f7d 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -32,8 +32,19 @@
 /* Number of 32bits values in payload */
 #define PAYLOAD_ARG_CNT4U
 
+#define ZYNQMP_PM_MAX_QOS  100U
+
+/* Node capabilities */
+#defineZYNQMP_PM_CAPABILITY_ACCESS 0x1U
+#defineZYNQMP_PM_CAPABILITY_CONTEXT0x2U
+#defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
+#defineZYNQMP_PM_CAPABILITY_POWER  0x8U
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_REQUEST_NODE = 13,
+   PM_RELEASE_NODE,
+   PM_SET_REQUIREMENT,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -75,6 +86,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
 };
 
+enum zynqmp_pm_request_ack {
+   ZYNQMP_PM_REQUEST_ACK_NO = 1,
+   ZYNQMP_PM_REQUEST_ACK_BLOCKING,
+   ZYNQMP_PM_REQUEST_ACK_NON_BLOCKING,
+};
+
 /**
  * struct zynqmp_pm_query_data - PM query data
  * @qid:   query ID
@@ -102,6 +119,15 @@ struct zynqmp_eemi_ops {
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
+   int (*request_node)(const u32 node,
+   const u32 capabilities,
+   const u32 qos,
+   const enum zynqmp_pm_request_ack ack);
+   int

[PATCH v3 0/4] drivers: soc: xilinx: Add support for ZynqMP power domain driver

2018-10-04 Thread Jolly Shah
The zynqmp power domain driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

This patch series is based on top of Xilinx firmware patch set:
https://patchwork.kernel.org/cover/10555405/

v3:
 - Changed binding to have FW node as a power controller as suggested by Rob
 - Updated FW driver to register it as mfd child devices from firmware probe
 - Move bindings location as suggested

v2:
 - Rebased on top of latest firmware driver patch series
 - Updated driver name from zynqmp-genpd to zynqmp-power-controller
 - Updated device tree bindings to move power controller node under firmware 
node

Jolly Shah (1):
  drivers: soc: xilinx: Add ZynqMP power domain driver

Rajan Vaja (3):
  dt-bindings: power: Add ZynqMP power domain bindings
  firmware: xilinx: Add APIs to control node status/power
  firmware: xilinx: Add node IDs for zynqmp firmware

 .../bindings/power/xlnx,zynqmp-genpd.txt   |  34 ++
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  73 
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   2 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 403 +
 include/dt-bindings/power/xlnx-zynqmp-power.h  |  39 ++
 include/linux/firmware/xlnx-zynqmp.h   |  98 +
 8 files changed, 659 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c
 create mode 100644 include/dt-bindings/power/xlnx-zynqmp-power.h

-- 
2.7.4



[PATCH v3 4/4] drivers: soc: xilinx: Add ZynqMP power domain driver

2018-10-04 Thread Jolly Shah
From: Jolly Shah 

The zynqmp-genpd driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  15 ++
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   2 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 403 +
 5 files changed, 430 insertions(+)
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c

diff --git a/drivers/firmware/xilinx/Kconfig b/drivers/firmware/xilinx/Kconfig
index 8f44b9c..bd33bbf 100644
--- a/drivers/firmware/xilinx/Kconfig
+++ b/drivers/firmware/xilinx/Kconfig
@@ -6,6 +6,7 @@ menu "Zynq MPSoC Firmware Drivers"
 
 config ZYNQMP_FIRMWARE
bool "Enable Xilinx Zynq MPSoC firmware interface"
+   select MFD_CORE
help
  Firmware interface driver is used by different
  drivers to communicate with the firmware for
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index faf6a52..6b365df 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,12 @@
 #include 
 #include "zynqmp-debug.h"
 
+static const struct mfd_cell firmware_devs[] = {
+   {
+   .name = "zynqmp_power_controller",
+   },
+};
+
 /**
  * zynqmp_pm_ret_code() - Convert PMU-FW error codes to Linux error codes
  * @ret_status:PMUFW return code
@@ -596,11 +603,19 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
 
zynqmp_pm_api_debugfs_init();
 
+   ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, firmware_devs,
+ ARRAY_SIZE(firmware_devs), NULL, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "failed to add MFD devices %d\n", ret);
+   return ret;
+   }
+
return of_platform_populate(dev->of_node, NULL, NULL, dev);
 }
 
 static int zynqmp_firmware_remove(struct platform_device *pdev)
 {
+   mfd_remove_devices(>dev);
zynqmp_pm_api_debugfs_exit();
 
return 0;
diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index 687c8f3..81a345e 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -17,4 +17,13 @@ config XILINX_VCU
  To compile this driver as a module, choose M here: the
  module will be called xlnx_vcu.
 
+config ZYNQMP_PM_DOMAINS
+   bool "Enable Zynq MPSoC generic PM domains"
+   default y
+   depends on PM && ARCH_ZYNQMP && ZYNQMP_FIRMWARE
+   select PM_GENERIC_DOMAINS
+   help
+ Say yes to enable device power management through PM domains
+ If in doubt, say N.
+
 endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index dee8fd5..f468d1b 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1,2 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
+
+obj-$(CONFIG_ZYNQMP_PM_DOMAINS) += zynqmp_pm_domains.o
diff --git a/drivers/soc/xilinx/zynqmp_pm_domains.c 
b/drivers/soc/xilinx/zynqmp_pm_domains.c
new file mode 100644
index 000..999fe67
--- /dev/null
+++ b/drivers/soc/xilinx/zynqmp_pm_domains.c
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Generic PM domain support
+ *
+ *  Copyright (C) 2015-2018 Xilinx, Inc.
+ *
+ *  Davorin Mista 
+ *  Jolly Shah 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Flag stating if PM nodes mapped to the PM domain has been requested */
+#define ZYNQMP_PM_DOMAIN_REQUESTED BIT(0)
+
+/**
+ * struct zynqmp_pm_domain - Wrapper around struct generic_pm_domain
+ * @gpd:   Generic power domain
+ * @dev_list:  List of devices belong to power domain
+ * @node_ids:  PM node IDs corresponding to device(s) inside PM domain
+ * @node_id_num:   Number of PM node IDs
+ * @flags: ZynqMP PM domain flags
+ */
+struct zynqmp_pm_domain {
+   struct generic_pm_domain gpd;
+   struct list_head dev_list;
+   const u32 *node_ids;
+   int node_id_num;
+   u8 flags;
+};
+
+/*
+ * struct zynqmp_domain_device - Device node present in power domain
+ * @dev:   Device
+ * :  List member for the devices in domain list
+ */
+struct zynqmp_domain_device {
+   struct device *dev;
+   struct list_head list;
+};
+
+/*
+ * struct zynqmp_pd_info - PM domain info
+ * @id:Number of PM node IDs
+ * @ids:   PM node IDs corresponding to device(s) inside PM domain
+ * @name:   

[PATCH v3 3/4] firmware: xilinx: Add node IDs for zynqmp firmware

2018-10-04 Thread Jolly Shah
From: Rajan Vaja 

Xilinx ZynqMP firmware has different node IDs for different
peripherals. Add node IDs which can be used by any driver.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 include/linux/firmware/xlnx-zynqmp.h | 72 
 1 file changed, 72 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6998f7d..14bb780 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -40,6 +40,78 @@
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
 #defineZYNQMP_PM_CAPABILITY_POWER  0x8U
 
+/* Node IDs */
+#define NODE_UNKNOWN0
+#define NODE_APU1
+#define NODE_APU_0  2
+#define NODE_APU_1  3
+#define NODE_APU_2  4
+#define NODE_APU_3  5
+#define NODE_RPU6
+#define NODE_RPU_0  7
+#define NODE_RPU_1  8
+#define NODE_PLD9
+#define NODE_FPD10
+#define NODE_OCM_BANK_0 11
+#define NODE_OCM_BANK_1 12
+#define NODE_OCM_BANK_2 13
+#define NODE_OCM_BANK_3 14
+#define NODE_TCM_0_A15
+#define NODE_TCM_0_B16
+#define NODE_TCM_1_A17
+#define NODE_TCM_1_B18
+#define NODE_L2 19
+#define NODE_GPU_PP_0   20
+#define NODE_GPU_PP_1   21
+#define NODE_USB_0  22
+#define NODE_USB_1  23
+#define NODE_TTC_0  24
+#define NODE_TTC_1  25
+#define NODE_TTC_2  26
+#define NODE_TTC_3  27
+#define NODE_SATA   28
+#define NODE_ETH_0  29
+#define NODE_ETH_1  30
+#define NODE_ETH_2  31
+#define NODE_ETH_3  32
+#define NODE_UART_0 33
+#define NODE_UART_1 34
+#define NODE_SPI_0  35
+#define NODE_SPI_1  36
+#define NODE_I2C_0  37
+#define NODE_I2C_1  38
+#define NODE_SD_0   39
+#define NODE_SD_1   40
+#define NODE_DP 41
+#define NODE_GDMA   42
+#define NODE_ADMA   43
+#define NODE_NAND   44
+#define NODE_QSPI   45
+#define NODE_GPIO   46
+#define NODE_CAN_0  47
+#define NODE_CAN_1  48
+#define NODE_EXTERN 49
+#define NODE_APLL   50
+#define NODE_VPLL   51
+#define NODE_DPLL   52
+#define NODE_RPLL   53
+#define NODE_IOPLL  54
+#define NODE_DDR55
+#define NODE_IPI_APU56
+#define NODE_IPI_RPU_0  57
+#define NODE_GPU58
+#define NODE_PCIE   59
+#define NODE_PCAP   60
+#define NODE_RTC61
+#define NODE_LPD62
+#define NODE_VCU63
+#define NODE_IPI_RPU_1  64
+#define NODE_IPI_PL_0   65
+#define NODE_IPI_PL_1   66
+#define NODE_IPI_PL_2   67
+#define NODE_IPI_PL_3   68
+#define NODE_PL 69
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
PM_REQUEST_NODE = 13,
-- 
2.7.4



[PATCH v3 4/4] drivers: soc: xilinx: Add ZynqMP power domain driver

2018-10-04 Thread Jolly Shah
From: Jolly Shah 

The zynqmp-genpd driver communicates the usage requirements
for logical power domains / devices to the platform FW.
FW is responsible for choosing appropriate power states,
taking Linux' usage information into account.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 drivers/firmware/xilinx/Kconfig|   1 +
 drivers/firmware/xilinx/zynqmp.c   |  15 ++
 drivers/soc/xilinx/Kconfig |   9 +
 drivers/soc/xilinx/Makefile|   2 +
 drivers/soc/xilinx/zynqmp_pm_domains.c | 403 +
 5 files changed, 430 insertions(+)
 create mode 100644 drivers/soc/xilinx/zynqmp_pm_domains.c

diff --git a/drivers/firmware/xilinx/Kconfig b/drivers/firmware/xilinx/Kconfig
index 8f44b9c..bd33bbf 100644
--- a/drivers/firmware/xilinx/Kconfig
+++ b/drivers/firmware/xilinx/Kconfig
@@ -6,6 +6,7 @@ menu "Zynq MPSoC Firmware Drivers"
 
 config ZYNQMP_FIRMWARE
bool "Enable Xilinx Zynq MPSoC firmware interface"
+   select MFD_CORE
help
  Firmware interface driver is used by different
  drivers to communicate with the firmware for
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index faf6a52..6b365df 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,6 +24,12 @@
 #include 
 #include "zynqmp-debug.h"
 
+static const struct mfd_cell firmware_devs[] = {
+   {
+   .name = "zynqmp_power_controller",
+   },
+};
+
 /**
  * zynqmp_pm_ret_code() - Convert PMU-FW error codes to Linux error codes
  * @ret_status:PMUFW return code
@@ -596,11 +603,19 @@ static int zynqmp_firmware_probe(struct platform_device 
*pdev)
 
zynqmp_pm_api_debugfs_init();
 
+   ret = mfd_add_devices(>dev, PLATFORM_DEVID_NONE, firmware_devs,
+ ARRAY_SIZE(firmware_devs), NULL, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "failed to add MFD devices %d\n", ret);
+   return ret;
+   }
+
return of_platform_populate(dev->of_node, NULL, NULL, dev);
 }
 
 static int zynqmp_firmware_remove(struct platform_device *pdev)
 {
+   mfd_remove_devices(>dev);
zynqmp_pm_api_debugfs_exit();
 
return 0;
diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
index 687c8f3..81a345e 100644
--- a/drivers/soc/xilinx/Kconfig
+++ b/drivers/soc/xilinx/Kconfig
@@ -17,4 +17,13 @@ config XILINX_VCU
  To compile this driver as a module, choose M here: the
  module will be called xlnx_vcu.
 
+config ZYNQMP_PM_DOMAINS
+   bool "Enable Zynq MPSoC generic PM domains"
+   default y
+   depends on PM && ARCH_ZYNQMP && ZYNQMP_FIRMWARE
+   select PM_GENERIC_DOMAINS
+   help
+ Say yes to enable device power management through PM domains
+ If in doubt, say N.
+
 endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
index dee8fd5..f468d1b 100644
--- a/drivers/soc/xilinx/Makefile
+++ b/drivers/soc/xilinx/Makefile
@@ -1,2 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_XILINX_VCU)   += xlnx_vcu.o
+
+obj-$(CONFIG_ZYNQMP_PM_DOMAINS) += zynqmp_pm_domains.o
diff --git a/drivers/soc/xilinx/zynqmp_pm_domains.c 
b/drivers/soc/xilinx/zynqmp_pm_domains.c
new file mode 100644
index 000..999fe67
--- /dev/null
+++ b/drivers/soc/xilinx/zynqmp_pm_domains.c
@@ -0,0 +1,403 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Generic PM domain support
+ *
+ *  Copyright (C) 2015-2018 Xilinx, Inc.
+ *
+ *  Davorin Mista 
+ *  Jolly Shah 
+ *  Rajan Vaja 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Flag stating if PM nodes mapped to the PM domain has been requested */
+#define ZYNQMP_PM_DOMAIN_REQUESTED BIT(0)
+
+/**
+ * struct zynqmp_pm_domain - Wrapper around struct generic_pm_domain
+ * @gpd:   Generic power domain
+ * @dev_list:  List of devices belong to power domain
+ * @node_ids:  PM node IDs corresponding to device(s) inside PM domain
+ * @node_id_num:   Number of PM node IDs
+ * @flags: ZynqMP PM domain flags
+ */
+struct zynqmp_pm_domain {
+   struct generic_pm_domain gpd;
+   struct list_head dev_list;
+   const u32 *node_ids;
+   int node_id_num;
+   u8 flags;
+};
+
+/*
+ * struct zynqmp_domain_device - Device node present in power domain
+ * @dev:   Device
+ * :  List member for the devices in domain list
+ */
+struct zynqmp_domain_device {
+   struct device *dev;
+   struct list_head list;
+};
+
+/*
+ * struct zynqmp_pd_info - PM domain info
+ * @id:Number of PM node IDs
+ * @ids:   PM node IDs corresponding to device(s) inside PM domain
+ * @name:   

[PATCH v3 3/4] firmware: xilinx: Add node IDs for zynqmp firmware

2018-10-04 Thread Jolly Shah
From: Rajan Vaja 

Xilinx ZynqMP firmware has different node IDs for different
peripherals. Add node IDs which can be used by any driver.

Signed-off-by: Rajan Vaja 
Signed-off-by: Jolly Shah 
---
 include/linux/firmware/xlnx-zynqmp.h | 72 
 1 file changed, 72 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6998f7d..14bb780 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -40,6 +40,78 @@
 #defineZYNQMP_PM_CAPABILITY_WAKEUP 0x4U
 #defineZYNQMP_PM_CAPABILITY_POWER  0x8U
 
+/* Node IDs */
+#define NODE_UNKNOWN0
+#define NODE_APU1
+#define NODE_APU_0  2
+#define NODE_APU_1  3
+#define NODE_APU_2  4
+#define NODE_APU_3  5
+#define NODE_RPU6
+#define NODE_RPU_0  7
+#define NODE_RPU_1  8
+#define NODE_PLD9
+#define NODE_FPD10
+#define NODE_OCM_BANK_0 11
+#define NODE_OCM_BANK_1 12
+#define NODE_OCM_BANK_2 13
+#define NODE_OCM_BANK_3 14
+#define NODE_TCM_0_A15
+#define NODE_TCM_0_B16
+#define NODE_TCM_1_A17
+#define NODE_TCM_1_B18
+#define NODE_L2 19
+#define NODE_GPU_PP_0   20
+#define NODE_GPU_PP_1   21
+#define NODE_USB_0  22
+#define NODE_USB_1  23
+#define NODE_TTC_0  24
+#define NODE_TTC_1  25
+#define NODE_TTC_2  26
+#define NODE_TTC_3  27
+#define NODE_SATA   28
+#define NODE_ETH_0  29
+#define NODE_ETH_1  30
+#define NODE_ETH_2  31
+#define NODE_ETH_3  32
+#define NODE_UART_0 33
+#define NODE_UART_1 34
+#define NODE_SPI_0  35
+#define NODE_SPI_1  36
+#define NODE_I2C_0  37
+#define NODE_I2C_1  38
+#define NODE_SD_0   39
+#define NODE_SD_1   40
+#define NODE_DP 41
+#define NODE_GDMA   42
+#define NODE_ADMA   43
+#define NODE_NAND   44
+#define NODE_QSPI   45
+#define NODE_GPIO   46
+#define NODE_CAN_0  47
+#define NODE_CAN_1  48
+#define NODE_EXTERN 49
+#define NODE_APLL   50
+#define NODE_VPLL   51
+#define NODE_DPLL   52
+#define NODE_RPLL   53
+#define NODE_IOPLL  54
+#define NODE_DDR55
+#define NODE_IPI_APU56
+#define NODE_IPI_RPU_0  57
+#define NODE_GPU58
+#define NODE_PCIE   59
+#define NODE_PCAP   60
+#define NODE_RTC61
+#define NODE_LPD62
+#define NODE_VCU63
+#define NODE_IPI_RPU_1  64
+#define NODE_IPI_PL_0   65
+#define NODE_IPI_PL_1   66
+#define NODE_IPI_PL_2   67
+#define NODE_IPI_PL_3   68
+#define NODE_PL 69
+
 enum pm_api_id {
PM_GET_API_VERSION = 1,
PM_REQUEST_NODE = 13,
-- 
2.7.4



  1   2   3   4   5   6   >