Re: [PATCH V3] drivers/mtd: add powernv flash MTD abstraction driver
On 06/02/2015 09:56 AM, Cyril Bur wrote: Powerpc powernv platforms allow access to certain system flash devices through a firmwarwe interface. This change adds an mtd driver for these flash devices. Minor updates from Jeremy Kerr and Joel Stanley. Signed-off-by: Cyril Bur Signed-off-by: Joel Stanley Signed-off-by: Jeremy Kerr Reviewed-by: Neelesh Gupta Neelesh. --- Hello Brian and MTD folk, Could I please get an ACK for Michael to take this through the powerpc tree. Thanks. V2: Address Brian Norris' review Fix typos Change from NAND flash type to NOR flash type Correctness tweaks V3: Address Neelesh Gupta's review Minor corrections Release the opal token on error Unregister mtd device on module remove --- drivers/mtd/devices/Kconfig | 8 + drivers/mtd/devices/Makefile| 1 + drivers/mtd/devices/powernv_flash.c | 286 3 files changed, 295 insertions(+) create mode 100644 drivers/mtd/devices/powernv_flash.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 33/36] genirq: Use helper function to access irq_data->msi_desc
On 2015/6/2 11:45, Michael Ellerman wrote: > On Mon, 2015-01-06 at 08:05:42 UTC, Jiang Liu wrote: >> Use irq_data access helper to access irq_data->msi_desc, so we could >> move msi_desc from struct irq_data into struct irq_common_data later. >> >> Signed-off-by: Jiang Liu >> --- >> arch/powerpc/sysdev/xics/ics-opal.c |2 +- >> arch/powerpc/sysdev/xics/ics-rtas.c |2 +- >> >> diff --git a/arch/powerpc/sysdev/xics/ics-opal.c >> b/arch/powerpc/sysdev/xics/ics-opal.c >> index 3996393c254d..27c936c080a6 100644 >> --- a/arch/powerpc/sysdev/xics/ics-opal.c >> +++ b/arch/powerpc/sysdev/xics/ics-opal.c >> @@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d) >> * card, using the MSI mask bits. Firmware doesn't appear to unmask >> * at that level, so we do it here by hand. >> */ >> -if (d->msi_desc) >> +if (irq_data_get_msi_desc(d)) >> pci_msi_unmask_irq(d); >> #endif >> >> diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c >> b/arch/powerpc/sysdev/xics/ics-rtas.c >> index e2665a9dfc0f..3854dd41558d 100644 >> --- a/arch/powerpc/sysdev/xics/ics-rtas.c >> +++ b/arch/powerpc/sysdev/xics/ics-rtas.c >> @@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d) >> * card, using the MSI mask bits. Firmware doesn't appear to unmask >> * at that level, so we do it here by hand. >> */ >> -if (d->msi_desc) >> +if (irq_data_get_msi_desc(d)) >> pci_msi_unmask_irq(d); >> #endif >> /* unmask it */ > > These look OK. > > Though I would point out we already have 16 irq_foo_get_bar() accessors?! Hi Michael, Thanks for review. We are trying to solve some issues introduced by hierarchy irqdomain/irqchip by splitting irq_data into a common part (irq_common_data) and per-chip part(irq_data). These accessors are used to ease the transition and hide implementation details. Thanks! Gerry > > Acked-by: Michael Ellerman > > cheers > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc/powernv: Add poweroff (EPOW, DPO) events support for PowerNV platform
Hi Michael,
Please add below minor additions in commit log once u
accept this patch. Thanks for your help with this. Let me know,
if anything else is needed from me on this.
Regards,
Vipin
On 05/18/2015 08:48 PM, Vipin K Parashar wrote:
This patch adds support for FSP EPOW (Early Power Off Warning) and
DPO (Delayed Power Off) events for PowerNV platform. EPOW events are
generated by SPCN/FSP due to various critical system conditions that
need system shutdown. Few examples of these conditions are high
ambient temperature or system running on UPS power with low UPS battery.
DPO event is generated in response to admin initiated system request.
s/system request/shutdown request/
Upon receipt of EPOW and DPO events host kernel invokes
orderly_poweroff for performing graceful system shutdown. System admin
can also add systemd service shutdown scripts to perform any specific
actions like graceful guest shutdown upon system poweroff. libvirt-guests
is systemd service available on recent distros for management of guests
at system start/shutdown time.
Signed-off-by: Vipin K Parashar
Reviewed-by: Joel Stanley
Reviewed-by: Vaibhav Jain
---
arch/powerpc/include/asm/opal-api.h| 44
arch/powerpc/include/asm/opal.h| 3 +-
arch/powerpc/platforms/powernv/opal-power.c| 147 ++---
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
4 files changed, 179 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..90fa364 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -355,6 +355,10 @@ enum opal_msg_type {
OPAL_MSG_TYPE_MAX,
};
+/* OPAL_MSG_SHUTDOWN parameter values */
+#defineSOFT_OFF0x00
+#defineSOFT_REBOOT 0x01
+
struct opal_msg {
__be32 msg_type;
__be32 reserved;
@@ -730,6 +734,46 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/*
+ * EPOW status sharing (OPAL and the host)
+ *
+ * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
+ * with individual elements being 16 bits wide to fetch the system
+ * wide EPOW status. Each element in the buffer will contain the
+ * EPOW status in it's bit representation for a particular EPOW sub
+ * class as defiend here. So multiple detailed EPOW status bits
+ * specific for any sub class can be represented in a single buffer
+ * element as it's bit representation.
+ */
+
+/* System EPOW type */
+enum OpalSysEpow {
+ OPAL_SYSEPOW_POWER = 0,/* Power EPOW */
+ OPAL_SYSEPOW_TEMP = 1,/* Temperature EPOW */
+ OPAL_SYSEPOW_COOLING= 2,/* Cooling EPOW */
+ OPAL_SYSEPOW_MAX= 3,/* Max EPOW categories */
+};
+
+/* Power EPOW */
+enum OpalSysPower {
+ OPAL_SYSPOWER_UPS = 0x0001, /* System on UPS power */
+ OPAL_SYSPOWER_CHNG = 0x0002, /* System power config change */
+ OPAL_SYSPOWER_FAIL = 0x0004, /* System impending power failure */
+ OPAL_SYSPOWER_INCL = 0x0008, /* System incomplete power */
+};
+
+/* Temperature EPOW */
+enum OpalSysTemp {
+ OPAL_SYSTEMP_AMB= 0x0001, /* System over ambient temperature */
+ OPAL_SYSTEMP_INT= 0x0002, /* System over internal temperature */
+ OPAL_SYSTEMP_HMD= 0x0004, /* System over ambient humidity */
+};
+
+/* Cooling EPOW */
+enum OpalSysCooling {
+ OPAL_SYSCOOL_INSF = 0x0001, /* System insufficient cooling */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..d30766f 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -141,7 +141,8 @@ int64_t opal_pci_fence_phb(uint64_t phb_id);
int64_t opal_pci_reinit(uint64_t phb_id, uint64_t reinit_scope, uint64_t
data);
int64_t opal_pci_mask_pe_error(uint64_t phb_id, uint16_t pe_number, uint8_t
error_type, uint8_t mask_action);
int64_t opal_set_slot_led_status(uint64_t phb_id, uint64_t slot_id, uint8_t
led_type, uint8_t led_action);
-int64_t opal_get_epow_status(__be64 *status);
+int64_t opal_get_epow_status(uint16_t *status, uint16_t *length);
+int64_t opal_get_dpo_status(int64_t *dpo_timeout);
int64_t opal_set_system_attention_led(uint8_t led_action);
int64_t opal_pci_next_error(uint64_t phb_id, __be64 *first_frozen_pe,
__be16 *pci_error_type, __be16 *severity);
diff --git a/arch/powerpc/platforms/powernv/opal-power.c
b/arch/powerpc/platforms/powernv/opal-power.c
index ac46c2c..581bbd8 100644
--- a/arch/powerpc/platforms/powernv/opal-power.c
+++ b/arch/powerpc/platforms/powernv/opal-power.c
@@ -1,5 +1,5 @@
/*
- * PowerNV OPAL power control for graceful shutdown handling
+ * PowerNV support for OPAL power-control, poweroff events
*
[PATCH v2] powerpc/pseries: Ratelimit EPOW event warnings
We print the respective warning after parsing EPOW interrupts,
prompting user to take action depending upon the severity of the
event.
Some times same EPOW event warning, such as below could flood kernel
log, over a period of time. So Limit the warnings by using ratelimit
variant of pr_err. Also, merge adjacent pr_err/pr_emerg into single
one to reduce the number of lines printed per warning.
May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
Signed-off-by: Kamalesh Babulal
Cc: Anshuman Khandual
Cc: Anton Blanchard
Cc: Michael Ellerman
---
v2 Changes:
- Merged multiple adjacent pr_err/pr_emerg into single line to reduce
multi-line
warnings, based on Michael's comments.
arch/powerpc/platforms/pseries/ras.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..3620935 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -145,17 +145,17 @@ static void rtas_parse_epow_errlog(struct rtas_error_log
*log)
switch (action_code) {
case EPOW_RESET:
- pr_err("Non critical power or cooling issue cleared");
+ pr_err_ratelimited("Non critical power or cooling issue
cleared");
break;
case EPOW_WARN_COOLING:
- pr_err("Non critical cooling issue reported by firmware");
- pr_err("Check RTAS error log for details");
+ pr_err_ratelimited("Non critical cooling issue reported by
firmware,"
+ " Check RTAS error log for details");
break;
case EPOW_WARN_POWER:
- pr_err("Non critical power issue reported by firmware");
- pr_err("Check RTAS error log for details");
+ pr_err_ratelimited("Non critical power issue reported by
firmware,"
+ " Check RTAS error log for details");
break;
case EPOW_SYSTEM_SHUTDOWN:
@@ -169,15 +169,14 @@ static void rtas_parse_epow_errlog(struct rtas_error_log
*log)
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
- pr_emerg("Critical power/cooling issue reported by firmware");
- pr_emerg("Check RTAS error log for details");
- pr_emerg("Immediate power off");
+ pr_emerg("Critical power/cooling issue reported by firmware,"
+" Check RTAS error log for details. Immediate power
off");
emergency_sync();
kernel_power_off();
break;
default:
- pr_err("Unknown power/cooling event (action code %d)",
+ pr_err_ratelimited("Unknown power/cooling event (action code
%d)",
action_code);
}
}
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/pseries: Ratelimit EPOW event warnings
* Michael Ellerman [2015-06-01 21:26:51]:
> On Thu, 2015-05-28 at 10:03 +0530, Kamalesh Babulal wrote:
> > We print the respective warning after parsing EPOW interrupts,
> > prompting user to take action depending upon the severity of the
> > event.
> >
> > Some times same EPOW event warning, such as below could flood kernel
> > log, within very short duration. So Limit the message by using
> > ratelimit variant of pr_err.
> >
> > May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
> > May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
> > May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
> > May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
> > May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
> > May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
> > May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
>
> Looking at the time stamps those are actually all fairly far apart in time,
> aren't they? So do we actually see them within a short duration in practice?
Thanks for the review. Agree, I should have phrased it better. My intend was to
say, that these warnings keep flooding the kernel log, over a period of time.
[..]
> > case EPOW_WARN_POWER:
> > - pr_err("Non critical power issue reported by firmware");
> > - pr_err("Check RTAS error log for details");
> > + pr_err_ratelimited("Non critical power issue reported by
> > firmware");
> > + pr_err_ratelimited("Check RTAS error log for details");
> > break;
>
> Those last two could be collapsed onto one line which would reduce the spam.
Yes, it could reduce the number of lines printed. Will resend the patch with the
changes.
Thanks,
Kamalesh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 34/34] vfio: powerpc/spapr: Support Dynamic DMA windows
On Fri, May 29, 2015 at 06:44:58PM +1000, Alexey Kardashevskiy wrote: > This adds create/remove window ioctls to create and remove DMA windows. > sPAPR defines a Dynamic DMA windows capability which allows > para-virtualized guests to create additional DMA windows on a PCI bus. > The existing linux kernels use this new window to map the entire guest > memory and switch to the direct DMA operations saving time on map/unmap > requests which would normally happen in a big amounts. > > This adds 2 ioctl handlers - VFIO_IOMMU_SPAPR_TCE_CREATE and > VFIO_IOMMU_SPAPR_TCE_REMOVE - to create and remove windows. > Up to 2 windows are supported now by the hardware and by this driver. > > This changes VFIO_IOMMU_SPAPR_TCE_GET_INFO handler to return additional > information such as a number of supported windows and maximum number > levels of TCE tables. > > DDW is added as a capability, not as a SPAPR TCE IOMMU v2 unique feature > as we still want to support v2 on platforms which cannot do DDW for > the sake of TCE acceleration in KVM (coming soon). > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpRdysyNySLP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 33/34] vfio: powerpc/spapr: Register memory and define IOMMU v2
On Fri, May 29, 2015 at 06:44:57PM +1000, Alexey Kardashevskiy wrote: > The existing implementation accounts the whole DMA window in > the locked_vm counter. This is going to be worse with multiple > containers and huge DMA windows. Also, real-time accounting would requite > additional tracking of accounted pages due to the page size difference - > IOMMU uses 4K pages and system uses 4K or 64K pages. > > Another issue is that actual pages pinning/unpinning happens on every > DMA map/unmap request. This does not affect the performance much now as > we spend way too much time now on switching context between > guest/userspace/host but this will start to matter when we add in-kernel > DMA map/unmap acceleration. > > This introduces a new IOMMU type for SPAPR - VFIO_SPAPR_TCE_v2_IOMMU. > New IOMMU deprecates VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE and introduces > 2 new ioctls to register/unregister DMA memory - > VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY - > which receive user space address and size of a memory region which > needs to be pinned/unpinned and counted in locked_vm. > New IOMMU splits physical pages pinning and TCE table update > into 2 different operations. It requires: > 1) guest pages to be registered first > 2) consequent map/unmap requests to work only with pre-registered memory. > For the default single window case this means that the entire guest > (instead of 2GB) needs to be pinned before using VFIO. > When a huge DMA window is added, no additional pinning will be > required, otherwise it would be guest RAM + 2GB. > > The new memory registration ioctls are not supported by > VFIO_SPAPR_TCE_IOMMU. Dynamic DMA window and in-kernel acceleration > will require memory to be preregistered in order to work. > > The accounting is done per the user process. > > This advertises v2 SPAPR TCE IOMMU and restricts what the userspace > can do with v1 or v2 IOMMUs. > > In order to support memory pre-registration, we need a way to track > the use of every registered memory region and only allow unregistration > if a region is not in use anymore. So we need a way to tell from what > region the just cleared TCE was from. > > This adds a userspace view of the TCE table into iommu_table struct. > It contains userspace address, one per TCE entry. The table is only > allocated when the ownership over an IOMMU group is taken which means > it is only used from outside of the powernv code (such as VFIO). > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson > --- > Changes: > v11: > * mm_iommu_put() does not return a code so this does not check it > * moved "v2" in tce_container to pack the struct > > v10: > * moved it_userspace allocation to vfio_iommu_spapr_tce as it VFIO > specific thing > * squashed "powerpc/iommu: Add userspace view of TCE table" into this as > it is > a part of IOMMU v2 > * s/tce_iommu_use_page_v2/tce_iommu_prereg_ua_to_hpa/ > * fixed some function names to have "tce_iommu_" in the beginning rather > just "tce_" > * as mm_iommu_mapped_inc() can now fail, check for the return code > > v9: > * s/tce_get_hva_cached/tce_iommu_use_page_v2/ > > v7: > * now memory is registered per mm (i.e. process) > * moved memory registration code to powerpc/mmu > * merged "vfio: powerpc/spapr: Define v2 IOMMU" into this > * limited new ioctls to v2 IOMMU > * updated doc > * unsupported ioclts return -ENOTTY instead of -EPERM > > v6: > * tce_get_hva_cached() returns hva via a pointer > > v4: > * updated docs > * s/kzmalloc/vzalloc/ > * in tce_pin_pages()/tce_unpin_pages() removed @vaddr, @size and > replaced offset with index > * renamed vfio_iommu_type_register_memory to vfio_iommu_spapr_register_memory > and removed duplicating vfio_iommu_spapr_register_memory > --- > Documentation/vfio.txt | 31 ++- > arch/powerpc/include/asm/iommu.h| 6 + > drivers/vfio/vfio_iommu_spapr_tce.c | 512 > ++-- > include/uapi/linux/vfio.h | 27 ++ > 4 files changed, 487 insertions(+), 89 deletions(-) > > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt > index 96978ec..7dcf2b5 100644 > --- a/Documentation/vfio.txt > +++ b/Documentation/vfio.txt > @@ -289,10 +289,12 @@ PPC64 sPAPR implementation note > > This implementation has some specifics: > > -1) Only one IOMMU group per container is supported as an IOMMU group > -represents the minimal entity which isolation can be guaranteed for and > -groups are allocated statically, one per a Partitionable Endpoint (PE) > +1) On older systems (POWER7 with P5IOC2/IODA1) only one IOMMU group per > +container is supported as an IOMMU table is allocated at the boot time, > +one table per a IOMMU group which is a Partitionable Endpoint (PE) > (PE is often a PCI domain but not always). > +Newer systems (POWER8 with IODA2) have improved hardware design which allows > +to remove this limitation and have multiple IOMMU gro
[PATCH V3] drivers/mtd: add powernv flash MTD abstraction driver
Powerpc powernv platforms allow access to certain system flash devices
through a firmwarwe interface. This change adds an mtd driver for these
flash devices.
Minor updates from Jeremy Kerr and Joel Stanley.
Signed-off-by: Cyril Bur
Signed-off-by: Joel Stanley
Signed-off-by: Jeremy Kerr
---
Hello Brian and MTD folk,
Could I please get an ACK for Michael to take this through the powerpc
tree.
Thanks.
V2: Address Brian Norris' review
Fix typos
Change from NAND flash type to NOR flash type
Correctness tweaks
V3: Address Neelesh Gupta's review
Minor corrections
Release the opal token on error
Unregister mtd device on module remove
---
drivers/mtd/devices/Kconfig | 8 +
drivers/mtd/devices/Makefile| 1 +
drivers/mtd/devices/powernv_flash.c | 286
3 files changed, 295 insertions(+)
create mode 100644 drivers/mtd/devices/powernv_flash.c
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index c49d0b1..f73c416 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -195,6 +195,14 @@ config MTD_BLOCK2MTD
Testing MTD users (eg JFFS2) on large media and media that might
be removed during a write (using the floppy drive).
+config MTD_POWERNV_FLASH
+ tristate "powernv flash MTD driver"
+ depends on PPC_POWERNV
+ help
+ This provides an MTD device to access flash on powernv OPAL
+ platforms from Linux. This device abstracts away the
+ firmware interface for flash access.
+
comment "Disk-On-Chip Device Drivers"
config MTD_DOCG3
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index f0b0e61..7912d3a 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MTD_SPEAR_SMI) += spear_smi.o
obj-$(CONFIG_MTD_SST25L) += sst25l.o
obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
obj-$(CONFIG_MTD_ST_SPI_FSM)+= st_spi_fsm.o
+obj-$(CONFIG_MTD_POWERNV_FLASH)+= powernv_flash.o
CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/powernv_flash.c
b/drivers/mtd/devices/powernv_flash.c
new file mode 100644
index 000..777e09f
--- /dev/null
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -0,0 +1,286 @@
+/*
+ * OPAL PNOR flash MTD abstraction
+ *
+ * IBM 2015
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+/*
+ * This driver creates the a Linux MTD abstraction for platform PNOR flash
+ * backed by OPAL calls
+ */
+
+struct powernv_flash {
+ struct mtd_info mtd;
+ u32 id;
+};
+
+enum flash_op {
+ FLASH_OP_READ,
+ FLASH_OP_WRITE,
+ FLASH_OP_ERASE,
+};
+
+static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
+ loff_t offset, size_t len, size_t *retlen, u_char *buf)
+{
+ struct powernv_flash *info = (struct powernv_flash *)mtd->priv;
+ struct device *dev = &mtd->dev;
+ int token;
+ struct opal_msg msg;
+ int rc;
+
+ dev_dbg(dev, "%s(op=%d, offset=0x%llx, len=%zu)\n",
+ __func__, op, offset, len);
+
+ token = opal_async_get_token_interruptible();
+ if (token < 0) {
+ if (token != -ERESTARTSYS)
+ dev_err(dev, "Failed to get an async token\n");
+
+ return token;
+ }
+
+ switch (op) {
+ case FLASH_OP_READ:
+ rc = opal_flash_read(info->id, offset, __pa(buf), len, token);
+ break;
+ case FLASH_OP_WRITE:
+ rc = opal_flash_write(info->id, offset, __pa(buf), len, token);
+ break;
+ case FLASH_OP_ERASE:
+ rc = opal_flash_erase(info->id, offset, len, token);
+ break;
+ default:
+ BUG_ON(1);
+ }
+
+ if (rc != OPAL_ASYNC_COMPLETION) {
+ dev_err(dev, "opal_flash_async_op(op=%d) failed (rc %d)\n",
+ op, rc);
+ opal_async_release_token(token);
+ return -EIO;
+ }
+
+ rc = opal_async_wait_response(token, &msg);
+ opal_async_release_token(token);
+ if (rc) {
+ dev_err(dev, "opal async wait failed (rc %d)\n", rc);
+ return -EIO;
+ }
+
+ rc = be64_to_cpu(msg.param
Re: [PATCH V7 04/10] powerpc/eeh: Trace first 7 BARs in address cache
On Tue, Jun 02, 2015 at 11:51:15AM +0800, Wei Yang wrote:
>On Mon, Jun 01, 2015 at 06:32:33PM -0500, Bjorn Helgaas wrote:
>>The subject says "Trace first 7 BARs..." I think maybe you meant "Track
>>first 7 BARs" or maybe "Cache only BARs, not windows or IOV BARs"
>>
>
>Agree, Track is more accurate.
>
>Gavin,
>
>Which subject you prefer?
>
"Cache only BARs, not windows or IOV BARs" is better.
>>On Tue, May 19, 2015 at 06:50:06PM +0800, Wei Yang wrote:
>>> EEH address cache, which helps to locate the PCI device according to
>>> the given (physical) MMIO address, didn't cover PCI bridges.
>>
>>"doesn't contain PCI bridge windows"?
>>
>>I see that eeh_addr_cache_insert_dev() ignores bridges because it never
>>calls __eeh_addr_cache_insert_dev() when "(dev->class >> 16) ==
>>PCI_BASE_CLASS_BRIDGE". I think it would be more technically correct if
>>you removed that test and relied on the "i <= PCI_ROM_RESOURCE" test in
>>this patch, because it is legal (though rare) for bridge devices to have
>>two BARs, and I assume you would want to put those in your cache if they
>>exist.
>>
>
>I think this is fine to remove the test "(dev->class >> 16) ==
>PCI_BASE_CLASS_BRIDGE" for a bridge and rely on the "i <= PCI_ROM_RESOURCE"
>
>Gavin,
>
>Do you thinks this is fine?
>
Fine to me.
>>> Also, it
>>> shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
>>> should be returned.
>>> The patch restricts the address cache to cover first 7 BARs for the
>>> above purposes.
>>>
>>> [gwshan: changelog]
>>> Signed-off-by: Wei Yang
>>> Acked-by: Gavin Shan
>>> ---
>>> arch/powerpc/kernel/eeh_cache.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kernel/eeh_cache.c
>>> b/arch/powerpc/kernel/eeh_cache.c
>>> index eeabeab..f6c5f05 100644
>>> --- a/arch/powerpc/kernel/eeh_cache.c
>>> +++ b/arch/powerpc/kernel/eeh_cache.c
>>> @@ -196,7 +196,7 @@ static void __eeh_addr_cache_insert_dev(struct pci_dev
>>> *dev)
>>> }
>>>
>>> /* Walk resources on this device, poke them into the tree */
>>> - for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>>> + for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>>> unsigned long start = pci_resource_start(dev,i);
>>> unsigned long end = pci_resource_end(dev,i);
>>> unsigned int flags = pci_resource_flags(dev,i);
>>> --
>>> 1.7.9.5
>>>
>
>--
>Richard Yang
>Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V3] drivers/mtd: add powernv flash MTD abstraction driver
On Mon, 2015-01-06 at 03:26:44 UTC, Cyril Bur wrote: > Powerpc powernv platforms allow access to certain system flash devices > through a firmwarwe interface. This change adds an mtd driver for these > flash devices. > > Minor updates from Jeremy Kerr and Joel Stanley. > > Signed-off-by: Cyril Bur > Signed-off-by: Joel Stanley > Signed-off-by: Jeremy Kerr > --- > V2: Address Brian Norris' review > Fix typos > Change from NAND flash type to NOR flash type > Correctness tweaks > V3: Address Neelesh Gupta's review > Minor corrections > Release the opal token on error > Unregister mtd device on module remove You seem to have dropped Brian and linux-mtd from Cc? Please put them back and repost, with a request for an ACK so we can take it via the powerpc tree. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 04/10] powerpc/eeh: Trace first 7 BARs in address cache
On Mon, Jun 01, 2015 at 06:32:33PM -0500, Bjorn Helgaas wrote:
>The subject says "Trace first 7 BARs..." I think maybe you meant "Track
>first 7 BARs" or maybe "Cache only BARs, not windows or IOV BARs"
>
Agree, Track is more accurate.
Gavin,
Which subject you prefer?
>On Tue, May 19, 2015 at 06:50:06PM +0800, Wei Yang wrote:
>> EEH address cache, which helps to locate the PCI device according to
>> the given (physical) MMIO address, didn't cover PCI bridges.
>
>"doesn't contain PCI bridge windows"?
>
>I see that eeh_addr_cache_insert_dev() ignores bridges because it never
>calls __eeh_addr_cache_insert_dev() when "(dev->class >> 16) ==
>PCI_BASE_CLASS_BRIDGE". I think it would be more technically correct if
>you removed that test and relied on the "i <= PCI_ROM_RESOURCE" test in
>this patch, because it is legal (though rare) for bridge devices to have
>two BARs, and I assume you would want to put those in your cache if they
>exist.
>
I think this is fine to remove the test "(dev->class >> 16) ==
PCI_BASE_CLASS_BRIDGE" for a bridge and rely on the "i <= PCI_ROM_RESOURCE"
Gavin,
Do you thinks this is fine?
>> Also, it
>> shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
>> should be returned.
>> The patch restricts the address cache to cover first 7 BARs for the
>> above purposes.
>>
>> [gwshan: changelog]
>> Signed-off-by: Wei Yang
>> Acked-by: Gavin Shan
>> ---
>> arch/powerpc/kernel/eeh_cache.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/eeh_cache.c
>> b/arch/powerpc/kernel/eeh_cache.c
>> index eeabeab..f6c5f05 100644
>> --- a/arch/powerpc/kernel/eeh_cache.c
>> +++ b/arch/powerpc/kernel/eeh_cache.c
>> @@ -196,7 +196,7 @@ static void __eeh_addr_cache_insert_dev(struct pci_dev
>> *dev)
>> }
>>
>> /* Walk resources on this device, poke them into the tree */
>> -for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> +for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>> unsigned long start = pci_resource_start(dev,i);
>> unsigned long end = pci_resource_end(dev,i);
>> unsigned int flags = pci_resource_flags(dev,i);
>> --
>> 1.7.9.5
>>
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 03/10] powerpc/pci: Remove VFs prior to PF
On Mon, Jun 01, 2015 at 06:20:05PM -0500, Bjorn Helgaas wrote:
>On Tue, May 19, 2015 at 06:50:05PM +0800, Wei Yang wrote:
>> As commit ac205b7b ("PCI: make sriov work with hotplug remove") indicates,
>
>The conventional reference is:
>
> ac205b7bb72f ("PCI: make sriov work with hotplug remove")
>
Thanks, will change it in next version.
>> VFs, which might be hooked to same PCI bus as their PF should be removed
>> before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
>> cause kernel crash.
>>
>> The patch applies the above pattern to PowerPC PCI hotplug path.
>>
>> [gwshan: changelog]
>> Signed-off-by: Wei Yang
>> Acked-by: Gavin Shan
>> ---
>> arch/powerpc/kernel/pci-hotplug.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/pci-hotplug.c
>> b/arch/powerpc/kernel/pci-hotplug.c
>> index 7ed85a6..98f84ed 100644
>> --- a/arch/powerpc/kernel/pci-hotplug.c
>> +++ b/arch/powerpc/kernel/pci-hotplug.c
>> @@ -50,7 +50,7 @@ void pcibios_remove_pci_devices(struct pci_bus *bus)
>>
>> pr_debug("PCI: Removing devices on bus %04x:%02x\n",
>> pci_domain_nr(bus), bus->number);
>> -list_for_each_entry_safe(dev, tmp, &bus->devices, bus_list) {
>> +list_for_each_entry_safe_reverse(dev, tmp, &bus->devices, bus_list) {
>> pr_debug(" Removing %s...\n", pci_name(dev));
>> pci_stop_and_remove_bus_device(dev);
>> }
>> --
>> 1.7.9.5
>>
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3, 33/36] genirq: Use helper function to access irq_data->msi_desc
On Mon, 2015-01-06 at 08:05:42 UTC, Jiang Liu wrote: > Use irq_data access helper to access irq_data->msi_desc, so we could > move msi_desc from struct irq_data into struct irq_common_data later. > > Signed-off-by: Jiang Liu > --- > arch/powerpc/sysdev/xics/ics-opal.c |2 +- > arch/powerpc/sysdev/xics/ics-rtas.c |2 +- > > diff --git a/arch/powerpc/sysdev/xics/ics-opal.c > b/arch/powerpc/sysdev/xics/ics-opal.c > index 3996393c254d..27c936c080a6 100644 > --- a/arch/powerpc/sysdev/xics/ics-opal.c > +++ b/arch/powerpc/sysdev/xics/ics-opal.c > @@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d) >* card, using the MSI mask bits. Firmware doesn't appear to unmask >* at that level, so we do it here by hand. >*/ > - if (d->msi_desc) > + if (irq_data_get_msi_desc(d)) > pci_msi_unmask_irq(d); > #endif > > diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c > b/arch/powerpc/sysdev/xics/ics-rtas.c > index e2665a9dfc0f..3854dd41558d 100644 > --- a/arch/powerpc/sysdev/xics/ics-rtas.c > +++ b/arch/powerpc/sysdev/xics/ics-rtas.c > @@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d) >* card, using the MSI mask bits. Firmware doesn't appear to unmask >* at that level, so we do it here by hand. >*/ > - if (d->msi_desc) > + if (irq_data_get_msi_desc(d)) > pci_msi_unmask_irq(d); > #endif > /* unmask it */ These look OK. Though I would point out we already have 16 irq_foo_get_bar() accessors?! Acked-by: Michael Ellerman cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
On Tue, 2015-06-02 at 10:53, Wood Scott wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 02, 2015 10:53 AM
> To: Zhao Qiang-B45475
> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
>
> On Tue, 2015-06-02 at 10:37 +0800, Zhao Qiang wrote:
> > ls1 has qe and ls1 has arm cpu.
> > move qe from arch/powerpc to drivers/soc/fsl to adapt to powerpc and
> > arm
> >
> > Signed-off-by: Zhao Qiang
> > ---
> > Changes for v2:
> > - move code to driver/soc
> > Changes for v3:
> > - change drivers/soc/qe to drivers/soc/fsl-qe Changes for v4:
> > - move drivers/soc/fsl-qe to drivers/soc/fsl/qe
> > - move head files for qe from include/linux/fsl to
> include/soc/fsl
> > - move qe_ic.c to drivers/irqchip/ Changes for v5:
> > - update MAINTAINERS
> >
> > MAINTAINERS| 5 +++--
> > arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
> > arch/powerpc/platforms/83xx/misc.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
> > arch/powerpc/platforms/85xx/common.c | 2 +-
> > arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
> > arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
> > arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
> > arch/powerpc/platforms/Kconfig | 19
> > --
> > arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++--
> > --
> > arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
> > arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
> > arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
> > arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
> > drivers/irqchip/Makefile | 1 +
> > .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
> > .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
> > drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> > drivers/net/ethernet/freescale/ucc_geth.c | 8
> > drivers/net/ethernet/freescale/ucc_geth.h | 8
> > drivers/soc/Kconfig| 2 ++
> > drivers/soc/Makefile | 1 +
> > drivers/soc/fsl/Makefile | 5 +
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +---
> > ---
> > drivers/soc/fsl/qe/Makefile| 8
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
> > .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
> > .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
> > drivers/spi/spi-fsl-cpm.c | 2 +-
> > drivers/tty/serial/ucc_uart.c | 2 +-
> > drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> > drivers/usb/host/fhci-hcd.c| 2 +-
> > drivers/usb/host/fhci-hub.c| 2 +-
> > drivers/usb/host/fhci-sched.c | 2 +-
> > drivers/usb/host/fhci.h| 4 ++--
> > .../include/asm => include/linux/fsl}/qe_ic.h | 0
> > .../include/asm => include/soc/fsl}/immap_qe.h | 0
> > {arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
> > .../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
> > .../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
> > .../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
> > 46 files changed, 103 insertions(+), 115 deletions(-) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%) create
> > mode 100644 drivers/soc/fsl/Makefile copy {arch/powerpc/sysdev/qe_lib
> > => drivers/soc/fsl/qe}/Kconfig
> > (50%)
> > create mode 100644 drivers/soc/fsl/qe/Makefile rename
> > {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c
> > (98%)
> > rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c
> > (99%) rename {arch/powerpc/sysdev/qe_lib =>
> > drivers/soc/fsl/qe}/ucc_slow.c (98%) rename {arch/powerpc/include/asm
> > => include/linux/fsl}/qe_ic.h
> > (100%)
> > rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h
> > (100%)
> > rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
> > rename {arch/powerpc/include/asm => include/soc/fsl}/u
[PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm
Signed-off-by: Zhao Qiang
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc/fsl-qe to drivers/soc/fsl/qe
- move head files for qe from include/linux/fsl to include/soc/fsl
- move qe_ic.c to drivers/irqchip/
Changes for v5:
- update MAINTAINERS
MAINTAINERS| 5 +++--
arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
arch/powerpc/platforms/Kconfig | 19 --
arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++
arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
drivers/irqchip/Makefile | 1 +
.../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
.../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8
drivers/net/ethernet/freescale/ucc_geth.h | 8
drivers/soc/Kconfig| 2 ++
drivers/soc/Makefile | 1 +
drivers/soc/fsl/Makefile | 5 +
.../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +--
drivers/soc/fsl/qe/Makefile| 8
.../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
.../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
.../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
.../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 ++--
.../include/asm => include/linux/fsl}/qe_ic.h | 0
.../include/asm => include/soc/fsl}/immap_qe.h | 0
{arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
.../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
.../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
.../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
46 files changed, 103 insertions(+), 115 deletions(-)
rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%)
create mode 100644 drivers/soc/fsl/Makefile
copy {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig (50%)
create mode 100644 drivers/soc/fsl/qe/Makefile
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_slow.c (98%)
rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_slow.h (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index c43ea88..84b234b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3743,8 +3743,9 @@ F:include/linux/fs_enet_pd.h
FREESCALE QUICC ENGINE LIBRARY
L: linuxppc-dev@lists.ozlabs.org
S: Orphan
-F: arch/powerpc/sysdev/qe_lib/
-F: arch/powerpc/include/asm/*qe.h
+F: drivers/soc/fsl/qe/
+F: include/soc/fsl/*qe*.h
+F: include/soc/fsl/*ucc*.h
FREESCALE USB PERIPHERAL DRIVERS
M: Li Yang
diff --git a/arch/powerpc/platforms/83xx/km83xx.c
b/arch/powerpc/platforms/83xx/km83xx.
Re: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
On Tue, 2015-06-02 at 10:37 +0800, Zhao Qiang wrote:
> ls1 has qe and ls1 has arm cpu.
> move qe from arch/powerpc to drivers/soc/fsl
> to adapt to powerpc and arm
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2:
> - move code to driver/soc
> Changes for v3:
> - change drivers/soc/qe to drivers/soc/fsl-qe
> Changes for v4:
> - move drivers/soc/fsl-qe to drivers/soc/fsl/qe
> - move head files for qe from include/linux/fsl to include/soc/fsl
> - move qe_ic.c to drivers/irqchip/
> Changes for v5:
> - update MAINTAINERS
>
> MAINTAINERS| 5 +++--
> arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
> arch/powerpc/platforms/83xx/misc.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
> arch/powerpc/platforms/85xx/common.c | 2 +-
> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
> arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
> arch/powerpc/platforms/Kconfig | 19
> --
> arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++--
> --
> arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
> arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
> arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
> arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
> drivers/irqchip/Makefile | 1 +
> .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
> .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 8
> drivers/net/ethernet/freescale/ucc_geth.h | 8
> drivers/soc/Kconfig| 2 ++
> drivers/soc/Makefile | 1 +
> drivers/soc/fsl/Makefile | 5 +
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +---
> ---
> drivers/soc/fsl/qe/Makefile| 8
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
> .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
> .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
> drivers/spi/spi-fsl-cpm.c | 2 +-
> drivers/tty/serial/ucc_uart.c | 2 +-
> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> drivers/usb/host/fhci-hcd.c| 2 +-
> drivers/usb/host/fhci-hub.c| 2 +-
> drivers/usb/host/fhci-sched.c | 2 +-
> drivers/usb/host/fhci.h| 4 ++--
> .../include/asm => include/linux/fsl}/qe_ic.h | 0
> .../include/asm => include/soc/fsl}/immap_qe.h | 0
> {arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
> .../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
> .../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
> .../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
> 46 files changed, 103 insertions(+), 115 deletions(-)
> rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%)
> create mode 100644 drivers/soc/fsl/Makefile
> copy {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig
> (50%)
> create mode 100644 drivers/soc/fsl/qe/Makefile
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c
> (98%)
> rename {arch/powerpc/sysdev/qe_lib =>
> drivers/soc/fsl/qe}/ucc_fast.c (99%)
> rename {arch/powerpc/sysdev/qe_lib =>
> drivers/soc/fsl/qe}/ucc_slow.c (98%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h
> (100%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h
> (100%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc.h (96%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_fast.h
> (98%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_slow.h
> (99%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c43ea88..84b234b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3743,8 +3743,9 @@ F: include/linux/fs_enet_pd.h
> FREESCALE QUICC ENGINE LIBRARY
> L: linuxppc-dev@lists.ozlabs.org
> S: Orphan
> -F: arch/powerpc/sysdev/qe_lib/
> -F: arch/powerpc/includ
Re: [PATCH kernel v11 32/34] powerpc/mmu: Add userspace-to-physical addresses translation cache
On Fri, May 29, 2015 at 06:44:56PM +1000, Alexey Kardashevskiy wrote: > We are adding support for DMA memory pre-registration to be used in > conjunction with VFIO. The idea is that the userspace which is going to > run a guest may want to pre-register a user space memory region so > it all gets pinned once and never goes away. Having this done, > a hypervisor will not have to pin/unpin pages on every DMA map/unmap > request. This is going to help with multiple pinning of the same memory. > > Another use of it is in-kernel real mode (mmu off) acceleration of > DMA requests where real time translation of guest physical to host > physical addresses is non-trivial and may fail as linux ptes may be > temporarily invalid. Also, having cached host physical addresses > (compared to just pinning at the start and then walking the page table > again on every H_PUT_TCE), we can be sure that the addresses which we put > into TCE table are the ones we already pinned. > > This adds a list of memory regions to mm_context_t. Each region consists > of a header and a list of physical addresses. This adds API to: > 1. register/unregister memory regions; > 2. do final cleanup (which puts all pre-registered pages); > 3. do userspace to physical address translation; > 4. manage usage counters; multiple registration of the same memory > is allowed (once per container). > > This implements 2 counters per registered memory region: > - @mapped: incremented on every DMA mapping; decremented on unmapping; > initialized to 1 when a region is just registered; once it becomes zero, > no more mappings allowe; > - @used: incremented on every "register" ioctl; decremented on > "unregister"; unregistration is allowed for DMA mapped regions unless > it is the very last reference. For the very last reference this checks > that the region is still mapped and returns -EBUSY so the userspace > gets to know that memory is still pinned and unregistration needs to > be retried; @used remains 1. > > Host physical addresses are stored in vmalloc'ed array. In order to > access these in the real mode (mmu off), there is a real_vmalloc_addr() > helper. In-kernel acceleration patchset will move it from KVM to MMU code. > > Signed-off-by: Alexey Kardashevskiy There's a bunch of ways this could be cleaned up, but those can be done later. So, Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpa_fltUfJMD.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 31/34] vfio: powerpc/spapr: powerpc/powernv/ioda2: Use DMA windows API in ownership control
On Fri, May 29, 2015 at 06:44:55PM +1000, Alexey Kardashevskiy wrote: > Before the IOMMU user (VFIO) would take control over the IOMMU table > belonging to a specific IOMMU group. This approach did not allow sharing > tables between IOMMU groups attached to the same container. > > This introduces a new IOMMU ownership flavour when the user can not > just control the existing IOMMU table but remove/create tables on demand. > If an IOMMU implements take/release_ownership() callbacks, this lets > the user have full control over the IOMMU group. When the ownership > is taken, the platform code removes all the windows so the caller must > create them. > Before returning the ownership back to the platform code, VFIO > unprograms and removes all the tables it created. > > This changes IODA2's onwership handler to remove the existing table > rather than manipulating with the existing one. From now on, > iommu_take_ownership() and iommu_release_ownership() are only called > from the vfio_iommu_spapr_tce driver. > > Old-style ownership is still supported allowing VFIO to run on older > P5IOC2 and IODA IO controllers. > > No change in userspace-visible behaviour is expected. Since it recreates > TCE tables on each ownership change, related kernel traces will appear > more often. > > This adds a pnv_pci_ioda2_setup_default_config() which is called > when PE is being configured at boot time and when the ownership is > passed from VFIO to the platform code. > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpZMJC7u2NIS.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 30/34] powerpc/iommu/ioda2: Add get_table_size() to calculate the size of future table
On Fri, May 29, 2015 at 06:44:54PM +1000, Alexey Kardashevskiy wrote: > This adds a way for the IOMMU user to know how much a new table will > use so it can be accounted in the locked_vm limit before allocation > happens. > > This stores the allocated table size in pnv_pci_ioda2_get_table_size() > so the locked_vm counter can be updated correctly when a table is > being disposed. > > This defines an iommu_table_group_ops callback to let VFIO know > how much memory will be locked if a table is created. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpNb8tySHrN9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 29/34] powerpc/powernv/ioda2: Use new helpers to do proper cleanup on PE release
On Fri, May 29, 2015 at 06:44:53PM +1000, Alexey Kardashevskiy wrote: > The existing code programmed TVT#0 with some address and then > immediately released that memory. > > This makes use of pnv_pci_ioda2_unset_window() and > pnv_pci_ioda2_set_bypass() which do correct resource release and > TVT update. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpBC5U1y63CC.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 28/34] vfio: powerpc/spapr: powerpc/powernv/ioda: Define and implement DMA windows API
On Fri, May 29, 2015 at 06:44:52PM +1000, Alexey Kardashevskiy wrote: > This extends iommu_table_group_ops by a set of callbacks to support > dynamic DMA windows management. > > create_table() creates a TCE table with specific parameters. > it receives iommu_table_group to know nodeid in order to allocate > TCE table memory closer to the PHB. The exact format of allocated > multi-level table might be also specific to the PHB model (not > the case now though). > This callback calculated the DMA window offset on a PCI bus from @num > and stores it in a just created table. > > set_window() sets the window at specified TVT index + @num on PHB. > > unset_window() unsets the window from specified TVT. > > This adds a free() callback to iommu_table_ops to free the memory > (potentially a tree of tables) allocated for the TCE table. > > create_table() and free() are supposed to be called once per > VFIO container and set_window()/unset_window() are supposed to be > called for every group in a container. > > This adds IOMMU capabilities to iommu_table_group such as default > 32bit window parameters and others. This makes use of new values in > vfio_iommu_spapr_tce. IODA1/P5IOC2 do not support DDW so they do not > advertise pagemasks to the userspace. > > Signed-off-by: Alexey Kardashevskiy > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpqt8EoOHMOx.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Set up and enable PSL Timebase
On Mon, 2015-06-01 at 15:56 +0200, Philippe Bergheaud wrote: > Michael Neuling wrote: > > Please use negative error codes here. -EIO? > > And check it here. > > Mikey, > > I am reluctant to fail the entire CAPI init after a PSL timebase sync failure. > If we ignore the error, the CAPI device stays available (without timebase > sync). > If we honour the error, the CAPI device fails entirely. > > I know three reasons why PSL timebase sync can fail: > 1. h/w failure This would be a good reason to fail it. Bad hardware, we should fail. > 2. OPAL did not initialize the CAPP timebase (wrong OPAL version) This would not as we are going to have to deal with older opal for a while. Is there a way for us to tell if OPAL has this capability? I guess we could add something to the device tree of the PHB node if we know the timebase has been synced. > 3. the PCIe bus was not powered off/on between shutdown and reboot We should fix that. What's the problem? > I think that it is premature to choose to fail the entire CAPI init in all > cases. > In particular, point 3. introduces a regression, as PCIe off/on was never a > requirement for booting CAPI on P8. We should fix it. Is a PERST enough? > I have tried one workaround do far: forcing the 0 to 1 transition of the tb > bit of the PSL register TB_CTLSTAT. > In vain. > > What do you think? The OPAL one (2) is the most concerning but let's work out if we can determine if the syncing has happened in the CAPP unit or not. If we know it's synced but it fails your test, then I think we should fail the whole probe. I the other reasons (1 and 3) shouldn't be ignored. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 27/34] powerpc/powernv: Implement multilevel TCE tables
On Fri, May 29, 2015 at 06:44:51PM +1000, Alexey Kardashevskiy wrote:
> TCE tables might get too big in case of 4K IOMMU pages and DDW enabled
> on huge guests (hundreds of GB of RAM) so the kernel might be unable to
> allocate contiguous chunk of physical memory to store the TCE table.
>
> To address this, POWER8 CPU (actually, IODA2) supports multi-level
> TCE tables, up to 5 levels which splits the table into a tree of
> smaller subtables.
>
> This adds multi-level TCE tables support to
> pnv_pci_ioda2_table_alloc_pages() and pnv_pci_ioda2_table_free_pages()
> helpers.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> Changes:
> v10:
> * fixed multiple comments received for v9
>
> v9:
> * moved from ioda2 to common powernv pci code
> * fixed cleanup if allocation fails in a middle
> * removed check for the size - all boundary checks happen in the calling code
> anyway
> ---
> arch/powerpc/include/asm/iommu.h | 2 +
> arch/powerpc/platforms/powernv/pci-ioda.c | 98
> ---
> arch/powerpc/platforms/powernv/pci.c | 13
> 3 files changed, 104 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/iommu.h
> b/arch/powerpc/include/asm/iommu.h
> index 4636734..706cfc0 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -96,6 +96,8 @@ struct iommu_pool {
> struct iommu_table {
> unsigned long it_busno; /* Bus number this table belongs to */
> unsigned long it_size; /* Size of iommu table in entries */
> + unsigned long it_indirect_levels;
> + unsigned long it_level_size;
> unsigned long it_offset;/* Offset into global table */
> unsigned long it_base; /* mapped address of tce table */
> unsigned long it_index; /* which iommu table this is */
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index fda01c1..68ffc7a 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -49,6 +49,9 @@
> /* 256M DMA window, 4K TCE pages, 8 bytes TCE */
> #define TCE32_TABLE_SIZE ((0x1000 / 0x1000) * 8)
>
> +#define POWERNV_IOMMU_DEFAULT_LEVELS 1
> +#define POWERNV_IOMMU_MAX_LEVELS 5
> +
> static void pnv_pci_ioda2_table_free_pages(struct iommu_table *tbl);
>
> static void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
> @@ -1975,6 +1978,8 @@ static long pnv_pci_ioda2_set_window(struct
> iommu_table_group *table_group,
> table_group);
> struct pnv_phb *phb = pe->phb;
> int64_t rc;
> + const unsigned long size = tbl->it_indirect_levels ?
> + tbl->it_level_size : tbl->it_size;
> const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
> const __u64 win_size = tbl->it_size << tbl->it_page_shift;
>
> @@ -1989,9 +1994,9 @@ static long pnv_pci_ioda2_set_window(struct
> iommu_table_group *table_group,
> rc = opal_pci_map_pe_dma_window(phb->opal_id,
> pe->pe_number,
> pe->pe_number << 1,
> - 1,
> + tbl->it_indirect_levels + 1,
> __pa(tbl->it_base),
> - tbl->it_size << 3,
> + size << 3,
> IOMMU_PAGE_SIZE(tbl));
> if (rc) {
> pe_err(pe, "Failed to configure TCE table, err %ld\n", rc);
> @@ -2071,11 +2076,19 @@ static void pnv_pci_ioda_setup_opal_tce_kill(struct
> pnv_phb *phb)
> phb->ioda.tce_inval_reg = ioremap(phb->ioda.tce_inval_reg_phys, 8);
> }
>
> -static __be64 *pnv_pci_ioda2_table_do_alloc_pages(int nid, unsigned shift)
> +static __be64 *pnv_pci_ioda2_table_do_alloc_pages(int nid, unsigned shift,
> + unsigned levels, unsigned long limit,
> + unsigned long *tce_table_allocated)
> {
> struct page *tce_mem = NULL;
> - __be64 *addr;
> + __be64 *addr, *tmp;
> unsigned order = max_t(unsigned, shift, PAGE_SHIFT) - PAGE_SHIFT;
> + unsigned long local_allocated = 1UL << (order + PAGE_SHIFT);
> + unsigned entries = 1UL << (shift - 3);
> + long i;
> +
> + if (*tce_table_allocated >= limit)
> + return NULL;
I'm not quite clear what case this limit logic is trying to catch.
>
> tce_mem = alloc_pages_node(nid, GFP_KERNEL, order);
> if (!tce_mem) {
> @@ -2083,31 +2096,69 @@ static __be64 *pnv_pci_ioda2_table_do_alloc_pages(int
> nid, unsigned shift)
> return NULL;
> }
> addr = page_address(tce_mem);
> - memset(addr, 0, 1UL << (order + PAGE_SHIFT));
> + memset(addr, 0, local_allocated);
> +
> + --levels;
> + if (!levels) {
> + *tce_table_allocated += local_allocated;
> + return addr;
> + }
> +
> + for (i = 0; i < entries; ++i) {
> + tmp = pnv_pci_ioda2_table_do_alloc_pages(n
Re: [PATCH kernel v11 26/34] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
On Fri, May 29, 2015 at 06:44:50PM +1000, Alexey Kardashevskiy wrote:
> This is a part of moving DMA window programming to an iommu_ops
> callback. pnv_pci_ioda2_set_window() takes an iommu_table_group as
> a first parameter (not pnv_ioda_pe) as it is going to be used as
> a callback for VFIO DDW code.
>
> This adds pnv_pci_ioda2_tvt_invalidate() to invalidate TVT as it is
I'm assuming that's what's now called pnv_pci_ioda2_invalidate_entire()?
> a good thing to do. It does not have immediate effect now as the table
> is never recreated after reboot but it will in the following patches.
>
> This should cause no behavioural change.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> Reviewed-by: Gavin Shan
> ---
> Changes:
> v11:
> * replaced some 1<
> v9:
> * initialize pe->table_group.tables[0] at the very end when
> tbl is fully initialized
> * moved pnv_pci_ioda2_tvt_invalidate() from earlier patch
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 47
> +--
> 1 file changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 3d29fe3..fda01c1 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1968,6 +1968,43 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
> *phb,
> }
> }
>
> +static long pnv_pci_ioda2_set_window(struct iommu_table_group *table_group,
> + int num, struct iommu_table *tbl)
> +{
> + struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
> + table_group);
> + struct pnv_phb *phb = pe->phb;
> + int64_t rc;
> + const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
> + const __u64 win_size = tbl->it_size << tbl->it_page_shift;
> +
> + pe_info(pe, "Setting up window %llx..%llx pg=%x\n",
> + start_addr, start_addr + win_size - 1,
> + IOMMU_PAGE_SIZE(tbl));
> +
> + /*
> + * Map TCE table through TVT. The TVE index is the PE number
> + * shifted by 1 bit for 32-bits DMA space.
> + */
> + rc = opal_pci_map_pe_dma_window(phb->opal_id,
> + pe->pe_number,
> + pe->pe_number << 1,
> + 1,
> + __pa(tbl->it_base),
> + tbl->it_size << 3,
> + IOMMU_PAGE_SIZE(tbl));
> + if (rc) {
> + pe_err(pe, "Failed to configure TCE table, err %ld\n", rc);
> + return rc;
> + }
> +
> + pnv_pci_link_table_and_group(phb->hose->node, num,
> + tbl, &pe->table_group);
> + pnv_pci_ioda2_tce_invalidate_entire(pe);
> +
> + return 0;
> +}
> +
> static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
> {
> uint16_t window_id = (pe->pe_number << 1 ) + 1;
> @@ -2123,21 +2160,13 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
> *phb,
> pe->table_group.ops = &pnv_pci_ioda2_ops;
> #endif
>
> - /*
> - * Map TCE table through TVT. The TVE index is the PE number
> - * shifted by 1 bit for 32-bits DMA space.
> - */
> - rc = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
> - pe->pe_number << 1, 1, __pa(tbl->it_base),
> - tbl->it_size << 3, 1ULL << tbl->it_page_shift);
> + rc = pnv_pci_ioda2_set_window(&pe->table_group, 0, tbl);
> if (rc) {
> pe_err(pe, "Failed to configure 32-bit TCE table,"
> " err %ld\n", rc);
> goto fail;
> }
>
> - pnv_pci_ioda2_tce_invalidate_entire(pe);
> -
> /* OPAL variant of PHB3 invalidated TCEs */
> if (phb->ioda.tce_inval_reg)
> tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpAA90oqhodz.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 08/10] powerpc/powernv: Support PCI config restore for VFs
On Tue, May 19, 2015 at 06:50:10PM +0800, Wei Yang wrote:
> After PE reset, OPAL API opal_pci_reinit() is called on all devices
> contained in the PE to reinitialize them. However, VFs can't be seen
> from skiboot firmware. We have to implement the functions, similar
> those in skiboot firmware, to reinitialize VFs after reset on PE
> for VFs.
>
> [gwshan: changelog and code refactoring]
> Signed-off-by: Wei Yang
> Acked-by: Gavin Shan
> ---
> arch/powerpc/include/asm/pci-bridge.h|1 +
> arch/powerpc/platforms/powernv/eeh-powernv.c | 70
> +-
> arch/powerpc/platforms/powernv/pci.c | 18 +++
> 3 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h
> b/arch/powerpc/include/asm/pci-bridge.h
> index c324882..ad60263 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -206,6 +206,7 @@ struct pci_dn {
> #define IODA_INVALID_M64(-1)
> int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
> #endif /* CONFIG_PCI_IOV */
> + int mps;
> #endif
> struct list_head child_list;
> struct list_head list;
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
> b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index 7af3c1e..33deb78 100644
> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -1612,6 +1612,67 @@ static int pnv_eeh_next_error(struct eeh_pe **pe)
> return ret;
> }
>
> +static int pnv_eeh_restore_vf_config(struct pci_dn *pdn)
> +{
> + struct eeh_dev *edev = pdn_to_eeh_dev(pdn);
> + u32 devctl, cmd, cap2, aer_capctl;
> + int old_mps;
> +
> + /* Restore MPS */
> + if (edev->pcie_cap) {
> + old_mps = (ffs(pdn->mps) - 8) << 5;
> + eeh_ops->read_config(pdn, edev->pcie_cap + PCI_EXP_DEVCTL,
> + 2, &devctl);
> + devctl &= ~PCI_EXP_DEVCTL_PAYLOAD;
> + devctl |= old_mps;
> + eeh_ops->write_config(pdn, edev->pcie_cap + PCI_EXP_DEVCTL,
> + 2, devctl);
> + }
> +
> + /* Disable Completion Timeout */
> + if (edev->pcie_cap) {
> + eeh_ops->read_config(pdn, edev->pcie_cap + PCI_EXP_DEVCAP2,
> + 4, &cap2);
> + if (cap2 & 0x10) {
> + eeh_ops->read_config(pdn,
> + edev->pcie_cap + PCI_EXP_DEVCTL2,
> + 4, &cap2);
> + cap2 |= 0x10;
> + eeh_ops->write_config(pdn,
> + edev->pcie_cap + PCI_EXP_DEVCTL2,
> + 4, cap2);
> + }
> + }
> +
> + /* Enable SERR and parity checking */
> + eeh_ops->read_config(pdn, PCI_COMMAND, 2, &cmd);
> + cmd |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
> + eeh_ops->write_config(pdn, PCI_COMMAND, 2, cmd);
> +
> + /* Enable report various errors */
> + if (edev->pcie_cap) {
> + eeh_ops->read_config(pdn, edev->pcie_cap + PCI_EXP_DEVCTL,
> + 2, &devctl);
> + devctl &= ~PCI_EXP_DEVCTL_CERE;
> + devctl |= (PCI_EXP_DEVCTL_NFERE |
> +PCI_EXP_DEVCTL_FERE |
> +PCI_EXP_DEVCTL_URRE);
> + eeh_ops->write_config(pdn, edev->pcie_cap + PCI_EXP_DEVCTL,
> + 2, devctl);
> + }
> +
> + /* Enable ECRC generation and check */
> + if (edev->pcie_cap && edev->aer_cap) {
> + eeh_ops->read_config(pdn, edev->aer_cap + PCI_ERR_CAP,
> + 4, &aer_capctl);
> + aer_capctl |= (PCI_ERR_CAP_ECRC_GENE | PCI_ERR_CAP_ECRC_CHKE);
> + eeh_ops->write_config(pdn, edev->aer_cap + PCI_ERR_CAP,
> + 4, aer_capctl);
> + }
Where is all this stuff set up the first time? It'd be nice if we could
use the same path that did it the first time.
Are we setting up a PF or a VF here? The function is called
pnv_eeh_restore_vf_config(), but it's called when "edev->physfn", so it's a
little confusing.
> +
> + return 0;
> +}
> +
> static int pnv_eeh_restore_config(struct pci_dn *pdn)
> {
> struct eeh_dev *edev = pdn_to_eeh_dev(pdn);
> @@ -1622,7 +1683,14 @@ static int pnv_eeh_restore_config(struct pci_dn *pdn)
> return -EEXIST;
>
> phb = edev->phb->private_data;
> - ret = opal_pci_reinit(phb->opal_id,
> + /*
> + * We have to restore the PCI config space after reset since the
> + * firmware can't see SRIOV VFs.
> + */
> + if (edev->physfn)
> + ret = pnv_eeh_restore_vf_config(pdn);
> + else
> + ret = opal_pci_reinit(phb->opal_id,
> OPAL_REINIT_PCI_DEV, edev->config_addr);
> if (ret) {
Re: [PATCH V7 06/10] powerpc/eeh: Create PE for VFs
On Tue, May 19, 2015 at 06:50:08PM +0800, Wei Yang wrote: > Current EEH recovery code works with the assumption: the PE has primary > bus. Unfortunately, that's not true to VF PEs, which generally contains "Primary bus" normally means the bus on the upstream side of a PCI bridge. But a PE is not a bridge, so I don't know what it means here. s/not true to VF PEs/not true for VF PEs/ > one or multiple VFs (for VF group case). The patch creates PEs for VFs > at PCI final fixup time. Those PEs for VFs are indentified with newly s/indentified/identified/ > introduced flag EEH_PE_VF so that we handle them differently during > EEH recovery. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 06/10] powerpc/eeh: Create PE for VFs
On Tue, May 19, 2015 at 06:50:08PM +0800, Wei Yang wrote:
> Current EEH recovery code works with the assumption: the PE has primary
> bus. Unfortunately, that's not true to VF PEs, which generally contains
> one or multiple VFs (for VF group case). The patch creates PEs for VFs
> at PCI final fixup time. Those PEs for VFs are indentified with newly
> introduced flag EEH_PE_VF so that we handle them differently during
> EEH recovery.
>
> [gwshan: changelog and code refactoring]
> Signed-off-by: Wei Yang
> Acked-by: Gavin Shan
> ---
> arch/powerpc/include/asm/eeh.h |1 +
> arch/powerpc/kernel/eeh_pe.c | 10 --
> arch/powerpc/platforms/powernv/eeh-powernv.c | 17 +
> 3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
> index 1b3614d..c1fde48 100644
> --- a/arch/powerpc/include/asm/eeh.h
> +++ b/arch/powerpc/include/asm/eeh.h
> @@ -70,6 +70,7 @@ struct pci_dn;
> #define EEH_PE_PHB (1 << 1)/* PHB PE*/
> #define EEH_PE_DEVICE(1 << 2)/* Device PE */
> #define EEH_PE_BUS (1 << 3)/* Bus PE*/
> +#define EEH_PE_VF(1 << 4)/* VF PE */
>
> #define EEH_PE_ISOLATED (1 << 0)/* Isolated PE
> */
> #define EEH_PE_RECOVERING(1 << 1)/* Recovering PE*/
> diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
> index 35f0b62..260a701 100644
> --- a/arch/powerpc/kernel/eeh_pe.c
> +++ b/arch/powerpc/kernel/eeh_pe.c
> @@ -299,7 +299,10 @@ static struct eeh_pe *eeh_pe_get_parent(struct eeh_dev
> *edev)
>* EEH device already having associated PE, but
>* the direct parent EEH device doesn't have yet.
>*/
> - pdn = pdn ? pdn->parent : NULL;
> + if (edev->physfn)
> + pdn = pci_get_pdn(edev->physfn);
> + else
> + pdn = pdn ? pdn->parent : NULL;
> while (pdn) {
> /* We're poking out of PCI territory */
> parent = pdn_to_eeh_dev(pdn);
> @@ -382,7 +385,10 @@ int eeh_add_to_parent_pe(struct eeh_dev *edev)
> }
>
> /* Create a new EEH PE */
> - pe = eeh_pe_alloc(edev->phb, EEH_PE_DEVICE);
> + if (edev->physfn)
> + pe = eeh_pe_alloc(edev->phb, EEH_PE_VF);
> + else
> + pe = eeh_pe_alloc(edev->phb, EEH_PE_DEVICE);
> if (!pe) {
> pr_err("%s: out of memory!\n", __func__);
> return -ENOMEM;
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
> b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index ce738ab..c505036 100644
> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -1520,6 +1520,23 @@ static struct eeh_ops pnv_eeh_ops = {
> .restore_config = pnv_eeh_restore_config
> };
>
> +static void pnv_eeh_vf_final_fixup(struct pci_dev *pdev)
> +{
> + struct pci_dn *pdn = pci_get_pdn(pdev);
> +
> + if (!pdev->is_virtfn)
> + return;
> +
> + /*
> + * The following operations will fail if VF's sysfs files
> + * aren't created or its resources aren't finalized.
> + */
I don't understand this comment. "The following operations" seems to refer
to eeh_add_device_early() and eeh_add_device_late(), and
"VF's sysfs files being created" seems to refer to eeh_sysfs_add_device().
So the comment suggests that eeh_add_device_early() and
eeh_add_device_late() will fail because they're called before
eeh_sysfs_add_device(). So I think you must be talking about some other
"following operations," not eeh_add_device_early() and
eeh_add_device_late().
> + eeh_add_device_early(pdn);
> + eeh_add_device_late(pdev);
> + eeh_sysfs_add_device(pdev);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, pnv_eeh_vf_final_fixup);
Ugh. This is powerpc code, but I don't like using fixups as a hook like
this. There is a pcibios_add_device() -- could this be done there?
If not, what happens after pcibios_add_device() that is required for this
code? Maybe we need a pcibios_bus_add_device() hook?
> +
> /**
> * eeh_powernv_init - Register platform dependent EEH operations
> *
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 04/10] powerpc/eeh: Trace first 7 BARs in address cache
The subject says "Trace first 7 BARs..." I think maybe you meant "Track
first 7 BARs" or maybe "Cache only BARs, not windows or IOV BARs"
On Tue, May 19, 2015 at 06:50:06PM +0800, Wei Yang wrote:
> EEH address cache, which helps to locate the PCI device according to
> the given (physical) MMIO address, didn't cover PCI bridges.
"doesn't contain PCI bridge windows"?
I see that eeh_addr_cache_insert_dev() ignores bridges because it never
calls __eeh_addr_cache_insert_dev() when "(dev->class >> 16) ==
PCI_BASE_CLASS_BRIDGE". I think it would be more technically correct if
you removed that test and relied on the "i <= PCI_ROM_RESOURCE" test in
this patch, because it is legal (though rare) for bridge devices to have
two BARs, and I assume you would want to put those in your cache if they
exist.
> Also, it
> shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
> should be returned.
> The patch restricts the address cache to cover first 7 BARs for the
> above purposes.
>
> [gwshan: changelog]
> Signed-off-by: Wei Yang
> Acked-by: Gavin Shan
> ---
> arch/powerpc/kernel/eeh_cache.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
> index eeabeab..f6c5f05 100644
> --- a/arch/powerpc/kernel/eeh_cache.c
> +++ b/arch/powerpc/kernel/eeh_cache.c
> @@ -196,7 +196,7 @@ static void __eeh_addr_cache_insert_dev(struct pci_dev
> *dev)
> }
>
> /* Walk resources on this device, poke them into the tree */
> - for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> + for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
> unsigned long start = pci_resource_start(dev,i);
> unsigned long end = pci_resource_end(dev,i);
> unsigned int flags = pci_resource_flags(dev,i);
> --
> 1.7.9.5
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V7 03/10] powerpc/pci: Remove VFs prior to PF
On Tue, May 19, 2015 at 06:50:05PM +0800, Wei Yang wrote:
> As commit ac205b7b ("PCI: make sriov work with hotplug remove") indicates,
The conventional reference is:
ac205b7bb72f ("PCI: make sriov work with hotplug remove")
> VFs, which might be hooked to same PCI bus as their PF should be removed
> before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
> cause kernel crash.
>
> The patch applies the above pattern to PowerPC PCI hotplug path.
>
> [gwshan: changelog]
> Signed-off-by: Wei Yang
> Acked-by: Gavin Shan
> ---
> arch/powerpc/kernel/pci-hotplug.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/pci-hotplug.c
> b/arch/powerpc/kernel/pci-hotplug.c
> index 7ed85a6..98f84ed 100644
> --- a/arch/powerpc/kernel/pci-hotplug.c
> +++ b/arch/powerpc/kernel/pci-hotplug.c
> @@ -50,7 +50,7 @@ void pcibios_remove_pci_devices(struct pci_bus *bus)
>
> pr_debug("PCI: Removing devices on bus %04x:%02x\n",
>pci_domain_nr(bus), bus->number);
> - list_for_each_entry_safe(dev, tmp, &bus->devices, bus_list) {
> + list_for_each_entry_safe_reverse(dev, tmp, &bus->devices, bus_list) {
> pr_debug(" Removing %s...\n", pci_name(dev));
> pci_stop_and_remove_bus_device(dev);
> }
> --
> 1.7.9.5
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/defconfig: new way of writing defconfig
On Mon, 2015-06-01 at 00:04 -0500, Pan Lijun-B44306 wrote: > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Wednesday, May 13, 2015 5:18 PM > > To: Pan Lijun-B44306 > > Cc: linuxppc-...@ozlabs.org > > Subject: Re: [PATCH v3] powerpc/defconfig: new way of writing > > defconfig > > > > On Mon, 2015-05-11 at 23:39 -0500, Lijun Pan wrote: > > > It is always a headache dealing with different defconfigs though > > > they > > > only differ in a few places. Hence we are proposing a new way of > > > writing the defconfig: > > > 1. Define a basic defconfig say mpc85xx_basic_defconfig 2. Spin > > > off as > > > much features as possible from the current mpc85xx_defconfig > > > and create a separate config file, say, smp.config, > > > kvm_500.config > > > Every time we add a new feature, we don't need to change several > > > defconfigs, we just add a new *.config And you could merge any > > > fragments you want into .config with the current kconfig in > > > Kernel. > > > > > > Say you want to build mpc85xx_smp_defconfig, you do 7 steps: > > > make mpc85xx_basic_defconfig > > > make 32bit.config > > > make smp.config > > > make cpu8.config > > > make kvm_e500.config > > > make uart2.config > > > make i2c.config > > > > > > With the new rules added into arch/powerpc/Makefile, you can do > > > it in > > > one step: > > > make mpc85xx_smp_defconfig > > > > We currently do it in one step. The 7 step version exists only in > > previous > > versions of this patch, and won't be in the git history, so such > > comments should > > go beneath the --- line. > > Sure, I will put them beneath --- line in the next patch. > > > > > > directory "scottwood" has my patch, > > > directory "scottwood" does not have my patch > > > > You shouldn't be working off of my repository unless it has > > patches (that you > > need or that would conflict) that haven't yet been merged upstream. > > I am working off an old commit. See the result from $"git log" > 17a0f33 powerpc/defconfig: new way of writing defconfig > d41444d powerpc/corenet: enable CONFIG_I2C_MUX and > CONFIG_I2C_MUX_PCA954x > 7f9af0a powerpc/t2080qds: fix rtc interrupt > 56302c5 powerpc/mpic: Remove WHOAMI readback after EOI Don't do that. [ b44306@b44306-12scottwood]$ ./scripts/diffconfig > > > ../scottwood2/.config .config EPAPR_PARAVIRT n -> y KVM_GUEST n > > > -> y > > > PPC_QEMU_E500 n -> y > > > // these changes are expected since mpc85xx_smp_defconfig has > > > enabled > > kvm_e500.config in freescale's internal git repo. > > > > > What does our internal git repo have to do with anything? > > I will take off kvm_e500.config if upstream defconfig does have > these. > I will add kvm_e500.config later. You didn't answer my question. > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index > > > fc502e0..7c80298 100644 > > > --- a/arch/powerpc/Makefile > > > +++ b/arch/powerpc/Makefile > > > @@ -269,6 +269,52 @@ bootwrapper_install: > > > %.dtb: scripts > > > $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) > > $(patsubst %,$(boot)/%,$@) > > > > > > +configfiles=$(wildcard $(srctree)/kernel/configs/$(1).config > > > +$(srctree)/arch/$(SRCARCH)/configs/$(1).config) > > > + > > > +define mergeconfig > > > +$(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh - > > > m -O > > > +$(objtree)/arch/$(SRCARCH)/configs > > > +$(objtree)/arch/$(SRCARCH)/configs/.config $(call > > > configfiles,$(1)) > > > +endef > > > > Why not invoke make with the .config target instead? > > I first merge (no any make) all the config fragments into one, then > make it. Do you mean for the reason described in http://patchwork.ozlabs.org/patch/476345/ ? You should probably base these changes on top of that patch. > This is a way to make sure the .config after this patch the same as > .config before this patch. In the general case that's not a reasonable goal, unless you remove the gratuitous inconsistencies from the configs first (which would be a good thing). > > > +mpc85xx_defconfig: > > > + $(Q)cp > > > $(srctree)/arch/$(SRCARCH)/configs/mpc85xx_basic_defconfig > > > +$(srctree)/arch/$(SRCARCH)/configs/.config > > > > Don't modify $(srctree), ever. Why not just depend on the > > mpc85xx_basic_defconfig target? > > > > > + $(call mergeconfig,32-bit) > > > + $(call mergeconfig,uart6) > > > + $(call mergeconfig,mpc85xx_misc) > > > + $(Q)mv $(objtree)/arch/$(SRCARCH)/configs/.config > > $(objtree)/arch/$(SRCARCH)/configs/mpc85xx_tmp_defconfig > > > + $(Q)$(MAKE) -f $(srctree)/Makefile mpc85xx_tmp_defconfig > > > + > > > +mpc85xx_smp_defconfig: > > > + $(Q)cp > > > $(srctree)/arch/$(SRCARCH)/configs/mpc85xx_basic_defconfig > > $(srctree)/arch/$(SRCARCH)/configs/.config > > > + $(call mergeconfig,32-bit) > > > + $(call mergeconfig,smp) > > > + $(call mergeconfig,cpu8) > > > + $(call mergeconfig,kvm_e500) > > > + $(call mergeconfig,uart2) > > > + $(call mergeconfig,i2c) > > > + $(Q)mv $(objtree)/arch/$(SRCARCH)/configs
Re: [RESEND PATCH 0/3] Allow user to request memory to be locked on page fault
On Fri, 29 May 2015 10:13:25 -0400 Eric B Munson wrote: > mlock() allows a user to control page out of program memory, but this > comes at the cost of faulting in the entire mapping when it is > allocated. For large mappings where the entire area is not necessary > this is not ideal. > > This series introduces new flags for mmap() and mlockall() that allow a > user to specify that the covered are should not be paged out, but only > after the memory has been used the first time. I almost applied these, but the naming issue (below) stopped me. A few things... - The 0/n changelog should reveal how MAP_LOCKONFAULT interacts with rlimit(RLIMIT_MEMLOCK). I see the implementation is "as if the entire mapping will be faulted in" (for mmap) and "as if it was MCL_FUTURE" (for mlockall) which seems fine. Please include changelog text explaining and justifying these decisions. This stuff will need to be in the manpage updates as well. - I think I already asked "why not just use MCL_FUTURE" but I forget the answer ;) In general it is a good idea to update changelogs in response to reviewer questions, because other people will be wondering the same things. Or maybe I forgot to ask. Either way, please address this in the changelogs. - I can perhaps see the point in mmap(MAP_LOCKONFAULT) (other mappings don't get lock-in-memory treatment), but what's the benefit in mlockall(MCL_ON_FAULT) over MCL_FUTURE? (Add to changelog also, please). - Is there a manpage update? - Can we rename patch 1/3 from "add flag to ..." to "add mmap flag to ...", to distinguish from 2/3 "add mlockall flag ..."? - The MAP_LOCKONFAULT versus MCL_ON_FAULT inconsistency is irritating! Can we get these consistent please: switch to either MAP_LOCK_ON_FAULT or MCL_ONFAULT. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4] QE: Move QE from arch/powerpc to drivers/soc
On Sun, 2015-05-31 at 23:09 -0500, Zhao Qiang-B45475 wrote: > On Fri, Jan 30, 2015 at 1:22PM +0800, Wood Scott wrote: > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Friday, January 30, 2015 1:22 PM > > To: Zhao Qiang-B45475 > > Cc: linux-ker...@vger.kernel.org; net...@vger.kernel.org; linuxppc- > > d...@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061 > > Subject: Re: [v4] QE: Move QE from arch/powerpc to drivers/soc > > > > On Wed, Nov 12, 2014 at 11:40:13AM +0800, Zhao Qiang wrote: > > > ls1 has qe and ls1 has arm cpu. > > > move qe from arch/powerpc to drivers/soc/fsl to adapt to powerpc > > > and > > > arm > > > > > > Signed-off-by: Zhao Qiang > > > --- > > > Changes for v2: > > > - move code to driver/soc > > > Changes for v3: > > > - change drivers/soc/qe to drivers/soc/fsl-qe Changes for v4: > > > - move drivers/soc/fsl-qe to drivers/soc/fsl/qe > > > - move head files for qe from include/linux/fsl to > > > include/soc/fsl > > > - move qe_ic.c to drivers/irqchip/ > > > > Need MAINTAINERS update for drivers/soc/fsl/qe, as previously > > discussed. > > You mean, I need to finish the following work before move qe to > public directory? > > 1. gpio.c -> needs to be converted to GPIO framework and placed in > drivers/gpio > 2. qe_ic* should probably move into drivers/irqchip > 3. qe_io.c should be converted over to pinmux and put in > drivers/pinctrl > 4. Some of the clock could should be looked to be converted to use > the clk framework Those would be nice but at the very least: 1. Don't introduce code into the toplevel /lib that duplicates existing functionality, and 2. Add a MAINTAINERS entry as described above -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/4,v3] powerpc/fsl-booke: Add T1024 QDS board support
On Mon, 2015-06-01 at 03:23 -0500, Liu Shengzhou-B36685 wrote:
> > Subject: Re: [2/4,v3] powerpc/fsl-booke: Add T1024 QDS board
> > support
> >
> > On Thu, Apr 09, 2015 at 04:07:43PM +0800, Shengzhou Liu wrote:
> > > + flash@2{
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + compatible = "eon,en25s64"; /* 8MB */
> > > + reg = <2>;
> > > + spi-max-frequency = <1000>;
> > > + };
> >
> > AFAICT the vendor is phyton, not eon.
>
> How do you think the vendor is phyton?
> Per en25s64 data sheet, it's really EON (Eon Silicon Solution, Inc,
> www.eonssi.com)
I'm not sure. The search results for it look a bit different from
what I remember seeing last week. I'll fix it.
> I had sent a patch for EON http://patchwork.ozlabs.org/patch/367810/
> last year.
> There is no 'phyton' in binding document.
There is no binding document. As for vendor-prefixes, you should ping
to get that patch merged -- and when you're depending on an unmerged
patch (even if just documentation), please mention it below the ---
line when submitting.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[v2] powerpc/fsl: Add FMan Port 10G compatibles
From: Igal Liberman
This patch adds two boolean properties to FMan Port.
FMan has 3 types of ports:
- 1G ports
By default, all ports support 1G rate
- 10G Ports
Port which use 10G hardware, and configured as 10G
- 10G Best effort ports
Ports which use 1G hardware, configured as 10G, in this case,
the rate is not guaranteed.
The new properties help to distinguish the different type of ports.
v2 - Addressed feedback from Scott:
Replaced "10G-support" with "fsl,fman-10g-port"
Replaced "best-effort-port" with "fsl,fman-best-effort-port"
Signed-off-by: Igal Liberman
Change-Id: If1ac160fbedc0cfd058f46ae8d8e3a50d3ecebb2
---
.../devicetree/bindings/powerpc/fsl/fman.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
index edda55f..1fc5328 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -189,6 +189,19 @@ PROPERTIES
Definition: There is one reg region describing the port
configuration registers.
+- fsl,fman-10g-port
+ Usage: optional
+ Value type: boolean
+ Definition: The default port rate is 1G.
+ If this property exists, the port is s 10G port.
+
+- fsl,fman-best-effort-port
+ Usage: optional
+ Value type: boolean
+ Definition: Can be defined only if 10G-support is set.
+ This property marks a best-effort 10G port (10G port that
+ may not be capable of line rate).
+
EXAMPLE
port@a8000 {
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Set up and enable PSL Timebase
Michael Neuling wrote: > Please use negative error codes here. -EIO? > And check it here. Mikey, I am reluctant to fail the entire CAPI init after a PSL timebase sync failure. If we ignore the error, the CAPI device stays available (without timebase sync). If we honour the error, the CAPI device fails entirely. I know three reasons why PSL timebase sync can fail: 1. h/w failure 2. OPAL did not initialize the CAPP timebase (wrong OPAL version) 3. the PCIe bus was not powered off/on between shutdown and reboot I think that it is premature to choose to fail the entire CAPI init in all cases. In particular, point 3. introduces a regression, as PCIe off/on was never a requirement for booting CAPI on P8. I have tried one workaround do far: forcing the 0 to 1 transition of the tb bit of the PSL register TB_CTLSTAT. In vain. What do you think? Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 23/25] cputime:Introduce the cputime_to_timespec64/timespec64_to_cputime function
This patch introduces some functions for converting cputime to timespec64
and back, that repalce the timespec type with timespec64 type, as well as
for arch/s390 and arch/powerpc architecture.
And these new methods will replace the old
cputime_to_timespec/timespec_to_cputime
function to ready for 2038 issue. The cputime_to_timespec/timespec_to_cputime
functions are moved to include/linux/cputime.h file for removing conveniently.
Signed-off-by: Baolin Wang
---
arch/powerpc/include/asm/cputime.h|6 +++---
arch/s390/include/asm/cputime.h |8
include/asm-generic/cputime_jiffies.h | 10 +-
include/asm-generic/cputime_nsecs.h |4 ++--
include/linux/cputime.h | 16
5 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index e245255..5dda5c0 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -154,9 +154,9 @@ static inline cputime_t secs_to_cputime(const unsigned long
sec)
}
/*
- * Convert cputime <-> timespec
+ * Convert cputime <-> timespec64
*/
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64
*p)
{
u64 x = (__force u64) ct;
unsigned int frac;
@@ -168,7 +168,7 @@ static inline void cputime_to_timespec(const cputime_t ct,
struct timespec *p)
p->tv_nsec = x;
}
-static inline cputime_t timespec_to_cputime(const struct timespec *p)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *p)
{
u64 ct;
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index b91e960..1266697 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -89,16 +89,16 @@ static inline cputime_t secs_to_cputime(const unsigned int
s)
}
/*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
*/
-static inline cputime_t timespec_to_cputime(const struct timespec *value)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *value)
{
unsigned long long ret = value->tv_sec * CPUTIME_PER_SEC;
return (__force cputime_t)(ret + __div(value->tv_nsec *
CPUTIME_PER_USEC, NSEC_PER_USEC));
}
-static inline void cputime_to_timespec(const cputime_t cputime,
- struct timespec *value)
+static inline void cputime_to_timespec64(const cputime_t cputime,
+ struct timespec64 *value)
{
unsigned long long __cputime = (__force unsigned long long) cputime;
#ifndef CONFIG_64BIT
diff --git a/include/asm-generic/cputime_jiffies.h
b/include/asm-generic/cputime_jiffies.h
index fe386fc..54e034c 100644
--- a/include/asm-generic/cputime_jiffies.h
+++ b/include/asm-generic/cputime_jiffies.h
@@ -44,12 +44,12 @@ typedef u64 __nocast cputime64_t;
#define secs_to_cputime(sec) jiffies_to_cputime((sec) * HZ)
/*
- * Convert cputime to timespec and back.
+ * Convert cputime to timespec64 and back.
*/
-#define timespec_to_cputime(__val) \
- jiffies_to_cputime(timespec_to_jiffies(__val))
-#define cputime_to_timespec(__ct,__val)\
- jiffies_to_timespec(cputime_to_jiffies(__ct),__val)
+#define timespec64_to_cputime(__val) \
+ jiffies_to_cputime(timespec64_to_jiffies(__val))
+#define cputime_to_timespec64(__ct,__val) \
+ jiffies_to_timespec64(cputime_to_jiffies(__ct),__val)
/*
* Convert cputime to timeval and back.
diff --git a/include/asm-generic/cputime_nsecs.h
b/include/asm-generic/cputime_nsecs.h
index 0419485..65c875b 100644
--- a/include/asm-generic/cputime_nsecs.h
+++ b/include/asm-generic/cputime_nsecs.h
@@ -73,12 +73,12 @@ typedef u64 __nocast cputime64_t;
/*
* Convert cputime <-> timespec (nsec)
*/
-static inline cputime_t timespec_to_cputime(const struct timespec *val)
+static inline cputime_t timespec64_to_cputime(const struct timespec64 *val)
{
u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_nsec;
return (__force cputime_t) ret;
}
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec
*val)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64
*val)
{
u32 rem;
diff --git a/include/linux/cputime.h b/include/linux/cputime.h
index f2eb2ee..e4c88da 100644
--- a/include/linux/cputime.h
+++ b/include/linux/cputime.h
@@ -13,4 +13,20 @@
usecs_to_cputime((__nsecs) / NSEC_PER_USEC)
#endif
+static inline cputime_t timespec_to_cputime(const struct timespec *ts)
+{
+ struct timespec64 ts64 = timespec_to_timespec64(*ts);
+
+ return timespec64_to_cputime(&ts64);
+}
+
+static inline void cputime_to_timespec(const cputime_t cputime,
+ struct timespec *value)
+{
+ struct timespec64 ts64;
+
+ cp
[PATCH v4 00/25] Convert the posix_clock_operations and k_clock structure to ready for 2038
This patch series changes the 32-bit time types (timespec/itimerspec) to
the 64-bit types (timespec64/itimerspec64), since 32-bit time types will
break in the year 2038.
This patch series introduces new methods with timespec64/itimerspec64 type,
and removes the old ones with timespec/itimerspec type for
posix_clock_operations
and k_clock structure.
Baolin Wang (25):
time:Introduce struct itimerspec64
timekeeping:Introduce the current_kernel_time64()
hrtimer:Introduce hrtimer_get_res64()
security: Introduce security_settime64()
time:Introduce the do_sys_settimeofday64()
posix-timers:Introduce {get,put}_timespec/{get,put}_itimerspec
posix-timers: Split up timer_gettime()/timer_settime()/clock_settime()/
clock_gettime()/clock_getres().
posix-timers: Convert timer_gettime()/timer_settime()/clock_settime()/
clock_gettime()/clock_getres() to timespec64/itimerspec64.
mmtimer:Convert to timespec64/itimerspec64
alarmtimer:Convert to timespec64/itimerspec64
posix-clock:Convert to timespec64/itimerspec64
time:Introduce timespec64_to_jiffies()/jiffies_to_timespec64()
cputime:Introduce cputime_to_timespec64()/timespec64_to_cputime()
posix-cpu-timers:Convert to timespec64/itimerspec64
k_clock:Remove timespec/itimerspec
arch/powerpc/include/asm/cputime.h|6 +-
arch/s390/include/asm/cputime.h |8 +-
drivers/char/mmtimer.c| 36 +++--
drivers/ptp/ptp_clock.c | 26 +---
include/asm-generic/cputime_jiffies.h | 10 +-
include/asm-generic/cputime_nsecs.h |4 +-
include/linux/cputime.h | 16 ++
include/linux/hrtimer.h | 16 +-
include/linux/jiffies.h | 21 ++-
include/linux/posix-clock.h | 10 +-
include/linux/posix-timers.h | 18 +--
include/linux/security.h | 25 +++-
include/linux/time64.h| 35 +
include/linux/timekeeping.h | 26 +++-
kernel/time/alarmtimer.c | 43 +++---
kernel/time/hrtimer.c | 10 +-
kernel/time/posix-clock.c | 20 +--
kernel/time/posix-cpu-timers.c| 84 ++-
kernel/time/posix-timers.c| 259 +
kernel/time/time.c| 20 +--
kernel/time/timekeeping.c |6 +-
kernel/time/timekeeping.h |1 -
security/commoncap.c |2 +-
security/security.c |2 +-
24 files changed, 437 insertions(+), 267 deletions(-)
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/pseries: Ratelimit EPOW event warnings
On Thu, 2015-05-28 at 10:03 +0530, Kamalesh Babulal wrote:
> We print the respective warning after parsing EPOW interrupts,
> prompting user to take action depending upon the severity of the
> event.
>
> Some times same EPOW event warning, such as below could flood kernel
> log, within very short duration. So Limit the message by using
> ratelimit variant of pr_err.
>
> May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
> May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
> May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
> May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
> May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
> May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
> May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
> May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
> May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
> May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
> May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
> May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
> May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
Looking at the time stamps those are actually all fairly far apart in time,
aren't they? So do we actually see them within a short duration in practice?
It does seem sensible to rate limit them though.
> diff --git a/arch/powerpc/platforms/pseries/ras.c
> b/arch/powerpc/platforms/pseries/ras.c
> index 02e4a17..2556bc2 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -145,17 +145,17 @@ static void rtas_parse_epow_errlog(struct
> rtas_error_log *log)
>
> switch (action_code) {
> case EPOW_RESET:
> - pr_err("Non critical power or cooling issue cleared");
> + pr_err_ratelimited("Non critical power or cooling issue
> cleared");
> break;
>
> case EPOW_WARN_COOLING:
> - pr_err("Non critical cooling issue reported by firmware");
> - pr_err("Check RTAS error log for details");
> + pr_err_ratelimited("Non critical cooling issue reported by
> firmware");
> + pr_err_ratelimited("Check RTAS error log for details");
> break;
>
> case EPOW_WARN_POWER:
> - pr_err("Non critical power issue reported by firmware");
> - pr_err("Check RTAS error log for details");
> + pr_err_ratelimited("Non critical power issue reported by
> firmware");
> + pr_err_ratelimited("Check RTAS error log for details");
> break;
Those last two could be collapsed onto one line which would reduce the spam.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Fix build break with STRICT_MM_TYPECHECKS && DEBUG_PAGEALLOC
If both STRICT_MM_TYPECHECKS and DEBUG_PAGEALLOC are enabled, the code in kernel_map_linear_page() is built, and so we fail with: arch/powerpc/mm/hash_utils_64.c:1478:2: error: incompatible type for argument 1 of 'htab_convert_pte_flags' Fix it by using pgprot_val(). Reported-by: Geert Uytterhoeven Signed-off-by: Michael Ellerman --- arch/powerpc/mm/hash_utils_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index fda236f908eb..a04ca922f0db 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1475,7 +1475,7 @@ static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi) unsigned long hash; unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize); unsigned long vpn = hpt_vpn(vaddr, vsid, mmu_kernel_ssize); - unsigned long mode = htab_convert_pte_flags(PAGE_KERNEL); + unsigned long mode = htab_convert_pte_flags(pgprot_val(PAGE_KERNEL)); long ret; hash = hpt_hash(vpn, PAGE_SHIFT, mmu_kernel_ssize); -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc/configs: enable RTC class support
A working rtc kernel driver is needed so that hwclock can synchronize system clock to rtc during shutdown/boot. We already have a rtc platform driver for power arch located at drivers/rtc/rtc-opal.c However it depends on CONFIG_RTC_CLASS which is disabled by default. So this driver is not compiled with pseries defconfig as rtc class support is missing from the kernel. We fix this by enabling rtc class support in pseries defconfig so that this driver gets enabled and is compiled into the pseries kernel. Signed-off-by: Vaibhav Jain Cc: Cyril Bur --- This patch depends on an earlier patchset by Cyril Bur to merge pseries 'le' and 'be' defconfigs. The patchs are located at http://patchwork.ozlabs.org/patch/476346/ http://patchwork.ozlabs.org/patch/476345/ arch/powerpc/configs/pseries_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 4da8260..e55e7c8 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -189,6 +189,7 @@ CONFIG_HVC_RTAS=y CONFIG_HVCS=m CONFIG_VIRTIO_CONSOLE=m CONFIG_IBM_BSR=m +CONFIG_RTC_CLASS=y CONFIG_GEN_RTC=y CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=1024 -- 2.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/perf: Fix book3s kernel to userspace backtraces
From: Anton Blanchard
When we take a PMU exception or a software event we call
perf_read_regs(). This overloads regs->result with a boolean that
describes if we should use the sampled instruction address register
(SIAR) or the regs.
If the exception is in kernel, we start with the kernel regs and
backtrace through the kernel stack. At this point we switch to the
userspace regs and backtrace the user stack with perf_callchain_user().
Unfortunately these regs have not got the perf_read_regs() treatment,
so regs->result could be anything. If it is non zero,
perf_instruction_pointer() decides to use the SIAR, and we get issues
like this:
0.11% qemu-system-ppc [kernel.kallsyms][k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--52.35%-- 0
| |
| |--46.39%-- __hrtimer_start_range_ns
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | |
| | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
| | | |
| | | --100.00%-- 0x7e714
| | | 0x7e714
Notice the bogus _raw_spin_irqsave when we transition from kernel
(system_call) to userspace (0x7e714). We inserted what was in the SIAR.
Add a check in regs_use_siar() to check that the regs in question
are from a PMU exception. With this fix the backtrace makes sense:
0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--53.83%-- 0
| |
| |--44.73%-- hrtimer_try_to_cancel
| | kvmppc_start_thread
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | __ioctl
| | 0x7e714
| | 0x7e714
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
---
v2: Return the result directly rather than if (x) return true.
Add a big comment.
Cc to stable.
arch/powerpc/perf/core-book3s.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 12b638425bb9..d90893b76e7c 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -131,7 +131,16 @@ static void pmao_restore_workaround(bool ebb) { }
static bool regs_use_siar(struct pt_regs *regs)
{
- return !!regs->result;
+ /*
+* When we take a performance monitor exception the regs are setup
+* using perf_read_regs() which overloads some fields, in particular
+* regs->result to tell us whether to use SIAR.
+*
+* However if the regs are from another exception, eg. a syscall, then
+* they have not been setup using perf_read_regs() and so regs->result
+* is something random.
+*/
+ return ((TRAP(regs) == 0xf00) && regs->result);
}
/*
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v4.1-rc6
On Mon, Jun 1, 2015 at 12:09 PM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.1-rc6[1] to v4.1-rc5[3], the summaries are:
> - build errors: +8/-52
+ /home/kisskb/slave/src/drivers/media/i2c/ov2659.c: error: 'struct
v4l2_subdev_fh' has no member named 'pad': => 1264:38
+ /home/kisskb/slave/src/drivers/media/i2c/ov2659.c: error: implicit
declaration of function 'v4l2_subdev_get_try_format'
[-Werror=implicit-function-declaration]: => 1054:3
i386-randconfig
+ error: aes.c: undefined reference to `.enable_kernel_altivec': =>
.text+0x48e894), .text+0x48e6e0), .text+0x48e960)
+ error: aes_cbc.c: undefined reference to `.enable_kernel_altivec':
=> .text+0x48ea98), .text+0x48ebf4)
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/8943/ (254 out of 257 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/8914/ (254 out of 257 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/10] perf, tools: Handle header line in mapfile
On Fri, May 29, 2015 at 10:49:27PM -0700, Andi Kleen wrote: > On Fri, May 29, 2015 at 11:13:15AM +0200, Jiri Olsa wrote: > > On Thu, May 28, 2015 at 10:45:06PM -0700, Sukadev Bhattiprolu wrote: > > > Jiri Olsa [jo...@redhat.com] wrote: > > > | > if (line[0] == '#' || line[0] == '\n') > > > | > continue; > > > | > + if (!strncmp(line, "Family", 6)) > > > | > + continue; > > > | > > > | I think we should fix mapfiles to put the 'Family' starting > > > | line as a comment.. the way powerpc mapfile is done > > > > > > You mean add something like this to the Intel mapfile: > > > > > > # Power8 entries > > > 004d0100,1,power8.json,core > > > > > > and drop this patch? > > > > right > > But it's a CSV file. CSV files are supposed to have column headers. > There are lots of tools that work better with them if they have headers. header could be behind '#' > Please keep the header. hum, do all arch start with 'Family' column? I guess not, so eventualy we will need to add first column of each arch in here? ending up with list of 'keywords' which we ignore or let's just ignore first line? I'd rather go with just one comment char and place the header behind it jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] selftests/powerpc: Add install support to more powerpc tests
These tests were merged in parallel to the install support, update them now to use it. This also adds cross compile support for the VPHN test which was missing it. Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/switch_endian/Makefile | 14 -- tools/testing/selftests/powerpc/vphn/Makefile | 13 + 2 files changed, 9 insertions(+), 18 deletions(-) diff --git a/tools/testing/selftests/powerpc/switch_endian/Makefile b/tools/testing/selftests/powerpc/switch_endian/Makefile index 081473db22b7..e21d10674e54 100644 --- a/tools/testing/selftests/powerpc/switch_endian/Makefile +++ b/tools/testing/selftests/powerpc/switch_endian/Makefile @@ -1,9 +1,8 @@ -CC := $(CROSS_COMPILE)gcc -PROGS := switch_endian_test +TEST_PROGS := switch_endian_test ASFLAGS += -O2 -Wall -g -nostdlib -m64 -all: $(PROGS) +all: $(TEST_PROGS) switch_endian_test: check-reversed.S @@ -13,12 +12,7 @@ check-reversed.o: check.o check-reversed.S: check-reversed.o hexdump -v -e '/1 ".byte 0x%02X\n"' $< > $@ -run_tests: all - @-for PROG in $(PROGS); do \ - ./$$PROG; \ - done; +include ../../lib.mk clean: - rm -f $(PROGS) *.o check-reversed.S - -.PHONY: all run_tests clean + rm -f $(TEST_PROGS) *.o check-reversed.S diff --git a/tools/testing/selftests/powerpc/vphn/Makefile b/tools/testing/selftests/powerpc/vphn/Makefile index e539f775fd8f..a485f2e286ae 100644 --- a/tools/testing/selftests/powerpc/vphn/Makefile +++ b/tools/testing/selftests/powerpc/vphn/Makefile @@ -1,15 +1,12 @@ -PROG := test-vphn +TEST_PROGS := test-vphn CFLAGS += -m64 -all: $(PROG) +all: $(TEST_PROGS) -$(PROG): ../harness.c +$(TEST_PROGS): ../harness.c -run_tests: all - ./$(PROG) +include ../../lib.mk clean: - rm -f $(PROG) - -.PHONY: all run_tests clean + rm -f $(TEST_PROGS) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Set up and enable PSL Timebase
Michael Neuling wrote:
On Mon, 2015-06-01 at 09:37 +0200, Philippe Bergheaud wrote:
Michael Neuling wrote:
On Thu, 2015-05-28 at 15:12 +0200, Philippe Bergheaud wrote:
This patch configures the PSL Timebase function and enables it,
after the CAPP has been initialized by OPAL. Failures are reported
and ignored.
Needs an Signed-off-by.
Yes.
Comments inline.
---
drivers/misc/cxl/cxl.h |5 +
drivers/misc/cxl/pci.c | 35 +++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index a1cee47..38a7cf9 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -82,8 +82,10 @@ static const cxl_p1_reg_t CXL_PSL_AFUSEL = {0x00B0};
/* 0x00C0:7EFF Implementation dependent area */
static const cxl_p1_reg_t CXL_PSL_FIR1 = {0x0100};
static const cxl_p1_reg_t CXL_PSL_FIR2 = {0x0108};
+static const cxl_p1_reg_t CXL_PSL_Timebase = {0x0110};
static const cxl_p1_reg_t CXL_PSL_VERSION = {0x0118};
static const cxl_p1_reg_t CXL_PSL_RESLCKTO = {0x0128};
+static const cxl_p1_reg_t CXL_PSL_TB_CTLSTAT = {0x0140};
static const cxl_p1_reg_t CXL_PSL_FIR_CNTL = {0x0148};
static const cxl_p1_reg_t CXL_PSL_DSNDCTL = {0x0150};
static const cxl_p1_reg_t CXL_PSL_SNWRALLOC = {0x0158};
@@ -151,6 +153,9 @@ static const cxl_p2n_reg_t CXL_PSL_WED_An = {0x0A0};
#define CXL_PSL_SPAP_Size_Shift 4
#define CXL_PSL_SPAP_V0x0001ULL
+/** CXL_PSL_Control /
+#define CXL_PSL_Control_tb 0x0001ULL
+
/** CXL_PSL_DLCNTL */
#define CXL_PSL_DLCNTL_D (0x1ull << (63-28))
#define CXL_PSL_DLCNTL_C (0x1ull << (63-29))
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index fc938de..afd89cc 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -360,6 +360,38 @@ static int init_implementation_adapter_regs(struct cxl
*adapter, struct pci_dev
return 0;
}
+#define TBSYNC_CNT(n) (((u64)n & 0x7) << (63-6))
+
+static int cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
+{
+ u64 psl_tb;
+ int delta;
+ unsigned int retry = 0;
+
+ /*
+* Setup PSL Timebase Control and Status register
+* with the recommended Timebase Sync Count value
+*/
+ cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2));
2?
Quoting the PSL workbook description of the PSL_TB_CTLSTAT register:
4:6 tbsync_cnt
TimebaseSyncCount. Number of 250MHz cycles x 2048 before initiating another
Timebase Recalibration sequence.
Processor chipTimebase facilities receive a tod_sync pulse every 16us or 4000
250 MHz cycles so '010' is the Recommended value.
000 = never
001 = 2048
010 = 4096 (2 * 2048)
...
111 = 14336 (7 * 2048)
Will make the TimebaseSyncCount unit explicit. Something like:
#define _2048_250MHZ_CYCLES 1
cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2 * _2048_250MHZ_CYCLES));
Sounds good!
+
+ /* Enable PSL Timebase */
+ cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
+ /* Wait until CORE TB and PSL TB difference <= 16usecs */
How many tries does this normally take?
Two. The second attempt always succeds.
Ok
Should we have a sleep in here to wait for it to sync rather than just
coming back around right away?
Yes, will add msleep(1) at the beginning of the loop (as the first attempt
always fails).
Humm, ok. Is there any documentation to say how long it's suppose to
take?
Could not find any.
With msleep(1) at the beginning if the loop, the first attempt always succeeds,
as far as I can see.
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Set up and enable PSL Timebase
On Mon, 2015-06-01 at 09:37 +0200, Philippe Bergheaud wrote:
> Michael Neuling wrote:
> > On Thu, 2015-05-28 at 15:12 +0200, Philippe Bergheaud wrote:
> >
> >>This patch configures the PSL Timebase function and enables it,
> >>after the CAPP has been initialized by OPAL. Failures are reported
> >>and ignored.
> >
> >
> > Needs an Signed-off-by.
> Yes.
> > Comments inline.
> >
> >
> >>---
> >> drivers/misc/cxl/cxl.h |5 +
> >> drivers/misc/cxl/pci.c | 35 +++
> >> 2 files changed, 40 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> >>index a1cee47..38a7cf9 100644
> >>--- a/drivers/misc/cxl/cxl.h
> >>+++ b/drivers/misc/cxl/cxl.h
> >>@@ -82,8 +82,10 @@ static const cxl_p1_reg_t CXL_PSL_AFUSEL = {0x00B0};
> >> /* 0x00C0:7EFF Implementation dependent area */
> >> static const cxl_p1_reg_t CXL_PSL_FIR1 = {0x0100};
> >> static const cxl_p1_reg_t CXL_PSL_FIR2 = {0x0108};
> >>+static const cxl_p1_reg_t CXL_PSL_Timebase = {0x0110};
> >> static const cxl_p1_reg_t CXL_PSL_VERSION = {0x0118};
> >> static const cxl_p1_reg_t CXL_PSL_RESLCKTO = {0x0128};
> >>+static const cxl_p1_reg_t CXL_PSL_TB_CTLSTAT = {0x0140};
> >> static const cxl_p1_reg_t CXL_PSL_FIR_CNTL = {0x0148};
> >> static const cxl_p1_reg_t CXL_PSL_DSNDCTL = {0x0150};
> >> static const cxl_p1_reg_t CXL_PSL_SNWRALLOC = {0x0158};
> >>@@ -151,6 +153,9 @@ static const cxl_p2n_reg_t CXL_PSL_WED_An = {0x0A0};
> >> #define CXL_PSL_SPAP_Size_Shift 4
> >> #define CXL_PSL_SPAP_V0x0001ULL
> >>
> >>+/** CXL_PSL_Control
> >>/
> >>+#define CXL_PSL_Control_tb 0x0001ULL
> >>+
> >> /** CXL_PSL_DLCNTL
> >> */
> >> #define CXL_PSL_DLCNTL_D (0x1ull << (63-28))
> >> #define CXL_PSL_DLCNTL_C (0x1ull << (63-29))
> >>diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> >>index fc938de..afd89cc 100644
> >>--- a/drivers/misc/cxl/pci.c
> >>+++ b/drivers/misc/cxl/pci.c
> >>@@ -360,6 +360,38 @@ static int init_implementation_adapter_regs(struct cxl
> >>*adapter, struct pci_dev
> >>return 0;
> >> }
> >>
> >>+#define TBSYNC_CNT(n) (((u64)n & 0x7) << (63-6))
> >>+
> >>+static int cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
> >>+{
> >>+ u64 psl_tb;
> >>+ int delta;
> >>+ unsigned int retry = 0;
> >>+
> >>+ /*
> >>+* Setup PSL Timebase Control and Status register
> >>+* with the recommended Timebase Sync Count value
> >>+*/
> >>+ cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2));
> >
> >
> > 2?
> Quoting the PSL workbook description of the PSL_TB_CTLSTAT register:
>
> 4:6 tbsync_cnt
> TimebaseSyncCount. Number of 250MHz cycles x 2048 before initiating another
> Timebase Recalibration sequence.
> Processor chipTimebase facilities receive a tod_sync pulse every 16us or 4000
> 250 MHz cycles so '010' is the Recommended value.
> 000 = never
> 001 = 2048
> 010 = 4096 (2 * 2048)
> ...
> 111 = 14336 (7 * 2048)
>
> Will make the TimebaseSyncCount unit explicit. Something like:
>
> #define _2048_250MHZ_CYCLES 1
> cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2 *
> _2048_250MHZ_CYCLES));
Sounds good!
> >
> >>+
> >>+ /* Enable PSL Timebase */
> >>+ cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
> >>+ /* Wait until CORE TB and PSL TB difference <= 16usecs */
> >
> >
> > How many tries does this normally take?
> Two. The second attempt always succeds.
Ok
> > Should we have a sleep in here to wait for it to sync rather than just
> > coming back around right away?
> Yes, will add msleep(1) at the beginning of the loop (as the first attempt
> always fails).
Humm, ok. Is there any documentation to say how long it's suppose to
take?
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.
Hi Aisheng, On Wed, May 27, 2015 at 7:46 PM, Suman Tripathi wrote: > > > On Tue, May 26, 2015 at 6:06 PM, Ulf Hansson > wrote: > >> On 21 May 2015 at 10:43, Suman Tripathi wrote: >> > The sdhci framework disables SDR104/SDR50/DDR50 based on only quirk. >> > This patch adds the support to disable SDR104/SDR50/DDR50 based on >> > reading the capability register 0. >> > >> > Signed-off-by: Suman Tripathi >> > --- >> > --- >> > drivers/mmc/host/sdhci.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c >> > index 58c1770..a3d9b8a 100644 >> > --- a/drivers/mmc/host/sdhci.c >> > +++ b/drivers/mmc/host/sdhci.c >> > @@ -3118,7 +3118,8 @@ int sdhci_add_host(struct sdhci_host *host) >> > } >> > } >> > >> > - if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) >> > + if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V || >> > + !(caps[0] & SDHCI_CAN_VDD_180)) >> > caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 >> | >> >SDHCI_SUPPORT_DDR50); >> > >> > -- >> > 1.8.2.1 >> > >> >> I have no problem with this patch, except that it would be nice to get >> a few "tested by" to make sure it doesn't break UHS support for some >> SoCs. >> >> Kind regards >> Uffe >> > > Can anyone test this in some other SoC ? Appreciate your help .. > > Can you test this patch on imx SoC ? > > -- > Thanks, > with regards, > Suman Tripathi > -- Thanks, with regards, Suman Tripathi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [2/4,v3] powerpc/fsl-booke: Add T1024 QDS board support
> Subject: Re: [2/4,v3] powerpc/fsl-booke: Add T1024 QDS board support
>
> On Thu, Apr 09, 2015 at 04:07:43PM +0800, Shengzhou Liu wrote:
> > + flash@2 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "eon,en25s64"; /* 8MB */
> > + reg = <2>;
> > + spi-max-frequency = <1000>;
> > + };
>
> AFAICT the vendor is phyton, not eon.
How do you think the vendor is phyton?
Per en25s64 data sheet, it's really EON (Eon Silicon Solution, Inc,
www.eonssi.com)
I had sent a patch for EON http://patchwork.ozlabs.org/patch/367810/ last year.
There is no 'phyton' in binding document.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
incompatible type for argument 1 of 'htab_convert_pte_flags'
http://kisskb.ellerman.id.au/kisskb/buildresult/12433431/
arch/powerpc/mm/hash_utils_64.c:1478:2: error: incompatible type for
argument 1 of 'htab_convert_pte_flags'
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 24/24] m68k: Dispatch nvram_ops calls to Atari or Mac functions
Hi Finn,
On Sun, May 31, 2015 at 3:01 AM, Finn Thain wrote:
> A multi-platform kernel binary needs to decide at run-time how to dispatch
> the arch_nvram_ops calls. Add platform-independent arch_nvram_ops, for use
> when multiple platform-specific NVRAM ops implementations are needed.
Thanks for your series!
> Signed-off-by: Finn Thain
>
> ---
> arch/m68k/Kconfig |2
> arch/m68k/atari/nvram.c | 22 +
> arch/m68k/include/asm/atarihw.h |6 ++
> arch/m68k/include/asm/macintosh.h |4 +
> arch/m68k/kernel/setup_mm.c | 89
> ++
> arch/m68k/mac/misc.c |8 ++-
> 6 files changed, 117 insertions(+), 14 deletions(-)
>
> Index: linux/arch/m68k/atari/nvram.c
> ===
> --- linux.orig/arch/m68k/atari/nvram.c 2015-05-31 11:01:21.0 +1000
> +++ linux/arch/m68k/atari/nvram.c 2015-05-31 11:01:29.0 +1000
> @@ -73,7 +73,7 @@ static void __nvram_set_checksum(void)
> +#ifndef CONFIG_MAC
> const struct nvram_ops arch_nvram_ops = {
> - .read = nvram_read,
> - .write = nvram_write,
> - .get_size = nvram_get_size,
> - .set_checksum = nvram_set_checksum,
> - .initialize = nvram_initialize,
> + .read = atari_nvram_read,
> + .write = atari_nvram_write,
> + .get_size = atari_nvram_get_size,
> + .set_checksum = atari_nvram_set_checksum,
> + .initialize = atari_nvram_initialize,
> };
> EXPORT_SYMBOL(arch_nvram_ops);
> +#endif
IMHO, the #ifdef is ugly.
> #ifdef CONFIG_PROC_FS
> static struct {
> Index: linux/arch/m68k/mac/misc.c
> ===
> --- linux.orig/arch/m68k/mac/misc.c 2015-05-31 11:01:28.0 +1000
> +++ linux/arch/m68k/mac/misc.c 2015-05-31 11:01:29.0 +1000
> @@ -489,7 +489,7 @@ void pmu_shutdown(void)
> +#ifndef CONFIG_ATARI
> const struct nvram_ops arch_nvram_ops = {
> .read_byte = mac_pram_read_byte,
> .write_byte = mac_pram_write_byte,
> .get_size = mac_pram_get_size,
> };
> EXPORT_SYMBOL(arch_nvram_ops);
> +#endif
> #endif /* CONFIG_NVRAM */
Same here.
> Index: linux/arch/m68k/kernel/setup_mm.c
> ===
> --- linux.orig/arch/m68k/kernel/setup_mm.c 2015-05-31 11:00:59.0
> +1000
> +++ linux/arch/m68k/kernel/setup_mm.c 2015-05-31 11:01:29.0 +1000
> @@ -568,3 +572,88 @@ static int __init adb_probe_sync_enable
>
> __setup("adb_sync", adb_probe_sync_enable);
> #endif /* CONFIG_ADB */
> +
> +#if IS_ENABLED(CONFIG_NVRAM) && defined(CONFIG_ATARI) && defined(CONFIG_MAC)
Likewise.
> +static ssize_t m68k_nvram_read(char *buf, size_t count, loff_t *ppos)
> +{
> + if (MACH_IS_ATARI)
> + return atari_nvram_read(buf, count, ppos);
> + else if (MACH_IS_MAC) {
> + ssize_t size = mac_pram_get_size();
> + char *p = buf;
> + loff_t i;
> +
> + for (i = *ppos; count > 0 && i < size; --count, ++i, ++p)
> + *p = mac_pram_read_byte(i);
> +
> + *ppos = i;
> + return p - buf;
> + }
> + return -EINVAL;
Isn't this handled already by the nvram core, based on the available operations
in nvram_ops? Same for the other nvram abstractions in this file.
> +const struct nvram_ops arch_nvram_ops = {
> + .read = m68k_nvram_read,
> + .write = m68k_nvram_write,
> + .read_byte = m68k_nvram_read_byte,
> + .write_byte = m68k_nvram_write_byte,
> + .get_size = m68k_nvram_get_size,
> + .set_checksum = m68k_nvram_set_checksum,
> + .initialize = m68k_nvram_initialize,
> +};
> +EXPORT_SYMBOL(arch_nvram_ops);
Can't you just fill in the mach specific pointers in the generic structure,
and be done with it?
If you handle this right, I think you can do without the temporary "def_bool
(ATARI && !MAC) || (MAC && !ATARI)" in "[RFC 22/24] m68k/mac: Adopt nvram
module", too.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch v3 33/36] genirq: Use helper function to access irq_data->msi_desc
Use irq_data access helper to access irq_data->msi_desc, so we could
move msi_desc from struct irq_data into struct irq_common_data later.
Signed-off-by: Jiang Liu
---
arch/ia64/kernel/msi_ia64.c |2 +-
arch/ia64/sn/kernel/msi_sn.c|2 +-
arch/powerpc/sysdev/xics/ics-opal.c |2 +-
arch/powerpc/sysdev/xics/ics-rtas.c |2 +-
arch/tile/kernel/pci_gx.c |2 +-
drivers/pci/msi.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index 6c50d332b7d7..af4eaec0f7c3 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -23,7 +23,7 @@ static int ia64_set_msi_irq_affinity(struct irq_data *idata,
if (irq_prepare_move(irq, cpu))
return -1;
- __get_cached_msi_msg(idata->msi_desc, &msg);
+ __get_cached_msi_msg(irq_data_get_msi_desc(idata), &msg);
addr = msg.address_lo;
addr &= MSI_ADDR_DEST_ID_MASK;
diff --git a/arch/ia64/sn/kernel/msi_sn.c b/arch/ia64/sn/kernel/msi_sn.c
index 42b5a13af142..fb25065b22c6 100644
--- a/arch/ia64/sn/kernel/msi_sn.c
+++ b/arch/ia64/sn/kernel/msi_sn.c
@@ -175,7 +175,7 @@ static int sn_set_msi_irq_affinity(struct irq_data *data,
* Release XIO resources for the old MSI PCI address
*/
- __get_cached_msi_msg(data->msi_desc, &msg);
+ __get_cached_msi_msg(irq_data_get_msi_desc(data), &msg);
sn_pdev = (struct pcidev_info *)sn_irq_info->irq_pciioinfo;
pdev = sn_pdev->pdi_linux_pcidev;
provider = SN_PCIDEV_BUSPROVIDER(pdev);
diff --git a/arch/powerpc/sysdev/xics/ics-opal.c
b/arch/powerpc/sysdev/xics/ics-opal.c
index 3996393c254d..27c936c080a6 100644
--- a/arch/powerpc/sysdev/xics/ics-opal.c
+++ b/arch/powerpc/sysdev/xics/ics-opal.c
@@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d)
* card, using the MSI mask bits. Firmware doesn't appear to unmask
* at that level, so we do it here by hand.
*/
- if (d->msi_desc)
+ if (irq_data_get_msi_desc(d))
pci_msi_unmask_irq(d);
#endif
diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c
b/arch/powerpc/sysdev/xics/ics-rtas.c
index e2665a9dfc0f..3854dd41558d 100644
--- a/arch/powerpc/sysdev/xics/ics-rtas.c
+++ b/arch/powerpc/sysdev/xics/ics-rtas.c
@@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d)
* card, using the MSI mask bits. Firmware doesn't appear to unmask
* at that level, so we do it here by hand.
*/
- if (d->msi_desc)
+ if (irq_data_get_msi_desc(d))
pci_msi_unmask_irq(d);
#endif
/* unmask it */
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index b1df847d0686..65b701b3b5ed 100644
--- a/arch/tile/kernel/pci_gx.c
+++ b/arch/tile/kernel/pci_gx.c
@@ -1442,7 +1442,7 @@ static struct pci_ops tile_cfg_ops = {
/* MSI support starts here. */
static unsigned int tilegx_msi_startup(struct irq_data *d)
{
- if (d->msi_desc)
+ if (irq_data_get_msi_desc(d))
pci_msi_unmask_irq(d);
return 0;
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index be6034cf5c21..c2f0da733d3a 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1178,7 +1178,7 @@ EXPORT_SYMBOL(pci_enable_msix_range);
*/
void pci_msi_domain_write_msg(struct irq_data *irq_data, struct msi_msg *msg)
{
- struct msi_desc *desc = irq_data->msi_desc;
+ struct msi_desc *desc = irq_data_get_msi_desc(irq_data);
/*
* For MSI-X desc->irq is always equal to irq_data->irq. For
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch v3 24/36] powerpc, irq: Use access helper irq_data_get_affinity_mask()
Use access helper irq_data_get_affinity_mask() to hide implementation
details of struct irq_desc.
Signed-off-by: Jiang Liu
---
arch/powerpc/kernel/irq.c |2 +-
arch/powerpc/sysdev/xics/ics-opal.c |2 +-
arch/powerpc/sysdev/xics/ics-rtas.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 45096033d37b..290559df1e8b 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -441,7 +441,7 @@ void migrate_irqs(void)
chip = irq_data_get_irq_chip(data);
- cpumask_and(mask, data->affinity, map);
+ cpumask_and(mask, irq_data_get_affinity_mask(data), map);
if (cpumask_any(mask) >= nr_cpu_ids) {
pr_warn("Breaking affinity for irq %i\n", irq);
cpumask_copy(mask, map);
diff --git a/arch/powerpc/sysdev/xics/ics-opal.c
b/arch/powerpc/sysdev/xics/ics-opal.c
index 68c7e5cc98e0..3996393c254d 100644
--- a/arch/powerpc/sysdev/xics/ics-opal.c
+++ b/arch/powerpc/sysdev/xics/ics-opal.c
@@ -54,7 +54,7 @@ static void ics_opal_unmask_irq(struct irq_data *d)
if (hw_irq == XICS_IPI || hw_irq == XICS_IRQ_SPURIOUS)
return;
- server = xics_get_irq_server(d->irq, d->affinity, 0);
+ server = xics_get_irq_server(d->irq, irq_data_get_affinity_mask(d), 0);
server = ics_opal_mangle_server(server);
rc = opal_set_xive(hw_irq, server, DEFAULT_PRIORITY);
diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c
b/arch/powerpc/sysdev/xics/ics-rtas.c
index 0af97deb83f3..e2665a9dfc0f 100644
--- a/arch/powerpc/sysdev/xics/ics-rtas.c
+++ b/arch/powerpc/sysdev/xics/ics-rtas.c
@@ -47,7 +47,7 @@ static void ics_rtas_unmask_irq(struct irq_data *d)
if (hw_irq == XICS_IPI || hw_irq == XICS_IRQ_SPURIOUS)
return;
- server = xics_get_irq_server(d->irq, d->affinity, 0);
+ server = xics_get_irq_server(d->irq, irq_data_get_affinity_mask(d), 0);
call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hw_irq, server,
DEFAULT_PRIORITY);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 25/34] powerpc/powernv/ioda2: Introduce helpers to allocate TCE pages
On Fri, May 29, 2015 at 06:44:49PM +1000, Alexey Kardashevskiy wrote: > This is a part of moving TCE table allocation into an iommu_ops > callback to support multiple IOMMU groups per one VFIO container. > > This moves the code which allocates the actual TCE tables to helpers: > pnv_pci_ioda2_table_alloc_pages() and pnv_pci_ioda2_table_free_pages(). > These do not allocate/free the iommu_table struct. > > This enforces window size to be a power of two. > > This should cause no behavioural change. > > Signed-off-by: Alexey Kardashevskiy > Reviewed-by: Gavin Shan Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpBY_sxUiDHP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 01/24] macintosh/nvram: Remove as unused
On Sun, May 31, 2015 at 3:01 AM, Finn Thain wrote:
> Signed-off-by: Finn Thain
Removal seems to be forgotten by full-history-linux
commit 17c6f4635bea74e110ab3558d408c9cd218c568a
Author: Benjamin Herrenschmidt
Date: Fri Feb 6 14:20:56 2004 +1100
ppc32: Rework nvram management
move drivers/macintosh/nvram.c to drivers/char/generic_nvram.c,
update platform hooks,
fix powermac nvram driver for newer machines
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Set up and enable PSL Timebase
Michael Neuling wrote:
On Thu, 2015-05-28 at 15:12 +0200, Philippe Bergheaud wrote:
This patch configures the PSL Timebase function and enables it,
after the CAPP has been initialized by OPAL. Failures are reported
and ignored.
Needs an Signed-off-by.
Yes.
Comments inline.
---
drivers/misc/cxl/cxl.h |5 +
drivers/misc/cxl/pci.c | 35 +++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index a1cee47..38a7cf9 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -82,8 +82,10 @@ static const cxl_p1_reg_t CXL_PSL_AFUSEL = {0x00B0};
/* 0x00C0:7EFF Implementation dependent area */
static const cxl_p1_reg_t CXL_PSL_FIR1 = {0x0100};
static const cxl_p1_reg_t CXL_PSL_FIR2 = {0x0108};
+static const cxl_p1_reg_t CXL_PSL_Timebase = {0x0110};
static const cxl_p1_reg_t CXL_PSL_VERSION = {0x0118};
static const cxl_p1_reg_t CXL_PSL_RESLCKTO = {0x0128};
+static const cxl_p1_reg_t CXL_PSL_TB_CTLSTAT = {0x0140};
static const cxl_p1_reg_t CXL_PSL_FIR_CNTL = {0x0148};
static const cxl_p1_reg_t CXL_PSL_DSNDCTL = {0x0150};
static const cxl_p1_reg_t CXL_PSL_SNWRALLOC = {0x0158};
@@ -151,6 +153,9 @@ static const cxl_p2n_reg_t CXL_PSL_WED_An = {0x0A0};
#define CXL_PSL_SPAP_Size_Shift 4
#define CXL_PSL_SPAP_V0x0001ULL
+/** CXL_PSL_Control /
+#define CXL_PSL_Control_tb 0x0001ULL
+
/** CXL_PSL_DLCNTL */
#define CXL_PSL_DLCNTL_D (0x1ull << (63-28))
#define CXL_PSL_DLCNTL_C (0x1ull << (63-29))
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index fc938de..afd89cc 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -360,6 +360,38 @@ static int init_implementation_adapter_regs(struct cxl
*adapter, struct pci_dev
return 0;
}
+#define TBSYNC_CNT(n) (((u64)n & 0x7) << (63-6))
+
+static int cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
+{
+ u64 psl_tb;
+ int delta;
+ unsigned int retry = 0;
+
+ /*
+* Setup PSL Timebase Control and Status register
+* with the recommended Timebase Sync Count value
+*/
+ cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2));
2?
Quoting the PSL workbook description of the PSL_TB_CTLSTAT register:
4:6 tbsync_cnt
TimebaseSyncCount. Number of 250MHz cycles x 2048 before initiating another
Timebase Recalibration sequence.
Processor chipTimebase facilities receive a tod_sync pulse every 16us or 4000
250 MHz cycles so '010' is the Recommended value.
000 = never
001 = 2048
010 = 4096 (2 * 2048)
...
111 = 14336 (7 * 2048)
Will make the TimebaseSyncCount unit explicit. Something like:
#define _2048_250MHZ_CYCLES 1
cxl_p1_write(adapter, CXL_PSL_TB_CTLSTAT, TBSYNC_CNT(2 * _2048_250MHZ_CYCLES));
+
+ /* Enable PSL Timebase */
+ cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
+ /* Wait until CORE TB and PSL TB difference <= 16usecs */
How many tries does this normally take?
Two. The second attempt always succeds.
Should we have a sleep in here to wait for it to sync rather than just
coming back around right away?
Yes, will add msleep(1) at the beginning of the loop (as the first attempt
always fails).
+ do {
+ if (retry++ > 5) {
+ pr_err("PSL: Timebase sync: giving up!\n");
+ return 1;
Please use negative error codes here. -EIO?
OK.
+ }
+ psl_tb = cxl_p1_read(adapter, CXL_PSL_Timebase);
+ delta = mftb() - psl_tb;
+ if (delta < 0)
+ delta = -delta;
+ } while (cputime_to_usecs(delta) > 16);
+
+ dev_info(&dev->dev, "PSL: Timebase synced\n");
+ return 0;
+}
+
static int init_implementation_afu_regs(struct cxl_afu *afu)
{
/* read/write masks for this slice */
@@ -995,6 +1027,9 @@ static struct cxl *cxl_init_adapter(struct pci_dev *dev)
if ((rc = pnv_phb_to_cxl(dev, OPAL_PHB_CAPI_MODE_CAPI)))
goto err3;
+ /* Don't care if this one fails: */
+ cxl_setup_psl_timebase(adapter, dev);
And check it here.
OK.
Thank you,
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup
Am 28.05.2015 um 13:52 schrieb Dominik Dingel: > Hi everyone, > > there is a potential bug with KVM and hugetlbfs if the hardware does not > support hugepages (EDAT1). > We fix this by making EDAT1 a hard requirement for hugepages and > therefore removing and simplifying code. The cleanup itself is nice and probably the right thing to do. Emulating large pages makes the code more complex and asks for trouble (as outlined above) The only downside that I see is that z/VM as of today does not announce EDAT1 for its guests so the "emulated" large pages for hugetlbfs would be useful in that case. The current code allocates the page table only once and shares it for all mappers - which is useful for some big databases that spawn hundreds of processes with shared mappings of several hundred GBs. In these cases we do save a decent amount of page table memory. Not sure if that case is actually important, though. Christian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 23/34] powerpc/iommu/powernv: Release replaced TCE
On Fri, May 29, 2015 at 06:44:47PM +1000, Alexey Kardashevskiy wrote: > At the moment writing new TCE value to the IOMMU table fails with EBUSY > if there is a valid entry already. However PAPR specification allows > the guest to write new TCE value without clearing it first. > > Another problem this patch is addressing is the use of pool locks for > external IOMMU users such as VFIO. The pool locks are to protect > DMA page allocator rather than entries and since the host kernel does > not control what pages are in use, there is no point in pool locks and > exchange()+put_page(oldtce) is sufficient to avoid possible races. > > This adds an exchange() callback to iommu_table_ops which does the same > thing as set() plus it returns replaced TCE and DMA direction so > the caller can release the pages afterwards. The exchange() receives > a physical address unlike set() which receives linear mapping address; > and returns a physical address as the clear() does. > > This implements exchange() for P5IOC2/IODA/IODA2. This adds a requirement > for a platform to have exchange() implemented in order to support VFIO. > > This replaces iommu_tce_build() and iommu_clear_tce() with > a single iommu_tce_xchg(). > > This makes sure that TCE permission bits are not set in TCE passed to > IOMMU API as those are to be calculated by platform code from > DMA direction. > > This moves SetPageDirty() to the IOMMU code to make it work for both > VFIO ioctl interface in in-kernel TCE acceleration (when it becomes > available later). > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpR61Gy7ZVXa.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
