Date   

Re: Request for Camera CSI support for IMX

Lakshmi Natarajan <lakshmi.natarajan@...>
 

Hello Jan,

Thanks for the details. This gives us an idea on what we could do next.
Thanks for your immediate support. We will get in touch with NXP for this.

Regards,
Lakshmi


On Wed, Oct 21, 2020 at 4:27 PM Jan Kiszka <jan.kiszka@...> wrote:
Hi Lakshmi,

On 21.10.20 11:50, Lakshmi Natarajan wrote:
> Hello Jan,
>
> This is regarding requests for CSI support in the IMX processor.
> We were using Yocto + NXP provided kernel to use the CSI peripheral of
> the IMX6 processor. We have complete support from NXP for their kernel
> along with the Yocto framework.
> We want to move to CIP 4.19 + ISAR framework.
> When we checked CIP kernel 4.19 - there was no support for CSI interface
> as well as there were some differences in the arch support too.
> After study of the NXP provided framework, we found that they use the
> kernel from https://source.codeaurora.org/external/imx/linux-imxand
> commit ID 0f9917c56d5995e1dc3bde5658e2d7bc865464de.
> Even linux kernel 5.9 doesn't have the imx specific support.

That's unfortunate.

> Can you guide us on how we should proceed with the same - will it be
> possible for CIP to add IMX support (or) should we request NXP to add
> the patch for CIP kernel 4.19

Yes, please reach out to NXP and ask what their answer for upstream is,
today or at least for the future. It's their issue in the first place.
Also for that, you should prepare with naming the kernel interfaces or
drivers you need in more details.

If NXP cannot or do not want to answer this appropriately, plan B) will
be identifying the patches they provide on top of the upstream kernel,
optimally 4.19. Those patches then needs to be applied on top of the CIP
kernel but, as they are unfortunately downstream only, you will then
have to maintain them for your product and can't propose them for the
CIP kernel.

Best regards,
Jan

>
> Regards,
> Lakshmi
>
>
> On Tue, Oct 20, 2020 at 5:48 PM Rajashree Sankar
> <rajashree.sankar@... <mailto:rajashree.sankar@...>> wrote:
>
>     Hello Jan,
>     We have used Yocto Framework provided by NXP from the following link
>     <https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/evaluation-kit-for-the-i-mx-6ull-and-6ulz-applications-processor:MCIMX6ULL-EVK?fpsp=1#documentsandsoftware>.Refer
>     to the Document
>
>
>           L4.19.35_1.1.0_LINUX_DOCS
>           <https://www.nxp.com/webapp/Download?colCode=L4.19.35_1.1.0_LINUX_DOCS>
>           in the above mentioned link.
>
>     The DT-bindings and the IMX Camera capture information will be
>     available by following the steps mentioned in the document
>     i.MX_Yocto_Project_User's_Guide from the above link.
>     The Kernel which we are using is fetched from the bitbake files
>     attached below( linux-yocto_4.19.bb <http://linux-yocto_4.19.bb> and
>     its append).Could you please let us know whether CSI  Camera capture
>     supported in this kernel be included in the Linux CIP?
>
>     Thanks and Regards,
>     Rajashree Sankar
>
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for
> use by the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended recipient
> of this e-mail message, you are hereby notified that any dissemination,
> distribution or copying of this e-mail message, and any attachments
> thereto, is strictly prohibited. If you have received this e-mail
> message in error, please immediately notify the sender and permanently
> delete the original and any copies of this email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS
> NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
> Electronic Transactions Act or the applicability of any other law of
> similar substance and effect, absent an express statement to the
> contrary hereinabove, this e-mail message its contents, and any
> attachments hereto are not intended to represent an offer or acceptance
> to enter into a contract and are not otherwise intended to bind the
> sender, Sanmina Corporation (or any of its subsidiaries), or any other
> person or entity.

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.


Re: Request for Camera CSI support for IMX

Jan Kiszka
 

Hi Lakshmi,

On 21.10.20 11:50, Lakshmi Natarajan wrote:
Hello Jan,
This is regarding requests for CSI support in the IMX processor.
We were using Yocto + NXP provided kernel to use the CSI peripheral of the IMX6 processor. We have complete support from NXP for their kernel along with the Yocto framework.
We want to move to CIP 4.19 + ISAR framework.
When we checked CIP kernel 4.19 - there was no support for CSI interface as well as there were some differences in the arch support too.
After study of the NXP provided framework, we found that they use the kernel from https://source.codeaurora.org/external/imx/linux-imxand commit ID 0f9917c56d5995e1dc3bde5658e2d7bc865464de.
Even linux kernel 5.9 doesn't have the imx specific support.
That's unfortunate.

Can you guide us on how we should proceed with the same - will it be possible for CIP to add IMX support (or) should we request NXP to add the patch for CIP kernel 4.19
Yes, please reach out to NXP and ask what their answer for upstream is, today or at least for the future. It's their issue in the first place. Also for that, you should prepare with naming the kernel interfaces or drivers you need in more details.

If NXP cannot or do not want to answer this appropriately, plan B) will be identifying the patches they provide on top of the upstream kernel, optimally 4.19. Those patches then needs to be applied on top of the CIP kernel but, as they are unfortunately downstream only, you will then have to maintain them for your product and can't propose them for the CIP kernel.

Best regards,
Jan

Regards,
Lakshmi
On Tue, Oct 20, 2020 at 5:48 PM Rajashree Sankar <rajashree.sankar@... <mailto:rajashree.sankar@...>> wrote:
Hello Jan,
We have used Yocto Framework provided by NXP from the following link
<https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/evaluation-kit-for-the-i-mx-6ull-and-6ulz-applications-processor:MCIMX6ULL-EVK?fpsp=1#documentsandsoftware>.Refer
to the Document
L4.19.35_1.1.0_LINUX_DOCS
<https://www.nxp.com/webapp/Download?colCode=L4.19.35_1.1.0_LINUX_DOCS> in the above mentioned link.
The DT-bindings and the IMX Camera capture information will be
available by following the steps mentioned in the document
i.MX_Yocto_Project_User's_Guide from the above link.
The Kernel which we are using is fetched from the bitbake files
attached below( linux-yocto_4.19.bb <http://linux-yocto_4.19.bb> and
its append).Could you please let us know whether CSI  Camera capture
supported in this kernel be included in the Linux CIP?
Thanks and Regards,
Rajashree Sankar
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: Request for Camera CSI support for IMX

Lakshmi Natarajan <lakshmi.natarajan@...>
 

Hello Jan,

This is regarding requests for CSI support in the IMX processor.
We were using Yocto + NXP provided kernel to use the CSI peripheral of the IMX6 processor. We have complete support from NXP for their kernel along with the Yocto framework.
We want to move to CIP 4.19 + ISAR framework.
When we checked CIP kernel 4.19 - there was no support for CSI interface as well as there were some differences in the arch support too.
After study of the NXP provided framework, we found that they use the kernel from https://source.codeaurora.org/external/imx/linux-imx and commit ID 0f9917c56d5995e1dc3bde5658e2d7bc865464de.
Even linux kernel 5.9 doesn't have the imx specific support.
Can you guide us on how we should proceed with the same - will it be possible for CIP to add IMX support (or) should we request NXP to add the patch for CIP kernel 4.19

Regards,
Lakshmi


On Tue, Oct 20, 2020 at 5:48 PM Rajashree Sankar <rajashree.sankar@...> wrote:
Hello Jan,
We have used Yocto Framework provided by NXP from the following link.Refer to the Document 

L4.19.35_1.1.0_LINUX_DOCS  in the above mentioned link.

The DT-bindings and the IMX Camera capture information will be available by following the steps mentioned in the document i.MX_Yocto_Project_User's_Guide from the above link.
The Kernel which we are using is fetched from the bitbake files attached below( linux-yocto_4.19.bb and its append).Could you please let us know whether CSI  Camera capture supported in this kernel be included in the Linux CIP?

Thanks and Regards,
Rajashree Sankar


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 20 October 2020 21:48
To: cip-dev@...
Cc: Pavel Machek <pavel@...>; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Biju Das <biju.das.jz@...>
Subject: Re: [cip-dev] If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3
and RZ/G2x

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC
version or shall we wait for couple of days more ?
I guess I'd like non-RFC version of patches 1-22 in a series. I
believe it makes sense to add 30, 32, 49, 50 to them, as they are
simple and fix a bug.

Would that work for you?
Sure ill get on posting the above mentioned patches as non-RFC in a series.

How do we tackle with rest of the patches ?
Well... I applied this batch. If someone can explain the mutex
vs. spinlock thing, then I guess we can do next batch up to 35...
Thank you for queuing in the patches.

I have replied on patch 24/50 to add my two cents.

OTOH I did not go through those patches in detail, and RFC is good
enough for review, so... maybe you can just wait.
Sure will wait.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [RFC PATCH 4.19.y-cip 24/50] PCI: endpoint: Replace spinlock with mutex

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 20 October 2020 21:44
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [RFC PATCH 4.19.y-cip 24/50] PCI: endpoint: Replace spinlock with mutex

Hi!

commit 3d3248dbd018502f654064c78efcd2e165ab3486 upstream.

The pci_epc_ops is not intended to be invoked from interrupt context.
Hence replace spin_lock_irqsave and spin_unlock_irqrestore with
mutex_lock and mutex_unlock respectively.
Could I get some kind of explanation why this is good idea?
Apart of one mentioned above other point I would add is on a single core machine mutex_lock/unlock would be good choice.

Also to add the callbacks in controller driver might sleep. For example in raise_irq callback [1], [2].

As long as code protected by the locks does not sleep, spinlocks are
okay... (but they should not need "_irqsave" variants).

They are likely to have better performance, too, when protected code
is small and fast.
I do agree with the above two points *if the code isn't sleeping*.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tree/drivers/pci/controller/pcie-rockchip-ep.c?h=linux-4.19.y-cip#n410
[2] https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tree/drivers/pci/controller/pcie-cadence-ep.c?h=linux-4.19.y-cip#n310

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 00/26] Fixes and extension to PCIe EPF

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 20 October 2020 21:41
To: cip-dev@...
Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das <biju.das.jz@...>;
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Subject: Re: [cip-dev] [PATCH 4.19.y-cip 00/26] Fixes and extension to PCIe EPF

Hi!

This patch series is part of RFC series [1] ("Add PCIe EP support for
Renesas R-Car Gen3 and RZ/G2x"). For making it more cleaner and easier
to review series [1] is split up as suggested by Pavel, patches 1-22,
30, 32, 49, 50 are included in this set from [1].
Thanks, applied and pushed out.
Thank you.

Cheers,
Prabhakar

Our automated testing did not find anything wrong (but I don't think
that means much).

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Pavel Machek
 

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC
version or shall we wait for couple of days more ?
I guess I'd like non-RFC version of patches 1-22 in a series. I
believe it makes sense to add 30, 32, 49, 50 to them, as they are
simple and fix a bug.

Would that work for you?
Sure ill get on posting the above mentioned patches as non-RFC in a series.

How do we tackle with rest of the patches ?
Well... I applied this batch. If someone can explain the mutex
vs. spinlock thing, then I guess we can do next batch up to 35...

OTOH I did not go through those patches in detail, and RFC is good
enough for review, so... maybe you can just wait.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [RFC PATCH 4.19.y-cip 24/50] PCI: endpoint: Replace spinlock with mutex

Pavel Machek
 

Hi!

commit 3d3248dbd018502f654064c78efcd2e165ab3486 upstream.

The pci_epc_ops is not intended to be invoked from interrupt context.
Hence replace spin_lock_irqsave and spin_unlock_irqrestore with
mutex_lock and mutex_unlock respectively.
Could I get some kind of explanation why this is good idea?

As long as code protected by the locks does not sleep, spinlocks are
okay... (but they should not need "_irqsave" variants).

They are likely to have better performance, too, when protected code
is small and fast.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 00/26] Fixes and extension to PCIe EPF

Pavel Machek
 

Hi!

This patch series is part of RFC series [1] ("Add PCIe EP support for
Renesas R-Car Gen3 and RZ/G2x"). For making it more cleaner and easier
to review series [1] is split up as suggested by Pavel, patches 1-22,
30, 32, 49, 50 are included in this set from [1].
Thanks, applied and pushed out.

Our automated testing did not find anything wrong (but I don't think
that means much).

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[PATCH 4.19.y-cip 26/26] tools: PCI: Fix fd leakage

Lad Prabhakar
 

From: Hewenliang <hewenliang4@...>

commit 3c379a59b4795d7279d38c623e74b9790345a32b upstream.

We should close fd before the return of run_test.

Fixes: 3f2ed8134834 ("tools: PCI: Add a userspace tool to test PCI endpoint")
Signed-off-by: Hewenliang <hewenliang4@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
tools/pci/pcitest.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index b7e3b6a64956..9f3d2e584ce4 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -140,6 +140,7 @@ static int run_test(struct pci_test *test)
}

fflush(stdout);
+ close(fd);
return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */
}

--
2.17.1


[PATCH 4.19.y-cip 25/26] tools: PCI: Exit with error code when test fails

Lad Prabhakar
 

From: Jean-Jacques Hiblot <jjhiblot@...>

commit b71f0a0b1e3fea212a6a5042ced8b48a81738ac9 upstream.

This makes it easier to use pcitest in automated setups.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
tools/pci/pcitest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index 4c5be77c211f..b7e3b6a64956 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -140,6 +140,7 @@ static int run_test(struct pci_test *test)
}

fflush(stdout);
+ return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */
}

int main(int argc, char **argv)
@@ -228,6 +229,5 @@ int main(int argc, char **argv)
return -EINVAL;
}

- run_test(test);
- return 0;
+ return run_test(test);
}
--
2.17.1


[PATCH 4.19.y-cip 24/26] PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table address

Lad Prabhakar
 

From: Kishon Vijay Abraham I <kishon@...>

commit 6f5e193bfb55963ce5f4f68cc927f371ddb0913b upstream.

commit beb4641a787d ("PCI: dwc: Add MSI-X callbacks handler"),
in order to raise MSI-X interrupt, obtained MSIX table address from
Base Address Register (BAR). However BAR only holds PCI address
programmed by the host whereas the MSI-X table should be in the local
memory.

Store the MSI-X table address (virtual address) as part of ->set_bar()
callback and use that to get the message address and message data
here.

Fixes: beb4641a787d ("PCI: dwc: Add MSI-X callbacks handler")
Signed-off-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
[PL: Dropped changes to designware driver]
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/pci-epf-core.c | 2 ++
include/linux/pci-epf.h | 15 +++++++++++++++
2 files changed, 17 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index fb1306de8f40..93ebe916949e 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -99,6 +99,7 @@ void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar)
epf->bar[bar].phys_addr);

epf->bar[bar].phys_addr = 0;
+ epf->bar[bar].addr = NULL;
epf->bar[bar].size = 0;
epf->bar[bar].barno = 0;
epf->bar[bar].flags = 0;
@@ -135,6 +136,7 @@ void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar,
}

epf->bar[bar].phys_addr = phys_addr;
+ epf->bar[bar].addr = space;
epf->bar[bar].size = size;
epf->bar[bar].barno = bar;
epf->bar[bar].flags |= upper_32_bits(size) ?
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 2d6f07556682..bc5ce7afd79a 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -92,10 +92,12 @@ struct pci_epf_driver {
/**
* struct pci_epf_bar - represents the BAR of EPF device
* @phys_addr: physical address that should be mapped to the BAR
+ * @addr: virtual address corresponding to the @phys_addr
* @size: the size of the address space present in BAR
*/
struct pci_epf_bar {
dma_addr_t phys_addr;
+ void *addr;
size_t size;
enum pci_barno barno;
int flags;
@@ -127,6 +129,19 @@ struct pci_epf {
struct list_head list;
};

+/**
+ * struct pci_epf_msix_tbl - represents the MSIX table entry structure
+ * @msg_addr: Writes to this address will trigger MSIX interrupt in host
+ * @msg_data: Data that should be written to @msg_addr to trigger MSIX interrupt
+ * @vector_ctrl: Identifies if the function is prohibited from sending a message
+ * using this MSIX table entry
+ */
+struct pci_epf_msix_tbl {
+ u64 msg_addr;
+ u32 msg_data;
+ u32 vector_ctrl;
+};
+
#define to_pci_epf(epf_dev) container_of((epf_dev), struct pci_epf, dev)

#define pci_epf_register_driver(driver) \
--
2.17.1


[PATCH 4.19.y-cip 23/26] PCI: endpoint: Fix clearing start entry in configfs

Lad Prabhakar
 

From: Kunihiko Hayashi <hayashi.kunihiko@...>

commit f58d5f53c89479c12ad719c1960176442add5aaa upstream.

After an endpoint is started through configfs, if 0 is written to the
configfs entry 'start', the controller stops but the epc_group->start
value remains 1.

A subsequent unlinking of the function from the controller would trigger
a spurious WARN_ON_ONCE() in pci_epc_epf_unlink() despite right
behavior.

Fix it by setting epc_group->start = 0 when a controller is stopped
using configfs.

Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Cc: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/pci-ep-cfs.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c
index d1288a0bd530..4fead88257bb 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -58,6 +58,7 @@ static ssize_t pci_epc_start_store(struct config_item *item, const char *page,

if (!start) {
pci_epc_stop(epc);
+ epc_group->start = 0;
return len;
}

--
2.17.1


[PATCH 4.19.y-cip 22/26] PCI: endpoint: Cast the page number to phys_addr_t

Lad Prabhakar
 

From: Alan Mikhak <alan.mikhak@...>

commit daee4f4e42c792997f4fee47dcdfa65dd720ec02 upstream.

Modify pci_epc_mem_alloc_addr() to cast the variable 'pageno'
from type 'int' to 'phys_addr_t' before shifting left. This
cast is needed to avoid treating bit 31 of 'pageno' as the
sign bit which would otherwise get sign-extended to produce
a negative value. When added to the base address of PCI memory
space, the negative value would produce an invalid physical
address which falls before the start of the PCI memory space.

Signed-off-by: Alan Mikhak <alan.mikhak@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/pci-epc-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-epc-mem.c b/drivers/pci/endpoint/pci-epc-mem.c
index 0471643cf536..abfac1109a13 100644
--- a/drivers/pci/endpoint/pci-epc-mem.c
+++ b/drivers/pci/endpoint/pci-epc-mem.c
@@ -136,7 +136,7 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
if (pageno < 0)
goto ret;

- *phys_addr = mem->phys_base + (pageno << page_shift);
+ *phys_addr = mem->phys_base + ((phys_addr_t)pageno << page_shift);
virt_addr = ioremap(*phys_addr, size);
if (!virt_addr)
bitmap_release_region(mem->bitmap, pageno, order);
--
2.17.1


[PATCH 4.19.y-cip 21/26] PCI: endpoint: Clear BAR before freeing its space

Lad Prabhakar
 

From: Alan Mikhak <alan.mikhak@...>

commit dbb7bbcc8ad248b1ab05bd27dfdb587ef4023dab upstream.

Associated pci_epf_bar structure is needed in pci_epc_clear_bar() to
clear a BAR correctly but it is reset in pci_epf_free_space() (that
is called first) which results in pci_epc_clear_bar() failure.

Reorder the pci_epc_clear_bar()/pci_epf_free_space() calls execution
to fix the issue.

Signed-off-by: Alan Mikhak <alan.mikhak@...>
[lorenzo.pieralisi@...: reworded the commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index e8bcc924dbf8..1cfe3687a211 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -381,8 +381,8 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
epf_bar = &epf->bar[bar];

if (epf_test->reg[bar]) {
- pci_epf_free_space(epf, epf_test->reg[bar], bar);
pci_epc_clear_bar(epc, epf->func_no, epf_bar);
+ pci_epf_free_space(epf, epf_test->reg[bar], bar);
}
}
}
--
2.17.1


[PATCH 4.19.y-cip 20/26] PCI: endpoint: Skip odd BAR when skipping 64bit BAR

Lad Prabhakar
 

From: Alan Mikhak <alan.mikhak@...>

commit 3041a643613a2530ade35a9ae97709a9da4c0c72 upstream.

Always skip odd BAR when skipping 64bit BARs in pci_epf_test_set_bar()
and pci_epf_test_alloc_space() otherwise pci_epf_test_set_bar() will
call pci_epc_set_bar() on an odd loop index when skipping reserved 64bit
BAR.

Moreover, pci_epf_test_alloc_space() will call pci_epf_alloc_space() on
bind for an odd loop index when BAR is 64bit but leaks on subsequent
unbind by not calling pci_epf_free_space().

Signed-off-by: Alan Mikhak <alan.mikhak@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Reviewed-by: Paul Walmsley <paul.walmsley@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 25 +++++++++----------
1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 7d41e6684b87..e8bcc924dbf8 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -389,7 +389,7 @@ static void pci_epf_test_unbind(struct pci_epf *epf)

static int pci_epf_test_set_bar(struct pci_epf *epf)
{
- int bar;
+ int bar, add;
int ret;
struct pci_epf_bar *epf_bar;
struct pci_epc *epc = epf->epc;
@@ -400,8 +400,14 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)

epc_features = epf_test->epc_features;

- for (bar = BAR_0; bar <= BAR_5; bar++) {
+ for (bar = BAR_0; bar <= BAR_5; bar += add) {
epf_bar = &epf->bar[bar];
+ /*
+ * pci_epc_set_bar() sets PCI_BASE_ADDRESS_MEM_TYPE_64
+ * if the specific implementation required a 64-bit BAR,
+ * even if we only requested a 32-bit BAR.
+ */
+ add = (epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ? 2 : 1;

if (!!(epc_features->reserved_bar & (1 << bar)))
continue;
@@ -413,13 +419,6 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
if (bar == test_reg_bar)
return ret;
}
- /*
- * pci_epc_set_bar() sets PCI_BASE_ADDRESS_MEM_TYPE_64
- * if the specific implementation required a 64-bit BAR,
- * even if we only requested a 32-bit BAR.
- */
- if (epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
- bar++;
}

return 0;
@@ -431,7 +430,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
struct device *dev = &epf->dev;
struct pci_epf_bar *epf_bar;
void *base;
- int bar;
+ int bar, add;
enum pci_barno test_reg_bar = epf_test->test_reg_bar;
const struct pci_epc_features *epc_features;
size_t test_reg_size;
@@ -451,8 +450,10 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
}
epf_test->reg[test_reg_bar] = base;

- for (bar = BAR_0; bar <= BAR_5; bar++) {
+ for (bar = BAR_0; bar <= BAR_5; bar += add) {
epf_bar = &epf->bar[bar];
+ add = (epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ? 2 : 1;
+
if (bar == test_reg_bar)
continue;

@@ -465,8 +466,6 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
dev_err(dev, "Failed to allocate space for BAR%d\n",
bar);
epf_test->reg[bar] = base;
- if (epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
- bar++;
}

return 0;
--
2.17.1


[PATCH 4.19.y-cip 19/26] PCI: endpoint: Allocate enough space for fixed size BAR

Lad Prabhakar
 

From: Alan Mikhak <alan.mikhak@...>

commit f16fb16ed16c7f561e9c41c9ae4107c7f6aa553c upstream.

PCI endpoint test function code should honor the .bar_fixed_size parameter
from underlying endpoint controller drivers or results may be unexpected.

In pci_epf_test_alloc_space(), check if BAR being used for test
register space is a fixed size BAR. If so, allocate the required fixed
size.

Signed-off-by: Alan Mikhak <alan.mikhak@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 27806987e93b..7d41e6684b87 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -434,10 +434,16 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
int bar;
enum pci_barno test_reg_bar = epf_test->test_reg_bar;
const struct pci_epc_features *epc_features;
+ size_t test_reg_size;

epc_features = epf_test->epc_features;

- base = pci_epf_alloc_space(epf, sizeof(struct pci_epf_test_reg),
+ if (epc_features->bar_fixed_size[test_reg_bar])
+ test_reg_size = bar_size[test_reg_bar];
+ else
+ test_reg_size = sizeof(struct pci_epf_test_reg);
+
+ base = pci_epf_alloc_space(epf, test_reg_size,
test_reg_bar, epc_features->align);
if (!base) {
dev_err(dev, "Failed to allocated register space\n");
--
2.17.1


[PATCH 4.19.y-cip 18/26] PCI: endpoint: Set endpoint controller pointer to NULL

Lad Prabhakar
 

From: Alan Mikhak <alan.mikhak@...>

commit db7a62482d2f6a63f36f30f62c4cbf1e53035719 upstream.

Set endpoint controller pointer to NULL in pci_epc_remove_epf()
to avoid -EBUSY on subsequent call to pci_epc_add_epf().

Add a check for NULL endpoint function pointer.

Signed-off-by: Alan Mikhak <alan.mikhak@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Acked-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/pci-epc-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index e4712a0f249c..2091508c1620 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -519,11 +519,12 @@ void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf)
{
unsigned long flags;

- if (!epc || IS_ERR(epc))
+ if (!epc || IS_ERR(epc) || !epf)
return;

spin_lock_irqsave(&epc->lock, flags);
list_del(&epf->list);
+ epf->epc = NULL;
spin_unlock_irqrestore(&epc->lock, flags);
}
EXPORT_SYMBOL_GPL(pci_epc_remove_epf);
--
2.17.1


[PATCH 4.19.y-cip 17/26] PCI: endpoint: Add support to specify alignment for buffers allocated to BARs

Lad Prabhakar
 

From: Kishon Vijay Abraham I <kishon@...>

commit 2a9a801620efac92885fc9cd53594c0b9aba87a4 upstream.

The address that is allocated using pci_epf_alloc_space() is
directly written to the target address of the Inbound Address
Translation unit (ie the HW component implementing inbound address
decoding) on endpoint controllers.

Designware IP [1] has a configuration parameter (CX_ATU_MIN_REGION_SIZE
[2]) which has 64KB as default value and the lower 16 bits of the Base,
Limit and Target registers of the Inbound ATU are fixed to zero. If the
programmed memory address is not aligned to 64 KB boundary this causes
memory corruption.

Modify pci_epf_alloc_space() API to take alignment size as argument in
order to allocate buffers to be mapped to BARs with an alignment that
suits the platform where they are used.

Add an 'align' parameter to epc_features which can be used by platform
drivers to specify the BAR allocation alignment requirements and use
this while invoking pci_epf_alloc_space().

[1] "I/O and MEM Match Modes" section in DesignWare Cores PCI Express
Controller Databook version 4.90a
[2] http://www.ti.com/lit/ug/spruid7c/spruid7c.pdf

Signed-off-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 5 +++--
drivers/pci/endpoint/pci-epf-core.c | 10 ++++++++--
include/linux/pci-epc.h | 2 ++
include/linux/pci-epf.h | 3 ++-
4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index ed5cd28b9572..27806987e93b 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -438,7 +438,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
epc_features = epf_test->epc_features;

base = pci_epf_alloc_space(epf, sizeof(struct pci_epf_test_reg),
- test_reg_bar);
+ test_reg_bar, epc_features->align);
if (!base) {
dev_err(dev, "Failed to allocated register space\n");
return -ENOMEM;
@@ -453,7 +453,8 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
if (!!(epc_features->reserved_bar & (1 << bar)))
continue;

- base = pci_epf_alloc_space(epf, bar_size[bar], bar);
+ base = pci_epf_alloc_space(epf, bar_size[bar], bar,
+ epc_features->align);
if (!base)
dev_err(dev, "Failed to allocate space for BAR%d\n",
bar);
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index 8bfdcd291196..fb1306de8f40 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -109,10 +109,12 @@ EXPORT_SYMBOL_GPL(pci_epf_free_space);
* pci_epf_alloc_space() - allocate memory for the PCI EPF register space
* @size: the size of the memory that has to be allocated
* @bar: the BAR number corresponding to the allocated register space
+ * @align: alignment size for the allocation region
*
* Invoke to allocate memory for the PCI EPF register space.
*/
-void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar)
+void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar,
+ size_t align)
{
void *space;
struct device *dev = epf->epc->dev.parent;
@@ -120,7 +122,11 @@ void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar)

if (size < 128)
size = 128;
- size = roundup_pow_of_two(size);
+
+ if (align)
+ size = ALIGN(size, align);
+ else
+ size = roundup_pow_of_two(size);

space = dma_alloc_coherent(dev, size, &phys_addr, GFP_KERNEL);
if (!space) {
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index b3a3c0805603..0c12d69dde92 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -112,6 +112,7 @@ struct pci_epc {
* @reserved_bar: bitmap to indicate reserved BAR unavailable to function driver
* @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
* @bar_fixed_size: Array specifying the size supported by each BAR
+ * @align: alignment size required for BAR buffer allocation
*/
struct pci_epc_features {
unsigned int linkup_notifier : 1;
@@ -120,6 +121,7 @@ struct pci_epc_features {
u8 reserved_bar;
u8 bar_fixed_64bit;
u64 bar_fixed_size[BAR_5 + 1];
+ size_t align;
};

#define to_pci_epc(device) container_of((device), struct pci_epc, dev)
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index ec02f58758c8..2d6f07556682 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -149,7 +149,8 @@ void pci_epf_destroy(struct pci_epf *epf);
int __pci_epf_register_driver(struct pci_epf_driver *driver,
struct module *owner);
void pci_epf_unregister_driver(struct pci_epf_driver *driver);
-void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar);
+void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar,
+ size_t align);
void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar);
int pci_epf_bind(struct pci_epf *epf);
void pci_epf_unbind(struct pci_epf *epf);
--
2.17.1


[PATCH 4.19.y-cip 16/26] PCI: endpoint: Fix a potential NULL pointer dereference

Lad Prabhakar
 

From: Kangjie Lu <kjlu@...>

commit 507b820009a457afa78202da337bcb56791fbb12 upstream.

In case alloc_workqueue() fails, return -ENOMEM to avoid
potential NULL pointer dereferences.

Signed-off-by: Kangjie Lu <kjlu@...>
[lorenzo.pieralisi@...: commit log and code update]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index d0b91da49bf4..ed5cd28b9572 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -591,6 +591,11 @@ static int __init pci_epf_test_init(void)

kpcitest_workqueue = alloc_workqueue("kpcitest",
WQ_MEM_RECLAIM | WQ_HIGHPRI, 0);
+ if (!kpcitest_workqueue) {
+ pr_err("Failed to allocate the kpcitest work queue\n");
+ return -ENOMEM;
+ }
+
ret = pci_epf_register_driver(&test_driver);
if (ret) {
pr_err("Failed to register pci epf test driver --> %d\n", ret);
--
2.17.1

3521 - 3540 of 9152