[PATCH V2] PCI: Add ACS quirk for Ampere root ports

[Feng Kan]

The Ampere Computing PCIe root port does not support ACS at this point.
However, the hardware provides isolation and source validation through the
SMMU. The stream ID generated by the PCIe ports contain both the
bus/device/function number as well as the port ID in its 3 most significant
bits. Turn on ACS but disable all the peer-to-peer features.

Signed-off-by: Feng Kan 
---
 V2 - Correct patch summary as per Bjorn's comment

 This is a rebranding of APM to Ampere, it is a change of vendor id
 and device id, all functionality stays the same as before.

 drivers/pci/quirks.c| 9 +
 include/linux/pci_ids.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index fc73401..57748a3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4514,6 +4514,15 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
/* APM X-Gene */
{ PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
+   /* Ampere Computing */
+   { PCI_VENDOR_ID_AMPERE, 0xE005, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE006, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE007, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE008, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE009, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
{ 0 }
 };
 
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index a6b3066..c875d42 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1333,6 +1333,7 @@
 #define PCI_DEVICE_ID_IMS_TT3D 0x9135
 
 #define PCI_VENDOR_ID_AMCC 0x10e8
+#define PCI_VENDOR_ID_AMPERE   0x1def
 
 #define PCI_VENDOR_ID_INTERG   0x10ea
 #define PCI_DEVICE_ID_INTERG_1682  0x1682
-- 
2.7.4

[PATCH] pci: quirk: adding Ampere vendor id to ACS quirk list

[Feng Kan]

Adding Ampere Computing vendor id to the ACS quirk list.

Signed-off-by: Feng Kan 
---
 Tanmay is no longer with us. After the email system is rebranded
 to the new company. We will clean up the remaining legacy items.

 drivers/pci/quirks.c| 9 +
 include/linux/pci_ids.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 10684b1..45d9187 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4512,6 +4512,15 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
/* APM X-Gene */
{ PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
+   /* Ampere Computing */
+   { PCI_VENDOR_ID_AMPERE, 0xE005, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE006, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE007, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE008, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE009, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
+   { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
{ 0 }
 };
 
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5..c21d1f8 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1331,6 +1331,7 @@
 #define PCI_DEVICE_ID_IMS_TT3D 0x9135
 
 #define PCI_VENDOR_ID_AMCC 0x10e8
+#define PCI_VENDOR_ID_AMPERE   0x1def
 
 #define PCI_VENDOR_ID_INTERG   0x10ea
 #define PCI_DEVICE_ID_INTERG_1682  0x1682
-- 
2.7.4

Re: [PATCH v3 0/5] ACPI: DMA ranges management

[Feng Kan]

On Wed, Nov 29, 2017 at 11:28 PM, Feng Kan  wrote:
> On Thu, Aug 3, 2017 at 5:32 AM, Lorenzo Pieralisi
>  wrote:
>> This patch series is v3 of a previous posting:
>>
>> v2->v3:
>> - Fixed DMA masks computation
>> - Fixed size computation overflow in acpi_dma_get_range()
>>
>> v1->v2:
>> - Reworked acpi_dma_get_range() flow and logs
>> - Added IORT named component address limits
>> - Renamed acpi_dev_get_resources() helper function
>> - Rebased against v4.13-rc3
>>
>> v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieral...@arm.com
>> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>>
>> -- Original cover letter --
>>
>> As reported in:
>>
>> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@mail.gmail.com
>>
>> the bus connecting devices to an IOMMU bus can be smaller in size than
>> the IOMMU input address bits which results in devices DMA HW bugs in
>> particular related to IOVA allocation (ie chopping of higher address
>> bits owing to system bus HW capabilities mismatch with the IOMMU).
>>
>> Fortunately this problem can be solved through an already present but never
>> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
>> window for a specific bus in ACPI and therefore all upstream devices
>> connected to it.
>>
>> This small patch series enables _DMA parsing in ACPI core code and
>> use it in ACPI IORT code in order to detect DMA ranges for devices and
>> update their data structures to make them work with their related DMA
>> addressing restrictions.
>>
>> Cc: Will Deacon 
>> Cc: Hanjun Guo 
>> Cc: Feng Kan 
>> Cc: Jon Masters 
>> Cc: Robert Moore 
>> Cc: Robin Murphy 
>> Cc: Zhang Rui 
>> Cc: "Rafael J. Wysocki" 
>>
>> Lorenzo Pieralisi (5):
>>   ACPICA: resource_mgr: Allow _DMA method in walk resources
>>   ACPI: Make acpi_dev_get_resources() method agnostic
>>   ACPI: Introduce DMA ranges parsing
>>   ACPI: Make acpi_dma_configure() DMA regions aware
>>   ACPI/IORT: Add IORT named component memory address limits
>>
>>  drivers/acpi/acpica/rsxface.c |  7 ++--
>>  drivers/acpi/arm64/iort.c | 57 ++-
>>  drivers/acpi/resource.c   | 82 +-
>>  drivers/acpi/scan.c   | 91 
>> +++
>>  include/acpi/acnames.h|  1 +
>>  include/acpi/acpi_bus.h   |  2 +
>>  include/linux/acpi.h  |  8 
>>  include/linux/acpi_iort.h |  5 ++-
>>  8 files changed, 219 insertions(+), 34 deletions(-)
>>
>> --
>> 2.10.0
>>
> Lorenzo:
>
> A network driver can use pci_set_dma_mask or its like to override what
> is done with this patch here.
> Which would result in iova allocation greater than the original _DMA
> aperture. Should we force
> the dma_set_mask to not change if an existing mask is already set?

Let me clarify the question some more, in our system the IOMMU supports only
42 bits of address. With your _DMA aperture patch, the initial dma_mask and
coherent_mask are correctly set by the code. However, the device driver can
set the dma_mask and coherent mask at a later point which over writes the
initial setting by your code. In which case, once the iova is exhausted with the
32 bit address, it will start seeking more iova address via the
dma_limit. In this
case it would fail my system since the iommu.aperture_end is that of 48 bits
as derived from ias field in  the SMMU.

Should the dma_limit be the smallest of driver->dma_mask, iommu.aperture_end and
your _DMA aperture size via ACPI table? Rather than just the
driver->dma_mask and
iommu.aperture_end. This will ensure the smallest/correct aperture is used.

Re: [PATCH v3 0/5] ACPI: DMA ranges management

[Feng Kan]

On Thu, Aug 3, 2017 at 5:32 AM, Lorenzo Pieralisi
 wrote:
> This patch series is v3 of a previous posting:
>
> v2->v3:
> - Fixed DMA masks computation
> - Fixed size computation overflow in acpi_dma_get_range()
>
> v1->v2:
> - Reworked acpi_dma_get_range() flow and logs
> - Added IORT named component address limits
> - Renamed acpi_dev_get_resources() helper function
> - Rebased against v4.13-rc3
>
> v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@mail.gmail.com
>
> the bus connecting devices to an IOMMU bus can be smaller in size than
> the IOMMU input address bits which results in devices DMA HW bugs in
> particular related to IOVA allocation (ie chopping of higher address
> bits owing to system bus HW capabilities mismatch with the IOMMU).
>
> Fortunately this problem can be solved through an already present but never
> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> window for a specific bus in ACPI and therefore all upstream devices
> connected to it.
>
> This small patch series enables _DMA parsing in ACPI core code and
> use it in ACPI IORT code in order to detect DMA ranges for devices and
> update their data structures to make them work with their related DMA
> addressing restrictions.
>
> Cc: Will Deacon 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> Lorenzo Pieralisi (5):
>   ACPICA: resource_mgr: Allow _DMA method in walk resources
>   ACPI: Make acpi_dev_get_resources() method agnostic
>   ACPI: Introduce DMA ranges parsing
>   ACPI: Make acpi_dma_configure() DMA regions aware
>   ACPI/IORT: Add IORT named component memory address limits
>
>  drivers/acpi/acpica/rsxface.c |  7 ++--
>  drivers/acpi/arm64/iort.c | 57 ++-
>  drivers/acpi/resource.c   | 82 +-
>  drivers/acpi/scan.c   | 91 
> +++
>  include/acpi/acnames.h|  1 +
>  include/acpi/acpi_bus.h   |  2 +
>  include/linux/acpi.h  |  8 
>  include/linux/acpi_iort.h |  5 ++-
>  8 files changed, 219 insertions(+), 34 deletions(-)
>
> --
> 2.10.0
>
Lorenzo:

A network driver can use pci_set_dma_mask or its like to override what
is done with this patch here.
Which would result in iova allocation greater than the original _DMA
aperture. Should we force
the dma_set_mask to not change if an existing mask is already set?

[PATCH] iommu: enable bypass transaction caching for ARM SMMU 500

[Feng Kan]

The ARM SMMU identity mapping performance was poor compared with the
DMA mode. It was found that enable caching would restore the performance
back to normal. The S2CRB_TLBEN bit in the ACR register would allow for
caching of the stream to context register bypass transaction information.

Signed-off-by: Feng Kan 
---
 drivers/iommu/arm-smmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 3bdb799..b5676a8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -59,6 +59,7 @@
 #define ARM_MMU500_ACTLR_CPRE  (1 << 1)
 
 #define ARM_MMU500_ACR_CACHE_LOCK  (1 << 26)
+#define ARM_MMU500_ACR_S2CRB_TLBEN (1 << 10)
 #define ARM_MMU500_ACR_SMTNMB_TLBEN(1 << 8)
 
 #define TLB_LOOP_TIMEOUT   100 /* 1s! */
@@ -1606,7 +1607,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device 
*smmu)
 * Allow unmatched Stream IDs to allocate bypass
 * TLB entries for reduced latency.
 */
-   reg |= ARM_MMU500_ACR_SMTNMB_TLBEN;
+   reg |= ARM_MMU500_ACR_SMTNMB_TLBEN | ARM_MMU500_ACR_S2CRB_TLBEN;
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
}
 
-- 
2.7.4

Re: [PATCH v3 0/5] ACPI: DMA ranges management

[Feng Kan]

On Thu, Aug 3, 2017 at 5:32 AM, Lorenzo Pieralisi
 wrote:
> This patch series is v3 of a previous posting:
>
> v2->v3:
> - Fixed DMA masks computation
> - Fixed size computation overflow in acpi_dma_get_range()
>
> v1->v2:
> - Reworked acpi_dma_get_range() flow and logs
> - Added IORT named component address limits
> - Renamed acpi_dev_get_resources() helper function
> - Rebased against v4.13-rc3
>
> v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieral...@arm.com
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@mail.gmail.com
>
> the bus connecting devices to an IOMMU bus can be smaller in size than
> the IOMMU input address bits which results in devices DMA HW bugs in
> particular related to IOVA allocation (ie chopping of higher address
> bits owing to system bus HW capabilities mismatch with the IOMMU).
>
> Fortunately this problem can be solved through an already present but never
> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> window for a specific bus in ACPI and therefore all upstream devices
> connected to it.
>
> This small patch series enables _DMA parsing in ACPI core code and
> use it in ACPI IORT code in order to detect DMA ranges for devices and
> update their data structures to make them work with their related DMA
> addressing restrictions.
>
> Cc: Will Deacon 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> Lorenzo Pieralisi (5):
>   ACPICA: resource_mgr: Allow _DMA method in walk resources
>   ACPI: Make acpi_dev_get_resources() method agnostic
>   ACPI: Introduce DMA ranges parsing
>   ACPI: Make acpi_dma_configure() DMA regions aware
>   ACPI/IORT: Add IORT named component memory address limits
>
>  drivers/acpi/acpica/rsxface.c |  7 ++--
>  drivers/acpi/arm64/iort.c | 57 ++-
>  drivers/acpi/resource.c   | 82 +-
>  drivers/acpi/scan.c   | 91 
> +++
>  include/acpi/acnames.h|  1 +
>  include/acpi/acpi_bus.h   |  2 +
>  include/linux/acpi.h  |  8 
>  include/linux/acpi_iort.h |  5 ++-
>  8 files changed, 219 insertions(+), 34 deletions(-)
>
> --
> 2.10.0
>
Works on XGene.
Tested-by: Feng Kan 

Re: [PATCH V4] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

+ Adding Bjorn
Sorry for top post, we are looking to pull this into the latest REL7.4
release. Would like
the maintainer to take a look. Thanks

On Tue, Aug 1, 2017 at 4:15 PM, Alex Williamson
 wrote:
> On Tue,  1 Aug 2017 16:08:13 -0700
> Feng Kan  wrote:
>
>> The APM X-Gene PCIe root port does not support ACS at this point.
>> However, the hw provides isolation and source validation through
>> the SMMU. The stream ID generated by the PCIe ports contain both
>> the BDF as well as the port ID in its 3 most significant bits.
>> Turn on ACS but disable all the peer to peer features.
>>
>> Signed-off-by: Feng Kan 
>> ---
>>   V4 Change: Remove TB & TD flags from ACS mask
>> V3 Change: Add comment regarding unique port id in stream ID
>> V2 Change: Move XGene ACS quirk to unique XGene function
>>
>>  drivers/pci/quirks.c | 14 ++
>>  1 file changed, 14 insertions(+)
>
>
> Reviewed-by: Alex Williamson 
>
>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 085fb78..22343b3 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4120,6 +4120,18 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, 
>> u16 acs_flags)
>>   return acs_flags ? 0 : 1;
>>  }
>>
>> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> +{
>> + /*
>> +  * XGene root matching this quirk do not allow peer-to-peer
>> +  * transactions with others, allowing masking out these bits as if they
>> +  * were unimplemented in the ACS capability.
>> +  */
>> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
>> +
>> + return acs_flags ? 0 : 1;
>> +}
>> +
>>  /*
>>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>>   * transactions and validate bus numbers in requests, but do not provide an
>> @@ -4368,6 +4380,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> *dev, u16 acs_flags)
>>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>>   /* Cavium ThunderX */
>>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> + /* APM XGene */
>> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>>   { 0 }
>>  };
>>
>

[PATCH V4] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
However, the hw provides isolation and source validation through
the SMMU. The stream ID generated by the PCIe ports contain both
the BDF as well as the port ID in its 3 most significant bits.
Turn on ACS but disable all the peer to peer features.

Signed-off-by: Feng Kan 
---
V4 Change: Remove TB & TD flags from ACS mask
V3 Change: Add comment regarding unique port id in stream ID
V2 Change: Move XGene ACS quirk to unique XGene function

 drivers/pci/quirks.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..22343b3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4120,6 +4120,18 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 
acs_flags)
return acs_flags ? 0 : 1;
 }
 
+static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
+{
+   /*
+* XGene root matching this quirk do not allow peer-to-peer
+* transactions with others, allowing masking out these bits as if they
+* were unimplemented in the ACS capability.
+*/
+   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
+
+   return acs_flags ? 0 : 1;
+}
+
 /*
  * Many Intel PCH root ports do provide ACS-like features to disable peer
  * transactions and validate bus numbers in requests, but do not provide an
@@ -4368,6 +4380,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
{ 0 }
 };
 
-- 
1.8.3.1

Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamson
 wrote:
> On Mon, 31 Jul 2017 10:56:53 -0700
> Feng Kan  wrote:
>
>> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson
>>  wrote:
>> > On Fri, 28 Jul 2017 11:50:43 -0700
>> > Feng Kan  wrote:
>> >
>> >> The APM X-Gene PCIe root port does not support ACS at this point.
>> >> However, the hw provides isolation and source validation through
>> >> the SMMU. The stream ID generated by the PCIe ports contain both
>> >> the BDF as well as the port ID in its 3 most significant bits.
>> >> Turn on ACS but disable all the peer to peer features.
>> >>
>> >> Signed-off-by: Feng Kan 
>> >> ---
>> >>   V3 Change: Add comment regarding unique port id in stream ID
>> >>   V2 Change: Move XGene ACS quirk to unique XGene function
>> >>
>> >>  drivers/pci/quirks.c | 15 +++
>> >>  1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> index 085fb78..0f8f1cd 100644
>> >> --- a/drivers/pci/quirks.c
>> >> +++ b/drivers/pci/quirks.c
>> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   return acs_flags ? 0 : 1;
>> >>  }
>> >>
>> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> >> +{
>> >> + /*
>> >> +  * XGene root matching this quirk do not allow peer-to-peer
>> >> +  * transactions with others, allowing masking out these bits as if 
>> >> they
>> >> +  * were unimplemented in the ACS capability.
>> >> +  */
>> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> >> +
>> >> + return acs_flags ? 0 : 1;
>> >> +}
>> >> +
>> >>  /*
>> >>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>> >>   * transactions and validate bus numbers in requests, but do not provide 
>> >> an
>> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>> >>   /* Cavium ThunderX */
>> >>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> >> + /* APM XGene */
>> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>> >>   { 0 }
>> >>  };
>> >>
>> >
>> > Hi Feng,
>> >
>> > Sorry, I have one more question as I happened to spend some time
>> > looking at PCI_ACS_DT this week.  DT specifies that peer-to-peer should
>> > occur normally between egress ports for transactions which are
>> > pre-translated by an ATS unit on the endpoint.  Therefore if a root
>> > port doesn't allow peer-to-peer, it seems like it should not claim to
>> > support PCI_ACS_DT.  I know your quirk is just a copy of the Cavium
>> > one, but we should also go back and verify this question with them, or
>> > perhaps I'm misinterpreting this capability.  AIUI this is also a
>> > performance capability, not an isolation capability, so it shouldn't
>> > affect the ability to consider a device isolated, it only gets
>> > confusing if we expect a performance benefit from this but don't
>> > actually see one.  Does your root port have this ability to
>> > selectively allow peer-to-peer of pre-translated transactions?  Thanks,
>> We do not support peer to peer between root ports (each root port is a
>> root complex in itself).
>> Therefore, this bit set/unset has no effect.
>>
>> As one of our guys pointed out in PCIe 3.1a, it may help address your
>> concern above.
>>
>> """
>> Root Port indication of ACS Direct Translated P2P support does not imply any
>> particular level of peer-to-peer support by the Root Complex, or that
>> peer-to-peer traffic is supported at all.
>> """
>
> That's interesting, but is that referring to the ACS capability or the
> control?


I could imagine how advertising the capability would not
> imply any particular level of p2p, but enabling the control (which is
> what we're claiming via this quirk) the spec states:
>
> 

Re: [PATCH v2 0/5] ACPI: DMA ranges management

[Feng Kan]

On Mon, Jul 31, 2017 at 8:23 AM, Lorenzo Pieralisi
 wrote:
> This patch series is v2 of a previous posting:
>
> v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
>
> v1->v2:
> - Reworked acpi_dma_get_range() flow and logs
> - Added IORT named component address limits
> - Renamed acpi_dev_get_resources() helper function
> - Rebased against v4.13-rc3
>
> -- Original cover letter --
>
> As reported in:
>
> http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@mail.gmail.com
>
> the bus connecting devices to an IOMMU bus can be smaller in size than
> the IOMMU input address bits which results in devices DMA HW bugs in
> particular related to IOVA allocation (ie chopping of higher address
> bits owing to system bus HW capabilities mismatch with the IOMMU).
>
> Fortunately this problem can be solved through an already present but never
> used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> window for a specific bus in ACPI and therefore all upstream devices
> connected to it.
>
> This small patch series enables _DMA parsing in ACPI core code and
> use it in ACPI IORT code in order to detect DMA ranges for devices and
> update their data structures to make them work with their related DMA
> addressing restrictions.
>
> Cc: Will Deacon 
> Cc: Hanjun Guo 
> Cc: Feng Kan 
> Cc: Jon Masters 
> Cc: Robert Moore 
> Cc: Robin Murphy 
> Cc: Zhang Rui 
> Cc: "Rafael J. Wysocki" 
>
> Lorenzo Pieralisi (5):
>   ACPICA: resource_mgr: Allow _DMA method in walk resources
>   ACPI: Make acpi_dev_get_resources() method agnostic
>   ACPI: Introduce DMA ranges parsing
>   ACPI: Make acpi_dma_configure() DMA regions aware
>   ACPI/IORT: Add IORT named component memory address limits
>
>  drivers/acpi/acpica/rsxface.c |  7 ++--
>  drivers/acpi/arm64/iort.c | 50 +++-
>  drivers/acpi/resource.c   | 82 ++-
>  drivers/acpi/scan.c   | 90 
> +++
>  include/acpi/acnames.h|  1 +
>  include/acpi/acpi_bus.h   |  2 +
>  include/linux/acpi.h  |  8 
>  include/linux/acpi_iort.h |  5 ++-
>  8 files changed, 211 insertions(+), 34 deletions(-)
>
> --
> 2.10.0
>
Thanks, this was tested and works on the XGene system.
Tested-by: Feng Kan 

Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson
 wrote:
> On Fri, 28 Jul 2017 11:50:43 -0700
> Feng Kan  wrote:
>
>> The APM X-Gene PCIe root port does not support ACS at this point.
>> However, the hw provides isolation and source validation through
>> the SMMU. The stream ID generated by the PCIe ports contain both
>> the BDF as well as the port ID in its 3 most significant bits.
>> Turn on ACS but disable all the peer to peer features.
>>
>> Signed-off-by: Feng Kan 
>> ---
>>   V3 Change: Add comment regarding unique port id in stream ID
>>   V2 Change: Move XGene ACS quirk to unique XGene function
>>
>>  drivers/pci/quirks.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 085fb78..0f8f1cd 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, 
>> u16 acs_flags)
>>   return acs_flags ? 0 : 1;
>>  }
>>
>> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> +{
>> + /*
>> +  * XGene root matching this quirk do not allow peer-to-peer
>> +  * transactions with others, allowing masking out these bits as if they
>> +  * were unimplemented in the ACS capability.
>> +  */
>> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> +
>> + return acs_flags ? 0 : 1;
>> +}
>> +
>>  /*
>>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>>   * transactions and validate bus numbers in requests, but do not provide an
>> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> *dev, u16 acs_flags)
>>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>>   /* Cavium ThunderX */
>>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> + /* APM XGene */
>> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>>   { 0 }
>>  };
>>
>
> Hi Feng,
>
> Sorry, I have one more question as I happened to spend some time
> looking at PCI_ACS_DT this week.  DT specifies that peer-to-peer should
> occur normally between egress ports for transactions which are
> pre-translated by an ATS unit on the endpoint.  Therefore if a root
> port doesn't allow peer-to-peer, it seems like it should not claim to
> support PCI_ACS_DT.  I know your quirk is just a copy of the Cavium
> one, but we should also go back and verify this question with them, or
> perhaps I'm misinterpreting this capability.  AIUI this is also a
> performance capability, not an isolation capability, so it shouldn't
> affect the ability to consider a device isolated, it only gets
> confusing if we expect a performance benefit from this but don't
> actually see one.  Does your root port have this ability to
> selectively allow peer-to-peer of pre-translated transactions?  Thanks,
We do not support peer to peer between root ports (each root port is a
root complex in itself).
Therefore, this bit set/unset has no effect.

As one of our guys pointed out in PCIe 3.1a, it may help address your
concern above.

"""
Root Port indication of ACS Direct Translated P2P support does not imply any
particular level of peer-to-peer support by the Root Complex, or that
peer-to-peer traffic is supported at all.
"""
> Alex

[PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
However, the hw provides isolation and source validation through
the SMMU. The stream ID generated by the PCIe ports contain both
the BDF as well as the port ID in its 3 most significant bits.
Turn on ACS but disable all the peer to peer features.

Signed-off-by: Feng Kan 
---
V3 Change: Add comment regarding unique port id in stream ID
V2 Change: Move XGene ACS quirk to unique XGene function

 drivers/pci/quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..0f8f1cd 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 
acs_flags)
return acs_flags ? 0 : 1;
 }
 
+static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
+{
+   /*
+* XGene root matching this quirk do not allow peer-to-peer
+* transactions with others, allowing masking out these bits as if they
+* were unimplemented in the ACS capability.
+*/
+   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
+  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
+
+   return acs_flags ? 0 : 1;
+}
+
 /*
  * Many Intel PCH root ports do provide ACS-like features to disable peer
  * transactions and validate bus numbers in requests, but do not provide an
@@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
{ 0 }
 };
 
-- 
1.8.3.1

Re: [PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

On Sun, Jul 23, 2017 at 7:06 PM, Alex Williamson
 wrote:
> On Fri, 21 Jul 2017 13:20:18 -0700
> Feng Kan  wrote:
>
>> On Thu, Jul 20, 2017 at 3:22 PM, Alex Williamson
>>  wrote:
>> > On Wed, 19 Jul 2017 17:46:51 -0700
>> > Feng Kan  wrote:
>> >
>> >> The APM X-Gene PCIe root port does not support ACS at this point.
>> >> However, the hw provides isolation and source validation through
>> >> the SMMU. Turn on ACS but disable all the peer to peer features.
>> >>
>> >> Signed-off-by: Feng Kan 
>> >> ---
>> >>  drivers/pci/quirks.c | 15 +++
>> >>  1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> index 085fb78..0f8f1cd 100644
>> >> --- a/drivers/pci/quirks.c
>> >> +++ b/drivers/pci/quirks.c
>> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   return acs_flags ? 0 : 1;
>> >>  }
>> >>
>> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> >> +{
>> >> + /*
>> >> +  * XGene root matching this quirk do not allow peer-to-peer
>> >> +  * transactions with others, allowing masking out these bits as if 
>> >> they
>> >> +  * were unimplemented in the ACS capability.
>> >> +  */
>> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> >> +
>> >> + return acs_flags ? 0 : 1;
>> >> +}
>> >> +
>> >>  /*
>> >>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>> >>   * transactions and validate bus numbers in requests, but do not provide 
>> >> an
>> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>> >>   /* Cavium ThunderX */
>> >>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> >> + /* APM XGene */
>> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>> >>   { 0 }
>> >>  };
>> >>
>> >
>> > Sorry, I'm not yet convinced there's an equivalent of SV, if a device
>> > spoofs a different bdf and it reaches the smmu, what prevents that from
>> > simply referencing the context for that alternate bdf?
>> Perhaps I am not understanding the question correctly. The bdf forms a
>> stream id which is used to provide an context. Since there is no actual
>> context created by an alternate bdf, the transaction would be rejected
>> by the SMMU.
>
> Unless that context does exist.  Take for example a basic topology:
>
> -[:00]-+-00.0
>+-01.0-[01]00.0
>+-02.0-[02]00.0
>
> Assume 00:01.0 and 00:02.0 are root ports and 01:00.0 and 02:00.0 are
> their respective downstream endpoint.  A single iommu would typically
> handle both of these endpoints using the requester ID, aka stream ID, to
> reference the appropriate context.  Source validation at the root port
> makes sure that any forwarded transaction has a requester ID that falls
> between the secondary and subordinate bus number range of the root
> port.  For instance, if device 01:00.0 was able to generate a
> transaction with a requester ID of 02:00.0, source validation at the
> root port would generate an ACS violation.  If the root port does not
> support source validation, the transaction might successfully reference
> the iommu context for the other endpoint.  Therefore I don't understand
> what property of the SMMU is able to prevent this spoofing technique if
> the root port provides no protection on its own.  Thanks,
Yes, you are right. I left out some details to our implementation. Our
implementation
of the stream ID is not just the BDF. The stream ID also contains a
port ID at the
upper bits to indicate the difference between the PCIe ports. The scenario you
explained up above should not happen.
>
> Alex

Re: [PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

On Thu, Jul 20, 2017 at 3:22 PM, Alex Williamson
 wrote:
> On Wed, 19 Jul 2017 17:46:51 -0700
> Feng Kan  wrote:
>
>> The APM X-Gene PCIe root port does not support ACS at this point.
>> However, the hw provides isolation and source validation through
>> the SMMU. Turn on ACS but disable all the peer to peer features.
>>
>> Signed-off-by: Feng Kan 
>> ---
>>  drivers/pci/quirks.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 085fb78..0f8f1cd 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, 
>> u16 acs_flags)
>>   return acs_flags ? 0 : 1;
>>  }
>>
>> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> +{
>> + /*
>> +  * XGene root matching this quirk do not allow peer-to-peer
>> +  * transactions with others, allowing masking out these bits as if they
>> +  * were unimplemented in the ACS capability.
>> +  */
>> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> +
>> + return acs_flags ? 0 : 1;
>> +}
>> +
>>  /*
>>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>>   * transactions and validate bus numbers in requests, but do not provide an
>> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> *dev, u16 acs_flags)
>>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>>   /* Cavium ThunderX */
>>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> + /* APM XGene */
>> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>>   { 0 }
>>  };
>>
>
> Sorry, I'm not yet convinced there's an equivalent of SV, if a device
> spoofs a different bdf and it reaches the smmu, what prevents that from
> simply referencing the context for that alternate bdf?
Perhaps I am not understanding the question correctly. The bdf forms a
stream id which is used to provide an context. Since there is no actual
context created by an alternate bdf, the transaction would be rejected
by the SMMU.

The point of
> root port SV is to ensure that any forwarded transaction is within the
> downstream bdf range.  Thanks,
>
> Alex

[PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
However, the hw provides isolation and source validation through
the SMMU. Turn on ACS but disable all the peer to peer features.

Signed-off-by: Feng Kan 
---
 drivers/pci/quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..0f8f1cd 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 
acs_flags)
return acs_flags ? 0 : 1;
 }
 
+static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
+{
+   /*
+* XGene root matching this quirk do not allow peer-to-peer
+* transactions with others, allowing masking out these bits as if they
+* were unimplemented in the ACS capability.
+*/
+   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
+  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
+
+   return acs_flags ? 0 : 1;
+}
+
 /*
  * Many Intel PCH root ports do provide ACS-like features to disable peer
  * transactions and validate bus numbers in requests, but do not provide an
@@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
{ 0 }
 };
 
-- 
1.8.3.1

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

>
> I don't know what that means, does the hardware support an equivalent
> to source validation or not?

Yes, source validation is done through the smmu.

  What's the response of the root port if
> the downstream device issues a transaction spoofing devices not within
> the bus number ranges of the bridge?
HW guys informs me there is way to disable transactions between root port.
I will confirm later.

>
>> Alex, the goal here is to enable virtualization to work correctly.
>> Please let me know if the
>> above is sufficient. Much thanks.
>
> Of course, but that means that the hardware vendor is vouching that
> this device provides the equivalent isolation for each of the missing
> components of ACS.  Claiming to have isolation capabilities that don't
> exist would be irresponsible and put users of that hardware at risk.
Agreed, I believe we do have isolation in our case based on the conference
we had today.

> Thanks,
>
> Alex

Re: [PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

On Mon, Jul 17, 2017 at 7:23 PM, Alex Williamson
 wrote:
> On Mon, 17 Jul 2017 17:45:52 -0700
> Feng Kan  wrote:
>
>> The APM X-Gene PCIe root port does not support ACS at this point.
>> Since the root does not allow peer to peer transactions, mask out
>> ACS capability flag bits.
>>
>> Signed-off-by: Feng Kan 
>> ---
>>  drivers/pci/quirks.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 085fb78..951064d 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4368,6 +4368,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> *dev, u16 acs_flags)
>>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>>   /* Cavium ThunderX */
>>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> + /* APM XGene */
>> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_mf_endpoint_acs },
>>   { 0 }
>>  };
>
>
> You're using the "mf_enpoint" quirk for something that is not an
> endpoint and may or may not be multi-function.  Downstream ports have
> different rules than multi-function endpoints and the quirk function is
> commented to reflect why certain fields are relevant or not to
> multi-function endpoints.  I don't think it's valid to use this quirk
> for other device types, we'd only need to accidentally test the assumed
> device type in that function to break you in the future.
Would creating another function like what Cavium did be sufficient?


Additionally,
> lack of peer to peer does not necessarily imply functionality like
> Source Validation, without which a device can spoof the requester ID.
> Thanks,
I can remove the statement.
>
> Alex
Alex, the goal here is to enable virtualization to work correctly.
Please let me know if the
above is sufficient. Much thanks.
>

[PATCH] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
Since the root does not allow peer to peer transactions, mask out
ACS capability flag bits.

Signed-off-by: Feng Kan 
---
 drivers/pci/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..951064d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4368,6 +4368,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_mf_endpoint_acs },
{ 0 }
 };
 
-- 
1.8.3.1

[PATCH V5 1/2] arm64: Change memcpy in kernel to use the copy template file

[Feng Kan]

This converts the memcpy.S to use the copy template file. The copy
template file was based originally on the memcpy.S

Signed-off-by: Feng Kan 
Signed-off-by: Balamurugan Shanmugam 
---
 arch/arm64/lib/copy_template.S | 195 +
 arch/arm64/lib/memcpy.S| 179 ++---
 2 files changed, 221 insertions(+), 153 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template.S

diff --git a/arch/arm64/lib/copy_template.S b/arch/arm64/lib/copy_template.S
new file mode 100644
index 000..048e66b
--- /dev/null
+++ b/arch/arm64/lib/copy_template.S
@@ -0,0 +1,195 @@
+/*
+ * Copyright (C) 2013 ARM Ltd.
+ * Copyright (C) 2013 Linaro.
+ *
+ * This code is based on glibc cortex strings work originally authored by 
Linaro
+ * and re-licensed under GPLv2 for the Linux kernel. The original code can
+ * be found @
+ *
+ * http://bazaar.launchpad.net/~linaro-toolchain-dev/cortex-strings/trunk/
+ * files/head:/src/aarch64/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+
+/*
+ * Copy a buffer from src to dest (alignment handled by the hardware)
+ *
+ * Parameters:
+ * x0 - dest
+ * x1 - src
+ * x2 - n
+ * Returns:
+ * x0 - dest
+ */
+dstin  .reqx0
+src.reqx1
+count  .reqx2
+tmp1   .reqx3
+tmp1w  .reqw3
+tmp2   .reqx4
+tmp2w  .reqw4
+tmp3   .reqx5
+tmp3w  .reqw5
+dst.reqx6
+
+A_l.reqx7
+A_h.reqx8
+B_l.reqx9
+B_h.reqx10
+C_l.reqx11
+C_h.reqx12
+D_l.reqx13
+D_h.reqx14
+
+   mov dst, dstin
+   cmp count, #16
+   /*When memory length is less than 16, the accessed are not aligned.*/
+   b.lo.Ltiny15
+
+   neg tmp2, src
+   andstmp2, tmp2, #15/* Bytes to reach alignment. */
+   b.eq.LSrcAligned
+   sub count, count, tmp2
+   /*
+   * Copy the leading memory data from src to dst in an increasing
+   * address order.By this way,the risk of overwritting the source
+   * memory data is eliminated when the distance between src and
+   * dst is less than 16. The memory accesses here are alignment.
+   */
+   tbz tmp2, #0, 1f
+   ldrb1   tmp1w, src, #1
+   strb1   tmp1w, dst, #1
+1:
+   tbz tmp2, #1, 2f
+   ldrh1   tmp1w, src, #2
+   strh1   tmp1w, dst, #2
+2:
+   tbz tmp2, #2, 3f
+   ldr1tmp1w, src, #4
+   str1tmp1w, dst, #4
+3:
+   tbz tmp2, #3, .LSrcAligned
+   ldr1tmp1, src, #8
+   str1tmp1, dst, #8
+
+.LSrcAligned:
+   cmp count, #64
+   b.ge.Lcpy_over64
+   /*
+   * Deal with small copies quickly by dropping straight into the
+   * exit block.
+   */
+.Ltail63:
+   /*
+   * Copy up to 48 bytes of data. At this point we only need the
+   * bottom 6 bits of count to be accurate.
+   */
+   andstmp1, count, #0x30
+   b.eq.Ltiny15
+   cmp tmp1w, #0x20
+   b.eq1f
+   b.lt2f
+   ldp1A_l, A_h, src, #16
+   stp1A_l, A_h, dst, #16
+1:
+   ldp1A_l, A_h, src, #16
+   stp1A_l, A_h, dst, #16
+2:
+   ldp1A_l, A_h, src, #16
+   stp1A_l, A_h, dst, #16
+.Ltiny15:
+   /*
+   * Prefer to break one ldp/stp into several load/store to access
+   * memory in an increasing address order,rather than to load/store 16
+   * bytes from (src-16) to (dst-16) and to backward the src to aligned
+   * address,which way is used in original cortex memcpy. If keeping
+   * the original memcpy process here, memmove need to satisfy the
+   * precondition that src address is at least 16 bytes bigger than dst
+   * address,otherwise some source data will be overwritten when memove
+   * call memcpy directly. To make memmove simpler and decouple the
+   * memcpy's dependency on memmove, withdrew the original process.
+   */
+   tbz count, #3, 1f
+   ldr1tmp1, src, #8
+   str1tmp1, dst, #8
+1:
+   tbz count, #2, 2f
+   ldr1tmp1w, src, #4
+   str1tmp1w, dst, #4
+2:
+   tbz count, #1, 3f
+   ldrh1   tmp1w, src, #2
+   strh1   tmp1w, dst, #2
+3:
+   tbz count, #0, .Lexitfunc
+   ldrb1   tmp1w, src, #1
+   strb1   tmp1w, dst, #1
+
+   b   .Lexitfunc
+
+.Lcpy_over64:
+   subscount, 

[PATCH V5 2/2] arm64: copy_to-from-in_user optimization using copy template

[Feng Kan]

This patch optimize copy_to-from-in_user for arm 64bit architecture. The
copy template is used as template file for all the copy*.S files. Minor
change was made to it to accommodate the copy to/from/in user files.

Signed-off-by: Feng Kan 
Signed-off-by: Balamurugan Shanmugam 
---
 arch/arm64/lib/copy_from_user.S | 78 +++--
 arch/arm64/lib/copy_in_user.S   | 67 ---
 arch/arm64/lib/copy_to_user.S   | 67 ---
 3 files changed, 120 insertions(+), 92 deletions(-)

diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 1be9ef2..4699cd7 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,49 +32,58 @@
  * Returns:
  * x0 - bytes not copied
  */
+
+   .macro ldrb1 ptr, regB, val
+   USER(9998f, ldrb  \ptr, [\regB], \val)
+   .endm
+
+   .macro strb1 ptr, regB, val
+   strb \ptr, [\regB], \val
+   .endm
+
+   .macro ldrh1 ptr, regB, val
+   USER(9998f, ldrh  \ptr, [\regB], \val)
+   .endm
+
+   .macro strh1 ptr, regB, val
+   strh \ptr, [\regB], \val
+   .endm
+
+   .macro ldr1 ptr, regB, val
+   USER(9998f, ldr \ptr, [\regB], \val)
+   .endm
+
+   .macro str1 ptr, regB, val
+   str \ptr, [\regB], \val
+   .endm
+
+   .macro ldp1 ptr, regB, regC, val
+   USER(9998f, ldp \ptr, \regB, [\regC], \val)
+   .endm
+
+   .macro stp1 ptr, regB, regC, val
+   stp \ptr, \regB, [\regC], \val
+   .endm
+
+end.reqx5
 ENTRY(__copy_from_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
-   add x5, x1, x2  // upper user buffer boundary
-   subsx2, x2, #16
-   b.mi1f
-0:
-USER(9f, ldp   x3, x4, [x1], #16)
-   subsx2, x2, #16
-   stp x3, x4, [x0], #16
-   b.pl0b
-1: addsx2, x2, #8
-   b.mi2f
-USER(9f, ldr   x3, [x1], #8)
-   sub x2, x2, #8
-   str x3, [x0], #8
-2: addsx2, x2, #4
-   b.mi3f
-USER(9f, ldr   w3, [x1], #4)
-   sub x2, x2, #4
-   str w3, [x0], #4
-3: addsx2, x2, #2
-   b.mi4f
-USER(9f, ldrh  w3, [x1], #2)
-   sub x2, x2, #2
-   strhw3, [x0], #2
-4: addsx2, x2, #1
-   b.mi5f
-USER(9f, ldrb  w3, [x1])
-   strbw3, [x0]
-5: mov x0, #0
+   add end, x0, x2
+#include "copy_template.S"
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
+   mov x0, #0  // Nothing to copy
ret
 ENDPROC(__copy_from_user)
 
.section .fixup,"ax"
.align  2
-9: sub x2, x5, x1
-   mov x3, x2
-10:strbwzr, [x0], #1   // zero remaining buffer space
-   subsx3, x3, #1
-   b.ne10b
-   mov x0, x2  // bytes not copied
+9998:
+   sub x0, end, dst
+:
+   strbwzr, [dst], #1  // zero remaining buffer space
+   cmp dst, end
+   b.lob
ret
.previous
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 1b94661e..81c8fc9 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -33,44 +34,52 @@
  * Returns:
  * x0 - bytes not copied
  */
+   .macro ldrb1 ptr, regB, val
+   USER(9998f, ldrb  \ptr, [\regB], \val)
+   .endm
+
+   .macro strb1 ptr, regB, val
+   USER(9998f, strb \ptr, [\regB], \val)
+   .endm
+
+   .macro ldrh1 ptr, regB, val
+   USER(9998f, ldrh  \ptr, [\regB], \val)
+   .endm
+
+   .macro strh1 ptr, regB, val
+   USER(9998f, strh \ptr, [\regB], \val)
+   .endm
+
+   .macro ldr1 ptr, regB, val
+   USER(9998f, ldr \ptr, [\regB], \val)
+   .endm
+
+   .macro str1 ptr, regB, val
+   USER(9998f, str \ptr, [\regB], \val)
+   .endm
+
+   .macro ldp1 ptr, regB, regC, val
+   USER(9998f, ldp \ptr, \regB, [\regC], \val)
+   .endm
+
+   .macro stp1 ptr, regB, regC, val
+   USER(9998f, stp \ptr, \regB, [\regC], \val)
+   .endm
+
+end.reqx5
 ENTRY(__copy_in_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
-   add x5, x0, x2  // upper user buffer boundary
-   subsx2, x2, #16
-   b.mi1f
-0:
-USER(9f, ldp   x3, x4, [x1], #16)
-   subsx2, x2, #16
-USER(9f, stp   x3, x4, [x0], #16)
-   b.pl0b
-1: addsx2, x2, #8
-   b.mi2f
-USER(9f, ldr   x3, [x1], #8)
-   sub x2, x2, #8
-U

[PATCH V5 0/2] copy to/in/from user optimization

[Feng Kan]

This coverts all copy in/from/to user file to use the copy template file.
The copy template file is based on the memcpy.S. The first patch converts
the memcpy to use the copy template as well. Overnight trinity test and
10G iperf was used to test correctness and performance. Noticeable
iperf improvement (~30%) on the receive side.

V5 Changes:
   1. Switch patch ordering.
   2. Simplify assembly code and use fixed large tags in marco
   3. Fixed indentation issue.

Feng Kan (2):
  arm64: Change memcpy in kernel to use the copy template file
  arm64: copy_to-from-in_user optimization using copy template

 arch/arm64/lib/copy_from_user.S |  78 +---
 arch/arm64/lib/copy_in_user.S   |  67 --
 arch/arm64/lib/copy_template.S  | 195 
 arch/arm64/lib/copy_to_user.S   |  67 --
 arch/arm64/lib/memcpy.S | 179 ++--
 5 files changed, 341 insertions(+), 245 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template.S

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 1/2] arm64: copy_to-from-in_user optimization using copy template

[Feng Kan]

This patch optimize copy_to-from-in_user for arm 64bit architecture.
The copy template is using the memcpy.S as a base. This allows the
sharing of the copy template with all of the copy*.S files.

Signed-off-by: Feng Kan 
Signed-off-by: Balamurugan Shanmugam 
---
 arch/arm64/lib/copy_from_user.S |  78 +---
 arch/arm64/lib/copy_in_user.S   |  66 --
 arch/arm64/lib/copy_template.S  | 196 
 arch/arm64/lib/copy_to_user.S   |  66 --
 4 files changed, 314 insertions(+), 92 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template.S

diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 1be9ef2..cb085cf 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,49 +32,58 @@
  * Returns:
  * x0 - bytes not copied
  */
+
+   .macro ldrb1 label, ptr, regB, val
+   USER(\label, ldrb  \ptr, [\regB], \val)
+   .endm
+
+   .macro strb1 label, ptr, regB, val
+   strb \ptr, [\regB], \val
+   .endm
+
+   .macro ldrh1 label, ptr, regB, val
+   USER(\label, ldrh  \ptr, [\regB], \val)
+   .endm
+
+   .macro strh1 label, ptr, regB, val
+   strh \ptr, [\regB], \val
+   .endm
+
+   .macro ldr1 label, ptr, regB, val
+   USER(\label, ldr \ptr, [\regB], \val)
+   .endm
+
+   .macro str1 label, ptr, regB, val
+   str \ptr, [\regB], \val
+   .endm
+
+   .macro ldp1 label, ptr, regB, regC, val
+   USER(\label, ldp \ptr, \regB, [\regC], \val)
+   .endm
+
+   .macro stp1 label, ptr, regB, regC, val
+   stp \ptr, \regB, [\regC], \val
+   .endm
+
 ENTRY(__copy_from_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
-   add x5, x1, x2  // upper user buffer boundary
-   subsx2, x2, #16
-   b.mi1f
-0:
-USER(9f, ldp   x3, x4, [x1], #16)
-   subsx2, x2, #16
-   stp x3, x4, [x0], #16
-   b.pl0b
-1: addsx2, x2, #8
-   b.mi2f
-USER(9f, ldr   x3, [x1], #8)
-   sub x2, x2, #8
-   str x3, [x0], #8
-2: addsx2, x2, #4
-   b.mi3f
-USER(9f, ldr   w3, [x1], #4)
-   sub x2, x2, #4
-   str w3, [x0], #4
-3: addsx2, x2, #2
-   b.mi4f
-USER(9f, ldrh  w3, [x1], #2)
-   sub x2, x2, #2
-   strhw3, [x0], #2
-4: addsx2, x2, #1
-   b.mi5f
-USER(9f, ldrb  w3, [x1])
-   strbw3, [x0]
-5: mov x0, #0
+#include "copy_template.S"
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
+   mov x0, #0  // Nothing to copy
ret
 ENDPROC(__copy_from_user)
 
.section .fixup,"ax"
.align  2
-9: sub x2, x5, x1
-   mov x3, x2
-10:strbwzr, [x0], #1   // zero remaining buffer space
-   subsx3, x3, #1
-   b.ne10b
-   mov x0, x2  // bytes not copied
+11:
+   sub x4, tmp3, dst
+   mov x0, x4
+   sub dst, tmp3, x4
+
+20:strbwzr, [dst], #1  // zero remaining buffer space
+   subsx4, x4, #1
+   b.ne20b
ret
.previous
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 1b94661e..b54d44e 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -33,44 +34,51 @@
  * Returns:
  * x0 - bytes not copied
  */
+   .macro ldrb1 label, ptr, regB, val
+   USER(\label, ldrb  \ptr, [\regB], \val)
+   .endm
+
+   .macro strb1 label, ptr, regB, val
+   USER(\label, strb \ptr, [\regB], \val)
+   .endm
+
+   .macro ldrh1 label, ptr, regB, val
+   USER(\label, ldrh  \ptr, [\regB], \val)
+   .endm
+
+   .macro strh1 label, ptr, regB, val
+   USER(\label, strh \ptr, [\regB], \val)
+   .endm
+
+   .macro ldr1 label, ptr, regB, val
+   USER(\label, ldr \ptr, [\regB], \val)
+   .endm
+
+   .macro str1 label, ptr, regB, val
+   USER(\label, str \ptr, [\regB], \val)
+   .endm
+
+   .macro ldp1 label, ptr, regB, regC, val
+   USER(\label, ldp \ptr, \regB, [\regC], \val)
+   .endm
+
+   .macro stp1 label, ptr, regB, regC, val
+   USER(\label, stp \ptr, \regB, [\regC], \val)
+   .endm
+
 ENTRY(__copy_in_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN)
-   add x5, x0, x2  // upper user buffer boundary
-   subsx2, x2, #16
-   b.mi1f
-0:
-USER(9f, ldp   x3, x4, [x1], #16)
-   subsx2, x2, #16
-USER(

[PATCH V4 0/2] arm64: copy to/in/from user optimization

[Feng Kan]

This coverts all copy in/from/to user file to use the copy template file.
The copy template file is based on the memcpy.S. The second patch converts
the memcpy to use the copy template as well. Overnight trinity test and
10G iperf was used to test correctness and performance. Noticeable
iperf improvement (~30%) on the receive side.

V4 Change:
- base the copy template file on the existing memcpy.S
- convert copy*.s to user copy template
- conver the memcpy to use the copy template.

Feng Kan (2):
  arm64: copy_to-from-in_user optimization using copy template
  arm64: Change memcpy in kernel to use the copy template file

 arch/arm64/lib/copy_from_user.S |  78 +---
 arch/arm64/lib/copy_in_user.S   |  66 --
 arch/arm64/lib/copy_template.S  | 196 
 arch/arm64/lib/copy_to_user.S   |  66 --
 arch/arm64/lib/memcpy.S | 179 ++--
 5 files changed, 340 insertions(+), 245 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template.S

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 2/2] arm64: Change memcpy in kernel to use the copy template file

[Feng Kan]

This converts the memcpy.S to use the copy template file. The copy
template file was based originally on the memcpy.S. Minor changes
was made to it to accommodate the copy to/from/in user files.

Signed-off-by: Feng Kan 
---
 arch/arm64/lib/memcpy.S | 179 +++-
 1 file changed, 26 insertions(+), 153 deletions(-)

diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
index 8a9a96d..761acd7 100644
--- a/arch/arm64/lib/memcpy.S
+++ b/arch/arm64/lib/memcpy.S
@@ -36,166 +36,39 @@
  * Returns:
  * x0 - dest
  */
-dstin  .reqx0
-src.reqx1
-count  .reqx2
-tmp1   .reqx3
-tmp1w  .reqw3
-tmp2   .reqx4
-tmp2w  .reqw4
-tmp3   .reqx5
-tmp3w  .reqw5
-dst.reqx6
+.macro ldrb1 label, ptr, regB, val
+ldrb  \ptr, [\regB], \val
+.endm
 
-A_l.reqx7
-A_h.reqx8
-B_l.reqx9
-B_h.reqx10
-C_l.reqx11
-C_h.reqx12
-D_l.reqx13
-D_h.reqx14
+.macro strb1 label, ptr, regB, val
+strb \ptr, [\regB], \val
+.endm
 
-ENTRY(memcpy)
-   mov dst, dstin
-   cmp count, #16
-   /*When memory length is less than 16, the accessed are not aligned.*/
-   b.lo.Ltiny15
+.macro ldrh1 label, ptr, regB, val
+ldrh  \ptr, [\regB], \val
+.endm
 
-   neg tmp2, src
-   andstmp2, tmp2, #15/* Bytes to reach alignment. */
-   b.eq.LSrcAligned
-   sub count, count, tmp2
-   /*
-   * Copy the leading memory data from src to dst in an increasing
-   * address order.By this way,the risk of overwritting the source
-   * memory data is eliminated when the distance between src and
-   * dst is less than 16. The memory accesses here are alignment.
-   */
-   tbz tmp2, #0, 1f
-   ldrbtmp1w, [src], #1
-   strbtmp1w, [dst], #1
-1:
-   tbz tmp2, #1, 2f
-   ldrhtmp1w, [src], #2
-   strhtmp1w, [dst], #2
-2:
-   tbz tmp2, #2, 3f
-   ldr tmp1w, [src], #4
-   str tmp1w, [dst], #4
-3:
-   tbz tmp2, #3, .LSrcAligned
-   ldr tmp1, [src],#8
-   str tmp1, [dst],#8
+.macro strh1 label, ptr, regB, val
+strh \ptr, [\regB], \val
+.endm
 
-.LSrcAligned:
-   cmp count, #64
-   b.ge.Lcpy_over64
-   /*
-   * Deal with small copies quickly by dropping straight into the
-   * exit block.
-   */
-.Ltail63:
-   /*
-   * Copy up to 48 bytes of data. At this point we only need the
-   * bottom 6 bits of count to be accurate.
-   */
-   andstmp1, count, #0x30
-   b.eq.Ltiny15
-   cmp tmp1w, #0x20
-   b.eq1f
-   b.lt2f
-   ldp A_l, A_h, [src], #16
-   stp A_l, A_h, [dst], #16
-1:
-   ldp A_l, A_h, [src], #16
-   stp A_l, A_h, [dst], #16
-2:
-   ldp A_l, A_h, [src], #16
-   stp A_l, A_h, [dst], #16
-.Ltiny15:
-   /*
-   * Prefer to break one ldp/stp into several load/store to access
-   * memory in an increasing address order,rather than to load/store 16
-   * bytes from (src-16) to (dst-16) and to backward the src to aligned
-   * address,which way is used in original cortex memcpy. If keeping
-   * the original memcpy process here, memmove need to satisfy the
-   * precondition that src address is at least 16 bytes bigger than dst
-   * address,otherwise some source data will be overwritten when memove
-   * call memcpy directly. To make memmove simpler and decouple the
-   * memcpy's dependency on memmove, withdrew the original process.
-   */
-   tbz count, #3, 1f
-   ldr tmp1, [src], #8
-   str tmp1, [dst], #8
-1:
-   tbz count, #2, 2f
-   ldr tmp1w, [src], #4
-   str tmp1w, [dst], #4
-2:
-   tbz count, #1, 3f
-   ldrhtmp1w, [src], #2
-   strhtmp1w, [dst], #2
-3:
-   tbz count, #0, .Lexitfunc
-   ldrbtmp1w, [src]
-   strbtmp1w, [dst]
+.macro ldr1 label, ptr, regB, val
+ldr \ptr, [\regB], \val
+.endm
 
-.Lexitfunc:
-   ret
+.macro str1 label, ptr, regB, val
+str \ptr, [\regB], \val
+.endm
 
-.Lcpy_over64:
-   subscount, count, #128
-   b.ge.Lcpy_body_large
-   /*
-   * Less than 128 bytes to copy, so handle 64 here and then jump
-   * to the tail.
-   */
-   ldp A_l, A_h, [src],#16
-   stp A_l, A_h, [dst],#16
-   ldp B_l, B_h, [src],#16
-   ldp C_l, C_h, [src],#16
-   stp B_l, B_h, [dst],#16
-   stp C_l, C_h, [dst],#16
-   ldp D_l, D_h, [src],#16
-   stp D_l, D_h, [dst],#16
+.macro ldp1 label, ptr, regB, regC, val
+ldp \ptr, \regB, [\regC], \val
+.endm
 
-   tst count, #0x3f
-   b.ne.Ltail63
- 

Re: [PATCH v4 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state

[Feng Kan]

On Tue, May 19, 2015 at 3:01 AM, Marc Zyngier  wrote:
> On Tue, 19 May 2015 09:40:21 +0100
> Linus Walleij  wrote:
>
>> On Thu, May 14, 2015 at 10:14 PM, Feng Kan  wrote:
>> > On Thu, May 14, 2015 at 3:32 AM, Linus Walleij  
>> > wrote:
>>
>> >> But surely the GPIO block has its own status register, so are
>> >> you saying that this register is unreliable?
>> >
>> > When the GPIO is used as interrupt, the gpio block does not report the
>> > status anymore. Which leaves us stuck with SPISR.
>> >>
>> >> I can think of a few reasons, like transient IRQs etc but
>> >> what is actually causing this?
>> >
>> > I won't say the obvious.
>>
>> Yeah I see your problem now :(
>>
>> I think it's better to fix the access functions so that you can
>> cross-call to the GIC driver to get the SPISR flag out though.
>> Let's see what Marc says.
>>
>> >> Which GPIO driver is this? Is it upstream?
>> >
>> > Yes, it is upstream. It is the xgene slimpro gpio driver. I am starting to
>> > think that we ought to switch to use some gpio poll driver rather than
>> > using gpio-key.
>>
>> There is both gpio_keys_polled and IRQ-driven gpio_keys so yeah
>> that's possible. But honestly I think it's better to deal with this
>> problem for real because IRQ is more efficient.
>>
>> So the way I perceive it this is the real problem:
>>
>> +static int gic_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which, bool 
>> *val)
>> +{
>> +   switch (which) {
>> (...)
>> +   case IRQCHIP_STATE_ACTIVE:
>> +   *val = gic_peek_irq(d, GIC_DIST_ACTIVE_SET);
>> +   break; case: read
>> from 0xd04 (SPISR) instead, because that makes more
>> sense to me, or am I wrong at it?
>>
>> +   case IRQCHIP_STATE_LINE_LEVEL:
>> +   *val = gic_peek_irq(d, GIC_DIST_SPISR);
>> +   break;
>>
>> And then put a define into  for
>> GIC_DIST_SPISR.
>
> What worries me here is that the PENDING state should already give you
> the right level of information (this is what the GIC-400 TRM says). The
> only reason why SPISR exists is that software can write to the PENDING
> register, while SPISR is RO.
>
> If reading the pending state doesn't work, then I'd like to know
> exactly *why*. Only then we can add support for LINE_LEVEL using SPISR
> (which has to be GIC-400 specific, as it is not architected).

IS_PENDING and IS_ACTIVE works fine for the ISR context. However,
the nature of the register is meant for IRQ handling and not to read
the status of a GPIO. By the time the gpio_key throws a work queue
and check the status of the PENDING register, it is no long relevant.



>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

This patch adds the support for APM Merlin board. The Merlin board
is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
Ethernet, SATA and Serial.

Signed-off-by: Feng Kan 
---
  V4 Change:
- Add ethernet

  V3 Change:
- Add PCIe
- Add merline to makefile in dts/apm directory

  V2 Change:
- Add dma-range definition

  V1 Change:
- add memreserve for spintable.
- remove clkfreq attribute
- update spin location, although it is done by bootloader.
- remove msi reg entry
- add chosen for stdout path
 arch/arm64/boot/dts/apm/Makefile   |   1 +
 arch/arm64/boot/dts/apm/apm-merlin.dts |  54 ++
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 267 +
 3 files changed, 322 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
 create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

diff --git a/arch/arm64/boot/dts/apm/Makefile b/arch/arm64/boot/dts/apm/Makefile
index a2afabb..c75f17a 100644
--- a/arch/arm64/boot/dts/apm/Makefile
+++ b/arch/arm64/boot/dts/apm/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
+dtb-$(CONFIG_ARCH_XGENE) += apm-merlin.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/apm/apm-merlin.dts 
b/arch/arm64/boot/dts/apm/apm-merlin.dts
new file mode 100644
index 000..10dfa7a
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-merlin.dts
@@ -0,0 +1,54 @@
+/*
+ * dts file for AppliedMicro (APM) Merlin Board
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "apm-shadowcat.dtsi"
+
+/ {
+   model = "APM X-Gene Merlin board";
+   compatible = "apm,merlin", "apm,xgene-shadowcat";
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   reg = < 0x1 0x 0x0 0x8000 >;
+   };
+};
+
+&serial0 {
+   status = "ok";
+};
+
+&pcie0 {
+   status = "ok";
+};
+
+&sata1 {
+   status = "ok";
+};
+
+&sata2 {
+   status = "ok";
+};
+
+&sata3 {
+   status = "ok";
+};
+
+&sgenet0 {
+   status = "ok";
+};
+
+&xgenet1 {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
new file mode 100644
index 000..77e3b0e
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -0,0 +1,267 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Shadowcat SOC
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/ {
+   compatible = "apm,xgene-shadowcat";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@000 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x000>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@001 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x001>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cp

Re: [PATCH v4 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state

[Feng Kan]

On Thu, May 14, 2015 at 3:32 AM, Linus Walleij  wrote:
> On Wed, May 13, 2015 at 5:44 PM, Feng Kan  wrote:
>
>> We are using the gpio driver with gpio_key for power button. The gpio
>> status can only be retrieved from the GIC register when the gpio is
>> acting as a interrupt.
>
> OK I understand so much. SPISR is a status register of the state
> of the IRQ lines of shared peripherals.
>
> But surely the GPIO block has its own status register, so are
> you saying that this register is unreliable?

When the GPIO is used as interrupt, the gpio block does not report the
status anymore. Which leaves us stuck with SPISR.
>
> I can think of a few reasons, like transient IRQs etc but
> what is actually causing this?

I won't say the obvious.
>
> Techically the GIC would normally be higher up the food
> chain, i.e. one IRQ on the GIC is cascaded to sub-IRQs on
> the GPIO chip by virtue of its own struct irq_chip and
> irqdomain. The exception is typically only systems where
> the GPIO block is fused with the IRQ controller so that each
> GPIO line has its own unique IRQ line on the primary,
> top-level interrupt controller.
>
> Which GPIO driver is this? Is it upstream?
Yes, it is upstream. It is the xgene slimpro gpio driver. I am starting to
think that we ought to switch to use some gpio poll driver rather than
using gpio-key.
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state

[Feng Kan]

On Wed, May 13, 2015 at 4:58 AM, Linus Walleij  wrote:
> On Wed, May 13, 2015 at 4:25 AM, Feng Kan  wrote:
>
>> Marc:
>>
>> Sorry for top posting. It seems with GIC-400, the get_irqstate is not a 
>> reliable
>> way of accessing the GPIO status. In our case, the gpio interrupt status can
>> only be read correctly with the SPISR register. So it seems we have to go
>> back to the old way of mapping the SPISR portion of the GIC in our GPIO
>> driver. We wanted to ask you if that is acceptable since SPISR in not
>> standard in all GIC, perhaps we can treat it differently.
>
> As GPIO maintainer I am curious about what this is...
>
> Can you describe the scenario where your GPIO (!) driver needs
> to be poking around in the GIC SPISR?

We are using the gpio driver with gpio_key for power button. The gpio
status can only be retrieved from the GIC register when the gpio is
acting as a interrupt. Marc had provided a patch which allow the
getting of the irq status
using the PENDING_SET register, however it seems it is not reliable.
Another register in the GIC call the SPISR always give the correct
status but it is only available in the GIC-400 and hence not likely to
be incorporated into the general GIC code. We would like to go back
the version 1 of the patch and ioremap the region in the gpio driver
and access the status that way. Please let us know what you think.

>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/3] irqchip: GIC: Add support for irq_{get,set}_irqchip_state

[Feng Kan]

Marc:

Sorry for top posting. It seems with GIC-400, the get_irqstate is not a reliable
way of accessing the GPIO status. In our case, the gpio interrupt status can
only be read correctly with the SPISR register. So it seems we have to go
back to the old way of mapping the SPISR portion of the GIC in our GPIO
driver. We wanted to ask you if that is acceptable since SPISR in not
standard in all GIC, perhaps we can treat it differently.

On Wed, Mar 18, 2015 at 4:01 AM, Marc Zyngier  wrote:
> Add the required hooks for the internal state of an interrupt
> to be exposed to other subsystems.
>
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/irqchip/irq-gic.c | 69 
> ---
>  1 file changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 471e1cd..0b4a4d0 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -151,13 +151,24 @@ static inline unsigned int gic_irq(struct irq_data *d)
>  /*
>   * Routines to acknowledge, disable and enable interrupts
>   */
> -static void gic_mask_irq(struct irq_data *d)
> +static void gic_poke_irq(struct irq_data *d, u32 offset)
> +{
> +   u32 mask = 1 << (gic_irq(d) % 32);
> +   writel_relaxed(mask, gic_dist_base(d) + offset + (gic_irq(d) / 32) * 
> 4);
> +}
> +
> +static int gic_peek_irq(struct irq_data *d, u32 offset)
>  {
> u32 mask = 1 << (gic_irq(d) % 32);
> +   return !!(readl_relaxed(gic_dist_base(d) + offset + (gic_irq(d) / 32) 
> * 4) & mask);
> +}
> +
> +static void gic_mask_irq(struct irq_data *d)
> +{
> unsigned long flags;
>
> raw_spin_lock_irqsave(&irq_controller_lock, flags);
> -   writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + 
> (gic_irq(d) / 32) * 4);
> +   gic_poke_irq(d, GIC_DIST_ENABLE_CLEAR);
> if (gic_arch_extn.irq_mask)
> gic_arch_extn.irq_mask(d);
> raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
> @@ -165,13 +176,12 @@ static void gic_mask_irq(struct irq_data *d)
>
>  static void gic_unmask_irq(struct irq_data *d)
>  {
> -   u32 mask = 1 << (gic_irq(d) % 32);
> unsigned long flags;
>
> raw_spin_lock_irqsave(&irq_controller_lock, flags);
> if (gic_arch_extn.irq_unmask)
> gic_arch_extn.irq_unmask(d);
> -   writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + 
> (gic_irq(d) / 32) * 4);
> +   gic_poke_irq(d, GIC_DIST_ENABLE_SET);
> raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
>  }
>
> @@ -186,6 +196,55 @@ static void gic_eoi_irq(struct irq_data *d)
> writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
>  }
>
> +static int gic_irq_set_irqchip_state(struct irq_data *d,
> +enum irqchip_irq_state which, bool val)
> +{
> +   u32 reg;
> +
> +   switch (which) {
> +   case IRQCHIP_STATE_PENDING:
> +   reg = val ? GIC_DIST_PENDING_SET : GIC_DIST_PENDING_CLEAR;
> +   break;
> +
> +   case IRQCHIP_STATE_ACTIVE:
> +   reg = val ? GIC_DIST_ACTIVE_SET : GIC_DIST_ACTIVE_CLEAR;
> +   break;
> +
> +   case IRQCHIP_STATE_MASKED:
> +   reg = val ? GIC_DIST_ENABLE_CLEAR : GIC_DIST_ENABLE_SET;
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   gic_poke_irq(d, reg);
> +   return 0;
> +}
> +
> +static int gic_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which, bool *val)
> +{
> +   switch (which) {
> +   case IRQCHIP_STATE_PENDING:
> +   *val = gic_peek_irq(d, GIC_DIST_PENDING_SET);
> +   break;
> +
> +   case IRQCHIP_STATE_ACTIVE:
> +   *val = gic_peek_irq(d, GIC_DIST_ACTIVE_SET);
> +   break;
> +
> +   case IRQCHIP_STATE_MASKED:
> +   *val = !gic_peek_irq(d, GIC_DIST_ENABLE_SET);
> +   break;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   return 0;
> +}
> +
>  static int gic_set_type(struct irq_data *d, unsigned int type)
>  {
> void __iomem *base = gic_dist_base(d);
> @@ -329,6 +388,8 @@ static struct irq_chip gic_chip = {
> .irq_set_affinity   = gic_set_affinity,
>  #endif
> .irq_set_wake   = gic_set_wake,
> +   .irq_get_irqchip_state  = gic_irq_get_irqchip_state,
> +   .irq_set_irqchip_state  = gic_irq_set_irqchip_state,
>  };
>
>  void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m

[PATCH V3] arm64: optimized copy_to_user and copy_from_user assembly code

[Feng Kan]

Using the glibc cortex string work work authored by Linaro as base to
create new copy to/from user kernel routine.

Iperf performance increase:
-l (size)   1 core result
Optimized   64B 44-51Mb/s
1500B   4.9Gb/s
3B  16.2Gb/s
Original64B 34-50.7Mb/s
1500B   4.7Gb/s
3B  14.5Gb/s

Signed-off-by: Feng Kan 
---
 arch/arm64/lib/copy_from_user.S |  92 +++--
 arch/arm64/lib/copy_template.S  | 213 
 arch/arm64/lib/copy_to_user.S   |  56 ++-
 3 files changed, 302 insertions(+), 59 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template.S

diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 5e27add..0e79ed9 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -15,7 +15,6 @@
  */
 
 #include 
-#include 
 
 /*
  * Copy from user space to a kernel buffer (alignment handled by the hardware)
@@ -28,39 +27,68 @@
  * x0 - bytes not copied
  */
 ENTRY(__copy_from_user)
-   add x4, x1, x2  // upper user buffer boundary
-   subsx2, x2, #8
-   b.mi2f
-1:
-USER(9f, ldr   x3, [x1], #8)
-   subsx2, x2, #8
-   str x3, [x0], #8
-   b.pl1b
-2: addsx2, x2, #4
-   b.mi3f
-USER(9f, ldr   w3, [x1], #4)
-   sub x2, x2, #4
-   str w3, [x0], #4
-3: addsx2, x2, #2
-   b.mi4f
-USER(9f, ldrh  w3, [x1], #2)
-   sub x2, x2, #2
-   strhw3, [x0], #2
-4: addsx2, x2, #1
-   b.mi5f
-USER(9f, ldrb  w3, [x1])
-   strbw3, [x0]
-5: mov x0, #0
-   ret
+#include "copy_template.S"
 ENDPROC(__copy_from_user)
 
.section .fixup,"ax"
-   .align  2
-9: sub x2, x4, x1
-   mov x3, x2
-10:strbwzr, [x0], #1   // zero remaining buffer space
-   subsx3, x3, #1
-   b.ne10b
-   mov x0, x2  // bytes not copied
+   .align2
+9:
+   /*
+* count is accurate
+* dst is accurate
+*/
+   mov x0, count
+   sub dst, dst, tmp1
+   b   .Lfinalize
+
+10:
+   /*
+* count is in the last 15 bytes
+* dst is somewhere in there
+*/
+   mov x0, count
+   sub dst, limit, count
+   b   .Lfinalize
+11:
+   /*
+* count over counted by tmp2
+* dst could be anywhere in there
+*/
+   add x0, count, tmp2
+   sub dst, limit, x0
+   b   .Lfinalize
+12:
+   /*
+* (count + 64) bytes remain
+* dst is accurate
+*/
+   addsx0, count, #64
+   b   .Lfinalize
+13:
+   /*
+* (count + 128) bytes remain
+* dst is pre-biased to (dst + 16)
+*/
+   addsx0, count, #128
+   add dst, dst, #16
+   b   .Lfinalize
+14:
+   /*
+* (count + 64) bytes remain
+* dst is pre-biased to (dst + 16)
+*/
+   addsx0, count, #64
+   add dst, dst, #16
+
+.Lfinalize:
+   /*
+* Zeroize remaining destination-buffer
+*/
+   mov count, x0
+20:
+   /* Zero remaining buffer space */
+   strbwzr, [dst], #1
+   subscount, count, #1
+   b.ne20b
ret
.previous
diff --git a/arch/arm64/lib/copy_template.S b/arch/arm64/lib/copy_template.S
new file mode 100644
index 000..7a22c6b
--- /dev/null
+++ b/arch/arm64/lib/copy_template.S
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Copyright (c) 2012-2013, Linaro Limited
+ *
+ * Author: Feng Kan 
+ * Author: Philipp Tomsich 
+ *
+ * The code is adopted from the memcpy routine by Linaro Limited.
+ *
+ * This file is free software: you may copy, redistribute and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ * This file incorporates work covered by the following copyright and
+ * permission notice:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *  1 Redistributions of source code must 

[PATCH RESEND V4 1/4] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 459 +
 3 files changed, 469 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..1ac07d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1082,6 +1082,15 @@ config I2C_CROS_EC_TUNNEL
  connected there. This will work whatever the interface used to
  talk to the EC (SPI, I2C or LPC).
 
+config I2C_XGENE_SLIMPRO
+   tristate "APM X-Gene SoC I2C SLIMpro devices support"
+   depends on ARCH_XGENE && MAILBOX
+   help
+ Enable I2C bus access using the APM X-Gene SoC SLIMpro
+ co-processor. The I2C device access the I2C bus via the X-Gene
+ to SLIMpro (On chip coprocessor) mailbox mechanism.
+ If unsure, say N.
+
 config SCx200_ACB
tristate "Geode ACCESS.bus support"
depends on X86_32 && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..9cf9c4b 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
+obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
new file mode 100644
index 000..f994b8a0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -0,0 +1,459 @@
+/*
+ * X-Gene SLIMpro I2C Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Author: Hieu Le 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This driver provides support for X-Gene SLIMpro I2C device access
+ * using the APM X-Gene SLIMpro mailbox driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
+#define MAILBOX_I2C_INDEX  0
+#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only */
+
+#define SMBUS_CMD_LEN  1
+#define BYTE_DATA  1
+#define WORD_DATA  2
+#define BLOCK_DATA 3
+
+#define SLIMPRO_IIC_I2C_PROTOCOL   0
+#define SLIMPRO_IIC_SMB_PROTOCOL   1
+
+#define SLIMPRO_IIC_READ   0
+#define SLIMPRO_IIC_WRITE  1
+
+#define IIC_SMB_WITHOUT_DATA_LEN   0
+#define IIC_SMB_WITH_DATA_LEN  1
+
+#define SLIMPRO_DEBUG_MSG  0
+#define SLIMPRO_MSG_TYPE_SHIFT 28
+#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
+#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
+#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
+#define SLIMPRO_IIC_DEV_SHIFT  23
+#define SLIMPRO_IIC_DEV_MASK   0x0080U
+#define SLIMPRO_IIC_DEVID_SHIFT13
+#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
+#define SLIMPRO_IIC_RW_SHIFT   12
+#define SLIMPRO_IIC_RW_MASK0x1000U
+#define SLIMPRO_IIC_PROTO_SHIFT11
+#define SLIMPRO_IIC_PROTO_MASK 0x0800U
+#define SLIMPRO_IIC_ADDRLEN_SHIFT  8
+#define SLIMPRO_IIC_ADDRLEN_MASK   0x0700U
+#define SLIMPRO_IIC_DATALEN_SHIFT  0
+#define SLIMPRO_IIC_DATALEN_MASK   0x00FFU
+
+/*
+ * SLIMpro I2C message encode
+ *
+ * dev - Controller number (0-based)
+ * chip- I2C chip address
+ * op  - SLIMPRO_IIC_READ or SLIMPRO_IIC_WRITE
+ * proto   - SLIMPRO_IIC_SMB_PROTOCOL or SLIMPRO_IIC_I2C_PROTOCOL
+ * addrlen - Length of the address field
+ * datalen - Length of the data field
+ */
+#define SLIMPRO_IIC_ENCODE_MSG(dev, chip, op, proto, addrl

[PATCH RESEND V4 3/4] Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver documentation

[Feng Kan]

Add APM X-Gene platform SLIMpro I2C driver documentation.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt 
b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
new file mode 100644
index 000..f6b2c20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
@@ -0,0 +1,15 @@
+APM X-Gene SLIMpro Mailbox I2C Driver
+
+An I2C controller accessed over the "SLIMpro" mailbox.
+
+Required properties :
+
+ - compatible : should be "apm,xgene-slimpro-i2c"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND V4 0/4] i2c: busses: xgene: I2C proxy driver for X-Gene

[Feng Kan]

This is a proxy I2C driver for APM X-Gene SoC. It uses the mailbox driver
to tunnel i2c transactions via the SLIMpro processor.

V4 Change:
- Remove PRP0001 and use a real ACPI id
V3 Change:
- Add ACPI support
- Fix previous comments.

Feng Kan (4):
  i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform
  i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver
  Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver
documentation
  arm64: dts: add proxy I2C device driver on APM X-Gene platform

 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt  |  15 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 469 +
 5 files changed, 499 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND V4 2/4] i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver

[Feng Kan]

This adds support for ACPI for the APM X-Gene I2C SLIMpro proxy
driver.

Signed-off-by: Feng Kan 
---
 drivers/i2c/busses/i2c-xgene-slimpro.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index f994b8a0..0b33aa2e 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -22,6 +22,7 @@
  * using the APM X-Gene SLIMpro mailbox driver.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -442,12 +443,21 @@ static const struct of_device_id 
xgene_slimpro_i2c_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, xgene_slimpro_i2c_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_slimpro_i2c_acpi_ids[] = {
+   {"APMC0D40", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, xgene_slimpro_i2c_acpi_ids);
+#endif
+
 static struct platform_driver xgene_slimpro_i2c_driver = {
.probe  = xgene_slimpro_i2c_probe,
.remove = xgene_slimpro_i2c_remove,
.driver = {
.name   = "xgene-slimpro-i2c",
.of_match_table = of_match_ptr(xgene_slimpro_i2c_dt_ids),
+   .acpi_match_table = ACPI_PTR(xgene_slimpro_i2c_acpi_ids)
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND V4 4/4] arm64: dts: add proxy I2C device driver on APM X-Gene platform

[Feng Kan]

Add proxy I2C device driver on APM X-Gene platform.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 70c14fa..00ae4d8 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -483,6 +483,11 @@
<0x0 0x7 0x4>;
};
 
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/4] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Sorry, please disregard this series. Made a mistake here, will fix and resend.

On Fri, Apr 24, 2015 at 10:11 AM, Feng Kan  wrote:
> Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
> device driver use the SLIMpro Mailbox driver to tunnel message to
> the SLIMpro coprocessor to do the work of accessing I2C components.
>
> Signed-off-by: Feng Kan 
> Signed-off-by: Hieu Le 
> ---
>  drivers/i2c/busses/Kconfig |   9 +
>  drivers/i2c/busses/Makefile|   1 +
>  drivers/i2c/busses/i2c-xgene-slimpro.c | 459 
> +
>  3 files changed, 469 insertions(+)
>  create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 22da9c2..1ac07d0 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -1082,6 +1082,15 @@ config I2C_CROS_EC_TUNNEL
>   connected there. This will work whatever the interface used to
>   talk to the EC (SPI, I2C or LPC).
>
> +config I2C_XGENE_SLIMPRO
> +   tristate "APM X-Gene SoC I2C SLIMpro devices support"
> +   depends on ARCH_XGENE && MAILBOX
> +   help
> + Enable I2C bus access using the APM X-Gene SoC SLIMpro
> + co-processor. The I2C device access the I2C bus via the X-Gene
> + to SLIMpro (On chip coprocessor) mailbox mechanism.
> + If unsure, say N.
> +
>  config SCx200_ACB
> tristate "Geode ACCESS.bus support"
> depends on X86_32 && PCI
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 3638feb..9cf9c4b 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -107,6 +107,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
>  obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
>  obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
>  obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
> +obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
>  obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
>
>  ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
> b/drivers/i2c/busses/i2c-xgene-slimpro.c
> new file mode 100644
> index 000..afe4cf2
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
> @@ -0,0 +1,459 @@
> +/*
> + * X-Gene SLIMpro I2C Driver
> + *
> + * Copyright (c) 2014, Applied Micro Circuits Corporation
> + * Author: Feng Kan 
> + * Author: Hieu Le 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + *
> + * This driver provides support for X-Gene SLIMpro I2C device access
> + * using the APM X-Gene SLIMpro mailbox driver.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
> +#define MAILBOX_I2C_INDEX  0
> +#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only 
> */
> +
> +#define SMBUS_CMD_LEN  1
> +#define BYTE_DATA  1
> +#define WORD_DATA  2
> +#define BLOCK_DATA 3
> +
> +#define SLIMPRO_IIC_I2C_PROTOCOL   0
> +#define SLIMPRO_IIC_SMB_PROTOCOL   1
> +
> +#define SLIMPRO_IIC_READ   0
> +#define SLIMPRO_IIC_WRITE  1
> +
> +#define IIC_SMB_WITHOUT_DATA_LEN   0
> +#define IIC_SMB_WITH_DATA_LEN  1
> +
> +#define SLIMPRO_DEBUG_MSG  0
> +#define SLIMPRO_MSG_TYPE_SHIFT 28
> +#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
> +#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
> +#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
> +#define SLIMPRO_IIC_DEV_SHIFT  23
> +#define SLIMPRO_IIC_DEV_MASK   0x0080U
> +#define SLIMPRO_IIC_DEVID_SHIFT13
> +#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
> +#define SLIMPRO_IIC_RW_SHIFT   12
> +#define SLIMPRO_IIC_RW_MASK0x1000U
> +#d

[PATCH V4 2/4] i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver

[Feng Kan]

This adds support for ACPI for the APM X-Gene I2C SLIMpro proxy
driver.

Signed-off-by: Feng Kan 
---
 drivers/i2c/busses/i2c-xgene-slimpro.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index afe4cf2..f1caa29 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -22,6 +22,7 @@
  * using the APM X-Gene SLIMpro mailbox driver.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -442,12 +443,21 @@ static const struct of_device_id xgene_slimpro_i2c_id[] = 
{
 };
 MODULE_DEVICE_TABLE(of, xgene_slimpro_i2c_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_slimpro_i2c_acpi_ids[] = {
+   {"APMC0D40", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
+
 static struct platform_driver xgene_slimpro_i2c_driver = {
.probe  = xgene_slimpro_i2c_probe,
.remove = xgene_slimpro_i2c_remove,
.driver = {
.name   = "xgene-slimpro-i2c",
-   .of_match_table = of_match_ptr(xgene_slimpro_i2c_id)
+   .of_match_table = of_match_ptr(xgene_slimpro_i2c_id),
+   .acpi_match_table = ACPI_PTR(xgene_slimpro_i2c_acpi_ids)
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 3/4] Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver documentation

[Feng Kan]

Add APM X-Gene platform SLIMpro I2C driver documentation.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt 
b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
new file mode 100644
index 000..f6b2c20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
@@ -0,0 +1,15 @@
+APM X-Gene SLIMpro Mailbox I2C Driver
+
+An I2C controller accessed over the "SLIMpro" mailbox.
+
+Required properties :
+
+ - compatible : should be "apm,xgene-slimpro-i2c"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 4/4] arm64: dts: add proxy I2C device driver on APM X-Gene platform

[Feng Kan]

Add proxy I2C device driver on APM X-Gene platform.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index a2b9657..d405dd0 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -522,6 +522,11 @@
<0x0 0x7 0x4>;
};
 
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 1/4] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 459 +
 3 files changed, 469 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..1ac07d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1082,6 +1082,15 @@ config I2C_CROS_EC_TUNNEL
  connected there. This will work whatever the interface used to
  talk to the EC (SPI, I2C or LPC).
 
+config I2C_XGENE_SLIMPRO
+   tristate "APM X-Gene SoC I2C SLIMpro devices support"
+   depends on ARCH_XGENE && MAILBOX
+   help
+ Enable I2C bus access using the APM X-Gene SoC SLIMpro
+ co-processor. The I2C device access the I2C bus via the X-Gene
+ to SLIMpro (On chip coprocessor) mailbox mechanism.
+ If unsure, say N.
+
 config SCx200_ACB
tristate "Geode ACCESS.bus support"
depends on X86_32 && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..9cf9c4b 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
+obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
new file mode 100644
index 000..afe4cf2
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -0,0 +1,459 @@
+/*
+ * X-Gene SLIMpro I2C Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Author: Hieu Le 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This driver provides support for X-Gene SLIMpro I2C device access
+ * using the APM X-Gene SLIMpro mailbox driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
+#define MAILBOX_I2C_INDEX  0
+#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only */
+
+#define SMBUS_CMD_LEN  1
+#define BYTE_DATA  1
+#define WORD_DATA  2
+#define BLOCK_DATA 3
+
+#define SLIMPRO_IIC_I2C_PROTOCOL   0
+#define SLIMPRO_IIC_SMB_PROTOCOL   1
+
+#define SLIMPRO_IIC_READ   0
+#define SLIMPRO_IIC_WRITE  1
+
+#define IIC_SMB_WITHOUT_DATA_LEN   0
+#define IIC_SMB_WITH_DATA_LEN  1
+
+#define SLIMPRO_DEBUG_MSG  0
+#define SLIMPRO_MSG_TYPE_SHIFT 28
+#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
+#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
+#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
+#define SLIMPRO_IIC_DEV_SHIFT  23
+#define SLIMPRO_IIC_DEV_MASK   0x0080U
+#define SLIMPRO_IIC_DEVID_SHIFT13
+#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
+#define SLIMPRO_IIC_RW_SHIFT   12
+#define SLIMPRO_IIC_RW_MASK0x1000U
+#define SLIMPRO_IIC_PROTO_SHIFT11
+#define SLIMPRO_IIC_PROTO_MASK 0x0800U
+#define SLIMPRO_IIC_ADDRLEN_SHIFT  8
+#define SLIMPRO_IIC_ADDRLEN_MASK   0x0700U
+#define SLIMPRO_IIC_DATALEN_SHIFT  0
+#define SLIMPRO_IIC_DATALEN_MASK   0x00FFU
+
+/*
+ * SLIMpro I2C message encode
+ *
+ * dev - Controller number (0-based)
+ * chip- I2C chip address
+ * op  - SLIMPRO_IIC_READ or SLIMPRO_IIC_WRITE
+ * proto   - SLIMPRO_IIC_SMB_PROTOCOL or SLIMPRO_IIC_I2C_PROTOCOL
+ * addrlen - Length of the address field
+ * datalen - Length of the data field
+ */
+#define SLIMPRO_IIC_ENCODE_MSG(dev, chip, op, proto, addrl

[PATCH V4 0/4] i2c: busses: xgene: I2C proxy driver for X-Gene

[Feng Kan]

This is a proxy I2C driver for APM X-Gene SoC. It uses the mailbox driver
to tunnel i2c transactions via the SLIMpro processor.

V4 Change:
- Remove PRP0001 and use a real ACPI id
V3 Change:
- Add ACPI support
- Fix previous comments.

Feng Kan (4):
  i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform
  i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver
  Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver
documentation
  arm64: dts: add proxy I2C device driver on APM X-Gene platform

 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt  |  15 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 469 +
 5 files changed, 499 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 2/4] i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver

[Feng Kan]

This adds support for ACPI for the APM X-Gene I2C SLIMpro proxy
driver.

Signed-off-by: Feng Kan 
---
 drivers/i2c/busses/i2c-xgene-slimpro.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index afe4cf2..0035760 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -22,6 +22,7 @@
  * using the APM X-Gene SLIMpro mailbox driver.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -442,12 +443,21 @@ static const struct of_device_id xgene_slimpro_i2c_id[] = 
{
 };
 MODULE_DEVICE_TABLE(of, xgene_slimpro_i2c_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_slimpro_i2c_acpi_ids[] = {
+   {"PRP0001", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
+
 static struct platform_driver xgene_slimpro_i2c_driver = {
.probe  = xgene_slimpro_i2c_probe,
.remove = xgene_slimpro_i2c_remove,
.driver = {
.name   = "xgene-slimpro-i2c",
-   .of_match_table = of_match_ptr(xgene_slimpro_i2c_id)
+   .of_match_table = of_match_ptr(xgene_slimpro_i2c_id),
+   .acpi_match_table = ACPI_PTR(xgene_slimpro_i2c_acpi_ids)
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 4/4] arm64: dts: add proxy I2C device driver on APM X-Gene platform

[Feng Kan]

Add proxy I2C device driver on APM X-Gene platform.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index a2b9657..d405dd0 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -522,6 +522,11 @@
<0x0 0x7 0x4>;
};
 
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 0/4] i2c: busses: xgene: I2C proxy driver for X-Gene

[Feng Kan]

This is a proxy I2C driver for APM X-Gene SoC. It uses the mailbox driver
to tunnel i2c transactions via the SLIMpro processor.

V3 Change:
- Add ACPI support
- Fix previous comments.

Feng Kan (4):
  i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform
  i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver
  Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver
documentation
  arm64: dts: add proxy I2C device driver on APM X-Gene platform

 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt  |  15 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 469 +
 5 files changed, 499 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 3/4] Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver documentation

[Feng Kan]

Add APM X-Gene platform SLIMpro I2C driver documentation.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt 
b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
new file mode 100644
index 000..f6b2c20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
@@ -0,0 +1,15 @@
+APM X-Gene SLIMpro Mailbox I2C Driver
+
+An I2C controller accessed over the "SLIMpro" mailbox.
+
+Required properties :
+
+ - compatible : should be "apm,xgene-slimpro-i2c"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 1/4] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 459 +
 3 files changed, 469 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..1ac07d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1082,6 +1082,15 @@ config I2C_CROS_EC_TUNNEL
  connected there. This will work whatever the interface used to
  talk to the EC (SPI, I2C or LPC).
 
+config I2C_XGENE_SLIMPRO
+   tristate "APM X-Gene SoC I2C SLIMpro devices support"
+   depends on ARCH_XGENE && MAILBOX
+   help
+ Enable I2C bus access using the APM X-Gene SoC SLIMpro
+ co-processor. The I2C device access the I2C bus via the X-Gene
+ to SLIMpro (On chip coprocessor) mailbox mechanism.
+ If unsure, say N.
+
 config SCx200_ACB
tristate "Geode ACCESS.bus support"
depends on X86_32 && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..9cf9c4b 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
+obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
new file mode 100644
index 000..afe4cf2
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -0,0 +1,459 @@
+/*
+ * X-Gene SLIMpro I2C Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Author: Hieu Le 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This driver provides support for X-Gene SLIMpro I2C device access
+ * using the APM X-Gene SLIMpro mailbox driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
+#define MAILBOX_I2C_INDEX  0
+#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only */
+
+#define SMBUS_CMD_LEN  1
+#define BYTE_DATA  1
+#define WORD_DATA  2
+#define BLOCK_DATA 3
+
+#define SLIMPRO_IIC_I2C_PROTOCOL   0
+#define SLIMPRO_IIC_SMB_PROTOCOL   1
+
+#define SLIMPRO_IIC_READ   0
+#define SLIMPRO_IIC_WRITE  1
+
+#define IIC_SMB_WITHOUT_DATA_LEN   0
+#define IIC_SMB_WITH_DATA_LEN  1
+
+#define SLIMPRO_DEBUG_MSG  0
+#define SLIMPRO_MSG_TYPE_SHIFT 28
+#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
+#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
+#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
+#define SLIMPRO_IIC_DEV_SHIFT  23
+#define SLIMPRO_IIC_DEV_MASK   0x0080U
+#define SLIMPRO_IIC_DEVID_SHIFT13
+#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
+#define SLIMPRO_IIC_RW_SHIFT   12
+#define SLIMPRO_IIC_RW_MASK0x1000U
+#define SLIMPRO_IIC_PROTO_SHIFT11
+#define SLIMPRO_IIC_PROTO_MASK 0x0800U
+#define SLIMPRO_IIC_ADDRLEN_SHIFT  8
+#define SLIMPRO_IIC_ADDRLEN_MASK   0x0700U
+#define SLIMPRO_IIC_DATALEN_SHIFT  0
+#define SLIMPRO_IIC_DATALEN_MASK   0x00FFU
+
+/*
+ * SLIMpro I2C message encode
+ *
+ * dev - Controller number (0-based)
+ * chip- I2C chip address
+ * op  - SLIMPRO_IIC_READ or SLIMPRO_IIC_WRITE
+ * proto   - SLIMPRO_IIC_SMB_PROTOCOL or SLIMPRO_IIC_I2C_PROTOCOL
+ * addrlen - Length of the address field
+ * datalen - Length of the data field
+ */
+#define SLIMPRO_IIC_ENCODE_MSG(dev, chip, op, proto, addrl

[PATCH V2 1/4] mailbox: add support for APM X-Gene platform mailbox driver

[Feng Kan]

Add support for APM X-Gene platform mailbox driver.

Signed-off-by: Feng Kan 
---
 drivers/mailbox/Kconfig |  10 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c | 261 
 3 files changed, 273 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..64120cc 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,14 @@ config ALTERA_MBOX
  An implementation of the Altera Mailbox soft core. It is used
  to send message between processors. Say Y here if you want to use the
  Altera mailbox support.
+
+config XGENE_SLIMPRO_MBOX
+   tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
+   depends on ARCH_XGENE
+   help
+ An implementation of the APM X-Gene Interprocessor Communication
+ Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
+ It is used to send short messages between ARM64-bit cores and
+ the SLIMpro Management Engine, primarily for PM. Say Y here if you
+ want to use the APM X-Gene SLIMpro IPCM support.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..1e0bed5 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX)  += omap-mailbox.o
 obj-$(CONFIG_PCC)  += pcc.o
 
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
+
+obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
new file mode 100644
index 000..49370e5
--- /dev/null
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -0,0 +1,261 @@
+/*
+ * APM X-Gene SLIMpro MailBox Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan f...@apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MBOX_CON_NAME  "slimpro-mbox"
+#define MBOX_REG_SET_OFFSET0x1000
+#define MBOX_CNT   8
+#define MBOX_STATUS_AVAIL_MASK BIT(16)
+#define MBOX_STATUS_ACK_MASK   BIT(0)
+
+/* Configuration and Status Registers */
+#define REG_DB_IN  0x00
+#define REG_DB_DIN00x04
+#define REG_DB_DIN10x08
+#define REG_DB_OUT 0x10
+#define REG_DB_DOUT0   0x14
+#define REG_DB_DOUT1   0x18
+#define REG_DB_STAT0x20
+#define REG_DB_STATMASK0x24
+
+struct slimpro_mbox_chan {
+   struct device *dev;
+   struct mbox_chan *chan;
+   void __iomem *reg;
+   int id;
+   int irq;
+   u32 rx_msg[3];
+};
+
+struct slimpro_mbox {
+   struct mbox_controller mb_ctrl;
+   struct slimpro_mbox_chan mc[MBOX_CNT];
+   struct mbox_chan chans[MBOX_CNT];
+};
+
+static inline void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 
*msg)
+{
+   writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
+   writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
+   writel(msg[0], mb_chan->reg + REG_DB_OUT);
+}
+
+static inline void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
+{
+   mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
+   mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
+   mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
+}
+
+static void mb_chan_enable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(mb_chan->reg + REG_DB_STATMASK);
+
+   val &= ~mask;
+
+   writel(val, mb_chan->reg + REG_DB_STATMASK);
+}
+
+static void mb_chan_disable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(mb_chan->reg + REG_DB_STATMASK);
+
+   val |= mask;
+
+   writel(val, mb_chan->reg + REG_DB_STATMASK);
+}
+
+static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
+{
+   u32 val = readl(mb_chan->reg + REG_DB_STAT);
+
+   if (val & MBOX_STATUS_ACK_MASK) {
+   writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
+   return 1;
+   }
+   re

[PATCH V2 2/4] mailbox: xgene: add ACPI support for X-Gene mailbox driver

[Feng Kan]

Add ACPI support for APM X-Gene mailbox driver.

Signed-off-by: Feng Kan 
---
 drivers/mailbox/mailbox-xgene-slimpro.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
index 49370e5..890f95b 100644
--- a/drivers/mailbox/mailbox-xgene-slimpro.c
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -18,6 +18,7 @@
  * along with this program; if not, see <http://www.gnu.org/licenses/>.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -240,6 +241,14 @@ static const struct of_device_id slimpro_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, slimpro_of_match);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id slimpro_acpi_ids[] = {
+   {"APMC0D01", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
+
 static struct platform_driver slimpro_mbox_driver = {
.probe  = slimpro_mbox_probe,
.remove = slimpro_mbox_remove,
@@ -247,6 +256,7 @@ static struct platform_driver slimpro_mbox_driver = {
.name = "xgene-slimpro-mbox",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(slimpro_of_match),
+   .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 0/4] APM X-Gene Mailbox driver

[Feng Kan]

This adds the mailbox driver for the APM X-Gene SoC

V2 change
- Add ACPI support
- use defines for reg offset

Feng Kan (4):
  mailbox: add support for APM X-Gene platform mailbox driver
  mailbox: xgene: add ACPI support for X-Gene mailbox driver
  Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts
documentation
  arm64: dts: mailbox device tree node for APM X-Gene platform.

 .../bindings/mailbox/xgene-slimpro-mailbox.txt |  34 +++
 arch/arm64/boot/dts/apm/apm-storm.dtsi |  14 ++
 drivers/mailbox/Kconfig|  10 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c| 271 +
 5 files changed, 331 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 3/4] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation

[Feng Kan]

This adds the APM X-Gene SLIMpro mailbox device tree node documentation.

Signed-off-by: Feng Kan 
---
 .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
new file mode 100644
index 000..d02a3d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
@@ -0,0 +1,34 @@
+The APM X-Gene SLIMpro mailbox is used to communicate messages between
+the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+interrupt based door bell mechanism and can exchange simple messages using the
+internal registers.
+
+There are total of 7 interrupts in this mailbox. Each used for an individual
+door bell (or mailbox channel).
+
+Required properties:
+- compatible:  Should be as "apm, xgene-slimpro-mbox".
+
+- reg: Contain the mailbox register address range.
+
+- interrupts:  7 interrupts must start from 0 to 6, interrupt 0 define the
+   the interrupt for mailbox channel 0 and interrupt 1 for
+   mailbox channel 1 and so likewise for the reminder.
+
+- #mbox-cells: only one to specify the mailbox channel number.
+
+Example:
+
+Mailbox Node:
+   slimpro-mbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 4/4] arm64: dts: mailbox device tree node for APM X-Gene platform.

[Feng Kan]

Mailbox device tree node for APM X-Gene platform.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index c8d3e0e..92e7b6b 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -489,6 +489,20 @@
clocks = <&pcie4clk 0>;
};
 
+   mailbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   <0x0 0x7 0x4>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] mailbox: add support for APM X-Gene platform mailbox driver

[Feng Kan]

On Tue, Apr 21, 2015 at 12:42 AM, Jassi Brar  wrote:
> On Wed, Feb 18, 2015 at 8:40 AM, Feng Kan  wrote:
>
>> +#define MBOX_CON_NAME  "slimpro-mbox"
>> +#define MBOX_REG_SET_OFFSET0x1000
>> +#define MBOX_CNT   8
>> +#define MBOX_STATUS_AVAIL_MASK 0x0001
>> +#define MBOX_STATUS_ACK_MASK   0x0001
>>
> Nit: BIT(16) and BIT(0) is more readable
will fix
>
>> +/* Configuration and Status Registers */
>> +struct slimpro_mbox_reg {
>> +   u32 in;
>> +   u32 din0;
>> +   u32 din1;
>> +   u32 rsvd1;
>> +   u32 out;
>> +   u32 dout0;
>> +   u32 dout1;
>> +   u32 rsvd2;
>> +   u32 status;
>> +   u32 statusmask;
>> +};
>> +
> Why not the normal way of defining offset macros, like most drivers do?
I personally don't prefer one way over another, let me know if you want me
to change to use defines.
>
>> +struct slimpro_mbox_chan {
>> +   struct device *dev;
>> +   struct mbox_chan *chan;
>> +   struct slimpro_mbox_reg __iomem *reg;
>> +   int id;
>> +   int irq;
>> +   u32 rx_msg[3];
>> +};
>> +
>> +struct slimpro_mbox {
>> +   struct mbox_controller mb_ctrl;
>> +   struct slimpro_mbox_chan mc[MBOX_CNT];
>> +   struct mbox_chan chans[MBOX_CNT];
>> +};
>> +
>> +static struct slimpro_mbox_chan *to_slimpro_mbox_chan(struct mbox_chan 
>> *chan)
>> +{
>> +   if (!chan || !chan->con_priv)
>> +   return NULL;
> This seems un-necessary. Anyway you don't care for NULL returned :)
> Probably just kill this function?
done
>
>> +
>> +   return (struct slimpro_mbox_chan *)chan->con_priv;
>> +}
>> +
>> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
>> +{
>> +   writel(msg[1], &mb_chan->reg->dout0);
>> +   writel(msg[2], &mb_chan->reg->dout1);
>> +   writel(msg[0], &mb_chan->reg->out);
>> +}
>> +
>> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +   mb_chan->rx_msg[1] = readl(&mb_chan->reg->din0);
>> +   mb_chan->rx_msg[2] = readl(&mb_chan->reg->din1);
>> +   mb_chan->rx_msg[0] = readl(&mb_chan->reg->in);
>> +}
>> +
> maybe move the send/recv function inline the caller?
done
>
>> +static void mb_chan_enable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
>> +{
>> +   u32 val = readl(&mb_chan->reg->statusmask);
>> +
>> +   val &= ~mask;
>> +
>> +   writel(val, &mb_chan->reg->statusmask);
>> +}
>> +
>> +static void mb_chan_disable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
>> +{
>> +   u32 val = readl(&mb_chan->reg->statusmask);
>> +
>> +   val |= mask;
>> +
>> +   writel(val, &mb_chan->reg->statusmask);
>> +}
>> +
>> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +   u32 val = readl(&mb_chan->reg->status);
>> +
>> +   if (val & MBOX_STATUS_ACK_MASK) {
>> +   writel(MBOX_STATUS_ACK_MASK, &mb_chan->reg->status);
>> +   return 1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +   u32 val = readl(&mb_chan->reg->status);
>> +
>> +   if (val & MBOX_STATUS_AVAIL_MASK) {
>> +   mb_chan_recv_msg(mb_chan);
>> +   writel(MBOX_STATUS_AVAIL_MASK, &mb_chan->reg->status);
>> +   return 1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
>> +{
>> +   struct slimpro_mbox_chan *mb_chan = id;
>> +
>> +   if (mb_chan_status_ack(mb_chan))
>> +   mbox_chan_txdone(mb_chan->chan, 0);
>> +
>> +   if (mb_chan_status_avail(mb_chan)) {
>> +   mb_chan_recv_msg(mb_chan)
>>
> you already did this in mb_chan_status_avail()  is it needed?
removed
>
>> +   mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
>> +   }
>> +
>> +   return IRQ_HANDLED;
>> +}
>> +
>> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
>> +{
>> +   struct slimpro_mbox_chan *mb_chan 

Re: [PATCH V2 RESEND] mailbox: add ACPI support for mailbox framework

[Feng Kan]

On Wed, Apr 8, 2015 at 4:58 PM, Feng Kan  wrote:
> This will add support for ACPI parsing of the mboxes attribute
> when booting with ACPI table. The client will have a attribute
> mimic the dts call "mboxes". In the ACPI case, the client will
> mark "mboxes" with the ACPI reference of the mbox it wishes to
> use.
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package (2) {"mboxes", Package(){"^^MBOXREF, index"}}
> }
> })
>
> Signed-off-by: Feng Kan 
> ---
>  V2 CHANGE:
> - change to use ACPI reference rather than use ACPI HID directly.
> - consolidate to use one single xlate function
> - fix code to accept use of index
>
>  drivers/mailbox/mailbox.c  | 105 
> ++---
>  include/linux/mailbox_controller.h |   6 +--
>  2 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index 19b491d..3bb981c 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -9,6 +9,7 @@
>   * published by the Free Software Foundation.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
>  }
>  EXPORT_SYMBOL_GPL(mbox_send_message);
>
> +#ifdef CONFIG_ACPI
> +static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
> +{
> +   struct acpi_device *acpi_dev;
> +   struct mbox_controller *mbox;
> +   struct mbox_chan *chan;
> +   int status;
> +   struct acpi_reference_args args;
> +
> +   status = acpi_dev_get_property_reference(ACPI_COMPANION(dev), 
> "mboxes",
> +index, &args);
> +   if (ACPI_FAILURE(status)) {
> +   dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
> +   return ERR_PTR(-ENODEV);
> +   }
> +   acpi_dev = args.adev;
> +
> +   chan = NULL;
> +   list_for_each_entry(mbox, &mbox_cons, node)
> +   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
> +   chan = mbox->chan_xlate(mbox, args.args[0]);
> +   break;
> +   }
> +
> +   return chan;
> +}
> +#endif
> +
> +static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
> +{
> +   struct of_phandle_args spec;
> +   struct mbox_controller *mbox;
> +   struct mbox_chan *chan;
> +
> +   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> +  "#mbox-cells", index, &spec)) {
> +   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", 
> __func__);
> +   return ERR_PTR(-ENODEV);
> +   }
> +
> +   chan = NULL;
> +   list_for_each_entry(mbox, &mbox_cons, node)
> +   if (mbox->dev->of_node == spec.np) {
> +   chan = mbox->chan_xlate(mbox, spec.args[0]);
> +   break;
> +   }
> +
> +   of_node_put(spec.np);
> +   return chan;
> +}
> +
> +static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
> +{
> +   if (!dev)
> +   return ERR_PTR(-ENODEV);
> +
> +   if (dev->of_node)
> +   return mbox_of_parse_chan(dev, index);
> +#ifdef CONFIG_ACPI
> +   else
> +   return mbox_acpi_parse_chan(dev, index);
> +#endif
> +}
> +
>  /**
>   * mbox_request_channel - Request a mailbox channel.
>   * @cl: Identity of the client requesting the channel.
> @@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
>  struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
>  {
> struct device *dev = cl->dev;
> -   struct mbox_controller *mbox;
> -   struct of_phandle_args spec;
> struct mbox_chan *chan;
> unsigned long flags;
> int ret;
>
> -   if (!dev || !dev->of_node) {
> -   pr_debug("%s: No owner device node\n", __func__);
> -   return ERR_PTR(-ENODEV);
> -   }
> -
> mutex_lock(&con_mutex);
> +   chan = mbox_parse_chan(dev, index);
>
> -   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> -  "#mbox-cells", index, &spec)) {
> -   dev_dbg(de

Re: [PATCH v3 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver

[Feng Kan]

On Fri, Apr 17, 2015 at 5:45 AM, Marc Zyngier  wrote:
> On 17/04/15 13:37, Duc Dang wrote:
>> On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier  wrote:
>>> On 17/04/15 11:00, Duc Dang wrote:
 On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier  wrote:
> On Tue, 14 Apr 2015 19:20:19 +0100
> Duc Dang  wrote:
>
>> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier 
>> wrote:
>>> On 2015-04-11 00:42, Duc Dang wrote:

 On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
  wrote:
>
> On 09/04/15 18:05, Duc Dang wrote:
>>
>> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
>> 16 HW IRQ lines.
>>
>> Signed-off-by: Duc Dang 
>> Signed-off-by: Tanmay Inamdar 
>> ---
>>  drivers/pci/host/Kconfig |   6 +
>>  drivers/pci/host/Makefile|   1 +
>>  drivers/pci/host/pci-xgene-msi.c | 407
>> +++
>>  drivers/pci/host/pci-xgene.c |  21 ++
>>  4 files changed, 435 insertions(+)
>>  create mode 100644 drivers/pci/host/pci-xgene-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 7b892a9..c9b61fa 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -89,11 +89,17 @@ config PCI_XGENE
>> depends on ARCH_XGENE
>> depends on OF
>> select PCIEPORTBUS
>> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> +   select PCI_XGENE_MSI if PCI_MSI
>> help
>>   Say Y here if you want internal PCI support on APM
>> X-Gene SoC. There are 5 internal PCIe ports available. Each port
>> is GEN3 capable
>>   and have varied lanes from x1 to x8.
>>
>> +config PCI_XGENE_MSI
>> +   bool "X-Gene v1 PCIe MSI feature"
>> +   depends on PCI_XGENE && PCI_MSI
>> +
>>  config PCI_LAYERSCAPE
>> bool "Freescale Layerscape PCIe controller"
>> depends on OF && ARM
>> diff --git a/drivers/pci/host/Makefile
>> b/drivers/pci/host/Makefile index e61d91c..f39bde3 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) +=
>> pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o
>> pci-keystone.o obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>> +obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>>  obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>>  obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>> diff --git a/drivers/pci/host/pci-xgene-msi.c
>> b/drivers/pci/host/pci-xgene-msi.c
>> new file mode 100644
>> index 000..4f0ff42
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xgene-msi.c
>> @@ -0,0 +1,407 @@
>> +/*
>> + * APM X-Gene MSI Driver
>> + *
>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
>> + * Author: Tanmay Inamdar 
>> + *Duc Dang 
>> + *
>> + * This program is free software; you can redistribute  it
>> and/or modify it
>> + * under  the terms of  the GNU General  Public License as
>> published by the
>> + * Free Software Foundation;  either version 2 of the  License,
>> or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be
>> useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty
>> of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MSI_INDEX0 0x00
>> +#define MSI_INT0   0x80
>> +
>> +struct xgene_msi_settings {
>> +   u32 index_per_group;
>> +   u32 irqs_per_index;
>> +   u32 nr_msi_vec;
>> +   u32 nr_hw_irqs;
>> +};
>> +
>> +struct xgene_msi {
>> +   struct device_node  *node;
>> +   struct msi_controller   mchip;
>> +   struct irq_domain   *domain;
>> +   struct xgene_msi_settings   *settings;
>> +   u32 msi_addr_lo;
>> +   u32 msi_addr_hi;
>
>
> I'd rather see the mailbox address dire

Re: [PATCH v4 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver

[Feng Kan]

On Sun, Apr 19, 2015 at 12:55 PM, Arnd Bergmann  wrote:
> On Sunday 19 April 2015 11:40:09 Duc Dang wrote:
>> On Fri, Apr 17, 2015 at 7:10 AM, Arnd Bergmann  wrote:
>> > On Friday 17 April 2015 02:50:07 Duc Dang wrote:
>> >> +
>> >> +   /*
>> >> +* MSIINTn (n is 0..F) indicates if there is a pending MSI 
>> >> interrupt
>> >> +* If bit x of this register is set (x is 0..7), one or more 
>> >> interupts
>> >> +* corresponding to MSInIRx is set.
>> >> +*/
>> >> +   grp_select = readl(xgene_msi->msi_regs + MSI_INT0 + (msi_grp << 
>> >> 16));
>> >> +   while (grp_select) {
>> >> +   msir_index = ffs(grp_select) - 1;
>> >> +   /*
>> >> +* Calculate MSInIRx address to read to check for 
>> >> interrupts
>> >> +* (refer to termination address and data assignment
>> >> +* described in xgene_compose_msi_msg function)
>> >> +*/
>> >> +   msir_reg = (msi_grp << 19) + (msir_index << 16);
>> >> +   msir_val = readl(xgene_msi->msi_regs + MSI_IR0 + 
>> >> msir_reg);
>> >> +   while (msir_val) {
>> >> +   intr_index = ffs(msir_val) - 1;
>> >> +   /*
>> >> +* Calculate MSI vector number (refer to the 
>> >> termination
>> >> +* address and data assignment described in
>> >> +* xgene_compose_msi_msg function)
>> >> +*/
>> >> +   hw_irq = (((msir_index * IRQS_PER_IDX) + 
>> >> intr_index) *
>> >> +NR_HW_IRQS) + msi_grp;
>> >> +   virq = irq_find_mapping(xgene_msi->domain, 
>> >> hw_irq);
>> >> +   if (virq != 0)
>> >> +   generic_handle_irq(virq);
>> >> +   msir_val &= ~(1 << intr_index);
>> >> +   processed++;
>> >> +   }
>> >> +   grp_select &= ~(1 << msir_index);
>> >> +   }
>> >>
>> >
>> > As the MSI is forwarded to the GIC here, how do you maintain ordering
>> > between DMA data getting forwarded from the PCI host bridge to RAM
>> > with regard to the MSI handler getting entered from this code?
>>
>> When device perform a DMA transfer, the order of PCIE inbound requests
>> will be like this:
>> 1. DMA data get transferred via PCIe inbound request
>> 2. After devices issue DMA transfer request, the device fires an MSI
>> interrupt by issuing another inbound write to write MSI data to MSI
>> termination address.
>>
>> As these 2 requests are transferred via PCIe bus in order, the DMA
>> data will be all in DDR before the MSI data hit the termination
>> address to trigger the MSI handler in interrupt handler code.
>
> Obviously they appear on the PCI host bridge in order, because that
> is a how PCI works. My question was about what happens then. On a lot
> of SoCs, there is something like an AXI bus that uses posted
> transactions between PCI and RAM, so you have a do a full manual
> syncronization of ongoing PIC DMAs when the MSI catcher signals the
> top-level interrupt. Do you have a bus between PCI and RAM that does
> not require this, or does the MSI catcher have logic to flush all DMAs?

Our hardware has an automatic mechanism to flush the content to DRAM before the
MSI write is committed.

>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver

[Feng Kan]

Hi Marc:

Is there any plans to support ACPI for GICv2m MSI? Both this driver and the
GICv2m seems to support OF model of discovery for msi controller. X-Gene1
uses this driver and X-Gene2 uses GICv2m, there needs to be a way to
associate msi controller with the PCIe bus. I haven't
found a standard way of doing finding "msi-parent" for ACPI. Do you have
any suggestion.

Sorry for top posting.


On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier  wrote:
> On 09/04/15 18:05, Duc Dang wrote:
>> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
>> 16 HW IRQ lines.
>>
>> Signed-off-by: Duc Dang 
>> Signed-off-by: Tanmay Inamdar 
>> ---
>>  drivers/pci/host/Kconfig |   6 +
>>  drivers/pci/host/Makefile|   1 +
>>  drivers/pci/host/pci-xgene-msi.c | 407 
>> +++
>>  drivers/pci/host/pci-xgene.c |  21 ++
>>  4 files changed, 435 insertions(+)
>>  create mode 100644 drivers/pci/host/pci-xgene-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 7b892a9..c9b61fa 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -89,11 +89,17 @@ config PCI_XGENE
>> depends on ARCH_XGENE
>> depends on OF
>> select PCIEPORTBUS
>> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> +   select PCI_XGENE_MSI if PCI_MSI
>> help
>>   Say Y here if you want internal PCI support on APM X-Gene SoC.
>>   There are 5 internal PCIe ports available. Each port is GEN3 
>> capable
>>   and have varied lanes from x1 to x8.
>>
>> +config PCI_XGENE_MSI
>> +   bool "X-Gene v1 PCIe MSI feature"
>> +   depends on PCI_XGENE && PCI_MSI
>> +
>>  config PCI_LAYERSCAPE
>> bool "Freescale Layerscape PCIe controller"
>> depends on OF && ARM
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index e61d91c..f39bde3 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>>  obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>> +obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>>  obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>>  obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>> diff --git a/drivers/pci/host/pci-xgene-msi.c 
>> b/drivers/pci/host/pci-xgene-msi.c
>> new file mode 100644
>> index 000..4f0ff42
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xgene-msi.c
>> @@ -0,0 +1,407 @@
>> +/*
>> + * APM X-Gene MSI Driver
>> + *
>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
>> + * Author: Tanmay Inamdar 
>> + *Duc Dang 
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MSI_INDEX0 0x00
>> +#define MSI_INT0   0x80
>> +
>> +struct xgene_msi_settings {
>> +   u32 index_per_group;
>> +   u32 irqs_per_index;
>> +   u32 nr_msi_vec;
>> +   u32 nr_hw_irqs;
>> +};
>> +
>> +struct xgene_msi {
>> +   struct device_node  *node;
>> +   struct msi_controller   mchip;
>> +   struct irq_domain   *domain;
>> +   struct xgene_msi_settings   *settings;
>> +   u32 msi_addr_lo;
>> +   u32 msi_addr_hi;
>
> I'd rather see the mailbox address directly, and only do the split when
> assigning it to the message (you seem to play all kind of tricks on the
> address anyway).
>
>> +   void __iomem*msi_regs;
>> +   unsigned long   *bitmap;
>> +   struct mutexbitmap_lock;
>> +   int *msi_virqs;
>> +};
>> +
>> +struct xgene_msi_settings storm_msi_settings = {
>> +   .index_per_group= 8,
>> +   .irqs_per_index = 21,
>> +   .nr_msi_vec = 2688,
>> +   .nr_hw_irqs = 16,
>> +};
>
> It would really help understanding how index, group and hw irq lines are
> structured. nr_msi_vec is obviously the product of these three numbers,
> so maybe you can loose it (we have computers, remember... ;-).
>
> Do you expect more than this single "storm" implementation? If so, maybe
> they should be described in the DT. If not, why do w

[PATCH V2 RESEND] mailbox: add ACPI support for mailbox framework

[Feng Kan]

This will add support for ACPI parsing of the mboxes attribute
when booting with ACPI table. The client will have a attribute
mimic the dts call "mboxes". In the ACPI case, the client will
mark "mboxes" with the ACPI reference of the mbox it wishes to
use.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) {"mboxes", Package(){"^^MBOXREF, index"}}
    }
})

Signed-off-by: Feng Kan 
---
 V2 CHANGE:
- change to use ACPI reference rather than use ACPI HID directly.
- consolidate to use one single xlate function
- fix code to accept use of index

 drivers/mailbox/mailbox.c  | 105 ++---
 include/linux/mailbox_controller.h |   6 +--
 2 files changed, 76 insertions(+), 35 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..3bb981c 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 }
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
+#ifdef CONFIG_ACPI
+static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
+{
+   struct acpi_device *acpi_dev;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+   int status;
+   struct acpi_reference_args args;
+
+   status = acpi_dev_get_property_reference(ACPI_COMPANION(dev), "mboxes",
+index, &args);
+   if (ACPI_FAILURE(status)) {
+   dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
+   return ERR_PTR(-ENODEV);
+   }
+   acpi_dev = args.adev;
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
+   chan = mbox->chan_xlate(mbox, args.args[0]);
+   break;
+   }
+
+   return chan;
+}
+#endif
+
+static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
+{
+   struct of_phandle_args spec;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+
+   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
+  "#mbox-cells", index, &spec)) {
+   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
+   return ERR_PTR(-ENODEV);
+   }
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (mbox->dev->of_node == spec.np) {
+   chan = mbox->chan_xlate(mbox, spec.args[0]);
+   break;
+   }
+
+   of_node_put(spec.np);
+   return chan;
+}
+
+static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
+{
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   if (dev->of_node)
+   return mbox_of_parse_chan(dev, index);
+#ifdef CONFIG_ACPI
+   else
+   return mbox_acpi_parse_chan(dev, index);
+#endif
+}
+
 /**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
@@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 {
struct device *dev = cl->dev;
-   struct mbox_controller *mbox;
-   struct of_phandle_args spec;
struct mbox_chan *chan;
unsigned long flags;
int ret;
 
-   if (!dev || !dev->of_node) {
-   pr_debug("%s: No owner device node\n", __func__);
-   return ERR_PTR(-ENODEV);
-   }
-
mutex_lock(&con_mutex);
+   chan = mbox_parse_chan(dev, index);
 
-   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
-  "#mbox-cells", index, &spec)) {
-   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
-   mutex_unlock(&con_mutex);
-   return ERR_PTR(-ENODEV);
-   }
-
-   chan = NULL;
-   list_for_each_entry(mbox, &mbox_cons, node)
-   if (mbox->dev->of_node == spec.np) {
-   chan = mbox->of_xlate(mbox, &spec);
-   break;
-   }
-
-   of_node_put(spec.np);
-
-   if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+   if (!chan || chan->cl ||
+   !try_module_get(chan->mbox->dev->driver->owner)) {
  

Re: [PATCH V2] mailbox: add ACPI support for mailbox framework

[Feng Kan]

Please disregard this, I messed up on the indexing. Will resubmit after fixing.

On Tue, Apr 7, 2015 at 4:34 PM, Feng Kan  wrote:
> This will add support for ACPI parsing of the mboxes attribute
> when booting with ACPI table. The client will have a attribute
> mimic the dts call "mboxes". In the ACPI case, the client will
> mark "mboxes" with the ACPI reference of the mbox it wishes to
> use.
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package (2) {"mboxes", "^^MBOXREF"},
> }
> })
>
> Signed-off-by: Feng Kan 
> ---
>  V2 CHANGE:
> - change to use ACPI reference rather than use ACPI HID directly.
> - consolidate to use one single xlate function
>
>
>  drivers/mailbox/mailbox.c  | 105 
> ++---
>  include/linux/mailbox_controller.h |   6 +--
>  2 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index 19b491d..8359f2e 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -9,6 +9,7 @@
>   * published by the Free Software Foundation.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
>  }
>  EXPORT_SYMBOL_GPL(mbox_send_message);
>
> +#ifdef CONFIG_ACPI
> +static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
> +{
> +   struct acpi_device *acpi_dev;
> +   struct mbox_controller *mbox;
> +   struct mbox_chan *chan;
> +   int status;
> +   struct acpi_reference_args args;
> +
> +   status = acpi_dev_get_property_reference(ACPI_COMPANION(dev), 
> "mboxes",
> +0, &args);
> +   if (ACPI_FAILURE(status)) {
> +   dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
> +   return ERR_PTR(-ENODEV);
> +   }
> +   acpi_dev = args.adev;
> +
> +   chan = NULL;
> +   list_for_each_entry(mbox, &mbox_cons, node)
> +   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
> +   chan = mbox->chan_xlate(mbox, index);
> +   break;
> +   }
> +
> +   return chan;
> +}
> +#endif
> +
> +static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
> +{
> +   struct of_phandle_args spec;
> +   struct mbox_controller *mbox;
> +   struct mbox_chan *chan;
> +
> +   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> +  "#mbox-cells", index, &spec)) {
> +   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", 
> __func__);
> +   return ERR_PTR(-ENODEV);
> +   }
> +
> +   chan = NULL;
> +   list_for_each_entry(mbox, &mbox_cons, node)
> +   if (mbox->dev->of_node == spec.np) {
> +   chan = mbox->chan_xlate(mbox, spec.args[0]);
> +   break;
> +   }
> +
> +   of_node_put(spec.np);
> +   return chan;
> +}
> +
> +static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
> +{
> +   if (!dev)
> +   return ERR_PTR(-ENODEV);
> +
> +   if (dev->of_node)
> +   return mbox_of_parse_chan(dev, index);
> +#ifdef CONFIG_ACPI
> +   else
> +   return mbox_acpi_parse_chan(dev, index);
> +#endif
> +}
> +
>  /**
>   * mbox_request_channel - Request a mailbox channel.
>   * @cl: Identity of the client requesting the channel.
> @@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
>  struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
>  {
> struct device *dev = cl->dev;
> -   struct mbox_controller *mbox;
> -   struct of_phandle_args spec;
> struct mbox_chan *chan;
> unsigned long flags;
> int ret;
>
> -   if (!dev || !dev->of_node) {
> -   pr_debug("%s: No owner device node\n", __func__);
> -   return ERR_PTR(-ENODEV);
> -   }
> -
> mutex_lock(&con_mutex);
> +   chan = mbox_parse_chan(dev, index);
>
> -   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
> -  "#mbox-cells", index, &spec)) 

[PATCH V2] mailbox: add ACPI support for mailbox framework

[Feng Kan]

This will add support for ACPI parsing of the mboxes attribute
when booting with ACPI table. The client will have a attribute
mimic the dts call "mboxes". In the ACPI case, the client will
mark "mboxes" with the ACPI reference of the mbox it wishes to
use.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) {"mboxes", "^^MBOXREF"},
    }
})

Signed-off-by: Feng Kan 
---
 V2 CHANGE:
- change to use ACPI reference rather than use ACPI HID directly.
- consolidate to use one single xlate function


 drivers/mailbox/mailbox.c  | 105 ++---
 include/linux/mailbox_controller.h |   6 +--
 2 files changed, 76 insertions(+), 35 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..8359f2e 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -278,6 +279,70 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 }
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
+#ifdef CONFIG_ACPI
+static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
+{
+   struct acpi_device *acpi_dev;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+   int status;
+   struct acpi_reference_args args;
+
+   status = acpi_dev_get_property_reference(ACPI_COMPANION(dev), "mboxes",
+0, &args);
+   if (ACPI_FAILURE(status)) {
+   dev_dbg(dev, "mbox: no matching mbox found in ACPI table\n");
+   return ERR_PTR(-ENODEV);
+   }
+   acpi_dev = args.adev;
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
+   chan = mbox->chan_xlate(mbox, index);
+   break;
+   }
+
+   return chan;
+}
+#endif
+
+static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
+{
+   struct of_phandle_args spec;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+
+   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
+  "#mbox-cells", index, &spec)) {
+   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
+   return ERR_PTR(-ENODEV);
+   }
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (mbox->dev->of_node == spec.np) {
+   chan = mbox->chan_xlate(mbox, spec.args[0]);
+   break;
+   }
+
+   of_node_put(spec.np);
+   return chan;
+}
+
+static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
+{
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   if (dev->of_node)
+   return mbox_of_parse_chan(dev, index);
+#ifdef CONFIG_ACPI
+   else
+   return mbox_acpi_parse_chan(dev, index);
+#endif
+}
+
 /**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
@@ -298,36 +363,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 {
struct device *dev = cl->dev;
-   struct mbox_controller *mbox;
-   struct of_phandle_args spec;
struct mbox_chan *chan;
unsigned long flags;
int ret;
 
-   if (!dev || !dev->of_node) {
-   pr_debug("%s: No owner device node\n", __func__);
-   return ERR_PTR(-ENODEV);
-   }
-
mutex_lock(&con_mutex);
+   chan = mbox_parse_chan(dev, index);
 
-   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
-  "#mbox-cells", index, &spec)) {
-   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
-   mutex_unlock(&con_mutex);
-   return ERR_PTR(-ENODEV);
-   }
-
-   chan = NULL;
-   list_for_each_entry(mbox, &mbox_cons, node)
-   if (mbox->dev->of_node == spec.np) {
-   chan = mbox->of_xlate(mbox, &spec);
-   break;
-   }
-
-   of_node_put(spec.np);
-
-   if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+   if (!chan || chan->cl ||
+   !try_module_get(chan->mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mute

Re: [PATCH] mailbox: add ACPI support for mailbox framework

[Feng Kan]

On Tue, Apr 7, 2015 at 4:37 AM, Rafael J. Wysocki  wrote:
> On Tuesday, April 07, 2015 11:41:43 AM Mika Westerberg wrote:
>> On Thu, Apr 02, 2015 at 11:04:24AM -0700, Feng Kan wrote:
>> > On Thu, Apr 2, 2015 at 2:07 AM, Mika Westerberg
>> >  wrote:
>> > > On Wed, Apr 01, 2015 at 10:01:45AM -0700, Feng Kan wrote:
>> > >> On Wed, Apr 1, 2015 at 12:45 AM, Mika Westerberg
>> > >>  wrote:
>> > >> > On Tue, Mar 31, 2015 at 02:18:00PM -0700, Feng Kan wrote:
>> > >> >> This will add support for ACPI parsing of the mboxes attribute
>> > >> >> when booting with ACPI table. The client will have a attribute
>> > >> >> mimic the dts call "mboxes". In the ACPI case, the client will
>> > >> >> mark "mboxes" with the ACPI HID of the mbox it wishes to use.
>> > >> >>
>> > >> >>   Name (_DSD, Package () {
>> > >> >>   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> > >> >>   Package () {
>> > >> >>   Package (2) {"mboxes", "ACPIHID"},
>> > >> >>   }
>> > >> >>   })
>> > >> >
>> > >> > Instead of this, why not match against the DT compatible property?
>> > >> >
>> > >> > Name (_HID, "PRP0001")
>> > >> >
>> > >> > Name (_DSD, Package () {
>> > >> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> > >> > Package () {
>> > >> > Package (2) {"compatible", 
>> > >> > "your-dt-compatible-string"},
>> > >> > }
>> > >> > })
>> > >> I think my description was not clear enough. The _DSD section is not
>> > >> meant to identify the mailbox driver, but used by the acpi node that 
>> > >> will
>> > >> request the mailbox channel. The dts version would be as below.
>> > >>
>> > >>mailbox: {
>> > >>}
>> > >>
>> > >>user-mbox: {
>> > >>   mboxes: <&mailbox 0>
>> > >>}
>> > >>
>> > >> The mboxes attribute in the user of the mbox has to specify the HID of 
>> > >> the
>> > >> mbox in order to retrieve channel pointer.
>> > >
>> > > Okay, then I think you can use reference instead of _HID, like
>> > >
>> > > // The mailbox device
>> > > Device (MLBX) {
>> > > }
>> > >
>> > > // User-mbox device
>> > > Device (USBX) {
>> > > Name (_DSD, Package () {
>> > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> > > Package () {
>> > > Package () {"mboxes", Package () 
>> > > {^^MLBX, 0}}),
>> > > }
>> > > })
>> > > }
>> >
>> > Thanks, will try this. A side question on your previous reply. Would you
>> > prefer a new driver using the PRP0001 or an actual proper HID.
>>
>> If you have existing DT bindings for this, then PRP0001 is fine.
>> Otherwise you should use the proper _HID for this particular device.
>
> To be precise, PRP0001 specifically means "Use the 'compatible' property
> to find the driver for this device", so if *that* is what you want to do,
I am a bit uneasy about this. I understand the application of this. For a system
that is both DT and ACPI compatible, this would open up a flood of PRP0001
device drivers. What is the guideline here? Is this PRP0001 only exist
to support legacy devices that do not have a proper HID.

> you can use PRP0001 as the _HID.  For Windows (and such) compatibility, you
> can provide a _CID whith a (list of) proper device ID(s) in addition to that.
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mailbox: add ACPI support for mailbox framework

[Feng Kan]

On Thu, Apr 2, 2015 at 2:07 AM, Mika Westerberg
 wrote:
> On Wed, Apr 01, 2015 at 10:01:45AM -0700, Feng Kan wrote:
>> On Wed, Apr 1, 2015 at 12:45 AM, Mika Westerberg
>>  wrote:
>> > On Tue, Mar 31, 2015 at 02:18:00PM -0700, Feng Kan wrote:
>> >> This will add support for ACPI parsing of the mboxes attribute
>> >> when booting with ACPI table. The client will have a attribute
>> >> mimic the dts call "mboxes". In the ACPI case, the client will
>> >> mark "mboxes" with the ACPI HID of the mbox it wishes to use.
>> >>
>> >>   Name (_DSD, Package () {
>> >>   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> >>   Package () {
>> >>   Package (2) {"mboxes", "ACPIHID"},
>> >>   }
>> >>   })
>> >
>> > Instead of this, why not match against the DT compatible property?
>> >
>> > Name (_HID, "PRP0001")
>> >
>> > Name (_DSD, Package () {
>> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> > Package () {
>> > Package (2) {"compatible", 
>> > "your-dt-compatible-string"},
>> > }
>> > })
>> I think my description was not clear enough. The _DSD section is not
>> meant to identify the mailbox driver, but used by the acpi node that will
>> request the mailbox channel. The dts version would be as below.
>>
>>mailbox: {
>>}
>>
>>user-mbox: {
>>   mboxes: <&mailbox 0>
>>}
>>
>> The mboxes attribute in the user of the mbox has to specify the HID of the
>> mbox in order to retrieve channel pointer.
>
> Okay, then I think you can use reference instead of _HID, like
>
> // The mailbox device
> Device (MLBX) {
> }
>
> // User-mbox device
> Device (USBX) {
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"mboxes", Package () {^^MLBX, 
> 0}}),
> }
> })
> }

Thanks, will try this. A side question on your previous reply. Would you
prefer a new driver using the PRP0001 or an actual proper HID.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

This patch adds the support for APM Merlin board. The Merlin board
is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
SATA and Serial.

Signed-off-by: Feng Kan 
---
  V3 Change:
- Add PCIe 
- Add merline to makefile in dts/apm directory

  V2 Change:
- Add dma-range definition

  V1 Change:
- add memreserve for spintable.
- remove clkfreq attribute
- update spin location, although it is done by bootloader.
- remove msi reg entry
- add chosen for stdout path
 arch/arm64/boot/dts/apm/Makefile   |   1 +
 arch/arm64/boot/dts/apm/apm-merlin.dts |  42 ++
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 216 +
 3 files changed, 259 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
 create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

diff --git a/arch/arm64/boot/dts/apm/Makefile b/arch/arm64/boot/dts/apm/Makefile
index a2afabb..c75f17a 100644
--- a/arch/arm64/boot/dts/apm/Makefile
+++ b/arch/arm64/boot/dts/apm/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
+dtb-$(CONFIG_ARCH_XGENE) += apm-merlin.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/apm/apm-merlin.dts 
b/arch/arm64/boot/dts/apm/apm-merlin.dts
new file mode 100644
index 000..2480baf
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-merlin.dts
@@ -0,0 +1,42 @@
+/*
+ * dts file for AppliedMicro (APM) Merlin Board
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "apm-shadowcat.dtsi"
+
+/ {
+   model = "APM X-Gene Merlin board";
+   compatible = "apm,merlin", "apm,xgene-shadowcat";
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   reg = < 0x1 0x 0x0 0x8000 >;
+   };
+};
+
+&serial0 {
+   status = "ok";
+};
+&pcie0 {
+   status = "ok";
+};
+&sata1 {
+   status = "ok";
+};
+&sata2 {
+   status = "ok";
+};
+&sata3 {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
new file mode 100644
index 000..af9bb1d
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -0,0 +1,216 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Shadowcat SOC
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/ {
+   compatible = "apm,xgene-shadowcat";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@000 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x000>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@001 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x001>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@200 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8"

Re: [PATCH] mailbox: add ACPI support for mailbox framework

[Feng Kan]

On Wed, Apr 1, 2015 at 12:45 AM, Mika Westerberg
 wrote:
> On Tue, Mar 31, 2015 at 02:18:00PM -0700, Feng Kan wrote:
>> This will add support for ACPI parsing of the mboxes attribute
>> when booting with ACPI table. The client will have a attribute
>> mimic the dts call "mboxes". In the ACPI case, the client will
>> mark "mboxes" with the ACPI HID of the mbox it wishes to use.
>>
>>   Name (_DSD, Package () {
>>   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>   Package () {
>>   Package (2) {"mboxes", "ACPIHID"},
>>   }
>>   })
>
> Instead of this, why not match against the DT compatible property?
>
> Name (_HID, "PRP0001")
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package (2) {"compatible", 
> "your-dt-compatible-string"},
> }
> })
I think my description was not clear enough. The _DSD section is not
meant to identify the mailbox driver, but used by the acpi node that will
request the mailbox channel. The dts version would be as below.

   mailbox: {
   }

   user-mbox: {
  mboxes: <&mailbox 0>
   }

The mboxes attribute in the user of the mbox has to specify the HID of the
mbox in order to retrieve channel pointer.

>
> This all will be done for you automatically with zero changes in the
> code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mailbox: add ACPI support for mailbox framework

[Feng Kan]

This will add support for ACPI parsing of the mboxes attribute
when booting with ACPI table. The client will have a attribute
mimic the dts call "mboxes". In the ACPI case, the client will
mark "mboxes" with the ACPI HID of the mbox it wishes to use.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) {"mboxes", "ACPIHID"},
    }
})

Signed-off-by: Feng Kan 
---
 drivers/mailbox/mailbox.c  | 121 +
 include/linux/mailbox_controller.h |   2 +
 2 files changed, 99 insertions(+), 24 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..9f2d0e3 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -278,6 +279,87 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 }
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
+static acpi_status
+mbox_acpi_find(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+   struct acpi_device *acpi_dev;
+
+   if (acpi_bus_get_device(handle, &acpi_dev))
+   return AE_OK;
+
+   if (strcmp(acpi_device_hid(acpi_dev), (const char *)context) == 0)
+   *rv = acpi_dev;
+
+   return AE_OK;
+}
+
+static struct mbox_chan *mbox_acpi_parse_chan(struct device *dev, int index)
+{
+   const char *mbox_attr = "mboxes";
+   struct acpi_device *acpi_dev;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+   int status;
+   char *hid_str;
+
+   status = device_property_read_string(dev, mbox_attr,
+(const char **)&hid_str);
+   if (status)
+   return ERR_PTR(-ENODEV);
+
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+ACPI_UINT32_MAX, mbox_acpi_find, NULL,
+(void *)hid_str, (void **)&acpi_dev);
+   if (ACPI_FAILURE(status) || !acpi_dev) {
+   dev_dbg(dev, "mbox: no matching mboxes %s found in ACPI 
table\n",
+   hid_str);
+   return ERR_PTR(-ENODEV);
+   }
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (ACPI_COMPANION(mbox->dev) == acpi_dev) {
+   chan = mbox->acpi_xlate(mbox, index);
+   break;
+   }
+
+   return chan;
+}
+
+static struct mbox_chan *mbox_of_parse_chan(struct device *dev, int index)
+{
+   struct of_phandle_args spec;
+   struct mbox_controller *mbox;
+   struct mbox_chan *chan;
+
+   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
+  "#mbox-cells", index, &spec)) {
+   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
+   return ERR_PTR(-ENODEV);
+   }
+
+   chan = NULL;
+   list_for_each_entry(mbox, &mbox_cons, node)
+   if (mbox->dev->of_node == spec.np) {
+   chan = mbox->of_xlate(mbox, &spec);
+   break;
+   }
+
+   of_node_put(spec.np);
+   return chan;
+}
+
+static struct mbox_chan *mbox_parse_chan(struct device *dev, int index)
+{
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   if (dev->of_node)
+   return mbox_of_parse_chan(dev, index);
+   else
+   return mbox_acpi_parse_chan(dev, index);
+}
+
 /**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
@@ -298,36 +380,15 @@ EXPORT_SYMBOL_GPL(mbox_send_message);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 {
struct device *dev = cl->dev;
-   struct mbox_controller *mbox;
-   struct of_phandle_args spec;
struct mbox_chan *chan;
unsigned long flags;
int ret;
 
-   if (!dev || !dev->of_node) {
-   pr_debug("%s: No owner device node\n", __func__);
-   return ERR_PTR(-ENODEV);
-   }
-
mutex_lock(&con_mutex);
+   chan = mbox_parse_chan(dev, index);
 
-   if (of_parse_phandle_with_args(dev->of_node, "mboxes",
-  "#mbox-cells", index, &spec)) {
-   dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__);
-   mutex_unlock(&con_mutex);
-   return ERR_PTR(-ENODEV);
-   }
-
-   chan = NULL;
-   list_for_each_entry(mbox, &mbox_cons, node)
-   if (mbox-

Re: [PATCH V2 1/3] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

On Mon, Mar 23, 2015 at 11:31 AM, Wolfram Sang  wrote:
> On Wed, Feb 18, 2015 at 11:34:01AM -0800, Feng Kan wrote:
>> Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
>> device driver use the SLIMpro Mailbox driver to tunnel message to
>> the SLIMpro coprocessor to do the work of accessing I2C components.
>>
>> Signed-off-by: Feng Kan 
>> Signed-off-by: Hieu Le 
>
> Sigh, I lost my first review, so here we go again...
> It looks mostly good. Using checkpatch with '--strict' will show some
> whitespace issues. Please fix these.
>
>> +config I2C_XGENE_SLIMPRO
>> + tristate "APM X-Gene SoC I2C SLIMpro devices support"
>> + depends on ARCH_XGENE && MAILBOX
>
> COMPILE_TEST?
>
>> +static int start_i2c_msg_xfer(struct slimpro_i2c_dev *ctx)
>> +{
>> + if (ctx->mbox_client.tx_block) {
>> + if (!wait_for_completion_timeout(&ctx->rd_complete,
>> +  msecs_to_jiffies
>> +  (MAILBOX_OP_TIMEOUT)))
>
> Don't be too strict with the 80 char limit IMHO. I think it is more
> readable to combine the last two lines into one.
>
>> + msg[0] = SLIMPRO_IIC_ENCODE_MSG(SLIMPRO_IIC_BUS, chip,
>> + SLIMPRO_IIC_READ, protocol, addrlen,
>> + readlen);
>
> ditto
>
>> + msg[0] = SLIMPRO_IIC_ENCODE_MSG(SLIMPRO_IIC_BUS, chip,
>> + SLIMPRO_IIC_WRITE, protocol, addrlen,
>> + writelen);
>
> ditto
>
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, readlen,
>> +DMA_FROM_DEVICE);
>
> The device should be the device of the dma channel.

The device is not visible on linux, DMA is done by the helper processor.
Perhaps you cah give me some idea how to do this. Thanks

>
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, writelen,
>> +DMA_TO_DEVICE);
>
> ditto
>
>> + rc = dma_mapping_error(ctx->dev, paddr);
>> + if (dma_mapping_error(ctx->dev, paddr)) {
>
> if (rc)
>
>> +static struct i2c_algorithm xgene_slimpro_i2c_algorithm = {
>> + .smbus_xfer = xgene_slimpro_i2c_xfer,
>
> Might be a tad less confusing to name this function
> xgene_slimpro_smbus_xfer. You decide.
>
>> + rc = i2c_add_adapter(adapter);
>> + if (rc) {
>> + dev_err(&pdev->dev, "Adapter registeration failed\n");
>> + return rc;
>> + }
>> +
>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> + if (rc)
>> + dev_warn(&pdev->dev, "Unable to set dma mask\n");
>
> Shouldn't that be before i2c_add_adapter?
>
>> +static struct platform_driver xgene_slimpro_i2c_driver = {
>> + .probe  = xgene_slimpro_i2c_probe,
>> + .remove = xgene_slimpro_i2c_remove,
>> + .driver = {
>> + .name   = "xgene-slimpro-i2c",
>> + .of_match_table = of_match_ptr(xgene_slimpro_i2c_id)
>
> You are DT only, do we need of_match_ptr?
>
>> +MODULE_DESCRIPTION("APM X-Gene SLIMpro I2C driver");
>> +MODULE_LICENSE("GPL");
>
> MODULE_AUTHOR left out intentionally?
>
> Thanks,
>
>Wolfram
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] sata: xgene: add ACPI support for APM X-Gene SATA ports

[Feng Kan]

This adds ACPI support for the APM X-Gene SATA ports. When the system
boots using ACPI table, the SATA ports are able to configure using the
values supplied by the ACPI table rather than the DTS.

Signed-off-by: Feng Kan 
Reviewed-by: Hanjun Guo 
---
 drivers/ata/ahci_xgene.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 2e8bb60..2b78510 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -22,6 +22,7 @@
  * NOTE: PM support is not currently available.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -718,6 +719,14 @@ disable_resources:
return rc;
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_ahci_acpi_match[] = {
+   { "APMC0D0D", },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
+#endif
+
 static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci"},
{},
@@ -730,6 +739,7 @@ static struct platform_driver xgene_ahci_driver = {
.driver = {
.name = DRV_NAME,
.of_match_table = xgene_ahci_of_match,
+   .acpi_match_table = ACPI_PTR(xgene_ahci_acpi_match),
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata: xgene: add ACPI support for APM X-Gene SATA ports

[Feng Kan]

On Mon, Jan 12, 2015 at 10:29 PM, Hanjun Guo  wrote:
> On 2015年01月13日 05:07, Suman Tripathi wrote:
>>
>> Hi,
>>
>> Tested-by: Suman Tripathi 
>>
>> On Thu, Jan 8, 2015 at 11:35 PM, Hanjun Guo > <mailto:hanjun@linaro.org>> wrote:
>>
>> On 2015年01月09日 01:56, Feng Kan wrote:
>>
>> On Wed, Jan 7, 2015 at 11:50 PM, Hanjun Guo
>> mailto:hanjun@linaro.org>> wrote:
>>
>> Hi Feng Kan,
>>
>> I have some comments below.
>>
>>
>> On 2015年01月08日 01:32, Feng Kan wrote:
>>
>>
>> Just want to ping this again.
>>
>> Happy new year
>>
>> On Thu, Dec 11, 2014 at 2:31 PM, Feng Kan > <mailto:f...@apm.com>> wrote:
>>
>>
>> This adds ACPI support for the APM X-Gene SATA
>> ports. When the system
>> boots using ACPI table, the SATA ports are able to
>> configure using the
>> values supplied by the ACPI table rather than the DTS.
>>
>> Signed-off-by: Feng Kan > <mailto:f...@apm.com>>
>> ---
>> drivers/ata/ahci_xgene.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/ata/ahci_xgene.c
>> b/drivers/ata/ahci_xgene.c
>> index d0c851a..4951392 100644
>> --- a/drivers/ata/ahci_xgene.c
>> +++ b/drivers/ata/ahci_xgene.c
>> @@ -22,6 +22,7 @@
>>  * NOTE: PM support is not currently available.
>>  *
>>  */
>> +#include 
>> #include 
>> #include 
>> #include 
>> @@ -521,6 +522,14 @@ disable_resources:
>>return rc;
>> }
>>
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id
>> xgene_ahci_acpi_match[] = {
>> +   { "APMC0D0D", },
>>
>>
>>
>> When I was going through the PNP and ACPI ID list in
>> http://www.uefi.org/PNP_ACPI___Registry
>> <http://www.uefi.org/PNP_ACPI_Registry>, I found that
>> there is no "APMC" for ACPI ID, I only found that there is
>> a PNP ID "APM" for Applied Memory Tech company, are
>> you using PNP ID for this one?
>>
>> if not, I think you can send a request to UEFI and
>> request a new ACPI ID of "APMC" for Applied Micro, and then
>> submit the patch again.
>>
>> How to send a request to register the ACPI ID, you can
>> refer to:
>> http://www.uefi.org/PNP_ACPI___Registry
>> <http://www.uefi.org/PNP_ACPI_Registry>
>>
>>
>> Hanjun, the documents are bit out of sync. We have received
>> approval and
>> it is present in the document link below. I can also forward the
>> approval letter
>> if it needed.
>>
>>
>> http://download.microsoft.com/__download/7/E/7/7E7662CF-CBEA-__470B-A97E-CE7CE0D98DC2/ISA%__20PNPID%20List.xlsx
>>
>> <http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/ISA%20PNPID%20List.xlsx>
>>
>>
>> Sorry for missing this link, I think I should report this
>> inconsistency to ACPI spec working group and then update it
>> accordingly.
>
>
> Also I had reported this issue to ASWG and some people will
> check with this issue and fix it, so
>
> Reviewed-by: Hanjun Guo 

Hi. Is there a chance this can make it into tree. Thanks

>
> Thanks
> Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

This patch adds the support for APM Merlin board. The Merlin board
is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
SATA and Serial.

Signed-off-by: Feng Kan 
---
  V2 Change:
- Add dma-range definition

  V1 Change:
- add memreserve for spintable.
- remove clkfreq attribute
- update spin location, although it is done by bootloader.
- remove msi reg entry
- add chosen for stdout path 
 arch/arm64/boot/dts/apm/apm-merlin.dts |  41 
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 155 +
 2 files changed, 196 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
 create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

diff --git a/arch/arm64/boot/dts/apm/apm-merlin.dts 
b/arch/arm64/boot/dts/apm/apm-merlin.dts
new file mode 100644
index 000..3feefbd
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-merlin.dts
@@ -0,0 +1,41 @@
+/*
+ * dts file for AppliedMicro (APM) Merlin Board
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "apm-shadowcat.dtsi"
+
+/ {
+   model = "APM X-Gene Merlin board";
+   compatible = "apm,merlin", "apm,xgene-shadowcat";
+
+   chosen {
+   linux,stdout-path = &serial0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = < 0x1 0x 0x0 0x8000 >;
+   };
+};
+
+&serial0 {
+   status = "ok";
+};
+&sata1 {
+   status = "ok";
+};
+&sata2 {
+   status = "ok";
+};
+&sata3 {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
new file mode 100644
index 000..d9e193d
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -0,0 +1,155 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Shadowcat SOC
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/memreserve/ 0x40 0x0001;
+
+/ {
+   compatible = "apm,xgene-shadowcat";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@000 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x000>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@001 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x001>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@200 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x200>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@201 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x201>;
+  

[PATCH V1] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

This patch adds the support for APM Merlin board. The Merlin board
is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
SATA and Serial.

Signed-off-by: Feng Kan 
---
  V1 Change:
- add memreserve for spintable.
- remove clkfreq attribute
- update spin location, although it is done by bootloader.
- remove msi reg entry
- add chosen for stdout path 

 arch/arm64/boot/dts/apm/apm-merlin.dts |  41 
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 154 +
 2 files changed, 195 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
 create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

diff --git a/arch/arm64/boot/dts/apm/apm-merlin.dts 
b/arch/arm64/boot/dts/apm/apm-merlin.dts
new file mode 100644
index 000..3feefbd
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-merlin.dts
@@ -0,0 +1,41 @@
+/*
+ * dts file for AppliedMicro (APM) Merlin Board
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "apm-shadowcat.dtsi"
+
+/ {
+   model = "APM X-Gene Merlin board";
+   compatible = "apm,merlin", "apm,xgene-shadowcat";
+
+   chosen {
+   linux,stdout-path = &serial0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = < 0x1 0x 0x0 0x8000 >;
+   };
+};
+
+&serial0 {
+   status = "ok";
+};
+&sata1 {
+   status = "ok";
+};
+&sata2 {
+   status = "ok";
+};
+&sata3 {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
new file mode 100644
index 000..0dc8127
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -0,0 +1,154 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Shadowcat SOC
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/memreserve/ 0x40 0x0001;
+
+/ {
+   compatible = "apm,xgene-shadowcat";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@000 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x000>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@001 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x001>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@200 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x200>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x40 0xfff8>;
+   };
+   cpu@201 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x201>;
+   enable-method = "spin-table";
+   cpu-relea

Re: [PATCH] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

On Tue, Mar 10, 2015 at 10:20 AM, Mark Rutland  wrote:
> Hi,
>
> On Tue, Mar 10, 2015 at 05:10:54PM +0000, Feng Kan wrote:
>> This patch adds the support for APM Merlin board. The Merlin board
>> is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
>> SATA and Serial.
>>
>> Signed-off-by: Feng Kan 
>> ---
>>  arch/arm64/boot/dts/apm/apm-merlin.dts |  39 
>>  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 154 
>> +
>>  2 files changed, 193 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
>>  create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
>
> [...]
>
>> + memory {
>> + device_type = "memory";
>> + reg = < 0x1 0x 0x0 0x8000 >;
>> + };
>
> [...]
>
>> + cpu@000 {
>> + device_type = "cpu";
>> + compatible = "apm,strega", "arm,armv8";
>> + reg = <0x0 0x000>;
>> + enable-method = "spin-table";
>
> I take it that as with Potenza there won't be PSCI?
Yes.
>
>> + cpu-release-addr = <0x1 0xfff8>;
>> + };
>
> The range covered by the cpu-release-addr exists in the memory node and
> there's no /memreserve/, so this is broken.
I will fix this and the rest.
>
> Please fix this so the release address and the code the secondaries are
> executing to poll it can't be accidentally clobbered.
>
> [...]
>
>> + gic: interrupt-controller@7809 {
>> + compatible = "arm,cortex-a15-gic";
>> + #interrupt-cells = <3>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + interrupt-controller;
>> + interrupts = <1 9 0xf04>;   /* GIC Maintenence IRQ */
>> + ranges = <0 0 0 0x7900 0x0 0x80>; /* MSI Range */
>
> Nothing in this patch seems to require this ranges entry. Remove it
> until it's necessary.
>
>> + reg = <0x0 0x7809 0x0 0x1>, /* GIC Dist */
>> +   <0x0 0x780A 0x0 0x2>, /* GIC CPU */
>> +   <0x0 0x780C 0x0 0x1>, /* GIC VCPU Control */
>> +   <0x0 0x780E 0x0 0x2>; /* GIC VCPU */
>> + };
>> +
>> + pmu {
>> + compatible = "arm,armv8-pmuv3";
>> + interrupts = <1 12 0xff04>;
>> + };
>> +
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 0 0xff04>,  /* Secure Phys IRQ */
>> +  <1 13 0xff04>, /* Non-secure Phys IRQ */
>> +  <1 14 0xff04>, /* Virt IRQ */
>> +  <1 15 0xff04>; /* Hyp IRQ */
>> + clock-frequency = <5000>;
>
> CNTFRQ should be programmed (on all CPUs) by the FW/bootloader prior to
> entering the kernel.
>
> If it isn't configured, virtualization is broken.
>
> If it is configured, this is unnecessary and can be dropped from the
> dts.
>
> [...]
>
>> + serial0: serial@1060 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <0 0x1060 0x0 0x1000>;
>> + reg-shift = <2>;
>> + clock-frequency = <1000>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <0x0 0x4c 0x4>;
>> + };
>
> It would be good if /chosen/stdout-path were set up appropriately for
> this.
>
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm64: dts: add APM Merlin Board device tree

[Feng Kan]

This patch adds the support for APM Merlin board. The Merlin board
is based on the APM X-Gene Shadowcat SoC. This DTS enables PMU,
SATA and Serial.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-merlin.dts |  39 
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 154 +
 2 files changed, 193 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apm/apm-merlin.dts
 create mode 100644 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

diff --git a/arch/arm64/boot/dts/apm/apm-merlin.dts 
b/arch/arm64/boot/dts/apm/apm-merlin.dts
new file mode 100644
index 000..152c513
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-merlin.dts
@@ -0,0 +1,39 @@
+/*
+ * dts file for AppliedMicro (APM) Merlin Board
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "apm-shadowcat.dtsi"
+
+/ {
+   model = "APM X-Gene Merlin board";
+   compatible = "apm,merlin", "apm,xgene-shadowcat";
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   reg = < 0x1 0x 0x0 0x8000 >;
+   };
+};
+
+&serial0 {
+   status = "ok";
+};
+&sata1 {
+   status = "ok";
+};
+&sata2 {
+   status = "ok";
+};
+&sata3 {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
new file mode 100644
index 000..14b6cce
--- /dev/null
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -0,0 +1,154 @@
+/*
+ * dts file for AppliedMicro (APM) X-Gene Shadowcat SOC
+ *
+ * Copyright (C) 2015, Applied Micro Circuits Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/ {
+   compatible = "apm,xgene-shadowcat";
+   interrupt-parent = <&gic>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@000 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x000>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@001 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x001>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x101>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@200 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x200>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@201 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x201>;
+   enable-method = "spin-table";
+   cpu-release-addr = <0x1 0xfff8>;
+   };
+   cpu@300 {
+   device_type = "cpu";
+   compatible = "apm,strega", "arm,armv8";
+   reg = <0x0 0x300>;
+   enable-method = "sp

[PATCH] rng: xgene-rng: add ACPI support for APM X-Gene RNG unit

[Feng Kan]

This adds ACPI support for APM X-Gene RNG unit.

Signed-off-by: Feng Kan 
---
 drivers/char/hw_random/xgene-rng.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/char/hw_random/xgene-rng.c 
b/drivers/char/hw_random/xgene-rng.c
index 23caa05..c37cf75 100644
--- a/drivers/char/hw_random/xgene-rng.c
+++ b/drivers/char/hw_random/xgene-rng.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -310,6 +311,14 @@ static int xgene_rng_init(struct hwrng *rng)
return 0;
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_rng_acpi_match[] = {
+   { "APMC0D18", },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_rng_acpi_match);
+#endif
+
 static struct hwrng xgene_rng_func = {
.name   = "xgene-rng",
.init   = xgene_rng_init,
@@ -415,6 +424,7 @@ static struct platform_driver xgene_rng_driver = {
.driver = {
.name   = "xgene-rng",
.of_match_table = xgene_rng_of_match,
+   .acpi_match_table = ACPI_PTR(xgene_rng_acpi_match),
},
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI: xgene: fix breakage from generic config usage

[Feng Kan]

Acked-by: Feng Kan 

On Wed, Mar 4, 2015 at 2:24 PM, Mark Salter  wrote:
> Commit 350f8be5bb402 ("PCI: xgene: Convert to use generic config
> accessors") breaks PCI on the X-Gene platform. It creates two
> problems with the xgene_pcie_map_bus() function. First, it returns
> an int but should return a void __iomem *, but that's just a
> compile-time warning. The breakage is caused by the offset not
> being added to the base of the config map. So all config reads
> and writes operate on the first four bytes of config space. This
> patch fixes both issues.
>
> Signed-off-by: Mark Salter 
> ---
>  drivers/pci/host/pci-xgene.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> index 52bb25c..b87f80b 100644
> --- a/drivers/pci/host/pci-xgene.c
> +++ b/drivers/pci/host/pci-xgene.c
> @@ -129,17 +129,21 @@ static bool xgene_pcie_hide_rc_bars(struct pci_bus 
> *bus, int offset)
> return false;
>  }
>
> -static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> - int offset)
> +static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int 
> devfn,
> +   int offset)
>  {
> struct xgene_pcie_port *port = bus->sysdata;
> +   void __iomem *base;
>
> if ((pci_is_root_bus(bus) && devfn != 0) || !port->link_up ||
> xgene_pcie_hide_rc_bars(bus, offset))
> return NULL;
>
> xgene_pcie_set_rtdid_reg(bus, devfn);
> -   return xgene_pcie_get_cfg_base(bus);
> +   base = xgene_pcie_get_cfg_base(bus);
> +   if (base)
> +   base += offset;
> +   return base;
>  }
>
>  static struct pci_ops xgene_pcie_ops = {
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pci: host: xgene: fix incorrectly returned address by map_bus

[Feng Kan]

Please take Mark's patch if you think it is better.



On Thu, Mar 5, 2015 at 8:38 AM, Bjorn Helgaas  wrote:
> [+cc Mark]
>
> On Thu, Feb 26, 2015 at 06:21:51PM -0600, Bjorn Helgaas wrote:
>> On Tue, Feb 17, 2015 at 03:14:00PM -0800, Feng Kan wrote:
>> > The generic accessor functions for pci-xgene uses map_bus
>> > call that returns the base address but did not add the additional
>> > offset.
>> >
>> > Signed-off-by: Feng Kan 
>> > ---
>> >  drivers/pci/host/pci-xgene.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
>> > index aab5547..ee082c0 100644
>> > --- a/drivers/pci/host/pci-xgene.c
>> > +++ b/drivers/pci/host/pci-xgene.c
>> > @@ -127,7 +127,7 @@ static bool xgene_pcie_hide_rc_bars(struct pci_bus 
>> > *bus, int offset)
>> > return false;
>> >  }
>> >
>> > -static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
>> > +static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int 
>> > devfn,
>> >   int offset)
>> >  {
>> > struct xgene_pcie_port *port = bus->sysdata;
>> > @@ -137,7 +137,7 @@ static int xgene_pcie_map_bus(struct pci_bus *bus, 
>> > unsigned int devfn,
>> > return NULL;
>> >
>> > xgene_pcie_set_rtdid_reg(bus, devfn);
>> > -   return xgene_pcie_get_cfg_base(bus);
>> > +   return xgene_pcie_get_cfg_base(bus) + offset;
>>
>> Where's the locking here?  ECAM doesn't need locking because the
>> bus/dev/fn/offset is all encoded in the MMIO address.  But it looks
>> like X-Gene doesn't work that way and bus/dev/fn is in the RTDID register.
>>
>> So it seems like X-Gene needs locking that not everybody needs.  Are you
>> relying on higher-level locking somewhere?
>
> Ping, what's going on here?  I've gotten at least three patches for this
> offset issue, so we need to get it resolved.
>
> If there's no locking problem, I can just apply this and we'll be finished.
> Actually, I think Mark's patch is better, because it correctly returns NULL
> (failure) if xgene_pcie_get_cfg_base() fails.  So please review and ack
> that one or explain why this one is better.
>
> But if there *is* a locking problem, we should fix that, too.  That should
> be a separate patch, so I guess I can apply the one to fix the offset
> problem first, and we'll at least be no worse off with respect to locking
> than we are today.
>
> Please help me out.
>
> Bjorn
>
>> >  }
>> >
>> >  static struct pci_ops xgene_pcie_ops = {
>> > --
>> > 1.9.1
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: eth: xgene: fix booting with devicetree

[Feng Kan]

On Wed, Mar 4, 2015 at 8:51 AM, Mark Salter  wrote:
> Commit de7b5b3d790a ("net: eth: xgene: change APM X-Gene SoC platform
> ethernet to support ACPI") breaks booting with devicetree with UEFI
> firmware. In that case, I get:
>
> Unhandled fault: synchronous external abort (0x9610) at 0xfc620010
>  Internal error: : 9610 [#1] SMP
>  Modules linked in: vfat fat xfs libcrc32c ahci_xgene libahci_platform libahci
>  CPU: 7 PID: 634 Comm: NetworkManager Not tainted 4.0.0-rc1+ #4
>  Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0-rh-0.14 Mar  1 2015
>  task: fe03d4c7e100 ti: fe03d4e24000 task.ti: fe03d4e24000
>  PC is at xgene_enet_rd_mcx_mac.isra.11+0x58/0xd4
>  LR is at xgene_gmac_tx_enable+0x2c/0x50
>  pc : [] lr : [] pstate: 8145
>  sp : fe03d4e27590
>  x29: fe03d4e27590 x28: 
>  x27: fe03d4e277c0 x26: fe03da8fda10
>  x25: fe03d4e2760c x24: fe03d49e28c0
>  x23: fc620004 x22: 
>  x21: fc62 x20: fc620010
>  x19: 000b x18: 03ffd4a96020
>  x17: 03ff7fc1f7a0 x16: fe79b9cc
>  x15:  x14: 
>  x13:  x12: fe03d4e24000
>  x11: fe03d4e27da0 x10: 0001
>  x9 :  x8 : fe03d4e27a20
>  x7 :  x6 : ffef
>  x5 : fe000105f7d0 x4 : fe7ca8c8
>  x3 : fe03d4e2760c x2 : 
>  x1 : fc62 x0 : 4000
>
>  Process NetworkManager (pid: 634, stack limit = 0xfe03d4e24028)
>  Stack: (0xfe03d4e27590 to 0xfe03d4e28000)
>  ...
>  Call trace:
>  [] xgene_enet_rd_mcx_mac.isra.11+0x58/0xd4
>  [] xgene_gmac_tx_enable+0x28/0x50
>  [] xgene_enet_open+0x2c/0x130
>  [] __dev_open+0xc8/0x148
>  [] __dev_change_flags+0x90/0x158
>  [] dev_change_flags+0x30/0x70
>  [] do_setlink+0x278/0x870
>  [] rtnl_newlink+0x404/0x6a8
>  [] rtnetlink_rcv_msg+0x98/0x218
>  [] netlink_rcv_skb+0xe0/0xf8
>  [] rtnetlink_rcv+0x30/0x44
>  [] netlink_unicast+0xfc/0x210
>  [] netlink_sendmsg+0x498/0x5ac
>  [] do_sock_sendmsg+0xa4/0xcc
>  [] ___sys_sendmsg+0x1fc/0x208
>  [] __sys_sendmsg+0x4c/0x94
>  [] SyS_sendmsg+0x2c/0x3c
>
> The problem here is that the enet hw clocks are not getting
> initialized because of a test to avoid the initialization if
> UEFI is used to boot. This is an incorrect test. When booting
> with UEFI and devicetree, the kernel must still initialize
> the enet hw clocks. If booting with ACPI, the clock hw is
> not exposed to the kernel and it is that case where we want
> to avoid initializing clocks.
>
> Signed-off-by: Mark Salter 
> ---
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> index 869d97f..b927021 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> @@ -593,7 +593,7 @@ static int xgene_enet_reset(struct xgene_enet_pdata 
> *pdata)
> if (!xgene_ring_mgr_init(pdata))
> return -ENODEV;
>
> -   if (!efi_enabled(EFI_BOOT)) {
> +   if (pdata->clk) {
> clk_prepare_enable(pdata->clk);
> clk_disable_unprepare(pdata->clk);
> clk_prepare_enable(pdata->clk);

Acked-by: Feng Kan 
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 3/3] arm64: dts: add proxy I2C device driver on APM X-Gene platform

[Feng Kan]

Add proxy I2C device driver on APM X-Gene platform.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 27d6c3d..f19bb6b 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -483,6 +483,11 @@
<0x0 0x7 0x4>;
};
 
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 2/3] Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver documentation

[Feng Kan]

Add APM X-Gene platform SLIMpro I2C driver documentation.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt 
b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
new file mode 100644
index 000..f6b2c20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
@@ -0,0 +1,15 @@
+APM X-Gene SLIMpro Mailbox I2C Driver
+
+An I2C controller accessed over the "SLIMpro" mailbox.
+
+Required properties :
+
+ - compatible : should be "apm,xgene-slimpro-i2c"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = <&mailbox 0>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 1/3] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 464 +
 3 files changed, 474 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 825b586..5c27005 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1072,6 +1072,15 @@ config I2C_CROS_EC_TUNNEL
  connected there. This will work whatever the interface used to
  talk to the EC (SPI, I2C or LPC).
 
+config I2C_XGENE_SLIMPRO
+   tristate "APM X-Gene SoC I2C SLIMpro devices support"
+   depends on ARCH_XGENE && MAILBOX
+   help
+ Enable I2C bus access using the APM X-Gene SoC SLIMpro
+ co-processor. The I2C device access the I2C bus via the X-Gene
+ to SLIMpro (On chip coprocessor) mailbox mechanism.
+ If unsure, say N.
+
 config SCx200_ACB
tristate "Geode ACCESS.bus support"
depends on X86_32 && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index a04f972..3d58a85 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
+obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
new file mode 100644
index 000..c34ade8
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -0,0 +1,464 @@
+/*
+ * X-Gene SLIMpro I2C Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Author: Hieu Le 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This driver provides support for X-Gene SLIMpro I2C device access
+ * using the APM X-Gene SLIMpro mailbox driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
+#define MAILBOX_I2C_INDEX  0
+#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only */
+
+#define SMBUS_CMD_LEN  1
+#define BYTE_DATA  1
+#define WORD_DATA  2
+#define BLOCK_DATA 3
+
+#define SLIMPRO_IIC_I2C_PROTOCOL   0
+#define SLIMPRO_IIC_SMB_PROTOCOL   1
+
+#define SLIMPRO_IIC_READ   0
+#define SLIMPRO_IIC_WRITE  1
+
+#define IIC_SMB_WITHOUT_DATA_LEN   0
+#define IIC_SMB_WITH_DATA_LEN  1
+
+#define SLIMPRO_DEBUG_MSG  0
+#define SLIMPRO_MSG_TYPE_SHIFT 28
+#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
+#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
+#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
+#define SLIMPRO_IIC_DEV_SHIFT  23
+#define SLIMPRO_IIC_DEV_MASK   0x0080U
+#define SLIMPRO_IIC_DEVID_SHIFT13
+#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
+#define SLIMPRO_IIC_RW_SHIFT   12
+#define SLIMPRO_IIC_RW_MASK0x1000U
+#define SLIMPRO_IIC_PROTO_SHIFT11
+#define SLIMPRO_IIC_PROTO_MASK 0x0800U
+#define SLIMPRO_IIC_ADDRLEN_SHIFT  8
+#define SLIMPRO_IIC_ADDRLEN_MASK   0x0700U
+#define SLIMPRO_IIC_DATALEN_SHIFT  0
+#define SLIMPRO_IIC_DATALEN_MASK   0x00FFU
+
+/*
+ * SLIMpro I2C message encode
+ *
+ * dev - Controller number (0-based)
+ * chip- I2C chip address
+ * op  - SLIMPRO_IIC_READ or SLIMPRO_IIC_WRITE
+ * proto   - SLIMPRO_IIC_SMB_PROTOCOL or SLIMPRO_IIC_I2C_PROTOCOL
+ * addrlen - Length of the address field
+ * datalen - Length of the data field
+ */
+#define SLIMPRO_IIC_ENCODE_MSG(dev, chip, op, proto, addrl

[PATCH 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation

[Feng Kan]

This adds the APM X-Gene SLIMpro mailbox device tree node documentation.

Signed-off-by: Feng Kan 
---
 .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
new file mode 100644
index 000..d02a3d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
@@ -0,0 +1,34 @@
+The APM X-Gene SLIMpro mailbox is used to communicate messages between
+the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+interrupt based door bell mechanism and can exchange simple messages using the
+internal registers.
+
+There are total of 7 interrupts in this mailbox. Each used for an individual
+door bell (or mailbox channel).
+
+Required properties:
+- compatible:  Should be as "apm, xgene-slimpro-mbox".
+
+- reg: Contain the mailbox register address range.
+
+- interrupts:  7 interrupts must start from 0 to 6, interrupt 0 define the
+   the interrupt for mailbox channel 0 and interrupt 1 for
+   mailbox channel 1 and so likewise for the reminder.
+
+- #mbox-cells: only one to specify the mailbox channel number.
+
+Example:
+
+Mailbox Node:
+   slimpro-mbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] arm64: dts: mailbox device tree node for APM X-Gene platform.

[Feng Kan]

Mailbox device tree node for APM X-Gene platform.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f1ad9c2..27d6c3d 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -469,6 +469,20 @@
clocks = <&pcie4clk 0>;
};
 
+   mailbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   <0x0 0x7 0x4>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mailbox: add support for APM X-Gene platform mailbox driver

[Feng Kan]

Add support for APM X-Gene platform mailbox driver.

Signed-off-by: Feng Kan 
---
 drivers/mailbox/Kconfig |  10 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c | 289 
 3 files changed, 301 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84325f2..14ceae1 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -51,4 +51,14 @@ config ALTERA_MBOX
  An implementation of the Altera Mailbox soft core. It is used
  to send message between processors. Say Y here if you want to use the
  Altera mailbox support.
+
+config XGENE_SLIMPRO_MBOX
+   tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
+   depends on ARCH_XGENE
+   help
+ An implementation of the APM X-Gene Interprocessor Communication
+ Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
+ It is used to send short messages between ARM64-bit cores and
+ the SLIMpro Management Engine, primarily for PM. Say Y here if you
+ want to use the APM X-Gene SLIMpro IPCM support.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 2e79231..e15fcf7 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,3 +9,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX)+= omap-mailbox.o
 obj-$(CONFIG_PCC)  += pcc.o
 
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
+
+obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
new file mode 100644
index 000..09c619a
--- /dev/null
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -0,0 +1,289 @@
+/*
+ * APM X-Gene SLIMpro MailBox Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan f...@apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MBOX_CON_NAME  "slimpro-mbox"
+#define MBOX_REG_SET_OFFSET0x1000
+#define MBOX_CNT   8
+#define MBOX_STATUS_AVAIL_MASK 0x0001
+#define MBOX_STATUS_ACK_MASK   0x0001
+
+/* Configuration and Status Registers */
+struct slimpro_mbox_reg {
+   u32 in;
+   u32 din0;
+   u32 din1;
+   u32 rsvd1;
+   u32 out;
+   u32 dout0;
+   u32 dout1;
+   u32 rsvd2;
+   u32 status;
+   u32 statusmask;
+};
+
+struct slimpro_mbox_chan {
+   struct device *dev;
+   struct mbox_chan *chan;
+   struct slimpro_mbox_reg __iomem *reg;
+   int id;
+   int irq;
+   u32 rx_msg[3];
+};
+
+struct slimpro_mbox {
+   struct mbox_controller mb_ctrl;
+   struct slimpro_mbox_chan mc[MBOX_CNT];
+   struct mbox_chan chans[MBOX_CNT];
+};
+
+static struct slimpro_mbox_chan *to_slimpro_mbox_chan(struct mbox_chan *chan)
+{
+   if (!chan || !chan->con_priv)
+   return NULL;
+
+   return (struct slimpro_mbox_chan *)chan->con_priv;
+}
+
+static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
+{
+   writel(msg[1], &mb_chan->reg->dout0);
+   writel(msg[2], &mb_chan->reg->dout1);
+   writel(msg[0], &mb_chan->reg->out);
+}
+
+static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
+{
+   mb_chan->rx_msg[1] = readl(&mb_chan->reg->din0);
+   mb_chan->rx_msg[2] = readl(&mb_chan->reg->din1);
+   mb_chan->rx_msg[0] = readl(&mb_chan->reg->in);
+}
+
+static void mb_chan_enable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(&mb_chan->reg->statusmask);
+
+   val &= ~mask;
+
+   writel(val, &mb_chan->reg->statusmask);
+}
+
+static void mb_chan_disable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(&mb_chan->reg->statusmask);
+
+   val |= mask;
+
+   writel(val, &mb_chan->reg->statusmask);
+}
+
+static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
+{
+   u32 val = readl(&mb_chan->reg->status);
+
+   

[PATCH 3/3] arm64: dts: mailbox device tree node for APM X-Gene platform.

[Feng Kan]

Mailbox device tree node for APM X-Gene platform.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f1ad9c2..27d6c3d 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -469,6 +469,20 @@
clocks = <&pcie4clk 0>;
};
 
+   mailbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   <0x0 0x7 0x4>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mailbox: add support for APM X-Gene platform mailbox driver

[Feng Kan]

Add support for APM X-Gene platform mailbox driver.

Signed-off-by: Feng Kan 
---
 drivers/mailbox/Kconfig |  10 ++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c | 289 
 3 files changed, 301 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84325f2..14ceae1 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -51,4 +51,14 @@ config ALTERA_MBOX
  An implementation of the Altera Mailbox soft core. It is used
  to send message between processors. Say Y here if you want to use the
  Altera mailbox support.
+
+config XGENE_SLIMPRO_MBOX
+   tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
+   depends on ARCH_XGENE
+   help
+ An implementation of the APM X-Gene Interprocessor Communication
+ Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
+ It is used to send short messages between ARM64-bit cores and
+ the SLIMpro Management Engine, primarily for PM. Say Y here if you
+ want to use the APM X-Gene SLIMpro IPCM support.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 2e79231..e15fcf7 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,3 +9,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX)+= omap-mailbox.o
 obj-$(CONFIG_PCC)  += pcc.o
 
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
+
+obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c 
b/drivers/mailbox/mailbox-xgene-slimpro.c
new file mode 100644
index 000..09c619a
--- /dev/null
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -0,0 +1,289 @@
+/*
+ * APM X-Gene SLIMpro MailBox Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan f...@apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MBOX_CON_NAME  "slimpro-mbox"
+#define MBOX_REG_SET_OFFSET0x1000
+#define MBOX_CNT   8
+#define MBOX_STATUS_AVAIL_MASK 0x0001
+#define MBOX_STATUS_ACK_MASK   0x0001
+
+/* Configuration and Status Registers */
+struct slimpro_mbox_reg {
+   u32 in;
+   u32 din0;
+   u32 din1;
+   u32 rsvd1;
+   u32 out;
+   u32 dout0;
+   u32 dout1;
+   u32 rsvd2;
+   u32 status;
+   u32 statusmask;
+};
+
+struct slimpro_mbox_chan {
+   struct device *dev;
+   struct mbox_chan *chan;
+   struct slimpro_mbox_reg __iomem *reg;
+   int id;
+   int irq;
+   u32 rx_msg[3];
+};
+
+struct slimpro_mbox {
+   struct mbox_controller mb_ctrl;
+   struct slimpro_mbox_chan mc[MBOX_CNT];
+   struct mbox_chan chans[MBOX_CNT];
+};
+
+static struct slimpro_mbox_chan *to_slimpro_mbox_chan(struct mbox_chan *chan)
+{
+   if (!chan || !chan->con_priv)
+   return NULL;
+
+   return (struct slimpro_mbox_chan *)chan->con_priv;
+}
+
+static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
+{
+   writel(msg[1], &mb_chan->reg->dout0);
+   writel(msg[2], &mb_chan->reg->dout1);
+   writel(msg[0], &mb_chan->reg->out);
+}
+
+static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
+{
+   mb_chan->rx_msg[1] = readl(&mb_chan->reg->din0);
+   mb_chan->rx_msg[2] = readl(&mb_chan->reg->din1);
+   mb_chan->rx_msg[0] = readl(&mb_chan->reg->in);
+}
+
+static void mb_chan_enable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(&mb_chan->reg->statusmask);
+
+   val &= ~mask;
+
+   writel(val, &mb_chan->reg->statusmask);
+}
+
+static void mb_chan_disable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
+{
+   u32 val = readl(&mb_chan->reg->statusmask);
+
+   val |= mask;
+
+   writel(val, &mb_chan->reg->statusmask);
+}
+
+static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
+{
+   u32 val = readl(&mb_chan->reg->status);
+
+   

[PATCH 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation

[Feng Kan]

This adds the APM X-Gene SLIMpro mailbox device tree node documentation.

Signed-off-by: Feng Kan 
---
 .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
new file mode 100644
index 000..d02a3d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
@@ -0,0 +1,34 @@
+The APM X-Gene SLIMpro mailbox is used to communicate messages between
+the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+interrupt based door bell mechanism and can exchange simple messages using the
+internal registers.
+
+There are total of 7 interrupts in this mailbox. Each used for an individual
+door bell (or mailbox channel).
+
+Required properties:
+- compatible:  Should be as "apm, xgene-slimpro-mbox".
+
+- reg: Contain the mailbox register address range.
+
+- interrupts:  7 interrupts must start from 0 to 6, interrupt 0 define the
+   the interrupt for mailbox channel 0 and interrupt 1 for
+   mailbox channel 1 and so likewise for the reminder.
+
+- #mbox-cells: only one to specify the mailbox channel number.
+
+Example:
+
+Mailbox Node:
+   slimpro-mbox: slimpro-mbox@1054 {
+   compatible = "apm,xgene-slimpro-mbox";
+   reg = <0x0 0x1054 0x0 0xa000>;
+   #mbox-cells = <1>;
+   interrupts =<0x0 0x0 0x4>,
+   <0x0 0x1 0x4>,
+   <0x0 0x2 0x4>,
+   <0x0 0x3 0x4>,
+   <0x0 0x4 0x4>,
+   <0x0 0x5 0x4>,
+   <0x0 0x6 0x4>,
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pci: host: xgene: fix incorrectly returned address by map_bus

[Feng Kan]

The generic accessor functions for pci-xgene uses map_bus
call that returns the base address but did not add the additional
offset.

Signed-off-by: Feng Kan 
---
 drivers/pci/host/pci-xgene.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index aab5547..ee082c0 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -127,7 +127,7 @@ static bool xgene_pcie_hide_rc_bars(struct pci_bus *bus, 
int offset)
return false;
 }
 
-static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
+static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int 
devfn,
  int offset)
 {
struct xgene_pcie_port *port = bus->sysdata;
@@ -137,7 +137,7 @@ static int xgene_pcie_map_bus(struct pci_bus *bus, unsigned 
int devfn,
return NULL;
 
xgene_pcie_set_rtdid_reg(bus, devfn);
-   return xgene_pcie_get_cfg_base(bus);
+   return xgene_pcie_get_cfg_base(bus) + offset;
 }
 
 static struct pci_ops xgene_pcie_ops = {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

On Thu, Jan 29, 2015 at 10:11 PM, Wolfram Sang  wrote:
>
>> > ctx->dev is probably the wrong device here. The i2c controller is not
>> > DMA capable itself, you need to have a pointer to the device that actually
>> > performs the DMA here.
>>
>> Arnd, I do agree this may not be the best identification. There is no
>> representation for this on the Linux side. I could put it as NULL. However,
>> there are other i2c bus drivers that seem to do the same thing. Please
>> let me know what you think.
>
> For completeness: Those drivers need fixing!
I have some doubts. I could hack up a dts node for the helper
processor that is doing the dma. However, the dma master could be
anything for that matter. I am not sure how I can write this in a
generic manner.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

On Tue, Nov 11, 2014 at 1:51 PM, Arnd Bergmann  wrote:
> On Tuesday 07 October 2014 17:06:47 Feng Kan wrote:
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 2e45ae3..a03042c 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -1009,6 +1009,15 @@ config I2C_CROS_EC_TUNNEL
>> connected there. This will work whatever the interface used to
>> talk to the EC (SPI, I2C or LPC).
>>
>> +config I2C_XGENE_SLIMPRO
>> + tristate "APM X-Gene SoC I2C SLIMpro devices support"
>> + depends on ARCH_XGENE && XGENE_SLIMPRO_MBOX
>
> Why this dependency on XGENE_SLIMPRO_MBOX?

>> +static int slimpro_i2c_blkrd(struct slimpro_i2c_dev *ctx, u32 chip, u32 
>> addr,
>> + u32 addrlen, u32 protocol, u32 readlen,
>> + u32 with_data_len, void *data)
>> +{
>> + dma_addr_t paddr;
>> + u32 msg[3];
>> + int rc;
>> +
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, readlen,
>> +DMA_FROM_DEVICE);
>
> ctx->dev is probably the wrong device here. The i2c controller is not
> DMA capable itself, you need to have a pointer to the device that actually
> performs the DMA here.

Arnd, I do agree this may not be the best identification. There is no
representation for this on the Linux side. I could put it as NULL. However,
there are other i2c bus drivers that seem to do the same thing. Please
let me know what you think.

>
>
>> + /* Request mailbox channel */
>> + cl->dev = &pdev->dev;
>> + cl->rx_callback = slimpro_i2c_rx_cb;
>> + cl->tx_done = slimpro_i2c_tx_done;
>> + cl->tx_block = true;
>> + cl->tx_tout = SLIMPRO_OP_TO_MS;
>> + cl->knows_txdone = false;
>> + cl->chan_name = "i2c-slimpro";
>> + ctx->mbox_chan = mbox_request_channel(cl);
>
> This is not the correct interface.
>
>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> + if (rc)
>> + dev_warn(&pdev->dev, "Unable to set dma mask\n");
>
> Are you sure that this is the correct device to perform the DMA?
>
> Moreover, the mask doesn't match the usage: the slimpro_i2c_blkrd
> function passes in only the lower 32 bit of the address, which would
> be DMA_BIT_MASK(32).
The upper part of the address is passed in as part of the msg[1]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

On Tue, Nov 11, 2014 at 1:51 PM, Arnd Bergmann  wrote:
> On Tuesday 07 October 2014 17:06:47 Feng Kan wrote:
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 2e45ae3..a03042c 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -1009,6 +1009,15 @@ config I2C_CROS_EC_TUNNEL
>> connected there. This will work whatever the interface used to
>> talk to the EC (SPI, I2C or LPC).
>>
>> +config I2C_XGENE_SLIMPRO
>> + tristate "APM X-Gene SoC I2C SLIMpro devices support"
>> + depends on ARCH_XGENE && XGENE_SLIMPRO_MBOX
>
> Why this dependency on XGENE_SLIMPRO_MBOX?
>
> Better replace it with a dependency on MAILBOX.
Arnd, just a question. Is this because this possibly help with future
compatibility by choosing a more broad dependency?
>
>> + } else {
>> + spin_lock_irqsave(&ctx->lock, flags);
>> + ctx->i2c_rx_poll = 1;
>> + for (count = SLIMPRO_I2C_WAIT_COUNT; count > 0; count--) {
>> + if (ctx->i2c_rx_poll == 0)
>> + break;
>> + udelay(100);
>> + }
>
> No, you can't block the CPU for an extended amount of time with
> interrupts disabled. Please kill this code.
>
>> + ctx->resp_msg = data;
>> + if (ctx->mbox_client.tx_block)
>> + init_completion(&ctx->rd_complete);
>
> reinit_completion()?
>
>> +static int slimpro_i2c_blkrd(struct slimpro_i2c_dev *ctx, u32 chip, u32 
>> addr,
>> + u32 addrlen, u32 protocol, u32 readlen,
>> + u32 with_data_len, void *data)
>> +{
>> + dma_addr_t paddr;
>> + u32 msg[3];
>> + int rc;
>> +
>> + paddr = dma_map_single(ctx->dev, ctx->dma_buffer, readlen,
>> +DMA_FROM_DEVICE);
>
> ctx->dev is probably the wrong device here. The i2c controller is not
> DMA capable itself, you need to have a pointer to the device that actually
> performs the DMA here.
>
>
>> + /* Request mailbox channel */
>> + cl->dev = &pdev->dev;
>> + cl->rx_callback = slimpro_i2c_rx_cb;
>> + cl->tx_done = slimpro_i2c_tx_done;
>> + cl->tx_block = true;
>> + cl->tx_tout = SLIMPRO_OP_TO_MS;
>> + cl->knows_txdone = false;
>> + cl->chan_name = "i2c-slimpro";
>> + ctx->mbox_chan = mbox_request_channel(cl);
>
> This is not the correct interface.
>
>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> + if (rc)
>> + dev_warn(&pdev->dev, "Unable to set dma mask\n");
>
> Are you sure that this is the correct device to perform the DMA?
>
> Moreover, the mask doesn't match the usage: the slimpro_i2c_blkrd
> function passes in only the lower 32 bit of the address, which would
> be DMA_BIT_MASK(32).
>
>> +#ifdef CONFIG_OF
>> +static struct of_device_id xgene_slimpro_i2c_id[] = {
>> + {.compatible = "apm,xgene-slimpro-i2c" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, xgene_slimpro_i2c_dt_ids);
>> +#endif
>> +
>> +static struct platform_driver xgene_slimpro_i2c_driver = {
>> + .probe  = xgene_slimpro_i2c_probe,
>> + .remove = xgene_slimpro_i2c_remove,
>> + .driver = {
>> + .name   = XGENE_SLIMPRO_I2C,
>> + .owner  = THIS_MODULE,
>> + .of_match_table = of_match_ptr(xgene_slimpro_i2c_id)
>> + },
>> +};
>
> The driver only supports DT, so just drop the #ifdef and the of_match_ptr().
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

On Tue, Nov 11, 2014 at 12:32 PM, Wolfram Sang  wrote:
> On Tue, Oct 07, 2014 at 05:06:47PM -0700, Feng Kan wrote:
>> Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
>> device driver use the SLIMpro Mailbox driver to tunnel message to
>> the SLIMpro coprocessor to do the work of accessing I2C components.
>>
>> Signed-off-by: Feng Kan 
>> Signed-off-by: Hieu Le 
>
> Thank you for this submission!
>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 2e45ae3..a03042c 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -1009,6 +1009,15 @@ config I2C_CROS_EC_TUNNEL
>> connected there. This will work whatever the interface used to
>> talk to the EC (SPI, I2C or LPC).
>>
>> +config I2C_XGENE_SLIMPRO
>> + tristate "APM X-Gene SoC I2C SLIMpro devices support"
>> + depends on ARCH_XGENE && XGENE_SLIMPRO_MBOX
>> + help
>> +   Enable I2C bus access using the APM X-Gene SoC SLIMpro
>> +   co-processor. The I2C device access the I2C bus via the X-Gene
>> +   to SLIMpro (On chip coprocessor) mailbox mechanism.
>> +   If unsure, say N.
>> +
>
> I guess this is a driver for embedded? If so, please sort it properly.
Sorry, having let this dangle for  a while.  I will fix up comments and submit
another version. I can move this to embedded, however Xgene is
suppose to be a server class chip.
>
>>  config SCx200_ACB
>>   tristate "Geode ACCESS.bus support"
>>   depends on X86_32 && PCI
>> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
>> index 49bf07e..22b5f0c 100644
>> --- a/drivers/i2c/busses/Makefile
>> +++ b/drivers/i2c/busses/Makefile
>> @@ -99,6 +99,7 @@ obj-$(CONFIG_I2C_CROS_EC_TUNNEL)+= i2c-cros-ec-tunnel.o
>>  obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
>>  obj-$(CONFIG_I2C_PCA_ISA)+= i2c-pca-isa.o
>>  obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
>> +obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
>
> Ditto.
>
>>  obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
>>
>>  ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
>> diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
>> b/drivers/i2c/busses/i2c-xgene-slimpro.c
>> new file mode 100644
>> index 000..2cf6c33
>> --- /dev/null
>> +++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
>> @@ -0,0 +1,531 @@
>> +/*
>> + * X-Gene SLIMpro I2C Driver
>> + *
>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
>> + * Author: Feng Kan 
>> + * Author: Hieu Le 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>
> The license preamble and MODULE_LICENSE do not match!
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Please sort the includes.
>
>> +
>> +#define XGENE_SLIMPRO_I2C"xgene-slimpro-i2c"
>
> Only used once, not really needed
>
>> +
>> +#define SLIMPRO_I2C_WAIT_COUNT   1
>> +
>> +#define SLIMPRO_OP_TO_MS 1000/* Operation time out in ms */
>
> *_TOUT_* or *_TIMEOUT_*. TO sounds like a conversion, from op to ms :)
>
>> +#define SLIMPRO_IIC_BUS  1
>
> What does this '1' mean?
>
>> +static int start_i2c_msg_xfer(struct slimpro_i2c_dev *ctx)
>> +{
>> + int count;
>> + unsigned long flags;
>> +
>> + if (ctx->mbox_client.tx_block) {
>> + if (!wait_for_completion_timeout(&ctx->rd_complete,
>> +  msecs_to_jiffies
>> +  (SLIMPRO_OP_TO_MS)))
>> + return -EIO;
>
> That should be -ETIMEDOUT, no?
>
>> + } else {
>> + spin_lock_irqsave(&ctx->lock, flags);
>> + ctx->i2c_rx_poll = 1;
>> + for (count = SLIMPRO_I2C_WAIT_COUNT; count > 0; count--) {
>> + if (ctx->i2c_rx_poll == 0)
>> + break;
>> + udelay(100);
>> + }
>> +
>> + if (count == 0) {
>> +   

Re: [PATCH] sata: xgene: add ACPI support for APM X-Gene SATA ports

[Feng Kan]

On Wed, Jan 7, 2015 at 11:50 PM, Hanjun Guo  wrote:
> Hi Feng Kan,
>
> I have some comments below.
>
>
> On 2015年01月08日 01:32, Feng Kan wrote:
>>
>> Just want to ping this again.
>>
>> Happy new year
>>
>> On Thu, Dec 11, 2014 at 2:31 PM, Feng Kan  wrote:
>>>
>>> This adds ACPI support for the APM X-Gene SATA ports. When the system
>>> boots using ACPI table, the SATA ports are able to configure using the
>>> values supplied by the ACPI table rather than the DTS.
>>>
>>> Signed-off-by: Feng Kan 
>>> ---
>>>   drivers/ata/ahci_xgene.c | 10 ++
>>>   1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
>>> index d0c851a..4951392 100644
>>> --- a/drivers/ata/ahci_xgene.c
>>> +++ b/drivers/ata/ahci_xgene.c
>>> @@ -22,6 +22,7 @@
>>>* NOTE: PM support is not currently available.
>>>*
>>>*/
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -521,6 +522,14 @@ disable_resources:
>>>  return rc;
>>>   }
>>>
>>> +#ifdef CONFIG_ACPI
>>> +static const struct acpi_device_id xgene_ahci_acpi_match[] = {
>>> +   { "APMC0D0D", },
>
>
> When I was going through the PNP and ACPI ID list in
> http://www.uefi.org/PNP_ACPI_Registry, I found that
> there is no "APMC" for ACPI ID, I only found that there is
> a PNP ID "APM" for Applied Memory Tech company, are
> you using PNP ID for this one?
>
> if not, I think you can send a request to UEFI and
> request a new ACPI ID of "APMC" for Applied Micro, and then
> submit the patch again.
>
> How to send a request to register the ACPI ID, you can
> refer to:
> http://www.uefi.org/PNP_ACPI_Registry

Hanjun, the documents are bit out of sync. We have received approval and
it is present in the document link below. I can also forward the approval letter
if it needed.

http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/ISA%20PNPID%20List.xlsx


>
> Thanks
> Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 3/7] arm64: dts: Add X-Gene reboot driver dts node

[Feng Kan]

Add X-Gene platform reboot driver dts node.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 4b2ec83..f31e8df 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
 
+   scu: system-clk-controller@1700 {
+   compatible = "apm,xgene-scu","syscon";
+   reg = <0x0 0x1700 0x0 0x400>;
+   };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -354,6 +359,13 @@
};
};
 
+   reboot: reboot@1714 {
+   compatible = "syscon-reboot";
+   regmap = <&scu>;
+   offset = <0x14>;
+   mask = <0x1>;
+   };
+
pcie0: pcie@1f2b {
status = "disabled";
device_type = "pci";
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 2/7] Documentation: arm64: add SCU dts binding documentation to linux kernel

[Feng Kan]

This add documentation for the SCU system clock unit device tree binding
to the kernel.

Signed-off-by: Feng Kan 
---
 Documentation/devicetree/bindings/arm/apm/scu.txt |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt

diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt 
b/Documentation/devicetree/bindings/arm/apm/scu.txt
new file mode 100644
index 000..b45be06
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apm/scu.txt
@@ -0,0 +1,17 @@
+APM X-GENE SoC series SCU Registers
+
+This system clock unit contain various register that control block resets,
+clock enable/disables, clock divisors and other deepsleep registers.
+
+Properties:
+ - compatible : should contain two values. First value must be:
+  - "apm,xgene-scu"
+   second value must be always "syscon".
+
+ - reg : offset and length of the register set.
+
+Example :
+   scu: system-clk-controller@1700 {
+   compatible = "apm,xgene-scu","syscon";
+   reg = <0x0 0x1700 0x0 0x400>;
+   };
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 0/7] APM X-Gene SoC platform device tree cleanup

[Feng Kan]

This sums up the dts changes of the recent committed drivers into the kernel.
This will grant PMU, reboot, USB and gpio functionalities to the platform.
These patches are all based on existing and approved driver that is in the
kernel tree today.

V3 Changes:
- add comments regarding usb node
- change dwgpio node name to gpio

V2 Changes:
- add dma-coherent attribute for usb node.

Feng Kan (7):
  arm64: dts: Add APM X-Gene USB DTS node
  Documentation: arm64: add SCU dts binding documentation to linux
kernel
  arm64: dts: Add X-Gene reboot driver dts node
  arm64: dts: Add Designware GPIO dts binding to APM X-Gene platform
  arm64: dts: Add APM X-Gene SoC GFC GPIO controller DTS entries
  Documentation: arm: pmu: Add Potenza PMU binding
  arm64: dts: Add PMU node for APM X-Gene Storm SOC

 Documentation/devicetree/bindings/arm/apm/scu.txt |   17 ++
 Documentation/devicetree/bindings/arm/pmu.txt |1 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi|   58 +
 3 files changed, 76 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 4/7] arm64: dts: Add Designware GPIO dts binding to APM X-Gene platform

[Feng Kan]

Add Designware GPIO dts binding to APM X-Gene platform

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f31e8df..a58f9a2 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -525,6 +525,21 @@
interrupts = <0x0 0x4f 0x4>;
};
 
+   dwgpio: gpio@1c024000 {
+   compatible = "snps,dw-apb-gpio";
+   reg = <0x0 0x1c024000 0x0 0x1000>;
+   reg-io-width = <4>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   porta: gpio-controller@0 {
+   compatible = "snps,dw-apb-gpio-port";
+   gpio-controller;
+   snps,nr-gpios = <32>;
+   reg = <0>;
+   };
+   };
+
phy1: phy@1f21a000 {
compatible = "apm,xgene-phy";
reg = <0x0 0x1f21a000 0x0 0x100>;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 6/7] Documentation: arm: pmu: Add Potenza PMU binding

[Feng Kan]

This patch documents the compatible string for APM X-Gene Potenza CPU's PMU.

Signed-off-by: Vinayak Kale 
Signed-off-by: Feng Kan 
---
 Documentation/devicetree/bindings/arm/pmu.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/pmu.txt 
b/Documentation/devicetree/bindings/arm/pmu.txt
index 75ef91d..6d268b3 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -7,6 +7,7 @@ representation in the device tree should be done as under:-
 Required properties:
 
 - compatible : should be one of
+   "apm,potenza-pmu"
"arm,armv8-pmuv3"
"arm,cortex-a17-pmu"
"arm,cortex-a15-pmu"
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 1/7] arm64: dts: Add APM X-Gene USB DTS node

[Feng Kan]

This parch adds the device tree nodes for APM X-Gnene USB host controller.
Since X-Gene SOC supports maximum 2 USB ports, 2 dts node are added.

Signed-off-by: Bao Truong 
Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f1ad9c2..4b2ec83 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -587,6 +587,25 @@
phy-names = "sata-phy";
};
 
+   /*
+* Do not change dwusb name, coded for backward compatibility
+*/
+   usb0: dwusb@1900 {
+   status = "disabled";
+   compatible = "xhci-platform";
+   reg =  <0x0 0x1900 0x0 0x10>;
+   interrupts = <0x0 0x89 0x4>;
+   dma-coherent;
+   };
+
+   usb1: dwusb@1980 {
+   status = "disabled";
+   compatible = "xhci-platform";
+   reg =  <0x0 0x1980 0x0 0x10>;
+   interrupts = <0x0 0x8a 0x4>;
+   dma-coherent;
+   };
+
rtc: rtc@1051 {
compatible = "apm,xgene-rtc";
reg = <0x0 0x1051 0x0 0x400>;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 7/7] arm64: dts: Add PMU node for APM X-Gene Storm SOC

[Feng Kan]

This patch adds the PMU device tree node for APM X-Gene Storm SOC.

Signed-off-by: Vinayak Kale 
Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index adea254..9d00dd4 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -97,6 +97,11 @@
clock-frequency = <5000>;
};
 
+   pmu {
+   compatible = "apm,potenza-pmu", "arm,armv8-pmuv3";
+   interrupts = <1 12 0xff04>;
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 5/7] arm64: dts: Add APM X-Gene SoC GFC GPIO controller DTS entries

[Feng Kan]

Add the flash controller muxed gpio dts node for APM X-Gene SoC platform.

Signed-off-by: Feng Kan 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index a58f9a2..adea254 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -540,6 +540,13 @@
};
};
 
+   gfcgpio: gpio0@1701c000 {
+   compatible = "apm,xgene-gpio";
+   reg = <0x0 0x1701c000 0x0 0x40>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
phy1: phy@1f21a000 {
compatible = "apm,xgene-phy";
reg = <0x0 0x1f21a000 0x0 0x100>;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sata: xgene: add ACPI support for APM X-Gene SATA ports

[Feng Kan]

Just want to ping this again.

Happy new year

On Thu, Dec 11, 2014 at 2:31 PM, Feng Kan  wrote:
> This adds ACPI support for the APM X-Gene SATA ports. When the system
> boots using ACPI table, the SATA ports are able to configure using the
> values supplied by the ACPI table rather than the DTS.
>
> Signed-off-by: Feng Kan 
> ---
>  drivers/ata/ahci_xgene.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index d0c851a..4951392 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -22,6 +22,7 @@
>   * NOTE: PM support is not currently available.
>   *
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -521,6 +522,14 @@ disable_resources:
> return rc;
>  }
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id xgene_ahci_acpi_match[] = {
> +   { "APMC0D0D", },
> +   { }
> +};
> +MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
> +#endif
> +
>  static const struct of_device_id xgene_ahci_of_match[] = {
> {.compatible = "apm,xgene-ahci"},
> {},
> @@ -534,6 +543,7 @@ static struct platform_driver xgene_ahci_driver = {
> .name = "xgene-ahci",
> .owner = THIS_MODULE,
> .of_match_table = xgene_ahci_of_match,
> +   .acpi_match_table = ACPI_PTR(xgene_ahci_acpi_match),
> },
>  };
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3] net: eth: xgene: change APM X-Gene SoC platform ethernet to support ACPI

[Feng Kan]

This adds support for APM X-Gene ethernet driver to use ACPI table to derive
ethernet driver parameter.

Signed-off-by: Feng Kan 
---
V3:
   - Fix compile error caught by allmodconfig
V2:
   - remove NO_MAC define
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c   |   94 --
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |   97 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |3 +
 3 files changed, 150 insertions(+), 44 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 7ba83ff..869d97f 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -593,10 +593,12 @@ static int xgene_enet_reset(struct xgene_enet_pdata 
*pdata)
if (!xgene_ring_mgr_init(pdata))
return -ENODEV;
 
-   clk_prepare_enable(pdata->clk);
-   clk_disable_unprepare(pdata->clk);
-   clk_prepare_enable(pdata->clk);
-   xgene_enet_ecc_init(pdata);
+   if (!efi_enabled(EFI_BOOT)) {
+   clk_prepare_enable(pdata->clk);
+   clk_disable_unprepare(pdata->clk);
+   clk_prepare_enable(pdata->clk);
+   xgene_enet_ecc_init(pdata);
+   }
xgene_enet_config_ring_if_assoc(pdata);
 
/* Enable auto-incr for scanning */
@@ -663,15 +665,20 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
struct phy_device *phy_dev;
struct device *dev = &pdata->pdev->dev;
 
-   phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
-   if (!phy_np) {
-   netdev_dbg(ndev, "No phy-handle found\n");
-   return -ENODEV;
+   if (dev->of_node) {
+   phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
+   if (!phy_np) {
+   netdev_dbg(ndev, "No phy-handle found in DT\n");
+   return -ENODEV;
+   }
+   pdata->phy_dev = of_phy_find_device(phy_np);
}
 
-   phy_dev = of_phy_connect(ndev, phy_np, &xgene_enet_adjust_link,
-0, pdata->phy_mode);
-   if (!phy_dev) {
+   phy_dev = pdata->phy_dev;
+
+   if (!phy_dev ||
+   phy_connect_direct(ndev, phy_dev, &xgene_enet_adjust_link,
+  pdata->phy_mode)) {
netdev_err(ndev, "Could not connect to PHY\n");
return  -ENODEV;
}
@@ -681,32 +688,71 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
  ~SUPPORTED_100baseT_Half &
  ~SUPPORTED_1000baseT_Half;
phy_dev->advertising = phy_dev->supported;
-   pdata->phy_dev = phy_dev;
 
return 0;
 }
 
-int xgene_enet_mdio_config(struct xgene_enet_pdata *pdata)
+static int xgene_mdiobus_register(struct xgene_enet_pdata *pdata,
+ struct mii_bus *mdio)
 {
-   struct net_device *ndev = pdata->ndev;
struct device *dev = &pdata->pdev->dev;
+   struct net_device *ndev = pdata->ndev;
+   struct phy_device *phy;
struct device_node *child_np;
struct device_node *mdio_np = NULL;
-   struct mii_bus *mdio_bus;
int ret;
+   u32 phy_id;
+
+   if (dev->of_node) {
+   for_each_child_of_node(dev->of_node, child_np) {
+   if (of_device_is_compatible(child_np,
+   "apm,xgene-mdio")) {
+   mdio_np = child_np;
+   break;
+   }
+   }
 
-   for_each_child_of_node(dev->of_node, child_np) {
-   if (of_device_is_compatible(child_np, "apm,xgene-mdio")) {
-   mdio_np = child_np;
-   break;
+   if (!mdio_np) {
+   netdev_dbg(ndev, "No mdio node in the dts\n");
+   return -ENXIO;
}
-   }
 
-   if (!mdio_np) {
-   netdev_dbg(ndev, "No mdio node in the dts\n");
-   return -ENXIO;
+   return of_mdiobus_register(mdio, mdio_np);
}
 
+   /* Mask out all PHYs from auto probing. */
+   mdio->phy_mask = ~0;
+
+   /* Register the MDIO bus */
+   ret = mdiobus_register(mdio);
+   if (ret)
+   return ret;
+
+   ret = device_property_read_u32(dev, "phy-channel", &phy_id);
+   if (ret)
+   ret = device_property_read_u32(dev, "phy-addr", &phy_id);
+   if (ret)
+   return -EINVAL;
+
+   phy = get_phy_device(mdio, phy_id, true);
+   if (!phy || IS_ERR(phy))
+   return