Re: [PATCH] kvm: better MWAIT emulation for guests

[Wanpeng Li]

Cc Peterz,
2017-03-10 9:12 GMT+08:00 Michael S. Tsirkin :
> On Thu, Mar 09, 2017 at 07:51:27PM -0500, Gabriel L. Somlo wrote:
>> On Fri, Mar 10, 2017 at 12:29:31AM +0200, Michael S. Tsirkin wrote:
>> > Some guests call mwait without checking the cpu flags.  We currently
>> > emulate that as a NOP but on VMX we can do better: let guest stop the
>> > CPU until timer or IPI.  CPU will be busy but that isn't any worse than
>> > a NOP emulation.
>>
>> Are you getting an IPI if another VCPU writes to the MONITOR-ed memory
>> location?
>
> In my testing yes.

Why there is still an IPI if monitor/mwait is used in guest?

>
>> If not, you'd be waking up too late and fail to meet the
>> specified behavior of the MONITOR/MWAIT instruction pair.
>>
>> > Note that mwait within guests is not the same as on real hardware
>> > because you must halt if you want to go deep into sleep.  Thus it isn't
>> > a good idea to use the regular MWAIT flag in CPUID for that.  Add a flag
>> > in the hypervisor leaf instead.
>>
>> Is it a good idea to advertise MWAIT capability to guests?
>
> I think it isn't so this patch does not do it.
>
>> The
>> misbehaving ones will call it willy-nilly, true, but aren't compliant
>> ones better off falling back to some alternative method (typically
>> using a HLT-based idle loop instead of a MONITOR/MWAIT based one) ?
>>
>> Thanks,
>> --Gabriel
>>

[...]

>> > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct 
>> > kvm_cpuid_entry2 *entry, u32 function,
>> > if (sched_info_on())
>> > entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
>> >
>> > +   if (this_cpu_has(X86_FEATURE_MWAIT))
>> > +   entry->eax = (1 << KVM_FEATURE_MWAIT);

s/"="/"|=", otherwise you almost kill other features.

Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Error in make linkcheckdocs

[Remy Leone]

Hello,

I've noticed that this bug started to happen :

When I try to launch make linkcheckdocs, the build block and cannot 
either fail or return. When launching the command :


sphinx-build . output -b linkcheck -vvv

from the Documentation directory, I get the following error:

SystemMessage: 
/media/sieben/Elastic/linux/Documentation/media/uapi/cec/cec-header.rst:9: 
(SEVERE/4) Problems with "kernel-include" directive path:
InputError: [Errno 2] No such file or directory: 
'/media/sieben/Elastic/linux/Documentation/$BUILDDIR/cec.h.rst'.


reST markup error:
/media/sieben/Elastic/linux/Documentation/media/uapi/cec/cec-header.rst:9: 
(SEVERE/4) Problems with "kernel-include" directive path:
InputError: [Errno 2] No such file or directory: 
'/media/sieben/Elastic/linux/Documentation/$BUILDDIR/cec.h.rst'.


The strange thing is that this file actually do exists: output/cec.h.rst

Any ideas about how to solve this?

Best regards

Rémy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Error in make linkcheckdocs

[Jani Nikula]

On Mon, 13 Mar 2017, Remy Leone  wrote:
> Hello,
>
> I've noticed that this bug started to happen :

Please always try to identify the commit where you see this fails, and
the commit where this worked. And from there on, 'git bisect' is your
friend.

> When I try to launch make linkcheckdocs, the build block and cannot 
> either fail or return. When launching the command :
>
> sphinx-build . output -b linkcheck -vvv
>
> from the Documentation directory, I get the following error:

Sadly, the media documentation have make based prerequisites to running
Sphinx, and you have to run the documentation targets using 'make' from
the kernel source root, e.g. 'make linkcheckdocs', to have them built.

The media rules generate stuff in the output directory, but Sphinx
itself makes it hard to include stuff from the output directory back
into the documentation. So there's a special "kernel-include" directive
that parses environment variables in the argument, and $BUILDDIR gets
used. You'll have to have BUILDDIR environment variable set. You can see
from your error messages that the variable was not expanded.

So please use make to run Sphinx, and have the prerequisites
generated. After that, you can achieve what you want by running

BUILDDIR=output sphinx-build . output -b linkcheck

in the Documentation directory, but it won't update the prerequisites.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 09-03-2017 14:27, Jose Abreu wrote:
> Hi Neil,
>
>
> On 08-03-2017 12:12, Neil Armstrong wrote:
>> Hi Jose,
>>
>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
>> Amlogic
>> source I have the following for 10bit, 12bit and 16bit for itu601 :
>>
>> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x043b },
>>  { 0x2000, 0x2cdd, 0x, 0x7a65 },
>>  { 0x2000, 0x, 0x38b4, 0x78ea }
>> };
>>
>> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x10ee },
>>  { 0x2000, 0x2cdd, 0x, 0x6992 },
>>  { 0x2000, 0x, 0x38b4, 0x63a6 }
>> };
> These two do not match anything I have here.
>
>> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x0800 },
>>  { 0x6acd, 0x7534, 0x2000, 0x0800 }
>> };
> This is more or less correct, I have small offsets. Note that I
> even have offsets with the values that are in dw-hdmi driver,
> which can be caused because I'm seeing the latest document that
> contain these values. I guess they were updated.
>
>> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x2000 },
>>  { 0x6acd, 0x7534, 0x2000, 0x2000 }
>> };
> The same for this.
>
>> But I miss the itu709 values.
>>
>> Could you confirm these values and maybe provide the itu709 values ?
> I will have to check if I can provide you the values. I will get
> back to you.

Sorry but looks like I won't be able to provide you the correct
values :/ If you are working for a Synopsys customer you can
contact our CAE (If so I can guide you to the correct CAE).

Anyway, unless you can test the values you have I suggest you
don't use them, they do not match what I have here and I can't
test them because right now I don't have a setup (I'm assuming
that your CSC block within the controller was not modified).

Best regards,
Jose Miguel Abreu

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

[PATCH 0/3] Documentation: admin-guide: Fix typos

[Tamara Diaconita]

Fix typos in admin-guide directory to make documentation more readable.
Typos found with 'aspell -c ' command.

Tamara Diaconita (3):
  Documentation: admin-guide: Fix typos
  Documentation: admin-guide: Fix typos
  Documentation: admin-guide: Fix typos

 Documentation/admin-guide/kernel-parameters.rst |  4 ++--
 Documentation/admin-guide/ras.rst   | 14 +++---
 Documentation/admin-guide/tainted-kernels.rst   |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.9.3

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

[PATCH 1/3] Documentation: admin-guide: Fix typos

[Tamara Diaconita]

Fix typos in kernel-parameters.rst file.

Signed-off-by: Tamara Diaconita 
---
 Documentation/admin-guide/kernel-parameters.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index b516164..eaf9c62 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -197,10 +197,10 @@ and is between 256 and 4096 characters. It is defined in 
the file
 
 Finally, the [KMG] suffix is commonly described after a number of kernel
 parameter values. These 'K', 'M', and 'G' letters represent the _binary_
-multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
+multipliers 'Kilo', 'Mega', and 'Giga', equaling 2^10, 2^20, and 2^30
 bytes respectively. Such letter suffixes can also be entirely omitted:
 
-.. include:: kernel-parameters.txt
+.. include:: kernel-parameters.TNT
:literal:
 
 Todo
-- 
2.9.3

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

[PATCH 2/3] Documentation: admin-guide: Fix typos

[Tamara Diaconita]

Fix typos in ras.rst file.

Signed-off-by: Tamara Diaconita 
---
 Documentation/admin-guide/ras.rst | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/ras.rst 
b/Documentation/admin-guide/ras.rst
index 1b90c6f..2656065 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -8,7 +8,7 @@ RAS concepts
 
 
 Reliability, Availability and Serviceability (RAS) is a concept used on
-servers meant to measure their robusteness.
+servers meant to measure their robustness.
 
 Reliability
   is the probability that a system will produce correct outputs.
@@ -42,13 +42,13 @@ Among the monitoring measures, the most usual ones include:
 
 * CPU – detect errors at instruction execution and at L1/L2/L3 caches;
 * Memory – add error correction logic (ECC) to detect and correct errors;
-* I/O – add CRC checksums for tranfered data;
+* I/O – add CRC checksums for transferred data;
 * Storage – RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
 to identify if the probability of hardware errors is increasing, and, on such
-case, do a preventive maintainance to replace a degrated component while
+case, do a preventive maintenance to replace a degraded component while
 those errors are correctable.
 
 Types of errors
@@ -121,7 +121,7 @@ using the ``dmidecode`` tool. For example, on a desktop 
machine, it shows::
 On the above example, a DDR4 SO-DIMM memory module is located at the
 system's memory labeled as "BANK 0", as given by the *bank locator* field.
 Please notice that, on such system, the *total width* is equal to the
-*data witdh*. It means that such memory module doesn't have error
+*data width*. It means that such memory module doesn't have error
 detection/correction mechanisms.
 
 Unfortunately, not all systems use the same field to specify the memory
@@ -145,7 +145,7 @@ bank. On this example, from an older server, ``dmidecode`` 
shows::
 
 There, the DDR3 RDIMM memory module is located at the system's memory labeled
 as "DIMM_A1", as given by the *locator* field. Please notice that this
-memory module has 64 bits of *data witdh* and 72 bits of *total width*. So,
+memory module has 64 bits of *data width* and 72 bits of *total width*. So,
 it has 8 extra bits to be used by error detection and correction mechanisms.
 Such kind of memory is called Error-correcting code memory (ECC memory).
 
@@ -186,7 +186,7 @@ Architecture (MCA)\ [#f3]_.
 .. [#f1] Please notice that several memory controllers allow operation on a
   mode called "Lock-Step", where it groups two memory modules together,
   doing 128-bit reads/writes. That gives 16 bits for error correction, with
-  significatively improves the error correction mechanism, at the expense
+  significantly improves the error correction mechanism, at the expense
   that, when an error happens, there's no way to know what memory module is
   to blame. So, it has to blame both memory modules.
 
@@ -1048,7 +1048,7 @@ found on newer Intel CPUs, such as ``i7core_edac``, 
``sb_edac`` and
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
 
-   To return to the default behaviour of matching any, you can do::
+   To return to the default behavior of matching any, you can do::
 
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
-- 
2.9.3

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

[PATCH 3/3] Documentation: admin-guide: Fix typos

[Tamara Diaconita]

Fix typos in tainted-kernels.rst file.

Signed-off-by: Tamara Diaconita 
---
 Documentation/admin-guide/tainted-kernels.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/tainted-kernels.rst 
b/Documentation/admin-guide/tainted-kernels.rst
index 1df03b5..f96e8a5 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -8,7 +8,7 @@ characters, each representing a particular tainted value.
 
   1) 'G' if all modules loaded have a GPL or compatible license, 'P' if
  any proprietary module has been loaded.  Modules without a
- MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by
+ MODULE_LICENSE or with a MODULE_LICENSE that is not recognized by
  insmod as GPL compatible are assumed to be proprietary.
 
   2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
-- 
2.9.3

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

Re: [PATCH 1/3] Documentation: admin-guide: Fix typos

[Jani Nikula]

On Mon, 13 Mar 2017, Tamara Diaconita  wrote:
> -.. include:: kernel-parameters.txt
> +.. include:: kernel-parameters.TNT

Huh?

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: admin-guide: Fix typos

[Jonathan Corbet]

On Mon, 13 Mar 2017 13:44:56 +0200
Tamara Diaconita  wrote:

> Fix typos in kernel-parameters.rst file.

So your fixes are generally good, but...

>  
> -.. include:: kernel-parameters.txt
> +.. include:: kernel-parameters.TNT
> :literal:

...this one show a bit of inattention to the end result.  It also makes it
clear that you didn't build the docs after doing your work - something you
should always do after changing the formatted docs.  Could you add that to
your workflow and redo the patch set, please?

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: admin-guide: Fix typos

[Jonathan Corbet]

On Mon, 13 Mar 2017 13:47:39 +0200
Tamara Diaconita  wrote:

This set is good, but with one quibble:

> @@ -1048,7 +1048,7 @@ found on newer Intel CPUs, such as ``i7core_edac``, 
> ``sb_edac`` and
>   echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
>   echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
>  
> - To return to the default behaviour of matching any, you can do::
> + To return to the default behavior of matching any, you can do::
>  
>   echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
>   echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank

That's a British spelling.  We have long accepted both British and
American spellings in the kernel tree.  Thus, for example, there are 930
occurrences of "behaviour", 204 of which are under Documentation.  They
are best left as they are.

(Part 3 had some similar changes).

As I said in the other reply, it's a good start, and you have fixed quite
a few genuine mistakes.  It would be great if you could regenerate the
series with these comments in mind, and I'll be happy to apply it.

(When you do so, if you could get the patches threaded under the 0/3
intro, that would be helpful as well.  "git send-email" can be your
friend in that regard.)

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 09/23] PCI: dwc: designware: Add EP mode support

[Kishon Vijay Abraham I]

Add endpoint mode support to designware driver. This uses the
EP Core layer introduced recently to add endpoint mode support.
*Any* function driver can now use this designware device
in order to achieve the EP functionality.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/Kconfig  |   5 +
 drivers/pci/dwc/Makefile |   1 +
 drivers/pci/dwc/pcie-designware-ep.c | 342 +++
 drivers/pci/dwc/pcie-designware.c| 125 +
 drivers/pci/dwc/pcie-designware.h| 105 +++
 5 files changed, 578 insertions(+)
 create mode 100644 drivers/pci/dwc/pcie-designware-ep.c

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index dfb8a69afc28..00335c71404e 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -9,6 +9,11 @@ config PCIE_DW_HOST
depends on PCI_MSI_IRQ_DOMAIN
 select PCIE_DW
 
+config PCIE_DW_EP
+   bool
+   depends on PCI_ENDPOINT
+   select PCIE_DW
+
 config PCI_DRA7XX
bool "TI DRA7xx PCIe controller"
depends on PCI
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index a2df13c28798..b38425d36200 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
+obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
new file mode 100644
index ..398406393f37
--- /dev/null
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -0,0 +1,342 @@
+/**
+ * Synopsys Designware PCIe Endpoint controller driver
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+
+#include "pcie-designware.h"
+#include 
+#include 
+
+void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
+{
+   struct pci_epc *epc = ep->epc;
+
+   pci_epc_linkup(epc);
+}
+
+static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
+{
+   u32 reg;
+
+   reg = PCI_BASE_ADDRESS_0 + (4 * bar);
+   dw_pcie_writel_dbi2(pci, reg, 0x0);
+   dw_pcie_writel_dbi(pci, reg, 0x0);
+}
+
+static int dw_pcie_ep_write_header(struct pci_epc *epc,
+  struct pci_epf_header *hdr)
+{
+   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+   dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
+   dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
+   dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
+   dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
+   dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
+  hdr->subclass_code | hdr->baseclass_code << 8);
+   dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
+  hdr->cache_line_size);
+   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
+  hdr->subsys_vendor_id);
+   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
+   dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
+  hdr->interrupt_pin);
+
+   return 0;
+}
+
+static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
+ dma_addr_t cpu_addr,
+ enum dw_pcie_as_type as_type)
+{
+   int ret;
+   u32 free_win;
+   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+   free_win = find_first_zero_bit(&ep->ib_window_map,
+  sizeof(ep->ib_window_map));
+   if (free_win >= ep->num_ib_windows) {
+   dev_err(pci->dev, "no free inbound window\n");
+   return -EINVAL;
+   }
+
+   ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
+  as_type);
+   if (ret < 0) {
+   dev_err(pci->dev, "Failed to program IB window\n");
+   return ret;
+   }
+
+   ep->bar_to_atu[bar] = free_win;
+   set_bit(free_win, &ep->ib_window_map);
+
+   return 0;
+}
+
+static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t 
phys_addr,
+ 

[GIT PULL 00/23] PCI: Support for configurable PCI endpoint

[Kishon Vijay Abraham I]

Please find the pull request for PCI endpoint support below. I've
also included all the history here.

Changes from v3:
*) fixed a typo and adapted to https://lkml.org/lkml/2017/3/13/562.

Changes from v2:
*) changed the configfs structure as suggested by Christoph Hellwig. With
   this change the framework creates configfs entry for EP function driver
   and EP controller. Previously these entries have to be created by the
   the user. (Haven't changed the epc core or epf core except for invoking
   configfs APIs to create entries for EP function driver and EP controller.
   That's mostly because the EP function device can still be created by
   directly invoking the epf core API without using configfs).
*) Now the user has to use configfs entry 'start' to start the link.
   This was previously done by the function driver. However in the case of
   multi function EP, the function driver shouldn't start the link.

Changes from v1:
*) The preparation patches for adding EP support is removed and is sent
   separately
*) Added device ID for DRA74x/DRA72x and used it instead of
   using "PCI_ANY_ID"
*) Added userguide for PCI endpoint test function

Major Improvements from RFC:
 *) support multi-function devices (hw supported not virtual)
 *) Access host side buffers
 *) Raise MSI interrupts
 *) Add user space program to use the host side PCI driver
 *) Adapt all other users of designware to use the new design (only
compile tested. Since I have only dra7xx boards, the new design
has only been tested in dra7xx. I'd require the help of others
to test the platforms they have access to).

This series has been developed over 4.11-rc1 + [1]

[1] -> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1348667.html

The following changes since commit 29b1586a2e7d564dd801c5792122bdf00fab0cec:

  PCI: dwc: dra7xx: Push request_irq call to the bottom of probe (2017-03-13 
19:17:10 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git 
tags/pci-endpoint-for-4.12

for you to fetch changes up to 6a02235543fb24f2468cba3b02f75d6c44ff9262:

  ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP 
(2017-03-13 19:23:04 +0530)


pci: endpoint: for 4.12

 *) Add PCI endpoint core layer
 *) Modify designware and dra7xx driver to be configured in EP mode
 *) Add a PCI endpoint *test* function driver and corresponding host
driver

Signed-off-by: Kishon Vijay Abraham I 


Kishon Vijay Abraham I (23):
  PCI: endpoint: Add EP core layer to enable EP controller and EP functions
  Documentation: PCI: Guide to use PCI Endpoint Core Layer
  PCI: endpoint: Introduce configfs entry for configuring EP functions
  Documentation: PCI: Guide to use pci endpoint configfs
  PCI: endpoint: Create configfs entry for EPC device and EPF driver
  Documentation: PCI: Add specification for the *pci test* function device
  PCI: endpoint: functions: Add an EP function to test PCI
  Documentation: PCI: Add binding documentation for pci-test endpoint 
function
  PCI: dwc: designware: Add EP mode support
  dt-bindings: PCI: Add dt bindings for pci designware EP mode
  PCI: dwc: dra7xx: Facilitate wrapper and msi interrupts to be enabled 
independently
  PCI: dwc: dra7xx: Add EP mode support
  dt-bindings: PCI: dra7xx: Add dt bindings for pci dra7xx EP mode
  PCI: dwc: dra7xx: Workaround for errata id i870
  dt-bindings: PCI: dra7xx: Add dt bindings to enable unaligned access
  PCI: Add device IDs for DRA74x and DRA72x
  misc: Add host side pci driver for pci test function device
  Documentation: misc-devices: Add Documentation for pci-endpoint-test 
driver
  tools: PCI: Add a userspace tool to test PCI endpoint
  tools: PCI: Add sample test script to invoke pcitest
  Documentation: PCI: Add userguide for PCI endpoint test function
  MAINTAINERS: add PCI EP maintainer
  ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to 
SW_WKUP

 Documentation/PCI/00-INDEX|  10 +++
 Documentation/PCI/endpoint/function/binding/pci-test.txt  |  17 +
 Documentation/PCI/endpoint/pci-endpoint-cfs.txt   | 105 
++
 Documentation/PCI/endpoint/pci-endpoint.txt   | 215 

 Documentation/PCI/endpoint/pci-test-function.txt  |  66 

 Documentation/PCI/endpoint/pci-test-howto.txt | 179 
+++
 Documentation/devicetree/bindings/pci/designware-pcie.txt |  26 +--
 Documentation/devicetree/bindings/pci/ti-pci.txt  |  42 +--
 Documentation/misc-devices/pci-endpoint-test.txt  |  35 +
 MAINTAINERS   

[PATCH v4 08/23] Documentation: PCI: Add binding documentation for pci-test endpoint function

[Kishon Vijay Abraham I]

Add binding documentation for pci-test endpoint function that helps in
adding and configuring pci-test endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX  |  2 ++
 .../PCI/endpoint/function/binding/pci-test.txt  | 17 +
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 4e5a2832f4e7..53717b7fcdd4 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -18,3 +18,5 @@ endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the pci endpoint function.
 endpoint/pci-test-function.txt
- specification of *pci test* function device.
+endpoint/function/binding/
+   - binding documentation for pci endpoint function
diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
b/Documentation/PCI/endpoint/function/binding/pci-test.txt
new file mode 100644
index ..c44fc18d78cc
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
@@ -0,0 +1,17 @@
+PCI TEST ENDPOINT FUNCTION
+
+name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
+
+Configurable Fields:
+vendorid: should be 0x104c
+deviceid: should be 0xb500 for DRA74x and 0xb501 for DRA72x
+revid   : don't care
+progif_code : don't care
+subclass_code   : don't care
+baseclass_code  : should be 0xff
+cache_line_size : don't care
+subsys_vendor_id : don't care
+subsys_id   : don't care
+interrupt_pin   : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
+msi_interrupts  : Should be 1 to 32 depending on the number of msi interrupts
+  to test
-- 
2.11.0

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

[PATCH v4 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions

[Kishon Vijay Abraham I]

Introduce a new EP core layer in order to support endpoint functions
in linux kernel. This comprises of EPC library
(Endpoint Controller Library) and EPF library (Endpoint
Function Library). EPC library implements functions that is specific
to an endpoint controller and EPF library implements functions
that is specific to an endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/Makefile|   2 +
 drivers/pci/Kconfig |   1 +
 drivers/pci/endpoint/Kconfig|  20 ++
 drivers/pci/endpoint/Makefile   |   6 +
 drivers/pci/endpoint/pci-epc-core.c | 575 
 drivers/pci/endpoint/pci-epc-mem.c  | 143 +
 drivers/pci/endpoint/pci-epf-core.c | 347 ++
 include/linux/mod_devicetable.h |  10 +
 include/linux/pci-epc.h | 142 +
 include/linux/pci-epf.h | 160 ++
 10 files changed, 1406 insertions(+)
 create mode 100644 drivers/pci/endpoint/Kconfig
 create mode 100644 drivers/pci/endpoint/Makefile
 create mode 100644 drivers/pci/endpoint/pci-epc-core.c
 create mode 100644 drivers/pci/endpoint/pci-epc-mem.c
 create mode 100644 drivers/pci/endpoint/pci-epf-core.c
 create mode 100644 include/linux/pci-epc.h
 create mode 100644 include/linux/pci-epf.h

diff --git a/drivers/Makefile b/drivers/Makefile
index 2eced9afba53..a5f8e43b2c4d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -14,7 +14,9 @@ obj-$(CONFIG_GENERIC_PHY) += phy/
 obj-$(CONFIG_PINCTRL)  += pinctrl/
 obj-$(CONFIG_GPIOLIB)  += gpio/
 obj-y  += pwm/
+
 obj-$(CONFIG_PCI)  += pci/
+obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
 # PCI dwc controller drivers
 obj-y  += pci/dwc/
 
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index df141420c902..9747c1ec8c74 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -134,3 +134,4 @@ config PCI_HYPERV
 source "drivers/pci/hotplug/Kconfig"
 source "drivers/pci/dwc/Kconfig"
 source "drivers/pci/host/Kconfig"
+source "drivers/pci/endpoint/Kconfig"
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
new file mode 100644
index ..a5442ace7077
--- /dev/null
+++ b/drivers/pci/endpoint/Kconfig
@@ -0,0 +1,20 @@
+#
+# PCI Endpoint Support
+#
+
+menu "PCI Endpoint"
+
+config PCI_ENDPOINT
+   bool "PCI Endpoint Support"
+   help
+  Enable this configuration option to support configurable PCI
+  endpoint. This should be enabled if the platform has a PCI
+  controller that can operate in endpoint mode.
+
+  Enabling this option will build the endpoint library, which
+  includes endpoint controller library and endpoint function
+  library.
+
+  If in doubt, say "N" to disable Endpoint support.
+
+endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
new file mode 100644
index ..dc1bc16491e6
--- /dev/null
+++ b/drivers/pci/endpoint/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for PCI Endpoint Support
+#
+
+obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
+  pci-epc-mem.o
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
new file mode 100644
index ..06808ed7ee1f
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -0,0 +1,575 @@
+/**
+ * PCI Endpoint *Controller* (EPC) library
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct class *pci_epc_class;
+
+static void devm_pci_epc_release(struct device *dev, void *res)
+{
+   struct pci_epc *epc = *(struct pci_epc **)res;
+
+   pci_epc_destroy(epc);
+}
+
+static int devm_pci_epc_match(struct device *dev, void *res, void *match_data)
+{
+   struct pci_epc **epc = res;
+
+   return *epc == match_data;
+}
+
+/**
+ * pci_epc_put() - release the pci endpoint controller
+ * @epc: epc returned by pci_epc_get()
+ *
+ * release the refcount the caller obtained by invoking pci_epc_get()
+ */
+void pci_epc_put(struct pci_epc *epc)
+{
+   if (!epc || IS_ERR(epc))
+   return;
+
+   module_put(epc->ops->owner);
+   put_device(&epc->dev);
+

[PATCH v4 23/23] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Kishon Vijay Abraham I]

The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
in RC mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

Acked-by: Tony Lindgren 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 6c679659cda5..67ebff829cf2 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm = {
.dep_bit  = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs   = pcie_wkup_sleep_deps,
.sleepdep_srcs= pcie_wkup_sleep_deps,
-   .flags= CLKDM_CAN_HWSUP_SWSUP,
+   .flags= CLKDM_CAN_SWSUP,
 };
 
 static struct clockdomain atl_7xx_clkdm = {
-- 
2.11.0

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

[PATCH v4 12/23] PCI: dwc: dra7xx: Add EP mode support

[Kishon Vijay Abraham I]

The PCIe controller integrated in dra7xx SoCs is capable of operating
in endpoint mode. Add endpoint mode support to dra7xx driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/Kconfig   |  31 +-
 drivers/pci/dwc/Makefile  |   4 +-
 drivers/pci/dwc/pci-dra7xx.c  | 197 +++---
 drivers/pci/dwc/pcie-designware.h |   7 ++
 4 files changed, 221 insertions(+), 18 deletions(-)

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index 00335c71404e..96e6d17d2ae1 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -16,14 +16,37 @@ config PCIE_DW_EP
 
 config PCI_DRA7XX
bool "TI DRA7xx PCIe controller"
-   depends on PCI
+   depends on (PCI && PCI_MSI_IRQ_DOMAIN) || PCI_ENDPOINT
depends on OF && HAS_IOMEM && TI_PIPE3
+   help
+Enables support for the PCIe controller in the DRA7xx SoC. There
+are two instances of PCIe controller in DRA7xx. This controller can
+work either as EP or RC. In order to enable host specific features
+PCI_DRA7XX_HOST must be selected and in order to enable device
+specific features PCI_DRA7XX_EP must be selected. This uses
+the Designware core.
+
+if PCI_DRA7XX
+
+config PCI_DRA7XX_HOST
+   bool "PCI DRA7xx Host Mode"
+   depends on PCI
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
+   default y
help
-Enables support for the PCIe controller in the DRA7xx SoC.  There
-are two instances of PCIe controller in DRA7xx.  This controller can
-act both as EP and RC.  This reuses the Designware core.
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+host mode.
+
+config PCI_DRA7XX_EP
+   bool "PCI DRA7xx Endpoint Mode"
+   depends on PCI_ENDPOINT
+   select PCIE_DW_EP
+   help
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+endpoint mode.
+
+endif
 
 config PCIE_DW_PLAT
bool "Platform bus based DesignWare PCIe Controller"
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index b38425d36200..f31a8596442a 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -2,7 +2,9 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
 obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
-obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
+ifneq ($(filter y,$(CONFIG_PCI_DRA7XX_HOST) $(CONFIG_PCI_DRA7XX_EP)),)
+obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
+endif
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index d78974d20360..35c18534469c 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -10,12 +10,14 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +59,11 @@
 #defineMSI BIT(4)
 #defineLEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
 
+#definePCIECTRL_TI_CONF_DEVICE_TYPE0x0100
+#defineDEVICE_TYPE_EP  0x0
+#defineDEVICE_TYPE_LEG_EP  0x1
+#defineDEVICE_TYPE_RC  0x4
+
 #definePCIECTRL_DRA7XX_CONF_DEVICE_CMD 0x0104
 #defineLTSSM_EN0x1
 
@@ -66,6 +73,13 @@
 
 #define EXP_CAP_ID_OFFSET  0x70
 
+#definePCIECTRL_TI_CONF_INTX_ASSERT0x0124
+#definePCIECTRL_TI_CONF_INTX_DEASSERT  0x0128
+
+#definePCIECTRL_TI_CONF_MSI_XMT0x012c
+#define MSI_REQ_GRANT  BIT(0)
+#define MSI_VECTOR_SHIFT   7
+
 struct dra7xx_pcie {
struct dw_pcie  *pci;
void __iomem*base;  /* DT ti_conf */
@@ -73,6 +87,11 @@ struct dra7xx_pcie {
struct phy  **phy;
int link_gen;
struct irq_domain   *irq_domain;
+   enum dw_pcie_device_mode mode;
+};
+
+struct dra7xx_pcie_of_data {
+   enum dw_pcie_device_mode mode;
 };
 
 #define to_dra7xx_pcie(x)  dev_get_drvdata((x)->dev)
@@ -101,9 +120,19 @@ static int dra7xx_pcie_link_up(struct dw_pcie *pci)
return !!(reg & LINK_UP);
 }
 
-static int dra7xx_pcie_establish_link(struct dra7xx_pcie *dra7xx)
+static void dra7xx_pcie_stop_link(struct dw_pcie *pci)
 {
-   struct dw_pcie *pci = dra7xx->pci;
+   struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
+   u32 reg;
+
+   reg = dr

[PATCH v4 21/23] Documentation: PCI: Add userguide for PCI endpoint test function

[Kishon Vijay Abraham I]

Add documentation to help users use pci-epf-test function driver
and pci_endpoint_test host driver for testing PCI.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX|   2 +
 Documentation/PCI/endpoint/pci-test-howto.txt | 179 ++
 2 files changed, 181 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-howto.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 53717b7fcdd4..fd533c79fa19 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -18,5 +18,7 @@ endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the pci endpoint function.
 endpoint/pci-test-function.txt
- specification of *pci test* function device.
+endpoint/pci-test-howto.txt
+   - userguide for PCI endpoint test function.
 endpoint/function/binding/
- binding documentation for pci endpoint function
diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt 
b/Documentation/PCI/endpoint/pci-test-howto.txt
new file mode 100644
index ..730b70c73055
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-howto.txt
@@ -0,0 +1,179 @@
+   PCI TEST USERGUIDE
+   Kishon Vijay Abraham I 
+
+This document is a guide to help users use pci-epf-test function driver
+and pci_endpoint_test host driver for testing PCI. The list of steps to
+be followed in the host side and EP side is given below.
+
+1. Endpoint Device
+
+1.1 Endpoint Controller Devices
+
+To find the list of endpoint controller devices in the system:
+
+   # ls /sys/class/pci_epc/
+ 5100.pcie_ep
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+   # ls /sys/kernel/config/pci_ep/controllers
+ 5100.pcie_ep
+
+1.2 Endpoint Function Drivers
+
+To find the list of endpoint function drivers in the system:
+
+   # ls /sys/bus/pci-epf/drivers
+ pci_epf_test
+
+If PCI_ENDPOINT_CONFIGFS is enabled
+   # ls /sys/kernel/config/pci_ep/functions
+ pci_epf_test
+
+1.3 Creating pci-epf-test Device
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-test device, the following commands can be used
+
+   # mount -t configfs none /sys/kernel/config
+   # cd /sys/kernel/config/pci_ep/
+   # mkdir functions/pci_epf_test/func1
+
+The "mkdir func1" above creates the pci-epf-test function device that will
+be probed by pci_epf_test driver.
+
+The PCI endpoint framework populates the directory with the following
+configurable fields.
+
+   # ls functions/pci_epf_test/func1
+ baseclass_codeinterrupt_pin   revid   subsys_vendor_id
+ cache_line_size   msi_interrupts  subclass_code   vendorid
+ deviceid  progif_code subsys_id
+
+The pci endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-test driver populates
+vendorid with 0x and interrupt_pin with 0x0001
+
+   # cat functions/pci_epf_test/func1/vendorid
+ 0x
+   # cat functions/pci_epf_test/func1/interrupt_pin
+ 0x0001
+
+1.4 Configuring pci-epf-test Device
+
+The user can configure the pci-epf-test device using configfs entry. In order
+to change the vendorid and the number of MSI interrupts used by the function
+device, the following commands can be used.
+
+   # echo 0x104c > functions/pci_epf_test/func1/vendorid
+   # echo 0xb500 > functions/pci_epf_test/func1/deviceid
+   # echo 16 > functions/pci_epf_test/func1/msi_interrupts
+
+1.5 Binding pci-epf-test Device to EP Controller
+
+In order for the endpoint function device to be useful, it has to be bound to
+a PCI endpoint controller driver. Use the configfs to bind the function
+device to one of the controller driver present in the system.
+
+   # ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
+
+Once the above step is completed, the PCI endpoint is ready to establish a link
+with the host.
+
+1.6 Start the Link
+
+In order for the endpoint device to establish a link with the host, the _start_
+field should be populated with '1'.
+
+   # echo 1 > controllers/5100.pcie_ep/start
+
+2. RootComplex Device
+
+2.1 lspci Output
+
+Note that the devices listed here correspond to the value populated in 1.4 
above
+
+   00:00.0 PCI bridge: Texas Instruments Device  (rev 01)
+   01:00.0 Unassigned class [ff00]: Texas Instruments Device b500
+
+2.2 Using Endpoint Test function Device
+
+pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
+tests. Before pcitest.sh can be used pcitest.c should be compiled using the
+following commands.
+
+   cd 
+   make headers_install ARCH=arm
+   arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
+   cp pcitest  /usr/sbin/
+   cp tools/pci/pcitest.sh 
+
+2.2.1 pcitest.sh Output
+   # ./pcitest.sh

[PATCH v4 17/23] misc: Add host side pci driver for pci test function device

[Kishon Vijay Abraham I]

Add PCI endpoint test driver that can verify base address
register, legacy interrupt/MSI interrupt and read/write/copy
buffers between host and device. The corresponding pci-epf-test
function driver should be used on the EP side.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/Kconfig |   7 +
 drivers/misc/Makefile|   1 +
 drivers/misc/pci_endpoint_test.c | 534 +++
 include/uapi/linux/Kbuild|   1 +
 include/uapi/linux/pcitest.h |  19 ++
 5 files changed, 562 insertions(+)
 create mode 100644 drivers/misc/pci_endpoint_test.c
 create mode 100644 include/uapi/linux/pcitest.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c290990d73ed..15ac29d7a840 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -771,6 +771,13 @@ config PANEL_BOOT_MESSAGE
 
 endif # PANEL
 
+config PCI_ENDPOINT_TEST
+   depends on PCI || COMPILE_TEST
+   tristate "PCI Endpoint Test driver"
+   ---help---
+   Enable this configuration option to enable the host side test driver
+   for PCI Endpoint.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7a3ea89339b4..6e139cd70421 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ECHO)+= echo/
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
 obj-$(CONFIG_PANEL) += panel.o
+obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
 
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_bugs.o
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
new file mode 100644
index ..5f4f8f8ff1c2
--- /dev/null
+++ b/drivers/misc/pci_endpoint_test.c
@@ -0,0 +1,534 @@
+/**
+ * Host side test driver to test endpoint functionality
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define DRV_MODULE_NAME"pci-endpoint-test"
+
+#define PCI_ENDPOINT_TEST_MAGIC0x0
+
+#define PCI_ENDPOINT_TEST_COMMAND  0x4
+#define COMMAND_RAISE_LEGACY_IRQ   BIT(0)
+#define COMMAND_RAISE_MSI_IRQ  BIT(1)
+#define MSI_NUMBER_SHIFT   2
+/* 6 bits for MSI number */
+#define COMMAND_READBIT(8)
+#define COMMAND_WRITE   BIT(9)
+#define COMMAND_COPYBIT(10)
+
+#define PCI_ENDPOINT_TEST_STATUS   0x8
+#define STATUS_READ_SUCCESS BIT(0)
+#define STATUS_READ_FAILBIT(1)
+#define STATUS_WRITE_SUCCESSBIT(2)
+#define STATUS_WRITE_FAIL   BIT(3)
+#define STATUS_COPY_SUCCESS BIT(4)
+#define STATUS_COPY_FAILBIT(5)
+#define STATUS_IRQ_RAISED   BIT(6)
+#define STATUS_SRC_ADDR_INVALID BIT(7)
+#define STATUS_DST_ADDR_INVALID BIT(8)
+
+#define PCI_ENDPOINT_TEST_LOWER_SRC_ADDR   0xc
+#define PCI_ENDPOINT_TEST_UPPER_SRC_ADDR   0x10
+
+#define PCI_ENDPOINT_TEST_LOWER_DST_ADDR   0x14
+#define PCI_ENDPOINT_TEST_UPPER_DST_ADDR   0x18
+
+#define PCI_ENDPOINT_TEST_SIZE 0x1c
+#define PCI_ENDPOINT_TEST_CHECKSUM 0x20
+
+static DEFINE_IDA(pci_endpoint_test_ida);
+
+#define to_endpoint_test(priv) container_of((priv), struct pci_endpoint_test, \
+   miscdev)
+enum pci_barno {
+   BAR_0,
+   BAR_1,
+   BAR_2,
+   BAR_3,
+   BAR_4,
+   BAR_5,
+};
+
+struct pci_endpoint_test {
+   struct pci_dev  *pdev;
+   void __iomem*base;
+   void __iomem*bar[6];
+   struct completion irq_raised;
+   int last_irq;
+   /* mutex to protect the ioctls */
+   struct mutexmutex;
+   struct miscdevice miscdev;
+};
+
+static int bar_size[] = { 4, 512, 1024, 16384, 131072, 1048576 };
+
+static inline u32 pci_endpoint_test_readl(struct pci_endpoint_test *test,
+ u32 offset)
+{
+   return readl(test->base + offset);
+}
+
+s

[PATCH v4 14/23] PCI: dwc: dra7xx: Workaround for errata id i870

[Kishon Vijay Abraham I]

According to errata i870, access to the PCIe slave port
that are not 32-bit aligned will result in incorrect mapping
to TLP Address and Byte enable fields.

Accessing non 32-bit aligned data causes incorrect data in the target
buffer if memcpy is used. Implement the workaround for this
errata here.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/pci-dra7xx.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 35c18534469c..147d37a7fe58 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "pcie-designware.h"
 
@@ -528,6 +530,51 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
{},
 };
 
+/*
+ * dra7xx_pcie_ep_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
+ * @dra7xx: the dra7xx device where the workaround should be applied
+ *
+ * Access to the PCIe slave port that are not 32-bit aligned will result
+ * in incorrect mapping to TLP Address and Byte enable fields. Therefore,
+ * byte and half-word accesses are not possible to byte offset 0x1, 0x2, or
+ * 0x3.
+ *
+ * To avoid this issue set PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE to 1.
+ */
+static int dra7xx_pcie_ep_unaligned_memaccess(struct device *dev)
+{
+   int ret;
+   struct device_node *np = dev->of_node;
+   struct regmap *regmap;
+   unsigned int reg;
+   unsigned int field;
+
+   regmap = syscon_regmap_lookup_by_phandle(np,
+"ti,syscon-unaligned-access");
+   if (IS_ERR(regmap)) {
+   dev_dbg(dev, "can't get ti,syscon-unaligned-access\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "ti,syscon-unaligned-access", 1,
+  ®)) {
+   dev_err(dev, "couldn't get legacy mode register offset\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "ti,syscon-unaligned-access", 2,
+  &field)) {
+   dev_err(dev, "can't get bit field for setting legacy mode\n");
+   return -EINVAL;
+   }
+
+   ret = regmap_update_bits(regmap, reg, field, field);
+   if (ret)
+   dev_err(dev, "failed to enable unaligned access\n");
+
+   return ret;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -637,6 +684,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
case DW_PCIE_RC_TYPE:
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
   DEVICE_TYPE_RC);
+
ret = dra7xx_add_pcie_port(dra7xx, pdev);
if (ret < 0)
goto err_gpio;
@@ -644,6 +692,11 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
case DW_PCIE_EP_TYPE:
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
   DEVICE_TYPE_EP);
+
+   ret = dra7xx_pcie_ep_unaligned_memaccess(dev);
+   if (ret)
+   goto err_gpio;
+
ret = dra7xx_add_pcie_ep(dra7xx, pdev);
if (ret < 0)
goto err_gpio;
-- 
2.11.0

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

[PATCH v4 22/23] MAINTAINERS: add PCI EP maintainer

[Kishon Vijay Abraham I]

Add maintainer for the newly introduced PCI EP framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..3c1b947811e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9581,6 +9581,15 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI EP SUBSYSTEM
+M: Kishon Vijay Abraham I 
+L: linux-...@vger.kernel.org
+T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git
+S: Supported
+F: drivers/pci/endpoint/
+F: drivers/misc/pci_endpoint_test.c
+F: tools/pci/
+
 PCI DRIVER FOR ALTERA PCIE IP
 M: Ley Foon Tan 
 L: r...@lists.rocketboards.org (moderated for non-subscribers)
-- 
2.11.0

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

[PATCH v4 20/23] tools: PCI: Add sample test script to invoke pcitest

[Kishon Vijay Abraham I]

Add a simple test script that invokes the pcitest userspace tool
to perform all the PCI endpoint tests (BAR tests, interrupt tests,
read tests, write tests and copy tests).

Signed-off-by: Kishon Vijay Abraham I 
---
 tools/pci/pcitest.sh | 56 
 1 file changed, 56 insertions(+)
 create mode 100644 tools/pci/pcitest.sh

diff --git a/tools/pci/pcitest.sh b/tools/pci/pcitest.sh
new file mode 100644
index ..5442bbea4c22
--- /dev/null
+++ b/tools/pci/pcitest.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+echo "BAR tests"
+echo
+
+bar=0
+
+while [ $bar -lt 6 ]
+do
+   pcitest -b $bar
+   bar=`expr $bar + 1`
+done
+echo
+
+echo "Interrupt tests"
+echo
+
+pcitest -l
+msi=1
+
+while [ $msi -lt 33 ]
+do
+pcitest -m $msi
+msi=`expr $msi + 1`
+done
+echo
+
+echo "Read Tests"
+echo
+
+pcitest -r -s 1
+pcitest -r -s 1024
+pcitest -r -s 1025
+pcitest -r -s 1024000
+pcitest -r -s 1024001
+echo
+
+echo "Write Tests"
+echo
+
+pcitest -w -s 1
+pcitest -w -s 1024
+pcitest -w -s 1025
+pcitest -w -s 1024000
+pcitest -w -s 1024001
+echo
+
+echo "Copy Tests"
+echo
+
+pcitest -c -s 1
+pcitest -c -s 1024
+pcitest -c -s 1025
+pcitest -c -s 1024000
+pcitest -c -s 1024001
+echo
-- 
2.11.0

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

[PATCH v4 16/23] PCI: Add device IDs for DRA74x and DRA72x

[Kishon Vijay Abraham I]

Add device IDs for DRA74x and DRA72x devices. These devices have
configurable PCI endpoint.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index a4f77feecbb0..5f6b71d15393 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -862,6 +862,8 @@
 #define PCI_DEVICE_ID_TI_X620  0xac8d
 #define PCI_DEVICE_ID_TI_X420  0xac8e
 #define PCI_DEVICE_ID_TI_XX20_FM   0xac8f
+#define PCI_DEVICE_ID_TI_DRA74x0xb500
+#define PCI_DEVICE_ID_TI_DRA72x0xb501
 
 #define PCI_VENDOR_ID_SONY 0x104d
 
-- 
2.11.0

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

[PATCH v4 15/23] dt-bindings: PCI: dra7xx: Add dt bindings to enable unaligned access

[Kishon Vijay Abraham I]

Update device tree binding documentation of TI's dra7xx PCI
controller to include property for enabling unaligned mem access.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 190828a5f32a..b69dd7dbd29e 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -39,6 +39,11 @@ DEVICE MODE
  - interrupts : one interrupt entries must be specified for main interrupt.
  - num-ib-windows : number of inbound address translation windows
  - num-ob-windows : number of outbound address translation windows
+ - ti,syscon-unaligned-access: phandle to the syscon dt node. The 1st argument
+  should contain the register offset within syscon
+  and the 2nd argument should contain the bit field
+  for setting the bit to enable unaligned
+  access.
 
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
-- 
2.11.0

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

[PATCH v4 18/23] Documentation: misc-devices: Add Documentation for pci-endpoint-test driver

[Kishon Vijay Abraham I]

Add Documentation for pci-endpoint-test driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/misc-devices/pci-endpoint-test.txt | 35 
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/misc-devices/pci-endpoint-test.txt

diff --git a/Documentation/misc-devices/pci-endpoint-test.txt 
b/Documentation/misc-devices/pci-endpoint-test.txt
new file mode 100644
index ..438571898d27
--- /dev/null
+++ b/Documentation/misc-devices/pci-endpoint-test.txt
@@ -0,0 +1,35 @@
+Driver for PCI Endpoint Test Function
+
+This driver should be used as a host side driver if the root complex is
+connected to a configurable pci endpoint running *pci_epf_test* function
+driver configured according to [1].
+
+The "pci_endpoint_test" driver can be used to perform the following tests.
+
+The PCI driver for the test device performs the following tests
+   *) verifying addresses programmed in BAR
+   *) raise legacy IRQ
+   *) raise MSI IRQ
+   *) read data
+   *) write data
+   *) copy data
+
+This misc driver creates /dev/pci-endpoint-test. for every
+*pci_epf_test* function connected to the root complex and "ioctls"
+should be used to perform the above tests.
+
+ioctl
+-
+ PCITEST_BAR: Tests the BAR. The number of the BAR that has to be tested
+ should be passed as argument.
+ PCITEST_LEGACY_IRQ: Tests legacy IRQ
+ PCITEST_MSI: Tests message signalled interrupts. The MSI number that has
+ to be tested should be passed as argument.
+ PCITEST_WRITE: Perform write tests. The size of the buffer should be passed
+   as argument.
+ PCITEST_READ: Perform read tests. The size of the buffer should be passed
+  as argument.
+ PCITEST_COPY: Perform read tests. The size of the buffer should be passed
+  as argument.
+
+[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt
-- 
2.11.0

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

[PATCH v4 13/23] dt-bindings: PCI: dra7xx: Add dt bindings for pci dra7xx EP mode

[Kishon Vijay Abraham I]

Add device tree binding documentation for pci dra7xx EP mode.

Acked-by: Rob Herring 
Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt | 37 +++-
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e25161f351..190828a5f32a 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,17 +1,22 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
- - reg : Two register ranges as listed in the reg-names property
- - reg-names : The first entry must be "ti-conf" for the TI specific registers
-  The second entry must be "rc-dbics" for the designware pcie
-  registers
-  The third entry must be "config" for the PCIe configuration space
+ - compatible: Should be "ti,dra7-pcie" for RC
+  Should be "ti,dra7-pcie-ep" for EP
  - phys : list of PHY specifiers (used by generic PHY framework)
  - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
   number of PHYs as specified in *phys* property.
  - ti,hwmods : Name of the hwmod associated to the pcie, "pcie",
   where  is the instance number of the pcie from the HW spec.
+ - num-lanes as specified in ../designware-pcie.txt
+
+HOST MODE
+=
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : The first entry must be "ti-conf" for the TI specific registers
+  The second entry must be "rc-dbics" for the designware pcie
+  registers
+  The third entry must be "config" for the PCIe configuration space
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
  - #address-cells,
@@ -19,13 +24,31 @@ PCIe Designware Controller
#interrupt-cells,
device_type,
ranges,
-   num-lanes,
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
 
+DEVICE MODE
+===
+ - reg : Four register ranges as listed in the reg-names property
+ - reg-names : "ti-conf" for the TI specific registers
+  "ep_dbics" for the standard configuration registers as
+   they are locally accessed within the DIF CS space
+  "ep_dbics2" for the standard configuration registers as
+   they are locally accessed within the DIF CS2 space
+  "addr_space" used to map remote RC address space
+ - interrupts : one interrupt entries must be specified for main interrupt.
+ - num-ib-windows : number of inbound address translation windows
+ - num-ob-windows : number of outbound address translation windows
+
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
 
+NOTE: Two dt nodes may be added for each PCI controller; one for host
+mode and another for device mode. So in order for PCI to
+work in host mode, EP mode dt node should be disabled and in order to PCI to
+work in EP mode, host mode dt node should be disabled. And host mode and EP
+mode are mutually exclusive.
+
 Example:
 axi {
compatible = "simple-bus";
-- 
2.11.0

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

[PATCH v4 19/23] tools: PCI: Add a userspace tool to test PCI endpoint

[Kishon Vijay Abraham I]

Add a userspace tool to invoke the ioctls exposed by the
PCI endpoint test driver to perform various PCI tests.

Signed-off-by: Kishon Vijay Abraham I 
---
 tools/pci/pcitest.c | 186 
 1 file changed, 186 insertions(+)
 create mode 100644 tools/pci/pcitest.c

diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
new file mode 100644
index ..39b5b0ba569e
--- /dev/null
+++ b/tools/pci/pcitest.c
@@ -0,0 +1,186 @@
+/**
+ * Userspace PCI Endpoint Test Module
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define BILLION 1E9
+
+static char *result[] = { "NOT OKAY", "OKAY" };
+
+struct pci_test {
+   char*device;
+   charbarnum;
+   boollegacyirq;
+   unsigned intmsinum;
+   boolread;
+   boolwrite;
+   boolcopy;
+   unsigned long   size;
+};
+
+static int run_test(struct pci_test *test)
+{
+   long ret;
+   int fd;
+   struct timespec start, end;
+   double time;
+
+   fd = open(test->device, O_RDWR);
+   if (fd < 0) {
+   perror("can't open PCI Endpoint Test device");
+   return fd;
+   }
+
+   if (test->barnum >= 0 && test->barnum <= 5) {
+   ret = ioctl(fd, PCITEST_BAR, test->barnum);
+   fprintf(stdout, "BAR%d:\t\t", test->barnum);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->legacyirq) {
+   ret = ioctl(fd, PCITEST_LEGACY_IRQ, 0);
+   fprintf(stdout, "LEGACY IRQ:\t");
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->msinum > 0 && test->msinum <= 32) {
+   ret = ioctl(fd, PCITEST_MSI, test->msinum);
+   fprintf(stdout, "MSI%d:\t\t", test->msinum);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->write) {
+   ret = ioctl(fd, PCITEST_WRITE, test->size);
+   fprintf(stdout, "WRITE (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->read) {
+   ret = ioctl(fd, PCITEST_READ, test->size);
+   fprintf(stdout, "READ (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   if (test->copy) {
+   ret = ioctl(fd, PCITEST_COPY, test->size);
+   fprintf(stdout, "COPY (%7ld bytes):\t\t", test->size);
+   if (ret < 0)
+   fprintf(stdout, "TEST FAILED\n");
+   else
+   fprintf(stdout, "%s\n", result[ret]);
+   }
+
+   fflush(stdout);
+}
+
+int main(int argc, char **argv)
+{
+   int c;
+   struct pci_test *test;
+
+   test = calloc(1, sizeof(*test));
+   if (!test) {
+   perror("Fail to allocate memory for pci_test\n");
+   return -ENOMEM;
+   }
+
+   /* since '0' is a valid BAR number, initialize it to -1 */
+   test->barnum = -1;
+
+   /* set default size as 100KB */
+   test->size = 0x19000;
+
+   /* set default endpoint device */
+   test->device = "/dev/pci-endpoint-test.0";
+
+   while ((c = getopt(argc, argv, "D:b:m:lrwcs:")) != EOF)
+   switch (c) {
+   case 'D':
+   test->device = optarg;
+   continue;
+   case 'b':
+   test->barnum = atoi(optarg);
+   if (test->barnum < 0 || test->barnum > 5)
+   goto usage;
+   continue;
+   case 'l':
+   test->legacyirq = true;
+ 

[PATCH v4 11/23] PCI: dwc: dra7xx: Facilitate wrapper and msi interrupts to be enabled independently

[Kishon Vijay Abraham I]

No functional change. Split dra7xx_pcie_enable_interrupts into
dra7xx_pcie_enable_wrapper_interrupts and dra7xx_pcie_enable_msi_interrupts
so that wrapper interrupts and msi interrupts can be enabled independently.
This is in preparation for adding EP mode support to dra7xx driver since
EP mode doesn't have to enable msi_interrupts.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/pci-dra7xx.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 7c9ed6a6675c..d78974d20360 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -140,18 +140,30 @@ static int dra7xx_pcie_establish_link(struct dra7xx_pcie 
*dra7xx)
return dw_pcie_wait_for_link(pci);
 }
 
-static void dra7xx_pcie_enable_interrupts(struct dra7xx_pcie *dra7xx)
+static void dra7xx_pcie_enable_msi_interrupts(struct dra7xx_pcie *dra7xx)
 {
-   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
-  ~INTERRUPTS);
-   dra7xx_pcie_writel(dra7xx,
-  PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN, INTERRUPTS);
dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
   ~LEG_EP_INTERRUPTS & ~MSI);
-   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
+
+   dra7xx_pcie_writel(dra7xx,
+  PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
   MSI | LEG_EP_INTERRUPTS);
 }
 
+static void dra7xx_pcie_enable_wrapper_interrupts(struct dra7xx_pcie *dra7xx)
+{
+   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
+  ~INTERRUPTS);
+   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN,
+  INTERRUPTS);
+}
+
+static void dra7xx_pcie_enable_interrupts(struct dra7xx_pcie *dra7xx)
+{
+   dra7xx_pcie_enable_wrapper_interrupts(dra7xx);
+   dra7xx_pcie_enable_msi_interrupts(dra7xx);
+}
+
 static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-- 
2.11.0

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

[PATCH v4 06/23] Documentation: PCI: Add specification for the *pci test* function device

[Kishon Vijay Abraham I]

Add specification for the *pci test* virtual function device. The endpoint
function driver and the host pci driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX   |  2 +
 Documentation/PCI/endpoint/pci-test-function.txt | 66 
 2 files changed, 68 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-test-function.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index f84a23c7c74b..4e5a2832f4e7 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -16,3 +16,5 @@ endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
 endpoint/pci-endpoint-cfs.txt
- guide to use configfs to configure the pci endpoint function.
+endpoint/pci-test-function.txt
+   - specification of *pci test* function device.
diff --git a/Documentation/PCI/endpoint/pci-test-function.txt 
b/Documentation/PCI/endpoint/pci-test-function.txt
new file mode 100644
index ..1324376ec6a3
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-test-function.txt
@@ -0,0 +1,66 @@
+   PCI TEST
+   Kishon Vijay Abraham I 
+
+Traditionally PCI RC has always been validated by using standard
+PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
+However with the addition of EP-core in linux kernel, it is possible
+to configure a PCI controller that can operate in EP mode to work as
+a test device.
+
+The PCI endpoint test device is a virtual device (defined in software)
+used to test the endpoint functionality and serve as a sample driver
+for other PCI endpoint devices (to use the EP framework).
+
+The PCI endpoint test device has the following registers:
+
+   1) PCI_ENDPOINT_TEST_MAGIC
+   2) PCI_ENDPOINT_TEST_COMMAND
+   3) PCI_ENDPOINT_TEST_STATUS
+   4) PCI_ENDPOINT_TEST_SRC_ADDR
+   5) PCI_ENDPOINT_TEST_DST_ADDR
+   6) PCI_ENDPOINT_TEST_SIZE
+   7) PCI_ENDPOINT_TEST_CHECKSUM
+
+*) PCI_ENDPOINT_TEST_MAGIC
+
+This register will be used to test BAR0. A known pattern will be written
+and read back from MAGIC register to verify BAR0.
+
+*) PCI_ENDPOINT_TEST_COMMAND:
+
+This register will be used by the host driver to indicate the function
+that the endpoint device must perform.
+
+Bitfield Description:
+  Bit 0: raise legacy irq
+  Bit 1: raise MSI irq
+  Bit 2 - 7: MSI interrupt number
+  Bit 8: read command (read data from RC buffer)
+  Bit 9: write command (write data to RC buffer)
+  Bit 10   : copy command (copy data from one RC buffer to another
+ RC buffer)
+
+*) PCI_ENDPOINT_TEST_STATUS
+
+This register reflects the status of the PCI endpoint device.
+
+Bitfield Description:
+  Bit 0: read success
+  Bit 1: read fail
+  Bit 2: write success
+  Bit 3: write fail
+  Bit 4: copy success
+  Bit 5: copy fail
+  Bit 6: irq raised
+  Bit 7: source address is invalid
+  Bit 8: destination address is invalid
+
+*) PCI_ENDPOINT_TEST_SRC_ADDR
+
+This register contains the source address (RC buffer address) for the
+COPY/READ command.
+
+*) PCI_ENDPOINT_TEST_DST_ADDR
+
+This register contains the destination address (RC buffer address) for
+the COPY/WRITE command.
-- 
2.11.0

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

[PATCH v4 02/23] Documentation: PCI: Guide to use PCI Endpoint Core Layer

[Kishon Vijay Abraham I]

Add Documentation to help users use endpoint library to enable endpoint
mode in the PCI controller and add new PCI endpoint functions.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX  |   2 +
 Documentation/PCI/endpoint/pci-endpoint.txt | 215 
 2 files changed, 217 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-endpoint.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f1613e..ba950b296bd8 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -12,3 +12,5 @@ pci.txt
- info on the PCI subsystem for device driver authors
 pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
+endpoint/pci-endpoint.txt
+   - guide to add endpoint controller driver and endpoint function driver.
diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt 
b/Documentation/PCI/endpoint/pci-endpoint.txt
new file mode 100644
index ..4a3e4388b37b
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -0,0 +1,215 @@
+   PCI ENDPOINT FRAMEWORK
+   Kishon Vijay Abraham I 
+
+This document is a guide to use the PCI Endpoint Framework in order to create
+endpoint controller driver, endpoint function driver and using configfs
+interface to bind the function driver to the controller driver.
+
+1. Introduction
+
+*Linux* has a comprehensive PCI subsystem to support PCI controllers that
+operates in Root Complex mode. The subsystem has capability to scan PCI bus,
+assign memory resources and irq resources, load PCI driver (based on
+vendorid, deviceid), support other services like hot-plug, power management,
+advanced error reporting and virtual channels.
+
+However PCI controller IPs integrated in certain SoC is capable of operating
+either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
+add endpoint mode support in *Linux*. This will help to run Linux in an
+EP system which can have a wide variety of use cases from testing or
+validation, co-processor accelerator etc..
+
+2. PCI Endpoint Core
+
+The PCI Endpoint Core layer comprises of 3 components: the Endpoint Controller
+library, the Endpoint Function library and the configfs layer to bind the
+endpoint function with the endpoint controller.
+
+2.1 PCI Endpoint Controller(EPC) Library
+
+The EPC library provides APIs to be used by the controller that can operate
+in endpoint mode. It also provides APIs to be used by function driver/library
+in order to implement a particular endpoint function.
+
+2.1.1 APIs for the PCI controller Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI controller driver.
+
+*) devm_pci_epc_create()/pci_epc_create()
+
+   The PCI controller driver should implement the following ops:
+* write_header: ops to populate configuration space header
+* set_bar: ops to configure the BAR
+* clear_bar: ops to reset the BAR
+* alloc_addr_space: ops to allocate *in* PCI controller address space
+* free_addr_space: ops to free the allocated address space
+* raise_irq: ops to raise a legacy or MSI interrupt
+* start: ops to start the PCI link
+* stop: ops to stop the PCI link
+
+   The PCI controller driver can then create a new EPC device by invoking
+   devm_pci_epc_create/pci_epc_create.
+
+*) devm_pci_epc_destroy()/pci_epc_destroy()
+
+   The PCI controller driver can destroy the EPC device created by either
+   devm_pci_epc_create or pci_epc_create using devm_pci_epc_destroy() or
+   /pci_epc_destroy()
+
+*) pci_epc_linkup()
+
+   In order to notify all the function devices that the EPC device to which
+   they are linked has established a link with the host, the PCI controller
+   driver should invoke pci_epc_linkup().
+
+*) pci_epc_mem_init()
+
+   Initialize the pci_epc_mem structure used for allocating EPC addr space.
+
+*) pci_epc_mem_exit()
+
+   Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
+
+2.1.2 APIs for the PCI Endpoint Function Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function driver.
+
+*) pci_epc_write_header()
+
+   The PCI endpoint function driver should use pci_epc_write_header() to
+   write the standard configuration header to the endpoint controller.
+
+*) pci_epc_set_bar()
+
+   The PCI endpoint function driver should use pci_epc_set_bar() to configure
+   the Base Address Register in order for the host to assign PCI addr space.
+   Register space of the function driver is usually configured
+   using this API.
+
+*) pci_epc_clear_bar()
+
+   The PCI endpoint function driver should use pci_epc_clear_bar() to reset
+   the BAR.
+
+*) pci_epc_raise_irq()
+
+   The PCI endpoint function driver should use pci_epc_raise_irq() to raise
+   Legacy Interrupt or MSI Interrupt.
+
+*) pci_epc_mem_a

[PATCH v4 04/23] Documentation: PCI: Guide to use pci endpoint configfs

[Kishon Vijay Abraham I]

Add Documentation to help users use pci endpoint to configure
pci endpoint function and to bind the endpoint function
with endpoint controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX  |   2 +
 Documentation/PCI/endpoint/pci-endpoint-cfs.txt | 105 
 2 files changed, 107 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-endpoint-cfs.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index ba950b296bd8..f84a23c7c74b 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -14,3 +14,5 @@ pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
 endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
+endpoint/pci-endpoint-cfs.txt
+   - guide to use configfs to configure the pci endpoint function.
diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt 
b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
new file mode 100644
index ..8b2a8280b131
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
@@ -0,0 +1,105 @@
+   CONFIGURING PCI ENDPOINT USING CONFIGFS
+Kishon Vijay Abraham I 
+
+The PCI Endpoint Core exposes configfs entry (pci_ep) in order to configure the
+PCI endpoint function and in order to bind the endpoint function
+with the endpoint controller. (For introducing other mechanisms to
+configure the PCI Endpoint Function refer [1]).
+
+*) Mounting configfs
+
+The PCI Endpoint Core layer creates pci_ep directory in the mounted configfs
+directory. configfs can be mounted using the following command.
+
+   mount -t configfs none /sys/kernel/config
+
+*) Directory Structure
+
+The pci_ep configfs has two directories at its root: controllers and
+functions. Every EPC device present in the system will have an entry in
+the *controllers* directory and and every EPF driver present in the system
+will have an entry in the *functions* directory.
+
+/sys/kernel/config/pci_ep/
+   .. controllers/
+   .. functions/
+
+*) Creating EPF Device
+
+Every registered EPF driver will be listed in controllers directory. The
+entries corresponding to EPF driver will be created by the EPF core.
+
+/sys/kernel/config/pci_ep/functions/
+   .. /
+   ... /
+   ... /
+   .. /
+   ... /
+   ... /
+
+In order to create a  of the type probed by , the
+user has to create a directory inside .
+
+Every  directory consists of the following entries that can be
+used to configure the standard configuration header of the endpoint function.
+(These entries are created by the framework when any new  is
+created)
+
+   .. /
+   ... /
+   ... vendorid
+   ... deviceid
+   ... revid
+   ... progif_code
+   ... subclass_code
+   ... baseclass_code
+   ... cache_line_size
+   ... subsys_vendor_id
+   ... subsys_id
+   ... interrupt_pin
+
+*) EPC Device
+
+Every registered EPC device will be listed in controllers directory. The
+entries corresponding to EPC device will be created by the EPC core.
+
+/sys/kernel/config/pci_ep/controllers/
+   .. /
+   ... /
+   ... /
+   ... start
+   .. /
+   ... /
+   ... /
+   ... start
+
+The  directory will have a list of symbolic links to
+. These symbolic links should be created by the user to
+represent the functions present in the endpoint device.
+
+The  directory will also have a *start* field. Once
+"1" is written to this field, the endpoint device will be ready to
+establish the link with the host. This is usually done after
+all the EPF devices are created and linked with the EPC device.
+
+
+| controllers/
+   | /
+   | 
+   | start
+| functions/
+   | /
+   | /
+   | vendorid
+   | deviceid
+   | revid
+   | progif_code
+   | subclass_code
+   | baseclass_code
+   | cache_line_size
+   | subsys_vendor_id
+   | subsys_id
+   | interrupt_pin
+   | function
+
+[1] -> Documentation/

[PATCH v4 10/23] dt-bindings: PCI: Add dt bindings for pci designware EP mode

[Kishon Vijay Abraham I]

Add device tree binding documentation for pci designware EP mode.

Acked-by: Rob Herring 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/pci/designware-pcie.txt| 26 +++---
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 1392c705ceca..b2480dd38c11 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -6,30 +6,40 @@ Required properties:
 - reg-names: Must be "config" for the PCIe configuration space.
 (The old way of getting the configuration address space from "ranges"
 is deprecated and should be avoided.)
+- num-lanes: number of lanes to use
+RC mode:
 - #address-cells: set to <3>
 - #size-cells: set to <2>
 - device_type: set to "pci"
 - ranges: ranges for the PCI memory and I/O regions
 - #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map: standard PCI properties
-   to define the mapping of the PCIe interface to interrupt
+- interrupt-map-mask and interrupt-map: standard PCI
+   properties to define the mapping of the PCIe interface to interrupt
numbers.
-- num-lanes: number of lanes to use
+EP mode:
+- num-ib-windows: number of inbound address translation
+windows
+- num-ob-windows: number of outbound address translation
+windows
 
 Optional properties:
-- num-viewport: number of view ports configured in hardware.  If a platform
-  does not specify it, the driver assumes 2.
 - num-lanes: number of lanes to use (this property should be specified unless
   the link is brought already up in BIOS)
 - reset-gpio: gpio pin number of power good signal
-- bus-range: PCI bus numbers covered (it is recommended for new devicetrees to
-  specify this property, to keep backwards compatibility a range of 0x00-0xff
-  is assumed if not present)
 - clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
- "pcie"
- "pcie_bus"
+RC mode:
+- num-viewport: number of view ports configured in
+  hardware. If a platform does not specify it, the driver assumes 2.
+- bus-range: PCI bus numbers covered (it is recommended
+  for new devicetrees to specify this property, to keep backwards
+  compatibility a range of 0x00-0xff is assumed if not present)
+EP mode:
+- max-functions: maximum number of functions that can be
+  configured
 
 Example configuration:
 
-- 
2.11.0

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

[PATCH v4 05/23] PCI: endpoint: Create configfs entry for EPC device and EPF driver

[Kishon Vijay Abraham I]

Invoke API's provided by pci-ep-cfs to create configfs entry for
every EPC device and EPF driver to help users in creating EPF device
and binding the EPF device to the EPC device.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 4 
 drivers/pci/endpoint/pci-epf-core.c | 4 
 include/linux/pci-epc.h | 2 ++
 include/linux/pci-epf.h | 2 ++
 4 files changed, 12 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 06808ed7ee1f..29cbe9a73b30 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 static struct class *pci_epc_class;
 
@@ -441,6 +442,7 @@ EXPORT_SYMBOL_GPL(pci_epc_linkup);
  */
 void pci_epc_destroy(struct pci_epc *epc)
 {
+   pci_ep_cfs_remove_epc_group(epc->group);
device_unregister(&epc->dev);
kfree(epc);
 }
@@ -507,6 +509,8 @@ __pci_epc_create(struct device *dev, const struct 
pci_epc_ops *ops,
if (ret)
goto put_dev;
 
+   epc->group = pci_ep_cfs_add_epc_group(dev_name(dev));
+
return epc;
 
 put_dev:
diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index 4c903fc1cd30..9ec1639ef749 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 static struct bus_type pci_epf_bus_type;
 static struct device_type pci_epf_type;
@@ -143,6 +144,7 @@ EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
  */
 void pci_epf_unregister_driver(struct pci_epf_driver *driver)
 {
+   pci_ep_cfs_remove_epf_group(driver->group);
driver_unregister(&driver->driver);
 }
 EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
@@ -172,6 +174,8 @@ int __pci_epf_register_driver(struct pci_epf_driver *driver,
if (ret)
return ret;
 
+   driver->group = pci_ep_cfs_add_epf_group(driver->driver.name);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(__pci_epf_register_driver);
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index ad0cd465737e..d6eb32291462 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -77,6 +77,7 @@ struct pci_epc_mem {
  * @ops: function pointers for performing endpoint operations
  * @mem: address space of the endpoint controller
  * @max_functions: max number of functions that can be configured in this EPC
+ * @group: configfs group representing the PCI EPC device
  * @lock: spinlock to protect pci_epc ops
  */
 struct pci_epc {
@@ -85,6 +86,7 @@ struct pci_epc {
const struct pci_epc_ops*ops;
struct pci_epc_mem  *mem;
u8  max_functions;
+   struct config_group *group;
/* spinlock to protect against concurrent access of EP controller */
spinlock_t  lock;
 };
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 54f133868a6e..5ff2c5a592c3 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -82,6 +82,7 @@ struct pci_epf_ops {
  * @driver: PCI EPF driver
  * @ops: set of function pointers for performing EPF operations
  * @owner: the owner of the module that registers the PCI EPF driver
+ * @group: configfs group corresponding to the PCI EPF driver
  * @id_table: identifies EPF devices for probing
  */
 struct pci_epf_driver {
@@ -91,6 +92,7 @@ struct pci_epf_driver {
struct device_driverdriver;
struct pci_epf_ops  *ops;
struct module   *owner;
+   struct config_group *group;
const struct pci_epf_device_id  *id_table;
 };
 
-- 
2.11.0

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

[PATCH v4 03/23] PCI: endpoint: Introduce configfs entry for configuring EP functions

[Kishon Vijay Abraham I]

Introduce a new configfs entry to configure the EP function (like
configuring the standard configuration header entries) and to
bind the EP function with EP controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/Kconfig  |   9 +
 drivers/pci/endpoint/Makefile |   1 +
 drivers/pci/endpoint/pci-ep-cfs.c | 509 ++
 include/linux/pci-ep-cfs.h|  41 +++
 4 files changed, 560 insertions(+)
 create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c
 create mode 100644 include/linux/pci-ep-cfs.h

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index a5442ace7077..c86bca9b7de3 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -17,4 +17,13 @@ config PCI_ENDPOINT
 
   If in doubt, say "N" to disable Endpoint support.
 
+config PCI_ENDPOINT_CONFIGFS
+   bool "PCI Endpoint Configfs Support"
+   depends on PCI_ENDPOINT
+   select CONFIGFS_FS
+   help
+  This will enable the configfs entry that can be used to
+  configure the endpoint function and used to bind the
+  function with a endpoint controller.
+
 endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index dc1bc16491e6..7219d51bb401 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -2,5 +2,6 @@
 # Makefile for PCI Endpoint Support
 #
 
+obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
   pci-epc-mem.o
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
new file mode 100644
index ..424fdd6ed1ca
--- /dev/null
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -0,0 +1,509 @@
+/**
+ * configfs to configure the PCI endpoint
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static struct config_group *functions_group;
+static struct config_group *controllers_group;
+
+struct pci_epf_group {
+   struct config_group group;
+   struct pci_epf *epf;
+};
+
+struct pci_epc_group {
+   struct config_group group;
+   struct pci_epc *epc;
+   bool start;
+   unsigned long function_num_map;
+};
+
+static inline struct pci_epf_group *to_pci_epf_group(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_epf_group, group);
+}
+
+static inline struct pci_epc_group *to_pci_epc_group(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct pci_epc_group, group);
+}
+
+static ssize_t pci_epc_start_store(struct config_item *item, const char *page,
+  size_t len)
+{
+   int ret;
+   bool start;
+   struct pci_epc *epc;
+   struct pci_epc_group *epc_group = to_pci_epc_group(item);
+
+   epc = epc_group->epc;
+
+   ret = kstrtobool(page, &start);
+   if (ret)
+   return ret;
+
+   if (!start) {
+   pci_epc_stop(epc);
+   return len;
+   }
+
+   ret = pci_epc_start(epc);
+   if (ret) {
+   dev_err(&epc->dev, "failed to start endpoint controller\n");
+   return -EINVAL;
+   }
+
+   epc_group->start = start;
+
+   return len;
+}
+
+static ssize_t pci_epc_start_show(struct config_item *item, char *page)
+{
+   return sprintf(page, "%d\n",
+  to_pci_epc_group(item)->start);
+}
+
+CONFIGFS_ATTR(pci_epc_, start);
+
+static struct configfs_attribute *pci_epc_attrs[] = {
+   &pci_epc_attr_start,
+   NULL,
+};
+
+static int pci_epc_epf_link(struct config_item *epc_item,
+   struct config_item *epf_item)
+{
+   int ret;
+   u32 func_no = 0;
+   struct pci_epc *epc;
+   struct pci_epf *epf;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+
+   epc = epc_group->epc;
+   epf = epf_group->epf;
+   ret = pci_epc_add_epf(epc, epf);
+   if (ret)
+   goto err_add_epf;
+
+   func_no = find_first_zero_bit(&epc_group->function_num_map,
+ sizeof(epc_group->function_num_map

[PATCH v4 07/23] PCI: endpoint: functions: Add an EP function to test PCI

[Kishon Vijay Abraham I]

Adds a new endpoint function driver (to program the virtual
test device) making use of the EP-core library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/Kconfig  |   2 +
 drivers/pci/endpoint/Makefile |   2 +-
 drivers/pci/endpoint/functions/Kconfig|  12 +
 drivers/pci/endpoint/functions/Makefile   |   5 +
 drivers/pci/endpoint/functions/pci-epf-test.c | 510 ++
 5 files changed, 530 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/endpoint/functions/Kconfig
 create mode 100644 drivers/pci/endpoint/functions/Makefile
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-test.c

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index c86bca9b7de3..c23f146fb5a6 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -26,4 +26,6 @@ config PCI_ENDPOINT_CONFIGFS
   configure the endpoint function and used to bind the
   function with a endpoint controller.
 
+source "drivers/pci/endpoint/functions/Kconfig"
+
 endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index 7219d51bb401..1041f80a4645 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -4,4 +4,4 @@
 
 obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
-  pci-epc-mem.o
+  pci-epc-mem.o functions/
diff --git a/drivers/pci/endpoint/functions/Kconfig 
b/drivers/pci/endpoint/functions/Kconfig
new file mode 100644
index ..175edad42d2f
--- /dev/null
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -0,0 +1,12 @@
+#
+# PCI Endpoint Functions
+#
+
+config PCI_EPF_TEST
+   tristate "PCI Endpoint Test driver"
+   depends on PCI_ENDPOINT
+   help
+  Enable this configuration option to enable the test driver
+  for PCI Endpoint.
+
+  If in doubt, say "N" to disable Endpoint test driver.
diff --git a/drivers/pci/endpoint/functions/Makefile 
b/drivers/pci/endpoint/functions/Makefile
new file mode 100644
index ..6d94a4801838
--- /dev/null
+++ b/drivers/pci/endpoint/functions/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for PCI Endpoint Functions
+#
+
+obj-$(CONFIG_PCI_EPF_TEST) += pci-epf-test.o
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
new file mode 100644
index ..d6a7a12a99f7
--- /dev/null
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -0,0 +1,510 @@
+/**
+ * Test driver to test endpoint functionality
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define COMMAND_RAISE_LEGACY_IRQ   BIT(0)
+#define COMMAND_RAISE_MSI_IRQ  BIT(1)
+#define MSI_NUMBER_SHIFT   2
+#define MSI_NUMBER_MASK(0x3f << MSI_NUMBER_SHIFT)
+#define COMMAND_READ   BIT(8)
+#define COMMAND_WRITE  BIT(9)
+#define COMMAND_COPY   BIT(10)
+
+#define STATUS_READ_SUCCESSBIT(0)
+#define STATUS_READ_FAIL   BIT(1)
+#define STATUS_WRITE_SUCCESS   BIT(2)
+#define STATUS_WRITE_FAIL  BIT(3)
+#define STATUS_COPY_SUCCESSBIT(4)
+#define STATUS_COPY_FAIL   BIT(5)
+#define STATUS_IRQ_RAISED  BIT(6)
+#define STATUS_SRC_ADDR_INVALIDBIT(7)
+#define STATUS_DST_ADDR_INVALIDBIT(8)
+
+#define TIMER_RESOLUTION   1
+
+static struct workqueue_struct *kpcitest_workqueue;
+
+struct pci_epf_test {
+   void*reg[6];
+   struct pci_epf  *epf;
+   struct delayed_work cmd_handler;
+};
+
+struct pci_epf_test_reg {
+   u32 magic;
+   u32 command;
+   u32 status;
+   u64 src_addr;
+   u64 dst_addr;
+   u32 size;
+   u32 checksum;
+} __packed;
+
+static struct pci_epf_header test_header = {
+   .vendorid   = PCI_ANY_ID,
+   .deviceid   = PCI_ANY_ID,
+   .baseclass_code = PCI_CLASS_OTHERS,
+   .interrupt_pin  = PCI_INTERRUPT_I

Re: [PATCH] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-03-10 00:29+0200, Michael S. Tsirkin:
> Some guests call mwait without checking the cpu flags.  We currently
> emulate that as a NOP but on VMX we can do better: let guest stop the
> CPU until timer or IPI.  CPU will be busy but that isn't any worse than
> a NOP emulation.
> 
> Note that mwait within guests is not the same as on real hardware
> because you must halt if you want to go deep into sleep.

SDM (25.3 CHANGES TO INSTRUCTION BEHAVIOR IN VMX NON-ROOT OPERATION)
says that "MWAIT operates normally".  What is the reason why MWAIT
inside VMX cannot reach the same states as MWAIT outside VMX?

>   Thus it isn't
> a good idea to use the regular MWAIT flag in CPUID for that.  Add a flag
> in the hypervisor leaf instead.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
  [...]
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
> *entry, u32 function,
> + if (this_cpu_has(X86_FEATURE_MWAIT))
> + entry->eax = (1 << KVM_FEATURE_MWAIT);

I'd rather not add it as a paravirt feature:

 - MWAIT requires the software to provide a target state, but we're not
   doing anything to expose those states.
   The feature would need very constrained setup, which is hard to
   support

 - we've had requests to support MWAIT emulation for Linux and fully
   emulating MWAIT would be best.
   MWAIT is not going to enabled by default, of course; it would be
   targeted at LPAR-like uses of KVM.

What about keeping just the last hunk to improve OS X, for now?

Thanks.

> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> @@ -3547,13 +3547,9 @@ static __init int setup_vmcs_config(struct vmcs_config 
> *vmcs_conf)
> CPU_BASED_USE_IO_BITMAPS |
> CPU_BASED_MOV_DR_EXITING |
> CPU_BASED_USE_TSC_OFFSETING |
> -   CPU_BASED_MWAIT_EXITING |
> -   CPU_BASED_MONITOR_EXITING |
> CPU_BASED_INVLPG_EXITING |
> CPU_BASED_RDPMC_EXITING;
>  
> - printk(KERN_ERR "cleared CPU_BASED_MWAIT_EXITING + 
> CPU_BASED_MONITOR_EXITING\n");
> -
>   opt = CPU_BASED_TPR_SHADOW |
> CPU_BASED_USE_MSR_BITMAPS |
> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
> -- 
> MST
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kvm: better MWAIT emulation for guests

[Michael S. Tsirkin]

On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
> 2017-03-10 00:29+0200, Michael S. Tsirkin:
> > Some guests call mwait without checking the cpu flags.  We currently
> > emulate that as a NOP but on VMX we can do better: let guest stop the
> > CPU until timer or IPI.  CPU will be busy but that isn't any worse than
> > a NOP emulation.
> > 
> > Note that mwait within guests is not the same as on real hardware
> > because you must halt if you want to go deep into sleep.
> 
> SDM (25.3 CHANGES TO INSTRUCTION BEHAVIOR IN VMX NON-ROOT OPERATION)
> says that "MWAIT operates normally".  What is the reason why MWAIT
> inside VMX cannot reach the same states as MWAIT outside VMX?

If you are going into a deep sleep state with huge latency you are
better off exiting and paying an extra microsecond latency
since a chance some other task will want to schedule seems higher.

> >   Thus it isn't
> > a good idea to use the regular MWAIT flag in CPUID for that.  Add a flag
> > in the hypervisor leaf instead.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
>   [...]
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct 
> > kvm_cpuid_entry2 *entry, u32 function,
> > +   if (this_cpu_has(X86_FEATURE_MWAIT))
> > +   entry->eax = (1 << KVM_FEATURE_MWAIT);
> 
> I'd rather not add it as a paravirt feature:
> 
>  - MWAIT requires the software to provide a target state, but we're not
>doing anything to expose those states.

Current linux guests just discover these states based on
CPU model, so we do expose enough info.

>The feature would need very constrained setup, which is hard to
>support

Why would it? It works without any tweaking on several boxes
I own.

>  - we've had requests to support MWAIT emulation for Linux and fully
>emulating MWAIT would be best.
>MWAIT is not going to enabled by default, of course; it would be
>targeted at LPAR-like uses of KVM.

Yes I think this limited emulation is safe to enable by default.
Pretending mwait is equivalent to halt maybe isn't.

> What about keeping just the last hunk to improve OS X, for now?
> 
> Thanks.

IMHO if we have a new functionality we are better of creating
some way for guests to discover it is there.
Do we really have to argue about a single bit in HV leaf?
What harm does it do?

> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > @@ -3547,13 +3547,9 @@ static __init int setup_vmcs_config(struct 
> > vmcs_config *vmcs_conf)
> >   CPU_BASED_USE_IO_BITMAPS |
> >   CPU_BASED_MOV_DR_EXITING |
> >   CPU_BASED_USE_TSC_OFFSETING |
> > - CPU_BASED_MWAIT_EXITING |
> > - CPU_BASED_MONITOR_EXITING |
> >   CPU_BASED_INVLPG_EXITING |
> >   CPU_BASED_RDPMC_EXITING;
> >  
> > -   printk(KERN_ERR "cleared CPU_BASED_MWAIT_EXITING + 
> > CPU_BASED_MONITOR_EXITING\n");
> > -
> > opt = CPU_BASED_TPR_SHADOW |
> >   CPU_BASED_USE_MSR_BITMAPS |
> >   CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
> > -- 
> > MST
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] kvm: better MWAIT emulation for guests

[Michael S. Tsirkin]

Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
unless explicitly provided with kernel command line argument
"idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
without checking CPUID.

We currently emulate that as a NOP but on VMX we can do better: let
guest stop the CPU until timer, IPI or memory change.  CPU will be busy
but that isn't any worse than a NOP emulation.

Note that mwait within guests is not the same as on real hardware
because halt causes an exit while mwait doesn't.  For this reason it
might not be a good idea to use the regular MWAIT flag in CPUID to
signal this capability: halt is sometimes better as you are giving up
the rest of your CPU slice.  Add a flag in the hypervisor leaf instead.

Reported-by: "Gabriel L. Somlo" 
Signed-off-by: Michael S. Tsirkin 
---

changes from v1:
- typo fix resulting in rest of leaf flags being overwritten
  Reported by: Wanpeng Li 
- updated commit log with data about guests helped by this feature
- better document differences between mwait and halt for guests
  


 Documentation/virtual/kvm/cpuid.txt  | 3 +++
 arch/x86/include/uapi/asm/kvm_para.h | 1 +
 arch/x86/kvm/cpuid.c | 3 +++
 arch/x86/kvm/vmx.c   | 4 
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/virtual/kvm/cpuid.txt 
b/Documentation/virtual/kvm/cpuid.txt
index 3c65feb..5caa234 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -54,6 +54,9 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest checks 
this feature bit
||   || before enabling paravirtualized
||   || spinlock support.
 --
+KVM_FEATURE_MWAIT  || 8 || guest can use monitor/mwait
+   ||   || to halt the VCPU.
+--
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
||   || per-cpu warps are expected in
||   || kvmclock.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index cff0bb6..9cc77a7 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
 #define KVM_FEATURE_STEAL_TIME 5
 #define KVM_FEATURE_PV_EOI 6
 #define KVM_FEATURE_PV_UNHALT  7
+#define KVM_FEATURE_MWAIT  8
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index efde6cc..3c7fca83 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
 
+   if (this_cpu_has(X86_FEATURE_MWAIT))
+   entry->eax |= (1 << KVM_FEATURE_MWAIT);
+
entry->ebx = 0;
entry->ecx = 0;
entry->edx = 0;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4bfe349..b167aba 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3547,13 +3547,9 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
  CPU_BASED_USE_IO_BITMAPS |
  CPU_BASED_MOV_DR_EXITING |
  CPU_BASED_USE_TSC_OFFSETING |
- CPU_BASED_MWAIT_EXITING |
- CPU_BASED_MONITOR_EXITING |
  CPU_BASED_INVLPG_EXITING |
  CPU_BASED_RDPMC_EXITING;
 
-   printk(KERN_ERR "cleared CPU_BASED_MWAIT_EXITING + 
CPU_BASED_MONITOR_EXITING\n");
-
opt = CPU_BASED_TPR_SHADOW |
  CPU_BASED_USE_MSR_BITMAPS |
  CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [PATCH v6] docs-rst: automatically convert Graphviz and SVG images

[Daniel Vetter]

On Thu, Mar 09, 2017 at 06:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Mar 09, 2017 at 03:02:49AM -0700, Jonathan Corbet wrote:
> > On Mon,  6 Mar 2017 14:09:27 +0100
> > Markus Heiser  wrote:
> > 
> > > This patch brings scalable figure, image handling and a concept to
> > > embed *render* markups:
> > > 
> > > * DOT (http://www.graphviz.org)
> > > * SVG
> > 
> > OK, this is finally in docs-next - thanks everybody.
> > 
> > Mauro, I tried to add your makefile patch, but it doesn't apply; care to
> > send an updated version?
> 
> Awesome! Can you pls send me/dri-devel a pull request with a stable tag
> for drm-misc, so that I can apply all the drm diagram patches?

Yes I'm annoying, but ping about the stable tag/pull request, so I can
vacuum up the drm graph patches. Except for this technicality they're
ready for merging.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-03-13 18:08+0200, Michael S. Tsirkin:
> On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
>> 2017-03-10 00:29+0200, Michael S. Tsirkin:
>> > Some guests call mwait without checking the cpu flags.  We currently
>> > emulate that as a NOP but on VMX we can do better: let guest stop the
>> > CPU until timer or IPI.  CPU will be busy but that isn't any worse than
>> > a NOP emulation.
>> > 
>> > Note that mwait within guests is not the same as on real hardware
>> > because you must halt if you want to go deep into sleep.
>> 
>> SDM (25.3 CHANGES TO INSTRUCTION BEHAVIOR IN VMX NON-ROOT OPERATION)
>> says that "MWAIT operates normally".  What is the reason why MWAIT
>> inside VMX cannot reach the same states as MWAIT outside VMX?
> 
> If you are going into a deep sleep state with huge latency you are
> better off exiting and paying an extra microsecond latency
> since a chance some other task will want to schedule seems higher.

Oh, so MWAIT behavior is same and can reach deep sleep, just use-cases
differ ... If the guest VCPU is running on isolated CPU, then you might
want to reach a deep state to save power when there is no better use.

>> >   Thus it isn't
>> > a good idea to use the regular MWAIT flag in CPUID for that.  Add a flag
>> > in the hypervisor leaf instead.
>> > 
>> > Signed-off-by: Michael S. Tsirkin 
>> > ---
>>   [...]
>> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
>> > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct 
>> > kvm_cpuid_entry2 *entry, u32 function,
>> > +  if (this_cpu_has(X86_FEATURE_MWAIT))
>> > +  entry->eax = (1 << KVM_FEATURE_MWAIT);
>> 
>> I'd rather not add it as a paravirt feature:
>> 
>>  - MWAIT requires the software to provide a target state, but we're not
>>doing anything to expose those states.
> 
> Current linux guests just discover these states based on
> CPU model, so we do expose enough info.

Linux still filters the hardcoded hints through CPUID[5].edx, which is 0
in our case.

>>The feature would need very constrained setup, which is hard to
>>support
> 
> Why would it? It works without any tweaking on several boxes
> I own.

MWAIT hints do not always mean the same, so they could lead to different
power/performance tradeoffs than the applications expects.  We should at
least specify that the paravirt feature allows only hint 0.

You probably don't run weird combinations of host/guest CPUs.

>>  - we've had requests to support MWAIT emulation for Linux and fully
>>emulating MWAIT would be best.
>>MWAIT is not going to enabled by default, of course; it would be
>>targeted at LPAR-like uses of KVM.
> 
> Yes I think this limited emulation is safe to enable by default.
> Pretending mwait is equivalent to halt maybe isn't.

Right, we must keep the VCPU thread running when emulating mwait as it
is different from a hlt.

>> What about keeping just the last hunk to improve OS X, for now?
>> 
>> Thanks.
> 
> IMHO if we have a new functionality we are better of creating
> some way for guests to discover it is there.
> 
> Do we really have to argue about a single bit in HV leaf?
> What harm does it do?

It adds code to both guest and hosts and needs documentation ...
The bit is acceptable.  I just see no point in having it when there
already is a detection mechanism for mwait.

In any case, this patch should also remove VM exits under SVM and add
KVM_CAP_MWAIT for userspace.  Userspace can then set the MWAIT feature
if it wishes the guest to use it in a more standard way.

I can do a cleanup due to unused VM exits on top of it.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kvm: better MWAIT emulation for guests

[Michael S. Tsirkin]

On Mon, Mar 13, 2017 at 08:39:11PM +0100, Radim Krčmář wrote:
> 2017-03-13 18:08+0200, Michael S. Tsirkin:
> > On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
> >> 2017-03-10 00:29+0200, Michael S. Tsirkin:
> >> > Some guests call mwait without checking the cpu flags.  We currently
> >> > emulate that as a NOP but on VMX we can do better: let guest stop the
> >> > CPU until timer or IPI.  CPU will be busy but that isn't any worse than
> >> > a NOP emulation.
> >> > 
> >> > Note that mwait within guests is not the same as on real hardware
> >> > because you must halt if you want to go deep into sleep.
> >> 
> >> SDM (25.3 CHANGES TO INSTRUCTION BEHAVIOR IN VMX NON-ROOT OPERATION)
> >> says that "MWAIT operates normally".  What is the reason why MWAIT
> >> inside VMX cannot reach the same states as MWAIT outside VMX?
> > 
> > If you are going into a deep sleep state with huge latency you are
> > better off exiting and paying an extra microsecond latency
> > since a chance some other task will want to schedule seems higher.
> 
> Oh, so MWAIT behavior is same and can reach deep sleep, just use-cases
> differ ... If the guest VCPU is running on isolated CPU, then you might
> want to reach a deep state to save power when there is no better use.
> 
> >> >   Thus it isn't
> >> > a good idea to use the regular MWAIT flag in CPUID for that.  Add a flag
> >> > in the hypervisor leaf instead.
> >> > 
> >> > Signed-off-by: Michael S. Tsirkin 
> >> > ---
> >>   [...]
> >> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> >> > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct 
> >> > kvm_cpuid_entry2 *entry, u32 function,
> >> > +if (this_cpu_has(X86_FEATURE_MWAIT))
> >> > +entry->eax = (1 << KVM_FEATURE_MWAIT);
> >> 
> >> I'd rather not add it as a paravirt feature:
> >> 
> >>  - MWAIT requires the software to provide a target state, but we're not
> >>doing anything to expose those states.
> > 
> > Current linux guests just discover these states based on
> > CPU model, so we do expose enough info.
> 
> Linux still filters the hardcoded hints through CPUID[5].edx, which is 0
> in our case.
> 
> >>The feature would need very constrained setup, which is hard to
> >>support
> > 
> > Why would it? It works without any tweaking on several boxes
> > I own.
> 
> MWAIT hints do not always mean the same, so they could lead to different
> power/performance tradeoffs than the applications expects.  We should at
> least specify that the paravirt feature allows only hint 0.
> 
> You probably don't run weird combinations of host/guest CPUs.
> 
> >>  - we've had requests to support MWAIT emulation for Linux and fully
> >>emulating MWAIT would be best.
> >>MWAIT is not going to enabled by default, of course; it would be
> >>targeted at LPAR-like uses of KVM.
> > 
> > Yes I think this limited emulation is safe to enable by default.
> > Pretending mwait is equivalent to halt maybe isn't.
> 
> Right, we must keep the VCPU thread running when emulating mwait as it
> is different from a hlt.
> 
> >> What about keeping just the last hunk to improve OS X, for now?
> >> 
> >> Thanks.
> > 
> > IMHO if we have a new functionality we are better of creating
> > some way for guests to discover it is there.
> > 
> > Do we really have to argue about a single bit in HV leaf?
> > What harm does it do?
> 
> It adds code to both guest and hosts and needs documentation ...
> The bit is acceptable.  I just see no point in having it when there
> already is a detection mechanism for mwait.

We don't want to use that standard detection mechanism IMHO at least
not in all cases.

> In any case, this patch should also remove VM exits under SVM

AMD does not have MWAIT AFAIK. In any case, I don't see
why can't SVM be a separate patch.

> and add
> KVM_CAP_MWAIT for userspace.

Sure, why not. Will do.

> Userspace can then set the MWAIT feature
> if it wishes the guest to use it in a more standard way.
> 
> I can do a cleanup due to unused VM exits on top of it.
> 
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5] DM: dm-inplace-compress: inplace compressed DM target

[Ram Pai]

This  patch   provides   a   generic  device-mapper  compression device.
Originally written by Shaohua Li.
https://www.redhat.com/archives/dm-devel/2013-December/msg00143.html

I have optimized and hardened the code.

I have not received any negative comments till now.  Feel confident with the
code.  Please consider merging the code upstream.


Testing:
---
This compression block device  is   tested in  the  following scenarios
a) backing a ext4/xfs/btrfs filesystem 
b) backing swap

Ran 'badblocks' test on the compressed block device.
Thoroughly stress tested on PPC64 and x86 system.

I have included a test-script that I used to test the block device.

Version v5:
Modified the parameter list format to use token=value.
Fixed a coding issue noted by Julia Lawall.
Fixed data corruption issue when compressed size was same as the
original data.
Modified the allowed maximum I/O size to be as large as two pages,
without  which  larger  size  I/O  need  larger  size  buffers to 
temporarily hold  compressed data. This can lead  to inability to 
satisfy memory allocation requests.

Version v4:
fixed kbuild errors; hopefully they are all taken care off.
  - no reference to zero_page
  - convert all divide and mod operations to bit operations

Version v3:
Fixed  sector  alignment  bugs  exposed  while   testing on x86.
Explicitly set the maximum request size  to 128K.  Without which
range  locking  failed,  causing  I/Os  to  stamp   each  other.
Fixed an occasional data corruption  caused by wrong size of the
compression buffer.
Added  a   parameter   while  creation  of  the   block  device, 
to  not  sleep   during  memory  allocations. This can be useful
if the device is used as a swap device.

Version v2:
All patches are merged into a single patch.
Major code re-arrangement.
Data and metablocks allocated based on the length of the device
map rather than the size of the backing device.
Size   of   each entry   in  the bitmap array is explicitly set
 to 32bits.
Attempt  to  reuse  the  provided  bio  buffer  space   instead
 of allocating a new one.

Version v1:
Comments from Alasdair have been incorporated.
https://www.redhat.com/archives/dm-devel/2013-December/msg00144.html


Ram Pai (1):
  From: Shaohua Li 

 Documentation/device-mapper/dm-inplace-compress.txt |  174 +
 drivers/md/Kconfig  |6 
 drivers/md/Makefile |2 
 drivers/md/dm-inplace-compress.c| 2295 
 drivers/md/dm-inplace-compress.h|  194 +
 5 files changed, 2671 insertions(+)



-- Test script -
#!/bin/bash
# a test program to verify the correctness of
# the dm-inplace-compression target
# - Ram Pai

compdevname="__compdev"
usage()
{
echo 
echo 
echo "$1:  -d  [ -h ] [ -c  ]"
echo "-d  path to the block device to "
echo "  back the compression device"
echo "-c   some unique name of the compress"
echo " device name to be used. Defaults to $compdevname"
echo "-h help"
echo 
echo 
return
}

getsize()
{
#the target will spew out the maximum size that
#it can accommodate for the device. So start with
#insane number and let it fail.
insane=0009
dmsetup create $2 --table \
"0 $insane inplacecompress device=$1, \
writethrough,compressor=lzo" 2>/dev/null
echo $(dmesg | \
   grep 'dm-inplace-compress:  This device can accommodate at most'\
   | tail -1 | awk '{print $(NF-1)}')
}

MYNAME=$(basename $0)
OPTIND=0
while getopts "d:c:h" args $OPTIONS
do
 case "$args" in
d)  device=$OPTARG
;;
c)  compdevname=$OPTARG
;;
*)  usage $MYNAME
exit 1
;;
esac
done

if [ -z "$device" ]
then
usage $MYNAME
exit 1;
fi

if [ ! -b "$device" ]
then
usage $MYNAME
echo ERROR: $device is not a block device
exit 1;
fi

if [ -b "/dev/mapper/$compdevname" ]
then
echo "WARNING: $compdevname already exist"
usage $MYNAME
fi

echo -n "ANY DATA ON $device WILL BE LOST. Continue using $device?: y/n:"
read yesorno
if [ "$yesorno" != "y" ]
then
echo "Ok, exiting"
exit 1;
fi

dmsetup targets | grep inplacecompress > /dev/null
if [ $? -ne 0 ]
then
echo "Please enable dminplacecompress target in the kernel"
echo "Try modprobe dm-inplace-compress.ko"
exit 1
fi



#clean and init the device
dd if=/dev/zero of=$device count=100 2> /dev/null

dmsetup remove $compdevname 2> /dev/null
size=$(getsize $device $compdevnam

[PATCH v5 1/1] DM: inplace compressed DM target

[Ram Pai]

This is a simple DM target supporting inplace compression. Its best
suited for SSD. The underlying disk must support 512B sector size,
the target only supports 4k sector size.

Disk layout:
|super|...meta...|..data...|

Store unit is 4k (a block). Super is 1 block, which stores meta  and
data size and compression algorithm. Meta is a bitmap. For each data
 block, there are 5 bits meta.

Data:

Data of   a block is compressed. Compressed  data  is round up to 512B,
which is the payload. In disk, payload is  stored at  the beginning of
logical sector  of the block. Let's look  at an example.  Say we store
data to block A, which  is in sector  B(A*8), its orginal  size is 4k,
compressed size is  1500.Compressed data (CD)  will  use three
sectors (512B). The three  sectors  are the  payload. Payload  will be
stored at sector B.

---
... | CD1 | CD2 | CD3 |   |   |   |   || ...
---
^B^B+1  ^B+2  ^B+7 ^B+8

For this block, we will not use sector B+3 to B+7 (a hole). We use four
meta  bits  to  present payload  size. The compressed size (1500) isn't
stored in meta directly. Instead, we  store  it  at  the last 32bits of
payload. In this  example, we store it at the  end  of  sector  B+2. If
compressed size + sizeof(32bits)  crosses a   sector, payload size will
increase one sector.  If payload  uses 8 sectors, we store uncompressed
data directly.

If IO size is bigger than one block, we can store the data as an extent.
Data of the  whole extent will compressed and stored in the similar way
like above.  The first  block of the extent is the head, all others are
the tail.  If extent is 1 block,  the  block  is head. We have 1 bit of
meta to present if a  block  is  head  or  tail. If 4 meta bits of head
block can't  store  extent payload size, we will borrow tail block meta
bits to  store  payload  size.   Max  allowd extent size is 128k, so we
don't compress/decompress too big size data.

Meta:
Modifying   data   will modify meta too. Meta will be written(flush) to
disk   depending   on   meta   write   policy. We support writeback and
writethrough mode.  In  writeback mode, meta will be written to disk in
an interval or a  FLUSH  request.  In  writethrough mode, data and meta
data will be written to disk together.

Advantages:

1. Simple. Since  we  store  compressed  data  in-place,  we don't need
   complicated disk data management.
2. Efficient. For  each  4k, we only need 5 bits meta. 1T data will use
less than 200M meta, so we  can  load  all meta into memory. And actual
compression size is in payload. So   if  IO doesn't need RMW and we use
writeback meta flush, we don't  need  extra IO for meta.

Disadvantages:

1. hole. Since we   store  compressed data in-place, there are a lot of
   holes (in above  example,  B+3 - B+7) Hole can impact IO, because we
   can't do IO merge.

2. 1:1 size. Compression  doesn't  change disk  size. If disk is 1T, we
   can only store 1T data even we do compression.

But this is for SSD only. Generally SSD firmware has a FTL layer to map
disk  sectors  to flash nand. High end SSD firmware has filesystem-like
FTL.

1. hole. Disk has a lot of holes, but SSD FTL   can   still  store data
   continuous in nand. Even if we can't do IO   merge in  OS layer, SSD
   firmware can do it.

2. 1:1 size. On one side, we write compressed data to SSD, which means
   less  data is  written to SSD. This will be very helpful to improve
   SSD garbage collection, and  so write speed and life cycle. So even
   this is a problem, the target  is still helpful. On the other side,
   advanced SSD FTL can easily do thin provision. For example, if nand
   is   1T   and   we   let   SSD   report   it   as   2T,   and   use
   the  SSD  as  compressed target. In such SSD, we don't have the 1:1
   size issue.

So even if   SSD   FTL   cannot   map   non-continuous disk sectors to
continuous nand, the compression target can still function well.


Signed-off-by: Shaohua Li 
Signed-off-by: Ram Pai 
---
 .../device-mapper/dm-inplace-compress.txt  |  174 ++
 drivers/md/Kconfig |6 +
 drivers/md/Makefile|2 +
 drivers/md/dm-inplace-compress.c   | 2295 
 drivers/md/dm-inplace-compress.h   |  194 ++
 5 files changed, 2671 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-inplace-compress.txt
 create mode 100644 drivers/md/dm-inplace-compress.c
 create mode 100644 drivers/md/dm-inplace-compress.h

diff --git a/Documentation/device-mapper/dm-inplace-compress.txt 
b/Documentation/device-mapper/dm-inplace-compress.txt
new file mode 100644
index 000..2fa0d58
--- /dev/null
+++ b/Documentation/device-mapper/dm-inplace-compress.txt
@@ -0,0 +1,174 @@
+Device-Mapper's "inplace-compress" target provides inplace compression of block
+devices using t

Re: [PATCH] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-03-13 22:03+0200, Michael S. Tsirkin:
> On Mon, Mar 13, 2017 at 08:39:11PM +0100, Radim Krčmář wrote:
> > 2017-03-13 18:08+0200, Michael S. Tsirkin:
> > > On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
>> >> What about keeping just the last hunk to improve OS X, for now?
>> > 
>> > IMHO if we have a new functionality we are better of creating
>> > some way for guests to discover it is there.
>> > 
>> > Do we really have to argue about a single bit in HV leaf?
>> > What harm does it do?
>> 
>> It adds code to both guest and hosts and needs documentation ...
>> The bit is acceptable.  I just see no point in having it when there
>> already is a detection mechanism for mwait.
> 
> We don't want to use that standard detection mechanism IMHO at least
> not in all cases.

Enabling mwait by default would make sense if the guest OS monitored its
steal time and disabled mwait when it detects that it is not the main
user of the CPU, because mwait then hurts the host as well as the guest.

This would warrant some kind of paravirt as we still wouldn't want to
have standard mwait by default.  My problem is that the paravirt flag
alone is not enough for a normal mwait use on Intel.

>> In any case, this patch should also remove VM exits under SVM
> 
> AMD does not have MWAIT AFAIK. In any case, I don't see
> why can't SVM be a separate patch.

AMD just doesn't have MWAIT hints. (AMD has even MWAIT in userspace and
MWAITX, but they are not supported by KVM.)

The separate patch would have to be part of the same series as we don't
want to have vendor-specific detection, so I'd just remove these two in
the same patch to simplify handling:

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d1efe2c62b3f..18e53bc185d6 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1198,8 +1198,6 @@ static void init_vmcb(struct vcpu_svm *svm)
set_intercept(svm, INTERCEPT_CLGI);
set_intercept(svm, INTERCEPT_SKINIT);
set_intercept(svm, INTERCEPT_WBINVD);
-   set_intercept(svm, INTERCEPT_MONITOR);
-   set_intercept(svm, INTERCEPT_MWAIT);
set_intercept(svm, INTERCEPT_XSETBV);
 
control->iopm_base_pa = iopm_base;

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [PATCH v6] docs-rst: automatically convert Graphviz and SVG images

[Jonathan Corbet]

On Mon, 13 Mar 2017 19:16:54 +0100
Daniel Vetter  wrote:

> > Awesome! Can you pls send me/dri-devel a pull request with a stable tag
> > for drm-misc, so that I can apply all the drm diagram patches?  
> 
> Yes I'm annoying, but ping about the stable tag/pull request, so I can
> vacuum up the drm graph patches. Except for this technicality they're
> ready for merging.

Sorry, travel has put me behind on a few things...  So here's a pull
request at the point that Markus's patch was merged.  It'll drag in a few
other small changes, but they were already there when I got to this.

jon

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.lwn.net/linux.git tags/doc-4.11-images

for you to fetch changes up to db6ccf23e8ba40fc2e8914ec9c0eb950df71d9fe:

  docs-rst: automatically convert Graphviz and SVG images (2017-03-09 02:59:26 
-0700)


Pointer for Markus's image conversion work.


Daniel Vetter (1):
  doc: Explain light-handed markup preference a bit better

Jonathan Corbet (1):
  Merge tag 'v4.11-rc1' into docs-next

Kees Cook (1):
  docs: Clarify details for reporting security bugs

Markus Heiser (1):
  docs-rst: automatically convert Graphviz and SVG images

sayli karnik (3):
  Documentation: phy: Fix repetition of word 'the'
  Documentation: ABI: testing: sysfs-bus-pci: Fix repetition of word 'the'
  Documentation: cpu-freq: cpu-drivers: Fix repetition of word 'to'

 Documentation/ABI/testing/sysfs-bus-pci |   2 +-
 Documentation/admin-guide/security-bugs.rst |  39 +-
 Documentation/conf.py   |   2 +-
 Documentation/cpu-freq/cpu-drivers.txt  |   2 +-
 Documentation/doc-guide/hello.dot   |   3 +
 Documentation/doc-guide/sphinx.rst  | 115 +-
 Documentation/doc-guide/svg_image.svg   |  10 +
 Documentation/phy.txt   |   2 +-
 Documentation/process/changes.rst   |   7 +-
 Documentation/sphinx/kfigure.py | 551 
 10 files changed, 718 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/doc-guide/svg_image.svg
 create mode 100644 Documentation/sphinx/kfigure.py
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs-rst: Don't use explicit Makefile rules to build SVG and DOT files

[Jonathan Corbet]

On Thu,  9 Mar 2017 15:14:52 -0300
Mauro Carvalho Chehab  wrote:

> Now that we have an extension to handle images, use it.

Applied, finally - thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cpufreq: User/admin documentation update and consolidation

[Rafael J. Wysocki]

On Monday, March 13, 2017 04:54:38 PM Jonathan Corbet wrote:
> On Thu, 09 Mar 2017 16:28:32 +0100
> "Rafael J. Wysocki"  wrote:
> 
> > The user/admin documentation of cpufreq is badly outdated.  It
> > conains stale and/or inaccurate information along with things
> > that are not particularly useful.  Also, some of the important
> > pieces are missing from it.
> > 
> > For this reason, add a new user/admin document for cpufreq
> > containing current information to admin-guide and drop the old
> > outdated .txt documents it is replacing.
> 
> Out of curiosity, how did you generate this?  Neither "git am" nor
> "patch" wants to deal with it.  Can I ask for a retry?

Well, to be honest, I downloaded the previous iteration from Patchwork and
I though it would apply, so I didn't check.  Sorry about that.

The one below applies for me with "git am" on top of 4.11-rc2.

Thanks,
Rafael


---
From: Rafael J. Wysocki 
Subject: [PATCH] cpufreq: User/admin documentation update and consolidation

The user/admin documentation of cpufreq is badly outdated.  It
conains stale and/or inaccurate information along with things
that are not particularly useful.  Also, some of the important
pieces are missing from it.

For this reason, add a new user/admin document for cpufreq
containing current information to admin-guide and drop the old
outdated .txt documents it is replacing.

Since there will be more PM documents in admin-guide going forward,
create a separate directory for them and put the cpufreq document
in there right away.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
---
 Documentation/admin-guide/index.rst  |1 
 Documentation/admin-guide/pm/cpufreq.rst |  700 +++
 Documentation/admin-guide/pm/index.rst   |   15 
 Documentation/cpu-freq/boost.txt |   93 
 Documentation/cpu-freq/governors.txt |  301 -
 Documentation/cpu-freq/index.txt |7 
 Documentation/cpu-freq/user-guide.txt|  228 --
 7 files changed, 716 insertions(+), 629 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
@@ -0,0 +1,700 @@
+.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy 
`
+
+===
+CPU Performance Scaling
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki 
+
+The Concept of CPU Performance Scaling
+==
+
+The majority of modern processors are capable of operating in a number of
+different clock frequency and voltage configurations, often referred to as
+Operating Performance Points or P-states (in ACPI terminology).  As a rule,
+the higher the clock frequency and the higher the voltage, the more 
instructions
+can be retired by the CPU over a unit of time, but also the higher the clock
+frequency and the higher the voltage, the more energy is consumed over a unit 
of
+time (or the more power is drawn) by the CPU in the given P-state.  Therefore
+there is a natural tradeoff between the CPU capacity (the number of 
instructions
+that can be executed over a unit of time) and the power drawn by the CPU.
+
+In some situations it is desirable or even necessary to run the program as fast
+as possible and then there is no reason to use any P-states different from the
+highest one (i.e. the highest-performance frequency/voltage configuration
+available).  In some other cases, however, it may not be necessary to execute
+instructions so quickly and maintaining the highest available CPU capacity for 
a
+relatively long time without utilizing it entirely may be regarded as wasteful.
+It also may not be physically possible to maintain maximum CPU capacity for too
+long for thermal or power supply capacity reasons or similar.  To cover those
+cases, there are hardware interfaces allowing CPUs to be switched between
+different frequency/voltage configurations or (in the ACPI terminology) to be
+put into different P-states.
+
+Typically, they are used along with algorithms to estimate the required CPU
+capacity, so as to decide which P-states to put the CPUs into.  Of course, 
since
+the utilization of the system generally changes over time, that has to be done
+repeatedly on a regular basis.  The activity by which this happens is referred
+to as CPU performance scaling or CPU frequency scaling (because it involves
+adjusting the CPU clock frequency).
+
+
+CPU Performance Scaling in Linux
+
+
+The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
+(CPU Frequency scaling) subsystem that consists of three layers of code: the
+core, scaling governors and scaling drivers.
+
+The ``CPUFreq`` core provides the common code infrastructure and user space
+interfaces for all platforms that support CPU performance scaling.  It defines
+the basic framework in whi

Re: [PATCH] cpufreq: User/admin documentation update and consolidation

[Jonathan Corbet]

On Mon, 13 Mar 2017 23:59:57 +0100
"Rafael J. Wysocki"  wrote:

> Well, to be honest, I downloaded the previous iteration from Patchwork and
> I though it would apply, so I didn't check.  Sorry about that.
> 
> The one below applies for me with "git am" on top of 4.11-rc2.

Works for me too.  Now applied, thanks!

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Documentation: hid: fix path to input bus definitions

[Jonathan Corbet]

On Sun, 12 Mar 2017 12:54:21 +0100
Martin Kepplinger  wrote:

> The UAPI header split failed to update the documentation here; fix things
> accordingly.

I've applied all four to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] kvm: better MWAIT emulation for guests

[Michael S. Tsirkin]

Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
unless explicitly provided with kernel command line argument
"idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
without checking CPUID.

We currently emulate that as a NOP but on VMX we can do better: let
guest stop the CPU until timer, IPI or memory change.  CPU will be busy
but that isn't any worse than a NOP emulation.

Note that mwait within guests is not the same as on real hardware
because halt causes an exit while mwait doesn't.  For this reason it
might not be a good idea to use the regular MWAIT flag in CPUID to
signal this capability.  Add a flag in the hypervisor leaf instead.

Additionally, we add a capability for QEMU - e.g. if it knows there's an
isolated CPU dedicated for the VCPU it can set the standard MWAIT flag
to improve guest behaviour.

Reported-by: "Gabriel L. Somlo" 
Signed-off-by: Michael S. Tsirkin 
---

Note: SVM bits are untested at this point. Seems pretty
obvious though.

changes from v2:
- add a capability to allow host userspace to detect new kernels
- more documentation to clarify the semantics of the feature flag
  and why it's useful
- svm support as suggested by Radim

changes from v1:
- typo fix resulting in rest of leaf flags being overwritten
  Reported by: Wanpeng Li 
- updated commit log with data about guests helped by this feature
- better document differences between mwait and halt for guests

 Documentation/virtual/kvm/api.txt| 12 ++--
 Documentation/virtual/kvm/cpuid.txt  |  6 ++
 arch/x86/include/uapi/asm/kvm_para.h |  1 +
 arch/x86/kvm/cpuid.c |  3 +++
 arch/x86/kvm/svm.c   |  2 --
 arch/x86/kvm/vmx.c   |  4 
 arch/x86/kvm/x86.c   |  3 +++
 include/uapi/linux/kvm.h |  1 +
 8 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 0694509..c7beb07 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4135,11 +4135,11 @@ available, means that that the kernel can support 
guests using the
 radix MMU defined in Power ISA V3.00 (as implemented in the POWER9
 processor).
 
-8.4 KVM_CAP_PPC_HASH_MMU_V3
+8.5 KVM_CAP_X86_GUEST_MWAIT
 
-Architectures: ppc
+Architectures: x86
 
-This capability, if KVM_CHECK_EXTENSION indicates that it is
-available, means that that the kernel can support guests using the
-hashed page table MMU defined in Power ISA V3.00 (as implemented in
-the POWER9 processor), including in-memory segment tables.
+This capability indicates that guest using memory monotoring instructions
+(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit.  As such time
+spent while virtual CPU is halted in this way will then be accounted for as
+guest running time on the host (as opposed to e.g. HLT).
diff --git a/Documentation/virtual/kvm/cpuid.txt 
b/Documentation/virtual/kvm/cpuid.txt
index 3c65feb..04c201c 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest checks 
this feature bit
||   || before enabling paravirtualized
||   || spinlock support.
 --
+KVM_FEATURE_MWAIT  || 8 || guest can use monitor/mwait
+   ||   || to halt the VCPU without exits,
+   ||   || time spent while halted in this
+   ||   || way is accounted for on host as
+   ||   || VCPU run time.
+--
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
||   || per-cpu warps are expected in
||   || kvmclock.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index cff0bb6..9cc77a7 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
 #define KVM_FEATURE_STEAL_TIME 5
 #define KVM_FEATURE_PV_EOI 6
 #define KVM_FEATURE_PV_UNHALT  7
+#define KVM_FEATURE_MWAIT  8
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index efde6cc..3c7fca83 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
 
+